To define an operation that is not self-defined, create a definition in the toolkit operation definition file. The following example creates a client operation:

The operation named myClientOp is an instance of MyClientOperation. The operation externalizer updates the instance with the attributes belonging to the context, the cross-field validation class, the serverOperation, and the serverOperationParentContext, and the format for the Java Connector. The definition also specifies the operation flow using a reference to a keyed collection containing the operation steps.

You can also define operations using the name of your operation as the tag name and then include the name of the package containing your operation in the toolkit configuration file. However, the recommended way is use “operation” as the tag name and set the package and operation class name in the implClass attribute as shown in the above example.

The operation definition has attributes that reference entities in other definition files such as contexts and formats. When the toolkit instantiates an operation, it tries to resolve all the references to the other definition files. If the toolkit cannot resolve a reference, it throws an exception and does not instantiate the operation and its dependent entities.

Most client operations either set the serverOperationParentContext dynamically or do not set it at all to let the system control the operation under the current context available on the server. The first operation for the application is to create a workstation context on the server belonging to the requesting client. This operation is also responsible for assigning a current context for the client workstation. The Java Connector chains any other operations coming from the same workstation to this current context. The application is also responsible for sending additional operations to modify the current context if required, although this will not be very common.

You can omit the definition for the server operation if the name of the server operation is the same as the client operation except that it ends with ServerOp instead of ClientOp. The system defaults to this name if you do not define the server operation in the operation definition file. The following is an example of a server operation definition:

You may add attributes in the operations definition file. To get the corresponding attributes updated in the operation object, you only have to modify the initializeFrom(Tag aTag) method in your class and provide the appropriate setter and getter.

There are two approaches to updating an operation instance with the corresponding attributes for a specific operation name. The first approach is to use one of the concrete operation constructors if the operation class inherits from BTTOperation:

The second approach to update the attributes of an operation instance is to use the operation externalizer to read the corresponding object from the operations definition file as shown in the following example:

The result is the same but with the first approach you need to know beforehand which operation class you want to instantiate. The second approach enables you to dynamically instantiate an operation by its name when the operation class is unknown. The second approach is recommended because the relationship between the operation name and the operation class can be dynamically changed without affecting the code. The toolkit uses this approach to instantiate operations.