In Office 2007, conversations are very strange and out of order when a message is view in it's own window.
For example, 3 messages would display as -
Message 2 header
<break>
Message 1 header
Message 1
Message 2
Message 3
This is very wierd, and all sorts of confusing, as you have to scroll to the bottom of the message to find the reply that has been sent.
The expected format should be -
Message 3
<break>
Message 2 header
Message 2
<break>
Message 1 header
Message 1
Does anybody know of a setting to change this? Thanks.
In the end, this turned out to be an error in the set up our our disclaimer software (Mail Exclaimer).
Related
I got a HL7 message with NTE segment. The HL7 message type RDE_O11 and version 2.5. While passing message with NTE, NHAPI is not parsing it. So with the following message,
MSH|^~\&|xxxx|xxxx|||||RDE^O11^RDE_O11||P|2.5||||||ASCII|||
PID||||||||||||N|||||||||
PV1|||||||||
ORC|||||||
RXO||||||||||||||||||||||||||
RXR||||||
RXE|||||M
NTE|1||#2 from 10/19/15 amb|RE
TQ1||
TQ1|||PO Q6H PRN|A||
RXR||||||
If I change the position of NTE right after MSH, NHAPI is able to parse it.
MSH|^~\&|xxxx|xxxx|||||RDE^O11^RDE_O11||P|2.5||||||ASCII|||
NTE|1||#2 from 10/19/15 amb|RE
PID||||||||||||N|||||||||
PV1|||||||||
ORC|||||||
RXO||||||||||||||||||||||||||
RXR||||||
RXE|||||M
TQ1||
TQ1|||PO Q6H PRN|A||
RXR||||||
What kind of error are you getting? The HL7 specification for the RDE_O11 message structure does allow NTE segments to appear after RXE (among several other locations). So it ought to work.
In my application, I am receiving a NewOrderMultiLeg message. The entire message is logged into the 'messages.log' file. But when I recevie the message into the onMessage(Message message, SessionID sessionID) method, I am getting only a part of the message, the message is getting truncated. i.e I only one element from the repeated group and the rest of the messages are truncated. I pasted here the message I recevied in log file and method.
Please help me to sort out this issue.
Message from application debugger.
8=FIX.4.49=10935=AB34=749=Server52=20150525-07:10:47.05956=TRADERINFO1=0.011=1250000163=1110=0228=0555=3635=0.010=075
Message from FIX logger.
8=FIX.4.49=24735=AB49=Server56=XXXXXXX34=452=20150525-07:08:14.71111=125000011=0.063=1635=0.0110=0228=0555=3616=9623=1687=10565=1616=3623=1687=10565=1616=13623=1687=10565=160=20150525-07:08:09.874152=1040=2376=XXXXXXXSERVER835=310=229
I am using FIX 4.4, quickfixj1.5.3.
Part of my config file
RejectInvalidMessage=N
ValidateFieldsHaveValues=N
ValidateIncomingMessage=N
ValidateFieldsOutOfOrder=N
ValidateUserDefinedFields=N
DefaultApplVerID=FIX.4.4
UseDataDictionary=Y
Thanks in advance.
Thanks
Bibin
I was missing one mandatory field 'LegSymbol' in InstrumentLeg component. In QuickFIX/J FIX4.4 dictionary shows 'LegSymbol' is non mandatory field but I found from some other sources, it is a mandatory field. Once I started receving the message with 'LegSymbol' field, my issues got sorted out.
Thanks
Bibin
Quickfixj is rejecting the following logon message:
8=FIXT.1.1|9=163|35=A|34=77086|1128=9|49=XXxVENUExXX|56=XXxUSxXX|52=20140704-11:24:22.308|108=4|98=0|1137=9|789=78069|58=RFA:f718fdb8-2ed3-4e0b-965f-4305188d06f9|1409=0|1407=100|10=013|
The actual log entry for it is:
20140704-11:24:22.316 ERROR [QFJ Message Processor] quickfixj.errorEvent - FIXT.1.1:XXxUSxXX->XXxVENUExXX: Rejecting invalid message: quickfix.FieldException: Tag appears more than once, field=1407: 8=FIXT.1.1^A9=184^A35=A^A34=77086^A49=XXxVENUExXX^A52=20140704-11:24:22.308^A56=XXxUSxXX^A1128=9^A58=RFA:f718fdb8-2ed3-4e0b-965f-4305188d06f9^A98=0^A108=4^A553=USRC^A554=test234^A789=7806 9^A1137=9^A1407=100^A1409=0^A10=093^A
Tag 1407 doesn't appear more than once though. We're using Quickfixj 1.5.3. With a FIX Version 5.0 SP2 - EP100 data dictionary. I can't see any issues with the data dictionary entries. The Logon message fields are all flat (except for the optional MsgTypeGrp which is not being used). Have tried with ValidateFieldsOutOfOrder as both Y and N. Config entries are:
[DEFAULT]
ConnectionType=initiator
HeartBtInt=4
FileStorePath=/dir/storeLoc
FileLogPath=/dir/logLoc
StartDay=sun
StartTime=09:55:00
EndDay=sun
EndTime=09:45:00
UseDataDictionary=Y
AppDataDictionary=/dir/dicLoc/QuickFIX_EP100.xml
TransportDataDictionary=/dir/dicLoc/QuickFIX_EP100.xml
ValidateFieldsOutOfOrder=N
EnableNextExpectedMsgSeqNum=Y
# Only the SP2 version supported
DefaultApplVerID=9
DefaultApplExtID=100
BeginString=FIXT.1.1
TargetCompID=XXxVENUExXX
TargetSubID=XXxSUBxXX
# Endpoint
SocketConnectHost=xxx.xxx.xxx.xxx
SocketConnectPort=XXXXX
[SESSION]
SenderCompID=XXxUSxXX
SenderLocationID=XXxLocxXX
Anyone have any ideas what could cause this. It couldn't be because there is '1407' in today's date?
I am new to telecom domain
I am trying to encode and decode the ranap errorIndication message.
but the specification specifies that
Procedure Code is to be used
if Criticality Diagnostics is part
of Error Indication procedure,
and not within the response
message of the same
procedure that caused the
error.
So if I include the procedure code of the failing message in the errorIndication message.Then the wireshark shows the errorIndication as the SACK of the failed message.
So I want to know how we can include the procedure code of the failing message in the errorIndication so that Wireshark should treat the message correctly.
Thanks in Advance.
A quick look at 3GPP TS 25.413 (RANAP signalling) shows that Criticality Diagnostics (9.2.1.35) is part of the Error Indication message (9.1.41).
In section 8.27, the spec says
The Error Indication procedure is initiated by a node to report detected errors in one incoming message, provided they cannot be reported by an appropriate failure message.
The definition for Procedure Code that you quoted in the question, makes it clear that the Procedure Code refers to a message that is NOT being replied to with the Error Indication.
In the Error Indication (section 9.1.41), there is also no code that refers to the message that caused the Error Indication.
The Error Indication information elements are
Message Type
Cause
Criticality Diagnostics (includes the Procedure Code that is causing the error)
CN Domain indicator
Global RNC ID
Global CN ID
Extended RNC ID
So, my conclusion, based on your description, is that I think Wireshark may have interpreted the spec wrongly. Wireshark seems to be looking for a message to which the Error Indicator is a reply.
But the Procedure Code is only supposed to tell you which message caused the error and should be re-sent. It's not supposed to tell you that the Error Indicator is a reply to that particular message.
Apologies if I am slandering Wireshark - if anyone comes up with an answer that proves me wrong, I will happily delete this post. Maybe you should ask this question on the Wireshark forum. I couldn't see anything like the issue you describe among the questions there.
Whenever Solr fails executing a query for some reason it returns an error message and an error code. I would like to handle such errors in Blacklight. Right now, when receiving an error from Solr, the user gets a 500 internal error. As a developer I can see that what happens is an RSolr::Error::Http in CatalogController#index with the following line of code as the source of the problem:
res = blacklight_solr.send_and_receive(path, :params=>solr_params)
Is it possible to customize the error handling so that I can at least display an indicative error message to the user instead of the unhelpful 500 internal error?
Open file lib\blacklight\catalog.rb. The function rsolr_request_error(exception) is responsible to handle Solr errors. The exception parameter is an RSolr::RequestError and it represents the error from Solr. In order to handle the error by displaying the message from Solr just add the following inside the else:
error_status = eval(exception.response[:body])['error']
if !error_status.nil? and !error_status['msg'].nil?
flash_notice = error_status['msg']
else
flash_notice = I18n.t('blacklight.search.errors.request_error')
end
If you wish to display a different message then assign a different message to flash_notice. If you wish to handle the error differently then this is where to do so.