Cisco Prime Service Catalog 12.1 統合ガイド

Service Link 統合を開発するための前提条件

Service Link 統合の開発には、幅広い技術スキルが必要です。これには次が含まれます。

• Active Form Components（AFC）でのディクショナリ使用の設定方法や配信計画でのタスクの設計方法など、サービス設計に関する理解。
• アプリケーションをホストしているサーバを含め、ターゲットのサードパーティ システムに関する詳細な知識。
• すべてのアダプタについて、XML タグ構造に関する理解（Service Link は XML メッセージをサービス カタログ（Service Catalog）と外部システム間で送信することで動作するため）。
• すべてのアダプタの XML スタイルシート言語（XSL）変換の設定に関するある程度の理解（Service Link ウィザードを使用して適用できる XML 変換を補完するため）
• データベース アダプタを使用する場合は、SQL に関する知識も必要です。
• http/Web サービス アダプタを使用して、サービス カタログ（Service Catalog）と Web サービス間でメッセージを渡す場合は、SOAP、WSDL、RESTful API、および Web サービス セキュリティのような Web サービス コンポーネントの知識が役立ちます。

Service Link の設計コンポーネント

サービス カタログ（Service Catalog）では、2 つの方法で統合を設計できます。

• Service Designer で使用できる Integration ウィザードは、Web サービスの統合を作成するためのウィザード形式のアプローチです。
• Service Link モジュールには、外部システムとの通信に使用されるメッセージング プロトコルに関係なく、すべての統合の作成および維持するための機能があります。

統合が追加されると、Service Link から使用できる高度な設定機能によって表示および維持が可能になります。上級ユーザは、場合によってはウィザードを使わずに、この機能を使用して Web サービスを統合することもできます。

また、管理者は Service Link を使用して、実稼働環境での統合の管理およびトラブルシューティングを実行します。

統合環境は、次のコンポーネントで構成されます。

• アダプタ

アダプタは、サービス カタログ（Service Catalog）から他社製システムに XML ドキュメントまたはその他のメッセージを送信するためのトランスポート コンポーネントを論理的に表現する用語です。あらかじめパッケージ化されたアダプタは、ファイル、http/Web サービス、JMS、IBM MQ、データベースなど、さまざまなメッセージ トランスポート プロトコルをサポートしています。

アダプタは、2 つのコンポーネントで構成されます。

– 着信アダプタ

受信アダプタは、外部システムからの着信メッセージを管理します。外部システム メッセージは、データを Service Catalog で解釈できるように、変換によって「標準」の nsXML（旧称 newScale XML）形式に変更できます。

受信アダプタには、ポーラーとリスナーの 2 種類があります。ポーラーは定期的に起動して、着信メッセージを探すスレッドです。これに対し、リスナーは待機し、着信した外部メッセージによって起動されます。ポーラーの例としては、メッセージを定期的にチェックする必要がある受信ファイル アダプタがあります。リスナー アダプタの例としては、HTTP 応答が受信されるまで待機する Web サービス リスナー アダプタがあります。

– 発信アダプタ

送信アダプタは、サービス カタログ（Service Catalog）からの着信 XML メッセージを管理し、そのメッセージを設定済みの外部システムに送信します。「標準」の nsXML 発信メッセージが Service Link に送信されると、変換によってメッセージが変更され、外部システムに転送できるメッセージの形式になります。その後、送信アダプタは、正しいプロトコルおよびロジックを適用して、メッセージを外部システムに送信します。

• エージェント

エージェントは、サービス カタログ（Service Catalog）が他社製システムとの間で双方向の通信を行うためのトランスポート メカニズムを論理的に表現する用語です。エージェントは、サービス設計者がタスクを適切な他社の宛先に送信するために使用できます。タスクに加えて、このアクションを外部システムに送信するエージェントを指定することにより、承認や確認を外部で行うことができるようになります。

エージェントは、着信アダプタおよび発信アダプタ、オプションのメッセージ変換（XSLT）コンポーネント、オプション パラメータ、エラー状態を解決するためのその他の設定で構成されます。

• 変換

XML スタイルシート（XSL）変換により、送信メッセージは他社製システムが理解できる形式に変換され、着信メッセージはサービス カタログ（Service Catalog）が理解できる形式に変換されます。

発信アダプタが含まれるエージェントは、現在の要求およびタスクに関連する情報が含まれる nsXML メッセージを自動的に作成します。エージェントに関連付けられた変換では、メッセージを外部メッセージに変換でき、その外部メッセージはエージェントに対して設定された発信アダプタを介して外部システムに配信されます。同様に、受信エージェントは、関連付けられたアダプタを介して外部メッセージを受信します。変換では、サービス カタログ（Service Catalog）のワークフロー マネージャ Business Engine によって認識および処理される着信メッセージ タイプにメッセージを変換する必要があります。

• ディクショナリとアクティブ フォーム コンポーネント

ディクショナリは、特定のサービス要求を処理するために必要なデータ フィールドを保持するサービス デザイン コンポーネントです。ディクショナリ フィールド（またはサービス要求で使用できるその他のデータ）にマッピングされたエージェント パラメータにより、外部システムが容易に理解できる標準の送信メッセージ形式になります。外部システムから受信した着信メッセージのエージェント パラメータは、Service Link に、これらのパラメータにマッピングされたディクショナリ フィールドの値を更新するように指示します。変更されたフォーム データは、サービス フォームですぐに使用できます。また、ディクショナリが含まれるアクティブ フォーム コンポーネントは、Service Link 統合を実装するサービスに含まれている必要があります。

必要に応じ、newscale.properties ファイルの serviceform.simtask.validation.skip プロパティを true に設定すると、検証チェックをバイパスし、1 または複数のサービス項目ベースのディクショナリを含むアクティブ フォーム コンポーネントの削除を防ぐことができます。

[統合（Integration）] ウィザードを使用すると、エージェントと変換、およびエージェントの設定を完了するための統合ディクショナリとアクティブ フォーム コンポーネントが自動的に作成されます。これらのコンポーネントが作成されると、Service Link および Service Designer によって維持されるようになります。

Business Engine および nsXML と Service Link の相互作用

Service Link を理解するうえで重要なことは、Business Engine との相互動作を理解することです。Business Engine は、すべてのワークフローを処理するコンポーネントです。ワークフロー アクションには、次のものがあります。

• 正しい順序で配信計画のタスクを開始する。
• 完了のすべての要件を満たしている場合に、タスクを完了とマークする。
• イベントのトリガーが発生したときに、設定されたとおりに電子メールを送信する。

ServiceLink を使用しない（つまり、すべてのタスクがサービス カタログ（Service Catalog）の内部に存在する）タスク プランでは、BusinessEngine の動作はほとんど見えません。Business Engine の使用は Service Link 内部で認識されます。これは、外部タスクのステータスを変更するために、Business Engine が理解できるメッセージを Service Link が処理または生成する必要があるためです。

Business Engine は外部タスク（Service Link で処理されるタスク）を開始するときに、発信 nsXML メッセージを生成します。発信タスクを処理する Service Link エージェントは、ターゲット システムが理解できる形式に nsXML メッセージを変換し、エージェントで指定された発信転送メカニズム（アダプタ）を使ってターゲット システムに配信します。

同様に、Service Link が外部システムからの着信メッセージを受信するように設定されている場合、そのメッセージを Business Engine が理解できる着信 nsXML メッセージに変換する必要があります。受信メッセージを使用して、現在の要求に対するサービス フォーム データのアップデートや、現在のタスクの完了、現在の要求へのユーザ コメントの追加が行えます。

有効な nsXML メッセージについては、この後で詳細に説明します。

Service Link へのアクセス

Service Link にアクセスするには、[モジュール（Module）] メニューから [Service Link] を選択します。Service Link ホームページが表示されます。

Service Link のホームページには、次の Service Link ホーム ページの要素 に示す要素が含まれます。

通信プロトコルの設計

Service Link で実行される設定およびテスト作業に加えて、同等の作業が他社製システムを担当する技術リソースによって実行される必要があります。インターフェイスが堅牢に動作するためには、熟慮された設計が必須です。

通常は、通信相手となるシステムのインターフェイス機能によって、統合の基本設計、つまり使用されるアダプタが決まります。

ファイル アダプタやデータベース アダプタは最も簡単に設計できます。JMS、MQ、または http/Web サービス アダプタを展開した場合は、接続の問題がシステム間のデータの移動を妨げないように、ネットワーク管理チームの専門知識が盛り込まれることがあります。ターゲット システムが企業のネットワーク外に存在している場合は、データ セキュリティの懸念も要因となります。たとえば、外部ベンダーとの通信に http または https で送信される SOAP メッセージを使用する場合です。

通常、発信 Service Link 通信に必要なデータを最初に評価します。（nsXML 送信メッセージを通じて）どのフィールドがすぐに使用でき、（フォーム データおよびエージェント パラメータを通じて）どの追加データを提供する必要があるのかを考慮する必要があります。送信通信はタスクごと（タスクの開始時）にのみ発生しますが、複数の独立した着信通信をサポートできます。作業の実行命令を受信すると、他社製システムは、完了時に単一の（着信）通信を発行する可能性があります。また、作業が完了する前に、複数のアップデートが送信されることも考えられます。たとえば、参照 ID を伝達する場合には、テキストのステータス アップデート返信する必要があり、最後に完了確認が伝達されます。Service Link アダプタの管理

アダプタの管理

Service Link のアダプタは、事前構成されます。追加のアダプタは、Adapter Development Kit を使用して開発できます。Service Link の [統合の管理（Manage Integrations）] タブの [アダプタ（Adapters）] ページを使用して、使用可能なアダプタを確認できます。

手順 1 Service Link ホームページで [統合の管理（Manage Integrations）] をクリックします。次に、[アダプタ（Adapters）] サブタブをクリックします。

[アダプタ（Adapters）] ページが表示されます。

手順 2 [名前（Name）] カラムで、目的のアダプタをクリックします。

選択したアダプタの [アダプタの管理（Manage Adapter）] ページが表示されます。データベース アダプタの詳細は次のとおりです。

図 5-1 [アダプタの管理（Manage Adapter）] ページ

これらの一般的なプロパティの大半は、通常、Service Link 開発者が変更すべきではありません。[Polling Interval]、[Retry interval]、および [Maximum Attempts] は、要件に応じて変更する必要があります。すべての変更は、このアダプタ タイプを使用するすべてのエージェントによって継承されます。

追加の受信プロパティおよび送信プロパティは、アダプタをエージェントで使用する場合に指定します。これらのプロパティについては、Service Link アダプタの管理で説明します。

エージェントの管理

エージェント ウィザードを使用すると、エージェントの設定手順を、順を追って実行できます。このウィザードは 8 ページで構成されますが、前のページで選択したオプションによって一部のページがスキップされる場合があります。

エージェント ウィザードのページの概要は、次の エージェント ウィザード ページの表 のとおりです。

エージェントを管理するには:

手順 1 Service Link ホームページの、[共通タスク（Common Tasks）] 領域で [エージェント（Agent）] をクリックするか、 [統合の管理（Manage Integrations）] > [エージェント（Agents）] > [エージェント（Agent）] を選択します。

エージェント ウィザードの [一般情報（General Information）] ページが表示されます。これは、このウィザードを構成する 8 ページのうちの最初のページです。特定のエージェント設定には関係のないページは、スキップできます。

図 5-2 [一般情報（General Information）] ページ

次の エージェントの作成：一般属性の表 で説明するフィールドに値を入力し、[Next] をクリックします。

失敗した電子メール（Failed Email）

Failed Email による通知は、送信メッセージを配信できない場合に生成できます。Service Link の失敗した電子メールには、すべてのタスク関連電子メールに使用できる標準の名前空間セットに加えて、障害時に生成されるメッセージに関する詳細を含めることができます。これらの名前空間を電子メール テンプレートに含めると、問題の診断時に役立てられます。使用可能な名前空間の詳細については、『 Cisco Prime Service Catalog Designer Guide 』を参照してください。

Failed Email は着信メッセージに適用されません。Service Link が着信メッセージの処理に失敗した場合、通知は生成されません。

送信メッセージの内容

発信アダプタは、サービス カタログ（Service Catalog）データベースに保存される nsXML メッセージを生成します。その後、このメッセージは変換され、指定したアダプタを介して、結果としての外部メッセージが任意の宛先に配信されます。

メッセージのフォーマットは ISEE.war/WEB-INF/classes/nsxml.xsd のアプリケーション サーバ上の対応する XML スキーマごとに、 Adapter Development Kit による統合の設計 に記載されています。完了メッセージには、サービス要求に関するすべての情報が含まれます。このようなメッセージはサイズが非常に大きくなる可能性があり（サービスで使用されるディクショナリやフィールドの数に応じて、500 K を超えることがよくあります）、結果的にデータベース内で大量のストレージを消費し、生成するために CPU の使用率も非常に高くなります。

リソースの消費量を削減するため、サービス カタログ（Service Catalog）には次のオプションが用意されています。

• [管理（Administration）] 設定を [メッセージの圧縮（Compress messages）] に設定すると、データベースに格納されている Service Link メッセージを圧縮できます。これにより、ストレージ要件が大幅に軽減されますが、DBA または担当者がメッセージを判読できなくなるため、トラブルシューティングが複雑になる可能性があります。
• Service Link Message Purge スクリプトが使用可能です。このスクリプトにより、完了済みのタスクのメッセージをトランザクション データベースから削除できます。その結果、データベース内のメッセージのストレージ要件が軽減されます。Message Purge スクリプトの使用に関する詳細については、Service Link のトラブルシューティングと管理を参照してください。
• 「Outgoing message content」プロパティを操作すると、nsXML メッセージの選択したノードだけを含めるように発信内容を設定できます。これにより、送信メッセージを処理するためのメモリ要件および CPU 要件が軽減されます。

デフォルトのメッセージ内容は「Data and parameters; no Service Details (small)」で、要求されたサービスを説明するコンテンツ ノードが含まれない nsXML メッセージが生成されます。エージェント パラメータおよび変換は、発信内容のタイプを考慮して設計する必要があります。要求されるすべての内容が nsXML メッセージに含まれていることを確認してください。特に、送信メッセージからディクショナリ データを排除する場合は、エージェント パラメータを適切なフォーム フィールド（または定数）にマッピングする必要があります。外部タスクに必要のない多数のフォーム フィールドがサービスに含まれる場合は、XML サイズの削減および関連する CPU 使用率の削減が非常に重要です。

発信内容のオプションの概要については、次の 発信メッセージの内容：オプションの表 を参照してください。

アダプタの選択

エージェントは、送信通信と着信通信の両方、送信通信のみ、または着信通信のみを管理するように設定できます。方向ごとに異なるアダプタ タイプを使用できます。たとえば、データベース アダプタは送信データを書き込むために使用できますが、システムは、受信ファイル アダプタによって読み取られるディレクトリにファイルを書き込むことによって応答します。

アダプタ タイプを選択すると、ウィザードの後続のページは、アダプタ タイプおよび使用方法（送信または受信）に関するプロパティを表示するように調整されます。プロパティ値は、エージェント定義の一部として指定する必要があります。

エージェント ウィザードの [エンドポイント（End Points）] ページ（ページ 2/8）では、エージェントで使用するアダプタ、および送信メッセージまたは着信メッセージに適用する変換を指定できます。変換は、[統合の管理（Manage Integrations）] オプションの [変換（Transformation）] サブタブを使用して、事前に定義しておく必要があります。

図 5-3 エージェント ウィザードの [エンドポイント（End Points）] ページ

各タイプのアダプタに適用できるプロパティについては、この章で後述します。実際には、このウィザードの次に続く 2 ページ（送信アダプタおよび受信アダプタの構成専用）は、選択しているアダプタによって異なります。ここでは、ダミー アダプタと自動完了オプションという 2 つの特殊なケースについて説明します。

ダミー アダプタは、エージェント内に、送信アダプタまたは受信アダプタとして設定できます。ダミー アダプタを選択することは、エージェントが単一方向にのみ動作することを意味します。たとえば、ダミー受信アダプタを使用するように設定されているエージェントは、エージェントが送信通信だけに関与することを意味します。同様に、アップデート タスクおよび締め切りタスク専用の個別（受信のみ）エージェントが存在することも考えられます。

[Auto Complete] オプションは、エージェントの受信アダプタ部の選択肢としてのみ使用できます。その効果は「ダミー アダプタ」を選択することと同様で、エージェントは発信の通信だけを管理します。主な違いは、タスクに関連付けられた送信通信が送信されると、そのタスクは自動的に完了しますが、残りの提供計画は引き続き実行されることです。

エージェント パラメータの使用

エージェント パラメータは、送信アダプタおよび受信アダプタと組み合わせて使用できます。

エージェント定義の一部として指定したパラメータ マッピングには、デフォルト値が使用されます。このマッピングは、Service Designer でサービスのタスク定義を編集することにより、サービスごとに上書きできます。

送信要求パラメータ

送信メッセージ内で使用されるエージェント パラメータは、追加データを含む標準 nsXML 送信メッセージを補足し、コンテンツ ノードを対応しやすい形式に整理するための方法を提供します。このパラメータには、外部メッセージに含めることができるように、XSL 変換を通じて簡単にアクセスできます。

図 5-4 送信要求パラメータ

パラメータ マッピングは、[サービスデータマッピング（Service Data Mapping）] 領域にマッピング元の要素を入力するか、パラメータ マッピング ペインの左にあるドロップダウン リストに表示されている要素を使用して式をビルドすることによって割り当てられます。マッピングは、次の組み合わせで構成できます。

• 定数値
• サービス フォーム上のディクショナリ フィールド
• nsXML 要素
• 上記のいずれかの要素に適用される事前作成済みの関数

エージェント パラメータをマッピングすると、次の利点があります。

• パラメータ値を抽出する変換では、値が入力されるディクショナリ フィールド名を参照する必要はありませんが、単にエージェント パラメータ名を参照することはできます。これにより、異なるサービスおよびディクショナリにわたるエージェントの再使用が促進されます。
• パラメータはすべてのコンテンツ タイプに含まれるため、メッセージで必要とされる他のすべてのコンテンツがサポートされる場合、サイズの小さい発信メッセージ コンテンツ タイプを使用できます。
• 変換を使用せずにはアクセスできない nsXML 要素および XPATH 操作を、外部メッセージに含めることができます。

送信パラメータを作成するには、次の手順を実行します。

手順 1 [送信要求パラメータ（Outbound Request Parameters）] ページで、[パラメータの追加（Add Mapping）] をクリックします。

ページの下部に [パラメータ値の編集（Edit Parameter Values）] ダイアログ ボックスが表示されます。

手順 2 パラメータの名前を入力します。

パラメータ名にはスペースを使用できますが、XML メッセージで意味を持つ特殊文字（「>」や「&」など）は使用できません。

手順 3 以下に示すガイドラインを使用して、パラメータの値/マッピングを指定します。

定数値

場合によっては、要求またはサービスの詳細に依存しない定数値を外部システムに渡す必要があります。たとえば、外部システムのマッピング元の名前を指定する必要がある場合は、[サービスデータマッピング（Service Data Mapping）] に「サービス カタログ（Service Catalog）」とだけ入力します（かぎカッコは入力しません）。

送信 nsXML へのマッピング

標準の nsXML 発信メッセージの選択された要素を、エージェント パラメータへのマッピングに使用できます。次の表は、これをまとめたものです。

[辞書（Dictionary）] フィールドへのエージェント パラメータのマッピング

エージェント パラメータをディクショナリ フィールドにマッピングするには、次の手順を実行します。

手順 1 [辞書（Dictionaries）] ノードを展開し、[辞書を選択（Select a dictionary）] オプションを表示します。

図 5-5 [辞書（Dictionary）] フィールドへのエージェント パラメータのマッピング

手順 2 すべての Service Catalog ディクショナリのリストを表示するには、[辞書を選択（Select a dictionary）] ドロップダウン メニューをクリックします。

図 5-6 ディクショナリ ドロップダウンの選択

手順 3 エージェント パラメータにマッピングするフィールドが含まれるディクショナリを選択します。ディクショナリ内のすべてのフィールドのリストが表示されます。

図 5-7 ディクショナリのフィールド

手順 4 エージェント パラメータにマッピングするフィールドをクリックし、[サービスデータマッピング（Service Data Mapping）] テキスト領域にドラッグします。ドラッグ アイコンが緑色のチェック マークに変化したら、マウスを放します。選択したフィールドの lightweight 名前空間が表示されます。

図 5-8 Lightweight 名前空間

グリッド ディクショナリを除き、エージェントはサービスに関係なく定義されるため、任意のディクショナリ フィールドを選択できます。このエージェントが使用されているサービスに、実際に、参照先のディクショナリが含まれることを確認するのは、サービス設計者の役割です。

1 つ以上のグリッド ディクショナリのコンテンツを渡す統合の場合、各グリッド ディクショナリの行を扱うために変換が必要です。これは、それらの行が複数のディクショナリ インスタンスとして保存されているからです。この変換は、発信 nsXML の <data-values> セクションで、「DictionaryName-n」の命名規則に従います。n はグリッド行番号です。たとえば、VMOperation という名前のグリッド ディクショナリで、サービス要求に 2 行のデータがある場合、その値は次のように表現されます。

着信エージェント パラメータ マッピングおよびグリッド ディクショナリ フィールドの更新はサポートされません。

ビルド済み関数の適用

ビルド済み関数はマッピングされた要素に適用できるため、パラメータ値は、対象システムで予期された意味または書式設定要件に適合します。たとえば、対象システム内のフィールドのデータ定義に含まれる文字数がサービス カタログ（Service Catalog）に保持されている文字数よりも少ない場合は、substring 関数を適用することによってフィールドを短縮できます。ビルド済み関数の概要は以下のとおりです。詳細については事前作成済み関数で説明します。

ビルド済み関数をエージェント パラメータに適用するには、次の手順を実行します。

手順 1 関数名が表示されるように、ビルド済み関数を展開します。

手順 2 使用する関数を強調表示します。ペインの下部に、関数の使用法を説明する [Help] が表示されます。

図 5-9 ビルド済み関数

手順 3 この関数を、パラメータの [Service Data Mapping] ボックスにドラッグします。ドラッグ アイコンが緑色のチェック マークに変化したら、マウスを放します。

図 5-10 緑色のチェック マーク

手順 4 $Parameter$ を実際の値のプレースホルダとして、関数が定義されます。

図 5-11 定義済み関数

手順 5 プレースホルダを、使用する nsXML メッセージのディクショナリ フィールドまたは要素と置換します。このフィールドまたは nsXML 要素を [Service Data Mapping] テキスト ボックスにドラッグし、パラメータ定義を手動で編集する必要があります。

図 5-12 パラメータ値の編集

送信 nsXML へのエージェント パラメータの追加

エージェント パラメータは、送信 nsXML メッセージの末尾に追加されます。たとえば、以下に示すエージェント パラメータは、直後に nsXML スニペットを生成します。

図 5-13 sXML スニペット

送信応答パラメータ

送信応答パラメータは、送信 http/Web サービスアダプタと組み合わせて使用できます。アダプタの [プロセス応答（Process Response）] 設定が true の場合、元の要求への応答が処理されます。この応答には、「送信パラメータ」メッセージ タイプが含まれる可能性があります。パラメータは、受信エージェント パラメータとして定義します。

受信エージェント パラメータ

エージェント パラメータを「送信パラメータ」受信メッセージ タイプと組み合わせて使用すると、そのパラメータがマッピングされているディクショナリ フィールドを外部タスクでアップデートできます。

変換の管理

変換を管理するには:

手順 1 [統合の管理（Manage Integrations）] タブで、[変換（Transformations）] サブタブをクリックします。

手順 2 [変換（Transformation）] をクリックします。

[変換（Transformation）] ページが表示されます。

[Direction] を指定することにより、変換を送信/受信メッセージのいずれかに適用できます。[Process Response] 設定がオンになっている場合、Web サービス発信メッセージに 2 つの変換の使用が必要になる場合があります。1 つは発信要求に適用され、もう 1 つはその要求への応答に適用されます。

[Validate] ボタンをクリックすると、XSLT を解析して、変換が整形式であることが確認されます。適切でない（たとえば、XML タグのつづりの誤りや欠落がある）場合は、診断メッセージが表示されます。変換を保存する前に、エラーを修正する必要があります。

ただし、Service Link では、変換の検証は行われません。たとえば、ソース メッセージに存在しない要素を変換が参照していても、エラーは検出されません。その場合、整形式 XML メッセージが生成されますが、対象システムに対して有効ではありません。したがって、Service Link がターゲット アプリケーションで認識できない外部メッセージ、または Business Engine で認識できない着信メッセージを生成した場合は、ランタイム エラーが生成されます。

XML 開発環境にアクセスしている場合、使用方法に精通していれば、その環境を使用して変換のテストを行うと効率的です。送信変換の場合は、（変換を適用する前に）エージェントによって作成された nsXML を XML 開発環境にコピーし、それをソース XML として使用するだけです。変換を検証した後、XSLT コードを Service Link 変換にコピーして貼り付け、適切なエージェントに関連付けます。

または、特に既存の変換に小さな変更を加える場合には、このページのテスト関数を使用すれば、変換の出力 XML を素早くプレビューできます。[テスト（Test）] ボタンをクリックするとポップアップ ウィンドウが表示されるので、そこで nsXML をソース XML パネルに貼り付け、変換を実行して出力 XML を取得できます。

Integration ウィザードを使用して開発された送信 Web サービス統合の場合、手動での変換の開発およびデバッグ プロセスは排除されます。Web サービス用の変換が自動的に作成され、これにより、発信 nsXML が、指定された WSDL と互換性のある形式に変換されます。ただし、wsdl または統合要件が変更された場合は、前述の手順に従って変換をアップデートする必要があります。

手順 3 次の 変換設定の表 で説明するフィールドに値を入力します。

手順 4 [Validate] をクリックして、変換に整形式 XSL が含まれることを確認します。

手順 5 [保存（Save）] をクリックします。

エージェント定義とプロパティ シートの確認

エージェントが Service Link または Integration ウィザードのどちらで作成された場合でも、すべてのエージェントの定義を確認または変更できます。[統合の管理（Manage Integrations）] タブの [エージェント（Agents）] サブタブが表示されたら、次のいずれかを実行できます。

• ページの左側にあるリスト ペインで、エージェント名をクリックします。
• ページの右側に一覧表示されたエージェント情報をスクロールし、エージェント名をクリックします。

リスト ペインのエージェント エントリが展開されます。編集または確認するエージェント定義の部分のプロパティ シートをクリックします。プロパティ シートが表示されたら、変更を入力し、[保存（Save）] をクリックして保存します。

図 5-14 エージェント エントリ

エージェント名をクリックすると、エージェント定義の概要が表示されます。

図 5-15 エージェント情報（Agent Information）

[エージェントパラメータのリセット（Reset Agent Parameters）] ボタンを除いて、このページは読み取り専用です。

Service Link エージェントの作成と導入

次の手順では、ファイル アダプタを使用する Service Link の統合の導入に必要なタスクの一般的なシーケンスを示します。これは Service Link のインストールの検証にも使用できます。

手順 1 Service Link ホーム ページの [共通タスク（Common Tasks）] 領域から、エージェント ウィザードをクリックし、場所フィールドに入力して他の送信アダプタのプロパティを指定することにより、送信ファイル アダプタを使用するエージェントを選択します。（このようなプロパティの詳細については、ファイル アダプタで説明します）。

手順 2 [エージェントの管理（Control Agents）] タブに移動し、エージェントを見つけ、エージェント名（エージェント定義へのリンク）を除く境界線上の任意の場所でマウスをクリックし、ページの右上にある [選択項目の開始（Start Selected）] をクリックして、エージェントを起動します。起動したかどうかを確認します。起動しない場合は、Service Link コンフィギュレーション設定のいずれかが間違っているか、Integration Server（ISEE）が正しく起動していません。

手順 3 入力したファイル ディレクトリがアプリケーション サーバ上に存在することを確認し、存在しない場合は作成します。サービス カタログ（Service Catalog）と外部アプリケーションの両方に、これらのディレクトリへの適切なアクセス権（書き込み/読み取り）があることを確認します。これらの条件が満たされていない場合は、実行時にファイル転送が失敗します。

手順 4 [Service Designer] に移動し、このエージェントを使用するサービスを作成します。

手順 5 [My Services] に移動し、サービスをオーダーします。

手順 6 要求が正常に作成されていれば、ISEE 送信キューは動作しています。[our apologies] ページが表示された場合は、JMS キューが動作していません。

手順 7 [トランザクションの表示（View Transactions）] タブからアクセスできる [メッセージ（Messages）] ページに移動します。作成した要求からメッセージが表示されていれば成功です。メッセージのステータスが「Message sent」になっているはずです。

手順 8 発信ファイル ディレクトリ（C:\cisco\SL\OutboundFiles など）に移動します。ここに XML ファイルがある場合は（XML ファイルの日時スタンプを調べて、要求に対応する新しいファイルであることを確認してください）、ファイル エージェントの送信が完了しています。おめでとうございます。発信 XML ファイルは有効な nsXML メッセージになります。

手順 9 [メッセージタイプ（Message Type）] カラムの要求に対して、[タスクの実行（Execute Task）] リンクをクリックします。[Message Details] ページが表示されます。

手順 10 Requisition ID が正しいことを確認します。メッセージの詳細画面から「Channel ID」をコピーします。

手順 11 以下に示すように、SampleInbound.xml という名前の XML ファイルを作成します。「insert your Channel ID here」と表示されている場所に、前のステップでコピーした Channel ID の値を貼り付けます。（二重引用符はそのまま残しておきます）。

たとえば、Channel ID の値を貼り付けると、SampleInbound.xml ファイルは次のようになります。

手順 12 着信ファイル ディレクトリ（C:\cisco\SL\InboundFiles など）に SampleInbound.xml ファイルを配置します。

手順 13 ファイル エージェントが入力をポーリングすると、受信ファイルが自動的に選択されます。（ファイル アダプタのポーリング間隔時間のデフォルトの設定は 10 秒ごとです）。SampleInbound.xml ファイルは、正常に処理されるとディレクトリから削除されます。

手順 14 [トランザクションの表示（View Transactions）] タブの [メッセージ（Messages）] ページに移動し、要求を探します。Type=Take Action が含まれる要求に対する別のメッセージがあり、Status=Inbound Message Completed と表示されている場合は、往復が実行されたことを意味します。

手順 15 [要求 ID（Requisition ID）] リンクをクリックして、[要求ステータス（Requisition Status）] ページを開きます。要求のステータスが「Closed (1 of 1 completed)」になっていることを確認します。

Service Link エージェントを使用するタスクの設定

エージェントを定義すると、そのエージェントを呼び出すワークフローが含まれる外部タスクを作成することにより、サービスで使用できるようになります。ワークフローを設定したら、中に含まれるエージェントに定義されている任意のエージェント パラメータを確認したり、上書きしたりできます。

外部タスクの作成

Service Link エージェントを使用する外部（他社製）アプリケーションにタスクを送信するには、次の手順を実行します。

手順 1 Service Designer を起動します。外部タスクに含めるサービスを選択します。[計画（Plan）] タブをクリックします。

手順 2 外部タスクの指定には、[Tasks] サブタブまたは [Graphical Designer] サブタブを使用できます。

• サービスの [Tasks] サブタブを使用して、タスクを定義し、配信計画に正しいシーケンスで配置します。
• [Graphical Designer] サブタブを使用して、図上にタスクを作成し、Associate ツールを使用して、図に正しいシーケンスで配置します。そのタスクをダブルクリックして、プロパティ シートを表示します。

手順 3 [General] タブの [Workflow Type] ドロップダウン リストを使用して、ドロップダウン リストから目的のアクションを選択します。これは Service Link モジュール定義済みのアクションであり、このドロップダウン リストに一覧表示されるエージェント名ではないことに注意してください。

手順 4 ワークフロー/タスク プランを保存します。Workflow Designer を使用した場合は、[Tasks] サブタブに戻ります。

手順 5 外部タスクを保存すると、[Workflow Type] の横に省略符号ボタンが表示されるようになります。この省略記号をクリックすることにより、現在エージェントに有効なパラメータ マッピングを確認したり（存在する場合）、この特定のサービスのマッピングを変更したりできます。 省略符号 ボタンをクリックします。

図 5-16 ワークフロー タイプの横にある省略符号ボタン

手順 6 [エージェントパラメータのオーバーライド（Agent Parameter Override）] ポップアップ ウィンドウが表示されます。エージェント パラメータを確認します。または、1 つ以上のパラメータのマッピングを変更します。各パラメータを変更するたびに [適用（Apply）] をクリックし、ウィンドウを閉じる前に [保存（Save）] をクリックしてください。

図 5-17 エージェント パラメータのオーバーライド

手順 7 [参加者（Participants）] タブで、パフォーマー（個人、キュー、または役職）を定義することもできます。これにより、その実行エンティティのカレンダーを使用してタスクの実行期日が計算されます。外部タスクの [参加者（Participants）] タブで値を設定していない場合は、デフォルト サービス キューのカレンダーを使用して実行期日が計算されます。この方法でプランに実行期日を設定すると、サービス カタログ（Service Catalog）で、外部タスクの提供動作レベル契約（OLA）の順守、および当該タスクを含むサービスのサービス レベル契約（SLA）の順守を計算できます。

エージェント マッピングとサービス定義の同期

エージェントを使用するタスクを作成して保存すると、そのエージェントに指定されているエージェント パラメータ マッピングが個々のタスクに自動的に継承されます。前述のように、サービス設計者は、すべてのエージェント マッピングをタスク レベルで上書きできます。

ただし、後で異なるエージェント パラメータ マッピング セットが含まれるようにエージェントを変更すると、そのエージェントを使用するように事前に定義されているタスクは、変更を自動的に継承しません。これには、次のような変更が含まれます。

• エージェント パラメータの追加
• エージェント パラメータの削除
• 既存のエージェント パラメータのマッピングの変更

エージェントを使用するサービスにこれらの変更を伝播するには、次の手順に従います。

手順 1 [Service Link Manage Integrations] タブの [Agents] サブタブをクリックします。

手順 2 パラメータ マッピングが変更されたエージェントの名前をクリックします。

[エージェント情報（Agent Information）] ページが表示されます。

図 5-18 [エージェント情報（Agent Information）] ページ

手順 3 エージェント パラメータ マッピングをアップデートされたエージェント定義と再同期する必要があるサービスを選択します。

手順 4 [選択されたタスクのリセット（Reset Selected Tasks）] をクリックします。このボタンはすべてのパラメータ マッピングをエージェントのデフォルトにリセットするため、タスク固有のすべてのマッピングを再適用する必要があります。

nsXML メッセージ

変換には正しい形式の XML を含める必要があるだけではなく、正しい形式の有効な nsXML メッセージを生成する必要があります。すべての nsXML メッセージが nsXML スキーマ（XML 文書の構造を記述する XML 文書）に従っている必要があります。このスキーマは、アプリケーション サーバ（ISEE.war/WEB-INF/classes/xsl/nsxml.xsd）で使用できます。

発信 nsXML メッセージ

外部タスクのステータスが Ongoing に変わると、発信 nsXML メッセージが生成されます。

各メッセージに生成された nsXML は、[Message Details] ページで nsXML メッセージをクリックすると、Service Link モジュールに表示できます。タスクに関連するデータおよび親要求に関連付けられているデータが表示されます。

nsXML において最も重要な要素は channel-id です。これは、外部タスクを一意に識別する ID です。この ID は他社製システムに提供され、対応するデータ アップデートがビジネス エンジンによって正常に適用されるためには、応答に表示される必要があります。

channel-id は、Globally Unique Identifier（GUID）として書式設定されます。GUID は、通常、次のような 16 進数のシーケンスとして、テキスト形式で書き込まれます。

このテキスト表記は、ハイフンで区切られた 5 つのデータ セットで構成されます。GUID の合計長は 36 文字（32 の文字と 4 つのハイフン）です。

2 つの送信メッセージ タイプがあります。

task-started

task-started メッセージ タイプは、外部タスクが開始されると生成されます。task-started メッセージの要素の詳細については、 Adapter Development Kit による統合の設計 を参照してください。

task-canceled

task-canceled メッセージ タイプは、外部タスクが含まれる要求が取り消されると生成されます。（サービスの配信計画の対応する設定から）外部タスクが実行された後、ユーザが要求のキャンセルを許可されていない場合、このメッセージは生成されません。しかし、要求の取り消しが許可されている場合は、外部タスクに関与エージェント内で使用されている変換によって task-started メッセージと task-canceled メッセージの両方が「スマートに」処理される必要があります。変換によって task-canceled メッセージ タイプをテストし、適切なメッセージを外部システムに送信する必要もあります。

着信 nsXML メッセージ

他社製システムの要求操作およびサービス項目操作からの着信メッセージについては、2 種類の操作がサポートされています。要求操作は、要求データおよびタスク ステータスの更新に使用されます。サービス項目操作は、要求に関連付けられたサービス項目の追加、変更、削除および取得に使用されます。特定の操作は「複合メッセージ」と呼ばれる 1 個の着信メッセージに統合されることがあります。各操作の詳細および制約事項は次の項で説明します。

要求操作

他社製システムは、対応する発信メッセージの channel-id を参照して、外部タスク用に 1 つ以上の着信メッセージを送信できます。外部タスクは処理操作の 1 つが送信されると完了し、これによって許可/配信計画の次のタスクが進行します。

take-action

take-action メッセージは、タスクのステータスを変更するために、承認または提供タスクに適用できます。take-action タグの action 属性は、実行されるアクションを識別します。有効なアクションの概要は次の take-action メッセージの表 のとおりです。

タスク プランの最後の提供タスクが done とマーキングされている場合は、要求が閉じられます（完了します）。take-action タグの「アクション」属性を対応する値に設定すると、許可タスクを Approved または Rejected とマークできます。

send-parameters

パラメータは、エージェント定義内のディクショナリ フィールドにバインドされたデータ要素です。send-parameters メッセージ タイプを使用すると、指定した 1 つ以上のパラメータがアップデートされ、続いてサービス内の対応するディクショナリ フィールドがアップデートされます。このタイプの着信メッセージの使用は、サービス要求で使用されるディクショナリ フィールドを外部システムで更新する推奨方法です。

add-comments

add-comments メッセージは、要求の [System Comments] セクションにコメントを追加するために使用します。

サービス項目操作

サービス項目は Service Item Manager で定義されるエンティティです。そのライフサイクルは、サービス項目インスタンスがプロビジョニングされた時点から、廃棄される時点までで、サービス要求に関連付けられます。サービス項目のライフサイクル イベントが外部システムによって処理される場合、Service Link サービス項目、更新、削除、および取得のメッセージを介して、サービス項目データを Lifecycle Center と同期できます。これらのメッセージ タイプは、Web サービスベースのサービス項目リスナー アダプタだけでサポートされます（サービス項目リスナー アダプタを参照）。

これらのメッセージには、1 つまたは複数のサービス項目タイプおよびサービス項目インタンスを含めることができます。1 つのメッセージに複数のサービス項目操作を組み合わせることはできません。言い換えると、操作の作成、更新、または削除は個別の着信メッセージで送信する必要があります。エラー状態が発生すると、同じメッセージのすべてのサービス項目の操作がロール バックされます。

日時タイプのサービス項目属性は、YYYY-MM-DD HH:MI:SS または YYYY-MM-DD の形式で指定する必要があります。すべての時刻は UTC 時間で保存されます。

サービス項目のサブスクリプションは、サービス項目インスタンスの作成時にオプションで含めることができます。操作でサブスクリプション情報が提供されていないと、要求のカスタマーとその個人のホーム組織単位に項目が割り当てられます。メッセージのサブスクリプション セクションにカスタマーのログイン ID または組織単位名が指定されている場合、これらの値はデフォルトのサービス項目の割り当てを上書きするために使用されます。サブスクリプションの処理規則の詳細については、『 Cisco Prime サービス カタログ（Service Catalog） Designer Guide 』の「Service Designer」の章を参照してください。

update

更新メッセージでは、サービス項目属性を省略すると、属性値は変更されません。メッセージで属性が明示的に指定されているものの、値が含まれない場合、そのサービス項目の属性値はテキスト フィールドでは空白に設定され、数値フィールドでは 0 に設定されます。

削除

delete サービス項目要求に必要なのは、サービス項目タイプおよびインスタンスの名前だけです。その他のサービス項目の属性およびサブスクリプション情報は無視されます。

getRequest

getRequest 操作はサービス項目インスタンスを取得するために使用されます。update および delete サービス項目要求と異なり、channel-id と topic-id 属性は任意選択です。各着信メッセージには getRequest 操作を 1 つだけ含めることができ、その中にサービス項目タイプを 1 つだけ含めることができます。Service Link ユーザ インターフェイスのような要求のロギングは行われません。

サービス項目属性とサブスクリプション データ（お客様のログイン ID、組織単位名、アカウント ID、および契約）を使用して、要求 XML で指定した検索フィルタに従って、サービス項目インスタンスが取得されます。getRequest では最高 5 個のフィルタを使用でき、これらは AND 結合と解釈されます。次の getRequest の検索フィルタ演算子の表 に、検索フィルタでサポートされる演算子を示します。

getRequest からの応答データにはサービス項目の属性名と値、およびサブスクリプション情報が含まれます。それぞれの getRequest 操作で返されるレコードの最大数は 100 です。次のレコード セットは、要求で「startRow」および「count」要素を指定することによって取得できます。startRow 要素は結果セットの開始行番号を示します。count 要素は返されるレコード数を示します。「startRow」および「count」のデフォルト値はそれぞれ 1 と 100 です（要求 XML にない場合）。count の値は、パフォーマンス上の理由から 100 に制限されています。

以下は getRequest XML の例です。

上記の要求の応答

getDefinitionRequest

getDefinitionRequest 操作はサービス項目タイプのメタデータまたは定義を取得するために使用されます。getRequest 操作同様、channel-id と topic-id 属性は任意選択です。各着信メッセージには getRequestDefinition 操作を 1 つだけ含めることができ、その中にサービス項目タイプを 1 つだけ含めることができます。Service Link ユーザ インターフェイスのような要求のロギングは行われません。

以下はサービス項目の getDefinitionRequest の例です。

上記の要求の応答

複合メッセージ

上記のメッセージ タイプは、単一の受信メッセージに組み合わせることができます。このような組み合わせは、「複合」メッセージと呼ばれます。実行順序が重要です。take-action タグを含める前に、パラメータの送信やコメントの追加を実行し、最後にサービス項目操作タグを配置する必要があります。

SIM インポート メッセージ

Service Item Manager（SIM）インポート メッセージ タイプは、外部システムからサービス カタログ（Service Catalog）へのサービス項目と標準定義およびデータをサポートしています。サービス項目の更新および削除の操作とは異なり、SIM のインポートは、特定のディレクトリに配置された着信ファイルをポーリングする File Adapter プロトコルに基づいています。サービス項目インスタンスの操作に加えて、SIM Import ではサービス項目グループおよびサービス項目タイプのメンテナンスもサポートされます。Service Item Manager のインポートの詳細については、『 Cisco Prime サービス カタログ（Service Catalog） Designer Guide 』を参照してください。

着信 JSON メッセージ

12.0.1 リリース以降、Prime Service Catalog は FTL 変換を使用した JSON 着信メッセージをサポートしています。JSON インバウンド メッセージは、ファイル アダプタおよび HTTP/WS アダプタでのみサポートされます。これを実現するには、カスタム JSON を nsXML にマッピングする FTL 変換を記述します。FTL 変換の記述の詳細については、 http://freemarker.org/ を参照してください。

HTTP/WS アダプタおよびファイル アダプタの詳細については、HTTP/WS アダプタとファイル アダプタを参照してください。

HTTP/WS アダプタとファイル アダプタを使用する要求で実行できるオペレーションは、次のとおりです。

• コメントを追加（Add Comments）
• パラメータを追加（Adding Parameters）
• 値を更新（Updating Values）
• 提供タスクの完了（Completing Delivery Task）
• レビュー タスク（Review Task）
• タスクを承認（Approve Task）
• タスクを否認（Reject Task）

各オペレーションについては、次で詳しく説明します。

add-comments

add-comments メッセージは、要求の [System Comments] セクションにコメントを追加するために使用します。

JSON ペイロードの例

{

"key":"CF04ECC6-1868-4D7B-9C83-463054C27453",

"message":"Adding comment to requisition”,

}

対応する変換の例

<?xml version="1.0" encoding="UTF-8"?>

<message channel-id="${root.key}">

<add-comments>

<comment>${root.message}</comment>

</add-comments>

それぞれの説明は次のとおりです。

• ${root} は、受信される JSON 文字列の org.json.JSONObject を表します。
• ${root.key} は、JSON ペイロードの channel-id/key 属性に対応します。
• ${root.message} は、要求に追加されるメッセージ属性に対応します。

add-parameters

パラメータは、エージェント定義内のディクショナリ フィールドにバインドされたデータ要素です。add-parameters メッセージ タイプを使用すると、指定した 1 つ以上のパラメータが追加され、続いてサービス内の対応するディクショナリ フィールドが追加されます。このタイプの着信メッセージの使用は、サービス要求で使用されるディクショナリ フィールドを外部システムで更新する推奨方法です。

JSON ペイロードの例

{

"key":"150A3FB7-5E2B-486B-8288-D197506A9762",

"param":"Param1",

"value":29

}

対応する変換の例

<?xml version="1.0" encoding="UTF-8"?>

<message channel-id="${root.key}">

<send-parameters>

<agent-parameter>

<name>${root.param}</name>

<value>${root.value}</value>

</agent-parameter>

</send-parameters>

</message>

それぞれの説明は次のとおりです。

• ${root} は、受信される文字列の org.json.JSONObject を表します。
• ${root.key} は、JSON ペイロードの channel-id/key 属性に対応します。
• ${root.param} は、パラメータ属性に対応します。
• ${root.value} は、追加されるパラメータの値です。

update-values

update-value メッセージ タイプでは、指定した 1 つ以上のパラメータを新しい値に更新できます。

JSON ペイロードの例

{

"key":"150A3FB7-5E2B-486B-8288-D197506A9762",

"param":"D.Age",

"value":65

}

対応する変換の例

<?xml version="1.0" encoding="UTF-8"?>

<message channel-id="${root.key}">

<update-data>

<data-value multi-valued="false">

<name>${root.param}</name>

<value>${root.value}</value>

</data-value>

</update-data>

</message>

それぞれの説明は次のとおりです。

• ${root} は、受信される文字列の org.json.JSONObject を表します。
• ${root.key} は、JSON ペイロードの channel-id/key 属性に対応します。
• ${root.param} は、パラメータ属性に対応します。
• ${root.value} は、追加されるパラメータの値です。

update-multiple-values

update-value message type メッセージ タイプでは、指定した複数のパラメータを新しい値に更新できます。

JSON ペイロードの例

対応する変換の例

take-action

take-action メッセージは、タスクのステータスを変更するために、承認または提供タスクに適用できます。take-action タグの action 属性は、実行されるアクションを識別します。有効なアクションの概要は次の表のとおりです。

タスク プランの最後の提供タスクが done とマーキングされている場合は、要求が閉じられます（完了します）。take-action タグの「アクション」属性を対応する値に設定すると、許可タスクを Approved または Rejected とマークできます。

JSON ペイロードの例

{

"key":"19E2A5E6-40EA-43AC-9D73-5FDEFF8C28FB",

"action":”ok”, "action":”approve”, "action":”reject

}

対応する変換の例

<?xml version="1.0" encoding="UTF-8"?>

<message channel-id="${root.key}">

<take-action action="${root.action}">

</take-action>

</message>

それぞれの説明は次のとおりです。

• ${root} は、受信される文字列の org.json.JSONObject を表します。
• ${root.key} は、JSON ペイロードの channel-id/key 属性に対応します。
• ${root.action} は、タスクのタイプです。

変換と nsXML

発信 nsXML メッセージは通常、非常にサイズが大きく複雑で、500 KB を超えることもよくあります。変換を使用してメッセージ形式を変更することは必須ではありませんが、外部システムが nsXML を読み取るように設定されていることはまずありません。結果として、通常、変換を使用して送信メッセージ形式を変更することは不可避です。

ただし、着信メッセージの形式についてはサードパーティ システムの担当者と相談することが多いため、nsXML メッセージ形式に近い仕様に合意することも可能です。その場合、受信変換の方が、対応する送信変換よりもはるかに簡素化できる可能性があります。

XSL Transformations（XSLT）と呼んではいますが、使用されているテクノロジーは、実際には拡張可能スタイルシート言語と呼ばれ、XPATH も含みます。XPATH は、XML ドキュメント内で情報を検索し、要素および属性全体を移動するための言語です。XPATH には、文字列値、数値、日付と時刻の比較、シーケンス操作、ブール値、およびその他のメソッドのための組み込み関数が用意されています。

Service Link ホーム ページからのメッセージの表示

Service Link のホーム ページの [Recent Failed Messages] ペインには、過去 30 日以内に宛先に配信できなかった Service Link メッセージが表示されます。デフォルトでは、メッセージは、送信日時に基づいて、最新のものから順に表示されます。

図 5-19 失敗メッセージ

[Failed Messages] グリッドで、いずれかのカラム リンクをクリックすると、関連情報が表示されます。

[View Transactions] タブから使用できる [Messages] ページでは、ステータスに関係なく、すべての送受信メッセージを表示し、ページに表示されたメッセージを明示的にフィルタリングし、指定した検索条件に一致するメッセージを検索できます。

メッセージの表示

[Messages] ページには、設定したフィルタに応じて、すべてまたは選択した Service Link メッセージが表示されます。デフォルトでは、完了したメッセージは表示されません。[メッセージ（Messages）] ページを表示するには、Service Link のホーム ページの [トランザクションの表示（View Transactions）] タブをクリックします。次に、[メッセージ（Messages）] サブタブをクリックします。Service Link ホーム ページの [Common Tasks] 領域にある [View Failed Messages] リンクでは、ステータスが「Failed」のメッセージだけを表示するようにフィルタが設定された [Messages] ページが表示されます。

次のように、[メッセージ（Messages）] ページが表示されます。

図 5-20 [メッセージ（Messages）] ページ

メッセージ詳細（Message Details）

[メッセージ詳細（Message Details）] ポップアップ ページには、サービス カタログ（Service Catalog）メッセージと外部メッセージの両方が表示されます。このページには、この要求内のタスクを一意に識別するチャネル ID も表示されます。この ID は、他社製システムの問題を解決する際に使用できます。

図 5-21 [メッセージ詳細（Message Details）] ページ

[メッセージ詳細（Message Details）] ポップアップ ページのいずれかのタブをクリックすると、関連情報が表示されます。

フィルタおよび検索

検索機能を使用すると、「 Failed 」ステータスを持つすべてのメッセージなど、メッセージのサブセットを表示できます。検索では、検索対象として [Messages] ウィンドウのいずれかのカラムを指定し、照合する値を選択または入力します。

[フィルタおよび検索（Filter and Search）] をクリックします（[メッセージ（Messages）] ページの最上部にあります）。

図 5-22 フィルタおよび検索

[フィルタおよび検索（Filter and Search）] ダイアログ ボックスでは、次の操作もサポートされます。

• カラムの意味に適した関係演算子を使用して、特定のカラムをフィルタリングする。たとえば、日付範囲の選択や、特定のステータスと同じでない任意のステータスの選択が可能です。
• カラムに指定されたすべての条件の論理「AND」によってフィルタリングする。

[フィルタおよび検索（Filter and Search）] ダイアログボックスは、非モーダルです。任意の基準を入力して、[適用（Apply）] をクリックすると、現在の設定の結果が表示されます。必要であれば、設定を調整して、[適用（Apply）] を再度クリックします。任意のカラムの昇順または降順でメッセージを表示したり、設定操作により表示されるカラムを変更することもできます。

失敗したメッセージの再送信

Service Link の開発中は、エージェントまたは変換設定のエラーのために配信に失敗した、多数のメッセージが生成されることがあります。これらのメッセージは再送信しないでください。同様に、Service Item Import タスクによって生成されたメッセージも再送信しないでください。インポート ファイル形式を変更して、インポート タスクを再試行してください。

ただし、公開環境では、外部システムの停止または修正可能なその他の外部要因のためにメッセージの配信が失敗することがあります。配信障害の原因を修正すると、エラー メッセージを再送信できます。

エラー メッセージを再送信するには、次の手順を実行します。

手順 1 [トランザクションの表示（View Transactions）] タブの [メッセージ（Messages）] ページで、失敗したメッセージが含まれる行をクリックします。

手順 2 [メッセージ（Messages）] ページの左下隅にある [メッセージの再送信（Resend Message）] をクリックします。

Service Link は指定された宛先に、メッセージを再送信しようとします。再送信が正常に行われると、メッセージのステータスと日付がアップデートされ、再送信日付が記録されて [再送信日付（Resent On）] カラムに表示されます。

メッセージの再送信中には、変換は再適用されません。エージェントは、変換済みのメッセージを宛先に送信しようとします。

サービス項目の操作に関する失敗した着信メッセージの再送信はサポートされません。プロセスはタスク処理の再試行を試みます。したがって、このようなメッセージの宛先は、Service Item インポート プロセッサではなく、Business Engine になります。

外部タスクの表示

外部タスクを表示するには、次の手順を実行します。

手順 1 Service Link のホーム ページで、[トランザクションの表示（View Transactions）] をクリックします。次に、[外部タスク（External Tasks）] サブタブをクリックします。

次に示す [外部タスク（External Tasks）] ページが表示されます。

図 5-23 [外部タスク（External Tasks）] ページ

手順 2 次のカラム リンクのいずれかをクリックすると、関連情報が表示されます。

フィルタおよび検索

メッセージ表示と同様、[External Tasks] ページには、データ テーブルに表示されているカラムおよびデータの順序をカスタマイズし、そのデータのフィルタリングと検索を行うための機能が用意されています。

図 5-24 フィルタおよび検索

手動メッセージの送信

起動され、着信メッセージを受信することが予期されるタスクは、「Ongoing」状態にあります。着信メッセージは、通常、タスクのアップデートまたはステータスの変更を行います。メッセージが受信され、タスクが完了するまでは、要求の配信計画にある後続のタスクを実行できません。予期されるメッセージはすでに送信されているが、何らかの理由で「消失した」ことが疑われる（または、外部システムの管理者と話をして確認できる）場合は、手動メッセージを送信してメッセージの受信をエミュレートすることができます。

手動メッセージを使用して、失敗したサービス項目の操作をエミュレートすることはできません。

（注） この機能を利用する場合は注意が必要です。この機能はシステム内のすべての通信プロトコルを上書きします。この機能を使用すると、サードパーティ システムの作成物がそのままになり、Service Link が応答できなくなる可能性があります。また、この機能を使用して要求をキャンセルした場合、たとえば、Service Link が関係先に通知を行わないため、自分でフォロー アップする必要があります。

Business Engine に手動メッセージを送信するには、次の手順を実行します。

手順 1 Service Link のホーム ページで、[トランザクションの表示（View Transactions）] をクリックします。次に、[External Tasks] をクリックします。

[External Tasks] ページが表示されます。

手順 2 [外部タスク（External Tasks）] ページの左下隅で、手動メッセージを送信するタスクが含まれている行をクリックします。

手順 3 [手動メッセージの送信（Send Manual Message）] をクリックします。

次に示す [手動メッセージの送信（Send Manual Message）] ダイアログ ボックスが表示されます。

図 5-25 手動メッセージの送信（Send Manual Message）

手順 4 送信するメッセージのタイプに応じて [Add Comment]、[Add Parameter]、[Update Values]、または [Take Action] をクリックします。

手順 5 選択したメッセージ タイプに関連付けられているポップアップ ダイアログボックスに応答します（ポップアップ ブロッカはオフにしてください）。これにより、メッセージ ウィンドウに、適切なタイプの整形式 XML メッセージが入力されます。また、このメッセージが通常のチャネルを通じて受信されたのではなく、手動で生成されたことを示す <add-comments> メッセージも含められます。

手順 6 必要に応じて、生成されたメッセージを編集できます。メッセージ全体を作成したら、[送信（Send）] をクリックします。受信メッセージが Business Engine に送信されます。

Service Link メッセージの再発行

まれに、Service Link アプリケーションが長時間停止したり、コンフィギュレーションが正しくないために、外部タスクに Service Link で作成された対応する発信メッセージを含めることができないことがあります。

Service Link で根本原因が解決し、アプリケーションが再び起動すると、問題の外部タスクを Service Link に再発行し、発信メッセージを作成して配信プロセスを再開することができます。

発信メッセージを再発行するには、次の手順に従います。

手順 1 Service Link のホーム ページで、[トランザクションの表示（View Transactions）] をクリックします。その後、[メッセージの再発行（Message Republish）] をクリックします。

手順 2 左側のペインに、1 つまたは複数の不明な発信 Service Link メッセージがある要求の Requisition ID を入力します。要求に関連するすべての承認タスクおよび配信タスクが評価され、発信メッセージの作成のために再発行が必要なタスクだけが処理されます。一度に最大 20 の要求を入力できます。

手順 3 [Republish] をクリックします。

手順 4 再発行プロセスが完了したら、右側のペインで処理のステータスを確認します。

Auto-Complete アダプタ

Auto-Complete アダプタを使用すると、エージェントは、送信メッセージを送信し、外部システムからの確認応答を待たずに、タスクを完了としてマーキングできます。送信メッセージが正常に送信される（たとえば、送信ファイル アダプタによって指定されたディレクトリにファイルが書き込まれる）と、auto-complete アダプタは、同じタスクの着信メッセージを生成します。着信メッセージは、メッセージ タイプ「take- action」を持ちます。このメッセージは、通常、Business Engine によって処理され、アクションを done としてマーキングして外部タスクを完了します。

ダミー アダプタ

ダミー アダプタはプレースホルダです。いくつかの処理シナリオで使用できます。

• ダミー アダプタを着信アダプタとして使用すると、Service Link で外部タスクを開始し、「Ongoing」ステータスのままにすることができます。
• ダミー アダプタを発信アダプタとして使用し、auto-complete アダプタを着信アダプタとして使用すると、サービス設計者は外部タスクで Auto-Complete エージェントを実装できます。その後、このタスクをワークフローの一部で使用し、参加者への電子メールを生成したり、他のタスクが含まれない要求を終了したりできます。この組み合わせは、Service Catalog と Service Link 間の通信が正しく機能しているかどうかを確認するためにも使用できます。

データベース アダプタ

データベース（DB）アダプタは、データベース内の 1 つ以上のテーブルを使用して、サービス カタログ（Service Catalog）と外部アプリケーション間でデータを渡します。

データベース接続

受信および送信データベース アダプタは、ANSI 標準 SQL をサポートする任意の JDBC 準拠リレーショナル データベースと通信できます。JDBC URL およびデータベース ドライバとともに、有効な接続基準を指定する必要があります。外部データベースが SQLServer または Oracle の場合、シスコ提供のドライバを使用できます。シスコが提供するドライバには、次のものがあります。

JDBC URL の形式は次のとおりです。

説明：

• dbtype は sqlserver または oracle です
• host は、データベース サーバの名前です
• port はデータベースに接続するポートです。通常は SQLServer の場合は 1433、Oracle の場合は 1521 です
• SQLServer にはデータベース名を指定し、Oracle には SID（システム ID）とサービス名を指定する必要があります

次に、例を示します。

サポート jar ファイルが Service Catalog ディレクトリ構造のディレクトリ ISEE.war/WEB-INF/lib にインストールされている場合、ユーザ指定のドライバを使用できます

手順 1 適切な他社製 JDBC ドライバを入手します。たとえば、Sybase JDBC ドライバは、Sybase の Web サイトからダウンロードできます。

手順 2 必要な jar ファイルを ISEE.war/WEB-INF/lib フォルダにコピーします。

手順 3 カスタム ドライバと正しい JDBC URL 形式を使用するように Agent 設定を変更します。たとえば、Sybase ドライバ用 JDBC URL の形式は次のとおりです。

手順 4 Service Link と Service Catalog サービスを再起動します。

JDBC Url の形式は、Service Link が導入されたアプリケーション サーバによっても異なります。たとえば、WebSphere アプリケーション サーバから SQLServer データベースへの接続を確立する場合、考えられる JDBC URL は次のようになります。

受信プロパティ

データベース アダプタを着信アダプタとして使用する場合、エージェントのプロパティに、指定したデータベース接続に対して実行される SQL ステートメントを含めます。この SQL は、一般的には、行のセットを返す select コマンドです。次に、これらの行が外部 XML メッセージに書式設定されます。メッセージは、（エージェントで指定される）着信変換によって有効な nsXML 着信メッセージに変換する必要があります。次に、メッセージが Business Engine に渡されます。Business Engine は、受信メッセージに指定されている Channel ID によって識別されるオープン タスクを見つけると、その受信メッセージを処理し、指定されたアクションを実行します。

データベース着信アダプタのプロパティ シートでは、次に示すプロパティ名に「DBInboundAdapter」というプレフィックスが付けられます。

受信メッセージとワークフロー

受信データベース アダプタのプロセス フローは次のとおりです。

図 5-26 受信データベース アダプタのプロセス・フロー

結果セットの行ごとに、アダプタは次の構造を持つ XML メッセージを生成します。

• メッセージのルート要素は <inbound-results> です。
• 必要な子要素は <row> です。各メッセージは <row> 要素を 1 つだけ持ちます。
• 各 <row> 要素には複数の <column> 要素があり、各カラムの要素は、アダプタに指定された InboundSQL ステートメントに含まれます。
• <row> 要素にはカラム名（<name>）と JDBC データ タイプ（<type>。文字の場合は 12、数値の場合は 1）の属性があります。
• 各 <column> 要素の値は、SQL ステートメントの対応するカラムに返される値です。

たとえば、SQL ステートメント

は、次のような XML ストリームを生成する可能性があります。

次に、変換がこの XML ストリームに適用され、有効な nsXML 着信メッセージが生成される必要があります。たとえば、継続中のタスクを完了する変換に、次のコードが含まれる場合があります。

得られた nsXML メッセージを Business Engine が処理します。メッセージが正常に適用された場合は、エージェント内に指定されている SuccessSQL が実行されます。SuccessSQL は、通常、処理で行が選択されたソース テーブル内の列をアップデートするため、次のポーリング間隔で行が再び見つかることはありません。Service Link が現在の行を更新するように指定するには、行の固有識別子を構成するカラムを識別します。これらの列は、受信 SQL ステートメントに含まれる必要があります。次に例を示します。

同様に、Business Engine が nsXML メッセージの適用に失敗した場合、たとえば、メッセージの処理中にエラーが発生した場合、FailureSQL が実行されます。FailureSQL は、通常、行が正しく処理されなかったことを示すために、現在の行のステータスをアップデートします。次に例を示します。

送信プロパティ

データベース アダプタを発信アダプタとして使用する場合は、サービス カタログ（Service Catalog）と外部システムの間に「ステージング テーブル」スタイルのインターフェイスを提供します。Business Engine によってエージェントに提供される nsXML 発信メッセージは、1 つまたは複数の SQL ステートメントが含まれる外部メッセージに変換する必要があります。その後、これらの SQL ステートメントは、指定された接続を使用して、指定されたデータベース内で実行されます。

DB 発信アダプタのプロパティ シートでは、次に示すプロパティ名に「DBOutboundAdapter」というプレフィックスが付けられます。

送信メッセージとワークフロー

XSLT 変換によって生成された送信メッセージは次の形式を持つ必要があります。

このメッセージには、それぞれが <execute-sql> タグ内にある複数の SQL ステートメントが含まれます。これらのステートメントは、通常、SQL テーブル内で行の挿入またはアップデートを実行します。アダプタに指定された JDBC ドライバがサポートしている SQL ステートメントを使用できます。SQL ステートメントにはユーザ定義関数を使用できますが、（SQLServer Transact-SQL または Oracle PL/SQL では）ストアド プロシージャはサポートされません。各外部タスクは Channel ID で一意に識別されるため、受信メッセージによってタスクを更新できるように、送信 SQL ステートメントのターゲット テーブルにはチャネル ID に対するカラムが含まれる必要があります。

ファイル アダプタ

ファイル アダプタは、指定されたディレクトリからのファイルの読み取り、または指定されたディレクトリへのファイルの書き込みをサポートしています。

• 複数のディレクトリ、または指定されたディレクトリのサブディレクトリにあるファイルを処理するように、アダプタを設定することはできません。
• 着信ファイル アダプタの起動時に、ディレクトリにある複数のファイルの中で最も古いファイルが処理されます。
• 指定されたディレクトリに対して、ファイルを処理するように設定するエージェントは 1 つだけにする必要があります。
• 指定するディレクトリ（場所）は、Service Catalog がインストールされているか、またはアプリケーション サーバからアクセスできるアプリケーション サーバのファイル システム上にする必要があります。Service Link の処理が進行すると、1 つのディレクトリから別のディレクトリにファイルが移動されるため、すべてのディレクトリが同じ物理デバイス上に存在している必要があります。

ファイル アダプタの受信プロパティ

ファイル アダプタのデフォルト値を持つプロパティは次のとおりです。

ファイル着信アダプタのプロパティ シートでは、次に示すプロパティ名に「FileInboundAdapter」というプレフィックスが付けられます。

ファイル アダプタの送信プロパティ

送信アダプタは、指定されたファイルの場所で XML ファイルを生成します。ファイル名には、channel-id が含まれます。これは、エージェントが含まれ、メッセージが作成された外部タスクの固有識別子です。ファイル名は、送信プロパティとして指定された日付形式で終わります。

ファイル発信アダプタのプロパティ シートでは、次に示すプロパティ名に「FileOutboundAdapter」というプレフィックスが付けられます。

HTTP/WS アダプタ

HTTP/WS アダプタは、HTTP 要求または Web サービス要求および応答を送受信するために使用します。HTTPS もサポートされます。

Web サービスに接続するプロキシ サーバの使用はサポートされていません。

Web サービスを呼び出すために使用する場合は、同期コールだけが可能です。発信変換は、Web サービスの標準に準拠する外部メッセージを生成するように作成する必要があります。SOAP ベースの Web サービスの場合、適切な SOAP ヘッダーと SOAP 本文要素を含める必要があります。

送信プロパティ

HTTP/WS アダプタの送信プロパティは、送信アダプタの動作を指定します。

http/ws 発信アダプタの HTTP/WS アダプタの送信プロパティ 表では、次に示すプロパティ名に「HttpOutboundAdapter」というプレフィックスが付けられます。

未使用の HTTP メソッドの無効化

Prime Service Catalog では、REST API に対して特定の HTTP メソッドのみが許可されます。他のメソッドを使用すると予期しない結果が生じる可能性があるため、サポートされていないメソッドへのユーザ アクセスを制限することをお勧めします。

サポートされる HTTP メソッドは次のとおりです。

• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE
• オプション

接続およびパッチのメソッドは許可されていません。

Apache サーバで <LimitExcept> 指令を使用して、アクセス制御を名前付きメソッド以外のすべての HTTP メソッドに制限します。詳細については、 https://httpd.apache.org で Apache ドキュメントを参照してください。次に LimitExcept 指令の例を示します。

<LimitExcept GET HEAD POST PUT DELETE TRACE OPTIONS>

Require valid-user

</LimitExcept>

IIS サーバの <verbs> 要素は、Web サーバによって許可される HTTP 要求の種類を制限するために許可または拒否される HTTP verb を指定します。詳細については、 https://docs.microsoft.com/en-us/iis で IIS サーバのドキュメントを参照してください。

次の例では 2 つのオプションが設定されます。ここでは、HTTP PUT 要求を拒否するように IIS を設定し、すべての HTTP verb への WebDAV アクセスを許可する要求フィルタも設定します。

<configuration>

<system.webServer>

<security>

<requestFiltering>

<verbs applyToWebDAV="false">

<add verb="PUT" allowed="false" />

</verbs>

</requestFiltering>

</security>

</system.webServer>

</configuration>

認証方式

送信 http/ws アダプタの一部のプロパティは、ある特定の認証方式、おそらく認証がカスタマイズされた Web サーバに対してにのみ必要です。 認証方式 の表では、送信 http/ws アダプタでサポートされている認証方式を要約します。

http/ws 要求への応答

要求が Web サイトにポストされると、あるいはメッセージが Web サービスに送られると、対象サイトでは通常はメッセージ送信者に応答を返します。応答に Service Link にとって有用な情報が含まれている可能性が低い場合、 Process Response プロパティを false に設定し、Service Link にこのようなメッセージを無視するように指定できます。ただし、このような応答に、外部システムのチケット番号や、Service Catalog で生成されたタスクに割り当てられたケース番号などの、追加情報が含まれていることがあります。この場合、Process Response と Save Ref Field の両方のプロパティを true に設定し、Service Link の Reference フィールドの xpath を指定して、Web サービスの応答から参照をキャプチャできます。さらに、変換を応答に適用し、サービス フォームを外部システムからの情報で更新するアクションを起動できます。

送信プロパティの値にエージェント パラメータを使用する

送信プロパティに、エージェント パラメータ名前空間を含めることができるようになりました。この場合、複数の操作が同じ外部システムにルーティングされ、ルーティング URL セグメントまたは要求ヘッダーの値だけが異なる場合に、単一のエージェントを複数の操作に使用できます。エージェント パラメータ名前空間の構文は $ParamName$ です。

参照フィールドと TopicID

通常、外部システムには独自の手段があり、インシデント、要求、またはその他のオブジェクトが、サードパーティ システムで開かれているか、製品のユーザ インターフェイスで維持されているかを識別します。指定された参照フィールド（TopicID）により、Service Catalog は、外部システムの一意の識別子と Service Catalog の channel-id の間の相互参照を維持することができます。TopicID が Web サービス要求への初回の応答で識別され、保存されると、それ以降に外部システムから Web サービスのリスナー アダプタ経由で受信されるメッセージは、その TopicID を Service Catalog の外部タスクを識別するのに使用できます。

受信プロパティ

• HTTP/WS 着信アダプタはリスナー アダプタで、呼び出しに基づくポーリングはサポートされません。
• 指定の URL に対して HTTP/WS 着信エージェントを 1 つだけ設定する必要があります。http プロトコルまたは https プロトコルのいずれかを使用できます。

受信 http アダプタに指定できるプロパティはありません。すべての http post を Integration Server の URL に転送する必要があります。

<ServerName>:<Port>/IntegrationServer/ishttplistener?channel-id=<channel-id>

説明：

• <ServerName> はサービス カタログ（Service Catalog）アプリケーション サーバです。
• <Port> はサービス カタログ（Service Catalog）が待ち受けるポートです。
• <channel-id> は、着信メッセージの影響を受けるタスクを一意に識別するチャネル ID です。channel-id が実行中のタスクに該当しない場合は、「Error 503（Application Error）」が他社製のシステムに返されます。

Web サービスの起動

Web サービスはそれほど単純ではない「HTTP による XML」です。送信アダプタの場合、XML メッセージは http（または https）によって Web サービスに送信されます。メッセージ（変換のアプリケーションによって作成された発信メッセージ）は、SOAP エンベロープで囲む必要があります。Web サービスに送られる XML メッセージの例は、次のようになります。

JMS アダプタ

JMS 受信アダプタはリスナー アダプタであり、ポーリングをベースとする起動はサポートしていません。

JMS アダプタはキューとの間でメッセージを読み書きしたり、特定のトピックをパブリッシュおよびサブスクライブすることができます。1 つのキューに設定できる JMS 受信エージェントは 1 つだけです。同じエージェントを複数のトピックのサブスクライブに使用することはできません。トピックは、「topic.sample.exported」のように、完全に指定する必要があります。

受信アダプタのプロパティ

JMS 着信アダプタのプロパティ シートでは、次に示すプロパティ名に「JMSInboundAdapter」というプレフィックスが付けられます。

送信アダプタのプロパティ

JMS 発信アダプタのプロパティ シートでは、次に示すプロパティ名に「JMSOutboundAdapter」というプレフィックスが付けられます。

MQ アダプタ

MQ 受信アダプタは、IBM WebSphere Message Queue（MQ）システムを使用するポーラー アダプタです。このアダプタでは、IBM MQ Series バージョン 5.x 以上をサポートしています。また、組み込み用に IBM MQ Series Java API を使用しています。IBM MQ ソフトウェアはサービス カタログ（Service Catalog）には付属していません。またライセンスは IBM から入手する必要があります。

受信プロパティ

MQ 着信アダプタのプロパティ シートでは、次に示すプロパティ名に「MQInboundAdapter」というプレフィックスが付けられます。

送信プロパティ

MQ 発信アダプタのプロパティ シートでは、次に示すプロパティ名に「MQOutboundAdapter」というプレフィックスが付けられます。

サービス項目リスナー アダプタ

Web サービス リスナー アダプタ（Web サービス リスナー アダプタを参照）と同様、サービス項目リスナー アダプタは、外部システムで外部タスクへの更新の送信に使用される Web サービス（SOAP）エンド ポイントを提供します。タスクの更新に加えて、このアダプタでは Lifecycle Center サービス項目を着信 SOAP メッセージの一部として作成、更新、および削除できます。また、アダプタにより、サービス項目メタデータとサービス項目インスタンスのデータを取得できます。

外部システムが送信する SOAP メッセージは、「processMessage」処理で起動される必要があります。SOAP 本文内のメッセージ内容は Service Link が認識できるメッセージに変換されてから、操作のタイプに基づいて分離され、それぞれ Business Engine と Service Item Import processor に転送されます。最大 2 つのメッセージが着信 SOAP メッセージの [トランザクションの表示（View Transactions）] ページに表示されます。1 つはタスク更新操作（take-action、add-comments、send-parameters）用で、1 つはサービス項目操作用（create、update、delete）です。後者のメッセージ タイプは「Service Item」です。

着信メッセージの認証は、管理モジュールのサイト設定「着信 HTTP 要求認証（Inbound HTTP Requests Authentication）」をオンにすることにより、任意で有効にできます。詳細については、Web サービス リスナー アダプタを参照してください。

受信プロパティ

サービス項目リスナー着信アダプタのプロパティ シートでは、次に示すプロパティ名に「ServiceItemListenerInboundAdapter」というプレフィックスが付けられます。

送信プロパティ

サービス項目リスナー アダプタは単方向（着信専用）です。したがって、発信プロパティはありません。

Web サービス リスナー アダプタ

Web サービス リスナー アダプタは、外部システムで外部タスクへの更新の送信に使用される Web サービス（SOAP）のエンド ポイントを提供します。外部システムが送信する SOAP メッセージは、「processMessage」処理で起動される必要があります。SOAP 本文内のメッセージ内容は、Service Link が理解できるメッセージに変換されてから、処理のため HTTP/WS 着信アダプタに転送されます。

Web サービス リスナー アダプタでは、基盤となっている Web サービス リスナーを使用します。着信メッセージの認証は、管理モジュールのサイト設定「着信 HTTP 要求認証（Inbound HTTP Requests Authentication）」をオンにすることにより、任意で有効にできます。有効にした場合、着信メッセージを処理するためには、有効なユーザ名および対応するパスワードを要求ヘッダーに渡す必要があります。必要に応じて [暗号化されたパスワードを受け入れる（Accept Encrypted Password）] 設定を有効にして、暗号化パスワードのみを使用するよう強制することができます。暗号化ユーティリティは、パスワードの暗号化された値を取得するサイト管理者ロールを持つユーザが使用できます。このユーティリティにアクセスするには、次のブラウザ ページを開きます。

http://<server>:<port>/RequestCenter/EncryptedPassword.jsp

受信プロパティ

Web サービス リスナー着信アダプタのプロパティ シートでは、次に示すプロパティ名に「WSListenerInboundAdapter」というプレフィックスが付けられます。

送信プロパティ

Web サービス リスナー アダプタは単方向（着信専用）です。したがって、発信プロパティはありません。

機密データの保護

Prime Service Catalog には通常、製品内で表示/アクセスされるとき、および外部システムと交換されるときに保護しなければならないデータが含まれます。このため、セキュア データ トランザクション中には暗号化方式を使用できます。

Prime Service Catalog 内における暗号化ディクショナリ属性の詳細については、『 Cisco Prime Service Catalog Designer Guide 』の「Configuring Dictionaries」を参照してください。

HTTP/WS および AMQP タスク アダプタに基づき、Service Link エージェントを介して送信される暗号化属性は、エージェントで設定される外部システムの 1024/2048 ビット RSA パブリック キーを使用して保護され、暗号化されます。アダプタの Http/WS 送信プロパティ ページで外部システムのパブリック キーと EncryptStringFormat を設定してから、エージェントのプロパティを設定する必要があります。詳細については、アダプタの管理を参照してください。

たとえば、Process Orchestrator（PO）へ送信される発信メッセージの暗号化属性は、次の方式で変換されます。

• 4 バイトのマジック番号
• 1 バイトの初期化ベクトル（IV）長
• IV
• 2 バイトのソルト長
• PO のパブリック キーを使用した、ソルト保護
• 暗号化ペイロード長 4 バイト
• 暗号化ペイロード

外部システムでパブリック キーが更新された場合、それに従ってエージェントを更新する必要があります。たとえば PO でパブリック キーが更新された場合、Service Link の古いメッセージが引き続き通過できるように、PO は猶予期間として 3 日間、古いキー ペアを受け入れます。3 日の猶予期間の後、Prime Service Catalog のエージェントが更新されなかった場合、PO はエラーを返します。したがって、外部システムでキーの再設定が行われた場合、エージェントではパブリック キーを手動でもう一度再設定する必要があります。

（注） 設定された外部システムのパブリック キーが Service Link のエージェントにない場合、エージェントが HTTPs/SSL プロトコルを使用する場合に限り、保存および暗号化されるように定義されたディクショナリ フィールド属性が復号化され、これらの属性の平文値が発信メッセージを介して送信されます。SSL が設定されていない場合、ディクショナリ フィールド属性は、暗号化形式のみで送信されます。

（注） Prime Service Catalog は AES アルゴリズムおよび 128/256 ビット対称キーをサポートしています。したがって、Service Catalog のインストール中に Java 開発キット（JDK）に「Java Unlimited Strength Crypto Policy」ファイルを手動で必ずインストールしてください。Java Unlimited Strength Crypto Policy ファイルにより、外部システムが 2048 ビット暗号化を実行できるようになります。Unlimited Strength Crypto Policy をインストールしない場合、インストーラにより、サーバの起動中にエラー メッセージが表示されます。Unlimited Strength Crypto Policy ファイルのインストールの説明については、Oracle の Web サイトを参照してください。Cisco Prime Service Catalog のインストールに関する情報については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。

クラウド リソース マネージャのアダプタ

クラウド リソース マネージャ アダプタは、Service Link から UCSD への送信通信をサポートします。クラウド リソース マネージャ アダプタは、着信ポーラーがアクティブ化される頻度を決定する、ポーリング間隔属性をサポートします。

（注） クラウド リソース マネージャのアダプタは事前設定されて提供されており、デフォルト設定を使用してこのアダプタを導入することが推奨されます。

全般情報（General Information）

最初に、エージェントに関する一般的な情報を指定します。

図 5-28 Create Agent

作成するディクショナリとアクティブ フォーム コンポーネントは、エージェントと同じ名前にします。ディクショナリに対する命名基準はエージェントに対する命名基準よりも厳しいため、エージェント名には英文字、数字、およびアンダースコアだけを使用します。また、数字から始まる名前は使用できません。

この画面の他のすべての設定は、Service Link の [Agents] ページで使用できる設定と対応しています。

[Next] をクリックして、ウィザードの次のページに進みます。

送信プロパティ

図 5-29 エージェントの発信のプロパティの作成

統合で実行される処理が含まれる WSDL の場所を入力します。これは通常は WSDL がある場所の URL になります。

Integration ウィザードによって、ウィザードが読み込まれ、サポートされている処理のリストが表示されます。任意の処理を選択します。その処理に指定されている属性によって、このウィザードの後続のページに表示されるエージェント パラメータの定義が変わります。

WSDL にルーティング URL が含まれている場合は、これも表示されます。

必要に応じて、[詳細プロパティ（Advanced Properties）] ドロップダウン ボタンをクリックして、統合に関するその他の設定を表示します。これらはここで入力することも、Service Link から後で指定することもできます。ウィザードから指定できるのは、基本認証だけです。

送信要求パラメータのマッピング

図 5-30 送信要求パラメータのマッピング

以下の図で示すように、ウィザードによって WSDL が解析され、Web サービスの送信要求で使用する必要のある属性が 2 つ含まれることが判断されます。そのため、エージェント パラメータが 2 つ作成されます。これらの名前は WSDL 内の属性の名前と同じになります。

これらのエージェント パラメータはディクショナリ フィールドにマッピングされます。フィールド名は WSDL 内の属性の名前と同じになり、ディクショナリ名はエージェント名と同じになります。このディクショナリは、エージェントを保存したときに自動的に作成されます。

必要に応じて、以前に Service Designer で定義したディクショナリおよびフィールドを参照するように [Service Data Mapping] を変更します。この方法で、エージェント パラメータのマッピングを効率的に変更できます。しかし、このウィザードによって作成されるディクショナリには、元のフィールドも引き続き保存されています。これを削除するには、ディクショナリの定義を編集します。

サービスにおけるディクショナリの構造や使用方法について、ここで簡単に説明します。Service Catalog ディクショナリの主な目的は、サービス フォームでユーザに表示するデータを構築することです。したがって、サービス設計者は通常はユーザ インターフェイスを念頭に置いてディクショナリを設定し、カスタマーとサービス チームのメンバーの両者にとって使いやすいようフィールドをグループ化および配置するようにします。

一般的には、送信メッセージには、多数のディクショナリのフィールドに入力された（あるいはデフォルトまたは計算されたもの）データを含めなければならない場合があります。ただし、これによってエージェント パラメータ マッピングの維持がより複雑になり、エラーが発生しやすくなります。統合の設計者はサービス フォームおよびディクショナリの設計についての詳しい知識を持っている必要があります。そのために、統合データを含める目的で、ディクショナリの作成を単独で練習することを推奨します。ディクショナリのフィールドの中には、サービス フォームに表示されるフィールドと重複するものがある場合があります。このような場合、サービス設計者は、表示されているディクショナリから統合ディクショナリにフィールドの値をコピーするための条件をルールとして設定する必要があります。また、統合ディクショナリはサービス フォームに表示されませんが（通常はアクティブ フォーム ルールによって非表示）、デバッグしやすくするために開発中は表示したままにすることができます。

送信応答パラメータのマッピング

デフォルトでは、Integration ウィザードでは、対象システムから受信した応答を処理すると仮定しています。応答で送信される属性には、対応するエージェント属性があり、これはディクショナリ フィールドにマッピングされています。

図 5-31 送信応答パラメータのマッピング

エージェントとフィールドの対応に加えて、マッピングには、ページの左側にある [Prebuilt Functions] ドロップダウンの矢印から指定できる単純な XSLT 処理も含めることができます。

送信パラメータについては、受信パラメータを代わりのディクショナリ フィールドにマッピングすることもできます。ページの左側にある [Dictionaries] ドロップダウン矢印からすべてのディクショナリを参照できます。

統合の要約

ウィザードの最後のページでは、定義した統合の要約が表示されます。定義を修正する場合は、前のページに戻ることができます。[保存（Save）] をクリックすると、作成したエージェントや他の統合コンポーネントを保存できます。デフォルトでは、統合を保存したときにエージェントが開始されます。この動作を変更するには、[保存時にエージェントを開始（Start agent upon saving）] チェック ボックスのチェックを解除します。

図 5-32 統合の要約

Service Link および Service Designer の画面からすべてのコンポーネントを編集できます。これらのコンポーネントを 統合コンポーネント の表に示します。

Service Link のステータスの確認

Service Link の動作ステータスは、最初に [Service Link Status] 表示を確認します。Service Link のステータスは、常に Service Link のホーム ページの [Common Tasks] 領域の下に表示されます。

図 5-33 Service Link Status

この機能は、Service Link が、割り当てられたポートを介して Service Catalog サービスとの通信を行っていることを確認するために役立ちます。

[Service Link Status] は Service Link の接続ステータスが動作していることを示し、使用されるポートおよびプロトコルを示します。

エージェントの起動と停止

Service Link のエージェントを停止し、エージェントのプロパティを変更したら、これが機能するためにはエージェントを再起動する必要があります。エージェントは、[Control Agents] ページから個別に起動および停止できます。

（注） Service Link サービスを停止して再起動すると、サービスが停止されたときに実行中だったすべてのエージェントが自動的に再起動されます。

ロギング

すべてのアダプタはそのアクティビティをサーバのログ ファイルに記録します。

さらに、Service Link\log ディレクトリに各標準アダプタ専用のログ ファイルがあります。ログに書き込む詳細度のレベルは設定できます。この方法は、アプリケーション サーバによって異なります。

サーバとアダプタ両方の固有のログ ファイルを管理する詳細については、『 Cisco Prime サービス カタログ（Service Catalog）管理および操作ガイド 』を参照してください。

JBoss のロギング

JBoss のインストールでは、「<JBOSS_DIR>\standalone\configuration」ディレクトリの logging.properties ファイルを変更することにより、Service Link アダプタのログをサーバ ログから別のファイルに分離できます。このような設定の例は、製品パッケージの「\preinstall\jboss\templates」ディレクトリにあるサンプル プロパティ ファイルにあります。

WebLogic のロギング

WebLogic では、アダプタごとにログ ファイルを分離することはできません。また IntegrationServer のコンポーネントは、デフォルトで WebLogic ロガーを使用するように設定されています。ログの分離が必要な場合は、ISEE.war/WEB-INF/classes にある newscalelog.properties ファイルを編集します。ロギング方法として共通のロギングを指定している行のコメントを外します。また、logger.directory に対するコメントを外して、システム内の有効な既存のディレクトリを設定することも重要です。このディレクトリに対しては、IntegrationServer の実行に使用しているユーザが完全な書き込みアクセス権を持っている必要があります。newscalelog.properties ファイルに、詳細な説明があります。また、他のアダプタに対して別の設定が必要な場合は、log4j.xml ファイルを編集し、FILE_ADAPTER アペンダとカテゴリを基盤として使用して、アペンダ名、参照、アペンダのパッケージとファイル名を変更します。

WebSphere のロギング

デフォルトでは、Service Link の WebSphere ロギングは、WebSphere アプリケーション サーバに含まれている log4j に基づいて行われます。WebSphere での log4j の実装は強力であり、管理コンソールや他のツールから設定できます。しかし、ログ ファイルを容易に分離することはできません。WebSphere でアダプタごとにログ ファイルを分離する場合は、次の手順に従ってください。

手順 1 「ISEE.war/WEB-INF/classes/config」で newscalelog.properties ファイルを見つけて、エディタで開きます。

手順 2 次の行をコメント解除します。

手順 3 logger.directory の行を見つけます。たとえば、次のようにログ ディレクトリを指定します。

これらのログ ファイルが存在する有効なディレクトリを入力すること、および IntegrationServer を実行するために使用されるユーザは、そのディレクトリに対する完全な書き込みアクセス権があることが非常に重要です。

手順 4 「ISEE.war/META INF/」ディレクトリで、「services」という名前のフォルダを手動で作成します。

手順 5 このサービス フォルダの下に、「org.apache.commons.logging.LogFactory」という名前のテキスト ファイルを手動で作成します。ファイル内で、次のように 1 行追加します。

メッセージの消去

Service Link メッセージでは大量のデータベース容量が使用される可能性があり、それらは一度要求が完了すると参照されなくなるため、データベース サイズを縮小するために定期的にデータベースからメッセージをパージすることにメリットがあります。パージ ユーティリティは、Administration モジュールの [ユーティリティ（Utilities）] タブでアクセスできます。ユーティリティは、メッセージ レコード エントリを実際に削除するわけではありません。代わりに、指定された保存期間よりも古いすべての完了または失敗したメッセージについて、メッセージの XML コンテンツを「Message has been purged」と置き換えます。詳細については、『 Cisco Prime Service Catalog Administration and Operations Guide 』の「Purge Utilities」の項を参照してください。

アプリケーション サーバのコンフィギュレーション ファイル

トラブルシューティングを行う際には、以下のファイルを分析します。

• rcjms.properties ファイル – このファイルには、統合の発信 JMS キューに関する情報が含まれ、「/RequestCenter.war/WEB-INF/classes/config」ディレクトリにあります。ビジネス エンジンは、このファイルで指定されているキューにメッセージを書き込みます。次のプロパティの値は、ISEE.war ファイルの integrationserver.properties ファイルのプロパティの値と一致する必要があります。

ISEEOutbound.JndiProviderUrl

ISEEOutbound.JndiFactory

ISEEOutbound.JmsTopicFactory

ISEEOutbound.JmsQueueFactory

ISEEOutbound.JmsQueue

ISEEOutbound.JmsTopic

• integrationserver.properties ファイル – このファイルには発信および着信 JMS キューに関する情報が含まれ、「/ISEE.war/WEB- INF/classes/config」ディレクトリにあります。このフォルダで指定されている JMS プロパティを確認します。
• newscale.properties ファイル：このファイルには isee.base.url のプロパティが含まれています。それが、Service Link サーバの url を指していることを確認します。

オンライン エラー ログ

サーバのログ ファイルおよびアダプタに固有のログ ファイルに加えて、Service Link によって検出されたエラーをオンラインで参照することもできます。[Messages] ページに表示されるエラー メッセージのメッセージ テキストは、そのメッセージについての詳細なエラーの説明にハイパーリンクされています。

エラー メッセージは、サーバ ログに表示されるそのものであり、非常に技術的な内容である場合があります。エラー メッセージの例と説明を以下に示します。

送信 Web サービスのメッセージは送信されたものの、指定された参照フィールドが応答メッセージにないため、受信応答を処理できませんでした。

変換によって、不正な XML メッセージが生成されました。

関数の使用法

基本的な関数の使用法は、式に関数を適用し、必要に応じて関数に引数リストを指定するというものです。一般的な表記は次のとおりです。

Service Link の場合、式は一般的に、Lightweight 名前空間構文によって指定されたディクショナリ フィールドまたは nsXML 要素になっています。次のように、引用符で囲みます。

次の構文を使用して、同じ式に 2 つ以上の関数をチェーンにして適用することができます。

たとえば、以下のサービス データ マッピングでは、まず指定したディクショナリ フィールドから先頭と末尾のスペースを削除（trim）して、次にその結果を小文字に変換しています。

図 5-34 パラメータ値の編集

また、以下のように、複数の要素を 1 つのマッピングに結合することもできます。要素は自動的に連結されて、1 つの文字列を形成します。

図 5-35 着信パラメータのマッピング

このシナリオでは、「一時」フィールドを使用して入力値を格納し、マッピング式で使用できるようにする別のコーディング テクニックも示します。

関数の概要

substring

substring 関数の構文は、次のとおりです。

文字列の中の部分文字列を取り出します。 from は、先頭の文字の位置を表します。これは 0 以上、 toExclusive 以下の数値である必要があります。これ以外の数値を指定すると、エラーによってテンプレートの処理が中断されます。 toExclusive は、取り出す部分文字列の最後の文字の次の場所を表します。言い換えると、最後の文字より 1 つだけ大きい数値を指定します。この値は、0 以上、文字列の長さ以下の数値である必要があります。これ以外の数値を指定すると、エラーによってテンプレートの処理が中断されます。 toExclusive を省略すると、デフォルトとして文字列の長さが使用されます。整数値でないパラメータを指定すると、その数値の整数部分だけが使用されます。

index_of

この文字列内の、指定された部分文字列の最初のインデックスを返します。たとえば、 "abcabc"?index_of("bc") は 1 を返します（1 文字めのインデックスは 0 です）。また、検索を開始するインデックスを指定することもできます。" abcabc " ?index_of( " bc ", 2) は 4 を返します。2 つ目のパラメータの数値に制約はありません。マイナスの値を指定した場合は、0 を指定した場合と同じ結果になります。また、この文字列の長さよりも大きな数値を指定した場合は、文字列の長さと同じ数値を指定した場合と同じになります。小数値は整数値に切り捨てられます。

1 つ目のパラメータがこの文字列の部分文字列として見つからない場合は（2 つ目のパラメータを指定した場合は、その位置以降で見つからない場合）、-1 が返されます。

last_index_of

この文字列内の、指定された部分文字列の最後（最も右側）のインデックスを返します。返される位置は、部分文字列の先頭（左側）の位置です。たとえば、" abcabc " ?last_index_of( " ab ") は 3 を返します。また、検索を開始する位置を指定することもできます。次に例を示します。

0 が返されます。2 つ目のパラメータは、部分文字列が始まる最も大きなインデックスを表すことに注意してください。2 つ目のパラメータの数値に制約はありません。マイナスの値を指定した場合は、0 を指定した場合と同じ結果になります。また、この文字列の長さよりも大きな数値を指定した場合は、文字列の長さと同じ数値を指定した場合と同じになります。小数値は整数値に切り捨てられます。

1 つ目のパラメータがこの文字列の部分文字列として見つからない場合は（2 つ目のパラメータを指定した場合は、その位置よりも前で見つからない場合）、-1 が返されます。

length

文字列内の文字数を返します。

lower_case

文字列を小文字に変換します。たとえば、「 GrEeN MoUsE 」は「 green mouse 」になります。

replace

元の文字列内のあるパターンを別の文字列で置き換えるために使用します。単語の境界は考慮されません。次に例を示します。

次のように置き換えられます。

置き換えは、左から右に向かって実行されます。つまり、次のように指定した場合は、

次のように置き換えられます。

最初のパラメータが空の文字列の場合、空の文字列がすべて置き換えられます。たとえば、 “foo”?replace(“”,"|") は “|f|o|o|” になります。

replace は、3 つ目のパラメータとして、 フラグ パラメータ も指定できます。

upper_case

文字列を大文字に変換します。たとえば、「 GrEeN MoUsE 」は「 GREEN MOUSE 」になります。