Monday, February 27, 2017

Simple Way to Export Your Data from Oracle Cloud

You should not get stuck in the Cloud. There are various options to create Oracle Cloud backup, but is very important to keep a local copy of your data. One of the simplest options to create a local copy of data from the Oracle Cloud - use Oracle SQL Developer.

Define Oracle Cloud DB connection in SQL Developer (the same as regular DB connection):

Use Database Export utility from Oracle SQL Developer:

Allows to export schema DDL, together with data (various formats, SQL INSERT statements one of them):

You can choose from long list of DB objects to export, this includes indexes, triggers, constraints, tables, etc.:

In my use case I select all objects to export (except PS_TXN):

There is option to filter exported data, again I will export all data:

Schema structure along with data is exported successfully:

Friday, February 17, 2017

ADF Editable Table - Recommendation For Data Entry Optimization

I will explain data entry use case related to ADF table. Specifically I will talk about a bit more complex case, when some columns in the table are set with AutoSubmit=true, to force values to be submitted to the server on change. This can be required when validation rule must be processed on value change or there are dependent re-calculated fields in the same row.

If you are using AutoSubmit=true columns in ADF table, it is easy to start loosing values from columns with AutoSubmit=false. Really? Yes - only, if table iterator is set with ChangeEventPolicy=ppr.

Let's do an experiment. First Name column field is set with AutoSubmit=true:

Iterator is set with ChangeEventPolicy = ppr:

Enter value for Last Name, field with AutoSubmit=false:

Change value for First Name, field with AutoSubmit=true and tab away:

Previously entered value for Last Name will be lost and focus will move to table header. Two bad things happened at once. First Name is set with AutoSubmit=true, this means it send value from this field in PPR request, and since table iterator is set with ChangeEventPolicy=ppr, in response it is refreshing table with data from the server. Obviously Last Name new value wasn't sent to server yet (AutoSubmit=false) and ChangeEventPolicy=ppr is reloading values on the client with whatever values are on the server. Technically this is not a bug, but is a critical bug from user perspective - loosing data.

If you have AutoSubmit=true columns in the table, make sure to set ChangeEventPolicy=none for iterator:

This time after changing value with AutoSubmit=true - other field values stay on the client and focus moves nicely to the next field:

When data is saved - changed from both fields are submitted to the DB:

Download sample application -

Tuesday, February 7, 2017

Setting Invalid Fields for the UI in ADF BC Groovy

What if you have entity level validation rule and want to attach validation error message to specific field. By default this is not possible - all entity level validation error messages are displayed in the popup and are not attached to the fields (differently than attribute level validation rule messages).

Apparently there is a way to achieve such requirement with Groovy expression, this can be executed from entity level validation - adf.error.addAttribute('Salary'). In addAttribute you need to provide attribute name which will be assigned with the error. Complete expression for entity validator:

Result displayed on UI - validation error message is assigned to the field, which was changed:

Download sample application -

Friday, February 3, 2017

ADF 12c New Groovy API to Work with View Object Methods

I have interesting topic to share - new Groovy API in ADF to work with View Object, apply View Criteria, execute it. I have discovered it while experimenting with new features and functionality in ADF 12c. Starting from ADF 12.2.1, we have an option to code Groovy in separate file with extension .bcs - ADF BC Groovy Improvements in ADF 12.2.1. This makes sense especially with this new Groovy API - it is more convenient to code/maintain more complex Groovy logic in separate file. As Oracle docs say - Groovy runs faster when it is coded in separate .bcs file, probably there is no need to parse XML to extract and execute expression.

Sample application -, contains Groovy implementation for Employees EO:

There is validation rule for Salary attribute coded in Groovy:

Let's take a look into Groovy method, we can open it in .bcs file - for more convenient to review/edit:

1. Method newView gets instance of Jobs VO, within Employees EO context. To get instance of VO with newView, it needs to be defined for programmatic access. This can be done in Model.jpx file, Groovy section.

2. Method copyNamedViewCriteria returns instance of predefined View Criteria. You need to set property ExtAllowUntrustedScriptAccess=true for View Criteria to be accessible in Groovy:

3. Method setViewVariable allows to set value for bind variable from VO. As a rule, bind variable must be assigned with ExtAllowUntrustedScriptAccess=true to be accessible in Groovy.

Let's see how it works on runtime. First it gets VO instance, applies bind variable value and then executes VO. Based on predefined logic, if row is returned - validation is successful:

When validation fails - message is returned:

This Groovy API can be useful when you need to access VO and execute logic directly from Groovy script, without coding Java method.

Sunday, January 29, 2017

Contextual Event API Improvements in ADF 12.2.1.x

ADF 12.2.1.x brings improved API support for Contextual Event implementation - this should simplify Contextual Event usage. Now Contextual Events can be produced without referencing ActionEvent or SelectionEvent, also there is no need to define Data Control to implement Contextual Event handler. Read more in ADF 12.2.1.x documentation - 46.4 Creating Contextual Events Using Managed Beans. I will provide example and explanation how to use these improvements.

Download sample application - This sample is based on two isolated ADF regions - table and chart. When row is changed in the table, through table selection listener method I generate Contextual Event with Job Id payload and send it over, event is consumed in chart region and it allows to refresh chart by key:

Row is changed in the table - new Contextual Event is produced and consumed - chart is refreshed:

We should check in the log - it prints what happens from event initialization to consumption. This gives useful info to debug Contextual Event flow:

Let's jump into code of event producer - method for table row selection (JSFUtils helper method allows to execute table row selection event programmatically, just before producing Contextual Event, this allows to access information about current row). Event is constructed without any event definition in the bindings, directly using method action and event dispatcher API - we can pass payload information directly - no need to describe it in the definition (this is advantage, as sometimes payload definition expression could execute too late and payload could be empty):

Method action definition doesn't represent any real method, it contains event name and acts as helper for event producer:

Consumer region contains Contextual Event handler mapping - it specifies event name and handler info (this is same as before). There is no need to define handler through data control anymore. Method action points directly to the bean method, through instance name. Payload value is sent through using paramVal name and ${data.payLoad} expression:

Consumer receives payload and re-executes VO:

Sunday, January 22, 2017

SQL Bind Variable Support in ADF BC REST

Is not that obvious from Oracle ADF BC REST developer guide how to provide value for bind variable defined directly in the View Object SQL statement. I did research around this and would like to post few hints to make your life easier, if you have same requirement - pass values from REST request to View Object required bind variables. This topic is especially useful, when you want to reuse existing ADF BC implementation for ADF BC REST access.

We are going to use View Object Row Finder. Oracle ADF BC REST developer guide explains how to use Row Finder with View Criteria. In our case we have different situation -  we would like to use Row Finder for required bind variables, referenced directly in SQL statement.

You can't define Row Finder without View Criteria. First trick is to define empty View Criteria, just to be able to define Row Finder - we are not going to use View Criteria functionality, our bind variables are referenced directly in SQL WHERE clause:

Once Row Finder is defined, you are going to see bind variables listed. Keep in mind - this doesn't means bind variables are referenced by Row Finder, they are just listed for possible use. Now main trick - go and define some dummy expression for each bind variable you want to use in REST request (make sure to uncheck - Save expression to groovy file):

This action would generate Groovy expression for each bind variable and list these bind variables under Row Finder. Go to source of View Object to see the structure:

Now remove Groovy expressions assigned to each bind variable - we don't need them, keep only bind variable names assigned to Row Finder:

Visually in the wizard is going to look like there are no changes made - but we keep bind variables under Row Finder tag now:

Bind variables are included directly into SQL statement WHERE clause:

ADF BC REST service is defined in regular way, no special tips here:

This is how REST call looks like: Departments?finder=RESTFilter;depNameVar=IT.locIdVar=1700. We include Row Finder name and two bind variables with values:

In the background we could check ADF BC log, where it prints SQL statement with both bind variables assigned with values:

Download and browse sample application ADFBCRestApp from my GitHub repository - jetcrud.

Wednesday, January 18, 2017

Multi Language Support in Oracle JET

There is great post from Geertjan Wielenga about Translating Oracle JET Applications. If you want to introduce multi language support into JET app - this is great place to start reading from. We are building production Oracle Cloud app with ADF BC REST and JET. This app requires multi language support - English and Lithuanian. I will describe below how we integrated multi language into various areas in the app.

Download or browse through sample application in GitHub repo - JETPlaygroundApp.

In JET we could set default language in index page html root tag. By default it is set to en-US, but it can be set to lt-LT for Lithuanian language or any other language:

Translation texts are located in message bundles. There is one default message bundle for English and translations are located in sub folders. English bundle:

Lithuanian bundle with translations for the same message keys:

Multi language bundle support must be registered in main.js (bundle file name can be anything):

Values for all labels/texts must be defined as observables and initialised from JET translation API by passing message key - this will bring default text:

When language is changed, we need to update observable values and reset language value in HTML tag. I'm changing menu labels as well by re-configuring JET router:

On UI in index.html message key is referenced directly from observable variable:

We can access message key defined in appController from individual JET module UI through $parent. For example, I'm using dueDate message key in incidents module:

Same message key is reused in another module - customers:

This is how language switch looks on UI - language change is available in preferences:

When we switch to Lithuanian language - texts are changed (the ones assigned with translatable messages):

Menu labels are also changes, JET Router is reset:

Labels are change in built-in JET components - such as date. Though is not translated completely for Lithuanian language (Today text remains in English):