Search  
HOME  |  CONTACT  |  Site Map Register  |  SIGN IN
Downloads Video Library PSP Blog
Print Content   About PSP » Technical Overview » Technical Description
 
Proven Interoperability
“PSP is a finished standard that has been proven successful by those dealers and suppliers using it in the powersports industry. Endorsement of PSP by the MATES board provides the marine industry a complete communications solution that can be implemented in the shortest possible time. ADP Lightspeed believes the implementation of PSP by MATES member companies shows the most promise of delivering better, more efficient information to marine dealers and the consumer.”
 
Eric Johnson , Director of Technology at ADP Lightspeed .

Technical Description

Partners Standard Protocol (PSP) defines an interoperable method for transmitting business data between dealers and suppliers. It is designed to enable implementation of a single transport and map proprietary formats to a common data structure that allows communication without writing custom code. A summary of the PSP specifications follows:

  • WebServices using STAR Web Services Specification and Transport Guidelines.
  • Messages encrypted using HTTPS
  • Transport contents are STAR XML Business Object Documents (BODs), including Parts Order, Parts Locator, and Parts Shipment
  • Other BODs will be added
  • WS-MetadataExchange is implemented to get business rules, security policy and BOD support policies of suppliers
  • Privacy assured by the use of HTTPS
  • Authentication of dealer by user ID and password
  • Authentication of supplier by their shared UDDI provider key and use of their digital certificate and HTTPS
  • Based on the OASIS standard of WS-Security, the user ID and password are transported in the SOAP header
  • Can utilize existing usernames and passwords (if currently implemented)
  • Business rule files can be consumed by DMS applications for dynamic implementation of custom business rules determined by the supplier. For example, supported shipping methods and acceptance of credit cards
  • The exact fields eligible to this approach are limited, constrained by schemas defined by the MIC
  • Supplier specifies the expiration time of the business rules life
  • Supplier Web service is listed in a private, Universal Description, Discovery and Integration (UDDI) registry
  • The supplier UDDI entries express the fact their Web services are an implementation of a STAR Web service
  • The BOD support policy (BOD, verbs and version supported by a supplier) can be discovered by a DMS using WS-MetadataExchange
  • New versions of supplier business rules XML files can be automatically retrieved

 

 

PSP Parts Order Transaction Example

The following is an example scenario for a PSP parts order transaction:

1. To initiate a parts order

  • Order Entry - dealer enters the order into their dealership management system (DMS)
  • Message Creation - DMS transforms the parts order to a standard Parts Order XML message and wraps it in a SOAP envelope
  • Security - DMS secures the message by
    • Authentication - Populates the SOAP header with the user ID and password assigned to the dealer by the supplier
    • Privacy - Establish a HTTPS connection to the suppliers Web service, which is a private connection
  • Transport - DMS routes the message by
    • Sending the secured SOAP message to the supplier Web service
    • Waiting for the response to be returned from the supplier

2. Upon receiving a Parts Order BOD

  • Security - Supplier system receives the message through the HTTPS connection and authenticates the dealer
  • Business Processing - Supplier processes the request and formulates a response message
  • Message Creation - Supplier translates the response to a PSP compliant XML response and wraps it in a SOAP envelope

  • Transport - Supplier transmits the response to the dealer using HTTPS and the DMS processes the response at the dealer 

 

The following are the periodic tasks a DMS would perform to enable efficient communications with supplier Web services:

  • Communicate with the UDDI to determine the current supplier Web service end point URL and cache for future communications
  • If reaching a supplier endpoint fails, query the UDDI to retrieve an updated endpoint reference
  • Communicate with the supplier Web service to retrieve and cache the
    • Business Object Document (BOD), verbs, and versions supported
    • Currently supported supplier specification business rules XML file versions
    • New supplier specification business rules XML files
  • Communicate with the supplier Web service to
    • Initiate a PullMessage request to retrieve message originating from the supplier

The following are the typical tasks performed to communicate a business transaction with a supplier Web service:

  • Validate the transaction to the supplier specific business rules. This would be most applicable to the ProcessPartsOrder BOD in the initial set of Business Object Documents (BODs) implemented
  • Translate the message into a STAR BOD
  • Package the BOD into a SOAP envelope expressing the Web method to be called and the proper message headers
    • Using OASIS Standard 1.0 Web Services Security Username Token Profile 1.0 for Username and Password
    • STAR PayloadManifest
  • Route the message to the supplier endpoint using HTTPS
  • If a synchronous request (ProcessMessage Web method), wait for the supplier response
  • The supplier Web service will
    • Authenticate the SOAP envelope
    • Receive the message(s)
    • Validate schema compliance and business rules
    • Translate to internal data structure requirements
    • Process the message(s) and formulate the response
    • Translate the response(s) to STAR Business Object Documents (BODs)
    • If a synchronous request, respond back to the client
    • If an asynchronous request, queue the response for later pickup by the DMS
  • If a synchronous request, the DMS will receive the pass/fail response
    • If successful, the response could be the positive response to the request. For example:
      • AcknowledgePartsOrder
      • ShowPartsOrder
      • A Confirm BOD for a successful CancelPartsOrder
    • If not successful, the response would be a Confirm BOD explaining the error
  • If an asynchronous request, the DMS receives responses at a later time using the PullMessage Web method. This will retrieve ALL outstanding messages from the supplier. This could include messages originating from the supplier to the DMS.
  • Both the DMS and the supplier will address exceptions in data and/or transaction transmission, receipt, etc. to notify the appropriate participants of errors in the transaction.
©2008 TranStand, Inc.   PSP PartnersRVIAMATESPowersports - MIC Terms & Conditions  |  Privacy Policy