I have created a Opalis workflow that checks number of active incidents related to a business service. If there are more the X (in my example 4) incidents active a problem work item will be generated. The problem work item will be assign to the problem managers Active Directory group.
The policy is divided into three parts. Part one will find the business service and active related incidents.Â
- Starts at 6 am every day
- Deletes the temporary file if it exists. The link after “Delete temp file” is configure to continue even if the “Detete temp file” activity fail, becurse there is no file to delete.
- Gets the business service, in my example “Contoso – Extranet”
- Gets related incidents to the business service
- Gets the incident workitem for each incident that is in relationship with the business service
- If the incident status is equals active, the policy continue over the link, else nothing more will happen
Part two will count number of active incidents and see if there are more incidents then the threshold. In my example the threshold is 4.
- Â If the status of the related incident in the first part of the policy is active, the GUID of the incident will be echo to a temporary file.
- The Junction activity is used to combine multiple threads to one. As multiple incidents can get back from “get related incidents” we need to make sure the rest of the policy is not ran in multiple threads, we use a junction activity for that. Â
- The combine activity is configure not to publish any data, that why we need to get the business service again. If we choose to publish data the policy might run multiple times and we dont want multiple problem work items.
- This activity count the number of lines in the temporary file
- Â Checks if number of lines in the file (number of active related incidents) are equal or more then the incident threshold
- If there are enough with related incidents the policy will move on
Part three will create a problem and assign it to problem managers. It will also link the problem to the business service and all the incidents to the problem.
- Created a problem work item with some dynamic text depending on the settings in the rest of the policy
- Link the new problem work item to the business service
- Query Active Directory to get the Problem Managers (in my example) security group
- Writes a platform even with the problem work item ID
- Assign the problem work item to the Active Directory group found in “Get Problem Managers from AD” activity
- Reads each line in the temporary file. Each line is a GUID of a related and active incident
- Link each active and related incident from the temporary file to the problem work item
The following two images show the problem work item created in Service Manager. Note that all incidents are related to the problem work item and that it is assign to problem managers.
To save some data processing you could move the “Get Business Service GUID” activity to the other side of “Compare Values” activity. Then you could not contact Service Manager a second time if there was not enough with incidents. The “Get Business Service GUID” result is used in the “Link Problem to Service” activity.
This export file have meet “mr Wolf” so it should not contain any unnecessary settings or objects.
You can download my policies here, 21 Problem Management clean, please note that this is provided “as is†with no warranties at all. Also please read this blog post about export and import of policies.
[…] Identify problems with Opalis and Service Manager […]
Great article! I think we will be implmenting this later today!
LOL! Nice one Jossan 🙂 Maybe you should sneak into the next Opalis course your company deliver 🙂
I can’t get this to work, it seems to fail somewhere between step 5 and 6, is this a april fools joke?