外部公開用のAPIとして定義した際に少し詰まったので、どんな挙動になるのかを書いておきます。

設定するとレスポンスが返せる

画像のようにreturn data from APIを設定すると、呼び出しもとにレスポンスを返せるようになります。
外部公開用のAPIであれば基本はJSONを返すのが一般的なので、画像のように何かしらのkeyとvalueを設定して返します。
よくあるケースだと、ステータスコードとかエラーメッセージとかですね。

このケースの場合、下記のような形式でデータが返ってきます。

$ curl -X POST "https://*****/version-test/api/1.1/wf/api_test"
{
    "status": "success",
    "response": {
        "key1": "val1",
        "key2": "val2"
    }
}%

自動で処理は終わらない

return data from APIという名前的に、この時点で処置が終わりレスポンスが返されるのかと思っていました。
これはいわゆる早期リターンというやつです。

しかし、これ以降の処理も実行されていました。実際には return をする処理ではなく、returnをするレスポンスの形式をセットする(決める)処理というのが正しいようです。
(最後まで処理は実行されるので注意)

対策

Terminate this workflowを実行すると、そこで処理を終了させることができます。

処理の大枠としては下記のようなことをすることが多いのですが、

1. バリデーション(リクエスト内容などにエラーがないか確認)

2. エラーがあればエラー用のレスポンスを返す

3. エラーがなければ実行したい処理を行う

4. 成功のレスポンスを返す

2の処理でreturn data from APIを実行した後に、Terminate this workflowを実行するということで対応ができます。

後から設定した内容で上書きされる

複数回return data from APIを実行した場合どうなるでしょうか。レスポンスの形式をセットする処理なので、最後に設定したものが使用されるのかと思っていました。

先ほどの処理の後に、key3だけを指定した処理を入れています。

そうすると2つの処理の値がマージされた状態で返されました。

$ curl -X POST "https://*****/version-test/api/1.1/wf/api_test"
{
    "status": "success",
    "response": {
        "key1": "val1",
        "key2": "val2",
        "key3": "val3"
    }
}

他にも試してみたのですが、keyがかぶっている場合には後から設定した方が使用されました。
裏ではレスポンス形式の配列を持っていて、それをまるっと更新するのではなく、マージする処理になってそうですね。

個人的にはこの挙動はわかりにくいかなと思うので、Terminate this workflowで処理を終わらせてレスポンスする方が良いかなと思いました。

まとめ

• return data from APIは後続の処理も実行される

• 複数設定した場合には後続の処理で設定したkeyで上書きされる

  • keyが重複してない場合には、前の処理のkeyは残る

• Terminate this workflowを使うことで後続の処理を実行させずに、レスポンスすることが可能

#bubble #bubble入門 #bubble初心者 #ノーコード #ノーコードツール #ノーコードアプリ