# コネクターの計画

コードの1行目を書き始めるよりも前に時間を取り、これから作成する Workato のカスタムコネクターのユーザーのために、あらゆる統合のユースケースについて考えておくことを強くお勧めします。これにより、どのようなアクションとトリガーがあればユースケースを満たせるのかが分かり、コネクターに含まれるべき最小限のアクションとトリガーのセットが見えてきます。このアクションとトリガーのリストは、将来的にいつでも拡張できます。

多くの場合、最も良くできたコネクターは、必ずしもアクションやトリガーの数が多いものではありません。そうではなく、よく考えられたアクションとトリガーのセットにより、さまざまなビジネスユースケースに対応できることが要件となります。自社が提供するサービスと、Workato のエコシステムに含まれる何百ものサービスとを統合するための方法として、自社プラットフォームへのコネクターをカスタマーのために構築する場合は、カスタマーのニーズが満たされるよう、アクションとトリガーのセットについてプロダクトマネージャーと開発者の両者で十分に検討しておくことをお勧めします。

# 統合ユースケースの洗い出し

コネクターは小さく始めて、時間をかけて大きく拡張できます、しかし、常に重要なのは、あらかじめ洗い出しておいた統合ユースケースにおいて、そのコネクターが自分やチーム、カスタマーの助けになるようにすることです。そのためには、ある程度の時間と労力をかけて、ユーザーがレシピでどのようにコネクターを使用するのかを考えておくことが求められます。まず、Workato で自動化したい具体的なユースケースを明らかにするために、ブレーンストーミングを行うことを強くお勧めします。社内利用のためにコネクターを構築する場合、そのユースケースは、自動化が望まれている面倒な手作業かもしれません。コネクターを構築して Workato のプラットフォームで公開し、カスタマーが Workato を使用してあなたのアプリケーションを自分のレシピに含められるようにしたい場合、ユースケースとしては、最大のビジネス価値を推進するようなものが想定されるでしょう。

# 例1:

XYZ 研究所の開発者であるあなたは、Salesforce へのコネクターを Workato 上で構築する仕事を任されました。会社では、Marketo から Salesforce に新しいリードを毎日手動でインポートしており、自社プラットフォームへの新規登録の応答時間に遅延が生じています。カスタマーデータと注文も、Salesforce から NetSuite に定期的にエクスポートする必要があり、ビジネスアナリストのチームがかなりの時間を費やしています。多くの場合、新規契約には、Salesforce には存在するものの、NetSuite には存在しない製品の項目も含まれています。

時間を節約し、ヒューマンエラーの可能性を減らすために、統合チームは上記の問題の解決に向けた5つの統合ユースケースを決定しました。

  1. Salesforce 内の新規リードについて、Slack で営業チームに通知する
  2. Salesforce 内の取引先データと NetSuite 内のカスタマーデータとを同期させる
  3. Salesforce 内の注文と NetSuite 内の領収書とを同期させる
  4. Marketo で獲得したリードを Salesforce 内で作成する
  5. Salesforce 内の製品と NetSuite 内の製品を同期させる

# 例2:

XYZ 研究所の主力製品は、カスタマーがあらゆるデバイスから財務会計にアクセスして管理できるクラウド会計ソフトウェア (XYZ 会計) です。プラットフォームの機能を拡張し、カスタマー離れを減らし、新しいリードを見つけるために、XYZ 研究所の製品チームは、Workato 上に XYZ 会計のコネクターを構築することも検討しています。そのようなコネクターがあれば、XYZ 会計のユーザーはそれを利用して、XYZ 会計に関わる会計データのエクスポートやインポートという面倒なプロセスを自動化できるようになります。

XYZ 会計で最もよく使用されている部分や、XYZ 会計と併用されるさまざまなアプリを評価した結果、XYZ 会計のカスタマーに最大の価値をもたらすものとして、いくつかの統合ユースケースが候補に残りました。

  1. Salesforce 内で新規に成立した商談があった場合、XYZ 会計で請求書を作成する
  2. Salesforce 内に新製品があった場合、XYZ 会計で新製品を作成する
  3. XYZ 会計に新規支払いがあった場合、Salesforce 内で商談を更新する
  4. XYZ 会計に新規ベンダーがあった場合、Salesforce 内で新規の納入業者を作成する
  5. Expensify 内に承認された新しい経費報告書があった場合、XYZ 会計で経費を作成する

# オブジェクトの基本セットの定義

多くの場合は、解決したい統合ユースケースが決まると、特定のオブジェクトに関して実装すべきコネクターのアクションとトリガーが見えてきます。

まずは、Workato のレシピで操作したい4 ~ 5種類のオブジェクトをリストアップすることをお勧めします。小規模なアプリケーションの場合、それですべてのオブジェクトが網羅されるかもしれません。百種以上のオブジェクトがある大規模なアプリケーションの場合、統合ユースケースに適合する5種類を選択することになるかもしれません。最初は範囲を限定しておき、後から手順を繰り返すことにしてもまったく問題ありません。

# 例3:

あなたは XYZ 研究所における統合担当の開発者です。運用チームが明らかにした統合ユースケースは、Salesforce の数種類のオブジェクトを中心に展開されています。それらのユースケースに基づいて考えると、Orders (注文)、Leads (リード)、Accounts (アカウント)、Products (製品) をサポートすることで、運用チームが求めているレシピを開発チームで構築できるように思われます。

# 例4:

あなたは XYZ 会計へのコネクターを構築する開発者です。そして、Invoices (請求書)、Products (製品)、Payments (支払い)、Vendors (ベンダー)、および Expense reports (経費報告書) のサポートを優先させるべきことを認識しています。自社アプリケーションへのコネクターをカスタマーのために構築する場合、事前に定義しておいたユースケースを越えてより多くのカスタマーがコネクターを利用できるよう、サポートするオブジェクトの種類を必要に応じて拡張するのが一般的です。

# 考えられるアクションの検討

オブジェクトを選択したら、今度はそれらのオブジェクトをサポートするアクションについて決定する必要があります。ほとんどの場合は、選択したオブジェクトの基本アクションとなる「Create (作成)」、「Read (読み込み)」、「Update (更新)」、「Delete (削除)」、および「Search (検索)」アクション (頭文字を取って CRUDS アクション) から始めると、それらをレシピ内で組み合わせて使用することで、大部分の統合ニーズに対応できます。ただし、自動化されたレシピによってデータが削除されることが望ましくない場合などに、「Delete」アクションの実装を控えるケースも見られます。

このほかにサポートを検討できる種類のアクションには、バッチアクションがあります。バッチアクションは、単一ではなく多数のオブジェクトを操作するアクションであり、多数のオブジェクトをアプリケーションの内外で同期させる必要があるシナリオでよく使用されます。中核的なユースケースを実現するためにユーザーがこの機能を必要とするのか、それともこの機能は後から追加できるのかを検討してください。

ほかにも、Workato の新規ユーザーにしばしば見られる失敗として、アクションを複雑にし過ぎるというものがあります。アクションをシンプルに保ち、常に1つの物事を扱うことに集中することで、エラーが発生した場合も、ユーザーのレシピのトラブルシューティングが容易になります。たとえば、「カスタマーを作成して請求書をカスタマーに添付」というアクションを作成するのではなく、それを分解して、「カスタマーを作成」と「請求書を添付」という2つのアクションにした方がよいでしょう。このように切り離すことで、より汎用的なアクションになり、ユーザーはアクションを組み合わせてより多くのことを実現できるようになります。

構築するコネクターの接続先 API に制限事項が存在する場合もあるため、注意してください。適切に構築された API のほとんどは、CRUDS アクションの実行に向けたエンドポイントを用意していますが、一部の API は処理量の大きいユースケースを想定したバッチアクション用のエンドポイントもサポートしています。

# 考えられるトリガーの検討

アクションだけでなく、オブジェクトベースのトリガーも実装して、エンドユーザーがアプリケーション内でイベントをトリガーできるようにすることをお勧めします。Workato では3種類のトリガー (ポーリング、静的 Webhook、動的 Webhook) をサポートしていますが、多くの場合は、想定する統合ユースケースに基づいて1種類のトリガーを実装すれば十分です。

ポーリングトリガーと Webhook トリガーのどちらかを選ぶ際は、「エンドユーザーがどれだけ迅速に新しいイベントにアクセスする必要があるか」に注目することが重要です。ユーザーが Web サイト上で支援を要求してくるといった一刻を争う状況で、すばやくヘルプを送ることに重点を置いてレシピを構築するには、Webhook が最適かもしれません。一方、CRM 内の新規売上に対しては、Webhook トリガーは不要で、ポーリングトリガーで十分かもしれません。

API の制限事項として、Webhook 機能そのものが存在しないという場合も考えられます。この機能がない場合、たいていはポーリングトリガーが良い代替手段になります。独自のアプリケーションに対するコネクターを開発している場合は、これを機会に Webhook トリガーの必要性を検討するのもよいかもしれません。

ポーリングトリガーについては、オブジェクトが作成されたときのトリガー、あるいはオブジェクトが作成または更新されたときのトリガーといった、基本的なものから始めることが通例です。

# ほかに特に追加するべきアクション/トリガーの検討

アプリケーションによっては、オブジェクトベースのアクションやトリガーの候補リストに現時点では含まれていない、特別なアクションを用意すべき場合があります。前に設定しておいた統合ユースケースすべてを振り返り、欠けているアクションやトリガーがないか確認しましょう。

達成したい統合ユースケースに関係するレシピを構築することを想像し、見逃されているアクションを探し出すことも有効な作業です。そのユースケースに必要となるレシピの簡単な骨組みを書き出してみると役立つことが、私たちの経験上分かっています。

# 例5:

あなたは Workato 上で XYZ コネクターを構築している XYZ 研究所の開発者です。カスタマーにとって重要な統合ユースケースの1つとして、XYZ の統合口座送金機能を Slack のようなビジネス用メッセージングアプリから利用するというものがあります。その統合ユースケースの骨組みを書き出した結果、以下のような手順が見えるようになりました。

レシピ: Slackbot の新規コマンドが XYZ 会計で口座送金を実行する アクションがサポートされているか
トリガー: Slack 上の新規コマンド「Post bank transfer (口座送金の投稿)」
1. XYZ 会計でサプライヤーを検索
2. サプライヤー ID を使用して、XYZ 会計で口座送金を実行 ×
3. Slack で返信を投稿しユーザーに通知

この骨組みを利用すると、このユースケースで非常に重要となる「口座送金の実行」アクションが見落とされていたことが容易に分かります。

まだ一度もレシピを作成したことがない方には、まず自身でレシピをいくつか作成してみることをお勧めします。そうすれば、レシピの構築にどのようなアクションが必要となるかについて理解が得られるでしょう。上記の例では、XYZ 会計のサプライヤーの内部 ID を取得するために、サプライヤーの検索アクションが必要となるでしょう。そのようなことを理解していると、見落としているアクションを確認するのに役立ちます。

# コネクターの状況確認

この作業を済ませたときには、構築すべきアクションとトリガーのリストが完成しているでしょう。表形式にすると、以下のようになります。

新規/更新トリガー 作成アクション 取得アクション 更新アクション 削除アクション 検索アクション 実行アクション
請求書
製品
支払い
ベンダー
経費報告書
口座送金

# いよいよコネクターを構築

これでコネクターの大まかな形が見えてきたので、今度は構築に取り掛かりましょう。次の章では、コネクターの構成を考え、構築する方法について説明します。


Last updated: 2023/8/31 1:07:14