SAP UI5 Presentation for SUP Hybrid Application – Part 2

Continuing the series (previous article link) of using SAP UI5 with SUP 2.x (Sybase/SAP Unwired Platform), this covers creating a JSON access layer into the MBO (Mobile Business Object) running on the SUP server.

A few points to remember about this environment:

  1. The application is still running in the SUP Hybrid Web Container (HWC).  In addition to a PhoneGap (Cordova) based runtime environment, this container provides the data transport and security to the SUP server.
  2. The SUP 2.x data transport protocol is still Sybase/SAP ‘iMO’ (iAnywhere Mobile Office – a secure proprietary protocol from the Sybase iAnywhere team).
  3. The JSON data layer presented here is purely internal to the application itself.  This serves two purposes:
    1. SAP UI5 has extensive data binding which can take advantage of standard data sources.
    2. There is the possibility that the future SAP servers will be using OData rather than iMO (unofficial speculation).  Using JSON in the rest of the application helps our application prepare for the possible future.
      This sample uses translates iMO into JSON, which is functionally equivalent to using OData in the application layer (since SAPUI5 simply views this as ‘data’).

Like before, the MBO being used in the example is Employee in the package BasicDataTests.  This MBO is simply a view onto the Employee table in the sampledb database supplied with all SUP installations.
This MBO contains the typical features along with all the capabilities of the SUP server.
After this simple MBO was created in the SUP designer, it was deployed to the server in the standard manner.

Create the Javascript Data API

Using a new feature in the 2.2 SUP design environment, we will generate a JavaScript API that can be used from any application executing within the Hybrid Web Container. This JavaScript API (described below) handles the data access from the application to the SUP server freeing the rest of the application for any 3rd party tool.

To create this JavaScript API:

  1. Open the SUP 2.2 design tool environment (the Eclipse based design tooling),
    (maybe original recipe, maybe SP02 – I’m not clear when this became public)…
  2. In the project explorer, select the top-level project – in my sample it is the BasicDataTests project within the Eclipse workspace.
    None of the editors need to be opened, just the project explorer which contains some MBOs deployed to your SUP server.
  3. Right-Mouse the project and select Generate Hybrid App API… in the context menu.
  4. Select the MBO of interest, here ‘Employee’.
  5. Press the Finish button.
  6. Examine the files generated, in this version they are in the folder:
    …/Generated Hybrid App/APIs.
    The JavaScript are in the js sub-folder.
    The WorkflowClient.xml configuration file in the APIs folder.

These screen shots should help:

Selecting the new
‘Generate Hybrid App’ feature in the SUP Workspace Explorer.
 WorkspaceNavigator_GenerateHybridAPI
The only page of the
‘Generate Hybrid App’ wizard we are concerned with.Note: We do not need to fill in the next screen of the wizard, ‘Server-Initiated Notification Configuration’, as we are not using that feature in these samples.
UI5_EmpGenHybridApp1
The files generated for the
JavaScript API which we will use in our application.
UI5_EmpNewFilesAfterGenerateHybridApp

Generated JavasSript Data API Details

After generating the JavaScript API for this MBO, the generated functions for the MBO object queries of interest are all in the file HybridApp.js.
The JavaScript APIs of interest are:

function employee_findAll(employeeObj, credInfo, errorCallback)
Return a list of all employee records.
Action: Employee_findAll
Object query: ‘findAll’ within MBO ‘Employee’
function employee_findByPrimaryKey(employeeObj, credInfo, errorCallback)
Return a single employee record after doing a lookup based on the primary key, the employee ID field.
Action: Employee_findByPrimaryKey
Object query: ‘findByPrimaryKey’ within MBO ‘Employee’
function employee_delete_onlineRequest(employeeObj, oldEmployeeObj, credInfo, errorCallback)
Delete the specified (single) employee record.
Action: Employee_delete
Object operation: ‘delete’ within MBO ‘Employee’
function employee_update_onlineRequest(employeeObj, oldEmployeeObj, credInfo, errorCallback)
Update the specified employee record.
Action: Employee_update
Object operation: ‘update’ within MBO ‘Employee’
function employee_create_onlineRequest(employeeObj, credInfo, errorCallback)
Create an employee record based on the object pased in.
Action: Employee_create
Object operation: ‘create’ within MBO ‘Employee’
function employee_findByLastName(employeeObj, credInfo, errorCallback)
Return a list of employee records by searching for a string fragment in the last name field.
This object query is not used in this sample.
Action: Employee_findByLastName
Object query: ‘findByLastName’ within MBO ‘Employee’

Note: In a typical Hybrid Application generated through the designer; this file, HybridApp.js, also provides the interface from application menu items (and actions) to the specific MBO online requests.

Note: The phrase ‘Action’ here relates to the naming in WorkflowClient.xml which is the string used when the call is made to the online request in the JavaScript APIs in HybridApp.js.

One important point to remember here is that the data we are retrieving and sending to the server is still the SUP ‘iMO’ format.  On top of that, the functions in the API described above are purely JavaScript APIs, not OData or JSON sources.

The next article will show an early hack to translate the data payload from the API call here into an in-memory JSON data source.  This in-memory source will be used for data binding for both incoming and outgoing communications with the SUP server.

Advertisements