Saltar a contenido

FAQ

Preguntas frecuentes

Esta página reúne las dudas más comunes de quienes desarrollan, ejecutan y orquestan automatizaciones con las herramientas de BotCity. Cada entrada describe un escenario específico, explica qué suele causar ese comportamiento y presenta la solución o una forma de sortear el problema.

Las preguntas están agrupadas por tema, desde la instalación y la configuración del entorno hasta la ejecución por el Runner, los escenarios de conexión remota, el desarrollo de las automatizaciones y las dudas sobre planes en el Orquestador. Haz clic en una pregunta para expandir la respuesta.

Compartir una respuesta específica

Cada entrada tiene su propio enlace, así que puedes compartir una respuesta específica con otras personas de tu equipo. Para copiar ese enlace:

  1. Haz clic en la pregunta para expandir la respuesta.
  2. Pasa el mouse sobre el título de la pregunta y haz clic en el icono de enlace (¶) que aparece al lado.
  3. Copia la dirección de la barra del navegador, que ahora apunta directamente a esa pregunta.

¿No encontraste tu pregunta?

Si tu escenario no está listado aquí, elige el canal según el tipo de duda:

  • Duda técnica, con plan contratado: abre un ticket en el portal de soporte. El acceso al portal se envía por correo electrónico a los usuarios de la organización, y cada plan tiene su regla de atención, descritas en el contrato. Los clientes Enterprise cuentan además con un canal directo con el equipo de Automation Experience.
  • Duda técnica, sin plan contratado: pregunta en el grupo de WhatsApp, donde el equipo de BotCity y otras personas usuarias responden. Los demás canales abiertos están reunidos en la página Comunidad.
  • Contrato, límites de la cuenta o upgrade de plan: habla con tu representante comercial o usa el formulario de contacto del sitio.

Instalación y configuración del entorno

¿Cómo resolver el problema de instalación que se queda atascado en 0%?

¿Cómo resolver el problema de instalación que se queda atascado en 0%?

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. Entre los comportamientos observados están:

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

Antes de abrir la solicitud al equipo de TI, confirma el origen del problema con la herramienta de diagnóstico. El BotCity - Diagnostic acompaña al paquete del Asistente y valida la conectividad con el Orquestador, además de las versiones de Java y Python instaladas en la máquina:

  1. Ejecuta el diagnostic.jar, que está en la misma carpeta del Asistente.
  2. Informa la URL de tu servidor y haz clic en Run Tests.
  3. Revisa el retorno de cada verificación en las columnas Test, Result y Notes.

Un resultado FAIL en alguna prueba de conexión indica que la máquina está en un entorno con bloqueos, y la columna Notes muestra qué falló en cada caso. Usa el botón Export para generar un archivo CSV con los resultados y enviarlo al equipo de TI junto con la solicitud de liberación.

La solución ideal en este caso es 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.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Qué hacer cuando el Wizard.exe es bloqueado por las políticas de seguridad de la empresa?

¿Qué hacer cuando el Wizard.exe es bloqueado por las políticas de seguridad de la empresa?

Al iniciar la instalación, la configuración o la autenticación del BotCity Runner mediante el Asistente en formato .exe, puedes no conseguir abrir el archivo. Esto suele ocurrir por políticas de seguridad que bloquean la ejecución de archivos ejecutables, una medida común para evitar la propagación de malware y el uso de software no autorizado.

Para sortear la restricción, usa la versión del Asistente distribuida para Linux, en formato .jar. Depende del Java Runtime Environment y suele pasar por las políticas sin bloqueo:

  1. Descarga el Asistente en formato .jar, disponible en la sección de descargas para Linux.
  2. Abre el archivo .jar.
  3. Si el Asistente inicia normalmente, sigue con la instalación o la configuración como de costumbre.

Si prefieres continuar con el archivo .exe, será necesario abrir una solicitud al equipo de seguridad de tu empresa pidiendo la liberación de ejecución de archivos .exe en el entorno.

El Asistente .jar no tiene limitación funcional

Usar el Asistente en .jar es perfectamente válido y no compromete el funcionamiento esperado de las herramientas. Si quieres evitar nuevas solicitudes al equipo de seguridad, puedes seguir con la versión .jar sin ninguna limitación.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo resolver el problema con la instalación de las dependencias al ejecutar la automatización (ModuleNotFoundError)?

¿Cómo resolver el problema con la instalación de las dependencias al ejecutar la automatización (ModuleNotFoundError)?

Al ejecutar la automatización, Python interrumpe la ejecución al inicio e informa que no encontró un paquete que ya habías instalado:

ModuleNotFoundError: No module named 'botcity'

En la mayoría de los casos, esto significa que las dependencias se instalaron en un intérprete de Python diferente del que ejecuta el código. Es común que el propio IDE cree un entorno virtual para el proyecto: si las dependencias se instalan en ese entorno virtual, pero el código se ejecuta con el Python "global" del sistema (o al contrario), los paquetes no se encuentran.

Para resolverlo, usa el mismo intérprete en las dos etapas:

  1. Descubre qué intérprete está activo en la terminal con python -c "import sys; print(sys.executable)" y compáralo con el intérprete seleccionado en tu IDE.
  2. Con el intérprete correcto activo, instala las dependencias: pip install --upgrade -r requirements.txt.
  3. Ejecuta la automatización con ese mismo intérprete.

Error similar con otra dependencia

Si tienes un problema parecido con alguna otra dependencia al ejecutar tu automatización con BotCity Runner, verifica si la dependencia fue definida correctamente en el archivo requirements.txt del robot.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo resolver problemas de verificación del certificado SSL al ejecutar comandos usando pip?

¿Cómo resolver problemas de verificación del certificado SSL al ejecutar comandos usando pip?

Al instalar dependencias con pip, manualmente o mediante el Runner, el comando falla porque Python no consigue validar el certificado SSL de la conexión con PyPI. El error aparece en el log del Runner o en la propia terminal:

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

Este escenario es común en entornos corporativos, donde el proxy o el firewall de la empresa intercepta la conexión y presenta un certificado interno que pip no reconoce. Mientras eso no se trate, ningún paquete se instala directamente desde PyPI (Python Package Index).

Para resolverlo, marca los dominios de PyPI como confiables en la configuración global de pip:

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

Con la configuración aplicada, la próxima instalación de dependencias, incluida la que el Runner hace antes de ejecutar la tarea, ya no debería fallar por causa del certificado.

Valida la configuración con los equipos de TI y seguridad

Si esta alternativa no es suficiente, valida con el equipo de TI de tu empresa si es una solución adecuada para tu entorno.

Recuerda también verificar con el equipo de TI si es necesario realizar configuraciones adicionales con respecto al uso de pip.

Puedes encontrar más detalles sobre bloqueos del entorno en la sección de requisitos previos de la documentación.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo configurar un proxy autenticado para las herramientas de BotCity?

¿Cómo configurar un proxy autenticado para las herramientas de BotCity?

En entornos corporativos con proxy autenticado, que exige usuario y contraseña, liberar las URLs en el firewall puede no ser suficiente. El Wizard, el Runner, el BotCLI, BotCity Studio y las automatizaciones Python también necesitan saber qué proxy usar y con qué credenciales para comunicarse con el Orquestador e instalar dependencias.

Para resolverlo, configura el proxy en dos puntos:

  • Herramientas Java (Wizard, Runner, BotCLI y BotCity Studio): define las propiedades de proxy de la JVM, por aplicación o mediante la variable de entorno JAVA_TOOL_OPTIONS.
  • Automatizaciones Python: crea las variables de entorno HTTP_PROXY y HTTPS_PROXY en el formato http://usuario:contraseña@host:puerto. pip y la biblioteca requests las leen en cualquier entorno virtual.

El paso a paso completo, incluido el tratamiento de caracteres especiales en la contraseña, está en la guía Configurar Proxy Autenticado en las Herramientas BotCity.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo confiar en un certificado SSL corporativo (SSL Inspection) en las herramientas Java y Python de BotCity?

¿Cómo confiar en un certificado SSL corporativo (SSL Inspection) en las herramientas Java y Python de BotCity?

En entornos con proxy de inspección SSL (SSL Inspection), la empresa sustituye el certificado original de los servidores por un certificado emitido por una CA interna. Las herramientas Java y Python no reconocen esa CA y rechazan la conexión, con errores como PKIX path building failed en Java o CERTIFICATE_VERIFY_FAILED en Python.

En este escenario, configurar el trusted-host de pip no resuelve el problema por completo, porque solo afecta la instalación de paquetes. El Wizard, el Runner y BotCity Studio siguen rechazando el certificado.

Para resolverlo, registra el certificado raíz de la CA interna en el truststore de cada tecnología:

  • Java (Wizard, Runner y BotCity Studio): importa el certificado en el cacerts de la JVM que usan las herramientas, con keytool.
  • Python (requests): crea un bundle personalizado a partir de certifi, con el certificado de la CA interna, y apunta la variable de entorno REQUESTS_CA_BUNDLE hacia él.

El paso a paso completo está en la guía Configurar Certificado SSL Corporativo.

Certificado proporcionado por el equipo de seguridad

El certificado raíz de la CA interna normalmente lo proporciona el equipo de infraestructura o de seguridad de tu empresa. Solicita el archivo (.crt, .cer o .pem) antes de comenzar la configuración.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

Ejecución por el Runner

¿Cómo resolver el error Python environment preparation failed al ejecutar una automatización mediante el Runner?

¿Cómo resolver el error Python environment preparation failed al ejecutar una automatización mediante el Runner?

Antes de ejecutar una tarea, el Runner prepara el entorno Python del robot. Cuando esa etapa falla, la tarea no llega a ejecutarse y el log registra Python environment preparation failed. Tres causas responden por la mayoría de los casos, y el propio log del Runner indica cuál es la tuya.

1. El Runner no alcanza PyPI

En el log aparecen intentos de conexión con pypi.org que terminan en timeout:

WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ReadTimeoutError("HTTPSConnectionPool(host='pypi.org', port=443): Read timed out. (read timeout=15)")': /simple/pip/
...
Python environment preparation failed.
Error executing task: Python environment preparation failed...

Sin acceso a PyPI, el pip install no consigue descargar los paquetes del robot. Esto es común en entornos corporativos con bloqueo de salida. Pide al equipo de infraestructura las liberaciones de firewall listadas en la sección Uso de Python en el desarrollo de automatizaciones.

2. Python no está instalado correctamente en la máquina

El log trae el mensaje de abajo justo después del intento de crear el entorno virtual:

execAndWait - Error: Cannot invoke "java.lang.Process.waitFor()" because "this.process" is null

En ese caso, Python no está instalado, no está en el PATH del sistema o le faltan los paquetes que el Runner usa para montar el entorno virtual. Confirma la instalación:

python --version
where python

Si los comandos responden, instala los paquetes necesarios:

python -m pip install --upgrade pip setuptools virtualenv

3. El Runner llama al comando equivocado de Python

Cuando la máquina tiene más de una versión instalada, cada una suele responder por un comando diferente. Prueba py y python en la terminal para descubrir cuál de ellos llama a la versión que el robot necesita. Si es py, infórmalo al Runner en el archivo conf.bcf, dentro de la carpeta conf donde se instaló el SDK de BotCity:

pythonBinary=py

También puedes indicar la ruta completa del ejecutable en el mismo parámetro, por ejemplo pythonBinary=C:\\Python312\\python.exe.

Usa barras dobles en la ruta de Python

Al informar la ruta completa en pythonBinary, escríbela con barras dobles, para que la barra simple no sea interpretada como carácter de escape durante la ejecución.

Consulta todos los parámetros aceptados por el conf.bcf en la sección Personalizar la configuración del Runner.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo tratar el error No pyenv.cfg file en los logs del Runner?

¿Cómo tratar el error No pyenv.cfg file en los logs del Runner?

Este error aparece en los logs del Runner cuando la creación del entorno virtual del robot no se completa: el archivo pyenv.cfg, que identifica el entorno, no fue generado o quedó incompleto.

Empieza siempre por el log del Runner para confirmar el mensaje. Si no es suficiente para identificar la causa, incluye debugEnabled=true en el archivo conf.bcf para generar una salida de log más detallada y reproduce el problema. El parámetro está disponible a partir de la versión 2.7.0 del Runner y se describe en la sección Personalizar la configuración del Runner.

Con el log en mano, verifica las causas más comunes:

Causa probable Qué verificar
Archivo setup.py en la carpeta del proyecto Renombra el setup.py y ejecuta la tarea nuevamente.
Creación del entorno interrumpida por falta de memoria RAM, falta de espacio en disco, timeout o falta de permiso Revisa los recursos de la máquina y el permiso de escritura en la carpeta de destino. En esos casos, la carpeta del entorno virtual puede incluso ser creada, pero con archivos pendientes.
Bloqueo por antivirus o EDR Crea el entorno virtual manualmente en la carpeta de destino para confirmar si existe algún bloqueo.
Limpieza de la carpeta por otra herramienta Verifica si alguna herramienta de limpieza actúa sobre la carpeta de destino.
Dos Runners creando el entorno en la misma carpeta Garantiza que solo un Runner trabaje sobre el mismo entorno virtual.
Entorno creado con una versión de Python diferente de la actual Confirma si la versión de Python en uso en la máquina es la misma que generó el entorno virtual.

Dónde quedan los entornos virtuales

Los entornos virtuales se crean en el directorio de instalación del SDK, dentro de la carpeta venvs. Si el SDK fue instalado en Documentos, por ejemplo, la ruta será C:\Users\{nombre_usuario}\Documents\BotCity\venvs\. Consulta la estructura completa de carpetas en la sección Explorando el Contenido.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Qué hacer cuando el Runner parece atascado después de tomar una tarea para ejecución?

¿Qué hacer cuando el Runner parece atascado después de tomar una tarea para ejecución?

En situaciones esporádicas, el Runner toma una nueva tarea, pero la ejecución no comienza: el estado permanece en Executing task... hasta que el Runner sea reiniciado.

En la mayor parte de los casos, la causa son recursos de la ejecución anterior que no fueron finalizados correctamente. Cuando el código intenta usar esos recursos de nuevo, el sistema operativo los considera "en uso" y la nueva ejecución no avanza. El ejemplo más común es el WebDriver en automatizaciones Web: sin el cierre adecuado, sigue en ejecución incluso después de que el proceso termina y afecta las ejecuciones siguientes.

Para resolverlo, garantiza en el código que todo recurso asignado por el robot sea liberado al final de la ejecución, incluso cuando ocurre una excepción. En automatizaciones Web, eso significa cerrar el navegador con bot.stop_browser(), conforme la sección Detener navegador, preferentemente dentro de un bloque finally, para que la limpieza ocurra incluso cuando el robot falla en medio del proceso.

Verifica siempre si todos los recursos usados en la ejecución fueron debidamente cerrados. Con el entorno limpio al final de cada ejecución, el Runner consigue iniciar la tarea siguiente sin conflicto con los recursos anteriores.

Consultando el log.txt del Runner

También puedes consultar siempre el archivo log.txt generado por el Runner para verificar cualquier excepción lanzada durante la preparación del entorno y la ejecución del proceso.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo corregir una tarea que quedó con el status incorrecto en el Orquestador?

¿Cómo corregir una tarea que quedó con el status incorrecto en el Orquestador?

La tarea continúa en el Orquestador con un estado que no corresponde a la realidad, normalmente En ejecución, incluso sin ninguna ejecución en curso en el Runner.

El Runner tiene un tratamiento interno que finaliza la tarea en estado de error cuando la falla no es reportada por el código o cuando hay una cancelación forzada. Ese tratamiento no se activa cuando el Runner se cierra de forma abrupta, por ejemplo en un reinicio o apagado de la máquina sin cerrar el Runner antes. Es en ese escenario que el estado queda desactualizado.

El estado incorrecto no afecta las ejecuciones siguientes, el impacto es solo visual y administrativo. Para corregirlo, finaliza la tarea con el BotCLI, que acompaña al BotCity Studio SDK:

  1. Abre una terminal en la carpeta donde se instaló el SDK.
  2. Copia el ID de la tarea en el Orquestador, disponible en Información de la tarea.
  3. Ejecuta el comando de abajo, cambiando 123 por el ID copiado y el número de tareas procesadas:
./BotCLI task finish -taskId "123" -totalItems 1 -processedItems 1 -failedItems 0

El comando finaliza la tarea y actualiza los indicadores de ítems totales, procesados con éxito y con fallo, de forma que deje de aparecer como En ejecución en la cola.

Otros argumentos del comando

El task finish también acepta un mensaje de finalización y el tipo de conclusión (SUCCESS, FAILED o PARTIALLY_COMPLETED). Consulta todos los argumentos en la sección task finish y la sintaxis general de la herramienta en Empezando.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

Entornos remotos y sesiones RDP

¿Qué hacer al recibir el error OSError: screen grab failed al ejecutar una automatización usando el Runner en un entorno remoto?

¿Qué hacer al recibir el error OSError: screen grab failed al ejecutar una automatización usando el Runner en un entorno remoto?

El error aparece cuando la automatización usa visión computacional para encontrar elementos en la pantalla, pero la conexión remota con la máquina de ejecución ya fue cerrada. Sin nadie conectado, el sistema operativo deja la pantalla negra, y el robot no consigue capturar la pantalla para buscar los elementos gráficos.

La salida es garantizar que la máquina tenga una sesión gráfica activa en el momento de la ejecución. Tienes dos opciones.

1. Scripts de sesión del BotCity SDK

BotCity distribuye dos scripts que desconectan la sesión actual del usuario y la redirigen a una sesión de terminal, manteniendo la sesión y la interfaz gráfica activas para el Runner. Están en la carpeta del SDK y se indican en el archivo de configuración del Runner: usa el parámetro startup para ejecutarlos cuando el Runner inicia, o beforeTask para ejecutarlos antes de cada tarea.

Script Dónde está Qué hace
startup.bat Carpeta startup Desconecta la sesión actual y la redirige a una sesión de terminal.
console_session.bat Carpeta scripts Hace la misma redirección y además define una resolución de pantalla específica para la nueva sesión.

Consulta el uso y la implementación de cada uno en la sección Mantener activa tu sesión remota.

2. BotCity Session Manager

En lugar de mantener la sesión abierta todo el tiempo, el Session Manager activa la sesión en la máquina remota conforme las tareas entran en la cola del Orquestador y la desactiva cuando no hay nada más para ejecutar. La interfaz gráfica queda disponible durante la ejecución, sin sesión ociosa después de ella, lo que también reduce el costo de las máquinas y atiende a las políticas de seguridad que limitan sesiones de usuario activas.

Consulta lo que hace la herramienta en BotCity Session Manager y cómo configurarla en Primeros Pasos.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo encontrar elementos utilizando visión computacional en conexiones remotas?

¿Cómo encontrar elementos utilizando visión computacional en conexiones remotas?

Por motivos de seguridad, es común que el cliente no permita el acceso directo al entorno, y que la automatización deba construirse a través de una conexión remota. En ese escenario, el robot encuentra los elementos en una conexión y deja de encontrarlos en la siguiente.

El motivo es que la imagen capturada cambia de una conexión a otra. Si la resolución de la sesión RDP es adaptativa, o si la calidad de la conexión se define automáticamente por la velocidad de la red, cada sesión presenta la pantalla de una forma un poco diferente, y las imágenes capturadas en BotCity Studio dejan de corresponder a lo que aparece en la pantalla.

Para que las capturas sean constantes entre las conexiones, configura la sesión RDP antes de mapear los elementos:

  1. En el cliente de conexión remota, haz clic en Mostrar opciones.
  2. En la pestaña Display, define una resolución fija, en lugar de una opción adaptativa como pantalla completa.
  3. En la pestaña Experiencia, elige un parámetro fijo de calidad, en lugar de dejar la detección automática por la velocidad de la conexión.

Recaptura los elementos después de cambiar la conexión

Cualquier cambio en las configuraciones de resolución o experiencia altera la imagen de la pantalla. Actualiza siempre los elementos visuales en BotCity Studio capturándolos nuevamente después de ajustar el acceso remoto, de lo contrario las imágenes antiguas no serán encontradas.

Con la resolución fija, consigues capturar la pantalla con BotCity Studio y usar los métodos de visión computacional del Framework Desktop para manipular una aplicación que se está ejecutando en el entorno remoto.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Qué hacer cuando el script de startup devuelve Session not found?

¿Qué hacer cuando el script de startup devuelve Session not found?

El script que debería desconectar la sesión del usuario y redirigirla a la consola falla con el mensaje Session not found, y la sesión continúa como estaba.

La causa suele ser un nombre de usuario con espacios, como USER NAME. El script console_session.bat, que está en la carpeta scripts del BotCity Studio SDK, localiza la sesión activa por el nombre del usuario:

FOR /F "skip=1 tokens=3 usebackq" %%X in (`query session %USERNAME%`) DO tscon %%X /dest:console
powershell.exe -Command Set-DisplayResolution -Width 1600 -Height 900 -Force

Con un nombre compuesto, el espacio rompe la consulta del query session y no queda ningún ID de sesión para que tscon redirija.

Para resolverlo, cambia %USERNAME% por el comodín %User*Name% en la primera línea del script, manteniendo el resto como está:

FOR /F "skip=1 tokens=3 usebackq" %%X in (`query session %User*Name%`) DO tscon %%X /dest:console
powershell.exe -Command Set-DisplayResolution -Width 1600 -Height 900 -Force

El comodín localiza la sesión incluso cuando el nombre tiene espacios u otros caracteres especiales. El fragmento skip=1 tokens=3 sigue extrayendo el ID de la sesión, y tscon la redirige a la consola.

Variación para el startup.bat

El startup.bat, que está en la carpeta startup del SDK, hace la misma redirección por PowerShell:

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "$sessionid=((quser $env:USERNAME | select -Skip 1) -split '\s+')[2]; tscon %sessionname% /dest:console"

En ese script, tscon usa la variable %sessionname%, y no el resultado del quser, entonces un nombre de usuario con espacios no impide la redirección. La consulta del quser alimenta solo la variable $sessionid, que el script no llega a utilizar.

Si adaptaste el startup.bat para usar el $sessionid

Un nombre de usuario compuesto ocupa dos columnas en la salida del quser y desplaza las posiciones del -split. En ese caso, el índice [2] deja de apuntar al ID de la sesión y necesita ajustarse conforme la salida del comando en tu máquina.

Consulta el contenido original de los scripts y cómo indicarlos en la configuración del Runner en las secciones Script de desconexión de sesión y Script de configuración del ambiente.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo configurar la codificación para evitar problemas al escribir caracteres en sesiones RDP en MacOS?

¿Cómo configurar la codificación para evitar problemas al escribir caracteres en sesiones RDP en MacOS?

El robot escribe el texto en la VM, pero los caracteres en mayúsculas y los caracteres especiales salen mal o simplemente no aparecen. El caso típico es el método kb_type() del Framework Desktop, usado en un proceso que se ejecuta en una VM accedida desde MacOS.

La causa está en la codificación de teclado que el Microsoft Remote Desktop de MacOS usa por defecto en la sesión RDP: no corresponde a lo que la VM espera recibir, y parte de las teclas enviadas por el robot se pierde en el camino.

Para corregirlo, cambia la codificación en la aplicación de Microsoft Remote Desktop:

  1. Accede a la pestaña Connections.
  2. Marca la opción Keyboard Mode > Unicode.

Pantalla de configuración de Microsoft Remote Desktop en MacOS con la opción Keyboard Mode definida como Unicode.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

Desarrollo de automatizaciones

¿Qué hacer cuando la tecla Print Screen no captura la pantalla en BotCity Studio?

Presionas Print Screen para llevar la pantalla de la aplicación a la pestaña UI del Studio, como se describe en Trayendo la pantalla de interacción al Studio, pero la captura no se carga.

La mayoría de las veces, otra aplicación en ejecución está interceptando la tecla Print Screen y BotCity Studio no llega a recibir la imagen.

Empieza verificando la propia tecla:

  • Confirma que el Print Screen está activo y funcional en otras aplicaciones de la máquina.
  • Cierra o deshabilita programas que capturan la pantalla y pueden estar interceptando la tecla.

Si la tecla continúa no disponible, usa una de las alternativas de captura:

Alternativa Descripción
Botón de captura en el Studio Además del Print Screen, también puedes capturar la pantalla con el botón en el menú superior derecho de BotCity Studio.
Atajo de teclado personalizado El Studio permite configurar otra tecla o combinación para la captura. Consulta cómo en Atajo personalizado de impresión.
Extensión para VSCode BotCity Studio también está disponible como extensión para instalar directamente en VSCode. Consulta más en BotCity Studio para Visual Studio Code.

En macOS la tecla es otra

En macOS, la captura no se hace con el Print Screen, sino con la tecla F9, por limitación del propio sistema operativo.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Por qué el navegador Edge no inicia cuando la automatización se ejecuta mediante el Orquestador?

¿Por qué el navegador Edge no inicia cuando la automatización se ejecuta mediante el Orquestador?

La automatización Web con Microsoft Edge se ejecuta normalmente en la ejecución local, pero falla cuando el robot se ejecuta mediante el Orquestador. El navegador no llega a abrir y la ejecución se detiene con el siguiente mensaje en el log:

Message: session not created: probably user data directory is already in use, please specify a unique value for --user-data-dir argument, or don't use --user-data-dir

A pesar de que el texto apunta al directorio de perfil, el comportamiento viene de un bug de Selenium, reportado en la issue #15340 del repositorio oficial: Edge intenta relanzar sus propios procesos por la capa de compatibilidad, y es el relanzamiento el que falla. Por eso el error aparece en las ejecuciones controladas por el Runner y no en el entorno local.

Versiones en las que el problema fue reportado

La issue fue abierta con Selenium en la versión 4.29.0, Edge y msedgedriver en la versión 133.0.3065.82, en Windows 10. Hasta el momento no hay una versión de Selenium indicada como corrección, así que mantén el argumento aplicado incluso después de actualizar el navegador o el driver. Acompaña la issue para verificar si la situación cambió.

Para sortearlo, agrega el argumento --edge-skip-compat-layer-relaunch a las opciones del navegador, siguiendo el mismo formato de la sección Personalización de las opciones del navegador:

def_options = default_options(
    headless=bot.headless,
    download_folder_path=bot.download_folder_path,
    user_data_dir=None,  # Informar 'None' aquí generará un directorio temporal
)

# Impide que Edge relance los procesos por la capa de compatibilidad
def_options.add_argument("--edge-skip-compat-layer-relaunch")

bot.options = def_options

Con el argumento aplicado, los robots vuelven a ejecutarse en el entorno orquestado, sin necesidad de cambiar configuraciones locales o políticas de ejecución de la máquina.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Cómo resolver el error de certificado SSL al conectar al Orquestador desde el código Python?

¿Cómo resolver el error de certificado SSL al conectar al Orquestador desde el código Python?

El robot falla al conectarse al Orquestador mediante BotMaestroSDK porque Python no reconoce el certificado SSL presentado en la conexión. Normalmente el log muestra un SSLError con el mensaje CERTIFICATE_VERIFY_FAILED.

Este escenario es común en entornos corporativos, donde el servidor usa un certificado autofirmado o el proxy de la empresa intercepta el tráfico y presenta un certificado emitido por una CA interna.

Para solucionarlo, desactiva la validación del certificado justo después de instanciar el SDK, antes de cualquier llamada al Orquestador:

from botcity.maestro import BotMaestroSDK

maestro = BotMaestroSDK.from_sys_args()
maestro.VERIFY_SSL_CERT = False  # Ignora la validación del certificado

Versión mínima del SDK

Para que la flag VERIFY_SSL_CERT funcione correctamente, la dependencia botcity-maestro-sdk debe estar en la versión 0.7.0 o superior.

Desactivar la validación reduce la protección de la conexión

Con VERIFY_SSL_CERT = False, el robot deja de validar el certificado presentado por el servidor. Valida con el equipo de seguridad de tu empresa si esta solución es adecuada para tu entorno. La alternativa más segura es hacer que la máquina de ejecución confíe en el certificado interno, como muestra la guía Configurar Certificado SSL Corporativo.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

Orquestador y planes

¿Cuáles son las características y limitaciones de una cuenta Community en el Orquestador BotCity?

¿Cuáles son las características y limitaciones de una cuenta Community en el Orquestador BotCity?

Una nueva cuenta creada en el Orquestador BotCity tiene acceso completo a las funcionalidades de la plataforma durante los primeros 30 días, el período de trial. Terminado ese plazo, parte de las funcionalidades se deshabilita y otra parte pasa a tener límite de uso.

Funcionalidades deshabilitadas:

Recursos que pasan a tener límite de uso:

Los valores de esos límites dependen de tu contrato, así que no existe un número único que valga para todas las cuentas. Para consultar los límites que se aplican a tu organización, accede a la página Cuenta y Planes en el Orquestador, que muestra el plan vinculado y los límites de automatizaciones y Runners.

Para confirmar las condiciones de tu contrato, o evaluar un upgrade, habla con tu representante comercial.

Las limitaciones valen solo para la orquestación

Las limitaciones de una cuenta Community están orientadas a la parte de orquestación.

La etapa de desarrollo de las automatizaciones no tiene ningún tipo de limitación con respecto al uso de los frameworks y plugins de código abierto de BotCity, ni al uso de las herramientas de BotCity Studio para visión computacional e inspector Web y Windows.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

¿Por cuánto tiempo se almacenan los datos históricos de las automatizaciones?

¿Por cuánto tiempo se almacenan los datos históricos de las automatizaciones?

El período de retención vale para los datos históricos que las automatizaciones generan en la plataforma:

Por cuánto tiempo esos datos continúan disponibles depende del contrato de tu organización, así que no existe un período único que valga para todas las cuentas.

Para confirmar la retención que se aplica a ti, consulta el plan vinculado a tu organización en la página Cuenta y Planes del Orquestador y valida el período contratado con tu representante comercial. Esa es también la conversación que vale cuando la operación necesita un histórico más largo por exigencia regulatoria o de auditoría.

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.

Aprendizaje y contenidos

¿Dónde puedo encontrar contenido para aprender más sobre el uso de BotCity?

¿Dónde puedo encontrar contenido para aprender más sobre el uso de BotCity?

El material de aprendizaje está distribuido entre cursos, tutoriales y canales de la comunidad. El mejor punto de partida depende de lo que necesites en el momento.

Para el primer contacto con la plataforma, haz los cursos de la Academia. Son gratuitos y solo requieren una cuenta BotCity.

Para construir una automatización de principio a fin, sigue los tutoriales del portal de documentación:

Para acompañar novedades e intercambiar experiencias, usa los canales abiertos:

¿Todavía necesitas ayuda?

Si esto no resuelve tu caso, o tu pregunta no está listada aquí, abre un ticket con el equipo de soporte.