Archive for Uncategorized

When defining a request offering you have the option to add different prompts used to collect information from an end user. One of the prompts available is the Query Result prompt type. A query result prompt is a control that can list the result of a query executed against the Service Manager CMDB so that a user can select resources from that list as input when making a request or when reporting an incident.

If you choose to add a query result prompt you’ll need to configure it as well. In the configuration you’ll describe which kind of objects you want to query for, which criterias they should fulfill and which data to show in the table that lists the result. One of the final options you’ll have is to choose if you want to add the selected items as either “A related item” or “An affected configuration item” (as seen in the picture below.

Now let’s say you want to add the selected objects as something else, maybe even using one of your custom relationship types?!

As it turns out, this can easily be achieved by editing the MP where you stored your request offering and doing a small modification to the XML. If open the MP you’ll find a section called “RequestOfferings”. In your request offering (use the Title attribute to make the identification of a specific request offering easier), you’ll find a section called “Targets”. Depending on which checkboxes you selected in the UI, the content of the Targets section will differ. If you’ve checked both options, as in the picture, it contains the following two targets:

<Targets>
 <Target Path="" OutputName="$InstanceValue$" RelationshipId="D96C8B59-8554-6E77-0AA7-F51448868B43" />
 <Target Path="" OutputName="$InstanceValue$" RelationshipId="B73A6094-C64C-B0FF-9706-1822DF5C2E82" />
</Targets>

If you want to add custom relationship types as targets, it’s just a matter of copying one of the existing ones and changing the relationship id to match the relationship you want to use.

Tip: To add another target you’ll need to find get the relationship id of the relationship you want to use. This can easily be done using smlets (http://smlets.codeplex.com). Using smlets, just run the following command:

PS> Get-SCSMRelationshipClass|ft Name,DisplayName,Id

Below is an example where I’ve added two custom relationships as targets.

<Targets>
 <Target Path="" OutputName="$InstanceValue$" RelationshipId="D96C8B59-8554-6E77-0AA7-F51448868B43" />
 <Target Path="" OutputName="$InstanceValue$" RelationshipId="B73A6094-C64C-B0FF-9706-1822DF5C2E82" />
 <!--Custom Target Max Cardinality 2147483647-->
 <Target Path="" OutputName="$InstanceValue$" RelationshipId="53287fcd-8797-3cb5-2014-7deb12a2ed8d" />
 <!--Custom Target Max Cardinality 1-->
 <Target Path="" OutputName="$InstanceValue$" RelationshipId="5d3e92c4-ded5-013f-e6b5-ca6f8967e672" />
</Targets>

In my request offering i list users from the CMDB. When the request is submitted a new Service Request is created and the selected user (in this case Patrik Sundqvist) is related to the request through both of the standard relationships as well as two custom ones. In the picture below you can see that four of the relationships added during the creation of the request comes from the query result prompt, these are underlined. The two that has a solid line is the standard ones (added when you check the checkboxes in the UI), the dotted lines shows the two custom relationships that I added as targets in the MP directly.

Note that the Path attribute of the Target defines which component in the type projection that should act as Source the relationship that is going to be established. If Path is empty the seed class e.g. the service request will be the source of the relationship.

You can download an example mp here which contains a couple of custom relationships and a request offering with customized query result prompt targets.

Categories : Uncategorized
Comments (2)
Jul
01

Competing workflows

Posted by: | Comments (0)

When using an AddRelationship or RemoveRelationship trigger to fire of workflows in Service Manager you might end up with an unwanted scenario of competing workflows.

Let’s say that you implement a rule that subscribes to relationships being added between a work item and configuration items (such as “configuration items to change” in a change request). The normal behavior after implementing this would be that multiple workflows where fired if multiple configuration items where related to the change request at the same time.

The behavior above is good if you want to do something specific with each configuration item being added to a change request. In certain scenarios though you might only be interested in firing of one workflow when relationships are added (or removed), no matter the amount of relationship changes being committed to the Service Manager database. If this is the case, you could end up with multiple workflows competing to finish of the same task.

Say you want to do something to a change request as soon as a (any) configuration item is added to the change request through the “configuration items to change” relationship. In this case, you only need one workflow to fire of, no matter how many configuration items were added in the transaction (commit). In scenarios like these the “top secret” BatchSize value of subscriptions comes into play. After some digging around I found that the value of BatchSize parameter actually limits the amount of write actions being executed based on a subscription (per poll). This effectively means that setting the BatchSize value to 1 will make sure that only one workflow (write action) is executed even though the condition of the subscription rule was fulfilled by multiple objects.

The MP xml below comes from a management pack where I’ve changed the BatchSize to 1 to fire of a single workflow when a configuration item(s) is added to a change request. The workflow in this specific case was used to add a special activity to all change requests which has one or more “configuration items to change”. The workflow would start with checking of the special activity had already been added, if not it would add the activity. This way, if a previous workflow has already added the activity, the following workflows (triggered by new configuration items being added) would abort at a very early stage, perfect! But if the BatchSize hadn’t been tuned to 1, adding multiple configuration items to the change (where no “configuration items to change” had previously been added) at the same time, would cause multiple workflows to fire of. All of them would think that they were first and they would end up competing for adding the special activity.

<DataSource ID="DS" TypeID="SystemCenter!Microsoft.SystemCenter.CmdbInstanceSubscription.DataSourceModule">
 <Subscription>
  <RelationshipSubscription RelType="$MPElement[Name='WorkItem!System.WorkItemAboutConfigItem']$" SourceType="$MPElement[Name='WorkItem!System.WorkItem']$" TargetType="$MPElement[Name='System!System.ConfigItem']$">
   <AddRelationship />
  </RelationshipSubscription>
  <PollingIntervalInSeconds>30</PollingIntervalInSeconds>
  <BatchSize>1</BatchSize>
 </Subscription>
</DataSource>