To use the Automaton to handle a business process, create a flow processor by doing the following:
1 Model the business process as a state machine.
2 From this model, identify the Automaton entities that you need to extend.
To change the internal behavior of the Automaton to suit the requirements of a particular project, create a specialized flow processor and states by subclassing from DSEProcessor or DSEState, and define the relationships between the tag names and the classes actually implementing the behavior. These steps follow the normal programming model of the toolkit.
In addition to the standard technique, you can directly set the tag name of the flow processor to the actual name of the class that the externalizer is to instantiate. When you use this technique, the externalizer does not use the relationships defined in the configuration file. Instead, it follows the standard approach used for operations, which is to use the name of the class set as the tag name instead of searching in the toolkit configuration file for the relationship between the tag name and the name of the class to be instantiated.
3 Using the model, create a definition of the flow processor. Each node in the model has a corresponding state within the flow processor.
You can define the process in the toolkit processor definition file, dseproc.xml, or in a self-defined processor file. The self-defined processor file can also contain definitions for the contexts and formats that the processor requires that are not defined in the generic toolkit files.
To create the definitions, use any ASCII editor.
4 To implement the business logic within the process, define the flows in the processor using actions and guard conditions.
Example
The toolkit provides the following examples of realizing a complex business function using a flow processor:
▪ Managing processes in a rich graphical user interface (see Flow processor example: process management in a GUI)
▪ Managing navigation dialogs in a complex business function (a mutual fund acquisition) using an HTML client (see Flow processor example: dialog navigation controller)
In this definition, the value of the implClass attribute in the processor tag means that the toolkit instantiates the myPackage.MyProcessorClass to create the processor instance. The processor externalizer updates the instance with the attributes and subtags contained in this file.
2 In the toolkit context definition file, create a definition for the context that the processor uses to store data.
3 In the toolkit format definition file, create definitions for the formats used to move data into and out of the context.
▪ The refKColl tag references a collection of data defined in this self-defined processor file.
▪ The refFormat tag named firstFormat references a format defined in this self-defined processor file
▪ The refFormat tags named secondFormat and thirdFormat reference formats that are not defined here. The toolkit formats definition file must therefore define these formats.
▪ The refService tag references a service defined in the self-defined processor file
▪ Data5 is not defined in the self-defined processor file. The toolkit data definition file must therefore define this data.
▪ The workstation context is not defined here. The toolkit context definition file must therefore define this context.
2 In the toolkit configuration (dse.ini) file, check that the value of the modularity field is appropriate.
This field allows the toolkit to distinguish between self-defined and regular processors.
<field id="modularity" value="modularityType" />
Where modularityType can be:
▪ grouped - The toolkit only uses entities defined in the toolkit definition files. This is the default value.
▪ split - The toolkit only uses entities defined in self-defined files.
▪ mixed - The toolkit uses regular and self-defined entities.
3 To enable externalizers to find the definitions, do one of the following ways:
▪ Specify the path and file name of the self-defined processor file inside the files.processors keyed collection:
▪ The value of the id attribute is the name of one self-defined processor.
▪ The value of the value attribute is the name of the file containing the self-defined processor definition. This attribute is optional and if not defined, the toolkit searches for a file with the name of the self-defined processor with a .xml extension.
▪ The value of the path attribute specifies the location of the self-defined processor file. This attribute is optional and if unspecified, the toolkit uses the value of the generic path in the paths collection to search for the file. See the following bullet for a description of the generic path.
The following example contains many ways of defining the location of the self-defined processors. See the notes below the example for the effect of defining the tag in its way.
[c] Uses the default file name and the generic path.
[d] Reads the file from an HTTP address.
[e] Reads the file from a .zip file.
[f] Reads the file from a .jar file.
▪ Place the self-defined file in the generic entities path. The definition of the generic path is in the paths keyed collection. The toolkit uses the generic path if it cannot find the location of the file in the processors section of the files keyed collection. If the file does not contain generic entities path definition, add its definition:
▪ The path to the definition files for the toolkit entities such as operations, processors, data, and formats. The path can be an absolute path or relative local path from the location of the toolkit configuration (dse.ini) file.
▪ The HTTP address of the definition files. It can be an absolute path or a relative path from the location of the toolkit configuration (dse.ini) file.
▪ The value "fromJar". The toolkit reads the entities from a JAR file.
Determining whether a process executed successfully
To determine whether a processor executed successfully, you can obtain the value of the typeIdInfo of the final state. This value declares how the processor finished and allows you to handle the result accordingly.
For example, say you have a processor with the following definition:
The following code launches the processor and gathers the typeIdInfo of the final state:
// Get the processor from the external definition Processor proc = (Processor) DSEProcessor.readObject("procName"); // Run the processor proc.execute(); // Get the typeIdInfo corresponding with the final state String result = proc.getCurrentState().getTypeIdInfo(); if (result.equals("ok")){ // do whatever } else if (result.equals("notOk")) { // do whatever else } // close the processor to free up resources proc.close();