FAQ¶

Esse tipo de problema é mais comum em casos onde existem bloqueios no ambiente da empresa onde as ferramentas estão sendo utilizadas. Entre os comportamentos observados, estão:

• Instalação através do Wizard travada em 0%.
• Erro ao iniciar o Runner
• Problema de autenticação ao tentar fazer login no BotCity Studio

A solução ideal nesse caso é solicitar para o time de TI da empresa algumas liberações de acesso. Veja mais detalhes sobre as URLs que precisam de liberação de acesso na seção: Problemas com bloqueios do ambiente.

Esse tipo de problema costuma ocorrer quando a etapa de instalação das dependências não é feita da forma correta. Ao rodar o código, é lançada uma mensagem referente a instalação dos pacotes: ModuleNotFoundError: No module named 'botcity’.

A primeira etapa é garantir que o mesmo interpretador Python está sendo utilizado para instalar as dependências e rodar o código. Algo comum de acontecer é a própria IDE criar um ambiente virtual para o projeto, se esse ambiente virtual for utilizado para instalar as dependências porém na hora de rodar está sendo utilizado o Python "global" do sistema, então muito provavelmente esse erro referente a instalação será lançado.

Após garantir que a configuração dos ambientes está correta, basta usar o mesmo interpretador Python para instalar as dependências: pip install --upgrade -r requirements.txt e rodar o código posteriormente.

Uma nova conta que é criada no Maestro tem durante um período de 30 dias acesso total as funcionalidades da plataforma (trial). Após esse período de 30 dias, o acesso à plataforma continua da mesma maneira, a única diferença são algumas limitações e o acesso à alguns recursos específicos.

Após o período de trial, não é possível utilizar mais as funcionalidades de:

• Credenciais
• Auditoria
• Agendamentos
• BotCity Documents (dentro do Studio)

Além disso, o workspace também terá algumas limitações de outros recursos:

• Tarefas - máximo de 10 tarefas criadas por dia
• Automações - máximo de 1 processo de automação na plataforma
• Runners - máximo de 1 Runner Desktop na plataforma

Veja mais detalhes sobre a diferença entre os planos e os recursos disponíveis acessando este link.

Uma ótima alternativa para ter um primeiro contato com a ferramenta é acessar os cursos disponibilizados no BotCity Academy.

Além disso, você também pode acessar os tutoriais disponíveis no portal de documentação:

• Desenvolvendo seu primeiro bot Desktop
• Desenvolvendo seu primeiro bot Web
• Orquestrando seus processos de automação

Em situações esporádicas, pode ser que o Runner pareça ficar travado após puxar uma nova tarefa para execução. Nesse tipo de situação, a execução não é iniciada e o status do Runner fica como Executing task... até que o Runner seja reiniciado.

No geral, o que pode causar esse tipo de problema são os recursos utilizados pela execução anterior, que não foram finalizados da forma adequada. Dessa forma, quando há a tentativa no código de acessar esses recursos novamente, ocorre um conflito por causa do sistema operacional considerar que esses recursos já estão "em uso".

Um exemplo clássico é a utilização do WebDriver em automações Web. Sem a finalização adequada, pode ser que o WebDriver continue em execução mesmo após a finalização do processo, fazendo com que isso afete as execuções seguintes.

Uma possível solução para esse tipo de problema, é incluir tratamentos no código para garantir que todos os recursos que são alocados e utilizados pelo robô, sejam finalizados da forma correta ao final da execução, mesmo em casos onde ocorram exceções.

Seguindo essa boa prática, toda vez que esse processo for executado pelo Runner o ambiente vai estar "limpo", e com isso não haverá problemas na tentativa de utilizar determinados recursos.

Em alguns casos, por motivos de segurança, o cliente não permite que o desenvolvedor acesse o ambiente diretamente, obrigando que a construção da automação seja feita através de uma conexão remota, desta forma, podem surgir algumas dificuldades ao manipular uma aplicação que está em um ambiente remoto.

Através do Framework Desktop BotCity, podemos controlar uma máquina remota via RDP utilizando visão computacional.

Abaixo estão listados alguns pontos importantes para obter sucesso na busca de elementos dentro deste cenário de conexão remota e visão computacional:

• A conexão RDP deve ser configurada para usar uma resolução constante (não pode ser adaptativa como tela cheia, pois pode variar de caso para caso).
• A conexão RDP deve ser configurada para usar um parâmetro de experiência fixo e não automaticamente com base na velocidade da conexão.

Com uma configuração de resolução definida, você conseguirá utilizar tranquilamente o BotCity Studio para fazer as capturas de tela e manipular os elementos de uma aplicação que está rodando em um ambiente remoto.

O erro OSError: screen grab failed normalmente é lançado ao tentar executar uma automação que faz uso da visão computacional para encontrar elementos em um ambiente onde a conexão remota já foi encerrada. Isso ocorre porque ao encerrar a conexão, o sistema operacional fará com que a tela fique preta, impedindo que os robôs capturem a tela e realizem a procura por elementos gráficos.

Para contornar esse problema, a BotCity oferece dois scripts para conseguir rodar robôs que utilizam a interface gráfica do ambiente sem que seja necessário estar conectado a sessão. Esses scripts desconectam a sessão atual do usuário e a redireciona para uma sessão de terminal, mantendo a sessão e interface gráfica ativas para o BotCity Runner.

Esses scripts estão disponíveis dentro da pasta do BotCity Studio SDK, e podem ser usados nas configurações de execução do Runner. Você pode optar por executá-los ao iniciar o Runner usando o parâmetro startup, ou antes de cada tarefa que será executada pelo Runner, através do parâmetro beforeTask.

Veja mais detalhes sobre o uso e implementação desses scripts na seção Mantendo a sua sessão remota ativa.

Em alguns casos, ao utilizar o Microsoft Remote Desktop no MacOS para iniciar uma sessão RDP, é necessário alterar a configuração da codificação para evitar problemas na digitação de caracteres especiais e também caracteres maiúsculos.

Esse problema pode ocorrer, por exemplo, ao tentar utilizar no código da sua automação a função kb_type() do framework Desktop da BotCity para digitar caracteres maiúsculos em um processo que está rodando em uma VM.

Nesse tipo de situação, a codificação configurada por padrão no Microsoft Remote Desktop do MacOS pode fazer com que a digitação dos caracteres não funcione corretamente dentro da VM.

Para configurar a codificação e evitar esse tipo de problema na sessão RDP, basta acessar a aba Connections e marcar a opção Keyboard Mode > Unicode no aplicativo do Microsoft Remote Desktop.

Em alguns casos esporádicos, ao utilizar a tecla de Print Screen para que uma captura de tela seja feita, a imagem capturada não é exibida no Studio.

Esse comportamento pode estar relacionado com diversos fatores, como por exemplo outras aplicações que interceptam a ação do Print Screen fazendo com que o BotCity Studio não consiga acessar a imagem.

Abaixo estão listadas algumas abordagens que podem ser utilizadas caso você esteja enfrentando este tipo de problema:

Os bloqueios de acesso são bastante comuns em ambientes corporativos. Com isso, pode ser que você encontre alguns problemas ao tentar utilizar as ferramentas da BotCity e os recursos do Python em uma máquina que esteja no ambiente da sua empresa.

Um problema que pode acontecer nesses cenários é a falha na validação do certificado SSL ao tentar executar comandos utilizando o pip do Python, como por exemplo para fazer a instalação de alguma dependência.

WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] \ 
certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)'))': /simple/pip/

Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): \
Max retries exceeded with url: /simple/pip/ (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] \
certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)'))) - skipping

Caso você esteja observando algum erro parecido com esse no log do Runner ou ao executar comandos manualmente, pode ser que o seu ambiente esteja com algum bloqueio para instalar pacotes diretamente do PyPI (Python Package Index).

Para resolver esse problema, você pode tentar executar o seguinte comando para fazer uma configuração global do pip relacionada ao trusted-host:

pip config set global.trusted-host \
    "pypi.org files.pythonhosted.org pypi.python.org" \
    --trusted-host=pypi.python.org \
    --trusted-host=pypi.org \
    --trusted-host=files.pythonhosted.org

Dessa forma, a próxima vez que o Runner for realizar a etapa de instalação das dependências, esse erro relacionado ao SSL não voltará a acontecer.