【问题标题】:D365 Can I update systemuserid?D365 我可以更新 systemuserid 吗?
【发布时间】:2020-01-21 07:47:21
【问题描述】:

在我们的 D365 在线环境中,我们有多个沙盒和生产实例。在每一个中,systemuserid 都是不同的(用户导入是在我加入之前完成的!!)。添加新用户时也会发生 SystemUserId 中的这种不匹配。 (例如上周添加的我自己的用户记录)

我知道在 onPrem 中更新 systemuserid 不受支持,但这是可能的,但在在线环境中,解决此问题的最佳选择是什么?使用不同的 Guid,在不同环境中移动解决方案时,所有参考(工作流程等)都会失败。

作为我的最后一个选择来到这里,因为我已经用谷歌搜索并查看了 SDK。

谢谢,

【问题讨论】:

  • 唯一受支持的更新或插入数据的方法是通过 API 完成的。在所有环境中,我相信。听起来完全刷新您的开发环境可能是唯一“简单”的解决方案。

标签: dynamics-crm microsoft-dynamics dynamics-crm-online dynamics-365 user-guide


【解决方案1】:

您根本无法更新 ID。我通常在我的所有开发环境中复制我的生产数据库以避免这个问题。 D365 也可以轻松做到这一点。您应该在两个 sprint 之间花一点时间来执行此操作,因为它有助于让系统用户 ID 和实体对象类型代码在任何地方都相同。

【讨论】:

  • 有趣的是,将生产实例复制到沙箱是否会保留所有被复制实体的 GUID,甚至包括在 Minimal 中的“系统”实体?
  • 它保留了一切。它可能会影响系统用户的域名和组织设置,因为导入必须与新的服务器/环境进行映射。
  • 复制生产也会导致 systemuserid 重复。当我们通过 365 管理门户添加新用户并将用户权限分配给 Dynamics CE 时,我们再次在 systemuserid 中得到重复。对我来说,这个问题分为两部分,修复现有的 guid 并防止未来的新用户 guid 被复制。
  • @Nick 导入,映射...您指的是本地部署吗?
  • 是的,我指的是本地部署,但当然,在这种情况下,Azure 会为您完成。
【解决方案2】:

将数据硬编码到流程中是一种不好的做法,会使您的流程变得非常僵化。您可以创建一个配置实体,在那里设置系统管理员 ID 并检索它。如果您有自定义工作流活动,您将能够检索记录并在每个配置任务中使用它。

【讨论】:

  • 我从一开始就试图把这个想法卖给项目经理,经过调查后,我觉得这是我唯一的选择。
猜你喜欢
  • 2017-03-15
  • 2018-01-20
  • 2012-05-31
  • 2013-03-06
  • 1970-01-01
  • 2018-05-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多