Message "Not found" at runtime

[pazodoble]

When implementing ORD for a CAP service developed in Java, the generation of JSON descriptions at CDS build time works properly:
/src/main/resources/ord/open-resource-discovery.json
/srv/src/main/resources/ord/srv.json

However, in BTP environment, it was not possible to access the ORD entry-point at runtime. Instead of returning JSON for the [base URL]/.well-known/open-resource-discovery URL as expected, the message "Not found" is displayed.

The whole step by step procedure to implement ORD, especially the update of the srv/pom.xml file, is described here: https://wiki.one.int.sap/wiki/pages/viewpage.action?pageId=5054189656

This has been demonstrated to work for a local URL like http://localhost:4004/.well-known/open-resource-discovery

So, at the current state, we might need to serve own routes through adapting Java servlets - which is less convenient.

We could demonstrate that this problem is not caused by missing route in the Approuter (
https://github.wdf.sap.corp/CloudConso/grdc-approuter/blob/main/approuter/xs-app.json).

During CDS build, in the logs, we cannot see the expected line:
"Servlet OrdServlet mapped to /.well-known/open-resource-discovery"

Related issue: #114

[pazodoble]

Hello,
Coming back to you regarding this issue, it seems that there is a dysfunction of the @cap-js/ord plugin 1.2.0 at build time (see https://github.tools.sap/cap/issues/issues/18273)

Description of the issue :
In the pom.xml file of the java application, the tag:
<command>compile --to ord srv -o "${project.basedir}/src/main/resources/ord/open-resource-discovery.json"</command>
actually generates a srv.json file instead of the expected open-resource-discovery.json file.
As a consequence, the ORD endpoint does not appear properly in the CAP Java automatically generated index page of served paths:

The following workaround works fine: open a terminal and directly type the command from the source directory of the project
cds compile --to ord srv -o "srv/src/main/resources/ord/open-resource-discovery.json"
This causes the open-resource-discovery.json file to be generated in the srv/src/main/resources/ord directory as expected. See CAP Java automatically generated index page of served paths now:

At the start of the application, the ORD servlet is properly mapped to the /.well-known/open-resource-discovery relative URL, confirmed by the log:
2025-05-05T14:46:22.82+0200 [APP/PROC/WEB/0] OUT {"msg":"Servlet OrdServlet mapped to /.well-known/open-resource-discovery","level":"INFO","written_ts":"1746449182827864149","logger":"com.sap.cds.framework.spring.config.adapter.AdapterBeanFactory","written_at":"2025-05-05T12:46:22.827Z","thread":"main","type":"log"}
The full log at runtime during the start of the application is attached here:
log-grdc-runtime-OK.txt

Finally, we temporarily removed all XSUAA authentication from our Cloud application to permit access to the ORD entry-point. In the srv\src\main\java\com\sap\cloud\conso\datamapping\config\AppSecurityConfig.java file, we added the following lines:

@.securityMatchers(matchers -> matchers
   .requestMatchers(antMatcher(GET, "/**"))
[…]
.authorizeHttpRequests(authz -> authz
   .requestMatchers(antMatcher(GET, "/**")).permitAll()

We can now demonstrate that the ORD endpoint is properly created by the ORD Servlet and that the CAP Java ORD plugin serves the ORD files at runtime, however we still get authentication issue when accessing especially the /.well-known/open-resource-discovery relative URL:

[pazodoble]

Hello,
Is there any update regarding the "No authentication" issue, which is blocking.
We are open to have a call with our architect and security expert.
Thank you in advance.

[mlakov]

@pazodoble as of version 4.9.0 the ORD support for CAP Java has been re-worked quite heavily. You can find an example on how to set it up here: SAP-samples/cloud-cap-samples-java/pull/659.

When using CAP Java in combination with other frameworks (e.g. Spring / Spring Boot) you need to configure the corresponding security layer in order to ensure proper access to the two ORD servlets. We're doing something similar in our open-resource-discovery/spring-boot-starter-ord.