話題のサービスGoogle Cloudの「A.I.」を使ってみた!

こんにちはエヌデーデーの関口です。

最近ちまたではGoogle Cloudの新しいA.I.についてたくさんの記事を見かけますね。そこで、このブログでも負けじとA.I.について記事を書いてみようと思います。

GoogleのA.I.と言えば皆さんご存じの・・・Application Integration

そう、Application Integrationですね!ということで、今回はApplication Integrationの記事です!

Application Integrationの概要

Application Integrationは2023年7月に発表されたGoogle CloudのiPaaSにカテゴライズされるサービスです。

iPaaS(Integration Platform as a Service)とは、組織が利用している多数のクラウドサービスやオンプレミスのサービスを連携し、別のサービスにデータを連係したりするなどを容易にするためのサービスです。

同じような機能を提供するソフトウェアの分類にEAIやETLというものがあります。弊社ではEAIツールであるDataSpider Servistaを取り扱っていますが、iPaaSというものは一般的にはこれらの機能をクラウド上でサービスとして提供しているものと理解してください。

Application IntegrationはCloud Pub/Sub、Cloud Storage、BigQueryなどのGoogle Cloud上のサービスをはじめ、Salesforceなどに代表されるその他サードパーティ制のSaaS内のデータを抽出し、変換等を行った上で他のデータソースにデータを送るというような事ができるようになっています。

言葉だけで表現すると、いわゆるバッチ処理と何が変わらないのか?と思われる方もいると思いますが、主に次のようなメリットがあります。

  • 数多くのコネクタ
    Application Integrationでは、各種データソースにアクセスする為のコネクタと呼ばれるものがあらかじめいくつも用意されているため、SaaSへの接続が容易になっています
  • フローやマッピングなどが分かりやすいGUIで提供されている
    データの加工や条件分岐などのフロー、またデータ項目のマッピングなどはGoogle Cloud上のコンソールでGUIを操作して行うのでわかりやすくなっています
  • 自動スケール
    Google Cloudにより自動的にスケールされるため、信頼性や保守性が向上します

また、様々なトリガーが容易されているので、データの登録や更新のタイミング、あるいは定期的なスケジューリングで、Application Integrationに定義した処理を実行することができます。

Application Integrationを利用することで、例えばSalesforceにデータが作成されたら、それをトリガーにBigQueryにデータを登録する、金額が一定金額を超えている場合は、マネージャにメールを送る、別のデータベースからデータを取得してSalesforceのデータと付き合わせて加工した内容をCloud SQLに入れるというような事も比較的容易に構築することができるのです。

今回実現する構成

今回はSalesforceのイベントをApplication Integrationで捉えるということをやってみようと思います。

SalesforceにはChange Data Capture(変更データキャプチャ:CDC)という仕組みがあり、この仕組みを利用すると、Salesforce上のオブジェクトレコードに変更が加わった際に、外部のアプリケーションなどにその情報を通知するということができます。

今回の検証ではこの機能を用いて、取引先(Account)のデータに何か変化があったときにイベントが発火し、メールを送信するという単純な仕掛けを作成してみます。

なお、CDCについてはSalesforceのガバナ制限などを考慮して、一括処理などを行う場合はCDCを停止するなどの配慮が必要だということもお忘れ無く。

Salesforceを構成する

以降はSalesforce側で認証するための設定ですので、ご存じの方はGoogle Cloud側の設定まで読み飛ばしてください。

Salesforceにアクセスするためのユーザーを作成

今回はSalesforceが無料で利用できるDeveloper Editionを用いた環境を用意します。サインアップする際の手順等はここでは説明を省略します。(きっとそのうち当社のSalesforceチームが書いてくれるかも?)

さて、環境が用意できたらApplicaiton IntegrationからSalesforceにアクセスする為のユーザーを作成します。以降の処理はすべてシステム管理者で実行しています。

Salesforceのシステム連携専用のユーザーについては、2023年3月からSalesforce Integrationというライセンスが、エディションによって数は異なりますが、無料でいくつか使えるようになっています。このライセンスが付与されたユーザーではSalesforceのUIを使用することはできないのですが、システム連携用にAPIなどへのアクセスはできるようになっています。Salesforce Integrationのユーザーを使用する方法はGoogle Cloudのドキュメントで説明されている設定方法(Salesforceライセンスを設定する方法)とは異なりますが余分なライセンスを消費しないという点でもおすすめです。

Salesforceの画面右上の歯車マークから「設定」 > 左メニューの「クイック検索」に「ユーザー」を入力し > ユーザー画面を表示 > 「新規ユーザー」をクリックします。

次の図のように、ユーザーライセンスとプロファイルをそれぞれ、Salesforce IntegrationSalesforce API Only System Integrationsにセットすると、システム連携用のユーザーが作成できます。

※注意:作成時にSalesforce Integrationライセンスを選択すると、パスワード認証のセキュリティを向上させるためのシークレットトークンの発行ができませんので、一度別のライセンスで作成し、シークレットトークンを発行したらSalesforce Integrationに戻すという作業が必要です。

なお、最近のSalesforceではパスワードが不要のOAuth2のクライアント資格フロー(grant_type=client_credentials)も提供はしていますが、Application Integrationから接続する為にはパスワード認証フロー(grant_type=password)を利用するので、ユーザー作成後はパスワードなどを控えておいてください。

権限セットを作成する

ユーザーを作成したら、次は権限セットを作成します。Salesforce上の様々なオブジェクトに対する操作権限をあらかじめまとめて設定しておけるものです。権限セットにライセンスを付けると、そのライセンスが付けられたユーザーには自動的に権限がセットできるようになりますし、ユーザー毎に権限セットを選択して設定するということもできます。ただし、ライセンスに紐付いた権限セットについては、設定できる項目が限定されてしまうため、今回はライセンスに紐付かない権限セットを作成します。

Salesforceの画面右上の歯車マークから「設定」 > 左メニューの「クイック検索」に「権限セット」を入力し > 権限セット画面を表示 > 「新規」をクリックします。

ライセンスは「–なし–」を選択しておいてください。

保存すると作成した権限セットに割り当てる権限の設定画面が表示されるので「オブジェクト設定」をクリックします。権限セット画面の検索窓に「取引先」と入力すると候補項目が表示されるのでその中から「取引先」をクリックします。

取引先の設定画面が表示されたら「編集」ボタンを押します。(「プロパティを編集」ボタンではないので注意)

オブジェクトの権限を示した表のチェックをすべてつけて保存します。

「商談」についても同様に設定します。

作成したユーザーに権限セットライセンスと権限セットを付与する

先ほど作成したシステム連携用のユーザーに権限セットライセンスと権限セットを付与します。

権限セットライセンスを先に付与しないと、先ほど設定した権限セットが設定できないので注意してください。(筆者はこれがわからず時間を費やしました)

ユーザー画面に遷移すると表示されるユーザー一覧から作成したシステム連携用のユーザーをクリックします。ユーザーの詳細画面をスクロールし「権限セットライセンスの割り当て」項目の「割り当ての編集」ボタンを押し、リストの中からSalesforce API Integrationにチェックをいれて保存してください。

次にユーザーの詳細画面のなかから「権限セットの割り当て」項目の「割り当ての編集」ボタンを押します。

遷移した画面で、先ほど作成した権限セットを「追加」して保存します。

これでユーザー側の設定は完了です。

変更データキャプチャを有効にする

次にSalesforceとして変更データキャプチャの機能を有効にします。

「設定」 > 左メニューの「クイック検索」に「変更データキャプチャ」を入力し > 変更データキャプチャ画面を表示します。

使用可能なエンティティから、今回の場合であれば「取引先 (Account)」を選択されたエンティティに移動し、保存ボタンを押してください。

接続アプリケーションを作成する

最後にOAuth2にに必要なコンシューマー鍵、コンシューマーの秘密を取得します。要するにクライアントIDとクライアントシークレットのことです。そのためはまず接続アプリケーションを作成・登録します。

「設定」 > 左メニューの「クイック検索」に「アプリケーションマネージャー」を入力し > アプリケーションマネージャー画面を表示します。

右上の「新規接続アプリケーション」を押して各種項目を入力していきます。「コールバックURL」には任意のURLを入れておきます。(私はhttps://login.salesforce.com/にしています)

また、「選択したOAuth範囲」は次のいずれかを設定します。(両方設定しても可)

  • API を利用してユーザーデータを管理 (api)
  • いつでも要求を実行 (refresh_token offline_access)

保存を実行するとコンシューマー鍵とコンシューマーの秘密が表示されるので、忘れないようにメモしておいてください。なお、もう一度これらを取得し直したい場合は、アプリケーションマネージャー画面のリストから対象のアプリケーションの右端のドロップダウンから「参照」を選択し、詳細画面で「コンシューマーの詳細を管理」ボタンからユーザー認証を経て確認することができます。

アプリケーションを作成したら、アプリケーションマネージャー画面のリストから対象のアプリの右端のドロップダウンから「Manage」を選択します。

詳細画面に遷移したら許可されているユーザーの項目を「すべてのユーザーは自己承認可能」にしてください。

これでSalesforce側の設定は完了です。

Application Integrationを構成する

SalesforceからCDCを受け取る準備ができたので、Google Cloud側でApplication Integrationを設定してみます。

Google Cloudのコンソールから検索窓に「Application Integration」と入力するか、ハンバーガーメニューから「アプリケーションの統合」を探してクリックします。

リージョンを選択する(初回起動時)

選択しているプロジェクトで初めてApplication Integerationを作成する場合は、リージョンを選択するように促され、これをスキップすることはできません。リージョンについては2023年12月現在次のリージョンではSalesforceのCDCを利用できないのでこれら以外のリージョンを選択してください。

  • asia-northeast1
  • asia-south1
  • australia-southeast1
  • europe-west2
  • europe-west3
  • europe-west6
  • northamerica-northeast1
  • southamerica-east1
  • us-east4
  • us-west2

リージョンを選択したら「QUICK SETUP」をクリックしてください。しばらくすると概要ページに遷移します。

なお、ここで選択したリージョン以外でも後でリージョンを追加することはできますが、追加したリージョンは削除ができません。

統合(フロー)を作成する

早速フローを作りましょう。なお、Application Integrationではフローの集まりを「統合(Integrations)」という名称で呼んでいます。

概要ページで「CREATE INTEGRATION」をクリックします。

Integration nameとリージョンを選択します。リージョンには今回asia-northeast2を選択しています。

Salesforceトリガーの設定

作成ボタンを押すとフローを作成するキャンバスが表示されます。下図の中央ペインにトリガー(Trigger)やタスク(Task)を配置してフローを作っていきます。下図ではトリガーを選択するためのボタンを押した状態を示しています。

複数のトリガーが用意されているのがわかると思います。この中の1つにある「Salesforce」を選択します。

キャンバス上にアイコンを配置すると、左側に変数、右側にトリガーの設定ペインが表示されます。

変数はこの統合のフローが実行されている間に共有される値を格納します。変数は自分で追加することもできますし、事前に定義されているトリガー用の変数もあります。例えば、Salesforceのトリガーを配置すると、このトリガー特有であらかじめ決められた変数が自動的に設定されるという具合です。

なお、この変数にどのような値が入る想定なのかという説明は、SalesforceのCDCに関するドキュメントをご覧ください。簡単に説明するとSaleforceTriggerCdcPayloadには、オブジェクト作成時には値の入っているフィールド名と値、更新の場合は更新されたフィールド名と値がJSON形式で、SalesforceTriggerCdcSnapshotには作成、更新されたオブジェクトの全フィールドと値が入ってきます。

次にSalesforceトリガーの設定についてです。

こちらは主にSalesforceトリガーがどのSalesforceテナントに接続し、どんなイベントをハンドリングするのかという事を設定します。

Labelには複数のトリガーを識別するために任意の名称を付けます。

今回の例ではTrigger InputのEvent typeには「Change Data Capture (CDC)」を選択してください。

次にSalesforce instance configurationをクリックし、+ Add new Salesforce instance configurationをクリックします。

ダイアログが開くので、接続するインスタンスの情報を入力します。

Salesforce instance connection nameには接続設定を識別するための任意の名称を入力してください。

Salesforce domainには先に設定してあるSalesforceのドメインを入力してください。

Authentication profileには接続先のSalesforceドメインに接続するのに利用するプロファイルを選択するのですが、現時点では接続プロファイルがないので、+ Add new authentication profileをクリックします。

するとさらにダイアログが開き、認証プロファイルに関する情報を設定できるようになります。

認証プロファイルに名前を付けて、OAuth2に必要な情報を入力します。

Token endpointは、本番環境はhttps://login.salesforce.com/services/oauth2/tokenで、サンドボックスならば、https://test.salesforce.com/services/oauth2/tokenとなります。

Client IDはコンシューマー鍵、Secretにはコンシューマーの秘密を入力してください。Scopeには何も入れなくて結構です。

Usernameには接続ユーザーのアカウントを入れ、Passwordにはパスワードとシークレットトークンを繋げた文字列を入力してください。

最後にReuqest typesにRequest Bodyを選択して、SAVEを押します。認証情報が正しければ元のダイアログに戻りますので、AddでSalesforceインスタンスへの接続設定を完了します。

なお、ここで設定したプロファイルはApplication Integration画面の左メニュー「Auth プロファイル」から後で編集することも可能です。(ちなみに先に作成していおいたSalesforce instanceについては現在のところREST API経由でしか削除などができないので注意です)

次に、Salesforce channel configurationをクリックし、+ Add new Salesforce channel configurationをクリックします。

ダイアログが開くので、ここにCDCでキャプチャする対象のオブジェクト名を1つだけ入力します。今回はAccountを入力しました。

さいごにOperationをSalesforceのオブジェクトに関するイベント、Create, Update, Delete, Undeleteのうちから1つ選択します。従って1つの統合のなかでCreateもUpdateもイベントを取得したい場合はトリガーを2つ配置する必要があります。

今回は既存のAccountが更新されたケースに対応するUpdateを対象にしてみます。

Send Emailタスクを配置する

次にタスクを配置するため、TASKSのドロップダウンから「Send Email」を選択します。

キャンバス上にSend Emailのタスクを配置すると、メール送信の設定が右ペインに表示されますので、送信先(To Recipient(s))や件名(Subject)、Body formatに応じた本文(Body)を設定します。これらは変数の値を利用してフローの中で動的に加工して設定もできますし、この入力項目に直接文字を入力しても問題ありません。

今回は直接文字を入力してみましょう。

設定ができたら、トリガーとタスクをつなぎます。それぞれのアイコンのピン同士をドラッグ&ドロップでつなぐだけです。

デプロイ&実行

さて、ここまで来たらデプロイと実行をしてみましょう。(実際はテストモードでまず実行といいたいところなのですが、記事の都合上長くなるので省略します)

画面右上部のPUBLISHをクリックするとデプロイが行われます。

デプロイが完了すると、ENABLE EDITINGをクリックするまでキャンバス上で編集ができなくなります。

統合は変更する度に、バージョンが上がっていくという方式になっており画面右上部のバージョンを示すドロップダウンをクリックすると、これまでのバージョンがリストで表示されます。

また、その隣の三点リーダーをクリックすると、バージョンを削除したり、コピーしたり、あるいはそのバージョンの統合をJSON形式でダウンロード/アップロードするということも可能になっています。

統合をバックアップしておきたい時などは、このJSON形式のダウンロードをしておくと良いでしょう。

実行してみる

SalesforceとApplication Integrationの設定が完了したので実行してみましょう。

Salesforceから取引先のデータを一件選んで更新してみます。動画をご覧ください。

このように取引先のデータを更新してしばらくするとメールが送信されました。

条件分岐、変数を試す

Salesforceの設定などに少々戸惑いましたが、設定ができてしまえば簡単に統合のフローが作成できる事はわかりました。

それでは、次に条件分岐を試してみましょう。

取引先の年間売上が一定の金額(今回は100,000,000)を上回っている場合は、承認が必要というケースをつくってみます。キャンバスのENABLE EDITINGを押して編集を開始しましょう。

※実運用上はこのフローは役に立ちません。なぜならすでにSalesforce上で更新されてしまったことに対して承認するというフローなので非承認となった場合の動作なども定義しないと意味が無いからです。

変数を追加する

年間売上の金額を格納する変数AnnualRevenue(Integer)、条件分岐に用いるConditionalRevenue(Integer)、それからメールに会社名を含めたいので、会社名を格納するCompanyName(String)を定義します。

キャンバスの左ペインから + CREATEで変数を追加していきます。ここではConditionalRevenueの設定を例にしています。次の図のように、変数名とデータ型それから初期値がある場合はその値を入力します。

データマッピングで値を変数にセットする

変数を定義したらトリガーから受け取る値を変数に格納するデータマッピングのタスクを追加します。

TASKSからData Mappingを選択して、Salesforceトリガーと繋げます。そしてData Mappingの設定ペインでOPEN DATA MAPPING EDITORをクリックします。

Mapping Editorでは下図のように、どの変数をどの変数に入れるのかということを複数定義できます。移送元の変数がJSONである場合は、そのJSONの特定の属性を取るための.GET_PROPERTY()や、取得した値の変換を行うためのTO_INT()などのメソッドが容易されており、中にはJSONの配列属性の特定の値を集計するためのメソッドなども用意されています。

下図はSalesforceTriggerCdcSnapshotという変数からAnnualReveneuという属性の値を取得して、変数のAnnualRevenueに格納するという場面です。

同時に会社の名前も変数に入れて、次のようなマッピングができました。

条件分岐を行う

条件分岐は特定のノードから2本以上の線(Edge)を引くことで実現できます。

今回のケースでは承認を行う事になっているので、承認タスク(Approval)をまず置き、最終的なSend Mailタスクと分かれるように線を引きます。下図のようになります。

このままでは条件の分岐が行われません。まずは分岐の起点のポイントをクリックしてみてください。右側にForkという設定が表示されます。

Forkでは次のタスクをどういうときに実行するのかという条件を指定できます。

  • Run all match: 次の条件にすべて合致しているものすべて実行。例えば3つ線が引いてありそのうち2つが条件を満たしているのであれば、それら2つとも実行する
  • Run first match: 最初の条件に合致したものを実行。3つ線が引いてあり、そのうち2つが条件を満たしている場合、順番は関係なく、いずれか1つを実行する

通常はRun all matchで問題無いと思います。

一方、線が集まってくる側もポイントも設定が可能です。右側にはJoinという設定ができるようになっています。

Joinではこのタスクに到達するまでの条件がどのような場合なら実行するのかを設定します。

  • When all tasks and conditions succeed: 線につながっているタスクがすべて成功し、線に付けられている条件(後述)もすべて満たされている場合に実行する
  • When all tasks succeed: 線につながっているタスクがすべて成功している場合に実行する(条件は関係ない)
  • When any task succeeds: 線につながっているタスクがいずれか成功している場合に実行する

いわゆる今回のようなYes/Noの条件分岐の場合はWhen any task succeedsを選択しますし、あるタスクがすべて完了したら後続処理を流すということであれば、他の2つを使い分けるという事になります。

最後に線(Edge)に条件を追加していきます。線をクリックすると条件(Condition)が設定できるようになります。

ここには、変数や値そのものを比較演算子(=や<など)を用いて条件を書くことができます。複数の条件をANDやORを用いて繋げることも可能です。

今回、承認側にフロー流すための条件は次のようなものになります。

$AnnualRevenue$ >= $ConditionalRevenue$

一方、Data Mappingから直接Send Mailへの線の条件は次のようなものです。

$AnnualRevenue$ < $ConditionalRevenue$

承認(Approval)の設定をする

承認(Approval)は宛先に含めたメールアドレスに対して、承認か却下を選択させる画面へのURLを送信する機能です。承認するとタスクのアウトプットとしてtrue、却下するとfalseが出力されます。この値は後続のタスクなどで、$`Task_<タスクID>_isApproval`$という変数で利用ができます。

承認の主な設定項目は、承認メールの受信者、承認メールへのメッセージ、リマインダーメールの送信タイミング、承認までの有効期限と承認タスクを実行しなかったときに、暗黙的に承認とするのか、却下とするのかの設定です。

なお、承認メールの受信者には、Application Integration 承認者ロールがIAMで設定されていることが必要です。設定したのに送信されないというときには、IAMの設定を見直してください。

今回は文面に会社名や金額を含めてみたいと思います。次のようなメッセージにしてみました。

次の会社に変更が加わりました。承認/却下の判定をお願いします。
会社名: $CompanyName$
年間売上: $AnnualRevenue$

それから最後に送信されるメールも次のようなHTMLで送信してみます。

<p>次の会社の情報が更新されました。</p>
<table border="1">
<tr>
<td>
会社名
</td>
<td>
$CompanyName$
</td>
</tr>
<tr>
<td>
年間売上
</td>
<td>
$AnnualRevenue$
</td>
</tr>
</table>

最後に、承認(Approval)から伸びている線が無条件でメール送信することになっているので、承認されたときだけフローが流れるように次のような条件を設定します。この設定をしていないと却下の場合でも最後のフローに流れるということになってしまいます。

$`Task_3_isApproved`$ = true

全体像としては次のようなキャンバスになりました。

条件分岐を実行してみる

年間売上が規定の金額を超えていない場合は次のようになりました。

年間売上が規定の金額を超えている場合は次の通りです。一度承認のためのメールを受信し、そこに記述されている承認要画面のURLから専用画面に遷移している様子がわかると思います。

ログを見る

実行経過を調べる場合はアプリケーションの統合画面からログに遷移すると、実行ログが表示されます。

ログツリーを拡げていくと、Data Mappingの様子や、変数の様子がわかります。

また、変数がJSONである場合は値の項目をクリックすると、その内容がダイアログで表示されるようになるためデバッグするのに利用できますね。

まとめ

今回はGoogle CloudのAI・・・もといApplication Integrationを使ったSalesforceとの連携部分を紹介しました。

私はGoogle Cloudの記事を書くことが多めですが、当社ではSalesforceの実績も高く評価されておりますので、今後の記事でもSalesforceと他のGoogle CloudのサービスやSaaSなどとの連携を試したものを載せていこうと思います。