This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

File Sources not creating file and no error logged. How to troubleshoot?

We have a document creation platform that outputs to a shared location. M-Files previously has been able to pull in files and when it cannot, it generates an error in the Event Viewer. However in the last week, it seems to no longer pull in files from the File Source.

I can see when I watch the status of the import it gets to "Creating Documents" which is indicative that it recognizes it has files to import, and then ends. No files are created and the originals remain despite being set to delete upon creation (expected). We import a PDF paired with an XML file. I have cleaned out the folder and only put in a single PDF/XML pair to test, but it still fails to import with no error logged.

Also, there is no duplicate files in the vault as I have searched with an account with full vault access. 

Is there anywhere else I can go to turn on additional logging so I can troubleshoot this error?

Parents
  • I did manage to get it working again. Just a reboot of the server. Since we are in the process of a mass migration, a reboot might have done it some good after our first round of imports.

  • Sadly, this problem has returned in M-Files 21.9.10629.5. My File Sources are no longer importing again with no errors. It seems the server sees the files, tries to import, but nothing happens. It will say "Creating New Documents" and then end the process. The documents are not created, not deleted from source and no errors are written anywhere that I can find. (Usually they are in Event Viewer)


  • That is exactly what happens if some sort of automated handling is configured to take place immediately after import (workflow, event handler etc.) or if the imported object is placed in a class where required properties have not been given proper values. The process cannot complete, the object cannot be created, and nothing gets written in the logs. So the best way forward is to go through your configuration and check processing of those new objects all the way up to the point where the first actual check in happens if the process is successful. As mentioned above it has helped a lot to place a short pause immediately after import. This will allow objects to get checked in before the next steps in processing commence, and with that in place your import will be able to run. If objects then do not move on from the break point you have much better chances to figure out what goes wrong.

Reply

  • That is exactly what happens if some sort of automated handling is configured to take place immediately after import (workflow, event handler etc.) or if the imported object is placed in a class where required properties have not been given proper values. The process cannot complete, the object cannot be created, and nothing gets written in the logs. So the best way forward is to go through your configuration and check processing of those new objects all the way up to the point where the first actual check in happens if the process is successful. As mentioned above it has helped a lot to place a short pause immediately after import. This will allow objects to get checked in before the next steps in processing commence, and with that in place your import will be able to run. If objects then do not move on from the break point you have much better chances to figure out what goes wrong.

Children
  • While I agree, when missing properties, there is a message logged in the event viewer with the error. In this case there is no message.

    Once again I rebooted the server last night. I touched nothing after the reboot nd the files imported properly, so it seems to be something deeper that is getting hung up in the system.

    I also noticed a problem when trying to edit the Advanced Vault Settings for a minor change. While experiencing this behaviour I was also unable to save any changes in AVS. I would get an error of "System Broadcast Message Channel is not Open"

    Reboot also resolved that. So not sure if maybe this is part of a larger bug?