W-MSAによって挙動がかわる機能

最終更新日: 2020年7月5日
R8 | R9

ログオン

W-MSA利用時のログオン処理は次のようになります。

  • 各ドメインアプリケーションのログオン画面へのURLはそれぞれ異なります。カスタムドメイン名で区別しています。
  • どのドメインアプリケーションにログオンしても、アカウントのセッション情報は AWS ElastiCache (Redis) で管理されます。
  • ドメインアプリケーションでも、マルチセッションを利用することができます。
  • 一度ログオンが成功したアカウントは、ログオフするまで、別のドメインアプリケーションを利用することができます。すなわち、複数のドメインアプリケーションを渡り歩いた操作を行うことができます。(*1)
1. ただし別のドメインアプリケーションのメニュー画面を経由する必要があります。詳細は「メニュー」で説明します。

メニュー

  • ログオン後のメニュー画面もドメインアプリケーションごとに異なります。当該アプリケーションで管理できるモデルのみがメニューに表示されます。
  • システム管理者（または共通モデル、システムモデルを操作する権限をもったアカウント）は、どのドメインアプリケーションにログオンしても共通モデルおよびシステムモデルのメニューが表示されます。
  • 利用者は複数のドメインアプリケーションを渡り歩くことができます。このとき、必ず各ドメインアプリケーションのメニュー画面を経由してください。例えば app1 で、あるモデルに関する業務処理を行ったあと、app2 のメニュー画面を経由して app2 のモデルを操作することができます。この目的のため、各ドメインアプリケーションのメニューに、他のドメインアプリケーションのメニュー画面へ遷移するための外部リンクを用意することができます。[後述] しかし app1 から（ブックマークなどで）直接、app2 のモデルを操作する画面に遷移することはできません。(*2)
2. メニュー画面を経由せずに直接、ドメインをまたいでモデルの操作（検索、登録など）を行おうとするとエラーとなり、メニュー画面に戻されます。

外部リンクを使って別のドメインアプリケーションのメニューへ遷移する

メニュー設計で、外部リンクをメニューに含めることができます。[詳細...]

ここで、別のドメインアプリケーションのメニュー画面に遷移するための外部リンクメニューを用意することで、ドメインアプリケーションを渡り歩くことができるようにします。

外部リンクの URL に次のプレースホルダを含めることができます。 

${domainId.url}

記述方法は "ドメインID.url" となります。

例えばドメインアプリケーション app1 のメニューで、app2 ドメインのメニューへ遷移するための外部リンクは、次のようになります。 

${app2.url}/mainMenu.do

この ${app2.url} 部分は、実際には "メニュー > 管理処理 > モデル定義... > ドメイン情報検索" で表示される URL 値に置き換わります。

運用に関する注意

ドメインの URL を更新することができます。このとき、ログオン中のユーザーはいったんログオフし、再ログオンすることで上記の domainId.url 部分が反映されます。つまりドメインURL情報を更新した場合、これをメニューに反映させるために、利用者は再ログオンを行ってください。

ポータル（ポートレット）

ポータルを利用した場合、すべてのドメインアプリケーションで同じポータル設定が用いられます。

あるドメインアプリケーションだけポートレットの表示位置、表示サイズ、内部パラメータを変更する、ということはできません。

ポートレットに含まれるURL

ドメインアプリケーションに表示するポートレットは、その運用サーバの URL (<scheme>://<hostname>:<port>) が異なります。

W-MSAを運用する前に、ドメイン情報 (jfcdomain モデル) の URL 項目を更新しています。この対応により、ポートレットは正しく表示されます。(*3)

3. ポートレット表示時に URL 情報を参照し、設定されていた場合は rest/<モデルID> にドメインのURLを付加するようになっています。

CORSについての補足

ポートレットはすべてのドメインアプリケーションで共通利用されます。 そのため、あるポートレットが（自分のアプリケーションではなく）別サーバで稼働しているドメインアプリケーションのモデルのデータを取得する場合が考えられます。このとき、CORS の設定が必要になります。[詳細...]

CORS の対応を行った場合、ブラウザによってはセキュリティ対策のためセキュアな http 通信 (https) でない場合は他サーバへクッキーを送出しないものがあります。（近年のモダンブラウザはセキュリティ重視のため、そのような動作になっています。）

ドメインをまたぐアプリケーションのデータをポータルで表示しようとしてエラーになる場合、それぞれのサーバがセキュアな http 通信を行うようになっているかどうかを確認してください。

ジョブ

W-MSA環境では、ジョブは次の性質で区分されます。

区分説明例
1インスタンス 指定時刻になったとき、いずれか一つのインスタンスだけでジョブが実行される。（どのインスタンスかを指定することはできない。）複数のインスタンスで実行する必要がない場合向け。 前者はエクスポート処理やプログラムによるデータ操作処理。
ドメイン内の1インスタンス 指定時刻になったとき、ドメイン限定で一つだけ動作する。オートスケールしている場合、そのうちの一つのサーバで動作する。 プログラムによるデータ操作処理。（販売管理の月次の締め処理など）
全インスタンス 指定時刻になったとき、起動されているすべてのインスタンスでジョブが実行される。 チェックディスク、メンテナンスモード切り替えなど

エクスポート

W-MSA運用時は、データのバックアップとしてWagbyが提供するエクスポート機能ではなく、パブリッククラウドが提供するデータベースのバックアップサービスを使うことを原則とします。エクスポートしたデータは、ドメインを横断したデータのバックアップになっていません。ドメイン単位のデータしか含まれていません。また、システムモデルなどは重複して保持するため、インポートも難しい。 エクスポート機能自体は利用できますが、テスト環境で用いることはあっても、本番環境で用いることは想定しないようにして運用マニュアルをご用意ください。

バックアップフォルダ名の命名規則は次のようになります。ドメインIDが付与されるため、これで区別してください。 

data_<ドメインID>_YYYYMDDHHmmss.zip

Redisの挙動

ドメインアプリケーションの起動時に Redis (ElastiCache) はフラッシュされません。

キャッシュの扱い

キャッシュのクリア同期処理は自動的に行われます。(MQを利用します。)