Model Derivative Translation of Revit Models stored in BIM360 Docs - autodesk-forge

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'

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.

Related

Autodek Forge Tutorial

I have been working through the Autodesk Forge Sample App tutorial.
WHen I click the button to connect with my account I get this error;
{"developerMessage":"The required parameter(s) redirect_uri not present in the request","errorCode":"AUTH-008","more info":"https://forge.autodesk.com/en/docs/oauth/v2/developers_guide/error_handling/"}
If you get this error, you probably trying a 3 legged oauth flow. And it means that you did not provide the callback url in the request. Since you did not say which tutorial you have been using, let me point you to 2 sources - the Forge documentation tutorial here or the Learn Forge tutorial here
In both case, it is important to have the callback url defined in the application page on the Forge portal - If you are using your local machine, it should be something like http://localhost:3000/mycallback. The learnforge material tells you to define it as (see here):
http://localhost:3000/api/forge/callback/oauth
where the documentation tutorial says to use
http://sampleapp.com/oauth/callback
but here they assume you own the domain sampleapp.com which is probably not true. You need to replace sampleapp.com by your own domain or the localhost:port when developing your webserver on your local machine. Note it is important to use your true domain vs localhost when you'll run the code on your server, and update both your application page and your code to use the same definition. I usually setup 3 applications (dev: with localhost:3001, staging: with myapp-staging.autod3sk.net, and production: with myapp.autod3sk.net) - this is to avoid to have to edits keys all the time and make the application deployment a lot easier.
Now that your application is setup, you need to use that URL in your request as documented in the Oauth API. But all parameters should be URL encoded, otherwise the / character will be misinterpreted by the server. Failing to pass the correct and encoded URL parameter in the request will result in the error you are seeing.
Here is an example:
https://developer.api.autodesk.com/authentication/v1/authorize \
?response_type=code \
&client_id=MYCLIENT_ID \
&redirect_uri=MY_ENCODE_CALLBACKURL \
&scope=REQUIRED_SCOPES
after replacing the placeholders, it should look like this
https://developer.api.autodesk.com/authentication/v1/authorize\
?response_type=code\
&client_id=oz9f...k2d\
&redirect_uri=http%3a%2f%2flocalhost%3a3000%2fapi%2fforge%2fcallback%2foauth\
&scope=data%3aread
Copy this in your browser, and after logging and the consent page, the service should return to your browser with a URL like this:
http://localhost:3000/api/forge/callback/oauth?code=wroM1vFA4E-Aj241-quh_LVjm7UldawnNgYEHQ8I
Because, we do not have a server yet, the browser will error, but you can clearly see the URL returned to you with a code. You know need to copy that code into another request to get the final token. Here, we will use curl, but ideally both request and the callback should be handled by your server code.
curl 'https://developer.api.autodesk.com/authentication/v1/gettoken' \
-X 'POST' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=oz9f...k2d' \
-d 'client_secret=eUr...Q1e' \
-d 'grant_type=authorization_code' \
-d 'code=wroM1vFA4E-Aj241-quh_LVjm7UldawnNgYEHQ8I' \
-d 'redirect_uri=http://localhost:3000/api/forge/callback/oauth'
Ideally, all this needs to be done in your server code, like the learnforge tutorial teach you to do.

Uploading a file to storage location(bucket)

I tried uploading the file using postman ,curl command in windows and linux mentioned in the url https://forge.autodesk.com/en/docs/data/v2/tutorials/upload-file/ but getting gateway timeout error.
I followed the steps in the url https://forge.autodesk.com/en/docs/data/v2/tutorials/upload-file/. I am able to create bucket. But when I tried uploading file to the created bucket its giving 504 gateway timeout error.
Can you give me the solution to resolve this?
Screenshot attached for error
Please find request below:
curl -v 'https://developer.api.autodesk.com/oss/v2/buckets/testbucket/objects/test.3ds' -X 'PUT' -H 'Authorization: Bearer TOKEN' -H 'Content-Type: application/octet-stream' -H 'Content-Length: 308331' -T 'test.3ds'
It looks like the size of your model file is too big to upload, please use the resumable upload API instead, see the related thread here Upload large files (2GB) to Autodesk Forge Data Management API

How to get an authorization token from JuPyter hub using its REST APIs?

I want to start a notebook server as described here. I learnt that I need to get an auth token from this and so wanted to get the same, I have to use the api as described here. It always states "Method not allowed, 405". I am unable to figure out what is the right way to do this.
I tried the following post requests:
http://MY_JHUB_ON_K8S_SERVER.com/authorizations/token
with the body of JSON/Application:
{
"username": "aviral",
"password": "aviral",
}
The headers are:
[{"key":"Content-Type","name":"Content-Type","value":"application/json","description":"","type":"text"}]
In Postman, I had tried basic auth as well as no auth. In the basic auth, I pasted the username and password, while when there was no auth, I put the same in the json body
I expect to get the token so that I can start a server. Right now, regardless of the permutation and combination, I am getting 405.
This seems to be possible using the oath api endpoint but I wasn't successful.
Instead I run this command on the jupyterhub server to generate a token
jupyterhub token myusername
and then calls should work properly using the rest api:
curl --insecure 'https://myjupyterhubserver:8443/hub/api/users' \
-H 'Authorization: Token mygeneratedtoken'

Create Couchbase documents via REST API

I am new to Couchbase and I want to know about how CRUD can be achieved in it.
I have sucessfully created a bucket and I've tried to insert documents in it using CURL.
Creating a bucket using CURL succeeded like the following:
curl -X POST -u admin:citrus -d name=test-bucket -d ramQuotaMB=100 -d authType=none -d replicaNumber=2 -d proxyPort=11216 http://example.com:8091/pools/default/buckets
Now how can I create sample documents in this bucket?
How can I achieve this by using a REST API, please help me..
Couchbase isn't designed to use a REST API for data creation or mutation, perhaps you are thinking of CouchDB which does offer this and shares some similarities with Couchbase although they are distinct technologies.
You need to use one of the sdks to interact with your bucket, there are a multitude of SDK's available in all the major languages, Java,Ruby,Python,C etc. Check out the list of them here, they also contain getting started guides which covers the basic operations such as get/set and more complex examples of views and topics such as locking.
http://docs.couchbase.com/
I think you should use the Sync Gateway of Couchbase. The Sync Gateway provides a REST API which allows you to Create, Read, Update and Delete (CRUD) documents.
For example, if you have a Couchbase Server running on port 8091 with a bucket called test-bucket, you can set up your Sync Gateway with the following content in your sync_gateway.json configuration file:
{
"log": ["HTTP+"],
"adminInterface": "127.0.0.1:4985",
"interface": "0.0.0.0:4984",
"databases": {
"test-db": {
"server": "http://localhost:8091",
"bucket": "test-bucket",
"username": "test-bucket",
"password": "test-bucket-password",
"users": {
"GUEST": {"disabled": false, "admin_channels": ["*"] }
}
}
}
}
Then, after starting the Sync Gateway, you can create a document like the following:
curl -X PUT -H 'Content-Type: application/json' http://localhost:4984/test-db/myNewDocId -d #document.file
With document.file being a file with the JSON content of the document you'd like to create and with myNewDocId being the ID of the new document.
You can find all supported REST API methods and details in the official documentation: http://developer.couchbase.com/documentation/mobile/1.1.0/develop/references/sync-gateway/rest-api/document/index.html
Couchbase now supports adding document via curl call.
you can do
curl localhost:8093/query/service -u uname:paaswd -d 'statement=INSERT INTO `bucketName` (KEY, VALUE) VALUES ( "my_doc_id", {"Price":"price"} );'
Note we are using 8093 which is query service port. for this to run you have to have query service(n1ql) running.

Using an authentication token obtained from v1 API in a V2 API request

As I couldn't find how to authenticate with the V2 API with my Box credential I tried to use the authentication token from a V1 API with a V2 request.
I discovered something weird and I'd like to know if something is wrong.
The documentation of the header to authenticate a V2 request described it like this for a curl command):
curl -k -L https://api.box.com/2.0/files/5053864602/content -H "Authorization: Bearer AUTH_TOKEN"
With curl I couldn't get anything, not even an error message.
However I tried this request with Postman and in the response I could see that the token was invalid.
In this forum I found that the header could have a different form including the api_key so I tried the following:
curl -k -L https://api.box.com/2.0/files/5053864602/content -H "Authorization: BoxAuth api_key=API_KEY&auth_token=AUTH_TOKEN"
and this request works as I could get the content of the file like with a V1 API call.
Could someone from BOX explains what's going on? I suspect that I'm not the only one having this problem...
The Box API now supports OAuth 2, which has a completely revised authentication flow. You can find the instructions on how to use OAuth 2.0 with Box here: http://developers.box.com/oauth/
V1-style auth is still also supported in the V2 API, though it will eventually be deprecated. However, if you're starting to build against the Box API now, you should use OAuth 2 in order to avoid having to do double work and port over in the future.
There are several differences between V1-style auth and OAuth 2.0, but notably in OAuth 2.0 you don't have to sign API requests with your API key (which is now called a 'client id' with OAuth 2.0), only the access_token you get through the auth process.
You can read more about our implementation of OAuth 2 in my previous link, and also about the spec in general here.