Database Connectorのベストプラクティス ​

Workatoでワークフローを開発する際に、バグや無駄な時間を減らして作業を容易にするベストプラクティスをいくつかまとめました。

これらを次の2つの包括的なパターンに分けました:

• レシピ設計パターン
• データベース設計パターン

適用対象データベース ​

このガイドは、SQL ServerやOracleを含む、すべてのデータベースコネクターに一般的に適用できます。

レシピ設計パターン ​

データベースコネクターを使用するレシピを構築するときは、次の点に注意することをお勧めします:

• データベースアクションを削減する
• エラー処理を実装する
• ワークフローを個別のレシピに分割する

これらのガイドラインに従うと、データベースの負荷を軽減し、Workatoアセットを管理しやすくなります。

データベースアクションの削減 ​

すべてのWorkatoアクションは、データベースに追加の負荷を生じさせる可能性があることに注意してください。 負荷を最小限に抑え、レシピをより持続可能にするために、次をお勧めします:

• SelectまたはUpdate/Insertの代わりにUpsertアクションを使用する
• Batchアクションを使用してデータを集約し、データベースに送信する
• ストアドプロシージャまたはカスタムSQL関数を使用して、Workatoに送信する前にデータを変換する

エラー処理の実装 ​

エラー処理は、レシピ設計プロセスの重要な部分です。 詳細については、このガイドを確認してください。

複雑なワークフローを個別のレシピに分割する ​

すべてを実行する単一のレシピを作成したくなるかもしれませんが、このようなレシピはすぐに保守が困難になります。 このような状況を避けるため、ワークフローを複数のレシピに分割することをお勧めします。

ワークフローを複数のレシピに分割すると、次のことが可能になります:

• レシピの保守性の向上
• 問題のトラブルシューティングを容易にすることで、エラーを特定のレシピまたはステップまですばやく追跡できます。
• レシピステップの冗長性を削減します。 レシピ関数とAPIレシピを使用すると、別のレシピでレシピを再利用できます。

バッチトリガーおよびアクションと単一行トリガーおよびアクションの比較 ​

レシピ関数で複雑なワークフローを分解できるため、バッチアクションを使用するか単一行アクションを使用するかの判断は、多くの場合、ビジネス要件と設計上の考慮事項によって決まります。 バッチトリガー/アクションはサーバーの負荷を軽減し、ジョブの所要時間を短縮できますが、失敗したバッチアクションはバッチレベルで失敗するというトレードオフがあります。

適用可能なバッチトリガー/アクションを使用するほとんどのワークフローは、検討すると次の3つの方法で実現できます:

Update、Insert、およびUpsertアクションの使用 ​

Update、Insert、Upsertアクションの選択は、レシピやデータベーステーブルに多くの影響を与える可能性があります。 Upsertは、UpdateまたはInsertが使用されるほとんどのアクションを実現するために使用できますが、どちらを選択するかを決める際には、次の重要な考慮事項に注意してください。

構築時には、次の点に注意してください:

• Upsertは、単一の列に基づいてレコードを一意にする必要がある特定のケースでより高いパフォーマンスを発揮します。 これにより、レコードを更新するか新しいレコードを挿入するかを判断するために検索を実行する必要があったレシピで、必要なステップ数が削減されます。
• Upsertは、重複行が作成されない状況で有用です。ジョブが失敗して再実行された場合、以前に挿入された行が重複行になる可能性があります。 Upsertアクションを使用すると、これを防止できます。
• Updateでは、一意キーではすべてを特定できない可能性がある行を更新できます。更新する行は、パラメーターの範囲を使用して特定されます。例: すべてのレコードを更新するWHERE revenue >= 1000000
• Upsertは潜在的なバグや問題を隠す可能性があります。 たとえば、Salesforceで注文が変更されたときにトリガーされ、データベース内の注文レコードを更新するレシピには、Upsertアクションが適さない場合があります。 注文のレコードはすでにシステム内に存在しているはずなので、更新対象が存在しない場合は、そのことを記録し、代わりにレポートエラーでジョブを停止する必要があります。

カスタムSQLとストアドプロシージャの使用 ​

Workatoでは、次の2つの方法で独自のカスタムSQLクエリを記述できます:

1. データベースコネクターでサポートされている場合、カスタムSQLを使用して行を選択アクションを使用する
2. データベースコネクターでサポートされている場合、カスタムSQLを実行アクションを使用する

これらのアクションを使用して、データベースに対して幅広いアクションを実行できます。 独自のクエリを記述すると、返される列に関して整理が難しくなる場合があるため、返される列に意味のあるエイリアスを付け、必要な列のみを返すことでステップ出力を管理してください。 これにより、レシピの保守が容易になり、他のユーザーにとっても読みやすくなります。

カスタムSQLを使用すると、レシピ内でデータベースを呼び出すアクションの数を減らすことができます。 アクションが少ないほどサーバーの負荷が低くなり、最終結果をWorkatoに送信する前にサーバー上で直接データを結合および変換できるため、時間効率が向上します。 SQLに慣れている場合は、Workato上で行うのではなく、カスタムSQLを使用して基本的なデータ変換を実行することを検討してください。 カスタムSQLでは、Data Definition Language（DDL）も実行でき、テーブルの作成、削除、変更など、はるかに広範な操作を行えます（コネクションに適切な権限がある場合）。

カスタムSQLに加えて、Workatoではデータベースで定義されたストアドプロシージャの実行もサポートしています。 ストアドプロシージャは単なるクエリ以上のもので、複雑なトランザクションやロードの実行により一般的に使用されます。 このような場合、Workatoはストアドプロシージャを適切なタイミングで実行するオーケストレーションツールとして機能します。 ストアドプロシージャのもう1つの優れた機能は、入力パラメーターによって柔軟性を得ながら、レシピがデータベースで実行できる範囲を制御できることです。

データ処理でのコレクションの使用 ​

さまざまなソースからのデータの変換や集約など、カスタムSQLやストアドプロシージャが適さない場合、Workatoは基本的な変換にコレクションを使用する機能を提供します。 コレクションは、SQLの使いやすいコマンドを通じて、データクレンジング、データエンリッチメント、および集約に使用できます。 コレクションは、データウェアハウス、データレイクにデータを配置する前、または他のアプリケーションにエクスポートする前の最終ステップとして使用できる多用途なツールです。

データベース設計パターン ​

• Workatoで使用するテーブルの設計
• データ検証

Workatoで使用するテーブルの設計 ​

New rowおよびNew/updated row triggersを使用してトリガーを作成する場合、トリガー設定には次のいずれかが必要です:

• 一意キー（主キー）、または
• 一意キーとソート済み列

これは、トリガーがレコードを見逃さないようにするために必要です。

トリガーテーブルを選択するときは、次のガイドラインに従ってください:

• 一意キー
• ソート列

一意キー ​

1. 一意キーとして機能できる、自動インクリメントされる一意の整数キーがテーブルに存在している必要があります。 ほとんどの場合、テーブルのprimaryキーが自動インクリメントに設定されていれば、これを使用できます。
2. そうでない場合は、次の2つの解決策のいずれかを実装できます
   • 整数で、一意で、自動インクリメントされるプロキシとして機能できる既存のキーを見つける
   • 自動インクリメントされる新しい一意の整数キーを作成する

自動インクリメントされる新しいキーを作成する方法

1. テーブル内の他の列がIDENTITY列として宣言されていないことを確認してください。 （これがすでに行われている場合は、その列を一意の整数キーとして直接使用できます

2. 次のコマンドを入力して新しいIDENTITY列を作成します。[your_table_name]と[column_name]はそれぞれ、テーブル名と新しい列名のプレースホルダーです

ALTER TABLE [your_table_name]
  ADD [column_name] INT UNIQUE NOT NULL IDENTITY ;
  

3. この後、新しいキーを一意列として使用できるようになります。

4. データベースに新しいIDENTITY列を作成すると、以前のすべてのレコードに値がバックフィルされます。 初回のレシピ実行に注意してください。

ソート列 ​

1. テーブル内のupdated_at列は、ソート列として適しているはずです。
2. それがない場合は、レコードが更新された時刻に基づいてソートできる任意の列を使用できます。
3. 適した列がない場合は、この目的を満たすためにupdated_at列を作成できます。
4. データベーステーブル内のこの新しいupdated_at列を、ソート列として使用できるようになります

ソートに使用するupdated_at列を作成する方法

1. 次のコマンドを入力してupdated_at列を作成します。[your_table_name]と[column_name]はそれぞれ、テーブル名と新しい列名のプレースホルダーです

ALTER TABLE [your_table_name]
add updated_at datetime2
CONSTRAINT DF_myTable_updated_at DEFAULT GETDATE()

2. この後、レコードが変更されるたびにトリガーして更新するために、この列を追加する必要があります

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でのジョブエラーの可能性も低減します。 ほとんどのデータベースでは、テーブルを作成および変更して、流入するデータに制約を含めることができます。 データベース内のデータのクリーンさを確保するには、次のガイドを参照してください:

• Oracle
• SQL Server

データベースでALTER権限がない場合や、データベースに詳しくない場合は、データ検証をレシピ内で行うこともできます。 WorkatoのFormulaレシピを使用して、レシピでエラーをスローする可能性がある値を検出します。 詳細については、Formulaを参照してください。