Inaport 7.3 – Dramatically improving matching performance using local cache tables
With the rise of CRM systems such as Microsoft CRM 2011 which are accessed via web services, performance becomes more of an issue. Analysis of Inaport projects indicates that for a typical import into a web hosted CRM system, up to 99% of the time may be spent in the web service calls to the target CRM system.
An important objective, then, is to minimize the number of web services calls as far as possible. This post describes some techniques available in Inaport 7.3 that can dramatically reduce or eliminate the cost of matching on the target system, by removing the need to make any web services calls.
While these techniques have the biggest impact with web services based systems, they can also be very useful for on premise based systems such as SalesLogix.
It is a long and moderately technical post. A subsequent post will provide some examples of using these caching techniques. If you have any questions, it is likely that other readers do as well – feel free to ask for clarification in the comments, or to contact InaPlex direct.
The basic technique is caching the primary key of the target records in the source database. This can be done by one of:
- updating the source record with the primary key of the matched record in the target;
- using a cross reference table, that stores the primary keys of the source and target records, along with match information;
- building a match table that stores the primary key of the target, along with required match information.
Each of these techniques is useful in different scenarios.