Integration bus for Bank SOYUZ (AO): design and auto-testing

It is difficult to overestimate the importance of testing, especially when it comes to an integration platform for the interaction of credit conveyor systems. In this article we want to talk about how our team first designed such a bus, and then launched auto-tests for it.

What is an integration platform and why is it needed?

In large corporate systems, there are often problems of interaction between internal subsystems. Due to endless connections and requests, such a tangle over time becomes more and more confused and complicated. Its getting hard unwind maintain and manage it.

Each subsystem has its own release cycle: some are updated once a year, and some – once a week. These changes also need to be taken into account and integrated into the overall system canvas. To do this, you need an intermediary who exchanges data between all subsystems of the company. This intermediary is the integration platform.

In search of an artist for its development, the customer prepared a test task that needed to be implemented and protected. It was a fairly simple description of a task with several selected systems: database, service, file directories, etc. Within a week, it was necessary to create and demonstrate a fault-tolerant solution, as well as describe the development platform. In the implementation of such projects, we have gained decent experience, and according to the results of the defense we were chosen as the executor.

At that time, the customer in most cases used a point-to-point integration scheme: each system integrated with another. It was inconvenient and difficult to maintain. We have three tasks:

  1. replace existing integration through an integration platform;
  2. integrate new bank systems;
  3. Automate data exchange between them.

After successfully passing the test task, we started the project. Its phasing for themselves was determined in this way:

  • conduct an audit;
  • find customer employees who understand the target state of business processes (and not just the current one);
  • to formulate business requirements for IT systems and provide a roadmap for transition to the target state of business processes.

Implementation

For implementation, they chose the modular integration platform Red Hat JBoss Fuse.


JBoss Fuse Architecture

A little more about the basic tools that are out of the box:

Apache camelbuilt on corporate integration templates (EIP), provides message routing, has a large number of ready-made adapters for working with external systems: databases, files, message brokers, directory service, mail, etc.

Apache ActiveMQwhich organizes the exchange of messages, and also ensures their transmission and storage until the subscriber picks them up.

The integration process itself (flow) is a set of sequential actions. For example: receive a message from the source system through a developed / existing adapter, convert the message data, add, filter, transmit further to the receiver systems through their adapters.


Integration process

At the same time, verification of the data, their guaranteed delivery, error handling with the provision of the ability to collect a monitoring system, informing responsible executors about errors, etc. should be provided along the way.

Example

Take the process of issuing loans at a bank. A client in the Internet bank fills out an application, sends the data from the form and waits for the result. What happens inside this: through the rest api provided to the Internet bank, the bus accepts the request with the main data. Further, he requests through the soap interface in the MDM system additional information about the client, combines the information received into a common set, and transfers it through the ActiveMQ dedicated queue to the RTDM system to formulate an offer within the framework of existing loan products. Then the result from RTDM is returned in return, and the bus transmits the offer for the client back to the Internet bank.

Testing

When the integration bus passed to testers, initially the issue of product testing was decided manually. However, in the process, it was decided to automate the entire process and create a test platform.

We wrote emulators for all bank systems. Clients do not always provide access for testing on working data and systems at once, therefore emulators were developed for each project separately. The complexity of this work is comparable to the development of the integration solution itself. The test platform had a task: to collect, deploy, run the test and send the results to TestRail.

We made two sets of scripts that were run during each build (CI / CD). According to the commit, the assembly was initiated and deployed to the stand. After the deployment procedure, a short script (smoke test) was run, which let us know that no integration interactions were broken.

We were chasing an extended scenario for night assemblies, which gave us a complete answer to the question: what is with the bus and how does it interact with external systems? In the morning report, we saw successful tests or problems that appeared. However, we did not automate testing of the integration platform with external systems, since it is very difficult to verify the results of such testing. Therefore, they left manual testing: the customer’s employees carried out acceptance tests of their systems, and our specialist checked by logs whether the information passed correctly.

As a result, it was possible to achieve 100% test automation on emulators. When updating one of the external systems, the bus took on the task of maintaining the business process operability; accordingly, changes were made directly to it. This allowed you to quickly test any changes.

Instead of a conclusion

After all the stages passed, our team built fast and transparent processes with contractors and customers, and further development, testing, implementation and support processes went simply. As a result, 12 business processes were automated, which in their essence combined the work of the bank’s main systems: ABS, MDM, processing, RTDM, etc. In such projects, we always try with the help of automated testing, practically without involving functional testers. This reduces the final cost of project development and integration, reduces time to market and levels the human factor.

Alexander Sadykov, Deputy Head of Testing Department, Center for Software Solutions, Jet Infosystems

Pavel Ivanov, Head of Development Group, Center for Software Solutions, Jet Infosystems

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *