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)

In the new self-service portal (SSP) in Service Manager 2012 you have the option to validate input using a custom regular expression. To possibly save you some time when doing so I would like to share something important with you.

Always start you expression with caret (^) and end with a dollar sign ($). This makes sure that the input given by the user is an exact match to your expression.
^ – A caret matches the position at the beginning of the input string.
$ – A dollar sign matches the position at the end of the input string.

Example expression:
\d

The expression above can be used to find all digits in a text. If you would use that as a validation expression for a text field in Service Manager, according to Service Manager the input would be valid as long as a digit is written into the field. Here’s a pitfall, this means that a user can write whatever he/she wants before and after the digit. Normally this probably isn’t what you’re looking for when validating the input. Normally you would want to validate the complete input. Adding the caret and the dollar sign (^\d$) will make sure that nothing else goes into the text field than a digit.

If you want to try your expressions out before implementing them, here’s one of my favorites:
http://derekslager.com/blog/posts/2007/09/a-better-dotnet-regular-expression-tester.ashx

Other resources:
http://msdn.microsoft.com/en-us/library/ff650303.aspx
http://www.regular-expressions.info

Categories : Service Manager
Comments (0)

I’ve seen the question two times now, and that’s two times too many :)
The script below will show you how you can locate all Incident (as an example) that has an Classification value matching a Incident Classification that has a display name that matches *problem*.

?View Code POWERSHELL
Import-module smlets -Force
 
$class = get-scsmclass system.workitem.incident$
 
#Try to narrow the next search down by getting the root value for the enums you're interested in.
$rootEnum = Get-SCSMEnumeration IncidentClassificationEnum$
 
#Might be performance heavy depending on how many child enums the parent enum has.
$matchingEnums = get-scsmchildenumeration -Enumeration $rootEnum|?{$_.DisplayName -like '*problem*'}
 
$Filter = ""
$matchingEnums|%{$Filter +="Classification -eq '$($_.Id)' -or " }
$Filter = $Filter.TrimEnd("-or ")
 
Get-SCSMObject $class -Filter $Filter

Remember that the display name used when matching the filter is the localized display name used by the current process (if you run this in a workflow).
If you haven’t already got it, you’ll find SMLets at http://smlets.codeplex.com

When using smlets (smlets.codeplex.com) to work with Service Manager using PowerShell, small details can have huge impact on performance.

Server side vs. Client side filtering

The number one thing is to use server side filtering as far as possible. This has been described before but cannot be told too many times.

Example of client side filtering:

?View Code POWERSHELL
$class = Get-SCSMclass system.workitem.incident$ 
Get-SCSMObject -class $class|?{$_.Title -like '*printer*'}

Example of server side filtering:

?View Code POWERSHELL
$class = Get-SCSMclass system.workitem.incident$
Get-SCSMObject $class -Filter "Title -like *printer*"

In my test lab the server side filtering above is 50 times faster than client side. The reason for that is that client side filtering in the example above, in fact means bringing over all objects of the specific class to the client side and finding the matches there. Not a good idea!

Read more about the gain and tips about server side filtering in these excellent blog posts from Travis Wright and Jim Truher:
Properly Querying SCSM Using SMLets Get-SCSMObject cmdlet
Retrieving projection data with PowerShell

Choosing the lighter type projection

What I want to add to the above is how choosing the proper type projection will affect the performance.

As an example, let’s say we want to retrieve all Incidents that are currently Active and Un-Assigned (assigned to user is not set).

We can do this by using the following PowerShell commands:

?View Code POWERSHELL
#Get type projection
$IncidentProjection = Get-SCSMTypeProjection System.WorkItem.Incident.ProjectionType$
#Create criteria
$criteria = new-object $CTYPE $cc,$IncidentProjection.__Base,$IncidentProjection.managementgroup
#Get incidents matching the criteria
$incidents = Get-SCSMObjectProjection -Criteria $criteria

Note: I cut out the part of defining the criteria “$cc”, you can find it in the download available in the bottom of the post.

Depending on which type projection you choose the time for execution of the commands can differ greatly. The reason for this is that different type projections bring a different amount of data back from the server. A type projection is a definition of what data you want to wrap around the seed class instance (in this case the Incident). When choosing which type projection to use we have to think about how we want to define the criteria and which data we want to retrieve. In our example above we just want to see which incidents are Active and Un-assigned. This basically means that we only require a type projection (read more about type projections here) that has the seed class “Incident” and has one component, the AssignedUser. Let’s look at the effect of choosing two different type projections in the example above.

To see which type projections are available for a specific type you can use the following command:

?View Code POWERSHELL
Get-scsmtypeprojection|?{$_.TargetType.Name -eq "System.WorkItem.Incident"}

Note: Client side filtering is perfectly fine in usage like this of course. Another great way to study type projections is to export management packs and look at the xml directly. Also, if you do not find a suitable type projection you can also define your own, but that’s a different story.

After looking at the type projections let’s say that we choose to use the one called “System.WorkItem.Incident.ProjectionType” since this one contains all the components we’ll ever need. Actually it’s the projection that is used out of the box for the Incident form, which means it contains all the components used by the form like: Assigned User, Primary User, Activities, Affected User etc.

Executing the query for all Incidents with status Active which are Un-Assigned, using the type projection above, in my lab environment (over a medium slow connection) takes about 30s.

Now we might be perfectly fine with that, but let’s take a look at what would happen if we would have chosen a “lighter” type projection (fewer components wrapping the incident). As discussed earlier this scenario really only required one component, the AssignedUser, since we’re using the AssignedUser in our criteria.

The out-of-the-box type projection that has the least components and includes the AssignedUser is the projection called “System.WorkItem.Incident.View.ProjectionType”. This projection actually only contains two components: AssignedUser and AffectedUser. Using this projection for the same query for data as the previous, with the same setup takes 10s.

So by choosing a more suitable type projection we managed to cut two thirds of the time used for retrieving the incidents we were looking for.

So remember folks:

  • Use server side filtering
  • Use the type projection with the least components that fulfill your needs.
    Based on components used by your criteria and what data you want to retrieve.

One last thing, when creating views in Service Manager you can use the exact same reasoning regarding which components are required to achieve as good performance as possible. This has been described on its own in this great blog post by Travis Wright: Why is My Custom Incident View So Slow?

You can download my measurement script here: smletsDataQueryTest.ps1

Comments (0)


I few days ago a friend (Anders Bengtsson over at www.contoso.se) asked if I could help out with creating an Orchestrator Activity that would convert rich text to plain text. So, today we’re announcing another community contribution from Gridpro, the “Gridpro Orchestrator Text Manipulation Integration Pack”. At this point it only contains the one activity – “RTF to Plain Text”.

Download the integration pack from here: Gridpro Orchestrator Text Manipulation IP

Note: The activity needs the complete RTF content to be able to convert it correctly, line by line coversion is not supported.

Update: See how Anders uses the IP when working with announcements in Service Manager. Integrate Service Manager and SharePoint annoncements with a bit of Orchestrator magic

Categories : Orchestrator
Comments (3)

For our Swedish audience we are happy to introduce a half-day session in how Service Manager 2012 and Orchestrator 2012 can ease your daily IT operation burden by automation. This session is arranged by our partner Expero and is in Swedish. For more information and to book your seat click here

If you want even more hands-on experience on how Service Manager 2012 and Orchestrator 2012 work together we would recommend you to book a seat in our 2 days Labshop were we will be working with these products and see the full potential of the integration. Book your seat here

 

Sorry all non-Swedish speaking people out there… And congrats for those who understand Swedish! There is a series of online seminars about System Center 2012 taking place this spring with some great Swedish speakers. The seminars will be covering:

  • PowerShell
  • Configuration Manager 2012
  • Operations Manager 2012
  • Service Manager 2012 (my seminar)
  • Data Protection Manager 2012
  • Orchestrator 2012
  • Application Controller
  • How to build your automated data center with System Center 2012

For more information and registration: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032502587&Culture=sv-SE&WT.mc_id=nlc-n-se-loc–SystemCenter2012onlineseminars

 

Comments (0)

Going to MMS 2012? Want to see a demo bursting session? Come and see how your application lifecycle can be managed with System Center 2012!

This session will unveil the Application Lifecycle Management using System Center 2012 and Team Foundation Server (TFS). Learn how TFS in collaboration with System Center products can assist you building, deploying, operating and optimize your Application Lifecycle. See how we integrate System center and TFS to track and deploy the application. Understand how Operations Manager detects, Service Manager tracks, Orchestrator automates and TFS manages and controls the Application Lifecycle.

More info at: http://www.mms-2012.com/topic/list (keyword: lifecycle)

Categories : Service Manager
Comments (0)

A few weeks ago, I was in the “studio” with my colleague Jonas Ullman and some fellow Expero instructors recording System Center 2012 presentations. So if you understand Swedish and would like to see how Service Manager 2012 and Orchestrator can bring fully automated self-service to the table, Enjoy!

Comments (6)

When creating views in System Center Service Manager, displaying a property of a related object can be accomplished by targeting a combination class, a.k.a. type projection. The wizard that is used to build views in the SM console let you choose which of the related objects, e.g. the affected user of an incident, that you want to bind a column to in a view. This works for all relationships that are constrained to only allow the “source object” (e.g. an incident) to relate one “target object” (e.g. the affected user). The limitations are described in detail in this blog post: http://blogs.technet.com/b/servicemanager/archive/2011/04/06/faq-why-can-t-i-add-some-columns-that-i-want-to-views.aspx

As described in the blog post the reason why we’re not able to select objects that are related to the “source class” based on a one-to-many relationship is based on the complexity around providing features like sorting etc.

Now let’s say you’re ok with not being able to sort on a column like this and would find some kind of value in showing the display name of one of your affected configuration items in a view. Maybe the reason is that you want to know if the incidents listed in the view has defined affected configuration items or not? If so, then you could make use of a XAML (which is the language that WPF and Silverlight is based on) feature that lets you bind to one element in a collection using an index. The abstracts below shows how you force a view to show one of the related objects from a “one-to-many” relationship by data binding to an index of a collection of related objects.

The first section shows a type projection defined for the purpose of having a view showing the affected user and affected configuration items of an incident. The reason for creating this type projection instead of using e.g. the “Incident (Advanced)” type projection is only for performance reasons; always try to minimize the number of components used in a type projection used by your views. Since I only need the two I created a type projection that only contains the two.

Type Projection

<TypeProjection ID="Gridpro.Incident.TypeProjetion.AffectedItems" Accessibility="Public" Type="CoreIncident!System.WorkItem.Incident">
    <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAffectedUser']$" Alias="AffectedUser" />
    <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAboutConfigItem']$" Alias="AffectedConfigItems" />
</TypeProjection>

Next abstract comes from the input parameter of my view that tells Service Manager that I want to makes use of the type projection described above.

View – Item Source Query Parameter

<AdvancedListSupportClass.Parameters>
	<QueryParameter Parameter="TypeProjectionId" Value="$MPElement[Name='Gridpro.Incident.TypeProjetion.AffectedItems']$" />
</AdvancedListSupportClass.Parameters>

The final abstract shows how to make use of the index when binding to the affected configuration items. Notice the “[0]” written behind the type projection component alias AffectedConfigItems.

View – Column definition

<mux:Column Name="AffectedConfigItems" DisplayMemberBinding="{Binding Path=AffectedConfigItems[0].DisplayName}" Width="100" DisplayName="Header_AboutCI" Property="AffectedConfigItems[0].DisplayName" DataType="s:String" />

In the picture below you can see the example view provided in the following management pack: Gridpro.Examples.Views.zip

Indexed binding