1. Excel 업로드 파일 선택

파일선택 클릭시 > file open dialog

2. Excel Upload 내역확인

엑셀업로드 내역확인

실제 엑셀파일의 데이터

3. 고객등록 (BDC)

3-1. BDC 실행 스닛핏

  PERFORM set_bdc_options.

  PERFORM bdc_data USING: 'X' 'SAPMZSP1020' '0100',
                          '' 'BDC_CURSOR' 'ZSSP1020-CUSTID_L',
                          '' 'BDC_OKCODE' '=INSERT'.

  LOOP AT gt_data INTO gs_data.
    PERFORM bdc_data USING: 'X' 'SAPMZSP1020' '0200',
                            '' 'ZSSP1021-CNAME' gs_data-cname,
                            '' 'ZSSP1021-PHONE' gs_data-phone,
                            '' 'ZSSP1021-EMAIL' gs_data-email,
                            '' 'ZSSP1021-POSTCD' gs_data-postcd,
                            '' 'ZSSP1021-ADDRS' gs_data-addrs,
                            '' 'BDC_OKCODE' '=ADD'.
    CLEAR gs_data.
  ENDLOOP.

 CALL TRANSACTION 'ZSP1020' **USING gt_bdc** **OPTIONS FROM gs_opt MESSAGES INTO gt_bdcmsg.**

FORM set_bdc_options .
  gs_opt-dismode  = 'N'.
  gs_opt-updmode  = 'S'.
  **gs_opt-racommit = 'X'.**
ENDFORM.

• racommit 속성을 사용해 insert에서 commit work를 만났을때 transaction이 종료되는 문제.

  (해결) racommit = ‘X’이면 commit work를 만나도 transaction이 종료되지 않음.

• gt_bdcmsg을 사용하여 에러메세지 처리

        PERFORM get_msg_text USING ls_msg-msgid ls_msg-msgnr
                             ls_msg-msgv1 ls_msg-msgv2 ls_msg-msgv3 ls_msg-msgv4
                       CHANGING lv_msg_text. 
        ... 
  
        IF ls_msg-msgtyp EQ 'A' OR ls_msg-msgtyp EQ 'E'.
          gs_data-light = 1.
          gs_data-msg = |[실패] { lv_msg_text }|.
        ELSE.
          IF ls_msg-msgid EQ 'ZSPMSG' AND ls_msg-msgnr EQ '035'.
            gs_data-light = 3.
          ELSE.
            gs_data-light = 1.
            gs_data-msg = |[실패] { lv_msg_text }|.
          ENDIF.
        ENDIF.

3-2. BDC 실행결과

BDC 실행결과 - 상태 및 에러메세지

실행 실패시, 에러메시지 표출됩니다.

BDC 실행결과 레코드가 신규 등록되는것 확인할 수 있습니다.

트랜잭션 처리 전략 - Lock, 커밋/롤백

📌 배경(Why?)

입고(GR) 데이터는 재고·회계·후속 문서 흐름에 직접 연결되는 핵심 기준 데이터이기 때문에, 저장 시점의 작은 오류나 처리 충돌도 운영·재무 전반에 연쇄적인 영향을 미칠 수 있다.

이에 따라 다음과 같은 구조적 리스크를 통제할 필요가 있었다.

1) 부분 성공·부분 실패로 인한 트랜잭션 불일치

• 한 번의 저장안에 여러 품목이 함께 처리되는 구조로
• 일부 Item만 성공하고 일부는 실패하는 경우, 사용자 인식과 실제 반영 데이터 간 괴리가 발생

➡ 입고 문서와 재고 테이블 간 불일치, 운영자 재확인·조정 업무 증가

2) Lock 전략 미흡으로 인한 통제 불명확성

• 동일 레코드에 대한 동시 수정 통제 기준이 명확하지 않을 경우
• 누가 먼저 수정했는지, 왜 저장이 실패했는지 파악이 어려움

➡ 데이터 충돌 발생 가능성과 운영 부서의 시스템 신뢰도 저하의 문제 발생

📌 설계 의도(Why this design?)

입고(GR) 수정 및 저장 시점을 Logical Unit of Work (LUW) 정의하고,

동시성 제어와 Commit/Rollback 규칙을 명확히 설정함으로써

항상 일관된 처리 결과가 보장되도록 설계하였다.

1) 레코드 단위 Lock으로 ‘동시 수정’ 자체를 논리적으로 차단

입고 품목은 입고문서 번호(GRNUM) + 품목 번호(GRPOS) 조합으로 식별된다.

이에 해당 키를 기준으로 ENQUEUE/DEQUEUE Lock을 적용하여

동일 데이터에 대한 동시 수정이 발생하지 않도록 통제하였다.

• 선행 사용자가 Lock을 선점하면 수정 권한을 보유
• 후속 사용자는 조회만 가능하도록 제한하거나, 수정 시도 시 명확한 오류 메시지를 반환

이를 통해 “First User Wins” 원칙을 적용하고,

데이터 충돌을 애플리케이션 레벨이 아닌 트랜잭션 레벨에서 구조적으로 차단하였다.

“동시성 문제를 해결하는 가장 확실한 방법은 ‘동시에 같은 데이터를 못 건드리게 하는 것’이라고 판단했다. 동일 데이터에 대한 동시 수정 충돌을 SAP Lock(Enqueue) 메커니즘을 통해 구조적으로 방지하였다.

2) All or Nothing 트랜잭션 원칙

입고 저장 과정에서 일부 품목 또는 일부 테이블만 반영되고 나머지가 실패하는 경우,

GR 문서·PO 상태·재고 테이블·FI 문서 간 데이터 불일치가 발생할 가능성이 있었다.

다음 네 영역을 단일 처리 단위로 묶어 관리하였다.

• GR 문서 생성
• GR와 연계된 PO 상태 변경(완료 플래그)
• GR 기준으로 반영되는 재고 테이블 수량/레코드 생성·수정
• GR에 의해 발생하는 FI 문서(회계 전표) 생성

위 영역 중

어느 한 단계라도 오류가 발생하면 ROLLBACK WORK를 수행하고

모든 처리가 정상 완료된 경우에만 COMMIT WORK

를 실행하도록 설계하였다

즉,

“한 번의 저장은 GR·PO·재고·FI가 모두 성공했을 때만 유효하다”

라는 All-or-Nothing 트랜잭션 원칙을 적용하여,

문서·재고·회계 상태가 서로 어긋난 채로 남는 상황을 구조적으로 차단하였다.

📌 구현 방식(How?)

1) ENQUEUE/DEQUEUE 기반 동시성 제어 구현

① 입고 품목 단위 Lock 선점

입고 수정 저장이 시작될때,

변경 대상 품목을 기준으로 GRNUM(입고문서 번호) + GRPOS(품목 번호) 조합에 대해 Lock을 선점하도록 설계하였다.

• 저장 로직 진입 시 각 품목별로 ENQUEUE 호출
• Lock 선점 성공 시 → 해당 품목을 Validation 및 Update 대상으로 포함
• Lock 선점 실패(foreign_lock) 시 → 즉시 저장을 중단하고 사용자에게 명확한 안내 메시지 제공

“해당 품목은 현재 다른 사용자에 의해 수정 중입니다.”

이를 통해 동일 품목에 대한 동시 수정 자체를 사전에 차단하고,

사용자가 저장 실패 원인을 명확히 인지할 수 있도록 하였다.

*&---------------------------------------------------------------------*
*&      Form  ENQUEUE_LOCK
*&---------------------------------------------------------------------*
*       Lock Enqueue
*----------------------------------------------------------------------*
FORM enqueue_lock_item .
  DATA lv_numc LIKE ztspgri-grpos.

  CLEAR gv_subrc.
  PERFORM get_selected_rows USING go_alvb.

  LOOP AT gt_selected INTO DATA(ls_selected).
    CLEAR lv_numc.
    lv_numc = ls_selected-row_id.

    CALL FUNCTION 'ENQUEUE_EZ_ZTSPGRI'
      EXPORTING
        mode_ztspgri   = 'E'
        mandt          = sy-mandt
        grnum          = gs_hmain-grnum
        grpos          = lv_numc
      EXCEPTIONS
        foreign_lock   = 1
        system_failure = 2
        OTHERS         = 3.
    IF sy-subrc NE 0.
      gv_subrc = sy-subrc.
      MESSAGE i012. " 해당 품목은 현재 다른 사용자에 의해 수정 중입니다.
      RETURN.
    ENDIF.
  ENDLOOP.
ENDFORM.

② 트랜잭션 종료 시점의 Lock 해제 전략

입고 저장 로직이 종료될 때,

처리 대상 품목에 대해 DEQUEUE를 호출하여 Lock을 명확히 해제하도록 설계하였다.

• 모든 Validation 및 DB Update가 정상 완료된 경우 → COMMIT WORK 이후 DEQUEUE 수행
• 예외 또는 오류 발생 시 → ROLLBACK WORK 수행 후 반드시 DEQUEUE 실행

특히 예외 상황에서도 Lock이 해제되지 않고 남는 일이 없도록,

예외 처리 블록에서 Lock 해제를 강제하는 구조로 설계하였다.

이를 통해

• Lock 잔존으로 인한 Dead Lock 발생 가능성 차단
• 특정 사용자가 데이터를 장시간 점유하는 상황 방지
• 동시 사용자 환경에서도 안정적인 운영 보장

하도록 하였다.

*&---------------------------------------------------------------------*
*&      Form  DEQUEUE_LOCK_ITEM
*&---------------------------------------------------------------------*
*       Lock Dequeue
*----------------------------------------------------------------------*
FORM dequeue_lock_item.
  DATA lv_numc LIKE ztspgri-grpos.

  LOOP AT gt_selected INTO DATA(ls_selected).
    CLEAR lv_numc.
    lv_numc = ls_selected-row_id.

    CALL FUNCTION 'DEQUEUE_EZ_ZTSPGRI'
      EXPORTING
        mode_ztspgri = 'E'
        mandt        = sy-mandt
        grnum        = gs_hmain-grnum
        grpos        = lv_numc.
  ENDLOOP.

  CLEAR gt_selected.
ENDFORM.

2) All or Nothing 트랜잭션 처리 구현 방식

‘한 번의 저장 = 한 번의 Commit 또는 Rollback’ 원칙을 실제로 적용하기 위해, 사용자가 GR을 저장하는 행위 전체를 하나의 업무 트랜잭션으로 보고 GR·재고·PO·FI가 함께 움직이도록 설계했다.

① GR 문서 생성이 전체 트랜잭션의 시작점

• 사용자가 저장을 누르면 먼저 GR 헤더를 생성한다.

• GR 자체가 생성되지 않으면

  → 재고 반영, PO 상태 변경, FI 생성 모두 수행되지 않도록 차단.

• GR이 존재하지 않는데 재고나 회계가 움직이는 비정합 상황을 원천 방지했다.

② 모든 GR 품목·재고 반영을 ‘한 묶음’으로 처리

• GR 헤더가 성공해야 그 다음에 각 GR Item 생성 + 재고 증가를 수행한다.

• 어떤 품목이라도 입력 오류·재고 제약·Validation 실패가 발생하면

  → 이번 저장 전체를 즉시 Rollback.

• “몇 개 품목만 반영된 반쪽짜리 GR”이 남지 않도록 했다.

③ PO 품목·헤더 상태 자동 업데이트 (성공 시에만 진행)

• 모든 GR Item + 재고 반영이 정상 완료된 경우에만

  → PO Item 상태(진행/부분완료/완료) 갱신

  → 잔여 진행 품목 수에 따라 PO 헤더 상태 자동 변경.

• PO 상태 갱신 중 하나라도 실패하면

  → GR·재고·PO 변경 전체를 Rollback.

→ “입고는 되었지만 PO는 예전 상태 그대로” 같은 문서 불일치가 발생하지 않도록 했다.

④ FI 문서까지 포함한 ‘단일 트랜잭션’으로 통합

• FI 생성까지 성공해야만 최종 Commit.

• FI에서 오류가 나면

  → GR, 재고, PO 변경까지 모두 Rollback.

• MM(재고)과 FI(회계)가 서로 다른 상태로 갈라지는 현상을 근본적으로 차단했다.

3) 생성/수정 이력 필드 기반 Audit Trail 확보

입고(GR)와 연계된 재고·PO·FI 전 구간에 대해,

모든 테이블에 생성자·생성일·생성시각 / 수정자·수정일·수정시각을 갖는공통 Audit 필드 구조를 표준 규칙으로 설계했다.

• GR 생성 시점에는 해당 필드에 생성 정보를 일괄 세팅하고, 이후 재처리·정정 등으로 데이터가 변경될 경우에는 수정 정보만 업데이트하도록 일관된 플로우를 정의했다.

이를 통해,

• 누가, 언제, 어떤 업무 흐름으로 데이터를 생성·수정했는지를 명확하게 추적할 수 있고

  단순 오류 분석뿐 아니라 감사(Audit), 내부통제, 운영 보고서 작성 시에도 신뢰도 높은 이력 기반을 제공할 수 있게 되었다.

생성/수정 이력은 단순히 “언제 바뀌었는지”를 남기는 용도를 넘어,

변경 주체(담당자)와 변경 타이밍을 기준으로 책임과 권한을 명확히 할 수 있는 근거 데이터로 활용된다.

이슈를 추적할 때, “어느 조직/사용자가 어떤 패턴으로 수정했는지”를 이력 기반으로 분석할 수 있어, 운영 정책 수립, 권한 조정, 교육 대상 선정 같은 후속 프로세스에도 직접적인 인사이트를 제공한다.

📌 배경

입고(GR)는 재고·회계·PO 상태에 직접 영향을 주는 핵심 프로세스이기 때문에, 입력 오류나 처리 기준의 불명확성이 존재할 경우 연쇄적인 정합성 문제가 발생할 가능성이 있었다.

이에 따라 다음과 같은 운영 리스크를 사전에 통제할 필요가 있었다.

1) 잘못된 입력으로 인한 연쇄 오류 가능성

• 주말·미래일·마감일 입력
• 미운영/삭제된 창고·플랜트 선택
• 삭제·완료된 문서를 기반으로 GR 생성 시도

➡ 재고 수량·회계 반영·PO 진행 상태가 모두 틀어지는 문제 발생

2) 정상 입고·반품 입고가 동일하게 처리되는 구조

• 반품 사유(정상/불량)에 따라 재고 반영 여부가 달라야 함에도

• 하나의 로직으로 처리되어 재고가 과다 혹은 중복 반영되는 사례 발생

  ➡ 반품 유형별 재고 처리 기준을 시스템적으로 강제하는 것이 필요

3) 신규 품번/창고 조합의 재고 테이블 누락 문제

• 재고 테이블에 “자재 × 플랜트 × 창고 × 사이즈” 조합이 없으면

  운영자가 직접 레코드를 생성해야 했다.

• 신규 플랜트 오픈 혹은 신규 라인 투입 시 누락·지연·운영 부담 증가

  ➡ 입고 시점에서 재고 레코드가 자동 생성되는 구조가 필요

📌 설계 의도(Why this design?)

입고(GR) 생성 단계에서 발생하는 모든 오류와 재고 반영 문제를 입력 시점에서 바로 잡고,

정상 입고·반품 입고·재고 생성까지 하나의 일관된 흐름으로 처리하기 위해 다음 의도를 중심으로 설계를 진행했다.

1) GR 생성 전에 오류를 ‘선제적으로 차단’하는 Validation Layer 구축

입고 화면 상단에 Validation 유틸리티 레이어를 두어,

• 입고일(주말·미래일·마감일)
• 플랜트/창고 상태(운영/미운영/삭제)
• 참조 문서(삭제·완료·0수량 Item)

등을 GR 생성 이전 단계에서 즉시 검증한다.

검증 결과는

• 메시지 클래스 기반의 명확한 안내문구,
• Function Group 의 스크린 팝업을 통한 상세 정보 확인

으로 사용자에게 전달되어, 사용자 스스로 오류 원인을 빠르게 확인하고 수정할 수 있도록 했다.

2) DONUM 기반으로 정상 입고와 반품 입고를 구조적으로 분리

입고 유형을 DONUM 규칙으로 명확히 구분하였다.

• 1xxxx → PO 기반 정상 입고
• 4xxxx → GI 기반 반품 입고

또한 반품 사유(정상/불량)에 따라

• 재고 반영
• 재고 미반영

을 자동 분기해, 기존에 반복적으로 발생하던 반품 재고 과반영 문제를 시스템 단에서 차단했다.

✔ 정상 반품/불량 반품을 재고 수량만으로 구분할 수 없는 문제 해결

“정상 반품과 불량 반품을 모두 재고 증가로 처리하면, 재고 수량만 보고는 ‘판매 가능한 수량’과 ‘불량 적치 수량’을 구분할 수 없었다. 이에 ‘판매 가능 여부’를 기준으로 재고 반영 기준을 분리해, 정상 반품만 재고로 복귀시키고 불량 반품은 별도 흐름으로 관리하도록 설계했다.”

✔ 불량 반품의 재고 미반영 기준을 명확히 설정

“불량 반품은 실제로 재판매·재출고가 불가능한 ‘폐기 예정 수량’이라는 점에 주목했다. 따라서 정상 재고로 편입하는 대신, 품질(QM)·폐기(Scrap) 프로세스에서 별도로 관리하는 것이 현업 운영 방식과 가장 일치한다고 판단해, 시스템에서도 재고를 ‘미반영’하도록 설계했다.”

3) 신규 품번·창고·사이즈 조합도 GR 시점에 자동 생성

재고 테이블에

‘자재 × 플랜트 × 창고 × 사이즈’

조합이 존재하지 않더라도,

입고 처리 시 해당 조합을 재고 테이블의 레코드로 자동 생성하도록 설계하여

• 신규 플랜트/창고 오픈
• 첫 입고 품번
• 신규 라인 투입

상황에서도 운영자가 사전 세팅을 하지 않아도 재고 반영이 누락되지 않도록 했다.

✔ 재고 조합만 자동 생성하도록 한 이유

‘자재 × 플랜트 × 창고 × 사이즈’ 조합은 입고 시점에 재고테이블에 자동 생성되도록 했지만, 자재 마스터나 플랜트, 창고 마스터 자체는 여전히 표준 마스터 관리 프로세스를 통해서만 생성되도록 구분했다. 재고 구조는 운영 편의를 위해 자동화하되, 마스터 데이터 생성 권한까지 열어버리면 통제 리스크가 커진다고 판단했기 때문이다.

✔ 자동화 범위를 ‘재고 조합’으로 제한한 설계 의도

자동 생성 대상을 재고 조합으로 한정함으로써, 가장 번거로워하던 사전 세팅(조합 추가) 작업만 제거하고, 나머지 마스터 관리 프로세스는 기존 거버넌스를 유지하도록 했다. 결과적으로 ‘자동화로 편해지지만, 데이터 거버넌스는 깨지지 않는’ 선을 찾는 것이 설계의 핵심 기준이었다.

📌 구현 방식(How?)

1) 입고일 유효성 검사(Date Validation)

입고일 입력 시 다음 규칙을 즉시 검증하여 잘못된 날짜 입력을 사전 차단했다.

• 오늘 기준 7일 이전까지만 허용
  • ‘실제 업무에서 소급 처리가 필요한 최대 기간’을 기준으로 7일로 정의
• 미래날짜 자동 차단
• 명확한 메시지로 오류 원인 안내

→ 반복적으로 발생하던 입고일 및 회계 불일치 오류를 입력 단계에서 원천 방지했다.

2) 플랜트·창고 운영 상태 Validation

입고 생성 시 선택된 플랜트과 창고의 운영 여부를 즉시 검증해 잘못된 저장위치 선택을 막았다.

검증 항목

• 운영(Active)
• 미운영(Inactive)
• 삭제(Delete)
• 재고 반영 가능 여부

오류 발견 시

• 팝업 경고
• GR 생성 차단
• 대체 창고/플랜트 서치헬프

→ 잘못된 장소로 재고가 반영되는 사고를 시스템이 선제적으로 차단하도록 설계했다.

창고/플랜트 상태를 엄격하게 검증한 이유는, 현업에서 ‘테스트용’으로 열어둔 창고나 더 이상 사용하지 않는 창고에 입고가 들어가는 등 재고조정 업무가 과도하게 발생할 수 있기 때문이다. 운영 주체가 ‘사용 안 한다’고 판단한 저장 위치는 아예 입고 자체가 불가능하도록 시스템 통제 수준을 끌어올렸다.

3) DONUM 기반 문서 Validation + 입고/반품 자동 분기

GR 생성 시 DONUM 규칙으로 원본 문서를 자동으로 구분한다.

• 1xxxx → PO 기반 정상 입고
• 4xxxx → GI 기반 반품 입고

추가로 참조 문서 상태도 동시에 검증한다.

• 삭제된 문서(LOEKZ)
• 입고 완료된 Item
• 0수량 Item

→ 삭제·완료·무효 Item을 GR 생성 단계에서 자동 제외하여

정상 입고·반품 입고 로직을 정확하게 분리 처리할 수 있는 기반을 마련했다.

4) 메시지 클래스 통합 + Popup Utility 정비

모든 Validation 및 경고 메시지를 단일 메시지 클래스로 통합하여:

• 규칙·문구의 일관성 확보
• 다국어 대응 용이
• 유지보수 비용 감소
• 사용자에게 이해 쉬운 메시지 제공

기존에는 유사한 오류라도 프로그램마다 다른 메시지와 코드가 섞여 있어서, 오류 로그만 보고는 정확한 원인을 추적하기 어려웠다. 그래서 Validation 관련 메시지를 하나의 메시지 클래스로 일원화하고 코드 체계도 통합해, 장애 분석 시 ‘메시지 코드만으로도 어떤 레이어에서 막힌 건지’를 바로 인지할 수 있도록 하였다.

또한 Function Group 팝업스크린으로 다음 정보를 화면 이동 없이 조회할 수 있도록 했다.

• 자재 상세 정보
• 플랜트·창고 기본 정보
• 참조 문서 정보
• 담당자 정보

동시에 여러 화면에서 동일한 조회 스크린을 공통으로 재사용할 수 있도록 했다.

공용 FG 팝업을 두면서, 화면마다 비슷한 조회 로직과 UI를 중복 개발하지 않고 한 곳에서만 유지보수하면 되기 때문에, 개발 및 운영 비용을 줄이면서도 사용자 경험(UI/메시지)을 일관되게 유지할 수 있도록 했다.

5) 일반 입고(PO 기반) 재고 반영 로직

일반 입고(1xxxx) 시:

• GR Item 수량만큼 재고(matqty) 증가
• 동일 자재라도 플랜트/창고/사이즈/자재그룹 조합별로 분리 관리

→ 표준 재고 흐름을 유지하면서도

각 사업장·창고·라인의 재고 상태를 독립적으로 관리할 수 있게 했다.

6) 반품 입고(GI 기반) 재고 반영 분기

반품 입고(4xxxx)는 반품 사유에 따라 재고 반영을 자동 분기한다.

• 정상 반품 → 재고 증가
• 불량 반품 → 재고 미반영 (GR 문서만 생성)

→ 정상 입고와 반품 입고를 동일하게 처리해 발생하던

재고 과반영·중복 반영 문제를 구조적으로 차단했다.

7) ‘자재 × 플랜트 × 창고 × 사이즈’ 조합 자동 생성

입고(GR) 시점에 재고 테이블을 조회해 조합이 없으면:

• 신규 레코드 자동 INSERT
• 있으면 기존 matqty UPDATE

→ 운영자가 사전에 테이블을 세팅할 필요 없이,

입고 프로세스 자체가 신규 조합을 자동 생성하는 기준점으로 동작하도록 했다.

📌 배경

프로젝트의 기준상 입고(GR)는 두 가지 서로 다른 프로세스에서 발생한다.

• 일반 입고 → 구매오더(PO) 기반
• 반품 입고 → 출고문서(GI) 기반

그러나 GR을 PO나 GI에 FK로 연결하는 구조로는 두 흐름을 하나의 입고 프로세스 안에서 처리할 수 없었다.

PO와 GI를 GR에 직접 FK로 물리게 되면,

입고 유형마다 서로 다른 테이블과 관계를 관리해야 해서 구조가 지나치게 복잡해지고, 테이블 설계부터 손봐야 하는 문제가 있었다.

그래서 이미 사용 중이던 DONUM (관련문서번호 필드)규칙을 공통 식별자로 재사용해,

두 프로세스를 하나의 GR 구조 안에서 통합하는 것을 설계 기준으로 삼았다.

현업에서는 동일 거래처의 여러 PO를 한 번에 입고 처리하는 경우가 많았기 때문에,

이를 반영하여 여러 PO의 Item을 하나의 GR 문서에서 참조할 수 있는 구조로 목표로 하였다.

또한, 하나의 PO에 하나의 GR이 대응되는 방식에서 발생하던

• 반복 입력
• 상태 누락
• 문서 불일치
• 회계 반영 지연

과 같은 문제를 개선하고자 하였다.

➡ 이에 따라, 정상입고와 반품입고를 하나의 처리 구조 안에서 통합 관리하면서,

여러 PO의 Item을 하나의 GR 문서에서 참조 및 집계할 수 있는 방식으로 설계하였다.

📌 DONUM 기반 문서 매핑 구조 (Core Logic)

입고 문서의 Origin(생성 근거) 을 추적하기 위해

GR Item에 관련문서번호(DONUM) 를 공통 기준으로 설계했다.

이 규칙을 기반으로 시스템은 GR 생성 시 자동으로 문서 타입을 판별한다.

➡ 정상입고/반품입고 흐름을 하나의 GR 구조에서 통합할 수 있는 구조적 기반 확보

➡ GR을 특정 문서에 FK로 연결하지 않아도 문서 흐름을 정확히 추적 가능

입고 라인아이템 테이블 - DONUM, DLNUM

📌 구조 설계 (Header–Item 구조 통일)

PO, GI, GR 모두 Header–Item 구조로 통일하여

GR Item이 반드시 PO Item 또는 GI Item과 1:1로 매핑되도록 설계했다.

이를 통해

• 한 GR 아래에 여러 PO/GI 문서를 병합해도 Item 단위 추적이 정확
• 향후 FI·재고 업데이트에서도 오류 없이 연계 가능
• 문서 흐름이 구조적으로 단순하고 관리가 쉬움

등 입고 처리의 효율성과 문서 간 일관성을 확보했다.

📌 다건 PO → GR 병합 처리 구조 (핵심 설계)

같은 거래처이면

사용자가 선택한 여러 PO의 Item을 모두 수집하여 GR Header 1건 아래에 배치한다.

• PO 개수가 1개든 10개든 GR은 “1건” 생성
• GR Item은 PO Item 수만큼 자동 생성
• DONUM으로 원본 문서와 정확히 연결

➡ 입고 처리 속도 대폭 증가, 누락/중복 방지, 문서 수 감소

‘‘PO 한 건 → GR 한 건’ 구조에서는 동일 트럭에 실려 온 물량이라도 PO 개수만큼 나누어 반복 입력해야 했다. 이 과정에서 누락 및 중복 입력이나 상태 오류가 발생할 가능성이 높았다.

이에 따라, 기술 구조 역시 실제 업무 단위를 그대로 반영하여 여러 PO를 하나의 GR로 병합 처리할 수 있는 방향을 설계 기준으로 삼았다.

📌 GR 생성 후 PO 상태 자동 변경

PO 상태를 담당자가 수기로 관리하는 경우,

• 부분 입고를 ‘완료’로 표시하거나
• 실제로는 일부만 입고되었음에도 상태가 갱신되지 않는 등

부서별 해석 차이와 관리 기준 불일치로 인한 혼선이 발생할 가능성이 있었다.

이에 따라, PO 상태를 사람이 판단하는 것이 아니라 실제 입고 이력이 자동으로 정의하도록 설계하였다.

GR 생성 시 각 PO Item의 입고 수량을 분석하여,

• 모든 Item이 미입고일 경우 → A: 생성
• 일부만 입고된 경우 → B: 부분입고
• 모든 Item이 입고 완료된 경우 → C: 입고완료

로 PO header의 상태를 자동 판정하도록 로직을 구현하였다.

✔ 효과

• PO 진행 상황이 항상 “현재 기준”으로 정확히 유지됨
• 다건 병합입고에서도 PO 상태가 누락 없이 업데이트됨
• 구매·검수·회계팀이 PO 상태 판단을 수작업으로 할 필요가 사라짐

➡ 이를 통해, PO 관리의 정합성을 운영 단계에서 안정적으로 확보하였다

📌 GR 생성과 동시에 FI 문서 자동 생성

입고 이후 회계(FI)를 별도로 생성하는 방식은

문서 매칭 오류와 회계 반영 지연을 유발할 수 있었다.

이에 따라, 입고 시점(GR)을 회계 처리의 기준 시점으로 정의하고,

GR 생성과 동시에 FI 문서를 자동 생성하도록 설계하였다.

(※ Invoice 프로세스는 별도 흐름으로 운영되었으며, GR–FI 기준의 회계 반영 구조에 집중하였다.)

GR Header 정보를 기반으로 FI 문서를 생성하고,

GR–FI 간 참조 관계를 자동 설정함으로써 문서 연결이 즉시 확정되도록 구현하였다.

✔ 효과

• 입고와 회계가 실시간으로 동기화
• 회계팀의 후처리 작업 대폭 감소
• 문서 불일치 및 매칭 오류 제거
• 감사/정산 단계에서도 문서 추적이 명확해짐

➡ 입고(GR) → 회계(FI) 프로세스가 한 번에 자동 완결되는 구조 확보

초기 운영 설계에서 별도의 Invoice 프로세스를 태우지 않기로 하면서, 실제 비용 인식의 기준 시점을 어디로 둘지에 대한 합의가 필요했다.

논의 결과,

물류 기준으로 재화가 실제 창고에 입고되는 시점(GR)을 재고 및 원가 등 회계 처리의 기준 시점으로 삼는 것이 가장 직관적이라고 판단해, GR 생성과 동시에 FI 문서를 함께 생성하는 구조를 채택했다.

이를 통해 Invoice 없이도 입고 기준으로 재고와 비용이 일관되게 반영되도록 했다.

입고 프로세스 가시성 개선을 위한 통합 리포트 시스템 구축

📌 배경

기존 운영 환경에서는 입고(GR)와 관련된 정보가

• PO(구매),

• GR(입고),

• FI(회계),

• INVOICE(송장)

  등 서로 다른 화면에 흩어져 있어 문서 흐름을 한눈에 추적하기 어렵고,

  일/주/월 단위 실적을 분석하는 데에도 수작업이 과도하게 필요했다.

이에 따라

입고 프로세스 전체의 가시성을 개선 하고,

문서 연결·기간별 분석·보고 자동화 를 지원하는 통합 리포트 시스템을 구축하였다.

📌 핵심 설계 포인트

① 기간·조건 기반의 다차원 조회 구조 설계

현업 분석 패턴을 반영하여 다음 단위 조회 기능을 제공:

• 일별 / 주차별 / 월별 / 분기별 / 연도별 조회
• 자재, 사이즈, 플랜트, 창고, 담당자 등 상세 조건 필터링
• DONUM 기반 문서 타입(PO/GI) 자동 판별

기간 조건 선택 시 SAP가 자동으로 날짜 범위를 계산하여 사용자 입력 부담을 줄이고 조회 정확도를 높였다.

기간 단위를 일/주/월/분기/연도로 나눈 이유는, 구매·물류팀은 주/월 단위로, 경영진은 분기/연 단위로 실적을 보는 등 부서별 분석 단위가 서로 달랐기 때문이다. 주요 리포트 패턴을 한 화면에 모두 수용해, 각 팀이 엑셀을 따로 가공하지 않고도 바로 사용할 수 있도록 했다.

② 문서 흐름(PO–GR–FI)을 한 화면에서 연결하는 Traceability 확보

입고문서(GR)를 중심으로 다음 문서를 자동 연계:

• GR → PO
• GR → FI (회계문서)
• GR → Invoice
• (반품 시) GR → GI

원본 구매 단계부터 회계 처리까지의 전체 프로세스를 단일 화면에서 확인할 수 있게 되었다.

이는 기존에 화면을 여러 번 오가며 문서를 찾던 비효율을 제거한 개선이다.

기존에는 PO·GR·FI·Invoice가 서로 다른 트랜잭션에 흩어져 있어, 문제 발생 시 ‘어디에서 끊겼는지’를 찾는 데만 시간이 많이 걸렸다. 그래서 GR을 중심축으로 삼고 전후 문서를 한 번에 보여주면, 구매·물류·회계가 같은 화면을 기준으로 소통할 수 있다고 판단했다.

특히 클레임이나 정산 이슈가 발생했을 때, 한 화면에서 흐름이 끊긴 지점을 바로 찾을 수 있어 원인 파악과 책임 소재 확인에 드는 시간을 크게 줄이는 것을 목표로 했다.

③ 핫스팟(Hotspot) 기반 트랜잭션 자동 이동

ALV에서 문서번호(PO, FI, GI, IVNUM 등)를 클릭하면

해당 문서의 상세 화면 또는 별도 트랜잭션으로 즉시 이동하도록 구현하였다.

• 클릭 → 자동 SET/GET PARAMETER ID → CALL TRANSACTION
• 문서 추적 시간이 대폭 감소
• 구매/재고/회계팀의 협업 속도 상승

➡ 입고 리포트가 프로세스 네비게이션 역할까지 수행하도록 확장했다.

문서번호를 복사해 다른 트랜잭션에 붙여넣는 기존 방식은 단순히 번거로운 수준을 넘어서, 번호 오입력이나 잘못된 문서 조회로 이어지는 실제 장애 원인이 되기도 했다. 그래서 자주 조회하는 문서들은 클릭 한 번으로 이동하도록 해, 사용자의 수작업을 최대한 없애는 방향을 택했다.

이렇게 입고 리포트에서 바로 각 모듈 트랜잭션으로 네비게이션하게 함으로써, 보고서가 단순 조회용을 넘어 실제 업무 처리의 허브 역할을 하도록 설계했다.

④ Function Group 기반 상세 팝업 조회

자재, 창고, 담당자 등 특정 필드 클릭 시 즉시 세부 정보를 확인할 수 있도록

재사용 가능한 Function Group 기반 팝업을 구현하였다.

• 품번 클릭 → 자재 정보 팝업
• 플랜트/창고 → 기본정보 팝업
• GR Item → 라인아이템 상세 팝업

팝업이 여러 프로그램에서 호출되도록 설계해 유지보수성과 확장성을 높였다.

자재, 창고, 담당자 정보를 조회하는 팝업을 Function Group 하나로 통합한 이유는, 입고 리포트뿐 아니라 추후 다른 리포트·트랜잭션에서도 동일한 UI와 로직을 그대로 재사용할 수 있게 하기 위함이었다. 결과적으로 화면마다 유사한 조회 로직을 따로따로 만들지 않고, 한 곳만 수정해도 전 시스템에 반영되도록 유지보수 비용을 줄였다.

⑤ OLE2 기반 엑셀 다운로드 자동화

조회된 리포트를 원클릭으로 보고서 형태의 Excel로 변환하도록 구현하였다.

• 컬럼 헤더 자동 매핑
• 기간 기반 파일명·시트명 자동 생성

GATEWAY - DATAMODEL

GATEWAY - ENTRYTYPES

GATEWAY - ENTRY SET

GATEWAY - SERVICE MAINTANCE 확인

SERVICE DEFINITION 생성

SERVICE 생성(추가)

GATEWAY CLIENT 연결확인

ABAP Memory 특징

• SAP MEMORY는 파라미터 ID를 생성해야하는 반면 ABAP MEMORY를 사용하는 경우는 메모리 ID이름을 _프로그램 수준_에서 임의로 지정가능하다.

• ABAP MEMORY로 데이터를 넘겨주기 위해, EXPORT/IMPORT구문을 사용하고 _동일한 파라미터 ID_이름을 사용해야한다.

• 다른 프로그램에 데이터오브젝트(필드, 스트럭처, 인터널 테이블)를 넘겨주기 자주 사용한다.

• 다른 프로그램을 호출할 때 명령어(CALL TRANSACTION, SUBMIT)을 사용하면 내부세션이 생성되고 ABAP MEMORY에 잇는 데이터가 공유된다.

• 같은 윈도우(동일 내부세션)에서만 메모리 영역을 공유하므로 *새창을 띄워서 작업할 경우 메모리 영역이 사라진다. *

ABAP Memory 사용법

IMPORT/EXPORT

EXPORT OBJ1 …OBJN TO MEMORY ID KEY.

IMPORT OBJ… BOJN FROM MEMORY ID KEY.

Export 구문을 이용해서 데이터 오브젝트(필드, 스트럭처, 인터널 테이블)를 ABAP Memory에 로드할 수 있다.

ABAP MEMORY삭제

FREE MEMORY [ID KEY]

ID KEY를 넣지 않으면 전체 메모리가 삭제되므로 주의가 필요하다!

실습1

z11_05에서 EXPORT로 인터널테이블 gt_emplist가 ABAP Memory의 KEY 'TEST_ID'로 저장됨.

z11_06에서 IMPORT로 KEY 'TEST_ID'로 찾아와서 GT_EMPLIST값 가져옴.

트랜잭션 또는 실행가능한 프로그램을 호출할 때 발생하는 상황 2가지

1. 호출받은 프로그램이 종료되고 되돌아올 때. 호출받은 프로그램이 삭제되지 않고 비활성화된 상태. 그리고 메모리에 저장된 값들은 스택으로 옮겨진다.(최대9개까지)

LEAVE TO PROGRAM.

2. 호출받은 프로그램이 실행을 종료하고 호출한 프그램으로 복귀 하지 않고, 호출받은 프로그램은 내부 세션에서 자신이 호출한 프로그램을 대체해 버리고, 호출한 프로그램메모리 값은 삭제한다.

   ** LEAVE TO TRANSACTION ** 내부세션의 모든 스택을 삭제하고 새로운 내부 세션을 생성하여 트랜잭션을 호출. 그 결과 프로그램간에 데이터를 넘겨주지 못함.

   ※ SAP MEMORY는 여전히 데이터 전달된다.

SeSAC의 과정에서 배웠던 SAP Memory는 바로 모든 세션에서 쓸 수 있는 메모리라는 것이다.

예시)

이렇게 T-code: SE11에서 SCARR을 입력하면

다른 창을 열어서도 SCARR가 보인다.

F1 > Technical로 들어가면 이렇게 parameter ID가 있는데, 이걸 KEY로 SAP Memory에 저장된다.

GET/SET Parameter ID 설정하는법

방법1. t-code : se80

SE80에서

Workbench > Edit Object > Enhanced Options > SET/GET Parameter ID

로 SAP Memory의 KEY를 설정한다.

방법2. t-code : sm30

TPARA는 SAP 시스템 전체에서 사용하는 SPA/GPA Parameter ID 정의 테이블.

방법3. 더블클릭해서 생성하기

이게 가장 직관적이다. SE38이나 SE80에서 코드를 작성하면서 생성한다.

SAP Memory할당

 SET PARAMETER ID <pid> FILD <f>

필드 <f>를 SPA/GPA파라미터 <pid>에 저장
<pid> : 최재 20자. 값이 있다면 덮어쓴다.

SAP Memory읽기

 GET PARAMETER ID <pid> FILD <f>

SAP Memory의 <pid>에 있는 값을 필드<f>에 저장한다.
만약 <pid>가 메모리 ID에 존재하지 않는다면, sy-subrc = 4.

실습 1

파라미터 또는 Select-option변수에 'Memory ID'를 사용해 필드와 파라미터를 연결시킨다.

PARAMETERS P_1 TYPE C MEMORY ID 'PID'

레포트 프로그램에서 메모리 할당후 값을 엔터하면 ZMY에 SET A가 된다.

모듈풀 프로그램의 스크린페인터에서

PARAMTER ID와 GET/SET PAMRMETER 체크를 해주면

새창을 열어서 모듈풀 프로그램 실행하면 리포트프로그램에서 입력했던 값이 할당된 것을 확인할 수 있다. (GET ZMY)

실습 2

1. ZENM, ZENO를 더블클릭해서 Create Paramters해서 메모리할당

2. 사용자가 더블클릭하면(BY AT LINE-SELECTION), 파라미터 값 저장되고, Z11_03트랜잭션 실행된다.

※ AND SIP FIRST SCREEN: 첫화면을 건너뛰고(SKIP) 실행하라는 명령어. ※ HIDE: 필드의 값을 HIDE메모리 영역으로 저장하는 역할

Z11_02에서 더블클릭하면 이벤트를 타게 되고, 파라미터 값이 SET되고 Z11_03프로그램으로 넘어간다. (새로운 내부세션이 생성됨) SAP Memory에서 GET PARAMTER ID로 동일한 값이 출력된다.

생각해보기

SAP MEMORY를 어디서 활용할 수 있을까? 초기설정값에 활용할 수 있다.

예를 들어 회사코드 1000, 플랜트1010에 대한 조회 권한만 가지고 있다면 T-CODE : SU03또는 SU01에서 USER PROFILE의 PARAMETERS탭을 통해 값을 미리 설정할 수 있다.

이경우에 사용자가 로인하여 트랜잭션을 조회할때 회사코드, 플랜트 필드가 자도응로 값이 입력되어 효율적으로 사용할 수 있을 것이다.

JDK 다운로드한 후 (환경변수 설정 필요), Cloud Connector 다운로드

Cloud Connector 접속

https://localhost:8443 (colud connector 다운로드시 포트번호를 8443으로 설정해둠)

초기 로그인 UserName : Administrator Password: manage

Subaccount 추가

Cloud to On-Premise - System Mapping

Cloud to On-Premise - Add resource

Destination 설정

권한설정

Overview

SAP GUI에 로그인하면 하나의 사용자 터미널 세션이 생성된다. 이 터미널 세션에는 최대 6개의 GUI윈도우를 실행할 수 있다.

이때 6개의 윈도우를 _외부세션(External Session)_이라고 한다.

하나의 외부세션은 최대 20개의 _내부세션(Internal Session)_을 가질 수 있다.

내부세션은 하나의 외부세션 내에서 실행중인 프로그램이 다른 프로그램을 호출할때 성되는 세션이다.

• 사용자 터미널 세션: SAP에 로그인하면 생기는 전체 작업 공간이야.

• 외부 세션: 이 작업 공간 안에서 열 수 있는 최대 6개(또는 S/4 HANA의 경우 16개)의 창들 . 각 창은 독립적인 것처럼 보이지만, 사실 메모리를 공유하고 있다 .

• 내부 세션: 하나의 외부 세션 안에서 프로그램이 다른 프로그램을 부를 때 생기는 작은 작업 공간. 최대 20개까지 만들 수 있다.

ABAP Memory와 SAP Memory차이점

ABAP 메모리:** 동일한 외부 세션 안에서 실행되는 프로그램들끼리 데이터를 공유하는 메모리. **

각각의 외부세션에 하나만 존재한다. 각각의 프로그램은 자신의 내부세션을 가지고, 내부세션은 스택에 쌓인다. 데이터를 주고받을 때는 EXPORT/IMPORT 구문을 사용한다.

SAP 메모리: 사용자 터미널 세션 내의 모든 외부 세션에서 접근할 수 있는 Global Memory

• SAP에 로그인해서 띄운 모든 창에서 이 메모리에 접근할 수 있다 .
• 데이터를 주고받을 때는 SET PARAMETER / GET PARAMETER 구문을 사용한다.

정리

• User Terminal Session (최상위): 사용자가 SAP GUI에 로그인할 때 생성되는 가장 큰 단위.

• External Session: 사용자가 새 창을 열 때 생성되는 메인 세션입니다.

• Internal Session: 하나의 외부 세션 내에서 프로그램이 실행되거나 다른 프로그램을 호출할 때 생성되는 세션.

• ABAP Memory: 동일한 외부 세션 내에 있는 내부 세션들끼리만 데이터를 주고받을 수 있는 메모리 . External Session 레벨에 존재.

• SAP Memory : 모든 외부 세션이 공통으로 접근할 수 있다. User Terminal Session 레벨에 존재.

프로그램 간의 데이터를 넘겨주는 법

1. Interface

TYPE-1(리포트 프로그램 프로그램을 호출할때,

Submit 구문을 이용해 Selection screen의 Input필드에 값을 입력하거나,

Parameters (단일 값): WITH [필드명] = [값]
Select-options (범위 값): WITH [필드명] IN [Range 인터널 테이블]

DATA: lr_date TYPE RANGE OF sy-datum,
      ls_date LIKE LINE OF lr_date.

" Select-option을 위한 Range 데이터 준비
ls_date-sign   = 'I'.
ls_date-option = 'BT'.
ls_date-low    = '20240101'.
ls_date-high   = '20241231'.
APPEND ls_date TO lr_date.

SUBMIT z_target_report
  WITH p_user = sy-uname          " Parameter에 값 전달
  WITH s_date IN lr_date          " Select-option에 Range 테이블 전달
  VIA SELECTION-SCREEN            " (선택) 화면을 보여줄지 여부
  AND RETURN.                     " 실행 후 다시 현재 프로그램으로 복귀

Selection screen의 Variant를 호출하는 방법 (복잡한 입력 조건을 매번 넣기 힘들 때, 백그라운드 작업(Batch Job)을 돌릴 때 등 )

" 예시: 'MONTHLY_BATCH'라는 이름의 Variant를 사용하여 호출
SUBMIT z_target_report
  USING SELECTION-SET 'MONTHLY_BATCH'
  AND RETURN.

2. ABAP Memory

ABAP Memory를 이용하여 EXPROT, IMPORT 구문을 사용한다. 동일한 파라미터 명을 사용한다.

• 핵심 구문: EXPORT ... TO MEMORY ID / IMPORT ... FROM MEMORY ID
• 특징: 동일한 ID를 사용해야만 데이터를 찾을 수 있어요.

" [프로그램 A] 데이터를 메모리에 저장 (보내기)
DATA: gv_text TYPE string VALUE 'j_wisdom_h'.

EXPORT p1 = gv_text TO MEMORY ID 'ZMY_NICKNAME'. 
" 'ZMY_NICKNAME'이라는 메모리id에 
" gv_text를
"'p1'이라는 이름으로 데이터를 넣음

" --------------------------------------------------

" [프로그램 B] 메모리에서 데이터를 읽기 (받기)
DATA: gv_received TYPE string.

IMPORT p1 = gv_received FROM MEMORY ID 'ZMY_MEM'.
" 'ZMY_NICKNAME' 메모리id에서 
" 'p1'이라는 이름을 찾아 데이터를 꺼냄

3. SAP Memory

SAP Memory영역의 파라미너 ID를 이용해 데이터를 넘겨준다.

• 핵심 구문: SET PARAMETER ID / GET PARAMETER ID

  " [창 1] 사용자가 입력한 회사 코드를 글로벌하게 저장
  SET PARAMETER ID 'BUK' FIELD '1000'. 
  " 'BUK'라는 공용 게시판 위치에 '1000'이라는 값을 딱! 붙여둠
  

" --------------------------------------------------

" [창 2] 다른 프로그램에서 그 값을 자동으로 가져옴 DATA: gv_bukrs TYPE bukrs.

GET PARAMETER ID 'BUK' FIELD gv_bukrs. " 공용 게시판 'BUK' 위치에 있는 값을 읽어와서 변수에 담음

### 4. Database Table
가장 일반적인 방법. 
프로그램 A가 데이터를 테이블에 저장하고,
프로그램 B가 테이블에서 데이터를 조회

### 5. Presentation Server
SAP GUI가 실행 중인 로컬PC에 데이터를 파일로 다운로드했다가 업로드하는 방법 (GUI_DOWNLOAD, GUI_UPLOAD)

CAPM의 정의부터 주요 특징, 그리고 개발 과정을 혁신하는 자동화까지 자세히 살펴보겠습니다.

1. CAPM이란 무엇인가요?

CAPM은 SAP Cloud Application Programming Model의 약자로, 개발자가 복잡한 인프라나 기술적인 세부 사항에 얽매이지 않고 비즈니스 로직 구현에 집중할 수 있도록 설계된 프레임워크입니다.

2. CAPM의 주요 특징

CAPM은 개발 생산성을 극대화하고 유연한 애플리케이션 개발을 지원하는 여러 가지 특징을 가지고 있습니다.

2.1. CDS(Core Data Services) 중심 모델링

CAPM은 CDS(Core Data Services)를 사용하여 데이터 모델과 서비스 정의를 통합합니다.

CDS는 데이터베이스 스키마, 서비스 인터페이스, 비즈니스 로직을 하나의 추상화된 모델로 정의할 수 있게 해주며, 이는 개발의 일관성과 효율성을 높이는 핵심 요소입니다.

2.2. 언어 유연성

CAPM은 개발자들이 선호하는 프로그래밍 언어를 선택할 수 있도록 지원합니다.

• Node.js: JavaScript/TypeScript 기반의 백엔드 개발에 익숙한 개발자에게 적합합니다.

• Java: 안정적이고 성능이 뛰어난 엔터프라이즈 애플리케이션 개발에 강점을 가집니다.

2.3. 데이터베이스 독립성

CAPM은 특정 데이터베이스에 종속되지 않습니다. 개발자는 프로젝트 요구사항에 따라 다양한 데이터베이스를 유연하게 선택하고 변경할 수 있습니다.

• SAP HANA: SAP 환경에 최적화된 인메모리 데이터베이스입니다.

• SQLite: 개발 및 테스트 단계에서 가볍게 사용할 수 있는 파일 기반 데이터베이스입니다.

그 외 다양한 관계형 데이터베이스를 지원합니다.

3. CAPM의 '자동화 마법'

CAPM의 가장 강력한 장점은 개발자가 반복적이고 번거로운 작업을 직접 처리할 필요 없이, 프레임워크가 자동으로 많은 부분을 처리해준다는 점입니다.

3.1. OData API 자동 생성

CDS 모델을 정의하면 CAPM은 해당 모델을 기반으로 OData(Open Data Protocol) API를 자동으로 생성합니다.

이는 데이터 생성(Create), 조회(Read), 업데이트(Update), 삭제(Delete)와 같은 기본적인 CRUD(Create, Read, Update, Delete) 엔드포인트를 별도의 코딩 없이 바로 사용할 수 있게 해줍니다.

3.2. DB 스키마 자동 배포 및 관리

CDS 모델에 따라 데이터베이스 스키마가 자동으로 생성되고 배포됩니다. 모델이 변경되면 CAPM은 데이터베이스 스키마를 자동으로 업데이트하여 개발자가 수동으로 스키마를 관리하는 부담을 덜어줍니다.

3.3. 내부 통신 자동 연결

CAPM 프로젝트 내에서 여러 서비스 간의 통신은 별도의 Destination 설정 없이 자동으로 연결됩니다. 이는 마이크로서비스 아키텍처에서 서비스 간의 상호작용을 매우 간편하게 만들어줍니다.

4. Destination 설정 가이드

CAPM은 내부 서비스 간 통신을 자동화하지만, 외부 시스템과의 연결에는 Destination 설정이 필요합니다.

• 내부 프로젝트 서비스 사용 시: CAPM 프로젝트 내에서 다른 서비스(예: 동일한 CAPM 프로젝트 내의 다른 마이크로서비스)를 호출할 때는 별도의 Destination 설정이 필요 없습니다.

• 외부 시스템 연결 시: Northwind OData 서비스, SAP S/4HANA 시스템, 또는 기타 외부 API와 같이 CAPM 프로젝트 외부에 있는 시스템에 연결할 때는 Destination 설정이 필수적입니다. 이는 보안 및 연결 정보를 중앙에서 관리하고 안전하게 통신하기 위함입니다.

5. CAPM 개발 프로세스 시각화

CAPM을 활용한 애플리케이션 개발 프로세스는 다음과 같이 시각화할 수 있습니다.

CAPM은 개발자가 비즈니스 가치 창출에 집중할 수 있도록 복잡한 기술적 장벽을 낮추고, 자동화를 통해 개발 생산성을 혁신하는 강력한 도구입니다.

1. SAP BTP의 큰 그림: 글로벌 계정

글로벌 계정(Global Account)은 SAP BTP를 사용하기 위한 가장 큰 단위(최상위)라고 보면 된다.

글로벌 계정은 여러 개의 하위 계정(Subaccount)을 관리하고, 우리가 쓸 수 있는 자원(자격 및 할당량)을 총괄하는 역할을 한다.

• 상업적 계약
• 자격 및 할당량
• 지역
• 전체 리스스 관리

이 계정은 특정 지역에 묶여있지 않고, 전 세계 어디서든 관리할 수 있는 자유로운 계정이다.

여기서는 앱을 직접 배포할 수 없다.

2. 실제 작업 공간: 하위 계정

하위 계정(Subaccount)은 *실제로 앱을 만들고, 서비스를 사용하고, 구독을 관리하는 작업 공간이다. *

즉, 글로벌 계정내의 논리적 컨테이너다.

글로벌 계정 아래에 여러 개의 하위 계정을 만들 수 있다.

각 하위 계정은 서로 독립적이라서, 마치 여러 개의 독립된 작업실을 가지고 있는 것과 같다.

하위 계정은 특정 지역(Region)에 연결되어 있다.

글로벌 계정에서 받은 자원(인타이틀먼트와 쿼터)은 이 하위 계정들에게 나눠줘야 실제로 사용할 수 있다.

Cloud Foundry 조직과 Kyma 클러스터

Cloud Foundry

Cloud Foundry 환경을 활성화하면 Cloud Foundry 조직이 자동으로 생긴다. (초기값으로 활성화되어있음)

Cloud Foundry는 SAP가 엑세스 할 수 있는 제3자 환경이다. 대부분의 클라이언트가 Cloud Foundray 환경을 사용한다.

이 조직 안에 공간(Space)을 만들어서 앱을 더 세부적으로 관리할 수 있다.

Kyma

Kyma 환경을 활성화하면 Kubernetes 클러스터가 생긴다.

Kyma는 SAP의 자체환경이다.

하나의 하위 계정 안에 여러 개의 Kyma 클러스터를 만들 수 있다.

각 클러스터 안에는 네임스페이스(Namespace)를 만들어서 작업 부하를 나누고 자원 접근을 제어할 수 있다.

• Cloud Foundry는 개발자가 인프라를 신경 쓰지 않게 한다. 소스코드를 올리면 '빌드팩(Buildpack)'이 알아서 실행 환경을 구성한다.

  간단한 배포에 장점

• Kyma는 컨테이너 기술을 직접 다룬다. Docker 이미지를 사용하여 환경을 구성하므로, 특정 OS 설정이나 복잡한 네트워크 구성이 필요한 경우 훨씬 자유롭다.

  강력한 제어권에 장점

디렉토리

디렉토리(Directory)는 하위 계정들을 더 체계적으로 정리하고 관리할 수 있게 해준다.

마치 컴퓨터에서 폴더 안에 또 다른 폴더를 만들어서 파일을 정리하듯이, 디렉토리 안에 다른 디렉토리나 하위 계정을 넣을 수 있다.

최대 7단계까지 깊은 계층 구조를 만들 수 있다.

가장 위는 글로벌 계정, 가장 아래는 하위 계정이고, 그 사이에 최대 5개의 디렉토리 레벨을 가질 수 있다.

디렉토리를 사용하면 사용량과 비용을 모니터링하거나, 자원(인타이틀먼트)을 미리 할당해둘 수도 있다.

예를 들어, 특정 부서의 디렉토리에 예산을 미리 배정해두는 것.

SAP BTP 3단계 계정구조를 가지고 있다.

• global account
• sub-account
• space (Cloud Foundry)

글로벌 계정 생성

글로벌계정, 서브계정, 스페이스, 디렉토리 관계 블로그 글

Cloud Foundry 환경과 Kyma 환경.

• Cloud Foundry는 SAP가 액세스할 수 있는 제3자 환경이다.
  • space라는 공간을 갖는다.
• Kyma는 SAP 자체 환경이다.

애플리케이션 배포시 서브계정과 환경을 확인하고 해당 공간에 배포된다.

하위계정 생성

Destination

OData서비스가 생성되는 도메인 또는 호스트가 포함된다.

Destination에 포함되는 주요 정보

• Name: 앱에서 호출할 별명 (예: Northwind_Service)
• URL: 실제 데이터가 있는 주소 (예: https://services.odata.org/...)
• Proxy Type: 인터넷을 통할 것인지(Cloud), 내부망을 통할 것인지(On-Premise)
• Authentication: 어떤 방식으로 로그인할 것인지 (예: NoAuthentication, BasicAuthentication)

UFA (User Front-end Application)

SAP BTP 환경에서 사용자에게 보여지는 화면단(Front-end) 애플리케이션을 통칭하는 용어

스스로 데이터를 가지고 있지 않기 때문에, 반드시 외부(클라우드나 온프레미스)에 있는 OData 서비스를 호출해서 데이터를 가져와야 한다.

이때 데이터를 어디서 가져올지 알려주는 이정표가 바로 'Destination'다.

'내부 통신' vs '외부 연결'

• Destination이 필요한 이유: 주로 외부(External)에 있는 시스템과 연결할 때 사용한다.
• Destination이 필요 없는 이유: CAPM 프로젝트 안에는 보통 화면(UFA)과 백엔드(CAPM)가 같이 들어있다. Destination를 찾아보지 않고도 상대 경로(Relative Path)를 통해 바로 데이터를 주고받을 수 있다.

CAPM은 SAP Cloud Application Programming Model의 약자로 SAP 클라우드 환경에 최적화된 애플리케이션을 빠르고 표준화된 방식으로 만들기 위한 프레임워크다.

Trust Configuration

비즈니스 사용자가 어플리케이션에 로그온할 수 있도록 IDP를 하위 계정에 연결한다.

• IAS (Identity Authentication Service, 신원 인증 서비스)
• IDP (Identity Provider, 신원 제공자)

Instance and Subscriptions

SAP 엔터프라이즈 앱을 구축, 확장, 통합하기 위한 클라우드 플랫폼이다. 애플리케이션 개발, 통합, 자동화, 보안 및 ID, 데이터 및 분석을 제공한다. Colud Foundry, CAMA, ABAP환경을 지원한다.

SAP Fiori

SAP UI/UX 디자인 시스템 (디자인 원칙) 엔터프라이즈급 사용자 인터페이스를 만드는데 사용된다.

5가지 원칙

• Role-based
• adaptive
• Simple
• Coherent
• Delightful

SAP UI5 (SAP UI Development Toolkit for HTML5 )

SAP UI5는 반응형 웹 애플리케이션을 구축하는 데 사용되는 JavaScript 프레임워크(기술 프레임워크)

• MVC 아키텍처
• Data-binding (jasion, odata, resource)
• 라이브러리 컨트롤 지원(SAP.m,SAP.f, SAP.TNT 등)
• 반응형, 크로스 플랫폼

CAPM ( Cloud Application Programming Model)

SAP 클라우드 애플리케이션 프로그래밍 모델

• Node.js 또는 Java기반 프레임워크
• CDS 모델링 사용
• OData v4서비스 사용
• 보안, 유효성 검사 및 권한 부여 기능 내장
• BTP에 쉽게 배포가능

아키텍처 오버뷰

SAP UI5 APP 은 결국 프론트엔드 즉, 사용자 인터페이스 개발이다. 그리고 이 개발을 위해 Fiori 프레임워크인 UI5을 사용한다. JavaScript 컨트롤러를 사용해 이벤트와 그 처리 매커니즘을 이용한다.

그리고 CDS, handler, DB를 사용하여 CAMP 서비스에서 UI5로 데이터를 보낸다.

SAP BTP Cloud Foundary에 있는 HANA Cloud에 HANA DB를 구성한다.

• UI5앱은 CAPM Odata를 사용한다.
• CAMP는 Colud Foundary의 BTP에 배포되었다.
• UI5가 HTML5 앱저장소가 배포되었다.
• Fiori 런치패드는 UI5를 실행하고 IAS(Identity Authentication Service) 및 XS UAA(User Account and Authentication)가 인증을 처리한다.

UI5앱 end-to-end 학습순서

1. UI5앱 빌드
2. CAPM 서비스 생성
3. SAP BTP에 배포
4. 대상(destination)을 구성
5. 실시간 CRUD
6. Fiori 런치패드, TMS(테스트 <-> 프로덕션) 전송구조
7. 프로젝트

PBO(Process Before Output)와 PAI(Process After Input)라는

두 가지 핵심 이벤트와 화면 흐름 제어 명령어로 구성된다.

PBO는 화면이 사용자에게 보이기 전에 데이터를 준비하고 화면 속성을 제어하는 단계이며,

PAI 는 _사용자의 입력 값을 처리하고 비즈니스 로직을 실행_하는 단계다.

💡 PBO 시점에 스크린 만들어지고 있다. 끝날시점 스크린으로 값이 넘어온다.

💡 PAI 시작시점에 스크린으로 값이 넘어온다. (작업을 해야하니까) 끝날시점에 스크린이 사라진다.

입력값을 주고 엔터를 친다. 그 후 화면은 이전의 화면과 같은 화면일까 ?

NO.

화면은 PAI를 거쳐 Next Screen으로 이동하고, PBO로 새로운 스크린이 만들어진다. Next Screen이 같은 화면 번호여서 똑같아 보이지만 다른 스크린이 새로 생성된 것이다.

생명주기가 뭔데?

생물의 생명주기란 어떤 대상이 탄생해서 성장하고, 유지되다가 결국 소멸하는 일련의 과정을 의미한다.

ABAP에서 스크린 생명주기는 생물의 생명주기랑 비슷하다. 스크린 어떻게 만들어지고 유지되고 결국 소멸하고 또 다시 탄생하는 그 과정의 총칭이다. 그리고 대표적인 단계가 PBO, PAI다.

PBO/PAI가 정확히 뭔데?

PBO (Process Before Output)

이 단계는 화면이 사용자에게 보이기 직전에 실행되는 부분이다. 화면에 표시될 데이터를 준비하고, 입력 필드를 활성화하거나 비활성화하는 등 화면의 모습을 설정하는 역할을 한다.

PBO가 끝나면 비로소 화면이 사용자에게 나타나게 된다.

PAI (Process After Input)

이 단계는 사용자가 화면에 무언가를 입력하거나 버튼을 클릭하는 등 액션을 취했을 때 실행되는 부분이다. 사용자가 입력한 값을 프로그램으로 가져와서 유효한지 검사하고, 필요한 비즈니스 로직(예: 데이터 조회, 저장)을 수행하며, 다음 화면으로 이동할지 결정하는 등의 작업을 한다. PAI가 끝나면 다음 PBO가 실행되어 새로운 화면이 나타나거나, 현재 화면이 다시 표시될 수 있다.

그리고 다음 화면을 결정짓는 명령어는** SET SCREEN**이다.

SET SCREEN? 다음 스크린 설정과 생성

이미지에서 하이라이트 표시된 Next Dynpro가 바로 넥스트스크린을 _정적_으로 결정짓는 부분이다. (참고. 아무것도 입력되지 않으면 0으로 인식한다)

넥스트 스크린은 엑션으로 pai가 실행되고 나고 현재화면이 사라진뒤 다음에 보여질 스크린을 결정짓는다.

스크린에서 지정하고 싶지 않고, 동적으로 지정하고 싶다면 SET SCREEN을 사용한다.

이 말은 즉 슨, 기본적으로 Next Dynpro에 의해 정의된 스크린 번호가 넥스트 스크린을 결정하고, SET SCREEN 명령어를 사용한다면, 이 명령어로 선언된 스크린 번호가 넥스트 스크린이 된다는 것이다.

• ** SET SCREEN ** : "다음에 보여줄 화면을 미리 설정"하는 명령어

모호한가?

MODULE user_command_0100 INPUT.
  CASE ok_code.
    WHEN 'EXIT'.
      LEAVE PROGRAM.
    WHEN 'CANC'.
      SET SCREEN 0.
    WHEN 'BACK'.
      LEAVE TO SCREEN 0.
    WHEN 'S200'.
      SET SCREEN 0200."dynamic screen
      MESSAGE i999(zmcb00) WITH gv_carrid.
      LEAVE SCREEN."현재스크린 떠남

    WHEN 'ENTER'.

    WHEN OTHERS.
  ENDCASE.
ENDMODULE.

현재 스크린은 100. Next Dynpro은 100이다. (가장 일반적인 경우)

예시1) S200인 액션 100에서 pai를 탄다. 그리고 SET SCREEN에 의해서 next screen이 200으로 변한다. 현재화면 멈추고 메세지띄우고 (by type i) leave screen으로 현재 스크린을 떠난다. pbo로 넥스트스크린 200으로 이동(생성)한다.(기존스크린삭제됨)

예시2) ENTER를 입력했다면 100에서 pai를 탄다. pbo로 Next Dynpro인 100으로 이동(생성)한다.(기존스크린삭제됨)

이해가 될 것이다. 화면에 대한 명령어가 없다면 스크린의 기본 설정 Next Dynpro에 따라서 다음 스크린이 결정되고,

SET SCREEN이 있다면 그것에 해당하는 스크린이 다음 스크린이 된다.

주의할 점. LEAVE TO SCREEN.

• ** LEAVE TO SCREEN**: "현재 화면을 즉시 종료하고 지정된 화면으로 이동"하는 명령어'

SET SCREEN 0. LEAVE SCREEN.

= LEAVE TO SCREEN 0.

이걸 왜 주의해야할까? SET SCREEN은 단순히 다음 스크린을 설정하는거지 현재 화면을 끝내(종료)는 것이 아니라는 것이다.

LEAVE SCREEN이 있어야 즉시, 현재 화면이 끝나고 다음 스크린으로 넘어가는것이다.

즉, 이 명령어가 있다면 뒤에 정의된 함수 및 로직은 무시된다.

왜냐? 현재 스크린이 제거되었는걸?

자 그럼 question 하나 더

WHEN 'S200'.
      SET SCREEN 0200."dynamic screen
      MESSAGE i999(zmcb00) WITH gv_carrid.

여기서는 메세지는 보일까? YES.

SET SCREEN은 다음스크린을 설정할 뿐, 현재 화면을 즉시 종료하지는 않는다.

뒤로가기? 스크린 삭제.

자, 이제 넥스트 스크린으로 이동. 스크린 100 -> 스크린 200으로 이동하기에 대한 pbo/pai 간단한 설명을 끝냈다.

이번에는 뒤로가기다.

가장 흔히 쓰는 뒤로가기는 LEAVE TO SCREEN 0 명령어다.

 WHEN 'BACK'.
      LEAVE TO SCREEN 0.

앞서 말했듯 SET SCREEN 0, LEAVE TO SCREEN을 합친 형태다.

넥스트 스크린을 0으로 설정한다는건 어떤 의미일까? 0은 없는 화면이다. 그래서 0으로 이동할려고하면 프로그램이 종료되거나 기존에 남아있던 화면으로 돌아간다.

지금 현재 화면은 200으로 스크린은 100 -> 200으로 왔다.

그럼 기존 100은 남아있는건가..? NO.

앞서 말했듯 기존 스크린은 삭제되고 넥스트 스크린(여기서는 set screen 설정에 의해)으로 200이 새로 생긴것이다.

100은 사라지고, 200만 남았다.

그래서 SET SCREEN은 다음 화면을 설정하고 현재 화면을 종료하여 메모리를 효율적으로 사용한다.

다시 돌아가서 그러면 200에서 뒤로가기 즉 LEAVE TO SCREEN 0.을 사용한다면?

넥스트 스크린을 0으로 설정하고 현재 스크린을 제거한다. 그 결과 프로그램이 종료된다. 왜냐? 스크린 0은 없다.

그럼 어떻게 해야 다시 100으로 돌아갈 수 있는가? 앞서 말한 SET SCREEN을 다시 써주면 된다. SET SCREEN 100으로 말이다.

한가지 더, 만약 아래처럼 아무것도 입력을 안한다면? nextnpro를 통해 넥스트 스크린으로 이동할 것이다. 그리고 nextnpro은 일반적으로 자기자신이다.

 WHEN 'BACK'.

이제 반복에 반복을 했으니 다음 Call Screen으로 넘어가자.

Call Screen.

• ** CALL SCREEN ** : 현재 화면 위에 "새로운 화면을 덮어씌우듯이 호출"하는 방식

전공생이나 이 개발직 공부를 해봤다면 사실 이게 더 이해하기가 쉬울 것이다. CALL STACK이 익숙할테니.

앞선 스크린은 현재스크린을 삭제하고 넥스트 스크린을 생성하는 방식이었다.

콜스크린은 현재스크린을 삭제하지 않고, 잠시 홀딩시킨 상태에서 넥스트 스크린을 그 위에 쌓는다. (STACK과 같은 구조)

그래서 로직도, 코드도 조금 다르다.

MODULE user_command_0100 INPUT.
  CASE ok_code.
        ...
    WHEN 'BACK'.
      LEAVE TO SCREEN 0.
      ...
    WHEN 'C200'.
      CALL SCREEN 0200.
    WHEN OTHERS.
  ENDCASE.
ENDMODULE.

MODULE user_command_0200 INPUT.
  CASE sy-ucomm.
    WHEN 'BACK'.
      LEAVE TO SCREEN 100.
    WHEN 'C100'.
      CALL SCREEN 0100.
    WHEN OTHERS.
  ENDCASE.
ENDMODULE.

자 다시 해보자 초기 스크린은 100이다.

Fuction code C200 액션이 발생한다. 그럼 CALL SCREEN으로 200을 호출한다.

그리고 스크린 200의 pbo을 통해 200스크린이 보이고 생성된다. (스크린 100 위에 쌓인다. 스크린 100이 제거되지 않음).

스크린 200에서 뒤로 가기를 하면? LEAVE TO SCREEN 100. 으로 현재 스크린으로 종료하고 스크린 100으로 이동(생성한다).

=> 여기서 주목할 점

뒤로가기할때 LEAVE TO SCREEN 100.을 하면 이전 스크린 100으로 돌아오는 것이 아니고 100이 새로 생성된다는 것이다.

200에서 뒤로가기하며 next screen 100으로 이동

200의 pai가 종료되면서 새로운 스크린(100)으로 이동

(200이 100으로 대체된다고 생각하면됨)

빈약하지만 플로우를 도식화하면 아래와 같다.

200 → 뒤로가기(next 100) → 100 → 뒤로가기 (next 스크린 0)→사라짐 -> 100 → 뒤로가기 (next 스크린 0)→사라짐

그래서 뒤로가기를 두번을 해야지 기존 스크린 100으로 돌아가야하는 상황이 생긴다. 불필요한 클릭을 한 번 더 해야하는것이다.

한번에 이전의 스크린 100으로 돌아갈려면?

MODULE user_command_0100 INPUT.
  CASE ok_code.
        ...
    WHEN 'BACK'.
      LEAVE TO SCREEN 0.
      ...
    WHEN 'C200'.
      CALL SCREEN 0200.
    WHEN OTHERS.
  ENDCASE.
ENDMODULE.


MODULE user_command_0200 INPUT.
  CASE sy-ucomm.
    WHEN 'BACK'.
      LEAVE TO SCREEN 0.
    WHEN 'C100'.
      CALL SCREEN 0100.
    WHEN OTHERS.
  ENDCASE.
ENDMODULE.

100→200→100 ⇒ back을 한 번하면 초기화면으로 이동.

바뀐 것은 user_command_0200의 BACK 부분이다. 100이 0으로 바뀌었다.

WHEN 'BACK'.
      LEAVE TO SCREEN 0.

200에서 뒤로가기하며 스크린 삭제되고 next screen 0으로 이동한다.. pai가 끝나면서 새로운 스크린(0)으로 이동해야하는데 없다. 그러면 전에 있던 스크린 100으로 이동한다.

콜스크린에서는 이전 스크린으로 돌아오기 위해서는 넥스트스크린 설정을 0으로 해야한다.

MODULE user_command_0100 INPUT.
  CASE ok_code.

    WHEN 'CANC'.
      SET SCREEN 0.
*      LEAVE SCREEN.
    WHEN 'BACK'.
      LEAVE TO SCREEN 0.

    WHEN 'C200'.
      CALL SCREEN 0200.

      CLEAR gv_carrname.
      SELECT SINGLE carrname
        FROM scarr
        INTO gv_carrname
        WHERE carrid = gv_carrid.

    WHEN 'ENTER'.

    WHEN OTHERS.
  ENDCASE.
ENDMODULE.

100 → 200으로 콜스크린이 이동되면

그 밑에는 홀딩된다.

그리고 200에서 뒤로가기로 기존 100으로 돌아오면, select 구문 실행된다.

그래서 처음 100에서 200으로 콜스크린 이동시에는 gv_carrname 결과값이 보이지 않지만 (왜냐면 select 구문이 아직 실행안됨)

100으로 돌아온 후 콜스크린 이동시에, gv_carrname이 반영(적용)된다.

그래서 한발자국씩 늦게 보인다.

이 문제를 해결하는 법은 간단하다 select 구문을 먼저 실행시키고 콜 스크린을 하면 된다.

[CALL, SET, LEAVE]

한 번 더 꼬아서 보기

스크린 100의 nextnpro 200으로 설정한다면, + 콜 스크린

100의 PAI에서 콜스크린으로 200이 불러와지고,

200에서 뒤로가기로 leave to screen 0로

200스크린이 삭제된다.

다시 100으로 돌아온다.

계속 100의 PAI구문 실행된다.

별다른 set screen 설정이 없기때문에

next screen으로 200이 생성된다. (nextnpro 200. 기존 100은 삭제됨)

여기서 뒤로가기를 하면

스크린은 200밖에 없으므로

leave to screen 0이 의해 현재 스크린 삭제되고, 초기화면으로 돌아간다.(프로그램 종료)

그래서 동작은

100 → 200

200에서 뒤로가기 ⇒ 200

200에서 뒤로가기 ⇒ 프로그램 종료.

SAP ABAP 개발 과정 및 예비 개발자들을 위해, ABAP 프로그램 구조, 시스템 설치, UI5/Fiori, SAP BTP, RFC/BAPI/CDS 기술까지 포함한 실무 대비용 기술 노트입니다.

❓ 기술 질문 요약

• 도메인: 타입, 길이, 값 범위 등 기술적 속성
• 데이터 엘리먼트: 설명, 레이블 등 의미적 속성

🛠 SAP 설치 환경 구성

• Oracle VirtualBox: 가상머신
• openSUSE: SAP 서버 설치용 리눅스 배포판
• SAP Logon: SAP 접속용 클라이언트 프로그램
• su / sudo: 계정 전환 및 root 명령 실행
• npladm: SID가 NPL인 SAP 시스템 관리자 계정
• chmod: 파일 권한 변경 명령어
• 포트 포워딩: 호스트 포트 ↔ 게스트 포트 연동 방식

🌐 UI5, Fiori, Launchpad

• SAPUI5: SAP 제공 웹 애플리케이션 개발 프레임워크
• Fiori: SAPUI5 기반 웹 앱 (모바일 친화적)
• Fiori Launchpad: Fiori 앱을 통합 제공하는 대시보드
• STC01 (TCODE): SAP_GW_FIORI_ERP_ONE_CLNT_SETUP 수행 → 여러 권한·서비스 자동 세팅

🧾 ABAP 리포트와 ALV

• Report: ABAP에서 가장 기본적인 프로그램 유형 (조건에 따라 조회 및 결과 출력)
• ALV: 데이터를 표 형태로 출력하는 도구 (REUSE_ALV_GRID_DISPLAY, CL_GUI_ALV_GRID 등)
• Type Pool SLIS: ALV용 타입/상수 정의 집합

TYPE-POOLS: SLIS.
DATA: fieldcatalog TYPE slis_t_fieldcat_alv WITH HEADER LINE.
fieldcatalog-fieldname = 'MANDT'.
fieldcatalog-seltext_m = 'Client'.
fieldcatalog-do_sum = 'X'.

ALV 레이아웃 예시

DATA: gd_layout TYPE slis_layout_alv.
gd_layout-zebra = 'X'.
gd_layout-colwidth_optimize = 'X'.
gd_layout-info_fieldname = 'LINE_COLOR'.

ALV 정렬

DATA: gd_sort TYPE slis_t_sortinfo_alv WITH HEADER LINE.
gd_sort-spos = 1.
gd_sort-fieldname = 'CARRID'.
gd_sort-up = 'X'.
gd_sort-subtot = 'X'.

🧮 선택화면(Selection-Screen) 흐름 정리

SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME.
  PARAMETERS: p_file TYPE rlgrap-filename.
SELECTION-SCREEN END OF BLOCK b1.

📋 주요 문법 요약

• TYPE STANDARD TABLE OF: 특정 타입의 내부 테이블 선언
• WITH HEADER LINE: 테이블 + 동일 구조의 워크 에어리어 생성
• LIKE: 기존 오브젝트의 타입을 따라 선언

📦 도움말 (F4) 제공 예시

AT SELECTION-SCREEN ON VALUE-REQUEST FOR s_cname-low.
  DATA: it_return_tab TYPE ddshretval OCCURS 0 WITH HEADER LINE.
  CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
    EXPORTING
      retfield = 'CARRNAME'
      dynprofield = 's_cname-low'
    TABLES
      value_tab = it_f4help3
      return_tab = it_return_tab.

🔽 사용자 정의 드롭다운 (LISTBOX)

TYPE-POOLS: vrm.
DATA: lt_droplist TYPE vrm_values.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_carrid.
  SELECT carrid AS key, carrid && ' ' && carrname AS text
    FROM scarr INTO TABLE @lt_droplist.
  CALL FUNCTION 'VRM_SET_VALUES'
    EXPORTING id = 'p_carrid' values = lt_droplist.

🔁 JOIN 종류

➕ COLLECT 문

• 동일 키 존재 시: 숫자 필드 합산
• 키 미존재 시: 새로운 행 추가

DATA: lt_itab TYPE TABLE OF ty_itab WITH HEADER LINE.
COLLECT lt_itab.

🔄 시스템 변수

🧠 BDC vs BAPI

🔗 관련 개념

📌 BTP (SAP Business Technology Platform)

• SAP의 클라우드 PaaS
• 통합, 데이터, 앱, AI 기능 포함

📌 RAP (RESTful ABAP Programming)

• S/4HANA 기반 ABAP 개발 모델
• CDS + Behavior + 서비스로 구성

📌 CDS (Core Data Services)

• SQL 기반 View
• JOIN, 집계, UI annotation 가능
• 고성능 + Fiori 연계 용이

📌 RFC (Remote Function Call)

• 시스템 간 함수 호출 표준 방식
• CALL FUNCTION IN DESTINATION 형태로 사용

🟦 INITIALIZATION

프로그램 실행 직후, 선택화면 뜨기 전에 1회 실행

INITIALIZATION.
  SY-TITLE = '엑셀 업로드 프로그램'.
  r1 = 'X'. " 기본값 설정

🟨 AT SELECTION-SCREEN OUTPUT

선택화면이 사용자에게 보여지기 직전에 실행 (필드 제어용)

AT SELECTION-SCREEN OUTPUT.
  LOOP AT SCREEN.
    IF screen-name = 'P_FILE' AND r2 = 'X'.
      screen-active = 0.
      MODIFY SCREEN.
    ENDIF.
  ENDLOOP.

🟩 AT SELECTION-SCREEN ON VALUE-REQUEST

특정 필드에 F4 도움말 요청 시 실행

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_file.
  PERFORM get_file_path. " 파일 탐색기 열기

🟧 AT SELECTION-SCREEN

실행버튼 또는 Function Key 클릭 시 전체 유효성 검사

AT SELECTION-SCREEN.
  PERFORM act_function_key. " 양식다운로드 처리

🟥 START-OF-SELECTION

선택화면 통과 후 본 로직 시작

START-OF-SELECTION.
  PERFORM upload_from_excel.

🟪 END-OF-SELECTION

데이터 처리 후 화면 출력 등

END-OF-SELECTION.
  CALL SCREEN 100. " ALV 출력

SAP ABAP을 활용하여 항공사 예약 정보를 조회하고, 고객 정보를 ALV로 시각화하는 프로그램을 개발했습니다.

*주요기능 *

• 항공편 조건에 따른 예약정보 조회

• 취소 여부 필터링

• 고객 상세 정보 팝업 조회

• 빠른 예약 고객 Top 5 추출 및 출력

SAP 내부 테스트 테이블(ZSBOOK, SCUSTOM 등)을 기반으로 진행되었으며, 핫스팟 이벤트 및 사용자 정의 툴바, 이중 ALV 출력

📋 사용 기술

프로그램 구조

ZPORTFOLIO_ARS ├─ ZPORTPOLIO_ARS_TOP : 전역변수 선언 ├─ ZPORTPOLIO_ARS_SEL : 선택화면(SELECTION-SCREEN) ├─ ZPORTPOLIO_ARS_C01 : ALV 이벤트 클래스 ├─ ZPORTPOLIO_ARS_F01 : 데이터 조회, ALV 출력 Form들 ├─ ZPORTPOLIO_ARS_I01 : 화면 입력 처리 └─ ZPORTPOLIO_ARS_O01 : ALV 출력 및 화면 구성

💡 핵심 기능 설명

📌 1. 조건별 예약 데이터 조회 (GET_DATA)

SELECTION-SCREEN에서 입력한 항공사, 항공편, 출발일 조건으로 예약 조회

SELECTION-SCREEN BEGIN OF BLOCK BL01 WITH FRAME TITLE TEXT-001.
*   검색조건
PARAMETERS: p_air TYPE sbook-carrid OBLIGATORY,   
            p_conn   TYPE sbook-connid OBLIGATORY,    
            p_date   TYPE sbook-fldate.    
SELECTION-SCREEN END OF BLOCK BL01.

SELECTION-SCREEN BEGIN OF BLOCK BL02 WITH FRAME TITLE TEXT-002.
  SELECT-OPTIONS: s_cust FOR scustom-id NO-EXTENSION.
  PARAMETERS: r1 RADIOBUTTON GROUP rad DEFAULT 'X',
              r2 RADIOBUTTON GROUP rad,
              r3 RADIOBUTTON GROUP rad.
SELECTION-SCREEN END OF BLOCK BL02.

r1/r2/r3 라디오버튼에 따라 전체 / 취소 / 미취소 필터링

START-OF-SELECTION.

  IF r1 = 'X'.
    gv_cancelled = ''.
  ELSEIF r2 = 'X'.
    gv_cancelled = space.  " 취소되지 않은 예약
  ELSEIF r3 = 'X'.
    gv_cancelled = 'X'.    " 취소된 예약
  ENDIF.

  PERFORM get_data.                      " 1단계: 데이터 조회
  PERFORM apply_filter_condition.       " 2단계: 필터 조건별 분류

END-OF-SELECTION.


IF GT_TABLE IS INITIAL.
  MESSAGE '조회할 데이터가 없습니다.' TYPE 'I'.
ELSE.
  CALL SCREEN 100.
ENDIF.

FORM get_data.
  CLEAR gt_table.

  IF r1 = 'X'.
   SELECT
    a~carrid, a~connid, a~fldate, a~bookid, a~customid, a~CUSTTYPE,
    a~loccuram, a~loccurkey, a~order_date, a~cancelled,
    b~carrname,
    c~name      AS custname,
    c~telephone
    INTO CORRESPONDING FIELDS OF TABLE @gt_table
    FROM  zsbook AS a
    INNER JOIN scarr AS b ON a~carrid = b~carrid
    INNER JOIN scustom AS c ON a~customid = c~id
    WHERE a~carrid   = @p_air
      AND a~connid   = @p_conn
      AND a~fldate   = @p_date
      AND a~customid IN @s_cust.

  ELSE.
    SELECT
      a~carrid, a~connid, a~fldate, a~bookid, a~customid, a~CUSTTYPE,
      a~loccuram, a~loccurkey, a~order_date, a~cancelled,
      b~carrname,
      c~name      AS custname,
      c~telephone
      INTO CORRESPONDING FIELDS OF TABLE @gt_table
      FROM  zsbook AS a
      INNER JOIN scarr AS b ON a~carrid = b~carrid
      INNER JOIN scustom AS c ON a~customid = c~id
      WHERE a~carrid   = @p_air
        AND a~connid   = @p_conn
        AND a~fldate   = @p_date
        AND a~customid IN @s_cust
        AND a~cancelled = @gv_cancelled.
   ENDIF.

ENDFORM.

ZSBOOK, SCARR, SCUSTOM 조인 SELECT

📌 2. 남은 일수 계산 + 상태 아이콘 표시 (SET_STATUS_ICON)

예약일과 출발일 차이 계산

남은 일수 100 이상: 초록불, 50 이상: 노랑불, 그 외: 빨강불 표시

특정 조건(>=150)은 셀 강조 색상까지 설정 (CELL COLOR)

전체조회 모드일때 취소된 예약은 빨간색 배경색 지정.

<== gt_table
...
DATA LINECOLOR(4)     TYPE C.   ==> 라인 컬러
DATA CELLSCOL  TYPE LVC_T_SCOL. ==> 셀 컬러
...
==>

FORM apply_filter_condition.
  LOOP AT gt_table INTO gs_table.
    IF r1 = 'X'. " 전체 조회일때
      IF gs_table-cancelled = 'X'.
         gs_table-linecolor = 'C611'.  ==> 라인 컬러
      ENDIF.
    ENDIF.

    PERFORM set_status_icon CHANGING gs_table.
    MODIFY gt_table FROM gs_table.
  ENDLOOP.
ENDFORM.


FORM set_status_icon CHANGING gs_table LIKE gs_table.
  DATA: LS_COLOR TYPE LVC_S_SCOL. 
  DATA: lv_days_left TYPE i.

  lv_days_left =  gs_table-fldate - gs_table-order_date .
  gs_table-days = lv_days_left.

  IF lv_days_left >= 150.
      LS_COLOR-FNAME = 'DAYS'.
      LS_COLOR-COLOR-INT = 1.
      LS_COLOR-COLOR-INV = 1.
      LS_COLOR-COLOR-COL = 5.
      APPEND LS_COLOR TO gs_table-CELLSCOL. ==> 셀 컬러
  ENDIF.

  IF lv_days_left >= 100.
    gs_table-zstatus = ICON_LED_GREEN.  " 초록불
  ELSEIF lv_days_left >= 50.
    gs_table-zstatus = ICON_LED_YELLOW. " 노랑불
  ELSE.
    gs_table-zstatus = ICON_LED_RED.    " 빨강불
  ENDIF.
ENDFORM.

FORM set_layout .
  gs_layout-zebra = 'X'.
  gs_layout-cwidth_opt = 'X'.
  gs_layout-sel_mode   = 'D'.
  gs_layout-info_fname ='LINECOLOR'. " 라인 컬러
  gs_layout-ctab_fname = 'CELLSCOL'. " 셀 컬러
ENDFORM.

📌 3. 고객 ID 핫스팟 클릭 → 고객 상세 팝업 (handle_hotspot_click)

ALV 내 CUSTOMID 필드에 Hotspot 설정

클릭 시 선택한 고객 ID를 gv_cid에 저장 후, SCREEN 200 호출

FORM set_fildcat .
  DEFINE _fcat.
    CLEAR gs_fcat.
    gs_fcat-fieldname  = &1.
    gs_fcat-coltext    = &2.
    gs_fcat-key        = &3.
    gs_fcat-edit       = &4.
    gs_fcat-outputlen  = &5.
    gs_fcat-lowercase  = &6.
    gs_fcat-col_pos    = &7.
    APPEND gs_fcat TO gt_fcat.
  END-OF-DEFINITION.

  _fcat: 'ZSTATUS'   '상태'             ''  '' '3'  ''  '1',
         'CARRID'    'Airline Code'    'X' '' '6'  ''  '2',
         'CARRNAME'  'Airline Name'    'X' '' '20' ''  '3',
         'CONNID'    'Flight No.'      'X' '' '6'  ''  '4',
         'FLDATE'    'Flight Date'     'X' '' '10' ''  '5',
         'BOOKID'    'Booking'         'X' '' '6'  ''  '6',
         'CUSTOMID'  'Cust. No.'       ''  '' '10' ''  '7',
         'CUSTNAME'  'Customer Name'   ''  '' '20' ''  '8',
         'TELEPHONE' 'Telephone No.'   ''  '' '15' ''  '9',
         'CUSTTYPE'  'B/P Type'        ''  '' '4'  ''  '10',
         'LOCCURAM'  'Amount'          ''  '' '10' ''  '11',
         'LOCCURKEY' 'Curr.'           ''  '' '5'  ''  '12',
         'ORDER_DATE' 'Booking Date'   ''  '' '10' ''  '13',
         'DAYS'      'DAYS'            ''  '' '10' ''  '14',
         'CANCELLED' 'Cancelled'       ''  '' '1'  ''  '15'.

* HOTSPOT 필드 설정
  LOOP AT gt_fcat INTO gs_fcat WHERE fieldname = 'CUSTOMID'.
    gs_fcat-hotspot = 'X'.
    MODIFY gt_fcat FROM gs_fcat.
  ENDLOOP.
ENDFORM.

스크린 200 => Modal dialog box로 설정 => 스크린페인터로 dictionary/program field 에서 scustom 필드 불러와서 그리기

FORM display_alv_0100 .
  CREATE OBJECT g_event_receiver.
  SET HANDLER g_event_receiver->handle_hotspot_click FOR go_grid.
  SET HANDLER g_event_receiver->HANDEL_TOOLBAR FOR go_grid.
  SET HANDLER g_event_receiver->HANDEL_USER_COMMAND FOR go_grid.

 CALL METHOD GO_GRID->SET_TABLE_FOR_FIRST_DISPLAY
    EXPORTING
      IS_LAYOUT                     = GS_LAYOUT
    CHANGING
      IT_OUTTAB                     = GT_TABLE
      IT_FIELDCATALOG               = GT_FCAT.

ENDFORM.

GO_GRID 에 이벤트 리시버 등록

CLASS lcl_event_receiver DEFINITION DEFERRED.
DATA: g_event_receiver TYPE REF TO lcl_event_receiver.

*--------------------------------------------------
* 클래스 선언
*-------------------------------------------------
CLASS lcl_event_receiver DEFINITION.
  PUBLIC SECTION.

  " 핫스팟 클릭 이벤트 
  METHODS : handle_hotspot_click
    FOR EVENT hotspot_click OF CL_GUI_ALV_GRID
    IMPORTING e_row_id e_column_id.

  " 툴바 보여주는용 함수.
  METHODS : HANDEL_TOOLBAR
    FOR EVENT TOOLBAR OF CL_GUI_ALV_GRID
    IMPORTING E_OBJECT.

  " 툴바 클릭시 발생하는 ucomm을 갖고 작동하는 함수.
  METHODS : HANDEL_USER_COMMAND
    FOR EVENT USER_COMMAND OF CL_GUI_ALV_GRID
    IMPORTING E_UCOMM.
ENDCLASS.
*--------------------------------------------
* 클래스 구현
*--------------------------------------------
CLASS lcl_event_receiver IMPLEMENTATION.

  METHOD handle_hotspot_click.
    DATA: tmp_gt_table LIKE LINE OF gt_table.
    READ TABLE gt_table INDEX e_row_id-index INTO tmp_gt_table.

    IF sy-subrc = 0.
      gv_cid = tmp_gt_table-customid. "> 선택된 고객id

      CALL SCREEN 200 STARTING AT 16   1
                      ENDING   AT 77  20.
    ENDIF.
  ENDMETHOD.

  METHOD HANDEL_TOOLBAR.
    PERFORM HANDEL_TOOLBAR USING E_OBJECT.
  ENDMETHOD.

  METHOD HANDEL_USER_COMMAND.
    PERFORM HANDEL_USER_COMM USING e_ucomm.
  ENDMETHOD.

ENDCLASS.

콜스크린 실행 결과 모달화면, PBO실행

MODULE status_0200 OUTPUT.

 SET TITLEBAR '200' WITH '고객 정보'.
 SET PF-STATUS 'ZSTAT'.

ENDMODULE.

MODULE set_alv_0200 OUTPUT.

  PERFORM get_customer.

ENDMODULE.


FORM get_customer.

  SELECT SINGLE *
    FROM scustom
    WHERE id = gv_cid.

ENDFORM.

선택된 id기준으로 scustom에서 정보 불러와서 자동으로 스크린에 SET.

📌 4. 툴바 버튼 → 빠른 예약 고객 Top 5 조회 (handle_toolbar)

사용자 정의 툴바 버튼에 SHOW 명령 연결

클릭 시 남은 일수 기준 Top 5 고객 정렬 → ALV 출력 (화면 250)

METHODS : HANDEL_TOOLBAR
  FOR EVENT TOOLBAR OF CL_GUI_ALV_GRID
  IMPORTING E_OBJECT.

CL_GUI_ALV_GRID의 TOOLBAR 이벤트 발생 시 호출. ( e_object 객체를 전달받는 이벤트 핸들러 )

*&---------------------------------------------------------------------*
*& Form HANDEL_TOOLBAR
*&---------------------------------------------------------------------*
*& text
*&---------------------------------------------------------------------*
*&      --> E_OBJECT
*&---------------------------------------------------------------------*
FORM handel_toolbar  USING PO_OBJECT TYPE REF TO CL_ALV_EVENT_TOOLBAR_SET.
  DATA : LS_TOOLBAR TYPE STB_BUTTON. " STB_BUTTON: 툴바 버튼의 속성

  LS_TOOLBAR-ICON = ICON_CUSTOMER.
  LS_TOOLBAR-FUNCTION = 'SHOW'.
  LS_TOOLBAR-TEXT = 'Early Booked Top 5 Customer'.
  APPEND LS_TOOLBAR TO PO_OBJECT->MT_TOOLBAR.

  CLEAR  ls_toolbar.
ENDFORM.

SAP는 모든 이벤트마다 하나의 객체를 넘겨주고, 그 객체 내부 필드를 조작해서 원하는 기능을 추가하라는 구조를 채택함. "버튼 테이블만 채우면 알아서 툴바가 만들어지는" 방식으로 일관성을 유지

FORM handel_user_comm  USING    p_ucomm.
 CASE p_ucomm.
    WHEN 'SHOW'.
      CALL SCREEN 250 STARTING AT 16   5
                      ENDING   AT 62  13.
  ENDCASE.
ENDFORM.

ALV에서 사용자가 버튼을 클릭하거나 특정 동작을 할 때, SY-UCOMM 타입의 기능 코드를 E_UCOMM이라는 이름으로 이벤트 파라미터에 담아 전달. (여기서는 툴바 클릭시)

MODULE set_alv_0250 OUTPUT.

  IF GO_CUSTOM IS INITIAL.

    PERFORM create_object_instance_250.

    PERFORM get_customer_top5.

    PERFORM set_fildcat_250.

    PERFORM set_layout_250.

    PERFORM display_alv_0250.

  ENDIF.

ENDMODULE.

*&---------------------------------------------------------------------*
*& Form GET_CUSTOMER_TOP5
*&---------------------------------------------------------------------*
*& 전체 예약 데이터(GT_TABLE)에서 고객ID/이름/남은일수 정보 추출
*& → 남은 일수 기준으로 정렬하여 Top 5 고객만 GT_CUST에 저장
*&---------------------------------------------------------------------*
FORM get_customer_top5.

  " 1. 초기화
  CLEAR gt_cust.

  " 2. 예약 테이블 루프 → 고객 정보 구조에 매핑
  LOOP AT gt_table INTO gs_table.
    CLEAR gs_cust.
    MOVE-CORRESPONDING gs_table TO gs_cust.
    APPEND gs_cust TO gt_cust.
  ENDLOOP.

  " 3. 남은 일수(DAYS) 기준 내림차순 정렬
  SORT gt_cust BY days DESCENDING.

  " 4. 상위 5개 항목만 남기고 나머지 삭제
  DELETE gt_cust FROM 6 TO LINES( gt_cust ).

ENDFORM.

*&---------------------------------------------------------------------*
*& Form CREATE_OBJECT_INSTANCE_250
*&---------------------------------------------------------------------*
FORM create_object_instance_250 .

  CREATE OBJECT GO_CUSTOM
    EXPORTING
      CONTAINER_NAME = 'CON1'.   "Custom Control 이름

  CREATE OBJECT GO_GRID2
    EXPORTING
      I_PARENT = GO_CUSTOM.
ENDFORM.

커스텀 컨트롤러 생성 GO_CUSTOM

*&---------------------------------------------------------------------*
*& Form SET_FILDCAT_250
*&---------------------------------------------------------------------*
*& text
*&---------------------------------------------------------------------*
*& -->  p1        text
*& <--  p2        text
*&---------------------------------------------------------------------*
FORM set_fildcat_250 .

  DEFINE _fcat2.
    CLEAR GS_FCAT2.
    GS_FCAT2-FIELDNAME  = &1.
    GS_FCAT2-COLTEXT    = &2.
    GS_FCAT2-KEY        = &3.
    GS_FCAT2-OUTPUTLEN  = &4.
    GS_FCAT2-LOWERCASE  = &5.
    APPEND GS_FCAT2 TO GT_FCAT2.
  END-OF-DEFINITION.

  _fcat2: 'CUSTOMID'  '고객ID'    'X'  '8'   '',
          'CUSTNAME'  '고객명'     ''  '25'  '',
          'DAYS'      '남은일수'    ''  '4'   ''.

ENDFORM.

FORM display_alv_0250.
  APPEND cl_gui_alv_grid=>mc_fc_excl_all TO GT_FUNCTIONS.

  CALL METHOD GO_GRID2->SET_TABLE_FOR_FIRST_DISPLAY
    EXPORTING
      IS_LAYOUT       = GS_LAYOUT2
      it_toolbar_excluding = GT_FUNCTIONS
    CHANGING
      IT_OUTTAB       = GT_CUST
      IT_FIELDCATALOG = GT_FCAT2.
ENDFORM.

UI_FUNCTIONS : UI_FUNC(function code)로 이루어진 테이블

MC_FC_EXCL_ALL은 SAP가 정의한 기능 코드 상수.

mc_fc_excl_all = '&EXCLALLFC' (상수. 펑션코드).

이 값이 UI_FUNC 타입 테이블 (GT_FUNCTIONS)에 들어가면, SAP는 “ALV 표준 기능 전부 비활성화”라고 인식

it_toolbar_excluding: 특정 툴바 버튼을 제외하기 위한 목록 → 위에서 'mc_fc_excl_all'을 넣었으므로 모든 버튼이 제거됨

TCODE : STC01

Task list SAP-GATEWAY-BASIC-CONFIG does not exist

Message no. STC_TM013

대신 SAP_GW_FIORI_ERP_ONE_CLNT_SETUP 을 실행( 베이직 컨피그와 , 피오리 런치패드 초기화 셋업 포함되어있음)

홈화면에 피오리 런치패드 즐겨찾기 추가됨

지금 상태로는 연결안됨. 호스트 설정과 포트포워딩 설정 필요.

호스트 설정

C드라이버\ Windows\ System32\drivers\etc

127.0.0.1 vchcl.dummy.no-domain

127.0.0.1 localhost

내 컴퓨터에서 localhost 또는 vchcl.dummy.no-domain으로 접속 시 항상 127.0.0.1(즉, 내 PC 자신)로 연결됩니다.

HTTP 쓸 수 있는 게이트웨이 => 8000번, 34300번

포트포워딩 설정

호스트 IP/포트: 내 PC(호스트)에서 접근할 때 사용할 주소와 포트 (예: 127.0.0.1:3200)

게스트 IP/포트: 가상머신(게스트) 내부에서 실제 서비스가 동작하는 주소와 포트 (예: 10.0.2.15:3200)

예를 들어, 내 PC에서 127.0.0.1:3200으로 SAP GUI 클라이언트로 접속하면, 이 요청이 자동으로 가상머신의 10.0.2.15:3200으로 전달됩니다.

1. CDS 뷰란 무엇인가?

CDS 뷰는 SQL 기반의 뷰(View)를 보다 강력하게 확장한 SAP의 데이터 정의 언어입니다.
기존 ABAP SQL이 가진 한계를 극복하며, 성능과 가독성 모두를 갖춘 데이터 모델링 방식으로 각광받고 있습니다.

✅ CDS 뷰는 성능, 구조화, 연동 측면에서 기존 SQL 뷰보다 유리합니다.

2. CDS 뷰 개발 환경 구축

CDS 뷰는 Eclipse 기반 개발환경에서 작성됩니다.

✅ 환경 구축 절차

1. Eclipse 설치
2. Help > Install New Software → SAP HANA 플러그인 설치
3. SAP BTP 또는 ABAP 플랫폼 선택 후 설치 진행
4. New > ABAP Project 생성 후 SAP 서버 접속 (ID, PW, Client 입력)
5. ABAP 프로젝트 내에서 CDS 뷰 작성

✍️ CDS 뷰 생성 위치

• ABAP 프로젝트 내부의 패키지
  → New > Other > Core Data Services > Data Definition

3. CDS 뷰 문법 및 활용 예시

CDS 뷰는 SQL SELECT 구문과 유사하게 작성되며, 다양한 내장 함수 및 연산을 지원합니다.

✅ 기본 문법 예시

@AbapCatalog.sqlViewName: 'ZVIEW_EXAMPLE'
define view ZCDS_SALES as select from sflight
{
  carrid,
  connid,
  seatsocc,
  price,
  round( price / seatsocc, 2 ) as avg_price_per_seat
}

✅ 기존 ABAP SQL의 한계 vs CDS 뷰의 개선 예시

📌 예시 1: 다단계 조인 / 읽기 복잡성

❌ ABAP Open SQL

기존 ABAP에서는 여러 테이블을 조인하려면 반복적으로 SELECT, LOOP, READ TABLE 등의 복잡한 구문을 사용해야 했습니다.

SELECT * FROM sflight INTO TABLE @DATA(lt_sflight).

LOOP AT lt_sflight INTO DATA(ls_sflight).
  SELECT SINGLE carrname INTO @DATA(lv_carrname)
    FROM scarr
    WHERE carrid = @ls_sflight-carrid.
ENDLOOP.`

✅ CDS 뷰

CDS 뷰에서는 조인을 뷰 정의에 한 번에 처리할 수 있어 간결하고 성능도 뛰어납니다.

define view ZCDS_FLIGHT_INFO as
  select from sflight
    inner join scarr on sflight.carrid = scarr.carrid
{
  sflight.carrid,
  scarr.carrname,
  sflight.connid,
  sflight.price
}

📌 예시 2: 계산 필드

❌ ABAP Open SQL

ABAP에서는 계산 로직이 SQL에서 어렵고 보통 ABAP 코드에서 처리함:

DATA(avg_price) = price / seatsocc.`

✅ CDS 뷰

계산된 필드를 뷰 정의 안에서 바로 처리할 수 있습니다:

round( price / seatsocc, 2 ) as avg_price_per_seat

📌 예시 3: 시멘틱 & 권한 제어 내장

ABAP SQL은 단순한 데이터 읽기만 가능하며, 권한 제어나 필드 설명은 추가 코드로 구현해야 합니다.

CDS는 @Annotations를 통해 뷰에 권한(Authorization), 설명, UI 속성 등을 바로 부여할 수 있습니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '항공편 요약 뷰'

✅ 요약