MXPA00012050A - Comunicacion de flujo de trabajo - Google Patents

Abstract

Se proporciona un método implementado por computadora para la comunicación de flujo de trabajo. el método incluye los siguientes pasos. primero, son sujetados uno o más flujos de trabajo. Despúes un administrador de evento es disparado sobre la ocurrencia de un evento predefinido en el flujo de trabajo. finalmente, un mensaje basado en el evento es formulado y enviado a un grupo fijo.

Description

COMUNICACIÓN DE FLUJO DE TRABAJO CAMPO TÉCNICO DE LA INVENCIÓN Esta invención se refiere en general al campo de la cadena de suministro, de la empresa y del sitio de planeación, y más particularmente, a un método para la comunicación del flujo de trabajo.

ANTECEDENTES DE LA INVENCIÓN Las aplicaciones y ambientes de cadena de suministro, de empresa y de sitio de planeación son ampliamente usados por las entidades fabricantes para el soporte de decisión y para ayudar a las operaciones de administración. Los ambientes de soporte de decisión para la cadena de suministro, de la empresa y del sitio de planeación han evolucionado de ambientes monolíticos de dominio único a ambientes monolíticos de dominios múltiples. Las aplicaciones de software de planeación convencionales están disponibles en un amplio rango de productos ofrecidos por varias compañías. Estas herramientas de soporte de decisión permiten a las entidades operaciones de fabricación complejas de administración más. eficiente. Sin embargo, las cadenas de suministro están generalmente caracterizadas por ambientes de planeación múltiples, distribuidas y heterogéneos. Por tanto, hay limites a la efectividad de los ambientes convencionales cuando se aplican al problema de la planeación de la cadena de suministro debido a las arquitecturas de aplicación monolíticas. Además, estos problemas son exacerbados cuando no hay un "propietario" de la cadena de suministro completa.

Es deseable para el siguiente paso evolucionarlo para los ambientes de planeación el establecer una arquitectura heterogénea de dominios múltiples que soporte dominios múltiples de expansión de productos, así como productos y motores múltiples de expansión. La integración de los varios ambientes de planeación en una solución sin costura puede permitir la planeación de cadena de suministro entre empresa y entre dominio. Además, una función importante proporcionada por algunas aplicaciones de planeación es la optimización del ambiente de objeto más bien que el simplemente las transacciones de seguimiento. En particular, la familia de productos RHYTHM disponible de i2 TECHNOLOGIES proporciona una funcionalidad de optimización. Sin embargo, ccn respecto a la planeación en el nivel de cadena de suministre de empresa, muchas aplicaciones convencionales, tal como aquellas disponibles de SAP, usan motores de planeación de recurso de empresa (ERP) y no proporcionan la optimización.

El éxito o falla de una empresa puede depender en gran extensión de la calidad de la realización de decisión dentro de la empresa. Por tanto, el software de soporte de decisión, tal como la familia de productos RHYTHM de 12 TECHNOLOGIES, que soportan la realización de decisión óptima dentro de las empresas puede ser particularmente importante para el éxito de la empresa. En general, las decisiones óptimas son relativas al dominio del soporte de decisión en donde el dominio es la extensión del "mundo" considerado para llegar a la decisión.

Por ejemplo, la decisión que está siendo hecha puede ser qué tanto de un artículo dado una fábrica puede producir durante un período de tiempo dado. La respuesta "óptima" depende del dominio de la decisión. El dominio puede ser, por ejemplo, justo la fábrica misma, la cadena de suministro que contiene la fábrica, la empresa completa o la cadena de suministro de empresas múltiples. (Estas últimas dos pueden ser consideradas conociendo los dominios más grandes o los dominios múltiples) . Típicamente, entre más grande es el dominio del soporte de decisión, más óptima será la decisión. Consecuentemente, es deseable para el software de soporte de decisión el cubrir aún dominios más grandes en el proceso de realización de decisión. Una solución es el diseñar flujos de trabajo los cuales pueden ser un juego de actividades unidas por flujos de datos que juntos logran algunas tareas. Los flujos de trabajo pueden ser ejecutados sobre uno o más motores de flujo de trabajo sobre una o más empresas. Al correr los flujos de trabajo sobre diferentes motores y diferentes empresas la capacidad para enviar mensajes entre flujos de trabajo o entre un flujo de trabajo y una aplicación o usuario. Lo que se requiere es un método para la comunicación que está descrito que proporcione ventajas sobre los ambientes de cadena de suministro, de empresa y de sitio de planeación convencionales.

Se proporciona un método implementado por computadora para la comunicación del flujo de trabajo. El método incluye los siguientes pasos. Primero, uno o más de los flujos de trabajo son ejecutados. Después es disparado un administrador de evento sobre la ocurrencia de un evento predefinido en el flujo de trabajo. Finalmente, un mensaje basado sobre el evento es formulado y enviado a un grupo fijo.

Una ventaja técnica de la presente invención es la de que la capacidad para enviar mensajes dentro y entre las empresas usando ya sea un paradigma de punto a punto o de suscripción/publicación. Las ventajas técnicas adicionales deben ser fácilmente aparentes a ur. experto en el arte de las siguientes figuras, descripciones y reivindicaciones.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Un entendimiento más completo de la presente invención y de las ventajas de la misma puede adquirirse mediante el referirse a la siguiente descripción tomada en conjunción con los dibujos acompañantes en los cuales los números de referencia indican características de referencia, y en donde: La figura 1 es un diagrama de incorporación de una arquitectura implementada por computadora que puede soportar la colaboración de empresas.

La figura 2 es un diagrama de una incorporación de componentes de un sistema de colaboración global; La figura 3 es un diagrama de un sistema de colaboración global de la figura 2 en donde ciertos elementos de software que tienen módulos particulares están resaltados; La figura 4 es un diagrama de bloque de una incorporación de un sistema que permite la colaboración dentro de empresas para la realización de decisiones óptima; La figura 5 es un diagrama de bloque de la incorporación del uso de un espacio de trabajo de colaboración global ; La figura 6 es un diagrama de una incorporación de un ciclo de vida para una colaboración; A-*fe- ~~*-- La figura 7 es un diagrama de situaciones en donde el software común está presente en ambos lados de la relación y en donde no lo está; La figura 8 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a radio y de eje a red; La figura 9 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a eje; La figura 10 es un diagrama de una incorporación del diseño de un flujo de trabajo de entre empresas que incluye la formación de parámetros sobre grupos; La figura 11 es ur. diagrama de una incorporación de la administración de cambio mediante el modificar un diseño de un flujo de trabajo; La figura 12 ilustra un diagrama de bloque de una incorporación del sistema que incorpora la comunicación de flujo de trabajo; La figura 13 es un diagrama de bloque de una incorporación del administrador de evento; La figura 14 ilustra un diagrama de bloque de una incorporación de un modelo de comunicación de publicación/suscribir; La figura 15 es un diagrama de una incorporación de integración de un flujo de trabajo con el mundo exterior; La figura 16 es un diagrama de una incorporación de un flujo de datos que corre en una actividad única; La figura 17 es un diagrama de una incorporación de una división de flujo de datos a través de actividades múltiples; La figura 18 es un diagrama de bloque de una incorporación de un modelo de datos común basado sobre el modelo de transformación; La figura 19 es un diagrama de una incorporación de una transformación directa; La figura 20 es un diagrama de una incorporación de niveles de transformación y de acceso diferentes; y La figura 21 es un diagrama de una incorporación de la sustitución de un motor de eje por un motor de radio dentro de una colaboración.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La mejora de los procesos de soporte de decisión involucra la expansión para proporcionar un nivel de empresas y un soporte de decisión de nivel de empresas múltiples para la realización de decisiones óptimas. Técnicamente y conceptualmente, el proporcionar un soporte de decisión de nivel de empresas múltiples y de nivel de empresa difiere del proporcionar soporte de decisión de nivel de fábrica y de nivel de cadena de suministro. Las razones para ésto pueden ser que, en las situaciones de dominios múltiples (tal como unidades de negocios dentro de una empresa o empresas múltiples) , los diferentes dominios frecuentemente operan diferente software de soporte de decisión. También, en las situaciones de dominios múltiples, un dominio generalmente no puede obligar a otro dominio a hacer una decisión en particular. En otras palabras, el soporte de decisión óptima en este ambiente frecuentemente requiere el ser llevado a cabo en un ambiente negociado en oposición a uno coercitivo.

El proporcionar un soporte de decisión en situaciones de dominio múltiples puede lograrse mediante el perseguir un acercamiento de colaboración para el soporte de decisión más bien que uno coercitivo. Varias tecnologías de procesamiento de comunicación y distribuidas pueden usarse para implementar tal ambiente, incluyendo el internet, la red, JAVA, XML, CORBA, etc., lo cual ayuda a hacer posible una realización de decisión colaborativa a gran escala. Pronto estarán disponibles los productos de 12 TECHNOLOGIES que permitirán un acercamiento de colaboración al soporte de decisión, incluyendo el administrador de colaboración RHYTHM-GLOBAL (GCM) y el diseñador de colaboración RHYTHM-GLOBAL (GCD) .

Sistema de Colaboración y Componentes de Proceso La figura 1 es un diagrama de una incorporación de una arquitectura implementada por computadora que puede soportar la colaboración de empresas. Como se mostró, una arquitectura de soporte de decisión global puede ser construida sobre el enlace subyacente, la mensajería global, la visión y los componentes de almacén de información. La colaboración puede entonces involucrar un diseñador de colaboración global (GCD) y un administrador de colaboración global (GCM) soportado por la arquitectura de soporte de decisión. El diseñador de colaboración global puede ser usado para diseñar y poner en instancias las colaboraciones, y el administrador de colaboración global puede ser usado para correr las colaboraciones. En este esquema, las colaboraciones pueden ser mencionadas como módulos y pueden tener versiones.

La figura 2 es un diagrama de una incorporación de componentes de un sistema de colaboración global. Como se mostró, el sistema puede permitir que colabore un eje de empresa 2 con una empresa radio 4 y una empresa red 6. La empresa eje 2 y la empresa radio 4 cada una incluyen un administrador de colaboración global 8. Los administradores de colaboración global 8 están acoplados a y se comunican con los espacios de trabajo de comunicación global internos respectivos 10. Un espacio de trabajo de colaboración global externa 12 proporciona unos medios para compartir información entre la empresa eje 2, la empresa radio 2 y la empresa red 6. La empresa eje 2 también puede colaborar a través de un procesador de intercambio de datos electrónico (EDI) 14 con un red agregada de valor (VAN) . Además, la empresa eje 2 puede comunicarse y colaborar con otras empresas eje usando un bus de mensaje global 15.

En operación, el controlador primario de la colaboración puede ser el motor de espacio de trabajo de colaboración global 8 de la empresa eje 2. La relación de eje a eje puede ser facilitada por el bus de mensaje global 15, y las relaciones de eje a radio y de eje a red pueden ser facilitadas por el espacio de trabajo de colaboración global externa (GCW) 12. Como se mostró, una empresa eje 2 puede generalmente tener un espacio de trabajo de colaboración global interno 10 y un espacio de trabajo de colaboración global externo 12. El espacio de trabajo de colaboración global interno 10 puede ser usado para compartir e intercambiar datos con las interconexiones de usuario internas así como con el procesador de intercambio de datos electrónico 14. El espacio de trabajo de colaboración global 12 puede ser usado para compartir e intercambiar datos con las empresas radio 4 y las empresas red.

Por seguridad, el espacio de trabajo de colaboración global externo 12 puede ser instalado en un DMZ o afuera de una pared en contra de incendios corporativa de una empresa eje 2. De esta manera no necesitan hacerse conexiones directas desde el exterior a la red corporativa protegida de la empresa eje 2. El espacio de trabajo de colaboración global puede aceptar por ejemplo, las conexiones II0P,HTTP, y HRRPS . En particular las últimas dos conexiones son útiles para hacer puente entre configuraciones de pared en contra de incendios existentes. De esta manera, no es necesaria una configuración de pared en contra de incendios sobre cualesquier el cliente (nodo de radio o nodo de e]e) o el servidor (nodo eje) lo cual puede hacer la solución más rápidamente desplegable.

La figura 3 es un diagrama de sistema de colaboración global de la figura 2 en donde ciertos elementos de software que constituyen los módulos particulares están resaltados. Como puede verse, el software para el módulo de administrador de colaboración global puede estar presente en los siguientes lugares: en el motor de eje 8, en el motor de radio 8, en la interconexión de usuario de eje-usuario (VI), en la interconexión de usuario radio-usuario y en la interconexión de usuario de eje-nodo. Adicionalmente, el módulo puede comunicarse con las aplicaciones nativas 17 sobre la empresa eje 2 y la empresa radio 4. Las comunicaciones con las aplicaciones nativa 17 pueden ser ya sea sincrónicas (línea de punto) o asincrónicas (líneas sólidas) . La comunicación asincrónica con las aplicaciones nativas 17 puede ser facilitada por el espacio de trabajo de colaboración global interno 10, como se mostró, además, una base de datos de serie global (GSDB) puede estar presente sobre el lado empresa eje 2.

La figura 4 es un diagrama de bloque de un sistema indicado generalmente en el punto 16, que permite la colaboración dentro y entre las empresas para una realización de decisión óptima. Como se mostró, un sistema 16 incluye un nodo de eje 8 el cual puede ser un proceso dentro de un motor de eje que ejecuta sobre un sistema de computadora. El nodo de eje 18 está acoplado a y se comunica con un nodo de radio 20 el cual también puede ser un proceso dentro de un motor de eje que se ejecuta sobre un sistema de computadora. Como se mostró, el nodo de radio 20 puede estar afuera de un límite de empresa 22 de el nodo de eje 18. El nodo de eje 18 también puede ser acoplado a y comunicarse con una pluralidad de nodos de radio 24 los cuales pueden ser procesos dentro de un motor de radio que ejecuta en uno o más sistemas de computadora. El nodo de eje 18 puede además estar acoplado a y _¿¡§¡^^áife comunicarse con una pluralidad de nodos de red 26 los cuales pueden ser procesados dentro de un explorador de red ejecutando sobre un sistema de computadora. Además el nodo de eje 18 está acoplado a y se comunica con el sustituto EDI (Intercambio de Datos Electrónicos) 28 el cual puede proporcionar una compuerta a los sistemas de intercambio de datos electrónico.

Los motores de eje y los motores de radio junto con un espacio de trabajo de comunicación global, pueden ser las entidades primarias de un administrador de colaboración global. En este ambiente, un motor de eje es el controlador primario de la colaboración. El motor de eje puede coordinar a ambas la colaboración global así como las colaboraciones locales. Las colaboraciones globales son aquellas que abarcan nodos de eje 18, los nodos de radio 20 y 24 y los nodos de red 26. Un colaboración local puede correr sobre un eje de papel único o un grupo de radio/radio. Estas colaboraciones pueden ser distribuidas, pero permanecer dentro de una empresa única. Los motores de eje también pueden ser coordinados con interconexiones de usuario y eje (Ul) así como el procesador de red de valor agregado-intercambio de datos electrónico de un sustituto de datos electrónico 28. En una incorporación, los motores de eje son motores de hilado múltiple que pueden coordinar simultáneamente colaboraciones múltiples así como versiones múltiples de la misma colaboración. Además, los motores de eje pueden cargar dinámicamente y ejecutar colaboraciones.

Un motor de radio puede también operar para iniciar una colaboración. En este ambiente, a diferencia de un motor de eje, un motor de radio no es una entidad independiente.

En vez de ésto un motor de radio puede solo coordinar en conjunción con un motor de eje. Además, un motor de radio no puede coordinar con otros motores de radio u otros nodos de eje.

Como un motor de eje, un motor de radio puede ser de hilados múltiples y puede coordinar simultáneamente colaboraciones múltiples así como versiones múltiples de la misma colaboración. Los motores de radio también pueden ser cargados dinámicamente y ejecutar colaboraciones.

La figura 5 es un diagrama de bloque de una incorporación del uso de un espacio de trabajo de colaboración global 30. En la figura 5, el espacio de trabajo de colaboración global 30 proporciona la entidad primaria usada para compartir datos/objetos entre las entidades en la colaboración. Como se mostró el espacio de trabajo 30 puede ir.terconectar con los administradores de colaboración global (GCMs) 32, un sistema local 34, un servidor de red 36 y una interconexión de red 37 y las aplicaciones nativas 38. En general, los objetos pueden ser colocado en el espacio de trabajo de colaboración global 30 por una entidad y ser recuperados por otra entidad. La recuperación puede ser lograda ya sea mediante pregunta o mediante suscripción. De esta manera, el espacio de colaboración global 30 combina los atributos de una base de datos así como de un bus de mensaje.

El espacio de trabajo de colaboración global puede ser organizada como una jerarquía de ranuras las cuales pueden estar en memoria o ser persistente. Las ranuras también pueden ponerse en cola o ser regulares, y los permisos de grano fino pueden ser sujetados a cada ranura. Los permisos pueden ser firmados por usuario por operación. Las operaciones primarias pueden ser leer, escribir, tomar y suscribir.

Las ranuras en memoria retienen datos en la memoria volátil. La escritura y la recuperación de las ranuras en memoria es muy rápida pero se somete a la pérdida si el espacio de trabajo de colaboración global 30 se cae. Cuando se usa en las ranuras de memoria, el espacio de trabajo de colaboración global 30 puede ser considerado una base de datos de objeto en memoria segura y rápida, con capacidades de seguridad y mensajería. Las ranuras persistentes retienen sus datos en una almacén estable. La escritura y la recuperación de las ranuras persistentes es más lenta que para las ranuras en memoria, pero los datos no se pierden si se cae el espacio de trabajo de colaboración global 30.

La decisión en cuanto a usar las ranuras en memoria o persistente puede depender de la aplicación. El espacio -t¿i*-^- .w-, de trabajo de colaboración global 30 almacena los datos en la forma de objetos y puede almacenar objetos JAVA, objetos CORBA o un arreglo de BITE arbitrario, esto, acoplado con sus capacidades en memoria, hace al espacio de trabajo de colaboración global 30 apropiado como un mecanismo de compartir datos de alta velocidad entre otros motores en memoria orientados por objeto tal como el planeador de fábrica y el planeador de cadena de suministro de 12 TECHNOLOGIES.

Un diseñador de colaboración global (GCD) proporciona una herramienta para permitir a los diseñadores de colaboración el diseñar interactivamente, el poner en instancias y el desplegar colaboraciones que van a correrse usando el administrador de colaboración global. La salida del diseñador de colaboración global es un código que puede ser cargado automáticamente y ser corrido por el administrador de colaboración global . El diseñador de colaboración global puede permitir a los diseñadores el crear nuevas colaboraciones, recuperar colaboraciones existentes y colaboraciones de versión. El diseñador de colaboración global también puede permitir a los diseñadores el diseñar la red de eje y de radio para colaboraciones y diseño de los eventos y mensajes de la colaboración. El diseñador de colaboración global puede integrar una biblioteca de objeto estándar y una biblioteca de componente estándar para un uso fácil desde dentro del diseño de colaboración global. El diseñador de colaboración global puede ¡feaB_fe_Si3£_&s^-,,_,-_,------_,-_^^^ ser usado para crear flujos de trabajo de empresas múltiples sofisticados con sincronía a sincronía, su flujo de trabajo y divisiones o -divisiones, uniones-sincronización, divisiones-heterofundido, uniones-heterofundido, etc. Los flujos de trabajo globales y los flujos de trabajo locales pueden ambos ser creados. El diseñador de colaboración global puede proporcionar una verificación automática de las colaboraciones y la generación de código automático, cuyo código se corre por el administrador de colaboración global. El código generado puede ser editado manualmente si se desea. Además, el diseñador de colaboración global puede proporcionar la iniciación de una colaboración que incluye la generación de configuraciones de administrador de seguridad y configuraciones de espacio de trabajo de colaboración global .

La figura 6 es un diagrama de una incorporación de ciclo de vida para una colaboración. Core se mostró, en el paso, una colaboración puede ser diseñada usando el diseñador de colaboración global. Entonces, en el paso 46, una colaboración puede ser instanciada usando el diseñador de colaboración global. La colaboración instanciada puede ser entonces desplegada, en el paso 44, usando el diseñador de colaboración global y el administrador de colaboración global. Después del desplegado, la colaboración puede ser corrida usando el administrador de colaboración global en el paso 46. Subsecuentemente, una nueva instancia puede ser creada o una nueva versión de la colaboración puede ser creada. Para crear una nueva instancia, el flujo regresa al paso 42. Para una nueva versión, el diseñador de colaboración global puede ser usado en el paso 48 para modificar la colaboración.

La extensión del soporte de decisión de dominio único a el soporte de dominio múltiple puede ser complicado. En particular, la discusión siguiente describe un número de desafíos presentados por el soporte de decisión de dominios múltiples y las incorporaciones de cómo estos desafíos son examinados por el sistema presente en los procesos que permiten la colaboración dentro y entre las empresas para una realización de decisión óptima.

Heterogeneidad de la Representación Un problema con la colaboración es el puentear la heterogeneidad de representación a través de empresas. Antes de que pueda ocurrir exitosamente la colaboración, la heterogeneidad de representación a través de las empresas debe ser puenteada. Las empresas frecuentemente representan los mismos datos en maneras diferentes. Estas diferencias varían de diferencias semánticas a diferencias tecnológicas, a diferencias en nombres, etc. La solución obvia para puentear estas diferencias es la estandarización. Sin embargo, esto inmediatamente eleva el asunto sobre qué estándar debe convenirse. El presente sistema y el proceso evitan tal requerimiento.

Deberá notarse que puede haber tres categorías relevantes de estándar que requieren ser examinados. Estas tres categorías son: estándares de formato, estándares de transporte y est ndares semánticos. Los estándares de formato de refieren a los formatos tecnológicos los cuales los datos/objetos son codificados. Los ejemplos incluyen XML, las corrientes de la serie Java, las corrientes de la serie IIOP y el formato de intercambio de datos electrónico. Los estándares de transporte son usados para pasar datos, estos pueden incluir HTTP, IIOP, RMI , DCOM, FTP, las redes de valor agregado, los buses de mensaje asincrónico tal como MQSeries, etc. En tercer lugar los estándares semánticos son la forma en la cual el contenido semántico de los datos está descrito. Los ejemplos incluyen el intercambio de datos electrónico, el modelo de datos común 12 (CDM) .

Mediante el considerar los estándares en esta luz, puede surgir un entendimiento de los asuntos. Una mayoría de la confusión actual surge del hecho de que existen muchos estándares que cubren dos o más de las categorías arriba mencionadas y esas discusiones de los varios estándares falla en categorizar cual categoría está siendo discutida. Por ejemplo, el intercambio de datos electrónico es primariamente un estándar semántico, pero también típicamente implica un estándar de formato ( el formato de expediente de intercambio de datos electrónicos) y un transporte (una red agregada de valor) . Una vez que ésto es entendido, se hace claro que el estándar semántico de intercambio de datos electrónico puede ser separado de los otros dos. Por tanto, los objetos de intercambio de datos electrónico semántico puede ser codificado en otros formatos como las corrientes de serie Java y pueden pasarse sobre otros estándares de transporte tal como HTTP. Similarmente, XML es primariamente un estándar de formato que puede ser usado para codificar varios estándares semánticos. Están realizándose esfuerzos para codificar el intercambio de datos electrónico en XML.

Varios estándares de formato pueden ser soportados por el administrador de colaboración global presente, incluyendo XML el formato de intercambio de datos electrónico, las corrientes de serie Java (mencionadas como formato Java y no deben confundirse con el lenguaje Java o la plataforma Java) y las corrientes de serie IIOP. De éstos, en una incorporación, el formato Java es el formato primario y el resto son formatos derivados. Debido a que el formato Java puede contener el comportamiento para producir los otros formatos, se ha escogido como el formato primario. Los formatos XML, de intercambio de datos electrónico e IIOP pueden ser derivados del formato Java.

La figura 7 es un diagrama de situaciones en donde el software común de 12 TECHNOLOGIES está presente sobre ambos lados de una relación y en donde no lo está. Como se mostró, por ejemplo, cuando el administro de comunicación global RHYTHM está sobre ambos lados nada va a ganarse par convertir a un formato intermedio. Esto introducirá una ineficiencia innecesaria, y sólo datos (no objetos) serían intercambiables limitando el rango de aplicaciones. Por tanto cuando el mismo software está presente sobre ambos lados, los objetos Java binarios pueden ser directamente intercambiados. Por otro lado, por ejemplo, cuando el ADMINISTRADOR DE COLABORACIÓN GLOBAL RHYTHM está presente sólo de un lado, los objetos formateados EDI o XML pueden ser producidos (salida) e interpretados (entrada) .

Con respecto a los estándares de transporte, el administrador de colaboración global presente puede soportar a la variedad de estándares de transporte, incluyendo HTTP, IIOP, y los buses de mensaje asincrónico. Mayores detalles se proporcionan abajo con respecto a manejar múltiples tipos de relación.

Con respecto a los estándares semánticos, el administrador de colaboración global presente puede primariamente soportar dos estándares semánticos e intercambio de datos electrónico y RHYTHM-CDM. El intercambio de datos electrónico puede ser soportado debido a que este es generalmente el estándar semántico más popular. Sin embargo este sufre de la desventaja (entre otras) de no proporcionar cobertura profunda del dominio de planeación. El RHYTHM-CDM, por otro lado, proporciona la cobertura profunda del dominio de planeación y proporcionará construcciones apropiadas para llevar a cabo un soporte de decisión de empresas múltiples. Adicionalmente, este formato está soportado por todos los motores de planeación de 12 TECHNOLOGIES.

En general, un problema con los estándares públicos tal como el intercambio de datos electrónico, es el de que muchos no pueden cubrir adecuadamente las clases de datos/objetos que las empresas intercambiarían. Además, la espera de los cuerpos estándares para estandarizar sobre un objeto en particular puede no ser una opción, y la cadena de suministro no tiene ninguna ventaja competitiva particular por el uso de estándares públicos. Por esta y otras razones, el presente administrador de colaboración global soporta un acercamiento alterno a la estandarización mediante el soportar los estándares de comunidad propietarios. Por ejemplo, usando el RHYTHM-GCD, una comunidad de empresas puede diseñar un juego de estándares que son relevantes sólo para esa comunidad. El RHYTHM-GCM soportará y hará cumplir estos estándares de comunidad propietarios. El RHYTHM-GCD también soporta una biblioteca de objetos de bloque de construcción que pueden estar compuestos en estándares de comunidad propietaria. Los estándares de comunidad propietaria tienen un número de ventajas como incluyendo: éstos pueden ser diseñados para cubrir exactamente las clases de datos/objetos que las empresas intercambiarán; sólo las partes relevantes requieren el convenir sobre el estándar particular, por tanto el proceso será mucho más rápido que la espera por un cuerpo estándar; los estándares diferentes pueden ser desarrollados para diferentes categorías de socios y, en un caso extremo, un estándar diferente para cada socio; y pueden ser desarrollados los estándares que dan a la cadena de suministro una ventaja competitiva sobre los competidores .

Tipos de Relación Múltiples Otro problema para permitir la colaboración es el manejo de tipos de relación múltiple. Las empresas tienen algunas relaciones de varios tipos con sus socios. En algunas maneras las relaciones que pueden variar son: entre los socios de comercio principales por un lado y entre los socios de comercio menores por el otro; entre las empresas de aproximadamente una influencia igual sobre la cadena de suministro y entre empresas de influencia desigual sobre la cadena de suministro; y entre empresas con un alto grado de sofisticación técnica sobre un lado y entre las empresas con un lado desigual de sofisticación tecnológica por el otro lado. Como deberá entenderse, éstos tipos de relaciones diferentes deben ser manejados diferentemente.

El administrador de colaboración global presente puede modelar las relaciones de empresas como una red de eje y radio, como se describió arriba y se muestra en la figura 4. De esta manera, los cuatro tipos de relaciones son: de eje-a-red; de eje-a-Van-Intercambio de datos Electrónico; de eje-a-radio y de eje-a-eje. Cada tipo de relación tiene un uso apropiado.

Con respecto a la relación de eje-a-radio, cuando la gente habla del comercio electrónico el día de hoy, la gente frecuentemente implica una arquitectura en donde un explorador de red habla a algún servidor centralizado. Esta arquitectura tiene algunas ventajas: La infraestructura para soportar esta arquitectura está ya típicamente; y toda la administración puede ser centralizada sobre el lado del servidor. Sin embargo, esta arquitectura también tiene una gran desventaja en el sentido de que ésta requiere de la presencia de un humano en el lado del explorador de la red. Por tanto, la automatización de sistema a sistema no es posible. Basándose sobre éstas ventajas y contras este tipo de relación puede ser apropiado cuando una empresa requiere de intercambiar datos con ya sea un socio menor o un socio con menos sofisticación tecnológica.

Con respecto a la relación eje-a-Valor agregado de red- Intercambio de datos electrónico, la vasta mayoría del comercio electrónico entre empresas tiene lugar actualmente mediante el enviar un intercambio de datos electrónico sobre redes de valor agregado. La ventaja de este acercamiento puede ser la de que la integración de sistema a sistema es posible y esta actualmente soportada corrientemente. Las desventajas de este acercamiento son: los grandes costos para enviar datos sobre red de valor agregados propietario; los altos costos administrativos debido a la falta de una verdadera estandarización; requerimiento de herramientas de terceras partes justo para convertir del verdadero "estándar" a una forma apropiada para la empresa; ningún soporte para la integración de sistema a humano y ningún soporte para los estándares propietarios y los estándares corporativos. Basándose sobre estas y otras ventajas y desventajas, este tipo de relación puede ser apropiado cuando se soporta un ambiente de un legado de red de valor agregado- intercambio de datos electrónico.

Con respecto a la relación de eje-a-radio, este tipo de relación también permite una integración de sistema a sistema como red de valor agregado- Intercambio de datos electrónico. Arquitectónicamente el eje a radio es una colaboración entre un motor de eje y un motor de radio. La relación de eje-a-radio puede tener ventajas como red de valor agregado. intercambio de datos electrónico. Esta puede usar el internet público para reducir los costos de red; los costos administrativos son mucho más bajos que los de red de valor agregado-intercambio de datos electrónico debido a que gran parte de la infraestructura de la relación de eje a radio puede ser desplegada centralmente y administrada. Los objetos verdaderos (en adición a solo datos) pueden ser intercambiados permitiendo colaboraciones mucho más avanzadas; y los estándares semánticos múltiples pueden ser soportados incluyendo el intercambio de datos electrónico, I2-CDM y los estándares de comunidad propietaria. Basándose sobre las características arriba mencionadas, la relación de eje a radio puede ser apropiada cuando las empresas que desean llevar a cabo una colaboración de sistema a sistema sofisticada. También puede ser apropiado en donde no está presente un programa de software de I2 Technologies en cualesquiera de las empresas. Esto se debe a la relación de eje a radio que puede ser desplegada centralmente por la empresa de eje.

Con respecto al eje a eje, la relación es similar a la de eje a radio excepto porque ésta tiene lugar entre los dos motores de eje más bien que un motor de eje y uno de radio. Basándose sobre esta característica, la relación de eje a e e puede ser apropiada entre empresas que desean el llevar a cabo una colaboración de sistema a sistema sofisticada. Además, la relación de eje a eje puede ser apropiada cuando dos empresas tienen un RHYTHM-GCM comprado separadamente y han puesto sus motores de eje.

Hay diferencias entre los motores de eje y los motores de radio. En general, unas capacidades de motores de eje ^£^^^ig^« son sobrepuestas de unas capacidades de motor de radio. La siguiente Tabla prop*o :iona un ejemplo de algunas de las diferencias . Tí, TABLA Seguridad Un problema adicional con una colaboración es el desafío de proporcionar una seguridad comprensiva. Antes de que las empresas puedan colaborar efectivamente, necesita examinarse el asunto de la seguridad. Puede haber muchas facetas diferentes para la seguridad en un contexto de colaboración. Un cuadro de colaboración de empresas múltiples cualesquiera debe de referirse a todas éstas facetas diferentes. Los requerimiento para una red de seguridad colaborativa puede incluir que: intercambio de datos entre los dos socios deba ser sólo visto por los dos socios; que los datos intercambiados entre los dos socios deban ser a prueba de invasión; una empresa debe ser capaz de verificar que un socio es quien dice que lo sea; el cuadro no debe introducir nuevos agujeros de seguridad en la red de los socios; y el cuadro debe ser relativamente fácil de poner y de administrar.

Un sistema de colaboración de seguridad puede ser proporcionado mediante el implementar una estrategia de seguridad comprensiva para referirse a los requerimientos arriba mencionados. En una incorporación, la estrategia tiene tres aspectos diferentes para esto: seguridad tecnológica, una permisibilidad de cuadro y división de datos.

La seguridad tecnológica puede referirse a los medios tecnológicos usados para garantizar la seguridad.

Esta seguridad puede ser usada para proporcionar: privacía, certificación e integridad de información. La privacía asegura que ninguna persona autorizada puede ver los datos. La certificación involucra la certificación que las partes en la colaboración son realmente quienes reclaman ser. La integridad de datos involucra el hacer posible para una persona no autorizada el modificar los datos que están siendo enviados en cualesquier forma .

El acercamiento de seguridad preciso puede estar basado sobre la relación descrita anteriormente. Por ejemplo, un esquema está detallado en la tabla que sigue: Como puede verse de la tabla, todos los tipos de relación, con la excepción de eje-a-VAN EDI, pueden soportar la seguridad a través de SSL 3.0.

El SSL 3.0 es un protocolo estándar industrial basado en una codificación desclave pública de soporte sobre una conexión de base de soquet y proporciona : privacía, certificación de clientes así como de servidor, integridad de información y manejo de certificado. El SSL 3.0 es un protocolo de nivel superior en el cual varios algoritmos criptográficos de clave pública pueden ser conectados incluyendo el R?A y el Diffie-Helman.

Una vez que el saludo SSL es completado, el siguiente paso es la certificación de nombre de usuario-palabra de contraseña. Esto proporciona la certificación más allá de lo que proporciona el SSL 3.0 mismo. Las contraseñas pueden ser almacenadas usando la codificación a base de contraseña PKCS5 (un estándar RSA) . Una vez que un usuario o el que habla es certificado, este se regresa a una muestra de acceso. Esta muestra de acceso tiene una vida de tiempo especificable por el administrador. Un usuario puede entonces accesar al sistema para la duración de la validez de la muestra de acceso. Esto tiene el efecto benéfico de no requerir certificación en cada acceso. Cada solicitud la cual es accesada, certifica la muestra de acceso mediante la validación de la firma (la cual es un resumen codificado usando la clave privada del administrador de seguridad) del administrador de dicha seguridad.

El sistema de seguridad tecnológico es una parte del esquema de seguridad. La otra parte tiene que ver con el diseño de las colaboraciones mismas. El sistema debe permitir a las empresas el sujetar fácilmente los permisos a varias acciones que otras empresas pueden llevar a cabo sobre ésta. El espacio de trabajo de colaboración global puede soportar un modelo de permiso jerárquico con permisos individuales unidos a diferentes elementos de datos en la jerarquía. En particular, ésta puede soportar permisos de la lectura, la escritura, toma y permisos de suscripción de usuario específico y del que habla específico. Por tanto, las empresas pueden afinar específicamente quien puede leer y que datos, quien puede escribir que datos, quienes pueden tomar que datos y quienes pueden suscribir para escribir notificaciones sobre que datos.

Un tercer elemento en la estrategia de seguridad del sistema de colaboración es la capacidad para dividir los datos a través de varios espacies de trabajo de colaboración. En particular, los espacios de trabajo de colaboración son divididos en espacios de trabajo colaboración interna y un espacio de trabajo de colaboración externa. Sólo los datos que requieren ser verdaderamente compartidos con los socios están en el espacio de trabajo de colaboración externo. El resto está en el espacio de trabajo de colaboración interno. El espacio de trabajo de colaboración externo está diseñado para asentarse ya sea afuera de la pared de incendios de la sociedad o en una extrared o DMZ .

El diseño de sistema de colaboración no requiere que el espacio de trabajo de colaboración externa haga conexiones a través de la pared de incendios corporativa en la red interna (aún cuando lo podría hacer) .

En una incorporación, las colaboraciones globales pueden usar ambas los espacios de trabajo de colaboración interna y externa. Las colaboraciones locales pueden usar sólo el espacio de trabajo de colaboración interno y por tanto ser completamente invisibles a las empresas socias. Aún para las colaboraciones globales sólo las partes relevantes usan los espacios de trabajo colaboración externa. Además, debido al sistema de permiso descrito anteriormente, cada empresa socio puede sólo ver (leer, escribir, tomar, suscribir) sus propios datos.

La Figura 8 es un diagrama de bloque de una incorporación de una conf?gurac_ón de seguridad para un caso de eje-a-red y de eje-a-radio. Como se mostró, una empresa e e 50 está acoplada a y se comunica con un espacio de trabajo de colaboración global interno 52 y un espacio de trabajo de colaboración global externo 54. Una empresa de radio 56 y una empresa de red 58 se conectan a través de un servidor de red 60 al espacio de trabajo de colaboración global externo 54. La empresa de hablar 56, como la empresa e e tiene un espacio de trabajo de colaboración global interno 62. Las empresas 50, 56 y 58 pueden ser protegidas por l s paredes de incendio asociadas, mientras que la extrared formada por el servidor de red 60 y el espacio de trabajo de colaboración global externo 54 puede ser protegida mediante un director de filtrado y comunicarse a través del HTTP sobre el SSL 3.0.

La Figura 9 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a eje. Como se mostró, una empresa de eje 64 y una empresa de eje 66 pueden comunicarse a través de un SSL 3.0 protegido por la conexión TCP/IP. La comunicación puede ser entre los intermediarios de mensaje global separados 68 y 69. Ambas empresas ejes 64 y 66 están protegidas por una pared de incendios, como se mostró.

Los Flujos de Trabaio Entre Empresas Uno de los problemas con el soporte de decisión de empresas múltiples puede ser que no hay una colaboración de circuito cerrado. En vez de ésto, los datos pueden ser obtenidos de una empresa a la siguiente sin un flujo de trabajo coherente. A fin de implementar una colaboración de circuito cerrado, el soporte para crear flujos de trabajo de empresas múltiples es necesario. El diseñador y administración de colaboración global presente puede hacer posible el construir, desplegar, vigilar y cambiar los flujos de trabajo de empresas múltiples sofisticadas.

En general, urt-e "flujo de trabajo" puede ser un juego de "actividades" unidas juntas por flujos de datos que juntos logran alguna tarea. Los flujos de trabajo son típicamente ejecutados sobre motores de flujo de trabajo. Un "flujo de trabajo distribuido" puede referirse a un flujo de trabajo que es ejecutado sobre motores de flujo de trabajo múltiples. En otras palabras, diferentes partes del flujo de trabajo se ejecutan sobre motores diferentes. Un "nodo" puede referirse a entidades abstractas sobre las cuales diferentes motores de flujo de trabajo de una corrida de flujo de trabajo distribuida, y un "grupo de nodo" puede ser un juego de nodos agrupado por algunas características. Un "flujo de trabajo distribuido de empresas múltiples" puede ser flujos de trabajo distribuidos en donde los nodos son empresas.

Los parámetros de flujos de trabajo pueden ser importantes para la colaboración de empresas. Un "flujo de trabajo paramétrico" es un flujo de trabajo que está con parámetros sobre alguna variable y puede ser regular o distribuido. El poner en instancias el flujo de trabajo paramétrico con diferentes valeres de las variables de parámetro produce diferentes instancias del flujo de trabajo. Un "flujo de trabajo distribuido con parámetros sobre nodos en un grupo de nodos" puede referirse a flujos de trabajo distribuidos en donde los parámetros sobre el flujo de trabajo son los nodos en un grupo de nodo. Por tanto, cuando el flujo de trabajo es puesto en ssife, instancias éste está confeccionado para un nodo particular en un grupo de nodo. Hay varias características importantes para los flujos de trabajo que pueden ser soportadas por medio de la colaboración global presente. Estos flujos de trabajo pueden ser fuertemente teclados. El teclado fuerte ser esencial para producir flujos de trabajo libres de error y robustos. En esencia, el teclado fuerte garantiza el tipo de un mensaje en un tiempo designado. Por ejemplo, si el flujo de trabajo está diseñado para ser enviado a una cuenta de materiales, entonces el teclado fuerte asegura que es físicamente imposible el que un objeto distinto a una cuenta de materiales sea enviado. Para un flujo de trabajo diseñado con el diseñador de colaboración global y ejecutado con el administrador de colaboración global, puede ser imposible el aún enviar un objeto de un tipo incorrecto. Esta capacidad es importante para producir flujos de trabajo libres de error y robustos.

A pesar del teclado hay, por ejemplo, dos escenarios en los cuales los tipos de objetos equivocado pueden concebiblemente ser pasados en el flujo de trabajo: debido a un error en la parte del diseñador del flujo de trabajo; y un intento malicioso por alguien de minar el flujo de trabajo. Ambos de éstos escenarios pueden ser manejados. El primero puede ser manejado mediante el hacer imposible que un error en el diseño lleve a tal escenario. El segundo puede ser manejado mediante el hacer a prueba de violación los flujos de datos mediante el usar una criptografía de clave pública u otro esquema de codificación (característica de integridad) como se describió arriba.

Otra característica importante es el soporte para los flujos de trabajo con parámetro sobre grupos. Algunos flujos de trabajo de empresas múltiples involucran un gran número de empresas. En tales casos se hace impráctico el crear flujos de trabajo individualizados para cada socio. En vez de ésto puede ser ventajoso el crear flujos de trabajo que tengan parámetros sobre grupos de socios. Por ejemplo, en el ramo de la procuración, dos grupos pueden ser los proveedores primarios y los proveedores secundarios . El grupo de proveedores primario puede tener un tipo de flujo de trabajo, y los proveedores secundarios pueden tener otro tipo de flujo de trabajo. Los flujos de trabajo a base de grupo pueden ser paramétpcos en ese sentido, a un tiempo corrida, un flujo de trabajo real puede ser específico creado para un miembro de un grupo.

En el contexto de las empresas múltiples, una empresa puede colaborar, por ejemplo, con cientos o miles potencialmente de otras empresas. Cada colaboración o flujo de trabajo de empresas múltiples puede ser potencialmente (y típicamente) único. Sin embargo, el diseño de miles de flujo de trabajo especializados con soci'? de empresas ni es deseable ni es posible. Por otro lado, muchos de éstos flujos de trabajo son simplemente variaciones paramétricas sobre un flujo de trabajo parameterizado subyacente. Por ejemplo, una compañía A puede ser colaboradora (en las ventas) con detallistas, distribuidores, directores de ventas etc. Por tanto, hace sentido el agrupar los varios socios. Un agrupamiento de ejemplo puede ser: alMart, Sears; el resto de los detallistas además de WalMart y de Sears (grupo) ; distribuidores primarios (grupo) y distribuidores secundarios (grupo) . Ahora, los flujos de trabajo con todos los miembros, por ejemplo, del grupo de distribuidores primarios son variaciones sobre un flujo de trabajo distribuido paramétrico subyacente, con parámetros sobre el distribuidor particular en ése grupo.

Los flujos de trabajo con parámetros sobre grupos pueden ser soportados con una técnica de definición de flujo de trabajo de HETEROCASTING . La técnica de definición HETEROCASTING generalmente involucra el usar una definición de flujo de trabajo con parámetros para poner en instancias flujos de trabajo heterogéneos basados sobre diferencias en los parámetros. Por tanto, la técnica de definición de HETEROCASTING permite un flujo de trabajo distribuido no paramétricos que se haga fácilmente paramétrico (a través de una herramienta de diseño visual) sobre nodos en un grupo de nodos. Puede haber dos actividades de flujo de trabajo primarias usadas para lograr ésta definición: una actividad de división HETSWDCAST y una actividad junta HETREOCAST. Todas las actividades entre división HETEROCAST y una unión HETEROCAST tienen parámetros sobre los nodos de un grupo de nodo a los que estas actividades corresponden.

La Figura 10 é*s un diagrama de una incorporación del diseño de un flujo de trabajo entre empresas que incluye los parámetros sobre grupos. Como se mostró, el flujo de trabajo puede comenzar con una actividad de escucha 70 que espera algún evento. La actividad 70 puede ser enlazada a actividades paralelas 71 que enlazan a un sub-flujo de trabajo 72 y a una división de HETEROCAST 73. El sub-flujo de trabajo mismo puede incluir una definición de flujo de trabajo. Con respecto al HETEROCASTING, el flujo de trabajo después de la división HETEROCAST 73 se convierte en parameterizada. Por tanto, en el ejemplo de la Figura 10, la actividad 74 es una actividad con parámetros. Después de la actividad 74, una junta de HETEROCAST 75 recibe el flujo desde la actividad 74. El sub-flujo de trabajo 72 y una junta de HETEROCAST 75 son enlazadas a una junta sincrónica o asincrónica 76 la cual, a su vez, se enlaza a un evento integrado 77 (por ejemplo, el multifraguado) . Un flujo de trabajo aquel de la Figura 10 puede ser diseñado usando el diseñador de colaboración global presente y puede permitir una representación completa de flujo de trabajo para un soporte de decisión entre empresas. Este flujo de trabajo puede entonces ser instanciado e implementado a través del administrador de colaboración global presente.

La Figura 11 es un diagrama de una incorporación del cambio de manejo mediante la modificación un diseño de un flujo de trabajo. Como se mostró, un diseño de flujo de trabajo inicial puede tener un evento 70 enlazado a una división de actividad paralela 71. Entre la división de actividad 71 y una junta 76, pueden haber, por ejemplo, dos actividades 78. Este flujo de trabajo, una vez diseñado, puede ser instanciado e implementado usando el administrador de colaboración global. Si un cambio requiere hacerse al flujo de trabajo, el diseñador de colaboración global alivia grandemente el problema de hacer el cambio. Por ejemplo, una nueva actividad 79 puede ser agregada entre la división 71 y la junta 76. El flujo de trabajo puede entonces ser remstanciado centralmente e implementado.

En particular, la técnica de HETEROCAST puede permitir a la construcción de flujos de trabajo distribuidos parameterizados sobre nodos en un grupo de nodo. Esto puede permitir una ganancia de productividad enorme sobre el diseño de flujos de trabajo individuales para miembros de trabajo individuales. Además, ésta técnica hace un diseño rápido y el prototipo de flujos de trabajo de entre empresas sofisticados con cientos o miles de posibles socios. La técnica debe ser distinguida del "multielenco" en el cual los mensajes idénticos son enviados a los varios nodos (socios) . En esencia, el multielenco permite el diseñar un flujo de trabajo único que corre idénticamente a través de los nodos múltiples. Esto difiere de la técnica del HETEROCASTING, en donde los flujos de trabajo corren diferentemente basándose sobre cual nodo de ellos deben de correr.

Una tercera característica importante es el soporte para los flujos de trabajo a base de papel o rol. Los flujos de trabajo a base de papel permiten a los flujos de trabajo el ser especificados usando papeles genéricos. Esta capacidad permite la creación de flujos de trabajo genéricos o templados que pueden ser instanciados en varios escenarios. Por ejemplo, los tipos de papel pueden ser: papeles de socio, papeles de radio; papeles de grupo de radio; papeles de red; papeles de grupo de red; papeles de usuario. Como un ejemplo de los papeles, los papeles de socios se refieren a los diferentes papeles desempeñados por los socios. Por tanto, un papel ce socio en el caso de la procuración es el proveedor primario y de proveedor secundario.

Los flujos de trabajo a base de papel pueden llevar al concepto de tres diferentes fases en el diseño y ejecución de un flujo de trabajo. La fase de diseño es la fase en la cual los flujos de trabajo a base de papel son definidos.

La fase de poner instancias es la fase en la cual los papeles son mapeados a las instancias. Por ejemplo, el proveedor primario puede ser mapeado a una primera compañía, y el aprobador PO puede ser mapeado a John Doe. En tercer lugar, la fase de tiempo de corrida puede ser la fase en la cual corre el flujo de trabajo con instancias.

Una característica importante adicional es la integración de los flujos de trabajo automatizados con flujos de trabajo orientados por el usuario. Los flujos de trabajo pueden ser frecuentemente descritos como teniendo dos variedades: flujos de trabajo de sistema a sistema automatizados, y flujos de trabajo de interconexión de usuario. Aún cuando hay flujos de trabajo que son completamente automáticos, y hay flujos de trabajo que son impulsados completamente por el usuario, la mayoría de los flujos de trabajo tienen elementos de automatizados así como de interconexión de usuario. El presente administrador y diseñador de colaboración global no requieren el hacer ésta distinción artificial entre los tipos de flujo de trabajo. Por tanto, los flujos de trabajo pueden ser automatizados en partes e interactuar con los usuarios en otras partes. Ambas partes automatizadas y las partes de usuario pueden abarcar empresas múltiples.

Una característica importante adicional es la comunicación de flujo de trabajo. La comunicación puede ocurrir a través de empresas disparadas por eventos que ocurren en un flujo de trabajo. La. comunicación puede tomar una de dos formas: suscripción/publicación. En un esquema de comunicación de punto a punto los mensajes individuales son enviados a cada recipiente intentado. Por ejemplo, si iay 10 gentes que requieren el ser contactadas, son enviados 10 mensajes a esas gentes. En un esquema de publicación y suscripción, los individuos se suscriben para recibir mensajes los cuales son generados por un evento. Cuando el evento ocurre, se envía un mensaje a los usuarios quienes se han suscrito.

La Figura 12 ilustra un diagrama de bloque de una incorporación del sistema que incorpora una comunicación de flujo de trabajo. El sistema 16 incluye un eje 17 el cual incluye un motor de eje 19. El motor de eje 19 incluye un administrador de evento 200. Acoplado al eje 17 están los nodos de radio 24 los cuales pueden incluir los procesos tales, el flujo de trabajo que corre sobre los motores de radio. Los nodos de radio adicionales 20 pueden estar acoplados al eje 17.

En operación los nodos de radio 24 pueden ser operables para recibir las comunicaciones de punto a punto del eje 17. Cuando un flujo de trabajo ejecuta en el motor de eje 19 alcanza un cierto evento, el administrador de evento 200 puede ser integrado para enviar mensajes individuales a los nodos de radio 4 en un esquema de punto apunto. Adicionalmente, el nodo de radio 20 puede suscribir al administrador de evento 200 para recibir los mensajes en ?iertos tiempos basándose sobre eventos alcanzados por el flujo de trabajo que corre sobre el motor 19. Cuando el evento es alcanzado, el administrador de eventos 200 junto con el manejador de mensajes (no mostrado) enviará mensajes a todos los suscriptores. Por ejemplo, un evento puede ser el arribo de una cuenta. Cuando la cuenta arriba, todos los suscriptores recibirán una notificación.

La Figura 13 es un diagrama de bloque de una incorporación del administrador de eventos 200. El administrador de eventos 200 está acoplado a un administrador de flujo de trabajo 202. El administrador de flujo de trabajo 202 está asociado con uno o más módulos 203. Los módulos 203 están acoplados a un espacio de trabajo 204 en donde los datos y objetos pueden ser almacenados para usarse por un motor. El administrador de flujo de trabajo 202 está también acoplado a un manejador de mensajes 206 el cual es operable para recibir los mensajes de los módulos y transmitir mensajes a los espacios de trabajo externos. El manejador de mensajes 206 está acoplado a un espacio de trabajo externo 208 en donde los datos y objetos pueden ser intercambiados entre entidades diferentes en una colaboración. Las interconexiones CORBA 201 son proporcionadas para permitir una variedad de diferentes lenguajes de programación (tales como C++ y Java) para accesar varios componentes .

En la operación^un evento que ocurre en un fMgo de trabajo que corre sobre un motor que puede disparar "^el manejador de evento 208 para empezar un flujo de trabajo mediante el accesar el administrador de flujo de trabajo 202. Adicionalmente, cualesquier evento que ocurre en un flujo de trabajo puede disparar el administrador de flujo de trabajo 202 para accesar el administrador de evento 200. El administrador de eventos 200 puede entonces notificar a todos los suscriptores que ocurrió el evento. Las notificaciones contienen datos con parámetros específicos para ésta instancia del evento.

La Figura 14 ilustra un diagrama de bloque de una incorporación de un modelo de comunicación de publicar/suscribir. La ilustración es un administrador de evento 200 acoplado a y en comunicación con una pluralidad de GUI/aplicaciones 212, 214, y 216. El administrador de eventos 200 también está acoplado a un módulo 204 el cual es operable para correr un flujo de trabajo 210.

En operación, la primera aplicación/GUI 212 envía un evento 218 al administrador de eventos 200. Aún cuando el 212 es recibido por el administrador de eventos 200 éste se pasa a un módulo 204 en donde éste dispara la ejecución del flujo de trabajo 210. Cuando el flujo de trabajo 210 alcanza un punto éste genera un segundo evento 200. Este entonces envía al administrador de eventos 200. El manejador de evento 200, ,ág«£ft' entonces notifica los mensajes informando GUI/aplicación 212, 214 y 216 que ha ocurrido el evento. Los valores con parámetro específicos para el evento son entonces enviados junto con las notificaciones siempre que éstos sean suscriptores al administrador de eventos 200.

Integración con el Mundo Exterior La Figura 15 es un diagrama de una incorporación de la integración de un flujo de trabajo con el mundo exterior.

Como se describió en la sección previa, pueden ser cerrados los flujos de trabajos entre las empresas y en las empresas. Estos flujos de trabajo pueden ser compuestos de actividades fuertes juntas en varias configuraciones. No hay una restricción sobre qué diferentes actividades del flujo de trabajo pueden hacerse sin embargo, una de las principales tareas de éstas actividades es la de integrarse con el mundo exterior. La Figura 15 muestra como un flujo de trabajo puede ser integrado con el mundo exterior usando el acercamiento a base de componente para la integración. Los componentes pueden incluir accesorios 80, las transformaciones 82, los objetos de transferencia 84, los adaptadores y los flujos 86.

El administrador de colaboración global puede soportar un modelo de integración a base de componente. El modelo de integraci-én a base de componente permite la flexibilidad en la estructuración de la integración. Puede haber dos tipos de componentes: los componentes primitivos y los componentes compuestos. Los componentes primitivos pueden incluir accesorios 80, los transformadores 82 y los objetos de transferencia 84. Los cßóponentes compuestos incluyen los adaptadores y los flujos 86. Los componentes compuestos son construidos en términos de componentes primitivos. En éste esquema, los accesorios 80 son usados para tener acceso a una fuente externa tal como SCP (PLANEADOR D? CADENA DE SUMINISTRO) , un SAP, una base de datos de relación, los servidores de red, los uses de mensajes de correo electrónico, etc. Los accesorios 80 pueden ser usados para leer, escribir o escuchar fuentes y destinaciones de datos. Los transformadores 82 pueden ser usados para transformar los datos de una forma a otra forma. Los objetos de transferencia 84 son objetos que pueden ser pasados de actividad a actividad o de empresa a er.presa. Los objetos de transferencia 84 pueden ser convertibles opcionalmente a las estructuras EDI, XML, CORBA, etc. Les accesorios 80 y los transformadores 82 pueden ser unidos juntos para formar flujos. Un flujo completo puede ser ejecutado en una actividad única como se muestra en la Figura 16.

La Figura 16 es un diagrama de una incorporación de un flujo de datos que corre en una actividad única 92. Como se mostró, una fuente de datos 90 puede ser accesible desde y proporcionar datos a un componente accesor 94. El componente accesor 94 puede entonces pasar datos a través de los componentes de transformador 96 y 98 los cuales proporcionan datos a un segundo componente accesor 100. Los datos pueden entonces ser almacenados en un destino de datos 102.

La Figura 17 es un diagrama de una incorporación de una división de flujo de datos a través de actividades múltiples 104 y 106. Como se mostró, el flujo de la Figura 14 difiere de aquel de la Figura 17 en que sentido de que los componentes de transformador 96 y 98 están dentro de actividades separadas 104 y 106 y se comunican mediante un objeto de transferencia. Los flujos de datos de empresas múltiples pueden estar basados sobre el modelo de la Figura 17 más bien que aquel de la Figura 16.

Con respecto a las transformaciones, en una incorporación, pueden ser soportados ios tipos de transformación fundamentales: las transformaciones a base de I2-CDM y las transformaciones directas. Las transformaciones a base de I -CDM están basadas sobre EL MODELO DE DATOS COMÚN de 12 TECHNOLOGIES (CDM) . El modelo de datos común es ur. esquema abstracto que está disponible en ambas formas de relación y de objeto.

La Figura 18 es un diagrama de bloque de una incorporación de un modelo de transformación a base de 12 -CDM.

Como se mostró, los transformadores y los accesores pueden ser acoplados para transformar unos datos de aplicación en un objeto de datos de modelo de datos común 110 y viceversa. Por ejemplo, un objeto de PLANIFICADOR DE CADENA DE SUMINISTRO (SCP) puede ser creado mediante un accesor de planeador de cadena de suministro desde los datos de planeador de cadena de suministro 114. El objeto planeador de cadena de suministro 112 puede entonces ser transformado mediante un transformador de planeador de cadena de suministro-CDM en un objeto CDM 110. Análogamente, un objeto SAP 116 puede ser creado por un accesor SAP desde los datos SAP 118. El objeto SAP 116 puede entonces ser transformado por un transformador SAP-CDM en un objeto CDM 110. El accesor SAP y el transformador SAP, como con otros accesores y transformadores puede ser combinado en un adaptador SAP-CDM estándar 120 que puede ser usado para las transformaciones a base de CDM de otros componentes. Como otro ejemplo, un objeto BAAN 122 puede ser creado por un accesor BAAN desde unos datos BAAN 124. El objeto BAAN 122 puede entonces ser transformado en ur. objeto CDM 110 por medio de un transformador BAAN-CDM. Estos transformadores trabajan en otra dirección también.

La Figura 19 es un diagrama de una incorporación de una transformación directa. En los transformadores directos, los objetos son convertidos de una forma a otra sin pasar a través de un formato intermedio. Por ejemplo, como se mostró en la Figura 19, los datos de planeador de cadena de suministro (SCP) 130 pueden ser accesadosj por un accesor SCP para crear un objeto de planeador de cadena de suministro 132. El objeto de planeador de cadena de suministro 132 puede entonces ser transformado directamente a un objeto PLANEADOR FÁBRICA (FP) 134. El objeto planeador de fábrica 134 puede entonces convertirse en los datos de planeador de fábrica 136 a través de un accesor de planeador de fábrica. Este flujo de datos puede operar en otra dirección también.

En éstos procesos, hay varios niveles de granulos a los cuyo acceso y transformación puede tener lugar incluyendo el de relación (tabla), el objeto genérico (árbol, gráfica, matriz, etc.), un objeto específico (cuenta de materiales, plan, etc.) . Algunas veces el acceso puede sólo estar disponible a un nivel (dígase tabla) pero las transformaciones pueden ser más apropiadas a otro nivel (dígase objeto genérico) . Por ejemplo, el agregado jerárquico (una forma de transformación) es frecuentemente apropiada sobre un objeto de árbol. Sin embargo, los datos pueden ser sólo accesibles en una forma tabular. En éste caso, por ejemplo, los datos deben ser accesados al nivel tabular, transformarse en un árbol y después tener el agregado jerárquico aplicado a éste.

La Figura 20 es un diagrama de una incorporación de diferentes niveles de acceso y transformación. Como se mostró, el acceso y la transformación pueden tener tres niveles.

Un primer nivel 140 involucra el acceso de tabla y las transformaciones. Un segundo nivel 142 puede involucrar un objeto genérico (árbol, gráfica, etc.) acceso y transformaciones y un tercer nivel puede involucrar un objeto específico (construcción de materiales, plan, etc.) acceso y transformaciones. Además de las transformaciones entre los formatos de aplicación, puede haber transformaciones entre los tres niveles como se mostró.

Desplegado de Colaboraciones Un factor importante en un sistema de colaboración de empresas múltiples es la facilidad con la cual puede ser desplegada la colaboración. Como se discutió, el administrador de colaboración global presente puede soportar cuatro clases diferentes de relaciones de socio: de eje a red, de eje a radio, de e e a eje y de eje a-VAN-EDI. De éstas cuatro, la relación de eje a red tiene todas las características de despliegue de las aplicaciones de red tradicionales. La relación de eje a-VAN-EDI puede desplegable a la extensión en que ésta nivela una infraestructura VAN-EDI existente. Aún cuando la relación de eje a red es altamente desplegable, ésta puede sufrir del problema de requerir un humano sobre el lado de la red de la relación. En otras palabras, puede no ser adecuada para una colaboración de sistema a sistema.

La solución de eje a radio puede proporcionar un despliegue máximo en el 'ambiente de colaboración de sistema a sistema. En el campo de eje a radio, el motor de radio es análogo al explorador de red, y la parte de radio de la colaboración es análoga a la página de red. Similar a una página de red, la parte de radio de la colaboración puede estar diseñada centralmente y desplegada a motores de radio remotos . A diferencia de la página-red, aún puede haber integración que requiera el hacerse remotamente. Esta integración remota puede ser inevitable pero puede ser circunscrita y definida precisamente por la parte de radio de esta colaboración.

Otro aspecto del despliegue es el manejo de versiones. Las colaboraciones una vez diseñadas y desplegadas son factibles de requerir cambio (en diferentes formas varias) al pasar el tiempo. Puede ser importante el que versiones subsecuentes de colaboraciones sean fácilmente desplegables como versiones iniciales. El administrador de colaboración global presente puede proporcionar un soporte completo para las versiones y redespliegue centralizado de las colaboraciones. Además, las diferentes versiones de las colaboraciones pueden correr simultáneamente sin impactar unas a otras. Esto permite a una versión existente el ser faseada graciosamente mientras que otra versión es faseada hacia adentro.

Otro elemento del despliegue del presente administrador de colaboración global es la nivelación de infraestructura existente. Este elemento es evidente, por ejemplo, en el soporte de la relación de red a radio sobre los protocolos de red existentes. El soporte de eje a radio sobre los protocolos de red existentes puede ser importante para el despliegue rápido ya que no se requiere información o reconfiguración de una infraestructura de red existente. Unos ahorros de tiempo grandes en éste aspecto pueden venir de no tener que modificar cuidadosamente las infraestructuras de seguridad y de pared de incendios que pueden ya estar en el lugar.

Soporte de Colaboraciones de Muchos a Muchos La presente arquitectura de red y de radio proporciona una administración y despliegue fáciles. Sin embargo, en la práctica las empresas colaboran con muchas empresas las cuales a su vez colaboran aún con otras empresas. Por tanto, las empresas frecuentemente forman una gráfica o red de colaboración. Esto puede ser soportado a través de la capacidad para sustituir un motor de eje por un motor de red en un momento dado. Esta capacidad de sustitución permite a las redes la colaboración de muchos a muchos para que crezcan orgánicamente más bien que todas a la vez.

La Figura 21 es un diagrama de una incorporación de la sustitución de un motor de eje por un motor de red dentro de una colaboración. Como se mostró, una empresa (El) puede desplegar un motor de eje 150 sobre sí misma y un motor de radio 152 en todos los sitios de socios. En particular, un motor de radio 154 puede ser un sitio de socio (E2) . Si el sitio de socio (E2) desea el diseñar y controlar sus propias colaboraciones, éste puede reemplazar el motor de radio 154 con un motor de e e 156. Desde la perspectiva de El, E2 puede aún ser un radio en la colaboración El. Sin embargo, éste radio ahora corre sobre un motor de eje 156 el cual puede controlar sus propias colaboraciones con motores de radio 158. Además, los motores de radio 160 y 162 pueden ser asociados con una tercera entidad (E3) que interactúa con ambos el motor de eje 150 y el motor de eje 156 a nombre de la empresa E3.

Extensión del Sistema Un aspecto importante del presente sistema es su extensión. Sin la extensión, el sistema puede no ser capaz de manejar nuevas situaciones y desafíos con las cuales se confronte. Puede haber varias dimensiones diferentes a ésta extensión. Por ejemplo, un área primaria de extensión está en el área de los estándares de objeto semántico. Si los estándares soportados no son suficientes para un problema particular, entonces el sistema puede ser aumentado con nuevos estándares semánticos. Adicionalmente, el sistema permite la construcción de estándares semánticos propietarios. Además, el sistema puede ser extendido mediante el agregar nuevos accesores, transformadores, adaptadores, etc. La biblioteca de componente estándar puede ser extendida, a ambos generalmente y por usuarios finales .

Aún cuando la presente invención se ha descrito en detalle, deberá entenderse el que pueden hacerse varios cambios, sustituciones y alteraciones a la misma sin departir del espíritu y del alcance de la invención como se define por las reivindicaciones anexas.

Claims (10)

R E I V I N D I C A C I O N E S

1. Un método para la comunicación de flujo de trabajo que comprende: el ejecutar uno o más flujos de trabajo; disparar un administrador de eventos sobre la ocurrencia de un evento predefinido en el flujo de trabajo; y formular y enviar un mensaje basado sobre el evento a un grupo fijo.

2. El método tal y como se reivindica en la cláusula 1 caracterizado porque el mensaje es enviado a todos los miembros de un grupo que se ha suscrito previamente para recibir mensa es .

3. El método tal y como se reivindica en la cláusula 1 caracterizado porque el mensaje es enviado individualmente a todos los miembros de un grupo.

4. El método tal y como se reivindica en la cláusula 1 caracterizado porque los mensajes son enviados a través de empresas.

5. Un sistema para comunicar la ocurrencia de un evento en un flujo de trabajo que comprende: un motor de flujo de trabajo; y un administrador de evento acoplado al motor, el administrador de evento es operable para formular mensajes basados sobre la ocurrencia de un evento en un flujo de trabajo.

6. El sistema tal y como se reivindica en la cláusula 5 caracterizado porque el administrador de eventos además comprende un manejador de mensaje operable para ayudar al manejador de evento en la comunicación de mensajes.

7. El sistema tal y como se reivindica en la cláusula 5 caracterizado porque además comprende un manejador de flujo de trabajo acoplado al maie ador de evento y operable para enviar y recibir información e- relación a la ocurrencia de un evento en un flujo de trabajo.

8. El sistema tal y como se reivindica en la cláusula 5 caracterizado porque el manejador de eventos es además operable para iniciar un flujo de trabajo basado sobre la ocurrencia de un evento.

9. El sistema tal y como se reivindica en la cláusula 5 caracterizado porque el mensaje es enviado a un grupo el cual se ha suscrito para recibir mensajes.

10. El sistema tal y como se reivindica en la cláusula 5 caracterizado porque los mensajes son individualmente enviados a los miembros de un grupo. R E S U M E N Se proporciona un método implementado por computadora para la comunicación de flujo de trabajo. El método incluye los siguientes pasos. Primero, son ejecutados uno o más flujos de trabajo. Después un administrador de evento es disparado sobre la ocurrencia de un evento predefinido en el flujo de trabajo. Finalmente, un mensaje basado en el evento es formulado y enviado a un grupo fijo. -saaaáa^