Ver si proceso en ejecución en máquina remota

[Neftali [Germán.Estévez]]

Empezado por nincillo

Yo había pensado en abrir un puerto y por sockets hacer llamadas cada vez que se genera una factura para que el programa "externo" proceda al envío y sino hay respuesta a la petición avisar del problema.

Si es posible, lo más sencillo (creo yo) es que tantos los programas cliente (ERP) como el servicio (o la app. que habías pensado) estén conectados a la Base de Datos.
Los ERP van colocando ficheros en la cola (es una o varias tablas dependiendo del diseño) y el servicio los va procesando y en la misma Base de Datos va generando las respuestas.
La lógica de envío sólo está en el servicio.

Empezado por nincillo

¿Podrías orientarnos un poco el como hacer un programa que funcione como un servicio?

Nosotros diseñamos el servicio en 2 piezas (EXE + DLL). En realidad para facilitar debug y pruebas, se diseña un servicio y una aplicación.
Para no "repetir" código, toda la lógica se encuentra en la DLL y esa DLL se llama desde una APP y desde un SERVICIO.
Como he dicho la APP y el SERVICIO sólo tienen una llamada al método de "procesar" de la DLL (que tiene toda la lógica).


¿Porqué se hace esto? Porque los servicios no pueden tener parte visual y los LOGs para debug se envían al registro de eventos de Windows, en el caso de la APP sí puede tener parte visual y los LOGs para debug se envían a un fichero. Para todo el proceso de desarrollo se usa la APP+DLL y para el cliente final SERVICIO+DLL.



Si buscas por los foros encontrarás muchos hilos al respecto y posiblemente en el FTP encontrarás algún ejemplo:
https://www.clubdelphi.com/foros/showthread.php?t=89341
https://www.clubdelphi.com/foros/showthread.php?t=48843
https://www.clubdelphi.com/foros/showthread.php?t=12776
https://www.clubdelphi.com/foros/showthread.php?t=20913
https://www.intitec.com/varios/delph...io_windows.pdf

[RUBEN_SP]

Empezado por Neftali [Germán.Estévez]

Si es posible, lo más sencillo (creo yo) es que tantos los programas cliente (ERP) como el servicio (o la app. que habías pensado) estén conectados a la Base de Datos.
Los ERP van colocando ficheros en la cola (es una o varias tablas dependiendo del diseño) y el servicio los va procesando y en la misma Base de Datos va generando las respuestas.
La lógica de envío sólo está en el servicio.

Y que paso si en el mismo servidor hay varias instancias de la Base de Datos porque hay varias instalaciones ¿Cómo sabe el servicio a cual tiene que atender?

[ermendalenda]

Empezado por RUBEN_SP

Y que paso si en el mismo servidor hay varias instancias de la Base de Datos porque hay varias instalaciones ¿Cómo sabe el servicio a cual tiene que atender?

Lo más rápido es un registro de índice único autonumerico y controlar poner en bucle los reintentos por si coinciden 2 escrituras. Cuando te deje escribir obtienes el número que será único.
Los servicios se atienden a quien los pide, no se entremezclan y además puedes mandarles parámetros para identificar desde donde lo envías para que se registre.

[RUBEN_SP]

Empezado por ermendalenda

Lo más rápido es un registro de índice único autonumerico y controlar poner en bucle los reintentos por si coinciden 2 escrituras. Cuando te deje escribir obtienes el número que será único.
Los servicios se atienden a quien los pide, no se entremezclan y además puedes mandarles parámetros para identificar desde donde lo envías para que se registre.

No entiendo donde pones ese registro de índice único, ni tampoco se como se pasan parámetros a un servicio que está en ejecución

[Neftali [Germán.Estévez]]

Empezado por RUBEN_SP

Y que paso si en el mismo servidor hay varias instancias de la Base de Datos porque hay varias instalaciones ¿Cómo sabe el servicio a cual tiene que atender?

Es cuestión de buscar soluciones a los problemas.
En nuestro caso hay un único Servidor de Base de Datos, pero puede haber varias Bases de Datos dentro de ese servidor.
Cada base de datos es una empresa/obligado diferente (no se si es también tu caso); El servicio hace y una rueda y se va conectando a las diferentes Bases de Datos para enviar los datos de esa empresa. Una vez acabado se apunta en tiempo de espera (o el tiempo hasta el siguiente envío) para esa empresa.

Es decir, en nuestro caso, un único servicio se encarga de todos los envíos de las diferentes empresas/obligados tributarios. Por ahora en el Thread principal, porque no contemplamos que la "rueda de envío" pueda tardar más de 60 sg. Actualmente se hace muy rápido. Si en su día esa "rueda de envíos" empezara a tardar mucho, nos planteamos crear Threads (ya lo tenemos pensado).

[rci]

Empezado por Neftali [Germán.Estévez]

Es cuestión de buscar soluciones a los problemas.
En nuestro caso hay un único Servidor de Base de Datos, pero puede haber varias Bases de Datos dentro de ese servidor.
Cada base de datos es una empresa/obligado diferente (no se si es también tu caso); El servicio hace y una rueda y se va conectando a las diferentes Bases de Datos para enviar los datos de esa empresa. Una vez acabado se apunta en tiempo de espera (o el tiempo hasta el siguiente envío) para esa empresa.

Es decir, en nuestro caso, un único servicio se encarga de todos los envíos de las diferentes empresas/obligados tributarios. Por ahora en el Thread principal, porque no contemplamos que la "rueda de envío" pueda tardar más de 60 sg. Actualmente se hace muy rápido. Si en su día esa "rueda de envíos" empezara a tardar mucho, nos planteamos crear Threads (ya lo tenemos pensado).

Nosotros lo tenemos montado igual que vosotros Neftali, pero además en una misma base de datos puede haber varias empresas.
También estamos considerando hacer threads independientes para cada empresa (obligado tributario) para que se vayan enviando en paralelo las facturas de cada OT.
Pero como es un proceso que se va ejecutando repetidamente, si hacemos threads asíncronos, el proceso volverá a iniciarse y podría ser que el anterior no hubiera terminado y dos procesos estuviesen intentando enviar las mismas facturas. No tengo claro como hacerlo, porque si espero a que termine un envío (proceso síncrono) ya no tengo procesos en paralelo... le tendremos que dar una vuelta.
Saludos

[YellowStone]

De momento nosotros lo estamos controlando en desarrollo con un campo en la base de datos, cada vez que comienza un envío, se marca ese campo, y no se desmarca hasta que el propio proceso de envío lo desmarca al final, así si se intenta realizar un nuevo envío estando el campo marcado, no se permite.

El único problema que le veo a esto, que estoy pensando cómo solucionarlo, es que el proceso se interrumpa por cualquier motivo (un pantallazo azul de la muerte, por ejemplo) y no se desmarque el campo, y se queden las facturas sin enviar porque el proceso no arranca de nuevo.

[ermendalenda]

Ojo con eso para no verifactu
Las bases de datos y datos tienen que estar claramente separadas para distintos obligados tributariosm
Y según cono tengas el sif también para verifactu.

[rci]

Empezado por ermendalenda

Ojo con eso para no verifactu
Las bases de datos y datos tienen que estar claramente separadas para distintos obligados tributariosm
Y según cono tengas el sif también para verifactu.

Anda no sabia nada de eso.
nosotros en principio solo haremos modo Veri*Factu.
En cada tabla hay un campo que indica de que obligado tributario es esa información... eso sirve para lo que dices ermendalenda?

[razorxxx]

Empezado por ermendalenda

Ojo con eso para no verifactu
Las bases de datos y datos tienen que estar claramente separadas para distintos obligados tributariosm
Y según cono tengas el sif también para verifactu.

¿Puedes indicar en qué artículo del reglamento pone que esto es así?

[Neftali [Germán.Estévez]]

Empezado por ermendalenda

Las bases de datos y datos tienen que estar claramente separadas para distintos obligados tributarios

No se que quiere decir eso.
En un ERP con multiempresa puedes una Base de Datos con diferentes obligados tributarios. Creo que es lo habitual si piensas en empresas con varias sucursales, por ejemplo; o en un despacho/gestoría que gestiona N clientes.

[glopez]

Empezado por YellowStone

De momento nosotros lo estamos controlando en desarrollo con un campo en la base de datos, cada vez que comienza un envío, se marca ese campo, y no se desmarca hasta que el propio proceso de envío lo desmarca al final, así si se intenta realizar un nuevo envío estando el campo marcado, no se permite.

El único problema que le veo a esto, que estoy pensando cómo solucionarlo, es que el proceso se interrumpa por cualquier motivo (un pantallazo azul de la muerte, por ejemplo) y no se desmarque el campo, y se queden las facturas sin enviar porque el proceso no arranca de nuevo.

Hola, Creo que esto podrías solucionarlo comprobando si el campo está "desmarcado" o eres el único que está conectado a la BD. Es decir, no hay nadie más conectado a esa empresa.

[ISCOPYME]

Empezado por Neftali [Germán.Estévez]

Si es posible, lo más sencillo (creo yo) es que tantos los programas cliente (ERP) como el servicio (o la app. que habías pensado) estén conectados a la Base de Datos.
Los ERP van colocando ficheros en la cola (es una o varias tablas dependiendo del diseño) y el servicio los va procesando y en la misma Base de Datos va generando las respuestas.
La lógica de envío sólo está en el servicio.


Nosotros diseñamos el servicio en 2 piezas (EXE + DLL). En realidad para facilitar debug y pruebas, se diseña un servicio y una aplicación.
Para no "repetir" código, toda la lógica se encuentra en la DLL y esa DLL se llama desde una APP y desde un SERVICIO.
Como he dicho la APP y el SERVICIO sólo tienen una llamada al método de "procesar" de la DLL (que tiene toda la lógica).


¿Porqué se hace esto? Porque los servicios no pueden tener parte visual y los LOGs para debug se envían al registro de eventos de Windows, en el caso de la APP sí puede tener parte visual y los LOGs para debug se envían a un fichero. Para todo el proceso de desarrollo se usa la APP+DLL y para el cliente final SERVICIO+DLL.

Buenos días. A ver si alguien me puede dar alguna pista sobre el error que estoy teniendo. Yo hasta ahora tenía una dll que se encargaba de todo, el envío a la aeat, la respuesta, etc.... funcionando correctamente. Cuando he decidido crear un servicio que aproveche esta dll, mi sorpresa ha sido que no funciona correctamente, me da el siguiente error "Received content of invalid Content-Type setting: text/html - SOAP expects "text/xml".

¿ Alguien sabe algo de este error o me puede decir si se puede depurar un servicio en funcionamiento, para ver qué está pasando. ?

Muchas gracias.

[Neftali [Germán.Estévez]]

¿Estás llamado a la URL correcta?
Deberás añadir log, para ver más o menos dónde está fallando.
CXreo que suele ser lo habitual, cuando el componente de envío no recibe una respuesta correcta al realizar la llamada, por ejemplo cuando la URL es incorrecta, pero sin saber algo más concreto es difícil.

[ISCOPYME]

Hola. Buenos días.
La url que estoy enviando es : xxxxxhttps://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP sin las xxxxx

Pero lo más curioso es que la dll es la misma, en un proyecto tengo una aplicación que llama a la dll y funciona correctamente y en el segundo proyecto que es el servicio hace exactamente lo mismo, pero la dll devuelve el error. He visto por ahí que hay que poner la propieda content-type del httprio en "text/xml; charset=utf-8" pero no lo veo en el componente por ningún sitio. No sé si lo tengo delante, pero no lo veo.

[aleixep]

Empezado por ISCOPYME

Buenos días. A ver si alguien me puede dar alguna pista sobre el error que estoy teniendo. Yo hasta ahora tenía una dll que se encargaba de todo, el envío a la aeat, la respuesta, etc.... funcionando correctamente. Cuando he decidido crear un servicio que aproveche esta dll, mi sorpresa ha sido que no funciona correctamente, me da el siguiente error "Received content of invalid Content-Type setting: text/html - SOAP expects "text/xml".

¿ Alguien sabe algo de este error o me puede decir si se puede depurar un servicio en funcionamiento, para ver qué está pasando. ?

Muchas gracias.

Primero que nada, ¡hola a todos! Este es mi primer mensaje al foro, así que espero hacerlo bien.

En nuestro caso, ISCOPYME, nos salía ese error cuando no se enviaba correctamente el certificado electrónico. Si abres el navegador web, pegas esa URL y no seleccionas el certificado, la AEAT devuelve un HTML indicando el error 403. En nuestro caso, si el Delphi no encontraba el certificado, cuando hacía la petición al WebService sin él, también devolvía un HTML. ¡Espero que te sirva!

[ISCOPYME]

Empezado por aleixep

Primero que nada, ¡hola a todos! Este es mi primer mensaje al foro, así que espero hacerlo bien.

En nuestro caso, ISCOPYME, nos salía ese error cuando no se enviaba correctamente el certificado electrónico. Si abres el navegador web, pegas esa URL y no seleccionas el certificado, la AEAT devuelve un HTML indicando el error 403. En nuestro caso, si el Delphi no encontraba el certificado, cuando hacía la petición al WebService sin él, también devolvía un HTML. ¡Espero que te sirva!

Buenos días aleixep, gracias por tu aportación. He puesto logs en todos los sitios y efectivamente, no se lanza el procedimiento OnNeedClientCertificate del httprio. Lo que no consigo entender es por qué sí se lanza cuando lo hago desde una aplicación/form y no se lanza cuando se está haciendo desde un servicio windows. ¿ Alguien sabe como forzar a que se ejecute este procedimiento siempre ?

Muchas gracias.

[ISCOPYME]

Ya he averiguado el problema.

Lo pongo en vuestro conocimiento, por si a alguno le pasara.

Por lo visto al crear el servicio se instala bajo la cuenta del usuario del sistema local, que parece ser no tiene privilegios de acceso al almacén de certificados de windows. Cuando he cambiado el usuario que inicia la sesión a un usuario con privilegios ya funciona correctamente.