14.4 Considerations for automated actions

Consider both the conditions for executing an automated action, and the resulting action itself (contents of the executed command).

The command execution environment and user authentication functionality are also involved in executing automated actions. Consider these as well.

• Before suppressing an automated action, consider carefully whether the action is one that can be safely discarded. Examples are given below.

  Examples of actions that need to be executed once only during a set period (actions that can be suppressed):

  - An action that flashes a signal light

  - A user-notification action that sends an email

  - An action that needs to be suppressed during troubleshooting

  Examples of actions that should not be suppressed:

  - An action that performs recovery without user intervention

  - An action that changes depending on the event that triggered it

• When setting delay monitoring of an automated action, consider how long the action should take to complete from the time the JP1 event that triggers the action is received. Also consider the following:

  • Number of levels from JP1/IM - Manager to the target host

    The processing for sending an action from JP1/IM - Manager to the target host entails transfer processing to send the action request from the higher-level manager host to the lower-level manager hosts, and finally to have the target host receive the action. The greater the depth of the configuration management hierarchy, the greater the transfer processing involved and the longer the action will take to complete.

  • Network traffic from JP1/IM - Manager to the target host

    If JP1/IM - Manager is on a different server from the target host, the load on the network connecting the two hosts affects how long the action takes to complete. It will take longer when the network is busy than when traffic is light.

  • Load on the JP1/IM - Manager server

    The load on the server on which JP1/IM - Manager is running affects how long the action takes to complete. The greater the load, the longer it will take for the action to be sent from JP1/IM - Manager to JP1/Base on the same manager host, and the longer the action will take to complete.

  • Load on the target host

    The load on the target host affects how long the action takes to complete. The greater the load, the longer the action will take to complete.

  • Action execution time

    When an action takes longer than the delay monitoring time to execute, it will be reported as a delayed action. Make sure that you estimate action execution time accurately and set an appropriate delay monitoring time.

  In JP1/IM, you can set a maximum delay monitoring time of 24 hours. If you need to monitor an action that takes longer than 24 hours to execute, link with JP1/AJS as explained below to monitor the action.

  Example of monitoring the execution of an automated action by linking with JP1/AJS:

  Prepare a batch file or similar as the action to be executed by JP1/IM. The batch file or similar triggers execution of a JP1/AJS job, and then ends.

  To check whether a command (executed as a JP1/AJS job) that takes a day or longer to execute is running properly, use JP1/AJS.

• The commands in automated actions execute one by one, in the sequence that the actions are received at the target host. Delays might occur when one of these commands takes a long time to execute. In this case, you can reduce the chance of a delay by using the jcocmddef command to increase the number of commands executed concurrently by the JP1/Base on the target host.

  However, when commands are executed concurrently, those that take less time to process end more quickly. If you want commands to be processed in sequence, do not change the default (execute commands one by one).

  A maximum of 48 commands can be executed concurrently by the JP1/Base on the target host. When automated actions are executed by multiple instances of JP1/IM - Manager, bear the following in mind:

  • The total number of commands being executed concurrently by the instances of JP1/IM - Manager must not exceed 48.

  • Sufficient resources to execute the commands must be available on the target host of the automated action.

• An event that notifies the user of the status of an automated action references information saved in the action information file when invoked. If you are setting this type of action, set an adequate file size for the action information file. You can set the size of the action information file in the automated action environment definition file (action.conf.update). An action status notification event is issued at the following times:

  • When a command execution request ends normally and queuing of the action is confirmed

  • When the execution of an action ends (the action status changes to Ended, Cancel, or Kill)

    If the action status is Ended, the result code of the command set for the action is displayed. If the action status is Cancel or Kill, the result code is -1.

  • When the action status becomes an abnormal status (the action status changes to Fail or Error)

  • When the command execution request to command execution control for the action triggered by an action status notification event ends normally and queuing of the action is confirmed

  • The status of the action triggered by an action status notification event becomes an abnormal status

• If you use event information inheritance, event information is automatically specified in the contents of the command. For details about the event information inheritance function, see 4.19.5 Inheriting event information when a command is executed.

For details about automated actions, see the following references:

About automated actions:

• Overview of automated actions

  See Chapter 6. Command Execution by Automated Action (JP1/Base linkage).

• Overview of the command execution environment

  See 9.4.4 Managing command execution.

• Setting automated actions (via the GUI)

  See 3.32 Action Parameter Definitions window in the manual JP1/Integrated Management 3 - Manager GUI Reference.

• Setting automated actions (in a definition file)

  See Automated action definition file (actdef.conf) in Chapter 2. Definition Files in the manual JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

• Setting the automated action environment

  See Automated action environment definition file (action.conf.update) in Chapter 2. Definition Files in the manual JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

• Setting the environment for monitoring the execution of automated actions

  See Automatic action notification definition file (actnotice.conf) in Chapter 2. Definition Files in the manual JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

• Setting the command execution environment for automated actions on the target host

  See the description of the jcocmddef command in the JP1/Base User's Guide.

• Configuration definition

  See the description of the configuration definition file (jbs_route.conf) in the JP1/Base User's Guide.

Organization of this section

• 14.4.1 Notes regarding the considerations for automated actions

To Page Top