SAP R/3 Archi강의
제시카 블레이크
⚡ 스마트 요약
SAP R/3 Archi이 구조는 프레젠테이션, 애플리케이션 및 데이터베이스 책임을 분리하는 3계층 클라이언트-서버 설계입니다. 이 문서에서는 각 계층과 ABAP 및 Java 구성 요소 스택, 디스패처 기반 로그인 프로세스 및 그 이유 SAP 이 계층형 모델을 선택했습니다.
SAP R/3 Archi건축 양식은 거의 모든 고전 작품의 근간을 이룬다. SAP ERP 구축. 아래 섹션에서는 세 가지 계층이 어떻게 상호 작용하는지, 그리고 ABAP 및 Java 스택은 디스패처, 메시지 서버 및 데이터베이스 간에 작업을 분할합니다.
SAP R/3?
SAP R/3는 클라이언트-서버 기반의 엔터프라이즈 시스템입니다. 3계층 아키텍처 세 개의 독립적인 층으로 구성됨:
- 발표자:
- 어플리케이션
- 데이터베이스
- R 용 스탠드 실시간 처리.
- 3 ~를 의미 3 계층 건축 양식.
사용자 PC(프런트엔드): 사용자는 접근합니다. SAP 시스템을 통해 SAP GUI 또는 웹 브라우저를 사용합니다. 사용자 컴퓨터에는 프런트엔드 클라이언트만 설치되고, 애플리케이션 및 데이터베이스 서버는 별도의 전용 하드웨어에서 실행됩니다.
애플리케이션 서버: 애플리케이션 서버는 비즈니스 로직을 실행합니다. 작업 부하는 여러 애플리케이션 서버에 분산되므로 사용자는 부하가 많을 때 더 빠른 응답을 받을 수 있습니다. 이러한 서버는 일반적으로 사용자 워크스테이션이 아닌 원격 인프라에서 실행됩니다.
데이터베이스 서버: 데이터베이스 서버는 요청에 따라 데이터를 저장하고 검색합니다. SQL ABAP에 의해 생성된 쿼리와 Java 애플리케이션. 데이터베이스 및 애플리케이션 서비스는 용량 요구 사항에 따라 동일한 머신 또는 별도의 물리적 호스트에서 실행될 수 있습니다.
이유는 무엇입니까 SAP R/3는 3계층 아키텍처를 사용하나요?
프레젠테이션, 비즈니스 로직 및 스토리지를 세 개의 독립적인 계층으로 분리하면 다음과 같은 이점을 얻을 수 있습니다. SAP R/3는 단일층 또는 이중층 설계에 비해 다음과 같은 네 가지 실질적인 이점을 제공합니다.
- 독립적인 확장성: 각 계층은 개별적으로 확장할 수 있습니다. 비즈니스 로직의 병목 현상은 데이터베이스 하드웨어를 건드리지 않고 애플리케이션 서버를 추가하여 해결할 수 있습니다.
- 작업 부하 분배: 메시지 서버는 들어오는 세션을 애플리케이션 서버 전체에 분산시켜 특정 서버가 단일 경합 지점이 되는 것을 방지합니다.
- 데이터베이스 보호: 최종 사용자는 데이터베이스에 직접 연결하지 않습니다. 모든 읽기 및 쓰기 작업은 애플리케이션 서버의 작업 프로세스를 통해 이루어지며, 이 프로세스는 권한 확인, 잠금 및 트랜잭션 로깅을 표준화합니다.
- Upgrade 유연성: The SAP GUI 프런트엔드는 (데스크톱, 브라우저 또는 모바일 클라이언트를 통해) 발전할 수 있습니다. SAPUI5) 애플리케이션이나 데이터베이스 코드를 변경하지 않고.
이러한 분리는 또한 가능하게 하는 요소입니다. SAP 다양한 데이터베이스 백엔드를 지원하기 위해 — 포함 SAP HANA, Oracle, IBM Db2, 그리고 Microsoft SQL Server — 동일한 애플리케이션 코드베이스 내에서.
SAP R/2 대 SAP R/3: 어떻게 Archi진화된 구조
SAP R/2는 메인프레임에서 실행되었으며 사용자 단말기가 데이터베이스와 직접 통신하는 2계층 아키텍처를 사용했습니다. 1992년에 출시된 R/3는 클라이언트와 데이터베이스 사이에 전용 애플리케이션 계층을 추가했습니다. 두 시스템을 나란히 놓은 모습입니다.
| 아래 | SAP R/2 | SAP R/3 |
|---|---|---|
| 아키텍처 | 2계층(메인프레임 + 터미널) | 3계층 구조(프레젠테이션 + 애플리케이션 + 데이터베이스) |
| 하드웨어 | 중앙 집중식 메인프레임 | 분산 유닉스 / Windows / 리눅스 서버 |
| 확장성 | 수직형 전용 (더 큰 메인프레임) | 수평 확장 (애플리케이션 서버 추가) |
| 데이터베이스 액세스 | 사용자 세션에서 직접 | 애플리케이션 서버 작업 프로세스를 통해 중재됩니다. |
| 프로그래밍 모델 | ABAP/4 전용 | ABAP 및 Java 나란히 |
나머지 섹션에서는 세 가지 R/3 레이어 각각에 대해 자세히 설명합니다.
다른 이해 SAP 레이어
그림 1: 세 가지 SAP R/3 레이어와 레이어 간 트래픽 흐름.
프리젠 테이션 레이어
The 프리젠 테이션 레이어 구성하는 소프트웨어 구성 요소가 포함되어 있습니다. SAP GUI는 R/3 시스템의 그래픽 사용자 인터페이스입니다. 시스템과 사용자 간의 인터페이스 역할을 하며, 데이터를 입력하고 표시하기 위한 직관적인 레이아웃을 제공합니다.
이 계층은 사용자 입력을 애플리케이션 서버로 전달하고, 서버에서 수신한 데이터를 응답으로 렌더링합니다. SAP GUI가 실행 중일 때는 해당 세션이 지속되는 동안 R/3 시스템에서 사용자의 터미널 세션에 연결된 상태를 유지합니다.
응용 프로그램 계층
The 응용 프로그램 계층 하나 이상의 애플리케이션 서버로 구성됩니다. 메시지 서버각 애플리케이션 서버는 R/3 비즈니스 로직을 실행하는 서비스 세트를 운영합니다. 이론적으로는 단일 애플리케이션 서버로 충분하지만, 실제로는 용량 및 이중화를 위해 서비스가 여러 서버에 분산됩니다.
메시지 서버는 애플리케이션 서버 간의 통신을 조정합니다. 요청을 전달하고, tracks 애플리케이션 서버 그룹은 사용자가 로그인할 때 현재 부하에 따라 적절한 서버를 할당합니다. 이것이 수평 확장을 가능하게 하는 핵심입니다.
데이터베이스 계층
The 데이터베이스 계층 R/3 시스템에서 사용하는 모든 데이터를 저장하는 중앙 데이터베이스 시스템을 포함합니다. 데이터베이스 스택은 데이터베이스 관리 시스템(DBMS)과 데이터베이스 자체라는 두 가지 구성 요소로 이루어져 있습니다. SAP 자체 DBMS를 탑재하고 있습니다. SAP HANA또한 모든 주요 상용 데이터베이스를 지원합니다.Oracle, IBM 디비2, Microsoft SQL Server).
모든 R/3 데이터(사용자 정의 설정, 애플리케이션 코드, 화면 정의, 메뉴, 함수 모듈 및 런타임 데이터)는 이 데이터베이스에 저장됩니다. 프로그램 코드와 설계 객체는 특정 섹션에 저장됩니다. R/3 저장소이러한 "저장소 객체"는 ABAP 워크벤치가 시스템 간에 읽고 쓰고 전송하는 대상입니다.
구성 요소 이해 SAP R/3 3단 Archi강의
그림 2: ABAP + Java 두 스택이 인프라를 공유하는 방식을 보여주는 시스템 아키텍처.
현대 SAP NetWeaver 인스턴스는 ABAP과 Java 스택. 아래 구성 요소는 각 스택이 게이트웨이, ICM 및 JCO 브리지를 공유하여 스택 간 통신을 수행하는 동시에 자체 디스패칭을 처리하는 방식을 보여줍니다.
| 구성 요소 | 스택 | 직위별 |
|---|---|---|
| 메시지 서버(ABAP) | ABAP | 분산된 배차 담당자 간의 통신을 조정합니다. ABAP 시스템 또한 인스턴스 간에 부하를 분산합니다. |
| 배차 대기열 | ABAP | Buffer 작업 프로세스가 사용 가능해질 때까지 들어오는 요청을 보류합니다. |
| 배 차원 | ABAP | 대기열에서 요청을 가져와 각 요청을 적절한 작업 프로세스 유형에 할당합니다. |
| ABAP 작업 프로세스 | ABAP | R/3 애플리케이션에서 대화 단계를 실행합니다. 유형에는 대화, 업데이트, 백그라운드, 스풀 및 큐가 있습니다. |
| 게이트웨이 | 공유 | 간의 통신을 가능하게 합니다. SAP 시스템 및 시스템 간 SAP RFC를 통해 외부 시스템과도 연결 가능합니다. |
| 메모리 파이프 | 공유 | 인터넷 통신 관리자(ICM)와 ABAP 작업 프로세스 간에 데이터를 전송합니다. |
| 메시지 서버(Java) | Java | 좌표 Java 디스패처 및 서버 프로세스; 내부 통신을 가능하게 합니다. Java 런타임 클러스터. |
| 대기열 서버 | Java | 설정된 논리적 잠금을 관리합니다. Java 서버 프로세스 내부에서 실행되는 애플리케이션 코드. |
| 중앙 서비스 | Java | 특수 Java 잠금 및 프로세스 간 메시징을 처리하는 클러스터 인스턴스입니다. "인스턴스"는 리소스(메모리, 작업 프로세스 등)의 그룹입니다. |
| Java 배 차원 | Java | 고객 요청을 접수하고 전달합니다. Java 서버 프로세스. |
| SDM | Java | 소프트웨어 배포 관리자 — J2EE 구성 요소를 설치합니다. Java 스택. |
| Java 서버 프로세스 | Java | 멀티스레딩을 사용하여 대량의 요청을 동시에 처리합니다. |
| ICM | 공유 | 인터넷 통신 관리자 — HTTP, HTTPS 및 SMTP 트래픽을 활성화합니다. SAP 브라우저를 통해 접속할 수 있습니다. |
| 제이코 | 다리 | Java 커넥터 — 두 장치 간의 통신을 처리합니다. Java 두 스택이 나란히 실행될 때의 디스패처와 ABAP 디스패처. |
그림 3: ABAP 작업 프로세스의 범주(대화, 업데이트, 백그라운드, 스풀, 대기열).
방법 SAP 로그온 프로세스가 작동합니까?
그림 4: 사용자 로그인 과정의 단계별 흐름도 SAP R/3 디스패처 및 작업 프로세스 계층.
단계 1) 사용자가 클릭합니다 SAP 시스템 SAP GUI; 요청이 다음으로 전달됩니다. 운영자.
단계 2) 요청이 도착합니다 요청 대기열관제사는 다음을 따릅니다. 선입선출 규칙을 적용하고 요청을 다음으로 사용 가능한 작업 프로세스에 할당합니다.
단계 3) 적절한 유형의 작업 프로세스가 할당됩니다. 사용자가 로그인하면 대화형 작업 프로세스가 할당되고, 백그라운드 보고서는 백그라운드 작업 프로세스가 할당되며, UPDATE 문은 업데이트 작업 프로세스로 전달됩니다. 작업에 따라 작업 프로세스 유형이 결정됩니다.
단계 4) Dialog 작업 프로세스가 할당되면 사용자의 권한 및 현재 설정이 적용됩니다. 말아서 공유 메모리로 데이터를 전송하여 작업 프로세스가 사용자의 데이터에 접근할 수 있도록 합니다. 대화 단계가 완료되면 해당 데이터는 삭제됩니다. 출시 다음 사용자를 위해 메모리를 확보하기 위해서입니다. "대화 단계"는 거래 과정에서 한 화면에서 다른 화면으로 이동하는 것을 의미합니다.
단계 5) 작업 프로세스는 먼저 버퍼에서 요청된 데이터를 찾습니다. 버퍼에서 데이터를 찾는 것을 검색이라고 합니다. 친 데이터베이스 왕복을 방지하여 응답 시간을 향상시킵니다. 해당 항목을 찾지 못하면 오류가 발생합니다. 미스... 그리고 데이터베이스 읽기. 높은 적중률 대 실패율은 가장 큰 원인 중 하나입니다. SAP 성능을 테스트하려는 경우에 권장됩니다.
단계 6) 나머지 데이터는 데이터베이스에서 조회하고, 종합된 결과를 다시 전송합니다. SAP 디스패처를 통한 GUI.
단계 7) 최종적으로 사용자의 세션 데이터는 공유 메모리에서 제거됩니다. 롤아웃다음 요청을 위해 메모리 영역을 해제합니다.
요청이 어디에서 발생하든 모든 사용자 상호 작용에 대해 동일한 디스패처 → 큐 → 작업 프로세스 → 버퍼 → 롤아웃 주기가 반복됩니다. SAP GUI, ICM을 통한 브라우저 또는 게이트웨이를 통한 외부 시스템.
