SAP HCM에서 SAP가 아닌 데이터 웨어하우스로 데이터 추출

아시다시피 SAP는 거래 데이터를 유지 관리하고 분석 및 보고 시스템에서 이 데이터를 처리하기 위한 광범위한 소프트웨어를 제공합니다. 특히, SAP Business Warehouse(SAP BW) 플랫폼은 광범위한 기술적 역량을 갖춘 데이터를 저장하고 분석하기 위한 툴킷입니다. 모든 객관적인 이점에도 불구하고 SAP BW 시스템에는 한 가지 중요한 단점이 있습니다. 이는 데이터를 저장하고 처리하는 데 드는 비용이 높으며, 특히 Hana에서 클라우드 기반 SAP BW를 사용할 때 두드러집니다.

SAP가 아닌 제품, 바람직하게는 OpenSource 제품을 스토리지로 사용하기 시작하면 어떻게 될까요? X5 Retail Group에서는 GreenPlum을 선택했습니다. 물론 이는 비용 문제를 해결하지만 동시에 SAP BW를 사용할 때 거의 기본적으로 해결되었던 문제가 즉시 발생합니다.

특히, 대부분 SAP 솔루션인 소스 시스템에서 데이터를 검색하는 방법은 무엇입니까?

HR Metrics는 이 문제를 해결하기 위해 필요한 첫 번째 프로젝트였습니다. 우리의 목표는 HR 데이터 저장소를 만들고 직원과의 작업 영역에서 분석 보고를 구축하는 것이었습니다. 이 경우 데이터의 주요 소스는 모든 직원, 조직 및 급여 활동이 수행되는 SAP HCM 트랜잭션 시스템입니다.

데이터 추출

SAP BW에는 SAP 시스템용 표준 데이터 추출기가 있습니다. 이러한 추출기는 필요한 데이터를 자동으로 수집하고, 무결성을 모니터링하고, 변경 델타를 결정할 수 있습니다. 예를 들어 다음은 직원 속성 0EMPLOYEE_ATTR에 대한 표준 데이터 소스입니다.

한 직원의 데이터를 추출한 결과는 다음과 같습니다.

필요한 경우 이러한 추출기를 사용자 요구 사항에 맞게 수정하거나 사용자 고유의 추출기를 생성할 수 있습니다.

가장 먼저 떠오른 아이디어는 재사용 가능성이었습니다. 불행하게도 이는 불가능한 일로 판명됐다. 대부분의 논리는 SAP BW 측에서 구현되며 소스의 추출기를 SAP BW에서 쉽게 분리하는 것은 불가능했습니다.

SAP 시스템에서 데이터를 추출하기 위한 자체 메커니즘을 개발해야 한다는 것이 분명해졌습니다.

SAP HCM의 데이터 저장 구조

이러한 메커니즘의 요구 사항을 이해하려면 먼저 어떤 데이터가 필요한지 결정해야 합니다.

SAP HCM의 대부분의 데이터는 플랫 SQL 테이블에 저장됩니다. 이 데이터를 기반으로 SAP 애플리케이션은 조직 구조, 직원 및 기타 HR 정보를 사용자에게 시각화합니다. 예를 들어 SAP HCM의 조직 구조는 다음과 같습니다.

물리적으로 이러한 트리는 두 개의 테이블, 즉 hrp1000 개체와 hrp1001에 이러한 개체 간의 연결에 저장됩니다.

"부서 1" 및 "사무실 1" 개체:

개체 간의 관계:

개체 유형과 개체 간의 연결 유형이 엄청나게 많을 수 있습니다. 개체 사이에는 표준 연결과 특정 요구 사항에 맞게 사용자 정의된 연결이 모두 있습니다. 예를 들어, 조직 단위와 정규직 간의 표준 B012 관계는 부서장을 나타냅니다.

SAP의 관리자 표시:

데이터베이스 테이블의 저장:

직원 데이터는 pa* 테이블에 저장됩니다. 예를 들어, 직원의 인사 이벤트 데이터는 pa0000 테이블에 저장됩니다.

우리는 GreenPlum이 "원시" 데이터를 사용하기로 결정했습니다. SAP 테이블에서 복사하면 됩니다. 그리고 GreenPlum에서 직접 처리되어 실제 개체(예: 부서 또는 직원)와 지표(예: 평균 인원 수)로 변환됩니다.

약 70개의 테이블이 정의되었으며, 이 테이블의 데이터를 GreenPlum으로 전송해야 합니다. 그 후 우리는 이 데이터를 전송하는 방법을 연구하기 시작했습니다.

SAP는 상당히 많은 통합 메커니즘을 제공합니다. 하지만 가장 쉬운 방법은 라이선스 제한으로 인해 데이터베이스에 대한 직접 접근이 금지되는 것입니다. 따라서 모든 통합 흐름은 애플리케이션 서버 수준에서 구현되어야 합니다.
다음 문제는 SAP 데이터베이스에 삭제된 기록에 대한 데이터가 부족하다는 점이었습니다. 데이터베이스에서 행을 삭제하면 물리적으로 삭제됩니다. 저것들. 변경 시점을 기준으로 변경 델타를 형성하는 것은 불가능했습니다.

물론 SAP HCM에는 데이터 변경 사항을 기록하는 메커니즘이 있습니다. 예를 들어, 수신자 시스템으로의 후속 전송을 위해 모든 변경 사항을 기록하고 이를 기반으로 Idoc(외부 시스템으로 전송하기 위한 개체)가 형성되는 변경 포인터가 있습니다.

직원 번호가 0302인 직원의 정보 유형 1251445를 변경하는 IDoc 예:

또는 DBTABLOG 테이블에 데이터 변경 로그를 보관합니다.

hrp53216375 테이블에서 QK1000 키를 가진 레코드를 삭제하기 위한 로그의 예:

그러나 이러한 메커니즘은 필요한 모든 데이터에 사용할 수 없으며 애플리케이션 서버 수준에서 처리하는 데 상당한 리소스가 소모될 수 있습니다. 따라서 필요한 모든 테이블에 대해 대규모로 로깅을 활성화하면 시스템 성능이 눈에 띄게 저하될 수 있습니다.

다음 주요 문제는 클러스터링된 테이블이었습니다. SAP HCM RDBMS 버전의 시간 추정 및 급여 데이터는 각 계산에 대해 각 직원에 대한 논리 테이블 세트로 저장됩니다. 이러한 논리 테이블은 테이블 pcl2에 이진 데이터로 저장됩니다.

급여 클러스터:

클러스터링된 테이블의 데이터는 SQL 명령으로 간주될 수 없지만 SAP HCM 매크로 또는 특수 기능 모듈을 사용해야 합니다. 따라서 이러한 테이블의 읽기 속도는 매우 느립니다. 반면에 이러한 클러스터는 한 달에 한 번만 필요한 최종 급여 및 시간 추정 데이터를 저장합니다. 따라서 이 경우 속도는 그다지 중요하지 않습니다.

데이터 변경 사항의 델타를 형성하기 위한 옵션을 평가하면서 우리는 전체 언로드 옵션도 고려하기로 결정했습니다. 매일 시스템 간에 변경되지 않은 기가바이트의 데이터를 전송하는 옵션은 좋지 않을 수 있습니다. 그러나 여기에는 여러 가지 장점도 있습니다. 즉, 소스 측에서 델타를 구현하고 수신 측에서 이 델타의 임베딩을 구현할 필요가 없습니다. 이에 따라 비용과 구현 시간이 줄어들고 통합의 신뢰성이 높아집니다. 동시에 SAP HR의 거의 모든 변경 사항은 현재 날짜로부터 XNUMX개월 이내에 발생하는 것으로 확인되었습니다. 따라서 현재 날짜로부터 N개월 전에 SAP HR에서 데이터를 매일 전체 다운로드하고 매월 전체 다운로드를 선택하기로 결정했습니다. N 매개변수는 특정 테이블에 따라 다릅니다.
범위는 1부터 15까지입니다.

데이터 추출을 위해 다음과 같은 방식이 제안되었습니다.

외부 시스템은 요청을 생성하여 SAP HCM으로 보냅니다. 여기서 이 요청은 데이터의 완전성과 테이블 액세스 권한을 확인합니다. 검사에 성공하면 SAP HCM은 필요한 데이터를 수집하여 Fuse 통합 솔루션으로 전송하는 프로그램을 실행합니다. Fuse는 Kafka에서 필요한 주제를 결정하고 거기로 데이터를 전송합니다. 다음으로 Kafka의 데이터가 Stage Area GP로 전송됩니다.

이 체인에서 우리는 SAP HCM에서 데이터를 추출하는 문제에 관심이 있습니다. 좀 더 자세히 살펴보겠습니다.

SAP HCM-FUSE 상호 작용 다이어그램.

외부 시스템은 SAP에 대한 마지막 요청 성공 시간을 결정합니다.
프로세스는 SAP의 데이터 응답을 기다리고 반복 요청을 시작하기 위한 시간 초과 설정을 포함하여 타이머 또는 기타 이벤트에 의해 시작될 수 있습니다. 그런 다음 델타 요청을 생성하여 SAP로 보냅니다.

요청 데이터는 json 형식으로 본문에 전송됩니다.
메소드 http: POST.
요청 예시:

SAP 서비스는 요청의 완전성, 현재 SAP 구조 준수 및 요청된 테이블에 대한 액세스 권한 가용성을 모니터링합니다.

오류가 발생하면 서비스는 적절한 코드와 설명이 포함된 응답을 반환합니다. 제어가 성공하면 샘플을 생성하기 위한 백그라운드 프로세스를 생성하고 고유한 세션 ID를 생성하고 동기적으로 반환합니다.

오류가 발생하면 외부 시스템에서 이를 로그에 기록합니다. 응답이 성공하면 세션 ID와 요청한 테이블 이름을 전송합니다.

외부 시스템은 현재 세션을 열린 것으로 등록합니다. 이 테이블에 다른 세션이 있으면 경고가 기록되면서 닫힙니다.

SAP 백그라운드 작업은 지정된 매개변수와 지정된 크기의 데이터 패킷을 기반으로 커서를 생성합니다. 배치 크기는 프로세스가 데이터베이스에서 읽는 최대 레코드 수입니다. 기본적으로는 2000으로 가정합니다. 데이터베이스 샘플에 사용된 패킷 크기보다 많은 레코드가 있는 경우 첫 번째 패킷을 전송한 후 해당 오프셋과 증가된 패킷 번호로 다음 블록을 구성합니다. 숫자는 1씩 증가하며 엄격하게 순차적으로 전송됩니다.

다음으로 SAP는 패킷을 외부 시스템의 웹 서비스에 대한 입력으로 전달합니다. 그리고 시스템은 들어오는 패킷에 대한 제어를 수행합니다. 전달받은 ID를 가진 세션이 시스템에 등록되어 있어야 하며 Open 상태여야 합니다. 패키지 번호가 1보다 큰 경우 시스템은 이전 패키지(package_id-1)의 성공적인 수신을 기록해야 합니다.

제어가 성공하면 외부 시스템이 테이블 데이터를 구문 분석하고 저장합니다.

또한 패키지에 최종 플래그가 있고 직렬화가 성공한 경우 통합 모듈은 세션 처리가 성공적으로 완료되었음을 알리고 모듈은 세션 상태를 업데이트합니다.

제어/구문 분석 오류가 발생한 경우 오류가 기록되고 이 세션에 대한 패킷은 외부 시스템에 의해 거부됩니다.

마찬가지로 반대의 경우에도 외부 시스템에서 오류를 반환하면 이를 기록하고 패킷 전송을 중단한다.

SAP HСM 측에서 데이터를 요청하기 위해 통합 서비스가 구현되었습니다. 서비스는 ICF 프레임워크(SAP Internet Communication Framework - help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html). 특정 테이블을 사용하여 SAP HCM 시스템에서 데이터를 쿼리할 수 있습니다. 데이터 요청을 생성할 때 필요한 데이터를 얻기 위해 특정 필드 목록과 필터링 매개변수를 지정할 수 있습니다. 동시에 서비스 구현은 비즈니스 로직을 암시하지 않습니다. 델타 계산, 쿼리 매개변수, 무결성 모니터링 등을 위한 알고리즘도 외부 시스템 측에서 구현됩니다.

이 메커니즘을 사용하면 몇 시간 안에 필요한 모든 데이터를 수집하고 전송할 수 있습니다. 이 속도는 허용 가능한 수준에 있으므로 이 솔루션을 프로젝트에서 추출 도구에 대한 필요성을 충족할 수 있는 임시 솔루션으로 간주합니다.
대상 그림에서는 데이터 추출 문제를 해결하기 위해 Oracle Golden Gate와 같은 CDC 시스템이나 SAP DS와 같은 ETL 도구를 사용하는 옵션이 탐색되고 있습니다.

출처 : habr.com