Purpose
This article explains how SAP Mobile Platform 2.x server, specifically MobiLink, responds to a communication failure and how the client, UltraLite, handle this failure.
Overview
This article will walk you through the steps needed to understand how a MobiLink client (UltraLite) and MobiLink server component within SAP Mobile Platform 2.x respond to a communication failure on the next synchronization. All this depends on when the failure occurred in the synchronization.
In all cases below, we’re assuming that no other errors will occur when applying the upload stream or generating the download stream. The only issue will be a loss of communication between the ML client and the ML Server.
Environment
- SAP Mobile Platform 2.x (SMP)
- MobiLink component in the server side
- UltraLite component on the client
Symptoms
- If the SAP Mobile Platform 2.3 client in this case, it is UltraLite, encounters a communication error before it was able to write the entire upload stream to the wire, the transaction will be rolled back, it is basically as if no synchronization took place.
- If the client is able to write the entire upload stream to the wire, the next time the client perform the synchronization, will depend on how far the server was able to proceed. There are three use cases to cover:
| Use Case | Result |
|---|
Use Case #1 | 1. If the server never receives any of the upload stream 2. If the server only receives part of the upload stream |
Use Case #2 | If the server receives all the upload stream, but the connection is lost while the server is applying the upload stream |
| Use Case #3 | 1. If the connection is lost after the upload stream has committed but before the download is sent to the client 2. If the connection is lost while the download is being sent to the client |
Use Case #1
- The client wrote a complete upload
- But the server was not able to apply the upload, or send any type of response to the client. In that case the next time the client synchronizes, it will resend the same changes again, as well as any changes made since the last synchronization, but will indicate in the upload stream that it has assumed the previous upload was not applied. Since the previous upload did not apply at the consolidated database or the CDB, this upload will continue as usual.
Use Case #2
- The client wrote a complete upload
- The server was able to successfully apply the upload, but it was unable to send a response to the client to indicate that the upload was applied. In this case, the next time the client synchronizes, it will resend the same changes again, as well as any changes made since the last synchronization, but will indicate in the upload stream that it has assumed the previous upload was not applied. Since this is false, the server will reject the upload, and ask the client to resend the upload again, but to only include changes since the last synchronization. A warning (not an error!) will be printed to the MobiLink server log (mlsrv_err.log), and no additional action is required at the client side. The ML Client will automatically resend the upload.
To explain this use case in more details:- If the client thinks the last synch failed because it didn’t get a confirmation, it assumes the synch failed and resends the same data again, but there is information in the upload that says it’s not sure whether the last upload was applied. If it turns out that the last upload was applied, the MobiLink server rejects the upload and asks the client to resend from a different offset. Again, the client will do this automatically, and no errors are written to the MobiLink Log.
Use Case #3
- The client wrote a complete upload
- The server was able to successfully apply the upload and the server was able to send a response to the client indicating that the upload was applied.
- In this case, No download stream was received in the synchronization
- No data needs to be resent from the client, since both the client and server know that the data in the last synchronization was sent and applied
