The Failed Transactions screen displays and manages transactions sent from the mobile applications that cause an error on processing. This will only occur for mobile applications that are defined with "Server" error handling and shown in the Applications screen.
When working with offline mobile applications it is possible for the data in the mobile client to become out of synch with IFS Apps. This happens for instance when a mobile user modifies data that has already been modified in IFS Apps but not yet synchronized to the mobile application. Under these circumstances it is likely that the data mismatch will cause a transaction error when the mobile application synchronizes the modified data.
To handle these types of events without interrupting the mobile application, errors are held in a queue. This queue can then be processed by an administrator through the Failed Transactions feature.
See the Mobile Framework Synchronization Guide and/or the Troubleshooting Touch Apps for more information.
Transactions are managed based on the User/Device/Application/Transaction Group.
When a transaction errors for a User/Device/Application/Transaction Group, all subsequent transactions sent from the same User/Device/Application/Transaction Group are queued for processing after the failed transaction has been corrected. This is done to maintain data integrity as subsequent transactions may rely upon earlier transactions and cause additional errors if the transactions are not processed in order.
The Transaction Group is used to identify the business object where the failure occurs. This allows the Failed Transaction process to only block transactions from a single business object when a failure occurs rather than blocking all transactions from the User/Device/Application.
There is an Application Defined Event named MOBILE_FAILED_TRANSACTION which can be configured to alert administrators/end users when a Failed Transaction has occurred.
Failed transactions are viewed in the Failed Transactions screen. This screen allows you to browse through queued transactions by User/Device/Application/Transaction Group.
To empty a queue, an administrator must manage the failed transaction and reprocess the queued transactions. This can be done by either correcting the error or deleting the failed transaction. Once this is done the rest of the transactions in the queue are automatically resent and processed in order.
The queued transactions are reprocessed as the mobile user who created the transactions to preserve the original audit trail.
Failed Transactions can be dealt with in five different ways. These are:
As a first attempt the failed transaction can be reprocessed. If the failure is due to a time zone issue then replaying the transaction at a later date may allow the transaction to process successfully using Resend.
A Database Task can be used to automatically reprocess failed transactions.
If the failure has occurred due to incorrect system data then the system data can be corrected and the failed transaction can be reprocessed successfully using Resend.
If the failure has occurred due to incorrect transaction data then the transaction data can be modified in the Failed Transactions Details screen and then the transaction can be reprocessed successfully using Resend.
To correct a transaction you have to right click on the faulty transaction in the queue and select Show Details... from the context menu. You can view the details of any transaction in the queue but only the transactions that have failed can be edited and reprocessed.
There may be instances where some application errors are non-critical in the context that the application is used. In these cases the normal procedure would be to dismiss the error, delete the transaction and continue working. Trapping these failures would cause an unnecessary load on the administrator to process the failed transaction queues. It is therefore possible to configure filters to ignore certain types of transaction errors. All transaction failures detected that match a specific error are ignored and logged. An ignored transaction will, in contrast to a failed transaction, not cause subsequent transactions to be queued.
If the failure will never successfully reprocess the error code can be added to the Ignored Error Types using Ignore. Once the error code is set to be ignored the failed transaction can be reprocessed using Resend. A copy of the failed transaction will be maintained in Ignored Failed Transactions.
If the failure will never successfully reprocess the transaction can be deleted using Delete. A copy of the failed transaction will be maintained in Deleted Failed Transactions.
Deleting transactions could result in a mismatch between the data in IFS Applications and the mobile application. The delete option should therefore be used with caution and steps should be taken after deleting a transaction to ensure the data in IFS Applications and the mobile application are aligned. Either by changing the data in IFS Applications to match the mobile application or instructing the mobile user to perform an Initialization which will reset the mobile application data so that it once again matches IFS Applications.
The Failed Transaction Details screen shows the detailed error description and the data associated with the transaction.
In the lower half of the screen is an editor where you can edit the data to correct the failed transaction if necessary. Once you are satisfied with your changes you press the button Resend. This will send the modified transaction to the server for processing. Once the server has finished processing it will continue processing all the subsequent transactions in the queue until the queue is either empty or a failure occurs.
Note that in the above Failed Transaction example the Transaction Group has a negative number. This is due to the mobile application setting a key sequence number with a negative number which will be replaced with an IFS Applications generated sequence number on successfully processing. The IFS Mobile Client Framework ensures the automatic replacement of mobile application generated keys with IFS Applications generated keys.
This will attempt to reprocess the transaction using the data displayed in the Failed Transaction Details screen. The transaction will be reprocessed as the mobile user to ensure a full audit trail of the mobile users transactions. Due to this the User performing the Resend process must have the System Privilege "Impersonate User" granted to them via a Permission Set. The Permission Set TOUCHAPPS_ADMIN includes this System Privilege for this reason.
On resending, if the transaction still cannot be reprocessed successfully a prompted will be displayed to confirm if the transaction should be deleted or not. If the option to delete is taken then the transaction will be moved to the Deleted Failed Transactions feature.
After successfully reprocessing or deleting a transaction all subsequent queued transactions will be reprocessed in sequence.
Note: On Deleting a Failed Transaction the mobile application data should be realigned with the server data. This can be done by the administrator changing the server data to match the mobile application or requesting the mobile user to initialize the mobile application.
This will add the Error Code to Ignored Error Types list. The Resend action must then be processed to move the Failed Transaction to Ignored Failed Transactions.
There may be instances where some application errors are non-critical in the context that the application is used. In these cases the normal procedure would be to dismiss the error, delete the transaction and continue working. Trapping these failures would cause an unnecessary load on the administrator to process the failed transaction queues. It is therefore possible to configure filters to ignore certain types of transaction errors. All transaction failures detected that match a specific error are ignored and logged. An ignored transaction will, in contrast to a failed transaction, not cause subsequent transactions to be queued.
If the transaction data has been edited the Refresh button will revert the data to the original failed transaction data.
If you do not want to correct the transaction you can instead choose to Delete a Failed Transaction from the Failed Transaction screen via a context menu. On Deleting a Failed Transactions the transaction will be moved to the Deleted Failed Transactions feature.
After deleting a transaction any subsequent queued transactions will be reprocessed in sequence. Due to this the User performing the Resend process must have the System Privilege "Impersonate User" granted to them via a Permission Set. The Permission Set TOUCHAPPS_ADMIN includes this System Privilege for this reason.
Deleting transactions could result in a mismatch between the data in IFS Applications and the mobile application. The delete option should therefore be used with caution and steps should be taken after deleting a transaction to ensure the data in IFS Applications and the mobile application are aligned. Either by changing the data in IFS Applications to match the mobile application or instructing the mobile user to perform an Initialization which will reset the mobile application data so that it once again matches IFS Applications.
Note: On Deleting a Failed Transaction the mobile application data should be realigned with the server data. This can be done by the administrator changing the server data to match the mobile application or requesting the mobile user to initialize the mobile application.