Sunday, March 12, 2017

Improved Display for Empty Field Values in ADF Form

I had a task in the project, to improve display for empty field in ADF form. By default, if there is no row data in the result - all input text entries in ADF form will be hidden, user will see only labels. This is not ideal, most of time users would prefer to see disabled input text boxes instead.

In this example below, on purpose I search for non existing value and this causing form below to become empty. First Name field shows example with disabled text box, the way we want it to be displayed. All other fields display only label - default way:


Let's see how First Name field is changed to be rendered as disabled, when there is no data. I have changed EL for value property. Instead of pointing directly to the binding inputValue (when expression points to standard inputValue and when there is no data - field is rendered as read-only), I point to proxy method in my custom bean. Method is generic and it accepts field name as variable:


Disabled property is changed to return true, when primary key value is empty - this would happen when there are no rows in the result:


No need to change any other properties.

Proxy method is implemented in the bean. This implementation allows to pass parameter to the getter. Parameter - attribute name. Using parameter we are reading value from the bindings. If value is empty - NULL is returned, this makes field empty, but not read-only. When user is changing value - we need to update binding - this is done in put method. Here we get two values from EL - attribute name and actual new value. Think about it as about HashMap element:


With this generic method, there is no need to define separate getters/setters for each UI field. You only need to provide attribute name in EL expression:


Now form is displayed with empty disabled boxes, when there is no result:


When results are available - from displays and allows to edit data:


Download sample application - ADFDataEntryUIApp.zip.

Tuesday, March 7, 2017

Oracle Java Cloud - How to Create Access Rule for Managed Server

When you get fresh instance of Oracle Java Cloud, you are assigned with one admin and one managed server. If there is requirement to host multiple environments - demo, production, etc. - one managed server is not enough. Is better to run different environments on dedicated managed servers, this would simplify maintenance. WebLogic 12.2.1.2 partitions are not supported yet for Fusion Middleware, so only choice we have right now - different managed servers per environment.

In this short post, I will describe how to enable access to newly created managed server in Oracle Java Cloud. I have created RedSamuraiProd managed server with port 9075 in our Oracle Java Cloud service instance:


To allow access to port 9075, I need to define new access rule. This can be done through Cloud instance control, select Access Rules from the menu:


In Access Rules section, create new rule. Import here is to specify PUBLIc-INTERNET for source, WLS_MANAGED_SERVER for destination and port for managed server:


Once rule is created, managed server starts to be accessible from the internet. So simple and it works!

Wednesday, March 1, 2017

Oracle Java Cloud Upgrade to 12.2.1.2

We finished upgrade of our production Oracle Java Cloud instance to 12.2.1.2. This allows us to use new ADF BC REST features (16.5.2 What You May Need to Know About Versioning the ADF REST Framework).

Upgrade to newer version in Oracle Cloud is similar to on-premise upgrade. We need to create new service instance for software release 12.2.1.2 and later re-deploy our app, re-configure data source and setup security mappings:


12.2.1.2 instance is created in same way as it was before:


Instance is created in three simple steps, last step is just to review configuration:


Give it some 10 minutes to initialize:


And 12.2.1.2 environment is initialized - very simple and much more easier than to configure it by yourself on premise:


We can verify in Cloud EM - JRF 12.2.1.2 is installed, this means it includes full ADF 12.2.1.2 support:

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 - GroovyADFApp_v3.zip.

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 - GroovyADFApp_v2.zip.

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 - GroovyADFApp.zip, 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.