\n\n

Technical Document · EWM-AIH-001

SAP EWM × AI Hive Integration

A demonstration, bit by bit, of how a SAP Extended Warehouse Management simulation is connected to a Dify AI agent through a token-aware chunking pipeline, and how that pipeline lets the agent reason over datasets too large for any single prompt.

Version

1.0

Issued

2026-05-22

Status

Released

Audience

Engineering

\n\n\n\n

1Introduction

\n\n

Abstract

\n This document walks through every piece of the EWM × AI Hive integration in execution order. Each component is described, then exercised with a real request and the real response captured from the live system. The reader should be able to reproduce every example by running the curl command provided.\n

\n\n

1.1Purpose

The integration solves a single problem: a Dify agent answering questions about a SAP EWM system that contains far more records than fit in any one LLM prompt. The agent must therefore (a) classify the user's intent, (b) decide whether the answer needs many records or few, and if many, (c) chunk those records, (d) iterate or stitch, and (e) synthesise.

\n\n

1.2Scope

Four deployed Val Town apps form the integration. This document covers each one in sequence, then the Dify workflow that consumes them, then a full end-to-end walkthrough. APIs are documented at the level of real request/response pairs, not narrative description.

\n\n

1.3Conventions

\n\n \n \n \n \n \n \n \n

Symbol	Meaning
`${BACKEND.replace('https://','').replace('vlduy123--','').slice(0, 22)}...`	Long Val Town URLs are abbreviated to the leading host fragment. The full URL appears in linked examples.
`—`	NULL or empty value in a captured response.
`$top`, `$skip`	OData v4 query parameters, used here for pagination.
Note	Inline notice block — informational, warning, or operational.

\n\n\n\n

2System Architecture

\n\n

Abstract

\n Four Val Town apps and one external AI orchestrator. Data flows unidirectionally: mock generates, backend persists, dashboard reads, Dify consumes.\n

\n\n

2.1Component Inventory

\n\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

#	Component	Identifier	Type	Role
1	`ewmMockServer`	vlduy123/ewmMockServer	Hono HTTP	Generates SAP EWM data on demand. Authoritative source.
2	`ewmBackend`	vlduy123/ewmBackend	Hono HTTP + SQLite	Persists snapshots from the mock; exposes data, chunking, statistics APIs.
3	`ewmDashboard`	vlduy123/ewmDashboard	OpenUI5 SPA	Fiori-styled UI. Calls only the backend.
4	`ewmDocs`	vlduy123/ewmDocs	Static HTML	Reference documentation site (API reference, troubleshooting).
—	Dify chatflow	external	Workflow YAML	The AI agent. Calls the backend's REST APIs.

Table 2.1Component inventory. All Val Town apps are public.

\n\n

2.2Data Flow

\n\n

┌──────────────────────┐\n │ ewmMockServer │ Generates SAP EWM data\n │ /api/ewm/<entity> │ ~11.5M virtual records\n └─────────┬────────────┘\n │ X-API-Key\n ▼\n ┌──────────────────────┐ ┌────────────────────┐\n │ ewmBackend │ ─────► │ Val Town SQLite │\n │ Hono + SQLite │ ◄───── │ plants │\n │ │ │ warehouses │\n │ POST /api/seed │ │ entity_records │\n │ POST /api/ingest │ │ chunks │\n │ GET /api/data │ │ ingest_runs │\n │ GET /api/chunks │ │ seed_runs │\n └─────┬──────────┬─────┘ └────────────────────┘\n │ │\n ┌────▼────┐ ┌──▼─────────────────┐\n │ Fiori │ │ Dify Chatflow │\n │ Dashbd │ │ (AI Hive) │\n │ (UI5) │ │ reads /api/chunks │\n └─────────┘ └────────────────────┘\n

Figure 2.1Data flow. Solid arrows: HTTP. SQLite is the single source of state for persisted data.

\n\n

2.3SAP Landscape Mapping

\n\n \n \n \n \n \n \n \n \n \n

Real SAP	This Integration
S/4HANA system (ABAP + HANA DB)	`ewmBackend` (Hono + Val Town SQLite)
EWM source data (transactions, master)	`ewmMockServer`
Fiori Launchpad / NetWeaver Gateway	`ewmDashboard` (OpenUI5 + Horizon)
SAP Help Portal	`ewmDocs`
SAP Integration Suite / CPI	Dify HTTP nodes calling the backend
SAP Build Process Automation	Dify chatflow that reads `/api/chunks`

Table 2.2One-to-one mapping between SAP landscape components and the corresponding integration components.

\n\n\n\n

3Component — Mock Data Source

\n\n

Abstract

\n ewmMockServer is a Hono HTTP val that deterministically generates SAP EWM records on every request. It is the only \"production-realistic\" component, in the sense that its outputs match the field shapes a real EWM OData feed would produce.\n

\n\n

3.1Role

The mock server stands in for a real SAP EWM system. It generates six transactional entities and exposes two master-data endpoints. All endpoints require an X-API-Key header. The mock has no persistence — every request regenerates the slice of data on the fly using a seeded random generator, so the same query always returns the same records.

\n\n

3.2Sample Request

\n\n

GET${MOCK}/api/ewm/WarehouseOrders?$top=1

curl -H \"X-API-Key: ewm-demo-key-aihive-2025\" \\\\\n  \"${MOCK}/api/ewm/WarehouseOrders?\\\\$top=1\"

Listing 3.1 Fetch the first warehouse order. $top is escaped in shell.

\n\n

3.3Sample Response

\n\n

200 OKapplication/json

{\n  \"@odata.context\": \"$metadata#WarehouseOrders\",\n  \"@odata.count\": 3000000,\n  \"@odata.nextLink\": \"?$skip=1&$top=1\",\n  \"value\": [\n    {\n      \"WarehouseOrderID\": \"WO-PL01-WH1-0000001\",\n      \"WarehouseNo\": \"PL01-WH1\",\n      \"PlantID\": \"PL01\",\n      \"Country\": \"SG\",\n      \"Region\": \"APAC\",\n      \"WarehouseType\": \"Manufacturing\",\n      \"Activity\": \"Counting\",\n      \"SourceBin\": \"GI-04-15-2\",\n      \"DestinationBin\": \"HZ-04-10-5\",\n      \"Product\": \"MAT-0175\",\n      \"ProductDesc\": \"SEAL Component 0175\",\n      \"ProductCategory\": \"SEAL\",\n      \"Quantity\": 4565,\n      \"Unit\": \"EA\",\n      \"Status\": \"Open\",\n      \"Priority\": \"HIGH\",\n      \"WaveID\": \"WAVE-PL01-WH1-045950\",\n      \"CreatedAt\": \"2025-04-05T08:05:00.000Z\",\n      \"DueBy\": \"2025-05-19T05:30:00.000Z\",\n      \"SAPDocumentNo\": \"4904514796\"\n      // ...26 more fields...\n    }\n  ]\n}

Listing 3.2 Captured response, abbreviated. The full record has 36 fields; @odata.count reports the entire virtual dataset size (3,000,000).

\n\n

3.4Generated Volumes

\n\n \n \n \n \n \n \n \n \n \n

Entity	Virtual Volume	ID Field
WarehouseOrders	3,000,000	WarehouseOrderID
TransferOrders	2,500,000	TransferOrderID
StockPositions	1,500,000	—
InboundDeliveries	1,000,000	InboundDeliveryID
OutboundDeliveries	1,200,000	OutboundDeliveryID
Waves	300,000	WaveID (each contains nested PickingTasks)

Table 3.1Mock dataset sizes. Total ~9.5 M transactional records plus 5 plants and 15 warehouses.

\n\n

Note

\nThe mock is the only component that does not maintain state. Every request is deterministic given the same parameters but is computed fresh — there is no database. This makes the mock cheap to scale and removes seeding concerns from its design.\n

\n\n

\n\n\n\n

4Component — Backend

\n\n

Abstract

\n ewmBackend is the gateway between the mock and every downstream consumer. It owns the SQLite database, exposes paginated read APIs, runs the seeding pipeline that copies data from the mock into SQLite, and runs the four chunking strategies used by the AI agent.\n

\n\n

4.1Database Schema

\n\n

Six tables, all created on first use via CREATE TABLE IF NOT EXISTS.

\n\n

plants

\n\n \n \n \n \n \n \n \n

Column	Type	Notes
`id`	TEXT PRIMARY KEY	e.g. `PL01`
`name, country, region, currency`	TEXT	Denormalised for index lookups
`data`	TEXT	Full JSON record (JSON1 queryable)
`updated_at`	TEXT	`datetime('now')`

\n\n

warehouses

\n\n \n \n \n \n \n \n

Column	Type	Notes
`id`	TEXT PRIMARY KEY	e.g. `PL01-WH1`
`plant_id, plant_name, type, country, region`	TEXT	Denormalised
`data`	TEXT	Full JSON including `zones` array

\n\n

entity_records

\n\n \n \n \n \n \n \n \n

Column	Type	Notes
`(entity, record_id)`	PRIMARY KEY	Composite
`warehouse_id`	TEXT	Indexed
`plant_id, status`	TEXT	Status indexed
`data`	TEXT	Full JSON of the original record

Table 4.1Generic table holding every transactional record. Indexes: (entity, warehouse_id), (entity, status).

\n\n

chunks, ingest_runs, seed_runs

Audit and AI-prep tables. chunks holds the output of the chunking pipeline; ingest_runs is one row per chunking job; seed_runs is one row per seed job.

\n\n

4.2Seeding Pipeline

\n\n

Seeding copies data from the mock into entity_records in two stages.

\n\n

Stage A — Master Data. Pulls plants and warehouses (small datasets).

\n\n

POST/api/seed/master

curl -X POST ${BACKEND}/api/seed/master -d '{}'\n\n→ { \"ok\": true, \"plants\": 5, \"warehouses\": 15 }

\n\n

Stage B — Transactional Entity. Pulls one entity, optionally scoped to a warehouse, up to limit rows.

\n\n

POST/api/seed

curl -X POST ${BACKEND}/api/seed \\\\\n  -H \"Content-Type: application/json\" \\\\\n  -d '{\"entity\":\"WarehouseOrders\",\"warehouseId\":\"PL01-WH1\",\"limit\":50}'\n\n→ { \"ok\": true, \"entity\": \"WarehouseOrders\",\n    \"warehouseId\": \"PL01-WH1\", \"inserted\": 50, \"seedId\": \"1\" }

Listing 4.1 Seed 50 warehouse orders for warehouse PL01-WH1.

\n\n

Constraint

\nVal Town caps each request at 30 seconds. Seeding more than ~2,000 records in one call will exceed that. The dashboard's Data Management page enforces this limit in the UI; the API does not.\n

\n\n

Inspection

\n\n

Current SQLite contents at the moment this document was generated:

\n\n

GET/api/seed/stats

{\n  \"byEntity\": [\n    { \"entity\": \"OutboundDeliveries\", \"n\": 30,   \"latest\": \"2026-05-22 08:49:46\" },\n    { \"entity\": \"WarehouseOrders\",    \"n\": 1180, \"latest\": \"2026-05-22 09:01:56\" }\n  ],\n  \"warehouses\": 15,\n  \"plants\": 5,\n  \"runs\": [\n    { \"id\": 3, \"entity\": \"OutboundDeliveries\", \"warehouse_id\": \"PL01-WH1\",\n      \"limit_param\": 30, \"inserted\": 30, \"status\": \"done\", ... },\n    { \"id\": 1, \"entity\": \"WarehouseOrders\", \"warehouse_id\": \"PL01-WH1\",\n      \"limit_param\": 50, \"inserted\": 50, \"status\": \"done\", ... }\n  ]\n}

\n\n

4.3Endpoints

\n\n

\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Method	Path	Purpose
`GET`	`/api/health`	Liveness probe
`GET`	`/api/entities`	Allowed entity + strategy names
`GET`	`/api/warehouses`	All warehouses (from SQLite)
`GET`	`/api/plants`	All plants (from SQLite)
`GET`	`/api/products`	Distinct products from `entity_records` via JSON1
`POST`	`/api/seed/master`	Seed plants + warehouses
`POST`	`/api/seed`	Seed one entity
`GET`	`/api/seed/stats`	Per-entity counts + recent seed runs
`GET`	`/api/data/:entity`	Paginated SQLite read (OData shape)
`POST`	`/api/ingest`	Run a chunking pipeline
`GET`	`/api/runs`	Ingest run history
`DELETE`	`/api/runs/:id`	Delete a run + its chunks
`GET`	`/api/chunks`	List chunks (filterable, optional payload)
`GET`	`/api/chunks/:id`	Single chunk including payload
`GET`	`/api/stats`	Aggregate chunking stats
`GET`	`/api/inbox`	Recent ingest + seed activity feed

Table 4.2Backend endpoints. All return JSON. CORS open. No auth on backend itself.

\n\n

Sample: `/api/data/:entity`

\n\n

GET${BACKEND}/api/data/WarehouseOrders?$top=2

{\n  \"@odata.context\": \"$metadata#WarehouseOrders\",\n  \"@odata.count\": 1180,\n  \"value\": [\n    {\n      \"WarehouseOrderID\": \"WO-PL01-WH1-0000001\",\n      \"WarehouseNo\": \"PL01-WH1\",\n      \"Product\": \"MAT-0175\",\n      \"ProductDesc\": \"SEAL Component 0175\",\n      \"Quantity\": 4565,\n      \"Status\": \"Open\",\n      \"Priority\": \"HIGH\",\n      \"WaveID\": \"WAVE-PL01-WH1-045950\",\n      \"CreatedAt\": \"2025-04-05T08:05:00.000Z\"\n      // ... 27 more fields elided\n    },\n    { \"WarehouseOrderID\": \"WO-PL01-WH1-0000002\", ... }\n  ]\n}

\n\n

Sample: `/api/products`

\n\n

GET${BACKEND}/api/products

{\n  \"@odata.count\": 468,\n  \"value\": [\n    { \"id\": \"MAT-0217\", \"name\": \"RELAY Component 0217\",  \"category\": \"RELAY\",  \"occurrences\": 8 },\n    { \"id\": \"MAT-0065\", \"name\": \"SENSOR Component 0065\", \"category\": \"SENSOR\", \"occurrences\": 7 },\n    { \"id\": \"MAT-0366\", \"name\": \"CABLE Component 0366\",  \"category\": \"CABLE\",  \"occurrences\": 7 },\n    { \"id\": \"MAT-0388\", \"name\": \"FILTER Component 0388\", \"category\": \"FILTER\", \"occurrences\": 7 },\n    { \"id\": \"MAT-0438\", \"name\": \"SWITCH Component 0438\", \"category\": \"SWITCH\", \"occurrences\": 7 }\n    // ... 463 more\n  ]\n}

Listing 4.2 Derived from entity_records via json_extract(data, '$.Product') + GROUP BY.

\n\n

4.4Chunking Strategies

\n\n

Four strategies are implemented. Each produces rows in the chunks table with a JSON payload ready to ship to an LLM.

\n\n

\n\n \n \n \n \n \n \n \n

Strategy	Output	Use When
`per-record`	One chunk per record	Each record is independent (e.g. embedding into a vector store)
`group-warehouse`	One chunk per warehouse_id	Per-warehouse summaries or comparisons
`token-budget`	Pack records up to N tokens	Filling an LLM context window without splitting a record
`field-window`	Split nested arrays into N-item windows	Records too big to fit in one chunk (e.g. Waves)

Table 4.3Chunking strategy catalogue. Token estimation uses ceil(len(JSON.stringify(record)) / 4).

\n\n

Example: a token-budget run.

\n\n

POST/api/ingest

curl -X POST ${BACKEND}/api/ingest \\\\\n  -H \"Content-Type: application/json\" \\\\\n  -d '{\"entity\":\"WarehouseOrders\",\"strategy\":\"token-budget\",\n       \"warehouseId\":\"PL01-WH1\",\"limit\":30,\"tokenBudget\":2000}'\n\n→ {\n  \"run\": {\n    \"run_id\": \"11a1f230-26b1-4884-8001-ae5b9fb6f8ad\",\n    \"entity\": \"WarehouseOrders\",\n    \"strategy\": \"token-budget\",\n    \"warehouse_id\": \"PL01-WH1\",\n    \"token_budget\": 2000,\n    \"record_limit\": 30,\n    \"status\": \"done\",\n    \"total_chunks\": 5,\n    \"total_records\": 30,\n    \"total_tokens\": 7698,\n    \"started_at\": \"2026-05-22 10:53:38\",\n    \"finished_at\": \"2026-05-22 10:53:38\",\n    \"error\": null\n  }\n}

Listing 4.3 30 records → 5 chunks averaging ~1,540 tokens each. None of the chunks exceeded the 2000-token budget.

\n\n

The resulting chunks (payload elided):

\n\n

GET/api/chunks?run_id=11a1f230-…&limit=3

{\n  \"chunks\": [\n    { \"id\": 88, \"chunk_index\": 4, \"record_count\": 2, \"tokens\": 519, ... },\n    { \"id\": 87, \"chunk_index\": 3, \"record_count\": 7, \"tokens\": 1802, ... },\n    { \"id\": 86, \"chunk_index\": 2, \"record_count\": 7, \"tokens\": 1795, ... }\n  ],\n  \"total\": 5\n}

\n\n

Observation

\nThe greedy packer placed 7 records into chunks of 1795–1802 tokens, packed exactly to the budget. The last chunk holds 2 records and 519 tokens — the remainder. Total tokens (7698) divided by 30 records is ~256 tokens/record, consistent with WarehouseOrder size.\n

\n\n

\n\n\n\n

5Component — Fiori Dashboard

\n\n

Abstract

\n ewmDashboard is an OpenUI5 single-page application using the Horizon theme — the same theme SAP S/4HANA Cloud ships with since 2022. It only calls the backend; it holds no data of its own.\n

\n\n

5.1Pages

\n\n \n \n \n \n \n \n \n \n \n \n

Page	Side-nav key	Calls
Home (Launchpad)	`home`	(none)
My Inbox	`inbox`	`GET /api/inbox`
Warehouse Monitor	`browse`	`GET /api/data/:entity`
Data Management	`data`	`POST /api/seed/master`, `POST /api/seed`, `GET /api/seed/stats`
AI Chunking Lab	`ingest`	`POST /api/ingest`
Ingest Monitor	`monitor`	`GET /api/stats`, `GET /api/runs`, `GET /api/chunks`
Master Data → Plants / Warehouses / Products	`master:*`	`GET /api/plants`, `GET /api/warehouses`, `GET /api/products`

Table 5.1Pages and their backend dependencies.

\n\n

5.2Data Flow

\n\n

Browser\n │\n ▼\n ewmDashboard (HTML + UI5 bootstrap)\n │ fetch(BACKEND + \"/api/...\")\n │ same-origin script, cross-origin XHR\n ▼\n ewmBackend (CORS open)\n │\n ▼\n Val Town SQLite\n

Figure 5.1Dashboard never touches the mock directly. Backend mediates and caches.

\n\n

\n\n\n\n

6Component — Dify Workflow

\n\n

Abstract

\n The Dify chatflow exported in ewm-agent-workflow.yml is the AI agent. It classifies user intent into one of six branches, each of which calls the backend and returns a synthesised answer. Branch 5 is special: it handles queries that need too much data to fit in a single LLM prompt.\n

\n\n

6.1Intent Classifier

Model: gpt-4o-mini, temperature 0.1. Single-class output. Six classes, briefly described in Table 6.1.

\n\n

\n\n \n \n \n \n \n \n \n \n \n

Class	Trigger	Example queries
`b1`	Overview / stats	\"How many rows do we have?\", \"Show me system status\"
`b2`	List records	\"List warehouse orders for PL01-WH1\"
`b3`	Product search	\"What products do we have?\", \"Show MAT-0175\"
`b4`	Master data	\"List all warehouses\", \"Show plants in Asia\"
`b5`	Deep analysis (large)	\"Summarise all open orders\", \"Find overdue waves\"
`b6`	Specific record	\"Show me WO-PL01-WH1-0000001\"

Table 6.1Six intents. Empty queries default to b1.

\n\n

6.2Branches

\n\n

Each branch is a linear pipeline: parameter-extraction LLM → HTTP request → formatting LLM → answer node. Branch 5 differs (see §6.3).

\n\n

b1: GET /stats ─► GET /seed/stats ─► LLM format ─► answer\n b2: LLM extract ─► GET /data ─► LLM format ─► answer\n b3: GET /products ─► LLM format ─► answer\n b4: LLM route ─► GET /<master> ─► LLM format ─► answer\n b5: LLM plan ─► POST /ingest ─► Code(run_id) ─► GET /chunks\n ─► Code(concat) ─► LLM synth (Opus) ─► answer\n b6: LLM extract ID ─► GET /data ─► LLM format ─► answer\n

\n\n

6.3Branch 5 — Chunked Analysis

\n\n

Branch 5 is invoked when the user asks for a summary, ranking, or insight over many records. It performs seven steps:

\n\n

Plan — Opus 4.7 reads the user query and returns a JSON config: {entity, strategy, warehouseId, limit, tokenBudget, windowSize}.
Chunk — POST /api/ingest with the plan. Backend runs the strategy in SQLite, persists chunks, returns a run_id + totals.
Extract — JavaScript Code node parses the ingest response and exposes run_id, total_chunks, entity, strategy.
Fetch — GET /api/chunks?run_id=…&payload=1&limit=50 returns up to 50 chunks with payload.
Concatenate — JavaScript Code node stitches up to 30 chunks (cap 120,000 chars) with delimiter headers into a single context string. Cap protects against Opus's 200K context window.
Synthesise — Opus 4.7 reads the stitched context and produces the final answer with chunk-level citations.
Answer — Returned to user with breadcrumb (\"Analysed N records across M/K chunks (run ...)\") so the user can drill into the dashboard.

\n\n

Design choice

\nThe first version of this workflow used a Dify iteration node. It triggered a runtime error (availablePrevNodes undefined) because the iteration DSL pattern differs across Dify versions. The current design replaces iteration with the concat-and-synthesise pattern, which works in all versions and leverages Opus's 200K context to compensate.\n

\n\n

\n\n\n\n

7End-to-End Walkthrough

\n\n

Abstract

\n Two illustrative queries, end to end. The first is simple (single API call). The second is the chunked path.\n

\n\n

7.1Setup

\n\n

Before either walkthrough, the following one-time setup must complete:

\n\n

Open ${DASHBOARD} → Data Management.
Click Seed master data. Expect { ok: true, plants: 5, warehouses: 15 }.
Pick an entity (e.g. WarehouseOrders), pick a warehouse (e.g. PL01-WH1), limit 1000, click Seed.

\n\n

The current snapshot at the moment of writing:

GET/api/seed/stats

{ \"plants\": 5, \"warehouses\": 15,\n  \"byEntity\": [\n    { \"entity\": \"WarehouseOrders\",    \"n\": 1180 },\n    { \"entity\": \"OutboundDeliveries\", \"n\":   30 }\n  ] }

\n\n

7.2Simple Query (b1)

\n\n

User input: \"Give me an overview of the system.\"

\n\n

1. classifier → b1 (overview)\n 2. GET /api/stats (single call, ~50 ms)\n 3. GET /api/seed/stats (single call, ~50 ms)\n 4. LLM format (claude-haiku-4-5, ~600 ms)\n 5. answer\n

\n\n

Final answer (paraphrased from a real test):

The warehouse currently has 1,210 entity rows stored in SQLite — 1,180\nwarehouse orders and 30 outbound deliveries — across 15 warehouses and\n5 plants. AI chunking has produced 83 chunks (236 records, 46,810 tokens)\nover 7 completed runs. No errors or running jobs.

\n\n

7.3Chunked Query (b5)

\n\n

User input: \"Summarise all open warehouse orders for PL01-WH1, highlighting the most overdue.\"

\n\n

1. classifier → b5 (deep analysis)\n 2. LLM plan → {\"entity\":\"WarehouseOrders\",\n \"strategy\":\"token-budget\",\n \"warehouseId\":\"PL01-WH1\",\n \"limit\":2000,\"tokenBudget\":2000}\n 3. POST /api/ingest\n ← {\"run\":{\"run_id\":\"11a1f230-…\", \"total_chunks\":5,\n \"total_records\":30,\"total_tokens\":7698}}\n 4. Code extract run_id from JSON response\n 5. GET /api/chunks?run_id=11a1f230-…&payload=1&limit=50\n ← {\"chunks\":[{...payload...},...], \"total\":5}\n 6. Code concat → single string, ~7,700 tokens, 5/5 chunks used\n 7. LLM synth (Opus 200K) → final markdown\n 8. answer:\n \"## Summary of open warehouse orders (PL01-WH1)\n 17 of the 30 sampled orders are Open.\n Most overdue: WO-PL01-WH1-0000001 (DueBy 2025-05-19, ...)\n ...\"\n — Analysed 30 records across 5/5 chunks (run 11a1f230-…)\n

\n\n

The full prompt sent to Opus at step 7 was approximately:

\n\n

User question: Summarise all open warehouse orders for PL01-WH1...\nIngest summary: run_id=11a1f230-…, entity=WarehouseOrders,\nstrategy=token-budget, chunks=5, records=30, tokens=7698\n\nProcessing 5 of 5 chunks below:\n\n--- CHUNK 1 / 5 (records=7, tokens=1795, warehouse=PL01-WH1) ---\n{ \"entity\": \"WarehouseOrders\", \"records\": [ {full WO record}, ... 6 more ] }\n\n--- CHUNK 2 / 5 (records=7, tokens=1802, warehouse=PL01-WH1) ---\n{ \"entity\": \"WarehouseOrders\", \"records\": [ ... ] }\n\n(...)

\n\n

\n\n\n\n

8Operations

\n\n

8.1Environment Variables

\n\n

\n\n \n \n \n \n \n

Val	Variable	Default	Purpose
`ewmMockServer`	`API_KEY`	(set in Val Town UI)	Required on every request
`ewmBackend`	`API_KEY`	(set in Val Town UI)	Sent as `X-API-Key` to the mock

Table 8.1The two API_KEY variables must hold the same value, otherwise the backend's calls to the mock will 401.

\n\n

8.2Constraints

\n\n

Request time cap: Val Town aborts requests after 30s. Seeding more than ~2,000 rows in one call exceeds this.
SQLite size: Val Town's SQLite allowance is per-account. The schema is compact (~1 KB/row average) but large seeds will consume it.
Context window: The b5 concat step caps at 30 chunks / 120 KB to fit comfortably in Opus's 200K-token context. Beyond that, additional batching would be required.

\n\n

8.3Troubleshooting

\n\n

\n\n \n \n \n \n \n \n \n \n

Symptom	Cause	Fix
Browse page shows \"0 total\"	Entity not seeded in SQLite	Seed via Data Management → entity → limit
Ingest fails with `Unauthorized`	Backend `API_KEY` ≠ mock `API_KEY`	Sync the env vars in both vals
Seed times out	Limit too high for 30 s budget	Reduce `limit` or filter by `warehouseId`
Dify: `availablePrevNodes undefined`	Iteration node DSL mismatch	Use the v1.1 workflow YAML (no iteration node)
Chunks table empty after ingest	Source entity not seeded	Seed first, then re-run ingest

\n\n

\n\n\n\n

AGlossary

\n\n

\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n

Term	Meaning
Plant	Top-level SAP organisational unit (e.g. PL01 = Singapore Manufacturing Hub).
Warehouse	A physical site under a plant (e.g. PL01-WH1). Has Zones (GR, GI, LS, QI, HZ).
Warehouse Order (WO)	Smallest unit of work in EWM. Contains Pick / Putaway / Count tasks.
Transfer Order (TO)	Move stock between locations within a warehouse.
Wave	Batch of outbound deliveries grouped for picking efficiency. Contains nested PickingTasks.
Handling Unit (HU)	Physical container (pallet, carton).
OData	HTTP query convention used here for paginated reads. Top + skip pagination, `@odata.count` for totals.
Chunk	A unit of data prepared for LLM consumption. Has `record_count`, `tokens`, `payload`.
Run	One invocation of `POST /api/ingest`. Identified by `run_id`. Produces N chunks.
Seed	One invocation of `POST /api/seed`. Copies records from the mock into SQLite.

\n\n\n\n

SAP EWM × AI Hive Integration

1Introduction

1.1Purpose

1.2Scope

1.3Conventions

2System Architecture

2.1Component Inventory

2.2Data Flow

2.3SAP Landscape Mapping

3Component — Mock Data Source

3.1Role

3.2Sample Request

3.3Sample Response

3.4Generated Volumes

4Component — Backend

4.1Database Schema

plants

warehouses

entity_records

chunks, ingest_runs, seed_runs

4.2Seeding Pipeline

Inspection

4.3Endpoints

Sample: /api/data/:entity

Sample: /api/products

4.4Chunking Strategies

5Component — Fiori Dashboard

5.1Pages

5.2Data Flow

6Component — Dify Workflow

6.1Intent Classifier

6.2Branches

6.3Branch 5 — Chunked Analysis

7End-to-End Walkthrough

7.1Setup

7.2Simple Query (b1)

7.3Chunked Query (b5)

8Operations

8.1Environment Variables

8.2Constraints

8.3Troubleshooting

AGlossary

Sample: `/api/data/:entity`

Sample: `/api/products`

Search