I am unclear as to whether it is permissible in a BPMN 2.0 model for a timer to be the Start Event for an event sub-process, such as in the simplified example below:
The BPMN 2.0 documentation (version 2.0.1 dated 2013-09-02) on page 174 (section 10.3.5, Event Sub-processes) suggests this is not permissible:
The Start Event of an Event Sub-Process MUST have a defined trigger. The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error,
Escalation, Compensation, Conditional, Signal, and Multiple(see page 259 for more details)
On page 241 (section 10.5.2, Start Event), the specification states that a Timer is allowed as a Start Event:
A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation, Conditional, Signal, Multiple, and Parallel.
Which of these sections would apply in the case of the above example?
Not a BPMN expert but have some experience using BPMN 2.0 so I'll give this a go.
The example you posted doesn't look like a completely spec-approved way of doing it, but I can't be entirely sure. I see a few different ways to do this that should be within bounds.
Here are my two suggestions:
Unless you want to model a third event like "Out of stock" I would prefer option A for its simplicity.
Also I'd like to through out a recommendation for "BPMN Method and Style, 2nd ed." by Bruce Silver.
I'm going to conclude this is almost certainly an error in §10.5.2 of the spec, and that the timer as the start event in an event sub-process is allowed.
Tables 10.86 and 10.93 are both explicit in that the timer can be the trigger for an event sub-process.
The non-interrupting timer start event is only useful in an event sub-process. That symbol would have no use if a timer event were not allowed to trigger an event sub-process.
Section 10.5.6 consistently allows the use of the timer as the start event trigger
The issue was reported to OMG in 2010 (Issue 15532), although no further action was taken.
The same principle applies to Parallel Multiple events, which are similarly omitted from the same list in §10.5.2, but permitted in other sections.
I don't remember now the terminology, but what I would do to achieve what you want is put purchase parts + unpack parts in a subprocess (or sub-task?) and have a timer on it. This seems easier, clearer to read and does what you want.
Regarding documentation: I would say one part talks about the trigger and the other about the start of the event sub-process. So a timer can't trigger the event sub-process, but the start event of the event sub-process can be a timer.
Related
I am debugging an incompatibility problem of two Shopware 6 modules.
One is generating coupon codes in the CheckoutOrderPlacedEvent
The other one if firing this event itself
This causes the codes to be generated twice, for the profit of the customer :-)
In which module is this best fixed?
I tend to say, that we should not fire the CheckoutOrderPlaceEvent in modules, because this is likely to cause side effects.
On the other hand it would be possible to fix it in the coupon module, to detect if the coupons were already generated.
I tend to say, that this event shall only be fired once, as also OrderPlaced flows would be executed twice.
I agree that CheckoutOrderPlaceEvent should only be dispatched once, as the name suggests, when the order is placed. Dispatching the event will also trigger flows from the Flow Builder, so by default another order confirmation mail would be sent, which probably isn't in the interest of most merchants. In addition there might be numerous other flows triggered by the event which might do all kind of things. This might also lead to unexpected behavior. Really the keyword here is expectation and for unsuspecting users dispatching the event multiple times would not meet their expectations. While there is a context state to skip the execution of flows, other plugins might listen to the event as well with the expectation, that it is only fired once in the lifecycle of an order.
I have a process containing a sub-process. The sub-process can end either normally (with an Untyped End Event) or through Cancel End Event.
In the latter case I wanted to use a Boundary Interrupting Cancel Event to indicate next action taken in such case. I can't find a way to do that though. I can add other types of Boundary Events (both Interrupting and Non-Interrupting), but Cancel is not on the list.
This is a simplification of my process, with Escalation Events used in place of Cancel:
My situation is essentially similar to one described here.
I'm using Bizagi Modeller.
Do I oversee something or is it a limitation of Bizagi?
Cancel Intermediate events can only be stuck to the boundary of a Transaction Sub-Process according to the BPMN standard. It looks like you have used a reusable Sub-Process in your model. You have to right-click on the sub-process shape and select "Is transaction". Afterwards you can right-click on it again and attach the cancel event.
You will notice that the Transaction Sub-Process has a double lined boundary.
I've read the camunda doc, but I don't find anything about it.
I know it doesn't make sense throw something that nobody will catch, but is it possible?
https://docs.camunda.org/manual/7.7/reference/bpmn20/events/signal-events/
https://camunda.com/bpmn/reference/#events-signal
In the Business Process Model And Notation 2.0 specification(can be found at
https://www.omg.org/spec/BPMN/2.0/), P253, in the Table 10.89 - Intermediate Event Types in Normal Flow:
(Signal) This type of Event is used for sending or receiving Signals. A Signal is
for general communication within and across Process levels, across
Pools, and between Business Process Diagrams. A BPMN Signal is
similar to a signal flare that shot into the sky for anyone who might be
interested to notice and then react. Thus, there is a source of the Signal,
but no specific intended target.
Hope that helps.
Yes this is possible. You can model a throwing signal event when there are no receivers. The event will simply throw the signal and continue the normal flow (without anyone ever using the event).
In contrary to that, the catching signal events can not be used without a throwing signal event. If you use a catching signal event without a throwing signal event the process will stop at this event and will never be able to continue.
After the Task 1 is completed, we need to spawn an optional task, based on a condition. The process completion does not depend on this optional task completion.
What is the correct way to design this model ?
the desired behaviour can be modeled like this:
After Task1 completes Task2 is triggered, if the optional Condition is true, the optional Task is triggered as well.
The Instance is terminated after Task2 is finished. If the optional Task was still active it will be terminated.
You should use conditional marker for the optional flow.
Exclusive gateway in your diagram will always execute mandatory Task 2, optional task will always be ignored even when the condition for its execution is true.
Parallel gateway can not be used as it will wait for the optional task to complete for successful merge.
Are conditional markers BPMN 2.0 ok? not even seen them before except they remind me good old UML.
I think this should be solved using a XOR gateway.
Using non-interrupting (message/signal/escalation) events will help your scenario.
Alternatively, using event subprocess in this process.
Let me know if you understand how to use it. Otherwise, I will draw an example for you
UPDATE
NOTE:
1. I am only using bpmn.io to draw example instead of Camunda. However, this is basic BPMN and I assume Camunda must have this type of model. I am only familiar with JBPM.
EXPLANATION:
Basically, you don't really have to use message event. It can be signal/escalation depending on what scenarios you have. Theoretically, message event is used if there is an incoming message to create other activities and this event is the most common among the others. Yet, one thing you must consider is whether the event is interrupting or not. In your case, it doesn't interrupt, therefore I put non-interrupt message event.
Interrupt message event will abort the Task 1 immediately as soon as the event is triggered while non-interrupting is only adding additional task/event without aborting Task 1.
Hope this example helps.
I am learning how to use NSRunLoop and reading Apple Doc about Run Loops chapter.
I am confused about some description about how the doc states about the the run loop sequence of events
Because observer notifications for timer and input sources are delivered before those events actually occur, there may be a gap between the time of the notifications and the time of the actual events. If the timing between these events is critical, you can use the sleep and awake-from-sleep notifications to help you correlate the timing between the actual events
Here is doc link
It says observer notifications for timer and input sources are delivered before those events actually occur. Since those events being not happened, how does run loop knows those events are about to happen and sends notifications for thoes events in advance?
After many searches, It may help.
The doc says the followings in Custom Input Sources section.
In addition to defining the behavior of the custom source when an event arrives, you must also define the event delivery mechanism. This part of the source runs on a separate thread and is responsible for providing the input source with its data and for signaling it when that data is ready for processing. The event delivery mechanism is up to you but need not be overly complex.
More details link1 and link2
The event may occur, but that event may not be ready for using, cause the actual data produced by that event, processed on a separate thread, may not be enough to trigger the thread, which is listening that notification. So their is a gap between the notification posted by run loop and the finished happen event.
There are also other processes that leads to that gap, such as timer input source etc.
Anyone has better explanation?