Mobile Workflow Data Change Notification

Mobile Workflow data change notification (DCN) requests enable you to process the general DCN request and send notification to the device to keep the Mobile Workflow in sync with the back-end server when a change to the back-end server is made.

A typical scenario might look like this:


mwf_dev_ref_dcn_flow

All DCN commands support both GET and POST methods. The EIS developer creates and sends a DCN to Unwired Server through HTTP GET or POST operations. The portion of the DCN command parameters that come after http://host:8000/dcn/HttpAuthDCNServlet, can all be in POST; any var=name can be in either the URL (GET) or in the POST. The HTTP POST method is more secure than HTTP GET methods; therefore, Sybase recommends that you include the authenticate.password parameter in the POST method, as well as any sensitive data provided for attributes and parameters.

Note: Enter the HTTP request on a single line.

Mobile Workflow DCN format

The Mobile workflow DCN request is a JSON string consisting of these fields:
  1. Operation name(op) :upsert – the message must contain name/value pairs for every required attribute, and the name must exactly match the MBO attribute name.

    :delete – provide only the name/value pairs for the primary key column(s).

    These operations respectively insert or update, or delete a row in the CDB. Calling either of these operations does not trigger any other refresh action.

  2. Message ID (id) of the Mobile Workflow – used for correlation (a :delete for a previously submitted request with :upsert is possible)
  3. Username (to) – the Sybase Unwired Platform user name. For the user to be recognized by the Workflow DCN mechanism, the device user should first have established communication using the activation mechanism in Sybase Control Center.
    Note: The "To" field must match the SUP user name—it is not the user name that is used for registering the device.
  4. Subject (subject) – subject of the Mobile Workflow message.
  5. Originator <from> – who the Mobile Workflow message is from.
  6. Body of the workflow message <body> – it can embed customized information.
  7. <received> – received time of the Mobile Workflow message.
  8. <read> – whether the Mobile Workflow message is read.
  9. <priority> – whether the Mobile Workflow message has a high priority.
  10. List of dcn request <data> – JSON format string.
Example DCN request in JSON format:
{
"op":":upsert",
"id":"WID123",
"to":"SUPAdmin", 
"subject":"Trip request approval required",
"from":"user321",
 "body":"This is a message just used to do a test",
"received":"2009-03-29T10:07:45+05:00",
"read":false,
"priority":true,
"data":
   [
     {"id": "1",
     <general dcn request>
      }
      …
     {"id": "4",
     < general dcn request>
      }
   ]
}

Mobile Workflow DCN request flow

When the Mobile Workflow DCN request is received, Unwired Server gets the cmd value from the request first. If the value of cmd is wf the DCN request is a Mobile Workflow DCN request. The flow of the Mobile Workflow DCN request is as follows:

  1. Unwired Server invokes preProcessFilter if the DCN filter is specified.
  2. Unwired Server receives a raw HTTP POST body to generate and return a Mobile Workflow DCN request message object.
  3. The JSON format string is parsed into a Mobile Workflow DCN request object.
  4. The DCN request in the Mobile Workflow message object is parsed and any of them within the scope of a single transaction per DCN request object in the array are executed. Results are recorded for a report after completing the Mobile Workflow DCN request.
  5. From the CDB, the server looks up all users assigned to the indicated Mobile Workflow package in the “to” attribute of the Mobile Workflow message, then matches them with the receiver list.

    For every receiver, the server generates multiple Mobile Workflow messages (all Mobile Workflow messages are created within one transaction), one per device identified (one user might have multiple devices), and then sends them to the JMS queues.

    The lookup of the logical id is performed by combining the username in the “to” list to the “securityProfile” specified in the HTTP POST REQUEST URL parameter list.

  6. If any errors occur in step 4, step 5 is not executed. If any errors occur in step 5, step 5 is not committed. If any errors occur in either of those steps, an HTTP 500 error is received.
  7. Unwired Server invokes the postProcessFilter, if specified.
  8. If no errors occur, the server returns success to the caller HTTP 200 with the body of the JSON string (or any opaque data returned from the postProcessFilter) of the Mobile Workflow DCN Result. Otherwise, the server returns an HTTP 500 error with the body of the JSON log records.
Related tasks
Registering and Reregistering Messaging Devices