IBM i開発者にとってのAPI連携　～＜前編＞RPG的開発者がおさえるべきAPIの基礎知識　｜IBM iユーザーに捧げるAPI入門❶

Text＝小川 誠 ティアンドトラスト株式会社

RPG開発者にとってのAPI

API（Application Programming Interface）とはその名のとおり、アプリケーション（プログラム）同士が情報をやり取りするために事前に取り決められたインターフェース仕様のことである。

連携するアプリケーション（プログラム）は、同一システム内に存在する場合もあれば、他のシステムやクラウドに存在するケースもある。システム間でのアプリケーション連携の場合は、異なる OS 配下で実行されている場合がほとんどなので、そのインターフェースはOSの違いを吸収するために、汎用的で疎結合になるよう設計されていることが多い。

本題に入る前に、同一システム内とシステム間連携という2つのケースでAPI 利用の概要を見ていこう。

同一システム内でのAPI

IBM i のAPI とはもともと、OSの機能を RPG などのプログラムから利用する際のインターフェースを意味していた。このAPIは、プログラムオブジェクトやサブプロシージャー形式で提供されており、情報のやり取りはAPIにアクセスする際のパラメータを介して実行する。

今、筆者の手元に、『AS/400 システムAPI解説書 バージョン3（1995年10月）』の第1巻と第2巻がある。目次を見ると、さまざまなOS の機能を利用できる API が提供されている。たとえば バックアップと回復、デバッガー、動的画面管理機能、ファイル、統合化言語環境（ILE）、オブジェクト、機密保護、スプール・ファイルおよび印刷、UNIXタイプなど。

これらのAPIを使うことで、通常はシステムが提供するコマンドや5250の画面を通してのみユーザーが参照できた情報を、RPG などのプログラムからも直接参照が可能になる。

たとえば、コマンドWRKACTJOB SBS(QINTER)で表示される対話型ジョブの一覧や各ジョブのユーザー名、ステータスなどは、QUSLJOB APIを利用すればRPGプログラムから参照できる。定期的に対話型ジョブを監視し、MSGWになったジョブがあれば次のアクションを実行するなどの監視プログラムを、このAPIを利用すれば作成できる。

OSが提供する通信機能を直接プログラムから利用することも可能だ。たとえば RPGで独自のソケット通信プログラムを記述したい場合などがそうだ。

IBM i が提供しているシステムAPIは、バージョンごとにWebで公開されているので、興味があれば下記で調べてほしい。

◎IBM i 7.4 Application programming interfaces
https://www.ibm.com/docs/ja/i/7.4?topic=programming-application-interfaces

上記 API は、外部からの呼び出しを想定して設計されているわけではないので、利用は同一システム内に限定されていた。しかし最近はIBM iサービスとして、SQLインターフェースを経由してアクセス可能な例が増えている。

たとえばQUSLJOB APIと同様の情報にアクセスするために、現在は図表1のようにACTIVE_JOB_INFOテーブル関数が提供されているので、API を使わなくてもSQLインターフェースを経由して同様の情報を参照できる。

他システムとのAPI

次に、他システムに存在するプログラムと情報をやり取りする際のインターフェースについて考えてみよう。

システム連携時に使用される通信プロトコルは、事実上TCP/IP経由のみになるので、当然そのプロトコルを前提としたインターフェースが主流である。たとえばCSV形式のファイルをやり取りするデータ連携は、ファイル転送プロトコル（ftp、sftpなど）を使用して実装されることが多い。

昨今は、テキストファイルの送受信による情報のやり取りのほかに、リアルタイムに他システムが持つ情報にアクセスしたり、他システムが提供するサービスを使用するケースが多くなってきた。

IBMは2018年3月、IBM i の事業戦略を発表したが、その際にWatsonやクラウドサービスとの連携（水平統合）を踏まえた開発を続けると宣言した。あれから今年3月で5年が経過するが、その間にさまざまなクラウドサービスが拡大し、そのサービスに IBM i がまさに水平統合する必要性があることををユーザーも強く感じているだろう。

この水平統合の実現に向けて昨今注目されているのが、REST APIである。RPGからは、この REST APIをSQLインターフェース経由で利用することになる。

REST APIのRESTはREpresentational State Transfer の略で、もともとは分散システムでアプリケーション同士を連携させる設計手法を指していたが、最近ではHTTPプロトコルを介してアプリケーションをどのように連携させるかの取り決めをREST API と呼ぶ場合が多い。

Webサーバーにアクセスする際に使用されるHTTPプロトコルには、GETやPOSTなどのメソッドがあり、ブラウザはこのメソッドを利用して Web サーバーから情報を取得したり、ブラウザに入力された情報をサーバーに送る。

REST APIはこのメソッドを利用して、サーバー情報へのアクセスやサービスの利用を可能にするインターフェースであり、TwitterやSlackなどのサービスも、公開されているREST APIを経由して利用できる（図表2）。

ブラウザや専用アプリではなく、RPG などの言語から Web サービスを利用する場合も、この API を経由すればよい。ただし、どういうサービスが提供されているか、送受信するデータの形式をどうするかなどは、Web サービスを提供する側が決めているので、それを理解した上でプログラミングすることになる。この仕様は各社ごとに公開されているので、プログラミングする際にはその情報を参照する必要がある。

RPG開発者にとってのAPI基礎知識　

前述したとおり、REST API とは Webサーバーへのアクセス時に使用する http/https プロトコル（メソッドはGET、POST、PUT、DELETE）を使用して、アプリケーション（プログラム）をやり取りする取り決めを指す。

情報を必要とする側（クライアント）は、サーバー側が要求するAPIインターフェースの情報を HeaderおよびBody情報に含め、http プロトコルを使用してサーバー側に送信する。サーバー側はクライアントから送られてきた情報を読み取り、バックエンドのプログラムやサービスを起動して結果をクライアントに返す。

ここで重要なのは、http というどのプラットフォームも対応可能な標準プロトコルをベースに、システム（プログラム）間連携を実現していることだ。これにより、クライアントとサーバー側のプラットフォーム（OS）の違いを意識する必要がなくなり、しかも4つのメソッドのみを利用するというシンプルさにより、連携そのものを疎結合で実現することが可能になる。

IBM iをクライアントと考えた場合、REST APIを利用することで、特別なソフトウェアの導入やセットアップ、他のシステム特有のプロトコルの実装など、個別に対応することなく Web サービスを利用できるようになる。そして、今後増えていくであろう未知のサービスとの連携も可能になる。すでに稼働している基幹システムを活かしつつ、水平統合を実現できるこの API の理解は必須と考えてよい。

APIの前提となる知識

それでは、外部サーバー／サービスとの連携をREST APIで実装する際に必要な前提知識をまとめておきたい。前述したように、REST APIの使用はSQLインターフェースを経由するのが容易なので、それを前提に考える。

httpメソッドを呼び出す関数　

GET、POST、PUT、DELETEの4つのhttpメソッドを呼び出すには、以下のライブラリーで提供される関数を利用する。

◎SYSTOOLSライブラリー
https://www.ibm.com/docs/ja/i/7.4?topic=systools-http-function-overview

◎QSYS2ライブラリー
https://www.ibm.com/docs/en/i/7.4?topic=functions-scalar 内の HTTP_xxxx 関数

どちらも4つのメソッドを呼び出せるが、QSYS2ライブラリーの関数は後発で、違いはJava環境が必要（SYSTOOLSライブラリーの場合）かどうかにある。

組み込みSQL　

http関数をRPGから呼び出すには、組み込みSQLを使用する。組み込みSQLは、RPG Ⅲ／ILE RPG／FF RPGのすべてで利用できるが、送受信するデータを処理するための命令や変数の長さの制限により、RPG Ⅲは実質利用できない。

少なくとも定位置形式のILE RPG、可能であればFF RPGを使用して実装するのが望ましい。

HTTP リクエスト　

クライアントからWebサーバーに情報を送る場合のメッセージは、大きく分けてHeaderとBody に分けられるが、これを1つにまとめたものを「HTTPリクエスト・メッセージ」という。

HTTP 関数を利用する場合、実際のHTTPリクエストは関数が生成するが、HeaderとBodyにそれぞれ何を指定するかはアクセスするサーバーにより異なるので、それに従ってプログラムで値を設定する必要がある（図表3）。

http メソッドを呼び出す関数では、用意したHeaderとBodyをどのように指定するかが決まっているので、それに従ってプログラミングしなければならない。

XML／JSON　

リクエスト要求時のHeader情報は、利用するHTTP関数によって記述する形式が決まっている。またBody に要求情報を記述する形式も、サーバー側のインターフェースによって決められているので、それに基づいて記述する必要がある。

通常、その形式はXMLかJSONの場合が多いので、これについての理解も必要となる。

なお要求結果もXML／JSON形式で戻るので、それをどのようにRPGで処理するかの知識も必要となる。

XML形式はXML-INTO命令でデータ構造にマッピングしたり、Db2 for i の XMLPARSE 関数で値を取得する。JSON形式は、JSON_TABLE 表関数を使ってデータを表形式に変換する。これらの命令および関数は、後述のサンプルプログラムで利用しているので参考にしてほしい。

XMLとJSONの比較

ここで簡単に、XMLとJSON についてまとめておこう。

XML

eXtensible Markup Language の略で、HTML と同様に各情報をタグ（<…></…>）で囲んで記述するマークアップ言語である。

図表4からわかるように、HTMLと同様の構造でデータを記述するが、タグ名は作成者が自由に決められる。どのデータをどのタグで修飾するかは、XMLを作成する側と参照する側の双方で共有されていればよい。

RPGでは、送信されてきたXMLを解析（パース）して、データ構造にマッピングするための XML-INTO 命令が用意されているので、それを利用する。

JSON

Java Script Object Notationの略で、その名のとおり、JavaScriptオブジェクト記法を使用したデータ記述フォーマットである（図表5）。

もともとはJavaScript用だったが、現在では多くの言語がこの形式を処理できる。RPGでは送信されてきたJSONをテーブル形式に変換するJSON_TABLE関数などが利用可能である。

同じ情報を表すXML形式のサンプルと比較すればわかるように、より読みやすいフォーマットであり、同じ情報を記述する場合は JSON のほうがサイズが小さくなる傾向があるので、XMLに代わるフォーマットとして使用されることが多い。

XML形式もJSON形式も多くのREST APIで情報交換用に利用されており、前述したように HeaderとBody情報をどちらの形式で指定するかなど細かく仕様によって決まっているので、これを機会に理解を深めてほしい。

 後編を読む