none
Validating the content of a message RRS feed

  • Question

  • Hi all

    We have an internal product ordering website which provides our sales people the ability to pick items from a catalogue, create and configure an order and specify suppliers.  They then place that order, which behind the scenes submits the order in a common format to BizTalk 2013.  BizTalk then takes that order, transforms it to the suppliers formats, transmits them and recieves success reponses or failures, which are sent back to our internal website.

    The issue I have is suppliers have very different rules about what they will accept, such as for one supplier address lines 1 & 2 together cannot exceed 30 characters.  Now we could update the internal website to have validation rules per supplier, or just take the most restrictive validation rules and apply those for orders to all suppliers, that way the validation work is done before it reaches BizTalk.

    But I was wondering if validation of the order content would be better done in BizTalk, which could perform the validation and return any failures to the internal website before submitting to the suppliers.  This could be achieved via a Map or by Business Rules (as documented here https://seroter.wordpress.com/2009/11/11/validating-incoming-data-using-the-biztalk-business-rules-engine/).  I guess the advantage of the Business Rules is that updates (as a result of changes to rules at the supplier or additional suppliers being added) would not require a deployment.

    The internal website is the only application (currently and probably ever) that will submit these orders to our BizTalk.  New suppliers are easily added to our internal website, without code changes or deployments.  Suppliers themselve perform validation, but the errors returned are not very user friendly so not suitable for displaying to our users.

    So, I'd just like to know peoples thoughts on doing this kind of content validation in BizTalk.  Should BizTalk be doing it, the source internal website, or both.  If in BizTalk what would be the best approach.  Am I trying to do something unusual?

    Many thanks for any insight you can give me
    Colin.

    Thursday, April 14, 2016 10:18 AM

Answers

  • We do something very similar with BRE, where there is a Validation orchestration that calls the appropriate BRE policy, based on say, supplier name. This gives you a lot of flexibility.

    So, what you can do is create an envelope message with two logical sections/parts- 1) your actual mesage; 2)a validation header. The validation header can have elements like Suppliername, RuleExecution History, Passed/Failed validaton etc.

    Pass this envelope message to BRE (first select correct policy based on supplier). The rules can then access the actual message, do business validation on it. The rule execution results can be populated in the validation header of your envelope message.

    You don't need to do redeployments if validation logic changes, or if you are onboarding a new supplier. To avoid redeployment to onboard a new supplier, you can make the policy name selection within your Validation process dynamic as well. Pass the inbound message to an initial policy that can return the policyname to be called based on supplier/some identifier in the message. This returned policy name can then be used to invoke the actual policy that performs the validation in BRE.


    Thanks Arindam



    Thursday, April 14, 2016 10:25 AM
    Moderator
  • In general, yes.

    Ideally, any app such as your Order site would do all it's own internal validation but sometimes this isn't practical.

    Where BizTalk comes into play is when there are differences in the 'rules' that each app applies so it's unreasonable to expect every app to accommodate every other app.  In these cases, the integration app, in BizTalk, applies target specific rules and takes some action when something doesn't 'pass'.

    The BRE is the most appropriate facility to use here since Policies/Rules can be modified externally and are somewhat user accessible.

    • Marked as answer by ColinCG Thursday, April 14, 2016 2:33 PM
    Thursday, April 14, 2016 11:23 AM
    Moderator

All replies

  • We do something very similar with BRE, where there is a Validation orchestration that calls the appropriate BRE policy, based on say, supplier name. This gives you a lot of flexibility.

    So, what you can do is create an envelope message with two logical sections/parts- 1) your actual mesage; 2)a validation header. The validation header can have elements like Suppliername, RuleExecution History, Passed/Failed validaton etc.

    Pass this envelope message to BRE (first select correct policy based on supplier). The rules can then access the actual message, do business validation on it. The rule execution results can be populated in the validation header of your envelope message.

    You don't need to do redeployments if validation logic changes, or if you are onboarding a new supplier. To avoid redeployment to onboard a new supplier, you can make the policy name selection within your Validation process dynamic as well. Pass the inbound message to an initial policy that can return the policyname to be called based on supplier/some identifier in the message. This returned policy name can then be used to invoke the actual policy that performs the validation in BRE.


    Thanks Arindam



    Thursday, April 14, 2016 10:25 AM
    Moderator
  • In general, yes.

    Ideally, any app such as your Order site would do all it's own internal validation but sometimes this isn't practical.

    Where BizTalk comes into play is when there are differences in the 'rules' that each app applies so it's unreasonable to expect every app to accommodate every other app.  In these cases, the integration app, in BizTalk, applies target specific rules and takes some action when something doesn't 'pass'.

    The BRE is the most appropriate facility to use here since Policies/Rules can be modified externally and are somewhat user accessible.

    • Marked as answer by ColinCG Thursday, April 14, 2016 2:33 PM
    Thursday, April 14, 2016 11:23 AM
    Moderator