sap-sac

# sap-sac — SAP Analytics Cloud ## 1. Environment Intake Checklist 1. **SAC tenant region** — eu10 / us10 / kr-canary 등? 2. **Edition** — SAC for BI / Planning / Smart Predict / Augmented Analytics? 3. **Connection type** — Live (HANA, BW, S/4) vs. Import (Datasphere, Files)? 4. **Underlying data source** — S/4HANA Cloud / On-Premise / BW / Datasphere / non-SAP? 5. **Use case** — BI Story, Analytic App, Planning, Predictive scenario? 6. **User role** — Story creator, Modeler, Planning user, Admin? 7. **SAP release** — ECC 6.0 EhP 또는 S/4HANA release year? 8. **Deployment** — On-Premise / RISE Private Cloud / Public Cloud? 9. **Industry** — 제조·유통·금융·공공 등 데이터 통제와 마감 패턴은 무엇인가? 10. **Failure scope** — 전체/특정 사용자, 최초 시각, 재현 빈도, 정확한 에러 문구? 11. **Authentication path** — SAML SSO / OAuth / basic / identity propagation 중 무엇인가? 12. **Change history** — 인증서·metadata·proxy·role·model 변경 직후인가? 환경이 부족해도 답을 멈추지 않는다. 위 질문을 최대 4개로 묶어 요청하고, 동시에 운영 변경 없는 provisional diagnosis와 read-only check를 제시한다. ## 2. Core Concepts ### 2.1 Connection Models - **Live Connection** — real-time query, no data copy. HANA, BW, S/4 CDS views. - **Import Connection** — periodic data load. Files, Datasphere, non-SAP DBs. ### 2.2 Models - **Analytic Model** — flexible, dimension/measure-based, for BI Story - **Planning Model** — supports input, version, allocation, value driver - **Predictive Model** — Smart Predict / Augmented (regression, classification, time series) ### 2.3 Stories vs. Analytic Applications - **Story** — drag-drop dashboards, smart insight, easy for business users - **Analytic Application** — scriptable (JS), customizable UI, for app developers ## 3. Typical Issues ### Data Issues - "Story is empty" — check connection, model permissions, member filter - "Numbers don't match S/4" — live vs. import mismatch, currency/unit conversion - "Hierarchy missing" — refresh hierarchy in connection, check role mapping - "Live connection failed" — SAC connection → network/auth → S/4 `SICF` → `SAML2` 순서 ### Performance - Story slow → live query optimization (CDS views, indexes), reduce visible measures, use story-level filters - Live BW: check BW query performance, OLAP cache ### Planning - "Cannot save value" — check write access, locked dimensions, version status (Public/Private) - Allocation fail → check source/target model, rule structure - Forecast not generating → check data history, model dimensions ### Predictive - Smart Predict accuracy low → review data quality, target balance, feature relevance - Time-series forecasting → ensure consistent intervals ## 4. Connections to S/4 / Datasphere | Source | Connection | Notes | |---|---|---| | **ECC 6.0** | BW Query 또는 지원되는 Import/OData | S/4 Released CDS 경로를 가정하지 않음 | | **S/4HANA Public Cloud** | 지원되는 cloud connection/API | Released CDS/API만 사용, 고객 `SICF` 조정 불가 | | **S/4HANA On-Prem / RISE** | Live via 지원되는 network path | Cloud Connector/reverse proxy 선택은 실제 아키텍처 기준 | | **BW/4HANA** | Live via InA | BW Query 권한과 성능을 분리 확인 | | **Datasphere** | Live (Spaces) or Import | preferred for cloud BI | | **HANA Cloud** | Live | direct | | **Non-SAP DB** | Import via OData/JDBC | Datasphere as bridge recommended | ## 5. Korean Context - **한국 데이터 위치**: SAC tenant region이 ap-southeast-1 (싱가포르) 또는 kr-canary - **공공기관 컴플라이언스**: K-ISMS, 망분리 환경에서 SAC 사용은 Private Cloud 검토 - **한국어 UI**: SAC Story Title/Label 한국어 OK; 데이터 dimension name은 영문 권장 - **다국가 자회사 통합 보고**: 한국 본사 SAC tenant에 자회사 데이터 통합 (consolidation) ## 6. Cross-module Routing - BTP 환경/Cloud Connector 이슈 → `sap-btp` - S/4 CDS view → `sap-abap-developer` - Datasphere 연동 → `sap-integration-cloud` (Datasphere 포함 시) - Planning workflow → 비즈니스 컨설턴트 (CO/FI) ## 7. SAP Notes & References - SAP Note 2511489 — SAC performance troubleshooting (registered in `data/sap-notes.yaml`) - SAP Note 3056467 — Slow performance when opening/running stories (registered) - SAP Note 2651014 — Common errors with charts and tables (registered) - SAC Help: https://help.sap.com/docs/SAP_ANALYTICS_CLOUD - SAC Best Practices Guide (Story design, Planning, Predictive) ## 8. Out of Scope - BW dataflow design (use sap-abap) - Datasphere modeling (use sap-integration-cloud) - Non-SAC BI tools (Tableau, Power BI 등) ## 9. Diagnostic Response Contract SAC 장애·숫자 불일치·성능 이슈는 다음 순서로 답한다. 1. **Issue** — 증상, 영향 사용자, 시작 시각, source, connection mode를 재정의한다. 2. **Primary Root Cause** — 현재 evidence가 가장 강하게 지지하는 원인 하나를 먼저 쓴다. 3. **Falsification** — 원인이 틀렸다면 보여야 할 관찰값을 두 개 이상 쓴다. 4. **Check** — SAC UI 경로와 backend T-code + 메뉴 경로 + monitor/table field를 쓴다. 5. **Fix** — 최소 변경, QA Test Connection, 샘플 Story 검증 순으로 쓴다. 6. **Rollback** — 원복 artifact, trigger, owner, 정상 판정 기준을 쓴다. 7. **Prevention** — 인증서 만료, content transport, 성능 budget, refresh SLA를 쓴다. 단순 용어 질문은 Quick Advisory로 끝낼 수 있다. 실패 원인이 둘 이상이거나 cross-system 변경이 필요하면 Evidence Loop를 사용한다. Evidence Loop에서는 운영자가 COLLECT를 수행하며 에이전트가 프로덕션 변경을 대행하지 않는다. ### 9.1 Minimum Evidence Bundle - SAC tenant 리전과 tenant ID의 마스킹된 식별자 - SAC update wave 또는 문제 발생 전후 release 정보 - Story / model / connection 종류와 마스킹된 object 이름 - ECC EhP 또는 S/4HANA release year, deployment model, industry - 전체 사용자/특정 사용자 여부와 성공하는 비교 사용자 존재 여부 - 최초·최근 실패 시각(타임존 포함), HTTP status, correlation ID - SAML assertion 본문이 아닌 issuer·audience·NameID type의 마스킹된 요약 - 변경 이력: 인증서, metadata, proxy, role, content transport, source query Token, cookie, password, assertion 원문, 개인정보, 실제 재무 상세값은 수집하지 않는다. 화면 캡처에는 tenant host·사용자 ID·고객명·사업장명을 마스킹한다. ## 10. Environment and Release Decision Matrix | Environment | First supported path to identify | Do not assume | |---|---|---| | ECC 6.0 | BW Query, supported OData/Import, existing HANA/BW architecture | S/4 Released CDS or direct S/4 InA semantics | | S/4HANA On-Premise | actual live endpoint, reverse proxy/Cloud Connector, backend ICF | every landscape uses the same proxy pattern | | RISE Private Cloud | customer-managed vs SAP-managed boundary, approved connectivity | customer can change every backend component | | S/4HANA Public Cloud | released analytical content/API and cloud administration | customer access to `SICF`, `SAML2`, `STRUST` | | BW/4HANA | InA endpoint, BW Query, authorizations, query runtime | Story rendering is always the bottleneck | | Datasphere | Space exposure, live/import mode, replication freshness | federation and replication have the same latency | Public Cloud action에는 `T-code: 없음(Cloud UI)`을 명시하고 해당 Fiori/SAC 메뉴 경로를 쓴다. On-Premise/RISE action에는 아래 T-code directory의 메뉴 경로를 함께 쓴다. 어느 release인지 모르면 S/4 전용 CDS 이름이나 customer-maintainable backend setting을 단정하지 않는다. ## 11. Live Connection Failure Playbook 진단 순서는 반드시 **SAC → network/auth → S/4 `SICF` → `SAML2`** 이다. 각 단계가 통과한 evidence를 남긴 뒤 다음 단계로 간다. ### 11.1 Phase A — SAC Object and Scope 1. `T-code: 없음(SAC UI)` + `SAC Home > Connections > 해당 connection > Test Connection`에서 connection 자체가 실패하는지, Story만 실패하는지 분리한다. 2. `T-code: 없음(SAC UI)` + `SAC Home > Files > 해당 Story > View`에서 같은 model을 쓰는 최소 Story와 원본 Story를 비교한다. 3. `T-code: 없음(SAC UI)` + `SAC Home > Security > Users/Roles`에서 실패 사용자와 성공 사용자의 SAC role·team·sharing 차이만 read-only로 비교한다. 4. connection owner만 성공하면 shared credential/SSO/user mapping 가설을 올린다. 5. 모두 실패하면서 endpoint DNS/TLS에 도달하지 못하면 Story 계산 가설을 내린다. **Falsification A** - 같은 connection의 최소 Story가 정상 조회되면 connection 전체 장애 가설은 기각한다. - 같은 사용자·같은 시간에 Test Connection은 성공하고 특정 Story만 실패하면 network 가설을 낮춘다. - 성공 사용자와 실패 사용자의 role·team이 동일하면 SAC sharing만의 문제라는 가설을 낮춘다. ### 11.2 Phase B — Network and Authentication Edge 1. 브라우저 개발자 도구에서 실패 request의 host·path·HTTP status·timing만 수집한다. Header, cookie, token, payload는 내보내지 않는다. 2. reverse proxy 또는 Cloud Connector를 쓰는지 실제 topology로 확인한다. 두 방식을 동시에 당연한 구성으로 적지 않는다. 3. `SMICM` + `SAP Easy Access > Tools > Administration > Monitor > System Monitoring > Internet Communication Manager`에서 실패 시각의 HTTP/TLS 연결 흔적을 read-only로 본다. 4. `STRUST` + `SAP Easy Access > Tools > Administration > Administration > Trust Manager`에서 endpoint가 사용하는 PSE의 인증서 유효기간·issuer chain·hostname 관계를 확인한다. 5. proxy가 TLS를 terminate하면 browser→proxy와 proxy→backend 인증서 체인을 분리한다. 6. HTTP 401/403이면 endpoint 도달은 성공했으므로 DNS/firewall 가설의 우선순위를 낮춘다. 7. timeout/502/503이면 auth mapping을 바꾸기 전에 proxy route·backend reachability를 증명한다. **Falsification B** - backend `SMICM`에 같은 시각 request가 보이면 firewall이 backend 도달을 막았다는 가설은 기각한다. - TLS handshake와 인증서 체인이 정상이고 401/403이 반환되면 인증서 만료 단독 가설은 기각한다. - SAC가 아닌 승인된 기술 테스트도 같은 endpoint에서 실패하면 Story/model 가설을 낮춘다. ### 11.3 Phase C — S/4 ICF Service (`SICF`) 이 단계는 S/4HANA On-Premise 또는 customer-managed RISE 범위에서만 수행한다. Public Cloud에는 `T-code: 없음(고객 접근 불가)`로 표시하고 SAP cloud 운영 경로로 에스컬레이션한다. 1. 실패 request에서 실제 service path를 먼저 확인한다. 2. `SICF` + `SAP Easy Access > Tools > Administration > Administration > Network > HTTP Service Hierarchy`에서 그 path에 대응하는 InA 또는 OData node의 활성 상태를 조회한다. 3. InA 계열은 실제 configured endpoint의 `/sap/bw/ina` 하위 path를 기준으로 확인한다. 4. OData 계열은 실제 configured endpoint의 `/sap/opu/odata` 하위 path를 기준으로 확인한다. 5. 상위 node가 보인다는 이유로 subtree 전체를 활성화하지 않는다. 6. node 활성 상태와 handler/authorization 오류를 분리하고 실패 시각을 기록한다. 7. 활성 변경이 필요하면 개발/QA에서 정확한 node 하나만 변경하고 TR·변경 승인에 연결한다. 8. 변경 후 `SAC Home > Connections > 해당 connection > Test Connection` (`T-code: 없음(SAC UI)`)과 최소 read-only Story를 재실행한다. **Falsification C** - 정확한 node가 활성이고 같은 path가 유효한 HTTP 응답을 내면 inactive ICF 가설은 기각한다. - ICF 활성화 전후 HTTP status가 동일하면 서비스 비활성 단독 가설을 기각하고 auth로 이동한다. - 다른 사용자에게 동일 endpoint가 정상이라면 전역 ICF 비활성 가설은 기각한다. ### 11.4 Phase D — SAML Trust and Metadata (`SAML2`) ICF endpoint가 응답하는 것을 증명한 뒤에 수행한다. 1. `SAML2` + `SAP Easy Access > Tools > Administration > Administration > Security > SAML 2.0 Configuration`에서 Local Provider 활성 상태를 확인한다. 2. SAC/IdP의 Trusted Provider가 enabled인지 확인한다. 3. 양쪽 metadata의 entity ID, ACS URL, issuer, audience가 현재 endpoint와 맞는지 비교한다. 4. signing certificate 유효기간과 교체 이력, metadata 재import 시각을 확인한다. 5. NameID/user mapping이 실패 사용자에게 어떤 backend ID를 만드는지 마스킹해 비교한다. 6. 시스템 clock 차이로 assertion validity window를 벗어나는지 확인한다. 7. `SU53` + `System > Utilities > Display Authorization Check`를 실패 직후 실행해 마지막 실패 authorization object를 수집한다. 성공 후 나중에 실행한 결과는 evidence로 쓰지 않는다. 8. role 변경이 필요하면 `PFCG` + `SAP Easy Access > Tools > Administration > User Maintenance > Role Administration > Roles`에서 승인된 role owner와 함께 최소 권한만 검토한다. **Falsification D** - 동일 SAML identity로 backend launch가 성공하고 SAC만 실패하면 backend trust 단독 가설을 낮춘다. - Local/Trusted Provider, metadata, certificate, clock이 모두 일치하면 trust mismatch 가설을 기각한다. - `SU53`에 실패 authorization이 재현되고 role 차이가 있으면 network 가설보다 권한 가설을 올린다. ### 11.5 Live Fix and Rollback Pairs | Confirmed cause | Minimal Fix after QA | Mandatory Rollback | |---|---|---| | wrong SAC connection setting | approved connection copy에서 endpoint/auth 수정 후 Test Connection | 기존 connection export/설정으로 복원하고 테스트 | | expired TLS chain | 승인된 새 chain을 QA PSE에 반영 후 handshake 검증 | 기존 PSE backup·certificate chain으로 원복 | | exact ICF node inactive | 필요한 node 하나만 QA에서 활성화하고 TR 승격 | 같은 node를 이전 상태로 되돌리고 request 재검증 | | stale SAML metadata | 현 endpoint metadata를 QA에서 재import하고 mapping 검증 | 이전 metadata/certificate backup 재적용 | | missing authorization | role owner 승인 후 최소 object만 role transport | 이전 role version/transport로 복원하고 user 비교 | Fix 전후에 같은 사용자, 같은 최소 Story, 같은 filter, 같은 시간대 기준을 사용한다. Rollback trigger는 오류율 상승, 다른 SSO consumer 영향, 응답 status 악화처럼 측정 가능해야 한다. ## 12. Import vs Live — Do Not Mix the Diagnosis | Dimension | Live Connection | Import Connection | |---|---|---| | Data location | source에 남아 query됨 | SAC model에 snapshot 적재 | | Freshness | source query 시점 | 마지막 successful job 시점 | | Main failure surface | endpoint, SSO, source authorization, query | job, mapping, delta, transformation, model load | | Security | source row/data authorization + SAC sharing | SAC model security + import credential | | Performance | source runtime + network + rendering | model size + calculation + rendering | | Safe first test | Test Connection + minimal Story | preview + small scoped import job | | Wrong first fix | cache/full reload | `SICF`/SAML activation | ### 12.1 Import Job / Schedule Failure Intake Import가 "안 돌았다"는 말만으로 scheduler를 원인으로 단정하지 않는다. 아래 환경과 시간축을 먼저 맞춘다. 1. SAC tenant 리전, update wave, license/edition을 확인한다. 2. source가 ECC EhP, S/4HANA release year, BW/4HANA, Datasphere, cloud/non-SAP 중 무엇인지 확인한다. 3. deployment가 On-Premise, RISE Private Cloud, Public Cloud인지와 업종의 운영 window를 확인한다. 4. model·connection 종류, Import job 이름의 마스킹된 식별자, full/delta 방식을 확인한다. 5. 실패가 manual import, scheduled import 또는 둘 다인지 분리한다. 6. schedule owner, enabled/paused 상태, timezone, recurrence, 시작 window를 확인한다. 7. last successful run과 first failed run의 start/end time, duration, row count를 비교한다. 8. 평소와 실패 run의 extracted, loaded, rejected row 수와 watermark를 비교한다. 9. credential rotation, owner 퇴사/잠금, agent update, proxy/TLS, source query/schema 변경 이력을 받는다. 10. on-premise data acquisition agent가 필요한 connection인지 실제 architecture에서 확인한다. 모든 SAC Import가 agent 또는 DPA를 쓴다고 가정하지 않는다. 11. maintenance window, concurrent job, source batch와 겹치는지 확인한다. 12. 정확한 status, error category, correlation ID를 받되 token, password, payload 원문은 받지 않는다. 환경 정보가 부족하면 release/deployment/source, manual-vs-schedule, last success/first failure, credential/agent/query change 네 묶음으로 질문하고 read-only check를 동시에 제시한다. ### 12.2 Read-only Evidence Collection 1. `T-code: 없음(SAC UI)` + `SAC Home > Files > 해당 model > Data Management > Import Jobs`에서 다음을 기록한다. - scheduled/manual trigger - owner와 schedule enabled/paused 상태 - tenant timezone과 표시된 execution time - queued/start/end 시각과 duration - extracted/loaded/rejected row 수 - error stage, correlation ID, 마지막 성공 run 2. `T-code: 없음(SAC UI)` + `SAC Home > Connections > 해당 connection`에서 connection type, credential 상태, Test Connection 결과, agent binding을 read-only로 확인한다. 3. 동일 source·mapping에 작은 기간 또는 제한된 row를 사용한 manual Test Run을 준비한다. 프로덕션 full reload가 아니라 QA/model copy에서 실행한다. 4. 같은 connection의 다른 Import job이 같은 시간대 성공했는지 비교한다. 5. 같은 schedule owner의 다른 job과 성공 owner의 비교 job을 확인한다. 6. agent 기반 connection이면 인프라 담당자에게 service/heartbeat, last seen, proxy/TLS, agent log의 시각·error category만 요청한다. log의 credential과 payload는 마스킹한다. 7. agent 미사용 cloud connection이면 agent 장애 가설을 즉시 제외한다. 8. ODP delta architecture가 확인된 경우에만 `ODQMON` + `SAP Easy Access > Tools > Administration > Monitor > Operational Delta Queue`에서 subscription, request, last successful delta, backlog를 read-only로 확인한다. 9. BW Query가 source이면 `RSRT` + `SAP Easy Access > Business Warehouse > Business Explorer > Query > Query Monitor`에서 같은 변수·권한으로 query 실행 가능 여부와 result volume을 확인한다. 10. backend HTTP 도달 여부가 쟁점인 경우에만 `SMICM` + `SAP Easy Access > Tools > Administration > Monitor > System Monitoring > Internet Communication Manager`에서 실패 시각의 request 도달 흔적을 본다. 11. backend component가 Application Log를 남기는 경우에만 `SLG1` + `SAP Easy Access > Tools > Administration > Monitor > System Monitoring > Application Log > Display`에서 object/subobject/time window를 좁혀 조회한다. `ODQMON` queue reset, delta reinitialization, full reload, credential overwrite, agent reinstall은 evidence collection이 아니라 변경이므로 이 단계에서 수행하지 않는다. read-only evidence가 끝난 뒤에만 QA/model copy에서 다음 controlled test를 수행한다. 1. 같은 source·mapping의 작은 기간 manual Test Run 2. 같은 owner·timezone의 one-time schedule 3. 같은 작은 범위의 full-vs-delta 비교(실제 delta architecture일 때만) 4. 각 test 사이에 target row/watermark/duplicate를 대사하고 다음 test로 이동 ### 12.2.1 Job Stage Decision Gate | Read-only job observation | Primary layer | First comparison | |---|---|---| | expected time에 run record 없음 | schedule paused/disabled, owner, timezone, recurrence | 정의가 같은 QA one-time schedule | | run record가 queued에 머묾 | concurrency, maintenance, capacity/window | 격리 window의 queued duration | | start 후 extracted rows = 0 | credential, connection, agent, source availability | Test Connection + source/manual history | | extracted > 0, loaded = 0 | mapping, transform, target model | preview + model copy sample load | | loaded > 0, rejected > 0 | data type/key/date/member 품질 | rejected field + schema change history | | small scope 성공, full scope timeout | volume, partition, resource window | 같은 volume의 격리 window run | Stage evidence가 없으면 "agent down" 또는 "volume limit"을 Primary로 단정하지 않는다. run record가 없는 문제에 mapping을 고치거나, extraction 완료 뒤 오류에 credential을 먼저 바꾸지 않는다. ### 12.2.2 Release and Deployment Boundary for Import - SAC schedule control은 source가 ECC인지 S/4인지와 별개로 tenant에서 확인한다. - ECC/BW Query source는 실제 BW Query일 때만 `RSRT`로 source 실행을 확인한다. - ECC라고 해서 S/4 Released CDS 또는 S/4 Public Cloud 메뉴를 적용하지 않는다. - ODP delta 사용이 architecture evidence로 확인될 때만 `ODQMON`을 사용한다. - S/4HANA On-Premise/RISE도 agent, direct cloud connection, BW 경유 중 실제 경로를 식별한다. - S/4HANA Public Cloud는 `T-code: 없음(Cloud UI)`으로 표시하며 고객 backend T-code를 안내하지 않는다. - non-SAP/cloud source는 SAC job·connection·provider monitor를 사용하고 ABAP T-code를 억지로 붙이지 않는다. ### 12.3 General Cause Classification | Layer | Typical causes | Distinguishing evidence | |---|---|---| | Schedule control | paused/disabled, wrong timezone, expired owner, overlap/concurrency | manual 성공, schedule만 실패; queued/start time 불일치 | | Connection/auth | credential expiry/rotation, role loss, account lock | Test Connection 실패; rotation 시각과 first failure 일치 | | Agent/network | acquisition agent down, heartbeat loss, proxy/TLS route change | agent-based connection만 실패; last seen 단절 | | Source/query | source unavailable, query/schema/variable change, permission change | source test/`RSRT` 실패; extraction 전에 종료 | | Delta state | subscription/backlog/watermark inconsistency | `ODQMON` evidence; full test와 delta 결과가 갈림 | | Mapping/data | dimension key/type/date change, rejected rows, transform error | preview와 rejected sample이 같은 field를 지목 | | Volume/resource | timeout, row/size growth, concurrency or tenant/source resource pressure | 작은 범위 성공, 큰 범위만 duration 증가 후 실패 | | Target/model | target model lock/change, member limit or incompatible model change | extraction 성공 뒤 load stage에서만 실패 | 가능성이 높은 한 원인을 Primary Root Cause로 두고 나머지는 Alternatives로 낮춘다. 각 가설에는 아래처럼 서로 독립적인 반증 조건을 두 개 이상 붙인다. ### 12.4 Hypotheses with Falsification **H1 — Schedule metadata, owner, timezone, or concurrency** - 지지: 같은 scope의 manual import는 성공하고 scheduled trigger만 실패한다. - 지지: schedule이 paused/disabled이거나 표시 timezone·실행 window가 기대와 다르다. - 반증 1: 같은 owner·timezone·definition의 QA one-time schedule이 두 번 연속 성공한다. - 반증 2: manual import도 같은 stage·같은 error로 실패한다. - 반증 3: 실패 window에 겹친 job이 없고 schedule은 실제로 정시에 start됐다. **H2 — Credential, connection, or agent path** - 지지: Test Connection이 실패하고 credential rotation/owner lock이 first failure와 일치한다. - 지지: agent-based connection의 heartbeat/last seen이 실패 전 끊겼다. - 반증 1: Test Connection과 agent heartbeat가 정상이고 같은 connection의 다른 import가 성공한다. - 반증 2: 해당 connection은 agent를 사용하지 않는 cloud path이다. - 반증 3: extraction은 끝났고 target load/mapping stage에서만 실패한다. **H3 — Source query, schema, authorization, or availability** - 지지: source query/schema/variable 변경 직후 모든 trigger가 extraction stage에서 실패한다.