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

Question

背景
我们的一位客户将每月的信息以及发票发送到他们的联系人的一部分。这些联系人首先添加到营销列表中，然后联系人的名称，地址信息和OCR号码是提取。将这些成员导出到Excel文件时（可以发送以进行打印），我们的客户遇到了巨大的问题以生成文件。一旦成功，我们就意识到生成的Excel文件约为550 MB的大小，大约40k行，少于10列的名称和地址信息。一段时间后，我们发现Dynamics CRM生成了另外的160列，其中包含数据。删除这些列将文件大小降低到更合理的4 MB。这些列在被命名为" processID"one_answers" processts"之间交替。

导出时不会发生此问题。来自Advanced Find的发票，所以我很想知道Dynamics CRM是否做一些特别的事情，因为在这种情况下我们在导出时间运行插件。

详细信息
我们的客户更详细地使用的流量如下：

1. 创建了一个广告系列。该广告系列有一个序列号，我们生成的唯一ID。
2. 创建了一个营销清单，并连接到广告系列。
3. 成员被添加到营销清单中。这些成员也有一个序列号，一个唯一的ID。
4. 从营销清单表格切换到营销清单的成员。
5. 选择"导出视图"，这是我们创建的自定义视图。在我的最小repro中，此视图仅包含联系人的完整名称以及"生成的OCR"字段。
6. 在邮政联系中注册的插件会触发，并根据其序列编号加上广告系列的序列编号为营销列表的每个成员创建一个OCR号。然后将其添加到"生成的OCR"字段中。
7. 然后将视图导出到Excel。插件再次触发。
8. 如果导出成功，则生成的文件包含许多空列，标记为" processID"和ProcessTS"。

postcontactretievemultiple插件

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);
            }
        }
    }
}

广告系列（剪切无关的代码）
下面使用的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"one_answers" ProcessTs"列（见下文）。导出40 000个成员时，它包含80组这些列。这些列不存在于Dynamics CRM中的视图中。

    完整的名称生成的OCR ProcessID Processts    HenricFröberg800004450000165

我的问题

• 为什么添加这些额外的列？
• 为什么似乎有一个导出成员人数与数量添加了列？
• 我们该怎么做才能防止这种情况，以携带文件大小出口量？

我们使用的是Dynamics CRM 2016本地，汇总1（8.1.0.359），但是在安装汇总之前，我们很难将Excel文件导出以进行营销列表。

Answer 1

据我们所知，平台中固有的东西添加了这些额外的列。我们已经尝试了从营销列表中的导出成员，只有默认解决方案中的列，并且仍然添加了processid和processts列。但是，我们能够通过观察两个事实来解决这个问题。

观察

• 在导出期间的查询运行包含一个链接率，除了预期的list -member链接范围外，还可以执行与进程的外部连接。查看（和导出）营销列表成员的高级查找。
时，这种联系不存在。
• 添加的processid和processts列的数量与查询的PageInfo.Count属性成反比。

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

• 从查询中删除过程链接
• 增加pageinfo.count

代码
这是通过添加一个前牙术插件来完成的，该插件可以相应地修改查询。插件基本上看起来像这样：

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的增加，数量较小。现在，文件大小已大大减少，并且对其包含的数据量更合理。

答案

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