(57)【特許請求の範囲】
【請求項１】
第１イベントの後の装置の第１状態の間に、イベントフィルタリング条件をメモリに記録する工程と、
複数の入力された機械生成イベントについて、少なくとも前記イベントフィルタリング条件及び前記装置の前記第１状態に応じて、命令を選択する工程と、
入力用のプロンプトを含むユーザインターフェースを提示する工程であって、前記プロンプトは、前記装置の記述、少なくとも１つの状態遷移条件、及び前記イベントフィルタリング条件を含む、工程と、
整数のカウントパラメータを初期化する工程であって、前記イベントフィルタリング条件に基づいて、前記整数のカウントパラメータを超えた、互いに合致する特徴を持った追加のイベントは無視される、工程と、
前記複数の入力された機械生成イベントについて、少なくとも前記イベントフィルタリング条件、前記整数のカウントパラメータ、及び前記装置の前記第１状態に応じて選択された前記命令を実行するようにワークフローエンジンを構成する工程と、
を含む方法。
【請求項２】
一定の期間中に、入力されたイベントを無視する工程を更に含み、前記無視することは、前記入力されたイベントに対してはワークフロー動作を起動しないことを含む、請求項１に記載の方法。
【請求項３】
前記複数の入力された機械生成イベント及び前記追加のイベントは、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領される、請求項１に記載の方法。
【請求項４】
状態遷移に応じて、前記装置が、前記装置の前記第１状態から前記装置の第２状態に遷移したと判定する工程を更に含む、請求項１に記載の方法。
【請求項５】
前記状態遷移が前記少なくとも１つの状態遷移条件を満足していると判定すると、指定された動作を実行する工程を更に含む、請求項４に記載の方法。
【請求項６】
前記装置の前記第１状態は、オンライン、オフライン、スタンバイ、電力投入、電力切断、ネットワーク接続の範囲の内、少なくとも１つを更に含む、請求項１に記載の方法。
【請求項７】
コンピュータプログラム命令がロードされたメモリと、請求項１〜６の何れか１項に記載の方法を実施するよう構成されている、前記メモリ内に格納された命令を実行する動作が可能な１以上のプロセッサと、を備えたシステム。
【請求項８】
請求項１〜６の何れか１項に記載の方法を実施するためにプロセッサによって実行可能なコンピュータプログラム命令が与えられた非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【優先出願】
【０００１】
本出願は、「THROTTLING EVENTS IN ENTITY LIFECYCLE MANAGEMENT」と題する２０１６年２月１０日出願の米国仮特許出願第６２／２９３，７３８号（代理人整理番号：SALE 1143-1/1686PROV）に基づく利益を請求した、「THROTTLING EVENTS IN ENTITY LIFECYCLE MANAGEMENT」と題する２０１６年８月１８日出願の米国特許出願第１５／２４０，７２９号（代理人整理番号：SALE 1143-2/1686US）に基づく利益を請求している。上記優先権主張の基礎となる出願及び仮出願は、ＰＣＴ規則で許可された全範囲を参照してここに組み込む。
【関連出願】
【０００２】
本出願は、「SIMPLIFIED ENTITY LIFECYCLE MANAGEMENT」と題する２０１５年１１月９日出願の米国特許出願第１４／９３６，１４１号（代理人整理番号：SALE 1130-3/1644US）に関連している。当該関連出願の関連部分は、本出願に全体的に取り込まれる。
【０００３】
本出願は、「SIMPLIFIED ENTITY ENGAGEMENT AUTOMATION」と題する２０１５年１１月３日出願の米国特許出願第１４／９３１，６５８号（代理人整理番号：SALE 1131-3/1645US）に関連している。当該関連出願の関連部分は、本出願に全体的に取り込まれる。
【技術分野】
【０００４】
開示される技術は、一般的に、イベントとして扱われる、ＩｏＴ（Internet of Things）装置からのメッセージを処理するための装置構造に関し、特に、当該構造を実施するステートマシン装置を構築するために、分かりやすく、直観的で、スケーラブルな、容易にコード化できるアプローチを提供することに関する。
【背景技術】
【０００５】
本章で議論される主題は、本章における言及の結果、単なる先行技術と考えるべきではない。同様に、本章で言及された、或いは、背景として提供された主題に関連する課題は、先行技術で既に認識されたものと考えるべきではない。本章における主題は、単に、異なるアプローチを表しているだけであり、それ自体は、クレームされる技術の実施に対応していても良い。
【０００６】
今日の世界では、一般に「ビッグデータ」と言われる膨大なデータ量が扱われている。何百万ものインターネットユーザに応対し管理する、FacebookTM、InstagramTM、TwitterTM、銀行のウェブサイトといったウェブアプリケーション、或いは、Amazon.comTM、eBayTMといったオンラインの小売店さえも、エンドユーザにリアルタイムな体験を提供できるよう、できるだけ早く大量のデータを摂取するという課題に取り組んでいる。
【０００７】
他に、ビッグデータに大きく貢献するものとして、ＩｏＴ（Internet of Things）と呼ばれる概念及び理論的枠組がある。ＩｏＴとは、概して言えば、無線接続及び有線接続を通じて、互いに作用し合い、また、新たなアプリケーション又はサービスを生成する他の物体又は対象と協力することができる多種多様な物体又は対象から成る環境の中で、広く存在するものである。これらのアプリケーション又はサービスは、スマートシティ（地域）、スマートカー及びモビリティ、スマートホーム及び支援された生活、スマート産業、公共の安全、エネルギー、環境保護、農業、観光といった分野に存在する。
【０００８】
現在、こうしたＩｏＴアプリケーション又はサービスは、非専門家にもより利用しやすいものにする必要がある。ＩｏＴエコシステムが、実質的なプログラミング経験を必要とするハイテク製品に依存しているために、これまで、高価値の非技術的な領域の知識を有する非専門家は、ＩｏＴエコシステムの周辺から応援してきた。こうしたことから、高価な技術コンサルタントに頼らずに、独自に、ビッグデータの計算と分析を組み合わせて利用する、非専門家の能力を増加させることが必要となってきた。
【０００９】
開示される技術は、エンティティとの相互作用（interaction）を多段階的に進行させるためのステートマシン装置を構築する宣言的フレームワークにおいて、ローカライズされた状態を提供する。状態のローカライズによって、状態定義、状態遷移トリガー、状態遷移条件、状態遷移動作といった、これまで複雑であったステートマシン装置の様々な要素及び部品を指定する、より単純な規則ベースのオーサリングツールの提供が可能となり、それによって、上記宣言的フレームワークは、広範囲のアプリケーションに対して繰り返し使用できる。一度定義されると、ステートマシンは、非技術者ユーザによって提供された宣言的入力に基づいて、自動的に構築、生成、実施される。
【００１０】
多くの条件がマトリックスを用いて記述することができる。マトリックスには、アプリケーションのエンティティとの相互作用を多段的に進行させるためのプロファイル又はローカル変数に対して、適切なテストを記述することで生成されたイベントが含まれる。プロファイルには、オーケストレーションの対象についての現在の情報が含まれる。マトリックスは、一方で、以前は明示的な状態によって定義された状態定義、状態遷移トリガー、状態遷移条件、状態遷移動作に関連する大多数の条件を対象としつつ、ステートマシンのフォームを縮小するために、スロットル（throttling）、統合イベント、及び、プロファイル及びローカル変数に対して記述されたテストを組み合わせることができる。一度定義されると、イベント、プロファイル、状態の組み合わせは、非技術者ユーザによって提供される宣言的入力に基づいて自動的に生成及び実施されるステートマシンを単純化する。
【００１１】
したがって、ビッグデータの計算及び分析タスクを実行するために、単純、容易にコード化可能な宣言的言語ベースの解決法を使用する、システム及び方法を提供する機会が生じる。収益の増加、ユーザの定着率の増加、ユーザの関与及び経験の向上が得られる可能性がある。
【発明の概要】
【００１２】
詳細な説明及び付随する図面で後述する、典型的な、限定されない実施例の様々な側面について、基本的又は一般的な理解を助けるために、簡単な概要をここに述べる。ただし、本概要を広範囲に亘る又は網羅的な概観とすることは意図していない。代わりに、本概要の唯一の目的は、以下に続く様々な実施例のより詳細な説明に対する前置きとして、簡単な形で、幾つかの典型的な限定されない実施例に関して、幾つかの概念を提示することである。
【００１３】
これらの技術的な課題に対処するために、開示される技術は、エンティティとの相互作用を多段階的に進行させるためのステートマシンを実施する宣言的フレームワークを提供する。宣言的フレームワークは、状態定義、状態遷移トリガー、状態遷移条件、状態遷移動作といった、複雑なステートマシンの様々な要素及び部品を指定するために使用可能な簡単な規則ベースのオーサリングツールを提供することから、広範囲のアプリケーションに対して繰り返し使用できる。一度定義されると、ステートマシンは、非技術者ユーザによって提供された宣言的入力に基づいて、自動的に生成及び実施される。
【００１４】
開示される技術には、人間−機械の相互作用に依存せずに機械によって生成された機械生成イベントを処理するワークフローステートマシンにおいて、複数のケース−ステータス状態でケース−ステータス状態を表示することと、及び、第１イベントの後の少なくとも第１ケース−ステータス状態の間に、入力された第２イベントを無視するか、又は、処理するかを決定するイベントフィルタリング条件をメモリに記録することが含まれる。また、本技術には、イベントフィルタリング条件の、一定の期間内の回数に制限を指定する整数のカウントパラメータであって、当該制限を超えた、合致する特徴を持った追加のイベントは無視又は放棄され、当該カウントパラメータを初期化すること、入力された機械生成イベントを処理する命令をワークフローエンジンにロード（load）すること、ケース−ステータス状態及びイベントフィルタリング条件に応じて選択された命令を実行することも含まれる。
【００１５】
開示される技術の他の側面及び利点は、以下に続く図面、詳細な説明、請求項に見ることができる。
【図面の簡単な説明】
【００１６】
図面では、類似する参照符号は、一般に、様々な図に亘って同じ部品を参照している。また、図面は、必ずしも縮尺通りでなく、むしろ一般に、開示される技術の原理を表現することに重点が置かれている。以下の説明では、開示される技術の様々な実施例を、以下の図面を参照して述べる。
【００１７】
図１は、典型的なＩｏＴプラットフォームを示す図である。
【００１８】
図２は、開示される技術の一実施例に従って、図１に示す典型的なＩｏＴプラットフォームの例に類似した、ＩｏＴプラットフォームによって使用されるストリーム処理フレームワークを示す図である。
【００１９】
図３は、エンティティとの相互作用の自動的な多段的処理を実施するステートマシンの一実施例を示す図である。
【００２０】
図４Ａ、図４Ｂ、図４Ｃは、図３に示すステートマシンを作成するための宣言的入力を受け付けるデータエントリカラムナ（data entry columnar）の例を示す図である。
【００２１】
図５Ａ、図５Ｂ、図６Ａ、図６Ｂは、図３に示すステートマシンに対するスロットル規則を追加するための宣言的入力を受け付けるデータエントリカラムナの例を示す図である。
【００２２】
図７は、図４Ｂのデータエントリカラムナの例に追加されるスロットルの例を示す図である。
【００２３】
図８Ａは、非プログラミングユーザ向けの、一定の期間内に発生する指定された数のイベントをフィルタリングするために、機械生成イベントを処理するケース−ステータス状態を用いて、エンティティ管理ワークフローの作成を単純化するフローチャートの実施例を示す図である。
【００２４】
図８Ｂは、非プログラミングユーザ向けの、エンティティ管理ワークフローの作成を単純化するフローチャートのサーバ側の実施例を示す図である。
【００２５】
図８Ｃは、非プログラミングユーザ向けの、エンティティ管理ワークフローの作成を単純化する典型的な方法のクライアント側の実施例を示す図である。
【００２６】
図９は、非プログラミングユーザ向けの、１回のみの期間内で、エンティティ管理ワークフローの作成を単純化する典型的な方法の実施例を示す図である。
【００２７】
図１０は、開示される技術の１以上の実施例に従って、図１のＩｏＴプラットフォームとの統合に適した典型的なマルチテナントシステムのブロック図である。
【００２８】
図１１は、ワーカーノードの全てのプロセッサコアを利用する複数の物理スレッドを含むワーカーティア（worker tier）における、ワーカーノードの一実施例を示す図である。
【００２９】
図１２Ａ、図１２Ｂは、利用可能な物理スレッドのカウントが論理的並列スレッドの設定数と等しい又はそれを超える場合、パイプライン内のバッチを同時に処理する一実施例を示す図である。
【００３０】
図１３Ａ、図１３Ｂ、１３Ｃは、利用可能な物理スレッドが論理的並列スレッドの設定数未満の場合、パイプライン内のバッチを順番に多重化（multiplex）する一実施例を示す図である。
【００３１】
図１４は、バッチの多段階的処理の一実施例を示す図である。
【００３２】
図１５は、準リアルタイム（ＮＲＴ）データストリームの多段階的処理における強力な順序付け（strong ordering）を提供するフローチャートの一実施例を示す図である。
【発明を実施するための形態】
【００３３】
以下の詳細な説明は、図面を参照して行われる。実施例は、開示される技術を説明するために記述されるのであって、請求項によって定義される本技術範囲を限定することは意図していない。当業者は、以下に続く説明について様々な均等物を認識するであろう。
【００３４】
議論は以下のように整理される。まず初めに、本議論を通して使用される専門用語の説明が提供され、次に、様々な実施例によって対処される技術的課題及び提供される技術的解決法の幾つかを記載した序論が述べられる。次に、幾つかの実施例の高次の説明について、構造上のレベルで議論される。また、エンティティ管理ワークフローを実施するステートマシンが説明される。更に、幾つかの実施例で使用されるユーザインターフェースの図が提示される。次に、システムを実施するための、より焦点を絞った動作について、データエントリモデル、遷移トリガー、条件定義と一緒に、議論される。最後に、幾つかの特定の実施例について議論される。
＜専門用語＞
【００３５】
エンティティ：エンティティとは、現実又は物理的世界のイベントに反応すると共に、環境について検知されたデータ及び情報を交換することで、情報の転送、分析、応用、通信に関してサービスを提供するために、他の物体又は対象と、及び、環境と相互作用及び通信を行う物体又は対象として定義される。エンティティの例としては、人間、オンラインソーシャルネットワーク、無線又は有線センサー、スマートフォン、スマートウォッチ、アプリケーション、パソコン、ノートパソコン、タブレット、ＩＰ電話、サーバ、アプリケーションサーバ、カメラ、スキャナー、プリンター、ＲＦＩＤタグやＲＦＩＤリーダー等の近距離通信装置、車両、生物医学機器等が挙げられる。本出願では明瞭にするために、幾つかの実施例において、単数の「エンティティ」及び複数の「エンティティ」が区別無しに使用される。本出願については、幾つかの実施例において、「エンティティ」は、「データソース」、「ユーザ」、及び、その他の行為者である。
【００３６】
ＩｏＴプラットフォーム：ここで開示される「ＩｏＴ（Internet of Things）プラットフォーム」とは、リアルタイム、又は、しばしば少ない待ち時間を伴う準リアルタイムで、複数のエンティティから、大量のデータを収集及び処理する統合された環境として定義される。幾つかの例では、リアルタイム又は準リアルタイムの分析を生成するために、処理ロジックをデータに適用することができる。一実施例では、ＩｏＴプラットフォームは、データマイニング、機械学習、統計的処理、予測分析、時系列分析、規則ベース処理、複雑なイベント処理、パターン検出、相関関係等の計算タスクを行うことで、ストリームモードとバッチモードの組み合わせに対する計算を利用して、バッチ及びオフラインの分析を用いて総計を定期的に生成し、リアルタイムのデータストリームからの結果を置き換え、リアルタイムの分析を生成する統合フレームワークとして定義される。一実施例では、ＩｏＴプラットフォームは、１ノード、１秒毎に、１００万タプル（tuple）の処理オーダーという高スループットを提供する。別の実施例では、ＩｏＴプラットフォームは、標準的なグラフ、棒グラフ、図表、重なり合った解説画像といった、ＧＵＩ及び／又はＡＰＩベースのツールを用いて、豊かな視覚化という形でエンドユーザに識見（insight）を提供する。
【００３７】
準リアルタイムデータストリーム：準リアルタイムデータストリーム（ＮＲＴ）は、エンティティによって生成される時に登録されるイベントの収集物として定義される。一実施例では、ＮＲＴデータストリームは、データタプルの無制限のシーケンスである。幾つかの実施例では、ＮＲＴデータストリームは、１秒あたり１００万イベント又はタプルの発信率を有する。
【００３８】
イベント：イベントとは、出来事についての情報を伝達する識別可能なデータ単位である。一実施例では、イベントは、エンティティに関する情報を提供することもできる。イベントは３つの側面を持つことができる。すなわち、イベントが発生した時を示すタイムスタンプ、イベントについての様々な属性を示す一連の次元（dimension）、イベントに関連する一連の測定基準（metrics）である。イベントは、キー入力、マウスクリック等、その他様々なものが考えられるユーザによって発生されたイベントがなりえる。システムによって発生されたイベントには、統計（例えば、バイト数あたりの待ち時間等）、プログラムの読み込み及びエラー等、その他に様々なものが考えられる。一実施例において、イベントには、ネットワークフロー変数、装置情報、ユーザ及びグループ情報、アプリケーションについての情報（例えば、リソース状態、変数、カスタムトリガーイベント）が含まれる。イベントは、典型的には、ネットワークトラフィック、特定のエラー条件や信号、交差した閾値、累積したカウント等のＮＲＴデータストリーム内で認識可能な、メッセージ、トークン、カウント、パターン、値、マーカーの何れかを表す。PardotTMのようなアプリケーションとユーザの典型的な相互作用は、セッションとの関連で発生する一連のイベントを処理する。注目すべき主なイベントとして次のものがある。（ａ）ログイン―ユーザを認証するため、ホストサービスへユーザ信用証明物（credential）を提供する。（ｂ）アプリケーショントランザクション―一連のアプリケーションレベルのトランザクション（例えば、リード（lead）の追加、又は、新たな動作の定義）を実行する。（ｃ）ログアウト―このイベントは、サーバとのセッションを終了させる。幾つかの実施例では、ディープ・パケット・インスペクションのロジックが、イベントを識別するために生のイベントデータを探知（track）し、それらのイベントデータをイベントレポジトリに格納する。幾つかの実施例では、このアプリケーションは、「イベント」を「データ」、「データ」を「イベント」と、区別無く称する。様々なエンティティによって、又は、様々なエンティティについて生成されたイベントの他の例としては、着用可能なセンサーからの遠隔測定、スマートウォッチからのデータ、（Microsoft WordTM等の）アプリケーションの機能を用いてユーザによって生成されたデータ及び／又はメタデータ、旅を開始する又は完了する運転者によって使用されるＧＰＳから生成された短期又は長期の旅行データ、速度又は位置情報を報告する車両によって生成されるデータ、センサー信号を報告する医療機器によって生成されるデータ等が含まれる。
【００３９】
パイプライン：パイプラインは、一連のグループ化された相互に関連するイベントとして定義される。一実施例では、グループ分けは、タプル・バイ・タイプベース（tuple by type basis）で行われる。別の実施例では、グループ分けは、バッチ毎に（batch by batch basis）行われる。
【００４０】
オンラインソーシャルネットワーク：「オンラインソーシャルネットワーク」は、ユーザの共同体又は個人、及び／又は、他のエンティティが、（インターネット等の）コンピュータネットワークを通じて情報、リソース等を共有できるよう構成された、ソフトウェア、プロトコル及び／又はハードウェアの何らかの組み合わせとして定義される。オンラインソーシャルネットワークは、相互作用、関与、情報共有を育むウェブサイト、ブログ、フォーラムといったプラットフォームを使用する。オンラインソーシャルネットワークの例には、FacebookTM、TwitterTM、YouTube（登録商標）、FlickrTM、PicasaTM、DiggTM、RSSTM、BlogsTM、RedditTM、LinkedInTM、WikipediaTM、PinterestTM、Google Plus+TM、MySpaceTM、BitlyTM等が含まれる。幾つかの実施例では、このアプリケーションは、「オンラインソーシャルネットワーク」を「ソーシャルネットワーク」、「ソーシャルメディアサイト」、「ソーシャルネットワーキングサービス」、「ソーシャルメディアソース」、「ソーシャルネットワーキングエンティティ」と区別無く称し、またその逆もあり得る。
【００４１】
Application Programming Interface：「ＡＰＩ（Application Programming Interface）」は、インターフェースのタイプを含む、一連のクラスに属するコードライブラリ、メソッド及びフィールドのパッケージ化された収集物として定義される。ＡＰＩは、開発者及びプログラマーが、関連するクラスをインポートし、クラスのインスタンス化及びメソッドとフィールドの呼び出しを行う命令文（statement）を記述するだけで、自身のソフトウェア開発に当該クラスを使用することができる方法を定義する。別の実施例では、ＡＰＩは、互いに通信するソフトウェアの構成要素によりインターフェースとして使用されることを意図したソースコードベースの仕様である。ＡＰＩには、ルーチン、データ構造、オブジェクトクラス、変数に関する仕様が含まれる。基本的に、ＡＰＩは、開発者及びプログラマーに、オンラインソーシャルネットワークの基礎となるプラットフォーム性能及び機能にアクセスするためのインターフェースを提供する。例えば、Twitterの検索ＡＰＩは、検索又はユーザ名を通じてTwitterのデータを順次問い合わせ（ポーリング）する。Twitterの検索ＡＰＩは、開発者及びプログラマーに、発生したツィートから既存のデータセットへのアクセスを与える。検索ＡＰＩを通じて、開発者及びプログラマーは、検索基準に合ったツイートを要求する。検索基準は、キーワード、ユーザ名、位置、指定場所等が考えられる。別の例では、TwitterのストリーミングＡＰＩは準リアルタイムでツイートが投稿された時のデータのプッシュ（push）である。TwitterのストリーミングＡＰＩで、開発者及びプログラマーは、一連の基準（例えば、キーワード、ユーザ名、位置、指定場所等）を登録し、ツイートが当該基準に合致する場合、登録された基準は、直接、開発者及びプログラマーにプッシュされる。更に別の例では、Twitter Firehoseが、準リアルタイムでデータを開発者及びプログラマーにプッシュし、設定された基準に合致する全てのツイートの配信を保証する。
【００４２】
アプリケーション：アプリケーションは、ＵＲＬ（Uniform Resource Locator）を介してアクセスされるネットワークホストサービスを指す。例としては、内部のエンタープライズ・アプリケーションと共に、ＳａａＳ（Software as a Service）製品、ＰａａＳ（Platform as a Service）製品、ＩａａＳ（Infrastructure as a Service）製品が挙げられる。アプリケーションの例としては、Salesforce1 PlatformTM、Sales CloudTM、Data.comTM、Service CloudTM、Desk.comTM、Marketing CloudTM、PardotTM、Wave AnalyticsTM、Box.netTM、DropboxTM、Google AppsTM、Amazon AWSTM、Microsoft Office 365TM、WorkdayTM、Oracle on DemandTM、TaleoTM、YammerTM、ConcurTMが挙げられる。一実施例では、アプリケーションは、標準的なグラフ、棒グラフ、図表、重なり合った解説画像といった、ＧＵＩ及び／又はＡＰＩベースのツールを用いて、豊かな視覚化という形でエンドユーザに識見を提供する。
【００４３】
エンティティ体験動作：「エンティティ体験動作」は、通常、熟練オペレータ（例えば、会社、組織）の代わりに、効果的なユーザ管理及びリソースプロビジョニング、アプリケーションのライフサイクル管理、ユーザの関与、トラフィックの監視、活動の探知、アプリケーションのモデリングに関するプロビジョニングを可能とする、編成された取り組み（orchestrated effort）として定義される。
【００４４】
識別（identification）：ここで使用されるように、情報項目の「識別」は、必ずしも当該情報項目の直接の指定を必要としない。情報は、１以上の間接参照（indirection）を通して実際の情報を単に参照することによって、或いは、実際の情報項目を判断するのに十分な１以上の様々な情報項目を識別することによって、ある分野で「識別」することが可能である。また、ここでは、「指定する（specify）」という用語は、「識別する（identify）」と同じ意味で用いられる。
【００４５】
物理スレッド：一度配置（deploy）されると、コンテナは、一連の所謂「物理スレッド」を操作する。物理スレッドは、ワーカーノードのプロセッサコアを利用し、当該ワーカーノードに割り当てられる一連のコードプロセス（例えば、Ｊａｖａ（登録商標）プロセス）を内部で実行する。ただし、１コアにつき、物理スレッドは１つのみである。また、物理スレッドは、コンテナの様々な要素及び部品（例えば、エミッタやトランスフォーマー）に対して、一連のタスク又はジョブのロジックを実行する。
【００４６】
ロングテールタスクシーケンス：「ロングテールタスクシーケンス」とは、タスクシーケンスの開始時は適切なサイズであるが、タスクシーケンスが減少するにつれて、過剰となった専用のコンピュータリソースを消費するタスクシーケンスのことである。ロングテールタスクシーケンスの例として、スーパーボウル（Super Bowl）の間に、ゲーム会社から空想のアメリカンフットボールのゲームのトークンが提供されることが挙げられる。スーパーボウル後に空想のアメリカンフットボールへの需要が徐々に減少すると、ゲームトークンの使用も減少する。その結果、電子的にイベントとして受領される、ゲームトークンの買戻し要求数も減少する。しかし、ゲーム会社は、スーパーボウル後、長期間に亘って徐々に買い戻される未使用のトークンを依然として受け入れる。この延長された中休み（lull）は、スーパーボウル中に急増した程にはコンピュータリソースを必要としないことから、ロングテールタスクシーケンスの特徴となり、最初の割り当てよりも少ないコンピュータリソースで動作することが可能となる。
【００４７】
エミッタ：データは、所謂「エミッタ」を経由してコンテナに入る。エミッタは、コンテナのためのイベントタプルのソースであり、イベントタプルをコンテナに取り込む役割を担っている。一実施例では、エミッタは、入力待ち行列からイベントタプルを取り出す。幾つかの実施例では、エミッタは、ユーザ指定の変換機能を備え、入力待ち行列からバイト列を消費し、それらをタプルとして下流のトランスフォーマーに転送する。エミッタは、ワーカーノードの１以上の物理スレッドによって実行される１以上のタスク又はジョブを回収（retrieve）する。
【００４８】
トランスフォーマー：トランスフォーマーとは、コンテナで入力されたイベントタプルを処理し、それをコンテナ内の下流に位置する次の一連のトランスフォーマーへ引き渡す、コンテナの計算装置である。トランスフォーマーは、１以上のタスク又はジョブを下流に引き渡し、典型的には更に変形（transform）されてワーカーノードの１以上の物理スレッドに渡される。
＜序論＞
【００４９】
非プログラミングユーザ向けの、エンティティ管理ワークフローの生成を単純化するシステム、及び、様々な実施例を説明する。特に、開示される技術には、人間−機械の相互作用に依存せずに機械によって生成された機械生成イベントを処理するワークフローステートマシンにおいて、複数のケース−ステータス状態を表示することが含まれる。当該ケース−ステータス状態の内、（第１イベント後の）少なくとも第１ケース−ステータス状態の間に、入力された第２イベントを無視するか、又は、処理するかを決定するイベントフィルタリング条件がメモリに記録され、イベントフィルタリング条件の、一定の期間内の回数に制限を指定する整数のカウントパラメータが初期化される。当該制限は、それを超えた互いに合致する特徴を持った追加のイベントが無視又は放棄されるというものである。また、開示される技術には、入力された機械生成イベントを処理する命令をワークフローエンジンにロードすること、少なくともケース−ステータス状態及びイベントフィルタリング条件に応じて選択された命令を実行することも含まれる。
【００５０】
ＩｏＴ（Internet of Things）は、インターネットの新しい革命である。物体又は対象が、自身を認識可能にし、自身についての情報を通知できることで、内容に関連した決定を行う又は可能にすることによって、知能を獲得する。ＩｏＴは、ビッグデータを基礎に構築される。PigTMのようなビッグデータの計算及び分析システムは、広範囲に亘るプログラミング技術を持ったソフトウェア技術者向けに設計されているが、多くの組織では、ビッグデータの計算及び分析は、コード開発者以外の領域専門家（例えば、マーケティング担当者、ＣＥＯ、営業担当者）といった多くの個人にとってアクセス可能である必要がある。加えて、大半のユーザには、ビッグデータを基に完全に開発されたワークフロープロセスを記述する時間がない。
【００５１】
また、エンティティライフサイクル管理動作を実施する現在のＩｏＴアプリケーションは、技術者によって他の技術者向けに開発されることが多く、非技術者ユーザにとっては複雑である。その結果、形式的手法の経験がほとんど無いプログラマーにとって、現在のＩｏＴアプリケーションの有用性は非常に限られている。更に、ほとんどの営業用又は研究用のＩｏＴによる解決法は、柔軟性のあるフレームワークというよりはむしろ、単なるアプリケーションであり、様々な状況及び様々な目的のために使用するには、広範囲に亘る再プログラミングが必要とされるため、本来的にはコード構築を目指すものである。
【００５２】
こうした技術的課題に対処するため、開示される技術は、エンティティとの相互作用を多段階的に進行させるためのステートマシンを実施する宣言的フレームワークを提供する。上記宣言的フレームワークは、状態定義、状態遷移トリガー、状態遷移条件、状態遷移動作といった複雑なステートマシンの様々な要素及び部品の規定に使用できる単純な規則ベースのオーサリングツールを提供するため、広範囲のアプリケーションに対して繰り返し使用可能である。一度定義されると、ステートマシンは、非技術者ユーザによって提供された宣言的入力に基づいて、自動的に生成及び実施される。
【００５３】
今日の我々の世界は、世界経済の各分野を流れるデータのストリームによって生成されるバイナリコードを構成する１と０で成り立っている。それはどれぐらいのデータだろうか？
【００５４】
ＩＢＭによれば、２０１２年では、毎日２．５エクサバイトのデータが生成された。それは、１日で２５億ギガバイトのデータである。Facebook単独でも、同年で、１日あたり５０万ギガバイトのデータに関与している。データの重要性はますます大きくなっており、米国政府も、データへのアクセスを支援及び分析するために、率先してData.govを開設した。良いニュースとしては、データ処理及び格納費用が、過去十年と比べて１０００倍以上減少したことである。しかし、データは一旦格納されると、取り出して使用することが困難である。
【００５５】
こうしたデータの全てはどこから来るのか？明らかな発生源は、昔ながらの記録システム（systems of record）から生成されたデータである。また、新しいビジネス応用モデルであるＳａａＳ（Software as a Service）の急速な適応に見られるように、クラウドソフトウェアからのデータもある。
【００５６】
また、携帯電話、携帯機器、及び、単に物理的世界で監視できる全てのものに設置されたセンサーから、毎秒生成されるデータもある。更に、ソーシャルメディアは最も大きなデータストリームを表しており、それは天文学的な量で生成されている。
【００５７】
文字については忘れて、YouTube、Facebook、Instagram、Twitterといった一般向けのサービスにスマートフォン経由でアップロードされた写真及び動画の全てについて考えてみる。
【００５８】
スマートフォンは、現在、こうしたデータの津波の最も有力な原因である。パソコン及びフィーチャーフォン（スマートフォンではない携帯電話）はどちらも減少し、スマートフォンが、サハラ以南のアフリカでさえ、反対に増加している。そして、スマートフォンのある所にはアプリケーションがある。アプリケーションは実際的に全ての人間の活動（endeavor）のためにある。
【００５９】
アプリケーションは、人間の指、カメラ、運動センサー、ＧＰＳアンテナ、Bluetooth（登録商標）アンテナ、ジャイロスコープによって生成される全てのリアルタイムのデータストリームに対するスマートフォンの制御点である。スマートフォンのメーカーが、より多くのセンサー及び機能をこれらの装置に詰め込み続ける一方で、開発者は、我々全てを喜ばせるアプリケーションを構築し続ける。
【００６０】
２０１５年時点で、成人人口の５０％がスマートフォンを所有している。その数は、２０２０年には８０％にまで増加すると思われる。しかし、スマートフォンと同じぐらい感銘を与える、最大の波がまさに形成されている。我々は、物理的世界の「感覚化（sensorification）」に近づこうとしている。安価で、接続された、最小化されたコンピュータ及びセンサーの組み合わせが、スマートな、接続された製品と産業機器の世界を生み出すだろう。
【００６１】
この新しい技術カテゴリは、しばしば、「ＩｏＴ（Internet of Things）」と呼ばれる。ゼネラル・エレクトリック社は、ジェットエンジン、機関車、ＭＲＩ装置等の物を含めて、「インダストリアル・インターネット」という用語で、更に一歩先に進んでいる。
【００６２】
ＩｏＴは、ＩＴ革新の主要な、変換の波を表している。これは、ＩＴ主導型の生産性の大躍進の第３の波である。尚、最初の２つの波は、メインフレームとミニコンピュータ、及び、インターネットの出現によってもたらされたものである。言うまでもなく、これらのデータストリームの利用及び分析は、ＩＴとビジネスが次の十数年間に直面するであろう最大の課題を表している。
【００６３】
この大量のデータを説明するために使用される適切な用語は、ビッグデータである。ビッグデータに関しては、伝統的なデータ格納技術は、このように大量で高速のボリュームを扱うにはふさわしくない。そして課題はそこで終わらない。
【００６４】
企業は、こうしたデータの獲得方法だけでなく、検索、分析、視覚化の方法を理解し、、同時に、データを自身の事業及び顧客データに結び付ける必要もある。最終的な目標は、予測分析及びリアルタイムの知的意思決定を行う機能である。これには、記録システムから知能システムへのＩＴ変換が必要とされている。
【００６５】
ビッグデータが出現する前は、ビジネス・インテリジェンス（ＢＩ）の概念が既に、１９９０年代に一般に使用されるフレーズとなっていた。その当時、新しく生まれた多くのＢＩソフトウェアベンダーも市場に参入した。
【００６６】
ＢＩは、データをビジネスにとって意味のある有用な情報に変形するために必要な方法及びツールを提供した。この時期のＢＩの役割は、かなり基本的であり、データを収集して整理し、それを提示できる方法で視覚化することであった。
【００６７】
革新は続き、データウェアハウスの導入によって、記録システムから企業データにアクセスするのに要する時間が大幅に短縮された。こうした革新にも拘わらず、コアな課題は残っている。これらのデータウェアハウスをセットアップするには、深い専門的知識が必要とされ、ＢＩツールを使用するには相当な訓練が必要である。
【００６８】
単にビジネスに関わっている人には、まだ、アクセス可能な方法でこれらのツールを使用することはできない。ほとんどのＢＩツールは、訊こうとする質問が前もって分かっている場合に回答を得るには非常に良くできている。しかし、時には単に、どんな質問をすればいいか分からない場合もある。要するに、これらのツールでは、ビジネスユーザが、識見を、必要とする時に、必要とする方法で、必要とする場所で得ることができない。
【００６９】
幸いなことに、これは全くの課題である。クラウドで全体的に設計され、実行されるデータ分析ツールが、初めて構築されようとしている。ＩＴがハードウェアを提供する、或いは、データプラットフォームをインストールし、設定する必要はない。全ての関連する統合及びスキーマ開発を行うには、数カ月から数日に及んだ。この新しく発見された敏捷性によって、事業分野からの要求毎にＩＴが関与することが必要だった、伝統的な２段階のサービスビューローモデルを取り除く技術革新が可能となった。
【００７０】
これらの革新により、ビジネスユーザがデータにアクセスできるだけでなく、その分析に参加できるように、データの民主化（democratization）のための道が開かれつつある。このことは、アナリスト、データサイエンティスト、ＩＴを必要としない、回答への直接的なアクセスを持ったセルフサービスモデルを意味している。ビジネスユーザは、ほぼ瞬間的に回答を発見し、共有することができる。データについてどんな質問をすべきか事前に知らなければならない難しい要件は存在しない。ビジネスユーザは、データセットを調査して、識見を得るための質問をすばやく打ち出すことができる。
【００７１】
更に、この民主化は、モバイルによって促進される。スマートフォン、タブレット、ウェアラブル端末を用いて、ワーカーは、いつでもどこででもデータへアクセスし、緊急のビジネス上の質問に対する回答を直ちに得ることができる。データの民主化は、知能システムの構築を目指す行程において、なくてはならない段階となった。
【００７２】
データの民主化の成果が十分に得られる一方で、プロセス自体は主に、ビジネスユーザに、昔ながらの記録システム及びクラウドベースのビジネスアプリケーションからのデータへのアクセス及び分析の機能を提供する。これらの新しいＢＩツールの中にはせいぜいよくて、準リアルタイムのアクセスとデータ分析を提供できるものがあるくらいである。しかし、これらのＢＩツールは、スマートフォン、ウェアラブル端末、物理的世界において爆発的に増加しているセンサーから発生した、実際のリアルタイムのデータストリームを獲得し、分析するようには設計されていない。
【００７３】
リアルタイムのデータストリームは、たいていのＢＩツール及びプラットフォームが利用する後ろ向きの（backward-looking）履歴データとは全く異なる情報を伝達する。リアルタイムデータは、腐り易い。すなわち、検知されるだけでなく、それについて行動が起こされる必要がある。「識見までの時間（time to insight）」の概念は、知能システムの重要な性能指標の１つとして挙げられる。この識見には、全体的に新しいレベルのパッケージ化及び消費が必要とされる。情報は、状況に応じて直ちに、我々が日常生活で晒されているデータの不協和音を通り抜けるように伝達される必要がある。
【００７４】
知能システムは、データ識見によって何をすべきか、及び、適切なワーカーに対してその人の仕事上の役割及び組織内での役割に基づいてどのようにデータ識見を伝達すればよいかを分かる必要がある。こうしたシステムは、設定、立ち上げ、実行が容易な点で、現代のＢＩツールと同様に民主的である。また、知能システムは、我々が仕事で日々直面している毎日のデータの大洪水に対処するよう設計されている。ソーシャルメディア、トラフィック、ニュース集約アプリケーション等の消費者アプリケーションは、我々に最も重要である事柄に対してより知的に対処する際に役立つ。
【００７５】
知能システムに接続されるアプリケーションに対するハードルは、消費者アプリケーションと同様に高い。これは、ワンクリックでのインストール、美しくシンプルなユーザインターフェース、自分で選択できるモバイル機器を介した利用可能性を意味している。リアルタイムデータストリームの利用及び分析によって、リアルタイムでのアクションだけでなく、これから起こることを予測する機能へと拡充される。このことは、伝統的には、統計及び計算モデリングから視覚化及び報告までの全てを扱うデータサイエンティストの領域であった。データサイエンティストによって生成されるモデルは、たいていは、過去の歴史的な傾向を見て、そのデータを使ってパターン及び将来の傾向を予測するものであった。大量のリアルタイムデータストリームを対象とする計算モデルを構築する試みは、企業にとって重要な人的資源の課題を提示する。
【００７６】
リアルタイムのビッグデータストリームの分析と、それを使って何かをすることの両方を行うデータサイエンティストを有する会社はほとんどない。多くの組織は、現在募集中のポストを、資格要件を満たした人材で単に埋めるということができない。また、大学も、今後何年も需要に合った十分なデータサイエンティストを準備することはないと思われる。しかし、仮に、データを分析し組み立てるデータサイエンティストを配置したとしよう。その次はどうか？どうやってこれを利用可能なものに変換するか？どうやってライン管理者や取締役を、正しい決定を行うために、その分析の意味を理解するよう訓練するのか？
【００７７】
知能システムは、近い将来にデータサイエンティストに取って代わることはないだろうが、こうしたシステムは、データサイエンティストとして大量の従業員を雇用する必要を緩和する方向へ大きな役割を果たすと思われる。知能システムは、収集された知恵、専門的技術、組織について得られた識見を、知的な意思決定がこれら全ての合計となるように、利用し、拡大または縮小（scale）する。収集された知能は、ルールエンジンにおけるルールのように表現可能である。これらは、ビジネスユーザに、この収集された知能を受け取り、リアルタイムデータストリームを評価及び分析して知的意思決定を生む、単純で論理的なビジネスルールを構成することを可能にする。
【００７８】
データサイエンスには、データを用いて回答可能な量的な質問を策定する（formulating）処理、当該データを収集及びクリーニングする処理、当該データを分析する処理、質問に対する回答を関連する聞き手に伝える処理が含まれる。
【００７９】
企業が知能システムから得た初期の成果の多くは、簡単に成果が得られるもの、すなわち、上述した単純なビジネスルールの表現から得られる報酬である。しかし、組織が知能システムから得る識見が大きくなるにつれて、且つ、その諸要素（equation）の一部となる装置及びセンサーが増えるにつれて、アルゴリズムと機械学習の役割が知的意思決定において果たす役割が大きくなるだろう。
【００８０】
企業は、全てのデータを取捨選択するのに十分なビジネスアナリスト及びデータサイエンティストを雇用できないため、人工知能へますます注目するものと思われる。クレジットカード詐欺の検知が良い例であり、かなり精巧になってきている。
【００８１】
人工知能によって、詐欺に詳しい専門家への需要が完全に無くなるわけではないが、人工知能によって、人間による調査を必要とする疑わしい事例の数が大幅に減少している。
【００８２】
組織によるビッグデータへの取り組みが活発になるにつれて、多くの検討すべき事項が生じるだろう。適切な人材、適切なツール、適切な方法が必要となる。今日集まる技術は、データセットのソース及び大きさにおいて、本質的に無限である。如何に深い質問であっても、その場その場で対処する準備ができている。
【００８３】
これを超えた次の段階は、顧客に、どんな質問を彼らが尋ねる必要があるかを伝えることを開始する知能システムである。そこにたどり着くためには、知能システムの青写真が必要となるだろう。
【００８４】
データストリームのソースは、スマートフォン、及び、FitbitやApple Watchといった消費者向けウェアラブル端末等のモバイル機器からリアルタイムで発信している複数の信号である。これらの信号に対する制御点は、アプリケーションである。
【００８５】
アプリケーションは、人間の入力とこれらの装置に内蔵されたセンサーによって生成された生データの背景にコンテキストを置くものである。
【００８６】
Wikipediaによれば、センサーは、その周囲の環境のある特徴を感知又は検知することを目的とする変換器である。センサーは、イベント又は変化を大量に検知し、対応する出力を、一般的には、電気信号又は光信号として提供する。
【００８７】
これを全てまとめて結び付けることが、ディジタル配管（plumbing）、又は、アプリケーションプログラミングインターフェイス（ＡＰＩ）である。この概要で表されるデータストリームフローのあらゆる重大な要素に沿って、ＡＰＩは、システムにおける、高速で大容量のデータの端から端までの伝達を可能にするだろう。ＡＰＩという用語は、ＩＴ以外では一般的な用語ではないかもしれないが、今日のビジネス通信においてウェブやインターネットを説明する技術用語が共通語であるのと同様に、いずれは一般的になると思われる。
【００８８】
データストリームの主たる噴出源（gusher）は、接続された消費者向け製品と産業機器及び機械である。これらのリアルタイム信号は、自動車内、家庭内、貴重品、防犯システム、重要な物理的環境内のどこかに設置された製品センサーから発信される。
【００８９】
産業インターネットからの信号は、監視、保守、修理を要する機器又は機械の何らかの部分に設置されているセンサーから発信される。それは、物理的環境内のセンサーによりディジタル方式で監視可能な信号以外の何らかの信号である。知能システムは、これらの信号を識別し、利用できなければならない。
【００９０】
大量で高速のデータ信号を獲得（capture）するには、これらの信号入力を監視するために、「ディジタル番犬」が必要となる。仮にこれらのディジタル信号に何か重要なことが起きた場合、イベントが登録される。イベントのごく簡単な例としては、自動車内で温度センサーが作動して、外の凍りそうな状態を警告する場合が挙げられる。
【００９１】
知能システムは、これらのデータストリームを摂取（ingest）し、監視する技術を必要とする。ディジタル信号によって生成されたイベントは、メッセージを通じて配信され、消化（digestion）処理が計画通りに進められるように、システム内を進む。ここで、フィルターが、これらのデータストリームを更に分析するという仕事を開始できる。システムが適切に機能するためには、データフローの増大する容量及び速度に対処できなければならず、また、当該システムで故障やクラッシュが発生した場合でも、データストリームは失われてはならない。
【００９２】
データが獲得され、処理されると、消化段階に移行する。ここで、幾つかの魔法が起こり始める。これには、リアルタイムデータストリームの監視及び分析処理が含まれる。データが分析され、処理されると、どこかに置いておく必要がある。
【００９３】
流入するデータストリームは、構造化照会言語（ＳＱＬ）を用いたリレーショナルデータベース等の伝統的なデータベースストレージには適さない。これは、知能システムの必須要素である、非常に大きなデータセットを処理し、格納することができる特別な技術を要する。
【００９４】
このシステムのもう１つの鍵となる構成要素は、データストリームの分析に適用されるビジネスルールの形でフィルターを適用する機能である。これによって、組織の収集された知恵と専門知識をシステムに直接表現することで、人為的エラーを排除する処理が開始される。機械学習及びアルゴリズムの形での人工知能もまた、更なる分析のために、これらのデータストリームに適用することができる。
【００９５】
企業データは、今日の企業ＩＴの主流である記録システム及び関与システム（systems of engagement）で構成される。ＩＴが、メインフレーム及びミニコンピュータからパソコン及びインターネットへ移動した際、記録システムは、主として、紙及び手動で処理されていたものをディジタル時代へ移行することに関連してきた。また、記録システムは、日々の活動を自動化し、製品によってその情報を獲得し、本質的には歴史文書であるものを報告するというものであった。
【００９６】
関与システムは、顧客、パートナー、従業員との会話及び相互作用の社会的性質に焦点を当てる点で、記録システムとは根本的に異なる。ソーシャルメディア、及び、ＩＴを一般消費者向けにすることは、こうした会話がどのように生じ、どんなチャネルを通っているかを形作る。ドキュメントベースのディジタルの人工物の代わりに、関与システムは、時間、コンテキスト、場所の要素を追加する。記録のためのシステムは無くなることはない。単に、企業が、関与システムとの次世代の通信及び協力を含むことが必要になるだけである。
【００９７】
関与システム及び記録システムは、データストリームへのコンテキストの提供、フィルタリング、分析をする上で欠かせない要素である。もし顧客、パートナー、従業員の全体像を持っていなければ、データストリーム及び出力を理解することはできない。これらのシステムは、知能システムによってもたらされる分析的な識見及び知的意思決定を解明するには不可欠である。
【００９８】
企業のコンテキストを摂取、消化し、データストリームに適用した後、知的出力が生成され、適切な形で、適切な時期に、適切なチャネルへ配信される。第１の２つのチャネルは、ダッシュボードと識見である。ダッシュボードは、新会社の戦略を打ち出す、既存の市場プログラムを調整する、知的意思決定に基づく規則を改良するといった行動を、人間が探索し、実施できるように、何が起きていて、何が起こったのかについて、視覚化及びコンテキストを操作（drive）する。識見は、リアルタイムの意思決定の配信に、より依存する。それがダッシュボードと分析的識見の重要な違いである。ビジネス規則で、組織の収集された知識及び専門的知識を表現することは、簡単に回避できる悪い決定の排除に大いに役立つ。信号が増加し、データストリームが知能システムに流れ込む時に、データサイエンティストは、予測可能な方法で知的意思決定をもたらす機械学習アルゴリズムを生成するために、自身の方法及びモデルをより良く適用することができる。
【００９９】
データストリームの旅の最終段階に移ると、企業は、ビジネスの変換を開始するために、知的出力の成果の適用を開始することができる。我々の中心となる前提は、どのアプリケーション、装置、接続された製品、センサーの背後にも顧客がいるということである。ここに開示されるＩｏＴプラットフォームの役割は、販売、顧客サービス、マーケティング、コミュニティ、アプリケーション、分析を通して顧客を従事させるユーザ成功プラットフォームに、装置データを接続することである。
【０１００】
開示される技術は、非プログラミングユーザに向けに、コンピュータによって実施されるシステムを用いて、エンティティ管理ワークフローの生成の単純化に関する。開示される技術は、データベースシステム、マルチテナント環境、或いは、OracleTMに準拠したデータべース実装、IBM DB2 Enterprise ServerTMに準拠したリレーショナルデータべース実装、MySQLTM又はPostgreSQLTMに準拠したリレーショナルデータべース実装、Microsoft SQL ServerTMに準拠したリレーショナルデータべース実装、或いは、VampireTMに準拠したリレーショナルデータべース実装、Apache CassandraTMに準拠したリレーショナルデータべース実装、BigTableTMに準拠したリレーショナルデータべース実装、HBaseTM又はDynamoDBTMに準拠したリレーショナルデータべース実装といったＮｏＳＱＬ非リレーショナルデータベース実装を含む、何らかのコンピュータによって実施されるシステムに関連して実施可能である。
【０１０１】
更に、開示される技術は、２以上の別々に区別され、互いに協力し、通信するコンピュータによって実施されるシステムを用いて実施可能である。開示される技術は、プロセス、方法、機器、システム、装置、コンピュータ可読命令又はコンピュータプログラムコードを格納するコンピュータ可読記憶媒体、或いは、コンピュータ可読プログラムコードが内部で具体化されているコンピュータ利用可能媒体を備えるコンピュータプログラム製品といったコンピュータ可読媒体を含む、多数の方法で実施可能である。
【０１０２】
また、開示される技術は、MapReduceTM、バルク同期プログラミング、MPIプリミティブといった様々なプログラミングモデル、或いは、Apache StormTM、Apache SparkTM、Apache KafkaTM、TruvisoTM、IBM Info-SphereTM、BorealisTM、Yahoo! S4TMといった様々なストリーム管理システムを用いて実施可能である。
＜ＩｏＴプラットフォーム及びストリームバッチ処理フレームワーク＞
【０１０３】
非プログラミングユーザ向けの、エンティティ管理ワークフローの生成を単純化するシステム、及び、様々な実施例を説明する。当該システム及びプロセスは、実施例に従ってシステムの構造上のレベルの略図を示した図１及び図２を参照して説明する。図１及び図２は構造図であるため、説明の明瞭性を高めるため、詳細は意図的に省略されている。図１及び図２の議論は、以下のように整理される。まず初めに、各図面の要素について説明し、その後でそれらの相互接続について説明する。次に、システムにおける当該要素の使用について、更に詳細に説明する。
【０１０４】
図１には、典型的なＩｏＴプラットフォーム１００が含まれる。ＩｏＴプラットフォーム１００は、データソース１０２、入力コネクタ１０４、ストリームコンテナ１０６、バッチコンテナ１０８、リッチコンテクスチュアルデータストア（rich contextual data store）１１０、オーケストレーションシステム１１２、出力コネクタ１２２、アプリケーション１２３を備える。リッチコンテクスチュアルデータストア１１０は、様々なストレージノードＣ１〜Ｃ３を備える。オーケストレーション１１２は、データエントリカラムナ１１４、探索エンジン１１５、ライブダッシュボード構築エンジン１１６、モーフィングエンジン１１７、トゥイーンエンジン（tweening engine）１１８、トゥイーンステッパー１１９、統合開発環境（ＩＤＥ）１２１、レンダリングエンジン１２０を備える。アプリケーション１２３は、様々なＳａａＳ、ＰａａＳ、ＩａａＳの製品で構成される。
【０１０５】
図２は、開示される技術の一実施例に従って、図１で示すプラットフォームで使用されるストリーム処理フレームワーク２００を表している。フレームワーク２００は、データソース１０２、入力パイプライン２０４、ストリームコンテナ１０６、リッチコンテクスチュアルデータストア１１０、出力パイプライン２１８を備える。ストリームコンテナ１０６は、エミッタティア２０６、スケジューラ２０８、コーディネータ２１０、ワーカーティア２１４を備える。
【０１０６】
ＩｏＴプラットフォーム１００及びストリーミングフレームワーク２００の要素の相互接続を以下で説明する。ネットワーク（図示せず）が、データソース１０２、入力コネクタ１０４、ストリームコンテナ１０６、バッチコンテナ１０８、リッチコンテクスチュアルデータストア１１０、オーケストレーションシステム１１２、カラムナ１１４、出力コネクタ１２２、アプリケーション１２３、入力パイプライン２０４、エミッタティア２０６、スケジューラ２０８、コーディネータ２１０、ワーカーティア２１４、出力パイプライン２１８を連絡し、全てが互いに通信し合っている（実線矢印で表示）。実際の通信経路は、パブリック及び／又はプライベートネットワーク上で２地点間とすることができる。データソース１０２からのデータといった幾つかのアイテムは、間接的に、例えば、アプリケーションストア（図示せず）を介して、伝達される。全ての通信は、プライベートネットワーク、ＶＰＮ、ＭＰＬＳ回路、インターネット等の様々なネットワーク上で発生し、適切なＡＰＩ、及び、ＲＥＳＴ、ＪＳＯＮ、ＸＭＬ、ＳＯＡＰ、ＪＭＳ等のデータ変換形式を使用することが可能である。全ての通信は、暗号化することができる。通信は、一般に、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、電話ネットワーク（公衆交換電話網（ＰＳＴＮ））、セッション確立プロトコル（ＳＩＰ）、無線ネットワーク、２地点間ネットワーク、星状ネットワーク、トークンリングネットワーク、ハブネットワークや、ＥＤＧＥ、３Ｇ、４Ｇ  ＬＴＥ、ＷｉＦｉ、ＷｉＭＡＸ等のプロトコルを介したモバイルインターネットを含むインターネット等で行われる。更には、ユーザ名／パスワード、OAuth、Kerberos、SecureID、ディジタル証明書の他、様々な権限付与技術及び認証技術が、通信の安全性を確保するために使用することができる。
【０１０７】
図１（ＩｏＴプラットフォーム１００）及び図２（ストリーミングフレームワーク２００）の要素、及び、それらの相互接続についてこれまで説明してきたが、システムについて、以下で更に詳細に説明する。
【０１０８】
データソース１０２は、スマートフォン、ＷｉＦｉアクセスポイント、センサー又はセンサーネットワーク、モバイルアプリケーション、ウェブクライアント、サーバからのログ、ソーシャルメディアサイト等のエンティティである。一実施例において、データソース１０２からのデータは、ＡＰＩ（Application Programming Interface）を介してアクセスされる。ＡＰＩによって、センサー、装置、ゲートウェイ、プロキシ、及び、その他の種類のクライアントは、データソース１０２をＩｏＴプラットフォーム１００に、データがそれらから摂取できるように登録する。データソース１０２からのデータは、構造化データ（例えば、ユーザプロファイル、インタレストグラフ）、非構造化テキスト（例えば、ツイート）、半構造化相互作用ログの形でイベントを含むことができる。イベントの例としては、装置のログ、リンクへのクリック、お勧めの印象、特定のクライアントのログイン数、サーバのログ、ユーザの身元（ユーザハンドル又はユーザＩＤの時もあれば、ユーザの実名を指す時もある）、ソーシャルネットワークサービス上の各フィードに対してユーザが投稿したコンテンツ、ソーシャルグラフデータ、コメントが以前の投稿、イベント、ニュース記事等に応答して投稿されたかどうかを含むメタデータ等が挙げられる。イベントは、文字列フィールド（又はカラム）、及び、数、文字列、配列、オブジェクトといった本質的に異なる種類の対応する値を表す、ＪＳＯＮ（JavaScript Option Notation: JavaScriptは登録商標）、ＢＳＯＮ（Binary JSON）、ＸＭＬ、Protobuf、Avro、Thriftオブジェクト等の半構造化データフォーマットをとり得る。ＪＳＯＮオブジェクトは、他の実施例では、ネストすることが可能で、そのフィールドは、例えば、配列、ネストされた配列等の多値をとることができる。
【０１０９】
以下に説明するように、準リアルタイム（ＮＲＴ）データストリーム１０３は、エンティティによって生成された際に登録されたイベントの収集物である。一実施例では、イベントは、ＨＴＴＰによって入力パイプライン２０４まで伝達される。別の実施例では、イベントは、ＰＯＳＴリクエストを介して、入力パイプライン２０４の代わりに動作する受信器に転送される。例えば、TwitterのFirehose ＡＰＩ（Datashift、nTweetStreamer、tiwwter4j等のTwitterの関連会社を通じてアクセス可能）は、ツイートと呼ばれる無制限のタイムスタンプ付のイベントを、ツイート、ユーザ情報、場所、話題、キーワード、リツイート、フォロワー、フォロー、タイムライン、ユーザライン等についてのタイムスタンプデータを含む、こうしたツイートについてのメタデータと共にＪＳＯＮオブジェクトのストリームとして提供する。これらのＪＳＯＮオブジェクトは、Apache CassandraTM、GoogleのBigTableTM、HBaseTM、VoldemortTM、CouchDBTM、MongoDBTM、RedisTM、RiakTM、Neo4jTM等のスキーマレスな、又は、ＮｏＳＱＬのキーバリューデータストアに格納される。当該データストアは、ＳＱＬにおけるデータベースに相当するキースペースを用いて、解析されたＪＳＯＮオブジェクトを格納する。各キースペースは、テーブルに類似し、行と一連のカラムからなるカラムファミリーに分割される。
【０１１０】
入力コネクタ１０４は、データソース１０２からのデータを獲得し、当該データを、コンテナ１０６及び１０８によって消費可能な入力フォーマットに変形する。一実施例では、入力コンテナ１０４は、データソース１０２からフルデータプル及び／又はインクリメンタルデータプルを行う。別の実施例では、入力コンテナ１０４は、データソース１０２からのメタデータにもアクセスする。例えば、入力コネクタ１０４は、エンティティに関するメタデータをフェッチするために「記述（describe）」ＡＰＩコールを発行し、次に、エンティティに関するデータをフェッチするために適切なＡＰＩコールを発行する。幾つかの実施例では、カスタマイズされた入力コネクタ１０４が、個別のデータソース１０２に関して、Connector SDKTMを用いて記述される。
【０１１１】
他の実施例では、ワークフロー定義には、コネクタ及びオペレータの集合と共に、それらを実行する命令が含まれる。一実施例では、そうしたワークフローが、コネクタとオペレータがグラフノードであり、エッジがデータフローを反映する有向グラフとして指定される。さらに他の実施例では、複数のデータストリーム１０３は、コンテナ１０６及び１０８に入力される前に、結合され、変形される。
【０１１２】
コンテナ１０８内で動作するバッチ処理フレームワークは、リッチコンテクスチュアルデータストア１１０に格納されたオンライン分析処理（ＯＬＡＰ）のクエリーを用いて、ビジネス知能を生成する。一実施例では、イベントは、バッチ処理のジョブが所定の時間に実行可能な、未処理のイベントに対するバックアップとして機能するために、バッチコンテナ１０８に格納されている。バッチコンテナ１０８は、幾つかの実施例では、未加工のカウント（raw count）と共に、平均、中央値、パーセンタイル分析等の記述統計も提供する。一実施例では、遡及的な分析、機械学習モデリング、他のバッチ分析を提供するために、ScaldingTM及びPigTMといった分析ツールがバッチコンテナ１０８に含まれる。更に他の実施例では、バッチコンテナ１０８は、ストリームコンテナ１０６によって生じたエラーを訂正するために、又は、履歴データ及び再計算結果について分析を行うことでアップグレードされる機能を処理するために使用される。バッチ処理フレームワークの例としては、MapReduceプログラミングモデルを実施するHadoop分散ファイルシステム（ＨＤＦＳ）が挙げられる。
【０１１３】
バッチコンテナ１０８は、複数のＮＲＴデータストリームについてデータを収集する各入力パイプラインからイベントタプルを摂取する。幾つかの実施例では、複数のＮＲＴデータストリームは、単一のパイプラインに割り当てることができ、また、複数のパイプラインは、単一のバッチコンテナに割り当てることができる。
【０１１４】
ストリーム処理フレームワーク２００は、発生した時のイベントに基づく即時の分析及び識見の伝達に対して、無制限のイベントシーケンスの準リアルタイム（ＮＲＴ）処理を提供する。一実施例では、フレームワーク２００は、ノード当り毎秒１００万イベントを処理する。フレームワーク２００は、Apache StormTM及びApache SamzaTMといった１以上のストリームプロセッサ、又は、Apache SparkTMといったバッチストリームプロセッサを用いて実施可能である。一実施例では、フレームワーク２００は、一連のイベントタプルに対して実行されるジョブを記述し、当該イベントタプルに対して動作を行うＡＰＩを備える。
【０１１５】
データソース１０２からデータを読み込み、ストリームコンテナ１０６による消費のためにイベントを保持する、入力パイプライン２０４によって、イベントがフレームワーク２００に摂取される。一実施例では、入力パイプライン２０４は、コンテナ１０６に入力するイベントにとって、単一の伝達終点である。入力パイプライン２０４の例としては、Apache KafkaTM、FlumeTM、ActiveMQTM、RabbitMQTM、HTTP/HTTPSサーバ、UDPソケット他が挙げられる。幾つかの実施例では、入力パイプライン２０４は、インターネットを介して、各ＡＰＩ（例えば、Chatter API、Facebook API（例えばOpen Graph）、Twitter API（例えば、Twitter Firehose、Sprinklr、Twitter Search API、Twitter Streaming API）、Yahoo API（例えばBoss search）等）と接続することで、データソース１０２から発生するＮＲＴデータストリーム１０３及びデータフローをリスニングすることができるリスナーを備える。幾つかの実施例では、リスナーには、様々なデータソース１０２からのデータの取り込み（intake）に関与する異種のインスタンスが含まれる。ある実施例によれば、入力パイプライン２０４は、アプリケーションプロトコル層、又は、ＨＴＴＰプロトコル層や多くの可能性のある標準及び非標準のプロトコル層といった他の高次のプロトコル層を用いてネットワーク上でデータを受信するよう構成することが可能である。これらの高次のプロトコル層は、インターネットプロトコル（ＩＰ）等のネットワーク層、及び／又は、伝送制御プロトコル（ＴＣＰ）及び／又はユーザデータグラムプロトコル（ＵＤＰ）等のトランスポート層上でメッセージの送受信を行うためのデータの符号化、パッケージ化、再フォーマットを行うことができる。
【０１１６】
特定の実施例では、Apache KafkaTMが、入力パイプライン２０４として用いられる。Kafkaとは、出版−購読型（publish−subscribe）モデルを用いた分散メッセージングシステムである。Kafkaは、トピックと呼ばれるカテゴリにイベントを保持する。イベントは、いわゆる生産者（producer）によって出版され、いわゆる消費者（consumer）によってプルされ、処理される。分散システムとして、Kafkaはクラスタで実行され、各ノードはブローカーと呼ばれ、複製されたコミットログにイベントを格納する。他の実施例では、様々なメッセージング及びキューイングシステムが使用可能である。
【０１１７】
一実施例では、ＮＲＴデータストリーム１０３は、入力パイプライン２０４にバッチとして待ち行列に入れられる。一実施例では、バッチは、「ワーク単位」とも呼ばれるイベントタプルの集団（assemblage）として定義され、タイムスライスベース及び／又はバッチサイズベースで定義される。タイムスライスベースでの定義には、時間窓（例えば１つのバッチは、イベントタプルを最後の１秒から保持する）内で最近受信した部分によって、少なくとも１つの入力されたＮＲＴデータストリームを分割することが含まれる。バッチサイズベースでの定義には、データサイズ（例えば、１バッチに１０ＭＢの最近受信したイベントタプルを含む）で制限又は限定又は抑制される最近受信した部分によって、少なくとも１つの入力されたＮＲＴデータストリームを分割することが含まれる。他の実施例では、タイムサイズベースとバッチサイズベースの組み合わせを用いてバッチを定義する。
【０１１８】
特定の実施例では、Apache StormTMが、ストリームコンテナ１０６で動作し、ユーザによって送信された、「スパウト（Spouts）」又は「エミッタノード」（図２ではまとめてエミッタティア２０６と称する）と、「ボルト（Bolts）」又は「ワーカーノード」（図２ではまとめてワーカーティア２１４と称する）と呼ばれる、ノードのネットワークから構成される有向非巡回グラフのマトリックスを用いて、リアルタイムの計算を実行する。Stormのマトリックスでは、スパウトが、ＮＲＴデータストリーム１０３のソースであり、ボルトが、新たなデータを出力として生成するためにこれらのストリームを分析及び処理し、当該出力をマトリックスにおける次のステージへ渡すためのビジネスロジックを保持する。一実施例では、特別なKafkaのスパウトが、Kafkaのトピックからバッチとして読まれたイベントを、ワーカーティア２１４内のボルトへ発信する。
【０１１９】
ワーカーティア２１４は、ＩＤ−名前検索のような単純なデータ変形から、複数ストリーム結合のような複雑な動作まで、様々なストリーム処理のジョブを実行するボルト又はワーカーノード（図２では立方形で示されている）を備える。具体的には、ワーカーティア２１４内のワーカーノードは、リッチコンテクスチュアルデータストア１１０のような外部の持続性レイヤーに対して、集約（aggregation）、関数（function）、ストリームグルーピング（例えば、シャッフルグルーピング、フィールドグルーピング、オールグルーピング、グローバルグルーピング）、フィルタリング、コミットといったタスクを実行することができる。幾つかの実施例では、ワーカーティア２１４内のワーカーノードは、上流ステージが、下流ステージで消費されるイベントタプルを生成する場合、関連する処理ステージ間で推移的従属性を有する。
【０１２０】
ストリームコンテナ１０６内で渡されるメッセージは、タプルと呼ばれる。タプルは、未定義のフィールドセットに関する一連の値である。スパウト及びボルトは、夫々、事前に静的に発信するタプルのフィールドを定義する。全てのタプルは、ストリームコンテナ１０６内の他の構成要素に変換される前に、バイナリ形式にシリアライズされる。幾つかの実施例では、このシリアライズは、Ｊａｖａオブジェクトの高速シリアライズを提供するＫｒｙｏライブラリによって処理される。
【０１２１】
ストリームコンテナ１０６は、イベントストリームを渡すために、様々なタプルのグルーピングストラテジーを用いたスパウトとボルトの並列化を可能にする。グルーピングストラテジーは、イベントストリームの分割を定義し、次の計算単位の並列化の程度を制御する。尚、並列化の程度とは、並列実行数を指す。
【０１２２】
スケジューラ２０８は、ストリームコンテナ１０６内で１以上の入力パイプライン（例えば、入力パイプライン２０４）を探知し、上流の完了したステージの出力に依存する、バッチの実行、及び、下流ステージの実行をスケジュールする。一実施例では、スケジューラ２０８は、入力パイプライン２０４内の各バッチに固有のバッチ識別子（ＩＤ）を割り当てる。更に、スケジューラ２０８は、パイプライン毎に、現在のバッチの再送又は次のバッチのいずれかを、対応するステージの情報と共に起動する。また、スケジューラ２０８は、メッセージを[pipeline:‘a’, batch:7, stage‘b’]の形式でコーディネータ２１０に送信する。幾つかの他の実施例では、スケジューラ２０８は、ＩｏＴプラットフォーム１００の様々なパイプラインに優先レベルを割り当てる。この優先レベルは、第２パイプラインからの第２の数のバッチを実行する前に、第１パイプラインからの第１の数のバッチの実行を制御する。
【０１２３】
コーディネータ２１０は、ワーカーティア２１４内のワーカーノードに対するバッチのディスパッチを制御する。スケジューラ２０８がバッチステージを起動すると、コーディネータ２１０は、特定のステージを担当するエミッタティア２０６及びワーカーティア２１４にトリガーを送信する。[pipeline:‘a’, batch:7, stage‘b’]がコーディネータ２１０によって受信されると、コーディネータ２１０は、１００の利用可能なワーカーノードの内、２つに連絡する。これらは、ステージ‘a’から入力を受信した２つのワーカーノードである。
【０１２４】
また、コーディネータ２１０は、処理のために割り当てられたリソースのかなりの部分が特定のバッチには必要でない可能性が高い場合に、十分に「ロングテール」な動作を可能とするために、所与のバッチステージについて、ストリームコンテナ１０６内の保留中のワーク単位を探知する。stage[a]とstage[b]があり、stage[a]の出力がstage[b]で使用されるように単一の分散動作をとるとすると、stage[a] -> stage[b]で表される。ここで、一実施例に従って、stage[a]が１００のワーカーノードで実行され（夫々、物理ノードで実行される）、stage[b]が１００のワーカーノードで実行され（夫々、物理ノードで実行される）、stage[a]がstage[b]の２つのインスタンスだけに出力を生成する場合を想定する。stage[a]が完全に実行され、stage[b]が開始すると、コーディネータ２１０は、stage[b]に割り当てられた１００のワーカーノードの内の２つのみが起動する必要があることを知る。stage[a] -> stage[b] -> stage[c]で表される、３つのステージ処理についても同様に、stage[b]がstage[a]から何も入力を受信せず、そのため、stage[c]も何も入力を受信しない場合に、コーディネータ２１０は、stage[b]及びstage[c]に対して無関係な通信は全て回避する。stage[a]のデータが全てフィルターで除去される場合、stage[b]及びstage[c]に割り当てられたワーカーノードとの通信オーバーヘッドは存在しない。
【０１２５】
ストリームコンテナ１０６は、複数のＮＲＴデータストリームに関してデータを収集する各入力パイプラインからイベントタプルを摂取する。幾つかの実施例では、複数のＮＲＴデータストリームは単一のパイプラインに、複数のパイプラインは単一のストリームコンテナに割り当てることが可能である。
【０１２６】
リッチコンテクスチュアルデータストア１１０は、大量の履歴データを格納し、準リアルタイム分析と組み合わせた履歴クエリーベースの分析を可能とする。一実施例では、リッチコンテクスチュアルデータストア１１０は、ＩｏＴプラットフォーム１００内のタスクのスナップショットの取得に使用され、ＩｏＴプラットフォーム１００のパイプライン、スパウト、ボルト、その他の要素についての状態情報を格納する。幾つかの実施例では、リッチコンテクスチュアルデータストア１１０は、Apache CassandraTMのようなＮｏＳＱＬキーバリューカラムストア分散格納システムである。CassandraTMに送られたデータは、Java、Scala、Ruby、Clojure、PythonベースのＡＰＩ（例えば、Hector、Pelops、CQL、Thrift、Phpcassa、PyCassa等）を用いて接続が可能な、多くのノード又はコモディティサーバＣ１〜Ｃ３に広がる。Cassandraは、カラムと呼ばれる単位でデータを格納する。各カラムはタプルであり、関連するデータ要素の一覧である。基本的なカラム形式は、（名前、値、タイムスタンプ）で表すことができる。簡潔にするために、カラムの必須の要素であるタイムスタンプはしばしば記載しない。したがって、カラムの例は、（UserName, User-1）と書いてもよい。スーパーカラムと呼ばれる階層の任意のレベルは、任意の数のカラムを取り込んでもよい。レベルを上げて、キー（行と呼ばれることもある）は、名前と、１以上のカラム又はスーパーカラムを含むタプルである。キーの例としては、（Status_Key,（UserName, User-1），（Logged_In, Y）を書くことができる。任意の数のキーをカラムファミリーにグループ化してもよい。それと類似して、カラムファミリーのグループを、階層の最終レベルである、キースペースと称する。上記関係の２つの疑似コードの表現は、以下のように構成される。
・  [keyspace][column family][key][column]
・  [keyspace][column family][key][super column][column]
【０１２７】
出力パイプライン２１８は、処理されたイベントを収集し、永続的な格納へ転送するために待ち行列に入れる。一実施例では、出力パイプライン２１８からのデータは、ＳＱＬデータストア、及び、リッチコンテクスチュアルデータストア１１０等のＮｏＳＱＬデータストアへ同時に送信される。出力パイプライン２１８はKafkaによってホストされることも可能であり、ジョブの出力のためのシンク（sink）として機能する。
＜同時処理と多重処理の組み合わせ＞
【０１２８】
図１１は、ワーカーティア２１４のワーカーノード１の一実施例１１００であり、複数の物理スレッドＰＴ１〜ＰＴ１０を備える。各物理スレッドＰＴ１〜ＰＴ１０は、プロセッサコア１〜８の内の１つから選択されたワーカーノード１のプロセッサコア全体を利用する。ワーカーティア２１４は、独自の物理スレッドのセットを持ち、各物理スレッドがプロセッサコア全体を利用する、ワーカーノード２〜３も備える。
【０１２９】
図１２Ａ及び図１２Ｂは、利用可能な物理スレッドのカウントが論理的に並行なスレッドの設定数と等しいか又はそれを超える場合、１つのパイプラインで複数のバッチを同時に処理する一実施例１２００を示している。図１２Ａに示す典型的な筋書きでは、論理的に並行なスレッドの数、すなわち、並行度（parallelism）は、１０である。また、図１２Ａでは、利用可能な物理スレッド数は１０、すなわち、ＰＴ１〜ＰＴ１０である。したがって、１０個のバッチＢ１〜１０が入力パイプライン２０４で待ち行列に入ると、コーディネータ２１０が、図１２Ｂにおける利用可能な１０個の物理スレッドＰＴ１〜ＰＴ１０で、バッチＢ１〜Ｂ１０を同時に処理する。実行時に、コーディネータが、利用可能な物理スレッドＰＴ１〜ＰＴ１０のカウントが論理的に並行なスレッド設定数（１０）に等しいと判断したため、この同時処理１２００Ｂが生じる。
【０１３０】
図１３Ａ、１３Ｂ、１３Ｃは、論理的に並行なスレッド設定数よりも少ない利用可能な物理スレッドがある時、１つのパイプラインでバッチＢ１〜１０を多重化処理（multiplexing）する一実施例１３００Ａ〜Ｃを示している。図１３Ａに示す典型的な筋書きでは、論理的に並行なスレッドの設定数、すなわち、並行度は１０である。しかし、利用可能な物理スレッドの数は９のみ、すなわち、ＰＴ１〜ＰＴ９である。利用不可能な物理スレッドＰＴ１０は、図１３Ａ〜Ｃでは、グレイアウトされた箱によって示されている。幾つかの実施例では、利用不可能であるということは、過剰な又は等しいスレッドは開始されてもいないということを指しており、こうした実施例に関しては、当該利用不可能な物理スレッドＰＴ１０は、図１３Ａ〜Ｃでは示されないことになる。他の実施例では、利用不可能であるということは、図１３Ａ〜Ｃの典型的な筋書きで示されているように、既に開始された物理スレッドが失敗し、バッチ処理ができないことを指している。
【０１３１】
開示される技術は、９個の利用可能な物理スレッドＰＴ１〜ＰＴ９に対してバッチＢ１〜Ｂ１０を順に多重化処理することで、利用可能な計算リソースＰＴ１〜ＰＴ１０と処理対象のデータ単位Ｂ１〜Ｂ１０における不一致に適合する。多重化処理には、利用可能な物理スレッドＰＴ１〜ＰＴ９に対してバッチＢ１〜Ｂ９を同時に処理することが含まれ、バッチＢ１〜Ｂ９から１つのバッチ（例えばＢ９）が、利用可能な物理スレッドによって処理を完了する、或いは、出力パイプライン２１８で待ち行列に入ると、入力パイプライン２０４の次のバッチＢ１０が、図１３Ｃに示すように、コーディネータ２１０によって、次の利用可能な物理スレッド（例えばＰＴ９）で処理される。
＜強力な順序付けによる多段階処理＞
【０１３２】
図１４は、バッチ１として識別されるバッチの多段階処理１４００の一実施例である。図１４に示す典型的な筋書きでは、TwitterTM分析ツールを生成する。多段階処理１４００の間、ツイート（Tweet_1〜Tweet_2）が個々のタプルとしてバッチ１に格納される。これらのツイートは、エミッタ１４０２及びコンテナ（図示せず）のトランスフォーマー１４０４、１４０６、１４０８で処理される。結果として得られた分析は、ツイート内の全てのハッシュタグ、及び、ツイートにおけるそれらの頻度、それらが現れた全ユーザとツイートの数、それらのハッシュタグと頻度を持つユーザを一覧にする。また、出力の順序は、バッチ１のツイート（Tweet_1〜Tweet_2）の一覧順に従う。
【０１３３】
多段階処理１４００は、２つのステージ（ステージＡとステージＢ）に分割される。ステージＡでは、「Twitter摂取エミッタ」１４０２がTwitterＡＰＩに接続し、ツイートタプルをトランスフォーマー１４０４、１４０６、１４０８に発信する。「＠トランスフォーマー」１４０４は、ツイートを構文解析し、「＠」が前に付く単語を探すことでユーザを識別し、「＠ストリーム」と呼ばれるストリーム内のこれらの単語を「＠＃結合トランスフォーマー」１４０８に送信する。また、処理ステージＡでは、「＃トランスフォーマー」１４０６は、ツイートを構文解析し、「＃」が前に付く単語を探して、「＃ストリーム」としてこれらの単語を「＠＃結合トランスフォーマー」１４０８に送信する。処理ステージＡについて、コーディネータ２１０は、図１４でグレイアウトされている物理スレッドＰＴ４及びＰＴ６を利用する。このステージ情報は、スケジューラ２０８で格納され、スケジューラ２０８は、当該情報を実行時にコーディネータ２１０に通知する。
【０１３４】
ステージＢでは、「＠＃結合トランスフォーマー」１４０８が、＠ストリームと＃ストリームの両方を受信し、ユーザが言及されたツイート内で、ハッシュタグが何回現れたかをカウントする。図１４でステージＢが開始されると、コーディネータ２１０が、物理スレッドＰＴ４及びＰＴ６がステージＡの処理を行ったことを識別し、同じ物理スレッドＰＴ４及びＰＴ６で処理されるストリーム（＠ストリーム及び＃ストリーム）を「＠＃結合トランスフォーマー」１４０８に対してディスパッチする。
【０１３５】
更に、コーディネータ２１０は、バッチ１の両方のバッチ単位、すなわち、＠ストリームと＃ストリームが、それらのどちらかがステージＢで「＠＃結合トランスフォーマー」１４０８によって処理される前に、ステージＡで完全に処理されることを確実にすることで、出力における強力な順序付けを維持する。
＜オーケストレーション＞
【０１３６】
オーケストレーション１１２は、非プログラマーがエンティティ管理ワークフローを構築し実行することを可能にするウェブプラットフォームである。オーケストレーション１１２は、図４Ａ、図４Ｂ、図４Ｃに関連して後述する、宣言的且つドラッグ−ドロップ入力を受け付ける、データエントリカラムナ１１４を生成する宣言的且つ視覚的インターフェースを利用する。一実施例では、オーケストレーション１１２によって、非プログラマーは、広範囲に亘るプログラミング知識が無くても、ワークフローを視覚的に設計することができる。一実施例では、オーケストレーション１１２は、JSONの設定ファイルに格納されている形式宣言的記述（formal declarative description）を使用する。当該JSONファイルは、セッションで使用される挙動（behavior）を定義する。定義される挙動には、ワークフローで使用される他のパラメータ及び変数と共に、処理するイベントを指定するライフサイクルの間のエンティティの状態、状態遷移トリガー、使用される遷移規則、使用される動作規則を指定する応答動作が含まれる。他の実施例では、ＨＴＭＬ（Hypertext Markup Language）、ＳＧＭＬ（Standard Generalized Markup Language）、ＤＭＬ（Declarative Markup Language）、ＸＡＭＬ（Extensible Markup Language）、ＸＳＬ（Extensible Stylesheet Language）、ＸＳＬＴ（Extensible Stylesheet Language Transfomations）、Haskell及びMLのような関数型プログラム言語、Prologのような論理型プログラミング言語、Lucidのようなデータフロープログラミング言語、Jess、Lips、CLIPSのようなルールベース言語等の様々なプログラミング言語が、セッションで使用される挙動を定義するために使用できる。
【０１３７】
別の実施例では、オーケストレーション１１２は、宣言的構成要素及びランタイム構成要素を備える。宣言的構成要素を用いて、非プログラマーは、エンティティ状態、状態に関する遷移トリガー、状態に対する応答動作、エンティティライフサイクルワークフローの他のパラメータ及び変数を宣言する。一実施例では、宣言的構成要素は、他のユーザ及びコミュニティによって共通に使用される、既存のワークフロー又はワークフローの抜粋を提供する。一実施例では、宣言的入力が、記述コードの結果としてではなく、視覚的な方法で、ブラウザで受領される。宣言的入力は、次に、ランタイム構成要素で直接実行可能な宣言的ファイル（例えば、ＸＭＬ）のパッケージを構築するために、オーケストレーション１１２によって使用される。
【０１３８】
更なる実施例では、図では詳細に示されていないが、オーケストレーション１１２のランタイム構成要素が、リレーショナルでＸＭＬネイティブの永続的なサービス、ゲートウェイ、ＳＯＡＰ、ＲＥＳＴ ＡＰＩ、及び、機械学習、クラスタリング、分類子（classifer）ベースの分類及び推薦（recommendation）、コンテクストテキスト分析、テキスト抽出及びモデリング、深い言語分析、表現ベースの英数字パターン検出といった意味的機能（semantic function）を用いて、宣言的ファイルを解釈する変換装置を備える。
【０１３９】
更に別の実施例では、オーケストレーション１１２は、ルールエンジン、及び、JavaやC++のような非宣言型言語のためのスクリプト環境として機能する。こうした実施例では、オーケストレーション１１２は、一連の事象（fact）に対して継続的に一連の規則を適用することで、高次の手続き型又は命令型プログラム言語での規則ベースのプログラミングを提供する。当該規則は、事象の変更、又は、手続き型又は命令型コード（例えばJavaコード）の実行が可能である。幾つかの実施例では、オーケストレーション１１２は、エディタ機能、コードフォーマット、エラーチェック、コマンド実行及びデバッグ、グラフィカルなデバッガーを提供する統合開発環境（ＩＤＥ）に基づく、グラフィカルな規則開発環境を備える。
【０１４０】
また、オーケストレーション１１２は、探索エンジン１１５、ライブダッシュボード構築エンジン１１６、モーフィングエンジン１１７、トゥイーンエンジン１１８、トゥイーンステッパー１１９、統合開発環境（ＩＤＥ）１２１、レンダリングエンジン１２０を備える。
【０１４１】
開示されるライブダッシュボード構築エンジン１１６は、探索エンジン１１５を用いてリアルタイムデータのクエリー結果として開発された複数の分析を表示する、ダッシュボードを設計する。つまり、非技術者ユーザは、探索エンジン１１５からのクエリー結果の複数のセットについて、単一のダッシュボード上に、表示チャートを配置することができる。規則ベースへの変更がダッシュボード上の表示チャートに影響する場合は、ダッシュボード上に残った表示チャートが、その変更を反映して更新される。正確な生のクエリー結果が、ダッシュボード上の全ての表示チャートに亘って、生成され、表示される。
【０１４２】
一実施例では、「ＥＱＬ言語」と呼ばれるリアルタイムクエリー言語が、オーケストレーション１１２によって使用され、結果を整列させる手段としてのデータフローを可能にする。これにより、登録されたイベントタプルについて、その場その場の分析が可能となる。非技術者ユーザは、クエリーパラメータを変更するために、状態定義、状態遷移トリガー、状態遷移条件、状態遷移動作を指定し、更新された規則ベースを用いて生のデータクエリーに基づいて、棒グラフ、円グラフ、散布図といった様々な表示オプションを選択する（表示チャートへのリアルタイムな変更を起こす）ことができる。ＥＱＬでの宣言は、（フィルター、グループ、順番といった）キーワード、識別子、リテラル（literal）、特別な文字から構成される。ＥＱＬは宣言的である。すなわち、クエリーから得たいものを記述する。次に、クエリーエンジンが、それをいかに効果的に行うかを決定する。
【０１４３】
一実施例では、イベントバスを備えるランタイムフレームワークは、ユーザ計算装置上で実行されるアプリケーション１２３、クエリーエンジン（図示せず）、統合開発環境１２１の間の通信を処理する。統合開発環境１２１は、状態、トリガー、状態遷移、応答動作、エンティティ活動レベル、経時的なそれらの変化を含む、複数のレベルの階層で実施される動画の（animated）データ視覚化の表示を提供する。
【０１４４】
統合開発環境１２１は、動画のデータ視覚化の表示を提供し、データ視覚化に適用された形状間の遷移を動画化する動画スクリプトを処理するインターフェースを提供する。動画遷移の例としては、チャートが表示環境に適合し、且つ、切れないようにスケーリングすること、及び、縦横の表示の回転が挙げられる。動画スクリプトは、レンダーされる形状を表し、レンダーされる形状間の遷移の動画を表示する非手続き型データ構造を用いて表される。一実施例では、生成された非手続き型データ構造を表現するためにJSONを用いることができる。
【０１４５】
レンダリングエンジン１２０は、形状及び形状間の遷移の動画を表す非手続き型データ構造を、レンダーされた図（graphic）に変換する。
【０１４６】
他の実施例では、オーケストレーション１１２は、上記で挙げたものと同じ要素を備えていなくても構わず、且つ／又は、代わりに他の／異なる要素を備えていても構わない。或いは、上記で挙げた要素に加えて他の／異なる要素を備えていても構わない。
【０１４７】
出力コネクタ１２２は、オーケストレーション１１２、及び／又は、出力パイプライン２１８からのデータを送信して、当該データをアプリケーション１２３によって消費可能な出力形式に変換する。一実施例では、出力コネクタ１２２は、オーケストレーション１１２からのフルデータプッシュ且つ／又はインクリメンタルデータプッシュを行う。別の実施例では、出力コネクタ１２２は、オーケストレーション１１２からメタデータも提供する。幾つかの実施例では、カスタマイズされた出力コネクタ１２２は、個々のアプリケーション１２３に対して、Connector SDKTMを用いて記述される。
【０１４８】
アプリケーション１２３は、ＩｏＴプラットフォーム１００での動作に適合した構成要素を備える。ＩｏＴプラットフォーム１００、又は、類似物は、アプリケーションサーバノード等のノードによって提供可能である。アプリケーション１２３は、ネットワークを介した、複数のアプリケーションサーバノードと情報の送受信を行うための入力及び出力データハンドラー構成要素を備えることができる。
【０１４９】
一実施例では、アプリケーション１２３は、複数のコンタクト記録、複数のアカウント記録、及び／又は、他の記録（まとめてアプリケーション記録と称する）を含む複数のデータオブジェクトを格納するためのデータストアを備える。幾つかの実施例では、アプリケーション記録には、ユーザ、ファイル、フォルダ、機会、アカウント、イベント、及び／又は、何らかのデータオブジェクトに対応するタプルを含むことができる（但し、これらに限るものではない）。アプリケーション１２３は、データストアに格納された記録を挿入、削除、更新の少なくとも何れかを行うように構成可能なデータ管理構成要素を備えることができる。また、アプリケーション１２３は、アプリケーション記録に関連する活動を監視するよう構成された監視エージェントを備えることができる。例えば、監視エージェントは、パブリック又はプライベートソーシャルネットワーキングサービスを介したユーザの投稿、及び／又は、ユーザの業務用デスクトップコンピュータの電子メールクライアントを探知し、データストアに格納された連絡記録、イベント記録、及び／又は、他のアプリケーション記録に対する更新を監視するよう構成することができる。
【０１５０】
処理されたイベントは、Sales cloudTM、Data.comTM、Service CloudTM、Desk.comTM、Marketing CloudTM、PardotTM、Service CloudTM and Wave AnalyticsTMといったSalesforce.com製品等のアプリケーション１２３によって更に使用できる。例えば、処理されたイベントは、アプリケーション１２３での機会、見込み客（lead）、連絡等を識別する、或いは、Radian6TM、 Buddy MediaTMサービス等の製品によるマーケティング業務を支援するために使用可能である。処理されたイベントは、次に、ソーシャルネットワークプロバイダーによって提供されるマッチングツールを使って、これらのソーシャルネットワーク上におけるこれらの特定のユーザを再発見することにも使用できる。更には、処理されたイベントを、ストリーミングコンテナ１０６及びオーケストレーション１１２が夫々行う集約及び分析から学習された特定のターゲティング（targeting）でレイヤー化することも考えられる。
【０１５１】
一実施例では、ＩｏＴプラットフォーム１００は、クラウドコンピューティング環境に配置することができ、マルチテナントデータベースシステムとして実施してもよい。ここで使用される、マルチテナントデータベースシステムという用語は、データベースシステムのハードウェア及びソフトウェアの様々な要素が、１以上のテナントによって共有されるシステムを指す。例えば、所与のアプリケーションサーバが、多数のテナントへの要求を同時に処理し、所与のデータベーステーブルが、複数のテナントに関する行を格納してもよい。
【０１５２】
幾つかの実施例では、ＩｏＴプラットフォーム１００の要素又は構成要素は、ワークステーション、サーバ、コンピューティングクラスタ、ブレードサーバ、サーバファーム、その他のデータ処理システム又は計算装置を含む様々なタイプのエンジンであってもよい。当該要素又は構成要素は、様々なネットワーク接続を通じてデータベースに通信可能に接続することができる。例えば、ストリーミングコンテナ１０６はネットワーク（例えばインターネット）を介して、バッチコンテナ１０８は直接のネットワークリンクを介して、オーケストレーション１１２はさらに異なるネットワーク接続によって、夫々、接続することができる。
【０１５３】
幾つかの実施例では、ＩｏＴプラットフォーム１００で使用されているデータベースは、マルチテナントデータベースシステムを形成するために、１以上のテナントからの情報を共通のデータベースイメージのテーブルに格納することができる。データベースイメージは、１以上のデータベースオブジェクトを備えることが可能である。他の実施例では、データベースは、リレーショナルデータベース管理システム（ＲＤＢＭＳ）、オブジェクト指向データベース管理システム（ＯＯＤＢＭＳ）、分散ファイルシステム（ＤＦＳ）、スキーマの無いデータベース管理システム、その他のデータ格納システム又は計算装置とすることができる。
【０１５４】
ＩｏＴプラットフォーム１００は、ここでは、特定のブロックに関して説明されているが、当該ブロックは、説明の都合上定義されていると理解され、構成部品の特定の物理的な構成を要求することを意図していない。更に、当該ブロックは物理的に区別される構成要素に対応している必要はない。物理的に区別される構成要素が使用される限りにおいて、（例えばデータ通信に関する）構成要素間の接続を、所望の通りに、有線及び／又は無線とすることが可能である。様々な要素又は構成要素を結合して単一のソフトウェアモジュールとすることができ、複数のソフトウェアモジュールを同じハードウェア上で実行することが可能である。
＜ステートマシン＞
【０１５５】
図３は、エンティティとの相互作用を自動的に多段階で進行させるステートマシン装置３００の一実施例である。図３の略図は、円でエンティティの状態を表し、矢印で或る状態から他の状態への遷移を引き起こす遷移トリガーを表している。具体的には、ステートマシン装置３００は、サーモスタットセンサーといった電気機器のライフサイクル管理を表している。一実施例では、電気機器は、機器のバッテリーレベルやネットワーク接続レベル等の当該機器に関する状態情報を受信するために、定期的にｐｉｎｇを送信している。ステートマシン装置３００で表示される状態には、開始状態３０２、４８時間不良継続状態３０６、長期無イベント状態３１０、ケース作成／更新状態３１４、応答待ち状態３１８、成功状態３２８が含まれる。更に、ステートマシン３００は、イベントトリガー３０１、３０９、３２０、及び、時間トリガー３０３、３０７、３１１、３１３という、２種類の遷移トリガーを処理する遷移プロセッサを備える。更に、常時規則が満足される３２２の場合に、システムは成功状態３２８を維持する。あるイベントがＮＲＴデータストリームから登録されると、遷移プロセッサによって処理されるイベントトリガーは、状態遷移を引き起こす。時間トリガーは、タイマーがオーバーランした際に、状態遷移を引き起こす。他の実施例では、イベントの組み合わせが登録される時に生じる既定のトリガー、及び、累積トリガーをオーバーライドするカスタムトリガー等、様々な遷移トリガーを定義することが可能である。
【０１５６】
次に、図３に示すサーモスタットとの相互作用の多段階進行について見ると、装置エラーがＮＲＴイベントストリームで検出されると、装置エラーイベントトリガー３０１が登録される。装置エラーイベントトリガー３０１は、Salesforce Service CloudTMといったサービスアプリケーションにケースを生成することで検出されたエラーを修正するよう設計されたチケットワークフローを開始させる。このチケットワークフローの開始は、開始状態３０２で表される。イベントストリームが、装置エラーが検出されてから３日間修正されていないことを確認すると、Ｄａｙ３タイマートリガー３０３がチケットワークフローを開始状態３０２から４８時間不良継続状態３０６に遷移させる。４８時間不良継続状態３０６から、次の状態遷移が、Ｄａｙ５タイマートリガー３０７又は不健康イベントトリガー３０９によって引き起こされる。イベントストリームが、装置エラーが検出されてから５日間修正されていないことを確認すると、Ｄａｙ５タイマートリガー３０７は、チケットワークフローを、４８時間不良継続状態３０６から長期無イベント状態３１０に遷移させる。別の実施例では、装置のバッテリーレベルが低い、又は、装置のネットワーク接続が悪い、或いは、その両方の状態があることをイベントストリームが確認すると、不健康イベントトリガー３０９が、チケットワークフローを、４８時間不良継続状態３０６からケース作成／更新状態３１４に遷移させる。
【０１５７】
チケットワークフローは、長期無イベント状態３１０に達すると、即時タイマートリガー３１１を用いてすぐにケース作成／更新状態３１４に遷移する。一旦ケース作成／更新状態３１４になると、ステートマシン装置３００を利用するアプリケーションが、ケースをオープンしたか、それに失敗したかを確認することで、応答したという事実に基づいて、チケットワークフローは、即時タイマートリガー３１３によって、応答待ち状態３１８に遷移する。
【０１５８】
一旦、応答待ち状態３１８になると、チケットワークフローは、ケース応答が受信されたことを確認するケース応答イベントトリガー３２０が登録されると、応答待ち状態３１８から４８時間不良継続状態３０６に遷移する。
【０１５９】
幾つかの実施例では、常時規則満足３２２が登録されると、チケットワークフローの様々な状態が、成功状態３２８に遷移する。一実施例では、成功状態３２８は、ＮＲＴイベントストリームで、装置の健康が良好であること、すなわち、装置バッテリーレベルが高く、装置のネットワーク接続が良いことを確認するイベントを受領したことを表す。成功状態３２８に達した時はいつでも、ステートマシン装置３００は安定した状態にある。
＜データエントリカラムナ＞
【０１６０】
図４Ａ、図４Ｂ、図４Ｃは、図３に示すステートマシンを生成するために、宣言的入力を受け付けるデータエントリカラムナ４００Ａ〜Ｃを示している。更に一般的には、データエントリカラムナ４００Ａ〜Ｃは、非技術ユーザが、洗練されたユーザ管理及びリソース供給オペレーション、アプリケーションライフサイクル管理オペレーション（例えば、Salesforce ThunderTM４０１）、トラフィック監視オペレーション、活動探知オペレーション、アプリケーションモデリングオペレーションを表す複雑なステートマシンを、宣言によって設計できるようにする。
【０１６１】
特に、データエントリカラムナ４００Ａ〜Ｃは、非技術ユーザが、ステートマシン装置の状態、タイムベース遷移トリガー、イベントベース遷移トリガー、条件の定義、状態遷移に応じた代わりの動作を容易に指定できるようにする。幾つかの実施例では、データエントリカラムナ４００Ａ〜Ｃは、非技術ユーザが、ステートマシンの様々な変数及びパラメータを指定する単純な表現を使用できるようにする。
【０１６２】
図４Ａについて見ると、データエントリカラムナ４００Ａによって、ユーザは、ステートマシン装置に関して、様々なイベントベース遷移トリガー４０２を識別することができる。図４Ａに示す例では、「装置イベントタイプ」４０３と題するイベントベース遷移トリガー４０３は、ドロップダウンメニュー４０４から選択フィールドの内の１つを選択することで、生成される。別の実施例では、カスタムのイベントベース遷移トリガーが、「イベントタイプ追加」ウィジット４０８をクリックすることで、生成される。装置イベントタイプトリガー４０３については、非技術ユーザによってチェックボックス４０５が選択されると、装置イベントタイプトリガー４０３が、図３のチケットワークフロー（図４ではオーケストレーションと称している）を開始するように、条件が非技術ユーザによって指定される。更に、条件４０６が非技術ユーザによって設定される。条件４０６は、自身が取り込むデータベースフィールドの少なくとも１つの値に対して評価される。図４Ａで使用される条件４０６の例としては、装置バッテリーレベルが低いかどうか、又は、装置のネットワーク接続が悪いかどうかが挙げられる。この例としての条件４０６は、以下の簡単な表現を用いて表される。
!device.battery_good||!device.wifi_good
【０１６３】
条件が満足されると、装置イベントタイプトリガー４０３が実行される。他の実施例では、装置イベントタイプトリガー４０３の記述４０７は、非技術ユーザから受信される。
【０１６４】
更に進むと、データエントリカラムナ４００Ａの条件定義で使用される様々な変数４０９（例えば、装置ＩＤ、ケース応答、サブジェクト、最後のサブジェクト、ケースＩＤ）が、非技術ユーザによって指定され、各イベントベース遷移トリガー４１０にマッピングされる。一実施例では、変数４０９を取り込む各条件４１１も、非技術ユーザによって識別される。別実施例では、変数４０９の各値４１２は、各変数４０９の初期値記述４１３と共に、非技術ユーザによって指定される。更に、カスタム変数が、「変数追加」ウィジット４１４をクリックすることで生成可能である。上記の指定は、簡単な表現、ドロップダウンメニュー、チェックボックス、ドラッグ−ドロップ機能等の宣言的又は視覚的入力を用いて行うことができる。
【０１６５】
更に、非技術ユーザは、カラムナ４１５を用いて、ステートマシンの様々な状態（例えば、常時、開始、４８時間不良継続、長期無イベント、ケース作成／更新、応答待ち）を識別できる。また、非技術ユーザは、ある状態から別の状態への遷移を引き起こす遷移トリガー４１６、満足されると遷移トリガー４１６が実行される条件４１７、遷移トリガー４１６に応答して行われる動作４１８によって、カラムナ４１５を介して特定の状態にリンクすることができる。他の実施例では、カラムナ４１５における常時状態の記述４１９及びそのトリガー、条件、動作を、非技術ユーザから受け取る。上記の指定は、簡単な表現、ドロップダウンメニュー、チェックボックス、ドラッグ−ドロップ機能等の宣言的又は視覚的入力を用いて行うことができる。図４Ａに示す特定の状態定義は、「常時（Always）」と題するグローバル状態が生成された（図３における成功）ことを示している。装置のバッテリーレベルが良好であり、且つ、装置のネットワーク接続が良好であるという条件が満足された場合に、常時規則が満足される。この例示した条件は、以下の簡単な表現で表される。
device.battery_good&&device.wifi_good
【０１６６】
上記条件が満足される時、成功状態が維持される。
【０１６７】
図４Ｂに示す開始状態４２０について見ると、イベントストリームが、装置エラーが検出されてから３日間修正されていないことを確認すると、動作４２３が実行される、すなわち、開始状態４２０が４８時間不良継続状態４２５へ遷移するように、非技術ユーザは、Ｄａｙ３タイマータイプトリガー４２１を指定する。他の実施例では、開始状態４２０の記述４２４及びそのトリガー、条件、動作を、非技術ユーザから受け取る。
【０１６８】
図４Ｂのデータエントリカラムナ４００Ｂに示す４８時間不良継続状態については、非技術ユーザが、装置イベントタイプトリガー４２６とＤａｙ５タイマータイプトリガー４３０の２つの遷移トリガーを指定する。装置イベントタイプトリガー４２６は、条件４２７を満足することで起動され、Ｄａｙ５タイマータイプトリガー４３０は、装置エラーが検出されてから５日間修正されていないことによって起動される。図４Ｂに例示した条件４２７は、３つの副条件４２７ａ〜ｃ、すなわち、装置バッテリーレベルが低く、且つ、装置ネットワーク接続が悪いかどうかに関する第１副条件４２７ａ、装置のバッテリーレベルが低いかどうかのみに関する第２副条件４２７ｂ、装置ネットワーク接続が悪いかどうかのみに関する第３副条件４２７ｃを含む。例示した条件４２７及びその副条件４２７ａ〜ｃは、非技術ユーザによって夫々指定される以下のような簡単な表現で表される。
!device.battery_good&&!device.wifi_good
!device.battery_good
!device.wifi_good
【０１６９】
これらの副条件の何れか１つが満足されると、動作４２８が実行される。動作４２８には、例示した条件４２７の少なくとも１つの副条件４２７ａ〜ｃに個別に応答する、３つの異なる副動作４２８ａ〜ｃが含まれる。第１副動作４２８ａは、第１副条件４２７ａに応答し、装置のバッテリーレベルが低く、且つ、装置ネットワーク接続が悪いことを示すサブジェクトを生成する。第２副動作４２８ｂは、第２副条件４２７ｂに応答して、単に装置のバッテリーレベルが低いことを示すサブジェクトを生成する。第３副動作４２８ｃは、第３副条件４２７ｃに応答して、単に装置ネットワーク接続が悪いことを示すサブジェクトを生成する。
【０１７０】
これら３つの副動作４２８ａ〜ｃに加えて、動作４２８は、４８時間不良継続状態４２５からケース作成／更新状態４３６への状態遷移を引き起こす「マスト（must）動作４２８ｄ」も含む。マスト動作は、副条件４２７ａ〜ｃのどれが満足しているか、副動作４２８ａ〜ｃのどれが実行されているかに関わらず、一実施に従って実行される。例示した動作４２８と副動作４２８ａ〜ｃ、及び、マスト動作４２８ｄは、非技術ユーザによって夫々指定される以下のような簡単な表現で表される。
subject = “Battery voltage low and weak Wi-Fi”
subject = “Battery voltage low”
subject = “Wi-Fi weak”
Change state to Create or Update a case
【０１７１】
更に、Ｄａｙ５タイマータイプトリガー４３０がタイムアウトすると、動作４３１が実行され、動作４３１は、状態を４８時間不良継続状態４２５から長期無イベント状態４３２への遷移を引き起こす。例示した動作４３１は、非技術ユーザによって夫々指定される以下のような簡単な表現で表される。
Change state to No Events in a Long Time
【０１７２】
他の実施例では、４８時間不良継続状態４２５の記述４２９及びそのトリガー、条件、動作を、非技術ユーザから受け取る。上記全ての指定は、簡単な表現、ドロップダウンメニュー、チェックボックス、ドラッグ−ドロップ機能等の宣言的又は視覚的入力を用いて行うことができる。
【０１７３】
図４Ｃのデータエントリカラムナ４００Ｃに示す長期無イベント状態４３２に関しては、非技術ユーザは、長期無イベント状態４３２からケース作成／更新状態４３６への即時状態遷移を引き起こす即時タイマータイプトリガー４３３を指定する。トリガー４３３に応答して実行される動作４３４には、２つの副動作４３４ａと４３４ｂが含まれる。第１副動作４３４ａは、長い間イベントが登録されていないことを示すサブジェクトを生成する。第２副動作４３４ｂは、「マスト動作」であり、状態遷移を引き起こす。例示した動作４３４とその副動作４３４ａ、及び、マスト動作４３４ｂは、非技術ユーザによって夫々指定される以下のような簡単な表現で表される。
subject = “No Events in a Long Time“
Change state to Create or Update a case
【０１７４】
他の実施例では、長期無イベント状態４３２の記述４３５及びそのトリガー、条件、動作を非技術ユーザから受け取る。上記全ての指定は、簡単な表現、ドロップダウンメニュー、チェックボックス、ドラッグ−ドロップ機能等の宣言的又は視覚的入力を用いて行うことができる。
【０１７５】
ケース作成／更新状態４３６に関して、非技術ユーザは、ケース作成／更新状態４３６から応答待ち状態４４１への即時状態遷移を引き起こす即時タイマータイプトリガー４３７を指定する。但しここでは、即時タイマータイプトリガー４３７は、条件４３８を満足した場合に起動される。例示した条件４３８は、２つの副条件４３８ａ及び４３８ｂを備える。第１副条件４３８ａは、作成されたケースフォームのフィールドが空白であるかを評価する。第２副条件４３８ｂは、最後に作成されたケースフォームのフィールドが埋められているか、且つ、評価されるサブジェクトが最後に作成されたケースのサブジェクトであるかを評価する。
【０１７６】
例示した条件４３８及びその副条件４３８ａ〜ｂは、非技術ユーザによって夫々指定される以下のような簡単な表現で表される。
ISBLANK(case)
!ISBLANK(caseID) && (subject != lastSubject)
【０１７７】
副条件４３８ａ〜ｂの少なくとも１つが満足されると、動作４３９が実行される。動作４３９は、副動作４３９ａ、４３９ｂ、４３９ｃを含み、応答待ち状態４４１への状態遷移を引き起こす。
【０１７８】
例示した動作４３９及びその副条件４３９ａ〜ｃは、非技術ユーザによって夫々指定される以下のような簡単な表現で表される。
Upsert? in?
Change state to Waiting for a Response
Upsert? in? Change state to Waiting for a Response
【０１７９】
他の実施例では、ケース作成／更新状態４３６の記述４４０及びそのトリガー、条件、動作を非技術ユーザから受け取る。上記全ての指定は、簡単な表現、ドロップダウンメニュー、チェックボックス、ドラッグ−ドロップ機能等の宣言的又は視覚的入力を用いて行うことができる。
【０１８０】
応答待ち状態４４１に関して、非技術ユーザは、ケース応答が受け取られたことを確認するケース応答イベントタイプトリガー４４２を指定する。ケース応答イベントタイプトリガー４４２は、ケース応答が問題なく登録されたかどうかを評価する条件４４３が満足されることによって起動される。
【０１８１】
条件４４３が満足されると、動作４４４が実行される。動作４４４は、副動作４４４ａ、４４４ｂ、４４４ｃ、４４４ｄを含み、４８時間不良継続状態４２５への状態遷移を引き起こす。
【０１８２】
例示した動作４４４及びその副動作４４４ａ〜ｄは、非技術ユーザによって夫々指定される以下のような簡単な表現で表される。
caseID = caseResponse.ID
lastSubject = subject
caseResponse = null
Change state to 48 Hours still Bad
【０１８３】
他の実施例では、応答待ち状態４４１の記述４４５及びそのトリガー、条件、動作を非技術ユーザから受け取る。上記全ての指定は、簡単な表現、ドロップダウンメニュー、チェックボックス、ドラッグ−ドロップ機能等の宣言的又は視覚的入力を用いて行うことができる。
【０１８４】
他の実施例では、様々な使用ケース及びオペレーションに基づく、ステートマシン及びデータエントリカラムナが実施可能であり、その幾つかは、特定の実施例として以下で述べる。
【０１８５】
他の実施例では、様々な使用ケース及びオペレーションに基づく、ステートマシン及びデータエントリカラムナが、図示されていないが、実施可能である。例えば、図３に見られるような、ダイアグラムアプローチや、図４Ａ〜４Ｃに関して上記で述べたようなデータを追加するためのＧＵＩによって、ＧＵＩ表示の分節（articulation）が工夫されるかもしれない。非技術ユーザは、ステートダイアグラム表示の分節を通じてデータを入力することが考えられる。
【０１８６】
上記実施例は、単なる例であって、上記で列挙した、高次のプログラム言語、低次のプログラム言語、機能プログラム言語、マークアッププログラム言語、命令プログラム言語であっても、別のプログラム言語で同様に適用可能である。
【０１８７】
以下に述べるスロットル及び合成イベントは、オーケストレーションにおける２つの典型的なパターンである。
＜フローチャート＞
【０１８８】
図１５は、準リアルタイム（ＮＲＴ）データストリームの多段階処理における強力な順序付けを提供するフローチャート１５００の一実施例を示している。フローチャート１５００は、少なくとも一部は、コンピュータ又は他のデータ処理システムで（例えば、情報の受信又は読み出し、当該情報の処理、結果の格納、当該結果の送信を行うよう構成された１以上のプロセッサによって）実施可能である。他の実施例では、図１５に示す例とは異なる順番で動作を行ってもよく、且つ／又は、図１５に示す例とは異なる、又は、少ない、又は、追加の動作を行ってもよい。複数の動作は、幾つかの実施例で組み合わせることができる。便宜上、このワークフローについて、方法を実行するシステムを参照して説明する。当該システムは、必ずしも、本方法の一部である必要はない。
【０１８９】
動作１５１０で、本方法は、上述したように、１以上の準リアルタイム（ＮＲＴ）データストリームからのデータを処理する複数の物理スレッドを含むコンピューティンググリッドを操作する工程を含む。
【０１９０】
動作１５２０で、本方法は、上述したように、ＮＲＴデータストリームからのデータを、コンピューティンググリッドで多段階に亘って処理するためのパイプラインにおけるバッチとして、待ち行列に追加する工程を含む。
【０１９１】
動作１５３０で、本方法は、上述したように、バッチステージに関する物理スレッドへのバッチ単位のディスパッチを制御するグリッドコーディネータと通信して、グリッドスケジューラにバッチに関する現在のバッチステージ情報を維持する工程を含む。
【０１９２】
動作１５４０で、本方法は、上述したように、グリッドコーディネータで現在のバッチステージ情報が受領されたことに応答して、当該情報において識別された現在のバッチステージに関して、ディスパッチを保留にするバッチ単位を決定する工程を含む。
【０１９３】
動作１５５０で、本方法は、上述したように、現在のバッチステージが依存する前回のバッチステージに関してバッチ単位を処理し、現在のバッチステージに関して保留のタスクを登録した物理スレッドを識別する工程を含む。
【０１９４】
動作１５６０で、本方法は、上述したように、前回のバッチステージに関するバッチ単位の処理が完了したことに続いて、現在のバッチステージに関するバッチ単位を、識別された物理スレッドへディスパッチする工程を含む。
【０１９５】
一実施例では、グリッドスケジューラがコンピューティンググリッドにおけるパイプラインを探知し、バッチの実行、及び、完了したステージの出力に依存する下流ステージの実行をスケジューリングする。
【０１９６】
別の実施例では、グリッドスケジューラは、コンピューティンググリッドにおける各パイプラインに、パイプライン識別子（ＩＤ）を割り当てる。更なる実施例では、グリッドスケジューラは、パイプラインにおける各バッチにバッチ識別子（ＩＤ）を割り当てる。更に別の実施例では、グリッドスケジューラが、バッチの各処理ステージにステージ識別子（ＩＤ）を割り当てる。
【０１９７】
一実施例では、グリッドスケジューラは、各バッチが実行される毎に、パイプラインＩＤ、バッチＩＤ、ステージＩＤをグリッドコーディネータに伝達する。別の実施例では、本方法は、処理ステージが互いに依存していない場合に、１以上のパイプラインの１以上のバッチに関して、複数の処理ステージを同時に実行する工程を更に含む。
＜スロットル＞
【０１９８】
スロットルは、あるイベントが動作を発生させる率を制限する。「この期間にこの動作をこんなに何回も行ってはならない」という意味を与えるために、毎出力動作に、スロットルタイム期間（７５５）を追加することで、出力動作をスロットルすることができる。この意味は、出力動作ダイアログとの関連で表すことができ、オーケストレーションによってレンダー及び管理することができる。動作が既に指定回数行われていた場合は、当該動作を行う次の要求が、当該期間が経過するまで無視される。スロットルは、バッテリーが低下している、又は、サブスクリプション（subscription）の期限が近づいている旨の顧客への警告といった、ビジネス環境において予想されるケースを処理するための効果的な機構である。
【０１９９】
スロットルは、幾つかのケースでは、最終的に持続不可能なリソースの消費を避けるために、又は、タイムベース遷移トリガーとイベントベース遷移トリガーの内、少なくとも１つによって引き起こされる状態遷移に対応した動作の受信者を過剰に刺激することを避けるために実施される。追加するための更なる情報がある時のみ２回目の電子メールを送信するといった、スロットルのより複雑なケースは、変数を更に設定又はテストする、或いは、状態を追加することによって、対処することができる。必要な機能は、次に説明するように、規則ベース入力を用いて、データエントリカラムナに追加できる。
【０２００】
図５Ａ、図５Ｂ、図６Ａ、図６Ｂは、上述したストットル機能を実施する状態を追加するための宣言的入力を受け付けるデータエントリカラムナ５００Ａ、５００Ｂ、６００Ａ、６００Ｂを示している。より一般的には、データエントリカラムナ５００Ａ、５００Ｂ、６００Ａ、６００Ｂによって、非技術ユーザは、洗練されたユーザ管理及びリソース提供オペレーション、アプリケーションライフサイクル管理オペレーション（例えばSalesForce IoT CloudTM 502）、トラフィック監視オペレーション、活動探知オペレーション、アプリケーションモデリングオペレーションを表す複雑なステートマシンの設計に、スロットル機能を宣言により追加することが可能となる。
【０２０１】
特に、データエントリカラムナ５００Ａ、５００Ｂ、６００Ａ、６００Ｂによって、非技術ユーザは、状態遷移に応答して動作がトリガーされる前に発生するイベントに関して、単位数毎の回数を容易に指定することが可能となる。幾つかの実施例では、データエントリカラムナ５００Ａ、５００Ｂ、６００Ａ、６００Ｂによって、非技術ユーザは、ステートマシンの様々な変数及びパラメータを指定するための簡単な表現を利用できるようになる。一実施例では、スロットル表現には、第１イベントで始まる１回だけの期間を指定する時間パラメータが含まれる。当該期間中は、第１イベントと一致する特徴を有する第２イベントは無視又は放棄される。
【０２０２】
一実施例では、図５Ａに示されるように、ユーザは、繰り返し制限動作５０６へのリンクを活性化させることができる。結果は、図５Ｂの例に示される。非技術ユーザは、開始（Started）５２２からの状態遷移を引き起こす、常時（Always）５２４を指定する規則（RULES）５１２を使用することができる。尚、“IF”カラム５２６で指定された表現が満足されると、動作５２８がトリガーされる。ユーザは“IF”カラム５２６を選択すると、動作を繰り返す前にイベントが生じる回数を任意で指定することができる。図６Ａは、カウントが２回であること、及び、単位６６４を選択するためのドロップダウンを示している。指定されたスロットルは、各出力動作に対してスロットル期間を追加して、選択された時／イベントタイプ（When/Event Type）及び“IF”条件の下にある全ての動作に適用される。図６Ｂは、「１月につき、２回以上この動作を行ってはならない」という意味を与えるよう構成されたスロットル機能６８６を例示している。スロットルは、ユーザが“Ｘ”６８７をクリックしてそれを削除しない限り、データエントリカラムナ内の“IF”セルの下部に残る。
【０２０３】
図４Ｂの例は、図７に示す「２４時間毎に２回」７５５といったスロットルイベントを含むことが可能である。ユーザは、更なるスロットル規則を含めるために、繰り返し制限動作７７５を選択することができる。
＜合成イベント＞
【０２０４】
合成イベントは、より基本的なイベントの特定のパターンの発生を反映する。ユーザは、一般的に、表現をイベントとして機能させることを望む。例えば、ユーザは、バッテリーの電圧が閾値を下回る時はいつでも動作が行われるようにオーケストレーションを記述して、表現がイベントとして機能するようにオーケストレーションを記述することを望むかもしれない。これは、“battery.voltage<2.7”といった表現を条件４２７のカラムに記載することで、表現してもよい。この合成イベントは、“エッジトリガー（edge-triggered）”イベントとも称され、次の２つの状況の何れかの下で起動（fire）する。２つの状況とは、状態への入力時に表現が“真（true）”である場合と、状態への入力時は表現が“偽（false）”であって、後に、当該状態のままで表現が“真”となる場合である。表現が“偽”となって、その後、当該状態のまま再び“真”になる場合、イベントは再び起動する。ユーザインターフェースは、Boolean表現のみが入力されることを保証するために確認をする。つまり、合成イベントは、変数の値、又は、変数に分解する表現をイベントとして扱う。最初に状態を入力した時の変数の値をテストし、その後、当該変数の値に対する何らかの変更についてテストを行う。
【０２０５】
“battery.voltage <= 2.7 during 48 hours AND device temperature > 140 during 48 hours”といった複雑な集約及び制限に関してチェックを行う状態に対する必要性を省くために、合成イベントはオーケストレーションに含めることができる。
＜プロファイル＞
【０２０６】
オーケストレーションは、ワークフローが直面する重要な問題の一つである、イベントが到着し得る順番が予測できないという問題を解決することができる。オーケストレーションに関するプロファイルは、オーケストレーションのオブジェクトについての現在の情報を提供する。プロファイルは、イベント及び状態と共に、オーケストレーションを指定する、すなわち、到着するかもしれない全てのイベント、及び、各イベントに応答して（応答はオーケストレーションの状態によって異なる可能性がある）オーケストレーションがすべきことを一覧にするために、使用される。
【０２０７】
ステートマシンのフォームを減らす幾つかの機構を、一方の軸にイベントを、他方の軸に変数及びプロファイルの条件をとったマトリックスに、組み合わせることが可能である。状態の使用の単純化に加えて、このマトリックスフォームによって、変数及びプロファイルの各条件と対になった各イベントの効果をユーザに検討させることで、ユーザはより少ないエラーでオーケストレーションを記述することができる。
＜フローチャート＞
【０２０８】
図８Ａは、非プログラミングユーザ向けの、エンティティ管理ワークフローの生成を単純化するフローチャート８００の実施例を示している。フローチャート８００は、少なくとも一部は、コンピュータ又は他のデータ処理システムで（例えば、情報の受信又は読み出し、当該情報の処理、結果の格納、当該結果の送信を行うよう構成された１以上のプロセッサによって）実施可能である。他の実施例では、図８Ａに示す例とは異なる順番で行ってもよく、且つ／又は、図８Ａに示す例とは異なる又は少ない又は追加の動作を行ってもよい。複数の動作は、幾つかの実施例で組み合わせることができる。便宜上、このワークフローについて、方法を実行するシステムを参照して説明する。当該システムは、必ずしも、本方法の一部である必要はない。
【０２０９】
動作８０１で、本方法は、人間−機械の相互作用に依存せずに機械によって生成された機械生成イベントを処理するワークフローステートマシンにおいて、複数のケース−ステータス状態を表示する。
【０２１０】
動作８０２で、本方法は、第１イベント後の少なくとも第１ケース−ステータス状態の間に、入力された第２イベントを無視するか、又は、処理するかを決定するイベントフィルタリング条件をメモリに記録する。
【０２１１】
動作８０３で、本方法は、イベントフィルタリング条件の、一定の期間内の回数に制限を指定する整数のカウントパラメータであって、当該制限を超えた、一致する特徴を持った追加のイベントは無視又は放棄され、当該カウントパラメータを初期化する工程を含む。
【０２１２】
動作８０４で、本発明は、入力された機械生成イベントを処理する命令をワークフローエンジンにロードし、少なくともケース−ステータス状態及び第１イベントフィルタリングに応じて選択された命令を実行する工程を含む。
【０２１３】
幾つかの実施例では、宣言的入力は、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領される。一時実施例では、宣言的入力は、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つを含む。別の実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。更に別実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
＜フローチャート＞
【０２１４】
図８Ｂは、非プログラミングユーザ向けの、エンティティ管理ワークフローの生成を単純化するフローチャート８１０のサーバ側の実施例を示している。フローチャート８１０は、少なくとも一部は、コンピュータ又は他のデータ処理システムで（例えば、情報の受信又は読み出し、当該情報の処理、結果の格納、当該結果の送信を行うよう構成された１以上のプロセッサによって）実施可能である。他の実施例では、図８Ｂに示す例とは異なる順番で動作を行ってもよく、且つ／又は、図８Ｂに示す例とは異なる又は少ない又は追加の動作を行ってもよい。複数の動作は、幾つかの実施例で組み合わせることができる。便宜上、このワークフローについて、方法を実行するシステムを参照して説明する。当該システムは、必ずしも、本方法の一部である必要はない。
【０２１５】
動作８１１で、上述したように、ステートマシンビルダーで実行される本方法は、エンティティとの相互作用の自動化された多段階進行を実施させるステートマシンを指定する、宣言的入力を受け付けるデータエントリカラムナを表示のために生成する工程を含む。幾つかの実施例では、データエントリカラムナは、多段階進行における状態に関する少なくとも１つのカラム、タイムベース遷移トリガー、イベントベース遷移トリガー、条件の定義、状態遷移に応じた択一的な動作を含む。
【０２１６】
一実施例では、データエントリカラムナへの入力を示すデータは、状態遷移に応じた動作の実行に続いて得られる少なくとも１つの状態の仕様（specification）を更に含む。別の実施例では、データエントリカラムナへの入力を示すデータは、全ての状態に適用されるグローバルな状態遷移に応じた少なくとも１つの常時動作（Always Action）の仕様を更に含む。更に別の実施例では、データエントリカラムナへの入力を示すデータは、エンティティの複数の状態の仕様を更に含む。
【０２１７】
動作８１２で、本方法は、上述したように、一定の期間が経過すると状態遷移を引き起こすタイマーによって、及び、状態遷移を引き起こすイベントによって、択一的に指定される状態遷移トリガーを定義するデータエントリカラムナへの宣言的入力を受領する。幾つかの実施例では、エンティティが電気機器の場合、当該電気機器の状態には、少なくとも、オン、オフ、スタンバイ、電源投入、電源切断、全電力のパーセンテージ、ネットワーク接続の範囲の内、少なくとも１つが更に含まれる。幾つかの実施例では、エンティティがユーザの場合、ユーザの状態には、熱心な、移り気な（churned）、自然消滅（lapsed）の内、少なくとも１つを更に含む。
【０２１８】
動作８１３で、本方法は、上述したように、状態遷移に応答して実行される選択された択一的な動作を指定するデータエントリカラムナへの宣言的入力を、ステートマシンビルダーが受領する工程を含む。
【０２１９】
動作８１４で、本方法は、上述したように、宣言的入力、又は、当該宣言的入力から構築されるワークフローステートマシン装置を保存する工程を含む。
【０２２０】
幾つかの実施例では、宣言的入力を、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領する。一実施例では、宣言的入力には、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つが含まれる。別の実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。更に別の実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
【０２２１】
図８Ｃは、非プログラミングユーザ向けの、エンティティ管理ワークフローの生成を単純化する典型的な方法フローチャート８２０のクライアント側の実施例を示している。フローチャート８２０は、少なくとも一部は、コンピュータ又は他のデータ処理システムで（例えば、情報の受信又は読み出し、当該情報の処理、結果の格納、当該結果の送信を行うよう構成された１以上のプロセッサによって）実施可能である。他の実施例では、図８Ｃに示す例とは異なる順番で動作を行ってもよく、且つ／又は、図８Ｃに示す例とは異なる又は少ない又は追加の動作を行ってもよい。複数の動作は、幾つかの実施例で組み合わせることができる。便宜上、このワークフローについて、方法を実行するシステムを参照して説明する。当該システムは、必ずしも、本方法の一部である必要はない。
【０２２２】
動作８２１で、本方法は、上述したように、エンティティとの相互作用の自動化された多段階進行を実施させるステートマシンを指定する、宣言的入力を受け付けるデータエントリカラムナを受領する工程を含む。幾つかの実施例では、データエントリカラムナは、多段階進行における状態に関する少なくとも１つのカラム、タイムベース遷移トリガー、イベントベース遷移トリガー、条件の定義、状態遷移に応じた択一的な動作を含む。
【０２２３】
一実施例では、データエントリカラムナへの入力を示すデータは、状態遷移に応じた動作の実行に続いて得られる少なくとも１つの状態の仕様を更に含む。別の実施例では、データエントリカラムナへの入力を示すデータは、全ての状態に適用されるグローバルな状態遷移に応じた少なくとも１つの常時動作（Always Action）の仕様を更に含む。更に別の実施例では、データエントリカラムナへの入力を示すデータは、エンティティの複数の状態の仕様を更に含む。
【０２２４】
動作８２２で、本方法は、上述したように、エンティティの複数の状態、一定の期間が経過すると状態遷移を引き起こすタイマー及びイベント値が条件を満たすと状態遷移を引き起こす宣言的入力によって択一的に指定される状態遷移トリガー、状態遷移に応答した動作の実行に続いて得られる少なくとも１つの状態、全ての状態に適用されるグローバルな状態遷移に応じた少なくとも１つの常時動作を定義するデータエントリカラムナへの入力を示すデータを送信する工程を含む。
【０２２５】
幾つかの実施例では、エンティティが電子機器の場合、当該電気機器の状態には、オン、オフ、スタンバイ、電源投入、電源切断、全電力のパーセンテージ、ネットワーク接続の範囲の内、少なくとも１つが更に含まれる。幾つかの実施例では、エンティティがユーザの場合、ユーザの状態には、熱心な、移り気な、自然消滅の内、少なくとも１つを更に含む。
【０２２６】
本方法では更に、当該条件が、自身が取り込むデータベースフィールドの少なくとも１つの値に対して評価され、状態遷移に応答して実施される択一的な動作を制御することを含む。
【０２２７】
幾つかの実施例では、入力イベントは、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領される。一実施例では、宣言的入力は、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つを含む。別の実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。更に別の実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
【０２２８】
図９は、非プログラミングユーザ向けの、エンティティ管理ワークフローの生成を単純化する典型的な方法フローチャート９００の実施例を示している。フローチャート９００は、少なくとも一部は、コンピュータ又は他のデータ処理システムで（例えば、情報の受信又は読み出し、当該情報の処理、結果の格納、当該結果の送信を行うよう構成された１以上のプロセッサによって）実施可能である。他の実施例では、図９に示す例とは異なる順番で動作を行ってもよく、且つ／又は、図９に示す例とは異なる又は少ない又は追加の動作を行ってもよい。複数の動作は、幾つかの実施例で組み合わせることができる。
【０２２９】
動作９１０で、本方法は、人間−機械の相互作用に依存せずに機械によって生成された機械生成イベントを処理するワークフローステートマシンにおいて、ケース−ステータス状態を表示する工程を含む。
【０２３０】
動作９２０で、本方法は、複数のケース−ステータス状態における少なくとも最初のケース−ステータス状態の間に、入力された第２イベントを無視するか処理するかを決定するために、イベントプリプロセッサによって使用されるイベントフィルタリング条件をメモリに記録する工程を含む。
【０２３１】
動作９３０で、本方法では、イベントフィルタリング条件は、第１イベントで開始する１回だけの期間を指定する時間パラメータを含み、当該期間中は第１イベントと合致する特徴を持った第２イベントが無視又は放棄される。
【０２３２】
動作９４０で、本方法は、入力された機械生成イベントを処理する命令を、遷移プロセッサ及びイベントプリプロセッサを備えるワークフローエンジンステートマシン装置にロードし、少なくともケース−ステータス状態及びイベントフィルタリング条件に応じて選択される命令を実行する工程を含む。
【０２３３】
本方法では更に、当該条件が、自身が取り込むデータベースフィールドの少なくとも１つの値に対して評価され、状態遷移に応答して実施される択一的な動作を制御することを含む。
【０２３４】
幾つかの実施例では、宣言的入力は、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領される。一実施例では、宣言的入力は、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つを含む。別の実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。更に別の実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
＜マルチテナント統合＞
【０２３５】
図１０は、１以上の実施例に従った図１のＩｏＴプラットフォーム１００との相互作用に適した典型的なマルチテナントシステム１０００のブロック図である。
【０２３６】
図１のＩｏＴプラットフォーム１００は、マルチテナントシステムを用いて実施することができる。その点で、図１０は、１以上の実施例に従った図１のＩｏＴプラットフォーム１００との相互作用に適した典型的なマルチテナントシステムの概念的なブロック図を示している。
【０２３７】
一般に、図１０に示すマルチテナントシステム１０００は、複数のテナント間で共有される共通データベース１０３０（或いは、ここでは「マルチテナントデータベース」と称する）からのデータ１０３２に基づく仮想アプリケーション１０２８を動的に生成及び支援するサーバ１００２を備える。仮想アプリケーション１０２８Ａ及び１０２８Ｂによって生成されるデータ及びサービスは、ネットワーク１０４５を介して、クライアント装置１０４０Ａ又は１０４０Ｂの幾つかに、要望通りに、提供される。仮想アプリケーション１０２８Ａ及び１０２８Ｂは、マルチテナントシステム１０００に加入（subscribe）している様々なテナントの夫々に対して、データベース１０３０内のデータ１０３２へのアクセスを確実に提供するアプリケーションプラットフォーム１０１０を用いて、ランタイム（又はオンデマンド）で適切に生成される。制限されない１つの例に従って、マルチテナントシステム１０００は、複数のテナントの認証されたユーザの幾人かを支援可能な、オンデマンドマルチテナントユーザ関係管理（ＣＲＭ）システムの形で実施される。
【０２３８】
ここで使用される「テナント」又は「組織（organization）」は、マルチテナントデータベース１０３０内のデータの共通のサブセットへのアクセスを共有する１以上のユーザのグループを指している。この点で、各テナントは、各テナントに関連付けられている、又は、割り当てられている、又は、属している１以上のユーザを含む。言い換えると、マルチテナントシステム１０００内の各ユーザは、マルチテナントシステム１０００によって支援される複数のテナントの内、特定のテナントに対して、関連付けられている、又は、割り当てられている、又は、属している。テナントは、ユーザ、ユーザの部署、仕事又は合法的な組織、及び／又は、マルチテナントシステム１０００内のユーザの特定の集団についてのデータを維持するその他のエンティティを表し得る。複数のテナントは、サーバ１００２及びデータベース１０３０へのアクセスを共有してもよいが、サーバ１００２から各テナントに提供される特定のデータ及びサービスは、他のテナントに提供されるものとは安全に分離することができる。したがって、マルチテナント構造によって、ユーザの様々な集団は、他のテナントに属している、又は、関連付けられているデータ１０３２の何れかを必ずしも共有しなくても、機能及びハードウェアリソースを共有することができる。
【０２３９】
マルチテナントデータベース１０３０は、相当数のテナントと関連付けられているデータ１０３２を格納し、管理することが可能な、何らかの種類のレポジトリ又は他のデータ格納システムである。データベース１０３０は、何らかの種類の従来のデータベースサーバハードウェアを用いて実施し得る。様々な実施例では、データベース１０３０は、サーバ１００２と処理ハードウェアを共有する。他の実施例では、データベース１０３０は、ここに記載する様々な機能を実行するために、サーバ１００２と通信する別個の物理的且つ／又は仮想データベースサーバハードウェアを用いて実施される。典型的な実施例では、データベース１０３０は、仮想アプリケーション１０２８Ａ又は１０２８Ｂにより開始又は提供されるクエリーに応答して、仮想アプリケーション１０２８Ａ又は１０２８Ｂのインスタンスに対してデータ１０３２の特定のサブセットを取り込み及び提供するために、最適なクエリープランを決定することができる、データベース管理システム又は他の同等のソフトウェアを備える。マルチテナントデータベース１０３０が、アプリケーションプラットフォーム１０１０によって生成されるオンデマンド仮想アプリケーション１０２８Ａ又は１０２８Ｂに対して、ランタイムでデータを提供する（又は提供に利用できる）という点で、マルチテナントシステム１０３０を、ここでは、択一的に、オンデマンドデータベースと称してもよい。
【０２４０】
実際には、データ１０３２は、アプリケーションプラットフォーム１０１０を支援する何らかの方法で、整理され（organized）、フォーマットされてもよい。様々な実施例では、データ１０３２は、半不定形（semi-amorphus）なヒープ（heap）型フォーマットを維持するために、比較的少数の大きなデータテーブルに適切に整理される。次に、データ１０３２は、特定の仮想アプリケーション１０２８Ａ又は１０２８Ｂに必要とされるように、整理することができる。様々な実施例では、従来のデータの関係は、インデックス作成、一意性（uniqueness）、エンティティ間の関係、従来のデータベース構成の他の側面の少なくとも何れかを要望通り設定する、任意の数のピボットテーブル１０３４を用いて設定される。更なるデータ操作及びレポート整形は、一般に、様々なメタデータ構成物（construct）を用いてランタイムで実行される。例えば、汎用データ辞書（ＵＤＤ）内のメタデータは、複数のテナントに共通な、任意の数のフォーム、レポート、ワークフロー、ユーザアクセス権、ワークロジック、他の構造物の記述に使用できる。テナント固有のフォーマット化、機能、他の構成物は、テナント毎に、テナント固有のメタデータ３３８として、要望通りに、維持されてもよい。データ１０３２を強制的に全てのテナント及びアプリケーションに共通する柔軟性のないグローバル構造にするのではなく、必要に応じて追加の構造を提供するピボットテーブル１０３４及びメタデータ１０３８Ａ及び１０３８Ｂによって、データベース１０３０は比較的不定形に構築される。そのためには、アプリケーションプラットフォーム１０１０は、ピボットテーブル１０３４及び／又はメタデータ１０３８Ａ〜Ｂを適切に用いて、データベース１０３０から比較的不定形なデータ１０３２を論理的に獲得、処理、提示するために、仮想アプリケーション１０２８Ａ及び１０２８Ｂの「仮想の」構成要素を生成する。
【０２４１】
サーバ１００２は、仮想アプリケーション１０２８を生成するための動的アプリケーションプラットフォーム１０１０をまとめて提供する１以上の実際の且つ／又は仮想の計算システムを用いて実施される。例えば、サーバ１００２は、典型的には必要に応じて従来のネットワーク通信、クラスタ管理、負荷分散、その他の機能と関連して、互いに連携して動作する実際の且つ／又は仮想のサーバのクラスタを用いて実施されてもよい。サーバ１００２は、プロセッサ１００５、メモリ１００６、入力／出力機能１００７等の何らかの種類の従来の処理ハードウェアで動作する。入力／出力機能１００７は、一般に、ネットワーク（例えば、ネットワーク１０４５、他のローカルエリア、ワイドエリア、他のネットワーク）、大容量記憶装置、表示装置、データ入力装置等に対するインターフェースを表している。プロセッサ１００５は、任意の数の「クラウドベースの」或いは他の仮想システムを含む、任意の数の分散又は統合システムに散在する、１以上のプロセッサ、コントローラ、マイクロプロセッサ、マイクロコントローラ、プロセッシングコア、その他の計算リソースといった何らかの適切な処理システムを用いて実施されてもよい。メモリ１００６は、プロセッサ１００５上で実行するためのプログラミング命令を格納できる、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、フラッシュメモリ、磁気又は光学大容量記憶装置等の、非一時的な短期又は長期記憶装置、又は、その他のコンピュータ可読媒体を表している。コンピュータ実行可能プログラミング命令は、サーバ１００２及び／又はプロセッサ１００５によって読みだされ、実行されると、サーバ１００２及び／又はプロセッサ１００５に、アプリケーションプラットフォーム１０１０及び／又は仮想アプリケーション１０２８Ａ及び１０２８Ｂを作成又は生成又は進行させ、ここに記載されている１以上の追加のタスク、動作、機能、処理の少なくとも１つを実行する。尚、メモリ１００６は、こうしたコンピュータ可読媒体の適切な一実施例を表しており、代わりに或いは追加で、サーバ１００２が、携帯可能な又はモバイルの構成要素又はアプリケーションプラットフォーム（例えば、携帯可能なハードドライブ、ＵＳＢフラッシュドライブ、光学ディスク等）として実現される外部のコンピュータ可読媒体を受け付け、それらと協働することが考えられる。
【０２４２】
アプリケーションプラットフォーム１０１０は、クライアント装置１０４０Ａ及び１０４０Ｂにデータ及び／又はサービスを提供する仮想アプリケーション１０２８Ａ及び１０２８Ｂを生成する、何らかの種類のソフトウェアアプリケーション又はその他のデータ処理エンジンである。典型的な実施例では、アプリケーションプラットフォーム１０１０は、処理ハードウェアの処理リソース、通信インターフェース、その他の機能に対するアクセスを、何らかの種類の従来の又は独自のオペレーティングシステム１００８を用いて、獲得する。仮想アプリケーション１０２８Ａ及び１０２８Ｂは、典型的には、クライアント装置１０４０Ａ及び１０４０Ｂから受領した入力に応答してランタイムで生成される。例示された実施例に関しては、アプリケーションプラットフォーム１０１０は、大量データ処理エンジン１０１２、クエリー生成部１０１４、テキストのインデックス付け及びその他の検索機能を提供する検索エンジン１０１６、ランタイムアプリケーション生成部１０２０を備える。これらの機能の夫々は、個別の処理又は他のモジュールとして実施されてもよく、多くの同等の実施例には、異なる且つ／又は追加の機能、構成要素、他のモジュールが必要に応じて含まれると考えられる。
【０２４３】
ランタイムアプリケーション生成部１０２０は、クライアント装置１０４０Ａ及び１０４０Ｂから受信した特定の要求に応答して、仮想アプリケーション１０２８Ａ及び１０２８Ｂを動的に構築し、実行する。仮想アプリケーション１０２８Ａ及び１０２８Ｂは典型的には、特定のアプリケーション１０２８Ａ又は１０２８Ｂの特定のテーブル、レポート、インターフェース、その他の機能の少なくとも１つを記述する、テナント固有のメタデータ１０３８Ａ及び１０３８Ｂに従って構築される。様々な実施例では、各仮想のアプリケーション１０２８Ａ又は１０２８Ｂが、必要に応じて、クライアント装置１０４０Ａ又は１０４０Ｂと関連付けされたブラウザ又は他のクライアントプログラム１０４２Ａ及び１０４２Ｂに供給可能な動的なウェブコンテンツを生成する。
【０２４４】
ランタイムアプリケーション生成部１０２０は、クライアント装置１０４０Ａ及び１０４０Ｂのユーザによって開始又は提供される入力クエリーに応答して、必要に応じて、マルチテナントデータ１０３２をデータベース１０３０から効率的に獲得するために、クエリー生成部１０１４と適切な相互作用を行う。典型的な実施例では、クエリー生成部１０１４は、特定の機能を要求するユーザの同一性（identity）を（ユーザの関連付けられたテナントと共に）検討し、汎用データ辞書（ＵＤＤ）１０３６内のシステム全体に亘るメタデータ、テナント固有のメタデータ１０３８Ａ及び１０３８Ｂ、ピボットテーブル１０３４、その他の利用可能なリソースの内、少なくとも何れかを用いて、データベース１０３０に対するクエリーを構築し、実行する。したがって、この例におけるクエリー生成部１０１４は、当該要求を開始したユーザ且つ／又はテナントに与えられたアクセス権とクエリーが一致することを確実にすることで、共通のデータベース１０３０のセキュリティを維持する。このように、クエリー生成部１０１４は、ユーザ及び／又はテナントにアクセス可能な要求されたデータ１０３２のサブセットを、当該ユーザ及び／又はテナントに関して特定の仮想アプリケーション１０２８Ａ又は１０２８Ｂのテーブル、レポート、その他の機能を追加する（populate）ために、データベース１０３０から必要に応じて適切に獲得する。
【０２４５】
更に図１０を参照すると、データ処理エンジン１０１２は、データ１０３２について、アップロード、ダウンロード、更新、オンライントランザクション処理等の大量の処理動作を実行する。多くの実施例では、データ１０３２の緊急性の低い大量処理は、処理リソースが利用可能になった時に発生するようスケジューリングすることができ、これにより、クエリー生成部１０１４、検索エンジン１０１６、仮想アプリケーション１０２８Ａ及び１０２８Ｂ等によるより緊急性の高いデータ処理を優先させることができる。
【０２４６】
例示した実施例では、アプリケーションプラットフォーム１０１０は、データ駆動の仮想アプリケーション１０２８Ａ及び１０２８Ｂを、それらが支援するテナントについて、作成且つ／又は生成するために利用される。こうした仮想アプリケーション１０２８Ａ及び１０２８Ｂは、カスタム（又はテナント固有の）スクリーン１０２４、標準（又は汎用）スクリーン１０２２等のインターフェース機能を使用してもよい。任意の数のカスタム及び／又は標準オブジェクト１０２６は、テナントにより開発された仮想アプリケーション１０２８Ａ及び１０２８Ｂへの統合に利用可能であってもよい。ここで使用されている、「カスタム」は、各オブジェクト又はアプリケーションが、テナント固有（例えば、マルチテナントシステムにおける特定のテナントに関連するユーザのみ利用可能である）、又は、ユーザ固有（例えば、マルチテナントシステムにおけるユーザの特定の集団にのみ利用可能である）ことを意味するものとして理解される。尚、「標準」又は「汎用」アプリケーション又はオブジェクトは、マルチテナントシステムにおける複数のテナントに亘って利用可能である。各仮想アプリケーション１０２８Ａ又は１０２８Ｂに関連付けられたデータ１０３２は、特定の仮想アプリケーション１０２８Ａ又は１０２８Ｂの特定の機能（例えば、レポート、テーブル、機能、オブジェクト、フィールド、式、コード等）を記述したメタデータ１０３８Ａ及び１０３８Ｂと共に、必要に応じて、データベース１０３０に提供され、要求されるまで、又は、必要とされるまで格納される。例えば、仮想アプリケーション１０２８Ａ及び１０２８Ｂは、テナントにアクセス可能な複数のオブジェクト１０２６を備えてもよく、この場合、テナントにアクセス可能なオブジェクト１０２６毎に、そのオブジェクトタイプに関連する情報が、各オブジェクトタイプに関連付けられた様々なフィールドに関する値と共に、データベース１０３０において、メタデータ１０３８Ａ及び１０３８Ｂとして維持される。この点において、オブジェクトタイプは、各オブジェクト１０２６の構造（例えば、フォーマッティング、機能、その他の構成物）、及び、それと関連付けられた様々なフィールドを定義する。
【０２４７】
引き続き図１０を参照すると、サーバ１００２によって提供されるデータ及びサービスは、ネットワーク１０４５上の何らかの種類のパソコン、携帯電話、タブレット、その他のネットワーク接続可能な（network-enabled）クライアント装置１０４０Ａ又は１０４０Ｂを用いて取り込むことができる。例示した実施例では、クライアント装置１０４０Ａ又は１０４０Ｂは、マルチテナントデータベース１０３０から取り込んだデータ及び／又は情報を図示可能な、モニター、スクリーン、別の従来の電子表示等の表示装置を備える。典型的には、ユーザは、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）等のネットワーキングプロトコルを用いてネットワーク１０４５を介してサーバ１００２とコンタクトをとるために、クライアント装置１０４０Ａ及び１０４０Ｂによって実行される従来のブラウザアプリケーション又はその他のクライアントプログラム１０４２Ａ又は１０４２Ｂを操作する。ユーザは、典型的には、サーバ１００２との後の通信で当該ユーザを識別するセッション識別子（「セッションＩＤ」）を得るために、サーバ１００２に対して自身の同一性を認証する。識別されたユーザが仮想アプリケーション１０２８Ａ又は１０２８Ｂに対するアクセスを要求すると、ランタイムアプリケーション生成部１０２０が、必要に応じて、メタデータ１０３８Ａ及び１０３８Ｂに基づいてランタイムでアプリケーションを適切に作成する。上述したように、仮想アプリケーション１０２８Ａ又は１０２８Ｂには、Java、ActiveX、クライアント装置１０４０Ａ又は１０４０Ｂ上で動作する従来のクライアントソフトウェアを用いて提示可能なその他のコンテンツを含んでいてもよく、他の実施例は、所望するように、ユーザによって提示及び閲覧可能な動的なウェブ又はその他のコンテンツを単純に提供してもよい。
【０２４８】
上記説明は、本質的に単なる例示であって、本主題及び本出願の実施例、及び、こうした実施例の使用を限定することは意図していない。更に、技術分野、背景、詳細な説明において表現された又は示唆された如何なる理論によっても拘束される意図はない。ここで使用される、「典型的な（exemplary）」とは、「例（example）、例証（instance）、説明（illustration）として役立つ」という意味である。ここに典型として記載されたどの実施例も、他の実施例よりも好ましい又は有利であると必ずしも解釈されるわけではなく、ここに記載された典型的な実施例は、主題の範囲又は適用可能性を決して限定するものではない。
【０２４９】
簡潔性のため、データベース、ソーシャルネットワーク、ユーザインターフェース、システムの他の機能的側面（及び、システムの個々の動作構成要素）に関する従来技術は、ここでは詳細には述べない。また、当業者は、実施例が、任意の数のシステム且つ／又はネットワークアーキテクチャ、データ送信プロトコル、装置構成と連動して実施されてもよく、ここに記載のシステムは、単なる適切な例にすぎないことを理解するであろう。更に、特定の専門用語は、ここでは参照を目的として使用されているに過ぎず、限定することを意図していない。例えば、「第１」、「第２」や他のこうした数字に関する用語は、文脈で明示されていない限り、順序や順番を示唆するものではない。
【０２５０】
本主題の実施例は、ここでは、機能的且つ／又は論理的ブロック構成要素の観点から、及び、様々な計算構成要素又は装置によって実行される、動作、処理タスク、機能を参照して記載される。こうした動作、タスク、機能は、コンピュータによって実行される、コンピュータ化された、ソフトウェアによって実施される、コンピュータによって実施されるものとして、言及されることもある。実際、１以上の処理システム又は装置は、アクセス可能なメモリの場所のデータビットを表す電気信号を他の信号の処理と共に操作することで、記載された動作、タスク、機能を、実行することが可能である。データビットが保持されているメモリの場所は、データビットに対応する特定の電気的、磁気的、光学的、又は、有機的特性を有する物理的な場所である。図に示されている様々なブロック構成要素は、特定の機能を実行するよう構成された、任意の数のハードウェア、ソフトウェア、ファームウェア構成要素によって実現されてもよいと理解される。例えば、システム又は構成要素の実施例は、１以上のマイクロプロセッサや他の制御装置の制御の下に様々な機能を実行する、例えば、メモリ要素、ディジタル信号処理要素、論理要素、ルックアップテーブル等の様々な集積回路の構成要素を使用してもよい。ソフトウェア又はファームウェアで実施される場合、ここに記載のシステムの様々な要素は、本質的には、様々なタスクを実行するコードセグメント又は命令である。プログラム又はコードセグメントは、プロセッサ可読媒体に格納、或いは、伝送媒体又は通信経路における搬送波で具体化されるコンピュータデータ信号によって転送することが可能である。「プロセッサ可読媒体」又は「機械可読媒体」は、情報を格納又は転送可能な何らかの非一時的媒体を含んでもよい。プロセッサ可読媒体の例には、電子回路、半導体記憶装置、ＲＯＭ、フラッシュメモリ、消去可能なＲＯＭ（ＥＲＯＭ）、フロッピーディスケット、ＣＤ−ＲＯＭ、光学ディスク、ハードディスク、光ファイバー媒体、無線周波数（ＲＦ）リンク等が含まれる。コンピュータデータ信号には、電子ネットワークチャネル、光ファイバー、空中（air）、電磁経路、ＲＦリンクといった伝送媒体を伝播可能な、何らかの信号を含んでもよい。コードセグメントは、インターネット、イントラネット、ＬＡＮ等のコンピュータネットワークを介してダウンロードされてもよい。この点において、ここに記載の主題は、コンピュータによって実施されるシステムと関連して、且つ／又は、互いに協力し、通信し合う２以上の個別の且つ区別されるコンピュータによって実施されるシステムと関連して、実施可能である。１以上の典型的な実施例では、ここに記載の主題は、マルチテナント環境内の仮想ユーザ関係管理（ＣＲＭ）アプリケーションと連動して実施される。
＜幾つかの特定の実施例＞
【０２５１】
幾つかの特定の実施例及び特徴を以下で述べる。
ＮＲＴデータの多段階処理
【０２５２】
一実施例では、準リアルタイム（ＮＲＴ）データストリームの多段階処理における強力な順序付けを提供する方法を説明する。本方法は、１以上の準リアルタイム（ＮＲＴ）データストリームからのデータを処理する複数の物理スレッドを含むコンピューティンググリッドを操作する工程と、ＮＲＴデータストリームからのデータを、コンピューティンググリッドで多段階に亘って処理するためのパイプラインにおけるバッチとして、待ち行列に追加する工程と、バッチステージに関する物理スレッドへのバッチ単位のディスパッチを制御するグリッドコーディネータと通信して、グリッドスケジューラにバッチに関する現在のバッチステージ情報を維持する工程と、グリッドコーディネータで現在のバッチステージ情報が受領されたことに応答して、当該情報で識別された現在のバッチステージに関して、ディスパッチを保留にしているバッチ単位を判定する工程と、現在のバッチステージが依存する前回のバッチステージに関してバッチ単位を処理し、現在のバッチステージに関して保留のタスクを登録した物理スレッドを識別する工程と、前回のバッチステージに関するバッチ単位の処理が完了したことに続いて、現在のバッチステージに関するバッチ単位を、識別された物理スレッドへディスパッチする工程を含む。
【０２５３】
一実施例では、グリッドスケジューラがコンピューティンググリッドでパイプラインを探知し、バッチ、及び、完了したステージの出力に依存する下流ステージの実行をスケジューリングする。
【０２５４】
別の実施例では、グリッドスケジューラは、コンピューティンググリッドにおける各パイプラインに、パイプライン識別子（ＩＤ）を割り当てる。更なる実施例では、グリッドスケジューラは、パイプラインにおける各バッチにバッチ識別子（ＩＤ）を割り当てる。更に別の実施例では、グリッドスケジューラが、バッチの各処理ステージにステージ識別子（ＩＤ）を割り当てる。
【０２５５】
一実施例では、グリッドスケジューラは、各バッチが実行される毎に、パイプラインＩＤ、バッチＩＤ、ステージＩＤをグリッドコーディネータに伝達する。別の実施例では、本方法は更に、処理ステージが互いに依存していない場合に、１以上のパイプラインの１以上のバッチに関して、複数の処理ステージを同時に実行する工程を含む。
【０２５６】
本章に記載の本方法の他の実施例は、上述の方法の何れかを実行するためにプロセッサによって実行可能な命令を格納する、非一時的なコンピュータ可読記憶媒体を備えることが可能である。本章に記載の本方法の更に別の実施例は、上述の本方法の何れかを実行するために、メモリと当該メモリに格納された命令を実行する動作が可能な１以上のプロセッサを含むシステムを備えることが可能である。
【０２５７】
一実施例では、ストリーム処理システムの限られた数のワーカーノード上でロングテールタスクシーケンスを含む複数のタスクシーケンスを処理する方法は、物理スレッドを有し、１つの物理スレッドがワーカーノードのプロセッサコア全体を利用するワーカーノードに対して、コンテナを定義する工程を含む。本方法はまた、複数のタスクシーケンスに関して、コンテナで実行されるパイプラインに、入力された準リアルタイム（ＮＲＴ）データストリームからのデータを待ち行列に追加する工程と、ＮＲＴデータストリームからのデータをバッチとして、当該バッチのディスパッチを制御するコンテナコーディネータを用いて処理する工程と、当該バッチを物理スレッドにディスパッチする工程を含み、バッチは完了又はタイムアウトまで実行され、実行中は、利用可能な物理スレッドのカウントと、論理的に並行なスレッドの設定数の比較が行われる。本方法は更に、利用可能な物理スレッドのカウントが、論理的に並行なスレッドの数と等しい、又は、それを超える場合は、物理スレッドでバッチを同時に処理し、利用可能な物理スレッドが論理的に並行なスレッドの数よりも少ない場合は、利用可能な物理スレッドに対してバッチを順番に多重化する工程を含む。
【０２５８】
幾つかの実施例では、開示された本方法は、パイプライン内の少なくとも１つのバッチのサブセットを、パイプライン内の少なくとも１つの別のバッチのサブセットと同時に処理し、当該両サブセット内の少なくとも幾つかのバッチを順番に多重化する。幾つかの実施例では、論理的に並行なスレッドの数は１０であり、利用可能な物理スレッドのカウントは１０である。本方法は更に、１０個の利用可能な物理スレッドでパイプライン内の複数のバッチを同時に処理することが可能である。他の実施例では、論理的に並行なスレッドの数は１０であり、利用可能な物理スレッドのカウントは９である。開示された本方法は更に、９個の利用可能な物理スレッドの内、８個で、パイプライン内の複数のバッチを同時に処理し、少なくとも１個の利用可能な物理スレッドについて、パイプライン内の幾つかのバッチを、順番に多重化する。
【０２５９】
別の実施例では、論理的に並行なスレッドの数は１０であり、且つ、利用可能な物理スレッドのカウントは１であり、１個の利用可能な物理スレッドに対して、パイプライン内のバッチを順番に多重化する。多重化では、パイプラインで次のバッチを処理する前に、完了又はタイムアウトまで、パイプラインでバッチを処理することが可能である。
【０２６０】
幾つかの実施例では、開示された本方法は更に、コンテナ内の複数のワーカーノードに対して、複数のパイプラインを同時に処理することが可能である。
【０２６１】
バッチは、幾つかの実施例に関しては、タイムスライスベースで定義され、時間窓内で最近受領した少なくとも１つの入力されたＮＲＴデータストリームの一部分を含む。他の実施例では、バッチは、バッチサイズベースで定義され、最近受領した少なくとも１つの入力されたＮＲＴデータストリームのデータサイズが制約された部分を含む。
【０２６２】
一実施例では、非プログラミングユーザ向けの、熟練オペレータ用のエンティティ関与ワークフローの分析を単純化する方法を説明する。本方法は、熟練オペレータによって起動された様々なエンティティ体験動作に関する複数のイベントストリームを受領する工程を含む。本方法はまた、複数の時間窓の間に、エンティティ体験動作のイベントストリームからエンティティ活動レベルを決定する工程を含む。本方法は、個々のエンティティ体験動作に関して、各エンティティ活動レベルに基づいて、複数のエンティティを複数の状態タイプに分類する工程を含む。本方法は更に、各エンティティオペレータに向けた表示のための視覚表示データを生成する。視覚表示データは、各エンティティ体験動作及び当該エンティティ体験動作の各状態に関する複数のイベントストリームと、タイムラインに沿ったエンティティ活動レベル及び当該レベルの変化と、複数の状態タイプと、ある状態から別の状態へのエンティティ遷移の経緯（trails）と、特定の状態タイプに属するエンティティ数に基づく当該状態タイプのサイズと、データエントリカラムナを描写する。データエントリカラムナは、出力メッセージングチャネル、メッセージング動作、メッセージ動作によって生成されるメッセージに取り込み、含める資源（asset）を指定する、選択可能な遷移−応答動作に関する宣言的入力を受け付ける。
【０２６３】
開示された技術の本章及び他の章に記載した方法は、以下の特徴、及び／又は、開示された追加の方法に関連して記載された特徴の１以上を含むことができる。簡潔性のために、本出願で開示された特徴の組み合わせは、個々に列挙することはせず、特徴の基本となるセット毎に繰り返すこともない。読者は、本方法で識別される特徴が、専門用語、序論、ＩｏＴプラットフォーム及びストリーム−バッチ処理フレームワーク、ステートマシン、データカラムナ、フローチャート、マルチテナント統合、幾つかの特定の実施例等といった、実施例として識別される基本の特徴のセットと如何に容易に組み合わせられるかを理解するであろう。
【０２６４】
一実施例では、視覚表示データは、リッチコンテクスチュアルデータストア１１０に格納される。
【０２６５】
一実施例では、視覚表示データは、時間をかけてリプレイすることで複数の状態タイプ間でのエンティティの遷移を視覚化するリプレイ制御を備える。
【０２６６】
別の実施例では、本方法は更に、同様の状態タイプのエンティティが状態クラウド内でグループ化されて示され、エンティティ状態遷移が最初の状態クラウドから最後の状態クラウドまでの遷移の経緯として示された状態遷移グラフを構築し、状態遷移を示すために状態クラウドと遷移の経緯を視覚的にコード化する工程を含む。
【０２６７】
幾つかの実施例では、遷移の経緯の視覚的なコード化が、対応する最後の状態クラウドの視覚的なコード化と一致する。
【０２６８】
別の実施例では、本方法は更に、同様の状態タイプのエンティティが状態バブル内でグループ化されて示され、エンティティ状態遷移が最初の状態バブルから最後の状態バブルまでの遷移アーチ（arches）として示された状態遷移グラフを構築し、状態遷移を示すために状態バブルと遷移アーチを視覚的にコード化する工程を含む。
【０２６９】
更に別の実施例では、本方法は更に、状態クラウドと状態バブルのナビゲーションの際にホバーパネル（hover panel）データを、表示のために生成する。幾つかの実施例では、ホバーパネルデータは、当該状態タイプのエンティティを分類するための基準、当該状態タイプのエンティティ数、一定期間における数の変化、状態遷移に応答して実施される選択可能な動作を制御する条件を識別する。
【０２７０】
幾つかの実施例では、イベントストリームは、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領される。
【０２７１】
他の実施例では、イベントストリームは、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つを含む。
【０２７２】
更なる実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。
【０２７３】
また更なる実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
【０２７４】
ここに開示された技術には、ストリームとバッチ処理フレームワークの組み合わせを用いてグラフィカル表現を記述するシステム及び方法も含まれる。開示された本技術は、統合された、異機種環境の（heterogeneous）ステートマシン上での、超高速の、任意の（ad hoc）データ探索及び、ファセットナビゲーションに関する。開示された装置及び方法は、デスクトップ及びモバイルのアプリケーション環境の両方に対して、ライブダッシュボード上にレンダーされたライブデータの共有を可能にするグラフィックを記述するために用いることができる。
【０２７５】
本章で記載された方法の他の実施例は、上記で述べた方法の何れかを実行するために、プロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を備えることができる。本章で記載された方法の更に他の実施例は、上記で述べた方法の何れかを実行するために、上記で述べたメモリと、当該メモリに格納された命令を実行する動作が可能な１以上のプロセッサを備えることができる。
【０２７６】
一実施例では、開示された技術によって、マーケティング担当者等の非技術ユーザが、電子メール又はモバイルプッシュイベント経由してユーザと相互に作用するための一連の経路を定義して、１行のコードも使うことなくユーザに接触することが可能となる。別の実施例では、開示された技術は、非技術ユーザに、通常は専門の開発者によって実施されるより複雑な問題解決法を必要とする相互作用を定義することを可能にする。
【０２７７】
一実施例では、開示された技術は、ユーザとブランドの持続可能な関係を作成するアプリケーションを構築することを目的とする多段階の良好なアプリケーション体験管理を実施する。良好なアプリケーション体験管理は、発見、開始、内容（context）、第１相互作用、達成（fulfillment）、放棄、育成（nurture）、共有の８つの段階で構成され、それらの全ては、開示された技術を用いて非技術ユーザによって簡単にコード化され、自動化されることが可能である。
【０２７８】
フォローアップは自動化されていなければ、簡単に忘れられる。会社の担当者は、取引を締結させる際の迅速なフォローアップの重要性を認識している一方で、多忙なためにそれを優先させることができないということがしばしばある。彼らの探知をカバーして、関係を再構築するのに時間を費やすのではなく、会社の担当者は、状況に応じて適切なフォローアップを定義するために、開示されたマーケティング自動化システムを使用することが考えられる。開示された技術の一実施例に従って、ユーザへのメッセージを、会社の担当者が各連絡先と定期的に接点が得られるように、自動化し、個人向けに変更することが可能となり、手動のタスクに費やす時間を減らし、取引の締結に集中することができる。フォローアップの自動化により、ユーザは会社の担当者から無視される可能性がかなり低くなり、競争相手に奪われる機会も減る。更に、定期的な接点を持つことで、会社の担当者は、キャンペーンサイクルの間中ずっと、連絡先に付き添うことができる。
【０２７９】
一実施例では、開示された技術は、電子メールマーケテイングやユーザ育成を含む自動化された通信及びマーケティングプログラムによって、非技術ユーザ向けに、キャンペーンの作成を合理化する。
【０２８０】
一実施例では、開示された技術は、複雑な販売サイクルを持つ会社向けに、売り上げを増加し、効率を最大化するよう設計されたマーケティング自動化プラットフォームを提供する。これにより、マーケティング及び販売部署は、１つの中心となるプラットフォームで、ユーザとの相互作用及びオンラインのマーケティングキャンペーンを管理することが可能となる。
【０２８１】
一実施例では、開示された技術は、フォーム、ページの閲覧、コンテンツのダウンロード、電子メール、社会的な相互作用等を含む、販売サイクルの全期間に亘るユーザとの全ての接点をリアルタイムで探知するマイクロレベルの分析を含む。
【０２８２】
一実施例では、開示された技術は、事前に定義された規則及び時間間隔に基づいたユーザに対する電子メールの送信、及び、その他の通信を含む、自動化されたユーザ育成も可能にする。他の実施例では、開示された技術は、いつユーザが積極的で、キャンペーンに参加しようとしているかを会社に知らせる、カスタマイズ可能なリアルタイム通知を提供する。
【０２８３】
一実施例では、開示された技術は、非技術ユーザが、動的で、ブランド化され（branded）、個人向けに変更されたオンラインマーケティングキャンペーン及び電子メールを容易に作成することができるウィザード及びツールを提供する。
【０２８４】
一実施例では、開示されたＩｏＴプラットフォームは、バッチ処理用の（Scalding又はCascadingを介した）Hadoop、及び、イベント処理用のStormを、ハイブリッド的に利用して、バッチ及びイベント結果を透過的に統合し、効果的に準リアルタイム分析を生成することができる。
【０２８５】
開示された技術の本章及び他の章で説明した実施及び特徴は、以下の特徴、及び／又は、開示された追加の方法に関連して記載された特徴の１以上を含むことができる。簡潔性のために、本出願で開示された特徴の組み合わせは、個々に列挙することはせず、特徴の基本となるセット毎に繰り返すこともない。読者は、本方法で識別される特徴が、専門用語、序論、ＩｏＴプラットフォーム、ストリーム−バッチ処理フレームワーク、ステートマシン、データカラムナ、フローチャート、マルチテナント統合、幾つかの特定の実施例等といった、実施例として識別される基本の特徴のセットと如何に容易に組み合わせられるかを理解するであろう。
【０２８６】
１つのサーバ側の実施例において、非プログラミングユーザ向けのエンティティ管理ワークフローの作成を単純化する方法を説明する。本方法は、エンティティとの相互作用を自動的に多段階で進行させるステートマシンを指定する宣言的入力を受け付けるデータエントリカラムナを、表示のために、生成する工程を備える。幾つかの実施例では、データエントリカラムナは、多段階進行における状態に関する少なくとも１つのカラム、タイムベース遷移トリガー、イベントベース遷移トリガー、条件の定義、状態遷移に応じた択一的な動作を含む。
【０２８７】
本方法はまた、一定の期間が過ぎると状態遷移を引き起こすタイマー、及び、状態遷移を引き起こすイベントによって、択一的に指定される状態遷移トリガーを定義するデータエントリカラムナへの入力を示すデータを受領する工程を備える。
【０２８８】
本方法は、状態遷移中に条件を、当該条件が参照するデータベースフィールドの少なくとも１つの値に対して、評価する工程を備える。
【０２８９】
本方法は更に、条件が満足されることに応答して、状態遷移中に択一的な動作を実行する工程を備える。
【０２９０】
開示された技術の本章及び他の章で記載した方法は、以下の特徴、及び／又は、開示された追加の方法に関連して記載された特徴の１以上を含むことができる。簡潔性のために、本出願で開示された特徴の組み合わせは、個々に列挙することはせず、特徴の基本となるセット毎に繰り返すこともない。読者は、本方法で識別される特徴が、専門用語、序論、ＩｏＴプラットフォーム及びストリーム−バッチ処理フレームワーク、ステートマシン、データカラムナ、フローチャート、マルチテナント統合、幾つかの特定の実施例等といった、実施例として識別される基本の特徴のセットと如何に容易に組み合わせられるかを理解するであろう。
【０２９１】
一実施例では、データエントリカラムナへの入力を示すデータは更に、状態遷移に応答した動作の実行に続いて得られる少なくとも１つの状態の仕様を含む。
【０２９２】
別実施例では、データエントリカラムナへの入力を示すデータは更に、全ての状態に適用されるグローバルな状態遷移に応じた少なくとも１つの常時動作の仕様を含む。
【０２９３】
更に別の実施例では、データエントリカラムナへの入力を示すデータは更に、エンティティの複数の状態の仕様を含む。
【０２９４】
幾つかの実施例では、エンティティが電子機器の場合、当該電気機器の状態には、オン、オフ、スタンバイ、電源投入、電源切断、全電力のパーセンテージ、ネットワーク接続の範囲の内、少なくとも１つが更に含まれる。
【０２９５】
幾つかの実施例では、エンティティがユーザの場合、ユーザの状態には、熱心な、移り気な、自然消滅の内、少なくとも１つを更に含む。
【０２９６】
幾つかの実施例では、入力イベントを、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領する。一実施例では、入力イベントには、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つが含まれる。別の実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。更に別の実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
【０２９７】
本章で記載された方法の他の実施例は、上記で述べた方法の何れかを実行するために、プロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を備えることができる。本章で記載された方法の更に他の実施例は、上記で述べた方法の何れかを実行するために、メモリと、当該メモリに格納された命令を実行する動作が可能な１以上のプロセッサを備えることができる。
【０２９８】
１つのクライアント側の実施例において、非プログラミングユーザ向けのエンティティ管理ワークフローの作成を単純化する方法を説明する。本方法は、エンティティとの相互作用を自動的に多段階で進行させるステートマシンを指定する宣言的入力を受け付けるデータエントリカラムナを受領する工程を備える。幾つかの実施例では、データエントリカラムナは、多段階進行における状態に関する少なくとも１つのカラム、タイムベース遷移トリガー、イベントベース遷移トリガー、条件の定義、状態遷移に応じた択一的な動作を含む。
【０２９９】
本方法はまた、エンティティの複数の状態、一定の期間が過ぎると状態遷移を引き起こすタイマー及びイベント値が条件を満たすと状態遷移を引き起こす入力イベントによって択一的に指定される状態遷移トリガー、状態遷移に応じた動作の実行に続いて得られる少なくとも１つの状態、全ての状態に適用されるグローバルな状態遷移に応じた少なくとも１つの常時動作を定義するデータエントリカラムナへの入力を示すデータを送信する工程を備える。
【０３００】
本方法は更に、当該条件が、自身が取り込むデータベースフィールドの少なくとも１つの値に対して評価され、状態遷移に応答して実施される択一的な動作を制御する工程を更に含む。
【０３０１】
開示された技術の本章及び他の章で記載した方法は、以下の特徴、及び／又は、開示された追加の方法に関連して記載された特徴の１以上を含むことができる。簡潔性のために、本出願で開示された特徴の組み合わせは、個々に列挙することはせず、特徴の基本となるセット毎に繰り返すこともない。読者は、本方法で識別される特徴が、専門用語、序論、ＩｏＴプラットフォーム及びストリーム−バッチ処理フレームワーク、ステートマシン、データカラムナ、フローチャート、マルチテナント統合、幾つかの特定の実施例等といった、実施例として識別される基本の特徴のセットと如何に容易に組み合わせられるかを理解するであろう。
【０３０２】
一実施例では、データエントリカラムナへの入力を示すデータは更に、状態遷移に応答した動作の実行に続いて得られる少なくとも１つの状態の仕様を含む。
【０３０３】
別の実施例では、データエントリカラムナへの入力を示すデータは更に、全ての状態に適用されるグローバルな状態遷移に応じた少なくとも１つの常時動作の仕様を更に含む。
【０３０４】
更に別の実施例では、データエントリカラムナへの入力を示すデータは更に、エンティティの複数の状態の仕様を更に含む。
【０３０５】
幾つかの実施例では、エンティティが電子機器の場合、当該電気機器の状態には、オン、オフ、スタンバイ、電源投入、電源切断、全電力のパーセンテージ、ネットワーク接続の範囲の内、少なくとも１つが更に含まれる。
【０３０６】
幾つかの実施例では、エンティティがユーザの場合、ユーザの状態には、熱心な、移り気な、自然消滅の内、少なくとも１つを更に含む。
【０３０７】
幾つかの実施例では、入力イベントを、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領する。一実施例では、入力イベントには、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つが含まれる。別の実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。更に別の実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
【０３０８】
本章で記載された方法の他の実施例は、上記で述べた方法の何れかを実行するために、プロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を備えることができる。本章で記載された方法の更に他の実施例は、上記で述べた方法の何れかを実行するために、メモリと、当該メモリに格納された命令を実行する動作が可能な１以上のプロセッサを備えることができる。
【０３０９】
一実施例では、ロングテールを有するタスクシーケンスへのリソース割り当てを管理する方法は、マシン全体に亘って定義された異機種環境のコンテナ及び複数のマシンを含む幾つかのコンテナで、マシンリソースを含むコンピューティンググリッドを操作する工程を備える。本方法は、初めに複数のマシンを第１コンテナに割り当てる工程と、初めにステートフル（stateful）タスクシーケンスの第１セットを第１コンテナに割り当てる工程と、コンテナスケジューラの制御の下、第１コンテナにおいて多重化されたワーク単位でステートフルタスクシーケンスの第１セットを実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、少なくとも１つのロングテールタスクシーケンスが、最初に割り当てられたリソースよりある程度少ないリソースを消費していることを検出する工程と、当該検出に応答して、第１コンテナに１以上の追加のステートフルタスクシーケンスを割り当てる、又は、第１コンテナから１以上のマシンの割り当てを解除する工程を備える。
【０３１０】
ロングテールを有するタスクシーケンスへのリソース割り当てを管理する方法は、過剰なマシンリソースがタスクシーケンスの第１セットのみに充てられていることを検出する工程と、第１コンテナ内のマシンの第２サブセットを未使用のままにするために、第１コンテナ内のマシンの第１サブセットに対してタスクシーケンスの第１セットをスケジューリングする工程と、第１コンテナからマシンの第２サブセットの割り当てを自動的に解除する工程を備える。
【０３１１】
一実施例では、開示された方法は、過剰なマシンリソースがタスクシーケンスの第１セットのみに充てられていることを検出する工程と、第１コンテナに追加のステートフルタスクシーケンスを自動的に割り当てる工程を更に備える。開示された方法では、第１コンテナ内で実行されるタスクシーケンスの数を４から２０まで増やすことができる。
【０３１２】
幾つかの実施例では、急増するタスクシーケンスへのリソースの割り当てを管理する開示された方法は、マシン全体に亘って定義された異機種環境のコンテナ及び複数のマシンを含む幾つかのコンテナで、マシンリソースを含むコンピューティンググリッドを操作する工程を備える。本方法は、初めに複数のマシンを第１コンテナに割り当てる工程と、初めにステートフルタスクシーケンスの第１セットを第１コンテナに割り当てる工程と、コンテナスケジューラの制御の下、第１コンテナにおいて多重化されたワーク単位でステートフルタスクシーケンスの第１セットを実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、少なくとも１つのタスクシーケンスが、最初に割り当てられたリソースよりある程度多いリソースを必要としていることを検出する工程と、第１コンテナに割り当てられた複数のマシンが所定の最大値にまだ達していないことを判定する工程と、第１コンテナにより多くのマシンを自動的に割り当てる、又は、第１コンテナから第２コンテナにタスクシーケンスの第１セット内の幾つかのタスクシーケンスを再割り当てする工程を備える。開示された方法は、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナに追加のマシンを自動的に割り当てる工程と、第１コンテナ内の複数のマシンと追加のマシンに対して、タスクシーケンスの第１セットに関してワーク単位をスケジューリングする工程を備える。第１コンテナ内のマシンの数は、８から１０まで増やすことができる。開示された方法は、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナに割り当てられた複数のマシンが所定の最大値に達したこと、及び、マシンがタスクシーケンスの第１セットにこれ以上割り当てられないことを判定する工程を備える。
【０３１３】
急増するタスクシーケンスへのリソースの割り当てを管理する開示された方法は、実行中、タスクシーケンスの第１セットの状態情報を維持する（persist）工程と、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナから第２コンテナにタスクシーケンスの第２サブセットを自動的に再割り当てする一方で、タスクシーケンスの第１サブセットを第１コンテナに割り当てたままにしておく工程を備える。本方法は更に、第２コンテナでタスクシーケンスの第２サブセットを初期化するために、維持された状態情報を用いる工程、第１コンテナのタスクシーケンスの第１サブセットと、第２コンテナのタスクシーケンスの第２サブセットに関してワーク単位をスケジューリングする工程を備える。
【０３１４】
一実施例では、欠陥タスクシーケンスへのリソース割り当てを管理する方法は、最初に第１コンテナにステートフルタスクシーケンスの第１セットを割り当てる工程と、再生可能な入力ソースから入力を受け取り、当該入力を処理するためにタスクシーケンスのステートフルな第１セットを起動する工程と、コンテナスケジューラの制御の下で、第１コンテナ内でステートフルタスクシーケンスの第１セットを多重化されたワーク単位で実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、実行中、タスクシーケンスの第１セットの状態情報を維持する工程と、所定のタイムアウト閾値を超える欠陥タスクシーケンスにおけるワーク単位の実行時間を検出する工程と、欠陥タスクシーケンスの維持された状態情報を自動的に再ロードして欠陥タスクシーケンスを再度開始させる工程を備える。本方法はまた、欠陥タスクシーケンスへの再生可能な入力を上記検出よりも前で、且つ、欠陥タスクシーケンスに関して維持された状態情報と同期する時点まで、自動的に巻き戻す工程と、所定のタイムアウト閾値を超えることなくワーク単位の完了まで欠陥タスクシーケンスを再実行する工程とを備える。
【０３１５】
欠陥タスクシーケンスへのリソース割り当てを管理する方法は更に、第１コンテナから第２コンテナに欠陥タスクシーケンスを再度割り当てる工程と、第２コンテナで欠陥タスクシーケンスの維持された状態情報を再ロードすることで、第２コンテナで欠陥タスクシーケンスを再度開始する工程と、欠陥タスクシーケンスへの再生可能な入力を上記検出よりも前で、且つ、欠陥タスクシーケンスに関して維持された状態情報と同期する時点まで、巻き戻す工程と、所定のタイムアウト閾値を超えることなくワーク単位の完了まで欠陥タスクシーケンスを再実行する工程を備える。
【０３１６】
一実施例では、ロングテールを有するタスクシーケンスへのリソース割り当てを管理する方法は、マシン全体に亘って定義された異機種環境のコンテナ及び複数のマシンを含む幾つかのコンテナで、マシンリソースを含むコンピューティンググリッドを操作する工程を備える。本方法は、初めに複数のマシンを第１コンテナに割り当てる工程と、初めにステートフルタスクシーケンスの第１セットを第１コンテナに割り当てる工程と、コンテナスケジューラの制御の下、第１コンテナにおいて多重化されたワーク単位でステートフルタスクシーケンスの第１セットを実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、少なくとも１つのロングテールタスクシーケンスが、最初に割り当てられたリソースよりある程度少ないリソースを消費していることを検出する工程と、当該検出に応答して、第１コンテナに１以上の追加のステートフルタスクシーケンスを割り当てる、又は、第１コンテナから１以上のマシンの割り当てを解除する工程を備える。
【０３１７】
ロングテールを有するタスクシーケンスへのリソース割り当てを管理する方法は、過剰なマシンリソースがタスクシーケンスの第１セットのみに充てられていることを検出する工程と、第１コンテナ内のマシンの第２サブセットを未使用のままにするために、第１コンテナ内のマシンの第１サブセットに対してタスクシーケンスの第１セットをスケジューリングする工程と、第１コンテナからマシンの第２サブセットの割り当てを自動的に解除する工程を備える。
【０３１８】
一実施例では、開示された方法は、過剰なマシンリソースがタスクシーケンスの第１セットのみに充てられていることを検出する工程と、第１コンテナに追加のステートフルタスクシーケンスを自動的に割り当てる工程を更に備える。開示された方法は、第１コンテナ内で実行されるタスクシーケンスの数を４から２０まで増やすことができる。
【０３１９】
幾つかの実施例では、急増するタスクシーケンスへのリソースの割り当てを管理する開示された方法は、マシン全体に亘って定義された異機種環境のコンテナ及び複数のマシンを含む幾つかのコンテナで、マシンリソースを含むコンピューティンググリッドを操作する工程を備える。本方法は、初めに複数のマシンを第１コンテナに割り当てる工程と、初めにステートフルタスクシーケンスの第１セットを第１コンテナに割り当てる工程と、コンテナスケジューラの制御の下、第１コンテナにおいて多重化されたワーク単位でステートフルタスクシーケンスの第１セットを実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、少なくとも１つのタスクシーケンスが、最初に割り当てられたリソースよりある程度多いリソースを必要としていることを検出する工程と、第１コンテナに割り当てられた複数のマシンが所定の最大値にまだ達していないことを判定する工程と、第１コンテナにより多くのマシンを自動的に割り当てる、又は、第１コンテナから第２コンテナにタスクシーケンスの第１セット内の幾つかのタスクシーケンスを再割り当てする工程を備える。開示された方法は、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナに追加のマシンを自動的に割り当てる工程と、第１コンテナ内の複数のマシンと追加のマシンに対して、タスクシーケンスの第１セットのワーク単位をスケジューリングする工程を備える。第１コンテナ内のマシンの数は、８から１０まで増やすことができる。開示された方法は、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナに割り当てられた複数のマシンが所定の最大値に達したこと、及び、マシンがタスクシーケンスの第１セットにこれ以上割り当てられないことを判定する工程を備える。
【０３２０】
急増するタスクシーケンスへのリソースの割り当てを管理する開示された方法は、実行中、タスクシーケンスの第１セットの状態情報を維持する工程と、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナから第２コンテナにタスクシーケンスの第２サブセットを自動的に再割り当てする一方で、タスクシーケンスの第１サブセットは第１コンテナに割り当てられたままにしておく工程を備える。本方法は更に、第２コンテナでタスクシーケンスの第２サブセットを初期化するために、維持された状態情報を用いる工程、第１コンテナのタスクシーケンスの第１サブセットと、第２コンテナのタスクシーケンスの第２サブセットに関してワーク単位をスケジューリングする工程を備える。
【０３２１】
一実施例では、欠陥タスクシーケンスへのリソース割り当てを管理する方法は、最初に第１コンテナにステートフルタスクシーケンスの第１セットを割り当てる工程と、再生可能な入力ソースから入力を受け取り、当該入力を処理するためにタスクシーケンスのステートフル第１セットを起動する工程と、コンテナスケジューラの制御の下で、第１コンテナ内でステートフルタスクシーケンスの第１セットを多重化されたワーク単位で実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、実行中、タスクシーケンスの第１セットの状態情報を維持する工程と、所定のタイムアウト閾値を超える欠陥タスクシーケンスにおけるワーク単位の実行時間を検出する工程と、欠陥タスクシーケンスの維持された状態情報を自動的に再ロードして欠陥タスクシーケンスを再度開始させる工程を備える。本方法はまた、欠陥タスクシーケンスへの再生可能な入力を上記検出よりも前で、且つ、欠陥タスクシーケンスに関して維持された状態情報と同期する時点まで、自動的に巻き戻す工程と、所定のタイムアウト閾値を超えることなくワーク単位の完了まで欠陥タスクシーケンスを再実行する工程とを備える。
【０３２２】
欠陥タスクシーケンスへのリソース割り当てを管理する方法は更に、第１コンテナから第２コンテナに欠陥タスクシーケンスを再度割り当てる工程と、第２コンテナで欠陥タスクシーケンスの維持された状態情報を再ロードすることで、第２コンテナで欠陥タスクシーケンスを再度開始する工程と、欠陥タスクシーケンスへの再生可能な入力を上記検出よりも前で、且つ、欠陥タスクシーケンスに関して維持された状態情報と同期する時点まで、巻き戻す工程と、所定のタイムアウト閾値を超えることなくワーク単位の完了まで欠陥タスクシーケンスを再実行する工程を備える。
【０３２３】
一実施例では、ストリーム処理システムの限られた数のワーカーノード上のロングテールタスクシーケンスを含む複数のタスクシーケンスを処理する方法は、物理スレッドを有し、１つの物理スレッドがワーカーノードのプロセッサコア全体を利用するワーカーノードに対して、コンテナを定義する工程を備える。本方法はまた、複数のタスクシーケンスに関して、コンテナで実行されるパイプラインに、入力された準リアルタイム（ＮＲＴ）データストリームからのデータを待ち行列に追加する工程と、ＮＲＴデータストリームからのデータをバッチとして、当該バッチのディスパッチを制御するコンテナコーディネータを用いて処理する工程と、当該バッチを物理スレッドにディスパッチする工程を備え、バッチは完了又はタイムアウトまで実行され、実行中は利用可能な物理スレッドのカウントが論理的に並行なスレッドの設定数と比較される。本方法は更に、利用可能な物理スレッドのカウントが、論理的に並行なスレッドの数と等しい、又は、それを超える場合は、物理スレッドでバッチを同時に処理し、利用可能な物理スレッドが論理的に並行なスレッドの数よりも少ない場合は、利用可能な物理スレッドに対してバッチを順番に多重化する工程を備える。
【０３２４】
幾つかの実施例では、開示された方法は更に、パイプライン内の少なくとも１つのバッチのサブセットを、パイプライン内の少なくとも１つの別のバッチのサブセットと同時に処理する工程と、当該両サブセットの少なくとも幾つかのバッチを順番に多重化する工程を備える。幾つかの実施例では、論理的に並行なスレッドの数は１０であり、利用可能な物理スレッドのカウントは１０であり、本方法は更に、１０個の利用可能な物理スレッドにおけるパイプラインのバッチを同時に処理する工程を備える。他の実施例では、論理的に並行なスレッドの数は１０であり、利用可能な物理スレッドのカウントは９である。開示された方法は更に、９個の利用可能な物理スレッドの内、８個で、パイプライン内のバッチを同時に処理する工程と、少なくとも１個の利用可能な物理スレッドについて、パイプライン内の幾つかのバッチを、順番に多重化する工程を備える。
【０３２５】
別の実施例では、論理的に並行なスレッドの数は１０であり、利用可能な物理スレッドのカウントは１であり、１個の利用可能な物理スレッドに対して、パイプライン内のバッチを順番に多重化する工程が含まれる。多重化には、パイプラインで次のバッチを処理する前に、完了又はタイムアウトまで、パイプラインでバッチを処理する工程を含むことが可能である。
【０３２６】
幾つかの実施例では、開示された方法は更に、コンテナ内の複数のワーカーノードに対して、複数のパイプラインを同時に処理する工程を含むことが可能である。
【０３２７】
バッチは、幾つかの実施例に関しては、タイムスライスベースで定義され、時間窓内で最近受け取った少なくとも１つの入力されたＮＲＴデータストリームの一部分を含む。他の実施例では、バッチは、バッチサイズベースで定義され、最近受け取った少なくとも１つの入力されたＮＲＴデータストリームのデータサイズが制約された部分を含む。
【０３２８】
一実施例では、ロングテールを有するタスクシーケンスへのリソース割り当てを管理する方法は、マシン全体に亘って定義された異機種環境のコンテナ及び複数のマシンを含む幾つかのコンテナで、マシンリソースを含むコンピューティンググリッドを操作する工程を備える。本方法は、初めに複数のマシンを第１コンテナに割り当てる工程と、初めにステートフルタスクシーケンスの第１セットを第１コンテナに割り当てる工程と、コンテナスケジューラの制御の下、第１コンテナにおいて多重化されたワーク単位でステートフルタスクシーケンスの第１セットを実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、少なくとも１つのロングテールタスクシーケンスが、最初に割り当てられたリソースよりある程度少ないリソースを消費していることを検出する工程と、当該検出に応答して、第１コンテナに１以上の追加のステートフルタスクシーケンスを割り当てる、又は、第１コンテナから１以上のマシンの割り当てを解除する工程を備える。
【０３２９】
ロングテールを有するタスクシーケンスへのリソース割り当てを管理する方法は、過剰なマシンリソースがタスクシーケンスの第１セットのみに充てられていることを検出する工程と、第１コンテナ内のマシンの第２サブセットを未使用のままにするために、第１コンテナ内のマシンの第１サブセットに対してタスクシーケンスの第１セットをスケジューリングする工程と、第１コンテナからマシンの第２サブセットの割り当てを自動的に解除する工程を備える。
【０３３０】
一実施例では、開示された方法は、過剰なマシンリソースがタスクシーケンスの第１セットのみに充てられていることを検出する工程と、第１コンテナに追加のステートフルタスクシーケンスを自動的に割り当てる工程を更に備える。開示された方法は、第１コンテナ内で実行されるタスクシーケンスの数を４から２０まで増やすことができる。
【０３３１】
幾つかの実施例では、急増するタスクシーケンスへのリソースの割り当てを管理する開示された方法は、マシン全体に亘って定義された異機種環境のコンテナ及び複数のマシンを含む幾つかのコンテナで、マシンリソースを含むコンピューティンググリッドを操作する工程を備える。本方法は、初めに複数のマシンを第１コンテナに割り当てる工程と、初めにステートフルタスクシーケンスの第１セットを第１コンテナに割り当てる工程と、コンテナスケジューラの制御の下、第１コンテナにおいて多重化されたワーク単位でステートフルタスクシーケンスの第１セットを実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、少なくとも１つのタスクシーケンスが、最初に割り当てられたリソースよりある程度多いリソースを必要としていることを検出する工程と、第１コンテナに割り当てられた複数のマシンが所定の最大値にまだ達していないことを判定する工程と、第１コンテナにより多くのマシンを自動的に割り当てる、又は、第１コンテナから第２コンテナにタスクシーケンスの第１セット内の幾つかのタスクシーケンスを再割り当てする工程を備える。開示された方法は、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナに追加のマシンを自動的に割り当てる工程と、第１コンテナ内の複数のマシンと追加のマシンに対して、タスクシーケンスの第１セットのワーク単位をスケジューリングする工程を備える。第１コンテナ内のマシンの数は、８から１０まで増やすことができる。開示された方法は、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナに割り当てられた複数のマシンが所定の最大値に達したこと、及び、マシンがタスクシーケンスの第１セットにこれ以上割り当てられないことを判定する工程を備える。
【０３３２】
急増するタスクシーケンスへのリソースの割り当てを管理する開示された方法は、実行中、タスクシーケンスの第１セットの状態情報を維持する工程と、第１コンテナ内でタスクシーケンスの第１セットを実行する際に所定の閾値を超える待ち時間を検出する工程と、第１コンテナから第２コンテナにタスクシーケンスの第２サブセットを自動的に再割り当てする一方で、タスクシーケンスの第１サブセットを第１コンテナに割り当てられたままにしておく工程を備える。本方法は更に、第２コンテナでタスクシーケンスの第２サブセットを初期化するために、維持された状態情報を用いる工程、第１コンテナのタスクシーケンスの第１サブセットと、第２コンテナのタスクシーケンスの第２サブセットに関してワーク単位をスケジューリングする工程を備える。
【０３３３】
一実施例では、欠陥タスクシーケンスへのリソース割り当てを管理する方法は、最初に第１コンテナにステートフルタスクシーケンスの第１セットを割り当てる工程と、再生可能な入力ソースから入力を受け取り、当該入力を処理するために、タスクシーケンスのステートフルな第１セットを起動する工程と、コンテナスケジューラの制御の下に、第１コンテナ内でステートフルタスクシーケンスの第１セットを多重化されたワーク単位で実行する工程を備え、第１タスクシーケンスに関する各ワーク単位は、第２タスクシーケンスに関する次のワーク単位が第１マシンリソース上で多重化されて実行される前に、タイムアウトを超過しない限り、第１コンテナにおける第１マシンリソース上で完了するまで実行される。本方法は更に、実行中、タスクシーケンスの第１セットの状態情報を維持する工程と、所定のタイムアウト閾値を超える欠陥タスクシーケンスにおけるワーク単位の実行時間を検出する工程と、欠陥タスクシーケンスの維持された状態情報を自動的に再ロードして欠陥タスクシーケンスを再度開始させる工程を備える。本方法はまた、欠陥タスクシーケンスへの再生可能な入力を上記検出よりも前で、且つ、欠陥タスクシーケンスに関して維持された状態情報と同期する時点まで、自動的に巻き戻す工程と、所定のタイムアウト閾値を超えることなくワーク単位の完了まで欠陥タスクシーケンスを再実行する工程を備える。
【０３３４】
欠陥タスクシーケンスへのリソース割り当てを管理する方法は更に、第１コンテナから第２コンテナに欠陥タスクシーケンスを再度割り当てる工程と、第２コンテナで欠陥タスクシーケンスの維持された状態情報を再ロードすることで、第２コンテナで欠陥タスクシーケンスを再度開始する工程と、欠陥タスクシーケンスへの再生可能な入力を上記検出よりも前で、且つ、欠陥タスクシーケンスに関して維持された状態情報と同期する時点まで、巻き戻す工程と、所定のタイムアウト閾値を超えることなくワーク単位の完了まで欠陥タスクシーケンスを再実行する工程を備える。
【０３３５】
一実施例における、ストリーム処理システムの限られた数のワーカーノード上でのロングテールタスクシーケンスを含む複数のタスクシーケンスを処理する方法は、物理スレッドを有し、１つの物理スレッドがワーカーノードのプロセッサコア全体を利用するワーカーノードに対して、コンテナを定義する工程を備える。本方法はまた、複数のタスクシーケンスに関して、コンテナで実行されるパイプラインに、入力された準リアルタイム（ＮＲＴ）データストリームからのデータを待ち行列に追加する工程と、ＮＲＴデータストリームからのデータをバッチとして、当該バッチのディスパッチを制御するコンテナコーディネータを用いて処理する工程と、当該バッチを物理スレッドにディスパッチする工程を備え、バッチは完了又はタイムアウトまで実行され、実行中は利用可能な物理スレッドのカウントと、論理的に並行なスレッドの設定数が比較される。本方法は更に、利用可能な物理スレッドのカウントが、論理的に並行なスレッドの数と等しい、又は、それを超える場合は、物理スレッドでバッチを同時に処理する工程と、利用可能な物理スレッドが論理的に並行なスレッドの数よりも少ない場合は、利用可能な物理スレッドに対してバッチを順番に多重化する工程を備える。
【０３３６】
幾つかの実施例では、開示された本方法は、パイプライン内の少なくとも１つのバッチのサブセットを、パイプライン内の少なくとも１つの別のバッチのサブセットと同時に処理する工程と、当該両サブセットの少なくとも幾つかのバッチを順番に多重化する工程を備える。幾つかの実施例では、論理的に並行なスレッドの数は１０であり、利用可能な物理スレッドのカウントは１０である。本発明は更に、１０個の利用可能な物理スレッドでパイプライン内の複数のバッチを同時に処理する工程を備えることが可能である。他の実施例では、論理的に並行なスレッドの数は１０であり、利用可能な物理スレッドのカウントは９である。開示された本方法は更に、９個の利用可能な物理スレッドの内、８個で、パイプライン内の複数のバッチを同時に処理する工程と、少なくとも１個の利用可能な物理スレッドについて、パイプライン内の幾つかのバッチを、順番に多重化する工程を備える。
【０３３７】
別の実施例では、論理的に並行なスレッドの数は１０であり、且つ、利用可能な物理スレッドのカウントは１であり、１個の利用可能な物理スレッドに対して、パイプライン内のバッチを順番に多重化する工程が含まれる。多重化には、パイプラインで次のバッチを処理する前に、完了又はタイムアウトまで、パイプラインでバッチを処理する工程を含むことが可能である。
【０３３８】
幾つかの実施例では、開示された本方法は更に、コンテナ内の複数のワーカーノードに対して、複数のパイプラインを同時に処理する工程を含むことが可能である。
【０３３９】
バッチは、幾つかの実施例に関しては、タイムスライスベースで定義され、時間窓内で最近受け取った少なくとも１つの入力されたＮＲＴデータストリームの一部分を含む。他の実施例では、バッチは、バッチサイズベースで定義され、最近受け取った少なくとも１つの入力されたＮＲＴデータストリームのデータサイズが制約された部分を含む。
＜ワークロード管理を備えたステートマシン装置の構成＞
【０３４０】
一実施例では、非プログラミングユーザ向けの、エンティティ管理ワークフローの作成を単純化する方法を説明する。本方法は、人間−機械の相互作用に依存せずに機械によって生成された機械生成イベントを処理するワークフローステートマシンにおいて、複数のケース−ステータス状態を表示する工程と、第１イベントの後の少なくとも第１ケース−ステータス状態の間に、入力された第２イベントを無視するか、又は、処理するかを決定するために、イベントプリプロセッサによって使用されるイベントフィルタリング条件をメモリに記録する工程を備える。本方法はまた、イベントフィルタリング条件の整数のカウントパラメータを初期化する工程を備え、当該カウントパラメータは、一定の期間内の回数に制限を指定し、当該制限を越えると合致する特徴を持った追加のイベントは無視又は放棄される。本方法は更に、入力された機械生成イベントを処理する命令をワークフローエンジンステートマシン装置にロードする工程と、少なくともケース−ステータス状態及びイベントフィルタリング条件に応じて選択された命令を実行する工程を備える。
【０３４１】
１つのサーバ側の実施例において、非プログラミングユーザ向けの、エンティティ管理ワークフローの作成を単純化する方法を説明する。本方法は、エンティティとの相互作用を自動的に多段階で進行させるステートマシンを指定する宣言的入力を受け付けるデータエントリカラムナを、表示のために、生成するステートマシンビルダーを備える。幾つかの実施例では、データエントリカラムナは、多段階進行における状態に関する少なくとも１つのカラム、タイムベース遷移トリガー、イベントベース遷移トリガー、条件の定義、タイムベース遷移トリガーとイベントベース遷移トリガーの少なくとも１つによって生じる状態遷移に応じた択一的な動作を含む。
【０３４２】
本方法はまた、一定の期間が経過すると状態遷移を引き起こすタイマーによって、及び、状態遷移を引き起こすイベントによって、択一的に指定される状態遷移トリガーを定義するデータエントリカラムナへの宣言的入力を受領する工程を備える。
【０３４３】
本方法は更に、タイムベース遷移トリガーとイベントベース遷移トリガーの少なくとも１つによって生じる状態遷移に応答して実行される、選択された択一的な動作を指定するデータエントリカラムナへの宣言的入力を受領する工程と、当該宣言的入力、又は、当該宣言的入力を用いてステートマシン装置が構築したワークフローを保存する工程を備える。
【０３４４】
本方法は更に、条件が満足されることに応答して、ステートマシン装置の遷移プロセッサが、状態遷移の間に択一的な動作の実行を起動する工程を備える。
【０３４５】
開示された技術の本章及び他の章で記載した方法は、以下の特徴、及び／又は、開示された追加の方法に関連して記載された特徴の１以上を含むことができる。簡潔性のために、本出願で開示された特徴の組み合わせは、個々に列挙することはせず、特徴の基本となるセット毎に繰り返すこともない。読者は、本方法で識別される特徴が、専門用語、序論、ＩｏＴプラットフォーム及びストリーム−バッチ処理フレームワーク、ステートマシン、データカラムナ、フローチャート、マルチテナント統合、幾つかの特定の実施例等といった、実施例として識別される基本の特徴のセットと如何に容易に組み合わせられるかを理解するであろう。
【０３４６】
一実施例では、本方法は、１回だけの期間中に、第２の入力されたイベントを無視することで、第２の入力されたイベントに対しては何れのワークフロー動作も起動しないことを含む。
【０３４７】
別の実施例では、データエントリカラムナへの宣言的入力は更に、全ての状態に適用されるグローバルな状態遷移に応じた少なくとも１つの常時動作の仕様を含む。
【０３４８】
更に別の実施例では、データエントリカラムナへの宣言的入力は更に、エンティティの複数の状態の仕様を含む。
【０３４９】
幾つかの実施例では、エンティティが電子機器の場合、当該電気機器の状態には、オン、オフ、スタンバイ、電源投入、電源切断、全電力のパーセンテージ、ネットワーク接続の範囲の内、少なくとも１つが更に含まれる。
【０３５０】
幾つかの実施例では、宣言的入力は、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領される。一実施例では、宣言的入力には、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つが含まれる。別の実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。更に別の実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
【０３５１】
一実施例では、非プログラミングユーザ向けの、エンティティ管理ワークフローの作成を単純化する方法を説明する。本方法は、人間−機械の相互作用に依存せずに機械によって生成された機械生成イベントを処理するワークフローステートマシンにおいて、複数のケース−ステータス状態を表示する工程を備える。本方法は更に、複数のケース−ステータス状態における少なくとも第１のケース−ステータス状態の間に、入力された第２イベントを無視するか、又は、処理するかを決定するために、イベントフィルタリング条件をメモリに記録する工程を備える。イベントフィルタリング条件は、第１イベントで開始され、第１イベントと合致する特徴を持った第２イベントが無視又は放棄される１回だけの期間を指定する時間パラメータを含む。本方法は更に、入力された機械生成イベントを処理する命令をワークフローエンジンにロードする工程と、少なくともケース−ステータス状態及びイベントフィルタリング条件に応じて選択された命令を実行する工程を備える。
【０３５２】
幾つかの実施例では、宣言的入力は、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領される。一実施例では、宣言的入力には、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つが含まれる。一実施例では、本方法は更に、状態遷移中に条件を、当該条件が参照するデータベースフィールドの少なくとも１つの値に対して、評価する工程を備える。
【０３５３】
一実施例では、データエントリカラムナへの入力を示すデータは更に、状態遷移に応答した動作の実行に続いて得られる少なくとも１つの状態の仕様を含む。
【０３５４】
別実施例では、データエントリカラムナへの入力を示すデータは更に、全ての状態に適用されるグローバルな状態遷移に応じた少なくとも１つの常時動作の仕様を含む。
【０３５５】
更に別の実施例では、データエントリカラムナへの入力を示すデータは更に、エンティティの複数の状態の仕様を含む。
【０３５６】
開示された一実施例では、非プログラミングユーザ向けの、エンティティ管理ワークフローの作成を単純化する方法は、エンティティとの相互作用を自動的に多段階で進行させるステートマシンを指定する宣言的入力を受け付けるデータエントリカラムナのＧＵＩを、表示のために、生成する工程を備え、データエントリカラムナは、多段階進行における状態に関する少なくとも１つのカラムと、状態遷移を引き起こすタイムベース遷移トリガー及びイベントベース遷移トリガー（状態遷移を引き起こす条件の定義を含む）と、第１イベントで始まる期間であってその間は第１イベントと合致する特徴を持つ入力された第２イベントが無視又は放棄される１回だけの期間を指定する時間パラメータを含むスロットル表現を含む。開示された本方法はまた、一定の期間が経過すると状態遷移を引き起こすタイマーと、状態遷移を引き起こし、スロットル表現を定義するイベントによって、択一的に指定される状態遷移トリガーを定義するデータエントリカラムナへの宣言的入力を受領する工程と、タイムベース遷移トリガーとイベントベース遷移トリガーの内、少なくとも１つによって生じる状態遷移に応答して実行される選択された択一的な動作を指定するデータエントリカラムナへの宣言的入力を受領する工程を備える。本方法は更に、宣言的入力又は当該宣言的入力から構築されるワークフローを保存する工程を備える。
【０３５７】
幾つかの実施例では、エンティティが電気機器の場合、当該電気機器の状態には、少なくとも、オン、オフ、スタンバイ、電源投入、電源切断、全電力のパーセンテージ、ネットワーク接続の範囲の内、少なくとも１つが更に含まれる。
【０３５８】
幾つかの実施例では、宣言的入力が、メッセージバス及びストリーム処理システムを備える準リアルタイム（ＮＲＴ）イベント管理フレームワークから受領される。一実施例では、宣言的入力には、ユーザクリックデータ、ユーザ購買行動、装置データ、ソーシャルメディアストリームの内、少なくとも１つが含まれる。別の実施例では、メッセージバスは、Kafka、Flume、ActiveMQ、RabbitMQの内、少なくとも１つである。更に別の実施例では、ストリーム処理システムは、StormとSparkの内、少なくとも１つである。
【０３５９】
本章に記載の方法の他の実施例は、上述した本方法の何れかを実行するために、プロセッサによって実行可能なコンピュータプログラム命令が与えられた非一時的なコンピュータ可読記憶媒体を含むことができる。本章に記載の方法の更に別の実施例は、上述した方法の何れかを実行するために、コンピュータプログラム命令がロードされたメモリ、及び、当該メモリに格納された命令を実行する動作が可能な１以上のプロセッサを備えるシステムを含むことが可能である。
【０３６０】
ここで使用された用語及び表現は、説明のための用語及び表現として使用されており、限定するためのものではない。また、こうした用語及び表現を用いて、表示又は記載された特徴の如何なる均等物、或いは、その一部を排除する意図はない。また、開示された技術の特定の実施例が記載されているが、ここに開示された概念を取り入れる他の実施例が、開示された技術の精神及び範囲から逸脱することなく使用できることは、当業者にとって明らかである。したがって、記載された実施例は、全ての側面において、限定的ではなく、単なる説明として考えられる。
【図１】
0006523354.tif 000002
【図２】
0006523354.tif 000003
【図３】
0006523354.tif 000004
【図４Ａ】
0006523354.tif 000005
【図４Ｂ】
0006523354.tif 000006
【図４Ｃ】
0006523354.tif 000007
【図５Ａ】
0006523354.tif 000008
【図５Ｂ】
0006523354.tif 000009
【図６Ａ】
0006523354.tif 000010
【図６Ｂ】
0006523354.tif 000011
【図７】
0006523354.tif 000012
【図８Ａ】
0006523354.tif 000013
【図８Ｂ】
0006523354.tif 000014
【図８Ｃ】
0006523354.tif 000015
【図９】
0006523354.tif 000016
【図１０】
0006523354.tif 000017
【図１１】
0006523354.tif 000018
【図１２Ａ】
0006523354.tif 000019
【図１２Ｂ】
0006523354.tif 000020
【図１３Ａ】
0006523354.tif 000021
【図１３Ｂ】
0006523354.tif 000022
【図１３Ｃ】
0006523354.tif 000023
【図１４】
0006523354.tif 000024
【図１５】
0006523354.tif 000025