Dynamics CRM 2016为营销列表生成庞大的Excel文件

背景
我们的客户之一将每月的信息连同发票一起发送给他们的联系人的子集。 这些联系人首先被添加到市场营销列表中，然后提取联系人的姓名，地址信息和OCR号码。 当将这些成员导出到一个Excel文件（这样它可以被发送打印）时，我们的客户甚至产生了大量的问题，甚至生成文件。 一旦我们成功了，我们意识到生成的Excel文件大小约为550 MB，大约有40k行和less于10列的名称和地址信息。 过了一段时间，我们发现Dynamics CRM生成了另外160个隐藏的列，不包含任何数据。 删除这些列将文件大小降低到更合理的4 MB。 这些列之间交替被命名为“processid”和“processts”。

从高级查找导出例如发票时，这个问题不会发生，所以我很想知道Dynamics CRM是否做了一些特殊的事情，因为在这种情况下，我们在导出时正在运行一个插件。

细节
我们的客户更详细地使用的stream程如下：

1. 广告系列已创build。 此广告系列会获得序列号，这是我们生成的唯一ID。
2. 营销列表已创build，并与广告系列相关联。
3. 成员被添加到市场营销列表。 这些成员也有一个序列号，一个唯一的ID。
4. 从营销列表表单切换到市场营销列表的成员。
5. select我们创build的自定义视图“导出视图”。 在我最小的repro中，这个视图只包含联系人的完整名称加上“生成的OCR”字段。
6. 一个在post上注册的插件检索多个，被触发，并根据它们的序列号加上活动的序列号为每个销售列表的成员创build一个OCR编号。 然后将其添加到“生成的OCR”字段。
7. 该视图然后导出到Excel。 插件被再次触发。
8. 如果导出成功，则生成的文件包含多个空列，标记为“processid”和“processes”。

PostContactRetrieveMultiple插件

protected override void Execute(PluginVars variables) { if (variables.Context.InputParameters.Contains("Query") && variables.Context.InputParameters["Query"] is QueryExpression) { QueryExpression objQueryExpression = (QueryExpression) variables.Context.InputParameters["Query"]; //Generate and fill the ocr number field when requested if (objQueryExpression.EntityName == Contact.EntityLogicalName && objQueryExpression.ColumnSet.Columns.Contains("company_generatedocr")) { if (objQueryExpression.LinkEntities.Count > 0 && objQueryExpression.LinkEntities.Count(le => le.LinkToEntityName == ListMember.EntityLogicalName) > 0) { var contacts = ((EntityCollection)variables.Context.OutputParameters["BusinessEntityCollection"]); Guid relatedListGuid = (Guid)objQueryExpression.LinkEntities.First(le => le.LinkToEntityName == ListMember.EntityLogicalName).LinkCriteria.Conditions[0].Values[0]; CampaignExtensions.GenerateOcrNumbersForCollection(contacts, relatedListGuid, variables.Dao); } } } } 

CampaignExtensions（剪下不相关的代码）
下面使用的OCREngine是我们的工具，用于根据联系人和广告系列的序列号创buildOCR编号，以及在支付相应的发票时解释创build的编号。

 public static void GenerateOcrNumbersForCollection(EntityCollection entityCollection, Guid marketingListId, DataAccess dao) { var campaignSequenceNumber = GetCampaignSequenceNumberFromList(marketingListId, dao); foreach (var entity in entityCollection.Entities) { string sequenceNumber = entity.GetSequenceValue(dao); //Get the sequence number for the contact var spec = new OCRSpecification(); spec.DonorNumber = sequenceNumber; spec.CampaignNumber = campaignSequenceNumber; entity.Attributes.Add("company_generatedocr", OCREngine.GenerateOCR(spec)); } } 

结果
当只有一个成员将营销列表的成员导出时，该文件只包含一组“processid”和“processes”列（见下文）。 出口40 000名成员时，包含80套这些栏目。 这些列不在Dynamics CRM的视图中。

    完整名称生成的OCR processid processes
     HenricFröberg800004450000165

我的问题

• 为什么添加这些额外的列？
• 为什么出口成员的数量和添加的列数之间似乎有相关性？
• 我们可以做些什么来防止这种情况，使出口文件的大小下降？

我们正在使用Dynamics CRM 2016 on-premise汇总1（8.1.0.359），但是在安装汇总1之前，我们在导出Excel文件时遇到了困难。

Answer 1

就我们所看到的，这个平台中固有的东西是增加了这些额外的列。 我们已经尝试了只有来自默认解决scheme的列的营销列表中的导出成员，并且仍然添加了processid和processts列。 然而，我们可以通过观察两个事实来解决这个问题。

意见

• 在导出过程中运行的查询包含一个LinkEntity，除了期望的列表成员LinkEntity之外，它还执行一个包含进程的外连接。 从“高级查找”查看（和导出）市场营销列表成员时，此实体不存在。
• 所添加的processid和processts列的数量与查询的PageInfo.Count属性成反比。

操作
因此，以下对查询的修改似乎正在工作到目前为止：

• 从查询中删除进程LinkEntity
• 增加PageInfo.Count

码
这是通过添加一个PreContactRetrieveMultiple插件，相应地修改查询完成的。 插件基本如下所示：

 public class PreContactRetrieveMultiple : CrmPlugin { protected override void Execute(PluginVars variables) { if (variables.Context.InputParameters.Contains("Query") && variables.Context.InputParameters["Query"] is QueryExpression) { QueryExpression objQueryExpression = (QueryExpression) variables.Context.InputParameters["Query"]; var processQuery = query.LinkEntities.FirstOrDefault(le => le.LinkFromAttributeName == "processid"); if (processQuery != null) { query.LinkEntities.Remove(processQuery); } query.ColumnSet = new ColumnSet(query.ColumnSet.Columns.Distinct().ToArray()); query.ColumnSet.Columns.Remove("processid"); query.ColumnSet.Columns.Remove("processts"); query.PageInfo.Count = 5000; } } } 

结果
随着PageInfo.Count的增加，这意味着视图将一次加载这5000条logging（而不是常规的50/100/250）。 因此，加载页面通常需要一些时间，并且经常popup“无响应页面”警告。 但是等一下，视图就会加载。 在导出时， processid和processts仍然会显示在文件中，但是数量会更less，因为PageInfo.Count已经增加了。 现在文件大小已经大大减less，对于包含的数据量来说更合理。

问题的答案

• 我不知道为什么这些额外的列被添加。
• 该平台似乎为获取所有数据所需的每个分页添加一对列。
• 上面显示的插件似乎有窍门，减less出口的文件大小。