Microsoft Unified Service Desk (USD) Configuration 102 - Non-Entity Information

In this next installment of an introduction to configuring USD, I'll go through some elements that aren't entities used in configuring but are still critical in knowing how to use USD to it's fullest. Below are the items that'll be discussed:

• Sessions
• Replacement Parameters
• Debugger

Sessions

One of the benefits of USD is that you can have multiple groups of hosted controls open at the same time.  A session is a set of forms and data related to one thing; that 'thing' usually being an account or a contact.  For instance, in a call center environment you can have someone in multiple chat sessions at the same time.  Each session in USD would be related to one of those chat sessions.  This way you can have multiple customers' forms open at the same time, and also any CRM forms related to those specific callers without losing track of what's related to what.

Replacement Parameters

Replacement parameters are used to store session-based information within USD hosted controls. In programming terms, think of them as key/value pairs.  These are used to pass information between CRM, any systems that you're integrating with USD, and any custom USD components.  These values can be based off a specific session or be global.

For example, you can make a custom search page that'll search an external system and return social security numbers.  From there you can search CRM for that social security number and start a session around that specific customer.  To pass that information around, you would use replacement parameters.  Additionally, once the CRM form for that customer is open, you can also pass information from the search page into that form using replacement parameters (use the Event of BrowserDocumentComplete to call an Action that will read Replacement Parameters).

To access replacement parameters use two leading brackets and 2 trailing brackets in your code.  For instance, [[Contact.FullName]] would be replaced in USD by a contact's full name.When accessing replacement parameters, there are many trailing parameters that can be used.  Some of the more common ones (from my experience) are:

• g - Global.  If a value is global, put a 'g' after the first ending bracket.  Ex:  [[SearchControl.SSN]g].
• + - Optional.  If the value doesn't exist, the action calls and other code will continue running.  Otherwise the action call will fail and any sub action calls won't be fired (that this could be a desired result!).  For instance, [[SearchControl.MiddleName]+].
• u - URL Encoding will be used when retrieving the value.  so a space would be replaced by "%20".

Additional Replacement Parameter parameters can be found on the MSDN site:

http://msdn.microsoft.com/en-us/library/dn864934.aspx

Debugger

The debugger is used to see what's going on in the background of USD, and also manually fire off action calls and events for testing.  There are many pages to the debugger, depending on what you're looking for.  Personally, I use it for three main purposes:

• Viewing Replacement Parameters
• Viewing Events/Action Calls
• Manually firing off events and action calls.

To view the replacement parameters, click on the Data Parameters tab in the debugger:

Here you can see all the replacement parameters for the given session and also any global values. Additionally you can use the Copy button on top to get the code needed to access that specific replacement parameter through code or USD configuration.

The action calls that have been run since USD has started up will be displayed under Action Calls.

As you can see above, everything has been captured from events firing, hosted controls closing, even the opening of the debugger itself (the last line above).

Additionally, you can manually run actions:

First, click on the dropdown arrow to bring up additional debugging options.  Once you do that, you'll see the 2nd image above where you can pick a specific action call to fire.  If you'd like to enter data into a specific action, click on Direct Action and from there you can pick which Hosted Control you want to use along with which specific Action you want to fire.  You can also use this to 'hide' certain actions from users and use them for debugging and development purposes.  For instance you might be pulling information from another application but never actually visually display that system.  If you're suddenly having troubles pulling data from that system, you can add an action to make that application visible.

Tips and Tricks (And hidden, lesser known items)

USD can be cached.  Every time USD opens, many many records are pulled down from CRM.  You can set USD to use caching though though Options (Options will be gone over in my next post).  If you have an Option named 'ClientCacheVersionNumber', the USD client will NOT pull all information from the server every time a user connects.  The only time all USD data will be retrieved is when this Option's value changes, making the locally stored value different from what's on the server.  If this option doesn't exist, the client will always pull all USD information down from the server.  I recommend that once you're in production you use this option, and even in your development environment to speed up actual development.

If you want to turn off the caching mentioned above for specific users (say you as a programmer always want the values loaded from CRM and not cached), you can do that through User Settings.  They'll be covered in the next section, but they're basically options on a per-user basis.  That said, just create a new User Setting record, set the Name to DisableCaching, the User field to the individual that you don't want to use caching, and you're all set.

You can fire USD Events from within CRM itself.  Let's say you have multiple values stored in replacement parameters and want to use different ones based off dropdown values changing on a CRM form.  If you want to pull specific values, you'd have to use an Action Call, but how do you fire them?  You'd first have to make a custom hosted control to accept a DoAction call (I'll cover this in a future post, but for now you can check out the MSDN site on making a custom control).  Then, you can call the DoAction event from a specific hosted control by calling http://uii/<hostedcontrol>/<actioncallname>.  USD will intercept that call and instead of displaying a webpage, it'll fire a DoAction event and pass in the given action.

------------

Next time I'll finish what the first USD post started by finishing the review of the entities that are involved in configuring USD.