ZREST – SAP ABAP REST & OpenAPI Infrastructure

The Problem It Solves

Writing a REST service on the SAP side is not the hard part. The hard part is keeping that service understandable and usable across the organisation.

The typical story: the e-commerce team asks for a service from SAP. It gets written in ABAP. Then the field list is explained to the other side in a spreadsheet or an email. A field is added; the documentation is not updated. A new developer has to read ABAP source to find out what the service returns. A Postman collection is hand-built for testing, and it goes stale too.

The result: the service works, but nobody is confident in it. A significant share of integration meetings goes to "is that field still being sent?"

ZREST was written to break that loop: the service definition and its documentation come from the same source, so the documentation cannot drift.

Key Features

How the Documentation Works

The user opens the documentation URL on the SAP system. The page HTML is produced by SAP; the interface assets are loaded from the Önder Yazılım server. The OpenAPI document itself never leaves your SAP system.

1. The user opens https://<your-sap-host>/<your-SICF-node-path>/swagger.html.
2. SAP returns a lightweight HTML page containing a single script line.
3. The browser fetches the interface files from Önder Yazılım and the licence is verified.
4. The interface reads the OpenAPI document from that same SAP server and lists the services.

The practical benefit: because the document and the page live on the same server, the browser treats them as the same origin. That means no CORS configuration, extra headers or security exceptions are needed from your Basis team — removing the item that most often delays a rollout.

Data Security

SAP service documentation is a map of an organisation's business processes. So the product's clearest commitment is this:

• Your SAP system makes no outbound connection. Verification traffic goes through the user's browser; there is no call from the SAP server to the internet. That means it also works on production systems with outbound access closed — no firewall, proxy or STRUST certificate work required.
• Your OpenAPI document is not stored with us. It travels from your SAP server to the browser; it never reaches the Önder Yazılım server.
• No business data passes through. "Try it out" requests go directly to your own SAP server.
• Third-party validator disabled. Swagger UI sends your service URL to an external validation service by default; in ZREST this is switched off and cannot be re-enabled. Your server address never leaves your organisation.
• What is recorded: during licence verification, only the licence key, the requesting server name and a timestamp.

Setup

Setup is three steps, all on the SAP side:

1. Import the transport. The ZREST package arrives as a standard transport request.
2. Activate the service node. The relevant node is activated in SICF.
3. Enter the licence key. The key you are given goes into a system-specific table (SM30). DEV, QAS and PRD each use their own key; the key is not carried by transports.

Licensing

ZREST is a licensed product. Licences are issued per SAP system: each system (DEV / QAS / PRD) uses its own key, and the key is bound to the server name it was issued for. As the expiry date approaches, a reminder appears on the documentation screen; your services are unaffected.