- Notas de Versão
- Introdução
- Configuração e Instalação
- Projetos de automação
- Dependências
- Tipos de fluxos de trabalho
- Comparação de arquivos
- Melhores Práticas de Automação
- Integração de controle de origem
- Depuração
- A ferramenta de diagnóstico
- Analisador de Fluxo de Trabalho
- Sobre o Analisador de Fluxo de Trabalho
- STN MG-001 - Convenção de nomenclatura de variáveis
- STN MG-002 - Convenção de nomenclatura de argumentos
- STN MG-004 - Duplicação de Nome de Exibição
- STN MG-005 - Variável substitui variável
- STN MG-006 - Variável substitui argumento
- STN MG-008 - Comprimento de variável excedido
- STN MG-009 - Variáveis Catablema de prefixo
- STN MG-011 - Argumentos Catablema de prefixo
- STN MG-012 - Valores padrão de argumentos
- STN MG-016 - Comprimento do argumento excedido
- SR-DB-002 - Contagem alta de argumentos
- SR-DB-003 - Esvaziar bloco catechu
- SR-DB-007 - Múltiplas camadas Com fluxograma
- SR-DB-020 - Propriedades de saída indefinidas
- SR-DB-023 - Fluxo de trabalho vazio
- SR-DB-024 - Verificação da atividade Persistente
- SR-DB-025 - Pré-requisito de serialidade de variáveis
- SR-DB-026 - Uso da atividade Dela
- SR-DB-027 - Melhores práticas de persistência
- SR-DB-028 - Pré-requisito de serialidade de argumentos
- SR-US-005 - Argumentos de atividades embutidos em código
- SR-US-009 - Variáveis não utilizadas
- SR-US-010 - Dependências não utilizadas
- SR-US-014 - Restrições de pacotes
- SR-US-020 - Mensagens de logue mínimas
- SR-US-024 - Não utilizado e postergado
- SR-US-025 - Uso incorreto do valor salvo
- SR-US-026 - Restrições da atividade
- SR-US-027 - Pacotes necessários
- ST-USG-28 — restringir modelos de invocação de arquivos
- Variáveis
- Argumentos
- Namespaces Importados
- Gravação
- Elementos de Interface Gráfica
- Fluxo de controle
- Seletores
- Repo. de Objetos
- Extração de Dados
- Automação de imagem e texto
- Automação de Tecnologias Citrix
- Automação RDP
- Automação da Salesforce
- Automação SAP
- Automação do Varear Horizonte
- Geração de logs
- A ferramenta ScreenScrapeJavaSupport
- O protocolo Servodrive
- Test Suite — Studio
- Extensões
- Solução de problemas
- Sobre a solução de problemas
- Suporte e limitações do Microsoft Apo-V
- Solução de problemas do Internet Explorer x64
- Problemas do Microsoft Office
- Como identificar elementos de EU em PDF com opções de acessibilidade
- Reparando o suporte da Active Accessibility
- Solução de problemas de aplicativos do JxBrowser
- Monitoração de eventos de usuário
- Solução de problemas da Citrix
- Automação de aplicativos em execução com um usuário diferente do Windows
Sobre a publicação de projetos de automação
Publicar um projeto de automação quer dizer arquivar a pasta do projeto, de modo que ela possa ser enviada para os Robôs e, então, executada.
Por padrão, todos os arquivos na pasta do projeto são publicados, exceto para casos de teste. Se você quiser impedir um arquivo específico de ser incluído no pacote publicado, clique com o botão direito no painel Projeto, e selecione Ignorar da Publicação (não disponível para arquivos de fluxo de trabalho em projetos de biblioteca). No caso de bibliotecas, para impedir que um arquivo de fluxo de trabalho apareça como um componente reutilizável no painel Atividades quando a biblioteca publicada for instalada em um projeto, clique com o botão direito no painel Projeto, e selecione Tornar Privado.
Você pode publicar os projetos de automação no Orchestrator, um feed personalizado do NuGet ou localmente. Depois de publicar no Orchestrator, o projeto arquivado é exibido na página Pacotes e você pode criar um processo para ser distribuído para os Robôs. Ao publicar um processo de automação no Espaço de Trabalho Pessoal do Orchestrator ou publicar casos de teste, um processo é criado automaticamente caso ainda não exista um e os processos existentes são automaticamente atualizados para a versão mais recente publicada.
Além disso, os projetos de automação podem ser publicados em um feed personalizado do NuGet, com a opção de também adicionar uma chave de API se o feed requer autenticação.
%ProgramData%\UiPath\Packages
.
project.json
e design.json
na pasta do projeto não devem estar em um local somente de leitura (por exemplo, se o projeto estiver sob controle de origem, os arquivos devem estar marcados para edição).
Você pode publicar projetos do Studio ou da linha de comando. Para atualizar dependências para vários projetos e publicar todas elas de uma só vez, utilize a Ferramenta para atualização em massa de dependências do projeto.
Para publicar um projeto, selecione Publicar na faixa de opções da guia Design do Studio.
Para publicar um projeto de automação:
A caixa de diálogo Informações exibe:
- O nome sob o qual o pacote foi publicado.
- O número da versão sob o qual o pacote foi publicado;
- O local onde o projeto foi publicado se ele tiver sido publicado localmente ou no Padrão do Robô. Clique no caminho para acessar o pacote, exceto se o local de publicação for o Orchestrator.
- A opção Detalhes que expande uma lista com os nomes dos arquivos do projeto que foram publicados.
-
A opção Copiar para Área de Transferência.
Informações adicionadas durante a publicação, como o local de publicação persistem na janela, para que possa ser usado em publicações subsequentes para o mesmo tipo de projeto. Sempre que você clica em Publicar, uma nova versão do projeto é criada e enviada para o feed de pacotes. A publicação em um feed seguro pode ser autenticada por meio da Chave do Robô, credenciais do Orchestrator, autenticação do Windows ou chave de API.
.xaml
inicial no Studio, faça as alterações e publique o projeto novamente.
Você pode publicar projetos usando o comando de publicação UiPath.Studio.CommandLine.exe.
UiPath.Studio.CommandLine.exe está disponível na pasta de instalação:
- Para instalações por máquina, o caminho padrão é: C:\Program Files\UiPath\Studio\.
- Para instalações por usuário, o caminho padrão é %localappdata%\Programs\UiPath\Studio\.
Os argumentos a seguir estão disponíveis para o comando de publicação:
Argumento | Description |
---|---|
-p, --project-path | O caminho para o project.json a ser publicado. O argumento é obrigatório. |
-g, --target |
Onde publicar o projeto:
|
-f, --feed | O URL personalizado para publicar o projeto. Este também pode ser um diretório local personalizado, paracido com o caminho na guia opções de Publicação no Studio. |
-a, --api-key | A chave de API para publicar o projeto. Esse argumento pode ser usado em relação a um destino personalizado. |
-i, --icon | Caminho para o ícone personalizado para usar para o pacote. |
-n, --notes | As notas de versão que contêm alterações feitas no projeto. |
-v, --new-version | A nova versão do projeto. Se não ifnromada, a versão será automaticamente aumentada. |
-t, --timeout | Especifica o valor do tempo limite para publicar projetos. O tempo limite padrão é de 30 segundos. Essa configuração se aplica somente em relação à transferência do pacote para a duração do Orchestrator. |
--cer-path | Caminho local até o certificado para assinatura do pacote. |
--cer-password | A senha do certificado. |
--timestamper-url | A URL para o carimbador de data/hora. |
--incl-all-feeds | Não é necessário. |
--help | Exibe os argumentos disponíveis para cada comando. |
--version | Verifique a versão do UiPath.Studio.CommandLine.exe. |
Por exemplo:
-
O comando a seguir publica o processo de amostra no feed de processos do tenant do Orchestrator:
UiPath.Studio.CommandLine.exe publish --project-path "C:\Users\username\Documents\UiPath\Sample\project.json" --target OrchestratorTenant --notes "Alguns bugs corrigidos."
-
O seguinte comando publica o mesmo processo em uma pasta local:
UiPath.Studio.CommandLine.exe publish --project-path "C:\Users\username\Documents\UiPath\Sample\project.json" --target Custom --feed "C:\Users\username\Desktop\myfeed" --notes "Alguns bugs corrigidos."
Para obter mais informações sobre o utilitário CommandLine.exe, consulte Atualização em Massa de Parâmetros da Linha de Comando.