# データベースコネクターのベストプラクティス
バグを減らし、無駄な時間を削減することで、Workato でのワークフロー開発作業を容易にするベストプラクティスをまとめました。
大きく分けて以下の2つのパターンがあります。
# 適用可能なデータベース
このガイドは一般的に、SQL Server と Oracle を含む、すべてのデータベースコネクターに適用されます。
# レシピのデザインパターン
データベースコネクターを使用するレシピを作成する際は、以下のことに留意してください。
これらのガイドラインに従うと、データベースへの負荷を削減でき、Workato アセットを管理しやすくなります。
# データベースアクションを減らす
あらゆる Workato アクションは、データベースへの負荷を増大させることに留意してください。負荷を最小限に減らし、レシピをより持続可能なものにするために、以下のことを推奨します。
- Select または Update/Insert アクションの代わりに、 Upsert アクションを使用する
- Lists by Workato および Batch アクションを使用して、データを集計してからデータベースに送信する
- ストアドプロシージャまたはカスタム SQL 関数を使用して、Workato に送信する前にデータを変換する
# エラーハンドリングを実装する
エラーハンドリングは、レシピのデザインプロセスの重要な部分です。詳細については、こちらのガイドを参照してください。
# 複雑なワークフローを複数のレシピに分割する
あらゆることを一度に実現できるレシピを作成することは魅力的に思えるかもしれませんが、そのようなレシピはすぐに維持に苦労することになります。そのようなことにならないよう、ワークフローを複数のレシピに分割することをお勧めします。
ワークフローを複数のレシピに分割すると、以下のようなメリットがあります。
- レシピの保守性の向上。
- 問題のトラブルシューティングが容易。 エラーの発生元である、特定のレシピまたはステップまですばやく追跡できます。
- レシピステップの冗長性を削減。 レシピファンクションと API レシピを使用することで、レシピを別のレシピで再利用できます。
# バッチトリガー/アクションと単一行トリガー/アクション
レシピファンクションによって複雑なワークフローを分割できるため、バッチアクションまたは単一行アクションのどちらを使用するかという決定は、多くの場合、ビジネス要件やデザインの考慮事項に左右されます。バッチトリガー/アクションはサーバー上の負荷を軽減し、ジョブ実行時間を短縮できますが、バッチアクションが失敗するときは、バッチレベルで失敗するというトレードオフが生じます。
分析すると、適用可能なバッチトリガー/アクションを持つほとんどのワークフローは、以下の3つの方法で実行できます。
メソッド | 利点/欠点 | ビジネスユースケースの例 |
---|---|---|
バッチトリガーに続いてバッチアクションを使用する。単一行のアクションに対しては Workato のリピートステップを使用する。 | このメソッドは、すべてのメトリックにおいて最も効率的です。Workato は各ジョブの実行において段階的な (同期) プロセスを採用しているため、その実行を停止させるエラーが発生すると、バッチ全体として、後続のステップも実行されなくなります。最初のステップが成功した場合にのみ後続のアクションが実行されるのが適切な場合は、この動作が有用です。1つのレコードのみのエラーでもバッチ全体が停止してしまうため、効率と、失敗したジョブの実行中に行われるはずの多くのレコードの処理が停止してしまうこととのバランスを探る必要があります。1つの解決策は、バッチサイズを切り替えることです。 | データベースから新しいリードをバッチで取得して Salesforce にバッチ挿入する場合、営業チームの個々のメンバーに、Salesforce で新規作成されたリードへのリンクを直接メールで送信することにより、フォローアップすることができます。Salesforce へのバッチ挿入アクション時にエラーとなった場合、不明なリンクや空のリンクを含むメールが営業チームに送信されることはありません。ジョブを繰り返す前に、レシピに支障なく調整を加え、このエラーに対処することができます。 |
単一行のトリガーに続いて単一行のアクションを使用する | このメソッドを使用することは、すべてのメトリックにおいて最も非効率的で、特に大量のレコードを扱うトリガー/アクションではこれが顕著となります。Workato はジョブの実行において段階的な (同期の) プロセスを採用しているため、その実行を停止させるエラーが発生すると、後続のステップも実行されないことになります。レシピを以降のステップに進める前にレシピを修正したい場合、このメソッドが必要になることがあります。このメソッドは、バッチ全体ではなく、エラーが発生した部分についてのみジョブの実行が停止する点で、バッチトリガーバージョンとは異なります。すべての新規行をできるだけ速く処理することが必要な、時間的制約のあるビジネスユースケースでは、これが最適なデザインオプションとなる可能性があります。 | データベーステーブルに新しい行として入力される新規注文など、時間的制約のあるジョブの実行では、製品が時間どおりにお客様に提供されるようにするために、後続のアクションが非常に重要になる場合があります。1つのレコードの失敗により注文のバッチ全体が停止すると、収益の損失が発生する恐れがあります。このような場合、会社の業務の中断を最小限に抑えるには、単一行のトリガー/アクションが最善の選択肢であると言えます。考えられる代替手段としては、バッチアクションのバッチサイズを小さくすることが挙げられます。 |
バッチトリガーに続いて必要なすべてのバッチアクションを使用する。個別のレシピは1つまたは複数の単一行アクションとともに使用できる。 | このメソッドを使用すると、複数のレコードを同時に処理できます。これにより、エラーをレシピレベルで封じ込めることができ、エラーの影響をその後に続くステップのみにとどめることができます。ステップが互いに独立しており、1つのステップを開始する前に別のステップを完了させる必要がない場合は、これが最善の解決策になる可能性があります。このメソッドは、前述のようにデータ型とビジネスニーズに基づいてレシピを分離することでレシピの保守と効率を向上させることができる、より複雑なワークフローに最適です。 | テーブル内の新しいレコードが、新規顧客による製品の無料トライアルのサインアップを示しているユースケースがあるとします。これらをドリップキャンペーンにバッチ単位で追加するとともに、フォローアップのために詳細情報を営業チームに個別に送信したいと考えています。これらのケースは互いに独立しており、一方の効率を損なうことなく、もう一方のケースを達成できるため、このワークフローは別個のレシピとして実行することが可能であり、ジョブの実行が失敗した場合のビジネスに対する影響を最小限に抑えることができます。 |
# Update、Insert、Upsert アクションの使用
Update 、 Insert 、 Upsert アクションのいずれを選択するかによって、レシピとデータベーステーブルにさまざまな影響が及ぶ場合があります。Upsert は、Update または Insert を使用するほとんどのアクションの実行に使用できますが、これらのいずれかを選択する際の主な考慮事項をいくつか示します。
レシピ作成の際は、以下の点に留意してください。
- 単一の列でレコードが一意であると特定できるケースでは、Upsert がより優れたパフォーマンスを示します。 これにより、レコードを更新するのか、新規レコードを挿入するのかを決定するために検索を行う必要があったレシピで、必要なステップの数を減らすことができます。
- 重複した行が作成されない状況では、Upsert が役立つ。 ジョブが失敗して再実行されると、以前に挿入された行が重複する場合があります。 Upsert アクションを使用することで、この状況を回避できます。
- Update により、一意のキーでは対象にならない、複数行に対して更新することができます。 さまざまなパラメータを使用して更新する行を特定できます (
WHERE revenue >= 1000000
であるすべてのレコードを更新するなど)。 - Upsert では潜在的なバグや問題が見つからない場合がある。 たとえば、Salesforce で注文が変更されたときにトリガーしてデータベース内の注文のレコードを更新するレシピは、Upsert アクションには適していないかもしれません。注文のレコードはすでにシステム内に存在しているはずなので、更新するレコードがないことが検出され、ジョブが停止されてエラーレポートが生成されることになります。
# カスタム SQL およびストアドプロシージャの使用
Workato では、独自のカスタム SQL クエリーを以下の2つの方法で作成できます。
- ご使用のデータベースコネクターでサポートされている場合は、 [Select rows using custom SQL action] を使用する
- ご使用のデータベースコネクターでサポートされている場合は、 [Run custom SQL action] を使用する
これらのアクションを使用して、データベース上で広範なアクションを実行できます。独自のクエリーを作成すると、返される列が乱雑になる場合があるため、返される列に 意味のわかるエイリアス を付け、 必要な列のみを返す ことで、ステップの出力を管理するようにしてください。そうすることで、レシピは管理しやすく、他のユーザーにとっても読みやすいものとなります。
カスタム SQL を使用すると、レシピ内でデータベースを呼び出すアクションの数を減らすことができます。アクションの数が少ないと、Workato に最終結果を送信する前に、サーバー上でデータを直接結合し、変換できるため、サーバーの負担が減り、時間効率が向上します。SQL に慣れている場合は、Workato 上ではなく、カスタム SQL を使用して基本的なデータ変換を実行することを検討してください。カスタム SQL により、テーブルの作成、削除、変更など、はるかに幅広い操作を含む、データ定義言語 (DDL) を実行することもできます (コネクションに適切な権限がある場合)。
カスタム SQL に加えて、Workato ではデータベースで定義されているストアドプロシージャの実行もサポートしています。複雑なトランザクションや読み込みを実行するには、単なるクエリーでなく、ストアドプロシージャがより一般的に使用されます。このような場合、Workato は適切なタイミングでストアドプロシージャを実行するオーケストレーションツールとして機能します。ストアドプロシージャのもう1つの優れた機能は、入力パラメータによって利用できる汎用性ですが、レシピがデータベースで実行できる範囲も依然として制御可能です。
# データ処理のためのコレクションの使用
さまざまなソースからのデータの変換や集計など、カスタム SQL やストアドプロシージャが適していない場合は、基本的な変換にコレクションを使用することができます。コレクションは、SQL の使いやすいコマンドを介して、データクリーニング、データエンリッチメント、および集計に使用できます。コレクションは汎用性の高いツールで、データウェアハウスやデータレイクにデータを配置したり、他のアプリケーションにデータをエクスポートしたりする前の、最後のステップとして使用できます。
# データベースのデザインパターン
# Workato 用のテーブルのデザイン
New row および New/updated row トリガー を使用してトリガーを作成する場合、トリガー設定には以下のいずれかが必要です。
- 一意のキー (プライマリキー)
- 一意のキーと並べ替えられる列
これは、トリガーでレコードを見落とすことがないようにするために必要です。
トリガーテーブルを選択する際は、以下のガイドラインを使用してください。
# 一意のキー
- 一意のキーとして機能する、自動増分する一意の整数キーがテーブル内に存在しているはずです。ほとんどの場合、テーブルの
primary
キーは自動増分するよう設定されているため、これを使用することができます。 - そうでない場合、以下の2つのソリューションのうちのどちらかを実装できます。
- プロキシとして機能する既存のキー (自動増分する一意の整数キー) を見つける
- 自動増分する一意の整数キーを新規作成する
自動増分するキーを新規作成する方法
テーブル内で、他に
IDENTITY
列として宣言されている列がないことを確認します (もし宣言されている場合は、それを直接一意の整数キーとして使用できます)。以下のコマンドを入力して、新しい
IDENTITY
列を作成します。ここで、[your_table_name] と [column_name] は、それぞれテーブル名と新しい列名のプレースホルダです。ALTER TABLE [your_table_name] ADD [column_name] INT UNIQUE NOT NULL IDENTITY ;
これで、新しいキーを一意の列として使用できるはずです。
データベースに新しい
IDENTITY
列を作成すると、以前のすべてのレコードが埋め戻されます。最初のレシピの実行に注目してください。
# 列の並べ替え
- テーブル内の
updated_at
列は、並べ替え列として適切です。 - そうでない場合は、レコードが更新された時刻に基づいて並べ替え可能な任意の列を使用できます。
- 適切な列がない場合は、このために
updated_at
列を作成できます。 - データベーステーブル内のこの新しい
updated_at
列を、並べ替え列として使用できます。
並べ替えの基準となる
updated_at
列を作成する方法
- 以下のコマンドを入力して、
updated_at
列を作成します。ここで、[your_table_name] と [column_name] は、それぞれテーブル名と新しい列名のプレースホルダです。ALTER TABLE [your_table_name] add updated_at datetime2 CONSTRAINT DF_myTable_updated_at DEFAULT GETDATE()
- この後、この列をテーブルに追加して、レコードが変更されるたびにトリガーおよび更新するようにする必要があります。
CREATE TRIGGER trg_[your_table_name]_update ON [your_table_name] AFTER UPDATE AS UPDATE [your_table_name] SET updatedAt = CURRENT_TIMESTAMP FROM INSERTED i WHERE [your_table_name].ID = i.ID;
# データ検証
データ検証は、データベースのデザインにおける重要なステップであり、データをクリーンにするとともに Workato でジョブエラーが発生する可能性を減らします。ほとんどのデータベースでは、テーブルを作成および変更して、そのテーブルに入力されるデータに対する制約を含めることができます。データベースのデータがクリーンであるようにするには、以下のガイドを参照してください。
ご使用のデータベースに慣れていないか、このデータベースの ALTER
権限がない場合は、レシピでデータ検証を実行することもできます。Workato の formula を使用して、レシピでエラーをスローする可能性のある値を捕捉します。formula の詳細については、こちらを参照してください。
Last updated: 2023/8/31 1:07:14