I'm trying to model the following (simplified) workflow. Each start event has a route to the Main Task as well as an alternative route which will trigger the "previous" start event.
My problem: if Start Event 2 is triggered through a path from Start Event 3 it should not be possible to trigger Start Event 1 any more (red path): 3->2 is ok, 2->1 is ok, but not 3->1!
What would be the "right" solution here? Should I create an alternative Start Event 2 when it's triggered through Start Event 3 (seem to be redundant). Or should I solve this somehow through a logic gate if triggered through Start Event 3 then ... else ... (seems to be over complicated). Or is there a better solution?
PS. I tried to find a better stack exchange site for modelling but it seems 99% of the questions regarding BPMN are posted here. But I'm open for suggestions.
First of all, Start Events must not have an incoming Edge. It is not allowed by the BPMN standard. So you should replace your Start Events 2 and 3 within the process with intermediate Events.
The decission logic to skip or execute the Intermediate Event now representing the event of what was before Start Event 3 could be implemented in an Event Based Gateway, describing on the Edges which path to take under which condition.
Based on Simulat's answer I found a alternative solution which I think is the better fit. The red path should not be possible because of the logic gate with the red circle (the top path is only viable if Start Event 3 has not occurred).
The problem I have with Simulat's answer are the intermediate events and the event based gate. Since there are no "real" events on those points so I think they should be xor logic gates, but I'm not sure. Feedback is welcome:
Related
how would you drow diagram - example A or Example B or both are fine? In Example A there is an event, one extra task and process is back in the main flow. Example B - if the event occurs process is not back in main flow. Is it correct to draw process like in example A? Examples enclosed. Thank you in advance for help.
I draw examples (enclosed) and checked in BPMN specification but still have doubs.
I would go a step further and put a gateway in front of "Application Analysis" and then draw the arrow from the message event to that gateway (so the gateway is only used to join, doesn't need a condition, it is best practice, you could draw the arrow from the message event directly back on the task itself and it would express the same thing).
The basic reasoning is that you shouldn't have multiple tasks for the same thing in the diagram unless it is really at a different stage in the workflow.
However it isn't exactly the same as your workflow, because like this the customer could change the loan amount multiple times and not just once.
There are some problems:
I think you want to make the message event interrupting, otherwise you grant both loans, the original one and the changed one.
After "Application Analysis" there should probably be a gateway that checks the result of the analysis and only if it was ok you grant the loan.
Following is a safety controller with input and output
Condition given below for designing a state machine:
Here SignalOk, SignalWeak and SignalLost are measurements signal quality of steering angle. SteeringAngle signal itself contains the original steering data. In case of 3 consecutive SignalOk, system controller will output ValidSignal with the steering angle data. In other cases, signal will be considered as CorrputSignal. I am using UML 2 state charts(Harel charts). This is so far what I have done:
N.B.:Parallel states and broadcasting is not supported yet, but nested states are supported.
I don't know how to model this stream of inputs in state machine, any kind of help will be appreciated.
First I would recommend renaming the states, so that they don't resemble actions. I suggest to name them First Ok received, Second Ok received and Ok confirmed.
Since the SteeringAngle shall be ignored the first two times, the only transition triggered by it should be an internal transition in Ok confirmed. This transition will also invoke ValidSignal.
Nothing is specified about the order of SteeringAngle and SignalOk. Therefore, SteeringAngle should be deferred in Second Ok received. This way, even it it comes first, it will stay in the event pool.
Any reception of SignalWeak or SignalLost should return to Ready. You could do this with a local transition of Operational to Ready.
One additional recommendation: Define an Initial state in Operational and target the SystemOk transition to Operational. The effect is the same, but it results in a better separation of the two top level states.
I've recently started at a new business and some of the processes are becoming a bit of a challenge to map out. Quite frequently we have a process that needs to go "on hold" when an event, which can occur at any point, is triggered. The problem I'm having mapping this out correctly is how to "restart" the process from where it left off, since it can effectively pause/unpause at any point.
Here's what I currently have:
Process Example
Basically, I need to have "Something Happened 2" not fully interrupt the sub-process, it just needs to put it on "hold". The actual situation is essentially that a customer can make a complaint while we handle their overdue bill, so we put the process on hold wherever it was at until we resolve the complaint, and then restart the process.
I'm not entirely sure the best approach to documenting this and couldn't find anything clear in the documentation, since a non-interupting event seems to have the rest of the process still continue forward in parallel.
Any help would be majorly appreciated.
If you really want to restart the whole sub-process from the beginning, then you could frontload an exclusive gateway. Once the complaint is dealt with, you can direct the sequence flow to that gateway, which would restart the sub-process. See below for an example (I have simplified your diagram a bit).
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 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.