Ojo con el timeout!!!

[razorxxx]

Empezado por ermendalenda

Tarda poquisimo, yo he enviado 400 registros en un lote y no llega a 5 segundos, pero aquí hay que tener en cuenta distintas variablea:
Siempre vas tener una conexion estable y rapida?
Usas router de datos(tarjeta movil)?
Yo le tengo puesto parecido, 40 segundos, perp estoy pensando subirlo a 60 por que en algunas ubicaciones no llega fibra y tengo que usar datos.
Otra cosa importante es que el timeout lo tengas en cuenta restando a los 240segundos, por que si consideras que aun puedes enviar sin incidendia teniendo por ejempño, ya pasados los 210 segjundos, y hay un retardo puedes pasarte de los 240 y mejor que salte el timeout antes de llegar a lps 240 segundos y mandarlo como incidenxia posteriormente

O sea, que a los 240 segundos le resto mi timeout, y ése sería el tiempo para comparar el primer registro pendiente de envío con el último para saber si hay que añadir el campo Incidencia = S?

[ermendalenda]

Empezado por razorxxx

O sea, que a los 240 segundos le resto mi timeout, y ése sería el tiempo para comparar el primer registro pendiente de envío con el último para saber si hay que añadir el campo Incidencia = S?

Sí, sería lo recomendable. De hecho ya me ha psado, por eso ahora lo resto.
Simplemente puede pasar que tengas un problema de red puntual y se quede mas tiempo y se coma el timeout completo y acabe enviandolo en los ultinos segundos del timeout.

[razorxxx]

Empezado por ermendalenda

Sí, sería lo recomendable. De hecho ya me ha psado, por eso ahora lo resto.
Simplemente puede pasar que tengas un problema de red puntual y se quede mas tiempo y se coma el timeout completo y acabe enviandolo en los ultinos segundos del timeout.

El problema es que en Delphi hay 3 tipos de Timeouts para los envíos por SOAP (componentes THTTPRIO): uno para establecer la conexión, otro para el envío y otro para la recepción de la respuesta. ¿cómo se puede hacer para usar un timeout general de, digamos, 30 segundos?

[ermendalenda]

Empezado por razorxxx

El problema es que en Delphi hay 3 tipos de Timeouts para los envíos por SOAP (componentes THTTPRIO): uno para establecer la conexión, otro para el envío y otro para la recepción de la respuesta. ¿cómo se puede hacer para usar un timeout general de, digamos, 30 segundos?

A ver, el más extenso en tiempo debe ser el de esperar la respuesta, te explico por qué:
Verifactu recibe inmediatamente lo que envianos, pero encola las respuestas, con lo cual si le entran 100.000 envios en un segundo, las reciben todas y posteriormente dan la respuesra una vez que analizan el fichero recibido y responden en orden de entrada
Con lo cual
Establecimiento dd conexion =10 segundos van sobrados
Timeout envio= 20 va bien
Respuesta= lo máximo que puedas 30 o 40 segundos.

¿Qur puede ocurrir?
Que enviado el lote no recibas respuesta, y tu programa te dé el timeout, para tí no está enviado, pero ellos lo han gestionado, y cuando vuelvas a enviar te puede dar uno más registroa duplicados cuando tu no los tenias marcados, eso es importante tenerrlo en cuenta.

[razorxxx]

Empezado por ermendalenda

A ver, el más extenso en tiempo debe ser el de esperar la respuesta, te explico por qué:
Verifactu recibe inmediatamente lo que envianos, pero encola las respuestas, con lo cual si le entran 100.000 envios en un segundo, las reciben todas y posteriormente dan la respuesra una vez que analizan el fichero recibido y responden en orden de entrada
Con lo cual
Establecimiento dd conexion =10 segundos van sobrados
Timeout envio= 20 va bien
Respuesta= lo máximo que puedas 30 o 40 segundos.

¿Qur puede ocurrir?
Que enviado el lote no recibas respuesta, y tu programa te dé el timeout, para tí no está enviado, pero ellos lo han gestionado, y cuando vuelvas a enviar te puede dar uno más registroa duplicados cuando tu no los tenias marcados, eso es importante tenerrlo en cuenta.

Sí, eso ya pasaba con el SII, el famoso error 3000. Cuando se reciba el error de registro duplicado, en mi sistema pasaré dicho RF a la tabla de Enviados (si bien mi app va a funcionar exclusivamente en modo VeriFactu, quiero que exista un histórico de lo que se ha mandado). El problema es que en estos casos el CSV no se puede recuperar, ni siquiera desde la consulta de RF, aunque creo que es un campo que realmente me lo puedo ahorrar en la tabla.

[ermendalenda]

Empezado por razorxxx

Sí, eso ya pasaba con el SII, el famoso error 3000. Cuando se reciba el error de registro duplicado, en mi sistema pasaré dicho RF a la tabla de Enviados (si bien mi app va a funcionar exclusivamente en modo VeriFactu, quiero que exista un histórico de lo que se ha mandado). El problema es que en estos casos el CSV no se puede recuperar, ni siquiera desde la consulta de RF, aunque creo que es un campo que realmente me lo puedo ahorrar en la tabla.

Si hombre, lo tienen controlado, cuando mandas un regustro duplicado si ha tendio algun error te lo devuelven junto con la respuesta de registro duplicado.
O sea pueden devokverte registro duplicado y fuera de tiempo, eso significa que cuando se envió entro tarde y sin marcar incidencia.
Pero si lo mandaste xomo incidencia creo que se pierde el rastro de que lo mandaste xomo tal, tanto en consulta como en la respuesta de duplicado, pero eso ya lo puedes contemplar tú.