Presentación de BizTalk como solución ENCAMINA

Presentación de BizTalk como solución ENCAMINA

a la integración de sistemas (EAI+B2B)

Presentación corporativa 2

Índice

• Un caso de éxito• ¿Quién es Canelafoods?• Introducción a CanelaConecta• Requisitos de la solución• Arquitectura lógica• Subsistemas• Arquitectura técnica• Módulos• Elementos de comunicación• Ejemplos de coordinación• Ejemplo de proceso• Interfaces de usuario• Entorno tecnológico• Arquitectura física• Ejecución del proyecto• Referencias BizTalk de ENCAMINA


Un caso d e éxito: CanelaFoods

Axapta

Web corporativoeCommerce

Call CenterAgentes comerciales

• Canelafoods es una compañía del grupo SCH, dedicada a la distribución especializada y con una gran vocación de servicio, multicanal y nacional.

• Ha requerido, y obtenido, un gran nivel de automatización y un rápido despliegue para cubrir sus expectativas y compromisos de negocio.

• ENCAMINA ha prestado servicios de consultoría y ha ofrecido soluciones adaptadas y orientadas al proceso, en todo lo concerniente al frontal de la empresa:

– Desarrollo de aplicativo de gestión de CallCenter (eService), basado en Relaziona.

– Desarrollo de sistema distribuido de soporte a la venta (SFA)

– Responsables del web corporativo– Consultoría de procesos CRM– Desarrollo de aplicación web transaccional de

ventas (eCommerce) e integración con el ERP Axapta.

– Intranet basada en MS SharePoint Server– Y además...CanelaConecta


Misión y objetivos de CanelaConecta

• Contexto: CanelaFoods, apoyado por ENCAMINA, ha desarrollado el concepto de CanelaConecta, como compendio de procedimientos y herramientas altamente eficientes, para facilitar el proceso de compra a sus clientes, sea cual sea su contexto tecnológico, y automatizar el de venta del propio Canelafoods.

• Las soluciones que componen CanelaConecta son:– CanelaInicia: Los clientes trabajan intercambiando ficheros MS Excell, completados

manualmente.– Canela Web: Los clientes trabajan con una aplicación web transaccional con gran funcionalidad.– Canela Integra: Los clientes usan sus aplicaciones especializadas del mundo HORECA y estas

se integran con los sistemas de Canelafoods de forma transparente a los usuarios.– Canela E2E: Los clientes trabajan con sus aplicaciones ERP y estas se integran con los sistemas

de Canelafoods de forma automática y transparente al usuario.

Esta presentación se basa sobre la dos últimas, pero existe coherencia, compatibilidad y cierto grado de integración entre todas ellas.


Requisitos de la solución

• REQUISITOS DE CLIENTE FINAL– Solicitar Catálogo específico de cada establecimiento (con sus código, precios y descripciones)

– Solicitar de pedido de compra (de venta para Canelafoods)– Ser confirmado por su solicitud de pedido (tener feedback rápido de su transacción)– Recibir albarán electrónico o preaviso de entrada (para facilitar la operativa de recepción)

• REQUISITOS DE ADMINISTRADOR– Crear nueva organización y establecimientos fácilmente.– Procesos de auditoría y control para gestionar todo el sistema– Parada y reinicio del sistema sin pérdida de transacciones ni datos.

• REQUISITOS NO FUNCIONALES– Compatibilidad con GPWEB (el sistema web interactivo debe estar integrado)– Agrupación de datos (todos los sistemas deben convivir y compartir el especio de datos y reglas

de negocio)– Usabilidad para el cliente final (el usuario final no es un experto de TI)– Seguridad– Concurrencia– Gestión simplificada


Arquitectura lógica

Descripción Mensajes

Pedidos Envío de un pedido desde el sistema de backoffice del horeca a Canelafoods.

Confirmación pedidos

Exportación catálogo

Confirmación de la aceptación de un pedido recibido, desde el ERP de CF al sistema del horeca (puede ser interno al sistema o ACK al comprador vía e-mail).

Exportación del catálogo desde el ERP de CF al sistema de compras del horeca (referencias, precios, unidades, etc.). Los catálogos deberán actualizarse periódicamente o cuando haya cambios en él. El catálogo debe existir inicialmente en el sistema del Cliente.

Información envío/ albarán

CF exportará la información de ítems enviados/ albarán al sistema de compras/ almacén del horeca.

En el siguiente cuadro se describe la interacción a cubrir entre los sistemas de CanelaFoods y sus clientes:

ConectorCanela

SistemaBackofficeen Horeca

FrontBackOfficeCanelaInfo envío/ albarán electrónico

Pedidos

Modificación catálogo

Confirmación pedidos (email) SistemasCF

Catálogo

Confirmación pedidos

Info envío

Input manual

Interfase

Solicitudde pedidos

Actualizaciónalbarán

Alta deproductos CF

BackOfficeCliente


Subsistemas

• ERP Axapta: Sistema central de gestión de Canelafoods. Es el destino final de los pedidos de compra (que entran como pedidos de venta) y origen de los catálogos de productos y albaranes. En él reposan todas las reglas de negocio, todos los datos y soporta todos procesos principales de los usuarios de CanelaFoods.

– Recibe peticiones de GPWEB y las contesta– Emite peticiones a BizTalk

• GPWeb: Sistema que inicialmente permitía la introducción de pedidos de compra por el canal WEB y por medio de las hojas Excel de pedido, y la extracción de el catálogo específico de productos para un cliente dado. Se considera la entrada común (pero síncrona, rígida y unidireccional) a todo el mundo exterior.

– Recibe solicitudes de servicio del mundo exterior (BizTalk y otros) – GPCOM - SOAP– Recibe peticiones interactivas desde usuario web– Emite solicitudes a Axapta

• BizTalk Server: Middleware conformado por el servidor MS BizTalk y un entorno específico para comunicar a los sistemas de clientes externos y el de Canelafoods, por medio de GPWeb. Puede adaptar asíncronamente los sistemas heterogéneos (distintas lógicas de negocio, formatos, protocolos, canales de comunicación, etc.) de los variopintos clientes finales .

– Recibe solicitudes de clientes finales del mundo exterior– Emite servicio a los clientes finales del mundo exterior– Recibe peticiones desde Axapta

• Conector HORECA: sistema de cliente final que adaptará su sistema de trastienda u HORECA y sabrá hablarse con el BizTalk Server. Este subsistema es muy variable y corresponde a proyectos individuales.


Aquitectura TécnicaCANELA FOODS

ERP (Axapta)

SQL

MS BizTalk

Adaptador GPWEB

Mid

dle

wa

re B

IZT

AL

K

SQL

ASP

Intranet/ Internet

CO

M+

SO

AP

CO

M+

COM+

COMConnector de Axapta

HTTP / HTTPS

XML Web Services

Mensajes XMLMensajes XML

MS

MQ

MS Message Queue ServerC

OM

+

Sistema basado en:•MS BizTalk Server•MS Message Queue Services•Mensajes XML•Servicios accesibles mediante SOAP•Aplicaciones web mediante ASP sobre IIS•Aplicaciones y servicios mediante COM+•Base de datos MS SQL Server

Acceso interactivo vía navegador web

Acceso interactivo vía navegador web


Módulos

• Pasarela– Procesos generales (Orquestación BizTalk)

• Pedido, Albarán, Catálogo, Evento– Contexto e inicialización por establecimiento (COM+ a medida, ficheros INI, BD)– Fontanería de BizTalk (Servicios de Mensajería BizTalk, MS MQS y IIS)

• Organizaciones• Messaging Ports• Canales• Mensajes y Envelopes• Carpertas y directorios• Colas MSMQS• Conector SOAP a GPWEB (COM+ Proxy)

– Tracking• Adaptador

– Comunicación I/O (Servicio SOAP)– Reglas de negocio (GPCOM)

– Clase Usuario– Clase Pedido– Clase Catálogo– Clase Log

– GPWEB (aplicativo de usuario web)• ERP

– Albarán– IF_ACCUA


Elementos de comunicación

• Mensajes– Documentos XML

• Catálogo• Pedido y Albarán• Evento• Aviso• Log

– Otros (potencialmente posibles)• Ficheros TXT, CSV, ...

• Canales de comunicación observados– Recipientes

• Carpeta FTP (para la recogida y/o entrega de ficheros)• Directorio (para la recogida y/o entrega de ficheros)• Páginas ASP (para la solicitud de un catálogo)• Colas de mensajes

– Públicas (para la solicitud de eventos)– Privadas (para la gestión de mensajes internos a BizTalk)

• Mensajes de correo electrónico (para enviar avisos y alarmas)

– Protocolos• HTTP/HTTPS (para servicios SOAP y páginas ASP)• SMTP (para el envío de mensajes de correo electrónico)• S.O. (MS MQS para la comunicación entre sistemas internos)


Ejemplo de coordinación I

ERP (Axapta)

SQL

Orchestration Adaptador GPWEB

SQL

ASP

Intranet/ Internet

CO

M+

SO

AP

CO

M+

COM+


HTTP / HTTPS

XML Web ServicesMensaje x

Mensajes XML

MS Message Queue Server

CO

M+

2

3

6, 85, 9

7Recive()

preproceso

Solicitud y retorno servicios

MS BizTalk

Messagins Services

1

410

1. Las funciones Receive() poolean continuamente la llegada de mensajes a carpetas y/o colas MS MQS2. Los mensajes se encolan en una cola privada del servidor donde está MS BizTalk o se lanzan directamente contra el proceso XLANG directamente.3. Un proceso atiende los mensajes genéricos encolados, los analiza mínimamente y los reencamina a la cola privada específica más adecuada o llama al XLANG

oportuno. Si este mensaje necesitase algún tipo de proceso, ej. Creación de múltiples mensajes encadenados, se realizaría en este punto.4. Un proceso específico recibe o recoge los mensajes y los trata adecuadamente.5. Mediante servicios externos se procesa el evento.6. El servidor GPCOM atiende peticiones SOAP y procesa todo lo que le concierne7. GPWEB y Axapta intercambian solicitud y respuesta concreta al servicio demandado.8. Se reponde al punto 69. Se entrega uno o más mensajes al servicio demandado en el punto 5.10. Se termina de ejecutar el servicio, probablemente accediendo al mundo exterior del cliente.


Ejemplo de coordinación II

ERP (Axapta)

SQL

MS BizTalk Adaptador GPWEB

SQL

ASP

Intranet/ Internet

CO

M+

SO

AP

CO

M+

COM+


HTTP / HTTPS

XML Web Services

Mensaje XML (Evento)

Mensajes XML

MS Message Queue Server

CO

M+

1

4

3

2

6, 85, 9

7

10

evento

encolado

preproceso

proceso

Solicitud y retorno servicios

1. Algo o alguien genera o declara una solicitud hacia el mundo exterior desde Axapta2. Los mensajes de evento se encolan en una cola pública del servidor donde está MS BizTalk3. Un proceso atiende los mensajes genéricos encolados, los analiza mínimamente y los reencamina a la cola privada específica más adecuada. Si este mensaje

necesitase algún tipo de proceso, ej. Creción de múltiples mensajes encadenados, se realizaría en este punto.4. Un proceso específico lee los eventos específicos (albarán disponible, entragar factura electrónica, enviar catálogo, etc.) y los trata adecuadamente.5. Mediante servicios externos se procesa el evento.6. El servidor GPCOM atiende peticiones SOAP y procesa todo lo que le concierne7. GPWEB y Axapta intercambian solicitud y respuesta concreta al servicio demandado.8. Se reponde al punto 69. Se entrega uno o más mensajes al servicio demandado en el punto 5.10. Se termina de ejecutar el servicio, probablemente accediendo al mundo exterior del cliente


Ej.: proceso: Pedido de compra

Función deRecepción de

FicherosRecogida de la

petición

BizTalk MessagingPuerto al Nuevo

XLANGFichero

PedidoCanela.xml

Orchestration

Recibir Petición

Comienzo

Fin

Procesar Orden dePedido

PeticiónVálida?

Si

No

No

Enviar Aviso

BizTalk Messaging

Channel Manual para el Envio de Avisos

Formato XSLAviso Canela

Puerto a la Cola deAvisos

Aviso XMLS

BizTalk Messaging

Channel para la Petición al ComponenteProxy del Servicio

Puerto al ServicioSOAP

Pedido Canela

Cola de Envío,protocolo SMTP

o File://

HTTP

Servicio SOAP

HTTP

1. El cliente crea una nueva petición en fichero plano y lo deja en una carpeta. BizTalk Messaging lo coge y procesala petición.

2. La lógica de negocio representada en el“orchestration” determina qué hacer con lapetición.

3a. La petición no es válida. La petición se reenvía al responsablecorrespondiente con el tipo y formato de aviso adecuado.

3b. La petición está aprobada. Enviar la orden de Pedido a GPWeb vía Internet con elcontexto del peticionario.

4. El servidor Soap procesa la orden a través de su servicio ProcesarPedido y genera el albarán orespuesta oportuna. Luego devuelve la respuesta via internet de vuelta al Puerto de servicio Proxy.

Channel para una Petición en FicheroPlano a una Petición de Pedido XML

Fichero Plano Fichero XMLMap

Pedido Canela

GPWeb

ServidorSOAP Map Contexto

+

BizTalk Messaging

Channel para la Petición al ComponenteProxy del Servicio

Puerto al ServicioSOAP

RespuestaPedido Canela

RespuestaPedido Canela

HTTP

HTTP

PeticiónProcesada

OK?

Si

Enviar Alerta


Interfaces de usuario

• En la medida de lo posible, todos los interfaces serán tipo web, cuando tiene que intervenir el usuario o cliente final. • Para los procesos operativos el interfaz será aquel que se ajuste mejor al sistema HORECA final, pero en cualquier

caso tenderá a ser transparente al usuario.• Para las operaciones de Administrador el interfaz será tanto web,

– GPWEB Control• Permite gestionar los usuarios y sus permisos• Permite conocer el estado de los pedidos solicitados a Axapta, e incluso relanzarlos.• Permite acceder a los logs de errores de los pedidos.

– GPWEB• El existente actual que permite acceder a los pedidos anteriores en sus diferentes estados, por establecimiento.• Permite acceder a los logs de errores de los pedidos.

– GPWEB BizControl• Permite conocer el pedido traceado de un pedido por el código de pedido dado por el cliente o por el número de pedido dado por Canelafoods

(Axapta).– BizTalkDocumentTracking:

• Aplicativo web accesible desde la parte de control de GPWEB (debajo del marco de control ), pero que corre en el servidor web de la máquina de BizTalk y que permite el seguimiento, trazado y control del estado de los mensajes intercambiados entre las distintas organizaciones y Canelafoods. Según los procedimientos estándares del aplicativo.

– CanelaBiz interface• Acceso por el Administrador del sistema a la entidad de establecimientos asociados a un Organization, para configurar sus colas de trabajo. Alta,

edición y baja

• como el de los propios aplicativos intervinientes para las muchas configuraciones:– BizTalk Messaging Services – BizTalk Administration– BizTalk Orchestration– BizTalk Editor– BizTalk Mapper– BizTalk Document Tracking


Entorno tecnológico

• Sistema operativo MS Windows 2000 Server

• Middleware: MS Biztalk Server 2002

• Servidor web: IIS 5.0

• ERP: Navision Axapta 2.5

• Base de datos MS SQL 2000 SP2

• COM Conector de Axapta

• Tecnología COM+

• Desarrollo con el lenguaje de programación MS Visual Basic 6.0 y VB Script

• Lenguaje de intercambio de datos: XML v1.0

• Lenguaje de publicación web: SOAP 2.0

• Librería de parseo XML Micrsoft MSXML v3


Arquitectura física

Servidor BizTalkSDC1PRO006

Servidor GPWEB-GPCOMServidor AOS2SDC1PRO013

DB GPWEBBD BIZTALKCluster BD

Intranet

Internet

WWW ServerFTP Server

SDC1PRO007

FirewallFPro002

Carpetas FTP de clientes finalesPásginas ASP de activación

Páginas web activas ASPCOMConnector Axapta

Servicios SOAP

Comunicaciones FTP, HTTP y SMTPClientes

Páginas web activas ASP (BIzControl)Gestión BizTalkCOM+ Proxy (SOAP)

MSMQS

Servidor AOS1SDC1PRO008

MSMQS


Ejecución del proyecto

• Un vez construida la plataforma de CanelaConecta (apróx. 6 meses) se comenzaron a desarrollar microsoluciones específicas para los sistemas de usuario final (1 a 2 meses por conector). En otros casos, una configuración del sistema final ha sido suficiente, puesto que ya era capaz de emitir mensajes en algún formato y lógica.

• Entre tanto, se han ido implementando soluciones intermedias de urgencia, bien haciendo uso de infraestructura que aportaba el sistema web, bien utilizando de forma directa o indirecta el sistema XML Web Services – SOAP implementado como soporte al proyecto global.


Referencias BizTalk de ENCAMINA

• Diseñadores, desarrolladores e implementadores del sistema CanelaConecta de Canelafoods.

• Integración MS BizTalk – MS Commerce Server 2000 para el proyecto de marketplace TodoHospital.com

• Soporte especializado a Deloitte-Watermark en la infraestructura Biztalk para su proyecto de integración Parques Reunidos (TPVs de los parques con ERP de la central)

• Desarrollo de mensajes I/0 para el proyecto de Caixa Manresa, liderado por Infodesa.

• ENCAMINA ha desarrollado soluciones de integración a medida con otros sistemas variopintos con soluciones de tipo VB/COM+, PL/SQL, intercambio de ficheros planos, SOAP – XML Web Services, etc.

Introducción

Área para el logotipo del cliente, NUNCA excederá en tamaño al

de ENCAMINA

Presentación de BizTalk como solución ENCAMINA

Documents

Transcript of Presentación de BizTalk como solución ENCAMINA