逻辑应用 Sharepoint 创建文件未按预期工作

Question

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

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

更多技术细节... 我尝试在逻辑应用中使用 base64toBinary() 将文件上传到 SharePoint： 由于 UI 隐藏了实际的表达式，因此该操作的代码如下所示（参见第 5 行）：

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

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

Answer 1

自然地，在向全世界发布一个问题，然后睡个好觉之后，我找到了答案。问题在于 Designer 生成的 JSON 表示法。在上面的代码中，您可以看到我在哪里使用了 base64toBody() 函数。我意识到它在将二进制文件转换为对象的整个函数周围都有花括号。通过删除大括号，文件现在作为二进制文件正确地传递给 SP：

"body": "@base64toBinary(items('For_each_file_attached')?['documentbody'])",

所以如果你想让它工作，我必须使用编辑器中的代码视图来使它正确。我很想知道是否有办法在从 CRM 检索它和使用创建文件操作之前进行从 base64 到二进制的转换，以便它可以成为更多的 OOTB 设计器。