web stats
Escape characters generating error in OBX - Page 4 - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #31  
Old 12-12-2019, 10:02 AM
cory_cole cory_cole is offline
Mirth Guru
 
Join Date: Mar 2012
Posts: 1,346
cory_cole is on a distinguished road
Default

Yep. The OBX has returns in it. Your preprocessor should be....


// Modify the message variable below to pre process data
while(message.indexOf('\n') > -1)
{
message = message.replace('\n', '');
}
return message;


Nothing needs to be in your destination transformer.
Reply With Quote
  #32  
Old 12-12-2019, 10:16 AM
Ozz Ozz is offline
OBX.1 Kenobi
 
Join Date: Apr 2015
Posts: 48
Ozz is on a distinguished road
Default

Quote:
Originally Posted by cory_cole View Post
Yep. The OBX has returns in it. Your preprocessor should be....


// Modify the message variable below to pre process data
while(message.indexOf('\n') > -1)
{
message = message.replace('\n', '');
}
return message;


Nothing needs to be in your destination transformer.
I almost don't want to say it, but that still gives me the "TypeError: The content of elements must consist of well-formed character data or markup" error

what does that mean exactly?
Reply With Quote
  #33  
Old 12-12-2019, 10:32 AM
cory_cole cory_cole is offline
Mirth Guru
 
Join Date: Mar 2012
Posts: 1,346
cory_cole is on a distinguished road
Default

I ran your message through successfully with that code. It means that the message is not in XML format. Mirth converts HL7 into XML for easier processing. In this message there were carriage returns that put the message in bad format. It could meant that there is a <tag> that doesn't have a </tag>. Not likely here as the message itself is not in XML.

Unless there is an issue in the PHI

Do you have any other code running on the message?

Last edited by cory_cole; 12-12-2019 at 10:34 AM.
Reply With Quote
  #34  
Old 12-12-2019, 10:57 AM
Ozz Ozz is offline
OBX.1 Kenobi
 
Join Date: Apr 2015
Posts: 48
Ozz is on a distinguished road
Default

Quote:
Originally Posted by cory_cole View Post
I ran your message through successfully with that code. It means that the message is not in XML format. Mirth converts HL7 into XML for easier processing. In this message there were carriage returns that put the message in bad format. It could meant that there is a <tag> that doesn't have a </tag>. Not likely here as the message itself is not in XML.

Unless there is an issue in the PHI

Do you have any other code running on the message?
Not at this time. We have one destination transformer to change a field value, but I have that off while working on this. Would you be able to attach your channel to a post here so I could load it & compare?
Reply With Quote
  #35  
Old 12-12-2019, 11:17 AM
agermano agermano is offline
Mirth Guru
 
Join Date: Apr 2017
Location: Indiana, USA
Posts: 1,095
agermano is on a distinguished road
Default

This goes back to what I originally said that the \E\ probably wasn't the problem. The best solution would be for the software that is creating the hl7 message to base64 encode the rtf document you're trying to embed and the receiving end would decode it.

If that isn't possible and it's always the case that the rtf document is the last field of the message, it should be fairly easy to strip that out with the attachment handler, like Jack suggested, and reattach at the end. Technically any carriage returns in the message should be escaped, as that is the segment delimiter, and you don't have valid segments following the delimiter.
Reply With Quote
  #36  
Old 12-12-2019, 11:24 AM
Ozz Ozz is offline
OBX.1 Kenobi
 
Join Date: Apr 2015
Posts: 48
Ozz is on a distinguished road
Default

Quote:
Originally Posted by agermano View Post
This goes back to what I originally said that the \E\ probably wasn't the problem. The best solution would be for the software that is creating the hl7 message to base64 encode the rtf document you're trying to embed and the receiving end would decode it.

If that isn't possible and it's always the case that the rtf document is the last field of the message, it should be fairly easy to strip that out with the attachment handler, like Jack suggested, and reattach at the end. Technically any carriage returns in the message should be escaped, as that is the segment delimiter, and you don't have valid segments following the delimiter.
I believe this method is the vendor's limitation, if they are to send RTF.

I would be happy to try the attachment process, if I could be guided on it.In the Summary tab, we have "Store Attachments' checked but the drop-down menu next to it has "None" selected. I don't think it's actually doing anything with this configuration, am I right?
Reply With Quote
  #37  
Old 12-12-2019, 11:50 AM
agermano agermano is offline
Mirth Guru
 
Join Date: Apr 2017
Location: Indiana, USA
Posts: 1,095
agermano is on a distinguished road
Default

Switch it to regex and click the properties button.

For the expression, use
Code:
(?:OBX\|(?:[^|]*\|){4})([\s\S]*)$
Use "application/rtf" for the mime type.

This will take EVERYTHING including and after OBX-5 of the first OBX segment and replace it with a token. The token will be replaced with what was removed when your destination connector attempts a send. If that doesn't work you may need a different regex or to write a javascript attachment handler.

This should let you process the message without changing the content by replacing values (and likely breaking your rtf.)
Reply With Quote
  #38  
Old 12-13-2019, 12:12 PM
Ozz Ozz is offline
OBX.1 Kenobi
 
Join Date: Apr 2015
Posts: 48
Ozz is on a distinguished road
Default

Quote:
Originally Posted by Ozz View Post
I almost don't want to say it, but that still gives me the "TypeError: The content of elements must consist of well-formed character data or markup" error

what does that mean exactly?
Quote:
Originally Posted by cory_cole View Post
Yep. The OBX has returns in it. Your preprocessor should be....


// Modify the message variable below to pre process data
while(message.indexOf('\n') > -1)
{
message = message.replace('\n', '');
}
return message;


Nothing needs to be in your destination transformer.


Got it working this morning with the above in place. Not sure why it wasn't working the other day, but here we are. Things are moving along - thank you so much! If I have to revisit and look at the attachment idea, it's nice to have that outlined here as well to go by.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 10:12 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Mirth Corporation