Oagi Industry Initiatives

  • 421 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
421
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. OAGI Industry Initiatives - STAR/XML - AMDX - TRANxml Open Applications Group, Inc. OAGIS Cross -Industry Schemas Anthony [Tony] Blazej Director of Industry Programs, Open Applications Group, Inc. [email_address] Industry Schemas
  • 2. Open Applications Group Industry Consortium working to achieve dramatically easier business software integration for:
    • Business to Business
    • Application to Application
      • Legacy
      • Packaged
    • Across the Enterprise
    • Down the Value Chain
    • From Factory Floor to Customer Door
  • 3. 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 SCE CRM TRANxml Industry Extensions [automotive, aerospace, metals….] Company extensions ------- OAGIS -------
  • 4. 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
  • 5. Collaborative Project Industry Initiative Auto BODs Messaging Frame- work TPAs
  • 6. Development Process Specification Owners Review & Approve Asset Owners build messages, documentation & XML schemas Domain Experts define problem and build scenarios
    • 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 coordination
    • STAR Management Board
    • Industry applicability
    • Data dictionary consistency
  • 7. Publish Specifications Project Work Group(s) Draft Specifications - Auto BODs - Messaging framework - TPAs Review Approve Final OAGIS/STAR Specification Perspective: - Architectural integrity - Core component reuse - Technical accuracy - Horizontal leverage Perspective: - Industry/Bus.Process fit - Data dictionary integrity - Technical accuracy
  • 8. 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
    Please come to ebXML Day Presentation Thursday @ 3:20pm DEALERS DMS OEM SYSTEMS Customer Data Vehicle Data Service Data Parts Data Other Data Financial Data Auto Retail Infrastructure: transport, trading partner & business process interaction protocols
  • 9. Auto Manufacturing Data-eXchange (AMDX) SUPPLIER SYSTEMS OEM SYSTEMS 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 Inventory Levels Forecasts Shipping Information Traceability Data Other Data Lead - times and Capacity Data
  • 10. 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
  • 11. Major Players AMDX Project Funding Sponsors Solution Providers
    • 12-15 members
    • Provides $
    • People resources
    • Software companies
    • Commited to implement
    • Provide subject matter experts
    XML Schemas Business Models Message Framework Deliverables focused on Automotive Industry needs Currently provides horizontal schemas
  • 12. 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”
  • 13. 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
  • 14. AMDX Project Overview AMDX Board AMDX Management Team AMDX Project Office OAGI Technical Support Office Material Management Work Group Procurement Work Group Finance Work Group ebXML 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
  • 15. 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
  • 16. TRANxml Schema for Logistics CARRIER SYSTEMS Tenders/Bills of Lading Focus: Secure, system-to-system interchange of logistics business data over a TCP/IP-based infrastructure using industry consensus protocols SHIPPER SYSTEMS [OEMs & Suppliers] Messaging Infrastructure: transport, trading partner & business process interaction protocols Forecasts Shipping Information Tracing/Tracking/ETA Metrics/Reports Freight Billing
  • 17. 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
  • 18. 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...
  • 19. Interested Parties TRANxml Project XML Schemas Business Models Messaging 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 Associations Standards Bodies Carriers & Shippers Logistics providers Application SW vendors
  • 20. 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
    Legacy X12/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”
  • 21. 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
  • 22. 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
  • 23. Deliverable #1: Collaboration (BPSS) <BusinessTransactionActivity name=&quot;Process PO&quot; nameID=&quot;F28FF3663B5E042F&quot; businessTransactionname=&quot;Process PO&quot; businessTransactionIDRef=&quot;F28FF36 B5E&quot; fromAuthorizedRole=&quot;Dealer&quot; fromAuthorizedRoleIDRef=&quot;F28FF33A3 B5E0&quot; toAuthorizedRole=&quot;OEM&quot; toAuthorizedRoleIDRef=&quot;F28FF33F3B5E0 405&quot; isConcurrent = &quot;true&quot; isLegallyBinding = &quot;false&quot; timeToPerform=&quot;30s&quot; /> Transaction view: Change Parts Order Parts Order Collaboration BPSS
  • 24. Deliverable #2: BOD - XML and Schema
    • <?xml version=&quot;1.0&quot;?>
    • <!DOCTYPE ProcessPurchaseOrder007 SYSTEM &quot;StarProcessPO007.dtd&quot;>
    • <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=&quot;http://www.ebxml.org/BusinessProcess&quot; xmlns=&quot;http://www.ebxml.org/BusinessProcess&quot; xmlns:xsd=&quot;http://www.w3.org/2000/10/XMLSchema&quot; elementFormDefault=&quot;qualified&quot;> <xsd:element name=&quot;Attachment&quot;> <xsd:complexType> <xsd:sequence> <xsd:element ref=&quot;Documentation&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/> </xsd:sequence> <xsd:attribute name=&quot;name&quot; type=&quot;xsd:string&quot; use=&quot;required&quot;/> <xsd:attribute name=&quot;nameID&quot; type=&quot;xsd:ID&quot;/> <xsd:attribute name=&quot;businessDocument&quot; type=&quot;xsd:string&quot;/> <xsd:attribute name=&quot;businessDocumentIDRef&quot; type=&quot;xsd:IDREF&quot;/> <xsd:attribute name=&quot;specification&quot; type=&quot;xsd:uriReference&quot;/> <xsd:attribute name=&quot;mimeType&quot; type=&quot;xsd:string&quot; use=&quot;required&quot;/> <xsd:attribute name=&quot;version&quot; type=&quot;xsd:string&quot;/> <xsd:attribute name=&quot;isAuthenticated&quot; type=&quot;xsd:boolean&quot; value=&quot;false&quot;/> <xsd:attribute name=&quot;isConfidential&quot; type=&quot;xsd:boolean&quot; XML Schema - validates the Parts Order XML - the actual Parts Order
  • 25. 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 Address
      • Partner(BillTo) segment occurs once.
      • BillTo Address
      • Partner(Supplier) segment occurs once.
      • Partner(Carrier) segment optionally occurs once.
      • Partner(AlternateCarrier) segment optionally occurs once.
      • Partner(AlternateShipTo) segment optionally occurs once.
      • AlternateShipTo Address
      • Charge 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
  • 26. 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
  • 27. OAGI and the “B2B Challenge” Challenge - 1 Show that application suites from different vendors can “talk to” one another when OAG BODs package the “content ” Challenge - 2 Show how process control, workflow, security and other aspects of robust B2B capabilities can be easily added-on by “integration vendors”
  • 28. 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 ]
  • 29. NIST MONITORING SYSTEM Process_PO
  • 30. monitoring Participant A Center-components Proxy- Component (e.g. “Vitiris”?) Notification / API Call TestBed Node
    • Routing
    • Reflection
    ? ? Participant B Participant C Participant E Participant D ebXML Infrastructure ebXML Messages non-ebXML Messages
  • 31. 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
  • 32. 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
  • 33. 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..]
  • 34. How?
    • Standardization
      • Build it once; build it right; use standard technologies; re-use components
    • Lower Barriers to Entry for Solution Providers
      • 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
  • 35. 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_address]