目次
- 概要
- データモデル
- マッピング
- その他の機能
1. 概要
Object Serviceは、Kony Fabricの機能であり、マイクロサービスアーキテクチャーに従ったモデル駆動型アプリケーションの設計と開発を可能にします。
またObject Serviceを使用することで、アプリケーションがデータをやり取りする方法を決定するデータモデルを定義することも可能です。
Object Serviceの機能を利用すると、より適切にAPIの呼び出しとデータの制御を行うことができます。単純化されたアプリケーションの開発であればIntegration Serviceを使用するだけで十分に作業が完了しますし、より複雑なものであれば、Object Serviceの利点の1つである「再利用性」を活かすことで作業を簡単にすることが可能です。
●Object Serviceの主な長所
・従来のIntegration Serviceとは違い、データモデルの設計とバックエンドデータのマッピングに焦点
・フロントエンドとバックエンドの独立した開発が可能
・サービスの作成と呼び出しの容易さ
・異なるアプリケーション間で同じデータモデルの再利用が可能
・メンテナンスが容易で、コードは自動的に生成
2. データモデル
データモデル
Kony Fabricでは、モバイルアプリケーションのユースケースに基づいて、データモデルを設計および最適化できます。
これは、バックエンドシステムとは無関係に実行できます。
エンドポイントタイプを選択した後、オブジェクトとしてすでにデータモデルが公開されているバックエンドLOB(Line Of Business)システムからデータモデルを生成できます。
または、データモデルを作成し、オブジェクトをバックエンドシステムに手動でマッピングすることもできます。
既存のサービスからサービス駆動型オブジェクトを作成することもできます。
データモデルの生成
バックエンドLOBオブジェクトからデータモデルを生成
Kony Fabric ConsoleのConfigure ServiceのメニューからObjectsタブをクリック->[Configure New]をクリック
下図の画面が出てきたら、Nameにオブジェクトの名前を入力します。
Endpoint Typeのリストボックスから使用したいエンドポイントタイプを選択します。
今回は「Relational Database」を選択します。
※エンドポイントタイプの選択についての詳細は下記のURL参照ください。
https://docs.kony.com/konylibrary/konyfabric/kony_fabric_user_guide/Content/ObjectsServices/Objectservices_Stage1.htm#Createobjects
SQLサーバーにアクセスするための情報を記載し[Save]をクリックします。
Object Serviceのエンドポイントタイプの選択が終わりましたので、続いてObject Serviceのデータモデルの設定を行います。
Object Serviceのデータモデル設定画面(下図)にて[GENERATE]をクリックします。
Import Objects from Backendという画面(下図)が開くので、テーブルの詳細を展開したいスキーマを選択し、更に個々のテーブルをチェックボックスにて選択します。
選択後、[NEXT]をクリックします。
Import Objects from Backend画面では、下図のようにインポートしたバックエンドオブジェクトとデータモデルのオブジェクト名が表示され、名前の編集を行うことも可能です。
[GENERATE]をクリックすると、下図のようにデータモデルが表示されます。
Kony Fabric Consoleの画面左側のナビゲーションペインのData Modelタブで各オブジェクトの左側にあるプラスボタンをクリックするとFieldsとRelationshipsが表示されます。
Fieldsをクリックすると下図のように、各オブジェクトのフィールドの一覧がConfigure画面に表示されます。
この画面では名前・属性・主キー属性を変更することができます(自動生成された属性は変更できません)。
またFieldsと同様にRelationshipsをクリックすると、各オブジェクトの関係性が一覧として表示されます。
ここでは関係性を編集したり削除したりすることができます。
一通りの編集が完了したら[SAVE]ボタンをクリックして保存します。
これでKony Fabricアプリケーションをパブリッシュすることができます。
バックエンドのマッピング
バックエンドデータとフロントエンドから呼び出すデータが同じ形式、表現になることは滅多にありません。
そういった状況では、バックエンドデータを簡単に取得、フィルタリングおよびより良い表現に変換できる強固なマッピングが必要になってきます。
●バックエンドフィールドへの共通マッピング
データモデルフィールドとバックエンドオブジェクトフィールドの間で定義される共通マッピングは変換リクエスト、変換レスポンスまたはその両方に適用されます。
Kony Fabricはバックエンドシステムでメソッドを呼び出す時にこれらのマッピングを適用します。
マッピングには3種のアイコンが存在します。
・↔︎: リクエストとレスポンスの両方のマッピングを示します。
・←: レスポンスのマッピングを示します。
・→: リクエストのマッピングを示します。
●メソッドのマッピングを構成する
Kony Fabric Consoleの画面左側のナビゲーションペインのMappingタブをクリックし、続いて右側のMethodsタブをクリックします。そこで[Add]ボタンをクリックします。
Data Model Verbフィールドのドロップダウンメニューからマッピングを行いたい処理を選択します(POST・GET・PUT・DELETE・PATCH・customから選択が可能)。
Verbセキュリティレベルの編集を行うことができます。
これはクライアントがどのようにVerb認証を行うかについて指定することができます。Identity Serviceを使用することでVerbへのアクセスを正常に認証された認証済みユーザーのみに制限することもできます。「Public」に設定することで全てのクライアントが認証無しでアクセスできるようにすることも可能です。
ServiceをクリックするとIntegration Serviceに取り込んだサービスの一覧が表示されるので、接続したいサービスを選択します。
Operationsをクリックすると、選択したサービスのオペレーション一覧が表示されるのでマッピングしたいオペレーションを選択します。
[Add Mapping]ボタンをクリックすると、下図のようにマッピングの設定画面が表示されます。
「Request Mapping」では、左側にはObject Serviceで作成したデータモデル一覧が、右側には選択したサービスのデータ一覧が表示されます。「Response」では、左側には選択したサービスのデータ一覧が、右側にはObject Serviceで作成したデータモデル一覧が表示されます。
ビジュアルデザイナー
Object Serviceにはビジュアルデザイナー(下図)が備わっており、ドラッグ&ドロップを使用してObject Serviceのリクエストおよびレスポンスを追加・変更・削除することができます。
バックエンドオブジェクト・データモデル・サービスに関連付けられた他のオブジェクトや関数は、それぞれ独自のコンテナに表示されます。
各コンテナには1つ以上のアイテムがリストされており、アイテムから別のアイテムにドラッグを行うことで新たなマッピングを作成することができます。
●任意のObject Serviceのビジュアルデザインビューにアクセスする方法
Object Serviceリストで、閲覧・編集したいサービスの右側にある「...」ボタンをクリックし、[Edit Configure]ボタンをクリックします。
ナビゲーションウィンドウで「Mapping」タブをクリックし、閲覧したいアイテムを選択します。
「Request Mapping」または「Response Mapping」タブを選択し閲覧・編集したいマッピングを選択します。
どちらかを選択後、「design view」タブ(下図赤枠)をクリックします。
このサービスのマッピングを編集したい場合は、ページ右下の[Edit]ボタンをクリックします。
●マッピングの追加
ドラッグ操作によりオブジェクトを相互にマッピングすることが可能です。アイテムのタイプにより、アイテムに複数のソースから複数のマッピングを含めることもできます。
●マッピングの削除
[Clear Mapping]ボタンをクリックすると、既存のマッピングを全て削除することもできます。
個々のマッピングの削除は、キーボードの「DELETE」キーで削除することができます。
●ビジュアルデザイナーで関数を使用したい場合
ビジュアルデザイナーが「Edit」モードの場合、「Toolbox」ペインには組み込み関数の一覧が表示されます。
これらの組み込み関数を追加するには、関数リストから使用したい関数を選択し、ビジュアルデザイナー上までドラックすることで配置できます。
●マッピングのテスト
マッピング設定画面上部の「Test」タブをクリックすることで、テストパネルが表示されマッピングのテストを行うことができます。
マッピングのテストを行うに際し、環境の選択を行います(下図赤枠)。
Request Payloadにリクエストパラメータを追加します(下図赤枠)。
またヘッダー情報が必要なサービスの場合はヘッダーの値を入力します。
リクエストパラメータおよびヘッダーの入力が完了したら、[Send]をクリックしテストを行います。
●高度なマッピング
高度なシナリオにはXML Mapperを使用することも可能です。
コアマッパーエンジンはObject Serviceパイプラインに統合されており、マッパーは渡された宣言型XMLを使用してJSONを論理的に取り込み、変更し、ノードを作成して既存のノードを更新するエンジンです。
マッパーに着信するリクエストの場合、基本的なURL解析とODATA解析が実行された後、リクエストマッパーは全てのコンテキストを利用できるようになります。リクエストマッパーはペイロードを変更し、パイプラインの次のステージに送信を行います。これは通常、統合コネクターを使用してバックエンドに送られます。
レスポンスの取得後、コンテキスト全体がレスポンスマッパーで使用可能になります。レスポンスマッパーはデータ変更に加えフォーマットを行なってからデータを出力します。内部マッパーロジックは、入力パイプラインと出力パイプラインの両方で同じだが、マッパーが使用できるコンテキストが変更されています。
下図はObject Serviceパイプラインを示しています。
4. その他の機能
プリプロセッサーとポストプロセッサー
アプリ開発者はFabricサーバー内のオブジェクトのフィールド毎にメタデータを定義することができます。
このオブジェクトのメタデータによりアプリ開発者はプリプロセッサーとポストプロセッサーを利用して、クライアント側のロジックを制御することができます。
プリプロセッサーは、クライアント側からのレクエストをバックエンドサーバーに送信する前にデータを暗号化・復号化・変換を行います。
逆にポストプロセッサーは、バックエンドサーバーからのレスポンスをクライアント側に送信する前にデータの暗号化・復号化・変換を行います。
プリプロセッサー/ポストプロセッサーは、クライアントアプリでスタンドアロンで使用したり、サーバーアプリのObject Serviceに組み込んで使用したり、様々なビジネス要件を達成することができます。
●クライアントオブジェクトにおけるプリプロセッサー/ポストプロセッサーのAPIシグネチャ
Visualizer側
・プロセッサーの登録
<model>.registerProcessors(option, successCallback, failureCallback)
モデルは、モデルオブジェクトのプロセッサーの登録を可能にするregisterProcessorsAPIを公開します。このステップは、モデル毎に少なくとも1回は実行する必要がある。
パラメーター
| パラメーター | タイプ | 必須 | |
|---|---|---|---|
| successCallback | function | このファンクションは成功時に呼び出されます。 | ○ |
| failureCallback | function | このファンクションは失敗時に呼び出されます。 | ○ |
| option | JSON | オプションからRegister Processor Optionを見ることができます。 | ○ |
プロセッサオプションの登録
| パラメーター | タイプ | 必須 | |
|---|---|---|---|
| preProcessor | function | モデルインスタンスにフィールドを保存する前に呼び出されるコールバックファンクション。 | × |
| postProcessor | function | モデルインスタンスに値を返却する前に呼び出されるコールバックファンクション。 | × |
| getFromServer | boolean | 「getFromServer」をtrueで設定した際、Fabricサーバーからのオブジェクトのメタデータはリフレッシュされます。通常falseで設定されており、オブジェクトプロパティのメタデータはクライアントのデバイスキャッシュからフェッチされます。 | × |
戻り値は「void」です。
・プリプロセッサー/ポストプロセッサーの定義
ここではプリプロセッサー/ポストプロセッサーのコールバックの定義について説明していきます。
プロセッサーは有効な関数を参照する必要があり、またvalueとcontextの2つの引数を受け取る必要があります。
valueは変換されるモデルオブジェクトプロパティの値で、object型です。
contextはモデルオブジェクトプロパティ固有のコンテキストで有効なJSONです。
※登録済みのプリプロセッサー/ポストプロセッサーのコールバック関数はそれぞれ変換された値を返す必要があります。これは未定義の動作になることを防ぐ為です。
| プロパティ | |
|---|---|
| データ型 | string型。Kony Fabricのオブジェクトサービスとして定義されたオブジェクトプロパティのデータ型を示す。 |
| オブジェクト | string型。モデルオブジェクトの名前を含みます。 |
| オブジェクトサービス | string型。上のオブジェクトを含むオブジェクトサービスの名前を含みます。 |
| フィールド | string型。オブジェクトプロパティまたはオブジェクトフィールドの名前を含みます。 |
| メタデータ | JSON型。フィールドとKony Fabricのオブジェクトサービスのアプリモデルとして定義されたメタデータを関連付けます。 |
※登録済みのプリプロセッサー/ポストプロセッサーコールバックは、Kony FabricアプリのObject Serviceでメタデータが定義されていないフィールドの更新または読み取り中には呼び出されません。
※単一のコールバック関数は、プリプロセッサー/ポストプロセッサーの両方のコールバックとして使用可能です。
Kony Fabric側
Kony Fabricのメタデータで有効化されたフィールドを持つオブジェクトサービスが必要となるので、Object Serviceのフィールドにメタデータを構成し、クライアントアプリのメタデータに基づいてプリプロセッサー/ポストプロセッサーを有効にしていきます。
まずKony Visualizerを起動し、リファレンスアーキテクチャーでプロジェクトを作成します。
Kony Fabricに接続し、フィールドを追加していきます。
先述の方法でObject Serviceを作成し、オブジェクトの作成も行います。
画面左側のデータモデルタブのFieldsに移動し[ADD]ボタンでフィールドを作成し[SAVE]ボタンで保存します。
「DETAIL」列の[View Detail]ボタン(アイコン)でフィールドの詳細ページに移動します。
「Metadata」欄で[ADD]ボタンをクリックします。
下図のようなダイアログが表示されたら、選択したフィールドの名前と値のメタデータを指定します。
[ADD]ボタンをクリックし、Fabricアプリに公開します。
ここまでの手順が完了したら、Kony Visualizerのプロジェクトの方に戻ります。
Visualizer画面左のプロジェクトメニューの「Kony Fabric」の右クリックメニューで「Generate Object Model」をクリックし、オブジェクトモデルを生成します。これによりモデル登録用のプリプロセッサー/ポストプロセッサーが有効になります。
続いてプロジェクトメニューの「Module」の右クリックメニューで「New JS module」をクリックし、新たにJSモジュールを作成します。コードはカスタムJSコードを指定(※1)し、クライアントアプリのプリプロセッサー/ポストプロセッサーにオブジェクトフィールドを登録(※2)します。
function preProcessor(value, context) {
value = encrypt(value); //transformation logic to be applied before sending over the network.
return value;
}
function postProcessor(value, context) {
value = decrypt(value); //transformation logic to be applied before returning value to user.
return value;
}
var objModelDef= kony.mvc.MDAApplication.getSharedInstance().modelStore.getModelDefinition("ObjectName");
function registrationSuccess() {
alert("Registration Success");
}
function registrationFailure(err) {
alert("Registration Failure" + JSON.stringify(err));
}
var options = {'preProcessor' : preProcessor, "postProcessor" : postProcessor };
objModelDef.registerProcessors(options, registrationSuccess, registrationFailure);
プロジェクトを登録し、ビルドを行います。
●バックエンドのメソッドのマッピングでのプリプロセッサー/ポストプロセッサーの設定
先述のバックエンドのメソッドのマッピングにおいて、「GET」の「Advanced」を選択すると「Custom Code Invocation」(下図の赤枠)が表示されます。
プリプロセッサー/ポストプロセッサーのパラメーターを構成して、ビジネス要件に応じてリクエストおよびレスポンスオブジェクトのフィルタが可能です。対応するテキストボックスでJavaのクラス名を指定できます。
※プリプロセッサー/ポストプロセッサーを呼び出すにはオブジェクトサービス作成中に有効なjarファイルをインポートする必要があります。対応するjarは「Object Service Define」の「Advanced Tab」でKony Fabric Consoleにアップロードする必要があります。
Javaプリプロセッサー/ポストプロセッサー
ObjectServicePreProcessorとObjectServicePostProcessorインターフェースを実装するJavaクラスです。
「Custom Code Invocation」で「Java」を選択し、「Class」のテキストボックスに「Pre Processor」または「Post Processor」のクラスを入力します。
このステップにより、開発者は以下のことを得られます。
・PreProcessor: モバイルにレスポンスを送信する前にデータにビジネスロジックを含めることができます。
・PostProcessor: リクエストを外部データソースに転送する前にビジネスロジックをデータに含めることができます。
ObjectServicePreProcessor
「Pre Processor」は、サービスの検証と認証の直後に実行されます。
下記のインターフェイスを実装し、executeメソッドのオーバーライドでカスタムプリプロセッサロジックを記述します。 FabricRequestManager、FabricResponseManager、およびFabricRequestChainがメソッド引数として提供されます。
public interface ObjectServicePreProcessor {
void execute(
FabricRequestManager fabricRequestManager,
FabricResponseManager fabricResponseManager,
FabricRequestChain fabricRequestChain
)
throws Exception;
}
メソッド引数
・FabricRequestManager: リクエスト関連情報を操作するための様々なタイプのハンドラーを指定します。
・FabricResponseManager: レスポンス関連情報を操作するための様々なタイプのハンドラーを指定します。
・FabricRequesChain: リクエストフローの制御に使用されるサーブレットFilterChainに似たチェーンを指定します。
ObjectServicePostProcessor
Fabricランタイムがバックエンドレスポンスを処理した後、「Post Processor」が実行されます。
下記のインターフェイスを実装し、executeメソッドのオーバーライドでカスタムポストプロセッサロジックを記述します。 FabricRequestManagerとFabricResponseManagerがメソッドの引数として提供されます。
public interface ObjectServicePostProcessor {
void execute(
FabricRequestManager fabricRequestManager,
FabricResponseManager fabricResponseManager
)
throws Exception;
}
メソッド引数
・FabricRequestManager: リクエスト関連情報を操作する様々なタイプのハンドラーを指定します。
・FabricResponseManager: レスポンス関連情報を操作する様々なタイプのハンドラーを指定します。
※オブジェクトサービスでのカスタムコード呼び出しの制限
・Bulk Sync V2 APIが使用されている場合、カスタムコードは呼び出されません。
・オブジェクトサービスを利用するオーケストレーションサービスが使用中の場合、カスタムコードは呼び出されません。
・Kony FabricコンソールテストAPIを使用する場合、カスタムコードは呼び出されません。
オフライン同期(オフラインオブジェクト)
概要
この機能はKony Fabric V8バージョンから新しく導入されました。
オフラインオブジェクトは、Object Serviceの上に構築された新しいデータ同期機能です。この機能を使用すると、アプリはKony FabricのObject Serviceからモバイルデバイスにデータをダウンロードできます。デバイスにネットワーク接続がない場合でも、アプリはダウンロードしたデータを引き続き使用でき、デバイスがネットワークを取得すると、データをKony Fabricオブジェクトサービスと同期できます。オープンソースプロトコルであるOdataプロトコルを使用し、中間に別の同期サーバーを必要とせずオブジェクトサービスに直接接続を行います。
基本的な機能
双方向の同期 (クライアントからサーバー、サーバーからクライアント)
増分ダウンロード/アップロード
・サーバーと同期したデバイスが前回クライアントに送信されてからサーバー上で変更されたデータのみ送信
・サーバーと同期したデバイスが最後にサーバーに送信されてからクライアントで変更されたデータのみサーバーに送信
競合の解決 (クライアントとサーバーの優劣無し)
・同じデータセットがクライアントとサーバーによって同時に更新
デバイスエンドSDKはフレームワークを提供するため、アプリ開発者は複雑なデータ同期やオフラインストレージに対処する必要がありません
高度な機能
バックエンドデータソースのサポート
・Konyコネクタを使用して、様々なエンタープライズバックエンドデータソースに接続
マルチスレッド
・複数の同期セッションを生成
・同期セッションはアプリのバックグラウンドで実行
階層エンティティの同期サポート
・エンティティを階層的にダウンロード/アップロードできるため、Kony Fabric Object Serviceバックエンドへのネットワーク呼び出しを低減
ダウンロードでのバッチサポート
・大量のデータを複数のバッチでダウンロード可能
アップロードでのバッチ処理サポート
・デバイスから複数のバッチを介して大量のデータをアップロード可能
フィルター
・同期操作でOdataフィルタークエリをサポート
同期の進行状況
・同期の進行状況イベントにより、アプリ開発者はダウンロードされたレコードの数などの追加情報とともにい現在のステータスを知ることが可能
リセット
・クライアントデバイスデータベースを空の状態にリセットします
ロールバック
・アプリを以前の同期状態に戻すことが可能
データベースの暗号化
・FIPS準拠の暗号化により、パスフレーズを使用しデバイスデータベースを保護することが可能
エラー処理と同期エラー
・エラー処理の改善は、OMRまたは同期操作中の問題のトラブルシューティングに役立ちます
構成
まずオフラインオブジェクトは「Offline enabled」のチェックボックスがオンになっている場合のみオフラインでもObject Serviceが有効になります。これはデバイスに同期する必要がある全てのFabricアプリのObject Serviceに対して実行する必要があります。
同期環境のセットアップ
オプションの構成
Change tracking
・すべてのオブジェクトの変更トラッキング列としてタイムスタンプフィールドを選択します。これにより、増分同期が可能になり、これがなければ、同期は常にデータ全体をダウンロードします。
Soft delete
・フィールドをソフト削除として選択します。これにより、クライアントで削除されたレコードの同期が可能になります。このプロパティがないと、クライアントは完全削除されたデバイスデータベースに存在するレコードについて知ることがなくなります。
クライアントの動作はオフラインオブジェクトのメタデータに依存するため、すべてのオブジェクト、その名前、データ型、関係、階層およびアクションが適切に定義されていることを確保してください。
同期環境のセットアップ
最初のセットアップにはネットワーク接続が必要です。
セットアップは、Fabricアプリにリンクされているオフライン対応Object Serviceのメタデータを取得します。その後、ネイティブチャネル(Android・iOS・Windows)のSQLiteおよびWebチャネルのIndexedDBに必要なオブジェクトデーブルを作成します。
Object Serviceメタデータには、オブジェクトプロパティ・データタイプ・他のオブジェクトとの関係などに関する情報が含まれ、同期環境の設定とデバイスでのCRUD操作入力の検証に使用されます。
オフラインオブジェクトAPIを使用する前に、アプリを起動する度にセットアップAPIを呼び出す必要があります。同期環境が作成されると、その後のセットアップの呼び出しによりデバイスデータベースからメモリにメタデータがロードされます。したがって、ネットワーク接続は必須ではなくなります。
その後のセットアップAPIの呼び出しには、オフライン対応Object Serviceに加えられた最新の変更は組み込まれません。ローカル同期環境で最新のメタデータを取得する場合は、リセットAPIまたはincrementalSetup APIを使用できます。
設計上の考慮事項
●データ型
Fabricは、オブジェクトフィールドのString・Date・Boolean・Number・Binaryデータ型をサポートし、バックエンドデータ型はこれらに適切にマッピングする必要があります。
ローカルデータベースでのオフラインCRUD操作は、入力レコードの不正なデータ型を検証するためObject Serviceプロパティを定義する際にテーブル全体のフィールド（参照フィールドなど）の型と一貫性を保つ必要があります。
●大きなデータセットの同期
AWSのKony Cloudゲートウェイは、デフォルトで30秒のリクエストタイムアウトを課します。これはクラウドサポートチケットの助けを借りることで60秒に延長できます。 同期するデータの量が膨大で、1回のリクエストで60秒以内にダウンロードできない場合、タイムアウトに陥ることなくデータを取得するために次のアプローチを検討してください。
・アプリケーション全体またはObject Serviceレベルではなく、オブジェクトレベルで同期する方法です。これによりリクエストごとにダウンロードするデータ量が削減できます。 定義された関係に対してオブジェクトが正しい順序で同期されていることを確保する必要があります（例：子が続く親オブジェクトの同期）。 多くの場合、最初のアプリ起動時の最初の同期は、後続のデルタ同期とは対照的に大きなデータ量になります。 初期同期にはObjectレベルの同期を使用し、デルタ同期にはObject serviceレベルの同期を使用することを検討することをオススメします。
・デフォルトでは、リクエストごとに500レコードのみがダウンロードされます。 これはデフォルトのバッチ処理（レコード数）によるものでタイムアウトを回避するためにレコードサイズに基づいたバッチサイズのカスタマイズが施されています。 APIを同期するためのオプションとしてバッチサイズを指定することもできます。
●増分同期
変更トラッキングは、各オブジェクトのFabricアプリで定義されている場合、増分同期が有効になります。つまり最後の同期以降に変更されたレコードを取得し同期時間を大幅に改善します。 同期の最大の利点の1つである最後の同期以降に変更されたデータのみをダウンロードするを損なわない為にも、変更トラッキングを行うことをお勧めします。
●同期
デフォルトでは完全同期で、アップロードに続いてダウンロードを実行されます。 アップロードの同期呼び出しが成功しない限り、ダウンロードポリシーを使用した同期呼び出しを行うべきではありません。それを行うことでデバイスデータが一貫性のない状態になる可能性があります。
●キャッシュのアップロード
この機能を有効にすると、アップロードされたレコードのキャッシュがサーバーに24時間保持されます。 これはクライアントが同じレコードをバックエンドに送信する場合に便利です。
アップロードキャッシュを有効にするには、Object Serviceのプロパティから「Enable Upload Cache」設定をチェックをつけます。
すべてのObject Serviceに対してこの機能を有効にしないと、アップロードキャッシュプロパティの後からの変更はデフォルトではデバイスに反映されません。 したがってクライアントアプリは、incrementalSetup APIを使用するか、クライアントの同期環境のAPIをリセットする必要がでてきます。
●コンフリクトの解決
複数のクライアントが同じレコードを変更してバックエンドに同期すると、クライアントのバージョンの1つがサーバーのバージョンと競合する可能性があります。 このような競合を解決するには、すべてのオフライン有効Object Serviceに対して適切な「Conflict Resolution Policy」を選択します。 デフォルトでは「None」で、競合をチェックせず、競合をチェックするオーバーヘッドがないためパフォーマンスの点では最適となっています。
●階層的な処理
オブジェクト間の関係を定義することに加えて、Kony Fabricの
「オブジェクトのマッピング」->「Advanced」->「Related Objects」から、すべての verbに対して正しい階層を選択してください。
例: 下図は「VTI_SAMPLE_ORDER2」エンティティのGET verbにマップされた関連オブジェクトです。
関連オブジェクトを定義する場合、子エンティティでサポートされるアクションタイプを指定することができます。
例: 親の更新操作は、子の作成および更新操作をサポートします。 特定の操作は、子エンティティレベルで無効にすることで親をエンティティのみ許可できます。 新しい子レコードは、親レコードとともにバックエンドにのみ送信することもできます。
関係および関連オブジェクトがFabricコンソールで定義されている場合、アプリケーションまたはObject Serviceレベルで同期を呼び出す際、階層形式でデータがアップロードおよびダウンロードされます。 オブジェクトレベルで同期すると、関係および関連オブジェクトが定義されている場合でも、非階層的な方法でアップロードとダウンロードが行われます。
参照
https://docs.kony.com/konylibrary/konyfabric/kony_fabric_user_guide/Default.htm#Objectservices.htm
https://docs.kony.com/konylibrary/konyfabric/kony_fabric_user_guide/Default.htm#offline_Sync.htm
https://docs.kony.com/konylibrary/konyfabric/offline_objects_user_guide/Default.htm#Offline_Objects_User_Guide.htm