Configuring an Engine Using Scenarios
An Engine Scenario is a good place to put all the configuration options that would overload the UI but don’t belong directly on master data. For example, your engine may support daily, weekly, and monthly bucketization. You could put this on the enterprise model but how many engines, modules, etc.. would also place configuration onto the enterprise model. Soon the enterprise model would be overloaded. Instead, if an engine has a scenario and the scenario contains the bucketization then the user configuring the system would have to create a scenario and set the bucketization. The user running the engine only needs to select the scenario. The scenario selector would only show the user the scenarios for the correct engine and that he has access to (he won’t see scenarios for other enterprises for example). If the scenario has a good clear name, then the engine user has nothing to fear. Choose the right scenario then they will be sure it will use the right bucketization.
A secondary benefit to scenarios is that other systems can use an engine’s scenario. For example, a PIV may wish to know how Replenishment will deal with late orders. If the PIV developer uses an org or enterprise policy that can identify the name of a scenario. And the person configuring the org or enterprise uses the same scenario in the PIV Policy they do when running Replenishment then both will deal with late orders in the same manner.
Anti-Patterns
Scenarios need to be given good clear names to instruct users when to use them. This is more of an implementation detail than development – but the pain is clear. Ambiguous names leads to the wrong scenario being used which leads to incorrect results.
Scenarios must NOT contain options that the user must not select. If a setting an engine to run for 10 years and create a data point for every minute for those 10 years and that will cause the system to crash, then the scenario shouldn’t have allowed these combinations.
Scenarios must NOT contain references to Model Names, Class Names or other things they would not understand. Often times, Scenarios for older engines draw on old IXM Engine Configs where they might refer to SCC Enhanced Order. Or they may refer to class name for a cheap way of providing extensibility. Capping module writes a CreateOrder class and then you add parameter to identify that class. It’s flexible but not appropriate for an end user.
Best Practice
Scenarios are first class Models and should be treated as such. They need a nice tailored UI with an inbound interface. A UI upload/download is nice. Custom dynamic enumerations so the user can see nice tailored options.