는 고객의

Question

배경
하나는 자신의 연락처의 부분 집합에 청구서와 함께 매월 정보를 전송 마케팅 목록에 대한 대규모 Excel 파일을 생성합니다. 이러한 연락처는 먼저 마케팅 목록에 추가되고 연락처의 이름, 주소 정보 및 OCR 번호는 으로 추출됩니다. 이러한 멤버를 Excel 파일로 내보낼 때 (인쇄용으로 보낼 수 있기 때문에) 고객이 파일을 생성하는 데 많은 문제가있었습니다. 우리가 성공하자 생성 된 Excel 파일 은 크기가 약 550MB이며 약 40k 행과 10 개 미만의 이름 및 주소 정보 열에 해당합니다. 잠시 후 Dynamics CRM에서 데이터가없는 160 개의 숨겨진 열이 추가로 생성되었음을 확인했습니다. 을 삭제하면 파일 크기가 4MB로 줄어 들었습니다. 이 칼럼들은 "processid"와 "processts"라는 이름으로 번갈아 사용되었습니다.

이 문제는 예를 들어. 고급 인보이스를 찾으십시오.이 경우 수출 시간에 플러그인을 실행하기 때문에 Dynamics CRM이 특별한 작업을하는지 궁금합니다.

1. 캠페인이 생성됩니다

   에 대한 자세한 사항
   우리의 고객이 더 구체적으로, 사용하는 흐름은 다음과 같다. 이 캠페인은 생성하는 고유 한 ID 인 순번을 가져옵니다.

2. 마케팅 목록이 만들어지고 캠페인에 연결됩니다.
3. 회원은 마케팅 목록에 추가됩니다. 이 회원은 고유 한 ID 인 일련 번호도 가지고 있습니다.
4. 마케팅 목록 양식에서 마케팅 목록 구성원으로 전환하십시오.
5. 작성한 사용자 정의보기 인 "보기 내보내기"를 선택하십시오. 최소한의 재현에서이보기에는 컨택의 완전한 이름과 "생성 된 OCR"필드가 포함됩니다.
6. 여러 연락처 검색 후 등록 된 플러그인이 트리거되고 일련 번호와 캠페인의 일련 번호를 기반으로 마케팅 목록의 각 구성원에 대한 OCR 번호가 만들어집니다. 그런 다음 "생성 된 OCR"필드에 추가됩니다.
7. 그러면보기가 Excel로 내보내집니다. 플러그인이 다시 트리거됩니다.
8. 내보내기가 성공하면, 생성 된 파일은 "빈 열 번호 표시"프로세스 id "와 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 번호를 만드는 Google의 도구입니다. 연락처 및 캠페인뿐만 아니라 해당 인보이스가 지불 될 때 생성 된 번호를 해석 할 수 있습니다.

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

하나의 멤버 마케팅 목록에 대한 수출 구성원이 파일은 "프로세스 id"와 "processts"열 (아래 참조)의 한 세트를 포함 결과입니다. 40,000 명의 회원을 내보낼 때이 열이 80 세트 포함됩니다. 이러한 열은 Dynamics CRM의보기에 없습니다.

 
    Complete Name Generated OCR processid processts 
    Henric Fröberg 800004450000165 

내 질문에

• 왜 이러한 추가 열이 추가됩니다?
• 내 보낸 멤버 수와 열의 수 사이에 상관 관계가있는 것으로 보이는 이유는 무엇입니까?
• 이 문제를 방지하기 위해 파일 크기가 으로 줄어들 수 있도록하려면 어떻게해야합니까? 우리는 역학 CRM 2016을 사용하고

온 - 프레미스, 마케팅 목록에 대한 Excel 파일을 수출 롤업 1 (8.1.0.359), 그러나 우리가 했어요 어려움이 우리로 지금까지

Answer 1

롤업 1을 설치하기 전에 플랫폼에서 이러한 추가 열을 추가하는 고유 한 것이 있습니다. 우리는 기본 솔루션의 열만있는 마케팅 목록에서 회원을 내보내려고했지만 processid 및 processts 열이 계속 추가되었습니다. 그러나 우리는 두 가지 사실을 관찰함으로써이 문제를 해결할 수있었습니다.

관찰

• 수출 동안 쿼리 실행은 LinkEntity listmember 기대뿐만 아니라, 프로세스와 외부 조인을 수행하는 LinkEntity이 포함되어 있습니다. 이 LinkEntity는 고급 찾기에서 마케팅 목록 구성원을보고 내보낼 때 존재하지 않습니다.
• processid 및 processts 열의 수는 쿼리의 속성에 반비례합니다.
  는 따라서, 쿼리에 다음과 같은 수정 보인다

작업 지금까지 작동합니다 :

• 는 PageInfo.Count
을 증가 쿼리
• 에서 프로세스 LinkEntity 제거

코드
이렇게하려면 PreContactRetrieveMultiple 플러그인을 추가하여 적절하게 쿼리를 수정하십시오.플러그인은 기본적으로 다음과 같습니다 다음 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; 
     } 
    } 
} 

결과
, 그것은보기가 대신 (한 번에이 5000 개 기록을로드하는 것을 의미합니다 일반 100분의 50/250). 따라서 페이지를로드하는 데 종종 시간이 걸리고 "Unresponsive page (페이지가 응답하지 않음)"라는 경고가 자주 표시됩니다. 그러나 조금 기다리면보기가로드됩니다. 내보낼 때 processid 및 processts은 여전히 ​​파일에 표시되지만 PageInfo.Count가 증가하면 훨씬 작은 숫자로 표시됩니다. 이제는 파일 크기가 훨씬 줄어들고 포함 된 데이터의 양이 더 합리적입니다. 이러한 추가 열이 추가 된 이유를 모르겠어요 질문

• 에

  답변.

• 플랫폼은 모든 데이터를 가져 오는 데 필요한 모든 페이징에 대해 한 번씩 열 쌍을 추가하는 것처럼 보입니다.
• 위의 플러그인은 내보내기의 파일 크기를 줄이기 위해 트릭을 수행하는 것으로 보입니다.