DynFlow

Finally got a chance to upload this user guide of DynFlow I wrote several weeks ago. What is DynFlow? Here's an excerpt from the guide:

DynFlow is an Orchestration Designer reusable module that simplifies greatly development of IVR for Avaya Experience Portal platform.

It is implemented as a state machine that encapsulates various points of interaction in an IVR flow. Currently, DynFlow supports the following points:

  • Announcement
  • Input collection
  • Menu
  • Blind transfer
  • CTI transfer
  • Custom-logic execution

Those points are the most-commonly used in any IVR. What makes DynFlow attractive is for typical cases you can almost forget developing IVR in Orchestration Designer; it's all reduced to specifying the points in your IVR as rows in a CSV file (you can achieve almost everything by working with a spreadsheet).

You can think of DynFlow as a motor that brings that spreadsheet to motion, transitioning from one point to the next.

Without further ado, here's the doc (can also be downloaded from https://www.box.com/s/fqh7kii7nr1fbxuu3ycn ).

The binary (the JARs and the WAR of DynFlow to be deployed to Tomcat) can be downloaded from https://www.box.com/s/tv6d49e15wtxj11ulsce . The DynFlow.war also needs to be imported as Reusable Mode in the Orchestration Designer if you want to develop IVR using it. Sample IVR is also provided in the ZIP.

Write Up Dynflow by Raka Angga Jananuraga

Progress on VoiceXML autotest using Bladeware

This is a continuation of this entry: http://jananuraga.blogspot.mx/2013/04/voicexml-autotest-switching-to.html

So, today I managed to get BladewareVxml running, tested with two samples vxml provided by BladewareVxml: helloworld.vxml and inline_grammar.vxml. The whole set of projects (bladeware, pcre, curl, xerces, spidermonkey) is also updated, and uploaded to Box.net, here: https://www.box.com/s/l9yniyq9pcbgb4nhro90

If you want to get them compiled and work with them on your PC, you will need Microsoft Visual Studio 2010. Just unpack the the file in C:\ (using 7-zip), and set the following environment variables:
  • BW_CURLDIR = C:\BladewareProject\curl-7.18.0
  • BW_JSDIR = C:\BladewareProject\bwjs-1.61.3
  • BW_PCREDIR = C:\BladewareProject\pcre-7.1
  • BW_VXMLDIR = C:\BladewareProject\bladeware-vxml
  • BW_XERCESDIR = C:\BladewareProject\xerces-c-src_2_8_0
Just open C:\BladewareProject\bladeware-vxml\vxml\BladewareVXML.sln on your Visual Studio 2010, and we will be on the same page. Just press Ctrl-F5 to start debugging.

Now, the samples vxml are available under C:\BladewareProject\bladeware-vxml\vxml\samples\ . Just copy them to your favorite webserver . In my case I copied them to my Jetty webserver under C:\jetty-distribution-9.0.2.v20130417\webapps\ROOT\samples , so those vxmls are accessible through the web under http://localhost:8080/samples/

The launcher of this Bladeware Vxml is available in the project named "client" (already set as the default StartUp project), a cpp file named runvxml.cpp. It takes various arguments for the execution, which you can set by: right-clicking on the project named ("client") >  Properties > Configuration Properties > Debugging > field named Command Arguments. Currently its value is: -config C:\BladewareProject\bladeware-vxml\vxml\etc\bvxml\runvxml_test.cfg -url  http://localhost:8080/samples/inline_grammar.vxml -channels 1 -calls 1

Now, from the execution of those 2 samples, what did we obtain? Hints to where we could possibly put our hooks. Have a look at these two screenshots. The next task would be to hunt down where those lines (marked with yellow box) are printed from. Those lines correspond to the events we're interested in.

I will be able to continue working on this next weekend. So, if you want to beat me to it before then, please do (and please share your findings). In the meantime I will be working on to get Pentaho BI stack running on my PC, part of my foray to big data analytics efforts :). Cya!




Warming up..., for my foray into big data analytics

Part of preparations for my foray into big data analytics is... mapping out the field. There are so many things to learn, so I have to get organized. I also need to bind together nicely in one single place things I've read so far (for further reference / simply to offload it from my head). This is just a note of my current understanding, which will evolve (corrected / refined) along the way. Without further ado, here it is:

---
A few additional words (added 1 May 2013)
---

As the name suggests: study-note. Has inaccuracies, incompleteness, some reasonings are not as strong as I would like them to be, etc. But I don't want to fall into analysis paralysis, so here it is my write-up, result of lots of googlings :), distilled....

My exercise laundry list:

(1) In datawarehousing, there's Pentaho. My reference is Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL ( http://amzn.to/104lh8k )

(2) In the area of NoSQL: my reference is "Seven Databases in Seven Weeks" ( http://amzn.to/10XxTWe ). Already finished reading the book. Now on to doing the exercises in the book. Will be focusing on PostgreSQL (as reference point, from the familiar SQL standpoint), and MongoDB (the most popular NoSQL db).

(3) In machine learning: my reference is "Data Mining: Practical Machine Learning Tools and Techniques" ( http://amzn.to/13OjqbM ). I'm using Weka and Knime. I have to be very pragmatic, lots of mathematical rigor in the book. In the short term, I only need to get myself familiared with the underlying idea behind those algorithms, and take advantage of already-implemented programming libraries (such as weka and mahout, to name a few). This, like techniques that is more close to art, is not something I can acquire in short time, because it depends on intuition, that requires time and lots of drills to develop.

(4) Data cleansing: key skill in data analysis. Thanks Google for giving Google Refine for free  ( https://code.google.com/p/google-refine/ ). My reference: "Bad Data Handbook: Cleaning Up The Data So You Can Get Back To Work" ( http://amzn.to/10Xz1ZI ).

Now... I need to switch back this weekend to finishing my VoiceXML autotest, before taking on that laundry list :D . Cya!

---

Note: the PDF can be downloaded from https://www.box.com/s/6lbafigfkbrta5cnll5u

VoiceXML Autotest: Switching to Bladeware VXML

UPDATE: Progress as of 5 May 2012 is available at: http://jananuraga.blogspot.mx/2013/05/progress-on-voicexml-autotest-using.html

---
Yep, I decided to switch to BladewareVxml to use as the basis for the VoiceXML Autotest I'm working on. Pragmatic reasons:

  • BladewareVxml is VoiceXML 2.1 compliant.
  • It's based on OpenVXI, which to my knowledge is used by many commercial products out there. So..., hopefully people would be more likely to use this tool.

What have I done so far? Very basic: get BladewareVxml compiled :) No brainer, I only had to fix a few build configurations, and one header file, VxiCommon.h, adding #include <iterator>. Download it from here: https://www.box.com/s/l9yniyq9pcbgb4nhro90

Next: I'm going to write a C++ interface and process with SWIG, first step toward integration with Python. The idea: software testers will write their test-script in Python, and that C++ interface will act as a bridge between that test script and the BladewareVXML interpreter object.

The C++ class that implements the interface will:
  • Accept (through its constructors) callback-function pointers written in python, such as:
    • readInput
    • renderPrompts
    • inputRecognized
    • inputNomatch
    • inputNoinput
    • transferPerformed
    • submit
  • Accept (through its constructors) VoiceXML platform properties.
  • Have methods that can be called from test script. These methods will interact with Bladeware VoiceXML interpreter object created during the construction:
    • runVxml
    • feedInputSpoken
    • feedInputDTMF
    • feedNoInput
    • hangup
  • Be implemented as singleton, allowing me to obtain a reference to it from any point in the Bladeware's Vxml code.
Before I get to that, I will have to study Bladeware Vxml code in debug mode. Now... where is the starting point(s)? :D Maybe I can start from these ones.... Ok, that's all for now, until next weekend.





GuiceXML & VoiceXML Autotest, (r.e).u.n.i.t.e.d. !

STOP PRESS :)  20 April 2013: I decided to use Bladeware Vxml instead of JVoiceXML as the engine for this tool. Click here to find out more about it.

***********************

Ok, quickie :)

GuiceXML: I already explained it in previous blog entry. This weekend I had a chance to make some improvement in the code, and it's available here for download: https://www.box.com/s/3bph4o8096489spnhip2 . Don't forget to download the sample VoiceXML files (just deploy them to your webserver), here: https://www.box.com/s/v0tmupsij9ogscullh1k .

I also had a chance to take a screencast of GuiceXML, so you can have a better idea of what it is. Here's the vid:



VoiceXML Autotest: it was explained in this old blog entry (actually it precedes GuiceXML). With that library you can check the VoiceXML flow against your expectations (scenario) expressed the following way:


The good things is: both things now share the same code base. :) 

Well, that's all for tonight. I'm sorry I don't have a chance tonight to write a bit about the code and where it's heading. I hope tommorrow night I'll be able to do it. Cya!

GuiceXML

UPDATE: GuiceXML and VoiceXML Autotest (re)united. This way. New code, screencast to give you a (more) concrete idea of what GuiceXML is about, and a screnshot of a code to express your voicexml automated-test scenario.

----- Original Entry -----

After a long hiatus, time to resurrect old projects. One of them is someting I name... GuiceXML. It's a word play of GUI + VoiceXML.... This is a cool (and useful) thing. Several companies are doing it, check out this one: http://fonolo.com/blog/2012/11/what-does-the-future-hold-for-visual-ivr/

VoiceXML is a language for describing flows of dialogs. Originally it's meant for interactive VOICE response (IVR). But..., it's quite easy to conceive these same flows of dialogs can be presented VISUALLY in a smartphone. We have proliferation of VoiceXML-based IVR; It's been around since 2000, nowadays majority of IVR are written in VoiceXML, so it's pretty standard, just as HTML is to websites. Also, smartphone is commonplace. Connect the dots, you can quickly see the opportunity for this kind of thing (an adaptor, VoiceXML app -> mobile app).

Of course in practice that wouldn't be as straightforward as it sounds. To begin with, inherently there's a difference between visual and audible user interaction. What are those fundamental differences? Well, I still have to read some more about it :), so can't write much now on that matter. This link in the meantime can provide some hints: http://www.informit.com/articles/article.aspx?p=26669 . So..., a good adaptor must provide a good API & tool to overcome this first challenge. I guess a significant amount of tinkering and work would be on tackling this challenge (note to product manager :)).

Maybe this technical description can illustrate some points. In GUI users are accustomed to seeing all the fields, that belong to the same form, on the same screen. Additionaly, in most cases users have freedom in deciding the sequence in which they fill-in the input fields. But that's normally not the case with VUI where users are kind of "forced" to give input one-by-one, in a predefined (and unflexible) sequence, eventhough there isn't dependency between each input. This is not a limitation of VoiceXML per se, but more of UI design (most VoiceXML applications are coded in that simplistic way). VoiceXML actually provides a way to implement mixed initiative dialog. Check out this link: http://www.vxml.org/t_20.htm

Alright, you might ask: why not simply apply some XSL transformations on the VoiceXML documents to produce HTML then?

Well, not that simple, and one of the reason is... something I would call the dynamism embedded in the VoiceXML spec itself, and without even requiring JavaScript (which is another thing that can be used inside a VoiceXML document). For example: an input field (), can have a "cond" attribute that specifies a Boolean expression, which must equate to 'true' in order for the content to be visited and executed. Furthermore, this expression can involve a value of another field(s). Meaning: in that case, there _is_ a dependency between fields. Contrast this to HTML where you would have to use some JavaScripts to provide similar behavior.

A good adaptor must know how to figure out whether or not there are dependencies between fields in a form, and adjust the way it asks for the inputs accordingly. We can think of parsing the fields in a form to see if any of them have "cond" attribute for example; if not, then it might be safe to presents all the fields in the form on a single screen. Now, it's easy to imagine that the task of adapting can be even more challenging if JavaScript codes exist in the VoiceXML document.

The crux of the matter: a simple, static transformation (such as the one with XSL) wouldn't work. The adaptor _must_ execute the VoiceXML (and the embedded JavaScript, if any). We don't want to require programmers to tweak existing VoiceXML code just in order to make it presentable as GUI. We want to provide 100% assurance that existing VoiceXML will processed the same way as it is on existing VoiceXML browser, that no logic inside existing VoiceXML code that might impact business operation will be ignored / droppped. In short, a VoiceXML-compliant adaptor.

For that reason, I decided to pick up JVoiceXML, an open-source VoiceXML interpreter, as the base for this adaptor. What needs to be done is extending it through various mechanism (Subscriber/Listener, injection of alternative Strategy, wrapper + delegation, etc). In some situations I even had to make modification directly in the JVoiceXML code, and I tried not to break its VoiceXML-compliance. It takes a lot of reverse engineering / debugging tricks to understand how it works and know where & how to make the modifications / extensions (link to list of modifications in JVoiceXML code). GuiceXML alpha 0.1 is based on JVoiceXML ver 0.7.5.

Here's the result so far (link to the code). You will need NetBeans to open the project (I'm using the latest version, 7.3). To run the project, create a Run configuration like this one:



The GuiceXML code belongs to a package named net.raka.jvxmltd.

This sequence of screens will give you a picture of what to expect from this alpha version. It still does thing in the most naive way, like I mentioned above, asking input one field at a time. This example requires you to deploy two VoiceXML documents (sample_01.vxml and sample_02.vxml) to your webserver. You just have to change the URL of the landing VoiceXML page (sample_01.vxml) to point to your webserver.



Also, of course this is a very rough version of GuiceXML, where I basically put hooks here and there, in order to be able to intercept and react on a few events that I'm interested in, such as announcement and input collection. In fact in one place I have to do a dirty trick of using execution stack trace, just in order to figure out whether a prompt should be played as part of input collection (i.e.: inside a ), or as an informational message (i.e.: inside a ). If it's part of input collection, that GuiceXML prints it in the text area inside the frame. Otherwise, it displays a blocking message dialog.



Actually, that dirty trick along with modifications I did directly in the JVoiceXML code, leads me to thinking that JVoiceXML code itself needs some refactoring. Ideally, to implement an adaptor / extension like GuiceXML, one shouldn't need to modify the core library (JVoiceXML). The hooks provided the library should be sufficient. However that's not the case with JVoiceXML 0.7.5.

Also, refactoring is needed in JVoiceXML to abstract away several classes on which the current GuiceXML is based / depends on. For example, JVoiceXML's TextTelephony (used by GuiceXML's TextDriverTelephony) communicates with its peer classes using socket. Well, that's not desired in GuiceXML because the idea is to have GuiceXML running in mobile environment (e.g.: J2ME / Android phone), and minimize the use of network resource (only HTTP will be needed to fetch the VoiceXML documents from the app server that hosts the IVR application). TextTelephony I think should be coded in such that way the I/O channel it uses can be injected, and the I/O channel itself is described as a java interface, where network socket is only one of the possible implementations. Click here to understand the role of Telephony in JVoiceXML.

Additional note: this visual IVR idea can be mixed with callback. Many times I get frustrated dealing with contact center on the phone (voice), for two reasons: (1) that tedious IVR and (2) long wait time to speak to an agent (when call gets transferred at the end of IVR interaction). With visual IVR, interaction can be sped up (and companies can reuse their existing IVR-app investment) and caller doesn's have to wait to be attended by the agent. The contact center agent is the one who is supposed to make the call back.

Here's a picture of a callback app concept I sketched a while back, and mentioned in this blog: http://www.nojitter.com/post/240001084/camping-with-avaya?pgno=2
.
 

Alright, that's all for now. Drop me a line if you're interested in the project. ( raka.angga _at_ gmail.com ). Cya!