【本レビューの指摘対応分】
前回指摘の内容を修正しましたので、本日引き続き指摘対応分のレビューをお願いします。
先ずは記録表58番の指摘対応について、確認をお願いします。
指摘自体の内容はPL層のManageBean、APIクラスとBL層の業務処理をそれぞれにCheckStatusフォルダに移動する指摘ですけど、
で、電文を疎通確認する時、不具合らしい事象が発生したため、ManageBeanクラスをフォルダに移動しても、その事象が解決出来なかったです。
電文の起動順は0001V2起動⇒00005クイックログイン認証⇒0008⇒00016だと、問題ないですが、
申し0001V2起動⇒0002⇒0003⇒0005クイックログイン認証⇒0008⇒00016実行順の場合、電文起動エラーが発生してしまった。
①先ずは、SappReqDispatchのManageBeanから見ます。
元々新規作成のManageBeanクラスを削除して、クラス中の内容をまるまるSmartPhoneAppQuickLoginRegistrationManagedBeanに移動します。
ManageBean変更に伴い、MethodBindingMapのXMLファイルにて、今回新規四つ電文のManageBeanの名を既存クルス名を変更します。
更に、actionをstartからeventに変更し、Action IDも合わせて修正します。
faces-config-securityのXMLファイルにて、元のManageBean定義の内容をまるまる消します。
電文処理正常する時、フォワード定義のところ、MethodBindingMapのAction IDと同じ名を利用します。
②次、Security側の本処理ManageBean修正です。
同じように、元々新規作成のManageBeanクラスを削除し、クラス中の内容を既存ManageBeanに移動します。
ConstantクラスとOUTServiceBeanクラスをインポートします。
共通情報を格納するBeanの定義を追加します。
FormBeanを初期化するメソッドで共通情報Beanを生成します。
一番後ろに、元内容をそのままに移動します。
MethodBindingMapMainServiceのXMLファイルにて、先SappReqDispatch直下のXMLファイルと同じ修正です。
faces-config-securityのXMLファイルも同じ修正です。
③次、Security APIクラスの修正です。
指摘内容に従って、元々API中で実装する内容をCheckStatusAPIクラスに移動します。
元々追加する新規電文に関する内容を全部消して、内容をCheckStatusAPIクラスに追加します。
フォルダ変更に伴って、利用されている定数クラスも変更しないといけません。
元々LoginAuthenticationConstantにて、追加する内容を消して、CheckStatusConstantクラスに移動します。
④次、BL層、実際の業務処理クラスの対応です。
電文処理「他行付番要否チェック」と「他行付番の申請状態更新」BLクラスをCheckStatusのNumbering直下に移動します。
次、レビュー表58番の修正内容を確認お願いします。
OUTServiceBeanを二つに分けられました。NumberingInitSettingStatusCheckクラスにて、OUTServiceBeanを利用されている箇所、
を分けたOutServiceBeanに変更します。
次、60番と61番例外処理に関する対応です。
ワーニングログをエラーログに変更し、元例外内容をエラーログに出力します。
最後、62番の指摘対応です。
accountTypeIdメンバー変数をローカル変数に変更します。メンバー変数をけして、メソッド中でローカル変数の定義を追加します。
他行付番申請受付完了
今回の新規画面「他行付番申請受付完了」のPCLレビューをお願いします。
画面種類によって、SFESとWEBView、二種類に分けれれますので、PCLファイルを２本作りました。更に、各ファイルにて、それぞれに三つ支店がありますので、ファイル中で支店毎、シートを用意しておきます。
先ずはSFESファイルのプローパ支店シートから説明させていただきます。
ケース1番の観点は、画面初期表示時、レイアウトの確認観点です。
確認内容について、いただいたモック通り、画面ヘッダー部、見出しタイトルの文言、IframeのURL、myAccountボタンと画面フッター部が正しい表示されること。
ケース2番、画面上唯一ボタンのアクションが正しいかないかので観点です。
ボタンをクリックした後、「myAccount」画面へ遷移されることを確認です。
ケース3番、RAT確認で画面のページネームが送信されるか、ないかの確認観点です。
前用の専用のJavaScriptを用意して送信されたページネームが「SPnumberingApplyAccomplished」であることを確認します。
次、DL支店シート、JRE支店シート中で各ケースの観点と確認内容はほぼ同じです。差異は1点だけです。IframeのURLについて、各支店毎、専用のURLが用意されます。
次webViewファイルの確認をお願いします。
同じく支店毎、シートが分けられます。
ケース観点はSFESと同じです。
差異は、レイアウト確認でwebViewの場合、ヘッダーとフッターの確認が不要のこと。ボタン名が「ホームに戻る」であること。ボタンをクリックした後、遷移先が「XXXXXX」であること。後は、IframeのURLがwebView場合各支店専用のURLが利用されいること。