Understanding Business Processes and Workflows

Chapter 9Processes and Workflows COMP 4/6302

Topics • Business processes • Workflows • Service composition meta-model • Web services orchestration and choreography • The Business Process Execution Language

Business processes • A process is a sequence of steps that: • is initiated by an event, • transforms its inputs (in terms information, materials, or business commitments), • produces a specified output. • A business process is a set of logically related tasks performed to achieve a well-defined business outcome. • It implies a horizontal view on an organization that looks at processes as sets of interdependent activities designed & structured to produce a specific output for a customer or a market. • It defines the results to be achieved, the context of the activities, the relationships between the activities & the interactions with other processes and resources.

Characteristics of processes A process: • may contain defined conditions triggering its initiation in each new instance (e.g. the arrival of a claim) and defined outputs at its completion. • may involve formal or relatively informal interactions between participants. • has a duration that may vary widely. • may contain a series of automated activities, capable of workflow management. • contains decision points. • Decisions have to be made with regard to routing and allocation of processing capacity. • is widely distributed and possibly customized. • exhibits a dynamic nature and is usually long running.

Process-oriented workflows • Process-oriented workflows are used to automate processes whose structures are well defined and stable over time. • A process-oriented workflow can depict various aspects of a business process, e.g., automated and manual activities, decision points and business rules, parallel and sequential work routes, and how to manage exceptions to the normal business process. • An order management process or a loan request is an example of a well-defined process. • Certain process-oriented workflows may have transactional properties.

Web Services and Business Processes • The nature of services creates the opportunity for building composite services by combining existing elementary or complex services (the component services) from different enterprises and in turn offering them as high-level services or processes. • Composite services (and related processes) integrate multiple services – and assemble new business functions – by combining new and existing application assets in a logical flow. • The definition of composite services requires coordinating the flow of control and information between the component services. • Business logic can be seen as the ingredient that sequences, coordinates, and manages interactions among Web services. • Techniques for Web services composability draw heavily on business process modelling and workflow processing languages.

Check availability and price Place order Check credit Create shipping manifest Confirm order Send payment Confirm shipment Confirm payment Send payment receipt Syndicated Web services 3rd Party Customer Supplier CityBank UPS CityBank

Flow Model • Flow models are used for the specification of complex service interactions. • A flow model describes • how activities (here implemented as Web services operations) are combined; • The order that these steps are executed (control links); • the decision points where steps may or may not have to be performed; • the passing of data items between the steps involved (data links). Is a control link superimposed on a data link, or the opposite?

Transition conditions

Service Composition: process flow as a Web service How is this process flow related to the workflow implemented in the project?

WS orchestration vs. choreography • Orchestration • Describes how Web services can interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under control of a single endpoint (single party). • Choreography • Associated with the public (globally visible) message exchanges, rules of interaction & agreements that occur between multiple business process endpoints. • Tracks the sequence of messages that may involve multiple parties and multiple sources, and described from the perspectives of all parties (common view).

Orchestration vs. Choreography Orchestration Choreography Orchestration & Choreography

Business Process Execution Language • BPEL as a service composition (orchestration) language facilitates the modeling and execution of business processes based on Web services. • models business process collaboration (<partnerLink>s); • models the execution control of business processes; • separates abstract definition from concrete binding; • supports fault handling & compensation; • supports service composability (structured activities can be nested and combined arbitrarily); • supports context (<scope> mechanism); • spawns off & synchronizes processes (<pick> & <receive> activities); • supports event-handling.

BPEL has five sections: message flow, control flow, data flow, process orchestration, fault and exception handling BPEL structure <process name=”PurchaseOrderProcess” ... >  <partnerLinks> ... </partnerLinks > <!– Data used by the process --> <variables> ... </ variables > <!– Supports asynchronous interactions --> <correlationSets> ... </correlationSets> <!– Activities that the process performs --> (activities)* <!–Exception handling: Alternate execution path to deal with faulty situations --> <faultHandlers> ... </faultHandlers> <!–Code that is executed when an action is “undone” --> <compensationHandlers> ... </compensationHandlers> <!–Handling of concurrent events --> <eventHandlers> ... </eventHandlers> </process>

BPEL 1.1 UML meta-model

BPEL Abstract and executable processes Abstract: interface only Executable: both interface and internal details BPEL abstract process corresponding to workflow diagram on page 9.6

Message flow • Message flow in BPEL deals with the sending and receiving of messages so that a process (Web service) instance can communicate with other Web services. This is handled by basic activities that include: • invoking a synchronous or asynchronous operation on some Web service (<invoke>), • waiting for an input-only process operation to be invoked by some external client (<receive>), and • generating the response of an input-output operation (<reply>). • Other services are called partners. • A partner is a Web service that a process invokes and/or any client that invokes a process. • It is essentially a mapping to a WSDL <portType> description of a physical partner’s Web service. • A process interacts with each partner using a <partnerLink> element. • A partner link is an instance of typed connector that a particular process offers to or requires from its partner at the other end of the link.

Synchronous and asynchronous communication

Control flow • Basic activities are the simplest form of interaction with a service. They are not sequenced and comprise individual steps to interact with a service, manipulate the exchange data, or handle exceptions encountered during execution. • <receive>, <reply>, and <invoke> represent basic activities that allow a business process to exchange messages with the services it composes. Other basic activities include exception handling mechanisms and state management activities. • Structured activities describe how a business process is created by composing the basic activities it performs into structures that express control patterns, data flow, fault handling, external event handling and coordination of message exchanges between process instances. Specify which activities should run • sequentially (<sequence> activity) • in parallel (<flow> activity) • have branching activities (<switch>) • to define iterations (<while>) • to execute one of several alternative paths (non-deterministic choice) based on external events (<pick>)

Data flow • The state of a business process includes the content of the messages that are exchanged as well as intermediate data used in business logic and in composing messages sent to partners. • To maintain the state of a business process, state variables, which are called <variable>s, are used in BPEL. • A BPEL variable is a typed data structure that stores messages associated with a workflow instance in order to facilitate stateful interactions among Web services (partners): • data <variable>s specify the business context of a particular process. These are collections of WSDL messages, which represent data that is important for the correct execution of the business process and provide the means for holding message content that constitute altogether the state of a business process. • the <assign> statement is used to copy data messages (messages, parts of messages and service references) between variables.

Process orchestration • The process composition (orchestration) section of BPEL uses <partnerLink>s to establish peer-to-peer partner relationships by specifying the roles of each party and the (abstract) interface that each provides. • <partnerLink>s specify the shape of a relationship with a partner by defining the message and port types used in the interactions in both directions between any two partners, i.e., the operations provided or invoked by a business process. • Another BPEL element, the <partnerLinkType> is used to describe the communicational relationship between two partners by defining the type of role that each partner plays when two processes interact and the port types used in the interactions in both directions.

Synchronous and asynchronous processes in BPEL <partnerLinkType name="creditCheckPLT"> <role name="creditChecker" portType="tns:creditCheckPT"> </role> </partnerLinkType> <partnerLinkType name="creditCheckPLT"> <role name="creditRequestor" portType="tns:creditCheck-CallbackPT"> </role> <role name="creditChecker" portType="tns:creditCheckPT"> </role> </partnerLinkType> <process> <receive partnerLink="CreditChecking" portType="CreditCheckPT" operation="initiate-credit-check" variable="creditCheckVar"> ..... perform processing ..... <reply partnerLink="CreditChecking" portType="CreditCheckPT" operation="initiate-credit-check" variable="creditCheckResponseVar"> </process> Synchronous process <process> <receive partnerLink="CreditChecking" portType="CreditCheckPT" operation="initiate-credit-check" variable="creditCheckVar"> ....... Perform time-consuming processing .....  <invoke partnerLink="CreditChecking" portType="CreditCheck-CallBackPT" operation="credit-check-response" inputVariable="creditCheckResponseVar"> </process> Asynchronous process

Example of asynchronous BPEL process Asynchronous BPEL process corresponding to the abstract process on page 9.20

Graphic representation of BPEL purchase order process

<portType name=“PurchaseOrderPortType"> <operation name=“SendPurchase"> ….. </operation> </portType> Purchase process WSDLPortType <partnerLinks> <partnerLinkname= "Purchasing" partnerLinkType=“PurchaseOrderPLT" myRole= "PurchaseService"/> <partnerLink name=“CreditChecker” partnerLinkType=“CreditCheckPLT" myRole="CreditRequester" partnerRole=“CreditChecker"/> <partnerLinkname=“BillingService" partnerLinkType=“BillingPLT" myRole=“BillRequester" partnerRole=“Biller"/> </partnerLinks> <partnerLinkType name=“PurchaseOrderPLT"> <role name=“PurchaseService"> <portType name=“PurchaseOrderPortType"/> </role> </partnerLinkType> <partnerLinkType name=“CreditCheckPLT"> <role name=“CreditChecker"> <portType name="CreditCheckPortType"/> </role> <role name=“CreditRequester"> <portType name="CreditCheckCallbackPortType"/> </role> </partnerLinkType> synchronous Purchase process partner link declarations Purchase process partner link types asynchronous PartnerLinks and associated partnerLinkTypes for Purchase Order process <partnerLinks> <partnerLink name="Purchasing" partnerLinkType="PurchaseOrderPLT" myRole="PurchaseService"/> <partnerLink name="CreditChecker" partnerLinkType="CreditCheckPLT" myRole="CreditRequestor" partnerRole="CreditChecker"/> <partnerLink name="InventoryChecker" partnerLinkType="InventoryCheckPLT" myRole="InvetoryRequestor" partnerRole="InventoryService"/> <partnerLink name=" BillingService" partnerLinkType="BillingPLT" myRole="BillRequestor" partnerRole="Biller"/> </partnerLinks>

<variables> <variable name=“PO“messageType=“POMessage"/> <variable name=“Invoice“messageType=“InvMessage"/> <variable name=“OrderAcceptance" messageType=“OrderAcceptMessage"/> <variable name=“POFault" messageType=“POFaultType"/> </variables> <assign> <copy> <from variable="PO" part=“purchaseOrder"/> <to variable=“creditRequest” part=“purchaseOrder"/> </copy> </assign> <wsdl: message name=“POMessage”> < wsdl: part name=“manufacturerInfo” type=“sns:manufacturerInfo”/> < wsdl: part name=“purchaseOrder” type=“sns:purchaseOrder”/> </ wsdl: message> …… < wsdl: message name="OrderAcceptMessage"> < wsdl: part name=“OA” type=“sns:OrderAcceptance”/> </ wsdl: message> < wsdl: message name=“POFaultType”> < wsdl: part name=“problemInfo” type=“xsd:string”/> </ wsdl: message>  …… <portType name=“PurchasePortType"> <operation name=”SendPurchase"> <input message="pos:POMessage"/> <output message="pos:InvMessage"/> <fault name="cannotCompleteOrder" message="pos:POFaultType"/> </operation> </portType> Purchase order process WSDL definitions Data variables for Purchase Order process Data variables for Purchase Order process

Process flow for purchase order process <sequence> <receive partnerLink="Purchasing" portType="lns:PurchaseOrderPortType" operation="SendPurchase" variable="PO" createInstance="yes" > </receive> <flow> <links> <link name="inventory-check"/> <link name="credit-check"/> </links> <!– Check inventory --> <invoke partnerLink="inventoryChecker" portType="lns:InventoryPortType" operation="checkInventory" inputVariable="inventoryRequest" outputVariable="inventoryResponse"> <source linkName="inventory-check"/> …. <invoke/> <!– Check credit --> <invoke partnerLink="creditChecker" portType="lns:CreditCheckPortType" operation="checkCredit" inputVariable="creditRequest" outputVariable="creditResponse"> <source linkName="credit-check"/> …. <invoke/> <!– Issue bill once inventory and credit checks are successful --> <invoke partnerLink="BillingService" portType="lns:BillingPortType" operation="billClient" inputVariable="billRequest" outputVariable="Invoice" joinCondition="getLinkStatus(‘inventory-check’) AND getLinkStatus(‘credit-check’)"> <target linkName="inventory-check"/> <target linkName=“credit-check"/> …. <invoke/> </flow> ... <reply partnerLink="Purchasing" portType="lns:purchaseOrderPT" operation="Purchase" variable="Invoice"/> </sequence>

Understanding Business Processes and Workflows