Transaction Monitor Service (idtm)
The Transaction Monitor Service (idtm) runs agent programs on behalf of the Workflow Manager Service (idwfm) or client programs such as iddriver. If an agent operation fails, idtm can retry the operation at specified intervals.
Depending on how target systems are configured, the idtm runs agents directly or through the Proxy Service (psproxy),
The Transaction Monitor Service is dependent on the Database Service . If you restart the database service, you must restart the Transaction Monitor Service.
Configuration
The service is automatically installed and started on the Bravura Security Fabric server during setup.You can modify the following parameters related to this service on the Service information page:
Option | Description |
|---|---|
Required parameters: | |
Maximum number of concurrent threads the service should run | Process queued requests with this many concurrent threads. It is reasonable to increase this number on larger Bravura Security Fabric servers. The default is 8. |
Timeout for connection in seconds | The timeout to use for connections. The default is 60 seconds. |
Port number this service is running on | Default is port 2234. |
Comma-delimited list of intervals, in minutes, to wait before retrying failed requests | If a queued request fails, the Transaction Monitor Service waits the specified time before retrying. For example, 5,5,10,10,20,20 means that Transaction Monitor Service will retry in intervals of 5, 10, then 20 minutes until the failed target system becomes available. To specify no retries, enter a value of 0. To restore the default intervals, clear this field of all values then click Update |
Optional parameters: | |
Plugin to determine if an action should still be run (IDTM ACTION STILL APPLICABLE PLUGIN) | You can use a plugin to configure the behavior before an operation is executed. The plugin accepts information about requested actions, and returns a ’true’ if the operation will be run, or a ’false’ if the operation will not be run. |
The maximum number of operations to do in a single agent invocation (IDTM AGENT SINGLE RUN OPERATION MAXIMUM) | Set the value, if needed to allow agents to handle large requests. The default is 100. |
Plugin to modify a batch of connector operations (IDTM BATCH OPREP PLUGIN) | You can use a plugin to rewrite requested operations on target systems. The plugin accepts information about requested actions, and maps them to 0 or more sub-actions on specified target systems. For example, a single update operation can be translated into an update and rename operation on a target system. See Rewriting target system operations for information on writing a custom plugin. |
The interval (in days) to email about IDTM operation failure after the first try fails (IDTM FAILURE EMAIL NOTIFICATION INTERVAL) | Set the interval to send out notifications to different parties of the request (authorizer, requester, recipient) after the first attempt of an IDTM operation fails. The default is one day. |
Plugin to determine whether and when to retry failed requests (IDTM RETRY PLUGIN) | You can use a plugin to configure the behavior when an operation fails. The plugin accepts information about requested actions, including the number of retries already done so far. |
The following table lists Transaction Monitor service events that can trigger email or updates on ticket systems.
Command-line options for idtm are listed below:
Argument | Description |
|---|---|
-h | Displays usage information. |
-v | Displays version number only. |
-clearqueue | Clears the queue. The service must be manually stopped before using this option. WarningThis operation removes all records of outstanding requests. |
-config | Displays service configuration information. |
-server | Run the service in server mode. |
-start | Starts the service. |
-stop | Stops the server/service |
Exposing role entitlement attributes to target systems
When a request is approved for some operation on a target system, the Transaction Monitor Service passes a reqacctitemsig attribute value to the agent. The value comes from the request itemid, which allows the target system to use the API to get role entitlement information from the Bravura Security Fabric database.
It is rare that target systems themselves store the entitlement attributes. This feature allows for support of proprietary systems that do store this information to get access to the information and have the Bravura Security Fabric store and set this information.
See also
Automated User Administration for an overview of how the Transaction Monitor Service works with the Workflow Manager Service and idtrack to propagate tracked changes.