亲爱的社区，淘客怎么做，
你可以放松我今天不谈阿尼了？但我下次可能会"回到"这个话题上。这篇文章将是关于关闭SAP审批流程的循环，这些流程将出现在Outlook中。因此，我们不仅可以看到如何根据SAP的批准请求采取行动，还可以在电子邮件中看到自适应卡的更新，以防其他人已经"批准"。很刺激吧？也许，只是缺少兴奋，可能有更多的电影参考线进一步？
我不会重复OData集成或适配卡的通信基础，因为社区已经很好地涵盖了它们。
例如，我非常喜欢Harald Schubert的这个原型。他将SAP云平台工作流服务与Outlook相结合，并能够从工作流表单生成自适应卡。
让我们看看移动部分
图1集成场景概述，消息更新
我正在及时运行Power Automatic上的流程，因为我无法控制SAP的演示系统ES5。否则，我更喜欢基于S/4hanabusinessevents之类的推送机制。让我们按照图1中的气泡进行操作，并详细讨论步骤。
我的流程检查ES5上的OData服务，以获得我的用户的待定批准：
https://sapes5.sapdevcenter.com/sap/opu/odata/sap/SEPMRA\u PO\u APV/PurchaseOrders？$format=json&$filter=OrderedByName eq'Firstname'。
之后，我对adaptive card ui的响应稍加润色并发送它。请注意，我创建了两个流：一个用于团队作为目标，另一个用于Outlook。卡的结构是相同的，但操作的实现方式不同。对于Teams连接器，这是内置的，淘客程序，但是对于Outlook，我需要提供一个从按钮调用的端点。如果您想了解更多信息，请查看下面的比较以供参考，或者查看此处的团队和Outlook文档：
图2自适应卡中的操作比较
在Microsoft世界中，您还可以经常看到与Outlook一起使用的自适应卡的术语"可操作消息"。让我们用它来避免进一步混淆Outlook上的卡片。到目前为止还不错。现在开始抛光？
例如OData时间戳格式需要转换为UTC才能很好地显示。
图3自适应卡上日期时间格式的屏幕截图
功能和显示分别如下：
图4团队自适应卡的屏幕截图
不用担心，您可以在我的GitHub回购上找到完整的流程供您剥离对于零件，
对于此类批准，您通常有多个人，他们可以这样做。因此，您可以有多个单独的目标或团队通道/共享收件箱来实现这一点。接下来，我的同事Tobias从我们的团队频道中批准了这个过程（参见图4）。
图5更新的团队卡截图
因此，团队频道中的每个人都从feed历史中了解到，该卡和相应的过程没有什么需要做的了。但现在的前景如何呢？当你打开电子邮件时，它们通常不会自动改变，对吗？正确的！！！我明白这是否有点吓人：当你看邮件时，邮件会突然发生变化，什么都不碰。但我保证这会比滑稽有趣？。
再次通过OData审批：
https://sapes5.sapdevcenter.com/sap/opu/odata/sap/SEPMRA\u PO\u APV/ApprovePurchaseOrder？sap client=002&POId='@{body（'Parse\u JSON\u flat'）？['POId']}'&Note='Thanks'
要从Power Automatic或Logic应用程序中完成这项工作，合肥大数据，您需要了解一种特殊的Cookie格式。您不仅需要获得X-CSRF-Token，还需要在传递之前将cookie头上的逗号替换为分号：
图6关于打开时神秘电子邮件刷新的Gif
请记住ES5的采购订单已经得到团队的批准。上面的gif*显示，万云，我的审批请求在打开时得到更新。这得益于可操作消息的奇妙自动调用操作。这样我就可以调用端点来获取更新的信息。在gif的末尾，您可以看到可操作的消息内容，免费大数据，闪亮的按钮被一个文本替换，说明Tobias已经批准了该请求。
*这是我第一次从视频转换到gif->仍在努力提高分辨率
只有一个警告：出于用户体验的原因，这些更新请求需要在2分钟内完成秒。不幸的是，由于演示系统的延迟、负载和性能能力，向ES5发出OData请求以检查批准请求的状态通常需要3秒或更长的时间。例如，在你自己的Azure设置中，你可以在你的Azure区域内处理这个问题。
由于这个障碍，我添加了一个"近岸"表存储，当我通过Power Automatic请求批准请求时，它会临时存储批准请求的ID。显然，当您直接在ES5中批准时，这是行不通的。同样，这对您自己的系统没有问题，因为您可以相应地调整流程。
关于生产准备的想法
要使此场景更适合生产，您需要对以下几点进行微调：
确保呼叫和响应的安全：您不能通过！你读了这么久就得到了那部电影的参考资料？有一个不错的博客和一个docs条目，介绍如何使用令牌和签名卡来验证从可操作消息接收消息的服务的发送者。多位接受者：我们之前简单地讨论过这个问题。您可能希望将这些批准广播给多个收件人。这些选项是powerautomatic中的并行分支，通过单个用户和Outlook上的共享邮箱使用团队通道。这是另一个博客，上面有一些插图。识别用户：我是在开玩笑和引用我的同事Tobias，尽管我的流程实际上没有识别任何人。但是您可以增强示例，让Microsoft Graph或O365连接器实际识别运行流的用户，并在您的消息中使用该信息。卡片设计：准备好对服务延迟和错过的更新做出反应。这样做的一个选项是CARD-ACTION-STATUS，例如，您可以对来自powerautomatic的过时批准做出反应。一旦您将OData请求发送到ES5，它会让您知道请求已经消失了。该响应可以作为附加消息返回给团队中的用户，也可以通过Outlook中的错误标注（查看卡片操作状态以了解详细信息）返回给用户，说明请求已被批准。Power Automated flow/Logic应用程序的弹性：这两种技术都实现了重试策略（目前默认为4个），可以解决许多现成的延迟问题。对于问题较多的情况，建议创建单独的分支来处理错误。我喜欢"configure run after"选项。红色箭头表示此路由将在出现错误时执行（已失败、已跳过、已超时）。另一个箭头为黑色，只有在前面的操作成功时才会继续。
最后一句话
