本系列的上一篇文章：发现SCP工作流-组件启动。

本篇文章是本系列的一部分，可在此处找到指南：发现SCP工作流。

我们在以前的文章中已经多次看到任务UI。在这篇文章中，我们将快速看看这是如何组合起来的。UI5应用程序本身并没有什么特别之处，除了我们在上一篇文章中介绍的组件启动。但值得一提的是，如果你能从另一个角度来创建应用程序以支持收件箱中的用户任务的话，

这个应用程序有一个标准的结构，这是我使用SAP Web IDE中的"基本SAPUI5应用程序项目"模板创建的。这是一个很有用的自动构建（缩小/预加载）的设置。

这是一组简单的工件，就像我们在上一篇文章的结尾看到的那样，这很可能是一个单一视图的UI所期望的：

其余的"chrome"（小写"C"）–用户任务项的主列表，带按钮的页脚栏，以及以此类推-来自我的收件箱主机应用程序。我们要做的就是提供足够的结构，以组件的形式呈现应用程序（现在谁不这么做？）它完成了大部分重要的工作，还有一个简单的视图和控制器。

这里是项目文件夹：

这里也有一些非核心工件–我打开了"显示隐藏文件"设置，还有（未展开的）dist文件夹，其中包含为部署而构建的文件。

让我们逐一查看关键工件，检查重要的部分。

在这个文件中没有什么特别的地方，除了我想对工作流运行时路由的重要引用，它位于SAPUI5资源路由旁边：

也就是说，这里有一点值得指出。

在发现SCP工作流时-实例启动，我建议改进路由名称"workflowservice"，其入口路径为"/workflow service/rest"，而不是更低级的"bpmworkflowruntime"，其入口路径仅为"/workflow service"。那么，我们为什么不在这里使用改进的"workflowservice"路由名称呢？

考虑任务UI实例化的上下文。它作为一个组件，什么是物联网，在一个组件容器中，在一个已经运行的主机应用程序（我的收件箱）中。因此，目的地路由由主机应用程序的neo中定义的路由控制-应用程序.json，而不是任务UI的neo-应用程序.json.

换句话说，因为我的收件箱应用程序的真名是"bpmmyinbox"，它定义了一个路由"bpmworkflowruntime"，而不是"workflowservice"，我们也必须在我们的任务UI应用程序中使用它。

理论上，什么叫物联网，我们在任务UI应用程序的neo中实际上不需要任何目的地路由-应用程序.json指向BPM工作流运行时。除非我们这样做-如果我们想在部署UI之前测试它！在这种情况下，为了保持一致性，我们还需要使用"bpmworkflowruntime"。

在上一篇发现SCP工作流-组件启动的文章中，我们实际检查了任务UI的独立工具的关键部分。除了模板之外，这里没有什么特别之处，除了在组件容器的实例化中添加了settings属性，以允许在URL中传递任务实例ID：

我们已经看到了组件.js上一篇文章中的文件–init函数。以下是完整的来源：

其余部分相当标准，加上我们有"completeTask"、"fetchToken"和"refreshTask"功能，这是我直接从Christian Loos的文章《SAP云平台工作流入门-如何构建简单的审批UI》中提出来的。

这是模型模块的外观：

没有什么令人兴奋的地方。我们可以看到createAppModel函数，我们从组件的init函数调用该函数来创建应用程序模型，该函数具有单个属性taskDescription，初始值为空字符串。这将很快在视图中使用，大数据说，实际值通过调用从特定工作流实例中的用户任务的描述中获取startupParameters.inboxAPI.getDescription函数（见前面）。

这个描述值的有趣之处在于，它特定于正在进行的特定工作流，并且可以构建从静态字符串和变量替换。但不是在UI5的上下文中…它实际上是在工作流定义本身中。

请看我们在上一篇发现SCP工作流-用户任务的帖子中看到的屏幕截图：

此处的描述字段（"您最近签入…"）是我们根据应用程序中的taskDescription属性检索和存储的内容的来源模型。

让我们在这里快速看一下，这样当我们很快看到视图时，至少我们对文本替换有了一个概念。

现在我们开始讨论可能最有趣的部分–任务UI本身是如何构造的。但我们发现其实几乎没有什么特别的。这是一个常规的XML视图，其中引用了一个控制器（我们将在下面介绍），以及一个可以显示签入啤酒和推荐啤酒的页面：

整个页面控件绑定到域模型（工作流上下文）中的根属性"啤酒"，因此所有其他属性都与此相关。如果我们知道这个上下文是什么样子的，也就是说，在域模型中是什么，那么阅读这个视图定义就更容易了，所以看看"beerinfo"资源的untappdapi文档，因为在工作流的这一点上，上下文正好包含这个。您可以看到API文档中的root属性确实是"beer"。

让我们快速查看一下我拥有的一个现有工作流实例的上下文：

请求：

响应：

让我们在此视图中选择至少值得注意的部分：