DatabricksインジェストのためのServiceNowの構成
Databricksインジェスト用にServiceNowインスタンスを構成する方法について説明します。
認証方法を選択する
次の認証方法がサポートされています。
- ユーザー対マシン(U2M)OAuth(推奨)
- マシン間(M2M)OAuth(クライアント認証情報)
- OAuth リソース所有者パスワード資格情報 (ROPC)
Databricksでは、接続にServiceNowユーザーのパスワードを保存する必要がないため、ROPCではなくU2MまたはM2M OAuthを推奨しています。U2M OAuthでは、認証トークンの有効期限が切れるとServiceNow接続の有効期限も切れます。defaultでは、これは100日ごとに発生します。頻度を減らすには、ServiceNowで有効期限を変更するか、M2M OAuthまたはROPCを使用します。
ユーザーの操作なしで実行される完全に自動化された本番運用パイプラインには、M2M OAuthを使用します。M2M OAuthでは、DatabricksはOAuthアプリケーションのクライアントIDとクライアントシークレットで認証を行い、必要に応じて新しいアクセストークンをリクエストするため、有効期限が切れる更新トークンや対話型のサインインは不要です。リクエストは、OAuthアプリケーションに割り当てた OAuthアプリケーションユーザー の権限で実行されます。M2M OAuthには、ServiceNow Washington DCリリース以降が必要です。
取得した認証の詳細を使用して、ServiceNow への Databricks Unity Catalog 接続を作成します。
ユーザーに権限を付与する
ServiceNow ユーザー権限を付与するための次のオプションがサポートされています。
OAuthスコープ | 説明 |
|---|---|
管理者アクセス(推奨) |
|
最小権限アクセス | テーブルレベルの ACL を使用します。 |
M2M OAuthの場合は、 OAuthアプリケーションの作成 で OAuthアプリケーションユーザー として割り当てるユーザーにこれらの権限を付与してください。
管理者アクセス(推奨)
Databricksはこのアプローチを推奨しています。なぜなら、効率的なスキーマ検出が可能になるからです。管理者権限があれば、コネクタはテーブルの継承階層に関係なく、テーブルごとに単一のAPI呼び出しで完全なテーブルスキーマを取得します。これにより、APIの使用量が削減され、パイプラインの起動パフォーマンスが向上します。
次の権限が必要です。
- 削除をキャプチャするには、ServiceNow ユーザーが の
sys_audit_delete tableにアクセスできる必要があり、取り込まれるテーブルが削除を追跡している必要があります (ServiceNow でテーブル属性をno_audit_delete=trueに設定することはできません)。 - ServiceNow ユーザーには、
adminロールが必要です。 - (オプション)管理者ユーザーを読み取り専用アクセスに制限するには、管理者ユーザーに
snc_read_onlyロールを割り当てます。
最小権限アクセス
権限制限がAPI使用量の最小化よりも重要な場合にのみ、この方法を選択してください。
管理者権限がない場合、コネクタはスキーマを検出するために複数のAPI呼び出しを行う必要があります。ServiceNowはテーブルの継承を使用するため、コネクタはテーブル階層全体(ターゲットテーブルから各親テーブルを経てルートテーブルまで)をたどり、チェーン内のすべてのテーブルのフィールド定義を取得する必要があります。API呼び出しの正確な回数は、テーブルの継承階層の深さによって異なります。
最小権限アクセスによるスキーマ検出は、初期設定時だけでなく、パイプラインの実行ごとに行われます。
この方法には、以下のACL権限が必要です。
sys_dictionarysys_dictionary.*sys_db_objectsys_db_object.*sys_audit_deletesys_audit_delete.*sys_glide_objectsys_glide_object.*
クライアント認証情報の付与(M2Mのみ)を有効にする
U2M OAuthまたはROPCを使用している場合は、このステップをスキップしてください。
ServiceNowでは、OAuthクライアント認証情報グラントはdefaultで無効になっています。M2M OAuthを使用する前に、ServiceNow管理者が有効にする必要があります。
-
すべて メニューで、
sys_properties.listと入力し、 Enter キーを押します。
-
glide.oauth.inbound.client.credential.grant_type.enabledプロパティを検索します。- プロパティが存在する場合は、それを開き、 値 を
trueに設定します。 - プロパティが存在しない場合は、 新規 をクリックし、次を入力します:
- 名前 :
glide.oauth.inbound.client.credential.grant_type.enabled - タイプ :
true | false - 値 :
true
- 名前 :

- プロパティが存在する場合は、それを開き、 値 を
-
更新 (新しいプロパティの場合は 送信 )をクリックします。
OAuthアプリケーションを作成する
この手順では、Databricks への取り込みにおける ServiceNow 認証の詳細を収集します。
ServiceNowでは、U2M OAuthにはdefaultで多要素認証(MFA)が必要です。サインイン時に、標準のMFAフローの一部として2番目の認証方法を提供します。この要件は、M2M OAuthまたはROPC認証には適用されません。
ServiceNow 管理者は、認証ユーザーを MFA 要件から除外できます。手順については、ServiceNow ドキュメントの「ユーザー免除」を参照してください。
-
「すべて 」メニューで「 システム OAuth 」を検索し、「 アプリケーション・レジストリ 」をクリックします。

-
[ 新規] をクリックして>外部クライアントの OAuth API エンドポイントを作成します 。

-
アプリケーションの名前を入力します。
-
認証スコープ のリストに
useraccountを追加します。 -
(U2M OAuth のみ) リダイレクト URL に
https://<databricks-workspace-url>/login/oauth/servicenow.htmlと入力します。<databricks-workspace-url>完全な Databricks ワークスペース URL (例:https://8757561887652360.0.gcp.databricks.com) に置き換えます。 -
(M2M OAuth のみ) クライアント資格情報の許可のためにアプリケーションを構成します。
-
フォームに defaultの付与タイプ フィールドがある場合は、 クライアント資格情報 を選択します。
-
[OAuth Application User] について、コネクターを実行するユーザーを選択します。このユーザーには、ユーザー権限の付与の権限が必要です。Databricksは、専用のサービスアカウントユーザーの使用を推奨しています。
フォームに OAuthアプリケーションユーザー フィールドがない場合は、フォームヘッダーを右クリックし、 設定 > フォームLayout をクリックします。 OAuthアプリケーションユーザー を 選択済み リストに移動し、 保存 をクリックします。

-
-
「送信」 をクリックします。

-
クライアント ID と クライアント シークレット をコピーします。
インスタンス ID を取得する
インスタンス ID は、ServiceNow アカウントのログイン URL の最初の部分です。
https://<instanceid>.service-now.com
たとえば、ServiceNow インスタンスのホームページが https://abc.service-now.comの場合、インスタンス ID は abcです。
ユーザー名とパスワードを取得する
このステップは ROPC フローにのみ必要です。 Databricks では、代わりに U2M OAuth を使用することをお勧めします。
アクティブな ServiceNow ユーザーのユーザー名とパスワードを取得します。
カーソル列のインデックス作成を有効にする
取り込みパフォーマンスを向上させるために、Databricks では、ServiceNow 管理者と協力して ServiceNow のカーソル フィールドのインデックス作成を有効にすることをお勧めします。カーソル列は、可用性と優先順位に従って次のリストから選択されます: sys_updated_on (最初の選択肢)、 sys_created_on (2 番目の選択肢)、 sys_archived (3 番目の選択肢)。これは、ServiceNow APIs使用して取り込む際のパフォーマンスを向上させるための標準的なアプローチです。 インデックスを設定すると、Databricks はカーソル列全体を完全にスキャンすることを回避でき、大規模な更新のボトルネックとなる可能性があります。手順については、ServiceNow ドキュメントの「テーブル インデックスの作成」を参照してください。