Background
One of our clients is organized in this way: a central service (or service center) provides services requiring subscriptions and local structures manage the administrative aspects (maintaining a clients base, creating new contracts…). Client data registered at local level have to be communicated to the central service’s data repository. In return, local data repositories should receive a report of delivered services from the central service. The central service and local structures use a different software ; the one of local structures is declined in about forty instances.
Previous architecture
A complex architecture had been implemented to adapt to this specific organization. The 40 local instances and the central instance were exchanging data through an intermediate application (ERP). This intermediate application was used to define which instance should receive messages from the central instance (message routing). A huge amount of data from local instances was delivered to the ERP but not all of them were relevant. Thus, the intermediate ERP was also used to filter information to update when necessary. The ERP communicated with local instances and central instance through a Message-Oriented Middleware (MOM).
Issues
These architecture choices (especially the use of MOM to send messages and of an intermediate ERP for routing and filtering) led to several problems:
• The use of an ERP (intermediate instance) to transmit data was not efficient in terms of performances,
• Several data repositories were coexisting and their update was not coordinated. No data repository was declared as a master one, it was difficult to determine the most up-to-date information (for example, which was the current address of a subscriber),
• MOMs were only used to assure messages transportation. There was no supervision. From the MOM interface, users could not determine if a message was successfully transmitted or not. Thus, some messages were lost. To get around the problem, employees carried out manual checks,
• The service center needed to access information related to local instance emitting a service request before handling it and communicating a feedback to the instance concerned. To take this task off central service, an urbanization of the information system architecture had to be planned.
Implemented solution
To solve these problems, we implemented a different architecture. Both the intermediate application used to filter and route messages and MOM have been removed and replaced by Xbus.
In addition to Xbus implementation, we assisted client’s teams in:
• Defining the nature of the messages sent by each instance to get a clear exchange pattern: the forty local instances are now data masters regarding the information related to clients. The central service only sends messages showing events that occurred for a given contract number (delivered service reports),
• Filtering the data before it is sent: the client’s teams defined which local data update should be sent to the central service. For example, when a new contract is created, the service center gets its number but not the ID of the local instance involved. Indeed, the subscriber’s affiliation with a local base can change in case he or she moves, and a separate matching table connects contract numbers with local bases. A change detection mechanism has been implemented into local instances. In that way, updates are automatically sent to the service center through Xbus. Therefore, it is no longer necessary to filter messages afterward through an intermediate instance.
This solution enables to:
• Improve performances: being by its nature a solution designed for integrating data, Xbus has been made to support continual exchange load ; performances are thus increased,
• Guarantee message delivery: Xbus guarantees data transport, even when the consumer application has been turned off at the time the message is sent (asynchronous data transmission),
• Control data transport: unlike MOM previously used, the bus is not only used to transport messages but also to oversee their delivery (check whether each message has been received, follow precisely their progress, know which applications are available and access to their connection history, know the processing time between the different systems),
• Assure message routing: the system used by Xbus to deliver messages (pipelines and nodes) makes it easier to develop routers. A specific router has been developed for this client to send messages from the central service to the local instance involved. It would not make sense for the central service to know in advance which local structure it wants to send messages to since the service center and local structures are not managed by the same entity. The router identifies the local structure which the message is aimed at thanks to a matching table. The matching table puts together the subscription contract number (included in messages sent by the central service) with the subscriber and the local structure involved. This table is filled with new content each time a contract is created,
• Urbanize the information system architecture: from now on, the service center can focus on the business part and no longer has to assume the role of common repository. Indeed, the central service only sends a report regarding events that occurred on a contract and Xbus, using the matching table, is in charge of routing the message to the relevant local base.
Benefits:
Our client received several benefits from the new implemented architecture:
• Increased speed for data transmissions → it enables the organization to increase their reactivity,
• Data exchange reliability → no message loss with drastic consequences (for example, providing a service to the wrong place),
• Existence of a master repository (central service’s one) which differs from the message transportation solution → no mistake due to several systems for subscriber referencing and equipment assignation,
• Urbanized information system → optimized information exchange visibility ; facility to grow the information system,
• Centralized access, connections and error reports management → better control of data exchange.
Convinced by Xbus efficiency, our client made all of its partners implement the solution. The use of Xbus has thus been extended to 10 other service centers.