Dynamics CRM中2016产生巨大的Excel文件进​​行营销列表

Question

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

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

详细
我们的客户使用，更详细的流程，如下：创建

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

的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是我们用于基于例如序列号创建OCR编号的工具。联系人和活动，以及在支付相应发票时解释创建的号码。

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”和“processts”列（见下文）。出口40 000名成员时，它包含80套这些栏目。这些列在Dynamics CRM视图中不存在。

 
    Complete Name Generated OCR processid processts 
    Henric Fröberg 800004450000165 

我的问题

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

我们使用动态CRM 2016内部部署，汇总1（8.1.0.359），但我们有困难，出口营销列表Excel文件安装汇总1.

Answer 1

据我们之前可以看到，平台中增加了这些额外的列。我们尝试使用仅包含默认解决方案的列的营销列表中的导出成员，并且仍然添加processid和processts列。然而，通过观察两个事实，我们能够解决这个问题。

观测

• 导出过程中，查询的运行中包含执行的外与进程加入，除了预期listmember LinkEntity一个LinkEntity。从Advanced Find查看（和导出）营销列表成员时，此实体不存在。
• 添加的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条记录（而不是常规的50％/ 100/250）。因此，加载页面通常需要一些时间，并且经常弹出“无响应页面”警告。但通过稍微等一下，视图就会加载。导出时，processid和processts仍将显示在文件中，但数量会更少，因为PageInfo.Count已增加。现在文件大小减少了很多，它所包含的数据量更合理。

对于这个问题

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