# Recomendaciones para la creación de escenarios comerciales Al desarrollar escenarios comerciales en la plataforma Sherpa RPA, se deben seguir los siguientes requisitos y recomendaciones: 1. **Asegurar la operación ininterrumpida.** El escenario debe estar diseñado para funcionar durante 24 horas sin fallos ni interrupciones, por lo que todos los bloques deben contener alternativas para el manejo de errores a través del conector "Si hay error", o el modo de manejo de errores debe estar configurado en Ignorar, asegurando que el manejo de la situación de error sea realizado por uno de los siguientes bloques en el escenario. De esta manera, se debe garantizar la resiliencia del escenario ante la aparición en pantalla de elementos de control no previstos, así como ante retrasos en el funcionamiento de aplicaciones e internet. En tales casos, se debe omitir el elemento actualmente procesado y reiniciar correctamente el escenario para pasar al siguiente elemento a procesar. Por ejemplo, en los datos de entrada del escenario hay 10,000 nombres de productos de los cuales se deben recopilar precios. El desarrollador ejecuta el escenario por la noche, y por la mañana descubre que el escenario se interrumpió inesperadamente 30 minutos después de iniciarse, y el robot no completó el escenario. Por lo tanto, las cuestiones de fiabilidad de los escenarios y el desarrollo de diferentes variantes de eventos son muy importantes. 2. **Asegurar la resiliencia del escenario.** Para garantizar la resiliencia del escenario, en todos los bloques que interactúan con la interfaz de usuario y las páginas web (en modo visual) se deben establecer tiempos de espera y períodos de espera no nulos (adecuados). Además, se debe evitar el uso de esperas incondicionales y retrasos en todas partes donde no sea absolutamente necesario. En lugar de retrasos incondicionales, se debe esperar durante un tiempo finito la aparición de los elementos de control necesarios para continuar con el trabajo del escenario.\ En caso de cualquier fallo en el escenario y su posterior reinicio, el escenario debe continuar funcionando (aproximadamente) desde el lugar donde se detuvo anteriormente. 3. **Asegurar un volumen adecuado de mensajes de depuración en el registro.** El escenario debe registrar un volumen adecuado de mensajes de depuración, a partir del cual se pueda entender el progreso del procesamiento de la tarea y en qué etapa se encuentra el robot en ese momento. 4. **Asegurar el correcto funcionamiento de los archivos abiertos.** Todos los archivos abiertos para lectura o edición deben cerrarse de manera oportuna y correcta, sin retrasar la liberación del archivo por parte del robot más allá del tiempo necesario. Al abrir archivos, se debe considerar la posibilidad de que estén bloqueados por otra aplicación. Esto es relevante cuando los empleados de la empresa cliente deben trabajar con el archivo que está utilizando el robot. Por ejemplo, el robot fue programado para ejecutarse por la noche, y durante el día, los empleados deben trabajar con el mismo archivo. Si el robot no lo cierra, los empleados no podrán editarlo. 5. **Recomendaciones para escenarios que son iniciados manualmente por el usuario.** Para los escenarios que son iniciados manualmente por el usuario, se recomienda mostrar un mensaje al final de la ejecución del escenario, indicando si se completó con éxito o no, y con qué resultados. 6. **Recomendaciones para el desarrollo de escenarios destinados a ejecutarse según un horario.** * Para los escenarios que están destinados a ejecutarse según un horario, no se deben mostrar mensajes de error en forma de ventanas de diálogo. Todos los errores deben registrarse en el log, y el escenario debe hacer todo lo posible para continuar funcionando correctamente. * Los escenarios que están destinados a ejecutarse según un horario deben, en cualquier variante de su detención (programada o inesperada), devolver el entorno del sistema al estado en el que se encontraba en el momento de su inicio, para que el siguiente inicio de este mismo escenario se realice correctamente. No se debe acumular recursos, ventanas de navegadores/aplicaciones abiertas y no cerradas, etc. 7. **Recomendaciones para el desarrollo de robots Attended.** * El robot Attended debe informar regularmente al usuario sobre la etapa actual de trabajo y el documento (sitio, etc. - dependiendo de la lógica del escenario de negocio) mediante un mensaje en la parte superior de la pantalla (para esto se debe marcar la opción "Mostrar en estado" en el bloque "Log"). * Se debe configurar la salida de mensajes para que no se muestre más de un mensaje por segundo y al menos un mensaje cada 10 segundos. * La parte más significativa del mensaje para el usuario debe ir primero y ser visible en la pantalla. * La salida de mensajes no debe interferir con el funcionamiento normal del robot, así como con la interacción del usuario con la interfaz del ordenador, si se supone que el usuario puede trabajar en paralelo con el robot. * Se permite no mostrar mensajes en aquellos casos en que las acciones, la etapa y el progreso del trabajo del robot sean completamente evidentes por lo que está ocurriendo en la pantalla. * Los mensajes registrados en el log deben responder a las siguientes preguntas: "¿qué está sucediendo ahora?", "¿todo va según lo planeado?", "¿cuánto tiempo tomará esto?" o "¿qué tan rápido se está procesando el volumen de trabajo asignado?" 8. **Recomendaciones para el almacenamiento de fuentes.** Todos los códigos fuente de todos los robots deben guardarse en una cuenta de GitHub. Para cada proyecto del desarrollador se creará un subrepositorio al que el ejecutor tendrá acceso. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sherparpa.ru/es/sherpa-rpa/sherpa-designer/rabota-v-sherpa-designer/nachalo-raboty-v-sherpa-designer/rekomendacii-po-sozdaniyu-kommercheskikh-scenariev.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.