【问题标题】:MS Dynamics365 - generate custom serial number, ensure uniquenessMS Dynamics365 - 生成自定义序列号,确保唯一性
【发布时间】:2019-11-25 05:31:32
【问题描述】:

我正在开发基于 Dynamics365 CRM 的解决方案,对于我们定义的自定义实体,我们需要创建自定义序列号。

出于各种业务原因,GUID 和顺序编号方案都行不通 - 业务坚持采用以下格式

99-9999-9999

其中每组数字基本上是一组随机数字。

在插件中创建它们很容易 - 但我如何确保唯一性?我本质上是一名 C#/SQL Server 开发人员,在 SQL Server/T-SQL 中,我只需在此列的“实体”表上创建一个唯一索引。检查是否存在新创建的号码很容易 - 只需执行

IF EXISTS (SELECT * FROM dbo.MyEntity WHERE SerialNum = @SerialNumGenerated)

检查一下,由于该单列已编入索引并且NOT NULL,因此它也会非常快。

但是如何在 Dynamics365 中做同样的事情(至少尽可能“相同”)?如果尚未使用新创建的“序列号”,我如何以编程方式检查(在我的 C# 插件中) - 并且这样做足够快,不会过多地减慢保存过程?我还能以某种方式在我的自定义实体上“索引”该属性并执行类似于IF EXISTS() 签入 T-SQL 的操作吗?

感谢任何提示或指点!

【问题讨论】:

  • 嗯,它仍然可以是连续编号... 1 => 00-0000-0001, 2=>00-0000-0002 ....
  • @Selvin: no - 没有顺序编号 - 它明确要求是随机数组
  • 你可能会觉得this article很有趣。
  • @Aron:谢谢-但这又只是普通的旧序列号生成-这不是我要找的
  • 在相关说明中,虽然我有一段时间没有这样做,但 Microsoft 支持应该能够为您在序列号列上创建一个 custom index。您可能还想查看alternate keys 是否自动获取索引。

标签: c# plugins dynamics-crm unique-constraint dynamics-365


【解决方案1】:

您想在手术前插件中进行此编号。这是完全保证唯一性的唯一方法,它的性能非常好,并且该数字将在创建记录时立即存在。

1) 生成字符
您可以使用任何您想要的方法,作为数据库开发人员,我通常只默认使用我熟悉的方法,Guid.NewGuid().ToString(); 的子字符串;

2) 检查唯一性

    QueryExpression query = new QueryExpression("[prefix_yourentityname]")
    query.Criteria.AddCondition("prefix_yourfieldname", ConditionOperator.Equal, [IDNumber]);
    query.TopCount = 1;
    bool isUnique = Service.RetrieveMultiple(query).Entities.Count = 0;

3) 在目标上设置 ID 号,以便与事务一起保存

性能:
此检查显然会导致对数据库的小型读取操作,但您没有更好的选择。如果您使用的是本地 CRM,您可以针对该表添加索引,包括 ID 字段。 Microsoft 支持为 CRM 数据库编制索引。

如果您使用在线 CRM,您唯一能做的就是将您的 ID 字段添加到此实体的快速查找视图“查看列”和“搜索列”中。 CRM 应用程序根据快速查找视图中的配置为每个表生成一个索引,因此将您的 ID 列添加到此视图将导致该字段被添加到索引中。

【讨论】:

  • 是的,这基本上是我的广泛想法。我有点不确定的一点是如何检查生成的新密钥是否足够快,这样就不会对性能造成太大的损害。在 SQL Server 中,我会通过使用 IF EXISTS() 子句而不是 COUNT(*) > 0 来进行优化以提高效率 - 我也可以在 Dynamics 中做类似的事情吗?
  • 我相信使用 TopCount 属性可能会使您的查询基本上像 IF EXISTS() 一样工作。 EXISTS 优于 COUNT(*) > 0 的性能优势是 EXISTS 一旦找到一条记录就会退出,我相信如果设置 TopCount = 1 也是如此。更新了我上面的代码。
  • 我还添加了一些关于表索引的信息。
  • 术前插件如何保证唯一性?
  • 预操作插件在创建记录之前同步执行。如果在此交易期间您检查并确认生成的号码不存在,那么您将永远不会创建重复。
【解决方案2】:

假设您无法设计一个在天文上不太可能生成重复项的生成公式(例如 GUID)。您将需要遵循这个一般逻辑。

  1. 运行公式以创建唯一 ID。
  2. 通过 RetrieveMultiple 搜索 CRM 以检查任何已使用该号码的记录。
  3. 如果号码已经存在;回到 1。
  4. 其他;使用新 ID 更新记录。

然后您必须决定在哪里执行您的代码。我想到了两个选项。

  1. 在“盒子”中,例如插件或 JavaScript。在这种情况下,您可能会遇到一个问题,即可能在不知道彼此的情况下同时执行多个公式。根据您的公式生成重复项的可能性以及创建记录的速度,这可能是可以接受的。

  2. 走出“盒子”,例如一个按计划运行的控制台应用程序,用于查找没有编号的记录。然后它对每条记录一一编号。单线程方法具有确保唯一性的好处,但从用户的角度来看会更慢。

如果是我并且我必须实现这个要求,我会选择选项 2。

【讨论】:

  • 是的,这基本上是我的广泛想法 - 我有点不确定的是如何检查生成的新密钥是否足够快,这样它就不会陷入困境系统。从动力学的角度来看,在这种情况下我能做些什么来通过“RetrieveMultiple”进行检查真的很快吗?就像例如在实体的属性上创建索引,或者类似的东西?
  • @marc_s 它可能会足够快,但是;前提是你可以添加自己的indexes,理论上微软在线创建索引automagically。除此之外,您可以查看某种架构,在其中预先生成所有 id 并将它们放入您弹出的队列中,这样您就不必检查了。
猜你喜欢
  • 2020-05-11
  • 2021-07-13
  • 1970-01-01
  • 2018-06-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-09
  • 1970-01-01
相关资源
最近更新 更多