Most of the examples of BPMN representing loop processes use the example of a single task with a single condition, such as the one in a previous question.
However, I am struggling a little bit to understand how you might do this for a task that has two conditions (which might also mean that it needs to be broken up into multiple tasks?).
The example I will provide is this:
A person needs to send a message to someone and make sure that it has been received (task 1) so they can move onto the next step (task 2). But if they send the same message out three times with no response then they will take another action (task 3). So the two conditions for task 1 is that a confirmation has been provided by the receiver (condition A) and that the message has not been sent out three times yet (condition B).
Hopefully someone with more experience can help with an example or a better way to represent this logic.
I would recommend not to model the repeated sending of messages as a loop. This is not an actual part of the business process, but probably rather a general communcation strategy in your system (and therefore valid for all sending operations).
If you do want to emphazize this behavior at this point, you could use an annotation.
So something like this should be fine and understandable:
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.
The process in a nutshell is that we are trying to recruit for open positions. We are assuming there is more than one position to be filled. There are level 1 & level 2 interviews, if someone passes, we want them to continue forward of course. But if not enough people pass to fill all of the open positions, we still need the ones who did succeed to move forward, while starting the searching process over again.
My question is, is how do I close off this process when there are multiple people/units/flows moving through it? Is the circled exclusive gateway at the end enough?
The exclusive gateway at the end of the process is correct.
However, I think the upper part of your diagramme might need some clarification. I see two design choices that you might want to rethink:
Does the Search for Candidates task create a list of candidates to interview or a single candidate ? In your diagramme, it first looks like there is a list of candidates that get interviewed in parallel during the Level 1 Interview task. However, the subsequent gateway suggests that you decide for each candidate, whether he/she has passed that level. If not, you move back to searching. The same applies for the Level 2 Interview task.
The inclusive gateways also suggest that you are deciding on individual candidates, whether they have passed each level because you can have a Yes and a No at the same time.
If a search for candidates results in a list of candidates that get interviewed at the same time, then I would put the interviews and Assign to project tasks inside a sub-process. You would loop through the interviews and assigning tasks until all posts are filled or all candidates examined (note the exit condition in the annotation at the top). If one round of interviews has not filled all posts, you would decide whether you need to launch another round.
If you rather interview candidates individually and want to avoid a sub-process, then you could keep your structure but use exclusive instead of inclusive gateways:
Note the data items in both examples that make it explicit whether your search resulted in a list of candidates that get interviewed or a single candidate at a time.
I have a BPMN diagram (see below) with some errors that I can't seem to figure out. The diagram depicts the Produce Magazine Article Process, where the writer and Researcher are freelancers who work together to write articles for various publications.
Bigger version: BPMN diagram
There is a bunch of errors here, three of them are logical (two are related), one is BPMN syntax.
Let's start with the syntax.
The message is always a communication between two separate pools s it has to cross pool boundaries. In your case, you have depicted Freelancers as a single pool, so Send information, being between lanes but not pools is a syntax error. Before suggesting a solution though, I will focus on logical errors.
Time event is not used to show the fact that some time goes by between the activities. That is actually something natural in the process It is used to indicate that the flow of time is a trigger of the next action(s). For instance, 7 days after choosing a topic the Publication might contact the Researcher to check on the progress. That would be indicated by timed event. In your case, it seems that the flow continuation is triggered by passing messages so you should indicate it as an Incoming message event. You actually do that in 2 places, one that is obvious (Get article as a "result" of time event) and the second that correlates to a second problem.
The second thing that most probably is a logical question is that since we are talking here about freelancers, most probably Researcher and Writer are two separate entities, not one organisation as your current diagram suggests. If that is the case, you should have them represented as two separate pools. Then your message would be judged, but still rather than "Wait for information" time event you should have "Receive information" incoming message event (that is BTW the starting event for the Writer pool - similarly receiving Article request by Researcher should be handled by Incoming message event).
If you prefer to depict the Freelancer as one "organisation", then you should completely abandon the time event (as again you have used it as an indication of time passing and as I have explained earlier that is not how it should be used). You have a simple flow, where once Researcher finishes their job, it is passed to Writer who carries it over from there. In such case, you should have a simple action flow (solid line) between the actions themselves.
It is also a good practice to be consistent in using End events (and at least recommended - some BPM engines verify that) to always have an End even for every branch of a process. You are missing one or two, depending on how are you going to approach the Freelancers part. Similarly, you should have a Start event for Publication.
Below are the two options shown in the form of diagrams. Note that I also did some minor changes to handle the insufficient information case by Publication. Otherwise, they will be stuck forever waiting for the article to come.
Option with Freelancers as separate pools:
Option with Freelancers considered as a single organisation
We have a situation where there are 2 modules, with one having a publisher and the other subscriber. The publisher is going to publish some samples using key attributes. Is it possible for the publisher to prevent the subscriber from reading certain samples? This case would arise when the module with the publisher is currently updating the sample, which it does not want anybody else to read till it is done. Something like a mutex.
We are planning on using Opensplice DDS but please give your inputs even if they are not specific to Opensplice.
Thanks.
RTI Connext DDS supplies an option to coordinate writes (in the documentation as "coherent write", see Section 6.3.10, and the PRESENTATION QoS.
myPublisher->begin_coherent_changes();
// (writers in that publisher do their writes) /* data captured at publisher */
myPublisher->end_coherent_changes(); /* all writes now leave */
Regards,
rip
If I understand your question properly, then there is no native DDS mechanism to achieve what you are looking for. You wrote:
This case would arise when the module with the publisher is currently updating the sample, which it does not want anybody else to read till it is done. Something like a mutex.
There is no such thing as a "global mutex" in DDS.
However, I suspect you can achieve your goal by adding some information to the data-model and adjust your application logics. For example, you could add an enumeration field to your data; let's say you add a field called status and it can take one of the values CALCULATING or READY.
On the publisher side, in stead of "taking a the mutex", your application could publish a sample with the status value set to CALCULATING. When the calculation is finished, the new sample can be written with the value of status set to READY.
On the subscriber side, you could use a QueryCondition with status=READY as its expression. Read or take actions should only be done through the QueryCondition, using read_w_condition() or take_w_condition(). Whenever the status is not equal to READY, the subscribing side will not see any samples. This approach takes advantage of the mechanism that newer samples overwrite older ones, assuming that your history depth is set to the default value of 1.
If this results in the behaviour that you are looking for, then there are two remaining disadvantages to this approach. First, the application logics get somewhat polluted by the use of the status field and the QueryCondition. This could easily be hidden by an abstraction layer though. It would even be possible to hide it behind some lock/unlock-like interface. The second disadvantage is due to the extra sample going over the wire when setting the status field to CALCULATING. But extra communications can not be avoided anyway if you want to implement a distributed mutex-like functionality. Only if your samples are pretty big and/or high-frequent, this is an issue. In that case, you might have to resort to a dedicated, small Topic for the single purpose of simulating the locking mechanism.
The PRESENTATION Qos is not specific RTI Connext DDS. It is part of the OMG DDS specification. That said the ability to write coherent changes on multiple DataWriters/Topics (as opposed to using a single DataWriter) is part of one of the optional profiles (object model profile), so no all DDS implementations necessariiy support it.
Gerardo
i'm not sure how to implement this the best way:
i have multiple rest requests where each on retrieves data from a different resource. the thing is that each requests needs data from the previous one.
now i have mknetworkkit running in this project and do i really have to make a request, then evaluate the data in the result block and start a new one from this result block which in turn will end up in the next result block and so forth...
it is not really recursive since evaluation is different for every request and it seems to me that nesting request/block combinations ten levels deep is not really a nice way to do this (synchronous requests apparently are also bad and not supported in mknetworkkit).
what would be the best practice to do this?
EDIT: i also would like to do this in one function call
Same issue here. What I've ended up with is placing each desired network call in a queue (array or whatever you want to store your operations in) and updating my network response delegate so that it checks the queue for the next operation in the chain.