![\"\"](\"https:\/\/blog.adesso-bc.com\/wp-content\/uploads\/2026\/09\/image.png\")
<\/figure>\n\n\n\nWhere can I find the service root URL?<\/p>\n\n\n\n
One of the most important pieces of information for an external application is the service root URL. This is the base URL relative to which we call the entity sets, the metadata document, and URLs that point to specific records. It is not worth constructing this manually. The correct starting point is the Service Binding object in Eclipse\/ADT. Here you can see which service definition has been published, which binding type is used, and the URL at which the service is available.<\/p>\n\n\n\n
Simplified format:<\/strong><\/p>\n\n\n\n A fontos tanuls\u00e1g: a k\u00fcls\u0151 alkalmaz\u00e1s nem a CDS view nev\u00e9t, nem a behavior nev\u00e9t \u00e9s nem az adatb\u00e1zist\u00e1bla nev\u00e9t h\u00edvja. A k\u00fcls\u0151 alkalmaz\u00e1s a publik\u00e1lt OData szolg\u00e1ltat\u00e1s service root URL-j\u00e9b\u0151l indul. Ha ez az URL hib\u00e1s, akkor minden m\u00e1s is hib\u00e1s lesz: a GET, a metadata lek\u00e9r\u00e9s, a CSRF token k\u00e9r\u00e9s \u00e9s a PATCH m\u0171velet is.<\/p>\n\n\n\n How do I know the name of the entity set?<\/p>\n\n\n\n Another common misunderstanding concerns the entity set name. People often try to call the name of the projection CDS or interface CDS. That is the wrong approach. From the external consumer’s perspective, what matters is the name under which the object is exposed in the service definition.<\/p>\n\n\n\n For example:<\/strong><\/p>\n\n\n\n In this case, the entity set name for the external application is:<\/strong><\/p>\n\n\n\n So a simple GET request might look like this:<\/strong><\/p>\n\n\n\n The metadata can be accessed as follows:<\/strong><\/p>\n\n\n\n This is a very important distinction. The external application does not need to know internal SAP object names; it needs to know the published service contract.<\/p>\n\n\n\n What is \/IWFND\/V4_ADMIN used for?<\/p>\n\n\n\n \/IWFND\/V4_ADMIN is the SAP Gateway administration interface for OData V4 services. Here you can verify whether the service group has been published, whether the service is reachable, and you can also test the given OData V4 endpoint. During the project, this was a key step because having a Service Binding created in ADT did not by itself guarantee that the external application could already consume the service. The Gateway-side publication also had to be configured correctly.<\/p>\n\n\n\n What is worth checking here:<\/p>\n\n\n\n If these do not work on the SAP side either, there is no point looking for the problem in the C# client, Postman, or any other external application. The SAP-side publication must be fixed first. To access the service test, locate the published endpoint and click the Service Test tab. This opens the test interface where we can work with the service.<\/p>\n\n\n\n The role of metadata<\/p>\n\n\n\n The $metadata document is one of the most important parts of an OData service. It describes which entity sets are available, which fields exist, which fields are keys, which data types the service expects, and how the external application must communicate with SAP. Therefore, the external application should not be adapted to our own assumptions, but to the metadata document.<\/p>\n\n\n\n Example:<\/strong><\/p>\n\n\n\n The metadata reveals, for example:<\/p>\n\n\n\n This is especially important for POST or PATCH requests. If the metadata says a field is named IsActive, then that exact name must also be used in the payload. If the metadata publishes a field as a string, we cannot send it as though it were a boolean. Metadata is therefore not just an incidental technical file. It is the contract between the service and the external application.<\/p>\n\n\n\n What is the X-CSRF-Token?<\/p>\n\n\n\n The CSRF token is important for modifying HTTP operations such as POST, PATCH, PUT, or DELETE. The idea is simple: the client must first request a token and then send that token back in the header of the modifying request.<\/p>\n\n\n\n Typical token retrieval:<\/strong><\/p>\n\n\n\n With the following headers:<\/strong><\/p>\n\n\n\n SAP returns the token in the response:<\/strong><\/p>\n\n\n\n For the modifying request, it must be sent back in the header:<\/strong><\/p>\n\n\n\n The critical point is that not only the token must be retained, but also the session cookies returned by SAP. If the token belongs to one session but the PATCH request is sent in another session, the request may fail. This is one of the typical reasons why a modification works in the SAP Gateway Client but fails from an external application.<\/p>\n\n\n\n Which headers are important?<\/p>\n\n\n\n For a GET request, the Accept header is usually sufficient:<\/strong><\/p>\n\n\n\n For token retrieval:<\/strong><\/p>\n\n\n\n For a PATCH request, you need to pay attention to the following:<\/strong><\/p>\n\n\n\n In some cases, an If-Match header may also be required, for example when ETag-based or concurrency handling is used:<\/strong><\/p>\n\n\n\n However, this should not be used blindly. Whether it is required must always be determined from the service metadata document and the GET response. A header is not decoration. It is part of the integration contract.<\/p>\n\n\n\n Executing a PATCH request<\/p>\n\n\n\n The purpose of PATCH is to partially modify an existing record. To do this, you first need to know the exact URL of the record. This URL is built from the service root, the entity set name, and the key field.<\/p>\n\n\n\n Simplified example:<\/strong><\/p>\n\n\n\n The exact key format must always be checked against the $metadata document. If there are multiple key fields, or if the service expects a named-key format, the URL may look different.<\/p>\n\n\n\n Example PATCH headers:<\/strong><\/p>\n\n\n\n Example body:<\/strong><\/p>\n\n\n\n This is correct only if, according to the metadata, IsActive is actually exposed under this name and type as a modifiable field. If the service expects a different type, the payload must be adjusted accordingly.<\/p>\n\n\n\n For PATCH, three things must always be checked:<\/p>\n\n\n\n If any of these are incorrect, it is not SAP that is “wrong”; the client is failing to comply with the service contract.<\/p>\n\n\n\n Key takeaway<\/strong><\/p>\n\n\n\n Using an OData V4 service does not begin with sending an HTTP request from the external application. First, the exact service root URL must be identified in the Service Binding. Then you need to check under which entity set name the service definition publishes the object. In \/IWFND\/V4_ADMIN, you must verify that the service group is published and testable. A GET request should be used to prove that the service is reachable. Based on the metadata, the keys, fields, and data types must be understood. Only then does it make sense to work with modifying operations such as PATCH requests.<\/p>\n\n\n\n The most important lesson for me was that the external application must be aligned not with my own assumptions, but with the contract described by the metadata. If we follow this principle, SAP integration becomes much more predictable. Instead of guessing, we work against a verified service contract.<\/p>\n","protected":false},"excerpt":{"rendered":" Service Binding, metadata, CSRF token, and PATCH requests from a practical perspective In the previous sections, I explained why it is worth connecting an external application to SAP through a RAP\/OData-based service, and we also went through how the RAP object chain is structured on the SAP side. At the end of the development process, […]<\/p>\n","protected":false},"author":11,"featured_media":248988,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","inline_featured_image":false,"footnotes":""},"categories":[335],"tags":[839,906],"class_list":["post-248989","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sap","tag-odata-v4","tag-sap-gateway","blogauthor-ignac-ferenc"],"acf":[],"yoast_head":"\nhttps://<host>:<port>\/sap\/opu\/odata4\/...\/<service>\/0001\/<\/code><\/pre>\n\n\n\ndefine service ZUI_AOT_IF_USER_O4 {\nexpose ZC_AOT_IF_USER as Users;\n}<\/code><\/pre>\n\n\n\nUsers<\/code><\/pre>\n\n\n\nGET <service-root>\/Users<\/code><\/pre>\n\n\n\nGET <service-root>\/$metadata<\/code><\/pre>\n\n\n\n\n
![\"\"](\"https:\/\/blog.adesso-bc.com\/wp-content\/uploads\/2026\/09\/image-1.png\")
<\/figure>\n\n\n\nGET <service-root>\/$metadata<\/code><\/pre>\n\n\n\n\n
GET <service-root>\/<\/code><\/pre>\n\n\n\nAccept: application\/json\nX-CSRF-Token: Fetch<\/code><\/pre>\n\n\n\nX-CSRF-Token: <token-value><\/code><\/pre>\n\n\n\nX-CSRF-Token: <token-value><\/code><\/pre>\n\n\n\nAccept: application\/json<\/code><\/pre>\n\n\n\nAccept: application\/json\n\nX-CSRF-Token: Fetch<\/code><\/pre>\n\n\n\nContent-Type: application\/json\n\nAccept: application\/json\n\nX-CSRF-Token: <token-value>\n\nCookie: <session cookie returned by SAP><\/code><\/pre>\n\n\n\nIf-Match: *<\/code><\/pre>\n\n\n\nPATCH <service-root>\/Users('<UserId>')<\/code><\/pre>\n\n\n\nContent-Type: application\/json\n\nAccept: application\/json\n\nX-CSRF-Token: <token-value>\n\nCookie: <session-cookie><\/code><\/pre>\n\n\n\n{ \n\n\"IsActive\": false\n\n}<\/code><\/pre>\n\n\n\n\n