我创建了一组逻辑应用程序，以在 D365 CE (CRM) 和 SharePoint 之间进行非常专业的集成。我在 CRM 中使用 Notes 实体来允许用户使用 native CRM UI 上传 docx 文件。逻辑应用程序找到该文件(使用 CRM 列表项操作)并将该文件作为 base64 编码字符串返回。我能够查看逻辑应用程序执行日志以查看 base64 字符串，并且能够成功对其进行解码并在 Word 中打开它，因此我知道一切运行正常。
问题是当我尝试使用 LA 创建文件或更新文件操作创建或更新 SharePoint 文档时。 SharePoint 中生成的文件具有正确的名称，但当我尝试使用 Word(任何版本)打开该文件时，出现错误。在上传到 CRM 并从 SharePoint 下载之前，我检查了 docx 文件，文件之间的字节存在一些差异 - 我的猜测是某些地方没有处理 Unicode 转换。在这张图中，您看到docx的PK签名(感谢Phil Katz)出现在前两个字节中，并且出现了其他几个字符串，但是(我认为是高位字符)没有正确转换(顶部的原始文件) ，并从底部的 SP 下载后):
更多技术细节...
我尝试在逻辑应用程序中使用 base64toBinary() 将文件上传到 SharePoint:
由于 UI 隐藏了实际表达式，因此该操作的代码如下所示(参见第 5 行):
问题是，base64toBinary() 没有返回文件的忠实表示，或者创建文件不高兴将 docx 文件作为二进制文件作为参数。我尝试过将原始的base64字符串直接传递给SP，但它只是将其存储为base64，并要求我在打开它之前下载/转换它，是的，我尝试过使用base64toString()。我还使用纯文本文件测试了该过程，效果很好。
我正在使用 D365 v8.2.2 和 O365 SharePoint。
最佳答案
自然地，在向全世界发布问题并睡个好觉后，我找到了答案。问题出在设计器生成的 JSON 表示法中。在上面的代码中，您可以看到我在哪里使用了 base64toBody() 函数。我意识到它在整个函数周围有花括号，将二进制文件变成了一个对象。通过删除大括号，文件现在已作为二进制文件正确传递到 SP:
"body": "@base64toBinary(items('For_each_file_attached')?['documentbody'])",
因此，如果您希望它起作用，我必须使用编辑器中的代码 View 来使其正确。我有兴趣知道是否有一种方法可以在从 CRM 检索数据和使用“创建文件”操作之前将其从 Base64 转换为二进制，以便它可以更加 OOTB 设计器。
关于dynamics-crm - 逻辑应用程序 Sharepoint 创建文件未按预期工作，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49373864/