High Performance MDM with AppFabric Cache, BizTalk, and Dynamics AX

- By David Nolting


The Context

Recently, ReachSOA architects were employed to help model a referential architecture for a renowned, international sports federation that managed both affiliates and public customers for public sporting events. The combined affiliate and public customer base ranged in the millions. At the time we were called in, they were at the tail end of a revamp of the CRM and ERP applications. As with most organizations, the affiliation relied on several disparate applications to manage affiliate membership, online ticket sales, and front office invoicing and back office order fulfillment. Microsoft Dynamics 2009 was chosen as the CRM product and would eventual morph into a full blown ERP solution. The ERP would become the MDM "source of truth" referential data source for customers (CDI), and products (PIM), as well as a historic base for product sales from the online and front office applications.

The solution was a classic BizTalk / Dynamics AX data synchronization model using BizTalk and the AX adapter:

 

The SLA Challenge
The integration between the affiliate database, BizTalk, and Dynamics AX proved to be very reliable. However, the integration time in AX was costly: database staging and AX business integration rules required to validate and integrate customers took time. BizTalk would deliver customer data to the AIF layer where it would be subjected to a lengthy staging process. Customers created from FrontOffice and Online Sales applications need to be made available for product fulfillment within minutes. Solicitation of the customer master record could occur from potentially thousands of connected users ( an SLA of 15 000 simultaneous connections ) was established.



At first, the architects looked at exposing Dynamics AX web services for consumption from the Front Office and Online applications. However, many technical problems such as performance, AX Business Connector Licenses, and "real time" reliability of the MDM database were put into question.



ReachSOA Analysis
We suggested a POC limited to 5 days to define and test an architecture using AppFabric Caching of the MDM. The cache would expose Pre-MDM services that would allow for recovery of master customer and product data and the ability to create the essential MDM Customer and place it into the cache so that it is available for consumption from the product fulfillment process within the state SLA of minutes ( in fact, it would be instantaneous with the Cache ).

To cut to the chase, we modeled the following technical architecture which combines synchronous and asynchronous flows using AppFabric and BizTalk:

 

 
We identified a series of Synchronous and Asynchronous flows. AppFabric Cache would be used for Synchronous Customer creation: a web service would allow for the creation of a customer from a subscribing app. The customer is updated to the cache and pushed to BizTalk for an asynchronous update to the MDM system. Ideally, MDM business rules would be called by AppFabric to pre-validate the Customer Information before it was updated to the cache. Business Rules integration with MDM was road mapped for a production version.

Rebooting the cache meant reloading the cache from the AX database. Fortunately, a cache reboot executed in about 30 minutes for millions of customers on a very modest VM platform.

We structured the cache so that it remained online at all times and a reboot merely updated entries in the cache rather than dumping and rebuilding it from scratch.



BizTalk Integration
We were able to update the cache from BizTalk Transactions that came from the Affiliate database. This meant that Affiliate information would be published to the MDM Cache well before it was staged into the MDM database meeting SLA requirements. BizTalk called a .Net Assembly that we built to wrap the AppFabric Cache API. Below is the component architecture of the Cache solution:

 

  Once the cache api was wrapped in our .Net Service Facade,  it was easy to hook up BizTalk and the cache :

 

 
WF Integration
We promoted use of WF ( Workflow Foundation ) to model the Creation/Update Process. This Work flow manages a transaction between the cache and the asynchronous integration tables that BizTalk would use to pickup and pass modifications to AX. If an update failed at the cache level or the SQL level, the transaction is rolled back and a fault is returned to the consuming app.

Functional Testing
The functional results of our POC were clearly positive. We managed to demonstrate flexible and rapid queries against the AX referential store thanks to AppFabric cache. The POC also demonstrated strategic possibilities such as full blown search and creation of SOA business domains for the affiliation.



Performance Testing
Performance testing was limited to Visual Studio Load tests to hammer the cache platform. Using this approach, we expressed the 15000 user connection SLA in terms of number of transactions we could handle per second; an SLA commonly used in EAI/ESB performance projects. This seemed to fit because the cache would sit well behind the online website and the transaction that involved querying the customer data would be less than 1 % of the entire online experience. Getting to a figure of number of transactions per second would help us project the number of servers required for a full blown implementation. Our cache was distributed across 3 machines as pictured below:

 
We used 3 virtual machines ( VMWare ESX ) to distribute the cache across multiple machines. Our initial goal was to show the High Availability/Fail Over capabilities of the cache; however, we did not have Windows 2008 R2 Enterprise installed on these machines and it was beyond the scope of the POC to upgrade from Standard to Enterprise.

We achieved anywhere from 85 to 95 transactions per second which seemed to largely satisfy the review committee given that we were not working in an optimal environment but had merely grabbed a few available machines.

We performed tests such as the following:


 

• Test 20 minute duration
• 104 819 tests completed
• 87,3 tests / sec
• 210 threads (limitation VS Load Test / CPU)
• 0.35 Avg Test Time

A few Technical Gotchas
As our Cache needs to theoretically remain available at all times, we configured High-Availability for the Cache.  One important characteristic for our caching model was to eliminate eviction.  Regardless of hit ratios, we needed all data to stay in the cache.   We stumbled upon this during the POC.    In addition, we will need to activate notifications in the event the cache drops entries due to eviction.  So, some time needs to be spent to understand and configure precisely the cache configuration.  Perhaps in another post, will drill down to some of the technical issues.   This post is more high-level and shows the business value of the technical architecture. 

Conclusions/Opportunities

The POC not only met but surpassed expectations. The POC restitution helped underline future potential for the solution. Here are the key take away points from the POC:

Practical Points

• Inexpensive Solution
• Rapid Development
• High Performance

 
Opportunities

• Potential for Full Blown Search
• First step towards MDM + SOA Enterprise Architecture
• Opportunity to Provide Service Inventory for Affiliate databases ( without creating another Silo )
• Best Practices and Governance in SOA
• Cloud ( public or private ) elasticity