Oracle JET Slider in Foreach Loop

While working in the project last week, I had a question from development team - how to render multiple Oracle JET Slider components in foreach loop. I thought this could be useful tip for other developers too.

You can get JET sample app from GitHub - JETSliderSample.

Take a look into dashboard.js, I have defined array with two elements, containing variables (value property variable must be observable, otherwise it will not receive changed data) required to initialize JET slider. Each array element, defines slider to be rendered in HTML. There is JS function which prints array content, it can be useful to access changed slider values:

HTML implementation contains foreach loop pointing to array from JS module. Each loop element prints JET slider. JET slider properties must be mapped with variables from array elements, otherwise slider would not function (if you are using it inside foreach loop):

This is how UI looks like. Multiple slider components are displayed through foreach loop. User can adjust slider values and print new values in JS function (hitting Submit button):

Oracle JET Tooling Migration from 2.2.0 to 3.0.0

Oracle JET 3.0.0 was released this week and I decided to migrate my local JET tooling from 2.2.0 to 3.0.0. Oracle JET developer guide provides well documented instructions for migration - B Oracle JET v2.x.x to v3.0.0 Tooling Migration. I was following outlined steps and tooling migration was smooth.

Migration from 2.2.0 to 2.3.0

Clean cache for bower and npm:

Install JET 2.3.0:

Migration from 2.3.0 to 3.0.0

Install JET 3.0.0:

Thats it - in three simple steps tooling was upgraded to 3.0.0.

Now we can create JET 3.0.0 app with Yeoman (follow instructions list in JET Getting Started guide):

I prefer to use NetBeans for JET application development. I already had a post about how to open JET application generated in Yeoman for development in NetBeans - JET Application - Generate with Yeoman - Debug in NetBeans. Let me go through this once again. NetBeans provides handy option to open HTML5/JS with existing sources:

We need to point to source folder, project directory and site root:

Make sure to point start file to index.html, NetBeans will ask this info when you try to run app for the first time:

To be able to run JET 3.0.0 application generated with Yeoman in NetBeans, you would need to copy two folders (create another app directly in NetBeans and copy from there):

1. Copy folder js/libs:

2. Copy folder css/libs:

Later when you build minified version of your app, css/libs folder can be removed:

JET 3.0.0 sample app is running:

In my next post I will explain how migrate existing JET 2.2.0 app to JET 3.0.0.

Red Samurai and Oracle PaaS JCS Success - JET/ADF BC REST Cloud Production Application

I would like to share our success in Oracle PaaS service - Java Cloud (JCS). We have managed to implement JET/ADF BC REST system in short period of time and deploy it in production running on Oracle JCS. UI is implemented entirely with JET, while back-end REST services are running on top of ADF BC. Secure access is controlled by unique ID managed by server side ADF Security.

Production application implements custom invoice processing logic for startup candy factory/distributor in Lithuania. Oracle Cloud doesn't require administration and provides all mandatory services to run custom application. This is primary reason why decision was made to use Oracle Cloud. In the next phase we are going to implement warehouse management logic, tightly integrated with invoice processing.

JET UI

Home screen displays dashboard with financial data for orders, customers and invoice items:

Menu structure (JET Router) is focused around implemented business logic:

1. Dashboard - statistical data display
2. New Invoice - invoice creation module
3. Template Setup - invoice template setup, to speed up invoice creation
4. Invoice Search - search through all invoices
5. Customer Setup - customer data management
6. Supplier Setup - supplier data management

Invoice Search screen implements form block and results table with pagination. This screen is using a set of JET components, starting from input list to responsive UI:

User have option to select invoice for editing. Various invoice fields can be changed in this screen. UI remains responsive and can be rendered on mobile device or JET Hybrid application - this was one of the key requirements:

Invoice items are edited in JET dialog. This is very convenient approach, JET dialog works really fast and allows to switch from one item to another in a quick way:

Development process - Oracle Developer Cloud Service

Application was developed using Oracle Developer Cloud Service. We think Agile boards/sprints defined in DevCS are really helpful. Offered functionality simplifies task management/monitoring process and you can see the progress in the sprint:

DevCS provides Git source control repository, agile board and issue tracking. It also gives you Build Automation. We were using Build Automation to re-build changes committed in ADF BC REST repository:

After build process completes - there is a an option to redeploy latest EAR package directly to JCS. This helps to save time, no need to repeat redeployment routine steps yourself each time when new build completes:

Application Structure

Application is divided into two parts (two separate deployments): ADF BC REST and JET UI implementation.

ADF BC REST implements back-end REST services and provides authentication/authorisation control. We are using regular ADF BC development, together with REST interface provided out of the box starting from ADF 12.2.1:

JET UI application is following modular architecture approach. Each use case is implemented in separate module. Common logic (REST service definition, etc.) is moved out into controller modules. Client side business logic is implemented in JET module JavaScript functions and rendered with JET UI components:

Oracle Cloud Deployment

We are using Oracle Java Cloud Service instance to run both ADF BC REST app and JET. ADF can't be deployed to Oracle Application Container Cloud service, but you can host JET from Java Cloud. For this reason it was more sense for us to use only Java Cloud and run both server side and host client side from the same instance.

Both demo and prod environments run from the same Cloud instance, targeted to different Managed Servers (to simplify maintenance):

If we take a look into application runtime statistics, ADF BC REST application mainly executes ADF REST servlet (to produce REST request response), our custom PDF servlet and ADF authentication servlet to execute session logout:

JET wrapper application doesn't run any server side logic, it simply return JET application content to the client - only File Servlet is invoked in operation:

Performance

JET runs on client side, there are much less server side calls comparing to ADF Faces application. In this example we change invoice status to Submitted. In result several REST calls are executed, each running below 100 ms. and transferring just a bit of info. Key difference between JET and ADF Faces - REST call doesnt block client functionality. REST call may execute asynchronously and user can continue to work with the application:

In the example below, we navigate to invoice list screen. Invoice MAR-36 status was changed to submitted, invoice line data is re-fetched to display up-to date information in the table for particular row. Invoice row data is re-fetched below 100 ms.:

Let's check navigation in the table. We navigate to the last page. REST request is completed in around 100 ms., and it returns only a set of rows for the last page:

When user log's our from JET application, we execute request for adfAuthentication servlet with parameter logout=true. This allows to close ADF BC REST session on the server side:

Summary

1. JET UI and ADF BC REST server side can be used in production system

2. JET UI and ADF BC REST runs great on Oracle Java Cloud

3. Oracle Developer Cloud Service is useful for JET and ADF development

Significant Improvement for WebLogic Start-Up Time on macOS Sierra

I have faced really slow WebLogic start-up times after upgrade to recent versions of macOS Sierra. It turns out to be common problem related to JVM start-up on macOS systems, nothing to do with WebLogic itself. Solution is to register mapping between 127.0.0.1 and your computer name in hosts file, read more on Stack Overflow - Jvm takes a long time to resolve ip-address for localhost. This issue seems to appear with newer JVMs.

Originally WebLogic was starting up in 157 seconds:

After config was applied in hosts file, start-up time improved a lot, it is 24 seconds now:

Changes in hosts file - 127.0.0.1 was mapped with my computer name, along with localhost. Same applies for ::1 mapping:

You can get computer name in System Preferences -> Sharing:

Hope this hint will be useful for those developers, who are working on macOS.

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.

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!

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: