CERTRULE로 잡는 주체전파 실패 3가지 #shorts #SAP #BTP
📖 개요: 사용자가 온프레미스로 안 넘어갈 때 어디부터 봐야 하는가 SAP BTP 앱에서 온프레미스 S/4HANA를 호출할 때 Principal Propagation(주체 전파)을 켜면, 클라우드에서 로그인한 사용자의 신원이 백엔드까지 그대로 전달되어 백엔드 권한(PFCG)으로 데이터
📖 개요: 사용자가 온프레미스로 안 넘어갈 때 어디부터 봐야 하는가 SAP BTP 앱에서 온프레미스 S/4HANA를 호출할 때 Principal Propagation(주체 전파)을 켜면, 클라우드에서 로그인한 사용자의 신원이 백엔드까지 그대로 전달되어 백엔드 권한(PFCG)으로 데이터
왜 Destination 인증 방식 선택이 중요한가 SAP BTP에서 외부 시스템을 호출할 때 Destination Service는 "어디로, 어떤 자격으로" 연결할지를 정의합니다. 문제는 인증 타입을 무엇으로 고르느냐에 따라 백엔드 감사 로그에 남는 주체 가 완전히 달라진다는 점입니다
이 글에서 다루는 내용 CAP for Java 이벤트 핸들러를 작성하다 보면 "지금 들어온 요청이 어떤 엔티티를, 어떤 키로, 어떤 조건으로 조회하는가"를 알아야 하는 순간이 반드시 옵니다. 이때 cqn.toString() 결과를 문자열로 잘라 쓰는 코드는 당장은 동작해도 확장 시 반드
개요: 왜 모든 오류가 500으로 나가는가 CAP Java로 서비스를 개발하다 보면, 핸들러 안에서 발생한 예외가 아무 처리 없이 그대로 올라가 클라이언트에게 500 Internal Server Error 로 반환되는 상황을 자주 만납니다. 재고 부족처럼 명백한 "업무 오류"조차 500
이 글에서 얻어갈 것 — 30초 요약의 전체 지도 Fiori Elements는 어노테이션 기반으로 화면을 자동 생성하는 프레임워크지만, 실무에서는 반드시 "표준에 없는 버튼 하나, 컬럼 하나"를 추가해야 하는 순간이 옵니다. 이 글은 그때 필요한 확장 포인트를 종류별로 빠르게 정리한 실
📖 개요 — 이 글에서 다루는 것 SAP Fiori elements 기반 앱에서 사용자가 입력하다 만 데이터를 안전하게 임시 저장해 주는 Draft(초안) 패턴은, CAP Node.js에서는 어노테이션 한 줄( @odata.draft.enabled )로 켤 수 있습니다. 그런데 "한
📖 개요: 로그 없는 CAP 디버깅이 실패하는 이유 CAP(Node.js) 프로젝트에서 "핸들러가 왜 안 타지?", "이 요청이 DB에 어떤 SQL을 날렸지?"라는 질문에 console.log 를 여기저기 심어가며 답을 찾는 경우가 많습니다. 하지만 CAP 런타임은 이미 cds.log
📖 이 글이 답하는 질문 버튼을 눌렀는데 화면이 3초간 아무 반응이 없다면, 사용자는 앱이 멈췄다고 판단하고 버튼을 다시 누릅니다. 그 결과는 중복 요청, 이중 저장, 그리고 "앱이 느리다"는 평가입니다. SAPUI5(및 OpenUI5)에는 이 문제를 한 줄로 해결하는 setBusy
📖 온프레미스 S/4HANA와 BTP, 왜 함께 쓰는가 많은 기업이 S/4HANA를 온프레미스(자사 데이터센터 또는 프라이빗 클라우드)에 운영하면서도, 확장 기능·모바일 앱·파트너 연동은 SAP BTP(Business Technology Platform) 위에 구축합니다. 핵심 배경은
📖 개요: 자연어 한 문장으로 SAP 업무를 움직이기 SAP 업무 자동화라고 하면 지금까지는 트랜잭션 코드(T-Code)를 외우고, 배치 잡을 걸고, 필요하면 ABAP 커스텀 개발까지 하는 그림이 일반적이었습니다. 이 글은 SAP의 생성형 AI 코파일럿인 Joule 을 SAP BTP
이 글에서 다룰 것 Fiori Elements List Report는 코드를 거의 쓰지 않고도 목록·필터·내비게이션을 갖춘 앱을 만들어 주지만, "표준 템플릿이라 커스터마이징이 안 된다"는 오해가 여전히 많습니다. 실제로는 freestyle로 새로 짜지 않아도 Annotation, ma
📖 개요: CAP Java 트랜잭션 롤백, 왜 자꾸 어긋나는가 SAP CAP(Cloud Application Programming Model) for Java는 개발자가 트랜잭션 경계를 직접 열고 닫지 않아도 되도록 ChangeSet 컨텍스트 라는 추상화를 제공합니다. 편리하지만, 이
시작하며: Joule을 BTP에서 켜기까지 Joule은 SAP가 자사 클라우드 제품 전반에 탑재하고 있는 생성형 AI 어시스턴트입니다. S/4HANA Cloud, SuccessFactors 같은 애플리케이션 안에서 자연어로 질문하고 트랜잭션을 실행하는 경험을 제공하지만, 그 뒤에서 이
📖 개요: 이 글에서 다루는 것 SAP Fiori 앱을 새로 만들 때 가장 먼저 마주치는 갈림길이 바로 Fiori Elements 와 Freestyle UI5 의 선택입니다. 같은 SAPUI5 프레임워크 위에서 동작하지만, 개발 속도·커스터마이징 자유도·유지보수 비용이 크게 달라지기
📖 개요 및 이 글에서 다루는 것 CAP Java 애플리케이션이 자기 데이터베이스만 바라보는 경우는 드뭅니다. 실무에서는 S/4HANA의 OData API나 다른 팀이 만든 마이크로서비스를 호출해 데이터를 합쳐 보여줘야 하는 상황이 훨씬 많습니다. 이 글에서는 CAP Java의 Rem
개요: 왜 CAP 쿼리 성능을 다시 봐야 하는가 SAP CAP(Cloud Application Programming Model) Node.js 런타임은 CQL(CDS Query Language)을 통해 데이터베이스 접근을 추상화합니다. 편리한 만큼, 추상화 뒤에서 어떤 SQL이 실행되는
📖 개요: Before와 After, 이름만 보고 쓰면 반드시 사고가 난다 CAP Java에서 커스텀 핸들러를 처음 작성할 때 가장 많이 겪는 사고는 문법 오류가 아니라 "코드는 정상 실행됐는데 DB에는 아무 것도 반영되지 않는" 침묵의 버그 입니다. 특히 @After 핸들러에서 엔티
개요 — 핸들러 실행 순서를 알아야 하는 이유 CAP Java(SAP Cloud Application Programming Model, Java 런타임)에서 커스텀 비즈니스 로직은 @Before , @On , @After 세 페이즈(Phase)의 이벤트 핸들러로 작성합니다. 이 세 페이
개요: 저장 버튼 없이 화면이 스스로 갱신되는 원리 Fiori Elements 앱에서 수량 필드를 바꿨는데 총액이 그대로라면, 사용자는 "이 앱이 계산을 안 하나?"라고 느낍니다. 백엔드 Determination은 이미 값을 다시 계산했지만, 브라우저가 그 사실을 모르는 것이 문제입니다
개요: 핸들러 실행 순서를 알아야 하는 이유 CAP Java(SAP Cloud Application Programming Model, Java 런타임)에서 커스텀 로직은 @Before , @On , @After 세 가지 페이즈(Phase)의 이벤트 핸들러로 작성합니다. 문제는 이 세 페