eDocArrangement2を使った自動処理入門
エラー処理 Error handling
エラー処理は大きく業務的なエラー処理と例外発生時（想定外）のエラー処理に分けられます。本記事では両者の考え方と実装・運用の要点を、具体例を交えて解説します。
-
業務的なエラー処理（入力検証・前提条件の不備）
-
例外発生時のエラー処理（環境障害・想定外事象）
業務的なエラー処理 Business/domain errors
仕様で明文化できる「期待からのズレ」を検出して、安全にやり直せる・修正できるよう導くための処理です。
例えば、以下のような業務処理を考えてみます。
作業者が以下の処理を行う。
-
FAXアプリケーションによって、FAXフォルダにyyyymmdd形式のファイル名で文書が格納される。
-
文書ファイルを開いて「受注日:2025/5/3」のようなアノテーションを手入力して貼り付ける。
-
監視フォルダに文書ファイルを投入する。
eDocArrangement2で以下の処理を行う。
-
フォルダを監視してファイルを検出したら以下の処理を実行する。
-
「受注日:」で始まるアノテーションを検索して、:の後ろの受注日を取得する。
-
受注日を文書属性に日付型で登録する。
-
ファイル名を受信日として文書属性に日付型で登録する。
-
処理済みフォルダに移動する。
エラー処理の検討
-
受注日のアノテーションが貼られていない場合がある。
-
受注日は手入力されるため入力ミスが発生する可能性がある。
-
文書属性の日付型は空文字や日付形式以外の文字を登録するとエラーが発生する。
-
入力ファイル名はyyyymmddの形式でアプリケーションが付与する。
このように処理で発生する可能性のある事象を、設計の段階で漏れなく予測・想像することが重要です。
順番に具体的なエラー処理を実装していきます。
受注日の空文字チェック
アノテーション取得1でテキストを正規表現検索する条件を追加して、正規表現の値に「受注日:([0-9/]+)」と入力した場合、以下のマクロで受注日:の後ろの日付が取得できます。
{%GET_U(DWアノテーション取得1,1,CapturedTexts,1,1)}
取得した文字をユーザーデータ(属性,受注日)にセットします。
{%SET_U(属性,受注日,{%GET_U(DWアノテーション取得1,1,CapturedTexts,1,1)})}
アノテーションが見つからない場合や数字と/以外の文字の場合は空文字になるので、条件文で空文字の判定を行います。
#受注日が空の場合は判定をFalseに設定
{%IF({%GET_U(属性,受注日)}=,
{%SET_U(属性,判定,False)}
,)}
受注日の日付形式チェック
空文字以外の場合は日付形式と判断してよいでしょうか？
例えば2025/13/1のように12をタイプミスして13になっているようなケースも考えられます。そのようなデータもエラーとして検出するために日付形式判定マクロ(IS_DATE)を用意しています。
そして日付形式判定がTrueなら文書属性にセットします。
#アノテーションから取得した値をユーザーデータにセットする
{%SET_U(属性,受注日,{%GET_U(DWアノテーション取得1,1,CapturedTexts,1,1)})}
#受注日が空の場合は判定をFalseに設定
{%IF({%GET_U(属性,受注日)}=,
{%SET_U(属性,判定,False)}
,
#受注日が空でない場合
{%IF({%IS_DATE({%GET_U(属性,受注日)})}=True,
#受注日が日付形式である場合
{%SET_U(属性,判定,True)}
#受注日を文書属性に設定
{%DW_SET_DOCUMENT_ATTRIBUTE({%DW_GET(OpenName)},受注日,{%GET_U(属性,受注日)},Date)}
,
#受注日が日付形式でない場合
{%SET_U(属性,判定,False)}
)}
)}
このようなマクロにすることで、受注日の入力チェックを行って日付形式である場合のみ文書属性に設定されるので文書属性登録時の形式エラーが発生しなくなります。
また、「{%GET_U(属性,判定)}」を条件分岐の条件にすれば、移動処理で正常な場合とエラーの場合で処理を分岐できます。
入力ファイル名のチェック
入力ファイルは他のアプリケーションがプログラムで付与するので、毎回必ず同じフォーマットになるのであれば、エラーチェックは行わなくてもよいでしょう。
例外発生時のエラー処理 Exception / unexpected errors
ファイル破損、ネットワーク断、ディスク障害など、通常は起こらない想定外のエラーに対する処理です。
例外エラーはプログラミングにおいて、とても対策が難しい現象です。プログラミングは論理的な考えに基づいて組み立てていきますが、例外エラーはハードの故障・不調などアナログ的に発生する場合があるので、すべての例外エラーに対応するのは極めて難しいです。
そのため、一般的なプログラム言語ではプログラムを広域にグループ化して、そのグループ内で発生した例外エラーを1か所で検知するtry～catch構文を実装しているものが多くあります。
eDocArrangement2でもファイルループなどの処理単位でtry～catch構文を使って例外エラーを検出できるようにしています。
条件分岐処理で「エラー回数で判定」を選択すると条件分岐の前で発生したエラーの有無で条件分岐できます。
下図のような設定では、XDW文書オープン1～XDW文書クローズ1までの処理のどこかでエラーが発生した場合に、対象ファイルをエラーフォルダに移動するようにする場合、文書クローズ1の直後に条件分岐を挿入すればよいです。
以下のように満たしている場合の処理に、業務処理のエラー判定の条件分岐を配置します。また、満たしていない場合の処理にエラーフォルダへの文書移動の処理を追加します。
例外処理の限界
このように例外エラー発生時の処理を用意しても、入力のファイルやフォルダ、出力フォルダへのアクセスが不能となった場合は、エラーフォルダに移動するファイル移動3の処理が失敗します。
そうなると、エラー処理が失敗した場合のエラー処理を行うようにするのか検討することになります。
そもそも例外エラーはハードが堅牢に動作していれば発生しません。まれに発生する問題に対してどこまでコストをかけるかという設計の話になります。
例えば、飛行機や電車などの交通インフラや医療機器などの人の生命にかかわるようなシステムは、ハードウエア、ソフトウエア共に、何重にも対策を行って障害対策を行っていますが、それでも100%障害が発生しないシステムを作るのは不可能だと思います。
そして対策を行うにはコストがかかります。プログラムであれば仕様の追加と実装、テストなどの費用がかかります。
まれに発生するかもしれない、発生しないかもしれない処理のためにどれだけ時間とお金を使って対策を行うかユーザー様と一緒に考えてみてください。
メール通知
eDocArrangement2ではメールサーバー設定でメールサーバーを登録しておくと、以下のマクロでメールを送信することができます。
{%SET_U(宛先,1,tom@test.com)}
{%SEND_MAIL(メールサーバー1,宛先,jerry@test.com,,,eDocArrangement2通知,例外エラーを検知しました。ログを確認してください。)}
例外エラーはハードディスクが故障するなど、忘れた頃に発生したりしますので、メール通知でお知らせするのは有効な手段かと思います。
但し、メールはメールサーバーやインターネットを使いますので、そこで障害が発生している場合にはメールが送信先に届かない可能性もあります。ここでもまた、どこまで対処を行うか検討が必要です。