Salesforce Marketing Cloud Connector

To use the Salesforce Marketing Cloud connector, you need:

To use a Salesforce Marketing Cloud connector in your Mule application, be sure to include the namespace and schema location.

After you download and install the connector, use the following steps to make the Salesforce Marketing Cloud connector available to inside a Mule application for use and packaging.

To use the Salesforce Marketing Cloud connector in a Mule application project, create a new project.

To access the data in a Salesforce instance, authenticate using "Basic authentication".

All you need to do in order to use "Basic Authentication" is to provide your credentials in a global configuration element, then reference the global configuration in any Salesforce Marketing Cloud connector in your application. If you notice that you are getting connection timeouts or read timeouts, you can modify the Connection Timeout and Read Timeout from the General Category, to increase those values.

Some objects in Salesforce Marketing Cloud have complex fields belonging to a base class (for example, a Recurrence field) In this particular case, DataSense is only able to bring up fields specific to a base class, but you might want to use additional fields that belong to a subclass of that base class.

Please go to the Providing a Subclass as a Type to a Complex Field subsection, for an example detailing how to achieve this.

The Retrieve operation allows you to retrieve records in a SQL query-like fashion.

To better illustrate this issue, we will go through an example. The Subscriber object has a complex structure:

The API only allows us to query fields on the first level, like EmailAddress or SubscriberKey but not fields like Attributes.Name

When performing an operation on an Automation object (like Create or Delete), the returned result will also contain the structure of the Automation object you acted upon.

In order to bypass this issue, make all operations that directly use an Automation object asynchronous. If the operation is asynchronous, the immediate response of the operation will be something like "Operation Queued".

Please see the Asynchronous Operations subsection for further explanation on how to make operations asynchronous.

Let’s say we want to schedule an existing Automation to send emails to a list of subscribers once per minute.

In order to do this, we would input a Schedule Reference into the connector through a flow variable for example, to provide details about the schedule.

Details such as how much time should pass between emails sent should go into a field called Recurrence. The field Recurrence found in ScheduleDefinition, for example, is a complex field that has no structure:

To specify that we want to work with a MinutelyRecurrence, and not a Recurrence, we must manually add the fields belonging to the MinutelyRecurrence class, and add an extra field called concreteClassType of type String whose value is the name of the subclass.

Here is how the mapping for the ScheduleDefinition would look in the flowVars for our example:

Notice that the recurrence map has a field called minuteInterval that actually belongs to a subclass of Recurrence, called MinutelyRecurrence.

For the connector to know that it is dealing with a MinutelyRecurrence object, we must also add the extra concreteClassType field with MinutelyRecurrence as the value.

Most operations are synchronous by default, meaning that the connector waits for the result of the operation.

To specify that you want an operation to behave asynchronously, you must use the Options parameter from the operation. We show in an example how this behavior can be achieved for the Create operation. This can also be done in a similar fashion for the other operations.

In this example we create a list of Automation objects to provide in the payload. Because Automation objects present an issue where the result of any operation that directly works with this type of object throws an exception caused by the presence of an unknown field, we make the operation asynchronous; this allows us to bypass this issue.

The CreateOptions parameter is responsible with making the call asynchronous. In our example, the CreateOptions is provided in a flowVars.

This is how the mapping for CreateOptions looks in the flowVars. The field requestType determines the type of call (SYNCHRONOUS or ASYNCHRONOUS). The conversationID field assigns an unique identifier to the asynchronous call.

Asynchronous calls can be grouped together using the conversationID, callsInConversation and sequenceCode fields (for example, if we want to make 5 asynchronous calls to the server, but we want them to execute together and we want to specify in which order to execute, we put the same conversationID to all of them, we put to callsInConversation the value 5, meaning that our group will have 5 calls, and sequenceCode is the order of the call in the group).

For this example, because we have a single call, we pass a value of 1 to callsInConversation and sequenceCode.

You may check your code against the complete application’s XML representation, shown below.