ADF Regions and Shared Data Control Bindings Use Case

While teaching ADF trainings and talking to ADF developers, often I can see people think about ADF bindings as about some mistery and try to avoid using full potential of ADF Data Control. I would like to give simple, but practical example in this post, which describes how to use ADF bindings and access these bindings across different ADF regions.

This diagram shows how sample application (BindingAccessApp.zip) is implemented:

There are two regions (task flows), both are configured with Shared Data Control (means they will share same AM instance). Employees region could change current row. From Jobs region we can access bindings updated in Employees (Email attribute in this case).

Two regions are rendered side by side. I can move to different row in Employees and press button Set Current. This will set displayed row as current:

Current row in Employees region is set through custom method:

Button in Jobs region - Show Employee displays Email value from Employees region. Such functionality can be important, when you need to implement data exchange functionality between regions. Simply rely on ADF bindings in Shared Data Control - this would work:

Main page contains both regions:

Email field value is set in Employees region, through ADF bindings:

Binding attribute for Email is defined in Page Definition and attached to Data Control:

Make sure TF is set to default Shared transaction, otherwise changes in the ADF bindings values will not be visible outside of current task flow/region:

Email attribute is referenced through the binding in Jobs region:

You must include Email attribute binding into Jobs region page definition. Its value will be automatically set to the one from Employees region:

Hopefully this will explain how powerful ADF bindings are.

Oracle JET Example - Implementing Editable Collection Table

Oracle JET allows to implement inline editable tables. User can double click row or press Enter to switch to edit mode. Use Esc to switch back to readonly mode. With F2 can toggle between editable and readonly. Check it yourself in JET cookbook Editable Collection Table to see how it works.

I have followed instructions from the cookbook and implemented editable JET table on top of ADF BC REST service. Row with key 201 is switched to edit mode:

When we exit edit mode, event is handled in JavaScript and changed row is printed to the log. Here we can collect all changed rows into array and submit to the server all at once or we can fire individual REST calls per each changed row - depends on implementation:

To handle row edit, table must be set with editMode: 'rowEdit' property:

Row template property must be defined to render different HTML elements in readonly and editable modes. This property can be initialized dinamically with different template name retrieved from function:

Based on row edit mode, function returns template name:

Readonly template renders output texts, editable template renders input texts:

Changed row data is logged by ojbeforeroweditend listener function:

Download sample application - JETEditableTableApp.zip.

JDeveloper 12.2.1.1 Bug and Workaround - Wrong Instance Name for Method Action Binding

After upgrade to JDeveloper 12.2.1.1 I have noticed issue related to Method Action binding instance name. This is not ADF 12.2.1.1 bug, but JDeveloper bug. JDeveloper sets incorrect name for Method Action binding instance name.

If you are going to create custom method in VO/AM and expose it through interface to be called in bindings layer - there will be similar error as below on runtime:

Source of this error is in the method binding definition:

Go to page definition source view and you will find instance name highlighted with warning. JDeveloper is able to recognize invalid expression, but still it generates it. ADF 12.2.1.1 runtime quality is improved, but can't say the same about JDeveloper IDE. Oracle focus is on Cloud, but still there is a lot to do to improve development tools quality:

Expression must be replaced manually to correct one (the one previous JDeveloper version used to generate) - data.DataControlName.VOInstanceName:

With correct expression for instance name, custom method is invoked correctly without error:

Download sample application - ADFOperationBindingApp.zip.

Oracle JET and ADF BC REST Security Integration Approach

I have promised to atendee of my OOW'16 session (Building Enterprise-Grade Mobile Apps with Oracle JET and Cordova [CON5731]) to post a blog about ADF BC REST security and integration with Oracle JET. This post is to demonstrate how we could reuse cookie ID generated by ADF BC REST Web session for REST requests from JET.

First thing first, here you can download source code - jet_adfbc_security.zip. This archive contains ADF BC REST application and JET source code (you need to copy it into your local JET application).

Take a look first into JET login form. This is where we collect username/password and call login function. One important detail - invalidComponentTracker, this allows to report required validation error, when user hits login button with empty username or password:

Here is the login function in JET. If there are no validation errors, it executes POST against ADF BC REST service custom method. In response we could return user info, preferences, etc. This is the only one request where we are using username/password. Key point of this request is to get JSESSIONID from ADF BC REST server, so we could use it for subsequent requests, without sending username/password again. This is similar concept to ADF Faces, it is also using JSESSIONID to track web user and HTTP session on the server. If login is successful, we are reading custom parameter from response with JSESSIONID value. JET router is updated to render different menu structure after login:

Custom response parameter is populated on the server in Filter class. On authentication request this parameter is set once:

ADF BC REST application is enabled with standard ADF Security:

This is how it works. Login form in JET:

Login is successful with redsam/welcome1 user. Two tabs are rendered - Home and People. Home tab displays chart with employees:

We should dive deeper and check what happens with REST communication. POST method in response gets custom parameter with JSESSIONID value, if authentication is successful based on Authorization header parameter:

Chart data in Home tab is retrieved through GET method and this method is not using Authorization header anymore. It calls REST method using JSESSIONID in URL. JESSIONID must be before URL parameters:

Home tab is implemented with JET chart component:

JSESSIONID is included into REST call URL through getURL method, which is referenced by JET collection:

People tab implements table with pagination support:

Same approach is applied in People tab. JSESSIONID is appended into URL through getURL method, before URL parameters:

People UI with paginated table in JET:

REST request URL contains JSESSIONID: