APIとプログラム開発の勘所--外部のクラウドサービスの仕様変更に注意 - (page 2)

問題発生時の復旧方針をあらかじめ組み込む

　前述の人事システムからの連携では、4つのステップでシステムを連携する例を紹介しました。このような連携では、何らかの問題が途中生じた時にどのように回復すべきかの方針を組み込んでおくと良いでしょう。

　たとえば、ステップ2を処理中のeラーニングシステムで問題が生じ、ステップ4のDropboxアカウントが払い出されない状況があるとします。こういった場合、利用者からの「Dropboxアカウントが払い出されていない」という苦情として検出することが大半ですが、問題原因切り分けのためにステップ1の人事システムの情報確認から、ステップ2のeラーニングシステム、ステップ3の電子署名システムといった具合に、関連する全てのシステムの状態を確認しなければなりません。それぞれかなり手間のかかる操作で、場合によっては各サービスのサポートへ問い合わせ回答を待つ必要があり、解消に時間がかかることがしばしばあります。

　一方、利用現場では、すぐに利用開始しなければ業務が停止するといったプレッシャーが利用部門とシステム管理部門の双方にかかります。たとえば下記のように、すぐに対応が取れるような回復方針の準備があれば、組織へのプレッシャーを最小限にできます。

• （1）一次対応として、たとえばeラーニングで実施予定だった教育を動画資料として利用者に配布
• （2）eラーニング受講証明の代わりにメールなどで受講の旨を確認
• （3）Dropboxアカウントを払い出し
• （4）後日のシステム復旧後、再度正式にeラーニングシステムで証明を取得

　また、すべてを再実行するようにシステム復旧方法を設計すれば、さらに回復の複雑性を低減できます。具体的には、プログラムが何度実行されても同じ結果になる、冪等性（べきとうせい）を持つような設計とすると良いでしょう。

　Dropboxアカウント作成の処理を例に考えてみましょう。Dropboxアカウントを作成するAPIでは、ユーザーIDとなるメールアドレスを指定してアカウントを作成します。該当ユーザーアカウントが無ければ成功して終了しますが、すでに該当するユーザーが存在する場合にはエラーを報告します。ユーザーアカウントが存在していれば業務上の問題はないため、アカウントが存在する場合はこのエラーを無視するようにします。このような設計であれば、何度再実行してもプログラムは問題なく終了するので安心して再実行できます。

　同様に、今回の例ではステップ3で電子署名システムと連携、署名依頼を送付しますが、再実行のたびに新しい署名依頼を送信するような設定は避けるべきでしょう。ユーザーが混乱するだけでなく、ユーザーの署名後に未署名の依頼が複数残るなどでシステム上の扱いも複雑になります。このような状況にならないよう、連携元となるeラーニング終了に対しての署名依頼がすでにあるかを確認し、ない場合に新しく署名依頼を実行するようなプログラムの開発がお勧めです。

　このように、各システムをAPIで連携する際にどのような回復方針にするか統一しておくことで、システム連携をより強固に実施できます。

　プログラム開発には他にもさまざまな考慮すべき点があり、一度ですべての勘所を網羅するのは難しいですが、今回紹介したようなAPI仕様変更といった外部要因がある点とその対策、問題発生時の対応方針などは、広く応用できる指針といえるでしょう。

　次回は、サービス利用のユーザー視点からAPIの魅力について紹介します。