/IWFND/GW_CLIENT

/IWFND/GW_CLIENT acts as an HTTP client inside the SAP Gateway system. You choose a method (GET, POST, PUT, PATCH, MERGE, DELETE or HEAD), enter a request URI, add headers and a payload, and execute. The response appears next to the request with its HTTP status, headers and body. From the same screen you can:

• add URI options such as $count or $format=json;
• jump to the error log, to service maintenance or to the service implementation;
• turn a response into the next request with Use as Request;
• clean up or rebuild the metadata cache on the hub, the backend or both.

/IWFND/GW_CLIENT answers the question an SAP Fiori app hides: what does the service itself return?

A buyer at Alder Manufacturing reports that the supplier list shows no entry for Cedar Office Supply:

1. Copy the failing request URI from the browser developer tools, for example /sap/opu/odata/sap/ZALDER_SUPPLIER_SRV/SupplierSet with its filter.
2. Start /IWFND/GW_CLIENT, select GET and paste the URI.
3. Execute and read the HTTP status and the response body.
4. Change one thing at a time: remove the filter, add $format=json, request the single entity by key.
5. For a failed save, rebuild the request with the same method, headers and payload; SAP Gateway expects a valid X-CSRF-Token, fetched with a preceding GET, on modifying requests.
6. If the error came from a user report, open the entry in /IWFND/ERROR_LOG and replay it from there instead of retyping it.

A request that fails in /IWFND/GW_CLIENT is a service problem; a request that succeeds there points back to the app or its parameters.

/IWFND/GW_CLIENT turns a vague app symptom into an HTTP status that points to one layer.

/IWFND/GW_CLIENT can save a request as a test case in a test group, either in the database or as a file on your PC. A test case keeps the method, URI, headers, payload and an expected HTTP status; response validation compares a new response with a stored one.

SAP delivers example groups, CORE_SAMPLES for OData V2 and V4_TEST for OData V4, which work only when the services they call are active. For a custom service, a small test group run after each transport catches regressions before users do. Test cases make /IWFND/GW_CLIENT a lightweight regression tool, not only a debugging screen.

• /IWFND/ERROR_LOG and /IWBEP/ERROR_LOG: find the failed request and replay it in /IWFND/GW_CLIENT.
• /IWFND/TRACES: records payload and performance traces when the request succeeds but the data looks wrong.
• /IWFND/MAINT_SERVICE: checks registration and system alias when the service is not found.
• SU53: confirms an authorization failure behind a 403.

Keep in mind that the result reflects the user and authorizations the test request runs with, which are usually not those of the user who reported the problem. /IWFND/GW_CLIENT reproduces the request; the related transactions explain the result.