使用类似搭积木的低代码开发方式进行 SAP API 开发

Jerry 之前的文章SAP API开发方法大全介绍的第七种 SAP API 开发方式，SAP Data Intelligence Graph，实际上是 Low Code Development(低代码开发)的一种体现。

本文通过一个具体的例子来介绍，如何在 SAP Data Intelligence Modeler 的图形化界面里，通过类似小朋友玩积木的方式，将各种 SAP 发布的标准 Operator 搭配在一起，再通过少量的编码，得到一个支持增删改查的 API.

打开 Modeler 的 Operators 标签页，看到位于不同 Categories 下面总共存在超过 300 个 Operator.

每个 Operator 可以实现某领域的一个功能，比如连接 ABAP 系统并读取数据，生成随机数据，将数据写入某持久化存储，调用 API 等等。我们通过把这些 Operators 组合起来, 最后实现一个端到端的场景。

在动手使用这些 Operator 组建 API 之前，让我们先试试一些最简单的 Operator. 拖拽一个拥有《星际争霸》里人族雷达站图标的 Data Generator 到编辑页面里。

这个 Operator 定义了一个 Output Port, 类型为 String，意思是它生成的随机数，以 String 的类型，通过该 Output Port 传递给其他 Operator.

上图 Data Generator 的 Output Port 指向了另一个 Terminal Operator 的 Input Port, 这代表了数据流的传递方向，从 Data Generator 输出到 Terminal.

这些作为节点的 Operators 以及连接节点的有向线段组合在一起，构成了 SAP Data Intelligence 里的 Graph(图).

SAP Data Intelligence 官网上提到了其“拥抱开放技术”的一个特质：

比如 SAP Data Intelligence 提供的 Kafka Consumer 和 Producer Operator，给其维护一个 Kafka Broker 的地址，就能无需编程，轻松实现生产者-消费者场景：

现在回到本文开头提到的增删改查 API 的需求。这个 API 可以让消费者通过 HTTP 的方式调用，通过 API 进行增删改查的操作对象仅仅维护在 Graph 运行时的内存里，实际就是 JavaScript 简单实现的对象键值对，为简单起见，省略了持久化操作。

这个由 Graph 实现的 API 最后如下图所示，总共由 6 个 Operator 组成，其中一个 HTTP Server，四个 JavaScript Operator 和一个 Multiplexer.

根据帮助文档，HTTP Server 这个 Operator 封装了最简单的 HTTP 服务器的功能，能够在用户配置的 endpoints 上接收 HTTP 请求。

如何配置 Operator？右键菜单里选择“Open Configuration”, 点击 Routes 的编辑图标：

根据 SAP 帮助文档，HTTP Server Operator 只负责接收 HTTP 请求，并不负责收到这些请求后的业务处理，而是通过 Output Port 交由 Graph 下游的其他 Operator 完成。Route 配置信息一目了然，在路径/objects 上接收到带参数 id 的 HTTP 请求后，按照 HTTP 请求类型，分别将请求通过 get, post 和 delete 三个 Output Port 转发给其他 Operators.

接下来我们实现 HTTP GET 操作的响应逻辑。从 Operators 标签页里拖拽一个 JavaScript Operator 到编辑页面里，重命名为 GET Handler，创建一个名叫 request 的 Input Port，将其连接到 HTTP Server 的 get Output Port.

右键单击 GET Handler，选择 Open Script 菜单项：

由于预见到 HTTP Server 接收到 GET，POST 和 DELET 请求后，都有一些通用的逻辑要处理，比如从 URL 里解析出消费者传入的对象 ID 参数值，并交由下游 Operator 进一步处理。因此这里的设计是这三个 Handler 在收到请求后，仅仅构造一个命令对象，该对象包含这次 HTTP 请求所对应的内存中 JavaScript 对象键值对的操作类型(GET 请求对应 select，POST 请求对应 insert，DELETE 请求对应 delete)和传入的参数 ID 值：

从上图看出这三个 Handler 的实现代码，除了通过 command Output port 传给下游节点的操作类型(objectStore.command)存在差异之外，并无其他区别。

任意一个 HTTP 请求被 HTTP Server 接收后，只会触发这三个 Handler 其中一个。三种 Handler 产生三种可能的输出操作，通过名为 command 的 Output Port 传递给上图中图标为三叉戟的三路复用器。这个复用器确保最后一个 JavaScript Handler 能够同时处理这三种可能性，执行完对应的键值对操作后，将处理结果经过上图橙色虚线标注的数据流，传递给 HTTP Server 的 Input Port.

在名为 Object Store 的 JavaScript Handler 内部，用变量 objects 定义一个空的 JavaScript 对象，作为键值对的存储实体。针对 select，insert 和 delete 三种操作，分别这个对象来实现增删改查。

这样该 Graph 从接收到 HTTP 请求，到处理完请求将结果写入 HTTP Server 名为 Response 的 Input Port，形成了一个完整的闭环。

Graph 开发完毕后，点击运行按钮，待其处于运行状态后，就可以使用 Postman 等工具或编程语言消费了。在控制台将其 Runtime Handle 抄下来：

首先测试 API 读取功能，试图读取一个 ID 为 1 的实例：

https://<host>/app/pipeline-modeler/service/v1/graphs/<runtime handler>/operator/httpserver1/objects/1

看到返回的提示信息“no obect with ID”就是我们在 Object Store JavaScript Handler 里硬编码的错误处理。

接着调用 HTTP Post 插入一条 key 为 1 的 JavaScript 对象：

然后用 HTTP GET 读取，这次读取成功：

使用 HTTP DELETE 请求删除这个 ID 为 1 的对象：

希望本文能帮助大家对 SAP Data Intelligence 里这种低代码开发方式有一个最直观的了解，感谢阅读。