ステップ ​

レシピのステップとは、アクション、またはビジネスロジックの記述に役立つ制御フローステートメントのことです。

レシピエディターで利用可能なレシピの各種ステップ

アクションステップ ​

アクションは、作成、更新、検索などの操作をターゲットアプリで実行します。各アクションは一連の入力項目を必要とし、通常はデータ、つまり出力データツリーを返します。

例 : アクションステップ ​

以下のステップでは、Zendesk 統合で 組織の検索 アクションを実行します。左側の入力項目には、以下の条件に基づいて Zendesk 組織を検索する場合に利用可能な項目が表示されます。

• [Name]
• [Tags]
• [Notes]
• [Details]

以下のケースでは、名前に基づいて 組織の検索 アクションが実行されます。

Salesforce アカウント名で Zendesk 組織を検索。サンプルレシピ

組織の検索 アクションが実行されると、Zendesk は見つかった組織に関するデータを返します (ある場合)。出力データツリーには、後続のステップでマッピングに利用可能な項目が表示されます。

以下の場合、 組織の更新 アクションでは、組織の検索 アクションの ID 項目を使用して、更新する Zendesk 組織が特定されます (ID 項目がハイライトされます)。

ID で特定された Zendesk 組織の更新。サンプルレシピ

IF 条件ステップ ​

IF 条件ステップは、指定された条件が満たされた場合に1つまたは一連のアクションを実行するようレシピに指示します。たとえば、以下のスクリーンショットのレシピは、Zendesk 組織を作成するのか、それとも更新するのかを、条件付きステップに従って判断します。

条件の説明や例については、条件を参照してください。

例 : 条件付きのアクションステップ ​

以下のレシピでは、2つの条件付きステップが定義されています。

• Zendesk 組織が見つかった場合は、Zendesk 組織を更新します。
• Zendesk 組織が見つからない場合は、新しい Zendesk 組織を作成します。

条件付きステップに従って、Zendesk 組織を作成するのか、それとも更新するのかを判断するレシピ。サンプルレシピ

この例では、Zendesk 組織が見つかった場合、あるいはそうでない場合の、それぞれの条件付きステップに従ってすべてのジョブが処理されます。

リピートステップ ​

項目のリスト (請求書の品目のリストなど) に対する操作を行う場合、リスト内のすべての項目に対して一連のアクションを実行しなければならないことがあります。その場合には、リピートステップが便利です。リピートブロック内でインデントされたアクションは、リスト内のすべての項目に対して実行されます。

リストがリピートステップへの入力となります。リピートブロック内のアクションでは、 リピート ステップのデータツリーから出力されるデータを使用する必要があります。これにより、リスト内のすべての項目が確実に処理されます。

例 : リピートステップ ​

Salesforce アカウントを (バッチトリガーを使用して) 組織として Zendesk に同期させるシナリオのサンプルを参照してください。

リピートステップを使用して、Salesforce アカウントのリストを繰り返すレシピ。サンプルレシピ

この例では、トリガーは Salesforce アカウントのリストを返します。Zendesk はバッチアクションをサポートしていないため、Salesforce から Zendesk に各 Salesforce アカウントを1つずつ追加する必要があります。

リストのデータピルをリピートステップに渡す必要があります。インプットリスト項目を選択した場合は、以下に示すように、リスト型のデータピルのみをデータツリーで使用できます。リスト型のピルは、スタックアイコンで識別できます。

リストデータピルとリピートステップのインプットリスト項目のマッピング。サンプルレシピ

Foreach 出力データツリーからのデータピルは、アクションが繰り返されるときに各リスト項目の値が使用されるようマッピングする必要があります。たとえば、2つの Salesforce アカウントがトリガーで取得された場合、 Foreach データツリーのピルを使用することで、 組織の作成 アクションにより、最初のイテレーション時に最初の Salesforce アカウントのデータで Zendesk 組織が作成され、2回目のイテレーション時に2番目の Salesforce アカウントのデータで Zendesk 組織が作成されます。

リピートステップのデータツリーのデータピルの使用。これにより、繰り返されるリストの値が使用される。サンプルレシピ

以下は、 Foreach データツリーのマッピングを表示しています。

データピルは、リピートステップのデータツリーからマッピングされる。サンプルレシピ

さらに詳しいリピートステップのサンプルや、リスト処理の詳細については、リスト管理の説明を参照してください。

バッチ単位のリピート ​

上流のアプリやシステムがデータを送信する速度が、下流のアプリやシステムがデータを受信する速度よりも速い場合があります。このようなデータ移動の処理には、バッチサイズを設定して、バッチ単位のリピート機能を使用することができます。そうすれば、大きなデータセットが自動的に小さなバッチに分割されて転送されます。​

使用方法 ​

バッチ単位のリピート機能を使用するには、以下のステップを実行します。

1. レシピエディターの [What happens next?] コンテナーから、[Repeat action] ステップを選択します。

2. [Repeat action] ステップにインプットリストのデータピルを入力します。

3. [Repeat mode] を [Batch of items] に設定し、バッチ単位のリピート機能を呼び出します。(使用可能なオプションは、[One item at a time] と [Batch of items] の2つです。)詳細については、以下の図を参照してください。

4. [Batch size] 項目を設定します。バッチサイズが指定されていない場合、または指定された数値が1未満の場合には、デフォルトで100に設定されます。ここでは、バッチサイズとしてデータピルを入力することも可能です。

5. これまでの設定が、バッチイベントタグを含む For each ステートメントに反映されていることがわかります。

サンプルレシピを参照してください。

レシピファンクションの呼び出しのステップ ​

レシピファンクション - レシピファンクションの呼び出しのアクションでは、別のレシピをトリガーすることができます。 レシピファンクション と呼ばれる、こうしたタイプのレシピでは、レシピのロジックを素早く簡単に再利用できます。

詳細については、レシピファンクションのドキュメントを参照してください。

停止ステップ ​

停止ステップでは、1つのジョブが終了してそれ以上は処理されなくなります。通常は、ビジネスロジックにエラーがあって、それ以上ジョブを処理する必要がない場合に使用されます。

停止ステップは、ビジネスロジックに応じて、ジョブを失敗または成功としてマークするように設定できます。

例 : 停止ステップ ​

以下のレシピでは、すべての Salesforce アカウントが組織として Zendesk に存在することを想定しています。対応する Zendesk 組織が見つからない場合、レシピは以降のアクションの処理を停止します。

停止ステップを利用してメールを送信し、ジョブを終了するレシピ。サンプルレシピ

このレシピで実行されるすべてのジョブは、Zendesk 組織が見つかった場合、あるいはそうでない場合の、それぞれの条件付きステップに従って処理されます。見つからなかった場合、ジョブはステップ4で停止します。見つかった場合、ジョブは条件付きステップ (ステップ3および4) 内のアクションを実行せず、一致する Zendesk 組織を更新します。

このレシピは、このジョブが失敗したことにレシピのオーナーが気づいて再実行を試みるよう、ジョブをエラーとしてマークします。

停止ステップのエラーメッセージの設定。サンプルレシピ

エラー処理ステップ ​

このステップでは、プログラミング言語における try-catch と同様の概念に基づいたアクションによりエラーを監視できます。エラーが発生した場合は、以下のように対処できます。

1. ネットワークの問題などの一時的なエラーの場合は、一連のアクションを再試行します。

2. メールやアプリのエラーメッセージでユーザーにエラーを通知したり、ロールバック (作成したレコードや途中まで作成したレコードを削除してジョブを取り消すこと) を実行したりするなど、改善策を実施します。

このステップは、 監視 ブロックと エラー ブロックの2つのブロックで構成されます。エラーを監視するアクションは、 監視 ブロック内になければなりません。すべてのアクションが成功した場合、 エラー ブロックは無視されます。ただし、 監視 ブロック内のアクションでエラーが生じた場合は、 エラー ブロック内のアクションが実行されます。

例 : エラー監視ステップ ​

以下のレシピでは、Zendesk 組織が見つかったかどうかにかかわらず、検索ステップの直後に Zendesk 組織の更新を試みます。一致する Zendesk 組織が見つからない場合、 組織の更新 アクションは失敗します。

エラー監視により Zendesk 組織の更新の失敗を監視するレシピ。サンプルレシピ

レシピがエラー監視ブロック内の失敗したアクションを捕捉すると、失敗した 組織の更新 アクションも捕捉されます。自動再試行が設定されていないため、レシピは続行され、 エラー ブロック内のステップが直ちに実行されます。この場合、更新が失敗する理由は、一致する Zendesk 組織が見つからなかったことだけと思われます。そのため、改善ステップでは、新しい Zendesk 組織が作成されます。

自動再試行 ​

エラー監視ステップを使用する場合、 監視 ブロック内のアクションを、それらのアクションが失敗したときに Workato で自動再試行されるように設定できます。デフォルトでは、 監視 ブロックアクションは再実行されません。

エラーブロックはデフォルトで [Do not retry] が選択される

最大3回まで再試行できるほか、次の再試行までの時間間隔を選択することもできます。

再試行設定フィールド

また、 監視 ブロックを自動再試行するために満たす必要がある条件を定義することもできます。使用可能な条件の詳細については、IF 条件の説明を参照してください。

再試行条件項目の設定この例では、エラーメッセージに401エラーコードが含まれていない場合に限り、監視ブロックのアクションが再度実行されます。

例 : 再試行を伴うエラー監視ステップ ​

ネットワークの問題やタイムアウトの問題など、一時的な理由で 監視 ブロック内のアクションが失敗する傾向がある場合、自動再試行を使用して、レシピが成功するまでステップの再実行を試みるように (最大3回) するのは理にかなったことだといえます。

上記のエラー監視サンプルのレシピを再利用します。この場合、Zendesk 組織が見つかったかどうかにかかわらず、検索ステップの直後に Zendesk 組織の更新を試みます。一致する Zendesk 組織が見つからない場合、 組織の更新 アクションは失敗します。

Zendesk 組織の更新時に失敗したアクションを自動再試行するレシピ。サンプルレシピ

Zendesk 組織の更新に失敗した場合、レシピはエラーメッセージに401エラーコード (Unauthorized エラー) が含まれているかどうかを確認します。Unauthorized エラーメッセージを伴うエラーの場合、さらに再試行したとしても失敗します。このメッセージは、おそらくは権限が変更されたことが原因で、Zendesk 組織を更新するための適切な権限がないことを示しているためです。Unauthorized エラーメッセージを伴わないエラーの場合は、指定された時間が経過した後 (たとえば5秒後)、最大3回まで組織の更新アクションを再試行します。