Normal Template - ebXMLlists.ebxml.org/archives/ebxml-core/200104/doc00000.doc · Web...

ebXML Proof-Of-Concept

Technical Planning Document for End-to-End eBusiness Demonstration in Vienna version 0.56

Working Draft, April 3, 2001This version:

ebXML Technical Planning Document for End-to-End eBusiness Demonstration in Vienna - Version 0.56

Previous version:ebXML Technical Planning Document for End-to-End eBusiness Demonstration in Vienna - Version 0.55

Authoro Sig Handelman [[email protected]]

o Mark Hale [[email protected]]

Contributorso William Cox [[email protected]]

o Polly Jan [[email protected]]

o Liora Alschuler [[email protected]]

o Matthew Gertner [[email protected]]

o Nita Sharma [[email protected]]

document.doc 5/18/23 1 of 22

1

1

2

3

4

5

6789

101112

13

14

15

16

17

18

19

20

2122

23

24

23

Table of Contents

TABLE OF CONTENTS 2

ABSTRACT 3

SUPPORTING ORGANIZATIONS 3

ORGANIZATIONS AND ROLES 3

MEETING DATE 4

SUBMITTED PROPOSALS 5

FUNCTIONAL REQUIREMENTS 6 1.2 REGISTRY/REPOSITORY 61.3 MESSAGING 61.4 TRADING PARTNER 61.5 BUSINESS PROCESS 61.6 CORE COMPONENTS 71.7 SECURITY 7

EBXML TECHNICAL ARCHITECTURE 8

END-TO-END SCENARIOS FOR EBUSINESS 8

RUNTIME COMPONENTS 11 1.1 BUSINESS PROCESS 111.2 BUSINESS DOCUMENTS 111.3 AGREEMENT 121.4 EXECUTION 12

EBXML CHOREOGRAPHY FOR EBUSINESS 13

MARKETPLACE 15 1.5 BUSINESS PROCESS 151.6 DOCUMENTS 15

EXCHANGE BUSINESS PROCESS 15 1.7 DOCUMENTS 17

PAYMENT AUTHORITY 17 1.8 BUSINESS PROCESS 171.9 DOCUMENTS 18

FINANCIAL INSTITUTION 19 1.10 BUSINESS PROCESS 191.11 DOCUMENTS 19

REPORTING INSTITUTION 19 1.12 BUSINESS PROCESS 191.13 DOCUMENTS 19


4

25

26

27

28

29

30

31

32333435363738

39

40

4142434445

46

474849

5051

525354

555657

585960

5

2 HEALTH LEVEL 7 – eBusiness Track 19

AbstractThe Proof-of-Concept (POC) working group met during the Vancouver ebXML joint meeting held February 12-16, 2001 to begin planning a fully choreographed demonstration for the Vienna ebXML joint meeting. In preparation, proposals were solicited with a January 26, 2001 deadline date for functional characteristics of the various working group specifications to be reviewed. These proposals were originally targeted for a demonstration to be held in conjunction with an ebXML joint meeting to be held in early April 2001. This meeting has been cancelled. The POC WG decided to move forward with the proposal contents for a Vienna choreography. Some of the functional characteristics are based on the speculative state of the specifications in the upcoming months based on the POC WG interaction with the other ebXML working groups. The choreography will be updated accordingly as the specifications reach quality review.

At meetings of the POC Work Group, held March 8 and March 15, it was decided to add a track for HL7 (Health Level 7). It was also decided to augment the Proof of Concept with a demonstration of Complementaty Functions between ebXML Registry and UDDI. We also discussed on March 15 the possibility of bringing in a marketplace, Covisint, to show functionality of ebXML processes with an existing marketplace.

Supporting Organizations VISA International Corporation HL7 Covisint/CommerceOne

Organizations and Roles

A table will be created in this specification outlining the identification of participants in the choreagraphed sequences outlined in this document was well as the support roles for the POC. The roles of the companies include the Market Place and Payment parts of first scenario, and the clinical roles of the HL7 scenario. As in previous POC’s individual companies or companies in partnerships will act in these roles at the demonstration.

The support roles include Certificate Authority, Registry Providers, Providers of Run Time codes for specifications.


661

62

63646566676869707172737475767778

79808182838485

86

878889

90

91

92939495969798

99

100101

7

Meeting DateThe Vienna ebXML joint meeting will be held May 7-11. At the writing of this draft, both a POC plenary demonstration and an open POC demonstration to the public are being discussed. The open demonstration will be tentatively held on May 9.


8102

103104105106107

9

Submitted ProposalsThere were eight proposals submitted for the choreography. The proposals are located on the POC WG private web site for download. The proposals are (in no particular order):

1. ebXML Security and TPA Proof Of Concept, Version 1

2. TRP Multi-Hop with Reliable Messaging Proof Of Concept, Draft Version 0.1

3. TR&P: Reliable Messaging, Scalability and Robustness, January 25, 2001

4. ebXML - Complex Content Exchange, Version 0.1

5. Registry: Flexible discovery through ad hoc queries, Registry Security, January 25, 2001

6. ebXML London POC Proof-Of-Concept - Core Components, Version 0.1

7. ebXML Business Process Editor Toolset Proof Of Concept, Version 1.1

8. Business Collaboration Protocol Specification & Implementation Proof Of Concept


10

108109110111

112

113114

115116

117

118119

120

121122

123124

11

Functional Requirements

The POC WG met on Tuesday, February 13 to define functional properties of the other working group specifications that should be incorporated into the end-to-end demonstration of eBusiness. The work group status in this list has been updated on March 26. The properties include:

1.2 Registry/Repository

Query (Ad Hoc)

CPP Discovery process

Business document discovery

Core components discovery

Dynamic configuration of run-time infrastructure using CPA

Coordination with UDDI. The coordination with UDDI will be included in this specification in a later version.

1.3 Messaging

Multi-hop

Security

Support for multiple transports (HTTP, SMTP, per SOAP enveloping)

Multi-part payloads

ebXML Messaging Spec 98b+

1.4 Trading Partner


Business processes for negotiation of CPA

ebXML Trading Partner 0.93+

1.5 Business Process

Storage of business process in Reg/Rep


Show link of business process in the CPA

Business Process Editor and other tools

Choreography of Business Process expressed in ebXML Schema


12

125

126127128129130

131

132

133

134

135

136

137138139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

13

o XML schema possibility to run Workflow o XML schema loaded into the Registry Classification scheme

CPA rendering through the Business Process Editor

Monitoring of the Business Processes

It is our intent in this Proof of Concept to automate as much as possible the business scenario of the Market Place through the use of Business Process tools. At the same time, the tools may be used for the Health Level 7 scenario.

1.6 Core Components

Storage of core components in RegRep

GUID service as defined in the technical architecture

Inclusion of core components dictionary

Core Components will be used to create Sample Business Documents for the Payment Authority of the Market Place demo. The creation will make use of the following steps.

o A design time interface for assembly and context rules per the ebXML Specification. The documents will be created ahead of the demo; the rules will be documented in this specification.

o A run-time interface to show the documents and the construction rules can be presented as part of the Proof of Concept.

1.7 Security

XML DSIG for Authentication Purposes

Include security at the messaging level

Secure access to registry contents

Security of payloads in messages optional between Trading Partners

We are planning for a Certifcate Authority to be available during the Proof of Concept for Security Purposes


14156157

158

159

160161162163

164

165

166

167

168169170171172173174175

176

177

178

179

180

181182

183

184

15

ebXML technical ArchitectureThe choreography for the eBusiness demonstration is designed to step through the various aspects of the ebXML technical architecture. The three phases that are important for implementation are highlighted in Figure 1. These include:

Design

During design time, the ebXML business processes, core components, dictionaries are installed in the registry. This also includes maintenance activities.

Configuration

Arrangements to conduct business are done during configuration time. This includes binding business processes and business documents to business collaborations by creating and registering collaborative protocol profiles. From here, collaborative protocol agreements are formed in which business can be conducted. Finally, these agreements provide the basis for configuring the runtime systems.

Runtime

Real time business activities are conducted. Systems configured under the collaborative protocol agreements exchange of business documents according to pre-defined business processes. EbXML messaging is used to communicate.

BusinessService

BusinessService

TradingPartner

BusinessProcess

CoreComponents

Context

RepositoryRegistry

TR&P TR&P

BusinessService

BusinessService

TradingPartner

BusinessService

BusinessService

TradingPartner

BusinessProcess

CoreComponents

Context

RepositoryRegistryRepositoryRegistry

TR&P TR&PTR&P TR&P

Design

Configuration

Runtime

Figure 1. ebXML Technical Architecture

It is important to remember that these phases are rough guidelines. In implementations, interactions among all of the ebXML architecture components will involve ebXML messaging and agreements.


16

185186187188189

190

191192193

194

195196197198199200201

202

203204205206

207208209210211212

17

End-to-end Scenarios for eBusiness

Market Place

A corporate buyer wants to purchase corporate supplies using a Market Place and a Payment System

A corporate supplier has available wares for Market Place users and is willing to accept payment through the Payment System

The eBusiness scenario looks as shown in Figures 2 and 3. Figure 2 is included for its details on the Credit (Payment Authority) while Figure 3 has the total picture.

These are pictures that have been taken from the Business Process document provided by Nita Sharma. They will be normalized into one case over the next week.

Figure 2. Payment Authority Emphasis


18213

214

215216

217218219

220221222223

224225226

227228

229

230

19

Figure 3. End-to-End Choreography


20

231232

233

234

21

Runtime ComponentsThe POC WG has implemented several demonstrations and has found it useful to categorize the elements that go into a business process. These elements are derived from Figure 4.

Request

Response

Company X Company Y

CPP CPP

CPA

BusinessDocument

Header

Message Ack

Message Ack

Figure 4. Anatomy of a Business Process

1.1 Business ProcessThe Business Processes are comprised of request and response transactions between two parties. These transactions are asynchronous. More complex processes involve third parties or multiple request and responses. A response indicates the request has been processed and a business decision has been made. The business-level transactions are typically combined with asynchronous message-level acknowledgements for receipt of a completed data set.

1.8 Business DocumentsA business message is sent during each transaction of the business process. The message is comprised of a header and business document (e.g. payload). All headers and payloads need to be explicitly called out for the demonstration.


22

235236237238

239240

241242243244245246247248249

250251252253254

23

1.9 Agreement

The data for the business process and business documents are explicitly called out in the CPA. This includes such things as: end points for the transactions, protocol, business documents associated with the transaction, etc. The CPA can be used to configure interoperable implementations at run-time.

1.10 ExecutionThere are a number of variables in the implementation environment that do not show up in the schematic that do need to be configured as well. These include:

Assignment of domain names and IP addresses for closed demonstrations

Assignment of DUNS+4 numbers for demonstrations with RosettaNet payloads

Screenshots for underlying software. Most ebXML components are services. For a demonstrations, simple GUI interfaces need to be created to illustrate the functional aspects.


24255256257258259260

261262263264

265266267268269270271

25

ebXML Choreography for eBusinessThe choreography is broken into the three segments that comprise the ebXML architecture as described earlier: design, configuration and runtime.

The choreography of this part of the business process will be automated through the use of the Business Editor.

Step FunctionalityDesign

1. Edit Business Process for secure payment

2. Register secure payment Business Process in Registry/Repository

BP support in Reg/Rep

3. Demonstrate Core Components dictionary

4. Select secure payment Core Components from dictionary

5. Form Business Document from Core Components

6. Register Business Document in Registry/Repository

BD support in Reg/Rep

A.Focus on Registry/Repository security Security

Configuration

1. Show a secure seller CPP template

2. Show ability to edit CPP template

3. Show Business Document discovery in Registry/Repository(Uses drilldown)

Drilldown

4. Show Business Process discovery in Registry/Repository(Uses drilldown)

Drilldown

5. Show interface to form CPP with BD and BP

CPP has all necessary components

6. Register CPP in Registry/Repository CPP support in Reg/Rep

7. Registry interaction (merge, delete, etc.)

8. Secure buyer discovers a secure seller in the Registry/Repository(Uses Ad Hoc query)

Ad Hoc Support


26

272273274275

276277

278

279

27

9. Secure buyer retrieves secure seller CPP from Registry/Repository

10. CPA formation for secure payment

11. Approval is gained by secure buyer sending CPA to seller and acknowledgement returned

12. CPA is used to configure secure payment runtime environment

Step FunctionalityRuntime - Marketplace

0. Buyer discovery of seller in marketplace. (Already done in configuration.)

Runtime - Exchange

1. Secure seller creates ‘Product Catalogue’

A.Multipart catalogue Test payload support in messaging

B.Message sniffer Shows messaging properties

2. Secure buyer contacts exchange for ‘Product Catalogue’

3. ‘Product Catalogue’ exchange is coordinated by Exchange

A.Show seller interacting with exchange through a hub

Complex routing

B.Show exchange interacting with buyer using reliable messaging

Reliable messaging

C.Show multiple payload types for exchange content

Payload/Business Document Support

D.Show multiple transport capability for buyer and seller interaction with exchange

Messaging is transport agnostic

Runtime – Payment Authority

4. Secure buyer submits ‘Arrange Payment’ to Payment Authority

A.Focus on how secure payload and messaging

Security

5. Secure seller receives ‘Authorize Payment’ from Payment Authority

6. Secure seller arranges ‘Shipment’ to the secure buyer


28

29

7. Payment Authority sends an ‘Invoice’ to the secure buyer

Runtime – Financial Institution

8.

Runtime – Reporting Institution

9.

Marketplace


The following pictures will be updated with the addition of material from the Business Process Team.

Buyer RegRep SellerCPP Registration

Seller CPP Query

Seller CPP Retrieval

CPA Approval

1.12 Documents

Exchange Business Process


30

280

281

282

283284285

286

287

288

31

Buyer Exchange Seller

Acknowledgement

Send Product List

Acknowledgement

Send Price List

Business TransactionMessaging Level Ack

Inclusion of Hub and Reliable Messaging components.

Buyer Exchange Seller

Acknowledgement

Send Product List

Acknowledgement

Send Price List

Business TransactionMessaging Level Ack

HubMSH MSH


32

289290291

292

293294

33

1.13 Documents

The POC WG would like to take a sidebar during the demonstration to show multiple payload support. A single payload will need to be selected for the baseline demonstration. The selection will be from RosettaNet and xCBL payloads since they were submitted by the proposal deadline. Payload choice should be made no later than six weeks prior to the Vienna demonstration.

This table will require closure by April 10.

Institution Documents Comments Contact

RosettaNet PIP21 (Catalogue)PIP3A4 (Purchase Order)

Submitted by proposal deadline but not tied to any specifications

Jeffrey Eck, GE

Hicham Bahi, Documentum

CommerceOne XCBL Submitted by proposal deadline

Dimitri Cherkassky, Commerce One

OAG Glenn Thomsen, Killdara

EDI Shows legacy compatibility

Jeffrey Eck, GE

Payment Authority



34295296297298299300301

302

303

304

305

306

35

: SecureBuyer Exchange : Exchange

: PaymentAuthority

: SecureSeller

BuyingMessage

CreditRequest

CreditAuthorization

ShipmentNotice

Invoice

The Business Process using the Exchange simplifies the operation of the Payment Authority, since the Exchange has details of the Secure Buyer. In this model the Secure Buyer selects the goods to be bought from the Exchange, the Exchange requests a Credit Request for the goods, and the Payment Authority does a Credit Authorization to the Secure Seller, who now sends a Shipment Notice to the Secure Buyer. At month’s end the Payment Authority sends an Invoice to the Secure Buyer.

1.15 Documents

Core Components will be used to create 4 documents for the interactions between the Secure Buyer, Secure Seller, Exchange and Payment Authority. They include:

1. Credit Request.

2. Credit Authorization.

3. Shipment Notice.


36

307308309310311312313314

315

316317318319

320

321

322

37

4. Invoice.

In the Credit Request and Credit Authorization in addition to Core Components we will use the model of “Secure Electronic Transactions (SEC) Version 1.0” Payload

Financial Institution


1.17 Documents

Reporting Institution


1.19 Documents

2 HEALTH LEVEL 7 – eBusiness Track

Description: HL7 Track in Vienna ebXML POC

The HL7 track in the POC will demonstrate the exchange of information between a physician office, a hospital, a laboratory and a third-party clinical data repository or portal. In this scenario, a patient comes to the physician (primary care provider or PCP) for an examination. A record of the exam is created (an encounter note) and the physician decides to admit the patient to a hospital for further procedures and diagnosis. The physician office sends the hospital an admit message (registration) and, optionally, sends the encounter note as well.

At the hospital, the patient has a second examination. As a result, a laboratory test is ordered and a second encounter note


38323

324325326327

328

329

330

331

332

333

334

335

336

337

338

339

340

341342343344345346347348349350

351352

39

is created. The lab order is sent to a laboratory. The laboratory responds with a results message. The lab results are sent to the hospital and to the PCP.

The clinical database/portal can receive copies of all information artifacts such that at the end of the sequence, it contains:

PCP encounter note

Registration message

Hospital encounter note

Lab order

Lab result

This demonstration is similar to ones staged by HL7 in the past with these important differences:

The transport and routing will be defined by ebXML

Security will meet ebXML specifications

HL7 vendors will partner with ebXML vendors to accomplish secure, remote transactions

Collaboration Partner Agreements will be created describing the role and interactions of all parties

In summary the scenario for the Health Care Demo as proposed looks as is found in Figure 5.


40353354355

356357358

359

360

361

362

363

364365366

367

368

369370

371372

373374375

41

1st Phase, examination by PCP 2nd Phase, PCP

Registers Patient for Hospital, sendsencounter note

3rd Phase, Hospital peforms Procedure

4th Phase, Hospital Orders Lab Test

5th Phase, Lab sends Results to Clinical Database, PCP and Hospital

Patient

Procedure

Order Lab Test

Examination

Registration

Laboratory

Clinical Database-Repository

Hospital

PCP

Send Results

Contains:* PCP encounter note* registration* hospital encounter note* lab order* lab results

Figure 5. Health Scenario USE CaseThe Roles of the Health Scenario are explained in the Sequence Diagram found in Figure 6.


42

376

377

378379

43

: Patient : PCP : Hospital : Laboratory : Clinical

Database-RepositoryExamination

Registration

ProcedureOrder Lab Test

Submit Results

Callup Results

Figure 6. Sequence Diagram of HL7 Scenario


44

380

381

382

45

Normal Template - ebXMLlists.ebxml.org/archives/ebxml-core/200104/doc00000.doc · Web...

Documents

Transcript of Normal Template - ebXMLlists.ebxml.org/archives/ebxml-core/200104/doc00000.doc · Web...