
クエステトラユーザのみなさん、こんにちは。開発責任者の畠中です。
申し込みフォームで、入力してもらったメールの存在確認をするようにしていました。
申込フォームで、メールの存在確認をはさむ — 受信タスク (フォーム) の使い方 —
そして次に、フォームに締め切りを設定しました。
申し込みフォームに期限を設定する — 受信タスク (フォーム) の使い方 —
今回は、更に電話番号も入力してもらうようにしようと思います。また電話番号の存在確認もするようにします。
今はこのようになっています。
- 開始イベント(フォーム)でメールアドレスを入力してもらう。
- 1 で入力されたメールアドレスにメール送信。3 の URL を伝える。
- 受信タスク (フォーム) で続きの情報を入力してもらう。
- ヒューマンタスクはおまけ。
AND ゲートウェイで別れた下半分の流れは、フォームの締め切りのための処理です。
これを以下のように変えます。
- 開始イベント(フォーム)でメールアドレスと電話番号を入力してもらう。
- 1 で入力されたメールアドレスにメール送信。4 の URL を伝える。
- 1 で入力された電話番号に電話をかける。4 で入力してもらう、確認番号を伝える。
- 受信タスク (フォーム) で、確認番号と続きの情報を入力してもらう。
- ヒューマンタスクはおまけ。
前回の「ワークフローの途中で、自動的に電話をかける」の仕組みを、取り入れる形になります。
ワークフローの途中で、自動的に電話をかける
まずデータ項目です。項目名の先頭に★印がついているものが、新しく追加するデータ項目です。
データ項目名 | データ型 | 必須 | 開始イベント (フォーム) |
受信タスク (フォーム) |
ヒューマン タスク |
---|---|---|---|---|---|
件名 | – | – | – | – | 表示のみ |
メールアドレス | 文字型 単一行 |
〇 | 編集可 | 表示のみ | 表示のみ |
★電話番号 | 文字型 単一行 |
〇 | 編集可 | 表示のみ | 表示のみ |
名前 | 文字型単一行 | 〇 | – | 編集可 | 表示のみ |
★確認番号 | 数値 | 〇 | – | 編集可 | 表示のみ |
フォームキー | 文字型 単一行 |
– | – | – | 表示のみ |
初期値: #{#randomString(20)} |
|||||
申し込み締め切り | 日時型 | – | – | – | 表示のみ |
初期値: processInstanceStartDatetime.addDays(7) |
|||||
API Key | 文字型単一行 | – | – | – | 表示のみ |
初期値: #{#randomString(5)} |
|||||
★callback url | 文字型単一行 | – | – | 表示のみ | |
★確認番号(サーバ保持用) | 数値 | – | – | 表示のみ |
前回の「ワークフローの途中で、自動的に電話をかける」の仕組みから
- [電話番号] 申込者の電話番号。存在確認のため、電話をかける先の電話番号になる。
- [API Key] 受信タスク (Webhook) で使用。コールバック URL の一部になる。
- [callback url] Twilio から電話がつながった際にコールバックされる URL。受信タスク (Webhook) の URL を指定。
を追加しています。それに加えて
- [確認番号]
- [確認番号 (サーバ保持用)]
を追加しています。後者が Questetra で動的に生成し、申込者に電話で伝える番号です。 前者は受信タスク(フォーム)で、申込者に入力してもらう番号です。 両方の番号が一致していることで、申し込み者の電話番号の存在を確認します。
ワークフロー図は以下の通りです。
赤い四角で囲まれた「電話の発信」部分が追加された部分です。 この部分は前回ブログで作成したワークフローアプリのコピーです。
赤い四角で囲まれた部分の先頭、「確認番号の生成」には、乱数生成のアドオンを使っています。
乱数ジェネレータ
アドオンのインポートは、以下を参照してください。
設定は以下のようにします。0 から 99 の間の乱数を生成し、「確認番号 (サーバ保持用)」に保存します。
処理失敗時に、トークンをエラー境界イベントに移動 | (チェックなし) |
---|---|
最大数をセットしてください (100:0 – 99) | 100 |
乱数が格納される数値型データを選択してください | 「確認番号(サーバ保持用)」 |
「callback url 計算」およびメッセージ送信中間イベント (HTTP) の設定は省略します。
「callback url 計算」では、次の受信タスク (Webhook) の URL を計算するようにします。
メッセージ送信中間イベント (HTTP) は、Twilio の「電話をかける」API を呼び出すようにします。
前回のブログを参考に、設定してください。
受信タスク (Webhook) の設定です。Twilio のコールバックに対して、「話す内容」を返します。
確認番号を伝えるようにしなければなりません。
API キーの値を指定する文字型データ項目 | 「API Key」 |
---|---|
受信する HTTP リクエストのメソッド | POST |
受信する HTTP リクエストの Content-Type | application/x-www-form-urlencoded |
リクエストボディ保存先の文字型データ項目 | |
HTTP レスポンスの Content-Type | text/xml;charset=UTF-8 |
HTTP レスポンスの内容 | |
<?xml version="1.0" encoding="UTF-8"?> <Response> <Say voice="alice" language="ja-JP">お申込みありがとうございます。</Say> <Say voice="alice" language="ja-JP">確認番号は</Say> <Say voice="alice" language="ja-JP">#{data['8']}</Say> <Say voice="alice" language="ja-JP">です。</Say> <Say voice="alice" language="ja-JP">確認番号は</Say> <Say voice="alice" language="ja-JP">#{data['8']}</Say> <Say voice="alice" language="ja-JP">です。</Say> </Response> |
#{data['8']}
は、「確認番号(サーバ保持用)」の参照です。
レスポンスで指定している TwiML の内容ですが、本来的には、固定の部分は録音を流し(<Play>
タグを使う)、動的に変わる部分にのみスピーチエンジンを使う (<Say>
タグを使う) のがお勧めだそうです。
電話番号を携帯電話番号に特化すれば、電話ではなく SMS で十分じゃないかという話もあります。申し込み者が SMS か電話か、どちらか選べれば格好いいのですかね。その改良については「もしかしたら」ということで。
今回は以上です。それではまた。
ピンバック: 申込フォームに入力チェックを加える – Questetra Support
ピンバック: ワークフローの途中で、SMS を送信する – Questetra Support