SAP ECC 및 Oracle E-Business Suite와 같은 레거시 ERP 시스템은 여전히 Fortune 500 회사의 중요한 비즈니스 운영을 지원하고 있지만, 이러한 단일 아키텍처는 현대 API 우선 설계 패턴보다 수십 년 앞서 있습니다. 이 질문은 기업들이 컨테이너화 및 마이크로서비스 분해에 저항하는 브라운필드 환경에 DevOps 변환 전략을 적용하려 시도하면서 자연스럽게 등장했습니다. 전통적인 자동화 접근 방식은 이러한 시스템이 비밀스러운 ABAP 또는 PL/SQL 코드베이스에서 프레젠테이션 로직과 비즈니스 규칙을 밀접하게 결합하기 때문에 실패합니다. 기관들은 두꺼운 클라이언트 SAPGUI 인터페이스에 Selenium 기반 웹 자동화를 단순히 적용하는 것이 재앙적인 유지 관리 오버헤드와 잘못된 긍정을 초래한다는 것을 발견했습니다.
근본적인 장애는 ERP 시스템이 세션 관리가 강력한 상태 유지 GUI 프레임워크에 의존하고 노출된 REST 인터페이스가 없기 때문에 발생합니다. 데이터베이스 직접 검증은 수천 줄의 레거시 트리거 코드에 내장된 애플리케이션 계층 비즈니스 규칙을 위반하는 위험이 있어 테스트 결과에서 잘못된 부정(위조를 의미)으로 연결됩니다. 공유 샌드박스 환경은 ABAP 트랜잭션이 자율 커밋을 자주 활용하여 표준 트랜잭션 롤백 메커니즘을 우회하게 되어 테스트 격리를 방해합니다. 또한, 실시간 검증은 UI 확인에 비해 비동기 RFC (원격 함수 호출) 처리 대기열이나 야간 배치 작업 일정으로 인해 상태 변경을 감지해야 합니다.
하이브리드 자동화 아키텍처를 구현하여 RPA 스타일 화면 자동화와 변경 데이터 캡처 (CDC) 메커니즘을 통한 이벤트 기반 데이터베이스 검증을 결합합니다. Delphix나 Redgate SQL Clone과 같은 데이터 가상화 도구를 배치하여 전체 테라바이트 규모의 환경을 복제하지 않고 각 병렬 테스트 스레드에 대해 독립적이고 쓸 수 있는 데이터베이스 하위 집합을 프로비저닝합니다. Selenium 주변의 SAP CBTA 또는 SapShell 래퍼와 같은 독점적인 자동화 어댑터를 사용하여 부서지기 쉬운 XPath 로케이터 없이 동적 Dynpro 컨트롤 식별자를 처리합니다. Apache Kafka를 사용하여 SAP 변동 포인터 또는 데이터베이스 트랜잭션 로그를 소비하는 이벤트 버스를 설정하여 폴링 지연을 제거하면서 UI 및 데이터베이스 상태 일관성을 모두 검증하는 비동기 주장을 가능하게 합니다.
글로벌 제조 대기업은 구매 요청, 공급업체 승인, 상품 수령, 송장 검증을 포함하여 SAP ECC 6.0 모듈에 걸친 Procure-to-Pay 워크플로우의 자동화를 요구했습니다. 목표 환경은 수동 테스터, 배치 작업 일정 및 다양한 지리적 팀 간의 12개 병렬 자동화 스트림이 동시에 사용하고 있는 공유 SANDBOX 인스턴스였습니다. 워크플로우는 구매 주문 작성이 RFC 호출을 통해 별도의 SAP BW 시스템에 대한 신용 한도 검사를 트리거한 후 비동기 재고 업데이트를 포함하는 복잡한 상태 전환을 포함했습니다.
자동화가 450001 ID를 가진 구매 주문을 작성했지만, 주장이 실행되기도 전에 경쟁 테스트가 동일한 공급업체 마스터 데이터를 수정하거나 비용 센터에서 사용 가능한 예산을 소진했기 때문에 데이터베이스 경합으로 인해 테스트의 극한 안정성이 떨어졌습니다. SAPGUI 화면은 런타임 ABAP 화면 시퀀스를 기반으로 동적으로 생성된 제어 ID를 사용하여, 개발의 작은 구성 변경이 발생할 때마다 стандартные Selenium 로케이터가 깨졌습니다. 부가적으로, 중요한 비즈니스 검증은 야간 ABAP 배치 작업이 처리된 후에만 완료되어 단순 UI 기반 접근 방식으로는 당일 테스트 피드백을 불가능하게 만들었습니다.
연장 대기로 순수 UI 자동화가 처음 고려한 솔루션이었습니다. 이 전략은 SAP CBTA에 명시적 동기화 포인트와 공격적인 폴링 루프를 사용하여 UI 상태 변경을 감지하는 데 전적으로 의존했습니다. 장점으로는 최소한의 인프라 발자국과 SAP의 공식 지원 자동화 도구 세트와의 정렬로 추가 라이센스가 필요하지 않았습니다. 단점은 고정된 폴링 간격으로 인해 테스트 케이스당 실행 시간이 50분 이상 늘어나고, 백엔드 IDoc (중간 문서) 처리가 성공적으로 이루어졌는지 검증할 수 없으며, 배치 작업이 시간이 예측할 수 없이 지연될 때 지속적인 잘못된 긍정을 초래했습니다.
직접 데이터베이스 조작이 두 번째 대안으로 고려되었습니다. 이 접근 방식은 UI를 전적으로 우회하여 주장용으로 JDBC 연결을 사용해 EKKO (구매 문서 헤더) 및 EKPO (구매 문서 항목) 테이블을 확인했습니다. 장점으로는 서브 초 속도 검증과 프론트엔드 렌더링 변경에 대한 이론적 면역이 포함되어 SAPGUI 클라이언트 설치 없이도 테스트를 실행할 수 있었습니다. 단점은 ABAP 검증 로직이 변경되었을 때 SQL 쿼리가 업데이트되지 않아 유지 관리의 악몽을 초래하고, 사용자에게 보이는 비즈니스 프로세스를 테스트하기보다는 구현 세부 사항을 검증할 위험이 발생하며, 직접 업데이트가 애플리케이션 수준의 권한 확인을 우회하면서 데이터 무결성 제약을 위반할 수 있다는 것입니다.
가상 테스트 데이터를 사용하는 하이브리드 아키텍처가 세 번째 구현된 대안이었습니다. 이 솔루션은 **SAP TDMS (테스트 데이터 마이그레이션 서버)**를 활용하여 공유 샌드박스 내에 독립적이고 클라이언트 특정 데이터 구간을 설계하고 각 자동화 스레드에 고유한 회사 코드를 할당했습니다. UI 상호작용을 위해 Selenium과 SapShell 자동화 래퍼를 사용하고, CDC를 통해 실시간 상태 변경 알림을 위한 CDPOS (변경 문서 항목) 테이블을 모니터링하는 Kafka 리스너를 결합했습니다. 장점으로는 교차 오염이 없는 진정한 병렬 실행, 폴링보다 80% 더 빠른 검증 속도를 가진 이벤트 기반 주장, 그리고 TestPlant 또는 Micro Focus UFT의 AI 엔진과 같은 AI 기반 객체 인식 도구에 의해 방지되는 UI 로케이터 변경에 대한 복원력 등이 있습니다. 단점은 TDMS 구성과 데이터 노화 및 새로 고침 주기를 관리하기 위한 복잡한 테스트 데이터 조정 논리를 위한 상당한 초기 인프라 투자입니다.
하이브리드 아키텍처는 단순히 시간을 조정하여 증상만 가리기보다는 근본 원인인 테스트 데이터 격리를 해결했기 때문에 선택되었습니다. 초기 설정에 Basis 관리자와의 협력이 반드시 3주 필요한 설정이었지만, 이는 레거시 시스템에 대한 진정한 CI/CD 통합을 가능하게 하고 피드백 루프를 3일에서 2시간 이내로 줄였습니다. 이러한 접근 방식은 순수 UI 자동화가 제공할 수 없는 결정론적 실행 보장을 제공하면서 직접 데이터베이스 쿼리가 희생한 사용자 중심 검증 관점을 유지했습니다.
현재 이 프레임워크는 250개 이상의 병렬 테스트 실행을 지원하며 8개 지역 팀에서 일일 0건의 교차 오염 사건을 기록하였습니다. 테스트의 불안정성은 42%에서 1.8%로 감소했으며, 주문에서 현금의 중요한 경로 실행 시간은 6시간에서 28분으로 단축되었습니다. 이 아키텍처는 다른 레거시 모듈 자동화에 대한 기업 표준으로 자리 잡아 메인프레임 시대의 시스템이 위험한 교체 현대화 전략 없이 현대적인 자동화 속도를 이룰 수 있음을 입증했습니다.
자동화 파이프라인을 위해 고유한 조직 구조-예를 들어 회사 코드, 공장 ID 또는 구매 조직-를 예약하여 논리적 테넌트 격리를 구현하는 방법은 무엇입니까?
후보자들은 종종 데이터베이스 트랜잭션으로 테스트를 래핑하는 것을 제안하지만 ABAP의 COMMIT WORK 명령은 JDBC 트랜잭션 경계를 무시하는 자율 커밋을 실행합니다. 올바른 접근 방식은 논리적 테넌트 격리를 구현하여 특정 조직 구조-예를 들어 회사 코드, 공장 ID 또는 구매 조직-를 자동화 파이프라인 전용으로 예약하는 것입니다. 이를 Temporal Isolation 전략과 결합하여 자동화가 6개월 미래의 날짜로 사업 문서를 생성하도록 하여 수동 테스터와 현재 날짜의 트랜잭션을 처리하는 배치 작업에 보이지 않도록 합니다. 정리를 위해 직접 SQL 삭제 대신 애플리케이션 계층의 참조 무결성 및 권한 확인을 존중하기 위해 BAPI_PO_DELETE와 같은 BAPI (Business Application Programming Interface) 호출을 사용합니다.
부하가 분산된 환경에서 SAP 메시지 서버가 연결을 동적으로 다른 애플리케이션 서버로 리디렉션 할 때 SAPGUI 자동화가 실패하지 않도록 방지하는 기술은 무엇입니까?
많은 후보자들이 로드 밸런서 수준에서 스티키 세션을 구성할 것을 제안하지만, 이는 QA 팀에 드물게 부여되는 네트워크 관리 권한을 요구합니다. 올바른 솔루션은 로그인 후 즉시 SAPGUI 연결 문자열에서 특정 애플리케이션 서버 인스턴스 번호를 캡처한 다음 모든 후속 자동화 단계를 해당 특정 노드로 명시적으로 라우팅하는 것입니다 - SAP 라우터 문자열 사용. 테스트 컨텍스트 내에 스레드 ID를 특정 서버 인스턴스에 매핑하는 세션 친화성 레지스트리를 구현하고 SAP의 TH_SERVER_LIST 기능 모듈을 사용해 사용할 수 있는 노드를 사전에 식별하십시오. 이는 상태 유지 ABAP 세션 변수가 여러 화면 전환을 통해 지속적으로 유지될 수 있도록 하여 인프라 변경이나 로드 밸런싱을 중지할 필요 없이 동작합니다.
부드러운 스크린 스크래핑 없이 비동기 SAP 배치 작업 완료와 자동화를 동기화하는 방법은 무엇입니까?
대부분의 후보자들은 작업 개요 화면의 폴링이나 고정 지연 구현을 제안하며, 이 모두는 취약성과 예측할 수 없는 실행 시간을 초래합니다. 고급 솔루션은 RFC (원격 함수 호출) 목적지를 통해 SAP의 XBP (External Batch Processing) 인터페이스를 활용하여 자동화가 BP_JOB_STATUS_GET을 프로그래밍적으로 호출하게 합니다. 다음은 PyRFC를 사용한 Python 구현입니다:
from pyrfc import Connection def wait_for_batch_job(conn, job_name, timeout=300): """이벤트 기반 **SAP** 배치 작업 완료 대기""" import time start = time.time() while time.time() - start < timeout: result = conn.call('BP_JOB_STATUS_GET', JOBNAME=job_name, EXTERNAL_USER_NAME='AUTOMATION_USER') status = result['STATUS'] if status == 'F': # 완료된 경우 return True elif status == 'A': # 중단된 경우 raise Exception(f"작업 {job_name}이 중단되었습니다") time.sleep(2) # 짧은 폴링, 하지만 웹 후크로 대체할 수 있습니다. return False
이는 GUI 타이밍으로부터 검증을 분리해 주며, SAP의 이벤트 메쉬 웹후크와 결합하여 검증 오버헤드를 분으로 줄이고 구조화된 작업 로그 구문 분석 기능을 제공하여 비결정적인 실패 분석을 위한 추가 RFC 호출, 예를 들어 BP_JOBLOG_READ을 통해 제공합니다.