バインドとランタイム リソース

コード化されたアプリ内のバインド。UiPath リソースが bindings_v2.json で宣言され、Studio Web によってプッシュで登録される方法について説明します。

コード化されたアプリが自己完結型であることはめったにありません。通常は、アセット、ストレージ バケット、キュー、コネクション、その他のオートメーション プロジェクトなどの Orchestrator リソースを呼び出します。Studio Web は、アプリのソースに同梱されている bindings_v2.json ファイルを使用して、デプロイ時にこれらの参照を宣言、解決、上書きします。

バインディングとは

バインドとは、コード化されたアプリから UiPath リソースへの論理参照です。次の 2 つの部分があります。

• プッシュする内容のルートにある bindings_v2.json内の宣言。各エントリには、リソース、その種類、および既定値の名前が付けられます。
• Orchestrator のエンティティ (フォルダー、アセット、バケット、キュー、コネクション、またはプロセス) に対する具体的な解決策は、デプロイ時にソリューションの環境設定によって決定されます。

bindings_v2.json の宣言は安定しているため、コードを変更することなく、同じコード化されたアプリを開発、ステージング、運用環境にデプロイできます。

でのバインディングの宣言 bindings_v2.json

プッシュするもののルートにある bindings_v2.json ファイルによってバインドが宣言されます。これは、最上位の resources 配列を持つバージョン管理されたスキーマに従います。各エントリには 1 つのバインドが記述されています。

例：

{
  "version": "2.0",
  "resources": [
    {
      "activityDisplayName": "Get Asset",
      "activityId": "GetRobotAsset_1",
      "resource": "asset",
      "key": "Asset",
      "id": "assetAssetAssetFalse",
      "value": {
        "name": {
          "defaultValue": "Asset",
          "isExpression": false
        }
      },
      "metadata": {
        "BindingsVersion": "2.2"
      }
    },
    {
      "activityDisplayName": "Invoke Process",
      "activityId": "InvokeProcess_1",
      "resource": "process",
      "key": "Arghya-Queue-Query",
      "id": "processArghya-Queue-QueryArghya-Queue-QueryFalse",
      "value": {
        "name": {
          "defaultValue": "Arghya-Queue-Query",
          "isExpression": false,
          "displayName": "Process name"
        }
      },
      "metadata": {
        "BindingsVersion": "2.2"
      }
    },
    {
      "activityDisplayName": "Add Queue Item",
      "activityId": "AddQueueItem_1",
      "resource": "queue",
      "key": "Arghya_query_queue",
      "id": "queueArghya_query_queueArghya_query_queueFalse",
      "value": {
        "name": {
          "defaultValue": "Arghya_query_queue",
          "isExpression": false
        }
      },
      "metadata": {
        "BindingsVersion": "2.2"
      }
    }
  ]
}

リソースごとのフィールド

フィールド	目的
activityDisplayName	Studio Web の [ リソース] パネルに表示される人間が判読できるラベル。
activityId	SDK が実行時にバインドを調べるために使用する安定した識別子です。
resource	リソースの種類: asset、 bucket、 queue、 connection、 processなど。
key	アプリ内のリソースのキーまたは論理名。
id	Studio Web がプッシュ間でバインドを保持および差分するために使用する構成された識別子。
value.name.defaultValue	環境のオーバーライドを適用する前に解決先となる既定の Orchestrator エンティティ名です。
value.name.isExpression	true defaultValue が評価する式である場合は、 リテラルをfalseします。
metadata.BindingsVersion	リソースごとのスキーマのバージョン。

プッシュ時のバインドの登録

uip codedapp pushごとに bindings_v2.jsonが再読み取られます。Studio Web はプッシュされたコンテンツからファイルを読み込み、プロジェクトの [リソース] パネル下のresources配列の各エントリを登録します。idが変更されていない既存のバインディングでは、環境マッピングが保持されます。新しいエントリは、マップするまでマップされません。

プッシュした内容に bindings_v2.json がない場合、プロジェクトにはバインドがなく、[ リソース] パネルは空になります。

プッシュが完了すると、Studio Web のプロジェクト ビューで同期が確認され、登録されている各リソースの種類が一覧表示されます。

Orchestrator リソースへのバインドのマッピング

登録済みの各バインドに対して、(またはソリューションの環境設定で) 一致する Orchestrator リソースを選択します (たとえば、選択したフォルダー内の特定の資格情報アセットに Get Asset バインドをマッピングするなど)。

マッピングは、プッシュされたソース内ではなく、ソリューションの環境設定の一部として保存されます。これにより、1 つのコード化されたアプリ パッケージを開発、ステージング、運用に安全に昇格できます。各環境で独自の解決策が提供されます。

環境の管理については、「 ソリューションについて」をご覧ください。

ベスト プラクティス

• activityDisplayNameは意図を明らかにするものである必要があります (Get AssetではなくGet Payment API Key)、[リソース] パネルおよびすべての環境マッピングに表示されます。
• activityIdは、プッシュ間で安定した状態を維持する必要があります。Studio Web は、プッシュ間で環境マッピングを差分および保持するために、 idと組み合わせて使用します。
• 最小限の bindings_v2.json は保守が容易です。つまり、すべてのエントリが、アプリがデプロイされるすべての環境で解決要件になります。
• bindings_v2.json はソース コードであり、アプリの他の部分と一緒に Git に存在する必要があります。