workflow
Product: xTier™/LWC 2.3 Whitepaper:  Technical Whitepaper	support@fitechlabs.com  Download  Buy
Depends: log  Related: n/a
xTier™ Navigator: cache cluster config email i18n ioc info jmx jndi security log marshal objpool os fs tx uidgen workflow jobs db startup jms grid

Description
Most workflow engines impose a proprietary rule definition language (RDL) which has its own syntax and the ability to call methods written in some other well accepted language, such as Java. The main goal of this type of system is to enable business people to control business workflow without any knowledge of Java. The disadvantage of this approach is that it splits the business logic into two pieces, half of which are written in a proprietary RDL and the other half in Java. In order to debug this type of system, the developer now has to somehow know and control which piece of functionality is written in what language (RDL or Java). In addition, this type of workflow system generally comes with its own IDE which imposes proprietary means of development and debugging.

Unlike other workflow engine solutions, the xTier™ workflow service is designed for developers. Its main goal is to provide developers with a convenient and easy to use API so they can utilize a customizable workflow when working on their daily projects. All rules are defined in XML and are developed in Java. The developer can therefore use the IDE of their choice. Since xTier™ does not carry extra weight of another proprietary rule definition language, rules are executed with extremely minimal overhead from the workflow service.

xTier™ worklow service is based on Event-Condition-Action (ECA) paradigm. The 'event' component indicates when a rule has to be executed, the 'condtion' checks which action needs to be executed next, and the action defines what needs to be done. In xTier™ workflow service, 'event' is the result of rule execution, 'condition' checks the return value of the rule to determine which rull to execute next, and 'action' actually specifies which rule to execute. User should read the 'event-condition-action' construct as follows: "In the event of execution of rule 'A', if it returned code 'B', then execute rule 'C'.

The main features of xTier™ 'workflow' service are:

• Based on industry well known Event-Condtion-Action paradigm.
• All rules are IoC based for easy reuse and configuration.
• No propriatary rule definition language or IDE.
• Can be used for business or system tasks.
• Allows for reusing rules between different execution sets.
• Run-time and parse-time validation of rules and execution sets.

 Top

Configuration
xTier™ 'workflow' service is configured via pre-defined xtier_workflow.xml configuration file. This file follows standard xTier™ service configuration pattern that can be demonstrated by the following complete example of workflow configuration:

1		<region name="examples">
2		<!-- Validation switches. -->
3		<validation run-time="true" parse-time="true"/>
4
5		<group name="order.processing">
6		<!-- Generic rule for validating price. -->
7		<rule name="validate.price">
8		<ioc policy="new">
9		<java class="com.fitechlabs.xtier.examples.services.
10		workflow.WorkflowValidationRules$ValidatePriceRule">
11		<!-- Constructor arguments. -->
12		<ctor>
13		<!-- Minimum price. -->
14		<arg type="float64">0.01</arg>
15		<!-- Maximum price. -->
16		<arg type="float64">999999.0</arg>
17		</ctor>
18		</java>
19		</ioc>
20
21		<input>
22		<param name="price"/>
23		</input>
24
25		<output>
26		<success code="OK"/>
27
28		<failure code="FAILURE">
29		<param name="errMsg"/>
30		</failure>
31		</output>
32		</rule>
33
34		<!-- Generic rule for validating quantity. -->
35		<rule name="validate.qty">
36		<ioc policy="new">
37		<java class="com.fitechlabs.xtier.examples.services.
38		workflow.WorkflowValidationRules$ValidateQtyRule">
39		<!-- Constructor arguments. -->
40		<ctor>
41		<!-- Minimum quantity. -->
42		<arg type="int32">1</arg>
43		<!-- Maximum quantity -->
44		<arg type="int32">999999999</arg>
45		</ctor>
46		</java>
47		</ioc>
48
49		<input>
50		<param name="qty"/>
51		</input>
52
53		<output>
54		<success code="OK"/>
55
56		<failure code="FAILURE">
57		<param name="errMsg"/>
58		</failure>
59		</output>
60		</rule>
61
62		<!-- Execution set for placing a new order. -->
63		<execset name="create.new.order" entry-rule="validate.price">
64		<!--
65		Creates an order object and adds it to the session.
66		Note, that this rule is private to this execution set and
67		cannot be accessable by other execution sets.
68		-->
69		<rule name="create.order.object">
70		<ioc policy="new">
71		<java class="com.fitechlabs.xtier.examples.services.
72		workflow.WorkflowOrderCreationRule"/>
73		</ioc>
74
75		<input>
76		<param name="qty"/>
77		<param name="price"/>
78		</input>
79
80		<output>
81		<success code="OK">
82		<param name="order"/>
83		</success>
84		</output>
85		</rule>
86
87		<event rule="validate.price">
88		<if code="OK">
89		<action type="execute" rule="validate.qty"/>
90		</if>
91
92		<if code="FAILURE">
93		<action type="exit" code="FAILURE"/>
94		</if>
95		</event>
96
97		<event rule="validate.qty">
98		<if code="OK">
99		<action type="execute" rule="create.order.object"/>
100		</if>
101
102		<if code="FAILURE">
103		<action type="exit" code="FAILURE"/>
104		</if>
105		</event>
106
107		<event rule="create.order.object">
108		<if code="OK">
109		<action type="exit" code="OK"/>
110		</if>
111		</event>
112		</execset>
113		</group>
114		</region>

Formal sepcification for this service configuration can be found in xtier_workflow.dtd file in ${XTIER_ROOT}/config/dtd folder. Rule configuration is composed of two main constructs: 'rule' and 'execset'. Following is detailed description of workflow configuration parameters.

validation	This element specifies validation parameters for workflow services. This element has two attributes for two types of workflow validation: run-time - enables/disables run-time validation. Runtime validation ensures that all input and output contracts specified in rule XML definition are actually followed within implementation. It is important to set rum-time validation to true in debugging stage and turn it off in production since it may affect performance. parse-time - enables/disables parse-time validation. Parse time validation ensures that execution set is valid in respect to all input and output parameters specified in rules XML definitions. Parse-time validation also checks for cycles in execution paths, verifies that rule and execution set names are not mistyped, checks that all returned codes returned by a rule are handled within caller execution set, warns about unreachable events and verifies that all execution sets have at least one terminal event. It is recommended that parse-time validation is always turned on since it has no effect on performance.
rule	This element specifies a workflow rule. Every workflow rule definition is composed of following elements and attributes: name - attribute that specifies the name of the rule. Note that name must be unique within the group the rule is defined in. ioc - defines the actual implementation of the rule. Implementation of the rule is called 'rule body' and is defined via WorkflowRuleBody interface. See IocService for more details on IoC usage. input - optional element that defines input parameters this rule expects to be present in the session. Input element is composed of list of parameter names that will be accessed during execution of this rule. Every parameter may be declared optional, i.e. the rule may not always access it. output - defines returnd codes and set off all output parameters associated with them. Every rule must have at least one return code defined by either <success> or <failure elements. Every return code may optionally have output parameters associated with it. Just as with input parameters, output parameters may be declared optional, i.e. the rule may not always add them to the session.
execset	This element specifies a workflow execution set. Every workflow execution set definition is composed of following attributes and elements: name - name of execution set. Must be unique within the group this execution set belongs to. entry-rule or entry-execset - specifies which rule or execution set to execute first when starting to execute this execution set. rule - optional element that defines private rules to be used only within this execution sets. event - top leevel element in event-condition-action chain. Event constitutes a rule that just finished executing. Events have one or more <if> elements - one for each possible rule return code; this constitutes condition part of ECA. Every <if> element has a nested <action> element. 'action' element specifies which rule to execute next. User should read the 'event-condition-action' construct as follows: "In the event of execution of rule 'A', if it returned code 'B', then execute rule 'C'." output - defines returnd codes and set off all output parameters associated with them. Every rule must have at least one return code defined by either <success> or <failure> elements. Every return code may optionally have output parameters associated with it. Just as with input parameters, output parameters may be declared optional, i.e. the rule may not always add them to the session.

 Top

Examples
Usage of 'workflow' service follows the standard pattern of using xTier™ service: you need to obtain an instance of xTier™ kernel that serves as a service registry. Once you have xTier™ kernel you can get an instance of any service, in our case the workflow service. Once the service instance is obtained the service API can be used.

Following code snippet is taken out from 'workflow' service example:

1		// Start xTier kernel.
2		Utils.startXtier();
3
4		// Get the instance of xTier kernel.
5		XtierKernel xtier = XtierKernel.getInstance();
6
7		// Get the instance of 'workflow' service.
8		WorkflowService workflow = xtier.workflow();
9
10		Map inputs = new HashMap();
11
12		// Store session inputs into the map. Note that
13		// these parameters are specified as inputs in
14		// the workflow XML configuration file.
15		inputs.put("qty", new Integer(100));
16		inputs.put("price", new Double(20));
17
18		// Execute execution-set 'create-new-order' from
19		// group 'order-processing'.
20		WorkflowResult result = workflow.exec("order.processing",
21		"create.new.order" , inputs);
22
23		// Stop the xTier kernel.
24		xtier.stop();

 Top