Cisco Prime Service Catalog 12.0 統合ガイド

メッセージ キュー

交換はプロデューサ アプリケーションからのメッセージを受け入れ、それをメッセージ キューにルーティングします。事前、事後、および主要 AMQP タスクのために作成される交換はすべて「ファンアウト」タイプで、各タスクについてデフォルト キューが作成され、それらのキューが各タスクにバインドされます。デフォルト キューの名前は <topic-name>_queue です。トピック名は「キュー サービス要求」タスクに対してユーザが [Service Designer] > [計画（Plan）] タブで入力した名前です。

（注） プードル攻撃を防ぐために、RabbitMQ サーバとの Prime Service Catalog 統合は SSL プロトコル TLSv1.2 バージョンのみをサポートしています。TLSv 1.2 が指定されていない場合、クライアントは RabbitMQ サーバに接続してメッセージを利用することができず、次の例外が発生して接続に失敗します。javax.net.ssl.SSLException: Received fatal alert: protocol_version

交換とキューを作成し、メッセージを利用するためのサンプル コードは次のようになります。

package amqpProject;

import com.rabbitmq.client.ConnectionFactory;

import com.rabbitmq.client.Connection;

import com.rabbitmq.client.Channel;

import com.rabbitmq.client.QueueingConsumer;

public class SampleProcess {

public static void main(String[] argv) throws Exception {

String exchangeName = "testExchange";

String queueName = exchangeName+"_queue";

String brokerIpAddress = "10.142.10.77";

String userName = "admin";

String password = "cisco123";

ConnectionFactory factory = new ConnectionFactory();

factory.useSslProtocol("TLSv1.2"); !--Included to prevent Poodle attack

factory.setHost(brokerIpAddress);

factory.setUsername(userName);

factory.setPassword(password);

Connection connection = factory.newConnection();

Channel channel = connection.createChannel();

channel.exchangeDeclare(exchangeName, "fanout", true, false, null);

channel.queueDeclare(queueName, true, false, false, null);

channel.queueBind(queueName, exchangeName, "");

QueueingConsumer consumer = new QueueingConsumer(channel);

channel.basicConsume(queueName, true, consumer);

while (true) {

QueueingConsumer.Delivery delivery = consumer.nextDelivery();

String message = new String(delivery.getBody());

System.out.println(" [x] Received from "+queueName+":-");

System.out.println(message);

}

}

}

REST-based nsAPIs

サービスおよびそのタスクに関するメッセージ ブローカの詳細を返すための REST API セットがあります。これにより返される署名および応答を以下に示します。必要な入力値はパス パラメータとして受け入れられるサービス名です。交換の詳細を含む、そのサービスに関するすべての AMQP タスクが発信者に返されます。

サービス固有の API のサンプル応答は次のようになります。

http://localhost:8088/RequestCenter/nsapi/messagebroker/service/<service name>

Overview API

Overview API は、Service Designer モジュール内で設定されたすべての交換を収集し、RabbitMQ サーバにすでに作成されている交換とキューを検出するためのコールを行います。Overview API は、AMQP サーバに対してルックアップを実行し、キューに関する情報を取得します。出力は JSON 形式で送信されます。

Overview API と noCache パラメータの使用：

• UI を使用して RabbitMQ 情報を指定し、noCache パラメータなしで Overview API を使用すると、情報がキャッシュとデータベースの両方から取得されます。
• ただし、データベースに直接アクセスして RabbitMQ 情報を挿入する場合は、確実に最新情報をフェッチするために、noCache =1 を指定して Overview API を使用する必要があります。

RabbitMQ サーバからの応答例は次のようになります。

http://localhost:8088/RequestCenter/nsapi/messagebroker/overview

{"connections":[{"connectionIdentifier":"am1","host":"10.78.0.247","port":5671},{"connectionIdentifier":"am2","host":"10.78.0.247","port":5671},{"connectionIdentifier":"am3","host":"10.78.0.247","port":5671},{"connectionIdentifier":"AM4","host":"10.78.0.247","port":5671},{"connectionIdentifier":"am5","host":"10.78.0.247","port":5671}]}

http://localhost:8080/RequestCenter/nsapi/messagebroker/overview?connectionIdentifier=am1

{"rabbitmq_version":"3.6.1","username":"admin","password":"UhP0zDGRoC2R7isv9qCQ6A==","ipAddress":"10.78.0.247","recoveryInterval":300000,"vhost":"/","inboundQueue":"psc_inbound_queue","authorization_key":"owL7ViRfE4Sce0aG1jSzZInkIVw5CsM7acQ5rlswpXzF/kForoUjlfrVVUOuA+CqSFSTuJlLQ5GRUMmzzxbV2xtrMvhGed6x1WU08MbDLKydSSY5UQvoAS7aZ0dROdXvF+G4uD4nAlQ6HSIc6dBct3M+dDJcm02z9OshvMaCmkvZa380B8/MbbBhu5Q3FntzWkAVY/FobU9gvlidoDt1Ty0CmAgfvPbP6joLXYaTPHjaqjYaBaX2Y4m+1V7Wm3Rb+oLpHZkCVm7Pr1zlLByPs6d+qaQShIfr0yeXXbZrQNh3s8qHl+YbYFRtNin/JEeLa6pY5J19m6zUV78n2BstRQ==","message-time-to-live":"300000","useSSL":true,"port":"5671","exchanges":[{"name":"exchange2","vhost":"/","type":"fanout","created":"false"},{"name":"HeatStack","vhost":"/","type":"fanout","created":"true"},{"name":"exchange3","vhost":"/","type":"fanout","created":"false"}],"queues":[{"name":"exchange2_queue","vhost":"/","created":"false"},{"name":"HeatStack_queue","vhost":"/","created":"true"},{"name":"exchange3_queue","vhost":"/","created":"false"}],"certificate":"-----BEGIN CERTIFICATE-----\nMIIC5DCCAcygAwIBAgIBATANBgkqhkiG9w0BAQsFADATMREwDwYDVQQDDAhNeVRlc3RDQTAeFw0x\nNjA2MTExMTUwMTJaFw0xNzA2MTExMTUwMTJaMCcxFDASBgNVBAMMCyQoaG9zdG5hbWUpMQ8wDQYD\nVQQKDAZzZXJ2ZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq8v2yJT7tv+nOwFSo\nEE1c0oVg3skd86JN7jVJaz/mMOyJjDmf1147iUwZPMTTCB34ovYUXFkw+a+0ext2WRHgQLTMPvVO\nA86jwuPd/bhUxXg8jeEfE4V/1Seci9Xz+5VxqCybCNOzJQ12/vLXvIJK43U/+1GdXnpWxFaF0yd0\nht3iUy6mfUAHfNMI2SOfJwbbdUaMyD0/Krsiu+X+vFQBUDmM7Y0priItiDVDq7rxug2UOPACzzMG\n5yJ5aJjNLSlJRwKKst/jjvesqHIgWNo0qKvkTET3tIVsKDi1Fn9IdKQuuoI1n225+58cWSANmZ5M\n4BdSIf4z6QRuKliBRi55AgMBAAGjLzAtMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgUgMBMGA1UdJQQM\nMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBCwUAA4IBAQC4L9fk4kuu/dpLeFWNUhb5Uyk6AqbTRAyD\nlq1m11E09EhmTH7cnoFsz0ELBDppASIUADSb9jmUeNKJtjW94gq8luSem1Z8lQzUCOCE6rsaznrw\nm9jJO7gXA5SSmy7PgdokdhbeTzlSYA3kkkR5ZE8M403Qv5cEPREqnshs6f6bQSm8tzSNETy3OyHL\npUo7YVTBCfJMQ/e2nZxCJSDuEL6QaIL4kmEYeu8j/1RplBAofMkDfDe+yMx2MJYl+MopVggGexpa\nMqybCchrDTJ/8sI/R18Ld80TQ2Km70sQqvNVenCpGCtgGIcupRWaAOpsQH0PNaUK+lcwYRIvf0VS\n09QE\n-----END CERTIFICATE--"}

パブリック キー GUID を使用してクレデンシャルを暗号化する

Prime Service Catalog は、nsAPI に渡されるパブリック キーの GUID を使用することにより、安全に AMQP クレデンシャルを返す方法をサポートしています。

外部システムのパブリック キー GUID がクエリ パラメータとして渡された場合、応答内のクレデンシャルは GUID に関連付けられているパブリック キーにより暗号化されます（PO のセキュリティ ストリング形式を使用）。

外部システムのパブリック キー GUID が渡されない場合は、DB で暗号化された文字列がそのまま返されます（注：外部システムではこれを復号化できません）。

暗号化された機密データは、以下に示す AMQP Overview API で返されます。

暗号化は、接続ごとに設定された公開キーを使用して実行されます。

認証キー生成 API

create、update、および delete などのサービス項目操作では channel-id よりも認証キーのほうが重要です。しかし、外部のタスクを一意に識別するため、メッセージ内には channel-id も必要です。以下の nsAPI を使用して作成される認証キーは、ユーザに固有です。認証キーは、上述の nsAPI が呼び出されるたびに値が変更されるように見えますが、特定のユーザのすべての AMQP 接続に対して同じです。このキーは、ユーザを認証するため、また、各ユーザに与えられた許可に従ってさまざまなモジュールにアクセスするために使用されます。

認証キーは、以下の nsAPI から取得できます。

JOLT ワークフローを使用した JSON の変換

Prime Service Catalog 12.0 以降では、着信変換もサポートされています。ただし、変換は、サービス項目操作ではサポートされていません。着信メッセージについてサポートされている変換の種類は XSL および JOLT で、発信については XSL、JOLT、および FTL がサポートされています。

変換を作成するための大まかなワークフローは、次のとおりです。

手順 1 [管理（Administration）] > [接続を管理（Manage Connections）] > [AMQP] から AMQP 接続を追加します。詳細については、『 Cisco Prime Service Catalog Administration and Operation Guide 』の「Managing AMQP Connections」の項を参照してください。

手順 2 JOLT 形式で送信変換および着信変換を作成します。詳細については、変換の管理を参照してください。

手順 3 Service Designer で、サービス要求のための AMQP タスクを設定します。 詳細については、『 Cisco Prime Service Catalog Designer Guide 』の「Configuring AMQP Tasks for Publishing Service Request to an External System」の項を参照してください。

注意事項：

• 次については、AMQP タスク パラメータのポップアップ ページでオーバーライドすることで、デフォルト値を定義できます。

– 公開キー

– メッセージ タイプ、つまり、特定の接続において発信メッセージおよび着信メッセージの処理がデフォルトで行われるメッセージ フォーマット（XML/JSON）。

• メッセージ タイプは AMQP 接続ごとまたはタスクごとに設定できますが、タスクごとの設定が優先されます。
• 取得される変換は、選択されている変換の種類に応じて異なります。つまり、XML が選択されている場合は発信変換および着信変換には XSL 変換のみが使用でき、JSON の場合は JOLT 変換または FTL 変換のいずれかとなります。
• FTL 変換は、発信メッセージについてのみサポートされています。

JOLT を使用した JSON 変換の例

JSON 着信 AMQP の入力：

JOLT 変換の仕様：

JSON 出力：

次は、上記の変換および入力に基づいて Prime Service Catalog 着信 AMQP コードによって生成された出力で、最終的に処理されたものです。

AMQP 着信 XML の例

AMQP 着信 JSON の例

着信メッセージ

他社製システムの要求操作およびサービス項目操作からの着信メッセージについては、2 種類の操作がサポートされています。

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

AMQP での要求操作

AMQP でサポートされている要求操作は、Service Link の要求操作と同様です。ただし、AMQP 着信メッセージでは、XML および JSON 形式がサポートされています。各操作の詳細については、着信 nsXML メッセージを参照してください。

take-action 操作は、配信タスクを完了としてマークします。

要求のディクショナリ フィールドのデータは、新しい値に更新されます。

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

AMQP でのサービス項目操作

（注） 変換は、サービス項目操作ではサポートされていません。

サービス項目操作では、認証キーを生成してメッセージに含める必要があります。認証キーを生成するには、次の nsAPI を使用します。

http://<ServerURL> /RequestCenter/nsapi/messagebroker/overview?connectionIdentifier=<particular amqp connection identifier>

この API の詳細については、 認証キー生成 APIを参照してください。 次は、AMQP でのサービス項目操作のサンプルです。

作成

create メッセージでは、サービス項目に属性値が追加されます。

update

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

削除

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

発信メッセージ

パブリッシュされるメッセージ形式は、Service Link で現在使用されている形式と同様で、nsXml、JSON、または FTL 形式です。

XML 発信メッセージの例

nsXml データ構造の例を以下に示します。

• データのメッセージ構造例、サービス詳細なし（デフォルト、小）

• セキュリティ ストリングを持つメッセージ構造例を次に示します。

JSON 発信メッセージの例