Data Change Notification Requirements

Use these data change notification (DCN) requirements to familiarize yourself with possible implementation scenarios.

Personalization parameters in DCN

Server and client personalization parameters of the MBO need to be specified separately in the ppm parameter. The required ppm parameter in the dcn_request has to be a string which should be a Base64-encoded map of personalization parameters. This example shows how you must use ppmString to define the value for ppm parameter in the dcn_request:

Map<String, String> ppm = new HashMap<String, String>();
        ppm.put("myCompany", "Sybase");
        String ppmString = Base64Binary.toString(gson.toJson(ppm).getBytes());

DCN upsert operations and MBO relationships

When using the DCN payload mode to upsert rows to MBOs where there is a relationship between rows of data, you must provide the data in the correct order so Unwired Server can properly create the metadata in the cache (CDB) to reflect the data relationship. The correct order is to send the upserts for the rows for the child MBO before upserting the related parent rows. However, when you are using DCN to insert data into the cache, the concept of child and parent may be different from what is reflected in the package definition seen in Unwired WorkSpace.

When using DCN to upsert rows to both the parent and child MBOs in a relationship, the order for the upserts can change depending on the nature of the relationship. This is due to the implementation details of the cache metadata. In these examples, the Department MBO is the parent MBO in both relationships, but notice the order of the upsert operations:

For a one-to-one relationship between:
```
Dept.dept_head_id - > Employee.emp_id
```
(from a department to the department head) the order in which you upsert a new department and new department head is:
1. Employee
2. Department
The foreign surrogate key reference is contained in the Department table in the cache.
For a one-to-many relationship between:
```
Dept.dept_id - > Employee.dept_id
```
(from a department to all of the employees in the department) the order in which you upsert a new department and a new employee is:
1. Department
2. Employee
The foreign surrogate key reference is contained in the Employee table in the cache.

Message autonomy

Unwired Server expects serialized DCN message updates to MBO instances. That is, do not send two concurrent threads of the same MBO instance to Unwired Server.

Unwired Server expects an entire graph when sending updates to MBOs within a composite relationship.

DCN upsert operations and binary data

When using DCN to upsert binary data to the cache (CDB), the string used for the value of the binary type attribute of the MBO in the request message must conform to a very specific encoding for the DCN request to be processed correctly. Read the binary data into a byte array, then use the following code to obtain it in the correctly encoded format:

 

byte[] picByteArray = < < user code to read binary data into byte[] > > 
String picStringBase64Encoded = com.sybase.djc.util.Base64Binary.toString(picByteArray); 
String picStringUrlEncoded = java.net.URLEncoder.encode(picStringBase64Encoded, "UTF-8");

Use the picStringUrlEncoded string as the value for the binary attribute in the DCN request message.

DCN and date, time, and datetime datatypes

DCN accepts date, time, and datetime attribute and parameter values using this format:

date – yyyy-MM-dd
time – HH:mm:ss
datetime – yyyy-MM-dd'T'HH:mm:ss

For example, Unwired Server parses string or long values and upserts a valid timestamp object:

http://localhost:8000/dcn/DCNServlet?cmd=dcn&username=supAdmin&password=
s3pAdmin&package=testdatetime:1.0&domain=default&dcn_request=
{"pkg":"testdatetime","messages":[{"id":"1","mbo":"TestDateTimeStamp","op":":upsert",
"ppm":null,"cols":{"testTimestamp":"2009-08-09T12:04:05","testDate":"2009-08-09","c_int":"0",
"testDateTime":"2009-08-09T12:04:05","testSmalldt":"2009-08-09T12:04:05","testTime":"12:04:05"},
}]}

MBOs with complex data types must be handled specifically, depending on whether you use Unwired WorkSpace or code entirely written by a developer:

Manually writing the code – if a package uses a complex type, and it defines MBOs from that returned type , you can use a DCN to update that complex type. For example, PurchaseOrder is a complex type. The MBO is defined with the returned POHeader and POLineItem because of a DCN written to update that PurchaseOrder. The DCN code parses the PurchaseOrder data structure, and then constructs separate DCN upsert requests for each row from the POHeader and POLineItem MBOs that are derived from that PurchaseOrder.
Unwired WorkSpace – the DCN with payload requires the MBO attribute name-value pairs as payload data. Because the DCN payload data disregards the EIS schema, the developer needs to be aware of how the EIS schema and the MBO attributes are mapped. The most important consideration is the logic used by the developer to flatten either the complex type, database tables, or the Web service internal schema, or how the developer maps to the backend as MBO attributes.

Send DCN messages only to MBOs with load operations that do not take parameters

You cannot use DCNs with MBOs that define more than one partition (that is, a load operation mapped to synchronization parameters in Unwired WorkSpace). An MBO load operation must be managed completely by DCN should not return any data. If the DCN initializes and maintains the cached MBO, the MBO load operation must not return any rows.

If the load operation initializes the MBO, and you use DCNs to maintain the MBO, then associate the MBO with a cache group that implements an infinite schedule. Do not send DCN messages until the cache is initialized.

Cache update policies and DCN

Do not use an cache update policy that invalidates the cache if you use a DCN to populate the MBO.

DCN and deadlocks

The requirements described above (Message autonomy and Send DCN messages only to MBOs with load operations that do not take parameters) are designed to prevent deadlock situations. However, if you do not define an order of operation execution, deadlocks might occur depending on the DCN implementation or the locking mechanism used by the enterprise information system (EIS). In a deadlock situation, the entire transaction is rolled back (if there are multiple operations in a single DCN) and a replayFailed result is returned.