SAP B1 Blog

Der Service Layer von SAP Business One diente bisher überwiegend als passiver Datenlieferant: Anwendungen fragten Daten über OData ab, jede weitergehende Automatisierung erforderte zusätzlichen Verbindungscode in der Middleware. Mit dem Feature Package 2608 für SAP Business One 10.0 erweitert SAP diese Schnittstelle um konditionale Webhooks und angereicherte Ereignis-Nutzdaten. Ergänzend veröffentlicht SAP ein Beispielprojekt, das zeigt, wie sich Service-Layer-OData-Dienste über das Model Context Protocol als Werkzeuge für KI-Agenten bereitstellen lassen, und das dabei benutzerdefinierte Objekte, Tabellen und Felder automatisch einbindet. Dieser Artikel ordnet ein, welche Neuerungen produktive Service-Layer-Funktionen sind und welche als Referenzcode zu verstehen sind.

Weiterlesen: SAP B1 10.0 FP2608: Service Layer KI als transaktionalen Schicht

Ereignisgesteuerte Webhooks statt reiner OData-Abfragen

Bislang beantwortete der Service Layer überwiegend OData-Abfragen und lieferte Daten nach Anfrage aus. Mit dem Feature Package 2608 baut SAP diese Schnittstelle zu einem stärker ereignisgesteuerten System aus: Webhooks liefern mehr Kontext direkt im Ereignis, und eine neue Filterlogik steuert, wann ein Ereignis überhaupt ausgelöst wird. Logik lässt sich dadurch näher an der Datenquelle verarbeiten, statt sie zusätzlich in externen Systemen nachzubauen.

Diese Webhook-Erweiterungen sind reguläre, produktive Service-Layer-Funktionen. Sie unterscheiden sich damit von der KI-Anbindung über das Model Context Protocol, die SAP als Beispielprojekt bereitstellt. Clientseitige Funktionen wie die Frage-Funktion Ask AI im Web Client bleiben ohnehin rein lesend: Sie beantworten Fragen zu vorhandenen Daten, verändern aber nichts.

Model Context Protocol: Beispielprojekt für schreibenden KI-Zugriff

Mit FP 2608 veröffentlicht SAP ein Beispielprojekt für das Model Context Protocol (MCP), einen plattformunabhängigen Standard, über den große Sprachmodelle wie Claude oder Microsoft Copilot Zugriff auf Anwendungen erhalten. Laut der Dokumentation zu diesem Beispielprojekt zeigt es, wie sich Service-Layer-OData-Dienste als dynamische Werkzeuge für KI-Agenten bereitstellen lassen, die MCP unterstützen.

SAP kennzeichnet das Projekt ausdrücklich als Referenz- und Lernmaterial, nicht als fertiges Produkt. Es ist laut Dokumentation nicht notwendigerweise produktionsreif. Partner und Entwickler sollen die Architektur studieren, den Code anpassen, die eingebauten Funktionen bewerten und darauf aufbauend eigene MCP-Server-Implementierungen für ihre jeweiligen Geschäftsanforderungen entwickeln.

Der entscheidende Unterschied zu den produktiven Webhook-Erweiterungen liegt im Zugriffsmuster: Das Beispielprojekt demonstriert sowohl Lese- als auch Schreibtransaktionen über den Service Layer. Ein KI-Agent könnte darüber also nicht nur Daten abfragen, sondern auch Belege anlegen oder ändern. Damit ein Agent dabei keine unkontrollierten Buchungen vornimmt, sieht das Beispielprojekt laut Dokumentation drei Mechanismen vor:

• Zugriffstoken über den Identitäts- und Authentifizierungsdienst von SAP Business One: Er baut auf Keycloak auf und lässt sich an weitere Identitätsanbieter anbinden
• Protokollierung sicherheitsrelevanter Ereignisse: Der MCP-Server schreibt Schreibbestätigungen, Beginn und Ablauf von Sitzungen sowie fehlgeschlagene Anmeldungen standardmäßig in eine rotierende Protokolldatei
• Geprüfte Berechtigungen: Der Service Layer gleicht Rollen und Berechtigungen des Tokens mit dem Berechtigungsmodell von SAP Business One ab. Verweigert er den Zugriff, meldet der Beispielserver dem KI-Agenten einen Fehler und gibt keine Daten zurück

Wer den schreibenden KI-Zugriff produktiv einsetzen will, muss die Architektur des Beispielprojekts also selbst übernehmen und anpassen. SAP liefert damit keinen fertigen MCP-Server, sondern eine Vorlage für eigene Implementierungen.

BizObjProps und DeliveryDetails: Weniger Abfragen pro Ereignis

Ein zentrales technisches Problem bisheriger Webhooks war das sogenannte N+1-Problem. Webhooks lieferten bislang nur den Objekt-Schlüssel eines Ereignisses. Für jedes weitere Detail musste der Empfänger deshalb eine eigene, separate Abfrage starten. Das führte zu vielen Einzelabfragen und unnötiger Netzwerklast.

Mit BizObjProps schickt der Service Layer künftig ausgewählte Felder direkt im Ereignis mit, statt nur den Schlüssel zu übergeben. Diese Anreicherung der Nutzdaten reduziert die Zahl der Folgeabfragen. Ergänzend führt FP 2608 DeliveryDetails ein: Statusinformationen zur Zustellung und zu Fehlversuchen landen direkt in der Nutzlast. Das beschleunigt die Fehlersuche bei Integrationen und reduziert die Netzwerklast.

FilterExpr und app.Name: Kontrollierte Auslösung von Ereignissen

Um unnötigen Datenverkehr zu vermeiden, führt FP 2608 die konditionale Webhook-Logik FilterExpr ein. Ein Ereignis feuert damit nur noch, wenn zuvor definierte mathematische, zeitliche oder String-Bedingungen erfüllt sind, etwa mit Funktionen wie UPPER, ROUND oder TODAY.

Zusätzlich steht die Kontextvariable app.Name zur Verfügung. Sie ermittelt laut SAP-Dokumentation den Prozessnamen der aufrufenden Anwendung ohne Dateiendung, etwa SAP Business One für den Desktop-Client oder httpd für den Service Layer selbst. Daraus ergibt sich eine mögliche Anwendung: Unzureichend konfigurierte Webhooks können zu Ereignis-Schleifen führen, wenn Anwendung A einen Datensatz aktualisiert und der zugehörige Webhook dadurch erneut einen Aufruf an Anwendung A auslöst. Über app.Name lässt sich die aufrufende Anwendung erkennen und ein solcher zirkulärer Aufruf im Filterausdruck ausschließen. SAP selbst beschreibt diesen Einsatzzweck in der Dokumentation nicht ausdrücklich, er ergibt sich aus der Grundfunktion der Variable.

Automatische Einbindung benutzerdefinierter Objekte

Traditionelle Middleware stößt häufig an ein grundsätzliches Problem: Jedes neue benutzerdefinierte Feld erfordert eine manuelle Anpassung des Codes, weil das Datenschema als starr angenommen wird. Der MCP-Server im Beispielprojekt bindet benutzerdefinierte Objekte (UDO), Tabellen (UDT) und Felder (UDF) automatisch neben den Standardentitäten ein, eine zusätzliche Konfiguration ist dafür nicht nötig.

Getrennt davon organisiert das Beispielprojekt den Zugriff auf Entitäten allgemein in drei Schritten: b1_find_entities ermittelt passende Entitäten, b1_get_entity_schema liefert deren Schema, und b1_read beziehungsweise b1_write führen die Lese- oder Schreiboperation aus.

Service Layer als Grundlage für zwei unterschiedliche Ausbaustufen

Insgesamt liefert FP 2608 zwei unterschiedliche Bausteine für den Einsatz von KI-Agenten am Service Layer. Zum einen produktive Webhook-Erweiterungen, die weniger Abfragen pro Ereignis erzeugen und die Auslösung von Ereignissen gezielt steuern. Zum anderen ein Beispielprojekt, das den Weg zu einem schreibenden KI-Zugriff über das Model Context Protocol aufzeigt.

Für Architekten und Integratoren verschiebt sich der Fokus dementsprechend in zwei Richtungen. Die überarbeitete Webhook-Filterlogik ersetzt bereits heute einen Teil des bisher notwendigen Verbindungscodes in der Middleware. Der schreibende KI-Zugriff über den Service Layer und die automatische Einbindung benutzerdefinierter Objekte bleiben dagegen vorerst Referenzarchitektur: Wer sie produktiv nutzen will, muss das veröffentlichte Beispielprojekt studieren und eine eigene Implementierung darauf aufbauen.

Quellen: 
https://help.sap.com/doc/fc2f5477516c404c8bf9ad1315a17238/10.0/en-US/Working_with_SAP_Business_One_Service_Layer.pdf. https://help.sap.com/docs/SAP_BUSINESS_ONE/bb89a9939c294f14a7f532f7e76ade9e.