コネクターのデバッグ ​

コネクターのアクションを定義することは重要ですが、他のソフトウェアプロジェクトと同様に、コネクターのデバッグは工程の重要な部分です。 これを支援するために、Connector SDKには2つのオプションがあり、それぞれに独自の利点があります。

状況によっては、両方のツールが必要になる場合があります。 ただし、よりシンプルなビルドでは、Test codeタブで十分であり、このガイドではこれに焦点を当てます。 SDK CLIの詳細については、CLIリファレンスを参照してください。

Test codeタブ ​

コードのテストは、新しいコネクターを構築するうえで不可欠な手順です。 APIコネクションを確立した後や、アクションおよびトリガーを変更するときなど、コネクターのさまざまなコンポーネントを構築する際は頻繁にテストすることをお勧めします。

Test codeタブを見つけるには、Tools > Connector SDKに移動し、使用するコネクターを選択して、Source code > Test codeをクリックします。

コネクターのコードを変更すると、Test codeタブが最新のコード変更のデバッグを支援します。 常に最新バージョンを基に作業できるように、作業内容は自動的に保存されます。

コネクションのデバッグ ​

すべてのコネクタービルドは、APIへのコネクションの構築とデバッグから始まります。 コネクションが正常に確立されるまで、アクションとトリガーは使用できません。 コネクションを確立するには、Test codeタブの下にあるConnectionタブに移動し、Auth typeを選択して必要なフィールドに入力し、Connectをクリックします。

Test codeタブでは、Recent testsタブにコネクション試行のログが表示されます。 ログには、入力パラメーター、出力、および結果として発生したエラーメッセージやHTTPリクエストが含まれます。

Auth typeとしてPersonal access tokenを使用するAPIコネクション

コネクションフィールドのデバッグ ​

コネクションハッシュのfields属性で定義されたフィールドは、保存時に表示されます。

ログには次のタブが含まれます。 ​

Input - このタブには、入力フィールドからコネクションに渡された入力がJSON形式で表示されます。

Output - このタブには、コネクション出力のJSON表現が表示されます。これは、connection、execute、object_definitionsなど、コネクター内のさまざまなlambda関数で使用されます。

Error - このタブは、コネクターでエラーが発生した場合にのみ表示されます。 エラーは、メソッドを使用してエラーを発生させた場合、またはAPIリクエストが非2XXレスポンスコードで応答した場合に発生します。 手動でエラーを発生させる方法の詳細を確認してください。

Debug - このタブには、認証フロー中に行われたHTTPリクエストが表示されます。 HTTPリクエストは、実行された順に出力されます。

前の画像では、デバッグトレースはtestブロック内で送信された次のリクエストから生成されています。

test: lambda do |_connection|
    get('/users/me')&.
      after_error_response(/.*/) do |_code, body, _header, message|
        error("#{message}: #{body}")
      end
  end,

Console - このタブには、アクションとトリガーのテスト中に実行されたputsメソッドに関する情報が含まれます。 putsメソッドは、特定の変数を出力するようコンソールに指示します。 これらのputsは、pick_lists、object_definitions、methodsのコードからも出力できます。 これは、コードから変数を出力してデバッグする場合に役立ちます。 コンソールログは、実行された順に出力されます。 putsを使用して複数の変数を出力した結果

トリガーとアクションのデバッグ ​

トリガーとアクションのデバッグでは、主に次の2つの部分をデバッグできます。

1. レシピエディターで使用している場合と同様のオペレーションのUI
2. オペレーションの実際の実行

オペレーションのUIについては、アクションまたはトリガーをクリックすると、レシピエディターにスタブが表示されます。 これにより、アクションとトリガーで定義した関連する入力フィールドと出力データピルをすべて確認できます。

このビューでは、Test codeタブのUIで指定された入力を変更すると、動的な入力または出力フィールドを確認できます。 必要に応じて、Raw JSONビューに切り替えて、アクションの入力JSONを直接指定することもできます。 これは、レシピ自体からの入力があるアクションまたはトリガーをデバッグする場合に役立ちます。 UIポップアップの右上隅にあるChange viewで、Raw JSONビューに切り替えることができます。

完了したら、Testをクリックしてオペレーションを実行します。 ポーリングトリガーの場合、トリガーの最初のポーリングをシミュレートするためにpollブロックが実行されます。 アクションの場合、executeブロックがシミュレートされます。 コードが実行されると、Test codeタブのRecent testsタブにテストのログが表示されます。

Output - トリガーとアクションの出力には、いくつかのわずかな違いがあります。

• アクション: これは通常の出力で、ジョブの出力として自然に渡されます。 さらに、定義した各データピルのname値と照合されるため、ユーザーはデータピルを後続のアクションにマッピングできます。
• トリガー: トリガーに関する重要な違いは、1回のトリガーポーリングで複数のジョブが生成される可能性があることです。 これに馴染みがない場合は、ポーリングトリガーに関するガイドをお読みください。 そのため、トリガーテストの出力では、個々のジョブに変換されるレコードの配列と同義であるeventsやstaged_eventsなど、いくつかの項目が強調表示されます。 配列内の各インデックスは、1つのジョブに対応します。 それ以外にも、can_poll_moreの結果や、ポーリングの次の反復に渡されるclosureも確認できます。

制限事項 ​

Picklists、methods、object_definitions ​

個々のpick_lists、methods、object_definitionsのテストは、Test codeタブではサポートされていません。 ただし、簡単な回避策として、目的のアクション/トリガーで使用する前にこれらのpick_listsをテストできるサンプルテストアクションを作成できます。

例:

actions: {
    test: {
      execute: lambda do |connection, input|
        # Print the output of the sample method to see if it works as intended
        puts call(:sample_method)
      end
    },
}

Formulaモードとプリミティブ型の配列 ​

Formulaモードは現在UIポップアップで機能せず、この機能は無効になっています。 ただし、場合によっては、プリミティブ型の配列など、デフォルトでFormulaモードを使用するフィールドが表示されることがあります。 例

input_fields: lambda do
    [
        {
            name: "customer_ids",
            label: "Array of customer IDs",
            type: "array",
            of: "string"
        }
    ]
end

このような場合は、Test codeタブのRaw JSONビューを使用して、入力を手動で指定する必要があります。