XML-INTOと操作エレメント
こんにちは、Jon
注: この記事に記載のコードはここからダウンロードできます。
XML 文書を別のプログラムに渡して最終処理をする前に、非常に基本的な前処理を行う RPG プログラムを操作しています。プログラムは動作するのですが、エラー・メッセージが入ったジョブ・ログで一杯になってしまいます。どうしたらこれを取り除けるでしょうか？
XML 構造は次のようになっています。
<Payload> エレメントには <Event>、<Report>、または <Parameter> の子エレメントが入っています。このうち一度に 1 つのエレメントだけがメッセージに入っています。<Event> の場合、PGMA を呼び出しています。<Report> の場合、PGMB を呼び出しています。<Parameter> の場合、PGMC を呼び出しています。
次の XML-INTO を使用して、エレメントがあるかどうか確認しています。
これは問題なく動作します。エラーがない場合、<Event> エレメントが存在し、PGMA が呼び出されています。エラーが返された場合、<Report> エレメントがないか確認して PGMB を呼び出します。エラーがない場合、<Parameter> がないか確認して PGMC を呼び出します。
このアプローチの欠点は、XML-INTO が失敗するごとに、多数のエラー・メッセージがジョブ・ログに生成されることです。メッセージはこうなります。「The XML document does not match the RPG variable; reason code 1. (XML 文書が RPG 変数と一致しません。理由コード 1)」(RNX0353)。「allowingmissing=yes」オプションがこうしたエラーを抑制してくれると期待したのですが、だめでした。
ジョブ・ログのこうしたエラーを回避しながら、エレメントが存在するかどうか、どのように判断できるか教えてくれませんか？XML-SAX は非常に複雑そうなので使うのは避けたいです。特定のエレメントが存在するかという点だけ知りたいのです。このプログラムのエレメント値は気にしていませんが、特定の子エレメントが存在するかどうかだけが気になります。
--Josh
こんにちは、Josh
まず言わせていただきたいのですが、エラー条件を使用するという、元々の解決法は奇抜なやり方でしたね。正直私なら、そのようにやることは思いもよらなかっただろうと思います。私が提案する解決法を示した後に、(ログ中のエラー・メッセージではなく) そのアプローチの問題点について少しお話しします。
これをうまくやる「隠し味」の基本レシピについては、Four Hundred Guru の XML-INTO シリーズのパート 2 と パート 3 で説明しました。しかし、こうした状況での使用法をしっかり説明していなかった点は認めます。
使用する必要があるオプションは countprefix です。これは主に、文書内で特定のエレメントが何回繰り返されているか判断するように設計されたものですが、オプションのエレメントが存在するかどうか判断する場合にも使用できます。
カウントの定義がどのようになっているか示す、修正版のデータ構造体を次に示します。
また、これを使用する XML-INTO は次のように変わります。
XML-INTO が完了したら、単に「count_」変数をテストしてエレメントが存在するかどうか判断します。次のようになります。
これが「allowmissing=yes」オプションを指定しなくても動作する理由は、他に通知する手段がない場合に RPG はエレメントが「見当たらない」と見なすためです。カウントを提供することで、エレメントが存在するかどうかに関して通知する手段を提供し、エラーは生成されません。
いくつか注意事項を述べさせてください。
メールでエレメント値については気にしていないとおっしゃっていましたが、XML-INTO に文書を完全に処理させ、結果生じたデータ構造体コンポーネントを呼び出しているプログラムに渡すのが良いと考えます。これが気が進まないなら、「allowextra=yes」を追加する必要があるでしょう。このオプションがないと、コンパイラーは <Event>、<Report>、<Parameter> 各エレメントの子エレメントをエラー条件として処理するからです。
「Allowextra」は、こうしたケースなど、ほとんどの場合で十分に安全が確保されていますが、他に選択肢がない場合を除いて、「allowmissing」は絶対に使用しないでください。非常に危険なオプションです。理由は、そのオプションを指定すると、文書全体が空になる可能性があり、その場合エラー信号は発信されないためです。V5R4 では選択の余地がありませんでしたが、今では優れたオプションがあります。
固定フォーマットとフリー・フォーマットの両方で、説明した技法の基本をデモンストレーションする、サンプルの RPG プログラムがあります。これらを試してみたい方は、コードをここからダウンロードできます。
最後に、元々のエラーを引き起こすアプローチについてコメントを 1 つ。そのアプローチは、こうした単純なケースでのみうまくいくことを認識してください。例えば、Message または Payload が繰り返しエレメントだった (または他の繰り返しエレメント内で入れ子になっていた) 場合、これは使用されなかった可能性があります。私がここで示した解決法は、あらゆる条件下でうまく機能します。
多くの場合、特に <Event>、<Report>、および <Parameter> の子エレメントを構文解析したくない場合、XML-SAX が最適なアプローチだったでしょう。このトピックの今後のヒントに注目すれば、私の言わんとすることがわかるでしょう。しかし、あらゆるアプローチの中で、この特定の問題に対する最もシンプルなアプローチは、単に %Scan を使用して必要なエレメントが存在するかどうか確認することでしょう。例を挙げます。
などなど。
上手くいくことを祈っています。
