The IXM Engine Configuration is a Value Chain level configuration for an engine. It has limited UI capability (due to permissions) and should be limited to configurations that a user should not see – or even desire to see.

All engines must have an entry in the IXM Engine Config. Engines are identified by a tuple: Module prefix, Engine Name, and Config name. The configuration has a field that holds a JSON string of parameters. Absence of a valid entry in this table will result in the engine not operating.

<ModelList xmlns="http://www.onenetwork.com/Platform">
<ValueChainId>8001</ValueChainId>
<CustomModelName>Standard IxmEngineConfig</CustomModelName>
<ActionName>PLT.InsertOrUpdate</ActionName>

<IxmEngineConfig>
<ValueChainId>8001</ValueChainId>
<ConfigName>Default</ConfigName>
<ModulePrefix>OMS</ModulePrefix>
<EngineName>OrderSourcingEngine</EngineName>
<EngineConfigParams>
{
"DumpData" : false,
"AggregateEnhancedOrderWithSameDetails" : false
}
</EngineConfigParams>
<DefaultThreadCount>1</DefaultThreadCount> 
<TaskMaxRunTimeMillis>3600000</TaskMaxRunTimeMillis>
<TaskMaxAttempts>3</TaskMaxAttempts>
</IxmEngineConfig>

Anti-Patterns

Too many parameters in the engine config: Similar to having too many UI parameters overloading the end user, having too many engine config parameters can overload the production support team. When there are 30 entries and one is supposed to be true but is false, it is very difficult to find.

Parameters that a user would want to control: The Engine Config is a VC level construct. Very few users have access to this level of data, and those users are never concerned with an engine configuration.

Best Practices

Some engines are naturally extended to solve several related business problems with the same code base. But when a user runs the engine, they only want to solve one of those business problems. The choice of extending one engine vs. writing a new engine is a development choice that shouldn’t impact an end user.

For example, Replenishment can do Demand Propagation, Supply Propagation, Both, or even be used to Allocate Orders. All of these follow the same basic process of reading a network and transactions, following supply and demand matching logic, and making a decision. The difference is only the nature of the decision. A good use of engine configuration is to create one configuration for each of these and then add a menu item for each. Then, the user can run an engine to do Demand Propagation, Supply Propagation, Both, Allocate Orders, etc. without ever knowing they are running the same engine.

Mechanical processes such as task generation techniques or the use of a truncate/insert strategy are good practices. Often an end user wants to manually run an engine for only a small subset of data while scheduled tasks want to run for the entire network. Mechanical choices like how to generate tasks or to use merge into statements or a truncate/insert would differ. Creating a UI configuration for a Chain configuration is good practice.

Technical Details

The IXM Engine Config table (loaded by IXM engine config XML in a dataset) tells the Platform how to set up a listener for an Engine. The listener is looking at the grid job table and ready to call the engine's factory for a task writer or task generator.

IXM Engine Config is organized by Engine Name, Module Prefix, and Config Name. The Engine Name and Module Prefix identify the actual IXM engine and is used to find the.IXM file in the module. This .IXM maps to a Factory. The Factory maps to Task Generator or Writer, provides JMX Console attributes, contains some preprocessing for UI inputs, and identifies the actual class to execute the task (often called "the engine"). Config Name allows there to be more than one Config per engine. When you see a Run Engine on the menu, it names all three of these to identify the precise engine config which in turn finds the right .IXM, which in turn finds the Factory, etc.

My Run Engine UI has no Parameters

While the .IXM file identifies the parameters to display on the UI, the IXM Engine Config is first referenced from the menu item. If it doesn't exist, then it won't (it could, but it's not coded that way) find the .IXM file and so it can't find the Config. In this situation, your Run Engine UI will only have the default parameter Start Time and nothing else.

ENGINE_CONFIG_PARAMS

Each Engine Config has a field for Engine Config Params. This is a JSON string of various name value pairs. Generally, the Engine Config Parameters have gone out of style in favor of Parameter or Scenario data structure OR the use of Attributes from SCC. Some engines may have NULL and often use the config name Default.

It is important to note that these can be changed while the system is running. The last update date will be in the past. The system will detect this and reload the configuration, and the next engine run will use the new settings.

But it is important to note that a NEW entry will NOT be read while the system is running. The platform will only start a new listener on the Grid Job table at startup. If there is no listener, then the engine will never run.

NOTE: The engine config is VC level configuration. This means any change applies to every enterprise in the network. This, along with the ability to easily create a UI for a custom config model, is why most engines moved away from this configuration.

Default_Thread_Count

On a given node, this is the number of threads that will be listening and able to execute the engine. If the number is 3, then as many as 3 concurrent threads can be executing the tasks for the engine. Generally, as problem complexity for each engine drops or the power of the app server increases, then this number can be increased.

Task_Max_Run_Time_Millis

This is the maximum amount of time the system will allow a task to run before it terminates. This should be long enough to allow the task to complete with plenty of time to spare. Generally 2x normal operation.

Task_Max_Attempts

This should ALWAYS be set to 1. The engine only fails if it can not complete in time or there is a significant error. It is unlikely to improve – a second or third run is rarely helpful. In fact it generally exacerbates a problem in that the tasks never seem to complete.

Task_Retry_Delay_Millis

This is the delay between retries. For engines, the Attempts should always be 1 so the delay between retries is irrelevant.

IXM Engine Node Config

This model links an engine config with a node (by its IP). This allows for the configuration to be altered by Node. This is generally only used for controlling thread count by node. For example, if you want only 1 type of engine to use a special server – you can set the thread count down to 0.

Instance Config

InstanceConfig.xml may also define some attributes for the tasks of an engine. Note that each of these are created during deploy so we can have settings in node.properites to persist the value per node (there is 1 instance config per node).

<Type>DPX_AlertComputation_ItemSubnetConfig</Type>

</TaskConfig>

Logical Idle Set Count is a special property that controls how the Platform controls the listeners when the number of threads per node increases at a large rate. Engines that have a dozen or more thread count need to make sure they work in lockstep rather than all cram the grid task table at the same time.

NOTE: Logical Idle Set Count was deprecated with NEO 3.3 with a dedicated thread poller provided by PLT.