当前位置:   article > 正文

实施Microsoft Dynamics 365 CE-6. 自定义Dynamics365CE介绍了自定义Dynamics365CE应用程序的方法_ce365

ce365

本章将帮助您了解Dynamics 365自定义功能。您将了解自定义的概念,以及如何考虑重用现有组件而不是创建新实体。您将学习如何创建新实体以及自定义实体窗体、视图和数据类型。您还将了解Dynamics365客户参与(CE)安全性。稍后,您将了解如何自定义仪表板和图表,这将帮助您为客户设置商业智能功能。

我们将在本章中讨论的主要主题是:

  • 了解Dynamics 365 CE定制
  • 了解解决方案
  • 与实体合作
  • 设置安全选项
  • 更改导航
  • 自定义仪表板和图表

技术要求

本章要求您设置Dynamics 365 CE试用版,以便执行自定义操作。我们在Dynamics 365 CE简介一章中讨论了如何设置Dynamics 365 CE试用版。您还应该对Dynamics 365 CE有一个基本的了解。

了解Dynamics 365 CE定制

所有Dynamics 365 CE应用程序(由Microsoft构建和Dynamics 365 CE安装的应用程序)都提供通用的商业体验。例如,Sales应用程序为我们提供了实现端到端通用销售流程所需的一组核心功能。这涉及到存储客户数据的常用业务实体、指导和完成销售流程的业务流程流,以及仪表板、图表和报告等通用商业智能工具。如果需要,所有这些流程都可以根据我们的业务特定需求进行修改,也可以为最终用户提供个性化体验。Dynamics 365 CE Power Platform允许我们使用Dynamics 365 CE应用程序本身修改大多数现有组件。我们不需要任何额外的工具来更改组件的行为。根据我们的需求定制现有Dynamics 365 CE组件的过程称为Dynamics 365 CE定制。

尽管我们可以使用Dynamics 365 CE Power Platform创建新组件,但考虑现有组件是非常重要的。让我们来看一个Account实体的简单场景。几乎所有Dynamics 365 CE第一方应用程序(如销售、市场营销、服务、现场服务和项目服务自动化(PSA))中都提供帐户实体。尽管我们可以使用Dynamics 365 CE Power Platform创建新组件,但考虑现有组件是非常重要的。让我们来看一个Account实体的简单场景。几乎所有Dynamics 365 CE第一方应用程序(如销售、市场营销、服务、现场服务和项目服务自动化(PSA))中都提供帐户实体。

我们可以根据这些不同的配置文件自定义帐户实体。Dynamics365CE的自定义可以非常简单——例如,将Account实体显示名称从Account重新标记为Customer时。或者,它可能很复杂,例如当我们需要添加一组新实体、设置数据模型以及设置业务流程时。在处理复杂的需求时,如果任何Microsoft独立软件供应商(ISV)已经为类似的需求开发了解决方案,那么值得查看Microsoft AppSource,因为这可以为我们节省时间和金钱。

现在,我们已经对Dynamics365CE的自定义概念有了基本的了解,让我们讨论如何自定义Dynamics365 CE。

了解解决方案

在为Dynamics 365 CE进行任何定制之前,了解我们可以将定制组件存放在哪里是非常重要的。解决方案充当Dynamics 365 CE组件的容器。我们在Dynamics 365 CE中看到的所有组件都是该解决方案的一部分,该解决方案被称为默认解决方案或基本解决方案。当您连接到Dynamics 365 CE应用程序时,如果您导航到make.powerapps.com,这是一种访问和修改解决方案的新方法,您可以看到组织的默认解决方案,如以下屏幕截图所示:

要自定义系统,语言必须与基本语言匹配。我们无法用另一种语言自定义系统。

您可以双击“默认解决方案”以查看它所具有的所有组件。我们可以使用筛选器下拉列表只查看特定类型的解决方案组件,例如以下内容:

该解决方案包含所有开箱即用的Dynamics 365 CE组件、我们定制的任何组件以及ISV开发的组件。在前面的屏幕截图中,您可以看到解决方案的所有组件。屏幕截图中给出的组件列表表示哪些组件可以包含在解决方案中。请记住,在添加前面的解决方案组件时,只有组件的在解决方案中添加元数据;它不包括任何用户数据。

我们只能通过创建XML web资源在解决方案中包含XML数据。

在传统的应用程序中,所有开发和更改的组件都包含在包中,这样它们就可以从开发环境移动到其他环境。在Dynamics 365 CE中,我们使用解决方案对更改进行打包,以便将更改移动到其他环境中。在使用解决方案时,我们可以将自定义组件分离为自定义解决方案。在开始对Dynamics 365 CE进行任何自定义之前,最好创建我们自己的自定义解决方案,以便我们可以将所有新组件以及自定义组件保留在此解决方案中。这个解决方案可以在测试过程结束后分发给其他人。

现在我们对解决方案有了基本的了解,让我们讨论一些用于解决方案的术语。

发布者

发布者基本上就是解决方案的作者。我们创建的每个解决方案都必须有一个发布者,因为这有助于我们确定谁开发或定制了该解决方案中的组件。每个组织都有一个默认发布者,该发布者由Dynamics 365 CE Power Platform在组织设置过程中创建。当您设置新的Dynamics 365 CE云实例或在本地安装Dynamics 365 CE时,会为<<组织>>创建一个名为“默认发布服务器”的新发布服务器。例如,让我们假设我的组织的名称是HIMBAP。Dynamics 365 CE Power Platform将为HIMBAP设置一个名为“默认发布服务器”的发布服务器。我们将在创建自定义实体一节中讨论更多关于发布者的内容。

版本

每个解决方案都需要一个版本。我们可以使用四个间隔指定解决方案的版本号。例如,我们可以使用major.minor.build.revision的格式。我们可以根据组织的要求使用版本信息。有时,供应商会在其解决方案版本中使用Dynamics 365 CE发布版本来确定其解决方案支持的Dynamics 365 CE版本。

导入

导入过程用于在我们的Dynamics 365 CE组织中安装解决方案。导入过程中,Dynamics 365 CE Power Platform会检查是否存在任何解决方案组件相关性。如果我们的组织中不存在依赖项,它将显示为错误。如果解决方案包含任何工作流或插件步骤,它会要求您启用它们。

导出

导出选项用于将我们的解决方案分发到其他环境。导出解决方案时,我们可以选择将解决方案导出为托管还是非托管。这两类将构成我们的下一个讨论主题。我们还可以将配置作为解决方案的一部分。在导出过程中,Dynamics 365 CE将指示任何相关组件中是否缺少解决方案。

非托管解决方案

处于开发阶段的每个解决方案都属于非托管类别。我们前面讨论的默认解决方案也处于非托管阶段。我们可以修改非托管解决方案的现有组件,也可以向其中添加新组件。让我们为我们的HIMBAP汽车服务中心创建一个示例。我们可以创建一个解决方案,在该解决方案中,我们可以添加所有需要的开箱即用实体,也可以创建任何需要的新实体。导出解决方案时,Dynamics 365 CE将询问我们是要将解决方案导出为托管解决方案还是非托管解决方案。如果我们选择一个非托管解决方案,它将使用以下名称格式导出一个非管理解决方案:

<<SolutionName>> _SolutionVersion.zip
这里,SolutionName是我们解决方案的显示名称,SolutionVersion是解决方案的版本信息。将非托管解决方案导入组织时,它会覆盖使用早期解决方案完成的任何自定义。导入Dynamics 365 CE组织后,我们还可以创建或删除非托管解决方案的现有组件。没有直接的方法可以在一个步骤中卸载非托管解决方案,因此我们必须逐个删除组件。

托管解决方案

当我们不希望我们的解决方案在目标系统中是可编辑的时,我们会将解决方案导出为托管解决方案。托管解决方案可以轻松安装和卸载。我们不需要像在非托管解决方案中那样删除单个组件。在目标系统中安装托管解决方案时,它不会覆盖系统的现有自定义项。我们的托管解决方案是否可供编辑取决于解决方案下组件的托管属性。正如您在下面的屏幕截图中看到的,我们可以为我们的组件选择不同的选项,以指示如果解决方案作为托管解决方案安装,是否可以在目标系统中修改:

我们可以在目标系统中安装托管解决方案的更新,只要它具有与早期版本的托管解决方案相同的发布服务器即可。例如,我们可以首先安装1.0.0.0版本的托管解决方案,然后在目标系统中安装1.1.0.0版本的更新版本。两种解决方案的发布者应该匹配;否则,我们将无法将更新后的解决方案导入到目标系统。

使用以下屏幕截图,我们可以了解同时安装托管和非托管解决方案时系统的行为。我们有一个账户实体表单,假设我们安装了一个托管解决方案,该解决方案也对账户实体表单进行了一些更改。用户将能够看到具有开箱即用账户实体表单设计的账户实体表单版本,以及托管解决方案的更改,如下所示:

现在,让我们想象一下,除此之外,我们还安装了一个非托管解决方案B。因为它是非托管的,所以它将覆盖早期解决方案中的更改。现在,用户将只看到解决方案B中实现的更改。

如果您不是ISV并为自己的组织进行自定义,建议使用非托管解决方案将更改分发到其他环境。但是,如果您是ISV,您应该使用托管解决方案来分发给您的客户。

导出解决方案时,建议在解决方案中仅包含自定义组件。例如,假设我们已经完成了更改,现在我们想部署我们的自定义解决方案来测试组织。我们可以在解决方案中包括所有自定义组件以及我们修改过的系统组件。我们需要记住的另一件重要的事情是,如果测试环境中还没有所有依赖项,那么就将它们包括在我们的解决方案中;否则,解决方案导入将失败。此外,如果任何解决方案组件依赖于另一个解决方案组件,则我们不能删除该组件。

在发布对现有解决方案的任何更新时,我们可以创建解决方案补丁,并且只能包括最近更新或新的项目。例如,如果我们向Account实体添加了一个新属性,那么我们只能在解决方案中包括这些属性,而不能包括Account实体中的所有组件,如表单、视图和所有字段。

要查看有关解决方案修补程序的更多详细信息,请参阅

Use cloned solutions and patches in Dynamics 365 Customer Engagement (on-premises) | Microsoft Learn

现在我们已经了解了解决方案,让我们自定义Dynamics 365 CE环境。

与实体合作

实体用于存储Dynamics 365 CE数据和元数据。Dynamics 365 CE中的每个实体都表示Dynamics 365 CE数据库中的一个表。当我们建立Dynamics 365 CE组织时,我们可以获得许多现成的实体,这些实体可以用于不同的目的。实体可分为两大类:

  • 系统实体
  • 自定义实体

让我们详细了解这些类别中的每一个。

系统实体

系统实体是我们通过Dynamics365CE设置获得的实体。大多数系统实体,如潜在客户、客户、联系人、机会、报价和订单,都可以轻松定制。例如,我们可以改变这些实体的形式设计;我们可以修改这些实体中可用的视图;我们可以为这些实体添加新的字段。但是,有些实体(如Rule Item、Customer Relationship和Wall View)不可用于自定义。

在默认解决方案中,我们可以使用“可自定义”列检查哪些开箱即用的实体是可自定义的,哪些实体是不可自定义的。

自定义实体

自定义实体是由我们创建的。如果我们的需求无法用任何开箱即用的系统实体来满足,我们可以创建自定义实体。我们可以创建两种类型的自定义实体:标准实体和活动类型实体。标准实体类似于开箱即用的标准系统实体,如Account、Contact和Lead。活动类型实体是一个特殊的实体,我们可以在其中获得不同的特殊PartyList字段,从而可以选择多种类型的实体记录。例如,对于电子邮件实体中的字段,我们可以向帐户、联系人或用户发送电子邮件。

创建解决方案时,可以使用“添加现有实体”按钮将现有实体添加到解决方案中,也可以创建新实体。在将现有实体添加到我们的解决方案中时,我们应该始终只包括要自定义的组件,而不是将整个实体添加到解决方案中。通过这种方式,我们可以保持我们的解决方案轻松分发。

现在我们已经了解了Dynamics365CE实体,让我们讨论如何创建自定义实体。

创建自定义实体

让我们想象一下,我们想要创建我们在第4章“准备功能和技术设计文件”中的“理解功能和技术性设计”一节中讨论过的实体。我们将使用以下步骤创建一个车辆实体来存储客户的车辆信息:

  • 首先,我们将创建我们的自定义解决方案。让我们想象一下,我们想把它命名为HIMBAP汽车服务。从make.powerapps.com导航到“解决方案”,然后单击“新建解决方案”按钮。我们可以按照屏幕截图中显示的编号顺序进行操
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Cpp五条/article/detail/687866
推荐阅读
相关标签
  

闽ICP备14008679号