Errata
1. July 24, 2009. The Index in the book is incorrect. Download a correct index here as pdf.
25 Responses to “Errata”
Leave a Reply
BPMS Watch
- BPMN 2.0 from Visio Premium 2010I mentioned in a previous post I had created a tool that converts BPMN diagrams from Visio Premium 2010 to BPMN 2.0-compliant XML. It was an interesting project because Visio itself does not internally “understand” the structure of a BPMN model. Sure, it can test many of the rules in the BPMN spec, but that [...]
- BPMN Model InterchangeOn my summer vacation I’ve been thinking a lot about the XML side of BPMN. While we usually think of BPMN as a diagramming standard, it is also – in principle – a model interchange standard, an XML format than can be exported from tool A and imported into tool B. BPMN 2.0, XPDL 2.1 [...]
- Method and Style Workshop UpdateLast Friday I had a run-through of my upcoming BPMN Method and Style Level 1 workshop. It was a good thing. I got some helpful feedback on the content, and I learned a few tricks of Microsoft Visio 2010 (having the Visio product manager in attendance didn’t hurt). It was a little rushed to squeeze [...]
In Figure 10-20 the intermediate Signal event “Account created” in the subprocess “Setup 401k account” has to be a throwing event (black triangle).
Ah yes…sigh… you are correct. Good catch. I will post a correction in Errata and later in v1.2 of the book. The printed version 1.1 (available since last week) fixes the index issue and one other graphic.
[BPMN Method and Style, page 97]
Well I am not sure what you mean by saying that ‘until Signal was introduced, BPMN had no way to synchronize with some internal milestone, or state of partial completion’.
What about a workflow pattern no. 19 presented on BPMN.ORG?
http://bpmn.org/Documents/Notations%20and%20Workflow%20Patterns.pdf [page 21]. Could any one explain that to me? I am confused.
Mieszko,
You are right. I should have said “no good way”. BPMN 1.0 supported this Signal-like behavior in the Link event, one of many disconnected behaviors given to Link. Because it was a semantic mishmash, Link was redefined in BPMN 1.1 to simply mean a sequence flow “go-to” (one of the original behaviors), which remains the case in v2.0.
–Bruce
I am little confused by the rules for access to data objects and messages. Ch5 p45 states “If some document or data element is either received by the process in a message flow or retrieved, created, or updated by a process activity, then that document or data is assumed to be available for use by any downstream activity, gateway, or event in the BPMN model.” I read this to mean that once I have a message (say “Customer Request”) start event then the first activity (and any other downstream activity) can reference the contents of that message. However later in Fig 19.4 the “Receive Loan App” message is associated with a DO “Customer data” which is subsequently used in the first task “Review Loan Application”. Why? If my interpretation of the p45 definition is correct, that task already has access to the contents of the message so why the need to complicate the diagram by adding this data mapping? Fig 20.1 shows a similar pattern of mapping the message to a DO.
Fig 10-16 and associated text shows an example of escalation of a user task, it is not clear how the escalation event is triggered. If this model was taken forward into level 3 for execution modeling, then how could it specify under what circumstances the escalation will happen and the additional parallel activity will start (Update Account Info) ?
Fig 15-4 shows a breakdown of Arrange Financing sub-proc. For Each Lender is a multi instance sub-proc, however the Lenders pool is also shown as multi-instance. This would suggest that for each individual instance of For Each Lender, there are multiple Lender participants in the collaboration. Also 15-3 which shows the top level process only shows one Lender pool (i.e. not multi instance). I would have expected this to be other way round - multi instances at top level, but single instance in the sub-process depiction - because the For Each Lender already depicts multiple instances, each of which is related to a single Lender instance.
Frank - re 1st comment…
It is the difference between Level 2 modeling and Level 3. At Level 2 (or 1), the statement in Ch5 p45 applies. Access to the data is implicit. At L1 or L2, the data object is effectively an artifact or annotation, as it was in BPMN 1.2. At Level 3, executable BPMN, the DO represents a local variable and the data associations are mappings between activity dataInputs/dataOutputs and the DO. L1/L2 has to do with process documentation and analysis, L3 with execution on a process engine.
Frank, re 2nd question…
Fig 10-16 shows Escalation on a User task. By convention (mine), this means User Action, what you could call ad-hoc. The task performer just decided to do this. On a subprocess, you might have an Escalation throw-catch that provides more insight into when/where the decision to take the action occurs… but a task is atomic, so you can’t look inside it. If you want to indicate the reason for the User Action, my style says you should use the task label or text annotation to do so.
Frank, re 3d comment…
Fig 15-3 is irrelevant because it comes before consideration of the iterative behavior in the step by step method. Your interpretation of Fig 15-4 might be correct, but it is not mine. The MI symbol on the Lender pool indicates there are multiple “participants” (Lenders), which is correct. The MI symbol on Arrange Financing activity means there are multiple instances of this activity, one for each Lender. I don’t think it is correct to assume that the notation means that each instance of the MI activity collaborates with ALL instances of MI pool. Certainly with the Level 3 detail added, this would be clear. At Level 2 it is a matter of interpretation… and I have just given you mine.
page 82, figure 9-14 is this suppossed to be an exclusive merge within the subprocess? Then it doesn’t really make sense. If it is a syncronizing merge, then it is missing the gateway. As far as I understood it.
Figure 14.6, Chapter 14, Page 158
“Undo Book Travel” Compensation event doesn’t seem to be thrown in the case where the cancelation message “Disapproval” is recevied. Is this correct?
In figure 10-26 the event subprocess is captioned “Handle Order Update” but in the following paragraph it is referred to as “Handle Update Order”.
NB: Please take this as a compliment - the reason that small, obscure errors like this and the Figure 10-20 black triangle (Eileen Willers, above) get picked up is, I think, that your book has been worth such close reading. Your book, for me, has illuminated numerous aspects of BPMN behaviours that had passed me by in my initial reading of the BPMN 2.0 beta spec. One of the strong selling points of BPMN is that it has such a complete specification:- one that is detailed enough to enable support tools to be developed. It is sad, however, that this admirable detail is presented in such a way that it obscures the behavioural aspects of BPMN that people like myself (ie business analysts or busines ‘users’ rather than tool developers) are interested in. I can’t help feeling that this is an example of a confusion between the ‘what’ and the ‘how’ of BPMN. The BPMN spec has patches of ‘what’ detail (eg the behavioural rules that the BPMN objects follow) interspersed with large tracts of ‘how’ type information (Class diagrams, attribute descriptions and XML schemas) which swamp and obscure the ‘what’ details. While the ‘how’ information is necessary, I feel it ought to be documented in its own, separate, cross-referenced section of the spec. I guess that would then relate the spec more closely to your notion of BPMN levels. (What makes it worse, though, is that even when the ‘what’ detail is presented in the spec it is printed in such a multiplicity of fonts, styles and sizes that just reading it gives one a headache. )
Regards,
Lyndon Roy London, UK
Franziska,
Sorry for the delayed comment approval/reply. In the diagram you reference, sequence flows from two parallel paths merge directly into an end event. This does not need a gateway to perform the join. A join is always implied at end events. In fact, I say it is bad style to use an AND-gateway (or in this case OR-gateway) join in front of an end event, because it is redundant. A process (or subprocess) does not complete normally until all parallel paths have reached an end event. This is the implied join.
-Bruce
I agree with you. My mistake. Receiving the Disapproval message in the event gateway should also throw the compensation. Good catch! I can see I need to do another update soon.
Lyndon,
Thanks for the catch. An error in proofreading on my part. Re the BPMN spec, it really is intended for tool and engine developers not for BPMN users. I was under the same false assumption as you when I joined the team in Nov 2008. Don’t hold your breath waiting for OMG to make the spec more useful as an end user document.
–Bruce
Continuing to read your excellent book. I have a few more minor comments which I hope are useful. Please let me know if this forum isn’t a suitable repository for such.
Figure 13-2
As drawn I think it will loop until BOTH count >=10 AND date >= deadline, also 2nd sentence of 5th paragraph on page 147 where you write “The loop condition would be something like Count <10 or Date<DeadlineDate.” Is this correct, or should it be a loop while “Count <10 and Date<DeadlineDate”, so that it terminates the loop when either condition is met?
Figure 13-7
“Posting” message between “Post Job” and “Applicant” appears in figures 13.6, but missing from figure 13-7. Is this intentional?
Figure 13-8
It looks like a single “Order” is output from “Update batch system” from time to time, but if “receive updates” isn’t running at the time that message is sent, what happens to the data? ii.e. how / where is the batch or orders accumulated?
Figure 15-2
Gateway added to 2nd output of “Enter Order” to make a conditional split, however no condition included on diagram. (Later figures include the condition “if dealer arranged financing” just before the input to “arrange financing”)
Excellent book, very illuminating on how to efficacely use this language.
Like other users I too have a small comment on the examples:
Figure 15-8: Isn’t the Cancel Factory Order user task redundant here, after adding its handling in the top-level diagram in Figure 15-5 (Cancel order
end event) ?
Reaching the Car Unavailable end event would result in sending twice the Cancel Factory Order message because of the modelled exception catch-rethrow to the parent diagrams.
If to cancel a factory order requires some manual activities in addition to sending the Cancel factory order to the Factory pool, I would see best to move this task on the exception flow of the top-level diagram (Figure 15-5).
Alberto,
Yes that is correct. When Cancel Factory Order is moved outside the subprocess to the end event, it would be removed from the child level process.
–Bruce
After reading the book, I still not understanding when I must use a send task and when I must use the intermediate send message event.
Could you offer me some examples.
Thanks
Deysi,
They are effectively interchangeable, i.e. use either one. There are a few features of Send task missing in the Message event: you can put a Loop or MI marker on it, you can attach an Error event to the boundary. Since it is an activity you can assign a Performer to it, although BPMN sort of assumes that “the process” itself is the sender rather than a particular performer role. And similar for Receive task vs catching Message event. For the most part, they are equivalent. In drafting BPMN 2.0, there was some discussion whether to eliminate Send and Receive tasks for this reason, but in the end they stayed in.
–Bruce
What happen when my end event is a message address to a Dist. list which include process participant business units as well as some business units that only need to receive the message to continue their own and independent process?
Page 49.
Fig 6-2 presents how internal business units have to be presented as lane. There are not messages symbols for explaining communication between them. In my case it’s really important to express message interchange to guarantee that each business units is validating intermediate results on time for the central process to be continued.
Can I still using intermediate message event?
When the next on-line training is taking place?
On pp 167 (figure 15-7) the book says that the Fulfill Order Subprocess is cancelled by Intermediate Message Boundry named BUYER CANCEL. I cannot see what is a trigger for this event?