Announcement

Collapse
No announcement yet.

Escape characters generating error in OBX

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Escape characters generating error in OBX

    I have a vendor sending RTF results which include the escape characters for the backslash, \E\.

    We appear to be failing the messages due to the escape characters. I manually replaced these characters with the backslash and the message no longer errored. However, our downstream vendor needs the escape characters.

    The error reads: TypeError: The content of elements must consist of well-formed character data or markup.



    What would be causing our inbound interface to fail messages which include the \E\ values? Being standard, I expect that to not be a problem.

    I suppose I can try to find a way to transform the \ to \E\, but that would also require having the source vendor change what they're sending in the first place. Would be best to realize why we are erroring when receiving \E\

  • #2
    Could you store the RTF data as an attachment, and then re-attach when sending? That way you are never trying to parse the \E\ ?

    -= Jack Haines : Founder/CEO of Healthcare Integrations, LLC
    -= [email protected]
    -= Mirth Connect (Advanced)-certified
    -= Gold member of HL7.org
    -= Available for Mirth Connect channel development and consultation! Schedule a FREE call with me at https://calendly.com/jackhaines

    Comment


    • #3
      Originally posted by jackwhaines View Post
      Could you store the RTF data as an attachment, and then re-attach when sending? That way you are never trying to parse the \E\ ?
      That's good advice in general, but I'd also be interested to know what is causing the error. There shouldn't be any issues with passing it through.

      Comment


      • #4
        preprocessor script...

        msg = msg.replaceAll('\\E\\', '\\\\');//I think that is the correct number of \s


        postprocessor script...

        msg = msg.replaceAll('\\\\', '\\E\\');

        Comment


        • #5
          Originally posted by cory_cole View Post
          preprocessor script...

          msg = msg.replaceAll('\\E\\', '\\\\');//I think that is the correct number of \s


          postprocessor script...

          msg = msg.replaceAll('\\\\', '\\E\\');
          It's telling me "ReferenceError: "msg" is not defined". I tried with and without "return message;" after each of those scripts andgot the same error.

          Comment


          • #6
            Originally posted by jackwhaines View Post
            Could you store the RTF data as an attachment, and then re-attach when sending? That way you are never trying to parse the \E\ ?
            Our channel has "Store Attachment" checked off, but nothing beyond that. The attachment drop-down is set to "None". I have never worked with this feature and am unsure how to go about doing what you said.

            Comment


            • #7
              change msg to message.

              Comment


              • #8
                Originally posted by cory_cole View Post
                change msg to message.
                TypeError: cannot find function replaceAll in object (message pasted here)


                This is what I have now:


                preprocessor script...

                message = message.replaceAll('\\E\\', '\\\\');

                postprocessor script...

                message = message.replaceAll('\\\\', '\\E\\');

                Comment


                • #9
                  put this as your first line...

                  message = java.lang.String(message);//converts the javascript string to a java string;

                  and your return line to....

                  return String(message);//convert back to a javascript string.

                  Comment


                  • #10
                    Originally posted by cory_cole View Post
                    put this as your first line...

                    message = java.lang.String(message);//converts the javascript string to a java string;

                    and your return line to....

                    return String(message);//convert back to a javascript string.
                    THis is just the pre-processor at this point, right? Do I keep the message = message.replaceAll('\\E\\', '\\\\');
                    line?

                    Comment


                    • #11
                      Yes. replaceAll is a Java function and not a javascript function. You need to convert to Java in order for the replaceAll to work. But all other msg functions are javascript. So, it needs to be converted back.

                      Comment


                      • #12
                        Originally posted by cory_cole View Post
                        Yes. replaceAll is a Java function and not a javascript function. You need to convert to Java in order for the replaceAll to work. But all other msg functions are javascript. So, it needs to be converted back.
                        Here is what I have currently:

                        pre:
                        message = java.lang.String(message);
                        message.replaceAll('\\E\\', '\\\\');
                        return String(message);


                        post:
                        message = message.replaceAll('\\\\', '\\E\\');
                        return message;


                        Receiving error: "Illegal/unsupported escape sequence near index 1".

                        I can't tell which way is closer to working

                        If I remove the 2nd line in the pre-processor which switches \E\ with \, then I get a post-processor error of "cannot find function replaceAll in object message 45".

                        I'm not sure which is closer to working...

                        Comment


                        • #13
                          One weird note is that we have another channel which IS processing these RTF paths with the backslash characters, but there is no pre/post processing code or transformations occurring. Reviewing the Summary config, nothing seems to be different either. The only difference is one is a Channel Reader and the other is TCP receiver. But the Channel Reader receives the original HL7 message from the source, which has the backslash characters present anyway. Nothing seems different on that channel either.

                          I feel like there has to be something I'm missing on the setup of one of these channels...

                          Comment


                          • #14
                            What are your inbound data types?
                            Are you using strict parser on either of them?

                            Comment


                            • #15
                              Originally posted by cory_cole View Post
                              What are your inbound data types?
                              Are you using strict parser on either of them?
                              Same settings for both:

                              HL7 v2.x inbound/outbound

                              Not using strict parser

                              Comment

                              Working...
                              X