Enhancement to existing Bulk API for Import Metadata

kevin.cho

There is an existing bulk API endpoint that allows workspace admins to retrieve the full list of Import actions from a given model. This endpoint is in the format: 

https://api.anaplan.com/2/0/models/{{mdlID}}/imports/

 where {{mdlID}} is the model GUID. 

This returns a JSON response, which contains an object called "imports" - which is a list of JSON objects that define each import within a model. 

Each import has the following attributes: 

• id - guid of the import action, used for executing it via the Bulk APIs)
• name - name of the action from Anaplan front-end
• importDataSourceId
• importType - defines if loading into a list or module

 

The importDataSourceId is currently only populated for import actions that are sourced from a flat file, and returns the file ID of the associated import file. This key is blank for those imports that are sourced from a view/module. 

 

Enhancement request: 

The schema of an Anaplan import is defined in the following metadata endpoint 

https://api.anaplan.com/2/0/models/{{mdlID}}/objects/import

 where {{mdlID}} is the model GUID. The schema actually includes a key called importDataSource with structure below: 

"importDataSource": {
   "properties": { 
      "importDataSourceId":...,
      "sourceModelId": ...,
      "sourceModelName": ...,
      "sourceWorkspaceId": ...,
      "type": ...}}

This key should be returned as part of each import, such that we can programatically create data flow maps between our Anaplan models - something which is becoming increasingly difficult to do as the number of models and actions increase. 

axel.frot

Great suggestion !

etbell

Any updates from the Anaplan team on this? In addition to programmatically creating data flow maps, this could be extremely helpful in creating automated reports to assist with saved view maintenance. It is extremely easy for saved views to get out of hand and there is currently not a good way within Anaplan to identify which views are actively used versus those that are outdated. If this is updated it can be used in combination with a call to the https://api.anaplan.com/2/0/models/{model_id}/views endpoint to create reports to assist model builders in the cleanup process.

david.savarin

+1 to this. Maybe a quick win to bring to the api ?

Please can we also get the source model id as well for all those nice datahubs --> spoke models flows following the anaplan best practices

kevin.cho

Thanks @etbell @david.savarin @axel.frot for your support! Likewise here, this was sparked out of an initial thought to have more structured data flow maps for maintenance and change management purposes.

@AdamT any thoughts on this? Cheeky tag to get this in front of you if you hadn't seen this 😆

david.savarin

FOr us it s a regulatory requirement under bale 3 to have data lineage.

david.savarin

Besides, i believe there was a very similar idea exchange posted a while ago after discussing it in the developer forum.

Might be worth to merge them into one single topic and hopefully get more traction :

https://community.anaplan.com/discussion/140690/more-information-about-imports-in-transactional-api

axel.frot

up

david.savarin

Any news to enhance this ?