このドキュメントでは、リクエスト元、承認者、ワークフロー管理者が Knowledge Catalog(旧 Dataplex Universal Catalog)でガバナンス リクエストを管理する方法について説明します。
始める前に
ガバナンス ワークフローを使用するには、必要な API が有効になっていること、承認者と管理者に必要な Identity and Access Management(IAM)ロールと権限が付与されていることを確認します。
Dataplex API が有効になっていない場合は、有効にします。
API を有効にするために必要なロール
API を有効にするには、serviceusage.services.enable 権限が必要です。プロジェクトを作成した場合は、オーナーロール(roles/owner)を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール(roles/serviceusage.serviceUsageAdmin)を介してこの権限を取得できます。ロールを付与する方法を確認する。
必要なロール
ガバナンス リクエストの管理に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。
-
データ プロダクトへのアクセス リクエストを承認または拒否します。
- Dataplex データ プロダクト編集者(
roles/dataplex.dataProductsEditor) - Dataplex データ プロダクト管理者(
roles/dataplex.dataProductsAdmin)
- Dataplex データ プロダクト編集者(
-
メタデータ変更リクエストを確認して承認する:
- Dataplex Catalog 管理者(
roles/dataplex.catalogAdmin) - Dataplex ワークフロー承認者(
roles/dataplex.workflowApprover)
- Dataplex Catalog 管理者(
-
作成したリクエストを表示、編集する: Dataplex 変更リクエスト オーナー(
roles/dataplex.changeRequestOwner) -
拡充エージェントによって作成されたリクエストを表示、編集する: Dataplex Catalog 管理者(
roles/dataplex.catalogAdmin) -
すべてのリクエストを表示し、任意の状態のリクエストを削除します。
- Dataplex ワークフロー管理者(
roles/dataplex.workflowAdmin) - Dataplex Catalog 管理者(
roles/dataplex.catalogAdmin)
- Dataplex ワークフロー管理者(
-
承認者のメール通知を構成します。
- Dataplex Catalog 管理者(
roles/dataplex.catalogAdmin) - Dataplex Catalog 編集者(
roles/dataplex.catalogEditor) - Dataplex 用語集オーナー(
roles/dataplex.glossaryOwner)
- Dataplex Catalog 管理者(
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
ロールと権限の詳細については、Knowledge Catalog の IAM ロールをご覧ください。
リクエスト元としてリクエストを管理する
リクエスト元は、データ プロダクトへのアクセスをリクエストしたり、メタデータの変更を提案したりするなど、変更リクエストを開始します。リクエストを送信した後、承認者が対応する前に、進行状況のモニタリング、リクエストの詳細の表示、保留中のリクエストの詳細の編集、NEW 状態のリクエストの削除を行うことができます。
作成したリクエストを表示する
作成したリクエストを表示する、または特定のリクエストを検査するには、次の操作を行います。
コンソール
Google Cloud コンソールで、Knowledge Catalog の [ガバナンス ワークフロー] ページに移動します。
[My Requests] タブをクリックして、過去のリクエストと保留中のリクエストのリストを表示します。
REST
作成したリクエストを一覧表示するには、changeRequests.list メソッドを使用します。
curl -X GET \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests?filter=author=USER_EMAIL"
特定のリクエストを表示するには、changeRequests.get メソッドを使用します。
curl -X GET \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests/CHANGE_REQUEST_ID"
次のように置き換えます。
PROJECT_ID: 実際のGoogle Cloud プロジェクト ID。LOCATION: リソースが存在するリージョン(us-central1など)。USER_EMAIL: メールアドレス。CHANGE_REQUEST_ID: リクエストの一意の ID。
バッチ メタデータ変更リクエストの場合は、レスポンス フィールドを調べて、リクエストの作成方法を特定します。
- ユーザーが送信したリクエスト:
authorはリクエスト元のメールアドレスで、batchChangeMetadataRequest.description.jobは設定されていません。 - エンリッチメント エージェントが生成したリクエスト:
authorはエンリッチメント エージェントのサービス アカウントで、batchChangeMetadataRequest.description.job.nameはエンリッチメント実行 ID に設定されます。
リクエストを編集する
保留中のリクエストが NEW 状態または FAILED 状態にある場合は、REST API を使用して更新できます。FAILED 状態のリクエストを更新すると、状態が NEW にリセットされ、承認者が再度審査できるようになります。メタデータ変更リクエストを編集できるユーザーは、リクエストの作成方法によって異なります。
- ユーザーが送信したリクエスト: 元の作成者のみが
PATCHリクエストを送信して、理由またはリクエスト ペイロードを更新できます。 - エンリッチメント エージェントによって生成されたリクエスト: 作成者に加えて、レビュー担当者と承認者は、リクエストが
NEW状態またはFAILED状態のときにPATCHリクエストを送信して、バッチをキュレートできます。たとえば、提案されたアスペクト値を変更したり、changes配列からアイテムを削除したりできます。authorフィールドは、拡充エージェントのサービス アカウントのままです。
保留中の変更リクエストを更新するには、changeRequests.patch メソッドを使用します。
リクエストの理由のみを更新するには、次の PATCH リクエストを送信します。
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"justification": "NEW_JUSTIFICATION"
}' \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests/CHANGE_REQUEST_ID?updateMask=justification"
バッチ メタデータ変更リクエストのペイロードを更新するには、次の PATCH リクエストを送信します。
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"justification": "NEW_JUSTIFICATION",
"batchChangeMetadataRequest": {
"name": "projects/PROJECT_ID/locations/LOCATION/entryGroups/ENTRY_GROUP_ID",
"changes": [
{
"updateEntryRequest": {
"entry": {
"name": "projects/PROJECT_ID/locations/LOCATION/entryGroups/ENTRY_GROUP_ID/entries/EXISTING_ENTRY_ID",
"aspects": {
"ASPECT_PROJECT_ID.ASPECT_LOCATION.ASPECT_TYPE_ID": {
"data": {
"ASPECT_FIELD_NAME": "UPDATED_ASPECT_FIELD_VALUE"
}
}
}
},
"updateMask": "aspects",
"aspectKeys": [
"ASPECT_PROJECT_ID.ASPECT_LOCATION.ASPECT_TYPE_ID"
]
}
}
]
}
}' \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests/CHANGE_REQUEST_ID?updateMask=batchChangeMetadataRequest.changes,justification"
次のように置き換えます。
PROJECT_ID: 実際のGoogle Cloud プロジェクト ID。LOCATION: 変更リクエストが存在するリージョン(us-central1など)。CHANGE_REQUEST_ID: 変更リクエストの一意の ID。NEW_JUSTIFICATION: 変更リクエストの更新された理由。ENTRY_GROUP_ID: ターゲット エントリ グループの ID。EXISTING_ENTRY_ID: 更新されたバッチ ペイロードのエントリの ID。ASPECT_PROJECT_ID: アスペクト タイプを含むプロジェクトの ID。ASPECT_LOCATION: アスペクト タイプのロケーション(us-central1、globalなど)。ASPECT_TYPE_ID: 更新するアスペクト タイプの ID。ASPECT_FIELD_NAME: 更新するアスペクト フィールドの名前。UPDATED_ASPECT_FIELD_VALUE: アスペクト フィールドの更新後の値。
リクエストを削除する
リクエスト元は、NEW 状態のリクエストのみを削除できます。リクエストを削除する手順は次のとおりです。
コンソール
Google Cloud コンソールで、Knowledge Catalog の [ガバナンス ワークフロー] ページに移動します。
[My Requests] タブをクリックします。
削除するリクエストが含まれている行を見つけます。必要に応じて、フィルタを適用してエントリを分離します。
[ アクション] をクリックしてから、[削除] をクリックします。
REST
リクエストを削除するには、changeRequests.delete メソッドを使用します。
たとえば、次の DELETE リクエストを送信します。
curl -X DELETE \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests/CHANGE_REQUEST_ID"
次のように置き換えます。
PROJECT_ID: 実際のGoogle Cloud プロジェクト ID。LOCATION: リソースが存在するリージョン(us-central1など)。CHANGE_REQUEST_ID: 削除するリクエストの一意の ID。
承認者としてリクエストを管理する
承認者は、データリソースに対して送信された保留中のリクエストを評価して対応します。
通知
リクエストを承認または拒否すると、Knowledge Catalog が決定を処理し、審査コメントを記載したメール通知をリクエスト元に送信します。バッチ リクエストの場合、更新プロセスが完了すると、Knowledge Catalog からメール通知が送信されます。作成者がサービス アカウントの場合、Knowledge Catalog は通知を送信しません。
承認に関する考慮事項
自分のリクエストを承認することはできません。承認者は別のプリンシパルであり、提案された変更に必要なすべての書き込み権限とタイプ使用権限を保持している必要があります。ただし、拡充エージェントは、信頼度に基づいて独自のリクエストを自動承認するか、承認者に送信して審査を依頼できます。エンリッチメント エージェントによって生成されたバッチ メタデータ変更リクエストの場合、リクエストが NEW 状態または FAILED 状態のときに、リクエストを承認する前にリクエスト ペイロードを編集できます。
保留中のリクエストを表示
審査待ちのリクエストを表示するには、次の操作を行います。
コンソール
Google Cloud コンソールで、Knowledge Catalog の [ガバナンス ワークフロー] ページに移動します。
[Pending Approvals] タブをクリックして、審査待ちのリクエストを表示します。リクエストは、リソースタイプ、リクエスト タイプ、日付でフィルタできます。
REST
特定のプロジェクトとロケーションで審査待ちのリクエストを一覧表示するには、changeRequests.list メソッドを使用します。
たとえば、次の GET リクエストを送信します。
curl -X GET \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests?filter=state=NEW"
次のように置き換えます。
PROJECT_ID: 実際のGoogle Cloud プロジェクト ID。LOCATION: リソースが存在するリージョン(us-central1など)。
返されたリストで、バッチ メタデータ変更リクエストの changeType フィールドが BATCH_CHANGE_METADATA に設定されています。拡充エージェントの実行によって作成されたリクエストには、batchChangeMetadataRequest.description.job.name に拡充実行 ID が含まれます。
保留中のバッチ変更リクエストに対するレスポンスの例
{ "changeRequests": [ { "name": "projects/my-project/locations/us-central1/changeRequests/b326114f-472b-457d-81e8-98b8ad89c608", "uid": "b326114f-472b-457d-81e8-98b8ad89c608", "justification": "Enrichment Agent Proposal: Batch Metadata Change", "author": "enrichment-agent@my-project.iam.gserviceaccount.com", "state": "NEW", "resource": "//dataplex.googleapis.com/projects/my-project/locations/us-central1/entryGroups/my-entry-group", "changeType": "BATCH_CHANGE_METADATA", "batchChangeMetadataRequest": { "name": "projects/my-project/locations/us-central1/entryGroups/my-entry-group", "description": { "job": { "name": "projects/123456789012/locations/us-central1/enrichmentTasks/my-enrichment-task/runs/55199e83-1a1e-4837-bb8c-c402c6bee641" } }, "changes": [ { "createEntryRequest": { "parent": "projects/my-project/locations/us-central1/entryGroups/my-entry-group", "entryId": "new-entry-id", "entry": { "entryType": "projects/my-project/locations/us-central1/entryTypes/my-entry-type" } } } ] } } ] }
リクエストを承認する
リクエストを承認する手順は次のとおりです。
コンソール
Google Cloud コンソールで、Knowledge Catalog の [ガバナンス ワークフロー] ページに移動します。
[Pending Approvals] タブをクリックします。
承認するリクエストを含む行を見つけます。
[ アクション] をクリックしてから、[承認] をクリックします。
REST
リクエストを承認するには、changeRequests.approve メソッドを使用します。
たとえば、次の POST リクエストを送信します。
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{}' \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests/CHANGE_REQUEST_ID:approve"
次のように置き換えます。
PROJECT_ID: 実際のGoogle Cloud プロジェクト ID。LOCATION: リソースが存在するリージョン(us-central1など)。CHANGE_REQUEST_ID: 承認する変更リクエストの一意の ID。
ユーザーまたは拡充エージェントから送信されたバッチ メタデータ変更リクエストを承認すると、Knowledge Catalog は IAM 権限とペイロード ルールを同期的に検証します。
- 検証に成功すると、このメソッドは
APPLYING状態のChangeRequestを返します。一方、Knowledge Catalog はバックグラウンドでバッチを実行します。
{
"name": "projects/my-project/locations/us-central1/changeRequests/b326114f-472b-457d-81e8-98b8ad89c608",
"uid": "b326114f-472b-457d-81e8-98b8ad89c608",
"justification": "Proposing new entry using RequestBatchMetadataChange",
"author": "requester@example.com",
"state": "APPLYING",
"resource": "//dataplex.googleapis.com/projects/my-project/locations/us-central1/entryGroups/my-entry-group",
"approver": "approver@example.com",
"changeType": "BATCH_CHANGE_METADATA",
"batchChangeMetadataRequest": {
"name": "projects/my-project/locations/us-central1/entryGroups/my-entry-group",
"changes": [
{
"createEntryRequest": {
"parent": "projects/my-project/locations/us-central1/entryGroups/my-entry-group",
"entryId": "new-entry-id",
"entry": {
"entryType": "projects/my-project/locations/us-central1/entryTypes/my-entry-type"
}
}
}
]
}
}
```
* If synchronous payload validation fails (for example, with an
`INVALID_ARGUMENT` or `NOT_FOUND` error), the request immediately
transitions to the `FAILED` state instead of `APPLYING`.
* If permission validation fails with a `PERMISSION_DENIED` error, the request
remains in the `NEW` state.
After background execution finishes, poll `changeRequests.get` to check the
final state (`APPROVED` or `FAILED`). If any changes in the batch fail,
`batchChangeMetadataResponse.failedRequests` lists each failed change by its
position in `changes` (starting at `0`) along with the error details:
```json
{
"name": "projects/my-project/locations/us-central1/changeRequests/b326114f-472b-457d-81e8-98b8ad89c608",
"state": "APPROVED",
"changeType": "BATCH_CHANGE_METADATA",
"batchChangeMetadataResponse": {
"failedRequests": {
"1": {
"code": 5,
"message": "Entry not found."
}
}
}
}
リクエストの状態の詳細については、ガバナンス ワークフローの処理パスをご覧ください。
変更を拒否する
リクエストを拒否する手順は次のとおりです。
コンソール
Google Cloud コンソールで、Knowledge Catalog の [ガバナンス ワークフロー] ページに移動します。
[Pending Approvals] タブをクリックします。
拒否するリクエストを含む行を見つけます。
[ アクション] をクリックしてから、[拒否] をクリックします。
ダイアログで、拒否の理由を入力します。
[不承認] をクリックして確定します。
REST
リクエストを拒否するには、changeRequests.reject メソッドを使用します。
たとえば、次の POST リクエストを送信します。
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"comment": "REJECTION_REASON"
}' \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests/CHANGE_REQUEST_ID:reject"
次のように置き換えます。
PROJECT_ID: 実際のGoogle Cloud プロジェクト ID。LOCATION: リソースが存在するリージョン(us-central1など)。CHANGE_REQUEST_ID: 拒否する変更リクエストの一意の ID。REJECTION_REASON: 拒否の理由。
明確な却下コメントを提供することで、リクエスト元は決定を理解し、リクエストを再送信する前に理由を修正できます。
ワークフロー管理者としてリクエストを管理する
ワークフロー管理者は、組織全体のガバナンス リクエストを監視し、承認者のメール通知を構成し、承認履歴を監査し、任意の状態のリクエストを削除します。
承認者のメール通知を構成する
エントリ グループまたはビジネス用語集で承認者のメール通知を構成して、そのリソースに対して単一またはバッチのメタデータ変更リクエストが作成されるたびに自動的に通知されるメールアドレスを最大 10 個指定できます。
エントリ グループで通知を構成するには、entryGroups.patch メソッドを使用します。
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"changeRequestConfig": {
"approverEmails": [
"APPROVER_EMAIL_1",
"APPROVER_EMAIL_2"
]
}
}' \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/entryGroups/ENTRY_GROUP_ID?updateMask=changeRequestConfig"
ビジネス用語集で通知を構成するには、glossaries.patch メソッドを使用します。
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"changeRequestConfig": {
"approverEmails": [
"APPROVER_EMAIL_1",
"APPROVER_EMAIL_2"
]
}
}' \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/global/glossaries/GLOSSARY_ID?updateMask=changeRequestConfig"
次のように置き換えます。
PROJECT_ID: 実際のGoogle Cloud プロジェクト ID。LOCATION: エントリ グループのロケーション(us-central1、globalなど)。ENTRY_GROUP_ID: エントリ グループの ID。GLOSSARY_ID: ビジネス用語集の ID。APPROVER_EMAIL_1、APPROVER_EMAIL_2: 変更リクエストの作成時に通知する承認者のメールアドレス。メールアドレスは 10 件まで指定できます。
すべてのリクエストを表示し、承認履歴を追跡する
状態をまたいですべてのアクティブなリクエストと過去のリクエストを表示して、ワークフローをモニタリングし、データ プロダクトへのアクセスとメタデータの変更を監査できます。
コンソール
Google Cloud コンソールで、Knowledge Catalog の [ガバナンス ワークフロー] ページに移動します。
[承認ログ] タブをクリックして、完了した承認、拒否、過去の監査証跡を表示します。
REST
特定のプロジェクトとロケーション内のすべてのアクティブなリクエストと過去のリクエストを一覧表示するには、changeRequests.list メソッドを使用します。
たとえば、次の GET リクエストを送信します。
curl -X GET \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/changeRequests"
次のように置き換えます。
PROJECT_ID: 実際のGoogle Cloud プロジェクト ID。LOCATION: リソースが存在するリージョン(us-central1など)。
任意の状態のリクエストを削除する
NEW 状態のリクエストのみを削除できるリクエスト元とは異なり、ワークフロー管理者は、 Google Cloud コンソールまたは changeRequests.delete メソッドを使用して、任意の状態のリクエストを削除できます。手順については、リクエストを削除するをご覧ください。
次のステップ
- ガバナンス ワークフローの詳細を確認する。
- 単一リソースのメタデータの変更をリクエストする方法を確認する。
- バッチ メタデータの変更をリクエストする方法を確認する。