プライマリ・コンテンツに移動
Oracle® Mobile Application Framework Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発
2.3.3
E82940-01
目次へ移動
目次
前
前 		次
次

26 MAFアプリケーションでのデータのキャッシュ

この章では、MAFアプリケーションでデータをキャッシュする方法について説明します。

この章の内容は次のとおりです。

26.1 MAFアプリケーションでのデータ・キャッシュの概要

MAFでは、JSONペイロードでRESTサービスによって取得されたデータのキャッシュをサポートしています。これにより、MAFアプリケーションは、デバイスがオフラインでネットワーク接続が使用できない場合でも、ローカルに保存されたキャッシュ・データにアクセスして動作するようになります。

データ・キャッシュは、モバイル・アプリケーションのユーザーに優れたユーザー操作性を提供するための重要な要素です。ユーザーは、モバイル・アプリケーションがいつでも使用でき、機能することを期待します。残念なことに、モバイル・アプリケーションの接続性は信頼できない場合もあり、ネットワーク接続を使用できなかったり、接続の確立時につながったり切れたりを繰り返し、最終的に切断されることがあります。MAFは、ユーザーのデバイスがオフラインのときでも作業を継続できるMAFアプリケーションの開発が可能な、いくつかの機能を提供しています。ネットワーク接続が使用できない場合、MAFアプリケーションではローカルに格納されているキャッシュ・データにアクセスして、シームレスなユーザー操作を確保します。

図26-1に、MAFでのキャッシュの動作を示します。キャッシュ・レイヤーでは、ビジネス・ロジック・レイヤーから生成されるRESTコールがインターセプトされます。キャッシュ・レイヤーでは、sync-config.xmlファイルが読み取られ、ファイルのエントリに基づいて、RESTサービスからのレスポンスがキャッシュ・データ・ストアに格納されます。sync-config.xmlファイルで、キャッシュするURI(エンド・ポイント)リソースを指定し、そのURIのキャッシュ・ポリシーを指定します。キャッシュ・レイヤーでは、指定したURIがキャッシュ内で特定のリソースを識別するためのキーとして使用されます。

図26-1 MAFアプリケーションでのデータのキャッシュ

このイメージについては周囲のテキストで説明しています。

MAFでは、キャッシュ内のデータのリフレッシュおよび期限切れの頻度を決定するために、適用および構成できるポリシーのセットが提供されます。これらのポリシーにより、リクエストを処理する方法をキャッシュ・レイヤーに伝え、その結果として、アプリケーションにとって、サーバーからデータを取得するよりもデバイスに格納されているフェッチ・データをオフラインで読み込んで使用する方が高速なため、アプリケーションのパフォーマンスを向上できます。これらのポリシーでは、インターネットに接続できなくなった場合にオフライン読取りを有効にすることで、アプリケーション・キャッシュで最適なユーザー操作性を維持することもできます。

次の項で説明されている機能から、自分のMAFアプリケーションで必要とするものを実装します。

注意:

MAFアプリケーションでは、JSONペイロードでRESTサービスによって取得されたデータのキャッシュのみがサポートされます。

26.2 MAFアプリケーションでのデータ・キャッシュの有効化

データ・キャッシュを有効にするには、maf.propertiesファイルで次の行のコメントを外します。

#java.commandline.argument=-DsyncEnabled=true

注意:

データ・キャッシュを有効にすると、ネットワーク上を通過するすべてのデータがキャッシュされます。キャッシングを有効にしてアプリケーションをデプロイした後、実行時にオフにする方法はありません。

キャッシュするリソースおよびキャッシュ・ポリシーの構成の詳細は、「sync-config.xmlファイル内のキャッシュ・リソースおよびキャッシュ・ポリシーの指定」を参照してください。

26.3 sync-config.xmlファイル内のキャッシュ・リソースおよびキャッシュ・ポリシーの指定

MAFアプリケーションが作成されると、そのアプリケーションの/.adf/META-INFディレクトリにsync-config.xmlファイルも作成されます。このファイルには、キャッシュが有効化されているときに、すべてのエンド・ポイントに適用されるデフォルト・ポリシーが含まれています。ただし、このファイルで別のキャッシュ・ポリシーを指定することもできます。

JDeveloperでは、MAFアプリケーションを作成すると、デフォルトでMAFアプリケーションの/.adf/META-INFディレクトリにsync-config.xmlファイルが作成されます。このファイルを使用して、MAFアプリケーションが指定のエンド・ポイント(URI)に対してコールを行うときに適用されるキャッシュ・ポリシーを指定します。デフォルトで、sync-config.xmlファイルには、キャッシュを有効にすると適用されるデフォルトのポリシーが含まれています。このデフォルトのキャッシュ・ポリシーは、sync-config.xmlファイルで指定するエンド・ポイント以外のすべてのエンド・ポイントに適用されます。

例26-1に、同じサーバーから発生した2つの異なるエンド・ポイント(URI)に対して2つの異なるポリシー(policy1とpolicy2)を定義する方法を示します。この例には、MAFアプリケーションがpolicy1およびpolicy2に指定されている以外のすべてのURIにRESTコールを行うときに適用されるデフォルトのポリシーも示されています。最後に、この例では暗号化を有効にする方法を示しています。

WorkBetterサンプル・アプリケーションのsync-config.xmlファイルでは、キャッシュ・ポリシーの別の使用例を確認できます。「サンプルのMAFアプリケーション」を参照してください。

例26-1で、sync-config.xmlのBaseURI要素のTaskConnは、MAFアプリケーションのconnections.xmlファイルで次のように定義されている接続の参照です。

<Reference name="TaskConn" className="oracle.adf.model.connection.url.HttpURLConnection" xmlns="">
    <Factory className="oracle.adf.model.connection.url.URLConnectionFactory"/>
    <RefAddresses>
      <XmlRefAddr addrType="TaskConn">
	<Contents>
	  <urlconnection name="TaskConn" url="http://localhost:7101/TaskService/rest/v1"/>
	</Contents>
      </XmlRefAddr>
    </RefAddresses>
  </Reference>

この構成の利点は、接続の詳細の変更(たとえば、ホスト名の変更)がconnections.xmlファイルの変更のみで済むことです。sync-config.xmlファイルを変更する必要はありません。

例26-1 2つのポリシーを定義するsync-config.xmlファイルのサンプル

<Settings xmlns="http://xmlns.oracle.com/sync/config">
   <!-- The connection.xml file defines the URL that the value of the BaseURI element references. -->
   <BaseUri>TaskConn</BaseUri>

   ...
   <EnableEncryption>true</EnableEncryption>
   <Policies>
	<ServerGroup id="tasklist" baseUri="TaskConn">
	   <Policy id="policy1">
		<Path>/taskservice1/rest/v1/TaskList/*</Path>
		
	 <!-- This caching policy applies to a REST service accessed by a call to an end point constructed from 
	      a concatenation of the baseURI value for TaskConn and the <Path> element's value. That is,
	      http://localhost:7101/TaskService/rest/v1/taskservice1/rest/v1/TaskList/* 

	      When the end point above is used by the business logic layer in the MAF application, the cache layer checks sync-config.xml
        to see if there is a cache policy defined for the end point. If it finds the policy, it applies the policy. -->

		<FetchPolicy>FETCH_FROM_SERVICE_ON_CACHE_MISS_OR_EXPIRY</FetchPolicy>
		<UpdatePolicy>QUEUE_IF_OFFLINE</UpdatePolicy>
		<ExpirationPolicy>EXPIRE_AFTER</ExpirationPolicy>
		<ExpireAfter>30</ExpireAfter>
		<EvictionPolicy>EVICT_ON_EXPIRY_AT_STARTUP</EvictionPolicy>
   </Policy>
	</ServerGroup>

	<ServerGroup id="taskdetail" baseUri="TaskConn">
 	   <Policy id="policy2">
		<Path>/taskservice1/rest/v1/TaskDetail/*</Path>
		
	 <!-- This caching policy applies to a different REST service accessed by a call to an end point constructed from 
	      a concatenation of the baseURI value for TaskConn and the <Path> element's value. That is,
	      http://localhost:7101/TaskService/rest/v1/taskservice1/rest/v1/TaskDetail/*

	      When the end point above is used by the business logic layer in the MAF app, the cache layer checks sync-config.xml 
	      to see if there is a cache policy defined for the end point. If it finds the policy, it applies the policy. -->
		
		   <FetchPolicy>FETCH_FROM_SERVICE_IF_ONLINE</FetchPolicy> 
		   <UpdatePolicy>UPDATE_IF_ONLINE</UpdatePolicy>
		   <ExpirationPolicy>EXPIRE_AFTER</ExpirationPolicy>
		   <ExpireAfter>30</ExpireAfter>
  		   <EvictionPolicy>EVICT_ON_EXPIRY_AT_STARTUP</EvictionPolicy>
	   </Policy>
	</ServerGroup>

  <DefaultPolicy>
		<FetchPolicy>FETCH_FROM_SERVICE_IF_ONLINE</FetchPolicy>
		<UpdatePolicy>UPDATE_IF_ONLINE</UpdatePolicy>
		<ExpirationPolicy>NEVER_EXPIRE</ExpirationPolicy>
		<EvictionPolicy>MANUAL_EVICTION</EvictionPolicy>
	   </DefaultPolicy>
   </Policies>
</Settings>

26.4 MAFで提供されているキャッシュ・ポリシー

sync-config.xmlファイルに、モバイル・アプリケーションのキャッシュ・ポリシーを定義します。ポリシーを組み合せて、モバイル・アプリケーションに適切なコンテンツを提供します。

データ・ストレージ・ポリシー設定の構成の詳細は、「sync-config.xmlファイル内のキャッシュ・リソースおよびキャッシュ・ポリシーの指定」を参照してください。

アプリケーションのキャッシング動作の構成を可能にするポリシーは、次のグループに分類されます。

  • フェッチ・ポリシー - リソースをフェッチするキャッシュ・レイヤーを指示します(サーバーから、ローカル・キャッシュから、その2つの組合せなど)。これらのポリシーのリストは、表26-1を参照してください。

  • 有効期限ポリシー - キャッシュ・レイヤーが、ローカル・キャッシュに格納されているリソースが古くなり失効し、更新ポリシー(表26-4で説明)に従って更新する必要があるか、または削除ポリシー(表26-3を参照)に従ってローカル・キャッシュから削除する必要があるかを確認するまでの期間(秒単位)を設定します。有効期限ポリシーの詳細は、表26-2を参照してください。

  • 削除ポリシー - キャッシュ・レイヤーが、いつ、ローカル・キャッシュに格納されているリソースを削除するかを指定します。削除ポリシーは、サーバー側のリソースではなく、ローカル・キャッシュのデータのみに適用されます。ポリシーのリストは、表26-3を参照してください。

  • 更新ポリシー — ローカル・キャッシュに格納されている期限切れのポリシーの更新のタイミングを定義します。ポリシーのリストは、表26-4を参照してください。

表26-1 フェッチ・ポリシー

ポリシー 説明

キャッシュからフェッチ

サーバーからではなく、キャッシュからのみデータをフェッチするようにキャッシュ・レイヤーに指示します。キャッシュ・レイヤーでキャッシュにデータが見つからない場合、エラーまたはnullオブジェクトが返されます。このポリシーが適用されると、キャッシュ・レイヤーによりキャッシュから直接データが取得されるため、クライアント・アプリケーションがオンラインまたはオフラインのときにこのポリシーを実行できます。

サービスからフェッチ

キャッシュからではなく、直接サーバーからのみデータをフェッチするようにキャッシュ・レイヤーに指示します。キャッシュ・レイヤーは、クライアント・アプリケーションがオンラインのときのみ、このポリシーを適用できます。それ以外の場合は、エラーまたはNULLオブジェクトがクライアント・アプリケーションに返されます。
サービスからフェッチ(オンラインの場合) クライアント・アプリケーションがオンラインのときはサーバーからデータをフェッチし、アプリケーションがオフラインのときはキャッシュからデータをフェッチするようにキャッシュ・レイヤーに指示します。
サービスからフェッチ(キャッシュミス) キャッシュからデータをフェッチするようにキャッシュ・レイヤーに指示します。リクエストされたデータが見つからない場合、キャッシュ・レイヤーはサーバーからデータをフェッチします。
サービスからフェッチ(キャッシュミスまたは有効期限) データがキャッシュに存在し、失効(期限切れ)していない場合は、キャッシュのデータをフェッチするようにキャッシュ・レイヤーに指示します。それ以外の場合は、キャッシュ・レイヤーはリクエストされたデータをサーバーからフェッチします。
キャッシュからフェッチ(更新をスケジュール) キャッシュからデータをフェッチして、サーバーの最新のコピーからキャッシュを更新するバックグラウンド・リフレッシュをスケジュールするようにキャッシュ・レイヤーに指示します。キャッシュ・ミス(キャッシュにリクエストされたデータがないことを意味します)がある場合、キャッシュ・レイヤーはクライアント・アプリケーションにnullオブジェクトを返します。
フェッチとリフレッシュ キャッシュ・レイヤーに次のことを指示します。

  • リクエストしたデータが存在し、期限切れでない場合、キャッシュからデータをフェッチします。

  • バックグラウンドのリフレッシュをスケジュールして、サーバーの最新コピーからキャッシュを更新します。

キャッシュ・ミス(キャッシュにリクエストされたデータがないことを意味します)がある場合、またはデータの期限が切れている場合は、キャッシュ・レイヤーは、「サービスからフェッチ」のポリシーに従って直接サーバーからデータをフェッチします。

表26-2 有効期限ポリシー

ポリシー 説明
再起動時に期限切れ クライアント・アプリケーションが再起動するときにURIのデータを期限切れとして確認するか、または次にクライアント・アプリケーションからコールされたときにサーバーのコピーでローカル・データを更新するように、キャッシュ・レイヤーに指示します。
期限切れまでの時間 「期限切れまでの時間」ポリシーで設定されている指定時間(秒)の後にデータを期限切れとするようにキャッシュ・レイヤーに指示します。このポリシーは、定期的に更新されるデータに使用されます。
期限切れまでの時間 キャッシュ・レイヤーがキャッシュ内のデータの有効期限切れを確認するまでの秒数。
期限切れなし ローカル・データを期限切れにできないことをキャッシュ・レイヤーに指示します。

表26-3 削除ポリシー

ポリシー 説明
起動時に期限切れを削除 クライアント・アプリケーションが再起動するときに期限切れのデータをキャッシュから削除するか、または次にクライアント・アプリケーションからコールされたときにサーバーのコピーでローカル・データを更新するように、キャッシュ・レイヤーに指示します。
手動削除 キャッシュ・レイヤーは、ローカル・キャッシュからデータを自動的に削除できません。データを手動で削除するには、APIを使用します。

表26-4 更新ポリシー

ポリシー 説明
オンラインの場合に更新 クライアント・アプリケーションがオンラインのときにのみ、サーバー側のデータでローカル・キャッシュを更新するようにキャッシュ・レイヤーに指示します。それ以外の場合、キャッシュ・レイヤーはエラーを返します。

26.5 sync-config.xmlファイルでの構成サービス・エンド・ポイントの使用方法

syncconfig.xmlのServerGroup要素のベースURIに対する要素と属性は、connections.xmlで定義されているエンド・ポイントを参照します。実行時にエンド・ポイントが変更されたとしても、キャッシュ・ポリシーは新しいURLに対して不変のまま維持されます。

sync-config.xmlのBaseUri要素およびServerGroup要素のbaseUri属性は、connections.xmlで定義されたエンド・ポイントを参照できます。この機能を利用するには、次のように、URL以外の有効な接続参照を指すように値を置換します。

baseUri="<connection_reference_name_in_connections_xml>"

エンド・ポイントが接続オーバーライドを使用して実行時に変更された場合、キャッシュ・ポリシーは新規URLに対しても同じになります。第16章「MAFアプリケーションで使用されるエンド・ポイントの構成」を参照してください。WorkBetterサンプル・アプリケーションは、この構成の実装を示しています。このサンプル・アプリケーションおよびその他のサンプル・アプリケーションにアクセスする方法の詳細は、「サンプルのMAFアプリケーション」を参照してください。

26.6 MAFアプリケーションでのキャッシュ・データの暗号化

MAFでは、MAFアプリケーションでキャッシュされるデータを暗号化する機能が提供されます。

有効にすると、MAFアプリケーションによってキャッシュされるすべてのデータが暗号化されます。このオプションはデフォルトでは無効にされています。暗号化を有効にするには、次の例に示すようにsync-config.xmlファイルを構成します。
<?xml version="1.0" encoding="UTF-8"?>
<Settings xmlns="http://xmlns.oracle.com/sync/config">
  <BaseUri>TaskConn</BaseUri>
  ...
  <EnableEncryption>true</EnableEncryption>
  <Policies>
  ...
</Settings>

26.7 FARでのsync-config.xmlファイルのパッケージ化

ビュー・コントローラ・プロジェクトをFARとしてデプロイすると、そのプロジェクトにはモバイル・アプリケーションで使用されるWebサービス・エンドポイントを記述するsync-config.xmlファイルが含まれるようになります。FARがアプリケーションに追加されていると、MAFは、sync-config.xmlファイルとconnections.xmlファイルに関連するメッセージをログに記録します。

ビュー・コントローラ・プロジェクトがFARとしてデプロイされると、sync-config.xmlファイルは機能アーカイブ・ファイルに含まれます。connections.xmlファイルと同様に、アプリケーションにFARを追加すると、MAFはFAR (jar-sync-config.xml)内のsync-config.xmlファイルの内容と、使用するアプリケーションのsync-config.xmlファイルの内容をマージします。「FARのビュー・コントローラ・プロジェクトとしての追加時に行われる処理」で説明されているように、sync-config.xmlファイルには、モバイル・アプリケーションによって使用されるWebサービスのエンド・ポイントが記述されているため、FARを追加することで、モバイル・アプリケーションを構成するアプリケーション機能によって使用されるすべてのWebサービスのエンド・ポイントを更新できます。

アプリケーションにFARを追加すると、MAFは、アプリケーションのsync-config.xmlファイルとconnections.xmlファイルを確認し、変更を求めるメッセージをログに記録します(変更が必要な場合)。図26-2に示すように、これらのメッセージは、使用するアプリケーションのsync-config.xmlファイルの状態を反映します。

図26-2 メッセージ・ログ

このイメージについては周囲のテキストで説明しています。

使用するアプリケーションにsync-config.xmlファイルがない場合、MAFではこのファイルをアプリケーションに追加し、次のようなメッセージを書き込みます。

oracle.adfmf.framework.dt.deploy.features.deployers.SyncConfigMerger _logNoSyncConfigInAppUsingFar
WARNING: The application does not contain a synchronization file, "sync-config.xml". Creating one 
containing the synchronization configuration in the Feaure Archive.

sync-config.xmlファイルの<ServerGroup>要素に、使用するアプリケーションのconnections.xmlファイルで定義された対応する<Reference>要素がない場合、MAFは、次に示すような接続の確認(または作成)を要求するログ・メッセージを書き込みます。

oracle.adfmf.framework.dt.deploy.features.deployers.SyncConfigMerger _logAddedServerGroups
WARNING: The following server groups were added sync-config.xml by the Add to Application 
operation:
{
  ServerGroup1 - there is no existing application connection defined for this server group.
Please create the connection.

  ServerGroup2 - verify its configuration.
}

使用するアプリケーションのsync-config.xmlファイルの<ServerGroup>定義が、FAR内の対応するsync-config.xmlファイルの定義を複製する場合、MAFは、次のSEVEREレベルのメッセージをログに書き込みます。

oracle.adfmf.framework.dt.deploy.features.deployers.SyncConfigMerger _logDuplicateServerGroups
SEVERE: Cannot merge the server groups from the Feature Archive because the following definitions 
already exist:
ServerGroup1
ServerGroup2
前
前 		次
次
目次へ移動
目次