Dynamics crm 逻辑应用程序Sharepoint创建文件未按预期工作

我创建了一组逻辑应用程序，以便在D365 CE（CRM）和SharePoint之间进行非常专业的集成。我正在使用CRM中的Notes实体，以允许用户使用本机CRM UI上载docx文件。Logic应用程序查找该文件（使用CRM列表项操作），并将该文件作为base64编码字符串返回。我能够查看Logic应用程序执行日志以查看base64字符串，并且我能够成功地解码它并在Word中打开它，因此我知道很多操作都是完美的

问题是当我尝试使用“创建文件”或“更新文件”操作创建或更新SharePoint文档时。生成SharePoint的文件具有正确的名称，但在尝试使用Word（任何版本）打开该文件时出错。在上传到CRM和从SharePoint下载之前，我检查了docx文件，文件之间的字节存在一些差异——我猜某个地方没有处理Unicode转换。在这张图片中，您可以看到docx的PK签名（感谢Phil Katz）出现在前两个字节中，其他几个字符串也出现了，但是（我认为是高阶字符）没有正确转换（顶部是原始文件，从底部的SP下载后）：

还有一些技术细节。。。 我尝试在logic应用程序中使用base64toBinary（）将文件上载到SharePoint： 由于UI隐藏了实际表达式，因此此操作的代码如下所示（请参见第5行）：

问题是base64toBinary（）没有返回文件的忠实表示，或者创建文件不喜欢将docx文件作为二进制文件作为参数。我曾尝试将原始base64字符串直接传递给SP，但它只是将其存储为base64，并要求我在打开它之前下载/转换它，是的，我尝试使用base64toString（）。我还用一个纯文本文件测试了这个过程，效果很好

---

我正在使用D365 v8.2.2和O365 SharePoint。

当然，在向全世界发布了一个问题，然后睡了个好觉之后，我找到了答案。问题在于设计器生成的JSON符号。在上面的代码中，您可以看到我在哪里使用了base64toBody（）函数。我意识到它在整个函数周围都有花括号，将二进制文件变成了一个对象。通过删除大括号，文件现在以二进制文件的形式传递给SP：

“正文”：“@base64toBinary（items（'For_each_file_attached'）？['documentbody']）”

因此，如果您想让它工作，我必须使用编辑器中的代码视图使其正确。我很想知道是否有一种方法可以在从CRM检索base64到使用CreateFile操作之前将其转换为二进制，从而使其更适合OOTB设计器