| Standards for Technology in Automotive Retail |
| Home - News Feed

Chapter 2. Implementing the CPA
Prev |  | Next

## Chapter 2. Implementing the CPA

## 2.1. Implementing the CPA

### 2.1.1. Overview

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.

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

2. Those transactions that require more security or reliable messaging properties can have those properties defined without impacting the other transactions within the CPA

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

### 2.1.2. STAR CPA Structure

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.

Figure 2.1. STAR CPA Structure

### 2.1.3. PartyInfo Section

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.

#### 2.1.3.1. CPA ID

See section 1.6.2 for the naming conventions for the CPA ID element.

#### 2.1.3.2. Party ID

The naming conventions for the PartyId element are still under development by STAR.

#### 2.1.3.3. Collaboration Roles

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

Figure 2.2. Collaboration Role Structure

#### 2.1.3.4. Process Specification

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"/>

#### 2.1.3.5. Role

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.

#### 2.1.3.6. Service Binding

The ServiceBinding element defines the Service and Action elements that appear in the ebMS message header

#### 2.1.3.7. Service Element

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>

#### 2.1.3.8. CanSend and CanReceive Elements

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>

#### 2.1.3.9. Business Transaction Characteristics

The attributes contained in the BusinessTransactionCharacteristics element will be negotiated and defined by each party according to their individual requirements.

#### 2.1.3.10. Channel ID

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.

#### 2.1.3.11. Certificate Info

The certificate section of the STAR CPA is defined using the standard constructs as defined in the ebCPPA 2.0 specifications document.

#### 2.1.3.12. Delivery Channel Definitions

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.

#### 2.1.3.13. Document Exchange Definitions

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.

#### 2.1.3.14. Transport Definitions

The STAR CPA contains a single transport definition for a standard HTTP connection. Additional transport definitions may defined to support SSL or SMTP transports as needed.

Prev |  | Next
Chapter 1. ebMS Messaging | Home | Chapter 3. Implementing ebMS Reliable Messaging