test

N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド

<finally> 要素

<try> ステップの子要素です。<finally> は、<try> または <catch> ステップ内で典型的なエラーが以前に発生したかどうかにかかわらず実行するステップを指定します。典型的なエラーには、プランの中断とプランのタイムアウトがあり、これらのエラーが発生した場合、<finally> 要素のステップはスキップされます。<finally> には、<try> ステップを含んでいるブロックのスコープ内で許可される任意の数のステップを含めることができます。

<finally> 要素は、エラーを考慮することなく常に実行する必要があるクリーンアップステップを指定するために使用されます。エラーに対応してクリーンアップステップを実行するには、代わりに <catch> 要素内にクリーンアップステップを配置します。

例 2–6 <try> ステップの使用方法

以下の例では、コンポーネントのインストールは、再起動があとに続くリソース配備で構成されています。このケースでは、コンポーネントのインストールが完了したと見なされるのは、そのリソースが配備され、再起動時における失敗がそのインストール状態に影響を与えない場合だけです。典型的なエラーは、以下のように再起動時に抑制できます。


<installSteps blockName="default">
    <deployResource/>
    <try>
        <block>
            <call blockName="restart"><thisComponent/></call>
        </block>
        <catch/><!-- すべての典型的なエラーを抑制します -->  
    </try>
</installSteps>

<try> ブロックは、インテリジェントな自動アップグレードのモデル化に使用できます。バージョン 1.1 のコンポーネントが 2 つの異なるインストールルーチンを持っているとします。あるユーザーはコンポーネントのフレッシュインストールを行い、そのコンポーネントのバージョン 1.0 が以前にインストールされていた場合、もう 1 人のユーザーがアップグレードインストールを行います。この状況は、以下のように単一のインストールブロックとしてモデル化できます。


<installSteps blockName="default">
    <try>
        <block>
          <checkDependency>
              <installedComponent name="foo" version="1.0"/>
          </checkDependency>
          <!-- 1.0 のインストールが存在するため、アップグレードを行います -->
        </block>
        <catch>
          <!-- 1.0 のインストールが存在しないため、フレッシュインストールを行います -->
        </catch>
    </try>
</installSteps>

<finally> ブロックは、通常、一時リソースのクリーンアップに使用されます。次の例では、一時ファイルの作成、処理、および削除が行われます。


<control blockName="default">
    <varList>
        <var name="file" default="/tmp/file.txt"/>
    </varList>
    <execNative outputFile=":[file]">
        <exec cmd="ls"><arg value="-l"/></exec>
    </execNative>
    <try>
        <block>
            <!-- 何らかの方法でファイルを処理します -->
        </block>
        <finally>
            <execNative>
                <exec cmd="rm"><arg value=":[file]"/></exec>
            </execNative>
        </finally>
    </try>
</control>