アダプタの開発
![]() |
![]() |
![]() |
![]() |
ADK の設計時フレームワークには、アダプタのユーザがアプリケーション ビューの定義、デプロイ、およびテストの際に必要となる Web ベースの GUI を作成するためのツールが用意されています。各アダプタには EIS 固有の機能がありますが、アプリケーション ビューをデプロイするための GUI は、すべてのアダプタで必要です。設計時フレームワークでは、主に以下のコンポーネントを使用して、このような GUI の作成やデプロイの作業を最小限に抑えることができます。
DesignTimeHelper
クラス。WebLogic Server のアプリケーション ビューをデプロイ、アンデプロイ、コピー、および編集する際に利用できる単純な API を提供します。
Java サーブレットと JSP を組み合わせることで、さまざまな方法でフォームを処理できます。どの方法でフォームを処理する場合でも、以下の基本的な要件を満たす必要があります。
また、Web アプリケーションには、有効な情報の再入力を要求せずに、ユーザが最後に入力した内容を再表示できる機能も必要です。Web アプリケーションは、入力されたフィールド値がすべて有効になるまで手順 2 を繰り返す必要があります。
Web アプリケーションで使用する各フォームに対してすべてのフォーム処理機能を実装すると、プロセスが冗長になりエラーの原因にもなります。ADK 設計時フレームワークでは、MVC (Model-View-Controller) パラダイムによって、このプロセスが簡素化されています。このパラダイムでは、以下の 5 つのクラスをベースとします。
このクラスは HTTP リクエスト処理ロジックを提供します。このクラスは、MVC ベース メカニズムのモデル コンポーネントです。RequestHandler オブジェクトは ControllerServlet
によってインスタンス化され、HTTP セッション中に handler
キーの下に保存されます。ADK には com.bea.adapter.web.AbstractDesignTimeRequestHandler
クラスが用意されています。この抽象基本クラスにより、アプリケーション ビューをデプロイする際にすべてのアダプタに共通して必要な機能が実装されます。アダプタまたは EIS 固有のロジックを定義するには、このクラスを拡張する必要があります。
このクラスは HTTP リクエストを受け取ると、リクエスト中の各フィールド値の有効性を検証し、リクエストの処理を RequestHandler
に委託します。また、表示するページを決定します。ControllerServlet
は Java Reflection を使用して、RequestHandler
で呼び出すメソッドを特定します。ControllerServlet
は doAction
という HTTP リクエスト パラメータを探し、フォーム処理ロジックを実装するメソッド名を指定します。このパラメータがなければ、ControllerServlet
は RequestHandler
でメソッドを呼び出しません。
ControllerServlet
は、Web アプリケーションに使用する web.xml
ファイルでコンフィグレーションされます。ControllerServlet
は、RequestHandler
で実行するメソッドに HTTP リクエストを委託します。ControllerServlet
を使用する場合、コードを指定する必要はありません。ただし、表 9-5 に示すパラメータを指定する必要があります。
ActionResult
では、リクエストの処理結果がカプセル化されます。また、次に表示するページを決定するための情報が ControllerServlet
に提供されます。
Web アプリケーションのすべてのフィールドについて、有効性を検証する必要があります。com.bea.web.validation.Word
クラスおよびその子孫により、フォーム中の各フィールドの有効性を検証するロジックが提供されます。無効なフィールドがあると、Word
オブジェクトはメッセージ バンドルを使用して、該当するフィールドに応じてインターナショナライズまたはローカライズされたエラー メッセージを検索します。ADK には、表 9-1 に示すカスタム バリデータが用意されています。
com.bea.web.tag.AbstractInputTagSupport
Web ツールキットで提供されるタグ クラスには以下の機能があります。
ControllerServlet
がフォームのフィールド名を使用して、検証オブジェクトにアクセスできるように、com.bea.web.validation.Word
を初期化して Web アプリケーション スコープに保存する。
<adk:submit name='xyz_submit' doAction='xyz'/>
このタグにより、doAction
パラメータがリクエスト中の ControllerServlet
に渡されます。この結果、ControllerServlet
から登録済みの RequestHandler
で xyz()
メソッドが呼び出されます。
com.bea.web.validation.Word
のインスタンスがオブジェクトによって初期化され、入力フィールド名をキーとして、Web アプリケーション スコープにこのインスタンスが格納される。このようなタグにより、ControllerServlet
で検証オブジェクトが有効になるため、まず HTTP リクエストを大まかに検証してから、RequestHandler
にリクエストを出すことができます。以下にその例を示します。
<adk:int name='age' minInclusive='1' maxInclusive='120' required='true'/>
com.bea.web.tag.IntegerTagSupport
のインスタンスで doStartTag()
メソッドを呼び出したら、このタグの HTML が生成される。IntegerTagSupport
インスタンスにより、com.bea.web.validation.IntegerWord
の新しいインスタンスが作成され、これがキー age
に基づいて Web アプリケーション スコープに追加されます。その結果、ControllerServlet
では、年齢の値を検証する必要があるときはいつでも、対応する ServletContext
から IntegerWord
インスタンスを検索できます。検証によって、年齢に渡された値が 1 以上かつ 120 以下であることが確認されます。これらの前提条件を満たすと、コード リスト 9-1 のような JSP フォームが表示されます。
<form method='POST' action='controller'>
Age: <adk:int name='age' minInclusive='1' maxInclusive='120'
required='true'/>
<adk:submit name='processAge_submit' doAction='processAge'/>
</form>
以下のダイアグラムに、フォーム処理の実行方法を順を追って示します。
ControllerServlet
は age
をキーとして使用して、ServletContext
から com.bea.web.validation.Word
を検索します。このオブジェクトは、com.bea.web.validation.IntegerWord
のインスタンスです。ControllerServlet
は、Java Reflection API を使用して、processAge()
メソッドを探して、RequestHandler
でこのメソッドを呼び出します。このメソッドが存在しない場合は、例外が生成されます。メソッド署名は、以下のとおりです。
public ActionResult processAge(HttpServletRequest request) throws Exception
RequestHandler
は、フォームの入力データを処理した後、ActionResult
オブジェクトを返して処理結果を示します。ActionResult
には、ControllerServlet
が次に表示するページを決定するための情報が格納されます。その情報は、Web アプリケーション内に表示する別の JSP や HTML のページの名前などにします。たとえば、thanks
という情報があった場合には、次に thanks.jsp
ページが表示されます。
設計時 GUI の開発では、実行時アダプタを開発する場合とは異なる独自の機能を使用します。この節では、設計時 GUI の機能を説明します。
設計時 GUI は、一連の JSP (Java Server Page) で構成されます。JSP とは、特定のトランザクションを開始する目的で Java サーブレットを呼び出すための HTML ページのことです。ユーザ側から見た JSP は、通常の Web ページと変わりません。
これらの JSP の実装方法については、「手順 2 : ページ フローの定義」を参照してください。
テンプレートとは、HTTP リクエストで指定するパラメータに基づいて Java サーブレットが動的に生成する HTML ページのことです。テンプレートを使用することにより、Web アプリケーションで使用するカスタム ページやカスタム HTML の量を最小限に抑えることができます。
設計時フレームワークの JSP テンプレートのセットを使用すると、アダプタの新しいアプリケーション ビューを定義、デプロイ、およびテストするための Web アプリケーションを効率的に作成できます。アダプタの開発者にとって、ADK のテンプレートには以下の 3 つの利点があります。
ADK で提供される JSP テンプレートのリストについては、「JSP テンプレート」を参照してください。
ADK で提供される JSP タグ ライブラリを使用すると、使いやすい HTML フォームを簡単に作成できます。アダプタ ページを開発する際、HTML フォーム入力コンポーネントのカスタム タグを使用すれば、検証メカニズムへシームレスにリンクできます。以下の表に、ADK に用意されているカスタム タグを示します。
表 9-4 に記載されている属性を使用すると、JSP タグをさらにカスタマイズできます。
注意 : タグの使用方法については、以下の場所にある adk.tld
を参照してください。
WLI_HOME
/adapters/src/war/WEB-INF/taglibs
アプリケーション ビューは、アプリケーション固有の機能に対するビジネス レベルのインタフェースです。詳細については、「アプリケーション ビュー」を参照してください。
設計時 GUI アダプタを構築する際に必要なファイル構造は、サービス接続を構築する場合と同じです。「手順 2a : ディレクトリ構造の設定」を参照してください。参照先で説明されているファイル構造のほかに、以下の点にも注意する必要があります。
.jsp
ファイル、.html
ファイル、および画像ファイルをバンドルしたものである。 WLI_HOME
/adapters/ADAPTER/src/war/WEB-INF/web.xml
である。この記述子により、Web アプリケーションをデプロイおよび初期化する方法が J2EE Web コンテナに指示されます。
図 9-2 に、設計時 GUI の開発手順を示します。
設計時 GUI の開発を始める前に、以下の質問に答えて要件を定義する必要があります。
EIS では、イベントおよびサービス カタログにアクセスするための関数を定義する必要があります。EIS にこれらの関数がない場合は、カタログを参照できません。EIS がこれらの関数を提供しない場合は、以下の設計基準に従うことをお勧めします。EIS のメタデータを入手するために設計時 UI を呼び出す。これは、実行時コンポーネントを呼び出すことと同じです。いずれの場合も、バックエンド EIS で関数が実行されます。
したがって、設計時メタデータの機能を提供するには、できるだけ実行時アーキテクチャを利用する必要があります。CCI Interaction オブジェクトを使用する設計時 GUI 固有の関数を呼び出す必要があります。ADK に用意されているサンプル アダプタは、このアプローチに基づいた例やフレームワークを提供します。サンプル アダプタは、WLI_HOME
/adapters/sample
にあります。
通常、関数やイベントに関するメタデータを取得するには、アダプタから EIS を呼び出す必要があります。これにより、アダプタで EIS メタデータが XML スキーマ フォーマットに変換されます。このとき、SOM API を呼び出す必要があります。サンプル アダプタは SOM API を実装する指示を出すこともできます。この API の詳細については、「JSP タグの ADK ライブラリ」を参照してください。
WLI_HOME
/adapters/dbms/docs/api/com/bea/adapter/dbms/utils/
class-use/TestFormBuilder.html
ユーザがアプリケーション ビューを呼び出したときの JSP の表示順序を指定する必要があります。この節では、効果的なアプリケーション ビューで必要となる基本的なページのフローを説明します。ここで説明する要件は最低限必要なものであり、フローには必要に応じてページを追加できます。
アプリケーション ビューはセキュアなシステムであるため、ビューを実装する前にログインする必要があります。このため、最初は必ず [Application Integration Design Console ログオン] ページを表示します。
このページを使用するには、有効なユーザ名とパスワードを入力します。この情報から、ユーザが、デフォルトの WebLogic Server セキュリティ レルムに定義されたアダプタ グループのメンバーであることを確認します。
注意 : アプリケーション ビューの Web アプリケーションに対するセキュリティ要件は、WLI_HOME
/adapters/ADAPTER/src/war/WEB-INF/web.xml
ファイルで指定されています。これは、adapter.war
ファイルに組み込まれています。
ユーザが正常にログインすると、[Application Integration Design Console] ページが表示されます。このページには、アプリケーション ビュー、各フォルダのステータス、およびこれらに対して実行されたアクションを示すフォルダが表示されます。ユーザはこのページから既存のアプリケーション ビューを表示したり、新しいアプリケーション ビューを追加できます。
appvwsum.jsp
) が表示されます。このページの詳細については、「ページ 9 : アプリケーション ビューの概要」を参照してください。[新規アプリケーション ビューの定義] ページ (defappvw.jsp
) では、クライアントが配置された任意のフォルダに新しいアプリケーション ビューを定義できます。これには、アプリケーション ビューとアダプタを関連付けるための説明が必要になります。このフォームには、アプリケーション ビュー名と説明を入力するフィールドと、アプリケーション ビューと関連付けるアダプタを表示するドロップダウン リスト ボックスがあります。
新しいアプリケーション ビューを定義した後に [OK] を選択すると、[Configure Connections] ページが表示されます。
新しいアプリケーション ビューが有効であれば、ユーザは接続のコンフィグレーションを行う必要があります。つまり、アプリケーション ビューの有効性が検証された後、[Configure Connection Parameters] ページ (confconn.jsp
) が表示されます。このページは、EIS の接続パラメータを指定するためのフォームです。接続パラメータは EIS 固有であるため、このページの外観はアダプタごとに異なります。
ユーザが接続パラメータを送信すると、アダプタはこのパラメータを使用して EIS への新しい接続を試みます。EIS に接続されると、ユーザには次の [Application View Administration] ページが表示されます。
ユーザには、新しいアプリケーション ビューを管理する方法が必要です。[Application View Administration] ページ (appvwadmin.jsp
) には、アンデプロイされたアプリケーション ビューの概要が表示されます。具体的には、以下の情報が表示されます。
さらに、アプリケーション ビューにイベント リストやサービス リストを提供するほかに、新しいイベントやサービスを追加できるページへのリンクも設定します。
次にユーザは、イベントをアプリケーション ビューに追加する必要があります。[Add Event] ページ (addevent.jsp
) で、これを行うことができます。
新しいイベントを定義して保存すると、[Application View Administration] ページに戻ります。
アプリケーション ビューに新しいサービスを追加する必要もあります。[Add Service] ページ (addservc.jsp
) で、これを行うことができます。
新しいサービスを定義して保存すると [Application View Administration] ページに戻ります。
1 つ以上のサービスまたはイベントを追加すると、アプリケーション ビューをテストできます。アプリケーション ビューをテストすると、テスト用のイベントやサービスの処理にこれを利用できるようになります。アプリケーション ビューのテストをする場合は、以下の 2 つの方法を選択できます。
アプリケーション ビューのテストに成功したら、アプリケーション ビューを [アプリケーション ビューの概要] ページからパブリッシュできるため、WebLogic Workshop アプリケーションから使用できるようになります。
アプリケーション ビュー (テストとパブリッシュを行っていないビューも含む) を保存すると、後で Application Integration Design Console からアプリケーション ビューへ戻ることができます。この処理では、アプリケーション ビューは目的の WebLogic Workshop アプリケーション内のアプリケーション統合リポジトリに保存されます。アプリケーション ビューはテストを行うと自動的にこのリポジトリに保存されるので、実際にアプリケーション ビューのテストをする前にデザイン セッションを残す場合にのみ、この手順は必要となります。
アプリケーション ビューが正常にデプロイされると、[アプリケーション ビューの概要] ページ (appvwsum.jsp
) が表示されます。このページにはアプリケーション ビューに関する以下の情報が表示されます。
ページには、アプリケーション ビューのテストを停止するオプションがあります。ユーザが [テストの停止] リンクをクリックすると、この選択を確認する子ウィンドウが表示されます。ユーザが確認した後、アプリケーション ビューのテストが停止され、概要ページが再表示されます。このようにしてテストされていないアプリケーション ビューは、引き続きリポジトリに保存されます。このため、ユーザはアプリケーション ビューを編集したり削除できます。
アダプタでイベントのテストがサポートされている場合は、[概略] ページに各イベントのテスト リンクが表示されます。イベントのテストは、ADK で直接にはサポートされていません。
アダプタでサービスのテストがサポートされる場合は、[概略] ページに各サービスのテスト リンクが表示されます。ADK では、testservc.jsp
ファイルと testrslt.jsp
ファイルを提供することにより、サービスをテストする 1 つのアプローチが紹介されています。これらのページを自由に使用して独自のサービス テスト方法を作成できます。
ページには、アプリケーション ビューをテストするオプションがあります。ユーザが [テスト] リンクを選択すると、アプリケーション ビューのテストが開始され [アプリケーション ビューの概要] ページが再ロードされます。
ページには、アプリケーション ビューを編集するオプションがあります。ユーザが [編集] リンクをクリックすると、[Application View Administration] ページが表示されます。
ページには、アプリケーション ビューを削除するオプションがあります。ユーザが [削除] リンクをクリックすると、ADK リポジトリからアプリケーション ビューを削除するかどうかを確認する子ウィンドウが表示されます。ユーザが確認した後、アプリケーション ビューがリポジトリから削除され、Application Integration Design Console に戻ります。
ここでは、設計時 GUI 開発をサポートするためのソフトウェア環境を設定します。
エンドユーザ向けのメッセージはメッセージ バンドルに格納する必要があります。メッセージ バンドルは、key=value の組み合わせで構成される単純な .properties
テキスト ファイルで、この key=value の組み合わせにより、メッセージをインターナショナライズできます。実行時にロケールと地域言語を指定すると、メッセージの内容が、key=value の組み合わせの指定に従って翻訳され、メッセージが指定されたロケールに適切な言語で表示されます。
メッセージ バンドルの作成方法の詳細については、以下のサイトの JavaSoft チュートリアルでインターナショナライゼーションについて参照してください。
http://java.sun.com/docs/books/tutorial/i18n/index.html
設計時 UI は、WAR ファイルの J2EE Web アプリケーションとしてデプロイされます。WAR ファイルは、JAR ファイルにある WEB-INF/web.xml
内で Web アプリケーション記述子が付いた JAR ファイルです。ただし、WAR ファイルでは、WebLogic Server の J2EE Web コンテナを使用してその場で JSP を再コンパイルすることはできません。このため、通常は単に JSP ファイルを変更するだけでも、WebLogic Server を再起動する必要があります。これは JSP の特長と相反するため、ADK では WebLogic Server を再起動しなくても JSP を更新できるように以下の解決策をお勧めします。
<target name='war' depends='jar'>
<!-- 既存の環境をクリーンアップする -->
<delete file='${LIB_DIR}/${WAR_FILE}'/>
<war warfile='${LIB_DIR}/${WAR_FILE}'
webxml='${SRC_DIR}/war/WEB-INF/web.xml'
manifest='${SRC_DIR}/war/META-INF/MANIFEST.MF'>
<!--
重要 ! WEB-INF/web.xml ファイルを WAR から削除する
このファイルは上記の webxml 属性によりすでに含まれている
-->
<fileset dir="${SRC_DIR}/war" >
<patternset >
<include name="WEB-INF/weblogic.xml"/>
<include name="**/*.html"/>
<include name="**/*.gif"/>
</patternset>
</fileset>
<!--
重要 ! ADK 設計時フレームワークをアダプタの設計時
Web アプリケーションに含める。
-->
<fileset dir="${WLI_HOME}/adapters/src/war" >
<patternset >
<include name="**/*.css"/>
<include name="**/*.html"/>
<include name="**/*.gif"/>
<include name="**/*.js"/>
</patternset>
</fileset>
<!--
設計時 UI をサポートするアダプタのクラスを含める
-->
<classes dir='${SRC_DIR}' includes='sample/web/*.class'/>
<classes dir='${SRC_DIR}/war' includes='**/*.class'/>
<classes dir='${WLI_HOME}/adapters/src/war'
includes='**/*.class'/>
<!--
Web アプリケーションで必要とされ、EAR で共有されないすべての JAR
ファイルを、WAR ファイルの WEB-INF/lib ディレクトリ下に含める
-->
<lib dir='${WLI_LIB_DIR}'
includes='adk-web.jar,webtoolkit.jar,wlai-client.jar'/>
</war>
</target>
この Ant ターゲットは、PROJECT_ROOT
/lib
ディレクトリ内に設計時インタフェース用の有効な WAR ファイルを作成します。このディレクトリで、PROJECT_ROOT
は WebLogic Integration がインストールされている場所で、開発者はここにアダプタを構築します。たとえば、DBMS サンプル アダプタは、以下の場所で構築されます。
<Application Deployed="true" Name="BEA_WLS_SAMPLE_ADK_Web"
Path="WLI_HOME\adapters\PROJECT_ROOT\lib">
<WebAppComponent Name="BEA_WLS_SAMPLE_ADK_Web"
ServletReloadCheckSecs="1" Targets="myserver" URI=
"BEA_WLS_SAMPLE_ADK_Web"/>
</Application>
WLI_HOME
を、WebLogic Integration がインストールされているディレクトリのパス名に置き換えます。コード リスト 9-3 に示すように、PROJECT_ROOT
を、アダプタ開発ツリーのトップレベル ディレクトリの名前に置き換えます。注意 : GenerateAdapterTemplate
を実行すると、コード リスト 9-3 の情報が自動的に更新されます。WLI_HOME
/adapters/ADAPTER/src/overview.html
を開いて、この情報をコピーし、config.xml
エントリに貼り付けることができます。
src/war
ディレクトリ内で変更し、WAR ターゲットを再構築します。一時ディレクトリ内の JSP は変更しないでください。WAR ファイルが作成されると、これは、特定の JSP への変更のみを取り上げる WebLogic Server によってモニタされるディレクトリにも抽出されます。WebLogic Server が実行するモニタの間隔は、WEB-INF/weblogic.xml
にある pageCheckSeconds
パラメータで指定されます。
コード リスト 9-4 にこのパラメータの設定方法を示します。
<jsp-descriptor>
<jsp-param>
<param-name>compileCommand</param-name>
<param-value>/jdk130/bin/javac.exe</param-value>
</jsp-param>
<jsp-param>
<param-name>keepgenerated</param-name>
<param-value>true</param-value>
</jsp-param>
<jsp-param>
<param-name>pageCheckSeconds</param-name>
<param-value>1</param-value>
</jsp-param>
<jsp-param>
<param-name>verbose</param-name>
<param-value>true</param-value>
</jsp-param>
</jsp-descriptor>
Web アプリケーションで使用するフォームごとに「設計時フォーム処理の概要」で説明する手順を実行すると、プロセスが冗長になりエラーの原因にもなります。設計時フレームワークでは、MVC (Model-View-Controller) パラダイムをサポートすることにより、このプロセスが簡素化されます。
設計時 GUI を実装するには、DesignTimeRequestHandler
クラスを実装する必要があります。このクラスでは、フォームからのユーザ入力を受け入れ、設計時 GUI のアクションを実行します。このクラスを実装するには、ADK の AbstractDesignTimeRequestHandler
を拡張する必要があります。このオブジェクトが提供するメソッドの詳細については、DesignTimeRequestHandler
クラスの Javadoc を参照してください。
AbstractDesignTimeRequestHandler
は、WebLogic Server でアプリケーション ビューをデプロイ、編集、コピー、削除するためのユーティリティ クラスを提供します。これにより、アプリケーション ビュー記述子にアクセスできます。アプリケーション ビュー記述子では、アプリケーション ビューに適用する接続パラメータ、イベント リスト、サービス リスト、ログ レベル、およびプールの設定が提供されます。[アプリケーション ビューの概要] ページに、各パラメータが表示されます。
AbstractDesignTimeRequestHandler
は、すべてのアダプタに共通するすべてのアクションに適用できる実装を提供します。主なアクションは以下のとおりです。
注意 : ADK には、CCI 接続を取得するための接続パラメータを処理するメソッドはありますが、confconn.jsp
ページは提供されません。このフォームの作成方法については、「手順 5a : confconn.jsp フォームの作成」を参照してください。
これらのアクションを正しく実行するには、AbstractDesignTimeRequestHandler
を実装する際に、以下のメソッドを指定する必要があります。
initServiceDescriptor();
このメソッドにより、設計時にアプリケーション ビューにサービスが追加されます (「手順 4b : initServiceDescriptor() の実装」を参照)。
initEventDescriptor();
このメソッドにより、設計時にアプリケーション ビューにイベントが追加されます (「手順 4c : initEventDescriptor() の実装」を参照)。
AbstractDesignTimeRequestHandler
の各具象実装に、以下の 2 つのメソッドを指定する必要があります。
ManagedConnectionFactory
クラスを指定するには、以下のメソッドを実装する必要があります。
protected Class getManagedConnectionFactoryClass();
このメソッドにより、アダプタに対する SPI の ManagedConnectionFactory
実装クラスが返されます。このクラスは、AbstractManagedConnectionFactory
が EIS への接続を試行する際に必要です。
サービス接続では、アダプタのユーザが設計時にサービスを追加できるように、initServiceDescriptor()
を実装する必要があります。このメソッドの実装を コード リスト 9-5 に示します。
コード リスト 9-5 initServiceDescriptor() の実装
protected abstract void initServiceDescriptor(ActionResult result,
IServiceDescriptor sd,
HttpServletRequest request)
throws Exception
このメソッドは、AbstractDesignTimeRequestHandler
の addservc()
の実装によって呼び出されます。このメソッドにより、IServiceDescriptor
パラメータに関連付けられた EIS 固有の情報が初期化されます。addservc()
の基本クラスを実装することにより、エラー処理などを実行します。ユーザが addservc
JSP を送信すると、addservc()
メソッドが呼び出されます。
イベント接続では、アダプタのユーザが設計時にイベントを追加できるように、initEventDescriptor()
を実装する必要があります。このメソッドの実装を コード リスト 9-6 に示します。
コード リスト 9-6 initEventDescriptor()
の実装
protected abstract void
initEventDescriptor(ActionResult result,
IEventDescriptor ed,
HttpServletRequest request)
throws Exception;
このメソッドは、AbstractDesignTimeRequestHandler
の addservc()
の実装によって呼び出されます。このメソッドにより、IServiceDescriptor
パラメータに関連付けられた EIS 固有の情報が初期化されます。addevent()
の基本クラスを実装することにより、エラー処理などを実行します。ユーザが addevent
JSP を送信すると、addevent()
メソッドが呼び出されます。addevent
には共通のロジックが含まれ、EIS 固有のロジックが initEventDescriptor()
に委託されるので、この JSP はオーバーライドしないでください。
注意 : サービス記述子にプロパティを追加する場合は、Bean 属性の命名規約に従って名前を指定する必要があります。従わない場合、サービス記述子が InteractionSpec
を正しく更新しません。
設計時 GUI を実装する最後の手順は、インタフェースを構成する各種のフォームを記述することです。フォームの作成に慣れるためには、以下の節を参照してください。
以下の節では、これらのフォームのコードの記述方法を説明します。フォームのサンプル コードも紹介します。
このページでは、ユーザが EIS 用の接続パラメータを指定するための HTML フォームを提供します。このページには、アダプタの設計時 Web アプリケーションを表示する必要があります。このフォームは doAction=confconn
によって ControllerServlet
にポストされます。つまり、設計時インタフェースの RequestHandler
で以下のメソッドを指定する必要があります。
public ActionResult confconn(HttpServletRequest request) throws
Exception
このメソッドを実装すると、指定した接続パラメータに基づいてアダプタの ManagedConnectionFactory
の新しいインスタンスを作成できます。ManagedConnectionFactory
により、EIS への接続を設定するための CCI ConnectionFactory
が指定されます。このため、confconn フォームの送信を処理することにより EIS に接続するために必要なパラメータが正しく指定されているかどうかが検証されます。
サンプル アダプタの confconn
フォームをコード リスト 9-7 に示します。
コード リスト 9-7 confconn.jsp のコーディング
1 <%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
2 <form method='POST' action='controller'>
3 <table>
4 <tr>
5 <td><adk:label name='userName' required='true'/></td>
6 <td><adk:text name='userName' maxlength='30' size='8'/></td>
7 </tr>
8 <tr>
9 <td><adk:label name='password' required='true'/></td>
10 <td><adk:password name='password' maxlength='30'size='8'/></td>
11 </tr>
12 <tr>
13 <td colspan='2'><adk:submit name='confconn_submit'
doAction='confconn'/></td>
14 </tr>
15 </table>
16 </form>
以下の節では、コード リスト 9-7 の内容を説明します。
コード リスト 9-7 の行 1 で、JSP エンジンに ADK タグ ライブラリをインクルードするように指定します。
<%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
ADK が提供するタグは、表 9-3 に示します。
コード リスト 9-7 の行 2 で、フォームが ControllerServlet
にポストされます。
<form method='POST' action='controller'>
ControllerServlet
は、Web アプリケーションに使用する web.xml
ファイルでコンフィグレーションされます。このクラスは、RequestHandler
で実行するメソッドに HTTP リクエストを委託します。ControllerServlet
を使用するためにコードを指定する必要はありません。ただし、表 9-5 に示す初期パラメータを指定する必要があります。
コード リスト 9-7 の行 5 で、フォームのフィールドのラベルを表示します。
<adk:label name='userName' required='true'/>
表示する値は、ユーザのメッセージ バンドルから取得します。required
属性により、ユーザによるこのパラメータの指定が必須かどうかを示します。
コード リスト 9-7 の行 6 で、テキスト フィールドにサイズ 8、最大長 30 が設定されます。
<adk:text name='userName' maxlength='30' size='8'/>
コード リスト 9-7 の行 13 で、アダプタのユーザが入力を送信するためのボタンをフォームに表示します。
<adk:submit name='confconn_submit' doAction='confconn'/>
ボタンのラベルは、confconn_submit
キーを使用してメッセージ バンドルから取得されます。フォーム データを送信すると、ControllerServlet
が登録済みのリクエスト ハンドラ (RequestHandlerClass
プロパティを参照) で confconn
メソッドを検索し、リクエスト データをリクエスト ハンドラに渡します。
AbstractDesignTimeRequestHandler
により、confconn()
メソッドが実装されます。このメソッドの実装によって、Java Reflection API を利用して、アダプタの ManagedConnectionFactory
インスタンスのセッター メソッドに、ユーザが指定した接続パラメータがマップされます。アダプタの ManagedConnectionFactory
に具象クラスを指定するだけで済むようになります。このクラスを指定するには、以下のメソッドを実装します。
public Class getManagedConnectionFactoryClass()
このフォームを使用すると、アプリケーション ビューに新しいイベントを追加できます。このフォームは EIS 固有です。サンプル アダプタの addevent.jsp
フォームをコード リスト 9-8 に示します。
コード リスト 9-8 addevent.jsp フォームを作成するサンプル コード
1 <%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
2 <form method='POST' action='controller'>
3 <table>
4 <tr>
5 <td><adk:label name='eventName' required='true'/></td>
6 <td><adk:text name='eventName' maxlength='100' size='50'/></td>
7 </tr>
8 <tr>
9 <td colspan='2'><adk:submit name='addevent_submit'
doAction='addevent'/></td>
10 </tr>
11 </table>
12 </form>
以下の節では、addevent.jsp
の内容を説明します。
コード リスト 9-8 の行 1 で、JSP エンジンに ADK タグ ライブラリをインクルードするように指定します。
<%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
ADK が提供するタグは、表 9-3 に示します。
コード リスト 9-8 の行 2 で、フォームが ControllerServlet
にポストされます。
<form method='POST' action='controller'>
ControllerServlet
は、Web アプリケーションに使用する web.xml
ファイルでコンフィグレーションされます。このクラスは、RequestHandler
で実行するメソッドに HTTP リクエストを委託します。ControllerServlet
を使用するためにコードを指定する必要はありません。ただし、表 9-5「ControllerServlet の初期パラメータ」に示すように、初期パラメータを指定する必要があります。
コード リスト 9-8 の行 5 で、フォームのフィールドのラベルを表示します。
<adk:label name='eventName' required='true'/>
表示する値は、ユーザのメッセージ バンドルから取得します。required
属性により、ユーザによるこのパラメータの指定が必須かどうかを示します。
コード リスト 9-8 の行 6 で、テキスト フィールドにサイズ 50、最大長 100 が設定されます。
<adk:text name='eventName' maxlength='100' size='50'/>
コード リスト 9-8 の行 9 で、アダプタのユーザが入力を送信するためのボタンをフォームに表示します。
<adk:submit name='addevent_submit' doAction='addevent'/>
ボタンのラベルは、addevent_submit
キーを使用してメッセージ バンドルから取得されます。フォーム データを送信すると、ControllerServlet
が登録済みのリクエスト ハンドラ (RequestHandlerClass
プロパティを参照) で addevent()
メソッドを検索し、リクエスト データをリクエスト ハンドラに渡します。
イベントの定義に必要なその他のフィールドを追加する必要があります。複数のフィールドを使用したフォームの例については、「DBMS サンプル アダプタを使用したアダプタの開発方法の学習」を参照してください。
このフォームを使用すると、アプリケーション ビューに新しいサービスを追加できます。このフォームは EIS 固有です。サンプル アダプタの addservc.jsp
フォームをコード リスト 9-9 に示します。
コード リスト 9-9 addservc.jsp のコーディング
1 <%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
2 <form method='POST' action='controller'>
3 <table>
4 <tr>
5 <td><adk:label name='serviceName' required='true'/></td>
6 <td><adk:text name='serviceName' maxlength='100' size='50'/></td>
7 </tr>
8 <tr>
9 <td colspan='2'><adk:submit name='addservc_submit'
doAction='addservc'/></td>
10 </tr>
11 </table>
12 </form>
コード リスト 9-9 の行 1 で、JSP エンジンに ADK タグ ライブラリをインクルードするように指定します。
<%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
タグ ライブラリでは、ADK で提供される使いやすいフォーム検証機能がサポートされます。ADK タグ ライブラリには、表 9-3 に示すタグが用意されています。
コード リスト 9-9 の行 2 で、フォームが ControllerServlet
にポストされます。
<form method='POST' action='controller'>
ControllerServlet
は、Web アプリケーションに使用する web.xml
ファイルでコンフィグレーションされます。このクラスは、RequestHandler
で実行するメソッドに HTTP リクエストを委託します。ControllerServlet
を使用するためにコードを指定する必要はありません。ただし、表 9-5「ControllerServlet の初期パラメータ」に示すように、初期パラメータを指定する必要があります。
コード リスト 9-9 の行 5 で、フィールドのラベルを表示します。
<adk:label name='serviceName' required='true'/>
表示する値は、ユーザのメッセージ バンドルから取得します。required
属性により、ユーザによるこのパラメータの指定が必須かどうかを示します。
コード リスト 9-9 の行 6 で、テキスト フィールドにサイズ 50、最大長 100 が設定されます。
<adk:text name='serviceName' maxlength='100' size='50'/>
コード リスト 9-9 の行 9 で、アダプタのユーザが入力を送信するためのボタンをフォームに表示します。
<adk:submit name='addservc_submit' doAction='addservc'/>
ボタンのラベルは、addservc_submit
キーを使用してメッセージ バンドルから取得されます。フォーム データを送信すると、ControllerServlet
が登録済みの RequestHandler
(RequestHandlerClass
プロパティを参照) で addservc
メソッドを検索し、リクエスト データをリクエスト ハンドラに渡します。
サービスの定義に必要なその他のフィールドを追加する必要があります。複数のフィールドを使用したフォームの例については、「DBMS サンプル アダプタを使用したアダプタの開発方法の学習」を参照してください。
設計時にアダプタのユーザに対してイベントやサービスを編集する機能を有効にする場合は、アダプタ プロパティを編集し、edtservc.jsp
と edtevent.jsp
のフォームを作成して、特定のメソッドを実装する必要があります。ここでは、以下のタスクについて説明します。
注意 : この手順は省略可能です。ユーザにこれらの機能を提供する必要はありません。
最初にアダプタ プロパティ ファイルを以下のように変更し、サンプル アダプタに合わせてシステム プロパティを更新します。
edtservc_title=Edit Service
edtservc_description=On this page, you edit service properties.
edtevent_description=On this page, you edit event properties.edtevent_title=Edit Event
glossary_description=This page provides definitions for commonly used terms.
service_submit_add=Add
service_label_serviceDesc=Description:
service_submit_edit=Edit
service_label_serviceName=Unique Service Name:
event_submit_add=Add
event_label_eventDesc=Description:
event_label_eventName=Unique Event Name:
event_submit_edit=Edit
eventLst_label_edit=Edit
serviceLst_label_edit=Edit
event_does_not_exist=Event {0} does not exist in application view {1}.
service_does_not_exist=Service {0} does not exist in Application View {1}.
no_write_access={0} does not have write access to the Application View.
addservc_submit_add=Add
addevent_label_eventDesc=Description:
addservc_label_serviceName=Unique Service Name:
addevent_submit_add=Add
pingTable_invalid=The ping table cannot be reached.Please enter a valid table in the existing database to ping.
pingTable=Ping Table
addevent_label_eventName=Unique Event Name:
addservc_label_serviceDesc=Description:
アダプタ プロパティ ファイルを更新した後、新しいファイルを元のファイルと比較し、同期していることを確認します。
これらの JSP は編集機能を提供するために呼び出されるファイルです。編集 JSP ファイルと追加 JSP ファイルの主な違いは、記述子の値のロード方法です。編集 JSP ファイルは、既存の記述子の値をロードします。このため、DBMS サンプル アダプタでの編集および追加には、同じ HTML ファイルを使用します。
これらの HTML ファイルは各 JSP ページに静的にインクルードされます。これにより、JSP/HTML とプロパティを複製する必要がなくなります。記述子の値は編集ページに表示するコントロールにマップされます。ここから、任意の変更を送信できます。
記述子に定義された値でコントロールを初期化するには、AbstractDesignTimeRequestHandler
で loadEvent/ServiceDescriptorProperties()
メソッドを呼び出します。このメソッドにより、サービスのプロパティがすべて、RequestHandler
に設定されます。これらの値を設定すると、RequestHandler
により JSP ファイルで使用する ADK コントロールに各値がマップされます。
loadEvent/ServiceDescriptorProperties()
をデフォルトの設定で実装すると、ADK タグに関連付けられたプロパティ名を使用して、記述子の値がマップされます。ADK タグ名以外の値を使用してサービスやイベントのプロパティをマップする場合は、これらの値をオーバーライドして ADK タグ名マッピングに記述子を渡す必要があります。
また、HTML を解決する前に、RequestHandler
を初期化する必要があります。この初期化は 1 度だけ実行します。edtevent.jsp
のロード時に使用するコード例をコード リスト 9-10 に示します。
コード リスト 9-10 edtevent.jsp
のロード時に使用するサンプル コード
if(request.getParameter("eventName") != null){
handler.loadEventDescriptorProperties(request);
}
edtservc.jsp
ファイルを edtservc
に送信する必要があります。
<adk:submit name='edtservc_submit' doAction='edtservc'/>
edtevent.jsp
ファイルを edtevent
に送信する必要があります。
<adk:submit name='edtevent_submit' doAction='edtevent'/>
WLI_HOME/adapters/dbms/src/war
最後に、表 9-6 に示すメソッドを実装します。
各メソッドの実装例については、サンプル アダプタを参照してください。
一般に、アダプタ用の web.xml
記述子と weblogic.xml
記述子により、単純なパターンに従って、設計時 Web アプリケーションのすべての JSP ページ名と、設計時 Web アプリケーションのその他の設定情報がリストされます。多くのアダプタの Web 記述子は非常に似ているため、ADK には自動的に Web 記述子を生成する方法が用意されています。そのためアダプタ開発者は、サイズが大きく、他のアダプタの Web 記述子とほとんど一致するような Web 記述子を管理する必要がなくなります。
使用するアダプタの Ant build.xml
で特別な Ant 対象をインクルードおよび呼び出すことで、Web アプリケーション記述子を生成しなければならないことがあります。GenerateAdapterTemplate
を使用して ADK サンプル アダプタのクローンを作成する場合、作成される build.xml
には必要な Ant 対象およびその対象を使用するための呼び出しがすでに含まれています。WLI_HOME
/adapters/sample/project/build.xml
を参照して、generate_web_descriptors
対象を検索してください。この Ant 対象には web-gen.properties
と呼ばれるファイルがあり、そこに格納されている情報から web.xml
および weblogic.xml
記述子を生成します。サンプル アダプタ build.xml
では、この対象は packages
対象の最上位付近で呼び出されます。
サンプル アダプタには、アダプタに指定する際のテンプレートとして機能する web-gen.properties
ファイルが含まれています。このファイルで設定するプロパティとその意味を以下に示します。
display-name
- web.xml の display-name 要素に使用される値。使用するアダプタのアダプタ論理名です (たとえば、サンプル アダプタでは BEA_WLS_SAMPLE_ADK)。version
- web.xml の version 要素に使用される設計時 Web アプリケーションのバージョンとその値。GenerateAdapterTemplate で使用した値と同じ値にします (たとえば、サンプル アダプタでは 8.1.0)。request-handler-class
- アダプタの設計時リクエスト ハンドラ実装クラスの完全なクラス名。AbstractDesignTimeRequestHandler を拡張し、通常は <アダプタのパッケージ>.web.DesignTimeRequestHandler にあるクラスです。adapter-logical-name
- 使用するアダプタのアダプタ論理名。GenerateAdapterTemplate で使用した値と同じ値にします (たとえば、サンプル アダプタでは BEA_WLS_SAMPLE_ADK)。debug-setting
- 「on」または「off」のいずれかの値。値を「on」にすると、ソース コードに配置された (またはサンプル アダプタのソース コードを作成したときに取り込まれた)、ILogger.debug() メソッドを使用するデバッグ文が有効になります。値を「off」にするとデバッグ文は無効になり、ログ ファイルへの書き込みは行われません。extra-jsp-list
- 「追加の」JSP のカンマ区切りのリスト。「標準の」JSP には以下のものがあります。
addevent、addservc、confconn、edtevent、edtservc、event、service、testform、varset
設計時 GUI の開発時に採用すべき重要なプログラミング手法は、アプリケーション ビューで使用するすべてのページで一貫したルック アンド フィールを実装することです。ルック アンド フィールは display.jsp
によって決定されます。このページは ADK に組み込まれており、設計時 Web アプリケーションに以下の利点をもたらします。
content
HTTP リクエスト パラメータに基づいてその他の JSP をインクルードできる。content
HTTP リクエスト パラメータがない場合は、display.jsp
ファイルに main.jsp
をインクルードする必要があります。error.jsp
として登録できる。一連のページで一貫したルック アンド フィールを実装するには
この手順は省略可能です。環境変数は、システム管理者や WebLogic Integration アプリケーション デプロイヤが、デプロイ対象の環境に応じて環境固有の情報に新しい値を指定できるように、アプリケーション ビュー内にある環境固有の情報を分離するためのものです。環境に固有と判断できるイベントやサービスのプロパティがアダプタに含まれていない場合は、アダプタで環境変数を実装する必要はありません。DBMS サンプル アダプタでイベントやサービスのプロパティに含まれる環境固有の情報の例としては、以下のものがあります。
環境変数を実装するかどうかを決定する場合には、イベントおよびサービス接続情報は考慮しないでください。本来、接続情報は、接続先の EIS インスタンスに固有のものです。環境変数は、イベントおよびサービスを定義する際に環境固有の情報を分離するためにのみ使用されます。
アダプタで環境変数のサポート機能を実装する場合は、アダプタの設計時 GUI と実行時段階の両方でこのサポート機能を設定する必要があります。実行時の考慮事項の詳細については、「サービス アダプタの開発」を参照してください。
設計時 GUI では、以下の 2 種類の手順で、環境変数のサポート機能を追加できます。
addevent
/edtevent
/addservc
/edtservc
JSP ページから varset.jsp
を追加する。この追加 JSP により、環境変数セットを表示および変数するときに使用する HTML テーブルが提供されます。この変数セットは、定義されるアプリケーション ビューとともに格納されます。varset.jsp
テーブルに表示される変数を参照する変数マーカを受け入れるようにする。アプリケーション ビューの変数セットを表示および編集する際によく使われる方法は、イベントとサービスを定義する JSP ページに varset.jsp
JSP ページを追加する方法です。これは、以下の JSP コードを追加することで実行できます。
<p>
<hr>
<p>
<jsp:include page='varset.jsp'>
<jsp:param name='mode' value='writeable'/>
<jsp:param name='hostPage' value='addservc'/>
</jsp:include>
これにより、アプリケーション ビューの環境変数を表示および編集するときに、水平線の下にテーブルが表示されます。この varset.jsp
テーブルで、ユーザが変数の定義を追加、削除、および編集できます。varset.jsp
JSP の使用例については、DBMS サンプル アダプタを参照してください。このコードの mode パラメータは常に writable にし、hostPage
パラメータは、変数セット JSP をホストしている JSP の名前にする必要があります (.jsp
拡張子は付けない)。
注意 : varset.jsp
JSP ページを使用せずに、独自の変数を定義することができます。com.bea.connector
パッケージで定義されている IMutableVariableSet
インタフェースを使用して、アプリケーション ビューに定義された変数を制御できます。以下のコードは、アプリケーション ビュー記述子を取得し、これに対して myVariable
という新しい変数を定義する方法を示します。
import com.bea.wlai.common.IApplicationViewDescriptor;
import com.bea.connector.IMutableVariableSet;
IApplicationViewDescriptor avd = getApplicationViewDescriptor();
IMutableVariableSet varSet = avd.getMutableVariableSet();
// 変数を追加する
IVariable myVar = varSet.addVariable("myVariable", "string", "My Variable",
"the default value");
// 次に、変数を削除する
varSet.removeVariable("myVariable");
varset.jsp
JSP ページを追加してあれば、このページで定義できる環境変数を使用することができます。環境変数の使用方法は、アダプタの性質と、アダプタに保持される環境固有の情報によって異なります。
通常、環境変数を使用して設定するのは、イベントまたはサービスのプロパティの値の一部またはすべてのいずれかです。実行時に環境変数によって設定される値は、デフォルト値にすることも、システム管理者またはアプリケーション デプロイヤが変数に設定した特定の値にすることもできます。変数をプロパティの値の一部に使用するか、その値全体に使用するかは、作成者が決定できます。
DBMS サンプル アダプタでは、場合により、変数をプロパティ値全体として使用したり (たとえば、イベントのカタログ名やスキーマ名)、プロパティ値の一部として使用したり (たとえば、サービスの SQL 文中のカタログ名やスキーマ名) しています。DBMS サンプル アダプタでは、変数名に中括弧を付けて {var_name
} と表記することで、環境変数が使用されていることを示しています。イベントとサービスのいずれでもこの構文が使用されます。中括弧で変数名を区切るのは、中括弧が SQL 構文では予約された文字でも有効な文字でもないためです。したがって、DBMS サンプル アダプタでは、パーサで混同が生じることなく、SQL 文で確実に中括弧を解析できます。
アダプタでは、プロパティ値で変数参照をユニークかつ安全に識別するためのさまざまな規約が必要となる場合があります。
イベントおよびサービスのプロパティ値で変数参照を表記する方法を決定すると、これらのプロパティ値で使用されている変数を検証するときに必要なコードを記述できます。以下の規則が適用されます。
varset.jsp
を使用) 定義した環境変数と一致していなければならない。 実行時に、Application Integration エンジンにより変数とその値がセットで設定されます。実行時のアダプタ コードでは、設定済みプロパティ値のすべての変数参照の代わりに、変数の実行時の値を使用する必要があります。詳細については、「サービス アダプタの開発」または「イベント アダプタの開発」を参照してください。
varset.jsp
によって (設計時に) 定義された変数のリストを入手するには、スーパークラス (AbstractDesignTimeRequestHandler
) メソッドの呼び出しにより設定される IApplicationViewDescriptor
を取得します。
import com.bea.connector.IVariableSet;
IApplicationViewDescriptor avd = getApplicationViewDescriptor();
IVariableSet varSet = avd.getVariableSet();
// 変数名をリストに表示する
String[] varNames = varSet.listVariableNames();
// 最初の変数を取得する
IVariable var = varSet.getVariable(varNames[0]);
WebLogic Integration には、サンプル アダプタの設計時インタフェースの基本機能を検証するためのテスト ドライバが用意されています。このテスト ドライバは、http://www.httpunit.org にあるテスト用 Web インタフェースのフレームワークである HTTP ユニットを基準に作成されています。HTTP ユニットは、JUnit テスト フレームワーク (http://www.junit.org で入手可) に関連しています。HTTP ユニットと JUnit の両バージョンが WebLogic Integration に組み込まれています。
テスト ドライバではいくつかのテストが実行されます。これによりアプリケーション ビューが作成されてイベントとサービスの両方がアプリケーション ビューに追加され、アプリケーション ビューにデプロイ/アンデプロイを実行し、イベントとサービスの両方についてテストを実行します。正常に実行が終了すると、テスト ドライバはすべてのアプリケーション ビューを削除します。
すべてのテスト ケースが、DesignTimeTestCase
クラス、または対応する親クラス (AdapterDesignTimeTestCase
) で有効です。DesignTimeTestCase
クラス (sample.web
パッケージ、および WLI_HOME
/adapters/sample/src/sample/web
フォルダ内) には、サンプル アダプタに固有のテストが組み込まれています。AdapterDesignTimeTestCase
(com.bea.adapter.web
パッケージ、および WLI_HOME
/lib/adk-web.jar
ファイル内) には、すべてのアダプタと一部の便利なメソッドに適用されるテストが組み込まれています。
設計時インタフェースをテストするには、以下の一連の手順を実行します。
cdWLI_HOME
/adapters/sample/project
designTimeTestCase.properties
ファイルを編集します。実行するテスト ケースのリストを含む行に、web.DesignTimeTestCase
を追加します。以下のような行になります。
test.case=web.DesignTimeTestCase
ant designtimetest
![]() ![]() |
![]() |
![]() |