Share via

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 ;-)

Comments

  • Anonymous
    May 26, 2006
    Great summary!  

    I'd also be interested in hearing about the recommended approaches for migrating a MSS 2004 SALT application to a MSS 2007 VXML application.  I realize that any static/dynamic markup served up by my application will have to be rewritten, but am assuming that speech controls like a QA will now be able to generate either SALT or VXML.  

    A blog on this topic would be great.  Or, if you can point me to any doc related to this in the Beta, that would work too.
  • Anonymous
    June 05, 2006
    Hi Jeff,

    Sorry for the delay in responding your questions. Here’s the reply from our program management team: “Our research and discussions with VXML developers showed that having an outstanding VXML editor would be the most useful integration. We also found that the majority of SALT and VXML developers would not “cross-over” their applications. Consequently, we have no plans to support VXML generation from the QA controls. Our VXML editing is support through the ASP editor with Intellisense support.

    One anticipated scenario was a developer using SALT and VXML applications side by side in one logical application (leveraging pre-existing work, etc.). You can do this with the Dialog Workflow Designer by placing activities which allow you to consume your pre-existing SALT or VXML applications. If having a web application isn’t a requirement it would be easy to replicate your application using the Workflow Designer.

    During Beta is our time to get candid feedback on our product and direction; we’d love further amplification of your requirements.”