...
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.
...
| Note |
|---|
| 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 classed classified as an update, . It is an additional request. It ; 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:
- Update: These are transactions created in sequence that must be processed in sequence. These are created using the “Edit” icon in the application. Editing records will not correct issues with records that previously failed, they will just queue another transaction to be processed, once the failed record has been fixed.
- Fix: This is a fix to the original transaction, a non-sequential event. It can be performed by the administrator in the Delivery In queue or by users on a device.
| Info | ||
|---|---|---|
| ||
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. |
Critical
...
monitoring
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.
| Warning |
|---|
| 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 as if . 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, administators administrators could find that although the original reason for failure was resolved, they are no longer able to process any update to the record.
The sooner that failures are addressed, the better.
Checking failures / queue on the client
There are two areas which should be monitored on a device:
Records waiting to upsync - client
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 was 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.
...
| Warning |
|---|
| The device queue should only ever be temporary, once 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). |
Failures - client
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.
...
| Warning |
|---|
| 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 gransactions 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 proccessed processed again by the QueueJob. When the QueueJob is run, the following occurs:
...
It is critical that users monitor the failures / queued transactions by monitoring the following parts of the application.
| Note | ||
|---|---|---|
| ||
Client:
Server:
|
...
|
...
|
| Filter by label (Content by label) | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...