RAP 12 - MANAGED REPORT : EML

 

목차

EML(Entity Manipulation Language)이란?

EML은 RAP모델에서 정의된 비즈니스 오브젝트(BO)를 코드로 조작(CRUD)하기 위해 SAP가 새롭게 제공하는 ABAP 전용 문법입니다. Classic ABAP에서는 DB 테이블을 컨트롤할때 SELECT, UPDATE, INSERT, DELETE 구문을 사용하고 표준로직을 처리할때  BAPI, Function, Class Method 등을 사용하여 처리했습니다. 하지만 RAP 아키텍쳐에서는 모든 데이터가 CDS View와 Behavior Definition이라는 비즈니스 오브젝트 단위로 이루어져 있습니다. 이제 개발자가 DB테이블을 직접 UPDATE하거나 별도의 BAPI를 호출할 필요 없이 RAP BO엔진에게 직접 명령을 내리는 전용 표준언어가 필요해졌고 그것이 바로 EML입니다.

 

EML의 주요 특징

1) 완벽한 트랜잭션 버퍼 및 비즈니스 로직 보장

Open SQL로 DB를 직접 고치면 Behavior Definition에 정의된 검증로직(Validation), 권한체크(Authorization), 채번(Numbering) 등을 모두 우회하게 되어 데이터가 꼬일 가능성이 있습니다. 하지만 EML을 사용하면 Behavior Definition에 구현된 모든 비즈니스 규칙과 Draft 버퍼 엔진을 완벽하게 태우면서 안전하게 데이터를 조작합니다.

 

2) 직관적이고 강력한 구문(READ / MODIFY ENTITY)

문법형태가 Open SQL과 매우 유사하여 ABAP개발자가 적응하기 쉽습니다.

READ ENTITIES : BO 데이터를 읽어옴(Draft 버퍼 포함)

MODIFY ENTITIES : BO 데이터 생성(Create), 수정(Update), 삭제(Delete), 액션(Excute) 실행

 

3) 3대 응답 구조체

EML구문을 실행하면 결과를 세가지 표준 구조체로 받아 처리합니다.

MAPPED : 새로 생성되거나 변경된 인스턴스 정보(임시 ID 매핑등)

FAILED : 처리에 실패한 인스턴스 Key 정보

REPORTED : 에러/경고 메시지 정보

 

그러면 실습을 해보면서 좀더 학습해 보도록 하겠습니다. 실습을 하기위한 Class를 하나 생성하겠습니다.

 

 

개발 Package 에 마우스 우클릭 후 New -> ABAP Class 를 클릭합니다.

 

 

Class Name과 Description을 입력하고 Next 버튼을 클릭합니다.

 

 

Class가 생성되면 아래와 같이 IF_OO_ADT_CLASSRUN 인터페이스를 추가해 줍니다. 자 이제 EML 실습을 위한 준비는 다 됐습니다.

 

 

READ ENTITY - Short Form

가장 간단한 READ ENTITY 구문입니다. READ ENTITY 다음에 View Entity 이름을 적어주면 됩니다. FROM VALUE 에는 내가 읽고싶은 Key 조건을 넣어주면 됩니다. 테이블 형식으로 넘겨줘야 합니다. 만약 Travel ID 4번도 같이 조회하고 싶을때는

VALUE #( ( TravelId = '00000003' ) ( TravelId = '00000004' ) ) 이렇게 넣어주면 됩니다. 실행 후에 결과값은 RESULT로 반환되고 만약 에러가 발생하면 그럼 F9번을 눌러 실행을 해보겠습니다.

READ ENTITY zever_m_travel_i
FROM VALUE #( ( TravelId = '00000003' ) )
RESULT DATA(lt_result)
FAILED DATA(lt_failed)
REPORTED DATA(lt_reported).

IF lt_result IS INITIAL.
  out->write( 'NO DATA' ).
ELSE.
  out->write( lt_result ).
ENDIF.

 

 

하단 Console 텝에서 결과 를 확인 할 수 있습니다. 실행하기 전에 우측 Clear Console 버튼을 눌러 Clear를 먼저 합니다. 결과를 보면 Key값인 Travel ID필드의 값만 들어있고 나머지 필드들은 비어 있습니다. READ할때 필드를 따로 지정하지 않아서 그렇습니다. 이번에는 필드를 지정해 보겠습니다.

 

 

아래처럼 FIELDS 구문에 필드명을 나열해 줍니다. FIELDS 구문을 사용하게 되면 "FROM VALUE" 절을 "WITH VALUE" 로 바꿔줘야 합니다. 결과를 보면 해당필드의 값을 잘 가져옵니다. 만약 모든필드를 가져오고 싶을때는 "FIELDS ( ... )" 대신 "ALL FIELDS" 를 써주면 됩니다.

 

 

이번엔 Association으로 연결괸 Booking 정보를 READ해 보겠습니다. 모든 필드를 대상으로 하겠습니다.

 

 

READ ENTITY - Long Form

이전까지는 하나의 Entity만 READ 하는 Short Form 구문이었고 이번에는 Multi Read가 가능한 Long Fomr 구문을 사용해 보겠습니다. 아래는 Long Form의 가장 간단한 구문입니다. "READ ENTITIES OF"구문 다음에는 Business Object의 Root Entity가 오게 됩니다. 그 아래에 "ENTITY"구문 다음에는 실제 데이터를 가져올 Target View이름을 입력하면 됩니다. 그 아래 나머지 구문은 Short Form과 동일합니다. 결과를 확인해 보면 Short From이랑 동일합니다.

 

 

Long Form 의 장점은 Root Entity에 속해있는 개별 Entity 여러개를 동시에 Read 할 수 있습니다. 아래와 같이 Travel 정보와 Booking 정보를 동시에 읽을 수 있습니다. Entity를 READ할 때는 모든 Key값을 조건으로 줘야 합니다. 아래에서 Booking 정보를 읽을때 TravelId 만 주고 BookingId를 안주면 값을 못가져 옵니다. READ ENTITY EML 사용시 이점을 주의해야 합니다.

 

 

MODIFY ENTITY - Short Form

CREATE

Travel 정보를 하나 생성해 보겠습니다. MODIFY ENTITY에 대한 구문은 아래와 같습니다. 생성이기 때문에 임시 Key 역할을 하는 %CID에 값을 입력해 줘야 합니다. 여기서는 임의값인 "CID"를 입력했습니다. 그리고 Key값 이외의 필드에 값을 넣어주고 %CONTROL에서는 값을 저장할 필드에 "01"을 입력해 줘야 합니다. 그런데 TravelId에는 값을 주지 않았습니다. 왜일까요? EML 구문으로 생성을 하게되면 실제 APP에서 생성할때 로직과 동일하게 작동 합니다. 즉 Early Numbering 에서 자동채번하는 로직을 타게되고 자동으로 채번이 됩니다. F9를 눌러 실행을 해보면 결과가 MAPPED를 통해서 리턴됩니다. MAPPED로 결과를 리턴하는 로직은 Early Numbering에 우리가 넣어준 로직입니다. 성공하면 COMMIT ENTITIES 를 해줍니다. 그럼 생성된 Travel 정보를 APP에서 확인해 보겠습니다.

 

 

정상적으로 생성되었습니다.

 

 

아래와 같이 두건 을 동시에 생성할 수도 있습니다. 생성시에 호출되는 Early Numbering에 디버깅을 찍고 한번 실행시켜 보겠습니다.

 

 

Earlynumbering_create Method에서 Loop이 시작하는 지점에 디버깅 포인트를 걸고 Entities 의 값이 어떻게 들어오는지 확인해 보겠습니다. MODIFY EML에서 두건을 동시에 CREATE 했기때문에 Entities 에 두건이 들어왔습니다. 여기서 다시한번 기억하고 넘어가야 할 부분이 App에서는 한건씩 Create하기 때문에 항상 한건만 들어온다 하더라도 외부에서 이런식으로 여러건을 동시에 Create 할수도 있기때문에 이점을 주의해서 로직을 구현해야 합니다.

 

 

F8을 눌러 끝까지 실행 후 결과를 보면 아래와 같이 Travel ID두건이 생성되었습니다.

 

 

APP에서도 정상적으로 조회가 됩니다.

 

 

Travel 정보와 그 하위의 Booking정보를 동시에 생성할 수도 있습니다. 아래와 같이 입력하고 실행해 보면 Travel ID "4217"과 Booking Number "0010"이 생성되었습니다.

 

 

APP을 실행해서 확인해 보겠습니다. 정상적으로 생성되었습니다.

 

 

 

DELETE

이번에는 조금전 생성했던 Travel ID "4217"을 삭제해 보겠습니다. Travel 정보와 Booking정보는 부모/자식 관계로 연결되어 있기 때문에 Travel 정보만 삭제해도 Booking정보도 함께 삭제됩니다. 아래와 같이 입력하고 실행해 보겠습니다.

 

 

APP을 실행해서 조회해보면 검색이 안됩니다. DB를 확인해 봐도 정상적으로 삭제가 되었습니다.

 

 

 

UPDATE

이번에는 업데이트를 해보겠습니다. Travel ID "4215"의 Agency ID와 Customer ID 값을 Update 해보겠습니다.

 

 

아래와 같이 입력하고 실행해 보겠습니다.

 

 

APP에서 확인해 보면 정상적으로 Update 되었습니다.

 

 

 

MODIFY ENTITY - Long Form

Modify Entity EML의 경우에도 Read Entity EML과 마찬가지로 Long Form 이 존재합니다. 구문도 거의 비슷하고 여러건의 CREATE, UPDATE, DELETE 구문을 동시에 수행할때 사용합니다. 물론 한건만 처리하는 경우에도 Long From을 사용해도 됩니다. 이번에는 위에서 UPDATE 시 사용했던 Travel ID "4215"에 대해서 날짜를 다른 값으로 Update 해보고 새로운 Travel 정보를 Create 해보겠습니다.

MODIFY ENTITIES OF 뒤에는 Root Entity 를 입력해 주고 그 하위에 실제로 처리할 Entity명을 입력해 줍니다. 아래와 같이 입력하고 실행합니다. 결과 Console 창을 보면 Travel ID "4218"을 생성했다고 나옵니다. APP으로 가서 Create와 Update 가 정상적으로 되었는지 확인해 보겠습니다.

 

 

Travel ID "4215"에 대해서 날짜정보가 정상 Update 되었습니다.

 

 

Travel ID "4218"도 정상적으로 생성 되었습니다.

 

 

 

EML은 RAP개발시 자주 사용하는 문법이기 때문에 익숙해 지기 전까지는 잘 정리된 문서가 있으면 매우 유용합니다. 본인만의 문서를 만들어서 실제 개발시에 잘 활용하시기 바랍니다.