プログラミングジョブの作成
powerShellをoperationManagerで実行してみます。
Windowsのタスクでも出来るんですけど、せっかくジョブを実行できるソフトがあるので、こちらを使います。
実行するスクリプトはこれ。
D:\script\pingChk.ps1
実際の設定は、こんな感じ。
環境によっては、コマンドの「v1.0」の部分が変わるんでしょうかね。
Ver.上げる気が無いので、確認できませんけどね。
他のタグの設定は、初期値のままにします。
スクリプト
「pingChk.ps1」の内容です。
ロジック部分は長いので省略してます。やってることはpingとかなんで、別の記事（下段リンク「目次」）からご覧ください。
# フォルダ構成を定義
[System.String]$RootDIR = 'D:\script'
[System.String]$LogDIR = $RootDIR + '\log' # ログ
# 処理開始時点での日時情報
[System.String]$OpeDate = Get-Date -format yyyyMMdd_HHmmss
# ログファイル定義
[System.String]$LogName = $LogDIR + '\' + $OpeDate + '.log'
[boolean]$LogDateTrue = 1 # ログ出力関数用 「日時を追加する」
[boolean]$LogDateFalse = 0 # ログ出力関数用 「日時を追加しない」
# ----------------------
# ログ出力用関数
# ----------------------
# 【機能概要】
# メッセージを、画面とテキストファイルに追加書込みします。
# 出力時に日時を追加表示することも可能です。
# 【引数】
# msg 表示するメッセージ
# file 出力するテキストファイルの完全パス
# dspTimeFlag メッセージへの日時に追加出力（0:追加しない, 1:追加する）
function msgOutput([String]$msg, [String]$file, [boolean]$dspTimeFlag) {
if ($dspTimeFlag) {
$WkLogTimeMsg = Get-Date -format yyyy/MM/dd-HH:mm:ss
Write-Host ($msg + ' : ' + $WkLogTimeMsg)
Write-Output ($msg + ' : ' + $WkLogTimeMsg) | out-file $file Default -append
} else {
Write-Host $msg
Write-Output $msg | out-file $file Default -append
}
}
# ----------------------
# エラートラップ関数
# ----------------------
# 【機能概要】
# 各スクリプトのtrapで実行するエラー共通処理です。
# ログと画面にエラー内容を出力します。
function errorTrap() {
msgOutput '' $LogName 0
msgOutput '□□□□□□□□□□□□□□□□□□□□□□' $LogName $LogDateFalse
msgOutput '□' $LogName $LogDateFalse
msgOutput '□ 異常終了しました。' $LogName $LogDateFalse
msgOutput '□' $LogName $LogDateFalse
$Error[0] # ログ関数に渡すと、エラー発生個所とかが消えるので直接ログに
Write-Output $Error[0] | out-file $LogName Default -Append # 書込みを行います。画面にも表示したいので２行になります。
msgOutput '□' $LogName $LogDateFalse
msgOutput '□□□□□□□□□□□□□□□□□□□□□□' $LogName $LogDateFalse
}
# エラートラップを準備します。
trap {
errorTrap
exit 99
}
# 処理開始
msgOutput '□□□□□□□□□□□□□□□□□□□' $LogName $LogDateFalse
msgOutput '死活監視を開始します。' $LogName $LogDateTrue
msgOutput '□□□□□□□□□□□□□□□□□□□' $LogName $LogDateFalse
msgOutput '' $LogName $LogDateFalse
*** ロジック ***
# 正常終了
msgOutput '□□□□□□□□□□□□□□□□□□□' $LogName $LogDateFalse
msgOutput '死活監視を終了しました。' $LogName $LogDateTrue
msgOutput '□□□□□□□□□□□□□□□□□□□' $LogName $LogDateFalse
exit 0
スクリプトのエラーコードはexitの後に数値を入れることで設定できるようです。
なので、処理の先頭でエラートラップを仕込んで、異常時にはエラーコード「99」が返却されるようにします。
処理が最後まで実行された場合には「0」が返却されるようにします。
テスト
スクリプト自体は、事前に手動で動作を確認しておきます。
んで、さっそくoperationManagerから起動してみると見事に異常終了しました。
Windowsサーバーが64bit版で、operationManagerが32bit版である関係で、実行時ポリシーの設定を32bit用のpowerShellに対して設定しないといけなかったようです。
詳細はこちらを参照 http://harikofu.blog.fc2.com/blog-entry-36.html
ポリシーを設定して再度実行すると、またまたエラーが出る。
なんだろ？
実験しましょう
発生条件を掴むために、いろいろと実験してみました。
test.ps1
# エラートラップの設定
# 全てのエラーを捉えたいので、ErrorActionPreferenceにstopを設定
$ErrorActionPreference = "Stop" # Stop(停止), Inquire ( 問い合わせ ), Continue ( 続行 )
Write-Host ('テスト開始')
& 'D:\script\testBat.bat'
Write-Host ('テスト終了')
# -----------------------------
# 正常終了
# -----------------------------
Write-Host ('正常終了')
exit 0
# ----------------------
# エラートラップ
# ----------------------
trap {
Write-Host ('異常終了')
$Error[0]
exit 99
}
testBat.bat
exit
単純に、powerShellからバッチを実行するだけの処理です。
実際に、これを実行した結果が下記のログです。
テスト開始
D:\script>exit
異常終了
Write-Host : OS ハンドルの位置が FileStream が予期していた位置ではありませんで
した。FileStream 内と Win32 コード内または別の FileStream 内で 1 つのハンドルを
同時に使用しないでください。データが失われる可能性があります。
発生場所 D:\script\test.ps1:10 文字:11
+ Write-Host <<<< ('テスト終了')
+ CategoryInfo : NotSpecified: (:) [Write-Host]、IOException
+ FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Comma
nds.WriteHostCommand
ふむ、どうやらpowerShellから別のジョブを実行するとエラーになるようです。
バッチファイルの他に、Oracleのエクスポートなども試して見ましたが、同じように異常終了します。
ちなみに、powerShellからpowerShellの実行は問題なく動作しました。
サポートセンターに聞いてみた
正直、お手上げです。
なので、サポートセンターに上記のスクリプトを送って原因を教えてもらうことにしました。
実行ポリシーの部分でも書きましたけど、サーバが64bit版でoperationManagerが32bit版の時に、こういう現象が発生するらしいです。
operationManagerが32bit版の場合、powerShellは32bit版で実行され、その結果、ジョブが正しく動作しないらしいです。
はっきりとは言ってませんでしたが、operationManagerは悪くなくて、Microsoft側の問題という感じの回答に聞こえました。
...なんか、納得し難いですね。
32bit用のpowerShellで手動実行しても正常終了するわけだし、operationManager側で対応できないものなんだろうか？
うーん、JP1だとどうなんだろうなぁ？
スケジュール登録
まぁ、特定条件下で動かないってのは、よくある話なので回避策をとる事にします。
やりようは、いくらでもありますしね。
今回は、外部バッチを実行していた部分をoperationManagerから直接実行させることにしました。
後は、実行スケジュールは、毎朝実行するように設定して完了です。
富士通SupportDesk
サポートセンターって書いてますけど、実際は「富士通SupportDesk」ですね。
数回使った感想としては、結構頼りになると感じてます。
今回は「もう少しなんとかならんか？」と思う回答ではありましたが、operationManagerって製品自体に回避策が無い以上、サポートデスクとしては、これ以上の回答は出来ないでしょうしね。
投稿記事の一覧：目次
スポンサードリンク
0
0
