I have to send HL7 message to web service. I am adding CHAR(13) (carriage return or \r) as segment terminator in stored procedure and calling a web service to send the HL7 message. When the service receives the message they are saying I am adding extra CHAR(10) (line feed or \n ) in my segment terminators. I have looked into my values and just before sending it only has \r as segment terminators. How to make sure that the service also receives it as only \r without extra \n. I have looked around but haven't found any solution so far.
Have you looked at the message in Fiddler or TCP Spy depending on how you are sending your message?
It will at least prove if you are providing anything other than the /r
I've been caught by messages having multiple ways of breaking the line. \r, \n and also a combo of the 2.
Have you tried redirecting the message to somewhere you can actually read yourself at different stages of the processing? It's getting changed somewhere and reading it out at different stages caught the error for me. Or just a series of the below at different stages.
content = hl7message.read()
if "\n" in content:
print "ERROR"
Related
This is my first time using Lua, and with following a tutorial, Im making a chat program, allowing two players to send and receive messages to each other. The receiving is called chatreceive.lua. The script is:
rednet.open("right")
sender, message = rednet.receive()
print("computer " .. sender .. " has sent :")
print(message)
I keep getting an error saying
chatreceive.lua:3: attempt to concatenate global 'sender' (a nil value)
Any solutions? Ive been trying for a while now
That means that the variable 'sender' was nil. This probably means that there was some sort of error with rednet. You should add a lot of checks to make sure your programs don't fail in critical situations:
if sender==nil then
print("SENDER IS NIL!!!")
end
Also, what version of CC are you using? You shoud be more specific, to get better answers...
Interesting about how the server detect the end of client's message in https://www.rfc-editor.org/rfc/rfc4315
As I know multipart/mixed contains a lot of empty lines, it would be wrong using just CRLF.
Messages and similar multiline structures are preceded by a byte count.
> A1 APPEND INBOX {4082}\r\n
< + Go ahead\r\n
> (4082 bytes of message follow)\r\n
Simple as that.
We have an API as a proxy between clients and google Pub/Sub, so it basically retrieves a JSON body and publishes it to the topic. Then, it is processed by DataFlow, which stores it in BigQuery. Also, we use transform UDF to, for instance, convert a field value to upper case; it parses JSON sent and produces a new one.
The problem is the following. The number of bytes sent to the destination table is much less than to the deadletter, and the error message is 99% percent contains the error saying that the sent JSON is invalid. And that's true, the payloadstring column contains distorted JSONs: they could be truncated, concatenated with other ones, or even both. I've added logs on the API side to see where did the message set corrupted, but neither received or sent by the API JSON bodies are invalid.
How can I debug this problem? Is it any chance of pub/sub or dataflow to corrupt messages? If so, what can I do to fix it?
UPD. By the way, we use a Google-provided template called "pubsub topic to bigquery"
UPD2. API is written in Go, and the way we send the message is simply by calling
res := p.topic.Publish(ctx, &pubsub.Message{Data: msg})
The res variable is then used for error logging. p here is a custom struct.
The message we sent is a JSON with 15 fields, and just to be concise I'll mock it and UDF.
Message:
{"MessageName":"Name","MessageTimestamp":123123123",...}
UDF:
function transform(inJson) {
var obj;
try {
obj = JSON.parse(inJson);
} catch (error){
throw 'parse JSON error: '+error;
}
if (Object.keys(obj).length !== 15){
throw "Message is invalid";
}
if (!(obj.hasOwnProperty('EventSource') && typeof obj.EventSource === 'string' && obj.MessageName.length>0)) {
throw "MessageName is absent or invalid";
}
/*
other fields check
*/
obj.MessageName = obj.MessageName.toUpperCase()
/*
other fields transform
*/
return JSON.stringify(obj);
}
UPD3:
Besides being corrupted, I've noticed that every single message is duplicated at least once, and the duplicates are often truncated.
The problem occurred several days ago when it was a massive increase in the number of messages, but now it got back to normal, and the error is still there. The problem was seeing before, but it was a much more rare case.
The behavior you describe suggests that the data is corrupt before it gets to Pubsub or Dataflow.
I have performed a test, sending JSON messages containing 15 fields. Your UDF function as well as the Dataflow template work fine since I was able to insert the data to BigQuery.
Based on that, it seems your messages are already corrupted before getting to Pub/Sub, I suggest you to check your messages once they arrived to Pub/Sub and see if they have the correct format.
Please notice that it's required for the messages schema match with the BigQuery table schema.
I am using emqtt message broker for mqtt.
I am not a erlang developer and has zero knowledge on that.
I have used this erlang based broker, because after searching many open source broker online and suggestions from people about the advantage of erlang based server.
Now i am kind of stuck with the out put of the emqttd_cli trace command.
Its not json type and if i use a perl parser to convert to json type i am getting delayed output.
I want to know, in which file i could change the trace log output format.
I looked on the trace code of the broker and found a file src/emqttd_protocol.erl. An exported function named trace/3 has the code that you need.
Second argument of this function, named Packet, has the information of receive & send data via broker. You can fetch required data from it and format according to how you want to print.
Edit : Sample modified code added
trace(recv, Packet, ProtoState) ->
PacketHeader = Packet#mqtt_packet.header,
HostInfo = esockd_net:format(ProtoState#proto_state.peername),
%% PacketInfo = {ClientId, Username, ClientIP, ClientPort, Payload, QoS, Retain}
PacketInfo = {ProtoState#proto_state.client_id, ProtoState#proto_state.username, lists:nth(1, HostInfo), lists:nth(3, HostInfo), Packet#mqtt_packet.payload, PacketHeader#mqtt_packet_header.qos, PacketHeader#mqtt_packet_header.retain},
?LOG(info, "Data Received ~s", [PacketInfo], ProtoState);
I have a RPG program A and a CL program B. A accepts some user input from display file and use it as the entry parameter of B. b processes the entry parameter, and if there is an error the message will be received and resent by B so that it will be displayed on the bottom of the display file using message subfile. This message displaying mechanism works but not completely, as the message sent could only be glanced in a very short period of time, then it disappeared from the display file. What would be the cause of this problem? How to stop the message from disappearing?
Here is the sample code inside program B:
DCLF FILE(ECSWIFP1)
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR))
OVRDBF FILE(ECSWIFP1) TOFILE(ECSWIFP1) SHARE(*YES)
OPNQRYF FILE(ECSWIFP1) QRYSLT(&QRYSTR)
RCVF
CLOF FILE(ECSWIFP1)
DLTOVR FILE(ECSWIFP1)
RTVDTAARA DTAARA(&E4LIBN/&E4OBJN) RTNVAR(&DTARVAL)
GOTO CMDLBL(END)
ERROR:
CLOF FILE(ECSWIFP1)
MONMSG MSGID(CPF4520)
DLTOVR FILE(ECSWIFP1)
MONMSG MSGID(CPF9841)
MSG:
RCVMSG MSGTYPE(*ANY) MSGDTA(&MSGDTA) MSGID(&MSGID)
IF COMD(%SST(&MSGID 1 3)) *NE 'CPF') THEN(GOTO CMDLBL(MSG))
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGDTA(&MSGDTA) MSGTYPE(*STATUS) TOPGMQ(*EXT)
END:
ENDPGM
And here is part of the display file DDS for displaying message:
A R MSG SFL
A SFLMSGRCD(24)
A S0MSGK SFLMSGKEY
A S0PGMQ SFLPGMQ
A R MSGCTL SFLCTL(MSG)
A OVERLAY
A SFLDSP
A SFLINZ
A SFLSIZ(0005)
A SFLPAG(0001)
A S0PGMQ SFLPGMQ
Suppose there is no matching record based on the query string, then RCVF causes CPF0864 to be sent out, and this message can be displayed on the screen without problem.
But if a record is found and the field values are used in the RTVDTAARA command, and the failure of this command (e.g. data area not found) will causes the problem I described above, which is that the received message can only be glimpsed in a short period of time and then disappears. Why this happens?
The typical sequence is
write msgctl
write bottom
exfmt main
Make sure that any record format displayed after the message subfile has OVERLAY specified. Without OVERLAY, 'bottom' will erase the message subfile and 'main' will erase 'bottom'.
Application Display Programming is an old but useful reference.
EDIT After seeing the CL and DDS.
I believe the issue is due to SNDPGMMSG MSGTYPE(*STATUS). Status messages are special, and do not normally go into a subfile message queue. The Messages section in the Infocenter has more information on the different message types.
In CL PGMB, change the SNDPGMMSG to MSGTYPE(*DIAG) TOPGMQ(*PRV). This will throw the exception message to the caller (to PGMA) as a diagnostic message. Double check that you have OVERLAY in the DDS where you need it - my example above that would be bottom and main.
This sequence worked and display the message of message-subfile on the screen
The typical sequence is
write msgctl
write bottom
exfmt main
Make sure that any record format displayed after the message subfile has OVERLAY specified. Without OVERLAY, 'bottom' will erase the message subfile and 'main' will erase 'bottom'.
c