Defining a new client

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 File > Save recording configuration as. 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.