Skip to content

Dilen13/template-sfdc2sfdc-opportunity-bidirectional-sync

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

69 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Anypoint Template: Salesforce and Salesforce Opportunity Bidirectional Sync

License Agreement

Note that using this template is subject to the conditions of this License Agreement. Please review the terms of the license before downloading and using this template. In short, you are allowed to use the template for free with Mule ESB Enterprise Edition, CloudHub, or as a trial in Anypoint Studio.

Use Case

As a Salesforce admin, I want to have my opportunities synchronized between two different Salesforce organizations

Template overview

Let's say we want to keep Salesforce instance A synchronized with Salesforce instance B. Then, the integration behavior can be summarized just with the following steps:

  1. Ask Salesforce A:

Which changes have there been since the last time I got in touch with you?

  1. For each of the updates fetched in the previous step (1.), ask Salesforce B:

Does the update received from A should be applied?

  1. If Salesforce answer for the previous question (2.) is Yes, then upsert (create or update depending each particular case) B with the belonging change

  2. Repeat previous steps (1. to 3.) the other way around (using B as source instance and A as the target one)

Repeat ad infinitum:

  1. Ask Salesforce A:

Which changes have there been since the question I've made in the step 1.?

And so on...

The question for recent changes since a certain moment in nothing but a poller with a watermark defined.

As implemented, this Anypoint Template also leverages Outbound messaging The integration could be also triggered by HTTP inbound connector defined in the flow that is going to trigger the application and executing the batch job with received message from Salesforce source instance. Outbound messaging in Salesforce allows you to specify that changes to fields within Salesforce can cause messages with field values to be sent to designated external servers. Outbound messaging is part of the workflow rule functionality in Salesforce. Workflow rules watch for specific kinds of field changes and trigger automatic Salesforce actions in this case sending opportunities as an outbound message to Mule HTTP inbound connector, which will then further process this message and create Opportunity in target Salesforce organization.

Considerations

To make this Anypoint Template run, there are certain preconditions that must be considered. All of them deal with the preparations in both, that must be made in order for all to run smoothly. Failling to do so could lead to unexpected behavior of the template.

Salesforce Considerations

There may be a few things that you need to know regarding Salesforce, in order for this template to work.

In order to have this template working as expected, you should be aware of your own Salesforce field configuration.

###FAQ

As source of data

If the user configured in the template for the source system does not have at least read only permissions for the fields that are fetched, then a InvalidFieldFault API fault will show up.

java.lang.RuntimeException: [InvalidFieldFault [ApiQueryFault [ApiFault  exceptionCode='INVALID_FIELD'
exceptionMessage='
Account.Phone, Account.Rating, Account.RecordTypeId, Account.ShippingCity
^
ERROR at Row:1:Column:486
No such column 'RecordTypeId' on entity 'Account'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.'
]
row='1'
column='486'
]
]

As destination of data

There are no particular considerations for this Anypoint Template regarding Salesforce as data destination.

Run it!

Simple steps to get Salesforce and Salesforce Opportunity Bidirectional Sync running.

Running on premise

In this section we detail the way you should run your Anypoint Template on your computer.

Where to Download Mule Studio and Mule ESB

First thing to know if you are a newcomer to Mule is where to get the tools.

  • You can download Mule Studio from this Location
  • You can download Mule ESB from this Location

Importing an Anypoint Template into Studio

Mule Studio offers several ways to import a project into the workspace, for instance:

  • Anypoint Studio generated Deployable Archive (.zip)
  • Anypoint Studio Project from External Location
  • Maven-based Mule Project from pom.xml
  • Mule ESB Configuration XML from External Location

You can find a detailed description on how to do so in this Documentation Page.

Running on Studio

Once you have imported you Anypoint Template into Anypoint Studio you need to follow these steps to run it:

  • Locate the properties file mule.dev.properties, in src/main/resources
  • Complete all the properties required as per the examples in the section Properties to be configured
  • Once that is done, right click on you Anypoint Template project folder
  • Hover you mouse over "Run as"
  • Click on "Mule Application"

Running on Mule ESB stand alone

Complete all properties in one of the property files, for example in [mule.prod.properties] (../master/src/main/resources/mule.prod.properties) and run your app with the corresponding environment variable to use it. To follow the example, this will be mule.env=prod.

Running on CloudHub

While creating your application on CloudHub (Or you can do it later as a next step), you need to go to Deployment > Advanced to set all environment variables detailed in Properties to be configured as well as the mule.env. Once your app is all set and started, you will need to define Salesforce outbound messaging and a simple workflow rule. This article will show you how to accomplish this The most important setting here is the Endpoint URL which needs to point to your application running on Cloudbhub, eg. http://yourapp.cloudhub.io:80/?source=value. Value for source parameter could be A for source outbound messaging for organization A or B for organization B. Additionaly, try to add just few fields to the Fields to Send to keep it simple for begin. Once this all is done every time when you will make a change on Opportunity in source Salesforce org. This Opportunity will be sent as a SOAP message to the Http endpoint of running application in Cloudhub.

Deploying your Anypoint Template on CloudHub

Mule Studio provides you with really easy way to deploy your Template directly to CloudHub, for the specific steps to do so please check this link

Properties to be configured (With examples)

In order to use this Mule Anypoint Template you need to configure properties (Credentials, configurations, etc.) either in properties file or in CloudHub as Environment Variables. Detail list with examples:

Application configuration

  • http.port 9090

  • poll.frequencyMillis 10000
    This are the miliseconds (also different time units can be used) that will run between two different checks for updates in Salesforce

  • watermark.default.expression 2015-08-25T11:00:00.000Z
    This property is an important one, as it configures what should be the start point of the synchronization.The date format accepted in SFDC Query Language is either YYYY-MM-DDThh:mm:ss+hh:mm or you can use Constants. More information about Dates in SFDC

Trigger policy(push, poll)

  • trigger.policy poll This property defines, which policy should be used for synchronization. When the push policy is selected, the HTTP inbound connector is used for Salesforce's outbound messaging and polling mechanism is ignored.

Account sync policy(empty value, syncAccount)

  • account.sync.policy `` If the account.sync.policy property has no value assigned, the contact will be just moved over without a parent account. If the syncAccount policy is syncAccount then the Opportunity will be created with an account with the same name as in the source instance.

SalesForce Connector configuration for company A

  • sfdc.a.username jorge.drexler@mail.com
  • sfdc.a.password Noctiluca123
  • sfdc.a.securityToken avsfwCUl7apQs56Xq2AKi3X
  • sfdc.a.url https://login.salesforce.com/services/Soap/u/32.0
  • sfdc.a.integration.user.id A0ed000BO9T

SalesForce Connector configuration for company B

  • sfdc.b.username mariano.cozzi@mail.com
  • sfdc.b.password LaRanitaDeLaBicicleta456
  • sfdc.b.securityToken ces56arl7apQs56XTddf34X
  • sfdc.b.url https://login.salesforce.com/services/Soap/u/32.0
  • sfdc.b.integration.user.id A0ed000BO9T

API Calls

Salesforce imposes limits on the number of API Calls that can be made. Therefore calculating this amount may be an important factor to consider. The Anypoint Template calls to the API can be calculated using the formula:

1 + X + X / 200

Being X the number of Opportunities to be synchronized on each run.

The division by 200 is because, by default, Opportunities are gathered in groups of 200 for each Upsert API Call in the commit step. Also consider that this calls are executed repeatedly every polling cycle.

For instance if 10 records are fetched from origin instance, then 12 api calls will be made (1 + 10 + 1).

When the outbound messaging is enabled in Salesforce and template trigger policy is push, specify Saleforce source organization eg. http://yourapp.cloudhub.io:80/?source=A as URL query parameter Also consider that all required fields of Opportunity in Salesforce should be added for the outbound messaging.

Customize It!

This brief guide intends to give a high level idea of how this Anypoint Template is built and how you can change it according to your needs. As mule applications are based on XML files, this page will be organized by describing all the XML that conform the Anypoint Template. Of course more files will be found such as Test Classes and Mule Application Files, but to keep it simple we will focus on the XMLs.

Here is a list of the main XML files you'll find in this application:

config.xml

Configuration for Connectors and Properties Place Holders are set in this file. Even you can change the configuration here, all parameters that can be modified here are in properties file, and this is the recommended place to do it so. Of course if you want to do core changes to the logic you will probably need to modify this file.

In the visual editor they can be found on the Global Element tab.

businessLogic.xml

This file holds the functional aspect of the template (points 2. to 4. described in the template overview). Its main component is a [Batch job][8], and it includes steps for both executing the synchronization from Salesforce instance A to Salesforce instance B, and the other way around.

endpoints.xml

This file should contain every inbound and outbound endpoint of your integration app. It is intented to contain the application API. In this particular template, this file contains a couple of poll inbound endpoints that query salesforce for updates using watermark as mentioned before.

errorHandling.xml

This is the right place to handle how your integration will react depending on the different exceptions. This file holds a Choice Exception Strategy that is referenced by the main flow in the business logic.

About

Anypoint Template: Salesforce to Salesforce Opportunity Bidirectional Sync

Resources

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Java 100.0%