Familiarize yourself with data change notification (DCN) requirements before implementing DCN.
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());
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. 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 graphical model of the package used in the design tooling. Also, one-to-many relationships differ, as noted below.
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:
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:
The foreign surrogate key reference is contained in the cache table used to hold the data for the Department MBO.
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:
The foreign surrogate key reference is contained in the cache table used to hold the data from the Employee MBO.
Unwired Server expects serialized DCN message updates to MBO instances. Therefore if concurrent DCN clients or processes are used, insure that all updates to all rows of MBO(s) are contained within a single DCN request in order to avoid a possible deadlock condition.
Unwired Server expects an entire graph when sending updates to MBOs within a composite relationship.
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.
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"},
}]}
Special care must be taken when using DCN to populate MBOs which form the sub-types of a larger complex type. For example a PurchaseOrder type is composed of POHeader and POLineItem MBOs. To successfully populate the rows of the POHeader and POLineItem MBOs with data derived from a PurchaseOrder, the DCN code must properly set the primary key attributes and insert the rows in the correct order so that the relationship between rows from the POHeader and the POLineItem MBOs is successfully defined. See also the "DCN upsert operations and MBO relationships" topic.
If DCN is the exclusive mechanism for loading and maintaining the data for the MBOs from a cache group, set the cache refresh policy to DCN.
DCN with payload directly updates the CDB by inserting the record into the MBO cache table. Using a DCN cache group policy ensures that MBO data is updated only through DCN and not another refresh mechanism. When designing your MBOs, keep in mind that if you use other methods (for example, a Scheduled cache group policy), DCNs as well as the scheduled refresh update the MBO.
If the cache group relies on a combination of DCN with On-demand or Schedule cache refresh policies, then you cannot use DCN with MBOs that define more than one partition (that is, a load operation mapped to synchronization parameters in Unwired WorkSpace). The cache refresh policy does not support updating data inserted via DCN when the configured cache policy triggers a refresh of the partitioned data.
If the load operation initializes the MBO, and you use DCN 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.
Do not use a cache update policy that invalidates the cache if you use a DCN to populate the MBO.
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.
If any attribute values differ from the actual EIS values, those values are updated with the actual value when a cache refresh occurs. Any rows inserted into the cache which contain a primary key value which is not present in the EIS are marked as logically deleted when a cache refresh occurs. Once a row has been marked as logically deleted from the cache, attempts to upsert data using that same primary key value fail until the logically deleted row is purged from the cache.