5

I have been tasked at work with implementing what I can only refer to as a rule interpreter. Part of my job is to identify production errors as they occur with shipment codes, and we are looking to make this process more streamlined with a user-friendly GUI so we can eventually offload the responsibility to another department. I can handle the GUI part pretty easily, but i've never written anything quite like this before.

Here's the broad strokes of the situation:

  1. We have a number of clients. Each follows the same processes for everything but the assignment of codes to shipments. Each client has their own rules for doing this.
  2. Each rule is represented by a SQL statement in a stored procedure. We also have the rules documented in plain english.
  3. Each rule has a validation file associated with it, and a key generated from the package's information (For example, the carrier and an account number), so the individual shipments always know their own keys to the validation files.
  4. Each process also has their own rules for determining if the shipment code is valid, usually expressed as the length of certain segments of the shipment code.

So, what we're trying to do is represent this outside of SQL. Is there a good design pattern for representing a set of rules that can be expressed in any order so we can make an application for verifying why errors occurred?

Here is an example set of rules:

  1. For each shipment, get the carrier, tracking number and account number.
  2. Use the carrier and the first four digits of the account number to determine the profit center for the shipment from the value file 2003-01
  3. Use the carrier + profit center to get the destination code from 2003-22.
  4. Finally, determine the accounting code by concatenating carrier + destination code + account number.
  5. Validate the code. It should be sixteen Alphanumeric characters. The package should have an 8 digit account number, and a 4 digit carrier code. None of the values used above should be blank.
  • Forget the rules for now, what is the main requirement, identify production errors as they occur with shipment codes depending on the client? How can you quickly tell if there is an error, by validating the shipment code that is stored somewhere? Steps 1 to 4 should be done automatically when your shipment is stored in the DB. – PmanAce Nov 18 '16 at 19:45
  • @PmanAce that is the case. However, when one of these rules is 'broken' somehow (ie there is no data found in the sql statement) the process quits and sends a generic email out. Management, in their infinite wisdom, has forbidden us from modifying the logic without a customer request, even to add internal-only stuff. I need to find out quickly which rule was broken. – Adam Wells Nov 18 '16 at 19:51
  • If you can modify the emails that are sent, you could parse the parameters passed to the sql statement and see if anything is missing and go from there. – PmanAce Nov 18 '16 at 19:53
1

It is complex, but you could create a rule language, a language in which you can express rules. I would do this only if you need to have people modify the rules without the help of a software developer.

Such a language would need logical (boolean) operators as well as "environment variable references"; such references refer to such things as "tracking number", etc. You may need other operators as well.

  • Creating a domain specific language is sometimes a good idea, but it's no guarantee that a person who isn't skilled at software development will be able to program effectively in the language. It does mean that it's likely to be easier at least for someone who isn't a software developer to read the rules in the custom language, if the language is well designed. – bdsl Jan 24 '17 at 0:30
  • Such a "language" does not need to necessarily be a proper language, with a separate parser, etc. A DSL-like API may suffice. OTOH a proper language, preferably of a completely declarative type, could be more approachable for business people. Consider giving them a way to express the rules using a spreadsheet; they'll be glad to use their main everyday tool. – 9000 Feb 22 '17 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.