In this demo you’ll see how you can bring the latest technology from Microsoft to your end-users.
The End User Experience
Let’s start from the end users perspective. The end user, Mr User in this scenario, wants to install Winrar on his computer, but he doesn’t know how to install it and he lacks permissions to install applications on his computer.
1. Mr User starts by logging in to the ZervicePoint portal
2. He opens the OneGet category (the category name can of course be changed to Applications)
3. Next, he chooses the “Install Package” service (Only one service? Yeah, OneGet & Windows Management Framework 5.0 is still in Preview, but we will add more OneGet Services as soon as it goes live)
4. The service is pretty simple to use for Mr User.
He can simply type the name of the application that he wants to install in the “Select a Package” field. The “Select a computer” field is pre-populated with Mr User’s computer (this is based on an Active Directory lookup that returns all Mr User’s computers, the one’s where the ManagedBy attribute is set to Mr User and defaults to the computer that he logged onto most recently).
5. Mr User types “Winrar” in the “Select a package” field
And voila, more information appears. The information describes additional information about the selected package.
6. Mr User then clicks on “Add to Cart” and place the orders for the Winrar package.
It is a good idea to control what end users can install. To handle this we’ve added an approval activity. When adding an approval activity to ZervicePoint you basically tell the workflow (the tasks that is running in the background) to wait until a specific person has approved the order. If the order is approved, the package will be installed. If the request is denied Mr User will not get the application installed. in this case we’ve set the approval to the user’s manager (based on the Active Directory attribute).
7. Now, let’s take a look what happens when Mr Manager logs into the portal.
Mr Manager just logged in to ZervicePoint since he got notified via e-mail that he has something to approve (yep, adding e-mail notifications is really simple).
8. Mr Manager clicks on “My Tasks” and sees that Mr User wants to install a package and that he need to either approve or deny the request.
When clicking on the order more information is displayed.
9. Mr Manager chooses to approve the Winrar package for Mr User. He therefore adds a comment and clicks approve.
Once Mr Manager approves the order and the workflow continues. When the workflow is completed Winrar has been installed on Mr user’s computer and is now ready to use.
10. Mr User can simply find his new package in the Windows 8.1 Search as shown below.
The Technical aspects
Now let’s take a look at what actually happens in the background. The service is built using ZervicePoint’s Service Designer interface.
First we set some basic catalog information:
And here’s a description of the fields:
- Current Language: Yeah, we support multiple languages!
- Display Name: The name of the service.
- Short Description: A simple one-liner describing the service.
- Description: A detailed description of the service.
- Allow user to change orders quantity: You can design your service to support quantity, useful if you are ordering hardware or guitar picks.. somehow I always loose my guitar picks.
- Owner: The service owner. (lookup field from Active Directory or other source).
- Cost: the initial cost for the service.
- Monthly Cost: useful for subscriptions and such.
- Categories: The categories where the service will be visible
- Keywords: Hashtags, useful when searching for services.
- Visible for Roles: ZervicePoint has a pretty cool Role system based on ADFS claims. This allows us to control, in detail, what kind of services an end-user should see.
Next we have the Form (this is what the user sees as a service):
The form designer supports full drag ‘n drop functionality. Simply pick the element you want and drag it into your form.
ZervicePoint supports a couple of different elements:
- Text Field: Free text.
- Text Area: A larger chunk of text.
- Text block: Supports movies, images, and other interactive coolness.
- Drop down list: A drop down that displays single or multiple choices that the user can select. I’ll get back to this one in a while since it’s pretty awesome.
- Checkbox: Yes or No (boolean True/False)
- Radiobutton: Well, its a radiobutton..
- Date & Time picker: Supports Date & Time (depending on your regional settings you’ll see date & time differently).
- File upload: Useful if you want to upload documents and files. Awesome if you add some approval activities to it
- Hidden field: Used to store additional data, not displayed to the end user.
- Form section: Helps you divide the service into different sections for a cleaner look and feel.
So what about Winrar and the ComputerName? where did that come from?
Glad you asked! Winrar, and all the other packages that the end user can search for comes from a Dynamic Drop Down PowerShell Module. The module is connected to the “Select a package” drop down list. If we click on the drop down list we can see the details about it.
Notice that Searchable is checked. This allows the end user to search for “something”. Dynamic bind is also checked and connected to Package.
Package is a variable that stores the value of whatever the end user selected. in this scenario it would contain “Winrar”.
And now for the cool part: Data Source!
Notice how data source is connected to ZervicePoint.DropDown.OneGet. This is actually a PowerShell module running on the server side.
Drop down modules in PowerShell are specific to ZervicePoint and follow a set of rules. They need to include a Search function that returns a PowerShell Object containing an ID and a Name. The Name is displayed to the End User and the ID is passed to the variable connected to the drop down list. Lets take a look at the actual code behind:
Note that the Search function includes a single PowerShell Cmdlet: Find-Package. it binds $search to the Name parameter and $search contains whatever the end user types!
So when the end user typed Winrar, the Find-Package Cmdlet executed and returned information about the Winrar package. Since we are working with a list we need to return an ID and a Name. Again, the ID is passed to the variable and the Name is displayed to the end user.
The Computer drop down list also uses PowerShell in the background but instead of using the OneGet Module it queries Active Directory. The ZervicePoint.Dropdown.ADComputer module is configured to only display computers where the ManagedBy attribute is equal to the end users DistinguishedName (an end-user can only see his own computers). It’s also possible to add additional rules and queries if needed. This is based on roles in ZervicePoint.
Another fun thing that happens is that ZervicePoint auto-populates a couple of fields. In this scenario the Provider Name, Source, Version, Status and Summary fields are automatically populated with information based on the users selection of package.
This is also performed by PowerShell. When populating additional fields we use a webservice to call a PowerShell “Get” function or CmdLet and return the object to ZervicePoint. In this example we’ve connected the Get-ZPOneGetPackage function to the service.
The function is placed in a PowerShell module and here’s what it looks like:
Again, this is a really simple PowerShell function that contains a oneliner! Notice how we select ProviderName, Source, Name, Version, Status, and Summary.
What’s even cooler is that if we name an element ProviderName it will automatically be populated with the ProviderName value from the PowerShell function. Pretty neat!
Here’s how the Provider Name element is configured:
As you can see we’ve simply set the Name so that it matches the PowerShell objects property.
Now, let’s take a look at the Process Activity.
The process activity only contains two steps. The first step is an Approval activity and the second step is a Drumroll PowerShell function! ZervicePoint includes a couple of built-in activities such as:
- Approval: Allows you to add an approval to any service.
- Task: Allows you to add a manual task. A good example would be: Type in the MAC Address for the newly delivered computer.
- State: Allows you to display information about the current state. This is really useful if you build a longer running activity.
- Send E-mail: Sends an email.
- Sequence: Allows you to group activities.
- Conditional sequence: Allows you to add logic to you activities. An example is if you have different approaches to an order in different offices or countries.
- Delay: Allows you to delay an activity for a number of hours, days, week, years.
- End process: Allows you to terminate a process if some criteria is not met.
All other activities are PowerShell Modules. Each function in a module is shown as an activity and can be used in ZervicePoint!
Let’s take a closer look on the activities used in our service.
The Approval activity starts of with a list of users that need to approve the order. In this example its connected to the Users manager. The users manager is grabbed from the users Manager attribute in Active Directory so its pretty dynamic. We can also add specific users, such as a helpdesk user account or we could add approvers based on a custom PowerShell function. We can add one or multiple approvers to an Approval activity.
The Approval Activity includes additional settings:
- Form: The form that is displayed to the Approver.
- Type: Parallel or Sequence. Allows us to send the approval request to the approvers in a sequence or all at once.
- Required: All approvals or One approver.
- On Timeout: Reject or Approve.
- Timeout: The time to wait for an approver to either approve or reject.
- Approval result: Allows us to store the choice made by the approver in a variable.
- Notify approver(s): Allows us to automatically send an e-mail to the approvers whenever they have a new task in ZervicePoint.
Next we have the Install-ZPOneGetPackage. This is an activity written in PowerShell and placed in the ZervicePoint.OneGet module. Here’s the actual code behind:
The module contains the function Install-ZPOneGetPackage. The function has two mandatory parameters: ComputerName and Package.
ComputerName is used when connecting to the remote computer using New-PSSession and Package is used as an input to the Install-Package Cmdlet on the remote computer. Again, this is a fairly simple, straightforward PowerShell function that relies on PowerShell’s Remoting and Cmdlets.
In ZervicePoint we simply add the users choice of package to the Package parameter and the users Computer to the ComputerName parameter.
And there we have it. Bringing OneGet to the end-user in a controlled manner
//Niklas Goude – ZervicePoint Development Team