Ok, if you add an Integration Activity in Designer into a workflow, and
once you select a WSDL file, and a call within it, the IA sets up a
bunch of stuff by default.

It looks like each version of Designer does it a smidgen different.

For example, in D4.01 AU2, you get a choice of two approaches. The new
way and old way. Since I am working with an RBPM 3.7 system, I chose
old way to be safe.

But AU1 (or no AU, not sure where it changed) to AU2 it changed as well.

For example, in AU2, old approach they did something quite clever. A
variable _serverUrl_ is defined in the IA instead of hard coding the URL
for the SOAP endpoint, and you can pass it into a form field in the
Start workflow call.

Then in pre-activity map, you copy it into the <FirstNode> as a XML
attr, which in the IA itself, is then copied into a variable, and the
Mapping tool knows about it, which is clever as well.

Inside the IA, just before the WS Interchange action that does the
actual SOAP call, it copies the XML attr into the variable, removes it
via an XPATH call (all in one, during a variable declaration, a little
less obvious, but again clever) and then sets the Endpoint URL as the

All good stuff and in fact a huge improvement, since before GCV's were
available it was hard to move these from Dev to QA to Prod. This makes
it much easier, as you can define and specify the server URL in the
start workflow token in Policy and use the GCV's from there. (Also
GCV's are not available in the IA, alas, so you cannot GCV'ize the user
and password for the user to make the call...)

However, if you look at some of the default XPATH functions it calls, it
does 'manual' namespace declarations via XPath calls to add an XML
attribute xmlns:xsd with the value of http://www.w3.org/SChema or
whatever, one by one, for each node in the document.

But in troubleshooting another issue I noticed that there is a Apply
Namespace action, that for some reason defaults to Ignore Namespaces on
both Input and Output?

So why does it default to so many XPATH calls to add the name space
info, instead of using a pair of Apply Namespace actions (one for Input,
and one for Output)?

Clearly there was a reason, I would love to understand the rationale...
Since this will help better understand how this stuff all works under
the covers, which will only make it easier to use!!

(I wish this kind of stuff was in the docs, this is the truly
interesting stuff, right?)