Embedded Environments FAQ ​

デプロイメントタブには、Embedded Partner（EP）および権限を持つコラボレーターがアクセスできます。 詳細については、Embedded Environmentsのロールを参照してください。

各Environmentへのアクセスは、コラボレーターごとに定義できます。 Environmentごとに異なるロールを割り当てることができます。 詳細については、Embedded Environmentsのロールを参照してください。

デプロイメントを実行するには、ユーザーが元のEnvironmentとターゲットEnvironmentの両方でデプロイメント権限を持っている必要があります。 詳細については、Embedded Environmentsのロールを参照してください。

いいえ。 コラボレーターがデプロイメントタブを表示するには、少なくとも2つのEnvironmentへのアクセス権と、両方のEnvironmentでのデプロイメント権限が必要です。

コラボレーターが2つのEnvironmentでデプロイメントアクセス権を持っている場合、ターゲットとして選択できるEnvironmentは1つのみです。 コラボレーターがデプロイメント権限を持たないEnvironmentにログインしている場合、そのコラボレーターはデプロイメントタブにアクセスできません。

コネクターは現在のEnvironmentでのみ使用できるようになります。 デプロイされない限り、他のEnvironmentには表示されません。

SDKコネクターがデプロイメントパッケージに含める対象として選択されている場合、そのコネクターは、更新またはソースコードの変更とともに、プロダクションまたはテストEnvironmentに正常に含められます。 各Environmentには個別のコネクターIDがあり、別々のインスタンスであることを示します。 SDKコネクターは、使用可能な各Environmentのツール> Connector SDKの下に表示されます。

共有リンクを通じて顧客のDevelopmentワークスペースにSDKコネクターをインストールすると、Developmentでプライベートコネクターとして使用できるようになります。 コネクターがない場合、パッケージのインポートは失敗します。 インストール後、コネクターは他のEnvironmentには最初は存在しません。

プライベートリンクでインストールすると、コネクターは現在のEnvironmentで使用できるようになります。 コネクターがない場合、それを使用するパッケージのインポートは失敗します。 インストール後、コネクターは他のEnvironmentには最初は存在しません。

Developmentでバージョンを変更しても、プロダクションのバージョンには影響しません。 ただし、Developmentからプロダクションに新しいバージョンをデプロイすると、同じIDを維持したまま、プロダクションのコネクターが更新されます。

コネクターはDevelopment、テスト、プロダクション間で独立して動作します。 デプロイメントにより、更新を含むコネクターが転送され、一貫性が維持されます。 さらに、コネクターの共有にプライベートリンクを使用した場合の動作は、RLCMインポートで確認される動作と一致します。

ルックアップ テーブルは、テーブルスコープ（グローバルまたはプロジェクト）に関係なく、デプロイメントパッケージに含まれます。 ルックアップ テーブルのコンテンツは、このデータを含めることを選択した場合にのみデプロイメントに含まれます。

Workato UIのプロビジョニングボタンを使用すると、データを失うことなく顧客を移行できます。 この方法では、特定の顧客にEnvironmentsが割り当てられます。 レシピは通常どおり実行され続けます。 最初は既存のワークスペースがDevelopment Environmentになり、必要に応じて手動でプロダクションに移動する必要があります。

Development、テスト、プロダクションEnvironmentを備えたEnvironments機能を導入しても、コネクションベースの料金には影響しません。 コネクションは、1つまたは3つすべてのEnvironmentで認証されているかどうかに関係なく、1回だけカウントされます。 これにより、各コネクションを1回だけカウントすることで、公正な料金体系が維持されます。 これは、わかりやすく公平な請求慣行に対する当社の取り組みに沿っています。

はい。 Environments機能はFully Embeddedセットアップと完全に互換性があります。 内部的には、各Environmentは異なるmanaged_user_idに対応しています。 ナビゲーションバーが非表示になるFully Embedded構成では、3つの異なるJWTを生成する必要があります。 さらに、Environmentごとに異なるオリジンURLを指定できます。 これにより、Development、テスト、プロダクションの各ステージに合わせて統合を調整できます。

各Environmentには一意のmanaged_user_idが関連付けられています。 特定のEnvironment（Development、テスト、またはプロダクション）のEmbedded APIsを操作するには、APIエンドポイントで適切なmanaged_user_idを使用する必要があります。 たとえば、.../managed_user/:managed_user_id_dev/または.../managed_user/:managed_user_id_prod/などのエンドポイントを使用して、対応するEnvironmentのデータと設定にアクセスできます。

はい。 Connection WidgetはEnvironments機能と互換性があります。 ウィジェットを選択してコネクションを認証する際は、使用する予定のEnvironment（Development、テスト、またはプロダクション）に対応する正しいIDとconnection_idを指定する必要があります。

Environments機能はCustomerワークスペースでのみ有効です。 Adminワークスペースはまだこの機能をサポートしていませんが、ベストプラクティスとしてBuildワークスペースとLiveワークスペースを区別することをお勧めします。

はい。 混在アプローチを使用できます。 各CustomerワークスペースにEnvironmentsをプロビジョニングするかどうかを決定できます。 ワークスペースをプロビジョニングした後は、Environments機能を無効にすることはできません。 ただし、Role-Based Access Control（RBAC）を使用して可視性を制限し、必要に応じてコラボレーターが特定のEnvironmentにのみアクセスできるようにすることができます。

いいえ。 システムは、Development、テスト、プロダクションEnvironmentを使用するよう標準化されています。 Environmentの数を増やすことはできません。

いいえ。 Environment名はDevelopment、テスト、プロダクションです。 これらの名前は変更できません。

いいえ。 Environmentの数を減らすことはできません。 ただし、Role-Based Access Control（RBAC）設定を調整して、コラボレーターのアクセスをDevelopmentやプロダクションなど特定のEnvironmentのみに制限できます。 これにより、運用設定をカスタマイズし、Environmentの数を機能的に制限できます。

共有コネクターの同じ公開済みバージョンが、すべてのEnvironment（Development、テスト、プロダクション）で使用されます。

詳細なRole-Based Access Control（RBAC）は、Embedded Admin Consoleで使用できます。 割り当てたロールは、デフォルトで、すべての顧客ワークスペースおよび3つすべてのEnvironment（Development、テスト、プロダクション）にわたって、このカスタマーマネージャーに適用されます。

Environmentごとに異なるロールまたはアクセスを提供する予定がある場合は、コラボレーターをCustomerワークスペースごとに個別に追加し（Customer Managerとしてではなく）、Environmentごとにコラボレーターロールを指定する必要があります。 これらのロールは、ユーザーインターフェイスまたはWorkato APIを通じて割り当てることができます。