This topic references the following Activities:
Try
Activity: Try-catch exception
The workflow starts with a Try-catch exception activity. The purpose of this activity is simply to act as an error-catching container. If any activity inside the Try-catch exception activity errors with an unhandled exception, the Try-catch exception activity will catch the error and execute the activities under the Catch branch. In this case, if an error occurs, the error will get logged to the active workflow log using the LogError logger activity.
For this activity, we do not need to specify any input or output properties. We simply ensure that activities that we want covered by this activity are placed inside the Try-Catch container, nested directly below the node named Main.
LogError
Activity: Logger
If the Try-Catch exception activity encounters an unhandled exception, the Catch statement runs and logs the error.
The Logger activity will write an entry into the workflow log for the executing workflow. Note: This assumes that logging was enabled when the workflow was deployed.
The activity only requires one property to be specified which is the text to output into the active log. This can be specified as an Initial Value or as a Runtime Expression.
In this example, the following output is output using the Initial value:
"The following error has occurred: " + Catch.ExceptionMessage
We use Catch.ExceptionMessage to retrieve the error text from the exception that was generated which is contained within the Catch activity.
WmiConnect
Activity: WmiConnection, Operation: Connect
The first activity inside the Try-catch exception is a WmiConnection activity called WmiConnect. The purpose of this activity is to form a connection to a WMI namespace. We need to connect to the namespace root\cimv2 in order to query the operating system caption from one of that namespace's classes (Win32_OperatingSystem).The WmiConnection activity has two operations; Connect and Disconnect. After choosing Connect a new input property appears for us to specify the NameSpace. Here we are specifying an initial value of:
root\cimv2
We could also pass this through as a runtime expression. We would normally use a runtime expression if the namespace was dynamic and being brought in from an input property or from the result of a previous value. We could also hard-code it in this box as well enclosed in double-quotes (i.e. "root\cimv2").
WmiQueryWin32OS
Activity: Wmi, Operation: Execute Query
After establishing a connection to the namespace, it is then possible to obtain data from Wmi using the Wmi activity. The Wmi activity supports many different operations such as executing a query, retrieving a single instance (Get instance) creating an instance (Create instance), checking if an instance exists (Does Instance Exist), deleting a class (Delete Class) or deleting a specific instance using a path (Delete Instance Using Path). In this example workflow, the Execute Query operation is used to run a WQL query against the root\cimv2 namespace that we connected to previously.
After selecting Execute Query two input properties are available - WmiConnection and Query.
The WmiConnection property is a JAVA OBJECT data type and expects us to provide a runtime expression to a previous WMI connection. In the runtime expression builder we simply enter the Connection property from the previous WmiConnect activity (in the format [ActivityName].[PropertyName].
We enter: WmiConnect.Connection
The Query property is a TEXT data type and expects us to either type in or reference a previous text string that represents the WQL query that will be run against the WMI namespace (root\cimv2). In this example, the WMI class that should be queried to obtain the operating system caption is Win32_OperatingSystem, so for the Query property we enter an initial value of:
Select * From Win32_OperatingSystem
Note that when the Execute Query operation is selected, this activity is an iterative activity and will execute all contained activities for each WMI instance that gets returned by the query. Dragging an activity directly on top or just below the WmiQueryWin32OS will nest it inside. Any activities that should only execute once, such as the WmiDisconnect activity, should be placed outside of the WmiQueryWin32OS activity. Hovering over the WmiQueryWin32OS activity will show which activities are inside by drawing a box around all contained objects.
WmiGetValues
Activity: WmiInstance, Operation: Get values
The WMI query from the WmiQueryWin32OS activity above will execute and retrieve all WMI instances resulting from that query. The WmiGetValues WmiInstance activity will be used to store the results of that instance. The WmiInstance activity supports multiple operations including Get values which retrieves defined WMI properties from the specified instance, Set values which will set the specified property values in WMI, Delete instance which will remove the specified instance from WMI, Put instance which will add or update an existing instance to WMI and execute method/execute static method which can be used for calling a WMI method. For this example workflow, the Get values operation is used.
The only built-in property that is required for Get values is the WmiInstance which is a JAVA OBJECT data type and requires a runtime expression pointing to the previously retrieved WmiInstance property of the WmiQueryWin32OS activity. This is specified in the format [ActivityName].[PropertyName].
WmiQueryWin32OS.WmiInstance
In addition to the WmiInstance, the actual desired output properties of the WMI instance need to be added. These are added as User defined properties. In the case of the example, Win32_OperatingSystem contains many properties, but we are only interested in one - Caption.
We therefore just add one user-defined property called Caption. Because Caption is a text string, it is added as a TEXT data-type user-defined property.
Note: WHOLE NUMBER/FRACTIONAL NUMBER can be used for storing respective numeric data types, BOOLEAN for true/false etc.
The name of the WMI instance property must match exactly with the name of the user-defined property created, but is not case-sensitive.
For cases where a property needs to be retrieved that matches the name of a built-in property (such as Name or Description), a lower-case alternative must be used so as not to conflict.
i.e. to retrieve a WMI property called Name, create a user-defined property called name (note the lower-case n)
At this point in the workflow, a connection has been established to WMI, a query has been run against Win32_OperatingSystem to retrieve all instances and the Caption value from the retrieve instance(s) is stored in the Caption user-defined property. This caption can then be used in subsequent workflow activities.
IfValuesFound
Activity: If-Else
The workflow then checks to see whether the caption was queried successfully. To do this we use an If-Else statement to evaluate a logical condition. In this case, we evaluate the Caption value previously stored in the user defined property of the WMIGetValues activity. We use two conditions joined with double-ampersand (&&) to check firstly that the value of Caption is not null (meaning no value has been stored in Caption property due to query failure, no instance etc.) and secondly that the value of Caption is not an empty string, meaning it was queried successfully but the value was blank.
The expression of the If-Else statement is:
WMIGetValues.Caption != null && WMIGetValues.Caption != ""
Note: we use != to mean 'not equal'. The inverse of this would just be a single equals sign (=) to check if the value was equal to null or empty string.
Depending on the evaluation of the If-Else condition depends on whether the workflow proceeds down the Found (TRUE) or NotFound (FALSE) path.
LogCaption
Activity: Logger
If the If-Else condition evaluates to TRUE (the Caption was queried successfully) then we want to output the Caption to the log.
The Logger activity will write an entry into the workflow log for the executing workflow. Note: This assumes that logging was enabled when the workflow was deployed.
The activity only requires one property to be specified which is the text to output into the active log. This can be specified as an Initial Value or as a Runtime Expression.
In this example, the output WMIGetValues.Caption is output as a runtime expression.
LogNotFound
Activity: Logger
If the If-Else condition evaluates to FALSE (the Caption could not be queried or was queries successfully but just contains an empty string) then we want to output this message to the log.
The Logger activity will write an entry into the workflow log for the executing workflow. Note: This assumes that logging was enabled when the workflow was deployed.
The activity only requires one property to be specified which is the text to output into the active log. This can be specified as an Initial Value or as a Runtime Expression.
In this example, the following output is output using the Initial value:
Caption not found in WMI
WmiDisconnect
Activity: WmiConnection, Operation: Disconnect
The final thing left to do is to perform housekeeping and disconnect the WMI connection that was formed at the start of the workflow. We use another WmiConnection activity but this time we specify the Disconnect operation instead of Connect.
Specifying Disconnect gives us just one input property Connection which expects a JAVA OBJECT representing the open WMI connection. Here we specify the Connection property of the WmiConnect activity that we setup at the start.
WmiConnect.Connection
After disconnecting the WMI connection, the workflow exits out of the Try-catch exception statement and ends.
Full Workflow:
The workflow used in this example can be downloaded from the link below.