Dynamic365-应用开发指南-全-

Dynamic365 应用开发指南（全）

原文：annas-archive.org/md5/0efaacf1c2685069338ee9023fc77627

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

本书将向您介绍新的设计工具的组成部分，例如用于业务流程的 SiteMap、App 模块和 Visual Designer。深入学习后，您将了解如何利用 Dynamics 365 中 PowerApps 的功能开发自定义的 SaaS（软件即服务）应用程序。您将学习如何使用 Microsoft Flow 自动化业务流程，然后我们将探索 Web API，这是 Dynamics 365 CRM 中最重要的平台更新。您还将学习如何在自定义应用程序中实现 Web API，编写一个 Azure 感知插件，设计并集成云感知解决方案。最后，本书将介绍如何配置服务，使用新发布的功能，如可编辑网格、数据导出服务、LinkedIn 集成、关系洞察和实时辅助。

本书适用对象

本书面向有经验的开发人员，他们希望构建业务解决方案软件，并且对 Microsoft Dynamics 365 应用程序开发（尤其是 CRM 领域）不熟悉。

本书内容概述

第一章，自定义应用程序导航，探索了 Site Map 设计器，这是 Dynamics 365 CRM 中引入的一个新的基于 Web 的工具，允许自定义人员快速定义应用程序中的导航。之前，用户需要导出 SiteMap XML 并手动在 XML 编辑器中更新，或者使用某些第三方工具。内置的 Site Map 设计器使得编辑应用程序的站点地图变得更加容易。

第二章，使用 App 模块设计器设计应用程序，介绍了 App 模块设计器，它使得为用户添加特定应用程序组件变得更加容易。基本上，一个应用程序是相关实体、仪表板和业务流程流的集合，经过优化，使最终用户只能看到与他们相关的 Dynamics 365 CRM 组件。

第三章，使用 Visual Process Designer 定义流程，解释了 Visual Process Designer，它为 Dynamics 365 CRM 的业务流程流带来了拖放设计功能。Microsoft Dynamics 365 CRM 中的业务流程流工具旨在帮助引导用户通过系统中的业务流程。

第四章，使用业务规则设计器定义业务规则，带您了解业务规则，这是一种在 Dynamics 365 CRM 中引入的新界面。它经过了完整的用户界面改进，从逐步添加操作改进为拖放操作的方式。

第五章，创建自定义业务应用程序，解释了 PowerApps，它提供了模板来构建自定义的 SaaS（软件即服务）应用程序。Microsoft PowerApps 允许企业各层级的用户创建可用的移动应用程序。

第六章，使用 Microsoft Flow 自动化业务流程，将引导你创建你最喜欢的应用和服务之间的自动化工作流，从而减少工作量，提高效率。它是一个基于云的工具，普通用户无需开发人员的帮助即可轻松使用。自动化工作流被称为流（flows）。要创建一个流，用户指定在特定事件发生时应执行的操作。

第七章，使用 Web API 开发应用程序，涵盖了 WebAPI，它是 Dynamics 365 CRM 中最重要的平台更新之一。它替代了 OData 和最终的基于 SOAP 的服务。它基于 OAuth v2.0 和 Open Data Protocol (OData) v4.0 标准，这两种技术都已广泛应用，并且是平台无关的。因此，它可以从不同平台上的不同类型应用程序中进行调用。

第八章，在 Dynamics 365 中利用 Azure 扩展，解释了 Azure 扩展，它将消息请求数据发布到 Microsoft Azure Service Bus 上任何正在监听的应用程序。这为 CRM 与其他业务应用程序之间的集成提供了无限的可能性，无论这些应用程序是基于云还是本地部署。

第九章，在应用程序中使用可编辑网格，探讨了可编辑网格，它是 Microsoft Dynamics 365 CRM 中最受欢迎的功能之一。它提供了丰富的主网格和子网格（Web 和移动应用）的内联编辑功能，使得用户可以减少点击操作，直接进行操作，而无需导航到主记录。

第十章，配置 Microsoft Cognitive Services 与 Dynamics 365，解释了认知服务的配置，这使得人工智能能够被纳入并与 Dynamics 365 CRM 集成，特别是用于产品推荐和建议知识文章。推荐服务和文本分析服务连接可以在 Dynamics 365 CRM 内轻松配置。

第十一章，通过学习路径培训用户，介绍了学习路径，它允许用户编写自定义的应用内帮助体验，这些体验可能是特定于 CRM 解决方案的。它促进了 Dynamics 365 CRM 实施的学习和用户采纳。

第十二章，Dynamics 365 中的其他新功能，简要描述了 Dynamics 365 CRM 中一些在前面章节未涉及的其他新功能。

若要充分利用本书

本书假设读者对 Dynamics CRM 有一定基础知识，并希望学习 Dynamics 365 中引入的新特性。然而，未曾接触过之前版本并从零开始学习 Dynamics 365 的读者同样能从中受益。开发人员、自定义人员、管理员和高级用户都能通过学习 Dynamics 365 中引入的最新功能和变化提升他们的技能。

您可以通过 Dynamics 365 的试用实例（trials.dynamics.com/）以及 Visual Studio 2017 的免费社区版（www.visualstudio.com/vs/community/）尝试本书中提到的所有功能和主题。部分内容不适用于 Dynamics 365 的本地版本。

下载示例代码文件

您可以通过您的帐户在 www.packtpub.com 下载本书的示例代码文件。如果您在其他地方购买了本书，可以访问 www.packtpub.com/support 并注册，以便直接将文件发送到您的邮箱。

您可以按照以下步骤下载代码文件：

  1. 登录或注册 www.packtpub.com。

  2. 选择“支持”标签。

  3. 点击“代码下载与勘误”。

  4. 在搜索框中输入书名，并按照屏幕上的指示操作。

一旦文件下载完成，请确保使用最新版的工具解压或提取文件夹：

  • Windows 版的 WinRAR/7-Zip

  • Mac 版的 Zipeg/iZip/UnRarX

  • Linux 版的 7-Zip/PeaZip

本书的代码包也托管在 GitHub 上，网址为 github.com/PacktPublishing/Dynamics-365-Application-Development。我们还有来自丰富图书和视频目录的其他代码包，访问 github.com/PacktPublishing/，快去看看！

下载彩色图像

我们还提供了一份 PDF 文件，包含本书中使用的带色彩的截图/图示。您可以在此下载： www.packtpub.com/sites/default/files/downloads/Dynamics365ApplicationDevelopment_ColorImages.pdf。

使用的约定

本书中使用了一些文本约定。

CodeInText：表示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 句柄。例如：“监听应用程序需要实现 IServiceEndpointPlugin 接口的 Execute 方法，并使用 WS2007HttpRelayBinding，将 RemoteExecutionContext 从 Azure Service Bus 传递过去。”

代码块如下所示：

   Request: GET [Organization URI] /api/data/v9.0/contacts? 
    $select=firstname&$top=5
    Accept: application/json
    OData-MaxVersion: 4.0
    OData-Version: 4.0

粗体：表示新术语、重要单词或你在屏幕上看到的单词。例如，菜单或对话框中的词语会以这种方式出现在文本中。示例如下：“完成所有更改后，点击保存实体按钮：”

警告或重要说明如下所示。

提示和技巧如下所示。

联系我们

我们始终欢迎读者的反馈。

一般反馈：发送电子邮件至feedback@packtpub.com，并在邮件主题中提及书名。如果你有任何关于本书的疑问，请通过questions@packtpub.com与我们联系。

勘误表：虽然我们已尽一切努力确保内容的准确性，但错误仍然会发生。如果你在本书中发现错误，我们将非常感激你向我们报告。请访问www.packtpub.com/submit-errata，选择你的书籍，点击“勘误提交表单”链接并填写相关详情。

盗版：如果你在互联网上发现任何我们作品的非法复制品，无论其形式如何，我们将非常感激你提供其位置地址或网站名称。请通过copyright@packtpub.com与我们联系，并附上该材料的链接。

如果你有兴趣成为作者：如果你在某个领域有专长，并且有兴趣写书或为书籍做贡献，请访问authors.packtpub.com。

评论

请留下评论。当你阅读并使用完本书后，为什么不在购买本书的网站上留下评论呢？潜在读者可以参考并利用你的公正意见做出购买决策，我们 Packt 可以了解你对我们产品的看法，作者也能看到你对他们书籍的反馈。谢谢！

关于 Packt 的更多信息，请访问packtpub.com。

第一章：自定义应用程序导航

站点地图可以定义为一组链接，用户可以通过这些链接导航并浏览网站。在 Dynamics 365 及其早期版本中，站点地图是一个 XML 文件，用于定义应用程序或特定应用模块的用户导航。直到 CRM 2016，组织只有一个站点地图文件。随着 Dynamics 365 中应用程序的出现，现在每个应用模块都有一个站点地图文件。在自定义站点地图方面，直到现在，我们必须使用 XML 编辑器、文本编辑器或某些第三方工具进行更新。然而，在 Microsoft Dynamics 365 中，产品本身内置了站点地图设计器。该设计器允许管理员、定制员或具有适当权限的用户通过简单地添加、拖动和放置站点地图设计器画布中的组件，轻松定义应用程序的导航。在本章中，我们将涵盖以下内容：

  • Dynamics 365 中的站点地图概述

  • 了解设计器界面及其组件——区域、组和子区域

  • 可以在站点地图上执行的常见操作

站点地图概述

对于每个配置的应用程序，我们将为其定义一个单独的站点地图。默认情况下，我们将在配置 Dynamics 365 时配置一个 Dynamics 365 自定义应用程序。在 Dynamics 365 实例的配置过程中，我们还可以配置其他应用程序，如销售、现场服务、项目服务自动化或客户服务，如果我们在配置 Dynamics 365 时选择了这些应用程序。现在，让我们尝试了解如何使用 Dynamics 365 的站点地图设计器，以 Sales 应用为例。假设我们在配置 Microsoft Dynamics 365 时选择了销售，如下所示：

Dynamics 365 企业计划 1 试用版的链接可以在此处找到：signup.microsoft.com/Signup?OfferId=bd569279-37f5-4f5c-99d0-425873bb9a4b&dl=DYN365_ENTERPRISE_PLAN1。

这将配置 Dynamics 365 的销售应用程序。以下是销售应用的导航界面：

现在，在我们已经了解了站点地图的基础知识后，让我们看看站点地图设计器的界面，它包含哪些组件，以及我们如何使用它来更新销售的站点地图。

站点地图设计器概述

要访问我们的销售应用程序的站点地图设计器，请执行以下步骤：

  1. 使用具有系统定制员、系统管理员或任何适当安全角色的用户登录 Dynamics 365 销售应用程序，以便自定义站点地图。

  2. 转到设置 | 解决方案。

  3. 创建一个新的解决方案，并填写适当的详细信息。例如，我们创建了一个名为“网站地图解决方案”的解决方案，发布者为默认发布者，版本为 1.0.0.0。

我们还可以登录到默认的Dynamics 365 - custom应用程序，创建一个新的解决方案并将销售应用网站地图添加其中。

  1. 点击客户端扩展并在其中添加销售应用网站地图，如下所示：

我们也可以进入设置 | 自定义并更新默认解决方案中的网站地图。然而，作为最佳实践，我们应该创建一个单独的解决方案，并在其中添加需要自定义的组件。

双击它将打开销售应用网站地图，在网站地图设计器中供我们编辑。网站地图设计器画布允许我们操作区域、组和子区域组件：

在设计器画布中，我们可以进行添加、剪切、复制、粘贴、克隆和删除操作。

让我们详细了解这些组件。

理解网站地图中的组件

网站地图由三个主要组件组成：

  • 区域：区域可以定义为导航窗格中的主节点或区域，包含组及其相应的子区域。可以添加新的区域，或更新或删除现有区域。如果区域不包含任何可见的子区域，则该区域将被隐藏。

  • 组：组可以定义为一个集合或子区域的组合。像区域一样，可以添加新的组，或更新或删除现有的组。

  • 子区域：子区域可以定义为区域内的导航链接，定义了点击时在 CRM 的主面板中加载的内容。子区域可以指向仪表板、实体、URL 或 Web 资源。像区域和组一样，可以添加新的子区域，或更新或删除现有的子区域。

参考我们的销售应用界面：

  • 销售、营销、设置和培训被称为区域。

  • 我的工作、客户、销售、资料、营销、目标和工具是销售区域内的组。

  • 仪表板、最新动态和活动是“我的工作”组中的子区域。

销售区域将具有特定于销售的子区域，这些子区域被安排在称为组的区域内。同样，营销、设置和培训区域将有相应的子区域，放置在相应的组内。如以下截图所示，营销区域包含仪表板、活动、账户、联系人、潜在客户、营销列表、活动、快速活动等。它还包括与营销模块相关的子区域。这些子区域被安排在“我的工作”、“客户”、“营销”、“资料”和“工具”组内：

现在，既然我们已经了解了网站地图组件的概况，让我们在下一节中查看这些组件的不同属性。

了解区域、组和子区域的属性

在开始自定义我们的销售应用导航之前，让我们先看看这些组件的不同属性。

  • 区域组件包含以下属性：

  • 组组件与区域组件共享大多数相同的属性：

将组设置为配置文件属性可能与 Dynamics 365 不相关，因为工作区区域从 CRM 2013 开始已被停用。

与区域和组相比，子区域有更多的属性：

  • 如我们所知，站点地图本质上是一个 XML 文件，通过站点地图设计器进行的任何更改实际上是在后台更新站点地图的 XML：

  • 要获取销售应用站点地图定义，请导出包含销售应用站点地图客户端扩展的解决方案并解压缩它。然后，打开 customizations.xml 文件并搜索 SiteMap 标签。

  • 以下是销售应用站点地图中“我的工作”组的示例 XML。我们可以看到 Area、Group 和 SubArea 标签及其对应的属性：

  • 如前所述，除了使用站点地图设计器，我们还可以使用任何文本编辑器手动更新站点地图的 XML，并可以将解决方案导入回去（并发布）以查看更改。

站点地图 XML 参考：msdn.microsoft.com/en-us/library/gg334430.aspx.

在本节中，我们查看了站点地图设计器的区域、组和子区域组件的属性。在下一节中，我们将学习如何通过站点地图设计器执行一些基本操作，如更新、添加、删除等。

使用站点地图设计器的常见操作

现在，我们已经详细了解了站点地图组件的所有属性，让我们看看如何使用站点地图设计器执行一些常见操作。

编辑站点地图中的现有组件

要编辑站点地图中的现有区域、组和子区域，我们需要在设计器中选择该组件，并转到该组件的属性标签。让我们通过一个简单的例子来理解这一点。假设我们想将现有的“培训”区域重命名为“帮助”，我们需要在站点地图中选择“培训”区域，转到其属性标签并更新其标题属性。

让我们将“帮助”指定为标题属性的值。这将把区域的标题从“培训”更新为 Help，如下所示：

我们还可以通过内联编辑更新站点地图组件的标题属性。为此，将鼠标悬停在组件上以显示铅笔图标。我们可以点击铅笔图标来编辑标题。同样，我们也可以编辑或更新组和子区域组件的相应属性，正如我们之前提到的，设计器中所做的任何更改都会反映在站点地图的 XML 中。

向站点地图添加组件

要向站点地图添加区域、组或子区域，我们需要点击站点地图设计器操作栏上的“添加”按钮。让我们在这里添加一个区域来理解这个过程。点击“添加”按钮并选择区域：

或者，从“组件”标签中拖放区域。

添加后，我们需要选择组件（此处为区域），然后在“属性”标签中编辑其属性。例如，下面的图片显示了新添加的区域组件的“属性”标签：

这将会在站点地图中添加一个名为“新区域”的新区域。

同样，我们也可以在导航中添加或拖放新的组和子区域组件，并指定它们的属性。

剪切、复制和粘贴组件到站点地图

通过站点地图设计器，我们还可以剪切、复制和粘贴站点地图组件。让我们选择我们的新区域，并点击操作栏上的剪切按钮以剪切该组件。该组件将变灰。

同样，我们可以选择该组件并点击复制按钮来复制该组件。粘贴按钮可以让我们选择将组件粘贴到右侧或左侧，针对区域和组组件，如下所示：

将组件克隆到站点地图

要克隆或复制现有的区域、组和子区域到站点地图，我们可以选择该组件并点击站点地图设计器操作栏上的克隆按钮。克隆后，将会在下一个克隆的组件旁添加相应的组件，并且该组件的标题后会加上“-Copy”后缀。例如，克隆“销售区域”，如下面的图片所示，将在克隆的销售区域旁添加一个名为“Sales-Copy”的新区域：

从站点地图中删除组件

要从站点地图中删除一个区域、组或子区域，选择该组件，然后点击操作栏上的删除按钮，或者按“删除”键：

删除一个区域也将删除其中的组和子区域。同样，删除组将删除其中的子区域。

在站点地图中组织组件

使用拖放功能，我们可以在重新排列站点地图之前，移动站点地图中的组件：

例如，我们可以将销售区域移到站点地图中的最后一个区域，将我的工作设置为销售区域内的第二个组，将仪表盘设置为我的工作组中的最后一个子区域，依此类推，具体如下所示：

我们还可以将一个子区域移到不同的组中。例如，仪表盘子区域可以移动到其他任何组，如客户、销售、辅助资料等，甚至将一个组移到不同的区域。也就是说，我们可以将我的工作组移到设置、培训和销售区域中。

在站点地图中保存、验证和发布更改

要反映前述任何更改（如添加、克隆、删除等），我们需要点击“保存”，然后在站点地图设计器画布中发布它。此时，*草稿表示有未保存的更改。

保存更改并点击“发布”后，它会变为“已发布”，表示更改已应用并且用户可以查看：

点击“保存”按钮也会验证站点地图，并在有任何错误时显示出来。例如，如果我们没有为任何必填字段提供值，或为某些属性指定了不允许的字符。在下方截图中，我们没有为子区域的实体属性提供值，并点击了“保存”，这是一个必填字段：

这将显示设计器中的错误信息通知，并附有所有详细信息。我们只有在修复错误后，才能保存并发布更改。

在站点地图中添加子区域组件

让我们以一个简单的场景来理解如何添加新的子区域组件。我们意识到，销售应用程序的用户会频繁访问 CRM 中的“开放潜在客户视图”，因此如果我们能够在销售区域的“我的工作”组中为他们添加一个“开放潜在客户视图”子区域，将会很有帮助。为了实现这一点，我们需要在“我的工作”组中添加一个新的类型为 URL 的子区域。为此，我们需要在站点地图设计器中的操作栏中点击“添加”，然后添加一个新的子区域，并将其拖动并放置到“我的工作”组中的活动子区域下面：

这里，视图的 URL 模式需要如下：

=/_root/homepage.aspx?etc=<entity code >&viewid=%7b<GUID value of view id>%7d"

对于 etc 和 viewid 查询参数，我们需要进入 CRM 中的“开放潜在客户视图”，然后点击“电子邮件链接 | 当前视图”功能区按钮，以获取链接：

链接将包含 etc 和 viewid 的值。我们将复制链接中 etc 和 viewid 查询字符串参数的值。然后，我们可以设置我们新子区域的属性，如下所示：

我们将保存并发布它。发布后，用户将在销售应用程序中看到名为“开放潜在客户”的新子区域：

点击“开放潜在客户”子区域将打开如下所示的“开放潜在客户”视图：

在站点地图中隐藏子区域组件

正如我们之前看到的，子区域组件有一个权限属性。它定义了是否根据用户通过安全角色分配的权限来显示或隐藏该子区域。让我们通过一个示例来理解这一点。假设我们只希望那些对潜在客户实体具有创建权限的用户能看到我们刚刚添加的“开放潜在客户”子区域。要定义这一点，让我们返回站点地图设计器中“开放潜在客户”子区域的“属性”选项卡。在那里，我们需要进入“高级”部分中的“权限”。在实体下拉菜单中，我们可以选择“潜在客户”实体，并点击“+”按钮来添加记录。我们将不勾选任何复选框，除了“创建”：

保存并发布更改。现在，让我们以只分配了销售人员安全角色的用户身份登录。在这里，我们已经更新了安全角色，并为潜在客户实体的“创建”权限设置为“无”；即我们在以下截图中看到的第一个选项：

没有“创建”权限的用户将无法在他们的站点地图中看到“开放潜在客户”子区域。

从站点地图向 URL 传递参数

正如我们之前看到的，子区域组件有一个“参数传递”复选框属性。它指定是否将组织和语言上下文的信息传递到 URL。该属性仅适用于类型为网页资源或 URL 的子区域。假设我们在子区域的 URL 属性中定义了以下 URL：

http://mydomain/mypage.aspx。

选中“参数传递”复选框将传递以下参数：

http://mydomain/mypage.aspx/?orglcid=1033&orgname=org29d341dd&userlcid=1033。

  • orglcid：组织的基础语言的语言代码标识符

  • orgname：组织的唯一名称

  • userlcid：当前用户使用的语言代码标识符

这些信息可用于创建支持多语言的解决方案。

创建支持多语言的解决方案的详细信息请参见msdn.microsoft.com/en-us/library/hh670609.aspx#Anchor_0。

编辑站点地图并支持客户

让我们简要地看看除了站点地图设计器外，还可以通过其他方式编辑站点地图，以及客户在 Dynamics 365 中支持不同类型站点地图的方式。

站点地图编辑器

站点地图，正如我们所知道的，是一个 XML 文件。任何 XML 文本编辑器都足够用来编辑站点地图 XML 文件。为此，我们可以导出包含站点地图 XML 的非托管解决方案，在记事本、Visual Studio 或任何其他 XML 编辑器中编辑它，然后再导入回来。这里需要记住的重要一点是，如果我们作为托管解决方案导入站点地图，它将创建一个新的站点地图记录，并包含所有最新的更改；而在非托管情况下，现有的站点地图 XML 会被覆盖。

编辑带有模式验证的站点地图 XML 的详细信息请参考 msdn.microsoft.com/en-us/library/gg334493(v=crm.8).aspx。

除了站点地图设计器外，我们还可以使用第三方站点地图编辑器来编辑站点地图。其中一个最受欢迎的工具是包含在 XRM 工具箱中的站点地图编辑器。这是我们的销售应用站点地图如何在站点地图编辑器中加载的：

与手动编辑 XML 相比，这个工具使得编辑站点地图变得更加容易。这个工具自 CRM 2011 以来一直是编辑站点地图最受欢迎的工具之一，并且最近更新以支持在 Dynamics 365 中可用的多个站点地图。另一种选择是通过编程更新站点地图。为此，我们可以使用站点地图实体，并更新其 sitemapxml 属性，如下所示：

  • 创建站点地图实体的对象：
Entity siteMap = new Entity["sitemap"];
  • 使用有效的 XML 更新其 sitemapxml 属性：
siteMap["sitemapxml"] = "valid site map xml";
  • 使用组织服务实例更新实体：
service.Update(siteMap);
  • 使用 PublishXmlRequest 类发布更改：
PublishXmlRequest request = new PublishXmlRequest();
 request.ParameterXml = "<importexportxml><sitemaps><sitemap></sitemap></sitemaps></importexportxml>";
 service.Execute(request);

我们还可以通过编程创建和删除特定于应用的站点地图记录。然而，建议你使用站点地图设计器，而不是通过编程进行操作。另一个需要注意的点是，默认的站点地图记录无法创建或删除。

强烈建议我们在开始编辑之前导出现有的站点地图 XML 文件并保存一份副本，这样如果在编辑过程中发生错误，可以帮助我们恢复。

支持的客户端

默认站点地图，即用于 Dynamics 365 的站点地图 – 自定义应用，支持 Dynamics 365 Web 应用程序和 Dynamics 365 for Outlook。任何新的自定义应用程序的站点地图，或如销售、客户服务、现场服务和项目服务自动化等业务应用，只能通过 Dynamics 365 Web 应用程序进行支持。

摘要

在这一章中，我们了解了站点地图在 Dynamics 365 中的发展。现在，每个应用程序可以有多个站点地图，并且产品中内置的站点地图设计工具也可以使用。我们还详细了解了新的站点地图设计器以及可以通过它执行的一些常见操作。在下一章中，我们将介绍新的可视化流程设计器，以及如何使用它通过直观的拖放功能创建业务流程流。

第二章：使用应用模块设计器设计应用程序

应用程序是 Dynamics 365 或 Dynamics CRM 9.x 版本中引入的新功能。在 Dynamics CRM 的后续版本之前，无法创建针对任何模块的自定义应用程序。曾经存在一个单一层次的站点地图，为整个组织提供了各种实体、仪表板等的链接。然而，随着 Microsoft Dynamics 365 的推出，微软引入了应用程序的概念，这些应用程序可以针对特定的业务领域或模块。同时，我们还可以在产品本身中使用内置的应用程序设计器。该设计器允许管理员、自定义人员或具有适当权限的用户，通过简单地添加、拖动和放置组件，在应用程序设计器画布内轻松设计应用程序。

本章将涵盖以下内容：

  • Dynamics 365 中应用程序概述

  • 配置应用程序所需的前提权限

  • 配置 Dynamics 365 应用程序

  • 了解应用程序属性

  • 了解应用程序设计器界面

  • 添加和移除组件、验证、发布和保护应用程序

  • 导出和导入应用程序

Dynamics 365 中应用程序概述

应用程序是 Dynamics 365 中新增的功能，旨在为用户提供快速导航，以便他们能快速访问最相关的实体等内容。应用程序非常方便，每个应用程序都有自己的站点地图。关于在 Dynamics 365 中设计站点地图的详细信息，将在第一章中讨论，自定义应用程序导航。简而言之，站点地图是存储导航链接的组件，并且在 Dynamics 365 中以 XML 格式存储。应用程序可以包含以下组件：

  • 实体

  • 仪表板

  • 表单

  • 视图

  • 图表

  • 商业流程

配置应用程序所需的权限

在我们开始讨论配置 Dynamics 365 中应用程序所需的步骤之前，了解特定用户所需的前提安全权限是非常重要的，这样他们才能访问配置应用程序的功能。如果你希望授予一个高级用户或最终用户设计和使用自己应用程序的能力，这一点尤其重要。以下表格总结了配置 Dynamics 365 应用程序所需的最低权限：

序号 实体名称 读取 写入 创建
1. 应用程序 是 是 是
2. 解决方案 是 - -
3. 自定义 是 是 -

这里详细介绍了通过 CRM 屏幕查看安全角色区域的内容：

  1. 在 Dynamics 365 的自定义选项卡下，应配置应用程序的安全角色：读取、写入和创建权限。请参阅以下截图：

  1. 在 Dynamics 365 的自定义选项卡下，应配置安全角色：自定义的读取和写入权限。请参阅以下截图：

  1. 在 Dynamics 365 的“自定义”选项卡下，应配置安全角色：自定义的读取和写入权限。请参阅以下截图：

注意：系统管理员和系统定制者角色已经具备配置 Dynamics 365 应用程序的必要权限。如果需要其他安全角色（非上述角色）访问配置 Dynamics 365 应用程序，必须配置前述的安全权限。

配置 Dynamics 365 应用程序

在本部分中，我们将了解配置 Dynamics 365 应用程序所需的各个步骤。下图概述了配置 Dynamics 365 应用程序所需的步骤：

以下是每个步骤的描述：

  1. 配置应用程序属性： 应用程序属性，如名称、唯一名称、图标等，需要作为配置应用程序的起点进行配置。下一部分将给出详细描述。

  2. 使用站点地图设计器配置应用程序导航： 每个应用程序可以有自己的站点地图。详细描述请参阅第一章，自定义应用程序导航。

  3. 包含所需的应用组件： 应用组件可以包括必须包含在应用中的工件或实体资产。

  4. 检查应用程序是否缺少任何必需的组件： 需要检查应用程序是否缺少任何必需的组件。这可以通过在发布应用程序之前点击“验证”来完成。

  5. 通过发布使应用程序可供使用： 要让用户能够访问该应用程序，必须发布该应用程序。详细描述请参阅以下部分。

  6. 为应用程序配置安全角色访问权限： 可以通过安全设置限制应用程序的访问权限，确保只有特定的用户可以访问应用程序。详细描述请参阅以下部分。

了解应用程序属性和设计器界面

在配置应用程序之前，应用程序具有一些特定的属性，我们需要了解这些属性。配置应用程序之前需要提供以下属性。以下表格总结了这些属性：

序号 属性名称 属性描述
1. 名称 需要提供此属性以为应用程序指定唯一名称。
2. 唯一名称 唯一名称会根据名称属性自动填充。它包含一个前缀，前缀从发布者的前缀中获取。唯一名称的唯一部分可以更改（前缀不能更改，因为它是从解决方案的发布者中获取的）。唯一名称只能包含英文字母或数字。
3. 描述 此属性包含对应用程序旨在实现的目标的简短描述。注意：建议您使用此属性提供有意义的应用程序描述，因为这将是持续的 CRM 自定义和维护的有用信息。
4. 图标 此属性的默认设置是使用默认应用缩略图，已选中。如果你希望为应用图标使用不同的 Web 资源，请取消选中此复选框，并指定 Web 资源作为应用图标。此图标将在应用的预览磁贴中显示。

| 5. | 客户端类型 | 此属性允许你选择应用的客户端类型行为。它可以是以下之一：

  • Web： 这是 Dynamics 365 的经典 Web 浏览器客户端界面。

  • 统一界面：这是全新的改进版 Dynamics 365 Web 浏览器客户端界面，PC 和移动设备上的外观和体验相似。

|

| 6. | 应用 URL 后缀 | 应用 URL 属性会根据指定的应用名称自动填充。应用 URL 需要唯一。格式如下：

  • 本地部署： http://<server>/<org name>/Apps/<App URL>

  • 在线部署： https://<server>. crm#.dynamics.com/Apps/<App URL>

注意： 如果清除该选项，系统会自动生成一个带有应用 ID 的应用 URL。

7. 使用现有解决方案创建应用 此属性可以用于从已安装的解决方案列表中创建应用。当选择此选项时，顶部的完成按钮将变为下一步。选择下一步后，你可以选择可用的解决方案。如果解决方案中配置了任何站点地图，它也会可供选择。选择了解决方案，必要时选择站点地图（如果它是解决方案的一部分），然后点击完成。解决方案或站点地图中存在的组件会自动添加到应用中。
8. 选择欢迎页面 此属性允许你选择一个 Web 资源，配置为应用的欢迎页面。这是一个有用的属性，可以配置有助于用户使用应用的链接，或者视频/升级说明链接等。此链接在用户打开应用时总是会在欢迎页面上显示。用户以后可以选择“下次不显示此欢迎页面”来禁用该页面，之后再次打开应用时该页面将不会显示。

了解应用程序设计器的界面并将组件添加到应用中

现在我们已经了解了上一节中的应用程序属性，是时候使用 Dynamics 365 应用程序设计器配置我们的第一个 Dynamics 365 应用，并了解其界面。可以通过以下步骤创建一个 Dynamics 365 应用：

  1. 导航到“设置” | “我的应用”，如下图所示：

  1. 在我的应用屏幕上，你将能够看到已经配置好的内置应用列表，或者你所在组织中已配置的任何其他自定义应用：

  1. 在我的应用屏幕上，点击右上角的创建新应用按钮，如下图所示：

另外，你也可以选择在“我的应用”屏幕底部的“创建新应用”图块，在“正在编辑的应用”选项下：

  1. 下一屏幕将展示应用设计器屏幕，包含我们在上一部分中描述的所有应用属性：

这张图片展示了应用设计器屏幕

  1. 为应用选择一个有意义的名称。在我们的例子中，我们正在创建一个用于快速生成潜在客户的应用，因此我们将应用命名为潜在客户生成。注意，唯一名称、应用 URL 后缀和 Web URL 属性是自动生成的：

这张图片展示了潜在客户生成

注意： 在此步骤中，我们保持应用的默认属性。你可能希望覆盖这些自动生成的属性。

  1. 提供应用的有意义描述（URL 应该是唯一的）：

同时，我们将保持客户端类型为 Web（经典 CRM Web 界面）。

  1. 若要为应用选择不同的图标，请取消勾选“使用默认图片”复选框，然后选择你希望用作应用图标的 Web 资源：

我们将为这个特定应用选择经典 CRM 图标。注意，在选择图标后，你可以在右侧的应用图块预览区域看到应用图块的预览：

  1. 可选地，你可以选择使用现有的解决方案来创建应用，并为应用选择一个欢迎页面。我们将跳过第一个 Dynamics 365 应用的设置，并点击右上角的完成按钮：

  1. 点击完成后，应用设计器将跳转到选择不同组件的屏幕。

一个应用可以由两种不同类型的组件组成，如下表所述：

序号 组件名称 组件内容
1 工件 实体、仪表板和业务流程
2 实体资产 表单、视图、图表等

现在让我们来了解一下应用设计器的布局。应用设计器分为两个不同的区域：

  • 画布：在应用设计器的左侧，你会看到一个画布区域，在这里你可以添加应用组件。以下截图展示了画布区域的示例：

  • 组件属性：在应用设计器的右侧，你将看到一个区域，你可以在这里选择各种组件及其属性。以下截图展示了组件及其属性区域的示例：

请注意，这里还提到了不同组件的分类，组件区域将组件分为两大类：ARTIFACTS 和 ENTITY ASSETS。在 App Designer 的画布上，如果选择了仪表板或业务流程，仪表板或业务流程下的所有实体会自动被 App Designer 选择。然后，您只需选择适当的实体资产，例如视图、表单和图表。

在我们的“潜在客户生成”应用中，由于未选择站点地图，站点地图区域将显示“配置缺失”：

  1. 点击箭头图标后，在 App Designer 的画布区域中的站点地图区域，您将看到站点地图设计器。如以下截图所示，站点地图设计器将在第一章，自定义应用程序导航中详细讨论：

在以下站点地图编辑器屏幕上点击“保存并关闭”。

注意：有关网站地图和网站地图设计器的详细信息，请参见第一章，自定义应用程序导航。

  1. 请注意，作为所选站点地图的一部分的“潜在客户”实体，已经在 App Designer 的 Entity View 中可用。类似地，所选站点地图上的所有组件都会自动出现在 App Designer 中：

  1. 默认选择 ENTITY ASSETS 时，所选实体的所有表单和视图将显示在 Entity View 下。我们来更改视图。点击视图选择旁的“全部”，选择您希望在此应用程序中使用的视图。此处，仅选择了“所有潜在客户”和“已关闭的潜在客户”视图：

您还可以选择类似的表单和图表，并在屏幕右上角点击“保存”。

  1. 接下来，我们来看看屏幕的工件部分。这里，您可以看到提供了站点地图、仪表板和业务流程，默认选择了“全部”：

  1. 我们可以选择业务流程图块，点击显示“全部”的区域。完成后，您将看到选择当前应用程序中可用的业务流程的选项。由于这是“潜在客户生成”应用程序，因此我们仅选择了在现成的 Dynamics 365 中可用的“从潜在客户到机会销售”业务流程：

  1. 一旦选择了特定的业务流程，App Designer 会自动选择该流程下的所有实体：

  1. 接下来点击“保存”。然后点击右上角的“验证”按钮：

  1. 在验证后，您可能会偶尔收到警告或错误，如下所示：

  1. 在我们的例子中，这些只是潜在警告。因此，我们可以跳过它们；但是错误警告是无法跳过的。我们可以通过点击“发布”来发布我们的应用。这将成功发布应用：

使用自定义应用

在上一部分，我们发布了一个名为潜在客户生成的新自定义应用。在本部分中，我们将尝试使用我们新创建的自定义应用。请按照以下步骤使用您新创建的自定义应用：

  1. 展开“Dynamics 365”区域，您应该能够找到新发布的潜在客户生成的 Dynamics 365 应用：

注意： 安全性考虑将在本章的下一部分进行讲解。由于当前用户是系统管理员角色，因此可以访问该应用。

或者，用户也可以导航到设置 | 我的应用并在已发布应用列表中查看该应用：

  1. 请注意，现在新应用已启动，网站地图中的导航选项显示了我们之前配置的站点地图：

  1. 此外，如实体资产配置中所选，潜在客户中仅提供两个视图供使用：

保护应用

在实际场景中，通常需要仅将特定应用访问权限授予某一特定用户组。对于这一需求，我们可以将应用保护为仅通过特定安全角色访问。

我们现在希望编辑潜在客户生成应用的安全权限，使其仅对销售经理和销售人员安全角色可用。我们可以通过仅为某些安全角色启用应用访问权限来实现这一点。请按照以下步骤仅为某些安全角色启用应用访问权限：

  1. 导航到设置 | 我的应用，并在潜在客户生成应用下选择更多选项：

  1. 选择“管理角色”选项。这将在屏幕右侧启动“管理角色”窗口，在此窗口中可以选择不同的安全角色。选择适当的角色并点击“保存”：

注意： 系统管理员和系统自定义角色默认对所有应用具有完全访问权限。建议您保持此设置，因为这些安全角色未来需要维护或自定义应用。

现在，潜在客户生成应用仅对销售经理和销售人员角色以及系统管理员和系统自定义角色可用。

编辑现有应用

如果我们希望编辑应用中任何工件或实体资产组件的布局或自定义设置，我们可以通过以下步骤来实现：

  1. 导航到设置 | 我的应用，并在潜在客户生成应用下选择更多选项：

  1. 选择“在应用设计器中打开”选项。此操作将启动该应用的应用设计器窗口：

现在，可以根据需要编辑“Lead Generation”应用并保存。然后，需要重新验证并发布以便将更改反映给用户。

导入和导出应用

应用可以作为 CRM 解决方案组件从一个环境打包到另一个环境。要导出“Lead Generation”应用，请按照以下步骤操作：

  1. 导航到设置 | 解决方案并创建一个名为“Lead Generation”的新解决方案。你也可以选择打开正在使用的现有解决方案。在左侧，注意到有“应用”选项：

  1. 接下来，选择“添加现有应用”按钮：

  1. 选择“Lead Generation”应用并点击确定：

  1. 如果你没有包含为该应用创建的自定义站点地图，系统将提示你包含所需组件。选择“是，包含所需组件”选项并点击确定：

  1. “Lead Generation”应用现在已添加到 CRM 解决方案中。现在可以将其作为 CRM 解决方案 ZIP 文件导出，并导入到任何其他环境中。

删除应用

有时，一个应用在 Dynamics 365 实例中不再需要，你可能想要删除该应用。按照以下步骤在 Dynamics 365 中删除一个应用：

  1. 导航到包含应用的解决方案。在我们的例子中，我们为此目的创建了一个“Lead Generation”解决方案。导航到设置 | 解决方案下的“自定义”区域，并打开“Lead Generation”解决方案。点击左侧屏幕上可用的解决方案组件中的“应用”选项：

  1. 选择“Lead Generation”应用并点击删除按钮：

  1. 系统将提示你确认删除。点击删除：

注意：建议你同时删除为该应用在 CRM 实例中创建的站点地图，否则将来如果创建一个名称相似的应用，可能会导致问题。

  1. 该应用现在已从 CRM 系统中移除。

应用设计器的浏览器和操作系统支持

应用设计器可以在以下操作系统和浏览器组合中使用：

  • Windows 10 上的 Microsoft Edge

  • Windows 10 或 Windows 8.1 上的 Internet Explorer 11

  • Windows 8.1 上的 Internet Explorer 11 现代版

  • Windows 8 上的 Internet Explorer 10

  • Windows 8 上的 Internet Explorer 10 现代版

  • Windows 8、Windows 8.1 或 Windows 10 上的 Mozilla Firefox

  • Windows 8、Windows 8.1 或 Windows 10 上的 Google Chrome

  • Apple Safari 在 MAC OS X 上

总结

在本章中，我们了解了应用程序是如何作为一个新的强大导航功能引入到 Dynamics 365 中的。我们还理解了应用程序如何为用户提供快速访问他们日常 CRM 工作所需的最相关选项。现在，我们可以为每个应用程序拥有多个站点地图，并且产品本身内置了应用设计器工具。我们还详细了解了新的应用设计器以及可以通过它执行的一些常见操作。

在下一章，我们将介绍新的站点地图设计器，以及如何利用它的直观拖放功能来创建站点地图。

第三章：使用可视化流程设计器定义流程

Microsoft Dynamics 365 版本引入了一个新的编辑器，用于设计业务流程流，采用了改进的业务流程流设计器。通过业务流程流编辑器，系统管理员或系统定制员可以使用丰富的图形编辑器创建、编辑和配置业务流程流。业务流程流编辑器使组织能够提高用户生产力，并减少执行日常 CRM 活动所需的时间。

在本章中，我们将涵盖以下内容：

  • 业务流程流概述

  • 业务流程流所需的前提权限

  • 业务流程流的基本组件

  • 业务流程流设计器概述

  • 创建和编辑业务流程流

  • 任务流概述

  • 任务流的基本组件

业务流程流概述

业务流程流提供了客户业务阶段的洞察，并允许管理在每个阶段需要捕捉的字段。它还帮助根据需要捕捉的字段限制在不同阶段之间的移动。最终用户会发现它更为方便，因为它简单易用，并通过业务流程流提供了对业务的直观理解。

业务流程流是 Dynamics 365 最终用户的引导性流程。它帮助引导 CRM 最终用户。

它易于可视化，并作为实体表单的可视元素出现。它由不同的指令阶段组成，帮助最终用户在系统中遵循业务流程，而无需详细的培训。

从最终用户的角度来看，业务流程流有两个基本组件：

  • 第一个组件是阶段，它包括给用户的具体指示，以遵循该流程

  • 第二个组件是步骤，它代表在特定阶段由最终用户填写的字段

一个阶段可以包含多个步骤。

Dynamics 365 业务流程流确保最终用户一致地输入数据，并在每次处理特定实体或实体集时遵循相同的步骤。

业务流程流帮助最终用户以标准方式完成工作，遵循逐步流程，在每个业务阶段填写应填的字段。简而言之，业务流程流作为最终用户的基本指南，提供特定流程以捕捉字段。

您可以添加与常见销售和服务方法相关的业务阶段，通过业务流程流进行映射。

理解业务流程流用户界面

以下图像概述了 Dynamics 365 中可用的业务流程流：

业务流程流包含不同的组件，这些组件在定制过程中是必需的；它包括以下主要组件：

  1. 阶段：

阶段就像在业务流程流顶部给出的引导标签，用于指定该做什么：

  1. 步骤：

步骤是为在阶段中使用的实体创建的字段：

  1. 阶段门控、设置为激活、下一步、完成：

在业务流程图的右下角，此选项帮助您进入下一阶段或完成该过程：

  1. 工作流：

工作流是一种用于在 CRM 中触发特定消息的过程。业务流程图具有新功能，可以在不同阶段进行时触发工作流。

  1. 条件：

业务流程图支持条件分支；条件用于业务流程图中。这些条件允许在业务流程图中添加 if...else 逻辑，以便根据不同的字段值移动到不同的阶段。

创建业务流程图所需的前提条件和安全角色

在我们开始讨论在 Dynamics 365 中创建业务流程图所需的步骤之前，了解用户在能够创建和编辑业务流程图之前所需的前提安全权限是非常重要的。如果您希望为用户或最终用户提供设计和使用自己业务流程图的能力，这一点尤为重要。以下表格总结了在 Dynamics 365 中创建、配置和激活业务流程图所需的最低权限：

序号 实体名称 读取 写入 创建
1. 过程 是 是 是
2. 解决方案 是 - -
3. 自定义 是 是 -

解决方案和自定义编辑权限是必需的，因为从特定解决方案创建和编辑流程是最佳实践。

在此提供通过 CRM 屏幕查看安全角色区域的详细信息：

  1. 在 Dynamics 365 安全角色的自定义选项卡下，过程的读取、写入和创建权限应按如下所示进行配置：

此外，您还需要杂项权限才能激活该过程：

  1. 在 Dynamics 365 安全角色的自定义选项卡下，应按如下所示配置自定义的读取和写入权限：

  1. 在 Dynamics 365 安全角色的自定义选项卡下，应按如下所示配置自定义的读取和写入权限：

注意：系统管理员和系统定制者角色已经具备配置 Dynamics 365 业务流程图所需的权限。如果某些除上述角色外的安全角色需要创建或编辑 Dynamics 365 业务流程图，则需要配置先前的安全权限。

要在自定义实体上启用业务流程，需要进行少量自定义。需要在实体配置中选中业务流程复选框。下图列出了支持业务流程的开箱即用实体组：

客户 信函 联系人 报价
约会 营销列表 电子邮件 循环约会
活动 商机 权益 销售文献
活动活动 电话 传真 社交活动
活动响应 产品 案例 订单
竞争者 价格表项 发票 用户
团队 负责人 任务 -

业务流程设计器概述

现在我们已经熟悉了业务流程的基础知识，是时候探索新的业务流程编辑器了。以下图像详细显示了新改进的编辑器中提供的不同组件。图像后的文本概述了业务流程设计器中可用的各种组件：

在业务流程设计器中，可以看到以下组件：

  1. 画布上的组件：当创建新的业务流程时，默认会创建此阶段。自定义人员可以向画布上添加更多组件并使用它。

  2. 添加组件按钮：要在设计器画布上添加组件，点击添加按钮并选择您要添加组件的位置。

  3. 删除按钮：要从设计器画布中删除组件，请选择该组件并使用删除选项。

  4. 截图按钮：此选项允许您截取在画布上设计的业务流程的屏幕截图，用于文档记录。

  5. 连接器按钮：当需要条件分支时，此选项非常有用，用于连接不同的组件。

  6. 保存，验证，另存为，启用：

    • 保存：用于保存当前设计的业务流程

    • 验证：用于验证流程并查找业务流程中的错误

    • 另存为：用于以不同的名称保存业务流程

    • 启用：启用业务流程

  7. 订单流程：此选项允许您在业务流程中添加序列号。如果某个实体有多个业务流程，则此选项允许您选择哪个业务流程优先向用户提供。

  8. 添加组件和属性：此选项也可以用于向画布上添加组件。属性标签允许您设置组件的属性：

1. 迷你地图：迷你地图对于导航整个流程或部分流程非常有用。

2. 全局工作流：在业务流程中使用的全局工作流在此列出或添加。

注意： 编辑安全角色按钮可用于启用特定业务流程的不同安全角色。

创建业务流程

在了解业务流程之后，以下步骤将解释如何创建业务流程。由于用户界面友好，它非常简单：

  1. 转到设置 | 流程：

  1. 在操作工具栏上，点击“新建”：

  1. 创建流程对话框将出现在屏幕上。接下来，按照这些规格完成所需的字段：

1. 输入业务流程的名称。在本示例中，我们将创建一个“电话到案件”业务流程示例。

2. 在类别中，指定流程类别，并选择业务流程。

3. 从实体列表中选择实体，以指定你希望创建业务流程的实体。在这里，我们选择案件实体：

  1. 一旦新流程创建完成，业务流程设计器将打开，并且会有一个已经创建的阶段。

  2. 从“组件”选项卡中拖动并放置“阶段”组件，放置到设计区域或画布区域的“+”标志上。

1. 要设置阶段的属性，请点击该阶段，然后在屏幕右侧的属性选项卡中设置属性。

2. 输入所需的显示名称。

3. 如有需要，选择该阶段的类别。

4. 点击“应用”按钮以完成更改：

  1. 要在业务流程中添加更多组件，请点击“组件”：

  1. 向业务流程中添加阶段和步骤：

1. 从组件中选择步骤组件，然后将其拖放到另一个阶段。

2. 选择步骤并点击“属性”选项卡以设置步骤的属性。

3. 添加步骤的显示名称。

4. 从实体中提供的字段列表中选择适当的字段。

5. 选择所需的复选框以使字段为必填项。

6. 要保存并应用更改，请点击“应用”按钮：

  1. 要在业务流程中包含一个分支（条件），请按照以下步骤操作：

1. 从“组件”选项卡中选择“条件”组件，然后将其拖放到画布中。要连接阶段和条件，请将条件组件拖放到两个阶段之间的+标志上。

2. 选择画布上的条件组件，从属性选项卡中设置条件组件的属性，并选择“应用”按钮保存并应用更改：

  1. 要调用工作流到业务流程中，请将工作流组件拖动到相应的阶段或全局工作流：

1. 从组件列表中选择工作流组件，然后将其拖放到某个阶段。

2. 若要为该流程使用全局工作流，请选择工作流组件。将其拖动到全局工作流项上。

3. 要设置工作流的属性，请点击“属性”。

4. 为工作流添加显示名称。

5. 选择工作流触发器并将其设置为Stage Exit。

6. 选择触发器的工作流。

7. 要保存并应用更改，请点击Apply按钮：

  1. 点击操作栏上的Validate按钮，并验证业务流程流：

  1. 要保存，请点击操作栏上的Save按钮：

  1. 要激活该流程，点击操作栏上的Activate按钮：

编辑业务流程流

Dynamics 365 允许你编辑现有的业务流程流。在本节中，我们将编辑之前已创建的业务流程流，并向其中添加一个开箱即用的工作流来发送电子邮件：

  1. 转到设置 | 进程：

  1. 选择你想要编辑的现有业务流程。接下来，点击操作栏上的EDIT按钮：

  1. 业务流程流设计器将会打开。展开业务流程流的第一阶段，选择Add workflow component：

  1. 点击画布上的工作流组件并设置其属性。将触发条件设置为Stage Exit，选择工作流，然后选择Send email workflow。要保存并应用组件上的更改，请点击Apply按钮，如下所示：

注意： 发送电子邮件的工作流是一个预配置的开箱即用工作流，用于通过标准的开箱即用工作流编辑器在案例实体上单独发送电子邮件。

  1. 可选地，要在第一阶段添加新字段，你需要在第一阶段添加一个新的步骤组件，并将属性设置为案例实体中的主题字段：

  1. 要保存更改并更新业务流程流，点击Update按钮并关闭业务流程流设计器：

了解任务流

任务流是业务流程流的一种变体，或者我们简单地说，任务流是移动设备上使用业务流程的另一种方法。任务流与业务流程流有相似之处，但它的功能与业务流程流非常不同。例如，任务流可以在不同的用户设备上同时执行，同一记录上的不同用户可能会得到不同的结果。任务流还可以在移动设备上使数据透明化。

任务流中有不同的功能可供使用：

  • 任务流是基于用户级别的，这意味着每个流程对用户来说都是唯一的

  • 任务流可以由不同的用户在同一记录上使用，这些用户可能会得到不同于其他用户的结果

  • 任务流具有来自多个实体的可编辑控制

  • 在任务流中，条件分支更具灵活性

任务流的组件

请考虑以下几点：

  1. 页面：

在任务流中显示的页面是为了某个目的或显示其上的所有字段。

页面设计是为了适应移动设备，使用设备的整个屏幕，而不是覆盖在实体上。页面只包含字段、标签和章节标签。任务流中至少需要添加一页。

  1. 条件：

任务流条件类似于业务流程流中的条件，用于支持流程中的条件分支。如果在任务流中添加if...else情景会更有帮助。条件用于在页面之间添加条件分支。此条件基于页面内字段的值。

  1. 字段：

实体字段用作任务流字段。

  1. 标签和章节标签：

标签和章节标签有助于在页面上添加文本描述，并为最终用户提供文本指导。

创建任务流

任务流可以通过在 Dynamics 365 中按照以下步骤创建：

  1. 转到设置 | 流程：

  1. 在操作工具栏上，点击新建：

  1. 转到创建流程对话框，选择“将流程作为任务流运行”选项：

  1. 点击确定，任务流设计器将在新窗口中打开，界面类似于业务流程设计器。

  2. 转到屏幕的右侧，拖动组件选项卡从页面中，发布后将其放到画布上：

  1. 要给页面添加名称，请点击属性选项卡中的页面，输入新名称，然后点击应用按钮：

  1. 要向任务流添加分支，请从组件选项卡中拖动条件组件，并将其放到适当位置的+符号上：

  1. 要设置条件的属性，请点击条件，然后在属性选项卡中设置属性：

1. 选择源实体

2. 选择需要在条件中检查的实体字段

3. 选择操作符和要比较的值

4. 然后点击应用按钮以保存更改：

  1. 如果要向页面添加字段、标签或章节标签，请将其从组件选项卡拖到相应的页面：

  1. 要更改这些项目的属性，请点击项目，在属性选项卡中设置项目属性，然后点击应用按钮。在我们的示例中，我们在第一页添加客户和联系人字段，并添加一个标签，“客户信息”。这适用于第二页，添加服务级别字段：

  1. 点击操作栏上的验证按钮，以验证任务流：

  1. 点击屏幕顶部的保存，将过程保存为草稿（只要过程是草稿，最终用户将无法使用它）：

  1. 要激活任务流，请点击激活：

  1. 要检查任务流的工作情况，请打开 Dynamics 365 移动应用并使用您的凭证登录：

总结

在本章中，我们了解了 Dynamics 365 中如何引入业务流程流增强功能。我们还详细看了新的业务流程流设计器，并了解了通过它可以执行的一些常见操作。

我们还查看了任务流和任务流设计器，它们可以为 Dynamics 365 的移动应用用户提供更加优化的不同业务阶段任务体验。

在下一章，我们将介绍新的业务规则设计器，以及它如何通过直观的拖放功能来创建业务规则。

第四章：使用业务规则设计器定义业务规则

在上一章中，我们了解了如何使用新的可视化流程设计器通过拖放功能创建业务流程图。在本章中，我们将看到如何使用相同的可视化拖放流程设计器创建业务规则。业务规则首次在 Dynamics CRM 2013 中引入。基本上，业务规则允许我们定义规则，例如设置字段为必填/非必填、显示/隐藏字段、锁定/解锁字段等——也就是说，使用直观的界面轻松定义 CRM 表单/实体上的条件和操作，而之前我们需要编写 JavaScript 或开发插件才能实现。后续版本的 Dynamics CRM 进一步增强了业务规则。随着 Dynamics 365 的发布，业务规则设计器的界面得到了彻底改造，具备了拖放组件的能力，并新增了小地图、快照等功能。

在本章中，我们将涵盖以下内容：

  • Dynamics 365 中业务规则概览

  • 了解新业务规则设计器中的不同组件及其使用方法

  • 在 Dynamics 365 中实施新的推荐操作

  • 业务规则设计器的其他功能

业务规则的发展

如前所述，业务规则首次在 CRM 2013 中引入。它提供了一个简单的声明性界面，系统自定义员、开发者或高级用户可以轻松创建验证和业务规则，而无需编写一行代码。业务规则界面由一组条件组成，满足这些条件时要执行的操作，以及作为约定的描述，以便理解业务规则的作用。

在 CRM 2015 中，许多 CRM 2013 的限制得到了改善。CRM 2013 中的业务规则仅限于在客户端运行。对于服务器端，仍然需要编写插件或其他自定义代码。这一问题在 CRM 2015 中得到了改善，新增了名为“实体范围”的选项。具有实体范围的业务规则将在客户端和服务器端都运行。

对于实体范围，如果规则是在表单中触发的，无论是在创建还是更新记录时，规则将首先在客户端运行，然后再在服务器端运行。因此，如果一个规则包含像“将销售金额设置为销售金额 + 10”这样的操作，就会导致规则验证失败，因为它会创建一个循环引用。

CRM 2015 中业务规则的第二大更新是支持 if...else 条件，并且可以使用 AND/OR 逻辑在条件中组合多个表达式。在 CRM 2013 中，要定义一个包含 else 条件的简单规则，我们必须编写两个业务规则。

在业务规则中，条件中的表达式只能使用 AND 条件或 OR 条件组合，但不能同时使用两者。

例如，在联系人表单中，如果“婚姻状况”字段的值为“已婚”，则将“配偶/伴侣姓名”字段设置为“业务必填”，否则将其设置为“无”。在这里，我们将只需编写一个业务规则，而不是过去需要编写两个业务规则，一个用于设置字段为业务必填，另一个用于将其设置为“无”，这得益于 CRM 2015 以来支持的if...else语句。

CRM 2015 的另一个更新是添加了名为“设置默认值”的新操作，用于设置字段的默认值。

CRM 2013 中的不同操作。以下截图显示了 Dynamics 2013 中可用的不同操作：

CRM 2015 中的不同操作（包括新的“设置默认值”操作）。以下截图显示了在 Dynamics 2015 中可用的不同操作，包括新的“设置默认值”操作：

CRM 2015 还引入了为字段设置默认值的操作，同时通过业务规则清除字段值的功能。

下一个版本，CRM 2016，添加了根据业务流程属性调用业务规则的功能。如下所示，我们在条件中定义了业务流程规则和活动阶段规则；即，如果业务流程等于“销售机会流程”并且活动阶段为“建议”。以下截图显示了在定义业务规则时使用业务流程流程的情况：

与 CRM 2016 中的活动阶段规则类似，我们可以根据 CRM 2016 中选择的阶段规则定义条件。

创建基于业务流程的业务规则的详细信息，请参阅 msdn.microsoft.com/en-us/library/mt639372.aspx。

随着 2016 年 12 月更新的 Dynamics 365，我们现在拥有了一个全新更新的编辑器，用于定义业务规则，一个称为“推荐”的新操作，以及一些新功能。

在本节中，我们详细介绍了业务规则从 CRM 2013 到 CRM 2016 的发展历程。现在，让我们详细查看 Dynamics 365 中的新业务规则设计器及其所有组件。

了解新业务规则设计器

要快速查看新设计器，请打开任何实体进行自定义，选择左侧导航中的“业务规则”，然后点击“新建”按钮。这将打开在 Dynamics 365 中引入的全新业务规则设计器，具有全新的外观和感觉。新设计器允许我们使用拖放功能添加组件，如条件和操作：

这里需要记住的关键点是，业务规则在本质上仍然是相同的；只是编辑器发生了更新。我们仍然可以使用之前可用的范围选项，即实体、所有表单以及该实体的单独表单：

让我们暂停一下，快速回顾一下范围：

范围类型 描述
实体 业务规则适用于该实体的所有表单，包括快速创建和服务器端。
所有表单 业务规则适用于该实体的所有表单，包括快速创建。
特定表单（信息、账户等） 业务规则仅在该实体的特定表单上运行。

业务规则设计器的组件基本上分为流程和操作。

条件组件属于流程，而可用的各种操作包括推荐、显示错误消息、设置默认值、设置可见性、锁定/解锁、设置字段值和设置业务必填项。

推荐是 Dynamics 365 中新增的一项操作，通过它我们可以根据某些条件建议用户执行某个活动。我们将在接下来的章节中详细介绍。

新的设计器还允许搜索这些组件。搜索是即时搜索类型，在我们仍在输入时就会显示结果。

例如，在搜索框中输入 set 会显示带有 set 名称的操作，并在下拉框中筛选出可见的组件：

每个组件——即条件和操作，都有其特定的属性。在查看这些组件的属性之前，让我们先看看如何在业务规则设计器画布中添加这些组件。

使用条件组件指定条件

在创建新的业务规则时，业务规则设计器会打开，并且已经添加了一个条件。

要添加更多条件，我们可以点击工具栏上的添加按钮并选择添加条件：

另一种选择是将条件组件从组件选项卡拖放到设计器画布中。选择设计器中的条件时，会在属性选项卡中显示该条件组件的特定属性：

让我们来看一下条件组件的一些属性。

点击 + 新建会在规则部分添加一个新规则。例如，以下图片中的规则 2：

以下图片显示了规则逻辑和属性选项卡中的条件表达式（文本视图）属性。应用按钮应用条件，而丢弃按钮可用于撤销上一步操作，类似于Ctrl + Z命令：

现在，让我们看看可用于业务规则的不同类型操作的属性。

使用操作组件对条件执行操作

可以像添加条件一样添加操作，方法是点击工具栏上的“添加”按钮，并选择我们要添加的操作。也可以通过从“组件”选项卡中拖动操作并将其与条件关联来添加操作，具体如下所示。这里，我们从“组件”选项卡中拖动了“显示错误消息”操作，并将其与我们现有的新条件链接：

这将“显示错误消息”（Show Error Message）操作添加到条件中：

现在让我们来看看所有不同操作的属性：

  • 锁定/解锁：此操作可用于定义一个字段是否需要被锁定或解锁：

这是锁定字段“概率”（Probability）在商机表单中的显示方式：

  • 显示错误消息（Show Error Message）：此操作可用于在特定字段上显示错误消息：

这是错误消息在商机表单中的显示方式。将鼠标悬停在红色叉图标上可以查看错误消息：

  • 设置字段值：设置字段值操作可以用于为字段定义一个值。值可以使用以下选项设置。根据字段的数据类型，选项会有所不同：

  • 值（Value）：此选项可以直接指定字段的值

    • 字段（Field）：此选项可用于将字段的值指定为另一个字段的值

    • 公式（Formula）：此选项可通过应用公式来指定字段的值（此选项适用于日期时间、整数和小数字段）

    • 清除（Clear）：此操作会清除字段的值（此选项对于布尔类型和选项集字段不可用）

例如，我们可以使用“设置字段值”（Set Field Value）操作来定义一个规则，利用公式将预计关闭日期设置为从商机创建之日起 100 天，具体如下所示：

  • 设置业务必填（Set Business Required）：设置业务必填操作可用于将字段设置为“业务必填”或非强制性：

  • 设置可见性：设置可见性部分可用于显示或隐藏字段：

  • 推荐：如前所述，推荐是 Dynamics 365 中引入的新操作。推荐的不同属性如下：

推荐（Recommendation）是一种特殊类型的操作，它本身包含了其他操作：

该操作属于“设置字段值”（Set Field Value）类型：

这与我们之前讨论的设置字段值操作相同。为了看到所有组件的实际效果，让我们实现一个推荐业务规则。

推荐操作

现在我们对推荐操作的不同属性和业务规则设计器的不同组件有了一些基本了解，接下来我们将实现一个场景，看看它们如何发挥作用。我们将实现的场景是，如果选择的销售阶段是建议，我们将建议用户将概率设置为80。

让我们一步步地实现它。

在 CRM 中创建新业务规则有四种方式：

  • 在字段级别：

    1. 打开实体进行自定义

    2. 点击并打开字段

    3. 在左侧导航中选择业务规则，并点击新建以创建一个新的业务规则：

  • 在实体级别：

    1. 打开实体进行自定义

    2. 在左侧导航中选择业务规则，并点击新建以创建一个新的业务规则：

  • 从表单：

    1. 打开自定义表单，点击业务规则功能区按钮：

    1. 这将在表单的右侧面板中打开业务规则资源管理器，允许我们通过点击新建业务规则按钮来创建新的业务规则：

    1. 另一种可以从表单内定义业务规则的方式是通过打开自定义表单，双击任何字段或选择任何字段，然后点击更改属性功能区按钮以打开字段属性对话框。然后我们可以选择业务规则选项卡并点击新建以创建新的业务规则。

    2. 回到我们的场景，选择机会实体进行自定义，并创建一个新的业务规则，详细信息如下：

规则名称 销售阶段推荐。
描述 将销售阶段-建议的概率推荐为 80。
    1. 选择条件组件并在属性选项卡中定义规则当销售阶段等于建议时，如下所示：

  1. 点击应用以应用条件

  2. 接下来，我们需要为此条件添加一个推荐操作

  3. 可以点击工具栏上的添加按钮，或从组件选项卡中拖动推荐操作：

  1. 选择推荐操作并定义其属性，如下所示，然后点击应用：

  1. 接下来，我们需要定义作为推荐的一部分的操作（设置字段值）。为此，请在推荐中选择新建操作部分：

  1. 我们将操作定义为设置概率字段值为 80，如下所示，然后点击应用：

这就是我们最终规则在设计器画布中的样子。点击“保存”以保存规则；它也会验证规则是否有错误。在我们定义规则的过程中，随时可以点击“验证”来验证规则：

验证成功后，我们将看到“验证成功”消息。

如果出现任何错误，“验证”将显示错误消息，并以红色高亮显示。我们可以查看属性标签页以找出错误原因。在保存并发布业务规则之前，我们需要修复所有错误：

接下来，我们需要点击激活按钮以激活规则。

要查看业务规则的实际应用，我们需要打开机会记录并将销售阶段的值设置为“提议”：

这将显示概率字段旁边的信息图标。点击它将打开推荐框，显示我们之前设置的推荐标题和详细信息：

我们可以点击“关闭”按钮来关闭推荐对话框。点击“应用”将把概率值更新为 80，这是我们在“设置字段值操作”中定义的，具体如下：

现在，我们已经实现了推荐规则。接下来，让我们在下一节中介绍业务规则设计器的其他附加功能。

业务规则设计器的附加功能

除了创建规则的功能外，新的业务规则设计器还引入了一些额外的功能，让我们快速浏览一下这些新功能。

剪切、复制和粘贴组件

业务规则设计器中的工具栏提供了剪切、复制、粘贴和删除组件的选项。

要剪切或复制组件，选择该组件并点击工具栏中的“剪切”或“复制”按钮。或者，我们也可以使用键盘快捷键（CTRL + C 或 CTRL + X）来复制或剪切：

点击“粘贴”（或CTRL + V）会显示一个带有+符号的区域，可以在该区域添加已复制的组件：

点击+会将复制的组件添加到指定位置。

删除组件

要删除组件，只需选择该组件并点击工具栏上的“删除”按钮（或按CTRL + X）。这将打开确认删除对话框。

在“确认删除”对话框中点击“确定”将删除该组件。

拍摄业务规则的快照

点击工具栏上的“快照”按钮将当前业务规则的状态保存为图像文件：

文件以业务规则的名称保存，扩展名为.png。

设置缩放级别并适应画布以提高可读性

我们可以通过点击 - 和 + 镜头来设置商务规则设计器的缩放级别。第三个选项是“适应画布”，它使商务规则定义自动调整以适应商务规则设计器的画布：

使用迷你地图轻松导航

商务规则设计器画布还具有迷你地图组件，可以提供已设计商务规则的迷你视图：

它还允许在设计器画布内轻松导航。使用迷你地图，我们可以轻松滚动到商务规则定义的右下角，在那里我们可以看到锁定/解锁操作组件，如下所示：

使用商务规则（文本视图）阅读商务规则

设计器画布中的商务规则（文本视图）组件显示定义的规则的文本视图。

对于我们之前定义的推荐规则：

商务规则（文本视图）将显示以下内容：

关于商务规则的几个关键点

以下是关于商务规则的一些重要要点，在我们决定是否使用它们之前需要考虑：

  • 我们不能使用商务规则来隐藏表单的选项卡和部分。

  • 如果通过商务规则设置字段的值，则该字段的 OnChange 事件将不会被触发。

  • 商务规则中有一个 if...else 条件的限制，最多为 10 个。

  • 如果商务规则引用了表单中没有的字段，它将不会运行，也不会显示任何错误消息。

  • 如果商务规则没有定义为实体范围（Scope: Entity），它只会在表单加载时和字段值更改时运行。它不会在表单保存时运行。

  • 商务规则按激活顺序执行。所以，如果我们为一个实体定义了多个相互关联的商务规则，首先激活的商务规则会先执行，之后的商务规则按激活顺序执行。

  • 如果我们为某个特定字段定义了 JavaScript 和商务规则，JavaScript 将首先执行。

  • 商务规则不支持具有时区、持续时间或语言格式的整数字段。

  • 商务规则会在 Dynamics 365 的平板应用中进行缓存，当该应用打开时。如果有任何更改需要反映，必须关闭并重新打开该应用。

总结

在本章中，我们讨论了商务规则如何从 CRM 2013 到 Dynamics 365 的演变。我们有了一个全新的设计器，使得编写和定义商务规则更加直观。我们还详细了解了 Dynamics 365 中新增的推荐操作以及一系列新功能。

在下一章中，我们将了解 Microsoft PowerApps 及其如何用于创建自定义商务应用。

第五章：创建自定义业务应用

PowerApps 是一项服务，允许您跨平台创建、管理和使用自定义业务应用。它与客户现有的系统和数据源安全连接，允许自定义者在无需编写代码的情况下构建应用。通过发布，可以即时使这些应用适用于网页和移动用户。

在本章中，我们将涵盖以下几点内容：

  • PowerApps 概述

  • 配置和创建 PowerApps 所需的权限

  • PowerApps 中的连接器

  • 理解 PowerApps 的设计界面

  • 使用 Dynamics 365 数据创建 PowerApps

  • 在移动设备和平板设备上运行 PowerApps

  • PowerApps 中的数据连接服务

  • 使用数据连接服务创建应用

  • 在数据连接服务中创建实体

  • 自定义 PowerApps

PowerApps 在 Dynamics 365 中的概述

PowerApps 是一项服务，它与数据源（如 Azure、Dynamics 365 或 Office 365）建立安全连接，最小化组织对数据安全的担忧。任何用户都可以在 PowerApps 中设计应用，无需编写代码。发布这些 PowerApps 非常方便。

从员工的角度来看，PowerApps 提供了以下几种工作灵活性：

  • 提供快速创建应用的能力

  • 提供创建可在任何设备上运行的应用的能力

  • 提供 Microsoft Office 的应用体验

  • 提供内置的连接功能，能够与 PowerApps 建立连接，支持如 Dynamics 365 或 Office 365 等云服务

从开发者的角度来看，PowerApps 提供了以下功能：

  • 将 Azure 服务纳入 PowerApps，提高用户端的性能和速度

  • 容易创建与任何现有业务系统的数据连接和 API

  • 在组织数据安全管理中的可靠性与稳健性

PowerApps 加速了工作进程，并减少了构建应用的时间。这对于那些初学者非常有效和高效，允许您直接将云端内容传输到移动设备。

PowerApps 节省了大量开发时间，同时也可以将云端数据源与最少的配置连接起来。

设计 PowerApps 的前提条件

在 PowerApps 中设计非常简单。在此之前，我们将讨论 PowerApps 的配置和设计流程。完成以下步骤以进行设计：

  1. 使用 Dynamics 365 订阅创建 Office 365 实例

  2. 使用您的 Office 365 登录 ID 登录 PowerApps 网站

  3. 确保您的用户拥有 Office 365 全球管理员角色

PowerApps 中的连接器

PowerApps 能够从云端获取数据。为此，首先需要创建连接器。连接器指定 PowerApps 的数据源。将数据从云端传输到 PowerApps 非常简单且安全，无需担心任何加密问题来确保数据的安全性。

PowerApps 连接器支持许多服务，如在线数据或本地数据。PowerApps 提供两种类型的连接器：

  • 标准连接器：这些被称为标准连接器，因为 PowerApps 提供了对许多服务的支持，如 Dynamics 365、SharePoint 和 Excel。有许多连接器支持 PowerApps。

  • 自定义连接器：自定义连接器仅在需要将 PowerApps 与自定义服务连接时创建；例如，由开发人员设计的自定义服务，用于从本地数据服务器获取数据到 PowerApps。

一些类型的连接器仅与特定的数据源配合使用；例如，表格数据源，如 SharePoint 或 Excel。一些连接器设计用于与基于功能的数据源协作，如 Outlook、Facebook 和 Twitter。当从这些数据源获取数据时，PowerApps 有自己的不同功能与数据进行交互。然而，基于功能的数据需要比表格数据更多的处理与 PowerApps 进行配合。

以下是 PowerApps 中可用的连接器列表：

10to8 预约调度 计算机视觉 API Inoreader Pivotal Tracker
Act! 内容转换 Insightly Planner
Adobe Creative Cloud 内容审核 Instagram Plivo
Adobe Sign DB2 Instapaper PostgreSQL
Amazon Redshift Disqus Intercom Power BI
Apache Impala DocFusion365 - SP JIRA PowerApps 通知
AppFigures DocuSign JotForm Project Online
审批 Dropbox LeanKit Redmine
Asana Dynamics 365 LinkedIn RSS
AWeber Dynamics 365 for Financials LiveChat Salesforce
Azure AD Dynamics for Operations LUIS SendGrid
Azure 应用程序洞察 Dynamics NAV 邮件 服务总线
Azure 自动化 Easy Redmine MailChimp SFTP
Azure Blob 存储 Elastic Forms Mandrill SharePoint
Azure Cosmos DB Event Hubs Medium Skype for Business
Azure 数据湖 Eventbrite Microsoft Forms Slack
Azure 事件网格 Excel Microsoft StaffHub SmartSheet
Azure 事件网格发布 面部识别 API Microsoft Teams SMTP
Azure 文件存储 Facebook Microsoft Translator SparkPost
Azure 日志分析 文件系统 MSN 天气 SQL Server
Azure 日志分析数据收集器 Flic Muhimbi PDF Stripe
Azure 队列 FlowForma MySQL SurveyMonkey
Azure 资源管理器 FreshBooks Nexmo Teamwork Projects
Azure 表存储 Freshdesk 通知 Teradata
Basecamp 2 Freshservice Office 365 预定 Text Analytics
Basecamp 3 FTP Office 365 Groups Todoist
Benchmark Email GitHub Office 365 Outlook Toodledo
Bing 地图 Gmail Office 365 用户 Trello
Bing 搜索 Google 日历 Office 365 视频 Twilio
Bitbucket Google 联系人 OneDrive Twitter
Bitly Google Drive OneDrive for Business TypeForm
Bizzy (H3 Solutions, Inc.) Google Sheets OneNote (Business) UserVoice
Blogger Google Tasks Oracle Database Video Indexer
Box GoToMeeting Outlook Customer Manager Vimeo
bttn GoToTraining Outlook Tasks Visual Studio Team Services
Buffer GoToWebinar Outlook.com WebMerge
Calendly Harvest PagerDuty WordPress
Campfire HelloSign Parserr Wunderlist
Capsule CRM HipChat Paylocity Yammer
Chatter HTTP with Azure AD Pinterest YouTube
Cognito Forms Informix Pipedrive Zendesk
Common Data Service Infusionsoft Pitney Bowes Data Validation -

PowerApps 设计支持存储在云中的外部数据源；例如，从存储在 OneDrive 上的 Excel 文件中获取数据，还有其他数据源，如日历、电子邮件等，未来会支持该数据源的通知。

管理 PowerApps 数据

使用 PowerApps 中的数据并不是一个大挑战，借助连接器可以轻松使用数据，但从云端使用数据可能会导致大量数据进入应用程序。这对用户或系统本身都不好。非常重要的是创建一个高效、有效的应用程序来管理数据，因为获取数据就像是为应用程序用户获取所需的有用信息。这有助于减少内存占用、处理能力和网络带宽的需求。它还会通过获取有用的数据来提高 PowerApps 的响应时间和性能。

为了应对大量数据问题，数据委派被 PowerApps 用来进行处理。数据的委派只提供对用户有用的数据。这种数据排序能够节省大量网络流量。这意味着 PowerApps 会在加载设备之前处理数据。

委派就是在将数据发送到网络之前对数据应用公式。委派只支持表格数据源。

以下是数据源的列表，包含是否支持委派的信息：

数据源 支持委派
Common Data Service 是
SharePoint 是
SQL Server 是
Dynamics 365 是
Salesforce 是
Dynamics 365 for Operations 否
Dynamics 365 for Financials 否
Dynamics NAV 否
Google Sheets 否

PowerApps 通过委派功能来实现委派。以下列表列出了连接支持的一些委派功能和数据源：

以下列表指定了每个数据源的筛选和查找委派谓词：

获取 PowerApps 本地数据

可以使用本地数据来创建 PowerApps。网关用于将本地数据与 PowerApps 连接。网关是连接本地服务器中可用数据与 PowerApps 之间的桥梁。网关能够通过以下连接与本地数据源建立连接：

  • 文件系统

  • DB2

  • SharePoint

  • Informix

  • SQL Server

  • Oracle

PowerApps 设计器

PowerApps 设计器用于管理 PowerApps。该设计器包含以下组件，供设计 PowerApps 时使用：

屏幕：屏幕是 PowerApps 中不同控件的容器。屏幕就是为用户交互设计的应用程序的可视前端。在 PowerApps 中，管理屏幕非常简单。

以下是 PowerApps 中可用的屏幕类型：

  • 空白

  • 可滚动屏幕

  • 列表屏幕

  • 表单屏幕

控件：设计 PowerApps 时，需要不同的 UI 元素。这些 UI 元素也称为控件。

以下列表指定了 PowerApps 设计器的控件：

  1. 文本控件：

    • 标签

    • 文本输入

    • HTML 文本

    • 笔输入

  2. 控件：

    • 按钮

    • 下拉框

    • 日期选择器

    • 列表框

    • 复选框

    • 单选框

    • 切换

    • 滑块

    • 评分

    • 定时器

  3. 图库：

    • 垂直

    • 水平

    • 灵活高度

    • 空白垂直

    • 空白水平

    • 空白灵活高度

  4. 数据表

  5. 表单：

    • 编辑

    • 显示

    • 实体表单

  6. 媒体：

    • 图像

    • 相机

    • 条形码

    • 视频

    • 音频

    • 麦克风

    • 添加图片

  7. 图表：

    • 柱状图

    • 折线图

    • 饼图

使用 Dynamics 365 数据创建 PowerApps

这是一种简单且可靠的创建 PowerApps 的选项。在本节中，我们将讨论如何创建 PowerApps；此外，我们还将介绍如何在 PowerApps 中配置 Dynamics 365。PowerApps 能够从云中检索数据，包括 Azure 和 Dynamics 365。将 PowerApps 发布到 Web 和移动平台非常容易。

创建 PowerApps，请按以下步骤操作：

  1. 登录 Office 365 实例，并选择“浏览所有应用”选项：

  1. 选择 PowerApps 选项。

  2. 您将登录到 PowerApps 部分，或者您可以直接通过以下链接登录 PowerApps：web.powerapps.com/。使用与 PowerApps 登录相同的 Office 365 凭据：

  1. 导航部分位于屏幕的左侧。要创建应用程序，首先创建一个连接。从导航中选择“连接”。

  2. PowerApps 会将您重定向到“连接”部分。在这里，要添加新连接，请点击右上角出现的“新建连接”选项：

  1. 屏幕上将出现一个连接列表，如下图所示。从连接列表中选择 Dynamics 365：

  1. 屏幕上将弹出一个确认对话框。点击“创建”按钮：

  1. 现在，请检查“连接”部分；您将注意到屏幕上将显示 Dynamics 365 连接，如下图所示：

为案例实体创建 PowerApps

通过创建连接完成从云端提取数据的第一步。创建连接后，下一步是创建 PowerApps。有两种方法可以创建 PowerApps —— 使用 PowerApps 设计器从头开始创建 PowerApps，或者自动生成 PowerApps。

创建 PowerApps 将采用以下步骤：

  1. 使用您的 Office 365 凭据登录 web.powerapps.com/。

  2. 从导航中选择应用程序：

  1. 选择“创建应用程序”按钮：

  1. 在“以数据开始”下选择 Dynamics 365 Phone 布局选项：

  1. 单击“连接”以查看所有连接列表。在选择连接后，数据集将显示在与连接对应的数据集列表中：

  1. 选择与连接对应的适当数据集：

  1. 将打开一个表格列表，对应于数据集。

  2. 从列表中选择“案例”表，并单击“连接”按钮：

  1. 完成此步骤后，PowerApps 站点将重定向您到 PowerApps Studio：

  1. 要自定义应用程序，请首先从默认应用程序创建的屏幕列表中选择一个屏幕。要选择应用程序的屏幕以导航到 PowerApps Studio 左侧：

  1. PowerApps 根据案例记录接收的数据创建三个屏幕（请参考第 10 步中提到的屏幕）：

    • BrowseScreen1: 当用户启动应用程序时，此默认屏幕显示应用程序。

    • DetailScreen1: 当选择浏览屏幕上的项目时，此屏幕显示。

    • EditScreen1: 当单击项目进行编辑时，此屏幕显示。

  2. 要运行 PowerApps，请单击右上角的“运行”或预览应用程序：

  1. 预览后，通过选择“文件”选项保存应用程序：

  1. 单击“保存”。输入应用程序名称，并选择存储应用程序的位置：

在移动设备或平板电脑上运行 PowerApps

  1. 在移动设备或平板电脑上安装 PowerApps。

  2. 使用您的 Office 365 凭据登录。

  3. 从应用程序列表中选择应用程序：

  1. 打开所选的应用程序。

  2. PowerApps 将会启动：

通用数据服务

通用数据服务是一个基于 Azure 的云存储服务，旨在从多个应用收集数据并将其集中化，供用户使用。它被称为通用数据模型，包含数据实体。数据实体包含数据字段，用于存储数据。实体类似于数据源的表。PowerApps 可基于通用数据服务生成良好的应用。

以下是使用通用数据服务的优势：

  • 将数据导入自定义或标准实体

  • 创建支持不同场景和应用的自定义实体

  • 将自定义字段添加到标准实体的能力

  • 在应用中协作自定义和标准实体的能力

  • 通过添加插件来提高生产力，以便从 Microsoft Excel 和 Outlook 访问数据

  • 使用基于角色的安全性来保护自定义和标准实体的安全

  • 使用预定义的数据选择列表的能力，例如国家或称呼

每个实体都包含一组记录，用户可以删除、读取、更新和创建这些记录。实体之间可以创建关系，这就像使用查找功能一样简单。

通用数据服务中的实体分为自定义实体和标准实体。这些实体负责确保数据存储的安全。以下是实体的好处：

  • 简单管理：所有数据，包括数据和元数据，都存储在云端。

  • 简单共享：高效且易于在多个用户之间共享数据。

  • 简单安全：数据被安全存储，用户只有在获得授权时才能查看数据。基于角色的安全性允许你控制组织内不同用户对实体的访问。

  • 简单的元数据：所有数据和关系都可以轻松存储在 PowerApps 上。

  • 生产力工具：实体可以通过 Microsoft Excel 和 Outlook 等生产力工具轻松访问。

  • 选择列表：易于使用的预定义数据选择列表。

通用数据服务中有两种实体类型：

  • 标准实体：标准实体由通用数据服务提供，默认提供这些实体。

  • 自定义实体：自定义实体是通用数据服务提供的扩展。当需要向通用数据服务添加新数据时，可以创建自定义实体。

实体包含字段。每个字段都有名称、数据类型、显示名称和一些简单的验证。数据类型可以是文本、日期、数字等。字段有三种类型：

  • 系统字段

  • 标准字段

  • 自定义字段

系统字段：系统字段是最重要的字段，这些字段无法更改或删除。系统字段呈现所有实体，无论是标准的还是自定义的。以下字段是重要的系统字段。

  • 创建记录日期

  • 创建者

  • 修改记录日期

  • 最后修改者

自定义字段：当系统或自定义实体需要额外的数据字段时，我们可以在这些实体中添加自定义字段。

标准字段：每个标准实体都包含标准字段。

还可以在查找字段之间创建关系。查找数据类型用于表示实体之间的关系。

使用常见数据连接创建 PowerApps

我们已经了解了与常见数据连接相关的内容。为了理解常见数据连接，以下步骤将帮助创建常见数据连接：

  1. 访问 PowerApps 网站并创建新的连接。选择常见数据服务：

  1. 在“常见数据服务”对话框中选择“创建”按钮：

  1. 使用您的 Office 365 凭证进行身份验证。

  2. 通过导航到 PowerApps 导航栏检查常见数据连接。

  3. 在导航栏中点击“应用”部分创建一个新应用，使用“常见数据服务”：

  1. 从“选择实体”列表中选择“账户”实体，然后点击“连接”：

  1. 系统将根据账户数据自动生成 PowerApps：

  1. 点击预览按钮以运行应用：

  1. 从菜单栏中选择“文件”选项。点击“另存为”选项，然后指定应用的位置和名称：

创建自定义实体

以下步骤将指定如何创建自定义实体：

  1. 访问www.powerapps.com，然后在左侧导航面板中展开“常见数据服务”部分，接着选择“实体”：

  1. 选择“新建实体”按钮。填写“新建实体”对话框中的所有必填字段：

  1. 实体将被创建，并显示所有字段：

  1. 对于实体，存在多个部分可以添加，包括“字段”、“键”、“关系”和“字段组”。

  2. 要添加“字段”，请选择“字段”部分，然后选择“添加字段”按钮。“添加字段”表单将会打开。

  3. 完成必要的信息，并点击“添加字段”按钮：

  1. 要添加关系，请按照相同的步骤，然后点击“关系”部分。选择“添加”按钮并填写以添加关系，指定相关实体：

  1. 完成所有更改后，点击“保存实体”按钮：

自定义 PowerApps

PowerApps 提供了定制化的可行性。可以轻松地从 PowerApps 设计器中改变应用的外观、主题和控件。PowerApps 中可以进行以下定制：

为此目的，我们将在最后一部分创建一个应用：

1. 编辑屏幕大小和方向：

  1. 打开最近创建的应用，进入 PowerApps 网站的导航窗格中的 Apps。

  2. 选择应用带末尾的 ... 符号。点击 Edit on the web 选项：

  1. PowerApps 设计器将在新标签页中打开：

  1. 选择菜单栏中的 File 选项。

  2. 然后点击 App settings 选项：

  1. 在 App settings 中，选择 Screen size + orientation。将 Orientation 设置为 Portrait，然后点击 Apply 按钮保存更改：

  1. 如果应用是针对平板的，则选择纵横比。纵横比和方向的锁定是可能的，但如果最终设备的纵横比与应用的纵横比不匹配，那么应用屏幕在最终设备上会显得不适合。作为好的实践，直到确保应用用户的终端设备相同时，不要锁定 PowerApps 的纵横比和方向。

2. 编辑 PowerApps 名称和图标：

  1. 现在，要更改应用名称，进入 File 菜单并选择 App settings。

  2. 点击 App Name + Icon。

  3. 点击 Edit app name，修改应用名称：

  1. PowerApps 网站页面将重定向到应用设置页面；你可以从此部分更改应用设置。点击 Edit app name 选项，屏幕上将出现一个更改应用名称的对话框：

  1. 重命名应用并保存更改：

  1. 在 PowerApps 中也允许编辑应用图标和符号：

  1. 现在，点击导航中的 Save 选项，然后点击 Save app。它将显示一个发布应用的选项。点击 Publish this version 按钮，发布应用：

3. 在 PowerApps 中添加屏幕：

设计应用的过程包括添加屏幕。要在应用中添加多屏幕，请按照以下步骤操作：

  1. 在 PowerApps 设计器中的应用中，选择菜单中的 Home 按钮并点击 New screen。选择适合应用的屏幕，或者选择 Blank screen：

  1. 要重命名屏幕名称，请点击左侧导航窗格中的 Screen 选项，然后选择重命名，或右键点击 Properties 并重命名屏幕。将其命名为 Account Source：

  1. 添加屏幕后，在 DetailScreen1 上添加导航。选择 DetailScreen1，然后点击菜单上的 Insert 按钮：

  1. 选择 Icons，添加一个前进图标到屏幕上，如下截图所示。如有需要，可以从属性中更改前进箭头的颜色：

  1. 添加屏幕后，添加导航到 DetailScreen1。选择 DetailScreen1，然后点击菜单上的“插入”按钮：

  1. 选择图标并在屏幕上添加一个前进图标。如果需要，可以更改前进箭头的颜色：

  1. 选择并调整图标。在选择图标时，选择“操作”选项卡。在导航中，选择“OnSelect”，并将其属性设置为“Navigate”，如下面的截图所示：

  1. 选择“帐户源”屏幕，并在屏幕上添加一个后退箭头：

  1. 如下图所示设置图标的“操作”：

  1. 现在点击预览按钮来运行和测试应用：

  1. 点击应用的下一个按钮：

4. 在 PowerApps 中添加和配置控件：

控件是屏幕上的 UI 元素，使应用更加互动。以下步骤是关于如何添加和配置屏幕上的控件。在上一节中，已向应用中添加了一个空白屏幕。接下来的步骤将在同一个应用中继续添加控件：

  1. 在 PowerApps 设计器中打开应用并选择屏幕：

  1. 从菜单栏选择“插入”选项。点击“标签”，该操作将添加一个标签到屏幕上：

  1. 要更改新添加标签的属性，选择屏幕上的标签，然后点击右侧的“属性”选项卡。将标签的名称更改为Account Detail Label，文本更改为Account Detail。通过拖动其边缘来调整标签的大小：

  1. 要配置控件，选择标签并点击菜单栏中的“主页”按钮。所有配置选项将可供使用：

  1. 通过选择填充颜色，来更改标签的颜色，并选择合适的颜色：

  1. 在屏幕上添加一个复选框和另一个标签：

  1. 检查“联系”标签的可见性并将其关闭，然后为标签设置以下属性：

  1. Contact标签将根据复选框的值显示或隐藏：

  1. 保存并发布更改。

5. 在 PowerApps 中添加列表和数据源：

PowerApps 支持添加多个连接。我们将从上一节继续应用设计，添加不同的数据源，并使用 Gallery 控件添加一个列表：

  1. 在 PowerApps 设计器中打开应用，并选择“帐户源”屏幕：

  1. 选择“插入”按钮，然后点击“图库”以添加图库的垂直布局：

  1. 调整图库和可见性条件，如下截图所示：

  1. 向图库添加数据。首先，选择图库，然后点击“属性”选项卡。如果数据源尚未添加，选择“自定义数据源”，然后添加数据源：

  1. 从连接列表中选择一个连接，或者创建一个新连接，然后点击“连接”。在此示例中，选择“通用数据服务”：

  1. 从实体列表中选择联系人，然后点击“连接”按钮：

  1. 选择联系人数据源：

  1. 所有联系人将出现在图库控件中：

总结

在本章中，我们已经看到了所有 PowerApps 功能。我们还实现并配置了 PowerApps 连接和数据源。我们还使用 Dynamics 365 数据和通用数据服务数据创建并配置了不同的 PowerApps。

第六章：使用 Microsoft Flow 自动化业务流程

在上一章中，我们学习了如何使用 Microsoft PowerApps 来轻松创建自定义业务应用程序。在本章中，我们将学习 Microsoft Flow，它可以定义为一项基于云的服务，使用户能够构建工作流，自动化跨多个应用程序和服务的不同任务和流程。

本章将涵盖以下内容：

  • 什么是 Microsoft Flow？

  • 在 Dynamics 365 上下文中的 Microsoft Flow

  • 使用 Microsoft Flow 自动化流程

  • Dynamics Workflow 与 Microsoft Flow 之间的区别

了解 Microsoft Flow

如前所述，Microsoft Flow 是一项基于云的服务，允许我们在不同的应用程序和服务之间创建自动化工作流。我们可以在 Microsoft Flow 中使用的应用程序和服务列表不断扩展。目前，Microsoft Flow 支持超过 170 种服务连接器，包括 Dynamics 365、Office 365 Outlook、OneDrive for Business、SharePoint、Twitter 和 Facebook 等流行应用程序。

查看 Microsoft Flow 中所有可用连接器的完整列表，请访问以下链接：

flow.microsoft.com/en-us/connectors/

如果这还不够，我们还可以为我们的 RESTful API（使用 JSON）构建自己的连接器。

在 Microsoft Flow 中创建自定义连接器，网址为 flow.microsoft.com/en-us/documentation/register-custom-api/

除了基于云的服务，我们还可以连接到本地数据源。要连接到本地数据源（如 SharePoint、SQL Server、Oracle 等），我们可以创建本地数据网关。

在 Microsoft Flow 中管理本地数据网关，网址为 flow.microsoft.com/en-us/connectors/

Microsoft Flow 提供了预定义的模板。这些模板是围绕流行服务和场景预构建的流程，我们可以立即开始使用。我们可以使用现有的模板来创建一个流程，或者如果某个特定场景未被现有模板涵盖，我们可以从头开始创建自己的流程——也就是从零开始创建一个。

若要查看 Microsoft Flow 中所有的模板列表，请访问以下链接：

flow.microsoft.com/en-us/templates/

一些最受欢迎的模板包括：

  • 将 Office 365 的电子邮件附件保存到 OneDrive for Business

  • 在 10 分钟后发送提醒给我自己

  • 当我收到老板的电子邮件时，发送推送通知

这些模板被分为多个类别，例如审批、按钮、收集数据、电子邮件、移动设备、通知等。模板还可以按名称、流行度和发布时间进行排序，如下图所示：

要创建一个流，我们需要使用现有的 Microsoft 帐户（无论是工作、学校还是个人帐户）登录，否则我们需要先进行注册。

访问 Microsoft Flow 的主页（flow.microsoft.com）并点击“登录”或“免费注册”：

Microsoft Flow 不支持以 .gov 和 .mil 结尾的电子邮件地址。

选择合适的 Microsoft Flow 计划

在我们深入创建流之前，首先了解不同 Microsoft Flow 计划提供的功能。基本上，有两个 Microsoft Flow 计划——一个是免费计划，另一个是高级计划。

免费计划 Flow Free 包含无限流创建、每月 750 次运行（每个用户）以及 15 分钟检查（如果流在上次运行后的 15 分钟内被触发，它将排队等待）。

Flow Plan 1（付费版）提供无限流创建、每月 4,500 次运行和 3 分钟检查。它还包括高级连接器，如 Salesforce、Common Data Service、Adobe Creative Cloud 等。

查看完整的高级连接器列表请点击这里：

flow.microsoft.com/en-us/connectors/?filter=&category=premium

以下是一些高级连接器，如 Salesforce、DB2 和 DocuSign 等：

Flow Plan 2 提供无限流创建、每月 15,000 次运行以及 1 分钟检查，并包括高级连接器。Flow Plan 1 和 Flow Plan 2 提供 90 天的免费试用。

除了上述计划外，还有 Dynamics 365 计划和 Office 365 计划，这些计划包括 Microsoft Flow。这些计划提供无限流创建、每月 2,000 次运行，并且流的频率为 5 分钟。但它们不包括高级连接器。以下是两个包含 Dynamics 365 应用程序的计划：

理解流的不同组成部分

我们已经讨论了不同 Microsoft Flow 计划之间的差异，这有助于我们决定选择哪个计划。现在让我们了解一下流中的不同组成部分。

流的不同组成部分包括：

  • 服务：服务可以定义为 Microsoft Flow 连接的不同应用程序，例如 Twitter、SharePoint、Facebook 等。这些服务既可以作为源，也可以作为流中的目标。以下是 Microsoft Flow 提供的一些服务的列表。目前，支持的服务有 160 个，且该列表还在不断增长。

  • 触发器：触发器是 Flow 的起点。它们可以是 Microsoft Flow 中的手动触发器，需要最终用户手动启动，或者可以是自动触发的，按照计划在特定时间运行，或从另一个应用程序或服务启动。触发器还可以是基于事件的；当服务中发生事件时，它将触发 Flow。例如，在 CRM 中创建潜在客户记录或在 SharePoint 列表中添加新项可以作为触发器。以下是特定于 Dynamics 365 的触发器列表：

  • 操作：操作定义了当 Flow 被触发时需要执行的步骤，换句话说，就是工作流执行的输出。操作可以是发送电子邮件、创建记录、在社交媒体（如 Twitter 或 Facebook）上发布内容等。以下是与 Dynamics 365 相关的一些操作：

  • 条件：条件可以在 Flow 中放置 if/then 分支逻辑。它们基本上包括 Flow 在条件输出的基础上可以采取的“是”路径和“否”路径：

  • 循环和 Switch：使用循环，我们可以在满足特定条件时多次执行某个操作，或者只执行一次。这可以通过 Apply to each 或 Do-Until 步骤来完成。同样，Switch 步骤可以用于在操作中指定类似于 switch case 的逻辑：

以下图片展示了一个空白的 Switch 步骤，包含一个 Apply to each 步骤和一个 Do Until 步骤：

我们可以通过 Flow Ideas 门户提交关于新连接器和触发器的建议：

powerusers.microsoft.com/t5/Flow-Ideas/idb-p/FlowIdeas

在本节中，我们介绍了 Microsoft Flow 的概念，提供的不同计划，以及构成 Flow 的基本组件。在下一节中，我们将讨论 Microsoft Flow 在 Dynamics 365 背景下的应用。

在 Dynamics 365 背景下理解 Microsoft Flow

Microsoft Flow 提供了针对 Dynamics 365 的预构建模板，例如从 Excel 表格创建 Dynamics 365 潜在客户、通知团队新机会等。以下是一些特定于 Dynamics 365 的流行模板：

查看完整的 Dynamics 365 模板列表，请访问以下链接：

flow.microsoft.com/en-us/connectors/shared_dynamicscrmonline/dynamics-365

以下表格列出了可用于 Dynamics 365 的不同触发器：

在撰写本章时（2017 年 11 月），微软还为 Dynamics 365 添加了两个新的触发器和四个新的操作，这些内容作为版本 2 处于预览阶段。这些更新版本的触发器和操作将继续获得最新的功能。拥有独立的版本有助于在不干扰现有流程（使用旧版）流的情况下测试新功能。

新增了一个触发器，可以在创建和更新实体记录时调用。触发器和操作的更新版本支持将选项集作为本地化的字符串，而旧版仍然使用整数作为选项集值。

可用于 Dynamics 365 的操作列表：

以下是添加到 Dynamics 365 中的新触发器和操作：

触发器：

  • 当记录被创建时（预览）：当在 Dynamics 365 中创建记录时，触发流程，且选项集作为字符串暴露

  • 当记录被创建或更新时（预览）：当在 Dynamics 365 中创建或更新记录时，触发流程，且选项集作为字符串暴露

操作：

  • 创建新记录（预览）：为实体创建一条新记录，选项集作为字符串暴露

  • 获取记录（预览）：获取特定实体的记录，选项集作为字符串暴露

  • 列出记录（预览）：获取实体的记录，选项集作为字符串暴露

  • 更新记录（预览）：更新具有选项集并以字符串形式暴露的实体的现有记录

在 Dynamics 365 中，我们需要为自定义实体启用变更追踪，以便 Microsoft Flow 跟踪该实体记录的任何更新或删除。默认情况下，OOB 实体启用了变更追踪。对于自定义实体，转到设置 | 自定义 | 打开自定义实体 | 在常规标签的“数据服务”部分选中“变更追踪”复选框。

创建一个 Dynamics 365 流程

我们可以从 Microsoft Flow 的主页 (flow.microsoft.com/) 创建流程，或者在 Dynamics 365 中，通过转到设置 | Microsoft Flows 创建一个流程。

我们还可以通过功能区上流程弹出菜单中的“创建流程”或“查看您的流程”菜单选项创建一个流程，如下图所示：

下图显示了添加到表单功能区中的新流程菜单：

让我们实现一个示例流程，看看所有组件如何运作。

我们将实现以下场景：

  • 场景：在 Dynamics 365 中创建一个评分为高的潜在客户记录时，将潜在客户记录的详细信息添加到 OneDrive 内的 Excel 文件中的新行，创建 Wunderlist 中的跟进任务，并最终在 Microsoft Flow 移动应用中发送通知。

  • 触发器：在 Dynamics 365 中创建潜在客户记录时触发。

  • 条件：如果创建的潜在记录中的 Rating 字段值为 High。

  • 操作：在 Excel 中插入行，创建 Wunderlist 任务并发送通知。

  1. 访问 Microsoft Flow 主页(flow.microsoft.com/)，使用 Microsoft 帐户登录，进入“我的流程”并点击“从空白创建”。

  2. 指定流程名称，并在搜索框中搜索 Dynamics 365，筛选出与 Dynamics 365 相关的触发器和操作。在结果中，我们需要选择 Dynamics 365- 当记录创建时触发器：

  1. 指定要连接的 CRM 的“组织名称”，并在实体名称中选择潜在：

  1. 点击“新步骤”，然后选择“添加条件”以添加条件：

  1. 将 Rating 设置为等于1，即 Lead 中 Rating 字段的选项“Hot”的OptionSet值，如下图所示：

  1. 在“动态内容”选项卡的搜索框中搜索Rating字段，并将其添加到条件中。动态内容选项卡将列出所有潜在实体的字段。Rating 字段的值将在流程执行时从 Dynamics 365 中创建的潜在记录中获取，因此称之为动态内容。动态内容将在流程执行时，基本上包含新创建的潜在记录的详细信息：

  1. 条件块具有与“是”路径和“否”路径相关联的分支。在“是”路径中点击“添加操作”以添加操作：

  1. 搜索并选择 Excel - 插入行操作：

  1. 如果需要，登录 OneDrive 账户并授权 Microsoft Flow。在One Drive文件夹中，选择要保存潜在记录详情的 Excel 文件及其中的表格。以下截图显示了我们 Excel 文件中现有的潜在表格，我们将在其中添加一行包含潜在记录详情的数据：

  1. 将每一列与“插入行”操作中的相应字段（动态内容）进行映射，如下图所示：

  1. 对于我们的下一个操作，添加一个新的操作，在 Wunderlist 中创建一个任务。为此，请点击先前添加的“插入行”操作中的“添加操作”，然后选择 Wunderlist - 创建任务操作，如下图所示：

  1. 如果需要，登录 Wunderlist 并授权 Microsoft Flow。指定如下截图所示的详细信息：

  1. 要向 Microsoft Flow 移动应用发送推送通知，请点击流程中的“添加操作”，然后选择“通知 - 发送移动通知”操作，如下图所示：

  1. 指定如下图所示的详细信息：

  1. 点击“创建流程”以创建流程。

  2. 为了测试我们的流程，让我们创建一个潜在客户记录，评级为“热”，并指定如下图所示的其他详细信息：

  1. 要检查流程的状态，在 Microsoft Flow 的首页选择“我的流程”，然后点击我们创建的流程：

  1. 点击“查看所有选项”在“运行历史记录”中，将显示 Microsoft Flow 运行历史记录的所有详细信息：

  1. 点击“成功”行将显示步骤的执行详情。在我们的案例中，所有步骤都成功完成，绿色勾号表示：

现在让我们检查每个操作在其相应应用中的输出：

  1. 插入 Excel 行操作：此操作已将一个新行添加到我们的 Excel 表格中，包含创建的潜在客户记录的详细信息：

  2. Wunderlist 操作中的创建任务：此操作已在 Wunderlist 的收件箱中添加了一个新的待办任务：

  3. 在 Microsoft Flow 移动应用中的“发送我移动通知”操作：此操作已在 Flow 移动应用中发送了一条有关创建的潜在客户记录的通知：

Microsoft Flow 移动应用适用于 Android、iOS 和 Windows Phone。使用移动应用，我们可以从模板创建流程，监控流程活动，并管理我们的流程：flow.microsoft.com/en-us/documentation/mobile-create-flow/

这完成了我们 Dynamics 365 流程的创建和测试。现在，要与其他用户共享此流程，我们可以将该用户添加为所有者：

  1. 转到“我的流程” | 选择流程 | 点击“邀请其他所有者”：

  1. 指定新所有者：

我们还可以将我们的流程提交为模板，发布到 Microsoft Flow 模板库：flow.microsoft.com/en-us/documentation/publish-a-template/

在本节中，我们看到了特定于 Dynamics 365 的不同模板、触发器和操作。我们还创建了一个自定义的 Dynamics 365 流程。在下一节中，我们将比较 Flow 和 Dynamics 365 工作流，帮助我们选择其中一个。

Dynamics 365 工作流与 Microsoft Flow

有些场景可以通过 Dynamics 工作流或 Microsoft Flow 来实现。以下是我们在决策时可以考虑的一些要点：

如果某个场景可以在 Dynamics 365 中通过工作流实现，那么工作流是更好的选择。这是因为我们可以通过 CRM 中的系统作业轻松管理和监控它。而要管理和监控 Flow 流程，我们需要跳出 CRM，在 Flow 的门户中进行操作。

工作流可以同步和异步运行。当条件满足时，工作流会立即触发。因此，在我们希望立即采取行动的场景中，工作流是更好的选择。此外，工作流具有解决方案感知能力，因此可以轻松地从一个环境迁移到另一个环境。

在我们需要与第三方应用程序和服务（如 Twitter、Facebook、Yammer 等）无缝集成的场景中，Microsoft Flow 更为适用。要在工作流中实现这一点，可能需要开发工作，即编写自定义工作流活动。

使用工作流时，我们只能通过电子邮件发送通知；然而，使用 Flow，我们可以通过 SMS、推送通知（到 Flow 移动应用）、以及通过 Gmail、Hotmail 等账户发送电子邮件通知，且无需编写任何代码。

Microsoft Flow 通过特定的审批操作支持审批场景，如下图所示。审批请求可以发送给除了 Dynamics 365 用户以外的其他用户：

Microsoft Flow 拥有 Dynamics 365、列记录操作，可以用来检索实体的记录。我们可以使用它找到符合特定条件的实体记录列表，并对其进行处理。它还可以用来设计一个流，当父记录被更新或删除时，自动更新或删除子记录。通常，要实现这样的场景，我们必须在 CRM 中编写自定义的工作流活动或插件。使用 Microsoft Flow，我们可以无需编写任何代码即可实现这一点：

使用 Microsoft Flow 删除 Dynamics 365 中父记录被删除时的所有子记录：debajmecrm.com/2017/02/21/dynamics-crm-365-flows-using-microsoft-flows-generic-framework-to-delete-all-child-records-when-a-parent-record-is-deleted-in-dynamics-365/

在动态工作流中，为了实现调度任务，我们最终会使用等待或超时条件，这可能会影响系统性能。另一方面，Microsoft Flow 支持重复触发器，可以在定期的、自定义的时间间隔触发事件：

简而言之，选择其中一种并没有明确的界限，因为两者都有各自的优点和不足。

总结

本章中，我们介绍了如何使用 Microsoft Flow 编写工作流，这些工作流可以与多个应用程序和服务无缝集成，且无需编写任何一行代码。我们还详细探讨了 Microsoft Flow 在 Dynamics 365 中的应用，并学习了如何编写一个简单的流，以集成多个应用程序。

在下一章中，我们将介绍 Web API 以及如何使用它们来创建与 Dynamics 365 集成的应用程序。

第七章：使用 Web API 开发应用程序

Web API 是一项新功能，首次在 Dynamics CRM 2016 中引入。你可以使用 Dynamics 365 Web API，结合不同的编程语言、多个平台和设备。Dynamics 365 中的 Web API 使用 开放数据协议（OData），也称为 OData 版本 4。由于 Dynamics 365 Web API 基于开放标准构建，因此不需要使用任何程序集。

在 Dynamics 365 中，组织数据服务已被弃用，并由 Web API 替代。该 API 的主要目的是提供与组织服务的功能对等，并尽量减少约束。

以下是 Web API 的特点：

  • 它实现了 OData 版本 4.0，用于构建和消费基于丰富数据源（如 DOC、HTML 和 PDF）的 RESTful API。

  • 它支持多种编程语言，如 .Net、C++、Java、Python、设备和平台。

  • 请求和响应采用 JSON 格式

开始使用 Dynamics 365 Web API（客户端 JavaScript）

Dynamics 365 Web API 可以通过 JavaScript 调用和访问。你可以将 Web API 与 HTML Web 资源、表单脚本和功能区命令结合使用，对数据执行各种操作。

Web API 与 JavaScript 一起使用非常方便，因为它返回的结果是 JSON 对象，能够轻松地转换为 JavaScript 对象。

在 Dynamics 365 中，Web API 主要用于 HTML Web 资源和单页面应用程序中。

JavaScript Web 资源

在 JavaScript Web 资源中使用 Web API 的主要好处是，你无需进行身份验证，因为 Web 资源是应用的一部分，只能由已认证用户访问。你可以直接在 JavaScript Web 资源中编写 Web API 操作代码并执行操作。

单页面应用程序

单页面应用程序能够发起 Dynamics 365 Web API 调用。它们包含许多运行在浏览器上的 JavaScript 库，这些库通过 跨源资源共享（CORS）认证 Dynamics 365 API。

在单页面应用程序中使用 JavaScript 时，adal.js 库用于允许用户进行身份验证，并通过托管的 Web 应用访问 Dynamics 365。你还必须集成一个包含身份验证令牌的授权头。

在本章后续部分，我们将通过一些示例，使用 Web API 执行基于 Web 资源的 CRUD 操作。

Dynamics 365 Web API 使用 XMLHttpRequest 对象来执行操作。

在 Dynamics 365 Web API 中使用 XMLHttpRequest

XMLHttpRequest（XHR）是所有浏览器支持的本地对象，它使得 AJAX 技术得以在网页中动态交互。

我们将查看一个非常简单的示例，该示例使用 Web API 和 XMLHttpRequest 对象。

以下是获取所有机会的 Web API 代码：

    var req = new XMLHttpRequest();
    req.open("GET", Xrm.Page.context.getClientUrl() +   
    "/api/data/v8.2/opportunities()", true);
    req.setRequestHeader("OData-MaxVersion", "4.0");
    req.setRequestHeader("OData-Version", "4.0");
    req.setRequestHeader("Accept", "application/json");
    req.setRequestHeader("Content-Type",
    "application/json; charset=utf-8");
    req.setRequestHeader("Prefer", "odata.include-annotations="*"");
    req.onreadystatechange = function() {
      if (this.readyState === 4) {
        req.onreadystatechange = null;
        if (this.status === 200) {
          var result = JSON.parse(this.response);
          var opportunityid = result["opportunityid"];
        } else {
        Xrm.Utility.alertDialog(this.statusText);
       }
      }
    };
    req.send();

在上述代码中，您会注意到，在初始化一个新的XMLHttpRequest对象后，您需要在发送或设置任何属性之前打开它。open方法的参数包括 HTTP 请求方法（GET、PUT、POST、DELETE等）、URL 以及一个布尔值参数，表示是否异步执行操作。

Web API URL 和版本

Web API 的 URL 由以下部分组成：

  • 协议：HTTP 请求中的协议可以是http://或https://。

  • 基础 URL：基础 URL 就是当前组织的 URL，可以通过函数Xrm.Page.context.getClientUrl()获取。

  • Web API 路径：Dynamics 365 中的 Web API 路径是 API/data。

  • 版本：这是 Dynamics 365 Web API 的版本。最新版本是 9.0。

  • 资源：资源可以是实体的名称、函数或您想执行的操作。

上述示例中使用的 URL 是Xrm.Page.context.getClientUrl() + "/api/data/v8.2/opportunities().

HTTP 请求还支持各种HTTP 方法，具体描述如下：

  • GET：用于检索数据；成功调用的状态码是200 OK

  • POST：用于创建新记录

  • PATCH：用于更新或执行对实体记录的upsert操作

  • DELETE：用于删除记录

  • PUT：用于更新实体记录的单个属性

对于 HTTP 请求，还使用了各种 HTTP 头部，具体描述如下：

Dynamics 365 仅支持 JSON 格式。因此，以下头部可与 Dynamics 365 Web API 一起使用。

对于每个请求，必须包括Accept头部值application/json，即使没有响应，返回的也是正文。如果发生错误，将以 JSON 格式返回。虽然代码没有这个头部也能正常工作，但在请求中使用它是一种最佳实践。

您必须始终包含OData-Version和OData-Max-Version头部，设置为 4.0 的值。当前的 OData 版本是 4.0，但为了避免未来 OData 版本的不明确性，您应该在请求中包括这些头部。

不包含任何最近更改的属性可能包含缓存数据。因此，为了覆盖浏览器缓存 Web API 请求，必须在请求正文中包含If-None-Match: null头部。

在对 Dynamics 365 中的 Web API 有了基本了解后，我们将开始使用 Web API 执行各种操作。我们还将学习如何使用 Web API 请求创建、检索、更新和删除实体记录。我们还会查看关联和取消关联请求的示例。

因此，至少应包括以下 HTTP 头部：

  • Accept: application/json

  • OData-MaxVersion: 4.0

  • OData-Version: 4.0

  • If-None-Match: null

使用 Dynamics 365 Web API 查询数据

在从 Dynamics 365 检索数据时，您可以设置所需数据的各种条件，并且可以应用多种过滤器来检索特定的数据。为此，我们将通过一个示例来展示如何使用 Web API 查询数据：

  1. 在此示例中，我们将使用 $set 和 $top 系统查询选项返回前五个联系人的 firstname 属性：
   Request: GET [Organization URI] /api/data/v9.0/contacts? 
    $select=firstname&$top=5
    Accept: application/json
    OData-MaxVersion: 4.0
    OData-Version: 4.0

前述请求的响应如下：

    {
      "@odata.context":  "https://biocondev3.crm8.dynamics.com
      /api/data/v9.0/$metadata#contacts(firstname)",
      "value": [
      {
        "@odata.etag": "W/"684628"",
        "firstname": null,
        "contactid": "ade1d0f5-28ed-e711-a95e-000d3af27347"
      },
      {
        "@odata.etag": "W/"679541"",
        "firstname": null,
        "contactid": "fa420510-85ec-e711-a95f-000d3af27534"
      },
      {
        "@odata.etag": "W/"679547"",
        "firstname": "C",
        "contactid": "94cd4c79-85ec-e711-a95f-000d3af27534"
      },
      {
        "@odata.etag": "W/"679575"",
        "firstname": null,
        "contactid": "e8f5339f-88ec-e711-a95f-000d3af27534"
      },
      {
        "@odata.etag": "W/"681230"",
        "firstname": null,
        "contactid": "fc71e9b9-a2ec-e711-a95f-000d3af27534"
      }
    ]
   }
  1. 在下一个示例中，我们将展示如何限制每个请求返回的实体记录数。最多可以返回 5,000 条记录。您不能在 Dynamics 365 中检索超过 5,000 条记录：
Request: GET [Organization URI]/api/data/v9.0/accounts?$select=nameHTTP/1.1
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0
Prefer: odata.maxpagesize=3

前述请求的响应如下：

{
"@odata.context": "https://biocondev3.crm8.dynamics.com/api/data/v9.0/$metadata#contacts(firstname)",
"value": [
{
"@odata.etag": "W/"684628"",
"firstname": null,
"contactid": "ade1d0f5-28ed-e711-a95e-000d3af27347"
},
{
"@odata.etag": "W/"679541"",
"firstname": null,
"contactid": "fa420510-85ec-e711-a95f-000d3af27534"
},
{
"@odata.etag": "W/"679547"",
"firstname": "C",
"contactid": "94cd4c79-85ec-e711-a95f-000d3af27534"
}
]
}
  1. 现在，我们将看到如何使用 Dynamics 365 Web API 应用系统查询选项来查询数据。第一个查询选项附加在 [?] 后面，后续每个选项通过 [&] 分隔。查询选项区分大小写。

在下一个查询中，我们将选择年龄小于 50 的联系人的 firstname 和 lastname：

GET [Organization URI]/api/data/v9.0/contacts?$select=firstname,lastname&$top=3&$filter=age lt 50

Dynamics 365 Web API 中使用的标准筛选运算符如下所示：

运算符 描述 示例
比较运算符 - -
Eq 等于 $filter=age eq 50
Ne 不等于 $filter=age ne 50
Gt 大于 $filter=age gt 50
Ge 大于或等于 $filter=age ge 50
Lt 小于 $filter=age lt 50
Le 小于或等于 $filter=age le 50

逻辑运算符如下所示：

运算符 描述 示例
逻辑运算符 - -
And 逻辑与 $filter=age lt 50 and age gt 20
Or 逻辑或 $filter=contains(firstname,'(sample)') or contains(firstname,'test')
Not 逻辑非 $filter=not contains(firstname,'sample')

分组运算符如下所示：

分组运算符 - -
( ) 优先级分组 (contains(firstname,'sample') or contains(firstname,'test')) and age gt 50

标准查询选项

Web API 支持的 OData 字符串查询函数如下所示：

函数 示例
Contains $filter=contains(firstname,'(sample)')
Endswith $filter=endswith(firstname,'Inc.')
startswith $filter=startswith(firstname,'a')

排序查询：

您可以按升序或降序排序记录。以下示例展示了如何排序记录：

GET [Organization URI]/api/data/v9.0/contacts?$select=firstname,age,&$orderby=age asc,firstname desc&$filter=age ne null

现在，学习了如何使用 Dynamics 365 Web API 查询数据后，我们将讨论 CRUD 操作。我们将通过一些执行这些操作的示例来进行演示。

使用 Dynamics 365 Web API 进行 CRUD 操作

我们将展示一些创建、更新、检索和删除实体的基本示例。

创建实体

以下是一个 Web API 的代码示例，用于为 entity 账户创建新记录。首先，我们将创建一个 JSON 对象并设置所需的属性：

//Creates a JSON object for an Entity to be created.
var entity = {};
//Sets the properties for entity.
entity.accountnumber = "AC1009348YU";
entity.name = "Shree Technosoft";
entity.telephone1 = "9978759612";
var req = new XMLHttpRequest();
req.open("POST", Xrm.Page.context.getClientUrl() + "/api/data/v8.2/accounts", true);
req.setRequestHeader("OData-MaxVersion", "4.0");
req.setRequestHeader("OData-Version", "4.0");
req.setRequestHeader("Accept", "application/json");
req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
req.onreadystatechange = function() {
  if (this.readyState === 4) {
    req.onreadystatechange = null;
    if (this.status === 204) {
      var uri = this.getResponseHeader("OData-EntityId");
      var regExp = /(([^)]+))/;
      var matches = regExp.exec(uri);
      var newEntityId = matches[1];
    } else {
      Xrm.Utility.alertDialog(this.statusText);
     }
   }
  };
  req.send(JSON.stringify(entity));

获取实体记录列表

接下来，我们将通过 Web API 请求从 Dynamics 365 中检索账户列表。以下是用于检索实体列表的代码：

var req = new XMLHttpRequest();
req.open("GET", Xrm.Page.context.getClientUrl() + "/api/data/v8.2/accounts?$select=accountid,accountnumber,accountratingcode,telephone1", true);
req.setRequestHeader("OData-MaxVersion", "4.0");
req.setRequestHeader("OData-Version", "4.0");
req.setRequestHeader("Accept", "application/json");
req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
req.onreadystatechange = function() {
  if (this.readyState === 4) {
    req.onreadystatechange = null;
    if (this.status === 200) {
      var results = JSON.parse(this.response);
      for (var i = 0; i < results.value.length; i++) {
        var accountid = results.value[i]["accountid"];
        var accountnumber = results.value[i]["accountnumber"];
        var accountratingcode = results.value[i]
        ["accountratingcode"];
        var telephone1 = results.value[i]["telephone1"];
     }
   } else {
       Xrm.Utility.alertDialog(this.statusText);
     }
   }
  };
  req.send();
  The response for the above code will be as below:
  {
    "@odata.context":    "https://demoorg3.crm8.dynamics.com/api/
    data/v8.2/$metadata#accounts
    (accountid,accountnumber,accountratingcode,telephone1)",
    "value": [
    {
      "@odata.etag": "W/"671215"",
      "accountid": "9252cd68-e9e3-e711-a95e-000d3af27163",
      "accountnumber": "DR567821X",
      "accountratingcode": 1,
      "telephone1": null
   },
   {
     "@odata.etag": "W/"677922"",
     "accountid": "e771ecea-edea-e711-a95f-000d3af27534",
     "accountnumber": "DR9888900RR",
     "accountratingcode": 1,
     "telephone1": null
   },
   {
     "@odata.etag": "W/"707246"",
     "accountid": "2de6ad4f-0ef1-e711-a95e-000d3af278ae",
     "accountnumber": "AC1009348YU",
     "accountratingcode": 1,
     "telephone1": "9978759612"
   },
   {
     "@odata.etag": "W/"684666"",
     "accountid": "493d50f5-28ed-e711-a95e-000d3af27fd9",
     "accountnumber": "DR7845699AS",
     "accountratingcode": 1,
     "telephone1": null
   }
  ]
 }

这些检索到的对象可以很容易地转换为 JavaScript 对象。这些对象可以分配给 JavaScript 数组，并可用于后续操作。

更新实体记录

现在，我们将更新一个entity记录。更新记录时，你需要传递你想要更新的记录的 GUID，以及包含要更新字段的 JSON 对象。在这里，我们将更新一个账户记录的email和city：

var entity = {};
entity.emailaddress1 = "contact@shreetech.in";
entity.address1_city = "Mumbai";
var req = new XMLHttpRequest();
req.open("PATCH", Xrm.Page.context.getClientUrl() + "/api/data/v8.2/accounts(2de6ad4f-0ef1-e711-a95e-000d3af278ae)", true);
req.setRequestHeader("OData-MaxVersion", "4.0");
req.setRequestHeader("OData-Version", "4.0");
req.setRequestHeader("Accept", "application/json");
req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
req.onreadystatechange = function() {
  if (this.readyState === 4) {
    req.onreadystatechange = null;
    if (this.status === 204) {
      //Success - No Return Data - Do Something
    } else {
      Xrm.Utility.alertDialog(this.statusText);
    }
   }
 };
 req.send(JSON.stringify(entity));

删除实体记录

删除entity记录时，你需要传递要删除记录的 GUID。以下是从 Dynamics 365 删除账户entity记录的代码：

var req = new XMLHttpRequest();
req.open("DELETE", Xrm.Page.context.getClientUrl() + "/api/data/v8.2/accounts(2de6ad4f-0ef1-e711-a95e-000d3af278ae)", true);
req.setRequestHeader("Accept", "application/json");
req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
req.setRequestHeader("OData-MaxVersion", "4.0");
req.setRequestHeader("OData-Version", "4.0");
req.onreadystatechange = function () {
  if (this.readyState === 4) {
    req.onreadystatechange = null;
    if (this.status === 204 || this.status === 1223) {
      //Success - No Return Data - Do Something
    } else {
      Xrm.Utility.alertDialog(this.statusText);
    }
  }
};
req.send();

在 Dynamics 365 Web API 中进行模拟操作

当你想要代表另一个用户执行业务逻辑时，你需要使用模拟。有时候，某些流程或业务逻辑需要代表特定的 Dynamics 365 用户来执行，并且该用户拥有适当的安全角色；对于这种需求，模拟非常有用。

在代码中，当你需要代表其他用户创建记录时，你将使用此功能。为此，你需要两个用户账户。要使用模拟功能，你需要添加一个名为 MSCRMCallerID 的头部，其 GUID 值等于该用户的系统用户 ID，具体如下请求所示。

请参考以下代码：

Request
POST [Organization URI]/api/data/v9.0/contacts HTTP/1.1
MSCRMCallerID: 9ba9f608-514e-49fd-81cd-84537a31f68e
Accept: application/json
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0
{"name":"Contact created using impersonation"}

使用 Web API 获取元数据

Microsoft Dynamics 365 是一个元数据驱动的应用程序，在某些场景和特定需求中，你需要查询元数据。Dynamics 365 Web API 支持查询元数据。我们将使用EntityDefinitions实体来获取contact实体的元数据。

以下是查询元数据的请求：

GET [OrgURL]/api/data/v8.2/EntityDefinitions(LogicalName='contact')/Attributes"
Following is the Sample code for querying metadata for Contact Entity:
var req = new XMLHttpRequest();
//Opens request
req.open("GET", window.parent.Xrm.Page.context.getClientUrl() + "/api/data/v8.2/EntityDefinitions(LogicalName='contact')/Attributes", true);
//Sets request Headers
req.setRequestHeader("OData-MaxVersion", "4.0");
req.setRequestHeader("OData-Version", "4.0");
req.setRequestHeader("Accept", "application/json");
req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
req.setRequestHeader("Prefer", "odata.include-annotations="*"");
//Function to detect ready state change
req.onreadystatechange = function () {
  if (this.readyState === 4) {
    req.onreadystatechange = null;
    //Check if request completed successfully
    if (this.status === 200) {
      var result = JSON.parse(this.response);
      var index = 1;
      for (var i = 0; i < result.value.length; i++) {
        //Gets schemaname from response.
        var schemaName = result.value[i].SchemaName;
      }
    }
    else {
      Xrm.Utility.alertDialog(this.statusText);
    }
   }
 };
 req.send();
});

Dynamics 365 Web API 在 9.0 版本中的更新

现在，在 Dynamics 365 最新发布的 9.0 版本中，对于查询数据和执行各种操作，使用 Dynamics 365 Web API 进行了许多显著的变化。随着新版本的发布，我们将不再需要为使用 Web API 创建任何请求，而是直接使用内置的预定义函数来使用 Web API。

在新版本的 Dynamics 365 中使用 Web API 变得非常简单和方便。现在，Dynamics 365 引入了新的库Xrm.WebApi，并通过 Web API 执行 CRUD 操作。该库提供了执行操作的函数，接下来我们将在示例和代码中展示这些操作。

创建实体记录

这是使用Xrm.WebApi.createRecord()函数创建新联系人的示例代码：

function createContact() {
  // contact data object
  var entity = {};
  entity.firstname = "Mark";
  entity.lastname = "Andrew";
  entity.telephone1 = "7845687845";
  entity.address1_city = "California";
  // create record
  Xrm.WebApi.createRecord("contact", entity).then(
  function success(result) {
    console.log("Contact Created Successfully !!");
  },
  function (error) {
    console.log(error.message);
  }
 );
}

更新实体记录

在以下示例中，我们将通过添加一个新的email属性来更新联系人记录：

function updateContact() {
  // contact data object
  var entity = {};
  entity.emailaddress1 = "mark@gmail.com";
  //get contact id
  var contactId = "DC1F674E-55F1-E711-A95F-000D3AF27163"
  // update contact record
  Xrm.WebApi.updateRecord("contact", contactId, entity).then(
  function success(result) {
    console.log("Contact Record Updated");
  },
  function (error) {
    console.log(error.message);
  }
 );
}

删除实体记录

以下是删除联系人记录的示例代码：

function deleteContact() {
  var contactId = "DC1F674E-55F1-E711-A95F-000D3AF27163";
  Xrm.WebApi.deleteRecord("contact", contactId).then(
  function success(result) {
    console.log("Contact deleted");
  },
  function (error) {
    console.log(error.message);
  }
 );
}

检索记录

在新版本中，你可以直接使用 fetch XML 通过 Web API 从 Dynamics 365 检索多个记录。在下面的示例中，我们将使用 fetch XML 查询来获取/检索某个选定账户的联系人。以下是从 Dynamics 365 检索记录的示例代码：

function retrieveMultipleContacts(executioncontext) {
  var formContext = executioncontext.getFormContext();
  var contactId = formContext.data.entity.getId();
  var fetchContacts = "<fetch version='1.0' output-format='xml-  
  platform' mapping='logical' distinct='false'>" +
  "<entity name='contact' >" +
  "<attribute name='fullname' />" +
  "<attribute name='telephone1' />" +
  "<attribute name='contactid' />" +
  "<order attribute='fullname' descending='false' />" +
  "<filter type='and'>" +
  "<condition attribute='parentcustomerid' operator='eq'   
  uitype='account' value ='" + accountId + "' />" +
  "</filter>" +
  "</entity >" +
  "</fetch > ";
  Xrm.WebApi.retrieveMultipleRecords("contact", "fetchXml= " +    
  fetchContacts).then(
    function success(result) {
    for (var i = 0; i < result.entities.length; i++) {
      console.log(result.entities[i]);
    }
  },
   function (error) {
     console.log(error.message);
    });
  }

总结

在本章中，我们学习了如何在 Dynamics 365 Web API 中处理单页应用程序、XMLHttpRequest、Web API URL 和版本，以及标准查询选项，还学习了如何使用 Dynamics 365 Web API 进行 CRUD 操作。在下一章中，我们将介绍 Azure 与 Dynamics 365 的集成，如何配置 Azure 集成与 Dynamics 365，并编写支持 Azure 的插件和不同的监听应用程序。

第八章：利用 Dynamics 365 中的 Azure 扩展

在上一章中，我们学习了如何在 Dynamics 365 中使用新的 REST Web API 端点执行各种操作，并如何利用它来开发自定义的业务应用程序。在本章中，我们将学习 Dynamics 365 如何原生支持与 Microsoft Azure 的集成。本章假定你已经对 Microsoft Azure 的基础知识有基本的了解。

关于 Microsoft Azure 的参考资料—docs.microsoft.com/en-us/azure/fundamentals-introduction-to-azure 和 azure.microsoft.com/en-in/training/

Microsoft Azure 可以定义为一个云计算平台或一组基于云的服务，开发人员和 IT 专业人员可以通过全球各地的数据中心，使用这些服务来构建、测试、部署和管理应用程序。Microsoft Azure 提供 基础设施即服务（IaaS）、平台即服务（PaaS）和 软件即服务（SaaS）。

使用 IaaS，我们基本上是在指 Azure 虚拟机，即托管在云中的服务器。云计算服务提供商（在这里是 Microsoft）管理基础设施，而我们需要为使用这些资源付费。在这种模式下，我们拥有完全的控制权，并且负责管理操作系统、中间件以及在其上运行的应用程序。我们还可以将 Dynamics 365 部署到 Microsoft Azure 虚拟机中的本地环境。

使用 PaaS，我们可以在云中获得完整的开发和部署环境，可以用来构建、部署和管理我们的云应用程序。我们只需为使用的云服务付费。在这里，我们只管理我们的应用程序和服务，而云服务提供商管理其他一切。

使用 SaaS，我们基本上是通过互联网连接并使用软件或基于云的应用程序。在这种模式下，我们只需要为所使用的云应用程序付费。云服务提供商管理所有内容，包括底层基础设施、中间件、应用程序软件等。我们只需连接到这些应用程序，通常通过浏览器在互联网上使用它们。Dynamics 365 在线版属于 SaaS。

在本章中，我们将涵盖以下内容：

  • 理解 Azure 与 Dynamics 365 的集成

  • 配置 Azure 与 Dynamics 365 的集成

  • 编写支持 Azure 的插件和不同的监听器应用程序

理解 Azure 与 Dynamics 365 的集成

Microsoft Azure 服务总线是 Microsoft Azure Stack 中的主要组件，它使我们能够将 Dynamics 365 与 Microsoft Azure 连接。通过 Azure 服务总线，我们可以将 Dynamics 365 内部执行的操作详情传递给多个监听该信息的应用程序，并且这些应用程序可以读取和处理这些信息。

Microsoft Azure 服务总线简介

Azure Service Bus 可以定义为在微软 Azure 数据中心运行的云消息传递服务。Azure Service Bus 使我们能够连接不同的应用程序、服务或设备，这些应用程序、服务或设备可能托管在云中或防火墙内的本地网络中。它可以用于连接不同的业务线（LOB）应用程序、平板电脑、手机，甚至任何家用电器或传感器。该 Azure Service Bus 支持两种不同的通信机制：经纪人消息传递（队列、主题和订阅）和中继服务。

Azure Service Bus 的经纪人消息传递功能包括可以在微软 Azure 数据中心创建和托管的队列和主题。应用程序可以连接到创建的队列或主题，并向其发送消息。这些消息将被持久存储。接收应用程序随后可以连接到这些队列或主题，接收并处理消息。发送应用程序和接收应用程序可以托管在云中，也可以托管在本地。队列提供单向异步通信，发布者发布消息，订阅者接收消息。每条消息只会被单个订阅者接收。主题同样提供单向异步消息传递基础设施，发布者发布消息，接收者像队列一样接收消息。主要区别在于，相同的消息可以被多个订阅者接收，订阅者可以选择性地指定一些标准，使其只接收符合规定规则的消息。由于它们通过经纪人提供单向异步通信，即发送者和接收者之间没有直接连接，因此不适用于我们希望发送者和接收者交换消息或直接连接，或希望它们之间进行同步通信的场景。为了解决这个问题，Azure Service 提供了中继服务。

Azure Service Bus 的中继服务提供应用程序之间的双向同步通信能力，不同于队列和主题。中继服务允许我们在云中暴露一个端点，作为我们托管在云中或本地服务的代理。任何能够访问互联网的客户端都可以调用这个端点，这些请求将被中继回防火墙后面托管的服务或任何其他侦听消息的应用程序。这为组织提供了一种非常可靠且具有成本效益的方式来暴露服务。

Azure Service Bus 文档：docs.microsoft.com/en-us/azure/service-bus-messaging/。

理解 Dynamics 365 和 Azure Service Bus

在前一部分中，我们介绍了 Azure Service Bus 的基础知识，本部分将讨论 Dynamics 365 如何与 Azure Service Bus 集成。

下图显示了 Dynamics 365 如何与 Azure Service Bus 协作，连接到可以位于云端或托管在防火墙后面的应用程序：

以下是该过程的逐步解释：

  1. Dynamics 365 用户在 CRM 内执行操作，例如创建潜在客户记录、更新机会等。

  2. 这会触发已注册的 Azure 感知 OOB（开箱即用）插件或自定义 Azure 感知插件或工作流活动的执行，然后通知异步服务系统作业。

  3. 一旦异步服务收到通知，它会处理将请求消息的数据上下文发布到 Azure Service Bus 的过程。此发布操作通过系统作业执行。Dynamics 365 用户可以在 Dynamics 365 Web 应用中检查系统作业的状态，（设置 | 系统作业）。

  4. Microsoft Azure Service Bus 随后将执行上下文转发给 Microsoft Azure Service Bus 监听应用程序。Azure Service Bus 还负责管理授权。发布数据到 Service Bus 的 Dynamics 365 和任何读取数据的监听应用程序，都是通过访问控制服务（ACS）或共享访问签名（SAS）进行授权的。

Azure Service Bus：身份验证与授权——docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-authentication-and-authorization。

  1. 注册在 Azure Service Bus 解决方案端点上的 Microsoft Azure Service Bus 监听应用可以读取并处理 Azure Service Bus 发布的 Dynamics 365 执行上下文。

  2. 然后，Azure Service Bus 将相关系统作业的状态设置为完成。

SAS 授权在 CRM Online 2016 Update 1 中引入，并且比 ACS 性能更好。SAS 是推荐的 Dynamics 365 授权方法。有关将服务端点从 ACS 更新为 SAS 授权的内容，请参阅此处——msdn.microsoft.com/en-us/library/mt728940.aspx。

理解 Azure 感知插件

正如我们之前所见，我们可以在 Dynamics 365 中针对特定事件注册一个 Azure 感知插件，该插件将此执行上下文传递给 Azure Service Bus，然后由它将上下文转发给监听应用程序。在这里，我们可以使用 OOB Azure 感知插件，或者我们可以编写自己的自定义 Azure 感知插件或自定义工作流活动。

使用 Dynamics 365 Online Version 9.0 时，我们可以使用 Webhook 作为 Azure Service Bus 的替代方案，将关于事件的数据发送到 Web 应用程序——docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/use-webhooks。

对于 OOB Azure 感知插件，我们需要通过插件注册工具首先注册新的服务端点：

在服务端点注册中，我们需要指定一个连接到 Azure Service Bus 的地址，以便将插件事件传递给它：

服务端点包含有关 Azure Service Bus 的授权信息，如 Service Bus 命名空间地址和 SAS 密钥。成功注册后，我们可以像处理常规插件程序集一样，为已添加的服务端点添加插件步骤。

这个 Azure 感知的现成插件以完全信任模式执行。然而，现成的 Azure 感知插件存在某些限制，例如它只能异步执行，不能调用 CRM SDK 方法，也不能编写跟踪语句用于日志记录或审计目的。

除了 Dynamics 365 提供的现成的 Azure 感知插件外，我们还可以创建自定义的 Azure 感知插件或自定义工作流活动。

传递给 IPlugin Execute 方法的 IServiceProvider 包含 IServiceEndpointNotificationService 的实例。我们可以调用其 Execute 方法，将执行上下文发布到 Azure Service Bus。Execute 方法需要一个服务端点的实体引用；我们可以从插件注册工具中获取服务端点 ID。添加这段代码以调用端点通知服务，使我们的插件Azure 感知：

public class AzureAwarePlugin : IPlugin 
{ 
public void Execute(IServiceProvider serviceProvider) 
{ 
// set the Service Endpoint Id 
var serviceEndpointId = "[ServiceEndpointGuid]"; 

// Obtain the execution context from the service provider. 
IPluginExecutionContext context = (IPluginExecutionContext) 
serviceProvider.GetService(typeof(IPluginExecutionContext)); 

// Extract the notification service for posting execution context 
IServiceEndpointNotificationService notificationService = (IServiceEndpointNotificationService) 
serviceProvider.GetService(typeof(IServiceEndpointNotificationService)); 
// Call the Execute method. 
var response = notificationService.Execute(new EntityReference("serviceendpoint", 
new Guid(serviceEndpointId)), context); 
} 
}

自定义的 Azure 感知插件在沙盒中以部分信任模式执行。编写自定义插件的好处是我们可以调用 CRM SDK 方法，并且在双向中继服务的情况下，还可以接收监听应用程序的响应。此外，插件可以注册为同步或异步执行。

对于 Azure 感知插件，建议将其注册为异步执行，以获得最佳的系统性能。

了解 Dynamics 365 与 Azure 解决方案之间的不同合同

以下是在通过插件注册工具注册新服务端点时，可以定义的不同类型的合同：

队列：

对于队列合同，需要在 Azure Service Bus 中创建一个消息队列。监听应用程序等待 Service Bus 在队列中发布的消息。当队列中有消息时，监听应用程序可以读取并处理这些消息。在队列合同的情况下，监听应用程序不需要主动监听。

单向：

在单向合同的情况下，监听应用程序需要主动监听。如果没有活动的监听器，向 Service Bus 发送的请求会失败，系统作业在重试次数用尽后，其状态会被设置为“失败”。

监听应用程序需要实现IServiceEndpointPlugin接口的Execute方法，并结合WS2007HttpRelayBinding，RemoteExecutionContext由 Azure Service Bus 传递。

双向：

双向合同类似于单向合同，唯一的区别是，在双向合同中，可以将类型为字符串的消息从监听应用程序返回给发布消息到 Azure 服务总线的自定义插件工作流活动。

监听应用程序需要实现 ITwoWayServiceEndpointPlugin 接口的 Execute 方法，并配合使用 WS2007HttpRelayBinding，该绑定将 RemoteExecutionContext 从 Azure 服务总线传递过来。

REST：

REST 合同类似于双向合同。在这里，监听应用程序需要实现 IWebHttpServiceEndpointPlugin 接口的 Execute 方法，并配合使用 WebHttpRelayBinding，该绑定将 RemoteExecutionContext 从 Azure 服务总线传递过来。

主题：

主题类似于队列。然而，使用主题时，一个或多个监听器可以订阅该主题，以接收来自主题的消息。消息将经过筛选，并通过主题的相应订阅路由到订阅者。

事件中心：

Microsoft Azure 事件中心提供大规模的遥测服务。它们通常用于大规模应用程序遥测和物联网场景。多个设备或应用程序可以将遥测消息发送到事件中心。消息可以达到每秒数千或数百万条，并被读取和处理。创建事件中心解决方案应用程序类似于编写 Azure 服务总线监听应用程序。在这里，我们首先开始在 Microsoft Azure 中创建一个事件中心，就像在 Azure 服务总线中一样。接下来，我们需要在通过插件注册工具注册 Dynamics 365 服务端点时指定事件中心连接字符串。我们将在本章后面详细讨论这一点。

要为上述合同编写监听应用程序，我们需要使用 Azure SDK 版本 1.7 或更高版本—azure.microsoft.com/en-in/downloads/。

现在，既然我们已经对 Dynamics 365 中可用的 Azure 扩展有了基本了解，接下来我们将在下一部分实施一个简单的业务场景，看看它是如何运作的。

配置 Dynamics 365 与 Azure 服务总线的集成

让我们以一个简单的场景为例进行实施，这将帮助我们理解如何在 Dynamics 365 中配置 Azure 扩展，以及如何为不同的合同类型编写不同的监听应用程序。监听应用程序本质上是一个第三方应用程序，当 Dynamics 365 中发生事件时，它需要被通知。监听应用程序和 Dynamics 365 是两个独立的、断开连接的应用程序。

场景：在 Dynamics 365 中创建潜在客户记录时，将其信息（执行上下文）通过 Azure 服务总线传递给监听应用程序。然后，监听应用程序可以读取并处理该信息。

让我们详细地逐步讲解：

  1. 使用现有账户登录到 Azure 管理门户 portal.azure.com，或在 azure.microsoft.com/en-us/free/ 创建一个免费账户

  2. 在门户中搜索并添加一个新的服务总线服务。提供所需的详细信息并点击创建命名空间，以创建服务总线命名空间。必须指定的名称需要在整个数据中心内唯一。这将为服务总线命名空间创建一个 URI，可以通过它在互联网上访问服务总线。此服务总线命名空间充当通信机制的容器，如中继服务和经纪消息（队列和主题）：

  3. 接下来，我们将创建一个队列，用于将消息从 Dynamics 365 发布到该队列。打开服务总线，点击+队列按钮，创建一个包含所需详细信息的队列：

  4. 按照此处显示的详细信息提供，并点击创建按钮以创建队列：

  1. 对于创建的队列，选择共享访问策略并点击添加，创建一个新的共享访问策略。顾名思义，发送权限是将消息发送到命名空间监听器所需的权限，类似地，监听权限是监听应用程序在命名空间上开始监听所需的权限。管理权限是创建队列、删除队列、创建订阅、枚举主题、订阅等所需的权限。在这里，我们在添加 SAS 策略时选择了发送和监听复选框，因为我们将使用相同的策略同时进行发送和监听。我们也可以创建两个单独的策略，一个用于发送者，另一个用于监听应用程序。点击创建，以创建一个新的 SAS 策略：

服务总线操作（SAS）所需的权限详细信息请参见此处—docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas#rights-required-for-service-bus-operations

  1. 选择已创建的共享访问策略并复制其主连接字符串。

  2. 返回 Dynamics 365，我们需要通过插件注册工具注册一个服务端点。在插件注册工具中选择注册新服务端点。

从以下地址下载最新的 Microsoft Dynamics 365 SDK—www.microsoft.com/en-us/download/details.aspx?id=50032

  1. 将连接字符串粘贴到注册新服务端点对话框中，并点击下一步：

  2. 这会自动填充服务端点注册的详细信息。点击保存：

这将添加服务端点到插件注册工具。接下来，我们为在潜在客户实体上创建消息注册一个新步骤。设置执行模式为异步。如果我们尝试将其设置为同步模式，将会收到以下警告：只有异步步骤才支持服务端点插件，因为 OOB Azure 感知插件仅支持异步执行模式：

  1. 现在，让我们在 Dynamics 365 中创建一个潜在客户记录以触发插件：

  2. 转到设置 | 系统作业，相应的系统作业已创建，显示从异步服务发布到 Azure Service Bus 的消息状态：

  1. 返回我们的队列，我们可以看到一个新的消息已添加到 ACTIVE MESSAGE COUNT：

在下一部分，我们将创建监听应用程序来读取从 Dynamics 365 发布到 Azure Service Bus 的数据。

编写一个队列监听器

让我们创建一个简单的队列监听器来读取传递到队列的消息：

  1. 打开 Visual Studio，选择项目类型为控制台应用程序。

  2. 在项目中安装以下 NuGet 包——WindowsAzure.ServiceBus。它提供了用于 Microsoft Azure Service Bus 操作的客户端库。

  3. 添加对Microsoft.Xrm.Sdk程序集的引用，或者安装以下 NuGet 包——Microsoft.CrmSdk.Core程序集。

  4. 指定在插件注册工具中为服务端点定义的相同连接字符串。

  5. 我们需要使用连接字符串创建一个QueueClient对象，并使用接收到的BrokeredMessage获取远程执行上下文。接下来，我们从RemoteExecutionContext中检索主题字段的值、实体名称和触发插件的消息，并将其写入控制台，如下所示：

// set the connection string of the Shared Access Policy created for the Queue 
var connectionString = "Endpoint=sb://[namespace].servicebus.windows.net/;SharedAccessKeyName=[KeyName];SharedAccessKey=[KeyValue];EntityPath=[QueueName]"; 

// create the Queue Client object 
var client = QueueClient.CreateFromConnectionString(connectionString); 

while (true) 
{ 
Console.Write("Press [Enter] to retrieve a message from the queue."); 
string line = Console.ReadLine(); 
Console.WriteLine("Waiting for a message from the queue... "); 
try 
{ 
// get the message from the Queue Client 
BrokeredMessage brokeredMessage = client.Receive(); 

// if message recieved 
if (brokeredMessage != null) 
{ 
// get the Remote Execution Context passed from the Azure Service Bus 
RemoteExecutionContext context = brokeredMessage.GetBody<RemoteExecutionContext>(); 

// cast to Entity object 
Entity entity = (Entity)context.InputParameters["Target"]; 

// get the lead's topic attribute value 
var leadTopic = entity.Attributes["subject"].ToString(); 

// output to console 
Console.WriteLine(string.Format("   Entity Name = {0}, Message Name = {1}, Lead's Topic = {2}", 
context.PrimaryEntityName, context.MessageName, leadTopic)); 

// marks message as processed and deleted 
brokeredMessage.Complete(); 
} 
} 
catch (TimeoutException ex) 
{ 
Console.WriteLine(ex.Message); 
continue; 
} 
catch (FaultException ex) 
{ 
Console.WriteLine(ex.Message); 
continue; 
} 
}
  1. 运行我们的应用程序时，我们可以看到以下细节作为RemoteExecutionContext传递到队列中的输出：

该示例应用程序运行时，将读取队列中的消息并在控制台中打印详细信息。

这里，队列的消息生存时间属性定义了消息如果未处理，将在队列中保留的时间跨度。之后，它将被移除或转为死信，即移动到另一个名为死信队列的次级子队列。死信队列保存未成功投递或处理的消息。

Azure Service Bus 死信队列——docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues。

队列的 锁定持续时间 属性指定一条消息被接收者接收后会被锁定的秒数。这指定了监听器应用程序处理消息的时间。如果消息未被处理，其他接收者将可以接收该消息。

编写主题监听器

让我们继续之前的潜在客户记录创建场景，并将其更新为使用主题而不是队列：

  1. 登录 Azure 门户，通过点击 +主题来创建 Azure Service Bus 中的主题。

  2. 添加所需的详细信息并点击创建按钮：

  1. 在主题内，创建一个新的共享访问策略，并复制其主连接字符串。此连接字符串将在插件注册工具中注册新服务端点时使用，如此处所示：

  2. 向此已注册的服务端点添加一个新步骤，使其通过在 Dynamics 365 中创建潜在客户记录来触发。

  3. 现在让我们回到我们创建的主题。点击主题内的 + 订阅按钮以添加一个新订阅。按此处所示指定所需的详细信息并点击创建：

  1. 这将在主题内创建一个新订阅。我们可以创建多个订阅，每个订阅都会收到已发布到 Azure Service Bus 的消息副本。

  2. 以下是我们的主题监听器应用程序的示例代码。在这里，我们将使用一个 SubscriptionClient 对象来读取和处理传递的上下文，而不是使用 QueueClient 对象：

// set the connection string of the Shared Access Policy created for the Subscription 
// along with name of the Topic and Subscription 

var connectionString = "Endpoint=sb://[namespace].servicebus.windows.net/;SharedAccessKeyName=[KeyName];SharedAccessKey=[KeyValue];EntityPath=[TopicName]"; 

var topic = "[topic]"; 
var subscriptionName = "[subscription]"; 

// create the Subcription Client object 
var client = SubscriptionClient.CreateFromConnectionString(connectionString, topic, subscriptionName); 

while (true) 
{ 
Console.Write("Press [Enter] to retrieve a message from the topic."); 
string line = Console.ReadLine(); 
Console.WriteLine("Waiting for a message from the topic... "); 
try 
{ 
// get the message from the client 
BrokeredMessage brokeredMessage = client.Receive(); 

// get the Remote Execution Context passed from the Azure Service Bus 
RemoteExecutionContext context = brokeredMessage.GetBody<RemoteExecutionContext>(); 

// cast to Entity object 
Entity entity = (Entity)context.InputParameters["Target"]; 

// get the lead's topic attribute value 
var leadTopic = entity.Attributes["subject"].ToString(); 

// output to console 
Console.WriteLine(string.Format("  Entity Name = {0}, Message Name = {1}, Lead's Topic = {2}", 
context.PrimaryEntityName, context.MessageName, leadTopic)); 

// marks message as processed and deleted 
brokeredMessage.Complete(); 
} 
catch (TimeoutException ex) 
{ 
Console.WriteLine(ex.Message); 
continue; 
} 
catch (FaultException ex) 
{ 
Console.WriteLine(ex.Message); 
continue; 
} 
}

  1. 现在，让我们回到 Dynamics 365 并创建一个潜在客户记录，以触发我们的插件：

  2. 在我们的主题中，我们可以看到为该主题创建的所有订阅都已接收到消息：

  1. 运行我们的订阅监听器，我们得到了预期的输出：

到目前为止，我们已经涵盖了如何为队列和主题编写监听器应用程序，在下一部分中，我们将介绍如何编写单向、双向和 REST 合约的监听器应用程序。

编写单向监听器

让我们逐步了解编写单向监听器所需的所有步骤：

  1. 继续相同的场景，首先，我们需要注册我们的服务端点。为此，为 Azure Service Bus 命名空间创建一个新的共享访问策略。进入 Azure Service Bus 的共享访问策略设置，点击“添加”创建一个具有发送和监听权限的新策略，并复制其主连接字符串。

  2. 将复制的连接字符串粘贴到插件注册工具中的注册服务端点对话框中。

当我们创建一个 Azure 服务总线命名空间时，会自动创建一个名为RootManageSharedAccessKey的策略。它具有一对主密钥和副密钥，授予对服务总线命名空间的发送、监听和管理权限。建议您创建其他策略，而不是使用这个默认的具有所有权限的策略。

  1. 更新服务端点注册中的属性值，如下所示：

  • 命名空间地址：将sb替换为https

  • 指定类型：OneWay

  • 路径：MyPath

以下截图显示了已填充适当值的服务端点注册对话框：

  1. 注册一个步骤，在创建潜在客户记录时为注册的服务端点触发，并通过在 Dynamics 365 中创建潜在客户记录来触发它。

  2. 转到设置 | 系统作业并检查相应创建的系统作业。

  3. 在这里，系统作业将失败并显示以下消息：

  1. 如前所述，对于中继服务，要求有一个主动监听器，这与队列或主题不同。

  2. 在我们的单向监听器应用程序中，需要实现IServiceEndpointPlugin接口，并使用WS2007HttpRelayBinding。

  3. 在接下来的步骤中，我们将在控制台应用程序中自托管该服务：

[ServiceBehavior] 
class AzureExample : IServiceEndpointPlugin 
{ 
static void Main(string[] args) 
{ 
// get the shared access key name 
// shared access key value 
// service bus endpoint from the Shared Access Policy Connection String. 
var sharedAccessKeyName = "[keyName]"; 
var sharedAccessKey = "[keyValue]"; 
var serviceBusEndPoint = "https://[serviceBusNameSpace].servicebus.windows.net"; 

// initialize the ServiceHost 
var serviceHost = new ServiceHost(typeof(AzureExample)); 

// define the behaviour 
var transportClient = new TransportClientEndpointBehavior 
(TokenProvider.CreateSharedAccessSignatureTokenProvider(sharedAccessKeyName, sharedAccessKey)); 

// add the service endpoint 
serviceHost.AddServiceEndpoint(typeof(IServiceEndpointPlugin), 
new WS2007HttpRelayBinding(), serviceBusEndPoint).EndpointBehaviors.Add(transportClient); 

serviceHost.Open(); 

Console.ReadLine(); 
} 

void IServiceEndpointPlugin.Execute(RemoteExecutionContext context) 
{ 
// cast to Entity object 
Entity entity = (Entity)context.InputParameters["Target"]; 

// get the lead's topic attribute value 
var leadTopic = entity.Attributes["subject"].ToString(); 

// output to console 
Console.WriteLine(string.Format("  Entity Name = {0}, Message Name = {1}, Lead's Topic = {2}", 
context.PrimaryEntityName, context.MessageName, leadTopic)); 
} 
}
  1. 运行监听器应用程序，使其能够主动监听传递给它的消息，并在 Dynamics 365 中创建潜在客户记录。这将触发我们监听器应用程序中的Execute方法，并在控制台窗口中输出远程执行上下文的详细信息。

在这一部分中，我们学习了如何编写单向监听器，在下一部分我们将介绍如何编写双向监听器应用程序。

编写双向监听器和 Azure 感知插件

让我们详细地走一遍编写双向监听器的所有步骤：

  1. 在双向合同的情况下，我们需要实现一个自定义的 Azure 感知插件，该插件可以接收来自双向监听器应用程序的响应，但在此之前，我们先注册一个新的服务端点用于双向合同，如下所示：

  2. 双向监听器应用程序需要实现ITwoWayServiceEndPointPlugin接口，并使用WS2007HttpRelayBinding。此外，Execute方法返回一个字符串，启用双向通信。如前所述，使用中继时是实时的，因此监听器需要主动监听消息，不同于队列和主题。

  3. 在接下来的步骤中，我们将在控制台应用程序中自托管该服务：

[ServiceBehavior] 
class AzureExample : ITwoWayServiceEndpointPlugin 
    { 
        static void Main(string[] args) 
        { 
            // get the shared access key name 
            // shared access key value 
            // service bus endpoint from the Shared Access Policy 
            Connection String. 
            var sharedAccessKeyName = "RootManageSharedAccessKey"; 
            var sharedAccessKey = "[KeyValue]"; 
            var serviceBusEndPoint =  
           "https://[ServiceBusNamespace].servicebus.windows.net"; 

            // initialize the ServiceHost  
            var serviceHost = new ServiceHost(typeof(AzureExample)); 

            // define the behaviour 
            var transportClient = new
            TransportClientEndpointBehavior 

        (TokenProvider.CreateSharedAccessSignatureTokenProvider
        (sharedAccessKeyName,  
          sharedAccessKey)); 

            // add the service endpoint 
            serviceHost.AddServiceEndpoint
           (typeof(ITwoWayServiceEndpointPlugin), 
                new WS2007HttpRelayBinding(),  
                serviceBusEndPoint).EndpointBehaviors.
                Add(transportClient); 

            serviceHost.Open(); 

            Console.ReadLine(); 
        }        

        string ITwoWayServiceEndpointPlugin.Execute
        (RemoteExecutionContext context) 
        { 
            // cast to Entity object 
            Entity entity =  
            (Entity)context.InputParameters["Target"]; 

            // get the lead's topic attribute value 
            var leadTopic = entity.Attributes["subject"].ToString(); 

            // output to console 
            Console.WriteLine(string.Format
            ("  Entity Name = {0}, Message Name = 
            {1}, 
            Lead's Topic = {2}", 
                context.PrimaryEntityName, 
               context.MessageName, leadTopic)); 

            // return the message back to the
            custom azure aware plugin 
            return "Message Processed"; 
        } 
    }

  1. 为了读取双向中继中从监听器应用程序返回的消息，让我们编写一个自定义的 Azure 感知插件。

  2. 我们在这里需要的第一件事是我们注册的服务端点的 GUID。我们可以从服务端点的属性窗口中获取 GUID，ServiceEndpointId，如下所示：

  1. 在这里，IServiceEndpointNotificationService将为我们提供服务端点，我们将其服务端点实体引用传递给它。

  2. 我们需要调用通知服务的Execute方法，将执行上下文发送到 Azure Service Bus。Execute方法返回从监听器应用程序接收到的响应，然后我们使用ITracingService在自定义的 Azure 感知插件中进行跟踪：

public class AzureAwarePlugin : IPlugin 
    { 
        public void Execute(IServiceProvider serviceProvider) 
        { 
            // set the Service Endpoint Id 
            var serviceEndpointId = "[serviceEndpointGUID]"; 

            // Obtain the execution context from 
            the service provider. 
            IPluginExecutionContext context = 
           (IPluginExecutionContext) 
                serviceProvider.GetService
                 (typeof(IPluginExecutionContext)); 

            //Extract the tracing service for use in debugging 
           sandboxed plug-ins. 
            ITracingService tracingService = 

          (ITracingService)serviceProvider.GetService
         (typeof(ITracingService)); 

            // Extract the notification service for posting 
            execution context 
            IServiceEndpointNotificationService 
            notificationService =  
           (IServiceEndpointNotificationService) 

           serviceProvider.GetService(typeof
          (IServiceEndpointNotificationService)); 

            var response = notificationService.Execute(new 
          EntityReference("serviceendpoint", new 
           Guid(serviceEndpointId)), context); 

            if (!string.IsNullOrEmpty(response)) 
            { 
                tracingService.Trace("Response = {0}", response); 
            } 
        } 
    }

  1. 注册插件并为潜在客户创建消息添加一个新的步骤。与 OOB Azure 感知插件不同，自定义的 Azure 感知插件可以注册为同步。

  2. 创建一个潜在客户记录以触发插件。确保我们的双向监听器应用程序正在运行并准备好接收消息。

  3. 听众应用程序在成功接收到来自 Azure Service Bus 传递的上下文后，返回字符串“Message Processed”。

  4. 在 Dynamics 365 中，转到设置 | 插件跟踪日志进行验证：

要启用插件跟踪日志的日志记录，请转到设置 | 系统设置 | 自定义选项卡。选择所有选项以启用插件跟踪日志字段的日志记录。

在接下来的部分中，我们将介绍如何编写 REST 监听器应用程序，这与双向监听器应用程序类似，主要区别在于它使用 REST 端点。

编写 REST 监听器

让我们详细介绍编写双向 REST 监听器的所有步骤。由于它使用 REST 端点，它允许我们在 Node.js 中创建一个中继服务，并可以在多个平台（如 macOS、Windows、Linux 等）上执行：

  1. 在编写 REST 监听器之前，我们首先按照下图所示注册一个新的服务端点：

  2. REST 监听器需要实现IWebHttpServiceEndpointPlugin接口并使用WebHttpRelayBinding。在这里，我们再次在控制台应用程序中自托管该服务：

[ServiceBehavior] 
  class AzureExample : IWebHttpServiceEndpointPlugin 
    { 
        static void Main(string[] args) 
        { 
            // get the shared access key name 
            // shared access key value 
            // service bus endpoint from the Shared 
           Access Policy Connection String. 
            var sharedAccessKeyName = "RootManageSharedAccessKey"; 
            var sharedAccessKey = "[KeyValue]"; 
            var serviceBusEndPoint = 
            "https://[ServiceBusNamespace].servicebus.windows.net"; 

            // Create the service host for 
           Azure to post messages to. 
            var serviceHost = new 
           WebServiceHost(typeof(AzureExample)); 

            // define the behaviour 
            var transportClient = new 
            TransportClientEndpointBehavior 

        (TokenProvider.CreateSharedAccessSignatureTokenProvider
        (sharedAccessKeyName,  
           sharedAccessKey)); 

            // Using an HTTP binding instead of a 
            SOAP binding for this RESTful 
             endpoint. 
            WebHttpRelayBinding binding = new WebHttpRelayBinding(); 
            binding.Security.Mode = 
            EndToEndWebHttpSecurityMode.Transport; 

            // add the service endpoint 
            serviceHost.AddServiceEndpoint
             (typeof(IWebHttpServiceEndpointPlugin), 
               binding, serviceBusEndPoint).
              EndpointBehaviors.Add(transportClient); 

            // Begin listening for messages posted to Azure. 
            serviceHost.Open();            

            Console.ReadLine(); 
        } 

        string IWebHttpServiceEndpointPlugin.
         Execute(RemoteExecutionContext context) 
        { 
            // cast to Entity object 
            Entity entity = 
            (Entity)context.InputParameters["Target"]; 

            // get the lead's topic attribute value 
            var leadTopic = entity.Attributes["subject"].ToString(); 

            // output to console 
            Console.WriteLine(string.Format
            ("  Entity Name = {0}, Message Name = 
             {1}, 
             Lead's Topic = {2}", 
                context.PrimaryEntityName, 
                context.MessageName, leadTopic)); 

            // return the message back to the 
            custom azure aware plugin 
            return "Message Processed by Rest Listener"; 
        } 

    }
  1. 返回 Dynamics 365，创建一个潜在客户记录以触发插件，该插件调用监听器应用程序的Execute方法。监听器接收到消息后，返回字符串“Message Processed by Rest Listener”，该信息将在插件的插件跟踪日志中被追踪，如下所示：

在本节中，我们学习了如何编写 REST 监听器，在接下来的部分中，我们将介绍如何编写事件中心监听器应用程序。

编写事件中心监听器

让我们详细介绍编写事件中心监听器的所有步骤。要创建事件中心监听器：

  1. 转到 Azure 门户，搜索事件中心，并创建一个新的事件中心命名空间。

  2. 在事件中心命名空间中选择事件中心，然后点击“添加事件中心”以创建一个新的事件中心。

  3. 对于创建的事件中心，添加一个新的SharedAccessKey，并为其分配适当的权限，复制其连接字符串，并在插件注册工具中注册新的服务端点时使用，如下所示：

  1. 添加一个步骤，以便在创建潜在客户记录时触发插件。

  2. 对于事件中心监听器应用程序，创建一个新的控制台应用程序，添加以下 NuGet 包——WindowsAzure.ServiceBus。

  3. 以下是我们事件中心监听器应用程序的示例代码。在这里，我们使用 EventHubClient 对象来创建接收器：

var connectionString = "Endpoint=sb://[namespace].servicebus.windows.net/;SharedAccessKeyName=[KeyName];SharedAccessKey=[KeyValue];EntityPath=[QueueName]"; 

// create the Event Hub Client object 
var client = EventHubClient.CreateFromConnectionString(connectionString); 

// create the event hub reciever 
EventHubConsumerGroup consumerGroup = client.GetDefaultConsumerGroup(); 
var eventHubReciever = consumerGroup.CreateReceiver(client.GetRuntimeInformation().PartitionIds[0]); 

while (true) 
{ 
Console.Write("Press [Enter] to retrieve a message from the Event Hub."); 
string line = Console.ReadLine(); 
Console.WriteLine("Waiting for a message from the eventhub... "); 

// call the Recieve method 
var message = eventHubReciever.Receive(); 

// get the JSON result 
string jsonResult = Encoding.UTF8.GetString(message.GetBytes()); 
// output to window 
Console.WriteLine("JSON Output" + jsonResult); 
}

  1. 在 Dynamics 365 中创建一个新的潜在客户。

  2. 运行我们的事件中心监听器时，我们可以在控制台中看到预期的 JSON 输出：

接收事件的推荐方式是使用事件处理器主机—docs.microsoft.com/en-us/azure/event-hubs/event-hubs-dotnet-standard-api-overview#event-processor-host-apis。 （本章的源代码包括使用事件处理器接收事件的示例。）

总结

本章我们讲解了 Dynamics 365 中提供的 Azure 扩展以及如何配置和编写监听应用程序来支持不同的合同类型。

在下一章中，我们将介绍 CRM 2016 引入的新可编辑网格及其支持的不同属性。

第九章：在应用程序中使用可编辑网格

Dynamics 365 中的可编辑网格功能允许最终用户直接从视图或网格更新记录，这使得更新记录更加方便和简便。虽然也可以使用 Excel 表格执行相同的任务，但使用 Excel 表格更新数据比从网格编辑记录花费更多时间。

在本章中，我们将讨论与可编辑网格相关的以下要点：

  • 可编辑网格概述

  • 配置可编辑网格所需的先决权限

  • 支持的实体、视图和字段到可编辑网格

  • 配置可编辑网格所需的步骤

  • 使用 JavaScript 配置可编辑网格

  • 使用业务规则配置可编辑网格

  • 移动设备上的可编辑网格

Dynamics 365 中的可编辑网格概述

可编辑网格支持多种功能。以下列表概述了可编辑网格支持的主要 CRM 组件：

  • 实体或子网格级别的记录编辑

  • 个人视图以及系统视图

  • 移动客户端

  • 支持键盘或鼠标导航

  • 记录分组和排序

  • 记录筛选

  • 网格列的移动和调整大小

  • 分页（支持带有多个记录的子网格以适应网格视图）

  • 将分组、排序、筛选、分页、列移动和调整大小等更改保存到另一个会话中

  • 查找字段

  • 汇总字段和计算字段

  • 安全角色

  • JavaScript 事件

  • 业务规则

  • 使用图表和搜索的最终用户也可以通过只读网格访问操作栏

配置可编辑网格所需的先决条件和安全权限

在讨论如何在 Dynamics 365 中配置可编辑网格之前，了解配置可编辑网格所需的先决安全权限非常重要，这些权限是特定用户在能够配置可编辑网格之前所需的。下表总结了配置 Dynamics 365 可编辑网格所需的最低权限：

序号 实体名称 读取 写入 创建
1. 解决方案 是 - -
2. 自定义 是 是 -

通过 CRM 屏幕详细了解安全角色区域，如下所示：

  1. 导航到 设置 | 安全角色 并更新自定义的读取和写入权限，如下图所示：

  1. 导航到 设置 | 安全角色 并更新解决方案的读取和写入权限，如下图所示：

注意： 系统管理员和系统定制者角色已经具备配置 Dynamics 365 可编辑网格所需的权限。如果需要其他安全角色访问创建或编辑 Dynamics 365 可编辑网格，则需要配置上述安全权限。

可编辑网格支持的实体和视图

大多数开箱即用的实体、视图等支持可编辑网格；然而，某些实体和视图在 Dynamics 365 中不支持可编辑网格。

如果您想为实体配置可编辑网格，需满足一些条件。配置可编辑网格时需满足下列条件：

  • 实体是可定制的

  • 实体应为引用或自定义实体

  • 实体不应是子实体

可编辑子网格支持 Dynamics 365 中的所有视图类型，除了汇总视图和关联视图。

下列部分概述了基于平台（Web/平板/手机）支持的可编辑网格实体列表。

开箱即用的支持实体

Web/平板/手机

下表列出了支持 Web、平板和手机用户界面的实体：

账户 案例 知识文章视图 评级模型
预约 类别 知识库记录 评级值
可预定资源 特征 潜在客户 SLA KPI 实例
可预定资源预订 竞争对手 商机 社交活动
可预定资源预订头 联系人 订单 社交资料
可预定资源类别 电子邮件 电话呼叫 同步错误
可预定资源类别关联 权限 价格清单 任务
可预定资源特征 反馈 产品 团队
可预定资源组 发票 队列 用户
预订状态 知识文章 报价 -

仅限平板/手机

下表列出了支持 Dynamics 365 平板和手机用户界面的实体：

活动 电子邮件模板 备注 流程
附件 过期流程 商机产品 队列项
渠道访问配置文件规则项 发票产品 商机销售流程 报价产品
竞争对手地址 知识文章事件 订单产品 Sharepoint 文档
连接 潜在客户到商机销售 组织 翻译流程
连接角色 邮箱 电话到案例流程 -
电子邮件签名 新流程 价格清单项 -

仅限 Web

下表列出了支持 Web 用户界面的实体：

活动 渠道访问配置文件规则 传真 快速活动
活动活动 合同 信函 定期预约
活动响应 权限模板 营销列表 销售文献
渠道访问配置文件 外部方 职位 SLA

可编辑网格支持的和不支持的数据类型

可编辑网格支持 Dynamics 365 中大多数字段类型。下列字段类型支持可编辑网格：

  • 单行文本

  • 多行文本

  • 选项集

  • 多选项集

  • 两个选项

  • 状态原因

  • 整数

  • 浮动小数

  • 小数

  • 货币

  • 日期和时间

  • 图像

下列字段类型不支持在可编辑网格中使用：

  • 状态

  • 客户类型字段

  • 复合字段

  • 方列表

  • 基于查找字段的相关实体字段

配置主实体视图的可编辑网格

现在我们已经对支持的实体、视图和字段类型有了基本了解，接下来我们将看看如何为实体配置可编辑网格。

让我们以“帐户实体”的视图为例。当为任何实体配置可编辑网格时，所有可用的视图都将变得可编辑。

以下是配置 Dynamics 365 中帐户实体可编辑网格的步骤：

  1. 转到设置 | 自定义，如下面的截图所示：

  1. 选择“自定义系统”，如下面的截图所示：

  1. 选择帐户实体，如下面的截图所示：

  1. 选择“控件”，然后点击“添加控件...”，如下面的截图所示：

  1. 在“添加控件”对话框中，选择“可编辑网格”，然后点击“添加”按钮，如下面的截图所示：

  1. 在添加的“可编辑网格”行中，选择要应用网格的表单类型。这将使可编辑网格成为所选表单类型的默认控件。在此示例中，我们选择的是“Web”选项：

  1. 现在，保存更改并发布，如下面的截图所示：

  1. 要查看更改，导航到帐户实体。点击当前视图中的任何实体行，并尝试编辑“地址”字段：

  1. 编辑完字段后，点击保存按钮，将您的更改保存到帐户实体记录中。

配置表单的可编辑子网格

可编辑网格还可以配置为 Dynamics 365 实体表单中的子网格。可编辑网格使得从父实体表单编辑相关记录变得更加方便。例如，用户可以在帐户实体表单上，更新其中的相关联系人。

在这里，我们将在帐户实体表单上创建一个可编辑的联系人子网格。以下步骤将使帐户实体的联系人子网格可供用户编辑：

  1. 转到设置 | 自定义，如下面的截图所示：

  1. 点击“自定义系统”，如下面的截图所示：

  1. 点击“帐户”实体，然后选择“表单”，如下面的截图所示：

  1. 选择帐户的主表单并打开它：

  1. 选择适当的联系人子网格，然后点击功能区上的“更改属性”：

  1. 在设置属性对话框中，选择“控件”，点击“添加控件”，然后按照前面列出的步骤操作：

  1. 在添加控件对话框中，选择“可编辑网格”：

  1. 选择网页选项以启用子网格，然后点击“确定”按钮。保存表单如下所示：

  1. 保存后，发布它：

  1. 要查看更改，请进入一个帐户记录并检查联系人子网格：

在可编辑网格中使用 JavaScript

JavaScript 在 Dynamics 365 中用于提供客户端验证以及其他客户端需求。可编辑网格也支持 JavaScript。可编辑网格支持三种类型的事件，以下是这些事件：

  • OnRecordSelect – 该事件在用户选择可编辑网格中的记录时触发

  • OnChange – 该事件在可编辑网格实体行的任何列发生变化时触发

  • OnSave – 该事件由保存按钮触发

以下是使用 JavaScript 与可编辑网格结合的简要示例：

以下是一个场景，我们将在机会的可编辑网格中实现：

  • 如果概率大于 70%，则将机会的评级设置为热

  • 如果概率介于 50%到 69%之间，则将评级设置为温暖

  • 如果概率低于 50%，则将评级设置为冷

前提条件：要开始处理此示例，首先将“评分”和“概率”这两个额外字段添加到机会实体的任意视图中。同时，按照本章前面说明的步骤，将机会实体的主网格配置为可编辑网格。

  1. 创建一个新的 JavaScript Web 资源 OpportunitySetRating，并在其中使用以下代码：
    function OpportunitySetRating(executionContext) { 
      //Get opportunity entity 
      var OpportunityObject =   
       executionContext.getFormContext().data.entity; 
      //Get Attributes from Opportunity record 
      var probablityAttribute = 
       OpportunityObject.attributes.getByName("closeprobability"); 
      var ratingAttribute = 
       OpportunityObject.attributes.getByName("opportunityratingcode"); 
      //Rating options 
      var hotRatingOption = 1; 
      var warmRatingOption = 2; 
      var coldRatingOption = 3; 
      //Check Probability attribute contain data 
      if (probablityAttribute != null) { 
        //Check probablityValue attribute contain data 
        var probablityValue = probablityAttribute.getValue(); 

        // Check Probability Value 
        if (probablityValue < 50) { 
            ratingAttribute.setValue(coldRatingOption); 
        } 
        else 
            if (probablityValue > 50 && probablityValue < 70) { 
                ratingAttribute.setValue(warmRatingOption); 
            } 
            else 
                if (probablityValue > 70) { 
                    ratingAttribute.setValue(hotRatingOption); 
                } 
        // End of if else 
      } 
    }
  1. 在启用机会实体的可编辑网格后（如前所述为前提条件），点击实体自定义设置中的事件选项卡：

  1. 将新创建的 JavaScript Web 资源添加到表单库：

  1. 在事件处理程序中，选择字段为“概率”，并选择事件OnChange（类似地，如果需要，你可以选择 OnSave 和 OnRecordSelect 的处理程序。当前示例中不使用它们）：

  1. 为事件设置事件处理程序属性，设置为 OpportunitySetRating（提及 JavaScript Web 资源中的函数名称）：

  1. 最后，保存更改并发布所有自定义设置：

保存并发布

  1. 现在，导航到机会实体并选择您已添加了评级和概率字段的视图。当您更改概率的值时，您会注意到评级字段的变化：

可编辑网格和业务规则

在 Dynamics 365 中，业务规则提供了一种便捷的方式来对实体字段应用验证。业务流程将在更改字段值时触发，以执行指定的操作。可编辑网格支持 Dynamics 365 中的业务规则。可编辑网格支持以下业务规则操作：

  • 显示错误信息

  • 设置字段值

  • 设置业务必填

  • 设置默认值

  • 锁定或解锁字段

要在可编辑网格上使用业务规则，无需做更多配置。您可以通过在表单级别创建一个简单的业务规则来实现。当您在可编辑网格上更改记录的数据时，这个业务规则将会生效。

我们将创建一个简单的业务规则，如果首选联系方式为电话，则解锁主要电话字段，否则锁定该字段。以下是将业务规则应用于可编辑网格的步骤：

  1. 转到设置 | 自定义，如以下截图所示：

  1. 点击自定义系统，如以下截图所示：

  1. 现在，展开账户实体并点击视图，如以下截图所示：

  1. 选择所有账户视图并添加两个列：

1. 首选联系方式

2. 主要电话

这在以下截图中演示：

  1. 现在创建一个新的业务规则，如前所述。添加一个条件，检查首选联系方式的值是否为电话，然后添加一个锁定/解锁规则，解锁主要电话，否则在 else 条件中设置锁定/解锁规则来锁定主要电话：

  1. 完成上述步骤后，将业务规则的范围设置为实体：

  1. 保存并激活业务规则，并确保发布您之前所做的所有更改。

  2. 现在，导航到账户实体并选择所有账户视图。您会注意到视图中的字段现在更改了首选方法字段的值，并检查结果：

移动设备上的可编辑网格

可编辑网格在移动设备上受到支持，这使得可编辑网格非常有用，因为它们节省了用户在移动设备上的时间和数据。还有一些功能仅在移动设备上受到支持。主要的不同之处是，可编辑网格可在移动设备的仪表板上使用，而在网页上不可用。这使得可编辑网格在移动设备上成为一个更强大的功能。

让我们将“活动案例”视图设为可编辑，该视图在移动设备的仪表板上可用。

以下是让可编辑网格在移动设备的仪表板上显示的步骤：

  1. 转到“设置 | 自定义”，如以下截图所示：

  1. 单击“自定义系统”，如以下截图所示：

  1. 展开实体并选择“案例”实体。在案例实体上添加一个可编辑网格控件，并确保它在手机上也可用：

控件标签下的可编辑网格

  1. 保存并发布你所做的更改：

保存并发布

  1. 要查看结果，请打开 Dynamics 365 移动应用并导航到“案例”：

  1. 当“案例”记录出现在屏幕上时，选择记录并编辑记录主题，如下所示：

概要

在本章中，我们已看到可编辑网格的功能，它们在网页和移动平台上均受支持。我们还讨论了支持和不支持的实体、视图和字段，这些内容支持可编辑网格。

在下一章中，我们将学习如何配置 Microsoft 认知服务。

第十章：配置微软认知服务

在第九章，在应用程序中使用可编辑网格，我们学习了如何配置可编辑网格以及如何利用网格支持的不同方法和事件。在本章中，我们将探讨微软认知服务，以及如何将它们与 Dynamics 365 集成。微软认知服务是一组 API，可以用来将人工智能功能添加到应用程序中。

微软认知服务与 Dynamics 365 的集成仍处于公开预览阶段，仅适用于美国（US）区域的实例。

本章将涵盖以下内容：

  • 微软认知服务概述

  • 将 Dynamics 365 与微软认知服务连接

  • 实现文本分析 API，用于建议知识文章、类似案例和文档建议

了解微软认知服务

微软认知服务可以定义为一组 API，这些 API 可以轻松配置和使用，将强大的人工智能功能带入应用程序、网站和机器人中。微软认知服务是基于 JSON 的标准 REST API，可以从许多流行的编程语言（如 Curl、C#、Java、JavaScript、PHP、Python 等）中进行调用。早在 2015 年，微软发布了一套名为 Project Oxford 的技术，允许开发人员构建更智能的应用程序，整合机器学习方面的功能，后来这些技术被重新命名为微软认知服务。目前，微软认知服务包含不同的 API，如计算机视觉 API、视频 API、Bing 语音 API、文本分析 API、推荐 API、Bing 图像搜索 API 等等，按视觉、语音、语言、知识和语音等类别进行分类。

可以在 azure.microsoft.com/en-in/services/cognitive-services/directory/ 查阅不同的微软认知服务 API 列表。

让我们快速了解这些不同的 API：

  • 视觉 API：这些 API 允许应用程序识别面部、情绪，并理解图像和视频。它包括计算机视觉 API、视频 API、面部 API、情绪 API 等等。要查看面部 API 的实际应用，我们可以访问 azure.microsoft.com/en-us/services/cognitive-services/face/，提交一张图片，面部 API 将分析这张图片，并以 JSON 格式返回结果，如下截图所示，在检测结果中：

  • 语音 API：这些 API 允许应用程序识别语音，将语音转换为文本，并将文本转换为语音。它包括语音识别 API 和文本转语音 API。要查看语音 API 的实际应用，请浏览 azure.microsoft.com/en-us/services/cognitive-services/speech/ 并播放任何示例或开始录音。语音识别 API 会将口语转换为文本，如下所示：

  • 语言 API：这些 API 允许应用程序评估情感和话题，了解用户需求，检测并修正拼写错误等功能。它包括文本分析 API、翻译文本 API、Bing 拼写检查 API 等。要查看拼写检查功能的实际应用，请浏览 azure.microsoft.com/en-us/services/cognitive-services/spell-check/。在输入 Spell 错误为 Spel 并点击提交后，它会自动更正为 Spell，如下图所示：

  • 知识 API：这使得应用程序可以根据客户的需求、决策能力以及与来自网络、学术等丰富知识库的集成，提供推荐。它包括推荐 API、问答生成器 API、学术知识 API 等。组织可以使用推荐 API 来了解销售行为，并在客户购买时推荐相关产品，从而实现销售增长。要查看问答生成器 API 的实际应用，请浏览 azure.microsoft.com/en-us/services/cognitive-services/qna-maker/ 并搜索特定的关键词。搜索 Login 会匹配到问题 如何登录到问答生成器门户？ 并返回适当的答案，如下图所示：

  • 搜索 API：通过这个 API，应用程序可以访问网页、图片、视频、新闻等，并利用 Bing API 的自动建议功能。它包括 Bing 自动建议 API、Bing 图片搜索 API、Bing 新闻搜索 API、Bing 网页搜索 API 等。要查看 Bing 新闻搜索 API 的实际应用，请浏览 azure.microsoft.com/en-us/services/cognitive-services/bing-news-search-api/ 并搜索 Dynamics 365。Bing 新闻搜索 API 将返回与 Dynamics 365 相关的所有新闻，如下图所示：

关于 Cognitive Services 的文档、快速入门、教程和示例，请访问 docs.microsoft.com/en-us/azure/#pivot=products&panel=cognitive

启用 Dynamics 365 Microsoft Cognitive Services 集成

Microsoft Dynamics 365 的 Cognitive Services 集成在 2016 年 12 月的更新中引入，适用于 Dynamics 365 Online。跨售产品推荐预览和使用 Text Analytics Topic Detection API 的案例主题分析预览在 2016 年 12 月更新中引入，但在 2017 年 7 月的 Dynamics 365 更新中已不再提供。

Microsoft 建议使用产品关系来进行跨售产品推荐，而不是推荐 API，因为该功能将在 2018 年 2 月 15 日后被移除。www.microsoft.com/en-US/dynamics/crm-customer-center/define-related-products-to-increase-chances-of-sales.aspx

要在 Dynamics 365 中启用 Microsoft Cognitive Services 集成：

  1. 打开 Dynamics 365，转到“设置”|“管理”

  2. 点击“系统设置”，打开“预览”选项卡

  3. 在“案例主题分析”、“建议相似案例”和“建议知识文章”部分下，选择启用 Dynamics 365 Text Analytics 预览

  1. 在 Text Analytics 预览确认对话框中选择“确定”，以同意将数据与 Azure 机器学习 Text Analytics API 共享

现在，在我们已启用 CRM 中的功能后，接下来的部分将介绍如何将 Text Analytics API 与 Dynamics 365 连接。

将 Text Analytics API 与 Dynamics 365 连接

要将 Dynamics 365 与 Cognitive Services 连接：

  1. 转到“设置”|“管理”，选择 Azure 机器学习 Text Analytics 服务配置

  2. 点击“继续”以同意共享数据

  3. 配置 Text Analytics 连接时，我们需要 Azure 服务 URL 和 Azure 帐户密钥

  4. 使用现有帐户登录 Azure 门户 azure.microsoft.com/en-us/free/ 或设置免费试用 azure.microsoft.com/en-us/free/

  5. 点击“创建”，在 AI + Cognitive Services 下创建新的 Text Analytics API 服务

  1. 提供所需的详细信息，如名称、订阅、位置、定价和资源组。勾选确认框并点击“创建”：

  1. 打开创建的 Text Analytics API，转到“概览”部分并复制终结点

  1. 同样，转到“密钥”部分，在“资源管理”下，复制密钥的值

  2. 将 Azure 服务 URL 和 Azure 账户密钥字段的值粘贴到 Dynamics 365 中的文本分析连接内，并点击测试连接按钮验证连接。成功验证后，最后连接状态字段将显示为成功。点击激活以启用连接，如下图所示：

在本节中，我们成功将文本分析 API 与 Dynamics 365 连接。在下一节中，我们将看到如何利用文本分析 API 向用户推荐类似的知识库文章。

配置 Dynamics 365 中的知识库建议

通过知识库建议，Dynamics 365 可以向用户推荐与用户正在处理的案例相关的相似知识库文章。这可以帮助用户快速解决案例，从而提高客户满意度。

要启用知识库建议，首先，我们需要在 Dynamics 365 中设置知识搜索字段：

  1. 转到设置 | 服务管理并选择知识搜索字段设置。

  2. 点击新建创建一个知识搜索模型，如下图所示：

  1. 对于知识搜索模型记录：

    • 名称：名称指定模型的名称。

    • 源实体：源实体指定启用文本搜索规则的实体，以查找匹配的记录。默认情况下，我们可以选择案例实体。要为其他实体启用它，我们需要打开该实体进行自定义，并在通信与协作下启用知识管理。在下图中，我们可以看到我们已为潜在客户实体启用了知识管理：

    • 最大关键短语数：指定考虑的最大关键短语数量。允许的值在 0 到 1,000 之间。

    • 描述：指定该模型的可选描述。

  1. 创建模型后，接下来我们需要定义用于关键词或关键短语判定的字段。在这里，我们已经在案例实体的案例标题字段上定义了一个文本分析实体映射记录，如下图所示：

  1. 对于文本分析实体映射记录：

    • 实体名称：指定启用知识管理的源实体。在这里可以选择活动实体和与源实体具有1 - N或N - 1关系的实体。

    • 字段名称：指定选定实体的单行文本、多行文本和选项集字段，以查找匹配的知识库记录。

  2. 点击 ACTIVATE 启用模型，如下图所示：

  1. 更新案例表单以添加知识库建议。启用“开启自动建议”，并在“使用文本分析提供知识库（KB）建议”字段中选择文本分析，如下图所示：

  1. 点击“确定”关闭属性对话框，然后点击“保存并发布”表单。

  2. 要查看实际效果，打开任意案例记录，然后进入 KB 记录。在这里，根据案例标题——例如“需要帮助解决 3D 打印机组件问题”，点击“KB 记录”标签会显示与案例标题匹配的相应知识库文章，如下图所示：

同样，我们可以根据“主题”字段（作为关键词或关键短语的确定字段），为 Lead 实体（或任何启用知识管理的其他实体）定义模型，并可以自定义 Lead 来包括 KB 记录建议。根据“主题”（例如，Audio），KB 记录会建议一个标题中包含 Audio 的 KB 文章，如下图所示：

在本节中，我们介绍了配置知识库建议，接下来我们将学习如何配置 Dynamics 365 进行相似记录建议。

配置 Dynamics 365 中的相似记录建议

通过相似记录建议，用户在 Dynamics 365 中处理特定记录时，可以快速找到相似记录，并利用这些信息更好地服务客户。例如，在处理一个案例时，用户可以找到相似的案例，并使用这些相似案例中的信息来解决当前案例。

配置 Dynamics 365 中的相似记录建议：

  1. 将文本分析连接与 Dynamics 365 连接，我们之前已经完成了此操作

  2. 在 Dynamics 365 中，进入“设置”|“数据管理”，选择“相似记录建议设置”。

  3. 为案例实体创建一个新的高级相似性规则，如下图所示：

在“高级相似性规则”记录中：

    • 名称：指定规则的名称。

    • 来源实体：指定正在配置规则的实体。它支持 Lead、Opportunity、Contact、Account、Case 或与这些实体具有 N - N 关系的自定义实体。

    • 描述：指定规则的可选描述。

    • 使用文本分析进行目标匹配：指定是否使用文本分析服务或 Dynamics 365 进行关键词匹配。

    • 按状态筛选结果：指定结果的筛选标准。对于案例，可以是“活动中”、“已解决”和“已取消”。

    • 关键词最大数量：指定在执行文本搜索时要考虑的最大关键词数。允许的值为 0 到 1,000 之间。

  1. 创建相似性规则后，我们需要定义匹配将基于的字段，并进行建议。创建一个新的案例记录匹配字段，如下所示，在案例标题字段上：

在文本分析实体映射记录中：

以下是可以定义的两种条件类型：

    • 文本匹配：指定案例标题字段中的文本将用于查找关键短语或关键词进行匹配。

    • 精确匹配：指定文本应完全匹配。对于精确匹配，只能指定源实体字段。

    • 实体：指定将创建文本搜索规则的实体。可以指定源实体，如潜在客户、商机、联系人、帐户、案例，或与源实体相关的自定义实体以及像电子邮件、传真、信件等活动实体。

    • 字段：指定需要运行相似性分析的字段。字段类型可以是单行文本、多行文本或选项集。

  1. 单击“激活”以启用规则。

  2. 要查看实际效果，请打开任意一个案例记录。这里我们打开了一个标题为“请求的服务”的案例记录：

  1. 向下滚动到案例关系选项卡，点击+（加号）在相似案例子网格中。

  2. 查找相似案例对话框显示了所有相似的案例记录，如下所示：

  1. 然后，我们可以选择建议的相似案例记录，并单击“找到解决方案”将该记录关联起来，如下所示：

  1. 这通过连接将“即将需要服务”记录与“请求的服务”记录连接，如下所示：

在本节中，我们介绍了配置相似记录建议；在下一节中，我们将学习如何配置 Dynamics 365 的文档建议。

在 Dynamics 365 中配置文档建议

通过文档建议，用户可以了解到与他们正在处理的记录相关的所有重要文档，这在处理高优先级案例或重要商机时非常有帮助。建议的文档类型可以是 Word、Excel、PowerPoint、OneNote、Adobe PDF 和文本文件。Microsoft Azure 文本分析使用定义的相似性规则查找相关记录，然后显示与这些记录相关的建议文档列表。用户可以选择打开文档或将这些文档复制到当前记录中。文档建议仅搜索用户有权限访问的位置和文档。可以搜索的位置包括 SharePoint 站点、One Drive、Office 365 群组和外部 URL：

要设置 SharePoint 集成： technet.microsoft.com/library/dn531154.aspx 要启用 OneDrive for Business： technet.microsoft.com/en-us/library/mt622109.aspx

部署 Office 365 组： technet.microsoft.com/en-us/library/dn896591.aspx

在 Dynamics 365 中配置类似文档建议：

  1. 将文本分析连接与 Dynamics 365 连接，我们已经完成了这一步。

  2. 在 Dynamics 365 中，转到设置 | 文档管理，选择管理文档建议：

  1. 如果实体未配置文档建议，我们将收到以下通知：

  1. 让我们为案例实体启用此功能。打开案例实体进行自定义，启用文档管理并发布实体：

  1. 在管理文档建议中选择案例实体并点击应用：

  1. 启用文档建议后，下一步是为案例实体创建类似记录建议规则。进入设置 | 数据管理 | 类似记录建议设置。在这里，我们将使用我们之前基于案例标题创建的现有规则，如下图所示：

  1. 为了展示实际效果，让我们打开之前在类似记录建议中打开的相同案例记录，即标题为“服务请求”的案例，结果建议了 10 个类似的案例记录，如下图所示：

  1. 打开该案例记录的关联文档链接。

  2. 点击文档关联网格中的SHOW SUGGESTIONS功能按钮：

  1. 文档建议将列出所有与先前建议的类似案例记录关联的文档，如下所示：

  1. 选择要复制到现有案例记录的文档并点击复制：

  1. 这将复制选定的文档到当前案例记录中：

本节介绍了如何配置文档建议，在接下来的章节中，我们将学习如何在 Azure 门户中监控文本分析服务。

在 Azure 门户中监控文本分析服务

要监控我们配置的文本分析服务：

  1. 登录 Azure 门户

  2. 打开已创建的文本分析 API

  3. 在“监控”部分选择“指标”，它允许我们选择各种指标，如数据输入、数据输出、总呼叫、总错误等，并以折线图的形式显示结果：

  1. 下图显示了过去 24 小时内选择了“数据输入”和“数据输出”指标的折线图。我们还可以指定图表类型为柱状图，并可以筛选时间范围为“过去 1 小时”、“过去 1 周”或定义自定义范围：

  1. 类似地，在这里我们可以看到包含不同指标的报告，比如被阻止的呼叫、客户端错误、服务器错误、成功呼叫、总呼叫和总错误：

总结

在本章中，我们概述了 Microsoft 认知服务，并介绍了如何使用文本分析 API 来建议知识文章、类似案例和 Dynamics 365 中的文档。

在第十一章《通过学习路径训练用户》中，我们将探讨学习路径的创建，它使我们能够为 Dynamics 365 用户定制自己的帮助体验。通过这一新功能，我们可以减少培训时间和成本，提高用户使用 Dynamics 365 的生产力。

第十一章：通过学习路径培训用户

Dynamics 365 学习路径在 Dynamics 365 版本 9.0 中首次推出。此功能允许在用户打开页面时向 Dynamics 365 中添加可自定义的帮助内容。它还允许用户同时跟随帮助并进行工作，提供适应性，并轻松学习 Dynamics 365。

本章将涵盖以下主题，以帮助您更好地理解学习路径：

  • 学习路径概述

  • 学习路径的先决条件

  • 在 Dynamics 365 中启用学习路径

  • Dynamics 365 学习路径的内容库

  • 创建和配置学习路径的步骤

  • 理解学习路径

学习路径概述

Dynamics 365 学习路径是一个有效且高效的功能，使用户能够同时学习和适应 Dynamics 365。此功能仅适用于 Dynamics 365 在线版。

学习路径帮助可以在加载页面时或点击帮助按钮时提供给用户。学习路径为文本、视频和网址提供培训。它提供了在 Dynamics 365 中执行任务的完整流程。学习路径支持将内容导入和导出到不同的组织，这意味着可以方便地将学习路径从一个组织导出到另一个组织。

学习路径支持帮助内容的本地化，这意味着帮助内容是为使用学习路径的 Dynamics 365 用户创建的。所有帮助内容以选定语言提供给 Dynamics 365 用户；这一独特属性使得 Dynamics 365 学习路径对用户具有吸引力。

学习路径可以在平板电脑和移动设备上访问。它对不同地区更为可靠；很快将会在所有剩余地区提供访问。

使用学习路径的先决条件

学习路径为 Dynamics 365 用户带来了大量的好处。首先，需要完成以下先决条件才能使用学习路径：

  • Dynamics 365 学习路径仅在 Dynamics 365 版本 9.0 中受支持。在 Dynamics 365 2016 版本 1 中，用户只能看到 Microsoft 创建的默认帮助；要为学习路径创建内容，需要使用新的 Dynamics 365 版本 9.0。

  • 系统自定义者或系统管理员角色需要被分配，以便创作学习路径内容。

  • 在组织中，必须启用 Dynamics 365 中的学习路径。下一部分将介绍如何为组织启用学习路径。

  • 添加用户到学习路径组非常重要。此任务将在下一部分中介绍。

在 Dynamics 365 中启用学习路径

由于默认情况下学习路径是关闭的，因此需要在 Dynamics 365 中开启学习路径。以下步骤将说明如何启用学习路径，并且如何将用户添加到 Dynamics 365 学习路径组：

  1. 使用 Office 365 凭据登录到 Dynamics 365 9.0 实例。

  2. 在 Dynamics 365 中，应启用“退出学习路径”功能。选择设置并点击“退出学习路径”。完成此阶段后，Dynamics 365 控件将被重定向到 Dynamics 365 主屏幕。请看以下截图：

  1. 下一阶段是启用学习路径创作功能。进入设置 | 管理：

选择系统设置：

  1. 选择系统设置 | 启用学习路径并启用学习路径创作。点击确认以保存更改，如下所示：

  1. 现在，继续添加用户到学习路径组中。进入 Office 365 管理面板。选择组，点击学习路径创作者，然后将用户添加到该组，如下图所示：

Dynamics 365 学习路径内容库

学习路径内容库用于展示为组织创建和可用的内容。此外，它还用于管理、创建和与控件交互。内容库可以从 Dynamics 365 网站地图的“培训”选项卡访问，或者点击侧边栏中的“内容库”选项。

下图将解释内容库的用户界面：

请考虑以下几点：

  1. 引导任务：

引导任务包含一个或一系列步骤。启动引导任务非常简单。它通过逐步引导用户完成过程，帮助用户理解新任务。它确保你同时添加数据和执行任务。它为用户提供一个“下一步”按钮，如果用户正在执行任何任务，这使得它更加高效。

它支持许多功能，如添加视频、链接和更多信息，帮助用户更加熟悉 Dynamics 365 界面。

  1. 侧边栏：

当用户点击帮助按钮、选择页面上的链接或按钮时，侧边栏会出现，并将页面导航到该自定义设计内容。Dynamics 365 支持创建主屏幕侧边栏，用户选择帮助按钮或打开主屏幕时，它会显示在屏幕上。

系统自定义器还可以创建错误侧边栏，当出现问题时，会显示给用户。侧边栏支持添加链接、信息和视频，以帮助最终用户。

  1. 管理：此选项允许以以下方式管理内容：

    • 检入：此选项保存更改并使内容对其他用户可用

    • 删除：用来删除内容

    • 导出：将内容导出到其他组织

    • 导入：从其他组织导入内容

  2. 发布：发布所有更改到内容并使其对最终用户可用。

  3. 本地化：使用此选项添加内容的本地化。

  4. 配置：此选项用于配置安全角色以及发布环境。

创建和配置学习路径的步骤

Dynamics 365 覆盖了从潜在客户到机会的销售流程。在此场景中，使用从潜在客户到机会的流程作为学习路径示例。以下步骤提供了如何为潜在客户到机会创建学习路径的指导：

  1. 在 Dynamics 365 中，进入培训 | 内容库：

  1. 内容库将会打开：

  1. 选择侧边栏选项：

  1. 学习侧边栏表单将会打开，填写所有必要的字段。输入名称，选择模板，并保存侧边栏表单：

  1. 完成此步骤后，编辑侧边栏模板，输入侧边栏名称，必要时编辑部分，并向部分中添加 URLs 和图片：

  1. 如果需要更新部分属性，请点击该部分的编辑按钮。此选项将添加内容类型、文本、按钮、链接列表等：

  1. 选择侧边栏表单的保存选项：

  1. 选择左侧的预览按钮查看预览：

  1. 在查看预览后，发布或检查更改：

  1. 选择学习路径首页按钮，此操作会将你重定向到学习路径库：

  1. 选择“引导任务”选项以创建引导任务：

  1. 填写所有必要的引导任务字段并保存，如下图所示：

  1. 在流程编辑器中，添加从潜在客户到机会的引导选项。首先，收起流程编辑器，然后选择“Leads”实体：

然后选择“Leads”标签页，如下图所示：

  1. 扩展流程编辑器，当潜在客户记录加载时：

  1. 选择“添加新步骤”并点击“学习步骤”：

  1. 将新创建的学习步骤拖放到新潜在客户按钮上。在学习步骤中添加标题和描述：

  1. 点击保存按钮以保存学习步骤中的更改：

  1. 点击创建新潜在客户记录的按钮并打开新的潜在客户表单。要向“联系方式”部分添加新步骤，请选择用户操作并点击下一步按钮。使用以下图片：

  1. 拖放此学习步骤到潜在客户记录的联系人部分。添加步骤描述和名称。选择“保存”按钮以保存更改：

  1. 对公司部分重复相同的过程：

  1. 为 SAVE 按钮创建相同的学习步骤：

  1. 对 QUALIFY 按钮重复此过程：

  1. 为业务流程流的“Next”按钮添加另一个步骤：

  1. 在机会记录中，选择带有“Next”按钮的学习步骤：

  1. 拖放此步骤到机会名称上。对业务流程流、活动等重复此操作：

  1. 现在，保存引导任务：

  1. 查看预览并发布更改。

发布内容和发布组

除非已发布，否则 Dynamics 365 学习路径内容不可用。可以从内容库发布内容。要发布学习路径中的内容，首先需要进行签入。以下步骤将帮助你了解如何从内容库发布内容。

  1. 转到内容库：

  1. 选择要发布的内容列表中的内容。如果内容未签入，请确保将其签入：

  1. 点击“发布”按钮以发布更改：

这些是非常简单的发布内容步骤。

发布组用于发布学习路径的内容。启用学习路径时，默认会创建一个发布组。该默认发布组的名称与组织名称相同。你也可以创建其他发布组，并且可以将多个组织添加到发布组中。多个组织可以是不同组的成员，从而实现将内容发布到不同组织。

以下步骤说明如何创建发布组：

  1. 转到内容库：

  1. 点击“配置”：

  1. 在“发布配置”中选择新的发布组：

  1. 完成名称和可选描述：

  1. 将组织包含在发布组中。

  2. 点击“保存”并点击“确定”。

总结

在本章中，我们了解了如何在 Dynamics 365 中操作学习路径，Dynamics 365 学习路径的内容库，创建和配置学习路径的步骤等。在下一章中，我们将讨论网页客户端刷新和统一界面，以及相关功能，如相关搜索和关系洞察。

第十二章：Dynamics 365 中的其他新特性

在上一章中，我们了解了在 Dynamics 365 中新增的 学习路径 功能，该功能为最终用户提供了丰富的上下文内容。在本章中，我们将介绍一些在 2017 年 7 月和 2016 年 12 月的更新中引入的、我们在之前章节中未提及的新特性。

以下是本章将涵盖的一些主要话题：

  • Web 客户端刷新

  • 统一界面

  • 活动时间线

  • 多选选项集

  • 虚拟实体

  • 自动编号

  • 相关性搜索

  • 数据导出服务

  • 关系洞察

  • 实时协助

  • LinkedIn 潜在客户生成表单

Dynamics 365 中引入的顶级新特性

每次更新都会在 Dynamics 365 中添加许多新的功能、特性和改进。部分新功能面向那些每天使用系统的最终用户，而其他功能则面向管理员、自定义人员或开发人员，他们负责配置、定制和围绕该系统开发解决方案。本章将介绍一些之前章节未涉及的新功能。

理解 Web 客户端刷新中引入的视觉变化

Web 客户端刷新功能是 2017 年 7 月更新中引入的最大改进之一，旨在根据 Dynamics 365 用户对用户界面的反馈，提升产品体验。Web 客户端应用的用户界面经过了彻底的重设计，旨在通过提高可读性和可访问性，帮助用户在使用应用时提高工作效率。

下面是 Web 客户端的一些主要改进：

  • 容器（如节）现在有了明确的边框，任何不属于内容的额外空白部分已被灰色阴影标示出来。类似地，主体内容被放置在白色容器中，以便将其与头部和其他内容分开。如果容器中没有数据，系统会通过图标和消息清晰地显示出来，如社交面板中的活动列表所示：

  • 现在可以为表单中的标签和数值配置文本换行。我们需要进入系统设置 | 常规标签，并选择“是”以启用“允许在表单字段标签和数值中换行”选项：

  • 这是启用文本换行后，表单中字段显示的样式：

样式变化包括三种新主题：

  • CRM 默认主题

  • CRM 蓝色主题

  • CRM 橙色主题

主题还包括通过页面头部填充颜色和面板头部填充颜色属性来定义页面头部和节头部的颜色选项。

在这里，我们为这些属性指定了以下值：

  • 页面头部填充颜色 – #ccffcc

  • 面板头部填充颜色 – #ccffff

这是这些更改在 Dynamics 365 界面中的显示方式：

我们现在可以为表单中的子网格标题定义颜色。打开表单进行自定义，选择子网格，在编辑属性对话框中，我们可以指定面板标题颜色，如下所示：

使用多选项集选择多个选项

多选项集现在作为 Dynamics 365 中的新属性类型可用。这是该新属性类型的一些关键功能：

  • 多选项集可用于高级查找

  • 它们适用于主表单、快速创建和快速查看表单

  • 现有的全局选项集可以用于创建多选项集属性

  • 现有的客户端 API 方法，特定于现有的单值选项集，适用于新的多选项集

  • 多选项集不支持业务规则和工作流

以下截图显示了多选项集字段，其中三个项目已被选中：项目 1、项目 2 和项目 3：

使用“Does Not Contain Data”筛选器进行高级查找

现在，ADVANCED FIND 视图支持针对相关记录的“Does Not Contain Data”筛选器。所以基本上，我们现在可以编写这样的查询：查找所有不包含相关任务的潜在客户记录。但是，正如所示，我们目前无法为相关记录定义筛选条件：

这是前述查询的fetch XML 形式：

    <fetch version="1.0" output-format="xml-platform" mapping="logical" 
     distinct="true"> 
      <entity name="lead"> 
        <attribute name="fullname" /> 
        <attribute name="companyname" /> 
        <attribute name="telephone1" /> 
        <attribute name="leadid" /> 
        <order attribute="fullname" descending="false" /> 
        <link-entity name="task" from="regardingobjectid" to="leadid"
         link-type="outer" alias="ac" /> 
        <filter type="and"> 
          <condition entityname="ac" attribute="regardingobjectid" operator="null" /> 
        </filter> 
      </entity> 
    </fetch>

定义 Web 资源依赖关系

对于 JavaScript 和 HTML Web 资源，我们现在可以指定依赖关系。这确保了在导出时，所有必需的依赖资源在解决方案中可用，或者已经存在于目标系统中（即解决方案正在导入的系统），否则会导致导出失败。它还确保我们不会意外删除任何组件，而不先删除其依赖关系。对于 HTML 和 JavaScript，我们可以定义对其他 Web 资源类型（如 CSS、HTML、JavaScript 库、RESX 和 XML）的依赖关系。对于 JavaScript，我们还可以定义对特定实体属性的依赖关系，如下所示：

了解新的统一界面

统一界面是 Dynamics 365 2017 年 7 月更新中引入的新框架。使用统一界面，我们现在在所有平台上都有相同的架构。目前，我们有以下应用程序，如客户服务中心（这是互动服务中心的新版本）、现场资源中心、项目资源中心和销售中心，这些都在统一界面上开发，如下所示：

统一界面从头开始构建，注重可访问性、一致性和性能。它还带来了更快的开发和部署时间，单一的定制集可以无缝地在不同设备间工作。对于最终用户，它将在平板电脑/手机客户端、移动 Web 客户端或 Outlook 应用中提供统一的体验，这使得用户体验更加一致、友好，并节省了培训成本。

新统一界面的好处包括：

  • 轻松访问左侧导航面板中的收藏夹和最近的记录、仪表板和实体：

  • 在统一界面中，最近使用的记录可以被固定，如下所示：

  • 新的响应式统一客户端界面会根据屏幕大小自动适配。在调整浏览器窗口大小时，统一界面会显示适应小屏幕的界面，如右侧图片所示：

  • 业务流程现在可以在浮动模式和停靠模式下显示：

  • 业务流程可以像这里展示的那样垂直对齐：

  • 新的统一界面时间轴控件将所有活动、笔记和帖子整合并提供单一视图，用户可以按记录类型、日期等进行筛选。它还允许用户根据记录类型执行各种操作，如下所示：

  • 知识库的编辑器已得到增强，包括支持编辑 HTML 源代码，如下所示：

  • 它还包括预览内容的选项，以检查其与不同设备的兼容性：

使用虚拟实体集成外部数据

在 2017 年 7 月的 Dynamics 365 更新中，我们现在可以创建一种虚拟类型的自定义实体。之所以称为虚拟实体，是因为该实体的数据并未保存在 Dynamics 365 内部。在运行时，虚拟实体在被访问时会从配置的外部数据源提供商获取数据。目前，它仅支持 OData V4 数据提供商。在 Dynamics 365 的早期版本中，若要从外部数据源获取或检索数据，我们需要编写自定义代码。现在，一旦 OData 服务准备好并已公开，它就成为 Dynamics 365 内部的配置内容，系统管理员或定制者可以处理，而无需依赖开发人员。

配置虚拟实体的方法：

  1. 转到设置 | 管理，并选择虚拟实体数据源：

  1. 点击“新建”以创建新的数据源。目前，它仅支持 OData V4 数据提供程序：

  1. 指定 OData 服务的 URL，并提供所需的值以创建 OData 源记录：

  1. 现在，数据源设置完成后，下一步是创建虚拟实体。转到设置 | 自定义 | 自定义系统 | 选择实体并点击“新建”以创建新实体。要创建虚拟实体，我们需要选择“虚拟实体”复选框。

  2. 对于虚拟实体，External Name 属性和 External Collection Name 属性应与我们希望在 Dynamics 365 中配置的 OData 实体的实体名称和实体集名称相对应：

要了解更多关于 OData 的信息，请访问以下链接：

www.odata.org/documentation/

  1. 在创建虚拟实体时，系统将自动创建两个字段，这些字段需要作为虚拟实体配置的一部分，映射到 OData 实体的相应字段。除了自动创建的字段，我们还可以创建新的自定义字段，然后将它们映射到 OData 实体的相应字段，以便它们在 Dynamics 365 中显示。

  2. 在这里，我们将为虚拟实体创建的 ID 字段与我们的 OData 实体的主键字段（例如EntityID）进行映射。主键字段必须是 GUID 类型，否则我们将得到异常：

  1. 一旦我们完成了所有虚拟实体字段的创建和映射，就可以发布更改。

  2. 这个虚拟实体将像其他任何实体一样可用。我们可以打开高级查找视图，选择虚拟实体并针对其运行查询，或者打开为该实体创建的任何记录进行查看。

  3. 在计划使用虚拟实体时，我们需要考虑以下几个要点：

    • 虚拟实体是只读的

    • 虚拟实体是组织所有的，但是，Dynamics 365 的安全功能不支持虚拟实体

    • 虚拟实体不能是活动类型

    • 我们不能针对虚拟实体配置 SLA（服务水平协议）或业务流程流

    • 虚拟实体不支持创建快速创建表单

    • 我们不能在它们上启用审计和重复检测

    • 虚拟实体字段不能用于汇总和计算字段

    • 尽管我们可以在高级查找中使用它，微软不推荐使用连接 Dynamics 365 原生数据与虚拟实体数据的查询

    • 我们不能针对虚拟实体编写工作流或插件

实现自动编号

自动编号作为一个特性，从 Dynamics 365 版本 3.0 开始就已经存在，但它一直仅限于少数几个实体，如合同、案例、文章、报价单等。

转到设置 | 管理，然后点击自动编号，查看我们可以配置自动编号的所有实体：

然而，现在通过 Dynamics 365 2017 年 7 月更新，我们终于可以为其他实体定义自动编号了。目前，我们只能使用 SDK 的CreateAttribute请求以编程方式定义它。我们没有用户界面来定义它。

下面是创建新的自动编号字段名称的示例代码，

My Auto Number 在联系人实体中：

    CreateAttributeRequest createAttributeRequest = new CreateAttributeRequest(); 
    createAttributeRequest.EntityName = "contact"; 

    var autoNumberAttributeMetadata = new StringAttributeMetadata() 
    { 
      AutoNumberFormat = "Auto Number - {SEQNUM:4} - {RANDSTRING:4} - 
       {DATETIMEUTC:yyyyMMddhhmmss}", 
      SchemaName = "new_autonumber1", 
      MaxLength = 100, 
      RequiredLevel = new AttributeRequiredLevelManagedProperty(
       AttributeRequiredLevel.ApplicationRequired), 
      DisplayName = new Microsoft.Xrm.Sdk.Label("My Auto Number", 1033), 
      Description = new Microsoft.Xrm.Sdk.Label("This is my first auto number
       field through SDK", 1033) 
    }; 

    createAttributeRequest.Attribute = autoNumberAttributeMetadata; 
    var response = organizationService.Execute(createAttributeRequest);

以下图片展示了为联系人记录指定格式后生成的自动编号字段：

下面是这个新自动编号属性的特定属性：

AutoNumberFormat 指定自动编号字段的格式，静态字符串以及：{SEQNUM:size} - 顺序号的大小{RANDSTRING:size} - 生成的随机字符串的大小{DATETIMEUTC:format}- 日期时间的格式
架构名称 指定自动编号字段的架构名称
最大长度 指定自动编号字段的最大长度

| 必需级别 | 指定自动编号字段的必需级别：

  • 无

  • 推荐

  • 应用程序要求

  • 系统要求

|

显示名称 指定自动编号字段的显示名称
描述 指定自动编号字段的描述

我们可以使用由 Jonas Rapp 开发的 XrmToolBox 插件——Auto Number Manager，通过一个直观的用户界面来创建、更新和删除自动编号字段。anm.xrmtoolbox.com/

使用UpdateAttribute请求，我们可以更新现有自动编号字段的格式。这仅适用于新创建的记录，不适用于现有记录。我们还可以为一个实体创建多个自动编号字段。

不支持将属性要求级别设置为系统要求的自动编号字段。

使用相关搜索提升搜索体验

相关性搜索将微软的 Azure Search 的强大功能带入 Dynamics 365，以提高搜索性能。来自 Dynamics 365 实体的数据以及为相关性搜索启用的字段与 Azure Search 数据库同步，后者对其进行直观的语义搜索，并按相关性显示结果。与按实体分组显示结果的分类搜索不同，相关性搜索会跨实体字段进行搜索，并按最相关到最不相关的顺序显示结果。此外，与仅能按实体过滤结果的分类搜索相比，相关性搜索允许 Dynamics 365 用户根据多个条件（如记录类型、所有者、修改日期、创建日期和为每个实体定义的其他筛选选项）过滤结果，这些选项基于面向的维度进行筛选。由于相关性搜索使用语义搜索，我们无需在搜索文本中指定通配符。相关性搜索还会高亮显示搜索结果中的匹配单词。基本上，一旦我们确定并配置了实体及其相应的字段进行相关性搜索，第一次进行完全同步时可能需要超过一个小时，具体时间取决于同步的数据量，之后在 Dynamics 365 中所做的任何更改可能最多需要 15 分钟才能出现在搜索结果中。

Azure Search 文档可以在这里找到：docs.microsoft.com/en-us/azure/search/。

启用相关性搜索

启用相关性搜索：

  1. 进入“设置” | “管理” | “系统设置”。在“常规”选项卡中，勾选“在设置搜索部分启用相关性搜索”，并同意与外部系统共享数据：

  1. 接下来，我们需要定义要进行相关性搜索的实体和字段。进入“自定义设置” | “实体”，点击“配置相关性搜索”以选择需要启用相关性搜索的实体：

  1. 对于相关性搜索，可以选择的实体数量没有限制。限制在于每个组织的字段数量，最多为 1,000 个字段。这里，查找字段相当于添加 3 个字段，选项集相当于 2 个字段，其余字段为 1 个字段。

  2. 我们可以将可用实体列表框中的实体添加到已选择实体列表框中，然后点击发布。进度条中的“总字段索引”字段显示已使用字段的总数：

  1. 要为实体启用某一特定属性的相关性搜索，我们需要将该字段添加为该实体的“快速查找”视图中的查找列。只有单行文本和多行文本字段可以被搜索。

  2. 在“快速查找”视图中定义的前四个字段将在用户界面的搜索结果中显示。

  3. 同样，Quick Find 视图中的前四个可筛选字段，即除单行文本或多行文本以外的数据类型字段，将作为相关性搜索用户界面中的筛选项显示。

  4. 在 Quick Find 视图中定义的过滤器也会应用于相关性搜索结果。但是，并非所有操作符都支持用于过滤。以下是相关性搜索不支持的操作符列表：

Like NotLike BeginsWith DoesNotBeginsWith
EndWith DoesNotEndWith ChildOf EqualUserLanguage
Mask NotMask MaskSelect Above
Under NotUnder UnderOrEqual AboveOrEqual

Quick Find 视图中的相关实体字段不会被相关性搜索视为查找列、视图列或筛选器。

  1. 要执行相关性搜索，请点击导航栏中的搜索图标并输入文本以开始搜索。在这里，我们输入了Eva作为搜索文本：

  1. 搜索结果将根据相关性以列表形式显示，并且包括来自所有可搜索实体的结果，这些结果可以根据记录类型、所有者、修改时间、创建时间或任何其他定义的筛选项进一步筛选。匹配项也会在结果中高亮显示。

  2. 用户还可以定义默认的搜索体验，并为每个为相关性搜索配置的实体配置筛选字段：

    • 要定义默认的搜索体验，请导航到导航栏上的齿轮图标，选择“选项”以打开“设置个人选项”对话框。在“常规”选项卡中，我们可以定义相关性搜索、分类搜索，或者让最后一次使用的搜索成为默认搜索体验，如下所示：

  • 同样，我们可以点击“配置”按钮来配置筛选器和筛选项，以定义相关性搜索的筛选项。我们可以为每个可搜索的实体定义最多四个字段，如下所示：

使用数据导出服务导出 Dynamics 365 数据

数据导出服务可以定义为一个可扩展且安全的云服务，它使得可以将 Dynamics 365 在线数据库复制到 Microsoft Azure SQL 数据库或 Microsoft Azure 虚拟机上的 SQL 数据库中。然后，这些 Dynamics 365 数据可以用于各种分析和报告场景，例如 Power BI 或基于 SQL 的 SSRS 报告，或者在其上构建任何自定义解决方案。数据导出服务基于定义的导出配置文件同步整个 Dynamics 365 数据，首次同步后，随后的运行仅同步增量变化。

配置数据导出服务

配置数据导出服务：

  1. 我们首先需要将 Office 365 租户与 Azure 订阅关联（如果它们是分开的），请参见 docs.microsoft.com/zh-cn/azure/billing/billing-add-office-365-tenant-to-azure-subscription。

  2. 接下来，我们创建一个 Azure SQL 数据库。为此，请登录 Azure 门户并点击“添加”以创建一个新的 SQL 数据库： docs.microsoft.com/zh-cn/azure/sql-database/sql-database-get-started-portal。

  3. 在成功创建 Azure SQL 数据库后，打开 SQL Server Management Studio 以连接到 Azure SQL 数据库。我们可以从 Azure 门户获取服务器名称，并设置防火墙规则，以允许从 SQL Server Management Studio 连接到 Azure SQL 数据库：

  1. 接下来，我们需要创建一个 SQL 用户，该用户将由数据导出服务用于在 Azure 数据库中写入数据。对于这个第一个用户，创建一个登录，选择主数据库：
      Create login [dataexportserviceuser] with PASSWORD = '**********';
  1. 为您创建的 Azure SQL 数据库分配数据库所有者角色，以便用于导出 Dynamics 365 数据：
      Create user [dataexportserviceuser] from login [dataexportserviceuser]; 

      Exec sp_addrolemember 'db_owner', 'dataexportserviceuser';

数据库用户所需的数据库权限，请参阅此处： technet.microsoft.com/zh-cn/library/mt744592.aspx#Anchor_1。

  1. 现在，在设置好数据库后，我们需要在 Dynamics 365 中配置数据导出服务。导航到设置 | Dynamics 市场，找到数据导出服务并点击“立即获取”。同意条款和条件。这将把数据导出服务解决方案安装到 Dynamics 365 实例中：

  2. 这会在 Dynamics 365 的设置中添加数据导出链接。点击后，我们会看到一个免责声明页面，在这里我们需要同意将数据导出到外部系统：

启用浏览器中 discovery.crmreplication.azure.net/ 域的弹出窗口，以便在导航到设置 | 数据导出时自动登录。

  1. 一旦我们自动登录，我们可以点击“新建”按钮来创建一个数据导出配置文件：

对于数据导出配置文件：

名称 指定导出配置文件的唯一名称。
密钥库 URL 指定密钥库的 URL，该密钥库基本上包含安全存储在其中的 Azure SQL 数据库凭据和连接信息。
模式 指定数据库的模式。默认值是 dbo。
前缀 指定我们希望赋予在数据库中创建的表的前缀。
重试次数 指定在插入或更新记录失败时重试的次数。可接受的值为 0 到 20。默认值为 12。
重试间隔 指定在失败时每次重试的间隔时间。可接受的值为 0 到 3,600 秒。默认值为 5 秒。
写入删除日志 指定日志记录已删除记录的可选设置。
  1. 对于密钥库 URL，微软提供了 PowerShell 脚本，我们需要使用它来生成密钥库 URL。要获取脚本，请点击密钥库 URL 文本框旁边的蓝色信息图标并复制它。基本上，在这里我们需要在 PowerShell 脚本中为以下占位符指定值，如下所示：

  1. 转到 Azure SQL 数据库的概览部分，以获取订阅 ID、资源组名称、位置和连接字符串的值。

  2. 对于连接字符串，我们需要复制 ADO.NET 连接字符串，并将用户名和密码替换为之前创建的 SQL DB 用户的凭据。

  3. 对于组织 ID，请进入 Dynamics 365 中的设置 | 自定义并从 实例参考信息 部分复制 ID。

  4. 对于租户 ID，请导航到 Azure 门户 | Azure Active Directory | 应用注册 | 端点，并从联合元数据文档 URL 中复制租户 ID。

  5. 替换 PowerShell 脚本中的占位符并运行脚本。这将会在 Azure 门户中创建一个密钥库记录。要复制密钥库 URL，请导航到 Azure 门户 | 密钥库。选择已创建的密钥库并点击 Secrets。复制密钥标识符值，并将其粘贴到 Dynamics 365 中创建导出配置文件时的密钥值 URL 处，然后点击验证。

安装并配置 Azure PowerShell 扩展： docs.microsoft.com/en-us/powershell/azure/install-azurerm-ps?view=azurermps-3.8.0。

  1. 在验证成功后，我们将收到成功消息。点击下一步选择我们希望导出的实体：

  1. 在选择实体步骤中，我们选择了 Contact 实体。由于这里只选择了一个实体，因此在接下来的选择关系步骤中不会有关系可供选择。在最后的总结步骤中，检查详细信息，然后点击“创建并启用”以创建并启用配置文件，如下所示：

实体必须启用变更追踪才能将其添加到导出配置文件中。

  1. 激活后将开始同步过程。我们可以点击刷新，检查导出配置文件记录的同步状态：

  1. 在同步成功后，我们可以在 SQL Azure 数据库中看到 Contact 实体的导出数据：

配置关系洞察

关系洞察利用 Microsoft Azure 的机器学习能力，分析 Dynamics 365、Exchange 和 Office 365 中的信息，并引导用户帮助他们与客户建立更个性化和富有成效的关系。所有从这些来源捕获的洞察信息都显示在 Dynamics 365 中，因此用户无需离开 Dynamics 365，也无需在不同的应用程序之间切换，以便了解接下来需要采取的业务活动。

关系洞察的三个主要功能是：

  • 关系助手

  • 电子邮件参与

  • 自动捕获

关系洞察仍处于预览阶段，该功能仅在北美（NA）地区可用。

启用关系洞察

启用关系洞察：

  1. 进入设置 | 管理。打开系统设置，在预览选项卡中，选择“是”以在“关系洞察”部分启用它们：

  1. 进入设置 | 关系洞察，点击安装。选择 Dynamics 365 管理页面中的 Dynamics 365 关系洞察解决方案，点击“管理”，然后选择“接受”以同意允许关系洞察访问 Dynamics 365 Online。这将为所选的 Dynamics 365 实例配置关系洞察：

配置关系助手

我们可以通过两种方式启用和配置关系助手：从设置 | 关系洞察或从个人选项设置。关系助手分析用户正在处理的客户记录的所有通信，并生成操作卡。这些操作卡提醒用户需要执行的操作，如今天需要发送的电子邮件，提醒用户即将到期的机会，或显示与何时打开电子邮件或附件、账户、案例、联系人等记录相关的分析或通知。这些操作卡分为不同类别，如下所示：

来自 Exchange 的电子邮件卡需要配置 Exchange Online。

操作卡可以在表单中的社交窗格的助手选项卡中查看。关系助手也可以作为仪表板中的一个组件添加。这里显示的示例操作卡提醒用户在 14 天内关闭机会的机会记录。用户可以从操作卡中打开机会记录并进行处理：

配置自动捕获

以下是配置自动捕获的步骤：

  1. 进入设置 | 关系洞察，点击自动捕获选项卡以启用它。

  2. 自动捕获需要服务器端同步和配置 Exchange Online。

配置服务器端同步：technet.microsoft.com/en-us/library/dn531109.aspx。

  1. 自动捕获会分析通过 Exchange Online 进行的电子邮件通信，并在 Dynamics 365 中显示相关的电子邮件以进行跟踪。目前，这些电子邮件是私密的，仅对当前用户可见。

  2. 下面是从 Exchange 发送到联系人的电子邮件如何在 Dynamics 365 社交窗格的活动标签中显示：

  1. 用户可以点击跟踪来跟踪 Dynamics 365 中的活动。状态会从“未跟踪”变为“跟踪待定”。在服务器端同步完成后（约 15 分钟内），电子邮件开始在 Dynamics 365 中被跟踪：

  1. 一旦启用，自动捕获将为该 Dynamics 365 实例中的所有用户启用。用户可以通过点击齿轮图标，打开个人选项，选择电子邮件标签，并在活动列表选项中选择“不在 Dynamics 365 中显示未跟踪的电子邮件”来关闭此功能。

配置电子邮件参与

以下是配置电子邮件参与的步骤：

  • 转到设置 | 关系洞察，选择 >电子邮件参与标签页并点击开始设置。这将开始配置电子邮件参与服务。

  • 配置完成后，选择复选框以启用电子邮件参与。

为了提供关于附件的见解，我们需要在 Dynamics 365 中启用服务器端同步，以支持 SharePoint、Exchange 和 One Drive for Business：technet.microsoft.com/en-us/library/dn531154.aspx 和 technet.microsoft.com/en-us/library/mt622109.aspx。

  1. 电子邮件参与提供关于电子邮件通信的见解，如电子邮件或附件是否已被打开，链接是否已被点击，基于打开率建议最佳的发送时间等。

  2. 配置完 SharePoint 集成后，我们需要为电子邮件实体启用文档管理；转到设置 | 文档管理 | 文档管理设置并勾选“电子邮件”复选框。如果我们希望在电子邮件活动中跟踪附件，这是必需的。

  3. 电子邮件参与仅适用于从 Dynamics 365 内部发送的电子邮件。要查看其效果，请创建一个电子邮件活动。你会注意到在电子邮件活动的表单中新增了一个名为电子邮件参与的部分。默认情况下，创建的电子邮件会被跟踪。要取消跟踪，我们需要点击不跟踪链接：

  1. 电子邮件还可以安排稍后发送：

  1. 设置提醒允许我们设置何时希望收到通知的条件：

  1. 我们可以看到调度信息已添加到活动记录中，如下所示：

  1. 与电子邮件参与相关的操作卡片将显示在关系助手中：

  1. 与电子邮件类似，附件也可以被跟踪。为此，在附件子网格中点击+按钮，这将打开管理附件对话框。文档上传成功后，我们将看到跟踪附件的选项：

  1. 我们还可以看到一个名为“RECIPIENT ACTIVITY”（收件人活动）的部分，已添加到正在跟踪的电子邮件的电子邮件实体表单中。它为我们提供了电子邮件被打开的次数、附件被查看的次数、链接点击的次数以及回复的总数的概览视图。

  2. 除了概览视图外，我们还可以查看邮件何时以及在哪个设备上被打开，链接何时被点击，附件何时被查看等等，如下所示：

  1. 电子邮件参与功能也适用于电子邮件模板。如果我们使用电子邮件模板发送邮件，它会跟踪例如某个特定模板的邮件被打开多少次，邮件的打开率、回复次数、回复率以及模板被用于发送邮件的总次数，基于这些捕捉到的细节，会标记该邮件模板为推荐，如下所示：

配置 Dynamics 365 Live Assist

Dynamics 365 的 Live Assist 是 Dynamics 365 的一个附加组件，添加了聊天、共同浏览和视频功能。它允许 Dynamics 365 用户与客户进行更加个性化的互动，从而可能提高在线销售、加速问题解决等。

安装方法：

  1. 进入设置 | Dynamics Marketplace，搜索 Live Assist 并点击免费试用以开始使用。

  2. 验证 Dynamics 365 实例，并点击同意将应用程序添加到 Dynamics 365：

  1. 这将打开 Live Assist 配置页面，选择 Dynamics 365 实例，提供联系电子邮件地址并点击提交以开始配置：

  2. 配置完成后，一封确认邮件将发送到提供的联系电子邮件地址。邮件中会包含指向 Live Assist 管理门户的链接，我们可以使用 Dynamics 365 凭据登录，并按照说明完成 Live Assist 的设置。

  3. 通过管理员门户（admin.na1.liveassistfor365.com/portal/），管理员可以管理订阅和用户，例如启用或禁用用户，或将监督者（管理员）角色分配给用户：

  1. 在 Dynamics 365 内，我们可以看到 Live Assist 链接添加到设置中的业务区域：

  1. 如下图所示，在 Dynamics 365 右侧的 Live Assist 面板中：

Live Assist for Microsoft Dynamics 365 的知识库：www.liveassistfor365.com/en/support/knowledge-base/.

  1. 要查看其操作方式，我们可以使用 Live Assist 演示站点。要访问它，我们需要在管理门户中点击“开始”按钮，转到其中的第 3 步，并启动 Dynamics 365 和演示站点：

  1. 我们可以点击“启动 Dynamics 365”按钮以打开 Dynamics 365，点击“演示站点”按钮以打开 Live Assist 提供的演示站点，用于测试目的：

  1. 演示站点是一个为测试设计的 CafeX 站点。Dynamics 组织的 Live Assist 标签将自动嵌入演示站点。

  2. 在 Dynamics 365 中使用 Live Assist 的代理人可以在演示站点内与访客进行聊天和协助，如下图所示：

  3. 代理人可以在 Dynamics 365 内的 Live Assist 小部件中搜索知识库、开放聊天活动，并创建案例记录：

  1. 要开始共同浏览会话，用户可以在 Live Assist 小部件内点击蓝色屏幕共享图标。共同浏览允许客户或访客与代理人共享屏幕：

  1. 我们还可以在全屏模式下打开聊天窗口，其中包括搜索联系人或案例、创建新联系人或案例记录的功能，同时提供有关访客、聊天、设备等的附加详细信息，如下图所示：

配置 Dynamics 365 Connector for LinkedIn Lead Gen Forms

使用 Dynamics 365 Connector for LinkedIn Lead Gen Forms，我们可以无缝同步 LinkedIn Lead Gen Forms 中的 LinkedIn 潜在客户到 Dynamics 365。这些潜在客户可以在 Dynamics 365 中进行培养。

设置 LinkedIn Lead Gen Forms：business.linkedin.com/marketing-solutions/native-advertising/lead-gen-ads.

配置方法如下：

  1. 转到“设置” | Dynamics Marketplace，在其中搜索Dynamics 365 Connector for LinkedIn Lead Gen Forms安装它。点击“免费试用”，按照说明开始安装过程。

  2. 在 LinkedIn 组织选择器页面中，选择组织并点击“继续”以开始设置：

  1. 安装成功后，我们将收到确认电子邮件。这会在 Dynamics 365 中安装LinkedInLeadGenIntegration解决方案。

  2. 每当从 LinkedIn 同步一个新的潜在客户时，Dynamics 365 会查找在活动的 LINKEDIN 潜在客户匹配策略记录中定义的匹配字段，以确定是创建新潜在客户还是更新 Dynamics 365 中的现有潜在客户记录。

  3. LinkedIn 潜在客户是在 Dynamics 365 中创建的 LinkedIn 表单提交记录。它们包含 LinkedIn 用户在提交表单时提供的答案。现有的潜在客户记录会根据定义为匹配字段的字段与这些答案进行匹配。

  4. 拥有 LinkedIn Lead Gen Forms Connector Administrator 安全角色的用户可以定义电子邮件潜在客户匹配策略。以下是在 Dynamics 365 中创建的默认记录，其中定义了基于电子邮件地址的匹配字段：

  1. 在任何给定的时间点，只能激活一个策略。如果定义了多个字段，则所有字段必须匹配，现有的潜在客户记录才会被更新。如果只有部分字段匹配，则我们可以配置在 LinkedIn LeadGen 集成配置记录的“匹配失败时”属性中，是否应创建新的潜在客户记录，或者不采取任何操作：

  1. 接下来，我们需要授权 Dynamics 365 从 LinkedIn 的广告活动管理器同步数据。转到设置 | LinkedIn 用户个人资料，点击“新建”以创建一个新的用户个人资料记录。要将 LinkedIn 帐户添加到这个新用户个人资料中，点击“授权”按钮。输入 LinkedIn 帐户凭据并选择“允许”：

  1. 在接下来的屏幕中选择“是”，以允许 Dynamics 365 访问 LinkedIn 数据。

  2. 这会将 LinkedIn 帐户添加到个人资料中并开始同步。我们也可以点击“同步提交”按钮手动启动同步。这将开始将 LinkedIn 表单提交记录与 Dynamics 365 进行同步：

  1. 在 Dynamics 365 中，我们可以打开潜在客户记录并查看在 LinkedIn Lead 信息部分中捕获的详细信息，如下所示：

总结

本章中，我们介绍了 Dynamics 365 中的一些重大变化，如 Web 客户端刷新和统一界面，以及像相关性搜索和关系洞察等功能，这些功能将人工智能引入到 Dynamics 365 中。我们还了解了如何通过简单的配置步骤导出 Dynamics 365 数据，这些数据可以用于各种分析目的。

posted @ 2025-06-29 10:39  绝不原创的飞龙  阅读(129)  评论(0)    收藏  举报