ERP PPL Integration with Agentic AI Hello

its on erp ppl integration

1. Integration Strategy Integration strategy June 2025 Prepared By ​ Seema Nachankar Pankaj KumaR

2. Agenda Introduction and Objective Landscape Architecture Integration Principles Integration Tools & Technologies Integration Patterns Security and Authentication Monitoring and Error Handling Interface Inventory and Future Strategy Q&A

3. Introduction and Objectives As part of the SAP S/4HANA transformation journey, a seamless, scalable, and secure integration strategy is essential to enable consistent data flow and process orchestration across the enterprise ecosystem. Objectives: Provide overview of the integration strategy approach O utlines the approach to designing, delivering, and governing system integrations required to support core business processes Outlines SAP’s modern integration technologies to ensure a flexible and future-ready integration architecture Outlines the security, enable proactive monitoring and error handling.  

4. Proposed Environment Strategy (Discovery) SBX Discovery phase DEV Discovery phase QAS Test Phase TRN Test Phase UAT Test Phase PRD Test Phase Integration Suite(BTP) Integration Suite(BTP) Integration Suite(BTP) Integration Suite(BTP) Integration Suite(BTP) SAP Cloud ALM (BTP) SAP ALM(BTP) Datasphere (BTP) Datasphere (BTP) Datasphere (BTP) Datasphere (BTP) SAP Signavio SAP Ariba SAP Ariba SAP Success Factors SAP SuccessFactors SAP Enable Now SAP Concur SAP Concur Cloud Connector(Prod) Cloud connector (Non-Prod) webdisp webdisp webdisp webdisp BODS DP Agent DP Agent DP Agent Staging DB S4 with Fiori S4 with Fiori S4 with Fiori DP Agent webdisp webdisp DP Agent BODS Staging DB BODS Staging DB BODS Staging DB S4 with Fiori S4 with Fiori S4 with Fiori SAP BTP Integration Suite SAP BTP Integration Suite(BTP)

5. Detailed Combined Future State Technical Architecture SAP Biz Tech Platform (integration Suite) API /Microservices Layer (Includes API Gateway) Unified IAM/User MGMT Profile MGMT *Not a comprehensive list of all integrations Token (ServiceNow Framework) Service now HR Service Delivery Case MGMT Error Handling Event Logging Employee Onboarding Observability SAP Procurement Sourcing SAP ARIBA Contracts Supplier Lifecycle and Performance Supplier Risk Buying and Invoicing SAP HXM (Success) SAP SFSF Recruiting SAP SFSF Onboarding Talent Management Suite SAP SFSF Learning SAP SFSF Career & Talent Development SAP SFSF Compensation Core HR Core EC Payroll SAP Workforce Forecasting SAP Absence and Leave Management Time & Attendance Management BSI SAP Web Layer SAP FIORI SAP UI5 Web Dispatcher S4 HANA (ERP) Finance Finance Group Reporting Environment Mgmt Treasury and Risk Mgmt. EHS Workplace Safety Cash Mgmt Access Control Adv Payment Mgmt Materials Management Document and Reporting Compliance General Ledger Account Payable Adv Financial Closing SAP SAC (Reporting) Forecasting Budgeting Reporting Other VS Power Plan SAP Enable Now Signavio Concur Blackline Additional Integrations UI Model (LRP) OpenText Additional SAP Integrations SAP Cloud ALM Error Handling Cloud Connector SAP Analytics Cloud Analytics Datasphere Field HxGN Fleet Focus FA Suite FT Customer KY SAP CSS RI CSS PA OpenGrid (KY/RI) Maximo (KY) Cascade Sailpoint

6. Integration Principles Principle Description API-First Approach Prefer standardized APIs (OData/REST/SOAP/RFC) for integration over custom interfaces. All modern SAP systems (e.g., S/4HANA, BTP) are API-centric. Standard Over Custom Prefer standard SAP-delivered content (like iFlows, APIs, pre-packaged integration) over building custom interfaces. Separation of Concerns Keep business logic, routing, and data transformation independent. Use middleware (like SAP Integration Suite) for routing and transformation. Use of Middleware Always use a centralized integration platform like SAP Integration Suite (CPI) for orchestrating integrations. Avoid point-to-point unless justified. Reusability Design integration content (iFlows, mappings, APIs) to be modular and reusable across different use cases or processes. Security by Design Integrations must include authentication, authorization, encryption, and auditability from the beginning (e.g., OAuth 2.0, SAML, HTTPS). Monitoring & Error Handling Design for observability: logging, alerting, and handling errors gracefully using tools like SAP Integration Suite Monitor or SAP Solution Manager. Loose Coupling Systems should interact without being tightly dependent on each other’s internal logic. This ensures flexibility, upgradability, and resilience. Cloud-Native Readiness Design integrations to be cloud-scalable, stateless, and resilient, particularly when involving SAP BTP or hyperscaler platforms (Azure, AWS, GCP).

7. Integration Tools SAP BTP Integration Suite Cloud Integration API Management Open Connector Event Mesh Trading Partner Management Integration Advisor Edge Integration Cell Microsoft Azure Microservices Globalscape System

8. Core Process Integration Architectural Aspects Translation between different protocols possible Mapping, transformation, data enrichment, splitting or routing possible Transport layer encryption Central API management layer provides authentication and central monitoring features Published APIs for reusability Non SAP or Cloud domain Core domain Non SAP or Non SAP *SAP S4HANA -based SAP systems Cloud Integration Suite Central API Management Integration Patterns: Core to Cloud Integration SAP systems

9. Integration Style Use Case Scenario Example Integration Tool / Methodology Integration Description Process Integration Standard Content ( Iflow ) SAP S/4 HANA to SAP Service Cloud SAP Integration Suite (CPI) Standard integration using Middleware Process Integration Messaging with/without Transformation + Custom Iflow SAP S/4 HANA to SAP Service Cloud SAP Integration Suite (CPI) Extension of Standard iFlow with requirements like Transformation, Mediation, or Routing Process Integration Messaging without Transformation + Registration of SOAP/REST/OData service (with or without Quota or Strict Governance) SAP S/4 HANA to Power Plan Microsoft Azure Microservice Simple Pass-through OR with strict requirements (Quota / Traffic Management / Security Policies) Process Integration Messaging with Transformation + Quota Management / Strict Governance SAP S/4HANA → Multiple Wausau / Oracle ERP Microsoft Azure Microservice Involves Transformation, Mediation, Routing + strict Quota/Security/Traffic Management policies Process Integration File transfers US Bank SFTP → Oracle ERP / EPM SFTP SAP Clould Integration or Globalscape System Simple Pass through scenario Integration Patterns: OnPrem to Cloud

10. Core domain Cloud domain Native integration (SAP to SAP) Architectural Aspects Only applicable if no re-use of transmitted information is expected Common standard functionality with vendor supported connectors SAP provided standard integration components are used Mapping, transformation, data enrichment, splitting or routing not required Load balancing not required Transport layer encryption Synchronous request – response and asynchronous communication possible Central monitoring is not required (will be provided by source or target system) * SAP S4HANA -based SAP systems SAP systems Integration Patterns: Cloud to OnPrem Integration Impact: Each interface needs to be evaluated for maintainability, operations and future proofing. Each interface needs additional Security assessment.

11. Integration Style Use Case Scenario Example Integration Tool / Methodology Integration Description Process Integration Standard Content (Iflow) SAP Service Cloud to SAP S/4 HANA SAP Integration Suite (CPI) Standard integration using Middleware Process Integration Messaging with/without Transformation + Custom Iflow SAP Service Cloud to SAP S/4 Hana SAP Integration Suite (CPI) Extension of Standard Iflow - Integration logic requirement ( Transformation / Mediation / Routing ) Process Integration Messaging without Transformation + (Registration of SOAP/REST/Odata service ) with or without Quota requirement or Strict governance SEW to SAP S/4 HANA 3rd Party to SAP S/4 Hana Microsoft Azure Microservice Simple Pass through scenario OR Pass through with strict requirement for Quota/ Traffic management of API calls OR Pass through with strict requirement for Security policies Process Integration Messaging with Transformation and Quota management / Strict governance Multiple Payment Vendor to SAP S/4 HANA Microsoft Azure Microservice Integration logic requirement ( Transformation / Mediation / Routing ) + (Strict requirement for Quota / Traffic management of API calls / Strict Security policies for API calls) Process Integration File transfers US Bank SFTP to Globalscape SFTP to SAP S/4 Hand Globalscape System or SAP Clould Integration Simple Pass-through scenario Integration Patterns: Cloud to OnPrem

12. 12 Integration Process(Reusable APIs with Central Governance) Cloud domain Non SAP Cloud domain Non SAP Cloud Integration Suite Central API Management Architectural Aspects Central discovery of provided APIs for reusability Translation between different protocols possible Mapping, transformation, data enrichment, splitting or routing possible with SCPI Transport layer encryption Central API management layer provides authentication and central monitoring features Application with built-in API gateways should be integrated via the Central API management to support reusability and central governance. Integration Patters: Cloud to Cloud Integration

13. Integration Style Use Case Scenario Example Integration Tool / Methodology Integration Description Process Integration Messaging without Transformation + (Registration of SOAP/REST/ Odata service ) with or without Quota requirement or Strict governance SAP Service Cloud to Power Plan Microsoft Azure Microservice API based exchange - Simple Pass through scenario OR Pass through with strict requirement for Quota/ Traffic management of API calls OR Pass through with strict requirement for Security policies Point to Point Direct Communication without Transformation CTI to Service Cloud Or SAP Service Cloud to DQM Direct connection Process Integration Messaging with Transformation SAP Service Cloud to Experian Microsoft Azure Microservice API based exchange - Integration logic requirement ( Transformation / Mediation / Routing ) Integration Patter n s: Cloud to Cloud

14. Native integration Core domain Non SAP *S4 HANA based SAP systems Core domain Non SAP *S4 HANA -based SAP systems or or Integration Patterns: OnPrem to OnPrem Integration Architectural Aspects Only applicable if no re-use of transmitted information is expected Common standard functionality with vendor supported connectors Translation between different protocols not required Mapping, transformation, data enrichment, splitting or routing not required Load balancing not required Central monitoring is not required (will be provided by source or target system) Impact Each interface needs to be evaluated for maintainability, operations and future proofing.

15. Integration Style Use Case Scenario Example Integration Tool / Methodology Integration Description Point to Point SAP to SAP integration (Standard IDOC ) S/4 to ERP S/4 ALE ( Application Link Enabling) Direct Communication Process Integration Messaging with Orchestration MDUS AMI Services SAP Edge Integration Cell(EIC) Custom integration using Middleware with Orchestration requirement Process Integration Messaging with Pub Sub model / Transformation / Mediation / Routing Subscribe / Publish to IBM MQ SAP Event Mesh + SAP Edge Integration Cell(EIC) Custom integration using Middleware Process Integration File transfers without transformation (Any size) and transformation (< 50 MB) SAP S/4 HANA to Globalscap SFTP SAP Edge Integration Cell(EIC) Custom integration using Middleware - can include Integration logic requirement ( Transformation / Mediation / Routing ) Process Integration SAP to Non SAP (non file based- database Read/inserts/updates) SAP S/4 HANA to Database Application SAP Edge Integration Cell(EIC) ERP Integration Patterns: OnPrem to OnPrem

16. Layer Security Protocol Purpose Authentication OAuth 2.0, SAML 2.0, Client Certificate Verifies identity of users or systems connecting to BTP Authorization XSUAA (SAP Authorization & Trust Management) Role-based access control using scopes, roles, and attributes Transport Security HTTPS (TLS 1.2/1.3) Encrypts data in transit between BTP and systems Connectivity SAP Cloud Connector, BTP Destinations, JWT Tokens Enables secure tunnel between on-premise and BTP Audit & Logging SAP BTP Audit Log Service Tracks access, changes, and system events for compliance Secure Data Exchange : Protecting business assets requires secure data sharing across integrated systems. Compliance & Trust : Robust security ensures regulatory compliance and maintains user trust. Authentication Framework : Clearly defined mechanisms will govern how systems authenticate and identify each other. SAP S/4HANA Integration : These protocols apply specifically to the SAP S/4HANA integration landscape. Security and Authentication

17. 17 SAP Cloud ALM (Application Lifecycle Management) tool will be used for Error handling Provides centralized monitoring of: Integration flows ( iFlows ) in SAP Integration Suite (CPI) Business processes (via process monitoring) Alerts & KPIs for technical failures or delays This will be used for both S4 Cloud and PCE applications Integration files will be Archived in a secure SFTP provided by PPL Error Handling and Archival

18. Interface Inventory Next Steps Deep dive and validate the Requirements in Workshop B by Functional Leads along with Business Focus needed from Functional on the "PPL Application Inventory" for the Suggested Disposition with comments "TDD" which is around 779 applications Functional Specification along with Mapping Documents for the identified Baseline Assumptions Interface Counts were based on previous experiences of similar size utility implementation. Interfaces : Count is based on interface inventory gathered during pre-ERP phase. Requirement dispositioning is performed at high-level with limited business participation across operating companies. Areas No Of Interfaces Count Finance 264 HxM 106 SCM (SCM +PS + Reporting +EHS + Cross Functional) 154

19. Appendix

20. Data Transfer & Integration Guidelines All integration should prioritize OData, followed by SOAP, then REST. IDoc should be avoided and only used as a last resort when no standard APIs are available. All standard SAP APIs (SAP API Hub) must be checked first; if enhancement is possible, extend them before considering custom APIs. File Transfer & Size Limits SAP has a 100 MB limit for payload transfer via OData. For payloads larger than 100 MB: Files should be written to a locally mounted SFTP location. Transfer via local SFTP integration (outside SAP). For transactional data with payloads < 10 KB: REST is preferred over SOAP. *Still, OData remains the first choice if available. Core ERP Modernization Philosophy Keep the central ERP system (SAP S/4HANA) as standardized as possible. Minimize core customizations. Leverage side-by-side extensions using SAP BTP or other cloud-native platforms Integration Strategy

21. API Management & External Exposure If an API is exposed externally, it must go through API Management (APIM). APIM should perform minimal transformation, primarily for: *Security *Monitoring *Traffic management API endpoints exposed externally must follow governance and security standards. Before Building Custom integration Check SAP API Hub for standard APIs. If standard API exists but lacks fields – consider API enhancement. If no standard or extensible API exists – then build custom service. Prefer OData, then REST, lastly SOAP. Do not use IDocs unless no alternative exists. For file transfer > 100 MB, use local SFTP. Event Handling Strategy For any real-time execution event, use SAP Event Mesh. For asynchronous EOIO (Exactly Once In Order) events, ensure event mesh is triggered appropriately. Integration Strategy

22. Integration Domain & patterns Describes common integration use cases or patterns that forms standard practice

23. Integration use-case patterns are grouped by integration styles and facilitate consistent solution selection Application-to-Application Integration Business-to-Business Integration Data Warehouse Integration Data Migration / Initial Load Data Quality Management Delta Data Synchronisation Employee Business Partner Customer Process Integration Data Integration User Integration L1 L2 Level Thing to Analytics Thing to Process Thing to Data Lake Thing Integration Thing to Thing API Managed Integration Event Based Integration Workflow Management Stream Analytics … Cross Use Cases Business-To-Governance Integration

24. Integration use-case patterns in the process invocation style focus on transport of transactional data Business Logic Application Business Logic Application Application-to-Application Integration Business-to-Business Integration Business-To-Governance Integration Process Invocation Exchange of transactional data between business applications within the enterprise Partner 1 Business Logic Application Partner 2 Business Logic Application Organization Business Logic Application Govenment Agency Business Logic Application Exchange of transactional data between business applications within the enterprise and external partner applications outside of the company Transform transactional data into predefined exchange formats and transfer it electronically to external legal or tax authority systems 1 2 3 L1 L2 Level 1 2 3

25. Data Warehouse Integration Data Migration / Initial Load Data Quality Management Delta Data Synchronisation Integration use-case patterns in the data movement style focus on transport of non-transactional data Data Movement 1 2 3 1 4 2 3 4 Data Application Data DB Data App / MDG Data Application Data System of Records Data Application Data Source application Data Source application Data Target application Data Source Data Source DQM Data Synchronization or distribution into other systems of created or changed data after initial load Provisioning of data from multiple data sources to a data warehouse One-time unidirectional transfer of data from multiple sources to one or more targets (initial load for application migration) Migration, initial load, synchronisation or distribution of data into several systems with the requirement of proper data validation, consolidation and cleansing L1 L2 Level Data Target application

26. Integration Domains: It is important to define the integration areas in PPL ERP landscape to identify integration domains and solutions CORE LEGACY PARTNER CLOUD USER System of Record System of Engagement Customized application for PPL ERP only legacy level to Global level All external business partners: Suppliers. Vendors. Banks . Tax Department. Applications hosted on hyperscaler User Interactions via Mobile App, Web Browser or Handheld devices Single or Continental Locations System owner- PPL ERP Constrained and incoherent connectivity System owner- PPL ERP Single or Continental Locations Integrates via B2B standards(e.g., EDI) Open standards (e.g., Rest APIs). System Owner- Partner System Owner: External Cloud Vendors iOS or Android based mobile apps System Owner: Users All B2B Partners Scope Details Examples BTP

27. BTP Integration Framework- Holistic Integrations

28. BTP Integration Framework – AI-Driven Integrations

29. BTP Integration Framework Continue..

30. Use of Integration Solution Advisory Methodology (ISA-M)

31. Use of Integration Pattern

32. Example of Technology Pattern

33. Peripheral Systems Solution – to be architecture Core Process SAP BTP (Business Technology Platform) SAP (IaaS) Non-SAP application Legend SAP Partner Product SAP (SaaS) Third Party Applications Side systems Enable Now Training Cloud Connector Integration BODS Conversion Cloud ALM Tech Monitoring FCC FleetFocus CCS ABT Quantium ARM Maximo Cascade PowerPlan Aligne Fuels DOA Volts TRAC Finance Group Reporting Environment Mgmt Treasury and Risk Mgmt. EHS Workplace Safety Cash Mgmt Access Control Adv Payment Mgmt Materials Management Document and Reporting Compliance General Ledger Account Payable S4 HANA (ERP) Finance Adv Financial Closing SAP Analysis Cloud Analytics SAP Datasphere Data Model & Integration Concur Travel & Expenses DP Agent Data Replication Webdispatcher Integration Time & Attendance Management SAP Workforce Forecasting SAP WFS SAP Absence and Leave Management SAP SFSF Recruiting SAP SFSF Onboarding Talent Management Suite SAP SFSF Learning SAP SFSF Career & Talent Development SAP SFSF Compensation SAP SuccessFactors Work Zone SAP HXM (Success) Core HR Core EC Payroll Core EC SAP WFS Talent Management Suite SAP ARIBA Contracts Supplier Lifecycle and Performance Supplier Risk Buying and Invoicing Procurement Sourcing Signavio Process Management Open Text Exstream Cloud-Native D ocument Management Billing & Rates Device Management Contract Accounting Service Orders Prepay Exception Management S4 HANA ISU (CIS) Initiator Host

34. Detailed Combined Future State Technical Architecture SAP Biz Tech Platform (integration Suite) API /Microservices Layer (Includes API Gateway) Unified IAM/User MGMT Profile MGMT *Not a comprehensive list of all integrations Token (ServiceNow Framework) Service now HR Service Delivery Case MGMT Error Handling Event Logging Employee Onboarding Observability SAP Procurement Sourcing SAP ARIBA Contracts Supplier Lifecycle and Performance Supplier Risk Buying and Invoicing Field HxGN Fleet Focus FA Suite FT SAP HXM (Success) SAP SFSF Recruiting SAP SFSF Onboarding Talent Management Suite SAP SFSF Learning SAP SFSF Career & Talent Development SAP SFSF Compensation SAP SuccessFactors Work Zone Core HR Core EC Payroll SAP Workforce Forecasting SAP Absence and Leave Management Time & Attendance Management BSI ServiceSuite Customer KY SAP CSS RI CSS PA SAP Web Layer SAP FIORI SAP UI5 Web Dispatcher S4 HANA (ERP) Finance Finance Group Reporting Environment Mgmt Treasury and Risk Mgmt. EHS Workplace Safety Cash Mgmt Access Control Adv Payment Mgmt Materials Management Document and Reporting Compliance General Ledger Account Payable Adv Financial Closing OpenGrid Maximo Cascade SAP SAC (Reporting) Forecasting Budgeting Reporting Other VS Power Plan SAP Enable Now Signavio Concur Blackline Additional Integrations UI Model (LRP) OpenText Additional SAP Integrations SAP Cloud ALM Error Handling Cloud Connector SAP SAC (Reporting) Analytics

35. Proposed Environment Strategy (Discovery) SBX Discovery phase DEV Discovery phase QA Test Phase TRN Test Phase UAT Test Phase PRD Test Phase Cloud Connector(Prod) Cloud connector (Non-Prod) Integration Suite(BTP) Integration Suite(BTP) Integration Suite(BTP) Integration Suite(BTP) Integration Suite(BTP) SAP Cloud ALM (BTP) SAP ALM(BTP) Datasphere (BTP) Datasphere (BTP) Datasphere (BTP) Datasphere (BTP) SAP Signavio webdisp webdisp webdisp webdisp BODS DP Agent DP Agent DP Agent Staging DB S4 with Fiori S4 with Fiori S4 with Fiori SAP Ariba SAP Ariba SAP Success Factors SAP SuccessFactors DP Agent webdisp webdisp DP Agent SAP Enable Now SAP Concur SAP Concur BODS Staging DB BODS Staging DB BODS Staging DB S4 with Fiori S4 with Fiori S4 with Fiori

36. Note: Not architecturally accurate as these are Illustrative Integration Patterns to be confirmed during design SAP BTP (Business Technology Platform) SAP Enable Now SAP S/4 HANA (ERP) Finance Group Reporting Environment Mgmt Treasury and Risk Mgmt. EHS Workplace Safety Cash Mgmt Access Control Adv Payment Mgmt Materials Management Document and Reporting Compliance UI Model LRP Workforce Including Field Time US Payroll Tax Calculation BSI Edge / Third-Party Applications Concur Expenses Signavio Blackline Account Reconciliation Additional Modules SAP Ariba Sourcing Procurement Open Text Vendor Invoice Mgmt. Document Storage API Gateway Connected People Growth Strategy Corporate & Gov. Affairs Shared Ops ServiceNow EHS Incident Management Health and Safety Mgmt Environment Management Management of Change SAP SAC Budgeting Forecasting Reporting MDG Master Data Governance Alight vs. BenefitFocus Benefits TRACs v. Beeline v. FieldGlass Contingent Worker Mgmt SAP IBP (Integrated Business Planning)? Planning SAP SuccessFactors Core HR Employee Payroll Recruiting Purchased from SAP already SAP (IaaS) Non-SAP application Legend SAP (SaaS) SAP (PaaS) Pending Decision Not yet Purchased High Level Technical Architecture ITSM HR Help Desk Environment Health & Safety Training & Compliance Enterprise Sustainability Mgmt Distributed Workforce Legal Regulatory Affairs Corporate Strategy

37. Governance & Change Control In Progress - Naming conventions - Change management process - Review cycles

38. Governance Security & Authentication In Progress - Naming conventions - Change management process - Review cycles

39. monitoring & Logging Error handling

40. Key Features of Monitoring and Logging in SAP Integration Suite  Monitoring & Logging 1. Centralized Monitoring: SAP Integration Suite provides a centralized monitoring dashboard that offers a comprehensive view of the health and status of your integration flows, APIs, and services   Monitoring Dashboard :  The centralized dashboard gives users a real-time overview of the status of all integration flows and related components, providing insights into message exchanges, execution results, and errors.  It allows users to monitor the performance, health, and success/failure rates of individual integration scenarios, which helps quickly identify and address any issues.  Operational Monitoring :  Operational monitoring includes monitoring for key integration components like SAP Cloud Integration (for integration flows), API Management, and SAP Event Mesh.  Metrics such as processing times , message volume , throughput , and error rates can be tracked to ensure that integrations run smoothly and meet performance expectations.  Exception Handling and Alerts :  The platform provides mechanisms to set up alerts for failed or delayed integrations. You can define alert thresholds for specific error conditions or message failures and configure automated notifications (e.g., via email, SMS, or internal systems).  Alerts help integration administrators quickly take corrective actions before the issues impact the business.  1. Message Processing Monitoring: Monitoring the processing of messages is crucial for ensuring the reliability of your integrations. SAP Integration Suite tracks each message's journey from sender to receiver, making it easier to diagnose issues.  Message Flow Monitoring :  Message Flow Monitoring allows you to track the flow of messages through various integration components, including the status of each individual message (e.g., whether it has been successfully processed, is pending, or has failed).  The system records details such as processing times , payload data , status codes , and the source/target system for each message, making it easier to track and troubleshoot issues.  Error Handling :  If a message fails during processing, the system provides detailed error logs to help identify the root cause. This could include issues like data mismatches, transformation errors, or connectivity problems.  Integration developers and operators can view detailed error reports , and messages that failed can be retried or resubmitted with corrections. 

41. Key Features of Monitoring and Logging in SAP Integration Suite Continue  3. Audit Logs: Audit logs are crucial for compliance and security, as they provide a detailed history of actions performed within the integration environment. They track user activities, changes, and critical system events.  User Activity Logs :  Audit logs capture information about who accessed the SAP Integration Suite, what actions were taken, and when they were executed. This helps monitor user activity for security and accountability purposes.  System Event Logs :  System event logs provide insights into the operational activities of the integration platform itself, such as system startups, configuration changes, or errors encountered during integration execution.  These logs are especially important for troubleshooting and ensuring that the system is functioning as expected .  Compliance Monitoring :  For industries with regulatory requirements, audit logs help maintain compliance by ensuring that all actions are tracked, and data handling practices align with industry standards.  4. Integration Flow Logs: Integration flow logs allow you to monitor the details of your integration flows, which are at the heart of the integration scenarios in SAP Integration Suite.  Flow Execution Logs :  These logs capture detailed information about the execution of each integration flow, including the status of the flow, data transformations, routing decisions, and error occurrences.  Logs also provide insights into performance, such as how long each step of the integration flow took to process, which helps optimize integration performance.  Payload Visibility :  SAP Integration Suite allows you to log the content of the message payloads , including the transformed data. This provides visibility into how the data was modified during processing, helping in debugging and ensuring the correctness of data transformations. 

42. Key Features of Monitoring and Logging in SAP Integration Suite Continue  5. API Management Monitoring: API Management is a critical component in SAP Integration Suite for managing and securing APIs. Monitoring API performance is key to ensure smooth API communication between systems.  API Analytics :  SAP API Management provides a detailed API analytics dashboard that tracks key metrics like API calls, response times, error rates, and throughput.  This data helps organizations monitor the health of their APIs and identify potential performance bottlenecks or issues affecting API consumers.  Usage and Traffic Monitoring :  You can monitor API usage, including which API endpoints are most frequently called, which users or systems are calling the APIs, and how much traffic is being processed. This helps in ensuring API reliability and scaling the system accordingly.  Security and Access Monitoring :  API Management monitoring also tracks the security of API calls, including the usage of OAuth tokens and the authentication status of API requests. Suspicious or unauthorized access attempts can be flagged for further investigation.  6. Event Mesh Monitoring: SAP Event Mesh is used to enable event-driven architectures by facilitating the exchange of events between systems. Event Mesh monitoring ensures the health and reliability of event-driven communications.  Event Flow Monitoring :  Event Mesh enables tracking of event flows between producers (senders) and consumers (receivers) in real-time. This allows for monitoring whether events are successfully published and consumed across the integration landscape.  Event Message Integrity :  The integrity and reliability of event-based communication are tracked, ensuring that messages or events are delivered in sequence and without data loss. 

43. Key Features of Monitoring and Logging in SAP Integration Suite Continue  7. Logging Capabilities and Integration with External Tools: SAP Integration Suite provides logging capabilities and integrates with external monitoring and logging tools for more advanced use cases.  External Monitoring Tools Integration :  Integration with external tools like Splunk , Dynatrace , Prometheus , or ELK Stack (Elasticsearch, Logstash, Kibana) allows you to centralize monitoring across your entire integration environment.  These integrations help unify logs, metrics, and alerts in a single pane of glass for more effective monitoring and troubleshooting.  Custom Logging Configuration :  For specific use cases, SAP Integration Suite allows the customization of logging levels (e.g., detailed, verbose, or basic logs). This flexibility helps in controlling the amount of log data captured and ensures that logs are aligned with the organization's needs.  8. Alerting and Notification: The SAP Integration Suite includes alerting and notification capabilities to proactively inform system administrators or operators about issues with integrations.  Real-Time Alerts :  The system can send real-time alerts to notify users of issues, such as failed integrations, exceeded thresholds, or system errors. Alerts can be configured to be sent via email , SMS , or integrated with external systems for automated workflows (e.g., via SAP Intelligent Robotic Process Automation (RPA) or other automation tools).  Threshold-Based Alerts :  Alerts can be configured to trigger based on performance thresholds, such as a specific response time or error rate. These proactive alerts allow administrators to quickly address performance degradation or failures before they impact end users. 

44. Key Features of Monitoring and Logging in SAP Integration Suite Continue  9. Best Practices for Monitoring and Logging in SAP Integration Suite: Set Up Proactive Alerts : Define alerts for critical thresholds, such as failed integrations or high error rates. This will allow you to react quickly to problems before they escalate.  Monitor Key Metrics : Regularly monitor key performance indicators (KPIs) like processing times, throughput, and error rates for integration flows, APIs, and event messages to ensure optimal performance.  Leverage Audit Logs : Use audit logs to maintain accountability and traceability of user actions and system events. These logs can be valuable for security auditing and compliance.  Centralize Log Management : Integrate SAP Integration Suite’s logging with external monitoring and logging systems to centralize all logs and metrics in one place for easier management and troubleshooting.  Use Message Visibility for Troubleshooting : Enable detailed message logging (including payload visibility) for troubleshooting. This can be invaluable in identifying issues in data transformations or integration flows.  Optimize Based on Insights : Use insights from performance and usage metrics to optimize your integrations. For example, if you notice high response times or API call failures, investigate the root cause and take corrective actions 

45. Error Handling Error Handling And Retry Mechanism Exception Sub-process in Main and Local Integration Process to Catch technical errors Send error responses back to the sending system Message Processing Log to store error payload as attachment to enable debugging Message data validation should be done at source application to detect the errors early Decouple Error handling logic in separate integration flow Configure Alerts using Solman. Configure the transaction as short as possible! Configure the transaction as long as needed for a consistent runtime execution! Configure only one transaction if multiple JMS components are used! Avoid mixing JDBC and JMS transactions! Retry Mechanism for Asynchronous messages Define the Retry Policy Implement Error Handling Configure Retry Settings Utilize Message Queues Retry Logic - Use exponential backoff or fixed interval retry to control the timing between retries Monitor and Alert Dead-Letter Queue Leverage Queues or Persistence Layers Retry Scheduler Implement Exponential Backoff Monitoring and Alerting

46. Interface Inventory Next Steps Deep dive and validate the Requirements in Workshop B by Functional Leads along with Business Focus needed from Functional on the "PPL Application Inventory" for the Suggested Disposition with comments "TDD" which is around 779 applications Functional Specification along with Mapping Documents for the identified Baseline Assumptions Interface Counts were based on previous experiences of similar size utility implementation. Interfaces : Count is based on interface inventory gathered during pre-ERP phase. Requirement dispositioning is performed at high-level with limited business participation across operating companies. Areas No Of Interfaces Count Finance 264 HxM 106 SCM (SCM+PS+Reporting+EHS+cross Functional) 154

47. Integration Tools & Protocol Usage preferences

48. Need to be decided approved Support Services Use case IDoc designed for SAP to SAP communication RFC designed for SAP to SAP communication SOAP typically used for transactional service request OData Typically used for  creation and consumption of REST APIs REST typically used for high data volume, real-time transfer and also for mobile devices JMS designed for high volume and transaction requests, Guaranteed delivery JDBC typically used for direct database access (if database doesn‘t support other protocols) File MFT scenarios such as encryption, tokenization and key management, large file transfer, security protocol support, routing of FTP processes scheduling of file transfer processes,NFS transfer HTTP/ HTTPS An iFlow in SAP Cloud Integration consumes a REST API from a 3rd-party system (e.g., weather data, payment gateway) Integration Protocols IDOC RFC SOAP ODATA REST FILE* JMS JDBC AMQP Integration Protocols Usage Preferences Kafka

49. Q&A Thank you

50. SAP BTP Integration Suite Cloud Integration API Management Open Connector Event Mesh Trading Partner Management Integration Advisor Edge Integration Cell Microsoft Azure Microservices Globalscape System Integration Tools

51. OnePPL  ERP Environment Sizing Environment DB Size Perpetual vs. Temporary Prod 6TB Perpetual Prod DR 6TB Perpetual QA 6TB Perpetual Dev 512GB Perpetual Sandbox 512GB Perpetual Training 512GB Perpetual Pre Prod 6TB Perpetual Additional Metrics Qty ERP: Users TBD Employee + Contractor Count

52. Change Management Program Structure : ACN Org for Next Gen Enterprise Services Greg Smith PPL Client Account Lead Andrew Lanktree Reinvention Lead Shobha Krishna Technology Service Lead Manish Sharma Americas CEO Reinvention Executive Sponsor Keith Boone Americas TS&A Lead Reinvention Executive Sponsor Scott Tinkler Global Utilities Lead Reinvention Executive Sponsor Craig Richey Americas Finance Lead ERP Executive Sponsor Chris Barrett ERP Delivery Lead Jignesh Amin Business Architect Viji Manickam SAP Platform Architect Finance Jeremy Cohen BA Finance Lead T&O Simar Akhtar Data and AI Alexandria Orlando VRO Alex Bratton EA/BA Saurabh Kumar Pratik Lakdawala Managed Service Aji Thomas Draft as of 5/5 Sadashiv Salunkhe ATC Engagement Lead Felipe Olmedo BA ATR Lead Emily Aberle Finance BA - RTR Rasmia Riwan Finance BA Nicholas Forward Finance BA Christina Nobile Finance BA Mallika Heredia Finance BA Asheesh Bhatia SAP Finance Lead Doug Palmatier Project Acct Lead Supply Chain Nathan Nickerson SCM BA Lead Rick Jones SCM SMA - MM Karin Stevens SCM SMA - PO Jasmeet Vig Supply Chain BA Brianna Coeling Supply Chain BA Gianna Joyce Supply Chain BA Daniel Dennison SAP SCM Lead Maulesh Trivedi SAP MM Lead Noelle Tadena Ariba Lead Wilbert Chew Ariba Human Experience Management Ethan Butler HXM BA Lead Lindsey Montini HXM BA Hannah Housenick HXM BA Karel Fennema SuccessFactors Lead Carla Cleland EC Payroll Lead Peter Dancs Time and Absence Jasmine Saunders EC Lead Tech Delivery Viji Manickam Interim SAP Tech Lead Monica Peran Agentic AI Lead Pankaj Kumar Integration Lead Niju Manuel SAP Consultant Change Management Ethan Butler OCM Lead Arya Bedi Finance Rachel Brackney Team Lead / SCM Amber Heard Recruiting Lead Ibrahim Kilic SF Analyst Umakanth Gannu Reporting Lead Jonathan Lieu Data Conversion Sushmita Singh Tax SMA Swetha Kavali SAC + Reporting Chris Blowars SAP Consultant Jagdish Patil ATCI Delivery Lead Kani Kumar PMO Analyst Manasvi Chavan PMO Lead Madhu Raghavan Ariba Seema Nachankar ATCI Integration Lead Chiran Buddana ATCI Data Conversion Praneeth Kothapally ATCI Dev Lead Siva Subrahmanyan SAP Platform Lead Hannah Pyenson Project Manager/VRO Iara Hilsenrat Flex Valentina Dold Flex Sridhar Volety CIS Engagement Lead

53. Change Management Program Structure : ACN Org for Next Gen Enterprise Services Greg Smith PPL Client Account Lead Andrew Lanktree Reinvention Lead Shobha Krishna Technology Service Lead Manish Sharma Americas CEO Reinvention Executive Sponsor Keith Boone Americas TS&A Lead Reinvention Executive Sponsor Scott Tinkler Global Utilities Lead Reinvention Executive Sponsor Craig Richey Americas Finance Lead ERP Executive Sponsor Chris Barrett ERP Delivery Lead Jignesh Amin Business Architect Viji Manickam SAP Platform Architect Finance Jeremy Cohen BA Finance Lead T&O Simar Akhtar Data and AI Alexandria Orlando VRO Alex Bratton EA/BA Saurabh Kumar Pratik Lakdawala Managed Service Aji Thomas Draft as of 5/5 Sadashiv Salunkhe ATC Engagement Lead Felipe Olmedo BA ATR Lead Emily Aberle Finance BA - RTR Rasmia Riwan Finance BA Nicholas Forward Finance BA Christina Nobile Finance BA Mallika Heredia Finance BA Asheesh Bhatia SAP Finance Lead Doug Palmatier Project Acct Lead Supply Chain Nathan Nickerson SCM BA Lead Rick Jones SCM SMA - MM Karin Stevens SCM SMA - PO Jasmeet Vig Supply Chain BA Brianna Coeling Supply Chain BA Gianna Joyce Supply Chain BA Daniel Dennison SAP SCM Lead Maulesh Trivedi SAP MM Lead Noelle Tadena Ariba Lead Wilbert Chew Ariba Human Experience Management Ethan Butler HXM BA Lead Lindsey Montini HXM BA Hannah Housenick HXM BA Karel Fennema SuccessFactors Lead Carla Cleland EC Payroll Lead Peter Dancs Time and Absence Jasmine Saunders EC Lead Tech Delivery Viji Manickam Interim SAP Tech Lead Monica Peran Agentic AI Lead Pankaj Kumar Integration Lead Niju Manuel SAP Consultant Change Management Ethan Butler OCM Lead Arya Bedi Finance Rachel Brackney Team Lead / SCM Amber Heard Recruiting Lead Ibrahim Kilic SF Analyst Umakanth Gannu Reporting Lead Jonathan Lieu Data Conversion Sushmita Singh Tax SMA Swetha Kavali SAC + Reporting Chris Blowars SAP Consultant Jagdish Patil ATCI Delivery Lead Kani Kumar PMO Analyst Manasvi Chavan PMO Lead Madhu Raghavan Ariba Seema Nachankar ATCI Integration Lead Chiran Buddana ATCI Data Conversion Praneeth Kothapally ATCI Dev Lead Siva Subrahmanyan SAP Platform Lead Hannah Pyenson Project Manager/VRO Iara Hilsenrat Flex Valentina Dold Flex Sridhar Volety CIS Engagement Lead

54. Integration Domains

55. It is important to define the integration areas in PPL ERPlandscape to identify integration domains and solutions CORE LEGACY PARTNER CLOUD USER System of Record System of Engagement Customized application for PPL ERP only legacy level to Global level All external business partners: Suppliers. Vendors. Banks . Tax Department. Applications hosted on hyperscaler User Interactions via Mobile App, Web Browser or Handheld devices Single or Continental Locations System owner- PPL ERP Constrained and incoherent connectivity System owner- PPL ERP Single or Continental Locations Integrates via B2B standards(e.g., EDI) Open standards (e.g., Rest APIs). System Owner- Partner System Owner: External Cloud Vendors iOS or Android based mobile apps System Owner: Users All B2B Partners Scope Details Examples BTP

56. Integration Domains Cloud Domain External applications Partner Domain S4HANA 2.0 on-premise applications Core Domain Legacy applications National applications User Domain Mobile applications Web applications Desktop applications Thing Domain Power Plan Applications applications Domain User2Cloud Cloud2Cloud Core2Cloud Core2Legacy Legacy2Legacy Core2Partner User2Core User2User Thing2Cloud Thing2Core Core2Core SAP SaaS applications Non SAP SaaS applications Legend Process and data centric integration DEFERRED Thing integration Integration domains describe typical areas in a hybrid landscape where integration is needed

57. Integration Patterns Integration domain Core2Core

58. Native integration Core domain Non SAP *S4 HANA based SAP systems Core domain Non SAP *S4 HANA -based SAP systems or or Core to Core Integration Architectural Aspects Only applicable if no re-use of transmitted information is expected Common standard functionality with vendor supported connectors Translation between different protocols not required Mapping, transformation, data enrichment, splitting or routing not required Load balancing not required Central monitoring is not required (will be provided by source or target system) Impact Each interface needs to be evaluated for maintainability, operations and future proofing.

59. SAP and non-SAP integration Architectural Aspects Translation between different protocols required Mapping, transformation, data enrichment, splitting or routing required Load balancing possible Ex:- S4 to Salesforce, Concur Cloud Integration Core domain Non SAP *SAP S4HANA based SAP systems or Core domain Non SAP *SAP S4HANA based SAP systems or Core to Core Integration

60. SAP and SAP integration (When Pre-packaged content Available) Architectural Aspects Standard content provided by SAP for seamless integration. Translation between different protocols part of the pre-packaged content Mapping, transformation, data enrichment, splitting or routing required, provided by SAP Ex: . Core domain *S4HANA -based SAP systems Cloud Integration Suite Core domain *S4HANA -based SAP systems Core to Core Integration

61. Core domain Core domain Data synchronisation without transformation (managed file transfer) Architectural Aspects Managed file transfer Translation between different protocols not possible Mapping, transformation, data enrichment, splitting or content-based routing not possible WLA: Workload Automation IFMS: Information Flow Management System Recommendation is to use a single Managed File System (MFS) Ex: Managed file transfer (MFT), Web services through REST API Non SAP Non SAP or *SAP S4HANA -based SAP systems *SAP S4HANA -based SAP systems * definition in glossary WLA / IFMS Core to Core Integration

62. Core domain Bulk* or mass* data synchronisation with transformation Architectural Aspects Bulk or mass data transfer Translation between different protocols possible Extract, Transform (incl. Cleansing), Load (ETL) Proper data cleansing ability Load balancing possible SAP Data Services (SDS) Non SAP or *SAP S4HANA -based SAP systems Core domain Non SAP or *SAP S4HANA -based SAP systems *definition in glossary Core to Core Integration

63. Core domain Core domain Real-time database synchronisation Architectural Aspects Trigger-based real-time replication (database-level only) Pool and cluster table support (SAP ABAP-based systems only) Single or mass data movement Mapping or transformation of data possible SAP Landscape Transformation Replication Server (SLT ) Non SAP Non SAP or *SAP S4HANA -based SAP systems *SAP S4HANA -based SAP systems Core to Core Integration

64. Core domain Core to Core Integration Initial load Architectural Aspects Bulk or mass data transfer Translation between different protocols possible Extract, Transform, Load Load balancing possible One-time unidirectional data transfer SAP Data Services (SDS) Non SAP Core domain Non SAP or *SAP S4 HANA -based SAP systems

65. Core domain Core to Core Integration Initial load Architectural Aspects Bulk or mass data transfer Translation between different protocols possible Extract, Transform, Load Load balancing possible One-time unidirectional data transfer SAP Data Services (SDS) Non SAP Core domain Non SAP or *SAP S4 HANA -based SAP systems

66. Communication with external partner systems Architectural Aspects Non-EDI scenarios (e.g. Rest) for external partner systems Translation between different protocols required Mapping, transformation, data enrichment or splitting will be performed with SCPI Transport layer encryption required Central API management layer provides authentication and central monitoring features Published APIs for reusability External partner system 3 rd party carriers Others Core domain Non SAP or *SAP S4 HANA -based SAP systems Bank ( Multicash ) Cloud Integration Suite Central API Management Core to Partner Integration

67. Electronic Data Interchange (EDI) with external partner systems Architectural Aspects Only relevant for EDI scenarios Translation between different protocols required EDI provider manages transfer to individual suppliers Routing to EDI provider (and vice versa) Mapping, transformation, data enrichment or splitting to expected EDI provider format (and vice versa) by EDI provider Transport layer encryption required Cloud Integration Suite External supplier system Core domain Non SAP or EDI provider * SAP S4 HANA -based SAP systems Core to Partner Integration

68. Core domain Data synchronisation without transformation (managed file transfer) Architectural Aspects Managed file transfer Translation between different protocols not possible Mapping, transformation, data enrichment, splitting or content-based routing not possible WLA: Workload Automation IFMS: Information Flow Management System Non SAP or * SAP S4 HANA -based SAP systems WLA / IFMS Core to Partner Integration External partner system 3 rd party carriers Others Bank ( Multicash )

69. Applications communication Architectural Aspects COMM Module instance (located in stores) manages service requests to SAP IS No direct connection between WMS Applications and SAP IS Communication between WMS Applications and COMM Module out of scope/ left as is Request-Response (time-critical business information) and asynchronous (fire and forget) communication is possible Translation between different protocols required Mapping, transformation, data enrichment, splitting or routing possible Near real-time possible Store domain Core domain Non SAP or * S4HANA -based SAP systems integration Suite WMS Applications Core to Legacy Integration Comm Module … Comm Module Comm Module

70. Reference integration architecture Integration domain Cloud2Cloud On Premise Application

71. Cloud domain Cloud domain Native integration Architectural Aspects Only applicable if no re-use of transmitted information is expected Common standard functionality with vendor supported connectors Translation between different protocols not required Mapping, transformation, data enrichment, splitting or routing not required Load balancing not required Transport layer encryption Synchronous request – response and asynchronous communication possible Central monitoring is not required (will be provided by source or target system) Non SAP Non SAP Cloud to Cloud Integration Impact: Each interface needs to be evaluated for maintainability, operations and future proofing .

72. 72 Integration Process(Reusable APIs with Central Governance) 72 Cloud domain Non SAP Cloud domain Non SAP Cloud Integration Suite Central API Management Architectural Aspects Central discovery of provided APIs for reusability Translation between different protocols possible Mapping, transformation, data enrichment, splitting or routing possible with SCPI Transport layer encryption Central API management layer provides authentication and central monitoring features Application with built-in API gateways should be integrated via the Central API management to support reusability and central governance. Cloud to Cloud Integration

73. Reference integration architecture Integration domain Cloud2Cloud

74. Core domain Cloud domain Native integration (SAP to SAP) Architectural Aspects Only applicable if no re-use of transmitted information is expected Common standard functionality with vendor supported connectors SAP provided standard integration components are used Mapping, transformation, data enrichment, splitting or routing not required Load balancing not required Transport layer encryption Synchronous request – response and asynchronous communication possible Central monitoring is not required (will be provided by source or target system) * SAP S4HANA -based SAP systems SAP systems Core to Cloud Integration Impact: Each interface needs to be evaluated for maintainability, operations and future proofing. Each interface needs additional Security assessment.

75. Core domain Cloud domain Native integration (Non SAP to Non SAP) 75 Architectural Aspects Only applicable if no re-use of transmitted information is expected Common standard functionality with vendor supported connectors Translation between different protocols not required Mapping, transformation, data enrichment, splitting or routing not required Load balancing not required Transport layer encryption Synchronous request – response and asynchronous communication possible Central monitoring is not required (will be provided by source or target system ) Non SAP Non SAP Core to Cloud Integration Impact: Each interface needs to be evaluated for maintainability, operations and future proofing. Each interface needs additional Security assessment.

76. Core Process integration Architectural Aspects Reuse existing Interfaces Translation between different protocols possible Mapping, transformation, data enrichment, splitting or routing possible Load balancing possible Transport layer encryption Cloud Integration Suite Non SAP or Cloud domain Non SAP Core domain Non SAP or Non SAP *SAP S4HANA -based SAP systems Core to Cloud Integration

77. Core Process Integration Architectural Aspects Translation between different protocols possible Mapping, transformation, data enrichment, splitting or routing possible Transport layer encryption Central API management layer provides authentication and central monitoring features Published APIs for reusability Non SAP or Cloud domain Core domain Non SAP or Non SAP *SAP S4HANA -based SAP systems Cloud Integration Suite Central API Management Core to Cloud Integration SAP systems

78. Cloud domain Core domain Data synchronisation without transformation (managed file transfer) Architectural Aspects Managed file transfer Translation between different protocols not possible Mapping, transformation, data enrichment, splitting or content-based routing not possible Transport layer encryption WLA: Workload Automation IFMS: Information Flow Management System Recommendation is to use a single Managed File System (MFS) Non SAP Non SAP or *SAP S4HANA -based SAP systems *definition in glossary WLA / IFMS Core to Cloud Integration

79. Cloud domain Core domain Bulk* data synchronisation with transformation Architectural Aspects Bulk or mass data transfer Translation between different protocols possible Extract, Transform (incl. Cleansing), Load (ETL) Load balancing possible Transport layer encryption Proper data cleansing ability Non SAP Non SAP or *SAP S4HANA -based SAP systems SAP Data Services (SDS) Core to Cloud Integration

80. Reference integration architecture Integration domain User2Cloud

81. Cloud domain Browser based consumption – Vendor Web Portal available Architectural Aspects SAP Cloud Platform Portal used as the landing page SAP Cloud Platform provides authentication services and Single Sign On Capabilities to the vendor specific web interface Applications from the Cloud Domain will be accessed using the Web-Interface delivered by the specific vendor All new implementations or custom implementations must follow the Fiori UX principle and where it is possible use Fiori UI framework All application should be implemented with a mobile first approach Supported Protocols and Browser User to Cloud Integration SAP or non SAP SAP Cloud Platform Portal Vendor specific web interface Authentication SAML OAuth Services OData REST SOAP Web Browsers IE 11+ Google Chrome Firefox Safari HTTP/S Supplier via Web Browser see supported protocols

82. Browser based consumption –Vendor Web Portal not available Architectural Aspects SAP Cloud Platform Portal used as landing page for external collaboration SAP Cloud Platform provides authentication services and Single Sign On Capabilities to the apps Fiori apps will be implemented within Cloud Platform OData Provisioning (Fiori Cloud) when external access is needed All new implementations or custom implementations must follow the Fiori UX principle and where is possible use Fiori UI framework All application should be implemented with a mobile first approach Central API management layer provides authentication and central monitoring features Managed APIs to be published via SAP Business Hub Enterprise for reusability Supported Protocols and Browser User to Cloud Integration *definition in glossary SAP Cloud Platform Portal HTTP/S Supplier via Web Browser API //Custom development Authentication SAML OAuth Services OData REST SOAP Web Browsers IE 11+ Google Chrome Firefox Safari Cloud domain SAP or non SAP Vendor specific web interface SAP API Management

83. Cloud domain Browser-based consumption Architectural Aspects Business logic not required Integration with existing systems based on the Application to Application (Process Invocation) and Delta Data Synch (Data Movement) Mapping, transformation, data enrichment, splitting or routing not required Load balancing required Transport layer encryption Central monitoring provided by external system Cashing required Supported Protocols and Web Browsers User to Cloud Integration Non SAP *definition in glossary Customer Protocol HTTPS HTTP Web Browsers IE 11+ Google Chrome Firefox Safari Vendor specific web interface

84. 84 Cloud domain Headless browser-based consumption including server-side rendering on first request Architectural Aspects Business logic not required Mapping, transformation, data enrichment, splitting or routing not required Load balancing included in Public API Transport layer encryption (HTTPS) Central monitoring included in Public API Caching in browser possible, but not required Supported Protocols and Web Browsers User to Cloud Integration Non SAP *definition in glossary Customer Protocol HTTPS HTTP Web Browsers IE 11+ Google Chrome Firefox Safari Public available HTTP API Public API Customer driven calls website Non SAP Public available website

85. Cloud domain Headless mobile consumption Architectural Aspects Business logic not required Mapping, transformation, data enrichment, splitting or routing not required Load balancing included in Public API Transport layer encryption (HTTPS) Central monitoring included in Public API Caching on mobile device possible, but not required Supports Native and Hybrid mobile applications User to Cloud Integration Non SAP *definition in glossary Public available HTTP API Public API Customer driven calls website Non SAP Public available website Customer Supported Devices Supported Mobile devices iOS Android Windows 10

86. Reference integration architecture Integration domain User2Core

87. User domain Browser based consumption Architectural Aspects SAP Fiori Launchpad used as single point of entry Services will be implemented in the SAP Gateway Transport layer encryption All new implementations or custom implementations must follow the fiori UX principle and where is possible use Fiori UI framework All application should be implemented with a mobile first approach Supported Protocols and Web Browser User to core access *definition in glossary Core domain *SAP S4HANA -based SAP systems SAP Front end server Fiori Launchpad Services OData REST SOAP Web Browsers IE 11+ Google Chrome Firefox Safari Employee Browser

88. User domain Mobile consumption Architectural Aspects Business logic implemented into the Mobile Application middleware (MAM) Integration with existing systems based on the Application to Application process invocation Decoupling of the mobile service provider from the internal middleware Possibility to have the MAM running in the cloud to increase elaticity Supports APIs based Hybrid mobile applications Device based authetication and secure data on device Offline cababilites and native device functionality support Supported Devices User to core access Employee Core domain Non SAP or *SAP S4HANA -based SAP systems Supported Mobile devices iOS Android Windows 10 SAP Front end server Fiori Launchpad

89. Browser based consumption –Vendor Web Portal not available Architectural Aspects SAP Cloud Platform Portal used as landing page for external collaboration SAP Cloud Platform provides authentication service and Single Sign On Capabilities to the apps Fiori apps will be implemented within Cloud Platform OData Provisioning (Fiori Cloud) when external access is needed All new implementations or custom implementations must follow the Fiori UX principle and where is possible use Fiori UI framework All application should be implemented with a mobile first approach Managed APIs for custom development via central API management Supported Protocols and Browser User to core Core domain SAP Cloud Platform Portal HTTP/S Supplier via Web Browser HTTP/S API //Custom development Authentication SAML OAuth Services OData REST SOAP Web Browsers IE 11+ Google Chrome Firefox Safari Non SAP *SAP S4HANA -based SAP systems Cloud Integration Suite SAP API Management

90. Mobile consumption Architectural Aspects Business logic implemented into the Mobile Application BackEnd (MABE) Integration with existing systems based on the Application to Application Process Invocation (see previous slides) Load balancing possible Caching possible Decoupling of the mobile service provider from the internal middleware Supports Native and Hybrid mobile applications Supported Devices User to core access *definition in glossary Customer Core domain Non SAP or *SAP S4HANA -based SAP systems Supported Mobile devices iOS Android Mobile App Back End

91. User domain Desktop consumption Architectural Aspects Native integration leveraging vendor specific desktop applications Applications used AS IS e.g. SAP Business Client (NWBC) or SAP GUI Supported Operating Systems User to core access *definition in glossary OS Windows 10 macOS Linux Vendor specific desktop client Employee Core domain Non SAP *SAP S4HANA -based SAP systems or

92. Need to be decided approved Integration Protocols Usage Preference Support Services Use case IDoc designed for SAP to SAP communication RFC designed for SAP to SAP communication SOAP typically used for transactional service request OData Typically used for  creation and consumption of REST APIs REST typically used for high data volume, real-time transfer and also for mobile devices JMS designed for high volume and transaction requests, Guaranteed delivery JDBC typically used for direct database access (if database doesn‘t support other protocols) File MFT scenarios such as encryption, tokenization and key management, large file transfer, security protocol support, routing of FTP processes scheduling of file transfer processes,NFS transfer Integration Protocols IDOC RFC SOAP ODATA REST FILE* JMS JDBC * Approved File to File via Managed File Transfer AMQP

93. API-first is a software design approach that centers on the API as the means of interacting with services and data. It treats APIs as first-class citizens, making APIs more reusable and adaptable, and enabling organizations to move faster and innovate more rapidly. API-First, API-as-a-Product API-as-a-Product describes a paradigm in which the API is not only the method of delivery – it is the primary product of value being delivered , based on an open business model mindset An API product is not an API specification or service, but a deployable package including code, security/regulatory policies, access model, API documentation and SLAs API API Application Data

94. Pankaj Input Agenda Who is Who Guiding Principle- Diagram -Clean core, API diriven , Integration Advisor, Event Meshing,Modular Patterns : - cloud to cloud, cloud to on premise, cloud to partner etc.. 5.Use of AI- Flow step recommendation, Recommendation for Interface Mapping . Doscovery Center Use (cloud.sap.com) CTMS- Transport Management .Security Input

95. Integration Architecture Design and Principles Web / others (non-SAP) SAP Service Cloud Azure API Gateway LWC S/4 HANA ADMS Service cloud workloads are mostly supported through SAP BTP, with custom flows as needed Some service cloud workloads can be served from non-BTP Non-service cloud workloads going through the common API gateway Exceptions can exist within the environment, but must be tracked / planned / intentional SAP/ALM Central observability e.g., Dynatrace SAP integration platform (BTP) Log traffic Initial subset of guiding principles which will inform the implementation of Integration Architecture CoE API as a product, API first. A Central API Gateway will act as a single point of entry for managing, routing, and securing requests throughout PPL’s landscape Domains own their integrations, applications own business and transformation logic Dumb pipes, smart endpoints. Use standard APIs and message queues, embed intelligence in the application or services Reporting and Observability are baked into integration development Common patterns will be available, which should be used by Domain / API owners Focus on remediation and reduction of tech debt during transitionary phase CCaaS Underneath the common gateway, it is a case-by-case choice to build a LWC container for: Legacy systems not supporting standard API integration, And/or for scope enforcements, And/or to extend/orchestrate API interfaces NOT EXHAUSTIVE

96. Sources that can help to provide and use the full potential of ISA-M Blog : https://blogs.sap.com/2019/02/24/integration-solution-advisory-methodology-isa-m-define-integration-guidelines-for-your-organization/ Videos: https://www.youtube.com/watch?v=ViH3eQXAjCo&t=3s Open SAP : https://open.sap.com/courses/int2 Integration Assessment : https://blogs.sap.com/2020/05/14/new-version-of-the-sap-integration-solution-advisory-methodology-template-released/

97. Integration Architecture Guiding Principles Initial subset of guiding principles which will inform the implementation of Integration Architecture CoE API as a product, API first. A Central API Gateway will act as a single point of entry for managing, routing, and securing requests throughout PPL’s landscape. Domains own their integrations, applications own business and transformation logic. Dumb pipes, smart endpoints. Use standard APIs and message queues, embed intelligence in the application or services. Reporting and Observability are baked into integration development Service cloud workloads are mostly supported through SAP BTP, with custom flows as needed Some service cloud workloads can be served from non-BTP Non-service cloud workloads going through the common API gateway Log traffic Underneath the common gateway, it is a case by case choice to build a LWC container, direct to source, or re-use BTP custom iFlows LWC Clarity

98. Cross use case pattern complements the existing integration styles and patterns API Managed Integration Event Based Integration Workflow Management Stream Analytics … Cross Use Cases Example: Expose APIs to business partners. Managed APIs leverage API traffic management policies, API security policies and API Analytics. API-Managed Integration Provisioning of omni-channel and secure access to business applications by managed APIs . Application Layer API Management API Consumption Layer … … Application Application Managed API Managed API …