test

N1 Service Provisioning System 4.1 リファレンスガイド

try 手順の例

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


<installSteps blockName="default">
	<deployResource/>
	<try>
		<block>
			<call blockName="restart"><thisComponent/></call>
		</block>
		<catch/><!-- suppress all typical errors -->  
	</try>
</installSteps>

try ブロックは、インテリジェントな自動アップグレードをモデル化するためにも使用できます。 バージョン 1.1 のコンポーネントが存在し、バージョン 1.0 を以前にインストールしたことがあるかどうかに基づいて選択できる 2 つの異なるインストールルーチン、フレッシュインストールとアップグレードインストールが存在する場合を考えてみます。 このケースは、以下のように単一のインストールブロックとしてモデル化できます。 


<installSteps blockName="default">
	<try>
		<block>
			<checkDependency>
				<installedComponent name="foo" version="1.0"/>
			</checkDependency>
			<!-- 1.0 install exists, do upgrade -->
		</block>
		<catch>
			<!-- 1.0 install doesn"t exist, do fresh install -->
		</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>
			<!-- process file in some way -->
		</block>
		<finally>
			<execNative>
				<exec cmd="rm"><arg value=":[file]"/></exec>
			</execNative>
		</finally>
	</try>
</control>