Part 2 of 3: Building Future-Proof Extensions in SAP S/4HANA Public Cloud
Introduction
In Part 1, we explored the fundamental paradigm shift that SAP S/4HANA Public Cloud brings to the SAP ecosystem. We established that traditional development approaches—direct system modifications, transport file manipulation, and custom ABAP program installations—are no longer viable in the Clean Core architecture.
Now comes the critical question: How do we actually build robust, maintainable extensions that survive SAP’s quarterly updates while delivering business value? This isn’t just about learning new tools—it’s about adopting an entirely new development philosophy that embraces constraints as design principles.
As ReleaseOwl works with organizations transitioning to Public Cloud, we consistently see the same challenge: developers with decades of traditional SAP experience struggling to translate their expertise into Clean Core-compliant solutions. This blog provides a practical roadmap for making that transition successfully.
The Clean Core Development Stack: Your New Toolkit
Understanding the Extension Hierarchy
SAP S/4HANA Public Cloud provides a structured hierarchy of extension options, each with specific use cases and constraints:
Tier 1: Key User Extensibility
- Custom Fields and Tabs: Add fields to standard business objects using the Custom Fields app
- Custom Logic: Implement simple business rules using the Custom Logic app
- Custom CDS Views: Create analytical views for reporting purposes
- Software Collections: Bundle and transport key user extensions across systems
Tier 2: Developer Extensibility (In-Stack)
- RAP-based Applications: Build applications using the ABAP RESTful Application Programming Model
- ABAP Classes and Interfaces: Develop reusable components following Clean Core principles
- Business Add-Ins (BAdIs): Implement enhancement points provided by SAP
- Git-enabled Change and Transport System (gCTS): Version control and transport ABAP developments
Tier 3: Side-by-Side Extensions (SAP BTP)
- CAP Applications: Build business applications using the Cloud Application Programming Model
- UI5 Applications: Develop modern web interfaces
- Integration Flows: Orchestrate data and processes across systems
- Multi-Target Applications (MTARs): Deploy complex, multi-service applications
Key User Extensibility: The Foundation Layer
Custom Fields: Beyond Simple Field Additions
Custom fields in Public Cloud are far more powerful than their traditional counterparts, but they require careful planning:
abap
// Example: Adding a custom field with validation logic
// This approach ensures Clean Core compliance
@EndUserText.label: ‘Project Risk Category’
@EndUserText.quickInfo: ‘Risk assessment category for project management’
define view extension view ZC_PROJECTEXT as projection on I_Project {
Project,
@UI.fieldGroup: [{
position: 10,
qualifier: ‘RiskAssessment’
}]
@Consumption.valueHelpDefinition: [{
entity: {
name: ‘I_RiskCategory’,
element: ‘RiskCategoryCode’
}
}]
cast(” as zproject_risk_category) as ProjectRiskCategory
}
Best Practice Guidelines for Custom Fields:
- Semantic Naming: Use business-meaningful names that will remain relevant through SAP updates
- Data Element Reuse: Leverage existing SAP data elements where possible to maintain consistency
- Value Help Integration: Connect to standard value help sources to ensure data integrity
- Validation Logic: Implement validation at the field level rather than through custom programs
Software Collections: The New Transport Mechanism
Software Collections replace traditional transport requests for key user extensions. Unlike transport requests that bundled multiple change types, Software Collections are focused and purpose-built:
Collection Strategy Best Practices:
yaml
# Example Software Collection Structure
Collection Name: “Sales_Process_Enhancement_v1.2”
Description: “Enhancements for quarterly sales review process”
Components:
– Custom Fields:
– Sales Document: QuarterlyReviewStatus
– Customer Master: SalesRiskRating
– Custom Logic:
– Auto-populate review status based on sales performance
– CDS Views:
– Sales Performance Analytics
– Customer Risk Assessment
Dependencies:
– Standard Business Roles: Sales Manager, Sales Representative
– Configuration Sets: Sales Area Configuration
Critical Success Factors:
- Atomic Collections: Each collection should represent a complete business feature
- Dependency Mapping: Clearly document all dependencies to prevent deployment failures
- Version Management: Use semantic versioning to track collection evolution
- Testing Integration: Include test scenarios that validate collection functionality
Developer Extensibility: RAP and Clean Core ABAP
The ABAP RESTful Application Programming Model (RAP)
RAP represents the future of ABAP development in Public Cloud. It enforces Clean Core principles through its architecture:
Core RAP Concepts:
- CDS-Based Data Models: All data access goes through CDS views
- Behavior Definitions: Business logic is implemented in dedicated behavior classes
- Service Exposure: Applications are exposed as OData services automatically
- Transactional Consistency: Built-in support for draft handling and transaction management
Example: Building a RAP-Based Purchase Requisition Enhancement
abap
// Data Model (CDS View)
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: ‘Purchase Requisition Extension’
define root view entity ZC_PURCHREQ_EXT as projection on ZI_PURCHREQ_EXT {
key PurchaseRequisition,
PurchaseRequisitionItem,
@EndUserText.label: ‘Approval Workflow Status’
ApprovalWorkflowStatus,
@EndUserText.label: ‘Business Justification’
BusinessJustification,
@EndUserText.label: ‘ROI Calculation’
ROICalculation,
/* Associations to standard SAP objects */
_PurchaseRequisition,
_PurchaseRequisitionItem
}
// Behavior Definition
managed implementation in class zcl_bp_purchreq_ext unique;
strict ( 2 );
define behavior for ZC_PURCHREQ_EXT alias PurchReqExt
persistent table zpurchreq_ext
lock master
authorization master ( global )
{
field ( readonly ) PurchaseRequisition, PurchaseRequisitionItem;
field ( mandatory ) ApprovalWorkflowStatus;
create;
update;
delete;
validation validateBusinessJustification on save { field BusinessJustification; }
determination calculateROI on modify { field BusinessJustification; }
mapping for zpurchreq_ext {
PurchaseRequisition = purchase_requisition;
PurchaseRequisitionItem = purchase_requisition_item;
ApprovalWorkflowStatus = approval_status;
BusinessJustification = business_justification;
ROICalculation = roi_calculation;
}
}
// Behavior Implementation
CLASS zcl_bp_purchreq_ext DEFINITION INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
METHODS validateBusinessJustification FOR VALIDATE ON SAVE
IMPORTING keys FOR PurchReqExt~validateBusinessJustification.
METHODS calculateROI FOR DETERMINE ON MODIFY
IMPORTING keys FOR PurchReqExt~calculateROI.
ENDCLASS.
CLASS zcl_bp_purchreq_ext IMPLEMENTATION.
METHOD validateBusinessJustification.
READ ENTITIES OF ZC_PURCHREQ_EXT IN LOCAL MODE
ENTITY PurchReqExt
FIELDS ( BusinessJustification )
WITH CORRESPONDING #( keys )
RESULT DATA(lt_entities).
LOOP AT lt_entities INTO DATA(ls_entity).
IF strlen( ls_entity-BusinessJustification ) < 50.
APPEND VALUE #( %tky = ls_entity-%tky ) TO failed-purchreqext.
APPEND VALUE #(
%tky = ls_entity-%tky
%msg = new_message_with_text(
severity = if_abap_behv_message=>severity-error
text = ‘Business justification must be at least 50 characters’
)
) TO reported-purchreqext.
ENDIF.
ENDLOOP.
ENDMETHOD.
METHOD calculateROI.
” Implementation of ROI calculation logic
” This method demonstrates how business logic is cleanly separated
” and remains testable and maintainable
ENDMETHOD.
ENDCLASS.
Git-enabled Change and Transport System (gCTS)
gCTS fundamentally changes how we manage ABAP code in Public Cloud by introducing Git-based version control:
gCTS Best Practices:
- Repository Structure: Organize code by business domain, not technical layers
/src
/purchasing
/master_data
/requisitions
/purchase_orders
/sales
/quotations
/orders
/billing
- Branching Strategy: Adopt a Git flow appropriate for SAP’s quarterly updates
yaml
Branch Strategy:
– main: Production-ready code
– develop: Integration branch for features
– feature/*: Individual development branches
– hotfix/*: Emergency fixes
– release/Q1-2024: Preparation for quarterly updates
- Commit Standards: Use conventional commits for clear change tracking
feat(purchasing): add approval workflow for high-value requisitions
fix(sales): resolve calculation error in discount application
refactor(core): optimize CDS view performance for large datasets
Side-by-Side Extensions: SAP BTP Development
Cloud Application Programming Model (CAP)
For complex business applications that extend beyond what’s possible with in-stack development, CAP provides a powerful framework:
Example: Building a Vendor Risk Assessment Application
javascript
// Service Definition (CDS)
using { cuid, managed } from ‘@sap/cds/common’;
using { API_SUPPLIER_SRV } from ‘./external/API_SUPPLIER_SRV’;
namespace vendorrisk;
entity VendorRiskAssessments : cuid, managed {
vendor : Association to API_SUPPLIER_SRV.A_Supplier;
riskScore : Integer @assert.range: [1, 10];
riskCategory : String enum { HIGH; MEDIUM; LOW };
assessmentDate : Date;
assessor : String;
comments : String(1000);
approvalStatus : String enum { PENDING; APPROVED; REJECTED };
// Calculated fields
virtual daysUntilReview : Integer;
}
// Service Implementation
service VendorRiskService {
@requires: ‘VendorManager’
entity VendorRiskAssessments as projection on vendorrisk.VendorRiskAssessments
actions {
@requires: ‘VendorApprover’
action approve();
@requires: ‘VendorApprover’
action reject(reason: String);
action calculateRiskScore() returns Integer;
};
@readonly
entity Suppliers as projection on API_SUPPLIER_SRV.A_Supplier {
Supplier,
SupplierName,
Country,
SupplierAccountGroup
};
}
Integration Patterns with S/4HANA Public Cloud:
- API-First Approach: Always use official SAP APIs for data exchange
- Event-Driven Architecture: Leverage SAP Event Mesh for real-time integration
- Security Integration: Use SAP Identity Authentication Service for SSO
Testing Strategies for Clean Core Compliance
Automated Testing Framework
Clean Core development requires comprehensive automated testing to ensure quarterly update compatibility:
Unit Testing for RAP Applications:
abap
CLASS ltc_purchase_req_validation DEFINITION FOR TESTING
DURATION SHORT
RISK LEVEL HARMLESS.
PRIVATE SECTION.
DATA: mo_cut TYPE REF TO zcl_bp_purchreq_ext.
METHODS: setup,
test_business_justification_validation,
test_roi_calculation,
test_approval_workflow.
ENDCLASS.
CLASS ltc_purchase_req_validation IMPLEMENTATION.
METHOD setup.
mo_cut = NEW #( ).
ENDMETHOD.
METHOD test_business_justification_validation.
” Test that validates business justification requirements
” This ensures the validation logic remains functional
” across SAP quarterly updates
DATA(lt_test_data) = VALUE ztab_test_data(
( justification = ‘Too short’ expected_result = ‘ERROR’ )
( justification = ‘This is a comprehensive business justification that exceeds the minimum character requirement and should pass validation’ expected_result = ‘SUCCESS’ )
).
LOOP AT lt_test_data INTO DATA(ls_test).
” Execute validation logic
” Assert expected results
ENDLOOP.
ENDMETHOD.
ENDCLASS.
Integration Testing with SAP APIs
javascript
// CAP Application Testing
const cds = require(‘@sap/cds’);
const { expect } = require(‘chai’);
describe(‘Vendor Risk Service’, () => {
let vendorRiskService;
before(async () => {
vendorRiskService = await cds.connect.to(‘VendorRiskService’);
});
it(‘should calculate risk score correctly’, async () => {
const testVendor = {
vendor_Supplier: ‘TEST001’,
riskCategory: ‘HIGH’,
assessmentDate: ‘2024-01-15’
};
const result = await vendorRiskService.run(
INSERT.into(‘VendorRiskAssessments’).entries(testVendor)
);
expect(result.riskScore).to.be.within(1, 10);
});
it(‘should integrate with SAP S/4HANA supplier data’, async () => {
const suppliers = await vendorRiskService.run(
SELECT.from(‘Suppliers’).limit(10)
);
expect(suppliers).to.be.an(‘array’);
expect(suppliers[0]).to.have.property(‘Supplier’);
});
});
Performance Optimization in Clean Core
CDS View Optimization
Performance optimization in Public Cloud focuses on efficient CDS view design:
sql
— Optimized CDS View Example
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@ClientHandling.algorithm: #SESSION_VARIABLE
define view ZI_SALES_PERFORMANCE_OPT as select from vbak as SalesOrder
inner join vbap as SalesItem
on SalesOrder.vbeln = SalesItem.vbeln
inner join kna1 as Customer
on SalesOrder.kunnr = Customer.kunnr
{
@Semantics.businessDate.from: true
SalesOrder.erdat as OrderDate,
@Semantics.amount.currencyCode: ‘TransactionCurrency’
@Aggregation.default: #SUM
SalesItem.netwr as NetValue,
@Semantics.currencyCode: true
SalesItem.waerk as TransactionCurrency,
@ObjectModel.text.element: [‘CustomerName’]
SalesOrder.kunnr as Customer,
Customer.name1 as CustomerName,
@Semantics.calendar.year: true
extract_year(SalesOrder.erdat) as SalesYear,
@Semantics.calendar.quarter: true
extract_quarter(SalesOrder.erdat) as SalesQuarter
}
where SalesOrder.vbtyp = ‘C’ — Sales orders only
and SalesItem.abgru = ” — Not rejected items
Performance Best Practices:
- Early Filtering: Apply filters as early as possible in the view hierarchy
- Appropriate Joins: Use inner joins when possible, left outer joins only when necessary
- Aggregation Optimization: Use built-in aggregation functions rather than custom logic
- Client Handling: Properly configure client handling for multi-client scenarios
Monitoring and Observability
Application Performance Monitoring
Clean Core applications require different monitoring approaches:
yaml
# Cloud ALM Integration for Custom Applications
Monitoring Configuration:
Application: “Vendor Risk Assessment”
Technical Monitoring:
– Response Time Thresholds: < 2 seconds
– Error Rate Threshold: < 1%
– Memory Usage: Monitor CAP application memory consumption
Business Monitoring:
– Risk Assessment Completion Rate
– Approval Workflow Cycle Time
– Integration API Success Rate
Alert Configuration:
Critical:
– SAP API Integration Failures
– Database Connection Issues
Warning:
– Performance Degradation
– High Error Rates in Business Logic
Preparing for Quarterly Updates
Update Compatibility Checklist
Before each quarterly update, validate your extensions:
Pre-Update Testing Protocol:
- API Compatibility: Verify all consumed SAP APIs remain stable
- Extension Point Validation: Confirm BAdI implementations still function
- Custom Field Integrity: Ensure custom fields maintain their configuration
- Integration Testing: Validate end-to-end business processes
- Performance Regression: Benchmark application performance
Post-Update Validation:
abap
” Automated post-update validation program
REPORT z_post_update_validation.
CONSTANTS: gc_test_suite TYPE string VALUE ‘POST_UPDATE_VALIDATION’.
DATA: lo_test_runner TYPE REF TO cl_test_runner,
lt_test_results TYPE TABLE OF test_result.
START-OF-SELECTION.
” Execute comprehensive test suite
lo_test_runner = cl_test_runner=>create( gc_test_suite ).
lo_test_runner->run_tests( ).
” Generate validation report
lt_test_results = lo_test_runner->get_results( ).
” Send notifications for any failures
LOOP AT lt_test_results INTO DATA(ls_result) WHERE status = ‘FAILED’.
” Implement notification logic
ENDLOOP.
Migration Strategies from Traditional SAP
Assessment and Planning
For organizations transitioning from traditional SAP systems:
Customization Analysis Framework:
- Inventory Current Customizations
-
- Catalog all modifications, user exits, and enhancements
- Assess business criticality and usage frequency
- Identify potential Clean Core alternatives
- Feasibility Assessment
-
- Technical feasibility: Can this be implemented in Clean Core?
- Business necessity: Is this customization still needed?
- Alternative solutions: Can standard functionality replace this?
- Migration Roadmap
-
- Phase 1: Key user extensibility migrations
- Phase 2: Developer extensibility (RAP applications)
- Phase 3: Side-by-side extensions for complex scenarios
Conclusion
Developing for SAP S/4HANA Public Cloud requires a fundamental shift in mindset from “how do I modify the system?” to “how do I extend the system cleanly?” This isn’t just about learning new tools—it’s about embracing constraints as design principles that ultimately lead to more maintainable, upgradeable solutions.
The Clean Core approach, while initially constraining, provides a structured path to building extensions that survive quarterly updates and align with SAP’s long-term product strategy. Organizations that master these development practices will find themselves with more stable systems, predictable operations, and faster access to SAP innovations.
The key to success lies in understanding that Clean Core isn’t a limitation—it’s a methodology that, when properly implemented, delivers superior outcomes for both technical teams and business users.
In Part 3 of our series, we’ll explore how to implement comprehensive change management and testing strategies that ensure your Clean Core extensions remain robust and reliable through SAP’s continuous update cycle.
This is Part 2 of our 3-part series on SAP S/4HANA Public Cloud. Coming up in Part 3: “Change Management and Testing in the Continuous Update Era” – where we’ll explore how to build processes and frameworks that ensure your extensions remain stable and compliant through SAP’s quarterly update cycle.
Leave A Comment