locked
Cascading Business Rules RRS feed

  • Question

  • I have come across a few issues around business rules in MDS that look like they could be bugs but haven't been able to find anyone else online with similar problems...

    I have a Customer Entity which is the upper level of my Customer hierarchy. At the lower level I have a Customer Store Location Entity which has domain based attributes of the Customer and Store Location. I've configured a business rule to set the Customer Store Location Name to be a concatenated string of the 'Customer Name' + ' - ' + 'Store Location' attributes which is set to trigger when the Customer Name attribute changes.


    When editing the Customer entity at the top level, the Customer Store location Entity shows this change but even when running the business rules at both levels, the Customer Store Location Name does not update.


    My two questions are:

    1. Why is the change to Customer not picked up by the Customer Store Location entity's business rule even though I can see the attribute has changed?
    2. Is there any way of triggering business rules to run for multiple entities if a change is made?

    Any advice would be much appreciated
    Thanks
    Ben

    Friday, November 12, 2010 11:44 AM

Answers

  • I think I have this figured out-- you need two rules.

    Step 1: Set Customer Name attribute to be in a change tracking group (1).

    Step 2: For CustomerStoreLocation entity, the first rule is: If has changed in group 1, then Customer = dba.Customer.Name.

    Step 3: For CustomerStoreLocation entity, the second rule is: concatenate CustomerStoreLocation Name by using your two values. This doesn't need a "has changed" aspect to it, because you always want it to be true. So this rule is an action only, no condition.

    Let me know if you need more details. If you run these two rules in order you should be good I think.

     

     


    Suzanne Selhorn [MSFT]
    • Proposed as answer by Kalman Toth Friday, November 19, 2010 2:50 PM
    • Marked as answer by Ben K Ng Friday, November 19, 2010 4:27 PM
    Thursday, November 18, 2010 10:10 PM

All replies

  • Hi Ben,

    I'm not 100% clear what you're doing, but maybe I can spark some ideas.

    For your business rule, are you using the Action "equals" rather than "defaults to"? ("Defaults to" is a one time change, whereas "equals" makes the change every time rules are applied.)

    The best way to have rules update multiple entities is to create multiple rules and set the priority order so they run in the right order.

    Also, "has changed" is a one-time thing as well I think. So if you run the rule on an attribute that's changed, you have to change the attribute again and re-run the rule to test...

    (If you reply with more questions, can you confirm--are you working with derived hierarchies or explicit? And can you give your rules in an "If Then" format so I can better understand what you're up to?)

    Thanks


    Suzanne Selhorn [MSFT]
    Monday, November 15, 2010 6:53 PM
  • Hi Suzanne, thanks for the reply.

    Here's the rule I'm using:

       If DBA.Customer.Name has changed in group 1

       Then CustomerStore.Name equals a concatenated value DBA.Customer.CustomerName + - + Location.

    This is a derived hierarchy.

    Here are the steps I have taken to test this rule:

    1. On the Customer Entity (DBA of Customer Store) I update the CustomerName. The row shows the "validation pending" flag.
    2. I run all business rules for this table and the "validation succeeded" flag is shown.
    3. I navigate to the Customer Store Entity. The row shows pending validation and I can see that the domain based attribute of Customer has updated to the new value.
    4. I run the business rule for the table (described above) expecting the Customer Store Name to show the concatenated string of DBA.Customer.CustomerName + " - " + Store Location.
    5. The name does not update yet validation succeeds.

    I've used CustomerName instead of standard "Name" field in case the issue is due to reserved words.

    All change tracking groups are set to 1.

    Thanks

    Ben

    Thursday, November 18, 2010 12:02 PM
  • I'm going to try to repro...

    I was wondering though--have you been doing any versioning of your model? I ran into an issue recently--I can't quite remember the specifics--but I think I created a business rule, then changed data in an older version of the model and couldn't get the rule to work. Rules work across all versions, but I thought I'd throw this out as another idea.


    Suzanne Selhorn [MSFT]
    Thursday, November 18, 2010 8:34 PM
  • Ah, I see your issue now. Let me ask around and see if I can get some ideas for how to make this work.

    Thanks


    Suzanne Selhorn [MSFT]
    Thursday, November 18, 2010 9:32 PM
  • I think I have this figured out-- you need two rules.

    Step 1: Set Customer Name attribute to be in a change tracking group (1).

    Step 2: For CustomerStoreLocation entity, the first rule is: If has changed in group 1, then Customer = dba.Customer.Name.

    Step 3: For CustomerStoreLocation entity, the second rule is: concatenate CustomerStoreLocation Name by using your two values. This doesn't need a "has changed" aspect to it, because you always want it to be true. So this rule is an action only, no condition.

    Let me know if you need more details. If you run these two rules in order you should be good I think.

     

     


    Suzanne Selhorn [MSFT]
    • Proposed as answer by Kalman Toth Friday, November 19, 2010 2:50 PM
    • Marked as answer by Ben K Ng Friday, November 19, 2010 4:27 PM
    Thursday, November 18, 2010 10:10 PM
  • That's great Suzanne. It works but I'm not sure I understand why step 2 is required (even though it is)...

     

    Friday, November 19, 2010 4:27 PM
  • My impression is that right now, change tracking is intended to be "per entity." I think that's why step 2 is required.
    Suzanne Selhorn [MSFT]
    Friday, November 19, 2010 5:46 PM
  • Ah ok that makes sense.

    Thanks Suzanne, this has solved a massive worry for us.

    Wednesday, November 24, 2010 7:55 AM