Yossi Dahan [BizTalk]

Google
 

Monday, November 29, 2010

Controlling the credentials used by the SOAP adapter from an orchestration

A long time ago I looked into how one could provider the credentials to use when accessing a web service using the SOAP adapter from the process.

The context for this is, of course, a multi-tenancy solution, where the system calls a third party service, but needs to make that call in the context of the current user it is serving. Each instance of the process may be serving a different user/company and so needs to provide different credentials to the back-end systems.

As you can read from the post, at the time, I wasn’t very successful, but now I have solved that mystery, and it turns out it’s quite straight forward.

The thing that baffled me was that the SOAP adapter’s property schema did contain the necessary context propertied (Authentication Scheme, Username and Password), but I could not get it to use them when set from the calling orchestration.

Whatever I did, the adapter seemed to use the pre-defined settings (from the send port).

Eventually, and after talking to Paolo Salvatori, the answer dawned on me -

In many (if not all) cases, the way BizTalk communicates send port settings to the adapters is via the message context. The adapter defines a property schema and BizTalk populates the settings when creating an instance of the pipeline in the outgoing message.

Given this, when I set the context properties in my orchestration and then sent the message through the port, BizTalk overwritten my properties with the ones defined in the send port and so the adapter did in fact read the context properties, only that my values were no longer there.

If the adapter configuration UI allowed not writing any authentication details into the message context, my values would have remained and it all would have worked first time, but sadly that option does not exist, and the adapter will always write the authentication scheme, and, if not Anonymous, the username and password properties.

The workaround, however, was quite simple – I’ve created my own properties for the username and password, and a pipeline component to read these and copy them to the adapter’s context properties. as my pipeline component will run after BizTalk had set the send port configuration, my component in this case will overwrite these settings and win.

Fight fire with fire!

Labels:

0 Comments:

Post a Comment

<< Home