Streaming pipeline components and property promotion
This is one of those things that makes perfect sense ,but until you see them in action you just can't be sure…
As part of a prototype I wanted to use data from the message to manipulate the behaviour of a send adapter.
To illustrate what I mean imagine the common scenario where there's send port that uses the file adapter and you want to control the name of the file created.
Typically you'd configure the file send port to use the %SourceFileName% macro - and update the ReceivedFileName context property with the name you require.
Now - imagine you can't to rely on the receive port to do the promotion (update ReceivedFileName) but have to do it in custom code in the send pipeline for some reason (which is irrelevant for this discussion)
You would rightly want to implement your pipeline component in a streaming fashion (as we all do, all the time….right?!)
So I did, and in fact, other then a couple of really foolish mistakes I've made writing the component was a relatively easy task, and it worked pretty much first time.
For my implementation I chose to use the XPathMutatorStream.
Normally it is used to update nodes in a streaming fashion, but although I did not need to manupulate the message at all I chose to use it as it has a great built-in mechanism to raise an event when specific locations in the message are read which was very useful for me.
Anyway - running this component in the receive pipeline worked like a charm - the property got promoted and the send adapter delivered the message correctly.
Running the same component with the same configuration (yes - with the same message...), but in the send pipeline, however, did not produce the expected results, and, in the file adapter sample, the original filename is used rather then the value from the message.
It appears the context property does not get set.
Well - actually - I suspect it does, but too late.
With the nature of streaming pipeline components the promotion will only happen when the stream reaches the relevant point in the message, which is only after the adapter (unless you have a non-streaming pipeline component further down the line) read all the bytes of the stream up to that point.
With most adapters this means it will happen too late, as the adapters will usually open whatever connection they need to before reading the stream. (as you know in an ideal scenario the adapter would not read the stream itself at all but leave it for the ultimate recipient). So they need any information regarding the connection up front, before the stream is read.
In my case it meant that only after the adapter started to write the stream to the file (and therefore read it from the component), that the filename property got promoted. Way after the adapter accessed it to determine the filename to use.