21. Business Process Analysis (3)

Size: px

Start display at page:

Download "21. Business Process Analysis (3)"

Melvin Francis
5 years ago
Views:

1 21. Business Process Analysis (3) DE + IA (INFO 243) - 2 April 2008 Bob Glushko 1 of 43 4/1/2008 3:34 PM Plan for Today's Class Business Transaction Patterns Business Signals Collaborations and Choreography Some alternative process modeling metamodels and approaches ebxml Business Process Specification Schema (BPSS) Business Process Execution Language (BPEL) BPEL4 People ("Service blueprinting" & "Business Artifacts: Operational specification" on Monday 4/7) 2 of 43 4/1/2008 3:34 PM

2 The ebxml Process Metamodel 3 of 43 4/1/2008 3:34 PM ebxml Metamodel - Another View 4 of 43 4/1/2008 3:34 PM

3 Business Transaction Patterns Exercise 1. A) Where can I buy a notebook computer? 2. B) Here's my catalog of notebook computers. 3. A) I'd like to order this one. 4. B) OK. 5. B) And here's your invoice. 6. A) OK. 7. A) When will the computer arrive? 8. B) By next Tuesday. 9. B) Here's my complete catalog, in case you're interested in other products besides notebook computers. 5 of 43 4/1/2008 3:34 PM Business Transaction Patterns Business Transaction Patterns describe typical ways that business documents are exchanged: Offer-Acceptance (Commercial Transaction) Request-Response Request-Confirm Query-Response Notification Information Distribution 6 of 43 4/1/2008 3:34 PM

4 Offer-Acceptance (Commercial Transaction) Pattern (1) 7 of 43 4/1/2008 3:34 PM Offer-Acceptance (Commercial Transaction) Pattern (2) This is the common "offer and acceptance" or "contract formation" pattern The standard and simplest example is "Place Order" The party making the offer "exposes itself to the imposition of legal liability by another" if the offer is accepted The accepting party must send an acknowledgment when it determines that the offer document passes the "business acceptance" test (this is often an "Order Response") Because of this legal exposure and the time it may take for the recipient to decide on the offer, the recipient might send receipt and confirmation signals The offer and the acceptance are "non-repudiable" 8 of 43 4/1/2008 3:34 PM

5 Request-Response Pattern (1) 9 of 43 4/1/2008 3:34 PM Request-Response Pattern (2) This pattern is used to model the situation where one party makes a request for information when the responding party has to apply some business logic to answer, because it may be dependent on the identity of the party making the query or because it needs to be dynamically generated Typical examples are "Request Quote" or "Check Inventory" This transaction might require non-repudiation on the responder's part The response doesn't create any obligations for the responding party 10 of 43 4/1/2008 3:34 PM

6 Request-Confirm Pattern (1) 11 of 43 4/1/2008 3:34 PM Request-Confirm Pattern (2) This pattern is used to model the situation where one party requests confirmation about a previously established contract or obligation It might be used to get status information or obtain authorization A typical example is "Request Order Status" This transaction will typically need non-repudiation on the responder's part 12 of 43 4/1/2008 3:34 PM

7 Query-Response Pattern (1) 13 of 43 4/1/2008 3:34 PM Query-Response Pattern (2) This pattern is used to model the situation where one party makes a request for information that the responding party already has, that is static (or slow-changing) and that isn't dependent on the identity of the party making the query A typical example is "Request Catalog" The response consists of a collection of results, each of which meets the constraints specified in the query Usually no receipt or confirmation signals And usually no non-repudiation requirement 14 of 43 4/1/2008 3:34 PM

8 Notification Pattern (1) 15 of 43 4/1/2008 3:34 PM Notification Pattern (2) This pattern is used to model a formal information exchange The standard example is "Notify of Invoice" It has non-repudiation requirements for the sender The recipient should respond with a receipt business signal It is like the Commercial Transaction pattern but there is no business response document 16 of 43 4/1/2008 3:34 PM

9 Information Distribution Pattern (1) 17 of 43 4/1/2008 3:34 PM Information Distribution Pattern (2) This pattern is used to model an informal information exchange A typical example is "Publish Catalog" This transaction will typically not use non-repudiation It is similar to Query-Response but without a responding business document. 18 of 43 4/1/2008 3:34 PM

Decision Tree for Transaction Patterns 19 of 43 4/1/2008 3:34 PM Business Signals in the Process Stack / Pipeline These transactional depictions omit other events or information sent by the message

10 Decision Tree for Transaction Patterns 19 of 43 4/1/2008 3:34 PM Business Signals in the Process Stack / Pipeline These transactional depictions omit other events or information sent by the message recipient in support of the "business document level" activity These events provide useful feedback or reassurance to the sender when the responding business can't reply to the request immediately While they are not documents, these business "signals" or "confirmations" have business value and are in addition to any acknowledgement signals associated with the lower level message transport layers (e.g., HTTP, TCP/IP) 20 of 43 4/1/2008 3:34 PM

11 Sequence Diagram for "Create Order" 21 of 43 4/1/2008 3:34 PM "Create Order" with Signals 22 of 43 4/1/2008 3:34 PM

Three Types of Business Acknowledgments 23 of 43 4/1/2008 3:34 PM Business Signals: Types Business Signals are not business documents but they are used at the process level to notify the sending

12 Three Types of Business Acknowledgments 23 of 43 4/1/2008 3:34 PM Business Signals: Types Business Signals are not business documents but they are used at the process level to notify the sending party of certain types of events A Receipt is used to inform a sender of a business message that the message has been received A Confirmation is used to inform a sender of a business message that the business document content is valid or invalid according to the recipient's business rules (e.g. valid part numbers) Business signals help to interrelate the parts of a transaction and are an essential part of what the transaction means; their presence or absence says a lot about the relationship between the sender and the recipient 24 of 43 4/1/2008 3:34 PM

13 Signals as "Process Pipeline" 25 of 43 4/1/2008 3:34 PM Business Acknowledgments as Transaction Properties With the six transaction patterns we can make broad contrasts, but we often need to make finer distinctions Even the same transaction type can "behave" differently within a particular trading community, supply chain, or marketplace because of different business rules, "quality of service" contracts or similar guarantees So we need some additional properties that further define the semantics of transactions to explicitly tell the participating businesses in a transaction what to expect from each other. Each of the six transaction patterns has a characteristic property profile 26 of 43 4/1/2008 3:34 PM

14 Time-Based Transaction Properties Time To Acknowledge Receipt -- The time in which a recipient of a document must respond with an Acknowledge Receipt business signal Time To Acknowledge Acceptance -- The time in which a recipient of a business document must respond with an Acknowledgement Acceptance business signal Time To Perform -- The time in which the responding party must respond with the expected business document 27 of 43 4/1/2008 3:34 PM Other Transaction Properties Authorization Required -- The sender must sign the document and the recipient must validate the signature and the role associated with the signature Non-Repudiation of Origin and Content -- The sender must store the business document in its original form for a duration mutually agreed upon in a trading partner agreement; the non-repudiation process includes validating the identity of the sender and the integrity of the content Non-Repudiation of Receipt -- The sender of the receipt is required to store the Acknowledgement Receipt for the mutually agreed upon time period; the non-repudiation process includes validating the identity of the sender and the integrity of the content 28 of 43 4/1/2008 3:34 PM

15 RosettaNet Transaction Properties Profile 29 of 43 4/1/2008 3:34 PM Business Process Concept of "Collaboration" Two or more business transactions can be sequenced to carry out a business collaboration A business collaboration is a series of activities carried out by two or more partners for the purpose of achieving a business goal; these activities are business transactions These transactions have more context in common with each other than with transactions that perform other parts of the business process 30 of 43 4/1/2008 3:34 PM

16 Meaningful and Necessary Semantic Overlap The set of transactions in a collaboration have meaningful and necessary semantic overlap with each other They have parties/actors in common The overlap must be necessary -- two parties must need to know about each of their transactions with a third party for the set of transactions to be collaborative 31 of 43 4/1/2008 3:34 PM Example: Collaborations in Drop Shipment 32 of 43 4/1/2008 3:34 PM

Example: Registering for Classes 33 of 43 4/1/2008 3:34 PM Choreography The choreography describes the sequence and transition between business transactions that make up a business collaboration.

17 Example: Registering for Classes 33 of 43 4/1/2008 3:34 PM Choreography The choreography describes the sequence and transition between business transactions that make up a business collaboration. From a "top-down" modeling perspective, the business transactions are re-usable (or "pluggable") components into collaborations you could have a collaboration that mixes RosettaNet business transactions with UBL transactions 34 of 43 4/1/2008 3:34 PM

Choreography, Orchestration, and Workflow Choreography is also used in a more precise sense to distinguish different patterns of process control We use choreography where there is distributed

18 Choreography, Orchestration, and Workflow Choreography is also used in a more precise sense to distinguish different patterns of process control We use choreography where there is distributed coordination with equivalent responsibility or where we don't need to take a position on how the process is controlled In an orchestrated process, one of the two parties serves as the conductor or it is controlled by an intermediary (the "traffic cop" analogy) Workflow is a choreographed process that includes people as participants 35 of 43 4/1/2008 3:34 PM "Business Process Specification Schema" 36 of 43 4/1/2008 3:34 PM

19 A BPSS Order Management Collaboration 37 of 43 4/1/2008 3:34 PM BPSS XML Representations 38 of 43 4/1/2008 3:34 PM

20 BPEL Order Management 39 of 43 4/1/2008 3:34 PM BPEL XML For Order Management 40 of 43 4/1/2008 3:34 PM

21 BPSS vs. BPEL The BPSS and BPEL process metamodels are similar because they both specify the parties involved in the process, the documents or messages they exchange, and the sequencing or choreography of the exchange But significant differences: BPSS is more conceptual and embodies the ideas of transaction patterns and transaction properties BPEL has constructs for describing processes abstractly, but these are much less widely used than concrete procedural elements that describe the processing flow between web services in a directly executable way BPSS takes a neutral view of the collaboration; BPEL describes a collaboration from the point of view of one of the participants BPSS is preferred by modelers, and BPEL by implementers -- and BPEL is probably built into the software you'll use for web services 41 of 43 4/1/2008 3:34 PM My advice: think BPSS, build in BPEL BPEL4People BPEL (Business Process Execution Language) is an OASIS specification for describing "transactional" business processes, especially between Web-based services While some services might be performed either by a computational/automated service or by a person (e.g., language translation), some services or tasks inherently involve people BPEL4People is an extension of BPEL that contains constructs for "people activities" that can be initiated out of a regular BPEL process attributes / roles for initiating processes or assigning people to carry them out handling timeouts or errors in long-running processes where compensation would be wasteful complex activity patterns like "second opinions," "escalation," "nominations," and "chained execution" 42 of 43 4/1/2008 3:34 PM

22 Readings for April 6 Stephen Eppinger, "Innovation at the Speed of Information" Document Engineering, Chapter 10, "Designing Business Processes with Patterns" 43 of 43 4/1/2008 3:34 PM

20. Business Process Analysis (2)

20. Business Process Analysis (2) DE + IA (INFO 243) - 31 March 2008 Bob Glushko 1 of 38 3/31/2008 8:00 AM Plan for Today's Class Process Patterns at Different Levels in the "Abstraction Hierarchy" Control