Issuu on Google+

Enterprise Integration using Related Key Repository & Coordinator Pattern

Prithvi Padmanabhan Architect/Development Manager January 20, 2014


Abstract Enterprises have a habit of crowding themselves with lot of applications that work in unison to pass data withers synchronously or asynchronously. In this process they either copy the IDs/Keys across each of the applications or completely store the data. Enterprise Related Key Repository & Coordinator Pattern tries to address this problem with unique approach of using relations in a centralized location solving some of the maintenance hassles that has plagued enterprises for years.

Enterprise Integration using Related Key Repository & Coordinator Pattern | Prithvi Padmanabhan

Page 1 of 7


Introduction In not too distant past, major challenges facing their IT teams were issues regarding message passing between systems and distributed architecture. With modern software technologies the message passing has become reliable to a certain extent with the advent of ESBs and other specifications. However one problem always tends to another, now enterprises completely different problem as to how to map keys between different systems. This white paper introduces a concept as to how this can be solved allowing each system to work with a centralized repository by using Related Key Repository & Coordinator Pattern

Problem Let’s say as an enterprise I have 3 or 4 applications which communicate between each other and each one of them store unique section of data. As an example let’s take a sales application (Application A) which keeps customer information and product information, the Fulfillment system (Application B) keeps the product fulfillment information and the Billing system (Application C) which keeps the billing information. All these applications need to communicate some piece of information to have the standard customer fulfillment and billing. The general practice of doing this is by passing information between systems or passing the external id (id of one system) and associate to the id of another system. This is maintenance nightmare to keep different ids. Not only that but also each system has to align with other systems model. More importantly it is reporting hassle to cumulate all the keys and then map it to the sales system. This is just one piece of the problem. If the applications communicate asynchronously there is no easy way to tell where the transaction actually Enterprise Integration using Related Key Repository & Coordinator Pattern | Prithvi Padmanabhan

Page 2 of 7


failed without each of the teams looking in their apps to check for failures. Also we just considered only 3 applications here wherein the model was similar. Consider cases the model is completely different but they are inter linked and related.

Solution 1 – Enterprise Key Id In order to solve the above problem most enterprises generate what they call as enterprise key and pass it along keeping a repository which is centralized. However the biggest problem still is how one debugs where actually the transaction failed. Not only that enterprise ids need to be created for each and every entity and that needs to be stored but each system needs to be aware of the model. This works however think about the over-head and cost just to solve part of the problem as we still did not solve the problem of easily debugging where something failed

Enterprise Integration using Related Key Repository & Coordinator Pattern | Prithvi Padmanabhan

Page 3 of 7


Solution 2 – Enterprise Related Key Repository & Coordinator Pattern Enterprise Related Key Repository & Coordinator Pattern tries to solve some of the problems that the enterprise faces with keys with unique way of using relations of real world into software paradigm. Consider Facebook for instance the most popular social app keeps your friends and then friends of friends thereby building a tree. Let’s for now we take that concept of social element and apply to the problem above. The problem above in its core is Keys related to other Keys. If we add a centralized repository and each app tells the centralized repository that the source key and how it is related then it does not need to

Enterprise Integration using Related Key Repository & Coordinator Pattern | Prithvi Padmanabhan

Page 4 of 7


maintain the keys. In other words the Related Key Repository just keeps the source application, the key type, the value and the related keys with same attributes.

Since this is now a graph we can quickly traverse the graph and find the related key. IN other words if want to look-up from the billing system the sales customer id we can easily do so by graph lookup.

Enterprise Integration using Related Key Repository & Coordinator Pattern | Prithvi Padmanabhan

Page 5 of 7


But this only solves part of the issue. We still need a way for easily identify where the transaction failed. If we add transaction coordinator as part of key repository and allow tell how the transaction needs to flow with simple rules then we can easily say where it failed. For example: Let’s say Sales Application started a transaction and it reached fulfillment. If we have the Related Key Repository we can easily identify that fulfillment system posted the target key however the billing system did not. This means that the message passing failed between fulfillment system and billing system. As indicated in the figure below the transaction started with sales application however if the billing application did not update the repository the end of transaction did not happen

Lets enhance it even further and think about reporting as well. Since now key repository keeps a graph of related keys along with the source key and target key with its relation, we Enterprise Integration using Related Key Repository & Coordinator Pattern | Prithvi Padmanabhan

Page 6 of 7


actually are getting rid of any crowding of passing of keys. Not only it is centralized the datawearhouse team can easily lookup data. This can be achieved if as part of configuration for each key we can keep a way to lookup the source data by either REST or SOAP services. Also if we add new systems then the only change is to have the system call the key repository and coordinator without worrying about storing the key.

Enterprise Integration using Related Key Repository & Coordinator Pattern | Prithvi Padmanabhan

Page 7 of 7


Enterprise integration using key repository & coordinator pattern