Logging and Tracing Dynamics AX MRP Runs

Understanding why software acts like it does can be an overwhelming task. There can be discrepancies between what we expect a program to do and what it actually does. The more complex a program is the more likely we are to experience these discrepancies.

Master planning (MRP) in Microsoft Dynamics AX is a prime example. Because it’s designed with a huge set of parameters that provide the flexibility required to fit a wide variety of businesses, configuring MRP is a complex task. And, historically speaking, the lack of transparency has made it difficult to analyze and understand the results of an MRP run by looking at its configuration. To provide this transparency, tracing and event logging functionality that gives a planner better insight into an MRP run has been added to Microsoft Dynamics AX 2012 R2.

Enabling MRP Logging and Tracing

The new logging and tracing features in MRP come in two flavors: One is purely a UI centered experience. The other ties in to the existing facilities for tracing and logging, and uses the Event Tracing for Windows (ETW) with the normal Microsoft Dynamics AX tracing providers.

Tracing/Logging in the UI

The UI centered experience is a powerful, light-weight tool that a planner can use to find out why certain choices were made during an MRP run, and to validate changes in an MRP configuration. A planner can quickly view the impact of a change when the dynamic master plan is updated. The Explanation tree view uses familiar UI elements, which makes it easier to use. In Figure 1 below, the requirement calculation is set to update an explosion for a production order (note that the Explanation tree view is available only for explosions). The setup for this requires only that the Enable trace check box is selected.

 

Figure 1

When the explosion is complete, information about the MRP run is displayed in the Explanation tab on the Explosion form. Figure 2 provides an example of what the explanation looks like.

 

Figure 2

A couple of things in Figure 2 are worth noting. First, the tree structure denotes the hierarchical nature of MRP. As can be seen from the tree, in producing the speaker enclosure (level 1), an issue is generated for which a receipt is sought. As none is found, a planned order is created (level 2). All of the details for the new planned order are listed and indented below the event – in this case the creation of a planned order. Additionally, the issue is pegged to the planned order, and at level 2 the initial futures date is set.

Another cool thing about the explanation is that you can perform a free text search. In Figure 2, for example, you could search for any lines that contain the word “delay.” If there are any hits, the text for the line is displayed in bold font. You can navigate between multiple hits by using the Up and Down arrows that are next to the Find text field.

Tracing/Logging of MRP Runs using Event Tracing for Windows (ETW)

While the tracing and logging experience in the UI is targeted towards the planner, the tracing and logging that uses ETW is geared more toward offline diagnostics scenarios. Using the offline capabilities requires the steps that are described in this section. Also, whereas the Explanation tree view is available only for explosions that are started manually to update the dynamic master plan, the ETW tracing is also available for generating full master plans.

First you must set up a data collector set by using the Performance Monitor utility. The steps to do this are as follows:

1. Open Performance Monitor.
2. Right click the User Defined node in the tree view, point to New, and select Data Collector Set.
3. Give the collector a meaningful name, like Dynamics AX MRP Trace.
4. Select the Create manually (Advanced) option, and click Next.
5. On the next step of the wizard, verify that the Create data logs radio button is selected, and then select the Event trace data check box. Click Next.
   Note  To avoid generating a lot of data that is not related to MRP tracing, you may want to clear the other check boxes.
6. You must now select the data providers. Do this by clicking the Add button.
7. In the dialog that appears, select Microsoft-DynamicsAX-Tracing, and then click OK.
8. After the provider is added, the Properties field displays properties related to the provider. In the list, select Keywords(Any), and then click Edit. On the list of properties that comes up, select MRP. Click OK to exit the Property dialog. In the wizard, click Next.

   
   Figure 3
   

9. On the next step of the wizard, specify where you want to store the tracing data, and then click Next.
10. On the final step of the wizard you can either change some selections or click Finish to accept the defaults.

You can verify that ETW has started collecting the tracing data by clicking the new collector set (in the example, it’s “Dynamics AX MRP Trace”) and then looking at the icons on the toolbar.

Let’s take this functionality out for a spin by doing the explosion again. The same information that was displayed in the UI in the example is now available to a multitude of tools via the data collector. For instance, you can use Event Viewer to open the log file that the data collector creates, and you can export the data to Excel or to a database for further analysis. Let’s look at an example of what the data looks like in the Event Viewer.

To view the data, start Event Viewer. Right-click Saved Logs, select Open Saved Log and navigate to the location where you store the log data. The file should be called DataCollector01 or something similar, depending on how many data collector sets you defined. After selecting the data collector, you’ll be prompted to decide where the log data is to be displayed in the Event Viewer tree – I usually just select the default.

Since the collector we defined is collecting all data related to MRP, there will be a lot of events logged. In my particular case, the number of events is around 9,500. Fortunately, you can filter by clicking the Filter Current Log in the Actions pane on the right hand side of the Event Viewer. In this context, the two events of interest are:

• 107 (This will be referred to as ReqExplanation)
• 108 (This will be referred to as ReqExplanationDetail)

You can specify multiple events in the filter dialog by separating them with commas. Using the filter to limit the number of events in the view leaves around 650 events from my MRP run.

The first of the event types, ReqExplanation, is shown below in Figure 4 below.

 

Figure 4

The following table describes a couple of interesting pieces of information that the event log gathered during the MRP run.

Message	This is the message that would be displayed in the Explanation tree view.
Trace ID	Each trace has a unique identifier that all events relate to. If you run MRP multiple times in a data collector session, the trace ID lets you identify the events that belong to each run.
Event ID	This is the unique identifier for the particular event. As you’ll see shortly, this is used to tie together related events in the MRP run.
Plan Version	Version of the plan in which the records were created.
BOM Level	The level of the BOM that is being examined by the MRP scheduling.
Req Level State	Indicates the state for each level while in the master planning run.
Req Process Status	Scheduling process status.
Sequence	The sequence number of the event, so that events can be ordered chronologically.
Item ID	The item that is being examined.
ReqTransRefId	Reference to the ReqTrans to which this message relates.
Message Type	The type of message that is being logged. This allows for filtering of message types in a locale independent way.

 

The second type of events logged, a ReqExplanationDetail, is shown below in Figure 5.

 

Figure 5

 

Message	As for the ReqExplanation event type, this is also displayed in the Explanation tree view.
Trace ID	The unique identifier of the trace.
Event ID	The unique identifier of the event.
Parent Event ID	The unique identifier of the parent event that the detail relates to.
Sequence	The sequence number of the event, so that events can be ordered chronologically.
Message Detail Type	Type of message detail being logged. This allows for filtering of message types in a locale independent way.

 Looking at Figure 4 and Figure 5, one major difference between the Explanation tree view and the ETW stands out. While the Explanation tree view graphically shows the BOM levels that were considered during the MRP run, that cannot be done graphically if you use ETW. To doing this by using the data from the ETW, you’ll have to examine the sequence and BOM Level fields in the data. Also, a detail event (108) is tied to its parent by the Parent Event ID field (incidentally, the two examples shown here are parent/child as the Parent Event ID of the ReqExplanationDetail (shown in Figure 5) matches the Event ID of the ReqExplanation (shown in Figure 4).

So, What’s the Cost?

Obviously, cool features like this are not entirely free of charge. We have, however, done our utmost to limit the impact that this will have. First, the Explanation tree view is totally independent of the ETW logging. That is, you can have ETW logging for explosions and full master plans without enabling the Explanation tree view. Conversely, you can enable the Explanation tree view without having the ETW logging enabled.

Because of the nature of the two independent logging and tracing methods, we check in a couple of ways to ensure that we don’t spend cycles doing unnecessary work. For instance, since the ETW tracing is governed solely by enabling a data collector and the MRP keyword, before we do an explosion or master plan generation we check whether the required ETW setup steps have been completed. Based on this check, we minimize the impact during the explosion or when the master plan is generated.

This is simpler for the Explanation tree view: If you don’t enable tracing when you start an explosion, we keep that in mind when doing the explosion and thereby minimize the impact of the feature.

If you do decide to enable the ETW logging for a full master plan generation, there will be some cost related to generating the necessary messages to log. Despite the fact that the ETW was designed with huge volumes of events in mind, you should expect to see some degradation of performance. This, however, we think is acceptable as the feature is a diagnostics feature, and not meant to be switched on and left on, but only switched on while the diagnosis is going on.

Wrapping up this post, I think you’ll find great value in the functionality we have added to assist you in understanding choices/decisions made by the MRP subsystem. Finding the right configuration and set of parameters for master scheduling that are exactly right for your business is difficult. With the tracing/logging, we believe we have made that task a lot easier for you.