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

  1. In the Checklist, select Configure.

    The Specify Query window opens.

  2. Create an SOSL query in the Specify Query window.
  3. Optional: You can specify dynamic parameters in the search clause of the SOSL statement. You can then map these parameters dynamically as the input parameters for the activity, which allows the activity to dynamically control the query that is based on the input to the orchestration. Use a ($) dollar sign to denote a parameter and follow it with the parameter name.
  4. Click the Validate icon , to validate the query.
    If the query is invalid, the Validation Feedback icon displays in the lower left corner of the Specify Query window. For invalid queries:
    1. Click the Validation Feedback icon in the lower left corner of the Specify Query window for a list of validation errors.
    2. Use the Refresh icon To refresh metadata and revalidate the SOSL statement.
  5. In the Checklist, select Query to configure specific query options.

    The Query Options pane opens.

  6. Select Include deleted items in query (execute a queryAll operation), to query for deleted records in addition to existing records. If you do not select this option, the Integration Appliance only queries existing records.
  7. Specify a Query batch size between 200-2000 queries to help tune the performance of the Integration Appliance.

    The option determines the batch size to use in the QueryOptions SOAP header for all query calls and does not affect the number of results that are returned by the activity. By default, this option is set to 500 queries.

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 that is based on 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.

SOSL Syntax Rules for Cast Iron
  • 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 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 run time.
    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 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 quotation marks, then the parameter's value is enclosed in single quotation marks during substitution and its contents are escaped automatically.

    For SOQL, the (\) backslash and (‘) single quotation mark is 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 side of the expression. The parameter is not nillable and has minOccurs=1, maxOccurs=unbounded on the element.

    The sequence is expanded at run time 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.




Feedback | Notices


Timestamp icon Last updated: Wednesday, 15 June 2016


http://pic.dhe.ibm.com/infocenter/wci/v7r0m0/topic/com.ibm.wci.doc/SerMax_Configuring_the_Query_Objects_Activity.html