Fedicom Server aplicado
Edito 25.04.2016:
Un video breve del funcionamiento en Vimeo
Pues al final sí que he tenido tiempo, y en este fin de semana he terminado de implementar un servidor de pedidos Fedicom.
Lo tengo en un servidor en DigitalOcean un servidor local en Ubuntu Server.
Se trata de enviar pedidos fedicom a ese servidor, manipularlos de alguna forma y si se quiere, o bien crear ficheros de texto con el pedido para su posterior tratamiento en otra aplicación, o bien enviarlos automáticamente a otro servidor fedicom. El emisor de pedidos no se entera de ese proceso pues va a recibir las respuestas correctamente incluso las faltas si se redirige el pedido.
El poder reenviarlos automáticamente a otro servidor puede ser de utilidad cuando se quiere enviar sólo los productos que no estén en falta, o simplemente redirigir ciertas lineas a distintos servidores fedicom por delegaciones por ejemplo.
Un resúmen del ejemplo eliminando las faltas sería éste:
- El emisor emite el pedido en formato Fedicom al servidor de DigitalOcean.
- Se comprueba que el formato del pedido cumpla las especificaciones fedicom, incluso el check de líneas y códigos. Si no es así se le responde en el formato adecuado que no es así.
- Se valida que exista el cliente, y si no es así se le contesta que cliente inexistente. Esto lo voy hacer haciendo una petición socket contra el ERP destino, el cual tiene que tener preparado para recibir esa petición.
- Si todo va bien, se tratarán todas las líneas del pedido, se consultan las existencias reales de cada código en el ERP destino también mediante otra función socket.
- Del pedido se excluyen las que no haya existencias para servir y si queda alguna línea del pedido con existencias se genera un fichero con el nuevo pedido a solicitar.
- Se contesta con todas las faltas al emisor original del pedido y se corta la comunicación con él.
- Con el fichero del nuevo pedido se envía por fedicom al ERP que en realidad será el que servirá los productos solicitados. La respuesta que nos de ya no nos servirá para nada.
Otras notas
Aunque pudiera parecer que todo este proceso pueda tardar mucho y por tanto haya un desfase de existencias o un corte debido al exceso de tiempo, esto no es así. Se realiza todo en cuestión de muy pocos segundos por lo que el usuario emisor apenas se da cuenta.
Se supone que se aprovecha concurrencia por lo que se pueden recibir más de un pedido a la vez.
Quedan logs en formato de ficheros de texto en el servidor de Digitalocean tanto de cada uno de los pedidos como de sus respuestas.
Es cierto que el ERP destino tiene que estar preparado para responder a determinadas peticiones socket como ExisteCliente o ExistenciasReales para poder recibir las faltas. Si se quisiera sólo el pedido para otras menesteres se podría por ejemplo capturar el pedido en un fichero y tal cual enviarselo al ERP destino, recoger todas las faltas y devolverselas al emisor tal cual sin ninguna manipulación en medio.
Todo está desarrollado en Go.
El fichero .ini con los parámetros es como este, y todos sus parámetros funcionan y tienen su utilidad:
```
# nivel de salida de logs por pantalla
debug=0
# datos por si reenvia el pedido
reenviapedido=0
ippedidos=pedtran.empresa.com
puerto=1111
# creamos fichero para leer por otros erps
creafichero=0
rutafichero=../../src/
# sockets consultas socio o existencias para las faltas
consultasocio=1
consultaexistencias=1
consultaip=ped.empresa.com
consultapuerto=4444
# tanto para reenvio pedido como fichero para erp si eliminamos faltas
borrafaltas=0
```
Y un fichero ejemplo a tratar por Disfar:
```
[principal]
direccion=transfer.empresa.com
puerto=1111
usuario=2525::TR
contra=
cliente=2525
tpedido=
pedido=borrame2
dtopedido=00.00
aplazamiento=000
fechaenvio=00000000
[articulos]
0000006025540=3
0000007077030=1
```
Para Disfar programé la rutina ZVZCMM
en MUMPS que es capaz de incorporar a Disfar pedidos, transfer y compromisos de compra según los ficheros con el formato de arriba, procesando todos los que encuentre en una carpeta definida y pasándolos a histórico por si se requiere su consulta posterior.