The Workflow Simulator (WFSimulator) allows you to test various types of workflows without an Operations Manager management group. This helps speed the testing and debugging of your management pack by letting you see the raw XML output produced by your workflows, as well as enabling tracing to view the trace statements from the modules loaded in your workflow.
For the WFSimulator to work properly, you must install the Operations Manager 2007 R2 agent on the computer on which you are running the Authoring console and the ResKit tools. To install the agent, run the MOMAgent.msi which you can find on any Operations Manager 2007 R2 management server under AgentManagement\<CPUArchitecture>\MOMAgent.msi. Given the default installation for the 64-bit Authoring console and ResKit tools, you will find it here: %ProgramFiles%\System Center Operations Manager 2007\AgentManagement\amd64\MOMAgent.msi.
The agent does not need to be running when you use WFSimulator. Shortly after installing the agent, you can stop and disable the agent in Services.msc; simulating will still succeed.
The following types of workflows are supported by the WFSimulator:
- Agent Tasks
Running Workflow Simulator
In the Authoring console, open a management pack that has one of the supported MP items that WFSimulator can simulate.
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
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.
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.
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
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).
Click Start Simulation.
Note This topic will not cover actual debugging and tracing of all modules and workflows.
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.
To stop, click Stop Simulation.
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.To debug scripts
Select the Debug scripts check box.
Click the Start Simulation button.
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.
When you have chosen your debugger, it will be attached to cscript.exe and you will be able to step through your script.
Showing Module Composition
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:
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
- 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.