I am calling to Business service in route. The Business is based on XML messaging.
Sometimes after a route calling I receiving the following error:
"ErrorBEA-382030 Failure while unmarshalling message: Failed to parse
XML text "
and the body is deleted.
I can't change the type of messaging from XML. Is there is other solutions?
Check the response coming from the Provider service. The XML being sent is not proper. Try to run Business Service directly.
Related
I am attempting to create a custom identity provider (based on https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/tree/master/test/TestIdPCore) but using HTTT-POST binding. The issue I am having is that when the service provider tries to validate the authn response they are getting errors ("actual digest value does not match expected"). I have also attempted to use a third party tool validating the xml response and was getting an error like "The XML has been altered after signing."
I am signing the assertion on the response using a certificate in the key store on the server where the service is running.
The XML need to keep the same plain format for the signatur validation to succeed.
You probably need to debug to find the problem.
Do you IdP work with a sample RP, e.g. https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/tree/master/test/TestWebAppCore
Do you have different RP's and do someone work?
I'd like to validate the (JSON) input to a Logic App, which I can do using the Schema Validation option:
Can I customise the error message this sends back? My API design has a particular format for the body of a non-success response that we would like to conform to.
I tried setting a response action immediately after the trigger and specifying "Run After" as Failed but the designer won't allow this.
The schema validation in HTTP trigger couldn't modify the message, so maybe you could don't validate the json data in trigger.
You could use Parse JSON action to parse the data to json and validate it. For details you could refer to this blog: Validating Json Schema in Azure Logic Apps. The create the response action and set it run after Parse JSON has failed.
You could custom the status code and the response body. I test with outputs('Parse_JSON')['errors'][0]['message'] it will send the Parse_JSON action error message. With this way, you could use parallel branch to create actions after the Parse_JSON success.
I would like to get the request XML in my Web service method and would like to save it. I know I can use LoggingInInterceptor to do that. However, I do not want to use it. The reason is when I save the request XML, I would like to perform user validations, get the client name and use the client name as the File name to save it.
Is there a way I can get the request XML in my Web service method.
No, you cannot. But you can write a generic HTTP service which gets the text content of a request.
I'm pretty new to camel so perhaps I'm going about this the wrong way but I'm routing messages from one endpoint to another and transforming them on the way. However the next stage is to add authentication to the pipeline. I have a service that tracks authenticated users. My plan is to, in the first stage of the route, to add a filter that checks to see if the current user is authenticated. If the user is not I want to transform the message into an authentication request and send that to my endpoint. All good so far, however, after authentication (if successful) I want to send the original message down the pipeline. Is this something that can be done?
A simplified version of my route would be:
from("seda:in").
filter(method(Authentication.class, "isNotAuthenticated")).
bean(AuthenticationTransformer.class)
to("cxfbean:out")
.end()
.bean(RequestTransformer.class)
.to("cxfbean:out")
The same message would be sent to both transformer beans.
You should preserve the message in the Exchange property setProperty("originalMessage", body()) before transforming it. Afterwards you can access that property using getProperty("originalMessage")
When calling a web service from Force.com, I am getting:
System.CalloutException: Web service callout failed: Unexpected
element. Parser was expecting element
'http://schemas.xmlsoap.org/soap/envelope/:Envelope' but found ':HTML'
The network guys at the other end has asked to see the full response that Salesforce is getting from their server.
Is there a way to achieve that? I have tried running with debug level 'Finest' from execute anonymous, but that yields the same little message with no further detail.
The message you are getting is because an error is generated as Saleforce is trying to parse the response is and it isn't logged unfortunately.
The parsing error is happening because instead of a SOAP message response you are getting an HTML page. This usually happens when you are accessing a service that is protected behind a firewall. Which means you may be able to see the service when browsing on your computer but remember that Salesforce is outside of your firewall and thus any communication by Salesforce to your service will be blocked.
Couple of ways to address this but this wiki topic from Salesforce best covers the options:
http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_om_outboundmessaging_security.htm
The above is specific to outbound messaging but essentially the technology issues are the same.
Don't forget that Apex includes an HttpRequest Class that works as a lower layer than the SOAP APIs. You should be able to write up a test method that sends a hard-coded XML request to the server and dumps the HttpResponse so you can see it.
Adding my own best answer, based on some internet research:
You can use an external tool like Runscope as a webservice proxy to automatically forward requests and pass through responses and view the XML SOAP messages. This is not a native solution on SFDC but it does do the job.
https://www.runscope.com/
The issue is that Force.com is trying to parse a SOAP response that's actually just HTML. This happens sometimes when an error occurred server-side and the response is meant for a browser to display, rather than sending back an exception report via a properly formatted SOAP response.
If they can't figure out why they are not sending back a consumable SOAP response, then you can try using other tools (outside of Force.com) to make the same webservice call from your browser and then see what the HTML actually says on return.