SALT in Skagit (Part 2)

  • Article

POSTED BY: GUNNAR KUDRJAVETS, MSS Software Design Engineer

ALAN TURNQUIST, MSS Software Design Engineer

Migrating your SALT applications to MSS 2007

If you’re starting to use the Beta version of MSS 2007 then there are three different ways to deal with your existing SALT applications:

  1. The simplest approach is to leave your SALT application as it is. Don’t change anything; don’t port your application to ASP.NET 2.0; just leave it be. You’ll need to make sure that your application is running inside an application pool which is running ASP.NET v1.*. To verify this you can use IIS Manager and after selecting “Properties” for your application check the “ASP.NET” tab. Also please note that it’s not possible to run different versions of ASP.NET in the same IIS process. We’ve done extensive performance and stress testing using this scenario as we expect that this will be the common migration path for MSS 2004 applications which won’t undergo any further development.
  2. Migrate your application from ASP.NET 1.* to ASP.NET 2.0. This includes converting your Visual Studio solution, updating references to the Speech Controls version number, making any changes necessary (look at ASP.NET upgrade guide), recompiling, and redeploying your application.
  3. Wrap your application into managed code. MSS 2007 provides a new managed API for developing speech applications and an even higher abstraction level to write speech applications using Workflow Designer. The API exposes SaltInterpreterActivity class which is designed to be a managed wrapper around the SALT applications. This option is beneficial if you want to reuse some components of your existing SALT applications in your existing managed applications. For example: you may have a significant portion of call flow written in SALT and for various reasons you don’t see any point in rewriting this using managed API.

This is just a short overview of the available options. The MSS 2007 Beta release includes a document called “Migrating Applications to MSS 2007” which describes all of these options and combinations between them in greater detail. Any feedback about this document is welcome and will be extremely helpful in making everyone’s experience while migrating SALT applications as smooth as possible.

Using the SaltInterpreterActivity class

A SaltInterpreterActivity is used to execute markup applications written in SALT. The usage pattern is to create the workflow that contains this class, set the start page and application data, if any, and then use SaltInterpreterActivity the same way as any other speech activity. There are two main purposes for using SaltInterpreterActivity class: using it as a managed wrapper for an existing SALT application and integrating existing SALT applications with the new managed speech and telephony applications.

Using SaltInterpreterActivity to wrap an existing SALT application is relatively trivial. In Visual Studio:

  1. Create a new speech workflow application. Choose “File | New | Project | Speech | Speech Workflow Application”.
  2. Fill in the necessary information and click “OK”.
  3. Check or uncheck the options you need and click “OK”.
  4. Make sure that Toolbox is visible by selecting “View | Toolbox”.
  5. Select the “answerCallActivity1” workflow element and delete it. Do the same for the “disconnectCallActivity1” element.
  6. Drag a “SaltInterpreter” element from the Toolbox to the canvas.
  7. Click on “saltInterpreterActivity1” and specify the “StartPage” property to point to the URI of your existing SALT application.

Deleting the telephony activities generated by default was necessary to ensure that the TelephonySession.State will be TelephonySessionState.Incoming when SALT application is started up. In MSS 2004 the SALT application development model required that an application itself handle the telephony related operations (accept, decline, disconnect etc.) In the Beta version of MSS 2007 the default speech workflow application will accept the call by default, which is incompatible with the design of the existing SALT applications.

In case you want to integrate your existing SALT application into your new managed application (which already has accepted the call), some changes to the SALT application are required. The state of the TelephonySession won’t be TelephonySessionState.Incoming and therefore you need to change the part of your SALT application which in MSS 2004 was responsible for communicating with the TIM via CSTA messages. In MSS 2007 those messages are handled by MSS. Here is a typical CSTA message sequence (for the inbound case) between the SALT application and the TIM:

  1. MonitorStart from SALT application; TIM responds with MonitorStartResponse.
  2. SetAgentState from SALT application; TIM responds with SetAgentStateResponse.
  3. DelieveredEvent from TIM, notifying the SALT application that an incoming call has arrived.
  4. AnswerCall from SALT application; TIM responds with either CSTAErrorCode or EstablishedEvent.

After sending those messages and receiving the corresponding successful responses back from the TIM/MSS the call is considered to be answered/accepted/established and the application is ready to begin automated dialog interaction.

If you are integrating your existing SALT application into managed application then TelephonySession.State will be TelephonySessionState.Connected and you do not need to send all of those messages anymore. Your application can start the execution as if it received the EstablishedEvent which would be the indication that the call was established successfully in the common case.

Next time: Minor changes we’ve made to SALT, a list of common problems you may encounter while porting your SALT applications over. I planned to publish this information with the current entry, but I would rather take some time and double-check the facts once more. It’s time-consuming to be paranoid ;-)