Temat: Podproces inicjowany zdarzeniem błędu

Witam grupowych guru z nadzieją, że zechcą podzielić się swoją wiedzą :)

Mam wątpliwość odnośnie stosowania podprocesu zdarzeniowego inicjowanego błędem. Ze specyfikacji BPMN 2.0 wynika, że nie może przechwycić błędu aktywowanego zdarzeniem końcowym błędu, bo aktywowany przez niego wyzwalacz może być przechwycony tylko przez zdarzenie krawędziowe (str. 247 specyfikacji):
"This type of End indicates that a named Error should be generated. All currently active threads in the particular Sub-Process are terminated as a result. The Error will be caught by a Catch Error Intermediate Event with the same errorCode or no errorCode which is on the boundary of the nearest enclosing parent Activity (hierarchically)."
Wynikałoby z tego, że podproces zdarzeniowy może tylko przechwytywać błędy systemowe, techniczne (na co wskazuje przykład na stronie 278). Jak więc obsłużyć błąd procesu biznesowego (nietechniczny) na poziomie procesu głównego, który siłą rzeczy nie może mieć zdarzenia krawędziowego? Aż by się prosiło użycie tutaj podprocesu zdarzeniowego, który przechwyci błąd aktywowany przez zdarzenie końcowe. A jeśli można by na poziomie procesu głównego, to dlaczego nie na dowolnym poziomie hierarchii procesów? Przeszukałem setki forów i artykułów w necie, ale nie znalazłem odpowiedzi. Znalazłem za to mnóstwo błędów, łącznie z obrazkiem, na którym zdarzenie początkowe błędu było użyte w normalnym przepływie i miało przechwytywać błąd aktywowany przez zdarzenie końcowe błędu na tym samym poziomie (http://www.slideshare.net/jimarlow/introductiontobpmn005 slajd nr 151).

Temat: Podproces inicjowany zdarzeniem błędu

Witam
Jimowi czasem się wydaje, że wie :-).

Co do podprocesu procesu aktywowanego błędem. Błąd zawsze działa z wewnątrz procesu i jest bezwarunkowy, aczkolwiek może być. Jeśli chcemy coś obsłużyć z innej gałęzi to w BPMN nie jest to błąd a sygnał.

Na marginesie str 442. w relacjach pomiędzy kompensacją a błędem jest częściowe zaprzeczenie ograniczenia ze strony 247

Temat: Podproces inicjowany zdarzeniem błędu

Jimowi? Może raczej Nocnemu Markowi, czy bardziej Nocnemu Piotrkowi ;)

Dzięki za wskazówkę o stronie 442. Tylko niestety autorzy specyfikacji nie odnoszą się tam wprost do wyzwalacza błędu aktywowanego zdarzeniem końcowym i można to odczytać jako odnoszące się tylko do wyzwalaczy automatycznych, systemowych.

Oczywiście można zastosować sygnał, ale to takie... trochę na siłę ;)

Możliwość zastosowania podprocesu zdarzeniowego błędu inicjowanego wyzwalaczem aktywowanym przez zdarzenie końcowe miałaby dużą zaletę z punktu widzenia projektowania obiektów danych. W przypadku podprocesu zdarzeniowego dysponuję obiektami procesu, przy zdarzeniu krawędziowym tylko ich "snapshot'em", co niekiedy może powodować konieczność powielenia ich na poziomie procesu nadrzędnego.

Może to przeoczenie, "zapomniano" o poprawieniu opisu zdarzenia końcowego po wprowadzeniu podprocesów zdarzeniowych w 2.0? Specyfikacja jak chodzi o zdarzenie błędu w ogóle jest niespójna - na stronie 247 przy opisie zdarzenia końcowego odnosi się do atrybutu errorCode:

"The Error will be caught by a Catch Error Intermediate Event with the same errorCode or no errorCode which is on the boundary of the nearest enclosing parent Activity (hierarchically)."

a na stronie 255 przy opisie zdarzenia krawędziowego do atrybutu name:

"...If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified..."

Definicja klasy zdarzenia błędu ErrorEventDefinition nie rozróżnia zdarzeń aktywowanych np. przez usługę od aktywowanych zdarzeniem końcowym, dlaczego więc miałaby być różnica w ich przechwytywaniu przez zdarzenie krawędziowe i zdarzenie początkowe podprocesu zdarzeniowego?

Może dzielę włos na czworo, ale liczę na wyrozumiałość grupowiczów i naczelnego guru :D

Temat: Podproces inicjowany zdarzeniem błędu

Tadeusz Świetlicki:
Jimowi? Może raczej Nocnemu Markowi, czy bardziej Nocnemu Piotrkowi ;)

Zdecydowanie Jimowi Marlow (autorowi prezentacji z Slideshare).
Znam parę jego "trafnych" wypowiedzi.

O sobie przecież źle nie będę pisał ;-D

Temat: Podproces inicjowany zdarzeniem błędu

Ups... sorki, myślałem, że to żart. Imię i nazwisko autora tego - skądinąd pożytecznego - dzieła zupełnie nie wbiło mi się w pamięć.

Co do Nocnego Piotrka nie mam wątpliwości, że wie i to nie czasami :)

Temat: Podproces inicjowany zdarzeniem błędu

Tadeusz Świetlicki:
Dzięki za wskazówkę o stronie 442. Tylko niestety autorzy specyfikacji nie odnoszą się tam wprost do wyzwalacza błędu aktywowanego zdarzeniem końcowym i można to odczytać jako odnoszące się tylko do wyzwalaczy automatycznych, systemowych.

Tak, ale w przykładzie (w części normatywnej) pokazanej jest wywoływanie procesu nazwaną usterką.
Mam wrażenie, że tablica została przepisana z wersji 1.x bez uzupełnienia jej o proces obsługi usterki wyzwalany zdarzeniem

Oczywiście można zastosować sygnał, ale to takie... trochę na siłę ;)

Nie jest to "na siłę". Sygnał to metoda komunikowania się w obrębie procesu/ów u jednego uczestnika.

(...)

Może dzielę włos na czworo, ale liczę na wyrozumiałość grupowiczów i naczelnego guru :D

Nie jest to "włos na czworo" a cenna dociekliwość.

Temat: Podproces inicjowany zdarzeniem błędu

Tadeusz Świetlicki:
Witam grupowych guru z nadzieją, że zechcą podzielić się swoją wiedzą :)

Mam wątpliwość odnośnie stosowania podprocesu zdarzeniowego inicjowanego błędem. Ze specyfikacji BPMN 2.0 wynika, że nie może przechwycić błędu aktywowanego zdarzeniem końcowym błędu, bo aktywowany przez niego wyzwalacz może być przechwycony tylko przez zdarzenie krawędziowe (str. 247 specyfikacji):
"This type of End indicates that a named Error should be generated. All currently active threads in the particular Sub-Process are terminated as a result. The Error will be caught by a Catch Error Intermediate Event with the same errorCode or no errorCode which is on the boundary of the nearest enclosing parent Activity (hierarchically)."

Wszystkie zdarzenia w tej sekcji nie opisują możliwości przechwycenia triggera
przez Event Sub Process, ale wystarczy cofnąć się do strony 242, by przeczytać, iż:
"A Start Event can also initiate an inline Event Sub-Process (see page 176). 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.".
Czyli rzucenie błędem w procesie, który zawiera Event Sub-Process, spowoduje uruchomienie procesu zdarzeniowego.

Zauważ też, iż na wskazanej stronie 247 i kolejnej przy żadnym zdarzeniu końcowym nie napisano, iż istnieje możliwość przechwycenia wpierw obsługi zdarzenia przez Even Sub-Process.

Poza tym na stronie 429 mamy już jasność:
"An Activity’s execution is interrupted if an interrupting Event is raised (such as an error) or if an interrupting Event Sub-Process is initiated, In this case, the Activity’s state changes to Failing (in case of an error) or Terminating (in case any other interrupting Event). All nested Activities that are not in Ready, Active or a final state (Completed, Compensated, Failed, etc.) and non-interrupting Event Sub-Processes are terminated. The data context of the Activity is preserved in case an interrupting Event Sub-Process is invoked. The data context is released after the Event Sub-Process reaches a final state.".

Innymi słowy, wszystkie zdarzenia z triggerem jak w tabeli 10.86 wpierw powodują uruchomienie podprocesu zdarzeniowego (zawartego w naszym podprocesie), następnie zaś ich zachowanie jest opisane tak jak w innych częściach specyfikacji, czyli może zostac przechwycone przez zdarzenie krawędziowe.

Ja bym nie mówił, iż jest to błąd specyfikacji. Według mnie raczej ciężko byłoby przy każdym omawianiu danego elementu non-stop powoływać się na wyjątki.
Według mnie nie należy wybiórczo interpretować fragmentów specyfikacji, a starać się przeszukiwać całą specyfikację w celu odpowiedniej interpretacji poszczególnych elementów.

Wynikałoby z tego, że podproces zdarzeniowy może tylko przechwytywać błędy systemowe, techniczne (na co wskazuje

Czym sie różnią błędy systemowe, techniczne od zdarzenia typu błąd ?
Ja jakos nie zauważyłem takiego rozróżnienia w specyfikacji, ale może się mylę ?

przykład na stronie 278). Jak więc obsłużyć błąd procesu biznesowego (nietechniczny) na poziomie procesu głównego, który siłą rzeczy nie może mieć zdarzenia krawędziowego? Aż by się prosiło użycie tutaj podprocesu zdarzeniowego, który przechwyci błąd aktywowany przez zdarzenie końcowe. A jeśli

I na taką konstrukcję specyfikacja zezwala, a wręcz podproces zdarzeniowy został do tego zaproponowany.

można by na poziomie procesu głównego, to dlaczego nie na dowolnym poziomie hierarchii procesów? Przeszukałem setki forów i artykułów w necie, ale nie znalazłem odpowiedzi. Znalazłem za to mnóstwo błędów, łącznie z obrazkiem, na którym zdarzenie początkowe błędu było użyte w normalnym przepływie i miało przechwytywać błąd aktywowany przez zdarzenie końcowe błędu na tym samym poziomie (http://www.slideshare.net/jimarlow/introductiontobpmn005 slajd nr 151).

Temat: Podproces inicjowany zdarzeniem błędu

Cieszę się, że mój post doczekał się odpowiedzi od takich autorytetów :)

Może to niewłaściwe podejście, ale wszystkie specyfikacje standardów interpretuję zawężająco, w ten sposób, że muszą być spełnione wszystkie warunki nałożone na jakiś specyfikowany obiekt. W BPMN 2.0 są one rozproszone, różne warunki dotyczące tego samego obiektu specyfikacji są podawane w różnych miejscach, mocno różniących się precyzją definicji, a nawet zdarzają się ewidentne niespójności (przynajmniej dla mnie czyni to tę specyfikację trudną do strawienia). W tym konkretnym przypadku tabela 10.88 explicite dopuszcza przechwytywanie wyzwalaczy Error aktywowanych przez zdarzenie końcowe tylko przez zdarzenia krawędziowe.

Oczywiście zauważyłem, że w tabeli 10.88 na stronie 247 i dalszych niektóre zdarzenia końcowe są opisane jako przechwytywane tylko przez zdarzenia krawędziowe - spośród 8 zdarzeń 3 (Error, Escalation i Cancel). Cancel jest zrozumiały - bo nie ma przechwytującego go zdarzenia początkowego. Error i Escalation wydają się być nielogicznie zubożone. Szczególnie dziwi Escalation, wprowadzony w 2.0 łącznie z podprocesami zdarzeniowymi. Trudno tu więc mówić o przeoczeniu, co mogłoby być prawdopodobne w przypadku Error, obecnego już w 1.x - ale to całkiem inny temat.

Dla kontrastu w przypadku Compensation w tej samej tabeli jest jawne dopuszczenie przechwytywania wyzwalacza przez zdarzenie początkowe podprocesu zdarzeniowego:
"...To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."

Co do rozróżnienia między błędami aktywowanymi przez system i przez zdarzenie końcowe, to istotnie wprost w specyfikacji go nie ma, bo wyspecyfikowane jest tylko zdarzenie końcowe błędu (czyli błąd procesu biznesowego). Do błędów technicznych (wyjątków rzucanych przez webservice'y czy generowanych przez silnik procesów biznesowych) jest odniesienie w tabeli klas 2.4 oraz w definicji klasy Error na stronie 81 (rozdział 8.3.3) wyszczególniającej dwa obiekty, których zawartość reprezentuje Error - zdarzenie błędu oraz nieudaną operację (co określiłem jako błąd techniczny):
"An Error represents the content of an Error Event or the Fault of a failed Operation. An ItemDefinition is used to specify the structure of the Error. An Error is generated when there is a critical problem in the processing of an Activity or when the execution of an Operation failed."
Kolejnym miejscem odnoszącym się do błędu technicznego jest rozdział 8.4 na stronie 104 (rys. 8.36 - diagram klasy Service).

Natomiast specyfikacja nie określa, w tym przypadku moim zdaniem słusznie, jak błąd techniczny nieudanej operacji ma być rzucony, bo to zależy od implementacji. Podaje więc tylko wymagany payload rzucanego błędu w tabeli 8.41 (str. 82). Nawiasem mówiąc jest w niej kolejny dramatyczny błąd:
"For an Intermediate Event within normal flow:
If the trigger is an Error, then the errorCode MUST be entered (if the processType attribute of the Process is set to executable). This “throws” the Error." - nie ma zdarzenia pośredniego normalnego przepływu rzucającego błąd.
I również w tej tabeli pominięto zdarzenia początkowe podprocesów zdarzeniowych, co już ewidentnie wskazuje na grube przeoczenie - to w końcu definicja klasy, która musi być kompletna.

Chyba przynudzam na ten temat, w końcu w specyfikacji jest mnóstwo nieścisłości. Chciałoby się jednak używać tak fajnej nowości, jak podproces zdarzeniowy, w zgodny z nią sposób, żeby w szczególności zapewnić maksymalną przenośność modeli między silnikami procesów. Choć w zasadzie i tak jest to problematyczne.

Jeśli dobrze rozumiem obaj starsi w wiedzy i doświadczeniu koledzy doradzają nieskrępowane używanie podprocesów zdarzeniowych błędu analogicznie jak zdarzeń krawędziowych?

Serdecznie dziękuję za poświęcony czas. :)

Temat: Podproces inicjowany zdarzeniem błędu

Tadeusz Świetlicki:
Cieszę się, że mój post doczekał się odpowiedzi od takich autorytetów :)

Może to niewłaściwe podejście, ale wszystkie specyfikacje standardów interpretuję zawężająco, w ten sposób, że muszą być spełnione wszystkie warunki nałożone na jakiś specyfikowany obiekt. W BPMN 2.0 są one rozproszone, różne warunki dotyczące tego samego obiektu specyfikacji są podawane w różnych miejscach, mocno różniących się precyzją definicji, a nawet zdarzają się ewidentne niespójności (przynajmniej dla mnie czyni to tę specyfikację trudną do strawienia). W tym konkretnym przypadku tabela 10.88 explicite dopuszcza przechwytywanie wyzwalaczy Error aktywowanych przez zdarzenie końcowe tylko przez zdarzenia krawędziowe.

No tak, ale wtedy Event Sub-Process nie miałby sensu, bo nie mógł być odpalony, prawda ?
A konstrukcja, gdzie najpierw następuje przechwyt przez Event Sub-Process, a dopiero póxniej wyłapanie przez zdarzenie krawędziowe, trzyma się "kupy".
Zatem należy przyjąć, iż "skróty myślowe" są w wielu częściach specyfikacji.
Natomiast próba wyjasnienia wielu mechanizmów naraz została opisana w rozdziale 13.

Oczywiście zauważyłem, że w tabeli 10.88 na stronie 247 i dalszych niektóre zdarzenia końcowe są opisane jako przechwytywane tylko przez zdarzenia krawędziowe - spośród 8 zdarzeń 3 (Error, Escalation i Cancel). Cancel jest zrozumiały - bo nie ma przechwytującego go zdarzenia początkowego. Error i Escalation wydają się być nielogicznie zubożone. Szczególnie dziwi Escalation, wprowadzony w 2.0 łącznie z podprocesami zdarzeniowymi. Trudno tu więc mówić o przeoczeniu, co mogłoby być prawdopodobne w przypadku Error, obecnego już w 1.x - ale to całkiem inny temat.

Dla kontrastu w przypadku Compensation w tej samej tabeli jest jawne dopuszczenie przechwytywania wyzwalacza przez zdarzenie początkowe podprocesu zdarzeniowego:
"...To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."

Tutaj to raczej chodzi o warunek, by czynność była "widoczna" dla zdarzenia rzucenia kompensacją, aczkolwiek faktycznie trochę się tu rozpisali, a więcej próbowali dorzucic w rozdziale 13.

Co do rozróżnienia między błędami aktywowanymi przez system i przez zdarzenie końcowe, to istotnie wprost w specyfikacji go nie ma, bo wyspecyfikowane jest tylko zdarzenie końcowe błędu (czyli błąd procesu biznesowego). Do błędów technicznych (wyjątków rzucanych przez webservice'y czy generowanych przez silnik procesów biznesowych) jest odniesienie w tabeli klas 2.4

a dokładniej ?

oraz w definicji klasy Error na stronie 81 (rozdział 8.3.3) wyszczególniającej dwa obiekty, których zawartość reprezentuje Error - zdarzenie błędu oraz nieudaną operację (co określiłem jako błąd techniczny):
"An Error represents the content of an Error Event or the Fault of a failed Operation. An ItemDefinition is used to specify the structure of the Error. An Error is generated when there is a critical problem in the processing of an Activity or when the execution of an Operation failed."

Tu chodzi o to, że błąd może być rzucony jawnie przez zdarzenie End Event, albo może być rzucone "niejawnie" z powodu jakiegoś niespodziewanego działania.

Kolejnym miejscem odnoszącym się do błędu technicznego jest rozdział 8.4 na stronie 104 (rys. 8.36 - diagram klasy Service).

Też nie widzę błędu technicznego, tylko klasę Error.

Natomiast specyfikacja nie określa, w tym przypadku moim zdaniem słusznie, jak błąd techniczny nieudanej operacji ma być rzucony, bo to zależy od implementacji. Podaje więc tylko wymagany payload rzucanego błędu w tabeli 8.41 (str. 82).

W rozdziale 13 dokładniej spróbowano wyjasnić zagadnienia związane z obsługa błędów.

Nawiasem mówiąc jest w niej kolejny dramatyczny błąd:
"For an Intermediate Event within normal flow:
If the trigger is an Error, then the errorCode MUST be entered (if the processType attribute of the Process is set to executable). This “throws” the Error." - nie ma zdarzenia pośredniego normalnego przepływu rzucającego błąd.

A tu nie mowy o zdarzeniu pośrednim rzucającym. Mowa jest o tym, według mnie, że zdarzenie przechwytujące błąd umieszczone w sekwencji musi posiadać konkretny kod błędu, by błąd przechwycić (i obsłużyć), w odróżnieniu od zdarzenia przechwytującego krawędziowego, które nie musi posiadać wyspecyfikowanego kodu błędu. Nie uważasz ?

I również w tej tabeli pominięto zdarzenia początkowe podprocesów zdarzeniowych, co już ewidentnie wskazuje na grube przeoczenie - to w końcu definicja klasy, która musi być kompletna.

Przy opisie różnych metod np. Javy nie podaje się, że gdy w metodzie cos pójdzie nie tak, to bedzie wyłapywany wyjątek przez system. Przy opisie wyłapywania wyjatków masz opis, iż jeśli załozysz pułapkę na dany wyjątek, to możesz ten wyjątek ładnie obsłużyć.
myślę, że podobny mechanzim specyfikowania języka zastosowano i tutaj.

Chyba przynudzam na ten temat, w końcu w specyfikacji jest mnóstwo nieścisłości. Chciałoby się jednak używać tak

No tak nie do końca. Proponowałbym próbować rozgryzać te niby nieścisłości w szerszym kontekście. Wtedy może wiele po prostu zniknie :)

fajnej nowości, jak podproces zdarzeniowy, w zgodny z nią sposób, żeby w szczególności zapewnić maksymalną przenośność modeli między silnikami procesów. Choć w zasadzie i tak jest to problematyczne.

Problematyczne jest już przeniesienie samego podprocesu !!!

Jeśli dobrze rozumiem obaj starsi w wiedzy i doświadczeniu koledzy doradzają nieskrępowane używanie podprocesów zdarzeniowych błędu analogicznie jak zdarzeń krawędziowych?

Polecałbym wpierw rozdział 13 :)

Serdecznie dziękuję za poświęcony czas. :)

Temat: Podproces inicjowany zdarzeniem błędu

Dziękuję za cenne uwagi.

Odniesienia do klasy Error zamieściłem dlatego, żeby pokazać dwa różne mechanizmy, rozróżnienie między błędem technicznym, czyli nieudaną Operacją, a błędem procesu biznesowego (czyli zdarzeniem końcowym błędu) - to była odpowiedź na Twoje pytanie czym się według mnie różnią. Mechanizmem aktywowania. A mój problem polega na tym, że w opisie dotyczącym drugiego z nich, tj. błędu aktywowanego zdarzeniem końcowym (który umożliwia modelowanie błędu procesu biznesowego) zawarto w tabeli 10.88 jawne ograniczenie przechwytywania go do zdarzeń krawędziowych. Pozostałe miejsca w specyfikacji nie rozróżniają już jak obiekt Error powstaje, a więc nie uchylają tego jawnego ograniczenia. Literalnie czytając specyfikację, zdarzenie początkowe podprocesu zdarzeniowego może więc przechwytywać jedynie błędy aktywowane pierwszym mechanizmem, przez obiekty Service, bo w świetle ograniczenia z tabeli 10.88 drugi mechanizm jest dla nich niedostępny.

Co do zdarzenia pośredniego błędu normalnego przepływu, to pełny opis atrybutu errorCode jest taki:
"For an End Event:
If the result is an Error, then the errorCode MUST be supplied (if the processType attribute of the Process is set to executable) This “throws” the Error.
For an Intermediate Event within normal flow:
If the trigger is an Error, then the errorCode MUST be entered (if the processType attribute of the Process is set to executable). [b]This “throws” the Error[b].
For an Intermediate Event attached to the boundary of an Activity:
If the trigger is an Error, then the errorCode MAY be entered. This Event “catches” the Error. If there is no errorCode, then any error SHALL trigger the Event. If there is an errorCode, then
only an Error that matches the errorCode SHALL trigger the Event."

Opis zdarzenia pośredniego normalnego przepływu jest praktycznie identyczny jak końcowego, więc raczej nie miałem wątpliwości, że chodzi o "rzucenie" błędu, a nie przechwycenie. Zresztą zdarzenia pośredniego normalnego przepływu przechwytującego błąd też nie ma, więc to błąd według mnie tak czy siak.

Rozdział 13... trochę czasu nad nim spędziłem... ;) Ale nie znalazłem w nim wyjaśnienia wątpliwości wzbudzonych tabelą 10.88 :(. Dlatego zapytałem fachowców :D

Jeszcze raz dziękuję za czas poświęcony mojemu postowi. Twoje wyjaśnienia dużo mi dały. BPMN to dla mnie poboczna tematyka i stosunkowo nowa. Specyfikacje, z którymi się stykam, mają inny charakter, stąd moje przyzwyczajenie do literalnego rozumienia każdego zapisu.

Temat: Podproces inicjowany zdarzeniem błędu

Tadeusz Świetlicki:
Co do zdarzenia pośredniego błędu normalnego przepływu, to pełny opis atrybutu errorCode jest taki:
"For an End Event:
If the result is an Error, then the errorCode MUST be supplied (if the processType attribute of the Process is set to executable) This “throws” the Error.

Zerknij tutaj: http://www.omg.org/issues/bpmn2-rtf.open.html

Temat: Podproces inicjowany zdarzeniem błędu

Stanisław Jerzy Niepostyn:

Tadeusz Świetlicki:
Co do zdarzenia pośredniego błędu normalnego przepływu, to pełny opis atrybutu errorCode jest taki:
"For an End Event:
If the result is an Error, then the errorCode MUST be supplied (if the processType attribute of the Process is set to executable) This “throws” the Error.

Zerknij tutaj: http://www.omg.org/issues/bpmn2-rtf.open.html

Super, dzięki wielkie :)

Temat: Podproces inicjowany zdarzeniem błędu

Stanisław Jerzy Niepostyn:

Tadeusz Świetlicki:
Co do zdarzenia pośredniego błędu normalnego przepływu, to pełny opis atrybutu errorCode jest taki:
"For an End Event:
If the result is an Error, then the errorCode MUST be supplied (if the processType attribute of the Process is set to executable) This “throws” the Error.

Zerknij tutaj: http://www.omg.org/issues/bpmn2-rtf.open.html

Ten link to strzał w dziesiątkę. Issue 15663 (Inconsistencies and contradictions concerning Error element) potwierdza wszystkie nieścisłości które znalazłem, w szczególności odwoływanie się raz do atrybutu name, a drugi raz do erroCode dla zdarzenia krawędziowego, jak i zasadniczy problem pominięcia zdarzenia początkowego błędu w przechwytywaniu wyzwalaczy aktywowanych przez zdarzenie końcowe i słabego opisu błędów technicznych. Niestety choć to zgłoszenie jest z 2010 rok brak reakcji zespołu, nawet dyskusji. Ale tak jak napisałeś, nie trzymanie się literalnie zapisów z tabeli 10.88 "trzyma się kupy". Pewnie w 2.1 nieścisłości zostaną poprawione.

Tak swoją drogą, zamiast poszukać na oficjalnej stronie omg, przeszukałem tony innych miejsc w sieci. To chyba oznaka braku zaufania do oficjalnych źródeł - muszę zmienić podejście. ;)

Stanisławie, wielkie dzięki i wyrazy uznania za skuteczną pomoc!!!