Configuring the Query Objects activity
You must create a SForce Object Search Language (SOSL) query to configure the Search Objects activity. The following sections discuss the steps to configure the Search Objects activity, create an SOSL query, and provide SOSL syntax rules for IBM® Cast Iron®.
Procedure
Creating SOSL Queries
When creating a SOQL query, you can use dynamic parameters in the WHERE clause of the SOQL statement. Studio can then dynamically map these parameters as the input parameters for the activity. This allows for dynamic control of the query based upon input to the orchestration.
About this task
The SForce Object Query Language does not define a syntax for parameterized queries; however, Cast Iron does enforce some proprietary SOQL syntax rules. You can use parameters in either simple expressions or set expressions.
- Use a ($) dollar sign to denote a parameter. After the ($) dollar
sign, specify a string of alphanumeric characters. The first character
must be a letter [a-zA-Z], optionally followed by one or more letters
[a-zA-Z], digits [0-9], or ( _ ) underscores. Note: Parameter names are case-sensitive; therefore, the parameters $a and $A are considered to be different parameters.The following table contains examples of valid and invalid parameter declarations:
Parameter Valid or Invalid $AnAccount valid $a123_456 valid $123a invalid $_id invalid - You must declare parameters on the right-hand side of an expression in a WHERE clause.
- Parameters can appear more than once in a given SOQL statement.
However, even though the parameter appears more than once in the SOQL
statement, it only appears once in the input parameter map. The activity
substitutes the same value for all locations where the parameter is
used at runtime.Note: When you use the same parameter name and there is a type mismatch, an error occurs. For example, the following SOQL generates an error because $param is used as both a string and date type:
SELECT Name from Account where Name like $param and createdDate > $param
- The type of the field in which a parameter is being compared determines
the type of the parameter and whether the parameter is being used
in a simple expression, a set expression, or part of a set expression.
Type of Expression Description Simple Expressions For example: Select ID from Account where Name = $NameParam The SoapType of the field on the left-hand side of the expression determines the parameter type. If the field type is nillable and the operator is ( = ) or ( != ), then the parameter is nillable. Setting xsi:nil=true on the parameter sets the parameter value to null when it is substituted. If the parameter's type requires it to be enclosed in (‘) single quotes, then the parameter's value is enclosed in single quotes during substitution and its contents are escaped automatically.
For SOQL, the (\) backslash and (‘) single-quote will be escaped.
Set Expressions For example: Select ID From Account where ID in $idList The parameter's type is a repeating sequence of the SoapType of the field on the left-hand side of the expression. The parameter is not nillable and has minOccurs=1, maxOccurs=unbounded on the element.
The sequence is expanded at runtime to be a proper set value, for example:
Select Id From Account where Id in (‘value1',‘value2')
Part of a Set Expression Parameters inside a set list are treated like a simple expression parameter type, for example: SELECT Name from Account where BillingState IN (‘California', $state2) In this example, the $state2 parameter type is the SoapType of the Account BillingState field and is not a repeating element. The parameter is not nillable.