Model Derivative Translation of Revit Models stored in BIM360 Docs

Question

I'm working on an app to translate Revit models which have already been published to the cloud into IFC format using the data-management and model-derivative APIs, and have run into two key issues for the model-derivative API.

1. Model-Derivative Translation Issue:

I have run into a failed translation error which has also popped up in other threads Model Uploader Error The file is not a Revit file or is not a supported version

code:"Revit-UnsupportedFileType"
message:"<message>The file is not a Revit file or is not a supported version.</message>"
type:"error"
code:"TranslationWorker-RecoverableInternalFailure"
message:"Possibly recoverable warning exit code from extractor: -536870935"
type:"error

However my case is somewhat unique, and other answers are not applicable. Previous cases have failed due to incorrect Revit version (apparently the translation may work on a 2016 version but not a 2019 version), or corruption during the upload of the file. This cannot be applicable for me as the .rvt to .svf translation was successful for this model, only my .rvt to .ifc translation has failed, also I am not uploading through the app, rather accessing files that are already on BIM360 docs.

Another strange part of this behavior is that the .rvt->.ifc translation has been successful for earlier versions of the same model. This leads me to believe that perhaps there is a file size issue where the latest version of the model is too large for translation, although I haven't found any limits on the file size in the model-derivative documentation.

2. Model-Derivative Download Issue:

Routing the download of a translated file through my server before downloading again from server to client, in order to use the 3-legged OAuth token, means having to download the same file twice (once from data-management api endpoint to server, secondly from server to client). This is problematic for large models. Currently my solution has been to just pass the 3-legged OAuth token and file URI to the client and have the request go straight from client to autodesk endpoint, although I thought this was bad practice.

I have not found any samples which incorporate this download endpoint, a NodeJS one would be optimal for me. Also I wish there was a content-length header attached to this endpoint to give a better idea of download progress.

The relevant endpoints for my issues are both here: https://forge.autodesk.com/en/docs/model-derivative/v2/tutorials/translate-source-file-to-obj/

Translate:

curl -X 'POST' -H 'Authorization: Bearer WmzXZq9MATYyfrnOFpYOE75sL5dh' -H 'Content-Type: application/json' -v 'https://developer.api.autodesk.com/modelderivative/v2/designdata/job' -d
'{
  "input": {
    "urn": "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ"
  },
  "output": {
    "formats": [
      {
        "type": "obj"
      }
    ]
  }
}'

Note: I have used "type": ifc rather than "type": obj, as my output format on this endpoint; that is not the issue.

Verify:

curl -X 'GET' -H 'Authorization: Bearer RWLzh098vuF3068r73FI7nF2RORf' -v 'https://developer.api.autodesk.com/modelderivative/v2/designdata/dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ/manifest'

Download:

curl -X 'GET' -H 'Authorization: Bearer RWLzh098vuF3068r73FI7nF2RORf' -v 'https://developer.api.autodesk.com/modelderivative/v2/designdata/dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ/manifest/urn%3Aadsk.viewing%3Afs.file%3AdXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ%2Foutput%2Fgeometry%2Fbc3339b2-73cd-4fba-9cb3-15363703a354.obj'

For the first issue what was the URN so we can look into the logs? Was it `dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ`? — Bryan Huang, Nov 01 '19 at 07:39
@BryanHuang The URN is: `dXJuOmFkc2sud2lwcHJvZDpmcy5maWxlOnZmLjZXUlc1dmY5U1hpblZVd3lVd2k4Y1E_dmVyc2lvbj0z` — John Haddadian, Nov 03 '19 at 01:29

Bryan Huang · Answer 1 · 2019-11-01T07:29:56.283

0

means having to download the same file twice (once from data-management api endpoint to server, secondly from server to client). This is problematic for large models.

Try set up a proxy service in your backend to relay user requests and direct them to fetch the derivatives and inject tokens into their headers so the tokens won’t get exposed to clients so the files won’t have to land physically on your backend as a go-between - see here for an sample.

Will update this answer once we get to the bottom of the first issue.

edited Nov 01 '19 at 07:29

answered Nov 01 '19 at 07:24

Bryan Huang

5,247
2
15
20

The proxy service worked great for the second issue, cheers for that. Any update on the first issue? The following URNs have this same issue: 'dXJuOmFkc2sud2lwcHJvZDpmcy5maWxlOnZmLjJ0TE0yY3VWU2htcXhaVy1FcDE4Zmc_dmVyc2lvbj0z' 'dXJuOmFkc2sud2lwcHJvZDpmcy5maWxlOnZmLjZXUlc1dmY5U1hpblZVd3lVd2k4Y1E_dmVyc2lvbj0z' – John Haddadian Dec 06 '19 at 00:02
@JohnHaddadian are these Revit 2014 files? – Bryan Huang Dec 11 '19 at 06:38
No, they are Revit 2019 files. – John Haddadian Dec 12 '19 at 22:56
good to know - can you share the request payload for the translation job? Engineering needs that to get to the bottom of things - looks like the issue lies with the file processing in our backend pipeline. – Bryan Huang Dec 13 '19 at 03:03
By the Request payload do you mean the body of the request posted to `https://developer.api.autodesk.com/modelderivative/v2/designdata/job` ? In that case: `body: {input : {urn:"dXJuOmFkc2sud2lwcHJvZDpmcy5maWxlOnZmLjJ0TE0yY3VWU2htcXhaVy1FcDE4Zmc_dmVyc2lvbj0z"}, output : { formats: [ {type: 'ifc'} ] } }` – John Haddadian Jan 17 '20 at 02:33
Yeah just passed this on to Engineering and will let you know – Bryan Huang Jan 17 '20 at 06:19

Model Derivative Translation of Revit Models stored in BIM360 Docs

1 Answers1