まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:domino

IBM Domino 上で Java サーブレットを動かすまでの設定と実装を紹介します。なお、今回は Domino バージョン 9 上で実行することを想定しています。


まずは Domino 上で Java サーブレットが動作するよう設定します。Domino 導入後、管理クライアントを開きます(ウェブ版でも構いません。その場合は webadmin.nsf を開きます)。サーバー設定文書を編集モードで開いて、"Internet Protocol" - "Domino Web Engine" - "Java servlet support" を "Domino Servlet Manager" に設定します。また必要に応じて Servlet URL path(デフォルトで /servlet)や Class path(同 domino/servlet)を編集して保存します。これで Domino サーバー側の設定は完了です:
2016102201


次に Java サーブレットを実装します。Domino 上の Java サーブレットは war ファイルを読み込む、といったことができないので、JDK でサーブレットの class ファイルを用意します。この辺り詳しくは以下のエントリも参照ください:
Eclipse(IDE) を使わずにJavaサーブレットを作る



上記エントリで紹介した HelloWorld サーブレットを動かしてもいいのですが、せっかくなので Domino のクラスを使って情報を取得して表示する内容にします。以下のソースコードを DominoInfo.java というファイル名で、UTF-8 で記述して保存します(青字部分で Domino クラスを使っています):
//. DominoInfo.java
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import lotus.domino.*;

public class DominoInfo extends HttpServlet{
  @Override
  protected void doGet( HttpServletRequest req, HttpServletResponse res ){
    try{
      NotesThread.sinitThread();
      Session session = NotesFactory.createSessionWithFullAccess();
      String username = session.getUserName();
      String version = session.getNotesVersion();
      
      res.setContentType( "text/plain; charset=UTF-8" );
      res.getWriter().println( username + " : " + version );
    }catch( Exception e ){
      e.printStackTrace();
    }finally{
      NotesThread.stermThread();
    }
  }
}

↑このサーブレットを実行するユーザー(つまりサーバー ID のユーザー)名と、実行中の Domino のバージョンを取得して表示する、という内容です。

これを javac でコンパイルします。このエントリでも紹介しましたが、javac のパラメータで UTF-8 エンコードであることと、ServletAPI.jar のクラスパスを指定する必要がありますが、更に加えて以下の2点を指定してコンパイルします:

(1) lotus.domino.* クラスを利用するので、Notes.jar のクラスパスを指定(以下のコマンド例では C:\IBM\Notes\jvm\lib\ext\Notes.jar に存在していると仮定)
(2) Domino 9 で使われている Java のバージョンは 6 (つまり JDK 1.6)なので、このバージョン互換でコンパイルするよう指定


具体的には以下のようなコマンドを実行します:
C:\tmp>javac -classpath c:\arc\servlet-api-3.1.jar;c:\IBM\Notes\jvm\lib\ext\Notes.jar -encoding utf-8 -source 1.6 -target 1.6 DominoInfo.java

コンパイルに成功すると DominoInfo.class というファイルが出来上がります。これを上記で設定した Domino の classpath(上の例だと domino/servlet)フォルダにコピーして、Domino を再起動します。

再起動後、ウェブブラウザで Domino サーバーの /servlet/DominoInfo にアクセスしてサーブレットを実行し、以下のような結果になることを確認します:
2016102202


↑サーバーを実行しているユーザーの名前(CN=Domino/O=Dot123)と、Domino サーバーのバージョン(Build V90_C06_12072012|December 07, 2012)が表示できました。 本来、これらの情報は Notes クライアントなどの特殊環境からでないと取得できないものですが、そのロジックを Java サーブレットという仕様でラッピングすることで HTTP アクセスで取得することができるようになったことが分かります。Notes/Domino データベースへの読み書きを実現するための1つの方法として使えます。

とうとう IBM Bluemix 上のランタイムとして Domino サーバーが登場しました。詳しくはこちらを参照ください:
Domino on Bluemix


IBM Notes/Domino は IBM が開発/販売しているコラボレーションプラットフォームです。多くの企業でエンドユーザーコンピューティングやグループウェアの基盤として使われ、多くのビジネスパートナー様による関連製品/サービスもリリースされています:
2015081202



今回リリースされた XPages(Domino) ランタイムは、パブリッククラウドである Bluemix 上で、サーバー機能である Domino が稼働する環境を提供するものです。そこだけを見ると嬉しいニュースなのですが、ではこの Domino は Bluemix とどこまで親和性があるのでしょうか? たとえば Bluemix では Java や PHP などのアプリサーバーと、DB2 や MySQL などのデータベースサーバーは分離されています。そのため、アプリサーバー部分だけを負荷に合わせて手動でスケールアウトさせることもできますし、そのスケールイン/アウトを自動化させる、いわゆる「オートスケール」の設定を組み込むことも可能です。

一方、Domino サーバーは「オールインワン」型でした。アプリサーバーもデータストアもその中で動くアプリケーションも、更にはユーザーディレクトリや HTTP, タスクスケジューラといったサブタスクも全て一元化されたサーバーを使っていました。考え方としては1つのサーバーが全ての機能を持ち、負荷分散でサーバーを複数台対応させる場合にはデータも複製して対応する、というアプローチでした。

ある意味で相反する考え方を持つ Bluemix のランタイムと Domino ですが、ではこの Domino ランタイムが Bluemix 上で動く場合に、Bluemix のスケーリングの考えは適用できるのかどうか?という疑問が生じます。

具体的には Bluemix 上の Domino は Java や PHP アプリサーバーのように簡単に複数台対応できるのか?同様にオートスケール設定ができるのか?その場合のデータの整合性はどのようにして保つのか/保たれるのか? といった疑問です。


結論を先に言うと、Bluemix 上の Domino は(条件付きで)スケール対応します。Java や PHP と同様のインターフェースやオートスケールサービスを使って、動的に Domino サーバーを複数台対応させることができます。その際に Domino 固有のデータ複製設定などは必要ありません。

でも「なぜそんなことが可能なのか?」という疑問が生じるはずです。それについて正確に表現すると「Bluemix 上で .nsf ファイルを XPages 設計要素と、ビュー/フォーム/文書の要素に分けてプッシュする形でデータベースアプリケーションをデプロイすればスケーリングに対応できる、ということになります。つまり .nsf ファイルを設計とデータとに分離します。そして前者をランタイムで、後者をサービスで運用する形を取り、更にランタイムから分離先のデータサービスを正しく参照して文書データをデータサービス内だけに保存するような設計にするという条件を付けることでスケーリングが可能になる、ということです(ランタイム側にもサービス側にも .nsf ファイルが必要です):
2015081201


これを実現するには XPages の仕組みが必要になり、加えて既存 XPages アプリの設計を少し改良する必要もあります。具体的には、例えば XPages の設計要素でデータベースファイルを指定する箇所を以下のように指定します:
<xp:dominoView databaseName="myapp_data.nsf"> 
  ↓
<xp:dominoView databaseName="#{javascript:bluemixContext.isRunningOnBluemix()? bluemixContext.getDataService().findDatabaseName() : 'myapp_data.nsf'}"> 


この処理内容は XPages 内で JavaScript を使って「Bluemix 環境であればバインドされているデータベースを使う、Bluemix 環境でなければ myapp_data.nsf を使う」という処理を記述しています。つまり Bluemix 環境上で動いている時とそうでない時に分けてデータベースファイルを指定しています。Bluemix 向けに拡張された Domino Designer ではこのような記述も可能になります。このような仕組みによって Bluemix 上でスケールできるよう対応させる必要があるとも言えます。それが "(Domino on Bluemix ではなく)XPages on Bluemix" という名称にも現れているのだと思います。


というわけで、エントリ冒頭の疑問に対する答はこちらです: 
IBM Domino はスケールイン/アウトできます。Bluemix と XPages があればね♪


なお、Bluemix 上の XPages 関連ランタイムやサービスは2015年8月12日現在ではまだ「試験提供」のステータスです。上記内容は試験提供内容を元に記述しています。正式提供に向けて今後仕様変更があるかもしれないことはご了承ください。


ついにこの日がやってきました!

まだ試験版という位置付けですが、IBM Domino のランタイムである "IBM XPages" が IBM Bluemix 上で公開されました。簡単に言えばノーツ/ドミノの .nsf ファイルが IBM のパブリックな PaaS クラウド上に用意された Domino HTTP サーバー上で動かすことができるようになった、ということです。PaaS なので Domino サーバーを構築する必要はありません。"IBM XPages" ランタイムのインスタンスを選んで起動するだけです:
2015071101


インスタンス作成後の画面がこちらです。作成した XPages(Domino) インスタンス上で自分の .nsf アプリケーションを動かすための手順が紹介されています。一般的なウェブアプリは DevOps サービスを使ったウェブ IDE でコーディングすることもできますが、.nsf の場合はそうはいきません。この手順の中にかかれているように「cf コマンドラインインターフェースツール」をインストールし、「スターターコード」をダウンロードしておきましょう:
2015071102


スターターコードは (インスタンス作成時に指定したアプリ名).zip というファイル名でダウンロードできます。この例ではインスタンス作成時の名前を dotnsf-xpages にしていたので、dotnsf-xpages.zip というファイルでダウンロードすることになります:
2015071103


インスタンス作成後の概要画面です。このインスタンスにはデフォルトで (インスタンス作成時に指定したアプリ名).mybluemix.net というホスト名が付与され、もうアクセス可能な状態になっています。XPages ランタイムの場合はデフォルトで 512MB のメモリが割り当てられるみたいですね:
2015071104


まだアプリケーションの中身には手を付けていませんが、デフォルトアプリケーションのままでホスト名(この例では dotnsf-xpages.mybluemix.net)を指定してブラウザでアクセスすると、このようなウェルカムページが表示されるはずです。後で確認しますが、この中身は .nsf ファイルの XPages で、その .nsf ファイルが Bluemix 上の Domino HTTP タスクを使って動いています:
2015071105


実際に動いているコードを確認してみましょう。先程ダウンロードしたスターターコード(dotnsf-xpages.zip)を展開すると、中に application.nsf と manifest.yml という2ファイルが含まれていることが分かります。application.nsf が Bluemix の Domino 上で動いている nsf ファイルで、manifest.yml はその application.nsf を dotnsf-xpages.mybluemix.net 上で動かすための設定が記述されたファイルです。この2ファイルをどこか専用のフォルダ(下図では c:\tmp\docroot\)を作って保存しておきます:
2015071106


application.nsf をノーツクライアントのデスクトップから開くとこんな感じです:
2015071107


この .nsf ファイルのアクセス権を確認します。現状、Bluemix 上で動かす .nsf ファイルは匿名アクセスができる必要がありそうです。自分の手元にある nsf ファイルを Bluemix にアップロードして試す場合は、匿名アクセスができるように -Default- や anonymous でのアクセス権があること、データベースの暗号化などが無効になっていることを確認してください:
2015071115


また application.nsf をドミノデザイナーで開くとこんな感じです。XPage 要素の中に先程ブラウザで表示したページが含まれています。先ほどの画面はやはりこの .nsf ファイルだったことが分かります:
2015071108


次に manifest.yml ファイルをテキストエディタで開いてみると、このような内容になっていることが確認できます(青字はコメント):
applications:
- disk_quota: 1024M
  buildpack: xpages_buildpack
  host: dotnsf-xpages ホスト名
  name: dotnsf-xpages Bluemix上のアプリ名
  path: .
  domain: mybluemix.net デプロイ先のドメイン名
  env:
    APP_HOME_URL: /application.nsf '/'でアクセスした時の実際のアクセス先
    APP_PRELOAD_DB: application.nsf 転送するNSFファイル
  instances: 1 インスタンス数
  memory: 512M メモリサイズ

この中身を書き換えると、異なる設定にしたり、異なるNSFファイルをアップロードすることもできるようになります。試しに匿名アクセス可能な updatesite.nsf というNSFファイルを用意しました(ノーツ8から対応した、Eclipse プラグインのアップデートサイト用のファイルです)。このNSFファイルは HTTP アクセスを想定して作られていますが、いわゆる XPages 対応はしていないものです:
2015071116


このファイルを Bluemix 上の Domino で動かしてみます。まずは manifest.yml を書き換えて、新しい NSF ファイルをアップロードし、またドキュメントルートにアクセスがあった場合にはこの NSF ファイルにアクセスするよう変更します:
applications:
- disk_quota: 1024M
  buildpack: xpages_buildpack
  host: dotnsf-xpages
  name: dotnsf-xpages
  path: .
  domain: mybluemix.net
  env:
    APP_HOME_URL: /updatesite.nsf
    APP_PRELOAD_DB: updatesite.nsf 
  instances: 1
  memory: 512M

次にこのアップロードする updatesite.nsf を先程のスターターコードを展開したディレクトリにコピーします。application.nsf はもう使わないので削除しても構いませんが、残しておいても構いません:
2015071117


ではこの updatesite.nsf を Bluemix 上の Domino アプリにデプロイしてみます。最初にインストールした cf コマンドラインツールを使います。Windows であればコマンドプロンプトを開いて、スターターコードを展開したフォルダに移動して、"cf login -a https://api.ng.bluemix.net" コマンドでログインします。メールアドレスとパスワードを聞かれるので、Bluemix アカウントに使っているメールアドレスとパスワードを入力します:

※データセンターとして英国を使っている場合、cf login コマンドのパラメータは https://api.ng.bluemix.net ではなく https://api.eu-gb.bluemix.net を指定します
2015071109

 
ログイン後に "cf push (アプリ名)" コマンドでデプロイします。manifest.yml に書かれた情報を元にデプロイ先やデプロイ対象、デプロイ先サーバーの設定などを識別して実行されます:
2015071110
 

無事に(エラーなく)デプロイが終了することを確認します。成功すると最後に稼働中となった Domino サーバーのステータスが表示されます:
2015071111
 

これで自分が用意した updatesite.nsf が Bluemix 上に転送されました。試しにブラウザでホスト名を指定してアクセスすると、先ほどのスターターコードのデフォルトアプリ(application.nsf)の画面ではなく、自分が用意した .nsf ファイルのデフォルトページ/デフォルトビューが表示されるはずです:
2015071112


・・・思い返してほしいのですが、ここまで Domino サーバーのインストールやインストール指示は行っていませんよね。Bluemix 側で最初から用意されたものを使っただけです。つまり Domino サーバーの用意までは IBM Bluemix が全て行ってくれて、利用者(管理者)は .nsf ファイルだけ用意して転送するだけでパブリックに公開された状態の Domino サーバー上で稼働させることができた、ということになるのです。これってすごくない!?

「うわ~、もしかしてノーツクライアントからもアクセスできちゃう!?」と期待したのですが、残念ながら現状は 1352 ポートは閉じられているようで、ノーツクライアントからこの Domino サーバーにアクセスすることはできないようです。つまり HTTP アクセスか XPages のページにアクセスできる、ということになります:
2015071113


気になるお値段ですが、どうやら他の Bluemix ランタイムと全く同じ模様です。つまり、こんな感じ:
 ・1GB時間あたり 7.35 円(メモリ1GBのインスタンス1つを1時間使うと7.35円)
 ・1ヶ月あたり 375GB時間までは無料枠、IBM XPages にも適用される
 ・無料枠を超えた分のGB時間が課金対象となる
2015071114
 
これも XPages 以外のランタイムと共通ですが一応注意点を。無料枠はアカウント1つに対する無料枠です。例えばこの XPages ランタイムのインスタンス1つだけを 512MB メモリで運用するのであれば無料枠内です。ただしこれ以外に Java ランタイムのインスタンス1つを 512MB メモリで運用する場合、どちらか1つは無料枠で運用できますが、もう1つはほぼ丸々課金対象となるので注意してください。

この XPages on Bluemix はまだ試験運転中で、今後仕様が変更になる可能性もあります。ただ少なくとも(メモリ512MBの条件があるとはいえ)無料でも試せて、自分が作った .nsf データベースが使えるパブリックな Domino が提供された、と考えると非常に大きなインパクトがあるように感じています。


ちなみに、上記で作成した dotnsf-xpages.mybluemix.net で動いている updatesite.nsf には、ボクが個人的に開発したノーツ用のプラグインアプリケーションがいくつか含まれていて、その中には時間が余った時たまにデモするテトリスなどのエンターテイメントアプリも含まれています:
2015071118

興味ある人はこちらを参照してインストールしてみてくださいませ:
ノーツに Eclipse プラグインを導入する


うーん、これでノーツアプリが Bluemix 上の Domino (のHTTPタスク) 上で動くようになったわけで、ということはノーツアプリで Bluemix Challenge 2015 に参加できるようになったとも言えるよな。。。

 

久しぶりのノーツネタです。


ノーツ9のクライアントでカレンダーを開くと、左下にこのようなセレクターが表示されます:
2015051501

ここで選択した形式でカレンダーが表示されます。自分は1週間単位で見ることが多いので、「1週間(勤務日)」で使っていることが多いです。なお「1週間(勤務日)」は月曜から金曜までの5日間を表示(土日は表示しない)、「1週間」だと月曜から日曜までの7日間が表示されます。

最近、自分の勤務が土日も含まれることが多くなってきました。というわけで、勤務用の5日表示では大事な仕事を忘れてしまいかねません。かといって「1週間(勤務日)」を残したまま「1週間」を選ぶのもわかりにくいというか・・・

こんなときこそカスタマイズです!さっそくドミノデザイナーでメールテンプレートを開いて、共有要素 - アウトライン内の NotesCalendarOutline を選択します:
2015051504


その中の「1週間」を書かれたラベルを選択して、ラベルの値を「1週間」から(例えば)「オレの1週間」に変更して保存します:
2015051502


これでノーツカレンダーを開き直すと、「オレの1週間」が選択できるようになり、選択すると7日間分のカレンダーが表示されます。これで安心して週末にも仕事のスケジュール入れられます(涙)。
2015051503




 

IBM Bluemix をはじめ、多くの便利な REST API が公開されています。REST API は HTTP プロトコルベースなので、特定のプラットフォームやプログラミング言語環境に縛られることなく、HTTP クライアント機能を持っている多くのプラットフォームやプログラミング言語から利用できるようになっています。

その一方で、IBM ノーツを使っている技術者の立場として、こういった外部の REST API をノーツからどうやって使うか、という情報があまり公開されておらず、「ノーツからは使えないんじゃないか?」と思われてしまっているように感じています。実際、ハードル高いと思う。

1点補足すると、これは「ドミノサーバー」からの話ではなく「ノーツクライアント」からの話です。ドミノサーバーであれば、Java サーブレットも使えるし、もちろんそのサーブレットからノーツデータベースにアクセスすることもできるので、連携もあまり問題ないと思うのですが、問題は「ノーツクライアント上」から「外部の」 REST API を使う、というケースです。 特に「外部の」という部分がミソで、JavaScript の AJAX などから使おうとしてもクロスサイトスクリプティング制約があったりするので、結構難しい問題だと思っています。


で、今回紹介するのは、ノーツクライアントから外部の REST API を使う方法です。"REST API" といっても、要は
 ・特定の URL に対して GET や POST でデータを送信してリクエストすると、
 ・結果が XML や JSON で返ってくるもの
という緩い定義で考えるものにします。これをノーツクライアントから実行して結果を受け取る、というものです。

今回は REST API のサンプルとして、マンホールマップの公開 API を使います。具体的には以下の URL に(GET で)アクセスすると、マンホールマップサービスに投稿されたデータから、最新20件のデータを取り出して JSON フォーマットで返す、というごく一般的(?)なものです:
http://manholemap.juge.me/searchcreated?limit=20&format=json

試しにウェブブラウザでこの URL にアクセスすると、取得結果の JSON がそのまま表示されて、こんな感じの結果になります。ちなみにこの JSON の中身の意味は・・・興味ある人はコメントなどで連絡ください、個人的に教えます(苦笑):
2015033001


この REST API にノーツクライアントからアクセスして JSON データを取得し、中身を解析してノーツで活用しよう、というのが今回の目的です。

まず最初に、これを実現するには「REST API を実行して、結果を取得する」という、ウェブ API ではごく当たり前のことを行う必要があるのですが、ノーツクライアントからこれを実行するには Java エージェントを使う必要があります。LotusScript や式関数などのマクロではノーツに関するカスタマイズ処理を記述することはできますが、TCP/IP 通信や HTTP プロトコルのレベルで処理をカスタマイズする方法は用意されていません。LSX(LotusScript eXtension) や WinSock の DLL を使って TCP/IP のソケット通信を行って・・・という手段がないわけではないと思いますが、そこまで自前で用意した上で更に HTTP プロトコルを実装、となるとさすがに非現実的です。その点、Java を使えば TCP/IP 通信は標準で持っているし、外部の便利なライブラリを使って比較的簡単に HTTP 通信を実現することもできます(更に言うと今回の例では JSON の解析も行う必要がありますが、それもライブラリに任せることができます)。 という背景もあって、今回は Java エージェントを使って REST API を実行します。

実際に Java エージェントを作る前の準備として、HTTP 通信用の Java ライブラリを用意しておきます。選択肢としてはいくつかあると思いますが、サンプルの多さなどから自分が個人的に使っているのが Jakarta Commons(Apache Commons)HTTP Client 3.1 です。この本体と、更に依存関係で必要な Logging ライブラリ、そして Codec ライブラリを全てダウンロードします。 更に実行結果の JSON テキストを取得した後の解析用に JSON ライブラリが必要になるので、これも JSON simple ライブラリをダウンロードしておきます。これらは同様の機能を持っているものであれば別のライブラリを使ってもいいのですが、以下のサンプルではこれらを使っている前提で紹介します。

以上をまとめて、以下の表のダウンロードサイトからライブラリ(のバイナリ)をダウンロードして、ダウンロードしたモジュールを展開するなどして表内右端列の4つの JAR ファイルをあらかじめ取得しておいてください。図のように同じフォルダに格納しておくと後で便利です(いずれも 2015年3月30日時点の最新バージョンです):
2015033002

ライブラリダウンロードサイト必要なファイル
HTTP Client 3.xCommons HttpClient Archivescommons-httpclient-3.1.jar
LoggingDownload Apache Commons Loggingcommons-logging-1.2.jar
CodecDownload Apache Commons Codeccommons-codec-1.10.jar
JSON simpleDownloads - JSON simplejson-simple-1.1.1.jar


では改めてノーツ上で Java エージェントを作ります。目的のデータベース(なければ新規に作って)をドミノデザイナーで開き、コード - エージェントをダブルクリックして選択後に「新規エージェント」ボタンをクリックして、エージェントを追加します:
2015033000


新規エージェント作成画面でエージェント名(図では "REST API Sample")を入力し、エージェントタイプに "Java" を選択して OK ボタンをクリックし、Java エージェントを作成します:
2015033003


新規に Java エージェントが追加されました。この中身を記述する前に、先ほど用意した4つのライブラリファイルを、このエージェント内にインポートして使えるようにしておきます。エージェント画面内の インポート - アーカイブ を選択します:
2015033004


ソースディレクトリに JAR ファイルが格納されているフォルダを指定し、インポートしたい JAR ファイルをまとめて指定して「終了」ボタンをクリックします。JAR ファイルが別々のフォルダに格納されている場合は、この手順を繰り返して全ての JAR ファイルをインポートします:
2015033005


Java エージェントのアーカイブに指定した JAR ファイルが追加されていることを確認してください。これで Java エージェント内でこれらのライブラリを使った処理を記述することができるようになりました。改めて javaAgent.java をダブルクリックして、エージェント処理の実装にとりかかります:
2015033006


ドミノデザイナー内でコードエディタが開き、javaAgent.java の編集状態になります。ここで記述された内容がこのエージェントの実行内容になります。コメントで "(Your code goes here)" と書かれた箇所の後に(というか、その前の部分を触らないように)実行内容を Java で記述します:
2015033007


今回の場合は、目的の REST API を実行して、その結果を取得する、という実装を行います。取得結果を最終的にどう扱うか(例えばノーツのデータとして格納するのか?別のデータベースに格納するのか?単に表示するだけか?など)は別に検討する必要があると思いますが、今回は結果を Java コンソールに出力する、という内容にします。なので、実装コードはこんな感じです。ここはもうノーツの世界ではなく、普通に Jakarta HTTP Client を使っているだけです:
  :
  :
  // (Your code goes here)
  HttpClient client = new HttpClient();
  GetMethod get = new GetMethod( "http://manholemap.juge.me/searchcreated?limit=20&format=json" );
  int sc = client.executeMethod( get );
  if( sc == 200 ){
    String json = get.getResponseBodyAsString();
    JSONParser parser = new JSONParser();
    JSONArray objs = ( JSONArray )parser.parse( json );
    int n = objs.size();
    for( int i = 0; i < n; i ++ ){
      JSONObject obj = ( JSONObject )objs.get( i );
      Long id = ( Long )obj.get( "id" );
      String username = ( String )obj.get( "username" );
      String text = ( String )obj.get( "text" );

      //. とりあえず整形してコンソールに出力
      String line = i + ": [" + id  + "] " + text + "(" + username + ")";
      System.out.println( line );
    }
  }
  :
  :

これで javaAgent.java およびこの(今回の例だと "REST API Sample")エージェントを保存します。


では試しにこのエージェントをノーツクライアント上で実行してみます。ノーツでこのエージェントを作ったデータベースを開きます。今回の例では最終結果を Java コンソールに出力しているので、その確認のためメニューから ツール - Java デバッグコンソールの表示 を選択します:
2015033001


こんな感じの Java コンソールウィンドウが開きます。実行結果はこの中に表示されるので、ウィンドウを閉じずにこのまま続けます:
2015033002


改めてノーツクライアントの画面に戻り、メニューから アクション - (作ったエージェント名(今回の例だと "REST API Sample")) を選択して、上記で作成した Java エージェントを実行します。実行方法はこれ以外にトリガを用意しても構いませんが、動作確認目的であれば、この方法が簡単でオススメです:
2015033003


作成した Java コードが正しく実行されると、REST API が呼び出され、結果の JSON テキストがパース&解析されて、取得したデータが1行ずつ Java コンソールに表示されるはずです:
2015033004


この例だと取得結果を Java コンソールに表示するだけでしたが、この結果を DB に格納するなり、これを元に HTML を作ってブラウザで表示する(参考記事)なり、色々な応用があると思います。ともあれノーツクライアントからであっても一般的な REST API を実行することができました。

後はこれを IBM Bluemix 上の各種 Watson API など、様々な外部 REST API を使う形で応用できると思っています。ノーツのデータを元に人工知能 API を使った解析を行うなど、いろんな使い方の可能性が広がると思っています。

 

このページのトップヘ