ebXML Proof-Of-Concept - ebXML - Enabling A Global ... · Web viewebXML London POC Proof-Of-Concept...

ebXML Proof-Of-Concept

Technical Planning Document for End-to-End Demonstration in Vienna version 0.63

Working Draft, April 25, 2001This version:

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

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

Authorso Sig Handelman [[email protected]]

o Sid Askary [[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/9/23 1 of 24

1

1

2

3

4

56789

1011

12131415

16171819202122

23

24

23

Table of ContentsINTRODUCTION...................................................................................................................3

1.1 ABSTRACT............................................................................................................31.2 SUPPORTING ORGANIZATIONS.............................................................................31.3 REFERENCED DOCUMENTS...................................................................................3

1.3.1 Specifications:..............................................................................................31.3.2 Schemas:......................................................................................................31.3.3 Payloads:.....................................................................................................4

1.4 MEETING LOGISTICS............................................................................................41.5 SUBMITTED PROPOSALS.......................................................................................41.6 ORGANIZATIONS AND ROLES...............................................................................5

2 SYSTEM OVERVIEW.............................................................................................5

2.1 ARCHITECTURE....................................................................................................52.2 FUNCTIONAL REQUIREMENTS..............................................................................6

2.2.1 Core Components........................................................................................62.2.2 Business Process..........................................................................................72.2.3 Trading Partner...........................................................................................72.2.4 Registry/Repository......................................................................................72.2.5 Messaging....................................................................................................72.2.6 Security........................................................................................................8

3 SCENARIOS..............................................................................................................8

3.1 GENERAL DEMONSTRATION FLOW......................................................................83.2 EBUSINESS: TRACK 1...........................................................................................9

3.2.0 Introduction.................................................................................................93.2.1.............................................................................................................................93.2.2 Choreography............................................................................................113.2.3 Step 1: Discovery.......................................................................................133.2.4 Step 2: Catalogue Update..........................................................................133.2.5 Step 3: Place Order...................................................................................153.2.6 Combined Sequence Diagram...................................................................16

3.3 HEALTHCARE: TRACK 2....................................................................................173.3.1 Introduction...............................................................................................17

4 APPENDIX A:.........................................................................................................21

3.1 TABLE OF FUNCTIONS........................................................................................214.1 TABLE OF DOCUMENT TYPES............................................................................21

5 APPENDIX B:..........................................................................................................23

5.1 AIAG.................................................................................................................235.2 HL7....................................................................................................................235.3 OAGI.................................................................................................................235.4 ROSETTANET......................................................................................................23


4

25

26

272829303132333435

36

3738394041424344

45

4647484950515253545556

57

5859

60

61626364

5

5.5 SWIFT...............................................................................................................245.6 X12....................................................................................................................24

Introduction

1.1 Abstract

This Document is a controlling agent for the Proof-Of-Concept (POC) Working Group’s interoperability demonstration during the ebXML conference in Vienna May 7 – 11, 2001.

It includes references to the business scenarios, documents and other material. To that end, material was provided by other ebXML Working Groups whose members also participate in the POC.

While the goal of the POC WG has been to demonstrate interoperability and to provide feedback to the other working groups, this particular document and the resulting demonstration mark the end of phase I in the ebXML delivery of specifications. As such, the specifications used in this document are the versions available as of April 16th, 2001.

1.2 Supporting Organizations

This Demonstration will highlight the ability of the ebXML set of standards to be used in many industries for many purposes. As such, we will showcase documents and business processes from the following organizations: AIAG, HL7, OAG, Rosettanet, SWIFT, X12 (APENDIX B).These are then demonstrated in the context of two general vertical scenarios: eBusiness and Healthcare.

1.3 Referenced Documents

1.3.1 Specifications:1. [ebXML-TRP] Messaging Service Specification v0.98b 2. [ebXML-R&R] Registry Services v0.90 3. [ebXML-R&R] Registry Information Model v0.904. [ebXML-BP] Business Process Specification Schema v0.995. [ebXML-CPP/A] Collaboration-Protocol Profile/Agreement v0.9416. [ebXML-CC] Core Components. ???7. [ebXML-A] Architecture Version 1.0

1.3.2 Schemas:


6656667

68

6970

717273

747576

7778798081

8283848586878889

90

9192939495969798

99100

7

1. XMLSignature Core –

http://ebxml.org/project_teams/transport/xmldsig-core-schema.xsd

2. Xlink - http://ebxml.org/project_teams/transport/xlink.xsd3. xml:lang -

http://ebxml.org/project_teams/transport/xml_lang.xsd4. SOAP1.1 - http://ebxml.org/project_teams/transport/envelope.xsd

Note that for the demo The location of the urls for the references will be modified to reflect a local directory setting.

1.3.3 Payloads:The POC WG will demonstrate multiple payload support. They are: (NEED DOCUMENT SAMPLES)

1. RosettaNet for Catalog Update2. OAG for Catalog Download3. OAG for Place Order4. X12 for Purchase Order and Purchase Order Ack5. AIAG XML (from Tokyo POC) for ASN6. Core Components for Payment Authorization, Invoice and

Invoice Response7. A “financial XML” for Financial Settlement from Payment

Authority to Bank8. Swift between Banks for Financial Settlements9. An XML Bill from the Bank to the Buyer

1.4 Meeting Logistics

The 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.

1.5 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


8101102103104105106107

108109110111

112113114

115116117118119120121122123124125

126127128129130131

132133134135

136

137138

139140

141

142143

9

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

1.6 Organizations and RolesA table will be created in this specification outlining the identification of participants in the choreographed sequences outlined in this document was well as the support roles for the poc. The roles of the companies include buyer, supplier, registry, market place, credit authorization and financial institution as 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.

2 System Overview

2.1 Architecture

The 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 Design, configuration and runtime.

During design time, the ebXML business processes, core components, and dictionaries are installed in the registry. This also includes maintenance activities. 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.

Real time business activities are conducted during runtime, as ebXML messaging is used to communicate. Systems configured under the collaborative protocol agreements exchange business documents according to pre-defined business processes.


10144145

146147

148149

150151152153154155156157158159160

161

162163164165166167168169170171172173174175176177178179180181182183

11

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.

2.2 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:

2.2.1 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.

A. 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.

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


12

184185

186

187188189190

191

192193

194195196197

198199

200

201

202203204205206207208209210211

13

2.2.2 Business Process

Storage of business process in Reg/Rep

Dynamic configuration of run-time infrastructure using CPA

Show link of business process in the CPA

Business Process Editor and other tools

Choreography of Business Process expressed in ebXML SchemaA. XML schema possibility to run Workflow B. 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.

2.2.3 Trading Partner Dynamic configuration of run-time infrastructure using CPA

Business processes for negotiation of CPA

ebXML Trading Partner 0.94+

2.2.4 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.

2.2.5 Messaging Multi-hop

Security

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

Multi-part payloads

ebXML Messaging Spec 98b+

2.2.6 Security XML DSIG for Authentication Purposes

Include security at the messaging level

Secure access to registry contents


14212213

214

215

216

217218219

220

221222223224225

226227

228

229

230231

232

233

234

235

236237

238239

240

241

242

243

244245

246

247

15

Security of payloads in messages optional between Trading

Partners

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

The functions used in the Proof of Concept are summarized in the Appendix of this document.

3 Scenarios

3.1 General Demonstration FlowThere will be a brief introduction followed by two business tracks. All the tracks utilize the same ebXML infrastructure and specifications, but the business scenarios and the payloads will vary. The demo will also try to highlight certain unique aspects, such as security and reliable messaging, in individual tracks.

1. Business Process - The 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.

2. Core Components (Business Documents) - A 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.

3. Collaborative Partner 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.

4. Transactions - There 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:

A. Assignment of domain names and IP addresses for closed demonstrations.


16248249

250251

252253

254

255256257258259260

261262263264265266267268269270

271272273274275

276277278279280281

282

283284285286

287288

17

B. Assignment of DUNS+4 numbers for demonstrations

with RosettaNet payloads.C. Screenshots for underlying software. Most ebXML

components are services. For a demonstrations, simple GUI interfaces need to be created to illustrate the functional aspects.

3.2 eBusiness: Track 1

3.2.1 IntroductionA 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. These are pictures that have been taken from the Business Process Work Group’s documents provided to the Proof of Concept WG. Two changes will be worked out between the groups. We will have a set of processes using a Catalogue on the eMarketPlace server. The use of Product lists and price lists in Catalogues is outlined later in this document. The Proof of Concept will also have additional messages between the e-Marketplace and the Payment Server. In addition the business messages between the e-Market Place and the Payment Server have been enhanced to include Credit Request, Invoice and Invoice Response.


18289290291292293294

295

296297298299300301

302303304305306307308309310311312313

314

19

Seller : SellerBuyer : Buyer

Payment Authority : Payment Authority Seller Bank : Seller

Bank

Registry : RegistryBuyer Bank : Buyer Bank

Net Market : Net Market

Catalog Upload

Catalog Download

Place Order

Payment Authorization

Purchase Order

ASN

Invoice

Invoice Response

Financial Settlement


Financial SettlementBill

BuyerBank:BOWSTREETSeller Bank:XML GLOBALSeller:

Catalog Upload: SAMSUNGPurchase Order, PO ACKNETFISHASN: TIBCOInvoice Processing:NTT COMM/NTT DATA

Catalog Download, Place Order, Purchase Order, Purchase Order Ack, COMMERCE ONE,Payment Authorization and ASN, GE

Catalog Download and Place Order: SAVVION/NTT COM/NTT DATA ASN: TIE

Payment Authorization and Invoice: IBM/VISA

PO Ack

ASN

CPP/CPA formation BEA and CONTIVO

Registry: STERLING COMMERCE

Insert my CP, Request Seller's CPP

Seller's CPPSend CPA


20

315

21

Figure 2. eBusiness Track

3.2.2 ChoreographyThe 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


22316

317

318319320321

322323

324

23

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

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


24

25

Runtime – Financial Institution

8.

Runtime – Reporting Institution

9.

3.2.3 Step 1: Discovery

Marketplace: Conversation

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

Documents: (NEED SAMPLE DOCUMENTS)

ebXML CPP and CPA for Discovery

3.2.4 Step 2: Catalogue Update

Marketplace: Conversation (Normal Messaging)


26

325

326

327

328329330

331332333

334

335

336

27

Buyer Exchange Seller

Acknowledgement

Send Product List

Acknowledgement

Send Price List

Business TransactionMessaging Level Ack

Documents: (NEED SAMPLE DOCUMENTS) RosettaNet for Catalog Update

OAG for Catalog Download

MarketPlace: Conversation (Reliable Messaging)

Buyer Exchange Seller

Acknowledgement

Send Product List

Acknowledgement

Send Price List

Business TransactionMessaging Level Ack

HubMSH MSH

Documents: (NEED SAMPLE DOCUMENTS) RosettaNet for Catalog Update


28

337338

339

340

341

342343

344

29

OAG for Catalog Download

3.2.5 Step 3: Place OrderPayment Authority: Conversation

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 (Fig. 3), 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.

: SecureBuyer Exchange : Exchange

: PaymentAuthority

: SecureSeller

BuyingMessage

CreditRequest

CreditAuthorization

ShipmentNotice

Invoice

Documents: (NEED SAMPLE DOCUMENTS)

X12 for:

1. Purchase Order


30345

346347

348349350351352353354355356

357358359

360

361

31

2. Purchase Order Ack

ebXML Core Components for:

1. Credit Request.

2. Credit Authorization (“Secure Electronic Transactions (SEC) Version 1.0”).

3. Shipment Notice.

4. Invoice. AIAG XML (from Tokyo POC) for ASN

Financial Institution: Conversation

NEED GRAPH

Documents: (NEED SAMPLE DOCUMENTS) A “financial XML” for Financial Settlement

from Payment Authority to Bank Swift between Banks for Financial Settlements An XML Bill from the Bank to the Buyer

3.2.6 Combined Sequence Diagram

The Sequence Diagram for all the components worked out on the Face-to-Face meeting on April 17, is presented in the following picture.


32362

363

364

365366

367

368369

370

371372

373374375376377378

379380

381382

33

Net Market : Net Market

Seller : Seller

Buyer : Buyer

Payment Authority : Payment Authority

Seller Bank : Seller BankBuyer Bank :

Buyer BankCatalog Upload

Catalog Download

Place Order

Payment Authorization

Purchase Order

Purchase Order AckASN

Invoice

Invoice Response



Financial SettlementBill

3.3 HealthCare: Track 2

3.3.1 Introduction

The Healthcare 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 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


34

383384

385

386387388389390

391392393394395396

397398399400

35

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

The transport and routing will be defined by ebXML while Security will meet ebXML specifications. HL7 vendors will partner with ebXML vendors to accomplish secure, remote transactions and 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.

Figure 5. Health Scenario


36401402403404405406407408409410411412413414415416417

418419

37

: PCP Hospital : Hospital : Laboratory : Clinical PortalHub : Hospital

Clinical Reports

: Patient

Callup Results

Forward Report

Forward Report

Examination

Forward Report

Register

Procedure

The Roles of the Health Scenario are explained in the Sequence Diagram found in Figure 6.


38

420421422423424

425

39

: PCP Hospital : Hospital : Laboratory : Clinical PortalHub : Hospital

Callup Results

Clinical Reports

Forward Report

Forward Report

SYBASEHub: VIQUITY

Lab Test Via Hub

Hospital: CYCLONE

Lab: NETFISH, NTT COMM/NTT DATA

Clinical Portal;CARE DATA, WEB METHODS

: PatientExamination

Forward Report

Register

Procedure


40

426

41

4 Appendix A:

3.1 Table of Functions

The Face-to-Face meeting April 17, 2001 worked out the following table, summarizing the use of the ebXML specifications during the Proof of Concept Demonstration.

TRP CPP/CPA BP CC RegistrySMTP – MAIL SERVER

Discover of CPP

BP Definition CC Document Creation

Content lifecycle

HTTP-SOAP-MSG

CPP into Registry

BP Schema Generation

Assembly Methodology

3 types of services

Some Reliable Message

CPA Assembly BP Storage in Registration

Registry Interaction

Retrieving objects

Security SMIME/PGP CA Server

Use of CPA for Runtime

Build CPP Based

CPA Negotiate Store CPA in Registry

CPA Service Extension

Binary Collaboration Drill Down

4.1 Table of Document Types

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 Dimitri


42

427

428429

430431432433434435

436

437438

43

proposal deadline Cherkassky,

Commerce One

OAG Glenn Thomsen, Killdara

EDI Shows legacy compatibility

Jeffrey Eck, GE


44

439440441

45

5 APPENDIX B:

5.1 AIAGThe Automotive Industry Action Group is a globally recognized organization founded in 1982 by a group of visionary managers from DaimlerChrysler, Ford Motor Company, and General Motors. The purpose: To provide an open forum where members cooperate in developing and promoting solutions that enhance the prosperity of the automotive industry. AIAG’s focus is to continuously improve business processes and practices involving trading partners throughout the supply chain.

5.2 HL7Health Level Seven is one of several ANSI-accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Health Level Seven’s domain is clinical and administrative data. Our mission is to: "To provide standards for the exchange, management and integration of data that support clinical patient care and the management, delivery and evaluation of healthcare services. Specifically, to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems."

5.3 OAGIThe Open Applications Group is a non-profit consortium focusing on best practices and process based XML content for eBusiness and Application Integration. It is the largest publisher of XML based content for business software interoperability in the world. Open Applications Group, Inc. members have over 5 years of extensive experience in building this industry consensus based framework for business software application interoperability and have developed a repeatable process for quickly developing high quality business content and XML representations of that content.

5.4 RosettanetA consortium of more than 400 of the world's leading Electronic Components (EC), Information Technology (IT) and Semiconductor Manufacturing (SM) companies, RosettaNet is a self-funded, non-profit organization dedicated to creating, implementing and promoting open e-business standards. These standards form a common e-business language, aligning processes between trading partners on a global basis.


46442

443444

445446447448449450451452453

454455456457458459460461462463

464465466467468469470471472473

474475476477478479480481

47

5.5 SWIFT

SWIFT is an industry owned co-operative supplying secure messaging services and interface software to over 7,000 financial institutions in 192 countries.We provide messaging services to banks, broker-dealers and investment managers, as well as to market infrastructures in payments, treasury, securities and trade. These services help our customers reduce costs, improve automation and manage risk.

5.6 X12

The Accredited Standards Committee (ASC) X12, comprised of cross-industry representation, delivers the most widely implemented electronic data interchange (EDI) standards that interact with a multitude of e-commerce technologies and serves as the premier source for integrating electronic applications. Through the X12 Committee's standards and active participation in emerging and technically relevant initiatives, ASC X12 links together multiple industries and sets the norm for a more effective exchange of information.


48482483484485486487488489

490

491492493494495496497498499

500501502503504505506507508509510511512513514515516517518519520521

522523524525

49

ebXML Proof-Of-Concept - ebXML - Enabling A Global ... · Web viewebXML London POC Proof-Of-Concept...

Documents

Transcript of ebXML Proof-Of-Concept - ebXML - Enabling A Global ... · Web viewebXML London POC Proof-Of-Concept...