Controlled Solving and Engine Adapters

English | 中文

Applies to DecisioWorks v1.4.0

Controlled solving and engine adapters: keeping algorithms aligned with the decision problem

A solver searches within variables, constraints, and objectives. It does not know why delivery matters, which tasks must remain stable, or who approved a shop-floor rule. engine_adapters translates DecisioCore business expressions into explicit GOCK calls and returns normalized status and result semantics.

Adapter responsibilities

• Select a planning or scheduling engine type.
• Assemble standard business objects into model inputs.
• Map structural constraints, objective materials, and explicit rules into the model.
• Validate thread counts, time limits, and other runtime parameters.
• Distinguish feasible solutions, proven infeasibility, no feasible solution found within the time limit, and license or runtime-loading errors.
• Restore model output to structures that the upper layers can analyze.

Run algorithms under explicit conditions

Controlled execution means every run has explicit input, objectives, rules, resource allocation, authorization scope, and final status. This preserves algorithmic capability while enforcing authorization and preventing arbitrary solver arrays from being interpreted as business conclusions.

Control points in a run

Phase	Control point
Before	Dataset readiness, engine type, objective direction, rule validity, resource limits
During	Request ID, action status, duration, cancellation or timeout
After	Candidates, selected solution and optimality status, result shape, objective direction, analysis material

Parameter limits

Thread count and maximum solve time depend on edition, license level, and runtime policy. The Web interface should show the permitted ranges and validate requests before submission. Reaching a time limit is not necessarily a system failure: a run may return a feasible solution with further improvement unfinished, or stop without finding a feasible solution. Those outcomes must remain distinct.

Upgrade models without rewriting the business layer

Stable actions and capability metadata isolate upper layers from model changes. When input and output specifications remain stable, new variables, solving strategies, or implementation changes can stay within the adapter and GOCK without requiring data integration, business workflows, and Web pages to be rewritten together.

Likewise, changes to shop-floor rules or management objectives should first enter the data, objective system, or rule control, then be mapped by the adapter. They should not require direct changes to the solver kernel.

Common mistakes

• Reporting time limits, infeasibility, and runtime-component failures as the same generic solving failure.
• Allowing the page to request more threads or time than the active license permits.
• Interpreting results in a direction opposite to the configured objective.
• Replacing the documented controlled runtime entry point with a temporary development entry point.
• Embedding customer-specific business rules directly in an engine adapter.

Continue with Runtime Status, Errors, and Limits and Objectives and Rule Control.