How do you turn an SAP query answer into a shareable report?
Josue Ramirez
Last updated: August 2026
Getting an answer from your data is one thing. Turning that answer into something you can actually share — a structured report for the director, a summary for the weekly review, a table the operations team can act on — is a different problem entirely.
Most business users solve that problem the same way: they wait for someone to pull the data, copy numbers into a spreadsheet, build a document on top of it, and send it. The whole cycle can take days. And when something changes and the numbers need to be refreshed, you start over.
Artifacts in ASK Chat are designed to change that workflow. You describe the document you need and the system builds it, pulling the data from your company's systems, structuring it, generating the analysis, and leaving you with something ready to share.
Why is the last mile where SAP analytics dies?
Every SAP analytics project I have seen budgets for the pipeline and forgets the last mile.
The pipeline part is well understood by now. Onibex One Connect, a real-time SAP data streaming platform, moves business events out of SAP ECC and SAP S/4HANA into Apache Kafka, serialized as Avro, registered in a schema registry, and landed in Confluent and downstream systems. That part has a clean architecture and measurable latency.
Then a human being asks a question, gets a number, and has to turn that number into something a person with a budget will act on. There is no pipeline for that. There is a person with a spreadsheet and a deadline.
The reason this last mile is so expensive is that it is not automatable on top of raw tables. If your answer came out of VBAK, the document you build from it has to carry the knowledge that VBAK is a sales order header, that its line items live somewhere else, and that a currency field is not just a number. That knowledge lives in a person's head, so the document has to be rebuilt by a person every time.
What is an SAP data product?
An SAP data product is a business object modeled as a complete, queryable unit: a sales order with its line items, a billing document with its accounting entries, named the way the business names it rather than the way the database stores it.
Four communities call this same thing four different names. SAP calls it a business object. Event driven architecture calls it an entity. Graph people call it a node. The data discipline calls it a data product, which is the term worth keeping, because it is the only one of the four that implies someone is responsible for its quality.
This matters for documents specifically. A document generated from a data product can be regenerated, because the structure it depends on is stable and named. A document generated from a raw table extract cannot, because the next person has to rediscover the joins.
How do you turn a natural language question into a document?
Onibex ASK, an agentic semantic layer over SAP data products, is where we put this. The interesting design decision was to make document creation a conversation rather than a form.
Four questions: what do you want to call this, who is going to read it, what data should it focus on, and what shape should it take. That is the entire setup. The audience question is the one that does the most work, because it changes what gets emphasized rather than just what gets styled.
The shape question maps to four formats, and the difference between them is editorial, not visual.
| Format | Structure | Best for |
|---|---|---|
| Detailed Report | Full narrative, tables and charts | Periodic reporting where the reader needs context, not just numbers |
| Executive Brief | Short, high-level summary with key takeaways | Senior stakeholders who need the point, fast |
| Data Tables | Structured tables with aggregations and a summary | When the data itself is the deliverable |
| Proposal Format | Data framed as a recommendation | When the document needs to argue a point or support a decision |
Generated documents land in a searchable library, filterable by type, which is a small detail that turns out to matter more than the generation itself. A report you can find again is a report you can update instead of rebuild.
What does the generated document actually contain?
Two views, and the split is deliberate.
The document view holds the finished artifact: structured tables, narrative written against the actual figures rather than around them, and key findings as bullets. The data view holds the underlying datasets on their own, with row counts, table and chart views, and the ability to keep asking questions of the same data without leaving the document.
Four actions stay available: copy, download every dataset to Excel, edit the parameters, and regenerate. There is also a SQL override field, which exists because sooner or later someone who knows their data better than any model does needs to say exactly what to fetch. Leaving that door open is not a failure of the semantic layer. It is what makes the semantic layer trustworthy.
Why is regenerate the feature, not generate?
Generating a report once is a party trick. Most enterprise reporting is not a one time act, it is the same report every Monday with new numbers.
Because the structure, audience, and focus are saved as parameters, regeneration reruns the document against current data instead of rebuilding it from scratch. The weekly report becomes one click, and the person who used to spend Monday morning on it spends it on something else.
This is also where the streaming layer stops being an abstraction. If SAP data arrives through business events in near real time rather than through an overnight batch, regenerating on Monday at 8am means Monday at 8am, not Friday at close.
What does this not solve?
It does not remove the need for someone to know whether the question was the right question. A well formatted document built on a misunderstood metric is worse than no document, because it travels further.
It also does not remove the modeling work. The data product layer has to exist first. Onibex ships more than 150 pre-packaged SAP data products so most teams start from something rather than nothing, but a company with heavily customized Z tables is going to model (Onibex product documentation, 2026).
The honest framing is narrower than "AI writes your reports." It is this: once your SAP data exists as data products and streams in real time, the step from question to shareable document stops being human labor. That is one step out of many, and it happens to be the one that everybody was quietly eating with overtime.
Frequently asked questions
What is Onibex ASK?
Onibex ASK is an agentic semantic layer that sits over SAP data products, so a business user can ask a question in plain language and get an answer grounded in modeled business objects rather than raw tables. Because the layer is semantic, the same question can also be turned into a document that regenerates against current data.
What is an SAP data product?
It is a business object modeled as a complete queryable unit, such as a sales order with its line items, named in business terms. It is the same concept SAP calls a business object, event driven architecture calls an entity, and graph modeling calls a node.
Can AI agents read directly from SAP without custom APIs?
Not usefully, and not from the database. SAP does not allow direct database access, so log based change data capture is off the table. The practical route is SAP business events at the business object level, streamed out through Apache Kafka.
Does the document stay current when the SAP data changes?
Only if you regenerate it. The parameters are saved, so regeneration reruns against current data. How current that data is depends on the pipeline underneath, which is why real time streaming and document generation are the same conversation.
Can you export the underlying data, not just the document?
Yes. Every dataset behind the document downloads to Excel, and the SQL override field lets someone specify exactly what to fetch when they know the data better than the model does.
How many SAP data products do you have to model yourself?
Onibex ships more than 150 pre-packaged SAP data products covering standard SD, MM, and FI objects, so a standard implementation starts from those (Onibex product documentation, 2026). Custom Z tables have to be modeled, and that modeling is the prerequisite for everything above it.
The semantic layer specification, the platform code, and the manual are on GitHub, so if your SAP data already streams and the reporting last mile is still manual you can see how this is put together: github.com/Onibex/agentic-semantic-knowledge-ask