SAP ABAP

SAP Background Job 관리와 SM37 분석

모델와이 2025. 4. 18. 10:00

 

안녕하세요. 모델와이입니다.

SAP 프로젝트 운영이나 구축을 하다 보면 하루에도 수십~수백 개의 Background Job이 실행되며 시스템 핵심 업무를 떠받치고 있습니다.
그런데 의외로 많은 분들이 SM37 화면에서 “Canceled”만 보고 끝나는 경우가 많죠.
오늘은 실전에서 자주 발생하는 Job 오류 대응법과 튜닝 포인트, 그리고 SM13과 SPOOL을 활용한 디버깅 방법까지 블로그로 정리해보겠습니다.


 1. SAP Background Job이란?

Background Job은 SAP 내에서 대량 데이터나 반복 업무를 자동으로 수행하기 위한 핵심 기능입니다. 주로 아래와 같은 용도로 사용됩니다:

  • FI Posting (BAPI 또는 Batch Input 방식)
  • 외부 인터페이스 수신/송신 처리
  • 마감 정산/배치 정리
  • 오류 전표 재처리

등록은 SM36, 모니터링은 SM37에서 진행합니다.


 2. Job 처리 실패 유형과 SM37 확인 포인트

SM37 트랜잭션에서 Job 실행 상태를 확인할 수 있습니다.

📷 [ SM37 화면 예시 ]

 

상태 설명 조치 필요 여부

✅ 종료됨 정상 처리 완료 정상 처리 후 완료
⚠️ 취소 (Red) Job 처리 실패 ✅ 원인 분석 필요
⏳ 활성 실행 중 일정 시간 이상이면 Loop 또는 Resource 대기 의심
⬜ 릴리스됨 실행 대기 중 트리거 시간 또는 조건 확인

 3. 오류 분석 ① – SM13에서 Commit 실패 확인

SAP에서는 DB Commit 작업이 실패하면 해당 트랜잭션이 Rollback되고 SM13 로그에 기록됩니다.

📍 SM13 확인 절차

  1. 트랜잭션 코드 SM13 입력
  2. 사용자 ID 또는 날짜로 필터 설정
  3. 오류 항목 더블클릭 → 상세 로그 확인

📷 [ SM13 오류 로그 상세 화면 ]

SM13 조회 후 화면

 

조회 화면 중 오류 내역 더블클릭 시 세부 화면

 

✔️ 예시 메시지 :

“RV_DELIVERIES_SAVE” -> 해당 내역을 더블클릭 시 세부 오류 내역 확인 가능

세부 오류 내역

 

🛠️ 조치 팁:

  • Update Module 내 구조 체크
  • 커스터마이징 필드 변경 여부 확인
  • 전표 내 필수 필드 누락 여부 검토

 4. 오류 분석 ② – SPOOL 출력 확인

SPOOL은 Job 실행 결과에 대한 출력물을 의미하며, 리포트의 로그나 메시지를 확인할 수 있습니다.

📍 SPOOL 확인 절차

  1. SM37 → 해당 Job 선택 → 상단 [Spool] 버튼 클릭
  2. Job 수행 시 WRITE 구문이 있을 경우 SPOOL에 기록됨
  3. 오류 메시지 또는 처리 건수 확인 가능

📷 [이미지 삽입: Spool 리스트 및 출력 로그 예시]

🛠️ 조치 팁:

  • Z 프로그램 내에 WRITE, MESSAGE, FORMAT 구문 추가하여 실시간 메시지 기록
    -> 프로그램 내 로직을 선언하지 않으면 해당 내역에 대한 로그가 표출되지 않으니 주의 !!
  • SPOOL 없는 Job이라면, ZLOG 테이블 설계 또는 ALV 팝업 전환 고려
  • SPOOL이 없지만 내부의 작업 로그를 통해 메시지만 확인도 가능

 5. Job 처리 성능을 위한 개발 전략

✅ Commit 주기 조절

대량 전표 처리 시, Commit이 너무 잦으면 Lock 경합 발생 / 너무 적으면 DB에 부담

LOOP AT it_data INTO wa_data.
  " 데이터 처리
  counter = counter + 1.

  IF counter MOD 100 = 0.
    CALL FUNCTION 'BAPI_ACC_DOCUMENT_POST'.
    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
  ENDIF.
ENDLOOP.

✅ 병렬 처리 적용

SAP ABAP에서는 CALL FUNCTION … STARTING NEW TASK 구문으로 병렬 작업을 수행할 수 있습니다. 단, 시스템 리소스 고려 필요!

다른 병렬 처리 방식에 대해선 다음 포스팅에서 살펴보겠습니다 !

CALL FUNCTION 'ZFI_PARALLEL_PROCESS'
  STARTING NEW TASK lv_taskname
  DESTINATION IN GROUP DEFAULT
  PERFORMING callback_form ON END OF TASK
  EXPORTING ...

🔷 6. JOB 설계 Best Practice

항목 권장 내용

JOB 명명 ZJOB_<업무명>_<주기> 예: ZJOB_FI_POST_DAILY
사용자 ID 별도 BATCH 계정 사용 (ex. ZBATCHUSR)
결과 저장 로그 테이블 별도 설계 (ZLOG_JOB_RESULT)
실패 건 재처리 실패 전표를 자동으로 다시 JOB 처리할 수 있는 Z 리포트 연결
이메일 알림 SAPConnect 설정 or ZMAIL 자동 발송 처리 로직 구축

✅ 마무리 요약

체크리스트 내용

SM37 상태 확인 Cancelled/Active 시 주의 -> 권한 막힐 경우 SM37DISP 실행
SM13 로그 확인 Update Task 실패 여부 분석
SPOOL 출력 확인 WRITE 메시지 기반 분석
Commit 설계 BAPI 처리 수에 따라 주기 조정
병렬 처리 데이터량 많을 때만, 제한 조건 확인
재처리 전략 실패 전표 자동 재처리 필수

 

대량 전표 처리 JOB에서 발생하는 오류는 대부분 커밋 문제, 필드 누락, 코드 로직 미비에서 발생합니다.
SM13, SPOOL을 통해 원인을 추적하고, 재처리 가능한 유연한 구조로 개발하는 것이 중요합니다.
다음 포스팅에서는 배치 병렬 처리에 대한 포스팅을 진행해보겠습니다.

감사합니다.
궁금하신 사항 있으시면 댓글에 남겨주세요.