API Exhibitions Migration Guide
HandleData
This guide details the migration procedure used to create API exposures in the new HandleData version from the parameters of API exposures linked to DataBlock.
- To migrate APIs, you must have the following rights
-
-
Global permissions (carried by the user or group present in the Project)
-
API Exposure": to view and modify HandleData API Exposures
-
API Exhibition - Creation": to create and migrate new Exhibitions
-
-
Data source rights (DataBlock)
-
Modification
-
-
The migration does not delete the source APIs: they will therefore remain published if they were and will have to be deleted manually afterwards.
Migration details
The migrated APIs are iso-functional with the first version. However, we recommend that you *check the accesses to refine the column accesses if you were using the restrictions for managing column rights from the DataBlocks.
Migration of the APIs requires a few adaptations, particularly for users of the APIs.
Users and groups present in the source Exhibitions filters, as well as all Project members, are considered as potential consumers: they must be associated with users or groups who have active access to the sharing module (future Market Place) in the mapping stage of the migration.
Exhibitions that have already been migrated can no longer be migrated (unless the migrated Exhibition is deleted).
Exhibition metadata (private)
So-called private metadata is Exhibition metadata: it is only visible to members of DataChain Projects, never to consumers +. The API exhibition is now a fully-fledged element of the DataChain Projects: rights to the element apply in the same way as to other DataChain elements (read, modify, etc.).
API Exhibition metadata
Element | V1 Exposure DataBlock | V2 Shares : API exposure |
---|---|---|
API Exhibition label |
Non existant API Exhibition - [Datablock Label] |
API Exhibition Description |
API Exhibition Description Non-existing |
[Datablock Label |
[Datablock Label |
Tags |
Datablock |
No tags |
*API Publication Status
Migrated APIs are not automatically published, their publication status is ‘Unpublished’: they must be published manually after migration.
*API Publication parameters
Publication parameters are used to create the API configuration at the time of publication.
Once the API is published, you can modify these parameters to update the configuration.
The parameters of the V1 Exhibition that are copied as Publication Parameters in V2 are those of the published version of the API.
If the API is not published, the ‘draft’ parameters are copied.
Public’ metadata is API Publication metadata which is visible to Project members and also to consumers.
API Publication metadata (visible to consumers)
Element | V1 Exposure DataBlock | V2 Sharing: API exposure |
---|---|---|
Access point |
access_point |
access_point (copied identically) |
Title |
Non existant |
API exposure - [DataBlock label] |
Detail |
V1 description visible to consumers (or none) |
V1 Description visible to consumers (or none) |
Key words |
Non-existent |
None |
*General column parameters
The general parameters are used to define the columns available for exposure in API accesses.
An active column in the general parameters can be inactive in an access to block access to the data in this column for certain users.
General column settings
Element |
---|
V1 Exposure DataBlock |
V2 Sharing: API exposure |
Alias |
AliasColumn |
AliasColonne |
Description |
Column Description (or none) |
Description column (or none) |
id |
Active * Inactive |
Active (EXCEPT if the column is hidden: option inactive) * Inactive |
Filterable |
- |
Active: if the column type allows it * Inactive: if the type does not allow it or the column is hidden. |
I.C. |
Active * Inactive |
Active (EXCEPT if the column is hidden: option inactive) * Inactive |
Hachable |
Inactive |
Inactive |
Hidden |
Active * Inactive |
Active * Inactive |
*API access
Accesses are the evolved version of the filters found in Exhibitions V1.
They allow you to define different access rights to data (columns and rows) for the same API.
It is possible to ‘reserve’ access to data for certain users and/or to create ‘open’ access.
For all migrated APIs (with or without filter) a default access is created.
Default access
Element | Content |
---|---|
Title |
Automatically generated access |
Description |
This access was created automatically at the time of migration. It has no row filters and no column restrictions. Consumers correspond to users and groups that were mapped to Project members at the time of migration.’ |
Status |
Active |
Access Type |
Reserved |
Consumers |
Corresponds to the result of mapping all Project members (groups + users) |
If the API contains 1 or more filters, an access is created for each filter configured with users.
Element |
---|
V1 Filter Exposure DataBlock |
V2 Sharing: Access to the Exhibition API |
Filter A |
Filter A |
Filter A |
Description |
Description of Filter A * Description |
Filter A Description * Filter A |
Status |
Active * Inactive |
Active * Inactive |
Access type |
Not available |
Limited |
Consumers |
Users and groups defined for this filter |
Corresponds to the result of mapping all the groups and users defined in the filter. |