Im getting this error:
(a:6016) The message with Action 'xxx'
cannot be processed at the receiver,
due to a ContractFilter mismatch at
the EndpointDispatcher. This may be
because of either a contract mismatch
(mismatched Actions between sender and
receiver) or a binding/security
mismatch between the sender and the
receiver. Check that sender and
receiver have the same contract and
the same binding (including security
requirements, e.g. Message, Transport,
None).
And I noticed that the binding used by my provider's WSDL is:
BasicHttpBinding_IxFlow
I guess I need to specify that in my Savon Controller. How can I do that?
Thx.
Since the error message is not really helpful (received this one for various errors) here are some suggestions:
try calling the service (or just generate the xml) from another client and record the XML
compare with Savonrb XML (it prints it to the console, not pretty formatted but good enough)
send the XML you captured from another client trough savon. Does this work? (you can specify custom XML with the block version of client#request method)
Look at (this was the problem with my service):
Order of parameters
Namespace of parameters
SOAPAction header (you can also specify it in the block version)
Related
Because I am rewriting a legacy app, I cannot change what the clients either send or accept. I have to accept and return JSON, HTML, and an in-house XML-like serialization.
They do, fortunately set headers that describe what they are sending and what they accept.
So right now, what I do is have a decoder module and an encoder module with methods that are basically if/elif/else chains. When a route is ready to process/return something, I call the decoder/encoder module with the python object and the header field, which returns the formatted object as a string and the route processes the result or returns Response().
I am wondering if there is a more Quart native way of doing this.
I'm also trying to figure out how to make this work with Quart-Schema. I see from the docs that one can do app.json_encoder = <class> and I suppose I could sub in a different processor there, but it seems application global, there's no way to set it based on what the client sends. Optimally, it would be great if I could just pass the results of a dynamically chosen parser to Quart-Schema and let it do it's thing on python objects.
Thoughts and suggestions welcome. Thanks!
You can write your own decorator like the quart-schema #validation_headers(). Inside the decorator, check the header for the Content-Type, parse it, and pass the parsed object to the func(...).
Within a Mirth Connect installation (version 3.5.1), I have setup a channel TCP (LLP) that receive a message HL7 and send an XML with the data of the PID segment (plus some of other useful informations about the HL7 message) to an external site.
I want to validate the message (if contains an error) and filtering the message according to some rules for the data of the segment PID (no name, no surname, etc).
To accompish this requirement, I have write a simple javascript filter and set in the channel (from Summary tab) the strict validation.
But I have this behavior.
If I don't use the strict validation option for the messages, I get all the data of the segment PID within tags like PID.1, PID.2 etc (e.g. for the name I have the following XML structure <PID.5><PID.5.1>XXX</PID.5.1>....</PID.5>).
Instead, if I use the strict validation option the message (in the filter) became different and other tags are present (e.g. for the name I have the following XML structure <PID.5><XPN.1><FN.1>XXX</FN.1></XPN.1>....</PID.5>).
Someone know the why I have this behavior? It is caused by some misconfiguration? Or it is the normal behavior?
Thanks at all for the support.
UPDATE
I realized only now that the structures were not visible.
Now, yes.
Thanks again at all for the support.
This is normal behavior. The default parser is implemented in the mirth hl7v2 datatype itself. When you use the strict parser, it uses the HAPI parser which produces the alternate xml you are seeing that actually conforms to the hl7 specification.
The following URI triggered an error in the public OData service:
http://services.odata.org/V4/Northwind/Northwind.svc/Suppliers?$filter=Address eq '<A'
Entity type Supplier contains property Address of type Edm.String. So, the value of Address may contain any UTF-8 character from the definition (see section 6. Primitive data types).
The server responds with:
Runtime Error: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons).
Is the there something wrong with this URI or it is really a problem on the server side (e.g. inappropriate parsing of the $filter query option)?
You should encode your query URL, e.g. with help of
http://prasannaadavi.com/2014/06/handling-special-characters-in-odata-queries.html
How are special characters handled in an oData query?
In your special case you should try encoding "<A" with "<A"
--> found in https://web.archive.org/web/20150101222238/http://msdn.microsoft.com/en-us/library/aa226544(SQL.80).aspx)
We are trying to write a iRule for the BIG-IP universal persistence module.
Our mission is to extract and persist from a HTTP response payload/body an application unique identifier (something like a seesionid for us).
Then use it in a consecutive HTTP requests.
Note, this unique identifier return in text/xml/soap-xml response formats and there is no cookie involve here.
We're having problem to write the TCL code for the extraction of our custom unique identifier from the HTTP response payload/body.
We have checked these manuals and did not find example for this kind of functionality:
https://devcentral.f5.com/wiki/iRules.HTTP_RESPONSE.ashx
https://devcentral.f5.com/wiki/iRules.HTTP__payload.ashx
Thanks.
Here's an example with jsession IDs that should get you started with basic persistence flow, and this example gives you an idea on how to work with payload data.
What error format must be used by RESTful API when content negotiation fails (ActionController::UnknownFormat is raised):
when a controller responds to the only one format (e. g. JSON) and the user has requested another one (e. g. XML), should the error be generated as JSON object or XML one?
when a controller responds to several formats and the user has requested neither of them, which one should be used during error generation: one of the 'known' by the controller or the one, having been requested by the user?
I think you are under no obligation to respond to any invalid request with the same format as the request was made. Imagine getting a request with payload in unknown binary format - what are you supposed to do in such a case.
ActionController::UnknownFormat should trigger a 406 Not Acceptable response, probably will in Rails 5.
You should rescue the ActionController::UnknownFormat and respond with proper HTTP code as well as set an Accept header listing all formats that your API supports (if Rails doesn't do it by default, I'm not sure)