Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

Introduction

The Mobile Java Client is only occasionally connected to the Data orchestration Engine (DOE) to send and receive business data as Data Objects. Because of this all business data entered by the user can not be validated immediately.

So during the synchronization process all the added, modified or deleted business data on the client is sent to the DOE which then passes this data to the backend systems who verifies it. DOE will send either a confirmation or a rejection back to client for all changes.

Here, lets try to further simplify and explain the behavior of the DOE and client to different message states and conditions.

Data Object's states

 A data object has a defined lifecycle in which it has at each time one of the following states:

    • NEW: DO node was newly added on client. This information is not yet sent to the DOE.
    • INCONSISTENT: DO node has been added or updated on client and is inconsistent with the data on the DOE. Corresponding change information is already passed to the client outbound queue.
    •  CONSISTENT: DO node is consistent with DOE in respect of the last synchronization. It has not been changed on client after the last confirmation from DOE.
    •  REJECTED: The last client change (insert, delete or update) of this DO node was rejected on server side. This is either an error or a conflict.

Now these states can change for a DO node if one of the following actions is carried out

    • Client insert:
              A DO node is newly created on the client and added to the database and the transaction is committed.
    • Client update:
              A DO node is updated on client and the transaction is committed.
    • Client delete:
              A DO node is deleted on client and the transaction is committed.
    • Client resolveServerWins:
              On client the error/ conflict repository API was used to apply the server state of the DO node which was sent from the server with the corresponding rejection message.
    • Client resolveClientWins:
              On client the error/ conflict repository API was used to reject the server state of the DO node which was sent from the server with the corresponding rejection message. Instead of this the local change will be kept, eventually corrected and resend to the server.
    • Server insert:
              Client receives a delta or bulk message for a DO node from server with action “INSERT”
    • Server delete:
               Client receives a delta message for a DO node from server with action “DELETE”. This delete also addresses all the child nodes of this node.
    • Server update:
               Client receives a delta message for a DO node from server with action “UPDATE”
    • Server confirm: 
               Client receives a confirmation message for a DO node.
    • Server reject:
               Client receives a rejection message for a DO node.

Transition States

So, now lets see the different transition states a message can go through and what will be the corresponding behavior on the DOE and client side

Case 1: START + Client insert = NEW
Client is creating new DO node. The corresponding insert information is not yet post to the client outbound message. Deleting this node in the same transaction won’t result in a message to server.

Case 2:  START + Server insert = CONSISTENT
Server sends an instance of a DO node to client either via delta message or via bulk message. The data is consistent with middleware.

Case 3:  NEW + Client update = NEW
Client has changed a DO node which was created on client in the same transaction. There is no change message for the insert yet in client’s outbound queue. As node is still unknown by the middleware the state remains in NEW.

Case 4:  NEW + Client delete = FINISH
Client has deleted a node which was created on client in the same transaction. The create information was not yet posted to the outbound queue. The deletion will immediately lead to a hard deletion without sending any change information of this node to the server.

Case 5:   INCONSISTENT + Client update = INCONSISTENT
A DO node which was already changed on the client without a server confirmation is updated again. A new update delta message for this node is posted to client outbound queue.

Case 6:   INCONSISTENT + Client delete = DELETED
A DO node which was already changed on the client without a server confirmation yet is deleted. The new state is DELETED (soft deleted) which means the node is locked for modifications and can not longer be reached for read access.

Case 7:   INCONSISTENT + Server update = INCONSISTENT
A DO node which is changed on the client without a server confirmation yet gets an update message from server. Client does not assign the updated field values to the client node but stores the fields in its Server Repository.  DOE must later on send a rejection message for this node in case of first one wins conflict or a confirmation in case of last one wins.

Case 8:  INCONSISTENT + Server delete = FINISH
A DO node which is changed on the client without a server confirmation yet gets a delete message from DOE. The server delete will be applied because it is an unrecoverable situation.

Case 9:   INCONSISTENT + Server confirm = CONSISTENT or INCONSISTENT
A DO node which was changed on client receives a confirmation from server. If change counter is 1 than the confirmation is for the last change on client so node’s state can be moved to CONSISTENT. In that case the fields that are sent along with the confirmation message are applied on client node. If there is an entry in the Server Repository, then those fields will be merged before with the fields in the confirmation message. If the change counter is higher than 1, then this means that this confirmation is for any previous change. In that case the change counter is decremented but the node remains in that state and the fields are ignored.

Case 10:   INCONSISTENT + Server reject = REJECTED or INCONSISTENT
A DO node which was changed on client receives a rejection from server. If change counter is 1 then the rejection is for the last change so the new state of this node is REJECTED which means node is locked for modifications on client and must be resolved before further actions.
If the change counter is higher than 1 then this rejection was for a previous change. In that case the change counter is decremented but the node remains in that state and the fields which are sent from server are stored in the Server Repository.

 If the rejection reason was error then the last change may already correct the problem and so there is no need to inform the user that one of his previous changes caused in error. If the rejection was because of a conflict then the last change must also cause a conflict. But in any case server will send a confirmation or rejection for the last change which will be used to determine the next state.

Case 11:   DELETED + Server update = DELETED
The DO node was deleted locally on client. The server has not yet confirmed or rejected this change. Instead of this the client receives a delta message from server. This is a client detected conflict. The node remains in DELETED state until the rejection message from server arrives.  The changed fields which are sent along with server’s update message will be stored in client’s Server Repository. In first one wins case server will later on reject this change, in the last one wins scenario server will confirm this change.

Case 12:   DELETED + Server delete = FINISH
The DO node was deleted locally on client. The server has not yet confirmed to reject this change. Instead of this the client receives a delete message from server. This is a technical but not a semantical conflict. On client the node will be hard deleted. Server will later on send a rejection for this conflict as error message which will be ignored on client because the node which will be referenced in this rejection message is not available on client.

Case 13:   DELETED + Server confirm = FINISH or DELETED
The DO node was deleted locally on the client. The server sends a confirmation message. If change counter is 1 then the confirmation is for the client delete of this node so the node can be hard deleted from client. If the change counter is higher than one the change counter is decremented but the node remains in DELETED state because the confirmation message was for a previous change. The fields that are sent along with the confirmation message will be stored in client’s Server Repository.

Case 14:   DELETED + Server reject = REJECTED or DELETED
The DO node was locally deleted on client. The server sends a rejection message. If change counter is 1 then the rejection is for the client delete. In that case the node moves into REJECTED state. The fields which are sent in the rejection message will be stored in client’s repository. If the change counter is higher than one then the rejection is for a previous client change (update or insert) and is out dated. In that case the change counter will be decremented and the fields will be stored in Server Repository. If the rejection is based on an error then client will receive a confirmation or rejection later on from the server. If it is due to a conflict then server will send a rejection message again.

Case 15:   CONSISTENT + Client update = INCONSISTENT
The DO node which was consistent with DOE is changed on client. The change information is passed to client’s outbound queue and client is waiting for server’s response. The DO node has a new state INCONSISTENT.

Case 16:   CONSISTENT + Client delete = DELETED
The DO node which was consistent with DOE is deleted locally. The change information is passed to client’s outbound queue and client is waiting for server’s response. On client there will only be a soft deletion of this node so that the field values are not lost and node can be recovered if server rejects the delete.

Case 17:   CONSISTENT + Server update = CONSISTENT
DOE changed a node which was consistent with client. The node will be updated on client.

Case 18:   CONSISTENT + Server delete = FINSH
DOE deleted a node which was consistent with client. The node will be hard deleted on client.

Case 19:   REJECTED + Client resovleServerWins = FINISH or CONISTENT
User decided to accept server state of the node and to lose the client changes. If the node was deleted on server then the node will also be hard deleted on client. If the node was updated on DOE then new state is CONSISTENT.

Case 20:   REJECTED + Client resolveClientWins INCONSISTENT or DELETED
User decided to reject server state and to resend client state. In that case the following conditions must be separated

    • DOE has updated the node and the client has done the same. The client needs to overwrite server’s state of this node by sending a corresponding update message to the DOE. Node’s next state is INCONSISTENT.
    • DOE has updated the node and client has deleted it. In that case client will resend the delete message to the server. Node’s next state is DELETED.

Case 21:   REJECTED + Server update = REJECTED
A rejected DO node which was not yet resolved on client receives an update message from server. The state remains but the fields which are sent in this update message are stored in client’s Server Repository.

Case 22:   REJECTED + Server delete = FINISH
A DO node which was not yet resolved on client receives a delete message from DOE. Node will be hard deleted from client.

  • No labels

1 Comment

  1. Former Member

    Great Read. Especialy helpful for newcomers like me. A very insightful article.