Creating health policy custom actions

Use custom actions to define custom corrective tasks that you can use when a health condition broken. You can also use custom actions to invoke wasadmin scripts.

Before you begin

Create a Java™ or non-Java executable file to run when the health condition breaches. You can use environment variables in your executable file to display the cell, node, and server that is affected by the health action, for example:

#!/bin/sh
echo "The sick server is "
echo $server
echo " which is on node "
echo $node
echo " which is a part of cell "
echo $cell

To enable the custom action feature:

Add a WebSphere asynchronous administration procedure to the dataset in the PROCLIB concatenation. The following is an example of the job control language (JCL) for this procedure:

//*--------------------------------------------
//SHELL2 EXEC PGM=BPXBATCH,REGION=0M,
// PARM='SH &CMD. &OPT.' 
//STDERR DD SYSOUT=* 
//STDOUT DD SYSOUT=* 
//*--------------------------------------------

The default name for the WebSphere asynchronous administration procedure is BBO8ADM. If a different name is required, change the procedure name, and update the WebSphere environment variable WAS_SERVER_ONLY_shell_command_proc_name to point to the new procedure name.
To update this variable in the administrative console, click Environment > WebSphere variables > <YOUR_NODE>. Select the WAS_SERVER_ONLY_shell_command_proc_name variable. Change the value to the new procedure name, and then click OK. Save and synchronize the configuration. Restart the servers that use the custom action feature to begin using the new procedure name.
Configure the start command for the WebSphere asynchronous administration procedure so that only the started task ID for the node agent can issue the command. Use the following RACF commands:
```
RDEFINE OPERCMDS MVS.START.STC.<ADMIN_PROC_NAME>.**UACC(NONE)
PERMIT MVS.START.STC.<ADMIN_PROC_NAME>.** CLASS(OPERCMDS) ID(<NODE_AGENT_ID>)ACCESS(UPDATE)
SETR RACLIST(OPERCMDS)REFRESH
```
Define the user ID associated with the WebSphere asynchronous administration procedure, and associate the user to the procedure using RACF commands. For example:
```
ADDUSER WSADMSH DFLTGRP(<CELL_ADMIN_GROUP>)OMVS(UID(2504) HOME
(/var/WebSphere/home/<CELL_ADMIN_GROUP> PROGRAM(/bin/sh)) NAME('WAS Asynch Admin
Task') NOPASSWORD NOOIDCARD  
RDEFINE STARTED <ADMIN_PROC_NAME>.*STDATA(USER(WSADMSH)GROUP
(<CELL_ADMIN_GROUP>)TRACE(YES)) 
SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH 
```
Note: In the previous example, the name of the WebSphere asynchronous administration task user ID is WSADMSH. This name can be customized as required. The DFLTGRP of the WebSphere asynchronous administration task user ID should be the WebSphere administrative group for the cell.

If the system console is not configured to require a login, then even when using RACF commands anyone with access to the console can start the WebSphere asynchronous administration procedure.

About this task

By default, you can define the following actions to occur when a health condition is broken: restart the server, take thread dumps, or take heap dumps. If you have more specific needs for actions that occur when a health condition breaches, then create a custom action. Custom actions consist of Java or non-Java process definitions, and can run on the deployment manager, a node that is hosting servers that breach health conditions, the node where the health management controller is running, or a node that you specify.

Create a custom action before you create a health policy. When you define the health policy, select the custom action as part of the action plan that runs when the health condition breaches. You can also define a custom action when you are creating an action plan in the health policy creation wizard.

When a health policy contains multiple custom actions, updating the custom actions can cause the health controller runtime to be out-of-sync with the administrative console configuration. If you add, delete or modify a custom action for a policy that contains multiple custom actions, start, and stop the health controller after saving your changes.

If you use a custom action to invoke a wsadmin script, create a custom script on your target endpoint, that contains the wsadmin invocation. For example, create a custom script test.sh, which uses a Python script to achieve its goal:

test.sh:
#!/bin/sh
/opt/IBM/WAS/bin/wsadmin.sh -lang jython -f /opt/IBM/WAS/wsadmin_test.py param1 param2 param3

wsadmin_test.py:
for arg in sys.argv:
#do something with args

In the administrative console, click Operational policies > Custom action > New. Choose the action type and define the custom action properties:

Name:
Executable:
Executable arguments:
Operating system:
Working directory:

Procedure

Select a Java or non-Java action type.
In the administrative console, click Operational policies > Custom action > New. Choose the type of action that you want to create.
Define the custom action properties.
For health actions that run non-Java and Java executable files:
- Specify a name for the action, the fully qualified path and name of the executable file, and any arguments to pass to the executable file.
- If required, specify variables for the user name and password, and specify the actual values to pass for the user name and password at the time the executable file runs.
- Specify the operating systems on which the executable files can run.
- Specify a fully qualified path for a working directory, which is where to run the executable file.
For health actions that run Java executable files, you must also specify the following properties:
- Specify the location of the Java executable directory.
- Specify the type of target: a Java class, or an executable Java Archive (JAR) file.
- Specify the environment variable that stores the process ID (PID) file name. The PID file name is stored in a WebSphere® variable. Remember the name of the variable so that you can create the variable in a later step.
For example, if you had an executable file to collect logs called logCollector.sh, you enter the following values for the custom action:
- Name: LogCollect
- Executable: /opt/mws/bin/logCollector.sh
- Executable arguments: -arg1 excludeCores -arg2 compress
- Operating system: UNIX
- Working directory: /opt/mws/bin/
Save the custom action.
If your health action is running a Java executable file, create the PID file name environment variable.
The PID file name specifies the location of the PID file where the server operation runs. To define the PID file name variable, click Servers > All servers > middleware_server > Variables > New or Environment > WebSphere variables > New. Enter the same name for the variable that you entered in the health action panel, and for the value, enter the fully qualified or variable qualified location of the PID file.

Results

You created a custom action that you can add to the action plans of your health policies.

What to do next

Create a health policy. In the administrative console, click Operational policies > Health policies > New.