Lo que tengo actualmente se puede resumir con este pseudocódigo:
public static void Main(string[] args)
{
var listOfObjects = Database.GetObjectsToUploadToOnlineService();
Parallel.ForEach(Upload)
}
private static void Upload(MyUploadObject obj)
{
//Build object (takes a few milliseconds)
//Format to JSON (takes a few more milliseconds)
//Upload (can take up to a max of 10 minutes)
//Wait for a response (can take up to a max of 10 minutes)
//Save response to our database (takes a few milliseconds)
}Este programa se acaba de configurar en nuestro servidor como una tarea programada. Somos dueños del programa y podemos hacer lo que queramos con él. Mi pregunta surge de un blog sobre hacer controles automáticos de monitoreo (no tengo un enlace a mano).
Así que eso me hizo pensar: ¿cómo puedo modificar mi programa para poder iniciar otro programa de "monitoreo"? ¿O debería cambiar esto de ser un programa de consola a decir un programa WPF que está oculto?
En general, preferiría poder ejecutar un programa en mi computadora que verifique el progreso del programa a través de la red, por lo que no tengo que RDP en el servidor para verificar su estado (pero no ser el fin del mundo).
En general, supongo que me gustaría ver una ventana que diga algo como: Procesar x de y hasta ahora, se están procesando los siguientes elementos. Enumere los elementos en, como, una tabla y haga que digan como "Cargando" o "Esperando respuesta". Tal vez si me vuelvo loco también podría hacer una cola de elementos fallidos (pero eso sería solo extra).
Mi mente sigue inclinándose hacia un evento, pero no puedo entender cómo ejecutaría un programa que pueda suscribirse y cancelar la suscripción a un programa en ejecución. ¿Es esto posible?
fuente
Respuestas:
Lo que necesita es una forma de comunicarse entre sus programas que no los vincule entre sí. Hay varias maneras de hacer esto, puede hacer que la tarea escriba en un archivo y tenga que monitorear la lectura del archivo, hacer que la tarea esté disponible a través de WCF para que el monitor pueda 'sondear' los cambios, usar la red ...
Para evitar reinventar la rueda, eche un vistazo a los objetivos de registro de log4net. Si tuviera que implementar algo como esto, probablemente usaría log4net e iniciaría sesión en UDP o Telnet y conectaría el monitor en el otro extremo. log4net se encarga de todo por usted, incluso no lanzar excepciones cuando no hay un monitor activo.
fuente
Según sus comentarios, veo que tiene una base de datos de cliente / servidor disponible, y su cargador ya tiene una conexión y acceso de escritura. Entonces, probablemente sería más fácil agregar una tabla de "monitoreo" o "estado" a la base de datos y dejar que su cargador informe su progreso allí (registre cada paso "interesante" allí, probablemente los 5 pasos que enumeró anteriormente).
Para ver el estado, cree un segundo programa con GUI, que se conecta a la base de datos y muestra el estado (por ejemplo, sondeando en intervalos de 1 minuto). Puede ejecutar ese programa en su escritorio local, asumiendo que es posible conectarse a la base de datos desde allí.
Por supuesto, al escribir en una tabla de estado interfiere con las transacciones de su base de datos, puede usar una conexión separada. También puede utilizar un mecanismo de cola de mensajes como MSQM para él, pero esa podría ser una solución de gran tamaño para su caso simple.
fuente
Solo para construir sobre la respuesta de @ JDT, una forma común de hacerlo es escribir mensajes en una cola de mensajes. Cada vez que sucede algo importante en su aplicación, escribiría un mensaje y lo enviaría a la cola de mensajes. Normalmente, el formato del mensaje es XML o similar. Es el escritor de colas.
La aplicación de monitoreo lee (lector de colas) la cola y recoge los mensajes y los procesa guardándolos y analizando el mensaje frente a mensajes o condiciones anteriores. Si se cumple una condición, la aplicación de monitoreo generará una alerta que indica un posible problema.
Esto desacopla su aplicación del monitoreo, ya que solo está enviando mensajes. Depende de la aplicación de monitoreo determinar cuándo, basándose en los mensajes actuales, que algo bueno o malo ha sucedido. Las colas se usan porque ofrecen un buen medio para almacenar los mensajes sin pérdida.
Desea mensajería centralizada si hay varias instancias de su aplicación ejecutándose. Si solo hay 1 instancia, puede ser suficiente usar otras tiendas como el registro de eventos de Windows o un archivo.
fuente