ABAP 프로그램은 Application Layer에서 실행되고, 모든 프로그램의 실행은 Application Server에서 이뤄집니다. Application Layer은 하나 혹은 그 이상의 Application Server와 Message Server를 포함합니다. Message Server은 Application Servers 간의 의사소통을 책임집니다. Application Server은 ABAP 코드를 실행할 수 있는 런타임 환경을 제공하며 ABAP 프로그램을 해석합니다.
SAP Netweaver는 Application Server로써, ABAP과 JAVA 프로그램들을 위한 런타임 환경을 제공합니다. SAP Netweaver는 Pure ABAP System으로, Pure JAVA System, 혹은 둘 다를 위해서 설치될 수 있습니다.
■ Pure ABAP System
Pure ABAP System은 ABAP 기반의 어플리케이션을 개발, 실행하는 것을 지원하지만, Java 기반의 어플리케이션들의 실행을 지원하는 것에는 제한이 있습니다.
■ Pure JAVA System
Pure JAVA System은 JAVA 플랫폼과 JAVA Enterprise Edition(JAVA EE) 어플리케이션을 지원합니다. Java EE 어플리케이션을 개발하고 실행하기 위한 전체 인프라 지원을 제공하지만 ABAP 기반의 어플리케이션을 지원하지는 않습니다.
■ Dual-Stack System
Dual-Stack System은 ABAP 기반과 JAVA EE 기반의 어플리케이션 둘 다를 지원합니다.
ABAP 컨설턴트들은 Application Server의 설치나 유지보수와 직접적으로 관련되지 않습니다. 이는 Basis 컨설턴트의 역할입니다. 그러나 ABAP 프로그램이 Application Server에서 실행되기 때문에, Application Server의 다양한 구성 요소(및 역할)를 알면 ABAP 프로그램이 실행될 때 발생하는 백엔드 프로세스를 이해하는 데 도움이 됩니다.
Application Layer의 모든 구성 요소를 논의하는 것은 다루기엔 양이 너무 많습니다. 따라서 Application Layer를 구성하는 중요한 몇 가지 구성 요소에 대해서만 논의할 것입니다.
SAP 시스템의 다양한 구성 요소는 모두 instances라고 합니다. 이러한 Instance는 사용자들의 요청을 처리하며, Application Server Instance의 수는 얼마든지 늘릴 수 있습니다.
주요한 Application Server Instance의 구성요소는 아래와 같습니다.
■ ICM
■ ABAP Dispatcher
■ SAP Web Dispatcher
■ SAP Gateway
■ SAP start service
■ Work processes
각 Application Server Instance는 많은 Work processes들을 가질 수 있지만, 하나 이상의 ICM, Dispacter, Gateway, SAP Start Service를 가질 수 는 없습니다.
여러 Application Server Instance와 함께, ABAP 시스템 중요한 하나인 ABAP Systme Central Services (ASCS) Instance가 있습니다. ASCS Instance에는 Message Server, enqueue server 및 separate start service가 포함됩니다. ASCS Instance는 locks 관리, exchanging messages, and load balancing을 처리합니다.
Message Server는 Load balanceing과 다양한 Instance들 간의 의사소통을 담방하고, enqueue server는 Application Locks를 관리합니다. Application Locks은 동시에 같은 데이터를 복수의 유저가 다루지 못하게 해줍니다.
ICM : Internet Communication Manager
ICM은 Application Server가 ICM은 HTTP, HTTPS 또는 SMTP와 같은 웹 프로토콜을 사용하여 외부 세계와 통신할 수 있도록 합니다. ICM은 응용 프로그램 서버를 웹을 활성화시키며, 사용자가 SAP GUI 대신 웹 브라우저를 사용하여 응Application Server에 요청을 보낼 수 있도록합니다.
ICM은 ABAP Dispatcher에 의해 시작되고 모니터링되는 별도의 프로세스들로 실행됩니다. ICM을 사용하면 Application Server 서버는 Web Dynpro 기반 Application과 같은 인터넷에서의 요청을 처리할 수 있습니다.
ABAP Dispatcher
각 Application Server에는 Dispatcher가 있습니다. 사용자의 요청은 Work Process를 통해 처리됩니다. Dispatcher의 역할은 요청을 Work Process에 할당하는 것입니다.
사용자는 요청을 보내고, 요청은 Dispatcher에게 전송되며, 디스패처는 요청을 사용 가능한 Work Process에 할당합니다.
요청이 Work Process에 할당되고 나면, Work Process는 요청을 실행하고 결과를 되돌려줍니다. Work Process는 결과를 전달하고 나면 자유로워지고, 다른 요청을 작업할 준비를 합니다.
유저가 SAP에 로그인하고 나면, 로그인 요청이 Message Server로 전달되고나면 Message Server는 Load Balancing을 수행하고 사용자의 로그인 요청을 부하가 가장 적은 인스턴스의 Dispatcher에 연결합니다. 연결되면 해당 인스턴스의 Dispatcher가 사용자의 모든 요청을 처리합니다.
Work Process
유저의 요청을 Work Process를 통해 작업되고, 다수의 Work Process는 Application Server Instance 마다 존재할 수 있습니다.
위 그림을 보면, 유저가 요청을 보냈을 때, 요청은 ABAP Dispatcher로 전달됩니다. ABAP Dispatcher는 요청을 작업 가능한 Work Process로 요청에 대한 처리를 위해 할당합니다. Work Process가 요청을 처리하고 난 뒤에, 결과를 전달하고, Work Process는 다시 자유로워지고 새로운 요청을 수행합니다.
Work Prccess는 어떤 사용자 세션 전용이 아니라, 어떤 사용자로부터의 요청도 처리할 수 있습니다. 위 그림에서, User1이 레포트를 실행했다고 했을 때, 이 요청은 Work Process 1에 ABAP Dispatcher에 의해 할당됩니다. Work Process 1은 요청을 처리하고 그 결과를 User 1에게 되돌려줍니다.
이러한 관점에서, 만약 User 2가 요청을 했을 때, ABAP Dispatcher는 해당 요청을 다시 Work Process 1으로 할당할 수 있습니다. 만약 User 1이 새로운 요청을 만들었는데, Work Process 1이 User 2의 요청을 처리하고 있는 중이라면, ABAP Dispatcher는 User1의 요청을 지금 작업할 준비가 되어있는 Work Process 2에 할당할 것입니다. 만약 User 1 또는 User 2가 Work Process 1과 Work Process 2가 모두 사용 중일 때 새로운 요청을 한다면, ABAP Dispatcher는 다음 사용 가능한 Work Process에게 이 작업을 할당합니다.
위 그림은 T-CODE SM50(Work Process Overview)의 예시이며, 해당 T-CODE를 어떻게 Work Process 상태들이 바뀌는지 볼 수 있습니다. 만약 어떠한 프로그램을 실행하고 SM50을 실행해본다면, 요청이 Dialog Work Process(DIA)를 통해 처리되고 있고 상태는 Running인 것을 확인할 수 있을 것입니다. 현재 자유롭고 작업할 준비가 되있는 Work Process의 상태는 Waiting입니다.
위에서 볼 수 있듯이, 다른 종류의 요청을 처리하는 다른 유형의 Work Process가 아래 표에 정리되어 있습니다.
| Work Process Type | Purpose |
| DIA(Dialog) | 유저가 Screen 을 통해 만든 요청인 Dialog Request를 다루는 유형 |
| UPD/UPD2(Update) | Database에 높은 우선순위와 낮은 우선순위의 Updates 유형을 다루는 유형 |
| BTC(Background Processing) | Background Job을 다루는 유형 |
| SPO(Spool) | Spool 요청을 다루는 유형 |
Basis 관리자는 트랜잭션 RZ10을 사용하여 각 유형별 Work Process의 수를 구성할 수 있습니다.
Gateway
Gateway readers는 TPC/IP에 기반을 둔 Remote Function Calls(RFCs)을 사용한 되부 시스템과의 의사소통을 가능하게 해줍니다. RFC Services는 SAP 시스템과 외부 Application 간의 의사소통을 가능하게 해줍니다.
RFC(Remote Function Call)는 ABAP 프로그램 내에서 만들어질 수도 있고, 외부 프로그램과의 인터페이스를 사용하여(RFC-활성화된 함수 모듈) 만들어질 수도 있습니다. 시스템 간에 RFC를 사용하는 것 외에도, 게이트웨이는 인스턴스의 프로세스 간에도 사용될 수 있습니다.
Start Service
Start Service는 SAP System Instance를 시작하는 데 사용됩니다. Windows에서는 서비스(Service)로 구현되고 Unix에서는 데몬(Daemon)으로 구현됩니다. Start Service는 Instance를 시작하고 중지하며, 런타임 상태를 모니터링하고 로그를 읽는 데 도움을 줍니다. 또한 스Start Service는 활성 세션이나 네트워크 포트와 같은 기술적 정보를 제공합니다.
Message Server
하나의 SAP 시스템에는 하나의 Message Server만 존재할 수 있습니다. Message Server는 서로 다른 application server instances간의 통신을 지원합니다. Message Server은 또한 Load Balancing(부하 분산)을 다룹니다. 앞서 다루었다싶이, 사용자가 SAP 시스템에 로그인하면, Message Server는 최소한의 부하를 가진 application server instance에 사용자를 연결합니다.
Message Server는 SAP GUI 및 RFC Connection의 Load Balancing(부하 분산)을 처리하며, 웹 환경의 부Load Balancing(부하 분산)은 SAP Web Dispatcher에서 처리됩니다.
SAP Web Dispatcher
SAP Web Dispatcher은 유용한 Web 환경입니다. SAP Web Dispatcher은 Internet과 SAP System 사이에 존재하며 모든 HTTP(S) 요청이 SAP Web Dispatcher를 통해 라우팅됩니다. 여러 SAP 시스템 앞에 배치하고, 특정 요청을 특정 시스템으로 라우팅하도록 구성하여 더 나은 Load Balancing을 위해 사용할 수 있습니다. SAP Web Dispatcher는 연결을 수락하거나 거부하여 더 나은 보안을 제공하도록 구성할 수 있습니다.
SAP Web Dispatcher는 특정 URL을 거부하여 URL 필터링을 통해 시스템에 대한 제한된 액세스를 허용할 수 있습니다. 또한 응용 프로그램 응답 시간을 개선하기 위해 웹 캐시로 사용할 수 있습니다.
Enqueue Server
Enqueue Server는 Lock(잠금)을 관리하며, SAP NetWeaver Application Server for ABAP에 속하지 않은 별도의 서버로 설치될 수도 있고, 클래식 ABAP Central Instance의 일부로 구성될 수도 있습니다. Enqueue 기능은 동시에 여러 사용자가 같은 데이터를 업데이트(예: 편집)하는 것을 방지하는 Logical Locking Functionality을 제공합니다. 예를 들어, 한 사용자가 문서를 편집하도록 변경 모드에 진입할 때, enqueue 기능은 다른 사용자가 동일한 문서를 변경 모드에 진입하는 것을 방지할 수 있습니다.
User Context
User Context는 사용자에 대한 Context 정보가 저장되는 곳입니다. 사용자가 요청을 하면 work process는 사용자 Context 영역에서 사용자에 대한 정보를 활용합니다. User Context Area은 사용자의 개인 설정, 권한, 날짜 및 통화 형식과 같은 정보를 저장합니다. work process는 이 정보를 각 사용자 요청에 적용합니다.
각 사용자마다, User Context는 사용자가 시스템에 로그인할 때마다 Application Server에 한 번 로드되고, 사용자가 시스템에서 로그아웃하면 삭제됩니다. User Context의 데이터는 해당 사용자의 다음 로그인까지 업데이트되지 않습니다.
위 그림을 보면, 유저로부터 요청이 처리되 전에는 work process는 사용자 컨텍스트에 맞추어 진행되며, 요청에 적용한 후에는 User Context를 종료합니다. 이는 work process가 모든 사용자로부터의 요청을 처리하고 각 요청에 User-specific context를 적용할 수 있도록 합니다.
'ABAP 프로그래밍 개념 > Architecture of SAP System' 카테고리의 다른 글
| 3-1. Data Structures : Client (0) | 2023.04.17 |
|---|---|
| 2-3. SAP Implementation Overview : Database Server/Relational Database Management System: Database Layer (0) | 2023.04.17 |
| 2-1. SAP Implementation Overview : SAP GUI: Presentation Layer (0) | 2023.04.17 |
| 2. SAP Implementation Overview (0) | 2023.04.17 |
| 1. Introduction to the Three-Tier Architecture (0) | 2023.04.17 |
