メインフレーム・アプリケーションのAPI化手法　～API化を実現する製品選択と対象アプリケーションの特性分析

Text＝佐々木 源、長澤 英樹、石渡 貴大　日本アイ・ビー・エム システムズ・エンジニアリング

APIは、現在すでに多くの企業で活用されており、システム間連携の主要技術になっている。メインフレーム・アプリケーションについてもAPI連携の事例は登場しており、既存のメインフレーム・アプリケーションをAPI化することで、より容易な連携と開発効率の向上が実現できる。

しかしメインフレーム・アプリケーションの場合、言語がCOBOLやPL/Iなど、APIで基本となるREST／JSONのインターフェースとは大きく異なっており、またプログラム処理が端末の画面遷移を前提とするなど、その特質上、API化での考慮点や対応の要否の検討も必要となる。

本稿ではメインフレーム上のCICS／IMSアプリケーションについて、API化を実現するのに必要な以下の2つのステップについて解説する。

ステップ1　API化を実現する製品の検討
ステップ2　API化するアプリケーションの特性分析

ステップ1　
API化を実現する製品の検討 

メインフレーム・アプリケーションをAPI化する製品としては現在、以下の2つが存在する。

IBM App Connect Enterprise （ACE）
z/OS Connect Enterprise Edition （z/OS Connect EE）

ここでは、これらの製品の概要を紹介する。

IBM App Connect Enterprise （ACE）の概要 

IBM App Connect Enterprise （以下、ACE）は、ESB （Enterprise Service Bus）製品として実績のあるIBM Integration Bus (MQSI→WMB→IIBと製品名を変更)の後継製品として位置づけられている。IIBにIBM App Connect Professionalおよびクラウド・ネイティブのテクノロジーを結合し、汎用型のESB統合製品となっている。

ACEでは、（1)通信・プロトコル変換、（2）ルーティング、（3）データ変換の3つの機能を備えている。組み込み型のノード（パーツ）を用いたコーディングレスな処理を実装する（グラフィカルなツールを用いて開発する）のに加え、より詳細な処理記述が可能なようにESQLやJavaといった開発言語もサポートしている。

通信用に、TCP／MQ／HTTP(S)／SOAPやOpenAPI 3.0といった汎用プロトコルのほか、CICS／IMSとの専用の接続用ノードも提供している。

ACEは製品構成として、App Connect Enterprise Toolkit （App Connect Toolkit）と呼ばれる開発環境（WindowsおよびIAサーバーのLinux）と実行環境の2つで構成される。

本体の実行環境は、Linux （IAサーバー、Linux on Z）、AIX、Windows、z/OS （V11からzCXコンテナ環境のみサポート）に加えて、クラウド環境（Red Hat OpenShift、Cloud Pak for Integration）もサポートする。

App Connect Toolkitでは、メッセージ変換を担うメッセージ定義の作成と処理を記述するメッセージ・フローの開発を行う（図表1）。

このうちメッセージ定義は、メインフレーム環境で広く使われている固定長フォーマット（長さ指定の可変長を含む）を論理的なデータモデルとして扱えるようにする変換スキームである。

固定長フォーマットでは、各データ項目を示す区切り文字や識別子は存在せず、各項目は項目別に事前定義された長さにより判別される。ACEでは、COBOL、C、PL/Iの構造体定義に対応したメッセージ定義（メッセージ・モデル：データの論理モデル）の作成が可能である。

一方のメッセージ・フローとは、処理の内容そのものである。入出力用に各種プロトコルに対応したノードと処理記述を定義できるノードを組み合わせて構成する。

図表2に示すように、COBOLおよびCではCOPYBOOKやヘッダー・ファイルを直接インポートすることで、メッセージ定義が作成可能である。

PL/IではWizardを用いてメッセージ定義を作成する。これにより、メッセージ・フローでメッセージ・データを物理フォーマットに依存しない形で各項目を取り扱えるようになる。

App Connect Toolkit上ではこのほか、ユニット・テスト、デバッグ、実行環境へのデプロイ、実行環境の管理と一連の操作を実施できる。

またACEでは、OpenAPI 3.0にも対応している。図表3のように、JSON定義を取り込むとインターフェース定義が自動生成される。

後段の連携処理には、CICS／IMS Requestノードのような専用ノードのほか、TCP／MQ／HTTP(S)／SOAPといった汎用プロトコル用のノードも利用できる。これにより、ACEを起点にメインフレーム資産のAPI化が可能となる。

図表4と図表5に、ACE でのCICSとIMSの連携の概要を示す。

CICS 連携では、CICS Request ノード、SOAP Request ノード、MQ ノード、TCP/IP ノードといった接続ノードが利用可能であり、バックエンドの CICS アプリケーションのタイプに応じて選択する。

IMS 連携では、MQ ノード、IMS Request ノード、TCP/IP ノードの接続ノードが利用可能であり、IMS 接続のミドルウェア構成に応じて選択する。

図表5　ACEとIMSの連携

 

z/OS Connect Enterprise Editionの概要

z/OS Connect Enterprise Edition （以下、z/OS Connect EE）は、z/OS上でREST／HTTP／JSONベースのAPIリクエストをバックエンドのアプリケーションやデータのインターフェースに変換する製品である。

バックエンドはCICSやIMS上で稼働するCOBOLやPL/Iのアプリケーション、Db2データやMQキューへのアクセスも提供する。

図表6に、z/OS Connect EEから連携可能なバックエンドを示す。

CICSやIMSのアプリケーションの場合、z/OS Connect EEが提供するEclipseベースの開発ツールであるAPI ToolkitにCOBOLやPL/Iのインターフェース構造体をインポートし、そのインターフェースから不要なフィールドを除去したり、フィールドに固定値を設定して隠蔽したり、HTTPのメソッドやURLをアサインしてAPIのインターフェースを構築する。

また、API ToolkitではAPIのテスト・ツールも提供しており、同じツール内から作成したAPIをz/OS Connect EEのサーバーにデプロイしてテストすることも可能となっている。

図表7に、API ToolkitでのAPI作成イメージを示す。

z/OS Connect EEでは、既存アプリケーションをAPIとして呼び出すだけでなく、CICSやIMS上のアプリケーションから外部のAPIを呼び出す機能も提供しており、双方向でのAPI連携の実現が可能である。

図表8と図表9に、z/OS Connect EEでのCICSとIMSとの連携の概要を示す。

なお最新のz/OS Connect EEでは、新たにコンテナ上で稼働するOpenAPI 3.0対応のリリースも登場し、より柔軟なAPIドキュメントとCOBOLやPL/Iの構造体のマッピングを含め、よりクラウド・ネイティブな連携の実現に向けて継続的に拡張されている。

ステップ2　
API化するアプリケーションの特性分析 

既存アプリケーションをAPI化する場合、単にCOBOLやPL/Iの既存のインターフェースをそのままAPIにできるわけではなく、アプリケーションの挙動や特性として制約事項がないかを確認する必要がある。

ここではCICSおよびIMSのアプリケーションについて、どのような観点でアプリケーション分析を行うかを紹介する。

CICSアプリケーションのAPI化アプローチ

CICSアプリケーションにはさまざまな実装や異なる形態があるため、すべてのアプリケーションあるいはプログラムが一様にz/OS Connect EEから呼び出せるわけではない。

主なCICSアプリケーションの形態の違いとしては、以下が挙げられる。

（1） アプリケーションの実行形態
3270アプリケーション、CICS Transaction Gateway（CTG）やCICS Universal Client（CUC）などの外部連携アプリケーションやMQアプリケーション

（2） アプリケーションの構造
プレゼンテーション・ロジック（PL）とビジネス・ロジック（BL）が1つのプログラム内に混在しているアプリケーション、またはPLとBLが別々のプログラムで実装されていてEXEC CICS LINKコマンドやCallステートメントで連携しているアプリケーション

（3） データ受け渡し方法
COMMAREAでの受け渡し、Channel＆Containerでの受け渡し、TSキュー／TDキュー／VSAMファイルでの受け渡し、GETMAINエリアやTWA/TCTUAによるメモリ上での受け渡し

（4） その他の処理
先行処理やステート・データの受け渡しの有無、アベンドやエラー時の処理の実装

CICSアプリケーションをAPI化する場合は、これらの構造や処理形態を把握した上で、そのままAPI化できるか、あるいは制約事項に対して何らか対処する必要があるかを判断する必要がある。

図表10に、アプリケーションの分析の流れとポイントを掲載する。

z/OS Connect EEから直接呼び出せるCICSアプリケーションは、EXEC CICS LINKコマンドで連携可能なCOMMAREAアプリケーションである （Channel＆Containerアプリケーションも連携可能だが、既存アプリケーションという点では、Channel＆Containerアプリケーションは比較的新しい形態なので、ここでは割愛する）。

そのためCOMMAREAアプリケーションではない場合、PLとBLのプログラム構造を確認した上で、BL部分をCOMMAREAアプリケーションとして抽出あるいは修正可能かを検討する必要がある。

COMMAREAアプリケーションとして抽出／修正できない場合は、Host Access Transformation Services （HATS）など、端末ベースの連携ソリューションを介したAPI化を検討する必要がある。

COMMAREAアプリケーションとして連携できる場合は、API化の制約事項となる処理がないかを分析する。分析は、以下の観点で実施する。

・PLとBLの分離性
・処理の粒度
・COMMAREAインターフェースの特性
・COMMAREA以外のデータ受け渡しの方法の有無

図表11に各ポイントでの確認詳細項目、およびその項目が該当する場合の対応方法について、ACEとz/OS Connect EEのそれぞれを記載する。

COMMAREAアプリケーションの中で、EXEC CICS SENDやEXEC CICS RECEIVEなど端末関連コマンドが使われているような場合は、ACEでもz/OS Connect EEでもアプリケーションの修正が必要となる。

そのほかのケースでは、ACEであれば、メッセージ・フローの中でロジックの組み込みで対応し、z/OS Connect EEであれば、COMMAREAアプリケーションの前段にラッパー・プログラムあるいはAPI Connectなどを配置して、ラッパー・プログラムやAPI Connect内でロジックを組み込んで対応するのが主な方法となる。

CICSアプリケーションのAPI化に関するACEとz/OS Connectの違いについて、図表12に示す。

ACEを使用する場合、メッセージ・フローでのロジックの組み込みにより、より複雑なインターフェースのマッピングや高度な制御が実現可能である。

またACEをz/OSの外に配置することにより、API化に際してのz/OS環境へのコンポーネント追加や構成変更は最小限に抑えられる。CICS-MQアプリケーションのほか、WebサービスやSocketインターフェースなどのアプリケーションとも連携でき、より広範囲なアプリケーションに対するAPI化が実現可能である。

一方、z/OS Connect EEを使用する場合、よりシンプルなインターフェースであれば、API Toolkitによってノー・コーディングでAPI化でき、より迅速なAPI化を実現できる点が大きな特徴である。

また企業内でのAPIを中心とした連携の展開によっては、CICSアプリケーションから外部のAPIを呼び出すパターンも必要となる場合がある。z/OS Connect EEではAPIリクエスターの機能が提供されているため、プロバイダーとリクエスターの双方向での連携が可能である点も特徴と言える。

いずれの製品でも、API化対象のアプリケーションに制約事項となる処理がないかを分析することが重要であり、必要に応じてメッセージ・フローあるいはラッパー・プログラムの配置による対応を検討していくことになる。

IMSアプリケーションのAPI化アプローチ

図表13は、RESTアプリケーションがAPI連携インフラ（すなわちACEもしくはz/OS Connect EE）を介して、IMSアプリケーションを呼び出す際の模式図である。

図表13での各処理の概要を、以下に示す。

① RESTアプリケーションは、IMSアプリケーションのメッセージ受信コール（GU IOPCB）が期待するフィールド項目をJSON形式で記述し、HTTPにて送信する。

②　API連携インフラは、各JSONフィールド項目のI/Oエリアへのマッピング、文字コード変換、通信プロトコル変換などを実施し、IMSアプリケーションを起動する。

③ IMSアプリケーションはJSON要求に含まれるフィールド項目をメッセージ受信コールのI/Oエリアの各項目として受信し、ビジネス・ロジックを実行する。そして、処理結果をメッセージ送信コール（ISRT IOPCB）で返答する。

④ この応答メッセージは、API連携インフラを介してRESTアプリケーションに返送され、送信コールのI/Oエリア項目がJSONフィールド項目にマッピングされて渡される。

IMSアプリケーションにはCICSのようにSEND-RECEIVEもしくはCOMMAREAアプリケーションといった区別がなく、すべて端末送受信用のDL/Iコールにてメッセージ受信／送信が行われる形式となる。従ってAPI連携を実現する際には、下記の3つの観点からIMSアプリケーションを分析することになる。

（1） どのようなIMSトランザクション属性（Full Function、Fast Path、RESPONSEもしくはNONRESPONSE、会話型）で定義されているのか

（2） IMSアプリケーションはどのようなメッセージ送受信パターン、すなわち端末送受信用のDL/Iコール発行パターンを有しているのか

（3）IMSアプリケーションはどのようなメッセージ構造を送受信するのか、すなわち端末送受信用のDL/IコールにおけるI/Oエリア構造は何か

この3点を踏まえた上での、IMSアプリケーション分析のポイントについて述べる。

まず重要となるのは、各API連携ソリューションにて、「API化で対応不可となる制約」への抵触状況を確認することである。IMS連携では、API連携ソリューションの選択によって制約事項への対応可否が異なる。なお、一般にz/OS Connect EE連携およびACE＋IMSノード連携に比べ、ACE＋MQノード連携およびACE＋TCP/IPノード連携のほうが制約が少ないと言える。

図表14に、各分析ポイントでの分析ソース、確認すべき項目、各API連携ソリューションでの対応可否をまとめているので参考にされたい。

次に重要となるのは、「APIとして公開される入出力インターフェースは何か」を明らかにすることである。これはすなわち、図表13で示したようなIMSアプリケーションの端末送受信用DL/Iコール発行順および使用I/Oエリア構造を把握することである。

なお、最もAPI化が容易となるのは、「要求－応答型かつ固定レイアウトの通信」を行うアプリケーション、これをIMS的に言い換えるならば、「GU/GN(x n) IOPCB ～ ISRT IOPCB(x n) かつ DC DL/Iコール出現順および各使用I/Oエリアが固定」のアプリケーションである。

すなわち、もともとシンプルなメッセージ通信を実施しているIMSアプリケーションはRESTfulな通信と相性がよいと言える。

図表15に、選択したAPI連携ソリューションが何らかの制約に抵触している場合、どのような対応が想定されるかをまとめた。

ほとんどの場合、IMSアプリケーション・ロジックを変更し、制約に抵触しない実装とするか、もしくはIMS側の構成や設定変更で回避するという方策が必要になる。

図表15から一例をあげれば、もし仮にIMSアプリケーション・ロジックを確認した結果、アプリケーション内で3270画面名（つまりMFS MOD名）をチェックしているロジックが含まれていた場合、「z/OS Connect EEおよびACE IMSノードでは、MOD名を疑似的に渡すことができない」という制約に抵触することになる。

この場合、IMSアプリケーション内からMOD名を検査するロジックを除去もしくはバイパスすることで対応する必要がある。

図表16に、主としてRESTクライアント側の要件から見たIMSアプリケーションのAPI化に関するACEとz/OS Connect EEの比較を示した。

ACE連携では、API連携のためにメッセージ・フローを開発する必要がある分、ほとんどのRESTクライアント要件に対して柔軟に対応できる。

すなわちACEによるAPI連携が優位なケースとして、ACEの有する豊富なインターフェース制御やフロー制御、プロトコル変換を活用したい場合や、現状のIMS側の実装がz/OS Connect EE制約に抵触しているが、ACEであればIMS側の変更なしで対応可能となる場合が挙げられる。

一方、z/OS Connect EEではAPI Toolkitを用いたコーディングなしの迅速なAPI化が可能な反面、複雑なRESTクライアント要件に対してはz/OS Connect EE単体では対応できず、IMSアプリケーションの改修、API Connectの援用、もしくは新しいコンテナ版z/OS Connect EEの採用といった対応が必要になる。

すなわち、z/OS Connect EEによるAPI連携が優位なケースとして、開発量を抑えて迅速なREST API化を実現したい、またz/OS側が直接REST Endpointになるシンプルなシステム構成が望ましいなどの場合が挙げられる。

以上、メインフレームのCICS／IMSアプリケーションのAPI化で使用可能な製品、およびどのようにアプリケーションを分析するかについてのアプローチを紹介した。

本稿がメインフレーム・アプリケーションのAPI化を検討するきっかけになれば幸いである。

参考情報

◎IBM App Connect Enterprise
◎z/OS Connect Enterprise Edition