이글은 아래 링크의 원본 글에 대한 한글 번역 입니다
https://www.zapyard.com/odata-and-sap-netweaver-gateway-part-ii-create-your-first-odata-service/
OData and SAP Netweaver Gateway. Part II. Create your first OData Service
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/
'ABAP > OData' 카테고리의 다른 글
| [번역] OData 와 SAP 넷위버 게이트웨이. 제 1장. 소개 (0) | 2017.07.07 |
|---|