Connect a custom SAP OData service to an AI agent | Agentic ERP Quickstart
Read the real service contract instead of guessing from the service name. What an AI accelerator can scaffold here, and the five things it cannot do for you.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 13Connect a custom SAP OData service to an AI agent | Agentic ERP Quickstart This article
Connect a custom SAP OData service to an AI agent | Agentic ERP Quickstart
The slow part of connecting a custom SAP service to an agent is not the application code. It is getting a service that is active, authorized, and safe to call, and that work sits with your SAP team on their timeline. Once the service exists the application side moves quickly, and an AI coding assistant moves it faster still. The boundary between those two halves is where these projects go wrong, because a scaffolded configuration file looks exactly like a working integration right up to the first real call.
Series: Building governed ERP agents on AWS · Series guide →
This post: How to connect a validated custom SAP service to the agent, and exactly where the application's help starts and stops.
Prereq: A custom OData service that is already active, authorized, and safe to test in a non-production SAP environment, plus a validated external AWS for SAP MCP Server deployment.
What you get from this post
A clear line between two kinds of work. Your SAP team owns the service contract. The application side owns everything after it. Most of the frustration in this task comes from starting the second half before the first half is really finished.
You also get:
- A readiness check to run before you touch any configuration.
- How to read the real service contract instead of guessing it from a service name.
- What an AI accelerator can scaffold here, and the five things it cannot do.
- Why enabling a read tells you nothing about whether a write is allowed.
Time: about 11 minutes to read.
IMPORTANT
This post does not cover SAP-side service creation, ABAP tooling, or clean-core compatibility, and it does not claim a delivery time. Those need SAP expertise and evidence this post does not have.
New to this series? Start here
The Agentic ERP Automation Quickstart is an open source reference implementation that deploys an AI agent for work your team does by hand from a written procedure, on Amazon Bedrock AgentCore. Accounts payable is the worked example, where a case looks like an invoice that does not match its purchase order. A new process type is a skill directory and your own SOPs. Six terms recur below:
- OData is the REST-style protocol SAP uses to expose data. A custom OData service is one your organization built rather than one SAP shipped.
- Metadata is the machine-readable description of a service: its entity sets, keys, fields, and relationships.
- The AWS for SAP MCP Server is a separate AWS-provided runtime that gives the agent its SAP tools. You deploy it yourself. MCP is the Model Context Protocol, the standard the agent uses to call tools.
- Kiro is an AI development environment. This repository ships a local Kiro "power" that can scaffold the application-side files for a new use case.
- A poller is the scheduled component that reads SAP and turns records into cases the agent can work on.
- On-behalf-of, often written OBO, is a token exchange that lets SAP see the individual signed-in person instead of a shared technical account.
Why the service boundary comes first
A custom OData service is an API contract, not another configuration string. Before an agent can use it, someone with SAP expertise has to settle its semantics, its authorization model, its fields, its keys, its navigation properties, its filters, and its lifecycle behavior.
This repository does none of that. It does not create, deploy, or validate custom ABAP services, and it has no homegrown SAP Lambda path. It reaches SAP exclusively through the external AWS for SAP MCP Server.
So the split looks like this:
| Owned by your SAP team | Owned by the application side |
|---|---|
| Service design, activation, and lifecycle | Skill configuration and SOP mapping |
| Authorization model and role assignment | Poller configuration and case fields |
| Field, key, and navigation semantics | Case schema, generated types, frontend display |
| SAP-side review and testing | Read-only functional testing of the agent path |
Step 1: Prove the service is ready before you configure anything
Work with the SAP owner to confirm two things: the service is active, and the identity you will test with is authorized for the read operations you intend. Use a non-production environment and a narrow test dataset.
Then confirm the AWS side. The external AWS for SAP MCP Server is a reference integration, which means you validate it in your own AWS account against your own SAP environment. Check its stack, its identity configuration, and its invocation path before you trust any result it returns.
IMPORTANT
Start the external runtime read-only. Its read and write enablement comes from CloudFormation parameters and runtime flags on the external SAP MCP stack. It is not controlled by this application'strigger-modesetting, and the two are easy to confuse.
Step 2: Read the real contract
Use the external MCP discovery tools against the actual service, in this order:
find_sap_servicesto confirm the service identifier.get_metadataorget_service_hintsto identify entity sets, keys, fields, navigation properties, and annotations.- A narrow
odata_readagainst a redacted or test-only set of records. - Write down the filters, keys, and fields that will produce an actionable exception case.
Do not infer a contract from a service name. Metadata is what tells you the entity set and the fields your poller configuration and your SOP have to use. Guessing here produces configuration that validates and then returns nothing.
Step 3: Scaffold the application side, with Kiro or by hand
The local
@add-use-case power can accelerate the application-side changes. It discovers service metadata at runtime, collects your domain requirements, and scaffolds five reviewable artifacts:- A skill configuration and a domain-only prompt.
- A starter SOP draft.
- A configuration-driven poller definition.
- Case-schema additions and generated types.
- Frontend domain metadata and field mappings.
Kiro is not a prerequisite. The same workflow is documented in the use-case and skill extension guides, and doing it by hand produces the same files.
Either way, a person still has to review the generated configuration, refine and approve the SOP, deploy the change, and test it against real or approved mock cases.
WARNING
The accelerator does not create the SAP service, activate it, change SAP authorizations, deploy the application, or prove your business workflow is correct. Treat every generated file as a draft that has not been reviewed.
Step 4: Check the configuration boundary and validate
A custom service fits the existing extension model, with each piece naming a different part of the contract:
| File | What it names |
|---|---|
| Skill configuration | The SAP service, and which process types map to which SOPs |
| SOP | The entity set or endpoint, preconditions, fields, decision rules, and escalation behavior |
| Poller configuration | The service, entity, filters, iteration pattern, process-type rules, and field mappings |
| Shared schema and frontend mapping | The domain and its case fields |
Validate before deploying. These are contributor tooling rather than the reader-facing launcher, and you need them here because you are editing repository files:
1
2
3
make generate-types
make test
make validateThe generator validates your poller configuration against the shared case schema and catches mismatched domain values and invalid field-map keys. It does not test the SAP contract, and it cannot review your SOP or your configuration for you.
Step 5: Synchronize, deploy, and test the read path
After review, synchronize the SOP content and deploy the configuration:
1
2
python3 launch.py sync-kb --only sops
python3 launch.py deployWARNING
Both commands change AWS resources or corpus content. Check the target account and Region first. SOP synchronization can remove remote corpus objects that have no local counterpart, and starting ingestion does not prove it has completed.
Then test the smallest safe path, in this order:
- The poller or test case produces the process type you expect.
- The agent loads the mapped skill and SOP.
- The agent uses the intended custom service and entity set for a read-only operation.
- Skips, duplicate removal, field mapping, case display, and escalation all behave correctly with approved test data.
Step 6: Treat a write as a separate decision
A configuration that can call a service is not permission to write through it. That holds whether Kiro generated the configuration or you wrote it yourself.
Write exposure is governed by the external SAP MCP deployment's
MCP_SERVER_WRITE_ENABLED setting and its per-operation flags, plus SAP-side authorization for the effective identity.Cedar can add a policy layer on top, but only on a covered Gateway target that has an associated policy engine with enforcement set to
ENFORCE. The direct on-behalf-of path does not go through this project's Gateway, so Gateway Cedar is not its write control at all. The Cedar policy post covers those conditions.One more distinction worth keeping straight:
trigger-mode controls whether unattended work starts. It is not a write authorization switch. The autonomy control post explains what it does and does not change.Whatever your topology, validate the environment and the business approval flow before you enable and test a write.
Trade-offs
- What you gain. Once the service contract exists, the application side is configuration, and an accelerator can draft most of it.
- What you give up. The hard part stays with SAP, and no amount of application tooling shortens it.
- What the design does not promise. A working read path says nothing about write authorization, and generated configuration is not reviewed configuration.
Where to go next
- Adding a new exception type . The same extension model, without a custom service in the picture.
- How an agent loads its procedure . What happens to the procedure you mapped.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 13Connect a custom SAP OData service to an AI agent | Agentic ERP Quickstart This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article