1

I'm building an OData v2 service with Olingo which partly gets data from an S/4 System through a custom Gateway OData service, partly from Cloud Platform Neo and combines both. To achieve this I use the SDK for service development included in the S/4 Cloud SDK (https://help.sap.com/viewer/p/SDK_FOR_SERVICE_DEVELOPMENT).

Here's my problem: When trying to call my Gateway OData service from my Olingo Service it gives me an error "No error field found in JSON". After some tries I found the stack trace but it doesn't really help me either since it just says that the Metadata request failed no reason why. Here's my stack trace: stack trace from SCP logs Can anyone tell me what might be the cause of this (credentials and URLs are double checked) and / or help me in resolving this issue?

Thanks a lot in advance!

EDIT

The issue seems to be connected to the destination configuration. I tried an HTTP destination instead of HTTPS and now it's working... Still I'd like to get it to work on HTTPS too.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Niklas
  • 375
  • 1
  • 3
  • 17
  • Have you already checked out https://stackoverflow.com/questions/48225150/what-can-we-do-for-the-error-no-error-field-found-in-json-vdm401. Even if the error may come from a different source please consider using the ODataConnectivityUtil to get to the cause of the problem. – Philipp Herzig Mar 19 '18 at 06:02
  • Yes, I saw that Question. However this " using the ODataConnectivityUtil " thing is described nowhere and the javadoc isn't really helpful either... – Niklas Mar 19 '18 at 06:31

2 Answers2

1

Note: This answer only applies to S/4HANA Cloud systems.

This seems to be related to SSL certificate verification. Your Java trust store could be missing the relevant server certificate. Can you try to disable the verification of the server certificate as follows:

  • To manually override the chain of trust, you can set a special flag on the destination configuration. To avoid any further issues with untrusted certificates in your local Neo deployment environment, please change the TrustAll flag in your destinations configuration file ./config_master/service.destinations/destinations/ErpQueryEndpoint:
TrustAll=TRUE
  • If you are running into the same problem in a Cloud Foundry deployment environment and you are using the environment variable approach, please adapt the destinations environment variable to additionally include the properties map:
[{"name": "ErpQueryEndpoint", "properties": [{"key": "TrustAll", "value": "true"}], "url": "https://my-url", "username": "USER", "password": "PASSWORD"}]
  • If you have deployed your application and are using the destination service in the Neo or Cloud Foundry environment, add a new additional property to your destination in the Cloud Platform cockpit. Enter TrustAll into the first input (dropdown) field and TRUE into the second field:

enter image description here

Note that this should only be used for testing purposes as it disables the verification of the server certificate. It should never be used in production.

When connecting to S/4HANA Cloud systems on SAP Cloud Platform, you should not encounter this issue as the default trust store already contains the relevant entries. In other cases, to solve such an issue, you have to add the certificate to your local trust store.

Sander Wozniak
  • 650
  • 8
  • 27
  • Thanks for the extensive answer. Since I'm connecting to an OnPrem S/4 system, I don't have the default JDK truststore option and additionally I'm getting the following message when trying to add the TrustAll property: `For destinations with HTTPS URL and ProxyType set to 'OnPremise', you are not allowed to add property TrustAll` – Niklas Mar 20 '18 at 05:11
  • 2
    I've updated the description. Please also see my alternative answer. – Sander Wozniak Mar 20 '18 at 09:46
1

Another option is that you try to register a custom error handler on the ODataQueryBuilder:

ODataQueryBuilder builder = 
    ODataQueryBuilder
    .withEntity(...)
    .errorHandler(new ODataVdmErrorResultHandler());

builder.build().execute();

This should give you better insight on the underlying error.

Sander Wozniak
  • 650
  • 8
  • 27
  • This was actually the most useful hint. Should I accept that as the answer even though it's not the answer to the actual problem? – Niklas Mar 21 '18 at 10:42
  • I would suggest this since this will help other users to find the cause of such issues more easily. – Sander Wozniak Mar 25 '18 at 19:00