Associações e recursos do runtime

Associações em aplicativos codificados, cobrindo como os recursos da UiPath são declarados em Bindings_v2.json e registrados pelo Studio Web no push.

Um aplicativo codificado raramente é independente — ele normalmente chama recursos do Orchestrator, como ativos, buckets de armazenamento, filas, conexões ou outros projetos de automação. O Studio Web usa um arquivo bindings_v2.json, enviado com a origem do seu aplicativo, para declarar, resolver e substituir essas referências no momento da implantação.

O que são associações

Uma associação é uma referência lógica de seu aplicativo codificado a um recurso da UiPath. Ele tem duas partes:

• Uma declaração dentro de bindings_v2.json, na raiz do que você envia por push. Cada entrada nomeia um recurso, seu tipo e um valor padrão.
• Uma resolução concreto para uma entidade do Orchestrator — pasta, ativo, bucket, fila, conexão ou processo — decidido no momento da implantação pela configuração do ambiente da solução.

Como as declarações em bindings_v2.json são estáveis, o mesmo aplicativo codificado pode ser implantado para desenvolvimento, preparação e produção sem alterações de código.

Declaração de associações em bindings_v2.json

Um arquivo bindings_v2.json na raiz do que você envia declara as associações. Ele segue um esquema versionado com uma matriz resources de nível superior; cada entrada descreve uma associação.

Exemplo:

{
  "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"
      }
    }
  ]
}

Campos por recurso

Campo	Finalidade
activityDisplayName	Rótulo legível por humanos mostrado no painel Recursos do Studio Web.
activityId	Identificador estável que o SDK usa para pesquisar a associação no runtime.
resource	Tipo de recurso: asset, bucket, queue, connection, process e assim por diante.
key	A chave ou o nome lógico do recurso dentro do app.
id	Um identificador composto usado pelo Studio Web para persistir e diferenciar associações entre push.
value.name.defaultValue	O nome da entidade do Orchestrator padrão para resolver antes que as substituições do ambiente sejam aplicadas.
value.name.isExpression	true se defaultValue for uma expressão a ser avaliada, false para um literal.
metadata.BindingsVersion	Versão do esquema por recurso.

Registrando associações por push

A cada uip codedapp push rele bindings_v2.json. O Studio Web carrega o arquivo do conteúdo enviado e registra cada entrada da matriz resources no painel Recursos do projeto. As associações existentes cujo id é inalterado mantêm seus mapeamentos de ambiente; novas entradas aparecem não mapeadas até que você as mapeie.

Se bindings_v2.json estiver ausente do que você enviar por push, o projeto não terá vinculações e o painel Recursos estará vazio.

Depois que o push é concluído, a visualização do projeto no Studio Web confirma a sincronização e lista cada tipo de recurso registrado:

Mapeamento de associações para recursos do Orchestrator

Para cada associação registrada, você (ou a configuração do ambiente da solução) seleciona um recurso do Orchestrator correspondente — por exemplo, mapear uma associação Get Asset para um ativo de credencial específico em uma pasta escolhida.

O mapeamento é armazenado como parte da configuração do ambiente da solução, não dentro da origem enviada. É assim que um único pacote de aplicativos codificado é promovido com segurança pelo desenvolvimento, teste e produção — cada ambiente fornece suas próprias resoluções.

Para o gerenciamento de ambientes, consulte Sobre soluções.

Melhores práticas

• Um activityDisplayName deve revelar a intenção (Get Payment API Key, não Get Asset) — ele aparece no painel Recursos e em cada mapeamento de ambiente.
• Um activityId deve permanecer estável entre os pushes. O Studio Web depende dele (combinado com id) para diferenciar e reter mapeamentos de ambiente entre push.
• Um bindings_v2.json mínimo é mais fácil de manter: cada entrada torna-se um requisito de resolução em cada ambiente no qual o aplicativo é implantado.
• bindings_v2.json é um código-fonte e deve estar no Git junto com o restante do aplicativo.