ServiceNowのData Policy機能を理解する

そもそもData Policyとは何か？

データポリシーを使用すると、フィールドに必須の読み取り専用状況を設定することで、データの一貫性を強制できます。
データポリシーは UI ポリシーに似ていますが、UI ポリシーは、標準のブラウザーを介してフォームに入力されたデータにのみ適用されます。データポリシーは、インポートセットまたは Web サービスを通じて取り込まれたデータやモバイル UI から入力されたデータを含む、システムに入力されたすべてのデータにルールを適用できます。
（引用元：https://www.servicenow.com/docs/r/ja-JP/zurich/platform-administration/c_DataPolicy.html）

UIポリシーではクライアント側に対してのみのルール適用になってしまうが、このData Policy機能を使うことであらゆる入口からのデータ挿入・更新に対して、同じガードレールを適用できるようになります、ということですね！

Data Policy設定画面

必ず全てのデータ更新パターンに強制する仕様にはなっておらず、インポートセット、SOAP、クライアントでそれぞれ使い分けができるような仕様になっているよう。

やってみる

事前にチェックボックスとテキスト項目を用意してテーブルを作成しておきます。

業務でもよくあるシナリオかと思いますが、チェックボックスがONの場合のみ、テキスト項目を編集可・必須とする、というかなりシンプルな事例です。

設定方法

検証

画面の初期描画時には、先程作成したData Policyの条件には合致しません。
ただし、「Falseの場合には取り消し」の設定をしておいたため、条件に合致しない場合には逆向きの動作が働き、読み取り専用・任意項目として表示されます。

チェックをONに設定した場合には正しく動作することがわかります！
「クライアントのUIポリシーとして使用」にチェックを入れているので、別途Ui Policyを設定しなくても良いのは開発者体験的にはGoodですね。フロントエンド・バックエンドで同じ型を共有しているといった感覚でしょうか。

List画面からのデータ更新

ではこの状態でList画面からデータを編集しようとした場合にも正しく動作するのか検証してみます。

一見データ更新できてしまいそうな予感がしましたが、チェックに引っかかり保存処理に失敗しました。
ただ言語設定が日本語になっているにも関わらず、エラーメッセージが英語となっているのはイマイチですね。エラーになったことは何となく分かるけど、どう対処したら良いかに迷ってしまいそうです。

データインポートによる更新

続いて、XML形式でのデータインポートでも試してみようと思います。
インポート画面には以下の注意書きがされています。

⚠️XML からレコードをインポートする場合、ビジネスルールは適用されません

正しくチェックに引っかかりインポートされませんでした！

Record Producerによるデータ登録

じゃあRecord Producer経由での処理ではどうかも検証したいと思います。
これまでと同様にちゃんと反映されていますね。

当然これではユーザーエクスペリエンスが悪いので、Record Producer側で適切なバリデーションチェックを実施すべきではありますが、もし実装に漏れがあったとしても不整合なデータが登録される事態を防ぐことはできますね。

あとからData Policy定義を変更したらどうなる？

ちょっと意地悪な検証です。
既存のData Policyを変更したり、あるいは既存データでは整合性が取れていない条件でData Policyを追加した場合にはどうなるでしょうか？

まず、既存データに対してチェックが行われることはありませんでした。
なのでそのままの状態で既存データのFormを開くと、必須項目を入力しなさいという状態になります。
Formでは当然必須項目を入力しないと保存できないわけですが、Listから必須項目とは関係ないデータ更新しようとした場合はどうなるでしょうか？
この場合にもこれまでと同様のエラーメッセージが表示され保存できませんでした。

そのため、既存のData Policyを変更、あるいは既存データが影響を受けるData Policyを追加する場合には、事前にデータパッチ等で手当てしておかないと、ユーザーが思い通りにデータ更新ができない事態が発生する可能性がありますね。

まとめ

Data Policy機能は、一貫したデータ整合性を保つために非常に重要な機能だと理解できました！

ServiceNowでは、通常のForm画面からのデータ編集だけでなく、List、API、Record Producer等様々な入口が提供されている故、注意しないと後続のデータ連携処理や、データ利活用時に問題が発生する可能性があります。

もちろんData Policyでは最低限のガードレールしか敷けないので、複雑な入力補助・ビジネスロジックが存在する場合には他にも考慮しなければならないポイントはあるかと思いますが、「これは本当にUI Policyで実装すべきか？」は常に意識しながら開発をしていきたいなと思いました。