If you are interested in learning more about improving schedule engine performance using Microsoft Dynamics 365 for Supply Chain Management, contact us here to find out how we can help you grow your business. You can also email us at info@loganconsulting.com or call (312) 345-8817.
Use Dynamics 365 Supply Chain Management to Improve Scheduling Engine Performance
Posted on: August 31, 2022 | By: Guy Logan | Microsoft Dynamics AX/365, Microsoft Dynamics Manufacturing
Microsoft Dynamics 365 Supply Chain Management’s resource scheduling engine feature is used when scheduling routes for planned and released production orders. This feature might get a little complex as solution time grows exponentially when there is an increasing number of decision variables. This blog will give you a general understanding of the scheduling engine and how a specific setup can have influence on the performance. For further help or information on the resource scheduling engine feature in Dynamics 365 Supply Chain Management, please reach out to speak with one of our knowledgeable Senior Consultants at Logan Consulting.
When it comes to improving the performance of the scheduling, general guidelines recommend reducing the complexity of the problem the engine needs to solve. Some of the main factors that can affect performance include:
- Routes with many operations
- Routes with parallel operations
- Operations with quantity of resources higher than one
- Operations with many applicable resources
- Use of hard links
- Use of finite capacity
- The number of different calendars used
- The number of working time slots per day in the calendar
- Total duration of the route
- Running multiple scheduling engines in parallel
Overview of basic scheduling flow
To understand how a given setup can affect performance, it is important to understand something about how the process flows, both inside the engine and in the X++ code that surrounds it.
The basic process of scheduling an order consists of three main steps:
- Loading data – Here, the X++ data models are transformed into the engine’s internal data model in the form of jobs and constraints.
- Scheduling – This is the main source for scheduling that processes the given model and constraints, and generates a result. During this process, the engine will request working time information and existing capacity reservations from X++ as needed.
- Save data – The engine result in the form of job capacity reservation slots is processed by X++ code to save capacity reservations and update the start and end times of the jobs/operation/order.
Load data into the engine
The scheduling engine has a more abstract data model than the Supply Chain Management database because it has been built as a generic engine that can handle different sources of data. The concepts of route, secondary operations, and run time need to be “translated” into the generic job and constraint model that the engine exposes. The logic for building the model has a significant amount of business logic to it and is different depending on the source data. The responsible X++ class is WrkCtrScheduler and it has derived classes for planned production orders, released production orders, and project forecasts.
Scheduling engine internals
Scheduling engine interface
To get an idea of how the engine works internally, it is best to look at the functionality it exposes externally. In X++, the main interface is WrkCtrSchedulerEngineInterface.
Solver
The engine itself is essentially a specialized constraint solver with custom heuristics added. The solver is based on two main elements: variables and constraints.
Variable
A variable represents a domain of possible values. Scheduling engine has two types of variables:
- DateTime variable – Has a domain of all dates and times, and the domain can be restricted by moving the lower and upper bound for the time of the variable closer to each other.
- Resource variable – Has a domain of applicable resources, and the domain can be restricted by eliminating resources from the list.
Constraint
A constraint acts on variables by restricting their domains, but it also depends on variables, so it gets activated when variables change. The process of “constraint propagation” is when a constraint performs its main function and reports back to the main logic if successful.
A variable is considered bound when it can’t be restricted further, which for DateTime variable means that upper and lower bound is the same, and for the Resource variable that it has only a single applicable resource. When all variables are bound, a solution is found.