ABAP Cloud의 다양한 사용 케이스 이해

클라우드 네이티브가 ABAP 프로그래밍 언어(ABAP 언어 버전 "클라우드 개발을 위한 ABAP" 또는 "ABAP 클래식"이 아닌 "주요 사용자를 위한 ABAP")와 기본 IDE(Eclipse용 ABAP 개발 툴)의 발전이 어떻게 필요했는지 살펴보았습니다. 따라서 ABAP이 사용하는 기본 프로그래밍 모델도 진화해야 하는 것은 놀라운 일이 아닙니다. 기존 ABAP 기술(예: SAP GUI 또는 Web Dynpro)은 클라우드 네이티브 요구사항과 호환되지 않습니다.

이전 소단원에서 언급한 바와 같이, REST는 오늘날 개발자가 가장 많이 사용하는 API 아키텍처 모델 중 하나로 떠올랐으며, REST의 가장 인기 있는 구현 중 하나는 개방형 데이터 프로토콜(OData)입니다. OData는 비즈니스 프로그램이 수행해야 하는 데이터 처리 및 데이터 조작 유형을 최적화하기 위해 처음부터 "ODBC for the Web"이라고 합니다. 기술적으로 필요한 것은 아니지만, OData를 통해 조작된 비즈니스 데이터가 데이터베이스에 존재하는 경우가 많습니다. SAP HANA 데이터베이스는 SAP S/4HANA Cloud의 기본 데이터베이스이므로 일반적으로 REST와 OData는 클라우드 네이티브가 필요로 하는 진화된 ABAP 프로그래밍 모델의 자연스러운 방향입니다. 이러한 진화의 결과는 ABAP RESTful 어플리케이션 프로그래밍 모델입니다.

하지만 작은 구덩이 정류장이 먼저 있었다.

REST 호환 OData 서비스의 첫 번째 생성은 ABAP RESTful 어플리케이션 프로그래밍 모델인 SAP Fiori를 위한 ABAP 프로그래밍 모델에 대한 사전 프로그래밍 모델을 기반으로 했습니다. 생성 시점에 이 모델은 서비스 생성에 대한 베스트 프랙티스였지만 몇 가지 문제가 있었습니다. 브라운필드 시나리오를 사용하는 SAP Fiori용 ABAP 프로그래밍 모델을 사용한 개발은 지원되지 않았으며 툴 지원은 통합 툴 환경이 아닌 여러 트랜잭션 코드로 구성되었습니다. 또한 프로그래밍 모델의 일부 측면에서는 프레임워크 구현을 사용하여 ABAP 개발자가 사용했던 것보다 ABAP 코드에 대한 투명성이 조금 떨어졌습니다.

이러한 과제는 관리 가능했지만, 다음 진화된 단계는 Eclipse의 전체 개발 흐름을 Eclipse용 ABAP 개발 툴과 통합하여 이를 제거하고 개발 아티팩트를 단순하고 직관적인 리스트로 통합하는 것이었습니다. ABAP RESTful 어플리케이션 프로그래밍 모델은 SAP Fiori용 ABAP 프로그래밍 모델의 후속 모델이며 ABAP Cloud에서 트랜잭션 사용 케이스에 사용되는 프로그래밍 모델입니다.

ABAP RESTful 어플리케이션 프로그래밍 모델을 사용하면 소수의 단순하고 직관적인 아티팩트에서 REST 호환 OData 서비스를 생성할 수 있습니다. 이러한 서비스는 사용자 계층에서 실행되는 SAP Fiori 앱의 서비스 계층이나 독립 실행형 웹 API(UI 기반 여부에 관계없이 모든 유형의 클라이언트에서 사용 가능)로 사용할 수 있습니다. ABAP RESTful 어플리케이션 프로그래밍 모델로 작성된 비즈니스 오브젝트를 로컬 API로 사용할 수 있습니다(곧 논의 예정).

이전 소단원에서는 어플리케이션이 별도의 사용자 계층, 서비스 계층, 데이터 레이어로 분할되는 마이크로 서비스 디자인이 클라우드 네이티브 개발의 중요한 요소라고 언급했습니다. ABAP RESTful 어플리케이션 프로그래밍 모델은 처음부터 마이크로 서비스 개념과 일치하도록 설계되었습니다.

ABAP RESTful 어플리케이션 프로그래밍 모델 아티팩트는 다음 네 가지 계층을 기준으로 구성됩니다.

• 데이터 액세스
• 도메인 모델 및 구현
• 비즈니스 서비스 노출
• 비즈니스 서비스 사용

다양한 레이어를 이해해 보겠습니다.

• 데이터 액세스

  ABAP RESTful 어플리케이션 프로그래밍 모델의 기본 계층에는 트랜잭션과 분석에 필요한 비즈니스 데이터가 들어 있는 데이터베이스 테이블이 있습니다. 물론 이 데이터베이스는 SAP HANA입니다. SAP HANA, ABAP RESTful 어플리케이션 프로그래밍 모델을 사용하면 인메모리 아키텍처, 열 저장소, 실시간 데이터, 기계 학습 기술의 이점을 다른 기술에서 자동으로 활용할 수 있습니다.

• 도메인 모델 및 구현

  도메인 모델 및 구현은 비즈니스 시나리오에 관련된 다양한 개념(예: 고객 및 오더), 해당 관계(예: 고객과 오더 간의 상위-하위 관계) 및 마지막으로 이러한 엔티티와 관계의 구현으로 구성됩니다.

• 도메인 고유 프로그래밍

  ABAP 언어 및 ABAP Core Data Services(CDS)는 ABAP RESTful 어플리케이션 프로그래밍 모델의 컨텍스트에서 읽기 전용 쿼리와 트랜잭션 비즈니스 오브젝트의 도메인별 구현을 제공하는 데 사용되는 주요 언어입니다.

  ABAP 언어 버전 "클라우드 개발을 위한 ABAP"은 비즈니스 로직을 구현하기 위해 ABAP Cloud 컨텍스트에서 사용되는 클라우드에 최적화된 언어 구조를 제공합니다. ABAP 언어는 ABAP RESTful 어플리케이션 프로그래밍 모델로 빌드된 비즈니스 오브젝트의 트랜잭션 동작을 기본적으로 제어할 수 있도록 엔티티 조작 언어(EML, Entity Manipulation Language)로 향상되었습니다.

  CDS는 ABAP 어플리케이션 서버에서 풍부한 의미 구조를 가진 데이터 모델을 정의하는 강력한 데이터 모델링 인프라를 제공합니다. 다양한 CDS 아티팩트는 다음을 사용하여 정의됩니다. 

  • CDS 유형 정의 언어(TDL)
  • CDS 데이터 정의 언어(DDL, Data Definition Language)
  • CDS 서비스 정의 언어(SDL)
  • CDS 데이터 제어 언어(DCL)
  • CDS 주석
• 도메인별 데이터 모델링

  도메인 고유 모델은 프로그래밍 모델 측면에 따라 데이터 모델의 디자인 타임 아티팩트를 결정합니다. ABAP RESTful 어플리케이션 프로그래밍 모델을 사용하여 읽기 전용 쿼리와 트랜잭션 비즈니스 오브젝트를 개발할 수 있습니다. 모든 실제 엔티티는 노드 간에 상위-하위 관계가 있는 하나 이상의 노드로 구성된 비즈니스 오브젝트(BO)로 표시됩니다. 비즈니스 오브젝트는 항상 루트 노드로 시작합니다.

  방금 언급한 고객 및 오더 예제를 채택하면 ABAP RESTful 어플리케이션 프로그래밍 모델에 두 가지 가능성이 있습니다. 읽기 전용 시나리오(즉, 쿼리 기능)와 트랜잭션 시나리오(생성, 업데이트, 삭제 기능)가 이러한 시나리오에 해당합니다. 쿼리는 ABAP CDS를 사용하여 모델링됩니다. 트랜잭션 기능은 ABAP 언어 및 EML과 함께 CDS 동작 정의를 사용하여 정의됩니다. 따라서 개념 레벨에서 BO는 ABAP CDS 엔티티로 정의된 데이터 모델과 CDS 동작 정의를 통해 정의되고 ABAP 언어 및 EML을 통해 구현되는 관련 트랜잭션 기능으로 구성됩니다. 각 BO 노드의 데이터 모델은 데이터 가능 테이블 또는 다른 CDS 엔티티 위에 정의된 하나의 CDS 뷰 엔티티로 표시됩니다. 따라서 예를 들어, 고객/오더 시나리오에는 각각 하나씩 두 개의 주요 CDS 뷰 엔티티가 있습니다.

• 비즈니스 서비스 노출

  비즈니스 서비스는 ABAP RESTful 어플리케이션 프로그래밍 모델의 REST 기능이 필요한 곳입니다. 다음과 같이 구성됩니다.

  • REST를 통해 액세스할 수 있는 쿼리 및 트랜잭션 기능을 표시하는 서비스 정의입니다.
  • 서비스 정의를 REST 프로토콜과 연결하는 서비스 바인딩으로, 서비스를 사용할 수 있습니다.

  서비스 정의는 선호하는 사용 유형에 따라 서로 다른 프로토콜을 사용하여 여러 서비스 바인딩으로 여러 번 게시할 수 있습니다.

• 비즈니스 서비스 사용

  다양한 옵션을 사용하여 소비할 수 있습니다. 앞서 언급했듯이 OData 기반의 서비스 바인딩은 SAP Fiori 앱 개발을 활성화할 수 있습니다. 앱 간(또는 시스템에서 시스템으로) 통합에 OData를 사용할 수도 있습니다. 이 경우 도메인 모델링 및 구현 계층의 UI 메타데이터는 무시됩니다. 이벤트 중심 아키텍처를 사용하면 이벤트 컨슈머로부터 직접 응답이 필요하지 않은 사용 케이스에서 이벤트 프로바이더와 이벤트 컨슈머 간의 비동기 통신이 가능합니다. SAP BTP의 서비스인 SAP Event Mesh를 사용하면 ABAP RESTful 어플리케이션 프로그래밍 모델 BO가 이벤트 컨슈머 또는 이벤트 프로바이더 역할을 할 수 있습니다.

ABAP Cloud는 트랜잭션 사용 케이스 외에도 분석 시나리오에 대한 최대 과제입니다. 분석 사용 케이스에서는 다차원 데이터 모델을 분석 및 평가하여 실시간 데이터 기반 비즈니스 의사결정을 도출합니다. 분석 프로그래밍 모델 측면은 임베드된 설정이나 시스템 간 설정에서 비즈니스 데이터를 분석하고 대시보드 또는 앱의 일부로 데이터를 시각화하는 데이터 모델을 생성하는 데 중점을 둡니다.

이러한 분석 사용 케이스에 대한 End-to-End 개발은 ABAP Cloud를 사용하여 수행할 수 있습니다. 재사용 가능 스타 또는 눈송이 스키마(큐브, 차원, 계층구조 기반)와 같은 분석 프로바이더는 다차원 도메인 고유 모델을 구축하도록 설계될 수 있습니다. 도메인 고유 로직은 CDS를 통해 구현됩니다. 다양한 분석 클라이언트(예: SAP Analytics Cloud 또는 SAP Analysis for Office)를 위한 정보 액세스(InA) 프로토콜 서비스를 사용하여 CDS 분석 프로바이더를 노출할 수 있습니다. 또한 SAP Fiori UI를 통해 OData 액세스를 노출할 수 있습니다.

마지막으로, 통합 사용 케이스를 살펴봅니다. 이 시나리오를 이해하면 지속 가능한 인텔리전트 기업이라는 용어를 정의하는 데 도움이 됩니다. 지속 가능한 인텔리전트 기업은 민첩하고 통합된 비즈니스 프로세스에 고급 기술과 Best Practices를 지속적으로 적용하는 기업입니다. SAP는 데이터 및 프로세스 통합, 유연한 가치 사슬 구축, 업계 선진사례로 혁신, 고객, 파트너 및 직원 정서에 대한 이해 및 조치, 환경 영향 관리를 위한 솔루션을 제공하여 고객이 지능형 기업으로 거듭날 수 있도록 지원합니다. SAP S/4HANA Cloud 및 SAP Ariba와 같은 SAP 제품의 포괄적인 포트폴리오와 SAP Business Technology Platform을 결합함으로써 SAP는 고유한 비즈니스 프로세스를 엔드 투 엔드로 통합할 수 있습니다.

SAP의 인텔리전트 엔터프라이즈는 다음과 같은 네 가지 핵심 End-to-End 프로세스로 구성됩니다.

• 리드-결제(Lead-to-Cash)
• 설계-운영(Design-to-Operate)
• 소싱-지급(Source-to-Pay)
• 채용-퇴직(Recruit-to-Retire)

이러한 각 프로세스에는 SAP S/4HANA Cloud를 비롯한 다양한 SAP 제품 및 솔루션에 대한 연결이 필요합니다. 따라서 연결 옵션이 계속 필요하며 ABAP Cloud의 일부로 제공됩니다. 비추천 통합 기술은 ABAP Cloud(예: IDoc)에서 더 이상 사용할 수 없습니다. 릴리스된 프레임워크만 가능합니다. 다음과 같은 연결 프레임워크를 사용할 수 있습니다.

• OData 서비스
• 비즈니스 이벤트
• HTTP 서비스
• 클라우드 지원 WebSocket RFC를 통한 RFC
• SOAP 사용(SOAP 서비스 프로바이더 계획됨)
• 외부 ODBC 클라이언트의 SQL 서비스
• 분석 클라이언트를 위한 SAP 정보 액세스(InA)

이러한 프레임워크와 함께 클라우드 커넥터는 내부 랜드스케이프에 있는 시스템에 연결할 수 있습니다.

자격 증명 간의 컨텐트 분리를 위해 고객은 SAP S/4HANA Cloud에서 연결 대상(SM59)과 논리 포트(SOAMANGER)의 기존 트랜잭션에 직접 액세스할 수 없습니다. 대신 일련의 SAP Fiori 앱(클라우드 통신 관리)을 사용하여 필요한 사용자 및 인증 옵션과 함께 통신 시나리오를 구현하는 데 필요한 모든 논리적 아티팩트를 설정합니다.

이 소단원은 ABAP Cloud 개발 모델과 ABAP RESTful 어플리케이션 프로그래밍 모델이라는 용어가 동일한 개념을 의미할 수 있다는 사실을 간략히 확인함으로써 마무리합니다. 그렇지 않습니다. 두 용어는 이해하는 데 중요한 여러 가지를 나타냅니다.

ABAP Cloud에서 참조하는 범위가 더 큽니다. 전체 개발 모델을 포괄합니다. 여기에는 프로그래밍 모델, 수명 주기 세부사항, API, 사용자 정의 및 확장 개발을 위한 규칙, ID 및 액세스 관리와 관련된 세부사항도 포함됩니다(이에 국한되지 않음).

반면 ABAP RESTful 어플리케이션 프로그래밍 모델이 참조하는 범위는 더 작고 구체적입니다. 특정 목적을 위한 특정 개발 아티팩트를 구축하기 위한 특정 프로그래밍 모델(예: 툴, 기술, 기술)을 가리킵니다. 프로그래밍 모델은 ABAP 클라우드에 통합되어 있습니다. 다른 방향으로 관계를 정의하는 것도 마찬가지로 적절합니다. 즉, ABAP Cloud는 트랜잭션, 분석 및 통합 사용 케이스를 구현하기 위해 ABAP RESTful 어플리케이션 프로그래밍 모델을 참조합니다.