Windows Live Agents: 2007年11月

11月19日

SetOnDelayMessage()

Here is an interesting feature released in 4.1. Sometimes we need to return information that takes a long time to process (i.e. accessing a slow datasource), and we want users to know the agent is still going to respond.

In situations like this, SetOnDelayMessage() comes in handy. This feature allows any developer to display a message (after a number of seconds) while a query is being processed. The release of the message doesn't stop the process of the query, allowing the agent to keep interacting with the user.

If the query is resolved before the delay time, the message would never be displayed.

The syntax is:

call SetOnDelayMessage(DELAY_IN_SECONDS, MESSAGE_STRING)

The delay time can be set to 0 for immediate release, and starts counting from the beginning of the query. If more than one instance are used, the delay time will start counting from the beginning of the query for all of them.

Something important about this feature is that it can only be used while the agent is deployed using MSN service (so you can't test it from the query window.)

Following are some examples:

1. In this case, the message would be shown after 5 seconds, if the list doesn't get populated before.

? What are your products on sale right now?
MSG - Please wait while I look for current sales.
call SetOnDelayMessage(5, MSG)
- Currently on sale:
</blank>
GetListOfCurrentSales()

2. In the next example, we set more than one message to be shown.

? Where can I buy ITEM=AnyProduct in LOCATION=AnyLocation.
call SetOnDelayMessage(5, "Please wait while I process your request")
call SetOnDelayMessage(10, "Be patient! :-) I'm still working on it.")
- You can find WHAT in:
ShowListOfStoresSellingAProductFromASlowDatasource(ITEM)

3. We could be even more imaginative, and use it as a progress indicator.

? Add all the numbers between 1 and 10.
for NUM in 1 to 10
    PERCENT = NUM*10
    MSG - PERCENT% completed
    call SetOnDelayMessage(0, MSG)
    TOTAL = TOTAL + NUM
- All the numbers between 1 and 10 total TOTAL.

23:18 | 添加评论 | 固定链接 | 写入日志

11月16日

Console User Release Notes 4.3

1 Introduction

These notes include broad descriptions of the major changes to the Management Console for version 4.3. The new features of 4.3 are:

Decision tree
Multiscope

2 Decision Tree

2.1 Summary

This feature allows the ability to create decision trees in the Knowledge Editor. Decision trees are used when cascading dialogues are required. One common scenario where decision trees will be used is troubleshooting problems.

When creating or editing a topic, the user has the option to make the response type “decision tree” and then build the outputs, choices, questions, and responses for the nodes of the tree. This release includes supporting features that give users the ability to:

Move nodes around via copy and paste
Insert nodes in the middle or at the top of the tree
Apply the “insist” condition that forces the user to select one of the given choices

2.2 Decision Tree Overview

Decision trees are made up of nodes. There are four types of nodes possible in a decision tree.

Decision Tree Root – this is the top of decision tree. Every decision tree has exactly one root.
Decision – this node type corresponds to the point at which the end user has to make a decision among choices.
Choice – these nodes represent the choices available for each decision.
Resolution – this is the end point of a particular branch in the tree.

Here is how the node types correspond to a decision tree diagram:

In Manage Topics, the UI for the decision tree editor has two panes. The structure of the tree is displayed on the left pane. When a node of the tree is selected in the left pane, the properties of that node are displayed on the right pane. Thus, the actions that take place in each pane are:

2.3 Building the structure of the decision tree

Creating a new topic with decision tree

To create a new topic with decision tree, click on the Create New Topic link and in the Response Type drop down, select the new “decision tree” option. A default decision tree with the Root element and first Decision node is shown.

Menus

Each type of node (except for Decision Tree Root) has a menu that you access by right clicking on the node. The menu will give the options to add, delete, or modify nodes. This is how you create the tree structure. When a new topic is created, begin building the tree by right clicking on the Decision node that appears.

Decision node menu

Choice node menu

Resolution Node menu

2.4 Set properties for each node

When you select a node of the decision tree on the left pane, the properties of the node appear in the right pane. In the right pane is where you add/modify/delete content and the other properties associated with the node. The right pane is different for each node type.

Root node properties:

Decision node properties

Choice node properties:

Resolution node properties, type “inline”:

Resolution node properties, type “reference” (when you reference another topic):

2.5 Decision tree example

Below is an example of a decision tree and how its structure would look in the UI.

2.6 Warning icons for incomplete decision tree

As you are creating the decision tree, a warning icon will appear on each line where content needs to be added in order to complete the tree. This is meant to make it easy for you to see where there is missing content (that would thus result in error scenarios for end users talking to the agent).

2.7 Decision tree preview

On the Preview tab, you will see the decision tree text shown in hierarchical format.

2.8 Usage Reporting

Decision tree data is defined by keys. Keys are [DecisionTree][DTName.A.B.C] = # where A.B.C is the path and # is the number of users that went down that path.

These keys must be defined in usage_config.xml. The following example shows the format.

<match>^\[DecisionTree\]\[Breakfast\.([^\.]+)\]$</match>

</set>

<value>value(breakfastfirstchoice)</value>

</datapoint>

<value>

value('[DecisionTree][Breakfast]') - value('[DecisionTree][Breakfast.Cereal]')- value('[DecisionTree][Breakfast.Pancakes]')- value('[DecisionTree][Breakfast.Nobreakfast]')

</value>

</datapoint>

For the data to appear in the console UI, add in usage_config.xml per usual:

Once your keys are defined in usage_config.xml, commit the file and publish the agent. Once the usage data has updated, click on the new Decision Tree link in the reporting section to see the numbers and percentages of end users that went down decision tree paths.

3 Multiscope

3.1 Summary

Scopes are used to categorize or tag topics. The purpose is to tailor topic questions and responses based on scopes to provide better end user experiences. Here are some example scopes and scope elements:

Scopes apply not only to topics, but also to end users. When an end user’s scope matches a topic’s scope, that will result in the end user seeing that topic.

Scopes perform two main duties:

They affect what the end user sees by affecting what topics match the end user’s queries.
They affect what console users can see and edit. For instance, a console user may be able to browse topics with only certain scopes, and may be able to edit a subset of those topics (those with a subset of the scopes he may see).

3.2 Create a Scope-Enabled Agent and Define Scopes

Creating a scope-enabled agent is as simple as adding a “scope definition” to the DLS of the agent.

1. Create the agent (if it’s not already created).

2. Modify the <agentname>.dls file to either include another dls that contains the scope definition, or include the scope definition directly in the <agentname>.dls file. We recommend the former only because it seems cleaner to completely separate that scope definition from the rest of the DLS (but it’s a personal preference).

Adding an include to an existing DLS:

1. Add the following line to the existing <agentname>.dls (inside the <domain-list> tag):

<import>scopesets.dls</import>

2. Create a scopesets.dls file (in the same directory as the <agentname>.dls file) and make it look like this:

<domain-list>
<scope-sets>
…your scope definition…
</scope-sets>
</domain-list>

Adding the scope definition directly in the existing DLS:

1. Modify the existing <agentdata>.dls file by adding a <scope-sets> tag under the <domain-list> tag:

<domain-list>
<scope-sets>
…your scope definition…
</scope-sets>
…the rest of the DLS file as before…
</domain-list>

A scope definition looks like this:

1. One <scope-sets> tag

2. Inside of that, one or more <scope-set> tags

3. Inside of each of those, one or more <scope-element> tags

4. Inside of the <scope-set> tag and following the <scope-element> tags, zero or more <scope-element-group> tags

5. Each scope-set, scope-element and scope-element-group have names (pretty names to display), and ids (the actual values we store)

a. for scope-elements, the pretty name is actually the text of the tag, not an attribute (like scope-set and scope-element group)

b. the text of the scope element group is the list of all ids of all scope-elements included in the group

You can have an unlimited number of scopes. For each scope, you can have an unlimited number of scope elements. You can also have scope element groups such as “Western U.S.” which contain elements like California, Washington, etc. You may put a given element into multiple groups.

Example:

<scope-sets>

<scope-set name="Division" id="division">

<scope-element id="template">Template</scope-element>

<scope-element id="us_north">US North</scope-element>

<scope-element id="us_south">US South</scope-element>

<scope-element id="us_west">US West</scope-element>

<scope-element id="us_east">US East</scope-element>

<scope-element-group id="us_all" name="All US">us_north us_south us_west us_east</scope-element-group>

<scope-element id="ca">Canada</scope-element>

<scope-element-group name="All Divisions" id="all_div">all -template</scope-element-group>

</scope-set>

<scope-set name="Product" id="product">

<scope-element id="sd200">SD 200</scope-element>

<scope-element id="sd300">SD 300</scope-element>

<scope-element id="sd400">SD 400</scope-element>

<scope-element id="sd500">SD 500</scope-element>

<scope-element id="elura">Elura</scope-element>

<scope-element-group name="All SD Cameras" id="all_sd">sd200 sd300 sd400 sd500</scope-element-group>

</scope-set>

</scope-sets>

3.3 Scope Editor

In the console, the Scope Editor is used whenever you need to select scopes. The Scope Editor appears in multiple places in the console.

Modify scope elements

The left side of the Scope Editor shows all scope sets and elements that apply. The scopes appear at the top and then subgroups and elements appear underneath each scope.

If a subgroup or element is preceded by a “+”, that means it is part of the scope set.
If a subgroup or element is preceded by a “-“ or blank, that means it is not part of the scope set.
To add or subtract a subgroup or element, click on the subgroup or element name. The items that you add or subtract are shown in the Preview panel on the right.

3.4 Set Console User Scopes

Every console user has a read scope mask and a write scope mask. The read scope mask determines topics that the user can see. The write scope mask determines the topics that the user can create, modify, and delete if the user has the proper roles. Scope masks are completely independent of roles.

Console user scope rules:

Each console user’s write scope mask is equivalent to or a subset of the user’s read scope mask.
The person granting console user permissions can only grant read and write scope masks that are equivalent to or a subset of his/her own read and write scope masks, respectively.

On the Console User Settings page, for each scope-enabled agent to which you have access, you’ll see boxes where you can edit read and write scope masks.

To modify read or write access, click on Edit. This will bring up the Scope Editor where you can edit all scopes. Alternatively, you can click on the down arrow next to each scope to edit just that scope.

3.5 Read and Write Topic Scopes

For every topic, there is a new “Scopes” tab that shows the scopes to which the topic belongs. When you’re in Edit Topic mode, this is also where you change a topic’s scopes. Click the Edit link to bring up the Scope Editor or use the arrows to edit individual scopes.

3.6 Clone Topics

When you want to modify a topic for certain scopes, you can use the Clone Topic function. When you clone a topic, the clone sits in a layer above the original topic and overrides the original topic for the chosen scopes. This is best illustrated using an example.

Simple Example

Example: You have a topic called International Rates that has the scope Language = All. You want to change the response for all French languages and leave it as is for all other languages.

Steps:

Go to the International Rates topic.
Click on Clone Topic.
The Scope Editor will appear. Choose the scopes of your new topic. In this case, change the Lanuguage scope element from “All” to “All French Languages”.
Your clone will appear. Modify the response for your clone and save.
In Manage Topics, you will now see two topics called International Rates. Go to the Scope tab of the original topic, you’ll see that the clone is “above it." Go to the Scope tab of the clone, you’ll see that the original topic is “below it."

Scope matching goes from top to bottom. A cloned topic overrides any topics below it.

Result: End users with a Language scope that is French/Belgium, French/France, and other French will see the reponse of the clone. All other end users will see the response of the original topic.

Add more clones (create more topic layers)

If you were to clone the clone to have yet a different response for French/Belgium, the third topic would sit above the second one.

You can have as many layers you want. You can delete layers any time.

When you clone a topic, the clone always sits directly above the topic being cloned. Sticking with the example, if you again clone the original topic (Language = All Languages) and make the scope of this clone Language = French/France, the layers would be

The scope matching always goes from top to bottom so top layers override layers below it. In this case, users with French/France would see the Middle 1 topic (All French languages) since this overrides the Middle 2 topic.

See topic layers

If a topic has layers above or below it, these will be displayed in the Scopes tab.

3.7 Approve Topics

You will see topics as allowed by your write scope. The scope chooser has been added so you can filter topics by scope. “Approve all” approves all the topics under your write scope.

3.8 Test Matching

The ability to select the end user’s scope mask has been added. Using the arrows on the right side, select the scope elements on which to perform the match. Since end users can have exactly one element per scope (for example, user’s Language scope is either English or French, not both and not All Languages), you are able to choose one element per scope only.

3.9 Talk to Agent

When you first go to Talk to Agent, a dialog will pop up where you can select the initial scope of the user talking to the agent.

3.10 Quality Analysis, Task List, Usage Reporting

The changes to these areas of the console are:

Quality Analysis – console users will see topics according to their read scope and be able to write to topics according to their write scope. Otherwise, there are no changes to this section.
Task List – console users will be able to write to topics according to their write scope. However, they will be able to see all topics (not restricted by read scope).
Usage Reporting – there are no changes to this section. Scopes have not been incorporated in this release.

17:38 | 添加评论 | 阅读评论 (5) | 固定链接 | 写入日志

11月12日

Getting more chat out of less with randomness

One goal in developing an agent is coverage -- that is, we want the agent to be able to answer a large number of questions without resorting to "catch" messages like "I'm sorry, I didn't understand that." Once we have this coverage, however, it's important to make these responses interesting and as human as possible. An agent that has one answer for every question is pretty boring compared to an agent that has ten. This article covers how to use randomness utilities and the platform's built-in randomness functionality to multiply the number of responses available.

Without including any special packages, we can double the number of responses to a question by simply adding one. For example, say we have a procedure that holds responses for queries about what foods an agent likes:

procedure WhatFoodDoYouLikeAnswer()
- I really like sushi.

If we add responses, the agent will automatically choose a random one on the list.

procedure WhatFoodDoYouLikeAnswer()
- I really like sushi.
- I like fish tacos.

This is good, but can be pretty time-consuming. However, we can use this built-in randomness to construct sentences using "\c", which means "continue without inserting a line break."

procedure WhatFoodDoYouLikeAnswer()
- I like \c
- I really like \c
nop
- sushi.
- fish tacos.

The "nop" (no operation, same as "do nothing") is used here to break up the list. The agent chooses from the two responses on top, then adds one of the two from the bottom. There's not much time saved yet, though, since we only have four possible responses for the four lines we've written:

I like sushi.

I really like sushi.

I like fish tacos.

I really like fish tacos.

We can continue in this way, perhaps randomizing punctuation.

procedure WhatFoodDoYouLikeAnswer()
- I like \c
- I really like \c
nop
- sushi\c
- fish tacos\c
nop
- !
- .
- ! :-)

Now we have a lot more responses:

I like sushi!

I really like sushi!

I like fish tacos!

I really like fish tacos!

I like sushi.

I really like sushi.

I like fish tacos.

I really like fish tacos.

I like sushi! :-)

I really like sushi! :-)

I like fish tacos! :-)

I really like fish tacos! :-)

Still, the agent basically likes sushi or fish tacos. Let's include this package for some more options:

package lib:/Shared/Utilities/RandomnessUtilities

One of the tools we can now use is the function SelectRandom. If we pass a few choices as parameters, it will return one randomly.

procedure WhatFoodDoYouLikeAnswer()
- I SelectRandom("like", "love", "adore", "can't live without") \c
nop
- sushi\c
- SelectRandom("fish", "hot", "beef") tacos\c
nop
- !
- .
- ! :-)

Now let's look at our number of outputs for 9 lines of code.

I like sushi!
I like sushi.
I like sushi! :-)
I love sushi!
I love sushi.
I love sushi! :-)
I adore sushi!
I adore sushi.
I adore sushi! :-)
I can't live without sushi!
I can't live without sushi.
I can't live without sushi! :-)
I like fish tacos!
I like fish tacos.
I like fish tacos! :-)
I love fish tacos!
I love fish tacos.
I love fish tacos! :-)
I adore fish tacos!
I adore fish tacos.
I adore fish tacos! :-)
I can't live without fish tacos!
I can't live without fish tacos.
I can't live without fish tacos! :-)
I like hot tacos!
I like hot tacos.
I like hot tacos! :-)
I love hot tacos!
I love hot tacos.
I love hot tacos! :-)
I adore hot tacos!
I adore hot tacos.
I adore hot tacos! :-)
I can't live without hot tacos!
I can't live without hot tacos.
I can't live without hot tacos! :-)
I like beef tacos!
I like beef tacos.
I like beef tacos! :-)
I love beef tacos!
I love beef tacos.
I love beef tacos! :-)
I adore beef tacos!
I adore beef tacos.
I adore beef tacos! :-)
I can't live without beef tacos!
I can't live without beef tacos.
I can't live without beef tacos! :-)

As a final touch, we can use the CoinToss function (which returns "true" half the time) to choose one type of response or another. So, half the time the agent will say what kind of food it likes, the other half of the time it will ask the user what they like:

procedure WhatFoodDoYouLikeAnswer()
if CoinToss()
    - I SelectRandom("like", "love", "adore", "can't live without") \c
    nop
    - sushi\c
    - SelectRandom("fish", "hot", "beef") tacos\c
    nop
    - !
    - .
    - ! :-)
else
    - I don't know, \c
    - I'm not sure, \c
    - Hmm... I don't really know, \c
    nop
    - what do you like?
    - what kind of food do you like?

There are other functions in the RandomnessUtilities package, like MakeShuffledList and PercentChance, that give you even more flexbility. However, even without using those functions, it's possible to create a huge number of responses by thinking in terms of randomizing sentence parts instead of entire sentences. Your users will appreciate the added intelligence.

16:00 | 添加评论 | 阅读评论 (2) | 固定链接 | 写入日志

Natural Language and Agents

So you wanna build an agent... Why not build a traditional web application? Web apps are commonly used and well understood. They offer you more display real estate, and more options for input and display.

But perhaps you have functionality that is better served by language commands than by clicks and drags. You want your user to be actively engaged with your advertising. Or you want to ask questions of your users, and you want your users to ask questions. Or you want users to find the information they're looking for just by typing a single sentence. In other words, you want a *natural language interface*.

Enter, your Windows Live Agent! You are the proud owner of a shiny new natural language interface. Now... how do you use this thing?

As with any application, an intuitive user interface is critical to the success of an agent. The interface should make it as easy as possible for the user to get what he or she wants out of the agent. How do you do that? Let the user *tell you* what he or she wants, in any form, without using special commands. This is the need that the WLA platform serves, yet people often forget it! We see countless agents written like command line interfaces. Here's a typical example:

User: what can i do?

Agent: Here's what you can do!

1. Get the latest news.

2. Play a game.

3. Give feedback.

Type a number from the list.

Here, we discourage the user from using English altogether! It might be equally effective to display this functionality as links on a webpage. Here's a slightly more natural example:

User: hey what's up

Agent: Want to see the latest news? Just type "news".

This gives the user the impression that typing "news" is the only entry point to the news feature, when in fact you could also type "let's see the news" or "latest news". You are in effect teaching your user to learn commands for your application. Instead, why not use a dialogue?

User: hey what's up

Agent: Want to see the latest news?

User: sure.

Agent: Okay, here it is...

By restricting your user's input, you also lose the benefit of easy user feedback – the ability to see exactly how users want to use your agent and what they want out of it. It could be that your users want functionality for "show me the news for the last 3 days" or "show me local news for Boston".

Unfortunately, it's not enough to provide the natural language handling behind the scenes, we also have to actively encourage users to break out of the typical "keyword search" mode. Here are a couple suggestions:

-Avoid menus if possible

-Work on your "natural" language style. Encourage users to act as they would in a normal conversation, by doing so yourself. Don't use "type this" – just let users type their request as they would normally ask for it.

Give it a try, and see the difference it makes in your conversation logs.

11月5日

Configuring an Agent for Deployment (Part 4 - Adding Screen Names)

Adding Screen Names

Here’s FooAgent’s configuration as viewed in the web console.

For each service, we should change the login, password, friendly name, contact-card, and if necessary buddyicon directives.

If you get a message about the dual-box parameter when validating or attempting to save, select the option to force save.

11:49 | 添加评论 | 阅读评论 (1) | 固定链接 | 写入日志

Configuring an Agent for Deployment (Part 3 - Removing What You Don't Need continued)

Now we just have FooAgent_en, which has two services:

The first is launched by the DS’s, which run either under the Deploy or dualbox filters. The second is launched by the KMS, which always runs under the KnowledgeManagement filter. The only thing we need to worry about, though, is entering screen names and other IM-related details. But first let’s continue removing extra stuff, and look at FooAgent.dls.

We’ll remove all non-English filesets, all non-English buddies, and all non-English language sets, leaving us with:

<domain-list import="/Shared/SharedSettings.dls">

</deployments>

<file-sets>

<file-set id="SharedRephrasings">

lib:/Shared/Core/Rephrasing/*.ddl

</domain>

</file-set>

<file-set id="SharedFiles">

/Variables.ddl

</domain>

/Shared/Overrides.ddl

</domain>

/Shared/Personality.ddl

</domain>

/Shared/Tests.ddl

</domain>

/Shared/Chat/*.ddl

</domain>

lib:/Shared/Core/Vocabulary/VocabularyAnalysis.ddl

</domain>

lib:/Shared/Utilities/TestUtilities.ddl

</domain>

</file-set>

<file-set id="English">

/English/Chat/*.ddl

</domain>

/English/UserInfo/*.ddl

</domain>

</file-set>

<file-set id="KnowledgeManagementFiles">

<file-set-ref id="Chinese" />

<file-set-ref id="English" />

<file-set-ref id="French" />

<file-set-ref id="German" />

<file-set-ref id="Italian" />

<file-set-ref id="Japanese" />

<file-set-ref id="Spanish" />

<file-set-ref id="SharedFiles" />

</file-set>

</file-sets>

<language-sets>

<language-set id="English" default="1">

<file-set-ref id="SharedRephrasings" />

lib:/English/Core/Rephrasing/*.ddl

</domain>

/English/CustomRephrasings.ddl

</domain>

</rephrasings>

</language-set>

</language-sets>

<file-set-ref id="KnowledgeManagementFiles" />

/English/Main.ddl

</domain>

/English/Overrides.ddl

</domain>

/English/Tests_en.ddl

</domain>

</buddy>

<file-set-ref id="KnowledgeManagementFiles" />

/English/Main.ddl

</domain>

/English/Overrides.ddl

</domain>

/English/Tests_en.ddl

</domain>

</buddy>

<file-set-ref id="English" />

<file-set-ref id="SharedFiles" />

/English/Main.ddl

</domain>

/English/Overrides.ddl

</domain>

/English/Tests_en.ddl

</domain>

</buddy>

</domain-list>

We still need to fix this part:

<file-set id="KnowledgeManagementFiles">

<file-set-ref id="Chinese" />

<file-set-ref id="English" />

<file-set-ref id="French" />

<file-set-ref id="German" />

<file-set-ref id="Italian" />

<file-set-ref id="Japanese" />

<file-set-ref id="Spanish" />

<file-set-ref id="SharedFiles" />

</file-set>

We remove everything but “English” and “SharedFiles”.

Also, we should fix the buddy name:

That’s it! For the rest of our customization, we’ll use the local web console.

11:47 | 添加评论 | 阅读评论 (2) | 固定链接 | 写入日志

Configuring an Agent for Deployment (Part 2 - Removing What You Don't Need)

Removing What You Don't Need

Say we’ve just instantiated a project called FooAgent, which we intend to speak English and live on Messenger, and we have the following set of files:

First, let’s get rid of all the non-English directories.

Now, let’s take a look at FooAgent.bfg. Adding and removing configuration parameters and domain inclusions via the IDE is covered elsewhere, so I’m going to show you how to edit the actual files.

For each language, there is one Buddy, like “FooAgent_zh”. We’ll delete all the Buddies that serve specific non-English languages. This is what we end up with:

<buddy_launcher_configuration import="../BuddyScriptLib/KnowledgeEditor/KnowledgeManagement.bfg">

<ddl-dir>

$_BFG_DIR

</ddl-dir>

DeployKMS

</deployment>

Deploy

</deployment>

<domain-list>

$_BFG_NAME.dls

</domain-list>

<force-dirty-start only-in="KnowledgeManagement Deploy dualbox" />

<debug>

3

</debug>

</component>

<storage-mode>

sqlite

</storage-mode>

<caching-user-count>

500

</caching-user-count>

</component>

<buddy_launcher_settings>

<dual-box only-in="dualbox" />

<access-list>

$_BFG_DIR/opsauth.txt

</access-list>

</buddy_launcher_settings>

<login>

english_screenname_live_agent@hotmail.com

</login>

crypto:as0S5Cq9mxPQ6SI/D4AxEUYZpQ0Kzg==

</password>

<friendly-name>

Windows Live Agent® Template - Production

</friendly-name>

$_BFG_DIR/Shared/WLAIcon.png

</buddyicon>

<big-bot />

<contact-card>

I am the WLA Template Production Agent!

</contact-card>

<no-xfr-on-bounce />

</service>

<login>

english_screenname_staging_agent@hotmail.com

</login>

crypto:as0S5Cq9mxPQ6SI/D4AxEUYZpQ0Kzg==

</password>

2

</verbose>

<friendly-name>

Windows Live Agent® Template - Staging

</friendly-name>

$_BFG_DIR/Shared/WLAIcon.png

</buddyicon>

<contact-card>

I am the WLA Template Staging Agent!

</contact-card>

</service>

</buddy>

<meta_data>

<debug_deployment />

</meta_data>

</buddy_launcher_configuration>

11:45 | 添加评论 | 阅读评论 (1) | 固定链接 | 写入日志

Configuring an Agent for Deployment (Part 1 - Intro)

The last step before an agent goes live in the Microsoft datacenter is to submit the project files to the Windows Live Agents group, who make sure the project compiles and can be deployed in its current configuration. Unfortunately, many of the projects we receive compile fine but are misconfigured. Partners develop agents on their own machines and are able to launch them fine for testing purposes, but this doesn’t mean the agents are configured to work with our servers.

Here’s a high-level description of our hosting picture:

SVN ßà KMS ßàDS1, DS2 à IM Cloud, http, etc.

1. All projects live in an SVN repository.

2. The KMS, or Knowledge Management Server (sometimes called the Staging Server) is a full BuddyScript server with additional components for Usage Reporting, audits, and sometimes knowledge editing. The KMS has a web console just like the one that ships with the SDK, and can be used to launch agents, but it is not meant to handle production traffic or failovers.

3. The KMS checks the SVN repository every 5 minutes for changes. If it finds any, it checks out the project, merges the code, and recompiles.

4. The DS’s, or Deployed Servers (sometimes called Production servers), are BuddyScript servers that handle traffic to the production agent(s). There are at least two, one of which is logged into the Messenger cloud at any given moment, the other serving as a backup in case of failure.

5. When we hit the “Publish” button on the KMS, a snapshot of the version of the agent on the KMS is marked as “published.” The DS’s check the KMS periodically (usually every five minutes) for published changes. If it finds any, it picks up the agent code from the KMS and recompiles.

This model will change in the coming months, but for the time being it’s important to note that certain directives have to be in place in the agent’s configuration files for it to launch that may be unnecessary when you are launching the agent locally for limited testing. If the agent is misconfigured, we may fix it ourselves or send it back to you, but either way, some time is lost.

So what is the correct way to configure an agent? There is an easy way, and a hard way. The hard way is to copy an example project like HelloWorld or Tutorial, submit the agent, have it break, then try to figure out what’s missing.

The easy way is to use the instantiation script located here:

C:\Program Files\Colloquis\Colloquis SDK\Projects\WLATemplate\StartInstantiation.bat

After you tell the script the name of your project and the project files are instantiated, all you need to do to configure the agent is

1. Remove what you don’t need.

2. Add screen names.

11:39 | 添加评论 | 阅读评论 (3) | 固定链接 | 写入日志