(57)【要約】企業データのためのモバイルクライアントからの要求が受信され、要求されたデータを含む適切な企業データソースが決定され、そして、企業データは決定された企業データソースから検索されるように、データが複数の企業データソースと分散システム内のモバイルクライアントの間で共有される。企業データが検索されるとき、それは、たとえ複数の企業データソースから来たとしても、検索されたデータに関連するリレーショナルのフォーマットに変換される。変換された企業データはモバイルクライアント内の関連データ・ストアに保存される。このように、モバイルアプリケーションは、複数の企業データソースからのデータと完全に統合することができ、そして、一時データ格納を用いることなく、データのアップデートおよび構成変化は、モバイルクライアントに分配でき、または、モバイルクライアントから分配でき、そして、それにより、企業データソースとモバイルクライアントの間の複雑な同期とデータコンフリクトの問題を回避する。
2006512695.tif 000002
【特許請求の範囲】
【請求項１】
複数の企業データソースとモバイルクライアントの間で共有されるデータを処理する方法であり、
クライアントアプリケーションで使用される企業データのためにモバイルクライアントから要求を受け取り、
要求されたデータを含むとして特定された企業データソースからの企業データを検索し、
メタデータによって指定された関係に従って、検索されたデータを、企業データソースから検索されたデータを定義するリレーショナルフォーマットに変換し、そして、
変換されたデータを、モバイルクライアント内のリレーショナルデータ格納に保存することを備え、
クライアント要求は、要求されたデータに対する企業データソースを特定して、そして、要求されたデータの間で関係する対応を指定するメタデータを含む方法。
【請求項２】
メタデータはクライアントアプリケーションで実行されるビジネスプロセスを記述する請求項１記載の方法。
【請求項３】
メタデータは、アプリケーションサーバからモバイルクライアントにて受け取られる請求項１記載の方法。
【請求項４】
モバイルクライアントは、クライアントアプリケーションの初期化動作の間、メタデータを要求する請求項１記載の方法。
【請求項５】
アプリケーションサーバが企業データソースへのデータおよびそこからのデータを処理するように、メタデータは、企業データソースのデータスキームを暴露する企業データソース内にビューを指定する請求項１記載の方法。
【請求項６】
メタデータは、モバイルクライアントと複数のバックエンド企業データソースとのデータコンフリクトを解決するコンフリクト検出と解決パラメータを指定する請求項５記載の方法。
【請求項７】
モバイルアプリケーションは、複数のディスプレイページを含み、そして、それぞれのディスプレイページは、別のディスプレイページのフローを指定するメタデータに関連する請求項１記載の方法。
【請求項８】
メタデータは、複数の企業データソースからの変換されたデータが、共に関連するように、リレーショナルデータベースフォーマットでオブジェクトを定義するデータのビジネスオブジェクト層を指定する請求項１記載の方法。
【請求項９】
モバイルクライアントからアップロードデータを受け取って、アップロードデータが送られるべきである対応する企業データソースを決定することを更に含む請求項１記載の方法。
【請求項１０】
モバイルクライアントからのアップロードデータが対応する企業データソースに保存されるべきであるかどうか、またはそのアップロードデータが拒絶されるべきかを決定するために、コンフリクト検出と解決ルールを適用することを含む請求項９記載の方法。
【請求項１１】
複数の企業データソースと複数のモバイルクライアントの間で共有することができるデータを、モバイルクライアントに供給することをサポートするアプリケーションサーバであり、
モバイルクライアントからデータ要求を受け取り、検索されるべきデータおよび、データが検索されるべき企業データソースを決定するために、クライアントのデータ要求のメタデータを処理するデータマネージャと、
企業データソースからのデータを検索し、検索されたデータを、企業データソースからの検索されたデータを決定する関連したフォーマットに変換し、そして、変換されたデータを、モバイルクライアント上の関連するデータ格納へリターンする１つ以上のコネクタとを備えるアプリケーションサーバ。
【請求項１２】
メタデータはクライアントアプリケーションで実行されるビジネスプロセスを記述する請求項１１記載のアプリケーションサーバ。
【請求項１３】
メタデータは、モバイルクライアントにてアプリケーションサーバから受け取る請求項１１記載のアプリケーションサーバ。
【請求項１４】
モバイルクライアントはクライアントアプリケーションの初期化動作の間、メタデータを要求する請求項１３記載のアプリケーションサーバ。
【請求項１５】
アプリケーションサーバが企業データソースへのデータおよびそこからのデータを処理するように、メタデータは、企業データソースのデータスキームを暴露する企業データソース内にビューを指定する請求項１１記載のアプリケーションサーバ。
【請求項１６】
メタデータは、モバイルクライアントと複数のバックエンド企業データソースとのデータコンフリクトを解決するコンフリクト検出と解決パラメータを指定する請求項１５記載のアプリケーションサーバ。
【請求項１７】
モバイルアプリケーションは、複数のディスプレイページを含み、そして、それぞれのディスプレイページは、別のディスプレイページのフローを指定するメタデータに関連する請求項１１記載のアプリケーションサーバ
【請求項１８】
メタデータは、複数の企業データソースからの変換されたデータが、共に関連するように、リレーショナルデータベースフォーマットでオブジェクトを定義するデータのビジネスオブジェクト層を指定する請求項１１記載のアプリケーションサーバ。
【請求項１９】
モバイルクライアントからアップロードデータを受け取って、アップロードデータが送られるべきである対応する企業データソースを決定することを更に含む請求項１１記載のアプリケーションサーバ。
【請求項２０】
モバイルクライアントからのアップロードデータが対応する企業データソースに保存されるべきであるかどうか、またはそのアップロードデータが拒絶されるべきかを決定するために、コンフリクト検出と解決ルールを適用することを含む請求項１９記載のアプリケーションサーバ。
【請求項２１】
モバイルネットワーク上で複数の企業データソースからのデータを処理するモバイルクライアントであり、
データ処理機能を実行して、データ要求を生成するアプリケーションと、
アプリケーションからデータ要求を受け取り、そして、検索されるために企業データソースを指定し、そして、データが検索されるべき企業データソースを指定するメタデータを含むクライアントデータ要求を生成し、モバイルネットワークを通じてクライアントデータ要求を送信するデータマネージャと、
クライアントデータ要求への応答から企業データが格納される関連データ記憶とを備え、  前記応答は、受信した要求に含まれるメタデータに基づき、企業データソースからの検索されたデータに関する関連フォーマットに変換された企業データ送信端末からの要求された企業データを備えるモバイルクライアント。
【請求項２２】
メタデータはクライアントアプリケーションで実行されるビジネスプロセスを記述する請求項２１記載のモバイルクライアント。
【請求項２３】
メタデータは、アプリケーションサーバからモバイルクライアントにて受け取られる請求項２１記載のモバイルクライアント。
【請求項２４】
モバイルクライアントは、クライアントアプリケーションの初期化動作の間、メタデータを要求する請求項２３記載のモバイルクライアント。
【請求項２５】
アプリケーションサーバが企業データソースへのデータおよびそこからのデータを処理するように、メタデータは、企業データソースのデータスキームを暴露する企業データソース内にビューを指定する請求項２１記載のモバイルクライアント。
【請求項２６】
メタデータは、モバイルクライアントと複数のバックエンド企業データソースとのデータコンフリクトを解決するコンフリクト検出と解決パラメータを指定する請求項２５記載のモバイルクライアント。
【請求項２７】
モバイルアプリケーションは、複数のディスプレイページを含み、そして、それぞれのディスプレイページは、別のディスプレイページのフローを指定するメタデータに関連する請求項２１記載のモバイルクライアント。
【請求項２８】
メタデータは、複数の企業データソースからの変換されたデータが、共に関連するように、リレーショナルデータベースフォーマットでオブジェクトを定義するデータのビジネスオブジェクト層を指定する請求項２１記載のモバイルクライアント。
【請求項２９】
モバイルクライアントからアップロードデータを受け取って、アップロードデータが送られるべきである対応する企業データソースを決定することを更に含む請求項２１記載のモバイルクライアント。
【請求項３０】
モバイルクライアントからのアップロードデータが対応する企業データソースに保存されるべきであるかどうか、またはそのアップロードデータが拒絶されるべきかを決定するために、コンフリクト検出と解決ルールを適用することを含む請求項２０記載のモバイルクライアント。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
[優先権のドキュメントの参照]
この出願は以下の継続中の仮米国特許出願の優先権の権利を要求する:
2002年12月23日出願、No. 60/436,230の「ビジネスプロセスユーザーインタフェースシステムおよび方法」、2003年1月23日出願、No. 60/442,810の「コンテキスト機密データのアップデートシステムおよび方法」および、2003年4月7日出願、No. 60/461,588 の「コンテキスト機密データのアップデートシステムおよび方法」
出願日付の優先権はこれにより要求され、そして、仮の特許出願の開示は参考のため取り込まれる。
【０００２】
[背景]
１．発明の分野
一般に、この発明はモバイル・コンピューティングシステムおよび特にモバイル・コンピューティングシステムにおけるデータ管理とデータ展開に関係する。
【０００３】
２．従来技術の説明
近年、多くのリソースがバック・オフィスとフロントオフィスでのプロセスのオートメーションに投資されている。例えば、高度なカスタマ・リレーションシップ・マネージメント(CRM)および経営資源利用計画(ERP)システムを開発して、購入するための多額が費やされている。多くの組織によって、実施するにはシステムの重荷および既存する過去のデータシステムと統合するのが困難であることが判明したが、多くの会社が重要な貯蓄と効率を達成した。これらの改良は、広範囲の技術主導の生産性上昇に貢献するのに役だった。
【０００４】
オフィスのプロセスオートメーションの取り組みは、通常多くの顧客重要なプロセスに焦点を合わせられており、そこでは、組織は顧客にインタフェースするが、取り組みは会社の正面玄関に大きく留まった。より最近、オートメーションの利益を彼らの作業員(彼らのモバイルの作業員)の最も自動化されなかったセグメントにもたらすように多くの組織が努力している。これらの作業者は顧客の組織の認知で大きな役割を果たした。現在、そのような作業者のためのオートメーションおよび実施されたビジネスプロセスの範囲は、ポケットベルや携帯電話などのモバイル・コンピューティングデバイスに制限されている。
【０００５】
モバイル・コンピューティングは、顧客に会う現場スタッフが持つ情報駆動の企業にかなりの利益を提供することができる。例えば、モバイル・コンピューティングデバイスを現場スタッフに提供することによって、現場スタッフの生産性を根本的に増強することができ、そして、注文やサービススケジューリングなどの重要なビジネスプロセスを劇的に加速することができる。そのようなモバイル・コンピューティングシステムの早期の採用者である多くの企業は、これらの利益がかなりの費用と共にしばしば来ることを発見した。モバイルプラットホームの採用者によって直面していた主要な困難のいくつかは、企業で他のデータとの統合にかかわる。
【０００６】
モバイルアプリケーションがしばしば、企業の他のデータシステムによる統合を阻害する、独占で閉じられたアーキテクチャの状態で入るので、企業データの統合問題が起こる。例えば、企業におけるデータは４つか５つの異なったソースで保守されるかもしれない。いくつかのデータソースは、CRMシステム、発信システム、ERPシステム、および財政的な記録システムを含む。それぞれのこれらのデータソースは、異なったデータアーキテクチャ、フォーマット、およびプロトコルを利用することがある。保存されるデータとデータ構成とアクセス機構は絶えず変化する。多くのモバイル・コンピューティングシステムは、企業における様々なソースからのデータが集められる一時データ保存を作成する。このように、異なった企業データソースからのデータ(それぞれが異なったデータアーキテクチャとフォーマットを持つ)をただ一つの一般的なデータベースに集めることができる。 実際の企業データソースよりむしろ一時データ保存にアクセスすることによって、モバイルユーザは企業データにアクセスすることができる。しかしながら、当座の格納はデータのアップデートとそれ自身のコンフリクト問題を作成する。一時データ保存内のデータが企業のデータソース内のデータの忠実なコピーであることを保証するために、頻繁に同期操作と他の安全装置を実行しなければならない。
【０００７】
これらの困難と拡大された複雑さの結果、モバイルアプリケーションが他のアプリケーションやデータと完全に統合し、よりすばらしい機能的な能力を持つのが必要であることの強調が更新される。この発明はこれらの要求を満足する。
【０００８】
[発明の概要]
この発明によると、モバイルクライアントからの企業データに対する要求が受信されるように、データが複数の企業データソース間で分散システム内のモバイルクライアントに利用され、要求されたデータを含む適切な企業データソースが決定され、そして、企業データは決定された企業データソースから検索される。企業データが検索されるとき、そのデータが、異なった関連性のないタイプの複数の企業データソース(例えばファイルシステムやｅメールなど)から来たとしても、それは関係するフォーマットに変換される。変換された企業データはモバイルクライアント内の関係するデータ保存に保存される。このように、複数の企業データ送信端末とデータ最新版からモバイルアプリケーションをデータと完全に統合することができ、そして、リアルタイムでクライアントと、そして、モバイルクライアントから構成変化を分配することができる。このように、モバイルアプリケーションは、複数の企業データ送信端末からのデータと完全に統合することができ、そして、データのアップデートおよび形態の変化は、一時データ保存を用いことなく、リアルタイムでモバイルクライアントに対し、およびそれから、データ最新版と構成変化を配分でき、その結果、企業データソースとモバイルクライアントの間の複雑な同期と非同期なデータ問題を避ける。リアルタイムのデータ変化は、モバイルアプリケーション自体への変化の展開、およびデータのアップデートを含むことができる。リアルタイムの変化は、データのコンフリクトおよび解決にさらに適応される。
【０００９】
この発明の他の特徴および利点は、この発明の原理を例により示した、以下の好適な実施例の説明で明らかになるであろう。この利点は、添付した図面に関連して以下の詳述の参照することにより、より容易により評価でき、かつよりよく理解されるようになるであろう。
【００１０】
[詳細な説明]
１．システムの概要
この発明は、データアップデートと構成変化は、一時データ保存を用いることなく、モバイルクライアントへ分配でき、かつ、そこから受け取ることができるように、データが複数の企業データソースからモバイルモバイルアプリケーションを実行するクライアントまで利用されるシステムを提供する。一時データ保存の排除は、企業データソースとモバイルクライアントの間の複雑な同期、非同期のデータ問題を回避する。したがって、モバイルアプリケーションのためのデータアップデートとシステム構成アップデートは、リアルタイムで、企業からモバイルクライアントへ、およびモバイルクライアントから企業へ伝えることができる。リアルタイムでシステムを通して変化を伝播することができるので、どんな特別な同期操作も必要ではない。
【００１１】
２．システムのプラットホーム
図１はこの発明に従って構成された適切なコンピュータシステム環境100のブロック図である。図１は、マイクロソフトPocketPCかパームPDAオペレーティングシステムに関連して作動するパーソナル・デジタル・アシスタント(PDA)デバイスなどのような、モバイルクライアントデバイス102を示す。モバイルクライアントデバイスは、サーバからデータを要求し、そしてデータアップデート、新しいデータを提供し、そして構成変化を受けるために、アプリケーションサーバ106とのネットワーク接続104を通じて交信する。複数のモバイルクライアント102がサーバ106と通信できることを理解されるべきである。図面の簡略化のために、図１ではただ１つのクライアントデバイス102が示される。
【００１２】
モバイルクライアント102は、複数の企業データ・ストアからリアルタイムのデータの検索のために、サー側コネクタウェブサービスを消費する。さらに、モバイルクライアントは、リアルタイムのクライアント側データアップデート、サーバ側データアップデート、およびシステム構成アップデートの管理のためにサーバ側データ管理ウェブサービスを消費する。
【００１３】
アプリケーションサーバ106は、CRMデータソースや、ERPソースや、金融システムリソースや、レガシーデータ・ストアや、同様のものなどのような企業データソース108と通信する。図１で例証された模範的企業データソースは、USA, California,San Mateo の Siebel Systems, Inc からの"Siebel" ソフトウェア、USA, California, Redwood Shores の Oracle Corporationからの"Oracle" ソフトウェア、Germany, SAP AG of Walldorf からの"SAP"ソフトウェアおよび、過去のソフトウェアを含むデータを含む。管理者アプリケーション110および開発者アプリケーション112は、アプリケーションサーバ106と通信し、このサーバは以下に述べるように、システムに対するメタデータ114も格納する。
【００１４】
アプリケーションサーバ106は、データ置き換え、アップデート、ユーザ認証、セキュリティ、およびロッギングサービスのためのデータ管理、構成、およびデータコネクタウェブサービスを提供する。また、アプリケーションサーバは企業情報と規則のフォームでビジネスプロセス管理を扱う。
【００１５】
また、モバイルクライアント102は、ビジネスデータ120を保存するリレーショナルデータベース118および、アプリケーション実行のためにモバイルクライアント上にメタデータ122を保存するリレーショナルデータベースも含んでいるデータ保存116を含む。モバイルクライアント102にインストールされるアプリケーション124は、適当な機能を実行する様々なソフトウェアコンポーネントを含む。例えば、アプリケーションは、サービスが要求された位置を、現場サービス要員に知らせ、サービス要求の本質について説明し、そして、サービス訪問を登録して、清算を与えるフィールドサービスアプリケーションを含むかもしれない。アプリケーション124はモバイルクライアント102によって要求されたデータを処理する複数のアプリケーションを含むかもしれない。
【００１６】
管理者アプリケーション110と開発者アプリケーション112は共に、「スタジオ」コンポーネント130を備える。図示した具体化では、管理者と開発者は、２つの個別のアプリケーションとして与えられ、そしてシステムを構成するために、メタデータデータとアプリケーションインタフェースを含む手段を提供する。
【００１７】
システム100は、サービスアプリケーション124をサポートするモバイル企業プラットホームを備える。そのシステムは、モバイルビジネスプロセスを高めるために、モバイルかされたソフトウェア解決を採用して管理する１セットのウェブサービスを提供する。一般的な例は、CRMかERP、営業支援システム(SFA)、顧客サポートおよび企業のためのヘルプデスク機能に統合することを含む。1台の機能かシステムからのデータが、しばしば異なった機能かシステムによって使用されることで、そのような企業アプリケーションは、クロスするアプリケーションの相互作用に依存する。モバイルクライアント上で実行された時、既存のアプリケーションの機能性、および企業情報は、複数の企業ソフトウェアアプリケーション、レガシーデータ・システム、およびモバイル作業者の中で利用される。このように、これらのアプリケーションおよびモバイル企業プラットホームに対して重要な投資利益率を達成することができる。
【００１８】
モバイル企業プラットホーム100は、分野でモバイルクライアントと関連携帯機器の使用を簡素化するウェブサービスを提供する。これらのウェブサービスは、データ管理機能、構成機能、およびコネクタ機能を含む。これらについては以下より詳細に述べる。モバイルクライアント102にインストールされるアプリケーション124は、それらがアプリケーションサーバ106によって適切に開始された後、いかなる接続または切断の状態でも十分に機能的である。
【００１９】
３. 論理的なアーキテクチャ
図１で例証されたモバイルエンタープライズのプラットホームを利用するどんなクライアントアプリケーションも図２のブロック図で例証されたシステムの部品を利用するであろう。これらの部品は以下を含む。
・ビジネス目的：ビジネスの概念に基づくプログラマブルの目的であり、異なる企業データソース(例えば、 Customer, Contacts, Assets, Tasksなどのデータソース)からのフィールドと関連する情報を結合する。
・ビジネスルール：企業データソースからのビジネスデータに対して適用されるチェックがあるビジネス定数を用いてビジネス処理を実施するカスタムロジック。
・ビジネス定数：クライアントアプリケーションを通じて使用のためにユーザの構成可能な変数であり、クライアントおよびサーバ側のビジネスルール(例えばBusiness Rules, Warning Messages, および同種)。
・データソース コネクタ：シームレスにさまざまな企業データソースへのアクセスを提供するように設計されたデータソースコネクタ(OracleとSQL Serverによりフォーマットされたものなどのデータベース、MQ シリーズ または MSMQのようなメッセージ用システム、Siebel または Peoplesoft, generic web services, および同種のようなCRMアプリケーション)。モデルビジネスプロセスを設計するためのフォームからフォームへのナビゲーションパラダイムを決定する。
・フォーム：イベント駆動の論理があり、ここでは"フォースフロー"か"フィールドフロー"のどちらかと関連するビジネスプロセスで情報を示して、情報を収集して、ユーザを指示するように設計される標準の視覚ディスプレイの画面(例えば、ビュー、編集、発見、および同様のもの)の組み合わせ。
・ビュー：企業データソースから特定されたデータかビジネス目的によって利用されるアプリケーションの修正できる表現。
・フィルタ：ビジネス目的に利用可能なデータを変更するためにビューに適用することができるフィルタ。
【００２０】
マイクロソフト社「.NET」などのフレームワーク技術とマイクロソフト社の「ヴィジュアルスタジオ.NET」などのツールを利用することで構成されるいずれのクライアントアプリケーションの構成(論理的なアーキテクチャ)も指定するためにこれらのコンポーネントを使用することができる。当業者は、アプリケーションとその関連データ・オブジェクトを指定するためにそのようなプログラミングツールに身近であろう。
【００２１】
図１で例証されたモバイルエンタープライズ プラットホームはメタデータ駆動のフレームワークとして実装される。フレームワークは、統合クライアント、サーバウェブサービスを提供して、フェールセイフ、ミッションクリティカルなモバイル企業ソリューションを採用するために、接続、構成およびデータ管理サービスを可能にする。
【００２２】
図２は、図１のモバイル企業プラットホーム内において、メタデータとして見せるために、リレーショナルデータベーステーブルおよび外部のアプリケーションビジネスブジェクトがマップされていることを例証する。１つ以上のビューが、ビジネスオブジェクトにより消費され、また、メタデータで定義され、それが次にモバイルアプリケーションにより利用される。モバイルアプリケーションは"Dexterra Smartclient"と呼ばれるクライアントフレームワークを利用し、それは、データマネージャ、そして/または、コネクタウェブサービスによって、ビジネスオブジェクト、モバイルクライアントデバイスにある基本的な物理的なデータベースへのローカルデータアクセス、デバイス統合、およびクライアント/サーバデータ通信の具体化を管理する。プラットホームの中では、すべての論理的な層(例えば、ビジネスオブジェクト、ビュー、フィルタ、および接続)のための仕様は、メタデータの中で定義されて、維持される。
【００２３】
モバイル企業プラットホームは、接近するメンバーを除く全てから、論理的なアーキテクチャ内の層を隔離するように設計された論理的なスタックとして設計される。論理的なスタックのボトムでは、ターゲットの層は、バックエンドにあるデータであり、企業データリソースである。プラットホームは、適所のソースデータで動作し、バックエンドシステム内に、中央層の模写データベースに模写されるべき記録の情報を必要としない。すなわち、どんな一時データ記憶も必要ない。これはリアルタイムのデータアクセスのみならず、設計に柔軟性を与え、これは、プラットホームおよびアプリケーションの所有権の総費用を削減するのを助けることができ、さして、データ管理プロセスの簡素化に役立つ。
【００２４】
論理的なスタック内の次の上の層は、接続層である。その接続層は、リレーショナルなフォーマットで、アプリケーションサーバへのバックエンドデータ記憶を説明するプログラムに従った構造物を提供する。セキュリティの設定(認証方法や、ユーザやグループ定義などの)のみならず、どのようにして企業データソースに接続するかに関する情報は、メタデータの中に保存され、そして管理者のコンポーネントを使用して維持される。
【００２５】
スタック内の次の層はビュー層であり、それは、バックエンドで１つ１つのマッピングをオブジェクトかテーブルに供給するオブジェクト、企業データソースを含む。例えば、バックエンドシステムがCUST_ADDR(顧客アドレス)と呼ばれるテーブルを持ち、そして、そのテーブルからのデータがアプリケーションでの使用に要求されるなら、管理者コンポーネント内にビューが形成される。管理者 ビューは、モバイル企業プラットホーム、企業データソースの外部の環境におけるそのデータを表すために例えば、CUSTOMER_ADDRESSと呼ばれるかもしれない。Viewにはバックエンドシステムにおける、データ・オブジェクトに関する特性かコラムに対応する特性を持つことが理解されるべきである。しかしながら、バックエンドデータソースのすべての特性がビュー特性として必要であることが必要ではない。実際、必要である特性は、管理者コンポーネントで定義され、そしてメタデータとして保存される。いま提供された例では、その特性は、IDや、ADDR、通りのアドレス、市、州、および郵便番号などの分野を含むかもしれない。
【００２６】
さらに、ユーザは、ビュー内で特性に関するデータタイプを定義することができ、そして、これらのデータタイプは企業データソースの対応する特性に関するデータタイプから独立している場合がある。特定することができるビュー特性の他のオプションは、ユニークな識別子と、書き込み禁止と、インデックスと、必要な特性と長さである。すべての上記の情報はメタデータとして格納される。
【００２７】
ビュー層は、また、データコンフリクトのしるしを供給して、そのようなコンフリクトを解決するための手段を提供する。データコンフリクトは例えば、モバイルクライアントからアップロードされたものと、サーバで存在するものとの間にデータ変化があるときはいつも、起こることがある。そのようなコンフリクトの解決は、ビューで実行することができ、データを可能にするのは、データタイプ(例えば、フィールド・データか顧客アカウント・データ)によって優先させるために、特定のソース(例えば、モバイルクライアントか企業データソースのどちらか)からのデータ変化を許可する。これは以下でさらにデータ管理ウェブサービスに関連して説明される。
【００２８】
図２で例証されるように、複数のデータ格納内の複数のオブジェクトに対してビューsを定義することができ、それにより、データ模写の重荷なしでシステムをアプリケーションの展開および適所の使用に柔軟性に提供する。コネクタのように、ビューの定義は、メタデータに格納され、そして管理者で管理される。当業者は詳細な説明なしでメタデータのデータ定義の詳細を理解するであろう。上で述べたように、次の層に通過されるデータを変更するために、フィルタをビューに適用することができる。管理者は、オブジェクトインターフェースに基づくビューを自動的に作成するビューウィザード、または、(企業データソースからの)バックエンドデータ格納オブジェクトのテーブル定義を含む、ビュー管理機能を供給する。
【００２９】
図２上の次の層は、ビジネスオブジェクトを含み、それは、写像されるか、１つ以上のビューに関係する。プラットホームのビジネスオブジェクトは、開発者が組立時、モバイルアプリケーションをカスタム設計することに相互作用するプログラムに従った実体である。ビジネスオブジェクトは複数の特性を含み、それらの各々は、簡単なデータタイプであるか、またはそれは別のビジネスエブジェクトであるかもしれない。プラットホームのビジネスエブジェクトを複数のビューに写像することができるので、開発者は複数の異種のデータソースから出典を明示されたデータを表すただ一つの実体で働くことができる。 したがって、この発明のモバイル企業プラットホームに従って定義された単一のビジネスオブジェクトは、異なった独占フォーマットのように、複数の、潜在的に非互換な企業データソースからのデータを含むことができる。
【００３０】
モバイルアプリケーションおよびモバイルクライアントデバイスのアプリケーションを作成するか、または変更する際に、開発者は単にビジネスオブジェク層と対話することができる。これは、ソースデータのために直接バックエンドシステム(企業データソース)を理解するか、または対話するというどんな要求からも開発者を隔離する。このように、ビジネスオブジェクト層は、永続およびデータ検索の詳細を抜き取って、オブジェクトベースのインタフェースをアプリケーション開発者に提供する。 開発者がモバイル機器上で直接にローカルなデータ格納と対話する必要は全くない。さらに、切断しているデータの本質のため、モバイルクライアントは、アップデータプロセスの間にアプリケーションサーバを通過するクライアントにローカル的にデータ変化を保存することによって、ビジネスオブジェクトインタフェースを通じて自動的にデータ変化の処理を管理する。これは、開発者をこの暗唱プログラミングタスクからさらに隔離する。
【００３１】
ビジネスオブジェクトは、メタデータとしてモバイルクライアントデバイスに存在していて、また、管理者を使用することで管理される(図１)。モバイル企業プラットホームを通じてのメタデータの使用は、コード化されるよりむしろ、グラフィカルユーザーインターフェースを通じて、ほとんどのデータ実体の属性と挙動を構成することができる環境を提供する。
【００３２】
モバイル企業プラットホームのメタデータ駆動の本質は、無状態のサーバアーキテクチャを通してモバイルクライアントでのビジネスプロセスの実行を可能にする。メタデータを通して、モバイルアプリケーションは構成され、そしてカスタマイズされることができる。メタデータは、ビジネス企業データを参照するビジネスオブジェクトの構造を、モバイル機器に定義し、そして、ビジネスプロセスを決定するビジネスルールの引き金となるイベントを定義する。
【００３３】
メタデータデータベースは、クロス機能(ビジネスオブジェクトを構成するためにコネクタを通して展開されるクロスアプリケーションのバックエンドビジネス情報)の参照を含む。このプロセスは、スタジオコンポーネント(図１)を通じて、企業データソースビジネス情報をビジネスオブジェクトに結合することを構成し、参照することで達成される。これは、経路をモバイルアプリケーションに対する特定のデータに提供し、データのアップデートのために、企業データソースからのビジネスデータを、それの本来のデータフォーマットでアプリケーションサーバまたは他のいずれかのシステムの一時データ保存に格納されないことを保証する。メタデータを用いた、非侵入的でリアルタイムの同期アプローチは、クロス機能データアクセス、データ密度およびデータの完全性を最大限にする一方、モバイル企業プラットホームが、最小の分裂量で、バックエンドシステムに有効的に接続することを可能にする。
【００３４】
４. モバイル企業プラットフォームコンポーネント
Ａ. モバイルアプリケーション
上で述べたように、モバイルクライアント102(図1)は、企業のビジネスプロセスを実行する、インストールされたアプリケーション124を含むことができる。そのアプリケーションは、上で説明されたモバイル企業プラットホームを利用することができ、そして、アプリケーションがいかにして、メタデータで構成されたビジネスプロセスを駆動するビジネスオブジェクトをいかに例示するかを示す。
【００３５】
例えば、タスクまたは作業命令情報は、ビューを通じてモバイルアプリケーションに提供され、そしてビジネスオブジェクトを通してアクセスされるであろう。ビューの定義を通じたビジネスデータの検索では、データ管理ウェブサービスを使用して、ビジネスオブジェクトは、タスクについて説明するためにビジネスデータをモバイルアプリケーションに提供することができる。このデータは、モバイル機器上のローカルリレーショナルデータベースに保存される。アプリケーションからの要求でタスクデータへのアップデートがタスクビジネスに委ねられた時、スマートクライアントアプリケーションは、モバイルクライアント上のビュー定義されたデータ格納への変化を固持し、その後、そのスマートクライアントは、データ管理ウェブサービスを通して、データアップデートを管理してオリジナルのデータソースに戻し、データ保全と一貫性を確実にする。
【００３６】
ここで説明されたモバイル企業プラットホームで利用できるウェブサービス(例えば、接続、構成、およびデータ管理サービス)の深さ、幅、およびパワーを利用することによって、販売力の生産性や、顧客サービスや、サポート解決などのアプリケーションを含む、大きい一組のモバイルアプリケーションを容易に組み立てることができる。そのようなアプリケーションは、油/ガス、ヘルスケア/医学的、および、財政的なサービス業解決を含む広い垂直なアプリケーションと統合することができます。
【００３７】
Ｂ. サーバコンポーネント
アプリケーションサーバは、一種のメタデータ駆動のプラットホームアプリケーションであり、情報、アプリケーション、およびビジネスプロセスをモバイルクライアントに提供し、そして、モバイル企業プラットホームとバックエンド企業データソースのホストとの間の管理されたデータ保全を確実にする。アプリケーションサーバは、米国、ワシントン、レッドモンドマイクロソフト社の「.NET」技術で構築されたプロセスベースの、かつ、高性能の解決である。「.NET」技術を使用して、モバイルエンタープライズ解決は、データの交換および転送のために、XMLとSOAPの使用によるネイティブのウェブサービスであるフレームワークである。アプリケーションサーバは、図１の機能的な構造図で示されるように３コアのウェブサービスを提供する。
・コネクタウェブサービス
コネクタウェブサービスは、モバイルクライアントと離散的な企業データソースの間のデータの保全状態の制御を維持している間、既存企業アプリケーションインフラストラクチャの非侵入の統合を提供する。
・構成ウェブサービス
構成ウェブサービスは、認証、ロギング、セキュリティなどのビジネスデータ、ビジネスオブジェクト、ビジネスルール、ビジネス定数、およびシステム構成を定義するメタデータ、およびモバイルクライアント(モバイル機器にあるコンポーネントアプリケーション)に渡されるモバイルアプリケーションを包含するルールを管理する。
・データ管理ウェブサービス
データ管理ウェブサービスは、モバイルクライアントアプリケーションと、アプリケーションサーバと、第三者の企業データソースとの間のアップデート相互作用を調整する。さらに、データ管理ウェブサービスは、リアルタイムの質問のためにコネクタ層と直接交信する能力を提供する。データ管理ウェブサービスは、データの保全を実施するために複数のユーザによる複数の企業データソースへの複数のアップデートに関する様々な状態を管理する方法に柔軟性を提供する。データ管理ウェブサービスは、アプリケーションサーバでこれをするか、またはいずれかのAPIおよび/または、ウェブサービスで発行された第三者で直接に行うことができる。
【００３８】
このように、データ管理ウェブサービスは、システムのモバイルクライアント中でアプリケーションのアップデートおよびデータ変化の展開を管理することができる。それぞれコンポーネントについては、以下、より詳細に説明する。
１．コネクタウェブサービス
コネクタウェブサービスは、いずれのODBC対応データソースかウェブサービスAPIとの通信もサポートするように設計される。コネクタウェブサービスは、顧客に１つ以上の第三者システムに保存されたデータに基づくビューを、定義して構築する。コネクタウェブサービスには、モバイルクライアントからのリアルタイムのデータアクセスと同様に標準の大量のアップデートを許可する発行されたインタフェースがある。
【００３９】
コネクタウェブサービスは、アプリケーションサーバメタアプリケーションと企業データソースの特定のインタフェースとの物理的な層の接続を提供する。コネクタは、データベース紛争管理と通知サービスと、取り扱い管理と、エラー管理をサポートする。デフォルト顧客構成では、モバイル企業プラットフォームシステムはODBCかウェブサービスコネクタで顧客に配布される。当業者は、ジーベルや、SAPや、ピープルソフトや、オラクルや、SQL Serverや、同様のものなどのように、最も一般的な企業システムに、コネクタを生産することができる。
【００４０】
例えば、「オラクル」アプリケーションコネクタは、顧客が持つ、API(PL/SQL手順などのような)に最も近いデータ構成か、またはODBCを通して企業データベース自体に直接に、顧客がオラクルサポートサービスにコールすることを可能にする。ODBCコネクタのすべてを有するので流動的である、査問、RDBMSスキームの流動的な質問は自動的に実行され、データベースの特定の物理設計を暴露する。これはそのシステムへの実際のインタフェースの階層的なビューを顧客に与える。
【００４１】
図３は、コネクタが企業データソースをモバイル企業プラットホームにいかにしてインターフェースするかの例を示す。図３の左側には、複数の企業データソースの表示があり、ERPデータソース302、CRMデータソース304、HR/財務データソース306、レガシー/ODBCデータソース308、および他のウェブサービスか他のソース(不図示)を含むことができる。図３の中央には、メタデータ312が表示され、これは異なった企業データソースからのデータがモバイルクライアント316(これは図３の右に位置する)にどのように保存され、関係するかを、アプリケーションサーバ314に指定する。
【００４２】
したがって、この例では、ORDER_IDとして記されたデータは、ERPデータソースに存在する。 F_NAME(ネーム)およびL_NAMEとして記されたデータは、CRMデータソースに存在する。CRED_LIMとして記されたデータはHR/財務データソース、およびWARRANTY(保証)として記されたデータは、レガシー/ODBCデータソースに保存される。これらの記されたデータのすべてがバックエンドオフィス・システムなどの企業データソースに保存される。
【００４３】
メタデータ312では、企業データソースからのデータ定義は、リレーショナルデータベースの企業データソースからデータ格納をクライアントに作成し、そしてモバイルクライアント上に関連ビジネスデータを保存するのに使用される、ビューに写像される。このビジネスデータへのアクセスは、モバイルクライアントのメタデータに定義され保存していたビジネスオブジェクト層を通して実行される。図３では、ERPデータソースからの注文_IDは、注文IDと呼ばれるビジネスオブジェクト特性に写像され、それの関連定義は、モバイルクライアント316に関するメタデータ318に保存され、またメタデータで定義した１つ以上のモバイルアプリケーションにより利用される。CRM企業データソースからのF_ネームデータがモバイルクライアントデータベースに保存されたファーストネームビジネスオブジェクト特性の定義に写像され(保存され)、そして、L_ネームデータはラストネームビジネスオブジェクト特性に写像される。同様に、HR/財務データソースからのCRED_LIMデータはクレジット_限界ビジネスオブジェクト特性に写像され、そして、Legacy/ODBCデータソースからの保証データは、保証ビジネスオブジェクト特性に写像される。したがって、潜在的に異なり、非互換な異種の企業データソース302、304、306、308、310からのデータは、ローカルデータ格納(企業データソースからアプリケーションサーバ314までのラインで示される)へのデータ管理ウェブサービスを通して、モバイルクライアントへ、モバイルクライアント(モバイルクライアント316内で実際の値で示される)上のビジネスオブジェクトの１つを用い、アクセスのための適切なフォーマットでモバイルクライアントに提供される。
【００４４】
コネクタタイプ
コネクタウェブサービスによってサポートされるコネクタは以下の３つのコネクタタイプを含む。
１．ウェブサービスコネクタは、モバイルプラットホームが第三者システム(非ODBCに従わないか(a)、ODBC/RDBMSの接続性を許可しない(b)または、そのインタフェースが標準のAPIで定義され、そしてウェブサービス 記述子言語(WSDL)により包装され、定義される(c))に接続している時に用いられる。
２．ODBC/RDBMSコネクタは、モバイルプラットホームを第三者システムに接続している時に使用される。その第三者システムは、ODBC に基づく(a)、およびallows for direct ODBC/RDBMSへの直接のアクセスを許可する(b)、および そのデータが、同じLAN環境内に物理的に位置するか、転送をサポートしている通信プロトコル(RPC、TCPなどの)を通じてアクセスできる(c) である。
３．APIがRPCのような非インターネットのプロトコルを通じてアクセスされるべきことを要求し(a)、ウェブサービスインターフェースが利用できないなら用いられる(b)ことを除けば、APIコネクタはウェブサービスコネクタと同様である。
【００４５】
ODBC/RDBMSコネクタを通してスキームをリードして、情報は、管理者アプリケーションを使用して、モバイル企業プラットホームのスタジオ部分130(図１)の使用で達成される。そのスタジオ部分は、バックエンドデータソースに写像するビューの定義を構成するため、および、１つ以上のビューの定義を１つ以上のビジネスオブジェクトに写像するために用いられる。管理者を用いて、ビューの定義を定義するか、またはビューをビジネスオブジェクトに写像するとき、情報はメタデータとして格納される。アプリケーションサーバおよび企業データソースのアップデータプロセスの間、メタデータは、どのようにデータを読んで、固持して、取り除くかを決定する(選択/挿入/アップデート/削除の機能)ためにリードされ、一方、コンフリクト検出/解決、適切である固有および補償の処理のような機能を用いて、データの保全を管理し、実施する。
【００４６】
ODBC/RDBMSコネクタを使用して、データは、ANSI SQLステートメントを通じて、リードされ、固持され、および/または除去され、および/またはマイクロソフト社のSQL ServerかオラクルのRDBMS(8i、9iなど)の場合でANSI SQLステートメント、そして/または、マイクロソフト社のSQL サーバまたはオラクルのRDBMS(8i、9iなど)の場合に手順が格納される。ウェブサービス/APIコネクタを使用して、データは、固持され、そして/または、適したAPI機能をコールするか、処理のための方法により、除去される。
【００４７】
２．構造ウェブサービス
Dexterra スタジオによって消費された構造ウェブサービスは、構成して、管理するために管理者、ビジネスアナリスト、および開発者に簡単な共同利用できる方法を提供し、そして、Dexterraモバイルエンタープライズ解決を管理する。構造ウェブサービスは、データを構成して、カスタム設計するために使用されるメタデータの簡単な操作とモバイルアプリケーションのプロセス定義を許可する。このサービスは管理者コンポーネントの特徴を参照してより理解されるであろう。その特徴は以下で詳細に説明される。
【００４８】
３．データ管理ウェブサーバ
アップデートプロセスモデル
アップデート処理モデルは、システムで利用され、そこでは、モバイルアプリケーションは、簡単な相互運用性のために、ウェブサーバとして提示された１組のコアネットコンポーネントを用いて、それらのローカルの保持データを、バックエンド企業データベースでアップデートする。
【００４９】
データ管理ウェブサービスは、モバイルアプリケーション、および、すべての関連ビジネスオブジェクトの定義されたデータをアップデートする。アップデートプロセスモデルは、Dexterraアプリケーションサーバおよびモバイルクライアントを通して、企業データ格納の間で２方向のデータ転送を可能にし、モバイルクライアントがネットワークに接続されている間、アップデートがなされるのを許可し、それらが接続されている時、クライアント間のアップデートを結合する。切断された状態の時、接続された状態が得られ、そしてアップデート要求が開始できるまで、アップデートは、クライアントの環境で管理される。
【００５０】
アップデートプロセスのモデルは「すべてまたは皆無」のアプローチを取る。全体のストリームがアプリケーションサーバからモバイルクライアントにダウンロードされる前に(または全体のストリームがクライアントからサーバにアップロードされる前に)、失敗が発生したなら、アプリケーションサーバ上のデータ管理ウェブサービスは、ダウンロード処理(または、アップロード)で認証を受信しない。その結果、サーバは、クライアントがデータの後退または単に再試行を必要とするかどうかに関してクライアントの状態を管理するための情報を担う。モバイルクライアントがアップデートプロセス動作を２回目に実行するとき、 アプリケーションサーバは、元の情報の状態を考慮に入れ、そして、アプリケーションサーバが処理したなら結果を提供するか、もしくは、アプリケーションサーバですべての必要な情報を決して受け取っておらず、その結果、信頼できる情報の提供を１回行い、そして１回だけ、モバイルクライアントとアプリケーションサーバとの間で行う時には、データがモバイルクライアントから１個以上のバックエンドデータソースに移行するとき、データの保全を実施する。
【００５１】
アップデート処理のブレークダウン
２つのタイプのアップデート処理がサポートされる。
１：最新を入手: このアップデートのタイプでは、モバイルクライアントは企業データソースからDexterraアプリケーションサーバを通じて最新情報を得ることを要求する。Dexterraアプリケーションサーバは、要求を処理して、そして、Dexterra コネクタウェブサービスを用いて、複数のデータソースから企業情報を検索して、その企業情報をモバイルクライアントに提供する。
２：２通りのアップデート：このアップデートのタイプでは、クライアントとサーバエンドの両方に関する記録は、Dexterra コンフリクト解決の構成されたパラメータを使用して、データの保全を、モバイルクライアントとバックエンド企業データソースの両方に押しつけることで、交換される。
【００５２】
コンフリクトの検出/解決
コンフリクト解決は、モバイルクライアントと１個以上のバックエンド企業データソースの間で行われた変更によって引き起こされたデータコンフリクトを調停するのに使用されるルールについて説明する。これは最初に、コンフリクト(検出)を特定して、次に、１つ以上の様々な方法でコンフリクトを解決(解明)することによって、実行される。
【００５３】
Dexterraアプリケーションサーバは、３つの方法の１つでコンフリクトを検出することができる：Revision(校正)、データ/タイム スタンプまたは、列かコラムレベルでコンフリクト状況を特定するのと同程度に良いマニュアル。
【００５４】
校正は、特定の分野か特性が再想像されるように単一の記録ソースで特定される設定であり、そして、Dexterraアプリケーションサーバは、データがバックエンドデータソースかモバイルクライアントのどちらかで変えられたかどうか決定するために、これを使用するであろう。
【００５５】
日付/タイム スタンプ
日付/タイム スタンプは、 特定の分野か性質が、日付/タイムスタンプとして単一の記録ソースで特定される設定であり、そして、いずれかの挿入/アップデートまたは削除でアップデートされ、そして、Dexterraアプリケーションサーバは、データがバックエンドデータソースかモバイルクライアントのどちらかで変えられたかどうか決定するのにこれを使用するであろう。
【００５６】
マニュアルは、単一の記録ソースでコンフリクトの状況を特定するために特定のフィールドまたは特性が全くない設定であり、従って、Dexterraアプリケーションサーバは、ユニークさを定義するためにすべてのフィールドまたは特性のデータを比較し、そして、バックエンドデータソースまたはモバイルクライアントのどちらかでデータが変化したかを検出する。
【００５７】
Dexterraアプリケーションサーバの構成によって、コンフリクトは４つの方法の１つで解決される：最初のアップデートで取得、最後のアップデートで取得、管理者の解決またはサーバ側のルール。
【００５８】
最初のアップデートで取得
最初のアップデートモデルでは、アプリケーションサーバは、アップデートをする最初のものであるどんな記録の変化も受け入れるだけであろう。記録がバックエンドデータソースにより最初にアップデートされ、そして、エラーをリターンする代わりに、コンフリクトがアップデートウェブサーバによって検出されるなら、Data管理ウェブサービスは、クライアントによって提供されたバージョンを下げて、バックエンド企業データソースからの記録の最新版のコピーを、モバイルクライアントに戻す。
【００５９】
最後のアップデートで取得
最後のアップデートで取得のモデル下では、サーバはコンフリクトを検出する必要はない。代わりに、それは単にモバイルクライアントから、バックエンド企業データソース内にて、現在の記録を上書きするバックエンド企業データソースへの変化を固持する。
【００６０】
管理者(またはマニュアル)解決
管理者/手動の解決のために構成された時、サーバは、解決するためにマニュアルの介入を必要とするとしてすべてのコンフリクトを扱い、そして、バックエンド企業データソースからの現在の記録を戻し、そして、コンフリクトの状況が起こり、Dexterra 管理者を通して解決を可能にする、あらゆる通知サービス(SMS、Emaiなど)で任意に通知する。管理者が、値を選択的にバックエンド企業データソースへ再度戻すために決定するので、そのようにすることはコラムレベルのコンフリクト解決を可能にする。
【００６１】
サーバ側ルール
あるコンフリクト状況がどのように解決されるべきであるかをよりプログラムに基づいて、かつ明確に決定するために、カスタマイズ可能なサーバ側ルールを作成することができる。例えば、コンフリクトは記録のデータの値に基づいて解決されてもよい。この柔軟性は、コンフリクト解決シナリオを囲む特定の動作の完全な制御を可能にする。
【００６２】
サーバからのクライアント展開
アプリケーションサーバは、モバイルクライアントにダウンロードされることになっている１つ以上のモバイルフィールドアプリケーションの定義を含み、タスクとして表されたフォーム/スクリーン(フォームフローと呼ぶ)、データ相互作用(フィールドフローと呼ぶ)、および、ビジネスプロセス/ワークフローに組み立てられるフォームフローとフィールドフローのグループ(フォースフローと呼ぶ)を含む。そのフォームフロー、フィールドフローおよびフォースフローを以下詳しく述べる。また、アプリケーション定義は、ビュー、ビジネスオブジェクト、ビジネス定数の定義などのアプリケーションに関連づけられた構成されたメタデータを含む。また、展開に含まれているのは、モバイルクライアントを「時折」接続された状態で実行させることが必要な１つ以上のバックエンド企業データソースからの特定のビジネスデータである。
【００６３】
アプリケーションサーバは、アプリケーションを提供して、管理し、そして、既存の企業データソースおよびシステムに接続する基礎を提供する。モバイル企業プラットホームアプリケーションは、アプリケーションサーバによって、ポケットPC、タブレットPCデバイスのようなモバイル機器に分配され、そして管理され、フィールド内のすべてのユーザの非常に管理しやすい管理者を提供する。
【００６４】
Ｃ．管理者コンポーネント
上記で気付くように、管理者のコンポーネント(図１)は、システム管理者が比較的通常の、または、頻繁な変化を実行することを可能にする。管理者のコンポーネントは、決定変数、ドロップダウンリストのコンテンツ、および他の情報へのアクセスを、ビジネスアナリストか管理者にとって、管理するのが適切であるフォーマットで提供する。管理者へのこのアプローチは、システム保全に妥協することなく、システム管理者は多くの機能を管理者レベルまで広げます。
【００６５】
例えば、企業のビジネスプロセスを定義するのに使用される企業情報を含むデータを、ビジネスオブジェクトの定義フォームを通して、受け取ることができる。構成ウェブサービスは、管理者のコンポーネントのこの態様へのアクセスを提供する。
【００６６】
図４は、管理者コンポーネントアプリケーションのビジネスオブジェクトのウィンドウのためのスクリーンディスプレイである。このアプリケーションは、システムの「スタジオ」部分130の一部としてコンピュータデスクトップで作成される(図１)。図４は、顧客管理者がビジネスオブジェクトのリストから選ぶかもしれないスクリーンページを示し、そして、選択されたビジネスオブジェクトに記述を供給するかもしれない。選択されたビジネスオブジェクトのための特性もリストから選択されるかもしれない。このように、使用しやすいインタフェースは、モバイル機器にインストールされるアプリケーションを、構成して、変更するために備えられる。
【００６７】
セキュリティの管理
システムと管理者コンポーネントの設計は、ユーザを加算し変更するための機構を与えるセキュリティ管理特性をサポートし、既存のディレクトリサービス、および/または、LDAPかアクティブ ディレクトリサービスを、「２層化された」でセキュリティモデルに統合する。そして、セキュリティ管理は、だれのクライアントが認証されたかを決定するために、認証プロセスで受信された情報に基づくクライアントを「認証」する。アプリケーションがクライアント上で安全であり(アクセスのためにユーザ名/パスワードを必要とする)、そして、ダウンロードされたデータはクライアント上で安全であり、そしてシステムアクセスが(SQL CEインタフェースを介して)制御されているので、したがって、高いレベルのセキュリティを提供する。システムがデスクトップ構成を通して組み込まれた「デバイス無能化」プロセスがあります、そして、ユーザはデバイスアプリケーションおよびデータへの禁止されたアクセスであるかもしれない。さらに、監査の目的のためにシステムに組み込まれたかなりの量のヒストリィ追跡、ロギング、および測定基準がある。セキュリティの他のモデルはサポートされ、IIS 認証サポートおよびDB/第三者システムレベルセキュリティ/認証、安全ソケット層(SSL)全体を含む。
【００６８】
図５はスタジオコンポーネントの一部である管理者アプリケーションのグループウインドウのためのスクリーン表示を示す。図５で示されるように、モバイル企業プラットホームによってサポートされた構成管理は、セキュリティが管理されるグループを定義することを許可し、そしてRole Basedモデル内で、定義されたグループに対する管理者の識別を許可する。最後に、各グループに関して、リストから管理許容レベルを選択することができる。したがって、構成サービスアプリケーションのこのページはセキュリティ機能を管理する便利な手段を提供する。
【００６９】
セキュリティの設定
既存企業アプリケーションとデータ格納への高速、効率的で信頼できる接性はシステムの操作に重要である。アプリケーションサーバは、ジーベルシステムやオラクルシステムなどの既存企業データソースおよびインストールされたソフトウェアアプリケーションとの、または、社内のカスタム開発されたシステムとの高速の統合のためのサービスを提供する。
【００７０】
図６は、管理者コンポーネントのセキュリティ設定ウィンドウのためのスクリーンディスプレイを示す。それぞれの企業データソースに関しては、セキュリティ設定ウィンドウは、そのようなデータのクライアントデータ格納への対応するモバイルクライアント情報だけでなく、管理者がサーバ名とアクセス接続ストリングを定義するのを可能にする。認証、承認、および同期データ設定などのセキュリティy設定ウィンドウを通して他のセキュリティ設定を指定することができる。
【００７１】
パフォーマンスモニターは、アプリケーションサーバと他の管理機能性の性能を目に見えることを許容するためにサポートされる。性能モニターは、エラーロギング能力を含む。
【００７２】
図７は、管理者コンポーネントのメトリックス ウィンドウのためのスクリーン表示を示し、ロギングのために選択することができるシステム性能測定基準のタイプを示す。例証されるように、ウェブサービスを選択して、構成することができ、コネクタは、指定されることができ、そして、ログインおよび同期化動作は、トラッキングのために選択できる。
【００７３】
Dexterraスタジオ開発者
「Dexterraスタジオ開発者」と呼ばれる特徴は、プログラマがモバイルアプリケーションへの変化を実行する。図示した具体化では、Dexterraスタジオ開発者は、プラグインとしてマイクロソフトVS.NET Integrated Development Environment(IDE)にヴィジュアルスタジオオートメイション(Visual Studio Automation)を使用することで配布される。Dexterraスタジオ開発者は、スクリーンを開発して、作業フローを定義して、マイクロソフト社VB.NETかC#などの一般的な開発環境と言語を使用することでビジネス規則を実施するユーザインターフェース要素を作成する、強健で、オブジェクト指向のワークスペースを、プロフェッショナルサービスとエンジニアリング要員に提供する。一連の設計者は、このアプリケーション開発プラットホームのパワーを減少させないでアプリケーション開発の特定のステップを通してユーザに対しガイドすることを支援する。これらの設計者は、定義されたメタデータを束ねるフォームとステップを作成するのを支援し、プログラマが構成ウェブサービスを使用して、ランタイムのときにDexterraアプリケーションサーバと有効に対話する。それにより、急速であるか頻繁な変化を必要とするかもしれないどんな管理情報かバックエンド構成のシステムの柔軟性とパワーも広げている。
【００７４】
Ｄ．クライアントコンポーネント
上で述べたように、企業プラットホームアーキテクチャのクライアント102(図１)は、モバイルアプリケーションが"フォースフロー"、"フィールドフロー"、および「フォームフロー」と呼ばれた技術を用い、役割ベースのビジネスプロセスの使用を許すフレームワークを提供し、そして、Webサービスを用い、その結果、ワイヤードでワイヤレスの接続を通じてインターネットなどのLAN/WANネットワーク上でモバイルクライアントと、Dexterraアプリケーションサーバと企業データソースとの通信を可能にする。クライアントデバイスで動くモバイルアプリケーションは、例外を提供する小さい形状因子デバイスのために最適化される方法で機能し、ユーザの経験を学習するのが簡単になる。
【００７５】
図示したシステムでは、クライアントは、メタデータを意識しているマイクロソフト社の「.NETのコンパクトフレームワーク」を用いて構築されたオブジェクトフレームワークである。クライアントコンポーネントは、モバイル機器における企業クラスアプリケーションの機能性の供給を可能にし、そのモバイル機器は、望ましくは、"PocketPC"オペレーティングシステムか、マイクロソフト社からのマイクロソフトTablet PCオペレーションシステムによって動作する。また、クライアントコンポーネントは、PocketPCインタフェースのCalendar、Task、およびTodayスクリーンの機能性をシームレス統合に提供するために既存の"PocketPC"の機能性と統合される。その結果、それは働くために安定して、有効な環境を提供する。
【００７６】
フォームフロー、フィールドフロー、フォースフロー
ディスプレイ画面のフォームにおけるいずれのビジネスプロセスタスク、ステップまたは操作も「フォームフロー」と呼ばれる。フォームフローは、ビジネスプロセスの開始を許容する「フィールドフロー」と呼ばれるプロセス相互作用を開始するのに用いられ、これは“フォースフロー”と呼ばれる。フィールドフローは、実世界の柔軟性をビジネスプロセスにもたらすためにフォースフローを「バンド外へ」進める。
【００７７】
フォームフローは３つのカテゴリに分解される: (1) 情報; (2) 活動; (3) そして、アップデート。情報のフォームフローは、ビジネスプロセスによる次の論理的なタスクを実現させるためにモバイルユーザにより要求された情報を示すスクリーンである。アクティブティのフォームフローは、何かするか、ユーザが行うか実行することを必要があるかもしれないなにかを示すスクリーンである。アップデートのフォームフローは、モバイルユーザがホストアプリケーション(企業データソース)に返されるデータを入力するようにうながされるとき表示されるスクリーンである。
【００７８】
例えば、一部が失敗したかもしれない時、そして、目録データベースの検索が、解決に対していずれかの整合する部分または同様な問題が存在し、かつ利用できるかを調べるために、目録データベースの検索が実行されるべきことが必要な時(参照と呼ばれる)、フィールドフローが必要であるかもしれない。または、フィールドフローは、一部が、命令されるか、または割り当てられる必要があるかもしれないとき、または配送のためにクライアントに予定されるかもしれないとき、必要である。アップデートと呼ばれるフィールドフロー。
【００７９】
フォースフローは、ビジネスプロセスであり、したがって、フォームフローとフィールドフローの集合である。フォースフローに関する例は、時間と、旅行と、仕事か発信イベントに関連している費用記録である。
【００８０】
戻って図２を参照すると、このブロック図は、ターゲットのアプリケーションでのコラムとフィールド間の関係が、フォームフロー内の情報といかに関係し(アプリケーション内のフォームとして示されたビジネスプロセスのステップ)、そして、フォースフローといかに関係するかを示す。１つのフォームフロー内に多くのビジネスノブジェクトがあり、そして、あらゆるビジネスプロセスに１つ以上のフォームフローが潜在的にある。
【００８１】
モバイルアプリケーションで参照すると、フィルタは、特性および状態がデータに置かれるべきであることを許容する。例えば、データタイプ型(例えば、データ)、有効なタイプ(例えば、月曜日から金曜日だけ)、およびいずれかのコンフリクト状態も検出されるかもしれない。 他のフィルタの特性と状態を構成することができる。
【００８２】
ビューは、１つ以上のビジネスオブジェクトでの使用のために、データおよび格納位置を定義し、そして、ビジネスオブジェクトは１つ以上のビューに基づくことができる。これは、追加特性が関連することを許容する。例えば、ビジネスオブジェクトは、一般の顧客の詳細を含む“顧客”として参照されてもよい。その詳細としては、位置、連絡、品目、またSLAや他の属性(アプリケーションが顧客として分類しそうだが、同じターゲットのテーブルやターゲットのアプリケーション内に保持されることはない)である。
【００８３】
５．オペレーションおよびユーザインターフェース
リアルタイムで企業データソースからビジネス情報を処理するために、モバイル企業プラットホームの操作は、モバイルクライアントのエンドユーザがいかにしてモバイルアプリケーションを利用し、そしてアプリケーションサーバと通信するかについての以下の記述を参照することでよりよく理解されるであろう。以下の例は、フィールドサービス技術(修理)などのような、フィールドサービスアプリケーションを備えるモバイルアプリケーションのための操作を例証する。
【００８４】
初めに、エンドユーザ(フィールドサービス技術者)は、営業日の始まりかサービス走行の開始にて、モバイルアプリケーションを開始し、そして業務通話発信情報および同様のものをダウンロードするアップロード操作を開始するであろう。アップロード操作の間、アプリケーションサーバは、モバイルクライアントが、モバイルアプリケーションの操作および最新のセットのタスク(フィールドサービスのコール)に必要なアプリケーションデータおよび企業情報を含むことを確実にするであろう。上で述べたように、企業情報はさまざまな異なった企業データソースから来るかもしれない。企業情報は、訪問されるべきで顧客、修理されるべきである製品、修理に必要であるかもしれない部品、および同様のものを含むかもしれない。アップデートが実行された後、クライアントアプリケーションの操作のために、ネットワーク接続(ワイヤードまたはワイヤレス)の必要は全くない。
【００８５】
図８は、モバイルクライアントからのディスプレイ画面802の図示であり、アップデート操作が実行された後にモバイルアプリケーションで生成される「待ち行列」ページを示す。 待ち行列のページはモバイルアプリケーションのフォームフローを表す。待ち行列のページは、だれがサービスコールを要求したかを顧客の修理待ち行列を示す。
【００８６】
フィールドサービス技術者が修理待ち行列で記載されている顧客へ到着したとき、その顧客は待ち行列ページの表示から選ばれます、そして、図９の表示ページの「着手」表示ボタンで矢のカーソルによって示されるように、次の営業活動が着手される。この操作は、図１０で例証された「概観」表示ページなどのように、別の表示ページ(ビジネスプロセスの一部としてフィールドフローを通して指定された異なったフォームフロー)を始めることができる。概観ページは、他の表示(他のフォームフロー)を選択することができ、モバイルアプリケーションのダウンロードされたメタデータで再度決定される、ページである。例えば、概観ページは、サービス技術者がこの顧客が申し込んだサービスのレベルを決定することを許可することができる。図１１で例証された「製品ヒストリ」表示ページを開始するために、「情報」表示ボタンを選択することができる。製品ヒストリページは、製品が調整されるために情報を示す。「ビュー」表示ボタンを選択することによって、見るために完全な製品ヒストリを呼び出すことができる。一方、フォースフロー情報およびモバイルクライアントに保存された関連データ(フィールドフロー、フォームフロー)により、ディスプレイページのこの系列が決定される。
【００８７】
サービス技術者が、どんな動作が修理を実現するのに必要であるかを決心したとき、別の表示ページでその動作を記録することができ、図１２で“詳細”ページとして例証される。図１２の表示ページの下部の「部品」のように、他の表示ボタンを選択することによって、修理部品を注文するなどのように、他のサービス動作を開始することができる。
【００８８】
図１３は「部品」表示ページを示し、サービス技術者は、適切な修理部品を注文するためにそれを使用することができる。すべての前述のデータ相互作用(製品ヒストリ、部品情報、注文フォーム)がネットワーク接続なしでサービス技術者によって生成されて、ナビゲートされて、対話されるのに注意されるべきである。すなわち、アップデート操作に続いて、モバイルアプリケーションのためにネットワーク接続が働く必要は全くない。
【００８９】
業務コールの完了のときに、技術者(モバイルユーザ)は修理のための経過時間などの業務通話情報を入力することができる。模範的データ収集のディスプレイページは図１４で示される。また、図１５で例証されるように、モバイル機器は、収集が顧客署名か業務通話の他の承認をサポートすることができる。
【００９０】
最終的に、修理を実行したフィールドサービス技術者は結局、業務通話の完成の後に、ネットワークへの無線接続がもう一度可能である地理的な位置に到着するであろう。モバイルアプリケーションは、自動的にデータ変化をアプリケーションサーバにアップロードすることに加わることができる。そのデータ変化は、訪問された顧客、修理診断、注文部品および顧客データ収集のごとき、技術者によって入力されたすべてのデータを含む。次に、図１６で例証されるように、待ち行列の表示をアップデートし、そして、技術者はサービス待ち行列における次の位置に進むことができるであろう。
【００９１】
したがって、モバイルアプリケーションは、インターネットなどのようなネットワークに(ワイヤレス)接続されたとき、操作上のデータをダウンロードすることによって、効率的に動作することができる。モバイルアプリケーションのビジネスプロセスは、その後、切断している状態、ネットワーク接続が無料の状態で、実行できる。接続が回復したとき、データアップロードを達成することができる。ネットワークに接続されたとき、アプリケーションサーバにて、接続を通じリアルタイムで企業データソースからデータを受け取り、またはそこへアップロードする。企業データソースからのデータは、直接モバイルクライアントによって決してアクセスされず、またモバイルクライアントにネイティブの形式では決して保存されないが、モバイルアプリケーションの目的のために構成されるように、モバイルクライアントのリレーショナルデータベース店にむしろ保存される。
【００９２】
モバイルクライアントのための初期運転は、モバイルアプリケーション自体がロードされて、インストールされる前に、アプリケーションを選択し、モバイルデバイスにダウンロードするために、アプリケーションソーバに最初の要求を行う。アプリケーションサーバは、フィールドセールからフィールドサービスまでどんなアプリケーションもサポートして、修理することができる。モバイルクライアントがアプリケーションを受け付けるとき、それはモバイルアプリケーションを作るメタデータおよび関連データファイルを受け取る。要求をアプリケーションサーバに位置するWebサービスに行うことによって、データをダウンロードする。標準のHTTP要求で伝えられた、シンプル オブジェクト アクセス プロトコル (「SOAP」)を使用することで、ウェブサービスへの要求をする。そして、その結果は、SOAPを使用してXMLとしてデバイスにリターンされる。クライアントデバイスは、次に、リターンされたXMLを分析して、クライアントデバイスで必要なデータをアップデートする。
【００９３】
モバイルアプリケーションメタデータは、モバイルクライアントデバイスの(例えば、SQL CEデータベース・ファイル)メタデータファイルの中に保存される。上で述べたように、メタデータは、ビジネスデータおよび関連データを備え、アプリケーションおよび、それがどのように反応するかに関する実際の定義である。 ビジネスオブジェクトの特性は、顧客ファーストネームや、ラストネームや、アドレスおよびSSNなどの与えられたビジネスオブジェクトの特定の属性である。また、ビジネスオブジェクトは、オブジェクトの挙動および状態を制御するのに支援するために、ビジネスオブジェクトに適用されるロジックの個々の１つであるビジネスルールを指定する(例えば、プラチナの顧客のために自動的に料金なしで翌日配達を得るための注文を置く)。他のデータは、ビジネス定数データを含み、それは、コントロールを助けて、与えられたビジネスルールに対する結果および評価基準を制御し決定することを支援する。そのルールは、顧客タイプが、翌日配達を得るためにはプラチナ、金、またはシルバーでなければならないルールのようなものである。これらのビジネス定数は、結果を決定するためのビジネスルール内で用いられる。メタデータが非常に正常化されたフォーマットでデバイスへダウンロードされ、次に、保存されたメタデータファイル内へ挿入される。これは、モバイルアプリケーションにより、ビジネスオブジェクトの迅速で簡単な作成を可能にする。
【００９４】
顧客ビジネスデータは、バックエンドシステムで保存された実際のデータであり、そのデータは次にクライアントデバイスにダウンロードされ、そして、その後、顧客データ定義の生成の間に、顧客ビジネスデータファイル内に生成されたテーブルに挿入される。上で述べたように、顧客ビジネスデータは最初に、モバイルクライアントのリレーショナルデータベースへの格納のために、コネクタによって適切なデータフォーマットに変換される。このデータは、モバイルアプリケーションを使用し始め、そして、データをアップデートし、そして、最新のデータをモバイルアプリケーションにダウンロードした最後の時間以降で、アプリケーションサーバで起きた変化だけをダウンロードする、基礎をエンドユーザ(フィールドサービス技術者)に与える。
【００９５】
図１７は複数の企業データソースとモバイルクライアントの間のデータを共有するためにモバイル企業プラットホームの操作を例証するフローチャートである。図１７で示された最初の動作であるフローのボックス1702では、モバイルアプリケーションは、アプリケーションサーバからモバイルクライアントへダウンロードして、インストールする。ダウンロードされた情報は、上述したフォースフロー、フォームフローおよびフォームフローにより例示されるように、ビジネスオブジェクトおよび、対応するビジネスルールを指定するメタデータ、およびビジネスプロセスに対する仕様を含む。
【００９６】
モバイルアプリケーションがモバイルクライアントにインストールされた後に、モバイルクライアントは、アプリケーションサーバと、モバイル企業プラットホーム構成の企業データソースと提携して働くことができる。モバイルクライアントのフィールドサービス技術者などのエンドユーザが、ビジネス情報データを必要とするとき、モバイルクライアントはデータのために要求を企業データソースからアプリケーションサーバに送る。クライアントのデータ要求は、要求されたデータのために企業データ送信端末を特定し、そして、要求されたデータ間の関係する対応を指定するメタデータを含む。この動作はフローチャートのボックス1704によって表される。
【００９７】
ボックス1706によって表された次の動作では、企業データは要求されたデータを含むとして特定された企業データソースから検索される。この動作は、コネクタとアプリケーションサーバのウエブサービススキームを通して実行される。次に、ボックス1708では、モバイルクライアントによって送られたメタデータによって指定された関係に従って、検索されたデータは、企業データソースからの検索されたデータに関係するリレーショナルデータベースフォーマットに変換される。
【００９８】
次に、フローチャートのボックス1710によって示されるように、変換されたデータは、モバイルクライアント内のリレーショナルデータ格納に格納される。モバイルクライアントから逆に企業データ格納へのデータのアップロードデータの場合では、フローのボックス1712に示されるように、アプリケーションサーバは、モバイルクライアントから受け取られたデータを格納のための企業データソースに写像して戻すためにコネクタを適用できる。このように、より効率的な動作のためにスキームに基づくメタデータを用いて、データは、モバイルクライアントと企業データソースの間で一時データ保存の必要性なしで共有される。
【００９９】
この発明の理解を伝えることができるように、この発明は、好ましい実施例の条件で以上のように説明してきた。ここではモバイル企業データシステムに対する構成を特に述べていないが、本発明にそれに対して適用可能である。したがって、この場所に説明された特定の実施例に制限されるようにこの発明を見るべきではなく、むしろこの発明は、モバイル企業データシステムに関して一般に広く適用できることを理解すべきである。したがって、付属クレームの範囲の中にあるすべての変更か、変化か、同等な構成と実現が発明の範囲の中で考えられるべきである。
【図面の簡単な説明】
【０１００】
【図１】この発明に従って組み立てられたモバイル企業プラットホームに対する適切なコンピュータシステム環境のブロック図である。
【図２】図１で例証されたモバイル企業プラットホーム内のデータの論理的なアーキテクチャのブロック図である。
【図３】企業データソースと図１のモバイルクライアントとの結合インタフェースを例証するブロック図である。
【図４】図１の管理者のコンポーネントアプリケーションのビジネス目的のウィンドウのためのスクリーンディスプレイである。
【図５】管理者のアプリケーションのグループのウィンドウのためのスクリーンディスプレイを示す。
【図６】図１の管理者の部品のセキュリティ設定ウィンドウのためのスクリーンディスプレイを示す。
【図７】管理者の部品のメトリックスウインドウのためのスクリーン表示を示す。
【図８】だれがサービスコールを要求したかを顧客の修理待ちの行列に示すために図１のモバイルクライアントで生成される「待ち行列」ページディスプレイの画面を例証する。
【図９】顧客着手操作が開始されている状態で、モバイルクライアントデバイスの待ち行列のディスプレイページを示す。
【図１０】図９の待ち行列から選択されたクライアントに対するモバイルアプリケーションのオーバービューのディスプレイページを示す。
【図１１】モバイルアプリケーションのプロダクト歴史ディスプレイページを示し、サービスされるべきプロダクトの情報を提供する。
【図１２】図９から選択されたサービスコールに対するモバイルアプリケーション詳細なディスプレイページを示す。
【図１３】図９から選択されたサービスコールに対するモバイルアプリケーションのパーツディスプレイページを示す。
【図１４】図９から選択されたサービスコールに対するモバイルアプリケーションのトータルのデータ収集ディスプレイページを示す。
【図１５】図９から選択されたサービスコールに対するモバイルアプリケーションのサインディスプレイページを示す。
【図１６】図９から選択されたサービスコールの完了後のモバイルアプリケーションの待ち行列ディスプレイページを示す。
【図１７】複数の企業データソースとモバイルクライアントの間のデータを共有するためにモバイル企業プラットホームの操作を例証するフローチャートである。
【符号の説明】
【０１０１】
100：コンピュータシステム環境
102：モバイルクライアントデバイス
104：ネットワーク接続
106：アプリケーションサーバ
112：開発者アプリケーション
114：メタデータ
124：サービスアプリケーション
【図１】
2006512695.tif 000003
【図２】
2006512695.tif 000004
【図３】
2006512695.tif 000005
【図４】
2006512695.tif 000006
【図５】
2006512695.tif 000007
【図６】
2006512695.tif 000008
【図７】
2006512695.tif 000009
【図８】
2006512695.tif 000010
【図９】
2006512695.tif 000011
【図１０】
2006512695.tif 000012
【図１１】
2006512695.tif 000013
【図１２】
2006512695.tif 000014
【図１３】
2006512695.tif 000015
【図１４】
2006512695.tif 000016
【図１５】
2006512695.tif 000017
【図１６】
2006512695.tif 000018
【図１７】
2006512695.tif 000019
【国際調査報告】
2006512695.tif 000020
2006512695.tif 000021