I've run into another issue with uploading a file using the Anaplan API. For this client I'm trying to do a data integration from a data migration tool called Scribe Online where the API connections are configured using a GUI. When Scribe receives the API specifications from anaplan.com/swagger.json it brings in the expected set of methods (i.e. POST, PUT, DELETE, etc.) in the form of objects that Scribe calls "blocks".
When I grab the PUT block into the Scribe Online mapping configuration it returns several PUT methods listed in their entirety below;
Put Put_1subversioncustomerscustomeriduseruserid Put Put_1subversionworkspacesworkspaceguidrestofpath Put Put_2subversioncat_valuescategory_value_id Put Put_2subversiondwahostshostGuid Put Put_2subversiondwapoolspoolGuid Put Put_2subversionwaworkspaces Put Put_2subversiondwaworkspaceServerGuid Put Put_2subversiondwaworkspacesworkspaceGuid Put Put_2subversionmodels Put Put_2subversionmodelsmodel_idcat_valuescategory_value_id Put Put_2subversionmodelsmodelIdpath Put Put_2subversionmodelsmodelIduseruserIdfavoritefavorite Put Put_2subversiontenants Put Put_2subversiontenantstenantId Put Put_2subversionusers Put Put_2subversionworkspacesworkspaceIdmodelsmodelIdpath
Examining the fields in these PUT method "variations" it would seem that they do not have many headers and parameters that match up with the Anaplan API docs in Apiary. For example, not a single one of those PUT methods will populate a field for "Content-Type" which is obviously critical for performing a file upload into Anaplan. I've attached screenshots to this post for further detail.
Has anyone else had to use a data migration tool or run into these PUT methods before? If so, which variation did you find worked out and to which fields & headers did you enter the parameters?
Just to tag on to this - I think I've uncovered where all the PUT operation invariants are coming from. Since Anaplan has created Connectors for several other applications like Tableau & Boomi it would seem that the invariants are the result of these other Connectors that aren't covered in the API docs.
I believe this actually opens up the issue to 2 questions. 1. What is the invariant that's actually associated with the examples shown in the API documentation? 2. If one of these invariants is not correlated with the API doc's examples - are there other Specification URIs that can be used?
Question 2 would be of particular interest in this case since I can provide a specific Specification URI to the connector in Scribe Online.
The swagger.json you retrieved only covers a subset of the API functionality - specifically anything that does down below the model level is out of scope. I'm afraid it won't be any use for uploading files and running imports, etc. The "proxy" ones get you down to that level, past that you'll need to fill in the details yourself.