FW: BPEL Use Cases for Transaction handling service

["John Evdemon" <jevdemon@microsoft.com>]

Here is David’s contribution.  I will be folding these into the new Use Case templates along with the other Use Cases we have already completed.

 

Please let me know if you have any questions.

 

Thanks!

 

John

 

PS: Thanks especially to David for contributing this work!

 

---

From: David RR Webber [mailto:david@drrw.info]
Sent: Tuesday, March 09, 2004 12:08 PM
To: John Evdemon
Subject: BPEL Use Cases for Transaction handling service
Importance: High

 

John,

 

As discussed.  Sorry I did not get these done for yesterdays meeting.

 

Life intervened!

 

Anyway - attached two HTML files describing these.

 

Do these look OK?

 

If so - next step I can submit them (or you can for me) to the

UC SC Kavi document system and we can get everyone's

comments and thoughts.

 

Once we have that honed - then we can proposed a BPEL / CAM

binding to implement this.

 

Thanks, DW

Title: BPEL IV&I UC #1

BPEL Use Case SC Use Case
UC ID:	IV-UC#1	Priority (L/M/H) :	Medium
Use Case :	eBusiness Transaction binding with external service - Validation
Description :	An industry group needs to have a consistent way of documenting the information exchanges for the scenarios its members are implementing. Further more implementers need a consistent way of ensuring compliance checking and testing. Each individual participant needs a consistent way of applying context to their specific interchange transactions. This can be provided as an external service that a BPEL instance can invoke. BPEL itself has only limited transaction information management tools. Therefore BPEL should be able to receive a document transaction and then pass that XML content to an external service, along with binding information around the type of content and context details so that the external service can perform that validation. Included in the external service is the ability to report back to BPEL, and or, invoke external process step(s) that may then manage the results of the validation. The OASIS CAM TC team has created a specification and toolset that can act as an external service in this way. A WSDL definition of a CAM process can provide the linkage between the CAM process and the BPEL. The BPEL will need to package the XML content that requires validation and pass that to the CAM process. The CAM process will return to the BPEL process the outcome from the external validation service.
Actors :	Trading partners wishing to exchange business transactions, implementers wishing to do industry conformance testing.
Pre-Conditions:	XML content and associated CAM template of rules to be validated and applied. Where applicable a context template that defines the localization parameters and their settings to be applied during the validation.	Post-Conditions:	Return to the BPEL process a result set indicating success or failure and if failure reporting of that. The CAM template may also contain mitigation actions for various error conditions that may be performed.
Basic Flow :	BPEL process receives reply containing XML transaction BPEL process initializes external service call with details of that transaction and the associated validation template and context parameters along with the WSDL details. BPEL process invokes the external validation service as webservice, passing the XML content to the external service, along with the binding details. CAM processor performs the validation directives using the CAM template referenced. CAM processor returns to the BPEL process success/failure reporting.
Alternate Flow :	none
Exceptions :	none
Includes Use Cases:	none	Special Requirements:	None
Assumptions:	Valid CAM template exists for XML transaction content to be checked.
Use Case Relationships:	None	Issues :	none
Examples:	Automotive industry IV&I compliance tests for the 4 supply chain inventory on-hand transactions they are implementing.
proposer david@drrw.info

 

Title: BPEL IV&I UC #2

BPEL Use Case SC Use Case
UC ID:	IV-UC-#2	Priority (L/M/H) :	Medium
Use Case :	eBusiness Transaction binding with external service - Transaction Assembly
Description :	An industry group needs to have a consistent way of documenting the information exchanges for the scenarios its members are implementing. Further more implementers need a consistent way of ensuring transaction content is assembled according to the industry definitions of those transactions. Each individual participant needs a consistent way of apply context to their specific interchange transaction assembly. This can be provided as an external service that a BPEL instance can invoke. BPEL itself has only limited transaction information management tools. Therefore BPEL should be able to receive information that is required to compose a document transaction and then pass that XML content to an external service, along with binding information around the type of content and context details so that the external service can perform that transaction assembly. Included in the external service is the ability to return back to BPEL the completed transaction, or dispatch it via a messaging service itself. The results of the assembly may also be returned as a success/failure report. The OASIS CAM TC team has created a specification and toolset that can act as an external service in this way. A WSDL definition of a CAM process can provide the linkage between the CAM process and the BPEL. The BPEL will need to package the XML content that requires assembly and pass that to the CAM process as an XML structure. That structure may resemble the final transaction content structure, but does not have to exactly match it. The CAM process will assemble the information into the exact structure layout and details in XML that are specifically required. CAM has an extensive set of functions that permit manipulation of data strings and content formatting. The CAM process will return to the BPEL process the outcome from the external assembly service, along with either a completed transaction document, or a delivery result status.
Actors :	Trading partners wishing to exchange business transactions, implementers wishing to define industry transaction formats for members use.
Pre-Conditions:	XML content and associated CAM template of rules for transaction assembly to be applied. Where applicable a context template that defines the localization parameters and their settings to be applied during the transaction assembly.	Post-Conditions:	Return to the BPEL process a result set indicating success or failure and if failure reporting of that. Optionally return to the BPEL process a completed and valid transaction document. The CAM template may also contain delivery instructions for the transaction content itself.
Basic Flow :	BPEL process receives reply containing XML transaction details from one or more sources. The BPEL collects this information until it is ready to be dispatched. BPEL process initializes external service call with details of that transaction and the associated assembly template and context parameters along with the WSDL details. BPEL process packages the raw transaction information as a simple XML structure that will be passed to the external assembly service. BPEL process invokes the external assembly service as webservice, passing the XML content to the external service, along with the binding details to be used. CAM processor performs the transaction assembly directives using the CAM template referenced. CAM processor returns to the BPEL process success/failure reporting. CAM process optionally returns to the BPEL process a completed transaction document. CAM process optionally itself delivers the transaction content via another message delivery service.
Alternate Flow :	none
Exceptions :	none
Includes Use Cases:	none	Special Requirements:	None
Assumptions:	Valid CAM template exists for XML transaction content to be checked. BPEL process creates a package of transaction content to be formatted into the resulting transaction.
Use Case Relationships:	None	Issues :	none
Examples:	Automotive industry IV&I transaction formats for the 4 supply chain inventory on-hand transactions they are implementing.
proposer david@drrw.info