SKP Catalog/Quality - use REST API to read and create Asset Versions
As Data Quality is now more widely used, some customers will deploy it with multiple tenants of SKP. This poses a problem when trying to move the Catalog Asset Versions. For Eli Lilly, the chief concern is that asset version history will be lost when moving from their SKPv1 tenant to their SKPv2 tenant, but the same issue exists if they should ever need to move to some “v3” tenant in the future. It is considered a high risk at Eli Lilly that they cannot move Asset Versions between tenants.
Please enhance the SKP REST API to include a Version parameter when reading or creating the various Catalog assets that permit versioning. The current design always returns the latest version and there is no method for creating multiple versions of an Asset at once.
Log in to comment and vote
Comments2
John Munkberg
Aug 7
@Ben Bauer In theory - if a term has 7 version in history - we could load Version 1, and then update it with versions 2-7 in order which would recreate the Version History minus the Change Dates and Stakeholder Approvals.
What are the actual requirements? Is the history of changes to the asset the goal, or the DATES and APPROVAL history, or ??
Is this only an artifact of converting SKP V1 to SKP V2 (tenant to tenant), or does this have broader implication of onboard Catalog Data into a new tenant? If they were converting from another catalog into SKP, would this be a requirement? They would need to be able to load every asset and it’s full lifecycle history? Or is this just an SKP ask because they are upgrading their tenant?
I need to understand if this is just a project issue, or a broader issue for the platform. And what are those requirements - and where are those requirements coming from (GxP, SOX, etc)?
John Munkberg
Aug 7
The design of SKP is such that each customer has a single tenant, and the DEV/QA/PROD environments are handled inside the tenant. Because it’s a SAAS platform, all tenants are the save “version” - therefore the versioning used by a client is related to their Assets (systems, datasets, terms, construct apps, ETL jobs, etc). Those are versioned within the tenant itself.
Now - if you need to LOAD an asset, or EXPORT an asset, it might be interesting to load this “HIstoric” data if desired. I don’t know how much this would be used - but I can sense that in certain industries that my critical. So I think this is something we could support - loading data or exporting data to include historic versions.