APIソリューション・セミナー

既存システムのAPI化をワンストップで実現！〜

〜APIエコノミーとバイモーダルITに対応した最新のMQファミリーをご紹介〜

2016.10.9

2

第一部 APIエコノミー、Bi-Modal IT 時代に求められるIT基盤とは

3

概説

急変するビジネス環境

4

5

「業界の統合・融合」が重大な影響を及ぼす

レストラン

API公開候補：

口コミ収集＆提供、予約、団体対応

季節、イベントメニュー開発

旅行、ゴルフ

API公開候補：

ツアー組み立て、申し込み、支払い

オプション追加

保険

API公開候補：

商品検索、シミュレーション、申し込み

保険シェアリング、超短期旅行保険

デパート、小売ストア

API公開候補：

パーソナル・キャンペーン

ポイントでの購入（支払い）

鉄道、バス、タクシー

API公開候補： 時刻表、座席予約、チケット発券

配車、乗り継ぎ案内

人材、介護

API公開候補：

ケア住宅紹介、入居契約

ケア・マネージャ派遣予約

ケア・サービス、タクシー配車

銀行の公開API

API

API

API

API API

API

API

銀行にとっての 新たな顧客

個客

API エコノミー = テクノロジー視点でみた業界の融合

電鉄系企業のパートナー連携ユースケース

6

なぜAPIに取り組むのか

Systems of Recordを安全に開放する

モバイル、IoT、クラウドへアプリや

データを提供

ブランド

イメージの向上

革新的なパートナーとの連係

新たな

ビジネスの実現

データやアルゴリズムを収益化

アプリ開発

スピードの向上

セルフ・サービスのライブラリや再

利用可能なAPI

7

デジタルIT： アプリケーション開発速度はますます加速しています

高速なアプリケーション開発を実現するために、APIとして公開された外部サービス部品を組み合わせるコンポジット・アプリケーション開発スタイルが広まっています。

DB+分析 IoT

モバイル セキュリティ

連携 DevOps

Watson

画像解析

音声認識

トレードオフ

性格解析

翻訳

Twilio

プッシュ 通知

品質管理

モバイル SDK

モバイル セキュリティ

モバイル アクセス

オートスケール

New Relic

監視

アジャイル

JMeter

Ustream

ビジネウ プロセス

キャッシュ

MQ Light

セッション キャッシュ

ワークフロー

スケジューラ

RabbitMQ

Sendgrid

エンタープライズ 固定IP

API管理

オンプレ 連携

Hadoop

Spark

Cloudant NoSQL

DWH

ElasticSearch

Geo

Twitter

MongoDB

PostgreSQL

Redis

脆弱性 分析

SSO

IoT ウェブアプリ

8

Bi-Modal ITの問題

9

エンタープライズIT

安定性・信頼性、運用最適化 サービスレベル重視 長期に渡るシステム開発

デジタルIT

システムの継続的な改善 マイクロ・サービス クラウド

ガートナーのレポートによると、テクノロジー関連費用のうち、38％がIT部門以外の事業部門から支出となっており、2017年にはその割合は50%が超えると予想されています。

迅速に新サービスを投入するためには社内ITへの迅速なアクセスが必要

コスト削減の圧力の中、更なる短納期を実現するのは困難

API：Bi-Modal ITに対する現実解

10

②APIとして 公開する

④“革新的”な アイデアをアプリ化

①既存 エンタープライズ

IT資産を

③開発者が セルフ・サービスで

利用できるようになり

セルフ・サービス化によって 新規アプリケーション用の連携IF準備の手間を大幅に低減しながら 業務部門の求めるスピードで既存IT資産へのアクセスを提供可能に

APIの利用シーンは外部連係に限定されません

Public Protected Private

公開範囲 一般公開 限定公開 非公開

API対象者 一般の開発者 ビジネス・パートナー 自社内開発者

想定される

アプリ利用者 消費者向け

消費者向け、または

法人向け 従業員向け

目的

外部リソースを活用したイノベーションの

実現

プロセスの自動化やEDI、新規パートナー協業の立ち上げ負荷

低減

生産性向上や、チャネル間の情報共有、内部からの改革の推進

ユースケース例

営業店の位置情報、預金や住宅ローン金利、プレスリリース

口座集約サービスへの残高情報提供、企業間でのデータ連携

社内タブレットアプリでの利用、情報系・勘定系情報の統合

11

開発者ポータルから新たな連携をセルフ・サービスで利用可能になる

システムへのアクセス状況の可視化・管理が容易になる

社内外サービスが一貫した方法で再利用可能となり、アプリケーション開発のスピードが上がる

既存IFをAPIとして整理することのメリット

12

企業内システム API ネットワーク

アプリケーション

社内開発 コミュニティ パートナー

コミュニティ

一般開発者 コミュニティ

APIを公開したい！

API利用者ごとに API利用可否を

適切に制御したい

APIの開発・保守を 低コスト・短期間で行いたい

誰がいつどれだけAPIを 利用しているか把握したい

安全にAPI公開したい

API利用者向けの ガイド方法が分からない

API公開に伴って発生する周辺課題

13

API化に必要なこと

14

AP

I G

ate

wa

y

API

API

REST/JSON

API Portal

API

外部

アプリ開発者

クライアント

アプリ

社内 取引先

IoT

モバイル

Web

Web Service

IBM z

ESB B2B

SaaS

API管理 インテグレーション

デジタルITをサポートするAPIアーキテクチャ

外部

アプリ開発者

社内 取引先

クライアントアプリ

IoT

モバイル

Web

B2B

SaaS

API Gateway

Data Power Micro Gateway

開発者ポータル

APIマネージャー

公開API

-ポリシー管理 -利用分析

-API仕様の開示 -APIキーの管理

-APIを保護・制御 -高度なｾｷｭﾘﾃｨｰ

内部API Compute -APIの実行

公開API

IBM Integration Bus

API Connect

-多様なバック エンドのAPI化

内部API Web

Service

IBM z

15

（空白ページ）

16

17

IBMの提供するソリューション

（空白ページ）

18

19

外部

アプリ開発者

社内 取引先

クライアントアプリ

IoT

モバイル

Web

B2B

SaaS

開発者ポータル

APIマネージャー

-ポリシー管理 -利用分析

-API仕様の開示 -APIキーの管理

IBM Integration Bus

API Connect

内部API

バックエンド・システム

API Gateway

-既存システム間連携の仲介

-既存IFのAPI化

公開API 既存IF

-セキュリティ -トラフィック制御

DataPower

・IBM Integration Bus ・IBM API Connect

IBMの提供するソリューション

IBM Integration Busの実績

20

アメリカの大規模小売業で採用

世界の大手通信サービス会社が採用

23 25

90% 世界のクレジット・カードのトランザクションで利用

20 社

世界で最大手の保険会社が採用

世界の航空券予約システムで利用

21 / 25

54 60

80%

/ 世界で最大手の銀行が採用

/

高い信頼性と多数の実績

対応システム：メインフレーム、UNIX/Linux, ERP, データベース等

対応プロトコル：Webサービス/REST/ファイル/データベース/TCP/メール/ MQTT/CORBA/MQFTE/C:D等

対応データ形式：固定長、可変長、文字列、バイナリー

幅広いシステム間の連携を実現

金融決済や銀行の勘定系接続や半導体工場の製造制御等、高い可用性が求められる連携で多数の実績

国内200社以上海外3000社以上

高パフォーマンス/拡張性

使いやすくシンプルな製品構成

少ないコア数で連携処理が可能なためSW費用、HW費用、運用費を低く抑えることが可能

DBMSやアプリケーション・サーバー等前提製品の導入が不要

開発ツールとランタイムの導入は数分で完了

単一の開発ツールで構成・開発・デプロイ・テストが完結

IIBの役割 ・メディエーション（仲介）

①プロトコル変換 ②データ・フォーマット変換 ③ルーティング

その他システム共通の関心毎 - ロギング・監査証跡 - 認証・認可 - 流量制御 - 開閉塞管理 等

IBM Integration Busは広範な連携要件に対応する、IBMの戦略的システム統合製品

多様なシステム間の間にハブとして配置され、異なるプロトコル、データ形式、制御の違いを吸収

IBM Integration Bus(IIB)

21

IBM Integration Busの歩み

’08 ’99 ’00 ’01 ’02 ’03 ’04 ’05 ’06 ’07 ’09 ’10 ’11 ’12 ’13 ’15 ’14

V2.0 ノードを組み合わせた フロー開発 V2.0.1 各種ノードの提供 ESQLのサポート DBアクセス Pub/Sub、XMLメッセージ V2.0.2 コントロールセンターの日本語化

MQSeries Integrator (MQSI)

WebSphere MQ Integrator (WMQI)

WebSphere Business Integration Message Broker （WBIMB）

WebSphere

Message Broker

（IIB）

V1.0 ルールエンジン

V2.1 TDSメッセージ ESQLの拡張 デバッガーの提供

V5 ツールキット （Eclipseベース） デプロイの変更 Webサービスサポート 高速Pub/Sub

V6 Javaノード Webサービス強化 パーサー拡張 タイマーノード ESQL機能拡張

V6.1 Webサービス強化 ファイル機能 コレクター・ノード WSRRとの連携 SOAPノード EIS接続 (SAP、Siebel etc.)

2002.1 2003.6 2005.10 2007.11

V7 シンプルな構成 パターンの提供 インパクト分析 MBXによる管理の統合 マルチインスタンスQmgr への対応ブローカー SCA ノード MQ Pub-sub の統合

2009.11

V1.0 V2.0 V2.1 V5.0 V6.0 V6.1 V7.0 V8.0 2011.12

V8 .NETサポートの追加 Express Edition追加 フロー作成API提供 DFDLサポート ブラウザによる管理 Record & Replay

V9.0 2013.7

IBM

Integration

Bus

V9 BRMSの統合 ポリシーベースの 負荷管理機能 BPMとの連携強化

V10 2015.3

V10 柔軟なMQ構成 MQTT用ノード 導入の簡素化 ブラウザ管理画面 の機能強化 GUIマッピング の機能強化

MQ

MQSI MQ

MQ

MQ

MQ

MQ

MQ

MQ

MQ

MQ

MQ

MQ

WMB

MF RDB ERP …

Webサービス

Java .NET

IIB MQ

MQ

MQ

MQ

MQ

MQ

MF RDB ERP

Analytics Business Rule

Webサービス

Java .NET

EAI/HUB ESB ESB

22

IoT

IIB 製品全体像

コンポーネント サポート・プラットフォーム

実行環境（統合ノード） AIX、HP-UX、Linux(x86、x86-64、POWER System、System z)、Solaris(x86-64、SPARC)、Windows(x86-64)、z/OS

開発ツール (Integration Toolkit) Windows(x86-64)、Linux(x86, x86-64)

稼動プラットフォーム

開発・管理環境

IBM Integration Toolkit • Web管理画面 • Java API • REST API • WAS管理コンソール・プラグイン • コマンド・ツール他

23

IBM MQ（IIBに付属）

ランタイム環境

JVM CLR

統合フロー データ・モデル

メッセージ・フロー

Devices

Web 2.0

Applicati

ons

Files

ERP/EIS /CRM

MQ, JMS, MSMQ

IIBの特長: 多様なプロトコル対応

WebSphere MQ (エンタープライズ・メッセージング)

サードパーティのJMS (TIBCO EMS, Sonic MQ, BEA JMS, webMethods, See Beyond, Vitria)

HTTP およびHTTP(S)

TCP/IP ソケット

FTP およびファイル

SMTP

SAP

PeopleSoft

Siebel

CICS

Loopback Connector

SCA (IBM BPM Advanced)

WSRR (WebSphere Service Registry and Repository )

Webサービス(SOAP/HTTP,SOAP/JMS)

IMS POP3/IMAP

CORBA

MQMFT (MQ Managed File Transfer)

Connect:Direct (グローバル標準のファイル転送)

ODBC/JDBC (DB2, Oracle, Sybase,

MS SQL Server等)

IBMプロトコル 標準プロトコル

エンタープライズ・アプリケーション

MQTT

24

IIBがサポートする多様なプロトコルはノードと呼ばれるメッセージ・フロー内に配置可能な部品で抽象化

IIBの特徴：多様なデータ形式に対応

25

<order>

<name>

<first>John</first>

<last>Smith</last>

</name>

<item>Graphics Card</item>

<quantity>32</quantity>

<price>200</price>

<date>2007-11-14</date>

</order>

Order

Name Item Qty Price Date

First Last

Physical Logical

XM

L

{“order”:

{“name”:

{“first”:”John”,

“last”:”Smith”},

“item”:”Graphics Card”,

“quantity”:32,

“price”:200,

“date”:”2007-11-14”}}

JSO

N

John,Smith,Graphics Card,

32,200,07/11/14 CSV

John Smith............

Graphics Card.........

3220020071114......... CB

L

その他独自形式

アプリケーションとIIBがやり取りするデータ → 様々な形式がある

メッセージ・フローで扱われるデータ → 物理形式表現を排除

XMLパーサー

JSONパーサー

DFDLパーサー

多様な形式のメッセージ同士を変換するため、IIBはメッセージをパースし論理形式でメモリー内に展開

非標準データ形式のための強力なパーサー：DFDLパーサー DFDL形式で定義されたデータのレイアウト情報を参照しながら多様なタ形式のデータをパース/シリアライズ

DFDL DFDL DFDL (レイアウト定義）

参照

DFDL(Data Format Description Language)

XML Schema 1.0をベースにした、非XMLデータの標準モデリング言語 XMLスキーマを固定長やタグ区切り文字などの非XMLデータ・フォーマットを扱うように拡張した規格

テキスト、バイナリー、可変長、固定長等、多様なデータ形式のデータをモデル化

DFDL のメッセージ・モデルを準備する方法

COBOLのコピー句やCのヘッダーファイルをインポートして生成

ウィザード/DFDLエディターにより作成

GitHubから入手

• HL7

• ISO8583

• IBM 4690-TLOG 等

26

Cヘッダー

WSDL XML スキーマ

COBOL

コピー句

各種メタ･データ

ウィザード

メッセージ・モデル

生成

生成

生成

GitHubからダウンロード

IIBが提供する変換インターフェース

強力な変換を迅速に記述 SQL ベースの言語

(ESQL) を使用 RDBMSに加え、メッセージ・

ツリーに対してもクエリー

任意のJava コードを実行可能 XpathやDOMに似たAPIでメッ

セージ・ツリーにアクセス JAXBでメッセージ・ツリーとJava

オブジェクトの間のバインディングも可能

スクリプティング

C#、VB、F#、C++/CLI、Jscript など

における変換を作成。 共通言語ランタイム

(CLR) に対応。

マップ元/マップ先をワイヤリング

必要に応じてマップの際に関数を実行可能

カスタムの関数を作成可能 GUIによるデータベースアク

セスも可

メッセージ変換、ルーティング等、メッセージに対するロジックの記述に複数の選択肢を提供

Java GUIマッピング .NET

高い開発生産性

既存Javaコードの再利用

直感的な開発 Microsoft 製品との 高い親和性

※Windows版のみで提供

27

IIBの機能例

28

IIB Node 1 IIB Node 2

Cache.Value = 42;

Cache.Value = 42; MyVar = Cache.Value;

v7 v8

v9

v10

パターン

メッセージの記録と再生

グローバル・キャッシュ

バージョン間の互換性

Chefによる運用自動化

フェール・オーバー機能

流量制限

統計機能

4半期ごとの継続的な機能追加・機能強化

誰でもダウンロード可能な継続的なOpen Beta

IBM Integration Bus V10以降の新機能

29

IIB v10.0.0.1

Q2 2015

IIB v10.0.0.0

Q1 2015

Single Package install Built in Unit Test

MQ Flexibility Shared Libraries

GDM Schemaless maps REST APIs

MQTT Connector

IIB v10.0.0.2

Q3 2015 Global Cache upgrade to WXSv8.6

GDM access to Global Cache REST API integration with APIm

CICS 2 Phase Commit TCPIP report properties enhancements

WESB conversion enhancements

IIB v10.0.0.3

Q4 2015

Business Transaction Monitoring CICS 2 Phase Commit on zOS Oracle stored proc in GDM Linux Power 8 Little Endian

(RHEL7.1, Ubuntu14.0.0.4, SLES12)

Open Beta

IIB v10.0.0.4

Q1 2016 Callable Flows for linking to IIBoC

Create a REST API without Swagger JSON Schema support for GDM

Salesforce Request node LDAP Authentication Web UI Activity Log

SLESv12 (x86 and Z Systems)

Maintenance only

IIB v10.0.0.5

Q2 2016 MQTT SSL and dynamic config

Bulk Push to API Connect Callable Flows report properties

IIB v10.0.0.6

REST Request node Loopback Request node JSON data in Graphical mapping

IIBのREST API機能強化の変遷

FixPackレベルごとのREST API関連の機能強化

30

バージョン 追加機能

10.0.0.0 Swagger文書をインポートしてREST APIサービスを提供する「REST APIアプリケーション」を追加

10.0.0.2 IIBで開発したREST APIアプリケーションをツールキットからAPI ConnectにPushする機能を追加

10.0.0.4 Integration ToolkitでAPI定義を作成する機能を追加 REST API操作をMapping ノードで実装可能

10.0.0.5 IIBで開発したREST APIアプリケーションをAPI Connectに対しWeb UIまたはmqsipushapisコマンドを使用してPushする機能を追加

10.0.0.6 Swagger文書に基づいて外部REST APIを呼び出す機能が追加。マッシュアップが可能に

IIB V10 REST API 連携機能

31

REST APIの記述の標準仕様 Swagger 2.0に対応したREST APIエディター機能を搭載 Swagger文書をインポートしてREST API公開のためのプロジェクトを生成

新規にREST APIエディターでSwagger文書を定義することも可能

Swagger文書として保存される

Toolkit上で定義/インポートしたAPI定義からフローの雛形が自動生成

既存連携インターフェースをノンコーディングでJSON形式に変換

IIB V10 REST API 連携機能

REST API定義から生成されたフローに既存MQインターフェースを呼び出す連携を実装

COBOLコピー句からインポートして作成した固定長のメッセージ・モデル

Swagger文書のJSONスキーマで定義されたモデル

IIB V10 REST API 連携機能

33

IIBサーバー上にデプロイしたREST APIは API ConnectにPushすることが可能

IIBにデプロイされたAPIをツールキット上で選択して右クリックしてPush

PushされたAPIはAPI Connect上で 即座に利用可能に

Web管理画面上のAPI

34

IIBサーバー上にデプロイしたREST APIはIIBのWeb管理画面で表示・管理可能 API仕様の確認とSwagger文書のダウンロード

API ConnectへのAPIのPush

IBM Integration BusでAPI化する理由

多種多様な既存業務システムのAPI化に利用可能 MQ, CICS, IMS, SAP, TCP/IP, RDB, File…

API化を一元的に行う基盤を担うことのできる信頼性 15年以上にわたりミッション・クリティカルなシステム連携を支えてきた実績

API化の費用と時間を節約 システム連携に特化したツールを活用することで高い開発生産性を享受可能

継続的な投資と安定したロードマップ IBM Integration Busは高い市場シェアを持つIBMの戦略的投資分野

35

IBM Integration Bus：開発者版

36

37

外部

アプリ開発者

社内 取引先

クライアントアプリ

IoT

モバイル

Web

B2B

SaaS

開発者ポータル

APIマネージャー

-ポリシー管理 -利用分析

-API仕様の開示 -APIキーの管理

IBM Integration Bus

API Connect

内部API

バックエンド・システム

API Gateway

-既存システム間連携の仲介

-既存IFのAPI化

公開API 既存IF

-セキュリティ -トラフィック制御

DataPower

・IBM Integration Bus ・IBM API Connect

IBMの提供するソリューション

IBM API Connect概要

IBM API Connect はAPI公開の課題を解決する包括的なAPI基盤ソリューション

APIの開発・保守コストを削減し、

公開までの期間を短縮

APIアクセスの

利用状況分析、トレンド把握 公開したAPIを手間なく利用してもらう

セルフ・サービス化の仕組み

APIにより連携の

セキュリティーを確保できる

API利用企業・開発者ごとの

アクセス管理と流量制御

ソリューション

APIの開発・保守を 低コスト・短期間で行いたい

誰がいつどれだけAPIを利用 しているか把握したい

API利用者向けのガイド方法が 分からない

安全にAPI公開したい

API利用者ごとにAPI利用可否を 適切に制御したい

1

2

3

4

5

API化に向けての課題

パブリック・クラウド

オンプレミス

LoopBackフレームワークにより、各種データベースのコネクターを利用して、ノンコーディングで簡単にAPIを自動作成。テスト・ビルド・デプロイも容易。

数分でAPIをノンコーディングで開発

管理者向けのAPIマネージャーは直感的で使いやすく、API公開の設定や分析機能もすぐに利用可能。カスタマイズ可能な開発者ポータルも標準機能で提供。

少ないコンポーネントでシンプルな構成

シンプルな構成で、クラスター構成やスケーラビリティーを確保。別途追加でAPサーバーやDBサーバーの構築・運用は不要なので運用維持コストも少ない。

強固なセキュリティー 仕様を標準サポート

長年に渡り国内外多くのお客様でWebサービスを保護してきた実績を持つDataPowerを活用。 より安全な仕組みをアプライアンスですぐに利用可能。

クラウドからオンプレ まで柔軟な提供形態

オンプレミスやIaaSの専用環境やBluemix Public、専用環境のBluemix Dedicated上のSaaSサービスを用途に応じて豊富な選択肢から選択可能。

特長

簡単な操作でAPI公開分析や開発者ポータルもすぐに使える

38

IBM API Connect概要

API基盤を支える各コンポーネント

API マネージャー

開発者 ポータル

APIゲートウェイ API

デザイナー

APIプロバイダーに必要な機能を提供

アプリ開発者向けの APIリファレンスとAPIキー発行管理

安全で高性能なAPIゲートウェイ

高速でアジャイルなAPI実装

シンプルで高機能なツールとランタイムが、API基盤を最適化します。

開発者ポータル

仮想アプライアンス

APIマネージャー

WAS Liberty Collective Controller

APIゲ

ート

ウェイ

API

Node.js

アプリ開発者

クライアント・アプリ

IoT

モバイル

Web B2B

SaaS

APIサービス

デジタルITをサポートするAPIアーキテクチャー

(Developer Toolkit）

有償

IBMサポートあり

ﾏｲｸﾛ･ｹﾞｰﾄｳｪｲ/ DataPowerｹﾞｰﾄｳｪｲ

Professional+α

無償

サポートなし

ﾏｲｸﾛ･ｹﾞｰﾄｳｪｲ

基本機能

有償

IBMサポートあり

ﾏｲｸﾛ･ｹﾞｰﾄｳｪｲ

Essentials+α

3段階のエディション

Professional Enterprise Essentials

開発者向け 単一プロジェクト向け 大規模プロジェクト向け

○サポート

○費用

○ｹﾞｰﾄｳｪｲ

○機能

APIコール数 5万回/月 500万回/月 2500万回/月

APIコール数

永久ライセンス（CPU能力とコア数による課金）

5万回/月 無制限 無制限

Professional Enterprise Essentials

2つの課金モデル

サブスクリプション（利用量に応じた月額課金）

39

API Connectが提供するセキュリティー

IBM API Connectは、API Gatewayとして業界最高水準のセキュリティー・ゲートウェイである、DataPower Gatewayを採用しています。DataPower Gatewayは、幅広いセキュリティー仕様を標準サポートしている強固なアプライアンスです。

IBM API Connectは、DataPower Gatewayのセキュリティー機能を最大限に活用できるとともに、追加でAPI基盤として必要となる高度なセキュリティー機能を容易に実現することが可能なアーキテクチャーです。

40

API Connectとして提供されているセキュリティー機能

• 基本認証(LDAP、認証URL)によるAPIの認証 • OAuth 2.0による認可 • APIキー(クライアントID)&シークレットによるアプリ認証 • SSL/TLSによる暗号化 • APIキーおよびシークレットの発行機能 • DeveloperごとのAPIの可視化制御 • APIごとのアクセス制御と柔軟なレート制限 • APIアクセス履歴の取得

IBM DataPower Gatewayのセキュリティー機能 • 認証、ユーザーアクセス制御 • シングル・サインオン • 電子署名/検証 • リバースプロキシー、SSL/TLS暗号・復号、PKI • OAuth 2.0 準拠・認可フォームのカスタマイズ • OAuth 2.0 外部認証のサポート • SAML/XACML/WS-*/JWT/RADIUS • OpenID Connect/SPNEGO/Kerberos • 業界標準に基づいたアクセス管理 • サードパーティ製認証システムとの連携 • メッセージのフィールドレベルの暗号/復号 • 不正 XML/JSON による脅威からの防御 • XML、JSON、SOAPメッセージの構造の妥当性の高速検査 • コンテンツ・ベースの流量制御 • 監査ログ出力 • メッセージ・コンテンツ・フィルタリング • 署名、暗号化されたファームウェア • Internet Content Adaptation Protocol (ICAP) • FIPS 140-2 への準拠とCommonCriteria 認定 • FIPS 140-2 Level 3準拠とCommonCriteria認定(*) • 開封検知(*) (*) 物理アプライアンスのみの機能

アクセス管理と流量制御

APIキーによるアクセス制御と流量制御 開発者ポータルではアプリケーション開発者がセルフ・サービスでAPI利用登録

利用登録はプランとよばれる単位で行われ、呼出し可能数等、利用条件の異なる複数のプランが提供可能

利用申請完了時にAPIを利用するアプリケーションの識別情報（APIキー）が発行

API ConnectはAPI要求に付加されたAPIキーの情報を基にアプリケーションごとにプランに応じた呼び出し回数に制限したり、必要に応じて特定のアプリケーションからの要求を拒否するなどの制御を行うことが可能

41

APIキー（クライアントID）の発行例 プランの選択画面例

プランの選択ボタン

APIキー （クライアントID）

利用可能なプラン

開発者ポータルのプラン登録画面

開発者は利用条件の異なる複数のプランから条件にあうものを登録

API利用登録時に発行されるAPIキー

クライアント・アプリ

IoT

モバイル

Web B2B

SaaS

API ゲートウェイ

API 内部API

APIマネージャー

②APIゲートウェイを通過するAPIトラフィックの情報は、APIマネージャーに非同期で送信される

分析

データ

API利用状況の把握

APIキーの情報を基にアプリケーションごとのAPIを呼び出し状況を分析するダッシュボード機能

収集した分析データをAPI利用課金の基礎情報として利用可能

API管理者

分析ダッシュボード表示例

③蓄積された分析データを 分析ダッシュボード上で分析

⑤分析データは、APIを利用してデータとしてエクスポート可能

④ダッシュボード上の元データは、CSVデータとしてエクスポートすることが可能

①事前登録されたプランに基づいてAPIの呼び出し回数をコントロール

42

ブランド・イメージに合わせた画面のカスタマイズ シンプルな操作で柔軟性の高いカスタマイズ

柔軟な認証方式 外部開発者 ： gmailアカウントで認証

社内開発者 ： 社内SSO基盤で認証

プランへのアプリケーション登録 開発者にセルフ・サービスのAPI利用申請を提供

（利用開始前に承認を行う設定も可能）

APIキーの発行

開発者サポート フォーラム機能による開発者コミュニティーの醸成

問題報告のためのサポート・チケットを発行機能

ブログ機能による開発者向けの情報発信

サンプル・コードの表示とAPIのテスト

開発者ポータル

43

- APIの仕様 - プランの表示・選択 - FAQの表示

ブログ機能 フォーラム機能 サポート機能（チケット発行）

言語ごとのサンプルコード （cURL、Ruby、Python、PHP、Java、Node、Go、Swift）

APIのテスト実行

開発者ポータル画面例

リクエスト・レスポンスのサンプル表示

IBM API Connectの価値

API公開の課題をワンストップで解決 IBMの長年の経験からのベスト・プラクティスを組込み

APIライフサイクル (設計, 開発, 公開, 管理) をカバーする包括ソリューション

バージョニングやトラフィック制御などのポリシーを適用可能

自由にカスタマイズ可能なポータル

ハイブリッド・クラウドに対応したオープンかつセキュアなAPI基盤 Open API Initiativeを始め、API標準への積極的な関与と機能拡張

2200以上のお客様での導入実績を持つAPIゲートウェイ (DataPower) の提供

メインフレームを含めた多様なバックエンドを接続するIBM Integration Busとの親和性

エンタープライズ・クラスの高度な要求にも対応 ビジネス規模に応じてスケール可能するアーキテクチャと価格体系

共有SaaS、占有SaaS、オンプレミスまで豊富な形態から柔軟に選択可能

IBMの中核製品としての安定したロードマップ

44

IBM Application Integration Suite

45

IBM Application Integration Suite

IIBの最上位エディションに位置づけられる IIBからのトレード・アップライセンスも提供

API公開に必要な製品をワンストップで提供 IBM Integration Bus ： 広範な既存業務インターフェースをAPI化

API Connect : API公開に必要なセキュリティ、開発者管理、アプリ管理、トラフィック制御等のAPI管理機能を提供 ※API ConnectはProfessional版となり、DataPowerは同梱されない

Salesforceとの連携用の部品も利用可能

46

外部

アプリ開発者

社内 取引先

クライアントアプリ

IoT

モバイル

Web

B2B

SaaS

開発者ポータル

APIマネージャー

-ポリシー管理 -利用分析

-API仕様の開示 -APIキーの管理

IBM Integration Bus

API Connect

内部API

バックエンド・システム（オンライン）

Microgateway -API Gateway

-既存システム間連携の仲介

-既存IFのAPI化

-セキュリティ -トラフィック制御

公開API

IBM Application Integration Suite

既存IF

API公開に必要となるコンポーネントは複数の製品の組合せで入手可能 IBM Application Integration Suite

IBM DataPower Gateway

各コンポーネントの責務と製品のカバー範囲

47

開発者ポータル APIマネージャー

-API ポリシー管理 -利用分析

-API仕様の開示 -APIキーの管理

Micro Gateway

IBM DataPower Gateway

IBM Integration Bus

API Gateway

IBM Application Integration Suite

API Connect Professional / Essential

API Connect Enterprise

ESB

IBM Integration Bus

IBM DataPower Gateway

- 高度な認証・認可 - DMZに配置可能なセキュリティ - トラフィック制御 - APIのアセンブル

- 認証・認可 - API利用分析 - API ポリシーの執行 - APIのパススルー

IB

Mの提供する製品・オファリング

機能コンポーネント

- 既存IFのAPI化 - メディエーション

Micro Gatewayの機能に加えて

（空白ページ）

48

IBM API製品採用事例のご紹介

49

2016年3月25日発表

API接続によって残高照会や入出金明細照会などの銀行機能を提供するサービスを開始 第一弾として、株式会社マネーフォワードが提供するサービスとのAPI接続を開始

住信SBIネット銀行プレスリリース「API接続サービスの開始および株式会社マネーフォワードとの公式連携開始について」(https://www.netbk.co.jp/wpl/NBGate/i900500CT/PD/corp_news_20160325)より抜粋

提携先企業にログインID・パスワードを 預ける必要がない

認証基盤（Oauth2.0準拠）による認証

IBM API Connectを活用し、よりセキュアな接続サービスを実現

IBM API Connectの活用により、 セキュアかつ容易にAPIを公開 アクセス制御や利用状況の分析も可能

API Connect活用事例「住信SBIネット銀行様」

50

製造業のお客様 IBM Application Integration Suiteを採用

企業内連携基盤の強化に加え、将来の事業拡大を見据えた API 公開やクラウドとの連携に基盤を整備

CICS / IMS / Z

DMZ

他社SaaS

Apps

Data

Process

SAP/PeopleSoft Adapter

SOAP/HTTP

ODBC/JDBC

MQ / JMS

Legacy File

M&A先 外部サービス

社内開発者

社外開発者

パートナー

REST/HTTP

SOAP/HTTP SOAP/HTTP

MQ

File

MQLight/AMQP

REST/HTTP

SOAP/HTTP

MQLight/AMQP

REST/HTTP

SOAP/HTTP

AP

I

Con

nect

Data

Pow

er

Gate

way

In

teg

ratio

n B

us

①社内システム連携基盤強化 グローバル展開やM&Aに伴う連携増に対し、変更・追加開発の工数と期間の短縮

②将来を見据えた連携基盤 取引先や社外との連携増加を想定し、API公開やクラウド連携を検討

選定理由： • パフォーマンス –実機検証で実証

• ハイブリッドクラウドへの対応力 – API 公開・クラウド連携・ゲートウェイ

• 豊富な実績 – 多くの実績を持つ製品によって構成された 信頼性の高いオファリング

51

期待できる効果： • システム連携に関わる工数、コストの大幅削減 • 新ビジネスや新業務の迅速な展開 • 外部サービスの活用が促進でき、システム開発の

効率化が実現

第一部：まとめ

Bi-Modal IT問題の観点からの既存業務のAPI化のメリット システムの利用状況が管理でき安全性と保守性が向上する

既存システムへのアクセス要望への対応を手間なく迅速に行える

API化におけるミドルウェアを活用した基盤の価値 API基盤の実現を迅速化することができる

技術の変化に対応をミドルウェアに任せることができる

API化も含めたシステム連携/統合の分野はIBMの注力分野 継続的な投資により最新技術動向をリード

ロードマップの安定性

52

53

第二部 基盤システムエンジニアのための

API公開第一歩

54

IIBのREST APIサポート

IIB V10 REST API 連携機能概要

55

IIBにおけるREST APIサポート REST API連携機能を強化し、既存システムの業務をAPIとしてより簡単に公開可能に

REST API連携用の「REST APIアプリケーション」を追加 Swagger文書をインポートしてREST APIサービスを提供

スクラッチからREST APIアプリケーションを生成することも可能 （Swagger文書なしに新規作成）

外部RESTサービスを呼び出すREST Requestノードを追加 同期呼び出し（REST Request）、非同期呼び出し（REST AsyncRequest/REST AsyncResponse）の

両方をサポート

ApplicationでSwaggerを追加サポート

JSONデータをGUI（Graphical Mapping）でマッピング可能に REST APIのオペレーションの実装をMappingノードで定義可能

API Connectとの連携をサポート API Connectとの連携により、APIの管理やAPI呼び出しの制御を実現

API ConnectへのREST API定義のPush機能を提供

IIB V10 REST API 連携機能概要

56

IIBにおけるREST APIサポートの技術要素 REST API

REST APIアプリケーション

REST APIエディター

RESTノード

Swagger

JSON

セキュリティ対応

REST API

57

APIは相対パスによって識別される複数のリソースを含む

各リソースは複数を操作を含み、HTTPメソッドに関連づけられる

各操作はHTTPボディの情報に加えてパラメーターを持つことができる 1) パス・パラメーター URLのパスの一部として設定される

2) クエリー・パラメーター key=valueの形式でパスの後に設定される

3) ヘッダー・パラメーター HTTP要求のヘッダーとして設定される

4) フォーム・パラメーター

相対パス 意味

/customers データベース内の全ての顧客情報

/customers/12345 顧客番号12345の顧客情報

/customers/12345/orders 顧客番号12345の全ての注文情報

/customers/12345/orders/67890 顧客番号12345の注文#67890

リソースの例

API

PUT GET DELETE

POST GET

/customerdb/v1

/customers

/customers{customerId)

基本パス

リソースと 相対パス

HTTPメソッド 操作

GET getCustomer

PUT updateCustomer

DELETE deleteCustomer

リソース/customer/{customerId}に対する操作の例

/customers/12345/orders/56789

/customers?min=5&max=20 例

Api-Client-Id : ff6e2c5d-42d5-4026-8f7f-d1e56da7f777 例

例

REST APIアプリケーション

REST APIアプリケーション IIB V10において、REST API実装に特化した「アプリケーション」が追加

REST API公開を簡単に行う方法を提供

REST APIの開発手法は2種類 ToolkitでスクラッチからREST APIを作成 Toolkitに統合されたREST APIエディターでリソース、モデル、操作などを定義し、Swagger文書を作成

Swagger初心者にもわかりやすいインターフェースを提供

既存のSwagger文書をインポートしてREST APIを作成 外部エディターを使用してSwagger文書を作成

インポート可能なSwagger文書の形式には制約がある（参照：「Swagger文書に関するIIBの制約事項」）

Swagger仕様に精通した人や、IIB開発者とは別のAPI設計担当者がSwagger文書を定義する場合に適する

58

REST APIエディター

REST APIエディターを使用してAPIを実装 REST API記述をダブルクリックで開き、定義の確認や設定を実施 IIBでスクラッチからREST API開発する場合は、REST API記述の各セクションを順次定義していく

Swagger定義をインポートした場合は、REST API記述で定義内容を確認し、必要に応じて修正

REST API記述の主な定義項目 「Header」セクションでREST APIに関する一般情報を設定

「Resources」セクションでREST APIの操作を定義

「Model Definitions」セクションで操作の要求・応答のスキーマ・タイプに使用できるJSONデータを定義

「Error Handling」でエラー・ハンドラーを定義

「Security」セクションでHTTPSを設定

59

REST API記述

外部のREST API呼び出しのためのRESTノードを提供 同期呼び出し、非同期呼び出しの用途に合わせて、以下の3つのノードを提供 RESTRequest ノード

RESTAsyncRequest ノード

RESTAsyncResponse ノード

Swagger文書を利用してRESTノードを構成 同期呼び出しの場合は、以下の方法でRESTRequestノードを構成 REST APIカタログから呼び出したいオペレーションを、メッセージ・フロー・エディターにドラッグ＆ドロップ

パレットからRESTRequestノードをメッセージ・フロー・エディターにドラッグ＆ドロップ

使用するSwagger文書の選択方法を指定

非同期呼び出しの場合は、パレットからRESTAsyncRequestノード、RESTAsyncReponseノードを追加 RESTAsyncRequestノードで使用するSwagger文書の選択方法を指定

RESTノード

60

REST呼び出し MQ呼び出し

IIB 既存システム RESTサービス

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文書を生成

61

http://swagger.io/

（参考）Swagger文書の例

62

{ "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" } } } } } },

(右へ続く）

（左からの続き） "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" } } } } }

JSONスキーマでAPI内で利用されるオブジェクトを定義

APIの情報の定義 - ホスト名 - スキーマ（HTTP/HTTPS等）

- 基本パス - Content-type 等

リソースとURLの定義

操作の定義

swagger.jsonの例（抜粋）

JSON

JavaScript Object Notation (JSON) RFC 4627で規定される軽量なデータ記述言語

JavaScriptに限定したものではなく、様々なプログラミング言語で使用可能

JSONメッセージの構造は以下の2タイプ オブジェクト

名前と値のペア

配列

値のリスト

オブジェクトと配列の組み合わせ、ネストも可能

IIBではJSONパーサー/ドメインを提供 提供はV7.0.0.2 から

HTTPノードに限らず、様々な入出力ノードで利用可能

Mappingノードにて、JSONスキーマ/Swagger文書を基にJSONメッセージのマッピングが可能 メッセージ･マップからJSONスキーマ/Swagger文書を選択し、マッピングを構成

JSONスキーマによる妥当性検査は未サポート

63

{"name": "John Smith", "age": 33}

["milk", "bread", "eggs"]

セキュリティ対応

REST API アプリケーションでは以下のセキュリティ対応をサポート HTTPSサポート REST APIでも従来通り、HTTPS通信をサポート

Basic認証 REST APIアプリケーションがリクエストを受信したタイミングでクライアントとの間でBasic認証を行う

ユーザー認証は、各種認証プロバイダーとの連携が可能

LDAP、WS-Trust V1.3準拠STS、TFIMなど

CORS対応 他のドメインでホストされたコンテンツへのアクセスをブラウザに許可するための規格であるCross-Origin Resource

Sharing(CORS)に対応

64

RESTのサービスでよく利用されるOAuthやOpenID Connectといった認証認可の仕組み（認可サーバーとしての機能）はIIBでは未サポート。 通常は、フロントにゲートウェイ製品（IBM API ConnectやIBM DataPower Gatewayなど）を配置し、そのコンポーネットによって対応する

Webページ

WebサーバーA HTTPリクエスト

HTTPレスポンス w/Webページ

IIB

http://domainA/index.html

https://domainB/content

CORS対応

65

REST API開発の流れ

REST APIアプリケーション開発の流れ

REST APIアプリケーションの開発の流れ

66

REST APIアプリケーションの作成

1-1.REST APIアプリケーションを新規に作成 1-2.Swagger文書をインポートして作成 事前にSwagger文書を準備

REST API記述にリソース、モデル、操作の追加

REST APIの操作の実装 サブフローで操作を実装

エラー・ハンドリングの実装

1

2

3

4

実行環境へのデプロイ 5

外部ツールを利用したテストの実施 6

1.REST APIアプリケーションの作成

REST APIアプリケーションを新規に作成する場合 ツールキットでスクラッチからのREST APIを作成

「New」→「start by creating a REST API」からREST APIウィザードを起動 REST APIアプリケーション名をセットし、「Create a REST API and define resources and operations

yourself」を選択

RESTアプリケーションと空のREST API記述が作成される

67

ウィザードを完了するとREST APIエディターが起動 空のREST API記述が表示されるので、ここで定義を追加していく

1.REST APIアプリケーションの作成

Swagger文書をインポートして作成する場合 Swagger文書が事前にある場合は、インポートしてREST APIを作成 Swagger V2.0の制約に準拠し、IIBの制約にかからないことを事前に確認

「New」→「start by creating a REST API」からREST APIウィザードを起動 「Import resources and operations defined in a Swagger document」を選択し、Swagger文書を指

定

68

1.REST APIアプリケーションの作成

69

JSONドキュメント（Swagger文書）に定義されたREST操作がサマリーとして表示される

インポートを完了するとREST APIエディターが起動 インポートしたSwagger文書に定義された操作やリソースの定義を確認/実装が可能

Swagger文書に関するIIBの制約事項

Swagger文書はJSON形式（.json）、またはYAML形式（.yaml/.yml）で保存する必要がある

Swagger文書のOperation ObjectのoperationIdフィールドにAPI内でユニークな値を設定する必要がある

同一の基本パスを持つREST APIは統合サーバー上に複数デプロイすることはできない

フォーム・データ・パラメーターはSwagger文書では許容されているが、パラメーターの解析処理にはIIBのサポート対象外

JSONスキーマの”$ref”は、内部ファイル参照でのみサポートされる

70

REST APIエディターで、REST APIを定義 HeaderセクションではREST APIの概要情報を定義 「REST API base URL」はREST APIの基本パス

REST APIのタイトルやバージョンの設定値はAPI ConnectへのPUSHの際に利用

ResourcesセクションではREST APIのリソースとそれに対する操作を定義 スクラッチから作成した場合は空定義。「Create a new resource」からリソースと操作を定義

Swagger文書から生成した場合も、リソースの追加/削除が可能

2.リソース、モデル、操作の追加

71

リソースと操作の追加 Resourcesセクションの （Create a new resource）からリソースを追加

2.リソース、モデル、操作の追加

72

リソース・パスとリソースに追加する操作を選択

Resourcesに追加した操作に対し、入力パラメーターや要求/応答メッセージの定義などを追加 パラメーターの追加

照会パラメーターとヘッダー・パラメーターは ボタンで追加/削除可能

パス・パラメーターはリソース・パス指定時に定義し、あとから名前やパラメーター・タイプの変更は不可

パラメーターのデータ・タイプやフォーマット、必須指定の定義はIIBでは妥当性チェックされない

要求/応答の追加

HTTPのステータス・コードに応じて複数の応答を定義可能

2.リソース、モデル、操作の追加

73

モデルの追加 「Model Definitions」セクションでJSONデータのモデルを定義 データタイプ、array、必須、ヌル許可、フォーマットを定義

操作の要求、応答の「Schema type」で定義したモデルを指定

2.リソース、モデル、操作の追加

74

「Model Definitions」セクションでJSONデータのモデルを定義

定義したモデルを「Resources」セクションの要求/応答定義の「Schema type」で指定

操作はサブフローとして実装 実装する操作の「Create a subflow for the operation」アイコンをクリックすると、サブフロー実装用

のメッセージ・フロー・エディターが起動

通常のフロー開発と同じ要領でノードを追加していく

実装していないオペレーションをクライアントが呼び出すと「HTTP 501 Not Implemented」が返される

3.操作の実装

75

REST API呼び出し時にLocal Environmentにセットされる情報

3.操作の実装

76

IF InputLocalEnvironment.REST.Input.Method = 'GET' THEN -- Executed only if the current operation was called using an HTTP GET. END IF; DECLARE logMessagePath CHARACTER 'Received request on path ' || InputLocalEnvironment.REST.Input.Path;

(0x01000000:Name):REST = ( (0x01000000:Name):Input = ( (0x03000000:NameValue):Method = ‘GET’ (CHARACTER) (0x03000000:NameValue):Operation = 'getYen' (CHARACTER) (0x03000000:NameValue):Path = ‘/Exchangeraterest/v1/yen’ (CHARACTER) (0x03000000:NameValue):URI = 'http://localhost:7800/Exchangeraterest/v1/yen' (CHARACTER) (0x01000000:Name ):Parameters = ( (0x03000000:NameValue):amount = '100' (CHARACTER) (0x03000000:NameValue):currency = 'USD' (CHARACTER) )

LocalEnvironment内の情報にアクセスするESQL例

LocalEnvironment.REST.Input 用途

Method リクエスターから呼び出したREST APIのメソッド

Operation リクエスターから呼び出したREST APIの操作

Path REST APIの呼び出しパス

URI REST APIの呼び出しURI

Parameters REST API呼び出し時にセットした呼び出しパラメーター セットしたパラメーターがこの子ツリーとして生成される

LocalEnvironment.RESTの例

グラフィカル・マッピングを使用してREST API操作の実装も可能 マップ作成時に「message map with input and output for REST API operation」オプション

を指定 REST API記述内のJSONスキーマ定義を元に入出力データがセットされる

Local Environmentがマップに自動的に追加される

3.操作の実装（グラフィカル・マッピング）

77

マップ入出力のメッセージ本体もREST API記述から自動的にセットされる 入力メッセージ Swagger文書で操作に対してリクエストとして定義されたJSON

操作のリクエスト定義にデータ部がない場合はBLOB

出力メッセージ HTTP Status 200の応答として定義されたJSON（Status 200の定義がない場合、デフォルトの応答または1つ目

の応答定義）

操作の応答定義にデータ部がない場合はBLOB

78

入力はデータ本体がないためBLOB

出力はREST API定義から取得したJSONスキーマ定義

画面例）

3.操作の実装（グラフィカル・マッピング）

REST API記述にないJSONデータをマップに使用する場合は、マップに自動セットされたメッセージ・アセンブリーを削除して、定義を追加 利用するJSONスキーマ定義は利用するREST APIプロジェクトまたは共有ライブラリー内にファイルがあることが前提

マップ作成後にパラメーターやデータ定義をREST API記述を変更すると、次回マップ起動時に変更が取り込まれる 既存の変換定義が無効になる可能性があるため、マップの定義の見直しが必要

新たにデータ定義を追加する場合は、マップの再作成が必要

79

3.操作の実装（グラフィカル・マッピング）

4.エラーハンドリングの実装

REST API記述の「Error Handling」でエラー処理を実装

3つのタイプのエラー・ハンドラーを提供

エラー・ハンドラーもサブフローとして実装 エラー・ハンドラーを実装しない場合、以下のデフォルトの動作となる （例）CatchやFailureを実装しないと、エラー発生時に 「HTTP 500 Internal Server Error」が返される

（例）Timeoutを実装しないと、タイムアウト発生時に「HTTP 504 Gateway Timeout」が返される

80

ハンドラーの種類 説明

Catch 操作のサブフローでの処理時に例外がスローされ、その例外がサブフロー内でキャッチされない場合に、ルーティングされる

Timeout 操作のサブフローが予期される時間内（180秒）にクライアントに応答を返さない場合に、ルーティングされる Timeoutエラー・ハンドラーがクライアントに要求タイムアウトの旨を通知。 ただし、サブフローの処理がキャンセルされるわけではない

Failure クライアントからの要求処理中にエラーが発生し、CatchやTimeoutのエラー・ハンドラーで処理されないケースでルーティングされる

4.エラーハンドリングの実装

REST API記述の「Error Handling」セクションのリンクをクリックして各ハンドラーを実装

81

ハンドラーを実装すると、リンクの名称が「Open ・・・」に変わる

通常のフロー開発と同様にノードを配置してエラー処理を実装

IIBのREST API開発の考慮点

REST APIの定義はREST API記述を編集 REST API記述をメッセージ・フローとして確認することもできるが（.msgflowファイルも作成される）、

編集は不可

REST APIの操作やエラー・ハンドラーはサブフローとして実装 REST API記述から編集用のリンクをクリックすることでフロー・エディターが起動

通常のフロー開発と同様に、サブフローを定義

82

5.実行環境へのデプロイ

通常のアプリケーションと同様にBARファイルを生成し、デプロイ

注意点 複数のREST APIを統合サーバーにデプロイする場合は異なる基本パスを指定する必要がある

83

デプロイするREST API定義を選択し、「Build and Save…」

5.実行環境へのデプロイ

デプロイしたREST APITをWeb UIからの確認 呼び出すためのURLや、呼び出し可能な操作が確認可能

84

どの操作が実装済みで、利用可能なのかを確認可能 RESTアプリケーションの「API」で

操作の一覧が表示される

呼び出しURLとREST API定義のURLが表示

6.テストの実施

RESTの送受信が行える外部テストツールを利用してREST APIのテストを実施

SwaggerUIを使用する例

85

WebUIで確認した REST API定義のURLをセット

テストする操作を開き、必要なパラメーターをセットして「Try it out!」を実行

6.テストの実施

86

確認可能な項目 ・実行したCurlコマンド ・リクエストURL ・応答電文 ・レスポンス・コード ・応答ヘッダー

87

IIBとAPI Connectの連携

API公開の流れ

88

APIConnectにおけるロールとAPI公開の流れ API開発者 APIを開発

API製品管理者 APIのテスト、ステージング、公開

→ 「IIBからREST API Push」により、上記ステップの一部(外部公開のためのAPI定義の拡張、プランの作成、ステージング)を実現

IIBでREST APIを開発してPUSH

IIBでの作業 APICでの作業

IIBからAPI Connectへの連携

IIBにデプロイされているREST APIをAPI Connectに対してPushし、API Connect経由によるAPI外部公開を容易に実現

IIBからAPI ConnectへのPush API ConnectへのPush方法は3つ

1. Webユーザーインターフェースを使用して1つ以上のAPIをデプロイ

2. mqsipushapisコマンドを使用して1つ以上のAPIをデプロイ

3. IBM Integration Toolkitを使用して、単体のAPIをデプロイ

Toolkitを使用した場合は、API作成まで実施

Web UIやコマンドを使用した場合、製品も作成され、ステージングの有無も選択可能 ステージングしたい場合は、対象のカタログ(サンドボックスが前提)を指定

Push時には事前に統合サーバーにREST APIをデプロイ済みであることが前提

Push後にAPI Connect側でセキュリティ要件の追加や、製品の作成、APIの追加/修正、ステージング、公開を実施

89

Web UIを使用したAPI Push

WebユーザーインターフェースからREST APIをPush

90

統合サーバーのメニューから「Push REST APIs to IBM API Connect」を選択 API Connectの接続情報や

ユーザー情報を設定

X.XX.XX.XX

Web UIを使用したAPI Push

91

組織の選択、タイトル、名前、バージョンの指定、ステージングする場合は、カタログを選択

PushするAPIを選択して「Push to IBM API Connect」

Pushされると、API Connect上に、API、製品が作成され、さらにカタログ「Sandbox」にステージングされた旨のメッセージが表示される

コマンドを使用したAPI Push

IIBコンソールで、mqsipushapisコマンドを実行して、REST APIをPush コマンドのパラメーター等については以下を参照

http://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/bn28900_.htm

92

mqsipushapis integrationNodeSpec -e integrationServerName -t apiConnectHost -g apiConnectPort -u apiConnectUser -a apiConnectPassword -o apiConnectOrganization

C:¥Program Files¥IBM¥IIB¥10.0.0.6>mqsipushapis IIB10006 -e EG01 -t 9.XX.XX.XXX -g 443 -u XXXX@jp.ibm.com -a passw0rd -o "Naomi's Provider Org" -c Sandbox -r DemoAPI -d DemoAPI -s 1.0.1 -k DemoAPI BIP9357I: Successfully replaced API 'DemoAPI' in IBM API Connect. BIP9358I: Successfully created Product 'DemoAPI' and added API 'DemoAPI' to it in IBM API Connect. BIP9360I: Successfully staged Product 'DemoAPI' to Catalog 'Sandbox' for Organization 'Naomi's Provider Org' in IBM API Connect. BIP8071I: コマンドが完了しました。

コマンド例

コマンド実行例

ツールキットを使用したAPI Push

ツールキットからREST APIをPush

93

統合サーバーにデプロイされたREST API（DemoAPI)を右クリック→「Push to IBM API Connect」

API Connectの接続情報や、ユーザーID/パスワードを設定

94

Push対象となる組織を選択し、Finishをクリックすると、APIがPushされ、API Connectに定義が作成される

ツールキットを使用したAPI Push

95

デモ

IIBで作成したREST APIをAPICにPushするステップをご説明

API Connectとの連携デモ

96

IIBでの作業

IIBでREST APIを開発してPUSH

APICでの作業

使用する環境

デモ環境のご説明

97

DMZ Trusted Zone 実行環境

開発環境

外部

アプリ開発者

社内 取引先

API開発者

クライアントアプリ

IoT

モバイル

Web

B2B

SaaS

- LoopBack - マイクロGateway - CLI

API Gateway

Data Power Micro Gateway

開発者ポータル

APIマネージャー

Developer Toolkit

公開API

API デザイナー

-ポリシー管理 -利用分析

-API仕様の開示 -APIキーの管理

-APIを保護・制御 -高度なｾｷｭﾘﾃｨｰ

内部API Compute -APIの実行

公開API

IBM Integration Bus

API Connect

-APIの実行

内部API

サーバー環境

PC環境

REST APIのプロバイダーとなるメッセージ・フローを開発 IIBが既存MQアプリケーションのAPI Wrapperとして動作

98

IIBメッセージ・フローのシナリオ

MQ/固定長で連携

IIB

RESTクライアント

既存システム

111111 (社員番号)

Ise Hanako ISE.OpenMiddleware (社員名、所属組織)

社員情報照会システム

メッセージ・フロー

REST/JSONで連携

HTTP 受信

変換 MQPUT

HTTP 応答

変換 MQGET

Swagger UI を利用

HTTP GETのPathパラメーター

{ "EmployeeInfo": { "EmployeeName": “ISE Hanako", "Organization": "ISE.OpenMiddleware" }}

MQアプリケーション

プロトコル変換 フォーマット変換

99

IIBメッセージ・フローの開発の流れ

1. REST API アプリケーションの作成

2. 既存システムと連携するための、メッセージ・モデルの準備

3. リソースの定義

4. モデルの定義

5. 操作の定義

6. 実行環境へのデプロイ

7. テストの実施

8. API ConnectへのPush

（空白ページ）

100

101

API ConnectによるAPI公開

IIBで作成したAPIをAPI Connectで公開する際の機能と手順について説明

IIBとAPI Connectの連携

102

DMZ Trusted Zone 実行環境

開発環境

外部

アプリ開発者

社内 取引先

API開発者

クライアントアプリ

IoT

モバイル

Web

B2B

SaaS

- LoopBack - マイクロGateway - CLI

API Gateway

Data Power Micro Gateway

開発者ポータル

APIマネージャー

Developer Toolkit

公開API

API デザイナー

-ポリシー管理 -利用分析

-API仕様の開示 -APIキーの管理

-APIを保護・制御 -高度なｾｷｭﾘﾃｨｰ

内部API Compute -APIの実行

公開API

IBM Integration Bus

API Connect

-APIの実行

内部API

103

API Connectの機能

API仕様の定義

公開するAPI仕様を定義する方法 APIマネージャーの「ドラフト」メニューの「API」タブで定義 GUIでスクラッチから定義

WSDLのインポート

Swagger（OpenAPI）文書のインポート

IIBからPush IIB上で定義されていたインターフェース仕様がそのまま引き継がれて設定される

仕様はSwagger文書のYAML形式で確認可能 「ソース」タブにて表示

API仕様の追加設定やカスタマイズが可能 「設計」タブにて設定

（例） 認証

基本認証

OAuth

APIキー

HTTPS

パス

メソッド

パラメーター

要求/応答メッセージのフォーマット

自動生成

Swagger2.0記述

WSDL

import

import

サービス・ レジストリー

discovery

ソース（YAML）

API追加メニュー

APIマネージャーの「ドラフト」メニューの「設計」タブ

push IIB

104

製品化とレート制限

製品 APIをパッケージングしてステージング・公開する単位（APIは複数の製品に所属可能）

開発者ポータル上での可視性（参照・利用させるアプリ開発者）を指定する

プラン 製品の中に最低1つがデフォルトで作成され、複数のプランを製品の中に定義できる

プランの中に含めるAPIとレート制限を指定

アプリ開発者が利用登録（配信登録）する単位

レート制限 レート制限はプランの中で指定可能

プラン全体、個々のAPIの操作の両レベルで柔軟に指定可能

105

製品（顧客サービス）

プランの設定例

ライトプラン

API

ベーシックプラン

API API API API

製品 ←レート制限

←レート制限

アクセス制御と流量制御

アプリケーション単位でのAPIへのアクセス制御と流量制御が可能

設定方法 あらかじめプロバイダー側で、製品、プランを作成しておく

各アプリケーションにAPIキーを発行する

プランに対して各アプリケーションのサブスクライブを設定する 利用できるAPI（パス）の種類とレート制限（単位時間あたりの利用回数）はプランへのサブスクライブにより決定

APIキーの発行とプランへのサブスクライブの設定方法 開発者ポータルからアプリケーション開発者が実施、または、APIマネージャーからAPI管理者が実施

106

アプリA

アプリB

アプリD

アプリC

プラチナプラン : レート制限 100回/分

ゴールドプラン : レート制限 50回/分

レギュラープラン : レート制限 10回/分

API-A

API-B

API-A

API-A

API-B

API-C

レート制限 : 100回/分

レート制限 : 100回/分

レート制限 : 50回/分

レート制限 : 50回/分

レート制限 : 50回/分

レート制限 : 10回/分

サブスクライブ状況

サブスクライブ状況

サブスクライブ状況

アプリA

アプリB

アプリC

アプリD

APIキー AAAA

APIキー BBBB

APIキー CCCC

APIキー DDDD

API提供側 API利用側

API提供側

変換と処理のカスタマイズ

ゲートウェイで実施する処理をカスタマイズできる機能 APIマネージャーの「ドラフト」メニューの「API」タブから該当APIを選択し、「アセンブル」タブにて設定

最低限バックエンドのAPIサービスの呼び出しを設定する

追加で必要な処理を柔軟に追加できる（メッセージ変換、XML-JSON変換、処理分岐など）

独自の処理をユーザー定義ポリシーとして作成・利用することも可能 サンプルのユーザー定義ポリシーはGitHubからダウンロードして再利用可能

107

パレット（ビルトイン・ポリシー）

キャンバス

アセンブリー・フロー プロパティー・シート

ドラッグ&ドロップで配置

各ポリシーをクリックして 詳細を指定

アセンブル機能

外部APIの呼び出し XML/JSONメッセージ変換 XML,JSONデータのValidation レスポンス変換 変数変換（マッピング） 変数の取得・生成 エラー制御 複数APIのマッシュアップ レスポンス・キャッシング エラーレスポンスのカスタマイズ 複数のAPIと連携してマッシュアップ JavaScript実行 XSLT実行 プロトコル変換 分析ログ出力内容変更 Operation-switch If Throw

アセンブル機能の例

ライフサイクル管理とバージョン管理

API Connectでは、製品とAPIのバージョン管理機能を提供 APIと製品それぞれにバージョンを持ち、APIはバージョンを指定して製品に含める

APIを修正した場合は新しいバージョンのAPIとして定義し、新しいバージョンの製品に含めて公開できる

古いバージョンの製品の公開を停止したい場合 サブスクライブしているアプリ開発者に事前通知を行ったうえで、新しいバージョンの製品にサブスクリプショ

ンのマイグレーションを強制的に行える

108

製品A V1

API-A V1

API-B V1

API-C V1

アプリA プラン

製品A V1

API-A V1

API-B V1

API-C V1

アプリA プラン

製品A V2

API-A V2

API-B V1

API-C V1

アプリB プラン

製品A V1

API-A V1

API-B V1

API-C V1

アプリA プラン

製品A V2

API-A V2

API-B V1

API-C V1

アプリB プラン

初期状態

API-AをバージョンアップしてV2としたので、製品AのV2として公開

数週間後 数ヵ月後

あるタイミングで製品AのV１の公開を停止したい場合、アプリ開発者に事前通知した上で、新しいバージョンの製品にサブスクリプションのマイグレーションを強制的に行える

開発者ポータル

APIを利用するアプリケーション開発者向けのポータル機能

主な提供機能 API仕様表示、サンプルコード表示、テストツール、アプリケーション登録・管理、クライアントIDの発行・管理、分析、ブ

ログ、フォーラム、レーティング、ソーシャル連携

カタログ（製品を公開するスペース）単位で開発者ポータルの有効/無効を指定可能（デフォルトは無効）

開発者ポータルのLook & Feelは柔軟にカスタマイズ可能

独自の開発者ポータルを作成するためのAPIも提供

109

- APIの仕様 - プランの表示・選択 - FAQの表示

ブログ機能 フォーラム機能 サポート機能（チケット発行）

言語ごとのサンプルコード （cURL、Ruby、Python、PHP、Java、Node、Go、Swift）

APIのテスト実行

APIキー（クライアントID）の発行例

開発者ポータル画面例

プランの選択画面例

プランの選択ボタン

APIキー （クライアントID）

利用可能なプラン

リクエスト・レスポンスのサンプル表示

分析機能

APIの利用状況の分析機能 APIゲートウェイを通過するAPIトラフィックの情報は、APIマネージャーに非同期で送信

され分析データとして蓄積される

課金のベースとなるデータ取得や、APIのトレンド分析が可能

ダッシュボード画面 蓄積された分析データを、APIマネージャーのダッシュボード上で分析可能

デフォルトのフィルター定義の中から選択するとダッシュボードに表示される

表示するフィルター定義を自由に定義可能

レイアウトや大きさをカスタマイズ可能

分析データの保存 分析データは、APIを利用してエクスポート可能

110

分析ダッシュボード表示例

API管理者 クライアント・アプリ

IoT

モバイル

Web B2B

SaaS

API ゲートウェイ

API 内部API

APIマネージャー

①APIゲートウェイを通過するAPIトラフィックの情報は、APIマネージャーに非同期で送信される

②蓄積された分析データを、分析ダッシュボード上で分析することが可能

③分析データは、APIを利用してデータとしてエクスポート可能

分析 データ

111

API Connectによる API公開ステップ

API公開の流れ

112

APIConnectにおけるロールとAPI公開の流れ API開発者 APIを開発

API製品管理者 APIのテスト、ステージング、公開

→ 「IIBからREST API Push」により、上記ステップの一部(外部公開のためのAPI定義の拡張、プランの作成、ステージング)を実現

IIBでREST APIを開発してPUSH

IIBでの作業 APICでの作業

API記述の作成

APIマネージャーからPushされたAPIの設定を確認する IIBからPushすると、APIマネージャー上で自動的にAPI定義が作成されているので確認する

APIマネージャーの「ドラフト」メニューの「API」タブから該当APIを選択し、 「設計」タブで定義

追加で必要な設定やカスタマイズを行う 認証の追加や、パスの変更・追加、パラメーターや要求・応答メッセージのフォーマット変更など

113

PushされたAPIの名前をクリックして詳細を表示し、追加で必要な設定やカスタマイズを実施

API記述の作成

バックエンドのAPIを呼び出す設定を「アセンブル」タブで確認 正しいURLが入力されていることを確認する

追加で必要な処理があれば追加する（メッセージ変換、XML-JSON変換、処理分岐など）

114

アセンブルでは、Proxyが実装されているので、URLの内容を確認

製品、プランの作成

APIマネージャーの「ドラフト」メニューの「製品」タブで設定

IIBのWeb UIやコマンドからPushする場合は、製品の作成とステージングまで行うこともできる

製品がすでに作成されている場合は、既存の製品の設定の確認・編集を行い、製品がない場合は新たに製品を作成する

プランをカスタマイズして、プランに含めるAPIを変えたり、レート制限の設定を行う

115

プランに含めるAPIを変えたり、レート制限の設定を行う

APIテスト

APIマネージャー上でAPIのテストを実施可能 APIマネージャーの「ドラフト」メニューの「API」タブから該当APIを選択し、 「アセンブル」タブの ボタン

からテスト画面を表示

116

テスト画面を表示

カタログやAPIが含まれる製品名を確認して「次へ」

操作やパラメーターを確認して「呼び出し」をクリックするとAPIのテスト呼び出しが行える

製品のステージング

APIマネージャーの「ドラフト」メニューの「製品」タブから該当の製品を選択 右上の ボタンをクリックすると、ステージング先のカタログが表示される

ステージングするカタログ（デフォルトでは「Sandbox」）を選択してステージングを実行

ステージングが完了すると、メッセージが上部に表示される

117

該当の製品をクリック ステージング

ステージングが完了するとメッセージが表示される

製品の公開

APIマネージャーの「ダッシュボード」メニューから、該当のカタログ（デフォルトでは「Sandbox」）を選択すると、そのカタログ上の製品一覧が表示される

製品をクリックすると、その製品に含まれるAPIとプラン、プランにサブスクライブしているサブスクライバー（アプリケーション）の数などが表示される

ステージングした製品の状態は「ステージング済み」というステータスとなっているので、右の ボタンから公開を選択して公開する

118

該当の製品をクリック するとその製品の情報が表示される

「ステージング済み」のステータスになっている

公開をクリック

開発者ポータル上での表示制御とサブスクライブできるアプリ開発者について指定をし 「公開」をクリック

公開が完了するとメッセージが表示される

開発者ポータルからの利用

アプリ開発者は開発者ポータルにログインして、APIキーの発行、プランへのサブスクライブ、APIのテスト実行などを実施可能 「アプリケーション」メニューから、アプリケーションを登録すると、APIキー（クライアントID）とシークレットが

自動発行される

「API製品」メニューから製品名を選択し、プランへのサブスクライブが可能

119

アプリケーションの登録を行うと、APIキー（クライアントID）とシークレットが発行される

プランへのサブスクライブは、プランの一覧から、「配信登録」をクリック

登録しているアプリケーションが表示されるので、チェックを入れて「配信登録」をクリック

APIのテスト実行が可能

（空白ページ）

120

121

デモ

IIBで作成したREST APIをAPI Connectを利用して公開するステップについて説明

API Connectとの連携デモ

122

IIBでの作業 APICでの作業

IIBでREST APIを開発してPUSH

使用する環境

デモ環境のご説明

123

DMZ Trusted Zone 実行環境

開発環境

外部

アプリ開発者

社内 取引先

API開発者

クライアントアプリ

IoT

モバイル

Web

B2B

SaaS

- LoopBack - マイクロGateway - CLI

API Gateway

Data Power Micro Gateway

開発者ポータル

APIマネージャー

Developer Toolkit

公開API

API デザイナー

-ポリシー管理 -利用分析

-API仕様の開示 -APIキーの管理

-APIを保護・制御 -高度なｾｷｭﾘﾃｨｰ

内部API Compute -APIの実行

公開API

IBM Integration Bus

API Connect

-APIの実行

内部API

サーバー環境

PC環境

API公開までの流れ

1. API記述の作成（確認）

2. 製品、プランの作成

3. APIテスト

4. 製品のステージング

5. 製品の公開

6. 開発者ポータルからの利用

124