---
sourceDocument: Xanadu IT Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/it-service-management

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

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

# 双方向のインシデントのチケッティングの統合 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：2分

双方向の統合では、ServiceNow のインスタンスとサードパーティシステム間でデータが交換され、インシデント情報がシステム間で同期されます。
この統合には以下の要件があるため、一方向の統合よりも複雑になります。

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

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

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

## 統合計画の内容

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

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

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

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

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

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