JP2022542092A - １つ又は複数の任意に定義されたワークフローのリモート実行のためのシステム及び方法 - Google Patents

Abstract

１つ又は複数の任意に定義されたワークフローのリモート実行のためのシステムは、所定のワークフローにおいて定義された１つ又は複数の機能を顧客計算基盤で実行するように動作可能なワークフローエンジンと、所定のワークフローの状態を定義するメタデータを保持するワークフローデータベースへのアクセスを有するワークフローアドミストレータであって、ワークフローエンジンからリモートであり、及び顧客計算基盤で実行していないワークフローアドミニストレータとを含む。ワークフローアドミニストレータエージェントは、ワークフローアドミニストレータをポーリングして、所定のワークフローが、実行のためにスケジュールされているときを識別し、及びスケジュールされているとき、所定のワークフローをワークフローレジストリから取得し、且つ所定のワークフローにおいて定義された１つ又は複数の機能を顧客計算基盤で実行するためのコマンドをワークフローエンジンに発行する。ワークフローアドミニストレータエージェントは、ワークフローデータベースに記憶するために、所定のワークフローの実行に関する状態情報をワークフローアドミニストレータに送信する。

Description

関連出願の相互参照
[0001] 本願は、２０１９年８月１日付けで出願された「SYSTEM AND METHOD FOR THE REMOTE EXECUTION OF ONE OR MORE ARBITRARILY DEFINED WORKFLOWS」という名称の米国仮特許出願第６２／８８１，５６８号に対するの優先権を主張するものであり、その開示は、あらゆる目的のために全体として参照により本明細書に援用される。

発明の背景
[0002] ワークフロー管理解決策は、データが管理されている顧客の代理としてそのようなワークフロー解決策を実行するか又は他に稼働させることを伴う。そのようなワークフロー管理解決策の実行は、典型的には、顧客の内部ネットワーク内での顧客コードの実行を制御することを含み、これは、顧客ネットワーク外部の信頼できるリソース及び信頼できないリソースの両方とのインターフェースを更に含み得る。顧客ネットワーク内及び顧客ネットワークなしでの顧客コードの実行は、別個の信頼性問題を呈する。顧客は、任意のワークフロー管理ソフトウェアのプロバイダが顧客ネットワーク内で実行することになるコードを信頼しなければならない一方、ソフトウェアプロバイダは、受信された任意の顧客コード及び／又はデータが悪意のある性質のものではないことを、そのような悪意のあるコードの注入が意図的であるか否かに関係なく信頼しなければならない。

[0003] したがって、当技術分野で必要とされているのは、１つ又は複数のワークフローのハイブリッド実行を提供するシステム及び方法であり、より具体的には、実際のコード実行及びデータ保守が顧客環境内で行われるが、１つ又は複数のリモートプロセスによって指揮されるシステム及び方法である。

発明の概要
[0004] 本発明の実施形態は、１つ又は複数のワークフローの完全に管理されるリモート指揮を提供するシステム及び方法に関する。そのような実施形態によれば、１つ又は複数のワークフローの実行を指揮するタスクを、顧客環境内でコードを任意に実行するタスクから切り離すシステム及び方法が提供される。このハイブリッド実行モデルによれば、顧客コードは、常に顧客のプライベート基盤に留まる。したがって、顧客は、１つ又は複数のワークフローの設計、テスト及び構築を行い、所定のワークフローは、１つ又は複数のタスクを含む。顧客は、幾つかのオープン及びクローズソースツール、例えばPrefect Technologies, Inc.によって提供され、https://www.prefect.io./coreからダウンロード可能なオープンソースワークフローオーサリング環境PREFECT CORE（商標）を用いて、所定のワークフローをオーサリングし得る。PREFECT COREワークフローエンジンの一実施形態を実施するソフトウェアライブラリ及びバイナリは、www.github.com/PrefectHQ/prefectにおいて公開されており、その開示は、全体として参照により本明細書に援用される。

[0005] ワークフローの準備ができると、顧客は、ワークフローの存在をリモート又はクラウドワークフロー基盤に登録し、それによりワークフローのコードレス版を再構築するのに十分なメタデータがリモート又はクラウドワークフロー基盤に送信されることになり、詳細は、限定されないが、所定のワークフローに含まれるタスク、そのようなタスクの従属構造、ワークフロー実行のスケジュール、ワークフローのランタイム環境についての情報等を含む。

[0006] リモート又はクラウドワークフロー基盤がそのような情報を保有すると、そのようなリモート基盤が、ワークフローの実行の一環として実行される基礎となるコードへのアクセスを有さない場合でも、ワークフローの指揮を開始することができる。一実施形態によるワークフロー実行は、所定のワークフローのリモート表現を「スケジュール済み」状態にすることを含む。顧客基盤で実行されているエージェントは、実行のためにスケジュールされたワークフローの可用性をモニタする。エージェントは、スケジュールされたワークフローを識別する場合、そのワークフローを取得し、そのワークフローを含む１つ又は複数のタスクの実行を開始する。そのような実行は、ローカルで又はリモート実行クラスタにおいて行われ得、それは、専ら顧客による定義に委ねられたデプロイ判断である。ワークフローを含む所定のタスクは、「実行」状態を経るにつれて、最終的に「成功」、「失敗」又は「再試行」を含む状態になり、そのような情報は、リモート又はクラウドワークフロー基盤にメタデータの１つ又は複数の項目として通信される。このようにして、全て顧客基盤に常駐するコード又はデータにアクセスする必要なく、中心ブローカーを通して、顧客基盤で実行中の複数の同時ワークフローを連携させることができる。

[0007] 一実施形態によれば、１つ又は複数の任意に定義されたワークフローのリモート実行のためのシステムは、所定のワークフローにおいて定義された１つ又は複数の機能を顧客基盤で実行するように動作可能なワークフローエンジンと、所定のワークフローの状態を記述するメタデータを保持するワークフローデータベースへのアクセスを有するワークフローアドミストレータであって、ワークフローエンジンからリモートであり、及び顧客基盤で実行していないワークフローアドミニストレータとを含む。本システムは、ワークフローアドミニストレータをポーリングして、所定のワークフローが、実行のためにスケジュールされている状態であるときを識別するワークフローアドミニストレータエージェントも含む。所定のワークフローがスケジュールされているとき、ワークフローアドミニストレータエージェントは、所定のワークフローをワークフローレジストリから取得し、且つ所定のワークフローにおいて定義された１つ又は複数の機能を顧客基盤で実行するためのコマンドをワークフローエンジンに発行し、ワークフローアドミニストレータエージェントは、ワークフローデータベースに記憶するために、所定のワークフローの実行に関する状態情報をワークフローアドミニストレータに送信する。

[0008] 本実施形態によるシステムは、ワークフローアドミニストレータに転送するために、ワークフローアドミニストレータエージェントから要求及びコマンドを受信するためのＡＰＩも含む。同様に、ＡＰＩは、ワークフローアドミニストレータエージェントに転送するために、ワークフローアドミニストレータから要求及びコマンドへの応答を受信する。より具体的には、ワークフローアドミニストレータは、ワークフローデータベースに問い合わせて、ワークフローアドミニストレータエージェントからの要求に応答する情報を取得し得、これは、ＡＰＩの使用を含み得、ワークフローアドミニテストレータエージェントからの要求は、実行を必要とする利用可能なワークフローについてのクエリを含み得る。更に、本実施形態に立脚して、ワークフローレジストリは、所定のワークフローの一部を形成するステップについてのビジネス論理を保持し、及びワークフローエンジンは、顧客基盤からリモートに配置し得る。

[0009] 一実施形態による、１つ又は複数の任意に定義されたワークフローのリモート実行のための方法は、ワークフローアドミニストレータエージェントを顧客基盤で、及びワークフローエンジンからリモートであるワークフローアドミニストレータをクラウド基盤で実行することと、ワークフローアドミニストレータに、所定のワークフローの状態を記述するメタデータを保持するワークフローデータベースへのアクセスを提供することとを含む。ワークフローアドミニストレータエージェントは、ワークフローアドミニストレータをポーリングして、所定のワークフローが、実行のためにスケジュールされている状態であるときを識別し、及び所定のワークフローが実行のためにスケジュールされているとき、所定のワークフローをワークフローレジストリから取得し、且つ所定のワークフローにおいて定義された１つ又は複数の機能を顧客基盤で実行するためのコマンドをワークフローエンジンに発行する。ワークフローアドミニストレータエージェントは、ワークフローデータベースに記憶するために、所定のワークフローの実行に関する状態情報をワークフローアドミニストレータに送信する。

[0010] 本実施形態による方法は、ＡＰＩにより、ワークフローアドミニストレータエージェントから要求及びコマンドを受信することに続き、ワークフローアドミニストレータエージェントは、受信された要求及びコマンドをワークフローアドミニストレータに転送する。同様に、ＡＰＩは、ワークフローアドミニストレータから要求及びコマンドへの応答を受信し、ワークフローアドミニストレータは、それをワークフローアドミニストレータエージェントに転送する。ワークフローアドミニストレータは、ワークフローデータベースに問い合わせて、ワークフローアドミニストレータエージェントからの要求に応答する情報を取得し得、これは、１つ又は複数のワークフローエージェントとの通信を含み得る。一実施形態によれば、ワークフローデータベースに問い合わせることは、実行を必要とする利用可能なワークフローについて問い合わせることを含む。本実施形態の方法は、ワークフローレジストリにおいて、所定のワークフローの一部を形成するステップについてのビジネス論理を保持するステップと、顧客基盤からリモートでワークフローエンジンを動作させるステップとを更に含み得る。

図面の簡単な説明
[0011] 本発明は、限定ではなく、例示を意図される添付図面の図に示され、図面では、同様の参照は、同様の又は対応する部分を指す。

[0012]本発明の一実施形態による、１つ又は複数の任意に定義されたワークフローのリモート実行のためのシステムを示すブロック図を提示する。 [0013]本発明の一実施形態による、ワークフローをローカルワークフロー基盤にデプロイし、対応するメタデータをリモートワークフロー基盤にデプロイする方法を示す流れ図を提示する。 [0014]本発明の一実施形態による、ワークフローを実行する方法を示す流れ図を提示する。 [0015]本発明の一実施形態による、ワークフローを実行する方法を示す流れ図を提示する。 [0016]本発明の一実施形態による、１つ又は任意に定義されたワークフローのリモート実行のための代替のシステムを示すブロック図を提示する。 [0017]本発明の種々の実施形態と併せてデプロイされるハードウェア及びソフトウェア構成要素を管理するユーザインターフェースの一実施形態を示す画面図を提示する。 [0017]本発明の種々の実施形態と併せてデプロイされるハードウェア及びソフトウェア構成要素を管理するユーザインターフェースの一実施形態を示す画面図を提示する。 [0017]本発明の種々の実施形態と併せてデプロイされるハードウェア及びソフトウェア構成要素を管理するユーザインターフェースの一実施形態を示す画面図を提示する。 [0017]本発明の種々の実施形態と併せてデプロイされるハードウェア及びソフトウェア構成要素を管理するユーザインターフェースの一実施形態を示す画面図を提示する。 [0017]本発明の種々の実施形態と併せてデプロイされるハードウェア及びソフトウェア構成要素を管理するユーザインターフェースの一実施形態を示す画面図を提示する。

発明の実施形態の詳細な説明
[0018] 本明細書で使用されるワークフローは、エンドユーザ計算基盤への／からのデータに対して機能を実行するか、又はエンドユーザ計算基盤に／からデータを読み出す幾つかの離散したタスクを含むプロセスである。タスクは、所定のワークフロー内の各タスクの状態管理を担当する「ワークフロー」エンジンによって支配されるルールのシステムに従って互いに従属し得る。例示的なルールには、限定されないが、あるタスクの開始を、１つ又は複数の他のタスクが特定の状態になるまで阻止するルール、特定の時間においてタスクのスケジュール又は再試行を許可するルール、あるタスクによって生成されたデータの後のタスクによる消費を許可するルール等がある。

[0019] 本願の趣旨である、ワークフロー実行のためのシステム等の実行可能なソフトウェアシステムのデプロイの２つの一般的な製品は、典型的には、完全に管理されるか又はオンプレミスである。完全に管理された製品には、サービスプロバイダ又はソフトウェアプロバイダによって所有及び／又は運営される基盤での全コードの記憶及び実行が含まれる。一方、オンプレミスには、エンドユーザの基盤でデプロイされ、実行されるパッケージングソフトウェアが含まれる。本願に記載されるワークフローデプロイ及び実行のモデルは、管理されたモデル及びオンプレミスモデルの両方の融合を含むため、「ハイブリッド」実行モデルと呼ばれる。

[0020] 上記に鑑みて、ワークフローを所定の計算環境で実行することはは有用であるが、スケジュールされたワークフロー及び実行中のワークフローとリモート対話する必要がある。本発明の種々の実施形態のシステム及び方法は、ユーザが、コアで開発されたワークフローを、ワークフローアドミニストレータ構成要素（「ワークフローアドミニストレータ」）の連携且つ制御下にあり得る、ワークフローデータベース及びＡＰＩサーバを含むステートフルアーキテクチャに接続できるようにする。システムは、有利には、ユーザがワークフローとリモートで対話できるようにする（例えば、実行のスケジュール又は状態の設定）と共に、ワークフローデータベースに問い合わせられるようにする完全ＡＰＩを提供する。基本的に、本明細書に記載されるプログラムコンストラクトは、コアで開発される所定のワークフローを「囲み」、ワークフローの実行を管理及びモニタするために必要な基盤を提供する。

[0021] 本発明の実施形態の一特徴は、所定のワークフローの又は所定のワークフローによって操作し得る実際のコード又はデータにアクセスする必要性をなくすことである。したがって、これらのシステムは、所定のワークフロー自体を記述するメタデータにアクセスするのみでよく、それにより、エンドユーザがコアを利用して、ローカルマシンでワークフローを設計できるようにするプロセスの作成が可能になる。設計されると、これらのワークフローは、「ビルド」され、すなわちエンドユーザによって所有及び／又は制御される基盤にデプロイされる。

[0022] エンドユーザ所有又は制御の基盤にワークフローをデプロイする場合、ワークフローエンジンの一部を形成するプログラムコードは、例えば、１つ又は複数のクラウドサーバに配置されたリモートワークフローデータベースにメタデータを送信する。所定のワークフロー及び／又はその状態を記述するメタデータは、限定されないが、所定のワークフローを構成する１つ又は複数のタスクの名称、時間従属性及びデータ従属性等の種々の組合せを含み得る、所定のワークフローを構成する種々のタスク間の従属性等の情報を含み得る。ワークフローアドミニストレータは、この情報を使用してワークフローの「ダミー」版を再構築し得、次いでこれを使用して、任意の所定のワークフローに関する実質的ないかなる情報も決して知ることなく、実際のワークフローを指揮し得る。エンドユーザは、定義され、ビルドされた所定のワークフローの実行を望む場合、信号をワークフローアドミニストレータに送信し、これは、ワークフローアドミニストレータがエンドユーザに対して公開するユーザインターフェース上のボタンを選択すること又はＡＰＩ若しくはＣＬＩコールを通してコマンドを発行することを含み得る。

[0023] ワークフローのリモート実行の開始を試みる場合、ワークフローアドミニストレータは、エンドユーザがワークフローデータベースに以前に保存したメタデータを使用して、要求されたワークフローをロードし、ダミー版を「スケジュール済み」状態にする。エージェントは、一実施形態によれば、エンドユーザが自らのプライベート基盤で実行する小さいコードであり、ワークフローがスケジュール済み状態になるのをリッスンし、そのようなイベントを発見すると、ワークフローをエンドユーザの基盤にデプロイするようにワークフローエンジンに指示する。ワークフローが実行するにつれて、エージェントは、ワークフローデータベースに記憶するために、状態変更の更新をワークフローアドミニストレータに通信する。リモートワークフロー基盤に常駐するダミーワークフローの任意の改変も同様にエンドユーザの基盤に同期することができ、例えばタスクを実際に実行する前に手動でタスクを特定の状態にする。

[0024] したがって、ワークフローアドミニストレータは、ワークフローデータベース内のデータを公開して、エンドユーザがビルドした１つ又は複数のワークフローの完全なオーバービュー、例えば実行中のタスク、失敗したタスク、各タスクにかかる時間及びそれらのエンドユーザが機密コード又はデータを決して共有する必要なくそれらのワークフローと対話する方法をそのようなエンドユーザに提供することができる。

システム基盤
[0025] 図１は、本明細書に記載されるワークフロー実行のハイブリッドデプロイのシステムの一実施形態を示す。本発明のハイブリッドデプロイモデルは、エンドユーザが小さいエージェント１０４を自らのローカルワークフロー基盤１０２にデプロイするプロセスを含む。一実施形態によるエージェント１０４は、ワークフローエンジン１０８による実行に向けてワークフローレジストリ１０６からワークフローを取得し、ワークフロー基盤を作成し、任意選択的に上記基盤を分解するためにエンドユーザが自らのローカルワークフロー基盤１０２にインストールする小さいアプリケーションであり、ワークフローエンジン１０８によって実行され得る。エージェント１０４が実行されると、実行する必要がある新しいワークフロー（その特定のエンドユーザを適用範囲とする）をポーリングする。エージェント１０４が実行のためにそのようなワークフローを識別すると、ワークフローは、エンドユーザ計算基盤１１０上でワークフローを実行するワークフローエンジン１０８に渡される。

[0026] 本発明の種々の実施形態によれば、エージェント１０４は、追加の技法、例えば長寿命の接続、ウェブサーバとしてのエージェントの実行及び当業者に既知の他のメッセージ交換技法を利用して、本明細書では「ポーリング」とも呼ばれる、実行を必要とするワークフローを識別し得る。例えば、本明細書で使用される「ポーリング」の範囲に入る別の技法は、所定のエージェント１０４とのリアルタイムデータ転送を促進する、ＨＴＴＰポーリングなど、半二重代替よりも低いオーバーヘッドでのエージェント１０４とリモートワークフロー基盤との間の対話を可能にする１つ又は複数のウェブソケットのデプロイである。本明細書で使用される「ポーリング」の範囲に入るものとして、エージェントとのデータ転送を可能にする他の技法も当業者は認識する。

[0027] 特定の実施形態によれば、ワークフロー状態を調べて、完了したワークフローを識別し、特定のワークフローの実行中に作成された任意の動的基盤を除去することを担当する、リソースマネージャと呼ばれる任意選択的なサイドプロセスがエージェントで実行している。リソースマネージャは、エンドユーザ計算基盤がワークフロー基盤で過剰実行されないようにする追加のセキュリティステップである。

[0028] ワークフローアドミニストレータエージェント１０４に加えて、本実施形態によるローカルワークフロー基盤１０２は、ワークフロープログラムコード、例えばバイナリ、従属性等を保持するワークフローレジストリ１０６を含む。ワークフローレジストリ１０６は、エンドユーザ計算基盤１１０へのデプロイについて、エンドユーザがビルドしているワークフローの保持に適した任意の形態のデータストア、例えばDockerレジストリ、NoSQLデータベース、リレーショナルデータベースシステム、オブジェクト指向データベースシステム、オブジェクト－リレーショナルハイブリッドデータベース又は当業者に既知の他の適したデータストアであり得る。実際に、ワークフローレジストリは、ファイル、バイナリラージオブジェクト（「ＢＬＯＢ」）又は任意のデジタルコンテンツを記憶するように動作可能であるか又はそれが可能な任意のファイルシステムを含み得る。ワークフローレジストリのデプロイに使用することができる技術の具体例には、限定されないが、DockerHub、Google Container Registry等がある。

[0029] 最後に、ワークフローエンジン１０８は、ワークフローアドミニストレータエージェント１０４によって実行が命令された所定のワークフローを実行するプラットフォームを要求する。ワークフローエンジン１０８が所定のワークフローを実行し得る例示的なプラットフォームには、限定されないが、Kubernetes、Yarn、Mesos等がある。

[0030] 特定の実施形態では、ワークフローは、ストレージ（ワークフロープログラムコード及び必要とされるデータが記憶される）及び実行環境（ワークフローを実行する方法の説明）を含む追加の情報項目をメタデータとして含む。ワークフローアドミニストレータエージェント１０４は、それらのメタデータを使用して、ワークフローレジストリ１０６からワークフロープログラムコードを取得し、エンドユーザ計算基盤でそれを実行するようにワークフローエンジン１０８に命令する。

[0031] エンドユーザは、リモートワークフロー基盤１１２とのネットワーク１２０を経由して、ワークフローアドミニストレータエージェント１０４がそれ自体を認証できるようにする許可トークン（図示せず）を提供する。ポーリングのプロセス及びメタデータの交換を通して、ワークフローアドミニストレータ１１６及びワークフローアドミニストレータエージェント１０４は、ＡＰＩサーバ１１８及びネットワーク１２０を介して、エンドユーザ計算基盤１１０と決して「話し合う」ことなく、そのような基盤にワークフローエンジン１０８をデプロイし、実行することが可能である。したがって、１つ又は複数のローカルワークフローのリモート実行を依然として可能にしながら、ネットワーク境界のセキュリティ又は整合性が損なわれないままである。

[0032] このアーキテクチャ配置は、エンドユーザが自らの計算基盤を管理できるようにし、それによりエンドユーザのプロセスのセキュリティを更に維持できるようにし、恐らくより重要なことに、既に実施されて、顧客によって調べられた任意のセキュリティプロトコル及びプロセスの使用を維持できるようにする。更に、ユーザによって記述された「結果ハンドラ」を使用して、タスクの出力をプライベートロケーションに記憶することができ、そのようなデータの取得に必要なメタデータのみがワークフローアドミニストレータに通信される（例えば、ロケーションのＵＲＩ）。

ワークフロービルド及びデプロイ
[0033] 図２は、エンドユーザによってビルドされたワークフローをデプロイする方法論の一実施形態を示す。ワークフロービルドの例示的な方法論は、エンドユーザが新しいワークフローを記述するか、又はエンドユーザ計算基盤への再デプロイに向けて既存のワークフローを改変すること（ステップ２０２）で開始される。ステップ２０２は、エンドユーザが、所望のタスクセットを実行するワークフローを記述することを含み、これについては、本明細書に提示される使用事例において更に詳細に説明する。例示的なＥＴＬワークフローでは、エンドユーザは、将来の解析に向けて情報をフェッチして記憶しようとし、これは、複数のソースからのデータのプル、クリーニング及びマージを必要とし得る。本発明の実施形態によるワークフローは、抽出、変換及びロード動作を行うとき、エンドユーザが、所定のタスクの範囲又は所定のタスクへの入力を更に定義するための入力パラメータの使用を含めて、ワークフロー内のタスク間の従属性を任意に定義できるようにする。したがって、エンドユーザは、所定のワークフローを定義するとき、固定された直線のパイプラインにロックされることはなく、むしろ例えば以下の表１に記載のような柔軟性を有する。

新しいワークフロー又は既存のワークフローの改変が完了すると、エンドユーザは、ワークフローをローカルワークフローレジストリにデプロイし（ステップ２０４）、ローカルワークフローレジストリは、ローカルワークフロー基盤の一部であり、典型的にはエンドユーザの制御下にある。

[0034] チェックが実行されて、ワークフローレジストリへのワークフローのデプロイが成功したか否かを判断する（ステップ２０６）。チェックにより、ワークフローレジストリへのワークフローのデプロイが失敗したと判断される場合、システムは、エラー状態を報告するエラーをエンドユーザに投げ、ワークフローのデプロイを中断する（ステップ２０８）。この時点で、プログラムフローは、終了するか又はステップ２０２に戻り得、エンドユーザは、ワークフローにおけるエラーを修正する（ステップ２０２）か、又はワークフローレジストリへのワークフローの再送信を試みる（ステップ２０４）。

[0035] ワークフロー、例えば実際のプログラムコード、バイナリ、従属性等の送信がワークフローレジストリに問題なく記憶される（ステップ２０６）と、ワークフローアドミニストレータエージェントは、所定のワークフローのメタデータ、例えばワークフローの構造、ワークフローがローカルワークフロー基盤に記憶された場所及びワークフローを適宜実行する様式を記述するデータをワークフローデータベースにデプロイしようとする（ステップ２１０）。ステップ２０１６と同様に、チェックが実行されて、ワークフローデータベースへのワークフローのデプロイが成功したか否かを判断する（ステップ２１２）。チェックにより、ワークフローデータベースへのワークフローのデプロイが失敗したと判断される場合、システムは、エラー状態を報告するエラーをエンドユーザに投げ、ワークフローのデプロイを中断する（ステップ２０８）。メタデータがワークフローデータベースに問題なく送信された場合、デプロイは、完了し、ワークフローエージェント及びワークフローエンジンは、ワークフローアドミニストレータからのワークフローを実行する命令を待つ（ステップ２１４）。

ワークフロー実行
[0036] ワークフロー実行は、図３が示す例示的なプログラムフロー実行に記載されるように、リモートワークフロー基盤で実行中のワークフローアドミニストレータが、実行するワークフローを識別することで開始し得る（ステップ３０４）。図３の実施形態によれば、ワークフローメタデータは、ワークフローが実行されるスケジュールを識別し得る。ワークフローがスケジュールを有する場合、ワークフローアドミニストレータは、そのスケジュールに従って新しいワークフロー実行を自動的に作成することができる。スケジューリングは、新しいワークフロー実行を生成する好都合な方法にすぎず、エンドユーザは、自動スケジューリングされたワークフロー実行と並行してアドホック実行を依然として作成することができる（それらが同じ開始時間を有する場合でも）。唯一の違いは、自動スケジュールされた実行が、特定の実施形態に従って設定される「auto_scheduled=True」フラグを有し得ることである。

[0037] ワークフローアドミニストレータは、実行準備ができたものとしてワークフローをマークし得、これは、ワークフローアドミニストレータがワークフローをキューに入れることを含み得る。ローカルワークフロー基盤におけるエージェントは、実行に利用可能なワークフローを示す信号を受信するまで、ワークフローアドミニストレータエージェントとワークフローアドミニストレータとの間に通信経路を形成するＡＰＩサーバにより、ワークフローアドミニストレータを定期的にポーリングする（ステップ３０６）。ワークフローアドミニストレータエージェントが、実行に利用可能なワークフローをピックアップする準備ができた場合、ワークフローアドミニストレータは、ワークフローストレージ及び環境情報をワークフローエンジンに送信する（ステップ３０８）。ワークフローストレージ及び環境情報の送信は、ワークフローエンジンとのインターフェースに先立つワークフローアドミニストレータエージェントによるそのような情報の受信を含み得る。

[0038] エージェントは、１つ又は複数のワークフローのローカル実行を指揮する、ローカルワークフロー基盤で実行される小さいプロセスであり、ワークフローエンジンがインストールされる任意の環境で実行するように動作可能である。エージェントは、本明細書全体を通して説明されるワークフロー実行へのハイブリッド手法の実施を促進し、これは、ワークフロー実行がローカルワークフロー基盤、例えば顧客基盤内部に常駐し、リモートワークフロー基盤にのみ要求を送出することを意味する。本発明の全ての構成要素は、通信パラダイムに従う。

[0039] エージェントは、任意選択的に、ヘルスチェックサービスとして使用するためにプライベートＨＴＴＰサーバを実行することができる。ヘルスチェックは、一般的な指揮サービス、例えばスーパーバイザード（supervisord）、docker、kubernetes等で使用でき、所定のエージェントが正常に動作していることをチェックし、動作していない場合はアクション（エージェントの再起動等）を実行する。イネーブルの場合、実施形態は、そのＨＴＴＰヘルスチェックデータを、構成されたエージェントアドレスで特定のパスを介して利用できるようにすることを提供する。このルートは、エージェントが実行されていて正常であれば、所定の値、例えば２００ ＯＫを返し、他の場合、ＨＴＴＰサーバは、エラーを返す。

[0040] 現在のワークフローの実行を完了するために追加の基盤が必要であるか否かを判断するために、ローカルワークフロー基盤でチェックが実行される（ステップ３１０）。ステップ３１０におけるチェックが真であると評価される場合、プログラムフローは、ステップ３１２に向けられ、ワークフローアドミニストレータエージェントの制御下で動作し得るワークフローエンジンは、実行中のワークフローの適切な完了のために必要な追加の基盤をローカルワークフロー基盤においてインスタンス化する。

[0041] ステップ３１０において実行された評価の出力にかかわらず、プログラムフローは、最終的に、ワークフローアドミニストレータエージェントが、メタデータにおいて識別される指示に従ってワークフローレジストリからワークフローコード及び関連するリソースをプルするように、ワークフローエンジンに指示するポイントに進む（ステップ３１４）。ワークフローエンジンが、ワークフロープログラムコード及びワークフローが従属する任意の要求されたリソースにアクセスすると、ワークフローエンジンは、ワークフローを実行する（ステップ３１６）。

[0042] 特定の実施形態によれば、ワークフロー実行（ステップ３１６）は、スケジュールに従って行われる。そのような実施形態では、スケジューラ情報は、所定のワークフローを実行するタイミング情報を識別する、所定のワークフローに関連付けられたメタデータとしてリモート基盤に送信することができる。当業者によって認識されるように、スケジューリングは、特定の時間にワークフローの実行を自動化するのに有用である。スケジュールは、簡単なスケジュールであり得るか、又は複雑なマルチ構成要素スケジュールであり得る。一実施形態による複雑なスケジュールは、クロック（特定の時間又は時間間隔としてワークフロー実行イベントを出す）、フィルタ（実行時、ワークフローを含めるべきか否かを決める、例えばon_date、on_datetime、at_time等）及び調整（フィルタを通過したワークフローに改変を行う、例えば時間間隔の追加、翌日又は将来の曜日への前進等）を定義する。これらの３つの構成要素は、ユーザが簡単な機能を複雑な挙動と組み合わせられるようにする。１つ又は複数のワークフローの実行スケジュールの調整へのスケジュールメタデータの使用について、図５に関連して更に詳細に説明する。

[0043] ワークフローの実行中、現在実行中のタスクからの任意のデータが記憶を必要とするか否かを判断するために、チェックが実行される（ステップ３１８）。タスクデータを記憶する必要がある場合、例えば１つ又は複数の下流プロセスによってタスクの出力が信頼され得るように、タスクの出力がある程度の永続性を必要とする場合、エンドユーザがワークフローの一環としてプログラムするカスタム結果ハンドラに従ってデータは記憶され得る（ステップ３２０）。任意のタスクデータが記憶を必要とするか否かにかかわらず、ワークフローエンジンは、状態変更情報をワークフローデータベースに記憶するために、メタデータとしてワークフローアドミニストレータに送信し（ステップ３２２）、メタデータが記述する実質的なデータは、ワークフローレジストリに記憶されるか、又はローカルワークフロー基盤の一部として別の方法で記憶される。

[0044] データの扱いに関して、本発明の種々の実施形態と併せて本明細書に記載されるハイブリッド実行モデルは、コード及びデータの両方の顧客制御を可能にし、いずれも顧客の内部エコシステムから出ないことを保証する。本明細書で参照されるデータは、所定のワークフローを構成するタスクからの１つ又は複数の入力及び／又は出力を指す。本明細書に記載のように、全てのワークフロー実行は、顧客ネットワークの整合性を維持しながら、例えば顧客の制御下にあるネットワーク及び計算リソースを使用して顧客基盤内で行われる。

[0045] データ永続性は、ワークフロー単位で伝達され得る。上記への代替として又は上記と併せて、データ永続性は、所定のワークフロー内でタスクごとに伝達され得る。いずれにせよ、ワークフローが後でデータを書き込む必要があるときに永続性が生じる。これは、例えば、タスク再試行（結果メソッドが再試行タスクへの１つ又は複数の上流入力で呼び出される）、タスクキュー（再試行と均等であるが、タスクが同時実行数の制限に達すると生じる）、タスクキャッシュ（タスクが、それ自体の結果をキャッシュするように設定される場合）と併せて生じ得る。特定のタスクによる永続性のためにデータ書き込みの呼び出しを含む全てのワークフロー実行は、顧客基盤で行われ、顧客コードは、リモート又はクラウド基盤で実行されない。

[0046] 任意の出力データの記憶及びその出力データに関する任意の記述を含む任意のメタデータの送信に続けて、ワークフローが完了したか否かを判断するためにチェックが実行される（ステップ３２４）。ワークフローが完了していない場合、例えばワークフローが定義し、完了する必要がある追加のタスク又は追加の処理がある場合、プログラムフローは、ステップ３１６に戻り、ワークフローエンジンは、ワークフローの実行、例えばワークフローが定義する次のタスクの実行を継続する。代替的に、処理は、完了し、ルーチンは、終了する（ステップ３０２）。

ワークフロー実行
[0047] 図４は、エンドユーザ計算基盤でワークフローエンジンによって実行中のワークフローをモニタし、対話する方法の一実施形態を示す流れ図を提示する。図４の方法論によれば、ワークフローは、ローカルワークフロー基盤におけるワークフローエンジンで実行中である（ステップ４０２）。ワークフローエンジンは、所定のワークフローを実行すると、ワークフローの処理が状態変更に繋がったか否かを判断するためのチェックを実行する（ステップ４０４）。同様に、特定の実施形態によれば場合により並行して、ワークフローエンジンは、現在実行中のタスクが、例えば、エンドユーザ計算基盤上の別のロケーションにあるワークフローレジストリへの記憶を必要とするか否かを判断するためのチェックを実行する（ステップ４０６）。

[0048] いずれかの状態変更があるとワークフローエンジンが判断する場合（ステップ４０４）又はワークフローが出力データを記憶していると判断する場合（ステップ４０６）、ワークフローエンジンは、イベントを記述するメタデータを生成する。ワークフローマネージャは、ワークフローに関連付けられた更新されたメタデータとしてワークフローデータベースに記憶するメタデータ、及び場合により特定のタスクを受信する（ステップ４０８）。このステップ４０８は、破線で結ばれたステップ４０４、４０６及び４０８で示されるように、方法の残りのステップと共にプロセス外で行われる。

[0049] 一実施形態によれば、ワークフローデータベース内のデータは、それに含まれるメタデータを問い合わせるために、完全なGraphQL ＡＰＩとして公開される。ワークフローデータベース内の全てのデータは、GraphQLを介して問い合わせ得る。したがって、更新されたメタデータは、エンドユーザの問合せ及び取得に利用可能になる（ステップ４１０）。例えば、以下の表２に示されるクエリは、アルファベット順に並べられた、「flow」で終わる名称の全てのワークフロー、それらの最新のワークフロー実行の状態及びその実行のタスク実行の５つの状態履歴を取得する。

[0050] ステップ４０４及び４０６で、データ更新を判断するためのチェックを実行した後、ステップ４１２で、状態変更が許容されたか否か又はそのような変更がエラー状態を生じさせたか否かを判断するための別のチェックを実行する（）。状態変更が許容されない場合、ワークフローは、エラー状態になり、それによりワークフローを終了させ、ワークフローエンジンは、ワークフローの実行をサポートするためにインスタンス化された任意のワークフロー固有の基盤を解体させる（ステップ４１６）。状態変更更新が許容され、ワークフローがエラー状態にならない場合、ワークフローが終了状態であるか否か、例えばワークフローが識別する全てのタスクが完了したか否かを判断するためのチェックが実行される（ステップ４１４）。ワークフローが終了状態である場合、ワークフローエンジンは、ワークフローの実行をサポートするためにインスタンス化された任意のワークフロー固有の基盤を解体する（ステップ４１６）。状態変更が許容され（ステップ４１２）、及びワークフローが終了状態ではない場合、プログラムフローは、ステップ４０２に戻り、ワークフローは、ローカルワークフロー基盤におけるワークフローエンジンで引き続き実行される。

メタデータ
[0051] 本明細書に記載のように、メタデータは、抽象化を提供して、ローカルワークフロー基盤において定義される１つ又は複数の特定のワークフローの記述を可能し、それにより、プライベート顧客データ又は基盤の詳細を知ることなく、リモート実行及び状態維持を可能にする。より具体的には、プログラム的にワークフローオブジェクトを囲むメタデータは、顧客基盤外への通信を決して必要とすることなく、エンドユーザワークフロー（状態、ステータス等を定義する）の指揮を可能にする点でハイブリッド実行モデルにとって極めて重要である。これは、例えば、一連の巧みに作られたポーリング動作を通して行うことができ、それにより、所定のワークフローは、例えば、ワークフローを構成する１つ又は複数の他のタスクの状態に基づいて、ワークフローを進める様式に関する情報のために、ＡＰＩサーバを介してワークフローアドミニストレータとの通信を開始する。

[0052] 限定されないが、タスク及びエッジを通したワークフロー構造、状態情報、ワークフローストレージ及び実行ステップ等の態様を含む種々のタイプの利用可能なメタデータは、ワークフローの異種の態様を記述するのに有用である。状態情報は、ワークフローアドミニストレータが、エンドユーザ計算基盤で行われているフローを安全にリモートで指揮できるようにするメタデータの特定の項目である。例えば、ワークフローがタスクを完了する場合、ワークフローアドミニストレータエージェントは、ＡＰＩサーバを介してこの状態メタデータをワークフローマネージャに通信する。同様に、所定のワークフロー内の任意の下流タスクが開始される場合、各下流タスクは、ＡＰＩサーバに問い合わせて、それ以上の処理への前提条件である任意の計算又は出力のステータスについて調べ得、すなわち所定のタスクが従属する任意のタスクが問題なく完成する状態である。状態情報を報告し、問い合わせるこのプロセスにより、動的タスク実行、ワークフロー並列実行、手法介入、デッドロック回避及び当業者に明らかな他の計算恩恵等の特徴が可能になる。

[0053] 図５は、本発明の一実施形態によるワークフロー実行をハイブリッドデプロイするシステムの代替の実装形態を示す。図１の実施形態のように、図５の実施形態は、内部オンプレミスワークフロー管理解決策のセキュリティをもってクラウドプラットフォームの利便性を提供する。図５が示す通信フローによれば、クラウド基盤５０２は、ＡＰＩ５０８を介して顧客基盤５０４から要求をメタデータ５０６として受信する。クラウド基盤においてメタデータ５１０の豊富なセットを有することにより、基礎をなすコード又はリソースに関する任意の知識を保有せずに、ワークフローの指揮が可能になる。表３は、例示的なワークフローを実施するための本発明の一実施形態による例示的な疑似コードを提示する。

[0054] 表３からの上記の定義された疑似コードによって示されるように、ワークフロー５１２ａ及び５１２ｂは、Ｎまでの数のリストを生成し、その数の２倍をマッピングして１を各々に加算し、数のリストを最終合算にまとめ、次いで合算をログする。ワークフローに含まれる２つの主要情報は、属性「ストレージ」及び「環境」である。ストレージは、開発者がワークフロー５１２ａ及び５１２ｂの実際のビジネス論理５１４を記憶する場所を指定する。これは、Docker（www.docker.com）レジストリからＳ３オブジェクトストレージ（aws.amazon.com/s3）、ローカル又はリモートファイルシステム等までを範囲とすることができる。本例によれば、システムは、Dockerを使用して、ワークフローを構成する実際のビジネス論理を記憶している。ファイル、ＢＬＯＢ又は任意のデジタルコンテンツを記憶するように動作可能であるか又はそれが可能である任意のファイルシステムが、本発明の種々の実施形態の範囲内に入ることが意図されることを当業者は認識する。環境は、開発者がワークフローをどのように実行することを望むか、及びワークフローがいずれの基盤ニーズを有し得るかを指定する方法である。この例では、開発者は、ワークフローの実行に静的Daskを利用している。

[0055] 開発者は、ワークフロー５１２ａ及び５１２ｂを定義すると、ワークフロー５１２ａ及び５１２ｂをクラウド基盤５０２に登録しなければならず、これは、本明細書で広く説明されるハイブリッド通信を含む。したがって、ワークフロー５１２ａ及び５１２ｂを構成する実際のビジネス論理５１４のいずれもクラウド基盤に送信されず、代わりにワークフローの構造を表すメタデータのみがそれらの間で交換される。表３のワークフローにおいて識別されたDockerストレージは、実際のワークフローコアの保持を担当する一方、メタデータは、クラウド基盤に送信される。クラウド基盤においてメタデータを受信すると、システムは、ワークフローを登録し得、ワークフローが属するプロジェクトを指定し得る。メタデータは、所定のワークフローに関してクラウド基盤が受信する唯一の情報であり、ワークフローの一般構造及びシステムがワークフローを記憶する場所に関する情報を含む。ワークフローが記憶されるロケーションを知ることは、クラウド基盤がワークフローの内容について知ることもなければ、そのようなコード及びデータにアクセスする許可も有さないことを意味する。

[0056] ワークフローをクラウド基盤５０２に登録すると、顧客基盤５０４は、１つ又は複数のエージェント５１６をインスタンス化し、これは、顧客又はその開発者が選択する任意のプラットフォームでのインスタンス化を含み得る。例えば、顧客は、Kubernetesエージェントとしてエージェント５１６をデプロイすることを選択し得、これは、Kubernetes ＡＰＩサーバと直接対話して、ワークフローをジョブとしてKubernetesクラスタで実行するように設計されたエージェントである。他のエージェントプラットフォーム、例えばAWS Fargateクラスタも本発明の種々の実施形態の範囲内にあり、開発者がオーサリングしているワークフローの特定のニーズに基づいて相互交換可能であることが意図される。

[0057] 所定のエージェント５１６は、ＡＰＩ５０８を介してクラウド基盤５０２をポーリングして、クラウド基盤５０２の一部として又はクラウド基盤５０２にリモートに配置され得るスケジューラ５１８構成要素によって識別され得る、実行のためにスケジュールされた、メタデータデータストア５１０に記述されたワークフローを識別することを担当する。これは、本発明の実施形態が満たすように設計された一要件を満たす：顧客が所有し、運営する基盤５０４内部の顧客ワークフローを指揮することが可能であること。ハードルは、クラウド基盤５０２がユーザ基盤５０４に決して全く話しかけず、代わりに顧客基盤５０４がＡＰＩ５０８を介して作業要求を開始することによって完全に除去される。作業が発見されると、エージェント５１６は、ワークフローを、選択されたそれに関連するプラットフォームで実行する。一実施形態によれば、エージェント５１６は、ＡＰＩ５０８を介してスケジューラ５１８を定期的にポーリングして、実行がスケジュールされた任意のワークフローを識別する。スケジューラ５１８が利用されない場合、所定のワークフローは、ユーザインターフェース５２０を通してクラウド基盤に、コマンドラインインターフェース５２２を通してクラウド基盤に所定のワークフローを実行するためのコマンドを発行することにより、又はプログラム的にＡＰＩ５０８に要求５２４を直接送信することにより、顧客基盤５０４で実行することができる。

[0058] エージェント５１６は、ＡＰＩ５０８を介してスケジューラ５１８に問い合わせて、ワークフローがワークフローエンジン５２６による実行のためにスケジュールされていると判断し、これは、一実施形態によれば、メタデータデータストアに記憶されたワークフローのメタデータを「スケジュール済み」状態にすることによって通信される。エージェント５１６が、ワークフローエンジン５２６により実行されるワークフローをピックアップすると、エージェントは、ワークフロー状態を「提出済み」に更新し、これも、メタデータデータストア５１０に記憶するためにクラウド基盤に送信される。これは、１つのみのエージェント５１６が利用可能なワークフロー５１２ａ及び５１２ｂを実行に選択することを保証するのに役立つ。一実施形態によれば、エージェント５１５は、現在のワークフローの実行を開始しながら、実行が必要なワークフローを探してスケジューラ５１８を引き続きポーリングする。

[0059] ワークフローが、ワークフロー５１２ａ及び５１２ｂにおいて指定された環境を使用してワークフローエンジン５２６において実行中であると、エージェント５１５は、メタデータデータストア５１０に記憶するために、ＡＰＩ５０８を介して状態更新をクラウド基盤に通信し始める。所定のワークフローの例示的なタスク状態パイプラインは、以下のように見える：保留中→実行中→成功。以下の表４は、一実施形態によれば、メタデータデータストア５１０に記憶するためにクラウド基盤５０２に送信される例示的なメタデータ状態オブジェクトを提示する。

[0060] 表４の例示的なメタデータ等の状態メタデータは、限定されないが、冪等性の保証、ステータスの報告、視覚化の構築、解析の提供等を含む幾つかの目的で使用することができる。ワークフローの実行が完了すると、ワークフローは、ワークフローエンジン５２６を介してその最終状態をクラウド基盤に報告し、それにより「完了済み」のステータスが入力されることになり得る。したがって、本発明の実施形態は、クラウド基盤を利用して、クラウド基盤が決して顧客基盤に達することなく又はワークフローの内容について知ることなく、顧客基盤内部のワークフローの実行を指揮する能力を顧客に提供する。

一般ワークフロー使用事例
[0061] 本明細書に開示されるシステム及び方法で構築される大半の使用事例のように、プロセスは、典型的には、ワークフローインスタンス化で開始される。例えば、基盤の顧客環境内で作業している開発者が、リモートＡＰＩ、例えば図１からのＡＰＩサーバ１１８によって提供されるＡＰＩを介して指揮することを望む２つのタスク（「タスクＡ」及び「タスクＢ）を有すると考える。第１のタスクであるタスクＡが、第２のタスクであるタスクＢが所望の結果を達成するために、プライベートデータを第２のタスクに提供すると更に考え、所望の結果は、ワークフロー実行の所望の結果である、顧客環境内の任意の結果であり得る。これらのタスクを定義するコードを記述した後、ユーザは、ＡＰＩに固有の幾つかの追加の構成を構成又は他に識別する必要がある：
・タスクＡの処理要件を所与として、タスクＡがデータを記憶すべき場所を指定する「結果」構成；そのような中間記憶ロケーションの例には、限定されないが、クラウドストレージ、顧客環境内のローカル記憶装置等があり得る。重要なことに、この記憶ロケーションの識別は、完全に開発者の裁量及び制御内であり、例えば、開発者は、そのような過渡的データ又は中間データが顧客環境から決して出ないことを保証することができる。
・ワークフローの「ストレージ」構成；結果構成と同様に、これは、開発者が、実際に、ワークフロー及びそれに関連付けられたプロセスを含むステップを定義するコードを保存し得るロケーションである。結果構成と同じように、このロケーションも完全に開発者の制御及び裁量内にあり、そのようなロケーションは、ＡＰＩサービスにより直接アクセスされる必要がない。
この構成を実施した状態で、開発者は、ここで、ＡＰＩコールを通してこのワークフローの存在をリモートＡＰＩに「登録」する。この登録ステップは、適切なアクセスを有するユーザがワークフロー構成及びコードを取得できるようにするのに十分なメタデータをＡＰＩに送信する。例えば、開発者がワークフロー構成をDockerレジストリ内に記憶する場合、登録ステップは、画像名、タグ及びレジストリＵＲＬを識別するＡＰＩメタデータのみを送信する。ＡＰＩは、メタデータを受信し、実行へのその可用性を登録する。

[0062] ここで、ワークフローは、存在することが知られ、実行のためにスケジュールすることができる。所定のワークフローを適宜実行するために、開発者は、リモートＡＰＩ並びにワークフローの構成及びインスタンス化中、開発者によって識別された結果及び記憶ロケーションの両方にアクセスすることができる「エージェント」プロセスをクライアント環境内でインスタンス化する必要がある。顧客は、このプロセスを顧客基盤内で実行し、任意の許容できるリスクレベルに従ってアクセス制御を構成することができる。エージェントは、リモートＡＰＩをポーリングして、スケジュールされた作業を知るように動作可能であり、スケジュールされた作業は、発見されると、そのワークフローを実行するためのコードを見つけることができる場所をエージェントに指示する、上述したメタデータをＡＰＩに提供させる。このデータが提供されて、エージェントは、コードにアクセスし、顧客基盤内で実行するためにコードを提出する。他の実施形態と同様に、リモートＡＰＩは、顧客基盤にアクセスする必要がなく、代わりに、エージェントは、ＡＰＩと顧客のプライベート基盤との間のセキュアな内部仲介者として機能することに留意されたい。

[0063] コードは、実行されるにつれて、ステータス更新をＡＰＩに報告し得る（例えば、「依然として実行中」、「問題なく終了しなかった」等）。本使用事例によれば、タスクＡが完了し、プライベートデータを生成した場合、結果構成は、そのデータを顧客基盤内に記憶し、ＡＰＩにロケーションを通知し、ロケーションは、特定の実施形態によれば、単にファイル名であり得るが、複雑なロケーション識別子も本発明の実施形態の範囲内に入るものと意図される。ストレージと同様に、極めて重要な態様は、結果構成が、適切なアクセス資格を有する開発者がデータを取得することができるのに十分な情報を提供することである。データは、次いで、タスクＢに提供され、タスクＢは、Ａと同様に実行される。タスクＢは、失敗するか又は将来に再実行される場合、開発者の制御内で許可された環境で実行中であるとき、タスクＡが生成したデータを適切なロケーションからプルすることができる。したがって、リモートＡＰＩは、ここで、本明細書に提供されるワークフロー実行サービスを利用して、全て顧客のプライベート基盤に実際にアクセスする必要なく、タスクＡ及びタスクＢの実行の記録と、いずれかのタスクの実行中に生じた任意の関連する問題とを有する。構成の他に、本発明の種々の実施形態によるワークフロー自動化を可能にするために顧客基盤に課される唯一の要件は、顧客基盤がＡＰＩをホストするロケーション及び関連するリソースと外部通信するように動作可能であるか又は他にそうすることが可能であることである。

具体的なワークフロー使用事例
[0064] 上記の本開示の一応用である一実施形態を示す具体的な使用事例として、顧客又は他のエンドユーザが、毎晩午前０時に実行される任意のワークフローを自動化することを望むと仮定する。例示的なワークフローは、データをサイトからダウンロードし、そのデータを処理し、次いで、処理されたデータを、顧客によって運営又は他に制御される基盤に常駐するリレーショナルデータベース内のテーブルの行中に挿入する。

[0065] 顧客は、まず、エンドユーザ計算基盤でのワークフローのオーサリング及び実行を提供する、必要な構成要素をローカルワークフロー基盤にインストールする。エンドユーザは、これらの構成要素を利用して、３つの「タスク」を含むワークフロー又は「フロー」オブジェクトをプログラム的に構築し、そこで、ユーザは、ワークフローエンジンによって実行されるとき、タスクの挙動を記述するカスタム「実行」機能を提供する。例示的なワークフローでは、３つのタスクは、データをダウンロードし、ダウンロードされたデータを処理し、処理されたデータを挿入する「実行」機能又はビジネス論理をそれぞれ有する。以下は、記述するタスクを可能な限り簡単にする幾つかの好都合なメソッドを使用して、この例示的なワークフローが疑似コードでどのように見えるかである。

各タスクが何らかの他の関数（ここでは定義されない）を呼び出していることが認識される。ユーザは、任意のビジネス論理をタスク内部に配置することができ、ワークフローエンジンは、プログラムコードが予期する入力及びプログラムコードが返す出力が何であるかについての幾つかの簡単なコントラクトを満たす限り、アグノスティックである。

[0066] ワークフローアドミニストレータがワークフローの最後で関数を呼び出す場合（「フロー」ブロックにおいて）、アプリケーションは、関数を実際には実行しておらず、むしろ、本明細書に記載のように、実際にはワークフローエンジンの制御下で顧客計算基盤において実行している。代わりに、ワークフローマネージャは、呼び出しを観測し、計算グラフを構築し得る。例えば、最初の呼び出し（「downloaded=download_data()」）後、ワークフローマネージャは、「download」タスクがワークフローの一部であることを知る。２行目において、プログラムコードは、そのタスクを別のタスク（「process_data」）に渡し、ワークフローアドミニストレータは、それらの２つのタスクが計算グラフにおいて結ばれていること及びデータがそれらの間でどのように移動するかを知る。

[0067] ワークフローをリモートワークフロー基盤で実行する場合、特定の本実施形態では、幾つかのイベントが自動的に生じる：
・顧客が以前に構築したワークフローを含むDockerコンテナが構築され、それにより、ワークフローマネージャは、この厳密なスクリプトをインスタンス化し、ワークフローエンジンにワークフローを将来実行するように命令することができる。
・コンテナは、顧客によって制御されるDockerレジストリに記憶される。このスクリプトは、リモート又はクラウドワークフロー基盤ではなく、顧客又はローカルワークフロー基盤で実行されるため、これは、ワークフロープログラムコードが第三者に行くか又は他に顧客制御から出ることが決してないことを意味する。
・コードではなく、計算グラフを記述するＪＳＯＮドキュメントが生成され、ワークフローデータベースに記憶するためにリモート又はクラウドワークフロー基盤に送信される。このドキュメントから、ワークフローアドミニストレータは、ワークフロー及び全ての構成タスクを「ダミー」形態で再構築することができる － これらのダミーワークフローは、同じ名称、ＩＤ、スケジュール、接続等を有するが、極めて重要なrun()関数を有さない。

[0068] このハイブリッドアーキテクチャに従って実行される後続ステップは、ワークフローを実行する環境の作成である。一実施形態によれば、ローカルワークフロー基盤は、先に構築されたコンテナをデプロイ可能な実行クラスタをホストする。そのクラスタにワークフローアドミニストレータエージェントがインストールされ、ワークフローアドミニストレータエージェントは、ＡＰＩサーバを介してワークフローアドミニストレータを常にポーリングして、任意のワークフローを実行すべきであるか否かを調べる。エージェントは、実行するワークフローを見つけた場合、認証トークンが提供された適切なコンテナを開始し、したがって、コンテナは、その進行をワークフローアドミニストレータに通信することができる。

[0069] 顧客の視点から、ここで、以下が可能である。
１）顧客は、ワークフローアドミニストレータにログインして、（とりわけ）利用可能なワークフロー及びその実行履歴を見、そのようなデータは、ＧＵＩを介して顧客に提供される。
２）顧客によって最初に構築されたワークフローは、ワークフローアドミニストレータにナビゲートすることができ、ワークフローアドミニストレータにそのワークフロー又は他のワークフローを実行するように命令することができる。
３）ワークフローアドミニストレータは、ダミーワークフローを「スケジュール済み」状態にし、これは、エージェントがモニタしているイベントである。エージェントがスケジュール済みワークフローを見ると、ワークフローエンジンは、コードを開始し、ＡＰＩサーバを介して進行をワークフローアドミニストレータに通信し、エンドユーザが３つのタスクが作成され、実行され、（望ましくは）成功状態で終了できるようにする。

[0070] エージェントは、コンテナをデプロイする場合、単にワークフローエンジンをローカルワークフロー基盤で実行しており、ワークフローエンジンが最新タスク状態情報をワークフローアドミニストレータから取得し、それらの状態への任意の変更を報告するように接続をオンにする。これは、ワークフローエンジンを単独で使用するよりも優れた幾つかの利点を提供する。例えば、タスクの１つが失敗し、再試行する必要があることを考える。失敗したタスクは、所望の開始時間を有する「再試行」状態になる。ワークフローマネージャ及びエージェントは、その状態の時間が過ぎたときを検出し、そのタスクの再試行状態を含む最新の情報を用いてワークフローエンジンを自動的に始め得る。ワークフローエンジンは、次いで、提供された更新された状態情報を所与として、タスクを適宜扱い得る。

[0071] リモートワークフロー基盤なしでこの挙動を模倣することは、可能であるが、「再試行」状態を永続層に記憶し、状態を調べて開始時間を理解し、プロセスを実行してワークフローを正しい時間に適宜再開し、認証されたＡＰＩを提供して、記憶された状態情報を更新できるようにし、次いで更新された状態情報及び他の全ての状態をワークフローエンジンに提供する必要がある。このようにして、リモートワークフロー基盤は、ワークフローエンジンの単なる「管理されるバージョン」ではなく、むしろワークフローエンジンの機能及び動作を改善する構造を最終的に提供する管理的でステートフルな特徴を提供する。実際に、本明細書に記載のハイブリッドワークフロー指揮モデルは、一方では、顧客基盤の制御に密に結び付き、顧客基盤の制御内にあるデータ及びコード実行の分岐を提供し、他方では、リモートクラウド基盤に常駐する指揮、エラーサーフェシング及びモニタリングを提供することにより、当技術分野におけるニーズを満たす。

[0072] 上述した本発明の実施形態は、サービス（「ＳａａＳ」）プラットフォームとしてのソフトウェアとしてエンドユーザ及びアドミニストレータに公開され得、そのような当事者が実施形態のワークフロー自動化態様を容易にデプロイし、実行できるようにする。例えば、図６は、顧客のワークフロー管理環境についての詳細を提供する管理ダッシュボードを提示するウェブインターフェース６０２を示す。ダッシュボード６０２を通して、顧客は、プロジェクト６０４に関する全体情報（例えば、１つ又は複数のワークフロー及び関連付けられたタスク）並びに顧客基盤で動作中の前に定義されたワークフロー６０６及びエージェント６０８に関する詳細情報を見ることができる。図６の例示的なダッシュボードＵＩ６０２は、基礎となるデータソースを問い合わせるように動作可能な１つ又は複数のプログラムコードと関連付けられた幾つかの情報パネルを提示すると共に、結果情報を表示のために提示する。例えば、そのような情報パネルは、限定されないが、ゼロ以上のワークフロー実行の全体結果履歴を視覚化するＵＩ６１０、総合ワークフロー実行に関するロールアップされた要約情報６１２、任意の報告されたエラー情報６１４、将来の実行のためにスケジュールされたワークフローの識別情報６１６、一般化された活動情報６１８、任意の失敗したワークフロー実行に関する詳細６２０及び顧客がローカル又は顧客基盤でデプロイしたアクティブエージェントの識別情報６２４を含み得る。

[0073] 上述したように、図６のダッシュボードの実施形態は、顧客が、現在接続されているリモートエージェントに制限し得るゼロ以上のリモートエージェントを閲覧、対話及び管理できるようにするＵＩを提示する制御機構を含む。図７の例では、エージェントタブ７０４が選択されると、ダッシュボード７０２は、本発明の種々の実施形態と併せて説明されたソフトウェア構成要素及びデータストレージにアクセスして、ゼロ以上の定義されたエージェントに関する情報を提示し、ＵＩは、所定のエージェントの別個のパネルＵＩ要素において表示する。例示的な実施形態では、２つのパネルＵＩ要素は、第１のエージェント７１０及び第２のエージェント７１２に関する情報を提示する。ダッシュボード７０２が顧客に表示するエージェント情報は、限定されないが、エージェントが最後に実行された最後時間及び最後の実行からの経過時間に関する情報７１４、エージェントが作業中であるワークフローエンジンのバージョン情報７１６、セキュリティトークン識別情報７１８及びデータ、１つ又は複数のデータストアを見るための制御機構７２０を含む。

[0074] 図８は、リモート又はクラウド基盤に関して本明細書で説明されたＡＰＩ等のインタラクティブＡＰＩの例示的なＵＩを提示する。図８のＵＩ８０２によれば、インタラクティブＡＰＩは、クエリ構築パネル８０４及びインタラクティブ結果パネル８０６を含むスプリットパネルインターフェースを提示する。使用に当たり、データストアに対するクエリを実行することを望むユーザは、クエリビルダパネル８０４にクエリ８０８を含むプログラムコードを提供し得る。クエリビルダパネル８０４の基礎をなすプログラムコード（図示せず）は、ＡＰＩによる評価又は実行のために、クエリ８０８を含むプログラムコードをパッケージングし、クエリ８０８は、表示８１０のために、インタラクティブ結果パネルの基礎をなすプログラムコードによって受信される結果セットを返す。

[0075] ワークフロー実行の一部として、本発明の実施形態は、成功したタスク実行及びワークフロー実行から生じ得る任意の問題を追跡するログ機能を含む。図９は、ワークフロー実行イベントを詳述するログを保持するデータストアにウィンドウを提供するユーザインターフェース９０２を提示する。図９の例示的なインターフェース９０２によれば、基礎となるプログラム構成要素は、関連するデータストアに問い合わせ、結果セット９０４を視覚化し、これは、本実施形態ではタスク単位であり、タスクは、独立していても又はしていなくてもよい種々のワークフローからインタリーブされる。

[0076] 図１０は、ワークフローを構成するタスク、例えば１００４、１００６及び１００８をユーザが視覚化できるようにするワークフロー視覚化エンジンの例示的なＵＩ１００２を提示する。タスクに加えて、例示的なワークフローは、任意の２つ以上の所定のタスク間に存在する関係又は従属性１０１０も定義する。例示的なＵＩ１００２は、「実行状態」インジケータ１０１２によって示される処理中のタスクと、現在のワークフロー１０１４の実行中に経過した時間量についての表示とを示す。したがって、図１０のワークフロー視覚化インターフェース１００２は、顧客又はアドミニストレータが、顧客基盤又はローカル基盤にアクセスする必要なく、タスク及びワークフローの名称、タスク及びワークフローの状態及び従属性をメタデータから特定できるようにする。

[0077] 図１～図１０は、本発明を説明できるようにする概念図である。本発明の実施形態の種々の態様がハードウェア、ファームウェア、ソフトウェア又はそれらの組合せで実施され得ることを当業者は理解するはずである。そのような実施形態では、種々の構成要素及び／又はステップは、ハードウェア、ファームウェア及び／又はソフトウェアで実施されて、本発明の機能を実行する。すなわち、同じハードウェア、ファームウェア又はソフトウェアモジュールが、図示のブロック（例えば、構成要素又はステップ）の１つ又は複数を実行することができる。

[0078] ソフトウェア実施では、コンピュータソフトウェア（例えば、プログラム又は他の命令）及び／又はデータは、コンピュータプログラム製品の一部としての機械可読媒体に記憶され、リムーバブル記憶ドライブ、ハードドライブ又は通信インターフェースを介してコンピュータシステム又は他のデバイス若しくは機械にロードされる。コンピュータプログラム（コンピュータ制御論理又はコンピュータ可読プログラムコードとも呼ばれる）は、メインメモリ及び／又は補助メモリに記憶され、１つ又は複数のプロセッサ（コントローラ等）によって実行されて、１つ又は複数のプロセッサに、本明細書に記載される本明細書の機能を実行させる。本明細書では、「機械可読媒体」、「コンピュータプログラム媒体」及び「コンピュータ使用可能媒体」という用語は、一般に、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、リムーバブル記憶ユニット（例えば、磁気又は光ディスク、フラッシュメモリデバイス等）、ハードディスク等の媒体を指すために使用される。

[0079] とりわけ、上記の図及び例は、本発明の範囲を単一の実施形態に限定することを意図せず、記載又は図示の要素の幾つか又は全ての相互交換により他の実施形態が可能である。更に、本発明の特定の要素が、既知の構成要素を使用して部分的又は完全に実施することができる場合、本発明の理解に必要であるそのような既知の構成要素の部分のみが説明されており、そのような既知の構成要素の他の部分の詳細な説明は、本発明を曖昧にしないように省略されている。本明細書では、単数の構成要素を示す実施形態は、本明細書に明確に別記される場合を除き、複数の同じ構成要素を含む他の実施形態に必ずしも限定されない。更に、本出願人は、本明細書又は特許請求の範囲内のいかなる用語についても、そのように明確に記載される場合を除いて、一般的ではない又は特殊な意味に帰されることを意図しない。更に、本発明は、例示として本明細書で参照された既知の構成要素への現在及び将来の既知の均等物を包含する。

[0080] 特定の実施形態の上記の説明は、他者が、本発明の一般概念から逸脱することなく、過度の実験なしで、関連する技術分野の技能内の知識（引用され、参照により本明細書に援用される文献の内容を含む）を適用することにより、そのような特定の実施形態を種々の用途に向けて容易に改変及び／又は適合させることができるように本発明の一般性質を完全に明らかにしている。したがって、そのような適合形態及び改変形態は、本明細書に提示される教示及び指針に基づいて、開示された実施形態の均等物の意味及び範囲内であることが意図される。本明細書における句又は用語は、限定ではなく、説明を目的としており、したがって、本明細書の用語又は句は、当業者の知識と併せて、本明細書に提示される教示及び指針に照らして当業者によって解釈されるべきであることを理解されたい。

[0081] 本発明の種々の実施形態について上述したが、限定ではなく、例として提示されたことを理解されたい。本発明の趣旨及び範囲から逸脱することなく、形態及び詳細における種々の変更形態がなされ得ることが当業者に明らかになるであろう。したがって、本発明は、上述した例示的な実施形態の何れによっても限定されるべきではなく、むしろ以下の特許請求の範囲及びその均等物に従ってのみ規定されるべきである。

Claims (14)

1. １つ又は複数の任意に定義されたワークフローのリモート実行のためのシステムであって、
   所定のワークフローにおいて定義された１つ又は複数の機能を顧客基盤で実行するように動作可能なワークフローエンジンと、
   前記所定のワークフローの状態を記述するメタデータを保持するワークフローデータベースへのアクセスを有するワークフローアドミストレータであって、前記ワークフローエンジンからリモートであり、及び前記顧客基盤で実行していないワークフローアドミニストレータと、
   前記ワークフローアドミニストレータをポーリングして、前記所定のワークフローが、実行のためにスケジュールされている状態であるときを識別し、及び前記所定のワークフローがスケジュールされているとき、前記所定のワークフローをワークフローレジストリから取得し、前記所定のワークフローにおいて定義された前記１つ又は複数の機能を前記顧客基盤で実行するためのコマンドを前記ワークフローエンジンに発行するワークフローアドミニストレータエージェントであって、前記ワークフローデータベースに記憶するために、前記所定のワークフローの実行に関する状態情報を前記ワークフローアドミニストレータに送信するワークフローアドミニストレータエージェントと
   を含むシステム。
2. 前記ワークフローアドミニストレータに転送するために、前記ワークフローアドミニストレータエージェントから要求及びコマンドを受信するためのＡＰＩを含む、請求項１に記載のシステム。
3. 前記ＡＰＩは、前記ワークフローアドミニストレータエージェントに転送するために、前記ワークフローアドミニストレータから要求及びコマンドへの応答を受信する、請求項２に記載のシステム。
4. 前記ワークフローアドミニストレータは、ワークフローデータベースに問い合わせて、ワークフローアドミニストレータエージェントからの要求に応答する情報を取得する、請求項３に記載のシステム。
5. 前記ワークフローアドミニストレータエージェントからの前記要求は、実行を必要とする利用可能なワークフローについてのクエリを含む、請求項４に記載のシステム。
6. 前記ワークフローレジストリは、所定のワークフローの一部を形成するステップについてのビジネス論理を保持する、請求項１に記載のシステム。
7. 前記ワークフローエンジンは、前記顧客基盤からリモートである、請求項１に記載のシステム。
8. １つ又は複数の任意に定義されたワークフローのリモート実行のための方法であって、
   ワークフローアドミニストレータエージェントを顧客基盤で、及びワークフローエンジンからリモートであるワークフローアドミニストレータをクラウド基盤で実行することと、
   前記ワークフローアドミニストレータに、所定のワークフローの状態を記述するメタデータを保持するワークフローデータベースへのアクセスを提供することと、
   前記ワークフローアドミニストレータエージェントによって前記ワークフローアドミニストレータをポーリングして、所定のワークフローが、実行のためにスケジュールされている状態であるときを識別することと、
   前記所定のワークフローが実行のためにスケジュールされているとき、前記ワークフローアドミニストレータエージェントにより、前記所定のワークフローをワークフローレジストリから取得し、且つ前記所定のワークフローにおいて定義された１つ又は複数の機能を前記顧客基盤で実行するためのコマンドをワークフローエンジンに発行することと、
   前記ワークフローアドミニストレータエージェントにより、前記ワークフローデータベースに記憶するために、前記所定のワークフローの実行に関する状態情報を前記ワークフローアドミニストレータに送信することと
   を含む方法。
9. ＡＰＩにより、前記ワークフローアドミニストレータエージェントから要求及びコマンドを受信することと、
   前記受信された要求及びコマンドを前記ワークフローアドミニストレータに転送することと
   を含む、請求項１に記載の方法。
10. 前記ＡＰＩにより、前記ワークフローアドミニストレータから要求及びコマンドへの応答を受信することと、
    要求及びコマンドへの前記受信された応答を前記ワークフローアドミニストレータエージェントに転送することと
    を含む、請求項９に記載の方法。
11. 前記ワークフローアドミニストレータによって前記ワークフローデータベースに問い合わせて、ワークフローアドミニストレータエージェントからの要求に応答する情報を取得することを含む、請求項１０に記載の方法。
12. 前記ワークフローデータベースに問い合わせることは、実行を必要とする利用可能なワークフローについて問い合わせることを含む、請求項１１に記載の方法。
13. 前記ワークフローレジストリにおいて、所定のワークフローの一部を形成するステップについてのビジネス論理を保持することを含む、請求項８に記載の方法。
14. 前記顧客基盤からリモートで前記ワークフローエンジンを動作させることを含む、請求項１に記載のシステム。

Images