When using the boxcarring functions of DSS from BPS, I get errors when starting/ending a session:
org.wso2.carbon.bpel.core.ode.integration.BPELFault: SOAP body doesn't contain required part
This seems to be because the SOAP body when returning from the call is empty. Is this a known bug?
I made my way around it in the bpel process by altering the wsdl and removing the return en fault mappings, but that does not seem a proper solution to me.
IMO your approach is correct way to solve this. Other way is fix the DSS service to return a valid message (if possible).
Related
I have built some RESTful api's with REstlet 2.3.4. I've been using HTTP_BASIC which let the browser prompt for credentials but it's time for a proper login form. I figure the easiest way to implement this is CookieAuthenticator. I can't find full working examples on github/google. I am sure i'm over looking them can someone provide a working example implementing CookieAuthenticator in Restlet?
I did get this to work after all. I have a longer answer here with some code examples. First, i was missing the fact that CookieAuthenticator is a filter and HAS the logic to handle login and logout. You need to create EMPTY ServerResources with a method annotated with #Post that has nothing in the body. Second, extend CookieAuthenticator and overwrite isLoggingIn(..) and isLoggingOut(..) with the code found in the link.
Cheers,
-ray
My question may first of all seem to have a duplicate but i have hit something that has suprised me. Yaws Webserver comes with a complete set SOAP example, but when i tried running it as is, this is what i get:
In text form, this is what i see in the shell:
1> inets:start().
ok
2> yaws_soap_lib:call("http://www.webservicex.net/WeatherForecast.asmx?WSDL","GetWeatherByPlaceName",["Boston"]).
=ERROR REPORT==== 15-Apr-2013::20:32:11 ===
Call to tuple fun {erlsom_parse,xml2StructCallback}.
Tuple funs are deprecated and will be removed in R16. Use "fun M:F/A" instead, for example "fun erlsom_parse:xml2StructCallback/2".
(This warning will only be shown the first time a tuple fun is called.)
{error,{decoding,"Malformed: Illegal character in prolog"}}
3> yaws_soap_lib:call("http://www.webservicex.net/WeatherForecast.asmx?WSDL","GetWeatherByPlaceName",["Boston"]).
{error,{decoding,"Malformed: Illegal character in prolog"}}
4>
You could try the yaws example following this page.
Another problem, is that i have tried other SOAP libraries like detergent and erlsoap and they are either too old or completely un-usable. Most of the solutions, even yaws, mentions his dependency on erlsom i pretty think for the XML parsing. But, i can hardly use erlsom single-handedly to offer soap services.
Somebody provide some information on how i can work with soap services (both a sa client and server) in erlang, and please explain the error i am getting with yaws. I am using the latest yaws version and erlang 15B.
This is an ugly hack, but here's how I deal with SOAP requests:
Write a function/module that wraps the following:
Set up some request templates (static XMLs) and fill them up with erlydtl
Make a HTTP POST request (using your client of choice) with SoapAction header set.
Take off the important stuff from the response using erlsom
From the official documentation we can read the following:
Tuple funs (a two-element tuple with a module name and a function) are
now officially deprecated and will be removed in R16. Use 'fun M:F/A'
instead.
So, Yaws should be updated. As a workaround, you have at least two options:
the Detergent library
Or, if you don't mind using the (not so) older Erlang R15, I believe it should work, as other users reported.
How can I get 2 or multiple responses back from a CXF based RESTFul webservice for a single call.
For example : For this http://localhost:8080/report/annual, I would like to get 2 JSON reponses back. The first one will give me the information about the report details & some other information. The second reponse will give me the actual report JSON. If these 2 be delivered async that will be really good.
I'm with #flesk, this really isn't a REST approach, this is more of an async messaging approach.
The first call should return "someinfo" after it starts the "actualReport" processing (in a separate thread/process since "actualReport" is time consuming). Then make a second call for "actualReport" and make sure the timeout value on that call is set high enough to let the report processing complete.
You could get fancy and loop on the second call, returning a 404 until the report is complete.
There are a number of ways to get what you want, just not with one RESTful call.
You can't. Why would you want to do that anyway, when you can just return something like
{"someInfo": {...}, "actualReport": {...}}
I am trying to develop SOAP based webservice using CXF. My requirement is to accept any XML data structure as method parameter and then the logic to parse/handle this data would be internally taken care by webservice (A generic webservice for accepting request).
Hence I want to declare the method parameter as either org.w3c.dom.Element or org.w3c.dom.Document. I tried declaring method with these types but it gave an error.
Can anyone please let me know how, I can achieve this? I dont want to use REST approach.
Would a Provider based service work? Alternatively, make the method param a DOMSource or just Source. That may work better.
When coding web services, how do you structure your return values? How do you handle error conditions (expected ones and unexpected ones)? If you are returning something simple like an int, do you just return it, or embed it in a more complex object? Do all of the web methods within one service return an instance of a single class, or do you create a custom return value class for each method?
I like the Request/Response object pattern, where you encapsulate your arguments into a single [Operation]Request class, which has simple public properties on it.
Something like AddCustomerRequest, which would return AddCustomerResponse.
The response can include information on the success/failure of the operation, any messages that might be used by the UI, possibly the ID of the customer that was added, for example.
Another good pattern is to make these all derive from a simple IMessage interface, where your general end-point is something like Process(params IMessage[] messages)... this way you can pass in multiple operations in the same web request.
+1 for Ben's answer.
In addition, I suggest considering that the generic response allow for multiple error/warning items, to allow the reply to be as comprehensive and actionable as possible. (Would you want to use a compiler that stopped after the first error message, or one that told you as much as possible?)
If you're using SOAP web services then SOAP faults are the standard way to return error details, where the fault messages can return whatever additional detail you like.
Soap faults are a standard practice where the calling application is a Soap client. There are cases, such as a COM client using XMLHTTP, where the Soap is parsed as XML and Soap faults cannot be easily handled. Can't vote yet but another +1 for #Ben Scheirman.