1 / 10

Discussion: Usage of Sender/Receiver in BODs in the AIAG IVI Protocol

Discussion: Usage of Sender/Receiver in BODs in the AIAG IVI Protocol. By: Chad Stone QAD, Inc. 4/1/04. AIAG IVI Protocol: Usage of Sender/Receiver in BOD.

alden-pearson
Download Presentation

Discussion: Usage of Sender/Receiver in BODs in the AIAG IVI Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Discussion: Usage of Sender/Receiver in BODs in the AIAG IVI Protocol By: Chad Stone QAD, Inc. 4/1/04

  2. AIAG IVI Protocol: Usage of Sender/Receiver in BOD There is currently some debate in the IVI POC team regarding the proper usage of the <Sender> and <Receiver> elements in the BOD <ApplicationArea>. In particular, how should these values be chosen relative to any “To” and “From” values in the transport layer, and the <CustomerPartyID> and <SupplierPartyID> elements appearing in the <SyncQuantityOnHand> BOD? This presentation lists several possible solutions, and outlines the application of one solution in a number of use cases. The POC and BOD teams need to reach an agreement on a consistent usage. This presentation is intended to initiate and focus the discussion.

  3. Sender/Receiver in BOD: Possible Approaches • The Sender/Receiver are always the customer/supplier, even if there are multiple hops and even if an IV app (non-ERP) is the source/destination of the message. • - Note: this approach requires sender/reply-to information in the transport layer, since the customer/supplier may not have an IVI compliant system. • 2) The Sender/Receiver are always the physical IV nodes sending and receiving the message. In a multi-hop scenario, the values change for each hop. This physical node information is probably best represented in the transport layer, rather than in the Sender/Receiver fields of the BOD. • 3a) The “Receiver” should represent the ultimate destination of the message. • Note: the definition of “ultimate destination” gets fuzzy when considering IV apps such as QAD’s: is it the IV app or the customer/supplier that might use the IV app? • 3b) The “Sender” should represent the party that creates the BOD and whom should receive any Confirm BODs • This gets fuzzy when an IV app creates the BOD. Should the IV app be the sender, or should the customer/supplier that the data pertains to be the sender? • Note: Using sender for the confirm routing would be inconsistent with an approach where sender always is the customer/supplier, since they cannot be confirmed to in all cases (eg if they are not IVI compliant)

  4. Use Case Diagrams Illustrating one Interpretation of Approach (3) The diagrams will examine the following use cases, which are a representative but incomplete selection of all possible cases that the IVI protocol should support: 1) Customer ERP sends IVI BOD to Supplier ERP 2) Customer ERP sends IVI BOD to middleware IVI node, which forwards a transformed IVI BOD to Supplier ERP 3) Customer ERP sends IVI BOD to middleware IVI node, which transforms it into an EDI doc and sends to Supplier ERP 4) Customer ERP sends IVI BOD to IV Application 5) IV Application sends IVI BOD to Supplier ERP 6) IV Application A federates data with IV Application B

  5. Scenario 1: Customer ERP sends IVI BOD to Supplier ERP Customer ERP IVI BOD Supplier ERP 1. Confirm BOD 2. • 1. IVI BOD sent from Customer ERP to Supplier ERP: • -Transport : From=Customer ERP, To=Supplier ERP • -BOD AppArea: Sender=Customer ERP, Receiver=Supplier ERP • -BOD DataArea: Customer=Customer DUNS, Supplier=Supplier DUNS • 2. Confirm BOD sent from Supplier ERP to Customer ERP: • -Transport : From=Supplier ERP, To=Customer ERP • -BOD AppArea: Sender=Supplier ERP, Receiver=Customer ERP • -BOD DataArea: Orig.App.Sender=Customer ERP, Orig.App.Receiver=Supplier ERP

  6. Scenario 2: Customer ERP sends IVI BOD to middleware IVI node, which forwards a transformed IVI BOD to Supplier ERP Middleware Transformer IVI Node Customer ERP IVI BOD IVI BOD Supplier ERP 1. 2. Confirm BOD 3. • 1. IVI BOD sent from Customer ERP to Middleware IVI node: • -Transport : From=Customer ERP, To=Middleware Node • -BOD AppArea: Sender=Customer ERP, Receiver=Supplier ERP • -BOD DataArea: Customer=Customer DUNS, Supplier=Supplier DUNS Note: a cascading confirm option is also permissible, though not depicted. • 2. IVI BOD sent from Middleware IVI node to Supplier ERP: • -Transport : From=Middleware Node, To=Supplier ERP • -BOD AppArea: Sender=Customer ERP, Receiver=Supplier ERP • -BOD DataArea: Customer=Customer DUNS, Supplier=Supplier DUNS • 3. Confirm BOD sent from Supplier ERP to Customer ERP: • -Transport : From=Supplier ERP, To=Customer ERP • -BOD AppArea: Sender=Supplier ERP, Receiver=Customer ERP • -BOD DataArea: Orig.App.Sender=Customer ERP, Orig.App.Receiver=Supplier ERP

  7. Scenario 3: Customer ERP sends IVI BOD to middleware IVI node, which transforms it into an EDI doc and sends to Supplier ERP Customer ERP IVI BOD EDI Message Supplier ERP 1. 2. Middleware Transformer IVI Node Confirm BOD EDI App. Advice 4. 3. • 1. IVI BOD sent from Customer ERP to Middleware IVI node: • -Transport : From=Customer ERP, To=Middleware Node • -BOD AppArea: Sender=Customer ERP, Receiver=Supplier ERP • -BOD DataArea: Customer=Customer DUNS, Supplier=Supplier DUNS • 2. EDI message sent from Middleware IVI node to Supplier ERP: • -Transport : From=Middleware Node, To=Supplier ERP • -EDI message : Customer=Customer DUNS, Supplier=Supplier DUNS • 3. EDI Application Advice message sent from Supplier ERP to Middleware IVI node: • -Transport : From=Supplier ERP, To=Middleware Node • -EDI message : Customer=Customer DUNS, Supplier=Supplier DUNS • 4. Confirm BOD sent from Middleware IVI node to Customer ERP: • -Transport : From=Middleware Node, To=Customer ERP • -BOD AppArea: Sender=Supplier ERP, Receiver=Customer ERP • -BOD DataArea: Orig.App.Sender=Customer ERP, Orig.App.Receiver=Supplier ERP

  8. Scenario 4: Customer ERP sends IVI BOD to IV Application Customer ERP IVI BOD IV Application 1. Suppliers / Customers interacting with data in various fashions (e.g. viewing on web browser, spreadsheets, mobile devices, ERP connections) Confirm BOD 2. • 1. IVI BOD sent from Customer ERP to IV Application: • -Transport : From=Customer ERP, To=IV Application • -BOD AppArea: Sender=Customer ERP, Receiver=IV Application • -BOD DataArea: Customer=Customer DUNS, Supplier=Supplier DUNS • 2. Confirm BOD sent from IV Application to Customer ERP: • -Transport : From=IV Application, To=Customer ERP • -BOD AppArea: Sender=IV Application, Receiver=Customer ERP • -BOD DataArea: Orig.App.Sender=Customer ERP, Orig.App.Receiver=IV Application

  9. Scenario 5: IV Application sends IVI BOD to Supplier ERP IVI BOD Supplier ERP IV Application 1. Suppliers / Customers interacting with data in various fashions (e.g. viewing on web browser, spreadsheets, mobile devices, ERP connections) Confirm BOD 2. • 1. IVI BOD sent from IV Application to Supplier ERP: • -Transport : From=IV Application, To=Supplier ERP • -BOD AppArea: Sender=IV Application, Receiver=Supplier ERP • -BOD DataArea: Customer=Customer DUNS, Supplier=Supplier DUNS • 2. Confirm BOD sent from Supplier ERP to IV Application: • -Transport : From=Supplier ERP, To=IV Application • -BOD AppArea: Sender=Supplier ERP, Receiver=IV Application • -BOD DataArea: Orig.App.Sender=IV Application, Orig.App.Receiver=Supplier ERP

  10. Scenario 6: IV Application A federates data with IV Application B IV Application A Customer ERP Suppliers / Customers interacting with data in various fashions (e.g. viewing on web browser, spreadsheets, mobile devices, ERP connections) Various data sent periodically by various protocols 1. 2. IVI BOD Confirm BOD IV Application B Suppliers / Customers interacting with data in various fashions (e.g. viewing on web browser, spreadsheets, mobile devices, ERP connections) • 1. IVI BOD sent from IV Application A to IV Application B: • -Transport : From=IV Application A, To=IV Application B • -BOD AppArea: Sender=IV Application A, Receiver=IV Application B • -BOD DataArea: Customer=Customer DUNS, Supplier=Supplier DUNS • 2. Confirm BOD sent from IV Application to Customer ERP: • -Transport : From=IV Application B, To=IV Application A • -BOD AppArea: Sender=IV Application B, Receiver=IV Application A • -BOD DataArea: Orig.App.Sender=IV Application A, Orig.App.Receiver=IV Application B

More Related