Transaction & Request Replay
You can easily replay Requests and Transactions directly from the records themselves. This is an invaluable tool for debugging and error handling.
Last updated
You can easily replay Requests and Transactions directly from the records themselves. This is an invaluable tool for debugging and error handling.
Last updated
Unlike retries (which are automated), replays are a user initiated action. You can replay both Requests and Transactions directly from their respective records by simply clicking the UI Action.
There are differences between what happens when you replay a Request compared to replaying a Transaction, which will be discussed later. The benefits will also be discussed.
You can replay a single HTTP Request (whether inbound or outbound). Having the ability to focus in on and replay the specific Request which has errored allows you to identify and correct errors more accurately, quickly and easily.
To replay a Request, click the Replay Request UI Action in the header of the Request record.
A Transaction comprises a Request/Receipt pair of HTTP Requests and represents an instance of a Message being sent/received. You can replay the whole Transaction again (not just a single Request). Replaying a Transaction works differently to replaying a Request and both would be used at different stages of the debugging process - though they are both equally as simple to perform.
You can replay a Transaction either from the record itself, or the list view:
Click the Replay UI Action in the header of the Transaction record
Unifi Admins can replay a Transaction at any time - except when it is 'Sending';
Unifi Managers can replay a Transaction when it is either Complete, Errored, or Ignored.
Firstly, having the ability to replay errored Requests/Transactions can save a significant amount of time and effort when debugging and error handling. For example, typically after spotting an error, you would have to step into the config & make a change, step out to the bonded record and send data again, step into the logs to check what happened and continue around until rectified. Compare that to being on the errored HTTP Request, making a change to the data in that request, replaying it and getting immediate feedback (seeing the response codes) all from within the same record.
Not only that, Unifi automatically replays as the originating user*. You don't have to impersonate to replay. Not only does this also save time & effort, but you can debug with confidence - being able to replay as the original sender (not the user replaying), allowing functionality that relies on the identity of the user to run correctly.
*(Originating user: Inbound - Integration user; Outbound - user who initiated the Transaction. )
When you replay a Request, you replay that specific instance of that data (as-is) at that time. When you replay a Transaction, Unifi takes the Stage data and reprocesses it before sending - building the payload/HTTP Request again.
You would normally replay a Request during development & testing, when debugging (making changes during investigation).
You would normally replay a Transaction once you have completed your investigation and made configuration changes, as reprocessing the data would take those changes into account when building a new payload/HTTP Request. Operationally, you are perhaps more likely to replay a Transaction in cases where, for example, the other system was unavailable and the attachment was not sent - so you want to reprocess and attempt to resend the attachment.
Each new attempt to replay either a Transaction or a Request will be incremented with a decimal suffix (.1, .2 etc.)*. This means you can easily identify which replay relates to which record and in which order they were replayed. For example, TX00123 will replay as TX00123.1 and then TX00123.2 etc.
*(Retries will also be incremented in the same manner.)
