Back to the Workshop
So we return to our Rulebase with Mechanics and Cars. Eagle-eyed readers will see this is an adapted version of an exercise in the Policy Automation training course. The version we are using here has different relationships and attributes than the one in the course. I am not intending to copy the material used in the course.
In the previous post we set up our Entities and experimented wth some Containment Relationship text. Now we can begin to study our Entiities in more detail and create / edit Attributes to extend the model.
Fire up the Debugger using Build and Debug without Screens. Let’s look at the output in the Debugger. Go ahead and right-click the “all the cars” icon and choose Add Instance.
Since the car currently has only one Attribute, you don’t have much choice as to what to enter – just double-click the green bar and type something like “Ford Fiesta”.
Which brings us to the question – just what is this information we are entering? Where did it come from, and what issues may we have?
The Attriibute you are entering was created automatically when you created the Entity definition. It is the “identifying attribute”. If this was the Mechanic, maybe it would be his or her name, or employee Id. Since it is the car, what would it be? I’ll hasard a guess and say why not the car registration plate, since it is unique and a useful way to distinguish between all those cars in the workshop. Of course our Car Entity will have a Make and Model as well, no doubt. So let us correct all of this and spot a couple of other traps along the way.
Back out of the creation and Click Build > Stop Debugging. Now double-click the Attriibute and let us review. We want this to represent the Car Registration. So go ahead and change the text. And observe :
Common trap #4. The Car is not a he or a she (despite what some drivers thiink!). It is impersonal – an “It” if you will. Failure to update the Default Gender will of course make for strange output in the Decision Report and Debugger.
Take the opportunity to give the Attribute a public name as well. Now we have spoken about the Car Entity, what about the Mechanic – for the Mechanic there is another one to think about.
Common trap #5 The Mechanic needs to be defined as male or female (depending on your business scenario, this may not be useful for our Rulebase, but there are many situations where it is!). To set up the “Gender Attribute” is quite simple. We have covered it before so just visit this post and resume when the Mechanic has a Gender Attriibute defined. Your Mechanic Entity should now have 2 Attributes and should look like this.
Note that we have also edited the Attribute Text for the Identifying Attriibute since the Mechanic’s name, in our case, will be enough to differentiate between them.
The Gender Attribute will come in very handy later on in the Web Determination and Decision Report for our Rulebase, Let’s now extend our Rulebase by adding a second rule to our Word Document. Make sure you create the Attribute as a Number and that you create it in the Properties Files (that could even be common trap #5b). The creation of the Attribute will look like this:
And the Rules should look like this now.
Now that job is done, we can begin to investigate the Gender Attribute. Firstly, we need to create a Screen File in our Project, and Create a Question Screen inside it.
Check your own project against the screenshot. If you are seeing “Who is the mechanic’s name?” then you need to edit the Attribute to “impersonal”, or if you chose to keep the original Attribute Text “the mechanic” then you will see that instead. Notice the new icon to show the Gender Attribute.
Build and run your Web Determination, and click the link referring to Mechanics. Add a Mechanic using the Add New Instance button.
Ignore any warnings you might get at this stage since our Interview is not really ready yet, so it has no real goals.
Excellent – Policy Automation has given us the two radio buttons and has shown it understands this is a Gender Attribute.
Common trap #6 Asssuming that this is going to work in different languages.
As you may know, in this demonstration sequence we have also been maintaining a parallel version in French.
Having entered the different Entities, Attributes, Rules in Word and having now created the Question Screen in the Screens File, this is what we get when we run the French Web Determination.
I’m sure you can spot the issue. To correct this we could go to the Question Screen, and the Gender Attribute Question, and change the Display Values for the List of Values.
And so finally we get good output when we Build and Run our Web Determination.
This editing of the Display Values may come in handy of course even if you are not working in a different language. The solution to the “male/ female” issue can be found in Part Six if you can wait that long.
In the next post in this series we will get our Reference Relationships up and running. Until next time!