To identify why errors occur on a device, it is important to understand how transactions are treated and the flow of data between the client and your data source.
The client can be used either online or offline. Records are created or updated on a mobile device and are upsynced when a connection to the Swift MEAP server is available. These records have to be processed in the sequence that they were created on a device in order to maintain data integrity.
The Swift MEAP client will not submit a transaction until it receives a success or failure notification from the Swift MEAP server for the previous transaction sent. The Swift MEAP server will not submit a transaction to your datasource for processing unless other transactions ahead of it have been processed.
In effect, this means there are two queues, one on the client which holds records waiting to upsync to the Swift MEAP server (the device request queue). The second is the list of records that could not be processed or are waiting to be processed (the server Delivery In Queue). Even if a record is in the Delivery In queue, it does not necessarily mean that there is an error with that record, it could be in the queue, waiting for another (failed) record ahead of it to be processed.
If a record fails, it cannot be corrected on a device by simply editing the record and selecting another value. So if a user enters an incorrect date in an appointment (which fails against the data source), they cannot tap the edit button on the client and change the appointment date. In this case, they are not correcting the original transaction, they are creating a second transaction that cannot be processed until the first transaction has been fixed (which is in error).
The user has performed two distinct changes:
Any change to a record within the client application, which has been made as a result of selecting the "Edit" icon and and saving, is classified as an update. It is an additional request; it will not "fix" a transaction that has already failed, it will queue another transaction to be processed. |
Therefore, we class records within two categories:
Users can only fix records on a device using the “Fix Record” button within the Sync Log, if enabled by the administrator using System Key: allow.user.to.edit.failed.records. Unless this key is enabled, all corrections must be made by the administrator in the Swift MEAP server or by resolving issues in the data source. |
It is critical that both end users and administrators take responsibility for ensuring the following:
Any records reported as failures and any records that require the failed record to be processed before they can be submitted (pending) will not exist in your data source, they have not been processed successfully. Therefore, the only place that they exist is on a device and within the Swift MEAP server (Delivery In queue).
All failures are reported to the user on a device. Administrators can monitor errors within the Swift MEAP console application. Failures are not automatically fixed, they need to be acted upon. It is often best to set up email notification in the server, so that administrators are aware of any errors as they occur.
Users should be reminded to monitor the sync log icon and review the sync log on a device, to ensure transactions are correctly synchronized. Failure to identify and resolve issues can lead to further issues. |
If issues are not fixed promptly, they can result in further complications. For example, if a record is processed at a later date, records could fail due to further time sensitive validation in place on your data source. If, for example, your data source only allows submission of activities within 7 days of them occurring and a user submits an Activity after 6 days, if the submission fails (for any reason) and is not fixed for three or four days, administrators could find that although the original reason for failure was resolved, they are no longer able to process any update to the record.
There are two areas which should be monitored on a device:
The network indication icon is a series of green / red vertical bars in the bottom left of the tablet display. The icon is green (indicating web access is available) or red (indicating no network access is available).
Records waiting to upsync are indicated in an amber circle. The number of records waiting to upsync is displayed in the circle icon. When the client connects to the Swift MEAP server, records in the device queue should be upsynced to the server.
Details of transactions in the queue can be viewed on the phone or tablet by going to Settings->Advanced Options->Show Queue
The device queue should only ever be occupied temporarily. Once the client connects to the Swift MEAP server, the number of records waiting to upsync should decrease immediately. There should never be a reason why this number is displayed for an extended period of time (if the device is connected to the network and the Swift MEAP server is accessible). |
Records that have failed (either due to validation in your Data Source or an inability to present the record to your data source) are displayed as a red circle on the Sync Log icon. The number of records that have failed are listed within the red circle icon. If no icon is present, there are no failures for the current client.
Failures can also be checked by clicking on the Sync Log icon and selecting “Failed” from the drop down selection box to view failed records. Each failed record is listed individually, selecting a transaction will show details of the failure message returned from your data source (or from the Swift MEAP server if the data source was unavailable).
If administrators have allowed users to fix records, the “Fix record” button will be listed in the sync log, once a record has been selected. If the “Fix record” button is not available, the record can only be fixed by your server administrator. Editing the record to change values will not fix the original transaction.
Allowing a user to fix a record essentially allows them to edit any value and alter it. This bypasses any onSave validation performed when normally editing or creating records. Extra validation can be entered which is executed when fixing records. Contact iEnterprises for details. |
Failed and pending records can be checked by selecting Queues->Delivery In. Each transaction has an “Edit transaction” button, where you can view details of the transaction, related records and details of the error message received.
You can alter any values in the “Edit transaction” screen and submit them for processing against your data source. If successfully processed, the transaction is handled as if the record were fixed on a device. A success notification will be returned to the device and any fields that were altered by the administrator will be sent to the client, so that server and client records contain the same data.
During upsyncing of transactions from the client queue, the following occurs:
Pending transactions are never processed, they are not failures but records queued for processing. Records in FAILED or RETRIED status are clear examples of failures that need to be cleared before pending transactions can be processed. If you open a pending transaction, you will not see a failure message but you will be able to view related record, to identify which record ahead of it in the queue has failed. |
Any records in FAILED or RETRIED status will be processed again by the QueueJob. When the QueueJob is run, the following occurs:
As a result of sequential processing, there may only be one record in the queue that has failed, but there could be a number of related records waiting to process (Pending). Processing a FAILED or RETRIED record and refreshing the queue may well clear several records from the Delivery In queue. When a record is listed as READY, it means the transaction was successfully processed, the server is waiting for the client to receive the success notification. |
It is critical that users monitor the failures / queued transactions by monitoring the following parts of the application.
Client:
Server:
|
|