確認インタープリタの開発
このトピックでは、既成の承認申請プロセッサクラスを拡張し、確認処理メソッドを機関固有の処理メソッドによってオーバーライドする方法について説明します。
ソリューション
• 既成の承認申請プロセッサを拡張するカスタムクラスを作成します。
• カスタムクラスを登録する xconf エントリを作成します。
ソリューションエレメント
次のテーブルで、ソリューションエレメントについて説明します。
|
エレメント
|
タイプ
|
説明
|
|
processAcknowledgement(String transmissionName, String transmissionContent)
|
API
|
承認申請の監督官庁から受信した確認を処理するときに使用します。
|
|
ApplicationData processAcknowledgement(String transmissionName, byte[] transmissionContent)
|
API
|
承認申請の監督官庁から受信した確認を処理するために代替として使用します。
|
デフォルトの動作
デフォルトの実装は、デモと説明のみを目的としています。各監督官庁が各承認申請タイプの確認の番号とフォーマットに関するドキュメントを提供することを前提としています。必要に応じて、インプリメンターは提供されているドキュメンテーションと一致する申請固有のプロセッサを作成できます。
確認 1 には、次の所定のフォーマットの JSON 文字列が含まれています。
{
"ackNumber": 1,
"typeName": "<typeName>"
"name": "<regulatorySubmissionName>",
"number": "<regulatorySubmissionNumber>",
"remoteIdentifier": "<remoteIdentifier>"
}
確認 2 には、次の所定の成功フォーマットの JSON 文字列が含まれています。
{
"ackNumber": 2,
"typeName": "<typeName>"
"remoteIdentifier": "<remoteIdentifier>"
"certificationNumber": "<certificateNumber>"
"expirationDate": "<exirationDate>"
"result": "SUCCESS"
}
確認 3 には、次の所定の失敗フォーマットの JSON 文字列が含まれています。
{
"ackNumber": 2,
"typeName": "<typeName>"
"remoteIdentifier": "<remoteIdentifier>"
"certificationNumber": "<certificateNumber>"
"expirationDate": "<exirationDate>"
"result": "FAILURE"
"errorCodes": [
{
"errorCode": "0",
"errorMessage": "A regulatory sumission error has occured."
},
{
"errorCode": "1",
"errorMessage": "One or more regularory submission attributes exceeds."
}
]
}
承認申請プロセッサインタフェースに基づいて、確認イベントは確認 2 を受信したときにのみ発送されます。これはジェネリック確認プロセッサのサンプルなので、
typename が含まれています。承認申請タイプ固有のプロセッサでは、承認申請プロセッサと登録先のタイプの間に 1 対 1 の関係があるので、
typename は既知です。承認申請プロセッサのインタフェースの詳細については、
承認申請プロセッサインタフェースを参照してください。
カスタムクラスの作成
確認処理をカスタマイズするには、SimpleRegulatorySubmissionProcessor または適切な改訂可能なサブタイププロセッサを拡張する Java クラス (独自のプロセッサ) を作成してから、processAcknowledegment メソッドをオーバーライドします。改訂可能なサブタイプポピュレータは、AERSubmissionProcessor、ERSubmissionProcessor、RPSSubmissionProcessor、および UDISubmissionProcessor のいずれかです。
次の例は、既成の要件を満たすように、processAcknowledgement メソッドがオーバーライドされた新しいカスタムクラスを示しています。ConditionalCheckoutRunner は、複数のサービス呼び出しが行われた場合に自動チェックアウトを許可しないようにすることで複数の作業版数を防止するために使用されています。
@Override
public ApplicationData processAcknowledgement(String transmissionName, byte[] transmissionContent)
throws Exception {
AcknowledgmentResult acknowledgmentResult = new AcknowledgmentResult();
new TransactionRunner<Boolean>() {
@Override
public Boolean performBusinessProcess() throws Exception {
JSONObject jsonContent = new JSONObject(new String(transmissionContent, StandardCharsets.UTF_8));
switch (jsonContent.getInt("ackNumber")) {
case 1:
String typeName = jsonContent.getString("typeName");
String number = jsonContent.getString("number");
RegulatorySubmission regulatorySubmission = RegulatorySubmissionHelper.service
.findRegulatorySubmissionByTypeAndAttribute(typeName, "number", number);
acknowledgmentResult.setTargetSubmission(regulatorySubmission);
new ConditionalAutoCheckoutRunner<RegulatorySubmission>(regulatorySubmission) {
@Override
public RegulatorySubmission performBusinessProcess(RegulatorySubmission coRegSub)
throws Exception {
ApplicationData appData = RegulatoryContentHelper.getService()
.storeRegulatoryContentReturnApplicationData(
coRegSub, RegulatoryContentCategory.ACKNOWLEDGEMENT1,
transmissionName,
new String(transmissionContent, StandardCharsets.UTF_8));
acknowledgmentResult.setCreatedData(appData);
return RegulatorySubmissionHelper.service.modifyRegulatorySubmission(coRegSub,
Map.of("remoteIdentifier", jsonContent.getString("remoteIdentifier")));
}
}.invoke();
break;
case 2:
String remoteIdentifier = jsonContent.getString("remoteIdentifier");
typeName = jsonContent.getString("typeName");
regulatorySubmission = RegulatorySubmissionHelper.service
.findRegulatorySubmissionByTypeAndAttribute(typeName, "remoteIdentifier", remoteIdentifier);
acknowledgmentResult.setTargetSubmission(regulatorySubmission);
regulatorySubmission = new ConditionalAutoCheckoutRunner<RegulatorySubmission>(
regulatorySubmission) {
@Override
public RegulatorySubmission performBusinessProcess(RegulatorySubmission coRegSub)
throws Exception {
ApplicationData appData = RegulatoryContentHelper.getService()
.storeRegulatoryContentReturnApplicationData(coRegSub,
RegulatoryContentCategory.ACKNOWLEDGEMENT2, transmissionName,
new String(transmissionContent, StandardCharsets.UTF_8));
acknowledgmentResult.setCreatedData(appData);
if (jsonContent.has("result") && "SUCCESS".equals(jsonContent.get("result"))) {
String expDateString = jsonContent.getString("expirationDate");
Timestamp expDate = Timestamp.valueOf(expDateString);
coRegSub = RegulatorySubmissionHelper.service.modifyRegulatorySubmission(coRegSub,
Map.of("certificateNumber", jsonContent.getString("certificateNumber"),
"expirationDate", expDate));
acknowledgmentResult.setAcknowledgmentSuccessful(true);
}
else {
if (jsonContent.has("errorCodes")) {
JSONArray failureCodes = jsonContent.getJSONArray("errorCodes");
ArrayList<AcknowledgementMessageBean> ackMessages = new ArrayList<>();
for (int i = 0; i < failureCodes.length(); i++) {
JSONObject failCode = failureCodes.getJSONObject(i);
String code = failCode.get("errorCode").toString();
String message = failCode.get("errorMessage").toString();
ackMessages.add(new AcknowledgementMessageBean(message, code));
}
RegulatorySubmissionHelper.service.saveAcknowledgementMessage(coRegSub,
ackMessages);
}
acknowledgmentResult.setAcknowledgmentFailed(true);
}
return coRegSub;
}
}.invoke();
// must dispatch events against the checked-in regulatory submission because the checked out version
// is on it's own branch
if (acknowledgmentResult.isAcknowledgmentSuccessful()) {
RegulatorySubmissionProcessorHelper.dispatchAcknowledgmentSuccessfulEvent(regulatorySubmission);
}
else {
RegulatorySubmissionProcessorHelper.dispatchAcknowledgmentFailedEvent(regulatorySubmission);
}
break;
default:
break;
}
return true;
}
}.invoke();
return acknowledgmentResult.getCreatedData();
}
関連トピック