このサイトをビューするために JavaScript を有効化してください。

Altova FlowForce Server 2020

ジョブのステップに失敗すると、 ジョブは中断されます。 (ログ、または、電子メールの送信などのために)ジョブを完全に終了する前に、クリーンアップのアクションを行うには、型 「エラー/成功の処理ステップ」のステップを作成することができます。「保護されたブロック」として参照されるステップを処理するエラー/成功により、ステップの実行を保護することができます。 次の図は、保護されたブロックの構成を表示しています。

ProtectedBlock

保護されたブロックの構造

保護されたブロック内の1つのステップに失敗すると、エラーハンドラーは、ジョブが終了される前に何が起こるかを管理します。エラーハンドラー は以下の内の1つです:

 

成功時 (保護されたブロック内の全てのステップに成功すると、システムにアクションを実行するように命令します)。

エラー時 (保護されたブロック内の1つのステップに成功すると、システムにアクションを実行するように命令します)。

常に (保護されたブロック内のステップの成功に関わらず、システムにアクションを実行するように命令します)。

 

保護されたブロックが実行を完了すると、 FlowForce Server は、出力をベースにした定義されたハンドラーを実行します。 例えば、 上に表示される図では、保護されたブロックは、ステップ A と ステップ B です。また、エラー処理の論理は以下の通りです:

 

A が失敗すると、 A、C および E が実行されます。

B が失敗すると、A、B、C および E が実行されます。

A と B に成功すると、 A、B、D および E が実行されます。

 

実際には、処理する各ジョブのために3つすべてのハンドラーの型を定義する(ことはできますが) 必要はありません。最も一般的なシナリオは 「エラー時」「常に」 ハンドラーのみを定義することです。例えば、下のイメージは、 「エラー時」「常に」 を使用した単純型の保護されたブロックを表示しています。

fs_protected_block_01

最初のステップは、 \system\shell\commandline 関数を呼び出して、 C:\scripts ディレクトリからスクリプトを実行します。 このステップの実行は2つのハンドラーにより保護されています: 「エラー時」「常に」「エラー時」 ハンドラーは最初のステップに失敗するとトリガーされます。 具体的には、最初のステップに失敗すると、エラー処理ステップが件名ライン内に失敗したジョブインスタンスの ID を含む電子メールを送信します。 「常に」 ハンドラーは最初のステップの成功に関わらず無条件で実行されます。このハンドラーはメッセージをthe C:\scripts ディレクトリからのスクリプトを実行してログします。上記に類似したサンプルに関しては、エラー処理をジョブに追加するを参照してください。

 

例外の処理を実行する際の注意点

上記の構成では単一のステップが処理されています。具体的には、ジョブの最初のステップです。複数のステップを処理するには、保護されたブロック内の他のステップの後に追加します。構造に関しては、保護されているブロック内のステップは、標準の処理されていないステップと同様です  (例えば、 関数を実行、式の埋め込み、ループを作成することなどができます)。一部の場合、保護されたブロック内のステップは以下で説明される通り特別な処理を必要とする場合があります。

 

例外ハンドラーは複数の例外ステップを含むことができる点を最初に考慮してください。例えば、 1つのステップはファイルを生成し、他のファイルは生成されたファイルを変換し、3番目のファイルは変換されたファイルを電子メールとして送信します。これは有効な構成です。また、複数の実行ステップを持つハンドラーは複雑性を追加し、エラーハンドラー内でエラーが発生する可能性があるため、慎重に扱われる必要があります。

 

同じハンドラー内に複数のステップが存在する場合、全てが実行されるまで、シーケンス順に、または、ステップが失敗するまで実行されます。ステップの失敗後はステップは実行されません。しかし、ハンドラーに失敗すると、存在する場合外側のハンドラーにより出力が処理されます。

 

この点に対応するために、ハンドラー内のステップの数を制限し、エラーの可能性を制限する必要があるかもしれません。 ハンドラー内部のステップが少ないほうが、ハンドラーの実行が完了する可能性は高いです。後続するステップが前のステップに依存する場合、例えば、このステップのみのために新規のエラーハンドラーを追加し、成功時にのみ依存するステップの実行を継続することができます。

 

更に留意する点は例外ハンドラーから保護されたブロック内の結果を参照することができない点です。理由は、ステップが失敗すると、保護済みのブロックは、定義されていないものになり、定義されていない結果を処理することは不可能だからです。

 

このため、例外ハンドラーを持つ保護されたブロック内に例外ステップが置かれると、例外ハンドラー内の実行ステップの結果にアクセスすることは不可能になります。ハンドラー が 「成功時」「エラー時」 または 「常に」 であることは関係ありません。

 

保護されたブロック内のステップのためにのみ制限を適用することができます。この点をよりよく理解するために、以下のサンプルジョブをよく考慮してください:

fs_protected_block_02

上記で説明されているジョブでは、各ステップに結果が存在します。例えば、最初のステップには、 result1 が、2番目のステップには result2 が存在します。上記のジョブでは、各ステップに結果が存在します。これらの結果の値にアクセスする必要がある場合は、以下の点に注意してください:

 

ステップ 1 は保護されたブロックの外部であるため、後続する他の捨てべのステップにより結果にアクセスすることができます。具体的には、 result1 にステップ 2  またはステップ 3 、およびエラーハンドラーからアクセスすることができます。

ステップ 2 と 3 はハンドラーからではなく同じ保護されたブロックの後続するステップからのみ結果にアクセスすることのできる保護されたブロックの内部に存在します。すなわち、 result2 はステップ 3 からアクセスすることが可能ですが、エラーハンドラーからアクセスすることはできません。後続するステップが存在しないため、result3 にアクセスすることはできません。

最後に、ハンドラー内に存在し、ハンドラーの唯一および最後のステップであるため、エラーハンドラーの結果である result_handler には他のステップからアクセスすることはできません。後続するステップが存在する場合、 result_handler 結果を消費することができます。

 

上記に留意して、保護されたデザインは結果の可視性を構成しています。実際のソリューションは場合により異なります。例えば、 ファイル名を作成するために 「エラー時」 ブロック内のステップの結果が重要な場合、 自身の保護されたブロック (ネストされ保護されたブロック) の内部に含むことができ、failed-step 関数を呼び出して、エラーを含む出力を取得し、ファイルを作成することができます。エラーを引き起こしたステップを識別することはできませんが、この関数は、エラーが発生した場合エラー情報を含む result 型を返します。 result はシェルコマンドを作動する抽象的な結果を表し、MapForce 変換、または、 StyleVision スタイルシートは期待する出力を作成する場合だけではなく、エラーが発生した場合でも処理されることができます。これは、サンプルにより理解することができ、エラー処理をジョブに追加するで詳細に説明されています。

(C) 2019 Altova GmbH