SAP Integration Technical Specification Template
A technical specification is the contract between the person who builds an interface and everyone who supports it later. This template covers the sections reviewers ask for, so the document is useful on day one and during the 3 a.m. outage.
Fill in
SAP Integration Technical Specification Template
Production confirmations from MES (IF-004)
Technical specification, version 0.3 Author: Karan Shah Date: 2026-10-20
1. Purpose
Post goods receipts and operation confirmations for production orders as work is completed on the shop floor, so SAP reflects actual progress and inventory.
2. Overview
| Item | Detail |
|---|---|
| Source system | Shop floor MES |
| Target system | SAP S/4HANA production system |
| Technology | RFC/BAPI |
| Trigger | Event driven |
| Expected volume | 9,000 messages per day, peak 1,300 per hour |
3. Data mapping
| Source field | Target field | Rule | Mandatory |
|---|---|---|---|
4. Error handling
Rejected confirmations are written to the application log (SLG1) and returned to the MES with a reason. MES retries up to 3 times with 5 minute spacing, then raises an alert to plant IT.
5. Security
Dedicated communication user with minimum authorizations for confirmation BAPIs. TLS between MES and SAP. Credentials held in the MES secure store.
6. Monitoring and support
Failed messages per hour reported in SLG1 and the middleware monitor. Alert when failures exceed 20 in an hour.
7. Open points and assumptions
| Point | Owner | Due date |
|---|---|---|
Approval
Fill the data mapping table with real field names from your interface. Add sections for transports, cutover and rollback if your project standard requires them.
Interface design review
Send your draft specification for a short review of error handling and monitoring gaps.
Optional. The tool and every export work without this. No spam.
How to use the template
Fill the fields once, export the document and complete the mapping and open points tables by hand or in Word. Write the purpose in business terms, then pin down the technical facts: source and target systems, technology, trigger and volume. Volume matters because it decides whether one synchronous call per message is acceptable or whether you need batching, queues or a middleware layer. Keep the specification short enough that a reviewer reads it. One page of overview, one table of mapping rules and a clear error section beat twenty pages of boilerplate.
- State volume with a peak, not just a daily total
- List mandatory fields explicitly
- Name who gets the alert when it fails
Choosing the technology
The technology field should follow from the requirement. IDocs suit asynchronous business documents with built in monitoring and reprocessing in the SAP system. BAPIs and RFC suit synchronous calls where the sender needs an immediate result. OData and REST APIs suit modern consumers and web apps. File based interfaces remain common for banks and legacy systems. A middleware flow in SAP Cloud Integration is useful when you need transformation, routing or connections to several systems. Record the reason for the choice, because the next team will ask.
Error handling and monitoring
Most specifications skip this and most outages hit exactly here. Decide what happens to a message that fails: is it retried, held, rejected back to the sender or logged for manual follow up? Decide how long messages are kept and where support finds them, such as WE02, SLG1, SM58 or the middleware monitor. Decide what triggers an alert and who receives it. Add idempotency: if the same message arrives twice, what is the outcome? Writing these answers before development saves a rebuild after the first production incident.
- Define retry count and spacing
- Define duplicate handling
- Define alert thresholds and recipients
- Define retention and archiving
Frequently Asked Questions
How detailed should the mapping table be?
Detailed enough that a developer who has not seen the project can build and a tester can verify. List source field, target field, transformation rule and whether it is mandatory. Link to the full message structure in an appendix if it is long.
Is this the same as a functional specification?
No. A functional specification describes the business need and process. The technical specification describes how the interface is built, secured, monitored and supported. They should reference each other.
Do I need a spec for a small change?
For a minor change to an existing interface, update the existing document and its version. For any new interface, even a small one, a short spec is worth writing.
Who should sign off the specification?
At minimum the author, the integration architect and the business owner. Add Basis or security when the interface opens a new connection or needs special authorizations.
Netray can review interface specifications against your landscape and help build the monitoring and recovery tooling around them.
Related Tools
SAP Integration Test Case Matrix Worksheet
An editable test matrix for SAP interface testing, with scenario, expected result, pass flag and defect count rolled up to a pass rate.
SAPSAP Interface Inventory Register Worksheet
An editable register of every interface touching SAP, with technology, owner, frequency and business criticality, ready to export to Excel.
SAPSAP Interface Volume and Storage Sizing Worksheet
An editable worksheet that turns messages per day, average size and retention into daily megabytes, peak hourly load and total storage.
SAPSAP IDoc Partner Profile (WE20) Setup Template
A fill-in setup sheet for WE20 partner profiles, WE21 ports and the inbound and outbound parameters behind each IDoc partner.