Excellent code by the way, this is simply brilliant...there's an issue when using this in a custom pipeline after the Biztalk AS2 components. What seems to happen is that the Biztalk AS2 components put some 'header' content in the message body and the move the stream position to the point after that (in my case it was position 133 for example instead of 0). If all you do is read the stream then all is well since you'll be starting from position 133(as was my case) so you never see the extra stuff.
The problem however when using your component in a subsequent pipeline stage is that the stream position is getting set to 0 on the copy. What happens now is that you get that header stuff in your message body.
The problem occurs on line 735 of BREPipelineFramework/BREPipelineFramework.PipelineComponents.BREPipelineFrameworkComponent/BREPipelineFrameworkComponent.cs , "originalStream.Position = 0;" when it's making the copy of the message.
I wasn't aware that the AS2 components did this so it drove me nuts for a little bit wondering where that extra data was coming from.
The idea of how to fix it was this:
read the current position of the stream before any processing or reads occurs and then after the copy, set the position to the same position.
The code changes I did that seems to work are these (I haven't done extensive testing on this but it fixed the issue I was having):
make this the first statement in the SetupBREPipelineMetaInstructionCollection method -
long originalStreamPos = inmsg.BodyPart.Data.Position;
and then replace this line:
originalStream.Position = 0; (on line 735)
with this line:
originalStream.Position = originalStreamPos;
This works because the input stream hasn't been read at this point since this method gets called pretty much first thing when the pipeline executes so it shouldn't have moved any (I think this may be what setting the position to 0 is protecting against perhaps).
One could argue to capture it during the first line in the Pipeline Execute method and pass the number to your setup method to ensure nothing happens to move it between pipeline execution and the setup method.
Thanks for all your work on this
Excellent code by the way, this is simply brilliant...there's an issue when using this in a custom pipeline after the Biztalk AS2 components. What seems to happen is that the Biztalk AS2 components put some 'header' content in the message body and the move the stream position to the point after that (in my case it was position 133 for example instead of 0). If all you do is read the stream then all is well since you'll be starting from position 133(as was my case) so you never see the extra stuff.
The problem however when using your component in a subsequent pipeline stage is that the stream position is getting set to 0 on the copy. What happens now is that you get that header stuff in your message body.
The problem occurs on line 735 of BREPipelineFramework/BREPipelineFramework.PipelineComponents.BREPipelineFrameworkComponent/BREPipelineFrameworkComponent.cs , "originalStream.Position = 0;" when it's making the copy of the message.
I wasn't aware that the AS2 components did this so it drove me nuts for a little bit wondering where that extra data was coming from.
The idea of how to fix it was this:
read the current position of the stream before any processing or reads occurs and then after the copy, set the position to the same position.
The code changes I did that seems to work are these (I haven't done extensive testing on this but it fixed the issue I was having):
make this the first statement in the SetupBREPipelineMetaInstructionCollection method -
long originalStreamPos = inmsg.BodyPart.Data.Position;
and then replace this line:
originalStream.Position = 0; (on line 735)
with this line:
originalStream.Position = originalStreamPos;
This works because the input stream hasn't been read at this point since this method gets called pretty much first thing when the pipeline executes so it shouldn't have moved any (I think this may be what setting the position to 0 is protecting against perhaps).
One could argue to capture it during the first line in the Pipeline Execute method and pass the number to your setup method to ensure nothing happens to move it between pipeline execution and the setup method.
Thanks for all your work on this