Suburban Destiny

AzMan Biz Rules

Ok, I see the intent of BizRules in AzMan. Sometimes the question, “Are you allowed to do this?” depends on more than your level of training (group), your profession (role), place in the organization (group), the task in question, or the operations that make up the task. Sometimes it depends on something like, the time of day, how much money you’re talking about, and so on.

So in AzMan’s 9 parameter CheckAccess() method, methods 4 and 5 allow you to pass in some value-parameter pairs. The business rules are attached to roles and tasks. Now since CheckAccess doesn’t let you pass in the name of a task or role, it must be starting with the operations and works backwards. If it hits a role or task with a BizRule attached to it, it runs it.

The script’s environment gets a global object AzBizRuleContext, which has the method GetParameter(stringName) and the Boolean property BusinessRuleResult.

Try as I might, the only way I could get my BizRule to talk to me was via the AzBizRuleContext and FSO. MsgBox didn’t work.

Having invested some time into learning how this feature works, here is my critique.

  1. The invocation is too weird. It looks like all parameters go into a great big pool and are used by any rules that happened to get invoked while going through all the relevant roles and tasks. This creates an opportunity for parameter name collision, wild behavior if these are using values by reference and if these rules can modify the parameter values. (A test for another day to see if these are the case)
  2. Since you can use CreateObject(progId), you should create COM wrappers around your .NET code and invoke it that way.
  3. The usage of parameters 6 through 9 appear to be for callbacks (maybe a sort of output parameters? A way to call the code of the caller?) Either way, I’m not sold on these patterns. If a pattern is inexplicable, undocumented—it is an anti-pattern.
  4. You can invoke business rules in any type safe way. In fact, it doesn’t look like the developer can invoke any rule. If the AzMan store doesn’t think the rule applies, the rule isn’t applied.
  5. Also, in Azman, you might get the right to an operation via many paths, biz rules might get applied when you weren’t expecting them. This sounds like it would lead to defensive programming, where you try to pass in all the parameters for all the biz rules in the entire store, all the time. Ugh.

Here is an alternative:


If MyBizRules.CheckRule(Amount,TimeOfDay,MoodOfAdministrator) Then
    AzManStore.CheckAccess(p1,p2,p3,[p4,p5,p6,p7,p8,p9]) ' p4 through p9 are nothing
End If

Application developers understand Amount, TimeOfDay, MoodOfAdministrator in a way that an API dedicated to groups, roles, tasks, and operations can’t. These are also domain specific issues. The point of checking is unambiguous. You won’t get a BizRule checks just because there were 15 ways to link the user to a particular operation and four of them crossed BizRules you weren’t thinking about. (Conversely, when you write a bizrule, you don’t have to forecast how many way an access check might shake out and think if they semanticly make sense in each case)

Update: Further thinking on this makes me think that the names/values arrays actually represent the universal relationship pattern. This is the idea that all data structures could be represented by a two column table with the name of the data entity and it’s value. This scales to a handful of data entitities. Anymore than that and you have a custom databases that is impossible to parse, search or use without an enormous amount of code.

← Back to Tech