Integration modernization is often discussed in two dimensions:
Platform modernization – moving from older stacks like SAP NetWeaver PI/PO, SAP Neo, or legacy 3rd party platforms to SAP Integration Suite.Scenario modernization – shifting from legacy protocols to modern integration patterns such as APIs & event-driven architectures; upgrading ABAP / Java mapping to graphical mapping / groovy script; or moving from basic auth to OAuth 2.0 or client certificate based authentication, and so on.
But there is another Modernization opportunity at the scenario level: decision logic modernization.
In this blog, we explore how routing decision logic, as an orchestration step — can be modernized using RPT-1, SAP’s latest foundation model hosted on BTP AI Core (Generative AI Hub) — applied to an outbound delivery routing scenario.
The Traditional Approach: Static Rules, Lookups, and Growing Complexity
In SAP PI/PO and Integration Suite, routing decisions are typically implemented using deterministic, rule-based logic. These decisions often control how a scenario behaves – including 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., via JDBC, SOAP, RFC lookups) 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 conditions and evolving business scenariosLookup tables become burdensome to maintainDecisions become rigid and hard to evolve over time
As a result, rule-based decisioning becomes harder to maintain as business requirements evolve. Agility suffers. Adaptation becomes expensive.
What if, instead of relying on static rule-based logic, iflows could make decisions based on historical business patterns — applying predictive machine learning without the overhead of training and managing custom models? With the in-context learning capabilities of SAP’s latest foundation model, RPT-1, such predictions can be performed on-the-fly at runtime.
Enter RPT-1: Foundation Model for Predictive Tasks
SAP’s RPT-1 is a pre-trained foundation model available via BTP AI Core (Generative AI Hub). Unlike traditional ML services that require dedicated data science setup, RPT-1 offers:
Pre-trained model, ready for “plug and play” in your scenarioNo ML infrastructure setupNo data science expertise requiredNo-code consumption via APIFaster time-to-marketDemocratization of AI capabilities across IT functions
SAP RPT-1 is pre-trained specifically for tasks such as classification and prediction over ERP tabular data, unlike many general-purpose GenAI models that are primarily trained on large corpora of natural language text. Instead of building and managing a full ML lifecycle, integration developers can now leverage predictive intelligence directly into iflows — without any data science related heavy-lifting.
If you are new to SAP RPT-1, I recommend that you read this introductory blog.
Also, explore this SAP-RPT-1 playground.
Business Scenario: Intelligent Outbound Delivery Routing with RPT-1
SmartSense Technologies (SST), a global provider of smart security devices, faces challenges in routing outbound deliveries from its manufacturing plants to distribution centers, retail stores, and end customers. Their current routing logic, embedded in integration flows, relies on static rules and lookup tables – employing a combination of Material, Quantity, Delivery priority, Material group, Ship to location, and so on. This leads to frequent shipping delays, cost overruns, and SLA violations whenever logistics conditions change and sub-optimal 3PL partner is chosen.
To overcome these limitations, SST decides to leverage SAP Integration Suite together with SAP RPT-1 foundation model. By embedding machine learning–driven decision-making into its integration flow, SST aims to dynamically select the optimal logistics partner for each delivery based on historical performance, cost, and delivery times.
The following diagram illustrates the target architecture implemented by SST for intelligent outbound delivery routing using SAP Integration Suite and RPT-1 model, hosted on BTP’s Generative AI hub:
Step 1: Outbound Delivery Creation
An outbound delivery is created in SAP S/4HANA, which triggers an outbound notification event. The event is consumed by the iflow, which then calls S/4HANA OData API to fetch the following delivery related header and item attributes.
Delivery header fields: DeliveryDate, SalesOrganization, ShipToParty, SoldToParty, DeliveryDocumentType, CreationDate, ShippingPoint, DeliveryPriority, IncotermsClassification, TransactionCurrency
Delivery item fields: Material, DeliveryDocumentItemText, MaterialGroup, ActualDeliveryQuantity, DeliveryQuantityUnit, Plant, StorageLocation, ItemGrossWeight, ItemWeightUnit, ControllingArea, DistributionChannel, GoodsMovementType, ProfitCenter
Step 2: Context Selection – Random Historical Records
We store historic labeled data i.e. delivery headers, items and corresponding optimal 3PL partner data in SAP HANA Cloud. The iflow is configured to fetch a random set of this historic data from HANA Cloud. As recommended in this blog, for most enterprise use-cases, where you have about hundred thousand to million lines of labelled data, depending on how diverse your scenario data is, you may choose the context size, by iterating and finalizing the apt number of historical records to pick. By picking random records, we are able to provide statistically diverse examples, improve prediction quality and avoid bias from sequential records.
The Iflow executes the following query on the HANA Cloud DB:
SELECT TOP ${property.NumberofRecords}
“DeliveryDate”, “DeliveryDocumentNumber”, “CreationDate”, “DeliveryPriority”, “IncotermsClassification”, “Material”, “DeliveryDocumentItemText”, “MaterialGroup”, “ActualDeliveryQuantity”, “DeliveryQuantityUnit”, “ItemGrossWeight”, “ItemWeightUnit”, “DistributionChannel”, “PartnerNumber”
FROM “RPT1″.”historic_3pl_selections”
ORDER BY RAND()
Step 3: Constructing the RPT-1 Request
We now combine:
Historical random records (known 3PL partner)The current outbound delivery (3PL partner to be predicted)
The current transaction includes a placeholder: [PREDICT]
The request payload contains:
900 historical labeled rows1 new outbound delivery row marked for prediction
For detailed info on payload construction, refer to the official documentation page and the GitHub repository (sample Postman/Bruno collections available for experimentation).
Further, while creating the inferencing request to RPT-1, we trim the columns from original 24 down to only 14 columns of delivery attributes, by removing fields like Sales Org, Controlling Area, Profit centre that do not influence partner selection. This is one of the best practices to achieve best possible predictive outputs. Read more recommended best practices here.
Step 4: Deploying RPT-1 in Generative AI Hub
Step 5: RPT-1 Response
The response contains Number of predicted records, predicted field (here optimal 3PL partner) along with Confidence score.
Response from our example scenario:
You can also send multiple unknown records in one batch. To read more about the number of max. records and columns supported by RPT-1, check out this help page.
Step 6: Intelligent Routing in the Iflow
The Iflow now:
Reads the predicted PartnerNumberEvaluates confidence threshold (optional safeguard)Routes outbound delivery to the optimal 3PL partnerOptionally, logs decision + confidence for traceability in HANA Cloud.
When AI in Iflows Brings Real Business Value
When routing decisions directly impact business outcomes
If sub-optimal routing can lead to SLA breaches, shipment delays, higher costs, or customer dissatisfaction, intelligent decision logic creates measurable advantage.When rule-based logic becomes complex and brittle
As business variables multiply (products, regions, priorities, partners), static rules become hard to maintain and scale. ML handles multi-dimensional patterns more effectively.When historical ERP data contains predictive patterns
If past delivery and fulfillment data reflects consistent business behavior, ML can learn from it and improve future routing decisions beyond deterministic conditions.When business context evolves over time
With changing product mixes, customer bases, or distribution models, retrainable ML models adapt dynamically — avoiding constant manual rule maintenance.
Not every integration scenario requires ML capabilities. But where routing decisions carry operational or financial impact, replacing rigid rule sets with adaptive decision logic can significantly improve resilience and maintainability. Decision logic modernization is therefore not about adding AI everywhere — it is about applying it where it meaningfully improves orchestration.
Note: This blog revisits our earlier implementation in light of the planned deprecation of SAP BTP Data Attribute Recommendation, demonstrating an updated approach using SAP-RPT-1 model.
Integration modernization is often discussed in two dimensions:Platform modernization – moving from older stacks like SAP NetWeaver PI/PO, SAP Neo, or legacy 3rd party platforms to SAP Integration Suite.Scenario modernization – shifting from legacy protocols to modern integration patterns such as APIs & event-driven architectures; upgrading ABAP / Java mapping to graphical mapping / groovy script; or moving from basic auth to OAuth 2.0 or client certificate based authentication, and so on.But there is another Modernization opportunity at the scenario level: decision logic modernization.In this blog, we explore how routing decision logic, as an orchestration step — can be modernized using RPT-1, SAP’s latest foundation model hosted on BTP AI Core (Generative AI Hub) — applied to an outbound delivery routing scenario.The Traditional Approach: Static Rules, Lookups, and Growing ComplexityIn SAP PI/PO and Integration Suite, routing decisions are typically implemented using deterministic, rule-based logic. These decisions often control how a scenario behaves – including 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., via JDBC, SOAP, RFC lookups) 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 conditions and evolving business scenariosLookup tables become burdensome to maintainDecisions become rigid and hard to evolve over timeAs a result, rule-based decisioning becomes harder to maintain as business requirements evolve. Agility suffers. Adaptation becomes expensive.What if, instead of relying on static rule-based logic, iflows could make decisions based on historical business patterns — applying predictive machine learning without the overhead of training and managing custom models? With the in-context learning capabilities of SAP’s latest foundation model, RPT-1, such predictions can be performed on-the-fly at runtime.Enter RPT-1: Foundation Model for Predictive TasksSAP’s RPT-1 is a pre-trained foundation model available via BTP AI Core (Generative AI Hub). Unlike traditional ML services that require dedicated data science setup, RPT-1 offers:Pre-trained model, ready for “plug and play” in your scenarioNo ML infrastructure setupNo data science expertise requiredNo-code consumption via APIFaster time-to-marketDemocratization of AI capabilities across IT functionsSAP RPT-1 is pre-trained specifically for tasks such as classification and prediction over ERP tabular data, unlike many general-purpose GenAI models that are primarily trained on large corpora of natural language text. Instead of building and managing a full ML lifecycle, integration developers can now leverage predictive intelligence directly into iflows — without any data science related heavy-lifting.If you are new to SAP RPT-1, I recommend that you read this introductory blog.Also, explore this SAP-RPT-1 playground.Business Scenario: Intelligent Outbound Delivery Routing with RPT-1SmartSense Technologies (SST), a global provider of smart security devices, faces challenges in routing outbound deliveries from its manufacturing plants to distribution centers, retail stores, and end customers. Their current routing logic, embedded in integration flows, relies on static rules and lookup tables – employing a combination of Material, Quantity, Delivery priority, Material group, Ship to location, and so on. This leads to frequent shipping delays, cost overruns, and SLA violations whenever logistics conditions change and sub-optimal 3PL partner is chosen.To overcome these limitations, SST decides to leverage SAP Integration Suite together with SAP RPT-1 foundation model. By embedding machine learning–driven decision-making into its integration flow, SST aims to dynamically select the optimal logistics partner for each delivery based on historical performance, cost, and delivery times.The following diagram illustrates the target architecture implemented by SST for intelligent outbound delivery routing using SAP Integration Suite and RPT-1 model, hosted on BTP’s Generative AI hub:Step 1: Outbound Delivery CreationAn outbound delivery is created in SAP S/4HANA, which triggers an outbound notification event. The event is consumed by the iflow, which then calls S/4HANA OData API to fetch the following delivery related header and item attributes.Delivery header fields: DeliveryDate, SalesOrganization, ShipToParty, SoldToParty, DeliveryDocumentType, CreationDate, ShippingPoint, DeliveryPriority, IncotermsClassification, TransactionCurrencyDelivery item fields: Material, DeliveryDocumentItemText, MaterialGroup, ActualDeliveryQuantity, DeliveryQuantityUnit, Plant, StorageLocation, ItemGrossWeight, ItemWeightUnit, ControllingArea, DistributionChannel, GoodsMovementType, ProfitCenter Step 2: Context Selection – Random Historical RecordsWe store historic labeled data i.e. delivery headers, items and corresponding optimal 3PL partner data in SAP HANA Cloud. The iflow is configured to fetch a random set of this historic data from HANA Cloud. As recommended in this blog, for most enterprise use-cases, where you have about hundred thousand to million lines of labelled data, depending on how diverse your scenario data is, you may choose the context size, by iterating and finalizing the apt number of historical records to pick. By picking random records, we are able to provide statistically diverse examples, improve prediction quality and avoid bias from sequential records.The Iflow executes the following query on the HANA Cloud DB:SELECT TOP ${property.NumberofRecords}
“DeliveryDate”, “DeliveryDocumentNumber”, “CreationDate”, “DeliveryPriority”, “IncotermsClassification”, “Material”, “DeliveryDocumentItemText”, “MaterialGroup”, “ActualDeliveryQuantity”, “DeliveryQuantityUnit”, “ItemGrossWeight”, “ItemWeightUnit”, “DistributionChannel”, “PartnerNumber”
FROM “RPT1″.”historic_3pl_selections”
ORDER BY RAND()Step 3: Constructing the RPT-1 RequestWe now combine:Historical random records (known 3PL partner)The current outbound delivery (3PL partner to be predicted)The current transaction includes a placeholder: [PREDICT]The request payload contains:900 historical labeled rows1 new outbound delivery row marked for predictionFor detailed info on payload construction, refer to the official documentation page and the GitHub repository (sample Postman/Bruno collections available for experimentation).Further, while creating the inferencing request to RPT-1, we trim the columns from original 24 down to only 14 columns of delivery attributes, by removing fields like Sales Org, Controlling Area, Profit centre that do not influence partner selection. This is one of the best practices to achieve best possible predictive outputs. Read more recommended best practices here. Step 4: Deploying RPT-1 in Generative AI HubStep 5: RPT-1 ResponseThe response contains Number of predicted records, predicted field (here optimal 3PL partner) along with Confidence score.Response from our example scenario:You can also send multiple unknown records in one batch. To read more about the number of max. records and columns supported by RPT-1, check out this help page.Step 6: Intelligent Routing in the IflowThe Iflow now:Reads the predicted PartnerNumberEvaluates confidence threshold (optional safeguard)Routes outbound delivery to the optimal 3PL partnerOptionally, logs decision + confidence for traceability in HANA Cloud.When AI in Iflows Brings Real Business ValueWhen routing decisions directly impact business outcomesIf sub-optimal routing can lead to SLA breaches, shipment delays, higher costs, or customer dissatisfaction, intelligent decision logic creates measurable advantage.When rule-based logic becomes complex and brittleAs business variables multiply (products, regions, priorities, partners), static rules become hard to maintain and scale. ML handles multi-dimensional patterns more effectively.When historical ERP data contains predictive patternsIf past delivery and fulfillment data reflects consistent business behavior, ML can learn from it and improve future routing decisions beyond deterministic conditions.When business context evolves over timeWith changing product mixes, customer bases, or distribution models, retrainable ML models adapt dynamically — avoiding constant manual rule maintenance.Not every integration scenario requires ML capabilities. But where routing decisions carry operational or financial impact, replacing rigid rule sets with adaptive decision logic can significantly improve resilience and maintainability. Decision logic modernization is therefore not about adding AI everywhere — it is about applying it where it meaningfully improves orchestration.Note: This blog revisits our earlier implementation in light of the planned deprecation of SAP BTP Data Attribute Recommendation, demonstrating an updated approach using SAP-RPT-1 model. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
