Accessing file BIM360 file locally through Autodesk docs

I’m trying to access a shared parameter file programmatically on BIM360 by pathing locally through

(C:\Users%USERNAME%\ACCDocs\Company\Project\Project Files\shared parameter.txt)

The problem is that files on BIM360 through Autodesk Docs aren’t synced and are inaccessible until synced. A work around is to open and read the file, which is suppose to force the sync to desktop and the file becomes accessible.

Opening and reading the file at the path in RevitPythonShell, Python Script node in Dynamo, or even ‘File From Path’ node to ‘FileSystem.ReadText’ node, does not work and returns ‘Proxy’.

In my googles I did come across this post

which elaborates on this workflow. They use ‘File From Path’ node in Dynamo to access the file which forces the sync. Although this does not work for me and when reading returns a string ‘Proxy’, using the ‘File Path’ node to ‘FileSystem.ReadText’ node DOES actually force the file to sync and be available but the problem being that ‘File Path’ node requires you to manually select the file which defeats my purpose.

At any rate, the linked post mentions that when the file is not yet synced, it isnt in the specified folder, there is 2 subfolders within that BIM360 directory on the local machine, two hidden directories, ‘_C’ and ‘_D’. the file is actually in ‘_D’ and Desktop Connector does some magic and moves it from ‘_D’ to your local machine when it syncs. Reading the file from this directory also returns an empty string vs ‘Proxy’ string.

Can anyone shed some light on the problems I’m having? or how I might programmatically force sync a file locally.

I’ve also tried opening Command Prompt from python and then opening/reading the file from there with no luck.

Oddly opening the file via Python 3.7.9 terminal in Vscode successfully syncs the file, but I need to do it all within Dynamo.

Thanks.

There are ways to force the sync from inside desktop connector, but those APIs are not documented and rather unstable between versions.

Opening from within a Python node should work more reliably, with a few caveats.

  1. The method you use to call for the open will matter. Make sure your options are set for a full open as if you were attempting to open the document not from Python but say a text editor.
  2. The frequency of updates and calls will be limited by the traffic limits for the system (as with any web tool, to prevent system overload). If you ran an update and synced the one file you’re likely fine. If you asked to sync 500… likely that will take awhile.
  3. The current state of the file will matter. Stale, out of sync, locked, locked by others… any of these can cause a delay to be sent to the app.
  4. Depending on the desktop connector version used (everyone should be on 15.1 at this point per the recent security advisory) the methods may have to change; so you’ll have to keep everyone current and update as frequently as 1x a month.

None of these sound good, but it’s the price you pay for hacking at the file via desktop connector at this time. A more foolproof solution would be to path directly via forge, and initiate a download.

Thanks for the reply Jacob,

I tried open() in python with all the access modes, and also os.startfile() on the target path and also the ‘_D’ location to no avail.

This was my attempt at avoiding having to access the file through Sharepoint API or Forge. Currently I have no experience with REST requests and from what I understand, I would need to make these with the urllib module if using ironpython through dynamo.

If you or anyone reading knows a good tutorials you can point me to I’d appreciate it. Thanks!

Good luck to anyone else who may stumble upon this looking for the same solution :slight_smile:

What are you trying to do with the file in particular?

I have a script that requires certain shared parameters, i wanted to automate creating those parameters if they dont exist in the project, and to preserve the guid of the shared parameters from our firms master shared parameter file, my plan was to load our shared parameter file and add the needed parameters to the project, instead of just creating and adding the needed parameters to the script users project.

Currently the file is on SharePoint which I originally tried pathing to, only to find out that users may sync at different folder levels making the paths to the shared parameter file directory inconsistent, so was exploring the idea of pathing to BIM360 thinking everyone would have the same path there.

Ok… this makes more sense now.

I think you can create the SP file on the users temp directory by grabbing the relevant info from your standard SP file and hard coding it into a DYN or a custom node (packaged or not) or even a non-linked web site on your firm’s domain (bonus: you can easily update this file), saving the new text document with the SP data to the temp directory as a new file, and then creating the SP in the project from there. Not sure if there is an issue with the workflow I am not seeing, but worth a shot anyway.

I wouldn’t stress the BIM360 concern. Project specific SP stuff is useful there, shouldn’t be bulk updated, and only a handful of users should ever need access to it. Not like you need to make it so no one can ever see your SP file - there aren’t highly unique trade secrets in any that I have seen (and I see more than most).

Ended up taking the dive and trying the Forge route and made it happen, which is exciting as I have been wanting to explore some ideas with Forge a long time.

I don’t have BIM360 account admin access or a Forge account at work but was able to get a trial of both BIM360 and Forge in order to give it a try which was awesome.

Used Postman.com to go through this tutorial

https://forge.autodesk.com/en/docs/bim360/v1/tutorials/document-management/download-document/

and ended up using System.Net.WebClient() to download the SP file.

3 Likes

AWESOME!!!

The capabilities that will open for you are HUGE. Really glad you worked it out.

Good luck on the journey. :slight_smile:

1 Like