SAP B1 10.0 FP2608: Service Layer AI as a transactional layer

Of the Service Layer of SAP Business One has previously served predominantly as a passive data provider: applications requested data via OData From then on, any further automation required additional connection code in the middleware. With feature package 2608 for SAP Business One 10.0, SAP is extending this interface with conditional webhooks and enriched event payloads. Additionally, SAP is releasing a sample project that demonstrates how service layer OData services can be provided as tools for AI agents via the Model Context Protocol, automatically integrating custom objects, tables and fields. This article classifies which innovations are productive service layer functions and which are to be understood as reference code.

Event-driven webhooks instead of pure OData queries

So far, the service layer has predominantly answered OData queries and delivered data upon request. With Feature Package 2608, SAP is building upon this interface towards a more event-driven system: webhooks deliver more context directly within the event, and new filter logic controls when an event is triggered at all. Logic can thus be processed closer to the data source, rather than having to replicate it additionally in external systems.

These webhook extensions are standard, production service-layer functions. They thus differ from the AI integration via the Model Context Protocol, which SAP provides as a sample project. Client-side functions such as the 'Ask AI' question feature in the web client remain purely read-only anyway: they answer questions about existing data, but do not change anything.

Model Context Protocol: Example project for writing AI access

With FP 2608, SAP is releasing a sample project for the Model Context Protocol (MCP), a platform-independent standard that gives large language models such as Claude or Microsoft Copilot access to applications. According to the documentation for this sample project, it demonstrates how service layer OData services can be provided as dynamic tools for AI agents that support MCP.

SAP explicitly designates the project as reference and learning material, rather than a finished product. According to the documentation, it is not necessarily production-ready. Partners and developers are intended to study the architecture, adapt the code, evaluate the built-in functions, and build upon it to develop their own MCP server implementations for their respective business requirements.

The decisive difference to the productive webhook extensions lies in the access pattern: the sample project demonstrates both read and write transactions via the service layer. An AI agent could therefore not only query data via this, but also create or modify documents. So that an agent does not thereby uncontrolled bookings undertakes, the sample project provides three mechanisms according to the documentation:

Access tokens via the SAP Business One identity and authentication service: It is based on Keycloak and can be integrated with other identity providers
Logging of security-relevant events: The MCP server writes write confirmations, session starts and expirations, and failed logins to a rotating log file by default
Validated permissions: The service layer compares the token's roles and permissions with the SAP Business One authorisation model. If it denies access, the sample server reports an error to the AI agent and returns no data.

Anyone wishing to make productive use of the writing AI interface must therefore adopt and adapt the architecture of the example project themselves. SAP does not, therefore, provide a ready-made MCP server, but rather a template for users’ own implementations.

BizObjProps and DeliveryDetails: Fewer queries per event

A key technical problem with previous webhooks was the so-called N+1 problem. Webhooks previously only delivered the object key of an event. For every further detail, the recipient therefore had to initiate a separate, individual query. This led to many individual queries and unnecessary network load.

with BizObjProps will the service layer send selected fields directly in the event in future, instead of just passing the key. This enrichment of the payload reduces the number of subsequent queries. In addition, FP 2608 introduces Delivery Details Status information on delivery and failed attempts ends up directly in the payload. This speeds up troubleshooting during integrations and reduces network load.

FilterExpr and app.Name: Controlled triggering of events

To avoid unnecessary data traffic, FP 2608 executes the conditional webhook logic FilterExpr a. An event will therefore only fire if previously defined mathematical, temporal or string conditions are met, such as with functions like UPPER, ROUND or TODAY.

Additionally, the context variable is available app.Name is available. According to the SAP documentation, it determines the process name of the calling application without the file extension, for example SAP Business One for the desktop client or httpd for the service layer itself. This gives rise to a possible use case: Incorrectly configured webhooks can lead to event loops if Application A updates a record and the associated webhook consequently triggers another call to Application A. Via app.Name the calling application can be identified and such a circular call can be ruled out in the filter expression. SAP itself does not explicitly describe this use case in the documentation; it follows from the variable’s basic function.

Automatic integration of custom objects

Traditional middleware often comes up against a fundamental problem: every new user-defined field requires the code to be adapted manually, because the data schema is assumed to be rigid. The MCP server in the example project binds user-defined objects (UDO), tables (UDT) and fields (UDF) automatically alongside the standard entities, no additional configuration is required for this.

Apart from that, the example project organises access to entities in general in three steps: b1_find_entities identifies suitable entities, b1_get_entity_schema provides their schema, and b1_read respectively b1_write carry out the read or write operation.

The service layer as the basis for two different implementation levels

Overall, FP 2608 provides two different building blocks for the use of AI agents at the service layer. Firstly, production-ready webhook extensions that generate fewer queries per event and precisely control the triggering of events. Secondly, a sample project that demonstrates how to achieve write-enabled AI access via the Model Context Protocol.

For architects and integrators, the focus is accordingly shifting in two directions. The revised webhook filtering logic is already replacing some of the connection code previously required in the middleware. By contrast, write-access AI via the service layer and the automatic integration of custom objects remain reference architecture for now: anyone wanting to use them in production must study the published sample project and build their own implementation on top of it.

Sources: 
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.