通信コンテンツクリーンアッププロセッサの開発
このトピックでは、既成の承認申請プロセッサクラスを拡張し、通信コンテンツクリーンアップメソッドを機関固有の処理メソッドによってオーバーライドする方法について説明します。
ソリューション
• 既成の承認申請プロセッサを拡張するカスタムクラスを作成します。
• カスタムクラスを登録する xconf エントリを作成します。
ソリューションエレメント
次のテーブルで、各種ソリューションエレメントについて説明します。
|
エレメント
|
タイプ
|
説明
|
|
cleanTransmissionContent(RegulatorySubmission regulatorySubmission)
|
API
|
申請の準備中に承認申請オブジェクトの適切なコンテンツをクリーンアップします。
|
|
getRegulatoryContentCategoriesToClean(RegulatorySubmission regulatorySubmission)
|
API
|
除去する必要がある規制コンテンツカテゴリのリストを提供します。
|
デフォルトの動作
申請または再申請の準備中に、このプロセスで再び取り込む必要がある既存の確認メッセージと規制コンテンツが削除されます。getRegulatoryContentCategoriesToClean メソッドは、除去する必要がある規制コンテンツカテゴリを提供します。規制コンテンツのカテゴリには、承認申請のメッセージボディ、確認 1、確認 2、および確認 3 などがあります。承認申請に現在存在しない規制コンテンツカテゴリは、その申請では除去されているものと見なされます。
デフォルトの実装は、主にデモと説明を目的としています。ただし、これは多くの承認申請タイプに適した一般的なベストプラクティスです。要件に応じて、インプリメンターは提供されているドキュメンテーションと一致する申請固有のプロセッサを作成できます。
カスタムクラスの作成
クリーンアップ処理をカスタマイズするには、SimpleRegulatorySubmissionProcessor または適切な改訂可能なサブタイププロセッサを拡張する Java クラス (独自のプロセッサ) を作成してから、cleanTransmissionContent メソッドをオーバーライドします。改訂可能なサブタイププロセッサには、AERSubmissionProcessor、ERSubmissionProcessor、RPSSubmissionProcessor、UDISubmissionProcessor などがあります。
オーバーライドされた cleanTransmissionContent メソッドの例を以下に示します。
@Override
public RegulatorySubmission cleanTransmissionContent(RegulatorySubmission regulatorySubmission) throws Exception {
RegulatoryContentCategory[] regulatoryContentToDeleteBeforeTransmit = getRegulatoryContentCategoriesToClean(
regulatorySubmission);
for (RegulatoryContentCategory regulatoryContentCategory : regulatoryContentToDeleteBeforeTransmit) {
try {
regulatorySubmission = RegulatoryContentHelper.getService()
.deleteRegulatoryContent(regulatorySubmission, regulatoryContentCategory);
} catch (WTException e) {
if (!e.getExceptionIdentifier().contains(regmstrResource.NO_CONTENT_FOR_CATEGORY)) {
throw e;
}
}
}
regulatorySubmission = RegulatorySubmissionHelper.service
.deleteAcknowledgementMessages(regulatorySubmission);
return regulatorySubmission;
}