Rational Automation Framework blog.

When it comes to performance within the realm of Rational Automation Framework, there are two places to look. Firstly, the database. Which we wont touch in this article. Secondly, is the projects structure. This document will walk you though a couple best practices and examples of ways to structure and set up your automation plans.

Rational Automation Framework has the ability to thread steps, iterate through steps using the .drill command or While loop. There is also a feature called Long Running Wsadmin in which you can run step with. I will start off by discussing threading and move to long running wsadmin and finish with the various step types.

Threading enables steps to run in parallel, either on the same server or on different servers. Threading is controlled by the Thread property setting for a step. By default, the Thread property is set to No. Threading helps reduce project execution time when there are parts of a project that can be run independently of each other. When the Thread property for multiple adjacent steps is set to Yes, the system attempts to run the step in parallel. Such steps are considered thread-enabled, and each step can be run separately while the rest of the job continues. Threading follows these rules.

• At least two steps in sequence must have the Thread property set to Yes for threading to occur. A set of threaded steps in sequence is called a thread block. Thread blocks can continue into steps that are part of an Inline. For example, if a step in a project contains an Inline and the first step of that Inline is also threaded, the two steps are part of the same thread block. They run concurrently. The thread block follows threaded steps, including nested Inline steps, until a Join step or a nonthreaded step is encountered. Take care to avoid race conditions when using nested Inline steps. A race condition can be caused by an inlined threaded step depending on results or data from the threaded parent step.

  • This is important, considering most of the steps within RAF are ran via libraries that are inlined into the project.

• A thread block is terminated by a step whose Thread property is set to Join or when it encounters a nonthreaded step. At that point step execution becomes sequential again.

• Steps may end up running simultaneously on one server or on several servers,

• If there are multiple thread blocks, the first thread block must complete before the next thread block can start.

Use the Max Threads property for the project to limit the number of threads that can run at the same time. Each thread-enabled step and its inline project, if any, can result in parallel processes. All processes are counted until the maximum for the parent project is reached. The system stops launching new parallel processes when it reaches the Max Threads value. It waits until the number of parallel processes for the project drops below the Max Threads value before continuing.

Most of the projects set up within RAF are launched via an inline that runs a library. Projects steps can be threaded, and so can the associated library steps. Something to keep in mind when designing your automation plan. This is particularly important when it comes to managing a single server. If there are two nodes on one physical machine, threading a step could potentially cause your project to fail. Take the step below as an example of this.

Notice that this step is threaded. It also has a condition that will cause the step to run in a loop for the amount of nodes to install. I can already see a problem when using one physical machine and trying to install more than one node at the same time. This will not work where as if each node were on a different physical machine. This would work.

Notice was_common_configure_jdbc_providers action runs more than one action. It also runs the was_common_configure_jdbc_datasources and was_common_configure_jdbc_was40_datasources. This is an example of a composite action.

Composite actions that are simply called. Will open a new jvm for each action. The composite action moves in sequence. Opening up a new JVM per operation. When running multiple steps against a server, it is possible to have a large number of JVM's running, thus slowing down the entire process. There is a way around this and it's called using Long Running Wsadmin.

Before using the useLongRunningWsadmin option, the necessary files must be in place on the framework server. The Environment Generation wizard for an existing cell puts those files where they need to be. If you have not run the Environment Generation wizard for an existing cell, use the was_common_configure_setup_lr_wsadmin action to copy the necessary files to the framework server. This is not supported on windows and before WAS 6.0.

This feature will launch a WsadminListener. This listener will open up a port and read in information in the form of a request. It puts a lock on the tmp/ directory and will execute each portion of an action using the same JVM. It also creates a larger more robust JVM. This can increase the time it takes to run composite actions.

The issue comes when running actions in long running while they are threaded. If there is another step that calls additional actions running at the same time. They will attempt to use the same Wsadminlistener. This works in some instances, while other instances it hangs the listener. This can depend on the type of actions being used, but rule of thumb. Just don't do it.

It is, possible to break the example composite action above into two steps. After all, one action just calls a series of other actions. Why cant you create your own automation plan calling these steps individually?

This can be done, and to some success as well. This would allow all the associated steps to be threaded. Which would cause them to run in their own individual JVM. This has a tendency to start up a lot of JVM's, but again, depending on the type of actions being ran. It may be faster to run each one in their own JVM. Allowing you to thread them all and avoid any .lock file issues or hung wsadmin processes.

Now let's talk about the different types of steps that can be used within Rational Automation Framework along with a .dot command that can be used in those steps.

Step type determines how the step is run. This property affects the contents of Command and the project specified in Inline, if any.

Regular: The step is run once.

Conditional: The step is run once if the expression in the Condition property evaluates to true. Selecting conditional causes the Condition, Else Inline, and Else Command properties to be shown. If the Condition property evaluates to false, then the Command and Inline are not run. Instead, the Else Command and Else Inline are run if they are specified.

While Loop: The step can be run multiple times. It is run until the expression in the Condition property is false or until the maximum number of iterations is reached. Selecting While Loop causes the Condition and Max Iterations properties to be shown.

The selector is evaluated each iteration of the While Loop to determine the server to use for the iteration.

The .drill command allows you to loop over a command, executing the command once for each member of a series of values. You can specify the values on the command line, or draw them from an environment variable or register. When the system runs a .drill command, the system uses the .drill syntax to construct a series of command lines and sends them to the agent for execution.

For example, the command .drill "A,B,C,D" "echo value $1" creates the following commands:

echo value A

echo value B

echo value C

echo value D

You can group the values and reference multiple values in each group using the $n syntax. $1 refers to the first value in the group; $2 to the second value in the group, and so on. For example, .drill through "(A,B,C,D,E),(B,C,D,E,F),(C,D,E,F,G)" grouped by "()" separated by "," exec "echo 1[$1] 2[$2] 3[$3] 4[$4] 5[$5]" creates these commands:

echo 1[A] 2[B] 3[C] 4[D] 5[E]

echo 1[B] 2[C] 3[D] 4[E] 5[F]

echo 1[C] 2[D] 3[E] 4[F] 5[G]

The .drill command is used in many of the “out of the box” actions. Take this configure library steps for example.

This step, is a regular step, but uses the .drill command to run this step on each individual servers on a node. It kinda works like a Java counter. Using the ${base_server_on_node} variable and the $1.

This is one way to set up a step. You can also set up a step using a while loop and an iteration condition. Such as the step in the example below, and our install example above.

There is also another step called conditional. This step allows you to have a condition, command and Else command.

There are also just plan old regular steps as in the example below.

It is even possible to use a while loop to iterate a condition, while using the .drill command as in the example below.

NOTE:

1. As Mentioned before, do not thread steps that are running wsadminLongRunning

2. Utilize the .drill command whenever possible to iterate through a series of steps. If you thread this step, be careful to make sure you are not running multiple steps on the same physical machine.

3. Use longRunningWsadmin for large composite actions such as was_common_configure_all.

4. It is ok to break down a composite action into many individual steps. Just because an action may not be visible in the CLI or Eclipse does not mean it can't be called in a step.

5. Be careful of the number of open JVM's you have, and be sure to check the target system after several failed attempts at running an action. This will ensure the JVM's are not still open and running.

6. Use the out of the box actions as a references for creating your own automation plans.

For any additional information on any of the topics discussed above. Please use the links below.

http://pic.dhe.ibm.com/infocenter/bldforge/v7r1m3/index.jsp?nav=%2F3