api v1 REST checkin

[Anonymous]

Hi. I'm working on PLM360 addin and I have some problems with it. I've found some difference between api v2 and the current. In api v2 FileUploadRequest object was send in request body. Api v1 checkin specs doesn't contain any info about body in request. Please give me any C# example how to organize my api v1 checkIn request.

Best regards, Dmitrij.

[gasevsm]

Hi Dmitrij,

Please review the following help page for schema and example on how to do checkin via API v1. http://help.autodesk.com/view/PLM/ENU/?guid=GUID-2A356A1D-F64E-436A-9A2B-7C83D1E70E2B

Hope this helps,

[Anonymous]

Thank you for reply, Martin! Follow to sepecs I've always have 415 error: "The server refused this request because the request entity is in a format not supported by the requested resource for the requested method (Unsupported Media Type)".

My request object:

this.RequestFormat = DataFormat.Json;
this.AddUrlSegment("id", workspaceId.ToString());
this.AddUrlSegment("dmsID", itemId.ToString());
this.AddUrlSegment("fileID", fileId.ToString());
this.AddHeader("Content-Type", "application/json");

What's wrong with this transferred data?

[Anonymous]

Martin, thanks for the reply! But for now I have the next error message "The first part of the request should contain object information". It seems like I need to transfer object info in the body of the request. But, again, I couldn't find any information about this in specs - http://help.autodesk.com/view/PLM/ENU/?guid=GUID-CB766836-98D8-4E46-BB7B-C031B4B6DCD4

[gasevsm]

Greetings,

The URL for checkins is different than for creating/uploading initial attachments, but the payload structure is the same as in create attachments or add binary file into an image field type on itemdetails. Please review this link. http://help.autodesk.com/view/PLM/ENU/?guid=GUID-F31EF246-A5EA-4892-B188-AA3F11DE4DBB

Here, the code is missing a payload for the application/json part. 

{
   "fileName":"{FileName}",
   "resourceName":"{UniqueResourceName}",
   "description":"{FileDescription}"
}

Also missing is a header on the entire http call "Content-Type: multipart/mixed" as well as the second part of the payload being binary including a Content-Disposition header and specific fields like "key" mandatory.  Please take a look at this dealing with adding a binary file to field of type Image for a complete example. http://help.autodesk.com/view/PLM/ENU/?guid=GUID-D189F997-B297-4C83-A249-B4A5F3671E39

Hope this helps,

[Anonymous]

I am also trying to checkin files via the v1 api. I have read the above but am still getting a 500 - Internal Server error. Is there any possible way to post a curl example as many of the help files show?

Thanks,

Nick

[Anonymous]

Hi, Nick. Just do 'check out' & 'undo check out' operations because attachments are marked as "checked in" by default after upload. This works for me.

[Anonymous]

I just tried to do a 'checkout,' change my file contents, then a 'create an attachment' for the same file and then an 'undo checkout.' I think this process did exactly what I would expect in that the checkout was taken away but the file contents were not updated so the attached file was the same as it was before the 'checkout' was performed. Is that the same for you? I would think that I would have to successfully complete a 'checkin' for the file to be updated.

I have tried to do the 'checkin' by creating the multipart/mixed request with the json as the first part and the second part being the file binary data. I do this via curl:

curl -v -k -i -X POST \
-H "Content-Type: multipart/mixed" \
-H "Accept: application/json" -H "Cookie: customer=<customer>; JSESSIONID=<sessionid>;" \
-F "metadata=@file.json; type=application/json" \
-F "content=@'document.pdf'; type=application/octet-stream" \
https://<tenant>.autodeskplm360.net/api/rest/v1/workspaces/22/items/14305/attachments/16/checkins' 

with the file.json being:

{
   "fileName":"document.pdf",
   "resourceName":"document.pdf",
   "description":"Test Document"
}

This returns a 500 - Internal Server Error:

HTTP/1.1 500 Internal Server Error
Date: Mon, 27 Jul 2015 14:04:47 GMT
Server: Apache
Set-Cookie: PLM360LBR=cookie==; path=/; domain=tenant.autodeskplm360.net
Vary: Cookie,Host,Accept-Encoding
Cache-Control: no-cache
Access-Control-Expose-Headers: X-AUTODESK-URI-ENCODING
Content-Length: 154
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-XSS-Protection: 1; mode=block
Connection: close
Content-Type: application/xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><errors xmlns:ns2="http://ns.autodesk.com/storage/v1"><httpStatusCode>500</httpStatusCode></errors>

Any help is appreciated.

Thanks,

Nick

[Anonymous]

Hi, Nick. Yeah, I think that problem with 'check in' wasn't solved because it didn't work for me too as I want. I figured this problem out with replace 'check in' operation with the next two:
1) Delete an attachment
2) Create an attachment
Hope, this helps.

[Anonymous]

While I agree that the deleting and replacing an attachment will update the file, it unfortunately also makes the change log of my workspace item not completely accurate. I also am unsure what would happen to the attachment version history. As this is important to the traceability of my workspace, the deleting and re-attaching method is not a perfect solution. Thanks for the suggestion though.

I have continued to try and make the check in work still with no success. Any other information or advice is appreciated.

Thanks,

Nick

[Anonymous · Accepted solution]

We have been working on making use of the checkout/checkin API recently and have managed to get it working so I thought I'd share our insights with this thread.

It turns out that the "checkins" API method payload isn't quite the same as the one for a new attachment, it's missing a fileVersion:

{
   "fileName":"{FileName}",
   "resourceName":"{UniqueResourceName}",
   "description":"{FileDescription}"
   "fileVersion":"{FileVersion}"
}

The first checkin of a file doesn't require this so we guess the API defaults it to 1 if it's missing.

Otherwise, setting up the request just as Martin describes in his post on 30th June worked just fine for us.

[Anonymous]

Excellent job! This works perfectly. Thanks!

[gasevsm]

Greetings. 

Please refer to this article as there a fix that you may be looking for.  Seems tho threads interested in same topic, so I'm unifying the audience and interested parties.  Kudos to @Anonymous and his development team for discovering the fileVersion missing default behavior~!

Hope this helps,