...

IBM Integration Bus V10 第3章 新機能の紹介 アップデート・セミナー 2015.7.3

by user

on
Category: Documents
83

views

Report

Comments

Transcript

IBM Integration Bus V10 第3章 新機能の紹介 アップデート・セミナー 2015.7.3
IBM Integration Bus V10
アップデート・セミナー
第3章 新機能の紹介
2015.7.3
内容







共有ライブラリ
MQ連携機能の拡張
MQTTサポート
REST APIアプリケーション開発 (Swaggerサポート)
グラフィカル・データ・マッピングの拡張
フロー・エクササイザー
その他の新機能
JavaScript
 HTTP/SOAPセキュリティ拡張
 CORSサポート
 Tutorial、GitHub連携

2
共有ライブラリ
3
共有ライブラリ
 V10から共有ライブラリ機能を提供

ライブラリ作成時に共有ライブラリと静的ライブラリを選択可能
 V8、V9のライブラリは静的ライブラリ

共有ライブラリ(Shared Library)




実行環境では1つのイメージのみが存在
参照するアプリケーションは1つの共通のイメージを参照
実行環境にライブラリ単体でのデプロイが可能
ライブラリ変更時はデプロイ後、直ちに参照する全ての
アプリケーションに反映される
 アプリケーションの再デプロイは不要

静的ライブラリ(Static Library)
 実行環境ではアプリケーションごとにライブラリ・イメージのコピーを持つ
 開発環境ではライブラリの実体は1つ
 ライブラリ変更時は、参照する各アプリケーションで再コンパイル、再デプロイが必要となる
 アプリケーションごとに異なるバージョンのライブラリを使用したい、ライブラリの変更のタイミングをアプリケーションご
とに制御したいなどの要件がある場合に選択
4
共有ライブラリと静的ライブラリ
 共有ライブラリと静的ライブラリの違い
ツールキット
実行環境
静的ライブラリは、
それぞれのアプリケ
ーション下にコピー
が組み込まれる
共有ライブラリ
静的ライブラリ
ライブラリの実体はそれぞれ1つ
共有ライブラリは、統合サーバー
直下にデプロイされる
5
共有ライブラリと静的ライブラリ

mqsilist コマンドでデプロイされている共有ライブラリの情報を確認可能
【mqsilistコマンド】
mqsilist <integration_node_name> -e <integration_server_name> -y <sharedLibraryName>
【mqsilistコマンド実行例】
>mqsilist MB10BK -e EG01
BIP1275I: 統合サーバー 'EG01' でアプリケーション 'Basic_test_Apl02' が実行中です。
BIP1275I: 統合サーバー 'EG01' でアプリケーション 'Basic_test_Apl' が実行中です。
BIP1273I: 統合サーバー 'EG01' に共有ライブラリー 'SharedLib01' がデプロイされました。
BIP8071I: コマンドが完了しました。
統合サーバーにデプロイされた共有ライブラリがリストされる
>mqsilist MB10BK -e EG01 -y SharedLib01
BIP1272I: 統合サーバー 'EG01' にファイル 'SharedLib01.Sh_ErrHandling.subflow' が
デプロイされました。 (共有ライブラリー 'SharedLib01')
BIP1249I: 共有ライブラリー 'SharedLib01' はアプリケーション 'Basic_test_Apl' に
よって参照されています。
BIP1249I: 共有ライブラリー 'SharedLib01' はアプリケーション 'Basic_test_Apl02'
によって参照されています。
統合サーバーにデプロイされた共有ライブラリのリソース情報、共有ライブラリを参照
するアプリケーション情報がリストされる
6
注意点
 共有ライブラリ利用時の注意点

実装時の制限





共有ライブラリ <-> 静的ライブラリ間の参照は不可
Integration プロジェクトは共有ライブラリを参照不可
共有ライブラリに定義するサブ・フローやESQLはスキーマ配下に定義が必須(後述)
共有ライブラリに含まれるJavaクラスは、IIBのクラス・ローダーとは独立したクラス・ローダーを利用(後述)
デプロイの注意
 共有ライブラリを事前にデプロイしておかないと参照するアプリケーションのデプロイは失敗
 BARファイルに一緒に含めてデプロイすることも可能
 共有ライブラリは直接統合サーバーにデプロイされる
 静的ライブラリは参照する各アプリケーションに含まれる
 参照アプリケーションがデプロイされた状態で共有ライブラリを除去することは不可

共有ライブラリに含められないリソース
・メッセージ・フロー
・CORBARequest ノードとIDL ファイル
・DecisionService ノードとdecision サービス
・PHPCompute ノードとPHP ファイル
・SCAノード
・WebSphere Adapters ノード
・XSLTransform ノード
・MRM メッセージ・セット
・XMLファイル
・XSLファイル
7
注意点(サブフロー、ESQL)

サブフロー、ESQLファイルを共有ライブラリに含める場合の注意点
 共有ライブラリ に定義するサブフローやESQLファイルはスキーマ配下に定義する必要がある
 アプリケーションや静的ライブラリ に定義するときは、デフォルトでは空のスキーマに定義
デフォルトでは共有ライブラリ 名のスキーマ配下に定義
(スキーマ名を任意に指定することも可)
 同名のスキーマは参照関係にあるアプリケーションや共有ライブラリ にまたがって定義してはならない
このように同名のスキーマ(test)をアプリケーションや共有ライブラリにまたが
って定義するとエラー
参照関係でなければ、同名スキーマを定義することも可能であるが、基本的
には共有ライブラリ にはユニークなスキーマを定義すること
8
注意点(Javaクラス)

Java クラスを共有ライブラリに含める場合の注意点
 共有ライブラリ 内にJavaクラスを定義できる
 ただし、アプリケーション内のJavaクラスから参照している共有ライブラリ のJavaクラスを利用することはできない
App1
ShLib1
JavaComputeClass1
JavaClassA
アプリケーションのクラスローダー
ShLib1用クラスローダー
共有ライブラリがデプロイされると新たにクラ
スローダーが作成される
統合サーバーのクラスローダーとは分離され
ていて、Javaからアクセスできない
 共有ライブラリ 内のJavaクラスから、参照している別の共有ライブラリ のJavaクラスを利用することは可能
 この場合、参照先のJavaクラスは参照元共有ライブラリ のクラスローダー内に入る
App1
ShLib1
ShLib2
JavaComputeClassA
JavaClassB
ShLib1用クラスローダー
ShLib2
ShLibX
JavaComputeClassX
JavaClassB
ShLibX用クラスローダー
複数の共有ライブラリ から利用されるJava
クラスは、それぞれのクラスローダーに存在す
ることになる
※ShLib2を再デプロイすると、利用して
いるすべてのクラスローダーが再作成され
る点に注意
9
MQ連携機能の拡張
10
MQ連携機能の拡張
 MQノードからローカル/リモートの任意のキューマネージャーに接続可能





V9 まではローカルの統合ノード・キューマネージャーにのみ接続可能
MQInput、MQOutput、MQGet、MQReplyが対象
1つのフロー内で異なるキューマネージャーに接続するMQノードの混在も可能
複数の統合ノード上のフローから同じキューマネージャーに接続することも可能
z/OS版はローカル接続のみサポート
 統合ノードに対しキューマネージャーの関連付けは必須だが、他のローカル・キューマネージャーへの接続も可

グローバル・トランザクションは統合ノードに関連付けたローカルのキューマネージャーのみ可能
ローカル
MQノード・フロー
キューマネージャー
リモート
キューマネージャー
ローカル
キューマネージャー
MQノード・フロー
11
キューマネージャーへの接続情報設定

新規のMQ Connectionタブで接続するキューマネージャーの情報を指定
 MQ Connection タブのプロパティ一覧
プロパティ
説明
Connection
キューマネージャーへの接続方法を指定(後述)
Destination queue manager name
接続先のキューマネージャー名
Queue manager host name
ホスト名
Listener port number
ポート番号
Channel name
チャネル名
Security identity
セキュリティID(後述)
Use SSL
クライアント接続時にSSL通信するかどうか(デフォルトはチェックなし)
SSL peer name
SSL利用時のピア名を指定
SSL cipher specification
SSL利用時のCipherSpecを指定
12
キューマネージャーへの接続情報設定

Connectionプロパティの設定値
設定値
説明
Local queue
manager
Destination queue manager nameプロパティに指定されたローカルのキューマネー
ジャーに接続 *1 (デフォルト)
MQ client
connection
properties
以下のプロパティの接続情報を基にリモートのキューマネージャーに接続
- Queue manager host name *2
- Listener port number
- Channel name
- Destination queue manager name
Client channel
definition table
(CCDT) file
クライアントチャネル定義テーブル(CCDT)の定義を基に接続 *3
キューマネージャー名(キューマネージャー・グループ名)はDestination queue manager
nameプロパティに指定
*1 キューマネージャー名の指定なしの場合、統合ノードに関連付けられたキューマネージャーに接続
(統合ノードに紐づくキューマネージャーがない場合は、デプロイ・エラー)
*2 マルチ・インスタンス・キューマネージャー使用時などでキューマネージャー障害時に接続先キューマネージャーの切り
替えが可能
host nameに複数のホスト名をカンマ区切りで定義
*3 使用するクライアントチャネル定義テーブル・ファイル(.TAB)は統合ノード・プロパティー(mqCCDT)で指定
(コマンド例)
mqsichangeproperties MB10BK -o BrokerRegistry -n mqCCDT -v "C:¥Program Files
(x86)¥IBM¥WebSphere MQ¥Qmgrs¥MB10QM¥@ipcc¥AMQCLCHL.TAB"
13
キューマネージャーへの接続情報設定
 キューマネージャーへの接続先情報を運用ポリシーに指定することも可能

V10から、MQノード用にMQEndpoint 運用ポリシーを提供
 MQ Endpoint のプロパティは、MQノードのMQ Connection タブのプロパティと同等
 運用ポリシーは実行環境にWebユーザー・インターフェースなどで定義
 環境によって異なる接続先情報を運用ポリシーに指定することで、フローから環境依存となる設定を排除できる

運用ポリシーの設定は実行時にノード設定を上書き
 ポリシーの設定は、ノード・プロパティやBARファイルの構成可能プロパティより優先される

運用ポリシーの設定変更は動的に有効
 フローを再デプロイすることなく、接続先情報を変更可能

MQノードのPolicyタブ - Policy URLプロパティに使用する運用ポリシーを指定
(URL指定)
14
セキュリティID
 キューマネージャーへの接続時にユーザーIDとパスワードを渡すことが可能

MQ V8 で提供された接続認証機能に対応
 V8の接続認証機能は、接続時にユーザーIDとパスワードで認証を行う

ローカル接続、クライアント接続ともに可能
 ただし、CCDTを利用したクライアント接続時は不可

統合ノードにセキュリティIDとしてユーザーIDとパスワードを登録
 mqsisetdbparmsコマンドで「mq::」のプリフィックスをつけて登録(登録方法は以下の3通り)
①セキュリティIDに特定の名前をつけて登録する方法
mqsisetdbparms integrationNodeName -n mq::securityIdentityName -u username
-p password
 securityIdentityName に任意のセキュリティID名を指定
 MQノードもしくは運用ポリシーのSecurity identityプロパティに上記セキュリティID名を指定するとここで指定したユーザー
ID/パスワードが使用される
②キューマネージャーを特定したセキュリティIDを登録する方法
mqsisetdbparms integrationNodeName -n mq::QMGR::mySecureQM -u username
-p password
 mySecureQM にはキューマネージャー名を指定
 指定したキューマネージャーに接続する際はここで指定したユーザーID/パスワードが利用される
(Security identityプロパティはブランク)
15
セキュリティID
③MQ全体に有効なセキュリティIDを登録する方法
mqsisetdbparms integrationNodeName -n mq::MQ -u username -p password
 ②に該当しないキューマネージャーに接続する場合、ここで指定したユーザーID/パスワードが利用される
(Security identityプロパティはブランク)
 有効となる設定の優先順位は、①>②>③
 登録したセキュリティIDの確認は以下のコマンドで実施
mqsireportdbparms integrationNodeName -n mq::*
 登録したセキュリティIDの削除は以下のコマンドで実施
mqsisetdbparms integrationNodeName -n mq::SecurityID -d
16
MQコネクション、キュー・ハンドル
 MQコネクション、キュー・ハンドルの保持時間

デフォルトでは、1分間、処理が発生しないとフローはアイドル状態になり、
MQコネクションやキュー・ハンドルをリリース
 MQInputノードは常に入力キューを受信待ちするため、リリース後すぐにキューマネージャーへの接続、キューの
オープンを実施

保持時間は、統合ノードのsharedConnectorIdleTimeoutプロパティで変更可能
 mqsichangepropertiesコマンドで変更
 0より大きい値で指定(秒)
 -1を指定した場合は、リリースしない
mqsichangeproperties integration_node_name -e integration_server_name -o
Connectors -n sharedConnectorIdleTimeout -v new_timeout_value
※MQ V9 までは、MQコネクションやキュー・ハンドルはフローがアイドル状態となっても保持し続けます。(ISE検証結果より)
17
MQTTサポート
18
MQTTサポート
 IoT、M2M向けの軽量でオープンなMQTTプロトコルをサポート

MQTT V3.1をサポート
 MQTTノードの提供
MQTTPublish
 MQTTSubscribe

・・・指定したトピックに対しメッセージをMQTTサーバーに送信
・・・パブリッシュされたメッセージをMQTTサーバーから受信
 MQTTサーバー機能の提供
統合ノード毎に1つのMQTTサーバーが構成される
 bipMQTT.exeプロセス
 MQTTノードはIIB提供MQTTサーバーと外部のMQTTサーバーのどちらにも接続可

統合ノード
統合サーバー
MQTT
クライアント
MQTT
クライアント
MQTTサーバー
(IIB提供)
MQTTサーバー
(外部)
19
<補足>
 MQTTとは

Internet of Things(IoT)、Machine-to-Machine(M2M)に適した軽量な通信
プロトコル
 少ないデータ量での通信、クライアント・モジュールの低バッテリー消費

Publish/Subscribe型のメッセージング・モデル
 MQTTサーバーを介して、トピック・ベースでメッセージの同報配信が可能
 非同期、かつ、双方向通信

メッセージの送達保証
 3つのQoS(Quality of Service)を規定し、
低品質なネットワーク環境でも信頼性の高い伝送を実現

オープンな仕様
 OASIS標準として仕様公開
 http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
 Pahoプロジェクトでクライアント・ライブラリを公開
 https://www.eclipse.org/paho/
MQTT Clients
Publish
トピック・ベース
Subscribe
MQTT Clients
MQTT Server
20
MQTTPublishノード
 指定したMQTTサーバー/トピックに対し、メッセージをPublishするノード

ホスト名とポート番号で接続するMQTTサーバーを指定
 運用ポリシーで指定することも可



統合ノードのMQTTサーバー、および外部のMQTTサーバーに接続可
トピックは任意に指定可
クライアントIDはMQTTサーバー内でユニークなIDを指定する必要あり
Publish
MQTTサーバー
 ノード・ターミナル
ターミナル
用途
In
前段のノードから出力されたメッセージが入力されるターミナル
Out
MQTTサーバーにパブリッシュされたメッセージが出力されるターミナル
Failure
MQTTサーバーへのパブリッシュに失敗した場合にメッセージが出力されるターミナル
21
MQTTPublishノード
 主要なノード・プロパティ
プロパティ
説明
Basicタブ
Client ID
MQTTサーバーに接続する際のユニークな名前
Topic name
パブリッシュ先のトピック名
Host name
MQTTサーバーのホスト名
Port
MQTTサーバーがリッスンするポート番号(デフォルト1883)
Quality of
service
MQTTプロトコルのQoS
0 - At most once(デフォルト), 1 - At least once, and 2 - Exactly once.
Security
identity
mqsisetdbparms コマンドで定義したセキュリティID
Policyタブ
Policy URL

運用ポリシーのURL
上記ノード・プロパティは、構成可能プロパティとしてBARファイルで上書き可能
 手動、もしくは mqsiapplybaroverride コマンドで上書き
22
MQTTPublishノード
 LocalEnvironment

以下のエレメントをノードの手前で設定することでノードの動きを動的に変更可能
 LocalEnvironment.Destination.MQTTNode.Output サブツリー

エレメント
タイプ
説明
retained
BOOLEAN
リテイン・パブリッシュにするかを指定
TopicName
CHARACTER
トピック名を指定
qos
INTEGER
QoSを指定
ノード処理完了後に以下のエレメントがセットされる
 LocalEnvironment.WrittenDestination.MQTT サブツリー
エレメント
タイプ
説明
ClientId
CHARACTER
クライアントID
DeliveryToken.isComplete
BOOLEAN
メッセージが正常にパブリッシュされたかどうか
23
MQTTSubscribeノード
 指定したトピックにパブリッシュされたメッセージをMQTTサーバーから受信

ホスト名とポート番号で接続するMQTTサーバーを指定
 運用ポリスーで指定することも可



統合ノードのMQTTサーバー、および外部のMQTTサーバーに接続可
トピックは任意に指定可
クライアントIDはMQTTサーバー内でユニークなIDを指定する必要あり
Publish
MQTTサーバー
Subscribe
 ノード・ターミナル
ターミナル
用途
Out
MQTTサーバーから受信したメッセージが出力されるターミナル
Failure
MQTTサーバーへのパブリッシュに失敗した場合にメッセージが出力されるターミナル
Catch
後続ノードで例外が発生した場合にメッセージが出力されるターミナル
24
MQTTSubscribeノード
 主要なノード・プロパティ
プロパティ
説明
Basicタブ
Client ID
MQTTサーバーに接続する際のユニークな名前
Topic name
サブスクライブするトピック名(ワイルドカード ”#”、”+“ を使用可能)
Host name
MQTTサーバーのホスト名
Port
MQTTサーバーがリッスンするポート番号(デフォルト1883)
Quality of
service
MQTTプロトコルのQoS
0 - At most once(デフォルト), 1 - At least once, and 2 - Exactly once.
Security
identity
mqsisetdbparms コマンドで定義したセキュリティID
Policyタブ
Policy URL

運用ポリシーのURL
上記ノード・プロパティは、構成可能プロパティとしてBARファイルで上書き可能
 手動、もしくは mqsiapplybaroverride コマンドで上書き
25
MQTTSubscribeノード
 LocalEnvironment

ノード処理完了後に以下のエレメントがセットされる
 LocalEnvironment.MQTT.Inputサブツリー
エレメント
タイプ
説明
Duplicate
BOOLEAN
受信したメッセージが前に受信したメッセージと重複しているかどうか
(TRUE/FALSE)
Retained
BOOLEAN
リテイン・メッセージかどうか(TRUE/FALSE)
Topic
CHARACTER
受信したメッセージのトピック・ストリング
QualityOfService
INTEGER
受信したメッセージのQoS(0/1/2)
26
クライアントID
 MQTTのクライアントIDに関する制約、考慮点

クライアントIDは、23バイト以内の文字列
 ツールキットにて、ノードに設定するタイミングで長さが超過しているとエラーを表示

MQTTサーバーに接続しているクライアント間でユニークなIDである必要がある
 すでに接続済みのクライアントIDを指定した新たな接続要求がきた場合、MQTTサーバーは先に接続してい
たコネクションを切断し、新規の接続を受け付ける(MQTTの仕様)
 MQTTSubscribeノードは一度コネクションが切断されても、即座に再接続を行う
27
並列稼動時の注意点
 マルチスレッドで動かした場合(追加インスタンス)
追加インスタンス数を増やすことで受信したメッセージを並行処理可能
 ただし、MQTTサーバーへの接続は1本のみ

③
②
①
①
②
MQTTサーバー
③
 マルチ・プロセスで動かした場合
複数の統合サーバーに同じMQTTSubscribeフローをデプロイしても同じクライアントIDを指
定している場合、MQTTサーバーは1つの接続しか受け付けない
 異なるクライアントIDを指定した場合は、接続は受け付けられるが、それぞれのフローが同じメ
ッセージをサブスクライブすることになる
 従って、マルチ・プロセスで動かしてもスケーラビリティは向上しない

28
運用ポリシー
 MQTTノード用の運用ポリシーを提供
MQTTPublishノード用、MQTTSubscribeノード用それぞれに運用ポリシーを提供
 MQTTノードに適用することで同等のノード・プロパティをランタイムで上書き可能
 以下のプロパティを設定可能


運用ポリシー・プロパティ
対応するノード・プロパティ
clientId(クライアントID)
Client ID
topicName(トピック名)
Topic name
hostName(ホスト名)
Host name
port(ポート)
Port
qos(サービス品質)
Quality of service
ノード・プロパティ「Policy URL」で適用する運用ポリシーを指定
 運用ポリシーはURLで指定
 作成時にMQTTPublishポリシー名を「LocalMQTTServer」とした場合、URLは以下となる
 /apiv1/policy/MQTTPublish/LocalMQTTServer
29
運用ポリシー

Web管理コンソールによる定義例
 統合ノード ⇒ 運用ポリシー ⇒ MQTTPublish / MQTTSubscribe
30
MQTTサーバー構成
 統合ノードに対しに1つのMQTTサーバーが構成される

統合ノード構成時に自動的に作成
 bipMQTT.exe

デフォルトで統合ノード起動時に自動起動
 以下のコマンドで変更可能(使用しない設定に変更する場合)
 mqsichangeproperties IBNODE -b pubsub -o MQTTServer -n enabled -v false
 以下のコマンドで確認
 mqsireportproperties IBNODE -b pubsub -o MQTTServer -n enabled

デフォルトのポートは11883
 同一環境で複数の統合ノードを構成した場合は構成順に1カウントアップした番号がセットされる
 以下でのコマンド明示指定可能
 mqsichangeproperties IBNODE -b pubsub -o MQTTServer -n port -v 11885
 以下のコマンドで確認
 mqsireportproperties IBNODE -b pubsub -o MQTTServer -n port
>mqsireportproperties 10bBK -b pubsub -o MQTTServer -r
MQTTServer
enabled='true'
port='11885'
31
リソース統計
 MQTTのリソース統計として以下の情報を取得可能
Measurements
Description
OpenConnections
MQTTサーバーに対して現在オープンなコネクション数
ClosedConnections
統合サーバーが起動されてから切断したMQTTサーバーへのコネクション数
MessagesReceived
MQTTSubscribeノードによって受信されたメッセージ数
MessagesSent
MQTTPublishノードによって送信されたメッセージ数
BytesReceived
MQTTSubscribeノードによって受信されたデータ量
BytesSent
MQTTPublishノードによって送信されたデータ量
FailedConnections
統合サーバーが起動されてから接続に失敗したコネクション数
 統合ノードの構成によってデフォルトでリソース統計情報をパブリッシュするPub/Subブローカーが異なる
 キューマネージャーを関連付けた統合ノードの場合、MQのPub/Subブローカー
 キューマネージャーを関連付けていない統合ノードの場合、統合ノードのMQTTブローカー
 Pub/Subブローカーによってトピック・ストリングも異なる点に注意
 MQ Pub/Subブローカーの場合
$SYS/Broker/integrationNodeName/ResourceStatistics/integration_server_name
 MQTTブローカーの場合
IBM/IntegrationBus/integrationNodeName/ResourceStatistics/integration_server_name
 リソース統計の詳細は以下を参照
http://www-01.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc /bj43310_.htm
32
アクティビティ・ログ
 MQTTのアクティビティ・ログを取得可能

MQTT固有の以下のタグを提供
タグ名
説明
TOPICNAME
MQTTノードが処理したメッセージのトピック名
CONNECTIONURL
MQTTノードが接続したMQTTサーバーへのURL
備考
例 tcp://xxx.xxx.xxx.xxx:11883
※IIB V10からIB Explorerが提供されなくなり、GUI でアクティビティ・ログを表示することができなくなっています。
アクティビティ・ログの利用に関しては下記をご確認ください。
http://www-01.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc /bj55000_.htm
33
REST APIアプリケーション
開発(Swaggerサポート)
34
IIB V10 REST API 連携機能概要
 REST API

ソーシャル・アプリケーション、モバイル端末、ブラウザー、組み込み機器等多様なクライアントが
リモートのサービスを呼び出す標準的な手法として利用されている
App
REST API連携機能が強化され、既存システムの
業務をAPIとしてより簡単に公開可能に
App
Swagger 2.0をサポート
APIm Catalog


REST APIを記述するための標準
Swagger文書をインポートしてREST APIサービスを
提供する「REST APIアプリケーション」を追加
統合サービスからJava Script クライアントの生成
IBM Integration Bus


API公開専用のウィザードが提供
既存のWebサービスをJavaScriptから呼ぶためのSDK生成
JSONサポートの強化
バックエンド・アプリケーション
、
サービス

JSONデータをGUIでマッピング可能に
35
REST APIアプリケーション
 REST APIアプリケーション
IIB V10において、REST API公開に特化した
“アプリケーション”が追加
 REST API公開を簡単に行う方法を提供
 Swagger 2.0の定義文書(JSON形式)をインポートして作成
 Swaggerツールと連携してAPIの定義、実装、公開、
テストが可能

36
REST APIの構成
 APIは相対パスによって識別される複数のリソースを含む
基本パス
リソースの例
相対パス
意味
/customers
データベース内の全ての顧客情報
/customers/12345
顧客番号12345の顧客情報
/customers/12345/orders
/customers/12345/orders/67890
リソースと
相対パス
API
/customerdb/v1
GET
/customers
POST
顧客番号12345の全ての注文情報
/customers/{customerId)
顧客番号12345の注文#67890
PUT
GET
DELETE
 各リソースは複数を操作を含み、HTTPメソッドに関連づけられる
リソース/customer/{customerId}に対する操作の例
HTTPメソッド
操作
GET
getCustomer
PUT
updateCustomer
DELETE
deleteCustomer
 各操作はHTTPボディの情報に加えてパラメーターを持つことができる

1) パス・パラメーター


2) クエリー・パラメーター


key=valueの形式でパスの後に設定される
3) ヘッダー・パラメーター


URLのパスの一部として設定される
例
/customers/12345/orders/56789
例
/customers?min=5&max=20
例
Api-Client-Id : ff6e2c5d-42d5-4026-8f7f-d1e56da7f777
HTTP要求のヘッダーとして設定される
4) フォーム・パラメーター
37
Swaggerとは?
 REST APIを記述するための仕様

JSON形式のSwagger文書でAPIを記述
 リソース、操作、パラメーター、HTTP要求・応答のデータ・モデルを
表現するJSONスキーマ
 WebサービスにおけるWSDL文書の位置づけ
 IIB V10ではV2.0がサポートされる
 Swagger文書は一般にswagger.jsonという名前が付けられる
 REST APIを記述、利用し、可視化するためのツールを含む

Swagger UI
 API文書をブラウザで表示し開発者にリファレンスとして提供
 ブラウザ上からAPIのテスト可能

Swagger Editor
 YAML形式でAPIを記述することでSwagger文書を生成

Swagger Code Generator
 JSON形式のSwagger文書から各種言語向けにクライアント/サーバーのコードを生成

その他
 Swagger-core
 プログラム・ソース内のアノテーションの情報からSwagger文書を生成
http://swagger.io/
38
(参考)Swagger文書の例
swagger.jsonの例(抜粋)
{
"swagger": "2.0",
"info": {
"title": "Staff Table API",
"description": "従業員テーブルへのアクセス用API",
"version": "1.0.0"
},
"host": "localhost",
"schemes": [
"http"
],
"basePath": “/StaffInfo/v1",
"produces": [
"application/json"
],
"paths": {
"/staff/{id}": {
"get": {
"summary": "従業員情報の取得",
"description": "",
"operationId": "getStaffData",
"parameters": [
{
"name": "id",
"in": "path",
"description": "従業員ID.",
"required": true,
"type": "string"
}
],
"tags": [
"Staff"
],
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/Staff"
}
},
"default": {
"description": "Unexpected error",
"schema": {
"$ref": "#/definitions/Error"
}
}
}
}
}
},
(右へ続く)
JSONスキーマでAPI内で利用
APIの情報の定義
されるオブジェクトを定義
- ホスト名
- スキーマ(HTTP/HTTPS等)
- 基本パス
(左からの続き)
- Content-type 等
"definitions": {
"Staff": {
"properties": {
"staffId": {
"type": "string",
"description": "従業員ID"
},
"lastChanged": {
"type": "string",
"format": "date-time",
"description": "最終更新日付"
},
"firstName": {
"type": "string",
"description": "名前"
},
"lastName": {
"type": "string",
"description": "苗字"
},
"mail": {
"type": "string",
"description": "メール・アドレス"
}
}
},
"Error": {
"properties": {
"code": {
"type": "integer",
"format": "int32"
},
"message": {
"type": "string"
},
"fields": {
"type": "string"
}
}
}
}
リソースとURLの定義
操作の定義
}
39
REST APIアプリケーションの開発の流れ
 REST APIアプリケーションの開発の流れ
1.
Swagger文書を準備
2.
REST APIアプリケーションを作成
2-1. REST APIアプリケーションを新規に作成
2-2. Swagger文書をインポート
3.
APIの操作を実装する
4.
実行環境にデプロイ
5.
Swagger UIでテスト
※ Swaggerについては後述
40
REST APIアプリケーション作成・利用の全体像
1.YAML形式でAPIを記述し
Swagger文書を生成
2.Swagger文書をインポート、
REST APIのサービスを実装
IIBフロー開発者
Barファイル
swagger.json
3.IIBランタイムにデプロイ
統合ノード
IIB ツールキット
Swagger Editor
4.Swagger UIでREST API
アプリケーションをテスト
REST API
呼び出し
(テスト)
API コンシューマ
アプリ開発者
Swagger UI
Swagger
Code
Generator
生成
Android
SDK
生成
Python
SDK
統合サーバー1
PHP
SDK
REST API
コンシューマ
アプリ
swagger.json
REST APIアプリケーションと
Swagger文書もIIBに配置される
swagger.json
生成
REST API
アプリケーション
REST API
呼び出し
41
1. Swagger Editorを利用したAPIの記述
 Web画面上でYAML形式でAPIを記述

Web上のサービスを利用することも、ローカルで稼働させることも可能
 Web上のサービスは下記URLよりアクセス可能
 http://editor.swagger.io/
 ローカルで稼働させる場合にはNode.js, gitが前提として必要
git clone https://github.com/swagger-api/swagger-editor.git
cd swagger-editor
npm start
1.YAML形式でAPIの記述
2.記述されたAPIのリファレンスが出力される
3.記述したAPIをJSON形式
Swagger文書としてダウンロード
42
1. Swagger Editorを利用したAPIの記述
 YAMLとJSON
YAMLはJSONと1対1に相互変換可能な形式
 JSONよりも短く記述しやすいためSwagger EditorでAPIの記述に採用されている

YAML形式による APIの記述
JSON形式による APIの記述
データの構造
字下げで表現
{ } で表現
配列
行頭の - で表現
[ ] で表現
43
2. REST APIアプリケーションの作成
 IntegrationツールキットのApplication Developmentビューより
「New」→「Start by creating a REST API」を選択して作成開始
REST APIアプリケーション名を入力
Swagger文書の場所を入力
44
2. REST APIアプリケーションの作成
 作成されたREST APIアプリケーションの操作を実装する
クリックして操作を実装するサブ・フローを生成
メッセージ・フロー・エディタでサブ・フロー
が開くのでAPI操作を任意のノードを組
み合わせて実装する
45
2. REST APIアプリケーションの作成

API操作のパラメーターへのアクセス方法
 パラメーターはLocalEnvironmentツリーに展開される
 パス・パラメーターが渡された際のLocalEnvironmentツリーの例
( ['MQROOT' : 0x1ea12590]
(0x01000000:Name):Destination = (
(0x01000000:Name):HTTP
= (
(0x03000000:NameValue):RequestIdentifier =
X'485454500000000000000000000000007c36000000000000' (BLOB)
)
(0x01000000:Name):RouterList =
)
(0x01000000:Name):REST
= (
(0x01000000:Name):Input = (
(0x03000000:NameValue):Method
= 'GET' (CHARACTER)
(0x03000000:NameValue):Operation = 'getStaffData' (CHARACTER)
(0x03000000:NameValue):Path
= '/v1/staff/12345' (CHARACTER)
(0x03000000:NameValue):URI
= 'http://localhost:7800/v1/staff/12345'
(CHARACTER)
(0x01000000:Name
):Parameters = (
(0x03000000:NameValue):id = '12345' (CHARACTER)
)
)
)
)
 ComputeノードのESQLからのアクセス例
DECLARE STAFF_ID CHAR;
SET STAFF_ID = InputLocalEnvironment.REST.Input.Parameters.id
46
3.REST APIのデプロイ
 通常のアプリケーションと同じくBARファイルとしてデプロイ

追加インスタンスやポリシーも設定可能
メッセージ・フローに対して追加インスタンス
やワークロード・ポリシー等のプロパティーを設
定
47
3.REST APIのデプロイ
 デプロイされたREST APIの情報にWeb管理画面からアクセス可能

Swagger文書もIIBランタイム上にホストされ、開発者やSwagger UI等からアクセスできる
ようになる
Swagger文書へのURL
48
3.REST APIのデプロイ
 HTTPリスナーに関する注意点

REST APIをデプロイする場合、HTTPリスナーは統合サーバー(組み込み)リスナーが前提
 MQの関連付けをしている場合は、明示的に以下のコマンドで、統合サーバー(組み込み)リスナーを使用する
ように設定変更が必要
mqsichangeproperties integrationNodeName -e integrationServerName -o
ExecutionGroup -n httpNodesUseEmbeddedListener -v true
49
4.Swagger UIを利用したREST APIアプリケーションのテスト
 Swagger UI

Swagger文書からAPI仕様を参照するWeb画面を生成
 APIを利用する開発者がAPI仕様を参照するとともに、REST APIのテスト機能も付属
 HTML, JavaScript, CSSの集合として作成されているため、 簡単にローカルにコピー、またはWebサーバ
ー上に配置して実行可能

IIBで実装したREST APIアプリケーションのテストに利用可能
50
4.Swagger UIを利用したREST APIアプリケーションのテスト
 テストしたいAPIの操作を開き、パラメーターを入力して送信すると応答コード、応
答メッセージ、応答ヘッダーが表示される
1.パラメーターを入力
2.テストを実行
3.応答結果が表示される
51
4.Swagger UIを利用したREST APIアプリケーションのテスト
 Swagger UIの構成
Swagger UIをダウンロードして展開すると、distフォルダ配下にindex.htmlが見つかる
 index.htmlを編集し、IIB上のSwagger文書のURLに変更

2. URLをIIB上のSwagger文書に変更
1. Swagger UIのindex.htmlを開く
 IIB上のSwagger文書へのURLはIIBのWeb管理画面、またはIIBツールキットより確認可能
Integration Nodesビ
ューよりREST API
Descriptionを選択し
てプロパティーを確認
52
4.Swagger UIを利用したREST APIアプリケーションのテスト
 注意事項

Swagger UIからIIB上のREST APIアプリケーションをテストする場合、クロスドメイン・アクセ
スが発生するためCORSの設定を行う必要がある
 設定例
mqsichangeproperties IntegrationNodeName -e IntegrationServerName -o HTTPConnector
-n corsEnabled -v true
 「参考資料:HTTP リスナーのCORSサポート」を参照
53
Swagger文書に関するIIBの制約事項
 Swagger文書はJSON形式(.json)で保存する必要がある
 Swagger文書のOperation ObjectのoperationIdフィールドにAPI内でユニ
ークな値を設定する必要がある
 同一の基本パスを持つREST APIは統合サーバー上に複数デプロイすることはで
きない
 フォーム・データ・パラメーターはSwagger文書では許容されているが、パラメータ
ーの解析処理にはIIBのサポート対象外
54
グラフィカル・データ・マッピングの
拡張
55
グラフィカル・データ・マッピングの機能強化
 IIB V10で強化されたグラフィカル・データ・マッピングの機能

anyタイプのメッセージに対して、ユーザー定義エレメントを動的に定義可能

データ・マッピングでEnvironmentツリーの追加可能

JSON メッセージのグラフィカル・データ・マッピング
56
(参考)グラフィカル・データ・マップ・エディター
 WebSphere Message BrokerのV8.0から組み込まれたグラフィカルなデータ
・マッピング・ツール
 IBMの他製品でも同様の機能を使用

IBM Integration Designer, Rational Application Developer など
 グラフィカル・データ・マップ・エディターの主な提供機能
GUIで変換の定義が可能
 GUIでデータベースの照会結果を出力メッセージに追加可能
 出力メッセージのルーティングや宛先制御を動的に設定
 データベースのデータの変更が可能(Insert, Update, delete)

57
グラフィカル・マッピング・エディターの例
①
②
①
① Input MessageとOutput
Messageを指定
② 各エレメント間をワイヤリング
③
③ 繰返し要素の場合は、For each
により繰り返し
④ さらに下位の要素をワイヤリング
④
58
ユーザー定義エレメントの追加
 IIB V10から、スキーマ無しでユーザー定義エレメントの追加が可能

XMLスキーマを持たないメッセージ・マップの構造化データに対して、ユーザー定義エレメントを
追加可能

追加できる拡張ポイント(anyエレメント)をもつリソース






LocalEnvironmentツリー
メッセージ本体
メッセージ本文内のxsd:anyエレメント
Environmentツリー
MQRFH2などのような拡張ポイントを持つ転送用ヘッダー
ユーザー定義エレメントを使用して、JSONメッセージや、xsd:anyを持つSOAPまたはXMLメ
ッセージを定義することが可能
59
ユーザー定義エレメント(JSON)の追加
 ユーザー定義エレメントの追加
JSONメッセージにユーザー定義エレメントを追加する例
 xsd:any タイプのエレメントを選択して、右ポップアップクリック・メニューから「Add UserDefined(ユーザー定義)」を選択する

60
ユーザー定義エレメント(LocalEnvironment)の追加
 LocalEnvironmentツリーのanyエレメント
①
① メッセージ・アセンブリのPropertiesをクリック
② プロパティの追加で、LocalEnvironmentをチェック
③ LocalEnvironmentが追加され、anyエレメントも存在
④ 右ポップ・アップメニューで「Add User-Defined」を選択
②
①
③
④
61
Environmentツリーの追加
 Environmentツリーをマッピング画面に追加可能
Environmentツリーが追加される
anyフィールドなので、ユーザー定義エレメ
ントを追加した上で、マッピングが可能
62
JSONメッセージのグラフィカル・マッピング
 マップ・エディターでIBM提供メッセージ・モデルとしてJSONドメインを選択可能
JSON (IBM 提供の JSON オブジェクト・メッセージ・モデル)
 JSON (IBM 提供の JSON 配列メッセージ・モデル)

①
① 新規マップの作成で、入力メッセージ、出
力メッセージで、JSONを選択
② 出力ドメインとしてJSONを選択
③ マッピング画面にJSONが追加
メッセージエレメントは、xsd:any ユーザー
定義エレメントを追加可
①
②
③
③
63
フロー・エクササイザー
64
フロー・エクササイザー
 新しいテストツール、フロー・エクササイザーを提供
メッセージが通ったパスや、任意のポイントでのメッセージ・ツリーの確認が可能
 以下の入力ノードを含むメッセージ・フローで使用可能







MQInputノード
HTTPInputノード
SOAPInputノード
FileInputノード
MQTTSubscribeノード
テストで使用したメッセージは、再テストのために保存可能
65
フロー・エクササイザーの実行手順
 フロー・エクササイザーの実行
1.
フロー・エクササイザーの開始
①「Start Flow exerciser」アイコンをクリック
②デプロイ先の統合サーバを選択
既にRecording状態の統合サーバに
リソースがデプロイされている場合は、当確
認画面なしにリソースを再デプロイ
66
フロー・エクササイザーの実行手順
③統合サーバはRecording状態になり、フローエディタは編集不可な状態になる
選択した統合サーバにはRecording状態を示
すアイコンが表示 (注:V10.0.0.1では、フロー
レベルに表示)
67
フロー・エクササイザーの実行手順
2.
テスト・メッセージの送信
 フロー・エクササイザーか外部ツール/ユーザー・アプリを使用して、テスト・メッセージを送信
 フロー・エクササイザーを使用する場合は以下のメッセージを利用可能
 新規に作成したメッセージ (MQInput、HTTPInput、SOAPInput使用時のみ利用可能)
 保管されたレコード・メッセージ
①「Send message」アイコンをクリックして、
フロー・エクササイザーからメッセージ送信
②新規にメッセージを作成する場合は、
「Input Message」を選択して、「New
message」アイコンをクリックし、新規メッセージ作
成画面で送信メッセージを作成して、「Send」
②レコード・メッセージを使用する場合は
「Recorded Messages」のリストから送信メッセ
ージを選択し「Send」
68
フロー・エクササイザーの実行手順
(新規メッセージの作成画面)
ヘッダーの編集も可能
選択したメッセージの複製
や、削除が可能
メッセージをエディタに直接入力し
たり、外部ファイルの読み込みが
可能
データ部を外部ファイルに
保管可能
メッセージを送信
69
フロー・エクササイザーの実行手順
③「Send」ボタンでメッセージを送信すると処理状況がポップアップで表示される
70
フロー・エクササイザーの実行手順
3.
実行結果の確認
 フロー・エクササイザーでメッセージを送信した場合は、メッセージの通過パスが自動的にハイライト
 外部ツール/ユーザー・アプリからメッセージを送信した場合は、「View path」アイコンをクリックしてハイライトさ
せる
メッセージが通ったパスがハ
イライトされる
ハイライトされた接続をクリ
ックすると、その時点でのメ
ッセージ・ツリーを表示
71
フロー・エクササイザーの実行手順
4.
レコードしたメッセージの保管
 入力ノードと次のノードの間のハイライトされた接続をクリックし、「Save」アイコンをクリック
 保管したメッセージは「Send message」ダイアログから再利用可能
クリック
クリック
適当な名前をつけ
て保管
保管したメッセージはApplication内のOther
Resources配下に、xmlファイルとして保管される
72
フロー・エクササイザーの実行手順
5.
フロー・エクササイザーを終了する
 すべてのレコード・メッセージは明示的に保管していなければ消去
①「Return flow to edit mode」アイコンをクリックし、 ②統合サーバを右クリック>「Stop Recording」を選択し、
フロー・エディタを編集可能な状態に戻す
recordingモードを停止
73
フロー・エクササイザーの考慮点
 考慮点

フロー・エクササイザーを使用した新規メッセージの作成機能はMQInput、HTTPInput、
SOAPInputでのみ使用可能
 MQInput使用でも以下の条件に当たる場合は、当機能は使用不可
 MQの構成定義に、ポリシーやクライアントチャネル定義テーブルを使用する場合
 フローがリモートの統合ノードにデプロイされ、MQの構成定義でローカルのキュー・マネージャーの使用を定義している場合

キャプチャしたレコード・メッセージは、以下のノードで使用可能




MQInputノード、HTTPInputノード、SOAPInputノード、FileInputノード、MQTTSubscribeノード
レコード・メッセージはInputノードでパースしたあとの論理メッセージで、編集は不可
レコード・メッセージをSendすると入力ノードで処理せずに、入力ノードのoutputターミナルに渡される
HTTPReply、SOAPReplyでは、レコード・メッセージを受け取るとReply送信の処理を省略

入力メッセージやレコード・メッセージはメッセージ・フローをプロジェクト交換ファイルにエクスポー
トしたときにフローに含まれる

入力メッセージやレコード・メッセージを他のフローにコピーすることは不可
74
フロー・エクササイザーの考慮点

複数メッセージを実行した場合、メッセージごとに通ったパスは表示されない
 ユーザーが個別に確認が必要
実行したメッセージが通ったパスがすべ
てハイライトされる

メッセージを複数流した場合、メッセージ・ツリーは異なるメッセージ・インスタンスとしてキャプチ
ャされる
 デフォルトで200メッセージ・インスタンスまで表示可能
 Windows>Preferences>Integration Development>Flow Exerciserでこの値は変更可能
 設定値を超えるメッセージがキャプチャされた場合、設定値に定義した数までのメッセージを表示するか、すべ
てのメッセージを表示するか確認のポップアップを表示
何番目に実行した
メッセージを表示
するかを選択
何件メッセージを表示するかを選択
(画面例では設定値を5に設定)
75
フロー・エクササイザーの考慮点

デバッガーとの併用は不可
 デバッガーをかけた状態で「Start Flow exerciser」を実行しても、デバッガーがONになった統合サーバはテ
ストの実行環境として選択できない
76
WebSphere ESB
コンバージョン・ツール
77
WESBからIIBへのコンバージョン
 WebSphere ESB(WESB) コンバージョン・ツールにより、サービス・コンポーネント・
モジュールの再利用が可能
 コンバージョンでは2種類の方法を検討
コンバージョン・ツールの使用によるコンバージョン
 手作業によるコンバージョン

 コンバージョン・ツールでサポートするモジュールの環境
WebSphere Integration Developer version 6.2
 WebSphere Integration Developer version 7
 IBM Integration Designer version 7.5
 IBM Integration Designer version 8

 コンバージョン・ツールは、ツールキット導入後にアドオンとして追加
ツールキットの「ヘルプ」メニューから、「新しいソフトウェアのインストール」を選択
2. リポジトリを指定して、インストールする
1.
名前
WebSphere Conversion Tool
ロケーション
http://public.dhe.ibm.com/software/integration/integrationbus/tools/wesbconvert/v10/
78
コンバージョン・ツールによるコンバージョン手順
 以下の手順でコンバージョンを実施
1.
WESBコンバージョン・ツールの起動
2.
WebSphere ESB変換セッション・ファイルの作成
 WebSphere ESB変換セッションは、拡張子が、.conversionのファイルとして、ワークスペース上に保存され
、変換選択項目や変換結果が保存される
3.
コンバージョン対象のWESBのプロジェクトを選択
4.
コンバージョン対象のWESBのリソースを選択
5.
WESB変換セッションのグローバル・プロパティーの構成
6.
「WebSphere ESBリソースの変換」ウィンドウで、「変換の開始」をクリックして、リソースを変
換
79
コンバージョン・ツールによるコンバージョン結果
 コンバージョン・ツールによる変換結果の確認画面
80
コンバージョンされたフロー例
 WESBメディエーション・フロー → IIBのメッセージ・フロー
 WESBメディエーションモジュールの各コンポーネント → IIBのサブ・フロー
WESB
メディエーション
IIB メッセージ・フロー
81
コンバージョン・ツールの制約(1/3)
 ワークスペース
IBM Integration ツールキットとIBM Integration Designer(IID)ではワークスペースを
共有不可
 コンバージョン・ツールで読み込むためには、WIDまたはIIDからプロジェクト交換ファイル形式
でエクスポートし、Integration ツールキットのインポートのWESBプロジェクト交換オプション
を使用

 プロジェクトファイル

WESBのJavaプロジェクトは、手動でコンバート
 WSDLファイル

IIBでは、Document/encodedスタイルのWSDLファイルはサポートされない
82
コンバージョン・ツールの制約(2/3)
 サービス

1 つ以上の操作と 1 つ以上のエクスポートが含まれる WESB サービスは、IIBアプリケーションに変換
 メディエーション・モジュール・コンポーネント

以下は手動での変換が必要
 実装タイプのないメディエーション・モジュール・コンポーネント
 スタンドアロン参照

1..1 の多重度設定を持つターゲット・サービスへの参照は変換
 エクスポート

以下は手動での変換が必要
 WESB の関数セレクター(WESB 変換ツールがメディエーション・モジュールをIIBのアプリケーションに変換する場合
)
 WESB のカスタム関数セレクター
 カスタム・データ・バインディング
 インポート

以下は手動での変換が必要
 複数のインターフェースを使用するインポート
 MQ、JMS、MQ JMS、汎用 JMS など、非同期バインディングを使用するインポート
 SCA (ネイティブ) バインディングを使用するインポート
 カスタム・データ・バインディング
83
コンバージョン・ツールの制約(3/3)
 メディエーション・プリミティブ

プロモートされたプロパティは、手動での変換が必要
 ビジネス・オブジェクト・マップ

BOマップは手動での変換が必要
 XMLマップ

以下の変換は、手動でのコンバージョンが必要






Lookup
Submap
Group
Custom XSLT
Custom Java
Custom XPath
IBM Integration Bus は、マッピング変換「グループ」および「ルックアップ」はサポートしない
 SMO添付エレメントに対して定義された変換は、手動でのコンバージョンが必要
 SMOコンテキスト・エレメントに対して定義された変換は、手動でのコンバージョンが必要
 SMOヘッダー・エレメントに対して定義された変換は、手動でのコンバージョンが必要

84
その他の新機能
85
その他の新機能
 JavaScript クライアントAPIの作成

既存の統合サービスにJSON/HTTPバインディングを追加する機能
 統合サービスはSOAP/HTTPのサービス提供に特化した特殊なアプリケーション
 WSDLをインポートして作成され、SOAP/HTTPバインディングを持つ

JavaScriptアプリケーションから利用可能なJavaScriptのAPIを生成
 Webサービスの操作に対応したメソッドを含むJavaScriptコードが生成

JavaScript開発者向けのWebページを生成
 JavaScriptクライアントAPIの参照
 サンプル・コードの参照
 JavaScriptクライアントAPIのダウンロード
 HTTP ノードと SOAP ノードの統合セキュリティー機能拡張

統合 Windows 認証 (IWA)のサポート
 HTTP リスナーのCORSサポート
 Tutorial/GitHub連携

チュートリアルの刷新、GitHubからサンプル・パターンの取得可能
86
Fly UP