ERP PPL Integration with Agentic AI Hello

Integrati
on
Strategy
Integratio
n strategy
June 2025
Prepared By
Seema Nachankar
Pankaj KumaR

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

Copyright © 2024 Accenture. All rights reserved. 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
• Outlines 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.

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)

© PPL CORPORATION
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

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).

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

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
Integratio
n Suite
Central API Management
Integration Patterns: Core to Cloud
Integration
SAP systems

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

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

Integration
Style
Use Case
Scenario
Example Integration
Tool /
Methodology
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 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
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
Integration Process(Reusable APIs with Central Governance)
Cloud domain
Non SAP
Cloud domain
Non SAP
Cloud
Integratio
n Suite
 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

Integration
Style
Use Case
Scenario
Example Integration
Tool /
Methodology
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
Experian
Microsoft Azure
Microservice
API based exchange - Integration logic
requirement ( Transformation / Mediation /
Routing )
Integration Patterns: Cloud to Cloud

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
• 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.

Integration
Style
Use Case
Scenario
Example Integration
Tool /
Methodology
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
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

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
1.Secure Data Exchange: Protecting business assets requires secure data sharing across integrated systems.
2.Compliance & Trust: Robust security ensures regulatory compliance and maintains user trust.
3.Authentication Framework: Clearly defined mechanisms will govern how systems authenticate and identify each other.
4.SAP S/4HANA Integration: These protocols apply specifically to the SAP S/4HANA integration landscape.
Security and Authentication

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

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

APPENDIX

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

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

INTEGRATION DOMAIN & PATTERNS
DESCRIBES COMMON INTEGRATION USE CASES OR
PATTERNS THAT FORMS STANDARD PRACTICE

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

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

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
L
1
L2
Level
Data
Target
application

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

BTP Integration Framework- Holistic Integrations

BTP Integration Framework – AI-Driven Integrations

BTP Integration Framework Continue..

Use of Integration Solution Advisory Methodology (ISA-M)

Use of Integration Pattern

Example of Technology Pattern

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
Environment
Mgmt
Treasury and
Risk Mgmt.
Cash Mgmt
Access Control
Adv Payment
Mgmt
Materials
Management
Document and
Reporting
Compliance
General Ledger
Account Payable
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
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
Performance
Supplier Risk
Procurement
Sourcing
Signavio
Process
Management
Open Text Exstream Cloud-Native
Document Management
Billing & Rates
Device Management
Contract Accounting
Service Orders
Prepay
Exception Management
S4 HANA ISU (CIS)
Initiator Host

© PPL CORPORATION
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
Performance
Supplier Risk
Field
HxGN Fleet Focus FA
Suite FT
SAP HXM (Success)
SAP SFSF Recruiting
SAP SFSF Onboarding
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
Environment
Mgmt
Treasury and
Risk Mgmt.
Cash Mgmt
Access Control
Adv Payment
Mgmt
Materials Management
Document and
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

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
SAP
BTP
(Business
Technology
Platform)
SAP Enable Now
SAP S/4 HANA (ERP)
Environment Mgmt
Treasury and Risk Mgmt. EHS Workplace Safety
Cash Mgmt
Access Control
Adv Payment Mgmt Materials Management
Document and
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

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

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

MONITORING & LOGGING
ERROR HANDLING

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:
o 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.
o 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:
o Operational monitoring includes
monitoring for key integration
components like SAP Cloud Integration
(for integration flows), API Management,
and SAP Event Mesh.
o 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:
o 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).
o 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:
o 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).
o 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:
o 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.
o Integration developers and operators can view detailed error
reports, and messages that failed can be retried or resubmitted
with corrections.

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:
o 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:
o 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.
o These logs are especially important for troubleshooting and
ensuring that the system is functioning as expected.
 Compliance Monitoring:
o 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:
o 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.
o 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:
o 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.

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:
o SAP API Management provides a detailed API
analytics dashboard that tracks key metrics
like API calls, response times, error rates, and
throughput.
o This data helps organizations monitor the
health of their APIs and identify potential
performance bottlenecks or issues affecting
API consumers.
 Usage and Traffic Monitoring:
o 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:
o 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:
o 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:
o The integrity and reliability of event-based communication are tracked,
ensuring that messages or events are delivered in sequence and without data
loss.

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:
o Integration with external tools like Splunk, Dynatrace, Prometheus, or ELK
Stack (Elasticsearch, Logstash, Kibana) allows you to centralize monitoring
across your entire integration environment.
o These integrations help unify logs, metrics, and alerts in a single pane of
glass for more effective monitoring and troubleshooting.
 Custom Logging Configuration:
o 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:
o 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.

9. Best Practices for Monitoring and Logging in SAP Integration Suite:
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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

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

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

INTEGRATION TOOLS & PROTOCOL
USAGE PREFERENCES

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

 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

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

© PPL CORPORATION
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
Scott Tinkler
Global Utilities Lead
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
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

INTEGRATION PATTERNS
Integration
domain
Core2Core

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
• Only applicable if no re-use of transmitted information is
expected
• Common standard functionality with vendor supported
connectors
routing 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.

SAP and non-SAP integration
• Translation between different protocols
required
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

SAP and SAP integration (When Pre-packaged
content Available)
• Standard content provided by SAP for
seamless integration.
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
Core to Core
Integration

Core domain
Core domain
Data synchronisation without transformation (managed file
transfer)
• Managed file transfer
• Translation between different protocols not possible
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
*definition in
glossary
WLA / IFMS
Core to Core Integration

Core domain
Bulk* or mass* data synchronisation with transformation
• Bulk or mass data transfer
possible
• Extract, Transform (incl. Cleansing), Load
(ETL)
• Proper data cleansing ability
SAP Data Services
(SDS)
Non SAP
or
Core domain
Non SAP
or
*definition in
glossary
Core to Core
Integration

Core domain
Core domain
Real-time database synchronisation
• 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
Core to Core
Integration

Core domain
Initial load
possible
• Extract, Transform, Load
• One-time unidirectional data transfer
SAP Data Services
(SDS)
Non SAP
Core domain
Non SAP
or
*SAP S4 HANA -based SAP systems

Core domain
Initial load
possible
• Extract, Transform, Load
• One-time unidirectional data transfer
SAP Data Services
(SDS)
Non SAP
Core domain
Non SAP
or

Communication with external partner systems
• Non-EDI scenarios (e.g. Rest) for external
partner systems
required
• Mapping, transformation, data enrichment or
splitting will be performed with SCPI
• Transport layer encryption required
features
External
partner system
• 3rd
party carriers
• Others
Core domain
Non SAP
or
Bank
(Multicash)
Cloud
Integrati
on Suite
Core to Partner Integration

Electronic Data Interchange (EDI) with external partner systems
• Only relevant for EDI scenarios
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

Core domain
Data synchronisation without transformation (managed file
transfer)
not possible
enrichment, splitting or content-based
routing not possible
• IFMS: Information Flow Management
System
Non SAP
or
WLA / IFMS
External
partner system
• 3rd
party carriers
• Others
Bank
(Multicash)

Applications communication
• COMM Module instance (located in stores) manages service
requests to SAP IS
• No direct connection between WMS Applications and SAP IS
o 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
routing possible
• Near real-time possible
Store domain
Core domain
Non SAP
or
integratio
n
Suite
WMS Applications
Core to Legacy Integration
Comm
Modul
e
…
Comm
Modul
e
Comm
Modul
e

Reference integration architecture
Integration domain
Cloud2Cloud On Premise
Application

Cloud domain
Cloud domain
Native integration
• Only applicable if no re-use of transmitted information is expected
• Common standard functionality with vendor supported connectors
• Mapping, transformation, data enrichment, splitting or routing not requir
• Synchronous request – response and asynchronous communication possi
• Central monitoring is not required (will be provided by source or target sy
Non SAP
Non SAP
Cloud to Cloud Integration
Impact:
• Each interface needs to be evaluated for
maintainability, operations and future

72
Integration Process(Reusable APIs with Central Governance)
72
Cloud domain
Non SAP
Cloud domain
Non SAP
Cloud
Integratio
n Suite
 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
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

Integration domain
Cloud2Cloud

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

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

Core
Process integration
• Reuse existing Interfaces
possible
enrichment, splitting or routing possible
Cloud
Integration
Suite
Non SAP
or
Cloud domain
Non SAP
Core domain
Non SAP
or
Non SAP

Core
Process Integration
splitting or routing possible
authentication and central monitoring features
• Published APIs for reusability
Non SAP
or
Cloud domain
Core domain
Non SAP
or
Non SAP
Cloud
Integratio
n Suite
SAP systems

Cloud domain
Core domain
Data synchronisation without transformation (managed file transfer)
• Translation between different protocols not possible
• Mapping, transformation, data enrichment, splitting or content-
based routing not possible
• IFMS: Information Flow Management System
• Recommendation is to use a single Managed File System (MFS)
Non SAP
Non SAP
or
*definition in
glossary
WLA / IFMS
CORE TO CLOUD INTEGRATION

Cloud domain
Core domain
Bulk* data synchronisation with transformation
• Extract, Transform (incl. Cleansing), Load (ETL)
• Proper data cleansing ability
Non SAP
Non SAP
or
SAP Data Services
(SDS)

Integration
domain
User2Cloud

Cloud domain
Browser based consumption – Vendor Web Portal available
• 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
Authenticatio
n
SAML OAuth
Services OData REST SOAP
Web
Browsers
IE 11+
Google
Chrome
Firefox Safari
HTTP/S
Supplier via
Web
Browser
see supported
protocols

Browser based consumption –Vendor Web Portal not available
• 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
*definition in
glossary
HTTP/S
Supplier via
Web
Browser
API //Custom
development
Authenticatio
n
SAML OAuth
Web
Browsers
IE 11+ Google
Chrome
Firefox Safari
Cloud domain
SAP or non SAP
SAP API Management

Cloud domain
Browser-based consumption
• Business logic not required
• Integration with existing systems based on the Application to
Application (Process Invocation) and Delta Data Synch (Data
Movement)
required
• Load balancing required
• Central monitoring provided by external system
• Cashing required
Supported Protocols and Web Browsers
Non SAP
*definition in
glossary
Custome
r
Protocol HTTPS HTTP
Web
Browsers
IE 11+
Google
Chrome
Firefox Safari

84
Cloud domain
Headless browser-based consumption including server-side rendering on first request
• 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

Cloud domain
Headless mobile consumption
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
Non SAP
*definition in
glossary
Public available
HTTP API
Public
API
Customer
driven calls
website
Non SAP
Public available
website
Custome
r
Supported Devices
Supported
Mobile
devices
iOS Android Windows 10

Integration
domain
User2Core

User domain
Browser based consumption
• SAP Fiori Launchpad used as single point of entry
• Services will be implemented in the SAP Gateway
• 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 Front end
server
Fiori Launchpad
Web
Browsers
IE 11+
Google
Chrome
Firefox Safari
Employee
Browser

User domain
Mobile consumption
• 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
Employe
e
Core domain
Non SAP
or
Supporte
d Mobile
devices
iOS Android
Windows
10
SAP Front end
server
Fiori Launchpad

Browser based consumption –Vendor Web Portal not available
• 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
User to core
Core domain
HTTP/S
Supplier via
Web Browser
HTTP/S
API //Custom development
Authenticatio
n
SAML OAuth
Web
Browsers
IE 11+
Google
Chrome
Firefox Safari
Non SAP
Cloud
Integration
Suite
SAP API Management

Mobile consumption
• Business logic implemented into the Mobile Application BackEnd
(MABE)
• Integration with existing systems based on the Application to
Application Process Invocation (see previous slides)
• 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
Custome
r
Core domain
Non SAP
or
Supported
Mobile
devices
iOS Android
Mobile App Back End

User domain
Desktop consumption
• 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
Employe
e
Core domain
Non SAP
or

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

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
Data

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

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

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-int
egration-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-meth
odology-template-released/

Integration Architecture Guiding Principles
Initial subset of guiding principles which will inform the implementation of Integration Architecture CoE
1. API as a product, API first.
2. A Central API Gateway will act as a
single point of entry for managing,
routing, and securing requests
throughout PPL’s landscape.
3. Domains own their integrations,
applications own business and
transformation logic.
4. Dumb pipes, smart endpoints. Use
standard APIs and message queues,
embed intelligence in the application
or services.
5. 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

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
…

ERP PPL Integration with Agentic AI Hello

More Related Content

Similar to ERP PPL Integration with Agentic AI Hello

Recently uploaded

ERP PPL Integration with Agentic AI Hello

Editor's Notes