はじめまして！SCI本部の諏訪と申します。
エンジニアブログ初登場させていただきます。
今回は、先日業務で携わった、API連携を使用した他社システムとの情報の同期について、
どのような工夫をしたのかや苦労した点などについて徒然と書いていこうと思います。
最後までお読みいただければ幸いです。☺
はじめに
普段私はSSO認証を実装している顧客情報管理システムの開発に関わっています。
このシステムでは、ユーザーを所属する組織と共に管理しているのですが、例えば組織の紐づけを変更するようなとき、
SSO認証元のシステム（以下「認証元」）と、認証先のシステム（以下「認証先」）それぞれでユーザーの情報を管理しているため、
どちらの情報も変更してあげる必要があります。
しかしこれでは、例えば全てのユーザーの情報を一斉に更新する必要があるようなとき、
管理者は認証元と認証先それぞれで全ユーザー分の情報を編集しなければならず、
ただでさえ大変な更新作業が2度手間になってしまいとても効率が悪いです。
また、年度が変わることに伴う組織異動などの際は、異動元の組織と異動先の組織のどちらからも処理しないといけず、
お互いのやり取りなども発生する可能性もあり、やはり手間がかかってしまいます。
そこで、認証元からユーザーの情報をAPIを使用して連携し、認証先に反映させることになりました。
この連携は日次で深夜に実行するので、毎日認証元の変更が認証先に反映されている状態になるのが目標です。
連携にあたっての大前提として、認証元と認証先ではユーザーの情報の管理の考え方に違いがあるため、
認証元のユーザーの情報をうまく認証先の仕様に対応できるように照らし合わせて、時にはこちら側で編集していく必要があります。
ここでひとつ問題が出てきました。
認証元のシステムが複数あり、それぞれに少しずつ仕様の違いがあったことです。
認証先ではそれらの差分をすべて吸収して、どの認証元の情報についても適切に情報を反映させる必要がありました。
今回はこの差異吸収・標準化のために行った手段についてご紹介してみようと思います。
この手段というのは大きく分けて3つあります。
- 各項目を照合して認証先の値に変換するテーブルを作成しました
- 認証元のデータそのものを持つテーブルを作成しました
- 処理を「連携」「反映」に分けて、データの取得と差分の吸収・反映という2つの役割に特化するようにしました
これらの手段を活用することによって、短期間での開発にしてはある程度まとまった仕組みが作成できたのではと思っています。
加えて、この先また違う仕様のものと連携することになっても、ある程度対応できるような仕組みになるように工夫しました。
それでは、この3つの手段について少し詳しくご説明します。
1. 各項目を照合してこちら側の値に変換するテーブル
認証元と認証先の情報を1レコードで扱うテーブルを作成しました。
このテーブルには、それぞれのアプリで、その項目が一意になるためのレコードを入れます。
認証元の仕様として、一意キーがない項目も度々ありましたが、その場合は、その項目を一意に特定するために必要な情報（項目）を半角スペースで連結して対応しました。
また、このDBには「変換用項目」という項目も作成しました。
これは、例えば「組織コード」「組織内部署コード」などといった、「何についてのレコードなのか」を判別するための項目です。
これにより、新しい項目について変換できるようにしないといけなくなった時にも対応できるようになっています。
2. 認証元のデータそのものを持つテーブル
連携される情報が「その日に所属しているユーザーすべての情報」のみで、
各ユーザーについて変更があったのかが連携された情報のみでは分からないケースについて考慮する必要がありました。
連携された情報について変更があるか・何が変更されたのかを判断するためには、連携された情報と、認証先で対応する情報を比較する必要があります。
しかし、取得したレコードすべてを認証先のデータの方式に合わせてから、認証先のDBの情報と比較する…というのは、
時間もかかりますし、変更のないデータについても一度変換する、という無駄な処理が発生してしまうため、できれば避けたいです。
これを解決するためとった方法は、「取得したレコードを全てそのまま入れておくテーブルを作成して、それと比較して変更があるかを判断する」というものです。
比較を行い、差分があるかの判断を先にしてから認証先のデータ形式に変換することで、
「変更のないデータについても一度変換する」処理が不要になります。
先に処理対象のデータを選別するので、変更のないデータについて行う必要のない処理を行う必要が無くなります。
ただこのテーブルの運用については少し注意が必要です。
まず、初回の連携時に、そのまま入れておくテーブルをどのように作成するかについては考慮する必要があります。
また、完全な同期を実現するためには認証先側の変更もこのテーブルに反映してあげないといけません。
今回のシステムでは、連携されたデータが正であるとして処理を構築していますが、このあたりの仕組みについては
もう少し考慮できたかなと個人的には反省点です。
さらに、今後似たような連携元ができた場合は、都度それ用のテーブルを作成する必要もあります。
3. 処理を「連携」「反映」に分ける
差分の吸収・反映専門の処理に切り分けたので、今後追加になった時に考える必要があるのは連携の部分のみです。
反映の方である程度ルールが決まっているので、連携の方では最低限それに合わせて整形しておけば後の部分については既存のシステムを使用できます。
結論
他にも細かく工夫した点はありますが、大きなもの3点をご紹介しました。
異なる仕様をうまく吸収してこちらに登録できるようにするのは大変でしたが、どうにか仕組みとしてまとめることができたのではと思います。
仕組みづくりのために苦労したことはたくさんあります。例えば…
- 「反映処理」のために形式を揃えること。ひとつの連携元の仕様に対応するともう片方がうまくいかないというのはしょっちゅうで、
どんなに細かい決定でもその理由が分かるようにしておかないとのちのち不整合が起きてしまいます。 - 年度の考慮。各認証元・認証先側とも年度の考え方が違ったので、本来異動や削除をしないユーザーの情報を処理してしまったり、間違った部署に所属させることがない仕組み作りはとても苦労しました。
今後また違う仕様のものと連携することになっても、ある程度はこの方法で対応できるようになっていると思います。
今決まっている認証元以外にもこの先また認証元が増えていくことがないとは言い切れないため、
今後のことについて考えた仕組み作りも目標のひとつとして掲げていたので、柔軟性がある仕組みにできたことはよかったです。
（とは書いていますが、今の状態は最低限の仕組みなので、よりスマートな仕組みが作れたのではという気持ちはすごくあります…
もしよい方法ありましたらそっと教えてもらえると嬉しいです）
この記事を読んだあなたの何かにお役に立てればうれしいです！