This article explains the different triggering conditions supported by Action Manager with the help of simple use cases. The article also gives a step by step guide for configuring a simple rule in Action Manager using Administration and Monitoring Console (hereafter called AMC). This article assumes that reader has practical experience installing and using TDI. A rule has two parts namely the condition and the action. The conditions are the different events which are generated by the TDI Server. For example the event of assembly line starting, the event of assembly line stopping etc. The Action Manager has a set of pre-defined actions which a user can configure. The actions can be executed when a particular triggering condition is satisfied. Thus in Action Manager terminology the condition is referred to as a trigger.
Action Manager is a standalone Java™ application that allows the user to monitor multiple TDI servers and assembly line executions using user defined rules. In many scenarios a TDI solution needs the ability to trigger assembly lines based on certain TDI events. The Action Manager provides a framework and the ability to capture the TDI server events and process the actions configured for these events. This can be done by configuring rules in Action Manager using AMC. AMC is a Web-based application for monitoring and managing remote TDI solutions.
Triggers and actions in Action Manager
As mentioned earlier Action Manager has a number of pre-defined triggers. When a triggering condition is met, a corresponding action will be taken, for which the Action Manager provides a set of pre-defined actions. In this section we will enumerate the different triggers and actions provided by Action Manager.
Triggers:
- On AL Terminate
- On Query AL Trigger
- No Trigger
- On Server API failure
- Time since last execution
- On Property change
- On Received event
Actions:
- Start AssemblyLine
- Stop AssemblyLine
- Enable/Disable AM Rule
- Execute AM Rule
- Notify Event
- Modify property
- Copy TDI property value
- Write to log
Action Manager supports many pre-defined triggers and actions which can be configured in custom rules. The triggers can be broadly classified into two types:
- Triggers which listen for events from a TDI Server for example On AL Terminate and On Query AL Result. These triggers act as listeners which are waiting for a particular event.
- Triggers which are based on polling mechanism, i.e., they keep on polling to determine if a condition is satisfied for example Time Since last execution, On Property and On Server API Failure.
The following sections discuss triggers in more detail and describe some use cases.
The On AL terminate trigger is triggered when the specified assembly line terminates. This trigger belongs to the first category, i.e., listening to events. DIEvent is a custom TDI Event. Every time an assembly line terminates the TDI server sends a DIEvent of type di.al.stop. The Action Manager has a listener for the DIEvent which gets triggered when the di.al.stop event is received. The listener verifies if the assembly line which has stopped is the same as configured by the user. If it's the same, then the Action Manager triggers the rule, i.e., the Action Manager executes all the actions which were configured in the rule. The di.al.stop event is triggered even if there is an abnormal termination of the Assembly Line. In scenarios where the user wants to take a particular action(s) after the assembly line terminates either successfully or not, this trigger can be used.
Figure 1. Configure trigger - On AL terminate
UseCase:
TDI has some server mode connectors like HTTP server connector, TCP server connector, SNMP server connector etc., which enable TDI to behave like a server. These connectors are configured in an assembly line and they start listening when the assembly line is started. In scenarios when the assembly line terminates these server connectors are no more able to process any requests coming from clients. An On AL Terminate trigger rule can be configured to ensure a high availability of these server connectors. This can be achieved by configuring a rule with On AL Terminate and having an action Start AL which will restart the assembly line having the server connector.
This trigger type can be said to be similar to an assertion. This is because the On Query AL Trigger checks for a particular attribute in the result entry, i.e., the last work entry of the assembly line. The attribute is checked for either equals, not equals, less than or greater than condition. If the condition is satisfied then the actions configured in the rule are triggered. This trigger belongs to the first category, i.e., listener based, as it waits for the assembly line stop event.
Figure 2. Configure trigger - On Query AL trigger
UseCase:
Consider a data synchronization assembly line which is scheduled to run everyday for backing up data. The user will be interested in knowing if the synchronization is completed successfully. For this the user will have to assert at the end of the assembly line execution if the final work entry, i.e., the result entry has an attribute that matches /does not match a pre-defined value. Once the assertion is made, the user will be able to verify if the data synchronization assembly line has been executed successfully. An On Query AL Trigger type can be configured by specifying the result entry attribute name, condition and an expected value of the same at the end of the assembly line execution. If the condition is satisfied the user would know that the assembly line is executed successfully. In this use case, if the user checks for the failure condition, then the user will have the option of re-running the assembly line using the startAL action.
The No Trigger type as the name suggests is not meant for any specific condition. This trigger can be thought of as a container which can group a set of actions in it and can be associated with any other rule. Thus, if a user has a common set of actions which are required in more than one rule then the user can simply configure a rule with No Trigger and set the necessary actions. This rule can now be executed by the user using the Execute Rule action.
Note: The Execute Rule action is the only way in which a user can execute a rule with No Trigger type. The rule with no trigger does not wait for any event nor does it poll for a specified interval.
|
Figure 3. Configure trigger - No trigger type
UseCase:
Consider a situation wherein a user has to configure a number of rules in Action Manager. However, for taking a remedial action for all the failure conditions the user wants to execute a common set of actions, for example Write the failure information to a log file and Start an assembly line which sends an email. In this scenario, the No Trigger rule comes in handy to the user. The user can configure the common set of remedial actions in a rule and use this rule along with the Execute Action in any of the triggering conditions.
The On Server API Failure trigger gets executed whenever there is a server API failure, i.e., whenever the server is not available. This can be either due to a graceful shutdown of a server or because of an abnormal server termination. In an event when a server shuts down all the configs and assembly lines running on that server are stopped. This trigger belongs to the second type, i.e., polling interval mechanism as mentioned in the broad classification of triggers. Thus, the On Server API Failure is not implemented as a standard listener. Rather, the trigger once configured keeps on polling the server to check if the server is running. The polling interval is specified in the Action Manager configuration file (namely am_config.properties) with the help of property com.ibm.di.amc.am.serverapi.fail.interval.time. If a TDI server stops, the configs and the assembly lines running on the server also stop. This can affect the business; thus, a user may want some notification to be sent in case a TDI Server stops. Except for the Write to log action all other actions need a TDI server to be running to ensure their successful execution, the user has to ensure that there is a back up server running which can be used for executing the actions.
Figure 4. Configure trigger - On Server API Failure
UseCase:
Consider a scenario where the user wants to be notified when a TDI server stops. In this case, the user will have to register two TDI servers with AMC. One on which the actual assembly lines doing the business activities are running and one which is a back up server. The back up server will have assembly lines with different connectors configured for sending notifications to the user. The user will configure a rule in Action Manager with trigger type On server Api Failure for the main server. The user can have a simple Write to log and a Start Assembly Line actions configured for this rule. The Start Assembly Line action will start a notification assembly line on the back up server which will notify users about the failure of main server. Thus, using the above mentioned approach, the user will be able to monitor the main TDI server. The notification assembly line can also be configured to start the stopped server again. This will ensure a high availability of the TDI Server.
This trigger type can be configured to work as a scheduler. As the name suggests, it will be triggered in the specified interval after every execution of the AL on which it is configured. The time interval can be configured to range anywhere from a few seconds to any number of days. This trigger belongs to the second type, i.e., polling interval mechanism as mentioned in the broad classification of triggers.
Figure 5. Configure trigger - Time Since Last Execution
Usecase:
Consider a scenario wherein a user wants to do a task repeatedly after a fixed interval of time. In such scenarios the Time Since last execution trigger can be used. For example consider an Assembly Line which is responsible for synchronization of directory servers. To ensure that the Assembly Line executes every day the user can configure a rule with the Time Since last execution trigger type. The time interval can be set for example to one day. When the triggering condition is satisfied the user can have the Start AseemblyLine action configured which will execute the same Assembly Line. This will ensure that the trigger waits for the mentioned interval (i.e. a day) and then starts the AL again.
The On Property trigger as the name suggests is triggered whenever there is a change in the specified property. This trigger belongs to the second category of triggers, i.e., polling based. The polling interval is specified in the Action Manager configuration file (namely am_config.properties) with the help of the com.ibm.di.amc.am.queryProperty.interval.time property.
Note: This trigger monitors only those properties which have been selected while creating a config view. Thereore, in a scenario where the user has selected no properties while creating the config view, this trigger cannot be used.
|
Figure 6. Configure trigger - On Property
UseCase:
The user can use the On Property trigger to monitor any changes in the properties of the config view. If there is a change in the property which is as per the user expectations or otherwise the same can be logged by the user using the Write to log action. This can provide auditing capabilities for property modifications.
The On Received event trigger gets triggered when the event is configured while creating the rule sent by TDI. This trigger belongs to the first category of triggers, i.e., it is event based. There are three configuration parameters defined for this type of trigger, namely the event type, the event data and event source. If all the three are specified, then the event which matches the event type, data and source is triggered. The event can be sent by using a TDI assembly line with EventNotifier or using the CLI or via Action Manager with the help of Notify Event action.
Figure 7. Configure trigger - On Received Event
UseCase:
The On received event trigger can be used for configuring a rule which will be capable of receiving any custom events sent by TDI. The user can configure an assembly line which will send a custom event in case something goes wrong. The Action Manager can receive this event and start a remedial assembly line to take corrective measures.
As shown from the use cases described above, AMC and Action Manager can be effective tools to monitor TDI solutions.
Creation of Sample Config View and rules
Walkthrough for creation of Sample Config View and rules
This section illustrates all the steps to create a config view, configure rules, and trigger this rule in Action Manager. It is assumed that TDI 6.1.1 is installed along with AMC. The sample config (SampleConfig.xml) and associated files are available in the downloads section and should be copied into the ${TDI _INSTALL}/configs folder. ${TDI _INSTALL} is the installation directory of TDI . This solution reads data from the sample.csv file and writes to sample.xml .
- Start the TDI server in daemon mode.
- Start AMC using following command - ${TDI_INSTALL}\bin\amc\start_tdiamc.bat
- Logon to the AMC console using the url of the following syntax http://host:port/tdiamc using the default username and password. For more details on TDI and AMC installation and start up, refer to TDI documentation
-
After logging on to the AMC console, select the Config Administration -->Load/Reload Configs link. Select the SampleConfig.xml and select the Load button. Next select the Config Administration --> Create Config View link on navigation panel . Add a suitable name for the config for eg SampleConfigView. On selecting next, the following panel is shown.
Figure 8. Select Config
Select the Quick Create button with the default settings. This creates a config view with the name 'SampleConfigView' -
Select the Operation Status and AM --> AM Configuration link on navigation panel to reach the Action Manager rules configuration screen. Select the 'SampleConfigView' from the Select Config View dropdown box. When selecting Add button in the Configured Rules section, the following panel will be shown.
Figure 9. Add Rule Panel
Enter name as 'rule 1'. Select trigger type 'On AL termination' and select the Add button in the Configured Actions section.
Figure 10. Select Action Panel
In the above panel, select the 'Write to log' option and select Next.
Figure 11. Write to Log Action Panel
Add the text in the Messages text box and select OK. The following rule panel will be shown.
Figure 12. Add Rule Panel with Write to log action
selecting OK, completes creation of this rule and the AMC configuration required for this example.
- Start Action Manager using ${TDI_INSTALL}\bin\amc\startAM.bat. A thread is created for the rule 'rule1' which would be waiting for the termination of the specified AL.
-
To trigger this rule, the 'read' AssembyLine of SampleConfig.xml needs to be executed. Select Operation Status and AM --> Monitor Status on the navigation panel. On the Monitor Status panel, select the SampleConfigView and click on the Config View Details button. The following panel will be shown.
Figure 13. Config View Details Panel
Start the AL using the option shown above. The rule will be triggered and the following status will be displayed on the Action Manager console.
Figure 14. Action Manager console
On AMC, the AM results table on the Config View Details panel will be shown as below.
Figure 15. Action Manager results
This article provides a detailed procedure for configuring rules in Action Manager using AMC. It discusses use cases for each of the trigger types and also describes the steps for creating a Config View and configuring a rule. The scenarios in which the Action Manager triggers can be utilized are limited only by the user's imagination.
| Description | Name | Size | Download method |
|---|---|---|---|
| Sample configuration file for TDI | Sample.zip | 10KB | HTTP |
Information about download methods
- Participate in the discussion forum.
-
"Tivoli Directory Integrator 6.1.1 Help"
The help captures all the details for working with TDI.
- The
TDI wikki
is a central place where TDI solution developers can upload their solutions.
- Browse the
technology bookstore
for books on these and other technical topics.
Rony John is currently a developer with the TDI team at the India Software Labs. Rony has completed her Bachelors in technology from Calicut university. She has 5 years of industry experience.




