받은 배달 작업을 위한 모범 사례

• 받은 ZIP 파일이 큰 경우 Windchill 서버에 ZIP 파일을 저장하고 새 외부 저장 첨부 옵션

을 선택하면 업로드 속도를 향상시킬 수 있습니다.

• Windchill 서버가 클러스터 환경에 있을 경우 모든 클러스터 레이어에서 받은 ZIP 파일을 사용할 수 있는지 확인하십시오.

• 발송자가 제공한 매니페스트 파일 또는 오프라인 뷰어를 검토하는 것이 좋습니다. 오프라인 뷰어를 검토하려면 가져오기 전에 파일 시스템에서 ZIP 파일의 압축을 풀어야 합니다. 업로드하려면 원본 ZIP 파일이 필요합니다. 매니페스트 파일을 검토하려면 ZIP 파일을 업로드하고 받은 배달에서 매니페스트를 검토해야 합니다.

매핑 정의는 소스 시스템 정보를 대상 시스템에 적합한 형식으로 변환하기 위한 유용한 도구입니다. 매핑 정의는 지침으로 제공된 속성(예: 컨텍스트, 폴더 및 라이프 사이클 템플릿) 및 시스템에서 로컬로 관리되는 비즈니스상 중요한 속성(예: 소유 조직, 라이프 사이클 상태 및 보안 레이블)에서의 변환을 제공할 수 있습니다.

• 받은 배달 가져오기 미리 보기 작업을 사용하여 받은 배달 데이터를 가져오기 전에 매핑 정의를 설정합니다.

• 미리 보기 창에서 매핑 정의 내의 소스 시스템 정보로 직접 정보를 복사할 수 있도록 미리 보기 및 매핑 정의를 병렬로 사용합니다.

• 매핑 정의를 설정하기 전에 유형 정의, 속성 정의 및 버전 지정 체계 정의 불일치를 고려하고 해결합니다.

◦ 소스 시스템의 정보를 사용자 구성에 직접 추가(예: 동일한 이름의 폴더 작성)하는 것이 더 효율적인지, 아니면 매핑을 정의하는 것이 더 효율적인지 고려합니다.

◦ 가져온 후 객체가 따르는 비즈니스 프로세스를 나타내는 라이프 사이클 템플릿 매핑을 사용하는 것이 좋습니다. 객체가 대상 시스템에서 소스 시스템과 동일한 비즈니스 프로세스를 따르는 것은 대부분 바람직하지 않으므로 객체에 대해 워크플로 프로세스를 시작하지 않는 라이프 사이클 템플릿에 대한 매핑을 정의하는 것이 좋습니다.

▪ 소스 시스템 라이프 사이클 템플릿에 대한 상관 관계를 유지하려는 경우 소스 시스템의 기본 라이프 사이클 템플릿 표현에 매핑하거나, 전송 시스템에서 가져온 정보에 대해 단순히 기본 라이프 사이클을 사용합니다.

▪ 고급 라이프 사이클 템플릿에 대한 매핑을 가져온 객체에 대해 워크플로를 시작해야 하는 경우로만 제한합니다.

▪ 고급 라이프 사이클을 사용하는 경우 객체를 다시 가져오면 대상 시스템의 변경 사항을 덮어쓰기 때문에 객체 변경을 도입하지 않는 워크플로 프로세스와 연관되어야 합니다.

• 가능한 경우 특정 소스 시스템에서 첫 번째 받은 배달을 가져온 후 매핑을 변경하지 마십시오. 매핑 정의를 변경하면 데이터 구성 문제가 발생할 수 있습니다.

• 받은 배달 가져오기 미리 보기 창의 컨텍스트 관련 정보 섹션에 있는 소스 값 필드에서 사용 가능한 텍스트를 사용하여 매핑 속성에 대한 소스 시스템 정보를 채웁니다.

• 매핑을 정의하는 사용자에게 폴더 위치, 라이프 사이클 템플릿 등 시스템의 관련 객체에 대한 적절한 권한이 있어야 합니다.

• 매핑 정의를 주기적으로 검토하여 잘못되었거나 사용되지 않는 매핑 정의를 제거 또는 변경합니다.

• 받은 배달 가져오기 미리 보기 작업과 매핑 정의 작업을 병렬로 사용합니다. 이렇게 하면 받은 배달 가져오기 미리 보기 창에서 정보를 복사하여 적절한 매핑 정의의 소스 시스템 정보에 붙여 넣을 수 있습니다.

• 받은 배달 가져오기 성능은 여러 등록 정보를 사용하여 제어할 수 있습니다. 등록 정보는 받은 배달 가져오기의 관리 방법을 제어합니다. 순차적으로 또는 트랜잭션이나 스레드를 사용하여 가져오기를 처리할 수 있습니다. 다음 등록 정보를 설정하여 성능을 최대화할 수 있습니다.

가져오기 중 문제가 있을 경우 일부만 가져올 수 있으므로 여러 트랜잭션을 사용하면 받은 배달 가져오기 성능에 향상에 유용할 수 있습니다. 권한 있는 사용자는 성공한 트랜잭션으로 가져온 객체를 사용할 수 있습니다. 실패한 트랜잭션은 조정 후에 다시 시도할 수 있습니다. 기본적으로 이 등록 정보는 1로 설정되어 있습니다. wt.ixb.tag.apply.TransactionTag.enableCount 등록 정보가 75000 이상으로 설정된 경우 이 등록 정보는 4로 설정됩니다.

◦ wt.ixb.tag.apply.TransactionTag.enableCount: 받은 배달 파일의 객체 수에 따라 여러 트랜잭션으로 나누는 임계값을 설정합니다.

사이트에서 여러 트랜잭션을 사용하여 받은 배달 파일을 가져오는 경우 이 등록 정보의 값을 설정하여 각 트랜잭션에 포함될 수 있는 최대 객체 수를 결정해야 합니다. 이 값은 객체 간의 링크를 제외하고 배달 파일에 포함된 객체 수로 측정됩니다. 예를 들어, 이 값을 3000으로 설정하고 배달에 5500개의 객체가 포함되어 있는 경우 가져오기가 두 개의 트랜잭션으로 나뉩니다. 기본적으로 이 등록 정보는 75000으로 설정되어 있습니다.

여러 스레드 사용은 받은 배달 가져오기 성능에 가장 큰 영향을 줍니다. 스레드는 같은 데이터베이스 연결을 공유하며, 임계값에 도달할 경우 성능에 영향을 줄 수 있습니다. 객체 수도 성능에 영향을 줄 수 있습니다. 객체 수가 많을수록 여러 스레드를 사용할 때의 성능 향상이 커집니다. 일반적으로 증분 패키지 배달에는 하나의 스레드로 충분합니다. 초기 패키지 배달의 경우, 특히 가져오기 시간이 짧으면 여러 스레드를 사용하는 것이 유용할 수 있습니다. 기본적으로 이 등록 정보는 1로 설정되어 있습니다.

wt.ixb.import.maxThreads 등록 정보의 값은 가져오기에 사용되는 트랜잭션 수를 결정하는 wt.ixb.import.noOfParallelImportPaths 등록 정보와 함께 사용됩니다.

• 단일 트랜잭션 시나리오: wt.ixb.import.noOfParallelImportPaths 등록 정보가 1로 설정된 경우 wt.ixb.import.maxThreads 등록 정보의 값은 가져오기에 사용된 총 스레드 수입니다.

• 여러 트랜잭션 시나리오: wt.ixb.import.noOfParallelImportPaths가 1보다 큰 값으로 설정된 경우 wt.ixb.import.maxThreads 등록 정보의 값은 가져오기 트랜잭션당 사용된 스레드 수입니다.

일괄 처리 크기가 받은 배달 가져오기 성능에 미치는 영향은 크지 않습니다. 등록 정보를 설정하여 각 가져오기 일괄 처리의 객체 수를 결정할 수 있습니다. 기본적으로 이 등록 정보는 10000으로 설정되어 있습니다.

• 가져오는 동안 받은 배달 가져오기 미리 보기 창에서 선택한 것과 동일한 가져올 위치 옵션을 사용합니다.

• 가져올 때 이 가져오기 프로세스 중에 제공한 최신 해결 저장 옵션을 사용하여 해결을 저장합니다. 이렇게 하면 나중에 동일한 소스 시스템에서 다른 받은 배달을 가져올 때 이러한 선택 항목을 재사용할 수 있습니다.

• 받은 배달 가져오기는 RDImportExecutorQueue를 사용하여 처리됩니다. 자세한 내용은 바로 사용할 수 있는 백그라운드 대기열을 참조하십시오.

• 받은 배달 가져오기에 성공한 후 배달과 연관된 업로드된 ZIP 파일을 제거하여 아카이브 성능을 향상시킬 수 있습니다. 가져오기에 성공할 경우 ZIP 파일을 자동으로 제거하려면 com.ptc.windchill.rd.cleanupFilesOnSuccessfulImport 속성을 True로 설정할 수 있습니다.

로그 파일은 미리 보기 및 가져오기 작업 중 검색된 항목에 대한 세부내용과 함께 받은 배달 정보 페이지에서 사용할 수 있습니다. 이러한 로그 파일을 사용하여 가져오기 프로세스 중에 발생한 경고 및 오류를 조사하고, 가져온 객체 및 링크를 식별하고, 가져올 때 충돌이 발생한 객체나 충돌로 인해 건너뛴 객체를 확인할 수 있습니다. 자세한 내용은 받은 배달 가져오기 로그 검토를 참조하십시오.