Integration Advisor: Architecture and Use

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 13 min read

Where This Article Sits#

References#

1) The Integration Advisor Landscape#

Integration Advisor is not a single tool — it is a stack of five layered capabilities that you adopt in order. Each layer has its own owner, its own deliverable, and its own failure mode at requirements stage.

They are not substitutes.

2) How It Connects to S/4HANA#

Integration Advisor sits at design time. The artifacts it produces are consumed at runtime by Cloud Integration, which is the iPaaS that S/4HANA actually talks to. Understanding the seam between these two layers is the single most useful piece of context.

                      +--------------------------------+
   Trading Partner    |  SAP Integration Suite tenant  |    SAP S/4HANA
       (EDI VAN)      |                                |     (on-prem or
            |         |  +--------------------------+  |      Private)
            |         |  |  Integration Advisor     |  |          |
            |         |  |  (design-time)           |  |          |
            v         |  |  Type Sys → MIG → MAG    |  |          |
  ============>       |  |        |                 |  |          |
  EDIFACT ORDERS      |  |        v generates       |  |          |
                      |  |  XSLT + XSD artifacts    |  |          |
                      |  +-------------+------------+  |          |
                      |                |               |          |
                      |                v deployed to   |          |
                      |  +--------------------------+  |          |
                      |  |  Cloud Integration       |<-+----------+
                      |  |  (runtime iflow)         |  |   IDoc / OData
                      |  |  reads XSLT, transforms  |  |
                      |  +--------------------------+  |
                      +--------------------------------+

Key point: Integration Advisor never touches a runtime message in production. It is a code generator, not a runtime engine. If a partner sends a malformed EDIFACT message at 3 AM, Cloud Integration handles it — Integration Advisor is not in the call path.

3) Maturity Map#

Honest read: the proposal engine is the visible feature, but the practical limit on a project is almost always Custom Functions and edge-case Custom Type Systems, not the headline ML.

4) Requirements Checklist#

Tenant and licensing prerequisites#

Type System and library decisions#

MIG design#

MAG design and Custom Functions#

Runtime artifact generation and deployment#

5) Decision Criteria#

The three questions to ask first#

Q1. Is there a measurable B2B mapping pain point right now?

If the customer cannot point to a specific mapping that takes too long, costs too much in PI/PO maintenance, or fails partner audits, Integration Advisor is the wrong project to start with. The proposal engine accelerates known mappings; it does not invent the need for them.

Q2. Do we own the data and the partner relationship?

Integration Advisor stores MIG and MAG metadata in the customer’s BTP tenant. If a third-party MSP owns the trading partner relationship (and the right to define the spec), the customer is buying capability they cannot exercise. Integration Advisor in this case ends up as shelfware.

Q3. Is there an internal sponsor with budget for both design-time and runtime?

Integration Advisor consumes Premium Edition entitlement; the runtime consumes Cloud Integration message volume. A sponsor who funds only one of these will hit a wall mid-project. The B2B center of excellence — not just an integration architect — is the right sponsor profile.

Domain selection by project context#

Licensing and cost#

6) Common Failures#

Failure 1: Treating Integration Advisor as a substitute for Trading Partner Management

The most frequent scoping error. Teams buy IA, design a beautiful MAG, generate runtime artifacts — and then discover at go-live that they have no partner agreement, no channel routing rules, and no way to onboard a second partner without copy-pasting iflows. IA owns the spec; TPM owns the agreement. Plan for both from the requirements stage.

Failure 2: Accepting all ML-proposed mappings without review

The proposal engine is good, not perfect. Auto-accepting proposals on uncommon segments produces mappings that look correct at design-time and fail at runtime when the source field is empty or the code list value is unexpected. Every proposal needs human acceptance — that is the design intent, not optional.

Failure 3: Underestimating Custom Function effort

Mainstream EDIFACT messages still typically need 5–15% of fields handled by Custom Functions: date format normalization, currency rounding, conditional flags. Projects scoped on “the proposal engine handles 95%” forget that the remaining 5% requires developer skill, not BA skill.

Failure 4: No code list governance

Code lists (currency codes, country codes, business partner classifications) drift between systems faster than message structures do. A MAG that maps a code list value 1:1 from source to target is a MAG that breaks when either system adds a new code. Map through a governed master data list, not field-to-field.

Failure 5: Forgetting to redeploy after MAG regeneration

IA regenerates the runtime artifact when MAG changes, but the artifact only takes effect in production after the consuming iflow is redeployed. Silent staleness — old XSLT running in production while the new XSLT sits in the Integration Suite package — is a common incident pattern. Build redeploy into the change process explicitly.

Failure 6: Choosing custom Type System for proprietary formats too early

A custom Type System is attractive because it makes proprietary partner schemas first-class citizens. It is also a long-term commitment that few teams have the capacity to maintain. For one-off proprietary formats, treat them as flat XML in Cloud Integration; reserve custom Type Systems for formats used by many partners.

Failure 7: No sandbox tenant for onboarding

Teams that learn the proposal engine on a productive tenant produce MIGs and MAGs that get edited live, with no rollback. A sandbox tenant is not a luxury — it is the standard onboarding pattern, and skipping it is the first cause of “we have to redo half of this” three months in.

FAQ#

Q: Can Integration Advisor be used with on-premise SAP PI/PO?

No. Integration Advisor is a capability of SAP Integration Suite (cloud) only. PI/PO has its own B2B Add-On with separate tooling. Migration from the PI/PO B2B Add-On to Integration Advisor is possible but is treated as a redesign, not a lift-and-shift.

Q: How is Integration Advisor licensed?

It is included in SAP Integration Suite Premium Edition, with consumption metered through CPEA or BTPEA credits. Standard Edition and the Free Tier do not include it. Pricing tiers have changed historically; verify the entitlement against the current order form before assuming availability.

Q: When should I descope Integration Advisor from a project?

Three signals: (1) only one or two partners in scope and no expectation of more, (2) all mappings use a single standard message you can hand-author in XSLT inside Cloud Integration in a day or two, (3) Premium Edition is not in the contract and a buy-up is not approved. In any of these cases, plain Cloud Integration mapping is faster and cheaper.

Q: How should the requirement be documented?

Write the requirement at the level of MIG and MAG, not at the level of “use Integration Advisor”. Specify: which Type System and version, which message types, which trading partners, which fields require Custom Functions, what the acceptance evidence looks like for each ML-proposed mapping. A requirement that says only “implement EDIFACT ORDERS in IA” is too vague to estimate.

Q: What is the relationship between Integration Advisor, Cloud Integration, and Trading Partner Management?

IA produces the specification (MIG, MAG, generated XSLT). Cloud Integration runs the iflow that consumes the generated XSLT. TPM defines the partner agreement — who the partner is, which channels are used, which iflow is invoked. All three are needed; each owns a different concern.

Q: Does Integration Advisor work for non-EDI integration scenarios (e.g., REST APIs)?

In principle yes — A2A mapping (application-to-application) is supported, including IDoc and proprietary XML. In practice, mainstream value comes from B2B EDI scenarios where the crowd library is mature. For REST API integration, API Management plus direct Cloud Integration mapping is usually a better fit.

Q: Who owns the generated runtime artifact in production?

The Cloud Integration team. Once the XSLT is deployed to a runtime iflow, all monitoring, error handling, and incident response are Cloud Integration responsibilities. IA-side designers are not paged for runtime issues.

Summary#

Integration Advisor solves a real problem: B2B mapping projects historically took months because the same EDIFACT message structure was rebuilt by every customer in every project. The crowd-sourced library plus ML proposal engine compress that work — for mainstream messages, dramatically. The honest scoping question is not “can IA do this” but “do we have a sponsor, a partner, and a developer who can finish what IA cannot propose.” Pair it with Trading Partner Management for full B2B coverage; descope it when the partner count or message variety does not justify Premium Edition.

What to Read Next#