We're using the shared Forge activity "AutoCAD.PlotToPDF+prod" to get back a plotted DWG in a PDF file, but the resulting PDF is missing the last layout from the DWG. However, there see to be some cases where the last page does get included. There are no obvious differences between the DWGs that include the last page when plotted to PDF and those who don't. Is there any reason why these shared Forge activity wouldn't include the last layout from the source DWG?
This is something that's holding us up from completing a large feature implementation before deploying it to production, so we'd like to find out if we're not going to be able to use the shared activity to make this work so that we can implement a work-around and prevent missing the deadline for delivery.
Thanks in advance.
Here is an example of the input versus output.
The provided drawing is dependent on external reference "background.bmp" as overlay, Forge Design Automation is not aware of the dependent reference, you need to provide that as well.
If your drawing depends on external files, you need to zip them and send, and make sure to provide path of main drawing that to be processed in pathInZip argument of workitem.
For example
{
"activityId": "AutoCAD.PlotToPDF+prod",
"arguments": {
"HostDwg": {
"localName": "Outputs",
"pathInZip": "Output.dwg",
"url": "downloadUrl",
"verb": "get"
},
"Result": {
"url": "uploadUrl",
"verb": "put"
}
}
}
Related
Via the BIM360 API, I am able to create Quality Issues and upload files (to be used as attachments). However, even though I am calling Post Attachments (https://forge.autodesk.com/en/docs/bim360/v1/reference/http/field-issues-attachments-POST/) (and all responses are good), nothing appears on the Issue screen.
Issue screen with manually added file. How can I make my attached file appear under the References->Files section?
(Note, I saw a mention elsewhere of the relationships API, but I get a random error just calling the first "asset" API [{"title":"Forbidden","detail":"Forbidden","errorCode":"GENERAL_ERROR","type":"https://developer.api.autodesk.com/bim360/assets/v1/error-codes/GENERAL_ERROR"}])
firstly, the screenshot shows you are working with Issues in Autodesk Construction Cloud (ACC), while the API you are using is for BIM360 Issue. This API is NOT compatible with ACC.
To work with ACC Issue, the API is available at the category of ACC:
https://forge.autodesk.com/en/docs/acc/v1/reference/http/issues-issues-GET/
this blog tells more.
https://forge.autodesk.com/blog/acc-issues-api-available-preview
In the context of ACC, the attachment(references) is managed by the general API (Relationship API). In Additional Tests of Postman collection of ACC Issue API, I demoed how to add Photo with the Issue. The logic is similar.
https://github.com/Autodesk-Forge/forge-acc.issues.api-postman.collection
Firstly, use Data Management API to get the document urn. Then, use ACC Issue API to get id of one issue. finally, use Relationship API to bind them.
PUT https://developer.api.autodesk.com/bim360/relationship/v2/containers/{{project_id_without_b}}/relationships
P.s. -bim360- in the domains is just because of legacy design of the terminologies. It can work for the contexts of both BIM360 and ACC (note it is Relationship API can work within both of the contexts)
Payload:
[
{
"entities": [
{
"domain": "autodesk-bim360-issue",
"type": "issue",
"id": "{{one_issue_id}}"
},
{
"domain": "autodesk-bim360-documentmanagement",
"type": "documentlineage",
"id": "{{one_document_urn}}"
}
]
}
]
I know that it is possible to download the derivatives via their respective urns. However, the SVF2 object in the manifest doesn't contain its urn. Therefore, I cannot download the derivative as explained here or here. Is this not supported yet? And can I compute the urn from the data returned in the manifest?
Extract of an manifest example:
{
"urn": "SOME_URN",
"derivatives": [
{
"hasThumbnail": "true",
"children": [
{
"useAsDefault": true,
"role": "3d",
"hasThumbnail": "true",
"children": [
{
...
},
{
...
},
{
"role": "graphics",
"mime": "application/autodesk-svf2",
"guid": "SOME_GUID",
"type": "resource"
}
],
I'd like to make clear that it is possible to download the SVF2 'files' since your WEB browser can do it; therefore, you can access the data as well. The files are actually cached in your Browser, see below.
The Viewer downloads an extra manifest files (otg_model.json) which contains additional information. But downloading the 'files' on your local machine will not help since it requires a lot of setup to get the Viewer work properly with a local SVF2 storage. And with the current state of the technology, it is highly recommended you do not try to do this in production. When it comes to development, and debugging, I go a sample posted here which can help. But please be careful with the Autodesk EULA on doing offline workflows. This sample is a replacement of the old extract.autodesk.io sample as people were abusing of this website, and can work with both SVF and SVF2.
To answer the question in the comment section. SVF2 is still in beta, and access to the underlying data/files will probably be only available at the end on the beta. The main reason is that SVF2 and the Viewer code evolves too rapidly today to make a general availability to everything. So unless you keep updating them on your local machine, things may break, and therefore Autodesk is limiting the access.
Sorry for disappointing you, but ...
Unfortunately, it's expected behavior. SVF2 doesn't have a concept of URN, and you cannot download SVF2 for offline viewing at this moment since it's unsupported.
Is there a reliable way, short of comparing full contents, of checking if a file was updated/change in Drive?
I have been struggling with this for a bit. Here's the two things I have tried:
1. File version number
I upload a plain text file to Google Drive (simple upload, update endpoint), and save the version from the file metadata returned after a successful upload.
Then I poll the Drive API (get endpoint) occasionally to check if the version has changed.
The trouble is that within a second or two of uploading the file, the version gets bumped up again.
There are no changes to the file content. The file has not been opened, viewed, or even downloaded anywhere else. Still, the version number increases from what it was after the upload.
To my code this version number change indicates that the remote file has been changed in Drive, so it downloads the new version. Every time!
2. The Changes endpoints
As an alternative I tried using the Changes api.
After I upload the file, I get a page token using changes.getStartPageToken or changes.list.
Later I use this page token to poll the Changes API for changes, and filter the changes for the fileId of uploaded file. I use these options when polling for changes:
{
"includeRemoved": false
"restrictToMyDrive": true
"spaces": "drive"
}
Here again, there is the same problem as with the version number. The page token returned immediately after uploading the file changes again within a second or two. The new page token shows the uploaded file having been changed.
Again, there is no change to the content of the file. It hasn't been opened, updated, downloaded anywhere else. It isn't shared with anyone else.
Yet, a few seconds after uploading, the file reappears in the changes list.
As a result, the local code redownloads the file from Drive, assuming remote changes.
Possible workaround
As a hacky hook, I could wait a few seconds after the file upload before getting the new file-version/changes-page-token. This may take care of the delayed version increment issue.
However, there is no documentation of what is causing this phantom change in version number (or changes.list). So, I have no sure way of knowing:
How long a wait is safe enough to get a 'settled' version number without losing possible changes by other users/apps?
Whether the new (delayed) version number will be stable, or may change again at any time for no reason?
Is there a reliable way, short of comparing full contents, of checking if a file was updated/change in Drive?
You can try using the md5Checksum property of the File resource object, if your file is not a Google Doc file (ie. binary). You should be able to use that to track changes to the contents of your binary files.
You might also be able to use the Revisions API.
The Revisions resource object also has a md5Checksum property.
As a workaround, how about using Drive Activity API? I think that there are several answers for your situation. So please think of this as just one of them.
When Drive Activity API is used, the activity information about the target file can be retrieved. For example, from ActionDetail, you can see whether the target file was edited, renamed, deleted and so on.
The sample endpoint and request body are as follows.
Endpoint:
POST https://driveactivity.googleapis.com/v2/activity:query?fields=activities%2CnextPageToken
Request body:
{"itemName": "items/### fileId of target file ###"}
Response:
Sample response is as follows. You can see the information from this. The file with the fileId and filename was edited at the timestamp.
{
"activities": [
{
"primaryActionDetail": {
"edit": {} <--- If the target file was edited, this property is added.
},
"actors": [
{
"user": {
"knownUser": {
"personName": "people/### userId who edited the target file ###",
"isCurrentUser": true
}
}
}
],
"actions": [
{
"detail": {
"edit": {}
}
}
],
"targets": [
{
"driveItem": {
"name": "items/### fileId of target file ###",
"title": "### filename of target file ###",
"file": {},
"mimeType": "### mimeType of target file ###",
"owner": {
"user": {
"knownUser": {
"personName": "people/### owner's userId ###",
"isCurrentUser": true
}
}
}
}
}
],
"timestamp": "2000-01-01T00:00:0.000Z"
},
],
"nextPageToken": "###"
}
Note:
When you use this API in my environment, please enable Drive Activity API at API console and include https://www.googleapis.com/auth/drive.activity.readonly in the scopes.
Although when I used this API, I felt that the response was fast, if the response was slow when you use this, I apologize.
References:
Google Drive Activity API
ActionDetail
If this was not what you want, I apologize.
What you are seeing is the eventual consistency feature of the Google Drive filesystem. If you think about search, it doesn't matter how quickly a search index is updated, only that it is eventually updated and is very efficient for reading. Google Drive works on the same premise.
Drive acknowledges your updates as quickly as possible. Long before those updates have propagated to all worldwide copies of your file. Derived data (eg. timestamps and I think I recall, md5sums) are also calculated after the update has "completed".
The solution largely depends on how problematic the redundant syncs are to your app.
The delay of a few seconds is enough to deal with the vast majority of phantom updates.
You could switch to the v2 API and use etags.
You could implement your own version number using custom properties. So every time you sync up, you increment your own version number. You only sync down if the application version number has changed.
I'm following the step-by-step instructions Extract Geometry tutorial , and everything seems to work fine, except when I check the manifest after posting the job, it always returns the manifest for the initial conversion to SVF.
The tutorial specifically states that you must convert to SVF first. This takes a few seconds to a few minutes, starting at 0% and going until 100%. I await completion, and when I post the second job with the following payload (verifying that the payload is as requested)
let objPayload = {
"input": {
"urn": job.urn # urn retrieved from the file upload / svf conversion
},
"output": {
"formats": [
{
"type": "obj"
, "advanced": {
"modelGuid": metaData[0].guid,
"objectIds": [-1]
}
}]
}
}
( where metaData[0].guid is the provided guid from Step 1's call to /modelderivative/v2/designdata/${urn}/metadata)
, then the job actually starts at about 99%. It sometimes takes a few moments to complete, but when it does, the call to retrieve the manifest returns the previous manifest where the output format is marked at "svf".
The POST Job page states that
Derivatives are stored in a manifest that is updated each time this endpoint is used on a source file.
So I would expect the the returned manifest to be updated to return the requested 'obj'. But it is not.
What am I missing here?
As Cyrille pointed out, the translate job only works consistently when translating to SVF. If translating to OBJ, you can only do so from specific formats, listed in this table.
At the time of this writing, if you request a job outside that table (eg IFC->OBJ), it will still accept your job, and simply not do it. So if you're following the "Extract Geometry" tutorial, when you request the manifest, it is still pointing to the original SVF translation.
My application is currently using the Document List API to track file and metadata changes using the Changelist. When we find a file has changed, we grab the metadata, the acl information, and the actual file. Lately we've found that we are getting a number a percentage of files that continually show up in the changelist every time we check.
After a bit of investigating, there is very little metadata that is changing in the file.
Here are examples from two different files that continually show up in the changelists.
Is there anyway I can avoid seeing these files over and over again? I have partially optimized to not download the files again, but it is still taking extra quite a bit of overhead to weed out false-positives from the changelist. Does anyone know if updating my app to use the Drive API will fix this issue?
Here is an example of what I'm seeing:
File 1 - Through the Documents List API
Initial Info
entry:etag=\""CkcaSU1LASt7ImBk"\"
id:...feeds/id/spreadsheet%3A0AgVqS9FfzZOCdGhZSVZ4UEtyT2tmRnZsR3lGNFBrVWc
published:2010-12-13T01:58:22.467Z
updated:2010-12-13T02:03:22.269Z
...
link:rel=\"thumbnail\" type=\"image/jpeg\" href=...?id=0AgVqS9FfzZOCdGhZSVZ4UEtyT2tmRnZsR3lGNFBrVWc&v=1&s=AMedNnoAAAAAUQHGlnP_b5jppjlFLN9OHRY5VSP2KZNR&sz=s220\"
...
/entry
Next Time I looked at the changelist
entry etag=\""CkUFR0sIQyt7ImBk"\"
id:...feeds/id/spreadsheet%3A0AgVqS9FfzZOCdGhZSVZ4UEtyT2tmRnZsR3lGNFBrVWc
published:2010-12-13T01:58:22.467Z
updated:2010-12-13T02:03:22.269Z
...
link:rel=\"thumbnail\" type=\"image/jpeg\" href=\"...?id=0AgVqS9FfzZOCdGhZSVZ4UEtyT2tmRnZsR3lGNFBrVWc&v=1&s=AMedNnoAAAAAUQMH4STQC7QSN1CJivPIl0U5KvMD8eKe&sz=s220\"
...
/entry
The only differences are the etag, updated time, and thumbnail image. The file itself did not change at all.
File 2 - This info I grabbed using the APIs explorer (using the DriveAPI 2 changes.get)
{
"kind": "drive#change",
"id": "21012",
"fileId": "0AgVqS9FfzZOCdGQyQUNjWkF0alVpNGd0WXNLMnpNU2c",
...
"thumbnailLink": ".../feeds/vt?gd=true&id=0AgVqS9FfzZOCdGQyQUNjWkF0alVpNGd0WXNLMnpNU2c&v=1&s=AMedNnoAAAAAUQlhSo3rF73K5WnN7E0qSR0uMhWEqM-t&sz=s220",
...
}
Ran through grabbing changes from the Documents List API, then checked the changelist again.
{
"kind": "drive#change",
"id": "21013",
"fileId": "0AgVqS9FfzZOCdGQyQUNjWkF0alVpNGd0WXNLMnpNU2c",
...
"thumbnailLink": ".../feeds/vt?gd=true&id=0AgVqS9FfzZOCdGQyQUNjWkF0alVpNGd0WXNLMnpNU2c&v=1&s=AMedNnoAAAAAUQlh69m8ZG_MzNujmmu80HN9XJ2jpG61&sz=s220",
...
}
In this case, the thumbnail link had again changed, and there was no longer a change with id 21012.