Cita:
Empezado por Neftali [Germán.Estévez]
Reescrito quedaría así (a ver si se entiende mejor...)
Código:
Inicio sistema (no habrá nada)
...
12:00:00 Se prepara envío (como es vacio, no se envía NADA); 60 sg. de espera
12:01:00 Se prepara envío (como es vacio, no se envía NADA); 60 sg. de espera
12:01:10 Generamos factura 1
12:01:45 Generamos factura 2
12:02:00 Se prepara envío (2 facturas en el envío); 60 sg. de espera
12:03:00 Se prepara envío (como es vacio, no se envía NADA); 60 sg. de espera
12:03:10 Generamos factura 3
12:03:20 Generamos factura 4
12:03:30 Generamos factura 5
12:03:40 Generamos factura 6
12:03:50 Generamos factura 7
12:04:00 Se prepara envío (5 facturas en el envío); AEAT contesta con 120 sg. de espera
12:06:00 Se prepara envío (como es vacio, no se envía NADA); 120 sg. de espera
12:08:00 Se prepara envío (como es vacio, no se envía NADA); 120 sg. de espera
12:09:50 Generamos factura 8
12:10:00 Se prepara envío (1 factura en el envío); AEAT contesta con 60 sg. de espera
12:11:00 Se prepara envío (como es vacio, no se envía NADA); 60 sg. de espera
...
|
De esta forma se entiende mucho mejor.
Me parece correcto el sistema.
En nuestro caso la tarea despierta siempre cada 60, pero a la práctica los envíos se harían en el mismo momento que este ejemplo de Germán, porque al despertar la tarea busca el valor de tiempo de espera indicado en la última comunicación (TiempoEsperaEnvio) y también la fecha y hora de ese último envío (TimestampPresentacion).
Luego suma el TiempoEsperaEnvio al TimestampPresentacion y compara con la hora actual (del ROA). si ya ha pasado el tiempo, envía, sinó termina la tarea hasta la siguiente iteración, hay un sleep de 60s.
Lo hemos hecho de esta forma, y no haciendo que la tarea espere un tiempo variable para despertar, porque la misma tarea al despertar envía (en procesos separados) registros de facturación de varios OT y he aceptado la posibilidad (supongo que remota o casi inexistente) de que para cada envío (a un OT) la AEAT conteste tiempos de espera distintos, y claro si fuera el caso, siempre esperaria solo el TiempoEsperaEnvio del último envío (del último OT). Imagino que nunca pasará pero por si a caso, tenemos una tabla donde se registra para cada OT el TiempoEsperaEnvio y el TimestampPresentacion del último envío y el servicio lo consulta antes de enviar.
Encontráis algún problema en nuestro planteamiento? a parte de ser un poco mas de trabajo para el desarrollador y alguna conexión a base de datos mas
Muchas Gracias