Transaction Error Handling Steps

A transaction error handling step references a step definition that is run during transmit if an error occurs while the Server is processing the transaction. This includes errors returned by the data state or update steps. Error handling steps are run only when transaction failure handling is enabled, via a configuration option of the Agentry Server. An error handling step can respond to the Client to indicate the proper action to take in relation to the error that has occurred.

Error handling steps can perform multiple tasks to resolve such an issue. These include:
  • Any post-error processing that may be necessary
  • Setting the error fatality level
  • Returning messaging to the Agentry Client for display to the user

One of the key components to transaction error handling steps is the error fatality. This term refers to the severity of the error and the proper way in which the transaction should be handled as a result of the error. This can include retrying the transaction, possibly after a change is made to it by the user, or removing the transaction from the Agentry Client and storing its data to the failed transactions queue on the Agentry Server.

Error handling steps may not need to be defined as a apart of the transaction failure handling. The Agentry Server contains configuration options to set default behaviors, including the fatality level of an error. Error handling steps are normally defined to override these defaults where necessary.

Error Handling Step Attributes

  • Step: This is the step definition within the module to be run as an error handling step for the transaction. The step referenced here should be defined to return data in the event of an error, or a specific type of error.
  • Error Type: This attribute determines the behavior of the application when the error handling step returns true, indicating the error that occurred should be handled by the step. The options for this attribute are:
    • Fatal with Message - The transmit will be aborted automatically and a message will be displayed to the user. The transaction will be removed from the Client and the data for it stored in the failed transactions que on the Server.
    • Fatal without Message - The transmit will be aborted automatically and no message will be displayed to the user specific to the transaction. The transaction will be removed from the Client and the data for it stored in the failed transactions que on the Server.
    • No Change - This selection will not change the error fatality for the transaction. Either another error handling step for the transaction will handle this, or the default fatality based on the error information returned by the back end system will remain. This is normally set for steps that either create messaging displayed to the user, or that perform other actions against the back end system to handle the error.
    • Retry with Change - The user will be able to choose to abort the transmit and to change the data for the transaction. This requires transaction merging be enabled, as a new transaction will be instantiated by the user and it will then merge with the pending transaction as a result of an error. This will be an option for the user and, should the user choose not to retry, the transmit will continue. The transaction will be removed from the Client and saved to the failed transactions queue on the Server.
    • Retry without Change - The user will be able to retry the transaction without editing the data it contains.
  • Step is true if: This attribute controls whether data returned by the step is treated as a true or false return. When this attribute is true and the step returns data, this is treated as a true response.
  • If True: This attribute defines whether or not the remaining error handling steps for the transaction should be run if the current error step returns true.
  • If False: This attribute defines whether or not the remaining error handling steps for the transaction should be run if the current error step returns false.
  • Notification: This Boolean attribute controls the external notification on the client device. If this attribute is true, a true result for the error handling step will result in the LED on the client device being activated and the transmit dialog flashing.
  • Sound: This attribute defines whether or not the system default sound on the client device should be played when the error step returns true. It also controls the number of times to repeat the sound.
  • Interval: If the Sound attribute is set to play the system sound two or more times, the interval attribute can be set to the number of seconds in between each time the sound is played.
Parent topic: Module-Level Data Definitions Overview