Bonita v2 Series: Part Two

This is part two of a trilogy on Bonita v2. Before explaining how Bonita workflow implements iterations, we'll introduce some basic Bonita concepts to help the user understand: Activity types, activity life cycles, and transitions between activities.

This is part two of a trilogy on Bonita v2. Be sure to read part one.

1. Introduction

What is an iteration?


An iteration, which can be also called a cycle or loop, consists of executing one or more activities that have already been previously executed.

Types of cycles

As van der Aalst introduces in his thesis Workflow Patterns, we can talk about two different groups of iterations: Structured cycles and arbitrary cycles.

  • Structured cycles: When a loop has only one entry and one exit point. (See Figure 1)

Figure 1 - Example of a structured cycle

  • Arbitrary cycles: A non-structured (arbitrary) cycle may have several entry points and/or several exit points within the cycle; in another words, it doesn't have a predefined number of entry and exit points. (See Figure 2)

Figure 2 - Example of an arbitrary cycle

Introduction to Bonita workflow

Before explaining how Bonita workflow implements iterations, we'll introduce some basic Bonita concepts to help the user understand: Activity types, activity life cycles, and transitions between activities.

Activity basics

In Bonita, the activity is the basic unit of work within a process.

Execution of an activity is either automatic or manual:

  • Automatic: The BONITA enactment engine executes the activity when applicable transitions from preceding activities are successfully evaluated.
  • Manual: The BONITA enactment engine will not start a manual activity until some application has explicitly started it thru the user API.

The life cycle of an activity is as follows:

Figure 3 - Activity life cycle

Activity States:

  • Ready: This is the state of an activity ready to start. There are two possible situations for this state to occur. In the first, an activity has no parent activity (this is the first activity of the workflow process). In the second situation, a normal activity has parent activities that have all terminated successfully, and whose transition condition(s) to the activity has been successfully evaluated.
  • Initial: This is the state of an activity waiting for some processing to complete before being ready to run. In the case of normal activities, at least one of the parent activities is still executing.
  • Executing: An activity in execution.
  • Dead: A cancelled activity. All dependent activities are automatically cancelled. Cancellation occurs in two cases: Explicit cancellation, or unsuccessful evaluation of an inner transition condition.
  • Terminated: An activity that has terminated successfully.

Figure 3 is a simplified version of Bonita's activity life cycle. It doesn't include anticipable activities feature.

Transition between activities

Most of the usual transition patterns can be achieved using Bonita. There is no special node to achieve these patterns; rather, any activity can act as a routing node.

The transition pattern is determined according to the type of the activity, which can be AND-JOIN (also known as "synchronize join"), or OR-JOIN (also known as "asynchronous join").

The transition pattern is also determined from the number of outgoing edges in an activity; this is the SPLIT construct (this allows several activities to execute in parallel). This is not a specific type of activity; if there are several outgoing nodes from a given activity, it is a SPLIT construct.

The usual patterns are summed up below in Figure 4, where the activity controlling the pattern is shown in blue, with the type of the activity shown beside.

The SplitAct (split activity) allows two parallel activities to start. This is achieved by having two outgoing edges, one to P1Act activity, and one to P2Act activity.

The SyncAct (synchronous activity) is type AND-JOIN. It executes only when both P1Act and P2Act are in the terminated state. If one of those activities is cancelled, then SyncAct is also cancelled.

The AsJoinAct (asynchronous activity) is of type OR-JOIN. It executes whenever either P1Act or P2Act are terminated. If both of these activities are cancelled, then AsJoinAct is also cancelled.

Figure 4 - Activity transitions

Transition patterns can be refined by defining conditions on edges between activities. A condition operates on the value of a property of the activities, and is expressed in Java. Any string that can be the operand of an "if"statement is valid. Assuming that the property "Prop" is defined for a given activity, any of the following constructs is a valid condition:

(Prop.indexOf("SomePart") == 2)
(Prop.lenght() == 9)
(orderType.equals("PO")) && (new Integer(Qte).intValue() > 100)

For more information related with Bonita workflow read the BonitaAPI documentation.

Iterations in Bonita v2

After the above overview of the basic concepts of Bonita activities and their transitions, it is time to talk about iterations in Bonita v2. Iterations are implemented as a special transition with a condition that permits looping to a previous activity while the condition evaluates to true. This means that in Bonitan iterations are defined explicitly during the workflow definition.

In order to set an iteration in Bonita three parameters are needed:

  1. From: The name of the activity that starts the iteration
  2. To: The name of the first activity that will be re-executed if the condition evaluates to true
  3. Condition: A Java condition to iterate (evaluate)

Figure 5 - Representation of an iteration in Bonita workflow

The condition is related in Figure 5 to the value of the property "someProp." This property is bound to the activity second, either directly (it is an activity property), or because it has been defined at the process level (it is a project property).

Processing an iteration

Assuming in Figure 5 that First and Second activities have been executed successfully at least once and the iteration condition is evaluated to true, then the iteration is performed. The next three steps are as executed as follows:

  1. All activities and transitions inside the iteration are set to initial state. The first activity of the iteration (activity First) is set to ready state if it is a manual activity or starts execution if it is an automatic activity. After that the process continues its execution as usual.
  2. After setting the activities inside the iteration to initial state, these activities are checked to see if any of them require a state other than initial. We will explain this subject further in the next chapter: Working with multiple entry points.
  3. Also, activities that contain multiple exit points that are outside the iteration are set to initial to be able to access them in the next loop if necessary. This point is explained in more detail in the next chapter: Working with multiple exit points.

After processing these three steps our process is ready to re-execute all those activities that were inside the iteration. Activities that are outside the iteration but depending on activities inside the iteration are also enabled. This permits Bonita v2 to exit an iteration whenever we want. This point is clarified later in Persistence data and iterations.

A graphical example when processing an iteration is shown in Figures 6 and 7:

Figure 6 - Before processing the iteration between node6 and node1 activities

Figure 7 - After processing the iteration

In Figure 6, before processing the iteration, the activity states are:

  • In terminated state: node0, node1, node3, node4 and node5. These activities are already executed.
  • In ready state: node6 activity.
  • In initial state: node7 activity.
  • In dead state: node2, node8 and node9. These activities have been cancelled because the transitions to node2 and node8 were evaluated to false.

We can see in Figure 7 that, after processing the iteration, node1 activity is in ready state and the other activities have been set to initial state. With this change all previously executed and cancelled activities are enabled again.

New iteration features

Several new features have been added with the new iteration's behaviour. Now BonitaV2 supports:

  • Structured and arbitrary cycles
  • The possibility to leave from an iteration whenever we want (elimination of the previous standby mode in the previous Bonita v1 series)
  • Iterations inside iterations
  • Multiple iterations beginning in the same activity
  • Crossed cycles

Examples of all these designs are introduced in Chapter 3: Other examples supported by BonitaV2

In chapter 2 the Approval Workflow example used in the first article of the Bonita trilogy is used as a practical sample to reinforce the iteration concepts. After that, some cases of multiple entry/exit point from an iteration are analyzed.

Persistence data and iterations

One of the major achievements in Bonita workflow is that all data, including both workflow relevant data and workflow internal states, are persisted throughout the process execution. This means that whenever an activity modifies its state this change is saved in the Bonita database along with any information or data that this activity manages.

The persistence mechanism and other services such as security, email, JCA connectors or event notifications are automatically managed by the application server in which the Bonita engine is running. This approach has many benefits in terms of Quality of Service. This also permits the end client workflow application to deal directly with any other API requests for workflow definition or execution.

A good introduction to the Quality of Services provided by an EJB container can be found at

As discussed above, distributed applications using EJBs wisely and appropriately may benefit from several (declarative or programmatic) qualities of services that the EJB container provides. These qualities of services include distributed transactions, role-based authentication and life cycle management. Conversely, applications that use EJBs inappropriately may end up with increased complexity and possibly significantly reduced performance.

As you can see in the previous abstract, the use of EJBs could have a negative impact if not used appropriately. In order to avoid these problems in Bonita we have been working with the JOnAS application server team to properly configure and tune those services within Bonita. Obviously these configurations could be adapted to other application servers.

Beginning on this premise, we have arrived at a point to start an iteration and re-execute some activities. We might ask ourselves: What happens to the information previously persisted in those activities that we want to re-execute? Should we roll back all persisted changes until the first activity is ready to re-execute? There are multiple solutions to solving this problem. The solution proposed in Bonita is to reset the state of all activities involved in the iteration but, at the same time, do not modify any project or activity properties. These changes permit re-execution on one hand of the activities inside the iteration, and on the other hand maintain the same properties values that could help us to determine some values. For example: An iteration count value, or who has taken part within each iteration (activity or person).

Another conflicting point exists where iterations are involved. As mentioned before, if we work with arbitrary cycles, it is possible to have multiple iteration exit points. In this case, we could iterate and leave the iteration at the same time. But by analyzing what that means we understand that performing both actions doesn't make sense because we are trying to continue executing our process through a path where, at its starting point, we want to execute it again.

How Bonita manages iterations and persistence

In Bonita we have decided that during the execution of an iteration we cannot leave the iteration and continue iterating at the same time. To guarantee the correct definition of the process models, some guidelines (GL) related to iterations have been defined. Also, a new API function, checkModelDefinition(), is added to check our process model.

Following are the iteration guidelines for a correct design of our process model:

Premise: It is not possible to continue execution inside iterations and exit at the same time.

  1. Only a single iteration is allowed between two connecting nodes.
  2. It's possible to have multiple iterations starting in the same node.
  3. All exit transitions from a node starting the iteration must meet a condition. If there is more than one exit transition from that node, all transitions must meet a condition.
  4. If there are multiple exit points within the iteration it is strictly necessary to have conditions on all the transitions exiting from that node. The conditions must be mutually exclusive for those conditions to take a path to either continue iterating or to exit from the iteration.

To clearly understand these guidelines the next chapter shows how to apply them in the Approval Workflow example.

2. Working with iterations in Bonita V2

Approval iterating workflow example

As seen in the first part of the Bonita trilogy, we will improve on the Approval Workflow example with an iteration.

In the Approval Workflow example in Figure 8 below we assume that in the Approval activity, the person validating the user request makes the decision that the information received is not correct or incomplete and can request the user to modify or re-enter his or her demand. In this case, an iteration is used to return from the Approval activity to the Request activity requesting the information again. For this reason, in this example, it makes sense to explicitly design the activity Request to be able to re-execute it (remember that in the first example this activity wasn't designed this way because it was a part of the workflow instance).

In this new example of the Approval Workflow process with iterations, properties are defined at activity level instead of at the process level. This requirement is due to the fact that now the person who approves the request can ask for more information. Activity properties are used to exchange the information between Request and Approval activities.

Figure 8 - Approval Workflow example

Approval activity sets the decision node property with three possible values: grant, reject, or change_request, in order to: Accept the request, reject it, or to ask for more information from the user making the request. This process model is an example that follows the iteration guidelines because it uses the decision property as an exclusive choice. Iteration occurs based on the decision property value. The result of the decision is to iterate or not but it is impossible to take both paths at the same time.

Approval iterating workflow CODE

This example is located at:

  • Folder: $BONITA_HOME/src/bonitaStandAloneClient/src/
  • Package:

package client.Java_client;

import hero.client.test.SimpleCallbackHandler;

import hero.interfaces.*;

import java.util.*;

public class ApprovalIteratingWorkflow {
 static public void main(String[] args) throws Exception{
  char[] password={'t','o','t','o'};
  SimpleCallbackHandler handler = 
   new SimpleCallbackHandler("admin",password);
  LoginContext lc = new LoginContext("TestClient", handler);
  ProjectSessionHome projectSessionh = ProjectSessionUtil.getHome();
  ProjectSession pss = projectSessionh.create();
  // Set activities
  pss.addNode("Request", Constants.Nd.AND_JOIN_NODE);
  pss.addNode("Approval", Constants.Nd.AND_JOIN_NODE);
  pss.addNode("Acceptance", Constants.Nd.AND_JOIN_AUTOMATIC_NODE);
  pss.addNode("Reject", Constants.Nd.AND_JOIN_AUTOMATIC_NODE);
  // Set node properties
  pss.setNodeProperty("Request", "User_name", "", true);
  pss.setNodeProperty("Request", "Phone_number", "", true);
  pss.setNodeProperty("Request", "Email_address", "", true);
  Collection applications = new ArrayList();
                                                 "Available_applications", applications);
  pss.setNodeProperty("Request", "Available_applications", "application1");
  Collection possible_decision = new ArrayList();
  pss.setNodePropertyPossibleValues("Approval", "decision", possible_decision);
  pss.setNodeProperty("Approval", "decision", "change_request", true);
  // Set transitions
  pss.addEdge("Request", "Approval");
  String approval_acceptance = pss.addEdge("Approval", "Acceptance");
  String approval_reject = pss.addEdge("Approval", "Reject");
  pss.setEdgeCondition(approval_acceptance, "decision.equals("grant")");
  pss.setEdgeCondition(approval_reject, "decision.equals("reject")");

  // Set iterations
  pss.addIteration("Approval", "Request", "decision.equals("change_request")");

  // Set hooks
                        hero.interfaces.Constants.Nd.BEFORETERMINATE, Constants.Hook.JAVA);
                        hero.interfaces.Constants.Nd.BEFORETERMINATE, Constants.Hook.JAVA);
  // Set activity roles
  pss.addRole("Administrator", "The system administator role");
  pss.setNodeRole("Request", "Administrator");
  pss.setNodeRole("Approval", "Administrator");
  // Set role mapper
  pss.addRoleMapper("Administrator", "AdministratorMapper", Constants.Mapper.PROPERTIES);
  // Check the defition model

How to execute the Approval iterating workflow example

To test the example it's assumed you have installed the latest version of Bonita v2. If you haven't done so you can try installation by following the Bonita Installation instructions.

This Bonita version executes under the JOnAS application server. This means JOnAS is required on your system. In our case study we have used the latest release version of JOnAS 4.7.x. (x = latest JOnAS version in general use.)

Once the JOnAS and Bonita programs are properly installed and configured, if we follow the instructions below we are ready to deploy and run our example.

First launch the JOnAS server with: JOnAS start.

The next step is to deploy our client application into our server. To do that:

  • Change the directory to: $BONITA_HOME/src/bonitaStandAloneClient
  • Execute the ant task: ant deploy_approval_iterating_java

To test the example we will use two sample applications included with Bonita package: Activity Manager and Formgenerator.

Through the Activity Manager included with Bonita we can instantiate the processes and start and terminate the activities. Now we will use this program to see the state changes of the process activities during the execution of our example.

To launch the manager:

  • Execute the ant task in the BONITA_HOME: ant manager
  • Log into the application with: admin/toto

In the Project List of the program we should see our example deployed:


To execute the example we will use the formgenerator application. Formgenerator allows Bonita workflow system end-users to instantiate a project or to start an activity bound to a process. It does this by filling a form with the values corresponding to the project or activity properties. We use the formgenerator to set our request parameters and to select the approval decision. This allows us to play with the iteration functionality.

To launch the formgenerator app and start a new instance of the example:

  • Open your browser and access the link: http://localhost:9011/formgenerator (Note that port 9011 is the default port)
  • Select the option: User's Instanceable Models
  • Click over Approval_iterating_workflow to create an instance of our example process
  • Click over the instance name: Approval_iterating_workflow_instance1491
  • Select to start the first activity of our example: Request

Combining both formgenerator and Activity Manager applications, our desktop could look something like this:

Figure 9 - Approval iteration workflow using Activity Manager and Formgenerator applications (I)

Note the process activities appear in the top left window. At the beginning only the first activity appears ready for execution. During the workflow execution other activities will appear.

After filling out our request we click the submit button that starts and terminates the Request activity. Then we select to execute the next activity (Approval) in the browser.

Figure 10 - Approval iteration workflow using Activity Manager and Formgenerator applications (II)

In this figure the important field is the property decision where we can select:

  • grant: To accept the request and execute Acceptance automatic activity.
  • reject: To reject the request and execute Reject automatic activity.
  • change_request: That returns to Request activity after submission.

If grant option is selected, then this sentence appears in our command window:

  • send mail accept OK during the Acceptance execution

If reject option is selected, then the following sentance appears:

  • send mail rejection OK during the Reject execution

A user's guide with more information related to the Activity Manager application can be found at

Some extra information related to the Formgenerator Web application can be found at

After reviewing this simple example introducing us to the iteration concepts, two more concerns relating to iterations are revealed: Multiple exit points and multiple entry points in iterations.

Working with multiple exit points

As seen in the introduction of this document, when we work with arbitrary cycles we can have more than one exit point in our iterations. For example, in the previous example of the approval workflow, it had two possible iteration exit points: One exits to Acceptance activity and another exits to Reject activity.

But why is it important to be careful with multiple exit points? The reason is, if iteration guidelines are not closely followed, it is easy to enter into a Bad_transition state. Figure 11 below shows this problem:

For this example assume the following:

  • 5 activities: Initial, Middle, Iterator, Final and Parallel
  • 1 property: Repeat when the value equals YES
  • Initial and Middle activities have been executed
  • Parallel activity has started its execution because there isn't any condition that controls its execution
  • Iterator activity is now executing and it's going to terminate
  • Final activity is still in the initial state

Figure 11 - Incorrect Iteration with multiple exit points I

Now, when Iterator activity detects that it has to iterate (because iteration's condition is true), all activities inside the iteration are re-evaluated and, in the normal case, set to initial. Explained in the next chapter is that if we have multiple entry points in our iteration some activities and transitions inside the iteration could be set to a state other than initial.

Activities that are exit points from the iteration (like Parallel activity) are also set to initial state if they are in dead state (that means that they have been previously cancelled in order to not exit the iteration). In our example activity Parallel is in executing state so it is not reset to initial state.

As in the Bonita v1 series, the first activity of the iteration is set to ready and, if it is an automatic activity, launched into execution.

After processing the iteration, the following schema is present:

Figure 12 - Incorrect Iteration with multiple exit points II

With the schema in Figure 12 it is easy to see that after terminating Middle activity for a second time a Bad_transition state exception is raised when the Bonita engine tries to set Parallel activity to the ready state because Parallel is still in the executing state (even in terminate if it terminates before).

What we propose is that it doesn't make sense to continue iterating and leave the iteration at the same time. We understand that if you arrive at this situation you can design your process in another way to avoid this conflict.

So this is the reason for the guideline premise proposed earlier: It is not possible to continue execution inside an iteration and leave it at the same time. Following this premise guarantees the correct execution of our process.

Using the example above in Figure 12, if we want to iterate several times and at the end, for some reason, leave the iteration thru Parallel activity, a possible solution could be to use another property as a condition in our model either to continue iterating or to leave the iteration. In Figure 13 below a property named execute_parallel is used for this purpose:

Figure 13 - Correct Model with multiple exit points

The design in Figure 13 follows the iteration guidelines.

Working with multiple entry points

Figure 14 introduces the multiple entry point concept. Activities A, B, and C are outside the iteration and they interact with an activity that is inside the iteration:

Figure 14 - Iterations with multiple entry points

In Figure 14, iteration occurs only if the four conditions are true (cond1, condA, condB and condC), and if the iterate condition is also true.

In the second iteration, activities A, B and C are not executed again because they are not inside the iteration. condA, condB, and condC conditions have the same value in the second iteration as they had in the first iteration.

Also, due to node 2 being an AND_JOIN, if one of the conditions is false (condA, condB, condC or cond1) then a CANCEL operation is performed for node 2 and propagated thru node 3 and 4. This effect is shown in the next figure where the transition from B to 2 is evaluated to false:

Figure 15 - AND_JOIN example propagating a cancel

In the Figure 15 example, after propagating cancel thru the activities no iteration is possible.

Figure 16 below shows the same example using an OR_JOIN activity for node 2.

Figure 16 - OR_JOIN example with multiple entries

In Figure 16, node 2 is able to start when ONE of its incoming edges becomes true. This concept is important because we could execute node 2 before executing node 1. An example of this case is shown in the Figure 17:

Figure 17 - OR_JOIN example before iterating

As you can see in Figure 17, node 2 is in ready state even if node 1 has not executed. If we continue executing this process terminating node 2 and node 3 activities and iterate property is set to true then a check is made to know the new state of node 2:

  • If condA, condB, and condC, are false, the new node 2 state is set to initial.
  • If one or more of condA, condB or condC is true, the new node 2 state is set to ready.

Cond1 doesn't matter in node 2 state evaluation, because this transition condition is inside the iteration and is previously set to initial. It is re-evaluated after node 1 execution.

So, assume that in this case condB is true, after node 3 termination and processing the iteration, node 1 and 2 will be ready to execute: node 1 is enabled by the iteration and node 2 is enabled by condB.


In the Figure 18 example, after terminating node B and processing the iteration, node 2 is automatically executed: because condB is evaluated to true and because Node 2 is type OR-JOIN it is not necessary to evaluate the other conditions.

Then, having executed activity B and 2, if activity 3 is started and terminated and iterate property is set to true enabling the iteration, Bonita's behavior is as follows:

  • Activity and transition states of nodes 1, 2 and 3 are initially set to initial state.
  • Activity 1 state is set to ready due to the iteration.
  • Activity 2 is automatically executed again because condB is true and it is an automatic activity. This execution is done before being able to execute node 1, which means that in this case node 2 is executed before node 1.

If we execute activity 1 after the automatic execution of node 2, activity 2 will not execute again.

Similar to this case is when we have an AND_JOIN_AUTOMATIC: if one of the outside transitions is evaluated to false, a cancel operation is raised over the activity inside the iteration and propagated thru the activities connected to it.

To play a little bit with these examples you can try to execute the example found at $BONITA_HOME/src/main/client/hero/client/samples/iterations/src/


It's important to pay special attention when modeling our process and we're working with iterations with multiple entry and exit points. This is especially true if we have automatic activities in order to prevent the following undesired situations:

  • Leaving the iteration thru one path and then continue iterating by another path. We arrive in a bad transition state when we want to leave the iteration thru the same path a second time.
  • To have more than one activity inside the iteration in ready state after the iteration.
  • To have some activities that are directly executed just after the iteration due to them being automatic and have some entry point that enables its execution.

3. Other examples supported by Bonita V2

Hereafter there are some examples using iterations in Bonita V2:

The source code of these examples can be found at: $BONITA_HOME/src/main/client/hero/client/samples/iterations/src.

To install them use the build.xml in .../samples/iterations folder.

To execute the models you can use the applications commented in the previous chapter: the Activity Manager or the Formgenerator.

  • An iteration inside another iteration: ""

The goal of this example is to design iterations within iterations. Figure 19 shows a basic case:

Figure 19 - Nested iterations

Two properties (cond1 and cond2) are used to control when we have to continue iterating and when not to iterate.

  • Several iterations starting in the same activity: ""

This example shows that we can have more than an iteration starting in the same node.

Note: Only ONE iteration is allowed between two connected nodes.

Figure 20 - Several iterations in the same activity

In the Figure 20 example path property is used to control which path is taken.

Use Formgenerator application to run this model and to choose a path value.

  • Embedded iterations: ""

The goal of this example is to demonstrate arbitrary cycles within our model.

This example is taken from

Figure 21 - Embedded iterations

In Figure 21 example D and E nodes generate a random number in a BeforeTerminate hook. Then, condition rnd is evaluated to determine whether to iterate or continue with the next activity.

  • Abort schema: ""

The example in Figure 22 shows how we can abort all the activities inside our process at the same time. Figure 22 shows a process where some activities can be started after the execution of Start activity. The main idea is that if one those activities (A1, A2, B1 and B2) decide to leave thru the Abort activity the whole process is reset to initial state because all the activities and transitions are inside the iteration.

An Abort activity must be defined as OR_JOIN (automatic or not) to abort on a condition from any node.

The activity reset takes place after the execution of Abort activity.

Figure 22 - Abort schema

Use the Formgenerator application to run this model and to set abort condition to true/false.

It is important to note that the activity starting the iteration is an OR_JOIN. In this case it's easy to break the GL premise and exit from the iteration for one side (from A1 to A2 in Figure 23) and continue iterating at same time by another (from B1 to Abort). This causes us to enter into a Bad_transition state. An example of this showing a wrong definition model is Figure 23:

Figure 23 - Wrong Model for Abort schema

Imagine in Figure 23, Start, A1 and A2 activities have executed and are in terminate state. Then activity B1 starts and decides to abort the operation by setting abort property to true and exits to Abort activity. After the execution of Abort activity, the iteration logic is processed and activities A1 and B1 are set to initial state but A2 activity remains in terminated because it is outside the iteration. In this case an exception is generated if we try to execute A2 again.

  • Rolling back schema:

This schema shows how we can roll back over the activities of our process using iterations.

Figure 24 - Roll back schema

Note: this configuration could be merged with the previous examples such as iterations inside iterations, or starting several iterations in the same node. With that in mind, we could roll back from an activity to all the previous ones as shown in Figure 25.

Figure 25 - Roll back schema II


This document is intended to be a practical introduction for those new to iterations within a workflow environment, and at the same time, present advanced iteration cases we hope are useful for those already familiar with iterations. Our goal is to encourage all readers to review and execute the examples presented within the document and especially those readers making their first steps into iterations and workflow processes.

We also propose that the solutions and guidelines for defining and using iterations in a workflow system described in this document will help you in developing better designs for use in your workflow platform, especially those concepts related to the relationship between data persistence and the iteration set.

Of course, any constructive feedback is welcome. You can contact the Bonita team and participate within the Bonita community at the mailing location "". The Bonita team wishes to thank you for taking your time to read this document and we hope you find it useful.

Have fun and enjoy your life!



About the author

Jordi Anguela Rosell is an Engineer working with Bull S.A.S, in the 'Bull Service Oriented Architecture' division. The mission of this division is to provide an integrated middleware platform to Bull customers. Previously, Jordi worked in Spain in multiple J2EE project developments. Jordi is actually committing for the Bonita open source project. He lives in the southeast of France.

Special Thanks

To Miguel Valdés and the rest of the Bonita team for their excellent job and trusting in me to carry out this work. To JOnAS team for giving us their support. To Roger Perey for the document reviews and dedication. And to finish, I also want to thank my family for their unconditional support.

Dig Deeper on Java web services and SOA

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.