juliobm algunos videos algunas notas algunos scripts aprendiendo

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:

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.