Classification of Messages

Transaction-Oriented Messages

Transaction Message : The system creates this message in response to a successful commit cycle on the client. The commit cycle on the client causes the data to change permanently in the client's local database. This results in a temporary inconsistency of data between the server and the client. The system creates attributes for each node in the message while creating the transaction message. These attributes are TASK and SENDBITS. However, this affects the performance of the DOE because this involves accessing the metadata in the entire message before the actual processing starts.

Confirmation Message : Only clients send transaction messages to the server and not vice versa. The transaction message is a request to the server to execute the transaction and return the result to the client by means of a confirmation or an error message.

This indicates that the transaction initiated on the client was successful and committed on all systems. The DOE generates this message in response to a transaction message by the client. This message is sent to the subscriber of the data. It also contains attributes that are updated by the DOE. When a client generates a request to initiate an order, the order number is not known until the order processor confirms the order and assigns an order number to it. When the client receives the order request as a confirmation message, the order number must be updated in the original record created and committed on the client. You can update the message header to change the message type appropriately.

Error Message : The client receives an error message if the transaction is not completely accepted by the DOE. If a client receives an error message, it implies that you need to revert the changes made during the creation of the transaction message. Hence, you need to delete an insert made during the commit cycle of the transaction message, revert the modifications made to attributes, and revert the deletions made to rows. Thus, you need to carry out a logical rollback of the changes. A failed transaction contains information about the reason for an error. The DOE adds an error node, SMMW_ERRS_LIST, to the original transaction message. This node contains the details of the error. The error node can contain several rows or records. The error node is an optional node and is only in the message if the message is of type error.

Synchronization-Oriented Messages

This indicates changes in the mobile clients or the back-end systems. The DOE identifies the mobile clients that need to receive these changes and sends messages to these clients. The system generates the import messages in response to the changes that occur to the DOE system's consolidated database.

You can use different mechanisms to initiate the changes. For example, when a mobile client triggers a transaction message, the system sends an import message to another client in addition to the confirmation message to itself. In addition, mechanisms such as the DOE delta download that bring in modifications from the back-end system also trigger import messages to clients.

If the client receives an import message for a particular row of data, the system applies the contents of the message to that row irrespective of the pending transaction messages on the row of data. Thus, it is possible that the transient values that are present after a transaction message request may be overwritten before they are logically committed by a confirmation message. This happens whenever a client receives import messages, or rather synchronization-oriented messages, between the transaction message and its corresponding confirmation message.

An import message has the message type I. All columns are considered for insertions (TASK=I). If not, you need to initialize all missing columns with database implementation-specific defaults on the client. Any number of columns can be considered for updates (TASK=U). However, you must supply the sync key at all times. The sync key cannot be changed after you assign it. It is used to identify the row that you need to change remotely. The topmost row is considered for deletions (TASK=D). It cascade-deletes all its child rows (and transitively their child rows, if necessary).

Zap Message : The DOE sends this type of message to the mobile client. This message is used to clear all instances of the data objects for which the message is sent to the client. On receiving a zap message, the client must perform a cascade-delete for all instances of the data objects available on the client.

A zap message has the message type Z.

Current State Message : The system sends this type of message from the DOE to the client. The message contains the current content of the CDS for the records present in the root segment of the message. The DOE processes this message and updates the CDS with the new content. In addition, it forwards this message to the mobile clients to update their local databases.

Download Request Message : The client sends this type of message to the server. This message does not have a body. When this request reaches the DOE, it triggers the extract for the data object. If the object is question is a two-way data object, the system performs the delta-download. Once the download is complete, the system sends the data to the client. The DR end marker is also sent together with the data to indicate the completion of the download.

DR End Marker Message : The server sends this type of message to the client. This message indicates the completion of the download request sent by the client. The client cannot send the download request for the data object unless it receives the DR End Marker message from the server for the download request sent previously.

Bulk Oriented Messages

Bulk Message : The DOE sends this type of message to the mobile client. This message contains data that you need to insert in the local database of the mobile client. Insertions of data in the bulk mode is quicker than inserting a single row at a time. You can configure the maximum number of records that a bulk message can contain. This parameter is the packet size, MAX_PACKET_SIZE. If this is not configured, the default size is 50. This means that the DOE packs up to 50 root node records and their entire child hierarchy in one bulk message. A bulk message has the message type B.