双方向のインシデントのチケッティングの統合
双方向の統合では、ServiceNow のインスタンスとサードパーティシステム間でデータが交換され、インシデント情報がシステム間で同期されます。
この統合には以下の要件があるため、一方向の統合よりも複雑になります。
- フィールドマッピングの包括的な定義。
- 変換が行われる場所の標準化：インバウンド、アウトバウンド、またはその両方。
- 参照データの所有権に関する考慮
- 更新をどのようにして継続的に行うか。
エラー処理を実装してください。これらのすべての実装を統合計画に含めてください。
双方向の実装は開発側独自のメリットに基づいて開発されますが、データ駆動型の検証ルールなど、再利用が可能なフレームワークを Now Platformで開発できます。
統合計画の内容
- 双方向の統合に必要なすべての側面の内容を計画します。
- 各組織の状況モデル。
- チケットの同期を保つためのビジネスルール定義。
- 個々のトランザクションの履歴を格納するための要件。この形式の監査を要件とする場合は、宛先テーブルを作成および更新する前に入力されるインターフェイステーブルを作成することを検討します。
- すべてのデータ要素の変換ルール。
- 参照データが情報システムに転送されるときのタイムライン。各システム間でデータを送受信する前に変換を実行するための要件を含めます。
- すべての段階における参照データの所有権のステートメント。
- スキーマ定義の更新。
インポートセットと Web サービスを使用する例
この実装では、データ認証がインポートセットに挿入される前に実行されます。データがインシデントテーブルに到達する前に、変換マップおよびスクリプトが実行されます。インシデントテーブルを使用して、インシデントレコードの履歴を格納します。アウトバウンドデータパスでは、データがアウトバウンドの Web サービスのキューに格納される前に、ターゲットテーブルによってビジネスルールがトリガーされる可能性があります。
インポートセットと ECC キューを使用する例
インバウンドパスの実装のバリエーションとして、インポートセットテーブル (この例ではインシデントインターフェイステーブル) を使用して履歴データを格納することが考えられます。現在ではデータの検証も行われており、処理や手動介入によって例外をクリアーすることができます。インシデントテーブルは、サードパーティ情報テーブルを参照として使用し、ビジネスルールに基づいてメッセージが生成されます。
このタイプの統合を実装するには、インバウンドデータ用としてサードパーティアプリケーションの Webサービスコンポーネントが必要です。アウトバウンドデータ用には ECC キューが推奨されます。