FAQ¶

Este tipo de problema es más común en casos donde hay bloqueos en el entorno de la empresa donde se están utilizando las herramientas. A continuación se presentan algunos de los comportamientos observados:

• La instalación a través del Asistente se queda atascada en 0%.
• Fallo al iniciar sesión en BotCity Studio.
• Error de autenticación al iniciar BotCity Runner.

La solución ideal en este caso sería solicitar al equipo de TI de la empresa algunos permisos de acceso. Consulta más detalles sobre las URL que requieren acceso en la sección: Problemas con entornos bloqueados.

Este problema suele ocurrir cuando no se realiza correctamente el paso de instalación de las dependencias. Al ejecutar el código, se muestra un mensaje relacionado con la instalación de los paquetes: ModuleNotFoundError: No module named 'botcity’.

El primer paso es asegurarse de utilizar el mismo intérprete de Python para instalar las dependencias y ejecutar el código. Algo común es que el IDE cree un entorno virtual para el proyecto; si se utiliza este entorno virtual para instalar las dependencias pero al ejecutar se está utilizando el Python "global" del sistema, entonces probablemente se producirá este error.

Después de asegurarse de que la configuración del entorno es correcta, utiliza el mismo intérprete de Python para instalar las dependencias: pip install --upgrade -r requirements.txt y luego ejecuta el código.

Una cuenta nueva que se crea en Maestro tiene acceso completo a las funcionalidades de la plataforma (prueba) durante un período de 30 días. Después de este período de 30 días, el acceso a la plataforma continúa de la misma manera; la única diferencia son algunas limitaciones y el acceso a algunos recursos específicos.

Después del período de prueba, ya no es posible utilizar las siguientes características:

• Credenciales
• Auditoría
• Programaciones
• Documentos de BotCity

Además, el espacio de trabajo también tendrá algunas limitaciones en otras características:

• Tareas: máximo de 10 tareas creadas por día
• Automatizaciones: máximo de 1 proceso de automatización en la plataforma
• Runners: máximo de 1 Desktop Runner en la plataforma

Consulta más detalles sobre la diferencia entre los planes y los recursos disponibles accediendo a este enlace.

Una excelente alternativa para tener un primer contacto con las herramientas es acceder a los cursos disponibles en BotCity Academy.

Además, también puedes acceder a los tutoriales disponibles en el portal de documentación:

• Desarrollando tu primer bot desktop
• Desarrollando tu primer bot web
• Orquestando tus procesos de automatización

En situaciones esporádicas, el Runner puede parecer atascado después de lograr una nueva tarea para la ejecución. En esta situación, la ejecución no se inicia, y el estado del Runner permanece como Executing task ... hasta que se reinicie el Runner.

En general, lo que puede causar este tipo de problema son los recursos utilizados por la ejecución anterior, que no se han finalizado correctamente. Por lo tanto, cuando hay un intento en el código de reaccionar estos recursos, se produce un conflicto porque el sistema operativo considera estos recursos ya "en uso".

Un ejemplo clásico es el uso de web drivers en la automatización web. Sin un acabado adecuado, el web driver puede continuar ejecutándose incluso después de que se complete el proceso, haciendo que esto afecte las siguientes ejecuciones.

Una posible solución a este tipo de problema es incluir tratamientos de código para garantizar que todos los recursos asignados y utilizados por el robot, se terminan correctamente al final de la ejecución, incluso en los casos en que ocurren excepciones.

Siguiendo esta buena práctica, cada vez que Runner ejecute este proceso el entorno estará "limpio", y por tanto no habrá problemas a la hora de intentar utilizar determinados recursos.

En algunos casos, por razones de seguridad, el cliente no permite que el desarrollador acceda directamente al entorno, lo que obliga a la construcción de automatización a través de una conexión remota. Por tanto, pueden surgir algunas dificultades a la hora de manipular una aplicación que se encuentre en un entorno remoto.

A través de BotCity Desktop Framework, podemos controlar una máquina remota a través de RDP mediante visión por computadora.

A continuación se enumeran algunos puntos importantes para tener éxito en la búsqueda de elementos dentro de este escenario de conexión remota y visión por computadora:

• La conexión RDP debe configurarse para usar una resolución constante (no se puede adaptar como una pantalla completa, ya que puede variar de un caso a otro).
• La conexión RDP debe configurarse para usar un parámetro de experiencia fijo y no automáticamente en función de la velocidad de conexión.

Con una configuración de resolución definida, podrá utilizar BotCity Studio sin problemas para tomar capturas de pantalla y manipular elementos de una aplicación que se ejecuta en un entorno remoto.

El error OSError: screen grab failed por lo general, se lanza al intentar realizar una automatización que utiliza la visión computacional para encontrar elementos en un ambiente donde la conexión remota ya se ha cerrado. Esto se debe a que al cerrar la conexión, el sistema operativo hará que la pantalla sea negra, evitando que los bots capturen la pantalla y que sea imposible buscar elementos gráficos.

Para superar este problema, BotCity ofrece dos scripts para ejecutar robots que utilizan la interfaz gráfica del entorno sin necesidad de estar conectados a la sesión. Estos scripts desconectan la sesión actual del usuario y lo redirigen a una sesión de terminal, manteniendo activa la sesión y la interfaz gráfica para BotCity Runner.

Estos scripts están disponibles dentro de la carpeta BotCity Studio SDK, y se pueden usar en la configuración de ejecución del Runner. Puede optar por ejecutarlos iniciando el Runner utilizando el parámetro startup, o antes de cada tarea que el Runner realice, a través del parámetro beforeTask.

Consulte más detalles sobre el uso e implementación de estos scripts en la sección Mantener activa tú sesión remota.

En algunos casos, al utilizar Microsoft Remote Desktop en MacOS para iniciar una sesión RDP, es necesario cambiar la configuración de codificación para evitar problemas al escribir caracteres especiales y también caracteres en mayúsculas.

Este problema puede ocurrir, por ejemplo, al intentar utilizar la función kb_type() del framework Desktop de BotCity para escribir caracteres en mayúsculas en un proceso que se está ejecutando en una VM.

En este tipo de situación, la codificación configurada por defecto en Microsoft Remote Desktop de MacOS puede hacer que la escritura de los caracteres no funcione correctamente dentro de la VM.

Para configurar la codificación y evitar este tipo de problema en la sesión RDP, simplemente acceda a la pestaña Connections y marque la opción Keyboard Mode > Unicode en la aplicación de Microsoft Remote Desktop.