ADF: af:tree custom context menu using selected row values

When you right click on a tree node you can see a context menu with some options like expand or collapse a node or all nodes. You can also add a custom options easily by using contextMenu facet. I am going to show you how to add a custom context menu and use selected node values in the options label.
You can download this example from my Github repository.
To create the tree structure that we will use in this example we are going to use Employees table of hr schema.
We should have this structure in the data model.
After we have our views added to the application module, we have to drag and drop EmployeesView1 from the datacontrol palette.
The next step is to add the children in the tree binding so we click on the add green button and select ‘EmployeeView’.
We are only going to use one attribute, but you can add as many as you want.
After clicking ‘Ok’ in the dialog we can add a custom contextmenu by adding a component structure like this:

If you run the application you can see ‘MenuOption 1’ in the context menu.
Now that we have our custom option in the context menu, We can try to add #{node.FirstName} in the text property os the commandMenuItem.

As you can see the new option is still in the context menu, but no name is displayed.

To achieve this we have to use a setPropertyListener with a popupFetch to store the value that we want to show in a variable.
This variable has to be at least in viewScope.
contentDelivery property of the popup has to be set to ‘lazyUncached’.

If you run the application again you can see that the option now displays the name of the selected node properly.


Update 25/09/2015; 

There is a issue while trying to open the contextual menu clicking one node while you have already have a contextual menu opened. Some times it will not open.

It can be fixed by adding contextMenuSelect=”false” in your af:tree

Oracle Mobile Cloud Service: Create an API that calls a REST web service

In the lasts post about Oracle Mobile Cloud Platform I already told that you can connect to a external SOAP/REST web service, but you have to do it through a connector. We have also to keep in mind that with REST API or Android/iOS SDK you cannot call directly a connector, you have to call a custom API that will make the call to that connector so we will also have to make a implementation of out custom API using node.js.
You can download this example from my Github repository.

In this post I am going to show with a quick example  how easy is to create an API that makes a call to an external REST web service.

The steps we are going to do are:

  1. Create a Mobile Backend (MBE)
  2. Create a Connector
  3. Create, design and implement an API.

Create a Mobile Backend (MBE)

A Mobile Backend is the gateway through we will make any API (custom or platform) call, so the first step is to create one.
In the Developer Portal we have to make click on Mobile Backend and in the next page we have to click on “New Mobile backend” and fill the required fields like name and description.

Create a connector
A connector will let us to make a external webservice call from MCS, so in the Developer Portal we have to navigate to Connectors.
In connectors page we have to click on “New Connector”, as type we pick REST and then we fill the name and the web service url.

In this example I have picked a public rest weather API:

api.openweathermap.org/data/2.5/weather?q=Madrid

Once we have created the connector we can skip until the last step, “Test” and just click on “Test Connector” to test our connector.

As you can see the web services give us weather data of Madrid as we put ‘Madrid’ in the url parameter.

Now we have connected MCS with a external web service, but as you can imagine we should make our connector parameterized so we don’t have to create a connector per city.

we have to make a couple of things to get it working:

First we have to edit the connector url and remove “?q=Madrid” from it.

And we have also to add a rule to our connector. To do this we have to go to rules step in our connector and click on add new rule.
In this case we are going to add a new parameter that will be associated to all the calls that we will make to this connector.
It is possible to associate a rule to a specific resource or a certain HTTP methods.

Now we are going to test that our connector works with the parameter.
We have to navigate to ‘Test’ and fill the input next to ‘Local URI’ with ‘?q=Barcelona’.
If we don’t fill the input the connector would use the default value we set in the rule.

As you can see the call has been successfuly made and the connector gives us the weather of Barcelona.

Create, design and implement an API

In the last step we are going to create an API that will call the connector.
Inside our MBE we have to create a new API.

We have to fill the name of the API and click on ‘Create’

Now that we have created the API, we have to design it.
In order to call the API anonymously so we can avoid creating any users or roles we have to head to Security and select ‘Allow Anonymous User Access’.

The next thing we have to do is define the endpoint of our API.
Our endpoint is going to have a parameter that we will define as {ciudad}. We have also to define endpoint methods.

In this case we are going to create a GET method so we have to click on ‘Add method’ button and select ‘GET’. At this point we can define the diferent responses that we want and add mock data so our mobile application developer can start building the app. 

As we are not going to use any static data and we are going to make a call to the connector we are not going to add any response.

Now we click on ‘Save’ and then head to ‘Implementation’.
Here we can implement our API logic using node.js by downloading a JavaScript Scaffold.

The JavaScript Scaffold is a zip file that contains:
  • package.json: This is a config file where we can add the API dependencies.
  • tiempoporciudad.js: This is the javascript file where we will add the logic to our API. The name is the same as the API in MCS.
  • samples.txt:  This file contains some implementation examples.
To start the implementation we have to add the connector as a depencency to our API. So we have to edit package.json and add the connector URI and connector version.
After that we will edit the lavascript file tiempoporciudad.js.
The point here is to get the parameter (ciudad) of the request and execute a GET call to the connector passing the value we get as parameter. The last thing is to include the response of the connector’s call in the API response,

Once we have our API implemented we have to put both files inside the zip that we downloaded and upload it to MCS.

At this point we have created the Mobile backend, we have connected to a external web service using a connector and we have created an API associated to the Mobile backend that makes a call to the connector.

The last step is to test our API to see if everything works fine.
We have to head to our API and click on ‘Test’ button and fill the name of the city. We will use Barcelona again to test.

If we click on ‘Test Endpoint we can see that the API returns the weather of Barcelona.

ADF: Add a calendar selector to inputText

There was a requirement posted in JDeveloper & ADF forums to add a calendar selector to a inputText so any text could be inserted and also a date could be selected. I am going to show you the solution I gave (Link)
You can download this example from my Github repository.

We need a inputText and a inputDate.

Next step is to set inputDate value to the inputText.

To achieve this, we have to use autoSubmit true in the inputDate and set the new value to the inputText in the valueChangeListener. We also have to set a partialTrigger so our inputText is automatically refreshed as son as the value in the inputDate is submitted.

This is the valueChangeListener that we are going to use.

In this method we have also to create a Date object and format it becasuse we would find in the inputText something like this:

Tue Jul 07 00:00:00 CEST 2015
findComponentInRoot method can be found in JSFUtils class.

At this point we already have the value in both components.

The last step is to beautify our component becasue we dot want to neither labels nor inputDate content box.
We have to add a panelLabelAndMessage surrounding both components and use simple property to hide both labels.
We have also to make add a style class to inputDate components as we don’t want to edit all inputDates style.

The last step is to make some skining so we can hide content box of the inputDate using the style class we added to the component.
If we run the application we can see our new “component” working.

Oracle Fusion Middleware Summer Camps 2015: Mobile Cloud Service

Last week I had the opportunity to attend to Oracle Fusion Middleware Summer Camps in Lisbon that Oracle organizes for EMEA partners. This year was the fifth edition and there were many new Oracle PaaS products to choose: Integration Cloud Service, Process Cloud Service, Java Cloud Service and the one I attended, Mobile Cloud Service. 

I have to say that it was the very first in class MCS training.

Oracle Mobile Cloud Service course was delivered by Frank NimphiusGrant Ronald (Oracle Product Management Team) and Jürgen Menge (Oracle Sales Consultant).

From the first minute we could start playing with MCS and also try the functionallity with a MAF application.

If you want to know MCS functionality you can check my previous post: Oracle Mobile Cloud Service overview.


Having such great trainers, we learnt some advices, good practices and tricks when using MCS. We saw a lot of interesting things, here comes some of them:

  • Notifications

MCS offers an API that allow us to abstract of the providers and fully manages notifications.
We can also send notifications to users in a specific role or platform, schedule notifications and monitor to see if notifications have been sent.

  • Cache and offline 

Thanks to the API we have a cache in the client that allow us to manage the synchronization with policies and also working in offline mode. We can get better performance, better usability, decrease network usage and increase battery life.

  • REST API y SDKs

With REST API and the SDKs we can call MCS Platform API and the custom API that we will create to integrate our applications with external systems. In future releases a JavaScript API will be available.

  • Analytics

Besides having metrics of all the API calls that our application make, we can also create our own events and funnels. We can use these, for example, in our mobile shopping application to know the step where users leave, evaluate the process and improve it.

 I would like to thanks Jürgen Kress for the great organization of the event and all the trainers for the outstanding tranning. See you next summer camp!!

Oracle Mobile Cloud Service overview

Thanks to Oracle Weblogic Oracle Weblogic Community I had the opportunity to use a Oracle Mobile Cloud Service GSE instance a couple of weeks ago. In this post I am going to show you the different parts of this PaaS product that is part of Oracle Mobile Platform.

In my opinion it is a powerful easy to use tool that help us to simplify and unify all business integration with web services, notifications and storage as well as providing metrics to measure the health and performance of the APIs that our mobile applications consume.

There are 3 main options in Mobile Cloud Service:

  • Developer portal
  • Administration: We can see the 3 environments that MCS provides, the logs, etc.
  • Analytics: We can see default metrics and also track our custom events.

 Let’s focus on the developer portal where we find the following options:

  • Mobile Backend

A Mobile Backend (MBE) is the gateway to Mobile Cloud Service. If we want to access any available resource from MCS, for example an API, we have to do it though an MBE. It is a group of all the resources that we can create in MCS. In the main page we can create or edit a MBE and we can also see some metrics about the health, the number of requests and the average response time.


If we select a MBE we can see the diferent actions like diagnostics, general settings of the MBE, create or select an API or configure notifications.

  • APIs

An API is just a REST web service that we will expose through an MBE. In MCS you use REST to consume as it provides better performance for mobile applications.

We can import a RAML file or design our API with the tool. While defining the design of the API we can create the endpoints, add security, etc.

We can also create our API implementation using node.js and test our API with mock data.
It is possible to export out API design to a RAML file and our implementation as a zip file.

  • Connectors
At the moment connectors allow us to integrate an existing REST or SOAP web service in MCS.

  • Storage

We can add the documents such us pictures, pdf documents or videos to MCS in shared o isolated mode that our applications will use.

 

  • User Management
Last but not least we have user and roles management.

Thanks to the REST API and 2 SDK, for  Android and iOS that Mobile Cloud Service also includes we can easily integrate our hybrid or native applications. In the future MCS will include also a JavaScript API.

Although in the application there are some tutorials to learn how to use the tool, Oracle product Management Team has available some  youtube videos so everyone can learn in depth what is Oracle Mobile Cloud Service and how to use it.

In the next posts about Oracle Mobile Cloud Service I will show you a simple integration with a external REST web service and a review of the Oracle Fusion Middleware Summer Camps (17-21 August 2015)