9/15/2019 Biztalk File Adapter Context Properties
Apr 17, 2018 - System properties are mostly used internally by BizTalk Messaging Engine and its components. In general, changing the values set by the.
Hi Svet Actually I already did some work with this idea, to create a shared pipe server (like beacon server), all context property pairs for all outgoing messages will be sent there and then immediately pulled out by a validation step (similar as receive step, it is a pipe server) along with a receive step. It actually works fine now, but we may still need to pull the context values for nothing, this is not convenient. I'm thinking that we probably can use some property (similar as Encoding/PromotedProperties) to mark it context value verification required. Does it sound good?
Hi Tony, very glad to hear that others have also realized that such feature would be very valuable. Thank you very much for sharing your experience of solving this, very much appreciated. From your description I can understand that what you have done is that in a send port instance context propery bag is sent as a separate message right after the actual payload message (the mesasge that you are expecting from BizTalk) is sent, however to a different static endpoint that is spun up for the lifetime of the test case. In a validation step then you pull out this extra message and perform the desired validation.
One question here - how do you correlate the received context property bag with the corresponding message? This is especially vital in parallel processing scenarios where you can get some racing conditions which can result in the payload message and the corresponding property bag received in the validation step coming out of band. I like though the idea of allowing to predefine a set of properties that you are interested in in an adapter property, This feature here is for the other way around - inbound to BizTalk, where system properties, not only adapter ones, are promoted when a message is received through the mock adapter. I will soon be adding a new feature for an upcoming version that would actually address exactly what you are describing.
![]()
The trouble with this current feature as described is that the promotion would be static - for each and every message the same value will be promoted/written to the context over and over again. The best would be to have a per-message capability where the desired values for promotion are supplied along with the test message. The same is applicable on the way out - all/predefined set of context properties to be available along with the received message. This way there is no need to try to create complex correlation logic for message payload and its context properties - they simply will come along with the message itself. Cheers, Svet. Hi Tony, finally managed to review your changes.
Looks pretty neat and is in line with what you described of an approach for solving this. Few comments about the implementation: - several projects for BizTalk 2013 R2 have changed target framework from 4.5.1 to 4.5. Any particular reason for this? - spotted one place where you defined a boolean variable with var. Though totaly legitimate i personally stick to the premitive types being explicitly defined, var type come very handy for complex types, especially with long names.
the changes to the WiX deployment definitions would no longer be required, as this deployment approach is currently abandoned and NuGet is the only supported way going forward. I still think that your approach for verifying context properties is somewhat an overkill as it requires the opening of one more pipe and sending those over a separate channel.
I still think there is a great chance of running in some sort of racing conditions when processing things in parallel, which your test cases are not currently verifying. You use a single $Context pipe per mocked endpoint and in case there are 2 or more instances of messages that are processed in parallel (lets say in de-batch scenario) then you might end up picking the wrong message context and then the test case would start behaving not as expected. That is why i still believe that the approach i drafted for you, where the properties are sent along with the message contents over the wire is far better, safer and predictable. Then we know for sure that the context properties are indeed the ones that belong to the given message. Thus the implementation would be simpler, as there will be no need for additional pipes. Furthermore, as already mentioned earlier, your implementation solves only the propagation of properties on the way out of BizTalk.
By implementing a messaging protocol that allows for including the message properties along with the message contents, then it will be irrelevant in which direction in regards to BizTalk they go. It will be then possible to promote context properties in the inbound adapter on a per message bases. A very typical case for such behavior that i have seen used everywhere, is some logic in a pipeline component, or orchestration, that is related to modifying the name of a received file. This means that when working with the mock adapter we have to force the message to appear as if it was received by the FILE adapter. This is achieved by promoting context properties specific to the file adapter.
And this is totally legitimate to do so, but currently the framework supports this only per end point instance, e.g. It is somewhat static.
It will give much greater flexibility if it is possible for this promotion to be performed on a per message base, like in setting context properties on a mock message in a test case that is about to be sent to the integration. Finally, I am currently working on a completely new programming model for the framework, that has nothing to do with BizUnit. So I am planning to incorporate this feature with the context properties in the coming changes. Hence i see the way ahead as follows: - if you insist to have your changes incorporated in the framework, i suggest you create a fork and check in the changes there. This is because I mean that your approach is off course a better and more robust solution, and as such i cannot accept to be incorporated in the code - if you are convinced by my reasoning and wish to abandon your implementation, and are still interested in working with the framework, then you can help with implementing the messaging protocol i am talking about. Thanks, Svet. Hi Tony, thanks for your reply and for your feedback and recommendations.
I am very pleased to hear that you are coaching others to use the framework. I will be very thankful if you would share what are the major challanges with taking the framework into usage some other time. One of the major reasons for me to base the usage on BizUnit is exactly to avoid a steep learning curve. But sleep tight - the coming changes are not meant to trash the support of BizUnit - this part will be intact as currently everybody who use TransMock have their tests implemented in BizUnit.
So it will be very irresponsible from me to just cut this part and say from now on you use this way instead for writing tests with TransMock. As for the messaging protocol your understanding is correct - it is somthing in this direction, but with better abstraction and a way to serialize and desirialize a message along with its BizTalk properties, and with baked extensibility in. You mention that the framework itself is not good in tests related to parallel processing. Could I ask you to register any such issues in the GitHub project, so that I can have it on the radar.
I have a very limited number of tests for such scenarios and managed to fix few issues related to this once i enhanced those tests. Yet there are cover perhaps few percent of most of the cases, so any specific input will help me to extend this reach. Will contact you when i have description and stuff for the protocol implementation. Thanks, Svet.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |