Migration of middleware to the Cloud

We show you the process from the old BizTalk system to Anyway.

The Commercial & Financial Markets Platforms area manages CaixaBank’s treasury operations, specifically for currency, debt and derivatives products. 

These transactions are handled through middleware, which deals with processing the operations of each source system and transforming the messages into an understandable format before sending them to the recipients. But the rising demand in their use led us to seek another solution, and, this time, we opted for an ad hoc development with Java technology and cloud infrastructure. We’ll tell you all about the process!

How did the old middleware work?

The original middleware, implemented under a market tool based on proprietary software external to the Bank, is deployed on Windows servers. This middleware routes, under certain criteria, the messages from different origins to the available destinations. With the increasing demand for the use of this middleware and the implementation of more and more Treasury products, the software developed could not be adapted in an agile way to the business needs. Faced with this situation, we detected the need to change to a proprietary software of the Bank (developed ad-hoc) with an infrastructure that complied with the standards that CaixaBank was committed to.

Evolution of the middleware to Anyway

In this regard, it was decided to create a tool from scratch, under Java technology and cloud infrastructure. This new software, called Anyway, would make it possible to have the logic completely developed in-house, specifically adapted to the needs of the different business areas and with total control within the Bank. Additionally, the cloud infrastructure would allow for lower costs (by not having pay for licences or active physical servers), more hardware power and more agility and efficiency in the processing of operations.

To ensure that the performance of the new tool was efficient, robust and was adapted in an agile way to any future changes, the solution was designed with following components:

Developments in Java

Components developed in this technology and deployed in the cloud infrastructure. Every circuit managed in the middleware is divided in an independent component, from which different mappings and the necessary transformations are implemented. In addition, every component will maintain its own specific configuration, which makes it possible to have a specific component for each circuit.

A core component is also implemented that will serve as the common base for all the Java components developed. In this design, the specific components will call the core when a generic action on a transaction is required. This solution means that any changes required in the global component of the application can be applied generally and at the lowest cost.

Differentiation by components makes it possible to isolate errors in the event of failure, avoiding propagation to the other circuits and therefore to the operations managed through them.

Use of Oracle database

Where all transactions and messages processed and transformed between the different sources and destinations are kept. It also makes it possible to have greater traceability, keeping a record of messages processed.

MQ queues

Every system writes its transactions, the middleware processes and transforms them and sends them through another output queue to each destination as appropriate. This design allows the transactions to be available in the queues themselves, as long as they are not read, and in the event of a global application error, to re-establish operation without impacting business operations. It also allows for exhaustive monitoring by having the load of each queue in real time and the way in which these transactions are being managed during the day.

GIT versioning

The Java code is maintained in a common repository for all developers, where the different implemented classes are published and versioning of changes is kept. This allows a great control of the modifications with respect to the previous middleware.

Web front end on the cloud

This tool allows a specific monitoring of each transaction processed by the middleware, as well as performing certain specific actions on them, facilitating the support work of the team in change of maintaining the application.

This solution gives us the following benefits:

• It allows CaixaBank’s teams to be more autonomous in the management of the transactions that go through the middleware, and with much lower costs.
• Significant reduction in maintenance cost, as the
  physical servers necessary for the operation of the old tool are decommissioned, as they are not needed on the cloud.
• Agility of adaptation to changes in the operation or performance of the tool, due to business requirements.
• Alignment of the solution with the leading technologies and infrastructures and with the aim of migrating the systems in CaixaBank.

Now you know how we evolved from the old Treasury middleware to the cloud.