I’d like to announce and introduce you to our second set of Anypoint Templates – Salesforce to Database. This set leverages the newly improved Database connector which allows you to connect with almost any JDBC relational database, consistently using the same interface for every case. Our first set of templates, Salesforce Org to Org integration, and is a good base for any “Salesforce to X”, or, “X to Salesforce” integrations.
If you are new to our templates, they are essentially Anypoint Studio projects (a.k.a. Mule Applications) that were built with the intention of being configured, customized, extended and reused. They’re built on top of five base data integration patterns:
|
|
|
|
|
Business Cases for Salesforce and Database Integration
Below are some of the key use cases that we built this set of templates around. Note that each template can serve as a good base even if you are integrating more than just Salesforce and Databases.
Use Case 1
I want to move from a custom or legacy CRM system to Salesforce.
Many organizations have custom systems that contain some aspect of their customer information. When introducing a new CRM system, businesses need to fill the new CRM with data from existing systems. This information will help make the transition to the new system smoother by giving users a single system to use. The integration patterns most useful for this use case are the migration pattern – which is used to bulk move the data from one system to the other – and the aggregation pattern – which can be used to ensure that the migration was successful or to see what the remaining delta is. In the case that your legacy or custom system has an API that can be used for the migration, I would recommend that you use those, especially if the data model is complex. In that case, you can still leverage the Database templates but would need to replace the database connector with a protocol connector like REST or SOAP.
Use Case 2
I want to synchronize data from Salesforce to a custom system in real time.
In some situations, you may want to keep the custom in-house tool operational, since it provides capabilities that are not covered by Salesforce, even if you want Salesforce to be the master record for some of the data that the tool uses. For example, you may want to use Salesforce to manage and own the contact data, but you want to see the contacts inside your custom tool. For this you can use the broadcast pattern to one way synchronize the data from Salesforce to the database. You can also use the bi-directional sync pattern to make it so that data flows both ways.
Use Case 3
I want to synchronize data from a custom/legacy system to Salesforce in real time.
Similar to the use case above, there may be custom objects or standard objects which you want to own and manage in the legacy/custom system but you want them to be represented inside Salesforce. For this, you can again use the broadcast pattern. However, the data flow direction will be from the database to Salesforce. Similarly, if you need both systems to be able to make changes and have it reflected in the other system, you can use the bi-directional sync pattern to achieve the unioning of the data.
Use Case 4
I want my cloud applications to have real-time integration with Salesforce.
Very similar to the use cases above, you may have using platforms like Heroku, Engine Yard, or Force.com to build out applications which you want to integrate with Salesforce. You can use the Salesforce to Database templates to help you achieve this directly or you can modify them by simply replacing the DB connector for a protocol connector to work against the API layer of the application that you built. This is very valuable if you build applications that are custom but are hosted in the cloud. Here again, the migration pattern can help you populate the DB of your new application, broadcast can help push data from one to the other, bi-directional sync in both directions, and aggregation for building reports or for creating an API on top of the two systems.
Use Case 5
I want to backup or extract data from my Salesforce instance.
In some cases, you need to extract large amounts of data from Salesforce for data warehousing or creating backups required by company policy. Regardless of the reason, our templates provide a great starting point for solving this use case. If you want to create a new snapshot, like a new table which is meant to serve as “the data at this point in time”, then I would recommend that you use a scheduled migration. Here you can use either Mule to poll every so often or you can have an external scheduler trigger the batch migration. In this case you will always process all the records as defined by your query. Another approach is to use the broadcast pattern, which leverages the batch module, meaning it can handle many records at once very effectively to publish all the updates since the last run. This is effectively saying, “I want this backup or snapshot to always be the latest snapshot”. This means you don’t have any history, but rather, you have just the current state minus the updates since the last run. Depending on your needs you can use the two patterns to get what you need.
Use Case 6
I want to generate reports using data from Salesforce and data from a Database.
Many times there is a need to generate reports using data that resides in multiple systems. This can be due to system specialization where different systems do different things and have different flavors of the data. Usually, the solution is to pull data from both systems into a third system, from where you can generate reports. Although this level of investment is probably a must for many advanced reporting needs, we wanted to provide an alternative where you can leave the data where it lives and dynamically generate reports across multiple systems to avoid the need to provision additional infrastructure for reporting. Or at least, you can leverage this solution to populate the reporting system with control rather than multiple point to point connections to it. The aggregation pattern was created to demonstrate how to pull data from multiple sources, join, format and use the data with the Anypoint Platform. sOut of the box, the templates that are based on the aggregation pattern pull all the objects from two sources, merge the data based on a shared field in each system, sort it to show all the objects in A, B, then in both, and to email this as a CSV file to a configured email account. You can easily modify them to support additional/different systems, different fields, different formating. Since they are exposed as an endpoint, you can use this template to power your dashboards, to pull data into your analytics tools or systems, or to generate files and store them where you store reports.
Use Case 7
I want to create an API that is a mashup of Salesforce and a database.
As need for new public and private APIs increases, and as APIs become more specialized, you may find yourself with a need to create new APIs on top of existing systems. In some cases, you have a need to create APIs that span multiple systems because some of the data you want to include in the response is part from one system and part from another system. This again, reduces the need for you to store duplicate data in multiple systems. The aggregation pattern, can be easily modified to return JSON, XML or other formats so that the main business logic of the template handles the retrieving, processing, and formatting of the content before it’s converted to the format that the API returns.
All of the templates that were built for these use cases can be found on our Salesforce Templates page. Note that they are organized by pattern and that they on the same page as our Salesforce Org to Org templates.
Thanks for reading! Feel free to share any feedback you might have in the comments below!
