Restcomm Apps 中的基本逻辑组件答案

【问题标题】：Basic logic components in Restcomm AppsRestcomm Apps 中的基本逻辑组件
【发布时间】：2015-03-26 18:01:07
【问题描述】：

我看不到在 Restcomm Apps 中使用 RVD 创建基本数据或基本逻辑树的方法。有没有办法为以下对象创建组件：

创建和分配变量值
基本逻辑组件，例如 If Then Else、等于/不等于、包含、文本比较、数字、日期，
使用正则表达式解析文本的能力
能够将变量插入任何值并正确解析它们
字符串连接或类似的

诸如此类的组件将允许应用开发者拥有更多独立的应用，而不必建立基础设施来管理所有应用逻辑。

当前的组件 API 是否支持新组件的开发？

【问题讨论】：

标签： voip mobicents restcomm

【解决方案1】：

@scottbarstow

目前 Restcomm RVD 没有提供您提到的大部分开箱即用的功能。但是，使用 Restcomm RVD 外部服务可以实现您的目标。变量、逻辑、正则表达式解析等将使用您选择的外部编程语言进行处理。

另一种选择是使用Restcomm-ruby helper 来构建您的应用程序。基本应用程序将使用 Restcomm Visual Designer 构建，然后您可以使用 Restcomm-ruby 帮助程序调用该应用程序。所有（If Then Else、Equal / Not Equal 等）都将由 Restcomm-ruby 助手处理。

您可以随时向 Telestax 发送 RFE。

【讨论】：

除非我遗漏了什么，否则 Ruby 助手所做的只是为 API 提供一个包装器。它不会在 RVD/App 框架中引入新功能。我可以构建外部应用程序来完成所有这些，这不是问题。但是，在许多情况下，我还不如将所有交互都指向该应用程序，甚至不构建应用程序。我可以像往常一样为数字配置应用程序 url 并将它们全部转发。

【解决方案2】：

RVD 是在为用户提供尽可能多的灵活性和在遵循迭代方法的同时花费尽可能少的开发工作之间进行斗争的结果。它以小步骤发展，以便始终具有功能进步的应用程序。为了满足这些要求，我们做出了一个非常关键的设计决策：将核心部分（控制器）保留为一个虚拟引擎，该引擎仅生成 RCML 并将所有逻辑委托给其他地方，可通过 HTTP 轻松访问。

话虽如此，@scottbarstow，我欢迎你的 cmets。拥有自包含应用程序大大简化了应用程序的设置和维护，尤其是现在 RAS 正在兴起。 ES 应该是一种与真正外部目标对话的工具，而不是一种将各种复杂操作委托给 RVD 之外的方式。

但是，“逻辑”的成本很高。引入用于分支、比较、字符串操作等的几个元素需要大量的设计思考、实现时间和调试问题。

我建议的替代方法如下：

改进 ES 与外部端点对话的方式。添加完全支持提交 POST/JSON 有效负载。可以选择 application/json 和 url 编码的表单内容类型。处理公共服务提供商通常需要的其他一切像松弛。所有处理都将在 ES 中完成。进一步的反馈在这里将不胜感激。

将所有逻辑保存在一个地方，而不是将其分散到各处几个新元素。引入某种类型的“脚本”元素脚本引擎将用于执行代码块实现所有必需的逻辑。让这个元素与外界对话通过带有“INs”和“OUTs”的简单的基于字符串的合约。已经有一个使用 Groovy 的实验性实现服务器端 Javascript 也可以这样做。

但是，等一下。 RVD 应该是普通用户的简单工具，而不是开发人员！ 嗯，确实。但考虑替代方案。是否会更容易理解和使用一些新的智能元素以及随之而来的所有附加语法含义？我想除非它非常基本。更不用说调试和支持了。

Javascript 具有众所周知的语法，并且更容易调试。它甚至可以在打开客户端测试窗口的浏览器中运行。

引入一个非常基本的分支/GOTO 元素。它将能够中断模块执行并重定向到另一个模块。的逻辑然而，分支将在之前的 Script 元素中实现。

技术缺陷和“为什么逻辑应该保存在一个单一的黑盒位置”

RVD 有状态。除了需要保留的由 Restcomm 提供的变量之外，它还创建了一些变量（收集、ES 元素创建此类）。由于应用程序流程是作为一系列 restcomm 发起的操作请求进行的，这些请求本质上是无状态的，因此有两种选择。

(a) 在操作 URL 中回收这些变量或

(b) 将它们存储在 RVD 中的类似会话的结构中，并保留一个被传输的会话 ID。

RVD 使用 (a)。

这意味着无论何时将控制权传递回 restcomm（例如执行 Gather/Collect 元素时），所有这些状态都需要在响应中包含的操作 URL 中进行编码。这样，当 restcomm 发出下一个请求时，RVD 将具有该状态。它与没有 HTTP 会话的老式 Web 开发模式大致相同。

此状态需要小，以免有大量数据在 RVD 和 Restcomm 之间来回传输。

RVD 应用程序由包含按顺序处理的元素的模块组成，任何元素都可能破坏 RVD 中的应用程序执行并将控制权返回给 restcomm。使元素独立是有意义的，以便可以选择中断应用程序执行并将控制权返回给 Restcomm。

我的观点是，我们需要保持元素独立，元素和 RVD 执行上下文之间的接口简单，状态易于序列化。而像 Script 元素这样的方块盒似乎符合这个目标。

【讨论】：

我认为脚本会起作用。几年前我用一个产品做到了这一点，我们允许用户编写 Javascript 来处理任何和所有逻辑，然后我们在一个有围墙的 V8 VM 中执行脚本。这种方法存在许多问题，即： - 控制脚本中可以做什么和不可以做什么以及检查违规（换句话说，防止滥用） - 以有意义/明显的方式调试/暴露错误 - 暴露以有意义的方式将应用程序实体添加到 JS 运行时
Furthermore... - 像我们所做的那样，通过类似被监禁的 V8 VM 来隔离执行。如果您让某人编写 javascript，开发人员将尽其所能找到您方法中的漏洞。我认为，如果该工具应该对非开发人员用户来说很容易，那么拥有更多组件而不是脚本语言会更有意义。脚本解决方案显然要强大得多。
我没有使用嵌入在 Java 中的服务器端 javascript，但我希望它会被定义为监禁。相比之下，Groovy 是一种通用语言，它似乎几乎不可能确保安全。可能存在 CPU 和 RAM 资源问题，但很容易使系统崩溃。

【解决方案3】：

在 RVD 中启用脚本相对简单。然而，目前尚不清楚什么是处理应用程序代码错误的好方法。没有经验的开发人员可以使用动态的、松散类型的脚本语言很快地自责。

RVD 的初衷是让简单的实时通信应用程序变得非常容易创建，而且很简单。是否应该扩大 RVD 的范围以使更复杂的事情成为可能，或者将这些事情推迟到外部服务，这仍然是一个悬而未决的问题。

我们可以仔细看看您尝试实现的应用吗？如果打算将短信或语音通话录音发送到 Slack 等第三方服务，则可以通过 Zapier 等服务实现。请参阅随附的屏幕截图，这些屏幕截图说明了从 WordPress 插件（重力形式）到 Slack 的连接。

用于 Restcomm 的类似 Zapier 模块（代替 Gravity Forms）会有帮助吗？

【讨论】：

您当然可以轻松地分支到其他服务。但是，如果您将其视为应用程序的开发人员，则会引入大量复杂性。对于安装该应用程序的每个人，他们是否需要一个 Zapier 帐户或其他一些凭据才能使其正常工作？至少您必须以某种方式为每个下载您的应用程序的客户启用对所有其他接触点的访问。真正的问题是：RVD 是设计成只是从电话到其他一切的桥梁，还是设计成一个更丰富的应用程序平台。两者都可以，但它们是非常不同的消息。
确实如此。 RVD 的首要任务是让将任何电话网络连接到现代应用程序变得非常简单。现在这已基本完成，我们可以进一步探索应用托管层，以尽量减少开发人员必须为常见应用处理的移动部分。