Hi, thanks for responding.
I'm using it as follows:
I'm using POST.
http://query.yahooapis.com/v1/public/yql?q=....Here comes the query...
select * from contentanalysis.analyze where text=[Here comes a large text]
Sometimes I don't get any response and sometimes I get an error.
For example following text:
using CDATA in the Oracle Service Bus
17 Feb
In our project when an error occured the following Error structure must be returned to the service consumer.
E 99999 someDescription
In a case of a validation error the consumer would receive the following message where description is a concat of $fault/ctx:errorCode and $fault/ctx:reason
E 99999 BEA-382505 - OSB Validate action failed validation
The limitation here is off course that the real description (the $fault variable) is not visible for the service consumer. Since the $fault contains an XML-structure we need a mechanism as CDATA to encapsulate this in the response message.
The following blogpost is a simplified result of the actual project, but should give a general idea:
So we used the above solution with a Replace action in the common Error Handler. In our data model the element is repeating so we made a choice to add a second element.
E 99999 {$fault/ctx:errorCode/text()} - {$fault/ctx:reason/text()} E {$fault/ctx:errorCode/text()} {fn-bea:serialize($fault/ctx:details)}
This will result in a result like:
E 99999 BEA-382505 - OSB Validate action failed validation E BEA-382505
The bea-serialize function helps us to transform an XML input to a string output. Apparently there has been an update to the XPath Expression Editor in the OSB since the editor in 11.1.1.3 now automatically sets the CDATA definition.
In the past (the AquaLogic days) you explicitly had to define this with a function as:
fn-bea:serialize(xs:string(fn:concat("")))
Anoter solution would be to use XQuery in the error handler and the use of a namespace stripping function (as described here by Marc Keldermann) to clean-up the result of the $fault/details.
