Cómo crear extranets B2B
La creación de una extranet que soporte la cadena de suministro de la empresa es una de las bazas fundamentales para salir airoso de los retos que plantea el comercio B2B. Pero su diseño e implementación exige tener en cuenta multitud de detalles. Aquí, Network World Global Test Alliance de IDG ofrece un modelo ideal de extranet B2B desarrollada en laboratorio pero perfectamente trasladable a la realidad diaria de muchas empresas.
Para crear un modelo ideal de extranet dedicada a soportar la cadena de suministro, se eligió el caso ficticio de un fabricante de automoción. A partir de aquí, se simularon dos escenarios extranet comunes: un enlace con un proveedor de misión crítica (un suministrador de piezas de automóviles) y otro con un proveedor menos fundamental para el negocio (un vendedor de material de oficina). Tres eran los objetivos: crear un enlace de red fiable tanto en hardware como en software, dar la seguridad apropiada y asegurar la integridad de los datos.
CONEXIONES DE RED
¿Qué medio de soporte de las transacciones con un socio comercial es el mejor, una línea alquilada, Frame Relay o una VPN basada en Internet? La respuesta dependerá de la criticidad que ese enlace tenga para la empresa. En el caso elegido de una planta de fabricación parece claro que no disponer en el momento oportuno de las piezas de automóvil necesarias podría convertirse en pérdidas significativas de dinero. El impacto sería muy distinto si lo que faltase fuera material de oficina.
Teniendo en cuenta estos condicionantes, para el enlace crítico se eligió un par de líneas alquiladas E-1 (2 Mbps) de dos operadores diferentes, lo que asegura una máxima disponibilidad. Para asegurarse un servicio continuado se probaron dos herramientas de balanceo de cargas, Microsoft Windows Load Balancing Service y Lightspeed Systems Total Control for E-Commerce IPMagic, para conmutar instantáneamente a la segunda línea cuando falle la primera. Ambas funcionaron perfectamente.Esta solución es cara en su conjunto, pero permite garantizar una fiabilidad del 99,9%.
Una alternativa más barata a la solución adoptada, también muy efectiva, consiste en contratar un par de enlaces Frame Relay a dos operadores diferentes. Sin embargo, se optó por las líneas alquiladas debido a que permitía utilizar hardware más sencillo y comprar DSU/CSU de diferentes fabricantes. A pesar de los obvios ahorros de costes, se rechazó la idea de usar una red privada virtual (VPN) basada en Internet porque añadía complejidad en la gestión y mayores riegos de seguridad, al tiempo que proporciona un rendimiento poco fiable.
Para el enlace con los suministradores de material de oficina –menos crítico– la alternativa VPN sí resultaba adecuada, ya que si Internet falla el impacto sobre el negocio no sería fundamental. Así, se creo una VPN de bajo ancho de banda entre la empresa y dichos suministradores.
GESTION DE ENLACES
Establecer los niveles de servicio y decidir quiénes serían los responsables de monitorizar el enlace con las firmas de piezas de automóvil fueron importantes pasos en el desarrollo del proyecto. Para mantener una fiabilidad del 99,9%, cada enlace E-2 se dedicó a soportar pedidos de piezas de automóvil, sin correo electrónico ni voz sobre IP (VoIP). Debido a su fiabilidad y su fácil configuración, se eligió VitalSuite, de Lucent, para monitorizar la WAN.
La negociación con un socio comercial para soportar comunicaciones TCP/IP no debería ser un problema, dada la popularidad de estos protocolos, fácilmente encaminables. Con todo, se prefirió complicar ago más la experiencia de laboratorio, estipulando que el suministrador de piezas de automoción utilizara un AS/400 y la arquitectura SNA de IBM.
Para conseguir los objetivos iniciales marcados, se concluyó que la mejor solución al problema que suponía utilizar niveles de transporte dispares era diseñar la aplicación con Advanced Program-to-Program Communications (APPC, también conocido como LU 6.2) para enviar y recibir transacciones. Y, a pesar de que se intentó por todos los medios complicar la situación, el diseño y administración del enlace APPC fue un juego de niños.
La única dificultad real apareció a la hora de diseñar el diálogo automatizado para que fuera tolerante a fallos imprevistos en la conexión, de modo que siempre se asegurase que las órdenes de pedidos llegasen a su destino. La intención era considerar a cada grupo transaccional de mensajes como un átomo, es decir, que la aplicación procesase solamente transacciones completas. También fue sencillo configurar un par de routers Cisco 4700, uno en la planta de ensamblaje y otro en las instalaciones del suministrador de piezas, para comunicar los paquetes SNA a través del enlace WAN.
Se rechazó la idea de usar una base de datos relacional como interfaz entre la planta de fabricación y el suministrador de piezas. Aunque insertar órdenes y confirmaciones en una base de datos compartida no tiene complicaciones, cada socio podría necesitar enviar un trigger (aviso) por la WAN para alertar a la otra parte de la introducción de una orden o confirmación cada vez que se produjese. ¿Por qué no enviar la transacción entera en vez de sólo el trigger?
Siguiendo otro enfoque, los socios podrían sondear la base de datos periódicamente para detectar actividades nuevas no procesadas. Pero este método consume mucho ancho de banda. También se rechazó la utilización de replicación de bases de datos porque ambos socios comerciales necesitarían actualizar los datos y no podrían designar un único responsable de esta tarea.
El enlace SNA de la empresa con el AS/400 funcionó bien, pero se quiso investigar un método que pudiera reducir la tarea de los programadores de aplicaciones a la hora de hacer conexiones de redes. Después de todo, ellos no son expertos en redes. Así, se eligió contrastar el enlace SNA creado con Message Queue Server (MSMQ) de Microsoft y MQSeries de IBM.
Como estas herramientas garantizan la entrega de mensajes, resultan muy apropiadas para crear diálogos automatizados basados en transacciones; se encargan además de efectuar las conversiones entre los formatos de datos en función de las necesidades. Aunque ambas trabajaron bien y fueron fiables en el laboratorio, en general MQSeries proporcionó el mejor enlace de red entre los servidores Windows NT corporativos y el AS/400 del proveedor. Su establecimiento resultó más sencillo que el de MSMQ, sin requerir ningún tipo de administración adicional. Además, corre sobre múltiples sistemas operativos, mientras que MSMQ depende específicamente de NT.
Por el contrario, la utilización de MSMQ, integrado gratuitamente en Windows NT Server 4.0 Enterprise Edition y Windows 2000 Server, fue complicada, ya que exige la instalación y configuración de otros tres componentes: Microsoft Transaction Server, SNA Server y SQL Server. MSMQ almacena información sobre colas (pero no los mismos mensajes, que residen en ficheros mapeados en memoria) en SQL Server. Se decidió usar además el componente opcional COM Transaction Integrator (COMTI) for CICS, para proporcionar acceso transaccional al ordenador AS/400 del proveedor de piezas. COMTI consiste en un conjunto de herramientas de desarrollo y servicios run-time que tratan las transacciones SNA y la lógica del negocio como componentes COM que c
Para crear un modelo ideal de extranet dedicada a soportar la cadena de suministro, se eligió el caso ficticio de un fabricante de automoción. A partir de aquí, se simularon dos escenarios extranet comunes: un enlace con un proveedor de misión crítica (un suministrador de piezas de automóviles) y otro con un proveedor menos fundamental para el negocio (un vendedor de material de oficina). Tres eran los objetivos: crear un enlace de red fiable tanto en hardware como en software, dar la seguridad apropiada y asegurar la integridad de los datos.
CONEXIONES DE RED
¿Qué medio de soporte de las transacciones con un socio comercial es el mejor, una línea alquilada, Frame Relay o una VPN basada en Internet? La respuesta dependerá de la criticidad que ese enlace tenga para la empresa. En el caso elegido de una planta de fabricación parece claro que no disponer en el momento oportuno de las piezas de automóvil necesarias podría convertirse en pérdidas significativas de dinero. El impacto sería muy distinto si lo que faltase fuera material de oficina.
Teniendo en cuenta estos condicionantes, para el enlace crítico se eligió un par de líneas alquiladas E-1 (2 Mbps) de dos operadores diferentes, lo que asegura una máxima disponibilidad. Para asegurarse un servicio continuado se probaron dos herramientas de balanceo de cargas, Microsoft Windows Load Balancing Service y Lightspeed Systems Total Control for E-Commerce IPMagic, para conmutar instantáneamente a la segunda línea cuando falle la primera. Ambas funcionaron perfectamente.Esta solución es cara en su conjunto, pero permite garantizar una fiabilidad del 99,9%.
Una alternativa más barata a la solución adoptada, también muy efectiva, consiste en contratar un par de enlaces Frame Relay a dos operadores diferentes. Sin embargo, se optó por las líneas alquiladas debido a que permitía utilizar hardware más sencillo y comprar DSU/CSU de diferentes fabricantes. A pesar de los obvios ahorros de costes, se rechazó la idea de usar una red privada virtual (VPN) basada en Internet porque añadía complejidad en la gestión y mayores riegos de seguridad, al tiempo que proporciona un rendimiento poco fiable.
Para el enlace con los suministradores de material de oficina –menos crítico– la alternativa VPN sí resultaba adecuada, ya que si Internet falla el impacto sobre el negocio no sería fundamental. Así, se creo una VPN de bajo ancho de banda entre la empresa y dichos suministradores.
GESTION DE ENLACES
Establecer los niveles de servicio y decidir quiénes serían los responsables de monitorizar el enlace con las firmas de piezas de automóvil fueron importantes pasos en el desarrollo del proyecto. Para mantener una fiabilidad del 99,9%, cada enlace E-2 se dedicó a soportar pedidos de piezas de automóvil, sin correo electrónico ni voz sobre IP (VoIP). Debido a su fiabilidad y su fácil configuración, se eligió VitalSuite, de Lucent, para monitorizar la WAN.
La negociación con un socio comercial para soportar comunicaciones TCP/IP no debería ser un problema, dada la popularidad de estos protocolos, fácilmente encaminables. Con todo, se prefirió complicar ago más la experiencia de laboratorio, estipulando que el suministrador de piezas de automoción utilizara un AS/400 y la arquitectura SNA de IBM.
Para conseguir los objetivos iniciales marcados, se concluyó que la mejor solución al problema que suponía utilizar niveles de transporte dispares era diseñar la aplicación con Advanced Program-to-Program Communications (APPC, también conocido como LU 6.2) para enviar y recibir transacciones. Y, a pesar de que se intentó por todos los medios complicar la situación, el diseño y administración del enlace APPC fue un juego de niños.
La única dificultad real apareció a la hora de diseñar el diálogo automatizado para que fuera tolerante a fallos imprevistos en la conexión, de modo que siempre se asegurase que las órdenes de pedidos llegasen a su destino. La intención era considerar a cada grupo transaccional de mensajes como un átomo, es decir, que la aplicación procesase solamente transacciones completas. También fue sencillo configurar un par de routers Cisco 4700, uno en la planta de ensamblaje y otro en las instalaciones del suministrador de piezas, para comunicar los paquetes SNA a través del enlace WAN.
Se rechazó la idea de usar una base de datos relacional como interfaz entre la planta de fabricación y el suministrador de piezas. Aunque insertar órdenes y confirmaciones en una base de datos compartida no tiene complicaciones, cada socio podría necesitar enviar un trigger (aviso) por la WAN para alertar a la otra parte de la introducción de una orden o confirmación cada vez que se produjese. ¿Por qué no enviar la transacción entera en vez de sólo el trigger?
Siguiendo otro enfoque, los socios podrían sondear la base de datos periódicamente para detectar actividades nuevas no procesadas. Pero este método consume mucho ancho de banda. También se rechazó la utilización de replicación de bases de datos porque ambos socios comerciales necesitarían actualizar los datos y no podrían designar un único responsable de esta tarea.
El enlace SNA de la empresa con el AS/400 funcionó bien, pero se quiso investigar un método que pudiera reducir la tarea de los programadores de aplicaciones a la hora de hacer conexiones de redes. Después de todo, ellos no son expertos en redes. Así, se eligió contrastar el enlace SNA creado con Message Queue Server (MSMQ) de Microsoft y MQSeries de IBM.
Como estas herramientas garantizan la entrega de mensajes, resultan muy apropiadas para crear diálogos automatizados basados en transacciones; se encargan además de efectuar las conversiones entre los formatos de datos en función de las necesidades. Aunque ambas trabajaron bien y fueron fiables en el laboratorio, en general MQSeries proporcionó el mejor enlace de red entre los servidores Windows NT corporativos y el AS/400 del proveedor. Su establecimiento resultó más sencillo que el de MSMQ, sin requerir ningún tipo de administración adicional. Además, corre sobre múltiples sistemas operativos, mientras que MSMQ depende específicamente de NT.
Por el contrario, la utilización de MSMQ, integrado gratuitamente en Windows NT Server 4.0 Enterprise Edition y Windows 2000 Server, fue complicada, ya que exige la instalación y configuración de otros tres componentes: Microsoft Transaction Server, SNA Server y SQL Server. MSMQ almacena información sobre colas (pero no los mismos mensajes, que residen en ficheros mapeados en memoria) en SQL Server. Se decidió usar además el componente opcional COM Transaction Integrator (COMTI) for CICS, para proporcionar acceso transaccional al ordenador AS/400 del proveedor de piezas. COMTI consiste en un conjunto de herramientas de desarrollo y servicios run-time que tratan las transacciones SNA y la lógica del negocio como componentes COM que c
