none
Speech Server Workflow and WinForms RRS feed

  • Question

  • Hi,

    Is it possible to host a Speech Workflow within a WinForms application, in a similar way to 'normal' Windows Workflow components?

    I'm trying to extend our existing Call Centre software to take into account OCS, and need to be able to make Dial/Answer/DTMF requests from the Forms application. Ideally, I would have a library called by the application: this enables different libraries to be used depending on the call centre in question.

    I can write a normal forms app that runs a standard workflow when a button is pressed, yet can't get Speech workflows to run. If my form inherits from IHostedSpeechApplication, the Start method never gets called and I've no idea what IApplicationHost should be...

    Suggestions or thoughts?


    Thanks in advance.

    benw
    Thursday, July 5, 2007 10:33 AM

Answers

  • I think you're asking "can I somehow, from my WinForms workflow, get the MSS workflow app to Hold, Hang-up, etc", right? In theory, yes, you can. Basically you need some communication channel between the two apps (whether you use MSMQ, remoting, or whatever). You could, then, have the WinForms app trigger the MSS app, and then pass messages back and forth such that the WinForms app says "hang up now". That's all possible, but it's not something we've tried nor something we explicitly designed as a feature. I suspect you could make this work, but it will require a fair amount of work. You should also make sure that you are really doing things the right way; i.e., be sure that you really want to have the logic in the WinForms app rather than in the MSS app.

     

    Dan

    Thursday, July 5, 2007 8:20 PM

All replies

  • Hi,

     

    Unfortunately it is not possible to host a Speech Workflow inside of a WinForms app or anything other than its default host. The IHostedSpeechApplication.Start method is called by our hosting infrastructure when a call comes in or when an outbound call request arrives, and only our hosting infrastructure is able to create a valid IApplicationHost. If you are trying to make outbound calls, you could use the MSMQ functionality to communicate between a WinForms-hosted workflow and an MSS-hosted workflow. I.e., the WinForms app posts a message to a queue at some point and waits for a response in the response queue, and you have an MSS app registered to listen on that first queue, and then able to put a response into the response queue when it's done.

     

    Your scenario is, however, an interesting one, and we will keep that in mind as we plan the next version.

     

    thanks,

    Dan

     

    Thursday, July 5, 2007 3:01 PM
  • Hi Dan,

    Thanks for your reply

    I think the fact that both systems use WorkFlow (and they both appear in the designer at the same time) was leading me to believe that the two were compatible.

    I'll try going down the route of posting messages to the queue for outgoing calls. I also need to find a way of sending several standard telephony requests to the server, namely Hold, Hang-Up, Accept Call, Decline Call, Transfer, and possibly have to handle DTMF data as well... is this possible from MSMQ or am I going to have to look at other ways of achieving this?


    benw

    Thursday, July 5, 2007 4:16 PM
  • I think you're asking "can I somehow, from my WinForms workflow, get the MSS workflow app to Hold, Hang-up, etc", right? In theory, yes, you can. Basically you need some communication channel between the two apps (whether you use MSMQ, remoting, or whatever). You could, then, have the WinForms app trigger the MSS app, and then pass messages back and forth such that the WinForms app says "hang up now". That's all possible, but it's not something we've tried nor something we explicitly designed as a feature. I suspect you could make this work, but it will require a fair amount of work. You should also make sure that you are really doing things the right way; i.e., be sure that you really want to have the logic in the WinForms app rather than in the MSS app.

     

    Dan

    Thursday, July 5, 2007 8:20 PM
  • That's pretty much what I'm trying to do. Our existing software is based on Swyx, and uses a wrapper over their Client Line Manager, to talk to their proprietary PBX server and handle the call states. Their call routing system is based on VB Script, and we use a .NET COM object that remotes to all our Winforms based clients to determine who gets the call: based on skill set, time of day and so forth. The client then gets presented with the call in the form of a  third party web-based Call Script. We handle various log details, SQL updates, and give the option of redialing logged numbers from a database, placing the existing call on hold, performing blind and supervised transfers to other agents and so forth.

    For future progress, I was looking to abstract the current Swyx dependency into a module that could be replaced by alternative systems. That way, a large call centre that might be running several different PBX/Routing systems would have the same operator based interface. I really like the idea of using the Speech Server Workflow to handle incoming calls. The fact that it's all .NET means that we can integrate much more closely with the call process, rather than rely on third party systems.

    However.. as I think we've established: although calls can be made, held, hung-up etc from Speech Server, I would need to write my own version of a Client Line Manager (or similar) to send events to something that would actually control the calls. I was interested in whether, instead of trying to send events to MSS, perhaps using Office Communications Server instead would be more viable, but couldn't get OCS to work with MSS at the same time (unless I'm missing a critical point here).

    Any further thoughts? I'm guessing the only way to do most of this is by actually sitting down and doing it: however if I can gather a few opinions on best practices along the way, then the more the better.



    benw
    Friday, July 6, 2007 1:42 PM
  • Hi Ben,

    Can you let us know the status of your issue? Have  you worked with Dan anymore? If you have found a resolution, would you mind sharing it with the forums?

     

    Friday, July 27, 2007 5:11 PM
  •  

    Hi Thom,

     

    The issue has been put on the back burner for the time being. Since our call centre software development team consists of one person, and paying customers needed existing software changed, I haven't been able to continue persuing this. Last thing that I was working on was getting MS-OCS 2007 installed to try and use that to catch calls, before being pulled off to concentrate on more urgent matters. Hopefully I'll be able to continue trying to get this working over the next month.

     

    will let you know how I get on.

     

     

    benw 

    Wednesday, August 1, 2007 3:13 PM