Alternative Decision Structures using included function libraries

referenced from Transportation Scheduling approach 4

• If the various function decision tables are defined in a separate library we could define the scheduling decision with a simple DT that invokes the functions.
• By default any dependencies on objects in included libraries are not shown (otherwise the diagram could get cluttered).
• Optionally you can display these dependencies if required.

Option 1 Inputs and Outputs explicitly defined as objects

• A single decision table invokes the optimize function which in turn will invoke all the other functions.
• In this example the decision has no knowledge of where the input data is coming from or where the output data will go.
• The caller of the decision must handle that.
• This makes the decision easier to use but requires the caller do more work to prepare the data.

Option 2 Inputs and Outputs specified as Functions (rather than objects)

• The source of the data is defined in the decision input specification section so the caller of the decision does not need to know where the data is coming from.
• The author of the individual tables also does not need to know where the data is coming from.
• The decision is now very closely bound to a specific database
• The person creating and deploying the data access functions would need to know the source of the data.
• Functions or microservices need to exist to handle the data retrieval logic.

Option 3 No Explicit Inputs or Outputs - Data read/written using functions inside decision tables

• In this example the rule author has complete control over which tables and records are retrieved.
• This makes the decision entirely self contained but does require the rule author have more technical knowledge.
• The decision is now very tightly bound to specific tables and queries.
• Functions or microservices need to exist to handle the data retrieval logic.

NOTE: another option would be to pass in the SQL queries as input strings - this would give the caller some flexibility over which records are processed by the decision.

Option 4 Database Query Strings passed as Inputs

• The caller would need to supply these query strings.
• The rule author doesn't need to know the source of the data.
• Functions or microservices need to exist to handle the query strings.