1장 개요 부분에서는 SAP 넷위버 게이트웨이, OData, HTTP의 개념, 정의 등을 설명하였습니다. 그리고 RESTful 과 STATEless에 대해서도 설명하였습니다. 이번 장에서는 OData 서비스를 만들고 URI를 호출하는 등 실습을 해보겠습니다. 이 URI는 SAP 외부(클라이언트)에서 SAP의 데이터를 조회/수정 하기위해 HTTP(s)로 호출하는 서버측 지점 입니다. 만약 SAPUI5 어플리케이션을 만든다면 이 URI로 접속하여 SAP의 데이터를 다룰 수 있습니다. 우리는 또한 스탠다드 메소드를 재정의하여 요구사항에 맞는 우리의 아밥 로직을 넣어 보겠습니다.

A. 데이터 모델 정의하기
티코드 SEGW (SAP Gateway Service Builder)로 이동합니다. 티코드는 SE38과 비슷한데 38 대신 GW (GateWay)가 들어갑니다. 생성 아이콘을 누릅니다. 프로젝트 이름, 설명, 패키지(로컬 가능)를 입력하고 저장합니다.

프로젝트가 만들어졌습니다. 아래에 폴더가 4개 있습니다. Data Model, Service Implementation, Runtime Artifacts 그리고 Service Maintenance 입니다. 그리고 Data Model 아래에는 3개의 폴더 Entity Types, Associations, Entity Sets 가 있습니다. 지금 보이는 모든 폴더는 비어 있습니다.

도대체 Entity Type은 뭐고 Entity Set은 무엇인가? 라는 생각이 들텐데요. 바로 알려드리겠습니다.🙂

Entity Type 은 쉽게 스트럭쳐라고(= 한줄만 가지고 있는 워크 에어리어) 생각하면 됩니다. Entity Set은 예상한대로 바로 인터널 테이블(= 여러 entity/줄) 입니다. 아밥퍼로서 자신감이 생깁니까? 우리는 방금 새로운 용어 2개를 배웠습니다. 🙂

우선 스트럭쳐를 헉!! 워크 에어리어 아니아니, Entity Type(이게 Gateway의 용어죠)을 만들어 보겠습니다.

Entity Types 폴더에서 마우스 오른쪽버튼을 누르고 "Create"를 선택합니다. 이름은 적절히 입력하고 잘 기억하세요. "Create Related Entity Set" 체크박스에 체크 합니다. 이 예제에서는 POHeader는 스트럭쳐(워크 에어리어)이고 POHeaderSet은 인터널 테이블입니다.

Service Implementation 폴더를 확인해 보면 POHeaderSet의 동작이 자동으로 생성된 것을 볼 수 있습니다. 이 ABAP 메소드는 외부에서 호출하는 단말지점에 대응하여 실행되는 메소드입니다.

이제 스트럭쳐/워크 에어리어 그리고 인터널 테이블의 각 필드를 정의하겠습니다.

Properties 폴더를 더블클릭 합니다. 다음 생성 버튼을 눌러서 추가된 라인에 필드 이름, 타입, 길이 등을 입력합니다. 이 예제에서는 Ebeln 과 Bukrs를 추가 했습니다. 추가로 필요한 필드를 더 추가합니다.

이것도 읽어보면 도움이 됩니다: SAP HANA from Space Level

필드 하나하나씩 추가하는데 좀 귀찮아 보이지 안나요? 이럴때 좋은 방법이 있습니다. 위 방법은 그냥 이런것도 있다라고 알고만 있으세요. 실제 프로젝트에서는 아래의 방법이 더 많이 쓰입니다. 아까 만든 POHeader Entity Type 과 POHeaderSet Entity Set 을 삭제합니다. 삭제 방법은 마우스 오른쪽버튼을 눌러서 delete를 선택하면 됩니다.

다시 제대로 만들어 보겠습니다.

Data Model 폴더에서 마우스 오른쪽버튼을 눌러서 Import > DDIC Structure를 선택합니다. Entity Type 이름을 입력하고 import할 ABAP 스트럭쳐를 입력합니다. Entity Set에 대한 체크박스를 체크하는 것도 필요합니다. (인터널 테이블이 필요없다면 체크 안해도 됩니다).

Next를 누릅니다. EKKO (예제의 경우) 스트럭쳐에서 Entity Type에 추가할 필드를 선택합니다.

다음은 키 필드를 선택합니다. 이 예제에서는 Ebeln이 키입니다.

Finish를 누르고, 저장합니다. Properties 폴더와 Service Implementation 폴더를 확인해 보세요. 각자 필요한 스트럭쳐와 동작이 만들어 진것을 확인할 수 있습니다.

이제, Entity Type을 추가로 하나 더 만들어 보겠습니다. 위와 같은 방법으로 EKPO 로 부터 import하여 Entity Type POItem 을 만들어 보세요.

위 그림을 보면 각각의 Entity Type은 각자의 Properties 폴더와 Navigation Properties 폴더를 가지고 있는 것을 볼 수 있습니다. 그리고 Service Implementation 폴더 아래에 각 Entity Set 별로 각자의 동작(Create, GetEntity, Update, Delete 등)을 가지고 있습니다.

지금까지 헤더 테이블과 아이템 테이블을 만들었습니다. 이제 더 이상 Entity Type이 필요한것 같지는 않습니다.

B. 구현과 서비스 등록
계속해서 만들고 서비스를 등록해 보겠습니다.

생성 버튼을 누르고 Ok를 선택합니다. 패키지를 입력하고 CTS 전송정보를 입력하고 저장합니다. 아래 그림처럼 성공 메시지가 나올 겁니다.

Technical Service Name은 외부 시스템에서 호출할 실제 서비스 이름이라는 점을 명심하세요. Model Provider Class (MPC) 와 Data Provider Class (DPC) 에서 각각 2개의 클래스, Base 클래스 와 Extended 클래스가 생성됩니다.

Model Provider Class는 /IWBEP/CL_MGW_ABS_MODEL에서 상속 받고 Data Provider Class는 /IWBEP/CL_MGW_ABS_DATA에서 상속 받습니다. 아래 그림은 생성된 클래스의 슈퍼클래스(부모) 관계를 보여줍니다.

참고: Data Provider Class는 Gateway Service functionalities를 제공합니다. Model Provider Class는 Gateway Service interface를 정의합니다.  DPC와 MPC는 코딩으로 서로 연결되어 있지 않습니다. 이들은 Configuration으로 서로 통신합니다.

C. 서비스를 서비스 카탈로그에 추가하기 (서비스를 게이트웨이 허브에 등록하기)
서비스를 구현했습니다. 이제 서비스를 서비스 카탈로그에 추가해야 합니다.

인터넷에서 볼 수 있는 대부분의 튜토리얼에는 Service Maintenance 폴더 아래에 한개 항목이 있고 그곳에 시스템 상세가 보이며 Register/Maintain 버튼이 활성 상태(아래 그림처럼)인 모습일 겁니다. 만약 Service Maintenace 폴더 아래에 한개의 항목이 보인다면, 그것은 바로 시스템에 "Embedded Deployment" 기능이 있는 것입니다.

SAP 넷위버 게이트웨이 컴포넌트는 SAP 백엔드 시스템에 애드온으로 설치되는데 Embedded Deployment 옵션으로 설치된 것입니다. OData 모델링과 외부에 서비스 공개하기 두가지 모두 백엔드 시스템에서 이루어 졌습니다.

Embedded Deployment 전략의 장점:
i. 비용을 줄일 수 있습니다. 추가로 게이트웨이 허브를 배치할 필요가 없습니다.
ii. 실행속도가 빠릅니다. 분리된 두 시스템(프론트엔드와 백엔드)간의 리모트 콜 통신 같은 오버헤드가 없습니다.

Embedded Deployment 전략의 단점:
i. 게이트웨이 허브 같은 접속을 위한 단일 지점이 없습니다. 대신 백엔드 시스템이 외부에 직접 공개 됩니다. 그래서 백엔드 시스템 보안에 더 신경을 써야 합니다.
ii. 백엔드 시스템의 추가 버전 업그레이드가 필요 할 수 있습니다.
iii. 만약 시스템 배치상 여러 SAP 백엔드를 운영중인 경우, 각각의 시스템에 넷위버 게이트웨이 컴포넌트를 설치하고 관리해야 하는 부담이 있습니다.

만약 Embedded System이라면, Register 와 Maintain 버튼을 누르세요.

위 그림은 우리 SAP 시스템의 것이 아닙니다. 우리 시스템에는 Service Maintenance 폴더 아래에 아무것도 없습니다. 우리 아키텍처는 "Hub Deployment with Development in the Backend System" 이기 때문입니다. 이 전략에서는 SAP 넷위버 게이트웨이를 별도의 게이트웨이 허브라고 불리는 기계에만 설치합니다. 게이트웨이 허브는 바같 세상에서 SAP을 바라보는 창문과 같습니다. 게이트웨이 허브에서는 OData 서비스를 등록하고 공개하는 일을 합니다. 하지만 개발은 여전히 SAP 백엔드 시스템에서 이루어집니다.

Hub Deployment with Development in the Backend System 전략의 장점:
i. 보안성이 높습니다. 외부에서 접속하는 시스템이 오직 하나이기에 게이트웨이 허브 하나만 보안을 책임지면 됩니다.
ii. 게이트웨이 컴포넌트는 다른 SAP 시스템에 있지만, OData 모델/서비스에 직접 백엔드 DDIC와 비지니스 데이터를 이용할 수 있습니다.
iii. 게이트웨이 허브는 새 버전 NW 7.3/7.4 또는 더 높은 버전으로 업그레이드 할 수 있습니다. 백엔드는 낮은 버전을 유지하더라도 상관없이 게이트웨이 허브만 별도로 업그레이드 가능합니다. 새로운 게이트웨이 버전은 SAPUI5도 지원합니다.

단점: 비용이 더 많이 들고 리모트 콜에 의한 통신 오버헤드가 있습니다.

우리 시스템 화면으로 돌아와서 계속하겠습니다. 우리 백엔드 시스템에는 기본적으로 maintain과 register 옵션이 없습니다. 그러므로 넷위버 게이트웨이가 있는 프론트엔트 시스템 즉, 게이트웨이 허브에서 작업을 계속해야 합니다.

게이트웨이 허브(프론트엔드 시스템)으로 가기위해 티코드 /IWFND/MAINT_SERVICE 를 입력합니다. 이 티코드는 즐겨찾기에 추가해두기를 권장합니다.🙂

  모든 OData 서비스에서 이 기능이 필요할 것입니다.

서비스가 아직 서비스 카탈로그에 등록되지 않았습니다. 서비스 카탈로그에 서비스를 등록해야 우리 서비스가 바같 세상에서 접속 할 수 있는 상태가 됩니다.

Add Service 버튼을 누릅니다. 백엔드 시스템 별명과 외부 서비스 이름(이 예제에서는 ZGW_PO_SRV)을 입력합니다. 백엔드 시스템에서 만든 서비스가 목록에 나타납니다. 해당 서비스를 클릭하면 서비스 이름이 보입니다. 그리고 모델 이름 (ZGW_PO_MDL)도 보입니다. 그대로 저장 합니다. 뒤로가기를 눌러서 서비스 카탈로그 화면으로 이동합니다.

우리가 만든 서비스를 찾아서 클릭해보세요. 오른쪽 아래에 시스템 별명이 보일 것입니다. SAP 게이트웨이 클라이언트로 이것을 테스트 해보겠습니다. 티코드 /IWFND/GW_CLIENT로 이동하세요.(이 티코드도 기억하시기 바랍니다). 테스트는 웹브라우저로도 가능합니다. 이번에는 SAP 게이트웨 클라이언트로 테스트를 해보겠습니다.

이런!! 에러가 발생했네요. 상태는 403, Forbidden 이고 메시지가 "No authorization to access Service" 입니다. 권한 확인을 위해 티코드 SU53으로 이동합니다. 확인 후 필요한 권한을 각자 SAP BC에게 요청하세요.

BC가 뭘해야 할지 잘 모를 경우 아래 스크린샷이 도움이 될 겁니다.

ZGW_PO_SRV_0001는 어디서 나온걸까요? 아래 그림을 봅시다.

이것도 읽어보면 도움이 됩니다: SAP ABAP for HANA Tutorials

권한 문제는 해결되었으니 이제 다시 티코드 /IWFND/MAINT_SERVICE로 이동합니다. 서비스를 선택하고 SAP GateWay Client를 누르거나 또는 직접 티코드 /IWFND/GW_CLIENT로 이동하세요. 실행을 눌러보겠습니다. 이번에는 상태 코드가 200 즉 성공이네요.

축하합니다!! 우리는 방금 OData 서비스를 만들고 활성화 시켰습니다.

위 그림에서 URI는 (/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml) XML을 포맷으로 하고 있습니다. 이 값을 JSON으로 바꿔 보죠 (/sap/opu/odata/sap/ZGW_PO_SRV/?$format=json). xml 과 json 모두 두 Entity Set이 있다고 잘 응답하는군요.

주의: json 이라는 단어는 대소문자를 구분합니다. 반드시 소문자 "json"이라고 입력해야 합니다.

이번에는 OData의 메타데이터를 확인해 보겠습니다. layman의 정의에 따르면 메타데이터는 스트럭쳐와 속성 또는 전체 뼈대 (엑스레이 처럼)를 의미 합니다.🙂

먼저 Entity Type (워크 에어리어/스트럭쳐)의 이름이 보입니다. 우리 OData 에는 두개(POHeader 와 POItem)가 있습니다. 다음으로 Entity Set (인터널 테이블)의 이름이 보입니다.  역시 두개(POHeaderSet 와 POItemSet)가 있습니다. 밑에는 링크를 하나 볼 수 있습니다. 이 링크는 웹브라우저에서 우리 서비스를 열수 있는 링크 입니다. 복사해서 브라우저에 붙여넣어 보세요.(접속시 SAP 프론트 엔드의 자격증명이 필요합니다)

만약 당신이 SAP OData 서비스를 이용하고자 하는 SAP 외부 웹 개발자이고 단지 서비스 이름과 URI만 알고 있는 상황이라면, 우선 알고 싶은 것은 스트럭쳐의 상세 정보일 것입니다. 스트럭쳐 정보가 어플리케이션 개발에 꼭 필요하기 때문이죠. 상세정보를 보기 위해 먼저 ?$format 을 이용하여 확인해 보겠습니다.

주로 쓰는 포맷은 2가지가 있습니다.

1. ?$format = json
https://txaixegd01.zapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=json

2. ?$format=xml
https://txaixegd01.zapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml

아밥퍼는 어떻게 OData 서비스의 에러를 찾을 수 있나요?
URI에 무언가 잘못입력하거 URI가 작동하지 않을때라면 화면에 이런 메시지가 나옵니다. "Run transaction /IWFND/ERROR_LOG on SAP Gateway hub system"

티코드 /IWFND/ERROR_LOG로 이동하면 에러를 확인할 수 있습니다.

위 경우 실제 에러는 "$"앞에 "?"가 없어서 발생한 것입니다.
틀림: https://txaixegd01.zapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/$format=xml
바름: https://txaixegd01.zapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml

/IWFND/ERROR_LOG의 화면을 확인해 보죠.

POHeaderSet에서 데이터를 가져올 수 있는지 확인해 봐야 겠습니다.

웹브라우저에 URI https://txaixegd01.zapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet를 입력하거나 또는 티코드 /IWFND/GW_CLIENT에서 /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet를 입력합니다.

저런, Not Implemented 에러가 있네요. data provider class의 메소드 'POHEADERSET_GET_ENTITYSET'가 구현되지 않았습니다.

백엔드 시스템에서 티코드 SEGW로 이동합니다. 우리는 Entity Type/Set를 만들었고 서비스를 활성화하고 등록했습니다. MPC와 DPC가 생성되었지요. 하지만 DPC 메소드를 재정의하지 않았습니다. 데이터를 백엔드 시스템에서 가져와서 Entity Set (인터널 테이블) 형태로 제공하는 아밥코드와 로직을 작성해야 합니다. entity set이 제공되면 결과는 OData 서비스 호출로 확인할 수 있습니다.

단지 재정의만 하고 코드는 전혀 작성하지 않습니다. 이상태에서 OData 서비스는 무슨 결과를 보여줄까요?

DPC Extension class에서 변경 모드로 진입합니다. Base class가 아닙니다 (상속받은 클래스를 확장하기 때문에 extension class로 작업합니다).

재정의할 메소드에 마우스 커서를 두고 재정의 아이콘을 누릅니다. 자동생성된 코드가 보입니다.

다음 장에서 입력 파라미터와 출력 파라미터에 대한 자세한 내용을 다루겠습니다. 지금은 그냥 저장하고 활성화 하세요. Redefinition 폴더를 보면 메소드 'POHEADERSET_GET_ENTITYSET'가 목록에 나타납니다. 메소드 재정의가 잘 되었습니다.

결과를 확인해 보겠습니다. 티코드 /IWFND/MAINT_SERVICE 또는 /IWFND/GW_CLIENT로 이동하여 URI: /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet를 입력합니다.

이번에는 에러가 없습니다. 상태는 200 이고 OK 입니다. 하지만 내용에 데이터는 없군요. 우리가 인터널 테이블(entityset)을 만드는 로직을 전혀 넣지 않은 것이 명확하네요.🙂

이제, 구매 오더 테이블 EKKO에서 10개만 가져오는 로직을 넣어보겠습니다. 아래 로직을 입력하고 저장하고 활성화 합니다.

METHOD poheaderset_get_entityset.
  SELECT * UP TO 10 ROWS FROM ekko INTO CORRESPONDING FIELDS OF TABLE et_entityset.
ENDMETHOD.

다시 결과를 확인해 보도록 하겠습니다.

10개의 항목이 보입니다. 각 항목을 펼쳐보면 상세 내용을 볼 수 있습니다.

같은 결과를 브라우저로 확인해 보겠습니다.

아, 오늘은 여기까지 하겠습니다. 다음 장에서 다른 메소드도 구현해 보고 URI를 조정하여서 여러가지를 테스트해 보겠습니다. 또한 Association 과 Navigation 링크를 어떻게 만드는지 설명하겠습니다(데이터 모델 사이의 다른 엔티티간에 관계와 이동). 다음 장에는 더 많은 코드와 팁이 기다리고 있습니다. 계속 관심 가져 주세요.🙂

이번장에 보너스 부록

i. Hub Deployment with Development in the Gateway Hub
사실 SAP 넷위버 게이트웨이를 배치하는 3번째 전략이 있습니다. 2가지는 위에서 언급했습니다. 3번째는 바로 "Hub Deployment with Development in the Gateway Hub"입니다. 게이트웨이 컴포넌트를 백엔드 시스템에 설치할 필요없이 관련된 모든 걸 게이트웨이 허브에 넣는 방법입니다. 만약 백엔드 시스템에서 개발이 전혀 필요 없는 이미 시스템에 있는 스탠다드를 활용할 경우 이 전략이 사용됩니다.

Hub Deployment with Development in the Gateway Hub의 단점:
i. 백엔드 데이터 딕셔너리 오브젝트에 직접 접속할수 없습니다. OData 서비스 개발을 위한 데이터는 BAPI나 RFC에서만 가져올 수 있습니다.
iii. 하나의 시스템만 사용하는 embedded deployment에 비해 추가 비용과 유지 오버헤드가 있습니다.

ii. OData 서비스의 접속 URL은 어떻게 결정되는가?
이번 장에서 OData Service 테스트를 위해 티코드 /IWFND/MAINT_SERVICE에서 SAP 게이트웨이 클라이언트를 실행했습니다 (또는 직접 티코드 /IWFND/GW_CLIENT를 실행했습니다). 웹브라우저로 접속할때 입력할 URL은 어떻게 만들어지는 걸까요?

답: OData를 위한 실제 URL의 구성: http(s)://<호스트>:<서비스 포트>/(나머지는 적절한 ICF 경로).

또 질문이 생기는군요. 어떻게 SAP에서 호스트,서비스 포트, ICF 경로를 알 수 있죠?
답: 티코드 SICF로 이동합니다. 입력없이 바로 실행을 누릅니다. 메뉴에서 Goto->Port Information 을 선택합니다. 팝업창이 나오는데 여기에 호스트와 서비스 포트가 있습니다.

기본 ICF 경로를 찾기위해서는, 티코드 SICF에서 서비스 이름을 입력하고 실행합니다. 아래의 트리를 서비스 이름이 나올때 까지 다 펼칩니다. 이 예제에서는 ICF 경로는 sap->opu->odata->sap->zgw_po_srv 입니다.

이제 http, 호스트, 서비스(포트) 그리고 ICF 경로를 이어 붙입니다. 예를들어 https://txaixegd01.retail.zapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/ 이렇게 됩니다. 다음에 누군가 시스템의 호스트와 포트 정보를 알려달라고 요청한다면, 우리는 답할 수 있겠죠. 🙂

다음 장: OData and SAP Netweaver Gateway. Part III. Query Options in OData Service URI

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

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 비지니스 데이터 연결 서비스를 제공합니다.

클라이언트 측(외부)과 서버 측(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를 사용할때 비용도 들지 않고 라이센스 문제도 없습니다.

참고: Microsoft 가 OData의 원조 입니다. 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에서 부터 동일한 데이터를 가져가는데도 여러 단말마다 각각의 인터페이스를 만들어 쓰고 있습니다.

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

1대1 독립적 연결방식의 대안으로는 "하나의 데이터 모델 -> 하나의 API -> 여러 단말 지원" 방식이 있습니다. 아래 그림을 보세요. SAP 넷위버 게이트웨이에 연결된 하나의 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기반 기술입니다. REST는 REpresentational 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 의 의미는 이렇게 동일합니다.

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

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

여러 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개의 컴포넌트가 하나로 통합되었습니다.

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

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