Defining an operation

To define an operation, create a definition in the toolkit operation definition file. The following example creates a client operation:
<operation id="myClientOp" context="myClientOc" 
    serverOperation="myServerOp"
implClass="myPackage.myClientOperation"
    xVal="myPackage.MyOperationValidationClass"
    serverOperationParentContext="wksAName">
  <refFormat name="csRequestFormat"
refId="myCSClientOpFormat"/>
  <iniValue name="dataFieldPath" value="iniValue"/>
</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 (the invoker request ID to use to pass the request to the application logic layer or the name of the OperationProcessor), and the serverOperationParentContext (if you are using OperationProcessor), and the format for the C/S Messaging API.

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.

You can omit the definition for the server operation if the name of the server operation (an alias for the invoker request ID or OperationProcessor) 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.

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 DSEOperation:

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:

(DSEOperation) DSEOperation.readObject("opName"); 

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.