Troubleshooting Failed Transactions¶
Failed transactions are transactions that doesn't get synched back to the backend system due to several different reasons. Main reasons are System Data Errors, Transaction Data Errors, Process Errors, Software Errors or Consequential error. This troubleshooting guide will go through each of the above error types and explain what you can do in order to resolve the failed transaction.
Note: 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.*
System Data Errors¶
System Data errors occur when the mobile app sends data to IFS Cloud that is invalid. This is typically due to the mobile app users data set-up or the IFS Cloud data set-up.
An example of incorrect mobile app user data set-up is when the user has expired in the company you use. In this example when a mobile app sends a transaction that will create a time record in IFS Cloud the following Failed Transaction will be generated:
To correct System Data errors the IFS Cloud data set-up should be amended and the Failed Transaction resent.
See Failed Transactions for details on how to handle Failed Transactions.
Transaction Data Errors¶
Transaction Data errors occur when the mobile app sends data to IFS Cloud that is unknown. As the mobile app can be offline mobile apps can allow data to be entered that is not known by the mobile app and instead allow IFS Cloud to validate this when the transaction is synchronized.
An example of unknown data is when you return a part that doesn't exist in IFS Cloud. In this example when a mobile app sends the return of the part to IFS Cloud the part will be validated and the following Failed Transaction will be generated:
To correct Transaction Data errors the IFS Cloud data set-up should be amended to register the unknown data or the Transaction Data should be modified in the Failed Transaction Detail screen. The Failed Transaction can then be resent.
See Failed Transactions for details on how to handle Failed Transactions.
Process Errors¶
Process errors occur when operational data in IFS Cloud is amended after the mobile app has synchronized. This can be removing data from IFS Cloud that the mobile app is altering or it can be amending configuration data in IFS Cloud that the mobile app has no knowledge of.
An example of removing data is Unassigning a Work Assignment that has been transferred to mobile app. In this example if the mobile app user updates the Unassigned Work Assignment the following Failed Transaction will be generated:
Another example of changing data can be seen by altering the configuration of a part in IFS Cloud that the mobile app has no knowledge of. So a Part that is not configured as Condition Code Enabled is synchronized with the mobile app. After this point, if the part configuration is changed to enabled Condition Code, will result in a Failed Transaction if the part is used in the mobile app before the part basic data is updated:
It is difficult to successfully resend Process errors so it is important the process is defined and the data set-up correctly before the mobile app is used.
See Failed Transactions for details on how to handle Failed Transactions.
Software Errors¶
From time to time software errors cause Failed Transactions. When these occur the error should be raised to IFS, so it can be corrected.
Until the software error is corrected the Failed Transaction should be Ignored or Deleted, depending on the importance and impact of Ignoring/Deleting the transaction.
See Failed Transactions for details on how to handle Failed Transactions.
Consequential Errors¶
As mobile apps can be offline, transactions are queued by the mobile app and synchronized when connectivity to IFS Cloud is restored. If a transaction for a specific business object generates a Failed Transaction that has subsequent transactions altering the same business object then the subsequent transactions will be queued behind the Failed Transaction as shown below:
If the Failed Transaction cannot be resent and is instead Deleted then the subsequent transactions are likely to also generate Failed Transactions.
An example of a consequential error is the creation of a Work Order followed by changing the Work Order status. On deleting the Work Order transaction then the subsequent state change transaction will fail as the Work Order will not exist in IFS Cloud and will generate a Failed Transaction.
In this example, if the mobile app user continues to update the Work Order then it is likely that more Failed Transaction will be generated:
It is therefore important to remember that after Deleting a Failed Transaction the mobile app data should be realigned with the server data. This can be done by the administrator changing the server data to match the mobile app or requesting the mobile app user to initialize the mobile app.
See Failed Transactions for details on how to handle Failed Transactions.