Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 will not "fix" a transaction that has already failed, it will queue another transaction to be processed.

...

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 tasked with monitoring reminded to monitor the sync log icon and reviewing review the sync log on a device, to ensure transactions are correctly syncrhonisedsynchronized.   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 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).

...

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.

...

Note
titleCritical areas to monitor

Client:

  1. Records waiting to upsync – Amber icon on the network connection status icon (tablet).  Accessible through Settings->Advanced Options->Show Queue.
  2. Failures – Red icon on the Sync Log icon.  Accessed by selecting the Sync Log icon and selecting “Failed” records from the drop down selection box.  If the “Fix record” button is available, you can correct data errors, otherwise, errors will need to be reported to your administrator.

Server:

  1. In recent servers, users can check Administrator->Monitoring where a summary of recent failures are listed.
  2. All errors can be checked in Queues->Delivery In.  Pending records are records queued for processing, others indicate some kind of failure.
    1. Records can be viewed (to see related records and fix failures) using the Edit Transaction icon
    2. 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.
    3. 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.
  3. In most cases, failures will require manual intervention before they can be processed.  Therefore, monitoring Delivery In for failures is critical.
  4. If failures repeatedly occur, it is usually due to missing validation on the client or missing fields.  These validation issues can be fixed with JavaScript scripts, to prevent errors occurring in the future.  Unless ownership is taken to prevent future errors, failures can re-occur frequently.
  5. The aim of the server administrator should be to ensure that the Delivery In queue is clear of any failed records, this . This is a pro-active role.

 

 

Filter by label (Content by label)
showLabelsfalse
max5
spacesSMKB
sortmodified
showSpacefalse
reversetrue
typepage
labelserrors deliveryin server client swiftmeap

...