Use the SalesforceRequest node to make synchronous requests to Salesforce.com, to create, retrieve, update, and delete Salesforce records. These functions are available for the predefined and custom Salesforce object types for a specified Salesforce system.
- Application Integration Suite
The SalesforceRequest node is available on Windows and Linux® x64 systems.
IBM® Integration Bus communicates with Salesforce by using LoopBack® connector technology from StrongLoop®. The LoopBack connector invokes Salesforce by using the Force.com REST API, which enables you to create, retrieve, update, and delete Salesforce records. For more information, see the Force.com REST API Developer Guide.
This topic contains the following sections:
You can use the SalesforceRequest node in a message flow to create, retrieve, update, and delete records in a Salesforce.com system.
Using the SalesforceRequest node in a message flow
For information about connecting to Salesforce.com, see Configuring a secure connection to Salesforce.com.
Terminals and properties
When you have put an instance of the SalesforceRequest node into a message flow, you can configure it; see Configuring a message flow node. The properties of the node are displayed in the Properties view. All mandatory properties for which you must enter a value (those without a default value) are marked with an asterisk.
The SalesforceRequest node terminals are described in the following table.
|In||The input terminal that accepts the request data object.|
|Out||The output terminal to which the response data object is sent if it represents successful completion of the request, and if further processing is required within this message flow.|
|Failure||If an error occurs in the SalesforceRequest node, the message is sent to the Failure terminal. Information about the error is propagated to the Failure terminal. Expiry of the Timeout property value is also propagated to the Failure terminal.|
The following tables describe the node properties. The columns headed M indicate whether the property is mandatory (marked with an asterisk on the panel if you must enter a value when no default is defined); the columns headed C indicate whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).
|Node name||No||No||The node type, SalesforceRequest||The name of the node.|
|Short description||No||No||A brief description of the node.|
|Long description||No||No||Text that describes the purpose of the node in the message flow.|
|Property||M||C||Default||Description||mqsiapplybaroverride command property|
|Salesforce URL||Yes||Yes||The URL of the external Salesforce system. You can override this property by setting the URL in the LocalEnvironment.Destination.Salesforce.Request subtree.||url|
|Operation||Yes||No||The default operation to use. This property
lists the operations that are available. You can override this property
by setting the operation name in the LocalEnvironment.Destination.Salesforce.Request
subtree. The available operations are:
|Salesforce object||Yes||No||The default Salesforce object name to use. This property lists the Salesforce objects that are available (for example, Account), or you can provide the name of a custom object. You can override this property by setting the object name in the LocalEnvironment.Destination.Salesforce.Request subtree.|
|Security identity||Yes||Yes||The security identity to look up in the integration node to get the OAuth authentication properties to be used. Use the mqsisetdbparms command to set the security identity on the integration node.||securityIdentity|
|Timeout (milliseconds)||No||Yes||120000||The time (in milliseconds) that the node waits for Salesforce to process the operation. You can override this property by setting timeoutMilliseconds in the LocalEnvironment.Destination.Salesforce.Request subtree.||timeoutMilliseconds|
|HTTP(S) proxy location||No||Yes||The proxy server to which requests are sent.
This value must be in the form hostname:port.
If the configured proxy server requires
authentication, the credentials must be set by using the mqsisetdbparms command with
the resource name
|Message domain||Yes||No||JSON||The domain that is used to parse the response message. By default, the message that is propagated is in the JSON domain. You cannot specify a different domain.|
|Message model||No||No||The name or location of the message model schema file in which the incoming message is defined. You cannot set this property.|
|Message||No||No||The name of the response message. The node detects the message type automatically; you cannot set this property.|
|Physical format||No||No||The name of the physical format of the response message. You cannot set this property.|
|Data Location||Yes||No||$Body||The location in the incoming message tree from
which data is retrieved to form the request that is sent from the SalesforceRequest node to the
The Data location property is applicable only in Create and Update operations.
|Output data location||No||No||$OutputRoot||The message tree location to which the SalesforceRequest node sends
See Combining a result message with an input message when fetching data from external systems.
|Copy local environment||No||No||Selected||This property controls how the local environment
is copied to the output message. If you select this check box, a new
copy of the local environment is created in the tree at each node
in the message flow, and it is populated with the contents of the
local environment from the preceding node. If a node changes the local
environment, the previous nodes in the flow do not see those changes
because they have their own copies. This behavior might be an issue
if you are using a FlowOrder node,
or if you use the propagate command on a Compute node.
If you clear the check box, each node does not generate its own copy of the local environment, but it uses the local environment that is passed to it by the previous node. If a node changes the local environment, those changes are seen by the upstream nodes.
|Events||No||No||None||Events that you have defined for the node are
displayed on this tab. By default, no monitoring events are defined
on any node in a message flow. Use Add, Edit,
and Delete to create, change or delete monitoring
events for the node; see Configuring monitoring event sources by using monitoring properties for details.
You can enable and disable events that are shown here by selecting or clearing the Enabled check box.