Reimagining flow decisions in Integration Suite
For the longest time, SAP’s integration platforms — from SAP PI/PO to Integration Suite — have empowered developers to model decisions in integration flows (Iflows) using deterministic, rule-based logic. These decisions often control how an Iflow behaves: which mapping logic to apply, which receiver system to call, or which transformation branch to follow.
The common approaches include:
Static routing via Routers based on payload elements or fieldsDynamic configurations, such as externalized parameters passed at runtimeLookups to external systems (e.g., JDBC or SOAP) to evaluate conditions at runtime — achieved in Integration Suite via patterns like Request-Reply or Content Enricher
These mechanisms work — but they come with growing challenges:
Rules get combinatorially complex with more conditionsLookup tables become burdensome to maintainDecisions become rigid and hard to evolve over time
What if Iflows could use a machine learning model trained on past outcomes to make decisions — not through rigid logic, but through inferred patterns?
BTP AI Services: Letting Iflows Tap into ML-Driven Decisioning
SAP’s BTP AI services offer a comprehensive suite of capabilities for embedding intelligence across applications, extensions, and integrations.
Key components include:
Data Attribute Recommendation (DAR) – a low-code ML service for classification & regression problemsAI Core – for custom ML model lifecycle managementAI Launchpad – for model deployment and lifecycle governanceDocument Information Extraction (DOX) – for intelligent document processingPersonalized recommendations – to deliver tailored content and product suggestions to usersTranslation Hub – enables you to efficiently translate content into multiple languages
Among these, DAR is particularly compelling for Iflow-based routing logic. It allows developers to train a classification model — and call it at runtime — without deep ML or data science expertise.
A Concrete Example: Intelligent Sales Order fulfilment routing
Let us walk through a realistic sales order routing scenario — where SAP Integration Suite collaborates with BTP’s Data Attribute Recommendation (DAR) to make machine learning-driven decisions, rather than relying on static rules or lookup tables.
Business Scenario: When a new Sales Order (SO) is received in SAP S/4HANA, an Iflow must determine the appropriate fulfilment path — such as:
Domestic delivery teamExport logistics providerSpecialized handling team (e.g., for hazardous or fragile goods)
Traditionally, this might involve:
Hardcoded logic like:
IF LAND1 = ‘DE’ AND MATKL = ‘X’ THEN ROUTE = ‘Domestic’Maintaining large lookup tablesDatabase queries that are difficult to scale or evolve
But this approach quickly becomes brittle as the business grows — especially with:
New customer segmentsEmerging market combinationsExpanding SKU diversityFrequent business exceptions
ML-Driven Approach with DAR
Instead of rule-based routing, we use DAR to learn from historical sales orders:
What fulfillment team handled similar orders in the past?What patterns exist in routing decisions based on order attributes?
This lets the Iflow become intelligent — delegating routing logic to an ML model trained on past behaviour.
Step-by-Step Flow: From Sales Order to fulfilment
1. Incoming Sales Order Fields (Features)
The Iflow extracts relevant attributes from the sales order.
Field
Description
VKORG
Sales organization
VTWEG
Distribution channel
SPART
Division
KUNNR
Customer number
LAND1
Country of destination
MATNR
Material number
MATKL
Material group
AUART
Sales document type (e.g., OR, RE)
NETWR
Net value of the order
WAERK
Currency
2. Label to Predict
The ML model (via DAR) predicts the fulfillment team:
Label
Meaning
DOMESTIC
Domestic delivery team
EXPORT
Export logistics team
SPECIAL_PRODUCTS
Specialized handling (e.g., fragile items)
ESCALATE
Manual assignment required (e.g., exception)
3. Runtime Intelligence in the Iflow
Iflow receives the incoming Sales Order from SAP S/4HANAIt extracts key features (as above)Sends them via API to DARDAR returns a prediction (e.g., EXPORT)Iflow routes the order to the correct 3PL provider or internal teamDecision and outcome are logged for traceability
4. Training the Model: From Logs to Intelligence
To train DAR:
Historical sales orders are extracted from SAP S/4HANAActual fulfilment team assignments (from workflow logs or processing systems) are used as ground truthA dataset is formed with order features (inputs) and assigned team (label)No need for manual feature engineering — DAR handles sampling, validation, and training automatically
5. Closing the Loop: Human-in-the-Loop & Retraining
To ensure explainability and continuous learning:
All DAR predictions + actual outcomes are logged in HANA CloudA CAP application provides a UI for humans to review and validate predictionsOnly validated cases are used for periodic retraining, ensuring the model evolves with the business
FAQs – Key Questions and Considerations
1. When does this truly add value?
When routing errors or sub-optimal routing could lead to real business impact — e.g., SLA violations, shipment delays, customer churn — not just minor inconvenience. Conversely, when ML helps route to the most suitable receiver — say Team B instead of A — it can improve fulfillment speed, reduce costs, or ensure better customer handling, translating into real business advantage.
2. How complex is adopting DAR in terms of learning curve?
DAR is low-code and API-driven plug and play service — you don’t need to tune algorithms or handle model lifecycle related heavy lifting. Even integration developers can use it by defining schemas and calling APIs for training, deploying, inferencing and re-training.
3. Why is model re-training important?
Because business context evolves. As your product mix, customer base, or regional distribution changes, the patterns shift (called data drift or concept drift). Retraining ensures your model stays accurate and doesn’t stale out.
4. Isn’t GenAI the next big thing? Does ML still matter?
Absolutely. GenAI excels at natural language tasks — like document generation or summarization. But for structured data decisions like classification or regression, ML models like DAR are more reliable, interpretable, and consistent. They are trained on enterprise-labeled history, not general-purpose text.
5. Isn’t this just another API call, which we do all the time to enrich our payload?
Technically yes — but functionally, it’s transformational. It lets you embed intelligence directly into your Iflow’s runtime logic. It’s not just wiring systems — it’s wiring business decisions.
6. Isn’t putting ML in middleware against “separation of concerns”, particularly when it is supposed to act as a pass-through layer?
No. The ML model and its lifecycle are maintained outside Integration Suite (e.g., in DAR or AI Core). The Iflow just consumes the result — maintaining clean separation but gaining powerful synergy.
Final Thoughts
Infusing AI into Integration Suite isn’t about over-engineering — it’s about elevating Integration Suite’s behaviour from rule-based mechanics to context-aware intelligence. With BTP AI services like DAR, integration developers can go beyond static routing and hardcoded decisions. They can orchestrate intelligent flows that learn from business history — and adapt as the world changes. As integration professionals, we’re not just moving data. We’re moving contextual, intelligent decisions.
Here are some essential links for you to get started and apply AI in meeting your business requirements:
Explore SAP Data Attribute Recommendation service
SAP Tutorials: Implement your ML service
This blog focused solely on intelligent routing within iFlows. But the potential of infusing AI into Integration Suite goes far beyond — limited only by the developer’s creativity. With the upcoming AI Adapter (planned for Q3), things are bound to get even more exciting.
“Stay hungry, stay foolish.” — Steve Jobs
Perhaps that same spirit can guide us as we collectively navigate the future of intelligent integration.
Reimagining flow decisions in Integration SuiteFor the longest time, SAP’s integration platforms — from SAP PI/PO to Integration Suite — have empowered developers to model decisions in integration flows (Iflows) using deterministic, rule-based logic. These decisions often control how an Iflow behaves: which mapping logic to apply, which receiver system to call, or which transformation branch to follow.The common approaches include:Static routing via Routers based on payload elements or fieldsDynamic configurations, such as externalized parameters passed at runtimeLookups to external systems (e.g., JDBC or SOAP) to evaluate conditions at runtime — achieved in Integration Suite via patterns like Request-Reply or Content EnricherThese mechanisms work — but they come with growing challenges:Rules get combinatorially complex with more conditionsLookup tables become burdensome to maintainDecisions become rigid and hard to evolve over timeWhat if Iflows could use a machine learning model trained on past outcomes to make decisions — not through rigid logic, but through inferred patterns?BTP AI Services: Letting Iflows Tap into ML-Driven DecisioningSAP’s BTP AI services offer a comprehensive suite of capabilities for embedding intelligence across applications, extensions, and integrations.Key components include:Data Attribute Recommendation (DAR) – a low-code ML service for classification & regression problemsAI Core – for custom ML model lifecycle managementAI Launchpad – for model deployment and lifecycle governanceDocument Information Extraction (DOX) – for intelligent document processingPersonalized recommendations – to deliver tailored content and product suggestions to usersTranslation Hub – enables you to efficiently translate content into multiple languagesAmong these, DAR is particularly compelling for Iflow-based routing logic. It allows developers to train a classification model — and call it at runtime — without deep ML or data science expertise.A Concrete Example: Intelligent Sales Order fulfilment routingLet us walk through a realistic sales order routing scenario — where SAP Integration Suite collaborates with BTP’s Data Attribute Recommendation (DAR) to make machine learning-driven decisions, rather than relying on static rules or lookup tables.Business Scenario: When a new Sales Order (SO) is received in SAP S/4HANA, an Iflow must determine the appropriate fulfilment path — such as:Domestic delivery teamExport logistics providerSpecialized handling team (e.g., for hazardous or fragile goods)Traditionally, this might involve:Hardcoded logic like:IF LAND1 = ‘DE’ AND MATKL = ‘X’ THEN ROUTE = ‘Domestic’Maintaining large lookup tablesDatabase queries that are difficult to scale or evolveBut this approach quickly becomes brittle as the business grows — especially with:New customer segmentsEmerging market combinationsExpanding SKU diversityFrequent business exceptionsML-Driven Approach with DARInstead of rule-based routing, we use DAR to learn from historical sales orders:What fulfillment team handled similar orders in the past?What patterns exist in routing decisions based on order attributes?This lets the Iflow become intelligent — delegating routing logic to an ML model trained on past behaviour. Step-by-Step Flow: From Sales Order to fulfilment1. Incoming Sales Order Fields (Features)The Iflow extracts relevant attributes from the sales order.FieldDescriptionVKORGSales organizationVTWEGDistribution channelSPARTDivisionKUNNRCustomer numberLAND1Country of destinationMATNRMaterial numberMATKLMaterial groupAUARTSales document type (e.g., OR, RE)NETWRNet value of the orderWAERKCurrency2. Label to PredictThe ML model (via DAR) predicts the fulfillment team:LabelMeaningDOMESTICDomestic delivery teamEXPORTExport logistics teamSPECIAL_PRODUCTSSpecialized handling (e.g., fragile items)ESCALATEManual assignment required (e.g., exception)3. Runtime Intelligence in the IflowIflow receives the incoming Sales Order from SAP S/4HANAIt extracts key features (as above)Sends them via API to DARDAR returns a prediction (e.g., EXPORT)Iflow routes the order to the correct 3PL provider or internal teamDecision and outcome are logged for traceability4. Training the Model: From Logs to IntelligenceTo train DAR:Historical sales orders are extracted from SAP S/4HANAActual fulfilment team assignments (from workflow logs or processing systems) are used as ground truthA dataset is formed with order features (inputs) and assigned team (label)No need for manual feature engineering — DAR handles sampling, validation, and training automatically5. Closing the Loop: Human-in-the-Loop & RetrainingTo ensure explainability and continuous learning:All DAR predictions + actual outcomes are logged in HANA CloudA CAP application provides a UI for humans to review and validate predictionsOnly validated cases are used for periodic retraining, ensuring the model evolves with the businessFAQs – Key Questions and Considerations1. When does this truly add value?When routing errors or sub-optimal routing could lead to real business impact — e.g., SLA violations, shipment delays, customer churn — not just minor inconvenience. Conversely, when ML helps route to the most suitable receiver — say Team B instead of A — it can improve fulfillment speed, reduce costs, or ensure better customer handling, translating into real business advantage.2. How complex is adopting DAR in terms of learning curve?DAR is low-code and API-driven plug and play service — you don’t need to tune algorithms or handle model lifecycle related heavy lifting. Even integration developers can use it by defining schemas and calling APIs for training, deploying, inferencing and re-training.3. Why is model re-training important?Because business context evolves. As your product mix, customer base, or regional distribution changes, the patterns shift (called data drift or concept drift). Retraining ensures your model stays accurate and doesn’t stale out.4. Isn’t GenAI the next big thing? Does ML still matter?Absolutely. GenAI excels at natural language tasks — like document generation or summarization. But for structured data decisions like classification or regression, ML models like DAR are more reliable, interpretable, and consistent. They are trained on enterprise-labeled history, not general-purpose text.5. Isn’t this just another API call, which we do all the time to enrich our payload?Technically yes — but functionally, it’s transformational. It lets you embed intelligence directly into your Iflow’s runtime logic. It’s not just wiring systems — it’s wiring business decisions.6. Isn’t putting ML in middleware against “separation of concerns”, particularly when it is supposed to act as a pass-through layer?No. The ML model and its lifecycle are maintained outside Integration Suite (e.g., in DAR or AI Core). The Iflow just consumes the result — maintaining clean separation but gaining powerful synergy.Final ThoughtsInfusing AI into Integration Suite isn’t about over-engineering — it’s about elevating Integration Suite’s behaviour from rule-based mechanics to context-aware intelligence. With BTP AI services like DAR, integration developers can go beyond static routing and hardcoded decisions. They can orchestrate intelligent flows that learn from business history — and adapt as the world changes. As integration professionals, we’re not just moving data. We’re moving contextual, intelligent decisions.Here are some essential links for you to get started and apply AI in meeting your business requirements:Explore SAP Data Attribute Recommendation serviceSAP Tutorials: Implement your ML serviceThis blog focused solely on intelligent routing within iFlows. But the potential of infusing AI into Integration Suite goes far beyond — limited only by the developer’s creativity. With the upcoming AI Adapter (planned for Q3), things are bound to get even more exciting.“Stay hungry, stay foolish.” — Steve JobsPerhaps that same spirit can guide us as we collectively navigate the future of intelligent integration. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
