(57)【要約】  データアーキテクチャは、コマンドによって定義されたデータオブジェクトによりデータソースとインターフェースする構成可能なビューを介して企業データソースへアクセスする能力を、モバイルクライアントに提供する。このモバイルクライアントは次にコネクタ（アダプタとも呼ばれる）を介してデータソースと通信を行う。各ビュータイプは、通信リンク及び他のシステム資源がより効率的に使用されるように、異なる機能を有するデータソースへインターフェースする。ビュータイプは、直接ビュー、派生ビュー、代行ビュー、及び定義ビューを含むことができる。
2008533630.tif 000002
【特許請求の範囲】
【請求項１】
複数の企業データソースと、アプリケーションサーバと通信を行うモバイルクライアントとの間で共有されるデータを処理するための、モバイルデータプラットフォームシステム内で使用されるコンピュータシステムのデータアーキテクチャフレームワークであって、
前記コンピュータシステム内の構成可能なビューオブジェクトであって、前記ビューオブジェクトに従って規定のコマンドオブジェクトデータアクションを実行するために前記コンピュータシステム内のデータオブジェクトに結合するビューオブジェクトと、
前記ビューオブジェクトにより規定されるようにデータに操作を行うリレーショナルデータエンジンとを含む、コンピュータシステムデータアーキテクチャフレームワーク。
【請求項２】
前記ビューオブジェクトは、要求されたデータのデータ定義が前記アプリケーションサーバの一つ又は複数のビューオブジェクトから導出される派生ビュータイプである、請求項１に記載のコンピュータシステム。
【請求項３】
前記ビューオブジェクトは、要求されたデータが前記アプリケーションサーバの代行キャッシュ記憶装置から検索される、代行ビュータイプである、請求項１に記載のコンピュータシステム。
【請求項４】
前記代行キャッシュ記憶装置は、既定の処理規則が適用されたデータを提供する、請求項３に記載のコンピュータシステム。
【請求項５】
前記ビューオブジェクトは定義ビュータイプであり、要求されたデータが前記定義ビュータイプのデータ定義に従って提供される、請求項３に記載のコンピュータシステム。
【請求項６】
前記ビューオブジェクトは、要求されたデータが前記企業データソースの一つから直接検索される直接ビュータイプである、請求項１に記載のコンピュータシステム。
【請求項７】
バックエンド企業データソースへのインターフェースを提供するとともに、テーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれかとして接続オブジェクトを介し利用可能なデータインターフェースオブジェクトを公開する接続オブジェクトと、
特定のデータアクションを実行するコマンドオブジェクトと、
前記データインターフェースオブジェクト上で実行される前記コマンドオブジェクトデータアクションの一つをモバイルデータクライアントが規定することを許容するデータオブジェクトと、
前記規定のコマンドオブジェクトデータアクションを実行するために、前記データオブジェクトに結合するビューオブジェクトと
をさらに含む、請求項１に記載のコンピュータシステム。
【請求項８】
前記データアクションは、選択、挿入、更新、及び削除を含むデータアクションの内の少なくとも一つのアクションを含む、請求項１に記載のコンピュータシステム。
【請求項９】
複数の企業データソースと、アプリケーションサーバと通信を行うモバイルクライアントとの間で共有されるデータを処理する方法であって、
前記企業データソースの一つにおけるデータに対するデータ操作の要求をモバイルクライアントから受信する工程と、
前記要求されたデータ操作に対応する規定のコマンドオブジェクトデータアクションを実行するために、データオブジェクトに結合する構成可能なビューオブジェクトを確定する工程と、
リレーショナルデータエンジンを利用することにより、前記ビューオブジェクトにより規定されたように前記データに対する操作を行う工程と
を含む方法。
【請求項１０】
前記確定されたビューオブジェクトは、要求されたデータのデータ定義が前記アプリケーションサーバの一つ又は複数のビューオブジェクトから導出される派生ビュータイプである、請求項９に記載の方法。
【請求項１１】
前記確定されたビューオブジェクトは、要求されたデータが前記アプリケーションサーバの代行キャッシュ記憶装置から検索される代行ビュータイプである、請求項９に記載の方法。
【請求項１２】
前記代行キャッシュ記憶装置は、既定の処理規則が適用されたデータを提供する、請求項１１に記載の方法。
【請求項１３】
前記確定されたビューオブジェクトは定義ビュータイプであり、要求されたデータは前記定義ビュータイプのデータ定義に従って提供される、請求項９に記載の方法。
【請求項１４】
前記確定されたビューオブジェクトは、要求されたデータが前記企業データソースの一つから直接検索される直接ビュータイプである、請求項９に記載の方法。
【請求項１５】
バックエンド企業データソースへのインターフェースを提供するとともに、前記確定したビューオブジェクトに従って、テーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれかとして接続オブジェクトを介し利用可能なデータインターフェースオブジェクトを公開する接続オブジェクトを確定する工程と、
前記確定したビューオブジェクトに従って特定のデータアクションを実行するコマンドオブジェクトを確定する工程と、
前記データインターフェースオブジェクト上で実行される前記コマンドオブジェクトデータアクションの一つを移動データクライアントが規定することを許容するデータオブジェクトを確定する工程と
をさらに含む、請求項９に記載の方法。
【請求項１６】
前記データアクションは、選択、挿入、更新、及び削除の内の少なくとも一つのアクションを含む、請求項９に記載の方法。
【請求項１７】
複数の企業データソースと、アプリケーションサーバと通信を行うモバイルクライアントとの間で共有されるデータを処理するための、モバイルデータプラットフォームシステム内で使用されるデータアーキテクチャフレームワークを含むコンピュータシステムであって、前記コンピュータシステムは、
ビューオブジェクトに従って規定のコマンドオブジェクトデータアクションを実行するために、前記コンピュータシステム内のデータオブジェクトに結合する前記コンピュータシステム内の構成可能なビューオブジェクトを確定する手段であって、前記データアクションは、選択、挿入、更新、及び削除を含むデータアクションの内の少なくとも一つのアクションを含む手段と、
前記ビューオブジェクトにより規定されたように、データに対し操作を行うための手段と
を含み、前記確定する手段は、
バックエンド企業データソースへのインターフェースを提供するとともに、テーブル、ストアドプロシージャ、スクリプト、又はオブジェクトのいずれかとして接続オブジェクトを介し利用可能なデータインターフェースオブジェクトを公開する前記接続オブジェクトと通信を行い、特定のデータアクションを実行するコマンドオブジェクトと通信を行い、前記データインターフェースオブジェクト上で実行される前記コマンドオブジェクトデータアクションの一つを移動データクライアントが規定することを許容するデータオブジェクトと通信を行い、前記規定のコマンドオブジェクトデータアクションを実行するために前記データオブジェクトに結合するビューオブジェクトと通信を行う、コンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、同時係属中のロバート・オファエル（Ｒｏｂｅｒｔ  Ｏ’Ｆａｒｒｅｌｌ）らによる２００５年３月２１日出願の米国仮特許出願第６０／６６４，１２１号明細書、「モバイルデータシステムのためのデータ管理（Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｄａｔａ  Ｓｙｓｔｅｍ）」、同時係属中のロバート・ローファン（Ｒｏｂｅｒｔ  Ｌｏｕｇｈａｎ）による２００５年３月２１日出願の米国仮特許出願第６０／６６４，０８８号明細書、「モバイルデータシステムのためのモジュラーアプリケーション（Ｍｏｄｕｌａｒ  Ａｐｐｌｉｃａｔｉｏｎｓ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｄａｔａ  Ｓｙｓｔｅｍ）」、同時係属中のロバート・オファエルらによる２００５年３月２１日出願の米国仮特許出願第６０／６６４，１２２号明細書、「モバイルデータシステムのためのアダプタアーキテクチャ（Ａｄａｐｔｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｄａｔａ  Ｓｙｓｔｅｍ）」、及び同時係属中のロバート・オファエルらによる２００５年４月１日出願の米国仮特許出願第６０／６６７，８１６号明細書、「モバイルデータシステムのためのモジュラーアプリケーション（Ｍｏｄｕｌａｒ  Ａｐｐｌｉｃａｔｉｏｎｓ  Ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｄａｔａ  Ｓｙｓｔｅｍ）」の優先権の利益を要求する。それぞれの出願日の優先権をここに要求し、またこれらの仮特許出願の開示を参照して本明細書に組み込む。
【０００２】
本特許文書の開示の一部は著作権保護を受ける資料を含む。本著作権者は、本特許文書ないし特許の開示の任意の者によるファクシミリによる複製に対しては本特許文書ないし特許の開示が米国特許商標庁のファイルないし記録にあることから異存がないが、他の場合にはいかなる著作権も全て留保する。
【０００３】
本発明は、一般的にはモバイルコンピューティングシステムに関し、特にモバイルコンピューティングシステムにおけるデータ管理とデータ展開（ｄａｔａ  ｄｅｐｌｏｙｍｅｎｔ）に関する。
【背景技術】
【０００４】
バックオフィス及びフロントオフィス処理の自動化を改善するために、高度な顧客管理（ｃｕｓｔｏｍｅｒ  ｒｅｌａｔｉｏｎｓｈｉｐ  ｍａｎａｇｅｍｅｎｔ：ＣＲＭ）及び企業全体業務管理（ｅｎｔｅｒｐｒｉｓｅ  ｒｅｓｏｕｒｃｅ  ｐｌａｎｎｉｎｇ：ＥＲＰ）システムが利用可能である。多くの会社はこのようなシステムの展開により大幅な節約と効率を達成したが、一方でこのようなシステムを実施するのは厄介であり、既存のレガシーデータシステムと統合するのは困難であると多くの組織体が感じているのも事実である。
【０００５】
最近になって、事業体及び企業は、モバイル従業員が主としてページャー、携帯電話、また携帯情報端末（ＰＤＡ）などのモバイルコンピューティング装置を利用することを支援するＣＲＭ及びＥＲＰシステムを展開している。このような移動体装置を使用するＣＲＭ及びＥＲＰシステムを大規模に採用するための一つの重要な障害は、企業内の他のデータとの統合に係る。
【０００６】
モバイルアプリケーションは企業の他のデータシステムとの統合を妨げる独自仕様の（ｐｒｏｐｒｉｅｔａｒｙ）閉じたアーキテクチャ内にしばしば導入されるので、企業データ統合問題が発生し得る。例えば、企業におけるデータは４つ又は５つの異なるソースにおいて維持されると考えられる。データソースのいくつかとして、ＣＲＭシステム、ディスパッチシステム、ＥＲＰシステム、財務記録システムが挙げられる。これらのデータソースの各々は異なるデータアーキテクチャ、フォーマット、プロトコルを利用することができる。格納されているデータ、そしてこのデータ及びアクセスメカニズムの構成は、絶えず変化している。多くのモバイルコンピューティングシステムは、企業内の様々なソースからのデータが収集される中間的なデータ記憶装置を作成する。このようにして、それぞれが異なるデータアーキテクチャ及びフォーマットを有する異なる企業データソースからのデータを単一の共通データベース内に収集することができる。モバイルユーザは、実際の企業データソースではなく中間的なデータ記憶装置にアクセスすることにより企業データにアクセスすることができる。しかしながら、中間的な記憶装置は、それ自身のデータ更新問題及びデータコンフリクト問題を生ずる。中間的なデータ記憶装置内のデータが企業データソース内のデータの忠実な複製であることを保証するために、同期動作と他の保護手段が頻繁に実行されなければならない。
【０００７】
ネットワークサーバを介して企業データソースへインターフェースするモバイルコンピューティング装置を利用することができるデータ統合ソリューションを提供することは知られている。このようなシステムは米国ワシントン州、ボセル（Ｂｏｔｈｅｌｌ）のデクステラ（Ｄｅｘｔｅｒｒａ）社に譲渡された２００３年１２月２３日出願の特許文献１に記載される。本出願の内容は参照により本明細書に組み込まれる。
【０００８】
デクステラ社の特許文献１は、モバイルクライアントからの企業データ要求が受信され、要求されたデータを含む適切な企業データソースが確定され、確定された企業データソースからこの企業データが取り出されないし検索される（retrieved）といった分散的なやり方で、データが、複数の企業データソースからモバイルクライアントまでの間で利用されるシステムについて記載している。企業データが検索される際、たとえデータが様々な非リレーショナルタイプの複数の企業データソース（例えばファイルシステム、電子メール等）に由来するとしても、企業データはリレーショナルフォーマットに変換される。変換された企業データは、モバイルクライアント内のリレーショナルデータ記憶装置に格納される。このようにして、モバイルアプリケーションは複数の企業データソースからのデータに完全に統合され、そしてデータ更新と構成変更（Ｃｏｎｇｉｇｕｒａｔｉｏｎ  Ｃｈａｎｇｅ）は中間的なデータ保存記憶装置を使用することなくリアルタイムでモバイルクライアントとの間で配信されるので、企業データソースとモバイルクライアント間の複雑な同期及び非同期データ問題を回避する。リアルタイムのデータ変更は、データ更新だけでなくモバイルアプリケーション自体の変更の展開も含むことができる。リアルタイムの変更は、さらにデータコンフリクト検出及び解決にも適応される。
【０００９】
上記で参照したデクステラ社のシステムは、目標のないしターゲットの企業データソースがオブジェクト又はデータテーブルを含み、各ターゲットデータテーブルがビュー（Ｖｉｅｗ）と呼ばれるデータオブジェクトへマッピングされるシステムアーキテクチャに基づく。すなわち、企業データソース内の各データテーブルに対応するビューが定義され、そこからアプリケーションはデータを取得する。ビューはアプリケーション開発者により定義されてもよいし、あるいは他のベンダーから定義されてもよい。ビュー内のデータは、ビジネスオブジェクトと呼ばれる一つ又は複数のデータエンティティ間で共有される。単一のビジネスオブジェクトは複数のビューからのデータを利用することができるので、複数の企業データソースからの（非互換のデータフォーマットを有するデータソースからも）データを利用することができる。このシステムでは、コネクタと呼ばれるデータオブジェクトがデータ共有用インターフェースに企業データソースを提供する。
【００１０】
一組のビジネスオブジェクトが定義されると、アプリケーション開発者は、ビューとコネクタを記述し定義することに関与するのではなく、ビジネスオブジェクトへのインターフェースを介しデータを扱いつつアプリケーションを設計することができる。このように、開発者にはフォーマットフリーのデータインターフェースが提示され、従ってターゲットにおける差異は開発者から取り除かれる。
【００１１】
上記で参照した特許文献１に記載のシステムは、多種多様の企業データソースへのアクセスを許容するモバイルコンピューティングプラットフォームに対して強力な開発ツールを提供する。また一方、ビューデータの構成における優れた適応性は、システムの能力を拡張するとともに優れた柔軟性を提供することができると考えられる。本発明はこのような優れたビュー構成能力を提供する。
【特許文献１】米国特許出願第１０／７４６，２２９号明細書
【発明の開示】
【課題を解決するための手段】
【００１２】
本発明によると、モバイルクライアントは、コマンドによって定義されるデータオブジェクトによりデータソースとインターフェースする構成可能なビューを介して企業データソースへアクセスし、これによりコネクタ（アダプタとも呼ばれる）を介してデータソースと通信を行う。各タイプのビューは、通信リンク及び他のシステム資源がより効率的に使用されるように、異なる機能を有するデータソースへインターフェースする。例えば、ビュータイプは、直接ビュー（Ｄｉｒｅｃｔ  Ｖｉｅｗｓ）、派生ビュー（Ｄｅｒｉｖｅｄ  Ｖｉｅｗｓ）、デリゲーティッドビューないし代行ビュー（Ｄｅｌｅｇａｔｅｄ  Ｖｉｅｗｓ）、定義ビュー（Ｄｅｆｉｎｉｔｉｏｎ  Ｖｉｅｗｓ）を含むことができる。これらの新規ビュータイプはデータインターフェース上で優れた制御を行うことができ、またシステム資源のさらなる利用のためにこれらの新規ビュータイプを構成することができる。
【００１３】
直接ビューは企業データソースからデータを直接検索するビューである。派生ビューはサーバからデータを要求する。サーバは実行時に企業データソースから対応データの基本セットを検索し、検索されたデータをリレーショナルデータエンジン（ＲＤＥ）内に置く。リレーショナルデータエンジンは派生ビューフィルタパラメータを適用し、フィルタリングされたデータを抽出し、要求する派生ビュータイプにこの抽出されたデータを提供する。代行ビューは定期的に企業データソースからデータを検索し、検索されたデータをリレーショナルデータエンジンキャッシュ内に置く。モバイルクライアントの以降の企業データ要求はリレーショナルデータエンジンキャッシュから対応することができ、これによりモバイルクライアントとデータソース間のデータトラフィックを低減する。定義ビューは、検索されたデータがどこで維持されるか、システムサーバにおいてかモバイルクライアントにおいてかに関する制御を可能にし、これによりシステム資源の利用に関する制御を拡張する。
【００１４】
本発明の他の特徴と利点は、本発明の原理を一例として例示する以下の好ましい実施形態の説明から明らかである。
【発明を実施するための最良の形態】
【００１５】
本発明により構築されたモバイルデータ統合システムにおいて、アプリケーションを実行するモバイルクライアントは構成可能なビューオブジェクトを介して企業データソースとインターフェースし、ビューオブジェクトはデータオブジェクトを介してデータにアクセスし、データオブジェクトはアダプタ（コネクタとも呼ばれる）を介して企業データソースにインターフェースするコマンドオブジェクトとして定義される。サポートされる複数のタイプのビューは、優れた適応性を提供することによりシステムの能力を拡大するとともに大きな柔軟性を提供する。各タイプのビューは、通信リンク及び他のシステム資源がより効率的に使用されるように、異なる機能を有するデータソースへインターフェースする。
【００１６】
以下に説明されるように、例示される実施形態では、ビュータイプは直接ビュー、派生ビュー、定義ビュー、指定ビュー（Ｄｅｓｉｇｎａｔｅｄ  Ｖｉｅｗ）を含む。直接ビューは、データオブジェクト、コマンド、アダプタを介し企業データソースからデータを直接検索する。派生ビューはフィルタパラメータを組み込み、サーバからのデータを要求する。サーバは実行時に企業データソースから対応データの基本セットを検索し、検索されたデータをリレーショナルデータエンジン（ＲＤＥ）内に置く。リレーショナルデータエンジンは派生ビューフィルタパラメータを適用して、フィルタリングされたデータを抽出し、要求する派生ビュータイプにこの抽出されたデータを提供する。代行ビューは、代行ビューのパラメータに従って定期的に企業データソースからデータを検索し、検索されたデータをリレーショナルデータエンジンキャッシュ内に置く。モバイルクライアントからの以降の企業データの要求は、要求されたデータを企業データソースから直接ではなくＲＤＥキャッシュから得ることにより対応することができ、これにより、モバイルクライアントとデータソース間のデータトラフィックを低減する。モバイルクライアントからの更新データは、アダプタを介して企業データソースに直接戻される。定義ビューは、検索されたデータがどこで維持されるか、システムサーバにおいてかモバイルクライアントにおいてかに関する制御を可能にする。通常、システム資源の量が２つの構成間の選択を決定する。
【００１７】
例示的な基本システムアーキテクチャの基本構成は、図１、図２、図３に関連して説明される。本発明の構成可能なビューオブジェクトを組み込むモバイルクライアントデータシステムの好ましい実施形態において、システムはアダプタ−コマンド−データオブジェクトアーキテクチャを利用する。アダプタ−コマンド−データオブジェクトについては、図４に関連する「Ｖ．アダプタアーキテクチャ」において、図１、図２、図３のシステムからのアーキテクチャ変更の点から以下にさらに説明される。構成可能なビューオブジェクトについては、以下の図５に関連する「ＶＩ．ビュータイプ」において、さらに詳細に説明する。
【００１８】
Ｉ．システム概要
本発明は、モバイルアプリケーションが複数の企業データソースに統合されるように、複数の企業データソースからモバイルアプリケーションを実行するモバイルクライアントまでデータが利用されるシステムであって、中間的なデータ記憶装置を使用することなくデータ更新と構成変更がリアルタイムでモバイルクライアントに配布されかつモバイルクライアントから受信されるシステムを提供する。中間的なデータ保存設備を排除することにより、企業データソースとモバイルクライアント間の複雑な同期と非同期データ問題を回避する。こうして、モバイルアプリケーションのデータ更新と構成更新は、リアルタイムで企業からモバイルクライアントへ、またモバイルクライアントから企業へ伝達することができる。本システムを介しリアルタイムで変更は伝達され得るので特別の同期操作は必要ではない。
【００１９】
ＩＩ．システムプラットフォーム
図１は、上記参照されたデクステラ社の特許文献１において説明したように構築された本発明による好適なコンピュータシステム環境１００のブロック図である。図１に、マイクロソフトポケットＰＣ又はパームＰＤＡオペレーティングシステムと共に動作する個人用デジタル情報処理端末（ＰＤＡ）装置などのモバイルクライアントデバイス１０２を示す。サーバからデータを要求し、データ更新を受信し、新しいデータを提供し、構成変更を受信するために、モバイルクライアントデバイス１０２はネットワーク接続１０４上でアプリケーションサーバ１０６と通信を行う。複数のモバイルクライアント１０２がサーバ１０６と通信を行うことができることを理解すべきである。図の簡潔性のため、図１には単一のクライアントデバイス１０２のみが示される。
【００２０】
モバイルクライアント１０２は、複数の企業データ記憶装置から検索されるリアルタイムのデータのためのサーバ側コネクタウェブサービスを使用する。さらに、モバイルクライアントは、リアルタイムのクライアント側データ更新、サーバ側データ更新及び構成更新の管理のためにサーバ側データマネージャウェブサービスを使用する。
【００２１】
アプリケーションサーバ１０６は、ＣＲＭデータソース、ＥＲＰソース、財務システム資源、レガシーデータ記憶装置等の企業データソース１０８と通信を行う。図１に図示された例示的企業データソースは、米国カリフォルニア州サンマテオ（Ｓａｎ  Ｍａｔｅｏ，Ｃａｌｉｆｏｒｎｉａ，ＵＳＡ）のジーベルシステムズ社（Ｓｉｅｂｅｌ  Ｓｙｓｔｅｍｓ，Ｉｎｃ）による「ジーベル（Ｓｉｅｂｅｌ）」ソフトウェア、米国カリフォルニア州レッドウッドショアズ（Ｒｅｄｗｏｏｄ  Ｓｈｏｒｅｓ，Ｃａｌｉｆｏｒｎｉａ，ＵＳＡ）のオラクル社（Ｏｒａｃｌｅ  Ｃｏｒｐｏｒａｔｉｏｎ）による「オラクル（Ｏｒａｃｌｅ）」ソフトウェア、独国ウォルドルフのＳＡＰ社（ＳＡＰ  ＡＧ  ｏｆ  Ｗａｌｌｄｏｒｆ，Ｇｅｒｍａｎｙ）による「ＳＡＰ」ソフトウェア、及び従来のソフトウェアを含むデータを含む。管理者アプリケーション１１０と開発者アプリケーション１１２は、以下にさらに説明されるように、システム用メタデータ１１４も格納するアプリケーションサーバ１０６と通信を行う。
【００２２】
アプリケーションサーバ１０６は、データ交換と更新、ユーザ認証、セキュリティ、及びロギングサービスのための、データマネージャ、構成ないしコンフィギュレーション、及びデータコネクタウェブサービスを提供する。アプリケーションサーバ１０６は、また、ビジネス情報及びビジネスルールの形式でビジネスプロセス管理を扱う。
【００２３】
また、モバイルクライアント１０２は、ビジネスデータ１２０を格納するリレーショナルデータベース１１８と、モバイルクライアント１０２上のアプリケーション実行のためのメタデータ１２２を格納するリレーショナルデータベースとを含むデータ記憶装置１１６を含む。モバイルクライアント１０２側にインストールされるアプリケーション１２４は、好適な機能を実行する様々なソフトウエアコンポーネントを含む。例えば、このアプリケーション１２４は、サービスが要求された場所についてフィールドサービス要員に通知し、このサービス要求の性質について説明し、このサービスアクセスをログに記憶してアカウントを設定するフィールドサービスアプリケーションを含んでもよい。アプリケーション１２４は、モバイルクライアント１０２により要求されたデータを処理する複数のアプリケーションを含むことができる。
【００２４】
アドミニストレータアプリケーションないし管理者アプリケーション１１０と、ディベロッパアプリケーションないし開発者アプリケーション１１２とは、ともに「スタジオ（Ｓｔｕｄｉｏ）」コンポーネント１３０を含む。例示された実施形態では、管理者アプリケーションと開発者アプリケーションは２つの個別のアプリケーションとして設けられ、メタデータとアプリケーションインターフェースとを含むシステムを構成する手段を提供する。
【００２５】
システム１００は、サービスアプリケーション１２４を支援するモバイル企業プラットフォームを含む。このシステムは、モバイルビジネスプロセスを強化するモバイル化ソフトウェアソリューションを効果的に配置管理する一組のウェブサービスを提供する。通常の例としては、ＣＲＭ又はＥＲＰへの統合化、セールスフォース自動化（ＳＦＡ）、企業のカスタマーサポート及びヘルプデスク機能が挙げられる。このような企業アプリケーションは、一つの機能又はシステムからのデータが、異なる機能又はシステムによりしばしば使用されるという点で、異アプリケーション相互作用（ｃｒｏｓｓ−ａｐｐｌｉｃａｔｉｏｎ  ｉｎｔｅｒａｃｔｉｏｎ）に依存する。モバイルクライアント上で実行されると、既存のアプリケーション機能及び企業情報は、複数の企業ソフトウェアアプリケーションと、レガシーデータシステムと、モバイル従業員との間で利用される。このようにして、これらのアプリケーションに対し、そしてモバイル企業プラットフォームに対し大きな投資回収を達成することができる。
【００２６】
モバイル企業プラットフォーム１００は、フィールドにおけるモバイルクライアント及び関連する携帯機器の利用を簡単化するウェブサービスを提供する。これらのウェブサービスはデータマネージャ機能、環境設定機能及びコネクタ機能を含む。これらは、以下にさらに詳細に説明される。モバイルクライアント１０２にインストールされたアプリケーション１２４は、これらの機能がアプリケーションサーバ１０６により正常に開始された後、接続又は非接続状態いずれにおいても完全に機能することができる。
【００２７】
ＩＩＩ．論理アーキテクチャ
図１に例示されたモバイル企業プラットフォームを利用する任意のクライアントアプリケーションは、図２のブロック図に例示されたシステムコンポーネントを利用する。これらのコンポーネントは次のものを含む。
【００２８】
ビジネスオブジェクト：ビジネス概念に基づくプログラム可能なオブジェクトであり、異なる企業データソースからのフィールドと関連情報とを組み合わせる（例えば、顧客、コンタクト、資産、タスクなどのデータソース）。
【００２９】
ビジネスルール：企業データソースからのビジネスデータに対し適用されるチェック付きのビジネス定数を利用する、ビジネスプロセスを実施するためのカスタム論理。
【００３０】
ビジネス定数：クライアントアプリケーションを介して使用するためのユーザ構成可能な変数と、クライアント及びサーバ側のビジネスルール（例えば、ビジネスルール、警告メッセージ等）。
【００３１】
データソースコネクタ：広範囲の種類の企業データソースへのアクセスをシームレスに提供するように設計されたデータソースコネクタ（例えば、オラクル及びＳＱＬサーバに従ってフォーマットされたようなデータベース、ＭＱシリーズ又はＭＳＭＱのようなメッセージ通信システム、ジーベル又はピープルソフト（Ｐｅｏｐｌｅｓｏｆｔ）のようなＣＲＭアプリケーション、一般的なウェブサービス等）。
【００３２】
ビジネスプロセス：米国ワシントン州ボセルのデクステラ社の、ビジネスプロセスをモデル化するためのフォームツーフォーム（ｆｏｒｍ−ｔｏ−ｆｏｒｍ）ナビゲーションパラダイムを定義する「フォースフロー（Ｆｏｒｃｅ  Ｆｌｏｗ）」処理のようなメタフォー（ｍｅｔａｐｈｏｒ）。
【００３３】
フォーム：情報を示し、情報を集め、所与のビジネスプロセスを通してユーザを導くように設計されたイベントドリブン論理を有する標準表示画面の組合せ（例えば、見る、編集、検出等）であり、ここでは「フォースフロー」又は「フィールドフロー（ＦｉｅｌｄＦｌｏｗ）」と呼ばれる。
【００３４】
ビュー：一つ又は複数のビジネスオブジェクトにより利用される企業データソース又はアプリケーションから識別された変更可能なデータのテーブル表現。
【００３５】
フィルタ：ビジネスオブジェクトに利用可能なデータを修正するための、ビューに対し適用可能なフィルタ。
【００３６】
これらのコンポーネントは、マイクロソフト社の「ネット（．ＮＥＴ）」等のテクノロジーフレームワークと、マイクロソフト社の「ビジュアルスタジオネット（Ｖｉｓｕａｌ  Ｓｔｕｄｉｏ．ＮＥＴ）」等のツールとを利用することにより構築される任意のクライアントアプリケーションの環境設定（論理アーキテクチャ）を指定するために使用することができる。当業者は、アプリケーション及びそれに関連するデータオブジェクトを指定するこのようなプログラミングツールに精通するであろう。
【００３７】
図１に例示されたモバイル企業プラットフォームは、メタデータドリブンフレームワークとして実施される。このフレームワークは統合化クライアント・サーバウェブサービスを提供し、フェールセーフかつミッションクリティカルなモバイル企業ソリューションを展開するのに必要な接続、環境設定、及びデータ管理サービスを可能にする。
【００３８】
図２は、図１のモバイル企業プラットフォームにおいて、リレーショナルデータベーステーブル及び外部アプリケーションビジネスオブジェクトの構造がメタデータとしてビューにマッピングされたことを示す。一つ又は複数のビューはビジネスオブジェクトにより使用され、メタデータで定義され、次にモバイルアプリケーションにより利用される。モバイルアプリケーションは「デクステラスマートクライアント（Ｄｅｃｓｔｅｒａ  Ｓｍａｒｔｃｌｉｅｎｔ）」と呼ばれるクライアントフレームワークを利用する。このクライアントフレームワークは、データマネージャ及び／又はコネクタウェブサービスを介してのクライアントサーバデータ通信だけでなく、ビジネスオブジェクトのインスタンス化、モバイルクライアントデバイス上に常駐する内在物理データベースへのローカルデータアクセス、デバイス統合化を管理する。プラットフォームにおいて、すべての論理層（例えば、ビジネスオブジェクト、ビュー、フィルタ、コネクタ）に対する仕様はメタデータ内に定義され維持される。
【００３９】
モバイル企業プラットフォームは論理スタックとして設計され、論理アーキテクチャにおける層を、非隣接メンバーを除くすべてから隔離するように設計される。論理スタックの最下部（ターゲット層）には、バックエンドの企業データソースに常駐するデータが存在する。プラットフォームは所定位置のソースデータと連動し、従ってレコードのバックエンドシステム内の情報が中間層の複製データベースに複製されることを必要としない。すなわち、中間的なデータ記憶装置は必要ではない。これは、リアルタイムのデータアクセスだけでなく設計の柔軟性を提供し、プラットフォーム及びアプリケーションの維持管理総経費を低減するのに役立つことができ、データ管理プロセスの簡易化を支援する。
【００４０】
論理スタックにおける次の上位層はコネクタ層である。コネクタ層は、アプリケーションサーバへのバックエンドデータ格納をリレーショナルフォーマットで記述するプログラマチック構成体を提供する。セキュリティ設定（認証方法、ユーザ及びグループ定義等）だけでなく、企業データソースに接続する方法に関する情報もまたメタデータ内に格納され、そしてアドミニストレータコンポーネント（Ａｄｍｉｎｉｓｔｒａｔｏｒ  ｃｏｍｐｏｎｅｎｔ）を使用することにより維持される。
【００４１】
スタックにおける次の層はビュー層であり、ビュー層はバックエンドの企業データソース内のオブジェクト又はテーブルへの１対１マッピングを提供するオブジェクトを含む。例えば、バックエンドシステムがＣＵＳＴ＿ＡＤＤＲ（顧客アドレス）と呼ばれるテーブルを有し、かつアプリケーションにおける使用のためにこのテーブルからのデータが必要とされる場合、アドミニストレータコンポーネント内にビューが生成される。企業データソース外では、モバイル企業プラットフォームの環境におけるこのデータを表すために、アドミニストレータビューは例えばＣＵＳＴＯＭＥＲ＿ＡＤＤＲＥＳＳと呼んでもよい。ビューはバックエンドシステムにおけるデータオブジェクトのプロパティ又はコラムに対応するプロパティを有するということを理解すべきである。しかしながら、バックエンドデータソース内のすべてのプロパティがビューにおけるプロパティとして必ずしも要求されない。実際は、必要とされるプロパティは、管理用コンポーネント（ａｄｍｉｎｉｓｔｒａｔｉｖｅ  ｃｏｍｐｏｎｅｎｔ）において定義され、メタデータとして格納される。先ほどの例では、プロパティは、ＩＤ、番地（ＳＴＲＥＥＴ＿ＡＤＤＲ）、市、州、ジップコー（ドＺＩＰ＿ＣＯＤＥ）のようなフィールドを含んでもよい。
【００４２】
さらに、ユーザは、ビュー内でプロパティのデータタイプを定義することができ、そしてこれらのデータタイプは、企業データソース内の対応するプロパティのデータタイプとは独立していてもよい。識別可能なビュープロパティの他の選択肢は、一意的な識別子、リードオンリー、インデクシング、必要プロパティ、長さである。上記情報はすべてメタデータとして格納される。
【００４３】
また、ビュー層は、データコンフリクトの識別を提供し、そしてこのようなコンフリクトを解決する手段を提供する。データコンフリクトは、例えばモバイルクライアントからアップロード中のものとサーバに存在するものとの間にデータ変更がある場合は常に発生し得る。このようなコンフリクトの解決はビュー層において実行することができ、最新のデータ変更が常に優先することを許容する、あるいは特定のソース（例えば、モバイルクライアント又は企業データソースのいずれか）からのデータ変更がデータタイプ（例えば、フィールドデータ又は顧客アカウントデータ）に依存して優先することを許容する等のビジネスルールを実施する。これは、データマネージャウェブサービスに関連して以下にさらに説明される。
【００４４】
図２に図示されるように、複数のデータ記憶装置内の複数のオブジェクトに対してビューを定義することができ、従ってデータ複製の負担なしに、アプリケーション展開の際、また現場システムの使用の際の柔軟性を提供する。コネクタと同様に、ビューの定義はメタデータに格納されアドミニストレータにより管理される。当業者は、さらなる説明なしにメタデータ内のデータ定義の詳細を理解するであろう。上記のように、次の層に渡されるデータを修正するために、フィルタをビューに適用することができる。前述の管理者アプリケーションは、バックエンドデータ格納オブジェクト（企業データソースからの）のオブジェクトインターフェース又はテーブル定義に基づいてビューを自動的に生成するビューウィザードを含むビュー管理機能を提供する。
【００４５】
図２の図表における次の上位層は、一つ又は複数のビューにマッピング又は関連付けられるビジネスオブジェクトを含む。プラットフォームのビジネスオブジェクトは、カスタム化モバイルアプリケーションを構築する際に開発者がインターフェースするプログラマチックエンティティ（ｐｒｏｇｒａｍｍａｔｉｃ  ｅｎｔｉｔｙ）である。ビジネスオブジェクトは、それぞれが簡易データタイプであってもよいし、あるいは別のビジネスオブジェクトであってもよい複数のプロパティを含む。プラットフォームのビジネスオブジェクトは複数のビューにマッピングされてよいので、開発者は、複数の異種混合のデータソースから供給されるデータを表す単一のエンティティを扱うことができる。従って、本発明のモバイル企業プラットフォームに従って定義された単一のビジネスオブジェクトは、複数の恐らく非互換の企業データソース（異なる独自フォーマット等）からのデータを含むことができる。
【００４６】
モバイルアプリケーション及びモバイルクライアントデバイス用のアプリケーションを作成するか修正する際、開発者はもっぱらビジネスオブジェクト層とやり取りすればよい。これにより、開発者はソースデータ用のバックエンドシステム（企業データソース）を理解するかあるいはそれと直接やり取りするためのいかなる要件からも逃れることができる。このようにして、ビジネスオブジェクト層は、アプリケーション開発者に対しオブジェクトベースのインターフェースを提供し、データの持続性（ｐｅｒｓｉｓｔｅｎｃｅ）及び検索の詳細を抽出する。開発者は移動体装置上のローカルデータ記憶装置と直接やり取りする必要はない。さらに、データが有する分離された性質により、モバイルクライアントは、更新処理中にアプリケーションサーバに渡されることになるデータ変更をクライアント内にローカルに格納することにより、ビジネスオブジェクトのインターフェースを介して自動的にこのデータ変更の処理を管理する。これにより、開発者はさらにこの機械的なプログラミングタスクからも逃れることができる。
【００４７】
ビジネスオブジェクトは、メタデータとしてモバイルクライアントデバイス上に存在し、また、管理者アプリケーション（図１）を使用することにより管理される。モバイル企業プラットフォームを通じてメタデータを使用することにより、ほとんどのデータエンティティの属性及び振る舞い（ｂｅｈａｖｉｏｒ）がコーディングではなくグラフィカルユーザインターフェースを介して構成することができる環境を提供する。
【００４８】
モバイル企業プラットフォームのメタデータ駆動的（ｍｅｔａｄａｔａ−ｄｒｉｖｅｎ）性質により、ステートレスサーバアーキテクチャによるモバイルクライアント上でのビジネスプロセスが実行できるようになる。メタデータを介することにより、モバイルアプリケーションを構成しカスタマイズすることができる。メタデータは、企業データを移動体装置へ参照させるビジネスオブジェクトの構造を定義し、また、ビジネスプロセスを管理するビジネスルールをトリガする事象を定義する。
【００４９】
メタデータデータベースは、ビジネスオブジェクトを構成するためにコネクタを介してエクスポーズないし公開（ｅｘｐｏｓｅ）されるクロスファンクショナル・クロスアプリケーション・バックエンドビジネス情報の参照子（ｒｅｆｅｒｅｎｃｅ）を含む。この処理は、接続する企業データソースビジネス情報をビジネスオブジェクトにより構成し参照するスタジオ（Ｓｔｕｄｉｏ）コンポーネント（図１）を介して達成される。これにより、このモバイルアプリケーションの特定データにパスを提供し、従って企業データソースからのいかなるビジネスデータも本来のデータフォーマットでアプリケーションサーバ上に、あるいはデータ更新のためにシステムの他のいかなる中間データ記憶装置上にも格納されないということを保証する。メタデータを使用するこの非侵入的でリアルタイムの同期手法は、クロスファンクショナルなデータアクセス、データ一貫性、及びデータ完全性を最大化する一方で、混乱を最少にしつつモバイル企業プラットフォームがバックエンドシステムに効果的に接続することを可能にする。
【００５０】
ＩＶ．モバイル企業プラットフォームコンポーネント
Ａ．モバイルアプリケーション
上記のように、モバイルクライアント１０２（図１）は、企業のビジネスプロセスを実施するインストール済みアプリケーション１２４を含むことができる。このアプリケーションは上述のモバイル企業プラットフォームを活用することができ、メタデータ内に構成されたビジネスプロセスを駆動するビジネスオブジェクトをアプリケーションがどのようにインスタンス化するかを示す。
【００５１】
例えば、タスク又は作業命令情報はビューを介してモバイルアプリケーションに提供され、ビジネスオブジェクトを介してアクセスされるであろう。ビュー定義を介したビジネスデータの検索では、データマネージャウェブサービスを利用することにより、ビジネスオブジェクトは、タスクを説明するために、モバイルアプリケーションにビジネスデータを配信することができる。このデータは移動体装置上のローカルリレーショナルデータベースに格納される。タスクデータに対する更新がアプリケーションからの要求内のタスクビジネスオブジェクトに委ねられると、スマートクライアントアプリケーションは、モバイルクライアント上のビューにより定義済みのデータ記憶装置への変更を保持する。次にスマートクライアントは、データマネージャウェブサービスを介しこのデータ更新を元のデータソースへ戻す管理を行い、こうしてデータの完全性と一貫性を保証する。
【００５２】
ここで説明されるモバイル企業プラットフォームにおいて利用可能なウェブの深さ、広さ、パワー、サービス（例えば、接続、構成、及びデータマネージャサービス）を利用することにより、セールスフォースの生産性、顧客サービス、及び支援ソリューション等のアプリケーションを含む大規模なモバイルアプリケーション群を容易に構築することができる。このようなアプリケーション群は、石油／ガス、ヘルスケア／医療、及び金融サービス産業のソリューションを含む広範囲な一組の垂直形アプリケーションに統合することができる。
【００５３】
Ｂ．サーバコンポーネント
アプリケーションサーバは一種のメタデータ駆動のプラットフォームアプリケーションであり、情報、アプリケーション及びビジネスプロセスをモバイルクライアントに提供し、モバイル企業プラットフォームとバックエンド企業データソースのホストとの間のデータ完全性の管理を保証する。アプリケーションサーバは、米国ワシントン州レドモンド（Ｒｅｄｍｏｎｄ，  Ｗａｓｈｉｎｇｔｏｎ，  ＵＳＡ）のマイクロソフト社（Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ）の技術「ネット（．ＮＥＴ）」上に構築される処理ベースの高性能ソリューションである。「．ＮＥＴ」技術を使用することにより、モバイル企業ソリューションは、データ交換とデータ移送のためのＸＭＬとＳＯＡＰを利用した固有のウェブサービスであるフレームワークとなる。アプリケーションサーバは、図１の機能アーキテクチャ図に示すように３つのコアウェブサービスを提供する。
【００５４】
コネクタウェブサービス
コネクタウェブサービスは、モバイルクライアントと個別の企業データソース間のデータ完全性条件（Ｄａｔａ−Ｉｎｔｅｇｒｉｔｙ  Ｃｏｎｄｉｔｉｏｎｓ）を常に制御する一方で、既存の企業アプリケーションインフラストラクチャーの非侵入的な統合を提供する。
【００５５】
コンフィギュレーションウェブサービス
コンフィギュレーションウェブサービスは、ビジネスデータ、ビジネスオブジェクト、ビジネスルール、ビジネス定数、及び認証、ロギング、セキュリティ、モバイルクライアントに渡されるモバイルアプリケーション（移動体装置上に常駐するコンポーネントアプリケーション）を包含する役割などのシステム構成を定義するメタデータを管理する。
【００５６】
データマネージャウェブサービス
データマネージャウェブサービスは、モバイルクライアントアプリケーション、アプリケーションサーバ、第三者企業データソース間の更新対話処理を指揮する。加えて、データマネージャウェブサービスは、リアルタイムの照会のためにコネクタ層と直接通信を行う能力を提供する。データマネージャウェブサービスは、データの保全を実施するために、複数の企業データソースに対する複数ユーザによる複数の更新に関する様々な条件を管理する方法における柔軟性を提供する。データマネージャウェブサービスはアプリケーションサーバを介してこれを行うか、あるいは任意のＡＰＩ、及び／又は第三者の公開ウェブサービスにこれを導いてもよい。
【００５７】
このようにして、データマネージャウェブサービスは、システムのモバイルクライアントを通じてアプリケーション更新とデータ変更の展開を管理することができる。これらのコンポーネントの各々について次にさらに詳細に説明する。
【００５８】
１．コネクタウェブサービス
コネクタウェブサービスは、すべてのＯＤＢＣ準拠データソース又はウェブサービスＡＰＩとの通信を支援するように設計される。コネクタウェブサービスは、顧客が、一つ又は複数の第三者システムに格納されたデータに基づいてビューを定義し構築することを可能にする。コネクタウェブサービスは、モバイルクライアントからのリアルタイムデータアクセスだけでなく標準的なバッチ更新も許容する公開インターフェース（Ｐｕｂｌｉｓｈｅｄ  ｉｎｔｅｒｆａｃｅ）を有する。
【００５９】
コネクタウェブサービスは、アプリケーションサーバメタアプリケーションと企業データソースの特定インターフェースとの間の物理層接続を提供する。このコネクタは、データベース競合管理及び通知サービス、トランザクション管理、エラー処理を支援する。デフォルトの顧客構成（ｃｕｓｔｏｒｍｅｒ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）では、モバイル企業プラットフォームシステムはＯＤＢＣコネクタ又はウェブサービスコネクタを備えた顧客に展開される。当業者は、ジーベル、ＳＡＰ、ピープルソフト、オラクル、ＳＱＬサーバのような最も一般的な企業システムへのコネクタを形成することができるであろう。
【００６０】
例えば、「オラクル」アプリケーションコネクタにより、顧客が有するＡＰＩ（ＰＬ／ＳＱＬ手順等）に最も近いデータ構造を介して顧客がオラクルサポートサービスを呼び出し、あるいは顧客がＯＤＢＣを介して直接企業データベース自体を呼び出すことができるようにする。すべてのＯＤＢＣコネクタと同様に、ＲＤＢＭＳスキーマの動的な問合せは自動的に実行され、特定のデータベースの物理的設計を公開する。これにより、このシステム内への実際のインターフェースの階層的ビューを顧客に与える。
【００６１】
図３は、どのようにコネクタが企業データソースをモバイル企業プラットフォームへインターフェースするかの例を示す。図３の左側には、ＥＲＰデータソース３０２、ＣＲＭデータソース３０４、人事／財務データソース３０６、レガシー／ＯＤＢＣデータソース３０８を含む複数の企業データソースが表されているが、他のウェブサービス又は他のソース（図示せず）を含んでもよい。図３の中間部には、異なる企業データソースからのデータがどのように図３の右側に示すモバイルクライアント３１６内に格納され関連付けられるかをアプリケーションサーバ３１４に対して規定する、メタデータ３１２が表されている。
【００６２】
この例では、ＯＲＤＥＲ＿ＩＤとして識別されるデータがＥＲＰデータソース内に存在する。Ｆ＿ＮＡＭＥ及びＬ＿ＮＡＭＥとして識別されるデータがＣＲＭデータソース内に存在する。ＣＲＥＤ＿ＬＩＭと識別されるデータは人事／財務データソース上に存在し、保証（ＷＡＲＲＡＮＴＹ）と識別されるデータはレガシー／ＯＤＢＣデータソース内に格納される。これらの識別されたデータはすべて、バックエンドオフィスシステムなどの企業データソース内に格納される。
【００６３】
メタデータ３１２内では、企業データソースからのデータ定義は、クライアント上にデータ記憶装置を作成することと、モバイルクライアント上のこのビジネスデータ（企業データソースからのもの）をリレーショナルデータベースに格納することとのために使用されるビューにマッピングされる。このビジネスデータへのアクセスは、モバイルクライアント上のメタデータ内に定義され格納されたビジネスオブジェクト層を介して行われる。図３に示すように、ＥＲＰデータソースからのＯＲＤＥＲ＿ＩＤは注文ＩＤと呼ばれるビジネスオブジェクトプロパティにマッピングされる。注文ＩＤのリレーショナル定義はモバイルクライアント３１６上のメタデータ３１８に格納され、そしてメタデータにおいても定義された一つ又は複数のモバイルアプリケーションにより利用される。ＣＲＭ企業データソースからのＦ＿ＮＡＭＥデータは、モバイルクライアントデータベース内に格納されたファーストネームのビジネスオブジェクトプロパティ定義にマッピング（格納）され、Ｌ＿ＮＡＭＥデータはラストネームのビジネスオブジェクトプロパティにマッピングされる。同様に、人事／財務データソースからのＣＲＥＤ＿ＬＩＭデータはクレジット限度のビジネスオブジェクトプロパティにマッピングされ、レガシー／ＯＤＢＣデータソースからのＷＡＲＲＡＮＴＹデータは保証のビジネスオブジェクトプロパティにマッピングされる。従って、恐らく類似しない非互換の異種の企業データソース３０２、３０４、３０６、３０８、３１０からのデータは、モバイルクライアント上のビジネスオブジェクトの一つ（モバイルクライアント３１６内では実際の値で示す）を使用するアクセスに対し、適切なフォーマットでデータマネージャウェブサービスを介しモバイルクライアントへ、そしてローカルデータ記憶装置へ伝達される（企業データソースからアプリケーションサーバ３１４に到る線により示す）。
【００６４】
コネクタタイプ
コネクタウェブサービスによりサポートされるコネクタには以下の３つのコネクタタイプがある。
【００６５】
１．ウェブサービスコネクタは、次の場合、すなわちモバイルプラットフォームが第三者システムに接続しており、この第三者システムが（ａ）ＯＤＢＣ非準拠である場合、又は（ｂ）ＯＤＢＣ／ＲＤＢＭＳ接続性を許容しない場合、又は（ｃ）そのインターフェースが標準ＡＰＩにより定義され、かつウェブサービス記述言語（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｏｒ  Ｌａｎｇｕａｇｅ：ＷＳＤＬ）によりラップされ定義される場合のいずれかの場合、使用される。
【００６６】
２．ＯＤＢＣ／ＲＤＢＭＳコネクタは、次の場合、すなわち第三者システムにモバイルプラットフォームを接続するときに（ａ）この第三者システムがＯＤＢＣ準拠であり、かつ（ｂ）直接ＯＤＢＣ／ＲＤＢＭＳアクセスを許容し、かつ（ｃ）そのデータが同じＬＡＮ環境内に物理的に配置されているか、あるいはその移送を支援する通信プロトコル（ＲＰＣ、ＴＣＰ等）を介してアクセス可能である場合に、使用される。
【００６７】
３．ＡＰＩコネクタは、ウェブサービスコネクタに類似しているが、（ａ）ＲＰＣ等の非インターネットプロトコルを介してアクセス可能であるＡＰＩを必要とし、かつ（ｂ）ウェブサービスインターフェースが利用可能でない場合に使用される。
【００６８】
ＯＤＢＣ／ＲＤＢＭＳコネクタを介しスキーマ情報を読込むことは、アドミニストレータアプリケーションを使用しモバイル企業プラットフォームのスタジオ（Ｓｔｕｄｉｏ）部１３０（図１）を使用することにより達成される。スタジオ部は、バックエンドデータソースへのビュー定義マッピングを構成するとともに一つ又は複数のビューの定義を一つ又は複数のビジネスオブジェクトにマッピングするために使用される。アドミニストレータを使用することによりビュー定義を定義するか、あるいはビューをビジネスオブジェクトにマッピングする際、この情報はメタデータとして格納される。アプリケーションサーバと企業データソースによる更新処理中、このメタデータは、データ（選択／挿入／更新／削除機能）をどのように読込み、保持し、除去するかを確定するとともにコンフリクト検出／解決、トランザクション（両者ともに固有のもの）、そして適切ならば補正などの機能を使用することによりデータの完全性を管理し実施するために読込まれる。
【００６９】
ＯＤＢＣ／ＲＤＢＭＳコネクタを使用することにより、データは、ＡＮＳＩ  ＳＱＬステートメント、及び／又はマイクロソフト社のＳＱＬサーバ又はオラクル社のＲＤＢＭＳ（８ｉ、９ｉ等）の場合はストアドプロシージャを介して読込まれ、保持され、及び／又は除去される。ウェブサービス／ＡＰＩコネクタを使用することにより、データは、適切なＡＰＩ機能又はトランザクション方法を呼び出すことにより読込まれ、保持及び／又は除去される。
【００７０】
２．コンフィギュレーションウェブサービス
デクステラ  スタジオにより使用されるコンフィギュレーションウェブサービスは、デクステラモバイル企業ソリューション（Ｄｅｘｔｅｒｒａ  Ｍｏｂｉｌｅ  Ｅｎｔｅｒｐｒｉｓｅ  ｓｏｌｕｔｉｏｎ）を実施し、構成し、管理する管理者、ビジネスアナリスト、及び開発者に対し簡単で相互運用可能な方法を提供する。コンフィギュレーションウェブサービスは、モバイルアプリケーションのデータ及びプロセス定義を構成しカスタマイズするために使用されるメタデータの簡単な操作を可能にする。このサービスは、以下にさらに詳細に説明されるアドミニストレータコンポーネントの特徴を参照することにより一層理解されるであろう。
【００７１】
３．データマネージャウェブサービス
更新処理モデル
更新処理モデルは、簡単な相互運用性のウェブサービスとして公開された一組のコアネットコンポーネントを使用するバックエンド企業データベースによりローカルに保持されたデータ（アプリケーション又はそのビジネスオブジェクトのいずれか）を、モバイルアプリケーションが更新するシステムにおいて利用される。
【００７２】
データマネージャウェブサービスは、モバイルアプリケーションと、その関連ビジネスオブジェクトで定義されたデータすべてを更新する。更新処理モデルは、デクステラアプリケーションサーバを介した企業データソースとモバイルクライアント間の双方向データ転送を可能にし、これによりモバイルクライアントがネットワークに接続中に更新が行われるようにし、両者が接続される際にクライアント同士間で更新をマージする。非接続状態時は、接続状態が達成され更新要求が開始可能となるまで更新はクライアント環境において管理される。
【００７３】
更新処理モデルは「オールオアナッシング（ａｌｌ  ｏｒ  ｎｏｔｈｉｎｇ）」の手法を取る。全ストリームがアプリケーションサーバからモバイルクライアントへダウンロードされる前に（あるいは全ストリームがクライアントからサーバへアップロードされる前に）故障が発生した場合、アプリケーションサーバ上のデータマネージャウェブサービスはダウンロードトランザクション（又はアップロード）に関する確認を受付けない。この結果、サーバは、それがデータのロールバックを必要とするか、又は単に再試行を必要とするかに関し、クライアント状態を管理するための情報を運ぶ。モバイルクライアントが２回目の更新処理操作を行う際、アプリケーションサーバは元の情報状態を考慮し、そしてアプリケーションサーバが処理を完了した場合、アプリケーションサーバはその結果を提供してよい、あるいはアプリケーションサーバがすべての必要情報を決して受信していなく、従って信頼できる情報配送を一回、かつモバイルクライアントとアプリケーションサーバとの間で一回のみ実施する場合、アプリケーションサーバは再度処理を行ってよい。データがモバイルクライアントから一つ又は複数のバックエンドデータソースへ移動する際、念のためデータの保全を実施する。
【００７４】
更新処理の詳細
２つのタイプの更新処理がサポートされる。
【００７５】
１：最新版を入手：この更新タイプでは、モバイルクライアントは、デクステラアプリケーションサーバを介して企業データソースから最新情報を入手するための要求を行う。デクステラアプリケーションサーバはこの要求を処理し、デクステラコネクタウェブサービスを使用することにより複数のデータソースからビジネス情報を検索し、このビジネス情報をモバイルクライアントに送る。
【００７６】
２：更新（双方向更新）：この更新タイプでは、クライアントとサーバエンドの両方の側の記録は、モバイルクライアントと、デクステラコンフリクトレゾリューション（Ｄｅｘｔｅｒｒａ  Ｃｏｎｆｌｉｃｔ  Ｒｅｓｏｌｕｔｉｏｎ）で構成されたパラメータを使用するバックエンド企業データソースと、の両方の側でデータの保全を実施することにより交換される。
【００７７】
コンフリクト検出／解決
コンフリクト解決は、モバイルクライアントと一つ又は複数のバックエンド企業データソースとの間でなされた変更に起因するデータコンフリクトに関するに調停に使用される規則を記述する。これは、最初にコンフリクトを識別し（検知）、次に一つ又は複数の様々な方法でコンフリクトを解決することにより実行される。
【００７８】
デクステラアプリケーションサーバは次の３つの方法、すなわち、版数、日時スタンプ、又は手動のうちの一つの方法で検出できるだけでなく、行又は列レベルによりコンフリクト状況を識別できる。
【００７９】
版数は、改版された単一レコードソース内の特定フィールド又はプロパティが識別される設定であり、デクステラアプリケーションサーバはこれを使用することによりバックエンドデータソース又はモバイルクライアントのいずれかでデータが変更されたかどうかを判断する。
【００８０】
日時スタンプ
日時スタンプは、特定フィールド又はプロパティが日時スタンプとして単一レコードソース内で識別され、何らかの挿入／更新又は削除があると更新される設定であり、デクステラアプリケーションサーバはこれを使用することにより、バックエンドデータソース又はモバイルクライアントのいずれかでデータが変更されたかどうかを判断する。
【００８１】
マニュアルは、単一レコードソース内にコンフリクト状況を識別するための特定フィールド又はプロパティがない設定であり、従ってデクステラアプリケーションサーバはすべてのフィールド又はプロパティデータを比較して一意性を定義し、バックエンドデータソース又はモバイルクライアントのいずれかでデータが変更されたかどうかを検知する。
【００８２】
デクステラアプリケーションサーバの構成に依存して、コンフリクトは次の４つの方法、すなわち最初の更新が勝つ、最後の更新が勝つ、アドミニストレータ解決、サーバ側規則のうちの一つの方法で解決される。
【００８３】
最初の更新が勝つ
最初の更新が勝つモデルでは、アプリケーションサーバは、更新を行う最初のものである任意のレコードの変更を受理するのみである。記録がバックエンドデータソースにより最初に更新され、そしてコンフリクトが更新ウェブサービスにより検知された場合、エラーを戻す代わりに、データマネージャウェブサービスはクライアントにより提供されたバージョンをやめて、このレコードの最新バージョンの複製をバックエンド企業データソースからモバイルクライアントに戻す。
【００８４】
最後の更新が勝つ
最後の更新が勝つモデルではサーバはコンフリクトを検知する必要はない。その代り、サーバはバックエンド企業データソース内の現在の記録に上書きすることにより、モバイルクライアントからバックエンド企業データソースへの変更を単に保持する。
【００８５】
アドミニストレータ（又はマニュアル）解決
アドミニストレータ／マニュアル解決として構成された場合、サーバは、すべてのコンフリクトを、解決すべきマニュアル介入を必要とするものとして処理し、バックエンド企業データソースから現在の記録の複製を戻し、そして随意に、コンフリクト状況が発生した旨を任意の通知サービス（ＳＭＳ、Ｅｍａｉ等）を介して通知し、デクステラアドミニストレータを介し解決することができる。このアドミニストレータが選択的にバックエンド企業データソースに再適用すべき値を判断するので、このようにすることによりコラムレベルのコンフリクト解決が可能となる。
【００８６】
サーバ側規則
カスタマイズ可能なサーバ側規則は、あるコンフリクト状況をどのように解決すべきかをよりプログラマブルにかつ具体的に判断するために作成することができる。例えば、コンフリクトは記録内のデータの値に基づいて解決されてよい。この柔軟性により、コンフリクト解決シナリオを取り巻く具体的なアクション全体の完全な制御が可能となる。
【００８７】
サーバからのクライアント展開
アプリケーションサーバはモバイルクライアントにダウンロードされる一つ又は複数のモバイルフィールドアプリケーションの定義を含み、これはビジネスプロセス／ワークフロー内に構築されるタスク（「フォームフロー（ＦｏｒｍＦｌｏｗｓ）」と呼ばれる）、データ対話処理（「フィールドフロー（ＦｉｅｌｄＦｌｏｗ）」と呼ばれる）、フォームフローとフィールドフローのグループ（「フォースフロー（ＦｏｒｃｅＦｌｏｗ）」と呼ばれる）として表されるフォーム／画面を含む。フォームフロー、フィールドフロー、フォースフローについては以下にさらに説明される。アプリケーション定義は、また、ビュー、ビジネスオブジェクト、ビジネス定数定義のようなアプリケーションに関連する構成済みメタデータを含む。また展開の際に含まれるのは、「時々の」接続状態においてモバイルクライアントを走らせるのに必要な一つ又は複数のバックエンド企業データソースからの特定のビジネスデータである。
【００８８】
アプリケーションサーバは、アプリケーションを提供し管理するとともに既存の企業データソース及びシステムに接続するための基盤を提供する。モバイル企業プラットフォームアプリケーションは、アプリケーションサーバにより、ポケットＰＣ、タブレット型ＰＣ装置などの移動体装置に配布され管理され、これによりフィールドにおけるすべてのユーザインターフェースを高度に管理可能とする。
【００８９】
Ｃ．アドミニストレータコンポーネント
上記のように、アドミニストレータコンポーネント（図１）により、システム管理者は比較的通常の又は頻繁な変更を行うことができる。アドミニストレータコンポーネントは、ビジネスアナリスト又は管理者が管理するための適切なフォーマットで、判断変数、ドロップダウン式リストコンテンツ、その他情報へのアクセスを提供する。この管理の手法により、システム管理者はシステム完全性を妥協することなく、多くの機能をアドミニストレータレベルまで拡張できるようになる。
【００９０】
例えば、企業のビジネスプロセスを定義するために使用されるビジネス情報から成るデータは、ビジネスオブジェクト定義フォームを介して受信することができる。コンフィギュレーションウェブサービスは、アドミニストレータコンポーネントのこの様相へのアクセスを提供する。
【００９１】
Ｄ．クライアントコンポーネント
上記のように、企業プラットフォームアーキテクチャにおけるクライアント１０２は、モバイルアプリケーションが「フォースフロー」、「フィールドフロー」、「フォームフロー」と呼ばれる技術を使用するとともにウェブサービスを使用する役割ベースのビジネスプロセスの使用を可能にするフレームワークを提供し、従って有線及び無線接続を介した、モバイルクライアントと、デクステラアプリケーションサーバと、インターネットなどのＬＡＮ／ＷＡＮネットワーク上の企業データソースとの間の通信が可能となる。クライアントデバイス上で走るモバイルアプリケーションは、ユーザ体験を習得するのがことの他容易な小型装置に対し最適化されたやり方で機能する。
【００９２】
例示されたシステムでは、クライアントは、メタデータを考慮するマイクロソフト社の「．ＮＥＴコンパクトフレームワーク」を利用して構築されるオブジェクトフレームワークである。クライアントコンポーネントは、好ましくはマイクロソフト社の「ポケットＰＣ」オペレーティングシステム又はマイクロソフトタブレットＰＣオペレーティングシステムに従って動作する企業向けアプリケーション機能の移動体装置上への配送を可能にする。クライアントコンポーネントは、また、ポケットＰＣインターフェースのカレンダー、タスク、トゥデイスクリーン（Ｔｏｄａｙ  ｓｃｒｅｅｎ）機能とのシームレス統合を提供するために、既存の「ポケットＰＣ」機能と一体化する。これによりクライアントコンポーネントは、作業するための安定した効果的な環境を提供する。
【００９３】
フォームフロー、フィールドフロー、フォースフロー
表示画面形式のすべてのビジネスプロセスタスク、すべての工程、又はすべての操作は、「フォームフロー」と呼ばれる。フォームフローは、「フォースフロー」と呼ばれるビジネスプロセスの開始を許可する「フィールドフロー」と呼ばれるプロセス対話処理を開始するために使用される。フィールドフローは、実世界の融通性をビジネスプロセスにもたらすために「帯域外（ｏｕｔ  ｏｆ  ｂａｎｄ）」フォースフローの開始を許可する。
【００９４】
フォームフローは、（１）情報、（２）活動、（３）更新の３つのカテゴリに分解される。情報フォームフローは、ビジネスプロセス内の次の論理タスクを遂行するために、モバイルユーザにより必要とされる情報を示す画面である。活動フォームフローは、ユーザが実行する必要があり得るものを示す画面である。更新フォームフローは、モバイルユーザがホストアプリケーション（企業データソース）に戻されるデータを入力することを指示された際に表示される画面である。
【００９５】
フィールドフローは、例えば、部品が故障したかもしれなく、そして解決法にマッチする部品又は同様の問題が存在しかつ利用可能かどうかを調べるために在庫データベースの探索（照合（ｌｏｏｋｕｐ）と呼ばれる）が実行される必要があり得る場合に必要とされるか、あるいは、クライアントへの配送のために、部品を注文又は割り当て又はスケジューリングする必要があるかもしれない場合に必要とされ得る（更新と呼ばれるフィールドフロー）。
【００９６】
フォースフローはビジネスプロセスであって、従ってフォームフローとフィールドフローの集合である。フォースフローの一例は、仕事又は派遣イベントに関連する時間、出張、費用を記録することであろう。
【００９７】
再度図２を参照すると、このブロック図は、ターゲットアプリケーションにおけるコラムとフィールドとの関係がどのように「フォームフロー」（アプリケーションでは「フォーム」と表示されるビジネスプロセスにおける工程）における情報に関係するか、そして次にフォースフロー（ビジネスプロセス）に関係するかを示す。すべてのビジネスプロセスでは、一つのフォームフローそして可能性として二つ以上のフォームフローにおいて多くのビジネスオブジェクトが存在し得る。
【００９８】
フィルタは、モバイルアプリケーションにおいて参照されると、特性と条件がデータに付加されるようにする。例えば、データタイプ（例えば、日付）、有効なタイプ（例えば月曜から金曜までのみ）、任意のコンフリクト条件が検知されてもよい。他のフィルタ特性及び条件が構成されてもよい。
【００９９】
ビューは一つ又は複数のビジネスオブジェクトで使用されるデータと記憶場所を定義し、ビジネスオブジェクトは一つ又は複数のビューに基づいてよい。これにより、追加の特性を関連付けることができる。例えば、ビジネスオブジェクトは「顧客」と呼ばれ、「顧客」は、標準的な顧客詳細である場所、接触、在庫、そしてまたアプリケーションが顧客として分類したいが同じターゲットテーブル又はターゲットアプリケーション内に保持したくないＳＬＡ及び他の属性を含んでよい。
【０１００】
Ｖ．アダプタアーキテクチャ
本発明によるアダプタアーキテクチャは図４に例示される。図４に例示されたコンポーネントのいくつかは図１に例示されたコンポーネントに類似している。図１のシステムに提供された対応するコンポーネントの機能を実行する図４におけるコンポーネントは、「１」ではなく「４」で始まることを除いて図４では同じ参照符号により識別される。
【０１０１】
図４は、本発明により構築された、好適なコンピュータシステム環境４００のブロック図である。図４は、マイクロソフトポケットＰＣ又はパームＰＤＡオペレーティングシステムと共に動作する個人用デジタル情報処理端末（ＰＤＡ）装置のようなモバイルクライアントデバイス４０２を示す。クライアントデバイス４０２は図１のクライアントデバイス１０２に関連して説明されたのと同じコンポーネントを含むが、図解の単純化のために図４では例示されない。サーバからデータを要求し、データ更新を受信し、新しいデータを提供し、構成変更を受信するために、モバイルクライアントデバイス４０２は、ネットワーク接続４０４上でアプリケーションサーバ４０６と通信を行う。複数のモバイルクライアント４０２がサーバ４０６と通信を行うことができることを理解すべきである。図の簡潔性のため、図４では単一のクライアントデバイス４０２のみが示される。
【０１０２】
モバイルクライアント４０２は、複数の企業データ記憶装置からのリアルタイムデータ検索のためにサーバ側コネクタウェブサービスを使用する。さらに、モバイルクライアントは、リアルタイムのクライアント側データ更新、サーバ側データ更新、システム構成更新の管理のためにサーバ側データマネージャウェブサービスを使用する。
【０１０３】
アプリケーションサーバ４０６は、ＣＲＭデータソース、ＥＲＰソース、財務システム資源、レガシーデータ記憶装置等の企業データソース４０８と通信を行う。
【０１０４】
「デクステラ  スタジオ」コンポーネント４３０はサーバ４０６と通信を行い、管理者アプリケーションと開発者アプリケーション（図４では図示せず）を含む。特に、スタジオ（Ｓｔｕｄｉｏ）コンポーネントはサーバ４０６のコンフィギュレータとインターフェースし、データサーバＤＤＳは、サーバとサーバ４０６のアダプタフレームワークとインターフェースし、このアダプタフレームワークは企業データソース４０８と通信を行う。
【０１０５】
アダプタフレームワークは、サーバ４０６と他の任意の企業データソースとの間のデータを移動させる際に必要とされる特定の入力と出力を実行するインターフェースを提供する。サーバ４０６のデータマネージャは、アダプタフレームワークを介して企業データソース４０８と通信を行うために、すべての適切に定義されたコネクタコンポーネントに対し要求し応答する。こうして、サーバ４０６は接続オブジェクト、コマンドオブジェクト、データオブジェクト、ビューの定義を使用して、どのようにして、どのデータを検索又はバックエンド企業データソースに保持するかを判断する。
【０１０６】
開発者がアダプタフレームワークのコンポーネントを指定できるように、設計ツールキット（「デクステラアダプタデザイナー」又はＤＡＤ）はスタジオ（Ｓｔｕｄｉｏ）４３０を備える。すなわち、ＤＡＤ４３０は、開発者に、デクステラ  スタジオ  ブイエス  ネット（Ｄｅｘｔｅｒｒａ  Ｓｔｕｄｉｏ  ＶＳ．ＮＥＴ）を利用する任意のデクステラ支援アダプタ（デクステラ  Ｓｕｐｐｏｒｔｅｄ  Ａｄａｐｔｅｒ）にアダプタフレームワークデータコンポーネントを接続し構築する手段を与える。コンポーネントとしては、接続オブジェクト、コマンドオブジェクト、データオブジェクト、ビューが挙げられる。
【０１０７】
ＤＡＤ４３０を使用し、開発者は、デクステラ支援アダプタを使用することによりバックエンドデータソースに対する接続オブジェクトを作成する。この接続オブジェクトは、テーブル、ストアドプロシージャ、スクリプト、又はオブジェクト（ＥＡＩ等）のいずれかとしてアダプタを介し利用可能なデータインターフェースオブジェクトを公開する（発見／内部観測（Ｉｎｔｒａｓｐｅｃｔｉｏｎ）又は説明のいずれかを使用することにより）。次に、デクステラアダプタデザイナーを使用し、開発者は、選択、挿入、更新、及び／又は削除などのアダプタを介した特定のアクションを実行する一連のコマンドオブジェクトを作成する。次に、開発者はデータオブジェクトを定義し、そこで適切な選択コマンド、挿入コマンド、更新コマンド、及び／又は削除コマンドを選択する。次に、ビューは、その要求／応答アクションに対するデータオブジェクトに結合される。このツールとアーキテクチャを使用することにより、開発者は、デクステラサーバ４０６内の単独に定義されたデータオブジェクトにマッピングされた一つ又は複数のバックエンド企業データソースからデータを要求し保持し、こうしてアブストラクション層を物理データ構造に与え、インターフェース能力を与えることができる。
【０１０８】
Ａ．コマンドオブジェクト
アダプタフレームワークのコマンドオブジェクトは、データを検索又は保持するために、アダプタ（すなわちコネクタ）を介して実行されるアクションを定義する。例えば、アダプタを介して企業データソースへ顧客データオブジェクトを保存するために「顧客保存（ＳａｖｅＣｕｓｔｏｍｅｒ）」コマンドを定義することができる。コマンドタイプ又はコマンドフォーマットは、それらがインターフェースし、従って支援しなければならない企業データソースに応じてアダプタにより確定される。例えば、モバイルデータシステムに対して可能なコマンドタイプとしては、テーブル、手順、ＳＱＬ、スクリプト、オブジェクトが挙げられよう。
【０１０９】
コマンドオブジェクトは、実行されるアクションを指定する。本発明によると、コマンドアクションタイプは次の５つの定義済みアクションを含む。（１）読込、（２）追加、（３）更新、（４）削除、（５）編集読込（ＲＥＡＤ  ｆｏｒ  ＥＤＩＴ）。これらのコマンドアクションは、データオブジェクトの議論に関連し以下にさらに説明される。コマンドオブジェクトは、コマンドが実行されると動作することになるフィルタを指定することができる。各フィルタは、対応するコマンドタイプのデータタイプに従ってデータに作用する。コマンドは、コマンドが実行されると戻されるコラムデータから成るコラム属性を含む。最後に、コマンドは、コマンドの適切な実行のために必要な値を指定するパラメータを含む。
【０１１０】
Ｂ．データオブジェクト
データオブジェクトはデータを検索又は保持するためにコマンドオブジェクトを関連付け、それらを単独のオブジェクト（例えば顧客オブジェクト）に論理的にグループ化する。データオブジェクトは、アダプタを介して企業データソース上で実行されるコマンドにより（すなわち、コマンドの結果として）定義される。上記のように、コマンドは読込、追加、更新、削除、編集読込を含む。読込コマンドは、データを検索し、どのデータコラムが戻されるか、それらの属性は何かを定義するコマンドオブジェクトであり、アダプタから「．ＮＥＴ」パラダイムへキャスティングするデータタイプを上書きする。追加コマンドは、新しいデータインスタンスを元の対応する企業データソースに挿入するために、アダプタを介してデータの新しいインスタンスを保持するコマンドオブジェクトである。更新コマンドは、既存データ要素への変更を、元の対応する企業データソースへアダプタを介して保持するコマンドオブジェクトである。削除コマンドは、アダプタを介して企業データソースからデータを削除するコマンドオブジェクトである。編集読込コマンドは、アダプタを介した行ロック（ＲｏｗＬｏｃｋ）により単一レコードを検索するコマンドオブジェクトである。
【０１１１】
データオブジェクトは、読込コマンドの戻り要素を、追加、更新、削除、編集読込コマンドのパラメータへマッピングする。単一データオブジェクトは、恐らく異なるアダプタへの異なるコマンドを介してデータを検索し保持することができる。
【０１１２】
Ｃ．接続（コネクション）
前と同様に、モバイルクライアントアプリケーションによるデータアクセスを実現するために、接続は企業データソースにインターフェースする。本発明に関連して説明されたアダプタフレームワーク４３０において、接続は、ビューと直接通信を行わないがその代り、コマンドオブジェクトと直接インターフェースし、最終的にデータオブジェクト及びビューとデータを交換する。
【０１１３】
Ｄ．ビュー
図４の構成のサーバ４３０におけるアダプタフレームワークでは、図１の構成の場合と同様に、ビューは単一データテーブルに結合しない。むしろ、ビューは、読込、追加、更新、削除、編集読込に対して定義されたコマンドによりデータオブジェクトに結合される。こうして、さらに汎用性のあるデータインターフェースが提供される。ビューの構造は、データオブジェクトに対する読込コマンド内に指定された、選択されたデータコラムにより定義される。さらに、フィルタは、もはやビューオブジェクトにおいて作成されないが、コマンドオブジェクトにおいて作成される。
【０１１４】
次の節においてさらに説明されるように、図４のシステムのビュータイプは直接ビュー（Ｄｉｒｅｃｔ  Ｖｉｅｗ）、派生ビュー（Ｄｅｒｉｖｅｄ  Ｖｉｅｗ）、代行ビュー（Ｄｅｌｅｇａｔｅｄ  Ｖｉｅｗ）、定義ビュー（Ｄｅｆｉｎｉｔｉｏｎ  Ｖｉｅｗ）を含む。サーバ４３０におけるビューオブジェクトの構成は、企業データソースへのビューＣＲＵＤ（Ｃｒｅａｔｅ（生成）、Ｒｅａｄ（読込）、Ｕｐｄａｔｅ（更新）、Ｄｅｌｅｔｅ（削除））操作の抽出を可能にし、ＣＲＵＤをハードコーディングするのではなく定義できるようにする。
【０１１５】
ＶＩ．ビュータイプ
上記のように、モバイルクライアントは、コマンドによって定義されたデータオブジェクトを介してデータソースとインターフェースする構成可能なビューを介し企業データソースへアクセスし、これによりコネクタ（アダプタとも呼ばれる）を介してデータソースと通信を行う。各タイプのビューは、通信リンクと他のシステム資源がより効率的に使用されるように、異なる機能を有するデータソースへインターフェースする。
【０１１６】
図４に例示されたシステムでは、ビュータイプは、直接ビュー、派生ビュー、代行ビュー、定義ビューを含む。以下にさらに説明されるように、これら新規のビュータイプは、データインターフェース上で優れた制御を行うことができ、またシステム資源の一層の利用のために構成することができる。
【０１１７】
Ａ．直接ビュー
直接ビューは、データオブジェクト、コマンド、アダプタを介し企業データソースからデータを直接検索する。直接ビューはモバイルクライアントのみのために定義されるタイプのビューである。ほとんどのビュータイプは、ＳＱＬＣＥと呼ばれるローカルのクライアントリレーショナルデータ記憶装置（キャッシュ）に頼ることにより、要求されたデータを検索する。対照的に、直接ビュータイプは、ローカルの顧客データ格納キャッシュへ行く代わりに企業データソースから直接データを要求する。企業データソースへの接続が失敗した場合、図４のシステムは、企業データソースが利用可能でない場合、ＳＱＬＣＥからのデータを検索することができるオプションのフェイルオーバー（ＦａｉｌＯｖｅｒ）操作を提供する。これは、リアルタイムにどのデータ（在庫データなど）が必要かと比べ、どのデータがローカルに保持されるかに関する制御が構成可能であるモバイルアプリケーションのクライアント／サーバのような操作を可能にする。
【０１１８】
システム（図１）に対するモバイルアプリケーションが計画され設計されると、アプリケーション開発者は、直接ビューとなるビュー（データオブジェクトの点から定義された）を選択することができる。このような設計判断は、「デクステラ統合開発環境ツール」又は「デクステラアダプタデザイナー」（ＤＡＤ）ツールと呼ばれるシステム開発ツールを介して指定することができる。通常、モバイルクライアントによる直接ビューの使用は、クライアント変数がバックエンドデータソースから戻された結果をユーザ固有となるように制限するビューフィルタ条件の一部として実行するのが最もよい。
【０１１９】
アプリケーションがモバイルクライアント上で実行されているとき、モバイルクライアントは、「ビジネスオブジェクト要求」（ＦｉｎｄＳｅｔ操作と呼ばれる）の間にビューからデータを要求することになる。モバイルクライアントは、ビューが直接ビューであることを理解するので、データマネージャを使用してビューフィルタ用の任意の環境変数又はユーザ定義変数を渡すことにより、デクステラサーバに対しビューのデータ要求を直接行なう。データマネージャは、バックエンド企業データソースからビュー用のデータ（デフォルト、派生、又は代行ビュータイプの）を検索し、このデータをクライアントに戻し、次にデータ検索の結果をビジネスオブジェクトに戻す。
【０１２０】
Ｂ．派生ビュー
派生ビューは、システムのデータサーバ内の一つ又は複数の定義済みビューからデータの定義を導出（抽出）する能力を提供する。これにより、ビューとして事前定義された一つ又は複数のデータ構造に基づいてデータ項目を定義することができる。派生ビューはフィルタパラメータを組み込み、そしてサーバからデータを要求する。サーバは実行時に企業データソースから対応データの基本セットを検索し、次に検索されたデータをリレーショナルデータエンジン（ＲＤＥ）内に置く。リレーショナルデータエンジンは派生ビューフィルタパラメータを適用し、フィルタリングされたデータを抽出し、要求する派生ビュータイプにこの抽出されたデータを提供する。従って、派生ビューは、一般的なＡＮＳＩ  ＳＱＬ操作を使用することにより、異なる企業データソース（ジーベル、オラクル等）の一つ又は複数の他のビューからのデータをフィルタにかけることができ、こうしてＳＱＬサーバ又はオラクルなどのリレーショナルエンジンの能力を利用する。
【０１２１】
派生ビューはシステムメタデータ内に定義される。派生ビューは、派生ビューの構造をテーブル又は定義済みオブジェクトとして事前に定義するのではなく派生ビューのデータ抽出を可能にするデクステラサーバ（ステートレスである）内に実行時に構築され、こうして企業内の変化に対する真の柔軟性を与える。
【０１２２】
デクステラ統合開発環境ツールを使用することにより、開発者は、最初に一つ又は複数の基本ビュータイプ（デフォルト、代行、又は定義ビュー）を作成し、そしてフィルタ条件、許可等を設定する。デフォルトタイプは、所望に応じ、残りのビュータイプの一つとなるように設定されてよい。基本ビューが作成された後、一つ又は複数のビューを選択し、マッピングすべきビューの属性（フィールド等）と基本ビューから戻されるデータに適用すべきフィルタ条件とを定義することにより派生ビューを作成することができる。
【０１２３】
実行時、デクステラサーバは、最初に派生ビューの基本ビューからデータを検索することにより、派生ビュー要求に応答し、次に検索されたデータをＳＱＬサーバ又はオラクルなどのリレーショナルエンジンに入れ、次に、データに対し派生ビューフィルタ条件（ＳＱＬとして）を適用し、比較のため、及びモバイルクライアントへの配送の準備のために配送用のデータをデータマネージャへ戻す。
【０１２４】
図５に派生ビューを例示する。図５は「Ｖ１」ビューと「Ｖ２」ビューに基づく派生ビュー（図５では「Ｖ３」として示す）を備えたシステム５０２の動作を例示する。ここではＶ１ビューがジーベルデータベース５０４から顧客データを検索し、Ｖ２ビューがジーベルデータベースから履歴データを検索するようになっている。Ｖ３ビューは検索用履歴データのサブセットのみを指定するが、これはＶ３のフィルタ条件を通して実現される。次に、データサブセットはモバイルクライアント５０６に戻される。Ｖ２ビューは、注文履歴のサブセットのみがＶ２ビューにより呼び出されるという点で、定義ビュータイプである。参照データ記憶装置５０８は、指定されたデータを検索可能なメタデータを含むが、注文履歴の生データを含まない。従って、興味のあるデータのみがデータベースから実際に引き出され、派生ビューＶ３に送信されるので、データベース５０４から検索され通信リンク上で戻されなければならないデータは削減される。
【０１２５】
Ｃ．代行ビュー
代行ビューは、デクステラサーバ上の一つ又は複数のバックエンド企業データソースからのデータを代行する又はキャッシュに格納するとともに、タイマー間隔（毎時になど）又は所定のイベント（サーバ側規則トリガーと呼ばれる）などの既定の一組の規則に基づいてこのキャッシュを検索し更新するデクステラサーバを構成する能力を提供する。こうして、代行ビューは、代行ビューのパラメータに従って定期的に企業データソースからデータを検索し、検索されたデータをリレーショナルデータエンジンキャッシュに入れる。
【０１２６】
デクステラ統合開発環境ツールを使用することにより、開発者は、テーブル、オブジェクト、ストアドプロシージャ、スクリプト等の特定のアダプタ支援オブジェクトタイプ（Ａｄａｐｔｅｒ−ｓｕｐｐｏｒｔｅｄ  ｏｂｊｅｃｔ  ｔｙｐｅ）に基づいてビューを作成する。次に、開発者はフィルタ条件、許可、関連オブジェクトパラメータを構成し、次にビューを代行ビューとしてマーキングし、フィルタ時間間隔、イベント規則などのフィルタの更新機能を構成する。その後、実行時に、デクステラサーバのデータマネージャは、設定時間間隔又はサーバ側イベント時に、定義済みアダプタからビュー用のデータを自動的に要求し、このデータをローカルＲＤＥにおけるキャッシュに格納する。
【０１２７】
モバイルクライアントの要求に応じ、デクステラサーバのデータマネージャは、ビューにより定義されたデータを、企業データソースに接続されたアダプタから要求するのではなくローカルＲＤＥからこのデータを検索する。フィルタ条件をローカルＲＤＥソースに適用することができ、これにより要求の性能を増すとともに一組の定義済みデータ用の従属バックエンドデータソースの領域を解放する。
【０１２８】
こうして、サーバが規定の更新機能に基づいて自動データ検索を実行した後、企業データを求めるその後のモバイルクライアントからの要求は、要求されたデータを企業データソースから直接ではなくＲＤＥキャッシュから入手することにより満足させることができ、これによりモバイルクライアントとデータソース間のデータトラフィックを低減させる。モバイルクライアントからの更新データは、アダプタを介して企業データソースに直接戻される。
【０１２９】
Ｄ．定義ビュー
定義ビューは、企業内にデータを検索又は保持すべきバックエンドデータ記憶装置が存在しない状況において、ユーザ定義ビューを作成する能力を提供する。この能力は、通常、企業システムの一部ではない移動体割り込み時に必要とされる機能に対し、バックエンドシステムを増強するために使用されてよい。別の使用法は、企業が、バックエンド企業システムを修正することなくモバイルアプリケーションからのデータをバックエンド企業データソース内のデータに関連付けることを可能にすることかもしれない。ユーザ定義ビュー（定義ビュー）は、「サーバのみ（ＳｅｒｖｅｒＯｎｌｙ）」又は「クライアントのみ（ＣｌｉｅｎｔＯｎｌｙ）」の選択肢を有することになる。ＳｅｒｖｅｒＯｎｌｙ選択肢は、バックエンドデータ処理を増強する目的で、データを格納するために使用することができるが、モバイルアプリケーションに対しては必要ない。ＣｌｉｅｎｔＯｎｌｙ選択肢は、ピックリスト、定数、列挙子などモバイルアプリケーションにおいて使用される追加データ要素を格納するために使用することができる。
【０１３０】
定義ビューは、検索されたデータがどこで維持されるか、システムサーバ側か又はモバイルクライアント側かに関する制御を許容する。通常、システム資源の量が２つの構成間の選択を決定する。
【０１３１】
定義ビューを利用するために、開発者はデクステラ統合開発環境ツールを使用し、ビジネスデータを格納するデータ構造（フィールド名、データタイプ、デフォルト値を含む）を定義することによりビューを作成する。次に、開発者は、アクセスを制御するために設定された許可だけでなくフィルタも作成することができる。移動体装置上にビュー定義を作成しないであろうＳｅｒｖｅｒＯｎｌｙ選択肢を選択してもよい。ＳｅｒｖｅｒＯｎｌｙ定義は、派生ビュー等の他の操作用の作業者ビューであろう。ＣｌｉｅｎｔＯｎｌｙ定義は、クライアントデバイス上のみにビューを作成するであろう。この選択肢が選択された場合、ユーザは種データを手動で入力し、範囲を区切られたソース又はＸＭＬファイルからデータをインポートし、このデータをＸＭＬファイルにエクスポートするであろう。
【０１３２】
デクステラサーバは、そのバックエンドデータソースとしてＲＤＥ内の定義ビュー構造を使用する。ＳｅｒｖｅｒＯｎｌｙ選択肢の場合には、ビュー定義はモバイルクライアントデータキャッシュ（ＳＱＬＣＥ）上に作成されない。デフォルト又はＣｌｉｅｎｔＯｎｌｙ選択肢の場合には、ビュー定義はローカルのクライアントキャッシュ（ＳＱＬＣＥ）内にテーブルとして作成される。ＣｌｉｅｎｔＯｎｌｙの場合、ビュー定義はサーバ上に構成された（ユーザが入力又はインポートした）データによりシードされる。
【０１３３】
Ｅ．リレーショナルデータエンジン
構成可能なビューと併せて、システムは、また、サーバ４０６のフレームワーク内にリレーショナルデータエンジン（ＲＤＥ）を含む（図４参照）。あるいは、ＲＤＥは、サーバと通信を行うことができるプラットフォームシステムの他のコンピュータに配置されてもよいであろう。ＲＤＥは、一つ又は複数のバックエンド企業データソース４０８から一つ又は複数のモバイルクライアントデバイス４０２までのデータのリアルタイム通信において、ＡＮＳＩ  ＳＱＬなどの標準シンタックスをステートレスなやり方で使用する。上述のように、ＲＤＥは派生ビュー、代行ビュー、定義ビューに対し有用であり、複雑なフィルタ条件、モバイルクライアントのステートモデル化、顧客データの比較等のために利用される。すなわち、上記のように、ＲＤＥは特定のビュータイプに従って利用される。
【０１３４】
デクステラサーバが一つ又は複数のバックエンド企業データソースから一つ又は複数のモバイルクライアントにデータを移動させる際、デクステラサーバは、データの定義へマッピングするデータモデルの静的な定義を必要とすることなく、リアルタイムでデータを格納するためにＲＤＥの能力を利用する。ＲＤＥは、フィルタ条件におけるデータの相関又はデータ抽出を促進するＡＮＳＩ  ＳＱＬなどの標準的用法シンタックスの能力を活用するために使用される。
【０１３５】
Ｆ．メタデータビジネスオブジェクト
構成可能なビューとＲＤＥを利用するために、本システムは、デクステラ  スタジオ  ＶＳ．ＮＥＴプラグインを利用する一つ又は複数のモバイルクライアントアプリケーションにより使用可能な一つ又は複数のバックエンド企業データソースから一つ又は複数のビューに結合されるメタデータ内にビジネスオブジェクトを作成し定義する能力を提供するメタデータビジネスオブジェクトを利用する。これは、デクステラ  スタジオ  ＶＳ．ＮＥＴプラグインを利用する真のオブジェクト指向アプリケーションコンポーネントアーキテクチャに対し、一つ又は複数の他のビジネスオブジェクトとの関係を作成する能力を提供する。
【０１３６】
ＲＤＥの使用は、プロパティ、デフォルト値、関係、フィルタ条件、許可、関連アプリケーション、ビジネスルールを含むビジネスオブジェクトの定義を構成するデクステラ統合開発環境ツールを使用することにより実施される。実行時にビジネスオブジェクトから要求があると、モバイルクライアントはメタデータ定義に基づいてオブジェクトインスタンスを作成する。これにより、クライアントアプリケーションは、次に、検出（Ｆｉｎｄ）、ＦｉｎｄＳｅｔ、保存、削除などの操作を行うことができる。モバイルクライアントは、ビジネスオブジェクト用の定義済みビューの属性に対し、これらの操作を行う。これにより、例えば、ローカル装置上のデータを検索又は更新することができる。
【０１３７】
ＶＩＩ．構成とユーザインターフェース
図４の構成のサーバ４３０のアダプタフレームワークでは、本発明を有しないシステムにおける場合にそうであるように（そして図２に示すように）、ビューは単一データテーブルに結合されていない。むしろ、ビューは、読込、追加、更新、削除、編集読込に対して定義されたコマンドを有するデータオブジェクトに結合される。こうして、さらに汎用性のあるデータインターフェースが提供される。ビューの構造は、データオブジェクトの読込コマンド内に指定された、選択データコラムにより定義される。
【０１３８】
本発明のビューオブジェクト構成を利用するシステムでは、ビューオブジェクトにおいてではなくコマンドオブジェクトにおいてフィルタが生成される。サーバ４３０におけるビューオブジェクトの構成は、企業データソースへのビューＣＲＵＤ（生成、読込、更新、削除）操作の抽出を可能にし、ＣＲＵＤがハードコーディングされるのではなく定義されるのを可能にする。フィルタの生成等のために変更されるビュー構成と、付随する変更以外に、図１に例示された残りのコンポーネントは、本発明に従って構築されたモバイルプラットフォームシステムのために利用することができる。
【０１３９】
図６は、図１に例示された、本発明の実施形態を含むモバイルプラットフォームのためのデータアーキテクチャの線図的表現を示す。図６は、データシステムのビューオブジェクトがビューＩＤを有し、定義済みデータオブジェクトに結合されることを示す。図６は、データオブジェクトが読込コマンド、追加コマンド、更新コマンド、削除コマンド、編集読込コマンドの内の一つ又は複数のコマンドを含むことができることを示す。
【０１４０】
図６は、コマンドオブジェクトもまたデータオブジェクトに結合され、そしてまた接続オブジェクトに結合され、この接続オブジェクトは次にアダプタオブジェクトに結合されることを示す。図６は、上述のように、モバイルプラットフォームのためのデータを検索するために、アダプタオブジェクトが、企業データソースとインターフェースするメタデータ記憶装置とインターフェースすることを示す。
【０１４１】
図７は、本発明により構築されたモバイルプラットフォームのためのデータアクセス構成の線図的表現である。図７は、モバイルクライアント（図７では「デクステラクライアント」として示す）が、サーバにおけるビューオブジェクトを介してアプリケーションサーバ（図７の「デクステラサーバ」）と通信を行うことを示す。ここで、ビューオブジェクトは、企業データ記憶装置（例えば、図７では、マイクロソフトＳＱＬサーバとジーベルデータサーバ）と最終的に直接インターフェースするアダプタオブジェクトにアクセスするコマンドオブジェクトを介して作用するデータオブジェクトとインターフェースする。クライアントデバイスにおいて、モバイルアプリケーションは、データ要求を、スマートクライアントを介してメタデータ記憶装置及びビジネスデータ記憶装置へ、そしてアプリケーションサーバにおけるビューオブジェクトへ伝達する。
【０１４２】
図８は、モバイルプラットフォームシステムのＤＡＤ機能へのアクセスがファイルエクスプローラタイプのグラフィカルユーザインターフェースを介してどのように獲得されるかを示す。図８は、ＤＡＤコンピュータープログラムアプリケーションをホストするコンピュータ装置上の表示のスクリーンショットである。図８において、表示画面は「デクステラエクスプローラ」というタイトルのウィンドウタイプの表示であり、ファイルツリー表示を有する作業スペースを示す。ツリー表示は、ソロモン、テンペスト、アルトリム、サンダーと表示されたサーバ名を有する「サーバ」の階層を示す。サーバ名は任意に選択されてよいことは明らかである。
【０１４３】
ＤＡＤプログラムに従って、選択されたサーバに対し多種多様のアクションを取ることができる。図８は「ソロモン」サーバが選択されたこと、そして調査され得るデータアクセスを示すためにデータアクセスメニュー項目がハイライト表示されていることを示す。データアクセスメニュー項目下に、データソース、データソースタイプ、コマンド、データオブジェクト、ビューを含むサブメニューが表示される。ＤＡＤプログラムとエクスプローラメニューを使用することにより、モバイルアプリケーション設計者は、新しいデータソースを規定することができ、そして開発済みアプリケーションを使用するモバイルクライアントの企業データソースへアクセスするためにこののアダプタとインターフェースすることができる。
【０１４４】
図９は、デクステラエクスプローラメニュー上の「データソースタイプ」を選択した設計者を示し、図９は、コンテキストメニューが生成され、新しいデータソースタイプを追加するか、ビューをリフレッシュするか、データソースタイプを編集するか、又はデータソースタイプを削除するかの選択肢を設計者に提供することを示す。従って、デクステラエクスプローラメニュー項目を選択することにより、選択されたメニュー項目上に追加の操作のメニューを提供するコンテキストメニューを生成することができる。図１０は、図９からのデータソースメニュー項目の選択を示し、設計中のシステムにおいて利用可能な例示的なデータソースを示す。図１１は具体的なデータソースタイプの選択を示す。このデータソースタイプから、選択されたデータソースタイプ上の編集操作のためにコンテキストメニューを生成することができる。図１２は、選択のために使用可能なビュータイプを示す。他のデクステラエクスプローラメニュー項目と同様に、ビューメニュー項目を選択することにより、設計者がビュータイプに関する編集操作（作成、編集、削除を含む）を実行できるようにするコンテキストメニューを生成する。
【０１４５】
上記のように、デクステラエクスプローラメニュー上の「データソース」ノードが選択された場合、エクスプローラプログラムにより生成されるコンテキストメニューを介して新しいデータソースを規定することができる。図１３は、新しいタイプのデータソースを作成するためにデータソースコンテキストメニューを利用することにより生成されるデータソースプロパティダイアログボックスを示す。図１３は、設計者に利用可能なデータタイプに基づいて、データアダプタの選択を許容する画面が設計者に提示されることを示す。図１３では、利用可能なアダプタタイプはＳＱＬサーバのＯＬＥ  ＤＢ、オラクルのＯＬＥ  ＤＢ、Ｃｌａｒｉｆｙアダプタ、Ｒｅｍｅｄｙアダプタが示される。これらのアダプタタイプは例示のためのみに示される。本発明の教示に従って追加の異なるアダプタタイプを提供し得ることを理解すべきである。図１３は、設計者がまたコネクションタイプを規定することができることを示す。アダプタを選択した後に、設計者は、接続パラメータを規定するためにコネクション表示ボタンを選択するであろう。
【０１４６】
図１４は、設計者がログイン情報を提供し、特定の企業データソースターゲットを選択するための認証画面を示す。設計者が許可されると、表示は選択されたアダプタに従って変更される。新しいデータソースが定義された後、ＤＡＤインターフェースを使用することにより、新しいデータソースタイプノードが、設計者の新しく定義されたデータソースタイプに従ってデクステラエクスプローラツリー表示（図１１）内に現われる。
【０１４７】
デクステラエクスプローラツリー表示から、他のノードを作成、編集、追加、削除することができる。図１５は、ツリー表示からコマンド選択を作成する設計者を示す。図１４の「新コマンドの追加」の選択は、図１６の「新コマンド」ダイアログボックスを生成する。
【０１４８】
図１６は、新コマンドに対し、データソース、アクション、データタイプ、ソースを規定するパラメータと、ＳＱＬステートメント入力用のスペースと共に、名前を入力することができることを示す。図１７は、追加コマンドダイアログのパラメータータブが追加のコマンド仕様を許容することを示す。
【０１４９】
図１６の新コマンド追加ダイアログボックスに関する管理パラメータには、次のものがある。
【０１５０】
コマンド名テキストボックス：ＤＡＤユーザは、一意的にコマンドを識別するために名前を入力する。「保存」の際、コマンド名がユニークであることの検証がある。
【０１５１】
データソース：これは定義済みデータソースのドロップダウンリストである。この情報はメタデータから発見される。すべてのコマンドは対応するデータソースを有する必要がある。
【０１５２】
コマンドタイプ（アクション）：これは、利用可能な異なるタイプのコマンドのドロップダウンリストである。すべてのコマンドはコマンドタイプを有する必要がある。
【０１５３】
データグループボックス：このグループボックスは、「メイン」と「パラメータ」用のタブを含んでおり、コマンドのアクションを定義するための制御を含む。このボックスは選択されたデータソースによって異なる。例えば、図１６に示す表示はＳＱＬサーバなどのＲＤＢＭＳである。オラクル／ジーベルシステムのようなシステムは「ＳＱＬステートメント」テキストボックスを恐らく持たないであろうと当業者は理解するであろう。
【０１５４】
ソースタイプラジオボタン：このラジオボタンを選択することにより、２つの対応するコンボボックス（データソースとソースタイプ）を有効にし、ＳＱＬステートメントテキストボックスを無効にする。このラジオボタンは、設計者が、企業データシステムにより利用可能な企業オブジェクトを使用していることを示す。
【０１５５】
ソースタイプボックス：企業システムから利用可能な企業オブジェクトのタイプを示すリストである。ソースタイプの例としては、テーブル、ビュー、又はＳＱＬにおけるストアドプロシージャが挙げられる。
【０１５６】
ソースボックス：タイプごとのフィルタリングに基づいてユーザが選択する利用可能な企業オブジェクトのドロップダウン式リスト。
【０１５７】
ＳＱＬステートメントラジオボタン：このラジオボタンを選択することにより、対応するテキストボックスを有効にし、ソースタイプ及びソースコンボボックスを無効にする。このラジオボタンは、このコマンドが実行しなければならないＳＱＬステートメントを、設計者が規定しようとしていることを示す。
【０１５８】
ＳＱＬステートメントテキストボックス：設計者は、コマンドにより実行されるＳＱＬステートメントを入力する。
【０１５９】
新コマンド追加のためのパラメータの中で、図１７のパラメーターダイアログボックスは次のものを含む。
【０１６０】
パラメーターリストボックス：関係する場合、選択された企業オブジェクトのパラメーターリストを含む。図１７は、戻値のパラメータと顧客ファーストネームを示す。
【０１６１】
パラメータープロパティグループボックス：選択されたパラメータのプロパティを記述する制御のグループ分けを示す。
【０１６２】
名前テキストボックス：選択パラメータの名前。図１７において、パラメータ名は編集されてはならないのでそれが無効であることを示すために、このテキストボックスは灰色反転表示される。
【０１６３】
指示ボックス：これは、パラメータが有し得る入力、出力、入力／出力などの指示タイプのドロップダウン式リストを含む。
【０１６４】
データタイプボックス：これは、この場合、パラメータに対し利用可能なデータタイプのドロップダウン式リストを含む。
【０１６５】
要求ボックス（Ｒｅｑｕｉｒｅｄ  ｂｏｘ）：ブール値の真又は偽を含み、これによりパラメータが必要かどうかを示す。
【０１６６】
値テキストボックス：パラメータの値が強制される場合、このテキストボックスは利用可能である。
【０１６７】
編集処理が完了した後、すべての追加項目を反映するためにデクステラエクスプローラ内のツリー表示は更新される。例えば、図１８は、「顧客照会」と呼ばれる新しいコマンドがツリー表示に追加されたことを示す。こうして、名前コマンドは、ソロモンサーバとインターフェースするためにＤＡＤを使用するすべての以降の開発者に利用可能になる。新しい顧客照会コマンドもまた、デクステラエクスプローラグラフィカルユーザインターフェースと編集コマンドを使用することにより、ツリー表示の別のノードに対し操作（コピー、移動、編集、移動、等）され得ることに留意されたい。
【０１６８】
こうして、本明細書で説明されたビューオブジェクト構成は、移動データプラットフォームの操作における柔軟性を強化するための複数のビュータイプを支援する。この新しいビューオブジェクト構成は、派生ビュー、代行ビュー、直接ビュー、定義ビューを含むビュータイプを支援する。各ビュータイプは異なる機能を有する企業データソースとインターフェースするので、優れた利便性、柔軟性、効率でもって通信リンクとシステム資源を使用することができる。
【０１６９】
こうして、デクステラエクスプローラツールは、異種のバックエンドデータソースへのカスタムの企業接続性を生成する能力を提供し、また、特定の実行インスタンスへの構成及び適応性を有する任意のバックエンド企業システムへの接続性を分離する能力を提供する。これにより、「．ＮＥＴ」インターフェースとバックエンドシステム間の通信が、バックエンドシステムにより必要とされる情報の構成とは別に開発されるようにし、こうして、本明細書で説明されたように、アブストラクション層を生成するとともに、コンフィギュレーションツールがその適応性を管理できるようにする。このようにして、開示されたツールは、デクステラデータマネージャに結合し、デクステラサーバと任意の企業データソースとの間でデータを移動させる際に必要とされる特定の入力と出力を実施する特定のデクステラアダプタインターフェースを実現する。
【０１７０】
図１９は、上述の移動データプラットフォームシステムの動作を示すフロー図である。フロー図ボックス１９０２に示す最初の動作では、複数の企業データソースと、アプリケーションサーバと通信を行うモバイルクライアントとの間で共有されるデータの処理方法は、モバイルクライアントから、企業データソースの一つにおけるデータに対するデータ操作の要求を受信することから始まる。ボックス１９０４に示す次の動作では、構成可能なビューオブジェクトが確定され、ここではビューオブジェクトは、要求されたデータ操作に対応する規定のコマンドオブジェクトデータアクションを実行するためのデータオブジェクトと結合するのに適している。ボックス１９０６における最後の動作では、リレーショナルデータエンジンを利用して、データに対する操作が、ビューオブジェクトで規定されたように実行される。
【０１７１】
モバイルアプリケーションの設計者により使用される、上記では「ＤＡＤ」と呼ばれるコンピュータープログラムツールが、移動データプラットフォームシステムの異種の企業データソースへのカスタム企業接続性を生成するために設けられる。ＤＡＤアプリケーションプログラムツールは添付図面に例示されたユーザインターフェースを介してこれらの機能を提供する。こうして、ＤＡＤアプリケーションプログラムツールは、複数の企業データソースとモバイルクライアントとの間で共有されるデータのアプリケーション処理を規定する手段を提供する。
【０１７２】
ＤＡＤツールプログラムが、接続アダプタを規定する処理を実行するためにユーザ入力を受信することができ、かつデータソース、バインディング等を確認することができる限り、ＤＡＤツールを含むコンピュータープログラムは、デスクトップコンピューター、ノート型コンピュータ等のコンピュータ装置又はコンピュータシステム上にインストールされてよい。構成されたアダプタと接続オブジェクトを、移動データプラットフォームシステム内に含むことができ、上記のようなモバイルプラットフォームのアプリケーションサーバにおいてインストールすることができるので、企業データソースを操作するために、アダプタの操作機能をモバイルクライアントにおいて利用することができる。
【０１７３】
上述のように、ＤＡＤツールは、バックエンド企業データソースにおいて格納されたデータオブジェクトに対し所望のデータ操作を提供するビューオブジェクトを構成する手段を提供する。構成されたビューオブジェクトが移動データプラットフォームに組み込まれると、移動データプラットフォームは規定のビューオブジェクトに従ってモバイルクライアントにより要求されたデータに対する操作を行う。このようにして、本コンピュータシステムは、ビューオブジェクトに従って規定のコマンドオブジェクトデータアクションを実行するために、コンピュータシステム内のデータオブジェクトに結合される構成可能なビューオブジェクトを提供する。
【０１７４】
本発明についての理解が得られるように、本発明は現在好ましい実施形態の点から上に説明された。しかしながら、本明細書では具体的に説明されないが本発明が適用可能なモバイル企業データシステムのための多くの構成が存在する。従って、本発明は本明細書で説明した特定の実施形態に限定されると見なすべきでなく、むしろ、本発明はモバイル企業データシステム一般に対して広い適用性を有するということを理解すべきである。従って、添付の特許請求項の範囲内のすべての修正、変形、又は均等な配置及び実施は、本発明の範囲内であると考えるべきである。
【図面の簡単な説明】
【０１７５】
【図１】本発明により構築されたモバイル企業プラットフォームのための好適なコンピュータシステム環境のブロック図である。
【図２】図１に図示されたモバイル企業プラットフォームにおけるデータの論理アーキテクチャのブロック図である。
【図３】図１の企業データソースとモバイルクライアント間のコネクタインターフェースを例示するブロック図である。
【図４】本発明により構築された好適なコンピュータシステム環境４００のブロック図である。
【図５】本発明によるビュー構造を使用した派生ビューデータフローの線図的表現である。
【図６】図１に図示されたモバイルプラットフォームのためのデータアーキテクチャの線図的表現を示す。
【図７】本発明により構築されたモバイルプラットフォームのためのデータアクセス構成の線図的表現である。
【図８】ＤＡＤコンピュータープログラムアプリケーションをホストするコンピュータ装置上の表示のスクリーンショットである。
【図９】「データソースタイプ」がデクステラエクスプローラメニュー上で選択されたときのＤＡＤプログラムにより生成されたツリー表示とコンテキストメニューを示す。
【図１０】図９の表示からのデータソースメニュー項目の選択を示す。
【図１１】コンテキストメニューが生成される、特定のデータソースタイプの選択を示す。
【図１２】選択のために利用可能なビュータイプを示す。
【図１３】新しいタイプのデータソースを作成するために、データソースコンテキストメニューを利用することにより生成されるデータソースプロパティダイアログボックスを示す。
【図１４】ＤＡＤログイン情報のための、及び特定の企業データソースターゲットを選択するための認証画面を示す。
【図１５】ツリー表示からコマンド選択を作成する設計者を示す。
【図１６】図１５における選択に応じた「新コマンド」ダイアログボックスを示す。
【図１７】追加コマンドダイアログのパラメータータブを示す。
【図１８】追加された「顧客参照」と呼ばれる新コマンドを有するツリー表示を示す。
【図１９】本発明によるコンピュータシステムの動作を例示するフロー図である。
【符号の説明】
【０１７６】
１０２  モバイルクライアントデバイス
１０４，４０４  ネットワーク接続
１０６，４０６  アプリケーションサーバ
１０８，４０８  企業データソース
１１０  管理者アプリケーション
１１２  開発者アプリケーション
１１６  データ記憶装置
１１８  リレーショナルデータベース
１２０  ビジネスデータ
１２２  メタデータ
１２４  アプリケーション
４３０  コンポーネント
【図１】
2008533630.tif 000003
【図２】
2008533630.tif 000004
【図３】
2008533630.tif 000005
【図４】
2008533630.tif 000006
【図５】
2008533630.tif 000007
【図６】
2008533630.tif 000008
【図７】
2008533630.tif 000009
【図８】
2008533630.tif 000010
【図９】
2008533630.tif 000011
【図１０】
2008533630.tif 000012
【図１１】
2008533630.tif 000013
【図１２】
2008533630.tif 000014
【図１３】
2008533630.tif 000015
【図１４】
2008533630.tif 000016
【図１５】
2008533630.tif 000017
【図１６】
2008533630.tif 000018
【図１７】
2008533630.tif 000019
【図１８】
2008533630.tif 000020
【図１９】
2008533630.tif 000021
【国際調査報告】
2008533630.tif 000022
2008533630.tif 000023
2008533630.tif 000024
2008533630.tif 000025