Oagi Industry Initiatives

OAGI Industry Initiatives

- STAR/XML

- AMDX

- TRANxml

Open Applications Group, Inc.

OAGISCross -Industry

Schemas

Anthony [Tony] BlazejDirector of Industry Programs,

Open Applications Group, [email protected]

IndustrySchemas

Copyright © 2002 Open Applications Group, Inc. All rights reserved

Industry Consortium working to achieve dramatically easier business software integration for:

Open Applications Group

• Business to Business• Application to Application

– Legacy– Packaged

• Across the Enterprise • Down the Value Chain• From Factory Floor to Customer

Door


OAGIS

• OAGIS is a cross-industry XML document framework for exchange of data between enterprise business systems both within a company and across a value chain

• OAGIS is architected for extensibility into industry specific domains

• OAGIS is designed for implementation as the XML data interchange technology of COTS application offerings

OAGIS Architecture, Core Components & Data Dictionary

HRXML Finance ERP eMFG SCECRM TRANxml

Industry Extensions [automotive, aerospace, metals….]

Company extensions

------- OAGIS -------


OAGIS “Industry Value Chain” Approach

• Work with established industry organizations to gain commitment of major industry players

• Identify all business-to-business touch points between trading partners in the value chain

• Gain executive sponsorship of an industry B2B/XML initiative to build consensus for normalize business processes, related messages and “trading partner agreements”

• Develop XML-based specifications to support those processes using open standards and production ready technologies

• Work with key software vendors to get XML messages incorporated in their COTS offerings

• Drive adoption and implementation of XML standards within and between member companies


IndustryIndustryInitiativeInitiative

Collaborative Project

Auto BODsAuto BODsMessagingMessaging Frame- Frame- work workTPAsTPAs


Development Process

SpecificationOwners Review &Approve

Asset Ownersbuild messages,documentation& XML schemas

Domain Expertsdefine problem

and buildscenarios

STAR/XML Work Group• Integration scenarios • Business process normalization• Identify messages• Work flow• Infrastructure definition• User / Solution Provider consensus building

STAR/XML Work Group• Modeling• Message choreography• Data Dictionary• BOD development• XML schema & samples• Documentation• Validation

OAGIS Management Board• Architecture • Reuse review• Consistency• Methodology• Cross-domain coordinationSTAR Management Board• Industry applicability• Data dictionary consistency


Publish SpecificationsProjectProjectWork Work

Group(s)Group(s)

Draft SpecificationsDraft Specifications - Auto BODs- Auto BODs - Messaging framework- Messaging framework - TPAs- TPAs

ReviewApprove

Final Final OAGIS/STAROAGIS/STARSpecificationSpecification

Perspective:Perspective:- Architectural integrity- Architectural integrity- Core component reuse- Core component reuse- Technical accuracy- Technical accuracy- Horizontal leverage- Horizontal leverage

Perspective:Perspective:- Industry/Bus.Process fit- Industry/Bus.Process fit- Data dictionary integrity- Data dictionary integrity- Technical accuracy- Technical accuracy


Standards for Technology in Automotive Retail (STAR)

Focus: Secure, automated interchange of auto retail business data over a TCP/IP-based infrastructure using industry consensus protocols

DEALERSDMS OEM

SYSTEMS

Customer Data

Vehicle Data

Service Data

Parts Data

Other Data

Financial Data

Auto Retail Infrastructure: transport, trading partner & business process interaction protocols

Please come to ebXML Day Presentation

Thursday @ 3:20pm


Auto Manufacturing Data-eXchange (AMDX)

SUPPLIERSYSTEMS

OEM SYSTEMS

Inventory Levels

Forecasts

Shipping Information

Traceability Data

Other Data

Lead-times and Capacity Data

Auto Industry Infrastructure: transport, trading partner & business process interaction protocols

Focus: Secure, automated interchange of auto supply chain business data over a TCP/IP-based infrastructure using industry consensus protocols


What is the AMDX initiative?

• A proposal for AIAG, Odette and JAMA to jointly participate in a project with the Open Applications Group to create a defined set of automotive industry transactions expressed in XML schemas and business process models.– Most automotive industry OEMs, suppliers, solution providers, B2B

trade exchanges are eagerly waiting for someone to develop of a set of standardized XML documents so they can begin embracing this new technology and take advantage of the benefits it promises

– This initiative will complement the “retail facing” work already underway in the STAR/XML project

• The proposed new auto industry XML standards will leverage cross-industry XML documents developed by a recognized XML content standards organization backed by software industry


Major Players

AMDX ProjectXML SchemasXML SchemasBusiness ModelsBusiness ModelsMessage FrameworkMessage Framework

Deliverables focused on Automotive

Industry needs

Funding Sponsors

Solution Providers

• 12-15 members

• Provides $

• People resources

• Software companies

• Commited to implement

• Provide subject matter experts

Currently provides

horizontal schemas


Proposed Deliverables

AMDX project will deliver “enhanced” set of automotive XML documents based on X12/EDIFACT transactions as well as creating new standardized transactions for critical business processes not

being addressed today.• Material Release• Ship Notice• Ship Schedule• Application Advice• Receiving advice• Production Sequence• Inventory Report• Purchase Order• Request for Quote• Response to RFQ• PO Change• PO Acknowledgement• PO Change Acknowledgement• Invoice• Payment order/remittance• Text message• Critical response scenario• Inventory consumption• Engineering changes• Warranty• eAPQP

Legacy X12 and

EDIFACT transactions

NEW business

processes

Standardized set of: •content for transactions •business processes collaborations

•messaging framework.

“AMDX scope will be sized to produce deliverables within

project schedule and budget”


Partnership in Action

• Users are expected to invite their key vendor[s] to work with them on this project

• Sponsors will agree upon scope of work and schedule so they can interlock deployment initiatives with availability of deliverables

• Participation by spectrum of users [OEM, Tier 1-2] validates the solution to be broadly applicable

• OAGIS methodology ensures rapid progress, consensus building among users and solution providers, and deployable results

• Documented “messages” and process models support future growth

AMDX initiative establishes a forum promoting collaboration between “users” and their key “supply chain enablement” vendors


AMDX Project Overview

AMDX Board

AMDX Management Team

AMDX Project OfficeOAGI Technical Support Office

Material Management Work

Group

Procurement Work Group

Finance Work GroupebXML Messaging

Work Group

• Invoice• Payment order/remittance• Text message

• Purchase Order• Request for Quote• Response to RFQ• PO Change• PO Acknowledgement• PO Change Acknowledgement

• Material Release• Ship Notice• Ship Schedule• Application Advice• Receiving advice• Production Sequence• Inventory Report

• TRP• Security• Digital certificates

Odette Technology Committee

AIAG EC Steering Committee

Domain groups

• Critical response scenario• Inventory consumption• Engineering changes• Warranty• eAPQP

Legacy X12 and

EDIFACT

New processes


OAGIS based AMDX Solution will:

• Define process & data requirements to streamline automotive supply chain business interactions

• Enhance & advance current AIAG initiatives • Avoid “reinventing the wheel”

– Save time– Streamline/focus partner XML development efforts

• Use of OAGIS provides– Re-used of proven methodology– Vocabulary to support B2B messaging– Infrastructure based on existing/emerging

implementation frameworks (RN, ebXML, BizTalk)– Experienced OAGIS solution providers


TRANxml Schema for Logistics

CARRIER SYSTEMS

Forecasts

Tenders/Bills of Lading

Shipping Information

Tracing/Tracking/ETA

Metrics/Reports

Freight Billing

Focus: Secure, system-to-system interchange of logistics business data over a TCP/IP-based infrastructure using industry consensus protocols

SHIPPERSYSTEMS[OEMs &

Suppliers]

Messaging Infrastructure: transport, trading partner & business process interaction protocols


Logistics Process

Core business function of all enterprises consuming raw materials or distributing products

• The logistics process depends on data generated within the enterprise, by suppliers and distributors, and by carriers at different points along the transportation route

• There are core transactions, documents and data items that can be standardized across industries and transport modes, plus…

• Industry practices and mode specific data requirements drive a need for domain specific extensions


What is the TRANxml initiative?

• A work effort extending the Open Applications Group’s Business Object Document library into the “logistics” domain

• A set of transportation focused transactions and B2B process collaborations, expressed in XML schemas, serving as the horizontal [cross industry] platform for logistics data exchange– The schemas become core components for messages needed by the

various transportation modes

– The schemas are the “data source” for higher level B2B processes such as Supply Chain Execution and Materials Management

• TRANxml BODs become the platform for industry specific extensions supporting the needs of shippers in auto, aerospace, metals, chemicals, electronics...


Interested Parties

TRANxml ProjectXML SchemasXML SchemasBusiness ModelsBusiness ModelsMessagingMessaging Framework Framework

“Logistics Domain” focused

deliverables

Funding Sponsors

Solution Providers

• 15-20 members

• Provide $$$

• People resources

• Software companies

• Committed to implement

• Provide subject matter experts

develops cross-industry

[horizontal] schemas

Industry AssociationsStandards Bodies

Carriers & ShippersLogistics providers

Application SW vendors


Proposed Deliverables

TRANxml project will deliver “enhanced” set of logistics XML documents based on X12/EDIFACT transactions as well as creating new standard messages for critical business processes not being addressed today.

• Rail Bill Of Lading• Car Location Message• Motor Carrier Bill Of Lading• Motor Carrier Load Tender• Shipment Status Message• Shipment Weights• Simple Rail Bill Of Lading• Terminal Operations and Intermodal Ramp• Simple Rail Carrier Waybill Interchange• Advance Car Disposition• Car Handling Information• Shippers Car Order• Rail Industrial Switch List• Ship Notice Manifest• Warehouse Stock Transfer Shipment Adv• Warehouse Shipping Advice• Warehouse Inventory Adjustment• Confirmation Ocean• Rail Carrier Freight Details and Invoice• Shipment Information• TranXML Acknowledgment• Vessel Schedule and Itinerary Ocean

• Inventory Consumption• Product Update• Multi-modal Bill of Lading

LegacyX12/EDIFACT transactions

NEW business

processes

Standardized set of: •content for transactions •business processes collaborations

•messaging framework.

“TRANxml scope will be sized to produce deliverables within

project schedule and budget”


OAGI EECF Architecture

Extended Enterprise Collaborative Framework• Message architecture - OAGIS ver. 8 [XSD]• Message Transport Method

– ebXML Messaging Services 2.0

• Message Security Method– Digital Signature

• Transport Security Method– Secure Socket Layer (SSL)– Digital Certificate

• BPSS schema express collaborations• CPP/A define OEM & supplier system configurations


Business Object Documents (BODs)

• BODs are the XML messages that business partners exchange between each other

• Examples:– “Process Purchase Order”– “Acknowledge Repair Order”– “Submit Credit Application”– “Return Credit Decision”

• BODs have a formal architecture, re-use the OAGIS data dictionary and are expressed in XSD


Success

Success

Dealer OEM

Parts OrderFailure

Parts OrderSuccess

XOR

AnyFailure

AnyFailure

AnyFailure Success

Success

Modify PO DealerCancel POChange PO

End Collaboration

Modify PO OEMCancel POChange PO

Process PO

AnyFailure

<BusinessTransactionActivity name="Process PO" nameID="F28FF3663B5E042F" businessTransactionname="Process PO" businessTransactionIDRef="F28FF36 B5E" fromAuthorizedRole="Dealer" fromAuthorizedRoleIDRef="F28FF33A3 B5E0" toAuthorizedRole="OEM" toAuthorizedRoleIDRef="F28FF33F3B5E0 405" isConcurrent = "true" isLegallyBinding = "false" timeToPerform="30s"/>

Deliverable #1: Collaboration (BPSS)

Initiator Responder

? Change PO

= Accept PO

x Reject PO

= Back Order

Transaction view: Change Parts Order

Parts Order Collaboration

BPSS


Deliverable #2: BOD - XML and Schema

<?xml version="1.0"?><!DOCTYPE ProcessPurchaseOrder007 SYSTEM

"StarProcessPO007.dtd"><ProcessPurchaseOrder007> <ControlArea>

<BusinessServiceRequest><Verb>Process</Verb><Noun>PO</Noun><Revision>007</Revision>

</BusinessServiceRequest> <Sender>

<LogicalIdentifier>CPAG</LogicalIdentifier>

<Component>PURCHASING</Component><Task>POISSUE</Task><ReferenceIdentifier>CPAGPOBERLIN02</

ReferenceIdentifier><Confirmation>0</Confirmation><Language>ENG</Language><CodePage>CP000111</CodePage><AuthorizationIdentifier>RSCHULTE</

AuthorizationIdentifier><UnitIdentifier>124</UnitIdentifier><GeographyIdentifier>014</

GeographyIdentifier <DestinationNameCode>HO</DestinationNameCode> <DestinationComponent>DCS</DestinationComponent

</Sender>

<xsd:schema targetNamespace="http://www.ebxml.org/BusinessProcess" xmlns="http://www.ebxml.org/BusinessProcess" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" elementFormDefault="qualified">

<xsd:element name="Attachment">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="name" type="xsd:string" use="required"/>

<xsd:attribute name="nameID" type="xsd:ID"/>

<xsd:attribute name="businessDocument" type="xsd:string"/>

<xsd:attribute name="businessDocumentIDRef" type="xsd:IDREF"/>

<xsd:attribute name="specification" type="xsd:uriReference"/>

<xsd:attribute name="mimeType" type="xsd:string" use="required"/>

<xsd:attribute name="version" type="xsd:string"/>

<xsd:attribute name="isAuthenticated" type="xsd:boolean" value="false"/>

<xsd:attribute name="isConfidential" type="xsd:boolean"

XML Schema - validates the Parts Order

XML - the actual Parts Order


Deliverable #3: Implementation Guide

ProcessPurchaseOrder007 occurs once for the entire file. ControlArea segment occurs once for the entire file. BusinessServiceRequest segment occurs once for the entire file. Sender segment occurs once for the entire file. DateTime(Creation) segment with Creation qualifier occurs once for the entire file. DataArea segment with sub-elements may occur multiple times. ProcessPurchaseOrder segment occurs once. PurchaseOrderHeader segment occurs once.

DateTime(Document) segment optionally occurs once.Partner(ShipTo) segment occurs once.ShipTo AddressPartner(BillTo) segment occurs once.BillTo AddressPartner(Supplier) segment occurs once.Partner(Carrier) segment optionally occurs once.Partner(AlternateCarrier) segment optionally occurs once.Partner(AlternateShipTo) segment optionally occurs once.AlternateShipTo AddressCharge segment optionally occurs once.PurchaseOrderTerms segment optionally occurs once.OperationAmount segment occurs once.

PurchaseOrderLine segment occurs once.Quantity(Ordered) segment occurs once.Quantity(Length) segment optionally occurs once.Quantity(Width) segment optionally occurs once.SerialNumber(VIN) optionally occurs once.SerialNumber(KeyCode) optionally occurs once.Partner(LineCarrier) segment optionally occurs once.

Relationship Diagram - Hierarchy of data elements

Data element definitions - Indicates required or optional, data dictionary reference


OAGI B2B Interoperability TestBed at NIST

The B2B TestBed is a funded, collaborative initiative designed to facilitate on-demand testing and demonstration of enterprise application interoperability in a B2B setting, for use by:

– software vendors– user project teams– standards organizations– and other stake holding parties


OAGI and the “B2B Challenge”

Challenge - 1Show that application suites from different vendors can “talk to” one another when OAG BODs package the “content”

Challenge - 2Show how process control, workflow, security and other aspects of robust B2B capabilities can be easily added-on by “integration vendors”


B2B TestBed Focus

• Business Aspects of interoperability– the ability of business partners to move information

between applications that make up their company’s IT backbones (e.g. ERP, Scheduling, CRM)

• Business Aspects include – business information being exchanged [BODs], and

– the processes of conducting the interaction and information exchange [collaboration], using

– industrial strength, open B2B messaging infrastructure [ebXML]


NIST MONITORING SYSTEM

Process_PO


monitoring

ParticipantA

Center-components

Proxy-Component(e.g. “Vitiris”?)

Notification /API Call

TestBed

Node• Routing• Reflection

?

?

ParticipantB

ParticipantC

ParticipantE

ParticipantD

ebXML Infrastructure

ebXML Messages

non-ebXML Messages


B2B TestBed Value

• User and vendor testing capability enhances development and deployment of new technologies

• Market-driven, Real-world Demos & Proof-of-Concept– OAG Vendor Challenge showed people that OAGIS-based solutions

existed and worked as advertised [Nov 2000]

– Need to bring this message to local level by demonstrating realistic interoperability solutions through many, customer focused demos, and presentations

– Infrastructure, demo code re-use

• Minimize errors and “throw-away” code

• Availability and low cost makes maximum exposure of “interoperability” possible

• Quick feedback to standards bodies


Main Benefits Expected from OAGIS/ebXML

• More information (orders, inventory status...) in a timely fashion [transaction based vs. batch]

• A common infrastructure lowers the cost of doing business– For OEM, SW vendors and Suppliers – Provide room for extensions at marginal cost– Enable new services (financial, insurance, …)

• A well defined interface (document formats and processes) against which internal processes can be engineered and optimized– The differentiation between OEMs will come from a better

use of the new information, more efficient processes and innovative services which leverage the platform


Who Benefits?

• OEMs– Save time and $$$ in redundant interface development &

expensive legacy support of proprietary interfaces

• Application Software Vendors– Build one interface per business area (vs. one per OEM)

• Suppliers– More timely, reliable, accurate information– Single application interface to service multiple OEMs – New interfaces delivered via SW Vendor products

• Automotive Supply Chain– Re-use of OAGIS standards (a part order is a part order...)– Compatibility with other industries [aerospace, metals..]


How?

• Standardization– Build it once; build it right; use standard technologies;

re-use components

• Lower Barriers to Entry for SolutionProviders – Increased competition; improved application quality;

lower prices; gives suppliers a choice

• Design an open, scalable, modular infrastructure• Make it available to everyone• Specifications become the intellectual capital of

all industry association members


Call to Action...

• Companies with auto industry and logistics know-how and solutions that want to get involved should contact Tony Blazej

• We invite “middle ware” providers with ebXML focus to work on the infrastructure portion of these projects and participate in our B2B TestBed

• Both initiatives will be ebXML framework projects– Suggestions for improving, expanding, leveraging these

projects are welcome

http://www.openapplications.org

[email protected]

Oagi Industry Initiatives

Technology

Transcript of Oagi Industry Initiatives