本系列的上一篇文章：发现SCP工作流–脚本任务。
本篇文章是本系列的一部分，可在此处找到指南：发现SCP工作流。
我们几乎完成了！在上一篇文章中，我们研究了如何将数据编组以发布到标称啤酒愿望列表。现在是时候将数据发送到愿望列表了。由于本系列的重点是SAP云平台上的工作流服务，而不是外围事务，因此我们将把wishlist条目附加到远程数据服务的列表中。我将把它作为一个练习留给读者来实现一个用于愿望列表数据的UI。
与脚本任务一样，服务任务非常简单。考虑到它们是为向远程端点发出HTTP请求而设计的，它们的参与度稍微高一些，而且有时还需要一些修饰，人工智能工作，主要与安全性和连接性方面有关。
那么，我们在哪里呢？我们已经整理好了愿望清单条目数据并准备发送。让我们提醒自己它是什么样子：
除了G套件，我也是Firebase生态系统的忠实粉丝，云端云服务器，已经涉猎了一段时间（包括思考将Firebase添加到UI5的可能性——如果你好奇，请参阅2012年的"Firebase和SAPUI5"帖子）。我创建了一个简单的Firebase项目，即时通讯云平台，物联网公司排名，并将数据库用作我的目标wishlist存储系统。在Firebase数据库上构建UI5应用程序非常简单；我和我的前朋友建立了一个Firebase驱动的仪表板和独立的UI5应用程序来控制它——它于2017年在巴塞罗那的SAP TechEd的谷歌展台上展出。
以下是数据的样子——每个wishlist条目都显示为"wishlist"节点中的一个节点：
您可以看到整理好的数据的结构直接反映为子节点。在wishlist节点中有另一个折叠的节点（以"pfazgr"结尾），包含另一个wishlist条目。
服务任务是工作流定义中的最后一个任务，详细内容如下：
您可以在Murali Shanmugham的great系列中看到这些服务任务设置的更详细的解释，特别是在SAP云平台中使用工作流和业务规则实现用户自注册场景的第3部分。我们将只关注这里需要的设置。
像这样的服务任务的执行是三件事之间可爱的协调的结果：
对工作流实例上下文的访问工作流服务中处理XSRF令牌获取和后续利用的机制SAP云平台上的连接服务
这里我们指定了"untappdwishliststore"作为"Destination"设置的值。你猜对了-这是一个在连接服务中管理的目的地，一个在SCP中几乎所有事情的中心服务。
让我们快速看看这个目的地是如何定义的：
这里URL的完整值是：
如果你参考Firebase数据库REST API文档，您将看到这是Firebase项目"untappdrecommendations"中数据存储的"根"URL，只需扩展URL以包含指向所需节点的路径信息，就可以对数据存储中的节点进行读/写访问。例如，此URL:
引用"wishlist"节点，因此GET请求的工作方式如下：
请注意，文档描述了如何简单地将".json"附加到URL以使事情正常工作。
我们可以使用POST将子项添加到此节点，再次指定路径信息：
当然，我们需要提供json中的子项数据，即，碰巧，这正是服务任务将为我们做的。
考虑到这一点，为脚本任务的路径设置指定的值确实是/wishlist.json文件"，它将附加到目标中定义的URL。
此资源不受XSRF保护，大数据分析学习，因此我们不需要让脚本任务服务获取首先为我们提供令牌（然后在实际的POST请求中提供），因此"Path to XSRF token"设置保持为空。
最后，我们需要指定要发送的数据的位置，以及要存储在响应中返回的数据的位置（如果有）。在我们的例子中，我们已经将wishlist条目编组到上下文中的"wishlistEntry"属性中，所以这就是我们指定的内容。而且我们对响应负载不感兴趣，所以我们没有为响应变量设置指定任何内容。我们选择了作为建议突出显示的两种啤酒：
脚本任务根据这些选择编组wishlist条目，服务任务启动，将此wishlist条目发送到Firebase数据库中，它立即出现的位置（我们在这里查看Firebase控制台数据库视图/编辑器）：
保留在workflow monitor应用程序中（我们在查找SCP workflow–the monitor时一直查看该应用程序），我们可以看到执行日志在项目消失之前一直运行到完成（因为实例设置为完成）：
单击"untappdwishliststore"链接，那里显示了用于服务端点的方法和URL：
我认为值得一提的是，工作流中此步骤的早期迭代看到我尝试将数据发送到一个Google电子表格，使用googleapps脚本（公开一个web应用程序）。这是我经常做的事情，而且非常有用。
我通常使用内容服务来返回对我正在使用这样一个脚本处理的请求的响应，但是有一个安全设计功能，这意味着对这些web应用的请求的响应是通过HTTP 302重定向机制从不同的主机提供的。这一切都很好，但是HTTP规范规定：
"如果302状态码是响应GET或HEAD以外的请求而收到的，除非用户能够确认，否则用户代理不能自动重定向请求，因为这可能会改变发出请求的条件。"
这意味着，当向响应302状态码的端点发送POST请求时，服务任务机制不能自动遵循该重定向，因为它遵循RFC2616。我们不能简单地忽略RFC2616！
结果是我无法成功向我的应用程序脚本发出POST请求。我可能会考虑在未来的迭代中避免使用内容服务，但现在它并不是那么重要。
