QuickFIX/J: Is there any way to modify the logon response sent by the server - fix-protocol

I am building a FIX adapter and the server I am hitting to response with 1137=FIX.5.0SP2.
My understanding is that 1137/DefaultApplVerId should be an enum. And QuickFIX/J throws up because it is expecting an enum value like 9.
13:46:00.628 [NioProcessor-12] ERROR quickfixj.errorEvent - org.quickfixj.QFJException: Unknown or unsupported ApplVerID: FIX.5.0SP2
org.quickfixj.QFJException: Unknown or unsupported ApplVerID: FIX.5.0SP2
Since I have no control over how the server responds. So my question is if there is any way for me to intercept and modify the response before it gets parsed by QuickFIX/J?

Related

Error while raising fault from the DUT to Onvif Device test tool in the test case

Error while raising fault from the DUT in the test case.
==========================================================
In the test case EventProperties>RealTimePullPointNotification
Interface>EVENT-3-1-17-v14.12 REAL TIME PULL POINT
SUBSCRIPTION-INVALID MESSAGE CONTENT FILTER the DUT sends fault
message to client.
While validating the fault in the client(Onvif
Device Test Tool Ver 6.12) I am getting the error No Action element
from namespace Addressing10 (http://www.w3.org/2005/08/addressing).
I set the wsa:Action Element to http://www.w3.org/2005/08/addressing/soap/fault then also i am getting
the above error.
The output from onvif device test tool is as below:
EVENT-3-1-17-v14.12 REALTIME PULLPOINT SUBSCRIPTION - INVALID MESSAGE CONTENT FILTER
STEP 4 - Create Pull Point Subscription - negative test
StepStart: 2019-11-13T17:18:31.6582116Z
Transmit done
Receive done
SOAP fault returned
Code: Sender
Reason: InvalidMessageContentExpression
Validate fault...
*No Action element from namespace Addressing10 (http://www.w3.org/2005/08/addressing). Expected element with value: http://www.w3.org/2005/08/addressing/soap/fault.*
STEP FAILED
TEST FAILED
My XML which sends error from DUT to client is as below:
========================================================
*std::string soapFault =
"<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope">"
"<SOAP-ENV:Header xmlns:wsa="http://www.w3.org/2005/08/addressing" >"
"<wsa:MessageID>"
"urn:uuid:c9517d6a-44e7-427a-a1f4-6902eb52a979"
"</wsa:MessageID>"
"<wsa:ReplyTo SOAP-ENV:mustUnderstand="true">"
"<wsa:Address>http://192.168.0.95:8082/onvif</wsa:Address>"
"</wsa:ReplyTo>"
"<wsa:To SOAP-ENV:mustUnderstand="true">http://192.168.0.95:8082/onvif/event_service</wsa:To>"
"<wsa:Action SOAP-ENV:mustUnderstand="true">"http://www.w3.org/2005/08/addressing/soap/fault"</wsa:Action>"
"</SOAP-ENV:Header>"
"<SOAP-ENV:Body>"
"<SOAP-ENV:Fault>"
"<SOAP-ENV:Code>"
"<SOAP-ENV:Value>SOAP-ENV:Sender</SOAP-ENV:Value>"
"<SOAP-ENV:Subcode>"
"<SOAP-ENV:Value>ter:InvalidArgVal</SOAP-ENV:Value>"
"<SOAP-ENV:Subcode>"
"<SOAP-ENV:Value>ter:InvalidMessageContentExpression</SOAP-ENV:Value>"
"</SOAP-ENV:Subcode>"
"</SOAP-ENV:Subcode>"
"</SOAP-ENV:Code>"
"<SOAP-ENV:Reason>"
"<SOAP-ENV:Text xml:lang="en"/>"
"</SOAP-ENV:Reason>"
"<SOAP-ENVetail>"
"</SOAP-ENVetail>"
"</SOAP-ENV:Fault>"
"</SOAP-ENV:Body>"
"</SOAP-ENV:Envelope>";*
From ยง9.9 of the ONVIF Core Specs:
9.9 SOAP Fault Messages
If a device encounters a failure while processing [WS-BaseNotification] messages from either a client or
Subscription Manager, then the device shall generate a SOAP 1.2 fault
message.All SOAP 1.2 fault messages shall be generated according to
[WS-BaseNotification] and [WS-Topics] specifications with one
exception;
All faults shall use the following URI for the
WS-Addressing [action] Message Addressing
Property::
http://www.w3.org/2005/08/addressing/soap/fault
Furthermore
the error should be sent as a SOAP receiver fault (env:Receiver), i.e.
the HTTP error code shall be 500.

Appropriate status code for a invalid form

The data could not have been inputted by a typical user due to client-side validation. Is "400 Bad Request" the appropriate status code?
If you are certain the form is invalid 400 Bad Request is acceptable. However depending on why you believe a form is invalid you may also choose to use
status code 422 Unprocessable Entity.
This status code is designed to handle the use case where an submitted request is understood by the server and the request is syntactically correct, but the server was unable to process the instructions contained within the request.
Another possibly appropriate error code would be 415 Unsupported Media Type. This error code should be used when the server fails to understand the request due to an invalid type of form. For example, if a server expected a JSON value but was given XML it should in theory return a 415 Unsupported Media Type code.

Intercept/Callback for QuickFIX message

I am using a FIX protocol to communicate with one of our counterparties. I have used Camel with Spring to build my communication routes.
I have a requirement where in my counterparty is expecting an ACK for every request it sends to me.
For example:
TradeCaptureRequestAck in response to TradeCaptureRequest
AllocationReportAck in response to AllocationReport
Confirmation_Ack in response to Confirmation
They are expecting a response irrespective of what happens at our end (even if something fails or exception occurs).
One way I know we can intercept the incoming message via MessageFactory. We can create a custom messagefactory and inject it in while creating QuickFixJComponent bean.
Problem with this approach is at factory level I will just be able to get the message type like TradeCaptureReport, AllocationReport etc. but not the content because factory only creates (and returns) the appropriate Message object. Actual work of populating this message object with incoming message data happens in Session class I guess (not sure about this).
Can someone please tell me if there is a way I can get or intercept the request message as soon as it reaches the route so that I can send the appropriate ACK to counterparty?

Coldfusion Webservice and SOAP

I am using coldfusion and IIS 7.5
Problem is that when the web service has 500 error, it returns HTML instead of XML.
Can anyone help me in fixing this please.
Thanks.
This is an Internal Server Error, may have occurred because of a data type mismatch. The server is expecting one data type but you are sending a different data type for the input parameter. Please check the input format of the web service that you are calling.
For example: If you try to consume a web service method which takes a SOAP object as an input parameter and you call that method with a different parameter other than SOAP the server will throw a 500 error.

Proper way to convey error messages during calls to a REST service?

I'm writing a REST based web service, and I'm trying to figure out the best way to handle error conditions.
Currently the service is returning HTTP Errors, such as Bad Request, but how can I return extra information to give developers using the web service an idea what they're doing wrong?
For example: creating a user with a null username returns an error of Bad Request. How can I add that the error was caused by a null username parameter?
According to the HTTP spec, the text that comes after the three digit response code, the "Reason-Phrase", can only be replaced with a logical equivalent. So you can't respond with 400 null user and expect anything useful to happen. Indeed, The client is not required to examine or display the Reason- Phrase.
In general, the HTTP response entity (typically the page that accompanies the response) should contain information useful to the client to guide them forward, even when the response is an error. On the web, most such errors are HTML, and are devoid of machine readable information, but most browsers do show the error to the user (and SO's error page is pretty good!).
So for a primarily machine readable resource you have two options:
Pass a human readable message anyway. Return 400 Bad Request with a HTML response, which the client may opt to show to the user. It's dead easy but it's a bit like throwing an unchecked exception, it passes all the hard work to the client, or indeed the end user.
Allow clients to recover. Return 400 Bad Request with a machine readable response which is part of your API, so clients can recover from known error conditions. This is harder, like throwing a checked exception, it becomes part of the API, and it allows clients to recover gracefully if they want to.
You could even make the server support both scenarios by defining a media type for the machie readable error recovery document, and allow clients to "accept" them: Accept: application/atom+xml, application/my.proprietary.errors+json
Clients that forget the mandatory field can opt in to getting machine readable errors or human readable errors by choosing to Accepting the error media type.
It's stated in the HTTP spec that most error codes should return some basic text that gives a clarification of why the error is being returned. The basic Java Servlet Spec defines the HttpServletResponse.sendError(int Code, String message) for this purpose.
String desc = "my Description";
throw new WebApplicationException(Response.status(Status.BAD_REQUEST).entity(desc).type("text/plain").build());