# ラベルとレポートの発行

> 実行が開始時と完了時に何を出すか、どの順で、どのキューを通して出すか、実行記録ファイルに何が固定されるか、そして送信のすべてがどう記録されるかを説明します。

実行は、自分のモデルの**アクション**を通して書類を出します。アクションは名前を付けた指令のまとまりで、どの指令も、実行の開始時か完了時にラベルかレポートを 1 つ出します。アクションは段取り > [アクション](process-actions)の下で宣言し、[手順](process-procedures)がまとまりのまま選びます。指令が描くのに使うテンプレートは、この根にある 2 つのライブラリです。レポートの指令の様式は[レポート](process-reports)から、ラベルの指令のファイルは[ラベル](process-labels)から来ます。このページは、実行が区切りに届いてから起きることです。

## 2 つの区切り {#the-two-boundaries}

区切りでは、選ばれたまとまりの間ではモデルの一覧の順に、各まとまりの中ではそのまとまり自身の順に指令が撃たれ、ラベルがレポートより先に出ます。どの指令も切り離されています。テンプレートが見つからないこと、組み立てが例外を投げること、キューが拒むことは、診断ログに残り、実行については何も変えず、その後ろの指令を止めることも決してありません。

| 区切り | いつ | 何が使えるか | 何が出るか |
| --- | --- | --- | --- |
| 開始 | 実行が実体になるとき、連番のカウンターが確保され、メタデータが書かれた後です。文書を組み立てている間、実行はもう記録しており、実行自身の開いたファイルを通して組み立てます。 | 実行記録の識別情報、メタデータ、開始の時点、そして「実行中」の状態です。 | 発行タイミングが開始のすべてのラベルの指令と、発行タイミングが開始で様式のあるすべてのレポートの指令です。後者は、まだ根拠のない章を省き、レシピの行に計画したレシピを印字する用紙になります。 |
| 完了 | 実行の最終状態とスナップショットに封がされ、ユニットが放されてからです。ラベルが先で、レポートはそのすぐ後、背後で出ます。 | 開始時のものすべてに加えて、終了の時点、所要時間、最終状態、総合判定、終了の理由、そして判定した判定基準です。 | 発行タイミングが完了で、総合判定の絞り込みがその実行の総合判定を受け入れる、すべてのラベルとレポートの指令です。 |

総合判定の絞り込み（合格、不合格、判定不能、総合判定なし）が読まれるのは完了時だけです。開始時には、まだ総合判定がありません。失敗で終わった実行には最終のスナップショットがないので、その完了のラベルは失敗した成果物を記録し、完了のレポートは発行されません。様式が削除されたレポートの指令と、様式のないレポートの指令は、何も発行しません。アプリケーションを立ち上げ直しても、開始の文書が繰り返されることは決してありません。立ち上げ直したあとに再び現れた実行は、すでに出した成果物を持っています。

## レポート {#reports}

様式のあるレポートの指令は、ほかに何を求めていようと、自分の区切りで PDF を発行します。ファイルは、実行記録の書き出しの基本の名前に、まとまりの名前を足して名付けられるので（`<base> - <group>.pdf`）、1 件の実行記録の用紙と締めのレポートが並んで立ちます。名前が同じファイルになってしまう 2 つのまとまりは、指令の識別情報で区別されます。同じ指令をあとで作り直すと、その指令の文書だけが置き換わり、ほかは変わりません。指令の 2 つの選択肢が、その文書に何が起きるかを決めます。

| 選択肢 | 効果 |
| --- | --- |
| 自動で印刷する | 発行した PDF は、その区切りについてそのユニットに効いているレポートのキューにも送られます。その枠にキューのないユニットは、その試みを失敗として記録します（「このアクションについて、ユニットに印刷キューが設定されていません。」）。 |
| 実行記録の中に残す | できあがった PDF が実行記録ファイルの中に保存されるので、様式を編集したり削除したりした後でも、発行したファイルが後の作り直しで置き換わった後でも、再送はそのバイト列そのものを送ります。そのぶん、実行記録はその文書の大きさを持ちます。 |

どちらかを求めた指令は、その文書を実行記録に登録します（履歴が**レポート**の下に並べる登録です）。どちらも求めなかった指令はファイルを発行して何も登録しません。作成は実行記録ファイルの書き出しであって、そこへの書き込みでは決してないからです。

## ラベル {#labels}

ラベルの指令は、差し込み項目 1 つにつき 1 つの取得元で、自分のテンプレートを描きます。開始時に解決するのは、受け付けられた開始の時点で確定した取得元だけです。メタデータ、モデルの名前と版、ユニットの名前とコード、手順の名前とコード、実行記録の識別子、開始の時点、そして実行記録の状態です。それ以外に対応付けられた差し込み項目は、開始のラベルを拒みます（「差し込み項目 '{{RESULT}}' は、実行が始まるときには使えません。」）。完了時には目録の全体が解決し、判定基準の結果は、その変わらない識別情報と、はっきり指定したサイクルで解決します（サイクルの欠落が「最新」を意味することは決してありません）。

作成のたびに、まず変わらない**成果物**が実行記録ファイルに追記されます。最終の指令のバイト列、テンプレートの名前、元のファイル、内容のハッシュ、まとまりの名前、発行タイミング、解決した値とその取得元、または指令を 1 つも作れなかった理由です。それから、そのバイト列が、その区切りについてそのユニットに効いているラベルのキューへ、`Ganter Lab · <group>` という名前の RAW の文書として送られます。その枠にキューのないユニットは、失敗した試みを記録します（「このラベルについて、ユニットに印刷キューが設定されていません。」）。テンプレートが消えているときは「設定されたラベルのテンプレートが見つかりません。」と記録します。送信の試みはすべて成果物に追記されます。スプーラーを呼ぶ前に**送信中**、そのあと**キューに送信済み**か**失敗**です。途中でアプリが止まった試みは**送信は不確定**のまま残り、自動でやり直されることは決してありません。プリンターがもうラベルを出しているかもしれないからです。「キューに送信済み」は、Windows が中身を受け付けたことの確認であって、紙が出たことの確認ではありません。

## プリンター {#printers}

文書がどのキューに入るかは、定義 > [プリンター](process-printers)で決まります。モデルは 4 つの既定の枠を宣言し、それぞれが、何を出すかといつ出すかの組み合わせ 1 つ（ラベルかレポートか、開始時か完了時か）に対応します。各ユニットは、モデルの 4 つに従うか、自分の 4 つを持ちます。指令は、自分の種類と発行タイミングで送り先を解決します。従っているユニットではモデルを通して、切り離したユニットではそのユニットの枠を通してです。ですから、2 つの手順が共有するまとまりは、1 度選んだ 1 つの送り先を通して印刷されます。キューは、ステーションが動いている利用者にインストールされている Windows の印刷キューです。ラベルは RAW のバイト列として出ていき、レポートは画素に描き直されて装置に描かれるので、ふつうの文書用のプリンターがレポートを、ラベルプリンターがラベルを受け持ちます。

## そのあと {#afterwards}

実行が出したものはすべて、履歴のその記録で読めます（[ラベルとレポート](histories-documents)）。成果物、登録、そして状態の付いたすべての試みです。そこでは、2 つの媒体に同じ 1 対の操作があります。実行記録が固定した証跡から**新しい**文書を作ること（設定された指令か、手で対応付けたテンプレートで新しいラベルを、どの様式でも新しい PDF を）と、記録されたものを**出し直す**こと（成果物の固定したバイト列を再印刷し、登録された PDF を再送すること）で、後者は何も解決し直しません。

## 発行がしないこと {#what-emission-does-not-do}

実時間の値を読むことは決してありません。ラベルは実行記録ファイルが固定したものだけを解決し、レポートはそのファイルからだけ描かれます。実行を変えることも決してありません。文書が失敗しても、総合判定も、状態も、ファイルも、そのままです。印刷されたことを確かめることもありません。そして、スナップショットやその場で判定の実行のために出すことも決してありません。それらは手順もアクションも持たないからです。