Introduction#
nJAMS Replay is an extension for nJAMS Server and nJAMS Client.
nJAMS Replay enables to restart a process execution exactly as it was recorded before. nJAMS Replay records the data during a process execution and uses this data for a replay. In addition, nJAMS Replay also allows to modify the data before you start a replay.
There are many scenarios that make nJAMS Replay a useful tool for your daily work:
- Support for operation team:
Assume you have a service that is triggered once a day. The last execution of the service failed, because a dependent system was unavailable at that time. nJAMS Replay allows you to retrigger that service as soon as the dependent system is up again. So the operation team of the service can quickly resolve issues by using nJAMS Replay.
- Support for service owner:
Assume you have a service that receives invalid data from a caller service, which causes the execution to fail. nJAMS Replay enables you to modify the invalid data and trigger that service again including the corrected data. You do not have to wait for the caller service to resend corrected data. So the service owner can resolve issues on his own.
- Support for quality assurance:
Assume you are testing a service and you are already using nJAMS Server for monitoring your services. Depending on your test cases you can modify the test data as required and trigger the service per test case with different data. nJAMS Server will instantly show the test results. So the QA team can use nJAMS not only for monitoring, but also for testing.
How does nJAMS Replay work?#
nJAMS Replay injects the start activity of a starter process with recorded data and triggers a new job. Since nJAMS Replay does not rely on any transport layer to trigger a new job, it is also not required to send messages in order to invoke the starter process. That means nJAMS Replay allows to restart basically any starter process directly in the process engine!
For example, you have a starter process that contains a JMS Queue Receiver as start activity. So far, it has been necessary to send a message to the designated JMS queue in order to invoke a job. With nJAMS Replay it is not required to use the underlying transport layer. You are now able to directly inject the JMS Queue Receiver activity with data and trigger the process execution. This invention allows to replay basically any process of any kind of start activity, even a Timer or File Poller can be replayed.
What is required to use nJAMS Replay?#
nJAMS Replay comes as a feature for nJAMS Server that just has to be unlocked by entering a valid license key.
On nJAMS Cloud you just have to subscribe to nJAMS Replay and nJAMS Replay is available instantly.
nJAMS Replay does not only consist of a server component, but also a client component. You will need an nJAMS Client that supports nJAMS Replay. Most of current nJAMS Clients do support nJAMS Replay. Please refer to nJAMS Client documentation about how to enable nJAMS Replay on nJAMS Client side.
How do I trigger a process execution, if no recorded data is available?#
If there is a starter process that has not been executed before and no data could have been recorded so far, the starter process can still be retrigered. In case there is no recorded data available, you can perform a “Replay as” that allows to enter data manually. Of course, you have to know the data structure the start activity expects.
How do I get the input data to trigger a process execution?#
nJAMS Replay records the input data of a start activity of any starter process execution. Once nJAMS Replay is enabled on nJAMS Client side, the input data is recorded whenever a process is started. The input data of a start activity is called payload. When you start a Replay, this payload is used to inject the start activity.
How do I see all of my Replays, is there an audit trail that journalizes the Replays?#
Yes. First of all, each process execution gets an identifier that allows you to recognize whether this job has been started by a Replay. The Replay identifier is displayed in the Result list of nJAMS GUI. Furthermore, there are additonal identifiers that indicate whether a Replay has been started from this job or whether recorded data is available.
Secondly, there is a history dialog that shows all Replays regarding a job including its payloads and timestamps. Even the hierarchy of Replays is provided, which means you can see whether a Replay was based on a previous Replay. And you can compare the payload of two Replays in a comfortable way. The payloads are presented side by side and differences are highlighted.
Last but not least, there is an audit log that provides a list of all performed Replays. The audit log includes information about start date of a Replay, the user that started the Replay, and the process that was replayed.
In summary, you have full transparency in respect of nJAMS Replay.