In Figure 5.43, in the Send Payment Confirmation Choreography task, the shading of the roles needs to be reversed.
In Figure 6.15, the edge from [p1,p4] labelled t2 needs to point to [p3, p4], not to [p2, p3].
Update to the Second Edition
We came up with a formalization of the 'multiple instances without a priori runtime knowledge' control flow pattern, using a coloured Petri net. While instances of B can be started, a transition can add tokens to the input place of B. Therefore, at the start of B, the number of instances does not need to be known. To make sure C synchronizes correctly, all additional tokens have to be removed first. This is represented by the inhibitor arc in the figure below. C can fire if there are m tokens left in its input place.
Errata for the First Edition, all corrected in the Second Edition of the BPM Book
On page X, "Dolf Grünberg" needs to be substituted by "Dolf Grünbauer"
Page 96, Definition 3.4, line 6: "an event ordering" instead of "an event orderings"
Page 216, first paragraph: The term "completed" is used with the meaning "immediately stopped".
Page 272, last line: "t1" instead of "t2"
Page 277, in the proof of the Soundness Theorem, 4th paragraph, it should be "M' greater M", not "M' greater or equal M"
Page 136, Figure 4.14: the example could use an end event after the exclusive or split, so that the otherwise infinite loop is terminated
Page 147, Figure 4.25: Figure illustrates "sequential execution without a priori design time knowledge" pattern. It might be misleading that the BPMN semantics of the subprocess is parallel execution of B,C, and D.
Page 152, Figure 4.28. According to the text, there must not be a token on place p2.
Page 156, second paragraph: "... determined the not by only ..." should read "... determined not only by ...". Also on this page "remainder" instead of "reminder".
Page 163, Figure 4.34: Arrows in the lower part should be directed from the connector to the event nodes, for the XOR connector, the OR connector, and the AND connector.
Page 205, Figure 4.76: The CreditInfo input and output parameters of the Accept Credit activity should be "CreditInfo = [Jane, 16000]", not "CreditInfo = [Miller, 15000]"
Page 261, Figure 5.35: Auctioning Service is the Receiver participant role, not the Sender participant role as indicated.
Martens (2003c), van der Aalst and Weske (2001b), Mohan (2002b), and Workflow Management Coalition (2005b) are redundant
Title in Zaha et al. (2006a) needs to be changed to "Let's Dance: A Language for Service Behavior Modeling"