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:
- 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.
- Each rule is represented by a SQL statement in a stored procedure. We also have the rules documented in plain english.
- 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.
- 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:
- For each shipment, get the carrier, tracking number and account number.
- 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
- Use the carrier + profit center to get the destination code from 2003-22.
- Finally, determine the accounting code by concatenating carrier + destination code + account number.
- 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.