In the last post we have seen that Mulesoft provides a bunch of connectors and transformers that could be used to design the flows. In this article lets try to look at some of the ways in which we could invoke Salesforce from Mulesoft, and vice - versa.
Inbound vs. Outbound Connector
Before we dwell into the details, it is important to understand that some of the connectors in Mulesoft behave differently when used as an Inbound Connector, and when used as an Outbound connector. This applies to the Salesforce connector as well. Generally when a connector is used at the start of the flow or in the source section of the flow, it acts as an Inbound connector and as Outbound connector otherwise.
Actions when used as an Outbound Connector
Actions when used as an Inbound Connector
- Subscribe to a topic
Imagine a situation where in we are required to poll salesforce at regular intervals for a set of records. In such cases, the use of a poller is very useful.
The poller in Mulesoft can be configured to run at a set frequency and the connectors within the poll scope would run accordingly.
Now, in the poll step, drag in a Salesforce connector. Since, this is enclosed in a poll step and not directly acting as an inbound connector, most of the salesforce actions are now available. For sake of simplicity lets consider the operation to be a query.
Open the salesforce connector, and write in the query, and add the necessary configuration details.
In this way, we can poll salesforce at regular intervals to get the records.
Note: Use of watermarks is a very useful concept under the poll step. More details on this can be found here
Publish - Subscribe Model
Salesforce offers the flexibility to use the Publish - Subscribe model by means of Push Topics.
In order to use this, drag a Salesforce connector onto the source section of a flow. Notice that the Salesforce connector is now changed to Salesforce (Streaming). This connector requires a topic name, so enter the details and the Mule flow would now be subscribing to that specific topic. Since this is a subscription model, no explicit polling is required, and the flow gets triggered in real time without much delay.
Listen on a local port
The above two approaches involve direct access of the salesforce instance either by means of polling or subscribing. In both the cases, there was no external invocation to the salesforce. So, the third way of invocation can be by means of a HTTP Listener configuration.
The way this works is, the HTTP service listens on a specific port on our mule server or our local machine. When a request is hit on this address, the Mulesoft flow kicks in, and the flow gets started.
So, we could probably host a service on the local host, read some parameters and send it in our request to salesforce. Following is a sample of the flow could look like.
As shown above, the flow is started whenever the HTTP service is hit with a GET request on the address specified in the HTTP connector configuration. In this case, since the service is hosted on the localhost, if we host the mule on a web server, then the server's ip can be used to reach the service.
There are many other possible invocations of the salesforce instance, but the above mentioned are the most commonly used scenarios.