编写脚本来实现复杂的业务逻辑
某些 Dynamics 365 Field Service 实现包括功能和复杂的业务逻辑，这些功能和复杂的业务逻辑超出了 Field Service 提供的现成流程。 有时，这些复杂性甚至超出了平台选项，例如工作流和业务规则。 对于复杂的要求，开发人员可以创建自定义代码。
实现复杂的业务逻辑通常涉及在服务器端编写插件，以及在客户端编写 JavaScript Web 资源。
本文探讨以下最佳做法：
- 在编写任何脚本之前，请研究现有的 Field Service 流程和功能。
- 尽可能避免编写脚本。 首先，尝试使用平台选项，例如 Power Automate 和 工作流。
- 异步（而不是同步）运行脚本。
- 避免在加载表单时加载脚本。 相反，仅在需要时加载它们。
- 对脚本运行解决方案检查器。
- 不要编辑或删除现有窗体库。
脚本类型
插件
插件提供了一种在 Microsoft 的事件驱动的 Dynamics 365 平台上编写您自己的自定义功能的方法，适用于您能想象到的几乎任何流程。 插件充当事件处理程序，并注册为在 Dynamics 365 中的特定事件上运行。 插件是用 C# 编写的， Visual Basic它们可以在同步模式或异步模式下运行。
自定义插件可帮助：
- 运行一些业务逻辑，例如在创建或更新 Dynamics 365 记录时更新记录的特定字段或更新相关记录。
- 在特定事件上调用外部 Web 服务，例如在保存或更新记录时。
- 在打开任何记录时动态计算字段值。
- 自动执行流程，例如在 Dynamics 365 中向客户发送有关特定事件的电子邮件。
JavaScript Web 资源
JavaScript 提供了一种应用自定义业务流程逻辑以在 Dynamics 365 中的窗体上显示数据的方法。 在 Field Service 的上下文中，开发人员可以将 JavaScript 添加到工作订单和预订窗体以强制执行业务逻辑。 他们还可以将 JavaScript 添加到日程安排板以创建预订规则，当在日程安排板上创建预订时执行验证。
步骤 1. 了解编写自定义脚本的风险
向 Field Service 实施添加插件和 JavaScript 时要小心。 过多的脚本和编写不当的脚本是导致性能不佳和错误的主要原因。 仅当自定义项对于运行 Field Service 操作至关重要时，才编写脚本。
在编写和实现脚本之前、期间和之后，请仔细阅读本文和相关内容。
步骤 2. 检查 Field Service 或 Dynamics 365 是否满足要求
在编写插件或 JavaScript Web 资源之前，请务必检查 Field Service 或其他 Dynamics 365 应用是否可以执行相同的功能或类似的功能。 重复的流程可能会导致错误和性能问题。
步骤 3. 首先尝试使用平台选项
在编写自定义脚本之前，请尝试使用平台选项（如 Power Automate工作流和业务规则）来满足您的要求。
如果您无法通过使用平台选项来满足您的要求，请确定工作流是否可以关闭到足以帮助您的业务。 平台选项更具可扩展性，更受支持，在升级过程中不太可能中断，并且性能更好。
要了解有关如何使用平台选项的更多信息，请 转到何时使用插件与工作流？
步骤 4. 在编写插件或脚本之前查看最佳实践
很多最佳做法是基于开发人员在数千个 Dynamics 365 实现中的经验建立的。 在编写插件或脚本之前和期间，请查看以下最佳实践：
- 在 Microsoft Dataverse 中进行插件和工作流开发的最佳做法和指南
- 模型驱动应用的客户端脚本的最佳做法和指南
- 使用 Dynamics 365 Customer Engagement 进行开发的最佳做法
- JavaScript 定制
- Microsoft Dataverse 中的可扩展自定义设计
第 5 步。 使用工具测试脚本
编写脚本后，必须对其进行测试。
首先， 使用解决方案检查器来验证您的模型驱动应用 Power Apps。 解决方案检查器可识别脚本是否违反了最佳做法，例如同步运行而不是异步 运行。
然后，使用插件探查器调试问题。
窗体库
许多 Field Service 记录类型（如工作订单（如下图所示））都具有默认情况下包含在 Field Service 中的 JavaScript 表单库。 这些库执行重要的流程。
重要提示
不要编辑或删除窗体库。
日程安排板上的 JavaScript（预订规则）
预订规则提供了一种使用 JavaScript 在日程安排板上执行验证的方法。 但是，与在其他表单（例如工作订单）上使用 JavaScript 时一样，请谨慎操作。 不要创建多个预订规则。 相反，请考虑使用 预订警报 来提醒调度员有关问题的信息。