Page 1
Chorus B2B Gateway User Guide 22 May 2009 Version 0.4.3...
Page 2
This table shows a record of significant changes to the document. Version Date Author Description 10 February Dane Moodie First draft for review by Chorus. 2009 23 February Dane Moodie Updated based on feedback from Jacqui Barclay. 2009 Updated CPA example based on IBM feedback.
TESTING YOUR IMPLEMENTATION.................. 21 3.1......................21 ESTING NTERNALLY 3.1.1. Sending Messages ....................21 3.1.2. Receiving Acknowledgements from Chorus..............24 3.1.3. Receiving Messages from Chorus ................25 3.2....................26 HORUS ONNECTIVITY 3.3................26 ESTING AGAINST THE HORUS ATEWAY MOVING TO PRODUCTION ....................
1. Introduction 1.1.1. Objectives of Manual The Chorus B2B Gateway is intended to allow Chorus’ customers to access our products and services utilising a business to business document exchange mechanism. This User Guide will define the technical steps that should be followed to allow your business to begin trading with us through our B2B Gateway.
Page 5
Message Service: one of the ebXML protocols utilised by the Chorus B2B Gateway ebXML The suite of protocols implemented on the Chorus B2B Gateway HTTP Hypertext Transfer Protocol: The application layer protocol used for communicating with the Chorus B2B Gateway...
Encryption will be achieved via the use of HTTPS with the Chorus B2B Gateway rather than XML Encryption. Essentially this moves encryption outside the realm of the ebXML layer, and into the communication layer.
1.5. Assumptions This guide assumes that • your business has been accepted to trade via the Chorus B2B Gateway. This guide will not provide information on legal agreements that must be signed, or accounts that must be established. • you have selected a Message Handler System, and implemented it within your company.
Chorus B2B User Guide 2. Getting Started In order to begin communicating with us via the Chorus B2B Gateway, you must implement an ebMS 2.0 compliant Message Service Handler (MSH). This MSH will typically be exposed to other applications within your company allowing these applications to send business documents through it to Chorus, and receive business documents from Chorus.
2.1. Overview In order to begin using the Chorus B2B Gateway, the following steps need to be followed. These will be defined in detail in the remainder of this document: 1. Implement and test your MSH internally 2.
The email address for alerts generated from the Any alerts generated by the Chorus B2B Gateway will be sent to this email address. If this is not included, alerts will not be sent via email. The list of alerts that will be sent is described in section 6.
This information will form the basis of the two Collaboration Protocol Agreement (CPA) documents that will be provided to you during the on-ramping process: 1. A CPA document that can be utilised for testing your MSH against the Chorus Test B2B Gateway.
Telecom will accept certificates signed by any of the root CAs recognised by the internet Explorer web browsers. Please send an email to Chorus at b2b@chorus.co.nz if you have any doubts about the CA you have utilised. 22 May 2009 Page 20 Version 0.4.3...
2.4.2. Test Keys You will be required to use a separate set of keys against the Chorus Test B2B Gateway from that used against the Production B2B Gateway. Exactly the same rules and instructions apply as above, except the certificate may be a self-signed certificate rather than a certificate signed by a CA.
Chorus B2B User Guide message (both receipt acknowledgements and business level responses). If you do not provide a Conversation ID, the Chorus B2B will generate a Conversation ID on your behalf. 9. An section exists, and at least 1 message is present.
Chorus B2B User Guide <eb:MessageId>123326619475500144FF9A57002097481268D135F6C377A@www.cisdal.com</eb:MessageI d> <eb:Timestamp>2009-01-29T21:56:34</eb:Timestamp> <eb:RefToMessageId>123326527165700144FFBB5C30066399501C6A1DB0D8178@sv2886.uname.telecom.c o.nz</eb:RefToMessageId> </eb:MessageData> </eb:MessageHeader> <eb:Acknowledgment SOAP:actor="http://schemas.xmlsoap.org/soap/actor/next" eb:version="2.0" soapenv:mustUnderstand="1"> <eb:Timestamp>2009-01-29T21:56:34</eb:Timestamp> <eb:RefToMessageId>123326527165700144FFBB5C30066399501C6A1DB0D8178@sv2886.uname.telecom.c o.nz</eb:RefToMessageId> <eb:From> <eb:PartyId>123456789</eb:PartyId> </eb:From> </eb:Acknowledgment> </soapenv:Header> <soapenv:Body/> </soapenv:Envelope> The following points must be checked: 1. The party information is identical to that in the initial request, except that parties are reversed.
We will provide a series of messages that can be sent to the Chorus Test B2B Gateway, together with the responses that can be expected. By verifying that the messages received in response correspond to those expected you can verify that your Message Service Handler is configured correctly.
4) Ensure Chorus have been notified of the IP addresses that connections will be established from. You may not send test messages to the Production Chorus B2B Gateway, however we do support the Ping service specified in the ebMS 2.0 specification. You may invoke our Ping service as a final connectivity test before using genuine services.
SSL. This ensures that no third parties can view the contents of the messages exchanged. You are also required to implement SSL on the endpoint of your MSH when receiving messages from Chorus. This ensures that any message sent by us can not be viewed by other third parties. 22 May 2009 Page 28 Version 0.4.3...
Chorus B2B User Guide If you do not wish to implement SSL inside your Message Service Handler, you may implement SSL in a proxy layer in front of your Message Service Handler. Our requirement is that any traffic routed over the Internet must be encrypted; there is no requirement that messages must be encrypted once inside your network.
Need help?
Do you have a question about the B2B and is the answer not in the manual?
Questions and answers