Basic logic components in Restcomm Apps

Question

I don't see a way in Restcomm Apps using RVD to create basic data or basic logic trees. Is there a way to create components for:

• Creating and assigning variable values
• Basic logic components such as If Then Else, Equal / Not Equal, Contains, Comparisons for Text, Numbers, Dates,
• The ability to parse text using Regex
• The ability to insert variables into any value and have them parsed correctly
• String concatenation or similar

Components such as these would allow an app developer to have many more self-contained apps instead of having to stand up infrastructure to manage all of the app logic.

Does the current component API support the development of new components?

Answer 1

@scottbarstow

At the moment Restcomm RVD doesn't provide most of the features you mentioned out of the box. However, it is possible to achieve your goal using Restcomm RVD External Services. The variables, logic, regex parsing, etc will be handled using an external programming language of your choice.

Another option will be to use the Restcomm-ruby helper to build your application. The basic app will be to built using Restcomm Visual Designer and then you can make a call to the app using the Restcomm-ruby helper. All the (If Then Else, Equal / Not Equal etc.) will be handle by the Restcomm-ruby helper.

You could always send an RFE to Telestax.

Answer 2

RVD has resulted out of a struggle between offering as much flexibility to the user and spending as little development effort as possible while following an iterative approach. It evolved with small steps in order to have a functional progressing application always. In order to honor these requirements, a very crucial design decision was made: to keep the core part (the controller) a dummy engine that simply produces RCML and delegate all logic somewhere else, easily accessible over HTTP.

That being said, @scottbarstow, i welcome your comments. Having self contained apps greatly simplifies the setup and maintenance of an application, especially now that RAS is emerging. ES should be a tool to talk to really external targets not a way to delegate all sorts of complex operations outside RVD.

However, "logic" comes at a high cost. Introducing several elements for branching, comparisons, string manipulation etc. needs a lot of thinking to be designed, hours to be implemented and headaches to be debugged.

The alternative approach i suggest is the following:

1. Improve the way ES talks to external endpoints. Add full support for submitting POST/JSON payload. Have a choice of choosing between application/json and url-encoded forms content types. Handle everything else that is typically required by common service providers like Slack. All processing will be done in the ES. Further feedback here would be appreciated.

2. Keep all logic in a single place instead of spreading it across several new elements. Introduce the "Script" element where some sort of scripting engine will be used to execute a block of code implementing all required logic. Let this element talk to the outside world through a simple string-based contract with "INs" and "OUTs". There is already an experimental implementation on that using Groovy and the same could be done with server side Javascript.

But, wait a minute. RVD is supposed to be a simple tool for common users, not developers! Well, indeed. But consider the alternative. Will it be easier to understand and use a number of new smart elements and all the added syntax implications that will come with it? I guess not unless its very basic. Let alone debugging and support.

Javascript has a well known syntax and it is much easier to debug. It even runs inside the browser which opens the window for client side testing.

3. Introduce a very basic branching/GOTO element. It will be able to break module execution and redirect to another module. The logic of branching however will be implemented in a previous Script element.

Technical shortcomings and "why logic should be kept in a single black-box place"

RVD has state. There are variables it creates (Collect, ES elements create such) in addition to these fed by Restcomm that need to be preserved. Since the application flow progresses as a series of restcomm originating action requests that are stateless by nature there are two options.

(a) Recycle these variable in the action URLs or

(b) Store them in an session-like structure in RVD and keep a session-id that gets transferred instead.

RVD uses (a).

That means whenever control is passed back to restcomm (like when a Gather/Collect element is executed) all this state needs to be encoded in the action URL contained in the response. That way when restcomm makes the next request RVD will have the state. Its more or less the same pattern with old-school web dev with no HTTP session.

This state needs to be small in order not to have a lot of data going back and forth between RVD and Restcomm.

An RVD application consists of modules that contain elements that are processed sequentially and any element can potentially break the app execution in RVD and return control back to restcomm. It makes sense to make elements independent so that there is an option to break the application execution and return control back to Restcomm.

My point is that we need to keep elements independent, the interface between an element and the RVD execution context simple and the state easily serializable. And a block-box like Script element seems to fit this goal.

Answer 3

Enabling scripting into RVD is relatively straightforward. However it is not clear what is a good way to deal with application code bugs. Inexperienced developers can shoot themselves in the foot pretty quick with dynamic, loosely typed scripting languages.

The original intention of RVD was to make simple real time communication apps really easy and fool proof to create. Its still an open question whether the scope of RVD should expand to make more complex things possible or defer those to external services.

Can we look closer at the app you are trying to implement? If the intention is to take an SMS or a voice call recording and send it to a third party service such as Slack, that could be achieved through a service like Zapier. See the attached screenshots that illustrate connection from a WordPress plug-in (Gravity Forms) to Slack.

Would a similar Zapier module for Restcomm (in place of Gravity Forms) help?