none
Is it a good idea to use BRE for Message transformation instead of using Maps? RRS feed

  • Question

  • We are thinking about a scenario of constructing multiple versions of hl7 messages from a source schema. We thought of constructing BRE vocabulary for both source schema and HL7 2.6 schema and then use policy per version with bunch of rules for transforming the source schema to hl7 schema. We think this will provide more maintainability to tackle future changes but in other way this seems a over kill. Any suggestions or opinions would be highly appreciated.  Thanks you
    Monday, November 10, 2014 3:19 AM

Answers

  • My experience is that such an implementation would be way over architected for the actual use cases you will experience.  Meaning, you will spend time building a framework for something that may change once or twice and in ways that the framework didn't originally consider :).

    At  that point, the cleaver implementation becomes a maintenance problem because it doesn't use common standard patterns.

    This manifests itself in situations where the original developer can implement a change in 10 minutes but anyone else takes hours because they have to learn the implementation from scratch while creating or modifying a Map would take only an hour or so.

    • Marked as answer by Angie Xu Friday, November 14, 2014 2:21 AM
    Monday, November 10, 2014 3:25 PM
    Moderator
  • Seems a bad idea. 

    XSLT is a specialized language to transform XML without serializing XML to the objects. It works good in the most of the cases. If you need more, serialize XML and use object to object mapping tools. There are plenty. Why exactly do you need BRE?

    I saw many implementations of the BRE in the production, 90%+ of them do not pass these tests for the BR use. So try those tests as a first step.


    Leonid Ganeline [BizTalk MVP]

    Monday, November 10, 2014 10:37 PM
    Moderator

All replies

  • Monday, November 10, 2014 4:43 AM
    Moderator
  • Maintainability would be a factor of how often the rules would change which would have resulted in map changes and deployment. If however the intent is to be able to add more message creation instances while the existing ones do not undergo much change then maps would be better.

    You could also use a combination of the two where you use maps to get the basic structure right and uses rules to supplement the message content that is more dynamic in nature (ass opposed to using DB lookup functoids within the map).

    Regards.

    Monday, November 10, 2014 5:24 AM
  • My experience is that such an implementation would be way over architected for the actual use cases you will experience.  Meaning, you will spend time building a framework for something that may change once or twice and in ways that the framework didn't originally consider :).

    At  that point, the cleaver implementation becomes a maintenance problem because it doesn't use common standard patterns.

    This manifests itself in situations where the original developer can implement a change in 10 minutes but anyone else takes hours because they have to learn the implementation from scratch while creating or modifying a Map would take only an hour or so.

    • Marked as answer by Angie Xu Friday, November 14, 2014 2:21 AM
    Monday, November 10, 2014 3:25 PM
    Moderator
  • Seems a bad idea. 

    XSLT is a specialized language to transform XML without serializing XML to the objects. It works good in the most of the cases. If you need more, serialize XML and use object to object mapping tools. There are plenty. Why exactly do you need BRE?

    I saw many implementations of the BRE in the production, 90%+ of them do not pass these tests for the BR use. So try those tests as a first step.


    Leonid Ganeline [BizTalk MVP]

    Monday, November 10, 2014 10:37 PM
    Moderator