AgileWorksからSAPへデータを連携する処理で、SAP側のコード体系に合わせるため、既存コードを9桁コードへ変換する読替処理を追加しました。テストでは代表的なコードを使って正常に変換できていましたが、本番切替後の夜間連携でエラーが発生しました。調べてみると、プログラムそのものではなく、読替マスタへの登録漏れが原因でした。未登録だったコードは2件です。今回は、この2件を軸に、代表データだけのテストでは見つけられなかった理由と、本番前に洗い出す方法を整理します。
AgileWorksのコードは変えず、SAPへ送るときだけ9桁へ変換した
今回の連携では、AgileWorks側で利用している既存コードと、SAP側で必要となるコード体系が異なっていました。SAP側では9桁コードを使う必要がありましたが、既存システム側のコードをすべて変更すると影響範囲が広がります。
既存データだけでなく、画面、帳票、過去データ、別の連携処理などが従来コードを前提としている可能性があります。そのため、AgileWorks側のコード体系は維持したまま、SAPへ連携する段階でだけ9桁コードへ変換する方式にしました。
そこで用意したのが読替マスタです。既存コードをキーにして対応するSAP側の9桁コードを取得し、その値を連携データへ設定します。
この方式は既存システムへの影響を抑えられる一方、「連携で利用するすべてのコードに読替先が存在すること」が新たな前提になります。今回のエラーは、その前提を満たしていないコードが本番データに含まれていたことで発生しました。
テストで確認したコードは正常だった
本番切替前には、読替処理が意図どおり動くかをテストしていました。既存コードを渡すと、読替マスタから対応する9桁コードを取得し、SAP向けデータへ設定できることを確認しています。
そのため、変換プログラム自体は動作していると判断しました。しかし、本番データに存在するすべてのコードを使ってテストしたわけではありませんでした。
ここで、「処理が正しく動くこと」と「すべての本番データを処理できること」は別の確認だと分かります。代表コードを数件使えば、読替ロジックが正しいことは確認できます。しかし、本番で利用されているコードの中に一つでもマスタ未登録のものがあれば、そのデータでは変換できません。
今回まさに、この差が本番の夜間連携で表面化しました。
夜間ジョブのログから9桁コードのエラーを確認した
本番切替後、夜間の連携ジョブでエラーが発生しました。ログを確認すると、9桁コードのチェック部分で問題になっていたため、エラー対象データから変換前の元コードを確認しました。
正常に処理できているデータも存在したため、9桁への変換機能全体が動いていないわけではありません。特定のコードだけで問題が発生している可能性が高いと考え、読替マスタとの対応を確認しました。
夜間バッチでは、この発見経路自体が重要な運用情報です。障害が午前1時に発生して午前9時まで誰も気付かないのであれば、原因を直しても同じ時間だけ滞留します。エラーの内容だけでなく、誰が何を見て気付いたのかまで含めて、監視の設計を考える必要があります。
読替マスタを調べると2件のコードが登録されていなかった
エラーになった元コードを読替マスタで検索すると、対応する9桁コードが存在していませんでした。登録が漏れていたコードは2件です。
処理の考え方は単純です。AgileWorks側の元コードを取得し、読替マスタを検索し、SAP側の9桁コードを取得します。読替先が存在しなければ、SAPへ渡す正しい9桁コードを生成できません。
つまり、プログラムそのものを修正する必要はありませんでした。必要だったのは、欠けていた2件の読替情報をマスタへ追加することです。
たった2件でも、夜間連携は正常に完了しません。マスタデータはソースコードほど目立ちませんが、システム間連携ではプログラムの一部と同じくらい重要だと感じた事象でした。
マスタへ2件追加した後、再実行方法を確認した
未登録だったコードについて、SAP側で利用する正しい9桁コードを確認し、読替マスタへ追加しました。その後、対象コードを使った場合に9桁コードを正常に取得できることを確認しました。
ただし、ここで注意が必要なのが夜間ジョブの再実行です。マスタを直したからといって、何も確認せずジョブを最初から再実行すると、すでにSAPへ送信済みの正常データを二重に送る可能性があります。
そのため、エラーになったデータの処理状態や、どの範囲から再実行できるかを確認する必要があります。連携済みフラグやジョブの再開位置など、具体的な仕組みは環境ごとに異なります。
今回も、マスタへの登録だけで障害対応を終わらせるのではなく、再実行して正常に完了するところまで確認しました。障害対応では「原因を取り除く作業」と「滞留したデータを安全に処理する作業」は分けて考えた方が安全です。
本番前にLEFT JOINで未登録コードだけを洗い出せる
今回のような登録漏れを本番前に見つける方法として有効なのが、元データと読替マスタを突き合わせる方法です。
元データに存在するコードを基準にして読替マスタをLEFT JOINし、マスタ側が見つからなかったものだけを取得します。実際のテーブル名や項目名は環境固有ですが、考え方は次のようになります。
SELECT DISTINCT s.SourceCode
FROM SourceData s
LEFT JOIN MappingMaster m
ON s.SourceCode = m.SourceCode
WHERE m.SourceCode IS NULL;この結果に2件表示されていれば、今回の未登録コードを連携実行前に発見できた可能性があります。代表データを選んでテストする方法と違い、実際の元データを基準にしているため、利用頻度の低いコードも確認できます。
また、単に未登録値を表示するだけでなく、そのコードが何件のデータで使われているかを集計すれば、影響度の判断にも利用できます。
切替時だけでなく、運用中も未登録コードは発生する
読替マスタは本番切替時に整っていても、その後に新しいコードが追加されれば、再び未登録の状態が生まれます。そのため、コードを追加する運用側のルールとして「元システムへ追加したら読替マスタも更新する」を決めておく必要があります。
さらに、上のSQLを定期的に実行する仕組みにしておけば、夜間ジョブで初めて気付くという事態を避けられます。マスタは一度作れば終わりではなく、コード体系をつなぐインターフェースの一部として管理し続けるものだと考えています。
コード変換ではプログラムより先に「全件変換できるか」を確認する
今回の本番エラーから得た一番大きな教訓は、コード変換機能をテストするとき、プログラムが正しく動くかだけでは十分ではないという点です。
読替マスタを使う以上、本番データに存在するコードがすべてマスタに登録されていなければなりません。代表コードを使った正常系テストとは別に、元データとマスタを全件突合する確認が必要です。
また、夜間ジョブの障害では、発生時刻だけでなく発見経路まで含めて監視を見直すと、次に同じことが起きたときの滞留時間を短くできます。
今回の原因は読替マスタの2件の登録漏れでした。小さな設定漏れですが、それだけでシステム間連携は止まります。コード体系を変更するときは、「変換できること」ではなく「現在存在するすべてのデータを変換できること」を確認する必要があります。
コメント