Importing communities
Command structure |
---|
|
Identifier
You can use any of the following fields as the identifier for a community but only one at a time:
id
name
externalSystemId
andexternalEntityId
Identifier structure |
---|
|
Code snippets in this section may show redundant data to demonstrate the fields accepted by the import API.
Optional fields
Field name | Field type | Remarks |
---|---|---|
description | String | Sets the community description. |
name | String | Sets the community name. Should only be used for updates. |
parent | The identifier of a community. | Sets the parent community for the community. |
responsibilities | The resource role and one or more users or user groups. | Creates or replaces responsibilities for the associated community. |
Expected behavior
If a community with the name Technical Community does not exist, the import API performs an insert
operation. It creates a community with the specified name and description. The parent community is retrieved and set as parent for the newly created community. If the parent community does not exist, the import results in an error.
The community name is changed to New Technical Community because of the implicit SET
operation.
If a community named Technical Community already exists, an update
operation is performed. The description and parent community are updated based on the provided input.
The Import API does not support importing nested communities in a single request. Parent communities of imported communities must exist in Collibra for the imported communities to be created successfully. The following example is not supported: to import all three communities, you must send three requests, each with just one community, in the order of dependency, starting from root to the children.
[
{
"name": "Technical Community 1",
"resourceType": "Community",
"identifier": {
"externalEntityId": "externalEntity1",
"externalSystemId": "externalSystem1"
},
"parent": {
"name": "Parent of All Communities"
}
},
{
"name": "Technical Community 2",
"resourceType": "Community",
"identifier": {
"externalEntityId": "externalEntity2",
"externalSystemId": "externalSystem2"
},
"parent": {
"name": "Technical Community 1"
}
},
{
"name": "Technical Community 3",
"resourceType": "Community",
"identifier": {
"externalEntityId": "externalEntity3",
"externalSystemId": "externalSystem3"
},
"parent": {
"name": "Technical Community 2"
}
}
]
Although not guaranteed, in some situations, the import may still be able to handle nested communities in a single request. To ensure consistency, you should avoid such requests.
Add operation
If the community needs to be created, the following fields have to be provided in order to import successfully:
name
Responsibilities
You define a responsibility by specifying a resource role, identified by name or ID, and assigning to it one or more users or user groups, identified by ID:
{
"00000000-0000-0000-0000-000000005018": [
{
"user": {
"id": "00000000-0000-0000-0000-000000900001"
}
}
],
"Business Steward": [
{
"userGroup": {
"id": "00000000-0000-0000-0000-000001000002"
}
}
]
}
The resource roles, users and user groups that define the imported responsibilities must already exist in Collibra.
You must specify each role only once in the list of responsibilities.
You can assign multiple users and multiple user groups to the same role:
"responsibilities": {
"Chief Data Officer": [
{
"user": {
"id": "00000000-0000-0000-0000-000000900001"
}
},
{
"user": {
"id": "00000000-0000-0000-0000-000000900002"
}
},
{
"userGroup": {
"id": "00000000-0000-0000-0000-000001000002"
}
}
]
}
The Import API performs a query for the responsibilities in Collibra and:
- If the same responsibilities exist, the Import API performs no action.
- If responsibilities other than the ones provided in the input exist, they remain unchanged.
- If a responsibility exists with the same role but different assignees, the Import API deletes the existing responsibility and replaces it with the one provided in the input.
- If the responsibilities do not exist, the Import API creates them.