Standards for Technology in Automotive Retail
| Standards for Technology in Automotive Retail | |
Table of Contents
This section describes the implementation of the CPA for STAR trading partners. This section is not intended to be a complete description of the CPA and its usage. For a detailed description of the CPA, please refer to the specifications document referenced in the preface of this document.
The STAR CPA has been designed for maximum flexibility. The Collaboration Roles have been designed to allow each party to define its own transport, security, and reliable messaging characteristics for each transaction type.. Channel, Document Exchange, and Transport definitions have also been pre-defined for every combination of transport type and message delivery option. The CPA parties need only to refer to the appropriate channel ID and DocExchange ID combination in the DeliveryChannel definition for each collaboration.
There are a number of benefits to having such a flexible design.
BODs or other transactions can be added or removed individually, allowing the CPA to reflect only those transactions that are actually supported by both parties
Those transactions that require more security or reliable messaging properties can have those properties defined without impacting the other transactions within the CPA
Transport definitions can be created for each transaction type. This will allow each BOD to be routed to a different URL, if necessary. This may be needed in large dealer franchises where the Service, Parts, and Accounting applications are running on separate physical machines or on separate application instances.
Figure 2.1, “STAR CPA Structure” below is a high-level depiction of the STAR CPA. It displays the primary CPA elements. Each primary element may have one or more child elements. The STAR implementation of these elements will be described below. A complete sample CPA can be found in Appendix A: Example CPA.
The PartyInfo element is the heart of the CPA. It defines the identification and security information for each party, the collaborations (BODs) supported by each party and all of the transaction characteristics for each collaboration. STAR has defined implementation guidelines for several of the child elements within the PartyInfo section.
The naming conventions for the PartyId element are still under development by STAR.
The CollaborationRole elements are the heart of the CPA. They are used to define the trading characteristics for each transaction. In the sample CPA shown in Appendix A, each Collaboration Role element is associated with a STAR BOD using the ProcessSpecification element. The structure of the CollaborationRole element is shown in Figure 2.2, “Collaboration Role Structure”.
The ProcessSpecification element defines the BOD type. The value of the name attribute should match the name attribute in the BPSS document for that BOD.
<tns:ProcessSpecification tns:name="PartsOrder" tns:uuid="urn:icann:star.org:bpid:3A4$2.0" tns:version="2.0" xlink:href="http://www.vwoa.com/po_processing/" xlink:type="simple"/>
The role names are defined using the Role element. Again, the Role names should match those in the BPSS document for the BOD. Currently STAR has defined the role names “Initiator” and “Responder” for all BOD types.
<<tns:Role tns:name="Initiator" xlink:href="http://www.starstandard.org/processes/3A4.xml#Initiator" xlink:type="simple"/>
The CPA was designed with two CollaborationRole elements per BOD to allow different messaging and transport parameters to be defined depending on whether the party is acting as the Initiator or the Responder for a transaction.
The ServiceBinding element defines the Service and Action elements that appear in the ebMS message header
The Service Element is defined using the BOD Noun value. For example, the ServiceElement for a PartsOrder collaboration role would be “PartsOrder”.
<tns:ServiceBinding>
<tns:Service tns:type="string">PartsOrder</tns:Service>
The CanSend and CanReceive elements define the ebXML actions associated with each collaboration. The ebXML action element corresponds to the STAR BOD verb that will be supported by each party. The ThisPartyActionBinding element within the CanSend or CanReceive element is used to indicate the supported action. The OtherPartyActionBinding element is a reference to the ID of the other party’s corresponding CanReceive element.
For example, if Party A is an OEM acting as the “Responder” and we are defining the collaboration for the PartsOrder BOD, the OEM would be capable of sending an “Acknowledge” verb and receiving a “Process” verb. The CanSend element would contain “Acknowledge” in the ThisPartyActionBinding element and the ID of Party 2’s corresponding CanReceive element in the OtherPartyActionBinding element. The CanReceive element would contain “Process” in the ThisPartyActionBinding element and the ID of Party 2’s corresponding CanSend element.
CanSend element for Responder collaboration role
<tns:CanSend>
<tns:ThisPartyActionBinding tns:action="Acknowledge" tns:id="SendPOAck" tns:packageId="DefaultComposite">
<tns:OtherPartyActionBinding>Party2_ReceiveAckPO</tns:OtherPartyActionBinding>
CanReceive element for Responder collaboration role
<tns:CanReceive>
<tns:ThisPartyActionBinding tns:action="Process" tns:id="ReceivePO" tns:packageId="DefaultPackage">
<tns:OtherPartyActionBinding>Dealer_SendPO</tns:OtherPartyActionBinding>
The attributes contained in the BusinessTransactionCharacteristics element will be negotiated and defined by each party according to their individual requirements.
The ChannelId element contains the identifier for the delivery channel that will be used to send or receive the BOD defined for a particular collaboration. The STAR CPA contains 14 delivery channel definitions. Each definition defines a different set of transport and message delivery parameters. Each party will determine the appropriate delivery channel types for each of the BODs that they support and assign the required delivery channel using the ChannelId element.
The certificate section of the STAR CPA is defined using the standard constructs as defined in the ebCPPA 2.0 specifications document.
As stated above, the STAR CPA contains 14 pre-defined channel types that can be used to define the delivery parameters for any collaboration activity by inserting the appropriate ID into the ChannelID element.
The STAR CPA contains 3 pre-defined DocExchange elements, each of which defines a different set of encryption and non-repudiation settings. A DocExchange ID is associated with Delivery Channel type definition.
