1

My input data has attributes for which multiple values can refer to a single business-friendly verbalization (domain label). I am trying to figure out how to represent this in Rule Designer. I'm new to ODM and still learning the ropes -- currently using ODM 8.8.1 (distributed / Java).

Imagine mapping ZIP code prefixes to their state. For example, ZIP codes beginning with 967 and 968 are Hawaii. In a nutshell, I want to express the rule as "if the ZIP code prefix is Hawaii..." rather than comparisons to 967 and 968. In domain terms, 967 and 968 are the real underlying attribute values, and Hawaii is the verbalization label. But obviously BOM-to-XOM expects a single return, and it wouldn't be correct to arbitrarily choose 967 or 968.

My actual scenario is far more complex involving long strings of cryptic code-values that the users would never know or recognize, but the concept is identical. In some cases a label can map to 15 or 20 underlying values.

Is this possible with ODM domains? (I am pretty sure it could be done on the other side with a decision table but I'm really trying to solve it as a domain problem for now.)

McGuireV10
  • 9,572
  • 5
  • 48
  • 64

2 Answers2

1

Your best approach here is to create a XOM or BOM class to map the state to the prefixes and then wrap that with the verbalization you want. I will illustrate with an example that maps zipcodes to states.

Example:

  1. Setup an enum or domain with your states:

public enum States
{
 AL,
 AK,
 AZ
  // etc
 }
  1. Make a class for your zipcodes:

public class Zipcode
{
 private String zipcode;

 public String getZipcode()
 {
  return zipcode;
 }

 public void setZipcode(String zipcode)
 {
  this.zipcode = zipcode;
 }
 
}
  1. Create an extender class to perform the mapping of zipcodes to states:

public class ZipToStateMap
{
 private Map<String, States> zipToStateMap = new HashMap<String, States>();
 
 public ZipToStateMap()
 {
  zipToStateMap.put("99553", States.AK);
  zipToStateMap.put("99571", States.AK);
  // etc
 }
 
 public States getStateFromZip(String zip)
 {
  return zipToStateMap.get(zip);
 }
 
 public boolean zipIsInState(String zip, States state)
 {
  return this.getStateFromZip(zip) == state;
 }
 
}
  1. Create a virtual bom method that uses the ZipToState:zipIsInState() extender:

virtual bom method image

  1. Write a rule using your new mapping:

enter image description here

  • Would you mind including some code snippet, or more guidance? This is technically a one-line answer. – DarkCygnus Dec 15 '17 at 17:30
  • I didn't need a class, but I added some if-string-contains tests in the BOM-to-XOM to translate the multiple real-world XOM values, returning a single BOM-only code. The real XOM field is not verbalized. In the context of my example, if the real XOM data was 967 or 968, the BOM would return a code "50" giving us a single value to verbalize as "Hawaii". – McGuireV10 Dec 15 '17 at 19:28
0

It might be possible to use ODM domains to address this problem, but I doubt that would be the best solution because that is not how domains are intended to be used. If you wanted a list of states or a list of zip code prefixes to that they could be referenced in rules, then ODM domains are a good solution. But to maintain a mapping between a state and it's zip code prefixes, I'm not so sure; ODM domains do not provide a way to get the possible values for the domain, unlike Java enums, which provide a .values() method.

Are you worried about maintaining the mapping between zip code prefixes and states? Are you wanting the business user to maintain the mapping?

One option without resorting to Java is to define a ruleset variable to hold a list of zip code prefixes for Hawaii. If we assume that variable is verbalized as 'the Hawaiian ZIP code prefixes', then the rule might be expressed as "if the ZIP code prefix is one of 'the Hawaii ZIP code prefixes' then ...".

There is also the possibility that rule overriding and the hierarchical property would be appropriate for your situation. But that is a complicated, seldom-used feature.

  • The real scenario is a vast list of complex, human-unfriendly codes we get back from an ancient mainframe database which map to financial asset types. They change rarely (I can think of maybe two or three additions in almost 20 years). My reply to the accepted answer explains how I resolved it. – McGuireV10 Jan 31 '18 at 21:05
  • I have a similar situation. ODM domains are a better solution because I can store the domain in EXCEL file, which mean the business people can do changes and deploy WITHOUT any help from the IT department :) That is the main benefit of ODM to the enterprise.... do as much as possible without writing any Java code. – John Henckel Jun 17 '21 at 19:13