Announcement

Collapse
No announcement yet.

WebDav Issue - Invalid Path

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

  • WebDav Issue - Invalid Path

    We are using Citrix ShareFile to share some data with clients. I want to connect it to Mirth Connect so I can automate some of our data feeds.

    Since Citrix ShareFile only supports FTPS and not SFTP, I am looking at WebDav but running into some issues. Note that I was able to set this up as a network drive without any problems.

    First, I configured the settings in the source and tested the connection successfully. Screen shot attached.

    Next, I deploy the channel, and try to process a file. The channel polls for a while and it eventually gives me an invalid file path error.

    Is anyone able to help with this? I'm not sure why test read would work on the directory but processing a file from the directory does not.

    EDIT: For what it's worth, I thought it would be worth noting I am having no issues using WebDav as a File Writer.

    Error:
    ERROR 2019-10-03 15:36:45,535 [File Reader Polling Thread on test2 (178b23f5-93cd-4f43-ab42-313ff8f2ed1a) < 178b23f5-93cd-4f43-ab42-313ff8f2ed1a_Worker-1] com.mirth.connect.connectors.file.filesystems.WebD avConnection: Invalid filepath: /Shared Folders/TestCompany/fromRHealth/test.txt
    ERROR 2019-10-03 15:36:45,536 [File Reader Polling Thread on test2 (178b23f5-93cd-4f43-ab42-313ff8f2ed1a) < 178b23f5-93cd-4f43-ab42-313ff8f2ed1a_Worker-1] com.mirth.connect.connectors.file.FileReceiver: Unable to dispatch message to channel 178b23f5-93cd-4f43-ab42-313ff8f2ed1a. File: https://rhealth.sharefile-webdav.com/Shared Folders/TestCompany/fromRHealth//Shared Folders/TestCompany/fromRHealth/test.txt
    java.lang.Exception: Invalid Path
    at com.mirth.connect.connectors.file.filesystems.WebD avConnection.readFile(WebDavConnection.java:193)
    at com.mirth.connect.connectors.file.FileReceiver.get BytesFromFile(FileReceiver.java:567)
    at com.mirth.connect.connectors.file.FileReceiver.pro cessFile(FileReceiver.java:411)
    at com.mirth.connect.connectors.file.FileReceiver.pro cessFiles(FileReceiver.java:328)
    at com.mirth.connect.connectors.file.FileReceiver.pol l(FileReceiver.java:239)
    at com.mirth.connect.donkey.server.channel.PollConnec torJob.execute(PollConnectorJob.java:49)
    at org.quartz.core.JobRunShell.run(JobRunShell.java:2 13)
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run (SimpleThreadPool.java:557)
    Attached Files
    Last edited by michaels; 10-03-2019, 09:35 AM.

  • #2
    I tried this a couple years ago and they have a bug in their webdav implementation that prevents it from working with mirth. I contacted their support and told them exactly what the problem was, but they said since I wasn't using one of the approved webdav clients, they couldn't help me. I couldn't even get past tier 1 support.

    Comment


    • #3


      There's no workaround I assume? Could it be related to:
      https://www.mirthcorp.com/community/...wse/MIRTH-4297

      Very frustrating that it works in file writer but not file reader.

      Comment


      • #4
        Here's the description of the problem I sent to [email protected] on Jul 18, 2017 after I couldn't get anywhere with sharefile support:

        Hi, I am a user of sharefile.com. It is possible to access our data at that site via webdav. I'm trying to automate moving some files to and from the server using the webdavclient4j library. While troubleshooting an issue, I noticed the HTTP headers returned by the server claimed to be running "IT Hit WebDAV Server .Net v3.1.864.0."

        What I noticed is that intermittently, but more often than not, when I send a PROPFIND request for a file with depth 0, the href part of the response is missing a slash between two folders. This is causing the library that I'm using to choke since the returned href does not match the path in the request. Folders don't seem to have this issue.

        I don't know if this is an issue with your library or with their use of it. I tried opening a support ticket with sharefile.com, and they are telling me they don't support it because it isn't their integration, but they aren't offering any other assistance either.
        And their response:

        Thank you for your question. This issue is caused by incorrect IHierarchyItemAsync.Path or IHierarchyItem.Path property implementation.
        https://doc3.webdavsystem.com/ITHit....Async.Path.htm

        SareFile has this property incorrectly implemented, missing a slash.
        Forwarding this back to sharefile support didn't help.

        Comment


        • #5
          I ended up not going this route, but in testing I was able to use a javascript reader to create my own instance of org.apache.webdav.lib.WebdavResource to download the files. I think I just avoided making the same calls that mirth was making that I knew were buggy on the remote end.

          Comment


          • #6
            Originally posted by michaels View Post
            Unable to dispatch message to channel 178b23f5-93cd-4f43-ab42-313ff8f2ed1a. File: https://rhealth.sharefile-webdav.com/Shared Folders/TestCompany/fromRHealth//Shared Folders/TestCompany/fromRHealth/test.txt
            java.lang.Exception: Invalid Path
            Not sure if this is something you're doing or if it's their end, but I think the problem here is that it's doubling the path.

            Comment


            • #7
              Here's the code from my disabled test channel. I don't know if it's still in working order or not. I was trying different things out before I abandoned it.

              Code:
              var webdavusername = $cfg('SharefileUser');
              var webdavpassword = $cfg('SharefilePassword');
              
              var sourcedir = '/Shared Folders/TestCompany/fromRHealth';
              
              var url = new org.apache.commons.httpclient.HttpsURL('https://rhealth.sharefile-webdav.com');
              url.setUserinfo(webdavusername,webdavpassword);
              try {
                  var client = new org.apache.webdav.lib.WebdavResource(url);
                  client.setPath(sourcedir);
              
                  var messages = new java.util.ArrayList();
              
                  client.listWebdavResources().forEach(function(r) {
                      logger.info(r + ' - ' + r.getResourceType() + ' - ' + r.isCollection());
                      if (!r.isCollection()) {
                          try {
                              var originalFilename = r.getDisplayName();
                              var is = r.getMethodData();
                              var byteArray = org.apache.commons.io.IOUtils.toByteArray(is);
                              var sourcemap = new java.util.HashMap();
                              sourcemap.put('originalFilename', originalFilename);
                              /*
                                  I think I was base64 encoding it rather than using the byteArray directly because
                                  these were PDFs which I was converting to attachments, and I think the built in
                                  mirth viewer was having trouble displaying the pdf unless I did it this way.
                                  I don't think this is still an issue in current mirth versions and you could
                                  probably do this instead for binary files:
                                      messages.add(new RawMessage(byteArray, null, sourcemap));  
                              */
                              messages.add(new RawMessage(FileUtil.encode(byteArray), null, sourcemap));
                              /*
                                  Or for text files (change charset as appropriate):
                                      messages.add(new RawMessage(new java.lang.String(byteArray, 'UTF-8'), null, sourcemap));
                              */
                          }
                          catch (e) {
                              logger.error(e);
                          }
                      }
                  });
              }
              finally {
                  if (client != null) {
                      client.close();
                  }
              }
              
              return messages;

              Comment


              • #8
                Thanks for your help. I have a call with their sales team today so maybe I will mention this to them.

                Regarding the duplicated file path - I have tried just about every different combination and confirmed everything in the source file reader. I also have it configured the same way in the file writer so the duplication has to be something in Mirth or ShareFile.

                In the meantime, I will take a look at your code and see if it works for us. Thanks again for your help.
                Last edited by michaels; 10-04-2019, 06:43 AM.

                Comment


                • #9
                  Originally posted by agermano View Post
                  Not sure if this is something you're doing or if it's their end, but I think the problem here is that it's doubling the path.
                  Do you think this is a bug with Mirth?

                  Comment


                  • #10
                    There's a slim chance it could be, but I think it's much more likely a sharefile bug.

                    The library that mirth uses is webdavclient4j.

                    Webdav operates over http. I remember when I was troubleshooting my issue I was replicating what mirth normally would do from outside of mirth, and was still getting the same error. I could see in the http response that they were sending back invalid data.

                    Comment


                    • #11
                      Why not use their API?
                      Mirth 3.8.0 / PostgreSQL 11 / Ubuntu 18.04
                      Diridium Technologies, Inc.
                      https://diridium.com

                      Comment


                      • #12
                        Originally posted by pacmano View Post
                        Why not use their API?
                        I am looking at that option now. Thanks for your input.

                        Comment


                        • #13
                          Originally posted by michaels View Post
                          I am looking at that option now. Thanks for your input.
                          We are trying to implement writing to ShareFile as well.
                          What did you end up doing "michaels"? Using their API (directly or with the Java/Javascript SDK)? Or did you get WebDAV to work?
                          Thank you!

                          Comment


                          • #14
                            Originally posted by mike_pose View Post

                            We are trying to implement writing to ShareFile as well.
                            What did you end up doing "michaels"? Using their API (directly or with the Java/Javascript SDK)? Or did you get WebDAV to work?
                            Thank you!
                            Sorry that I never responded to this. We ended up needing to purchase the SSL Manager so we could create secure endpoints using HTTP Listeners. Since we had the SSL Manager we were able to use their FTPS option but we don't pull data from ShareFile anymore. I'd be very interested to see if this WebDav issue was fixed - they told me they were making many improvements to their WebDav functionality but won't believe it until I see it.

                            Comment

                            Working...
                            X