特別寄稿 ｜ 箕手 幸広
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
ISE アセット企画
コンサルティングITスペシャリスト
････････
2017年ころから、アプリケーションのクラウド・ネイティブへの移行が注目されている。これまでは、クラウドでの利用を前提にしたSNSや軽量アプリケーションが主体であった。しかしここに来て、企業が大量に所有する基幹システムがそのターゲットになりつつある。これらの基幹システムはそもそもクラウド環境を想定しておらず、その移行にはクラウド・ネイティブという観点でのさまざまな検討・対策が必要である。
IBM iもこの流れと無縁ではないが、一気にクラウド化するのはあくまで理想論である。複雑な基幹システムは今のまま残しつつ、段階的にクラウドへの移行を進めていくのが現実解であろう。
ただしその場合、既存の基幹システムとの連携が必要となる。そこで本稿では、IBM i上の基幹システムとクラウドとの典型的な連携パターンを解説する。さらにクラウド連携で必要となるJSONとILE RPGとの関連性についても説明し、クラウドへのRPGの関わり方について考察していこう。
クラウドと基幹システムの
連携パターン
まずは、システム連携パターンについて解説する。システム連携というと難しく捉えがちであるが、基本的な考え方は昔と変わらない。
大きく分けると、以下のようになる。
1 データ連携（参照値渡し）
2 データ一括連携（参照値群渡し）
3 非同期データ連携（キュー渡し）
4 レガシーデータ連携（DB参照）
クラウド時代でも、この考え方で連携を考えればよい。ただし今回はそれに加えて、「連携先の基幹システムをどのように捉えるか」を考える必要がある。つまり基幹システム寄りに連携を考えるか、クラウド寄りに連携を考えるかである。
この観点から連携パターンを描くと、図表1、図表2のようになる。ここでは、図表1がクラウド中心であり、AI、アナリティクス、マシンラーニング（機械学習）などクラウドと親和性の高い業務での活用が考えられる。一方、図表2は基幹業務中心であり、IoTや基幹業務と密接につながることが想定される。
それでは簡単に、各連携パターンについて見ていこう。
データ連携（参照値渡し）
データ連携は図表1の上に示すとおり、最も多用される連携パターンである。古くはPCMLを活用したIBM iプログラムの呼び出しが利用されていたが、クラウドになってからは、PCMLをラップして呼び出せるREST callが提供されている。
このREST callは、「IBM Integrated Web Services for i」で利用できる。ツールそのものはIBM i OSに含まれているので、IBM iユーザーであれば誰でも利用できる。
連携データとしては、クラウド側で処理しやすいJSON形式が妥当である。JSON形式のデータについては、本稿の最後にILE RPGでどのように扱えるかを説明するので、ここでは詳しく触れない。JSONはXMLの派生形式データ表現であり、エンコーディングがUTF-8に限定され、データ構造を表現できると理解しておけばよい。
この連携方式のメリットは、IBM i側のRPGで実装されている複雑な業務ロジックを、RESTというWebでメジャーかつ疎結合な形で取り込める点である。デメリットとしては、連携データの交換に際してJSONデータへの変換が必要となることで、その部分をどのように扱うかが課題になる（この解決策については後述する）。
この方式では、クラウド上にある対話形式のアプリケーション（入力業務、チャットボットなど）で逐次、基幹データの参照・更新などを高速に処理するケースが想定される。筆者もこの方式が最も活用されると考え、当社のチームでサンプルアプリケーションの構築法を含めた情報を公開しているので、興味があれば参考にしてほしい（参考サイト①）。
参考サイト① IBM i ILE RPG cloud integration sample with IBM Cloud
データ一括連携（参照値群渡し）
データ一括連携は、図表1の下に示すとおりである。前述したデータ連携が対話形式を想定しているのに対し、この連携方式ではバッチインターフェースによる大量データの連携を想定している。
アナリティクスや機械学習などでは大量データが必要とされるので、そのデータは一括で受け渡すのが効率的である。この場合、テキストデータやCSVファイルなどが想定され、DBのデータをそのまま渡すのはクラウド側の処理効率からいっても適切ではない。
つまりIBM i側、すなわちRPGのほうでクラウド側が処理しやすい形式に一括処理するのが望ましい。とくに連携データをJSON形式で設定しておけば、クラウド側での処理コストや開発コストを低減できる。この方式では、生成されたJSONデータなどのデータ群を、SFTPなどでクラウド側に転送して取り込むと考えればよい。
メリットとしては、必要とされる大量かつ複雑な基幹データの処理をRPGに任せることで、クラウド側ではその結果のみを処理すればよい点が挙げられる。またデメリットとしては、RPG側では、クラウドで扱いやすいJSON形式のデータへ処理する方法が煩雑である点が指摘できる。
当然ながらRPG ⅢではJSON形式のデータを扱えず、RPG Ⅳでも直接処理できる命令セットは存在しない。しかしILE RPG（RPG Ⅳ）のモジュラー化の手法により、JSONを処理できるモジュールを作成すれば、システムで共有・利用できる。
JSONデータを出力する方法は複数あるが、ILE RPGでJSONデータを取り扱うためのライブラリーモジュールがオープンソースとして公開されており、利用が可能である。ここでは詳細に触れないが、参考サイト②にURLを紹介するので、ぜひ参照してほしい。
ここまでがクラウド中心の連携方式である。キーとなるのは、RPGでJSONデータを扱えるようにすることである。
さらに以下で、基幹システム寄りのデータ連携方式を見ていこう。
非同期データ連携（キュー渡し）
図表2の上に示すとおり、キュー経由でのデータ連携は、基幹システム間連携でも多用されている。基幹システムに従事しているユーザーであれば、馴染み深い連携方式であろう。
これまでクラウドでは基幹と連携できるキュー（IBM MQなどのチャネルサービス）が一般的ではなく、利用しづらい状況にあった。しかし2018年に入ってから、試験サービスではあるが、「IBM MQ on Cloud」などと呼ばれるサービスの利用環境が徐々に整いつつある。
キュー経由での非同期データ連携は今後、基幹連携で一定の需要が見込める方式と考えられている。メリットは、基幹システムで活用例の多い連携方式であり、採用しやすいこと。デメリットとしては、MQサービスの構築に一定の作業工数を要する点、クラウド側でのサービスがまだ出揃っていない点などが挙げられる。いずれにせよ、クラウド側での今後の対応状況を注視する必要があるだろう。
レガシーデータ連携（DB参照）
図表2の下に示すとおり、この連携はクラウドアプリケーションからダイレクトに基幹のDBMSにアクセスする。基幹アプリケーションには基本的に影響を与えないので、一見すると望ましい形に思えるかもしれない。しかしクラウド側で処理ロジックやアクセス方式をすべてサポートする必要があり、軽量かつシンプルを信条とするクラウドアプリケーションにとっては荷が重いと言えるだろう。
Javaなどで作成されている基幹システムをクラウド上に一部、もしくは全体を移設する際に利用する連携であると理解してほしい。メリットは前述したとおり、既存の基幹システムへの影響を最小化できることである。デメリットとしては、基幹システムの複雑さがクラウドに持ち込まれることになり、クラウドならではのメリットを享受しにくくなることが挙げられる。
JSONとILE RPGとの関連性
以上、クラウドを想定した場合の連携パターンを解説した。詳細な解説や派生パターンについては誌面の都合上省略しているが、クラウドとの連携システムを考える際の参考になるので、概念設計などのコンセプト作成時に活用してほしい。IBM i上のRPGで作成されている基幹システムでも連携パターンは明確であり、現時点で実装可能であることが理解できたかと思う。
最後に、JSONとILE RPGの関連性について少し述べたい。
前述したように、JSONはJavaScriptなどで利用されているXMLライクなデータ形式である。XMLライクとはいうものの、XMLよりも取り扱いが簡単で、平易な表現形式であり、とくにクラウドアプリケーションでは多く用いられている。
JASONでは以下のように、名称と値の組み合わせでデータを表現する。
････････
“name1” : value_1,
“name2” : value_2, …
“namen” : value_n
････････
さらにこの形式の応用として、データ構造を表現できる。サンプルとしては、以下のようになる。
････････
{
“employees” : [
{ “firstName”:”一郎”,
“lastName”:”山田” },
{ “firstName”:”花子”,
“lastName”:”山田” },
{ “firstName”:”たけし”,
“lastName”:”北野” }
]}
････････
RPGに慣れたユーザーであれば、これはどこかで見た覚えがあるだろう。そう、データ構造（DS）によく似た表示形式である。ちなみにDSは、ILE RPGで表現すると以下のようになる。
････････
dcl-ds employees Dim(3) Qualified;
firstName Char(n);
lastname Char(n);
end-ds;
････････
RPGでデータ構造が理解できているならば、JSON形式のデータも直感的に理解できるだろう。JSONとはいえ、データ形式はDSと同じであると考えればわかりやすい。
あとは、JSONとRPG DSの間でデータ形式の変換を行うかどうかである。それにはXMLでいうところのパーサーが必要になる。前述のオープンソースで提供されているパーサーモジュールや、最近ではIBM iテクノロジーリフレッシュ「7.3 TR4」で利用可能になったDATA-INTO命令などで独自のパーサーを作成すれば、活用できる。
DATA-INTO命令についての詳細は、参考サイト③を参照してほしい。
いずれにしても、IBM iでクラウドとの連携を考える際にはRPGでJSONをどう取り扱うかがキーとなる。これはすなわちIBM iユーザーにとって、今後はILE RPGが必須になることを意味する。
ここでは、ILE RPGでJSONを取り扱う詳細は割愛したが、また機会があれば紹介したい。本稿が、IBM iユーザーのクラウド活用の一助となれば幸いである。
［i Magazine 2018 Summer（2018年5月）掲載］
････････
著者｜箕手 幸広 氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
ISE アセット企画
コンサルティングITスペシャリスト
1988 年、日本IBM 入社。以降、AS/400 とともに大規模ユーザーのシステムインテグレーション、技術支援などに従事。2003 年に日本アイ・ビー・エム システムズ・エンジニアリングに出向、引き続きIBM i を中心とした技術支援を実施。最近はクラウド、オートメーションなどOSS を利用したハイブリッドソリューションにも力を入れている。
