Case study: Integration with other systems

Billing module components

The billing module consists of the four components application, functionality, I/O and the OSB database objects as shown in diagram

Diagram Components of billing module

The billing application controls the billing process. It is, e.g., responsible to determine the contracts to be billed and for the distribution among several billing processes. The application is customer specific and therefore not part of the OSB library.
The sample billing applications is of course not able to use any customer specific OSB library extensions, it is rather supposed to be the starting point for any customization needed.

The billing application relies on the I/O functions for read or write access to the database and uses the billing functions to create the invoices. Billing functions that need information from the database also use the I/O layer, retrieved data however should be cached in the billing application to avoid unnecessary I/O operations.

For the communication between the billing application, the billing and the I/O functions OSB objects are used. The I/O layer translates between OSB objects and the OSB database objects.

The separation of the billing functions from the I/O as indicated in diagram I is idealized. The way I've shown it will help us in understanding how other system can actually intergrate the OSB billing module.
In reality object-oriented design suggests that read and write operations should be member functions of the OSB classes. Of course there are pure data classes and mere functional classes that rely on them, but we will also have classes where both aspects are mixed.
The important thing is that in all classes I/O operations are isolated what allows to overwrite them if, e.g. a different database server is used.

By definition the database I/O methods of the OSB classes are implemented for the default database server.

The billing application should control all updates of the database. A billing function therefore should not write to the database via the I/O module. Any exception to this rule must be clearly documented.

Integration with other systems

Diagram shows the collaboration of the OSB billing module with another system: CC&B.

Diagram Integration with OSB billing

Existing CC&B applications like Customer Care and Rating produce data that are stored in the database CCB. Billing collects the data generated by other modules and uses the billing functions of the OSB library to create the invoices. The database OSB is not shown in the diagram: it depends on the integration strategy whether it is needed at all.

Communication via OSB objects

Any integration of the OSB billing module into a CC&B system must respect the principle that the billing functions of the OSB library only work with OSB objects: Offering other interfaces would mean that the core of the library must be permanently changed, not because new functionality is added but for integration with other systems. Such an approach of course would be unfavorable for the stability of the library.
As a consequence of this principle the billing application has to use OSB objects, though it might rely on other objects as well. I/O operations that are needed by the billing functions have to support OSB objects as well.

Strategies

With the rules as described above we have three approaches how to integrate the OSB billing module:

• Firstly we can change the applications of the target CC&B system to store data as OSB database objects where appropriate.
• Secondly we can change the I/O functions to translate CC&B database objects into OSB objects used by the billing application and vice-versa.
• The third possibility is to translate data generated by the CC&B system and to store the result in a dedicated database for OSB, that logically is the slave of the CC&B database. The results of the billing process need to be stored in the master CC&B database in a similar manner.

Database with OSB objects

In this approach existing applications of the target system are changed to read and write OSB database objects if billing relevant data are involved. In terms of OSB such data are taxation keys, products and product items, ... .
This strategy allows unrestricted use of all available billing functionality at the cost of the implementation effort in the applications of the CC&B system.

Replacement of I/O functions

It is not always possible to change applications of a CC&B system. This means that OSB billing on one hand must use the foreign data while on the other hand OSB objects are needed to access the billing functions. In order to fulfill this requirement we can extend the I/O functions of the OSB library to create OSB objects from database objects of the target system and vice-versa as shown in diagram

Diagram Replacement of OSB I/O functions

The replacement of the OSB I/O functions is only possible if their interface remains unchanged, however additional I/O functions may be provided in the interface of the CCB I/O library if necessary. Additional, OSB specific configuration data are needed. They may be either stored in a separate database OSB as indicated in diagram III or -if we are allowed to do so- inside the database of the CC&B system.

This method has the advantage that no extraordinary changes are needed in the billing application; but some OSB billing features may not be usable, simply because necessary are not maintained by the taget CC&B.

Master - slave databases

In this approach the data stored in the CC&B database (master) are translated and stored in the OSB database (slave). The billing application uses solely the OSB database to generate the invoices and to store the results. In a subsequent step the results are translated and made available in the CC&B database. The synchronization between the CC&B and OSB database can be obtained by several means:

• Batch Synchronization: A batch program periodically browses the CC&B database for changes and calls the translator to synchronize the changes in the OSB database.
• Real time: Whenever a CC&B application creates or modifies data, the translator is invoked making the necessary changes in the OSB database. Either the applications themselves or database triggers are responsible to initiate the translation. Real time synchronization requires also a batch mode that allows to realign the OSB database after it was not available, e.g., for maintenance reasons.
  
• On-demand: Whenever billing needs CC&B data it requests their translation. The results are stored in the OSB database from where they can be retrieved by the billling application.

The master - slave model allows the complete separation of the billing from other applications. The main problem yet to be solved is how we can guarantee the accuracy of the synchronization between the databases.
It should be noted that the real time mode is quite similar to working directly against OSB database objects, and that on-demand more or less corresponds to the replacement of the I/O functions. The main difference is that data are stored twice, once in CC&B and a second time the OSB database.

Conversion of identifiers

Ideally, in an integrated system, there is a central customer database which is used by all systems. This customer database will have some sort of unique identifier to reference a customer. In practice, every connected system will have its own customer structure and customer identifier. In between, there is a need to translate identifiers. I.e., every satellite system will have to provide two conversion functions:

masterCustomerID = convertID ( satelliteCustomerID )
satelliteCustomerID = convertID^-1 ( masterCustomerID )

Now let's assume that two satellite systems are connected to a master system and the two satellite systems also need to interact with each other. In this case, the satellite systems will communicate using the masterCustomerID. There will not be any additional conversion functions for the direct conversion of identifiers between satellite systems.