SAP v roce 2026 zpřísňuje pravidla pro používání API rozhraní. Na první pohled jde o technické téma pro integrační architekty. Ve skutečnosti se ale dotýká každé firmy, která má kolem SAPu postavené externí aplikace, datové integrace, reporting, portály, mobilní aplikace nebo nově AI agenty.
Změna je jednoduchá v principu: pro produktivní použití mají být využívána pouze publikovaná a oficiálně podporovaná API.
„To, že endpoint dnes funguje, ještě neznamená, že je správné ho používat.“
Cílem článku je vysvětlit, co se mění, koho se změna týká, jakou roli hraje SAP Business Accelerator Hub, co znamená OData / CDS a kde leží hranice mezi bezpečnou integrací a rizikovým řešením.
AI summary: 
SAP API Policy v4/2026 posiluje princip, že produktivní integrace mají používat publikovaná API a oficiálně dokumentované způsoby přístupu. Interní, privátní nebo jinak nepodporovaná rozhraní představují riziko z pohledu podpory, upgradu, bezpečnosti i compliance. Pro zákazníky to znamená jediné: zmapovat existující integrace, ověřit použité endpointy a připravit plán nápravy tam, kde se využívají nepublikovaná API, interní OData služby nebo přímé čtení databáze.
Co se mění
SAP dlouhodobě směřuje k principu clean core. Zákaznické rozšíření a integrace nemají zasahovat přímo do jádra systému, ale mají využívat jasně definovaná a podporovaná rozhraní.
API Policy v4/2026 tento směr zpřesňuje. Nestačí, že rozhraní technicky existuje. Rozhodující je, zda je publikované, dokumentované a použité k účelu, pro který bylo určeno.
„API není zkratka do systému. API je smlouva o tom, jak se systém smí používat.“
Historicky mnoho integrací vznikalo pragmaticky: našel se OData endpoint, RFC, CDS view, tabulka nebo technická služba a začala se používat. Často to roky fungovalo. Nová pravidla ale jasněji oddělují podporovaný způsob integrace od technické zkratky, která může být při upgradu, auditu nebo změně release problematická.
SAP Business Accelerator Hub jako výchozí bod
První otázka pro každou integraci by měla znít: existuje k danému scénáři publikované API?
SAP Business Accelerator Hub je centrální katalog, kde SAP publikuje API, integrační obsah, business services a další artefakty použitelné pro rozšíření a integraci SAP systémů.
Pokud API existuje v SAP Business Accelerator Hubu nebo v oficiální produktové dokumentaci, je to přirozený první kandidát. Pokud neexistuje, neznamená to automaticky, že integrace není možná. Znamená to ale, že je potřeba architektonicky rozhodnout, jaký podporovaný scénář použít.
„Nejdřív katalog. Až potom workaround.“
Co je v pořádku?
Bezpečné scénáře obvykle zahrnují:
- publikované API ze SAP Business Accelerator Hubu,
- API uvedené v oficiální produktové dokumentaci,
- použití API v souladu s jeho dokumentovaným účelem,
- integrační scénáře přes SAP Integration Suite,
- rozšíření a integrace přes SAP BTP,
- datové scénáře přes SAP Datasphere / SAP Business Data Cloud,
- SAP Data Services nebo SLT tam, kde dávají smysl pro řízenou replikaci dat,
- custom API vytvořené v zákaznickém namespace,
- custom CDS view vystavené přes podporovaný mechanismus,
- non-SAP integrační nástroje, pokud používají podporované SAP rozhraní.
Důležité je poslední pravidlo. Azure Data Factory, MuleSoft, Boomi, Informatica, Talend, Databricks, Snowflake nebo jiný nástroj nejsou samy o sobě problém. Problém vzniká až tehdy, když přes ně zákazník obchází podporovanou SAP vrstvu.
„Nejde o to, jaký nástroj používáte. Jde o to, kudy do SAPu vstupujete.“
Co je naopak rizikové?
Rizikové jsou zejména integrace, které používají:
- interní nebo privátní SAP API,
- OData služby nalezené technicky, ale neurčené pro externí použití,
- nepublikované CDS views,
- unreleased RFC nebo function modules,
- přímé čtení databázových tabulek,
- hromadné extrakce mimo schválený scénář,
- AI agenty, kteří samostatně vybírají a volají SAP endpointy bez architektonické kontroly.
Externí nástroj takové použití „nezlegalizuje“. Pokud Azure Data Factory, Databricks nebo jiná platforma čte data přímo z interních tabulek nebo nepublikovaných endpointů, riziko zůstává.
„Externí nástroj nezlegalizuje interní API.“
U on-premise systémů to nemusí znamenat okamžité technické vypnutí. U cloudových systémů může být dopad rychlejší. V obou případech ale vzniká problém s podporou, bezpečností, auditovatelností a budoucími upgrady.
OData a CDS: povolené, nebo nepovolené?
Častá otázka zní: „Co OData?“
OData samo o sobě není problém. OData je protokol. Rozhodující je, jaká služba je přes něj vystavena a zda je určena pro dané použití.
„OData není propustka. OData je jen způsob komunikace.“
Pokud používáte publikované OData API nebo oficiální komunikační scénář, je to v pořádku. Pokud ale externí aplikace používá interní OData službu, která nebyla určena pro produktivní externí integraci, dostáváte se do rizikové zóny.
Podobně je to s CDS Views. Custom CDS view může být v pořádku, pokud je vytvořené a vystavené jako externí API přes podporovaný mechanismus. Není ale v pořádku automaticky každé CDS, které lze technicky zavolat.
Dopad na stávající zákaznické integrace
Největší výzvou bude historie. Řada integrací vznikala v době, kdy byl hlavní požadavek rychle propojit systémy. Někde se použilo standardní API. Jinde zákaznické RFC. Jinde přímé čtení tabulek. A často dnes nikdo nemá kompletní přehled.
První krok proto není přepis integrací. První krok je inventura.
Doporučený postup:
- sepsat všechny SAP integrace,
- identifikovat použité endpointy a technické objekty,
- ověřit, zda jde o publikované API,
- zkontrolovat účel použití,
- rozdělit integrace podle rizika,
- připravit nápravný plán.
„Nejdřív mapa. Potom migrace.“
Co udělat teď
Firmy by neměly čekat na první problém při upgradu nebo auditu. Doporučený postup je relativně jednoduchý:
- vytvořit inventuru všech SAP integrací,
- identifikovat API, RFC, OData, CDS a DB přístupy,
- ověřit je proti SAP Business Accelerator Hubu a dokumentaci,
- označit rizikové integrace,
- připravit roadmapu nápravy,
- nastavit API governance pro nové projekty.
„API governance není brzda. Je to pojistka, že integrace přežije další release.“
Shrnutí
SAP API Policy v4/2026 není jen další technický dokument. Je to signál, že SAP zpřísňuje pravidla pro přístup k systému a tlačí zákazníky k čistší, podporovatelné a bezpečnější integrační architektuře.
Pro nové projekty to znamená jasné pravidlo: používat publikovaná API, dokumentované scénáře a řízené integrační vrstvy. Pro stávající zákazníky to znamená projít integrační landscape a zjistit, kde se dnes používají technické zkratky, které mohou být do budoucna problém.
„Integrace, která není řízená, je technický dluh. API Policy jen nastavuje datum splatnosti.“
Nevíte, zda jsou vaše SAP integrace v souladu s novou API politikou? Pomůžeme vám zmapovat stávající rozhraní, rozdělit je podle rizika a navrhnout realistický plán úprav. Datové extrakce a přístup k SAP datům posuzujeme v rámci SAP Data Readiness Check.