Let’s say you are about to meet a prospect or an existing customer who have expressed interest in integrating their Salesforce.com environment with a legacy or third party system. While, the first step is to always evaluate the existence of connectors or adapters; at times it may occur that we are required to “develop” the custom integration (technically – using web services and call-outs).
I am pretty sure, being a technical or functional person, you must have come across this scenario. This write-up is an attempt to capture some basic set of checkpoints that can be used to extract, understand and design a successful integration application.
1> Objects & Fields Mappings:
Sounds quite simple, yet the most important step! Object and field mappings are a matrix of data type, source (data/value that needs to be pulled from source system) and target (object/field where the value needs to be pushed from target) information. This information allows one to thoroughly understand and communicate the data flow. There are several ways to capture this and you may also find different versions/types of table on web. Here is the one that I often stick to –
|<Source System Name>||<Target System Name>|
|Source Object||Source Field||Source Field Datatype||Target Object||Target Field||Target Field Datatype|
|<Object S1>||<Field Name>||integer(80)||<Object T1>||<Field Name>||text(80)|
|<Object S2>||<Field Name>||text(80)||<Object T2>||<Field Name>||text(80)|
Sometimes, in case of complex data models, maintaining relational information may seem a challenge. For such situations, my mantra is simple i.e. deal with one object at a time! This object may be a parent or a child or a junction. Whatever be the case, if we are capturing each source to target mapping, we should be able to render the information efficiently and might also come up with design improvement suggestions.
2> Integration Direction (Unidirectional, Bidirectional or Multidirectional)
The integration direction defines the data flow direction. Though object and field mappings give a fair understanding of integration direction, it is always good to double check on this as it might unveil use cases or expectations that might be missed in the requirements.
Multi-directional Integration (more than 2 systems are involved)
3> Triggering Events, Frequency & Data Volumes
This is the launch pad for our integration! Generally the syncing between 2 systems takes place either on demand or on scheduled basis. Capture the specifics around following points.
- Invoking event – whether it is on record insert/update/delete or needs to run at some expected frequency (daily, weekly, etc.)
- Volume of data – no. of records that needs to processed/updated at once (the higher, the heavier). It is crucial to understand bulk processing capabilities of the system.
- System limitations – API limitations, Call out limitations, etc.
The success of an integration project heavily depends on these considerations so be super careful in executing this step.
4> Data filters / Criteria
It is important to understand when the data is ready, either to be sent over to target system or pulled from source system. Defining appropriate filters for pull/push not only helps in ensuring data consistency but also prevents unnecessary processing.
Let’s take a simple example – Opportunity’s revenue amount needs to be synced with legacy accounting system when opportunity stage reaches ‘Closed/Won’ stage. In this case, if a user manually triggers the sync, there is no point in making a callout and posting the information to legacy system if Opportunity is not closed yet. Instead, user should be alerted regarding criteria mismatch. In the same example, let’s say we additionally need to sync the Opportunity Line Items where Product belongs to a specific Product family. In this case, it is essential to limit only required Opportunity Line Items.
Make a note of all such conditions and enforce necessary validations for better performance and integrity.
5> Error Logging
It may occur that source system was unable to process request due to an internal error, misconfiguration, firewall settings or mismatching data. It is a good practice to log the errors with reference record id, error message or any other relevant detail about the transaction. It not only helps to identify and locate a specific error record but also allows analyzing erroring trends and identifying system or application improvements.
6> Post Actions
This one is the icing on cake! Once the integration pull/push and updates are completed, do check if any actions (like email alerts, additional field updates, etc.) needs to be performed. This could be an optional step.
Hope this helps you in scoping and designing your next custom integration project!
Shailendra J. Singh