Monday, January 26, 2015

How To Add New Operation in Oracle Mobile Suite Service Bus REST Service

I will use sample app from my previous blog post as the basis - Oracle Mobile Suite Service Bus REST and ADF BC SOAP. I was describing there the main steps in defining transformation from SOAP WS based on ADF BC to the REST WS interface. I will dive a little bit deeper into the same topic and will explain how to add new operation to the REST WS interface.

Here you can download updated sample application - In order to add new operation to the REST interface, you should choose Edit REST option for REST Proxy Service in JDEV Service Bus project:

REST Binding editor will appear. Here you should define new resource - I will add /employees to return the list of all employees. New operation should be defined for resource path - /employees, operation getEmployeesListAll in my case:

You can give any meaningful name for the operation. Make sure to select correct resource path and use GET (if you want to fetch data, not update or delete). I'm getting the list of all employees, this means there will be no parameters in this case:

In the response specification tab for the getEmployeesListAll operation, make sure select JSON as the payload. You could use the option to generate sample payload - this shows what kind of result set will be constructed (based on the response XSD - HRRestProxy.xsd, I have created it in the previous post mentioned above):

Once new operation is defined in the REST wizard, we can add it to the mapping. Simply you could copy existing operation mapping to the newly created operation branch. Select new branch and provide required operation name - getEmployeesListAll in this case:

We need to edit request action first and specify empty payload - we want to fetch the list of all employees. For this we could reuse existing transformation file (REST to SOAP):

Important to remember - transformation file is created as a XQuery Map module, where you need to specify source and target types (this will allow to transform REST to SOAP and vice versa):

Request action contains empty value binding - REST variable will be initialised as empty, this will allow to use getEmployeesListAll operation with /employees path:

For response action I'm reusing the same transformation as in getEmployeeList operation - response will be parsed in the same way, using the same binding:

This is how it works - the list of all employees is fetched with /employees path (testing using Postman extension available in Google Chrome):

Previously implemented operation works as well, user could search by First Name/Last Name:

Friday, January 16, 2015

Reading MAF iOS Simulator Logging Output

It could be very handy to know how and where to read MAF logging output from iOS simulator. This is not that obvious to find logging output on Mac OS system. All log is written into application.log file, this file is located inside temporary application directory. I will explain how to locate this directory and how to open application.log file. You can read more about MAF testing and logging here - 18.5 Using and Configuring Logging.

Sample mobile application -, is pretty basic and contains System.out.println to write a message into application.log file:

Message is written to the log from Action Listener method, invoked from Save button. Log file application.log is accessible from the following location (you can access it from the console) -

Users/youruser/Library/Application Support/iPhone/ 7.1/Applications/

As you can see, application.log file is stored under logs directory in documents folder. You must navigate to the iOS simulator, application temporary folder to access it:

There will be application.log file available:

Log file can be opened directly from console, execute command open -a TextEdit application.log:

Message from saveAction() is printed in the log:

Enjoy MAF coding in Mac OS !

Saturday, January 10, 2015

How To Start a Case in Oracle Adaptive Case Management 12c

Blog reader was asking to describe how to start a new case in Oracle ACM 12c. You can read my previous blog post on ACM 12c topic - Adaptive Case Management 12c and ADF Human Tasks. There are multiple ways to start a case, depends if you want just to test the case or really use it. I would recommend to use SoapUI to test the case. In the real scenario, case most likely will be started from third party web service or through ACM 12c Java API. Here I would like to describe, how you could use SoapUI to test ACM process during development.

Once ACM 12c application is deployed, you could open it in EM. There is the option to test deployed composite and invoke it through EM Web Service tester. In the example below you can see startCase operation selected and payload structure displayed. Unfortunately it doesn't work well to test ACM process through EM, payload structure is very confusing and it usually fails with mandatory attributes missing errors:

Instead I would recommend to use SoapUI to test the ACM 12c composite. You could download and use it free of charge. Start the tool and choose to create New SOAP Project:

We need WSDL URL to define a SOAP project in SoapUI. You can copy WSDL URL from EM test screen:

Paste it into SoapUI dialog (Initial WSDL field) and Project Name will be filled in automatically (keep Create sample requests for all operations? option selected):

SoapUI will fetch all operations from the service and new SoapUI project will be generated:

In order to start a new case, expand startCase operation and open Request 1. Request will be pre-filled with default payload structure (similar as we saw in EM):

Save SoapUI project, before doing any changes to the request structure. I would suggest to save it under ACM JDEV application structure - project is saved into single XML file:

Change the request to include custom data payload (you can find this XML code inside sample application available for download) and invoke the service. If request will be successful, you should see case number returned in the response:

Case with the same number should be available in BPM Workspace:

Here you can download sample application with SoapUI project (XML file) included -

Sunday, January 4, 2015

Oracle Mobile Suite Service Bus REST and ADF BC SOAP

One of the key parts of Oracle Mobile Suite 12c offering is Service Bus product. This is logical choice - Service Bus allows to transform complex SOAP Web Service data into simplified REST format, preferred by mobile client. I think it is essential to use Service Bus, when implementing enterprise mobile applications. It makes sense to learn how Oracle Service Bus works. I would recommend to start from Steven Davelaar excellent tutorial article, available here - Creating a Mobile-Optimized REST API Using Oracle Service Bus – Part 2.

I have created my own ADF BC application with SOAP WS - findEmployees method (filters by first and last name). Here you can download both applications - Keep in mind, for some reason Service Bus server doesn't start with JDEV 12c BPM Default Domain, it works only with JDEV 12c SOA Default Domain. Make sure to check, which JDEV you are using, you can check the list features installed:

ADF BC SOAP service is implemented to support Master-Detail (Employee - Department Managed by Employee) structure:

Detail VO is visible in WS response, only when ADF BC SDO classes are generated for the VO:

Here is Service Bus application main diagram. External Services contains a reference to the ADF BC SOAP WS (invoked through HTTP service). Proxy Services contains a reference to the REST proxy (this will be accessed from mobile device). Pipeline contains a mapping resource, this is where transformation between SOAP and REST happens:

REST proxy service is defined to support getEmployeesList operation with parameter - nameVar:

REST proxy service response is configured with EmployeeListResponse element, stored in HRRestProxy.xsd file:

Here is the structure returned by REST proxy service - list of employees and list of departments managed by employee:

Pipeline mapps SOAP and REST services. Here we can define how request and response actions are handled. Request action is processed with mapping stored in EmployeeDetailsPS2BS file:

Request action mapping is simple, it needs to pass search parameter and assign it to nameVar parameter from SOAP WS:

This is how search parameter is initialised in REST -  through special expression, value is taken from REST request and sent to SOAP call through mapping:

Response is handled with EmployeeDetailsBS2PS mapping:

This mapping is more complex and it represents the data, returned by REST proxy service. Here we need to map all attributes from SOAP WS to REST proxy service response. This is the place, where actual transformation happens - here we can decide, how we map attributes and even convert between types:

To test Service Bus application, you can simply right click on REST proxy service and choose run:

Service Bus application should be accessible in Enterprise Manager, list of all operations should be present. In the picture below, we can see both SOAP and REST proxy services present. You can open HRRestService:

Test button is present, this allows to test REST proxy service directly from Enterprise Manager:

Provide search parameter  - it will look for 'w' in both first and last name:

Response is constructed with list of employees:

This is request URL:, it can be used from mobile client, to retrieve similar data (department managed by employee 200 is present):

Tuesday, December 30, 2014

Custom ADF Application with New ADF 12c Alta UI

I was inspired by recently published WorkBetter application with ADF 12c Alta UI demo (you can read more about Alta UI and download WorkBetter application from here - Oracle Alta UI). I have decided to create my own application, using the same guidelines as described by Alta UI. While WorkBetter application is based on EJB, my application is using regular ADF BC model. Right now it displays a list of employees from HR schema and allows to edit selected employee data. In the future, I plan to add CRUD support and more advanced UI features. I would recommend to watch a video from Shay Shmeltzer, he describes how to build your first Alta UI application in ADF.

Here you can download my sample application, implemented with Alta UI - This application implements ADF task flow with employees data. By default, employees data is displayed as a list (you should see how it differs comparing to pre-Alta ADF UI, now UI is much cleaner and only essential data is displayed):

According to Alta UI guidelines, user should be given an option to switch to a grid view. This is useful and gives different perspective for the data view:

In the grid view there is an option to flip an item to see more details about particular entry - address, manager name in this case:

I'm using ADF quick search component to filter employees data. Quick search offers an option to select search field from the list - this is quite handy and comes out of the box:

User can click on any entry and this will navigate to the edit form. According to Alta UI guidelines, edit form should not be overloaded and must contain only necessary data. Sections must be clear enough to separate different data blocks:

You can switch to the list view, the same filtered data will be displayed in the list:

Let's dive into application code now. I'm using helper bean from WorkBetter application, this bean contains a method to trigger navigation by a hidden button located in the fragment (this is how navigation between fragments is implemented in WorkBetter app):

Quick query component is implemented as a standard ADF query block:

List and grid layout views are implemented as separate items, there is no single special component for this. Dedicated buttons are resetting variables and changing the view, based on the setting - one or another view is rendered:

Both components are implemented inside ADF Faces List, while actual list view layout is implemented inside ADF Faces panelGridLayout and grid view layout inside new ADF Faces Deck component:

Data item selection is handled automatically by ADF Faces List selection listener - row key is set and preserved in Data Control, this allows to reuse the same selected row in different fragments (for example - edit fragment):

I'm using helper Java Script method from WorkBetter application, this allows to trigger navigation from Java Script level. Server listener invokes custom method from the bean, where it is using hidden button to initiate navigation in the ADF task flow from one fragment to another:

Here is this hidden button, used to initiate navigation between fragments:

Navigation is defined in the ADF task flow - between view and edit fragments:

Managed bean is using helper method from WorkBetter class to initiate navigation through hidden button:

According to Alta UI guidelines, toolbar with Save/Cancel buttons must be placed into top right corner (it should not be in the bottom of the page anymore):

Sample application implements a special logic, to keep the current row, after Rollback functionality was invoked. Couple of methods are overriden in the ADF BC VO implementation class (you must set ClearCacheAfterRollback=false option in the AM):