这是我关于HCP、ABAP和websocket系列博客的第三部分。您可以在这里添加第一部分（包括部分列表）：HCP、ABAP和websocket第1部分。

在这一部分中，事情将开始变得更有趣：本周我们的目标是将UI5应用程序（从上周开始）的更改（删除的行）传播到一个经典的dynpro，反之亦然。本周的源代码是这样的：ebe3120

我开始做一个报告。我刚刚声明了一个类似DB table结构的行表，并创建了一个简单的过程（也可以是一个本地类方法），通过在DB上执行SELECT来填充表：我称之为load\u data.

之后，大数据中心是什么，我在这个报表中创建了一个屏幕；屏幕将只包含一个自定义控件（我将其命名为ALV）。还应创建新的GUI状态，返回/取消/退出按钮映射到一个简单的"退出"命令和另一个用于"删除选定行"操作的按钮（命令="删除"）。

在PBO模块中，我添加了一些简单的代码，用于初始化cl\u gui\u alv\u grid对象（将显示在自定义控件中）和调用load\u data过程。

在PAI中模块中，我编写了退出应用程序（如果发出"退出"命令）和从数据库中删除一行并重新加载数据（如果发出"删除"命令）的代码。

此时，可以测试报告：它应该显示表中的所有数据，并且当我们按下"删除"按钮时，应该删除选中的行。

所以，向上到目前为止，我们有一个UI5应用程序，它可以动态响应自己对数据所做的更改，还有一个ABAP报告，它根本不会动态响应。

首先让我们看看ABAP–>UI5场景：当我们在dynpro屏幕上删除一行时，它应该显示在UI5应用程序上。这没那么复杂。首先，我做了一个新的过程，在AMC上发送一个刷新消息。我还确保将报告添加到AMC中的授权程序列表中。

然后我在从DB表中删除行之后调用了此过程（在调用此过程之前，我还必须添加一个提交工作语句，以确保其他客户端不会读取表中删除的行）。

相反的情况有点技巧：我们需要触发PAI/PBO循环来实际显示刷新的数据，大数据技术学什么，并且我们还必须"找出"何时发生这样的更新。语句WAIT FOR MESSAGING CHANNELS可用于等待消息的到来。但是，如果我们直接在PAI/PBO模块中使用它，屏幕就会冻结，等待消息到来。我们希望报告具有响应性，高防云服务器，因此这是不可能的。

我找到的解决方案是将此指令封装在aRFC调用中。

因此，我们需要aRFC的功能模块。这将有一个简单的本地AMC消费者类，只需等待消息的到来。我还为FM等待消息传递通道的时间量设置了一个上限阈值。请注意，FM应该是远程启用的（以允许RFC呼叫）。

所以现在我们有了FM，我们可以在报告中使用它。我只是给这个调频台加了一个aRFC呼叫。我们再次需要一个表单，在aRFC返回结果时进行处理。为了触发PAI/PBO，我们必须使用set USER-COMMAND指令设置一个新的ok\u代码。我使用了两个不同的命令：一个用于FM返回时，因为收到了消息；另一个用于FM返回时，因为超过了最大时间限制。

在PAI中，我只检查了ok代码值，如果发出了"AFRC\u FUL"命令，大数据的内容，则重新加载表内容。

在这两种情况下（'ARFC\u FUL'和'ARFC\u TIM'），应进行新的aRFC呼叫。您可以在提交中看到完整的源代码来检查这个问题。

我们现在可以测试它了。当我们删除dynpro屏幕上的一行时，更改应自动传播到UI5接口，反之亦然。

下周，采购返利，我将在HCP（UI5 apps）上托管的应用程序和AS ABAP（UI5和dynpro）上托管的应用程序之间使用相同的机制。下周见