Mirth Connect 4.3.0 Released!

Mirth Connect 4.3.0 is now available as an appliance update and on our GitHub page.

This is a major release containing new features like adding new functionality to the Mirth Connect Setup Wizard, adding the ability for resource and channel-specific classloaders to load child-first or parent-first, and added a default implementation of the getObjectsForSwaggerExamples() method in the ServicePlugin class. This release also contains enhancements for the Mirth Connect Administrator Launcher, the Mirth Connect Docker images, and several bug fixes and security improvements.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

FTP - Non HL7 file

  • Filter
  • Time
  • Show
Clear All
new posts

  • FTP - Non HL7 file

    I'm trying to create a FTP to FTP channel that gets a file and sends the file to its destination without any manipulation. The files are in PDF format and do not contain any data in HL7 format.

    When I run the channel, this is the error I get:

    FAILURE: Error evaluating transformer
    org.xml.sax.SAXParseException: The content of elements must consist of well-formed character data or markup.
    Reid Hospital and Healthcare

  • #2
    Re:FTP - Non HL7 file

    This is because you're selecting HL7 as the incoming protocol, so Mirth try to parse the file as is it was an HL7 message.

    To avoid this, you can use an old trick: choose XML as the incoming message, and creates in the pre-processor a simple XML file

    return message;
    Then, in the transformer select the content element as a channel var, and in the destination write a file with the content of this var.


    • #3
      Re:FTP - Non HL7 file

      I'm still getting the same error. I have attached my channel. Could you take a look at it and see if I am understanding your logic correctly?

      Post edited by: afterdark23, at: 12/05/2007 10:36
      Reid Hospital and Healthcare


      • #4
        Re:FTP - Non HL7 file

        You should check too: "File type" to "Yes"
        and "Process Batch Files" to "No"


        • #5
          Re:FTP - Non HL7 file

          Thanks for your help. That seemed to take care of the problem.

          Will future versions be able to handle document transfers like this without the workaround code?
          Reid Hospital and Healthcare


          • #6
            Re:FTP - Non HL7 file


            I'm not sure this would be an useful feature: Mirth is useful because it try to understand the contents of the data it moves (HL7, X12, DICOM, XML, etc). If what you want to do is moving a file from one place to another, I think an cron(automated task will fits better). Nevertheless, if you think it's an interesting thing, you could add it as a new feature to the Issue Tracker

            By the way, afterdark23. ┬┐Where are you working with Openlink?


            • #7
              Re:FTP - Non HL7 file

              Currently we have set up automated applications to accomplish our file to file transfers. It would be nice to have one central location to monitor our interfaces and file connections. We can do file to file connections using Openlink, however, there is not allot of error trapping (IO exceptions, FTP can not connect) that allows us to see when a exception happens.

              I work at a hospital in east central Indiana.
              Reid Hospital and Healthcare


              • #8
                Hi afterdark23, would it be possible for you to send me your channel sample code? I am having similar problem and wanted to try your solution. But I don't know how to implement "in the transformer select the content element as a channel var, and in the destination write a file with the content of this var." as Albert suggested.
                Thank you for your help!



                • #9
                  I use successfully the following setup to FTP non-HL7 files (e.g. .gz files):

                  Incoming data: Delimited text
                  File type: Binary

                  Outgoing filetype also has to be Binary, otherwise the data are corrupted.
                  Outgoing template has to be ${message.rawData}

                  I don't need any other transformations like those described above.
                  JJ Mouris
                  FFE Luxembourg


                  • #10
                    This worked for me.

                    This worked for me as well. Thanks for the heads up.