2 作成者ワークフロー
ワークフローは、Oracle Orchestrationを使用して自動化できる一連のタスクまたはアクティビティを定義します。 ワークフローは1つ以上のステップで構成され、複数のワーカーまたは他のワークフローへのコールを使用してそのタスクを完了できます。
ワークフローの詳細、その構成方法および動作方法は、「ワークフローについて」を参照してください。
注意:
このマニュアルには、ワークフロー構文のバージョンが2つあります: V1.0およびV2.0。 現在、V1.0は改善処理サポートのためにこのドキュメントにのみ含まれています。 Oracle Orchestrationでは、作成されたすべてのワークフローについてV2.0構文および定義を先に使用する必要があります。ワークフローについて
アクティビティの複雑さに応じて、ワークフローは1つ以上のステップで構成されます。 ワークフローの一般的な実行モデルでは、パラレルおよびシリアル処理を組み合せて、任意のレベルのシリアル/パラレル処理を組み合せることができます。
重要な用語
ワークフローがどのように構造化されているかを確認する前に、ワークフロー関連の用語と概念を理解する必要があります。
- 「ワークフロー」: 1以上のワーカーによって実行されている、Oracle Orchestrationを使用して自動化できる一連の編成済タスクまたはアクティビティを定義します。
- ワークフロー名: この名前は、ステータスおよび結果のワークフロー送信の検索に使用できる識別子です。 オーケストレーション内のすべてのワークフローに一意の名前を付ける必要があります。
- ワークフロー・ライブラリ: ワークフローを格納および取得できる永続ストレージ領域。 ワークフローには1つ以上のバージョンを関連付けることができ、publishedまたはdraftの状態の場合もあります。 ワークフロー・ライブラリでは、ワークフローの完全なライフ・サイクル管理がサポートされており、これによりユーザーはこれらのワークフローを公開および管理して、そのワークフローを再利用できます。 ワークフローは、新しいバージョンとして更新および公開できます。最新バージョンのみアクティブになり、ワークフローのアクティブなバージョンは1つのみになります。 ワークフローには、ワークフロー・ライブラリUIを介してアクセスします。
- ワークフローの提出: 特定ワークフローの即時またはスケジュールされた実行。
- ワークフロー発行名: ユーザーはワークフロー送信のカスタム名を指定でき、特定に役立ちます。 ワークフロー送信名は、ワークフロー自体の名前ではなく、一意である必要はありません。
例: パッチDBCSワークフローの実行
- ワークフロー宣言: ワークフロー宣言には、ワークフローの論理実行を定義するコードが含まれています。 それらを入力定義および出力定義(検証ルールを含む)として定義し、適切なプロパティを使用してプラン・セクション内でUEL式を使用して参照できます。
- 計画: ワークフローのすべてのステップと入力について説明します。 ワークフローのランタイム・コンテキストを抽象化するユーザーをサポートします。
- ステップ: ワークフロー実行の一部として実行される個々のアクティビティ(ステップ)の単位を定義します。 ステップ・タイプの例として、ENTITY、REST、WAITがあります。
- 工程ステージ: ステップのメイン処理を定義します。
- 事前、事後、操作、公開: ステップ実行フローの一部として定義されるオプション・ステージです。
ワークフロー構造
図2-1オーケストレーション・ワークフロー構造

ワークフロー実行
ワークフロー実行は、パラレルおよびシリアル処理を組み合せて、任意のレベルのシリアル/パラレル処理を実行できるようにします。 さらに、ワークフロー・ステップは他のワークフローを参照することもでき、ワークフローをコンポーネント化またはモジュール化でき、ワークフロー管理者は、明確に定義された小さいワークフロー「ビルディング・ブロック」から複雑なアクティビティをアセンブルできます。
ワークフローの特性と動作
- ワークフローは、1つ以上の「ワークフロー・ワーカー」をインスタンス化できます。 ワークフロー・ワーカーの数によって、ワークフロー全体の並列性のレベルが定義されます。
- 各ワークフロー・ワーカーは、parallel内のワークフローの独自のインスタンスを実行します。 ワークフロー・ワーカー・インスタンス間のデータのクロス・トークや同期はありません。
- 各ワークフローには、1つ以上のステップが含まれる場合があります。
- 各ステップは、「シリアル」で同じワークフロー計画の他のすべてのステップとともに実行されます。
- 各ステップには、1つ以上の「ステップ・ワーカー」 を設定できます(ワークフローと同様)。
- 各ステップ・ワーカーは、parallel内のステップの独自のインスタンスを実行します。 他のステップ・インスタンス間のデータのクロス集計または同期は行われません。
- ステップによって、1ステップ・ワーカー当たりの完了したすべてのステップの結果を1つの結果に統合できます。
- ワークフローにより、完了したすべてのワークフローの結果が結合されて1つの結果になる場合があります。
- ワークフローは、ワークフロー全体の結果を公開できます(これは埋込みワークフローにとって重要であり、ワークフロー公開の結果は公開済ステップの結果と同じです)。
UIを使用した作成者ワークフロー
ワークフローは、Oracle Orchestrationを使用して自動化できるタスクまたはアクティビティを定義します。
- 左側のハンバーガ・メニューのワークフロー・ライブラリにナビゲートします。 メインの「ワークフロー・ライブラリ」画面が表示されます。
- 左側にあるプラス記号+をクリックします。 新しい画面がワークフロー・エディタとともに表示されます。
- ワークフローに一意の名前を選択し、ワークフローの処理内容の簡単な説明を入力します。 完了したら、次へをクリック
- JSON定義画面で、ワークフロー・コードをJSON形式で入力します。
- の完了後、ワークフローを「ドラフト」または「公開」として保存できます。 公開されたワークフローを送信または実行するには、「オーケストレーション・ワークフローの管理」を参照してください。
注意:
ワークフローを作成するには、V2.0構文を使用することをお薦めします。 V1.0構文は現在非推奨であり、レガシー目的でのみ示されています。 V1.0 UI間処理を使用してワークフローを作成することはできません。V2.0構文を使用した作成者ワークフロー
ワークフローは、オーケストレーションを使用して自動化できるビジネス・アクティビティの基本的なビルディング・ブロックです。 ワークフローを使用すると、タスクおよびアクティビティを自動化できます。このトピックでは、ワークフローの主要要素、ワークフローの構成方法およびJSONコード例を示します。 次の機能を利用できます:
- 単一のワークフロー計画に複数のステップを定義します。 参照: 例8: 2ステップのワークフローの実行とRESTコールの検証
- 入力変数の使用を許可するワークフローの再ユーザビリティを向上させます。 参照: 例6: 単一ステップREST変数入力のコール
- ワークフローで「ワークフロー変数およびデータ渡し」を介して変数を参照できるようにします。
- チェーン・ワークフローおよびネスト・ワークフローの場合、ユーザーはステップ実行内から別のワークフローをコールできます。
V2.0ワークフロー要素
- ワークフロー名: ワークフローに付けられた名前。 この名前は、ライブラリ内のワークフローの一意の識別子です。
- 計画: 計画は、各ステップがエンティティで実行する必要があるタスクであるステップのリストです。 計画には、ワークフロー入力を定義するための入力宣言を含めることもできます。
入力宣言: ワークフローの作成者は、パラメータ化を介してワークフロー内で参照されるワークフロー入力を定義できます。 ワークフローの作成者は、string、integerおよびbooleanなどの入力タイプを指定することもできます。 入力タイプは、作成者のニーズに基づいて、必須とマークすることもできます。
ステップのタイプ:
- REST: REST URIワークフローに使用します。 このステップ・タイプには、次の3パラメータがあります:
- URI使用するREST URI。これはrequiredパラメータです。
- 「メソッド」、GETまたはPOSTのいずれか。これはrequiredパラメータです。
- 「ヘッダー」はキー/バリューのペアのマップであり、これはオプションのパラメータです。
- ENTITY: 検出されたエンティティ内でアクションを実行するステップのタイプ。 パラメータには次のプロパティがあります:
- 資格証明: 資格証明は、コマンドが実行されるエンティティに対して認証するために必要です。 エンティティに関連付けられた「エージェント資格証明ストア」で作成した資格証明の名前を参照する必要があります。
- コマンド: エージェントで実行。
- 引数: コマンドに送信する入力。 複数の入力をカンマ区切り値として送信できます。
- stdin: 標準入力を介してコマンドに送信される入力。
- エンティティ: コマンドを実行する必要があります。 エージェントがホストまたはデータベースを監視中です。
- stdout: コマンド実行からの標準出力。
- commandTimeoutは、ステップを終了するためにエンティティ・ワークフローのカスタム・タイムアウトが必要な場合に使用します。 時間は左から右の順に表示されますh: hours, m: 分s: 秒;有効な例: 5m, 1h 10m, 30s. タイムアウトは、24時間を超えることはできず、負のコンポーネントがないか、数値と単位の間に空白がある必要があります。
- WAIT: 待機タイプを使用すると、ユーザーはコマンドを使用して実行フローで遅延を受けることができます。
- waitInSeconds。 最小待機時間は5秒で、最大待機時間は1800秒です(小数は許可されません)。
- WORKFLOW: ワークフロー・タイプにより、ワークフローは親子の方法でネストできます。 ネストされたワークフローには、次の設計仕様が必要です:
- name: ネストされたワークフローの名前(親の名前とは異なる)。
- workflowName: ワークフロー・ライブラリで呼び出されるワークフローの名前
- workflowVersion: ワークフロー・ライブラリ内のワークフローのバージョン。 このパラメータはオプションです。
- input: ネスト・ワークフローに送信する入力。 この入力は、親ワークフローの変数を子ワークフローに渡す必要がある場合に必要です。 ここで入力した入力変数は、ワークフロー・ライブラリで定義された変数によって上書きされます。
ステップ・コンポーネント:
- PRE: ステップ実行を開始するために完了または保証の必要な前提条件。 サポートされているコマンド:
- 「スキップ」前提条件を満たさない場合、ステップをスキップできます。
- POST: ステップの実行が正常に意図されていた内容であるかどうかを確認して、ステップ条件を検証します。 サポートされるコマンド:
- 「再試行」は、実行が成功するまでステップを再試行します。
- 「中止」事後条件を満たさない場合にステップを中止します。
- 「スキップ」ステップの条件が満たされていない場合は、そのステップを完全にスキップします。
- OPERATION: ステップによって実行されるアクション。 これは、定義されたステップ・タイプ(「REST、ENTITY、WAITまたはWORKFLOW」)に基づきます。
- PUBLISH: 変数を介して使用するために後続のステップに渡される情報。
- REST: REST URIワークフローに使用します。 このステップ・タイプには、次の3パラメータがあります:
- 入力: 入力セクションを使用すると、作成者はワークフローの入力宣言に対応する任意のデフォルト入力を指定できます。 ワークフローの送信時に指定したユーザー入力は、ワークフローの送信時に自動的に渡されます。 入力には次の2つの要素があります:
- vars: 変数を定義するJSONオブジェクトで、キーがワークフローのグローバル変数として使用可能になります。
- workerVars: JSONオブジェクトである場合、ワーカーの数とその名前はキーによって定義されます。 すべてのキーに値が必要です。workerVarsは、ローカル・ワーカー変数を定義するvarsと同じ構造になります。 workerVarsで定義された値は、同じ名前を共有するキーのglobal varsオブジェクトに定義されている値をオーバーライドします。 予定されているオーバーライドがない場合は、空のオブジェクトを指定する必要があります。
- ワーカー: 各ワークフロー・ワーカーは、ワークフローの独自のインスタンスを並行して実行します。 ワークフロー・ワーカー・インスタンス間のデータのクロス・トークや同期はありません。 サンプル就業者ワークフローについては、次を表示してください: 例7: 就業者による単一ステップRESTコール
- 通知:ワークフローのステータス更新を受信する電子メール・アドレスのリスト。
V1.0構文を使用したワークフローの作成
ワークフローは、オーケストレーションを使用して自動化できるビジネス・アクティビティの基本的なビルディング・ブロックで、タスクおよびアクティビティを自動化できます。
注意:
現在、V1.0構文は、是正アクション・サポートのためにこのマニュアルにのみ含まれています。 Oracleでは、作成されたすべてのワークフローについてV2.0の構文および定義を先に使用する必要があります。 「バージョン1.0はUI上でサポートされていません」。次に、ワークフローを定義するための標準のV1.0 JSON構造形式を示します:
name
workflow
plan
name
steps
step
step payload
uploadToLA
logSource
input
workflow workers (multiple workers are supported)
workflowProperties
property 1
property 2
...
property n
schedule
notification
表2-1 ワークフロー要素
要素 | 説明 |
---|---|
名前 | ワークフロー提出に与えられた名前。 名前は、ステータスと結果のワークフロー送信を検索するために使用できる識別子です。
注意: ワークフロー・サブミッション名は、特定のテナント・スコープ内で一意である必要はありません。 |
計画 |
各ステップがエンティティまたはREST呼び出しで実行する必要のあるタスクのステップのリスト。
ステップを定義するときに、uploadToLAプロパティをtrueに設定することで、ワークフローの詳細をOracle Log Analyticsに送信するように指定することもできます。 さらに、logSourceプロパティを設定することによって、アップロードされたログをLog Analyticsに知られている既存のログ・ソースに関連付けることができます。 |
ワークフロー・プロパティ |
ワークフロー提出に関連付けることができるキーと値のペアのマップ。 これらのキーと値のペアを使用すると、後である時点でワークフローの提出を検索するのに役立つキーワードを関連付けることができます。
注意: property1、property2、property3、property4、およびproperty5という名前を使用して、最大5つのタグを指定できます。 |
入力 | ワークフローの入力。 入力はvarsとworkerVarsで構成されます。 |
ワーカー |
作業者は、ワークフロー全体の並列度を定義します: 10の異なるホスト間で一連のステップを実行する必要があるユースケース(ENTITY)を考えてみましょう。 同様に、10の異なるエンドポイントに対してREST呼び出しを行う必要があるユースケース(REST)を考えてみましょう。 どちらの場合も、同じステップを異なるホスト名/ポート番号で実行する必要があります。 各実行はworkerです。 計画で指定されたすべてのステップ(現在のリリースでは、1つのステップのみが許可されます)が、指定された入力値を使用するワーカーごとに実行されます。 |
スケジュール |
ワークフローを実行する時間。 たとえば、毎日午後9時または毎週土曜日の午後10時30分にワークフローを実行する必要があるとします。 どちらの場合も、スケジュール情報はワークフロー提出に渡され、スケジュールされた時間にワークフローを実行できるようになります。 |
通知 | ワークフロー・ステータスの更新を受け取る電子メール・アドレスのリスト。 |
{
"name": "Patch Hosts Demo",
"workflow": {
"plan": {
"name": "Patch_Hosts_WF",
"steps": [{
"name": "patch",
"type": "ENTITY",
"input": {
"command": "/bin/sh",
"arguments": ["/scratch/patch.sh"],
"credential": "emcosTestCred"
}
}]
},
"input": {
"workers": {
"thread1": {
"entity": {
"entityByName": {
"name": "example.com",
"type": "omc_host_linux"
}
}
}
}
}
}
}
ワークフロー変数およびデータ渡し
ワークフローでは、内部データと外部出力データの両方で変数を使用できます。
"${workflow.omc.startTime}"
次の例では、言語式のテンプレート作成について説明します:
"${steps['REST step'].result.body}"
"${steps.provisioning.result}"
"${retry[0].vars.result}"
"${2 + 2}" // => 4
"${'foo' + 'bar'}" // => myoutput
- JSON結果タイプの場合:
"${steps.step1.result.myPublish.<json node name>}"
- REGEXの場合:
"${steps.step1.result.myPublish[0]}"