The first part of this blog covered aspects that are important for developers to understand in order to build bespoke mobile applications that expose functionality empowered by Oracle eBusiness Suite (EBS). This blog builds on the information provided in Part I and deals with some of the implementation details



Implementation details




The content of this post primarily deals with details around the following components


  • Oracle Mobile Cloud Service: mobile backend, custom API and connector configuration
  • Oracle Integration Cloud Service: DB adapter, REST connection, mapping, agent configuration etc.


Please note that, for the ICS related aspects of the solution, a lot of technical details have been explained already in other blogs, thanks to the Oracle A-team



Therefore, this blog will not repeat those details but briefly touch base on the ICS part in order to capture comprehensive details of the solution.


Create Mobile Backend in Oracle MCS


The first and foremost step is to create a Mobile Backend for our integration. It serves as a way to group APIs and other resources for a set of mobile apps. A mobile application can only access MCS APIs in the context of a mobile back-end. By and large, a mobile back-end encapsulates the following


  • Connectivity information
  • Security related configuration: HTTP Basic, OAuth, Enterprise SSO etc.
  • Security Realm configuration
  • Mobile Application registration information and more..




                                                                 MCS Mobile Backend



For a step-by-step guide on how to work with Mobile Backend, please refer to the following section from the official product documentation


Custom API Design


Next, we will design the interface/contract of the API which will be exposed to the mobile clients. This will involve creation of the necessary REST endpoints along with the actions (HTTP verbs like GET, POST etc.) and required parameters (query, path etc.)




The above diagram depicts two endpoints – one which deals with risk orders and the other deals with unpaid invoices




This figure above lists the details of the GET operation on the riskOrders endpoint – it consists of a set of mandatory query parameters which need to be passed along with the HTTP GET request. Oracle MCS gives you the capability to design your Custom APIs from scratch using its declarative UI interface. For a deep dive of this process, please refer ‘Creating a Complete Custom API’ section from the product documentation


Data Integration


The following sequences of diagrams provide an overview of the stored procedures which contain the business logic to work with data in EBS


















Test the stored procedure as follows




You should get results like these




The below set of screens showcase the ICS EBS DB adapter configuration which includes both ICS agent and EBS connectivity configurations


ICS Agent Group





The following section from the product documentation covers the ICS Agent installation process


ICS DB Adapter







ICS (inbound) REST Endpoint


The ICS REST endpoint is a gateway for external callers (e.g. Oracle MCS REST Connector API) to invoke business logic associated with EBS integration. The following screens depict the associated configuration




























Once the REST endpoint configuration is complete, one can test the associated operations. Here is an example of GET operation which fetches sales orders from EBS for a specific customer e.g. Technologies








Oracle MCS: Connector API Configuration


The REST Connector API in MCS acts as a client for the inbound ICS REST endpoint (whose configuration was outlined above). The Connector API greatly aids in declarative security and testing.





The Remote URL highlighted in the above figure is the URL of the ICS REST endpoint. For details on Connector API configuration in MCS, please refer their respective sections in the product documentation – REST, ICS, SOAP


Oracle MCS: Custom API Implementation


The custom API implementation


  • Uses custom Node.js code to implement the contract/interface sketched out initially
  • It internally calls the MCS REST Connector APIs (for ICS)





This snippet demonstrates a HTTP GET operation on the riskOrders endpoint. It takes care of the following

  • Build Basic authorization token (base-64 encoded)
  • Execution of business logic by making a secured call to the Connector API


Please note how the Connector API is invoked


  • the constant (represented by ‘ICS4EBSConnectorBaseURI’ is nothing but the base URI exposed by the MCS REST Connector API i.e. /mobile/custom/AccountHealthEbsAPI
  • the remaining URI (highlighted) is the one which we defined during ICS (Inbound) REST endpoint configuration








Mobile UI Development


As mentioned in the Key Integration Components section of part I of this blog, one choose from a number of supported client frameworks in order to build the mobile application. This mostly involves leveraging the REST APIs exposed by the mobile back end. If we consider the example of a hybrid mobile application, here is the  Javascript jQuery Ajax call  for invoking a GET request


var settings =
            "async": true,
            "url": "https://my-mcs-instance:443/mobile/custom/AccountHealthEbsAPI/riskOrders?customer=your_customer_name&username=your_user_name&password=your_password",
            "method": "GET",
            "headers": {
                "oracle-mobile-backend-id": "oracle_mcs_backend_id",
                "authorization": "Basic eW91cl91c2VyX25hbWU6eW91cl9wYXNzd29yZA==",
                "cache-control": "no-cache"

$.ajax(settings).done(function (response) {

MCS Platform Aspects


It is rather tough to cover all the feature of Oracle MCS is a couple of blogs. The important thing to note is that, MCS provides a comprehensive mobile back end platform which includes support for features such as Push Notifications, Analytics, Storage, offline data and sync etc. These can be best explored using Platform APIs section in the official product documentation




This blog does not cover the relevant security aspects from code & implementation perspective, but the below mentioned items are worth exploring from a deep dive perspective


  • Authentication: identifying valid mobile users using options ranging from HTTP Basic Auth, OAuth, Enterprise SSO as well as social login (Facebook is supported at the time of writing)
  • Authorization: protecting Custom APIs based on roles configured within MCS
  • Outbound Security: Connector APIs leverage declarative security policies to connect to external services
  • Identity Propagation: this involves transmission of the authenticated user context from the mobile app right down to the external system (using Connector APIs) based on tokens/assertions (without exchanging sensitive user credentials)


With this, we have reached the end of this two-part blog series !


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.