What is Connex?
Connex is Openlink’s name for a framework to integrate the application with other systems. There are features in the framework that offer scalability, security, high availability, auditing and guaranteed delivery. Additionally, there is support for data type translation and invalid message handling.
In this paper, we walk through some of the aspects of the Connex suite that should be evaluated as part of a Findur integration project.
What Does Connex Do?
Connex is a framework, and there are many products that implement the framework. Openlink has gateways that support common message protocols such as WebServices, JMS, and MQ. These gateways can be used to integrate Findur with any other system or enterprise service bus (ESB) that supports these protocols.
The Connex framework includes configurable event handling via method calls to perform upon the receipt of a message from another system, or upon processing of a business object in Findur (such as a new trade, or the production of a trade confirmation). Connex includes standard method implementations to handle some of these events.
The standard Connex method calls cover a range of activity such as trade services (retrieve, process, price, and more), market data services (retrieve, import), and reference data services (retrieve, counterparty import, and more). The functionality is broad, but the implementations are specific, and as with many of Openlink’s ‘standard’ solutions, they are overly generic, and unlikely to cover a client’s required use cases.
Openlink has also used the Connex framework to build packaged gateways to integrate with specific systems. For example, there are gateways to integrate with DTCC for regulatory reporting, Markit Trade Manager, TradeWeb, and much more. The scope of functionality of these products should be evaluated closely to ensure they cover all of the necessary instrument types and lifecycle events.
The rest of this paper will focus on the Connex framework, rather than specific point-to-point gateway implementations.
How Can I Evaluate Whether Connex Is Right For Me?
Connex is a licensable feature, or rather several licensable features. The cost of the licensing and implementation services can be very expensive.
An evaluation typically begins with a demonstration by Openlink of the important features available in Connex, focusing on the client’s stated use cases. From any demonstration, there is typically follow up work that the vendor needs to complete based on questions or concerns that were raised.
The vendor should also make all product documentation available at this time. Openlink typically controls documentation of licensable features so that it is only available to those clients who have purchased a license. A client evaluating a product should have all of the necessary documentation available to complete a well-informed evaluation.
Assuming the product continues to show well, the client can request a temporary license to a set of features. As with many enterprise applications, the licensing is not always easy to navigate, but more on that later.
A temporary license key period should be accompanied by some expert assistance to implement some proof-of-concept level features. It should be expected that there are professional services fees as part of this support effort. In the absence of expert assistance many clients evaluating complex software features are more likely to conclude that the product is difficult to use, or missing key features.
A temporary license key typically lasts for less than three months. Three months should be plenty of time to complete a thorough evaluation of the product. The client will then decide to purchase the product, or to go another route.
When evaluating one of the packaged gateways, it is very important to articulate the required scope of functionality early in the engagement. Detailed documentation of the required features, and any additional nice-to-have features should be documented. A formal RFP process, to which Openlink should commit in writing to having specific features available, can avoid problems, disputes and additional costs later.
Openlink may have training workbooks and videos available. Ask the account manager for these to be included as part of an evaluation. Openlink likes to charge extra for these services, but if it is part of a product evaluation, the account manager should be able to offer them for free.
A client evaluating a Connex product should also ask about other clients using the product. Clients should speak to one another about their usage of the system, the specific features utilized, and the experience during an implementation and post-go-live maintenance, upgrades and support. If Openlink will not facilitate this community engagement, we can help. We have a deep network of contacts that extends into nearly every Findur implementation around the world.
Connex Licensing
Connex licensing is complicated and costly. Let’s look at it in two steps. First, on the packaged product side. A gateway such as the DTCC gateway for regulatory reporting has relatively straight-forward licensing. Openlink will charge a fee to license the gateway, and then they charge more based on how many asset classes are required, for example, the need to report interest rate and commodity derivatives are two distinct asset classes.
For clients wishing to build their own gateways, they will need to select one of the protocols, such as MQ, JMS or WebServices. In addition, the client will need to purchase one of the Connex framework licenses. Openlink offers three levels: XML Standard, XML Professional and SDK.
XML Standard offers the ability to communicate from the external system into Findur via Connex. There is no support for consumption of a message received from an external system. This license level only allows the client to implement ‘standard’ Connex methods to complete the necessary processing of a message in Findur. This means that the ESB or external system must perform the message transformation to match the Connex standard message format. It also means that Connex must support the required use cases out-of-the-box.
It is improbable that the standard messages and processing support a client’s requirements for all but the most rudimentary requirements. We are not aware of any clients using the XML Standard license.
XML Professional adds bi-directional messaging, so data can be published by Findur, in addition to be consumed by Findur. However, the client will remain constrained by whatever features are available in the standard Connex methods. Again, we are skeptical of any client use cases that could be supported by this package, and certainly not within a well-architected solution.
The license for Connex SDK (software development kit) offers bi-directional messaging and adds the ability to implement custom method calls to control the message body and processing logic. Most clients that have real-time messaging requirements and who decide that Connex is right for them, will need to purchase a license for Connex SDK to resolve their requirements.
Cost of Connex
When the standard Connex method calls are insufficient for a client’s needs, the client would need to select the Connex SDK product. The client will also need to decide on a message protocol such as WebServices, MQ or JMS. The list price of these products, which is frequently discounted, is around $400,000. Typical annual maintenance is 20% on the list price, so budget about $80,000 per year in recurring license fees.
These are just the fees to license the intellectual property. Implementation service fees are extra. We will turn to that in the next section.
What Does a Connex Implementation Look Like?
After a client has decided to purchase the Connex license, and received the license key and gateway software, the implementation begins. We will assume that the client has selected the Connex SDK, and one of the popular message protocols (such as MQ, JMS or WebServices).
The rule of thumb is that the implementation fees on Openlink projects are about the same as the license fees. Of course, the scope of the integration effort can vary from a narrowly focused real-time trade extract, to a broad range of asynchronous messaging solution covering several trade asset classes, trade confirmations, settlements, reference data, and more. As they say, your mileage may vary. A project to implement of a broad range of functionality may take a year, or even longer.
The first task is to setup the online services, including a scheduler, protocol gateway and XML engines. There are many properties that must be configured on these services to establish connectivity. The documentation is typically limited and sometimes out-of-date referring to an old version of Findur that includes some additional properties, or is missing a few properties. This part of the project can be frustrating and involve several roundtrips with the Openlink Support Desk, including escalation to the Connex development team. Plan for this project task to take several days.
After establishing connectivity, it is a good idea to use a standard push method to confirm that a message can be sent. You may also wish to verify that a message can be received. There is a tool that supports manually dropping a message onto a queue for consumption. This is one of the many parts of the project to confirm that the technical consultant on the project has the necessary experience to provide a dedicated level of service.
The implementation of the custom processing logic will make up most of the time, effort and cost of the project. Messaging schemas must be designed and message transformation implemented. Exceptions must be handled, XML engines failed intentionally to test fault tolerance, and to make sure that messages are not lost. An analyst may use the reference data mapping tool in Connex to translate static and reference data between an external system’s representation to Findur’s representation.
Complex enterprise applications such as Findur often have bugs, and it is likely that the project will encounter some. Bugs must be documented, reported to the Support Desk, resolved by the vendor, and delivered. Include a contingency for core application bug fixes in the project plan.
As with any Findur project work, the effort will take place in a development environment. The configuration can be migrated to a test, and ultimately a production environment. It is important to test the migration capabilities. It is also important to verify that there is never an occasion where a Findur development environment is communicating with a production environment, or a Findur production environment is communicating with an external system’s development environment.
Automated system integration testing is available. Talk to us about automated testing, and we can offer specific advice.
During the implementation, be sure to allow time for thorough technical and operational documentation, as well as end-user training. System integration, whether using Connex or not, increases the complexity of the technology stack, and increases the burden on the IT support team.
Post-go-live, disaster recovery and upgrade testing must expand to include the scope of the Connex implementation. Update test cases (hopefully they are automated test cases!) and upgrade project plans to include the wide range of activity that must be tested going forward.
Alternatives to Connex
For most clients (we would argue all clients), the standard Connex methods will be insufficient to support their use cases. If the standard methods are sufficient, then the client is performing fairly limited functionality such as a query of the database, price request, or retrieval of a trade, all the while, accepting Openlink’s message schema. It is quite possible that this simple, limited functionality could be implemented without Connex at all.
Since it is unlikely that any client’s requirements are met by the standard Openlink message calls, we will assume the client has selected the Connex SDK. The client, or a professional services consultant, will need to design a message schema, and write method calls to perform the required business processing logic. Part of the design should include implementation of enterprise integration patterns that support the ease of development and on-going maintenance.
The developer will need to use one of Openlink’s APIs, either OpenJVS or OpenComponents, to perform the required business logic. OpenComponents is a more intuitive API compared to OpenJVS. We wrote a paper dedicated to that subject, so check it out here.
We have established that the integration project will involve some development effort using either OpenJVS or OC. The question clients face next is whether the Connex framework is a valuable investment, based on the features it has (scalability, auditing, high availability, etc), or whether these features could be implemented using an alternative API.
Now, more than ever, there are many open source solutions available to offer scalable, fault-tolerant, audited messaging. Openlink’s Connex framework is tightly coupled to the application. The client should engage an experienced architect, independent from Openlink to be free of a product sales conflict-of-interest. The architect should evaluate the framework’s features, especially in the context of the many alternatives that are available today.
Much of Connex’s features can be replaced using Java or .NET libraries. There are several benefits to avoiding Connex.
- Documentation: Connex is poorly documented. Open source libraries have better documentation, often entire reference manuals available, plus well-attended online forums and even video tutorials
- Cost: Connex licensing is expensive upfront, and has recurring annual fees. Many alternative messaging frameworks have none of these fees
- Integration patterns: there are open source libraries such as Camel or Spring Integration that enforce well-documented enterprise integration patterns, that can ease development effort and maintenance
- Quality: Openlink is not known for quality of product. Their regression testing is superficial. Many open source libraries are used at large institutions, and support test automation.
- Support: few of Openlink’s clients would be able to relate to a positive experience from Openlink’s Support Desk. Compare the support available from an alternative API as part of the decision about whether to select Connex as the integration framework. Also consider that the external systems, with which Findur integrates, may require the use of an alternative API anyway. If you need to have a support contract in place for the other systems, there can be benefits to consolidation of the technology around that supplier.
- Training: there are not many Connex specialists around the world able to configure, develop and support its implementation. There are many more developers around the world trained in more popular integration frameworks.
- Upgrades: Openlink application upgrades are always tricky. Expansion of the scope of the use of the application to include Connex requires additional regression test cases. Evaluate whether the effort to upgrade the application might be easier using an alternative messaging framework to Connex.
Connex Gear Development Using OpenComponents
OC has methods to support a Connex implementation, from inside Findur (in an embedded context) or from outside Findur, for example, in a Java main application (commonly referred to in the Openlink community as Toolkit mode).
In an embedded context, OC has interfaces that support development of Connex methods. While OC, far more than OpenJVS, employs object-oriented principles, many of the methods in OC rely on Table objects, which require the developer to have an intimate knowledge of the structure and content of the table.
The evaluation of whether to proceed with an integration project that uses Connex is unlikely to hinge on the decision about whether to utilize the OC Connex gear package. The effort to implement, and even more importantly, to support a production instance of Connex is the most important factor in a very important architectural decision.
