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

Interactive Product Presentation

The browser-ready presentation brings the ZREST story into one flow: architecture, inbound and outbound requests, live SAP screens, generated OpenAPI and Swagger, saved request variants, configurable logging and retention, deployment, and verification evidence.

Demo Screens

The images below were captured from a running ZREST demo service and its SAP administration screens. User information has been anonymised or excluded from the frame; no licence key or real customer data appears in the images.

Swagger interface

SAP configuration and monitoring

How the Documentation Works

The user opens the documentation URL on the SAP system. SAP produces the page HTML, while the interface assets are loaded from the Önder Yazılım server. The OpenAPI document is fetched directly from the SAP server by the user's browser; it is not sent to the Önder Yazılım server.

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 assets from Önder Yazılım and sends a separate request to the Önder Yazılım licence gateway for licence verification.
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 server makes no outbound connection to Önder Yazılım. Interface assets and licence verification are requested by the user's browser, so the browser must be able to reach onderyazilim.com.
• Your OpenAPI document is neither sent to nor stored by Önder Yazılım. It remains between the SAP server and the user's browser.
• No business data passes through. "Try it out" requests and business data travel directly between the browser and the SAP server.
• The third-party validator is disabled. The OpenAPI document and service URL are not sent to that validator. The technical data sent to the licence gateway is described separately below.
• Licence verification record: the licence key, matched licence/customer name, resolved server name, the location parameter (which may be a full URL), package version, verification time and result, referrer and user-agent are retained. The ZREST application access log does not collect the client IP address. Access records are deleted automatically after 180 days.
• Discovery notification: the server name, location and first-seen time for a newly observed server are sent through Formspree; the licence key and user-agent are not added to the notification payload. The ZREST application log does not collect the client IP address; the service provider may see the connecting server's IP address as technical connection data. See the Privacy Policy for details.

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.