<invoke> Examples

You must identify the mashable or mashup and operation name that you want to invoke. In most cases, you should also identify an output variable to receive the results from the invocation.

Note:

You can fill in mashable or mashup and operation information automatically in the Mashup Editor. See Automatically Generating <invoke> Statements in Mashup Editor for more information.

In most cases, the results from the mashable or mashup are complex documents. For mashables or mashups that return simple data, it is a best practice to explicitly declare the variable for the result and the datatype. For example:

Specify input parameters for the mashable operation in the inputvariables attribute. If there are multiple input parameters, list the names of the <variable> or <inputparam> elements to provide this data in the expected order, separated by commas.

Important:

Do not use the $ prefix for parameter or variable names in this attribute.

Also, when you invoke another mashup, input parameters must be listed in the order in which they appear in the invoked mashup script.

If you omit parameters in inputvariables, the effect depends on the placement of the parameter:

Parameters that you omit at the end of the list are not sent. The receiving mashable information source or mashup may use a default value, if any, handle the omission or treat this as an error.

If you skip a parameter in the list in inputvariables, the parameter is sent as a null value. For mashups, this overwrites any default value for the parameter. Mashables may handle this or may treat this as an error.

For REST web services, WSDL web services or Syndicated feeds that require basic HTTP authentication or NTLM authentication, you can also send user credentials to automatically handle login for the mashable invocation. If you omit credentials in <invoke>, MashZone NextGen uses the default credentials, if any, that were provided when the mashable was published.

Note:

For mashables that use SSL and x.509 certificates for authentication, MashZone NextGen automatically handles authentication with the mashable based on SSL configuration and WSS policies, if relevant.

You must construct a header with the appropriate credentials and then identify it using the header attribute in <invoke>. Basic HTTP authentication looks something like this:

<constructor outputvariable="basicHttp">
<header>
<httpBasicAuth>
<username>someone@xyz.com</username>
<password>somepassword</password>
</httpBasicAuth>
</header>
</constructor>
<invoke service="someRESTService" operation="someOp" header="$basicHttp"
outputvariable="$result" />

For NTLM credentials, the structure of header that you use in <invoke> is slightly different:

<constructor outputvariable="ntlm">
<header>
<ntlmAuth>
<username>someone@xyz.com</username>
<password>somepassword</password>
<domain>somedomain</domain>
</ntlmAuth>
</header>
</constructor>
<invoke service="someRESTService" operation="someOp" header="$ntlm"
outputvariable="$result" />

Because <constructor> allows Dynamic Mashup Expressions, you can also set user credentials dynamically. This example passes in user credentials as input to the mashup:

<input name="thisUser" type="string"/>
<input name="thisPW" type="string"/>
...
<constructor outputvariable="basicHttp">
<header>
<httpBasicAuth>
<username>{ $thisUser }</username>
<password>{ $thisPW }</password>
</httpBasicAuth>
</header>
</constructor>
<invoke service="someRESTService" operation="someOp" header="$basicHttp"
outputvariable="$result" />

For WSDL web services that require headers, construct the header in <constructor> and use the header attribute in <invoke>.

You can also optionally filter the result of the mashable operation using the filterexpr attribute and an XPath 2.0 expression. This is a shortcut to specifying a separate <filter> statement. For example:

When the results from the mashable information source contain an array of complex objects, the results contain a list of XML nodes for each complex object in the array. This list is enclosed within a parent node with a name in the form object-name_Array.

For a list of Customer objects, for example, the result would look something like this:

...
<Customer_Array>
<Customer>

</Customer>
<Customer>

</Customer>
...
</Customer_Array>
...

Note:

In previous releases, results for arrays of complex objects used a different naming convention for the parent node of the array:

You must update XPath expressions in mashup scripts from earlier releases to use the new name, object-name_Array, instead.

See Mashup Samples for a complete list of mashup samples and where to find them.