Creating a service offering through a self-service portal part 3: The work in Orchestrator

December 23, 2011 at 9:38 am in Uncategorized by mikeresseler

The series

Recap

In the first post we discussed what we are going to do through these series. I showed the result and the high-level overview of what we are going to do in more detail in the different posts.

In the second post we did some pre-work like creating a management pack specific for this solution and a knowledge base article to give some additional “power” to our solution.

In this post, we are going to focus on the workflow we are going to build in Orchestrator.  Let me already tell you that I didn’t bother to get some checks in the workflow.  In production, we would need to do that, but for this series, and to give a demonstration you want to loose as less time as possible Smile

Let’s start

image

Here you see the overview of the runbook.  Small one isn’t it Smile.  To build this, I need Orchestrator 2012 and the Active Directory Integration pack.  That’s it.

You see four activities in this runbook. I left the names of the activities like they are when you drag them into the designer.  Again, in production you want to change those so that the different activities have a name that makes the workflow or runbook better readable.

The first one is Initialize Data.  This activity will get the workflow started.  It is also the activity that is responsible for getting the variables from service manager.  As we have seen in Part 1 of this series, our end-user needed to fill in 3 fields.  Two of those fields deliver us the data (the user and the group) that we need to do the job.

Let’s have a look at the properties of this activity.

image

In the Details, I’ve created two variables.  One called GroupName and the Other one called UserName.  They are both of the type String.  That’s it.  Still easy right Winking smile

The second activity is the get user activity.  Because our end-user will select a display name from the portal (e.g. Mike Resseler) we need to find that name in Active Directory and come back with the Distinguished Name of the user (e.g. CN=MikeResseler, OU=Demo,DC=Infront,DC=Eu).  Only when we have the DN of that user, we will be able to perform the last activity, namely add that user to a group.  So let’s see how this works.

image

In the properties, all I have selected is my connector to AD.  This is something you need to create before and is normally done after you have imported the AD Integration Pack.  You can select a few Optional Properties here if you want to.  For example, you can choose only to get the DN name (which is what we need…) but because I wanted to play a bit more later on, I choose to return all the properties of the user to the databus.  Again, in a production environment I would do this to get less data on my databus.

Now we need to go to the tab Filter because there is where we are going to create the “Query” to get the properties of the correct user.

image

And here we add a query:

Name

Display Name

Relation

Equals

Value

From the pipeline: {UserName from “Initialize Data”}

All this does is search through AD based on the Display Name that equals our variable we got from the portal and that is passed through the “Initialize Data” activity

The next activity is the Get Group activity.  This is comparable with the Get User activity but it has a small difference in the filter

image

image

In the filter, we are going to search for the Common Name (CN) of that group.  The reason for that is that in many cases, a group has no display name, unless you really specified it (each time) into AD.  Many companies don’t do that so that’s why I’m searching for the CN name here

Name

Common Name

Relation

Equals

Value

From the pipeline: {GroupName from “Initialize Data”}

Finally, we have our last activity and that is the Add User To Group activity.  This activity will put the user in the group

image

This activity has two input parameters. The DN name of the user and the DN name of the group.  Since we searched them before on our workflow, we have them on our databus

Group Distinguished Name

{Distinguished Name from “Get Group”}

User Distinguished Name

{Distinguished Name from “Get User”}

That’s it.  All you now need to do is find out if your policy works (so test it with the test console our through the web console) and you are done.  Make sure that the policy is checked in and you are one step closer to your solution.

On to the next step which will be the preparation in Service Manager

Cheers,

Mike