특수 구성 "1C: 데이터 변환 2.0"

1C:Enterprise 플랫폼의 8번째 버전 출시는 자동화 시스템 개발의 중요한 단계가 되었습니다. 1C:Enterprise 8 플랫폼을 설계할 때 1C:Enterprise 7.7 플랫폼 기반 솔루션 사용에 대한 방대한 경험이 고려되었습니다. 새로운 플랫폼의 장점을 실현하는 새로운 산업 솔루션이 만들어졌습니다. 새 플랫폼에서 이전 언어 구성을 사용하는 것이 부적절해졌습니다.

이 문제의 해결(버전 7.7에서 버전 8로의 데이터 전송)을 용이하게 하기 위해 1C는 특수 구성 "데이터 변환 2.0"을 출시했습니다. 데이터 전송의 다양한 문제를 해결하는 전문가를 돕기 위해 만들어졌습니다. 1C는 예를 들어 1C: Accounting 7.7에서 1C: Accounting 8로 동일한 유형의 구성에서 데이터를 전송하기 위한 기성품 규칙을 출시했지만 1C: Enterprise 8 플랫폼으로 전환할 때 비표준 또는 수정된 표준 구성의 사용자 전송 규칙 데이터를 직접 생성해야 합니다.

데이터 전송 문제를 해결하기 위한 모든 다양한 개인 방법을 통해 해결해야 할 문제의 범위는 실질적으로 변경되지 않습니다.

참조 정보 동기화(신규 생성, 업데이트 기존 요소디렉토리, 계층 구조 삭제, 저장 또는 변경, 데이터 분기, 주기적 세부 정보 값 변경 기록 전송);

문서 및 작업의 동기화(문서 작성, 수정 또는 한 유형의 문서를 다른 유형으로 변환, 병합 또는 복제)

유지 관리를 위한 회계 장부를 위한 충분한 초기 조건 생성 경제 활동(남은 물품의 양도 등).

1C:Enterprise의 다른 버전 및/또는 구성의 데이터 저장 구조가 다르기 때문에 데이터 전송은 파일이나 테이블을 복사하는 것이 아니라 변환하는 것입니다. 변환이 명확하고 정확하려면 데이터 전송에 대한 규칙을 만들고 구성해야 합니다. 원본 데이터베이스와 대상 데이터베이스의 데이터 저장 구조를 알고 있는 경우 서로 다른 정보 베이스 간에 데이터를 전송하기 위한 규칙을 만들고 구성할 수 있습니다. 구성 메타데이터 구조에 대한 설명은 통일되어야 합니다. Data Conversion 2.0 구성은 소스 및 대상 구성 메타데이터 구조 설명을 기반으로 데이터 전송 규칙을 만들고 구성하는 데 사용됩니다.

인포베이스 간에 데이터를 전송하는 프로세스는 다음 단계로 구성됩니다.

• 1. 메타데이터 설명 파일 생성.
• 2. "데이터 변환"에서 구성 생성.
• 3. 변환 자체의 생성.
• 4. 데이터 변환 규칙의 일관된 생성.
• 5. 데이터 업로드 규칙의 일관된 생성.
• 6. 한 구성에서 다른 구성으로 데이터를 언로드 및 로드하는 실제 절차.

왜냐하면 이 특수 구성을 사용하는 것이 가장 효과적인 방법 중 하나입니다. 이 순간이러한 종류의 문제를 해결하는 방법과 교육 목적에 매우 유용한 개인 경험의 출처, LLC의 IS "서버: 임대료 계산"과 "1C: 엔터프라이즈 회계" 간의 데이터 교환 메커니즘을 개발하기 위해 " LLC"는 "Data Conversion 2.0" 구성 사용을 기반으로 하는 방법입니다.

데이터 변환 2.0 및 2.1은 8.1에서 8.3까지의 플랫폼 버전에서 구현된 1C 기술 구성입니다.

이 도구의 주요 임무는 1C 8과 7 응용 솔루션 간의 교환 규칙을 작성하는 것입니다.현재 데이터 변환 버전은 3.0입니다.

데이터 변환은 한 정보 베이스에서 다른 정보 베이스로 정보를 전송하는 문제뿐만 아니라 예를 들어 한 데이터베이스 내에서 정보를 변환하는 문제를 해결할 수 있는 매우 유용한 구성입니다.

구성은 다음과 같은 경우에 사용하기에 매우 편리합니다.

데이터 변환은 모든 프로그래머에게 유용할 것입니다. 교환 규칙을 생성하는 기술을 보유하는 것은 전문 기술에 큰 도움이 됩니다.

구성 작업 방법을 배우려면 실제 문제를 해결하는 것이 가장 적합합니다. 예를 들어, 한 데이터베이스에서 다른 데이터베이스로 정보를 전송하고, 구현 문서를 영수증 문서로 변환, "드라이브"와 같은 작업을 스스로 생각해보십시오. 현재 잔액~에 회계"잔액 입력"문서 및 기타 작업에서.

교환 1C 8.3의 "일반적인"규칙을 이해하는 것이 매우 유용합니다. 여기서 작업 구현에 대한 흥미로운 예를 종종 찾을 수 있습니다.

기본 사항을 이해하려면 자료가 필요하며 아래에서 고려하십시오.

변환을 위한 비디오 지침

"1C 데이터 변환" 구성을 사용하여 1C에서 데이터 교환을 설정하는 기본 사항은 다음 비디오를 참조하십시오.

1C Data Conversion 2.0 공부를 위한 교재, 교재

인터넷에 자료와 문서가 너무 많지 않아 가장 중요하고 흥미로운 자료를 수집하려고했습니다.

0. 우선 Ilya Leontiev의 무료 비디오 과정을 조언합니다. 링크.

1. 우선 구성에 내장된 도움말을 사용하는 것이 좋습니다. 정말 잘 쓰여지고 기술적으로 잘 구현되었습니다.

2. 두 번째로 중요한 정보 출처는 http://www.mykod.info/(사이트 폐쇄)로, 데이터 변환에만 특화된 사이트입니다. 거기에서 많은 변환 자료를 다운로드할 수 있습니다.

3. 별도로 교육 매뉴얼 교과서 - (저자 - Olga Kuznetsova)를 강조하고 싶습니다.

서로 다른 구성 간에 데이터를 마이그레이션하는 것은 쉬운 일이 아닙니다. 항상 그렇듯이 여러 솔루션이 있지만 모든 솔루션이 최적인 것은 아닙니다. 데이터 전송의 뉘앙스를 이해하고 이러한 문제를 해결하기 위한 보편적인 전략을 선택합시다.

한 솔루션에서 다른 솔루션으로의 데이터 마이그레이션 문제(순전히 1C 회사 제품에 관한 것)는 어제 발생하지 않았습니다. 1C 회사는 개발자가 마이그레이션을 만들 때 직면하는 어려움을 잘 알고 있으므로 도구를 돕기 위해 최선을 다합니다.

플랫폼을 개발하는 동안 회사는 데이터 전송을 단순화하는 기술뿐만 아니라 다양한 범용 도구를 도입했습니다. 모든 표준 솔루션에 내장되어 있으며 동일한 구성 간의 마이그레이션 문제가 일반적으로 해결되었습니다. 표준 솔루션의 긴밀한 통합으로 승리를 다시 한 번 확인했습니다.

비표준 솔루션 간의 마이그레이션에서는 상황이 다소 복잡해집니다. 광범위한 기술을 통해 개발자는 자신의 관점에서 문제를 해결하는 가장 좋은 방법을 독립적으로 선택할 수 있습니다.

그 중 몇 가지를 살펴보겠습니다.

• 텍스트 파일을 통한 교환
• 교환 계획의 사용;
• 등.

그들 각각에는 장단점이 있습니다. 요약하자면, 주요 단점은 장황할 것입니다. 마이그레이션 알고리즘을 독립적으로 구현하려면 상당한 시간 비용과 긴 디버깅 프로세스가 필요합니다. 나는 그러한 결정에 대한 추가 지원에 대해 이야기하고 싶지도 않습니다.

복잡성과 높은 유지 관리 비용으로 인해 1C 회사는 범용 솔루션을 만들었습니다. 개발 및 마이그레이션 지원을 최대한 단순화할 수 있는 기술입니다. 결과적으로 아이디어는 "데이터 변환"이라는 별도의 구성 형태로 구현되었습니다.

데이터 변환 - 표준 솔루션, 자체 구성. ITS:Prof에 가입한 모든 사용자는 사용자 지원 사이트 또는 ITS 디스크에서 이 패키지를 완전 무료로 다운로드할 수 있습니다. 설치는 1C의 다른 모든 표준 솔루션과 마찬가지로 표준 방식으로 수행됩니다.

이제 솔루션의 장점에 대해 조금 설명하겠습니다. 가장 중요한 것인 다용성부터 시작하겠습니다. 솔루션은 특정 플랫폼 구성/버전에 맞게 조정되지 않았습니다. 표준 구성과 자체 작성 구성 모두에서 똑같이 잘 작동합니다. 개발자는 새로운 마이그레이션을 생성하기 위한 보편적인 기술과 표준화된 접근 방식을 얻습니다. 솔루션의 다양성을 통해 1C:Enterprise 이외의 플랫폼에서도 마이그레이션을 준비할 수 있습니다.

두 번째 대담한 플러스는 시각 보조 장치입니다. 프로그래밍 없이 간단한 마이그레이션이 생성됩니다. 예, 예, 코드 한 줄 없이! 이것만으로도 한 번 기술을 배우고 귀중한 기술을 반복적으로 사용하는 데 시간을 할애 할 가치가 있습니다.

내가 주목하고 싶은 세 번째 장점은 데이터 배포에 대한 제한이 없다는 것입니다. 개발자 자신이 수신기 구성에 데이터를 전달하는 방법을 선택합니다. 기본적으로 두 가지 옵션을 사용할 수 있습니다. xml 파일에 업로드하는 것과 정보 베이스(COM/OLE)에 직접 연결하는 것입니다.

학습 아키텍처

우리는 이미 데이터 변환이 놀라운 일을 할 수 있다는 것을 알고 있지만 기술적인 이점이 무엇인지 아직 명확하지 않습니다. 가장 먼저 배워야 할 것은 모든 데이터 마이그레이션(변환)이 교환 규칙을 기반으로 한다는 것입니다. 교환 규칙 - IB에서 데이터를 업로드할 구조에 대한 설명이 있는 일반 xml 파일. 데이터 업로드/다운로드를 수행하는 서비스 처리는 교환 규칙을 분석하고 이를 기반으로 업로드를 수행합니다. 다운로드하는 동안 반대 프로세스가 발생합니다.

"KD" 구성은 개발자가 교환 규칙을 만드는 일종의 시각적 생성자입니다. 데이터를 업로드하는 방법을 모릅니다. CD 배포 키트에 포함된 추가 외부 서비스 처리가 이를 담당합니다. 그 중 몇 가지가 있습니다(파일 이름의 XX는 플랫폼 버전 번호).

• MDXXExp.epf- 처리를 통해 인포베이스 구조에 대한 설명을 xml 파일에 업로드할 수 있습니다. 구조에 대한 설명은 추가 분석 및 교환 규칙 생성을 위해 CD에 로드됩니다.
• V8ExchanXX.epf- 교환 규칙에 따라 정보 베이스에서 데이터를 업로드/다운로드합니다. 대부분의 일반적인 구성에서 즉시 처리가 가능합니다("서비스" 메뉴 항목 참조). 처리는 보편적이며 특정 구성/규칙에 얽매이지 않습니다.

자, 이제 위의 모든 사항을 기반으로 새 전환을 개발하는 단계를 정의해 보겠습니다.

1. 작업 정의. 어떤 데이터를 전송해야 하는지(어느 구성 개체에서), 가장 중요한 것은 어디로 전송해야 하는지 명확하게 이해해야 합니다.
2. CD로의 차후 로딩을 위한 구성 구조(소스/리시버)에 대한 설명 준비. 작업은 서비스 처리 MDXXExp.epf에 의해 해결됩니다.
3. IS의 구조에 대한 준비된 설명을 로드합니다.
4. CD의 시각적 수단을 사용하여 교환 규칙 만들기.
5. V8ExchanXX.epf 처리를 사용하여 생성된 데이터 변환 규칙에 따라 업로드/다운로드.
6. 교환 규칙 디버깅(필요한 경우).

가장 간단한 변환

데모를 위해서는 두 개의 배포된 구성이 필요합니다. 나는 "Trade Management" 10판과 작은 자체 작성 솔루션이라는 옵션에서 멈추기로 결정했습니다. 작업은 일반적인 UT 구성에서 데이터를 전송하는 것입니다. 간결하게 자체 작성 솔루션을 "수신자"라고 부르고 거래 관리를 "소스"라고 부르겠습니다. "Nomenclature" 디렉토리의 요소를 전송하여 문제 해결을 시작하겠습니다.

우선 데이터 변환 방식을 살펴보고 수행해야 할 작업 목록을 다시 읽어보겠습니다. 그런 다음 "소스" 구성을 시작하고 서비스 처리 MD82Exp.epf를 엽니다.

처리 인터페이스는 풍부한 설정으로 빛나지 않습니다. 사용자는 구조 설명에 포함되지 않는 메타데이터 개체 유형만 지정하면 됩니다. 대부분의 경우 이러한 설정은 변경할 필요가 없습니다. (예를 들어) 축적 레지스터에서 언로딩 움직임에 특별한 포인트는 없습니다.

수신기에 문서를 들고 있는 동안 움직임을 형성하는 것이 더 정확합니다. 모든 이동은 전송 후 문서 자체에서 이루어집니다. 기본 설정을 방어하기 위한 두 번째 인수는 업로드된 파일의 크기를 줄이는 것입니다.

일부 문서(특히 일반적인 구성에서)는 여러 레지스터에서 이동을 형성합니다. 이 모든 경제를 언로드하면 결과 XML 파일이 너무 커집니다. 이는 후속 운송 및 수신기 베이스로의 적재를 어렵게 만들 수 있습니다. 데이터 파일이 클수록 처리하는 데 더 많은 RAM이 필요합니다. 연습을 하다가 우연히 대용량 업로드 파일을 만났습니다. 이러한 파일은 표준 수단으로 구문 분석하는 것을 완전히 거부했습니다.

따라서 모든 기본 설정을 그대로 두고 구성 설명을 파일에 업로드합니다. 우리는 두 번째베이스에 대해 동일한 절차를 반복합니다.

CD를 열고 주 메뉴에서 선택 "디렉토리" -> "구성". 디렉토리는 변환을 생성하는 데 사용할 수 있는 모든 구성의 구조에 대한 설명을 저장합니다. 구성 설명을 한 번 로드한 다음 이를 반복적으로 사용하여 다른 변환을 생성할 수 있습니다.

디렉토리 창에서 “ 추가하다"를 클릭하고 표시되는 창에서 구성에 대한 설명이 포함된 파일을 선택합니다. "새 구성으로 업로드" 확인란을 선택하고 "업로드 수행" 버튼을 클릭합니다. 두 번째 구성의 구조에 대한 설명과 유사한 작업을 수행합니다.

이제 교환 규칙을 만들 준비가 되었습니다. 기본 CD 메뉴에서 "참조" -> "변환"을 선택합니다. 새로운 요소를 추가합니다. 새 변환 생성 창에서 소스 구성(UT 선택) 및 수신기 구성("수신기" 선택)을 지정해야 합니다. 그런 다음 "고급" 탭을 열고 다음 필드를 입력합니다.

• 교환 규칙 파일 이름 - 생성된 교환 규칙이 이 이름으로 저장됩니다. 파일 이름은 언제든지 변경할 수 있지만 지금 설정하는 것이 가장 좋습니다. 그러면 앞으로 시간이 절약됩니다. 데모 규칙의 이름을 "rules-ut-to-priemnik.xml"로 지정했습니다.
• 이름 - 변환의 이름. 이름은 절대적으로 무엇이든 될 수 있습니다. 저는 "데모. UT를 수신기로".

그게 다야, "확인"을 클릭하십시오. 즉시 모든 규칙을 자동으로 생성하라는 창이 우리 앞에 나타납니다. 그러한 유혹적인 제안에 동의하면 마스터에게 선택한 구성에 대한 설명을 자동으로 분석하고 교환 규칙을 독립적으로 생성하는 명령이 주어집니다.

바로 "and"에 점을 찍자. 마스터는 심각한 것을 생성할 수 없습니다. 그러나 이 가능성을 무시해서는 안 됩니다. 동일한 구성 간에 교환을 설정해야 하는 경우 마법사의 서비스가 매우 유용할 것입니다. 이 예에서는 수동 모드가 더 좋습니다.

"Exchange 규칙 설정" 창을 자세히 살펴보겠습니다. 인터페이스는 약간 혼란스러워 보일 수 있습니다. 컨트롤로 채워진 많은 수의 탭입니다. 사실, 모든 것이 그렇게 어렵지는 않습니다. 응용 프로그램으로 몇 시간 작업한 후에 이 광기에 익숙해지기 시작합니다.

이 단계에서는 "객체 변환 규칙"과 "데이터 업로드 규칙"이라는 두 개의 탭에 관심이 있습니다. 첫 번째 항목에서 일치 규칙을 설정해야 합니다. 두 구성의 개체를 비교합니다. 두 번째 항목에서 사용자가 언로드에 사용할 수 있는 가능한 개체를 결정합니다.

"개체 변환 규칙" 탭의 후반부에는 "속성 변환" 및 " 가치 변환". 첫 번째 항목은 선택한 개체의 속성(필수 사항)을 선택하고 두 번째 항목은 미리 정의된 값(예: 미리 정의된 사전 요소 또는 열거 요소)으로 작업하는 데 필요합니다.

좋습니다. 이제 디렉토리에 대한 변환 규칙을 생성해 보겠습니다. 두 가지 방법으로 이 작업을 수행할 수 있습니다. 개체 동기화 마법사를 사용("" 클릭)하거나 각 개체에 대해 수동으로 일치 항목을 추가합니다.

공간을 절약하기 위해 첫 번째 옵션을 사용합니다. 마법사 창에서 " 그 문서들"(우리는 디렉토리에만 관심이 있음) 그룹을 확장합니다. 참고 도서". 목록을 주의 깊게 스크롤하여 비교할 수 있는 디렉토리 이름을 살펴봅니다.

제 경우에는 Nomenclature, Organizations 및 Warehouse의 세 가지 디렉토리가 있습니다. "와 동일한 의미 로드를 수행하는 Clients 디렉토리도 있습니다. 상대방" 구성에서 " 유타". 사실, 주인은 훌륭한 이름 때문에 그들을 비교할 수 없었습니다.

우리는 이 결함을 스스로 고칠 수 있습니다. 창에서 찾기 개체 매핑» 핸드북 « 클라이언트"를 입력하고 "출처" 열에서 참조 도서 "상대방"을 선택합니다. 그런 다음 "유형" 열의 확인란을 선택하고 "확인" 버튼을 클릭합니다.

개체 동기화 마법사는 선택한 모든 개체의 속성을 변환하기 위한 규칙을 자동으로 생성하라는 메시지를 표시합니다. 속성은 이름으로 일치되며 데모에서는 이 정도면 충분하다고 동의합니다. 다음 질문은 업로드 규칙을 만드는 제안입니다. 동의합시다.

교환 규칙의 기초가 준비되었습니다. 동기화할 객체를 선택했고 속성 변환 및 업로드 규칙에 대한 규칙이 자동으로 생성되었습니다. 교환 규칙을 파일에 저장한 다음 IB "소스"(내 경우에는 UT)를 열고 서비스 처리를 시작하겠습니다. V8Exchan82.epf.

먼저 처리 창에서 우리가 생성한 교환 규칙을 선택합니다. 우리는 규칙을 로드하는 질문에 긍정적으로 대답합니다. 처리는 교환 규칙을 분석하고 언로드에 사용할 수 있는 개체에 대해 같은 이름의 트리를 만듭니다. 이 트리의 경우 데이터를 선택하는 데 필요한 항목을 변경하여 모든 종류의 필터를 설정하거나 노드를 교환할 수 있습니다. 우리는 절대적으로 모든 데이터를 업로드하기를 원하므로 필터를 설치할 필요가 없습니다.

파일에 데이터를 업로드하는 과정이 완료되면 IB " 수화기". 우리는 또한 그 안에서 처리를 엽니다. V8Exchan82.epf, 이번에는 "데이터 로드 중" 탭으로 이동합니다. 데이터 파일을 선택하고 "업로드" 버튼을 클릭합니다. 모든 데이터가 성공적으로 전송되었습니다.

현실 세계의 작업

첫 번째 데모는 오해의 소지가 있습니다. 모든 것이 매우 간단하고 논리적으로 보입니다. 사실 이것은 사실이 아닙니다. 실제 작업에서는 프로그래밍 없이 시각적 수단만 사용하여 해결하기 어렵거나 완전히 불가능한 작업이 발생합니다.

기술에 실망하지 않기 위해 몇 가지 실제 작업을 준비했습니다. 직장에서 반드시 만나게 될 것입니다. 그것들은 그렇게 사소해 보이지 않고 새로운 각도에서 데이터 변환을 보게 만듭니다. 제시된 예를 주의 깊게 고려하고 실제 문제를 해결할 때 스니펫으로 자유롭게 사용하십시오.

작업 번호 1. 누락된 정보를 입력하세요.

디렉토리 " 상대방". 수신자는 이에 대한 유사한 참고서 "클라이언트"를 가지고 있습니다. 데이터 저장에 완전히 적합하지만 소품이 있습니다. 조직"를 사용하여 조직에 속해 상대방을 분리할 수 있습니다. 기본적으로 모든 상대방은 현재 조직에 속해야 합니다(동일한 이름의 상수에서 얻을 수 있음).

문제에 대한 몇 가지 솔루션이 있습니다. 우리는 소품을 채우는 옵션을 고려할 것입니다 " 조직"바로 베이스에" 수화기", 즉. 데이터 로드 시. 현재 조직은 상수로 저장되므로 이 값을 얻는 데에는 아무런 장벽이 없습니다. 객체 변환 규칙(이하 FRP)을 열어보자 " 클라이언트"(객체를 두 번 클릭)하고 규칙 설정 마법사에서 "이벤트 처리기" 섹션으로 이동합니다. 핸들러 목록에서 " 로딩 후”.

속성에 대한 후속 할당으로 현재 조직을 가져오는 코드를 설명하겠습니다. "로드 후" 핸들러가 트리거되는 순간 객체는 완전히 형성되지만 아직 데이터베이스에 기록되지는 않습니다. 아무도 우리의 재량에 따라 그것을 변경하는 것을 금지하지 않습니다.

Object.ThisGroup이 아닌 경우 Object.Organization = Constants.CurrentOrganization.Get(); EndIf;

소품을 채우기 전에 " 조직» 속성의 값을 확인해야 합니다 « 이 그룹". 가이드 " 클라이언트» 계층 플래그가 설정되어 있으므로 그룹 확인이 필요합니다. 마찬가지로 세부 사항을 채우는 작업이 수행됩니다. 다른 처리기 옵션에 대한 도움말을 읽으십시오." 로딩 후". 예를 들어, 그 중 매개변수 " 거절". 값이 "True"로 지정되면 개체는 데이터베이스에 기록되지 않습니다. 따라서, 로딩 시 쓰기를 위한 오브젝트를 제한하는 것이 가능해진다.

작업 번호 2. 정보 등록의 세부 정보

핸드북에서 " 상대방"UT 구성, 세부 사항이 있습니다" 사는 사람" 그리고 " 공급자". 두 소품 모두 " 부울" 및 상대방의 유형을 결정하는 데 사용됩니다. IB에서 " 수화기", 참고서 " 클라이언트"비슷한 내용은 없지만 정보 등록은 있습니다" 클라이언트 유형". 유사한 기능을 수행하며 단일 클라이언트에 대해 여러 태그를 저장할 수 있습니다. 우리의 임무는 정보 등록부의 별도 기록에 세부 정보의 값을 전송하는 것입니다.

불행히도 시각적 수단만으로는 여기에 대처할 수 없습니다. 작게 시작하여 정보 레지스터에 대한 새 PCO를 생성합니다." 클라이언트 유형". 출처로 아무 것도 나열하지 마십시오. 업로드 규칙의 자동 생성을 거부합니다.

다음 단계는 업로드 규칙을 만드는 것입니다. 해당 탭으로 이동하여 " 추가하다". 업로드 규칙 추가 창에서 다음을 입력합니다.

• 샘플링 방법. "임의 알고리즘"으로 변경
• 변환 규칙. 정보 등록 "고객 유형"을 선택하십시오.
• 규칙의 코드(이름)입니다. "클라이언트 종 업로드"로 작성합니다.

이제 업로드할 데이터를 선택하는 코드를 작성해야 합니다. 여기에서 매개변수 " 데이터 샘플링". 여기에 준비된 데이터 세트가 포함된 컬렉션을 배치할 수 있습니다. 매개변수 " 데이터 샘플링" 받아들일 수 있다 다양한 의미- 쿼리 결과, 선택, 값 모음 등 클라이언트와 클라이언트 유형의 두 열이 있는 값 테이블로 초기화합니다.

아래는 이벤트 핸들러 코드입니다. 처리하기 전에". 매개변수 "를 초기화합니다. 데이터 샘플링" 다음에 디렉토리에서 데이터를 채우십시오 " 상대방". 여기에서 "열을 채우는 데주의를 기울일 가치가 있습니다. 클라이언트 유형". "UT"에는 "Boolean" 유형의 기능이 있고 수신자에는 열거형 기능이 있습니다.

이 단계에서는 원하는 유형(UT에 없음)으로 가져올 수 없으므로 지금은 문자열 형식으로 남겨 둡니다. 이렇게 할 필요는 없지만 소스에서 누락된 유형으로 캐스팅하는 방법을 즉시 보여주고 싶습니다.

데이터 가져오기 = NewValueTable(); 데이터 Selection.Columns.Add("클라이언트"); 데이터 Selection.Columns.Add("클라이언트 유형"); 디렉토리에서 데이터 선택 = Directories.Contractors.Select(); DataFromCatalog.Next()를 가져오는 동안 루프 If FetchingDataFromCatalog.ThisGroup then Continue; EndIf; If DataFetchFromCatalog.Buyer Then NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "구매자"; EndIf; DataFetchFromCatalog.Provider인 경우 NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "공급자"; EndIf; 종료 주기;

데이터 업로드 규칙을 저장하고 " 개체 변환 규칙". 정보 레지스터에 추가하자 " 클라이언트 유형" 속성 변환 규칙: 클라이언트 및 클라이언트 유형. 소스를 비워두고 "Before unloading" 이벤트 핸들러에서 다음과 같이 작성합니다.

// "클라이언트" 속성의 경우 Value = Source.Client; // "CustomerType" 속성의 경우 If Source.Customer = "Buyer" Then 식 = "Enumerations.CustomerTypes.Buyer" ElseIf Source.Customer = "Supplier" Then 식 = "Enumerations.CustomerTypes.Supplier"; EndIf;

목록에서 세부 정보는 선택한 데이터를 기반으로 채워집니다. 클라이언트를 단순히 링크로 전달하고 매개변수에 클라이언트 유형을 씁니다. 표현". 이 매개변수의 데이터는 수신자에서 해석되고 실행될 때 속성은 열거에서 올바른 값으로 채워집니다.

그게 다야, 교환 규칙이 준비되었습니다.고려 된 예는 매우 보편적 인 것으로 판명되었습니다. 7.7 플랫폼에서 생성된 구성에서 데이터를 전송할 때 유사한 접근 방식이 자주 사용됩니다. 이것의 눈에 띄는 예는 주기적 세부 사항의 전송입니다.

작업 번호 3. 표 형식 트릭

종종 하나의 테이블 형식 부분의 행을 여러 개에 게시해야 하는 작업이 있습니다. 예를 들어, 초기 구성에서 서비스와 상품은 하나의 테이블 섹션에 등록되고 이러한 항목의 저장은 수신기에서 분리됩니다. 다시 말하지만, 문제는 시각적 수단으로 해결할 수 없습니다. 여기서 두 번째 문제의 해결책을 기초로 삼는 것이 편리합니다.

데이터 업로드 규칙을 만들고, 임의의 알고리즘을 지정하고, "업로드 전" 핸들러에 쿼리를 작성하여 테이블 섹션에서 데이터를 가져옵니다.

공간을 절약하기 위해 요청의 코드(항상 소스 코드를 참조할 수 있음)를 제공하지 않겠습니다. 특이한 점은 없습니다. 결과 샘플을 정렬하고 정렬된 결과를 이미 친숙한 매개변수 " 데이터 샘플링". 다시 말하지만 값 테이블을 컬렉션으로 사용하는 것이 편리합니다.

데이터 가져오기 = NewValueTable(); //여기에 테이블 형식 섹션이 하나 더 있습니다. Data Selection.Columns.Add("Products"); //여기에는 표 형식의 섹션도 있습니다. Data Selection.Columns.Add("Services"); .Columns.Add("링크")에서 데이터 선택;

작업 번호 4. 작업으로 데이터 전송

조직에서 여러 회계 시스템을 사용하는 경우 조만간 후속 전기 형성과 함께 데이터 마이그레이션이 필요할 것입니다.

구성에서 " BP"보편적인 문서가 있다" 작업"이며 더 많은 와이어를 형성하는 데 이상적입니다. 여기에 한 가지 문제가 있습니다. 문서가 교묘하게 만들어지고 데이터를 문서로 전송하는 것이 그리 쉽지 않습니다.

이러한 변환의 예는 기사의 소스 코드에서 찾을 수 있습니다. 코드의 양이 상당히 많아 기사에 게시할 의미가 없습니다. 다시 업로드가 데이터 업로드 규칙에서 임의의 알고리즘을 사용한다고 말하겠습니다.

작업 번호 5. 여러 속성에서 데이터 동기화

우리는 이미 몇 가지 예를 다루었지만 지금까지는 마이그레이션 중 개체 동기화에 대해 이야기하지 않았습니다. 상대방을 이전해야 하고 그 중 일부가 수신자 데이터베이스에 있다고 가정해 보겠습니다. 데이터를 전송하고 중복을 방지하는 방법은 무엇입니까? 이와 관련하여 CD는 전송된 개체를 동기화하는 여러 방법을 제공합니다.

첫 번째는 고유 식별자에 의한 것입니다. 많은 개체에는 테이블 내에서 고유성을 보장하는 고유 식별자가 있습니다. 예를 들어, 핸드북 " 상대방"는 동일한 ID를 가진 두 개의 요소를 가질 수 없습니다. CD는 이에 대한 계산을 수행하고 생성된 모든 PSP에 대해 식별자로 검색이 기본적으로 즉시 활성화됩니다. PSP를 만드는 동안 개체 이름 옆에 돋보기 아이콘이 표시되어야 합니다.

고유 식별자로 동기화하는 것은 신뢰할 수 있는 방법이지만 항상 적절한 것은 아닙니다. 디렉토리를 병합할 때 " 상대방"(여러 다른 시스템에서) 그는 거의 도움이 되지 않습니다.

이러한 경우 여러 기준에 따라 개체를 동기화하는 것이 더 정확합니다. TIN, KPP, 이름으로 상대방을 검색하거나 검색을 여러 단계로 분할하는 것이 더 정확합니다.

데이터 변환은 검색 기준을 정의하는 개발자를 제한하지 않습니다. 추상적인 예를 생각해보자. 디렉토리를 동기화해야 한다고 가정합니다. " 상대방" 다양한 정보 기반에서. PCP를 준비하고 개체 변환 규칙 설정에서 " ID로 수신자 객체를 찾을 수 없는 경우 검색 필드를 계속 검색합니다.". 이 작업을 통해 고유 식별자와 임의 필드로 두 가지 검색 기준을 즉시 정의했습니다.

우리는 필드를 스스로 선택할 권리가 있습니다. TIN, KPP, 이름을 확인한 후 여러 검색 기준을 즉시 표시합니다. 편안한? 꽤, 하지만 다시 이것은 충분하지 않습니다. 검색 기준을 변경하려면 어떻게 해야 합니까? 예를 들어, 먼저 TIN + KPP의 무리를 검색하고 아무것도 찾지 못하면 이름으로 운을 시험하기 시작합니다.

그러한 알고리즘을 구현하는 것은 충분히 가능합니다. 이벤트 핸들러에서 검색 필드" 최대 10개의 검색 기준을 지정할 수 있으며 각각에 대해 검색 필드의 자체 구성을 정의합니다.

SearchOptionNumber = 1이면 SearchPropertyNameString = "TIN, KPP"; ElseIfSearchVariantNumber = 2 ThenSearchPropertyNameString = "이름"; EndIf;

항상 여러 솔루션이 있습니다.

모든 작업에는 여러 솔루션이 있으며 서로 다른 구성 간에 데이터를 전송하는 것도 예외는 아닙니다. 각 개발자는 자신의 솔루션 경로를 선택할 권리가 있지만 복잡한 데이터 마이그레이션을 지속적으로 개발해야 하는 경우 "" 구성에 주의하는 것이 좋습니다. 처음에는 교육에 자원(시간)을 투자해야 하지만, 처음의 다소 심각한 프로젝트에서 그 이상의 성과를 거둘 것입니다.

제 생각에는 1C 회사는 데이터 변환 사용 주제를 부당하게 우회합니다. 기술이 존재하는 전체 기간 동안 "1C: Enterprise 8. 데이터 변환: 응용 프로그램 솔루션 간의 교환"이라는 책만 출판되었습니다. 이 책은 꽤 오래되었지만(2008), 여전히 익숙해지는 것이 바람직합니다.

플랫폼 지식은 여전히 ​​필요합니다.

»는 범용 도구이지만 1C:Enterprise 7.7 플랫폼용으로 개발된 구성에서 데이터 마이그레이션을 생성하는 데 사용할 계획이라면 기본 제공 언어를 이해하는 데 시간을 보내야 합니다. 언어의 구문과 이념이 매우 다르기 때문에 학습에 시간을 할애해야 합니다. 나머지 원칙은 동일하게 유지됩니다.

이벤트 핸들러 메커니즘은 "Data Conversion 2.0"을 사용하여 데이터를 변환하는 핵심 기술 중 하나입니다. 이 메커니즘을 유능하고 능숙하게 사용하면 개발자는 거의 모든 데이터 변환 작업을 신속하게 해결할 수 있습니다. 프로세서 기술의 도움으로 데이터 선택, 데이터 변환이 쉽게 구현됩니다. 다른 유형, 복잡한 데이터 선택, 변환 설정 및 기타 여러 작업.

이 기술의 기본 원리를 고려하십시오. 범용 교환 처리에서 데이터 언로드 및 로드 알고리즘의 핵심 지점에서 데이터 언로드 또는 로드 처리에서 "하드와이어"되지 않고 데이터 교환 규칙에서 가져온 프로그램 코드를 실행할 수 있습니다. "데이터 변환 2.0" 구성은 이러한 프로그램 코드를 데이터 교환 규칙에 통합할 수 있는 기회를 제공합니다.

전체적으로 데이터 교환 알고리즘에는 타사 코드가 실행될 수 있는 20개 이상의 서로 다른 위치가 있습니다. 따라서 구성은 다양한 유형의 이벤트 핸들러 생성을 제공합니다.

이벤트 핸들러의 코드는 디렉토리 요소인 교환 규칙의 개체에 "첨부"됩니다: 변환, 개체 변환 규칙, 속성 변환 규칙, 데이터 업로드 규칙 및 데이터 정리 규칙. 당연히 이벤트 핸들러 코드는 여러 요구 사항을 충족해야 합니다. 특히 핸들러 코드에서 변환 과정을 제어하기 위해서는 특수 변수인 매개변수를 사용해야 합니다. 모든 유형의 이벤트 핸들러 및 사용 가능한 변수에 대한 전체 설명은 해당 양식의 핸들러 정보에서 찾을 수 있습니다.

주목!!!

데이터 변환 2.0 기술을 통해 1C:Enterprise 7.7 및 1C:Enterprise 8.0 플랫폼에서 구현된 정보베이스와 데이터 교환이 가능합니다. 1C:Enterprise 7.7 플랫폼 운영의 특성으로 인해 이 플랫폼에서 구현된 정보베이스용 이벤트 핸들러를 사용하여 데이터 교환 규칙을 준비하는 데는 여러 가지 기능이 있습니다.

1C:Enterprise 7.7 플랫폼의 경우 임의 코드를 실행할 수 없습니다(V8의 Run 기능과 유사). V7.7 플랫폼용 이벤트 핸들러를 사용해야 하는 경우 데이터 업로드 또는 다운로드 처리 텍스트를 "데이터 변환 2.0" 구성이 생성하는 처리 텍스트로 교체해야 합니다.

V7.7에서 V8로 데이터를 전송해야 하는 경우:

언로드할 때 규칙 파일 자체 외에도 시스템은 이벤트 핸들러를 구현하는 함수로 V77Exp.ert를 처리하기 위한 모듈의 텍스트를 생성합니다. 그런 다음 구성기에서 표준 V77Exp.ert 모듈을 "Data Conversion 2.0"에서 생성된 새 모듈로 교체해야 합니다.

1C:Enterprise 7.7 플랫폼에서 데이터 교환 솔루션을 개발할 때 이 중요한 "사소한 일"을 기억해야 합니다. 데이터 교환 규칙을 언로드할 때 모듈 텍스트가 생성된 수정된 처리를 사용하는 경우에만 규칙이 올바르게 작동합니다. 이 규칙에는 한 가지 예외가 있습니다. 이벤트 처리기를 사용하지 않으면 표준 처리를 사용할 수 있습니다.

진정으로, 블라디미르 밀킨(교사 및 개발자).