Simulating process instance specific order size (dynamic looping)

Well, I'm pretty new in the BPMN world, specially Aris world. Currently I'm developing a free XPDL interpreter so we can use it on systems we are developing inside my company, so I basically read the BPMN standard, but paid special atention to the XPDL standard, since it's what I really need to interprete the BPMN diagram.

I believe the answer is to add a Data Object named something like Order, and than read it's status/state and 2 extended attributes, one with the total number of itens in the order and the other with total itens already processed. Than you map some activities like "Process Order Item" that goes to "Check Order Status" and a decision node, if there still are itens to process, go to POI. I think this would put you on a loop.

Note that in this case, it's supposed that all itens have the same duration, which is a mistake, obviously. But then, you can start to work this logic a bit more until you get all itens processed according to it's type... Remember that Data Objects accept as many extended attributes as necessary, meaning you can make a new attribute for each type and process the sum of those itens.

Did it help?

PS: sorry for my english, I know it's terrible...

Check the XPDL definition:

 

7.1.9.5. DataObject   In BPMN, a Data Object is considered an Artifact and not a Flow Object. It is considered an Artifact because it does not have any direct affect on the Sequence Flow or Message Flow of the Process, but it does provide information about what the Process does. That is, how documents, data, and other objects are used and updated during the Process. While the name ―Data Object‖ may imply an electronic document, it can be used to represent many different types of objects, both electronic and physical. As an Artifact, Data Objects generally will be associated with Flow Objects. An Association will be used to make the connection between the Data Object and the Flow Object. This means that the behavior of the Process can be modeled without Data Objects for modelers who want to reduce clutter. The same Process can be modeled with Data Objects for modelers who want to include more information without changing the basic behavior of the Process. In some cases, the Data Object will be shown being sent from one activity to another, via a Sequence Flow. Data Objects will also be associated with Message Flow. They are not to be confused with the message itself, but could be thought of as the ―payload‖ or content of some messages. Figure 7.2: A Data Object associated with a Sequence Flow In other cases, the same Data Object will be shown as being an input, then an output of a Process. Directionality added to the Association will show whether the Data Object is an input or an output. Also, the state attribute of the Data Object can change to show the impact of the Process on the Data Object.

 

7.1.9.5. DataObject In BPMN, a Data Object is considered an Artifact and not a Flow Object. It is considered an Artifact because it does not have any direct affect on the Sequence Flow or Message Flow of the Process, but it does provide information about what the Process does. That is, how documents, data, and other objects are used and updated during the Process. While the name ―Data Object‖ may imply an electronic document, it can be used to represent many different types of objects, both electronic and physical. As an Artifact, Data Objects generally will be associated with Flow Objects. An Association will be used to make the connection between the Data Object and the Flow Object. This means that the behavior of the Process can be modeled without Data Objects for modelers who want to reduce clutter. The same Process can be modeled with Data Objects for modelers who want to include more information without changing the basic behavior of the Process. In some cases, the Data Object will be shown being sent from one activity to another, via a Sequence Flow. Data Objects will also be associated with Message Flow. They are not to be confused with the message itself, but could be thought of as the ―payload‖ or content of some messages. Figure 7.2: A Data Object associated with a Sequence Flow In other cases, the same Data Object will be shown as being an input, then an output of a Process. Directionality added to the Association will show whether the Data Object is an input or an output. Also, the state attribute of the Data Object can change to show the impact of the Process on the Data Object.

 

7.1.9.5. DataObject In BPMN, a Data Object is considered an Artifact and not a Flow Object. It is considered an Artifact because it does not have any direct affect on the Sequence Flow or Message Flow of the Process, but it does provide information about what the Process does. That is, how documents, data, and other objects are used and updated during the Process. While the name ―Data Object‖ may imply an electronic document, it can be used to represent many different types of objects, both electronic and physical. As an Artifact, Data Objects generally will be associated with Flow Objects. An Association will be used to make the connection between the Data Object and the Flow Object. This means that the behavior of the Process can be modeled without Data Objects for modelers who want to reduce clutter. The same Process can be modeled with Data Objects for modelers who want to include more information without changing the basic behavior of the Process. In some cases, the Data Object will be shown being sent from one activity to another, via a Sequence Flow. Data Objects will also be associated with Message Flow. They are not to be confused with the message itself, but could be thought of as the ―payload‖ or content of some messages. Figure 7.2: A Data Object associated with a Sequence Flow In other cases, the same Data Object will be shown as being an input, then an output of a Process. Directionality added to the Association will show whether the Data Object is an input or an output. Also, the state attribute of the Data Object can change to show the impact of the Process on the Data Object.

 

  7.1.9.5. DataObject In BPMN, a Data Object is considered an Artifact and not a Flow Object. It is considered an Artifact because it does not have any direct affect on the Sequence Flow or Message Flow of the Process, but it does provide information about what the Process does. That is, how documents, data, and other objects are used and updated during the Process. While the name ―Data Object‖ may imply an electronic document, it can be used to represent many different types of objects, both electronic and physical. As an Artifact, Data Objects generally will be associated with Flow Objects. An Association will be used to make the connection between the Data Object and the Flow Object. This means that the behavior of the Process can be modeled without Data Objects for modelers who want to reduce clutter. The same Process can be modeled with Data Objects for modelers who want to include more information without changing the basic behavior of the Process. In some cases, the Data Object will be shown being sent from one activity to another, via a Sequence Flow. Data Objects will also be associated with Message Flow. They are not to be confused with the message itself, but could be thought of as the ―payload‖ or content of some messages. Figure 7.2: A Data Object associated with a Sequence Flow In other cases, the same Data Object will be shown as being an input, then an output of a Process. Directionality added to the Association will show whether the Data Object is an input or an output. Also, the state attribute of the Data Object can change to show the impact of the Process on the Data Object.

 

7.1.9.5. DataObject In BPMN, a Data Object is considered an Artifact and not a Flow Object. It is considered an Artifact because it does not have any direct affect on the Sequence Flow or Message Flow of the Process, but it does provide information about what the Process does. That is, how documents, data, and other objects are used and updated during the Process. While the name ―Data Object‖ may imply an electronic document, it can be used to represent many different types of objects, both electronic and physical. As an Artifact, Data Objects generally will be associated with Flow Objects. An Association will be used to make the connection between the Data Object and the Flow Object. This means that the behavior of the Process can be modeled without Data Objects for modelers who want to reduce clutter. The same Process can be modeled with Data Objects for modelers who want to include more information without changing the basic behavior of the Process. In some cases, the Data Object will be shown being sent from one activity to another, via a Sequence Flow. Data Objects will also be associated with Message Flow. They are not to be confused with the message itself, but could be thought of as the ―payload‖ or content of some messages. Figure 7.2: A Data Object associated with a Sequence Flow In other cases, the same Data Object will be shown as being an input, then an output of a Process. Directionality added to the Association will show whether the Data Object is an input or an output. Also, the state attribute of the Data Object can change to show the impact of the Process on the Data Object.

Assuming you are referring to process simulation with ARIS Business Simulator (ABS), I can give the following advice:

With BPMN models I don't think it will be possible to create a simulation model which behaves the way you want. Mainly because ABS does not support the loop attributes of BPMN activities at the moment.

With EPCs you can use ERM attributes to model a loop as you described. There are some hints about this in the ARIS help system. (IIUC this should be the same as what you refer to as ERD attributes. But when souring the help system you will have more luck with the term "ERM".)

Basically you set the initial value of such an ERM attribute by connecting it with a "has output of" connection to a function and using a ":=" operator. When setting the value you can also specify a probability distribution for the operand.

Then you model a loop in the process flow using an XOR rule with two following events. You can connect the ERM attribute with "is compared to" connections to the events and in the events you can define conditions for the activation of each event or path respectively. (Check the help system for the exact attributes to be maintained.)

Now, the conditions allow you only to check for fixed values, e.g. "greater than zero". But you can influence the value of the ERM attribute (which actually becomes a part of the token being routed through the process). With a "has output of" connection within the loop you can, for example, decrement the value of the ERM attribute by 1. If you add such a construct, the simulation should execute the loop as many times as the initial value of the ERM attribute was and then exit through the event with the opposite condition, which could e.g. be "less or equal to zero".

In case this description was too confusing, you can check a picture of such a setup in the help system. The respective entry is titled "Example: ERM attribute conditions".

Dear

I am interested to know the current issues in transformation of BPMN to BPEL, If anyone has updated stuff on it please write...............

Dear

I am interested to know the current issues in transformation of BPMN to BPEL, If anyone has updated stuff on it please write...............

Pablo, I like the elegance of the Data Object approach you descirbed.  It would provide a means for discussing how the looping would work with the business subject matter experts that would then translate directly to the simluation. 

Ralph, did I interpret your post correctly -- that Business Simulator doesn't yet support reading those Data Objects during the simulation?  I have been experimenting with the ERM attributes (sorry about the typo, I've had a number of discussions lately about Entity Relationship Diagrams - ERD's and I mixed the terms), and coming to similar conclusions as yours.  The challenge now appears to be two-fold: (1) mixing BPMN and EPC model types in a single simulation (which I hear is doable, but possibly challenging); and (2) incurring the modeling burden of creating and maintaining ERM attributes for every loop in my process model.

Thanks again for the help!

Regarding Data Objects, you are right, they are not supported by ARIS Business Simulator.

Regarding the simulation of BPMN and EPC models, this is not possible at the moment. If it were, then it would be a bug. We decided not to allow this yet because we haven't had the time to exhaustively define the transitions between the respective model types during process execution.

Thanks for the confirmation, Ralf -- I quit trying to make EPC and BPMN models work together in the Business Simulator! 

On a related note, I have succeeded in creating an EPC model that creates the behavior I was looking for (dynamically sets order size, and then loops through activities based on the number of line items in the order), however, I have only been able to get it to work in Business Simulator as a single EPC model (monolithic).  When I try to break it into smaller models related to each other with assignments, I get an error when starting Business Simulator that says "Server Access: Assigning model 'model name1' to model 'model name 2' does not comply with established modeling guidelines". 

I'm not working on a server with this particular set of models, so I think the "Server Access" part of this is probably not relevant (maybe a bug?).  Is there some other approach to linking EPC models that I should be using so that I can run Business Simulator on multiple related models, or is this perhaps a design constraint of Business Simulator?

The general guideline for modeling an assignment for a function in an EPC is to include occurrence copies of the event just before the function and the event just after the function in the EPC to be assigned. So these events become the start and end event respectively of the EPC detailing the function. If the assignment is modeled like this, ABS should be able to include the assigned EPC in the simulation and find the path from the upper-level process to the lower-level one and back again.

In your case it seems that the assignment is not modeled like it is described above. This is at least what the error message seems to indicate.

What I did not quite understand was your remark about the models mentioned in the error message not being present on the server. Does it really mean there are no models with the mentioned names available?

Anyway, if you keep having trouble with process assignments, you can send me the ARIS database with the offending models and I'll take a look at them. Alternatively (I'm not sure if sending it through the community is possible.) you can send it to ARIS Support and tell them to forward it to me. A third option would be that I send you a database with a "template" of how a process assignment should be modeled. Just let me know what's easiest for you.