SAP BTP Extension Development mit LLMs: Code-Generierung und Deployment – Ein Deep Dive

Genug der Theorie. Heute öffnen wir die IDE. Für SAP-Entwickler stellt sich nicht die Frage, ob sie AI nutzen, sondern wie sie diese sauber in das Cloud Application Programming Model (CAP) integrieren. Wir zeigen den Weg vom API-Call zum deployten Service auf der BTP.

Lesezeit: ca. 8 Minuten | Level: Expert / Developer | Autor: CloudDNA Dev-Lead

Wer als Entwickler heute „AI-Integration“ hört, denkt oft an einfache REST-Calls gegen die OpenAI-API. Im Enterprise-Kontext auf der SAP Business Technology Platform (BTP) ist das jedoch zu kurz gesprungen (Stichwort: Credential Management, Audit-Logs, Vektor-Support).

Die saubere Architektur führt über den SAP Generative AI Hub und das SAP AI Core SDK.

In diesem Deep Dive bauen wir (gedanklich) eine CAP-Service-Erweiterung, die unstrukturierte Freitexte aus einem Fiori-Frontend entgegennimmt, sie via LLM analysiert und das strukturierte Ergebnis zurück in eine HANA-Tabelle schreibt.

Hier ist der technische Blueprint.

1. Die Architektur: AI Core als Proxy

Vergessen Sie API-Keys im Code. Wir nutzen die BTP-Infrastruktur.

Service: SAP AI Core (Plan: extended)
Model: GPT-4o (oder vergleichbar), deployed im AI Core.
Framework: SAP CAP (Node.js Flavor in diesem Beispiel).
Library: @sap-ai-sdk/ai-api & @sap-cloud-sdk/core.

Der Vorteil: Ihr CAP-Service kennt die Credentials des LLM-Providers nicht. Er kennt nur die BTP-Destination. Das ist „Security by Design“.

2. Setup & Dependencies

Zuerst binden wir das notwendige SDK in unser CAP-Projekt ein.

npm install @sap-ai-sdk/ai-api @sap-ai-sdk/foundation-models

In der mta.yaml (oder cdktf) müssen wir sicherstellen, dass unser CAP-Service an eine Service-Instanz des SAP AI Core gebunden ist.

resources:

- name: my-ai-core

type: org.cloudfoundry.managed-service

parameters:

service: aicore

service-plan: extended

👉 [Pair Programming Session buchen]

Jetzt Kontaktieren

3. Der Code: LLM-Orchestrierung in CAP

Nehmen wir an, wir haben eine Action analyzeFeedback in unserer service.cds.

Hier ist die Implementierung im Handler (service.js / service.ts):

const { AzureOpenAiChatClient } = require('@sap-ai-sdk/foundation-models');

module.exports = async (srv) => {
  srv.on('analyzeFeedback', async (req) => {
  const userText = req.data.text;

  // 1. Initialisierung des Clients via BTP Destination
  // Das SDK holt sich automatisch die Credentials aus dem Service Binding
  const response = await AzureOpenAiChatClient.getInstance()
  .run({
  messages: [
  { role: 'system', content: 'Du bist ein Assistent, der Kundenfeedback in JSON kategorisiert (Sentiment, Kategorie, Dringlichkeit).' },
  { role: 'user', content: userText }
  ],
  model: 'gpt-4-32k', // Deployment Name im AI Core
  temperature: 0.0
  });

  // 2. Parsing des Ergebnisses
  const aiResult = response.getContent();

  // 3. Speichern in der Datenbank (Pseudo-Code)
  await INSERT.into('FeedbackResults').entries({
  originalText: userText,
  analysisJson: aiResult
  });

  return aiResult;
  });
};

Was hier passiert (Under the Hood):

Destination Handling: Das @sap-ai-sdk prüft die Umgebungsvariablen (VCAP_SERVICES), findet die AI Core Bindung, authentifiziert sich via OAuth (XSUAA) und routet den Request sicher an den Generative AI Hub.
Abstraction: Ob im Hintergrund Azure OpenAI oder AWS Bedrock läuft, ist für Ihren Code fast transparent. Sie ändern nur das Deployment-Target-Mapping im AI Core, nicht den Code.

4. Die Falle: Timeouts & Asynchronous Processing

Ein häufiger Fehler bei SAP-Entwicklern, die neu in AI sind: Synchrone Calls.

Ein komplexer LLM-Prompt kann 30-60 Sekunden dauern. Der Standard-Timeout des SAP Load Balancers oder der Datenbankverbindung schlägt oft früher zu.

Die CloudDNA Best Practice:

Bauen Sie AI-Integrationen in CAP immer asynchron.

User sendet Request -> CAP setzt Status auf „Processing“ und gibt 202 Accepted zurück.
CAP triggert einen internen Event / Job.
Der Job ruft das LLM auf (Zeit spielt keine Rolle).
Wenn das LLM antwortet, updated CAP den Datenbank-Eintrag und nutzt ggf. WebSockets, um das Frontend zu informieren.

Nutzen Sie dazu cds.spawn oder externe Job-Scheduler auf der BTP.

5. Prompt Engineering im Code: Templates nutzen

Hardcodierte Strings im Code („Du bist ein Assistent…“) sind schlecht wartbar.

Lagern Sie Prompts aus. Wir nutzen dafür oft JSON-Files oder eine eigene Konfigurations-Entität in der Datenbank.

So können Sie den „System Prompt“ anpassen (z.B. „Sei strenger bei der Bewertung“), ohne die App neu deployen zu müssen.

6. Deployment & Skalierung

Beim mta build und cf push achten Sie auf den Memory-Footprint. Das AI-SDK und die Verarbeitung großer JSON-Payloads benötigen Speicher.

Empfehlung: Starten Sie mit mindestens 512MB für den Node.js Container, wenn Sie große Texte verarbeiten.

Fazit: Vom Coder zum Orchestrator

Die Entwicklung von SAP Extensions wandelt sich. Wir schreiben weniger Algorithmen für String-Parsing (das macht jetzt das LLM), dafür investieren wir mehr Zeit in:

Resilience: Was passiert, wenn das LLM nicht antwortet?
Security: Validierung des LLM-Outputs (verhindern von Injection-Attacken in die DB).
Cost Control: Caching von Antworten für häufige Anfragen.

Mit CAP und dem AI SDK haben wir ein mächtiges Werkzeugset, um Enterprise-Grade AI zu bauen. Nutzen Sie es, statt „nackte“ HTTP-Requests zu basteln.

Code-Snippet to go

Wussten Sie, dass CAP Vektoren unterstützt?

entity Documents {
  key id : UUID;
  content : String;
  embedding : Vector(1536); // Neu in HANA Cloud & CAP
}

Damit bauen Sie RAG-Szenarien (Retrieval Augmented Generation) direkt in Ihr Datenmodell ein.

Nächster Schritt

Wollen Sie diesen Code live sehen?

Blogposts sind geduldig. Code muss laufen. Wir bieten „Pair Programming Sessions“ an. Einer unserer Senior Developer setzt sich (virtuell) mit Ihrem Team zusammen, und wir bauen in 4 Stunden einen funktionierenden End-to-End Prototypen auf Ihrer BTP.

Willkommen zu AI Part 10

SAP CAP AI: SAP BTP Deep Dive- Extension Development mit LLMs & CAP