Forum Replies Created
-
AuthorReplies
-
Here is how I am doing it with removing a “\.br\” via script:
set lstSegments [split $origMsg \r]
#loop through segments
#echo “foreach line 153”foreach valSeg $lstSegments {
set segType [mjhGetField 0 $valSeg $fieldSep]# ——————————————————————
# —————————————————————— MSH
# ——————————————————————
if [cequal $segType NTE] {
#echo $valSeg
set CountVal 1
set CheckString [mjhGetField 3 $valSeg $fieldSep]
set MarkupExists [string match *\.br\* $CheckString]
while { [cequal $MarkupExists 1] } {
#echo “loop start”
#echo equality:[cequal $MarkupExists 1]
#echo [string first “\\.br\\” $CheckString]
#echo [string range $CheckString 0 [string first “\\.br\\” $CheckString]-1 ]
set valSeg [mjhSetField [string range $CheckString 0 [string first “\\.br\\” $CheckString]-1 ] 3 $valSeg $fieldSep]
set valSeg [mjhSetField $CountVal 1 $valSeg $fieldSep]
lappend newMSGx $valSeg
#echo $valSeg
set CheckString [string range $CheckString [string first “\\.br\\” $CheckString]+5 end]
#echo $CheckStringincr CountVal
set MarkupExists [string match *\.br\* $CheckString]
#echo MarkupExists:$MarkupExists
#echo CountVal:$CountVal
if [cequal $MarkupExists 0] {
set valSeg [mjhSetField $CheckString 3 $valSeg $fieldSep]
set valSeg [mjhSetField $CountVal 1 $valSeg $fieldSep]
#lappend newMSGx $valSeg}
}}
lappend newMSGx $valSeg
}You dont decare it. You set your “In” variable to a name then use that name enclosed in brackets in the SQL.
Your case would be:
In: access_cd
Select my_field from […] where rse.ACCESS_CD=<access_cd>
You can do this, just set the file based one like anything else, and it should work just fine – just remember to include any translations or TCL scripts that are in the route that you are mimicking. I do that a lot for when resending a group of messages and using the SMAT tool is inconvenient.
July 28, 2020 at 1:49 pm in reply to: Is there a way to convert HL7 MDM encoded base64 PDF data to text? #117552Adding this line did the trick. Thank you for the help!
set outfilename $OBX3_4
set fileId [open $outfilename “w”]
fconfigure $fileId -encoding binary -translation binary
puts $fileId $unencodedData
close $fileIdJuly 28, 2020 at 12:26 pm in reply to: Is there a way to convert HL7 MDM encoded base64 PDF data to text? #117550Turns out I am trying to do something similar – the PDF is encoded and I want to extract it into a file structure.
This is the code I am using, and it does create a file, but the PDF reader I am using (Adobe) says the file is “damaged”.
Up to this point, I have isolated the field into a variable then decode the variable and write to file:
set unencodedData [decode $OBX5_4 ]
echo unencodedData:$unencodedDataset outfilename $OBX3_4
set fileId [open $outfilename “w”]
puts $fileId $unencodedData
close $fileIdSo…what am I doing wrong? I have taken the value in $OBX5_4 and pasted it into a BASE64 to PDF converter (https://base64.guru/converter/decode/pdf) and it created the document just fine.
Thanks,
Scott
The EOF style will do the trick. Turns out the vendor was hesitant to modify the file they were creating. This is the first ‘public’ file-based interface I have had to create. I would’ve just tried out FTP, but it had to be FTPs and I dont have the plug in for that.
I appreciate everyone’s feedback and support. Thanks. Scott
Can you elaborate?
I am still having issues getting it formatted so that it will cross automatically.
That appears to be the issue. I used an editor to append the 0D at the end of the file and it went through. I have asked the vendor to make sure every segment ends that way (the rest of them do).
I’ll keep you posted. Thank you all for your help.
Not sure what the acronym CL stands for?
But the Style in the Fileset/FTP Local (TPS) Protocol Properties, in the Inbound area, is hl7. That what you were asking for?
Correct. Log of that sequence of events attached.
Attachments:
You must be logged in to view attached files.Here you go.
Attachments:
You must be logged in to view attached files.OK so I removed all scripts and just run a file though, with the process stopped when moved the file into the source folder. I tried the ‘good’ one first, and it went just fine, and created a file named default in the destination folder. Expected that result.
Then I put the real file in, it was picked up, but nothing happened.
Then I put a 2nd good file in the source folder, it was picked up and the default file was overwritten with that file.
So…back to square one for me. LOL
Attached is the log from this iteration of attempts.
Another thing that has bothered me is the look of the test tool’s results. Under normal circumstances, I only ever see the “tcl :out: INFO[…]” lines at the begining of the message, and the note of where it is being routed to. As you can see in the attached screen shot, thats not the case with the unedited file. Maybe a clue?
- This reply was modified 4 years, 9 months ago by Scott Caldwell.
Attachments:
You must be logged in to view attached files.seq_FileOut writes the file to a folder. All this time I thought it was native to the TCL library…apparently not? Its attached. Is it my culprit?
Attachments:
You must be logged in to view attached files.I have enable_all turned on.
In the log the edited file is named 1584545623256alt.dat – while the full one with the embedded PDF is named 1584545623256.dat
This never happens in the full file:
DRIVERCTL is set to: {FILENAME {../../../data/LocalSrc/ib_test/1584545623256alt.dat}}
Attachments:
You must be logged in to view attached files.Responses to other questions:
If so, how many threads are you using there? Just two, IB & OB, both fileset-local.
Give us a rundown of how you’ve got your threads set up:
IB: fileset-local, encoding:ASCII, Log: enable_all,TrxID Det.: HL7, HICIStatic route(Raw) with Procs: intrinsiqtest which i was using to throw echos as needed, and seq_FileOut.OB: fileset-local, encoding:ASCII, Log: enable_all,Outbound only
and what POC you’re using your decode proc. Not sure what this means.
Its possible the file is getting read in, there’s nothing to do. So there are no errors, but nothing is getting done. This works with all other messages & message types I have tried. Its only failing with the one with the full embedded PDF in it.
Also, you mentioned, “If remove or otherwise truncate the OBX5.4 field the file processes just fine.” – so what is the outcome when everything goes fine? It runs fine, file is written to the designated outbound folder.
Is your code referencing a variant? i dont think so?
- This reply was modified 4 years, 9 months ago by Scott Caldwell.
-
AuthorReplies