SAP UI5 Presentation for SUP Hybrid Application – Part 3 – JSON Data

Continuing the series (previous article link) of using SAP UI5 with SUP 2.x (Sybase/SAP Unwired Platform), this covers transforming the SUP native data stream from iMO to JSON expected by the SAPUI5 controls.
This shows the clear and straightforward – but not efficient approach.  Needless to say the production system does it in one step, but it is complicated.

The code for the override to hwc.processDataMessage(), with all the extra bits removed.

hwc.processDataMessage = function processDataMessage(
     incomingDataMessage     // incoming XML data message
[1]  workflowMessage = new WorkflowMessage(incomingDataMessage);
[3]  var jsonObject = hwc.createJsonFromDataMessage(
               workflowMessage.getValues() );
[4]  oModel.setData(jsonObject);

Line [1] creates the global variable workflowMessage which is a binary representation of the incoming XML data message.  This is the legacy SUP central data store for the HWC application.
The function in line [3] goes through the values in the workflowMessage and builds a JSON string, here called jsonObject – but it’s really just the string representing the incoming data in a JSON friendly format as one long string.  The routine ‘createJsonFromWorkflowMessage()’ is simple and boring, and simpler than most data marshaling functions I’ve written.

Finally, on line [4], using the built-in support from SAPUI5, we assign this JSON representation of an artificial JSON source into a global variable named oModel.
The global variable oModel was previously created with:

oModel = new sap.ui.model.json.JSONModel();

A couple things to note on this implementation:

  • Remember I said it was inefficient – so don’t use for production.
  • The workflowMessage variable has a lifetime outside this function.  That is because we need the original data-set in any outbound (reply) messages.
  • I am assigning the oModel into the global default model out of convenience (and some would say laziness).  This model is used to create a binding context which is then assigned to the screen when we navigate to it.

Classically – the return path, to send data back to the server is in our override to the SUP standard hwc.getMessageValueCollectionForOnlineRequest(screenKey, requestAction, keys, …) .

This uses the two global variables – workflowMessage and oModel.  What we need to do is take the updated values form the oModel (which is tied to the binding context of the SAPUI5 controls), merge the data back into the binarySUP workflowMessage then send that back to the SUP server.  This shows the basics of the process, with error handling and extra trappings removed.

hwc.getMessageValueCollectionForOnlineRequest = 
function getMessageValueCollectionForOnlineRequest(
    screenKey, requestAction, 
    keys, keyTypes, context) {

 var dataMessageToSend = new WorkflowMessage("");

 var mvc = workflowMessage.getValues();

 var i;
 var value;
 var jsonValues = oModel.getData();    // **** BOUND DATA ****

 for (i = 0; i < keys.length; i++) {
     var keyValue = keys[i];
     var boundValue = jsonValues[keyValue];
     value = mvc.getData(keys[i]);
     dataMessageToSend.getValues().add(keys[i], value);

 return dataMessageToSend;

As a cheat – I often short-circuit things and just roll my update payload by hand and call the generated JavaScript API directly.  This is simple because the SAPUI5 data-bound controls are all available as simple controls.  These controls are available in my context when the user presses ‘submit’, so it’s pretty simple.
This ends up not using the real SAPUI5 databinding for the outgoing payloads though.