I deployed exactly the same WS-proxy in 4.5.1 and 4.6. With 4.5.1 it works correctly, but with 4.6 I get:
ERROR - AxisEngine The endpoint reference (EPR) for the Operation not found is /services/registro.registroHttpSoap11Endpoint and the WSA Action = . If this EPR was previously reachable, please contact the server administrator.
The source is the following:
<proxy xmlns="http://ws.apache.org/ns/synapse" name="registro" transports="http" statistics="disable" trace="disable" startOnLoad="true">
<target>
<outSequence>
<send/>
</outSequence>
<endpoint>
<address uri="http://localhost:15080/SIGEM_RegistroPresencialWS/services/ServicioRegistroWebService"/>
</endpoint>
</target>
<publishWSDL uri="http://localhost:15080/SIGEM_RegistroPresencialWS/services/ServicioRegistroWebService?wsdl"/>
<description></description>
</proxy>
What do I have to do for 4.6. to make it work?
Thanx.
To enhance ESB performance pass-through transport has been enabled by default starting from ESB 4.6.0 version that is not the case for ESB 4.5.1. It seems your proxy service depends on SOAP body based dispatching but pass-through transport does not support for SOAP body based dispatching. SOAP body based dispatching build the message body and use first element's local name for dispatching which effect to proxy performance badly that is the reason it was not supported in pass-through transport. We are in a process to fix this limitation for future ESB releasees without loosing any advantage of pass-through transport.
BTW for the moment you can use one of the following workarounds.
When sending a messages to the proxy service append operation name to the endpoint URL
e.g - http://serverName/app/serviceName/operationName
Modify client level code to send expected SOAPAction value ( like Try-It case)
I'm not sure your backend service's WSDL defined "" as the value of SOAPAction if that is the case you may modified the backend service to have value other than "" per each operation. AS an example for JAX-WS services you can use #WebMethod annotation for this.
e.g - #WebMethod(action="XXXX")
Note : In case if your backend WSDL defining a value other than "" for SOAPAction while your client send message with SOAPAction="" then it's a violation of service contract by the client and need to be fixed on client level.
I have faced the same problem with wso2 ESB 4.7 and the web service is also developed by me for the company.
What worked for me is adding soapAction attribute to wsdl soap:operation element like below.
<soap:operation soapAction="http://localhost:8080/MyWebApp/services/hello" style="document"/>
Related
I wish all my Proxy Services to log a standard ERROR when the endpoint publishes a soapfault. Setting faultSequence to a valid logging sequence doesn't seem to be doing anything. I know the endpoint is publishing fault responses & the faultlogger sequence is a simply FULL log.
<SOAP-ENV:Fault...> </SOAP-ENV:Fault>
<proxy ... >
<target faultSequence="faultlogger" endpoint="conf:/myService>
...
</target>
</proxy>
How does faultSequence work?
I also tried to use a out, filter + log but wasn't sure what the xpath expression I should use to filter for faults.
faultSequence is executed when there is a technical error (in your xpath for exemple, or can't connect to an address configured in an endpoint)
A SOAPFault is not a technical problem and the out sequence is executed : you can verify response message to find potentials soap faults.
An other solution is to set the property named FORCE_ERROR_ON_SOAP_FAULT :
<property name="FORCE_ERROR_ON_SOAP_FAULT" value="true"/>
how to use faultsequence of proxy in esb
i want to use faultsequence when occur a fault in EndPoint. for example i stop service1 using jconsole and want to route message to service2 when call proxy service. but when i call proxy using soapui it show fault this message : The system is attempting to access an inactive service..
<target>
<inSequence >
<send>
<endpoint name="cal" >
<address uri="http://localhost:9763/services/service1/"/>
</endpoint>
</send>
</inSequence>
<faultSequence>
<log level="custom">
<property name="text" value="An unexpected error occured for service"/>
<property name="message" expression="get-property('ERROR_MESSAGE')"/>
</log>
<send>
<endpoint>
<address uri="http://localhost:9763/services/service2/"/>
</endpoint>
</send>
</faultSequence>
please guide me!
When your endpoint 1 is inactive it returns a soap fault and you want it to go to the fault sequence. But at the moment that fault sequence is considered as a response and it is sent to the client (soap ui).
In WSO2 ESB 4.5.0 onwards, there is a new property FORCE_ERROR_ON_SOAP_FAULT added. By setting this property, soap faults will be directed to fault sequence. You can do your next logics when you are in the fault sequence (for example invoking another sequence).
Refer [1] for a sample proxy service.
[1] http://maharachchi.blogspot.com/2012/09/now-you-can-send-soapfaults-to-fault.html
I believe your exact scenario is apart of your main end point if it faild you need to route the message to secondary endpoint.
Correct approach to your implementation is not using the fault sequence right approach is using fail over endpoint. You can find reference document at [1][2].
For sample you can refer "Sample 53: Failover sending among 3 endpoints" [3].
[1].http://wso2.org/project/esb/java/3.0.1/docs/endpoint_guide.html#FoEp
[2].http://docs.wso2.org/wiki/display/ESB403/Failover+Endpoint
[3].http://wso2.org/project/esb/java/3.0.1/docs/samples/endpoint_mediation_samples.html
Thank You,
Dharshana.
We have CXF based SOAP web services and we are hitting these services from SOAP UI with no problem. With one of these services, I setup a ProxyService on barebone WSO2 ESB 4.6.0. The proxy service seems to be working with the "Try It" option from the admin console. When I try to access it from SOAPUI, the WSO2 ESB starts complaining that
"The endpoint reference (EPR) for the Operation not found is /services/HelloWorldProxyService and the WSA Action = . If this EPR was previously reachable, please contact the server administrator."
Now, when I change the endpoint URL in SOAPUI as http:// hostname:8280/services/service-name.port-name/operation-name things start to work.
Does anyone know how to fix this issue? Are there configuration options on the WSO2 ESB which will let us use traditional SOAPUI with WSO2 ESB?
You can point the proxy service url(you can view this, via service dashboard of the particular proxy) in soapui and for the "action", in the insequence of the proxy define a property call;
. header name="Action" value="soap action"
Here is the guide on vailable properties
http://wso2.org/project/esb/java/3.0.0/docs/properties_guide.html
I have the same problem if I put operation1 at the end of WS URI (http://somedomain.com/WebServiceProxyName/operation1), but post a SOAP message body with constructs for another operation(operation2,3,4,5...) it works!!!
Sample
POST http://somedomain.com/..../operation1 HTTP/1.1
....
....
<soap:Envelope ...>
<soap:Header/>
<soap:Body>
<ws:operation2>
</ws:operation2>
</soap:Body>
</soap:Envelope>
Try to change the (original) WSDL and put the soapAction there:
You can define it as an attribute of the http://schemas.xmlsoap.org/wsdl/soap/:operation element in the binding section, e.g.
<wsdl:binding name="healthcheck-1.0.0SOAP" type="tns:HealthCheck100PortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="doHealthCheck">
<soap:operation soapAction="http://www.xyz.ch/healthcheck-1.0.0/doHealthCheck"/>
I'm building a WCF web service that requires interop with non-WCF clients (in fact, there will be no WCF clients).
I've already written a WSDL using SOAP 1.2 (as per this example). I've validated the WSDL and have used this file (not the WSDL generated by WCF, which is superficially different) to create a soapUI test project.
I have a requirement that the web service will support SOAP 1.2, so I can't just fall back to SOAP 1.1 (which worked just fine in an early prototype).
I've used WSCF.blue to generate my WCF service, interface, and data contract classes. Everything compiles nicely and the endpoint is exposed if I hit the WCF service in my browser. All seems well with the world.
When I try to call a method from soapUi I get the following response from the server (as visible from soapUI):
HTTP/1.1 415 Cannot process the message because the content type
'application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing"'
was not the expected type 'text/xml; charset=utf-8'.
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 30 Apr 2012 08:15:29 GMT
Content-Length: 0
(Actual method names and namespaces have been manually changed for the purposes of this question. Any typos in namespace are not errors in my code - just an oversight in typing up this question)
I know that SOAP 1.1 specifies that the content type must be text/xml. SOAP 1.2 requires application/soap+xml.
My raw request (as per soapUI):
POST http://localhost/MyWs.svc HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing"
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:ns="http://tempuri.org">
<soap:Header/>
<soap:Body>
<ns:fetchMyThingRequest attribute1="1" attribute2="10">
</ns:fetchMyThingRequest>
</soap:Body>
</soap:Envelope>
From this response, it tells me that my request is properly formed - it's a SOAP 1.2 request with the correct content type. My WCF service, however, does not expect this content type, which I assume means I have not configured it correctly and it still thinks it's a SOAP 1.1 web service.
Minimal Web.config, as per this blog post:
<system.serviceModel>
<services>
<service name="MyNamespace.MyPort">
<endpoint address="" binding="customBinding" bindingConfiguration="httpSoap12" contract="IWsPort12" />
</service>
</services>
<bindings>
<customBinding>
<binding name="httpSoap12">
<textMessageEncoding messageVersion="Soap12" />
<httpTransport />
</binding>
</customBinding>
</bindings>
</system.serviceModel>
A snippet of the service contract:
[ServiceContract(Namespace = "http://tempuri.org")]
public interface IWsPort
{
[OperationContract(Action = "http://tempuri.org/FetchMyThing")]
[FaultContract(typeof(WsFault), Action = "http://tempuri.org/FetchMyThing", Name = "fetchMyThingFault")]
[XmlSerializerFormat(SupportFaults = true)]
FetchMyThingResponse FetchMyThing(FetchMyThingRequest request);
}
I enabled service tracing for my WCF service and see the following exception that seems to confirm my hypothesis:
Activity: Listen at 'http://mycomputer/MyWs.svc
<Exception>
<ExceptionType>System.ServiceModel.ProtocolException, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType>
<Message>Content Type application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing" was sent to a service expecting text/xml; charset=utf-8. The client and service bindings may be mismatched.
</Message>
(erroneous detail snipped)
</Exception>
So, my contract and service bindings are probably mismatched, if this message is to believed, but from what I understand of WCF my configuration (or at least the intent behind it) is correct.
Does anyone have any ideas as to what's wrong with my configuration?
The only thing I can think with it is that because you've not specified a binding in a lot of detail, and its using HTTP (as per this: "Listen at 'http://mycomputer/MyWs.svc'") then is it using the default (i.e. basicHttpBinding) for this, which is creating the mismatch?
I had the same issue when I had multiple bindings on my service. When I removed all bindings and only left one unnamed binding in place, the error message disappeared.
Please check this link How to: Configure WCF Service to Interoperate with ASP.NET Web Service Clients
.
To configure a Windows Communication Foundation (WCF) service endpoint
to be interoperable with ASP.NET Web service clients, use the
System.ServiceModel.BasicHttpBinding type as the binding type for your
service endpoint.
Also, defining two endpoints you can use HTTP and HTTPS versions of the same service
TL;DR version is at the bottom.
I have constructed three WCF web services -- one that's using .NET 4 and two that's using .NET 3.5 -- that is consumed by an Android client. The Android client performs the calls using ksoap2-android. When the services were complete and the client could make all the calls and get all the data from the services, we decided to activate HTTPS communication for the web services. They are hosted on a server running IIS.
I'm not alone on this task. I work full-time with it, mainly the Android client. I have two coworkers, both of which have a lot of other responsibilities. The first is mostly involved in the services and the second is mostly involved in the server.
I've read a lot of guides, blogs and articles on the Internet on how to enable HTTPS for a WCF web service, but still I haven't been able to completely resolve this. For the Android client to be able to consume the client, we are limited to using the basicHttpBinding, since the wsHttpBinding contains some security details that are not supported by Android, or something. I'm not sure, but I read it some forum somewhere. If I'm wrong, I'd happily be corrected!
Okay, so I'll give a short account of what I've done so far:
I've enabled transport security, this is how the binding(s) looks:
<bindings>
<basicHttpBinding>
<binding name="basicHttp" closeTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
I've enabled meta data publishing over HTTPS using this line of code:
<serviceMetadata httpsGetEnabled="true" />
and this:
<endpoint address="" binding="mexHttpsBinding" contract="IMetadataExchange" />
Also, my second coworker has installed a trusted certificate (a real certificate from a CA) on the IIS server and added a https binding on the server.
Okay, so far, so good. Now we could connect to the services in the browser.
When we had done this it was possible to visit the service in the browser in a secure, encrypted, manner.
The problem is that it isn't possible to make a call to the service, neither in Android nor WCF Test Client. If I call the service on the https address, I get a 404 in response. WCF Test Client returns this:
There was no endpoint listening at https://[my service address] that could accept the message. This is often caused by an incorrect address or SOAP action.
To be able to debug this, I'm using Wireshark to intercept the messages and see what really happens. I've found out that after the set up procedures (handshake, establishing trust etc.) the client sends the header and get a 101 Continue in response, after which it POSTs the body. This should be normal behavior. But then the service returns 404 Not Found. Wireshark says that the full request URI is the http address. I've configured the server to use the https address, so why does it make a call to the http address?
I've tried setting the address and listenUri attribute of the endpoint to https and http respectively and the other way around. If I do that, the server answers the request with 405 Method Not Allowed.
Is there any way to solve this? What am I missing?
What am I missing?
TL;DR version below
I'm hosting three WCF SOAP web services with IIS, one using .NET 4 and the others using .NET 3.5. I'm trying to make a call from the WCF Test Client over HTTPS. I've enabled transport security, meta data publishing over HTTPS, installed a trusted certificate and added a https binding on the server.
When I try to make a call from WCF Test Client it says that there was no endpoint listening at the address. Wireshark tells me it makes the call to the http version of the service (i.e. "http://[my address]" instead of "https://[my address]"), although it is configured to call the https address. The service returns 404 Not Found. If I set the address of the service to https and listenUri to http, I get 405 Method Not Allowed. If I do it the other way around it says that it cannot be activated. What am I missing?
I solved this by removing the endpoint and using the <protocolMapping> tag, like this:
<protocolMapping>
<add scheme="https" binding="basicHttpBinding" bindingConfiguration="basicHttps" />
</protocolMapping>