GxPアプリ構築の基本

この記事では、GxP環境でアプリを構築するための基本的な知識を提供します。

この記事は、変数、テーブル、補完レコードなどの基本的なTulipの概念に関する予備知識を前提としています。

言語

アプリのスタイルと言語は、その使用目的に適合している必要があります。標準作業手順書、作業指示書、方法は、命令型の必須スタイルで記述する必要があります。

バージョン管理

アプリを公開するときは、コメント欄に、UIの更新、エラーの修正など、以前に公開したアプリに対する変更の内容を記述することが推奨される。

各ステップで表示される標準的な情報

ユーザーに適切なコンテキストを提供するため、各ステップには以下の要素を表示する必要があります：

• アプリが処理に使用されるメインアイテムの名前または一意のID。「アイテム」とは、使用または処理されているバッチ、オーダー、機器、ツールなどである。場合によっては複数の項目があり得る。ほとんどの場合、アプリの最初にその情報を含むテーブルレコードを作成またはロードすることで達成されるはずです。
• ログインユーザー
• アプリのバージョン
• アプリのステップ名

また、すべてのステップに "Log-off current user "アクションをトリガーするログオフボタンを設置することを推奨します。

タイムスタンプと日付フォーマット

完了記録のタイムスタンプは、タイムゾーンのオフセットを含むUTCで取得されます。日付と時間のフォーマットは、すべてのアプリのインスタンスレベルで設定できます。これはインスタンスの「Settings（設定）」メニューの「Date and Time（日付と時刻）」セクションで行われ、アカウント所有者が設定する必要があります。

電子署名ウィジェットによる電子署名の取得

ER/ES（電子記録/電子署名）規制に準拠するため、署名は署名者にコンテキストを与える必要があります：

• "何"

署名のコンテキスト（バッチ、注文、設備など

• 「なぜ(Why)

署名の理由（プロセスオーダーのリリースなど

署名には以下の構成を推奨する：

• 電子署名が必要なステップをグループ化し、グループ内の最後のステップに電子署名ウィジェットを含める。
• 該当する場合は、ウィジェットの前にサマリーステップを作成し、すべての関連データを表示して、署名者に署名のコンテキスト（「何」）を提供します。
• フォームタイトル（例：「ラベル再印刷のための署名」）とユーザー名ラベル（例：「Supervisor」）を使用して、署名の理由（「Why」）を定義します。

署名が送信されると、Tulipは自動的に追加情報を記録します：

• 「誰が」フォームに署名したか
• 「いつ」署名が送信されたか
• 追加されたコメント

現在のアプリデータを不変の完了レコードにコミットすることが必須です。これには2つの方法があります：

• 署名ウィジェットの送信ボタン上の「カスタムアクション」トリガーで「すべてのアプリデータを保存」アクションを使用する。
• サブミットボタンの標準の "Complete App "設定を使用するか、"Custom Action "トリガーの "Complete App "アクションを使用して、アプリを完了する。

すべてのアプリデータを保存」アクション

Save All App Data "アクションは、すべてのアプリ変数の現在の値と、ロードされたすべてのテーブルレコードの現在のフィールド値を、アプリのCompletionレコードに保存します。Completionレコードは不変であり、削除できません。

アプリの完了

App Completionは、「Save All App Data」アクションと同じ方法でデータを保存します。さらに、App CompletionはすべてのVariablesをデフォルト値にリセットします。さらに、すべてのテーブルレコードプレースホルダがクリアされます。アプリ完了後、同じアプリを最初から再開したり、同じアプリや別のアプリ内の特定のステップに進むことが可能です。これは、完了に使用した「トランジション」で設定できます。

アプリのキャンセル

アプリのキャンセルはアプリの完了と同じですが、すべての変数はデフォルト値にリセットされます。

アプリの自動初期化

実行中に複数回完了する必要があるアプリ（複数の署名など）の場合、各完了の前にコンテキストを保存することを推奨する。コンテキストは、現在のバッチなどのテーブルレコードのIDや、カウンタなどの変数である。アプリのコンテキストは、"App Info：レコード ID として "Station Name "を使用する。このレコードは "App Started "トリガーを使ってアプリの（再）開始時にロードすることができる。同じアプローチで、別のアプリへのシームレスな移行を実現できる。

同様の原理は、自動ログアウトやプレーヤーメニューの「Restart」選択などによるアプリのキャンセル後にアプリの実行を再開する場合にも適用できます。これらの使用例では、再起動後に開くAppの追加コンテキスト情報として、ステップ名を保存することを推奨します。これは、最後に表示されたステップの名前でも、回復のために開くべき特定のステップでもかまいません。

例外と例外によるレビューの有効化

アプリの実行中に発生するすべての例外を照合するために、1つのチューリップテーブルを使用することを推奨します。すべての例外（欠陥、観察など）は、その例外に関するすべての関連情報（タイプ、説明、日付/時刻、アプリ、オペレータなど）を含む単一のレコードとして、そのチューリップテーブルに格納されるべきである。さらにこのレコードは、例外に関連するすべての成果物（バッチ、オーダー、材料、設備、部屋など）のレコードに「リンクレコード」機能を使ってリンクされるべきである。

記録、記録訂正、記録履歴

GxP関連データをレコードとして、バッチ、オーダー、材料、設備、部屋など、関連するアーティファクトを参照しながらチューリップテーブルに保存することを推奨します。

GxP関連データの変更は記録履歴に反映されるため、元の記録内で修正することを推奨します。訂正は署名フォームで提出する。

記録の検索を容易にするため、すべての項目に"-"のような明確で体系的なIDを割り当てることを推奨する。

記録の履歴

上述したように、変数の値は、アプリの完了またはキャンセル時に完了レコードに保存される。一方、テーブルのデータ操作はリアルタイムで行われる。テーブルレコードのどのフィールドへの変更も、自動的にコンテキスト情報（ユーザー、アプリ、アプリバージョン、ステーション、タイムスタンプ）とともにTulipによって記録されます。

すべてのTulipテーブルレコードには、レコード履歴があります。このレコード履歴は、コンテキスト情報（ユーザー、アプリ、アプリのバージョン、駅、タイムスタンプ）を含む、ログに記録されたすべての変更を表示します。

さらに、レコード履歴は、レコードが含まれるアプリの完了またはキャンセルのデータを表示します。これには、それらの完了/キャンセルで記録された電子署名も含まれます。署名は、実行されたタイムスタンプに従って、記録履歴のタイムラインに表示されます。その他のすべての完了データは、完了/キャンセルのタイムスタンプで表示されます。

さらに読む

• GxPのベストプラクティス
• 記録履歴ウィジェットの使用
• アプリデータのエクスポート方法