Connecting SAP Treasury to external dealing platform FXAll using PI
In this blog I would like to share my experiences implementing an interface between SAP Treasury and the external dealing platform of FXAll using SAP PI.
As part of a large SAP implementation project for a corporate Treasury our customer wanted to automatically replicate treasury deals from the external dealing platform to SAP ECC 6.
As a service the dealing platform provides their customers with client software that connects to the platform and retrieves the deal data in xml format. Looking at the specifications of the client software I can see that the connection is established using https and I think: "XML and SSL... PI can do that!". The idea of not having to install additional software connecting to an external partner was very appealing. Of course, there was a catch.
SSL
First of all, there was the SSL connection. A quick test with the provided URL via an HTTP connection in SM59 failed: certificate mismatch. As it turned out, the provider uses 2 url's, one for test and one for production, but both hosts present the same certificate. To overcome this issue we have updated the hosts file on the PI server to trick the system to believe that's connecting to the hostname that is also present in the certificate.
We decided to trigger the http-request from the back-end system via an ABAP proxy, so it can be controlled from there. The proxy was generated and the PI configuration was done. Since we expected that we would require an adapter module later on, we configured the connection using a SOAP channel. Time for the first test.
This was a great lesson in SSL for me. All connection attempts using the SOAP channel where aborted with the error: ‘Connection closed by remote host'. It turns out that the SOAP adapter is using TLS v1.1 (which is equal to SSL v3.2), while the FXAll web dispatcher supports SSL v3.0. This is usually not a problem, since the protocol negotiates the lowest version of the protocol in the handshake step. However, the web dispatcher did not comply with the protocol.
Finally we switched back to the HTTP-adapter using the RFC-destination, since the RFC connection is using the SSL v3.0 protocol.
ZIP
The http-response is a zip-file, possibly containing multiple xml-files. Originally we tried to unzip it using the PayloadZipBean that SAP delivers with PI. The unzipping goes fine, but the result is a PI message containing multiple attachments. It is not possible to call a mapping for each single attachment. In the end we let go of the adapter module (also because we needed to use the http-adapter that does not allow for modules) and developed a java map that is doing the unzipping and creates a multi-message.
Enterprise service
The xml message from FXAll needed to be mapped to a format that the SAP system understands. SAP delivers two enterprise services for processing treasury deals: the asynchronous TreasuryDealNotificationIn and the synchronous equivalent TreasuryDealNotificationResponse. There was no apparent requirement for a synchronous scenario, so we started off with the asynchronous service. Testing the service learnt that the message will always be successfully processed. This does not mean that you will also have a treasury deal in your system. This particular proxy does not generate application errors and thus cannot be managed via the Forward Error Handling mechanism.
Luckily the synchronous service does respond with a meaningful error message in case of an issue. We have now implemented this and send the response in case of an error via the mail adapter to the treasury department.
Conclusion
We are live! The interface is running for a couple of weeks now and without the client software. I hope this blogs saves you from some headaches in case you meet similar requirements.
