前回の記事で、Payment Automation 2 は、HTTPベースのAPIを主体としたソリューションです。
とご紹介しました。
今回は、このHTTPベースのAPIを主体としているということはどういうことなのか、どんな風に利用するのか、ということをご説明したいと思います。
一般的なサービスの利用の仕方
一昔前は、情報システムは企業内にあることが普通でした。パソコンや機器には、特定の業務を行うためのアプリケーションがインストールされ、そのアプリケーションを操作して業務を行っていました。
時代が経過しインターネットが隆盛を極めると、情報システムはインターネットの雲の中に移動していき、Webサービスやクラウドサービスなどといったかたちで提供されることが多くなりました。
Webベースのサービス
このようなWebサービスやクラウドサービス、ソリューションの場合、通常はWebシステムにブラウザでログインして使用します。
ログインすると、様々な画面があり、その画面を操作して行いたいことを実行します。
一例として、Googleサーチコンソールを利用する場合は、まずGoogleにログインして、それからサーチコンソールの画面を開きます。
サーチコンソールの画面にアクセスすると、左側にメニューがあり、そこから各種機能を持った画面へ遷移することができます。
遷移先の画面では、何らかの情報を見て確認することができたり、何らかの情報を設定したり登録したりすることができます。
例えば、左サイドバーのメニュー「検索パフォーパンス」をクリックすると、検索パフォーマンスの画面に遷移し、どんな検索キーワードで検索結果に表示されて、どんな検索キーワードがクリックされたのかといった情報を確認することができます。
他のサービスでも同様です。Salesforce を見てみましょう。
Salesforce を利用する場合も、まずは Salesforce にログインします。するとメインの画面が表示されます。
メインの画面には各機能へアクセスするためのタブが表示されており、「商談」「リード」などの機能へ移動することができます。
このように、通常はサービスを利用する際には、ブラウザを通して機能にアクセスします。
システム連携
乱立するシステム
業務に利用されるシステムは1つとは限りません。むしろ複数ある方が一般的かと思います。
それらのシステムが全く別々の情報を取り扱うケースもあれば、関連する情報を取り扱うケースもあります。
例えば顧客に関する情報などは、システム間で関連しやすい情報といえます。
同じ顧客に対する、営業、商談、見積、受注、納品、請求、入金 といった流れの中で、それぞれを担当する部署は分かれます。
部署が異なるということは、システムに求められる機能が異なるため、したがって部署ごとに異なるサービス、システムを利用するのは普通です。
しかし同じ顧客についての情報を取り扱っているわけですから、各システム間でその情報を連携できれば便利です。
世の中には、業務の流れのすべてあるいは大部分をカバー可能であるとうたうサービスやシステムもありますが、たいていの場合は高価であったり、機能過多であったり、あるいは昔から使用しているシステムがあって、それと置き換えられないなどといった事情により、そのような大仰なシステムの導入には二の足を踏む企業が多いのではないかと思います。
そうなると、導入されている各システムを連携させなければなりません。
システム連携の方法
人間がサービスやシステムを使うときには、前述の通りブラウザでサービスやシステムとやり取りをします。それではシステムがシステムとやり取りを行うときにはどうするのでしょうか？
システムがシステムとやり取りを行うとき、単純なデータのみの連携であれば、ファイルを経由する方法があります。
よくあるのは、CSVファイルをエクスポートして、他方のシステムにそのCSVファイルをインポートするというものです。
この方法には、以下のような特徴があります。
- シンプルでわかりやすい
- 多くの場合、どこかに人の手が入るため自動化はしにくい
- システム間でCSVファイルの形式にミスマッチがあり、整形が必要となる
- 他システムの機能をコールするといった複雑な連携はできない
また他の方法として、API を介して行うという方法があります。
APIとは、プログラム(ここでは≒ソフトウェア≒アプリケーション)からプログラムにアクセスするためのインタフェースというのが、従来の認識かと思います。
ブラウザやスプレッドシートなどのアプリケーションは、普通はマウスとキーボード、あるいはスマホであればタップで人が操作します。
これらのアプリケーションは、人ではなく他のプログラムからアプリケーションにアクセス/操作できるように、機能の口(インタフェース)を提供している場合があります。これがAPIです。
システムとシステムが連携するときにAPIを用いると、複雑できめ細かな連携が可能となります。※1
なお、かつてAPIといえば、プログラミング言語の関数として提供されることがほとんどでした。
しかし、アプリケーションやシステムがクラウド化した現在、その機能はインターネットを通じて提供されています。それに伴い、クラウドサービス、システムのAPIはHTTP通信により提供されることが主流となっています。
Payment Automation 2 の利用イメージ
Payment Automation 2 のアプローチ
Payment Automation 2 は、当初から何らかのシステムと連携することを前提に開発されました。
そのため、一般的なクラウドサービスのようにブラウザでアクセスする画面が主体がではなく、APIが主体になっているというわけです。
利用イメージ
連携したいシステムに独自の処理を実装できる場合は、以下のようになります。
連携したいシステムに独自の処理を実装できない場合は、そのシステムと Payment Automation 2 をつなぐ中間のサーバ等に処理を実装することになります。
例:Salesforceと連携する場合のイメージ
Payment Automation 2 の機能の1つに、請求先を登録するという機能があります。この機能を使用する場合、これはAPIとして提供されていますので、このAPIをコールする部分を開発する必要があります。
ここでは、Salesforceの取引先責任者を Payment Automation 2 の請求先として登録する場合のイメージを見てみます。
SalesforceではApexという言語で独自の処理を実装することができますので、Apexで処理を実装することになります。
Payment Automation 2 では一部のAPIを除き、JSON形式でデータをやり取りします。
- 請求先として登録したいSalesforceの取引先責任者を取得する
- 取得した取引先責任者の情報をJSON形式に整形する
- 整形したデータをAPIのエンドポイントに送信する
シンプルですが、上記が請求先登録を行う処理のイメージになります。この処理をどう動かすかは、要求仕様次第で自由です。
ワークフローと組み合わせたり、Visualforceページ上でのボタン操作にひもづけたりすることができます。
※1 ただし、たとえ導入しているシステムがAPIを備えていたとしても、それだけでAPI連携できるわけではありません。
大手のシステムでは標準でコネクタを備えていることもありますが、それがない場合は接続部分の開発が必要になります。
シンプルなケースでは、ZapierなどのAPI統合サービスを利用することもできます。
