Comparing Development Approaches: SAP BTP vs. Traditional ECC Methods

APPROACH 1 – S/4 HANA and BTP Approach

Step 1: Understand Business Requirements

• Gather detailed requirements for the app: Identify the approval criteria for sales orders (e.g., orders exceeding a specific price threshold). Define user roles (e.g., Sales Rep, Pricing Manager). Specify actions users can take (e.g., Approve, Reject, Modify Price).
• Ensure that the app will interact with S/4HANA sales order data (e.g., VBAK, VBAP tables).

Step 2: Set Up SAP BTP Environment

1. Subscribe to SAP BTP Services: Access the SAP BTP Cockpit. Subscribe to services such as: SAP Extension Suite (for building the app). SAP Integration Suite (for secure communication with S/4HANA). SAP Business Application Studio (for app development).
2. Provision SAP HANA Cloud (if required): Set up SAP HANA Cloud for storing any additional data or logs.
3. Configure Destinations: Define a destination in the BTP Cockpit to connect with the S/4HANA system. Use the OAuth2ClientCredentials authentication method for secure API access.

Step 3: Design the Application

1. Use SAP Fiori for UI Design: Create a wireframe of the app using SAP Fiori principles. Include: A dashboard showing sales orders awaiting approval. A detailed view for order information, pricing details, and action buttons (Approve/Reject).
2. Choose Development Tool: Use SAP Business Application Studio for development. It provides templates for Fiori apps.

Step 4: Build the Backend Logic

1. Expose S/4HANA Sales Order Data via APIs: Access the SAP API Business Hub to find pre-built APIs for sales orders. Example API: /API_SALES_ORDER_SRV. Enable the required OData service in the S/4HANA backend (use transaction SICF to activate).
2. Develop Backend Services: Use Node.js or Java to create backend logic on BTP. Implement: API calls to fetch sales order data. Business rules for approval logic (e.g., reject orders above a price threshold without manager approval). Deploy backend services to the Cloud Foundry environment.

Step 5: Build the Frontend Application

1. Create a Fiori App: Use SAP Business Application Studio: Select the SAP Fiori Application template. Configure data source using the OData service from S/4HANA.
2. Develop UI Components: Create a list report to display sales orders awaiting approval. Add navigation to a detailed page showing order information. Include buttons for actions (Approve, Reject, Modify).
3. Bind Data to UI: Use SAPUI5 framework to bind API responses to frontend components.

Step 6: Integrate APIs

1. Connect App with Backend Services: Use the OData V2 or V4 protocol to fetch sales order details. Ensure secure communication using SAP BTP destinations.
2. Update Sales Orders in S/4HANA: Use PATCH/POST methods of the API to send approval decisions back to S/4HANA. Example: Approve: Update the VBAP status field. Reject: Add a rejection reason in a custom field.

Step 7: Test the Application

1. Unit Testing: Test backend services and APIs for expected behaviour. Validate business rules and edge cases (e.g., orders with missing data).
2. UI Testing: Test navigation, data binding, and user actions in the Fiori app.
3. Integration Testing: Test the end-to-end flow: Fetch orders → Display in the app → Send approval decision → Verify S/4HANA updates.

Step 8: Deploy the Application

1. Deploy to Cloud Foundry: Use the SAP Business Application Studio or CLI to deploy the app to BTP. Configure the app’s routing to expose it to end-users.
2. Configure Access: Assign roles and authorizations in SAP Identity Authentication Service (IAS). Ensure only authorized users can access the app.

Step 9: Monitor and Maintain

1. Set Up Logging and Monitoring: Use SAP BTP monitoring tools to track API usage, app performance, and errors. Enable logging for key actions (e.g., approvals, rejections).
2. Optimize: Gather user feedback to enhance app usability. Regularly update the app to accommodate new business requirements or S/4HANA changes.

Example Use Case in Action

1. A sales rep creates a sales order in S/4HANA.
2. The pricing exceeds a pre-set threshold, so the order status is flagged as “Pending Approval.”
3. The custom app fetches the flagged order and displays it on the Pricing Manager’s dashboard.
4. The manager views the order details, adjusts the pricing, and approves it.
5. The app updates the sales order status to “Approved” in S/4HANA via the API.

APPROACH 2 – Doing it old way in ECC

Building a similar custom pricing approval app using ECC instead of SAP BTP would involve more manual steps, limited flexibility, and a lack of advanced tools. Here’s a comparison of how it could be achieved in ECC and how SAP BTP makes the process more streamlined and advanced.

Custom Pricing Approval App in ECC

Step 1: Gather Requirements

Similar to SAP BTP, requirements are collected upfront. However, implementing them in ECC often involves greater technical complexity.

Step 2: Develop Custom Functionality in ECC

1. Custom ABAP Development: The app logic would need to be built entirely in ABAP. Create a Z-table to track sales orders pending pricing approval. Develop ABAP reports for listing pending approvals and updating sales orders after approval. Use User Exits or BAdIs to add custom fields to sales orders for tracking approval status.
2. Manual Integration for Data Updates: Write custom ABAP programs to fetch and update sales order data. Integrations with external systems (if needed) would require IDocs or manual file handling.

Step 3: Build the User Interface

1. SAP GUI-Based Transactions: Build a custom transaction (e.g., ZAPPROVE) for pricing approvals using ABAP and Screen Painter. The UI would be limited to SAP GUI, lacking the modern, user-friendly experience provided by Fiori.
2. Web UI (Optional): If a web-based interface is needed, use SAP Web Dynpro or SAP BSP (Business Server Pages), both of which involve a steep learning curve and limited UI capabilities.

Step 4: Implement Approval Logic

1. Validation via Custom ABAP Code: Approval criteria would be hardcoded or stored in Z-tables, making it inflexible. Status updates for sales orders would require explicit ABAP programs.
2. Workflow Integration: Implement SAP Workflow for approvals: Design a custom workflow using SWDD. Configure events to trigger workflows based on sales order conditions (e.g., price > threshold).

Step 5: Test and Deploy

1. Testing: Test ABAP programs, workflows, and manual integrations in a development environment.
2. Deployment: Transport the custom development (workflows, reports, and Z-programs) to production via the Transport Management System (TMS).

Challenges with ECC Approach

1. Limited Extensibility: Modifications often require direct changes to the core ECC system, leading to upgrade challenges. Extensions are tied to the core, making the system less flexible and future changes cumbersome.
2. Outdated User Interface: The SAP GUI and Web Dynpro interfaces are less intuitive and user-friendly compared to modern Fiori UIs.
3. Integration Complexity: Connecting external systems (e.g., email notifications, third-party approvals) requires additional middleware, such as SAP PI/PO, increasing time and cost.
4. No Real-Time Analytics: Analytics capabilities in ECC are limited to custom ABAP reports, which cannot offer real-time insights or dashboards.
5. Resource Intensive: Requires significant time and effort to develop and maintain custom ABAP programs and workflows.

How SAP BTP Makes It Advanced

1. No Core Modifications

• With SAP BTP, all extensions are side-by-side, ensuring the S/4HANA core remains clean.
• This approach makes upgrades smooth and reduces dependency on the core system.

2. Modern User Experience

• BTP enables you to build apps with SAP Fiori, providing a modern, intuitive UI accessible from any device.
• Custom workflows are visually managed using SAP Workflow Management or SAP Build Process Automation.

3. Simplified Integration

• Pre-built APIs in the SAP API Business Hub eliminate the need for custom integration logic.
• Event-driven architecture automates workflows and processes without constant polling or manual interventions.

4. Embedded Analytics

• Real-time insights and dashboards are possible with SAP Analytics Cloud, embedded directly in the app.
• Users can make informed decisions without switching between multiple systems or reports.

5. Rapid Development

• BTP offers low-code/no-code tools like SAP Build, enabling faster development cycles.
• Ready-to-use templates and integration scenarios reduce the need for manual coding.

6. Scalability

• BTP apps are inherently scalable, allowing organizations to handle growing data and user demands without re-architecting the solution.

Conclusion

While ECC provides the foundation for custom development, it requires manual effort, heavy coding, and complex integrations. SAP BTP, on the other hand, revolutionizes the process with side-by-side extensibility, APIs, modern UI tools, and real-time capabilities, making it the superior platform for innovation in today’s SAP landscape.

ECC vs SAP BTP Comparison

SAP BTP significantly outperforms ECC in areas such as:

• Development time (faster on BTP).
• User interface (modern and intuitive with SAP Fiori).
• Extensibility (side-by-side approach with no core changes).
• Integration (seamless with APIs and pre-built connectors).
• Analytics (real-time with embedded capabilities).
• Upgrade challenges (minimal for BTP due to clean core).