Una exportación funciona en la demostración, pero desaparece al reiniciar la aplicación web. Una importación programada se ejecuta dos veces al escalar a dos instancias. Un usuario pulsa de nuevo porque la primera solicitud agotó su tiempo de espera y empiezan dos copias del mismo trabajo. Estos problemas aparecen cuando se añade ejecución en segundo plano sin definir el ciclo de vida de la tarea.
Sacar trabajo de una petición HTTP puede mejorar la respuesta, pero también crea la responsabilidad de seguirlo hasta un resultado conocido. Un trabajo fiable tiene identidad, estado duradero cuando hace falta, ejecución controlada y un resultado útil para la persona o el sistema que lo pidió.
Decide si el trabajo debe sobrevivir a un reinicio
Distingue la actividad opcional dentro del proceso del trabajo de negocio que el sistema ha prometido realizar. Actualizar una caché desechable y generar una exportación para un cliente tienen necesidades de durabilidad diferentes. Si perder el proceso no debe perder el trabajo, registra el compromiso en almacenamiento duradero o una cola adecuada antes de comunicar su aceptación.
.NET ofrece abstracciones de servicios hospedados para ejecutar lógica en segundo plano dentro de una aplicación. La documentación de Microsoft sobre tareas hospedadas en segundo plano explica ese modelo. Un servicio hospedado no hace duradero por sí solo el trabajo en cola ni garantiza una única ejecución programada entre varias instancias.
Elige la organización de ejecución según la carga. Un proceso de trabajo dentro de la aplicación puede bastar para algunas tareas; uno operado por separado puede responder mejor a otras necesidades de escalado o fiabilidad. En ambos casos, el estado duradero y las reglas de procesamiento necesitan diseño propio.
Modela el trabajo como un ciclo de vida visible
Utiliza estados que comuniquen lo ocurrido: aceptado, en ejecución, completado, fallido o pendiente de revisión, por ejemplo. Define las transiciones permitidas y las pruebas de finalización. Evita comunicar éxito solo porque se recibió la solicitud de inicio.
Guarda un identificador estable y la información mínima necesaria para procesar correctamente. Incluye el contexto del cliente o del negocio y, cuando haga falta, la versión de la entrada solicitada. No dependas de que la sesión del navegador siga existiendo cuando el proceso empiece después.
En una exportación hipotética de existencias, el usuario podría recibir una referencia y una página de estado. El resultado debe explicar si refleja una instantánea o datos leídos durante el procesamiento. La diferencia importa si las existencias cambian mientras se ejecuta un trabajo grande.
Prevé interrupciones en cada paso importante
Un proceso puede detenerse después de leer un mensaje, escribir parte del resultado o completar una acción externa antes de confirmar el éxito. Diseña cómo se reanuda en cada punto. Asumir que siempre llegará a la última línea deja sin definir el comportamiento con mayores consecuencias.
Protege contra duplicados los efectos que no deben repetirse. Un identificador estable de operación, un paso completado registrado o una regla de unicidad adecuada pueden distinguir un reintento de trabajo nuevo. El mecanismo debe corresponder al efecto real en el negocio, además de impedir que dos procesos arranquen simultáneamente.
En trabajos de varios pasos, decide si guardar puntos de progreso, reiniciar desde el principio o compensar lo ya completado. Mantén comprensibles los estados intermedios. Un archivo parcialmente generado puede descartarse con seguridad, mientras que un envío externo parcial puede exigir conciliación antes de otro intento.
Coordina explícitamente los procesos y los horarios
Escalar una aplicación puede crear varias instancias de su servicio en segundo plano. Determina cómo se reserva el trabajo y cómo detecta otro proceso que una reserva ha caducado tras un fallo. Utiliza deliberadamente las garantías de la cola o del mecanismo de coordinación, sin depender de una variable estática en un único proceso.
Las tareas programadas necesitan la misma atención. Un temporizador en cada instancia puede repetir ejecuciones, y una aplicación detenida puede perder una ejecución prevista. Define si el trabajo omitido debe recuperarse, saltarse o revisarse y cómo se gestionan ejecuciones solapadas.
Registra la referencia temporal pertinente. Una tarea diaria ligada al día local de un cliente difiere de un intervalo UTC fijo, especialmente al cambiar la hora. Separa las reglas de programación de la hora mostrada para que la tarea no cambie de significado al trasladar la aplicación de entorno.
Limita concurrencia, reintentos y tiempo de procesamiento
Establece límites acordes con la capacidad de los sistemas posteriores. Más procesos pueden saturar una base de datos o API en lugar de terminar antes. Mide cómo afecta la concurrencia al proceso completo y elige límites que conserven un servicio útil para usuarios interactivos.
Clasifica los fallos antes de reintentar. Los datos inválidos normalmente deben convertirse en una tarea de corrección; un fallo temporal de dependencia puede justificar otro intento tras una pausa. Mantén un límite total de intentos o tiempo para que un elemento permanentemente fallido no consuma recursos indefinidamente.
Ofrece una cola de excepciones o una vista operativa equivalente. Debe explicar el trabajo fallido, los intentos pertinentes y las siguientes acciones permitidas. Reprocesar debe ser una decisión informada, especialmente si intentos anteriores pudieron producir efectos fuera de la base de datos del proceso.
Haz significativos el progreso y la cancelación
Expón el estado en términos comprensibles. Si no se puede medir el progreso exacto, una etapa clara puede ser mejor que un porcentaje inventado. Incluye una vía de respuesta para trabajos que superan su duración habitual, evitando que los usuarios creen más trabajo al repetir la solicitud.
Define con cuidado la cancelación. Una petición de cancelación puede detener pasos futuros sin revertir lo completado. Explica qué puede detener el sistema y si queda algún resultado o acción externa. El proceso debe atender la cancelación en límites adecuados, sin abandonar el estado a mitad de una escritura crítica.
Protege el acceso a los resultados. Las exportaciones y documentos generados pueden contener información restringida a un cliente o usuario. Autoriza su recuperación y decide cómo afectan la caducidad o los cambios de pertenencia al acceso a trabajos solicitados anteriormente.
Prueba el ciclo de vida con fallos controlados
Ensaya un reinicio después de aceptar trabajo, un mensaje duplicado, una dependencia lenta y un fallo después de un resultado parcial. Comprueba que el trabajo llega a un estado comprensible y que otro intento no duplica silenciosamente el efecto de negocio. Estas pruebas informan más que demostrar que un proceso puede ejecutar una función.
Supervisa antigüedad en cola, duración, patrones de fallo y resultados. Una cola pequeña puede contener un trabajo atascado desde hace días. Relaciona las alertas con una respuesta y conserva contexto para que soporte investigue sin buscar entre registros no relacionados.
Worktechlabs desarrolla aplicaciones y procesos .NET con el comportamiento operativo diseñado junto a las funciones. Combina el ciclo de vida de los trabajos con integraciones resistentes y observabilidad para que la ejecución en segundo plano siga siendo una parte visible del servicio, en lugar de un lugar donde desaparece el trabajo pendiente.
