SAP 에는 매우 정규화되고, 철저한 배포/형상관리 프로세스가 존재하며, BC Role 에서 개발/품질/운영의 배포와 형상을 관리하는 일은 매우 중요하다.
이러한 배포/형상관리는 CTS (Change and Transport System) 를 통해서 이루어지며, 이러한 CTS 를 관리하는 역할은 BC 가 담당한다.
여기서는 SAP CTS 배포/형상관리에 필요한 기본 지식과 흐름에 대해서 정리한다.
0. CTS 관련 기본 용어 정리
0-1. CTS (Change and Transport System)
ABAP Workbench에서 개발 프로젝트를 구성하고 사용자 정의한 다음 시스템 환경에서 SAP 시스템 간에 변경 사항을 전송하는 데 도움이 되는 도구
개발 시스템에서 변경사항이 생기면 CTS Request 를 생성해야 하며(이를 CTS 를 딴다고 한다), 변경 사항은 CTS 를 통해서 다른 시스템에 반영할 수 있다.
위의 설명과 같이 CTS 는 배포/형상관리의 Tool 이지만, 현업에서는 변경 사항을 기록하는 CTS Request 를 통칭해서 쓰인다.
따라서, CTS 를 딴다, 생성한다라는 표현은 CTS Request 를 새로 만들어 변경사항을 담는다 라고 이해하면된다.
0-2. TMS (Transport Management System)
TMS(전송 관리 시스템) 를 사용하여 SAP 시스템 간의 전송을 구성, 수행 및 모니터링
0-3. tp
Transport Control Program 으로 SAP Kernel 단에 존재하는 운송 제어 프로그램이다.
tp 는 SAP 시스템간의 전송을 제어하고, SAP Release 를 업그레이드 하기위한 유틸리티이다.
또한, tp 는 일반적으로 다른 운송 관련 프로그램(CTS, TMS, R3up) 에서 호출되기 때문에 직접 사용할 필요는 없다.
0-4. R3trans
R/3 전송 프로그램인 R3trans는 R/3 시스템 간에 데이터를 전송하고 서로 다른 SAP 릴리스 간 마이그레이션에 사용된다.
R3trans 역시 일반적으로 다른 프로그램에서 호출되어 사용되며, 사용자가 직접 사용할 필요는 없지만, 특수한 경우에 사용자가 R3trans 를 직접 호출하여 사용할 수 있다.
0-5. Landscape
여기에서 Landscape 는 TMS 내 시스템들의 구성도로 이해하면 된다.
SAP 에서는 Three-System Landscape 을 권장하며, 개발-품질-운영으로 구성된다.
소규모 시스템 또는 샌드박스 구조일 경우, Two-System Landscape 을 사용하기도 하며, 개발-운영으로 구성된다.
0-6. Domain 및 Domain Controller
TMS 관리의 대상이 되는 모든 SAP 시스템의 그룹을 Transport Domain 이라 한다.
Domain 내에서 설정의 기준이 되는 시스템을 Transport Domain Controller 라 하며, TMS 에 대한 설정 변경은 도메인 컨트롤러에서만 가능하며, 이로인해 해당 도메인 내 시스템들에게 일관성이 보장된다.
SAP 권장은 운영 000 클라이언트이나, 보통 개발 000 클라이언트로 많이 설정한다.
(기본은 000 클라이언트이나, 신규 S4HANA 버전부터는 클라이언트 구분이 사라진듯 하다.)
0-7. Transport Group
Transport Domain 내에서 공통 전송 디렉토리(/usr/sap/trans) 를 공유하는 시스템을 전송 그룹이라 한다.
0-8. Transport Route
전송 그룹내 각 시스템들이 연결되어있는 경로
0-9. TMSADM
전송 관리에 사용되는 어드민 계정으로 TMS 가 처음 구성될때 클라이언트 000 에 생성된다.
이후 도메인 컨트롤러를 구성할때, 암호를 설정할 수 있으며, 해당 암호는 해당 전체 도메인에 대해서 유효하다.
TMSADM 을 통해서 Transport 전용 백엔드 RFC (TMSADM@, TMSSUP@) 가 생성되고 CTS 가 전송된다.
1. TMS 시스템 등록 및 Domain, Domain Controller
기본적으로 처음 SAP 를 설치하게 되면, TMS 구성 및 전송 경로를 구성해줘야 한다.
테스트용 시스템이나 샌드박스 시스템일 경우라면, TMS 구성을 안해줘도 상관없지만, 이럴 경우, 변경 사항을 CTS 를 통해 다른 시스템에 전송할 수 없다.
여러 시스템 중에 전송 도메인이 될 시스템의 클라이언트 000 에 접속하여 Tcode STMS 를 들어가면, 현재 시스템을 Transport Domain Controller 로 등록할 수 있다.
정보 입력 후, 전송 도메인을 저장하면, TMS 는 TMSADM 계정을 새로 생성하고, 패스워드를 지정하면 전송 도메인 컨트롤러의 구성이 완료된다.
이후, 전송 도메인 시스템과 같은 공통 전송 디렉토리(/usr/sap/trans) 를 사용하는 시스템을 포함시키기 위해서는, 똑같이 클라이언트 000 에서 Tcode STMS 를 들어가면, SAP 에서 자동으로 해당 전송 도메인에 포함하도록 권유하는 제안하게 된다.
이렇게 같은 전송 도메인 안의 시스템은 같은 Group 안에 있으며, 전송 전략, 설정, 경로 등을 공유한다.
SAP 에서는 전송 도메인 컨트롤러의 중요성 때문에, 운영 시스템을 전송 도메인 컨트롤러로 사용하도록 권장한다.
- SAP Notes 3462718 - SAP system chosen to be the domain controller
1-1. TMS RFC
SAP 시스템 간의 통신은 TMS 가 구성될 때, 생성되는 RFC 연결을 사용하여 구현된다.
해당 RFC 는 TMSADM 계정으로 생성되고 사용한다.
1-1-1. 읽기 엑세스 연결 - TMSADM@
TMSADM@<SID>.<Transport Domain Name>
해당 RFC 는 TMS 와 관련된 모든 읽기 엑세스에 사용된다.
TMSADM@ RFC 연결을 통해 도메인 내의 모든 SAP 시스템의 Import Queue 를 표시할 수 있다.
1-1-2. 변경 엑세스 연결 - TMSSUP@
TMSSUP@<SID>.<Transport Domain Name>
해당 RFC 는 CTS 를 통한 변경 작업을 수행하는데 사용된다.
만약 TMSADM 계정의 패스워드가 바뀌거나, TMSADM 계정의 권한이 부족하다면, 로그온 화면을 띄어, 충분한 권한이 있는 계정으로 로그인하도록 한다.
그러나, 보통 TMSADM 계정을 별도로 수정할 일이 없기에 이러한 이슈에 대해 참고만 하면 된다.
2. Transport Routes
Transport Routes 는 CTS 가 전송되는 경로이다.
SAP 가 권장하는 가장 기본적인 구성인 Three-System Landscape 의 경우, 개발 -> 품질 -> 운영으로 이루어지며, 정책 및 환경에 따라 약간의 구성 차이가 있을 수 있다.
SAP 표준 구성의 Three System in Group 경우, 개발/품질/운영 시스템을 입력하면, 자동으로 다음과 같이 전송 경로가 구성된다.
여러 클라이언트별로 CTS 를 전송, 관리하고 싶다면, Transport System 에서 Extended Transport Tool(확장 전송 제어) 과 전송 프로파일에서 파라미터 CTC 를 활성화하면, Transport Target Group 을 사용하여 클라이언트 간의 전송이 가능해진다.
소규모 시스템에서 사용하는 Two-System Landscape 의 경우, 개발 -> 운영 구성으로 이루어진다.
이 구성의 경우, 보통 개발에 별도의 클라이언트를 생성하여 품질처럼 활용한다.
(예를들어 개발시스템 900번은 개발/ 800번은 품질)
샌드박스 시스템과 같이 전송대상이 별도로 없는 시스템의 경우에는 가상 시스템(Virtual System) 을 생성하여, 위에서와 같은 Two-System Landscape 경로를 사용하기도 한다.
만약 TMS 구성 없이 사용한다면, CTS 가 따지지 않게되며, 변경 사항에 대한 기록이 불가능해진다.
3. CTS Release
SAP 개발시스템에서 변경사항이 있을때 CTS Request 생성하여 기록한다.
(또는 이미 생성한 CTS Request 가 있다면, 해당 Request 에 Task 형태로 추가할 수 있다)
변경사항에 대한 모든 기록(변경, 생성, 삭제 등등) 은 CTS Request 에 기록되며, 다른 시스템에 배포할 준비가 되었을때 CTS Request 를 Release 를 하여 CTS 내 모든 오브젝트를 프리징한다.
CTS Release 를 했을때, CTS 내 오브젝트 들에 대해서 정합성 점검을 하며, 모든 오브젝트가 Active(활성화) 상태일때 Release 가 가능하다.
한번 Release 된 CTS 는 이전 상태로 바꿀 수 없기에 Release 전에 CTS 오브젝트들을 점검해야한다.
프로그램 RDDIT076 를 사용하여 Release Rollback 을 할 수 있긴하다. (권장하지는 않음)
프로그램 RDDIT076 실행 후, Rollback 할 CTS 번호를 입력하고 실행하면, 해당 CTS 의 Request 와 Task 가 전부 출력된다.
여기서 모든 Request 와 Task 를 더블 클릭하여, 수정모드로 변경하여 Status(상태) 값을 R -> D 로 변경해주면 된다.
CTS Release 가 완료되면, OS /usr/sap/trans 경로의 Cofiles, Data 디렉토리에 해당 CTS 의 파일이 물리적으로 생기게 되며, Release 한 시점으로 프리징이 된다.
CTS : <SID>K9<CTS Number>
Cofiles : K9<CTS Number>.<SID>
Data : R9<CTS Number>.<SID>
또한, 설정된 전송 경로에 따라 다음 전송 시스템(보통 품질시스템)의 Import Queue 에 해당 CTS 가 자동적으로 추가된다.
CTS 를 Release 하기 전에는, 아직 오브젝트가 프리징된게 아니기 때문에, 중복 변경을 막기위해 해당 오브젝트는 Lock 이 걸리게 된다.
이렇게 되면, 해당 오브젝트가 Release 되어 프리징되기 전까지는 다른 개발자가 Lock 오브젝트를 변경할 수 없다.
4. CTS Import and Import Option
CTS 배포(반영) 는 Tcode STMS 에서 이뤄진다.
배포 시스템의 Import Queue 로 접속하여, 반영할 CTS 를 선택하여 배포할 수 있다.
Import Queue 의 리스트는 수동으로 재구성을 해줘야 하며, 단축키 F5 로 Queue 를 재구성 할 수 있다.
CTS Import 시, 여러 옵션이 선택가능하다.
4-1. Import Option - Excution
전송 제어 프로그램 tp 가 시작하는 방법을 지정 가능하다.
◾ Synchronous
tp 가 CTS Import 를 완전히 종료될때까지 Dialog, Background 프로세스를 차단한다.
프로세스들은 Import 가 완전히 종료될때까지 대기하다가 Import 가 종료되면 수행된다.
◾ Asynchronous
tp 가 CTS Import 가 시작되어도, 따로 프로세스를 차단하지 않는다.
해당 옵션은 Import 요청이 많거나, Import 가 오래 걸리는 경우에 유용하다.
4-2. Import Option - Options
-
Leave Transport Request in Queue for Later Import
=> 대상 CTS 를 나중에 다시 Import 하기 위해서 Queue 에 남겨두는 옵션 -
Import Transport Request Again
=> 대상 CTS 가 완전히 Import 되었어도, 다시 Import 를 한다. -
Overwrite Originals
=> 대상 CTS 는 오브젝트의 원본을 덮어쓰는 Import 를 한다. -
Overwrite Objects in Unconfirmed Repairs
=> 대상 CTS 의 오브젝트가 확인되지 않은 Repair 일 경우에도 Import 를 한다. -
Ignore Non-Permitted Transport Type
=> 대상 CTS 가 Transport Pofile 설정에 따라 제외된 유형(Type) 이어도 Import 를 한다. -
Ignore Non-Permitted Table Class
=> 대상 CTS 의 Table (Delivery) Class 가 데이터 레코드 Import 를 허용하지 않아도, Import 를 한다. -
Ignore Predecessor Relationships
=> 대상 CTS 가 Import 되기 전, 프로젝트끼리의 선행(종속) 관계를 무시하고 Import 를 한다. 단, 선행 관계가 손상되는 경우에는 Import 되지 않는다.
특수한 상황을 제외하고는 해당 옵션을 사용하는 것을 권장하지 않는다. 해당 옵션으로 Import 를 완료하더라도 종속 관계가 깨져 연쇄적으로 오류가 발생할 수 있기 때문이다. -
Ignore Non-Matching Component Versions
=> 대상 CTS 의 Component Version 이 시스템의 현재 Component Version 과 일치하지 않더라도 Import 한다. 단, CTS 내 오브젝트들이 Component Version 과 독립적이라고 확신하는 경우에만 사용해야 한다.
해당 옵션도 특수한 상황을 제외하고는 권장하지 않는다.
종합적으로 일반적인 상황에서는 Import 옵션을 따로 지정할 필요는 없으며, Import 오류가 발생한 상황에서는 위에서 4개까지의 옵션으로 재 Import 하는 것을 고려해볼 수 있다.
상황에 따라서 아래 4개의 옵션까지도 고려할 수 있지만, 이 경우 Import 가 완료된다 하더라도 다른 문제가 발생할 가능성이 크기 때문에 충분한 검토 후에 옵션을 사용하여야 한다.
5. CTS Import Monitor
Tcode : SE07
보통 CTS 의 반영 상태나 진행 여부는 CTS Import Queue 에서 리프레시(F5) 를 통해서도 확인가능하나, CTS Import Monitor 를 통해서 보다 세부적인 모니터링이 가능하다.
Import Monitor 는 대상 시스템에서의 Import 상태를 보여주며, 크게 계획 일정 / 실행 Section 으로 나눠진다.
현재 Import 중인 CTS 는 실행 Section 에서 확인할 수 있다.
여기서 Import CTS 의 옵션과 Target Client, Return Code 를 확인할 수 있으며, 각 전송 요청에 대해서 우클릭을 하여 다음과 같은 세부 정보를 볼 수 있다.
- Delete Entry
- Import Details
- Display Corresponding Transport Step
- Import History
6. CTS Import Queue / Buffer
각 Transport System 은 고유의 Import Queue 를 가지고 있다.
Import Queue 는 OS 상에 파일로 존재하며, 해당 위치는 다음과 같다.
/usr/sap/trans/buffer/<SID>
Import Queue 는 CTS 가 쌓일 수록 엔트리가 점점 많아지고, 파일의 크기가 커지게 되는데, 이로 인해 Queue 의 새로고침(Refresh) 시간이 점점 길어지기 때문에, 주기적으로 정리를 해줘야 한다.
Import Queue 를 정리하는 방법은 다음 Post 를 참조하기 바란다.
7. CTS Cofiles / Data
3. CTS Release 에서 CTS Release 시, OS trans 디렉토리에 물리적인 파일이 생긴다고 설명했었다.
Cofiles 와 Data 두 파일이 생기게 되며, 각 파일의 역할은 다음과 같다.
Cofile : CTS 의 헤더파일이며 전송 유형, 개체 클래스, 필요한 임포트 단계 및 사후 처리 종료 코드에 대한 정보를 포함하는 명령을 가지고 있다. Cofile 은 K 로 시작한다.
Data : CTS 의 바디파일이며, 해당 전송요청에 대한 실질적인 데이터 파일이다. Data 는 R 로 시작한다.
따라서, Cofile 과 Data 는 CTS 의 물리적 실체이며, 두 파일이 있다면, 다른 시스템에도 Import 가 가능하다.
8. R3trans
전송 프로그램 중 하나인 R3trans 는 초반 설명과 같이 R/3 시스템간의 데이터 전송 또는 시스템 마이그레이션 간에 사용된다.
그러나 R3trans 에는 특수한 다른 사용법으로도 많이 사용된다.
여기서 대표적인 두가지 사용 방법에 대해서 소개한다.
8-1. DB <-> AP 연결 체크
보통 DB 접속/연결에 문제가 생긴것을 가장 쉽게 확인할 수 있는 방법으로 AP 서버에서 R3trans 명령어를 사용한다.
R3trans -d또는R3trans -x
RC = 0 일 경우가 정상이며, RC = 8, 12 라면 문제가 있어 연결이 안되는 경우이다.
R3trans 명령어를 실행한 디렉토리에는 로그로 trans.log 가 생성되며, 해당 로그를 확인함으로써 문제점을 확인할 수 있다.
8-2. 데이터 마이그레이션
R3trans 명령어를 사용하면 SAP 시스템간끼리의 데이터 전송이 가능하다.
이 경우, SAP 프로그램을 이용한 전송이기에 시스템의 OS, DB 버전과 관계 없이 데이터를 전송할 수 있다.
9. Import Logs
CTS 에 관한 Import Log 는 /usr/sap/trans/log 디렉토리에서 확인할 수 있다.
여기서 확인할 수 있는 Log 는 ALOG, SLOG, ULOG 와 함께 각 CTS 별 Import Log 를 확인할 수 있다.
9-1. ALOG
기본 형태 : ALOG$(syear)$(yweek).$(system)
ALOG 는 전송 디렉토리에서 수행된 모든 전송단계에 대한 개별 Return Code(RC) 가 포함되어있다.
ALOG 는 다음 구조로 항목이 표시된다.
- 변경 요청 (CTS 번호)
- SAP 시스템 이름 =>
<SID>,<SID>.<CLI>,<SID>:<CLI>등의 형식으로 표기 - 배포 단계 구분자 (Transport Action)
- Return Code
- YYYYMMDDHHmmss 형식의 타임스탬프
- CTS 소유자
- tp 를 호출한 OS 사용자 => 일반적으로
<SID>adm계정 (생략되기도 한다.) - tp 가 실행된 서버의 Hostname
9-2. SLOG
기본 형태 : SLOG$(syear)$(yweek).$(system)
SLOG 는 SAP 시스템에서 실행되는 모든 Import 에 대한 전반적인 정보를 제공하며, 각 CTS 단계에 따른 시간별 Import 수행과 함께 Return Code(RC) 가 표시된다.
SLOG 는 다음 구조로 항목이 표시된다.
- Line Type => START, STOP, ERROR, WARN, INFO, LIST, HALT 등등
- 변경 요청 (CTS 번호)
- SID
- 배포 단계 구분자 (Transport Action)
- Return Code
- YYYYMMDDHHmmss 형식의 타임스탬프
- CTS 소유자
- tp 를 호출한 OS 사용자 => 일반적으로
<SID>adm계정 (생략되기도 한다.) - tp 가 실행된 서버의 Hostname
9-3. ULOG
기본 형태 : ULOG$(syear)_$(quarter)
ULOG 는 전송, 패치 등의 tp 호출과 관련된 모든 명령을 매개변수와 함께 표시한다.
9-4. 각 CTS 별 운송 단계 로그
기본 형태 : <SID><Transport Action><6 digits>.<Tartget System>
예시)
CTS 번호 : DEVK900010 / QAS Import
=>DEV<Transport Action>900010.QAS
Transport Action 은 종류에 따라 다음 값을 가진다.
| Action | Desc |
|---|---|
| A | Activate dictionary |
| D | Import application-defined objects |
| E | R3trans export |
| G | Create programs and screens |
| H | R3trans dictionary import |
| I | Main R3trans import |
| L | R3trans import of the command file |
| M | Activate the enqueue modules |
| P | Test Import |
| R | Execute XPRA programs after PUT (XPRA) |
| T | R3trans import of table entries |
| V | Set the version flag |
| X | Export application-defined objects |
10. tp 와 ABAP 간의 통신
ABAP 에서 구현되는 전송(Import) 단계는 ABAP Dict. 객체 확성화, 구조 변환, 보고서 및 화면 생성 등등 매우 복잡한 단계를 거친다.
이러한 단계를 시작하려면, SAP ABAP 시스템에 최소 두개의 Background Workprocess 가 필요하며, 배치잡 RDDIMPDP (Import Dispathcer) 이 예약되어 있어야 한다.
배치잡 RDDIMPDP 은 수동으로 등록할 필요없이 RDDNEWPP 또는 RDDNEWPP2 프로그램을 실행함으로써 시스템으로 자동으로 배치잡 예약이 된다.
tp 에서 SAP 시스템에 전송 단계 시작을 전달하면, SAP 시스템의 RDDIMPDP 배치잡은 먼저 TRBAT 테이블을 확인하여 수행할 작업이 있는지 확인한다.
확인 후, 작업이 있다면 전송에 필요한 작업을 백그라운드로 시작하고, 다음 수행을 예약한다.
Import 중이 아니라면, TRBAT 테이블은 항상 비어있어야 한다.
만약 TRBAT 테이블에 엔트리가 있다면, Import 가 되지않고 Hang 또는 대기 중인 상태로, RDDIMPDP 배치잡과 tp 를 확인해봐야 한다.
이 후, 배치잡 RDDIMPDP 은 TRJOB 테이블을 확인하여, Import 종료를 인식한다.
이렇듯, tp 는 테이블 TRBAT, TRJOB 을 통해서 ABAP 전송 프로그램과 통신한다.
간혹, 품질 시스템 재구성 후, 기존 배치잡을 삭제하는 과정에서, RDDIMPDP 배치잡이 같이 삭제되는 경우가 있다.
이 경우, RDDIMPDP 배치잡이 없으면, CTS Import 가 수행되지 않기 때문에, RDDNEWPP 또는 RDDNEWPP2 프로그램을 실행하여 RDDIMPDP 배치잡을 다시 예약해줘야 한다.
000 클라이언트에서 DDIC 계정으로 수행하면 된다.
(SAP 에서는 DDIC 계정으로 수행하는걸 권장하진 않는다.)
11. CTS+
CTS+ 에 대해서도 간단하게나마 알고 있으면 좋다.
Enhanced Change and Transport System 이라고 불리는 CTS+ 는 ABAP 이 아닌 오브젝트를 전송하는데 사용된다.
SAP NW 7.0 SPS12 부터 제공되며, Non-ABAP 시스템(As JAVA 또는 HANA) 에서 오브젝트를 전송할때 사용된다.
SAP HANA for ABAP 일 경우, HTA(HANA Transport for ABAP) 기능으로 CTS+ 대체할 수도 있다.
- SAP Notes 1990798 - SAP HANA Transport for ABAP (HTA): Release Information
◾ Configure CTS+ for SAP PO system. SolMan 7.2 as a domain. Step by step guide
◾ CTS+ Configuration for Process Orchestration (PI/PO) and AEX 7.31 (JAVA Only Stack)
