{"id":69790,"date":"2026-08-03T08:35:56","date_gmt":"2026-08-03T06:35:56","guid":{"rendered":"https:\/\/www.cubeserv.com\/?p=69790"},"modified":"2026-08-03T09:46:56","modified_gmt":"2026-08-03T07:46:56","slug":"blog-serie-btp-teil-6-erweiterungen-in-der-praxis-side-by-side-extensions-mit-cap-und-rap","status":"publish","type":"post","link":"https:\/\/www.cubeserv.com\/de\/blog-serie-btp-teil-6-erweiterungen-in-der-praxis-side-by-side-extensions-mit-cap-und-rap\/","title":{"rendered":"Blog-Serie BTP Teil 6: Erweiterungen in der Praxis – Side-by-Side Extensions mit CAP und RAP"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ein \u00dcberblick \u00fcber die Integrationsstrategie der SAP BTP: Integration Suite, API Management und Event Mesh auf strategischer Flugh\u00f6he.<\/span><\/i><\/p>

Einleitung<\/h3>

In Teil 1<\/strong><\/a> haben wir das Clean-Core-Prinzip und die Extensibility-Level A bis D vorgestellt. In Teil 4<\/strong><\/a> ging es um die BTP-Environments Cloud Foundry, Kyma und das ABAP Environment. Jetzt verbinden wir beides: Wie sehen Erweiterungen konkret<\/em> aus? Welches Programmiermodell passt zu welchem Szenario?.<\/p>

Dieser Teil gibt einen \u00dcberblick \u00fcber die beiden zentralen Entwicklungsmodelle der SAP-Welt: das Cloud Application Programming Model (CAP) f\u00fcr Side-by-Side Extensions auf der BTP und das RESTful Application Programming Model (RAP) f\u00fcr On-Stack- & Side by Side-Erweiterungen in S\/4HANA und dem BTP ABAP Environment.<\/p>

Denn der eigentliche Mehrwert der SAP BTP entsteht nicht isoliert, sondern dann, wenn Systeme, Daten und Prozesse intelligent miteinander verbunden werden. Genau hier setzt die SAP Integration Suite<\/strong> an.<\/p>

Dieser Teil gibt einen \u00dcberblick<\/strong> \u00fcber die Integrationsf\u00e4higkeiten der SAP BTP mittels der SAP Integration Suite. Wir erkl\u00e4ren die wichtigsten Bausteine, ordnen sie ein und zeigen, wann welcher Ansatz sinnvoll ist.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Warum sollten wir \u00fcberhaupt den SAP-Standard erweitern?<\/h3>

Der SAP-Standard deckt viel ab, aber nat\u00fcrlich nie alles.
Unternehmen haben individuelle Prozesse, branchenspezifische Anforderungen oder Integrationsbedarfe, die \u00fcber die Standardfunktionalit\u00e4t hinausgehen.<\/p>

Und das ist auch gut so: Denn genau diese individuellen Prozesse machen Unternehmen erfolgreich. Sie sind oft die eigentliche USP, was das Unternehmen vom Wettbewerb unterscheidet. Wenn alle nur Standard machen, wo bleibt dann der Differenzierungsvorteil? Gleichzeitig gilt: Nicht jede historisch gewachsene Individualentwicklung ist heute noch sinnvoll. Unternehmen sollten ihre individuellen Prozesse regelm\u00e4\u00dfig hinterfragen im Sinne von \u201ebrauchen wir diesen Prozess noch in seiner jetzigen Form?\u201c oder \u201eHat sich der Gesch\u00e4ftskontext so ver\u00e4ndert, dass der Standard inzwischen die bessere L\u00f6sung w\u00e4re?\u201c.<\/p>

Diese Balance zwischen wertsch\u00f6pfender Individualisierung und sinnvoller Standardisierung ist eine der wichtigsten strategischen Entscheidungen. Fr\u00fcher wurde Individualisierung \u00fcber Z-Entwicklungen, User-Exits und Modifikationen umgesetzt mit den bekannten Folgen:<\/p>