The Problem
We wanted to enhance our custom Joule agent in SAP Joule Studio which is being used for ABAP development capable of answering questions about internal development policies, naming convention and broader custom development governance guidelines documents and technical specifications, all stored in Microsoft SharePoint.
The natural starting point was the Joule Studio/Build Control Tower, which provides a UI-driven setup for document grounding. However, we quickly hit a wall: the Control Tower wizard only supports AWS S3 (Object Store) as the document repository. If you want to use SharePoint, the wizard offers no path forward. This leaves enterprise customers who have no S3 infrastructure — and no intention of setting one up — with no obvious route to grounding their Joule agents in SharePoint content.
The alternative is to build the grounding pipeline directly using the SAP AI Core Pipeline API, bypassing the Control Tower entirely. This approach fully supports SharePoint, gives you precise control over which folders are indexed, and produces a pipeline that can be exposed as a Joule Skill and added as a tool to any custom Joule agent in SAP Build.
The documentation for this approach is scattered, inconsistent across versions, and contains several undocumented gotchas. This post documents the exact steps that work.
The Solution
What You Need
- SAP AI Core Extended plan (grounding is not available on Free or Standard)
- Microsoft Entra App Registration with Sites.Read.All and Files.Read.All Graph API permissions. Follow Prepare SharePoint Integration with Joule.
- A service account with SharePoint read access
Step 1 — Resource Group with the Correct Label
Create a resource group with the grounding label. Many tutorials use the short-form label — it is wrong. Use the full key: ( I had to use full key)
POST /v2/admin/resourceGroups
{
"resourceGroupId": "Document-Grounding",
"labels": [{ "key": "ext.ai.sap.com/document-grounding", "value": "true" }]
}
Step 2 — Create a Generic Secret for SharePoint
The secret stores your Microsoft Graph API credentials. Field names must be exact — user not username, tokenServiceURL not tokenUrl. ( Get the details from sharepoint admin)
All values must be Base64 encoded (on Windows use PowerShell):[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("value"))).
POST /v2/admin/secrets
AI-Resource-Group: Document-Grounding
{
"name": "sharepoint-secret",
"data": {
"url": "<base64(https://graph.microsoft.com)>",
"authentication": "<base64(OAuth2Password)>",
"user": "<base64([email protected])>",
"password": "<base64(password)>",
"clientId": "<base64(entra-app-client-id)>",
"clientSecret": "<base64(entra-app-client-secret)>",
"tokenServiceURL": "<base64(https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token)>"
},
"labels": [
{ "key": "ext.ai.sap.com/document-grounding", "value": "true" },
{ "key": "ext.ai.sap.com/documentRepositoryType", "value": "MSSharePoint" }
]
}
Both labels are mandatory. Without them, the pipeline cannot locate the secret.
Step 3 — Create the Pipeline
POST /v2/lm/document-grounding/pipelines
AI-Resource-Group: Document-Grounding
{
"type": "MSSharePoint",
"configuration": {
"destination": "sharepoint-secret",
"cronExpression": "0 0 * * *",
"sharePoint": {
"site": {
"name": "YOUR-SITE-NAME",
"includePaths": ["/YourFolder"]
}
}
}
}Always use includePaths. Without it, the pipeline attempts to index the entire site including hidden system libraries, leading to failures and irrelevant retrieval results.
The destination field is the AI Core Generic Secret name — not a BTP Destination. This is the single most confusing point in the documentation.
Step 4 — Trigger and Monitor
POST /v2/lm/document-grounding/pipelines/trigger
{ "pipelineId": "<your-pipeline-id>", "metadataOnly": false }Note: the pipeline ID goes in the request body, not the URL. Check status at /pipelines/{id}/status until it shows FINISHED. Only PDF, DOCX, TXT, and MD files are supported — Excel and PowerPoint files cause silent failures.
Step 5 — Query
POST /v2/lm/document-grounding/retrieval/search
AI-Resource-Group: Document-Grounding
{
"query": "your natural language question",
"filters": [{ "id": "<pipeline-id>", "dataRepositoryType": "vector" }],
"maxResults": 5
}The dataRepositoryType: "vector" field is required — omitting it returns a 400 error.
Step 6 — Expose via SAP Build
Wrap the retrieval endpoint in a SAP Build Action (upload an OpenAPI spec), then create a Joule Skill that calls it. Add the skill as a tool to your custom Joule agent.
Custom Action
Conclusion and Advantages
Building document grounding directly against SharePoint using the AI Core Pipeline API gives you a clean, enterprise-ready RAG pipeline with several advantages:
No S3 required — your documents live where they already are. No migration, no sync jobs, no additional object store costs.
Folder-scoped indexing - includePaths lets you ground your agent against a specific document set rather than an entire site, giving you precise control over what the LLM can retrieve.
Automatic re-indexing — the cron expression keeps your vector store current without any manual intervention.
Native SAP integration — the retrieval endpoint plugs directly into SAP Build Actions and Joule Studio, making it a first-class tool for custom Joule agents.
Separation from Joule Studio Control Tower — the Control Tower UI creates its own pipelines and does not support folder scoping. The direct API approach gives you full control.
The key takeaways: Use the Extended AI Core plan, get the Generic Secret field names exactly right, always scope to a folder with includePaths, and remember the pipeline trigger takes its ID in the body. Everything else follows the documentation
AI Core API References : https://help.sap.com/docs/sap-ai-core/generative-ai/grounding-035c455a5a424697b60f4a24b6d791fe
Note: Generative AI used to format the text meaningfully.
Bluesky
