...
The client can be used either online or offilneoffline. 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 integretyintegrity.
The Swift MEAP client will not submit a transaction until it receives a succuss 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.
...
Therefore, we class records within two categories:
- Update: These are transasctions 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. 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.
...
Failure to act upon errors promptly can result in further complications as if 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 occuring 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 could find that although the original reason for failure was resolved, they are no longer able to process any update to the record.
...
Any records in FAILED or RETRIED status will be proccessed again by the QueueJob. When the QueueJob is run, the folloiwng following occurs:
- The QueueJob will scan the delivery in table for records that fall into the current processing window. Usually, records that failed within the last 24 hours are re-processed automatically. Once the record is over 24 hours old, it has been submitted several times and the failure is considered permanent, therefore it will no longer be processed by the QueueJob.
- The QueueJob will ignore any Pending records, it will only process records in FAILED or RETRIED status.
- It will take all existing data and resubmit the record for processing, without change. This allows the server to recover from temporary errors, such as the data source being temporarily unavailable. If there were any errors with the data in the original transaction (validation failures / fields missing / etc.), reprocessing them will not result in successful processing, it will require investigation.
- If the QueueJob was succesful successful in processing the failed transaction, any records that were in Pending status (queued) waiting for the original transaction, will now be processed.
- Once records have been processed, they are marked as READY and a notification to the client is queued. When received, the client will display a success notification and remove the failed record from the sync log. It will also clear the notification from the Sync Log icon.
| Info |
|---|
| 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 transation transaction was successfully processed, the server is waiting for the client to receive the success notification. |
...
- In recent servers, users can check Administrator->Monitoring where a summary of recent failures are listed.
- All errors can be checked in Queues->Delivery In. Pending records are records queued for processing, others indicate some kind of failure.
- Records can be viewed (to see related records and fix failures) using the Edit Transaction icon
- Records that failed within the last 24 hours (controlled by system key queue.recordexpiretime.hours.short) will be reprocessed by the QueueJob, which is usually run every 30 minutes.
- Records that are resubmitted multiple times and still result in failures, will still remain in the queue but will be ignored after the 24 hour period by the short run queuejob. It is unlikely that resubmitting them will result in a successful notification but if you wish for them to be reprocessed, further medium and long term queuejobs can be configured.
- In most cases, failures will require manual invervention intervention before they can be processed. Therefore, monitoring Delivery In for failures is critical.
- If failures repeatidly repeatedly occur, it is usually due to missing validation on the client or missing fields. These configuration issues can be fixed, to prevent errors occurring in the future. Unless ownership is taken to prevent future errors, failures can re-occur frequently.
- The aim of the server administrator should be to esnure ensure that the Delivery In queue is clear of any failed records, this is a pro-active role.
...