Today’s post will cover the ability to preserve conversations when sending notifications. The typical scenario we are trying to avoid is: a user is answering a series of troubleshooting questions, and then receives a stock alert. The alert proposes to see more details, and the user can’t go back to finish his troubleshooting steps.

To avoid such disturbance, the BuddyScript engine runs notification and initiate alerts in different conversations from the one used to answer regular queries.

Each conversation is uniquely identified by an identifier. A system variable tells you what your conversation id is:

SYS.Conversation

Another system variable tells you the id of the conversation used to answer queries. This is called the user conversation.

            SYS.User.Conversation

If those two values are the same, you are in the user conversation, otherwise, don’t bother initiating a dialog.

You can switch the user conversation to be the conversation you are in with the following statement:

            set user conversation

You can also switch the user conversation to be a conversation you specify by doing:

            set user conversation CONVERSATION_ID

With this statement, you can temporarily highjack the user conversation and later restore it.

Finally, you can forward a query you just received to any conversation with the following statement:

            forward query CONVERSATION_ID

With those three elements, you can highjack the user conversation, receive the user queries, forward the queries that you don’t care to the previous user conversation, and restore the previous user conversation.

To illustrate this, here is the “Say Hi to my friend” example with the ability for the friend to reply back.

// Respond to Hi

 

declare procedure DisplayGreeting(FRIEND_NAME, GREETING)

 

? Say Hi to my friend EMAIL=AnEMailAddress

  RESULT = initiate EMAIL, "MSN": DisplayGreeting(SYS.User.NickName, "Hi") {createprofile=false loadprofile=true}

  - Ok, done.

 

procedure DisplayGreeting(FRIEND_NAME, GREETING)

  - Hey, your friend FRIEND_NAME says GREETING!

  SOURCE = SYS.ConversationSource

  if SYS.Conversation = SYS.User.Conversation

    // This is the user conversation

    - Do you want to say GREETING back to FRIEND_NAME ?

    ? Yes

      RESULT = initiate SOURCE.ScreenName, SOURCE.Service: DisplayGreeting(SYS.User.NickName, GREETING + " back")

      - Done.

    ? No

      - Fine.

  else

    SAVED_USER_CONV = SYS.User.Conversation

    set user conversation

    - If you want to say GREETING back to your friend, just say "reply"

    ? reply

      RESULT = initiate SOURCE.ScreenName, SOURCE.Service: DisplayGreeting(SYS.User.NickName, GREETING + " back")

      - Done.

    ? ANYTHING=AnythingRaw

      forward query SAVED_USER_CONV

    set user conversation SAVED_USER_CONV

   

The first thing DisplayGreeting does is to save SYS.ConversationSource in a variable. This variable contains some information on the user the initiate comes from, and will be used to initiate back.

It then identifies if the current conversation is the user conversation. That would be the case if the user was not in session with the agent. Depending on the result, we will phrase our question differently. The response will have to be less ambiguous if the user was already in a conversation with the agent.

If this is the user conversation, the rest of the code is simple.

If it is not the user conversation, the procedure highjacks it. If the user sends “reply”, an initiate is sent back to the originator. If the user sends anything else, the query is forwarded to the previous user conversation. In any case, the user conversation is restored to the previous one.

You can try this example with a routine with a dialog and see if the user that receives the greeting can ignore the question and respond to the dialog he was in. You can also test if he can still respond to his dialog after saying “reply”.

Here now is the kitchen timer example with a snooze capability. The same logic is used here.

// Kitchen Timer with snooze

 

declare procedure Ring()

variable KITCHEN_TIMER_NOTIFICATION = ""

 

? Kitchen timer

  - Ok, I'm setting up the time, how many minutes do you want ?

  ? DELAY=Integer

    - Alright, I will notify you in DELAY minutes

    KITCHEN_TIMER_NOTIFICATION = notify in DELAY minutes: Ring()

 

? Cancel Kitchen timer

  if KITCHEN_TIMER_NOTIFICATION = ""

    - What timer ?

  else

    cancel notify KITCHEN_TIMER_NOTIFICATION

    KITCHEN_TIMER_NOTIFICATION = ""

    - Done.

   

procedure Ring()

  - DRRRRRRRING !!!!!

    Your time is up!

  KITCHEN_TIMER_NOTIFICATION = ""

  if SYS.Conversation = SYS.User.Conversation

    // This is the user conversation

    - Do you want to snooze ?

    ? Yes

      KITCHEN_TIMER_NOTIFICATION = notify in 5 minutes: Ring()

      - Will ring again in 5 minutes.

    ? No

      - Fine.

  else

    SAVED_USER_CONV = SYS.User.Conversation

    set user conversation

    - To give an extra 5 minutes, type "snooze"

    ? Snooze

      KITCHEN_TIMER_NOTIFICATION = notify in 5 minutes: Ring()

      - Will ring again in 5 minutes.

    ? =AnythingRaw

      forward query SAVED_USER_CONV

    set user conversation SAVED_USER_CONV

 

Next post will explain how to empower your scripts by combining initiate and notify with dialogs. This is done through actions.

 

Damien.

Good (morning|afternoon|evening),

With the initiate functionality, you can choose to put one of two restrictions based on the targeted user:

·         The user has to be known to the agent

·         The user has to actually be conversing with the agent

This is a good idea to set those restrictions to avoid spamming the users.

By checking the result of initiate, you can know if it succeeded or not. If it did not, depending on the restrictions you just put, you can conclude if the user is known to the agent or if the user is not currently talking to the agent. You set those restrictions by adding the following properties:

·         {createprofile=false}: initiate will fail if the user doesn’t have a profile yet.

·         {loadprofile=false}: initiate will fail if the user is not in session with the agent.

The result of initiate is an object, the two important members of that object are:

·         Delivered: contains 1 if delivered, 0 otherwise

·         Status: string indicating the reason it was not delivered.

Here is an example of use of that information, I call it “Do you know my friend?”

// Do you know my friend

 

procedure DoNothing()

  nop

 

? Do you know EMAIL=AnEMailAddress ?

  RESULT_NOLOAD = initiate EMAIL, "MSN": DoNothing() {createprofile=false loadprofile=false}

  if RESULT_NOLOAD.Delivered

    - Yes I do, and he/she's talking to me right now.

  else

    RESULT_LOAD = initiate EMAIL, "MSN": DoNothing() {createprofile=false loadprofile=true}

    if RESULT_LOAD.Delivered

      - Yes, I know that guy

    else

      - Sorry, I can't say that I do

 

Another use of initiate is to send information from one user to another user. The next example is “Leave a note to my friend”. It lets a user leave a message for another user, which will get the message the next time he/she talks to the agent.

In addition, this example checks to see if the user is currently in session, in which case it will deliver the message immediately.

// Leave a note to my friend

 

declare procedure SendMessageDirectly(FRIEND_NAME, MESSAGE)

declare procedure LeaveMessageNote(FRIEND_NAME, MESSAGE)

 

? Can I leave a note to EMAIL=AnEMailAddress ?

  - Sure, what's the message ?

  ? MESSAGE=AnythingRaw

    RESULT = initiate EMAIL, "MSN": SendMessageDirectly(SYS.User.NickName, MESSAGE) {createprofile=false loadprofile=false}

    if RESULT.Delivered

      - Well, your friend and I are actually talking to each other right now, so I'm telling him/her now.

    else

      RESULT = initiate EMAIL, "MSN": LeaveMessageNote(SYS.User.NickName, MESSAGE) {createprofile=false loadprofile=true}

      - Ok, I'll leave a note for him/her to read next time he/she talks to me

 

procedure SendMessageDirectly(FRIEND_NAME, MESSAGE)

  - Hey, your friend FRIEND_NAME has left a message for you:

    MESSAGE

 

stored variable OFFLINE_MESSAGE_FROM_FRIEND = ()

 

procedure LeaveMessageNote(FRIEND_NAME, MESSAGE)

  OFFLINE_MESSAGE_FROM_FRIEND.FriendName = FRIEND_NAME

  OFFLINE_MESSAGE_FROM_FRIEND.Message = MESSAGE

 

procedure overrides ABGreetingProc(USERARRIVES, NEWUSER)

  - Good day!

  if OFFLINE_MESSAGE_FROM_FRIEND != ()

    - Hey, your friend OFFLINE_MESSAGE_FROM_FRIEND.FriendName left the following message for you:

      OFFLINE_MESSAGE_FROM_FRIEND.Message

    OFFLINE_MESSAGE_FROM_FRIEND = ()

   

 

About notifications, the only thing there is to do is to cancel them before they trigger. This is done by saving the notification id and passing it to the “cancel notify” statement.

To illustrate this simple thing, here’s the previous Kitchen timer example improved with a stop functionality.

// Kitchen Timer stopper

 

declare procedure Ring()

variable KITCHEN_TIMER_NOTIFICATION = ""

 

? Kitchen timer

  - Ok, I'm setting up the time, how many minutes do you want ?

  ? DELAY=Integer

    - Alright, I will notify you in DELAY minutes

    KITCHEN_TIMER_NOTIFICATION = notify in DELAY minutes: Ring()

 

? Cancel Kitchen timer

  if KITCHEN_TIMER_NOTIFICATION = ""

    - What timer ?

  else

    cancel notify KITCHEN_TIMER_NOTIFICATION

    KITCHEN_TIMER_NOTIFICATION = ""

    - Done.

   

procedure Ring()

  - DRRRRRRRING !!!!!

    Your time is up!

  KITCHEN_TIMER_NOTIFICATION = ""

 

Those messages, coming from an initiate or a notification, are designed not to disrupt the conversation. What that means is if the user is expected to answer a dialog or an enumeration, the fact that his kitchen timer rings or that he receives a message from a friend won’t prevent him from answering as he was supposed to.

What that also means is, if you add a dialog to your Ring procedure, the user will most likely not be able to answer it. How to fix this? This will be explained in the next post.

Damien.

Hello fellow agent developers,

 

I am going to present, in this post and the next 3 ones, the notion of conversations in BuddyScript and the way to best use them with the “initiate” and “notify” functionalities.

Here are the items I am going to cover in those four posts:

1.     Basic use of initiate and notify.

2.     Controlling the execution of initiate and notify.

3.     Handling conversation ids.

4.     Using actions.

Controlling the execution tells you how to know if a user is talking to the agent or not, if he has ever talked to the agent or not, and how to cancel a notification.

Handling conversation ids will show you how to interact with the user from a notification without disturbing the current conversation he was in. For example, the user plays a game with the agent and the agent throws a stock ticker alert, proposing the user to see details; the user should be able to finish his game.

Using actions will show you how to exchange information between users back and forth in an efficient manner, and how to combine notifications with dialogs. An example of use is a trivia game with a timer.

 

But today, I’m going to describe the initiate and notify functionalities.

Initiate is a BuddyScript functionality that lets you call a procedure on behalf of someone else. This procedure is executed with the profile of the user you specified, and any output generated will be sent to that user.

The first example is the “Say Hi to my friend” program.

// Say Hi to my friend

 

declare procedure DisplayGreeting(FRIEND_NAME, GREETING)

 

? Say Hi to my friend EMAIL=AnEMailAddress

  RESULT = initiate EMAIL, "MSN": DisplayGreeting(SYS.User.NickName, "Hi") {createprofile=false loadprofile=true}

  - Ok, done.

 

procedure DisplayGreeting(FRIEND_NAME, GREETING)

  - Hey, your friend FRIEND_NAME says GREETING!

In this example, user Joe will ask to say Hi to Mary, providing Mary’s live messenger screen name. As a result, Mary will receive a greeting from the agent. In this example, Mary has to have talked to the agent already; she must already have a profile stored.

 

The notify functionality calls a given procedure at a given time from the same user. It is used to create timers and reminders.

An example for it is the “Kitchen Timer”.

// Kitchen timer

 

declare procedure Ring()

 

? Kitchen timer

  - Ok, I'm setting up the time, how many minutes do you want ?

  ? DELAY=Integer

    - Alright, I will notify you in DELAY minutes

    ID = notify in DELAY minutes: Ring()

   

procedure Ring()

  - DRRRRRRRING !!!!!

    Your time is up!

 

Perfect to boil an egg.

If you want the best of both worlds, being able to specify the procedure to call, the time to execute it and for which user, you can combine the two.

Here’s the “Friend’s reminder” example

// Friend's reminder

 

declare procedure RemindFriend(FRIEND_NAME, ACTION, TIME)

declare procedure RemindNotification(ACTION)

 

? Remind my friend EMAIL=AnEMailAddress to ACTION=AnythingRaw at TIME=ATime

  RESULT = initiate EMAIL, "MSN": RemindFriend(SYS.User.NickName, ACTION, TIME)

  - Ok, that's done.

 

procedure RemindFriend(FRIEND_NAME, ACTION, TIME)

  STIME = TIME.hour + ":" + TIME.minute

  - Hey, SYS.User.ScreenName, FRIEND_NAME would like to remind you to ACTION at STIME.

  ID = notify day at STIME: RemindNotification(ACTION)

 

procedure RemindNotification(ACTION)

  - Hey there, it's time to ACTION!

 

The procedure “RemindFriend” doesn’t need to output anything to work. The alternative would be to do the notify first, followed by initiate.

Tomorrow, we’ll see in more details those two functionalities.

Damien.

Hello Developers and Partners of Windows Live Agents,

 

We are pleased to announce the public release of our new SDK for Visual Studio.  We have been in limited beta of the Colloquis SDK for quite some time and are excited to release this new technology to the public.  This new release of our SDK, as well as our Platform, marks an important step in building the Agents developer community.  We’ve been publishing weekly updates to this blog for almost a year, as well as supporting developers through our MSDN Forum, so we’re hopeful that we’ve gotten all your feedback and input handled in this newest release.  In addition to the release of the Platform and SDK, we’re also releasing our new system for hosting Agents at Microsoft, PHI (Partner Hosting Infrastructure).  With PHI, the previous method of mailing a project manager or an alias will be replaced by submitting your Agents through an automated system, receiving status on your project, and administering all your projects through a single console.  Hosting of your Agent will require a nominal yearly fee that offsets hardware costs (prices starting at ~$10k USD/year).  If you are working in partnership with Windows Live or MSN, that fee will likely be waived as part of your development contract on the product you are delivering.

 

I highly recommend you read the release notes below for important process related questions for Agent development, as well as our SDK Documentation. There is important information about how to use PHI, the IDE, and what guidelines you must follow in order to develop in this community.  As we’ve noted in earlier blog posts, the older standard of MSN Bot is no longer supported, or certified by Microsoft.  Windows Live Agents replaces the terminology, technology, guidelines, and processes under which many of you have operated in the past, but we believe we’ve spoken about this at great length and have given our partners a chance to migrate effectively.  The users of Messenger and Windows Live ID are protected by Microsoft’s global policy and we’re ensuring that Agents on our network are held to the highest standard in online safety by using the Agents SDK for development.  Development of an Agent on the Agents SDK does not ensure that an Agent will be hosted by Microsoft, pending content reviews and approvals by the policy and safety teams.

 

While we have many partners that work closely with the Agents team today, we are actively seeking new professional vendors that use this SDK to partner with us and the MSN Markets.  If you have been working with an MSN Market already, please send an email to wlabiz@microsoft.com to let us know the Agents you’ve developed and the people you’ve been in contact with at MSN.  Our development team is always recommending partners for vendor work in different regions.  We’ll be formalizing these partnerships under the Microsoft Partner Program in the future, but welcome the on-boarding of new development teams that can build Agents for online media needs. 

 

Any questions that you have on the release, the process, or the software, should be posted on the MSDN Forum.  The previous alias used by many today will be monitored, but replies will be limited to developers that are explicitly directed there.

 

We look forward to seeing the innovation from your development teams!

 

Best,

Windows Live Agents development team

 

 

Here are the relevant links for download and information:

·         SDK

·         SDK Documentation

·         PHI

·         Development Blog

·         MSDN Forum

New Features and Processes in Windows Live Agents 5.0

·         Visual Studio SDK

o   We will be retiring the old standalone Colloquis SDK (versions 4.3 and previous) within 90 days of our 5.0 release. The process by which you take your previously developed projects and update them will be discussed with our release notes, but we want to ensure that developers have Visual Studio 2005 or 2008 Standard (or above) prior to the release of our Agents plug-in.  Please subscribe to Alerts on our blog page for availability of the SDK as we will be posting the announcement there.

·         Partner Hosting Infrastructure (PHI)

o   We are streamlining the process by which projects can be hosted within Microsoft, if you choose to be hosted with us.  The old method of contacting a project manager within Microsoft will be replaced with our PHI system.  Within PHI, you will be submitting your Agents through an automated system, receiving status on your project, and administering all your projects through a single console.  Hosting of your Agent will require a nominal yearly fee that offsets hardware costs. We will be updating folks on the pricing model in the near future on our blog and through Windows Live development announcements, but it’s likely you’ll be able to waive these hosting fees if you are working with an MSN Market.  Microsoft will only host Agents that are developed within the languages that are supported by the SDK (English, French, Italian, German, Spanish, Japanese, Chinese; Portuguese and Dutch will release in the next few months).

·         Agent Provisioning

o   As part of the ongoing safety for our end-users, the ability to have a Windows Live ID provisioned as an Agent will require that the Windows Live Agent SDK is used for development of your Agent.  The previous method of submitting through Windows Live Gallery is no longer supported and will soon be removed from the system all together.  Provisioning an Agent lifts the limit of contacts within Windows Live Messenger, but will be enforced strictly to ensure our Platform is in use.

·         Compliance

o   The Windows Live Agents SDK is now enforcing Policy Compliance in all responses from an Agent hosted by Microsoft.  What this means to you as a developer is that your Agent may not respond with the exact text that you had scripted during your development.  When an Agent is hosted by Microsoft, we’ll have an additional set of tools that runs against your code to ensure that the response is appropriate for any and all users of Messenger.  We are holding our developers to the highest standards in online safety and will be posting blog entries on how you can safeguard your code within the SDK prior to Windows Live hosting.  You will be able to easily mimic the production conversation during development with these tools, so you can be sure your Agent is compliant with online safety guidelines.  If you are working with an MSN Market or Microsoft product, you will be hosted by Microsoft and subject to these tools.

·         Self-Hosting

o   As you are downloading the new SDK, you may run this free version with your production Agent, in your own environment.  There are limitations on sessions within this self-host model, as well as some other limitations in terms of high availability deployments, but it is almost exactly the same product as we would host for you through PHI.  This is an ideal setup for the smaller development teams that do not have SLA’s on their Agent and wish to prototype features.  We have found this scenario to easily handle a large percentage of Agent traffic in the field today.  Again, this model enforces that the Agent SDK is in place to connect to Messenger as a provisioned Agent.

 

 

IDE

We have completely moved away from the custom made IDE that all projects up to the 4.3 release of our platform used. Instead, we now have a solution fully integrated in Visual Studio as an add-in.

 

Full details on the new IDE are found in our documentation and on our blog.  Some quick highlights of features to look out for:

·         Conversation and comprehension windows redesigned to better show the inner workings of how query matches are done

·         Solution explorer to navigate your project

·         Colorization and IntelliSense support

·         Object browser for viewing all objects declared in your project

·         Full integration with our Partner Hosting Infrastructure (PHI). For example, seamlessly check in and check out your PHI projects.

·         And more…

Migrating a Project from 4.3 to 5.0

We have developed a script that helps to convert a project from 4.3 and make it compatible with our 5.0 release. The script basically creates a .connections file based on the language dependencies it reads in from the .dls file, updates obsolete references to the old Buddyscript libraries, and updates the .dls file.

 

An important thing to note is that the script will overwrite your current project directory. To be safe, you should backup your project directory before running the script.

 

The script is located in your Windows Live Agents SDK install directory (default location is in Program Files) at:

 

Windows Live Agents SDK\Projects\ProjectConversion\ConvertProjectTo5_0.bat

 

Drag and drop the project directory you wish to convert onto the .bat file, or double click the .bat file and enter the project directory path.

 

Note: The conversion script will not necessarily  address every issue. You will most likely have to do some manual work after running the conversion script. But it will still save you quite a bit of work.

 

PHI

Overview

Partner Hosting Infrastructure, or PHI, is a tool that will allow developers to apply for Microsoft to host their Agent projects. Developers will be able to upload their code, manage projects, and be informed of the current state of their projects.  This section will go over the tools that developers have available to them when developing a project, taking it live, and making changes to project files.

It allows developers to :

·         Submit a project application

·         Check in code for that Project

·         Stage and Test your Project

·         Go Live with your Project

 

How to modify your Project

Once your project is hosted at Microsoft, you have two options available to you when you would like to modify files in your project.

 

Using the Console

You can use the KMS Console at https://sampleProj.console.agents.live.com  to modify the project. This will allow you to edit topics and responses fairly easily. For more control, however, you would want to use the IDE to make project changes.

 

Using the IDE

You can use the IDE to check in files in the same way that you checked in the project originally. Please note that using the IDE will check in an entire project, and does not allow you to check in just a single file.

 

To check out using the IDE, you must first sign in with your Windows Live ID and acquire a project lock by clicking on Tools à Windows Live Agents Tools à Code Management à Check Out Project. You can then edit whichever files you wish. While a project is checked out to you, no one will be able to edit any of the project files using the IDE or KMS.

 

To check in, click on Tools à Windows Live Agents Tools à Code Management à Check In Project.

 

Checking In the Connections File

When you check in the connections file, it must be reviewed and approved before being hosted or going live in the data center. Check in the connections file as you would check in any other file (see directions above).

 

Checking in your project when the .connections file has not been modified will not trigger a review. Those changes should propagate immediately.

The standard reporting suite on the Knowledge Management Console covers the most important metrics -- Unique Users, Total Sessions, etc. However, you'll often want (or be asked) to provide additional reports based on the special needs of the customer and/or the particular tasks of the agent. This article won't cover all the details of configuring usage reports, but will hopefully demonstrate how to log a simple data point and have it show up on the console as a graph or table.

 

Before configuring usage, we should look briefly at how logging works. The agent's log is an object variable called SYS.Log -- anything written there is a candidate to show up in usage reports. This is completely separate from the User Profile: the agent may store the user's birthplace in a variable called G_USER.birthplace, but it won't show up in usage unless we also write it to, for example, SYS.Log.birthplace. It is also completely separate from the server component logs on the console.

 

So let's actually use birthplace as our example, and look at what we need to record and display that statistic.

 

Say we have a procedure called CollectBirthplaceFromUser() that takes care of collecting the user's birthplace and resolving it into a valid place name we can record.

 

 

WriteBirthplaceToProfile assigns the value of BIRTHPLACE to G_USER.birthplace. LogBirthplace writes the same value to the SYS.Log.birthplace variable.

 

 

Now that we're confident birthplaces are being collected and logged, let's move on to configuring Usage. We do this by editing a file at the root directory of the project, called usage_config.xml.

 

usage_config.xml controls the presentation of log data in the Usage Reports section of the console.  It's completely separate from the actual logging of data -- we can log something in the BuddyScript, for example, but not add the necessary sections in usage_config.xml for another month, at which point the data the agent has been logging for the last month will be displayed. However, the opposite is not true -- adding a section in usage_config.xml doesn't cause data to be collected.

 

There are two main parts: a "sections" element containing all the configuration options for the usage reports, and a "usagestats" element containing the variables and datapoints to be used in the sections element.

 

The sections element itself contains two subsections labeled "all_ids" and "individual_id", which correspond to views of usage statistics broken out by individual buddyid or all buddyid's combined, exposed as a drop-down list in the console. First we'll look at the all_ids section, which is somewhat simpler than the individual_id section.

 

The first section here is called Volume Summary, and contains a number of elements for reporting usage data. You can get a good idea of the syntax we'll be using later by examining this section.

 

 

The "name" identifier is the text displayed on the console, the "key" is the datapoint, "calc-type" can be normal or something else depending on whether we want to perform some math on the number before displaying it, "subkey" is the other datapoint to use when calc-type is not normal, "default-graph-state" toggles whether a particular element shows up on the graph, "graph-type" controls what kind of graph, if any, to display the data on. In this case, multiple elements are sharing a "barline" graph -- a combination bar graph and line graph where the user selects which data goes on the bar, and which goes on the line.

 

We could add our own section for birthplace, but it turns out there is already a section for demographics, so we'll just add an element within that section:

 

  <element name="Birthplace Distribution" key='[birthplace][%]' keyName="Birthplace" valueName="Sessions" calc-type="distribution" graph-type="pie" display-type="percentage"/>     

 

This will pull all the values of SYS.Log.birthplace and display them in a pie graph, distributed by the number of sessions they occur in, along with a key. ("name", "keyName", and "valueName" are all labels and have no effect on the display of the data.) [%] represents a wildcard, meaning "all values of birthplace" -- we could choose instead to report on only [birthplace]['New York'], for example. 

 

Since there are potentially a large number of birthplaces (depending on how smart CollectBirthplaceFromUser is), it probably makes sense to dispense with the graph, and just display a table:

 

  <element name="Birthplace Distribution" key='[birthplace][%]' keyName="Birthplace" valueName="Sessions" calc-type="distribution" display-type="percentage"/>     

 

That's all we need to do for the all_ids section. For the individual_ids section, because we'll be filtering by buddyid, we need to go to the bottom of the file and add a datapoint:

 

 

First we create a variable called userBirthplace, which is assigned the value of SYS.Log.birthplace. Then we create an hourly bucket for that data with a key for pulling the number of sessions within a particular buddyid where a particular birthplace was recorded. In the demographics section of the individual_id section, we'll add this:

 

 

This is similar to the element we created for the all_ids section, but birthplace (userBirthplace=%) and buddyid (buddyid=%var:buddyid%) are interpolated into their actual values, and we see only the number of sessions for a birthplace recorded for the buddyid currently selected. Now we can use the buddy dropdown on the console as a filter.

 

In practice, displaying a list of arbitrary names of places is not going to be very useful because there are many thousands of place names the user can enter. We'd probably want to constrain the list to countries, states, or other large areas, depending on the mission of the agent. Still, this example will hopefully get you started experimenting with Usage, which is the best way to learn. Chances are, usage_config.xml probably already contains most of the necessary pieces for whatever report you need to create.

Hi All,

 

I know a lot of folks have been waiting diligently for the new version of the SDK.  We have finished the product and are in the midst of deploying the platform in our data center now.  Once we get the final approval from Operations, we'll publish a link to the SDK and you'll be on your way!

 

Thanks for you patience and we look forward to you using the SDK!

 

Windows Live Agents team