双方向のインシデントのチケッティングの統合

双方向の統合では、ServiceNow のインスタンスとサードパーティシステム間でデータが交換され、インシデント情報がシステム間で同期されます。

この統合には以下の要件があるため、一方向の統合よりも複雑になります。

• フィールドマッピングの包括的な定義。
• 変換が行われる場所の標準化：インバウンド、アウトバウンド、またはその両方。
• 参照データの所有権に関する考慮
• 更新をどのようにして継続的に行うか。

エラー処理を実装してください。これらのすべての実装を統合計画に含めてください。

双方向の実装は開発側独自のメリットに基づいて開発されますが、データ駆動型の検証ルールなど、再利用が可能なフレームワークを ServiceNow AI Platformで開発できます。

統合計画の内容

• 双方向の統合に必要なすべての側面の内容を計画します。
• 各組織の状況モデル。
• チケットの同期を保つためのビジネスルール定義。
• 個々のトランザクションの履歴を格納するための要件。この形式の監査を要件とする場合は、宛先テーブルを作成および更新する前に入力されるインターフェイステーブルを作成することを検討します。
• すべてのデータ要素の変換ルール。
• 参照データが情報システムに転送されるときのタイムライン。各システム間でデータを送受信する前に変換を実行するための要件を含めます。
• すべての段階における参照データの所有権のステートメント。
• スキーマ定義の更新。

インポートセットと Web サービスを使用する例

この実装では、データ認証がインポートセットに挿入される前に実行されます。データがインシデントテーブルに到達する前に、変換マップおよびスクリプトが実行されます。インシデントテーブルを使用して、インシデントレコードの履歴を格納します。アウトバウンドデータパスでは、データがアウトバウンドの Web サービスのキューに格納される前に、ターゲットテーブルによってビジネスルールがトリガーされる可能性があります。

インポートセットと ECC キューを使用する例

インバウンドパスの実装のバリエーションとして、インポートセットテーブル (この例ではインシデントインターフェイステーブル) を使用して履歴データを格納することが考えられます。現在ではデータの検証も行われており、処理や手動介入によって例外をクリアーすることができます。インシデントテーブルは、サードパーティ情報テーブルを参照として使用し、ビジネスルールに基づいてメッセージが生成されます。

このタイプの統合を実装するには、インバウンドデータ用としてサードパーティアプリケーションの Webサービスコンポーネントが必要です。アウトバウンドデータ用には ECC キューが推奨されます。