Voip Restcomm应用程序中的基本逻辑组件

Voip Restcomm应用程序中的基本逻辑组件,voip,mobicents,restcomm,Voip,Mobicents,Restcomm,我在Restcomm应用程序中看不到使用RVD创建基本数据或基本逻辑树的方法。有没有一种方法可以为以下对象创建组件: 创建和分配变量值 基本逻辑组件,如If-Then-Else、Equal/Not-Equal、包含、文本比较、数字、日期、 使用正则表达式解析文本的能力 将变量插入任何值并正确解析它们的能力 字符串串联或类似 这样的组件将允许应用程序开发人员拥有更多的自包含应用程序,而不必建立基础设施来管理所有应用程序逻辑 当前的组件API支持新组件的开发吗?@scottbarstow 目前,

我在Restcomm应用程序中看不到使用RVD创建基本数据或基本逻辑树的方法。有没有一种方法可以为以下对象创建组件:

  • 创建和分配变量值
  • 基本逻辑组件,如If-Then-Else、Equal/Not-Equal、包含、文本比较、数字、日期、
  • 使用正则表达式解析文本的能力
  • 将变量插入任何值并正确解析它们的能力
  • 字符串串联或类似
这样的组件将允许应用程序开发人员拥有更多的自包含应用程序,而不必建立基础设施来管理所有应用程序逻辑

当前的组件API支持新组件的开发吗?

@scottbarstow

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

另一个选项是使用来构建应用程序。基本应用程序将使用Restcomm Visual Designer构建,然后您可以使用Restcomm ruby helper调用该应用程序。所有的(如果是Else,则为Equal/notequal等)都将由restcomruby助手处理


您可以随时向Telestax发送RFE。

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

RVD的初衷是让简单的实时通信应用程序真正易于创建,而且不会出错。差饷物业估价署的范围是否应扩大,使更复杂的事情成为可能,还是将这些事情推迟到外部服务,这仍然是一个悬而未决的问题

我们可以仔细看看你正在尝试实现的应用程序吗?如果目的是录制短信或语音通话并将其发送给第三方服务(如Slack),则可以通过Zapier等服务实现。请参阅随附的屏幕截图,其中说明了WordPress插件(重力表单)与Slack的连接

类似的用于Restcomm的Zapier模块(代替重力表单)会有帮助吗


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

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

然而,“逻辑”的代价很高。为分支、比较、字符串操作等引入几个元素需要大量的设计思想、几个小时的实现时间和令人头痛的调试工作

我建议的替代方法如下:

  • 改进ES与外部端点对话的方式。添加对 提交POST/JSON负载。在两者之间进行选择 应用程序/json和url编码的表单内容类型。手柄 公共服务提供商通常需要的所有其他内容 像松懈。所有处理将在ES中完成。进一步反馈 在此将不胜感激

  • 将所有逻辑放在一个地方,而不是将其分散 一些新的元素。引入“Script”元素,其中 脚本引擎将用于执行一段代码 实现所有必需的逻辑。让这个元素与外界对话 通过一个简单的基于字符串的带有“in”和“out”的契约来创建世界。 使用Groovy已经有了一个实验性的实现 服务器端Javascript也可以做到这一点

  • 但是,等一下。RVD应该是普通用户而不是开发人员的简单工具! 嗯,的确如此。但是考虑另一种选择。是否会更容易理解和使用一些新的智能元素以及随之而来的所有附加语法含义?我想不会,除非它非常基本。更不用说调试和支持了

    Javascript有一个众所周知的语法,调试起来更容易。它甚至运行在浏览器内部,打开窗口进行客户端测试

  • 介绍一个非常基本的分支/转到元素。它将能够中断模块执行并重定向到另一个模块。逻辑 但是,分支将在以前的脚本元素中实现
  • 技术缺陷和“为什么逻辑应该保存在一个黑匣子中”

    差饷物业估价署有。除了restcom提供的需要保留的变量之外,它还创建了一些变量(Collect、ES元素创建这些变量)。由于应用程序流是作为一系列restcomm原始操作请求进行的,这些请求本质上是无状态的,因此有两种选择

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

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

    差饷物业估价署使用(a)

    这意味着无论何时将控件传递回restcom(如执行聚集/收集元素时),所有这些状态都需要在响应中包含的操作URL中进行编码。这样,当restcomm发出下一个请求时,RVD将具有该状态。它的式样和旧的差不多