| Oracle® Fusion Middleware Oracle Application Development Frameworkモバイル開発者ガイド 11g リリース2 (11.1.2.3.0) B70750-01 |
|
![]() 前 |
![]() 次 |
この章では、サード・パーティのWebサービスをADFモバイルAMXアプリケーション機能の実装に統合する方法について説明します。
この章では、次の項目について説明します。
Webサービスでは、アプリケーションおよびその機能は、定義済のアプリケーション・プログラミング・インタフェースを使用してデータと情報を交換できます。Webサービスを使用すると、元のアプリケーションのプラットフォームや言語に関係なくビジネス機能を公開できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusion WebアプリケーションのWebサービスの概要に関する項を参照してください。
ADFモバイルでは、SOAPとRESTの両方のWebサービスをサポートしており、サード・パーティのWebサービスをADFモバイルAMXアプリケーション機能に統合できます。
ADFモバイルで開発したアプリケーション機能でWebサービスを使用する方法の中では、Webサービスのデータ・コントロールを作成する方法が最も一般的です。これは通常、次の理由で実行されます。
Webサービスとしてはすぐに利用できるが、アプリケーション内で開発するには時間がかかる機能を追加するため
異なるアーキテクチャで実行されるアプリケーションへのアクセスを提供するため
ADFモバイルで作成されたコンポーネントの再利用を可能にし、それらを他のアプリケーションのWebサービスとして利用可能にするため
Webサービス・データ・コントロールおよびその使用方法の詳細は次を参照してください。
『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のWebサービス・データ・コントロールに関する項
『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のREST Webサービス・データ・コントロールに関する項
『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のOracle ADF Fusion Webアプリケーションでのデータ・コントロールに関する付録
『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のデータ・コントロール・パネルの使用方法に関する項
JDeveloperでは、そのサービスのWeb Services Description Language(WSDL)ファイルのみを使用して、既存のSOAP Webサービスのデータ・コントロールを作成します。ローカル・ファイル・システムでWSDLファイルを参照するか、Universal Description, Discovery and Integration(UDDI)レジストリでWSDLファイルを検索するか、WSDL URLを直接入力することができます。
|
注意: ファイアウォールで保護されている環境で、ファイアウォール外にあるWebサービスを使用する場合は、JDeveloperで「Webブラウザとプロキシ」の設定を構成する必要があります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のブラウザ・プロキシ情報の設定に関する項を参照してください。 |
SOAP Webサービス・データ・コントロールを作成するには:
アプリケーション・ナビゲータでアプリケーション名を右クリックして、JDeveloperのメイン・メニューから「ファイル」→「新規」を選択します。
「新規ギャラリ」ダイアログで、左側の「ビジネス層」ノードを開いて「Webサービス」を選択します。右側の「アイテム」リストから「Webサービス・データ・コントロール」を選択して(図10-1を参照)、「OK」をクリックします。
ウィザードの指示に従って、データ・コントロールの作成を完了します。
|
注意: ADFモバイルでは、SOAP 1.1および1.2の両方のバージョンで次のエンコーディング・スタイルをサポートしています。
|
Webサービス・データ・コントロールの作成後は、Webサービスの操作およびその操作の戻り値が「データ・コントロール・パレット」に表示され、そのページでは、Webサービスの操作により戻されるオブジェクトを適切なADFモバイルAMX UIコンポーネントとしてドラッグ・アンド・ドロップできます。詳細は、第7.3.2.4項「データ・コントロールのビューへの追加」を参照してください。Webサービスの操作から戻されたデータが表示されると、次のオブジェクト・タイプが処理されます。
コレクション
Webサービスの操作により戻された複合オブジェクト
Webサービスの操作により戻された、ネストされた複合オブジェクト
Webサービスの操作を使用して、データの更新(標準データ型と複合オブジェクトの両方を含む)および削除ができます。
JDeveloperでは、既存のREST Webサービスのデータ・コントロールを作成できます。
|
注意: ファイアウォールで保護されている環境で、ファイアウォール外にあるWebサービスを使用する場合は、JDeveloperで「Webブラウザとプロキシ」の設定を構成する必要があります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のブラウザ・プロキシ情報の設定に関する項を参照してください。 |
同じ接続を使用して、REST Webサービス・データ・コントロール(URLサービス・データ・コントロールとも呼ばれる)に1つ以上のHTTPメソッドを関連付けることができます。標準のHTTPメソッド以外にもRESTサービスにより公開されたカスタム操作にアクセスできます。これらのカスタム操作は、HTTPメソッドの1つにマップされ、データ・コントロールを作成することでクライアントに公開できます。
モバイル・デバイスでセキュリティおよび通知機能を使用する場合は、RESTデータ・コントロールによって公開された特定の操作で使用する標準のHTTPヘッダーにカスタム・ヘッダーおよびカスタム値を追加できます。
始める前に:
データ・コントロールがアクセスするREST Webサービスへのアクセス権があることを確認します。
REST Webサービス・データ・コントロールを作成するには:
アプリケーション・ナビゲータでアプリケーション名を右クリックして、JDeveloperのメイン・メニューから「ファイル」→「新規」を選択します。
「新規ギャラリ」ダイアログで、左側の「ビジネス層」ノードを開いて「データ・コントロール」を選択します。右側の「アイテム」リストから「URLサービス・データ・コントロール」を選択して(図10-2を参照)、「OK」をクリックします。
「URLサービス・データ・コントロールの作成」ウィザードの説明に従って、次の点に注意しながらデータ・コントロールの作成を完了します。
ADFモバイルでは、Webサービスに対して基本認証のみをサポートしています(第10.5項「セキュアなWebサービスへのアクセス」を参照)。「接続」ページを完了する際は、「認証タイプ」フィールドの「基本」を選択します。
ADFモバイルでは、GET、POST、PUTおよびDELETEのすべてのHTTPメソッド・タイプをサポートしています。「接続」ページの「HTTPメソッド」フィールドを入力すると、これらのメソッド・タイプを選択できます。
|
注意: 同じ接続および同じREST Webサービス・データ・コントロールを使用して4つのメソッドをすべて追加できます。 |
ADFモバイルでは、「パラメータ」ページにリストされたすべての設定がサポートされます。
ADFモバイルでは、スプレッド・シート・データ内の区切り文字で区切られた値およびXMLデータ・フォーマットのXSLはサポートされません。「データ・フォーマット」ページを入力する際は、「XML」またはXML用のXSDフォーマットのいずれかを指定します。
URLサービス・データ・コントロール定義にローカルXSDファイルを指定することで、「スキーマ」フィールドにファイルURI参照を作成します。
|
注意: ADFモバイルではコンパイル時にXSD構造の内部定義を作成するため、アプリケーションのコンパイル後はXSDを変更しないようにします。したがって、XSDファイルをローカルで参照することをお薦めします。リモートXSDの使用がパフォーマンスに悪影響を与えるのは、ADFモバイルではアプリケーションを実行するたびにXSDを取得するためです。 |
前述の手順に従って作成されたREST Webサービス・データ・コントロールは、Oracle ADFのデータ・コントロールと同様に動作します。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のURLサービスに関する項を参照してください。
データ・コントロールを使用しないJavaによるREST Webサービスの使用方法の詳細は、第10.6.1項「REST Webサービス・アダプタの使用方法」を参照してください。
Webサービスの接続情報は、アプリケーション内の他の接続とともにconnections.xmlファイルに保存されます。このファイルは、Webサービス・データ・コントロールの作成時に新しいWebサービス・データ・コントロールウィザードによって.adf/META-INFディレクトリに生成されるため、明示的に作成する必要はありません(第10.2項「Webサービス・データ・コントロールの作成」を参照)。
接続設定を変更するには、connections.xmlファイルを編集します。
Webサービス・データ・コントロールを作成すると、URIのエンドポイントを変更できます。これは、機能をテスト環境から本番環境に移行するような場合に役に立ちます。
エンドポイントを変更するには、connections.xmlファイルを編集します。
ADFモバイルでは、HTTPおよびHTTPS経由の基本認証(BASIC_AUTH)とともに、保護されたWebサービスおよび非保護のWebサービスの両方がサポートされます。
詳細は、次の項を参照してください。
Oracle Fusion Middleware Webサービスの管理のポリシーの構成に関する項
ADFモバイル・アプリケーションから保護されたWebサービスにアクセスするには、アプリケーションに追加されたWebサービス・データ・コントロールの構成が必要な場合もあります。
SOAPベースのWebサービスでは次のセキュリティ・ポリシーがサポートされます。
oracle/wss_http_token_client_policy
oracle/wss_http_token_over_ssl_client_policy
oracle/http_basic_auth_over_ssl_client_policy
oracle/wss_username_token_client_policy
oracle/wss_username_token_over_ssl_client_policy
SOAP Webサービスが保護されている場合は、oracle/wss_http_token_over_ssl_client_policyまたはoracle/wss_http_token_client_policyのいずれかでWebサービス・データ・コントロールを構成することでアクセスが可能になります。これを行うには、図10-2に示す「データ・コントロール・ポリシーの編集」ダイアログを使用します。このダイアログは次の方法で開くことができます。
ナビゲータで.dcxファイルを選択します。
「構造」ペインで、構成が必要なWebサービス・データ・コントロールを右クリックし、ポップアップ・メニューから「Webサービス・セキュリティの定義」を選択します。
RESTベースのWebサービスでサポートされるセキュリティ・ポリシーは1つのみのため、ADFモバイルでは、HTTPS経由でのREST Webサービスにはoracle/wss_http_token_over_ssl_client_policy、HTTPプロトコル経由でのREST Webサービスにはoracle/wss_http_token_client_policyを自動追加し、Oracle Web Services Manager (OWSM) Lite MobileのADFアプリケーション・エージェントが適切なセキュリティ・ヘッダーを挿入できるようにします。
保護されたWebサービスにおけるユーザーの資格証明は、Webサービス・リクエストの起動時にそのリクエストに動的に挿入されます。このプロセスは、SOAP WebサービスとREST Webサービスで似ています。
ADFモバイルでは、Oracle Web Services Manager (OWSM) Lite MobileのADFアプリケーション・エージェントを使用してプロキシを作成および構成するほか、そのプロキシを使用してサービスをリクエストします。ユーザーの資格証明は、プロキシの構成時にOWSM強制コンテキストに挿入されます。資格証明の挿入はOWSMプロキシによって処理されます。詳細は、Oracle Fusion Middleware Oracle Web Services Manager Java APIリファレンスを参照してください。
Webサービスを起動する前に、ユーザーは、保護されたADFモバイル・アプリケーション機能の呼出しまたはアクセス制御サービス(ACS)で制御されたアプリケーションの起動を試みるユーザーによってトリガーされた認証プロンプトに応答する必要があります。後者では、アプリケーションでACS URLを使用してデフォルトのログイン・サーバーを定義し、user.role設定に依存する制約を持つ機能を少なくとも1つは備えておく必要があります。ユーザーの資格証明は、IDM Mobile資格証明ストアと呼ばれる資格証明ストアに格納されます。この資格証明ストアは、認証プロバイダのサーバーURLおよびユーザーと関連付けられた資格証明の格納に使用される、デバイス・ネイティブかつローカルなリポジトリです。実行時に、ADFモバイルでは、すべての資格証明がその使用前にIDM Mobile資格証明ストアに格納されているものとみなします。
ADFモバイルでは、WebサービスのエンドポイントURLに対してのみ認証がサポートされます。connections.xmlファイルには、Webサービスの接続参照のcredentialStoreKey属性にログイン・サーバーの接続名を指定して、ログイン・サーバーをWebサービスのセキュリティに関連付ける必要があります(例10-1および例10-2を参照)。
|
注意:
|
例10-1は、credentialStoreKey="MyAuth"として参照されるWebサービス接続の定義を示しています。ここで、MyAuthとは、ログイン接続の参照名です。
例10-1 Webサービス接続の定義
<Reference name="URLConnection1"
className="oracle.adf.model.connection.url.HttpURLConnection"
credentialStoreKey="MyAuth"
xmlns="">
<Factory className="oracle.adf.model.connection.url.URLConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="URLConnection1">
<Contents>
<urlconnection name="URLConnection1"
url="http://myhost.us.example.com:7777/
SecureRESTWebService1/Echo">
<authentication style="challange">
<type>basic</type>
<realm>myrealm</realm>
</authentication>
</urlconnection>
</Contents>
</XmlRefAddr>
<SecureRefAddr addrType="username"/>
<SecureRefAddr addrType="password"/>
</RefAddresses>
</Reference>
例10-2は、ログイン接続の定義を示しています。ここでのMyAuthは、ログイン・サーバー接続における資格証明ストア・キーの値として使用されます。
例10-2 ログイン接続の定義
<Reference name="MyAuth"
className="oracle.adf.model.connection.adfmf.LoginConnection"
adfCredentialStoreKey="MyAuth"
partial="false"
manageInOracleEnterpriseManager="true"
deployable="true"
xmlns="">
<Factory className="oracle.adf.model.connection.adfmf.LoginConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="adfmfLogin">
<Contents>
<login url="http://172.31.255.255:7777/
SecuredWeb1-ViewController-context-root/faces/view1.jsf"/>
<logout url="http://172.31.255.255:7777/
/SecuredWeb1-ViewController-context-root/faces/view1.jsf"/>
<accessControl url="http://myhost.us.example.com:7777/
UserObjects/jersey/getUserObjects" />
<idleTimeout value="10"/>
<sessionTimeout value="36000"/>
<cookieNames>
<cookie name="JSESSIONID"/>
</cookieNames>
<userObjectFilter>
<role name="testuser1_role1"/>
<role name="testuser2_role1"/>
<privilege name="testuser1_priv1"/>
<privilege name="testuser2_priv1"/>
<privilege name="testuser2_priv2"/>
</userObjectFilter>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
認証の失敗によってWebサービス・リクエストが拒否された場合は、ADFモバイルにより適切な例外が戻され、適切なアクションが起動されます(第18.5項「ロギングの使用方法と構成」を参照)。既存の例外で状況を適切に示せない場合は、新しい例外が追加されます。
connections.xmlファイルは構成サービスの下でデプロイされ、管理されています。詳細は、第10.7項「Webサービスの管理」を参照してください。
FAR内のconnection.xmlファイルは、ADFモバイル・アプリケーションのデプロイ時に集約されます。資格証明はデプロイメント固有のデータを表しており、FAR内に格納することは想定されていません。
ADFモバイル・アプリケーションでは、JavaコードからWebサービス層(RESTおよびSOAPの両方)を起動して、その結果をJavaメソッドで使用できます。
ADFモバイルでは、使用可能なGenericTypeBeanSerializationHandlerユーティリティ・クラスが提供され、POJO (JavaBeansオブジェクト)とADFモバイルのGenericTypeオブジェクトとの間で次の変換ルールのセットに基づいて変換が実行されます。
POJOからGenericTypeオブジェクトに変換する場合:
プロパティの決定に標準JavaBeansの反映ルールが使用されます。
変換プロセスでは一時プロパティが無視されます。
読取り可能プロパティはGenericType属性に変換されます。
配列プロパティはGenericType内で繰返し属性として表されます。
マッピング・プロパティはGenericType内で個別の属性として表されます。
非プリミティブ・プロパティはネストされたGenericTypeオブジェクトとして表されます。
GenericTypeオブジェクトからPOJOに変換される場合:
プロパティの決定に標準JavaBeansの反映ルールが使用されます。
変換プロセスでは一時プロパティが無視されます。
書込み可能プロパティはGenericType属性に変換されます。
GenericType内の繰返し属性は配列オブジェクトに変換されます。
POJOにMapインタフェースが実装されている場合は、標準アクセッサを介して設定できないすべてのプロパティがMapのsetメソッドを介してPOJOに設定されます。
非プリミティブ属性はネストされたPOJOオブジェクトとして表されます。
このヘルパーAPIを使用する利点は、Webサービスから受け取ったレスポンスを取得して、1回のコールでJavaBeanに変換できることです。
たとえば、Webサービスは、ビジネス・ロジック全体で再利用する必要があるEmployeeオブジェクトを渡したり戻したりします。このオブジェクトには次のプロパティ・セットがあります。
String型のname
address(street、city、stateおよびzipcodeの各属性を持つ複合オブジェクト)
long型のid
float型のsalary
String型のphone(複数のphoneになる可能性もある)
String型のpassword(このpasswordはバックエンドのWebサービスに送信しないでください)
例10-3は、考えられるEmployeeオブジェクトのコードを示しています。
例10-3 Employeeオブジェクト
public class Employee {
protected String name;
protected Address address;
protected long id;
protected float salary;
protected String[] phone;
protected transient String password;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Address getAddress() {
return address;
}
public void setAddress(Address address) {
this.address = address;
}
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;
}
public float getSalary() {
return salary;
}
public void setSalary(float salary) {
this.salary = salary;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
public void setPassword(String password) {
this.password = password;
}
public String[] getPhone() {
return phone;
}
public void setPhone(String phone) {
this.phone = phone;
}
例10-4は、EmployeeクラスのAddressオブジェクトのコードとして考えられるものを示しています。
例10-4 Addressオブジェクト
public class Address {
protected String street;
protected String city;
protected String state;
protected String zipcode;
public String getStreet() {
return street;
}
public void setStreet(String street) {
this.street = street;
}
public String getCity() {
return city;
}
public void setCity(String city) {
this.city = city;
}
public String getState() {
return state;
}
public void setState(String state) {
this.state = state;
}
public String getZipcode() {
return zipcode;
}
public void setZipcode(String zipcode) {
this.zipcode = zipcode;
}
変換ルールについては次に注意します。
passwordは一時的に定義されるため、変換アルゴリズムに対しては無視されます。
name、address、idおよびsalaryにはすべてgetメソッドおよびsetメソッドがあるため、それらはすべてGenericTypeとの間で変換が行われます。
プロパティ・タイプに基づき、oracle.adfmf.misc.ConverterクラスのcoerceToType(Object, Class)メソッドの定義に従って、プロパティをタイプ間で強制変換できます。
addressなどの複合オブジェクトは、変換アルゴリズムによって再帰的に処理することで、変換の方向により、子であるGenericTypeを構築するか、POJO複合オブジェクトを作成してデータを移入します。
phoneはStringオブジェクトの配列で、それぞれが一意の電話番号を表しており、またこの要素のカーディナリティは2以上のため、変換アルゴリズムによってGenericTypeオブジェクト内のphone属性におけるすべての組合せが検索され、それらが配列として表されるほか、Bean上ではsetPhoneメソッドが起動されます。GenericTypeBeanSerializationHandlerのtoGenericTypeメソッドでは各配置要素が取得され、個別のphone属性としてtoGenericTypeに追加されます。
次のように定義されている場合:
final String EMPLOYEE_VIRTUAL_BEAN_NAME = "EmployeeDC.Types.Employee"; Employee emp = getEmployee(); GenericType gt = null;
Employeeオブジェクトは、次のようにGenericTypeに変換されます。
gt = GenericTypeBeanSerializationHelper.toGenericType
(EMPLOYEE_VIRTUAL_BEAN_NAME, emp);
GenericTypeは次のようにEmployeeオブジェクトに変換されます。
emp = GenericTypeBeanSerializationHelper.fromGenericType
(Employee.class, gt, null);
正常に変換するには次の点を考慮します。
POJOでは通常、それらに関連付けられたGenericType構造に厳密に従います。
GenericType構造から外れた場合は、次のいずれかの方法に従います。
追加のBeanプロパティを一時的に宣言します。
操作パラメータとして使用されたときに欠落データをバッキング・サービスが処理できる場合は、POJOからオプション・プロパティを除外できます。
GenericTypeは、SOAPデータ・コントロールにのみ公開されます。仮想タイプには、toGenericTypeメソッドに渡される、関連付けられた仮想Bean名があります。JDeveloperの「データ・コントロール」ウィンドウで仮想タイプ上にカーソルを置くことによって仮想Bean名にアクセスできます。通常の名前フォーマットは、<DCName>.Types.<methodName>.<argName>です。
詳細は、Oracle Fusion Middleware Oracle ADFモバイルJava APIリファレンスを参照してください。
RestServiceAdapterインタフェースを使用して、RESTコールで送信されるデータにアクセスできます(このデータは、JavaScript Object Notationと表される場合があります)。RestServiceAdapterインタフェースによって、Webサービス・データ・コントロールを作成したり、それと直接やりとりする必要なしに、Webサービス操作の実行をトリガーできます。
ADFモバイル・アプリケーションでRestServiceAdapterインタフェースを使用するには、connections.xmlファイルに接続が存在することを確認し(第10.3項「新しいWebサービス接続の作成」を参照)、次の例で示すようにコードをBeanクラスに追加します。
例10-5は、GETリクエストに対するRestServiceAdapterの使用方法を示しています。
例10-5 GETリクエストに対するRestServiceAdapterの使用方法
RestServiceAdapter restServiceAdapter = Model.createRestServiceAdapter();
// Clear any previously set request properties, if any
restServiceAdapter.clearRequestProperties();
// Set the connection name
restServiceAdapter.setConnectionName("RestServerEndpoint");
// Specify the type of request
restServiceAdapter.setRequestType(RestServiceAdapter.REQUEST_TYPE_GET);
// Specify the number of retries
restServiceAdapter.setRetryLimit(0);
// Set the URI which is defined after the endpoint in the connections.xml.
// The request is the endpoint + the URI being set
restServiceAdapter.setRequestURI("/WebService/Departments/100");
String response = "";
// Execute SEND and RECEIVE operation
try {
// For GET request, there is no payload
response = restServiceAdapter.send("");
}
catch (Exception e) {
e.printStackTrace();
}
例10-6は、POSTリクエストに対するRestServiceAdapterの使用方法を示しています。
例10-6 POSTリクエストに対するRestServiceAdapterの使用方法
String id = "111";
String name = "TestName111";
String location = "TestLocation111";
RestServiceAdapter restServiceAdapter = Model.createRestServiceAdapter();
restServiceAdapter.clearRequestProperties();
restServiceAdapter.setConnectionName("RestServerEndpoint");
restServiceAdapter.setRequestType(RestServiceAdapter.REQUEST_TYPE_POST);
restServiceAdapter.setRetryLimit(0);
restServiceAdapter.setRequestURI("/WebService/Departments");
String response = "";
// Execute SEND and RECEIVE operation
try {
String postData = makeDepartmentPost("DEPT", id, name, location);
response = restServiceAdapter.send(postData);
}
catch (Exception e) {
e.printStackTrace();
}
System.out.println("The response is: " + response);
private String makeDepartmentPost(String rootName, String id,
String name, String location) {
String ret = "<" + rootName + ">";
ret += "<DEPTID>" + id + "</DEPTID>";
ret += "<NAME>" + name + "</NAME>";
ret += "<LOCATION>" + location + "</LOCATION>";
ret += "</" + rootName + ">";
return ret;
}
例10-7は、PUTリクエストに対するRestServiceAdapterの使用方法を示しています。
例10-7 PUTリクエストに対するRestServiceAdapterの使用方法
String id = "111";
String name = "TestName111";
String location = "TestLocation111";
RestServiceAdapter restServiceAdapter = Model.createRestServiceAdapter();
restServiceAdapter.clearRequestProperties();
restServiceAdapter.setConnectionName("RestServerEndpoint");
restServiceAdapter.setRequestType(RestServiceAdapter.REQUEST_TYPE_PUT);
restServiceAdapter.setRetryLimit(0);
restServiceAdapter.setRequestURI("/WebService/Departments");
String response = "";
// Execute SEND and RECEIVE operation
try {
String putData = makeDepartmentPut("DEPT", id, name, location);
response = restServiceAdapter.send(putData);
}
catch (Exception e) {
e.printStackTrace();
}
System.out.println("The response is: " + response);
private String makeDepartmentPut(String rootName, String id,
String name, String location) {
String ret = "<" + rootName + ">";
ret += "<DEPTID>" + id + "</DEPTID>";
ret += "<NAME>" + name + "</NAME>";
ret += "<LOCATION>" + location + "</LOCATION>";
ret += "</" + rootName + ">";
return ret;
}
例10-8は、DELETEリクエストに対するRestServiceAdapterの使用方法を示しています。
例10-8 DELETEリクエストに対するRestServiceAdapterの使用方法
RestServiceAdapter restServiceAdapter = Model.createRestServiceAdapter();
restServiceAdapter.clearRequestProperties();
restServiceAdapter.setConnectionName("RestServerEndpoint");
restServiceAdapter.setRequestType(RestServiceAdapter.REQUEST_TYPE_DELETE);
restServiceAdapter.setRetryLimit(0);
restServiceAdapter.setRequestURI("/WebService/Departments/44");
String response = "";
// Execute SEND and RECEIVE operation
try {
// For DELETE request, there is no payload
response = restServiceAdapter.send("");
}
catch (Exception e) {
e.printStackTrace();
}
System.out.println("The response is: " + response);
RestServiceAdapterを使用する場合は、AcceptヘッダーとContent-Typeヘッダーを設定して、MIMEタイプの不一致が原因でリクエストおよびレスポンスのペイロードが無効と判断されないようにします。
|
注意: REST Webサービス・アダプタでは、モバイル・アプリケーション上の文字セットとしてUTF-8のみをサポートします。UTF-8は、アダプタのプログラムに埋め込まれています。 |
Webサービス・コールから受け取ったバイナリ(非テキスト)レスポンスを処理するには、RestServiceAdapterを使用できます。これらのレスポンスには、PDFファイルやビデオ・ファイルなど、どの種類のバイナリ・データでも含めることができます。使用するRestServiceAdapterメソッドはsendReceiveです。
例10-9は、ファイルのリクエストをRESTサーバーに送信し、そのファイルをディスクに保存する方法を示しています(例10-10を参照)。
例10-9 ファイルのリクエストの送信
RestServiceAdapter restServiceAdapter = Model.createRestServiceAdapter();
restServiceAdapter.clearRequestProperties();
restServiceAdapter.setConnectionName("JagRestServerEndpoint");
restServiceAdapter.setRequestType(RestServiceAdapter.REQUEST_TYPE_GET);
restServiceAdapter.setRetryLimit(0);
restServiceAdapter.setRequestURI("/ftaServer/v1/kpis/123/related/1");
// Set credentials needed to access the REST server
String theUsername = "hr_spec_all";
String thePassword = "Welcome1";
String userPassword = theUsername + ":" + thePassword;
String encoding = new sun.misc.BASE64Encoder().encode(userPassword.getBytes());
restServiceAdapter.addRequestProperty("Authorization", "Basic " + encoding);
// Execute the SEND / RECEIVE operation.
// Since it is a GET request, there is no payload.
try {
this.responseRaw = restServiceAdapter.sendReceive("");
}
catch (Exception e) {
e.printStackTrace();
}
System.out.println("The response is: " + this.responseRaw);
// Write the response to a file
writeByteArrayToFile(this.responseRaw);
例10-10は、例10-9のコードによって呼び出されるメソッドを示しています。このメソッドでは、ファイルに対するbyte[]レスポンスをディスクに保存します。
例10-10 ファイルのディスクへの保存
public void writeByteArrayToFile(byte[] fileContent) {
BufferedOutputStream bos = null;
try {
FileOutputStream fos = new FileOutputStream(new File(fileToSavePath));
bos = new BufferedOutputStream(fos);
// Write the byte [] to a file
System.out.println("Writing byte array to file");
bos.write(fileContent);
System.out.println("File written");
}
catch(FileNotFoundException fnfe) {
System.out.println("Specified file not found" + fnfe);
}
catch (IOException ioe) {
System.out.println("Error while writing file" + ioe);
}
finally {
if(bos != null) {
try {
// Flush the BufferedOutputStream
bos.flush();
// Close the BufferedOutputStream
bos.close();
}
catch (Exception e) {
}
}
}
ADFモバイルが提供する構成サービスを使用すると、管理者は、サーバーから異なるADFモバイル・アプリケーションに対するWebサービス接続のエンドポイントを更新できるようになり、結果としてユーザーはADFモバイル・アプリケーションの初回起動時に新しい接続を取得できます。これを行うには、異なるアプリケーションの複数のconnections.xmlファイルをホストおよび更新します。それ以降にアプリケーションを起動すると、ADFモバイル・アプリケーションの開発者はコンテナ・ユーティリティAPIを使用して新しい接続をチェックするように要求されます(第6.2.3項「checkforNewConfiguration」を参照)。
管理者は、基本認証によって保護されるリソースとしてconnections.xmlファイルを指定する必要があります(第17章「ADFモバイル・アプリケーションのセキュリティ」を参照)。
クライアント・アプリケーションでは、更新のチェックに構成サービスを使用できます。
「構成サービス」ダイアログでは次を実行できます。
構成サービスのURLを更新してこのアプリケーションの更新を保存します。
「構成サービス」ダイアログの入力を支援するURLの値を使用して構成サービスのURLをシードできます(例10-11を参照)。そのプリファレンスIDが存在する場合は、それが「構成サービス」ダイアログにシードされます。
connections.xmlファイルは、構成サービスのURLに存在する必要があります。構成サービスが有効の場合は、アプリケーション・バンドルではなく構成サービスからこのファイルを取得し、使用します。詳細は、第10.7.1項「URLの構築について」を参照してください。
キーストアに保存されているユーザー名とパスワードを入力します。
管理者は、アプリケーションのadf-config.xmlファイルにある設定を使用して、アプリケーションの起動時に構成サービスを呼び出すかどうかを定義できます(例10-11を参照)。アプリケーションの初回起動時には、ダイアログが表示され、資格証明がキーストアにキャッシュされます。それ以降の起動(再起動は含まない)では、サーバーの変更をチェックし、「構成サービス」ダイアログの表示をトリガーすることをアプリケーションに指示する必要があります。ADFモバイルが提供するAPIでは、更新のチェックを実行し、その更新に対して「構成サービス」ダイアログを起動するためにクライアントAPIを呼び出すアプリケーション内の場所を指定できます。更新後は、アプリケーションは適切に実行されます(必要な場合は再起動されます)。
例10-11は、use-configuration-service-at-startupプロパティの使用方法を示しています。このプロパティのデフォルト値はfalseです。さらに、この例では、構成サービスの接続情報に関するユーザー・プロンプト内でエンドポイントURLのシードに使用されるadfmf-configuration-service-seed-urlプロパティが示されています。
例10-11 adf-config.xmlファイルでの構成サービスの設定
<adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties">
<adf-property name="use-configuration-service-at-startup" value="true"/>
<adf-property name="adfmf-configuration-service-seed-url"
value="http://myhost.us.example.com:7777/
ConfigServerWebDavFolder/"/>
</adf:adf-properties-child>
構成サービスでは、アプリケーションの起動時に次の手順を実行します。
アプリケーションの起動時に起動します。
Documentsディレクトリをチェックして管理対象ファイルのコピーを検索します。それらが見つかった場合は、構成サービスのプロセスが終了します。
構成サービスによってDocumentsディレクトリ内の構成ファイルが見つからない場合は次の操作が実行されます。
構成サービスが使用されていないことをadf-config.xmlファイルが示している場合、構成サービスは管理対象ファイルをアプリケーション・バンドルからDocumentsディレクトリ管理対象フォルダにコピーして、構成サービスのプロセスを終了します。
構成サービスが使用されていることをadf-config.xmlファイルが示している場合、構成サービスは管理対象ファイルのダウンロードを試みます。
セキュアなストアから、格納されている資格証明をチェックします。資格証明が見つかり、それらによって構成サーバーにアクセスできる場合は、Documentsディレクトリの管理対象フォルダにconnections.xmlファイルがダウンロードおよび配置され、その時点で構成サービスのプロセスが終了します。
資格証明が見つからず、格納されている資格証明では構成サーバーへのアクセスに失敗する場合、ユーザーに接続情報(ユーザー名、パスワードおよびエンドポイントURL)の入力を求めるプロンプトが表示されます。
構成サービスでは、アプリケーションが失敗またはドロップアウトするまでに、プロンプトまたはダウンロードを5回試みます。
構成サーバーへの接続が正常に確立された場合は、connections.xmlファイルがダウンロードされ、それ以降の使用に備えて接続情報が格納されます。
図10-4は、iPhoneにおける構成サービスのプロンプト・ダイアログを示しています。
構成サービスの各管理対象リソースへのURLが構築されています。これには、次のようにアプリケーションIDとファイル名が含まれています。
URLのhttp://my.server.com:port/SomeFolderLocationとアプリケーションIDのcom.mycompany.appnameがユーザーによって指定されている場合は、次のURLを使用して構成ファイルをダウンロードします。
http://my.server.com:port/SomeFolderLocation/com.mycompany.appname/connection.xml