本节开始讲实体中的基础数据存储对象，也就是字段。DynamicsCRM目前总共有13种字段类型，分别为单行文本、选项集、多选选项集、两个选项、图像、整数、浮点数、十进制数、货币、多行文本、日期和时间、查找、客户。如下图： 不同字段有不同的应用场景，下面会对每种类型进行详细的讲解。首先我们需要确定好要为哪个实体进行字段的添加，确定好后找到对应的实体，点击其对应的字段项就可以进入字段操作的界面。切换视图通过字段的可定义程度对字段进行筛选。 列表操作有新建、编辑以及删除等基本操作，其中删除和编辑需要选中字段后才可以使用。 下面开始新建字段，点击新建按钮就可以看到弹出一个新建字段的页面 显示名称：字
本节开始讲DynamicsCRM的窗体排版和设计，窗体也就是我们实际可以看到的表单界面。DynamicsCRM提供了一套独立的表单模板设计引擎，可以很方便的为开发者提供无代码开发，只需要简单的拖动和配置就可以完成一个表单的创作。首先我们定位到实体对于的窗体功能下 上图就是窗体的操作页，首先是窗体的创建。我们新创建一个实体后系统会默认给我们创建四个窗体。根据窗体类型的不同大致可以分为四种，分别是主窗体、快速视图窗体、快速创建窗体、卡窗体。主窗体：是为实体进行数据交互的主要窗体，多个主窗体可以进行切换。快速视图窗体：这些窗体出现在主窗体中，用于显示窗体中某个查找字段引用的某个记录的其他数据。快速创
本节开始讲DynamicsCRM的窗体排版和设计，窗体也就是我们实际可以看到的表单界面。DynamicsCRM提供了一套独立的表单模板设计引擎，可以很方便的为开发者提供无代码开发，只需要简单的拖动和配置就可以完成一个表单的创作。首先我们定位到实体对于的窗体功能下 上图就是窗体的操作页，首先是窗体的创建。我们新创建一个实体后系统会默认给我们创建四个窗体。根据窗体类型的不同大致可以分为四种，分别是主窗体、快速视图窗体、快速创建窗体、卡窗体。主窗体：是为实体进行数据交互的主要窗体，多个主窗体可以进行切换。快速视图窗体：这些窗体出现在主窗体中，用于显示窗体中某个查找字段引用的某个记录的其他数据。快速创
DynamicsCRM在实施过程中会遇到很多多个实体关联的问题，这样可以实现多个实体的记录通过关联的字段实现数据的综合展示，在SqlServer里面叫做外键，在DynamicsCRM叫做关系。DynamicsCRM有三种实体间的关系。分别是1：N，N:1以及N:N1：N关系顾名思义1：N关系就是一对多关系，也可以理解为主从表关系。在CRM建立方式就是在子表建立一个与主表关联的外键字段，这个字段就是一个关联了主实体的LookUp的字段。建立好之后就完成了1：N关系的建立。1：N关系的应用场景1：N关系的应用场景一版有以下几种，主从表、字段映射、字段的限制主从表关系前面窗体有讲到过，可以通过建立1
DynamicsCRM在实施过程中会遇到很多多个实体关联的问题，这样可以实现多个实体的记录通过关联的字段实现数据的综合展示，在SqlServer里面叫做外键，在DynamicsCRM叫做关系。DynamicsCRM有三种实体间的关系。分别是1：N，N:1以及N:N1：N关系顾名思义1：N关系就是一对多关系，也可以理解为主从表关系。在CRM建立方式就是在子表建立一个与主表关联的外键字段，这个字段就是一个关联了主实体的LookUp的字段。建立好之后就完成了1：N关系的建立。1：N关系的应用场景1：N关系的应用场景一版有以下几种，主从表、字段映射、字段的限制主从表关系前面窗体有讲到过，可以通过建立1
DynamicCRM插件中记录日志的方式有多种通常情况下分为ITracingService记录、单独日志表插入记录、文本记录三种。之前整理过ITracingService记录的方式，但这种记录有限制，只有存在异常时才会在插件跟踪日志中查到，异常报错时排查问题到可以，但插件详细的日志记录查看就不很方便，并且插件跟踪日志中记录到最上层的插件，直接通过插件名查询不方便。 单独日志表的方式，也很简单，自定义一个日志表，在插件中调用封装好的日志插入方法即可，但这个存在一个致命的问题，像是普通的信息记录没问题，若存在异常，插入操作会回滚，所以无法通过这种记录排查异常。 第三种文本记录，需要引用第三方组件，
DynamicCRM插件中记录日志的方式有多种通常情况下分为ITracingService记录、单独日志表插入记录、文本记录三种。之前整理过ITracingService记录的方式，但这种记录有限制，只有存在异常时才会在插件跟踪日志中查到，异常报错时排查问题到可以，但插件详细的日志记录查看就不很方便，并且插件跟踪日志中记录到最上层的插件，直接通过插件名查询不方便。 单独日志表的方式，也很简单，自定义一个日志表，在插件中调用封装好的日志插入方法即可，但这个存在一个致命的问题，像是普通的信息记录没问题，若存在异常，插入操作会回滚，所以无法通过这种记录排查异常。 第三种文本记录，需要引用第三方组件，
相较于其他函数计算项目，OpenFunction有很多独特的功能，其中之一便是通过Dapr与各种后端服务（BaaS）无缝集成。目前OpenFunction已经支持了Dapr的pub/sub和bindings构建模块，未来还会支持更多功能。截止到v0.7.0，OpenFunction与BaaS的集成还不算特别丝滑，需要在每个函数实例的Pod中注入一个DaprSidecar容器，这就会导致一个问题：整个函数实例的启动时间会受到DaprSidecar容器启动时间的影响，甚至DaprSidecar容器可能会比函数容器本身消耗的资源更多。为了解决这个问题，OpenFunction发布了v0.8.0，引入
相较于其他函数计算项目，OpenFunction有很多独特的功能，其中之一便是通过Dapr与各种后端服务（BaaS）无缝集成。目前OpenFunction已经支持了Dapr的pub/sub和bindings构建模块，未来还会支持更多功能。截止到v0.7.0，OpenFunction与BaaS的集成还不算特别丝滑，需要在每个函数实例的Pod中注入一个DaprSidecar容器，这就会导致一个问题：整个函数实例的启动时间会受到DaprSidecar容器启动时间的影响，甚至DaprSidecar容器可能会比函数容器本身消耗的资源更多。为了解决这个问题，OpenFunction发布了v0.8.0，引入
什么是 SolutionPublisher?官方介绍： SolutionPublisher|MicrosoftDocs创建组件的解决方案的发布者被认为是该组件的所有者。也就是说解决方案发布者指定了是谁开发了这个应用程序或组件。因为每个解决方案都有一个发布者，所以应该创建一个有意义的发布者，而不是使用默认发布者。每个解决方案发布者都有一个前缀（prefix），这也是为了可以避免命名冲突。如何创建SolutionPublisher?创建SolutionPublisher有两种方式（界面、代码），代码方式可以参考官方给的代码，CreateAPublisher |MicrosoftDocs界面创建的步
