Java Reference
In-Depth Information
▪
name
simply gives an identifier to this invocation element. This is key to keeping track of
what exactly is happening when. You may want to adopt a standard naming convention
for different constructs within your organization.
▪
partnerLink
is required, and indicates which partner link construct to use in identifying
the process to be invoked.
▪
portType
indicates the port type on the partner to use. Note that while this is typically
explicitly named within the
<invoke>
activity, it is optional here. That's because the port
type can be derived from the combination of the partner link and its partner role. It is re-
peated for clarity at design time, which is a good thing. The downside is that in the event
that the port type changes, the code will become outdated and need to be changed.
▪
operation
is required, and specifies the operation to invoke on the service.
▪
inputVariable
points to a variable containing the message or message part data that is
used as a parameter to the service. This is the data going into the service during invoca-
tion.
▪
outputVariable
indicates the variable that will hold the data as returned by the service.
Defining this indicates that your invocation is request/response. One-way operations can-
not include this attribute.
NOTE
You can leave out the
outputVariable
if the service you're invoking is one-way. In such a case,
processing will just continue normally without waiting for the partner.
The following list contains all of the optional child elements you can use within an invoke:
▪
<correlations>
▪
<catch>
▪
<catchAll>
▪
<compensationHandler>
▪
<toParts>
▪
<fromParts>
We'll examine all of these elsewhere in this topic except for
<toParts>
and
<fromParts>
constructs. According to the spec,
<toParts>
is “used as an alternative to explicitly creating
multi-part WSDL messages from the contents of WS-BPEL variables” [10.3.1], and
