Communication between organizations is formalized as process choreographies in daily business. While the correct ordering of exchanged messages can be modeled and enacted with current choreography techniques, no approach exists to describe and automate the exchange of data between processes in a choreography using messages. This paper describes an entirely model-driven approach for BPMN introducing a few concepts that suffice to model data retrieval, data transformation, message exchange, and correlation - four aspects of data exchange. For automation, this work utilizes a recent concept to enact data dependencies in internal processes. We present a modeling guideline to derive local process models from a given choreography; their operational semantics allows to correctly enact the entire choreography from the derived models only including the exchange of data. Targeting on successful interactions, we discuss means to ensure correct process choreography modeling. Finally, we implemented our approach by extending the camunda BPM platform with our approach and show its feasibility by realizing all service interaction patterns using only modelbased concepts. The work summarized in this extended abstract has been published in [Me15].
SQL 1 Introduction and Problem Description In daily business, organizations interact with each other, e.g., concluding contracts or exchanging information. Fig. 1(left) describes an interaction between a customer and a supplier with respect to a request for a quote. The customer sends the request to a chosen supplier which internally processes it and sends the resulting quote as response which then is handled internally by the customer. An interaction between business processes of multiple organizations via message exchange is called process choreography. In BPMN (Business Process Model and Notation), a choreography diagram describes the order of message exchanges between multiple participants from a global view (global choreography model). A collaboration diagram describes message exchanges are realized via send and receive activities, distributed over the different participants (local choreography model). This paper considers how to implement local choreography models that adhere to a global agreement; we focus on a top-down approach where all participants jointly agree on a
lvee rtsoeuCm reSqeunedsQt LQ Global_Request laCI: Global_Request.r_id lobG MReesqsuaegset ilr e p p u S
ReceiveQ request ReceiveQ quote Quote Message SendQ quote
CO:QRequest [new] Request [created] pk:Qr_id
[sent] pk:Qr_id [new] Quote [received] pk:Qq_id fk:Qr_id Global_Quote CI: Global_Request.r_id r e m o ts u C
request
request
Supplier [new] [new] Q[ruepofkkct::eeQQIiQIqqvi_eI_itidded]m [rpeDQfkkce:u:eQtQoaiqqvtdi_eel_isdidd] Global_Quote CI:QGlobal_Request.r_id r e m o t s u C Q f o Q l e v e L Q l a c o L l e v e L l a c o L
global data exchange and collaboration model to which each participant’s local process and data models either must adhere or are required to be changed accordingly [vdAW01]. Deriving a local choreography from a global one is a non-trivial step; various techniques are required [DW11] including locally enforcing the order of globally specified message exchanges. In general, both control-flow (order of message exchange) and data-flow (actual message contents) need to be addressed when transitioning from global to local models. The paper contributes an approach to for integrating control-flow and data-flow in message exchange; we present a few syntactic extensions to BPMN together with operational semantics that allow to model and realize the intended global interaction using model-based concepts only. 2 Approach We combine several existing approaches to automate data exchange in process choreographies entirely model-driven as follows; these approaches are used along the general guideline shown in Fig. 2. (1) All participants agree on a global choreography model expressed in BPMN as shown in Fig. 1(left); BPMN will also be used for the local choreography models. (2) In addition, we introduce Local Level of Supplier Request Quote taehxllacythaaanglglreeepfaotrotrimcsiapptaesncitufisscegddloabitna- CGIl:obGalol_bRaelC_qRuueesqtstuoemste.rr_id RCGeIl:oqbGualeols_btQ.arul__oidte ----rsgd_t_aairtdt_eeid 1 1 -----rspdq_tr_eaiiildctdiveeeryDate the collaboration modeled in Rreeqcueeivset Cqrueoattee qSueontde 1* agUmlgMaolpboLpabil;anlFgdciaghtthao4er(emctoooogpndr)taerplso.hhl-yo(fl3wmo)swoFtdhooeerfl ilrSeupp CO: Request [[nrReepewckq]e:uirv_eiesddt] [[snAeepfkwlkre:t:]IicqacI_t_leiieddd] [[ncpQerfkkweu::a]orqt_t_eieiddd] [rRepeckqe:uirv_eiesddt] ------saaaqqtrr__uAattiiaiitddrccnetllteeiictPTylryeipcee into local ones, we uti- Fig. 3: Local process model and local data model of the supplier lize the Public-to-Private approach [vdAW01] unchanged; Fig. 1(right) and Fig. 3 show the two local process models obtained from the choreography of Fig. 1(left). (4) Next, we map the data perspective fcooafrl wtpharerodcgealsotstbriambluotcdehe-ollerbveyoelgdrdeaafipthnayinscgthoaemesatarcahmigalhpot--- lllvLaoeebGlobal--GrdD_alaiotdetbaalM_oRdeeqluest 1 1 ----Grtdq_o_elitoildadibvlPearrliy_cDeQatueote 1 * -----Gtapqqy_r_ulpioiiacddenbetaitly_Article tiepmshliseont.rdgsWaeenbln,hsedlaetawenntrdeeedetxtohncferhtgonhalmenotrgbagtianhlnolsegblaalamntoledlcedyaslslboaaycdggaartelethsaeeddlmaortecoaocandilmpeddiloeaadonttaa-ft llvcLLaoeeGLoca---lRrsd_taDeaitdtaqeetuaeMstode1l o1f C-----ursggq_ts__Q_aitrqidtdu_o_eiomiddteer 111 -----Qtsqqdot_eduatil_tadoiiveldtPeerriycDDeaetteails* --------Qitsggqqqtyt__i_uuea_pqqiamtidoei_nde_tPitideirdtiycIetem to its local data model. This way heterogenous local data models are isolated from Fig. 4: Data schema mapping from global data each other and are synchronized. By mark- model (messages) to local data model of the Cusing specific attributes of the global data tomer. model as correlation identifiers (e.g., Global Request.r id in Fig. 1(left)) we obtain locally usable correlation keys through the above mentioned data schema mapping; these local correlation identifiers can then be used as proposed in the BPMN standard to associate an incoming message to the right process instance. (5) To process (create and store) messages in a model-driven fashion, we apply (and slightly extend) the approach in [Me13] for automatically deriving SQL queries from BPMN data objects to enact complex data-dependencies. Thereby, we utilize the notion of dedicated (multi-instance) case objects for subprocesses from to realize 1:n communication with a set of participants. Fig. 5 illustrates the syntax and the operational semantics we provided with this extension. 1.) To send Global Quote message, activity Send Quote first automatically derives SQL queries based on the annotations to its input data objects [Me13] (a Quote object related to the quote instance, a Request and several Article object related to the quote). 2.) The retrieved local data is transformed into a message carrying a data object of the global data model by an XQuery generated from the data schema mapping of Fig. 4. 3.+4.) The message is sent and received using standard communication protocols. 5.) The recipient correlates the received message through the designated correlation key Global Request.r id; technically, we identify the process instance of the Customer that holds a Quote object with attribute r id having the same value as the message; Process Engine of Supplier 1. Retrieval of data Database
CO: Request
Supplier Quote [created] pk: q_id fk: r_id ...
Send quote 2. Transformation of data Request [received] pk: qd_id fk: q_id
Article [seplke:IcaIt_eidd] fk: q_id
Quote Message 3. Send message
Correlation mechanism ...
Receive quote 5. Correlation of message [new] Quote Item [received] pk:IqIi_id fk: q_id this query is generated automatically. 6.+7.) The received message is transformed into local data objects (using the data schema mapping) which are then stored in the database of the Customer, again using queries derived from the output data objects of task Receive Quote [Me13]. We integrated several existing, isolated techniques for fully model-based definition and enactment of choreographies. We provided a few minor syntactic extensions of BPMN with complimentary operational semantics that translates model features into executable, platform-independent code [Me15]; we implemented our approach based on the Camunda BPM engine; see http://bpt.hpi.uni-potsdam.de/Public/BPMNData. Using this engine, we created fully model-driven implementations of all service interaction patterns [BDtH05] including patterns on 1:n message exchange with multiple participants using identical/different correlation identifiers, and referral of correlation identifiers. [DW11] [Me13] [Me15]