[jboss-svn-commits] JBL Code SVN: r19501 - labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Wed Apr 9 00:28:57 EDT 2008
Author: irooskov at redhat.com
Date: 2008-04-09 00:28:57 -0400 (Wed, 09 Apr 2008)
New Revision: 19501
Modified:
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-DSL.xml
labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-RuleFlow.xml
Log:
updated for inclusion to the reference guide
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-DSL.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-DSL.xml 2008-04-09 01:35:21 UTC (rev 19500)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-DSL.xml 2008-04-09 04:28:57 UTC (rev 19501)
@@ -258,12 +258,12 @@
<section>
<title>How it works</title>
- <para>DSLs kick in when the rule is parsed. The DSL configuration is read
- and supplied to the parser, so the parser can "expand" the DSL expressions
+ <para>DSLs are activated when the rule is parsed. The DSL configuration is read
+ and supplied to the parser, so the parser can <emphasis>expand</emphasis> the DSL expressions
into the real rule language expressions.</para>
<para>When the parser is processing the rules, it will check if an
- "expander" representing a DSL is enabled, if it is, it will try to expand
+ <emphasis>expander</emphasis> representing a DSL is enabled, if it is, it will try to expand
the expression based on the context of where it is the rule. If an
expression can not be expanded, then an error will be added to the
results, and the line number recorded (this insures against typos when
@@ -278,68 +278,58 @@
token placeholders are extracted by either searching until the end of the
line, or until a character or word after the token place holder is
matched. The "{" and "}" are not included in the values that are
- extracted, they are only used to demarcate the tokens - you should not use
- these characters in the DSL expression (but you can in the target).</para>
+ extracted, they are only used to demarcate the tokens. These characters should not be used in the DSL expression (but can be used in the target).</para>
</section>
<section>
<title>Creating a DSL from scratch</title>
- <para>DSLs can be aid with capturing rules if the rules are well known,
- just not in any technically usable format (ie. sitting around in people
- brains). Until we are able to have those little sockets in our necks like
- in the Matrix, our means of getting stuff into computers is still the old
- fashioned way.</para>
+ <para>DSLs can be aided with capturing rules if the rules are well known,
+ just not in any technically usable format.</para>
- <para>Rules engines require a object or data model to operate on - in many
- cases you may know this up front. In other cases the model will be
- discovered with the rules. In any case, rules generally work better with
- simpler flatter object models. In some cases, this may mean having a rule
+ <para>Rule engines require a object or data model to operate on, in other cases the model will be
+ discovered with the rules. No matter the case, rules generally work better with
+ simpler, flatter object models as this allows for the engine to infer relationships (providing future flexability). This may mean having a rule
object model which is a subset of the main applications model (perhaps
mapped from it). Object models can often have complex relationships and
- hierarchies in them - for rules you will want to simplify and flatten the
- model where possible, and let the rule engine infer relationships (as it
- provides future flexibility). As stated previously, DSLs can have an
+ hierarchies in them. As stated previously, DSLs can have an
advantage of providing some insulation between the object model and the
rule language.</para>
<para>Coming up with a DSL is a collaborative approach for both technical
- and domain experts. Historically there was a role called "knowledge
- engineer" which is someone skilled in both the rule technology, and in
- capturing rules. Over a short period of time, your DSL should stabilize,
+ and domain experts. Historically there was a role called knowledge
+ engineer which was someone skilled in both the rule technology, and in
+ capturing rules. Over a short period of time, the DSL should stabilize,
which means that changes to rules are done entirely using the DSL. A
- suggested approach if you are starting from scratch is the following
+ suggested approach if you are starting from scratch is outlined with the following
workflow: <itemizedlist>
<listitem>
- <para>Capture rules as loose "if then" statements - this is really
- to get an idea of size and complexity (possibly in a text
+ <para>Capture rules as loose <emphasis>if...then</emphasis> tatements. This is to get an idea of size and complexity (possibly in a text
document).</para>
</listitem>
<listitem>
- <para>Look for recurring statements in the rules captured. Also look
- for the rule objects/fields (and match them up with what may already
+ <para>Look for recurring statements in the rules captured and for the rule objects/fields (and match them up with what may already
be known of the object model).</para>
</listitem>
<listitem>
<para>Create a new DSL, and start adding statements from the above
- steps. Provide the "holes" for data to be edited (as many statements
+ steps. Provide the fields for data to be edited (as many statements
will be similar, with only some data changing).</para>
</listitem>
<listitem>
- <para>Use the above DSL, and try to write the rules just like that
- appear in the "if then" statements from the first and second steps.
- Iterate this process until patterns appear and things stabilize. At
- this stage, you are not so worried about the rule language
- underneath, just the DSL.</para>
+ <para>Use the above DSL, and try to write the rules just as they
+ appear in the <emphasis>if...then</emphasis> statements from the first and second steps.
+ Iterate this process until patterns appear and the system stabilizes. Emphasis now should be placed on just the DSL and not the rule language
+ underneath.</para>
</listitem>
<listitem>
<para>At this stage you will need to look at the Objects, and the
- Fields that are needed for the rules, reconcile this with the
- datamodel so far.</para>
+ Fields that are needed for the rules then reconcile this with the
+ datamodel created so far.</para>
</listitem>
<listitem>
@@ -354,35 +344,33 @@
<section>
<title>Scope and keywords</title>
- <para>If you are editing the DSL with the GUI, or as text, you will notice
+ <para>If the DSL is being edited with the GUI, or as text, it can be noticed that
there is a [scope] item at the start of each mapping line. This indicates
- if the sentence/word applies to the LHS, RHS or is a keyword. Valid values
+ if the sentence or word applies to the LHS, RHS or is a keyword. Valid values
for this are [condition], [consequence] and [keyword] (with [when] and
[then] being the same as [condition] and [consequence] respectively). When
- [keyword] is used, it means you can map any keyword of the language like
- "rule" or "end" to something else. Generally this is only used when you
- want to have a non English rule language (and you would ideally map it to
+ [keyword] is used, it means any keyword of the language like
+ <code>rule</code> or <code>end</code> can be maped to something else. Generally this is only used when requiring a non-English rule language (each would ideally map it to
a single word).</para>
</section>
<section>
<title>DSLs in the BRMS and IDE</title>
- <para>You can use DSLs in the BRMS in both guided editor rules, and
- textual rules that use a dsl. (In fact, the same applies to the
+ <para>DSLs can be used in the BRMS with both guided editor rules, and
+ textual rules that use a DSL (the same applies to the
IDE).</para>
- <para>In the guided editor - the DSLs generally have to be simpler - what
- you are doing is defining little "forms" to capture data from users in
- text fields (ie as you pick a DSL expression - it will add an item to the
- GUI which only allows you enter data in the {token} parts of a DSL
- expression). You can not use sophisticated regular expressions to match
+ <para>In the guided editor, the DSLs generally have to be simpler. What
+ is occuring is the defining of little forms to capture data from users in
+ text fields (For instance, as a DSL expression is picked it will add an item to the
+ GUI which only allows data to be entered in the {token} parts of a DSL
+ expression). When using the GUI, sophisticated regular expressions cannot be used to match
text. However, in textual rules (which have a .dslr extension in the IDE)
- you are free to use the full power as needed.</para>
+ the full power of the DSL can be utilized.</para>
- <para>In the BRMS - when you build a package the DSLs are already included
- and all the work is done for you. In the IDE (or in any IDE) - you will
- either need to use the drools-ant task, or otherwise use the code shown in
- sections above.</para>
+ <para>In the BRMS, when building a package, the DSLs are already included
+ and all the work is done automatically. In the Drools supplied IDE (or in any IDE), the drools-ant task will need to be used, or the code shown in
+ previous sections.</para>
</section>
</section>
Modified: labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-RuleFlow.xml
===================================================================
--- labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-RuleFlow.xml 2008-04-09 01:35:21 UTC (rev 19500)
+++ labs/jbossrules/branches/irooskov_docs/drools-docs/drools-docs-referenceguide/en/Chapter-Rule_Language/Section-RuleFlow.xml 2008-04-09 04:28:57 UTC (rev 19501)
@@ -15,39 +15,39 @@
</figure>
<para>Drools already provides some functionality to define the order in
- which rules should be executed, like salience, activation groups, etc. When
+ which rules should be executed, like salience, activation groups and so forth. When
dealing with (possibly a lot of) large rule-sets, managing the order in
- which rules are evaluated might become complex. Ruleflow allows you to
- specify the order in which rule sets should be evaluated by using a flow
- chart. This allows you to define which rule sets should be evaluated in
- sequence or in parallel, to specify conditions under which rule sets should
- be evaluated, etc. This chapter contains a few ruleflow examples.</para>
+ which rules are evaluated might become complex. Ruleflow allows the
+ specification of the order in which rule sets should be evaluated by using a flow
+ chart. This allows the ability to define which rule sets should be evaluated in
+ sequence or in parallel and to specify conditions under which rule sets should
+ be evaluated amoungst other functions. This chapter outlines these through ruleflow examples.</para>
<para>A rule flow is a graphical description of a sequence of steps that the
rule engine needs to take, where the order is important. The ruleflow can
- also deal with conditional branching, parallelism, synchonization, etc.</para>
+ also deal with conditional branching, parallelism and synchonization as but an example.</para>
<para>To use a ruleflow to describe the order in which rules should be
- evaluatied, you should first group rules into rulefow-groups using the ruleflow-group
- rule attribute ("options" in the GUI). Then you should create a ruleflow
- graph (which is a flow chart) that graphically describe the order in which the rules
+ evaluatied, rules should first be grouped into rulefow-groups using the ruleflow-group
+ rule attribute (<emphasis>options</emphasis> in the GUI). Then you should create a ruleflow
+ graph (which is a flow chart) that graphically describes the order in which the rules
should be considered (by specifying the order in which the ruleflow-groups should
be evaluated).</para>
<section>
<title>Assigning rules to a ruleflow group</title>
- <programlisting>
- rule 'YourRule'
- ruleflow-group 'group1'
- when
- ...
- then
- ...
- end
- </programlisting>
+<screen>
+rule 'YourRule'
+ ruleflow-group 'group1'
+ when
+ ...
+ then
+ ...
+end
+ </screen>
- <para>This rule will then be placed in the ruleflow-group called "group1".</para>
+ <para>This rule will then be placed in the ruleflow-group called <emphasis>group1</emphasis>.</para>
</section>
<section>
@@ -64,11 +64,10 @@
</mediaobject>
</figure>
- <para>The above rule flow specifies that the rules in the group "Check Order" must be
- executed before the rules in the group "Process Order". This means that only
- rules which are marked as having a ruleflow-group of "Check Order" will be
- considered first, and then "Process Order". That's about it. You could
- achieve similar results with either using salience (setting priorities, but this
+ <para>The above ruleflow specifies that the rules in the group <emphasis>Check Order</emphasis> must be
+ executed before the rules in the group <emphasis>Process Order</emphasis>. This means that only
+ rules which are marked as having a ruleflow-group of <emphasis>Check Order</emphasis> will be
+ considered first, and then <emphasis>Process Order</emphasis>. Similar results could be achieved with either using salience (setting priorities, but this
is harder to maintain, and makes the time-relationship implicit in the
rules), or agenda groups. However, using a ruleflow makes the order of
processing explicit, almost like a meta-rule, and makes managing more complex
@@ -82,8 +81,8 @@
<para>Ruleflows can only be created by using the graphical ruleflow editor which is
part of the Drools plug-in for Eclipse. Once you have set up a Drools project (check
the IDE chapter if you do not know how to do this), you can start adding ruleflows.
- When in a project, use "control+N" to launch the new wizard, or right-click the directory
- you would like to put your ruleflow in and select "New ... Other ...":</para>
+ When in a project, use <emphasis>Ctrl and N</emphasis> to launch the new wizard, or right-click the directory
+ the ruleflow is to be placed in and select <emphasis>New ... Other ...</emphasis>:</para>
<figure>
<title>Ruleflow</title>
@@ -96,14 +95,14 @@
</mediaobject>
</figure>
- <para>Choose the section on "Drools" and then pick "RuleFlow file".
+ <para>Choose the section on <emphasis>Drools</emphasis> and then <emphasis>RuleFlow file</emphasis>.
This will create a new .rf file.</para>
- <para>Next you will see the graphical ruleflow editor. Now would be a good time to
- switch to the "Drools perspective" (if you haven't done so already) - this will tweak the UI so
- it is optimal for rules. Then ensure that you can see the "properties"
- panel down the bottom of the Eclipse window, as it will be necessary to fill in the different
- properties of the elements in your ruleflow. If you cannot see the properties view, open it using
+ <para>Next the graphical ruleflow editor will be visible. Now would be a good time to
+ switch to the <emphasis>Drools perspective</emphasis>, this will tweak the UI so
+ it is optimal for rules. Then ensure that the <emphasis>properties</emphasis>
+ panel down the bottom of the Eclipse window can be seen, as it will be necessary to fill in the different
+ properties of the elements in ther ruleflow. If this cannot be seen, open it using
the Menu Window - Show View - Other ..., and under the General folder select the Properties view.</para>
<figure>
@@ -118,13 +117,12 @@
</figure>
<para>The RuleFlow editor consists of a palette, a canvas and an outline view. To add
- new elements to the canvas, select the element you would like to create in the palette
+ new elements to the canvas, select the element to be created in the palette
and then add them to the canvas by clicking on the preferred location. For example,
- click on the RuleFlowGroup icon in the Component Pallette of the GUI
- - you can then draw a few rule flow groups. Clicking on an element in your ruleflow
- allows you to set the properties of that element.</para>
+ click on the RuleFlowGroup icon in the Component Pallette of the GUI, rule flow groups can then be drawn. Clicking on an element in the ruleflow
+ allows the properties of that element to be set.</para>
- <para>Click on a ruleflow group, and you should see the following:</para>
+ <para>Clicking on a ruleflow group, should bring forth the following:</para>
<figure>
<title>Group properties</title>
@@ -137,22 +135,17 @@
</mediaobject>
</figure>
- <para>You can see here you set the visible name, but you also need to set
- the actual group name that is used in the rules.</para>
+ <para>It can be seen here that the visible name can be set, but the actual group name that is used in the rules also has to be set.</para>
<para>Next step is to join the groups together (if its a simple sequence
- of steps) - you use this by using "create connection" from the component
- palette. You should also create an "End" node (also from the component
- palette).</para>
+ of steps). This can be acomplished by using <emphasis>create connection</emphasis> from the component
+ palette.An "End" node (from the component palette) should also be created.</para>
- <para>In practice, if you are using ruleflow, you will most likely be
- doing more then setting a simple sequence of groups to progress though.
- You are more likely modeling branches of processing. In this case you use
- "Split" and "Join" items from the component pallette. You use connections
+ <para>In practice, if ruleflow is being implemented, this will most likely be to achieve more then setting a simple sequence of groups to progress though; it is more likely that it is being used for modeling branches of processing. In this case the
+ <emphasis>Split</emphasis> and <emphasis>Join</emphasis> items from the component pallette would be used. Connections are used
to connect from the start to ruleflow groups, or to Splits, and from
- splits to groups, joins etc. (i.e. basically like a simple flow chart that
- models your processing). You can work entirely graphically until you get
- the graph approximately right.</para>
+ splits to groups, joins and so forth (like a simple flow chart that
+ models the processing). All work can be done graphically until the graph is approximately correct.</para>
<figure>
<title>Complex ruleflow</title>
@@ -169,16 +162,18 @@
insurance claim processing rule flow. A description: Initially the claim
data validation rules are processed (these check for data integrity and
consistency, that all the information is there). Next there is a decision
- "split" - based on a condition which the rule flow checks (the value of
- the claim), it will either move on to an "auto-settlement" group, or to
- another "split", which checks if there was a fatality in the claim. If
- there was a fatality then it determines if the "regular" of fatality
- specific rules will take effect. And so on. What you can see from this is
- based on a few conditions in the rule flow the steps that the processing
- takes can be very different. Note that all the rules can be in one package
- - making maintenance easy. You can separate out the flow control from the
- actual rules.</para>
+ <emphasis>split</emphasis>. Based on a condition which the rule flow checks (the value of
+ the claim), it will either move on to an <emphasis>auto-settlement</emphasis> group, or to
+ another <emphasis>split</emphasis>, which checks if there was a fatality in the claim. If
+ there was a fatality then it determines if the <emphasis>regular</emphasis> of fatality
+ specific rules will take effect and onwards. What can be seen from this is that the ruleflow steps that the processing takes, can be quite different based on a few conditions.</para>
+<note>
+<para>
+ All the rules can be in one package and sepereated between the flow control and the actual rules, making maintenance easier.
+</para>
+</note>
+
<figure>
<title>Split types</title>
@@ -190,18 +185,12 @@
</mediaobject>
</figure>
- <para>Split types (referring to the above): When you click on a split, you
- will see the above properties panel. You then have to choose the type:
- AND, OR, and XOR. The interesting ones are OR and XOR: if you choose OR,
- then any of the "outputs" of the split can happen (ie processing can
- proceed in parallel down more then one path). If you chose XOR, then it
+ <para>Split types (referring to the above): Once a split has been clicked on, the above properties panel will become visible. The choice of type is then avaliable:
+ AND, OR, and XOR. The interesting ones are OR and XOR: if OR is chosen,
+ then any of the <emphasis>outputs</emphasis> of the split can happen (for isntance, processing can be done in parallel, down more then one path). If XOR is chosen, then it
will be only one path.</para>
- <para>If you choose OR or XOR, then in the row that has constraints, you
- will see a button on the right hand side that has "..." - click on this,
- and you will see the constraint editor. From this constraint editor, you
- set the conditions which the split will use to decide which "output path"
- will be chosen.</para>
+ <para>If either of OR or XOR are chosen, then in the row that has constraints, a button will be on the right hand side that has <emphasis>...</emphasis>. Clicking on this with the mouse pointer will launch the constraint editor. Using this editor, the conditions can be set, which the split will use to decide the <emphasis>output path</emphasis> to be chosen.</para>
<figure>
<title>Edit constraints</title>
@@ -214,9 +203,9 @@
</mediaobject>
</figure>
- <para>Choose the output path you want to set the constraints for (eg
- Autosettlement), and then you should see the following constraint
- editor:</para>
+ <para>Choose the output path the constraints are to be set for (for example,
+ Autosettlement), and then the following constraint
+ editor should become visible:</para>
<figure>
<title>Constraint editor</title>
@@ -231,7 +220,7 @@
<para>This is a text editor where the constraints (which are like the
condition part of a rule) are entered. These constraints operate on facts
- in the working memory (eg. in the above example, it is checking for claims
+ in the working memory (in the above example, it is checking for claims
with a value of less than 250). Should this condition be true, then the
path specified by it will be followed.</para>
</section>
@@ -239,45 +228,42 @@
<section>
<title>Using a rule flow in your application</title>
- <para>Once you have a valid ruleflow (you can check its valid by pressing
- the green "tick" icon in the IDE), you can add a rule flow to a package
- just like a drl. However, the IDE creates two versions of your ruleflow: one containing
+ <para>Once there is a valid ruleflow (validility can be checked by pressing
+ the green <emphasis>tick</emphasis> icon in the IDE), a ruleflow can be added to a package
+ just like a drl. However, the IDE creates two versions of the ruleflow: one containing
the ruleflow definition (*.rfm) and one containing additional graphical information (*.rf).
- When adding a ruleflow to a package, you should make sure that you are adding the
- .rfm file to your ruleflow (and not the .rf file).
- <programlisting>
+ When adding a ruleflow to a package, make sure that it is the .rfm file being added to the ruleflow, and not the .rf file.
+
+<screen>
Reader rfm = ... (rule flow reader, select your .RFM file here)
packageBuilder.addRuleFlow(rfm);
- </programlisting>
+</screen>
</para>
- <para>Alternatively, you can upload the .rf file to the BRMS (as a
+ <para>Alternatively, the .rf file can be uploaded to the BRMS (as a
ruleflow asset) and it will automatically be included in packages that are
deployed from it.</para>
- <para>Ruleflows are only executed if you explicitly state that they should be
- executed. This is because you could potentially define a lot of ruleflows in
- your package and the engine has no way to know when you would like to start
- each of these. To activate a particular ruleflow, you will
- need to start the process by calling the startProcess method on the working memory.
- For example, if you want to start a particular workflow after you have asserted your
+ <para>Ruleflows are only executed if explicitly stated that they should be
+ executed. This is because a lot of ruleflows could potentially be defined in
+ a package and the engine has no way of knowing when each is to be started. To activate a particular ruleflow, <methodname>startProcess</methodname> will need to be called on the working memory.
+ For example, if to start a particular workflow after having asserted the
facts into the working memory, use:
- <programlisting>workingMemory.startProcess("ID_From_your_Ruleflow_properties");</programlisting>
- (The ruleflow id can be specified in the properties view when you click the background canvas of your ruleflow).
- And then call fireAllRules(). This will start executing rules, taking the order specified in the ruleflow into account.
- Thats it !</para>
+<screen>workingMemory.startProcess("ID_From_your_Ruleflow_properties");</screen>
+ (The ruleflow id can be specified in the properties view after clicking the background canvas of the ruleflow).
+ And then call <methodname>fireAllRules()</methodname>. This will start executing rules, taking the order specified in the ruleflow into account.</para>
- <para> You can also start a ruleflow process from within a rule consequence using
- <programlisting>drools.getWorkingMemory().startProcess("ID_From_your_Ruleflow_properties");</programlisting>
+ <para>A ruleflow process can also be started from within a rule consequence using
+<screen>drools.getWorkingMemory().startProcess("ID_From_your_Ruleflow_properties");</screen>
</para>
</section>
<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. How the connections are visualized on the canvas using the connection layout property can also be specified:
<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)
+ <para>manual always draws connections as lines going straight from their start to end point (with the possibility to use intermediate break points)
</para>
</listitem>
<listitem>
@@ -303,35 +289,41 @@
<para>Currently, ruleflow supports eight 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 <property>name</property> 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 <property>name</property> 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>
</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>RuleFlowGroup: represents a set of rules. A RuleFlowGroup node should have one incoming connection and one outgoing connection. It contains a property <property>name</property> 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. </para>
+
+ <note>
+ <para>
+ 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 point.</para>
+ </note>
</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:
+ <para>Split: allows for the creation of branches in your ruleflow. A split node should have one incoming connection and two or more outgoing connections. It contains a property <property>name</property> 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>
</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>
+ <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.</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>
+ <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.</para>
</listitem>
</orderedlist>
-
- </para>
+ <note>
+ <para>
+ At least one of the outgoing connections should evaluate to true at runtime, or the ruleflow will throw an exception if it cannot find an outgoing connection. For example, a connection which is always true with a high priority number could be used to specify what should happen if none of the other connections can be taken.</para>
+ </note>
+ </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 the synchronization of multiple branches. A join node should have two or more incoming connections and one outgoing connection. It contains a property <property>name</property> which is the display name of the node. There are two types of splits currently supported:
<orderedlist>
<listitem>
<para>AND means that is will wait until all incoming branches are completed before continuing
@@ -345,13 +337,19 @@
</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>Milestone: represents a wait state. A milestone should have one incoming connection and one outgoing connection. It contains a property <property>name</property> which is the display name of the node, and the property <property>constraint</property> 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>
</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>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 <property>name</property> which is the display name of the node, and the property <property>processId</property> 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.</para>
+
+ <note>
+ <para>
+ 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>
+ </note>
</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 <property>name</property> which is the display name of the node, and the property <property>action</property> 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>
</listitem>
</orderedlist>
</para>
More information about the jboss-svn-commits
mailing list