Saturday, December 28, 2013

ADF UI with MongoDB for persistence

The sample application (JDeveloper 12c / 12.1.2) is available here.
This is a simple ADF application whose underlying business service implementation uses MongoDB for persistence.
The application allows create & update operations on a one-to-many data model (Department-Employees)

As shown in the screenshot below, you can Create a new department and then create a few employee records. The "Save all changes" button then calls the standard ADF POJO DataControloperations that in turn delegate the persistence of these objects to the MongoDB without using any SQL.

The data is saved in a database called "hrdb"  (see class MongoDAO in the Model project) in a collection called "Departments"

The design I have used is very basic and shown below.
I have used simple POJOS extending ReflectionDBObject as my 'persistable' entities but this can be anything else (such as EclipseLink) that can support MongoDB (either programmatically or out of the box).

1. Start an instance of MongoDB (v2.4.8) using mongod and all the default options.
If you enable authentication or the host/port is different, just change these in the MongoDAO class in the sample project
2. Just run the project.
3. Verify the data creates/updates either using the MongoDB console or the ReST interface via browser

Wednesday, December 18, 2013

Webservice interaction patterns - part 2 - Synchronous Webservice call timeouts

Goal: For reasons of performance and more importantly, good user experience, the client application (ADF) should be able to timeout gracefully instead of hanging indefinitely (and/or potentially causing STUCK threads on the ADF server) when invoking an external 'synchronous' web service.

At runtime
When I run the application,
If I enter all fields (remember to enter a unique Employee ID, email address etc), then the 'Commit' button calls the web service as usual.

However, if I Create a new record with the FirstName field set to TIMEOUT, you will notice that you see a timeout message on the screen after around 6 seconds.
 (don't update an existing one as in the sample app, the update operation just goes directly to the DB)

If I had not performed the setup listed in the "Client setup" section below, this would have resulted in a screen that appears to hang for a long time (with STUCK threads observed on the ADF application server after a while depending on the settings there)

My setup

Download the sample application from here.
I developed my 'external' transactional service using the SOA suite (BPEL).

1) From the zip file, open Webservices/EmpDeptCrud application and deploy the DataService on a SOA server (on a domain called 'default').
2) Open the TestWSCreateTimeout ADF application.
IF your SOA Server doesn't run on the URL http://soabpm-vm:7001, and you don't deploy it to a domain called 'default', then change the location property in the wsdl file to reflect where your service is accessibleThen right-click on the wsdl and "Generate web service proxy"
3) Just for the purpose of this test, go to the SOA server EM console and then navigate to the BPEL engine settings as shown below. Change the SyncMaxWaitTime
property to 600 (sec) or more.

In my web service implementation (a BPEL process), I added a wait activity that waits for 5 minutes as shown in the screenshot below.

Increased the default timeout (SyncMaxWaitTime) set in the SOA Suite's BPEL engine properties to be 10 minutes (600 sec) just so that my wait activity is effective. In the Oracle SOA Suite this timeout is 45 seconds by default (In other technologies it may be different or non-existent - hence this post that shows you what should be done to handle this gracefully on the client/UI side).
As a web application developer, you probably wouldn't have access to these settings on the service side.

The sample application is just an enhanced version of the one created for the previous post in this series. Both the ADF ui application and the web service are created using JDeveloper
(Although the ADF application could have been created in any other JDev release as the two are run independently on different servers)

Client setup (The ADF application)

At the point I invoke the external web service, it's a matter of adding the appropriate parameters in the request context. The REQUEST_TIMEOUT property is most relevant in this particular scenario.  A reasonable CONNECT_TIMEOUT is also recommended.
Just look at the code for the imports and libraries used.
The setup in ADF code is shown below

Friday, December 13, 2013

Webservice interaction patterns - part 1 - very basic DML

There are a number of ways you 'call' web services from an ADF application. The best method to choose would depend on the individual scenario.

This particular example is the most suitable option where:
- Our application is allowed to read from the database using its own business services - i.e. ADFbc (which are fairly easy to create and don't require a lot of 'plumbing' code compared to other technologies) but we need to delegate any transactional calls (such as create/update/deletes) to an external web service.

The reasons could be many: Most commonly, such business (web) services already exist with a number of person-years of effort, testing & polishing already gone into them and they already meet the requirements perfectly. So it makes perfect sense to not re-develop all that logic into ADFbc and just reuse the existing service.

What this post is not: If you have written all your business logic using ADF business components then you can expose that as a web service (e.g. for consumption of the mobile version of your app.) That is a different scenario altogether.

If ALL data access operations (both reads and writes) are based on web services, I would most likely choose a different approach. (which I will cover in the subsequent posts in this series).

The sample application (Created in JDev has three parts
1)  the web service which provides the Create operation.
I simply created it using the SOA Suite - but that's not the important part - you can pick the wsdl and implement the service using any technology. I also exposed only the Create operation for now and that too, just for a single row. It's easy to expose all the other CRUD operations as well.

2) The ADF application (Application TestWSCreate in the zip file). Contains the Model and ViewController projects (thing to note is the EmployeeImpl class and its doDML operation)
3) The web service proxy - which is just code generated from the wsdl. I have kept it in the Model project but it should probably be in its own project or application which you could call ExternalService clients etc.
Contents of my Model project are shown below:

Download the application from here1) On the server where you'll deploy the web service, create an XA data source pointing to the XE schema with the JNDI name jdbc/hrXADS
2) Create a connection pool on the DBAdapter with the jndi name eis/db/hrXA
and point it to the above XA data source

3. Open the application EmpDeptCRUD and deploy the project DataService on the SOA server.
I used the SOA-BPM VM and on my machine it runs at http://soabpm-vm:7001 . If your SOA server is running at a different
address, just point the location inside the WSDL in the proxy to your server's location (see the screenshot of the Model project) and re-generate the proxy classes (right click - generate web service proxy....)

4. Open and run the adfc-config from ViewController in the application TestWSCreate
Clicking 'Create New' will create a new Employee record - you can enter data, perform validations.
Finally, when you click 'Commit' the web service is invoked.

Here is how/why it happens:

Coming up:
- Detecting and Handling timeouts
- Leveraging the SOA Suite features (if the implementation technology for your external webservices is the SOA suite or even if you have a SOA Suite license).
- Optimizing web service calls when performing creates in a table / collection

Also see:

Update: updated the step on what to do when the web service URL is changed.

Thursday, December 12, 2013

JDeveloper Productivity features - run current working set

In a well designed application ('the sum of parts'), we probably divide functionality into projects. 
At any given time individual developers normally work on one or two projects, which they need to run and test quickly using the integrated weblogic server. 
For years I found the working set feature very effective for this:

Particularly note:

4.3.6 How to Manage Working Sets How to Run and Debug a Working Set

basically, using working sets, JDeveloper would only build, deploy and run projects you are specifically interested in or working on, saving you time.