Enterprise Application Integration: Part 2

Warning! This post and related code is something I began a while ago but did not get round to completing. Since starting this I have read up on EAI techniques and also on SOA. I now understand that while the examples here may be suitable for integrating two or three small applications, they would not scale for anything other than a very small business. However, as one of the primary functions of this blog is to record my learning process, I have decided to include it.

Click here to download the code from Codeplex. Please make sure you click on 'Code for Part 2'. This example cannot be run using SQL Server Express, it must be run on SQL Server. Please run the script in the SQL Scripts solution folder to create the required databases (even if you have done this for the last part).

Firstly, I have removed the integration layer and incorporated it into the Application layer to reduce complexity.

Extending Properties of an Entity

A new business requirement has been specified: contacts must have a payment authorisation level (low, medium and high) and this must be displayed in the drop down list in the create payment page.

Clearly, the Contact entity needs a new field: PaymentAuthorizationLevel, but should this go in the Client Data System? This information is specific to the Accounts System, and if every system stored its own information relating to a contact in the Client Data System, the Client Data System would become soon bloated, and the constant change would be hard to manage. This solution is unscalable.

So the solution to this I have implemented in this version is have an entity in the Accounts System also called 'Contact' which holds all the fields from the Client Data System and also the new PaymentAuthorizationLevel field. There is a table in the database for the Accounts System called 'Contact', which contains only an Id and the PaymentAuthorizationLevel field. The Id is not auto-incrementing: it is the primary key but it is also a foreign key to the Id in the Client Data System's Contact table.

There are now two mappings for Contact in the Data Layer: one with an entity name of 'ReadContact': This maps to a view which is a join of both Contact tables, and therefore populates all fields in the Accounts System. This mapping is read-only:

The other mapping is 'WriteContact', and is for writing. This saves the Contact object to the Accounts System database, but only the Id and PaymentAuthorizationLevel fields. In order to save a new Contact, the ContactService of the Account System must call the CreateContact method of the ContactService in the ClientDataSystem, return the Id, build a Contact entity in the Accounts System with the returned ID and PaymentAuthorizationLevel and then save that:

Edit: I've later noticed that the Contact Mapping (Read) in the above diagram should say Contact Mapping (Write)!

As mentioned in my disclaimer, this is not a perfect solution (The CreateContact method of the AccountService is very bloated), and I have already learnt new methods, but I thought I would document this as part of my learning process, and it may be useful for some smaller integration problems.