Yossi Dahan [BizTalk]


Wednesday, May 24, 2006

Dynamically controlling the SOAP adapter's authentication properties

I’ve been trying yesterday to call a web service that requires basic authentication.
Normally I’d set the web service’s username and password in the send port transport configuration, but in this particular case I wanted to specify them in the process.

Being optimistic I’ve used the following in my assign shape as part of the web service construction –

Request(SOAP.AuthenticationScheme) = "Basic";
Request(SOAP.Username) = "<username>";
Request(SOAP.Password) = "<password>";

With most adapters setting configuration through the message context works wonderfully.

This did not seem to be the case with the SOAP adapter.
It would ellegantly ignore the details in the message context and use the settings in the port configuration.

If anyone have managed to use these please let me know, for now I have to assume that the adapter does not use the context properties to override its settings as other adapters do.

Sensitive Context Properties

When creating a property schema it is possible to mark a property as “sensitive”.
According to the documentation doing so will prevent its contents from being displayed in the Admin Console or HAT.
This is very good when you have to convey sensitive information in the context as part of your solution.
For instance – the password property in the SOAP adapter’s system property schema is marked as sensitive.

It is important to note though that marking a property as sensitive prevents you from promoting this property.
In some cases (when promoting through a schema) it will cause a design time error in in some cases (promoting through the
IBaseMessageContext.Promote, or in an assign shape as mentioned above) will create a runtime error.

If you will examine the event log entry generated by this runtime error you might see an initial error as an ArgumentOutOfRangeException with “Index and length must refer to a location within the string.” As its description
However, if you will look deeper you will see an InvalidPropertyValueException hiding in the stack call.

Having said all that, when I actually tried to work with a property marked as sensitive I could see it's value in both HAT and the Admin Console, so I have to admit I'm not quite sure what I have missed.

Friday, May 05, 2006

Backup transport in a BizTalk send port

I've was asked about this yesterday so I thought it's probably worth posting the subject -

Through the BizTalk Administration Console (or the BizTalk Explorer in 2004) it is possible to configure a send port to deliver messages to their destination.

For each send port you can set the transport configuration which determine which adapter will be used (and its adpater specific configuration).
you also configure the retry policy required and the send handler to use (which depends on the adapter you select).

Through the send port configuration you can also configure a backup transport to use in cases where the primary transport falied.

The process is something like this -

BizTalk tries to deliver message based on the Primary Transport settings.
Failure to trasmit will cause event 5743 to be written to the event log and, if retry is configured for the primary transport, the message will be retried n time (based on this configuration).
If all the retry attempts failed, and a backup transport is configured, event 5742 will be logged to the event log and BizTalk will try to deliver the message using the Backup Transport.

It is important to note that the backup transport is totally independant in terms of adapter configuration, its retries policy (you can have retries on the backup transport as well as on the primary transport, and they can differ) and even the send handler used (which makes sense if you'll can use different adapters).

Also note that there is no time delay between the failure of the last retry attempt of the primary transport and the first attempt to deliver to the backup transport.
you cannot, however, use alternative pipeline (as the pipeline has already been executed at this point)