The Perils of Read-Only BOM Attributes
The other day, as I was using the code provided with the ODM tutorial “Creating and deploying a decision service” for illustrating my DVSBatch tool, I noticed something strange. The Borrower object generated in the DVS template was astoundingly simple:
What happened to the borrower’s bankruptcy information? Where did the borrower’s spouse go?
This presented a problem: how was I to use DVS to test rules with different bankruptcy data?
The bankruptcy attributes were clearly present in the business object model (BOM), as detected when viewing the Borrower BOM class in the BOM Editor in Rule Designer:
Even though these attributes are in the BOM, they do not show up in the DVS template. Digging into the spouse attribute, we see why. This attribute was marked as ‘Ignore for DVS’.
This is understandable. Since spouse information is not used in any of the rules in the sample ruleset, it is valid to ignore it for DVS testing.
But how about the bankruptcy information? As you can imagine, this information plays a pivotal role in determining the ‘corporate score’ in ‘Loan Validation Scoring’ rules. It is therefore imperative that Bankruptcy information be present for DVS testing. Diving into the member screen in the BOM editor, we see the root cause of the problem: the bankruptcy attributes are marked ‘Read Only’.
This is caused by the fact that in the Java execution object model (XOM), the bankruptcy attributes only have a ‘getter’, but no setter (other than the factory method setLatestBankruptcy).
public Date getLatestBankruptcyDate() {
return latestBankruptcy.getDate();
}
public String getLatestBankruptcyReason() {
return latestBankruptcy.getReason();
}
public int getLatestBankruptcyChapter() {
return latestBankruptcy.getChapter();
}
public void setLatestBankruptcy(Date date, int chapter, String reason) {
this.latestBankruptcy = new Bankruptcy(date, chapter, reason);
}
DVS does not handle read-only BOM attributes. For DVS to load data from an Excel spreadsheet into BOM entities, it needs a mechanism to set BOM attributes from Excel cell values. Having a read-only BOM attribute thwarts that and therefore the DVS template ignores read-only BOM attributes.
The Fix
The situation is this: we want to be able to use BOM attributes for DVS testing, but we don’t want these attributes to be writable within rules. The typical Java pattern of creating the accessor (getter) without the modifier (setter) falls short. This is a fairly common situation and it has a simple solution: create read/write BOM (and XOM) attributes, but only assign a navigation phrase in the BOM member verbalization.
For this example, we add the following setters (after adding the corresponding basic setters in the Bankruptcy class):
public void setLatestBankruptcyDate(Date date) {
if (latestBankruptcy == null) latestBankruptcy = new Bankruptcy();
latestBankruptcy.setDate(date);
}
public void setLatestBankruptcyReason(String reason) {
if (latestBankruptcy == null) latestBankruptcy = new Bankruptcy();
latestBankruptcy.setReason(reason);
}
public void setLatestBankruptcyChapter(int chapter) {
if (latestBankruptcy == null) latestBankruptcy = new Bankruptcy();
latestBankruptcy.setChapter(chapter);
}
Now we can set the BOM attribute to be Read/Write.
We don’t add an action phrase in the verbalization of this member. A non-existant action phrase effectively makes the BOM attribute "read-only" as far as rules are concerned. The navigation phrase is left untouched. When we generate the DVS template, we see the bankruptcy members in the Borrower class. Now, more meaningful DVS tests can be devised.
Conclusion
There are several conclusions that one can draw from this.
Avoid using read-only attributes in the XOM and the BOM, especially if they are used in rule processing. Read-only attributes cannot be used in DVS tests.
Sometimes, design patterns that make sense in a Java-only world have to be sacrified at the rule altar.
Use verbalization to make an attribute “read only” from a rule perspective. Specifically, remove action phrases to disallow updates to a BOM attribute from rules.
Do not assume you are seeing best practices being employed in the samples and tutorials provided with the IBM documentation.
