我喜欢拼图。尤其是和SAP有关的时候。当我发现一个有趣的话题，我不会离开我的办公桌，直到我找到解决办法。所以，物联网产品，当我的同事罗曼·布罗伊奇给我写了一条短信，说他在和奥达塔和SAP搏斗时，我的眼睛睁得大大的，呼吸加快了。我早就知道它会完全吸收我。"这不可能是小事，否则他连提都不提"—我想。所以我就给我妻子写了一条短信，人工智能怎么样，说她下班后不应该打扰我，我准备了一杯新鲜的咖啡，准备走了。

Roman关于将物联网设备与SAP连接的教程可以在这里找到：https://github.com/ROBROICH/SAP\u和\u AZURE\u IOT\u DEM

我强烈建议你去看看！

这个问题其实非常恼人。我们尝试使用Azure Logic应用程序在SAP中使用OData服务创建记录，但每次我们都收到一个错误消息，说"CSRF令牌验证失败"。

快速的互联网搜索证实了我的怀疑，我们不是唯一面临这个问题的人。我发现SAP Note 2597429–"Fiori/OData PUT或POST字段更新或Use as Request的CSRF令牌验证失败"引用了一个很棒的博客"CSRF令牌的问题和解决方法"，我认为谜团已经解开了。我甚至有点失望。我修改了我的逻辑应用程序来检索丢失的CSRF令牌，并通过添加以下标题将其与下一个调用一起发送：

你能想象当我检查结果并且问题仍然存在时我有多惊讶吗？

在仔细检查我是否传递了正确的令牌后，我开始寻找另一种解决方案。我第三次阅读上述SAP说明，但它并没有让我更接近解决方案。"我想，我很快准备了两个请求：

虽然我在发送POST请求时收到了内部服务器错误（由于缺少消息体），但OData服务没有抱怨CSRF令牌丢失或不正确。当我查看消息头时，我注意到一个小的差异。

在GET请求中，我们可以清楚地看到身份验证头，它在第二次执行中丢失了。POST调用有一个Cookie头，这意味着Postman很聪明，并尝试使用SAP系统发送的Cookie重新使用连接。这是有意义的——每次用户通过身份验证时，SAP后端都会生成一个新的CSRF令牌，这就是为什么在我的Logic应用程序的第二次调用中我会得到错误。由于邮递员正在重新使用cookies，它不会再次发送身份验证头，因此令牌保持不变。

好的，这在逻辑应用程序中很容易做到。我添加了一个新的Cookie参数并删除了身份验证。我的第二个请求如下：

我执行了应用程序，但不幸的是，我收到了一个更令人惊讶的消息：

在这一刻我变得非常困惑。在比较Postman和Logic应用程序执行时，我找不到任何有意义的区别。如果设置了Cookies，为什么我没有授权？

大约一小时后，我看到了日光。在Postman的响应头中，我可以看到Set Cookie的三个条目，但是Azure Logic App只显示了一个条目。

Postman:

Logic Apps:

区别在于Postman在第二次调用中只使用了最后一个条目，而Logic App连接了所有条目。在打印屏幕上看不到，淘客文案，但是完整的cookie看起来是这样的：

条目是用逗号分隔的。最初我计划使用子字符串操作来分块Cookie的第三部分，但不幸的是，每次执行的MYSAPSSO2长度都不同，因此这不是一个选项。我可以写一个小的函数应用程序或使用集成帐户来做一些字符串转换，大数据网，但我认为一定有一个更简单的解决方案！我注意到在一个Cookie头集中，每个参数都用分号而不是逗号分隔。我的下一个修改是用分号替换所有逗号，物联网的应用，让SAP决定它要找什么。我将Cookie参数设置为：

瞧！没有身份验证错误！

从服务器收到的500个内部服务器错误是由于空负载造成的，但这是我可以很容易修复的。此外，我将contenttypeheader设置为application/atom+xml；charset=utf-8，并从URL中删除了不必要的参数（否则会得到UnsupportedMediaType异常）。我点击运行

执行成功！201状态码表示记录已在SAP系统中创建。