Oracle Mobile Cloud Service First Hands-On Experience

Thanks to SOA Community and Jurgen Kress, I had a chance to play with Oracle MCS (Mobile Cloud Service). This new Oracle product is promoted with full force by Oracle PM team, there is dedicated Youtube channel with videos to watch and learn - Oracle Mobile Platform. Mobile Cloud Service offers mobile enterprise repository to organize and support your mobile development. Mobile backend services, security, connectors, storage and etc. can be defined and managed in MCS. Web Services published in MCS can be monitored to track performance and errors. All this should simplify mobile solutions implementation.

This was my first encounter with MCS and I would like to describe the test I did. MCS UI is implemented with Oracle internal JS framework following Alta UI standard. There are options to monitor and administer MCS instance. I'm more interested in development options:

I will not go through all available options, but only focus on Mobile Backend. Basically we can define a group, where we could include various reusable business logic artefacts (API's). Mainly this will be different Web Service calls. The same Web Service calls can be reused by mobile application developer.

In Mobile Backend section we can edit existing groups or create a new one:

You should think about Mobile Backend as about a group of reusable code artefacts (API's). There is an option to create new API or reuse existing one. I decided to reuse existing API for Incidents registration:

This API implements REST Web Service call to register new incident, also it allows to query information about previously reported incidents. This can be tested directly in MCS environment, we could define sample payload data and simulate Web Service call to register new incident:

Web Service call is successful, we can observe this from the log - new incident is registered and ID is assigned. Same Web Service will be reused from mobile application. With MCS we could monitor Web Service usage, number of invocations, errors, etc. - this makes it easier to manage entire infrastructure for mobile solutions:

To make sure new incident was successfully registered, I could run another REST call for the same Web Service - to get incident information about ID:

Result shows incident data, this means incident was located successfully:

Incidents registration service is registered in API's group, we could edit and test this Web Service online in MCS:

Red Samurai mobile backend service is live - invocation statistics and processing time metrics are aggregated by MCS:

Using Shared AM to Cache and Display Table Data

This post is based on Steve Muench sample Nr. 156. In my personal opinion, ADF samples implemented by Steve Muench still remain one of the best source of examples and solutions for various ADF use cases. Sample Nr. 156 describes how to use Shared AM to display cached data in UI table. Typically Shared AM's are used to implement cached LOV's (session or application scope). But it could go beyond LOV, based on the use case we could display cached data in the table or form. I have tested this approach with 12c and it works fine.

Download sample application - ADFBCSharedSessionLOVApp.zip. AM is defined with application scope cache level - this means cached data will be available for multiple users:

In order to display cached data on UI and pass it through ADF bindings layer, we need to use Shared AM configuration in bindings:

You should create new Data Control reference entry manually in DataBindings.cpx file. JDeveloper doesn't provide an option to select Shared AM configuration. Simply change configuration property to Shared (HrModuleShared as per my example):

Make sure to use correct Data Control entry for iterator in the Page Definition. Cached table iterator binding should point to shared Data Control configuration:

This is how it looks like on UI - readonly table data is fetched once and cached in application scope cache. Other users will be reusing cached data, without re-fetching it from DB:

Jobs VO is set with AutoRefresh = true property. This turns on DB change notification listener mechanism and keeps VO data in synch, when changes happen in DB. This helps to auto refresh cached VO (read more about it Auto Refresh for ADF BC Cached LOV):

Here is the test. Let's change Job Title attribute value in DB:

Click on any row from Jobs table, or use any buttons (make a new request). Cached VO will be re-executed and new data will be fetched from DB, including latest changes:

You should see in the log, DB change notification was received and VO was re-executed, VO data was re-fetched:

Oracle Process Cloud Application Player

With Oracle Process Cloud you can forget these days when you was waiting long to deploy BPM process and test Human Task UI. No need to wait anymore, in Oracle Process Cloud you could use Application Player feature, this allows to run the process and test Human Task UI almost instantly.

To demonstrate Application Player functionality, I have implemented basic process of Data Entry for the Claim Handling:

This process is using Web Form in the Start activity to capture data, human activity Claim Expense Review allows to review entered data, before submitting it:

This is how Web Form UI design looks like:

When you build Web Form and arrange UI components, business type is constructed automatically, no need to define anything separately. Business type can be used in the process, without changing it:

Data object variable is assigned to the process activity element through Association dialog in Process Cloud, this is where you can map input/output with business type:

Once process is ready to be tested, all you need to do is to invoke Application Player. Click on Test Application button in the top right corner:

In the Test Application window you should select Play option:

To show how it works, I have recorded a video - see yourself how helpful is Application Player:

Auto Refresh for ADF BC Cached LOV

You can configure auto refresh for ADF BC cached LOV and this works out of the box, no special coding is needed. My previous post describes how ADF BC session cached LOV behaves - ADF BC Session Cached LOV - Understanding Expire Time. Auto refresh can be configured for both application and session caching. One important thing - auto refresh doesn't work when ADF BC is configured with disconnected mode (ADF BC Tuning with Do Connection Pooling and TXN Disconnect Level). I would guess this is related to DB notification listener, it can't notify about DB changes, when DB connection is being taken from AM.

Make sure to remember to configure AM without disconnected mode. Auto refresh works for both application and session caching levels:

As a reminder - in order to use shared LOV functionality, you must select VO instance for LOV from shared AM configuration. See how it looks in the LOV definition wizard:

Auto refresh functionality is enabled with a single property - AutoRefresh = true. This can be set through VO general properties or directly in the VO source code:

Make sure Disconnect Application Module Upon Release option is not set:

I have overriden VO method processChangeNotification for logging purposes, this method is invoked automatically for VO's set with AutoRefresh = true. No need to code anything here, I'm just logging method invocation:

Let's do a test. First of all, check entries of Job list:

Go to DB and update one of the entries. For example, change Stock Clerk title and commit changes:

Come back to UI and press any button. This will trigger new request and Jobs list shared VO will be notified about DB change to refresh:

Check the list again, you should see changed entry for Stock Clerk:

In the log we can observe a call for change notification, it triggers shared LOV query re-execution and data re-fetch:

See recorded demonstration video, where I show refresh behaviour live:

Download sample application - ADFBCSharedSessionLOVApp.zip.

ADF BC Session Cached LOV - Understanding Expire Time

ADF BC offers LOV caching feature. There are two caching levels - application and session. With application level enabled, it makes LOV rows available for all users. On contrary for session level LOVs, data is cached for single session only. In this post I will focus on session level LOV's and I'm going to explain when cached data expires and is re-fetched.

You can configure caching level for LOV's in Model.jpx file, open AppModules section and select appropriate caching level for AM. I will be using Session level. Key point to understand - session level caching for LOV is nothing to do with Web user session lifetime. Session here is AM session, and cache remains in memory only until AM session remains assigned to the current user session:

LOV with caching feature is defined a bit differently, List Data Source must be selected from shared AM, other steps are the same:

My sample application implements two different VO's, based on Employees data. Both VO's are using the same cached LOV in session level for Jobs. This helps to make a test and check if cached LOV data expires. When cache is not expired, LOV data cached during first VO initialisation, should be present on the second LOV access. Above is example of Jobs LOV definition for Employees VO and below another example of Jobs LOV definition for Employees By Departments VO:

LOV VO is created with implementation class, where I override createRowFromResultSet method. It helps to track if LOV data was expired and rows were re-fetched:

As I have mentioned earlier, there are two VO's, both using the same cached LOV. On UI I have two different fragments, each located in TF. Call between two TF's is implemented, I'm using two different TF's to simulate Isolated TF behaviour. Isolated TF creates new instance of AM and this clears the cache of LOV on AM session level:

Let's understand how it works. First fragment is loaded, LOV data is fetched and cache is populated:

We can observe in the log, all rows fetched for LOV:

Open second fragment, LOV data is not re-fetched, it will be taken from the cache:

There are no rows fetched reported in the log:

Session cache works correctly for LOV. Now if user invoked Rollback, AM is reset and this indicates end of cache on AM session level, rows will be re-fetched. Try to press Cancel button:

There will be entries in the log, showing information about fetched rows - cache was cleared on Rollback:

Let's do another test with second TF set with Isolated option. When TF is set to be Isolated, it will force new AM instance creation, each time with TF is loaded. Meaning - there will be always new AM session and LOV cache will never be reused. TF is set to be Isolated:

Try to open TF and check LOV:

Differently than before, LOV data will be fetched - new AM instance was created on Isolated TF access and this requires to refill LOV data list:

Download sample application - ADFBCSharedSessionLOVApp.zip.

Oracle Process Cloud Service - SOAP Web Service Integration

Oracle Process Cloud (https://cloud.oracle.com/process) allows to invoke SOAP services, along with REST services. You can define a library of SOAP services in Oracle Process Cloud application and use them within the process. This helps to integrate with business logic running on premise.

I have implemented regular SOAP service in ADF BC, just to test how it works to invoke it from Process Cloud:

SOAP service method accepts employee ID and checks the status. ADF BC application is deployed on standalone WLS. Make sure to select correct deployment profile, when deploying ADF BC with SOAP on standalone server, otherwise SOAP service reference will be missing in deployed application. You should use ADF BC service deployment profile:

Once SOAP service is deployed, you can access WSDL file through Enterprise Manager. Oracle Process Cloud currently doesn't support direct SOAP references, instead you must provide WSDL file copy for Web Service registration:

Download WSDL file from URL (here is the sample WSDL, I was using for my test - HrModuleService.wsdl). This is how it looks like, it contains SOAP service description:

Here you can see Oracle Process Cloud interface. It looks quite user friendly and functional, this is what I like about it. On the left side, there is menu with different objects - Processes, Web Forms, Web Services, etc.:

To add new SOAP service reference is fairly easy, provide a name and upload WSDL file:

Once service is registered, we can go to the process diagram and select Service component from the palette:

Drag and drop it on the diagram, Implementation section will be opened, where you should specify SOAP service reference to be invoked:

Select Service Call from the list, this allows to invoke SOAP Web Service:

Once option for Service Call will be selected, you will be able to select Web Service reference. I have defined only one service, it is listed in the popup - select it:

Operation field is listing all available methods from the service, select one of the operations to be invoked:

Data associations are available to define correct mapping for the input/output values for the SOAP Web Service call, this can be done through Process Cloud composer window:

If you are interested in Human Task UI implementation in Oracle Process Cloud, read my previous post about REST service integration: Oracle Process Cloud Service - Consuming ADF BC REST Service in Web Form.