So How Difficult Is The Communication Server, Really?

I have met many people over the years who panic whenever the Communication Server in SimCorp Dimension is mentioned. But how difficult is the Communication Server really to get your head around, at least at a conceptual level? The Communication Server was built back in the early 2000’s by SimCorp as their Middleware solution, allowing customers to integrate with SimCorp Dimension in a more flexible manner. One of the first contenders for such integration was SWIFT, which up until then had been quite a difficult task, with high dependency on SimCorp consultants and developers whenever changes were needed. Nowadays, customers frequently make these changes themselves with little more than a few changes needed to an XML stylesheet.

The Communication Server is made up of two distinct parts, a Gateway and a Mediator. Although the Communication Server is a proprietary piece of technology, there are many standard technologies at play, especially where the Mediator is concerned. In software engineering, a mediator is a design pattern, which in the context of the Communication Server enables different objects to be loosely coupled. Objects in this context means messages received in many different formats and from many different media, e.g., SWIFT messages from an AMH server via a WebSphere queue, Bloomberg data through SFTP or a Web Service interface with an external system. No matter what data or where the data is sourced from, the Mediator offers a standard concept of Ports, where data is received and send statements in order to pass the data on. All making up the workflow being designed. The Gateway part of the Communication Server allows communication with SimCorp Dimension’s core, through the predefined Ports SCIn and SCOut. Last I knew the Gateway was an APL component and the Mediator a .NET component written in C#.

The preferred format within the Mediator is XML and XML technologies, mainly stylesheets (xslt) in order to transform data and schemas (xsd) in order to validate the XML message received, e.g. checking pre-agreed XML formats from external systems, to check the validity of the XML before the data is used within the Communication Server. The Cartridge Definition Language (CDL) used to write the business logic within the Mediator is, you guessed it, also XML. Knowing how to use XML and associated technologies is as such a huge bonus. If you can write an XML stylesheet and understand XPATH, you really are halfway there with the Communication Server.

The Mediator is designed as a multithreaded application, offering a separate thread for each Port that you implement. This means that Port A and Port B can execute code at exactly the same time, something to bear in mind when designing your solution, especially if resources are shared within the whole Communication Server solution, such a file on a network drive. The Communication Server even offers synchronisation in such situations, through the criticalsection statement, but let’s not get bogged down in the detail here. With this multithreaded paradigm, asynchronous design comes in very handy and works a treat with the Communication Server. Set and forget, lob the data over to a different Port, e.g., SCIn, and wait for an asynchronous callback. As an example, place a DFS message on a message queue and instruct SimCorp Dimension to give your Communication Server a callback on a specific handler within the SCOut Port. A handler is simply a way of calling different parts of code, within the same Port, such as SCOut.

Design your Communication Server solutions to benefit from the multithreaded nature and think asynchronously. Keep your Port logic short and sweet and specific, so that the purpose of the Port is well defined and potentially could be called from multiple places. There are synchronous statements you can use within the Mediator, but the longer a specific message takes on a specific Port, the longer that Port is blocked from handling the next message and Server throughput starts to decline. Asynchronous thinking, specific Port logic and send the message on, as soon as possible.

Happy developing in the Communication Server.