이전 글 “[SAP ABAP] Inbound Proxy 구현 — 외부에서 SAP로 데이터 수신, SPROXY · INTF Interface · Implementing Class” 에서 외부 → SAP 방향의 Provider Proxy 를 어떻게 만드는지를 다뤘습니다. 그 다음 단골 문제 — “그래서 이걸 어떻게 테스트하지?”. 거래처 시스템에서 직접 메시지를 보내달라고 하기엔 시간이 걸리고, PI/PO 환경이 아직 완성 전이면 실제 흐름을 태우기도 어렵습니다.
이때 가장 유용한 SAP 표준 기능이 SPROXY 의 Test Service Provider 입니다. 외부 시스템도, PI/PO 도 거치지 않고 SPROXY 화면 안에서 가짜 XML 메시지를 직접 만들어 Inbound Proxy 의 Implementing Class 메서드를 호출 할 수 있습니다. Generate Request Template 기능으로 자동 생성된 XML 골격을 받아 비즈니스 값만 채워 넣으면, 실제 외부 메시지가 도착한 것처럼 SAP 내부에서 메서드가 실행되고 CBO 테이블에 데이터가 들어가는지까지 검증 가능.
이 글에서는 SPROXY Test 의 진입 경로 → 테스트 다이얼로그 옵션 → Request Template 자동 생성 → 실제 값 입력 → 실행 결과 확인까지 5단계 흐름을 정리합니다. 디버그 옵션 활용법과 자주 빠뜨리는 함정도 함께. Z 커스텀 코드는 거의 등장하지 않고 표준 화면 조작 위주.
핵심 — SPROXY Test Service Provider 5단계
| 단계 | 작업 | 화면 / 기능 |
|---|---|---|
| 1 | SPROXY 진입 + Inbound 인터페이스 선택 | SPROXY 트리 → Service Provider |
| 2 | Test 아이콘 클릭 → 테스트 다이얼로그 진입 | Test Service Provider 팝업 |
| 3 | Input 옵션 선택 + 실행 | Generate Request Template / Debug method |
| 4 | 자동 생성된 Request Template XML 확인 + 실제 값 입력 | Display Request → Change Request 모드 전환 |
| 5 | 실행 → Implementing Class 메서드 호출 + 결과 확인 | SXMB_MONI · CBO 테이블 SELECT |
기본 그림은 단순합니다 — SPROXY 가 PI/PO 와 외부 시스템 역할을 동시에 해 준다. 개발자는 메시지 XML 만 정의하면 Inbound Proxy 의 Implementing Class 메서드가 실제 호출된 것처럼 돌고, 디버그 모드로 켜두면 메서드 안에서 step 디버깅까지 가능.
언제 사용하는가
| 상황 | 왜 SPROXY Test 가 답인지 |
|---|---|
| 개발 초기 — PI/PO 미연동 | PI/PO 채널/라우팅 설정 전에 Implementing Class 의 로직만 빨리 검증하고 싶을 때 |
| 거래처 송신 대기 중 | 거래처가 “언제 메시지 보내줄지” 일정이 늦어질 때 SAP 측 로직만 먼저 진행 |
| 실패 메시지 재현 | SXMB_MONI 의 실패 메시지 XML 를 복사해 와서 Test 화면에 붙여 동일 케이스 재현 + 디버깅 |
| 엣지 케이스 테스트 | 거래처가 실제로 보낼 가능성이 낮은 값(빈 라인 · 0건 · 대량 라인) 같은 케이스를 미리 검증 |
| 리팩토링 후 회귀 테스트 | Implementing Class 코드 수정 후 외부 시스템 없이 같은 메시지로 동일 동작 검증 |
거의 모든 Inbound Proxy 개발 시나리오에서 한 번 이상 거치는 단계. PI/PO 와 외부 시스템 의존성 없이 SAP 내부 로직만 단독으로 돌릴 수 있다 는 점이 가장 큰 가치.
1단계 — SPROXY 진입 + Inbound 인터페이스 선택
[1] T-Code SPROXY 실행
[2] 좌측 트리에서 Inbound 인터페이스(Service Provider) 탐색
└ Source > ESR > Software Component Version > Namespace
> Object Types > Service Providers > {인터페이스 이름}
[3] 인터페이스 더블클릭 → 우측 Properties 패널에 상세 표시
└ ABAP Object = INTF Interface 인지 확인 (Inbound 여부)
└ Implementing Class 행에 자동 생성된 구현 클래스 이름 표시
화면의 Service Provider Properties 패널에 다음 필드들이 표시됩니다.
| 필드 | 예시값 |
|---|---|
| Name | XX_IN_MI |
| Namespace | http://www.example.com/XX_IN_Message |
| ABAP Object | INTF Interface ← Inbound 표시 |
| ABAP Name | ZXIII_XX_IN_MI |
| Implementing Class | ZXICL_XX_IN_MI |
Outbound(CLAS Class) 가 선택돼 있으면 Test Service Provider 가 안 나타나니, 반드시 INTF Interface 인 인터페이스를 골라야 합니다.
2단계 — Test 다이얼로그 진입
화면 상단 도구 모음(또는 메뉴) 에서 Test 아이콘을 클릭합니다. 단축키나 메뉴 경로는 NetWeaver 버전마다 약간 다른데, 보통 다음 두 가지 중 하나.
[방법 A] 화면 좌측 도구 모음의 Test 아이콘 (지팡이 모양 또는 망치 모양)
[방법 B] 메뉴 → Service Provider → Test Service Provider
클릭하면 “Test Service Provider” 팝업 다이얼로그가 열립니다.
3단계 — Test Service Provider 다이얼로그 옵션
팝업은 세 블록으로 나뉩니다 — Test Object · Input · Debugging.
Test Object 블록
| 필드 | 의미 |
|---|---|
| Interface Name | 자동 — 1단계에서 고른 Provider Interface (예: ZXIII_XX_IN_MI) |
| Method Name | 자동 — 인터페이스 안의 비즈니스 메서드 (Service Interface 이름과 동일) |
| Use config-less shortcut | PI/PO 의 Sender Agreement 설정을 건너뛰는 단축 모드 (필요시 체크) |
Input 블록
요청 XML 을 어떤 모양으로 자동 생성할지 결정.
| 옵션 | 의미 / 언제 사용 |
|---|---|
| Generate Request Template ✅ | 기본 옵션. 메시지 타입의 모든 필드를 String 1 · String 2 ... 같은 placeholder 로 채운 XML 생성 |
| Generate Initial Req. Template | 모든 필드를 빈 값으로 생성 — 거래처가 “값 안 보낼 때” 동작 확인 |
| xsi:nil for all Leaf Elements | 모든 leaf 필드를 xsi:nil="true" 로 — NULL 처리 동작 검증 |
| xsi:nil for nillable Leaf Elm. | nullable 로 정의된 leaf 필드만 nil 처리 |
| Deletion Indicator | 메시지에 삭제 지시자(deletion flag) 포함 — 일부 시나리오 전용 |
| Enforce stylesheet generation | XML 스타일시트 강제 적용 — 거의 안 씀 |
기본은 Generate Request Template 선택. 그 다음 4단계에서 placeholder 값을 실제 비즈니스 값으로 바꿔 넣습니다.
Debugging 블록
| 옵션 | 의미 |
|---|---|
| Debug constructor | Implementing Class 의 CONSTRUCTOR 진입 시 디버거 자동 시작 |
| Debug method ⭐ | 비즈니스 메서드 진입 시 디버거 자동 시작 — 가장 많이 쓰는 옵션 |
| Don't catch application faults | cx_ai_application_fault 가 발생해도 trap 하지 않고 그대로 dump — 예외 원인 추적용 |
처음 테스트라면 Debug method 체크 후 실행. 비즈니스 메서드 첫 줄에서 디버거가 멈춰서 INPUT 파라미터에 어떤 데이터가 들어왔는지 확인하고 step 으로 따라갈 수 있습니다.
4단계 — Request Template XML 자동 생성 + 값 입력
실행 버튼(녹색 체크) 을 누르면 “Test Service Provider: Display Request” 화면이 열리며 다음과 같은 XML 이 자동 생성됩니다.
<?xml version="1.0"?>
<n0:XX_IN_MT xmlns:n0="http://www.example.com/XX_IN_Message">
<TRANS_HEADER>
<TRANSACTION_CODE>String 1</TRANSACTION_CODE>
<WORKS_CODE>String 2</WORKS_CODE>
<OP_KIND>String 3</OP_KIND>
<SNDR_EDIT_DATE>String 5</SNDR_EDIT_DATE>
<EAI_INTERFACE_ID>String 7</EAI_INTERFACE_ID>
<INTERFACE_DATA_SEND_SEQ>String 10</INTERFACE_DATA_SEND_SEQ>
</TRANS_HEADER>
<TRANS_BODY_IN_TAB>
<EBELN>String 12</EBELN>
<EBELP>String 13</EBELP>
<MATNR>String 14</MATNR>
<MENGE>String 15</MENGE>
<BUDAT>String 16</BUDAT>
<BLDAT>String 17</BLDAT>
<USNAM>String 18</USNAM>
<CNL_YN>String 19</CNL_YN>
</TRANS_BODY_IN_TAB>
<TRANS_BODY_IN_TAB>
<EBELN>String 20</EBELN>
<EBELP>String 21</EBELP>
...
</TRANS_BODY_IN_TAB>
</n0:XX_IN_MT>
PI/PO 에서 정의한 Message Type 의 구조가 그대로 XML 로 펼쳐지고, 각 leaf 필드에는 String 1 ~ String N 으로 일련번호 placeholder 가 채워져 있습니다. 라인 영역(TRANS_BODY_IN_TAB) 같은 0..N 반복 구조는 보통 라인 2~3건이 기본 샘플로 생성됨.
Display → Change 모드 전환 + 값 입력
화면 도구 모음의 연필 아이콘(Change 모드) 을 클릭하면 XML 편집이 가능해집니다. placeholder 자리에 실제 비즈니스 값을 채워 넣습니다.
<?xml version="1.0"?>
<n0:XX_IN_MT xmlns:n0="http://www.example.com/XX_IN_Message">
<TRANS_HEADER>
<TRANSACTION_CODE>CODE001</TRANSACTION_CODE>
<WORKS_CODE>0001</WORKS_CODE>
<OP_KIND>I</OP_KIND>
<SNDR_EDIT_DATE>20230306095959</SNDR_EDIT_DATE>
<EAI_INTERFACE_ID>IF_TEST_01</EAI_INTERFACE_ID>
<INTERFACE_DATA_SEND_SEQ>0001</INTERFACE_DATA_SEND_SEQ>
</TRANS_HEADER>
<TRANS_BODY_IN_TAB>
<EBELN>4500000001</EBELN>
<EBELP>00010</EBELP>
<MATNR>TEST-MAT-001</MATNR>
<MENGE>3066</MENGE>
<BUDAT>20230306</BUDAT>
<BLDAT>20230306</BLDAT>
<USNAM>TESTUSER</USNAM>
<CNL_YN></CNL_YN>
</TRANS_BODY_IN_TAB>
</n0:XX_IN_MT>
이 상태에서 실행하면 PI/PO 에서 실제로 메시지가 도착한 것과 동일하게 SAP 내부에서 처리됩니다. 라인이 2건 이상 필요하면 TRANS_BODY_IN_TAB 블록을 복사해서 한 번 더 붙여주면 됩니다.
5단계 — 실행 + 결과 확인
Change 모드에서 값 입력 완료 후 다시 실행 버튼을 누르면 다음 순서로 진행:
[1] SPROXY 가 XML 을 ABAP 구조체(INPUT 파라미터) 로 변환
[2] Implementing Class 의 비즈니스 메서드 호출
└ Debug method 체크돼 있으면 메서드 첫 줄에서 디버거 START
└ 아니면 그냥 실행되고 결과만 표시
[3] 메서드 안에서 일반 흐름대로:
└ INPUT → 내부 CBO 매핑 → 비즈니스 FM 호출 → COMMIT
[4] 결과 확인
├ 정상: 다이얼로그가 정상 종료, 화면에 "메시지 처리 완료" 표시
├ 예외: cx_ai_application_fault → 빨간 메시지 표시
└ Dump: Don't catch ... 옵션 켰을 때 또는 처리 안 한 예외 → ST22 로 이동처리 후 검증 — Implementing Class 안에서 호출한 Z FM 이 CBO 테이블에 데이터를 잘 넣었는지 SE16 또는 SQL Console 로 확인. 메시지 자체의 처리 흐름은 SXMB_MONI 에 기록되므로 거기서도 확인 가능 (Test 실행도 SXMB_MONI 로그가 남음).
실패 메시지 재현 패턴
운영기에서 거래처가 보낸 메시지가 실패했을 때 같은 케이스를 다시 만들어 디버깅하는 가장 빠른 방법.
[1] SXMB_MONI 에서 실패한 메시지를 더블클릭
[2] Payload 탭에서 Inbound XML 전체 복사
[3] SPROXY → 해당 Inbound 인터페이스 → Test 실행
└ Generate Request Template 으로 화면 생성
[4] Change 모드 진입 → 자동 생성된 XML 을
SXMB_MONI 에서 복사한 XML 로 통째 교체
[5] Debug method 체크 후 실행
└ 운영기에서 발생한 예외 케이스가 그대로 재현됨
└ 디버거로 step 따라가서 원인 파악운영 장애 복구의 가장 흔한 패턴. 거래처에 “다시 보내주세요” 요청 없이 SAP 안에서 단독 재현 가능.
핵심 디테일 — 빠뜨리기 쉬운 함정
- Outbound 인터페이스 선택 — ABAP Object 가 CLAS Class 면 Test Service Provider 메뉴 자체가 안 보임. 반드시 INTF Interface(Inbound) 를 선택
- Implementing Class 비활성 — 자동 생성된 직후 Implementing Class 가 비활성 상태면 Test 가 실패. SE24 에서 Ctrl+F3 으로 활성화 후 재시도
- Request Template 빈 라인 — 0..N 반복 구조에서 라인을 하나도 안 두고 실행하면 Implementing Class 안 LOOP 가 한 번도 안 돈다. 최소 1건은 남기는 게 안전
- xsi:nil 옵션 부적절한 선택 — 일반 테스트에 xsi:nil for all Leaf Elements 켜면 모든 필드가 NULL 로 처리되어 비즈니스 검증이 다 NG. 기본 Generate Request Template 만 사용
- Don't catch 옵션 운영기 사용 — 이 옵션은 개발기 디버깅 전용. 운영기에서 켜면 모든 예외가 dump → ST22 가득 채움
- 트랜잭션 COMMIT — Debug method 로 들어가서 디버거를 중간에 꺼버리면 COMMIT WORK 가 안 돼 CBO 테이블에 데이터가 안 들어감. 결과 확인 시 “DB 반영 됐는지” 까지 같이 봐야 함
- 권한 — S_PROXY — SPROXY Test 권한 객체
S_PROXY가 없으면 Test 메뉴 자체가 비활성. 운영기에서는 보통 개발자만 보유
요약
| 단계 | 화면 | 핵심 행동 |
|---|---|---|
| 1 | SPROXY | INTF Interface 인터페이스 선택 + Properties 확인 |
| 2 | SPROXY 도구 모음 / 메뉴 | Test 아이콘 클릭 → Test Service Provider 팝업 |
| 3 | Test Service Provider 다이얼로그 | Generate Request Template + Debug method 체크 → 실행 |
| 4 | Display / Change Request | 자동 XML 생성 → 연필 아이콘으로 Change 모드 → placeholder 에 실제 값 입력 |
| 5 | 실행 + SXMB_MONI / SE16 | Implementing Class 메서드 호출 → 결과 / DB 확인 |
SPROXY Test Service Provider 의 본질은 “외부 시스템 + PI/PO 없이 SAP 안에서 단독 메시지 시뮬레이션”. Inbound Proxy 개발 단계에서는 이 기능 없이는 거의 일이 진행이 안 됩니다. Generate Request Template 으로 빈 XML 받아 placeholder 만 채우면 메시지가 도착한 것과 동일하게 비즈니스 메서드가 호출되고, Debug method 옵션과 함께 쓰면 step 디버깅까지 가능. 운영 장애 재현·엣지 케이스 검증·회귀 테스트의 표준 도구.
이전 글 “[SAP ABAP] Inbound Proxy 구현 — 외부에서 SAP로 데이터 수신, SPROXY · INTF Interface · Implementing Class” 와 함께 보면 Inbound Proxy 의 구현부터 단독 테스트까지 한 흐름으로 잡힙니다.
Disclaimer — 이 포스트는 실무 정리 노트를 바탕으로 AI 보조로 정리되었습니다.
SPROXY 화면 구성과 Test Service Provider 다이얼로그 옵션은 NetWeaver 버전(ECC 6.0 / S/4HANA on-premise · Cloud) 과 적용된 SAP Note 에 따라 일부 차이가 있을 수 있으니, 실제 적용 시에는 해당 시스템의 SPROXY 메뉴와 권한 객체(S_PROXY) 상태를 함께 확인하시기 바랍니다.
