[jboss-svn-commits] JBL Code SVN: r20728 - in labs/jbossrules/trunk/drools-docs/drools-docs-flow/en: Chapter-Flow and 1 other directory.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Tue Jun 24 09:29:21 EDT 2008
Author: KrisVerlaenen
Date: 2008-06-24 09:29:21 -0400 (Tue, 24 Jun 2008)
New Revision: 20728
Modified:
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-Flow/Chapter-RuleFlow.xml
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/master.xml
Log:
docs
Modified: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-Flow/Chapter-RuleFlow.xml
===================================================================
--- labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-Flow/Chapter-RuleFlow.xml 2008-06-24 08:40:06 UTC (rev 20727)
+++ labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-Flow/Chapter-RuleFlow.xml 2008-06-24 13:29:21 UTC (rev 20728)
@@ -272,7 +272,7 @@
<section>
<title>Different types of nodes in a ruleflow</title>
- <para>A ruleflow is a flow chart where different types of nodes are linked using connections. It has the following properties: a (unique) id, a (display) name and a version. You can also specify how the connections are visualized on the canvas using the connection layout property:
+ <para>A ruleflow is a flow chart where different types of nodes are linked using connections. It has the following properties: a (unique) id, a (display) name and a version. Global and imports can be defined that can be reused throughout the entire process. You can also specify how the connections are visualized on the canvas using the connection layout property:
<orderedlist>
<listitem>
<para>manual always draws your connections as lines going straight from their start to end point (with the possibility to use intermediate break points)
@@ -298,30 +298,30 @@
</mediaobject>
</figure>
- <para>Currently, ruleflow supports eight types of nodes:
+ <para>RuleFlow supports different types of nodes:
<orderedlist>
<listitem>
- <para>Start: the start of the ruleflow. A ruleflow should have exactly one start node. The start node cannot have incoming cnnections and should have one outgoing connection. It contains one property "name" which is the display name of the node. Whenever ruleflow process is started, the ruleflow will start executing here and automatically continue to the first node linked to this start node</para>
+ <para>Start: the start of the ruleflow. A ruleflow should have exactly one start node. The start node cannot have incoming cnnections and should have one outgoing connection. It contains one property "name" which is the display name of the node. Whenever ruleflow process is started, the ruleflow will start executing here and automatically continue to the first node linked to this start node.</para>
</listitem>
<listitem>
- <para>End: the end of the ruleflow. A ruleflow should have one or more end nodes. The end node should have one incoming connection and cannot have outgoing connections. It contains one property "name" which is the display name of the node. When an end node is reached in the ruleflow, the ruleflow is terminated (including other remaining active nodes when parallelism is used).</para>
+ <para>End: the end of the ruleflow. A ruleflow should have one or more end nodes. The end node should have one incoming connection and cannot have outgoing connections. It contains one property "name" which is the display name of the node. When an end node is reached in the ruleflow, the ruleflow is terminated. If a ruleflow is terminated, all nodes that are still active in this ruleflow are cancelled first (which is possible if parallel paths are used).</para>
</listitem>
<listitem>
- <para>RuleFlowGroup: represents a set of rules. A RuleFlowGroup node should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node, and the property ruleflow-group which is used to specify the name of the ruleflow-group that represents the set of rules of this RuleFlowGroup node. When a RuleFlowGroup node is reached in the ruleflow, the engine will start executing rules that are part of the corresponding ruleflow-group. Execution will automatically continue to the next node if there are no more active rules in this ruleflow-group. This means that, during the execution of a ruleflow-group, it is possible that new activations belonging to the currently active ruleflow-group are added to the agenda due to changes made to the facts by the other rules. Note that the ruleflow will immediately continue with the next node if it encounters a ruleflow-group where there are no active rules at that poin!
t.</para>
+ <para>RuleSet: represents a set of rules. The rules are evaluated when the node is reached. A RuleFlowGroup node should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node, and the property "ruleflow-group" which is used to specify the name of the ruleflow-group that represents the set of rules of this RuleFlowGroup node. Rules can use the ruleflow-group attribute to become part of a ruleflow group. When a RuleSet node is reached in the ruleflow, the engine will start executing rules that are part of the corresponding ruleflow-group (if any). Execution will automatically continue to the next node if there are no more active rules in this ruleflow-group. This means that, during the execution of a ruleflow-group, it is possible that new activations belonging to the currently active ruleflow-group are added to the agenda due to changes made to the facts by the other rules. Note that the rul!
eflow will immediately continue with the next node if it encounters a ruleflow-group where there are no active rules at that point. If the ruleflow-group was already active, the ruleflow-group will remain active and exeution will only continue if all active rules of the ruleflow-group has been completed. </para>
</listitem>
<listitem>
<para>Split: allows you to create branches in your ruleflow. A split node should have one incoming connection and two or more outgoing connections. It contains a property "name" which is the display name of the node. There are three types of splits currently supported:
<orderedlist>
<listitem>
- <para>AND means that the control flow will continue in all outgoing connections simultaneously
+ <para>AND means that the control flow will continue in all outgoing connections simultaneously (paralellism).
</para>
</listitem>
<listitem>
- <para>XOR means that exactly one of the outgoing connections will be chosen. Connections are chosen by evaluating the constraints that are linked to each of the outgoing connections. Constraints are specified using the same syntax as the left-had side of a rule. The constraint with the lowest priority number that evaluates to true is selected. Note that you should make sure that at least one of the outgoing connections will evaluate to true at runtime, or the ruleflow will throw an exception at runtime if it cannot find an outgoing connection. For example, you could use a connection which is always true with a high priority number to specify what should happen if none of the other connections can be taken.
+ <para>XOR means that exactly one of the outgoing connections will be chosen (decision). Which connection is decided by evaluating the constraints that are linked to each of the outgoing connections. Constraints are specified using the same syntax as the left-hand side of a rule. The constraint with the lowest priority number that evaluates to true is selected. Note that you should always make sure that at least one of the outgoing connections will evaluate to true at runtime (the ruleflow will throw an exception at runtime if it cannot find at least one outgoing connection). For example, you could use a connection which is always true (default) with a high priority number to specify what should happen if none of the other connections can be taken.
</para>
</listitem>
<listitem>
- <para>OR means that all outgoing connections whose condition evaluates to true are selected. Conditions are similar to the XOR split, except that the priorities are not taken into account. Note that you should make sure that at least one of the outgoing connections will evaluate to true at runtime, or the ruleflow will throw an exception at runtime if it cannot find an outgoing connection.
+ <para>OR means that all outgoing connections whose condition evaluates to true are selected. Conditions are similar to the XOR split, except that the priorities are not taken into account. Note that you should make sure that at least one of the outgoing connections will evaluate to true at runtime (the ruleflow will throw an exception at runtime if it cannot find an outgoing connection).
</para>
</listitem>
</orderedlist>
@@ -329,28 +329,38 @@
</para>
</listitem>
<listitem>
- <para>Join: allows you to synchronize multiple branches. A join node should have two or more incoming connections and one outgoing connection. It contains a property "name" which is the display name of the node. There are two types of splits currently supported:
+ <para>Join: allows you to synchronize multiple branches. A join node should have two or more incoming connections and one outgoing connection. It contains a property "name" which is the display name of the node. There are three types of splits currently supported:
<orderedlist>
<listitem>
- <para>AND means that is will wait until all incoming branches are completed before continuing
+ <para>AND means that is will wait until all incoming branches are completed before continuing.
</para>
</listitem>
<listitem>
- <para>XOR means that it continues if one of its incoming branches has been completed
+ <para>XOR means that it continues if one of its incoming branches has been completed.
</para>
</listitem>
+ <listitem>
+ <para>Discriminator means that it continues if one of its incoming branches has been completed.
+ </para>
+ </listitem>
</orderedlist>
</para>
</listitem>
<listitem>
- <para>Milestone: represents a wait state. A milestone should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node, and the property "constraint" which specifies how long the ruleflow should wait in this state before continuing. For example, a milestone constraint in an order entry application might specify that the ruleflow should wait until (a fact in the working memory specifies that) no more errors are found in the given order. Constraints are specified using the same syntax as the left-had side of a rule. When a Milestone node is reached in the ruleflow, the engine will check the associated constraint. If the constraint evaluates to true directly, the flow will continue imediately. Otherwise, the flow will continue if the constraint is satisfied later on, for example when a facts in the working memory is inserted, updated or removed.</para>
+ <para>Event wait (milestone): represents a wait state. An event wait should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node, and the property "constraint" which specifies how long the ruleflow should wait in this state before continuing. For example, a milestone constraint in an order entry application might specify that the ruleflow should wait until (a fact in the working memory specifies that) no more errors are found in the given order. Constraints are specified using the same syntax as the left-hand side of a rule. When a wait node is reached in the ruleflow, the engine will check the associated constraint. If the constraint evaluates to true directly, the flow will continue imediately. Otherwise, the flow will continue if the constraint is satisfied later on, for example when a facts in the working memory is inserted, updated or removed.</para>
</listitem>
<listitem>
- <para>Subflow: represents the invocation of another ruleflow from withing this ruleflow. A subflow node should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node, and the property "processId" which specifies the id of the process that should be executed. When a Subflow node is reached in the ruleflow, the engine will start the process with the given id. The subflow node will only continue if that subflow process has terminated its execution. Note that the subflow process is started as an independent process, which means that the subflow process will not be terminated if this process reaches an end node.</para>
+ <para>SubProcess: represents the invocation of another process from withing this ruleflow. A sub-process node should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node, and the property "processId" which specifies the id of the process that should be executed. When a SubProcess node is reached in the ruleflow, the engine will start the process with the given id. If the property "Wait for completion" is true, the subflow node will only continue if that subflow process has terminated its execution (completed or aborted); otherwise it will continue immediately after starting the sub-process. If the property "independent" is true, the sub-process is started as an independent process, which means that the subflow process will not be terminated if this process reaches an end node; otherwise the active sub-process will be cancelled on termination (or abortion) of the process. A SubProcess can !
also define in- and out-mappings for variables. The value of variables in this process with given variable name in the in-mappings will be used as parameters (with the associated parameter name) when starting the process. The value of the variables in the sub-process with the given variable name in the out-mappings will be copied to the variables of this process when the sub-process has been completed. Note that can only use out-mappings when "Wait for completion" is set to true.</para>
</listitem>
<listitem>
- <para>Action: represents an action that should be executed in this ruleflow. An action node should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node, and the property "action" which specifies the action that should be executed. When an action node is reached in the ruleflow, it will execute the action and continue with the next node. An action should be specified as a piece of (valid) MVEL code.</para>
+ <para>Action: represents an action that should be executed in this ruleflow. An action node should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node, and the property "action" which specifies the action that should be executed. The action should specify which dialect is used to specify the action (e.g. Java or MVEL), and the actual action code. The action code can refer to any globals and the special 'drools' variable which implements KnowledgeHelper, and can for example be used to access the working memory (drools.getWorkingMemory()). When an action node is reached in the ruleflow, it will execute the action and continue with the next node.</para>
</listitem>
+ <listitem>
+ <para>WorkItem: represents an (abstract) item of work that should be executed in this ruleflow. A WorkItem node should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node. The type of work is uniquely identified by the work item name. When a WorkItem node is reached in the ruleflow, it will execute start the associated work item. If the property "Wait for completion" is true, the WorkItem node will only continue if the created work item has terminated its execution (completed or aborted); otherwise it will continue immediately after starting the work item. Each type of work item can define parameters that describe that type of work. For example, an email node (work item name "Email" will define properties like 'from', 'to', 'subject' and 'text'. The user can either fill in values for these parameters directly, or define a parameter mapping that will copy the value of the given variable!
in this process to the given parameter (if both are specified, the mapping will have precedence). Each type of work can also define result parameters that will be returned after the work item has been completed. A result mapping can be used to copy the value of the given result parameter to the given variable in this process. Note that can only use out-mappings when "Wait for completion" is set to true. The user can define their own types of work items (see the section about pluggable work items).</para>
+ </listitem>
+ <listitem>
+ <para>Timer: represents a timer that can trigger one or multiple times after a given period of time. A Timer node should have one incoming connection and one outgoing connection. It contains a property "name" which is the display name of the node. The "TimerDelay" property specifies how long (in milliseconds) the timer should wait before triggering the first time. The "Timerperiod" specifies the timer will between two subsequenct triggers. A period of 0 means that the timer should only be executed once. When a timer node is reached in the ruleflow, it will execute the associated timer. The timer is cancelled if the timer node is cancelled (e.g. by completing the running process).</para>
+ </listitem>
</orderedlist>
</para>
</section>
Modified: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/master.xml
===================================================================
--- labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/master.xml 2008-06-24 08:40:06 UTC (rev 20727)
+++ labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/master.xml 2008-06-24 13:29:21 UTC (rev 20728)
@@ -44,6 +44,7 @@
<xi:include href="Chapter-Introduction/Chapter-Introduction.xml" />
<xi:include href="Chapter-GettingStarted/Chapter-GettingStarted.xml" />
<xi:include href="Chapter-Flow/Chapter-RuleFlow.xml" />
+ <xi:include href="Chapter-DomainSpecificProcesses/Chapter-DomainSpecificProcesses.xml" />
<xi:include href="Chapter-Debugging/Chapter-Debugging.xml" />
<index/>
More information about the jboss-svn-commits
mailing list