SAP 시스템에는 일반적으로 마스터 데이터, 사용자 데이터 및 트랜잭션 데이터와 같은 다양한 종류의 데이터가 포함됩니다. 각 SAP 시스템은 또한 여러 Client(이하 클라이언트)로 구성되어 있으며, 각 클라이언트는 SAP 시스템 내의 조직 단위를 나타냅니다.
SAP 시스템에서 데이터 구조에 관련하여 다음 용어들은 구별되어야 합니다.
■ Client-specific data
→ 시스템의 특정 클라이언트에 존재하는 데이터
■ Cross-client(Client-independent) data
→ 시스템의 모든 클라이언트에 존재하는 데이터
3.1 Client Overview
각 SAP 시스템은 여러 클라이언트로 분할될 수 있으며, 각 클라이언트는 세 자리 숫자 값으로 식별됩니다. 각 클라이언트에는 고유한 마스터 데이터, 사용자 데이터 및 트랜잭션 데이터가 있습니다. 클라이언트 내 데이터를 client-specific data라고 합니다.
각 SAP 시스템 로그인은 특정 클라이언트를 나타내는 클라이언트 ID를 포함해야 합니다.
3.2 Client-Specific Data and Cross-Client Data
이전에 언급한 대로, SAP 시스템의 데이터는 Client-specific 또는 Cross-client(Client-independent) 데이터로 나뉩니다.
Client-specific data는 해당 데이터가 생성된 클라이언트에서만 볼 수 있으며, Cross-client(Client-independent) data는 전체 클라이언트에서는 접근할 수 있습니다.
SAP 시스템의 데이터는 항상 데이터베이스 테이블에 저장되므로, 데이터는 애플리케이션 테이블에서 클라이언트 컬럼(필드)을 유지함으로써 클라이언트에 제한됩니다. 이러한 테이블은 클라이언트별 테이블이라고 불리며, 클라이언트 컬럼은 MANDT(아래 그림 참조)라고 불립니다. 1번 예시에서 테이블의 클라이언트 필드/컬럼은 데이터를 특정 클라이언트에 제한하고 데이터를 클라이언트에 종속적으로 만듭니다. 2번 예시에서 테이블에서 클라이언트 필드/컬럼이 누락되면 이는 데이터를 전체 클라이언트에서 접근 가능한 상태로 만듭니다.
MANDT 필드는 데이터가 생성된 현재 클라이언트 번호를 저장합니다. 클라이언트별 테이블에서 데이터에 접근할 때, 시스템은 자동으로 사용자의 현재 클라이언트와 테이블의 MANDT 필드를 비교하여 데이터를 현재 클라이언트에 제한합니다.
예를 들어, 클라이언트 100에 로그인한 상태에서 구매 오더를 생성한다고 가정해봅시다. 관련된 구매 도어 어플리케이션 데이터베이스 테이블은 새로운 구매 오더 데이터로 업데이트되며, 이 경우 해당 테이블의 MANDT 필드는 자동으로 클라이언트 번호(100)로 업데이트될 것입니다. 만약 다른 클라이언트인 클라이언트 200에서 해당 구매 오더를 열어보려고 하면, 시스템은 MANDT 필드를 200과 일치시키려고 할 것이므로 클라이언트 100에서 생성된 구매 오를 표시하지 않을 것입니다.
Cross-Client 테이블인 경우, MANDT 필드는 테이블의 키의 일부가 아니기 때문에 데이터가 클라이언트에 제한되지 않습니다. 이러한 데이터는 시스템의 어떤 클라이언트에서든 접근 가능합니다. 테이블의 데이터가 클라이언트에 종속적인지 또는 클라이언트 간 공유되는지 확인하려면, 테이블의 첫 번째 필드로 MANDT가 포함되어 있는지, 그리고 키의 일부로 MANDT가 포함되어 있는지 확인하면 됩니다.
예를 들어, 자재 마스터 테이블인 MARA가 MANDT를 첫 번째 필드로 가지고 있고 테이블 키의 일부인 경우, 이는 MARA 테이블이 클라이언트별로 제한되는 것을 의미합니다. 만약 클라이언트 100에서 새로운 자재를 생성한다면, 해당 재료 데이터는 클라이언트 100에서만 볼 수 있습니다. 다른 클라이언트에서는 이 데이터에 접근할 수 없습니다. 마찬가지로, 특정 클라이언트에서 자재 데이터가 변경되더라도 다른 클라이언트의 데이터에는 영향을 미치지 않습니다. Application 데이터는 일반적으로 Cross-Client Data로 제한되며, 커스터마이징 데이터는 일반적으로 Cross-Client에 공유됩니다.
클라이언트 개념은 SAP 시스템을 여러 클라이언트로 분할하고 데이터를 특정 클라이언트에 제한하거나 클라이언트 간에 공유함으로써 시스템을 분리하는 것을 의미합니다.
SAP 시스템에 로그인할 때는 특정 클라이언트에 로그인하는 것이며, 시스템에서 수행되는 모든 활동은 항상 특정 클라이언트에서 수행됩니다. SAP system landscape를 계획할 때, 다양한 활동을 위해 여러 클라이언트를 생성할 수 있습니다. 예를 들어, 개발을 위한 하나의 클라이언트, 테스트/품질 보증을 위한 하나의 클라이언트, 그리고 운영을 위한 하나의 클라이언트 등을 가질 수 있습니다.
가장 중요한 클라이언트 역할은 다음과 같습니다
■ Customizing and development cliend(CUST)
→ SAP 시스템 소프트웨어는 기업별로 특정 비즈니스 요구에 맞게 수정되는 Standard Business 소프트웨어입니다. SAP 소프트웨어를 사용자 정의하고 다양한 개발 활동을 수행하기 위해 각 SAP 시스템에는 CUST 클라이언트가 있습니다.
■ Quality assurance client(QTST)
→ CUST에서 개발 작업이 완료된 후에는 해당 애플리케이션이 운영서버에서 사용될 수 있도록 하기 위해서는 철저하게 테스트되어야 합니다. 이러한 테스트가 수행되는 클라이언트를 QTST라고 합니다. 일반적으로 QTST 클라이언트는 정기적으로 운영서버 데이터로 반영해줌으로써 더 현실적으로 운영 서버에 가깝 애플리케이션을 테스트할 수 있도록 합니다.
■ Production client (PROD)
→ 실제 비즈니스 활동이 이루어지는 PROD 클라이언트에서는 개발 또는 테스트 활동이 없으며, 원활한 비즈니스 운영을 보장하기 위해 사용됩니다.
이 세 가지 중앙 클라이언트 (CUST, QTST, PROD)는 모든 SAP system landscape에서 존재합니다. 일반적으로 이 세 가지 클라이언트는 별도의 시스템 및 SAP 인스턴스으로서 유지 및 보수 되며, Objects들을 세 클라이언트 간에 이동하기 위한 전송 메커니즘(Transportation Mechanism)이 구현되어 있습니다.
각 시스템은 각 클라이언트 역할에 맞는 하나의 클라이언트를 갖습니다. 개발 시스템은 CUST 클라이언트를 가지고, 품질 시스템은 QTST 클라이언트를 가지고, 그리고 운영 시스템은 PROD 클라이언트를 가지게 됩니다.
예를 들어, ABAP 프로그램은 Cross-client(전체 클라이언트 공유)입니다. 하나의 클라이언트에서 프로그램을 생성하면, 해당 시스템의 모든 클라이언트에서 자동으로 사용 가능하게 됩니다. CUST 클라이언트에서 프로그램을 변경하면, 해당 변경 사항은 QTST 및 PROD 클라이언트에 자동으로 반영됩니다 (모든 클라이언트가 동일한 SAP 인스턴스에 설정된 경우). 모든 클라이언트가 동일한 인스턴스에 설정되어 있는 경우, 프로그램 변경 사항을 테스트할 수 있는 기회가 없습니다.
클라이언트를 별도의 시스템에 유지함으로써, 개발 시스템에서 변경 사항을 수행하고, 품질 시스템으로 전송하여 테스트를 수행한 후, 만족할 경우 이를 운영 시스템으로 가져올 수 있습니다.
다양한 클라이언트 간의 일관성을 유지하기 위해, 모든 Customizing 세팅은 단일 Customizing 클라이언트에서 수행되고 (변경 및 전송 시스템 [CTS]을 통해) 다른 클라이언트로 전송되는 것이 권장됩니다. 이렇게 함으로써 다른 Customizing 세팅 때문에 애플리케이션이 서로 다른 클라이언트에서 다르게 작동하는 상황을 방지할 수 있습니다.
QTST 및 PROD 클라이언트에서는 Customizing 설정 또는Workbench Devlopment를 수행하지 않는 것이 권장됩니다. Transaction SCC4를 사용하여 QTST 및 PROD 클라이언트에서의 개발 활동을 방지하기 위한 적절한 클라이언트 설정을 함으로써, 개발 활동은 항상 CUST 클라이언트에서 수행되고 테스트를 위해 다른 클라이언트로 전송, 테스트가 끝난 후에는 운영 환경에서 최종 사용자에게 제공됩니다.
