← Prev in month ← Prev in thread

FW: BPEL Use Cases for Transaction handling service

From
John Evdemon <>
Date
2004-03-09T21:33:49+00:00
ID
Thread
FW: BPEL Use Cases for Transaction handling service
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:] 

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 
		
	

 

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 
← Prev in month ← Prev in thread