We are trying to call OData and REST endpoints in an S/4HANA On Premise system from our SAP Cloud Platform Java app. However, our attempts to use the SAP CloudSDK to get an HTTP client for the corresponding destination
Destination destination = DestinationAccessor.getDestination(destinationName);
HttpClient client = HttpClientAccessor.getHttpClient(destination.asHttp());
fails with the exception
com.sap.cloud.sdk.cloudplatform.connectivity.exception.DestinationAccessException:
Failed to get on-premise proxy headers.
We are at a loss at what's causing it. The text also isn't very specific about what is missing. "Proxy headers", okay. But what are they, and where do I maintain them, and for what? None of the blogs 1 2 we've referred to mentions anything of the kind.
Our Destination looks as follows:
Name: ABC
URL: http://abc:445/sap/opu/odata/sap/SOME_ODATA_SRV
Proxy Type: OnPremise
User: MYUSER
Password: ******
sap-client: 123
It points to a Cloud Connector that exposes a back-end system:
Host: abc:445
Protocol: HTTP
Back-End Type: ABAP System
Connection check is successful.
I finally found the piece of code that throws the exception in method getHeadersForOnPremiseSystem of class ConnectivityService in library cloudplatform-connectivity-scp-cf, which apparently fails to resolve headers that are related to the XSUAA service using a PrincipalPropagationStrategy. That makes me wonder: as far as I know, principal propagation is for frontend access to Fiori apps. But we only want to call an OData endpoint, hence neither need nor want to configure that.
What are we missing or doing wrong?
Florian, you'll have to decorate your destination with DefaultErpHttpDestination like
HttpClient client = HttpClientAccessor.getHttpClient(destination.asHttp().decorate(DefaultErpHttpDestination::new));
Thanks for good feedback, we'll be updating our documentation on destination handling and other OData related topics here
Related
I am using quarkus 1.10.5.Final and need to call web service with web proxy.
Currently my code using microprofile client proxy and put below configuration in application.properties
client/mp-rest/url=https://remote.com
client/mp-rest/scope=javax.inject.Dependent
client/mp-rest/trustStore=classpath:/META-INF/resources/cacerts
client/mp-rest/connectTimeout=5000
client/mp-rest/readTimeout=5000
client/mp-rest/followRedirects=true
client/mp-rest/proxyAddress=http://proxy:8080
but still resulting RESTEASY004655: Unable to invoke request: java.net.UnknownHostException: No such host is known
I tried to use -Dhttp.proxyHost and -Dhttp.proxyPort to test the proxy and it was success.
the problem is I can't use -Dparams since it will break other service calls.
this link where I got config for mp-rest/proxyAddress
https://download.eclipse.org/microprofile/microprofile-rest-client-2.0-RC2/microprofile-rest-client-2.0-RC2.html
but its not mentioned in https://docs.jboss.org/resteasy/docs/4.1.1.Final/userguide/html/MicroProfile_Rest_Client.html
please let me know if I am looking on wrong thing.
May 2021 update
Quarkus 2.0 supports MicroProfile Rest Client 2.0. With it you can use the configuration you mention, namely
# A string value in the form of <proxyHost>:<proxyPort> that specifies the
# HTTP proxy server hostname (or IP address) and port for requests of
# this client to use.
client/mp-rest/proxyAddress=host:port
Or set it programmatically with
ProxiedClient client = RestClientBuilder.newBuilder()
.baseUri(someUri)
.proxyAddress("myproxy.mycompany.com", 8080)
.build(ProxiedClient.class);
Original answer
You should be able to set proxy for your Quarkus Rest client with the following properties:
org.jboss.resteasy.jaxrs.client.proxy.host
org.jboss.resteasy.jaxrs.client.proxy.port
org.jboss.resteasy.jaxrs.client.proxy.scheme
I just run into the same problem and found this issue.
Upgrade to MP Rest Client 2.0 #10520
MP-Rest-Client 2.0 is not available in quarkus 1.10.5.
We have implemented webservice call using JAX-WS RI 2.1.6 in JDK 6 now problem comes when we enable https webservice call stops reaching server and java reports following error,
javax.xml.ws.WebServiceException: java.io.IOException: Async IO
operation failed (3), reason: RC: 55 The specified network resource
or device is no longer available.
Now I have tested this within SoapUI and response from the service is received there.
Looked into various solution where it tells us to provide timeout settings but nothing seems work.
#WebEndpoint(name = "RulesSoap")
public RulesSoap getRulesSoap() {
((BindingProvider)super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class)).getRequestContext().put("com.sun.xml.internal.ws.connect.timeout", 1000);
((BindingProvider)super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class)).getRequestContext().put("com.sun.xml.internal.ws.request.timeout", 1000);
return super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class);
}
And just for information JAX-WS implementation is following few simple lines,
of course we submit all necessary data into respective stubs and all but I am not submitting here because our http calls are getting through,
Rules rules = new Rules(new URL(url), new QName("urn:decision:Rules", "Rules"));
RulesSoap rulesSoap = rules.getRulesSoap();
CorticonResponse response = rulesSoap.processRequest(request);
Note : Our application server WebSphere Application Server and Version 7.0.0.19
Thanks in Advance.
After lots of efforts we resolved this. I will provide steps if anything related to this happens how to find root cause,
Step 1 :
First of all we enabled soap tracing in WebSphere Application Server by following setting,
Admin Console > Servers > Server Types > WebSphere Application Servers >
{your server} > Troubleshooting > Change Log Detail Levels > Runtime
In run time please put this , *=info: com.ibm.ws.websvcs.*=all: org.apache.axis2.jaxws.*=all
This step will create trace.log file in your logs folder.
Now any web service request which goes out of your server will add logs to this file and necessary props like endpoint, request, response etc.
Step 2 :
Reading this trace.log file we found following endpoint,
PropertyValid 1 org.apache.axis2.jaxws.client.PropertyValidator validate validate property=(javax.xml.ws.service.endpoint.address) with value=(http://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0)
HTTPConnectio 3 resetConnection : http://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0 Persistent : true
Now if you notice here that our soap has endpoint address javax.xml.ws.service.endpoint.address where protocol is still using http which causes to fail ssl handshake.
Step 3 :
Solution for this is to override endpoint inside your soap stubs which can be implemented by adding following line,
RulesSoap rulesSoap = rules.getRulesSoap();
((BindingProvider)rulesSoap).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0");
Conclusion :
So here is what i think even we pass https url while we are creating objects but still does not take this https url on runtime, to me this looks like stubs creation issue with JAX-WS.
Thanks.
What protocol /ciphers are you using? You have mentioned there is connection to webservice on WAS7 with JDK6 and Java 6 does not support TLS1.2 (and TLS1.1 only from certain fixpack).
See this:
How to use TLS 1.2 in Java 6
For getting the blob container details we are using the below mentioned REST API.
Vhd is the blob container name.
https://(storageAccountName).blob.core.windows.net/vhd?restype=container&comp=list
When we use proxy server details (example:SQUID Proxy) to access the storage REST API calls, we are getting the below mentioned error.
HttpResponse for Blobs:: ResourceNotFoundThe
specified resource does not exist.
RequestId:6dc7e6f2-0001-000d-30f9-d56eb3000xxx
If we access the same rest api without proxy server, we are getting the valid response and it's working.
Per my experience, normally, using squid is as reverse proxy for backend services, but here you want to access the storage REST APIs via squid as forward proxy. You can refer to the wiki page https://en.wikipedia.org/wiki/Proxy_server, the SO thread Difference between proxy server and reverse proxy server and the blog to know the differences between both.
So the solution for the issue is that configuring the proxy server as forward proxy.
For Squid, you can try to refer to the squid wiki pages http://wiki.squid-cache.org/SquidFaq/ConfiguringSquid and http://wiki.squid-cache.org/Features/HTTPS to know how to configure as forword proxy with HTTPS.
For Apache, you can try to refer to the apache doc page http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#forwardreverse to do.
Then, setting the system properties for Java to enable proxy support after setting up forward proxy successfully.
There are two ways support proxy for Java.
Command Line JVM Settings: The proxy settings are given to the JVM via command line arguments:
java -Dhttp.proxyHost=proxyhostURL -Dhttp.proxyPort=proxyPortNumber -Dhttp.proxyUser=someUserName -Dhttp.proxyPassword=somePassword HelloWorldClass
Setting System Properties in Code: Adding the following lines in your Java code so that JVM uses the proxy to make HTTP calls.
System.setProperty("http.proxyPort", "someProxyPort");
System.setProperty("http.proxyUser", "someUserName");
System.setProperty("http.proxyPassword", "somePassword");
System.setProperty("http.proxyHost", "someProxyURL");
More information for Networking & Proxies & Properties in Java, Please refer to http://docs.oracle.com/javase/7/docs/technotes/guides/net/proxies.html and http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html.
we got the solution. The issue is we are invoking asynchronous calls for all storage accounts at a time. For example : if we have 5 storage accounts and each storage accounts 5 vhd containers and in for loop if we invoke all 5 at time and with callback waiting for 5 response,In this case it's not working. so we are invoking each call separately and it's started working.
I'm working with the Dropwizard sample project from the tutorial and faced the following strange issue:
With the following server config
server:
type: default
applicationConnectors:
- type: http
port: 8080
My resource returns the correct response.
When I change it to:
server:
type: simple
I see (from Jetty's logs) that it was correctly registered and loaded but doesn't work - if I try the same path I see 404 in browser and
GET /wizard-resource/rs 200
in the logs. I've tried to find the difference between simple and default in yaml configs but Google didn't shed much light on the topic.
So, here are two questions:
Why with simple connector do I get a 200 in logs but 404 in browser?
What is the use of simple connector and when it is better than default?
According to Dropwizard Javadocs:
Simple Server
A single-connector implementation of {#link ServerFactory}, suitable
for PaaS deployments (e.g., Heroku) where applications are limited to
a single, runtime-defined port. A startup script can override the
port via {#code -Ddw.server.connector.port=$PORT}.
Default Server
The default implementation of {#link ServerFactory}, which allows for
multiple sets of application and admin connectors, all running on
separate ports. Admin connectors use a separate thread pool to keep
the control and data planes separate(ish).
It's also mentioned (though not thoroughly) in the Configuration Reference documentation.
Not sure why it's logged as 200 while it's 404, it could be a bug; but the reason you're getting 404 could be because the default applicationContextPath config in simple server is /application. So if you try
GET /application/wizard-resource/rs
it should work.
I am connecting to a WCF web service with a Java client I am constructing. Someone else has already successfully built WCF clients to connect to this service. The WSDL available via HTTP provides Message Level Security. The WSDL available via HTTPS uses both TLS and Message Level Security. I understand that using TLS on top of Message Level Security is basically dual-encrypting, but that is a key requirement.
Since I can connect to the HTTP service correctly, I believe I have all the trust store and key store issues resolved.
I am connecting to the service using Metro 2.1.1. I have built the client in both Eclipse and Netbeans. I fetch the WSDL from the HTTP site, and using wsimport (with the -extensions flag) I build and execute the clients successfully.
When I fetch the WSDL using the HTTPS site I can again build both clients successfully. But when I execute them - I get the following error:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: An error occurred when verifying security for the message.
at com.sun.xml.ws.fault.SOAP12Fault.getProtocolException(SOAP12Fault.java:225)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy43.request(Unknown Source)
The only difference between the two WSDLs (the one fetched via HTTP and the other via HTTPS) is the reference in the WSDL to HTTPS:// vs. HTTP://.
I do not have easy access to the WCF service logs - normally there is a 3-6 hour delay between when I request a set of logs and when I can view them.
My question is has anyone encountered a similar circumstance - and is there something I am blatantly missing here? Is there something in a NetMon or Wireshark trace I can look for to see that the issue is? I have been struggling with this for days - any help would be most appreciated.
If you have access to the service configuration try disabling security context on the endpoint you're using:
<message establishSecurityContext="False" clientCredentialType="UserName"/>
You can read more about security context token (SCT):
Security Context Token
Message security knobs
Java client for WCF service with wsHttpBinding over SSL