1. In the Authoring console, open a management pack that has one of the supported MP items that WFSimulator can simulate.

2. In the Action pane, click Simulate.

   In the simulator window, you’ll see a Warning icon and tool tip for the Target Expressions field. This means you need to supply some default values to simulate this workflow. Normally, this is done at Runtime and the values are supplied by the Health Service

3. Expand the Target Expressions field. In many cases, workflows need GUIDs for certain values like $Target/Id$. The fly-out next to the Target Expressions field will generate a GUID for the expressions that require it.

   1. If this MP was already imported into a Operations Manager system that you have access to, you can resolve the target expressions to values that are in that Operations Manager database by using Resolve $Target/…$ via RMS. You will be prompted for credentials, if required, and it will automatically attempt to find valid values to populate the remaining expressions.

   2. If this MP was not imported into a management group, you can manually populate the remaining expressions. These settings are stored so when you open the workflow again for simulation, the settings will be set to the last settings used. If you want to clear all or any individual setting, you can do this from the same fly-out and choosing Reset $Target/…$ expression

4. You can change the overrideable parameter in the Overrideable Parameters field. You may want to do this to change the frequency or other exposed configuration to reproduce a problem (e.g. time-out is too short).

5. Click Start Simulation.

   Note
   This topic will not cover actual debugging and tracing of all modules and workflows.

6. In the bottom window, you’ll see each module that is executed, when it was executed, and a small summary for each line. Click a module in the bottom window to view the XML output of that module in the right pane. Depending on the modules, the XML output will differ, but allow you to see what values are gathered or processed by each module in the workflow.

7. To stop, click Stop Simulation.

8. You can save the output to an XML file by right-clicking in the lower left pane and choosing the Save output to file option.

Tracing enables you to see the XML output in the WFSimulator and to configure viewing the trace output of individual modules or the whole workflow. To enable tracing, right-click in the lower left hand pane under the Start Simulation and Stop Simulation buttons. You will have 2 options which have the following behaviors:

• Enable tracing for the whole workflow
  
  This is the only option enabled if you have not yet simulated this workflow.
  
  When choosing this option, all traces from all modules that are part of that workflow are shown in a separate window when you click Start Simulation. This option is also available after you’ve simulated a workflow. You will need to restart simulation for the Trace View window to appear.
  
  Example: If you have an event collection rule that is composed of an event data source, a filter condition detection, and an alert generation WriteAction, you should see traces of the incoming event from the event data source, details about how that event data is processed by the Expression Filter, and whether or not it matched the rule criteria.
  
  
• Enable tracing for this module
  
  Similar to tracing a whole workflow, this allows you to view the traces for a specific module in a workflow. If you are having problems or troubleshooting a specific thing (e.g. if your filter matches), you can choose this option after you have simulated the workflow at least once.
  
  After you simulate the workflow, If you find that no output is shown in the right pane, right-click the module that has no data and click Enable tracing for this module. Click Stop Simulation (if you haven’t already), then click Start Simulation to restart the simulation. The Trace Viewer window will open and you will see the traces for just that module.
  
  

Selecting the Debug scripts check box next to the Stop Simulation button will trigger the Just-In-Time debugger to launch so you can select a debugger if one is registered. If you do not have a debugger installed, this process will fail.

Debug scripts will only work for workflows that have a module type that uses a script. This is the equivalent of running your script at a command prompt using cscript.exe and choosing the “//x” option to launch the script under the debugger.

1. Select the Debug scripts check box.

2. Click the Start Simulation button.

3. If your workflow has a script, you will see a pop-up asking you to choose your debugger (for example, Visual Studio Express or the Web Script Debugger from Microsoft Office.)

   A Command Prompt window also opens with the title MOM Batch Response. This window will have no output, but this is expected.

4. When you have chosen your debugger, it will be attached to cscript.exe and you will be able to step through your script.

A third option in the context menu is Show Module Composition. By default, only the outermost member module is shown in the Module column. If that module is a composite—which a majority of modules are—the column will display a string notation of that module where:

• The outermost module in the Member Modules section is the first module ID followed by a backslash (“\”).
  
  
• The next inner composition ID is shown, again followed by a backslash (“\”), and so forth.
  
  

For example, you see the following after simulating a discovery which is composed of a registry probe, a filter condition detection, and a discovery mapper:

• Line1: DS\DS\Scheduler\DS1
  
  
• Line2: DS\DS\Probe
  
  
• Line3: DS\Mapping\Filter
  
  
• Line4: DS\Mapping\Mapper\Mapper
  
  

Because all discoveries have only one data source, DS is the first module ID in all lines. DS is composed of 2 module types: another data source module whose ID is also DS, and a module whose ID is Mapping.

• The second inner DS is composed of 2 additional modules: Scheduler and Probe. Scheduler is further composed of one module whose ID is DS1.
  
  
• The Mapping module is composed of 2 additional modules: Filter and Mapper. Mapper is further composed of one module whose ID is also Mapper.
  
  

A tree representation of this where the outermost module is at the top and each child tree item is a composition of the <MemberModules/> element in the MP XML would be:

• DS
  
  
  • DS
    
    
    • Scheduler
      
      
      • DS1
        
        
    • Probe
      
      
  • Mapping
    
    
    • Filter
      
      
    • Mapper
      
      
      • Mapper
        
        

There are a few limitations that may prevent you from simulating:

• When tracing is enabled, Administrator rights are required. You will receive a UAC prompt on Windows Vista and higher.
  
  
• If there is no output in the Data Column and the results pane on the right side, you should enable tracing to view the output of that module or workflow. The most likely condition is that the expression or criteria for that module is not met, so it doesn’t output any data item.
  
  
• Write actions are not supported and are removed from the workflow before simulating. That means you will not see the Alert Data Item XML in the right pane.
  
  
• Certain modules like Group Calculation will require access to a database and root management server because this module queries data out of the database.
  
  
• There is no validation of the Target Expressions or Overrideable Parameters. An example of one is where the user types "foo" in the CheckStartupType field in the Overrideable Parameters section.
  
  
• CheckStartupType expects an xsd:string. The configuration value supplied for CheckStartupType is not a valid Overrideable Parameter. Check the xsd type for this configuration and provide a valid value. For example, you may have an Overrideable Parameter named IntervalSeconds that expects a numeric value (xsd:int), but a string value was entered.