財務と運用アプリのメッセージング システム

  • [アーティクル]

この記事では、財務と運用アプリの豊富で強力なメッセージング システムについて説明します。

このエクスペリエンスを改善するために、財務と運用アプリ用に新しいメッセージング システムが作成されました。 以前のバージョンと比較すると、財務と運用アプリのメッセージング システムには次の機能が含まれています:

  • コンテキストのあるメッセージの関連性が強化されました (フォームとグローバル)。
  • 中断のレベル (なし、軽微、および中断) を強化しました。
  • メッセージの種類間での明確さと、その用途が強化されました。
  • メッセージを表示するために使用されるコントロールは、フォーム コンテキストに基づいて deterministic です。

ユーザーにメッセージを提示できる場所は?

財務と運用アプリのメッセージは、通常、メッセージ バー、アクション センター、またはメッセージ ボックスのいずれかの場所に表示されます。

メッセージ バー – 現在のページの同期タスクのメッセージ

メッセージ バーは、基本ページやドロップ ダイアログおよびスライダー ダイアログで利用できます。 メッセージ バーは、主にデータ検証に使用されます。 また、日付有効性のために使用されるメッセージなど、ページまたはデータの状態に関するメッセージの通信にも使用できます。 メッセージ バーでは、情報、警告、およびエラーのステータスを表示できます。 すぐにユーザーの注目が必要なメッセージには、メッセージ バーを使用しないください。 メッセージ バーは、メッセージが最初に受け取られたときに表示されます。また、現在のページに関してのみのメッセージを伝達するのに使用する必要があります。 メッセージ バーに送信されるメッセージは、現在のページに関連付けられます。 したがって、ユーザーがメッセージ バーを含むページから離れて移動すると、それらのメッセージは新しいページに表示されません。 ただし、ユーザーが元のページに戻ってくる場合、ページのメッセージが再度表示されます。 メッセージに次の情報を含めます。

  • このメッセージを生成した条件。
  • ユーザーがメッセージを生成した状態を解決せずに続行した場合の結果。

例

This customer is marked as inactive.

Customer validation has failed.

The transaction on voucher do not balance.

プレゼンテーション

メッセージ バーのスクリーン ショット。

アクション センター - 非同期タスクからのメッセージ

アクション センターは、ナビゲーション バーに配置されます。 ユーザーによる迅速なアクションを必要とせず、現在の作業を続行するために必要ではないメッセージが含まれています。 一般的な例にとしては、バッチ ジョブやレポート完了などのバック グラウンド処理からのフィードバックがあります。 アクション センターでは、情報、警告、および エラー の各ステータスを表示できます。 アクション センターは、開かれる前に前回開いたときから受信したメッセージの数を示します。

アクション センターには、最大で 500 件のメッセージを保持できます。 その後、メッセージは最初に表示されたものから順にサイクルします。

メッセージ ボックス – エラーや即時の通知 (完了した同期操作)

メッセージ ボックスを使用して、すぐに注意が必要な問題についてユーザーに警告します。 メッセージ ボックスはユーザーを中断して、メッセージが読み取られたり消されるまでユーザーの続行が妨げられるため、ユーザーが後で処理できないメッセージに対してのみ使用する必要があります。 メッセージ ボックスに表示されるエラー メッセージに次の情報を含めます。

  • 発生したエラー。
  • エラーの原因。
  • エラーを解決する方法に関する情報。

エラー メッセージは次の 2 つのコンポーネントを含める必要があります。

  • 主要な命令 – このテキストは太字で表示されます。
  • メッセージの詳細 – このテキストは主要な命令の下に表示されます。

例

  • 参照番号がバージョン %1 で使用されるので、参照番号を削除することはできません。
  • このエクスポートを実行するのに十分な権限があります。
  • カタログ インポート処理用のルート フォルダーが構成されていません。 仕入先カタログ インポート パラメータ フォームを使用してルート フォルダをコンフィギュレーションします。

プレゼンテーション

エラー メッセージの例。

エラー タイプのメッセージでは、メッセージを含むモーダルの「明るい色のボックス」で現在のページにオーバーレイすることでユーザーの操作をブロックします。

通知、警告、またはエラーをユーザーに表示する必要がありますか。

財務と運用アプリの以前のバージョンでは、これまで、情報、警告 (checkFailed)、およびエラーの状態は、シナリオ間で常に一貫して使用されていませんでした。 メッセージは、あるシナリオでは警告として、別のシナリオではエラーとして報告される場合があります。 表す状態を決定するとき、次の定義を使用します。

  • 通知 – 通知は、現在のユーザー活動に関係する可能性のあるイベントまたは関係しない可能性のあるイベントについてユーザーに通知します。 この通知は、ユーザー アクションまたはシステム イベントによって発生する場合があります。または、有用なプログラムからの情報を提供することができます。 通知は通常、即時のユーザー操作を必要としません。 info() アプリケーション プログラミング インターフェイス (API) を使用してユーザーに通知します。

  • 警告 – 警告は、今後問題が発生する可能性のある状態についてユーザーに警告します。 具体的には、警告は無効な状態のデータに使用されます。 無効なデータを使用するとエラーが発生するかもしれませんが、現状データの間違いを示すエラー状態ではなく、ユーザーはデータの不適切な状態についてのみ警告する必要があります。 データ検証の問題を表現するには、warning() または checkFailed() API を使用します。

    メモ

    システムが検証メッセージのクリーンアップを処理する方法により、warning() または checkFailed()API が使用される際、validate() の戻り値は常にfalse に設定する必要があります。 それ以外の場合は、警告メッセージがユーザーに表示されない可能性があります。

  • エラー - すでに発生した問題についてエラーがユーザーに警告します。 失敗したユーザー アクションは、エラー状態です。 エラーには、非中断 (パッシブ) または中断を使用できます。 中断のないエラーでは、ユーザーは問題の修正を試みる前に他のアクティビティを実行できます。 中断エラーでは、ユーザーはエラー状態を修正するまで続行したりタスクを完了したりできません。 パッシブ (非中断) エラーを表現するには、error() API を使用します。 中断エラーを表現するには、 box:: API を使用します。

このメッセージがユーザーに割り込むことを確認しますか?

(バッチ ジョブまたはその他の操作) のタスクが失敗した場合は、ユーザーに受動的に通知することが適切な場合があります。 ユーザーはいつでも問題を修正して操作を再試行できるので、すぐに通知する必要はありません。 そのような場合、error() API は適切であり、ユーザーは割り込みダイアログを受け取りません。 ただし、それ以外の場合、ユーザーは問題が修正されるまでは続行できません。 たとえば、まだ無効なデータを保持しているページをユーザーが保存しようとする場合、クライアントはエラー ダイアログを表すことにより、ユーザーを中断させます。 これらのケースでは、ダイアログを提示することにより、ユーザーを中断させる方が適切である場合、ボックス:: を使用する必要があります。

Box API の例。

私のメッセージは最終的にメッセージ バーまたはアクション センターに表示されますか。

メッセージング システムは、確定的 です。 つまり、ユーザーにメッセージを表示するための最善の方法を決定するために、メッセージング システムは呼び出しのコンテキストを使用します。 メッセージは、ページの上部に表示されるメッセージ バーまたはナビゲーション バーに表示されるメッセージ センターに表示されます。 メッセージの場所は、メッセージの送信元コードによって異なります。

一般:

  • メッセージが同期のページ アクション (つまり、ユーザーが結果を待つ必要がある) によって発生した場合、結果は現在のページのメッセージ バーに表示されます。 (例外は、アクションが開始された直後に終了したスライダー ダイアログです。スライダー ダイアログのメッセージが親のページに "バブル アップ" します。)
  • メッセージが同期 (切断) のアクション (たとえば、バッチジョブ) によって発生し、ユーザーが他のタスクを実行できる場合、またはそのアクションの処理中にも別のタスクにさえ移動できる場合は、メッセージはアクション センターにルーティングされます。

同期からのメッセージングまたは実行時間の長いバックグラウンド タスク

ページ上部にあるメッセージ バーは、何時間も前に開始されたバックグラウンド タスクではなく、現在のページに関する情報を表示するために使用されるため、(潜在的に) 長時間実行されているタスクはユーザーにメッセージ バーを表示しません。 場合によっては、多くのバックグラウンド タスクを実行しているユーザーは、タスクを完了しているときにページ間を移動し続けます。 したがって、現在のページに表示され、バックグラウンド タスクについてユーザーに通知されるメッセージは、見落とされたり無視されたりします。 したがって、設計上、バックグラウンド タスクはアクション センターにメッセージを送信します。 アクション センターに新しいメッセージが表示されると、非同期タスクの結果を待っている可能性のあるユーザーに通知が送信されます。

ダイアログおよびスライダー ダイアログからのメッセージング

確定的なメッセージング システムが、現在のページにメッセージを送信しようとします。 ただし、すべてのダイアログまたはスライダー ダイアログからの呼び出しが、そのダイアログまたはスライダーにルーティングされるわけではありません。 場合によっては、メッセージング システムが代わりに親ページにメッセージを送信します。 この現象は、ダイアログまたはスライダが閉じられているときにメッセージング システムが呼び出されると発生する可能性があります。 場合によっては、ダイアログまたはスライダーが閉じるプロセスを開始するときにメッセージング システムを呼び出せますが、クライアントが有効な理由から閉じるプロセスを中断します。 したがって、「不可逆地点」があり、その時点を過ぎると、メッセージング システムはもはやダイアログまたはスライダー にメッセージを送信しようとせず、メッセージを親ページに送信します。 ユーザーがフォーム上の OK ボタンクリックすると、下記のコード例に示すように、終了シーケンスに入ります。

closeOK()
{
    // current form
    super(); // calls close()
    // parent or message center
}
Close()
{
    // current form
    super();// point of no return
    // parent or message center
}

クライアントが closeOK() または close() を直接呼び出す場合、最終的な結果がページまたは親ページである可能性があります。

検証メッセージをクリーンアップする場合は?

財務と運用アプリにメッセージング システムを使用している場合は、検証メッセージ (同じ API を使用して呼び出される) がページ自体のメッセージ バーに受動的に表示されます。 無効な値は残っていますが、無効なフラグが立てられています。 ユーザーは引き続きデータを入力でき、データが保存される前の任意の時点で検証の問題を修正することができます。

検証の問題が修正されると、メッセージ バーの対応するメッセージは無効になり、メッセージング システムがメッセージを削除します。 メッセージ削除のタイミングは、検証ロジックが定義されているレベルによって異なります。

  • 検証ロジックがコントロールまたはフィールド レベルで定義されている場合、コントロールまたはフィールドに有効な値が入力されると、メッセージは削除されます。
  • 検証ロジックがテーブル レベルで定義されている場合、次回ユーザーが保存境界を超えるときにメッセージが削除されます。

UI からメッセージを削除する際に、開発者が詳細な制御を必要とする場合は、メッセージ () API を使用できます。 詳細については、メッセージング API 記事を参照してください。

私は古いバージョンからの移行をおこなっています。 新しいメッセージング システムを使用して既存のコードをどのように変更できますか。

多くの場合、変更は必要ありません。 メッセージング フレームワークは、多くの一般的なシナリオの下位互換性を革新し維持するように設計されています。 場合によっては、プログラムがメッセージの内容を改善させることがあります。 または、使用法のガイダンスに合わせるために警告() の代わりにエラー()、またはエラー() の代わりに警告() を使用するかもしれません (警告は無効なデータ、エラーは失敗したアクションのためのものです)。 それ以外の場合、スライダーのダイアログに表示されるメッセージが親ページに適していると判断できる場合があります。

SetPrefix() を使用して関連するメッセージのコレクションを作成するための詳細は、メッセージング API を Setprefix () ご覧ください。 この API は主に下位互換性がありますが、中断のない方法で表示されます。 結果ウィンドウを直接開くことはできません。代わりに、ユーザーは、結果メッセージをコレクションにグループ化するためにsetprefix () APIを使用したタスクを開始したアクション センターメッセージまたはページ上のメッセージバーによって、受動的に通知を受け取ります。 ユーザーに対して表示されるメッセージの重大度は、コレクション内の最も重要なメッセージの重大度レベルを反映しています。 たとえば、コレクションにエラーまたは警告が含まれていない場合、メッセージ バーは情報タイプです。

情報タイプ メッセージ バーの例。

コレクションに 1 つまたは複数の warning() への呼び出しが含まれている場合、メッセージ バーは、警告タイプです。

警告タイプ メッセージ バーの例。

コレクションに 1 つまたは複数の error() への呼び出しが含まれている場合、メッセージ バーは、エラー タイプです。

エラー タイプ メッセージ バーの例。

SetPrefix() の使用も確定的です。 つまり、SetPrefix() を使用して、ページ コンテキスト (たとえば、非同期バッチ操作) が存在しない場合、結果の通知はページに関連付けられていないアクション センターに送信されます。

大量の通知を生成するプロセスを管理するにはどうすればよいですか?

一部のプロセス (バッチ プロセスやユーザー作成のアラートなど) では、大量の通知が発生し、システムのパフォーマンスに悪影響を与える可能性があります。 システム通知管理の有効化 機能により、管理者は大量の通知ルールを監視し、アクションを実行できます。 これらのルールは、指定されたしきい値よりも 1 時間あたり多くの通知を生成するルールとして定義されます。

管理者は、以下を使用して大量の通知を管理できます。

  • システム パラメーター ページの システム通知 タブで、大量の通知ルールの基準を定義します。 既定の基準では、1 時間あたり 100 件を超える通知を生成する通知プロセスを、大量としてフラグ付けします。
  • 大量の通知の数を監視するには、システム管理 ワークスペースの 大量通知 タイルを使用します。
  • 大量通知ルール ページから通知を管理します。 ここから、管理者はどのユーザーがこれらの通知を受け取るかを確認し、大量の通知を生成しているプロセスをブロックして、これらのプロセスから通知が作成されないようにすることができます。 これらのプロセスはすでに多数の通知を生成している可能性があります。管理者は 通知のクリア アクションを使用して既存の通知を消去できます。

バージョン 10.0.39 では、大量であるしきい値を満たす通知プロセスは、大量の通知を自動でブロックするルール 機能を使用して、自動的にブロックされます。 この機能を有効にすると、ユーザーに関連付けられた通知プロセスがブロックされた場合にユーザーに通知されます。