<シリーズ 第3回> 株式会社オムニサイエンス社の「API-Bridge」を使ったIBM i とkintoneのAPI連携をやってみた!
投稿者:クラウド事業本部 クラウドサービス部 山﨑
<シリーズ 第3回> 「IBM i 」から「kintone」のデータを削除してみよう
本シリーズでは、IBM i のモダナイズ、API連携について、実際にSaaS等と連携させた検証作業についてご案内します。
前回までで、「IBM i 」から「kintone」のデータを照会、登録することができました。
今回は「kintone」データの削除をご紹介いたします。
今回も前回使用した「kintone」<顧客リスト>のデータを使用します。
まずは完成イメージをご紹介します。
kintone側のデータは、レコード番号48まで24件存在しています。
先頭のレコード番号「48」のデータを「IBM i 」から削除します。
入り口は、データ照会の画面になります。前回よりさらにバージョンアップを行ない、項目「U/D」を追加しました。
これは、「U」:更新、「D」:削除を指示するもので、今回は「D」:削除についての紹介となります。
「U」:更新については、次回をお楽しみに!
「U/D」欄に削除の「D」を入力し、実行キーを押下します。
確認画面が表示されますので、内容確認後、削除キー(ここではF10キー)押下。
データ削除が行なわれ、一覧画面に戻ってきます。
「IBM i 」一覧画面にレコード番号「48」のデータは表示されていません。
では、「kintone」の画面を確認してみましょう。
レコード番号「48」のデータがちゃんと消えています!
というわけで、実装方法をご紹介していきましょう。
まず、「APIBridge」の定義です。
※前回ご紹介した通り、「kintone」の当該テーブルにアクセスするためには
「トークン」が必要となります。
今回はデータの削除なので、メソッドには「*DELETE」を指定します。
一覧表示同様、2画面目から5画面目は未使用です。
6画面目にパラメータを指定します。
削除データをIFSのディレクトリにJSON形式で作成しました。
7画面目はデータ取得定義と同様になります。
(削除時は指定したライブラリは特に使用しません)
これで定義は終わりです。
6画面目で指定したJSONファイル「kintone/del.json」の内容は以下の通りです。
削除処理で編集・書き込みを行なっています。
次に、RPGを用意します。
既存の照会処理から呼び出されます。
1.SQLDEL:削除処理およびJSONファイルの出力用
ソースは以下となります(毎回言い訳してますが、ソースの美しさは求めていませんので、中途半端なILERPGだな、と言わないでください、あしからず)
SQLDEL
次に画面ファイルを用意します。
1.SQLD3:顧客データ削除画面
SQLD3
次に、CLPを用意します。
CLPは以下の構成としました。
1.API_INIT:初期設定用(登録処理でも使用している共通処理です)
2.API_EXEC3:削除APIBridge実行用
API_INIT JSONデータを出力するファイルをクリア
API_EXEC3 RPGで作成した登録用のJSONファイルをIFSのフォルダにコピーしています。CCSIDはUTF-8の「1208」を指定しています。
※今回、削除処理を追加するにあたり、既存の一覧照会処理を大幅に変更しました。
既存処理は「照会に特化した」機能だったので、そこに「削除」や次回ご紹介する「更新」
機能を追加するにはロジックがあまりにもよろしくありませんでした。
ですので、もう少し構造化を考えて再構築しましたので、ソースを再掲させていただ
きます。
あっ、何度も言いますが、今回の実証実験のために最低限の機能を実装するに
とどまっていますので、「ああ、ここはこうだよな・・・」など思われた方は
ご自分が試されるときに綺麗に実装してください、
また、今回の修正履歴がわかるように、あえてコメントアウト行なども残しています。
悪しからず・・・
ご参考) SQLCTL
⇒ 目ざとい読者の方はお気づきかと思いますが、今回の画面変更でどうしても項目が
収まりきらなかったので、初めて「*DS4」を使ってみました。
といっても、先頭行の「DSPSIZ」を変更して、「27行×132桁」が表示できるように
しました。
たったこれだけで、今までの「24行×80桁」の縛りから解放され、広い画面デザインが
できるようになりました。
もちろん、エミュレータの「画面サイズ」定義も修正が必要ですので、お忘れなく!
いかがでしょうか。データ削除処理も簡単に作成できました。
が、テストで試してみると何回やっても「指定されたメソッドが使用できない」という
エラーが発生し、頭を抱えてしまいました。
解決してしまえば簡単なことなのですが、それに気づくのが私には時間がかかってしまったということです。
以下にご説明しますので、参考になればと思います。
〇落とし穴は「JSON」にあり
→ 今回サンプルとして紹介した「del.json」をご覧になってお気づきの方もいらっしゃる
かもしれません。
以下の通り、「レコード番号」を指定するキーが、登録などで使用している「id」ではなく、
「ids」となっています。
これは、一括削除もできるようにするため、値(この場合「48」)を配列で指定するようになっています。
なので、複数形の「ids」なのです!
教訓:ネットの情報に従い実装するときは、隅から隅まで文字を確認すること!
というわけで、今回はここまで。
次回は、「IBM i 」側の最終回「kintone」のデータを「IBM i 」から更新するAPIを実証実験してみます。乞うご期待!
※「IBM i 」は、IBM株式会社の登録商標です。
「APIBridge」は、株式会社オムニサイエンスの登録商標です。
「kintone」は、株式会社サイボウズの登録商標です。
※製品名、サービス名、会社名、ロゴは、一般に各社の商標、または登録商標です。なお、本文および図表中では、「™」、「®」は明記しておりません。
製品の仕様・性能は予告なく変更する場合がありますので、ご了承ください。
本サービスの詳細リンク先:IBM i アプリケーションモダナイズ
本サービスの詳細を知りたい場合は、こちらよりお問い合わせください。