What does Rivr buy me? Part 2

The previous post explored some benefits regarding the use of Rivr, the Java VoiceXML API. Let’s continue to look at more of these advantages.

More compact representation of dialogue

With proper method extraction, your dialogue can look compact and simple. You can get the overview of the whole dialogue such as:

public VoiceXmlLastTurn run(VoiceXmlFirstTurn firstTurn,
                            VoiceXmlDialogueContext context) {

    Credentials credentials = askUserCredentials(context);
    if (!authenticateUser(credentials)) {
        return new Exit("exit-unauthorized");

    Operation operation = askTypeOfOperation(context);
    transferToAgent(context, operation);

    return new Exit("exit-success");

You can drill-down in any method to get more details. Any IDE will let you do this easily:

Credentials askUserCredentials(DialogueContext context) {
    String accountNumber = askAccountNumber(context);
    String pin = askPin(context);
    return new Credentials(accountNumber, pin);

This gives you a feel of how you could organize you code and your dialogue.

Supports revision control system, parallel development

Since Java source files can be put in source control, as well as other dialogue-related resources such as grammars and prompts, everything can be put into a revision control system such as Git, Mercurial or Subversion. Developers can thus work in parallel and because they understand the syntax of the artifacts they manipulate, they can resolve a merge conflict, something not feasible in the diagram world.

Better integration with business logic

Graphical tools offer various pre-packaged back-end interface facilities (Database requests, SOAP request, XML HTTP request, etc). The problem is that they are limited and not flexible enough. For instance, authentication mechanisms can be lacking, you may be forced to specify a WSDL location which may not exist in your development environment or you may not be able to stub your back-end. Moreover, you may already have your back-end client library available in Java making the provided back-end access node totally irrelevant, just adding more noise to the project.

With Rivr, it’s easy to create a back-end abstraction and have regular and stub implementations. This is how things are typically done in Java and this makes the integration seamless. Everything is still done in Java. No need to add anything else.

Support for automated test suites

Automated dialogue testing is one of the most interesting feature of Rivr. While in normal mode the dialogue is driven by a servlet, where InputTurn are created based on the VoiceXML platform responses, testing can be done by providing some test cases acting as provider of InputTurn, thus simulating inputs of the caller and the VoiceXML platform. The Rivr Cookbook shows an example where JUnit is used to perform a complete coverage test of the callflow. This is a very powerful tool helping increasing application quality and making the application more resilient.

Better debugging facilities

With Rivr, you debug the application as a whole. You simply place breakpoints in the Java code. You can thus trace problems at different levels: interaction details, callflow logic, back-end logic. Debugging dialogues with unit tests is another typical way to find the cause of a problem.

Rivr also dumps every interaction details (OutputTurns and InputTurns) into a Java-side logger. So you no longer need to look at logs on different servers to figure out what’s happening.

Java developer friendly

Rivr allows Java developers to be more efficient. They don’t spend their time trying to layout diagrams (auto-layout doesn’t work, right?) or trying to circumvent a limitation in the GUI. They simply code the callflow. Rivr is a more natural way to implement callflows for a Java developer than any other approach.

The fact that Rivr is a Java library makes it easier for new developers to join IVR development projects. No need to learn a complex tool, the API is something that can be picked up rapidly.

Lower risks in development projects and maintenance

Rivr is just a library, it isn’t a design-time tool. You are less likely to break your currently working application by integrating a new version of Rivr than by upgrading your new IVR graphical tool to the latest version. Besides, you can always compile and run your applications against older versions of Rivr if it works correctly. By comparison, upgrading a graphical tool is a “can’t-go-back” decision.

Rivr helps reduce the project’s risks by starting development immediately. No need to wait for the VoiceXML platform to be ready of the tools to be deployed on developer workstations.

Rivr isn’t in your way

Rivr is designed for a focused task: development and execution of VoiceXML dialogues. There is no decision made for you as how you should connect to your enterprise back-end, how alarms are triggered, how applications should be packaged or how it should be deployed across your different environments.

Rivr doesn’t impose any convention of any kind. You are free to organize your project structure as you see fit.


Rivr is an elegant and powerful solution for VoiceXML IVR development, bringing benefits to the developers as well as the organization. To find out more about Rivr, you can take a look at the Java API documentation or read the Getting Started article. Rivr also has a discussion group which is open for everybody, feel free to join and ask questions.

Share this:

About the author

Dominique Boucher
I am the CTO of Nu Echo, where I am in charge of leading the technology directions and help turn customer requirements into truly effective products and solutions.

Leave a Reply