There are a few different uses of business rules.
1.
Default values define data items by specifying what their default value should be. I'm not sure how this would be of much value to a third-party developer like yourself.
2.
Save validation define validation rules required to save. These rules can cause errors and/or warnings to appear in the "Errors and Warnings" windows. If it returns any errors, the save is aborted.
3.
Field validation define validation rules applied at data entry time. When the data item is altered, this rule can return errors which are displayed in a message box to the user and their initial edit is reverted.
I think field validation is what you want to do, based on your chosen names.
roteague wrote:I assume there is one entry per input.
Ideally, your rule will refer to specifically to each individual piece of data it is dependent upon. The business engine is optimized such that it will only call your rule if any of the inputs to the rule have changed. If you specify an entire object as an input, rather than the particular property of that object as an input, the business engine will call your rule more often than it needs to.
roteague wrote:The <Order> node refers to the order the parameter is passed into the function - not the Order object itself
Correct. The <Order> nodes specify the ordinal position of that parameter among the list of parameters. It make the most sense to number them 0..n, without skipping any positions.
roteague wrote:and the <Source> is the class or property from the order that is passed in.
The <Source> nodes refer to data item names relative to the object named in the BusinessObjectContext node. It can also be a literal constant, such as an error message.
roteague wrote:Naturally, the <BusinessObjectContext> is the context from the order.
The <BusinessObjectContext> node refers to the data item name of the parent object of the data item name specified in <Name>.
roteague wrote:So, if I wanted for example to build a Business Rule module to validate the TMK of a property, I would setup the XML as follows:
Code: Select all
<Instance>
<Name>IsValidTMK</Name>
<BusinessRule>ValidateTMK</BusinessRule>
<BusinessObjectContext>Property</BusinessObjectContext>
<InputList>
<Input>
<Order>0</Order>
<Source>TaxMap</Source>
</Input>
</InputList>
</Instance>
Would <BusinessRule> then be the name of the class that implements BusinessRuleBase (IBusinessRule)?
Yes, <BusinessRule> names a class that implements IBusinessRule, but I don't think your xml is right. I have more about that below.
roteague wrote:In this example case, I would simply implement ExecuteImpl in such a way as I need to check the inputs.
Yes.
Assuming you are trying to validate the data, you are missing something.
If you want the validation to occur when attempting to save, add an empty child <SaveValidationInstance /> node to your Instance node.
If you want the validation to occur as the data is entered, add an empty <FieldValidationInstance /> child node to your Instance node. Add a ValidatedField child to Instance with it's text specifying the data item name of the field you're validating. In your list of inputs, use [PotentialValue] to pull in the actual value entered by the user.
Code: Select all
<Instance>
<Name>IsValidTMK</Name>
<BusinessRule>ValidateTMK</BusinessRule>
<BusinessObjectContext>Property</BusinessObjectContext>
<FieldValidationInstance />
<ValidatedField>TaxMap</ValidatedField>
<InputList>
<Input>
<Order>0</Order>
<Source>[PotentialValue]</Source>
</Input>
</InputList>
</Instance>
You can find examples of this by searching <select dir>\Data\RuleInstanceDefs\CoreBusinessRules.xml for any of these terms: PotentialValue, FieldValidationInstance, or ConstantValue.