JP2022536108A - リモートソフトウェアアプリケーションのワークフローへの統合 - Google Patents

リモートソフトウェアアプリケーションのワークフローへの統合 Download PDF

Info

Publication number
JP2022536108A
JP2022536108A JP2021572334A JP2021572334A JP2022536108A JP 2022536108 A JP2022536108 A JP 2022536108A JP 2021572334 A JP2021572334 A JP 2021572334A JP 2021572334 A JP2021572334 A JP 2021572334A JP 2022536108 A JP2022536108 A JP 2022536108A
Authority
JP
Japan
Prior art keywords
software application
action
remote software
workflow
remote
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021572334A
Other languages
English (en)
Other versions
JP7315721B2 (ja
Inventor
スチュアート ディーン スウォープ
デイヴィッド タムジディ
アズファー サイド カズミ
クリストファー マロイ
レベッカ アニータ ディアス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ServiceNow Inc
Original Assignee
ServiceNow Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ServiceNow Inc filed Critical ServiceNow Inc
Publication of JP2022536108A publication Critical patent/JP2022536108A/ja
Application granted granted Critical
Publication of JP7315721B2 publication Critical patent/JP7315721B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5017—Task decomposition
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/547—Messaging middleware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/549—Remote execution

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

システムは、リモートソフトウェアアプリケーションのインターフェースの定義を格納するように構成された永続ストレージと、インターフェースを定義するように構成されたソフトウェアアプリケーションとを含む。ソフトウェアアプリケーションは、リモートソフトウェアアプリケーションが実行のためにそれによって公開されるリモートソフトウェアアプリケーションシステムを識別し、そこから特定のリモートソフトウェアアプリケーションの仕様を取得する。ソフトウェアアプリケーションは、仕様に基づいて、（ｉ）特定のリモートソフトウェアアプリケーションを介してアクセス可能なオブジェクトと、（ｉｉ）オブジェクトと相互作用するために呼び出し可能な関数とを判定する。ソフトウェアアプリケーションは、特定のリモートソフトウェアアプリケーションのためのインターフェースを定義するアクションを生成する。各アクションは、リモートソフトウェアアプリケーションシステムへリクエストを送信することによって関数の内の１つ以上の実行を呼び出し、それに応じて、リモートソフトウェアアプリケーションシステムを介して関数の内の１つ以上の出力を受け取るように構成される。アクションは、インターフェースを定義するために永続ストレージ内に格納される。

Description

アプリケーションプログラミングインターフェース（ＡＰＩ）は、ソフトウェアを構築するための一連の関数及び関連する通信プロトコルを提供する。ＡＰＩによって提供される関数は、特に、コンピュータネットワークを介してＡＰＩがアクセス可能である場合に、多くの異なるコンピューティングシステムにより使用され得る。すなわち、コンピューティングシステムは、これらの関数の別個の新たなバージョンを実装するのではなく、ＡＰＩの関数を利用し得る。ＡＰＩは、一般的に、それによって提供される関数と相互作用するための明確に定義されたプロトコル、標準、及び/又は規則を提供する。したがって、ＡＰＩの関数を利用するコンピューティングシステムは、特定のＡＰＩに固有のプロトコル、標準、及び規則に準拠し得る。これらの規則に準拠することによって、コンピューティングシステムは、事前定義された方法でＡＰＩの関数を呼び出し得、それに応じて、特定の予測可能な方法でフォーマット化された関数の出力を受け取り得る。
ソフトウェアベースのワークフロー設計ツールは、ワークフローの定義及び実行を可能にし得、ワークフローは、実行された場合に、１つ以上の目標を達成する特定のシーケンス又は一連のタスクである。ワークフロー設計ツールは、コンピュータプログラムコードを殆ど又は全く記述せずにワークフローがそれを介して定義され得るグラフィカルユーザインターフェースを提供し得る。各ワークフローは、要素の中でもとりわけ、特定の動作を実施するように構成された１つ以上のアクションを含み得る。アクションは、ソフトウェアベースのアクション設計ツールを使用してワークフローへの統合のために定義され得る。
ソフトウェアベースのアクション設計ツールは、１つ以上のリモートソフトウェアアプリケーションによって提供されるオブジェクト及び／又は関数と相互作用し、それらを利用するアクションを定義することを可能にし得る。これらのリモートソフトウェアアプリケーションは、ワークフローを実行するコンピューティングシステム（例えば、リモートネットワーク管理プラットフォーム）及び/又はワークフローが代わりに実行されるコンピューティングシステム（例えば、管理されるネットワーク）とは異なるサードパーティコンピューティングシステムによって開発及びホストされ得る。特定のリモートソフトウェアアプリケーションのオブジェクト及び／又は関数と相互作用する複数のアクションは、特定のリモートソフトウェアアプリケーションのためのインターフェースを集合的に定義し得る。このインターフェースは、代替的に、スポーク又は統合コネクタと称され得る。こうしたアクションは、これらのリモートソフトウェアアプリケーションのオブジェクト及び／又は関数を企業のワークフローに統合することにより、リモートソフトウェアアプリケーションによって提供される計算リソースを企業が利用することを可能にし得る。
ワークフローとリモートソフトウェアアプリケーションとの間の相互作用は、リモートソフトウェアアプリケーションシステムによって促進され得る。ワークフローを実行するコンピューティングシステム、リモートソフトウェアアプリケーションシステム、及びリモートソフトウェアアプリケーションを実行するコンピューティングシステムは各々、物理的に別個の別々のシステムであり得る。リモートソフトウェアアプリケーションシステムは、ワークフローを実行するコンピューティングシステムとリモートソフトウェアアプリケーションを実行するコンピューティングシステムとの間の仲介役として機能し得る。したがって、ワークフローは、リモートソフトウェアアプリケーションによって提供される幾つかの関数の実行に対するリクエストをリモートアプリケーションシステムへ送信し得る。リモートアプリケーションシステムは、順に、リモートソフトウェアアプリケーションにこれらの幾つかの関数の実行をリクエストし得る。関数の出力は、同様に、リモートソフトウェアアプリケーションシステムを介して、リモートアプリケーションによってワークフローに提供され得る。
特に、リモートソフトウェアアプリケーションの内の幾つかは、それらと相互作用するための標準、プロセス、及び／又は規則の異なるセットへのそれらの準拠において相互に異なり得る。したがって、リモートソフトウェアアプリケーションと直接相互作用するアクションは、それらとの通信及び相互作用を成功させるために、これらの標準、プロセス、及び/又は規則に準拠する必要があり得る。したがって、リモートソフトウェアアプリケーションと直接通信する各アクションは、特定のリモートソフトウェアアプリケーションの複雑さを説明するアプリケーション固有の方法で実装され得る。この方法でアクションを定義することは、特に標準、プロセス、及び/又は規則の文書化が利用できない、不足している、さもなければ不十分である場合に、時間がかかり得る。リモートソフトウェアアプリケーションシステムは、しかしながら、個々のリモートソフトウェアアプリケーションの標準、プロセス、及び/又は規則を説明し、ワークフローがリモートソフトウェアアプリケーションとの通信に使用し得る標準化された及び/又は均一のインターフェースを公開するＡＰＩを提供し得る。
一例では、リモートソフトウェアアプリケーションシステムは、リモートソフトウェアアプリケーションシステムにより公開される複数のリモートソフトウェアアプリケーションのそれぞれのリモートソフトウェアアプリケーションに、対応するＡＰＩを提供し得る。各ＡＰＩは、実行される場合に、リモートソフトウェアアプリケーションの対応する関数の実行を呼び出すＡＰＩ関数を含み得る。すなわち、リモートソフトウェアアプリケーションシステムは、その特定の関数の実行に対するリクエストを生成し得る。リモートソフトウェアアプリケーションシステムは、ワークフローに代わって関数の出力を受け取り得、この出力をワークフローに返し得る。したがって、リモートソフトウェアアプリケーションシステムのＡＰＩと通信し、その特定のＡＰＩ関数の実行をリクエストすることによって、ワークフローは、リモートソフトウェアアプリケーションの対応する関数の実行を呼び出し得る。特に、そうすることで、ワークフローはリモートソフトウェアアプリケーションシステムのＡＰＩと関連付けられた標準に準拠し得るが、対応するリモートソフトウェアアプリケーションの標準に準拠しないことがある。リモートソフトウェアアプリケーションシステムのＡＰＩは標準化され得るので、これらのＡＰＩを利用するインターフェースを開発することは、リモートソフトウェアアプリケーションと直接通信するインターフェースを開発することよりも容易であり得る。
また、リモートソフトウェアアプリケーションシステムは、そのＡＰＩ毎に、ＡＰＩの属性を定義する対応する仕様を提供し得る。すなわち、仕様は、可能な属性の中でもとりわけ、ＡＰＩを介してアクセス可能なオブジェクト、ＡＰＩを介して呼び出し可能な関数、これらの関数に対する入力、及びこれらの関数の出力を定義し得る。これらの仕様は、複数のリモートソフトウェアアプリケーションのためのインターフェースを構成するアクションを自動的に生成するために、ソフトウェアベースのアクション設計ツールによって取得、解析、及び使用され得る。
インターフェースの各アクションは、リモートソフトウェアアプリケーションの関数に対する入力値を受信し、その中に入力値を含むリクエストを生成し、リモートソフトウェアアプリケーションシステムのＡＰＩへ送信し、ＡＰＩから応答を受信し、応答内の関数の出力値を識別し、出力変数を介して出力値を他のアクションに公開するように構成され得る。
ソフトウェアベースのアクション設計ツールはまた、リモートソフトウェアアプリケーションのオブジェクト及び関数と相互作用するためにワークフローによって使用可能なサービス識別子（例えば、サービスアカウント）を識別するように構成され得る。各個別のサービス識別子は、個別のサービス識別子を使用してアクセス可能なオブジェクト及び／又は関数を定義する対応するスコープと関連付けられ得る。ソフトウェアベースのアクション設計ツールはまた、インターフェースの個々のアクションがワークフローへの統合に利用可能なように活性化されたり、ワークフローへの統合に利用不可能なように非活性化されたり、又は幾つかのタイプのワークフロー（例えば、特定のサービス識別子を使用するワークフロー）でのみ利用可能なようにコンテキスト固有の方法で活性化されたりすることを可能にし得る。
ソフトウェアベースのアクション設計ツールは、リモートソフトウェアアプリケーションのためのインターフェースを最新に保ち得る。一実装では、ソフトウェアベースのアクション設計ツールは、仕様の更新されたバージョンを定期的に取得し得、それになされた任意の変更を反映するようにインターフェースを更新し得る。別の実装では、ソフトウェアベースのアクション設計ツールは、そのアクションがワークフローに統合されるようにリクエストされる度に、特定のインターフェースを更新し得る。すなわち、インターフェースのアクションの定義がソフトウェアベースのワークフロー設計ツールによりリクエストされた後ではあるが、この定義がそれに提供される前に、ソフトウェアベースのアクション設計ツールは、そのインターフェースに対する更新された仕様を取得し得、任意の変更に従ってインターフェースを更新し得る。したがって、ソフトウェアベースのワークフロー設計ツールには、ワークフローへの統合のための改訂された定義が提供され得、ワークフローが現在のバージョンのアクションを利用することを可能にする。
したがって、第１の例示的実施形態は、（ｉ）ワークフローへの統合のためのリモートソフトウェアアプリケーションの個別のインターフェースの定義を格納するように構成された永続ストレージと、（ｉｉ）１つ以上のプロセッサと、（ｉｉｉ）個別のインターフェースを定義するように構成されたアクション設計ソフトウェアアプリケーションとを含むシステムを含む。アクション設計ソフトウェアアプリケーションは、リモートソフトウェアアプリケーションが実行のためにそれを介して公開されるリモートソフトウェアアプリケーションシステムを識別することを含む動作を１つ以上のプロセッサを介して実施するように構成される。動作はまた、リモートソフトウェアアプリケーションシステムから、リモートソフトウェアアプリケーションの内の特定のリモートソフトウェアアプリケーションの属性を定義する仕様を取得することを含む。動作は、仕様に基づいて、（ｉ）特定のリモートソフトウェアアプリケーションを介してアクセス可能な１つ以上のオブジェクト、及び（ｉｉ）１つ以上のオブジェクトと相互作用するために呼び出し可能な特定のリモートソフトウェアアプリケーションの複数の関数を判定することを更に含む。動作は、特定のリモートソフトウェアアプリケーションのためのインターフェースを定義する複数のアクションを生成することを更に含む。複数のアクションの各個別のアクションは、実行される場合に、（ｉ）リモートソフトウェアアプリケーションシステムへリクエストを送信することによって複数の関数の内の１つ以上の対応する関数の実行を呼び出し、（ｉｉ）リクエストに応答して、及びリモートソフトウェアアプリケーションシステムを介して、１つ以上の対応する関数の出力を受け取るように構成される。動作は、インターフェースを定義するために複数のアクションを永続ストレージ内に格納することを更に含む。
第２の例示的実施形態は、ワークフローへの統合のためのリモートソフトウェアアプリケーションの個別のインターフェースを定義するように構成されたアクション設計ソフトウェアアプリケーションによって、リモートソフトウェアアプリケーションが実行のためにそれを介して公開されるリモートソフトウェアアプリケーションシステムを識別することを含む。永続ストレージは、個別のインターフェースの定義を格納するように構成される。第２の例示的実施形態はまた、アクション設計ソフトウェアアプリケーションによって、及びリモートソフトウェアアプリケーションシステムから、リモートソフトウェアアプリケーションの内の特定のリモートソフトウェアアプリケーションの属性を定義する仕様を取得することを含む。第２の例示的実施形態は、アクション設計ソフトウェアアプリケーションによって、及び仕様に基づいて、（ｉ）特定のリモートソフトウェアアプリケーションを介してアクセス可能な１つ以上のオブジェクト、及び（ｉｉ）１つ以上のオブジェクトと相互作用するために呼び出し可能な特定のリモートソフトウェアアプリケーションの複数の関数を判定することを更に含む。第２の例示的実施形態は、アクション設計ソフトウェアアプリケーションによって、特定のリモートソフトウェアアプリケーションのためのインターフェースを定義する複数のアクションを生成することを更に含む。複数のアクションの各個別のアクションは、実行される場合に、（ｉ）リモートソフトウェアアプリケーションシステムへリクエストを送信することによって複数の関数の内の１つ以上の対応する関数の実行を呼び出し、（ｉｉ）リクエストに応答して、及びリモートソフトウェアアプリケーションシステムを介して、１つ以上の対応する関数の出力を受け取るように構成される。第２の例示的実施形態は更に、インターフェースを定義するために複数のアクションを永続ストレージ内に格納することを含む。
第３の例示的実施形態では、製品は、コンピューティングシステムによって実行されると、コンピューティングシステムに第１の例示的実施形態及び／又は第２の例示的実施形態に従った動作を実施させるプログラム命令をその上に格納する非一時的コンピュータ可読媒体を含み得る。
第４の例示的実施形態では、コンピューティングシステムは、少なくとも１つのプロセッサ、並びにメモリ及びプログラム命令を含み得る。プログラム命令は、メモリ内に格納され得、少なくとも１つのプロセッサによって実行されると、コンピューティングシステムに、第１の例示的実施形態及び／又は第２の例示的実施形態に従った動作を実施させ得る。
第５の例示的実施形態では、システムは、第１の例示的実施形態及び／又は第２の例示的実施形態の動作の各々を実行するための様々な手段を含み得る。
これらの並びにその他の実施形態、態様、利点、及び代替物は、添付の図面を適切に参照して、以下の詳細な説明を読むことによって当業者に明らかになるであろう。更に、この発明の概要並びに本明細書で提供される他の説明及び図は、例としてのみ実施形態を説明することを意図しており、したがって、多くの変形が可能である。実例として、構造要素及びプロセスステップは、請求されるような実施形態の範囲内にとどまりながら、再配置され得、組み合わされ得、分散され得、省略され得、さもなければ変更され得る。
例示的実施形態に従ったコンピューティングデバイスの概略図を説明する。 例示的実施形態に従ったサーバデバイスクラスタの概略図を説明する。 例示的実施形態に従ったリモートネットワーク管理アーキテクチャを描写する。 例示的実施形態に従ったリモートネットワーク管理アーキテクチャを含む通信環境を描写する。 例示的実施形態に従ったリモートネットワーク管理アーキテクチャを含む別の通信環境を描写する。 例示的実施形態に従ったフローチャートである。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったワークフロー設計ツールのグラフィカルユーザインターフェースを描写する。 例示的実施形態に従ったリモートソフトウェアアプリケーションシステムを描写する。 例示的実施形態に従ったＡＰＩ仕様の抜粋を描写する。 例示的実施形態に従ったＡＰＩ仕様の抜粋を描写する。 例示的実施形態に従ったＡＰＩ仕様の抜粋を描写する。 例示的実施形態に従ったＡＰＩ仕様の抜粋を描写する。 例示的実施形態に従ったＡＰＩ仕様の抜粋を描写する。 例示的実施形態に従ったメッセージ図である。 例示的実施形態に従ったメッセージ図である。 例示的実施形態に従ったワークフローを描写する。 例示的な実施形態に従ったフローチャートである。
例示的な方法、デバイス、及びシステムが本明細書に説明される。本明細書では、単語“例”及び“例示的”は、“例、実例、又は例証として役立つ”ことを意味するために使用されることを理解すべきである。“例”又は“例示的”であるとして本明細書に説明される任意の実施形態又は機構は、そのように述べられない限り、必ずしも他の実施形態又は機構よりも好ましい又は有利であると解釈されるべきではない。したがって、本明細書に提示される主題の範囲から逸脱することなく、他の実施形態が利用され得、他の変更がなされ得る。
したがって、本明細書に説明する例示的実施形態は、限定することを意図しない。本明細書に一般的に説明され、図に説明されるような本開示の態様が、多種多様な異なる構成で配置され得、置換され得、組み合わされ得、分離され得、及び設計され得ることは容易に理解されるであろう。例えば、“クライアント”コンポーネントと“サーバ”コンポーネントとへの機構の分離は、様々な方法で生じ得る。
更に、文脈が他のことを示唆しない限り、図の各々に示される機構は、相互に組み合わせて使用され得る。したがって、図は、一般的に、各実施形態に対して全ての説明された機構が必要であるとは限らないことを理解すると共に、１つ以上の全体的な実施形態のコンポーネントの態様としてみなされるべきである。
また、この明細書又は特許請求の範囲における要素、ブロック、又はステップの任意の列挙は、明確にする目的のためのものである。したがって、そうした列挙は、これらの要素、ブロック、又はステップが特定の配置に準拠すること、又は特定の順序で実行されることを必要とする又は暗示するものとして解釈されるべきではない。
Ｉ． はじめに
大企業は、多くの相互に関連する動作を伴う複雑なエンティティである。これらの幾つかは、人材（ＨＲ）、サプライチェーン、情報技術（ＩＴ）、財務等、企業全体で見られる。しかしながら、各企業はまた、本質的な能力を提供し、及び／又は競争上の優位性を創出する独自の動作を有する。
広く実装された動作をサポートするために、企業は通常、顧客関係管理（ＣＲＭ）及び人的資本管理（ＨＣＭ）パッケージ等の既製のソフトウェアアプリケーションを使用する。しかしながら、それらの独自の要件を満たすためにカスタムソフトウェアアプリケーションを必要とすることもあり得る。大企業は、数十又は数百のこれらのカスタムソフトウェアアプリケーションをしばしば有する。それにもかかわらず、本明細書の実施形態によって提供される利点は、大企業に限定されず、任意の規模の企業又は任意の他のタイプの組織に適用可能であり得る。
多くのそうしたソフトウェアアプリケーションは、企業内の個々の部門によって開発される。これらは、単純なスプレッドシートからカスタムビルドのソフトウェアツール及びデータベースにまで及ぶ。しかしながら、サイロ化されたカスタムソフトウェアアプリケーションの急増は、多くの欠点を有する。そのことは、その動作を運営及び拡大し、革新し、規制要件を満たす企業の能力に悪影響を及ぼす。企業は、そのサブシステムとデータとを統合する単一のシステムを欠くことに起因して、その動作を統合、合理化、及び強化することが難しいと感じることがある。
カスタムアプリケーションを効率的に作成するために、企業は、不必要な開発の複雑さを排除する、リモートでホストされたアプリケーションプラットフォームからの利益を得るであろう。そうしたプラットフォームの目標は、ソフトウェアエンジニア及び他の役割の個人が独自の高価値の機構の開発に集中できるように、時間のかかる反復的なアプリケーション開発タスクを削減することであろう。
この目標を達成するために、企業全体のワークフローをインテリジェントに自動化するように、サービスとしてのアプリケーションプラットフォーム（ａＳａａＳ）の概念が導入される。ａＰａａＳシステムは企業からリモートでホストされるが、安全な接続を介して企業内のデータ、アプリケーション、及びサービスにアクセスし得る。そうしたａＰａａＳシステムは、幾つかの有利な能力及び特徴を有し得る。これらの利点及び特徴は、ＩＴ、ＨＲ、ＣＲＭ、顧客サービス、アプリケーション開発、及びセキュリティに対する企業の動作とワークフローとを改善することが可能であり得る。
ａＰａａＳシステムは、モデルビューコントローラ（ＭＶＣ）アプリケーションの開発及び実行をサポートし得る。ＭＶＣアプリケーションは、情報の表現をユーザに情報が提示される方法から分離するために、それらの機能を３つの相互接続された部分（モデル、ビュー、及びコントローラ）に分割し、それによって、効率的なコードの再利用と並列開発とを可能にする。これらのアプリケーションはウェブベースであり得、作成、読み出し、更新、削除（ＣＲＵＤ）機能を提供し得る。このことは、新たなアプリケーションが共通のアプリケーションインフラストラクチャ上に構築されることを可能にする。
ａＰａａＳシステムは、グラフィカルユーザインターフェース（ＧＵＩ）開発のためのウィジェットの標準化されたセット等の標準化されたアプリケーションコンポーネントをサポートし得る。このように、ａＰａａＳシステムを使用して構築されたアプリケーションは、共通のルックアンドフィールを有する。他のソフトウェアコンポーネント及びモジュールも標準化され得る。幾つかの場合、このルックアンドフィールは、企業のカスタムロゴ及び／又は配色でブランド化又はスキン化され得る。
ａＰａａＳシステムは、メタデータを使用してアプリケーションの挙動を構成する能力をサポートし得る。このことは、アプリケーションの挙動が特定のニーズに合わせて迅速に適応されることを可能にする。こうしたアプローチは、開発時間を削減し、柔軟性を増加させる。更に、ａＰａａＳシステムは、メタデータの作成と管理とを容易にするＧＵＩツールをサポートし得、したがって、メタデータのエラーを削減する。
ａＰａａＳシステムは、ソフトウェア開発者が望ましくないアプリケーション間の依存性を回避し得るように、アプリケーション間の明確に定義されたインターフェースをサポートし得る。したがって、ａＰａａＳシステムは、永続的な状態情報及びその他のデータが格納されるサービス層を実装し得る。
ａＰａａＳシステムは、その上のアプリケーションが従来のアプリケーション及びサードパーティアプリケーションと相互作用し得るように、統合機構の豊富なセットをサポートし得る。実例として、ａＰａａＳシステムは、従来のＨＲ、ＩＴ、及び会計システムと統合するカスタム社員オンボーディングシステムをサポートし得る。
ａＰａａＳシステムは、企業グレードのセキュリティをサポートし得る。更に、ａＰａａＳシステムはリモートでホストされ得るので、それは、企業内のシステムと、又は企業外でホストされたサードパーティのネットワーク及びサービスと相互作用する場合にも、セキュリティ手順を利用すべきである。例えば、ａＰａａＳシステムは、一般的なセキュリティの脅威を検出及び識別するために、企業及び他の関係者の間でデータを共有するように構成され得る。
ａＰａａＳシステムの他の機構、機能、及び利点が存在し得る。この説明は例を目的としており、限定することを意図しない。
ａＰａａＳ開発プロセスの例として、ソフトウェア開発者は、ａＰａａＳシステムを使用して新たなアプリケーションを作成するようにタスクを課され得る。まず、開発者は、アプリケーションが使用するデータのタイプとそれらの間の関係とを特定するデータモデルを定義し得る。その後、ａＰａａＳシステムのＧＵＩを介して、開発者はデータモデルを入力（例えば、アップロード）する。ａＰａａＳシステムは、対応するデータベーステーブル、フィールド、及び関係の全てを自動的に作成し、それらは、オブジェクト指向サービス層を介してその後アクセスされ得る。
また、ａＰａａＳシステムは、クライアント側インターフェース及びサーバ側ＣＲＵＤロジックを備えた完全に機能するＭＶＣアプリケーションをも構築し得る。この生成されたアプリケーションは、ユーザに対して更なる開発の基礎として役立ち得る。有利なことに、開発者は基本的なアプリケーション機能に多くの時間を費やす必要がない。更に、アプリケーションはウェブベースであり得るので、それは、インターネット対応の任意のクライアントデバイスからアクセスされ得る。代替的又は追加的に、実例としてインターネットサービスが利用可能ではない場合、アプリケーションのローカルコピーにアクセスすることが可能であり得る。
ａＰａａＳシステムは、アプリケーションに追加され得る事前定義された機能の豊富なセットをもサポートし得る。これらの機構は、検索、電子メール、テンプレート、ワークフロー設計、レポート、分析、ソーシャルメディア、スクリプト、モバイルフレンドリーな出力、及びカスタマイズされたＧＵＩに対するサポートを含む。
以下の実施形態は、例示的なａＰａａＳシステムのアーキテクチャ及び機能の態様、並びにその機構及び利点を説明する。
ＩＩ． コンピューティングデバイス及びクラウドベースのコンピューティング環境の例
図１は、コンピューティングデバイス１００を例示する簡略化されたブロック図であり、本明細書の実施形態に従って動作するように配置されたコンピューティングデバイス内に含まれ得るコンポーネントの内の幾つかを説明する。コンピューティングデバイス１００は、クライアントデバイス（例えば、ユーザによってアクティブに動作されるデバイス）、サーバデバイス（例えば、クライアントデバイスに計算サービスを提供するデバイス）、又は他の何らかのタイプの計算プラットフォームであり得る。幾つかのサーバデバイスは、特定の動作を実施するためにクライアントデバイスとして時折動作し得、幾つかのクライアントデバイスはサーバの機構を組み込み得る。
この例では、コンピューティングデバイス１００は、プロセッサ１０２、メモリ１０４、ネットワークインターフェース１０６、及び入力／出力ユニット１０８を含み、それらの全ては、システムバス１１０又は同様のメカニズムによって結合され得る。幾つかの実施形態では、コンピューティングデバイス１００は、他のコンポーネント及び／又は周辺デバイス（例えば、取り外し可能なストレージ及びプリンタ等）を含み得る。
プロセッサ１０２は、中央処理装置（ＣＰＵ）、コプロセッサ（例えば、数学、グラフィックス、又は暗号化コプロセッサ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、及び/又はプロセッサの動作を実施する集積回路若しくはコントローラの形式等の任意のタイプのコンピュータ処理要素の内の１つ以上であり得る。幾つかの場合、プロセッサ１０２は、１つ以上のシングルコアプロセッサであり得る。他の場合、プロセッサ１０２は、複数の独立した処理ユニットを備えた１つ以上のマルチコアプロセッサであり得る。プロセッサ１０２はまた、実行されている命令及び関連データを一時的に格納するためのレジスタメモリ、並びに最近使用された命令及びデータを一時的に格納するためのキャッシュメモリを含み得る。
メモリ１０４は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、及び不揮発性メモリ（例えば、フラッシュメモリ、ハードディスクドライブ、ソリッドステートドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、及び/又はテープストレージ）を含むがそれらに限定されない任意の形式のコンピュータ使用可能メモリであり得る。したがって、メモリ１０４は、メインメモリユニットと長期ストレージとの両方を表す。その他のタイプのメモリは、生体メモリを含み得る。
メモリ１０４は、プログラム命令及び／又はプログラム命令が動作し得るデータを格納し得る。例として、メモリ１０４は、この明細書又は添付の図面に開示される方法、プロセス、又は動作の内の何れかを実行するためにプロセッサ１０２によって命令が実行可能であるように、これらのプログラム命令を非一時的コンピュータ可読媒体上に格納し得る。
図１に示されるように、メモリ１０４は、ファームウェア１０４Ａ、カーネル１０４Ｂ、及び／又はアプリケーション１０４Ｃを含み得る。ファームウェア１０４Ａは、コンピューティングデバイス１００の内の幾つか又は全てをブート、さもなければ開始するために使用されるプログラムコードであり得る。カーネル１０４Ｂは、メモリ管理、プロセスのスケジューリング及び管理、入力／出力、並びに通信のためのモジュールを含むオペレーティングシステムであり得る。カーネル１０４Ｂはまた、オペレーティングシステムがコンピューティングデバイス１００のハードウェアモジュール（例えば、メモリユニット、ネットワークインターフェース、ポート、及びバス）と通信することを可能にするデバイスドライバを含み得る。アプリケーション１０４Ｃは、ウェブブラウザ又は電子メールクライアント等の１つ以上のユーザ空間ソフトウェアプログラム、並びにこれらのプログラムにより使用される任意のソフトウェアライブラリであり得る。メモリ１０４はまた、これらの及びその他のプログラム及びアプリケーションにより使用されるデータを格納し得る。
ネットワークインターフェース１０６は、イーサネット（例えば、ファストイーサネット及びギガビットイーサネット等）等の１つ以上の有線インターフェースの形式を取り得る。ネットワークインターフェース１０６はまた、同軸ケーブル若しくは電力線等の１つ以上の非イーサネット媒体を介して、又は同期光ネットワーク（ＳＯＮＥＴ）若しくはデジタル加入者線（ＤＳＬ）技術等の広域媒体を介して通信をサポートし得る。ネットワークインターフェース１０６は更に、ＩＥＥＥ ８０２．１１（Ｗｉｆｉ）、ＢＬＵＥＴＯＯＴＨ（登録商標）、全地球測位システム（ＧＰＳ）、又は広域無線インターフェース等の１つ以上の無線インターフェースの形式を取り得る。しかしながら、他の形式の物理層インターフェース及び他のタイプの標準又は独自の通信プロトコルがネットワークインターフェース１０６を介して使用され得る。更に、ネットワークインターフェース１０６は、複数の物理インターフェースを含み得る。実例として、コンピューティングデバイス１００の幾つかの実施形態は、イーサネット、ＢＬＵＥＴＯＯＴＨ（登録商標）、及びＷｉｆｉインターフェースを含み得る。
入力／出力ユニット１０８は、コンピューティングデバイス１００とのユーザ及び周辺デバイスの相互作用を容易にし得る。入力／出力ユニット１０８は、キーボード、マウス、及びタッチスクリーン等の１つ以上のタイプの入力デバイスを含み得る。同様に、入力／出力ユニット１０８は、スクリーン、モニタ、プリンタ、及び／又は１つ以上の発光ダイオード（ＬＥＤ）等の１つ以上のタイプの出力デバイスを含み得る。追加的又は代替的に、コンピューティングデバイス１００は、例えば、ユニバーサルシリアルバス（ＵＳＢ）又は高品位マルチメディアインターフェース（ＨＤＭＩ）ポートインターフェースを使用して他のデバイスと通信し得る。
幾つかの実施形態では、コンピューティングデバイス１００のような１つ以上のコンピューティングデバイスは、ａＰａａＳアーキテクチャをサポートするように配備され得る。これらのコンピューティングデバイスの正確な物理的な位置、接続、及び構成は、クライアントデバイスにとって不明であり得、及び／又は重要ではないことがある。したがって、コンピューティングデバイスは、様々なリモートデータセンタの位置にホストされ得る“クラウドベースの”デバイスと称され得る。
図２は、例示的実施形態に従ったクラウドベースのサーバクラスタ２００を描写する。図２では、コンピューティングデバイス（例えば、コンピューティングデバイス１００）の動作は、サーバデバイス２０２、データストレージ２０４、及びルータ２０６の間で分散され得、これらの全ては、ローカルクラスタネットワーク２０８によって接続され得る。サーバクラスタ２００内のサーバデバイス２０２、データストレージ２０４、及びルータ２０６の数は、サーバクラスタ２００に割り当てられたコンピューティングタスク及び／又はアプリケーションに依存し得る。
例えば、サーバデバイス２０２は、コンピューティングデバイス１００の様々なコンピューティングタスクを実施するように構成され得る。したがって、コンピューティングタスクは、サーバデバイス２０２の内の１つ以上の間で分散され得る。これらのコンピューティングタスクが並行して実施され得る範囲で、タスクのこうした分散は、これらのタスクを完了して結果を返すための合計時間を削減し得る。簡単にする目的のために、サーバクラスタ２００及び個々のサーバデバイス２０２の両方は、“サーバデバイス”と称され得る。この命名法は、１つ以上の別個のサーバデバイス、データストレージデバイス、及びクラスタルータがサーバデバイスの動作に関与し得ることを意味すると理解すべきである。
データストレージ２０４は、ハードディスクドライブ及び／又はソリッドステートドライブのグループへの読み出し及び書き込みアクセスを管理するように構成されたドライブアレイコントローラを含むデータストレージアレイであり得る。ドライブアレイコントローラはまた、単独で、又はサーバデバイス２０２と組み合わせて、サーバデバイス２０２の内の１つ以上がデータストレージ２０４のユニットにアクセスすることを妨げるドライブの障害又は他のタイプの障害から保護するように、データストレージ２０４内に格納されたデータのバックアップ又は冗長コピーを管理するように構成され得る。ドライブ以外の他のタイプのメモリが使用されてもよい。
ルータ２０６は、サーバクラスタ２００に内部及び外部の通信を提供するように構成されたネットワーク機器を含み得る。例えば、ルータ２０６は、（ｉ）ローカルクラスタネットワーク２０８を介したサーバデバイス２０２とデータストレージ２０４との間のネットワーク通信、及び／又は（ｉｉ）ネットワーク２１２への通信リンク２１０を介したサーバクラスタ２００と他のデバイスとの間のネットワーク通信を提供するように構成された１つ以上のパケットスイッチング及び／又はルーティングデバイス（スイッチ及び／又はゲートウェイを含む）を含み得る。
また、ルータ２０６の構成は、サーバデバイス２０２及びデータストレージ２０４のデータ通信要件、ローカルクラスタネットワーク２０８のレイテンシ及びスループット、通信リンク２１０のレイテンシ、スループット、及びコスト、並びに／又はシステムアーキテクチャのコスト、速度、フォールトトレランス、復元性、効率、及び／若しくはその他の設計目標に寄与し得るその他の要因に少なくとも部分的に基づき得る。
可能な例として、データストレージ２０４は、ストラクチャードクエリ言語（ＳＱＬ）データベース等の任意の形式のデータベースを含み得る。テーブル、アレイ、リスト、ツリー、及びタプル等を含むがこれらに限定されない様々なタイプのデータ構造がこうしたデータベース内に情報を格納し得る。更に、データストレージ２０４内の任意のデータベースは、モノリシックであり得、又は複数の物理デバイスに分散され得る。
サーバデバイス２０２は、データストレージ２０４へデータを送信し、データストレージ２０４からデータを受信するように構成され得る。この送信及び検索は、ＳＱＬクエリ又は他のタイプのデータベースクエリ、及びそうしたクエリの出力の形式を夫々取り得る。追加のテキスト、画像、ビデオ、及び/又は音声も含まれ得る。更に、サーバデバイス２０２は、受信したデータをウェブページ表現に編成し得る。こうした表現は、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張可能マークアップ言語（ＸＭＬ）、又はその他の何らかの標準化された又は独自のフォーマット等のマークアップ言語の形式を取り得る。更に、サーバデバイス２０２は、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＰＨＰハイパーテキストプリプロセッサ（ＰＨＰ）、アクティブサーバページ（ＡＳＰ）、及びＪＡＶＡＳＣＲＩＰＴ（登録商標）等であるがこれらに限定されない、様々なタイプのコンピュータ化されたスクリプト言語を実行する能力を有し得る。これらの言語で書き込まれたコンピュータプログラムコードは、クライアントデバイスへのウェブページの提供、及びウェブページとのクライアントデバイスの相互作用を容易にし得る。
ＩＩＩ． リモートネットワーク管理アーキテクチャの例
図３は、例示的実施形態に従ったリモートネットワーク管理アーキテクチャを描写する。このアーキテクチャは、３つの主要なコンポーネント、管理されるネットワーク３００と、リモートネットワーク管理プラットフォーム３２０と、サードパーティネットワーク３４０とを含み、全てはインターネット３５０を介して接続される。
管理されるネットワーク３００は、例えば、データの格納と共に、コンピューティング及び通信タスクのためにエンティティによって使用される企業ネットワークであり得る。したがって、管理されるネットワーク３００は、クライアントデバイス３０２、サーバデバイス３０４、ルータ３０６、仮想マシン３０８、ファイアウォール３１０、及び／又はプロキシサーバ３１２を含み得る。クライアントデバイス３０２は、コンピューティングデバイス１００によって具現化され得、サーバデバイス３０４は、コンピューティングデバイス１００又はサーバクラスタ２００によって具現化され得、ルータ３０６は、任意のタイプのルータ、スイッチ、又はゲートウェイであり得る。
仮想マシン３０８は、コンピューティングデバイス１００又はサーバクラスタ２００の内の１つ以上によって具現化され得る。一般的に、仮想マシンは、コンピューティングシステムのエミュレーションであり、物理的コンピュータの機能（例えば、プロセッサ、メモリ、及び通信リソース）を模倣する。サーバクラスタ２００等の１つの物理的コンピューティングシステムは、最大数千の個々の仮想マシンをサポートし得る。幾つかの実施形態では、仮想マシン３０８は、個々の仮想マシンへの物理的コンピューティングリソースの割り当て、並びに性能及びエラーレポートを容易にする集中型サーバデバイス又はアプリケーションによって管理され得る。企業は、必要に応じて効率的にコンピューティングリソースを割り当てるために、仮想マシンをしばしば用いる。仮想化コンピューティングシステムのプロバイダは、ＶＭＷＡＲＥ（登録商標）及びＭＩＣＲＯＳＯＦＴ（登録商標）を含む。
ファイアウォール３１０は、管理されるネットワーク３００から開始される許可された通信を可能にしつつ、管理されるネットワーク３００をその中のデバイス、アプリケーション、及びサービスへの不正なアクセスの試みから保護する１つ以上の特殊なルータ又はサーバデバイスであり得る。ファイアウォール３１０は、侵入検出、ウェブフィルタリング、ウイルススキャン、アプリケーション層ゲートウェイ、及びその他のアプリケーション又はサービスを提供する。図３に示されていない幾つかの実施形態では、管理されるネットワーク３００は、リモートネットワーク管理プラットフォーム３２０と通信する１つ以上の仮想プライベートネットワーク（ＶＰＮ）ゲートウェイを含み得る（以下を参照）。
管理されるネットワーク３００はまた、１つ以上のプロキシサーバ３１２を含み得る。プロキシサーバ３１２の実施形態は、管理されるネットワーク３００、リモートネットワーク管理プラットフォーム３２０、及びサードパーティネットワーク３４０の間の通信及びデータの移動を容易にするサーバデバイスであり得る。特に、プロキシサーバ３１２は、リモートネットワーク管理プラットフォーム３２０の１つ以上の計算インスタンスとの安全な通信セッションを確立及び維持することが可能であり得る。そうしたセッションを介して、リモートネットワーク管理プラットフォーム３２０は、管理されるネットワーク３００及びそのコンポーネントのアーキテクチャ及び構成の態様を発見及び管理することが可能であり得る。可能性としてプロキシサーバ３１２の助けを借りて、リモートネットワーク管理プラットフォーム３２０はまた、管理されるネットワーク３００により使用されるサードパーティネットワーク３４０の態様を発見及び管理することが可能であり得る。
ファイアウォール３１０等のファイアウォールは、そうしたセッションがファイアウォールの背後から（すなわち、管理されるネットワーク３００上のデバイスから）最終的に開始されない限り、又はファイアウォールがセッションをサポートするように明示的に構成されていない限り、通常、インターネット３５０を介して着信する全ての通信セッションを拒否する。プロキシサーバ３１２を（例えば、管理されるネットワーク３００内に、ファイアウォール３１０によって保護される）ファイアウォール３１０の背後に配置することによって、プロキシサーバ３１２は、ファイアウォール３１０を通じてこれらの通信セッションを開始することが可能であり得る。したがって、ファイアウォール３１０は、リモートネットワーク管理プラットフォーム３２０からの着信セッションをサポートするように特別に構成される必要がなくてもよく、それによって、管理されるネットワーク３００に対する潜在的なセキュリティリスクを回避する。
幾つかの場合、管理されるネットワーク３００は、僅かなデバイスと少数のネットワークとからなり得る。他の配備では、管理されるネットワーク３００は、複数の物理的な位置に及び得、数百のネットワークと数十万のデバイスとを含み得る。したがって、図３に描写されたアーキテクチャは、桁違いにスケールアップ又はスケールダウンすることが可能である。
更に、管理されるネットワーク３００のサイズ、アーキテクチャ、及び接続に依存して、様々な数のプロキシサーバ３１２がその中に配備され得る。例えば、プロキシサーバ３１２の各々１つは、管理されるネットワーク３００の一部に関してリモートネットワーク管理プラットフォーム３２０と通信することに責任に負い得る。代替的に又は追加的に、２つ以上のプロキシサーバのセットは、負荷分散、冗長性、及び/又は高可用性の目的で、管理されるネットワーク３００のそうした部分に割り当てられ得る。
リモートネットワーク管理プラットフォーム３２０は、ユーザ、特に管理されるネットワーク３００のオペレータにａＰａａＳサービスを提供するホストされた環境である。これらのサービスは、実例として、ウェブベースのポータルの形式を取り得る。したがって、ユーザは、実例として、クライアントデバイス３０２から、又は潜在的に、管理されるネットワーク３００の外部のクライアントデバイスから、リモートネットワーク管理プラットフォーム３２０に安全にアクセスし得る。ウェブベースのポータルを介して、ユーザは、アプリケーションを設計、テスト、及び展開し得、レポートを生成し得、分析を表示し得、その他のタスクを実施し得る。
図３に示されるように、リモートネットワーク管理プラットフォーム３２０は、４つの計算インスタンス３２２、３２４、３２６、及び３２８を含む。これらのインスタンスの各々は、特定の顧客が利用可能なウェブポータル、サービス、及びアプリケーションのセット（例えば、完全に機能するａＰａａＳシステム）を提供する１つ以上のサーバデバイス及び／又は１つ以上のデータベースを表し得る。幾つかの場合、１人の顧客が複数の計算インスタンスを使用し得る。例えば、管理されるネットワーク３００は、リモートネットワーク管理プラットフォーム３２０の企業顧客であり得、計算インスタンス３２２、３２４、及び３２６を使用し得る。１人の顧客に複数のインスタンスを提供する理由は、顧客がそのアプリケーション及びサービスを独立して開発、テスト、及び展開することを望み得ることである。したがって、計算インスタンス３２２は、管理されるネットワーク３００に関連するアプリケーション開発に専用であり得、計算インスタンス３２４は、これらのアプリケーションのテストに専用であり得、計算インスタンス３２６は、テストされたアプリケーション及びサービスのライブ動作に専用であり得る。計算インスタンスは、ホストされたインスタンス、リモートインスタンス、顧客インスタンス、又はその他の何らかの呼称でも称され得る。計算インスタンス上に展開された任意のアプリケーションは、計算インスタンス内のデータベースへのそのアクセスがその中のある一定の要素（例えば、１つ以上の特定のデータベーステーブル又は１つ以上のデータベーステーブルを備えた特定の行）に制限され得るという点で、スコープ付きアプリケーションであり得る。
明確の目的のために、本明細書の開示は、物理的ハードウェア、ソフトウェア、及びそれらの配置を“計算インスタンス”と称する。ユーザは、それによって提供されるグラフィカルユーザインターフェースを口語的に“インスタンス”と称し得ることに留意されたい。しかしながら、本明細書で別段の定義がない限り、“計算インスタンス”は、リモートネットワーク管理プラットフォーム３２０内に配備されたコンピューティングシステムである。
リモートネットワーク管理プラットフォーム３２０のマルチインスタンスアーキテクチャは、マルチインスタンスアーキテクチャが幾つかの利点を示す従来のマルチテナントアーキテクチャとは対照的である。マルチテナントアーキテクチャでは、異なる顧客（例えば、企業）からのデータが単一のデータベースに混合される。これらの顧客のデータは相互に分離されるが、該分離は単一のデータベースを動作するソフトウェアによって実施される。結果として、このシステムにおけるセキュリティ違反は、全ての顧客のデータに影響を与え得、特に政府、医療、及び/又は金融規制の対象となるエンティティに追加のリスクを創出する。更に、１人の顧客に影響を与える任意のデータベース動作は、そのデータベースを共有する全ての顧客におそらく影響を与えるであろう。したがって、ハードウェア又はソフトウェアのエラーに起因する停止がある場合、この停止はそうした全ての顧客に影響を与える。同様に、１人の顧客のニーズを満たすためにデータベースがアップグレードされる場合、それは、アップグレードプロセスの間、全ての顧客にとって利用不可能であろう。多くの場合、共有されるデータベースのサイズに起因して、こうしたメンテナンスウィンドウは長いであろう。
対照的に、マルチインスタンスアーキテクチャは、各顧客に、専用のコンピューティングインスタンス内の独自のデータベースを提供する。このことは、顧客データの混合を防止し、各インスタンスが独立して管理されることを可能にする。例えば、ある顧客のインスタンスがエラー又はアップグレードに起因する停止を経験した場合、他の計算インスタンスは影響を受けない。データベースは１人の顧客のデータのみを含むので、メンテナンスのダウン時間は限定される。更に、マルチインスタンスアーキテクチャのよりシンプルな設計は、各顧客データベース及びインスタンスの冗長コピーが地理的に多様な方法で展開されることを可能にする。このことは、高可用性を容易にし、障害が検出された場合、又はメンテナンスが実施されている場合に、顧客のインスタンスのライブバージョンは動かされ得る。
幾つかの実施形態では、リモートネットワーク管理プラットフォーム３２０は、このプラットフォームを動作するエンティティによって制御される１つ以上の中央インスタンスを含み得る。計算インスタンスと同様に、中央インスタンスは、幾つかの数の物理サーバ又は仮想サーバとデータベースデバイスとを含み得る。こうした中央インスタンスは、計算インスタンスの内の少なくとも幾つかの間で共有され得るデータに対するリポジトリとして機能し得る。実例として、計算インスタンス上で発生し得る一般的なセキュリティ脅威の定義、計算インスタンス上で一般的に発見されるソフトウェアパッケージ、及び/又は計算インスタンスに展開され得るアプリケーションに対するアプリケーションストアは、中央インスタンス内に存在し得る。計算インスタンスは、このデータを取得するために、明確に定義されたインターフェースを介して中央インスタンスと通信し得る。
効率的な方法で複数の計算インスタンスをサポートするために、リモートネットワーク管理プラットフォーム３２０は、単一のハードウェアプラットフォーム上にこれらの複数のインスタンスを実装し得る。例えば、ａＰａａＳシステムがサーバクラスタ２００等のサーバクラスタ上に実装される場合、それは、様々な量の計算、ストレージ、及び通信リソースをインスタンス専用にする仮想マシンを動作し得る。しかしながら、サーバクラスタ２００の完全な仮想化は必要なくてもよく、インスタンスを分離するために他のメカニズムが使用され得る。幾つかの例では、各インスタンスは、サーバクラスタ２００上に専用のアカウント及び１つ以上の専用のデータベースを有し得る。或いは、計算インスタンス３２２は、複数の物理デバイスに及び得る。
幾つかの場合、リモートネットワーク管理プラットフォーム３２０の単一のサーバクラスタは、複数の独立した企業をサポートし得る。更に、以下で説明するように、リモートネットワーク管理プラットフォーム３２０は、負荷分散、冗長性、及び／又は高可用性を容易にするために、地理的に多様なデータセンタ内に配備された複数のサーバクラスタを含み得る。
サードパーティネットワーク３４０は、外部委託された計算、データストレージ、通信、及びサービスホスト動作に使用され得るリモートサーバデバイス（例えば、サーバクラスタ２００等の複数のサーバクラスタ）であり得る。これらのサーバは仮想化され得る（すなわち、サーバは仮想マシンであり得る）。サードパーティネットワーク３４０の例は、ＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ（登録商標）及びＭＩＣＲＯＳＯＦＴ（登録商標）ＡＺＵＲＥ（登録商標）を含み得る。リモートネットワーク管理プラットフォーム３２０と同様に、サードパーティネットワーク３４０をサポートする複数のサーバクラスタは、負荷分散、冗長性、及び/又は高可用性の目的で、地理的に異なる位置に配備され得る。
管理されるネットワーク３００は、そのクライアント及び顧客にアプリケーション及びサービスを展開するために。サードパーティネットワーク３４０の内の１つ以上を使用し得る。実例として、管理されるネットワーク３００がオンライン音楽ストリーミングサービスを提供する場合、サードパーティネットワーク３４０は、音楽ファイルを格納し得、ウェブインターフェース及びストリーミング能力を提供し得る。このようにして、管理されるネットワーク３００の企業は、これらの動作のために独自のサーバを構築及び維持する必要がない。
リモートネットワーク管理プラットフォーム３２０は、仮想マシンとその中の管理されるサービスとを管理されるネットワーク３００に公開するために、サードパーティネットワーク３４０と統合するモジュールを含み得る。モジュールは、ユーザが仮想リソースをリクエストし、サードパーティネットワークに柔軟なレポートを提供することを可能にし得る。この機能を確立するために、管理されるネットワーク３００からのユーザは、サードパーティネットワーク３４０でアカウントを最初に確立し、関連付けられたリソースのセットをリクエストし得る。その後、ユーザは、リモートネットワーク管理プラットフォーム３２０の適切なモジュールにアカウント情報を入力し得る。これらのモジュールは、アカウント内の管理可能なリソースを自動的にその後発見し得、使用、性能、及び支払い請求に関連するレポートをも提供し得る。
インターネット３５０は、グローバルインターネットの一部分を表し得る。しかしながら、インターネット３５０は、代わりに、プライベートワイドエリア又はローカルエリアパケット交換ネットワーク等の異なるタイプのネットワークを表し得る。
図４は、管理されるネットワーク３００と計算インスタンス３２２との間の通信環境を更に説明し、追加の機構及び代替の実施形態を紹介する。図４では、計算インスタンス３２２は、データセンタ４００Ａ及び４００Ｂに渡って複製されている。これらのデータセンタは、おそらく異なる都市又は異なる国に、相互に地理的に離れていてもよい。各データセンタは、管理されるネットワーク３００及びリモートユーザとの通信を容易にするサポート機器を含む。
データセンタ４００Ａでは、外部デバイスとの間のネットワークトラフィックは、ＶＰＮゲートウェイ４０２Ａ又はファイアウォール４０４Ａの何れかを通じて流れる。ＶＰＮゲートウェイ４０２Ａは、インターネットプロトコルセキュリティ（ＩＰＳＥＣ）又はトランスポートレイヤセキュリティ（ＴＬＳ）等のセキュリティプロトコルを介して、管理されるネットワーク３００のＶＰＮゲートウェイ４１２とピアリングされ得る。ファイアウォール４０４Ａは、ユーザ４１４及びリモートユーザ４１６等の許可されたユーザからのアクセスを可能にし、許可されていないユーザへのアクセスを拒否するように構成され得る。ファイアウォール４０４Ａを介して、これらのユーザは、計算インスタンス３２２、及び可能性として他の計算インスタンスにアクセスし得る。ロードバランサ４０６Ａは、計算インスタンス３２２をホストする１つ以上の物理又は仮想サーバデバイス間でトラフィックを分散するために使用され得る。ロードバランサ４０６Ａは、データセンタ４００Ａ（例えば、計算インスタンス３２２）の内部構成をクライアントデバイスから隠すことによってユーザアクセスを単純化し得る。実例として、計算インスタンス３２２が、複数のデータベースへのアクセスを共有する複数の物理的又は仮想コンピューティングデバイスを含む場合、ロードバランサ４０６Ａは、あるコンピューティングデバイス又はデータベースがその他よりも著しく多忙にならないように、ネットワークトラフィック及び処理タスクをこれらのコンピューティングデバイス及びデータベースに渡って分散し得る。幾つかの実施形態では、計算インスタンス３２２は、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、及びロードバランサ４０６Ａを含み得る。
データセンタ４００Ｂは、データセンタ４００Ａ内のコンポーネントの独自のバージョンを含み得る。したがって、ＶＰＮゲートウェイ４０２Ｂ、ファイアウォール４０４Ｂ、及びロードバランサ４０６Ｂは、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、及びロードバランサ４０６Ａと同じ又は同様の動作を夫々実施し得る。更に、リアルータイム又は凡そアルータイムのデータベースの複製及び／又はその他の動作を介して、計算インスタンス３２２は、データセンタ４００Ａ及び４００Ｂ内に同時に存在し得る。
図４に示すようなデータセンタ４００Ａ及び４００Ｂは、冗長性及び高可用性を容易にし得る。図４の構成では、データセンタ４００Ａはアクティブであり、データセンタ４００Ｂはパッシブである。したがって、データセンタ４００Ａは、管理されるネットワーク３００との間の全てのトラフィックに仕えているが、データセンタ４００Ｂ内の計算インスタンス３２２のバージョンは、凡そリアルータイムで更新されている。両方のデータセンタがアクティブな構成等、他の構成がサポートされ得る。
データセンタ４００Ａが何らかの方法で故障するか、さもなければユーザにとって利用不可能になった場合、データセンタ４００Ｂがアクティブなデータセンタとして引き継ぎ得る。例えば、計算インスタンス３２２のドメイン名をデータセンタ４００Ａの１つ以上のインターネットプロトコル（ＩＰ）アドレスと関連付けるドメイン名システム（ＤＮＳ）サーバは、ドメイン名をデータセンタ４００Ｂの１つ以上のＩＰアドレスと関連付け直し得る。この関連付け直しが完了した後（これには１秒又は数秒未満かかり得る）、ユーザは、データセンタ４００Ｂを介して計算インスタンス３２２にアクセスし得る。
図４はまた、管理されるネットワーク３００の可能な構成を説明する。上記のように、プロキシサーバ３１２及びユーザ４１４は、ファイアウォール３１０を通じて計算インスタンス３２２にアクセスし得る。プロキシサーバ３１２はまた、構成アイテム４１０にアクセスし得る。図４では、構成アイテム４１０は、クライアントデバイス３０２、サーバデバイス３０４、ルータ３０６、及び仮想マシン３０８の内の何れか又は全て、それらの上で実行する任意のアプリケーション又はサービス、並びにデバイス、アプリケーション、及びサービス間の関係の内の何れか又は全てを指し得る。したがって、用語“構成アイテム”は、任意の物理デバイス若しくは仮想デバイス、又は計算インスタンス３２２によりリモートで発見可能な又は管理される任意のアプリケーション若しくはサービス、又は発見されたデバイス、アプリケーション、及びサービス間の関係の省略表現であり得る。構成アイテムは、計算インスタンス３２２の構成管理データベース（ＣＭＤＢ）内で表され得る。
上記のように、ＶＰＮゲートウェイ４１２は、ＶＰＮゲートウェイ４０２Ａに、専用のＶＰＮを提供し得る。こうしたＶＰＮは、管理されるネットワーク３００と計算インスタンス３２２との間に大量のトラフィックがある場合、又はセキュリティポリシーがこれらのサイト間のＶＰＮの使用を提案する又は必要とする場合に役立ち得る。幾つかの実施形態では、ＶＰＮを介して直接通信する、管理されるネットワーク３００及び／又は計算インスタンス３２２内の任意のデバイスには、パブリックＩＰアドレスが割り当てられる。管理されるネットワーク３００及び／又は計算インスタンス３２２内の他のデバイスには、プライベートＩＰアドレス（例えば、サブネット１０．０．０．０／８及び１９２．１６８.０．０/１６として夫々省略表現で表される、１０．０．０．０～１０．２５５．２５５．２５５又は１９２．１６８.０．０～１９２．１６８.２５５．２５５の範囲から選択されるＩＰアドレス）が割り当てられ得る。
ＩＶ． デバイス、アプリケーション、及びサービス発見の例
リモートネットワーク管理プラットフォーム３２０が、管理されるネットワーク３００のデバイス、アプリケーション、及びサービスを管理するために、リモートネットワーク管理プラットフォーム３２０は、如何なるデバイスが管理されるネットワーク３００内に存在するか、これらのデバイスの構成及び動作ステータス、並びにデバイスにより提供されるアプリケーション及びサービス、並びに発見されたデバイス、アプリケーション、及びサービス間の関係をまず判定し得る。上記のように、各デバイス、アプリケーション、サービス、及び関係は、構成アイテムと称され得る。管理されるネットワーク３００内で構成アイテムを定義するプロセスは、発見と称され、プロキシサーバ３１２によって少なくとも部分的に容易にされ得る。
本明細書の実施形態の目的のために、“アプリケーション”は、１つ以上のプロセス、スレッド、プログラム、クライアントモジュール、サーバモジュール、又はデバイス若しくはデバイスのグループ上で実行する任意のその他のソフトウェアを指し得る。“サービス”は、相互に連携して働く１つ以上のデバイス上で実行する複数のアプリケーションによって提供される高レベルの能力を指し得る。例えば、高レベルのウェブサービスは、あるデバイス上で実行する複数のウェブアプリケーションサーバスレッドと、別のデバイスで実行するデータベースアプリケーションからのアクセス情報とを含み得る。
図５Ａは、構成アイテムがどのように発見され得るか、並びに発見された構成アイテムに関連する情報がどのように格納され得るかについての論理的描写を提供する。簡単にするために、リモートネットワーク管理プラットフォーム３２０、サードパーティネットワーク３４０、及びインターネット３５０は示されていない。
図５Ａでは、ＣＭＤＢ５００及びタスクリスト５０２は、計算インスタンス３２２内に格納される。計算インスタンス３２２は、発見コマンドをプロキシサーバ３１２へ送信し得る。応答において、プロキシサーバ３１２は、管理されるネットワーク３００内の様々なデバイス、アプリケーション、及びサービスへプローブを送信し得る。これらのデバイス、アプリケーション、及びサービスは、プロキシサーバ３１２へ応答を送信し得、プロキシサーバ３１２は、発見された構成アイテムに関する情報を、その中への格納のためにＣＭＤＢ５００にその後提供し得る。ＣＭＤＢ５００内に格納された構成アイテムは、管理されるネットワーク３００の環境を表す。
タスクリスト５０２は、プロキシサーバ３１２が計算インスタンス３２２に代わって実施する活動のリストを表す。発見が行われると、タスクリスト５０２はポピュレートされる。プロキシサーバ３１２は、タスクリスト５０２を繰り返し照会し、その中の次のタスクを取得し、タスクリスト５０２が空になる、又は別の停止条件に達するまで、このタスクを実施する。
発見を容易にするために、プロキシサーバ３１２は、プロキシサーバ３１２を介して到達可能な管理されるネットワーク３００内の１つ以上のサブネットに関する情報で構成され得る。実例として、プロキシサーバ３１２には、サブネットとしてＩＰアドレス範囲１９２.１６８．０／２４が与えられ得る。その後、計算インスタンス３２２は、この情報をＣＭＤＢ５００内に格納し得、これらのアドレスの各々でのデバイスの発見のためにタスクリスト５０２内にタスクを配置し得る。
図５Ａはまた、構成アイテム５０４、５０６、５０８、５１０、及び５１２として、管理されるネットワーク３００内のデバイス、アプリケーション、及びサービスを描写する。上記のように、これらの構成アイテムは、物理及び／又は仮想デバイス（例えば、クライアントデバイス、サーバデバイス、ルータ、又は仮想マシン）、それらの上で実行するアプリケーション（例えば、ウェブサーバ、電子メールサーバ、データベース、又はストレージアレイ）、それらの間の関係、並びに複数の個々の構成アイテムを含むサービスのセットを表す。
タスクをタスクリスト５０２内に配置することは、発見を発動し得、さもなければプロキシサーバ３１２に発見を開始させ得る。代替的又は追加的に、発見は、手動で発動され得、又は発動イベントに基づいて自動的に発動され得る（例えば、発見は、特定の時間に１日１回自動的に開始し得る）。
一般的に、発見は、スキャン、分類、識別、及び探索の４つの論理フェーズで進行し得る。発見の各フェーズは、プロキシサーバ３１２によって、管理されるネットワーク３００内の１つ以上のデバイスへ送信される様々なタイプのプローブメッセージを含む。これらのプローブへの応答は、プロキシサーバ３１２によって受信及び処理され得、その表現はＣＭＤＢ５００へ送信され得る。したがって、各フェーズは、より多くの構成アイテムが発見され、ＣＭＤＢ５００内に格納されることをもたらし得る。
スキャンフェーズにおいて、プロキシサーバ３１２は、デバイスの一般的なタイプを判定するために、オープンな伝送制御プロトコル（ＴＣＰ）及び／又はユーザデータグラムプロトコル（ＵＤＰ）ポートに対して、指定された範囲のＩＰアドレス内の各ＩＰアドレスを精査し得る。ＩＰアドレスにおけるこうしたオープンなポートの存在は、ＩＰアドレスが割り当てられるデバイス上で特定のアプリケーションが動作していることを指し示し得、このことは、順に、デバイスにより使用されるオペレーティングシステムを識別し得る。例えば、ＴＣＰポート１３５がオープンである場合、デバイスはＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムを実行している可能性がある。同様に、ＴＣＰポート２２がオープンである場合、デバイスはＬＩＮＵＸ（登録商標）等のＵＮＩＸ（登録商標）オペレーティングシステムを実行している可能性がある。ＵＤＰポート１６１がオープンである場合、デバイスは簡易ネットワーク管理プロトコル（ＳＮＭＰ）を通じて更に識別可能であり得る。他の可能性が存在する。特定のＩＰアドレスとそのオープンなポートとにおいてデバイスの存在が一旦発見されると、これらの構成アイテムはＣＭＤＢ５００内に保存される。
分類フェーズにおいて、プロキシサーバ３１２は、そのオペレーティングシステムのバージョンを判定するために、発見された各デバイスを更に精査し得る。特定のデバイスに対して使用されるプローブは、スキャンフェーズの間にデバイスについて収集された情報に基づく。例えば、ＴＣＰポート２２がオープンであるデバイスが見つかった場合、ＵＮＩＸ（登録商標）固有のプローブのセットが使用され得る。同様に、ＴＣＰポート１３５がオープンであるデバイスが見つかった場合、ＷＩＮＤＯＷＳ（登録商標）固有のプローブのセットが使用され得る。何れの場合にも、プロキシサーバ３１２が実行するために、タスクの適切なセットがタスクリスト５０２内に配置され得る。これらのタスクは、プロキシサーバ３１２がログオンすること、さもなければ特定のデバイスからの情報にアクセスすることをもたらし得る。実例として、ＴＣＰポート２２がオープンである場合、プロキシサーバ３１２は、特定のデバイスへのセキュアシェル（ＳＨＳ）接続を開始して、ファイルシステム内の特定の位置からその上のオペレーティングシステムについての情報を取得するように命令され得る。この情報に基づいて、オペレーティングシステムが判定され得る。例として、ＴＣＰポート２２がオープンであるＵＮＩＸ（登録商標）デバイスは、ＡＩＸ（登録商標）、ＨＰＵＸ、ＬＩＮＵＸ（登録商標）、ＭＡＣＯＳ（登録商標）、又はＳＯＬＡＲＩＳ（登録商標）として分類され得る。この分類情報は、１つ以上の構成アイテムとしてＣＭＤＢ５００内に格納され得る。
識別フェーズにおいて、プロキシサーバ３１２は、分類されたデバイスについての具体的詳細を判定し得る。このフェーズの間に使用されるプローブは、分類フェーズの間に特定のデバイスについて収集された情報に基づき得る。例えば、デバイスがＬＩＮＵＸ（登録商標）として分類された場合、ＬＩＮＵＸ（登録商標）固有のプローブのセットが使用され得る。同様に、デバイスがＷＩＮＤＯＷＳ（登録商標）２０１２として分類された場合、ＷＩＮＤＯＷＳ（登録商標）２０１２固有のプローブのセットとして使用され得る。分類フェーズの場合と同様に、プロキシサーバ３１２が実行するために、タスクの適切なセットがタスクリスト５０２内に配置され得る。これらのタスクは、ベーシック入力／出力システム（ＢＩＯＳ）情報、シリアル番号、ネットワークインターフェース情報、これらのネットワークインターフェースに割り当てられたメディアアクセス制御アドレス、及び特定のデバイスにより使用されるＩＰアドレス等の情報を特定のデバイスからプロキシサーバ３１２が読み出すことをもたらし得る。この識別情報は、１つ以上の構成アイテムとしてＣＭＤＢ５００内に格納され得る。
探索フェーズにおいて、プロキシサーバ３１２は、分類されたデバイスの動作状態についての更なる詳細を判定し得る。このフェーズの間に使用されるプローブは、分類フェーズ及び／又は識別フェーズの間に特定のデバイスについて収集された情報に基づき得る。この場合も、プロキシサーバ３１２が実行するために、タスクの適切なセットがタスクリスト５０２内に配置され得る。これらのタスクは、プロセッサ情報、メモリ情報、及び実行中のプロセス（アプリケーション）のリスト等の追加情報を特定のデバイスからプロキシサーバ３１２が読み出すことをもたらし得る。再度、発見された情報は、１つ以上の構成アイテムとしてＣＭＤＢ５００内に格納され得る。
ルータ等のネットワークデバイス上で発見を実行することは、ＳＮＭＰを利用し得る。実行中のプロセス又はその他のアプリケーション関連情報のリストを判定することの代わりに、又はそのことに加えて、発見は、ルータに認識されている追加のサブネットと、ルータのネットワークインターフェースの動作状態（例えば、アクティブ、非アクティブ、キューの長さ、ドロップしたパケット数等）とを判定し得る。追加のサブネットのＩＰアドレスは、更なる発見手順に対する候補であり得る。したがって、発見は、反復的又は再帰的に進行し得る。
発見が一旦完了すると、発見された各デバイス、アプリケーション、及びサービスのスナップショット表現がＣＭＤＢ５００内で利用可能である。例えば、発見後、管理されるネットワーク３００内のクライアントデバイス、サーバデバイス、及びルータに対するオペレーティングシステムのバージョン、ハードウェア構成、及びネットワーク構成の詳細、並びにそれらの上で実行するアプリケーションが格納され得る。この収集された情報は、デバイスのハードウェア構成及び動作ステータス、並びに複数のデバイスとアプリケーションとに及ぶサービスの特徴をユーザが見ることを可能にするように、様々な方法でユーザに提示され得る。
更に、ＣＭＤＢ５００は、構成アイテム間の依存性及び関係に関するエントリを含み得る。より具体的には、特定のサーバデバイス上で実行しているアプリケーション、及びこのアプリケーションに依存するサービスは、ＣＭＤＢ５００内でそのように表され得る。実例として、データベースアプリケーションがサーバデバイス上で実行していると仮定し、並びにこのデータベースアプリケーションが新入社員オンボーディングサービス及び給与サービスにより使用されると仮定する。したがって、サーバデバイスがメンテナンスのために動作を停止した場合、社員オンボーディングサービス及び給与サービスが影響を受けるであろうことは明らかである。同様に、構成アイテム間の依存性及び関係は、特定のルータが故障した場合に影響を受けるサービスを表すことが可能であり得る。
一般的に、構成アイテム間の依存性及び関係は、ウェブベースのインターフェース上に表示され得、階層的方法で表され得る。したがって、こうした依存性及び関係の追加、変更、又は削除は、このインターフェースを介して達成され得る。
更に、管理されるネットワーク３００からのユーザは、ある一定の調整された活動が複数の発見されたデバイスに渡って行われることを可能にするワークフローを開発し得る。実例として、ＩＴワークフローは、単一の動作で、全ての発見されたＬＩＮＵＸ（登録商標）デバイスに共通の管理者パスワードをユーザが変更することを可能にし得る。
上で説明した方法で発見が行われるために、プロキシサーバ３１２、ＣＭＤＢ５００、及び／又は１つ以上のクレデンシャルストアは、発見されるデバイスの内の１つ以上に対するクレデンシャルで構成され得る。クレデンシャルは、デバイスにアクセスするために必要な任意のタイプの情報を含み得る。これらは、ユーザＩＤ／パスワードの対及び資格証明書等を含み得る。幾つかの実施形態では、これらのクレデンシャルは、ＣＭＤＢ５００の暗号化されたフィールド内に格納され得る。プロキシサーバ３１２は、発見されているデバイスにログオンするため、さもなければアクセスするためにこれらのクレデンシャルをプロキシサーバ３１２が使用し得るように、クレデンシャルに対する復号化キーを含み得る。
発見プロセスは、図５Ｂにフローチャートとして描写されている。ブロック５２０において、計算インスタンス内のタスクリストは、実例として、ＩＰアドレスの範囲でポピュレートされる。ブロック５２２において、スキャンフェーズが行われる。したがって、プロキシサーバは、これらのＩＰアドレスを使用してデバイスに対するＩＰアドレスを精査し、これらのデバイス上で実行しているオペレーティングシステムの判定を試みる。ブロック５２４において、分類フェーズが行われる。プロキシサーバは、発見されたデバイスのオペレーティングシステムのバージョンの判定を試みる。ブロック５２６において、識別フェーズが行われる。プロキシサーバは、発見されたデバイスのハードウェア及び/又はソフトウェア構成の判定を試みる。ブロック５２８において、探索フェーズが行われる。プロキシサーバは、発見されたデバイス上で実行している動作状態及びアプリケーションの判定を試みる。ブロック５３０において、発見されたデバイス及びアプリケーションを表す構成アイテムの更なる編集が行われ得る。この編集は、本質的に自動化され得、及び/又は手動で行われ得る。
図５Ｂに表したブロックは、例示を目的とする。発見は、より多くの又はより少ないフェーズを有し得る高度に構成可能な手順であり得、各フェーズの動作は変更し得る。幾つかの場合、１つ以上のフェーズがカスタマイズされ得、さもなければ上記の例示的な説明から逸脱し得る。
Ｖ. ワークフローデザインツールの例
本明細書で論じられるリモートネットワーク管理プラットフォームの計算インスタンスは、それらの管理されるネットワークに代わってワークフローの仕様及び実行を可能にし得る。ワークフローは、実施される場合に１つ以上の目標を達成する特定のシーケンス又は一連のタスクである。幾つかの場合、ワークフローはフローチャートとして表され得、１つ以上の開始状態、中間状態、及び終了状態がそれらの間の様々な遷移によって接続される。幾つかの状態は、０回又は複数回滞在され得る。また、幾つかの状態は、１つよりも多い可能性のある次の状態を有し得、したがって、ユーザ入力、自動入力、データベース内に格納された情報に基づいて、又はその他のメカニズムを介して、ワークフローでなされる決定を表す。状態間の幾つかの遷移、入力の取得、又は出力の生成を引き起こすトリガーも定義され得る。
こうしたワークフローは、ソフトウェアベースのワークフロー設計ツールの使用を通じて計算インスタンス上に実装され得る。こうしたツールは、ワークフロー設計者に、ワークフローの状態、遷移、トリガー、アクション、入力データ、出力データ、及びその他の特徴を定義するためのオプションを提供する。ツールは、ＧＵＩを利用し得、計算インスタンス上に展開される一連の１つ以上のウェブページ及び／又はウェブベースのアプリケーションとして具体化され得る。一旦、完了して解放されると、管理されるネットワークの従業員は、組織化された効率的な方法で様々なタスクを実行するためにワークフローを使用し得る。特に、ワークフロー設計ツールは、所謂、“ローコード/ノーコード”ソリューションであり、設計者はワークフローを実装するためにプログラムコードを殆ど記述しないか、コードを全く記述しない。
本明細書の実施形態は、一般的なワークフロー設計のためのサポートを提供するが、例示的なワークフロー設計ツールは、トリガー、アクション、及びワークフローロジックの特定の定義に基づいて実装され得る。トリガーは、データベース内のエントリへの変更（例えば、ＣＭＤＢ内の構成アイテムの追加若しくは更新）等、又はスケジュール（例えば、１日１回又は週に１回）に従って、ワークフローを開始する条件を指定するために使用され得る。トリガーは、１つ以上のアクションを実施させ、各アクションは、実施されるアクションに対して真でなければならない条件を指定するワークフローロジックによって制御され得る。アクションは、データベース内の情報の状態を変更すること、及びユーザに通知（電子メール等）を送信すること等を含み得る。
幾つかの場合、サブフローが定義され得、ワークフローに組み込まれ得る。サブフローは、一連の再利用可能なアクションと、フロー、別のサブフロー、又はスクリプト内から開始可能にする特定のデータ入力とを含む、自動化又は半自動化されたプロセスであり得る。したがって、サブフローは複数のワークフローに適用され得る。
ワークフローの説明される例として、従業員が何らかの理由で企業を辞めた（例えば、従業員が退職した、解雇された、亡くなった等）、従業員のオフボーディングシナリオを考えてみる。ワークフローの目標は、（ｉ）退職した従業員により開かれた任意の保留中のカタログリクエスト（例えば、機器の要求）を検索してキャンセルすること、（ｉｉ）退職した従業員に割り当てられた開いているタスク（例えば、保留中の承認、達成される作業単位）を彼又は彼女のマネージャーに再割り当てすることである。様々な実施形態において、より多くの又はより少ない目標が存在し得る。
ワークフロー設計ツールは、設計者がワークフローを指定することを可能にする一連のＧＵＩページを設計者に提示し得る。こうしたページの例が図６Ａ～図６Ｊに示される一方、ワークフローの自動テストの結果が図６Ｋに示される。特に、これらの例は単に説明を目的としたものであり、限定することを意図しない。ワークフロー設計ツールは、ワークフローの設計に使用可能な情報の代替的配置を含む他のＧＵＩを提供することが可能であり得る。
図６ＡはＧＵＩ６００を描写する。ＧＵＩ６００の背景は、計算インスタンスによってサポートされる機構及び／又はアプリケーションを選択するためのウェブベースのメニューを示す。この背景は、ハッシュマーク等で示されている。
例えば、ＧＵＩ６００は、ユーザが検索用語“ｗｏｒｋｆｌｏｗ”を入力したダイアログボックス６０２を含む。このことは、メニュー６０４の下部からワークフロー設計ツールを選択する。この選択は、ＧＵＩ６００の上部に現れるテキスト“Ｗｏｒｋｆｌｏｗ Ｄｅｓｉｇｎｅｒ”に反映される。
ＧＵＩ６００はまた、ポップアップウィンドウ６０６を含む。或いは、ウィンドウ６０６は、別個のウィンドウではなく、ＧＵＩ６００の上にオーバーレイされたペインであり得る。それでも、ウィンドウ６０６は、ユーザがそのプロパティを指定することによって新たなワークフローの作成を開始することを可能にする。ＧＵＩ６００では、これらのプロパティは、ワークフローの名前“オフボーディング”、ワークフローのスコープアプリケーション“ユーザ管理”、ワークフローの説明“会社を辞めたユーザをオフボーディング”、及びワークフローが保護されるべきか否かである。代替的な実施形態では、より多くの又はより少ないプロパティが指定され得る。
ワークフローの名前は、ユーザにより入力される自由形式のテキストであり得る。ワークフローのスコープアプリケーションは、アプリケーションのドロップダウンメニューから選択され得、又はグローバルとして指定され得る。ＧＵＩ６００内のワークフローは“ユーザ管理”スコープアプリケーションに限定されているため、このワークフローはこのアプリケーションの一部とみなされ得る。ワークフローの説明もまた、自由形式のテキストであり得る。ワークフローの保護は、それが他のワークフロー設計者又はユーザによる変更可能（“なし”）であるか、それとも読み出し専用（“読み出し専用”）であるかを指定する。
ユーザがウィンドウ６０６内に入力された情報に一旦満足すると、ユーザは、“実行”ボタンを選択するか、さもなければ活性化し得る。この選択は、図６Ａでは、このボタンが破線で描写されることにより示されている。ユーザがウィンドウ６０６のダイアログを一旦完了すると、ユーザがトリガーを指定することを可能にするワークフロー設計ツールの次のフェーズが表示され得る。
図６Ｂは、ＧＵＩ６０８内のトリガー指定フェーズの第１の部分を描写する。ＧＵＩ６０８の上部は、ウィンドウ６０６内に入力されたように、ワークフローの名前“オフボーディング”を指定する。ＧＵＩ６０８のこのセクションは、このワークフローが現在ドラフト形式であり、“ユーザ管理”スコープアプリケーションの一部であることも指し示している。ＧＵＩ６０８は更に、ユーザがワークフローを夫々編集、テスト、コピー、保存、及び活性化することを可能にする一連のボタンを表示する。代替的実施形態では、ワークフローについての異なるタイプの情報が表示され得、潜在的に異なる機能を有するより多くの又はより少ないボタンがあり得る。
特に、読みやすくする目的のために、ＧＵＩ６０８（及び全ての更なるＧＵＩ）の背景からハッシュマークが省略されている。また、単語“Ｔｒｉｇｇｅｒ”は、トリガーが指定されていることを指し示すために通常の暗い色で表示され、単語“Ａｃｔｉｏｎ”は、アクション指定が行われていないことを指し示すために、より明るい色で示されている。
ポップアップウィンドウ６１０（ウィンドウ６０６と同様に、ＧＵＩ６０８の上にオーバーレイされたペインであり得、別個のウィンドウではなくてもよい）は、ユーザがワークフローに対するトリガーを指定することを可能にし得る。前述のように、２つの主要なタイプのトリガーがサポートされ得、これらのタイプはメニュー６１２内に示される。レコードベースのトリガーは、１つ以上の特定のデータベースレコードへの変更が発生した場合にワークフローを実施させ得る。メニュー６１２内に描写されているように、これらの変更は、レコードの作成、レコードの更新、レコードの作成又は更新、及びレコードの削除を含み得る。スケジュールされたトリガーは、ワークフローを１つ以上の指定された時間に実施させ得る。メニュー６１２に描写されるように、そうしたスケジュールは、ワークフローを毎日、毎週、毎月、（指定された時間に）一回だけ、又はユーザ指定の間隔で繰り返すように発動し得る。
図６Ｂにおいて、メニュー６１２は、レコードが更新された場合のトリガーをユーザが選択したことを破線で指し示している。このことは、選択されたトリガーの挙動を説明する情報ボックス６１４を表示させ得る。
図６Ｃは、ＧＵＩ６１６内のトリガー指定フェーズの第２の部分を描写する。ＧＵＩ６１６は、図６Ｂに示されている選択が完了していることを前提とする。したがって、ＧＵＩ６１６は、ポップアップウィンドウ６１８（ウィンドウ６０６と同様に、ＧＵＩ６１６の上にオーバーレイされたペインであり得、別個のウィンドウではなくてもよい）を描写し、それは、ユーザがワークフローに対するトリガーを更に指定することを可能にし得る。
ウィンドウ６１８は、幾つかのドロップダウンメニューを含み、その内の幾つかは、ＧＵＩ６０８からのユーザの選択に基づいて自動的にポピュレートされ得る。特に、トリガーメニュー６２０は、ユーザの“更新”オプションの選択を反映するためにポピュレートされ得、実行トリガーメニュー６３０は、レコードベースのトリガーが１回だけ実行されることが期待されることを反映するためにポピュレートされ得る。それにもかかわらず、ユーザは、ウィンドウ６１８内のこれらの選択を修正し得る。
テーブルメニュー６２２は、レコードを見つけ得るデータベーステーブルをユーザが指定することを可能にする。示されているように、このテーブルはｓｙｓ＿ｕｓｅｒであり、会社の従業員毎に１つのエントリが含まれていると想定されている。テーブルメニュー６２２は、１つ以上の利用可能なテーブルのリストを表示することが可能であり得る。
条件メニュー６２４、６２６、及び６２８は、ワークフローが実施させられるであろう、選択されたテーブル内のレコードの条件をユーザが指定することを可能にする。この条件は、状態又は遷移であり得る。実例として、条件メニュー６２４は、レコードがアクティブでなければならないことを示すために“アクティブ”を指定し、条件メニュー６２６は、アクティブから変化するレコードを示すために“から変更”を指定し、条件メニュー６２８は、アクティブから別の状態へ変化する任意のレコードを指し示すために“真”を指定する。
様々な実施形態において、条件メニュー６２４は、ｓｙｓ＿ｕｓｅｒテーブル内の様々なフィールドに対するエントリを含み得る。これらのフィールドは、電話番号、建物、都市、部門、住所、マネージャー、及び役割等を含み得る。条件メニュー６２６は、“である”、“ではない”、“空である”、“空ではない”、“何でもよい”、“と同じである”、“とは異なる”、“変更する”、”から変更する”、“に変更する”、及び/又はその他の様々な論理演算に対するエントリを含み得る。条件メニュー６２８は、条件メニュー６２４及び６２６に対してなされた選択に文脈的に基づくアイテムに対するエントリを含み得る。
全体として見ると、ウィンドウ６１８のトリガー指定は、ｓｙｓ＿ｕｓｅｒテーブル内の何れかのエントリがアクティブから別の状態（例えば、非アクティブ）に更新された場合にワークフローが１回実施されることを指し示す。このことは、ユーザが会社のアクティブな従業員ではなくなったことを指し示す。
図６Ｄは、ＧＵＩ６３２内のアクション指定の第１の部分を描写する。特に、６３４では、単語“Ｔｒｉｇｅｒ”には、図６Ｂ及び図６Ｃで指定されたトリガーの説明が付随する。更に、このテキストは、トリガーが指定されなくなったことを指し示すために灰色で表示される。
メニュー６３６に示されているように、ユーザは、アクション又はフローロジックを指定するオプションを有する。“アクション”ボタンの周りの破線は、アクションが指定されていることを指し示す。特に、メニュー６３６は、指定されているアクションに対する幾つかのコンテキストを表示する。例えば、“コア”アクションはデフォルトとして計算インスタンスによってサポートされる一方で、“グローバル”アクションは、全てのコアアクション、アプリケーションベースのアクション、及び統合ベースのアクションを含む。アプリケーションベースのアクション“Ａｐｐ１”、“Ａｐｐ２”、及び“Ａｐｐ３”は、リモートネットワーク管理プラットフォーム上に構築された個別のアプリケーションによってサポートされるアクションである。これらは、例えば、様々なタイプのＩＴサービス管理、ＩＴ動作管理、顧客サービス管理、セキュリティ動作、及びＣＲＭアプリケーションを含み得る。統合ベースのアクションは、リモートネットワーク管理プラットフォームと統合されたサードパーティアプリケーションによって定義又はサポートされるアクションを含む。これらは、例えば、仮想チャットアプリケーション及びメッセージングアプリケーション等を含み得る。これらの組み込み又はサードパーティアプリケーションの各々は、ワークフロー設計ツールがこれらのアプリケーションのデータ及び／又は機能を含むワークフローをサポートし得るように、ワークフロー設計ツールへのインターフェース（“スポーク”と称される）を明示的に公開し得る。
図６Ｄでは、ユーザは“コア”コンテキストを選択している。この選択に基づいて、サブメニュー６３８が表示される。このサブメニューは、“承認を要求”、“レコードを作成”、“タスクを作成”、“レコードを削除”、“ログ”、“レコードを検索”、“電子メールを送信”、“レコードを更新”、及び“条件を待機”等の幾つかの特定のアクションから選択する能力をユーザに提供する。これらから、ユーザは“レコードを検索”を選択している。したがって、選択されたアクションを説明する情報ボックス６４０が表示され得る。
図６Ｅは、ＧＵＩ６４２内のアクション指定の第２の部分を描写する。ポップアップウィンドウ６４４（ウィンドウ６０６と同様に、ＧＵＩ６４２の上にオーバーレイされたペインであり得、別個のウィンドウではなくてもよい）は、レコードを検索するテーブルと、これらのレコードが満たさなければならない条件とを指定することを可能にし得る。ウィンドウ６４４内に示すように、（図６Ｄで指定されるような）アクションは、レコードを検索することであり、この検索を実施するテーブルはｓｃ＿ｒｅｑｕｅｓｔ（ユーザによりなされるカタログリクエストを含むテーブル）である。ｓｃ＿ｒｅｑｕｅｓｔから返されるレコードは、“に対してリクエスト”フィールドがトリガーステップで識別されたユーザ（すなわち、アクティブステータスが変更されたユーザ）と一致するレコードである。
図６Ｅはまた、以前に定義されたトリガー並びに現在定義されているアクションに従って配列されたピル形状のユーザインターフェース要素（“ピル”）を含む列６４６を描写する。これらのピルは、点線の矢印により示されているように、列６４６から条件フィールド内の右端の選択可能なアイテム６４８にドラッグ可能である。このコンテキストでのユーザインターフェースピルは、典型的には、ワークフローで以前に指定されたデータを参照する楕円形のアイテムであり、このデータがワークフロー設計ツールで指定されると、ユーザインターフェース内に自動的に配置され得る。幾つかの実施形態では、（様々な形状の）ユーザインターフェースチップ又はタグが代わりに使用され得る。
特に、列６４６内の“トリガー”見出しの下にある２つのピルは、トリガーによって返されたユーザレコード（例えば、図６Ｃで指定されているようにアクティブから別の状態に変更されたｓｙｓ＿ｕｓｅｒ内のエントリ）と、トリガーが動作するテーブル（例えば、図６Ｃで指定されるようなｓｙｓ＿ｕｓｅｒ）とを指す。列６４６内の“アクション”見出しの下にある２つのピルは、図６Ｅで定義されているアクションによって見つけられたレコードと、これらのレコードが配置されているテーブル（例えば、ｓｃ＿ｒｅｑｕｅｓｔ）とを指す。
列６４６内のピル等のユーザインターフェース要素は、ワークフローで以前に指定又は参照されたデータ又はテーブルへの参照をユーザが簡単に含むことを可能にするため、ワークフローを指定するユーザにとって非常に便利である。このように、ユーザはこの情報への特定の参照を打ち込む必要はなく、代わりにピルをドラッグアンドドロップするだけで済む。
ユーザがウィンドウ６４４内に入力された情報に一旦満足すると、ユーザは“実行”ボタンを選択し得、さもなければ活性化し得る。この選択は、図６Ｅで、このボタンが破線で描写されていることにより示されている。ユーザがウィンドウ６４４のダイアログを一旦完了すると、ユーザがアクションに対するフローロジックを指定することを可能にするワークフロー設計ツールの次のフェーズが表示され得る。
図６Ｆは、ＧＵＩ６５０でのフローロジック指定を描写する。フローロジックはアクションに関連付けられ得、アクションの実行方法を指定する。特に、６５２では、単語“Ａｃｔｉｏｎ”には、図６Ｄ及び図６Ｅで指定されたアクションの説明が注釈として付けられている。
ポップアップウィンドウ６５４は、図６Ｄ及び図６Ｅで指定されたアクションによって返された幾つか又は全てのアイテム上でワークフローが動作するか否かの指定を可能にし得る。“フローロジック”ボタンは、アクションではなくフローロジックが指定されていることを示すために破線で描写されている。この場合、ウィンドウ６５４内でなされた選択は、図６Ｅで指定されたクエリから返された全てのアイテム上でワークフローが動作することを指し示す。特に、ウィンドウ６５４の“から”フィールド内の“１． [ｓｃ＿ｒｅｑｕｅｓｔ] ｒｅｃｏｒｄ”値は、フローロジックが６５２で指定されたアクション１の出力に適用されることを指し示す。特に、“から”フィールドの値は、ピルがそうしたピルを含む列からドラッグアンドドロップされることによりポピュレートされ得る。この列は、簡単にする目的のために図６Ｆには示されていないが、図６Ｅの列６４６に類似し得る。
ユーザがウィンドウ６５４内に入力された情報に一旦満足すると、ユーザは“実行”ボタンを選択し得、さもなければ活性化し得る。この選択は、図６Ｆで、このボタンが破線で描写されていることにより示されている。ユーザがウィンドウ６５４のダイアログを一旦完了すると、ユーザがフローロジックに対するサブアクションを指定することを可能にするワークフロー設計ツールの次のフェーズが表示され得る。
図６Ｇは、ＧＵＩ６５６でのサブアクション指定を描写する。特に、６５８では、単語“Ａｃｔｉｏｎ”には、図６Ｄ、図６Ｅ、及び図６Ｆで指定されたアクション及びフローロジックの更新された説明が付随する。更に、このテキストは、フローロジックが指定されなくなったことを指し示すために灰色で表示される。特に、サブアクション指定は、メニュー６３６とサブメニュー６３８とを再び表示し、今回は“コア”と“レコードを更新”とが選択されている。したがって、ＧＵＩ６５６は、図６Ｄ及び図６Ｅで定義されたアクションによって返されるアイテム毎にレコードが更新されるであろうことを指定するユーザを描写する。
図６Ｈは、ＧＵＩ６６０でのこのサブアクション指定を継続する。ポップアップウィンドウ６６２は、図６Ｆで指定されたフローロジックによって返されたアイテムについてアクションの指定が実行されることを可能にし得る。特に、ウィンドウ６６２に示されているオプションは、トリガーによって返されるｓｙｓ＿ｕｓｅｒテーブル内の各レコードに対して、同じユーザに対してリクエストされたｓｃ＿ｒｅｑｕｅｓｔテーブル内の何れのレコードも更新されるであろうことを指し示している。ユーザは、一致するレコードに対して更新される２つのフィールドも指定する。“リクエスト状態”フィールドは、退職した従業員の保留中のカタログリクエストをキャンセルするために、“閉鎖 キャンセル”に更新される。リクエストがキャンセルされた理由を指し示すために、“コメント”フィールドも“ユーザはシステムでアクティブではない”に更新される。
特に、“レコード”フィールドの値は、ピルがそうしたピルを含む列からドラッグアンドドロップされることによってポピュレートされ得る。この列は、簡単にする目的のために図６Ｈには示されていないが、図６Ｅの列６４６に類似し得る。
ユーザがウィンドウ６６２内に入力された情報に一旦満足すると、ユーザは“実行”ボタンを選択し得、さもなければ活性化し得る。この選択は、図６Ｈで、このボタンが破線で描写されていることで示されている。
図６Ｉは、これまでに定義されたワークフローを描写するＧＵＩ６６４を示す。６６６には、図６Ｄ、図６Ｅ、図６Ｆ、図６Ｇ、及び図６Ｈで指定されたアクションが表示される。それは、ステップ１（トリガーによって識別された従業員に対してリクエストされたｓｃ＿ｒｅｑｕｅｓｔテーブル内のレコードを検索すること）、２（これらのレコード毎に、ステップ/サブアクション２．１を実行すること）、及び２．１（それらを閉じて、適切なコメントを追加することによりこれらのレコードを更新すること）に分けられる。
上で紹介したように、残りの所望のワークフローは、退職した従業員に割り当てられた全てのタスクをその人のマネージャーに再割り当てすることも含む。この更なるステップは図６Ｊに描写されている。ある程度の繰り返しを避けるために、タスク再割り当てに対するアクション、フローロジック、及びサブアクションを指定するためのＧＵＩは省略されている。代わりに、図６Ｊは、完全なワークフローを示すために更新されたＧＵＩ６６４を描写する。
特に、ステップ３は、トリガーによって識別された従業員に割り当てられたタスクデータベーステーブル内のレコード（従業員によって実行されるタスクに対するエントリを含む）を検索する。ステップ４は、これらのレコードの各々に対して、ステップ/サブアクション４．１が実施されることを指し示すフローロジックを指定する。ステップ４．１は、ステップ４で識別された各レコードに対して、“に割り当て”フィールドが、識別された従業員のマネージャーに変更されることを指し示す。
このようにして、任意に複雑なフローチャート状のワークフローがデータ中心の方法で迅速に設計され得る。設計者は何れのコードも記述する必要がなく、適切なメニュー及びその他のインターフェース要素を用いて設計者を支援する一連のＧＵＩによってワークフロー指定を通じてガイドされる。その結果、設計者は大幅に時間を節約する。実際には、ワークフローは、高水準プログラミング言語（ＪＡＶＡ（登録商標）、ＪＡＶＡＳＣＲＩＰＴ（登録商標）、及びＣ＋＋等）でワークフローを手動でコーディングするために通常必要な日数ではなく、数時間で指定され得ることが実験で示されている。
このワークフロー設計ツールの別の利点は、展開前に同じＧＵＩによりワークフローをテスト可能であることである。図６ＫはＧＵＩ６６８を示し、それは、図６ＪのＧＵＩ６６０と同じ情報が含むが、そうしたテストの結果を反映する３つの列も含む。“状態”列は各ステップが完了したか否か（この例では全てのステップが完了している）を指し示し、“開始時刻”列は各ステップが開始した時刻を指し示し、“期間”列は各ステップの実施にかかったミリ秒単位での時間を指し示す。このことは、設計者が、各ステップが適切に実施されることを確認し、完了するまでに非常に長い時間がかかるステップを識別することを可能にする。代替的実施形態では、その他の情報が表示され得る。
図６Ａ～図６Ｋの例では、ワークフローが設計される。こうしたプロセスを実行するユーザペルソナは、ワークフロー設計者と称され得る。しかしながら、アクションは、アクション設計者のペルソナを有するユーザによって、類似した方法で（例えば、同様のＧＵＩを介して）設計され得る。したがって、アクション設計者は、公開され得るカスタムアクションを定義し得、公開されたアクションは、ワークフロー設計者によって選択されてワークフローに組み込まれ得る。
ＶＩ． リモートソフトウェアアプリケーションシステムの例
ソフトウェアベースのワークフロー設計ツールによって提供される統合ベースのアクションは、リモートネットワーク管理プラットフォームによって提供又は実行されないサードパーティアプリケーションによってサポートされるアクションも含み得る。こうしたソフトウェアアプリケーションは、リモートソフトウェアアプリケーションと称され得る。ワークフローは、そうした統合ベースのアクションを使用して、様々なリモートソフトウェアアプリケーションによって提供されるオブジェクト及び/又は関数と相互作用し得る。結果として、ワークフローは、（例えば、独立して開発及び／又は維持されなければならないソフトウェアアプリケーションの形式で）この機能を独立して実装する必要なしに、これらのリモートソフトウェアアプリケーションによって提供される機能を利用し得る。
特定のリモートソフトウェアアプリケーションとのこうした相互作用は、特定のリモートソフトウェアアプリケーションのためのインターフェース（すなわち、スポーク又は統合コネクタ）を集合的に構成する複数のアクションによって促進され得る。例えば、各アクションは、ワークフローが対応するオブジェクトと相互作用すること、及び／又はリモートソフトウェアアプリケーションの対応する関数を実行すること可能にし得る。幾つかの場合、ワークフローは、特定のリモートソフトウェアアプリケーションと直接通信し得る。すなわち、アクション設計ソフトウェアアプリケーションは、ワークフローが他のシステム（例えば、リモートソフトウェアアプリケーションシステム）の支援なしにリモートソフトウェアアプリケーションと相互作用し得るように、リモートソフトウェアアプリケーションのためのインターフェースを定義し得る。
他の場合では、しかしながら、ワークフローは、実行のために複数の異なるソフトウェアアプリケーションを公開するリモートソフトウェアアプリケーションシステムを利用し得る。すなわち、ワークフローはリモートソフトウェアアプリケーションシステムと相互作用し得、リモートソフトウェアアプリケーションシステムは、順に、ワークフローに代わって特定のリモートソフトウェアアプリケーションと相互作用する。幾つかの実装では、リモートソフトウェアアプリケーションシステムは、均一の又は標準化された方法でリモートソフトウェアアプリケーションの各々にアクセスするためのチャネル及び／又はプロセスを提供するように構成され得る。アクション設計ソフトウェアアプリケーションは、アプリケーション固有のインターフェースを定義することに伴う複雑さを軽減するために、この均一性を利用し得る。すなわち、対応するリモートソフトウェアアプリケーションと関連付けられた異なる標準、慣行、又は規則に各々が準拠する複数の異なるインターフェースを定義するのではなく、アクション設計ソフトウェアアプリケーションは、リモートソフトウェアアプリケーションシステムによって提供される均一性及び／又は標準化に準拠するインターフェースを定義し得る。
図７は、リモートソフトウェアアプリケーションシステムを介してアクセス可能なリモートソフトウェアアプリケーションを説明する。具体的には、図７は、リモートソフトウェアアプリケーション７００～７２０及びリモートソフトウェアアプリケーションシステム７４０～７６０を説明している。リモートソフトウェアアプリケーションシステム７４０は、リモートソフトウェアアプリケーション７００～７２０との相互作用を夫々可能にするＡＰＩ７４２～７５０を提供する。同様に、リモートソフトウェアアプリケーションシステム７６０は、他のリモートソフトウェアアプリケーション（図示せず）と相互作用するためのＡＰＩ７６２を提供する。リモートソフトウェアアプリケーションシステム７４０～７６０は、代替的に、リモートソフトウェアＡＰＩ管理システム、リモートソフトウェアＡＰＩ転送システム、又はリモートソフトウェアＡＰＩブリッジシステムと称され得る。
リモートソフトウェアアプリケーション７００～７２０の各々は、対応するコンピューティングシステムによってホスト及び実行され得る。一例では、リモートソフトウェアアプリケーション７００～７２０は、サードパーティネットワーク３４０内のコンピューティングデバイスによってホスト及び実行され得る。リモートソフトウェアアプリケーションシステム７４０～７６０は、リモートソフトウェアアプリケーション７００～７２０をホストするコンピューティングシステムとは異なり得、物理的に分離され得る。したがって、リモートソフトウェアアプリケーションシステム７４０～７６０は、実行のためにそれらの関数を公開するために、１つ以上のネットワークを介してリモートソフトウェアアプリケーション７００～７２０と通信し得る。リモートソフトウェアアプリケーションシステム７４０～７６０は、例えば、ＩＢＭ（登録商標）Ａｐｐ Ｃｏｎｅｎｅｃｔ、ＣＬＯＵＤＥ ＥＬＥＭＥＮＴＳ（登録商標）、又は他の同様のシステム若しくはプロバイダであり得る。特に、リモートソフトウェアアプリケーションシステム７４０～７６０は、リモートネットワーク管理プラットフォーム３２０及び管理されるネットワーク３００とは異なり得る。管理されるネットワーク３００は、（例えば、リモートネットワーク管理プラットフォーム３２０により提供されるワークフロー設計ソフトウェアアプリケーションを介して）リモートソフトウェアアプリケーション７００～７２０を実行するためにリモートソフトウェアアプリケーションシステム７４０～７６０を使用し得る。
リモートソフトウェアアプリケーション７００は、オブジェクト７０２～７０４と関数７０６～７０８及び７１０とを含む。関数７０６～７０８は、オブジェクト７０２と相互作用する（例えば、作成、削除、アクセス、及び／又は修正する）ように構成され得、関数７１０は、オブジェクト７０４と相互作用するように構成され得る。同様に、リモートソフトウェアアプリケーション７２０は、オブジェクト７２２～７２４と関数７２６～７２８及び７３０～７３２とを含み得る。関数７２６～７２８は、オブジェクト７２２と相互作用するように構成され得、関数７３０～７３２は、オブジェクト７２４と相互作用するように構成され得る。オブジェクト７０２～７０４及び７２２～７２４は、一般的に、その個別のリモートソフトウェアアプリケーションの動作に関連する情報を保持するように構成された任意のデータ構造又はその一部を表し得る。例えば、リモートソフトウェアアプリケーション７００は会計アプリケーションであり得る。したがって、オブジェクト７０２～７０４は、可能性の中でもとりわけ、会計、請求書、契約、顧客、従業員、見積もり、送り状、及びケースメッセージを含み得る。オブジェクト７０２が、例えば、送り状を表す場合、関数７０６～７０８は、可能性の中でもとりわけ、“送り状の作成”関数、“請求書の検索”関数、及び“請求書の修正”関数を含み得る。
ワークフロー、別のソフトウェアアプリケーション、又はコンピューティングデバイスは、それらの関数の実行をリクエストし、及び／又はそれらのオブジェクトと相互作用するために、リモートソフトウェアアプリケーション７００及び／又は７２０と直接（例えば、リモートソフトウェアアプリケーションシステム７４０を利用せずに）相互作用し得る。しかしながら、これらのアプリケーションがそうした相互作用のためにどのように構成されるかにおいて、リモートソフトウェアアプリケーション７００～７２０の間で違いがあり得る。例えば、リモートソフトウェアアプリケーションは、可能性のある違いの中でもとりわけ、その関数を呼び出すために使用される言語及び/若しくは構文、並びに/又はリモートソフトウェアアプリケーションがそれを介してアクセス可能な通信チャネル（例えば、コマンドラインインターフェース対ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ（ＲＥＳＴ）ＡＰＩ）が異なり得る。したがって、リモートソフトウェアアプリケーション７００～７２０の各々に対してアクション設計ソフトウェアアプリケーションにより個別の直接インターフェースを生成するプロセスは、アプリケーション固有であり得、したがって、複雑で時間がかかり得る。
しかしながら、特に、リモートソフトウェアアプリケーションシステム７４０は、リモートソフトウェアアプリケーション７００～７２０の各々と相互作用する方法を標準化し得るＡＰＩ７４２～７５０を提供し、アクション設計ソフトウェアアプリケーションが、均一なプロセスを介して複数の異なるリモートソフトウェアアプリケーションのためのインターフェースを生成することを可能にする。すなわち、ＡＰＩ７４２は、関数７０６～７０８及び７１０と夫々相互作用するためのＡＰＩ関数７４４～７４６及び７４８を含む。同様に、ＡＰＩ７５０は、関数７２６～７２８及び７３０～７３２と夫々相互作用するためのＡＰＩ関数７５２～７５４及び７５６～７５８を含む。ＡＰＩ７４２～７５０の各々の実装は、その個別のリモートソフトウェアアプリケーションの特定の標準、プロセス、及び／又は規則を説明し得、それらに従って動作し得る。しかしながら、ＡＰＩ７４２～７５０を識別する方法、それらのＡＰＩ関数を識別する方法、及び／又はＡＰＩ７４２～７５０と相互作用する方法は、ＡＰＩに渡って類似し得る。ＡＰＩ７４２～７５０及び７６２は、したがって、リモートソフトウェアアプリケーション７００～７２０の間の任意のバリエーションを秘匿し得、削除し得、及び／又は取るに足らないものにし得、それによって、これらのリモートソフトウェアアプリケーションのためのインターフェースの定義を容易にする。
例えば、ＡＰＩ７４２～７５０及び７６２は、ワークフローがハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエスト及び応答を介して通信し得るＲＥＳＴ ＡＰＩであり得る。また、図８Ａ～図８Ｅに関してより詳細に論じられるように、ＡＰＩ７４２～７５０及び７６２の各々は、アクション設計ソフトウェアアプリケーションがそのためのインターフェースを定義することを可能にする対応するＡＰＩ仕様によって説明され得る。リモートソフトウェアアプリケーション７００～７２０はそうした仕様を提供しないことがあり、したがって、（例えば、手動で定義する必要があることによって）インターフェースの定義をより困難にさせる。
特定のリモートソフトウェアアプリケーションがワークフローに統合される場合、ワークフローは、リモートソフトウェアアプリケーションシステム７４０を介してオブジェクト及び／又はその関数と相互作用し得る。すなわち、ワークフローは、第１のリクエストを、例えば、ＡＰＩ７４２へ送信し得る。第１のリクエストは、例えば、ＡＰＩ関数７４８が実行されることを指定し得る。したがって、リモートソフトウェアアプリケーションシステム７４０は、ＡＰＩ関数７４８を実行し得、それは、リモートソフトウェアアプリケーション７００へ、（順に、オブジェクト７０４と相互作用する）関数７１０の実行のための第２のリクエストを送信することを含む。第２のリクエストは、リモートソフトウェアアプリケーション７００の任意のアプリケーション固有の規則、プロセス、及び／又は標準に準拠する第１のリクエストの再フォーマット化されたバージョンであり得る。
アプリケーション７００は、関数７１０を実行し、出力を生成し得、それは、リモートソフトウェアアプリケーションシステム７４０へ送信され得る。リモートソフトウェアアプリケーションシステム７４０は、第１のリクエストに応答してワークフローへ送信される応答内にこの出力を含み得る。したがって、リモートソフトウェアアプリケーションシステム７４０は、ワークフローが、リモートソフトウェアアプリケーション７００と直接通信することなく、及びリモートソフトウェアアプリケーション７００の規則、プロセス、及び／又は標準に準拠するインターフェースを生成することなく、リモートソフトウェアアプリケーション７００の関数及びオブジェクトを利用することを可能にし得る。
幾つかの実装では、リモートソフトウェアアプリケーションシステム７４０は、数十、数百、又は数千のリモートソフトウェアアプリケーションの実行を提供し得、それらの各々は、対応するインターフェースを介してワークフローに統合可能であり得る。特に、これらのインターフェースの各々は、個々のリモートソフトウェアアプリケーションへの直接インターフェースではなく、リモートソフトウェアアプリケーションシステム７４０の対応するＡＰＩへのインターフェースであり得る。リモートソフトウェアアプリケーションシステム７４０は、リモートソフトウェアアプリケーションの関数を識別及び実行する標準化された均一な方法を提供し得るので、アクション設計ソフトウェアアプリケーションによってこれらのインターフェースを生成するプロセスは、直接インターフェースを生成するプロセスよりも単純であり得る。
ＶＩＩ． ＡＰＩ仕様の例
リモートソフトウェアアプリケーションシステム７４０～７６０は、ＡＰＩ７４２～７５０及び７６２の個別のＡＰＩ毎に、個別のＡＰＩの属性を定義する対応する１つ以上の仕様を提供するように構成され得る。これらの仕様は、ＡＰＩの態様の中でもとりわけ、ワークフローがＡＰＩと通信する方法、ＡＰＩを介して相互作用し得るオブジェクト、各ＡＰＩが実行のために公開する関数、各関数の入力、及び各関数の出力を指し示し得る。仕様はまた、各リモートソフトウェアアプリケーションシステムによって提供される異なるＡＰＩ、及びＡＰＩにアクセスするために使用され得るサービス識別子（例えば、ユーザカウント）を識別し得る。仕様は、したがって、アクション設計ソフトウェアアプリケーションがＡＰＩ毎に、その結果、これらのＡＰＩを介して公開されるリモートソフトウェアアプリケーション毎にインターフェースを自動的に生成することを可能にし得る。
図８Ａ、図８Ｂ、図８Ｃ、図８Ｄ、及び図８Ｅは、特定のリモートソフトウェアアプリケーションのためのインターフェースを構成するアクションを定義するために、アクション設計ソフトウェアアプリケーションにより使用され得る例示的な仕様の抜粋８００、８０２、８０４、８０６、及び８０８（すなわち、抜粋８００～８０８）を夫々説明する。ＡＰＩ仕様は、リモートソフトウェアアプリケーションシステム７４０～７６０によって開発及び提供され得る。仕様の抜粋８００～８０８は、抜粋８００の１行目に指し示されているように、ＯＰＥＮＡＰＩ仕様標準の第３バージョン（３.０．０）に従って記述される。ＯＰＥＮＡＰＩ仕様は、ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ（ＲＥＳＴ）ＡＰＩを説明するためのフォーマットを定義する。しかしながら、特に、アクション設計ソフトウェアアプリケーションは、ＲＥＳＴと関連付けられているもの以外の標準、プラットフォーム、プロセス、規則、又はプロトコル（例えば、ＧＲＡＰＨＱＬ、ＯＤＡＴＡ）に従って構築されたＡＰＩ、及びＯＰＥＮＡＰＩ以外のＡＰＩ仕様フォーマット（例えば、ＲＡＭＬ）をサポートするように構成され得る。
ＡＰＩ仕様は階層的に構造化され得、この階層は、タグ及びそれらの個別の値のインデント又はネストを介して指し示され得る。例えば、図８Ａの３行目のタグ“ＴＩＴＬＥ”、４行目の“ＤＥＳＣＲＩＰＴＩＯＮ”、６行目の“ＶＥＲＳＩＯＮ”は、２行目のタグ“ＩＮＦＯ”に対してインデントされていることが示され、したがって、親タグ“ＩＮＦＯ”の子である。こうした階層構造は、リモートソフトウェアアプリケーションシステムとそれらのＡＰＩとの異なる属性をその中で識別するように、アクション設計ソフトウェアアプリケーションによるＡＰＩ仕様の解析を容易にする。特に、抜粋８００～８０８はＹＡＭＬ Ａｉｎ‘ｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＹＡＭＬ）で記述されることが示されているが、抜粋８００～８０８は、代替的に、例えば、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）等の別のフォーマットで記述され得る。
仕様は、２行目に指し示されるように、リモートソフトウェアアプリケーションシステム、そのＡＰＩ、ＡＰＩ関数、及び/又はＡＰＩ関数が相互作用するオブジェクトの一般的な書誌情報（例えば、メタデータ）を提供し得る。この一般的な情報は、３行目に“Ａｖａｉｌａｂｌｅ Ｒｅｍｏｔｅ ｓｏｆｔｗａｒｅ ａｐｐｌｉｃａｔｉｏｎｓ（利用な可能なリモートソフトウェアアプリケーション）“として指し示される仕様のタイトル、４行目に“Ｓｐｅｃｉｆｉｅｓ ｒｅｍｏｔｅ ｓｏｆｔｗａｒｅ ａｐｐｌｉｃａｔｉｏｎｓ ｅｘｐｏｓｅｄ ｆｏr ｅｘｅｃｕｔｉｏｎ ｂｙ ｔｈｅ ｒｅｍｏｔｅ ｓｏｆｔｗａｒｅ ａｐｐｌｉｃａｔｉｏｎ ｓｙｓｔｅｍ（リモートソフトウェアアプリケーションシステムによる実行のために公開されるリモートソフトウェアアプリケーションを指定）”として指し示される仕様の又はＡＰＩの目的の説明、及び６行目に１．０．５として指し示されるＡＰＩのバージョンを含み得る。特に、対応するインターフェースは、ＡＰＩのバージョン毎に、又は少なくともＡＰＩへの重大な変更を伴うバージョン毎に定義され得る。重大な変更は、可能性の中でもとりわけ、その入力、その出力、入力及び/若しくは出力のフォーマットを変更する、又は関数を削除するものであり得る。
仕様は、８行目に指し示されるように、リモートソフトウェアアプリケーションシステム及び/又はそのＡＰＩと関連付けられた１つ以上のサーバを更に指し示し得る。具体的には、１つ以上のサーバは、これらのサーバをアドレッシングする、対応するベースユニフォームリソースロケーター（ＵＲＬ）によって指し示され得る。図８Ａの例では、仕様のこのセクションは、利用可能なＡＰＩの各々、したがって、リモートソフトウェアアプリケーションシステムによる実行のために公開されたリモートソフトウェアアプリケーションの各々を識別するために使用され得る。すなわち、第１のリモートソフトウェアアプリケーション、Ａｐｐｌｉｃａｔｉｏｎ １（例えば、リモートソフトウェアアプリケーション７００）のためのＡＰＩ（例えば、ＡＰＩ７４２）は、９行目及び１０行目に指し示されるように、ＵＲＬ“ＨＴＴＰ：／／ＡＰＰ＿１．ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ”によりアドレッシングされ得る。同様に、第２のリモートソフトウェアアプリケーション、Ａｐｐｌｉｃａｔｉｏｎ ２のためのＡＰＩは、１１行目及び１２行目に指し示されているように、ＵＲＬ“ＨＴＴＰ：//ＡＰＰ＿２．ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ”によりアドレッシングされ得る。
抜粋８００は、１３行目の省略記号により指し示されているように、リモートソフトウェアアプリケーションシステムによる実行のために公開された追加のリモートソフトウェアアプリケーションを指し示し得る。例えば、リモートソフトウェアアプリケーションシステムは、合計１０個のリモートソフトウェアアプリケーションを公開し得、第３～第９のアプリケーションは抜粋８００に示されていない。第１０のリモートソフトウェアアプリケーション、Ａｐｐｌｉｃａｔｉｏｎ １０（例えば、リモートソフトウェアアプリケーション７２０）のためのＡＰＩ（例えば、ＡＰＩ７５０）は、１４行目及び１５行目に指し示されているように、ＵＲＬ“ＨＴＴＰ：／／ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ／ＡＰＰ＿１０”によりアドレッシングされ得る。特に、第１０のリモートソフトウェアアプリケーションの例では、アプリケーションは、“ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ”ドメインのサブドメインとしてではなく、リソースパスパラメータ（すなわち、“／ＡＰＰ＿１０”）として指定される。抜粋８００は、したがって、リモートソフトウェアアプリケーションシステムを介した実行に利用可能なリモートソフトウェアアプリケーションのリストを指し示し得る。
幾つかの場合、仕様は、アプリケーション毎に複数のＵＲＬを指し示し得る。例えば、Ａｐｐｌｉｃａｔｉｏｎ １のテスト目的で使用されるステージングサーバは、追加のＵＲＬ“ＨＴＴＰ：//ＳＴＡＧＩＮＧ＿ＡＰＰ＿１．ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ”によりアドレッシングされ得る。幾つかの実装では、アクション設計ソフトウェアアプリケーションは、各ＡＰＩによって公開される特定のＡＰＩ関数、したがって個別のリモートソフトウェアアプリケーションの関数及びオブジェクトを定義する追加の仕様を取得するために、ベースＵＲＬを使用し得る。或いは、仕様は、これらの追加の仕様がそれを介して取得され得る追加のＵＲＬを提供し得る。
アクション設計ソフトウェアアプリケーションがリモートソフトウェアアプリケーションのためのインターフェースを定義する場合、抜粋８００に示されているベースＵＲＬは、個別のサーバデバイスにＡＰＩの関数を呼び出させるパラメータをその中に含むように修正され得る。そのために、図８Ｂ、図８Ｃ、及び図８Ｄは、Ａｐｐｌｉｃａｔｉｏｎ １の例示的な関数に対するパラメータをその中に指し示すＡｐｐｌｉｃａｔｉｏｎ １の仕様の抜粋を説明する。すなわち、仕様は、ＡＰＩの特定の関数にアクセスするためにＵＲＬに如何なるパラメータが含まれ得るかと、これらのパラメータをどのように含まれるかを指し示し得る。
図８Ｂの抜粋８０２は、この仕様が３行目に指し示されているように“Ａｐｐｌｉｃａｔｉｏｎ １ Ｆｕｎｃｔｉｏｎｓ”というタイトルであること、及び仕様が４行目及び５行目に指し示されているように“Ｓｐｅｃｉｆｉｅｓ ｔｈｅ ｆｕｎｃｔｉｏｎｓ ｏｆ Ａｐｐｌｉｃａｔｉｏｎ １ ｔｈａｔ ｃａｎ ｂｅ ｅｘｅｃｕｔｅｄ ｂｙ ｗａｙ ｏｆ ｔｈｅ ｒｅｍｏｔｅ ｓｏｆｔｗａｒｅ ａｐｐｌｉｃａｔｉｏｎ ｓｙｓｔｅｍ（リモートソフトウェアアプリケーションシステムを介して実行され得るＡｐｐｌｉｃａｔｉｏｎ １の関数を指定）”であることを指し示している。７、８、及び９行目で、抜粋８０２は、Ａｐｐｌｉｃａｔｉｏｎ １の関数及びオブジェクトとの相互作用するために使用されるＡＰＩを実行するように構成されたサーバデバイスに対するベースＵＲＬを再度指し示す。
抜粋８０２は、１１行目に、ＡＰＩのＦＵＮＣＴＩＯＮ＿１にアクセスするためにベースＵＲＬに追加され得るＵＲＬリソースパス及びリソースパスパラメータをも指し示す。１３行目に指し示されるようなＨＴＴＰ ＧＥＴリクエストを１２行目に指し示されているような“ＨＴＴＰ：／／ＡＰＰ＿１．ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ／ＦＵＮＣＴＩＯＮ＿１/｛ＩＮＰＵＴ＿１｝”へ送信することによって、ワークフローは、そのための入力としてＩＮＰＵＴ＿１を用いてＦＵＮＣＴＩＯＮ＿１のＡＰＩの実行をリクエストし得る。この場合、“ＦＵＮＣＴＩＯＮ＿１／｛ＩＮＰＵＴ＿１｝”はリソースパスを表す一方、“ＩＮＰＵＴ＿１”に代入される値はリソースパスパラメータを表す。特に、抜粋８０２の１６行目は、“ＩＮＰＵＴ＿１”の値が別のタイプのパラメータとしてではなく、リソースパスパラメータとして提供されることを指定している。
抜粋８０２は更に、１８行目により指し示されているように“ＩＮＰＵＴ＿１”の値がＦＵＮＣＴＩＯＮ＿１の実行に必要な入力であることを指定している。２０行目は“ＩＮＰＵＴ＿１”のスキーマ又は構造及び属性を指し示す。すなわち、“ＩＮＰＵＴ＿１”は、整数データ型であり、２１行目及び２２行目により夫々指し示されているように、最小値は１である。したがって、ＩＮＰＵＴ＿１の値が“５”を有するＦＵＮＣＴＩＯＮ＿１の実行をリクエストするために、ワークフローは、ＨＴＴＰリクエストを“ＨＴＴＰ：／／ＡＰＰ＿１．ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ／ＦＵＮＣＴＩＯＮ＿１／５”へ送信し得る。一例では、ＦＵＮＣＴＩＯＮ＿１は、ＩＤ又は他の識別子の値が“５”であるオブジェクトを返すように構成され得る。しかしながら、特に、ＡＰＩ関数は、幅広い範囲の動作を実施し得、関数の入力及び出力に対する例示的な名前は、したがって、コンテキストに基づいて変更され得る。
抜粋８０２は、２３行目に指し示されているように、ＡＰＩが送信し、ワークフローがＨＴＴＰリクエストに応答して受信し得るＨＴＴＰ応答の属性をも定義する。すなわち、ある可能な応答は“ＨＴＴＰ２００ ＯＫ”標準応答コードを表す“２００”であり、それは、成功したリクエスト及び応答を指し示す。別の可能な応答は、“ＨＴＴＰ４０４ ＮＯＴ ＦＯＵＮＤ”標準応答コードを表す“４０４”であり、それは、ＩＮＰＵＴ＿１に対する提供された値を用いてＦＵＮＣＴＩＯＮ＿１を実行しても、何ら出力が生成されなかった（例えば、一致するデータベースエントリが見つからなかった）ことを指し示す。
“４０４”応答は、ステータスコード自体以外の追加情報を含まないことがあるが、“２００”応答は、２５～３６行目で指定されるように、特定のフォーマットで編成されたＦＵＮＣＴＩＯＮ＿１の出力をも含み得る。すなわち、応答は、ＯＵＴＰＵＴ＿１に対する整数値、ＯＵＴＰＵＴ＿２に対する文字列値、及びＯＵＴＰＵＴ＿３に対する文字列値を含むＪＳＯＮオブジェクトを含み得る。したがって、２６～３６行目は、ＦＵＮＣＴＩＯＮ＿１が相互作用するオブジェクトの構造を指し示す。このように、抜粋８０２は、一般的に、対応するＡＰＩ関数がどのように振る舞い、どのオブジェクトと相互作用するかをアクション設計ソフトウェアアプリケーションに通知し、それによって、この関数を呼び出すアクションを定義することを可能にし、その出力を後続のアクションで利用することを可能にする。
図８Ｃは、２つのリソースパスパラメータとクエリパラメータとを入力として受け入れるＡＰＩの第２の関数を定義するＡＰＩ仕様の抜粋８０４を説明する。１～２行目に指し示されているように、第２の関数は、ＨＴＴＰ ＧＥＴリクエストを“ＨＴＴＰ：／／ＡＰＰ＿１．ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ／ＦＵＮＣＴＩＯＮ＿２/｛ＩＮＰＵＴ＿２｝/｛ＩＮＰＵＴ＿３｝”へ送信することによって呼び出される。ＡＰＩは、（ｉ）５～１０行目に指し示されるような整数パスパラメータ“ＩＮＰＵＴ＿２”、（ｉｉ）１１～１５行目に指し示されるような文字列パスパラメータ“ＩＮＰＵＴ＿３”、（ｉｉｉ）１６～２０行目に指し示されるような文字列クエリパラメータ“ＩＮＰＵＴ＿４”、及び（ｉｖ）１６～２２行目に指し示されるような整数クエリパラメータ“ＩＮＰＵＴ＿５”を入力として受け取ることを想定している。
クエリパラメータは、以下のフォーマット：“ＨＴＴＰ：／／ＥＸＡＭＰＬＥ．ＣＯＭ／ＲＥＳＯＵＲＣＥ＿ＰＡＴＨ？ＫＥＹ＿１＝ＶＡＬＵＥ＿１＆ＫＥＹ＿２＝ＶＡＬＵＥ＿２”においてＵＲＬの末尾に付け加えられたキー及び値のペアである。したがって、抜粋８０４は、ＩＮＰＵＴ＿２＝１０、ＩＮＰＵＴ＿３＝“ＡＣＴＩＶＥ”、ＩＮＰＵＴ＿４＝“ＭＡＲＫ”、及びＩＮＰＵＴ＿５＝１５を有するＦＵＮＣＴＩＯＮ２の実行に対するリクエストが“ＨＴＴＰ：／／ＡＰＰ＿１．ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ／ＦＵＮＣＴＩＯＮ＿２／１０／ＡＣＴＩＶＥ？ＩＮＰＵＴ＿４＝ＭＡＲＫ＆ＩＮＰＵＴ＿５＝１５”にアドレッシングされるべきであることを指定している。ＦＵＮＣＴＩＯＮ＿２は、例えば、（非アクティブではなく）“ＡＣＴＩＶＥ”であるグループ“１０”内の、ファーストネームが“ＭＡＲＫ”であるユーザを返すように構成され得、結果の最大数を１５に限定し得る。
特に、仕様は、必要のない幾つかの入力に対するデフォルト値を指し示し得る。したがって、クエリパラメータ“ＩＮＰＵＴ＿５”に対しては、抜粋８０４は、２２行目でこの入力がオプション（すなわち、ＲＥＱＵＩＲＥＤ：ＦＡＬＳＥ）であることを指し示し、２５行目は、この入力に対する値が提供されていない場合、デフォルト値の２０がそれに割り当てられることを指し示す。抜粋８０２と同様に、抜粋８０４はまた、ＦＵＮＣＴＩＯＮ２によって返される可能性のある応答（図示せず）を指し示し得る。
図８Ｄは、リソースパスパラメータ、ＨＴＴＰヘッダーパラメータ、及びＨＴＴＰクッキーパラメータを入力として受け入れるＡＰＩの第３の関数を定義する仕様の抜粋８０６を説明する。ＡＰＩのこの第３の例示的関数は、１～３行目に指し示されているように、リソースパス“／ＦＵＮＣＴＩＯＮ＿３／｛ＩＮＰＵＴ＿６｝”により識別され得る。第３の関数は、５～１０行目に指し示されるような整数リソースパスパラメータ“ＩＮＰＵＴ＿６”と、１１～１６行目に指し示されるようなユニバーサルユニーク識別子（ＵＵＩＤ）としてフォーマット化された文字列として提供されるＨＴＴＰヘッダーパラメータ“ＩＮＰＵＴ＿７”と、１７～２２行目に指し示されるような０又は１の何れかの値を有する整数として提供されるＨＴＴＰクッキーパラメータ“ＩＮＰＵＴ＿８”とを入力として必要とし得る。第３の関数は、対応するＨＴＴＰ応答内に含まれる出力を生成し得る。この出力は、抜粋８０２に示したものと同様の方法でＡＰＩ仕様によって指し示され得る。
図８Ｅは、特定のＡＰＩ関数が相互作用するオブジェクトを指し示すための代替的なフォーマットを説明する。すなわち、抜粋８０８は、ＨＴＴＰリクエストを“ＨＴＴＰ：／／ＡＰＰ＿１．ＲＥＭＯＴＥ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＹＳＴＥＭ．ＣＯＭ／ＦＵＮＣＴＩＯＮ＿４”へ送信することによってＡｐｐｌｉｃａｔｉｏｎ １のＦＵＮＣＴＩＯＮ＿４が呼び出され得ることを指定している。３～９行目は、ＦＵＮＣＴＩＯＮ＿４が生成するように構成される応答を指し示す。すなわち、ＦＵＮＣＴＩＯＮ＿４はオブジェクトＯＢＪＥＣＴ＿４を返す。このオブジェクトの構造は、ＦＵＮＣＴＩＯＮ＿４に対する“ＲＥＳＰＯＮＳＥ”セクションの一部として直接定義されるのではなく、仕様の“ＣＯＭＰＯＮＥＮＴＳ”セクション内で定義され得る。すなわち、１２～２２行目は、ＯＢＪＥＣＴ＿４が整数値を格納するように構成されたＦＩＥＬＤ＿１、文字列値を格納するように構成されたＦＩＥＬＤ＿２、及び整数値を格納するように構成されたＦＩＥＬＤ＿３で構成されることを指し示している。
このように、仕様は、（ｉ）ＡＰＩを介して相互作用され得るオブジェクト、（ｉｉ）ＡＰＩを介して実行され得る関数、及び（ｉｉｉ）オブジェクトと関数との間の関係を別個に定義し得る。抜粋８０２（関数の一部として定義されるオブジェクト）と８０８（独立して定義されるオブジェクト及び関数）とにより説明されるオブジェクトを定義するための規則は両方とも有効であるが、抜粋８０８は、仕様の“＄ＲＥＦ”セクションの明確な使用に起因して、アクション設計ソフトウェアアプリケーションが複数の関数を単一のオブジェクトに、より簡単かつ明確に関連付けることを可能にし得る。
ＡＰＩ仕様は、ＡＰＩの他の複数の可能な態様を更に定義し得る。例えば、ＡＰＩ仕様は、可能性の中でもとりわけ、ＡＰＩが従う認証標準又は手順、ＡＰＩの関数への入力として提供され得又はＡＰＩの関数からの出力として受け取られ得る他の様々なメディアタイプ（例えば、ＸＭＬ、フォームデータ、ポータブルドキュメントフォーマット（ＰＤＦ）、及び様々な画像フォーマット）、非推奨の関数、シリアル化された方法でＡＰＩにパラメータを提供する（例えば、複数の値を単一のキーに関連付けるクエリパラメータを提供する）ためのオプション、ＡＰＩの１つ以上の関数によって使用されるコールバックＵＲＬ、リンク、及び仕様拡張を定義し得る。例えば、ＯＰＥＮＡＰＩ３．０．０の場合、ＡＰＩ仕様は、ＯＰＥＮＡＰＩ仕様標準で提供されている、及び/又はＡＰＩによって利用されているＡＰＩの任意の他の態様を定義し得る。
例えば、これら又はその他の仕様は、特定のＡＰＩで使用され得るサービス識別子（例えば、ユーザカウント）を定義するために使用され得る。一例では、リモートソフトウェアアプリケーションに対応する各ＡＰＩは、その仕様内に、そのＡＰＩの関数のアクセス及び実行を許可するために使用可能なサービス識別子のリストを含み得る。或いは、各個別のサービス識別子は、個別のサービス識別子を使用することによって相互作用され得る関数及びオブジェクトを定義する異なる仕様と関連付けられ得る。このようにして、各サービス識別子は、各ＡＰＩ及び対応するリモートソフトウェアアプリケーションの関数及びオブジェクトの様々なサブセットと相互作用することを可能にされ得る。
特に、抜粋８０２～８０８により説明されているＡＰＩ関数は、説明の目的のために単純化されている。ＡＰＩ仕様は、しかしながら、抜粋８０２～８０８に示されているよりも非常に多くの異なるタイプの入力を受け入れ、非常に多くの異なるタイプの出力を生成する関数を定義し得る。
ＶＩＩＩ． インターフェース設計及びワークフロー設計動作の例
図９Ａは、リモートソフトウェアアプリケーションのためのインターフェースを定義することに関連する動作のメッセージ図を説明する。インターフェースは、リモートソフトウェアアプリケーションシステムのＡＰＩの１つ以上の関数の実行を呼び出す複数のアクションで構成され得る。ＡＰＩのこれらの関数は、順に、リモートソフトウェアアプリケーションの対応する関数の実行を呼び出す。インターフェースは、したがって、リモートソフトウェアアプリケーションシステムを介してリモートソフトウェアアプリケーションの関数を実行するために、ワークフローによって使用され得る。
具体的には、図９は、アクション設計ソフトウェアアプリケーション９００、永続ストレージ９０２、及びリモートソフトウェアアプリケーションシステム７４０を説明する。アクション設計ソフトウェアアプリケーション９００は、代替的に、ソフトウェアベースのアクション設計ツール、アクション定義ソフトウェアアプリケーション、又はアクション設計ソフトウェアアプリケーションと称され得る。永続ストレージ９０２は、幾つかの実装では、データベースの形式をとり得る。一例では、アクション設計ソフトウェアアプリケーション９００及び永続ストレージ９０２は、リモートネットワーク管理プラットフォーム３２０の計算インスタンス（例えば、計算インスタンス３２２）に配備され得、又はその一部を形成し得る。この計算インスタンスは、管理されるネットワーク３００に割り当てられ得、したがって、そのためのインターフェース及びワークフローを定義するために使用され得る。リモートソフトウェアアプリケーションシステム７４０は、アクション設計ソフトウェアアプリケーション９００によって定義されるアクションの１つ以上によって呼び出されるＡＰＩを提供及び維持するコンピューティングシステムであり得る。したがって、アクション設計ソフトウェアアプリケーションは、インターネット等のネットワークを介してリモートソフトウェアアプリケーションシステム７４０と通信し得る。
アクション設計ソフトウェアアプリケーション９００は、ブロック９０７によって指し示されるように、リモートソフトウェアアプリケーションシステムに対するサービス識別子を取得することによってインターフェースの定義を開始し得る。サービス識別子は、ユーザ名とパスワードとの組み合わせ、ウェブトークン（例えば、ＪＳＯＮウェブトークン）、又はアクション設計ソフトウェアアプリケーション９００がリモートソフトウェアアプリケーションシステム７４０のコンテンツに接続してアクセスすることを可能にする別の形式のクレデンシャルであり得る。サービス識別子はまた、リモートソフトウェアアプリケーションシステムをアドレッシングし、サービス識別子が対応するＵＲＬを含み得、又はそれと関連付けられ得、したがって、アクション設計ソフトウェアアプリケーション９００がリモートソフトウェアアプリケーションシステムと通信することを可能にする。
したがって、サービス識別子は、アクション設計ソフトウェアアプリケーション９００が、様々なリモートソフトウェアアプリケーションがワークフローにそれを介してアクセス可能なリモートソフトウェアアプリケーションシステムを識別することを可能にし得る。幾つかの場合、このサービス識別子はまた、リモートソフトウェアアプリケーションシステム７４０のＡＰＩにアクセスするためにワークフローによって使用可能であり得る。或いは、アクション設計ソフトウェアアプリケーション９００によって使用されるサービス識別子は、ワークフローによって使用可能なサービス識別子とは異なり得る。
ブロック９０７においてサービス識別子を取得することに基づいて、又はそれに応答して、アクション設計ソフトウェアアプリケーション９００は、矢印９０８によって指し示されるように、リモートソフトウェアアプリケーションシステム７４０に、利用可能なリモートソフトウェアアプリケーションの識別をリクエストするように構成され得る。利用可能なリモートソフトウェアアプリケーションは、リモートソフトウェアアプリケーションシステム７４０が、これらのアプリケーションのオブジェクト及び関数と相互作用するために使用され得るＡＰＩを提供するアプリケーションであり得る。矢印９０８でのリクエストに基づいて、又はそれに応答して、リモートソフトウェアアプリケーションシステム７４０は、矢印９１０によって指し示されるように、利用可能なリモートソフトウェアアプリケーションの識別子を提供するように構成され得る。一例では、識別子は、図８Ａに示されるものによく似た仕様の形式をとり得、利用可能な各リモートソフトウェアアプリケーションは、そのためのＡＰＩをホストするサーバの対応するＵＲＬによって識別される。他の例では、識別子は、例えば、利用可能なリモートソフトウェアアプリケーションの名前のリスト又はアレイとしてを含む、他の方法で提供され得る。
矢印９１０での識別子の受信に基づいて、又はそれに応答して、アクション設計ソフトウェアアプリケーション９００は、ブロック９１２によって指し示されるように、インターフェースが定義される特定のリモートソフトウェアアプリケーションをそこから選択するように構成され得る。幾つかの実装では、この選択は自動的であり得る。例えば、アクション設計ソフトウェアアプリケーション９００は、インターフェースがまだ定義されていない特定のリモートソフトウェアアプリケーションを選択し得る。他の実装では、選択は、ユーザによってなされた選択に少なくとも部分的に基づき得る。例えば、アクション設計ソフトウェアアプリケーション９００は、利用可能なリモートソフトウェアアプリケーションがそれを介して表示され、特定のリモートソフトウェアアプリケーションがそこから選択されるグラフィカルユーザインターフェースを提供し得る。
ブロック９１２での特定のリモートソフトウェアアプリケーションの選択に基づいて、又はそれに応答して、アクション設計ソフトウェアアプリケーション９００は、矢印９１４によって指し示されるように、リモートソフトウェアアプリケーションシステム７４０へ、特定のリモートソフトウェアアプリケーションに対するサービス識別子に対するリクエストを送信するように構成され得る。これらのサービス識別子は、ブロック９０７で取得されるものとよく似ており、ユーザ名とパスワードとの組み合わせ、ウェブトークン、又はその他の認証クレデンシャルを含み得る。これらのサービス識別子は、ワークフローがリモートソフトウェアアプリケーションシステム７４０により提供されるＡＰＩ及び／又はリモートソフトウェアアプリケーションと相互作用することを可能にし得る。すなわち、サービス識別子は、その関数を実行する前に、ＡＰＩによって及び／又はリモートソフトウェアアプリケーションによってリクエストされ得る。
サービス識別子は、ワークフローが相互作用可能であり得る関数及びオブジェクトの範囲を定義し得る。すなわち、幾つかのサービス識別子（例えば、管理者アカウントと関連付けられているもの）は、他のサービス識別子（例えば、非管理者ユーザと関連付けられているもの）よりも非常に多くのリモートソフトウェアアプリケーション、関数、及び/又はオブジェクトへのアクセスを可能にし得る。
矢印９１４でのリクエストの受信に基づいて、又はそれに応答して、リモートソフトウェアアプリケーションシステム７４０は、矢印９１６によって指し示されるように、リクエストされたサービス識別子をアクションデザインソフトウェアアプリケーション９００へ送信するように構成され得る。一実装では、サービス識別子は、ＡＰＩ仕様の形式で（例えば、その“ＳＥＣＵＲＩＴＹ”セクションで）提供され得る。他の実装では、サービス識別子は、リスト、アレイ、又はその他のデータ構造として提供され得る。
アクション設計ソフトウェアアプリケーション９００はまた、矢印９１８によって指し示されるように、特定のリモートソフトウェアアプリケーションの仕様をリクエストするように構成され得る。図８Ａ～図８Ｅに関して論じたように、仕様は、リモートソフトウェアアプリケーションシステム７４０を介して特定のリモートソフトウェアアプリケーションの関数を呼び出し、オブジェクトと相互作用するための標準、プロセス、及びその他の規則を定義し得る。特に、仕様の一部は、特定のリモートソフトウェアアプリケーションが動作するように構成されている方法（例えば、リモートソフトウェアアプリケーションの関数により必要とされる入力）によって決定され得る一方、別の部分は、リモートソフトウェアアプリケーションシステム７４０がワークフローに代わって特定のリモートソフトウェアアプリケーションと相互作用する方法（例えば、リモートソフトウェアアプリケーションシステム７４０のＡＰＩが動作する方法）によって決定され得る。
矢印９１８でのリクエストの受信に基づいて、又はそれに応答して、リモートソフトウェアアプリケーションシステム７４０は、矢印９２０によって指し示されるように、リクエストされた仕様をアクション設計ソフトウェアアプリケーション９００へ送信するように構成され得る。特に、幾つかの実装では、矢印９１４及び９１６の動作は、矢印９１８及び９２０の動作と夫々組み合わされ得る。これは、例えば、特定のリモートソフトウェアアプリケーションの仕様が、特定のリモートソフトウェアアプリケーションにアクセスするために使用可能なサービス識別子もその中に定義している場合であり得る。
矢印９１６でのサービス識別子及び／又は矢印９２０での仕様の受信に基づいて、又はそれに応答して、アクション設計ソフトウェアアプリケーション９００は、特定のリモートソフトウェアによりワークフローに公開され又は利用可能にされるオブジェクト及び関数を判定するように構成され得る。具体的には、仕様は、（ｉ）特定のリモートソフトウェアアプリケーションを介してアクセス可能な１つ以上のオブジェクト、及び（ｉｉ）１つ以上のオブジェクトと相互作用するために呼び出し可能な特定のリモートソフトウェアアプリケーションの複数の関数を判定するために、アクション設計ソフトウェアアプリケーション９００により使用され得る。例えば、仕様の抜粋８０２～８０８の場合、オブジェクトは、オブジェクトの中でもとりわけ、ＯＵＴＰＵＴ＿１～ＯＵＴＰＵＴ＿３（図８Ｂの２９～３６行目）及びＯＢＪＥＣＴ＿４（図８Ｅの１４～２２行目）で構成されるオブジェクトを含み得る。関数は、ＦＵＮＣＴＩＯＮ＿１（図８Ｂの１２行目）、ＦＵＮＣＴＩＯＮ＿２（図８Ｃの１行目）、ＦＵＮＣＴＩＯＮ＿３（図８Ｄの１行目）、及びＦＵＮＣＴＩＯＮ＿４（図８Ｅの１行目）を含み得る。
ブロック９２２でのオブジェクト及び関数の判定に基づいて、又はそれに応答して、アクション設計ソフトウェアアプリケーション９００は、ブロック９２４によって指し示されるように、特定のリモートソフトウェアアプリケーションのためのインターフェースを定義する複数のアクションを生成するように構成され得る。複数のアクションの各個別のアクションは、実行される場合に、リモートソフトウェアアプリケーションシステム７４０へリクエストを送信することによって、複数の関数の内の１つ以上の対応する関数の実行を呼び出すように構成され得る。リモートソフトウェアアプリケーションシステム７４０は、順に、このリクエストの修正バージョンを特定のリモートソフトウェアアプリケーションへ送信し得、特定のリモートソフトウェアアプリケーションは、リクエストで指定された任意の入力に従って１つ以上の対応する関数を実行し得る。リモートソフトウェアアプリケーションシステム７４０は、特定のリモートソフトウェアアプリケーションから、１つ以上の対応する関数の出力をその後受け取り得、それは、個別のアクションに戻され得る。したがって、個別のアクションは、リクエストに応答して、及びリモートソフトウェアアプリケーションシステムを介して、１つ以上の対応する関数の出力を受け取り得る。
各個別のアクションは、（ｉ）１つ以上の対応する関数の入力に対応する入力変数、及び（ｉｉ）１つ以上の対応する関数の出力に対応する出力変数を含むように定義され得る。入力変数は、ワークフローの実行中にリモートソフトウェアアプリケーションシステム７４０へ送信されるリクエストのパラメータ（例えば、ＵＲＬリソースパスパラメータ、ＵＲＬクエリパラメータ、ＨＴＴＰヘッダーパラメータ、ＨＴＴＰボディパラメータ、及び/又はＨＴＴＰクッキーパラメータ）にマッピングされ得る。したがって、個別のアクションが実行される場合、入力変数の値は、このマッピングに従ってリクエスト内に含まれ得る。同様に、出力変数は、リモートソフトウェアアプリケーションシステム７４０からの応答（例えば、そのＡＰＩ）の一部にマッピングされ得る。したがって、リモートソフトウェアアプリケーションシステム７４０からの応答の受信は、１つ以上の対応する関数の出力の値を応答から抽出させ得、この第２のマッピングに従って出力変数内に格納させ得る。
ブロック９２４でのアクションの生成に基づいて、又はそれに応答して、アクション設計ソフトウェアアプリケーション９００は、矢印９２６によって指し示されるように、永続ストレージ９０２内へのインターフェースの定義の格納をリクエストするように構成され得る。矢印９２６でのリクエストの受信に基づいて、又はそれに応答して、永続ストレージ９０２は、ブロック９２８によって指し示されるように、インターフェースの定義をその中に格納するように構成され得る。格納されたインターフェースは、その後、インターフェースのアクションの内の１つ以上を組み込む１つ以上のワークフローを定義するために、ワークフロー設計ソフトウェアアプリケーションにより検索され得る。幾つかの実装では、アクション設計ソフトウェアアプリケーション９００はまた、インターフェース又はアクションの第１のサブセットをアクティブとして指定し、第２のサブセットを非アクティブとして指定するように構成され得る。そうした指定は、例えば、アクション設計ソフトウェアアプリケーション９００のユーザインターフェースを介して提供される手動選択に基づき得る。アクティブなアクション及び/又はインターフェースは、ワークフロー設計ソフトウェアアプリケーションを介したワークフローへの統合に利用可能であり得るが、非アクティブなアクション及び/又はインターフェースは、この目的には利用可能ではないことがある。
したがって、図９Ｂは、リモートソフトウェアアプリケーションのインターフェースを利用するワークフローを定義することに関係する動作のメッセージ図を説明している。すなわち、ワークフロー設計ソフトウェアアプリケーション９０６は、アクション設計ソフトウェアアプリケーション９００により定義されたインターフェースの１つ以上のアクションを含むワークフローを定義するように構成され得る。ワークフロー設計ソフトウェアアプリケーション９０６は、代替的に、ソフトウェアベースのワークフロー設計ツール、ワークフロー定義ソフトウェアアプリケーション、又はワークフロー設計ソフトウェアアプリケーションと称され得る。一例では、ワークフロー設計ソフトウェアアプリケーション９０６は、リモートネットワーク管理プラットフォーム３２０の計算インスタンス（例えば、計算インスタンス３２２）内に配備され得、又はその一部を形成し得る。例えば、ワークフロー設計ソフトウェアアプリケーション９０６及びアクション設計ソフトウェアアプリケーション９００は、１つのソフトウェアパッケージ又はシステムの一部であり得る。
ワークフロー設計ソフトウェアアプリケーション９０６は、矢印９３０によって指し示されるように、永続ストレージ９０２に、リモートソフトウェアアプリケーション９５０のインターフェースの定義をリクエストするように構成され得る。幾つかの場合、矢印９３０でのリクエストは、インターフェースの全体（例えば、インターフェースを構成する全てのアクション）ではなく、インターフェースの１つ以上のアクションの形式を取り得る。このリクエストは、例えば、ワークフローを定義する過程の間にワークフロー設計ソフトウェアアプリケーション９０６により提供されるユーザインターフェースを介したインターフェース又はそのアクションの選択に応答して生成され得る。矢印９３０でのリクエストの受信に基づいて、又はそれに応答して、永続ストレージ９０２は、矢印９３２によって指し示されるように、インターフェースの定義を検索し、それをワークフロー設計ソフトウェアアプリケーション９０６に提供するように構成され得る。
幾つかの実装では、アクション設計ソフトウェアアプリケーション９００は、インターフェースの定義の各々を定期的にリフレッシュするように構成され得る。すなわち、アクション設計ソフトウェアアプリケーション９００は、仕様の更新されたバージョンを取得し、オブジェクト及び／又は関数を識別及び変更し、更新されたインターフェースを生成するために影響を受ける任意のアクションを更新するように構成され得る。したがって、幾つかの場合、矢印９３２で取得された定義は、最初の生成以降に１回以上更新されたインターフェースのバージョンを表し得る。
代替的又は追加的に、幾つかの場合、ワークフロー設計ソフトウェアアプリケーション９０６による永続ストレージ９０２からの特定のインターフェース定義の検索は、インターフェースの更新を発動し得る。すなわち、永続ストレージが矢印９３２において定義を提供する前に、永続ストレージ９０２は、この特定のインターフェースがワークフローに統合されるようにリクエストされている指標をアクション設計ソフトウェアアプリケーション９００へ送信し得る。この指標に基づいて、又はそれに応答して、アクション設計ソフトウェアアプリケーション９００は、このインターフェースに対応するリモートソフトウェアアプリケーション９５０に対する更新された仕様を取得し、更新された仕様に基づいてオブジェクト及び／又は関数の任意の変更を識別し、これらの変更に基づいて更新されたインターフェースを生成するように構成され得る。アクション設計ソフトウェアアプリケーション９００は、永続ストレージ９０２内へのこの更新されたインターフェースの定義の格納をその後リクエストし得る。永続ストレージ９０２は、したがって、ワークフロー設計ソフトウェアアプリケーション９０６に、古くなった出力を提供するのではなく、矢印９３２で更新されたインターフェースの定義を提供し得る。
矢印９３２での定義の受信に基づいて、又はそれに応答して、ワークフロー設計ソフトウェアアプリケーション９０６は、ブロック９３４によって指し示されるように、その中にインターフェースを統合するワークフローを定義するように構成され得る。そうしたワークフローは、それによって提供される対応するオブジェクトと相互作用するために、リモートソフトウェアアプリケーション９５０の特定の関数の実行を呼び出すようにインターフェースの１つ以上のアクションを使用し得る。インターフェースの１つ以上のアクションは、ワークフローの他の部分によって判定された入力値として受信され得、これらのアクションの出力がワークフローの更に別の部分で使用されることを可能にし得る。したがって、リモートソフトウェアアプリケーション９５０は実際には他のリモートコンピューティングシステムによって実行され得るが、リモートソフトウェアアプリケーション９５０のインターフェースは、ワークフローがリモートソフトウェアアプリケーション９５０をワークフローと一緒にローカルで実行されたかのように扱うことを可能にし得る。
ブロック９３４でのワークフローの定義及び／又はワークフロー内で指定された特定のトリガーの発生に基づいて、又はそれに応答して、ワークフロー定義アプリケーション９０６（又は別のソフトウェアアプリケーション）は、ブロック９３６により指し示されるように、ワークフローを実行するように構成され得る。ワークフローの実行がリモートソフトウェアアプリケーション９５０のインターフェースのアクションに到達した場合、ワークフロー設計ソフトウェアアプリケーション９０６は、矢印９３８によって指し示されるように、リモートソフトウェアアプリケーションシステム７４０へ、リモートソフトウェアアプリケーション９５０の関数の実行に対するリクエストを送信するように構成され得る。リクエストは、対応するアクションによって決定されるように、その中に関数に対する入力値を含み得る。
矢印９３８でのリクエストの受信に基づいて、又はそれに応答して、リモートソフトウェアアプリケーションシステム７４０は、ブロック９４０によって指し示されるように、矢印９３８でのリクエストによって指定されたＡＰＩ関数を実行するように構成され得る。このＡＰＩ関数の実行は、リクエスト９３８をリモートソフトウェアアプリケーション９５０と互換性のあるフォーマット又は状態に変換し得る。一例では、リモートソフトウェアアプリケーション９５０が図７のリモートソフトウェアアプリケーション７００に対応すると仮定すると、矢印９３８でのリクエストは、ＡＰＩ７４２のＡＰＩ関数７４４を指定し得、したがって、関数７０６の実行を遂行するために、リモートソフトウェアアプリケーションシステム７４０にＡＰＩ関数７４４を実行させる。特に、矢印９３８で関数が指定される方法は、リモートソフトウェアアプリケーションシステム７４０が、利用可能なリモートソフトウェアアプリケーションの属性を定義するために提供する仕様をどのように構造化及び／又はフォーマット化するかに依存し得る。
ブロック９４０での対応するＡＰＩ関数の実行は、矢印９４２によって指し示されるように、リモートソフトウェアアプリケーションシステム７４０に、ワークフローに統合された関数の実行に対するリクエストをリモートソフトウェアアプリケーション９５０へ送信させ得る。矢印９４２でのリクエストの受信に基づいて、又はそれに応答して、リモートソフトウェアアプリケーション９５０は、ブロック９４４によって指し示されるように、指定された関数を実行するように構成され得る。ブロック９４４での関数の実行に基づいて、又はそれに応答して、リモートソフトウェアアプリケーション９５０は、矢印９４６によって指し示されるように、リモートソフトウェアアプリケーションシステム７４０に関数の出力を提供するように構成され得る。
矢印９４６での関数の出力の受信に基づいて、又はそれに応答して、リモートソフトウェアアプリケーションシステム７４０は、矢印９４８によって指し示されるように、ワークフロー設計ソフトウェアアプリケーション９０６に、関数の出力を含む応答を提供するように構成され得る。特に、矢印９３８でのリクエストは、矢印９４２でのリクエストとフォーマットが異なり得るため、矢印９４８での応答は、同様に、矢印９４６での応答とは異なるフォーマットを含み得る。異なるフォーマット間のこの変換は、リモートソフトウェアアプリケーションシステム７４０によって提供される対応するＡＰＩ関数によって処理され得る。矢印９４８での応答の受信に基づいて、又はそれに応答して、ワークフロー設計ソフトウェアアプリケーション９０６は、ブロック９４９によって指し示されるように、関数の出力に基づいてワークフローを実行し続け得る。特に、ワークフローは、リモートソフトウェアアプリケーション９５０の他の関数及び／又はリモートソフトウェアアプリケーションシステム７４０を介して提供される他のリモートソフトウェアアプリケーションの他の関数を呼び出し得る。
ＩＸ． ワークフローの例
図１０は、ワークフロー１０００の概略的表現を説明する。ワークフロー１０００は、リモートソフトウェアアプリケーションの関数を呼び出すインターフェースアクション１０６０と、リモートソフトウェアアプリケーションの機能を呼び出さないことがあるアクション１００８及び１０４０とがその中に統合されて含む。アクション１０６０、１００８、及び１０４０の変数は、ワークフロー１０００を通るデータの例示的な流れを説明するために相互接続されて示されている。特に、幾つかの実装では、ワークフロー１０００は、省略記号で指し示されるような追加のアクション、又はより少ないアクションを含み得る。アクションがワークフローに統合されている、及び/又は統合されることを意図している場合、アクションは、代替的に、ワークフローアクションと称され得る。
アクション１００８は、入力変数１０１０、１０１２、及び１０１４を含む。ワークフロー１０００の実行の間、アクション１００８の入力変数１０１０、１０１２、及び１０１４には、入力値１００２、１００４、及び１００６が夫々割り当てられる。入力値１００２、１００４、及び１００６は、可能性の中でもとりわけ、ワークフロー１０００における他のアクションの出力、ユーザ入力、又はデータベースから検索されたデータを表し得る。アクション１００８は、出力変数１０１６、１０１８、及び１０２０を更に含み、それらの各々は、アクション１００８によって定義されたロジックに従って処理された入力値１００２、１００４、又は１００６の内の１つ以上を表す。例えば、出力変数１０２０は、データベースから検索され、入力値１００２（例えば、｛ラストネーム｝、｛ミドルネームのイニシャル｝、｛ファーストネーム｝として本来フォーマット化された名前）としてアクション１００８に提供される文字列の修正されたバージョン（例えば、｛ファーストネーム｝、｛ラストネーム｝として再フォーマット化された名前）を格納し得る。出力変数１０１６、１０１８、及び１０２０は、インターフェースアクション１０６０の入力変数１０２４、１０２６、及び１０２８に夫々接続され、したがって、これらの変数の値がワークフローを通じてどのように伝播されるかを指し示す。
インターフェースアクション１０６０は、入力変数１０２４、１０２６、及び１０２８の値に基づいてＡＰＩクエリ１０２９を生成するように構成される。ＡＰＩクエリ１０２９は、インターフェースアクション１０６０に対応するリモートソフトウェアアプリケーションの仕様によって定義された規則に従って生成され得る。ＡＰＩクエリ１０２９は、ＡＰＩクエリ１０２９によって呼び出される特定のリモートアプリケーションシステム及びこの特定のリモートアプリケーションシステムに対応する認証クレデンシャルを識別するのを支援する接続エイリアスを含むように生成され得る。接続エイリアスを使用することによって、システム固有の接続情報は、アクション（例えば、アクション１０６０）の定義から切り離され得、したがって、アクションが例えば、複数の異なる認証クレデンシャルを使用することを可能にする。ＡＰＩクエリ１０２９は、その対応するＡＰＩ関数の実行を呼び出すために、リモートソフトウェアアプリケーションシステム（例えば、７４０）へ送信される。ＡＰＩ関数は、順に、リモートソフトウェアアプリケーションの対応する関数の実行をリクエストし、そこからその出力を受け取る。
同様に、インターフェースアクション１０６０は、リモートソフトウェアアプリケーションシステムからＡＰＩ応答１０３０を受信するように構成される。ＡＰＩ応答１０３０は、その中に、ＡＰＩクエリ１０２９によって呼び出されるリモートソフトウェアアプリケーション関数の出力値を含む。これらの出力値は、インターフェースアクション１０６０によって、対応する出力変数１０３２、１０３４、及び１０３８にマッピングされる。
出力変数１０３２、１０３４、及び１０３８の値は、順に、アクション１０４０の入力変数１０４２、１０４４、及び１０４６に割り当てられ、伝播される。幾つかの場合、ＡＰＩ応答１０３０は、インターフェースアクション１０６０からアクション１０４０に渡されない出力値を含み得る。例えば、リモートソフトウェアアプリケーションからインターフェースアクション１０６０によって検索されたオブジェクトの幾つかの部分のみが、ワークフロー１０００の残余により使用され得る。アクション１０４０は、出力変数１０４８、１０５０、及び１０５２の出力値１０５４、１０５６、及び１０５８を夫々生成するために、入力変数１０４２、１０４４、及び１０４６を処理する。
したがって、インターフェースアクション１０６０のワークフローへの統合は、インターフェースアクション１０６０がアクション１００８の出力上で動作することを可能にし、アクション１０４０がインターフェースアクション１０６０の出力上で動作することを可能にする。言い換えれば、インターフェースアクション１０６０は、リモートソフトウェアアプリケーションの対応する関数が、アクション１００８及び１０４０と同じコンピューティングシステムの一部であるかのように呼び出されることを可能にする。また、インターフェースアクション１０６０は、アクション設計ソフトウェアアプリケーションによって自動的に定義され、ワークフロー１０００をプログラミングすることは、一般的に、アクション１０６０、１００８、及び１０４０の入力変数と出力変数との間の接続を定義することのみを含む。したがって、ワークフロー設計者は、インターフェースアクション１０６０によって呼び出されるＡＰＩ関数及び／又はリモートソフトウェアアプリケーション関数に関して、もしあれば、多くの詳細を知る必要がなくてもよい。
Ｘ. 動作例
図１１は、例示的な実施形態を説明するフローチャートである。図１１によって説明されるプロセスは、コンピューティングデバイス１００等のコンピューティングデバイス、及び／又はサーバクラスタ２００等のコンピューティングデバイスのクラスタによって実行され得る。しかしながら、プロセスは、他のタイプのデバイス又はデバイスサブシステムによって実行され得る。例えば、プロセスは、ラップトップ又はタブレットデバイス等のポータブルコンピュータによって実行され得る。
図１１の実施形態は、そこに示されている機構の内の何れか１つ以上を削除することによって簡略化され得る。更に、これらの実施形態は、以前の図の何れかの機構、態様、及び／又は実装と組み合わされ得、又は本明細書で他の方法で説明され得る。
ブロック１１００は、ワークフローへの統合のためのリモートソフトウェアアプリケーションの個別のインターフェースを定義するように構成されたアクション設計ソフトウェアアプリケーションによって、リモートソフトウェアアプリケーションが実行のためにそれを介して公開されるリモートソフトウェアアプリケーションシステムを識別することを含む。永続ストレージは、個別のインターフェースの定義を格納するように構成され得る。
ブロック１１０２は、アクション設計ソフトウェアアプリケーションによって、及びリモートソフトウェアアプリケーションシステムから、リモートソフトウェアアプリケーションの内の特定のリモートソフトウェアアプリケーションの属性を定義する仕様を取得することを含む。
ブロック１１０４は、アクション設計ソフトウェアアプリケーションによって、及び仕様に基づいて、（ｉ）特定のリモートソフトウェアアプリケーションを介してアクセス可能な１つ以上のオブジェクト、及び（ｉｉ）１つ以上のオブジェクトと相互作用するために呼び出し可能な特定のリモートソフトウェアアプリケーションの複数の関数を判定することを含む。
ブロック１１０６は、アクション設計ソフトウェアアプリケーションによって、特定のリモートソフトウェアアプリケーションのためのインターフェースを定義する複数のアクションを生成することを含む。複数のアクションの各個別のアクションは、実行される場合に、（ｉ）リモートソフトウェアアプリケーションシステムへリクエストを送信することによって複数の関数の内の１つ以上の対応する関数の実行を呼び出し、（ｉｉ）リクエストに応答して、及びリモートソフトウェアアプリケーションシステムを介して、１つ以上の対応する関数の出力を受け取るように構成され得る。
ブロック１１０８は、インターフェースを定義するために複数のアクションを永続ストレージ内に格納することを含む。
幾つかの実施形態では、リモートソフトウェアアプリケーションは、複数の異なるリモートコンピューティングシステムによってホストされ得る。リモートソフトウェアアプリケーションシステムは、ワークフローに代わる実行のためにリモートソフトウェアアプリケーションを公開するために、異なるリモートコンピューティングシステムの各々に通信可能に接続され得る。
幾つかの実施形態では、特定のリモートソフトウェアアプリケーションは、リモートソフトウェアアプリケーションシステムによって提供されるＡＰＩを介してアクセス可能であり得る。複数の関数の各個別の関数の実行は、ＡＰＩの対応するＡＰＩ関数を介して呼び出し可能であり得る。仕様は、ＡＰＩの複数の関数を定義し得る。各個別のアクションは、ワークフローによって実行される場合に、対応するＡＰＩ関数へリクエストを送信することによって、１つ以上の対応する関数の実行を呼び出すように構成され得る。リモートソフトウェアアプリケーションシステムは、特定のリモートソフトウェアアプリケーションに、リクエストの受信に応答して１つ以上の対応する関数を実行させるように構成され得る。
幾つかの実施形態では、リモートソフトウェアアプリケーションシステムを識別することは、リモートソフトウェアアプリケーションシステムをアドレッシングするＵＲＬを取得することと、ＵＲＬを介して、ワークフローに代わる実行のためにリモートソフトウェアアプリケーションシステムを介して公開されているリモートソフトウェアアプリケーションのリストを取得することを含み得る。リモートソフトウェアアプリケーションの個別のリモートソフトウェアアプリケーション毎に、ワークフローが個別のリモートソフトウェアアプリケーションの複数の関数の実行を呼び出すことを可能にする１つ以上のサービス識別子のリストが取得され得る。複数のアクションの各個別のアクションは、１つ以上の対応する関数の実行を呼び出すために、１つ以上のサービス識別子の内の特定のサービス識別子を使用するように構成可能であり得る。
幾つかの実施形態では、特定のリモートソフトウェアアプリケーションのためのインターフェースを定義する複数のアクションを生成することは、（ｉ）第１の部分のアクションがワークフローへの統合に利用可能であるように、複数のアクションの第１の部分を有効にすることと、（ｉｉ）第２の部分のアクションがワークフローへの統合に利用可能ではないように、複数のアクションの第２の部分を無効にすることを含み得る。
幾つかの実施形態では、仕様によって定義される属性は、複数の関数の個別の関数毎に、（ｉ）個別の関数が実行のためにそれを介して公開されるリモートソフトウェアアプリケーションシステムのＡＰＩのＵＲＬと、（ｉｉ）個別の関数の入力と、（ｉｉｉ）個別の関数の出力とを含み得る。インターフェースを定義する複数のアクションを生成することは、個別のアクション毎に、（ｉ）１つ以上の対応する関数の入力に対応する個別のアクションの入力変数と、（ｉｉ）１つ以上の対応する関数の出力に対応する個別のアクションの出力変数とを生成することを含み得る。個別のアクション毎に、第１のマッピングは、入力変数と、リモートソフトウェアアプリケーションシステムへ送信されるリクエストのパラメータとの間で判定され得る。個別のアクションの実行は、ＡＰＩのＵＲＬへリクエストを送信することによって、個別の関数の実行を呼び出し得る。リクエストは、第１のマッピングに従って入力変数の値をその中に含み得る。個別のアクション毎に、第２のマッピングは、出力変数とＡＰＩからの応答との間で判定され得る。応答はリクエストに対するものであり得る。ＡＰＩからの応答の受信は、１つ以上の対応する関数の出力の値を、第２のマッピングに従って出力変数内に格納させ得る。
幾つかの実施形態では、ＡＰＩへ送信されるリクエストのパラメータは、（ｉ）ＡＰＩをホストするサーバデバイスによって提供される特定のリソースを識別するＵＲＬリソースパスパラメータ、（ｉｉ）キー及び値のペアを含むＵＲＬクエリパラメータ、（ｉｉｉ）リクエストのＨＴＴＰヘッダーとしてＡＰＩに提供されるヘッダーパラメータ、（ｉｖ）リクエストのＨＴＴＰボディの一部としてＡＰＩに提供されるボディパラメータ、又は（ｖ）リクエストのＨＴＴＰクッキー内でＡＰＩに提供されるクッキーパラメータの内の少なくとも１つを含み得る。
幾つかの実施形態では、ワークフロー設計ソフトウェアアプリケーションは、個別のインターフェースを使用するワークフローを定義するように構成され得る。ワークフロー設計ソフトウェアアプリケーションは、ワークフローを定義するための第１のアクション及び第２のアクションの選択を受け取るように構成され得る。第２のアクションは、ワークフローにおいて第１のアクションに先行し得る。第１のアクションは、特定のリモートソフトウェアアプリケーションのためのインターフェースの複数のアクションから選択され得る。ワークフロー設計ソフトウェアアプリケーションはまた、第２のアクションの出力変数の第１のアクションの入力変数への割り当てを受け取るように構成され得る。ワークフロー設計ソフトウェアアプリケーションは、（ｉ）第２のアクションの出力変数と（ｉｉ）第１のアクションの入力変数との間の接続を生成するように更に構成され得る。第２のアクションの出力変数の値は、ワークフローの実行中に第２のアクションから第１のアクションの入力変数に渡され得る。
幾つかの実施形態では、ワークフロー設計ソフトウェアアプリケーションは、個別のインターフェースを使用するワークフローを定義するように構成され得る。ワークフロー設計ソフトウェアアプリケーションは、ワークフローを定義するための第１のアクション及び第２のアクションの選択を受け取るように構成され得る。第１のアクションは、ワークフローにおいて第２のアクションに先行し得る。第１のアクションは、特定のリモートソフトウェアアプリケーションのためのインターフェースの複数のアクションから選択され得る。ワークフロー設計ソフトウェアアプリケーションはまた、第１のアクションの出力変数の第２のアクションの入力変数への割り当てを受け取るように構成され得る。ワークフロー設計ソフトウェアアプリケーションは、（ｉ）第１のアクションの出力変数と（ｉｉ）第２のアクションの入力変数との間の接続を生成するように更に構成され得る。第１のアクションの出力変数の値は、ワークフローの実行中に第１のアクションから第２のアクションの入力変数に渡され得る。
幾つかの実施形態では、ワークフロー設計ソフトウェアアプリケーションは、インターフェースの複数のアクションから第１のアクションの選択を受け取ることによってワークフローを定義するように構成され得る。アクション設計ソフトウェアアプリケーションは、ワークフロー設計ソフトウェアアプリケーションが第１のアクションの選択を受け取ることに基づいて、リモートソフトウェアアプリケーションシステムから、（ｉ）１つ以上のオブジェクト又は（ｉｉ）複数の関数に対する１つ以上の更新を表す特定のリモートソフトウェアアプリケーションの更新された仕様を取得するように構成され得る。アクション設計ソフトウェアアプリケーションはまた、第１のアクションのワークフローへの統合前に、更新された仕様に基づいて第１のアクションを更新するように構成され得る。更新された第１のアクションは、ワークフロー設計ソフトウェアアプリケーションによる第１のアクションのワークフローへの統合のために永続ストレージ内に格納され得る。
幾つかの実施形態では、アクション設計ソフトウェアアプリケーションは、リモートソフトウェアアプリケーションシステムから、（ｉ）１つ以上のオブジェクト又は（ｉｉ）複数の関数に対する１つ以上の更新を表す特定のリモートソフトウェアアプリケーションの更新された仕様を定期的に取得するように構成され得る。アクション設計ソフトウェアアプリケーションはまた、更新された仕様に基づいて複数のアクションを更新し、更新された複数のアクションを永続ストレージ内に格納するように構成され得る。
幾つかの実施形態では、ワークフロー設計ソフトウェアアプリケーションは、少なくとも２つの異なるリモートソフトウェアアプリケーションの個別のインターフェースを使用するワークフローを定義するように構成され得る。
幾つかの実施形態では、リモートソフトウェアアプリケーションシステムを識別することは、実行のためにリモートソフトウェアアプリケーションの異なるセットを公開するように各々構成された複数の利用可能なリモートソフトウェアアプリケーションシステムを識別することを含み得る。リモートソフトウェアアプリケーションシステムは、管理されるネットワークがリモートソフトウェアアプリケーションシステムに対する１つ以上のサービス識別子を維持することに基づいて、複数の利用可能なリモートソフトウェアアプリケーションシステムから選択され得る。ワークフローは、管理されるネットワークに代わる実行のために定義され得る。
幾つかの実施形態では、１つ以上のオブジェクトは、キー及び値のペアの階層内に配列されたデータ構造を各々含み得る。
幾つかの実施形態では、複数の関数は、１つ以上のオブジェクトを作成すること、１つ以上のオブジェクトを修正すること、又は１つ以上のオブジェクトを削除することによって、１つ以上のオブジェクトと相互作用するように構成され得る。
ＸＩ． 結論
本開示は、様々な態様の例証として意図されている、この出願で説明する特定の実施形態に関して限定されるべきではない。当業者には明らかであるように、その範囲から逸脱することなく、多くの修正及び変形がなされ得る。本明細書に説明したものに加えて、開示の範囲内の機能的に同等の方法及び装置は、前述の説明から当業者には明らかであろう。そうした修正及び変形は、添付の特許請求の範囲内にあることが意図されている。
上記の詳細な説明は、添付の図を参照して、開示されたシステム、デバイス、及び方法の様々な機構及び動作を説明している。本明細書及び図で説明した例示的実施形態は、限定することを意味しない。本明細書に提示される主題の範囲から逸脱することなく、他の実施形態が利用され得、他の変更がなされ得る。本明細書に一般的に説明され、図に説明されるような本開示の態様が、多種多様な異なる構成で配置され得、置換され得、組み合され得、分離され得、設計され得ることは容易に理解されるであろう。
図中のメッセージフロー図、シナリオ、及びフローチャートの内の何れか又は全てに関して、本明細書で論じたように、各ステップ、ブロック、及び／又は通信は、例示的実施形態に従った情報の処理及び／又は情報の送信を表し得る。代替的実施形態は、これらの例示的実施形態の範囲内に含まれる。これらの代替的実施形態では、例えば、ステップ、ブロック、送信、通信、リクエスト、応答、及び／又はメッセージとして説明される動作は、関係する機能に依存して、実質的に同時又は逆の順序を含め、示された又は論じられた順序とは異なる順序で実行され得る。更に、より多くの又はより少ないブロック及び／又は動作は、本明細書で論じられるメッセージフロー図、シナリオ、及びフローチャートの内の何れかと共に使用され得、これらのメッセージフロー図、シナリオ、及びフローチャートは、部分的に又は全体的に相互に組み合され得る。
情報の処理を表すステップ又はブロックは、本明細書で説明する方法又は技術の具体的な論理機能を実施するように構成され得る回路に対応し得る。代替的又は追加的に、情報の処理を表すステップ又はブロックは、モジュール、セグメント、又はプログラムコードの一部（関連データを含む）に対応し得る。プログラムコードは、方法又は技術において具体的な論理演算又は活動を実装するためにプロセッサにより実行可能な１つ以上の命令を含み得る。プログラムコード及び／又は関連データは、ＲＡＭ、ディスクドライブ、ソリッドステートドライブ、又は別のストレージ媒体を含むストレージデバイス等の任意のタイプのコンピュータ可読媒体上に格納され得る。
コンピュータ可読媒体はまた、レジスタメモリ及びプロセッサキャッシュのような短期間にデータを格納するコンピュータ可読媒体等の非一時的コンピュータ可読媒体を含み得る。コンピュータ可読媒体は、プログラムコード及び／又はデータをより長期間格納する非一時的コンピュータ可読媒体を更に含み得る。したがって、コンピュータ可読媒体は、例えば、ＲＯＭ、光又は磁気ディスク、ソリッドステートドライブ、コンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）のような二次的又は永続的な長期ストレージを含み得る。コンピュータ可読媒体はまた、その他の任意の揮発性又は不揮発性のストレージシステムであり得る。コンピュータ可読媒体は、例えば、コンピュータ可読ストレージ媒体、又は有形ストレージデバイスとみなされ得る。
更に、１つ以上の情報送信を表すステップ又はブロックは、同じ物理デバイス内のソフトウェア及び／又はハードウェアモジュール間の情報送信に対応し得る。しかしながら、その他の情報送信は、異なる物理デバイス内のソフトウェアモジュール及び/又はハードウェアモジュール間であり得る。
図に示される特定の配置は、限定的とみなされるべきではない。他の実施形態は、所与の図に示される各要素の内の多少を含み得ることを理解すべきである。更に、説明された要素の内の幾つかは、組み合わされ得、又は省略され得る。更に、例示的実施形態は、図に説明されない要素を含み得る。
様々な態様及び実施形態が本明細書に開示されているが、他の態様及び実施形態は当業者には明らかであろう。本明細書に開示される様々な態様及び実施形態は、例証を目的とし、限定することを意図せず、真の範囲は、以下の特許請求の範囲によって示される。

Claims (20)

  1. ワークフローへの統合のためにリモートソフトウェアアプリケーションの個別のインターフェースの定義を格納するように構成された永続ストレージと、
    １つ以上のプロセッサと、
    前記個別のインターフェースを定義するように構成されたアクション設計ソフトウェアアプリケーションであって、前記アクション設計ソフトウェアアプリケーションは、
    前記リモートソフトウェアアプリケーションが実行のためにそれを介して公開されるリモートソフトウェアアプリケーションシステムを識別することと、
    前記リモートソフトウェアアプリケーションシステムから、前記リモートソフトウェアアプリケーションの内の特定のリモートソフトウェアアプリケーションの属性を定義する仕様を取得することと、
    前記仕様に基づいて、（ｉ）前記特定のリモートソフトウェアアプリケーションを介してアクセス可能な１つ以上のオブジェクトと、（ｉｉ）前記１つ以上のオブジェクトと相互作用するために呼び出し可能な前記特定のリモートソフトウェアアプリケーションの複数の関数とを判定することと、
    前記特定のリモートソフトウェアアプリケーションのためのインターフェースを定義する複数のアクションを生成することであって、前記複数のアクションの各個別のアクションは、実行される場合に、（ｉ）前記リモートソフトウェアアプリケーションシステムへリクエストを送信することによって前記複数の関数の内の１つ以上の対応する関数の実行を呼び出し、（ｉｉ）前記リクエストに応答して、及び前記リモートソフトウェアアプリケーションシステムを介して、前記１つ以上の対応する関数の出力を受け取るように構成されることと、
    前記インターフェースを定義するために前記複数のアクションを前記永続ストレージ内に格納すること
    を含む動作を前記１つ以上のプロセッサを介して実施するように構成される、前記アクション設計ソフトウェアアプリケーションと
    を含むシステム。
  2. 前記リモートソフトウェアアプリケーションは、複数の異なるリモートコンピューティングシステムによってホストされ、前記リモートソフトウェアアプリケーションシステムは、前記ワークフローに代わる実行のために前記リモートソフトウェアアプリケーションを公開するために、前記異なるリモートコンピューティングシステムの各々に通信可能に接続される、請求項１に記載のシステム。
  3. 前記特定のリモートソフトウェアアプリケーションは、前記リモートソフトウェアアプリケーションシステムによって提供されるアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアクセス可能であり、前記複数の関数の各個別の関数の実行は、前記ＡＰＩの対応するＡＰＩ関数を介して呼び出し可能であり、前記仕様は、前記ＡＰＩの複数の関数を定義し、各個別のアクションは、前記ワークフローによって実行される場合に、前記対応するＡＰＩ関数へ前記リクエストを送信することにより、前記１つ以上の対応する関数の実行を呼び出すように構成され、前記リモートソフトウェアアプリケーションシステムは、前記特定のリモートソフトウェアアプリケーションに、前記リクエストの受信に応答して前記１つ以上の対応する関数を実行させるように構成される、請求項１に記載のシステム。
  4. 前記リモートソフトウェアアプリケーションシステムを識別することは、
    前記リモートソフトウェアアプリケーションシステムをアドレッシングするユニフォームリソースロケーター（ＵＲＬ）を取得することと、
    前記ＵＲＬを介して、前記ワークフローに代わる実行のために前記リモートソフトウェアアプリケーションシステムを介して公開されている前記リモートソフトウェアアプリケーションのリストを取得することと、
    前記リモートソフトウェアアプリケーションの個別のリモートソフトウェアアプリケーション毎に、前記ワークフローが前記個別のリモートソフトウェアアプリケーションの前記複数の関数の実行を呼び出すことを可能にする１つ以上のサービス識別子のリストを取得することであって、前記複数のアクションの各個別のアクションは、前記１つ以上の対応する関数の実行を呼び出すために、前記１つ以上のサービス識別子の内の特定のサービス識別子を使用するように構成可能であること
    を含む、請求項１に記載のシステム。
  5. 前記特定のリモートソフトウェアアプリケーションのための前記インターフェースを定義する前記複数のアクションを生成することは、
    第１の部分のアクションが前記ワークフローへの統合に利用可能であるように、前記複数のアクションの前記第１の部分を有効にすることと、
    第２の部分のアクションが前記ワークフローへの統合に利用可能ではないように、前記複数のアクションの前記第２の部分を無効にすること
    を含む、請求項１に記載のシステム。
  6. 前記仕様によって定義される前記属性は、前記複数の関数の個別の関数毎に、（ｉ）前記個別の関数が実行のためにそれを介して公開される前記リモートソフトウェアアプリケーションシステムのアプリケーションプログラミングインターフェース（ＡＰＩ）のユニフォームリソースロケーター（ＵＲＬ）と、（ｉｉ）前記個別の関数の入力と、（ｉｉｉ）前記個別の関数の出力とを含み、前記インターフェースを定義する前記複数のアクションを生成することは、
    個別のアクション毎に、（ｉ）前記１つ以上の対応する関数の前記入力に対応する前記個別のアクションの入力変数と、（ｉｉ）前記１つ以上の対応する関数の前記出力に対応する前記個別のアクションの出力変数とを生成することと、
    個別のアクション毎に、前記入力変数と、前記リモートソフトウェアアプリケーションシステムへ送信される前記リクエストのパラメータとの間の第１のマッピングを判定することであって、前記個別のアクションの実行は、前記ＡＰＩの前記ＵＲＬへ前記リクエストを送信することによって前記個別の関数の実行を呼び出し、前記リクエストは、前記第１のマッピングに従って前記入力変数の値をその中に含むことと、
    個別のアクション毎に、前記出力変数と前記ＡＰＩからの応答との間の第２のマッピングを判定することであって、前記応答は前記リクエストに対するものであり、前記ＡＰＩからの前記応答の受信は、前記１つ以上の対応する関数の前記出力の値を前記第２のマッピングに従って前記出力変数内に格納させること
    を含む、請求項１に記載のシステム。
  7. 前記ＡＰＩへ送信される前記リクエストの前記パラメータは、（ｉ）前記ＡＰＩをホストするサーバデバイスによって提供される特定のリソースを識別するＵＲＬリソースパスパラメータ、（ｉｉ）キー及び値のペアを含むＵＲＬクエリパラメータ、（ｉｉｉ）前記リクエストのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダーとして前記ＡＰＩに提供されるヘッダーパラメータ、（ｉｖ）前記リクエストのＨＴＴＰボディの一部として前記ＡＰＩに提供されるボディパラメータ、又は（ｖ）前記リクエストのＨＴＴＰクッキー内で前記ＡＰＩに提供されるクッキーパラメータの内の少なくとも１つを含む、請求項６に記載のシステム。
  8. 前記個別のインターフェースを使用する前記ワークフローを定義するように構成されたワークフロー設計ソフトウェアアプリケーションであって、前記ワークフロー設計ソフトウェアアプリケーションは、
    ワークフローを定義するための第１のアクション及び第２のアクションの選択を受け取ることであって、前記第２のアクションは、前記ワークフローにおいて前記第１のアクションに先行し、前記第１のアクションは、前記特定のリモートソフトウェアアプリケーションのための前記インターフェースの前記複数のアクションから選択されることと、
    前記第２のアクションの出力変数の前記第１のアクションの入力変数への割り当てを受け取ることと、
    （ｉ）前記第２のアクションの前記出力変数と（ｉｉ）前記第１のアクションの前記入力変数との間の接続を生成することであって、前記第２のアクションの前記出力変数の値は、前記ワークフローの実行中に前記第２のアクションから前記第１のアクションの前記入力変数に渡されること
    を含む動作を前記１つ以上のプロセッサを介して実施するように構成される、前記ワークフロー設計ソフトウェアアプリケーション
    を更に含む、請求項６に記載のシステム。
  9. 前記個別のインターフェースを使用する前記ワークフローを定義するように構成されたワークフロー設計ソフトウェアアプリケーションであって、前記ワークフロー設計ソフトウェアアプリケーションは、
    ワークフローを定義するための第１のアクション及び第２のアクションの選択を受け取ることであって、前記第１のアクションは、前記ワークフローにおいて前記第２のアクションに先行し、前記第１のアクションは、前記特定のリモートソフトウェアアプリケーションのための前記インターフェースの前記複数のアクションから選択されることと、
    前記第１のアクションの出力変数の前記第２のアクションの入力変数への割り当てを受け取ることと、
    （ｉ）前記第１のアクションの前記出力変数と（ｉｉ）前記第２のアクションの前記入力変数との間の接続を生成することであって、前記第１のアクションの前記出力変数の値は、前記ワークフローの実行中に前記第１のアクションから前記第２のアクションの前記入力変数に渡されること
    を含む動作を前記１つ以上のプロセッサを介して実施するように構成される、前記ワークフロー設計ソフトウェアアプリケーション
    を更に含む、請求項６に記載のシステム。
  10. 前記インターフェースの前記複数のアクションから第１のアクションの選択を受け取ることによってワークフローを定義するように構成されたワークフロー設計ソフトウェアアプリケーションを更に含み、前記動作は、
    前記ワークフロー設計ソフトウェアアプリケーションが前記第１のアクションの前記選択を受け取ることに基づいて、前記リモートソフトウェアアプリケーションシステムから、（ｉ）前記１つ以上のオブジェクト又は（ｉｉ）前記複数の関数に対する１つ以上の更新を表す前記特定のリモートソフトウェアアプリケーションの更新された仕様を取得することと、
    前記第１のアクションの前記ワークフローへの統合前に、前記更新された仕様に基づいて前記第１のアクションを更新することと、
    前記ワークフロー設計ソフトウェアアプリケーションによる前記第１のアクションの前記ワークフローへの統合のために更新された前記第１のアクションを前記永続ストレージ内に格納すること
    を更に含む、請求項１に記載のシステム。
  11. 前記動作は、
    前記リモートソフトウェアアプリケーションシステムから、（ｉ）前記１つ以上のオブジェクト又は（ｉｉ）前記複数の関数に対する１つ以上の更新を表す前記特定のリモートソフトウェアアプリケーションの更新された仕様を定期的に取得することと、
    前記更新された仕様に基づいて前記複数のアクションを更新することと、
    更新された前記複数のアクションを永続ストレージ内に格納すること
    を更に含む、請求項１に記載のシステム。
  12. 少なくとも２つの異なるリモートソフトウェアアプリケーションの前記個別のインターフェースを使用するワークフローを定義するように構成されたワークフロー設計ソフトウェアアプリケーション
    を更に含む、請求項１に記載のシステム。
  13. 前記リモートソフトウェアアプリケーションシステムを識別することは、
    実行のためにリモートソフトウェアアプリケーションの異なるセットを公開するように各々構成された複数の利用可能なリモートソフトウェアアプリケーションシステムを識別することと、
    前記複数の利用可能なリモートソフトウェアアプリケーションシステムから、管理ネットワークが前記リモートソフトウェアアプリケーションシステムに対する１つ以上のサービス識別子を維持することに基づいて前記リモートソフトウェアアプリケーションシステムを選択することであって、前記ワークフローは、前記管理されるネットワークに代わる実行のために定義されること
    を含む、請求項１に記載のシステム。
  14. 前記１つ以上のオブジェクトは、キー及び値のペアの階層内に配列されたデータ構造を各々含む、請求項１に記載のシステム。
  15. 前記複数の関数は、前記１つ以上のオブジェクトを作成すること、前記１つ以上のオブジェクトを修正すること、又は前記１つ以上のオブジェクトを削除することによって前記１つ以上のオブジェクトと相互作用するように構成される、請求項１に記載のシステム。
  16. ワークフローへの統合のためにリモートソフトウェアアプリケーションの個別のインターフェースを定義するように構成されたアクション設計ソフトウェアアプリケーションによって、前記リモートソフトウェアアプリケーションが実行のためにそれを介して公開されるリモートソフトウェアアプリケーションシステムを識別することであって、永続ストレージは、前記個別のインターフェースの定義を格納するように構成されることと、
    前記アクション設計ソフトウェアアプリケーションによって、及び前記リモートソフトウェアアプリケーションシステムから、前記リモートソフトウェアアプリケーションの内の特定のリモートソフトウェアアプリケーションの属性を定義する仕様を取得することと、
    前記アクション設計ソフトウェアアプリケーションによって、及び前記仕様に基づいて、（ｉ）前記特定のリモートソフトウェアアプリケーションを介してアクセス可能な１つ以上のオブジェクトと、（ｉｉ）前記１つ以上のオブジェクトと相互作用するために呼び出し可能な前記特定のリモートソフトウェアアプリケーションの複数の関数とを判定することと、
    前記アクション設計ソフトウェアアプリケーションによって、前記特定のリモートソフトウェアアプリケーションのためのインターフェースを定義する複数のアクションを生成することであって、前記複数のアクションの各個別のアクションは、実行される場合に、（ｉ）前記リモートソフトウェアアプリケーションシステムへリクエストを送信することによって前記複数の関数の内の１つ以上の対応する関数の実行を呼び出し、（ｉｉ）前記リクエストに応答して、及び前記リモートソフトウェアアプリケーションシステムを介して、前記１つ以上の対応する関数の出力を受け取るように構成されることと、
    前記インターフェースを定義するために前記複数のアクションを前記永続ストレージ内に格納すること
    を含む、コンピュータ実装方法。
  17. 前記特定のリモートソフトウェアアプリケーションは、前記リモートソフトウェアアプリケーションシステムによって提供されるアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアクセス可能であり、前記複数の関数の各個別の関数の実行は、前記ＡＰＩの対応するＡＰＩ機能を介して呼び出し可能であり、前記仕様は、前記ＡＰＩの複数の関数を定義し、各個別のアクションは、前記ワークフローによって実行される場合に、前記対応するＡＰＩ関数へ前記リクエストを送信することによって前記１つ以上の対応する関数の実行を呼び出すように構成され、前記リモートソフトウェアアプリケーションシステムは、前記特定のリモートソフトウェアアプリケーションに、前記リクエストの受信に応答して前記１つ以上の対応する関数を実行させるように構成される、請求項１６に記載のコンピュータ実装方法。
  18. 前記仕様によって定義される前記属性は、前記複数の関数の個別の関数毎に、（ｉ）前記個別の機能が実行のためにそれを介して公開される前記リモートソフトウェアシステムのアプリケーションプログラミングインターフェース（ＡＰＩ）のユニフォームリソースロケーター（ＵＲＬ）と、（ｉｉ）前記個別の関数の入力と、（ｉｉｉ）前記個別の関数の出力とを含み、前記インターフェースを定義する前記複数のアクションを生成することは、
    個別のアクション毎に、（ｉ）前記１つ以上の対応する関数の前記入力に対応する前記個別のアクションの入力変数と、（ｉｉ）前記１つ以上の対応する関数の前記出力に対応する前記個別のアクションの出力変数とを生成することと、
    個別のアクション毎に、前記入力変数と、前記リモートソフトウェアアプリケーションシステムへ送信される前記リクエストのパラメータとの間の第１のマッピングを判定することであって、前記個別のアクションの実行は、前記ＡＰＩの前記ＵＲＬへ前記リクエストを送信することによって前記個別の関数の実行を呼び出し、前記リクエストは、前記第１のマッピングに従って前記入力変数の値をその中に含むことと、
    個別のアクション毎に、前記出力変数と前記ＡＰＩからの応答との間の第２のマッピングを判定することであって、前記応答は前記リクエストに対するものであり、前記ＡＰＩからの前記応答の受信は、前記１つ以上の対応する関数の前記出力の値を、前記第２のマッピングに従って前記出力変数内に格納させること
    を含む、請求項１６に記載のコンピュータ実装方法。
  19. ワークフロー設計ソフトウェアアプリケーションは、前記インターフェースの前記複数のアクションから第１のアクションの選択を受け取ることによってワークフローを定義するように構成され、前記方法は、
    前記ワークフロー設計ソフトウェアアプリケーションが前記第１のアクションの前記選択を受け取ることに基づいて、前記リモートソフトウェアアプリケーションシステムから、（ｉ）前記１つ以上のオブジェクト又は（ｉｉ）前記複数の関数に対する１つ以上の更新を表す前記特定のリモートソフトウェアアプリケーションの更新された仕様を取得することと、
    前記第１のアクションの前記ワークフローへの統合前に、前記更新された仕様に基づいて前記第１アクションを更新することと、
    前記ワークフロー設計ソフトウェアアプリケーションによる前記第１のアクションの前記ワークフローへの統合のために更新された前記第１のアクションを前記永続ストレージ内に格納すること
    を更に含む、請求項１６に記載のコンピュータ実装方法。
  20. リモートソフトウェアアプリケーションが実行のためにそれを介して公開されるリモートソフトウェアアプリケーションシステムを識別することであって、永続ストレージは、ワークフローへの統合のために前記リモートソフトウェアアプリケーションの個別のインターフェースの定義を格納するように構成されることと、
    前記リモートソフトウェアアプリケーションシステムから、前記リモートソフトウェアアプリケーションの内の特定のリモートソフトウェアアプリケーションの属性を定義する仕様を取得することと、
    前記仕様に基づいて、（ｉ）前記特定のリモートソフトウェアアプリケーションを介してアクセス可能な１つ以上のオブジェクトと、（ｉｉ）前記１つ以上のオブジェクトと相互作用するために呼び出し可能な前記特定のリモートソフトウェアアプリケーションの複数の機能とを判定することと、
    前記特定のリモートソフトウェアアプリケーションのためのインターフェースを定義する複数のアクションを生成することであって、前記複数のアクションの各個別のアクションは、実行される場合に、（ｉ）前記リモートソフトウェアアプリケーションシステムへリクエストを送信することによって前記複数の関数の内の１つ以上の対応する関数の実行を呼び出し、（ｉｉ）前記リクエストに応答して、及び前記リモートソフトウェアアプリケーションシステムを介して、前記１つ以上の対応する関数の出力を受け取るように構成されることと、
    前記インターフェースを定義するために前記複数のアクションを前記永続ストレージ内に格納すること
    を含む動作を、コンピューティングシステムによって実行されると、前記コンピューティングシステムに実行させるプログラム命令をその上に格納した、非一時的コンピュータ可読媒体を含む製品。
JP2021572334A 2019-06-06 2020-06-04 リモートソフトウェアアプリケーションのワークフローへの統合 Active JP7315721B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/434,071 US11240344B2 (en) 2019-06-06 2019-06-06 Integration of remote software applications into a workflow
US16/434,071 2019-06-06
PCT/US2020/036214 WO2020247696A1 (en) 2019-06-06 2020-06-04 Integration of remote software applications into a workflow

Publications (2)

Publication Number Publication Date
JP2022536108A true JP2022536108A (ja) 2022-08-12
JP7315721B2 JP7315721B2 (ja) 2023-07-26

Family

ID=71846471

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021572334A Active JP7315721B2 (ja) 2019-06-06 2020-06-04 リモートソフトウェアアプリケーションのワークフローへの統合

Country Status (5)

Country Link
US (1) US11240344B2 (ja)
JP (1) JP7315721B2 (ja)
KR (1) KR20220016276A (ja)
AU (1) AU2020287352B2 (ja)
WO (1) WO2020247696A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3367316A1 (en) * 2017-02-21 2018-08-29 SourceCode Technology Holdings, Inc. Collaborative design systems, apparatuses, and methods
US20200065313A1 (en) 2018-08-27 2020-02-27 Box, Inc. Extensible content object metadata
US11936638B2 (en) * 2019-06-28 2024-03-19 Salesforce Inc. Link protocol agents for inter-application communications
US11481233B2 (en) * 2019-09-13 2022-10-25 Logistiview, Inc. Augmenting legacy user interfaces using workflows
US11669793B2 (en) 2019-10-01 2023-06-06 Box, Inc. Inter-application workflow performance analytics
US11681572B2 (en) 2019-12-23 2023-06-20 Box, Inc. Extensible workflow access
US11263186B2 (en) 2020-02-06 2022-03-01 Servicenow, Inc. System and method for customized graphQL data-handling scripts
US20220035653A1 (en) * 2020-07-30 2022-02-03 Fujitsu Limited Task integration
US11900074B2 (en) * 2020-08-20 2024-02-13 Jpmorgan Chase Bank, N.A. Method and apparatus for implementing an end-to-end API design and development module integrating with firmwide tools and processes
US20220066818A1 (en) * 2020-08-31 2022-03-03 Fujitsu Limited Multiple task execution
US20220083679A1 (en) * 2020-09-14 2022-03-17 Box, Inc. Broker-assisted workflows
US11522943B1 (en) 2022-02-02 2022-12-06 Servicenow, Inc. System and method for deferring data retrieval
US20240045669A1 (en) * 2022-08-08 2024-02-08 Capital One Services, Llc Computer-based systems configured to decouple delivery of product configuration changes associated with continuous integration/continuous delivery programming pipelines and methods of use thereof

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9424112B1 (en) * 2015-10-01 2016-08-23 Emc Corporation Execution plan generator and execution engine for interfacing with application programming interfaces
JP2017134486A (ja) * 2016-01-26 2017-08-03 キヤノン株式会社 情報処理装置、情報処理装置のデータ処理方法、及びプログラム

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7506047B2 (en) 2001-03-30 2009-03-17 Bmc Software, Inc. Synthetic transaction monitor with replay capability
US7617073B2 (en) 2002-03-01 2009-11-10 Bmc Software, Inc. System and method for assessing and indicating the health of components
US7062683B2 (en) 2003-04-22 2006-06-13 Bmc Software, Inc. Two-phase root cause analysis
US7945860B2 (en) 2003-05-14 2011-05-17 Hewlett-Packard Development Company, L.P. Systems and methods for managing conversations between information technology resources
US8224683B2 (en) 2003-07-08 2012-07-17 Hewlett-Packard Development Company, L.P. Information technology service request level of service monitor
US7610512B2 (en) 2006-01-06 2009-10-27 Hewlett-Packard Development Company, L.P. System and method for automated and assisted resolution of it incidents
US8674992B2 (en) 2010-06-24 2014-03-18 Bmc Software, Inc. Spotlight graphs
EP2891038B1 (en) * 2012-08-31 2020-06-24 Citrix Systems, Inc. Reverse seamless integration between local and remote computing environments
US9442700B2 (en) 2013-09-30 2016-09-13 MuleSoft, Inc. API notebook tool
US9569288B2 (en) 2014-07-15 2017-02-14 International Business Machines Corporation Application pattern discovery
US9826045B2 (en) * 2014-09-26 2017-11-21 Oracle International Corporation Efficient means to test server generated applications on mobile device
US9391995B2 (en) * 2014-09-30 2016-07-12 Airwatch Llc Remote processing of mobile applications
US10565534B2 (en) * 2014-11-11 2020-02-18 Amazon Technologies, Inc. Constraints and constraint sharing in a catalog service platform
US9823950B1 (en) 2016-08-16 2017-11-21 International Business Machines Corporation Dynamically forming and executing application programming interface pipelines
US10853897B2 (en) * 2016-12-15 2020-12-01 David H. Williams Systems and methods for developing, monitoring, and enforcing agreements, understandings, and/or contracts
US10733557B2 (en) * 2017-04-04 2020-08-04 International Business Machines Corporation Optimization of a workflow employing software services
US11038778B2 (en) * 2018-12-11 2021-06-15 Vmware, Inc. Methods and systems that provision distributed applications that invoke functions provided by a distributed-function-as-a-service feature
US10554817B1 (en) * 2018-12-12 2020-02-04 Amazon Technologies, Inc. Automation of contact workflow and automated service agents in contact center system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9424112B1 (en) * 2015-10-01 2016-08-23 Emc Corporation Execution plan generator and execution engine for interfacing with application programming interfaces
JP2017134486A (ja) * 2016-01-26 2017-08-03 キヤノン株式会社 情報処理装置、情報処理装置のデータ処理方法、及びプログラム

Also Published As

Publication number Publication date
US20200389543A1 (en) 2020-12-10
AU2020287352B2 (en) 2023-02-02
US11240344B2 (en) 2022-02-01
KR20220016276A (ko) 2022-02-08
JP7315721B2 (ja) 2023-07-26
AU2020287352A1 (en) 2022-01-06
WO2020247696A1 (en) 2020-12-10

Similar Documents

Publication Publication Date Title
JP7315721B2 (ja) リモートソフトウェアアプリケーションのワークフローへの統合
US11258865B2 (en) Automated integration with cloud-based services
JP7245356B2 (ja) 動的アクション入力のためのワークフローサポート
US11068241B2 (en) Guided definition of an application programming interface action for a workflow
US10929107B2 (en) Workflow support for dynamic action output
US20200374195A1 (en) Guided configuration item class creation in a remote network management platform
JP7291854B2 (ja) サービス統合としてのソフトウェアのコードレス仕様
US11061696B2 (en) Extension points for web-based applications and services
US10951483B2 (en) Agent-assisted discovery of network devices and services
US11922155B2 (en) Post-upgrade debugging in a remote network management platform
US11061949B2 (en) User interface for contextual search
US11374805B2 (en) Descriptor architecture for a remote network management platform
US10983770B2 (en) Efficient bundling and delivery of client-side scripts
US11204917B2 (en) Graphical query builder for multi-modal search

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220203

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230123

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230131

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230330

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230627

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230713

R150 Certificate of patent or registration of utility model

Ref document number: 7315721

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150