SAP BW/4HANA 자격증 대비 핵심 예제 200선

> 데이터 엔지니어 배경을 가진 학습자를 위한 개념-예제-설명 정리입니다.
> 각 항목은 "개념 → 실무 예시 → 왜 중요한가"의 흐름으로 구성했습니다.
---
1. BW/4HANA 아키텍처 및 기본 개념 (1~20)
BW/4HANA란 — HANA 전용으로 재설계된 차세대 데이터 웨어하우징 솔루션. 예: 기존 Any-DB 기반 BW 대신 인메모리 컬럼 저장을 전제로 설계됨.
Simplified Data Model — Classic InfoCube, DSO, MultiProvider 등 레거시 오브젝트를 제거하고 aDSO/CompositeProvider로 통합. 예: 하나의 aDSO가 과거 Standard+Write-optimized DSO 역할을 모두 수행.
Code-to-Data Pushdown — 연산 로직을 애플리케이션 계층이 아닌 HANA DB 계층에서 처리. 예: ABAP 루프 대신 AMDP(HANA 프로시저)로 변환 로직 작성.
Greenfield 전환 — 기존 시스템 없이 신규로 BW/4HANA를 구축. 예: 처음 SAP를 도입하는 기업이 채택.
Brownfield 전환 — 기존 Classic BW를 BW/4HANA로 인플레이스 전환. 예: 기존 InfoCube를 aDSO로 자동 변환하는 전환 툴 사용.
Shell 전환 — 데이터 없이 구조(메타데이터)만 이관 후 신규 적재. 예: 데이터 이력이 필요 없는 경우 채택.
HANA 최적화 모델링 — 물리 계층을 최소화하고 뷰 기반 조회를 극대화. 예: Open ODS View로 소스 테이블을 가상 매핑.
BW/4HANA Cockpit — 관리자용 통합 모니터링/운영 도구. 예: 프로세스 체인 실행 현황을 한 화면에서 확인.
Eclipse 기반 BW Modeling Tools(BW/4HANA용 개발 툴) — GUI 대신 Eclipse Modeling Tools로 오브젝트 개발. 예: aDSO 생성 시 GUI 대신 이클립스 플러그인 사용.
InfoArea — 오브젝트를 논리적으로 그룹화하는 폴더 구조. 예: 재무 관련 오브젝트를 'FI' InfoArea 하위로 정리.
HANA Calculation View 연동 — Native HANA 모델을 BW 오브젝트처럼 활용. 예: HANA CV를 CompositeProvider에 소스로 편입.
레이어드 스케일러블 아키텍처(LSA++) — Acquisition-Harmonization-Propagation-Reporting 계층 설계 원칙. 예: Corporate Memory(원본 보존) → Propagation aDSO(정제) → Reporting(집계) 순서로 계층화.
Corporate Memory Layer — 원천 데이터를 그대로 보존하는 aDSO 계층. 예: 삭제/재처리 대비용 원본 데이터 아카이브.
Data Mart 계층 vs Reporting 계층 — 부서별 재사용 데이터 vs 최종 사용자 조회용 데이터로 역할 분리.
HANA-native 테이블 스토리지 타입 — Column Store 기반으로 압축·집계 성능 극대화. 예: 대용량 재무 트랜잭션 테이블도 실시간 집계 가능.
BW/4HANA 라이선싱 모델 — 별도 애플리케이션 서버로 운영되며 S/4HANA와 사이드카(Sidecar) 구성 가능. 예: S/4HANA 운영 부하와 분리해 리포팅 전용 시스템 구성.
Embedded BW vs Standalone BW/4HANA — S/4HANA 내장형 vs 독립 시스템 배포 방식 차이.
SAP Datasphere와의 관계 — BW/4HANA는 온프레미스, Datasphere는 클라우드 데이터 패브릭 솔루션. 예: 하이브리드 환경에서 BW/4HANA 데이터를 Datasphere로 연동.
Authorization(권한) 개념 - Analysis Authorization — 오브젝트 단위가 아닌 InfoObject 값 기반 권한 부여. 예: 특정 사용자에게 '한국' 법인 데이터만 조회 허용.
Namespace 규칙 — 커스텀 오브젝트는 고객 네임스페이스(예: Z, Y)로 생성. 예: ZFI_SALES라는 이름으로 커스텀 InfoObject 생성.
2. InfoObject (마스터 데이터) (21~40)
Characteristic InfoObject — 마스터데이터를 갖는 차원 필드. 예: 0CUSTOMER(고객), 0MATERIAL(자재).
Key Figure InfoObject — 수치형 측정값 필드. 예: 0AMOUNT(금액), 0QUANTITY(수량).
Attribute(속성) — Characteristic에 부가되는 추가 정보. 예: 0CUSTOMER의 속성으로 지역, 업종 추가.
Navigational Attribute — 쿼리에서 드릴다운 가능한 속성. 예: 고객 리포트에서 '지역'으로 드릴다운.
Display Attribute — 조회만 가능하고 드릴다운 불가능한 속성. 예: 고객 이메일 주소.
Compounding(복합키) — 여러 InfoObject를 조합해 고유값 형성. 예: 0COSTCENTER는 회사코드와 결합해야 고유.
Time-dependent Master Data — 특정 기간에만 유효한 속성 관리. 예: 조직 개편 이력 반영.
Text(텍스트) 테이블 — 언어별 설명 텍스트 저장. 예: 자재코드에 대해 한국어/영어 설명 병행 저장.
Hierarchy(계층구조) — 마스터데이터의 상하위 구조. 예: 계정과목 코드의 대분류-중분류-소분류 계층.
External Hierarchy vs Internal Hierarchy — 소스 시스템에서 로드 vs BW 내부에서 직접 정의.
0FISCPER(회계기간) InfoObject — 회계연도/기간을 나타내는 표준 InfoObject. 예: FI 리포팅의 기간 필터로 사용.
0FISCVARNT(회계연도 변형) — 회사별 회계연도 시작월 차이를 반영. 예: 4월 시작 회계연도 기업 대응.
Reference InfoObject — 기존 InfoObject의 기술 속성을 상속받아 신규 오브젝트 생성. 예: 0AMOUNT를 참조해 ZAMOUNT 생성.
Currency/Unit 처리 — Key Figure에 통화/단위 InfoObject를 연결해 환산 가능하게 함. 예: 0AMOUNT와 0CURRENCY 쌍 연결.
SID(Surrogate ID) — 마스터데이터 값을 정수로 매핑해 조인 성능 향상. 예: 텍스트 '서울'을 SID 1001로 변환 저장.
Attribute Change Run — 마스터데이터 속성 변경 후 집계 데이터 정합성 갱신 작업. 예: 고객 지역 변경 후 계층/속성 재계산.
InfoObject Catalog — InfoObject를 특성/키 필드별로 그룹 관리하는 폴더. 예: 재무 관련 특성만 별도 카탈로그로 관리.
마스터데이터 vs 트랜잭션 데이터 구분 — 변경 빈도가 낮은 참조데이터 vs 발생 이벤트 데이터.
0CALDAY, 0CALMONTH 등 Time Characteristic — 표준 제공 시간 관련 InfoObject. 예: 일별/월별 집계 리포트 기준.
Master Data Read Mode — 쿼리 실행 시 마스터데이터 텍스트를 즉시 읽을지, 캐시를 사용할지 설정. 예: 대용량 리포트 성능 튜닝 시 조정.
3. Advanced DataStore Object (aDSO) (41~65)
aDSO 정의 — BW/4HANA의 핵심 데이터 저장 오브젝트로 과거 InfoCube/DSO 역할을 통합. 예: 재무 트랜잭션 원장을 aDSO로 저장.
aDSO 유형 - Standard(표준) — 일반적인 상세 데이터 저장용. 예: 판매 전표 상세 내역 저장.
aDSO 유형 - Write-optimized 대체 시나리오 — 활성화 없이 빠른 적재만 필요한 경우 Inbound Table만 사용. 예: 대량 원천 데이터 임시 적재.
aDSO 유형 - All Characteristics as Key — 모든 특성을 키로 설정해 InfoCube처럼 동작. 예: 다차원 분석용 집계 테이블.
Inbound Table — 원천에서 적재된 원본 데이터가 위치하는 테이블(활성화 전 상태). 예: 로드 직후 데이터는 여기 저장.
Active Table — 활성화(Activation) 후 최종 데이터가 저장되는 테이블. 예: 리포팅에서 실제로 조회되는 데이터.
Change Log Table — 활성화 시 변경분(Delta) 이력을 기록하는 테이블. 예: 후속 오브젝트로의 델타 전송 근거.
Activation(활성화) 프로세스 — Inbound → Active Table로 데이터를 이관하며 델타를 계산하는 절차. 예: 매일 새벽 배치로 활성화 실행.
Semantic Key — aDSO에서 레코드의 고유성을 정의하는 키 필드 조합. 예: 전표번호+항목번호를 Semantic Key로 지정.
Overwrite vs Addition(덮어쓰기 vs 누적) — Key Figure 처리 방식 선택. 예: 재고 수량은 Overwrite, 매출액은 Addition.
aDSO의 Extraction 기능(추출용) — aDSO 자체가 델타 소스로서 후속 오브젝트에 데이터 제공. 예: aDSO → CompositeProvider로 델타 전송.
aDSO의 Reporting 플래그 — 해당 aDSO를 쿼리 대상으로 노출할지 여부 설정. 예: 중간 스테이징 aDSO는 리포팅 비활성화.
Field-based Modeling — InfoObject 없이 필드 기반으로 aDSO 설계 가능(HANA 최적화). 예: 빠른 프로토타이핑 시 필드 기반 모델링 사용.
InfoObject-based vs Field-based 혼합 모델링 — 필요한 필드만 InfoObject로 승격 가능. 예: 리포팅에 필요한 필드만 나중에 InfoObject化.
Request 기반 삭제(Selective Deletion) — 특정 요청(Request) 단위로 데이터 롤백. 예: 잘못 적재된 배치만 선택 삭제.
Data Tiering Optimization(DTO) — 데이터 온도(자주/드물게 조회)에 따라 저장 위치 최적화. 예: 오래된 데이터를 Extension Node나 Near-line Storage로 이동.
Near-Line Storage(NLS) — 사용 빈도 낮은 이력 데이터를 별도 스토리지로 아카이빙. 예: 5년 이상 지난 회계 데이터 NLS 이관.
HANA Execution Blend — Reporting 시 Active/Change Log/Archive 데이터를 통합 조회. 예: NLS 이관 후에도 쿼리에서 자동 통합 조회.
aDSO Delta Queue — 후속 시스템/오브젝트로 전송할 델타 레코드 대기열. 예: RSA7과 유사한 개념으로 델타 관리.
Repair Full Request — 델타 오류 발생 시 전체 재적재로 정합성 복구. 예: 델타 큐 손상 시 Full Load로 재정렬.
Data Validity(유효성 검증) — 적재 전 데이터 검증 규칙 설정. 예: 음수 금액이 들어오면 오류 처리.
Reconstruction(재구성) 기능 — 과거 요청을 재적재해 하위 오브젝트 데이터 복구. 예: aDSO에서 CompositeProvider로 재전송.
Snapshot aDSO 시나리오 — 특정 시점 전체 스냅샷 저장 방식. 예: 월말 재고 스냅샷을 매월 저장.
aDSO와 InfoSource 연계 — 복잡한 매핑 시 InfoSource를 매개로 여러 소스 통합. 예: 두 개의 서로 다른 소스를 하나의 InfoSource로 표준화 후 aDSO 적재.
성능 최적화 - Partitioning — 대용량 aDSO를 기간/조직 기준으로 파티셔닝. 예: 회계연도 기준 파티션으로 쿼리 성능 향상.
4. CompositeProvider (66~85)
CompositeProvider 정의 — 여러 데이터 소스를 가상으로 결합해 조회하는 오브젝트(물리 저장 없음). 예: 판매 aDSO + 재고 aDSO를 하나의 뷰로 결합.
Union(합집합) 결합 — 서로 다른 소스의 데이터를 세로로 이어붙임. 예: 국내 매출 + 해외 매출 데이터 통합.
Join(조인) 결합 — 공통 키 기준으로 데이터를 가로로 결합. 예: 판매 데이터와 고객 마스터를 고객ID로 조인.
Inner Join vs Left Outer Join — 조인 매칭 방식 선택. 예: 마스터데이터 누락 시에도 트랜잭션을 살리려면 Left Outer Join 사용.
Temporal Join — 이력성 데이터(Time-dependent) 기준으로 특정 시점 데이터를 조인. 예: 조직 개편 이력을 반영한 시점별 조인.
CompositeProvider의 소스 유형 — aDSO, InfoObject, Open ODS View, HANA View, InfoCube(레거시 호환) 등 다양.
Field 매핑 및 계산 필드(Calculated Field) — 조인 후 새로운 파생 필드 생성. 예: 매출 - 원가로 이익 필드 계산.
Currency/Unit Conversion 필드 — CompositeProvider 레벨에서 통화 환산 필드 추가. 예: KRW 금액을 USD로 자동 환산 표시.
HANA View로 자동 생성 — CompositeProvider는 활성화 시 HANA Calculation View로 변환됨. 예: 내부적으로 SQL 최적화된 뷰 생성.
성능 고려사항 - Union vs Join 선택 기준 — Union은 이질적 소스 통합, Join은 속성 보강에 적합.
CompositeProvider의 Filter(필터) 설정 — 특정 조건으로 소스 데이터 제한. 예: 특정 사업부 데이터만 포함.
Multi-Source 리포팅 시나리오 — FI aDSO + CO aDSO를 CompositeProvider로 묶어 통합 재무 리포트 구성.
BW Query를 소스로 사용 — 기존 쿼리를 CompositeProvider의 소스로 재사용 가능.
Constant Selection — 특정 필드를 고정값으로 필터링해 비교 분석 가능. 예: 특정 연도 매출을 기준값으로 고정 비교.
CompositeProvider Documentation(문서화) — 설계 의도를 기록해 유지보수성 확보. 예: 조인 조건과 목적을 주석으로 기록.
삭제된 InfoCube/MultiProvider 대체 — Classic BW의 MultiProvider 기능을 CompositeProvider가 완전 대체.
Elimination of Internal Business Volume — 그룹 내부 거래 상계 처리 기능. 예: 계열사 간 내부거래 매출 제거.
성능 모니터링 - HANA Plan Visualizer 연계 — CompositeProvider 쿼리 실행 계획 분석. 예: 조인 병목 구간 파악.
CompositeProvider 재사용성 — 여러 쿼리에서 하나의 CompositeProvider 공유 가능. 예: 재무팀/경영진 리포트가 동일 뷰 공유.
버전 관리(Transport) — CompositeProvider도 개발-품질-운영 시스템 간 전송 대상. 예: STMS를 통한 이관.
5. Open ODS View (86~100)
Open ODS View 정의 — 물리적 적재 없이 소스 테이블을 가상으로 BW에 노출하는 오브젝트. 예: HANA 스키마의 원천 테이블을 즉시 조회.
Facts 유형 Open ODS View — 트랜잭션(사실) 데이터 노출용. 예: 판매 전표 원천 테이블 직접 매핑.
Master Data 유형 Open ODS View — 마스터데이터 소스 노출용. 예: 고객 마스터 원천 테이블 매핑.
Text 유형 Open ODS View — 텍스트/설명 데이터 노출용.
소스 연결 유형 - DB Connection — 외부 데이터베이스와 직접 연결. 예: 타 시스템 오라클 DB를 실시간 조회.
소스 연결 유형 - HANA Local Table — BW/4HANA와 동일 HANA 인스턴스 내 테이블 활용.
소스 연결 유형 - ODP(SAP 소스) — S/4HANA 등 SAP 시스템의 ODP 소스 연결.
Field to InfoObject 매핑(승격) — Open ODS View 필드를 InfoObject로 연결해 표준화. 예: 원천 필드 'KUNNR'을 0CUSTOMER로 매핑.
Semantic Type 지정 — 필드별 의미(날짜, 금액, 단위 등) 정의로 후속 활용성 향상.
빠른 프로토타이핑(PoC) 활용 — 물리 적재 없이 빠르게 데이터 탐색 가능. 예: 신규 소스 데이터 품질 검증 시 우선 Open ODS View로 확인.
CompositeProvider와의 결합 활용 — Open ODS View를 CompositeProvider 소스로 사용해 정식 리포팅에 편입.
실시간성(Near Real-Time) — 물리 적재 과정이 없어 원천 변경이 즉시 반영. 예: 실시간 재고 조회 시나리오.
성능 트레이드오프 — 적재 데이터가 없어 원천 시스템 부하에 직접 영향. 예: 원천 DB 부하가 크면 조회 성능 저하.
거버넌스 이슈 — 표준화 전 데이터를 그대로 노출하므로 데이터 품질 관리 필요. 예: 원천 오류 데이터도 그대로 노출됨.
BW Bridge(선택 시나리오)와의 차이 — Open ODS View는 BW/4HANA 자체 기능, BW Bridge는 별도 클라우드 연계 아키텍처.
6. 데이터 추출 (Extractors, ODP) (101~125)
ODP(Operational Data Provisioning) 개념 — 소스와 타겟 간 델타 전송을 표준화한 프레임워크. 예: S/4HANA에서 BW/4HANA로 델타 추출.
ODP Context 유형 - SAPI — 기존 SAP DataSource 기반 추출.
ODP Context 유형 - BW — BW 오브젝트(aDSO 등)를 소스로 하는 추출.
ODP Context 유형 - HANA — HANA 뷰/테이블을 소스로 하는 추출.
ODP Context 유형 - ABAP CDS Views — CDS 뷰를 소스로 하는 최신 추출 방식. 예: S/4HANA의 표준 CDS 뷰를 BW로 추출.
DataSource(데이터소스) — 소스 시스템의 추출 구조를 정의하는 오브젝트. 예: 0FI_GL_4(총계정원장) 표준 DataSource.
Extract Structure vs Transfer Structure — 소스 측 구조와 BW 전송 구조 구분.
Full Load(전체 적재) — 소스 전체 데이터를 매번 재적재. 예: 초기 적재 또는 소규모 마스터데이터.
Delta Load(델타 적재) — 변경분만 적재. 예: 매일 신규/변경 전표만 적재.
Delta 방식 - After-Images vs Before/After-Images — 변경분 표현 방식 차이(최종값만 vs 변경 전후 모두).
Init(초기화) 프로세스 — 델타 적재 시작 전 기준점을 설정하는 절차. 예: Init 없이 델타 적재 시 오류 발생.
RSA7 / Delta Queue 모니터링 — 소스 시스템의 델타 큐 상태 확인(레거시 개념이나 ODP에도 유사 구조 존재).
Generic DataSource(제네릭 데이터소스) — 테이블/뷰/함수 기반 커스텀 추출 구조 생성. 예: 커스텀 Z테이블을 소스로 DataSource 생성.
Extractor Enhancement(추출 구조 확장) — 표준 DataSource에 필드 추가. 예: 커스텀 필드를 표준 FI 추출 구조에 추가.
Application Component Hierarchy — DataSource를 업무 영역별로 분류하는 트리 구조.
File Source(파일 소스) — CSV/플랫파일 기반 데이터 적재. 예: 외부 시스템에서 받은 엑셀/CSV를 적재.
DB Connect — 외부 DB 테이블을 직접 소스로 연결. 예: 타 ERP 시스템의 테이블 직접 추출.
Web Service / OData 소스 — API 기반 데이터 수집. 예: 외부 클라우드 서비스에서 OData로 데이터 수신.
Real-Time Data Acquisition(실시간 수집)의 대체 — BW/4HANA에서는 ODP 기반 고빈도 델타로 대체.
Subscription(구독) 개념 - ODP — 여러 타겟이 하나의 소스 델타 큐를 공유 구독. 예: 두 개의 aDSO가 같은 ODP 소스를 각각 구독.
Change Data Capture(CDC)와의 관계 — ODP 델타 메커니즘이 CDC의 SAP식 구현.
추출 모니터링 - Data Load Monitor — 적재 성공/실패, 레코드 수 확인 도구. 예: 적재 오류 발생 시 원인 로그 확인.
오류 처리(Error Stack) — 적재 실패 레코드를 별도 저장해 재처리 가능하게 함.
Semantic Groups(세만틱 그룹) — 병렬 처리 시 동일 그룹 레코드를 같은 패키지로 묶어 처리 순서 보장. 예: 전표번호 단위로 그룹핑해 순서 오류 방지.
소스 시스템 연결(Source System) 설정 — SAP/비SAP 시스템과의 연결 정의. 예: S/4HANA를 소스 시스템으로 등록 후 DataSource 활용.
7. 변환(Transformation) 및 DTP (126~145)
Transformation(변환) 개념 — 소스 필드를 타겟 필드로 매핑/가공하는 규칙 정의. 예: 소스의 'BUKRS'를 타겟 InfoObject 0COMP_CODE로 매핑.
1:1 필드 매핑 — 소스-타겟 필드명이 다르더라도 값 그대로 전달.
상수(Constant) 할당 — 고정값을 타겟 필드에 부여. 예: 데이터 출처 구분값 'SAP'를 상수로 삽입.
Formula(수식) 규칙 — 여러 필드를 조합한 계산 로직. 예: 수량×단가로 금액 필드 생성.
Routine(루틴) - Start Routine — 변환 시작 전 패키지 단위 데이터 가공. 예: 특정 조건 레코드 사전 필터링.
Routine - End Routine — 변환 완료 후 최종 후처리. 예: 타겟 적재 직전 중복 제거.
Routine - Field-level Routine — 개별 필드 단위 커스텀 로직. 예: 문자열 트리밍, 코드 변환 등.
Rule Group(규칙 그룹) — 같은 소스-타겟 조합에서 여러 매핑 규칙 세트 관리. 예: 국내/해외 데이터별 다른 매핑 규칙 적용.
Read Master Data(마스터데이터 조회) 규칙 — 코드값을 마스터데이터의 속성값으로 치환. 예: 고객코드로 고객 지역 속성 조회 후 매핑.
AMDP(ABAP Managed Database Procedure) — HANA 프로시저 기반 고성능 변환 로직. 예: 대용량 집계 로직을 DB 레벨에서 처리.
DTP(Data Transfer Process) 개념 — 소스에서 타겟으로 실제 데이터를 이동시키는 실행 오브젝트.
DTP 유형 - Full — 전체 데이터 이동.
DTP 유형 - Delta — 변경분만 이동.
Error DTP — 오류난 레코드만 별도 재처리하는 DTP. 예: Error Stack에 쌓인 레코드를 수정 후 재적재.
Filter(필터) 조건 - DTP — 특정 조건 데이터만 선택적으로 이동. 예: 특정 연도 데이터만 이동.
Semantic Grouping - DTP — 병렬 처리 시 순서 보장을 위한 그룹핑 설정.
Package Size(패키지 크기) 조정 — 성능 튜닝을 위한 처리 단위 크기 설정. 예: 대용량 초기 적재 시 패키지 크기 확대.
Direct Access(가상 접근) — 물리 적재 없이 실시간 소스 조회. 예: 소규모 데이터의 즉시성 요구 시나리오.
Transformation Chain(연쇄 변환) — 여러 단계를 거쳐 원천→스테이징→최종 오브젝트로 데이터 이동. 예: Open ODS View → aDSO(Corp Memory) → aDSO(Propagation) → CompositeProvider.
Multiple Transformation 관리 전략 — 유지보수성을 위해 변환 로직을 여러 단계로 분리. 예: 복잡한 계산은 여러 단계 변환으로 나눠 디버깅 용이하게 구성.
8. BW 쿼리 및 리포팅 (146~170)
BEx Query Designer — 쿼리를 설계하는 개발 도구. 예: CompositeProvider 위에 쿼리 생성.
Query의 InfoProvider 기반 생성 — aDSO, CompositeProvider 등을 기반으로 쿼리 생성.
Row/Column(행/열) 정의 — 쿼리 결과의 축 구성. 예: 행에 고객, 열에 월별 매출 배치.
Free Characteristics(자유 특성) — 초기 화면엔 없지만 드릴다운 가능한 필드. 예: 필요시 지역별로 추가 드릴다운.
Filter(전역 필터) — 쿼리 전체에 적용되는 조건. 예: 특정 회계연도만 조회.
Variable(변수) - Characteristic Value Variable — 실행 시 사용자 입력값으로 필터링. 예: 조회 기간을 사용자가 직접 입력.
Variable - Customer Exit — ABAP 코드로 변수값을 동적으로 결정. 예: 항상 '전월'을 자동 기본값으로 설정.
Variable - Formula Variable — 수식에서 사용하는 변수. 예: 환율 변수를 수식에 적용.
Restricted Key Figure(제한된 키 필드) — 특정 조건이 적용된 키 필드. 예: '국내 매출'만 별도 컬럼으로 정의.
Calculated Key Figure(계산된 키 필드) — 여러 키 필드 간 연산으로 생성. 예: 이익률 = (매출-원가)/매출.
Exception Aggregation(예외 집계) — 특정 특성 기준으로 다른 집계 방식 적용. 예: 재고는 합산이 아닌 마지막 값(Last Value) 집계.
Cell Editor(셀 편집기) — 행×열 특정 교차점에 개별 수식 적용. 예: 특정 셀만 다른 계산식 적용.
Condition(조건) — 상위/하위 N개, 임계값 이상 등 결과 필터링. 예: 매출 상위 10개 고객만 표시.
Exception(예외 - 조건부 서식) — 임계값 초과 시 색상 강조. 예: 예산 초과 항목 빨간색 표시.
Hierarchy 표시 옵션 — 쿼리에서 계층 구조 펼침/접힘 표시. 예: 계정과목 계층을 접은 상태로 기본 표시.
Query Properties - Read Mode — 쿼리 실행 시 데이터를 한번에 읽을지 드릴다운마다 읽을지 설정.
Currency Translation(통화 환산) - 쿼리 레벨 — 쿼리 실행 시점에 환산 적용. 예: 실시간 환율로 리포트 통화 통일.
Structure(구조) 재사용 — 행/열 구조를 여러 쿼리에서 공유. 예: 표준 재무제표 구조를 여러 리포트에 재사용.
BEx Analyzer(엑셀 프론트엔드) — 엑셀 기반 쿼리 조회 도구.
SAP Analytics Cloud(SAC) 연동 — BW 쿼리를 SAC 스토리에 연결해 시각화. 예: 경영진 대시보드 구성.
BI Consumer Services(BICS) 연결 — SAC/타 프론트엔드가 쿼리에 접속하는 표준 인터페이스.
Query Performance - Aggregation — HANA 인메모리 집계로 별도 Aggregate 불필요(레거시 대비 차이점).
OLAP Cache — 쿼리 결과를 캐싱해 반복 조회 성능 향상.
Local Calculation(로컬 계산) — 프론트엔드에서 실행되는 후처리 계산(예: 누계, 순위).
Report-to-Report Interface(점프 기능) — 한 리포트에서 다른 리포트/트랜잭션으로 이동. 예: 요약 리포트에서 전표 상세로 점프.
9. 프로세스 체인 (Process Chains) (171~185)
Process Chain 정의 — 여러 적재/처리 작업을 순서대로 자동 실행하는 배치 오브젝트.
Start Process — 체인의 시작점(스케줄 트리거). 예: 매일 새벽 2시 자동 실행.
DTP 실행 프로세스 — 체인 내에서 DTP를 실행하는 단계.
Activation 프로세스 — aDSO 활성화를 체인에 포함. 예: 적재 후 자동 활성화.
And(수렴) / Or 연결 — 여러 선행 프로세스 완료 조건 설정. 예: 두 개 적재가 모두 끝나야 다음 단계 진행.
Event 기반 트리거 — 특정 이벤트 발생 시 체인 시작. 예: 소스 시스템 배치 완료 이벤트 수신 후 시작.
에러 처리 - Error Handling 분기 — 실패 시 대체 경로 실행. 예: 실패 시 관리자에게 이메일 발송 프로세스 연결.
Local vs Meta Chain — 개별 체인을 상위 메타 체인으로 통합 관리. 예: 여러 부서 체인을 하나의 야간 배치로 통합.
Process Chain 모니터링(RSPC 유사 화면) — 실행 로그/상태 확인. 예: 실패 단계 로그로 원인 추적.
Attribute/Hierarchy Change Run 프로세스 — 마스터데이터 변경 후 자동 정합성 갱신 단계 포함.
Semaphore(잠금) 처리 — 동시 실행 충돌 방지. 예: 동일 aDSO에 대한 중복 활성화 방지.
재시작(Restart) 전략 — 실패 지점부터 재실행 가능하도록 설계. 예: 중간 실패 시 처음부터 재실행하지 않고 해당 단계부터 재개.
알림(Notification) 설정 — 성공/실패 시 이메일 등 알림 발송.
DTP Filter 변수와 체인 연동 — 체인 실행 시점 기준으로 동적 필터 적용. 예: '어제' 데이터만 자동 필터링.
Housekeeping 프로세스 — 로그 삭제, 임시 데이터 정리 등 유지보수 작업 포함.
10. 마이그레이션 (Classic BW → BW/4HANA) (186~200)
BW4HANA Transfer Cockpit — Classic BW 오브젝트를 BW/4HANA 대응 오브젝트로 전환 지원하는 툴. 예: InfoCube 목록을 확인 후 일괄 전환 대상 지정.
InfoCube → aDSO 전환 — Classic InfoCube를 자동으로 aDSO(All Characteristics as Key)로 변환.
Standard DSO → aDSO(Standard) 전환 — 기존 DSO를 aDSO Standard 유형으로 전환.
MultiProvider → CompositeProvider 전환 — 기존 다중 소스 결합 오브젝트를 CompositeProvider로 전환.
전환 전 사전 점검(Pre-check) — 지원되지 않는 레거시 오브젝트(예: 특정 구버전 기능) 사전 식별. 예: 전환 불가 오브젝트 리스트업 후 재설계.
Transfer Rules 시뮬레이션 — 전환 후 예상 데이터/로직 변화를 사전 검증.
Custom ABAP 코드 영향 분석 — 전환 시 기존 커스텀 루틴이 새 구조에서 동작하는지 점검. 예: Start Routine 내 레거시 API 호출 여부 확인.
단계적 전환(Phased Migration) 전략 — 전체 일괄 전환 대신 영역별 순차 전환. 예: 재무 영역 먼저 전환 후 영업 영역 전환.
Downtime 최소화 전략 — 전환 작업 시 시스템 중단 시간 최소화 방안 수립. 예: 야간/주말 시간대 전환 작업 수행.
전환 후 검증(Post-migration Validation) — 전환 전후 데이터 건수/합계 비교 검증. 예: 전환 전 매출 합계와 전환 후 합계 대사.
레거시 오브젝트 정리(Cleanup) — 사용하지 않는 Classic 오브젝트 삭제. 예: 전환 완료 후 불필요한 InfoCube 삭제.
BW Bridge 시나리오(클라우드 병행) — 온프레미스 유지가 어려운 경우의 대안적 클라우드 확장 경로.
전환 프로젝트 롤백 계획 — 문제 발생 시 이전 상태로 되돌릴 수 있는 백업/롤백 절차 수립.
교육 및 변화관리 — 전환 후 사용자(리포트 작성자 등) 대상 신규 툴/화면 교육 필요성.
전환 후 성능 벤치마킹 — HANA 최적화 이후 쿼리/적재 성능을 전환 전과 비교 측정. 예: 전환 전후 배치 소요시간 비교 리포트 작성.
---
참고: 위 내용은 학습 및 개념 정리 목적의 예제이며, 실제 시험 문항이나 SAP 공식 자료를 그대로 재현한 것이 아닙니다. 응시 전 SAP 공식 Learning Journey 및 최신 Certification 페이지에서 시험 범위를 반드시 재확인하시기 바랍니다.