上个月，物联网培训，SAP发布了表单，作为SAP云平台工作流的一部分（请参阅SAP云平台工作流中的新功能-表单和星期一早晨的想法：工作流表单和开发人员的定义）。其背后的思想是在sapwebide中为SCP上的工作流配置ui，并根据零代码方法在运行时使用所谓的formsplayer生成SAPUI5组件。本博客的目的是使表单与SAP Process Orchestration上的BPM开发保持一致，并强调流程上下文对此处理的意义。

我们的长期经验明确表明，UI开发是BPM实施项目的一个重要成本驱动因素。在SAP PO上，我们主要应用了两种方法来减少此类工作：

使用加速BPM（请参阅aBPM–SAP Consulting提供的解决方案扩展）分别为UI开发构建自己的工具箱和框架

aBPM从定义数据模型和UI布局的Excel文件中生成Java代码（在设计时）和SAPUI5代码（在运行时）。此外，Java控制器中有许多钩子，用于为各种UI和BPM事件执行自定义Java代码。javaapi提供对整个UI和数据模型的访问，以便在需要时扩展生成的工件。定制工具箱试图达到同样的效果：声明式UI开发和相关人工制品的生成—但它们不是基于Excel文件，而是基于XML。

除了这两种方法之外，还有另一种方法利用了SAP PO的内置功能：可以从中生成SAPUI5组件过程上下文，淘客佣金，这正是我们在项目中没有使用它的原因。我们遵循最佳实践，以尽可能精简流程上下文，这对于版本控制和迁移非常重要-特别是在敏捷项目中，当发布具有UI自适应的新版本时，旧版本中的流程实例仍在运行（例如，UI应通过具有新版本的某些元素进行扩展）版本，但旧的流程实例在其流程上下文中没有这些元素）。

但是使用SCP工作流服务，范例发生了变化：现在我们有了用于数据处理的JSON，有哪些云服务器，而不是XML。对于BPM开发，我们不再需要基于WSDL定义XML模式和web服务定义。现在，在运行时根据需要调整流程上下文中使用的JSON文档是没有问题的。这种灵活性允许我们将工作流中处理的所有请求数据保持在流程上下文中，这是使用表单的前提条件。

将数据保持在流程上下文中也会影响我们开发监控工具的方式：在（几乎）每个BPM项目中，都需要实现某种流程驾驶舱或请求概述，提供所有正在运行和已完成的工作流请求的功能视图，包括搜索功能、基于现有工作流启动工作流的功能、取消正在运行的实例等。例如，aBPM由aBPM驾驶舱组成。此类驾驶舱是基于存储工作流请求所有数据的数据库实现的。到目前为止，这还不是流程上下文，因为我们只是在流程上下文中使用请求数据的ID来引用它。但从现在开始，云免费，我们的方法是通过调用工作流中的服务任务，大数据怎么查询，将流程上下文（现在等于请求数据）推送到文档存储中，并在此基础上实现一个流程驾驶舱。

然而，当我们测试表单时，它看起来真的很有希望–但是由于缺少功能，它目前只是一个非常简单的工作流和所有其他复杂的选项，我们必须像以前一样定制开发ui。但我们必须考虑到，这只是表单的第一个版本，新版本肯定会提供更多的功能。我真的很期待。