In this post, we discuss how to design Custom APIs for Oracle Mobile Accelerator (MAX) using Oracle Mobile Cloud Service (MCS).
Before we delve into how to develop an MCS API for MAX,a few words about MAX and how does it work. MAX or mobile accelerator is a browser based mobile application development platform which is bundled along with MCS 2.0. It’s a zero code and 100% declarative development platform.
MAX is for the business users and API testers, to develop mobile applications quickly without having any mobile platform or coding knowledge/skill set. MAX provides a complete drag and drop based declarative mobile application development platform. The MAX browser tool set also comes with an embedded simulator for testing the application for both iOS and Android platforms.
APIs that MAX based application can consume
The current MAX version consumes the Custom API developed and published in MCS 2.0. These Custom APIs should be REST based with JSON response developed using Node.js. Any REST or SOAP end point that needs to be consumed from Oracle SaaS or external systems have to be first consumed using the MCS connector and in turn consumed in the Custom API developed using Node.js.
MAX App and API development approach
Development of the MAX application and the MCS Custom API to be consumed in the API go hand in hand. Assuming the MAX Application developer to be a business user and API being developed by a MCS developer, it is important to have a right development approach to ensure productive development with least number of iterations possible. Below development approach flowchart describes the stakeholders and the activity flow.
How to make MCS Custom API MAX compliant:
For a person developing the MAX application, he/she will be dealing with business objects that are based on the endpoints of MCS Custom API. Below screenshots where the accountdeals and userdeals endpoints show as the business object for MAX design time exhibits the same.
CRUD operations available for the business object is dependent on the methods defined for the endpoint, such as GET, POST, DELETE, PUT, PATCH etc. Below given table maps the functionality to the method:
For read only forms, list, bar chart, pie chart, and other charting components. We can select simple screen/template and then add the layouts later on.
For creating a record using the create functionality. The create screen has to be selected while selecting the screen type to be able to assign the create BO.
For edit functionality. The edit screen has to be selected while selecting the screen type to be able to assign the edit BO.
Swipe gesture to remove a record.
Based on the screen functionality and user interface components required the business object needs to be designed and the methods corresponding to the business object needs to be selected. For example, as shown in the picture below, the “notes” endpoint/business object has GET, POST and DELETE methods defined. It has been done so to furnish the functionality, where a user would see a list(using MAX List component) of notes and on the same screen there will be a “+” sign button for creating a note and swipe gesture(please refer the table above) enabled on the List to delete a note.
For MAX to consume the Custom API it is essential that the Custom API’s response is either an object or an array. An object can also contain an array, but it should not contain more than one array at the same object hierarchy level. Below is the sample JSON response which is compliant for MAX:
The eligible business components that will be shown for binding to a UI component in MAX will be dependent on response type. Some of them have been mentioned below in the mapping matrix:
To ensure that the endpoints defined in MCS are available as Business Objects for MAX, it is mandatory that we define the sample response for methods for an endpoint. Below screenshot shows the same.
Last but not the least, for current version of MCS, make sure the custom API is published for it to be available for consumption in MAX design time.
To conclude, below diagram depicts sample architecture for MAX based mobile extension for Oracle Sales cloud:
In case of integration with ERP systems, which have SOAP based API, SOAP connector would have to be used, instead of the REST connector shown in the architecture diagram above.
Please visit here for more details.
**The views expressed in this post are my own and do not necessarily reflect the views of Oracle.