SimonRinguette / bpswg

Automatically exported from code.google.com/p/bpswg
0 stars 0 forks source link

Sandboxing - lag time from different incoming flows #70

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
When an activity have multiple incoming flows, it's expected that are different 
lag times depending on the source. I mean If the flow comes from the back 
office it can take 2 days to start looking at it, if it comes from the customer 
portal it takes 1 day. How to address this?

Original issue reported on code.google.com by bpm....@gmail.com on 2 Mar 2012 at 11:14

GoogleCodeExporter commented 9 years ago
Assuming that you are using the term Lag Time as intended in the current 
specification,
you would simply assign a different Lag Time parameter to each of the sequence 
flow. In your example the sequence flow coming from backoffice would be 
assigned a value of 2 days. Assuming this time is constant from instances to 
instances.  If this lag time varies from instances to instances that you could 
assign to a distribution parameter.

Original comment by dga...@trisotech.com on 2 Mar 2012 at 3:19

GoogleCodeExporter commented 9 years ago
Interesting idea allowing a Time parameter on a sequence flow to provide for 
this behavior, a previous ISSUE 54 concerning parameters and where they are 
applied suggest sequence flows can't have time parameters.

Alternatively a Task could be inserted on each of the sequence flows....to 
accomodate the lag time.

Original comment by ghoo...@gmail.com on 12 Mar 2012 at 10:33

GoogleCodeExporter commented 9 years ago
Shouldn't the Lag time be applied to the Activity (or a added Intermediate 
Timer Event... but that would mean altering the model), rather than to the 
Sequence Flow? Per BPMN, unless I'm mistaken, Seq. Flows are assumed to be 
instantaneous.

Original comment by razvan.r...@wwhc.us on 15 Mar 2012 at 2:52

GoogleCodeExporter commented 9 years ago
In fact sequence can have time parameters as was discussed in Paris. (Issue 54 
is erroneous and will be commented appropriately).

As per execution semantic of BPMN 2.0 spec section1 3.2.1 

Start quote:
Token movement across a Sequence Flow does not have any timing constraints. A 
token might take a long or short time
to move across the Sequence Flow. If the isImmediate attribute of a Sequence 
Flow has a value of false, or has
no value and is taken to mean false, then Activities not in the model MAY be 
executed while the token is moving along
the Sequence Flow. If the isImmediate attribute of a Sequence Flow has a value 
of true, or has no value and is
taken to mean true, then Activities not in the model MAY NOT be executed while 
the token is moving along the
Sequence Flow

end quote.

Original comment by dga...@trisotech.com on 15 Mar 2012 at 8:24

GoogleCodeExporter commented 9 years ago
Closed Sept 20 Web Conference

Original comment by sringue...@trisotech.com on 20 Sep 2012 at 7:40

GoogleCodeExporter commented 9 years ago

Original comment by sringue...@trisotech.com on 20 Sep 2012 at 7:40

GoogleCodeExporter commented 9 years ago

Original comment by sringue...@trisotech.com on 24 Oct 2012 at 7:02