On Integration: Consolidated View

In my last post, I wrote about four integration scenarios using databases: Reference data, Consolidated view, Subscription and Publishing. Of these, the Consolidated View scenario requires the most interaction between the server and the client roles. This post will examine how to make the pieces fit together.

Consolidated view joins the data of multiple clients into a consolidated view. This makes you able to create administrative applications that span a set of subapplications without having to change the central view when a new application joins the mix.

consolidated-view-application In order to work smoothly, a Consolidated View application uses two forms of integration: The client application write to their partitions of a table in the server application, and the view of the server application redirects to the view of the client applications. Here is an example:

  1. A user wants to list all the contracts defined for a customer, regardless of what application manages that contract
  2. The Consolidated View application lists some contracts from Client Application 1, some contracts from Client Application 2 and so on
  3. The user clicks on the line associated with a Client Application 1 contract
  4. The consolidated view application has registered the URL for this kind of contract to be handled by a another application. It redirects (or proxies) the user to (for example) http://a.server.name:3223/clientApp1/contracts/foo_contract/?id=3313
  5. Client Application 1 lets the user interact with the data in any way the user desires
  6. Client Application 2 updates the consolidated view application database to reflect any changes to the contract
  7. The Contract has a link back to “View All Contracts for this Customer”. The user clicks this link and is brought back to the Consolidated View application
  8. The user wants to add a new type of contract to this Customer. This particular type of contract is handled by Client Application 2. The user clicks “Add bar contract”
  9. The consolidated view application has registered the URL for inserting new contracts like these for the customer. It redirects (or proxies) the user to (for example) http://b.server.name:3311/clientApp2/contracts/bar_contract/new?customer=1234
  10. Client Application 2 lets the user enter the data to create the new contract
  11. Client Application 2 updates the database for the consolidated application to include the new contract

In this scenario, the only thing the Consolidated View application knows about specific types of contract is where the user can be redirected in order to create or modify them. If a new application is added, a new row needs to by added to the contract_type table in the Consolidated View database. That is all. This means that despite the fact that the user is presented with a unified view of the data, the applications are very decoupled. The downsides of using this solution is that there is still some coupling, and this coupling is now more implicit. If any of the client applications move to a new URL, someone has to remember to update the consolidated view application. Even worse: If the client applications link back to the server application, we have to remember to update all client applications if the server application moves. Of course, the last problem can be solved (if we really want to) by having the consolidated view server application URL be part of a Reference Data domain. I hope this article has been concrete enough to show you, dear reader, how to solve problems elegantly using no application-level integration mechanisms. In my next post, I plan on examining how to get the various scenarios to scale.