今回はver.2.26で拡張された「DBトリガ」を活用した開発テクニックを解説いたしました。
＼ver.2.26のアップデートを「まだ確認していない」「おさらいしたい」方はこちら／
2023年9月6日（水）更新
MKupdate vol.24「ひろがる、つながる、なじむ ver.2.26【基本編】」
登壇者紹介
CRE部 部長の木下です。
ナレッジサイトとspirers boardの運営をしています。
ナレッジサイトとspirers boardの運営をしています。
司会の桂嶋です。本日は宜しくお願いします。
今回はトリガの使い方や開発テクニックを、できる限りわかりやすく説明したいと思いますので、開発以外の方もぜひご覧ください！
DBトリガのおさらい
DBトリガ カスタムプログラムアクション
ver.2.26で追加されたのは、非同期アクションのカスタムプログラムです。
このアップデートによりアプリの利用画面でもプログラムの実行ができるようなりました。
このアップデートによりアプリの利用画面でもプログラムの実行ができるようなりました。
レコードアクション・非同期アクションの違い
非同期アクションは個別で実行されるアクションです。
例えば非同期アクションのカスタムプログラムで、外部システムと連携するプログラムとメール配信を作成した場合、カスタムプログラムで処理が失敗したとしても他のアクションには影響しないため、メール配信は実行されます。
例えば非同期アクションのカスタムプログラムで、外部システムと連携するプログラムとメール配信を作成した場合、カスタムプログラムで処理が失敗したとしても他のアクションには影響しないため、メール配信は実行されます。
非同期アクションは、レコードアクションで実行された結果を利用できるなどシステムの幅が広がるアクションとなります。
DBトリガの基本的なおさらいはMKupdate vol.13「次回から使おう…ではなく”すぐ使おう！”」をご確認ください。
DBトリガを活用した開発テクニック
今回はzoomのURLを発行する商談アプリをベースに、主に黄色の箇所について、DBトリガのカスタムプログラムアクションの具体的な使い方について解説していきます。
全体像
利用しているトリガ
今回使用しているトリガは「更新トリガ」のみです。
登録トリガ、削除トリガは作成していません。
更新トリガの設定内容にについて説明します。
登録トリガ、削除トリガは作成していません。
更新トリガの設定内容にについて説明します。
事前に知っておいてほしい情報として、従来はレコードアクションが先に実行されて、その後非同期アクションが実行されます。
今回のアプリでは、発動条件をしぼることで非同期アクションのカスタムプログラムを実行した後に、レコードアクション→非同期アクションメール配信が動作するように作成しております。
今回のアプリでは、発動条件をしぼることで非同期アクションのカスタムプログラムを実行した後に、レコードアクション→非同期アクションメール配信が動作するように作成しております。
全体像①の動き
ユーザ側が商談依頼をすると、ステータスが「未発行」として登録されます。
このステータスはデフォルト値で設定しているので、DBトリガは利用していません。
このステータスはデフォルト値で設定しているので、DBトリガは利用していません。
全体像②〜③の動き
日程調整担当者が、商談日時とステータスを会議URL発行」に更新すると、カスタムプログラムが実行されます。
カスタムプログラムが実行されると、後続のzoomURLの発行、DBへの更新、メール配信と自動で実行されていきます。
カスタムプログラム内の動き
カスタムプログラム内の動きは以下のとおりです。
2.取得したURLを ver.2 の API を利用して、商談DBを更新
3.更新する際にステータスを処理中に変更
4.処理中でデータが更新された際に、レコードアクションが動作
自ＤＢ更新で、ステータスを発行済みにし、配信フラグを配信する
5.メールアクションが実行され、ユーザと営業にメールが飛ぶ
詳しい条件やサンプルプログラムは以下の記事をご確認ください！
開発情報・ナレッジ
ver.2
high
2023年9月6日 (水)
カスタムプログラムを使ってzoomのURLを発行するアプリ アプリ、サイト設計・構築
4では発動条件2つ用意しており、同じトリガ内で「配信フラグが配信するかつ処理中以外」で更新された場合は、「配信フラグが配信しない」に更新するトリガを入れております。
この配信フラグの処理をしていると、どうなるんでしょうか？
これを入れておくことで、処理中以外の場合に誤って自動でメールが飛ばない仕組みを作成しております。
これを入れておくことで、営業の方が商談情報を更新する際にステータスが「配信する」で更新された場合に、メールが飛んでしまうことを防いでいます。
このように動作ごとにステータスを更新作る動きをすることで、必要な時に必要なトリガが動かせるだけでなく、
プログラムを利用するので、処理が止まった際にどこで止まったかわかるように作ることもできます。
ステータスによる発動条件の設定方法
ステータスによる発動条件は、カスタムプログラムアクション内のPHPで分岐処理を行っています。
「レコードアクション」「非同期のメール配信」は、画面上から条件を選択することができますが、カスタムプログラムは経路条件は指定できるものの、ステータスによる発動条件はPHPで分岐処理のプログラムが必要となります。
ステータスによる発動条件は、カスタムプログラムアクション内のPHPで分岐処理を行っています。
「レコードアクション」「非同期のメール配信」は、画面上から条件を選択することができますが、カスタムプログラムは経路条件は指定できるものの、ステータスによる発動条件はPHPで分岐処理のプログラムが必要となります。
普段顧客対応されている方やシステムの保守などされている方は経験したことあるかもしれないですが…
稼働中のシステムでデータが正しく登録されていない、メールが届かなかった等発生した際に色々な調査をされると思いますが、ステータス管理をしておけばどこまで処理が進んでいて、どこからが失敗したのかがすぐに判別で切るので、運用面を考えてもとても便利だなと思いました！
稼働中のシステムでデータが正しく登録されていない、メールが届かなかった等発生した際に色々な調査をされると思いますが、ステータス管理をしておけばどこまで処理が進んでいて、どこからが失敗したのかがすぐに判別で切るので、運用面を考えてもとても便利だなと思いました！
無限ループを回避するアーキテクチャ
カスタムプログラムが×になっている箇所についても解説します。
この部分ですが、発動条件で絞っているため×にしているわけではありません。
カスタムプログラム内でAPIを利用してデータを更新した場合、カスタムプログラムが実行しないようにプラットフォーム側で制御されています。
カスタムプログラム内でAPIを利用してデータを更新した場合、カスタムプログラムが実行しないようにプラットフォーム側で制御されています。
カスタムプログラムはDBトリガなので、基本的にデータの登録や更新があると発動すると思いますが、カスタムプログラムでAPIを使ってDBに更新した時に、実行しないということですね。
なぜ、この制御が入っているかいうと、自身を更新するAPIの仕組みをカスタムプログラムで作成することで無限ループを作れてしまうためです。
SPIRALは共用サービスのため、無限ループが作れてしまうとサービスに負荷がかかり、他のユーザに影響が出てしまう可能性があるため禁止する仕組みが入っています。
ちなみにレコードアクションも同様にレコードアクションで登録/更新されたデータに対してトリガは実行されません。
SPIRALは共用サービスのため、無限ループが作れてしまうとサービスに負荷がかかり、他のユーザに影響が出てしまう可能性があるため禁止する仕組みが入っています。
ちなみにレコードアクションも同様にレコードアクションで登録/更新されたデータに対してトリガは実行されません。
安全にプログラムを使えるプラットフォーム
カスタムプログラム内からAPIを実行し、データ操作を行った場合は、カスタムプログラムは実行されません。
よって無限ループを回避するような仕様になっており、安全性をプラットフォーム側で担保しているので、安心してカスタムプログラムを使うことができます。
カスタムプログラム内からAPIを実行し、データ操作を行った場合は、カスタムプログラムは実行されません。
よって無限ループを回避するような仕様になっており、安全性をプラットフォーム側で担保しているので、安心してカスタムプログラムを使うことができます。
DBトリガの使い方ポイントまとめ
ここまでのDBトリガのポイントをまとめました。
ステータスをうまく使うことで、必要な時に実行できる
レコードアクションと非同期トリガを連携して作れる
無限ループなどプラットフォーム側で制御しているので、安心して使用できる
ステータスをうまく使うことで、必要な時に実行できる
レコードアクションと非同期トリガを連携して作れる
無限ループなどプラットフォーム側で制御しているので、安心して使用できる
その他：ステータス配信フラグを使った開発テクニック
トリガを使って配信する・しないを制御できるのはかなり便利というお話をします。
管理者からユーザにメールを配信する場合、配信フラグで管理することが多いと思います。
その際に、配信フラグをDBで直接変更する運用の場合、「配信する」状態から変更し忘れて通知されてしまうことを防ぎたい！といわれるケースがあると思います。
その際に、配信フラグをDBで直接変更する運用の場合、「配信する」状態から変更し忘れて通知されてしまうことを防ぎたい！といわれるケースがあると思います。
最初は「配信する」のステータスで配信できて良いんですけど…そのあとに「配信しない」に戻すのを忘れていると、次更新した時とかに、メール送りたくないのに送られてしまうみたいな時ですよね。
そうです！「配信依頼」のステータス以外で更新された場合に「配信しない」になるように設定しておくことで、ステータスを配信依頼に変更した場合のみ、メールが配信することができます。
次回以降で更新する場合は、自動で配信フラグが「しない」に変わるので、誤配信を減らすことができます。
次回以降で更新する場合は、自動で配信フラグが「しない」に変わるので、誤配信を減らすことができます。
最後にちょっとした補足ですが、SPIRAL ver.2 でも teams のメールアドレス宛の配信で通知が飛ばすことができるようになっています。
以前までは、teams のメールアドレス宛に配信してもチャット通知が飛んでこなかったのですが、最近では届くようになっています。
APIで作成していた方は、メールアドレス宛の通知もお試しください。
以前までは、teams のメールアドレス宛に配信してもチャット通知が飛んでこなかったのですが、最近では届くようになっています。
APIで作成していた方は、メールアドレス宛の通知もお試しください。
詳細はTeams に登録通知を行う方法をご確認ください！
最後に
トリガ機能がアップデートしたことで、
・外部システムともつながる
・構築できるシステムの幅がひろがる
・業務になじむ（フィッティングが高い）
プラットフォームにSPIRAL ver.2 は進化しています！
・外部システムともつながる
・構築できるシステムの幅がひろがる
・業務になじむ（フィッティングが高い）
プラットフォームにSPIRAL ver.2 は進化しています！
木下さんありがとうございました！
アップデート機能の体験方法
リリース前（9月6日以前）
ベータ環境でお試しいただけます。ベータ環境の申請はこちら
リリース後（9月6日以降）
ご自身のSPIRAL ver.2アカウントでお試しいただけます。SPIRAL ver.2アカウントをご契約されていない場合はトライアル環境でお試しいただけます。
トライアルの申請はこちら
