VALUE문은 NEW SYNTAX의 핵심 중의 핵심이라고 할 수 있다.

누군가 나에게 실무에서 가장 많이 본 NEW SYNTAX가 뭐냐고 물어본다면, 

나는 고민도 없이 VALUE 였다고 말할 것 같다. 기존에 APPEND와 INSERT의 기능과 여러 타입의 변수에 값을 할당 하는 기능을 한다. 

긴 코드를 간략하게 바꿀 수 있다는 것이 개발자에게 정말 편한 구문이다. 그만큼 가독성이 좋아 유지보수가 더 쉬워진다. 

얼마나 편하길래? 라는 궁금증이 들 수도 있으니, 아래 내가 경험한 코드를 봐보자.

가장 먼저 내가 SYNC 교육 과정을 하면서 했었던 방법이다. 물론 예시이기 때문에 4건의 데이터 밖에 없지만 실제로 6개 이상 노가다 하면서 썼었다. 이게 은근 정말 귀찮다. 

기존의 ECC 버전에서 많이 볼 수 있는 방법이다. 물론 해당 코드가 문제가 있다는 것이 아니다. 

어떤 사람은 이게 더 가독성이 좋다고 이야기할 수 도 있다. 

이 코드에 VALUE 문법을 사용하면 어떻게 될까? 

Old Syntax의 30줄 길이의 GT_FCAT이 단 4줄의 코드로 줄어든다. 

무엇보다 한줄이 하나의 데이터처럼 보여, 4건의 스트럭쳐를 테이블에 넣었구나를 빠르게 확인할 수 있다. 

테이블의 필드도 가로로 정렬되서 보기도 편하다. 

이정도면은 충분히 가독성의 차이를 느꼈을테니, 자세히 이야기를 해보자 .

# VALUE

VALUE는 간단하게 ECC 버전의 ‘=’ 코드를 쉽게 만들어준다고 생각하면 된다. 그로인해 개발자는 불필요한 변수 선언과 가독성 있는 코드를 짤 수 있다. 

내가 찾아보고 직접 해본 결과 VALUE는 아래 4가지로 설명할 수 있을 거 같다.

1. VALUE 구문
2. 스트럭쳐의 값 넣기
3. 테이블의 값 넣기
4. 변수의 값 넣기

그래서 해당 목차대로 하나씩 이야기해보려 한다.

1. VALUE 구문 

VALUE는 아래와 같은 구문들을 쓸 수 있다.

1. VALUE #
2. VALUE TYPE
3. VALUE ~ BASE
4. VALUE ~ OPTIONAL

1-1. VALUE # 이란? 

내가 VALUE를 처음 만난건 SYNC 교육 과정을 듣기도 전에 SAP JOY에서 NEW SYNTAX 세미나를 시청했을 때 였다.

‘#’ 표현이 들어가면서 VALUE 구문을 굉장히 어렵게 느껴졌고 더군다나 비전공자였던 나에게 괴리감이 있었다.

VALUE의 ‘#’은 쉽게 설명하기 위해서는 인라인 선언이라고 생각하면 쉽고 그냥 TYPE 의 또 다른 표현이라고 생각하자.

# 을 쓰면 TYPE을 써주지 않아도 알아서 앞의 변수를 참고해서 TYPE을 받는다.

정확하게는 VALUE [ Type ] 이 문법이다. 할당할 변수의 TYPE을 받겠다는 것을 #으로 표현한다. . 

아래의 예시를 봐보자. 

우리는 여기서 LS_SCARR을 인라인 선언하면서 GT_SCARR의 타입을 그대로 받아온다는 것을 알고 있다.

그거랑 똑같다. 할당 받을 데이터의 타입을 그대로 참조한다.

VALUE #도 똑같다. 

자동적으로 SCARR 타입을 받는다. 사람들은 대부분 편하니 #을 많이 사용한다.

하지만! 중요한 점이 있다. 

만약에 VALUE 뒤에 지정해줄 수 있는 TYPE이 존재한다면, #을 써주는 것보다 TYPE을 명시해주는 것이 퍼포먼스에 좋다.  그게 바로 2번 내용의 VALUE TYPE이다.

1-2. VALUE TYPE 이란? 

말 그대로 TYPE을 지정해 주는 것이다.  퍼포먼스의 차이를 알아보자. 

예를들어 1번과 2번의 구문이 존재한다. 

데이터가 수십만 건이 존재한다면 2번 방법이 퍼포먼스 적으로 유리하다. ( 대부분의 회사는 수십만건의 데이터는 가볍게 가지고 있다...! )

왜냐하면,  #을 써주는 순간 SAP 시스템 상에서 GS_SCARR의 타입을 확인하기 위한 과정이 생겨버린다. 

해당 과정을 보면은 

# 1번의 코드의 경우

엇? Type이 #이네? -> GS_SCARR이 뭐지?( Type 확인)  →해당 타입에 알맞게 값넣기

# 2번의 코드의 경우 

Type이 SCARR 이구나? -> 해당 타입에 알맞게 값넣기

잘 이해될 지 모르겠는데 1번의 빨간색 글씨처럼 할당할 변수의 TYPE을 확인하는 과정이 생기기 때문에, 

만약 TYPE을 입력해줄 수 있다면 입력해주는 것이 좋다. 

1-3. VALUE BASE

BASE 문은 기존 데이터를 유지하면서 데이터를 추가하는 방법이다. 한마디로 APPEND 다. 

예를 들어, 우리가 많이 쓰는 INTO 이런식의 표현은 기존에 있는 데이터를 없애고 새로운 데이터를 집어 넣는 방식이다.

기존의 데이터를 유지하면서 데이터를 추가하는 방식이다. 해당 코드처럼 GT_DATA에 이미 데이터가 존재한다면

BASE를 써서 GT_DATA의 기존 데이터를 데이터를 유지하고~ 이 값을 넣어~~ 라는 식의 표현이 될 수 있다.

1-4. VALUE OPIONAL

이거는 이전의 READ TABLE 할 때, 했던 내용이랑 똑같다. 덤프 관련의 내용이다.

OPTIONAL은 특정 조건에 데이터가 없어도 덤프를 안나게 막아준다.

* 해당 게시글에 자세하게 나와있다.

2025.03.07 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX #2 - 테이블 표현식(Table Expressions)

아래와 같은 상황이 존재한다. 

만약 이 과정에서 GT_DATA의 1번 INDEX가 존재하지 않는다. 라고 가정해보자. 

그러면 OLD 구문은 덤프가 나지 않고 SY-SUBRC 4로 떨어지면서 넘어간다.

하지만 VALUE 구문은 바로 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors가 생긴다.

이런 경우에는 OPTIONAL을 사용해주거나 Try Catch을 사용해야 덤프가 안난다. 데이터가 존재할 수도 있고 안할 수도 있다면 OPTIONAL을 추가해서 덤프를 나지 않도록 방지해주자. 

2. 변수에 값 할당

기존의 OLD 방식으로 하는 방법을 NEW 방법으로 사용이 가능하다.

3. Structure에 값 할당

스트럭쳐에 하나씩 값을 넣을 때는 아래와 같이 사용하면 된다. 

조건에 맞는 테이블의 ROW를 INTO 하는 상황.

4. TABLE에 값 할당

코드길이를 줄이는 것은 물론 가독성까지 좋게 만들 수 있다.

해당 사진들은 모두 다 #으로 표기했지만, 

실제 상황에서는 꼭 TYPE을 써주는 것 잊지 말자!! 

오늘도 파이팅! 

CONV란?

CONV 연산자는 데이터 타입을 변환하는데 사용된다.

한 타입의 변수를 다른 타입으로 변환할 수 있다.

CONV type( [let_exp] dobj )  형식으로 사용되며, 아래와 같이 사용할 수 있다.

CONV #(     

CONV I(       

 CONV STRING(

내가 느낀 것은 인라인 선언과 함께 사용할 때나, CLASS 나 FUNCTION의 파라미터를 입력할 때 편하다고 느꼈다.

예제를 통해서 하나씩 봐보자.

1. TYPE 변환

두 가지 타입이 다른 경우가 있다.

LV_VALUE는 TYPE C 이고 LV_INT는 TYPE I 이다.

CONV 연산자는 데이터의 TYPE을 변환해준다. 

해당 코드는 LV_VALUE의 값을  TYPE 'I' 로 변환해 LV_INT에 할당하라는 코드이다. 

실제 프로그램에서는 CHAR 와 INT 타입은 SAP 스탠다드 설정으로 자동 변환되어 CONV를 사용하지 않아도 정상적으로 실행된다. 

저렇게 사용한다는 것만 참고하자.

2. FUNCTION 에서 사용

- CONV는 TYPE 변환 연산자라고 했다. 우리가 TYPE 변환을 많이 사용하는 FUNCTION MODULE에서의 사용법이다.

해당 FUNCTION은 DAY_IN이라는 파라미터가 날짜타입이다. 우리는 여기에 문자형을 넣을거다.

그러면 당연히 파라미터와 TYPE이 맞지 않아 덤프가 뜰거다.

위의 코드는 TYPE 불일치로 덤프가 나오는 코드이다. 

나는 과거에 교육 과정 프로젝트에서 TYPE 생각을 안하다가 덤프를 마주한적이 간혹 있었다.

Function Module의 파라미터와 변수가 TYPE이 맞지 않아 덤프가 뜬다. 

이럴 때마다 나는 해당 TYPE에 맞는 변수를 새로 생성해주고 TYPE을 변환시켰었다. (근데 이게 은근 귀찮다....)

하지만 이제는! CONV를 써서 간편하게 TYPE을 변환할 수 있다. 

CONV 연산자를 사용해 LV_VALUE를 TYPE D로 변환하는 코드이다. 

근데 여기서도 한가지 의문이 생겼다. 

대부분 CONV 연산자에 예시로 TYPE I, TYPE STRING 등만 있어서

CONV SFLIFHT-FLDATE (LV_VALUE) 처럼 TABLE의 필드도 사용되는지 궁금했다.

정상적으로 프로그램이 실행되고 LV_VALUE가 BKPF 테이블의 BLDAT TYPE으로 변환된다. 

3. CLASS

만약에 아래와 같은 클래스가 있다고 치자.

I_INT1과 I_INT2는 I 타입이다.

만약 LV_F가 F 타입이기 때문에 CONV 없이 그냥 들어간다면 FUNCTION 때 처럼 덤프가 발생할 거다.

하지만 CONV # 을 사용하면은 CLASS의 파라미터 타입으로 변환되어 덤프가 뜨지 않는다.

그러면 여기서 CLASS의 CONV # 과 FUNCTION의 CONV랑 차이가 궁금할거다.

CONV #

• CLASS에서만 사용 가능
• 자동적으로 파라미터의 TYPE을 받아준다 ( VALUE # 과 동일 )

CONV TYPE

• Function 에서 사용 시, CONV 뒤에 타입을 꼭 지정해줘야 한다. (CONV # 불가능 )
• TABLE의 Field로도 TYPE을 받을 수 있다. 

만약에 왜 CLASS에서는 #이되고, Function에서는 #이 안되는 지 궁금하다면, 

내가 이전의 데이터 인라인 선언 게시글에 정리하였으니, 그거를 참고하면 된다!

# 데이터 인라신 선언 포스팅 참고! 

2025.03.05 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX # - 데이터 인라인 선언( Inline Declarations )

4. 응용 방법

1)  TABLE의 라인 수를 이용하여, 메세지 출력 또는 TITLE 에 사용

2) CLASS에서 사용 

해당 응용 방법 말고도 많은 방법이 존재하니, 잘 활용하기를 바란다.

오늘도 파이팅 입니다. :)

오늘은 NEW SYNTAX의 2번째 Table Expressions, 테이블 표현식이다! 

READ TABLE을 대체할 수 있는 신 문법으로, 내부 테이블이나 표준 테이블의 특정 행에 직접 접근할 수 있다.

기존에 없었던 새로운 접근 방식으로, 개발자가 코드를 더 간결하고 읽기 쉽게 만들 수 있도록 돕는다.

지난 포스팅에서 정리한 데이터 인라인 선언 방식을 적용하여, 함께 사용한다면 코드가 더 간결해 질 수 있다.

# 데이터 인라신 선언은 이전 포스팅 참고! 

2025.03.05 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX # - 데이터 인라인 선언( Inline Declarations )

일단은 늘 하던대로, 얼마나 간결해지는 지 예시부터 보자. 

READ TABLE은 SAP 개발을 하면서 많이 쓰는 구문 중의 하나이다. 우리가 자주 쓰는 구문이 사진의 NEW SYNTAX처럼 사용을 할 수 있다. 기존의 4줄의 코드는 데이터 인라인 선언과 테이블 표현식을 사용하여 1줄이 되었다. 

테이블 표현식의 코드를 해석하면 LV_CARRID2를 만들고, GT_DATA 테이블의 1번 INDEX(첫줄)를 찾고 1번 INDEX의 CARRID 값을 넣어라! 가 된다. 이런식으로 간결하게 표현할 수 있는게 큰 장점이다.

해당 예시는 여러가지 경우에서 변수에 값을 넣는 부분이지만 내가 공부하면서 느낀 거는 다양한 코드들을 정말 간결하게 표현할 수 있는 것 같다. 

하지만,

이 테이블 표현식을 사용하려면 우리는 아래의 2가지 사항을 정확하게 숙지해야 한다. 

1. 값을 할당할 때, 테이블에 데이터가 존재하지 않으면 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors(덤프)가 발생한다.
2. SY-SUBRC 는 존재하지 않는다. 데이터가 들어가도 SY-SUBRC 는 4 값을 가진다.

자세한 내용은 아래에서 예시와 함께 보자.

1. READ TABLE INDEX

처음 예시랑 똑같은 내용이다.

테이블에 데이터를 스트럭쳐로 옮기는 경우 해당 코드를 작성할 수 있다.

하지만!! 가장 중요한 사항은 해당 INDEX에 대한 데이터가 존재하지 않으면 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors(덤프)가 생긴다.

테이블 표현식은 데이터가 존재하지 않는다면 무조건 덤프를 낸다. 

"근데 우리가 개발하다 보면은 TABLE에 데이터가 존재할 수도 있고, 없을 수도 있는데 그런 상황에서는 쓰지 못할까? "

그래서 열심히 구글링과 SAP docu을 찾아봤다. 

역시 해결 방법이 존재했었다. 

1) TRY-CATCH를 이용하여 해결하기.

해당 코드는 TRY-CATCH를 이용해 데이터가 없을 경우, CATCH 로 빠지게 했다. 

프로그램을 실행시키면

덤프가 나지 않고 CATCH로 빠지게 된다. 

TRY-CATCH를 이용해 데이터가 없는 경우에 대한 로직을 작성하여 이 부분을 해결 할 수 있었다. 

그러나 만약 반복되는 코드일 경우 TRY-CATCH로 인해 가독성이 더 안좋질 수도 있다. 

그래서 두번째 방법이 존재하더라... 

2) VALUE와 OPTIONAL 이용하여 해결하기.

VALUE 구문은 NEW SYNTAX에서 핵심 중에 핵심이다. 제일 많이 본 것 같다. 

스트럭쳐와 변수에 데이터를 집어넣는 과정이다. 

OPTIONAL의 역할은 테이블에 원하는 데이터가 없을 때, CX_SY_ITAB_LINE_NOT_FOUND 예외가 발생하지 않도록 막아준다. 이녀석의 정확한 역할은 값이 있으면 넣고 없으면 패스~ 느낌인거 같다. 

그렇기 때문에 데이터가 없을 가능성이 있다면 잊지말고 항상 써줘야 한다. 

2. READ TABLE ~ WITH KEY.

WITH KEY 뒤 조건에 맞는 스트럭쳐를 테이블에서 가져오는 구문이다. 

WITH KEY를 입력하지 않고 대괄호([ ]) 사이에 해당 조건을 바로 나열해주면 된다. 

3. TRANSPORTING NO FIELDS.

우리는 원하는 조건의 데이터가 있는 지 확인하기 위해 TRANSPORTING NO FIELDS를 사용했다. 

그리고 IF SY-SUBRC를 이용해 데이터 존재 여부를 체크했었다. 

하지만 테이블 표현식을 사용할 때는 처음에 주의사항으로 이야기했던 

2. SY-SUBRC는 존재하지 않는다. 데이터가 들어가도 SY-SUBRC 는 4 값을 가진다 

이거를 기억해야 한다.

내가 직접 테스트 해본 결과, 데이터가 들어가도 이녀석들은 무조건 SY-SUBRC 4를 내뱉는다. 

그러면 같은 상황에서 데이터 핸들링을 하려면 어떻게 해야 할까? 

그래서 테이블 표현식에서는 두 가지 키워드가 존재한다.

# LINE_EXISTS와 LINE_INDEX.

1) LINE_EXISTS.

LINE_EXISTS는 조건에 맞는 테이블의 데이터 존재 여부를 확인해준다. 한마디로 ‘IF SUBRC = 0’ 이랑 같은 의미를 지낸다.

해당 조건에 DATA 여부를 확인하고, 존재하면 IF 문을 타게 된다.

2) LINE_INDEX.

LINE_INDEX는 해당 조건에 맞는 INDEX 값을 반환해준다.

인터널 테이블에 조건에 맞는 데이터가 몇번 INDEX에 있는 지 반환을 하게 된다.

기존에는 SY-TABIX로 인덱스 값을 확인했다면, 

테이블 표현식은 LINE_INDEX 키워드를 사용해서 조건에 맞는 데이터의 인덱스 값을 추출할 수 있다. 

실행 결과를 보면 CARRID가 FJ라는 데이터는 6번 INDEX에 존재하는 점을 알 수 있다. 

만약 데이터가 없는 경우는 0 값을 반환한다. 또한 INDEX가 존재할 수 없는 Hashed Table이나 Hashed Secondary Key를 사용한 경우에는 -1을 반환한다.

4. FIELD-SYMBOL ASSIGN.

필드심볼에 할당에 대한 테이블 표현식이다.

OLD 버전에서 IF조건문이 없고 데이터가 존재하지 않아도 덤프가 나지않는다. 

하지만 테이블 표현식은 데이터 없으면 가차없이! 덤프나기 때문에 무조건 IF 조건문으로 감싸줘야한다.

이렇게 반겨준다. 

25번에 데이터가 존재하지 않는 경우, 두 경우에 덤프 에러가 뜨지 않는다 .

근데 여기서 중요한 점은

SAP에서 해당 테이블 표현식을 쓸 때, IS ASSGIN 말고 SY-SUBRC를 사용하라고 권장을 한다. (SY-SUBRC 사용 못한다고 할때는 언제고…?)

이 경우에는 놀랍게도 기존에 4값만 들어오던 SY-SUBRC가 0값이 들어오게 된다........ 

이 부분에 대해서 찾아봤는데 필드 심볼의 할당은 ASSIGN을 사용하는 방법이 올바르지만, 여러 개발자의 유지보수 등을 고려하여 SY-SUBRC를 권장하는 거라고 한다. ( 어떤 개발자든 직관적으로 성공! 실패! 를 구분할 수 있다나 머라나.... ) 

# 응용

4-1. TABLE에서 데이터 변경

MODIFY로 인터널 테이블에서 값을 수정하는 과정을 간단하게 바꿀 수 있다.

NEW SYNTAX를 해석해보면 GT_SCARR테이블의 CARRID가 ‘AA’인 ROW의 CARRNAME을 ‘비행기’로 변경해라 가 될 수 있다.

다만 여기서도 해당 조건의 데이터가 없다면, ITAB_LINE_NOT_FOUND 가 반긴다는 것...

그렇기 때문에 나는 위 사진처럼 LINE_EXISTS를 사용하여 덤프를 방지 시킨다.

물론 TRY CATCH도 가능하다.

4-2. 2개의 테이블 데이터 핸들링.

GT_SCARR 의 특정 데이터의 값을 LT_DATA에 APPPEND 하는 상황이라고 가정.

둘 다 동일한 값을 가진다

4-3. F4 서치헬프 함수로 띄우는 과정에서 적용하기

실제 내가 적용했던 방법이다.

서치헬프에서 클릭한 값을 받아서 CALL FUNCTION 'DYNP_VALUES_UPDATE’에 사용하는 상황이다.

잘 참고하면 좋겠고 도움이 되었으면 좋겠다! 

올바르고 정답이 있는 코드는 없다고 생각한다. 

잘못된 코드는 있지만 올바른 코드는 없다! 각자 상황에 맞게 잘 활용하기를 바란다! 

 
SAP의 ERP 시스템은 방대한 데이터를 효율적으로 관리하는 것이 핵심이다. 기존 ABAP Old SYNTAX는 오랫동안 사용되어 왔지만, 대량의 데이터를 처리할 때 성능 문제와 제한 사항이 존재했었다. 그러한 이유로 비효율적인 구문을 ABAP개발자들 사이에서 공유하고 암묵적으로 사용하지 않았었다. SAP는 이러한 한계를 극복하고 최신 데이터베이스 기술을 반영하기 위해 ABAP New SYNTAX 를 도입하였다.
 
또한, SAP HANA DB로 전환되면서 데이터 연산을 데이터베이스 레벨에서 실행하는 'Push Down' 개념이 중요해졌다. 이를 통해 어플리케이션 서버의 부담을 줄이고 성능을 극대화할 수 있다.
 
하지만,
이 글의 목적은 무조건 'NEW SYNTAX가 최고야! ' 가 아니다. NEW SYNTAX에서도 단점이라고 하기에는 애매하지만 문제점(?)이 존재할 수 있다. 내가 신입으로 입사하고 NEW SYNTAX 공부를 하면서 느낀 장점과 문제점을 공유해보겠다. 
 

 내가 생각하는 New Syntax의 장점 

1. 코드 간결화 

- 데이터 인라인 선언 등으로 인해 코드가 많이 간소화되고 기존의 여러줄을 써야 하는 코드들을 한 줄로 해결할 수 있는 문법들이 많다. 
 
잠깐 아래 예시를 봐보면 코드 간결화가 이해될거다. 
해당 코드는 ALV의 FCAT에 값을 넣는 상황이다. 

OLD SYNTAX에서 GT_FCAT 테이블에 값을 넣는 코드 길이는 30줄이다. 

NEW SYNTAX는 단 5줄로 끝난다. 저기서 사용한 VALUE 구문이 NEW SYNTAX 에서 가장 많이 사용되는 구문 같다

결과는 동일하다. 

2.  개발자의 편의성 

- SAP가 ABAP 개발자의 편의성을 얼마나 중요시 생각했는지 알게 된다. 기존에 타입을 맞춰서 데이터 핸들링 등을 하는 번거로움 없이 인라인 선언으로  해당 타입을 자동적으로 읽어 알맞게 생성해준다.
 

3.  직관성  

- New Syntax 구문을 알고 있는 사람이 해당 코드를 보면은 정말 직관적으로 볼 수 있다. 위의 예시만 봐도 VALUE 구문을 이용해서 한눈에 알아볼 수 있게 코드가 짜여져있다. 
 

 내가 생각하는 New Syntax의 단점 

1.  코드의 복잡성  

- 장점에서는 직관적이고 간결하다고 했는데 갑자기 복잡성?! 이럴 수 있다. 이거는 내가 느낀 주관적인 사항이니 참고만 하면 좋을 것 같다. New Syntax 구문에 대한 지식이 없으면 더 복잡하게 느껴진다.
 
예제1) 
너무나 당연한 이야기지만 내가 처음 NEW SYNTAX은 VALUE 였고 구문에 대한 이해가 없으니 더 어렵게 느껴졌다. 

 
지금은 VALUE 구문을 알기에 어렵게 느껴지지 않지만 처음에는 큰 괴리감이 느껴졌다. 
한줄씩 뜯어서 해석하는데 오래 걸리기도 했다. 
 
그렇기 때문에 오히려 신문법을 배운 세대와 그렇지 않은 세대들이 거리감을 느낄 것 같다는 생각이 들었다.  
 

 내가 내린 결론 : Old Syntax와 New Syntax의 선택 

나는 한 가지 궁금증이 있었다.

'New Syntax가 SAP에서 성능을 위해서 개발한 신문법인데 모두 이거를 사용해야 하는거 아냐?' 라는 생각을 가지고 이곳 저곳을 찾아본 결과 답은 상황 BY 상황, 회사 BY 회사 였다. 최종적으로 내용을 정리해보면서 아래와 같은 결론이 나왔다. 

1. 개발자가 개발하기는 정말 편해진 것 맞다. 
2. 하지만 NEW SYNTAX 잘못 사용할 경우 코드가 더 복잡해질 수 있다.  
3. 신입 개발자(신문법 시대) 와 시니어 개발자(구문법 시대) 사이의 괴리감이 존재할 수 밖에 없다. 
4. 정답은 없다. ABAP 7.0 이전일 경우는 Old Syntax를 사용해야만 HANA일때는 NEW 선택해도 된다.
5. 본인이 특히 운영업무라면, 두 가지 방법 다 알 고 있는 것이 도움이 된다. 

결국은 본인이 성장하면서 직접 깨닫고 본인만의 개발 방법을 찾아야 하는 것 같다.! 무엇보다 많이 알고 있어서 손해볼 거는 없는 것 같다. 
 
 New Syntax의 첫 포스팅이기에 서론이 정말 길었지만.....
이제 이번 주제였던 데이터 인라인 선언에 대해 간략하게 정리해보겠다. 
 

 데이터 인라인 선언 

1.  변수 선언

- 기존에는 데이터 선언과 값을 할당하는 로직으로 2줄 이상의 코드가 필요했지만, 인라인 선언이 가능해지면서
  선언부에 대한 불필요한 로직을 줄이고, 선언과 값 할당을 동시에 할 수 있다.

2-1.  LOOP문에서 DATA 선언

- 개발을 하다보면은 LOOP를 돌려야 하는 순간을 많다. 여러 테이블을 LOOP 해야 한다면 DATA 선언부에 스트럭쳐를 모두 생성해야 했지만 이제는 ‘DATA(스트럭쳐명)’ 으로 선언이 가능하다.

위와 같은 데이터가 있는 상태에서 아래와 같은 방법으로 선언이 가능하다. 

2-2.  LOOP문에서 FIELD-SYMBOL 선언

- 필드심볼도 인라인 선언이 가능하다. 
 

 
필드심볼을 따로 선언하지 않고 바로 할당 가능하다. 
타입은 자동적으로 GT_ITAB에 맞춰진다. 
 

3.  SELECT문에서 DATA 선언

- 단, SELECT 문에서 인라인 선언시에는 New SQL 방식으로 입력해줘야한다. 
- 변수에는 @ 기호를 추가해야 되고, 필드명은 컴마(,)로 구분해줘야 한다. 

4.-1   READ TABLE에서 DATA 선언

4-2.  READ TABLE에서 FIELD-SYMBOL 선언

5.   METHOD에서 DATA 선언

- 메서드를 호출할 때, 실제 매개변수(Actual Parameter)는 형식 매개변수(Formal Parameter)와 타입이 일치해야 한다. 하지만 메서드의 형식 매개변수가 변경될 경우, 기존 방식에서는 관련된 모든 변수 선언을 수정해야 하는 번거로움이 있었다. 인라인 선언을 하면은 쉽게 해결 가능하다. 

이렇게 인라인 선언을 정리해보았다. 참고해서 사용하면 좋을 것 같다. 물론 내가 보려고 정리했다~ 나처럼 필요한 사람이 있을 수 있으니까~
 
마지막으로 인라인 선언을 찾아보면서 METHOD에서 인라인 선언 방식이 굉장히 편해보였다. 그래서 Function Module에서는 불가능한가? 라는 호기심에 찾아봤다. 
 

# Function Module은 인라인 선언이 안될까? 

결론부터 말하면, 불가능하다. 

나는 비전공자이다보니, 처음에는 왜 안되는 지 이해할 수 없었다. 하지만 Function Module과 Method의 개념과 차이를 알고나니 쉽게 이해되었다. ( 전공자들은 부럽다... )  
 

1) 함수 모듈과 Method의 차이

ㅁ Method 호출 구조

메서드는 클래스(Class) 내부에 정의되며, 객체 지향 프로그래밍(OOP) 방식으로 동작된다.

• 컴파일러가 메서드 시그니처(Method Signature, 즉 매개변수 타입 정보)를 정확히 알고 있음
• 메서드 호출 시점에 인라인 선언된 변수의 타입을 자동 유추 가능
• 이 때문에 CALL METHOD 구문에서는 DATA(...) 인라인 선언이 가능

 
메서드는 클래스 내부에서 정의되기 때문에, 컴파일러는 클래스를 직접 참조해서 메서드의 매개변수 타입을 확인할 수 있다. 그래서 P1의 타입을 보고, lv_p1의 타입을 자동으로 설정할 수 있다. 
 

ㅁ 함수 모듈(Function Module) 호출 구조

함수 모듈(CALL FUNCTION)은 컴파일 타임(코드 작성 시점)이 아니라 런타임(실행 시점)에 호출된다.

즉, 컴파일러가 함수 모듈 내부에서 P1이 어떤 타입인지 미리 알 수 없기 때문에, DATA(...)를 사용할 수 없는 거다.

해당 코드는 다음과 같은 에러 메세지가 뜬다. 

함수 모듈은 실행되기 전까지 ev_result의 타입이 무엇인지 확실하지 않으므로 인라인 선언이 불가능하다.
 

2) 함수 모듈의 실행 방식

함수 모듈은 "디스크에서 로드 → 실행 → 언로드" 과정이 필요하며, 이는 메서드와 다른 점이다. 차이는 다음과 같다. 

ㅁ 메서드(Method) 호출:

• 이미 메모리에 로드된 클래스의 일부
• 호출 즉시 시그니처를 참조하여 타입을 결정할 수 있음

ㅁ 함수 모듈(Function Module) 호출:

• 독립적인 실행 환경을 가짐
• 호출될 때 완전히 별개의 프로그램처럼 실행됨
• 함수 모듈 내부에서 정의된 IMPORTING/EXPORTING 매개변수의 타입 정보를 호출부에서 즉시 활용할 수 없음

이런 구조적 차이로 인해, 함수 모듈에서는 CALL FUNCTION 구문 안에서 새로운 변수를 인라인으로 선언할 수 없는 것이다.
 

3) SAP의 기술적 방향성과 함수 모듈의 역할

SAP은 ABAP OO(Object-Oriented ABAP)를 적극적으로 지원하며, 새로운 기능(인라인 선언, 테이블 표현식 등)은 클래스 및 메서드 중심의 구조에 맞춰 발전되고 있다고 한다.( 그렇대요.. )

• 함수 모듈은 RFC(Remote Function Call), BAPI 등에서 여전히 중요한 역할을 하지만, 새로운 기능과의 호환성이 제한적
• SAP도 클래스 기반 개발을 권장하고 있으며, 함수 모듈보다 클래스를 활용하는 것이 유지보수성 측면에서 유리

다음과 같은 이유로 Function Module에서는 인라인 선언이 불가능하다고 한다. 
혹시나 나와 같은 비전공자로서 궁금증이 있는 사람은 도움 되기를 바란다!! 
 
 

1. DO 루프

애는 계속 무한반복을 하게 된다. 그래서 IF 문을 사용해서 EXIT를 사용해 빠져나올 수 있게 해줘야 한다. 특정 조건에 만족하면 해당 루프를 빠져 나오게끔 처리해줘야한다.

대부분 그거를 IF로 조건이 맞으면 빠져나와 라는 구문을 써준다.

abap코드 복사
DO.
  Statements
  IF <abort_condition>. 
  EXIT. 
  ENDIF.
ENDDO.

• 설명: DO ... ENDDO 구조는 무한 루프입니다. EXIT 문을 사용하여 특정 조건(<abort_condition>)이 만족되면 루프를 빠져나갑니다.
• Loop Counter: sy-index 시스템 변수가 루프의 반복 횟수를 카운트합니다.

2. DO n TIMES 루프

n 자리에 반복하고자 하는 숫자 또는 변수를 입력한다. 그러면 n번만큼 반복하게 된다.

abap코드 복사
DO n TIMES.
  Statements
ENDDO.

• 설명: 루프를 n번 반복합니다.
• Loop Counter: sy-index 시스템 변수가 루프의 반복 횟수를 카운트합니다.

3. WHILE 루프

while - endwhile

조건이 참이면 반복을 하고 거짓이면 반복 중단을 한다.

abap코드 복사
WHILE <condition>.
  Statements
ENDWHILE.

• 설명: 주어진 조건이 참(true)인 동안 루프를 반복합니다.
• Loop Counter: sy-index 시스템 변수가 루프의 반복 횟수를 카운트합니다.

4. SELECT ... ENDSELECT 루프

abap코드 복사
SELECT ... FROM <dbtab> ...
  Statements
ENDSELECT.

• 설명: 데이터베이스 테이블에서 데이터를 선택하여 각 행에 대해 루프를 실행합니다.
• Database Table Rows: sy-dbcnt 시스템 변수가 선택된 행(row)의 수를 카운트합니다.

5. LOOP AT <internal table> ... ENDLOOP

abap코드 복사
LOOP AT <internal table> ...
  Statements
ENDLOOP.

• 설명: 내부 테이블의 각 행에 대해 루프를 실행합니다.
• Row Index for Internal Table: sy-tabix 시스템 변수가 내부 테이블에서 현재 행(row)의 인덱스를 나타냅니다.

정리 

• DO 루프: 무한 루프. EXIT를 사용해 조건을 만족할 때 빠져나옵니다. 루프 횟수는 sy-index로 카운트.
• DO n TIMES 루프: n번 반복하는 루프. 루프 횟수는 sy-index로 카운트.
• WHILE 루프: 조건이 참인 동안 반복하는 루프. 루프 횟수는 sy-index로 카운트.
• SELECT ... ENDSELECT 루프: 데이터베이스 테이블의 각 행에 대해 반복. 선택된 행의 수는 sy-dbcnt로 카운트.
• LOOP AT <internal table> ... ENDLOOP: 내부 테이블의 각 행에 대해 반복. 현재 행의 인덱스는 sy-tabix로 나타냅니다.

SAP ABAP 트랜잭션 코드 표

구분트랜잭션 코드설명

각 트랜잭션 코드 설명

1. SE80 - 오브젝트 네비게이터 (Object Navigator)
   • SE80은 ABAP 개발 환경에서 객체를 관리하고 탐색하는 주요 도구입니다. 이 트랜잭션을 통해 프로그램, 함수 그룹, 클래스, 패키지 등 다양한 객체를 생성, 수정, 삭제할 수 있습니다.
2. SE16 - 데이터 브라우저 (Data Browser)
   • SE16은 데이터베이스 테이블의 내용을 조회할 수 있는 트랜잭션 코드입니다. 특정 조건에 맞는 데이터를 검색하거나 테이블의 전체 내용을 확인할 수 있습니다.
3. SE16N - 일반 테이블 조회 (General Table Display)
   • SE16N은 SE16의 향상된 버전으로, 더 직관적인 인터페이스와 추가 기능을 제공합니다. 데이터를 조회하고 편집할 수 있으며, 빠른 데이터 검색을 지원합니다.
4. SE09 - 전송 조직자 (Transport Organizer)
   • SE09는 전송 요청(Transport Request)을 관리하는 트랜잭션 코드입니다. 개발 변경 사항을 다른 시스템으로 이동할 때 사용하는 전송 요청을 생성하고 추적할 수 있습니다.
5. BAPI - BAPI 탐색기 (BAPI Explorer)
   • BAPI(Business Application Programming Interface)는 비즈니스 객체를 SAP 시스템에서 호출할 수 있는 인터페이스입니다. BAPI 탐색기를 통해 다양한 BAPI를 검색하고 테스트할 수 있습니다.
6. SE11 - ABAP 딕셔너리 (ABAP Dictionary)
   • SE11은 데이터 사전을 관리하는 트랜잭션 코드입니다. 여기서 테이블, 뷰, 데이터 요소, 도메인 등 데이터베이스 객체를 생성하고 수정할 수 있습니다.
7. SE38 - ABAP 편집기 (ABAP Editor)
   • SE38은 ABAP 프로그램을 작성하고 수정할 수 있는 트랜잭션 코드입니다. 프로그램 소스 코드를 편집하고 디버깅할 수 있습니다.
8. SE37 - 기능 작성기 (Function Builder)
   • SE37은 함수 모듈을 관리하는 트랜잭션 코드입니다. 새로운 함수 모듈을 생성하고, 기존 함수 모듈을 수정 및 테스트할 수 있습니다.
9. SE24 - 클래스 작성기 (Class Builder)
   • SE24는 ABAP 클래스와 인터페이스를 관리하는 트랜잭션 코드입니다. 객체 지향 프로그래밍을 지원하며, 클래스와 메서드를 생성하고 수정할 수 있습니다.
10. SE91 - 메시지 (Message Maintenance)
    • SE91은 메시지 클래스를 관리하는 트랜잭션 코드입니다. 메시지 클래스를 생성하고 메시지 텍스트를 정의할 수 있습니다. 이 메시지들은 프로그램에서 오류 또는 정보 메시지로 사용됩니다.
11. SE93 - 트랜잭션 (Maintain Transaction)
    • SE93은 트랜잭션 코드를 생성하고 유지보수하는 트랜잭션 코드입니다. 사용자 정의 트랜잭션 코드를 생성하여 특정 프로그램이나 기능에 접근할 수 있습니다.
12. SM21 - 시스템로그 (System Log)
    • SM21은 시스템 로그를 확인하고 분석하는 트랜잭션 코드입니다. 시스템 오류, 경고, 정보 메시지 등을 추적할 수 있습니다.
13. ST05 - Performance Trace
    • ST05는 데이터베이스 성능을 분석하기 위한 트랜잭션 코드입니다. SQL 문, 락, 버퍼 등을 추적하여 성능 문제를 진단할 수 있습니다.
14. ST22 - 덤프 분석 (ABAP Runtime Error)
    • ST22는 ABAP 프로그램 실행 중 발생한 런타임 오류(Dump)를 분석하는 트랜잭션 코드입니다. 오류 원인을 파악하고 해결책을 찾을 수 있습니다.
15. ABAPHELP - 키워드 문서 (ABAP Key Word Documentation)
    • ABAPHELP는 ABAP 언어의 키워드에 대한 문서를 제공하는 트랜잭션 코드입니다. ABAP 키워드, 문법, 사용 예제 등을 확인할 수 있습니다.
16. ABAPDOCU - 데모 (ABAP Documentation and Examples)
    • ABAPDOCU는 ABAP 프로그램의 예제와 문서를 제공하는 트랜잭션 코드입니다. 다양한 예제 프로그램을 통해 ABAP 기술을 학습할 수 있습니다.
17. SQVI - 퀵 뷰어 (Quick Viewer)
    • SQVI는 간단한 조회 보고서를 생성할 수 있는 트랜잭션 코드입니다. 사용자가 테이블과 필드를 선택하여 빠르게 데이터를 조회하고 보고서를 만들 수 있습니다.
18. SQ01, SQ02, SQ03 - SAP Query
    • SQ01, SQ02, SQ03 트랜잭션 코드는 SAP Query를 생성하고 관리하는 데 사용됩니다. SQ01은 쿼리 디자인, SQ02는 정보 세트 유지보수, SQ03은 사용자 그룹 관리를 담당합니다.

ABAP Workbench 도구

그림 설명:

이 이미지는 SAP 시스템에서 ABAP 워크벤치(ABAP Workbench) 도구들을 보여줍니다. ABAP 워크벤치는 SAP 개발자들이 다양한 개발 작업을 수행할 수 있도록 도와주는 도구 모음입니다. 각각의 도구는 특정한 기능을 가지고 있으며, 효율적인 개발 환경을 제공합니다.

주요 도구:

1. Object Navigator (객체 탐색기): SE80
   • 개발자들이 프로젝트의 모든 객체를 관리하고 탐색할 수 있는 중심 도구입니다.
   • 프로그램, 함수 모듈, 클래스 등 다양한 객체를 쉽게 찾고 열 수 있습니다.
2. ABAP Editor (ABAP 편집기): SE38
   • ABAP 코드를 작성하고 수정할 수 있는 텍스트 편집기입니다.
   • 문법 강조, 코드 포매팅, 자동 완성 기능을 제공합니다.
3. Screen Painter (스크린 페인터): SE51
   • 사용자 인터페이스를 디자인하는 도구입니다.
   • 화면 레이아웃을 설계하고, 입력 필드, 버튼 등을 배치할 수 있습니다.
4. Menu Painter (메뉴 페인터): SE41
   • 애플리케이션의 메뉴 구조를 디자인하는 도구입니다.
   • 메뉴 항목과 서브 메뉴를 생성하고 구성할 수 있습니다.
5. Function Builder (함수 빌더): SE37
   • 함수 모듈을 생성하고 관리하는 도구입니다.
   • 재사용 가능한 함수 모듈을 작성하고, 다른 프로그램에서 호출할 수 있습니다.
6. Class Builder (클래스 빌더): SE24
   • 객체 지향 프로그래밍을 위한 클래스와 인터페이스를 생성하고 관리하는 도구입니다.
   • 클래스 정의, 메서드 구현, 상속 등을 지원합니다.
7. ABAP Dictionary (ABAP 딕셔너리): SE11
   • 데이터베이스 테이블, 뷰, 데이터 요소 등을 정의하고 관리하는 도구입니다.
   • 데이터 모델링과 데이터베이스 구조를 설계할 수 있습니다.
8. Debugger (디버거):
   • 프로그램을 실행하면서 코드를 단계별로 검토하고 오류를 찾을 수 있는 도구입니다.
   • 중단점 설정, 변수 값 확인, 실행 흐름 제어 등을 지원합니다.

SAP GUI의 화면 요소

SAP GUI (Graphical User Interface)에서 사용자 프로필을 유지 관리하는 화면의 요소입니다. 각 요소는 사용자가 SAP 시스템을 보다 효율적으로 사용할 수 있도록 도와줍니다. 주요 화면 요소는 다음과 같습니다:

1. Menu Bar (메뉴 바):
   • 화면 상단에 위치하며, 파일, 편집, 보기 등의 메뉴를 제공합니다.
   • 사용자는 메뉴 바를 통해 다양한 기능에 접근할 수 있습니다.
2. System Toolbar (시스템 도구 모음):
   • 메뉴 바로 아래에 위치합니다.
   • 일반적인 시스템 기능, 예를 들어 저장, 열기, 인쇄 등의 아이콘을 포함합니다.
3. Title Bar (제목 표시줄):
   • 현재 화면의 제목이 표시됩니다.
   • 사용자가 현재 작업 중인 화면이 무엇인지 쉽게 알 수 있습니다.
4. Application Toolbar (애플리케이션 도구 모음):
   • 화면 중앙 상단에 위치하며, 현재 화면에서 사용할 수 있는 기능을 아이콘 형태로 제공합니다.
   • 특정 화면에서 자주 사용하는 기능에 빠르게 접근할 수 있습니다.
5. Command Field (명령 필드):
   • 사용자가 명령어를 직접 입력하여 특정 화면이나 기능으로 빠르게 이동할 수 있습니다.
   • 예를 들어, 트랜잭션 코드를 입력하여 특정 화면으로 이동할 수 있습니다.
6. Tab Pages (탭 페이지):
   • 여러 관련된 정보나 옵션을 탭으로 구분하여 제공합니다.
   • 사용자는 각 탭을 클릭하여 해당 페이지의 내용을 볼 수 있습니다.
7. Input Field (입력 필드):
   • 사용자가 정보를 입력할 수 있는 공간입니다.
   • 예를 들어, 이름, 전화번호 등의 정보를 입력할 수 있습니다.
8. Status Bar (상태 표시줄):
   • 화면 하단에 위치하며, 현재 시스템 상태나 작업 진행 상황을 표시합니다.
   • 에러 메시지나 확인 메시지 등 중요한 정보를 보여줍니다.

WRITE field_1 AS CHECKBOX INPUT OFF.

AS SYMBOL (심볼 형태 출력)

• 이 형식을 사용하려면 이전에 다음의 문장을 기술해야 합니다:

INCLUDE <SYMBOL>.

AS ICON (아이콘 형태 출력)

• 이 형식을 사용하려면 이전에 다음의 문장을 기술해야 합니다:

INCLUDE <ICON>.

• 이 옵션을 사용하면 SAP R/3에 정의된 아이콘을 출력할 수 있습니다.

AS LINE (선 형태 출력)

• 이 형식을 사용하려면 이전에 다음의 문장을 기술해야 합니다:

INCLUDE <LINE>.

• 이 옵션을 사용하면 SAP R/3에 정의된 선을 출력할 수 있습니다.

QUICKINFO g (빠른 정보 출력)

• 이 옵션은 흔히 말하는 툴팁(부풀림 도움말)을 제공합니다.
• 어떤 아이콘이나 위치에 마우스를 올려놓으면 g(도움말)가 나타나는 형태를 제공합니다.
• 최대 40자까지 지원하며, g는 비숫자형 변수여야 합니다.

WRITE f TO g[+off][(len)]

• f의 값을 g 변수에 이동합니다.

WRITE f TO itab[+off][(len)] INDEX idx

• 내부 테이블의 idx 번째 데이터를 대상으로 값을 이동합니다.

예제 코드

다음은 다양한 WRITE 문의 사용 예제입니다:

REPORT Z00TEST_04 NO STANDARD PAGE HEADING.

INCLUDE <LINE>.
INCLUDE <ICON>.

DATA : L_COLOR TYPE CHAR25 VALUE '색깔 테스트'.

FORMAT COLOR COL_HEADING ON.
WRITE : / L_COLOR.
FORMAT COLOR OFF.

FORMAT INVERSE ON.
WRITE : / L_COLOR.
FORMAT COLOR OFF.

FORMAT COLOR 7.
WRITE : / L_COLOR.

ULINE /1(50).
WRITE: / SY-VLINE NO-GAP, LINE_TOP_LEFT_CORNER AS LINE.
ULINE 3(48).
WRITE: / SY-VLINE NO-GAP, SY-VLINE NO-GAP.

DATA: INFO(20) VALUE 'Information'.
WRITE: / SY-UNAME QUICKINFO 'User name'.
WRITE: / ICON_INFORMATION AS ICON QUICKINFO info
HOTSPOT COLOR COL_POSITIVE.

ULINE.

DATA SALES TYPE P VALUE 146260.
WRITE SALES CURRENCY 'USD' ROUND 3 DECIMALS 1.
WRITE SALES CURRENCY 'KRW' ROUND 3 DECIMALS 1.
WRITE SALES CURRENCY 'USD' ROUND 2 DECIMALS 2.
WRITE SALES CURRENCY 'KRW' ROUND 2 DECIMALS 2.

출력 결과

SAPUI5 라이브러리와 UI 컨트롤 가이드

SAPUI5는 다양한 기기에서 반응형 웹 애플리케이션을 개발하기 위한 강력한 프레임워크입니다. SAPUI5는 다양한 용도로 모듈화된 UI 컨트롤 세트를 제공하는 라이브러리 개념을 가지고 있습니다.

SAPUI5의 주요 라이브러리와 포함된 UI 컨트롤에 대해 자세히 알아보겠습니다.

UI 컨트롤이란 무엇인가?

UI 컨트롤은 버튼, 콤보박스, 텍스트 필드, 입력 및 출력 필드, 테이블 등과 같이 사용자 인터페이스를 구성하는 기본 요소입니다. 이러한 UI 컨트롤은 SAPUI5 라이브러리에 포함되어 있으며, 다양한 애플리케이션 개발에 사용됩니다.

주요 SAPUI5 라이브러리

1. sap.m

• 설명: SAPUI5의 주요 컨트롤 라이브러리로, 반응형 컨트롤을 포함하고 있어 터치 장치 및 데스크톱 브라우저에서 모두 사용할 수 있습니다.
• 주요 특징: 가장 많이 사용되는 라이브러리로, 다양한 기기에서 일관된 사용자 경험을 제공합니다.

2. sap.ui.comp

• 설명: 스마트 컨트롤을 포함한 SAPUI5 라이브러리입니다.
• 주요 특징: 사용자가 쉽게 상호작용할 수 있는 지능형 UI 요소를 제공합니다.

3. sap.ui.table

• 설명: 주로 데스크탑 시나리오에 사용되는 테이블 형태의 컨트롤을 제공합니다.
• 주요 특징: 데스크탑에 최적화되어 있지만, 모바일 및 태블릿에서도 작동합니다. 단, 모바일이나 태블릿에서 작성된 테이블은 PC에서 작게 표시되는 문제가 있어 데스크탑 사용에 더 적합합니다.

4. sap.ui.layout

• 설명: 화면을 보기 좋게 구성하는 레이아웃 컨트롤을 포함한 라이브러리입니다.
• 주요 특징: UI 요소를 정렬하고 배치하는 데 사용됩니다.

5. sap.ui.core

• 설명: SAPUI5 Core 런타임을 포함하며, 모든 구성 요소와 기본 클래스를 포함합니다.
• 주요 특징: jQuery와 기본적으로 사용되는 UI 컨트롤을 포함하고 있으며, 가장 핵심적인 기능들이 포함되어 있습니다.

SAPUI5를 사용한 개발의 이점

반응형 디자인

SAPUI5 라이브러리는 모든 디바이스에서 일관된 사용자 경험을 제공하기 위해 반응형 디자인을 지원합니다. 이를 통해 개발자는 별도의 모바일 및 데스크탑 버전을 만들 필요 없이, 하나의 코드베이스로 다양한 기기에서 최적화된 애플리케이션을 개발할 수 있습니다.

확장성

SAPUI5는 모듈화된 구조를 가지고 있어 필요에 따라 다양한 컨트롤을 쉽게 추가하거나 제거할 수 있습니다. 이는 애플리케이션의 확장성을 높이고 유지보수를 용이하게 합니다.

강력한 데이터 바인딩

SAPUI5는 강력한 데이터 바인딩 기능을 제공하여 UI와 데이터 모델 간의 동기화를 쉽게 할 수 있습니다. 이를 통해 데이터 변경 사항이 실시간으로 UI에 반영되며, 사용자 상호작용이 원활하게 이루어집니다.

다양한 테마와 커스터마이징

SAPUI5는 다양한 테마를 제공하여 애플리케이션의 외관을 쉽게 맞춤화할 수 있습니다. UI Theme Designer를 사용하면 기업의 브랜딩 가이드라인에 맞춰 애플리케이션의 디자인을 쉽게 변경할 수 있습니다.

결론

SAPUI5는 반응형 웹 애플리케이션을 개발하기 위한 강력하고 유연한 프레임워크입니다. 다양한 UI 컨트롤과 라이브러리를 통해 개발자는 효율적이고 확장 가능한 애플리케이션을 만들 수 있습니다. SAPUI5를 활용하여 사용자 경험을 극대화하고, 다양한 비즈니스 요구를 충족시키는 애플리케이션을 개발해 보세요.