To produce data, a recording
session must start at least one client. Several clients come with
the product. To automate starting a specific application, you can
define a new client.
The only task for the client is to start an application and to
notify the recording framework about client life cycle events. To
configure a client so that it can be recorded by a recorder, see Defining how a recorder can record a client.
Sometimes there is no client to launch because the client already
exists or because the client is a system that has its own life cycle.
In this case, you can use the Manual client that comes with the product.
The ID of the Manual client is com.ibm.rational.test.lt.recorder.core.manualClient.
To define a new type of client, complete these tasks:
- Declare a new client type in the plugin.xml file by using the com.ibm.rational.test.lt.recorder.core.client extension point.
- Determine whether the client can be run locally within the workbench,
remotely in a separate JVM, or in the same JVM as the recorder to
which it is bound.
- Define a delegate, which is the implementation class of the client.
The delegate starts and stops the client and notifies the framework
when the client is started or closed.
- If the client is remote, define a remote launcher implementation
that provides details about the JVM that runs the delegate.
- Optionally, define a prerequisite validator that performs basic
verification that the client can be run on the current computer.
To implement the IClientDelegate interface:
- You must provide an implementation of this interface. This interface
starts and stops the client and sends notifications of events such
as "client started" and "client stopped."
- The start() and stop() methods are asynchronous. In other words,
the operation does not need to be complete when these methods return.
For this reason, a client delegate must notify the framework when
an operation is complete.
- The stop() operation is invoked only when the user clicks Stop in the user interface. In many cases, the user gestures
in the application itself to close the application. The delegate must
monitor the application and notify the framework when the application
is closed.
- A client can have a configuration. The configuration is built
either by using an XML file, which is a file with the .recconfig extension
or by using a wizard. For an example of an XML file, open an existing
recording session file, and then click . The configuration is stored in a ClientConfiguration object, which
is a map of strings to various types of objects. A client delegate
reads this configuration in its initialize() method.
- A client delegate is given a context in its initialize() method.
This context enables the recorder to send notifications of events
and record log messages.
- Typically, you extend the BaseClientDelegate class rather than
directly implement the IClientDelegate class. The base abstract class
provides a basic behavior for most methods. You can override specifically
those that you must override.
- A client delegate can send messages to the user by calling the
sendUserMessage() method, or by calling the getContext().sendMessage(new
UserMessage(...)) method if the delegate does not extend the BaseClientDelegate
class.
- A client delegate can be enabled to communicate with outside entities
by setting or retrieving dynamic properties, or by receiving messages.
The client delegate is useful only if you develop a specific UI for
the client or if you define a client decorator for the client.
If your client launches a specific process, you can extend the
com.ibm.rational.test.lt.recorder.core.clients.ProcessBuilderClientDelegate
class. In this case, you need to extend only the initialize() method,
and then invoke setter methods to set up the command line, arguments,
environment variables, and working directory.