On the MegaFon Card - technical details, part 2
We continue to talk about the technical features of the project for the issuance and maintenance of MegaFon bank cards. In previous posts, we talked about the card as a financial product, its capabilities and the device software that provides the system. In this post, we will address issues related to the integration of IT systems of the “Bank Round” - MegaFon’s project partner - with the operator’s IT systems. Neoflex, a system integrator with more than twelve years of experience in the IT market, has become a technology partner in creating an integration solution that combines the IT systems of the bank and MegaFon.
The project went through several stages:
We understood that it was important not to make a mistake when designing the design of data flows. This may sound banal, but for this project this aspect was critical, because the integration affected the IT-landscapes of two different industries. Both telecom and banking have their own rules and historically established features that needed to be taken into account and “seamlessly” combined into a single data exchange process. We chose to take a pause at the start of the project and, together with the architects of the bank and the operator, develop an integration design, identify the necessary services, analyze business processes, make changes to them, then to shift them to the SOA concept. The design really managed to work out qualitatively, of course there were changes, but they were minor and did not affect the architecture of the integration solution later.
')
One of the most difficult aspects of the project at the planning stage was the presence of a large number of suppliers and contractors. Performing such a project with a classic waterfall would lead us to an increase in time, which was unacceptable. Due to the fact that the work was performed in a dynamic mode, it was practically unrealistic to fix the scope at the initial stage. We also could not work as a classic scrum, as many control points depended on suppliers of other systems. We applied a spiral approach: together with the bank, we analyzed the priorities of other suppliers, the overall objectives of the project and highlighted the blocks of functionality. This model and identified for us the composition of the iterations on the development of the project. As a result, when half the deadline for executing the entire project passed, we started analytics on services for IVR and client’s personal account, while the test environment was already equipped with an integration solution providing the card issuance process. This allowed at an early stage to determine what changes and improvements to make in the process, and the ABS team and the front of the release of cards could carry out end-to-end testing of new functionality.
The key task that faced the integration solution was to automate the flow of data through the processes of issuance, personification and activation of the card, and the performance of various operations on it, both payment and service ones. To solve, given the specifics of the problem, high non-functional requirements were presented. Everything was important: performance and message processing time, availability and change management, scalability and fault tolerance.
We chose the Oracle Service Bus solution as the main platform for integration. This is an industrial integration platform from one of the world leaders in the IT industry, which is designed to build an infrastructure for access to business services and their virtualization. Like a number of other industrial platforms, OSB has a developed tool for developing and debugging solutions, a large amount of documentation, you can also note the possibilities for quick and easy creation of complex data transformations, support from the box of a large number of different transport protocols, effective management of a large number of requests, convenient management changes. Neoflex already had successful experience in implementing projects of projects on the OSB platform, so we were confident in the solution and understood how to optimally use it for solving project problems of the Megaphone bank card, how to minimize the cost of writing code, in fact concentrating only on business functionality.
On the MegaFon side, the project affected the e-commerce gateway for debiting and replenishing the personal account, a system for managing services connected to customer phones, IVR, and the subscriber’s personal account. Also on the operator’s side, the “Sales and Service System” is actively used, through which requests for issuing and issuing cards are sent. On the bank side, the solution is integrated with the processing system, ABS, customer validation system. With all the systems except for billing, we integrated directly using industry standard technologies - SOAP and REST. Interaction with the billing system was configured using InPlat's gateway, which provides a single entry point for all MegaFon partners and provides access to e-commerce services.
Part of the project's functionality included not only the need to create traffic flows, but also complex business logic with support for asynchronous transactional computing. To implement such tasks as part of the architecture development, we decided to bring this functionality into a separate scalable solution based on java components, which was based on both the principles of the java enterprise and MSA (micro service architecture). The chosen approach allows for easy and inexpensive scaling of the load solution with the ability to quickly make the necessary changes in functionality.
Based on our experience, we understood that a critical part of such a solution is the system for monitoring the condition of the infrastructure and components of the solution and the system for auditing the processed messages. The bank uses Zabbix as a means of collecting and processing data on the state of the infrastructure, and we decided to integrate into it, having experience in using it in complex projects. When designing and creating a system, we laid monitoring points, all of them were created several dozen, they allow us to control the amount of resources used (processing flows, connections to the database, connections to external systems) and analyze indicators for processing messages, for example, the number of unsuccessful requests for the last time, the number of requests processed and so on. The developed audit system for processed messages allows you to view full information about all requests using filters and search through a convenient user interface. At the same time, various messages within one business process are combined into one chain. Naturally, information about requests, available in monitoring, is pre-processed in order to meet bank security policies and PCI DSS requirements, but this bank is enough to disassemble as quickly as possible any controversial situation. For integration it is very important, because Many systems and even several organizations are involved in the process.
Naturally on the development itself, the life of the system does not end. At the moment, we are accompanying the developed system and implementing changes within the development of the solution. I would especially like to note that the time spent on a thorough study and development of monitoring tools is more than paying for itself now while accompanying the solution. It is convenient to search for messages using various data, trace the entire chain of messages within a business transaction, and see exchanges with end systems. This allows you to quickly understand in which system the problem is, since according to the experience of developing integration solutions, the lion's share of appeals does not relate to integration errors, to integrable systems. And the most laborious is localization.
The project went through several stages:
- The Neoflex team studied business processes designed on the MegaFon side.
- Together with the bank's IT architects, we proposed a solution that allowed us to base these processes on the basis of an SOA architecture, taking into account the stability and sustainability of the system.
- Then requirements for a future integration solution were formulated, which was also developed by Neoflex.
- The next stage is development and testing, it was done iteratively, breaking the functionality into logical blocks.
We understood that it was important not to make a mistake when designing the design of data flows. This may sound banal, but for this project this aspect was critical, because the integration affected the IT-landscapes of two different industries. Both telecom and banking have their own rules and historically established features that needed to be taken into account and “seamlessly” combined into a single data exchange process. We chose to take a pause at the start of the project and, together with the architects of the bank and the operator, develop an integration design, identify the necessary services, analyze business processes, make changes to them, then to shift them to the SOA concept. The design really managed to work out qualitatively, of course there were changes, but they were minor and did not affect the architecture of the integration solution later.
')
One of the most difficult aspects of the project at the planning stage was the presence of a large number of suppliers and contractors. Performing such a project with a classic waterfall would lead us to an increase in time, which was unacceptable. Due to the fact that the work was performed in a dynamic mode, it was practically unrealistic to fix the scope at the initial stage. We also could not work as a classic scrum, as many control points depended on suppliers of other systems. We applied a spiral approach: together with the bank, we analyzed the priorities of other suppliers, the overall objectives of the project and highlighted the blocks of functionality. This model and identified for us the composition of the iterations on the development of the project. As a result, when half the deadline for executing the entire project passed, we started analytics on services for IVR and client’s personal account, while the test environment was already equipped with an integration solution providing the card issuance process. This allowed at an early stage to determine what changes and improvements to make in the process, and the ABS team and the front of the release of cards could carry out end-to-end testing of new functionality.
Briefly about the main thing
The key task that faced the integration solution was to automate the flow of data through the processes of issuance, personification and activation of the card, and the performance of various operations on it, both payment and service ones. To solve, given the specifics of the problem, high non-functional requirements were presented. Everything was important: performance and message processing time, availability and change management, scalability and fault tolerance.
We chose the Oracle Service Bus solution as the main platform for integration. This is an industrial integration platform from one of the world leaders in the IT industry, which is designed to build an infrastructure for access to business services and their virtualization. Like a number of other industrial platforms, OSB has a developed tool for developing and debugging solutions, a large amount of documentation, you can also note the possibilities for quick and easy creation of complex data transformations, support from the box of a large number of different transport protocols, effective management of a large number of requests, convenient management changes. Neoflex already had successful experience in implementing projects of projects on the OSB platform, so we were confident in the solution and understood how to optimally use it for solving project problems of the Megaphone bank card, how to minimize the cost of writing code, in fact concentrating only on business functionality.
Empirically
On the MegaFon side, the project affected the e-commerce gateway for debiting and replenishing the personal account, a system for managing services connected to customer phones, IVR, and the subscriber’s personal account. Also on the operator’s side, the “Sales and Service System” is actively used, through which requests for issuing and issuing cards are sent. On the bank side, the solution is integrated with the processing system, ABS, customer validation system. With all the systems except for billing, we integrated directly using industry standard technologies - SOAP and REST. Interaction with the billing system was configured using InPlat's gateway, which provides a single entry point for all MegaFon partners and provides access to e-commerce services.
Part of the project's functionality included not only the need to create traffic flows, but also complex business logic with support for asynchronous transactional computing. To implement such tasks as part of the architecture development, we decided to bring this functionality into a separate scalable solution based on java components, which was based on both the principles of the java enterprise and MSA (micro service architecture). The chosen approach allows for easy and inexpensive scaling of the load solution with the ability to quickly make the necessary changes in functionality.
Based on our experience, we understood that a critical part of such a solution is the system for monitoring the condition of the infrastructure and components of the solution and the system for auditing the processed messages. The bank uses Zabbix as a means of collecting and processing data on the state of the infrastructure, and we decided to integrate into it, having experience in using it in complex projects. When designing and creating a system, we laid monitoring points, all of them were created several dozen, they allow us to control the amount of resources used (processing flows, connections to the database, connections to external systems) and analyze indicators for processing messages, for example, the number of unsuccessful requests for the last time, the number of requests processed and so on. The developed audit system for processed messages allows you to view full information about all requests using filters and search through a convenient user interface. At the same time, various messages within one business process are combined into one chain. Naturally, information about requests, available in monitoring, is pre-processed in order to meet bank security policies and PCI DSS requirements, but this bank is enough to disassemble as quickly as possible any controversial situation. For integration it is very important, because Many systems and even several organizations are involved in the process.
Naturally on the development itself, the life of the system does not end. At the moment, we are accompanying the developed system and implementing changes within the development of the solution. I would especially like to note that the time spent on a thorough study and development of monitoring tools is more than paying for itself now while accompanying the solution. It is convenient to search for messages using various data, trace the entire chain of messages within a business transaction, and see exchanges with end systems. This allows you to quickly understand in which system the problem is, since according to the experience of developing integration solutions, the lion's share of appeals does not relate to integration errors, to integrable systems. And the most laborious is localization.
Source: https://habr.com/ru/post/327090/
All Articles