sap-cloud

## 1. Environment Intake Checklist When any Cloud PE issue or extension task is reported, collect before answering: - **Cloud PE Version**: 2401 / 2402 / 2403 / 2405 / (specific release month/year) - **Tenant Type**: Production / Non-Production (Test / Staging) - **Extension Tier**: Tier 1 (Key User Extensibility) / Tier 2 (Side-by-Side BTP) / Tier 3 (On-Stack ABAP Cloud) - **Deployment Model**: Cloud PE (never mention on-premise SE38/SE80/SMOD/CMOD — they are forbidden) - **Industry Sector**: Manufacturing / Finance / Retail / Public Sector / Other - **Change Control**: Are you in Fit-to-Standard phase or Operations phase? --- ## 2. Clean Core Principles (Non-Negotiable) SAP S/4HANA Cloud PE enforces **Clean Core** — no modifications to SAP standard code or tables. | Activity | On-Premise (ECC/S/4HANA OP) | Cloud PE | |----------|------------------------------|----------| | ABAP Modifications (SE38) | ✓ Allowed | ✗ FORBIDDEN | | Function Module Enhancements (SMOD/CMOD) | ✓ Allowed | ✗ FORBIDDEN | | Workflow Customizing (SWDD) | ✓ Allowed | △ Limited (no code exits) | | IMG Configuration | ✓ Full (SPRO) | △ Limited (Manage Your Solution) | | BAdI Implementation | ✓ Standard (SE19) | ✗ FORBIDDEN (use RAP instead) | | Enhancement Spots | ✓ Full (BADI_DEF) | ✗ FORBIDDEN | | Standard Table Modifications | ✓ Allowed (append structures) | ✗ FORBIDDEN | | Transport Mechanism | ✓ TMS (TP/TP4) | ✗ Direct upload to Cloud ALM | **Forbidden T-codes in Cloud PE:** - SE11 (ABAP Dictionary modifications) - SE38 (Classic ABAP program creation) - SE80 (Object Navigator for custom code) - SMOD / CMOD (Exit/Enhancement modification) - SWDD (Classic Workflow definition) - SPAM / SAINT (Transport/patch — managed by SAP) --- ## 3. Key User Extensibility — Tier 1 (Self-Service) ### 3.1 Custom Fields (Extensibility Add-Ons) Enable end users (non-developers) to add business fields without coding. **How to Create Custom Fields:** 1. **In Cloud PE UI** → **Manage Your Solution** → **Custom Fields** 2. Select object (Purchase Order, Sales Order, Material Master, etc.) 3. Click **Create Custom Field** - Field Name: `ZZ_CUSTOM_FIELD` (naming convention) - Data Type: Quantity / Amount / Date / Text / Dropdown - Label: Business-facing label (Korean: "사용자정의 필드") 4. **Deploy**: Activation is immediate (no transport) 5. **UI Integration**: Auto-added to relevant screens (Fiori UIs) **Limitations:** - No transactional logic (no derived fields) - No cross-object validation - Max 200 custom fields per object - Field length: Text max 255 characters **Example:** Add "승인 요청 코드" (approval code) to PO header: - T-code: MANAGE_CUSTOM_FIELDS (Fiori) - Object: Purchasing Document (PO) - Field: ZZ_APPR_CODE (Text, length 20) - Result: Auto-visible in PO Fiori app (no coding needed) --- ### 3.2 Custom Logic (ABAP Cloud with RAP) For business logic beyond custom fields — use **Restricted ABAP Programming (RAP)** on released SAP APIs. **What is RAP (Restful ABAP Programming)?** - Cloud-native ABAP development model (CDS-based) - No classic ABAP (SELECT, MODIFY, DELETE) — replaced by CDS + Event Handler - Event-driven (Create, Update, Delete hooks) - Published as OData V4 APIs automatically **Tier 1 Custom Logic Entry Points (Key User-friendly):** 1. **Calculations/Derivations** — Automatic field computation - Example: "Invoice Amount = Net Amount + Tax" (tax auto-calc on item save) - Implementation: CDS Calculation / Transient Field 2. **Validations** — Block invalid data - Example: "PO quantity must not exceed contract qty" - Implementation: CDS Validation (CDS element WITH ... , associations) 3. **Default Values** — Pre-fill fields on creation - Example: "Set cost center from user default" - Implementation: CDS Default Handler **ABAP Cloud Restrictions:** - ✗ SELECT FROM database table (use CDS instead) - ✗ MODIFY table directly - ✗ CALL FUNCTION (classic RFC) - ✓ CALL API (SAP standard APIs released) - ✓ SQL queries via CDS Views - ✓ OData consumption via HTTP **Example:** Validate PO quantity vs. contract ``` CDS View: ZC_PO_CUSTOM element ZZ_CONTRACT_QTY : Contract Qty; Validation Rule: if (PO_QTY > ZZ_CONTRACT_QTY) { raise_severity(error, 'Qty exceeds contract'); } ``` --- ### 3.3 Custom CDS Views (Read-Only Analytics) Expose custom data models for reporting without modifying SAP tables. **Use Case:** Create custom analytics on top of SAP data. - Example: "Monthly spend by cost center vs. budget" - Technology: CDS (Core Data Services) - Consumption: Fiori Analytical App / Excel / Analytics Cloud **Steps:** 1. **ABAP Workbench** (in Cloud PE) → **Create CDS View** 2. Define associations to standard SAP tables (PO, Invoice, GL, etc.) 3. Add calculations (SUM, AVG, COUNT) 4. **Publish as OData** (automatic) 5. Create Fiori app or connect to Analytics Cloud (SAC) **Limitations:** - Read-only (no CRUD operations) - Max 100M rows per query (performance limits) - Must use released SAP tables (not custom Z-tables) --- ### 3.4 Custom Business Objects (Transactional Objects) For completely new entities (not extending existing SAP objects). **Example:** "Internal Service Request" (separate from Purchase Order) **Technology:** ABAP Cloud Business Objects (BO, OData) **Development Steps:** 1. Create CDS View (root entity) 2. Define structure (header / items) 3. Create event handler (Create / Update / Delete) 4. Publish as OData V4 5. Create Fiori UI (using SAP Fiori Elements) --- ## 4. 3-Tier Extension Model ### Decision Tree: Which Tier for Your Use Case? ``` START ↓ Does your need fit Cloud PE standard? ├─→ YES → Use Standard Configuration (no extension needed) ├─→ NO → Does it require custom fields only? │ ├─→ YES → TIER 1 (Custom Fields only, end-user self-service) │ ├─→ NO → Does it require business logic (validation, calc) OR analytics? │ ├─→ YES → TIER 1 (Custom Logic via RAP / CDS Views) │ ├─→ NO → Do you need external integration (non-SAP APIs)? │ ├─→ YES → TIER 2 (BTP side-by-side app) │ ├─→ NO → Do you need classic ABAP OR table modifications? │ ├─→ YES → TIER 3 (On-Stack ABAP Cloud) │ └─→ NO → Evaluate Tier 2 (cleaner architecture) ``` ### Tier 1: Key User Extensibility (In-Cloud, No Coding*) | Capability | Tier 1 | Delivery | Ownership | |---|---|---|---| | Custom Fields | ✓ | Immediate (Fiori UI) | End User / Functional consultant | | Custom Validations | ✓ | 1-2 days (CDS Validation) | Functional consultant (no ABAP needed) | | Custom Calculations | ✓ | 1-2 days (CDS Calculation) | Functional consultant | | Custom CDS Views | ✓ | 3-5 days | ABAP Cloud developer | | Standard APIs | ✓ | 3-5 days (RAP event handler) | ABAP Cloud developer | | Custom UI (Fiori) | ✓ | 1-2 weeks | SAP Fiori developer (low-code) | *No Classic ABAP (SE38); ABAP Cloud is light-weight, CDS-centric. **Release Cycle:** Delivered in next **Cloud PE Monthly Release** (no need to wait for quarterly) --- ### Tier 2: Side-by-Side Extension (BTP, Managed Service) For use cases requiring: - External systems integration (CRM, ERP, custom legacy system) - Non-SAP data models - Complex workflows (beyond SAP workflows) - Custom UIs (Web app, Mobile, IoT) **Technology Stack:** - **BTP** (Business Technology Platform) - **CAP** (Cloud Application Programming model) - **JavaScript/TypeScript** (Node.js backend) - **Fiori / Custom HTML5** (Frontend) - **Event Mesh** (async integration) **Architecture:** ``` Cloud PE SAP ↓ APIs (OData) ↓ BTP CAP App ← Custom Logic ↓ External Services (3rd-party APIs) ↓ Custom UI (Fiori, Mobile, Web) ``` **Example:** Integration with vendor procurement system ``` Cloud PE → API Gateway → BTP CAP Service → Vendor System ↑_________________________↓ (async: purchase order created → notify vendor) ``` **Development Effort:** 4-8 weeks (includes BTP setup, CAP, testing, deployment) **Release Cycle:** Flexible (deployed directly to BTP, not tied to Cloud PE quarterly release) --- ### Tier 3: On-Stack ABAP Cloud (High-Control, Complex Logic) For use cases requiring: - Transactional consistency (multi-step atomic operations) - Table structure extensions (fields not available via Custom Fields) - Business object enhancements (complex workflows, side effects) - Legacy code conversion (ABAP Classic → ABAP Cloud) **Constraints:** - Must use **released SAP APIs only** (CHECK `/IWBEP/SBCO_APPL_TYPES`) - No classic ABAP (no SELECT ... FROM ... statements — use CDS) - No standard table modifications (use Custom Fields + RAP) - Code deployed via **Cloud ALM** (Custom Software Package) **Technology:** - **ABAP Cloud** (subset of ABAP on Cloud PE) - **RAP** (Restful ABAP Programming) - **CDS** (Core Data Services) - **Event Handlers** (Create/Update/Delete/Save) **Example:** Complex PO validation ``` ABAP Cloud Event Handler (Tier 3): CLASS zcl_po_validation DEFINITION FINAL CREATE PRIVATE ... METHODS validate( po_data TYPE STRUCT ) RAISING EXCEPTION; IF po_data-qty > contract_qty THEN RAISE EXCEPTION ... ENDIF. IF po_data-price > price_limit THEN RAISE EXCEPTION ... ENDIF. END CLASS. ``` **Release Cycle:** Deployed via **Cloud ALM** (can be mid-cycle if urgent, coordinated with SAP) --- ## 5. Fit-to-Standard Methodology **Goal:** Minimize custom extensions by adapting business process to SAP Cloud PE standard. ### 5.1 Fit-to-Standard Workshop (Day 1-3) **Participants:** Business analyst, functional consultant, IT lead, SAP solution architect **Phase 1: Current State (Day 1)** 1. Map customer's current business processes (draw swimlanes) 2. Document all deviations from SAP standard - Custom fields in use? - Custom screens? - Custom reports? - Manual workarounds? **Phase 2: Future State — Standard SAP (Day 2)** 1. Walk through SAP Cloud PE standard processes 2. Identify which customer requirements are **already satisfied** by SAP 3. Document remaining gaps (true business needs vs. legacy habits) **Phase 3: Gap Analysis (Day 2-3)** 1. For each gap, decide: - **Fit**: Change business process to match SAP standard (no extension needed) - **Extend**: Custom field / custom logic (use Tier 1/2/3) - **Workaround**: Manual process (not ideal, but sometimes business decision) **Example Gap Resolution:** | Current (Legacy) | SAP Standard | Decision | |---|---|---| | "Approval workflow must go to 3 approvers" | SAP workflows support multi-level approval | **Fit** — use standard SAP workflow (no custom code) | | "Cost center must be auto-filled from cost center master" | Standard provides default values | **Fit** — configure default values (no custom logic) | | "Invoice must reject if VAT% doesn't match contract" | SAP validation engine (CDS) exists | **Extend** — Tier 1 Custom Logic (1-2 days) | | "System must call legacy SMTP gateway for email" | SAP Cloud PE cannot call legacy on-premise | **Workaround** — use BTP Email Service or Tier 2 | ### 5.2 Delta Design (Post-Workshop) Create document (delivered to customer): ``` DELTA DESIGN DOCUMENT ==================== 1. Processes Fitting Standard (0 extensions needed) - Purchasing (PO to GR to IV) - Accounts Payable - Sales Order to Invoice 2. Required Extensions (Tier 1/2/3) a) Custom Field: Cost Center Sub-Division (Tier 1) Effort: 2 days Release: Next monthly release b) Custom Logic: PO Approval Workflow (Tier 1, CDS validation) Effort: 5 days Release: Next monthly release c) Side-by-Side: Vendor Portal (Tier 2, BTP CAP) Effort: 6 weeks Deployment: Separate BTP tenant 3. Workarounds (Manual Steps) - Monthly reconciliation report generation (IT manual export) - Legacy data migration (via LSMW, one-time) TOTAL EXTENSION EFFORT: 7 weeks (vs. 6 months if no Fit-to-Standard) CUSTOM CODE FOOTPRINT: 2 Tier 1 + 1 Tier 2 (minimal maintenance) ``` --- ## 6. Cloud ALM (Application Lifecycle Management) SAP's governance tool for Cloud PE updates, extensions, and quality assurance. ### 6.1 Cloud ALM Phases ``` IMPLEMENTATION PHASE (Go-Live Preparation) ├─ Test cycles (SIT, UAT) ├─ Regression testing ├─ Go-live cutover planning └─ Data load validation OPERATIONS PHASE (Post Go-Live) ├─ Quarterly SAP release upgrades (automatic) ├─ Custom extensions deployment ├─ Hotfix management └─ Issue management & change requests ``` ### 6.2 Deployment via Custom Software Package (CSP) **CSP** = deliverable unit for Tier 1 / Tier 3 custom extensions. **Contents:** - CDS Views (custom logic, analytics) - RAP Behavior (validations, calculations) - Fiori UI components - Custom business objects - Transport artifacts **Deployment Process:** 1. **Developer** → Package extension in ABAP Workbench 2. **Quality Gate** → Run Cloud ALM quality checks (ABAP Unit, Integration tests) 3. **SAP Review** (optional, for Tier 3) → SAP validates against released API list 4. **Upload to Cloud ALM** → CSP package 5. **Cloud PE Apply** → Deploy to production tenant (with rollback capability) --- ### 6.3 Quarterly Release Management SAP releases Cloud PE updates **every month** (for security/minor features) and **major release every quarter** (functional features, UI updates). | Activity | Frequency | Your Action | |---|---|---| | Security patches | Monthly (1st Tuesday) | Auto-applied by SAP (0 downtime) | | Feature releases | Quarterly | Review FSD (Feature Scope Description) | | Custom extension re-validation | Monthly | Check if your custom code still works | | Regression testing | Quarterly | Full regression suite (Cloud ALM) | **Key:** Cloud PE upgrades are **mandatory** and happen overnight (UTC). Plan testing for next day. --- ## 7. Feature Scope Description (FSD) Before each quarterly release, SAP publishes **FSD** — detailed list of new features, deprecations, and breaking changes.