1. Business Scenario
우리는 SAP ERP 시스템에 연결된 SAP 확장 창고 관리(SAP-EWM)를 사용하고 있습니다.
SAP EWM과 SAP ERP 간의 통합에는 많은 경우 queued 원격 함수 호출(qRFC)이 사용됩니다.
EWM 시스템에서 작업(예: 출고 완료, 입고 확정 등)을 수행하면 이 정보가 ERP로 전송되어야 합니다.
이때 qRFC라는 기술을 사용하여 데이터가 줄을 서서(Queue) 전송되는데,
여러 가지 이유(마스터 데이터 불일치, 커스터마이징 누락 등)로 인해 이 전송이 '실패(Error)' 상태로 멈출 수 있습니다.
모니터링 방법 (두 가지 경로)
오류가 발생한 큐(Failed Queue)는 아래 두 곳에서 확인할 수 있습니다.
- ERP 측 (T-Code: SMQ2):
- 인바운드 큐 모니터입니다. EWM에서 넘어온 데이터가 ERP 입구에서 멈춰 있는 것을 직접 확인합니다.
- EWM 측 (Warehouse Management Monitor):
- EWM 창고 모니터 내의 'Tools' 또는 'Message Queue' 노드에서 ERP로 보낸 메시지의 상태를 확인할 수 있습니다.
- 현업 사용자는 주로 익숙한 EWM 모니터를 사용합니다.
예시 데이터의 의미
큐 이름 DLWSB7GCLNT5001000055701은 대략 다음과 같은 구조를 가집니다:
- DLWS: Delivery 관련 큐임을 나타내는 접두사(Prefix)
- B7GCLNT500: 송신/수신 시스템 정보
- 1000055701: 실제 ERP의 납품(Delivery) 번호 또는 관련 문서 번호
2. 배경 정보 (Background Information)
qRFC는 SAP NetWeaver의 일부인 표준 SAP 기술로, 백그라운드 통신 및 프로세싱을 제공합니다.
또한 재시도(Retry)로직을 지원합니다.
예를 들어, 처리하려는 오브젝트(예: 출고 납품)가 다른 프로세스에 의해 잠겨(Locked) 있는 경우,
qRFC는 나중에 자동으로 재처리를 수행합니다.
또한 오류(예: 잘못된 커스터마이징)가 발생한 경우에도 qRFC를 다시 실행할 수 있습니다.
이러한 장점들 때문에 SAP EWM에서 qRFC를 사용합니다.
3. 사전 요구사항 (Prerequisites)
qRFC 통신 시 인바운드 큐(Inbound Queue)와 아웃바운드 큐(Outbound Queue)를 모두 사용할 수 있습니다.
SAP ERP의 설정에 따라 EWM으로 전송할 때 어떤 큐를 사용할지 선택할 수 있습니다.
(경로: Integration with Other SAP Components → EWM → Basic Settings for EWM Linkage → Define Queue for Transfer to SAP EWM)
기본적으로는 인바운드 큐가 사용되며, EWM 환경에서는 인바운드 큐 사용을 권장합니다.
큐 편집(Queue Editing)의 제약 조건:
- ERP 인바운드 큐에 대해서만 사용 가능합니다.
- SAP가 제공하는 RFC 함수만 편집할 수 있습니다 (이후 설명할 '화이트리스트' 개념 기반).
- 고객 개별 RFC 함수나, 고객이 임의로 파라미터를 추가(Enhancement)한 표준 RFC 함수는 편집이 불가능합니다.
[주의사항 - CAUTION]
큐 편집은 실패한 큐를 해결하기 위한 최후의 수단이어야 합니다.
큐 편집을 고려하기 전에 반드시 다른 방법으로 해결 가능한지 확인하십시오.
일반적인 큐 실패 원인:
- 누락되었거나 잘못된 커스터마이징(설정)
- 권한(Authorization) 부족
- SAP ERP와 EWM 간의 검증 로직 차이 (예: 허용 오차 체크, 유통기한/저장기한 체크, 주소 검증 등)
- 마스터 데이터 누락
- 필요한 SAP Note 미적용
- 회계 관련 메시지 (예: 잘못된 기간에 전기 시도)
위의 경우, 근본 원인(Root Cause)을 해결하여 큐 실패를 처리하는 것이 우선입니다.
SAP는 이러한 일반적인 오류 상황을 해결하기 위한 다양한 컨설팅 노트(Consulting Notes)를 제공합니다.
실패를 도저히 해결할 수 없거나 적시에 해결할 수 없는 경우에만 큐 편집을 옵션으로 고려해야 합니다.
[주의사항 - CAUTION]
수정하려는 qRFC 메시지/함수의 내용과 필드 변경이 백엔드 프로세스에 미치는 영향을 반드시 숙지해야 합니다.
잘못된 값으로 변경하면 **데이터 불일치(Inconsistency)**가 발생할 수 있어 매우 중요합니다.
특정 필드 변경이 어떤 프로세스에서는 무해할 수 있지만, 다른 프로세스에서는 치명적일 수 있습니다.
3.1 SAP EWM 측 설정
이 섹션은 EWM의 창고 모니터 /SCWM/MON에서 ERP 인바운드 큐를 표시하고자 할 때만 필요합니다.
3.1.1 필수 Note:
SAP Note 2226334가 구현되어 있어야 합니다.
3.1.2 RFC 다이얼로그 사용자 (RFC Dialog User):
- EWM에서 ERP 화면으로 넘어가야 하므로, ERP 시스템에 대한 RFC Destination이 'Dialog' 타입의 사용자로 정의되어야 합니다.
- T-Code: BD97에서 해당 ERP 시스템의 표준 다이얼로그 데스티네이션으로 등록해야 합니다.
- 보안상 고정된 사용자 대신 **'현재 사용자(Current User)'**를 사용하는 것이 권한 제어 및 감사(Auditing) 측면에서 권장될 수 있습니다.
3.1.3 qRFC 원격 조회 프로그램 등록:
- T-Code: SPRO 경로에서 Report for Container 필드에 /SCWM/ERP_DISP_QIN_LOG_EWM 프로그램이 등록되어 있는지 확인하십시오.
3.2 SAP ERP 측 설정
3.2.1 필수 Note:
SAP Note 2225968이 구현되어 있어야 합니다.
3.2.2 qRFC 조회 프로그램 등록:
T-Code: SMQE에서 조회 프로그램 /SPE/QUEUE_DISPLAY_TOOLS를 큐 접두사(DLWS*, WMC*, WMP* 등)에 대해 등록해야 합니다.
3.2.3 화이트리스트 (Whitelist)화이트리스트 포함 항목:
- EWM에서 ERP로 보내는 메시지에 사용되는 qRFC 함수 리스트
- 큐 편집 대상이 될 수 있는 해당 함수 모듈의 파라미터들
- 큐 편집 대상이 될 수 있는 해당 파라미터 내의 필드들
이 화이트리스트 개념을 통해 귀하는 사용자가 어떤 필드를 편집할 수 있게 할지 결정할 수 있습니다.[예시]
- 어떤 시나리오(예: 교차 HU가 아닌 경우)에서는 HU 데이터를 삭제하고 SAP ERP에서 HU 없이 재고 이동을 전기하는 것이 보통 문제가 되지 않습니다.
- 하지만 일부 시나리오에서는 나중에 전송될 qRFC 메시지가 해당 HU 정보에 의존하기 때문에 실패하게 됩니다. 이는 특히 **교차 HU(Cross HU)**의 경우에 해당합니다.
기본적으로 시스템에서 큐 편집 기능은 비활성 상태입니다. 큐 편집은 화이트리스트를 사용하여 활성화해야 하며, 이를 통해 어떤 RFC 함수, 파라미터, 필드를 편집에 개방할지 제어할 수 있습니다. 앞서 언급했듯이 SAP는 화이트리스트를 위한 기본 콘텐츠를 제공하며, 고객은 다음 두 가지 방식으로 이를 조정할 수 있습니다.
- 커스터마이징(Customizing): 수정 없이 적용
- 긴급 모드(Emergency Mode)
[마지막 디테일 핵심 요약]
- 비활성이 기본값 (Default Inactive): 큐 편집 기능은 설치하자마자 쓸 수 있는 것이 아닙니다. 화이트리스트에 대상을 등록하는 행위 자체가 "기능을 활성화"하는 스위치 역할을 합니다.
- 연쇄 반응의 위험성 (Downstream Impact): 가장 중요한 디테일은 **"현재 큐를 고치는 것이 미래의 큐에 영향을 준다"**는 점입니다. 예시로 나온 HU(Handling Unit) 데이터처럼, 지금 당장 에러를 해결하려고 값을 지우거나 바꾸면, 뒤따라올 다음 큐들이 참조할 데이터가 사라져 연속적인 에러(Chain Reaction)를 유발할 수 있습니다.
- 두 가지 운영 전략 (CUS vs APPL):
- Customizing (CUS): 정석적인 방법으로, 테스트 서버에서 설정 후 운영 서버로 전송(Transport)합니다. 안정적이고 영구적입니다.
- Emergency Mode (APPL): 운영 서버에서 즉시 수정이 필요할 때 사용하지만, 향후 패치나 전송 시 덮어씌워질 위험이 있는 임시/긴급 대응용입니다.
시스템에서 편집 가능한 큐 콘텐츠를 기반으로 화이트리스트를 구성할 때,
SAP가 제공하는 콘텐츠에는 자주 편집되는 파라미터와 필드들이 포함되어 있음을 유념하십시오.
그럼에도 불구하고, 편집이 후속 문제를 일으킬 수 있는 시나리오가 존재합니다.
따라서 파라미터나 필드의 편집을 허용하기 전에 반드시 해당 시나리오를 테스트해야 합니다.
필드 내용이나 데이터를 잘못된 값 또는 부적절한 값으로 변경할 경우,
큐 편집은 심각한 결과(데이터 불일치, 오류 메시지 발생)를 초래할 수 있습니다.
큐 편집으로 인한 데이터 불일치 생성 리스크를 완화하기 위해, SAP는 편집 가능한 파라미터와 필드를 제어하는 화이트리스트(Whitelist) 개념을 제공합니다.
3.2.3.1 커스터마이징 (수정 없이 적용)
커스터마이징이란 SAP가 제공하는 표준 설정을 사용자의 환경에 맞게 조정하는 것을 의미합니다.
일반적으로 개발/설정 시스템(Customizing System)에서 이러한 설정을 완료한 후, 운영 시스템(Productive System)으로 **운송(Transport)**하여 적용합니다.
이러한 변경 사항은 시스템 소스 코드를 건드리는 '수정(Modification)'이 아니므로,
향후 SAP 업그레이드 시에도 삭제되거나 덮어씌워지지 않습니다.
- 사용 트랜잭션: /SPE/MQWL_CUS
- 설정 방법: 해당 화면에서 'Editable(편집 가능)' 지표(체크박스)를 설정하여 어떤 RFC 함수를 편집할지 정의합니다.
- 기능 활성화: 'Editable'이 설정되고 사용자가 적절한 권한을 가지고 있다면, qRFC 컨테이너 조회 화면에 '편집(Edit)' 버튼이 나타납니다.
- 주의사항:
- 비즈니스 프로세스 구성 상황에 맞춰 이 설정을 진행하십시오.
- 이 트랜잭션 내에서는 SAP가 미리 정해놓은 리스트 외에 추가적인 qRFC 메시지 함수를 임의로 넣을 수 없습니다.
파라미터 및 필드 단위 설정 사용자가 특정 필드를 편집할 수 있게 하려면, 어떤 파라미터의 어떤 필드가 편집 가능한지 정의해야 합니다.
- 파라미터 설정:
- 한 개의 qRFC 메시지를 선택한 후, 트리 메뉴에서 **[qRFC Messages: Parameters]**를 클릭합니다.
- [New Entries] 버튼을 통해 해당 qRFC 메시지의 파라미터를 추가할 수 있으며, F4 도움말을 사용할 수 있습니다.
- 여기서 Editable(편집 가능) 및 Delete(삭제 가능) 지표를 설정합니다.
- Delete(삭제): 테이블 레벨 파라미터(예: HEADER_DEADLINES)에서 전체 행(Line)을 삭제할 수 있는지 제어합니다. 이는 Editable 지표와 독립적으로 작동합니다.
- Editable(편집): 파라미터 내의 개별 필드를 수정할 수 있는지 제어합니다. (실제 수정할 필드는 추가로 지정해야 합니다. 이 지표가 설정되지 않으면 해당 파라미터의 어떤 필드도 편집할 수 없습니다.)
참고 (Note): 이 지표들은 오직 SAP가 편집을 허용하도록 전달한 콘텐츠에 대해서만 변경할 수 있습니다.
필드 단위 화이트리스트 구성
파라미터 내의 개별 필드를 편집할 수 있게 하려면 해당 필드를 명시적으로 지정해야 합니다.
필드 선택 및 진입:
- 특정 qRFC 파라미터를 선택한 후, 탐색 트리에서 **[qRFC Messages: Fields]**를 클릭합니다. (예: /SPE/INB_DELIVERY_CONFIRM_DEC 메시지의 HEADER_DEADLINES 파라미터 설정 시)
필드 추가 및 활성화:
- [New Entries] 버튼을 클릭하여 해당 파라미터 구조 내의 필드를 화이트리스트에 추가합니다.
- 추가한 필드에 대해 'Editable(편집 가능)' 지표를 체크해야 실제 편집 권한이 부여됩니다.
- 입력 시 F4 도움말을 사용하여 해당 파라미터에서 선택 가능한 유효한 필드 리스트를 확인할 수 있습니다.
참고 (Note): 이 지표(Editable)는 오직 SAP가 표준으로 제공한 콘텐츠에 대해서만 변경이 가능합니다.
3.2.3.2 긴급 모드 (Emergency Mode)
경우에 따라 운영 시스템(Productive System)에서 화이트리스트를 직접 수정해야 할 때가 있습니다. 설정 시스템(Customizing System)에서 변경 후 운영 시스템으로 전송(Transport)하는 것이 불가능하거나 시간이 너무 오래 걸리는 상황이 이에 해당합니다. 또 다른 이유로는 평소에는 편집하지 않는 필드를 수정해야 하는 예외적인 상황이 발생했거나, SAP가 미처 편집 필요성을 예상하지 못한 경우일 수 있습니다.
이러한 경우 SAP 구성을 덮어쓰기(수정, Modify) 할 수 있는 옵션이 있습니다.
주의 (CAUTION)
이 작업은 '수정(Modification)'으로 간주되며, 나중에 화이트리스트 콘텐츠를 시스템으로 전송(Transport)할 경우 덮어씌워질 수 있음을 유념하십시오.
또한, SAP가 화이트리스트 표준 콘텐츠에서 편집 가능하도록 제공하지 않은 필드를 수정함으로써 데이터 불일치(Inconsistency)가 발생하지 않도록 반드시 주의해야 합니다.
- 사용 트랜잭션: /SPE/MQWL_APPL
- 작동 방식: 트랜잭션 실행 시, 설정은 운영 시스템에서만 변경되어야 하며 덮어씌워질 수 있다는 경고 메시지가 표시됩니다.
- 특징: SAP가 제공한 화이트리스트 콘텐츠의 제한 없이 변경이 가능합니다. (예를 들어, 이전 커스터마이징 화면에서는 비활성되어 있던 모든 지표들을 자유롭게 수정할 수 있게 됩니다.)
3.2.4 권한 (Authorizations)
큐 편집을 위해 권한 오브젝트 /SPE/QEDIT이 사용됩니다. 화이트리스트 설정은 편집 가능한 필드를 일반적인 관점에서 선언할 뿐이지만, 권한 설정을 통해 서로 다른 사용자가 각기 다른 큐 필드를 편집하도록 세부적으로 지정할 수 있습니다.
화이트리스트 항목이 존재하더라도, 이 권한 오브젝트가 할당되지 않은 사용자는 큐 콘텐츠를 편집할 수 없습니다.
이 권한 오브젝트는 다음과 같은 필드로 구성됩니다(T-Code SU21에서 상세 설명 확인 가능).
| 권한 필드 | 설명 |
| ACTVT | 활동(Activity): 사용자가 파라미터를 수정(02)만 할지, 또는 (테이블 파라미터의 경우) 행을 삭제(06)까지 할 수 있을지 정의합니다. (01-생성은 지원되지 않음) |
| /SPE/RFC | qRFC 함수명: 사용자가 편집할 수 있는 SAP EWM 관련 qRFC 메시지를 특정 함수로 제한할 수 있습니다. |
| /SPE/PARAM | qRFC 파라미터명: 특정 qRFC 메시지 내에서 편집 가능한 파라미터를 제한합니다. |
| /SPE/COMP | 필드명: 특정 파라미터 내의 개별 필드 단위로 편집 권한을 제한합니다. 구조체나 테이블 인터페이스에서 사용 가능하며, 단일 필드인 경우 파라미터 권한만으로 충분합니다. |
[설정 예시] 사용자가 재고 이동(Goods Movement)을 전기하는 모든 메시지에서 **전기일(Posting Date)**만 수정할 수 있고, 다른 필드는 건드릴 수 없게 하려는 경우:
- ACTVT: 02 (변경)
- /SPE/RFC: BAPI_OUTB_DELIVERY_CONFIRM_DEC, /SPE/INB_DELIVERY_CONFIRM_DEC, /SPE/GOODSMVT_CREATE
- /SPE/PARAM: HEADER_DEADLINES, IS_GOODSMVT_HEADER
- /SPE/COMP: TIMESTAMP_UTC, PSTNG_DATE, DOC_DATE
4 Queue Editing
5 Step-by-Step Procedure
5.1 큐 컨테이너 표시 (Display Queue Container)
큐 목록에서 실제 큐 콘텐츠(데이터)로 이동하려면 다음 단계를 수행하십시오.
- SAP ERP(SMQ2)를 사용하는 경우: 오류가 발생한 **큐 이름(Queue Name)**을 더블 클릭합니다.
- EWM 창고 모니터를 사용하는 경우: 해당 큐 항목을 선택한 후, 데이터 컨테이너(Data Container) 버튼을 클릭합니다. (문서상의 아이콘 참조)
그림 10(Figure 10)에서 큐 콘텐츠 표시 화면의 예시를 확인할 수 있습니다. 만약 귀하가 적절한 **권한(/SPE/QEDIT)**을 가지고 있고 화이트리스트 설정이 완료되었다면(사전 요구사항 참조), 화면에 편집(Edit) 버튼이 활성화되어 나타납니다.
5.2 Make Changes
5.2 큐 콘텐츠 편집 (Edit Queue Content)
편집 버튼을 누르면 **편집 모드(Edit Mode)**로 전환됩니다(Figure 11 참조). 편집 모드에서는 귀하의 권한과 화이트리스트 설정에 따라 필드 값을 변경할 수 있습니다. 예시에서는 IS_GOODSMVT_HEADER 파라미터의 전기일(Posting Date) 필드를 수정할 수 있는 것을 확인할 수 있습니다.
주의 (CAUTION)
편집 모드에서 값을 변경할 때는 반드시 **유효한 값(Valid values)**만 입력해야 합니다. 또한, **올바른 형식(Format)**을 입력하도록 주의하십시오. 예를 들어, 날짜나 시간은 때때로 타임스탬프(Timestamp) 형식으로 저장됩니다. 즉, 입력하려는 데이터의 정확한 타입을 알고 있어야 합니다. 보통 기존 값을 수정할 때는 형식을 쉽게 파악할 수 있지만(예시의 전기일처럼), 필드가 비어 있는 상태에서 새 값을 입력하려는 경우라면 무엇을 입력해야 하는지 사전에 정확히 확인해야 합니다.
참고 (Note)
이 사용자 인터페이스(UI)는 **기술적 인터페이스(Technical UI)**입니다.
시스템은 숫자 필드에 문자가 들어갔는지 정도의 아주 기본적인 체크만 수행할 뿐,
비즈니스 로직 체크(Business checks)는 전혀 수행하지 않습니다.
따라서 유효한 값이 입력되도록 보장할 책임은 전적으로 사용자에게 있습니다.
5.3 변경 사항 저장 또는 취소 (Save or Cancel Changes)
데이터 수정을 마친 후에는 다음과 같은 옵션을 선택할 수 있습니다.
5.3.1 변경 취소 (Cancel changes)
수정한 데이터를 저장하지 않고 종료하려면 뒤로 가기(Back), 취소(Cancel), 또는 종료(Exit) 버튼 중 하나를 클릭하십시오. 이 경우 큐 항목은 변경되지 않은 상태로 유지됩니다.
5.3.2 변경 사항 저장 (Saving of changes)
변경 사항을 저장하려면 다음과 같은 옵션이 있습니다.
- 저장 버튼 (Replace) 가장 기본적인 방법은 변경 사항을 그대로 저장하는 것입니다. 이는 "Replace(교체)" 버튼을 사용하여 수행할 수 있습니다 (Figure 11 참조). 이 버튼을 클릭하면 데이터가 저장됩니다. 이때 큐의 상태는 NOEXEC (Transaction recorded, 트랜잭션 기록됨) 상태로 전환됩니다. Figure 12에서는 SMQ2 트랜잭션에서 큐 조회를 시작했을 때 이 상태가 어떻게 표시되는지 예시를 확인할 수 있습니다.
5.3.2.2 저장 및 자동 실행
데이터를 수정한 후, 수동으로 저장만 하거나 혹은 저장과 동시에 실행까지 시도할 수 있습니다.
- 화면 갱신 (Refresh): EWM 창고 모니터에서 큐 조회를 시작한 경우, 데이터를 수정하고 돌아와도 메시지 큐 리스트는 그림 2와 같이 이전 상태 그대로 보일 수 있습니다. 이는 EWM 모니터의 데이터 컨테이너 표시 기능에 **자동 새로고침(Automatic Refresh)**이 기본적으로 설정되어 있지 않기 때문입니다. 따라서 변경된 상태(예: NOEXEC 등)를 확인하려면 반드시 새로고침(Refresh) 버튼을 클릭해야 합니다.
- 저장 및 실행 버튼 (Save and Execute): 사용자가 '저장' 후 '수동 실행'이라는 두 단계를 거치지 않도록, 데이터를 저장함과 동시에 자동으로 큐를 실행하는 버튼이 제공됩니다.
- 성공 시: 큐가 에러 없이 처리되면 ERP의 SMQ2 목록에서 즉시 사라집니다. (EWM 모니터에서는 새로고침을 해야 사라짐)
- 실패 시: 데이터를 수정했음에도 불구하고 여전히 오류가 발생한다면, 큐는 새로운 오류 메시지와 함께 다시 목록에 나타납니다.
- 변경 사항이 없을 시: 아무런 수정을 하지 않고 이 버튼을 누르면 "저장이 필요하지 않음"이라는 알림이 뜹니다.
- 성공 메시지: 수정 사항이 반영되어 실행되면 그림 13과 같은 성공 메시지가 표시됩니다.
[마지막 디테일 핵심 요약]
실무 운영 시 혼동하기 쉬운 3가지 기술적 포인트입니다.
화면 동기화의 시차 (Manual Refresh Required):
가장 빈번하게 발생하는 혼란은 "분명히 수정하고 저장했는데 왜 모니터에는 그대로 에러로 떠 있는가?"입니다. EWM 모니터는 실시간 반영 방식이 아니므로, 수정 후 반드시 상단의 새로고침(Refresh) 아이콘을 누르는 습관을 가져야 합니다.
에러의 연쇄 확인 (Iterative Troubleshooting):
'저장 및 실행'을 눌렀는데도 큐가 사라지지 않고 메시지만 바뀌었다면, 이는 첫 번째 장애물을 넘었더니 두 번째 장애물(예: 수량 허용치 에러 해결 후 회계 기간 마감 에러 발생)이 나타난 것입니다. 큐 편집은 이처럼 오류를 하나씩 제거해 나가는 반복적인 과정이 될 수 있습니다.
자동 실행의 효율성:
단순 오타 수정이나 날짜 변경처럼 확실한 수정의 경우 'Save and Execute' 버튼을 사용하는 것이 효율적입니다. 하지만 수정 값이 불확실하여 실행 결과를 모니터링해야 하는 경우라면, 우선 'Replace(저장)'만 하여 NOEXEC 상태를 만든 뒤,
SMQ2에서 수동으로 하나씩 실행하며 로그를 확인하는 것이 더 안전한 접근법입니다.
5.4 데이터 변경 모니터링 (Monitor Data Changes)
위에 언급된 기능을 통해 큐 데이터가 변경된 경우, 해당 내역은 **애플리케이션 로그(Application Log)**에 기록됩니다.
- 조회 트랜잭션: SLG1
- 로그 오브젝트: /SPE/QUEUE
- 하위 오브젝트(Subobject): QUEUE_EDIT
- 로그 보존 기간: 로그는 자동으로 생성되며, 만료 기간은 180일로 설정되어 있습니다. (그림 14 참조)
로그 상세 화면에서 특정 메시지 라인을 선택하고 상세 정보(Details) 아이콘을 클릭하면 다음과 같은 정보를 확인할 수 있습니다.
- 원본 데이터 전체: 변경 전 원래 큐에 담겨 있던 전체 데이터 콘텐츠.
- 변경 필드 내역: 어떤 필드가 바뀌었는지, **이전 값(Old Value)**과 **새로운 값(New Value)**을 보여줍니다. (테이블 항목의 삭제 및 삽입 내역 포함)
- 기술 정보: 원본 큐와 새로 생성된 큐에 대한 기술적인 정보(예: TID 등).
이 로그를 통해 나중에 시스템에서 어떤 큐에 대해 어떤 변경 작업이 수행되었는지 추적하고 모니터링할 수 있습니다.
참고 (Note)
애플리케이션 로그에는 편집 중에 변경된 데이터에 대한 항목이 기록됩니다. 테이블 형태의 파라미터(그림 16에 표시된 HEADER_DEADLINES 등)의 경우, 해당 테이블 파라미터의 어떤 항목이 변경, 삭제 또는 삽입되었는지 식별하는 것이 필요합니다.
이를 위해 로그 항목에 표시되는 **Table Key(테이블 키)**와 Line(행) 필드가 사용됩니다 (그림 15 참조).
- Table Key 필드: 테이블 파라미터 내에서 특정 행을 식별하는 데 도움이 되는 필드들이 하나로 합쳐져(Concatenated) 표시됩니다. 어떤 필드들이 합쳐지는지는 데이터 컨테이너 화면에서 하이라이트 처리된 필드를 통해 확인할 수 있습니다 (그림 16 참조).
- 주의: 이 식별용 필드들 또한 화이트리스트에 설정되어 있다면 편집이 가능합니다.
- Line 필드: 영향(변경/삭제 등)을 받은 테이블의 행 번호가 기재됩니다.
1. 변경 지시자(Change Indicator)의 역할
테이블 내에서 행 단위의 추가나 삭제가 이루어지면, 로그는 개별 필드 값을 일일이 나열하는 대신 Change Indicator 필드를 통해 해당 행의 상태 변화를 요약해서 보여줍니다.
- 삭제(Deletion): 특정 행이 통째로 사라졌음을 표시합니다.
- 삽입(Insertion): 새로운 데이터 행이 추가되었음을 표시합니다.
- 이는 로그의 가독성을 높이고, 단순 값 수정(Update)과 구조적 변경을 명확히 구분해 줍니다.
2. 라인 번호(Line Number)의 재사용 이슈
가장 주의 깊게 보셔야 할 기술적 디테일은 라인 번호의 중복 가능성입니다.
- 상황: 만약 기존의 5번 행을 삭제하고, 서로 다른 키 값을 가진 새로운 행을 추가한다면, 시스템은 새 행에 다시 5번이라는 번호를 부여할 수 있습니다.
- 위험성: 단순히 "5번 행이 처리되었다"는 정보만으로는 이것이 원래 있던 데이터인지, 새로 들어온 데이터인지 혼동할 수 있습니다.
3. 테이블 키(Table Key)의 중요성 (재강조)
위와 같은 라인 번호 재사용 상황 때문에 Table Key 필드가 결정적인 역할을 합니다.
- 라인 번호가 같더라도 **Table Key(하이라이트된 필드들의 조합)**를 확인하면, 삭제된 행의 키와 삽입된 행의 키가 다르다는 것을 알 수 있습니다.
- 이를 통해 "어떤 논리적 데이터를 지우고, 어떤 새로운 데이터를 넣었는지"에 대한 정확한 추적이 가능해집니다.
실무적 시사점
로그를 분석할 때 Line 번호는 참고용 '물리적 위치'로만 활용하시고, 실제 어떤 데이터가 어떻게 변했는지 확신하기 위해서는 반드시 Table Key와 Change Indicator를 조합하여 해석해야 합니다. 특히 대량의 데이터를 수정하거나 행을 교체했을 때 이 두 필드의 연동 확인은 필수적입니다.
6 Appendix
부록 A – 원본 큐와 편집된 큐의 차이점
모든 큐 항목은 고유한 **트랜잭션 식별자(TID)**에 의해 식별됩니다. 이 TID는 SMQ2 화면이나 창고 관리 모니터에서 확인할 수 있습니다.
일반적으로 이 기능을 "큐 편집"이라고 부르지만, 기술적으로는 기존의 큐 항목이 수정되거나 변경되는 것이 아닙니다.
대신, 원본 큐 항목(기존 TID)은 삭제되고, 변경된 데이터를 가진 새로운 큐 항목이 생성됩니다. 이 과정에서 다음과 같은 변화가 일어납니다.
- 새로운 TID 할당: 생성된 신규 큐 항목은 이전과 다른 새로운 TID를 부여받습니다.
- 사용자 이름 변경: 새 큐 항목은 편집을 수행한 사용자에 의해 생성되므로, 편집한 사람의 사용자 이름이 기록됩니다.
[예시] 사용자 SMITH가 큐를 편집했다고 가정해 보겠습니다.
- 원본 큐: 사용자 이름 ALEREM으로 생성됨 (Figure 18 참조).
- 편집된 큐: 사용자 이름 SMITH로 생성됨 (Figure 19 참조).
- 결과: 두 큐의 qRFC 트랜잭션 ID(TID)가 서로 다릅니다.
이처럼 사용자 이름과 TID가 변경되는 현상은 시스템 운영에 몇 가지 영향을 미칠 수 있으므로 반드시 고려해야 합니다.
사용자 이름 (User Name)
큐 항목이 처리될 때는 큐에 저장된 사용자 이름을 바탕으로 실행됩니다. 즉, 모든 애플리케이션 권한 체크는 해당 사용자 이름을 기준으로 수행됩니다. 또한 시스템 로그 기록 시에도 이 사용자가 나타납니다. 만약 다른 사용자가 큐를 편집하면, 새 큐 항목은 그 새로운 사용자 이름으로 처리됩니다. 따라서 해당 사용자가 큐를 정상적으로 처리할 수 있도록 적절한 애플리케이션 권한을 보유하고 있는지 반드시 확인해야 합니다.
트랜잭션 ID (TID)
TID는 SMQ2나 창고 관리 모니터에서 개별 큐 항목을 식별하는 고유 번호로 사용됩니다. 큐 데이터를 수정하고 저장하면 시스템은 원래의 화면(SMQ2 또는 모니터)으로 돌아가지만, 이 화면들은 **데이터 자동 새로고침(Automatic Refresh)**을 수행하지 않습니다. 따라서 화면에는 여전히 '이전' TID가 표시됩니다. 이때 사용자가 새로고침 없이 편집 및 교체된 큐에 대해 어떤 작업을 수행하려고 하면, 시스템은 해당 TID를 찾을 수 없습니다. (원본 큐는 삭제되고 새 TID를 가진 큐로 교체되었기 때문입니다.)
- 결과: 후속 작업이 TID를 참조하는 방식에 따라 에러 메시지가 발생하거나 작업이 실행되지 않습니다. (예: SMQ2에서 새로고침 없이 실행/조회 시 에러 발생)
- 주의: TID를 활용하는 별도의 개발 프로그램이나 프로세스가 있다면 이러한 동작 방식을 반드시 고려해야 합니다.
큐 내에서의 순서 (Sequence of Queue Entry)
앞서 설명했듯이 원본 큐는 삭제되고 새로운 큐가 생성됩니다. 하나의 큐 이름 아래에 여러 개의 항목이 존재할 수 있는데(Figure 20 참조), 특정 항목(예: /SPE/INB_DELIVERY_REPLACE)을 삭제하고 새로 만들더라도
해당 항목이 기존에 가지고 있던 순서 번호(Sequence Number)를 그대로 유지해야 합니다.
큐 편집 로직은 이를 보장합니다. 즉, 기술적으로는 삭제 후 재생성이지만, 리스트 상의 실행 순서는 변함없이 유지됩니다.
부록 B – 동시성 제어 (Concurrency Handling)
사용자가 큐를 편집하는 동안 다른 사용자나 프로세스가 동일한 큐 항목 또는 큐 이름에 접근하려고 할 수 있습니다.
시스템은 이를 방지하기 위한 안전장치를 갖추고 있습니다.
예를 들어, 사용자가 편집 중인 큐를 다른 프로세스가 동시에 실행하여 충돌을 일으키지 않도록 제어합니다.
큐의 정지 (Stopping of a Queue) 사용자가 큐 편집을 시작하면 해당 큐 전체가 'STOP' 상태로 설정됩니다.
(이는 SMQ2의 '즉시 큐 잠금' 기능과 동일합니다.)
- SMQ2: 상태란에 STOP으로 표시됩니다 (Figure 21 참조).
- 창고 관리 모니터: **자물쇠 아이콘(Lock Symbol)**으로 표시됩니다 (Figure 22 참조).
- 참고: 이 STOP 상태는 큐 편집만을 위한 특수 상태가 아니라, SAP 표준 큐 잠금 기능을 편집 프로세스에서 그대로 활용하는 것입니다.
[마지막 디테일 핵심 요약]
실무자가 큐 정체 현상을 분석할 때 반드시 알아야 할 3가지 기술적 포인트입니다.
- FIFO 원칙의 고수 (Sequence Integrity): 큐 편집이 삭제 후 재생성 방식임에도 불구하고 순서가 유지되는 것은 매우 다행스러운 일입니다. 만약 순서가 뒤섞인다면, 입고(Inbound) 큐가 처리되기 전에 입고 취소(Cancellation) 큐가 먼저 실행되는 등의 데이터 정합성 오류가 발생할 수 있기 때문입니다. 큐 편집 도구는 내부적으로 기존 순서값을 복사하여 새 큐에 이식합니다.
- 전체 큐 잠금의 파급 효과 (Queue-Level Lock): 가장 중요한 운영상 디테일은 **"특정 항목 하나만 막히는 게 아니라 큐 전체가 멈춘다"**는 점입니다. 어떤 관리자가 특정 큐를 편집하기 위해 화면을 열어놓고 자리를 비우면, 해당 큐 이름(Queue Name)을 공유하는 모든 후속 데이터들이 처리되지 못하고 줄줄이 대기하게 됩니다. 편집 작업은 가능한 한 신속하게 마쳐야 합니다.
- 잠금 해제의 자동화: 편집을 마치고 저장(Replace)하거나 취소(Cancel)하고 화면을 빠져나오면, 시스템은 자동으로 STOP 상태를 해제합니다. 하지만 비정상적인 종료(네트워크 단절 등) 시 큐가 STOP 상태로 남아있을 수 있으므로, 편집 후에는 반드시 SMQ2나 모니터에서 자물쇠 아이콘이 사라졌는지 확인하는 습관이 필요합니다.
큐 잠금 상태의 특성 및 주의사항
STOP 상태로 설정된 큐는 사용자나 다른 자동화 프로세스에 의해 처리되거나 실행될 수 없습니다. 이 STOP 상태는 큐 편집 작업이 완전히 종료(저장 또는 취소)될 때 비로소 해제됩니다.
주의 (CAUTION) 정지(STOP) 상태인 큐에 임의로 개입하지 마십시오.
큐 항목이 편집되고 있는 동안에는 큐 잠금(STOP 상태)을 강제로 해제하거나, 실행, 디버깅, 또는 큐 항목을 별도로 저장하는 행위를 해서는 안 됩니다.
이러한 개입은 편집된 큐를 저장하는 과정에서 **데이터 불일치(Inconsistency)**를 유발하거나 오류 메시지를 발생시킬 수 있습니다.
부록 C – 오류 처리 (Error Handling)
큐 편집 후 STOP 상태가 유지되는 경우 큐 편집이 완료되었음에도 불구하고 STOP 상태가 해제되지 않고 남아있는 경우가 발생할 수 있습니다. 이는 큐 편집 세션이 예상치 못하게 종료되었을 때 주로 발생하며, 원인은 다음과 같습니다.
- 시스템 덤프: Short Dump 또는 Assertion으로 인한 프로세스 강제 종료
- 디버깅 중단: 사용자가 디버깅 세션을 강제로 종료한 경우
- 세션 삭제: 관리자나 사용자에 의해 프로세스나 세션이 강제로 삭제된 경우
이러한 경우 STOP 상태가 계속 유지되어 큐가 자동으로 처리되지 않습니다. 이럴 때는 수동으로 STOP 상태를 제거할 수 있습니다.
해결 방법:
SAP ERP에서 트랜잭션 SMQ2를 실행하거나, 창고 관리 모니터에서 SMQ 화면으로 이동합니다. 해당 큐를 선택한 후 [Unlock Action(잠금 해제)] 버튼을 클릭합니다 (Figure 23 참조).
부록 D – 사용 편의성 향상
수동 새로고침 방지
'부록 A'에서 설명했듯이, 큐 콘텐츠를 변경한 후 후속 작업을 수행하려면 수동 새로고침이 필요할 수 있습니다.
만약 창고 관리 모니터(EWM Monitor)를 사용 중이라면 다음과 같은 방법으로 이를 개선할 수 있습니다.
EWM 모니터의 데이터 컨테이너 표시 액션은 자동 새로고침을 사용하지 않도록 설정되어 있습니다.
그 이유는 보통 데이터를 '조회'만 할 때는 새로고침을 원하지 않기 때문입니다.
이에 대한 대안으로, 편집 전용의 고객 전용(Customer-specific) 모니터 액션을 새로 만들 수 있습니다.
이 액션은 기존 조회 기능과 동일하지만 자동 새로고침이 설정되어 있다는 점이 다릅니다.
설정 방법:
- EWM 모니터 개념 숙지: 새로운 모니터 액션을 추가하는 방법은 SAP 도움말이나 가이드("How to Add Application Content to the Whse. Mgt. Monitor")의 5장을 참조하십시오.
- 모니터 메소드 복사 및 생성: 기존 큐 표시 액션(오브젝트 클래스: MQUEUE, 메소드 함수: /SCWM/MSG_LOG_DISPLAY)을 복사하여 새로운 고객 전용 모니터 메소드를 생성합니다.
- 자동 새로고침 활성화: 새로 만든 엔트리에서 자동 새로고침(Automatic Refresh) 지표(Indicator)를 설정합니다.
부록 E – 자주 묻는 질문(FAQ)*
[상세 번역 및 핵심 해설]
Q1. 편집 버튼이 안 보이거나 필드 수정이 안 됩니다.
- 답변: 화이트리스트 설정(3.2.3)에 해당 메시지/파라미터/필드가 등록되어 있는지 확인하십시오. 또한, 사용자에게 /SPE/QEDIT 권한(3.2.4)이 적절히 부여되었는지 점검하십시오.
Q2. 내가 직접 만든(Z-Custom) qRFC 메시지도 편집할 수 있나요?
- 답변: 아니요, 불가능합니다. 오직 SAP가 화이트리스트를 통해 제공한 표준 qRFC 메시지만 편집할 수 있습니다. 사용자가 임의로 자신의 함수를 추가할 수 없습니다.
Q3. 표준 qRFC 함수에 내가 만든 파라미터를 추가해서 편집할 수 있나요?
- 답변: 절대 권장하지 않습니다. 기술적으로 인터페이스 수정은 가능하지만, 큐 편집 도구는 이를 지원하지 않습니다. 사용자 정의 파라미터는 화면에 표시되지 않으며 편집도 불가능합니다. 대신 에러 메시지가 발생합니다.
- 주의 (CAUTION): 에러를 우회하려 하지 마십시오. 사용자 정의 파라미터를 강제로 끼워 넣을 경우, **데이터 유실(Data Loss)**이 발생할 수 있으며 새로 복사된 큐에 해당 데이터가 포함되지 않을 수 있습니다.
- 해결책: 나만의 데이터를 전달해야 한다면 대부분의 표준 함수에 포함된 IT_EXTENSIONIN 같은 표준 확장 파라미터를 활용하십시오.
Q4. 큐 편집 후 후속 작업(재시작 등)을 하려는데 에러가 나거나 아무 반응이 없어요.
- 답변: 큐 편집 시 새로운 TID가 생성됩니다(부록 A 참조). 화면에 여전히 옛날 TID가 떠 있을 수 있으니, **새로고침(Refresh)**을 누른 후 다시 시도하십시오.
Q5. 테이블 조회 화면에서 녹색으로 하이라이트된 필드는 무엇이며, 편집 가능한가요?
- 답변: 이 필드들은 해당 테이블의 행을 식별하는 '키 필드'입니다. 상세 내용은 5.4장을 참조하십시오. (설정에 따라 편집은 가능하지만 식별용임을 인지해야 합니다.)
- 커스텀 개발과의 충돌 주의 (No Workarounds): 가장 중요한 부분입니다. SAP EWM 프로젝트 시 표준 BAPI나 RFC 인터페이스를 확장하는 경우가 많은데, 이때 추가한 필드들은 큐 편집 도구에서 '투명 인간' 취급을 받습니다. 만약 큐 편집을 자주 사용해야 하는 핵심 인터페이스라면, 커스텀 필드를 추가하기보다 EXTENSION 구조를 활용하는 것이 큐 편집 도구와의 호환성을 지키는 길입니다.
- 데이터 유실의 공포: FAQ에서 언급된 "Data Loss"는 매우 심각한 경고입니다. 사용자가 데이터를 고치고 저장했는데, 시스템이 인식하지 못하는 커스텀 파라미터 값이 새 큐를 만들 때 누락되어 버린다면 원인 파악이 매우 힘든 논리적 오류를 야기할 수 있습니다.
- 확장의 한계 인정: 이 도구는 '범용 데이터 수정기'가 아니라 **'SAP가 허용한 안전한 필드에 대한 응급 처치 도구'**임을 명확히 인지해야 합니다.
지금까지의 긴 여정을 한 페이지로 요약해 드립니다. 큐 에러 발생 시 이 순서대로 검토하세요!
- [ ] 1단계 (설정 확인): SM30 -> /SPE/MQWL_CUS에서 해당 필드가 화이트리스트에 있는가?
- [ ] 2단계 (권한 확인): 내 계정에 /SPE/QEDIT 오브젝트와 ACTVT 02 권한이 있는가?
- [ ] 3단계 (진입): SMQ2 또는 EWM 모니터에서 'Data Container' 아이콘을 클릭했는가?
- [ ] 4단계 (수정): 'Replace' 버튼을 누르기 전, 데이터 형식이 정확한가? (비즈니스 체크 없음!)
- [ ] 5단계 (저장): 저장 후 상태가 NOEXEC로 바뀌었는지 확인했는가?
- [ ] 6단계 (새로고침): 반드시 Refresh를 눌러 새로운 TID를 불러왔는가?
- [ ] 7단계 (실행): 'Execute'를 눌러 큐가 리스트에서 사라지는지 확인했는가?
- [ ] 8단계 (모니터링): SLG1에서 변경 이력이 정상적으로 남았는지 확인했는가?
see note 3004810
'SAP' 카테고리의 다른 글
| [EWM] 이동 거리 계산 / 시리얼 관리 (0) | 2026.03.21 |
|---|---|
| [EWM] 쓸만한 sap notes 파일 - 개발관련 (0) | 2026.03.15 |
| [EWM] ewm의 Delivery 삭제 확인 (0) | 2026.03.07 |
| [ABAP] 테이블명 변수로 테이블 데이터 가져와서 해당 데이터로 다른 테이블 업데이트 (0) | 2026.02.27 |
| [EWM] 왜 batch를 별도 CBO성 필드로 관리하는가 (0) | 2026.02.26 |