Modeling Exception Flows in Integration Systems

Towards dynamic processes-of-business processes: a new understanding

“…More specifically, we were also interested in the dynamic business process to cope with the dynamism of large business processes enacted by SoS. Weber et al (2009) presented an enlightening understanding of dynamic business processes and established three major requirements that characterize this type of process: (1) flexibility (also deeply discussed in (Cognini et al, 2018) that pointed out that process models should be customized at design-time or run-time based on, for instance, constraints (Haisjackl et al, 2016;Pesic, 2018;Pesic and van der Aalst, 2006), variability (Rosa et al, 2017), late binding (Weber et al, 2009), context conditions (Ayora et al, 2012)); (2) adaptation (processes should cope with expected and unexpected exceptions that can be mitigated with exception handling patterns (Russell et al, 2006;Ritter and Sosulski, 2014;Lerner et al, 2010)) and ( 3) evolution (process models should change when business processes evolve).…”

“…Exception handling is required for all communications among constituent processes to ensure no unexpected stop and, hence, the PoP stability, since these are fully or partially automatized (performed through one or more SoS constituent systems). Exception handling (represented as an error intermediate event from BPMN and based on exception handling patterns (Ritter and Sosulski, 2014;Russell et al, 2006;Lerner et al, 2010)) was then included in the communication between HBS (automatic constituent process) and RCU and between HBS and RHU.…”

Toward A Collection of Cloud Integration Patterns

“…The exception patterns were introduced and analyzed in [21], thus summarized in Fig. 6 and not further discussed:…”

“…Tab. 57) as well as the overview [21]), Failover Router [21], Data Store, Smart Proxy [9] Known Uses "Adapter Monitor" [17], conceptually supprted by [19] For analytical reasons, it might be important to have statistics on the used components and adapters (cf. Tab.…”

Formalizing Application Integration Patterns

“…The enterprise integration patterns (EIPs) from 2004 [3] denote messaging patterns that serve as building blocks, when implementing an enterprise application integration (EAI) system [5]. While the EIPs are still practically relevant today [12], [8], the emerging technological, social and business trends since then require pattern extensions, e. g., for integration adapters and endpoints [7], exception handling and fault tolerance [10], [11], as well as information security among many other aspects [9], [8]. With the totality of those patterns playing a major role in real-world application integration architectures, the lack of a comprehensive formalization of the single pattern semantics and their compositions (beyond the currently only attempt using plain coloured petri nets (CPN) [2], [1]) will be instrumental for the verification and optimization of the current and future EAI process modeling and architectural solutions [8].…”