이글은 아래 링크의 원본 글에 대한 한글 번역 입니다
https://www.zapyard.com/odata-and-sap-netweaver-gateway-part-i-introduction/

 

OData and SAP Netweaver Gateway. Part I. Introduction

SAP Netweaver Gateway and OData

 

 

SAP 개발자라면 요즘 관심을 가지는 하나의 영역이 있으니 바로 데이터베이스로 SAP HANA, S/4 HANA, SAP ABAP on HANA 입니다. 그런데 아밥퍼라면 머지않아 프로젝트에서 만나게 될 또 다른 관심 기술 영역이 있습니다. 바로 OData, SAP 넷위버 게이트웨이, SAPUI5, SAP 피오리 입니다. “Fundamental Tutorial Series on SAP ABAP on HANA (SAP ABAP on HANA에 대한 Advance 시리즈가 곧 시작됩니다.)에 대한 연재 이후, 독자들로 부터 OData와 넷위버 게이트웨이에 대해 연재해 달라는 요청을 많이 받았습니다.

 

이 주제에 대해서는 사실 다른 SCN이나 블로그에 많이 소개 되고 있습니다. 그래서 처음에는 같은 주제에 대해 글을 쓰기가 망설여 졌습니다. 하지만 이제, 애독자들의 계속되는 요청에 힘입어 OData 와 넷위버 게이트웨이 연재를 시작하려 합니다. 간결하고 체계적으로 설명하겠습니다. 초보자들에게 많은 도움이 되었으면 좋겠습니다.

 

그럼 시작하겠습니다.

 

OData
일반적인 정의로 OData는 "Open Data Protocol"의 약어 입니다. 프로토콜은 모두가 지켜야할 일종의 규칙입니다. 그리고 OData 인터페이스는 개방형 표준으로 어떠한 어플리케이션, 프로그램, 소프트웨어, 장치에서든 상관없이 SAP에 HTTP(s) 프로토콜로 연결할 수 있고 데이터를 XML 문서로 다룰(읽고,쓰고,수정하고,해석하기) 수 있습니다. 이 프로토콜이 HTTP 기반이기 때문에 HTTP를 지원한다면 어떠한 프로그래밍 언어나 사용할 수 있습니다.

 

달리 표현하자면, OData는 기존 소프트웨어가 가지고 있는 폐쇠적인 데이터를 외부로 노출하고 공유하도록 도와주는 웹 프로토콜 입니다. OData 프로토콜은 JSON, Atom/XML 처럼 널리 쓰이는 데이터 포맷으로 표현하도록 지원합니다. OData를 사용하여 개발하면 크로스 플랫폼(여러 환경에서 공통으로 이용가능한) 형태의 웹과 모바일 어플리케이션을 만들 수 있습니다.

 

OData를 사용하면 고수준의 데이터 통합을 이루고 현재의 복잡한 비즈니스가 요구하는 여러 환경에서 공통으로 이용가능한 상호운용성을 가지는 서비스를 개발할 수 있습니다.

 

SAP Netweaver Gateway
아래 그림은 SAP 어플리케이션 계층에서 SAP 넷위버 게이트웨이의 위치를 나타냅니다. SAP 넷위버 게이트웨이는 외부에서 SAP을 들여다보고 SAP와 데이터를 주고/받을 수 있는 일종의 창문 같습니다. 외부에서 HTTP(s) 메시지를 보내면 SAP는 OData로 응답합니다. OData는 인터넷을 통해 데이터를 교환할 수 있는 공개 표준입니다. SAP 넷위버 게이트웨이(아래 그림에서 파란 상자로 표시)는 OData 서비스를 사용하여 외부에 연결된 장치, 플랫폼, 환경에 SAP의 데이터를 제공합니다. SAP 넷위버 게이트웨이는 프로그래밍 언어에 상관없고 SAP 개발 지식도 많이 필요 없는 SAP 비지니스 데이터 연결 서비스를 제공합니다.

 

Introduction to OData and SAP Netweaver Gateway

클라이언트 측(외부)과 서버 측(SAP) 양쪽의 프로그래밍 언어가 달라도 HTTP로 통신할 수만 있다면 전혀 상관 없습니다.

 

클라이언트는 쿼리를 보내고 받은 데이터를 다루는 형태로 서비스를 소비한다는 관점에서 OData 서비스의 "소비자(Consumers)" 라고 부릅니다. 비슷하게, 서버는 서비스를 제공한다는 관점에서 OData 서비스의 "공급자(Producers)"라고 부릅니다.

 

OData 이전에는 SAP 외부의 개발자들은 SAP에 접근하기 위해 RFC/BAPI 또는 웹서비스를 사용했습니다. 이런 경우 외부 개발자(웹 개발자)는 SAP와 주고 받는 데이터의 구조를 미리 알고 있어야 합니다. SAP 외부 개발자에게 SAP 시스템의 내부 작동원리에 대한 기본 지식이 필요했습니다. 하지만 이제 OData가 나타나면서 상황이 바뀌었습니다.

 

개발자 관점에서 OData의 장점.
i. OData 인터페이스는 XML 또는 JSON 을 사용하여 표현합니다. 두 포맷 모두 웹에서 정보 전송을 위해 널리 사용하며 평범한 문자기반의 프로토콜입니다.


ii. OData 메시지는 추가 설명이 필요없는 자기설명적(self-describing) 데이터 입니다. 그러므로 SAP 외부 개발자가 ABAP이나 SAP을 몰라도 OData 메시지의 내용을 해석하는데 문제가 없습니다.

 

이제 서버는 데이터를 제공하는 역할을 하고 클라이언트는 서비스를 호출하여 응답 받은 자원을 다루는 역할을 한다고 볼 수 있습니다. 서버는 자원을 조회하도록 서비스를 제공합니다. 클라이언트 또는 SAP 외부 개발자는 원하는 데이터를 제공하는 서비스를 호출하기만 하면 됩니다.

 

OData의 출현으로 SAP 와 SAP 외부 웹 개발자 사이의 소통 장애가 사라졌습니다. 이제 오픈북 같습니다. OData를 사용할때 비용도 들지 않고 라이센스 문제도 없습니다.

 

참고: MicrosoftOData의 원조 입니다. SAP이 원조가 아니라니 놀랍죠? 그후 OData의 표준화를 위해 Citrix Systems Inc., IBM Corp., Microsoft Corp., Progress Software, SAP AG, WSO2 등에서 참여하여 협력하였습니다. 지금은 Oasis Organisation 에서 OData를 관리하고 있습니다.

 

왜 OData를 웹의 ODBC (Open Database Connectivity)라고 하나요?
답: OData는 서버측 자원에 대해 데이터베이스에 접속한 것과 유사한 서비스를 제공합니다. 그래서 OData를 "웹의 ODBC"라고 합니다. 이해가 잘 안되시나요? 더 쉽게 풀어 보겠습니다.

 

ODBC ODBC는 DBMS나 OS 종류에 무관하게 DBMS에 접속하는 표준 API 입니다. 어플리케이션 계층과 DBMS사이에는 어플리케이션에서 받은 쿼리를 각 DBMS에 맞게 변환해주는 추가 드라이버가 있어서 가능합니다. 이와 비슷하게 OData는 공급자와 소비자 사이에서 미들웨어 같은 역할을 합니다. OData는 데이터를 소비(조회)하는 규격화된 방법이 있고 공급자(SAP 또는 SAP아닌) 종류에 무관하게 동작하는 것이 ODBC를 닮았습니다.

 

SAP에게 OData가 필요한 이유는 무엇인가요?
답: OData를 도입하기 전에는 "1대1 독립적 연결" 방식으로 SAP 와 SAP 외부간 통합을 이루었습니다. 만약 하나의 어플리케이션이 두개의 다른 플랫폼에서 사용된다면 SAP에는 두개의 독립된 설계가 필요 했습니다. 이런 방식은 일,노력,시간,돈의 중복 투자를 유발합니다.

 

아래 그림을 보세요. SAP에서 부터 동일한 데이터를 가져가는데도 여러 단말마다 각각의 인터페이스를 만들어 쓰고 있습니다.

 

Step by step OData Services

이 방식은 확장성이 떨어집니다. 시스템 구성의 복잡성이 증가 할수록 관리해야할 인터페이스도 같이 늘어 납니다.

 

1대1 독립적 연결방식의 대안으로는 "하나의 데이터 모델 -> 하나의 API -> 여러 단말 지원" 방식이 있습니다. 아래 그림을 보세요. SAP 넷위버 게이트웨이에 연결된 하나의 OData로 여러 종류의 모든 단말 어플리케이션을 지원합니다.

 

SAP Netweaver Gateway and OData

이 방식은 한가지 기술로 모든 환경, 모든 플랫폼을 지원합니다. 게다가 OData를 소비할때는 SAP 지식이 전혀 필요하지 않습니다.

 

OData의 라이벌은 무엇이 있나요?
답: 구글의 GData가 있습니다.

 

OData의 확장성이라는 특징이 SAP가 GData가 아니라 OData를 선택한 주요 요인중 하나 입니다. SAP에서는 값을 표시할때 일부 특별한 경우가 있는데 참조필드가 있는 경우가 있습니다. 예를 들어 통화 값을 표시하는 경우가 있습니다. 통화 값은 두개의 필드로 구성됩니다. 금액과 통화키 입니다. 이 두 값이 항상 연결된 쌍으로 함께 다녀야 합니다. OData의 확장성은 이런 제약사항을 지원합니다.

 

HTTP (Hyper Text Transfer Protocol)는 OData의 중요한 부분이기 때문에 여기서 잠깐 언급하겠습니다.

🙂

 

HTTP는 클라이언트-서버 구조 기반의 기술입니다. 브라우저는 클라이언트로 HTTP 요청을 보냅니다. 웹서버는 서버로 브라우저에게 응답을 보냅니다. HTTP는 클라언트와 서버 사이에 "무엇"을 전송하는지를 정의하고 있습니다. 데이터 패킷이 "어떻게" 전송되는지는 TCP/IP 프롵토콜에서 다룹니다.

 

 

What is stateless?
답: 웹서버는 HTTP 요청을 받고 그에 대해 응답을 보낸후 관련 내용을 모두 잊어 버립니다. 웹서버는 이전에 요청 받았던 내용을 보관하거나 기억할 필요가 없습니다. 이런 방식을 stateless 라고 합니다.

 

What is RESTful?
답: OData는 REST기반 기술입니다. RESTREpresentational State Transfer의 약어입니다. REST는 단말간 통신을 위한 간결하고 가벼운 아키텍처 유형입니다. RPC (Remote Procedure Calls)와 웹서비스의 대안으로 사용합니다. RPC나 SOAP은 동작-기반인데 반해 REST는 자원-기반 기술입니다.

 

동작이 아니라 자원을 기준으로 하기에 REST 서비스라고 부릅니다. 클라이언트와 서버 사이에 모든 통신은 HTTP 프로토콜 상에서 URI (Unified Resource Identifier)를 사용합니다. URI는 바로 자원(예: POHeader, POItem, Customer, Vendor 등)을 나타냅니다. 그리고 RESTful 서비스에서는 자원을 지칭한 후에 정해진 인터페이스만 동작 하도록 되어 있습니다. 자원을 다루는데 HTTP 메소드(GET, PUT, POST, DELETE)를 사용하도록 정해진 것입니다. 즉, 클라이언트는 어떤 메소드를 호출해야 할지 별도로 이름을 알고 있을 필요가 없습니다. GET 메소드는 해당 자원을 가져와서 표시하기 위해서 사용합니다. POST는 시스템에 새로운 자원을 추가할때 사용합니다. PUT는 기존 자원을 수정하기 위해서, DELETE는 기존 자원을 삭제하기 위해서 사용합니다. 어떠한 플랫폼이든지 어떠한 서비스든지 상관없이 GET, PUT, POST, DELETE 의 의미는 이렇게 동일합니다.


 

아직 이해가 잘 안되시나요? 실제 예재를 보면서 좀더 설명 드리겠습니다. (이걸 당장 어떻게 만들지 걱정하지 마세요. 다음 장에서 만드는 방법을 알려드립니다.)


 

RESTful API

위 그림의 OData 서비스에서 POHeaderSet, POItemSet, ZEKKOEKPOSet 는 "자원(Resource)" 입니다. Create, Delete, GetEntity, GetEntitySet 등은 "동작(Operation)" 입니다. OData 서비스를 호출할 때, SAP 외부(클라이언트)에서는 자원이 명시된 URI를 호출해야 합니다. 또한 SAP 외부에서는 GET, POST, PUT 등의 행위를 사용하여 서버로 부터 데이터 가져오기, 데이터 생성하기, 데이터 수정하기 등의 동작을 할 수 있습니다. 이 행위는 모든 OData에서 동일하게 정해진 것이고 표준화되어 있습니다. 클라이언트는 서버측에 실제 실행되는 메소드인 Create / GetEntity / GetEntitySet 등은 알 필요가 없습니다.


 

What is restful service

여러 URI가 동일한 자원을 지정하고 동일한 결과를 가질 수 있다는 점을 알려드립니다. 아래 예제를 보시죠.


 

URI 1: /sap/opu/odata/sap/ZGW_PURCHASE_SRV/POItemSet(Ebeln=’4500004723′,Ebelp=’00010′)

URI 2: /sap/opu/odata/sap/ZGW_PURCHASE_SRV/POHeaderSet(‘4500004723’)/HeaderToItemNav

위 두 URI는 모두 같은 자원을 지칭합니다.


 

우리 시스템에 SAP 넷위버 게이트웨이가 있는지 확인하는 방법이 있습니까?
답: NW 7.3 이거나 이전 버전이면 3개의 애드온 GW_CORE, IW_FND, IW_BEP 가 있습니다. GW_CORE 와 IW_FND 컴포넌트는 게이트웨이 서버의 기능을 위해 필요하고 IW_BEP 는 게이트웨이 백엔드 기능을 위해 필요합니다.

 

7.4이후 버전이라면 Gateway Foundation이란 이름의 SAP_GWFND 가 있습니다. 3개의 컴포넌트가 하나로 통합되었습니다.


 

SAP_GWFND

이번 장에서는 OData와 SAP 넷위버 게이트웨이 그리고 관련 용어 몇가지를 소개하였습니다. 이어지는 다음 장에서는 OData를 사용하는 실습을 좀더 깊이 있게 다루겠습니다. OData 서비스를 만드는 방법, 그리고 GET, POST, PUT 등의 메소드를 호출하는 방법, 서버에 정의된 메소드를 요구사항에 맞게 구현하는 방법 등을 배우게 될 것입니다. 또한 Navigations Associations 이 무엇이지를 배우고 실습할 것입니다. 마지막으로, 우리가 만든 OData 서비스를 소비할 SAPUI5 어플리케이션도 만들 것입니다.

 

다음 장: OData 와 SAP 넷위버 게이트웨이. 제 2장. OData 서비스 만들기 실습

 

 

이글은 아래 링크의 원본 글에 대한 한글 번역 입니다
https://www.zapyard.com/odata-and-sap-netweaver-gateway-part-i-introduction/

+ Recent posts