This blog covers topics which are important to understand in order to build bespoke mobile applications which expose functionality powered by Oracle eBusiness Suite (EBS). Teams can leverage the information presented in this blog for multiple aspect of their mobility projects, including planning, design and development
Current offerings & potential opportunities
EBS has a considerable number of mobile apps available as part of the product stack. Also, Oracle Mobile Cloud Service (MCS) latest offerings contain few mobile apps that have been released for EBS Self service and expense management features . However, as a developer working for an enterprise IT having EBS deployed, you still may need to build custom mobile apps that would need to expose business critical data, fetched from EBS, to end users. This could be a mobile app which exposes valuable information congregated from disparate cloud and on-premises applications on a single and intuitive interface, and is therefore completely isolated from other EBS Mobile apps available out of the box.
As an example, consider a fictitious company VISION CORP that sells computing hardware and data center equipment. They used to manage customer experience focused aspects using On-premises deployed Oracle Apps, but have now invested in Sales Cloud, for managing deals and opportunities, and also service cloud for customer service requests. They still use on-premises EBS for tracking Sales orders and invoices. Vision tracks customer data in several systems and to pull together the right information at the right time is quite challenging. Some of the existing customers may be new opportunities too based on their potential need to purchase new products and services. Therefore Vision IT department need to build an “Account Health” Mobile app for sales reps that aggregates customer information into a single, easy to use interface available from any smart phone. This single app should fetch data from Sales Cloud, Service Cloud and on-premises EBS, as shown in the figure below. Sales reps should now be able to quickly review and act on the critical account health information, before meeting existing customers (who are also prospective opportunities for additional sales) in order to successfully conclude relevant deals.
Mobile Application fetching data from Oracle Sales Cloud, Service Cloud and on-premises EBS
Selecting the right Cloud Platform for your Mobile Backend
A comprehensive Mobile Backend is the foundation for a successful mobile app development practice. A wise approach would be to leverage the compelling features which Oracle Mobile Cloud Service (MCS) gives you right out of the box
Oracle MCS: high level architecture
- Platform to host back-end APIs and implementations
- Support for mobile platform aspects – Security, Storage, Offline Data synchronization, Device Notifications, Location Services and Analytics.
- Easy interfaces for no-code UI development and SDKs for diverse set of UI development frameworks
- Quick & secure Integration with back-end systems, using connectors
It’s important to note that all of this is available without you having the need to install/configure and thereafter monitoring/patching/upgrading mobile back-end software infrastructure in your data centers.
Reference architecture presented below can be used for building bespoke mobile apps exposing data from on-premises EBS. It’s the same architecture also covered in the other blog from Oracle A-team.
Architecture for Mobile App fetching data from on-premises EBS
Key integration components
The client side is nothing but the mobile application. It needs to fetch relevant information from on-premises EBS e.g. information related to sales orders and invoices. It could be developed using any client technology which MCS supports
- Native client SDKs: Android, iOS, Windows
- Hybrid clients SDK: Apache Cordova
- Support for Xamarin and Swift: you can also use the MCS SDK with Swift applications and Xamarin platform also provides and SDK which you can use with MCS
You can refer the official documentation (Part II) for a detailed insight into all of the SDKs mentioned above.
In addition to existing SDKs, you can also use the following
- Oracle Mobile Application Framework (MAF): It is a comprehensive mobile application development platform using which you can build applications and deploy to iOS, Android and Windows platforms, all using a single code base. MAF is ideal for building mobile applications on top of backends built with Oracle MCS since it can leverage the REST APIs which MCS exposes
Oracle EBS serves as our target system in this case. It is the repository of information on top of which integrations are built in order to work with the data it contains. Data can be collected from EBS by setting up Integrated SOA Gateway and accessing the SOAP/REST interfaces. Relevant details are mentioned in My Oracle Support documents for EBS version 12.2.x (Document ID 1311068.1) or 12.1.x (Document ID 1998019.1). Considering this integration approach, Oracle Integration Cloud Service (ICS) EBS Adapter can be used to further build integrations. If EBS version is 11.x, the provision to setup Integrated SOA Gateway is not available and therefore the data will have to be collected by directly accessing EBS database and invoking PL/SQL APIs. Considering this integration approach, ICS Database Adapter can be used to further build integration in ICS
Oracle Mobile Cloud Service
MCS would be used to model the mobile backend for integration with the mobile application. MCS REST connector will be configured to connect with ICS integration source REST endpoint and get the data fetched from EBS. MCS Custom API implementation (Node.js code) will invoke the MCS REST connector to gather EBS data, and will expose a REST endpoint for the Mobile app client to invoke.
Oracle Integration Cloud Service
ICS is feature-abundant, but, from the context of this post, the following capabilities are critical
- Inbound REST adapter (source)
- Outbound DB adapter
- On-premise agent
It will provide a suitable platform for integrating with EBS and exposing the fetched data to Oracle Cloud Services (like MCS) in a desirable format. The usage of ICS gains more relevance when EBS is behind corporate firewall. Enterprises do not want to open firewall ports to have Cloud services directly invoke EBS integration interfaces (even http enabled). The solution to this problem lies in an ‘agent’ based approach and is achieved through a combination of an on-premise ICS Agent and Oracle Messaging Cloud Service.
ICS On-Premises Agent
ICS On-Premises Agent would be used as a communication channel between EBS and ICS. The key point to remember is that you’re not obliged to allow incoming requests from Oracle cloud to on-premises EBS – thanks to the combination of ICS and Oracle Messaging Cloud Service
Oracle Messaging Cloud Service
It would act as a mediator between the ICS On-Premises agent and ICS on Oracle Cloud. The ICS agent will be reading messages and publishing to messaging infrastructure powered by Oracle Messaging Cloud Service. Integration should be built in ICS with target using EBS or DB adapter and source as REST. This would let ICS fetch data from EBS and expose it via REST endpoints.
Here is the sequence of events which takes place when the mobile application interacts with the server side integration[AG1]
- The hybrid mobile app makes a call to the REST API exposed by the Custom API layer within Oracle MCS
- The Custom API implementation internally invokes the ICS Connector API (configured in MCS)
- The ICS REST endpoint is called by virtue of the ICS Connector API integration
- Now, the control flow passes on to the EBS DB adapter integration within ICS, which internally translates the (request) as a message and puts into the Oracle Messaging Cloud Service queue.
- The ICS on-premise agent picks up the message from the queue and processes it – this results in the invocation of EBS
- The results obtained from EBS are put into a Oracle Messaging Cloud service by the ICS on-premise agent and this is picked up by ICS component running in Oracle Public Cloud
- The call chain now reverses i.e. the response is passed back to the Connector API, from where it reaches the Custom API and finally back to the mobile client
Mobile App Development Approach
Using Oracle Mobility platform, following approach is recommended for building mobile apps. Though most of these considerations are applicable as general best practices, there are a few specific ones related to integrating the mobile implementation with on-premises EBS
Building the Core Functionality
Based on the requirements of the mobile app and the exact information required from the back end systems (EBS, in the current context), the actual core functionality of the solution is most important. It means - what is the purpose of the app, who are the user actors who would use it, what are the exact screens are required, what should be displayed on those screens, where will that data be obtained from.
Leveraging Platform Aspects
Once the core functionality is fathomed, additional relevant aspects that are more sort of mobility platform aspects need to be also devised - like Security, Offline synchronization/caching of relevant data etc., Storage of mobile content on Cloud (not on device), sending device Notifications, introducing Analytics. Implementation of these aspects would have impact on how developers would build various tiers of the overall solution – UI, mobile service, integration, EBS specific data collection.
Having considered these aspects and based on the architecture presented in the previous section, Fig 3 shows a project planning approach for various tasks involved. It is apparent here that using Oracle cloud platform and recommendations, enterprises could rapidly build EBS Mobility solutions by having different developer personas executing in parallel without any tight dependency on each other. For building a mobile app to fetch data from on-premises EBS, using Oracle Cloud Platform, the bare minimum skill based personas required in the team should comprise of
- Mobile Developer: Creates Custom API endpoints and the UI which will invoke it. Also owns the major work on implementing the mobility platform aspects (security, notification etc.). Also work on configuring secure mobile app access, may be with the help of security/Identity and Access Management (IAM) expert. Depending on the amount of work items involved and the level of segregation, one or more mobile developers could work in parallel, like one expert in Hybrid App development (using JET) building UI focusing on Look-and-feel (LAF) and the other one building custom API end points and configurations for push Notifications, Storage collections, Offline synchronization and so forth.
- Service Developer: Creates the backend service implementation invoked by the MCS custom API, which includes MCS connector configuration and API implementation code developed in Node.js. Also would configure identity propagation to backend system, may be with the help of IAM expert.
- Integration Developer: Creates ICS connections with required systems (like EBS) and actual Integrations including data flow with attribute mappings and transformations.
- EBS SME (Subject Matter Expert): As an expert of EBS, analyzes available EBS APIs or the (database) data model to devise the data extraction logic.
In addition to the personas listed above, please take into consideration, some of the other relevant roles prevalent in a traditional IT project. These are Enterprise Architect, Program/Release Manager, Project Manager and IAM expert.
MCS application development personas
In the initial phase of the project, diligent Requirement Analysis should be carried out. It should lead to the development of an exact UI Prototype of the mobile app, covering the details of each screen and the overall flow. Once the UI prototype is ready, it would be known - what exact information is required from EBS and what should be design/structure of actual MCS custom API which the app should invoke to render relevant information on UI.
Therefore the following two activities can be executed in parallel:
- EBS Integration Analysis: Based on EBS versions and multiple other factors (refer Architecture section), EBS SME would have finalized on the EBS integration approach – Integrated SOA Gateway for Web Services based integration approach or direct database access. Based on the UI prototype details, if the information required from EBS is not available thru the OOTB APIs, then the EBS SME would have to develop and deploy EBS custom integration interfaces for gathering required data (as described here) or develop custom stored procedures and deploy them to EBS DB schema. These activities are a part of EBS Integration Configuration.
- MCS Custom API definition: Based on UI requirements and the information required, it would be clear which screen default view, which swipe, which button click should render what data, and hence what should be the input and output expected from each of the corresponding MCS custom API invocations. Therefore, mobile developer can move forward defining the custom API skeleton and all the corresponding REST endpoints.
With the REST endpoints concluded with the MCS custom API design, Mobile Developer can go ahead and build the entire UI using the relevant client technology, without any dependency on another development activity in the project.Once the EBS Integration ready, mostly the Integration Developer (if having access to on-premises systems) or even the EBS SME can carry out the ICS Agent installation, directly on the EBS or another machine having proper connectivity with EBS. Thereafter, Integration Developer would proceed with ICS Integration Development. It will include creation of ICS connections and actual integrations - EBS as target and REST as source, with attribute mappings for request and response data flows. ICS has adapters for leveraging both approaches for EBS integration– Web Services based, using Integrated SOA Gateway (for EBS R12 onwards) or direct Database access invoking stored procedures.
With ICS integration available to fetch data from EBS, using the corresponding REST end point, it can be invoked by MCS using the MCS REST connector configuration. In addition to making this configuration in MCS, service developer would eventually develop the Custom API implementation, building the logic in Node.js, to invoke the corresponding MCS REST connector. With all the pieces finally ready, Integration testing of the end-to-end flow can be carried out to deliver a quality app
Based on the development strategy mentioned in this post, the implementation details have been covered in second part of this blog.
The views expressed in this post are my own and do not necessarily reflect the views of Oracle.