BizTalk, Development, Orchestrations

You do not (always) need a correlation set to promote properties in a message sent from an orchestration

It is common knowledge that you use a Correlation Set to correlate message by creating an instance subscription that subscribes to hopefully unique properties. The subscription is created by pointing out a number of properties that you want to use for the correlation. Then when a message is published to the MessageBox that matches that subscription it is delivered to the orchestration. What most experienced developers knows is that Correlation Sets also promote properties as they are initialized; as the first message is sent by the orchestration. There is no other way to manually select properties to be promoted in a message sent from an orchestration. However, do not think that manual promotion through the use of Correlation Sets is the only way that properties will get promoted when published by an orchestration. It is not.

If the property has a Property Schema Base of MessageDataPropertyBase as below, then you do not need a correlation set. You only need to send the message and promotion will be taken care of automatically.

image

Only if you want to promote a property that has a Property Schema base of context type (MessageContextPropertyBase or PartContextPropertyBase) do you need to manually provide a Correlation Set to make sure promotion happens.

image

By *ContextPropertyBase we mean that its origin cannot be found within the data of the message, but is expected to be promoted to the context by another component, such as the adapter, a pipeline component or something else – in this case an orchestration, do you need to manually take action to make sure it is promoted as you publish a message to the MessageBox from an orchestration. And in this case you need a Correlation Set.

Of course if you were to be actually doing correlation with the Correlation Set and not only using it to promote a property then you would still want to Initialize a Correlation Set containing all properties you want to use regardless if these have their origin in the message data or not.

Adapters, BizTalk, Orchestrations, SFTP

Using the SFTP Adapter in a Dynamic Send Port

In the comments to a previous blog post announcing the Blogical SFTP Adapter I got a question regarding the use of the SFTP Adapter in a Dynamic Send Port. The answer I was forced to give was that the SFTP Adapter did not in its current state support being used in a Dynamic Send Port. Not being one to shy away from a challenge, and eager to show we listen to feedback, I have added the artifacts and code necessary to support Dynamic Send Ports. Mikael has included my change and it will be available in the next release of the adapter to codeplex. The problem was that the adapter had no propertyschema, and so there was no way to access the properties needed from within an orchestration, and no support in the adapter for loading properties from anywhere but its configuration. It now has those things. The installer and source download now includes a propertyschema and the adapter looks at the message context if the config is null, which it will be in a Dynamic Send Port.


So, to use the SFTP adapter from your orchestration and a Dynamic Send Port, use something similiar to the below code:

DynamicSendPort(Microsoft.XLANGs.BaseTypes.Address) = “SFTP://server:22/”;
MsgOut(BTS.OutboundTransportType) = “SFTP”;
MsgOut(Blogical.Shared.Adapters.Sftp.Schemas.host) = “server”;
MsgOut(Blogical.Shared.Adapters.Sftp.Schemas.portno) = 22;
MsgOut(Blogical.Shared.Adapters.Sftp.Schemas.user) = “user”;
MsgOut(Blogical.Shared.Adapters.Sftp.Schemas.identityfile) = @”c:mysftpkeyfile.ppk”;
MsgOut(Blogical.Shared.Adapters.Sftp.Schemas.remotefile) = “OUT_%SourceFileName%”;

I’d post a full downloadable sample, but there really isn’t anything more to it then that. You should however take a look at the propertyschema, available in both the binary download and the source, to see which properties you can use.