I have a problem with WSO2, I have an application that provides me a WS in a version that takes into account application/soap+xml and another only text/xml.
But when I send the flow, it does not manage to receive it because it is soap+xml, I changed the content type in the message by text/xml, it sends the flow but does not work because wso2 removes the SOAP envelope, I do not see how to do someone has he an idea?
You need to configure the address endpoint format. It could be either SOAP 11 or SOAP 12, which is the SOAP version supported by backend (I believe it's SOAP 11 in your case as it expects text/xml content-type).
It can be configured under Endpoint Configurations in Endpoints tab in Publisher portal.
You need to select the relevant SOAP version as Format under Message Content, select Leave As-Is as the Optimize option under Message Content and save the changes. Refer the screenshots below:
Related
I have a service like this
MPGW <===> WSP <===> Backend
On the response, I have an attachment which I was expecting the type to be 'XOP' but instead I'm getting 'MIME' . Is there any way I can over ride to XOP?
FYI...when I hit the service directly the back-end (by passing datapower), I'm getting XOP attachment type.
Processing MTOM with SOAP 1.1 is not supported in DataPower so make sure you are using SOAP 1.2.
You need to check if it is the WSP (likely) or the MPGW that is changing the response. This you can do using the Probe.
You can handle the attachments in a MTOM Policy for the service. Also use pass-through if possible for the MPGW to make sure it is not changing the payload.
I'm trying to get a project that was made in Mule 3.4 working in Mule 3.7. In Mule 3.4, using the HTTP endpoint-based Connector it was possible to retrieve multiple cookies from response messages by using:
Object cookieObj = message.getInboundProperty("Set-Cookie");
String cookieValSchoolname = CookieHelper.getCookieValueFromCookies (cookieObj, "schoolname");
String cookieValJSessionId = CookieHelper.getCookieValueFromCookies(cookieObj, "JSESSIONID");
In Mule 3.4, using the HTTP endpoint-based Connector, the inbound property "Set-Cookie" contained an array of all the cookies that are set with Set-Cookie in the http header.
However when I use the same code with the new HTTP operation-based Connector, the inbound property "Set-Cookie" only contains the first cookie and not an array with all cookies.
Can anybody tell me how I can access all cookies using the new HTTP Connector?
Maybe there is a way to retrieve the raw http header, to parse that?
The only other inbound properties the message has are content-length, http.reason, http.status, content-type, server and date.
This is a bug. You can check the fix versions there. Cannot think of any workarounds unfortunately.
As far as Anypoint studio is concerned, mulesoft blog says "Anypoint Studio 5.3 with Mule 3.7.2 released!". If possible have that downloaded and do let us know if the issue is fixed. It might help others too.
The flow is SAP NWAS 7/Java AS ---> Apigee On Premise--->Apigee OnCloud -----> Backend. and back.
Backend is posting a response of appx 17 MB back. I have streaming enabled both on cloud and on premise Apigee. But the sap NWAS client states that only partial response is received .
When we invoke from POSTMAN however, we are getting complete response.
Please suggest where the problem can be?
Since Postman works fine for you, it seems like it might be a problem on the client side. So, it's possible that the client requires more info on the response in order to be able to display the content e.g. Content-Type header. Another way to troubleshoot this issue is to send a cURL command to the resource in Apigee and store it in the filesystem to validate that not only Postman can parse the response. e.g.
curl http://yourresourcehere/images/12344 > img12344.png
A JavaScript client that I have no control over is sending the incorrect HTTP request headers to my Web API services. More specifically, it's using a library that is sending an incorrect OData header.
Is there any way that I can intercept the HTTP request before it hits my services? Can I add/remove/update headers or query string info?
For instance, if I receive the following HTTP header:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 2.0
I'd like to know how to modify it to the following before the OData libraries take over:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 4.0
The header isn't incorrect. Your client expects an OData v2 service and even if you did manipulate the headers, it probably won't be able to understand the response from your server.
But you could use a simple HTTP proxy to rewrite the headers if you really want to try that route.
If you do that, make sure your OData server supports the Atom format because the OData JSON format changed completely between versions 2 and 4, so there's no way that JavaScript client will understand it. The Atom format changed as well, but if the client's parser is extremely lenient, it might work.
I have to use a 3rd party web service implemented in .NET 2.0 (on IIS, of course).
I have to make a java client. I am using wsdl2java to generate the SOAP stub.
As the original Apache Axis project now appears unmaintained, and I was having some problems parsing some responses from the service, I converted the client to use the latest (1.5) version of Axis2. Now, the .NET service won't even recognize my requests.
I managed to get the "chunking" turned off (where "stub" is a variable of type MumbleStub generated by wsdl2java, and I am showing what are several lines of code as one horrific line here):
stub._getServiceClient().getOptions().setProperty( HTTPConstants.CHUNKED, Boolean.FALSE);
.. so at least the service recognizes my request AS a request, albeit a bad one: "HTTP/1.1 400 Bad Request" is the response now (as opposed to an "intro / summary" page offering me a link to the WSDL).
I noticed that the Axis ("1") request had a different Content-TYpe header (text/xml, vs application/soap-xml), and I am wondering how to change this request header, if that is in fact the problem.
Alternately, has anybody else had this problem? Is the problem really the (undisplayable here, as it looks like "element injection" to the blog engine) ... xml version-"1.0" ... "XML meta intro tag" that Axis2 added to the beginning of the request?
WS-Deathstar, indeed.
As you mention the different content-type header I guess your client tries to send SOAP 1.2 requests and the 3rd party app only understands SOAP 1.1
Try changing the used soap version as AFAIK AXIS2 uses SOAP 1.2 by default
stub._getServiceClient().getOptions().setSoapVersionURI(org.apache.axiom.soap.SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI);