I think BTS 2004 is a confusing, frustrating, tedious, wonderful, huge, exciting and never ending story.
...so where do you put your business logic in BTS, some might say use the Business Rule Framework, others say call an external .NET assembly and put your business logic in there, others would see it put now where but in an orchestration, others again would place some logic in custom functoids and some might argue strongly that there business logic should reside in a custom pipeline, hell why not in a custom adapter while we are at it.
It can be pretty confusing making these decisions on where to put your business logic and validation in BTS...its not like when we eat sleep and s... the DNA (Doesn't Mean Anything) model back in the late 90', that was pretty strait forward compared to Biztalk.
I think the Biztalk model unfortunately invites you to put your business logic all over the place and then sometimes forces you to put it in a certain place...take for instance the scenario where you receive a schema from a third party, they want to make sure you obey certain rules, so they have made a schema with a pattern value for you. Now unfortunate for you, if you base your messages on this schema because the pattern is lost when you compile your BTS solution....for some reason the BTS team thought it was not necessary to crank up some code that utilized the Regex class when dealing with schemas that had the pattern value in it....so you must go an create a custom pipeline and do the schema validation there instead, while this might as well could have been built into say the Microsoft.XLANGs.BaseTypes.SchemaBase class.
btw I think it is tremendously traumatic that the Business Rules Composer doesn't include the namespace in the Document type when adding a schema :(, you are looking at some frustrating debugging hours if you are not aware of this....
Rorschach abstraction; no two people think they mean quite the same thing
10:11:26 PM 
|
