Toolbox Components

Now let’s look at the components on the Toolbox that you use in the course of your application development. First, there are a couple of warnings. On your Toolbox, you might see tabs for Windows Workflow 3.5 or even a Windows Workflow 3.0 tab.

However, there are a few exceptions. You can (and will) use the Windows Workflow v3.0 Code and IfElse activities to add branching logic and the capability to add code blocks your workflow. The IfElse activity gives you the capability to make decisions and send your calls down different logic branches. When the Code activity is dropped into your application, you can attach code behind to do such things as query a database and handle other programming tasks in your application.

A quick look at the Toolbox, which is shown in Figure 21.8, shows that the activities are grouped logically in three or four groups.

Figure 21.8 Toolbox

The first group of activities handles call control. In this group, you find activities for accepting a call (AcceptCall), transferring a call (BlindTransfer), making outbound calls (OutboundCall), and hanging up a call (DisconnectCall). This group of activities enables you to control how your application handles a call. For example, after accepting a call, you might want to prompt the user with a menu of phone extensions that he can select to get information about your business or products. After selecting from the menu prompt, send the call to the correct department using the blindTransferActivity.

You also see activities for handling call events such as CallDisconnectEvent or the CallOnHoldEvent. This group of activities enables you to control how your application responds to typical events that occur in a phone call or IM, such as the caller hanging up or closing the IM chat window. You can also use these activities to log the caller information or update a SQL database with the results of the call.

Next you see the CommunicationsSequence activity, which is the basic container in which you put all the other activities that make up the application call flow. This activity knows and understands the concept of a call and is necessary to keep the call alive.

Following that you see a GetPresence activity along with a Goto activity. The former enables you to get the presence status of a user and comes in handy for deciding how to deal with a caller. For example, the party you want to transfer the call to might have her presence showing as Busy, so you can send the caller to the target’s voicemail rather than opening an IM chat with the caller.

The gotoActivity gives you an easy way to divert your call flow to some other place in your Workflow logic. Although you can almost always use nested IfElse activities to control your logic, this can cause your Workflow to get quite large and hard to understand. Use of the gotoActivity simplifies your Workflow, making it easier to read and maintain.

The next two groups are similar in functionality. The first group handles voice calls and the second group duplicates the same functionality for IM chats. With the right branching logic, you can have your application handle both.

Notice two activities that interact with the user. The first SpeechStatement enables you to play a message to the caller. Think of this as a greeting or providing instructions. The application plays its prompt and simply moves on without expecting user input.

If you want to ask the caller something or give the caller choices, use the SpeechQuestionAnswer activity. This activity does exactly what its name implies: It asks the caller a question and receives the caller’s answer. You can use this activity to find information, such as what type of pizza the caller wants or the caller’s account number. After you drop this control into your Workflow, set the prompt (your question) and then attach a grammar that controls the acceptable inputs nine answers. Grammars are XML files that list the allowed user input and assign the values the speech recognition engine will return to your application. For example, if you ask the caller what type of pizza she wants, your grammar would have choices, such as “cheese,” “pepperoni,” “meat lovers,” or “deluxe.”

The different command activities, such as SpeechHelpCommand and SpeechRepeatCommand, are activities that handle global commands and are normally scoped to the whole Workflow. However, when you nest CommunicationsSequence activities, they can be scoped to individual CommunicationsSequence activities to change the behavior for the container. They enable the user to say “Help” or “Repeat,” and you can use the SpeechCommand activity to create your own command such as one that responds to the user, saying “Operator.”

The command activities are active anytime there is speech recognition taking place. For example, if you ask the user what type of pizza he wants to order and during recognition the caller says, “Operator,” your application can respond accordingly and direct the caller to a live person. Using commands like this keeps you from needing to add “Help,” “Repeat,” or “Operator” to all your grammars.