Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS) - PowerPoint PPT Presentation

electronic business extensible markup language business process specification schema ebxml bpss n.
Skip this Video
Loading SlideShow in 5 Seconds..
Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS) PowerPoint Presentation
Download Presentation
Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS)

play fullscreen
1 / 33
Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS)
Download Presentation
Download Presentation

Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS)

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Electronic Business eXtensible Markup Language -Business Process Specification Schema (ebXML-BPSS) Mike Richmond 11/21/2003

  2. Outline: • Introduction • Key Concepts • Business Transaction Semantics • XML BPSS Example

  3. What is ebXML? • A set of specifications that enhance e-business activities by allowing business process collaborations between 2 or more parties. • Started in 1999 as a joint effort between UN/CEFACT and Oasis • Oasis – A global consortium that works to develop and implement e-business standards. • UN/CEFACT – United Nations Center for Trade Facilitation and Electronic Business • Goal: create specifications to allow worldwide platform independent business transactions.

  4. Why ebXML? • Needed a way to unify a variety of existing XML specifications. • Electronic Data Interchange (EDI) is no longer seen as a viable method of conducting e-business. • Current specification for e-business transactions • Drawbacks: • High startup costs • Inconsistent formats • Implementation limited to large organizations • ebXML’s Benefits: • Common message structure enables worldwide communication • Provided free of charge • Scales well to any organization size

  5. ebXML and W. S. • "Web Services and ebXML are not competing frameworks. They can be viewed as serving two different B2B models and will continue to be used in parallel.“ - From the Business-to-Business Frameworks for IDA Networks study published in September 2003 by the European Commission's IDA (Interchange of Data between Administrations) [obtained from www.ebxml.org] • ebXML defines new ways to use the existing standards: • SOAP – ebXML Messaging Services use SOAP message headers and http protocols. • UDDI – the ebXML Registry mimics and works as a sub-directory of the UDDI registry. • WSDL – ebXML BPSS and CPP give it the functionality of WSDL plus error handling and failure scenarios.

  6. Diagram: Key concepts Requestor Responder - ebXML BPSS v1.10 p.9

  7. Business Transactions: “an atomic unit of work in a trading arrangement between two business partners.” - ebXML BPSS v1.10 Consists of 2 Roles: Requestor – the initiator of the transaction. Responder – a response is necessary for a “legal” transaction to take place. Ex: request catalog, send purchase order… Binary Collaboration: A set of business transactions between business partners. 2 Types: Binary – Either a business transaction or another Binary collaboration (allows for recursion). Multi – bundled binary collaborations - deprecated in ebXML BPSS v1.1 Ex: step 1 = request catalog, step 2 = send catalog Key Concepts:

  8. Document Flows: Defines the nature of a business transaction. 2 Types: One-way = notification Two-way = conversation (allows for contractual agreements) Choreography: Specifies which transaction should be executing at any given time. Describes the ordering and transitions between transactions and recursive collaboration instances. Key Concepts II:

  9. Business Transactions • An event where one or two document flows happen between the receiving and responding Business Activities. • Business Activities should not be thought of as “buyer” or “seller” roles, but kept vague. • Example Business Transaction: • A “Cancel Purchase Order” request may be sent out by either role in the business transaction. • Acknowledgements (Business signals) are used to control the content and usage of business transactions.

  10. Business Transaction Syntax <BusinessTransaction name="Catalog Request"> <RequestingBusinessActivity name="requestCatalog" <DocumentEnvelope businessDocument="Catalog Request"/> </RequestingBusinessActivity> <RespondingBusinessActivity name="sendCatalog"> <DocumentEnvelope isPositiveResponse="true" businessDocument="Catalog" /> </RespondingBusinessActivity> </BusinessTransaction>

  11. A More Detailed version: <BusinessTransaction name="Check Credit" nameID="122A3DD33" isGuaranteedDeliveryRequired="true"> <RequestingBusinessActivity name="checkCredit" nameID="122A3E833" isAuthorizationRequired="true" isIntelligibleCheckRequired="true" isNonRepudiationReceiptRequired="true" isNonRepudiationRequired="true" timeToAcknowledgeAcceptance=" PT30S" timeToAcknowledgeReceipt=" PT10S"> <DocumentEnvelope isAuthenticated="persistent" isConfidential="persistent" isTamperDetectable="persistent" businessDocument=" Credit Request" businessDocumentIDREF="122A3F613C"/> </RequestingBusinessActivity>

  12. <RespondingBusinessActivity name="confirmCredit" nameID="122A3E863" isAuthorizationRequired="true" isIntelligibleCheckRequired="true" isNonRepudiationReceiptRequired="true" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="PT10S"> <DocumentEnvelope isPositiveResponse="false" isAuthenticated="persistent" isConfidential="persistent" isTamperDetectable="persistent" businessDocument="Credit Denied" businessDocumentIDREF="122A3F8E3"/> <DocumentEnvelope isPositiveResponse="true" isAuthenticated="persistent" isConfidential="persistent" isTamperDetectable="persistent" businessDocument="Credit Approved" businessDocumentIDREF="122A3F6C3"> <Attachment name=”Credit Report” mimeType=”XML” businessDocument=”Credit Rating” businessDocumentIDREF="122A3F8E4" isConfidential=”none” isTamperDetectable=”none” isAuthenticated=”none”> </Attachment> </DocumentEnvelope> </RespondingBusinessActivity> </BusinessTransaction>

  13. Message Flow in a Business Transaction Request receiptAcknowledgement Signal AcceptanceAcknowledgement Signal Requesting Activity Responding Activity Response receiptAcknowledgement Signal AcceptanceAcknowledgement Signal Signals indicate the current state of the transaction.

  14. Business Document Flow • Conceptually modeled as the passing of Document Envelopes between the request and response ends of a business transaction. • Document envelopes carry only one primary business document, but may have any number of possible documents specified. • Example: A purchase order request is sent to a vendor (envelope from requestor) and the vendor replies with one of three predefined document envelopes: acceptance, denial, or partial acceptance .

  15. Binary Collaborations • Defined to be between 2 roles: the initiator and the responder. • Two types: • Business transaction activity • Collaboration activity – a binary collaboration executed within another binary collaboration. • isInnerCollaboration: boolean value that specifies whether the activity may be executed by itself or only within another collaboration. • Allows greater flexibility in defining how collaborations take place. • Collaboration Protocol Agreements (CPA) govern how they take place

  16. <BinaryCollaboration name="Firm Order" nameID="122A38D93" initiatingRoleIDREF=”122A38DA3” timeToPerform="P1D"> <Role name="buyer" nameID="122A38DA3"/> <Role name="seller" nameID="122A38DA5"/> <Start toBusinessState=”Place Order” toBusinessStateIDREF=”122A39C23” /> <BusinessTransactionActivity name="Place Order" nameID="122A39C23" businessTransaction="Create Order" businessTransactionIDREF="122A3DD33" fromRole="buyer“ fromRoleIDREF="122A38DA3" toRole="seller“ toRoleIDREF="122A38DA5" isConcurrent="true" isLegallyBinding="false" timeToPerform="P2H"/> <Failure fromBusinessState="Place Order" fromBusinessStateIDREF="122A39C23" conditionGuard="AnyProtocolFailure"/> <Success fromBusinessState="Place Order" fromBusinessStateIDREF="122A39C23" conditionGuard="BusinessSuccess | BusinessFailure"/> </BinaryCollaboration>

  17. Choreography • Purpose: “to specify which Business Transaction Activity and/or Collaboration Activity should happen at any point in time.” - ebXML BPSS v1.10 • How: keeping track of the current business state and any transitions between business states. • Transitions are used to created the nested activities mentioned earlier. • Business State examples: start, completion, fork, join, decision, business transaction activity, business collaboration activity. • In the UML model, all the examples are generalizations of the <<abstract>> business state.

  18. How BPSS fits into the ebXML Framework - ebXML BPSS v1.10 p.14

  19. Business Transaction Semantics • Transactions are set up to provide*: • Predictability – Roles, time bounds of signal passing, and determination of success or failure are all clearly defined. • Nonrepudiation • Security • Reliability • *Assuming reliable message passing and request/response acknowledgements are used.

  20. Timeouts • Timers are used to govern how long roles should wait when engaging in transactions. • Timeout values are specified within the business transaction XML forms using timetoAcknowledgeAcceptance and timetoAchnowledgeReceipt tags. • Values take the form: • P1H – one hour • P30S – 30 seconds • “All timers start when the initial requesting business document is sent.” - ebXML BPSS v1.10 • Problem: initial document transport latency will cause the timers to start at different times.

  21. Business Service Interface (BSI) Responsibilities: • Detect start of transactions • Detect transfer of control within transactions • Detect successful transaction completion • Detect unsuccessful transactions • Timeouts • Exceptions to protocol rules • Handle negative receipt/authorization signals

  22. States of the Business Transaction Protocol From message flow in a business transaction diagram Requesting Activity Protocol Success Protocol Failure Busn. Success Busn. Failure Success Failure - ebXML v1.1 Figure 16 p.43

  23. Show diagram on p. 54 => 62

  24. Nonrepudiation • Receipt acknowledgement ensures that both parties involved can legally enforce the agreement (the legally binding aspect of it has been deprecated). • Takes two forms: • 1: (unenforceable) • Each party (requestor/responder) is asked to save copies of all documents and envelopes involved in a transaction. • 2: (enforceable) • The isNonRepudiationOfReceiptRequired parameter is used in every message to make sure the receiver (either the requestor or responder) acknowledges the message. • A lack of response from the receiver will make the transaction null.

  25. Authorization Activated when the following parameter is included in a document. isAuthorizationRequired Receiving side of the activity must authorize the document by comparing it to a previously supplied set of values (by sender). Deprecated in version ebXML BPSS v1.1 Document Uses 3 messages with null, transient, or persistent values: isConfidential isTamperDetectable isAuthenticated Transient – security provided through the communication channel; tests ensure that it was not tampered with during transfer. Persistent – ensures the information remains confidential through the use of encryption. SecurityAuthorization and document integrity may be enforced through ebXML.

  26. Reliability • Documents and signals can be trusted to reach their destinations. • Parameter isGuaranteedDeliveryRequired forces the responding party to choose a communication channel where there is a delivery guarantee. • Instructs the CPP and CPA on the level of service required for this transaction.

  27. XML BPSS Example: Document Specifications <?xml version="1.0" encoding="UTF-8"?> <ProcessSpecification name="Simple" version="1.1" nameID="Simple-2434134" xmlns="http://www.untmg.org/downloads/General/approved/BPSS-v1pt10.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.untmg.org/downloads/General/approved/BPSS-v1pt10.xsd C:\projects\bpss\bpss_1.1\ebBPSS1.08b.xsd"> <!-- Business Documents --> <BusinessDocument name="CatalogRequest“specificationLocation="http://www.xyx.com/CatalogReq.xsd"/> <BusinessDocument name="Catalog" specificationLocation="http://www.xyx.com/Catalog.xsd"/> <BusinessDocument name="Purchase Order" specificationLocation="http://www.xyx.com/PO.xsd"/> <BusinessDocument name="PO Acknowledgement" specificationLocation="http://www.xyx.com/POAck.xsd"/> <BusinessDocument name="Credit Request" specificationLocation="http://www.xyx.com/CreditReq.xsd"/> <BusinessDocument name="Credit Confirm" specificationLocation="http://www.xyx.com/CreditCon.xsd"/> <BusinessDocument name="ASN" specificationLocation="http://www.xyx.com/CatalogASN.xsd"/> <BusinessDocument name="CreditAdvice" specificationLocation="http://www.xyx.com/CreditAdvice.xsd"/> <BusinessDocument name="DebitAdvice" specificationLocation="http://www.xyx.com/DebitAdvice.xsd"/> <BusinessDocument name="Invoice" specificationLocation="http://www.xyx.com/Invoice.xsd"/> <BusinessDocument name="Payment" specificationLocation="http://www.xyx.com/Payment.xsd"/> <BusinessDocument name="Inventory Report Request" specificationLocation="http://www.xyx.com/InvReq.xsd"/> <BusinessDocument name="Inventory Report" specificationLocation="http://www.xyx.com/InvRep.xsd"/>

  28. Business Transaction Specification <Package name="Ordering"> <!-- Here are some of the Business Transactions needed --> <BusinessTransaction name="Catalog Request"> <RequestingBusinessActivity name="RequestCatalog"> <DocumentEnvelope businessDocument="Catalog Request"/> </RequestingBusinessActivity> <RespondingBusinessActivity name="SendCatalog"> <DocumentEnvelope isPositiveResponse="true" businessDocument="Catalog"/> </RespondingBusinessActivity> </BusinessTransaction> <BusinessTransaction name="Create Order"> <RequestingBusinessActivity name="SendOrder" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P2D" timeToAcknowledgeAcceptance="P3D"> <DocumentEnvelope businessDocument="Purchase Order"/> </RequestingBusinessActivity> <RespondingBusinessActivity name="SendPOAcknowledgement" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P5D"> <DocumentEnvelope isPositiveResponse="true" businessDocument="PO Acknowledgement"/> </RespondingBusinessActivity> </BusinessTransaction> …… all documents have associated transaction specifications

  29. Binary Collaboration Specification <!-- Now one of the Binary Collaborations --> <BinaryCollaboration name="Request Catalog" initiatingRoleID="1122B1"> <Role name="requestor" nameID="1122B1"/> <Role name="provider" nameID="2211A1"/> <Start toBusinessState="Catalog Request"/> <BusinessTransactionActivity name="Catalog Request" businessTransaction="Catalog Request" fromRole="requestor" toRole="provider"/> <Success fromBusinessState="Catalog Request" conditionGuard="Success"/> <Failure fromBusinessState="Catalog Request" conditionGuard="Failure"/> </BinaryCollaboration>

  30. Compound Binary Collaboration <!-- A compound Binary Collaboration for illustration purposes--> <BinaryCollaboration name="Credit Charge" initiatingRoleID="8132B1"> <Role name="charger" nameID="8132B1"/> <Role name="credit service" nameID="8122B1"/> <Role name=“payor" nameID="7122B1"/> <Start toBusinessState="Credit Inquiry"/> <CollaborationActivity name="Credit Inquiry" binaryCollaboration="Credit Inquiry" fromRole="charger" toRole="credit service"/> <CollaborationActivity name="Credit Payment" binaryCollaboration="Credit Payment" fromRole="charger" toRole="payor"/> <Success fromBusinessState="Credit Payment" conditionGuard="Success"/> <Failure fromBusinessState="Credit Payment" conditionGuard="Failure"/> <Transition fromBusinessState="Credit Inquiry" toBusinessState="Credit Payment"/> </BinaryCollaboration>

  31. Multiparty Collaboration (deprecated) <!-- First the overall MultiParty Collaboration --> <MultiPartyCollaboration name="DropShip"> <BusinessPartnerRole name="Customer"> <Performs role="requestor" roleIDREF="1122B1"/> <Performs role="buyer" roleIDREF="1122B2"/> <Transition fromBusinessState="Catalog Request" toBusinessState="Create Order"/> </BusinessPartnerRole> <BusinessPartnerRole name="Retailer"> <Performs role="provider" roleIDREF="2211A1"/> <Performs role="seller" roleIDREF="1122B3"/> <Performs role="creditor" roleIDREF="9122B1"/> <Performs role="buyer" roleIDREF="1122B2"/> <Performs role="payee" roleIDREF="6122B1"/> <Performs role="payor" roleIDREF="7122B1"/> <Performs role="requestor" roleIDREF="1122B1"/> <Transition fromBusinessState="Create Order" toBusinessState="Check Credit"/> <Transition fromBusinessState="Check Credit" toBusinessState="Credit Payment"/> </BusinessPartnerRole> <BusinessPartnerRole name="DropShip Vendor"> <Performs role="seller" roleIDREF="1122B3"/> <Performs role="payee" roleIDREF="6122B1"/> <Performs role="provider" roleIDREF="2211A1"/> </BusinessPartnerRole> <BusinessPartnerRole name="Credit Authority"> <Performs role="credit service" roleIDREF="8122B1"/> <Performs role="payor" roleIDREF="7122B1"/> </BusinessPartnerRole> </MultiPartyCollaboration>

  32. Sources: • EbXML committee: www.ebxml.org • Oasis: www.oasis-open.org • UN/CEFACT: www.unece.org/cefact