STMS에서 급한 요청만 먼저 가져왔는데, 다음 전체 가져오기 뒤 왜 옛 버전으로 돌아갈 수 있을까

평소 운영 시스템에는 일주일에 한 번 대기열 전체를 가져오는데, 오류가 나서 급한 수정 요청 하나만 STMS에서 먼저 가져왔다고 해 봅시다. 프로그램은 고쳐졌습니다. 그런데 다음 정기 가져오기가 끝나면 그 프로그램이 다시 옛 버전이 될 수 있습니다. 이 글을 읽고 나면 단독 가져오기 전에 대기열과 Options 탭에서 무엇을 볼지, 이미 옛 버전이 됐다면 어떤 근거로 확인할지 말할 수 있습니다.

시스템 DV1·PR1, 요청 번호, 프로그램 ZDEMO_PRICE_CALC, 버전 표시 v1·v2, 요일과 시각은 모두 지어낸 값입니다. SAP 시스템에서 실행하지 않았고, 동작은 SAP Help Portal의 Change and Transport System 문서(ABAP Platform 2025 FPS02판, 비교한 곳은 NetWeaver 7.50 SPS29판)를 읽고 적었습니다. 릴리스한 요청이 왜 바로 운영에 보이지 않는지는 전송 요청과 태스크 글에서 다뤘으니, 여기서는 가져오는 순서만 봅니다.

같은 프로그램이 대기열에 두 번 들어 있다

PR1 대기열에 요청 세 개가 있습니다. 문서에 따르면 전체 가져오기는 대기열 순서로 진행되고, 그 순서는 내보낸 순서입니다. 먼저 내보낸 101에는 ZDEMO_PRICE_CALC의 v1이, 102에는 다른 프로그램이, 마지막 103에는 같은 프로그램의 수정본 v2가 들어 있습니다(그림의 1, 2).

정기 가져오기 사이에 운영 오류를 고치려고 요청을 먼저 넣는 일은 문서도 예로 드는 정상 경로입니다. 단독 가져오기를 고르면 나머지 요청은 대기열에 남습니다. 목요일에 103만 가져오면 PR1의 ZDEMO_PRICE_CALC는 v2가 되고 101은 그대로 기다립니다. 나중에 내보낸 요청이 앞선 요청을 추월한 상태입니다. 문제는 이다음 전체 가져오기입니다. 이때 들어가는 요청은 Request waiting to be imported와 Request is ready for import again 두 상태뿐입니다(그림의 3).

갈림길은 Options 탭의 체크 하나다

단독 가져오기 대화 상자의 Options 탭에 Leave Transport Request in Queue for Later Import가 있습니다(그림의 1).

켜 두면 단독 가져오기는 선행 가져오기(preliminary import)로 처리됩니다. 103은 대기열에 남아 Request is ready for import again 상태가 되고, 다음 전체 가져오기 때 다시 들어갑니다. 순서가 101, 102, 103이므로 마지막에 쓰이는 것은 v2입니다.

꺼 두면 103은 Request already imported 상태가 됩니다. 문서는 이 상태의 요청을 다음 전체 가져오기에서 다시 가져오지 않고 대기열에서 지운다고 적습니다. 101과 102만 들어가니, 같은 프로그램에 마지막으로 쓰이는 것은 101의 v1입니다.

SAP 노트

같은 대기열, 체크 하나로 갈리는 마지막 버전

가상 대기열 101(v1) → 102 → 103(v2), 목요일에 103만 단독 가져오기

• 목요일 직후는 같다

  ZDEMO_PRICE_CALC = v2

  • 두 경우 모두 PR1은 v2
  • 101은 아직 대기열에서 대기
  • 프로그램 동작만 보면 차이가 없음

• 옵션 켬

  final: v2

  • 103 상태: Ready for import again
  • 다음 전체 가져오기: 101 → 102 → 103
  • 마지막에 쓰이는 것은 103

• 옵션 끔

  final: v1

  • 103 상태: Already imported
  • 다음 전체 가져오기: 101 → 102
  • 103은 다시 들어가지 않음

문서 규칙을 가상 사례에 적용한 결과이며 실행 결과가 아니다

문서는 이것을 옛 오브젝트가 다음 전체 가져오기에 들어오는 추월 문제(overtaker problem)라고 부릅니다. 7.50 SPS29판에는 같은 대목이 overshooter problem으로 적혀 있어, 찾아볼 때는 두 단어를 모두 넣는 편이 좋습니다. 위의 v1·v2 결론은 문서 규칙을 가상 사례에 적용한 것입니다.

켜 둔 경우에도 v1이 먼저 들어간 뒤 v2가 들어가며, 그 사이에 어떤 버전이 보이는지는 문서에 없습니다. 문서는 가져오는 동안 작업하면 일시적인 문제가 생길 수 있다며 사용자 작업과 필요 없는 백그라운드 잡을 멈추라고 합니다.

기본값은 한 문장으로 정해지지 않는다

이 옵션의 기본값을 문서는 세 곳에서 다르게 설명합니다. 단독 가져오기 페이지는 기본으로 켜져 있다고 적습니다. 옵션 페이지는 Customizing 요청과 전송 가능한 변경 요청에서만 기본으로 켜진다고 적습니다. 전송 전략 페이지는 Mass Transports면 켜짐, Single Transports면 꺼짐이고 Workflow-Controlled Transports의 옵션은 단독 전송과 같다고 적습니다. 7.50 SPS29판도 이 세 문장은 같습니다. 이 글의 사례처럼 Mass Transports 시스템에서 프로그램이 전송 가능한 변경 요청에 든 경우에는 세 문장 모두 켜짐을 가리키고, 문서의 주간 가져오기 예도 켠 채로 둡니다. 그래서 이 경우 꺼진 쪽으로 가려면 누가 끄거나 설정이 달라야 한다고 이 글은 읽으며, 실제 시스템에서 확인한 것은 아닙니다. 그래도 기본값을 짐작하지 말고 가져올 때마다 탭을 열어 보는 편이 낫다는 것이 이 글의 해석입니다.

단독 전송만 받는 시스템에서는 켜 둘 이유가 적습니다. 남겨 둔 요청을 손으로 지워야 하고, Extras의 Delete Imported Requests는 선행 가져오기로 남은 요청을 지우지 않기 때문입니다. 대신 순서를 맞출 책임은 사람에게 옵니다. 문서는 단독으로 가져오는 요청이 같은 오브젝트의 옛 버전이 든 요청을 추월하지 않게 하라고 경고합니다. 이 전략에서 101을 뒤늦게 단독으로 가져오면 옛 버전이 마지막에 쓰이는 것은 같다고 읽힙니다.

켜 두어도 대신해 주지 않는 것

옵션은 다음 전체 가져오기의 순서를 맞춰 줄 뿐, 지금 하는 단독 가져오기를 검사하지 않습니다.

SAP 노트

옵션을 켜도 대신해 주지 않는 것

옵션은 다음 전체 가져오기의 순서를 맞출 뿐이다

• 요청 사이의 의존

  • 데이터 요소가 안 들어온 채 표만 오면
  • 활성화 오류가 난다
  • 단독 가져오기는 이 연결을 챙겨 주지 않음

• 테스트 가져오기

  • 찾는 것: 열린 수리, 대상 쪽 원본
  • 순서 점검이라는 설명은 문서에 없음

• Web UI 가져오기 점검

  • Predecessor·Downgrade 점검
  • 기준: 같은 오브젝트, export 시각
  • Predecessor는 직접 선행만, 미지원 유형 있음

• 대기열에서 지우기

  • 문서: 다음 가져오기에서 불일치 가능
  • 남겨 둔 103을 지우면 옵션의 효과도 사라진다고 읽힘

ABAP Platform 2025 FPS02 문서 기준

• 요청 사이의 의존. 문서의 예처럼 표가 든 요청만 가져왔는데 그 표가 참조하는 데이터 요소가 다른 요청에 남아 있으면 활성화 오류가 납니다. 단독 가져오기에서는 시스템이 이런 연결을 챙겨 주지 않는다고 적혀 있습니다.
• 테스트 가져오기. 문서가 적은 확인 대상은 열린 수리와 대상 시스템의 원본입니다(대화 상자 그림의 3). 순서를 점검한다는 설명은 없습니다. 같은 문서는 품질·운영 시스템에서는 이런 충돌이 생기지 않는다고 적는데, PR1은 운영 시스템입니다.
• Import Queue Web UI의 점검. Predecessor 점검은 선택하지 않은 앞선 요청 가운데 같은 오브젝트가 든 것을, Downgrade 점검은 export 시각이 더 이른 쪽을 옛 버전으로 보고 찾습니다. Predecessor 점검은 직접 선행만 찾고, 두 점검 모두 지원하지 않는 오브젝트가 있습니다. 2025 FPS02판은 요청 50개, 요청당 오브젝트 5,000개 이내로 쓰고, 일반적으로는 SAP Solution Manager의 Downgrade Protection 기능을 대신 고려하라고 하며, 7.50 SPS29판에는 이런 문구가 없습니다. 겹침 기준이 같은 오브젝트이므로, 위의 데이터 요소 같은 의존까지 잡아 준다고 볼 근거는 문서에서 찾지 못했습니다.
• 대기열에서 지우기. 문서는 요청을 지우면 다음 가져오기에서 불일치가 생길 수 있다고 합니다. 남겨 둔 103을 지우면 옵션을 끈 것과 같은 결과가 될 수 있다는 것은 이 글의 해석입니다. Import Transport Request Again을 옛 요청에 쓸 때도 같은 위험이 있다고 읽힙니다(대화 상자 그림의 2).

오류와 재실행은 따로 읽는다

RC 0~4라고 해서 순서가 맞았다는 뜻은 아닙니다. 문서에서 RC 0은 오류 없음, 4는 경고가 있어도 모든 오브젝트 전송, 8은 일부 오브젝트 실패, 12 이상은 치명적 오류입니다. 2025 FPS02판 표에는 0006이 더 있어, 심각한 경고의 예로 overtaker transport를 들고 작업은 수행된다고 적습니다. 7.50 SPS29판과 2023 FPS03판 표에는 이 줄이 없습니다. 확인한 것은 표의 차이뿐이며, 어느 릴리스부터 이 코드가 실제로 나오는지는 확인하지 못했습니다.

RC 8로 끝난 단독 가져오기가 대기열에 어떤 상태로 남는지는 이번에 읽은 문서에 없으니 화면의 상태와 로그로 판단합니다. 트랜스포트 워크플로 전략이면 오류를 고친 뒤 TMS 작업 목록의 Restart Import로 다시 시작합니다. tp 문서에 따르면 조건 없는 모드 1을 주지 않은 재실행은 아직 성공하지 않은 오브젝트만 다시 가져옵니다. 그러니 그냥 다시 돌려서 옛 버전이 고쳐지리라 기대하기는 어렵다고 읽힙니다.

이미 옛 버전이 된 것 같다면

먼저 이력을 봅니다. STMS의 Overview → Imports에서 시스템을 고르고 Goto → History → Import History로 들어갑니다. 기본 구간이 최근 7일이니 필요하면 넓힙니다. 나중에 내보낸 요청이 먼저 들어갔고(그림의 1), 앞선 요청이 그 뒤에 오류 없이, 그림에서는 RC 0으로 들어갔으며(그림의 2), 나중 요청의 다음 기록이 없다면(그림의 3) 추월을 의심할 만합니다. Request → Display → Object List로 같은 오브젝트인지 확인합니다. 요청 번호만으로는 어느 쪽을 나중에 내보냈는지 단정할 수 없습니다.

다음은 오브젝트입니다. 편집 화면의 Utilities → Versions → Version Management에서 다른 시스템과 원격 비교를 할 수 있습니다. 가져올 때 버전을 만드는지는 프로필 파라미터 VERS_AT_IMP에 달려 있으니, 목록에 버전이 없다고 가져오기가 없었다고 읽으면 안 됩니다. 문서는 가져오기로 오브젝트가 바뀌면 버전 개요에 설명(comment)이 붙는다고 적습니다. Import Queue Web UI 이력의 Analysis Mode는 RC 0~4로 끝난 요청에 Downgraded 상태를 표시하므로, 성공과 버전 밀림이 함께 있을 수 있습니다. 상세 화면에는 두 요청의 export 시각도 나옵니다. 다만 CTS_PLUG와 대상 시스템 로컬 로그온이 필요하고, 처음 만들어지는 잡 HISTORY_ANALYSIS_JOB<SID>를 릴리스해야 합니다.

복구에 대해 문서가 가져오기 뒤 발견한 오류에 적는 일반 원칙은 되도록 원본 시스템에서 고쳐 수정본을 전송하는 것입니다. 그 페이지가 추월을 다루는 것은 아니므로, 여기서 이것을 기본으로 삼는 것은 이 글의 해석입니다. 103을 다시 쓰려면, 대기열에 없을 때 Extras → Other Requests → Add로 넣고 Import Transport Request Again을 켜는 길이 있습니다. 이 연결은 페이지들을 이어 읽은 해석이고 복구 절차로 적힌 곳은 없습니다. 문서는 Request already imported 상태의 요청은 고를 수 없다고도 적으니 메시지의 긴 설명을 먼저 읽습니다. 어느 쪽이든 같은 오브젝트가 든 다른 요청이 없는지 이력에서 확인합니다.

단독 가져오기를 누르기 전에는 세 가지만 적어 두면 됩니다. 대기열 앞쪽에 같은 오브젝트가 든 요청이 있는가, Options 탭의 체크가 어떤 상태인가, 다음 전체 가져오기까지 남겨 둔 요청을 아무도 지우지 않는가.