MXPA05004988A - Un sistema y procedimiento para subrogacion electronica, manejo de flujo de trabajo entre organizaciones, procesamiento de transaccion entre organizaciones e interaccion de usuario con en una red informatica optimizada. - Google Patents

Abstract

Una red de subrogacion electronica inteligente ("ESN") automatiza flujo de trabajo entre organizaciones, flujo de trabajo y colaboracion entre organizaciones, flujo de trabajo y colaboracion entre organizaciones para subrogacion de seguro. Esta ESN es facilitada por un sistema novedoso de arquitectura y procedimiento que incluye un sistema de manejo de flujo de trabajo entre organizaciones, un sistema de procesamiento de transaccion entre organizaciones, y un mecanismo unico para optimizar y enriquecer la interaccion de usuario a base de web dentro de dicho sistema.

Description

WO 2004/044696 A3 ???!1?»?1«?11?11ß1??1? Declaration under Rule 4.17: (88) Date of publicaüon of the International search report: — ofimehtorsh¡p (R¡de 4.17(iv))for US only 13 Jannaiy 2005 Fortwo- tter codes and other abbrevialions, referto the "Guid-Published: ance Notes on Codes andAbbreviations " appearing at the begin- — wíift iniemational search repon ning ofeach regular issue ofthe PCI Gazette.

UN SISTEMA Y PROCEDIMIENTO PARA SUBROGACIÓN ELECTRÓNICA, MANEJO DE FLUJO DE TRABAJO ENTRE ORGANIZACIONES, PROCESAMIENTO DE TRANSACCIÓN ENTRE ORGANIZACIONES E INTERACCIÓN DE USUARIO CON BASE EN UNA RED INFORMÁTICA OPTIMIZADA REFERENCIA CRUZADA Esta solicitud se refiere a la aplicación provisional número 60/ 425,058, presentada el 8 de noviembre 2002, titulada "Sistema y procedimiento de subrogación electrónica" y la solicitud provisional número 60/ 425,670 presentada el 12 de noviembre 2002, titulada "Sistema y procedimiento de subrogación electrónica. Campo de la Invención La invención se refiere en general a una red de subrogación electrónica inteligente ("ESN") que automatiza el flujo de trabajo entre organizaciones, el flujo de trabajo y la colaboración entre organizaciones para la subrogación de seguros. La invención también se refiere a una arquitectura de un sistema y a un procedimiento novedosos que incluyen un sistema de manejo del flujo de trabajo, un sistema de procesamiento de transacciones entre las organizaciones y un mecanismo único para optimizar y enriquecer la interacción de un usuario basado en la red informática dentro de dicho sistema. Se analizará principalmente la invención, al menos 2 al inicio, haciendo referencia a la operación de una red de subrogación electrónica. Antecedentes de la Invención Durante las décadas de los 80 y 90, varios sistemas de procesamiento de transacciones comerciales se enfocaron en la integración de procesos y datos comerciales que existían dentro de una organización (es decir, dentro de una organización). Estos sistemas cubren una amplia selección de aplicaciones comerciales, de complejidades diversas, incluyendo la transmisión/ programación de producción, procesamiento de solicitudes, administración de recursos humanos, contabilidad financiera, administración de ventas, etc. Los ejemplos comerciales de dicho sistema incluyen ofertas de SAP, Oracle y PeopleSoft. Las organizaciones que implementaron satisfactoriamente dicho sistemas obtuvieron costos reducidos, mayor eficiencia y mayor competitividad. Con los sistemas dentro de las organizaciones en ejecución, estas organizaciones ahora buscan integrar los procedimientos comerciales, así como los datos que existen entre las organizaciones de socios comerciales (es decir, entre organizaciones). Actualmente, la mayoría de las transacciones comerciales entre organizaciones se produce usando documentos en papel como el medio principal de intercambio. Este proceso se caracteriza por un alto grado de 3 procesamientos manuales y tiempos de ciclos de transacciones largos ocasionando altos costos, errores y mucha ineficiencia. En contraste, la automatización de los sistemas de procesamientos entre organizaciones ha mostrado beneficios importantes incluyendo una mayor eficiencia, costos reducidos, tiempos de ciclos de transacción reducidos e información de administración enormemente mejorada. Por ejemplo, dentro de muchas industrias, existen diversas oportunidades para automatizar el procesamiento de las transacciones comerciales entre organizaciones, por ejemplo, seguros, fabricación, cuidado de la salud, banca, etc. Dentro de la industria de los seguros, existe una oportunidad como ésta relacionada con la subrogación. La subrogación en los seguros se define como el proceso mediante el cual una compañía de seguros (la parte demandante) busca el reembolso por parte de otra compañía o persona (contraparte) por una reclamación que ya se pagó. Para mayor información relacionada con la subrogación, refiérase a la descripción detallada a continuación. Dentro de la mayoría de las compañías de seguros, la función de subrogación no está automatizada. Muchas de las compañías más grandes han implementado un sistema de clasificación rudimentario para identificar la subrogación, sin embargo, muy pocas han implementado la automatización 4 para el flujo de trabajo de subrogación entre empresas y en toda la empresa. Los procesos manuales y de documentos aún dominan las prácticas comerciales de la subrogación actualmente en uso. Por lo tanto, existe la necesidad en el mercado de un sistema automatizado con las siguientes capacidades únicas para el procesamiento de transacciones comerciales entre organizaciones: 1) una central de red centralizada (basada en redes informáticas) que facilite la interconexión de varias organizaciones y elimine la proliferación de interfaces de punto a punto, 2) un sistema de administración del flujo de trabajo entre organizaciones que provea una estructura común para administrar el estado de todas las transacciones dentro del sistema, 3) un componente de procesamiento de transacciones entre organizaciones que de soporte a múltiples organizaciones y a su relación distintiva con cada transacción y al mismo tiempo asegurar la seguridad y privacidad de los datos de la organización, 4) un mecanismo modelo de datos unificados que permita el intercambio de elementos de datos comunes mientras da soporte a los requerimientos específicos de interfaces de la organización, y 5) datos específicos de la aplicación y específicos de la funcionalidad referente a los tipos de transacciones comerciales que están en procesamiento. Adicionalmente, dentro de la industria de los seguros, 5 se necesita un sistema entre organizaciones para las reclamaciones de subrogación. Tal sistema proporcionaría los datos específicos de la aplicación y funciones únicas al flujo de trabajo de la subrogación de los seguros. Sumario de la Invención La red de subrogación electrónica (ESN) es un centro de referencia virtual para las reclamaciones de subrogación diseñada para eliminar las ineficiencias y tareas manuales en el procesamiento de subrogación. Al usar la ESN, las partes demandantes pueden emitir demandas de subrogación electrónicamente a las contrapartes. La carpeta electrónica de la ESN, soporta los datos estructurados y no estructurados, de manera que las partes involucradas pueden compartir la información de la reclamación así como cualesquiera documentos de apoyo. Aunque las partes primarias de la reclamación de subrogación con frecuencia involucran a las empresas de seguros, las partes adicionales también pueden tomar parte en esta transacción comercial (por ejemplo, organizaciones de negociación, organizaciones de cobranza, abogados, etc.). La ESN tienen la capacidad exclusiva de proveer un flujo de trabajo común y procedimientos de colaboración para la subrogación que abarca múltiples organizaciones diversas, es decir, flujo de trabajo entre organizaciones y procesamiento de transacciones. 6 La ESN proporciona funciones para administrar el flujo de trabajo entre compañías y la colaboración entre éstas. La ESN administrar el flujo de trabajo entre las partes involucradas a través de un modelo de flujo de trabajo basado en el estado que asegura la consistencia del flujo de trabajo entre múltiples partes. Las contrapartes pueden crear reglas en la ESN para enviar la demanda de subrogación hacia los manejadores de archivos adecuados. Todas las partes involucradas pueden crear reglas comerciales en la ESN con base en las prácticas comerciales de cada compañía, las cuales se usan para auditar todos los archivos e identificar las condiciones de excepción. Varias partes pueden colaborar y negociar en línea a través de la ESN. La ESN proporciona funciones para los convenios automáticos de las reclamaciones de subrogación, sin intervención la del hombre, cuando los archivos de las reclamaciones pasan todas las auditorías de las reglas comerciales de las partes y las llamadas de responsabilidad corresponden. La ESN revisa los archivos con las regulaciones de negligencia comparativas de cada estado y, cuando es apropiado, automáticamente genera contrareclamaciones que están enlazadas con el archivo original. Cualquier parte que usa la ESN puede asignar cualquier archivo a una tercera parte, por ejemplo, una firma de negociación, una firma de cobranza, abogados externos, proveedores de servicio, etc. 7 La ESN proporciona funciones de pago en red. Los pagos se pueden rembolsar de manera bilateral o multilateral en donde la ESN dará seguimiento al vencimiento de los pagos entre dos o más partes en un periodo definido y después emitirá una alerta a las partes que deben realizar el pago. Además, la ESN provee a todas las partes información de conciliación y ubicación de archivos. Todos los miembros de la ESN tendrán acceso en línea a una administración completa de la elaboración de reportes, incluyendo los reportes del demandante y de la contraparte. Además, la ESN proporciona una función de referencia de manera que los miembros puedan comparar varios aspectos de su rendimiento como demandante o contraparte con la industria. La ESN proporciona flujo de trabajo elaborado entre organizaciones, capacidades de procesamiento de colaboración y transacción. Al hacerlo, la ESN se basa en una plataforma de programas y sistemas de programación central que consiste en varias tecnologías genéricas que incluyen un subsistema del flujo de trabajo entre las organizaciones, el sistema de procesamiento de transacciones entre organizaciones y el subsistema JView™. El subsistema del flujo de trabajo entre las organizaciones está diseñado para alcanzar los requerimientos del flujo de trabajo tanto entre las 8 organizaciones como dentro de ellas. Usa una serie de tablas de flujo de trabajo (estructuras de datos) y un algoritmo de flujo de trabajo único para realizar todas las operaciones de administración del flujo de trabajo. Las tablas de flujo de trabajo esencialmente son un conjunto de máquinas de estado finito (FSM), que definen un sistema de bucle cerrado para el flujo de trabajo relacionado con un procedimiento comercial. El subsistema de flujo de trabajo administra el estado del flujo de trabajo entre las organizaciones, el estado del flujo de trabajo dentro de una organización, la propiedad de la siguiente acción en un archivo, la navegación de funciones que se pueden realizar, y el estado del archivo. El sistema de procesamiento de transacciones entre organizaciones proporciona la estructura para una red de procesamiento central que maneja las transacciones comerciales entre las organizaciones. Esta estructura aisla las organizaciones miembro entre sí, soporta el intercambio de información estructurada y no estructurada, soporta transacciones y el flujo de trabajo de múltiples partes, así también proporciona seguridad y privacidad extensa a los datos para cada organización. Este sistema consiste en cuatro áreas principales, Subsistema de interfaz, Nivel de procesamiento de transacción (TLP), Servicios de sistema y Lógica de aplicación. El Subsistema de interfaz soporta los requerimientos de la interfaz única de cualquier fuente 9 determinada del origen de la transacción. Al hacerlo, el subsistema de la interfaz soporta el origen de las transacciones de los sistemas automatizados (usando interfaces de mensajería electrónica) o usuarios interactivos (usando interfaces basadas en redes informáticas). El Nivel de procesamiento de transacción es responsable de la coordinación del procesamiento de todas las solicitudes de transacción dentro del sistema. Los servicios del sistema proporcionan componentes y servicios comunes para bloqueo y reservación, servicios gráficos de objeto, reglas comerciales y administración de alertas, administración del flujo de trabajo, administración de seguridad, propiedad individual o de equipo, notificaciones externas, servicios instantáneos, elaboración de informes y administración de documentos. El nivel de lógica de aplicación proporciona al sistema la funcionalidad específica de la aplicación que requiere para un proceso comercial vertical determinado. Este nivel consiste en el modelo de datos unificados, un mecanismo para organizar y modelar la información comercial específica de la subrogación, la lógica de la aplicación relacionada con el modelo, la lógica de la aplicación relacionada con la transacción y la configuración. El subsistema JView™ proporciona un sistema y un procedimiento para optimizar y enriquecer la interacción entre las organizaciones. De manera importante mejora el tiempo 10 de respuesta del sistema mediante la descarga de la generación de HTML al sistema cliente y de esta manera reduce sustancialmente el procesamiento realizado en el servidor. Reduce el tamaño de los mensajes transmitidos entre el buscador y el servidor de la red informática, reduciendo sustancialmente de esta manera el ancho de banda de comunicación requerido. Proporciona un conjunto enriquecido de funciones locales (realizado en el sistema cliente) que elimina las solicitudes del servidor. Esto adicionalmente reduce la carga de procesamiento en el servidor y mejora en gran medida la capacidad de respuesta del sistema en general. Jview™ de Siteras utiliza por completo los estándares existentes de buscadores en redes informáticas, de esta manera mantienen la compatibilidad con los buscadores cliente existentes (es decir, soporta una implementación real de cliente delgado y no utiliza extensiones especiales de buscador, por ejemplo, complementos del buscador, aplicaciones del lenguaje Java, o controles de ActiveX). Al usar esta tecnología de núcleo, la combinación de la funcionalidad comercial específica de la subrogación de la ESN y la tecnología avanzada proporciona muchos beneficios únicos para la industria de los seguros. Los beneficios de la red de subrogación electrónica incluyen hacer más eficiente el flujo de trabajo de subrogación dentro de la compañía y 11 entre compañías; reducir la cantidad de manejo de documentos de subrogación así como de sus transacciones; mejorar la productividad tanto del personal que interviene en la subrogación (parte demandante) como del personal de la oficina de reclamaciones (contraparte), al eliminar muchas tareas manuales, reducir el tiempo de ciclos de las reclamaciones de subrogación; incrementar las recuperaciones de subrogación mediante una mejor asignación de recursos y contestaciones automáticas a las reclamaciones; reducir los costos de las pérdidas de las reclamaciones a través de la auditoría electrónica de los archivos de subrogación; mejorar la satisfacción del cliente al acelerar los reembolsos deducibles; reducir los gastos de manejo de pagos además de proveer información de administración valiosa. Breve Descripción de las Figuras Las características y los aspectos inventivos de la presente invención serán evidentes al leer la siguiente descripción detallada y los dibujos de los cuales se presenta una breve descripción: La figura 1 muestra varias interfaces con los usuarios que se puede implementar en la operación de una ESN de conformidad con esta invención. La figura 2 muestra un diagrama de bloques de diversos módulos/ subsistemas que se pueden incluir en una 12 ESN formados de conformidad con las enseñanzas de la presente invención. La figura 3 muestra un proceso esquemático y de flujo de trabajo de la manera en que la demanda inicial se puede presentar a la ESN que se muestra en la figura 2. La figura 4 ilustra un proceso de flujo de trabajo que muestra la manera en que se puede crear una carpeta electrónica compartida y un seguimiento de la auditoría para los archivos que se alojan en la ESN que se muestra en la figura 2. La figura 5 muestra un proceso esquemático y el flujo de trabajo para transferir documentos electrónicos y digitales en la ESN y para digitalizar documentos impresos en la ESN.

La figura 6 muestra un proceso esquemático de un flujo de trabajo de un enrutamiento en la red por demanda para la ESN que se muestra en la figura 2. La figura 7 muestra una vista esquemática de un enrutamiento de demanda fuera de red y un proceso de flujo de trabajo para la ESN que se muestra en la figura 2. La figura 8 muestra un módulo de respuesta de una parte que no responde y un proceso del flujo de trabajo para usarse con la ESN. La figura 9 muestra un módulo de opciones de respuesta y un proceso de flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 2. 13 La figura 10 muestra un módulo de negociación en línea y un proceso de flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 2. La figura 11 muestra un módulo de convenios y aprobación automática/ negociación en línea y un proceso del flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 2. La figura 12 muestra el proceso de flujo del trabajo para una característica de rechazo automático/ electrónico adaptado para usarse con la ESN que se muestra en la figura 2. La figura 13 muestra un módulo de convenio automático y un proceso de flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 2. La figura 14 muestra un módulo de contrademanda automático y un proceso de flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 2. La figura 15 muestra un módulo de asignación (árbitro) y un proceso de flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 2. La figura 16 muestra un módulo de asignación (a los vendedores) y un proceso de flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 2. La figura 17 muestra un módulo de pago manual y un proceso de flujo de trabajo adaptado para usarse con la ESN 14 que se muestra en la figura 2. La figura 18 muestra un módulo de pago electrónico y un proceso de flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 1. La figura 19 muestra un módulo de conexión en red para el pago de subrogación y el proceso de flujo de trabajo adaptado para usarse con la ESN que se muestra en la figura 2. La figura 20 muestra un modelo de datos unificado (módulo) adaptado para usarse con la ESN que se muestra en la figura 2. La figura 21 es un diagrama que muestra una jerarquía de objeto STM en el subsistema Jview™. La figura 22 muestra el concepto de diversas partes y su (relación) con una carpeta transaccional (por ejemplo, una transacción de subrogación de seguros) dentro del sistema de gestión de flujo de trabajo entre organizaciones. La figura 23 muestra un ejemplo de un "formulario" Jview™. La figura 24 muestra un ejemplo de una "forma" de Jview™. La figura 25 es un diagrama de relación con la entidad de las entidades principales de datos dentro del sistema de gestión del flujo de trabajo entre organizaciones. La figura 26 es un diagrama que muestra la 15 arquitectura del sistema para el procesamiento de transacciones entre las organizaciones. La figura 27 es un diagrama que muestra las capas diferentes de la arquitectura de la estructura de la aplicación para el procesamiento de transacciones entre las organizaciones; y La figura 28 es un diagrama que muestra una arquitectura de procesamiento de transacciones típica basada en redes informáticas y la relación de la estructura de la aplicación (para el procesamiento de transacciones entre organizaciones) dentro de esta arquitectura. Descripción Detallada de la Invención ANTECEDENTES - Red de subrogación electrónica (ESN) Subrogación Definida La subrogación de los seguros se define como el proceso mediante el cual una compañía de seguros (parte demandante) busca el reembolso por parte de otra compañía (contraparte) o persona para una demanda que ya se ha pagado. Los ejemplos de subrogación incluyen: El vehículo de Sandra se detiene en una señal de alto, el vehículo de Pedro la golpea por detrás; el automóvil de Sandra resulta dañado y ella presenta algunas lesiones. Sandra presente una reclamación a su compañía de seguros de su automóvil. Su compañía de seguros paga a Sandra los daños y lesiones, pero cree que Pedro fue el culpable del 16 accidente. La compañía de seguros de Sandra (parte demandante) entonces hará una subrogación en contra de la compañía de seguros de Pedro (contraparte) para recuperar el costo de la reclamación que pagó a Sandra. La casa de Tom se incendia como resultado de un incendio de la tienda de al lado. Tom presenta una reclamación con la compañía de seguros del propietario de su casa. La compañía de seguros de Tom paga los daños ocasionados a Tom, pero cree que la tienda es la responsable de ocasionar el incendio. La compañía de seguros de Tom entonces subroga en contra de la compañía de seguros de la tienda la cantidad de la demanda que pagó. Daniel pierde el control de su vehículo deportivo y golpea a un árbol después de que se deshacen sus neumáticos. Daniel presenta una reclamación con la compañía de seguros de su auto quien paga por estos daños y después presenta una subrogación en contra del fabricante del auto y/o el fabricante de los neumáticos para recuperar el costo de la reclamación. El vehículo de Jane es golpeado por un motociclista que no tiene seguro, Jane presenta una demanda con su compañía de seguros de auto. Su compañía de seguros paga los daños a Jane, pero cree que Bob fue el responsable del accidente. La compañía de seguros de Jane presenta una subrogación en contra de Bob para que pague el costo de la 17 demanda. Proceso de Subrogación Actual La subrogación actual se hace de manera manual, es un proceso que requiere muchos documentos. Algunas aseguradoras tienen sistemas de información que ayudan a identificar las oportunidades de subrogación, pero muy pocas presentan una comunicación electrónica con otras aseguradoras. El proceso de subrogación inicia cuando la demanda se reporta en primer lugar a la aseguradora a través del asegurado. Durante el proceso de investigación de la demanda, la aseguradora determina si hay una oportunidad de subrogación. Si se "clasifica" una demanda con una oportunidad de subrogación, el archivo se transfiere a la oficina de subrogación (las aseguradoras más grandes cuentan con unidades especializadas para la subrogación, mientras las aseguradoras más pequeñas típicamente manejan la subrogación de sus oficinas en el campo con ajustadores de la demanda). Una vez que se paga la demanda, la oficina de subrogación prepara un archivo de subrogación que consiste en una carta de demanda y algunos documentos de apoyo. La carta de demanda contiene la información básica sobre la demanda, por ejemplo, la cantidad demandada, el número de demanda, etc., así como la responsabilidad que considera la aseguradora demandante 18 que pertenece a la aseguradora de la contraparte. El archivo de subrogación entonces se envía por correo a la aseguradora contraparte. Los documentos de apoyo usualmente incluyen una copia del estimado del daño que se pagó por la demanda, alguna prueba del pago y copias de cualesquiera facturas asociadas (la factura de la renta de un auto, por ejemplo). Sin embargo, los documentos de apoyo pueden incluir muchos otros tipos de documentos que incluyen informes de la policía, fotografías, informes de valuación del vehículo, declaraciones de los testigos, etc. Una vez reunido, el archivo de subrogación (denominado "demanda") se envía por correo a la aseguradora contraparte. Los departamentos de subrogación con frecuencia tienen dificultad para determinar adonde enviar las demandas de subrogación, especialmente cuando la contraparte es una aseguradora grande con cientos o miles de oficinas de reclamos. Como resultado, las demandas de subrogación con frecuencia se envían a una ubicación equivocada. Típicamente, las aseguradoras reciben y manejan archivos de subrogación en sus oficinas de campo. Estas reclamaciones se conocen como reclamaciones de tercera parte. Si una demanda de subrogación se envía a una oficina equivocada, se le da una nueva ruta hacia la oficina adecuada. Esto puede tomar semanas e incluso meses en el proceso. Una vez que la demanda finalmente llega al 19 manejador adecuado del archivo (usualmente un ajustador de reclamos), el manejador de archivos compara los hechos de la demanda con los hechos de la reclamación que tiene en su archivo. Usualmente, la aseguradora de la contraparte asegurada habrá presentado ya una reclamación para el momento en que la aseguradora de la contraparte recibe la demanda de subrogación. El ajustador de reclamación de la aseguradora de la contraparte entonces investiga la reclamación y determina si la demanda de la aseguradora demandante es justificable. Con frecuencia esto incluye obtener documentación adicional de la aseguradora demandante incluyendo fotos de los daños, declaraciones de los testigos, etc. si el ajustador está de acuerdo con la demanda, entonces autoriza el pago de la reclamación. La mayoría de los archivos de subrogación de automóviles se establecen de esta manera, es decir, sin negociación. Si no está de acuerdo con la demanda, entonces niega la reclamación o negocia la reclamación con la aseguradora demandante. Típicamente, la negociación se realiza vía telefónica y los detalles de la negociación usualmente no se registran. Si el acuerdo se alcanza finalmente, la contraparte paga la cantidad acordada. Si no se alcanza un acuerdo, entonces el archivo se va a arbitraje o litigio. Si la parte responsable es un conductor no asegurado (U ), la mayoría de las aseguradoras envían el esfuerzo de recaudación a una 20 agencia de recaudación. La mayoría de los propietarios principales y aseguradoras dañadas son miembros de redes de arbitraje, organizaciones no lucrativas creadas para arbitrar las reclamaciones de subrogación entre las aseguradoras. Los miembros de las redes de arbitraje siempre envían sus archivos de arbitraje al servicio de arbitraje de la red de arbitraje. Las redes de arbitraje cargan una cuota por presentar y el proceso de arbitraje usualmente requiere cerca de 90 días. Si alguna de las partes, la aseguradora demandante o la aseguradora de la contraparte no es miembro de la red de arbitraje, entonces el archivo se va a litigio. El pago entre las aseguradoras también es poco eficiente. Típicamente, se cortan cheques para todos y cada uno de los archivos entre las aseguradoras. Esto puede ocasionar cientos o miles de cheques que fluyen diariamente en ambas direcciones entre las aseguradoras principales. Una vez que el pago se recauda, la aseguradora demandante se integra a su asegurado el deducible pagado, nuevamente con el cheque. Debido en gran parte a todo el papeleo y los procesos manuales, el ciclo de subrogación con frecuencia es muy largo. Un ciclo típico para un archivo de subrogación de automóvil promedio es de 90 a 120 días. El ciclo puede ser 21 mucho mayor para los archivos que van a arbitraje o litigio, las reclamaciones con pérdida total y las reclamaciones de conductores no asegurados. La información de la administración del flujo de trabajo en la subrogación (como es típico en cualquier proceso basado en papeleo) usualmente es escaso. Algunas aseguradoras cuentan con información limitada en el proceso del lado de la demanda y muy pocas aseguradoras, tienen una información de gestión significativa del lado de la contraparte. Tipos de subrogación Daños físicos al automóvil Las reclamaciones por daños físicos a un automóvil ("APD") son las reclamaciones asociadas con el daño físico a un vehículo de un asegurado, comúnmente debido a una colisión. El vehículo puede ser reparable o puede ser una pérdida total. Otras reclamaciones que caen dentro de esta categoría incluyen vehículos robados y vandalismo. Pagos Médicos/ protección por lesiones personales Las reclamaciones por pagos médicos y protección por lesiones personales son el resultado de las lesiones o enfermedad de una persona que están cubiertas por una póliza de seguro. Las reclamaciones de pagos médicos/ protección por lesiones personales incluyen lesiones que son el resultado de una colisión entre vehículos. 22 Propiedad Las reclamaciones por propiedad son el resultado del daño ocasionado a la propiedad personal o a las propiedades. Algunas reclamaciones de subrogación por propiedad pueden ser sencillas, mientras otras pueden ser muy largas y complejas para su negociación. Los volúmenes son mucho más bajos que las reclamaciones de automóviles, pero la subrogación por propiedad es un flujo de trabajo muy similar a los daños físicos a un automóvil. Responsabilidad de producto Las reclamaciones por responsabilidad de productos son el resultado de los daños ocasionados por algún defecto de un producto. Las reclamaciones de subrogación por responsabilidad de producto usualmente involucran negociaciones complejas y su volumen es bajo. Compensación de trabajadores Las reclamaciones por compensación a los trabajadores son el resultado de las lesiones que se presentan durante las horas laborables y al realizar las tareas propias del trabajo. Algunas reclamaciones de subrogación de compensación a los trabajadores pueden ser sencillas, mientras otras pueden ser complejas en su negociación. Seguro de salud Al igual que en las reclamaciones por propiedad y por 23 responsabilidad, las reclamaciones de un seguro de salud también son subrogadas cuando la enfermedad o lesión ha sido ocasionada por negligencia de otra parte. Tendencias de la subrogación Las aseguradoras comenzaron a dedicar personal a la subrogación a mediados de 1990. Históricamente, los ajustadores de reclamaciones en el campo manejaban las reclamaciones de subrogación. Cuando las aseguradoras más grandes comenzaron a comprender la importancia y el tamaño potencial de la recuperación en dólares de la demanda de la subrogación crearon centros especiales de subrogación (usualmente centralizados o regionalizados) dedicados a recuperar la subrogación. La función de subrogación no es muy automatizada en general. Muchas de las aseguradoras más grandes han implementado un sistema de clasificación rudimentario para identificar una subrogación, pero muy pocas han implementado una automatización para un flujo de trabajo en la subrogación en toda la empresa. Los procesos de papeleo y manuales aún dominan los procesos de subrogación. Hace algunos años, la industria reconoció la necesidad de mejorar la comunicación de los archivos de subrogación entre las compañías. A través del Instituto Nacional de Normalización de los Estados Unidos ("ANSI"), la industria formó un comité de normalización que completó una 24 especificación EDI X12 para la subrogación en febrero de 2001. La normalización no se ha implementado en ninguna de las aseguradoras. La normalización define casos comerciales para sólo un subconjunto de casos comerciales del mundo real. Además, asume que todas las aseguradoras soportan la normalización e implementan su propia lógica de programas y sistemas de programación de extremo posterior para interpretar los datos y ejecutar su flujo de trabajo. De esta manera, existe la necesidad de un sistema y proceso de subrogación electrónico para todos los tipos de reclamaciones de seguros, incluyendo los que se identifican bajo la sección titulada "tipos de subrogación". Los beneficios de la red de subrogación electrónica ("ESN") de la presente invención incluye: hacer más eficiente el flujo de trabajo de subrogación dentro de la compañía y entre las compañías; reducir la cantidad del manejo de papeleo de los documentos de subrogación y las transacciones; mejorar la productividad de ambas partes, la demandante y la contraparte; reducir el ciclo de las reclamaciones de subrogación; incrementar la recuperación de subrogación a través de contrareclamaciones automáticas; reducir los costos de las pérdidas de las reclamaciones a través de la auditoría electrónica de los archivos de subrogación; mejorar la satisfacción del cliente acelerando los reembolsos de los deducibles; reducir el pago por el manejo de gastos y mejorar la información de gestión 25 valiosa. DESCRIPCIÓN DETALLADA - Red de subrogación electrónica (ESN) La descripción detallada a continuación se puede presentar en términos de programa, estructuras de datos o procedimientos que se ejecutan en una computadora o red de computadoras. Estas descripciones y representaciones de procedimiento son los medios usados por los expertos en la técnica que representan de manera más efectiva la sustancia de su trabajo para otros expertos en la técnica. Como se mencionó anteriormente, la ESN actúa como una compensación electrónica para las demandas y respuestas de la subrogación. La ESN es un sistema y proceso implementados en una computadora basados en Internet que permiten que las aseguradoras interactúen entre sí además de interactuar con otras partes (árbitros, abogados, agentes de recaudación, etc.) involucrados en el proceso de subrogación. Con la ESN, las partes pueden enviar y recibir de manera electrónica las demandas de subrogación, anexar documentos de apoyo (estimados, fotografías, informes policiales, etc.), negociar en línea, establecer archivos automáticamente, asignar archivos a árbitros y vendedores, visualizar y transferir reportes en línea, auditar de manera automática archivos, recibir alertas y notificaciones electrónicas y mucho más. Además, la ESN 26 incluye la capacidad de enviar y recibir pagos electrónicos y fechas de vencimiento de los pagos netos. Con los reportes en línea de la ESN, las partes tienen acceso a una información de administración poderosa tanto en las demandas de subrogación emitidas como en las demandas de tercera parte recibidas. Debido a que la ESN se basa en redes informáticas, se puede tener acceso a la información en cualquier momento, en cualquier lugar en donde un usuario tenga acceso a Internet y la implementación con frecuencia es simple y sencilla, ya que no necesita la instalación de programas y sistemas de programación. De ser necesario, la ESN puede hacer interfaz directamente con los sistemas de reclamación virtualmente en cualquier formato en un modo de lotes o en tiempo real. La ESN se refiere a un sistema y proceso basado en Internet o en otra red para el manejo electrónico y el establecimiento de transacciones de subrogación entre compañías. La ESN proporciona un sistema para facilitar las transacciones de subrogación y el flujo de trabajo entre todas las partes involucradas en la subrogación. Como se puede observar en la figura 2, la ESN puede incluir traducción de datos, colaboración, flujo de trabajo, enrutamiento de demandas, seguridad, funciones comerciales, reglas comerciales, pagos electrónicos, reportes de la carpeta de subrogación y módulos o subsistemas de conectividad. Cada 27 sistema o módulo, uno o más de los cuales pueden usarse para procesar una demanda, pueden incluir programas y sistemas de programación, componentes físicos de cómputo o ambos que faciliten el proceso de una demanda. La red de subrogación electrónica ("ESN"), como se indica en la figura 2, es un método para procesar las reclamaciones de subrogación de un seguro a través de una red electrónica. Como se observa de mejor manera en la figura 2, la ESN contiene una variedad de componentes y procesos: Presentación de la Demanda de Subrogación y Administración de Documentos; Flujo de Trabajo de la Comunidad de la Subrogación; Enrutamiento de la Reclamación de Subrogación; Acciones de Seguimiento de la Subrogación; Reglas y Alertas Comerciales de la Subrogación; Asesor de la Subrogación; Valuación del Vehículo de la Subrogación; Colaboración en la Subrogación; Convenio Automático de la Subrogación; Contra Reclamaciones Automáticas de la Subrogación; Asignación de la Subrogación a Terceras Partes; Manejo de los Pagos de la Subrogación; Red de Pagos de la Subrogación; Elaboración de Informes de la Administración de la 28 Subrogación ; Referencias de la Subrogación; y Modelo de Datos Solicitados para la Subrogación. Presentación de la información de la demanda de subrogación y administración de documentos Como se observa mejor en la figura 3, la ESN proporciona un método para presentar demandas de subrogación de manera que proveen un mecanismo para transmitir información de demandas estructuradas (datos de las reclamaciones del sistema de reclamaciones) no estructuradas (documentos e imágenes de apoyo) y proporciona un mecanismo para digitalizar los documentos de apoyo en papel. Entonces, en la operación la ESN proporciona un proceso y un sistema para realizar las siguientes operaciones: introducir manualmente la información de las demandas de subrogación en la ESN; transferir el archivo de los registros de la demanda de subrogación en la ESN; transmitir archivos de la demanda de subrogación en la ESN a través de una interfaz electrónica. La función de transferencia de un archivo permite que una parte use las capacidades de transferencia de archivo dentro de la ASP de la ESN para transferir manualmente un archivo de transacciones para su procesamiento. Esta técnica se puede usar con cualquier formato de archivo. Ofrece una 29 seguridad excelente debido a que utiliza el mismo transporte HTTPS que todas las otras funciones interactivas basadas en ASP. De todas las técnicas de interfaz, se requiere la menor cantidad de configuración y establecimiento. Para usar la transferencia y archivos la parte crea un archivo de los registros de la demanda de subrogación desde su sistema de reclamación o subrogación y después transfiere el archivo seleccionando un botón. La ESN entonces correlaciona automáticamente cada registro hacia el modelo de datos solicitado. La ESN soporta ambas interfaces, de lote y de transacción. La interfaz de lote permite que una aseguradora envíe/ reciba de manera automática un lote de archivos de transacciones para/ de la ESN regularmente. Típicamente, se utiliza un protocolo de transferencia de archivos (por ejemplo, FTP, etc.). La transferencia de archivos se automatiza y no requiere ningún procesamiento manual. La interfaz de transacción permite que una parte envíe/ reciba de manera automática las transacciones individuales para/ de la ESN de una manera por evento en tiempo real. Esta interfaz está completamente automatizada y no requiere ningún procesamiento manual. Este tipo de interfaz se usa en donde se necesita la información en tiempo real. Como se observa mejor en la figura 4, una vez que la ESN recibe un registro de la demanda de subrogación, la ESN 30 crea una carpeta de subrogación electrónica, la cual puede contener información estructurada y no estructurada, así como un archivo histórico. El archivo histórico es un archivo de eventos con etiqueta de tiempo para todas las acciones que se llevan a cabo en la carpeta. El archivo histórico contiene un registro de eventos con etiqueta de tiempo que sigue los documentos afectados por el evento y la ID del usuario para el usuario que realizó la acción que creó el evento. El archivo histórico proporciona a ambas partes, la demandante y la contraparte, un seguimiento de auditoría completo. A través de interfaces electrónicas o transferencias de archivos, la ESN puede enviar y recibir mensajes en muchos formatos. Incluyendo archivos, EDI x12, XML o ASCII. La ESN también soporta la norma de demanda y contrademanda de subrogación de automóviles X12N272 de ANSI. Como se puede observar de mejor manera en la figura 5, los documentos de soporte no estructurado se pueden transferir en la ESN generalmente con cualquiera de las siguientes técnicas. Cuando las demandas se presentan electrónicamente, el mensaje electrónico (que contiene los datos de la demanda) puede especificar la IRL (ubicación en Internet) para uno o más documentos relacionados. Al recibir el mensaje electrónico, la ESN automáticamente recupera el 31 documento especificado de la URL especificada. Esta capacidad refiere que el remitente ponga disponibles todos los documentos relacionados en un servidor al que se puede tener acceso a través de Internet. Un acceso seguro a estos documentos se puede proveer de diversas maneras (por ejemplo, VPN, acceso al sistema seguro, certificados digitales del lado del cliente, etc.). Los usuarios anexan documentos de apoyo electrónicos usando la función de anexar de manera directa en la ESN. Los usuarios buscan entre los documentos que desean anexar, seleccionan el documento, seleccionan el documento, seleccionan el tipo de documento desde un menú que se despliega, proporcionan un título y/o descripción del documento, seleccionan las partes que tienen acceso al documento, y después seleccionan un botón para anexar los documentos a la carpeta. Para usar esta función, el documento de apoyo debe estar disponible como un archivo en una máquina local o en un servidor de red disponible. Los documentos de apoyo pueden tener algunos de los siguientes formatos: 32 La ESN entonces convierte el documento fuente en su formato original a un formato estándar para una visualización universal. Los documentos se convierten en los siguientes formatos: Documentos-visor/ complemento de Adobe Acrobat. Gráficos-visor/ complemento de Adobe Acrobat. Audio-cualquier reproductor estándar/ complemento de MP3 (por ejemplo Microsoft Media Player). Video-cualquier reproductor/ complemento de MPEG estándar (por ejemplo Microsoft Media Player). 33 Cualesquiera documentos en papel se pueden enviar a la ESN usando un soporte de fax. Para usar este soporte, el usuario primero debe usar una función de "anexar rápidamente" para seleccionar el tipo de documento y después imprimir una hoja de portada especial para fax. Esta hoja de portada entonces se coloca en la parte superior del documento que será enviado por fax. El documento entonces se puede enviar por fax a la ESN. Al recibir el fax, la ESN automáticamente digitaliza la cubierta especial (usando un OCR) para los códigos especiales en la información. Al usar esta información, el sistema anexa el documento a la carpeta de demanda adecuada. La ESN administra diversas versiones de soporte de documento. Flujo de trabajo de la comunidad en la subrogación La ESN administra el flujo de trabajo entre las partes (dos o más) dentro del proceso de subrogación de manera que provee un flujo de trabajo consistente para la colaboración entre las compañías, prevé una información de estado en tiempo real a todas las partes involucradas y activa un flujo de trabajo específico por compañía con base en los eventos y las condiciones de excepción dentro del flujo de trabajo. El modelo de flujo de trabajo específico de la subrogación incluye estados de flujo de trabajo entre las compañías, transiciones, condiciones, estado, indicadores de 34 acción, etc. El flujo de trabajo específico por compañía también se provee dentro del contexto del flujo de trabajo de la comunidad. Como se puede observar de mejor manera en la Tabla 1, la ESN puede soportar códigos estándar para representar el estado de una demanda en cualquier punto del proceso (es decir, el flujo de trabajo de la subrogación entre compañías estándar). Estos códigos estándares establecen la base para una comprensión consistente y una comunicación entre las partes respecto al estado de una demanda determinada. De esta manera, estos códigos representan el estado del archivo de subrogación entre partes en la ESN. Adicionalmente, la ESN se puede configurar para permitir la definición de los códigos del estado específico de las partes (es decir, el flujo de trabajo de subrogación dentro de la compañía). Estos códigos permiten que una organización defina los estados de flujo de trabajo adicionales que son específicos para sus procesos comerciales, mientras mantienen una definición de procesos estándar entre las organizaciones. Enrutamiento de reclamaciones de subrogación La ESN enruta las demandas de subrogación a las contrapartes. Un algoritmo de enrutamiento combina un índice específico de la parte demandante y un algoritmo heurístico para determinar la contraparte. Los datos en realidad nunca 35 abandonan el servidor de la ESN, el enrutamiento es virtual, y el manejador de archivos recibe la notificación de la demanda en la ESN a través de una notificación electrónica (correo electrónico, página, mensaje de texto, etc.). Si recibe una notificación a través del correo electrónico, entonces la ESN proporciona un enlace de URL para que el usuario acceda a la ESN y al archivo de demanda adecuado. Como se observa de mejor manera en la figura 6, una contraparte que es un miembro de la ESN mantiene reglas de enrutamiento en la ESN, de manera que la ESN puede enrutar de manera electrónica los archivos de subrogación entrantes hacia la oficina, grupo o manejador de archivos adecuado. La ESN soporta el enrutamiento semiautomatizado y el enrutamiento automatizado. Con el enrutamiento semiautomático, la demanda inicial se enruta a un coordinador de contrapartes ("enturador") en una ubicación central, regional u oficina de reclamaciones. Al usar la ESN, el enrutador puede visualizar todas las demandas entrantes ("enrutamiento pendiente"). Usando su sistema de reclamación interno, los enrutadores pueden determinar el número de reclamación de la contraparte asociado con la demanda y el grupo o el individuo asignado actualmente al archivo. El enrutador entonces es a la función "enrutar demanda" para actualizar la demanda con la información adicional (por ejemplo, el número de reclamación, 36 el porcentaje de responsabilidad, etc.), y transfiere la demanda al grupo/ individuo correcto dentro de la organización de esta parte. Después de completar esta función, el sistema ahora "pone en cola" esta demanda para el grupo/ individuo especificado ("respuesta pendiente"). Con el enrutamiento automático, la contraparte transfiere a la ESN un archivo "índice de la reclamación" regularmente (por ejemplo diario). El índice de reclamación provee la información de resumen sobre una reclamación, lo que permite hacer una búsqueda en la ESN para ubicar la reivindicación. Cuando la ESN recibe una demanda inicial para esta parte, puede usar el índice de reclamación para enrutar de manera automática la demanda hacia el grupo/ individuo correcto dentro de la organización de la contraparte. El archivo índice de reclamación también puede ser la base para dar soporte a los agentes automatizados dentro de la ESN que pueden revisar y responder de manera automática a las demandas iniciales con base en la reglas comerciales. La ESN también provee una función para informar por primera vez sobre condiciones de pérdida en donde la ESN o la contraparte puede determinar si la reclamación es el primer informe de pérdida y automáticamente enrutar el archivo a la unidad de notificación de pérdida de la contraparte. Cuando la contraparte recibe la demanda inicial, si el "solicitante" 37 (según se identifica en la demanda inicial) está asegurado/ cubierto por la contraparte, pero no existe reclamación (dentro del sistema de reclamaciones de la contraparte) para la fecha de pérdida especificada, entonces esta demanda representa una primera notificación de pérdida. En este caso, la contraparte primero necesita establecer un archivo de reclamación (dentro de su sistema) antes de procesar esta demanda. Para soportar este flujo de trabajo, el sistema colocará esta demanda en un estado especial "primera notificación de pérdida". De esta manera permite que la contraparte identifique fácilmente y procese todas las demandas entrantes en esta condición. cOn un enrutamiento automatizado, esta condición se puede identificar automáticamente añadiendo un índice contenedor de política. Con el enrutamiento semiautomatizado, el coordinador de enrutamiento, que puede ser un operador humano, puede usar la función "primera notificación de pérdida" (FNOL) para mover la demanda a este estado. La ESN también soporta la capacidad de volver a asignar un archivo a otro manejador de archivo a través de la función de asignación. Esta función de enrutamiento electrónico está disponible para las partes que son miembros de la ESN. Como se observa de mejor manera en la figura 7, una 38 contraparte que no es un miembro de la ESN recibirá una notificación por correo electrónico o fax sobre una demanda de subrogación de la ESN. Un usuario de la contraparte puede seleccionar un enlace en un correo electrónico para acceder al archivo de demandas de subrogación específica. Las contrapartes que no sean miembros de la ESN pueden reasignar archivos al transferir la notificación de correo electrónico de la ESN al sistema por primera vez, el sistema presenta un tutorial que provee una introducción básica a la ESN y familiariza al usuario con las características básicas y será necesario que conozca para responder de manera correcta a la demanda emitida. Las partes demandantes tienen acceso al directorio en línea de los contactos de la contraparte fuera de la red, ubicaciones y direcciones de correo electrónico. Este directorio se actualiza de manera automática cuando se emite una demanda a un nuevo contacto fuera de la red y todas las partes demandantes pueden tener acceso a éste en la ESN. Acciones del seguimiento de la subrogación La ESN establece y activa de manera automática acciones de seguimiento para los usuarios demandantes. Como se observa de mejor manera en la figura 8, si una contraparte no responde a la demanda de subrogación, la parte demandante puede enviar varios recordatorios por correo electrónico a una contraparte. Una parte demandante 39 puede definir los recordatorios de la acción de seguimiento específicos por compañía en la ESN; por ejemplo, la ESN puede emitir recordatorios a los usuarios demandantes para que contacten a un usuario de la contraparte si no hay respuesta en un marco de tiempo específico definido por la parte demandante. La ESN puede emitir alertas, recordatorios y las siguientes acciones ya sea para 1) un equipo agrupado de usuarios demandantes de manera que un usuario determinado en la agrupación obtiene el archivo que requiere la siguiente acción, o 2) un manejador de archivos individual. Reglas v alertas comerciales de la subrogación La ESN modela las prácticas comerciales únicas para cada miembro de la red y para manejar las condiciones de excepción en el flujo de trabajo de manera que facilita la persistencia entre cada práctica comercial de los miembros y el flujo de trabajo en la red. El procesamiento y las funciones realizadas por la ESN puede verse afectado por diversos parámetros específicos de las partes y sus configuraciones. De manera colectiva, estas configuraciones representan las "reglas comerciales" de una parte y permiten que una parte personalice el procesamiento de la ESN para soportar los procesos comerciales específicos de la parte. Las partes pueden definir perfiles específicos del software global o de comercio y las reglas comerciales. Por ejemplo, cuando la ESN procesa una transacción determina, 40 la lógica dentro de la ESN hace referencia a las "reglas comerciales" de la parte identificada y las usa para controlar el procesamiento de la transacción. La ESN permite que las reglas comerciales específicas para las partes se dividan en general en un número de categorías principales como se indica a continuación. Reglas de la compañía Definen la configuración global para esta parte. Reglas de flujo de trabajo Definen el flujo de trabajo específico de la parte. Reglas de enrutamiento Definen las configuraciones específicas de la parte para el enrutamiento por demanda automatizado o semiautomatizado. Estas configuraciones típicamente se usan para controlar la manera en que la ESN enruta una demanda entrante dentro de la organización de una parte. Reglas de auditoría de expedientes Definen las reglas específicas de la parte para las auditorías y condiciones del expediente. Esto incluye los siguientes grupos: General - si la pérdida es total, se deduce el rescate. Específico para la parte demandante - para cualquier respuesta recibida, es el porcentaje de recuperación menor que el porcentaje de recuperación mínimo. Específico de la contraparte - cantidades de daño 41 anormal especificadas como el porcentaje en comparación con el daño de la colisión, es decir, el reembolso por la renta, remolque, pérdida de uso, etc. (por los límites de la cantidad de la demanda). Las tolerancias máximas para varias cantidades de daños (por límites de la cantidad de la demanda). Reglas de socio comercial Definen las configuraciones específicas de la parte que se aplican a uno o más hechos comerciales. Un conjunto de reglas genérico único se puede establecer para todos los socios. Además, se puede establecer un conjunto específico para un socio comercial determinado. En este caso, estas configuraciones anularán cualquier configuración genérica para este socio específico. Las siguientes reglas también se pueden incluir: los anexos requeridos para las demandas (por límite de cantidad de la demanda) y requieren anexos para las demandas con base en cada código de cobertura reclamado. Los miembros pueden configurar las reglas comerciales específicas por la compañía. Todos los archivos son auditados con base en las reglas comerciales de todas las partes involucradas en la transacción. Se activan las alertas mediante las condiciones de excepción o las violaciones de las reglas comerciales con base en los parámetros de múltiples partes (definidos por TODAS las partes que tienen 42 acceso actualmente a la carpeta), por ejemplo, una contraparte puede recibir una alerta con base en los parámetros de la parte demandante. Una parte particular puede personalizar las alertas. Esta característica permite que una parte determine las condiciones de las excepciones específicas que generan una alerta. Cuando se visualiza un archivo, si existe cualesquiera alerta, se visualiza dentro del archivo un "panel de alerta". Cuando se actúa sobre un archivo, si existen alertas o se detectan recientemente, el usuario recibirá la presentación de un mensaje de advertencia. Para continuar con la transacción, el usuario debe anular de manera explícita este aviso. En este caso, los avisos y el usuario se registran en el editorial. La siguiente lista ilustra las alertas estándar o genéricas que se incluyen en las ESN: Alertas de auditoría de archivo - Estas alertas se refieren a las condiciones de excepción que se detectan con base en las "reglas de auditoría de archivo" definidas para una parte. Alertas de excepción para el socio comercial - Estas alertas se refieren a las condiciones de excepción que se detectan con base en las "reglas del socio comercial" definidas para una parte. Alertas de negligencia comparativas - Estas alertas se refieren a las condiciones de excepción que se detectan con 43 base en las leyes de negligencia comparativa del estado en donde se presentó la pérdida. Para mayor información consulte "soporte de negligencia comparativo" a continuación. Estatutos de alertas de limitación - Estas alertas se refieren a las condiciones de excepción que se detectan con base en el estatuto de las leyes de limitación para el estado aplicable. Asesor de subrogación - La ESN evalúa la mejor ruta de acción dentro del proceso de subrogación de manera que mejore el rendimiento de la subrogación, incrementen las recuperaciones y disminuyan los costos. La ESN puede evaluar, por ejemplo, el costo-beneficio de continuar una demanda y/o continuar una línea particular de acción, por ejemplo, seguir con el litigio, etc. Valuación de un vehículo de subrogación La ESN evalúa la validez de una demanda de subrogación de una tercera parte. Por ejemplo, las auditorías electrónicas para ciertas condiciones del archivo se pueden basar en los parámetros que son configurables de la parte demandante, la contraparte y el valor del vehículo, por ejemplo, la recuperación de la pérdida total, las condiciones de pérdida de uso, etc. Colaboración de subrogación La ESN proporciona un método para que múltiples partes incluyendo a la parte demandante y a la contraparte 44 colaboren de manera interactiva. Como se observa de mejor manera en la figura 9, una contraparte puede aceptar (estar de acuerdo en pagar), rebatir (negociar) o negarse (negarse a pagar) una demanda de subrogación. Como se observa de mejor manera en la figura 10, una contraparte puede preparar una contraoferta que puede incluir una respuesta al porcentaje de la responsabilidad y/o cantidades de daño (por ejemplo, cantidad del daño de la colisión, la cantidad del reembolso por renta, etc.). una parte demandante puede definir una contraoferta mínima aceptable en una base de archivo por archivo y la ESN emite una alerta a la parte demandante si una contraoferta está por debajo del mínimo de la parte demandante. Como se observa de mejor manera en la figura 11, una parte demandante puede definir las reglas comerciales respecto a las contraofertas aceptables mínimas que incluyen el porcentaje de responsabilidad, cantidades de daño, y/o demanda total y la ESN puede aprobar automáticamente las contraofertas si las reglas comerciales de la parte demandante se cumplen. Como se observa de mejor manera en la figura 12, una contraparte puede negarse a una demanda y proveer códigos de negación estándar como respuesta a la parte demandante. Funciones comerciales La ESN proporciona funciones comerciales que soporta el flujo de trabajo de la subrogación. Además de las 45 funciones estándar que se proveen en la tabla 2, el sistema permite que una parte defina las funciones personalizadas que son específicas al proceso y flujo de trabajo comercial. Estas funciones personalizadas se pueden definir para controlar la modificación de visualización de datos. Establecimiento automático de subrogación Como se observa de mejor manera en la figura 13, la ESN proporciona un método para establecer reclamaciones de subrogación entre las partes de manera automática con una escasa intervención humana, o sin ella, al eliminar muchas tareas manuales, y reduce el ciclo de los archivos de subrogación. La ESN funciona para establecer archivos electrónicamente si el archivo pasa las auditorías de las reglas comerciales de ambas partes y las llamadas de responsabilidad de ambas partes (el porcentaje de responsabilidad asignado por cada parte a cada parte asegurada) corresponden o se traslapan. La llamada de responsabilidad de la parte demandante se provee en la presentación de la demanda inicial. La llamada de la responsabilidad de la contraparte se lee a través de la ESN a través de una interfaz electrónica con el sistema de reclamación de la contraparte o a través de un índice de reclamación que proporciona la contraparte. Las capacidades "contra los juegos de azar" evitan que las contrapartes adivinen las reglas comerciales de las partes demandantes 46 y/o las llamadas de responsabilidad. Contrareclamaciones automáticas de subrogación Como se observa de mejor manera en la figura 14, la ESN puede crear contrareclamaciones cuando está en un cumplimiento de regulación, es decir, se configura para que incluya las leyes pertinentes del estado en donde ocurrió la pérdida, de manera que ayuda a reducir las oportunidades de contrareclamación por pérdida, y ayuda a incrementar la recuperación de la subrogación, ayuda a mejorar la productividad tanto de la parte demandante como de la contraparte eliminando muchas tareas manuales, y ayuda a reducir el tiempo de los ciclos para los archivos de subrogación. Cuando se establece la demanda original, la ESN puede auditar el porcentaje de seguridad y las regulaciones de negligencia comparativas del departamento de estado adecuado de seguros entonces, cuando la demanda inicial se establece en un porcentaje de responsabilidad menor al 100% para la contraparte y cumple con las regulaciones de negligencia comparativa del estado de la pérdida, se prepara automáticamente una contrareclamación para la contraparte en contra de la parte demandante para una acción justa relacionada con la responsabilidad. Por ejemplo, si la pérdida se realizó en un estado comparativo puro y las dos partes estuvieron de acuerdo en una responsabilidad del 80% para la 47 contraparte en la demanda inicial, la ESN prepara una contrademanda para la contraparte por la responsabilidad del 20% en contra de la contraparte. Las contrareclamaciones están unidas a la demanda original. La ESN alerta a la parte demandante sobre las auditorías de las reglas comerciales que se están violando. Con la ESN los usuarios pueden crear contrareclamaciones en una de dos maneras; 1) usando una acción "crear contrareclamación", o 2) emitir una nueva demanda en donde la parte demandante y la contraparte numera los enlaces con una demanda existente (en una relación inversa). Crear una contrademanda Una vez que la contraparte a aceptado una demanda, el sistema determina si existe la oportunidad de una contrademanda para esta demanda (dependiendo del porcentaje de responsabilidad y las leyes de negligencia comparativa del estado específico que aplican a esta demanda). En el procesamiento de la función "aceptar" para una demanda, el sistema analiza estas condiciones. Si esta demanda tiene la oportunidad de una contrademanda, entonces el sistema automáticamente lo indica. Un formulario específico de la contraparte "oportunidades de contrademanda" se provee y éste enumera todas las demandas que son candidatos para emitir una 48 contrademanda. Para emitir una contrademanda, la contraparte selecciona una de las demandas del formulario "oportunidades de contrademanda". Cuando se visualiza el formulario, una nueva acción está disponible "crear contrademanda". Esta acción se puede usar para crear un nuevo documento de demanda que se relaciona con la demanda inicial. Cuando este documento se crea (guardándolo), la ESN automáticamente enruta la contrademanda a la parte demandante que emitió la demanda inicial. Al hacerlo, tanto la demanda inicial como la contrademanda se relacionan (es decir, se refieren una a la otra). Vinculación de contrademanda automática Cuando dos compañías emiten demandas entre sí (de manera independiente) por la misma pérdida, en el punto en que se emite la segunda demanda, la ESN reconoce la relación de la contrademanda y automáticamente relaciona las demandas. Esta capacidad maneja la situación en donde ambas compañías creen que la otra es "la responsable". En general, en cualquier momento que la ESN detecta que dos demandas se han emitido entre dos compañías (en donde los números de demandas de la parte demandante y de la contraparte hacen referencia una a la otra); el sistema automáticamente "relaciona" estas demandas. 49 Una vez que se identifica una relación de contrademanda, el usuario fácilmente puede desplazarse hacia delante y hacia atrás entre ambas demandas seleccionando el enlace de la contrademanda. Desde ese momento y en adelante, las capacidades de colaboración de la contrademanda son exactamente las mismas que para la demanda inicial. Adicionalmente, la ESN aplica estos antecedentes de los medios de negligencia comparativa del estado adecuado y emite advertencia en el caso de que se vea afectada la capacidad de una parte para emitir o continuar una contrademanda. Se proveen formularios adicionales para habilitar a la contraparte para que administre las contrademandas que se han emitido. Dentro de cada estado, las leyes de negligencia comparativas se definen, las cuales rigen la capacidad de una parte determinada para emitir una contrademanda. Cuando se "acepta" una demanda por una contraparte, la ESN aplica las leyes de negligencia comparativas del estado de la ubicación de la pérdida. Con base en estas leyes, si se acepta la demanda, la ESN emite advertencias al usuario bajo las siguientes situaciones: no se ha emitido una contrademanda, pero la aceptación de esa demanda evita la emisión de una contrademanda; y una contrademanda se ha emitido, pero la 50 aceptación de esta demanda puede "invalidar" la contrademanda que actualmente está "en negociación". En este caso, el sistema requiere que el usuario anule esta advertencia para que la demanda sea aceptada. Tipos principales de las leves de negligencia comparativas Existen tres tipos principales de leyes de negligencia, comparativa pura, comparativa modificada (49% y 50%) y ninguna (es decir, negligencia de contribución). A continuación se presenta un resumen de la manera en que estas leyes afectan la capacidad de emitir reivindicaciones y contrademandas. Comparativa pura La parte responsable puede emitir una contrademanda por cualquier responsabilidad entre el 1 y el 50%. Comparativo del 50% modificado A menos que ambas partes estén de acuerdo en una responsabilidad del 50%, la parte responsable no puede emitir una contrademanda. Comparativo del 49% modificado La parte responsable no puede emitir una contrademanda. Si ambas partes acuerdan una responsabilidad del 50%, entonces ninguna parte puede emitir una reclamación a la otra. 51 Ninguno No se permite ninguna subrogación. Ninguna parte puede presentar una reclamación. Asignación de subrogación a terceras partes La ESN proporciona un método para asignar archivos de subrogación a terceras partes, de manera que se mejore la productividad tanto de la parte demandante como de la contraparte, se reduzca el tiempo del ciclo de subrogación y se provea el tiempo de gestión consistente. Como se observa de mejor manera en la figura 15, una parte demandante puede presentar un arbitraje a través de la ESN. Una vez que la parte demandante selecciona la función de arbitraje, la ESN electrónicamente notifica a la contraparte que la parte demandante está presentando la solicitud de un arbitraje. Esto proporciona a la contraparte una oportunidad más de acordar antes de unirse al arbitraje. La parte demandante entonces electrónicamente puede presentar arbitraje en cualquier momento después de enviar la primera notificación a la contraparte. A través de esta función de soporte de múltiples partes, la ESN notifica al árbitro que la parte demandante presentó el arbitraje y proporciona al árbitro una lista de todas las demandas que se han presentado para el arbitraje. El árbitro entonces puede introducir las fechas de audiencia, los números de caso y otro tipo de información en el archivo. 52 La contraparte puede revisar el arbitraje presentando en línea y presentado su respuesta. Una vez que se completa la audiencia y se otorga el juicio, el arbitro puede notificar a ambas partes sobre esta concesión a través de la ESN. De esta manera, la ESN se convierte en una "caja de herramientas" electrónica para el arbitraje. La ESN está diseñada para habilitar un acceso controlado a cada carpeta de subrogación "compartida" para múltiples partes. Al hacerlo, cada parte típicamente tiene una "relación comercial" específica para esa carpeta (demandante, contraparte, arbitro, etc.). La ESN define de manera explícita estas relaciones; y para cada relación, la ESN controla de manera explícita la información que se observa dentro de la carpeta y las acciones que se pueden llevar a cabo. Por ejemplo, suponga que se establecen tres partes en la ESN, la aseguradora Gordon, aseguradora Acmé y Arbco. Si Gordon emite una demanda para Acmé, entonces cuando la carpeta de subrogación para esta demanda se crea, la parte demandante será Gordon (relación de demandante) y la contraparte será Acmé (relación de contraparte). De esta manera, todos los usuarios de Gordon tendrán un límite de acceso a los datos y funciones asociadas con la relación del "demandante" cuando accedan a esta carpeta; todos los usuarios de Acmé tendrán un acceso limitado a los datos y 53 funciones asociadas con la relación "contraparte" cuando accedan a esta carpeta. Adicionalmente, si Gordon presenta el archivo para el arbitraje, entonces su árbitro (Arbco) les otorgará acceso al archivo. Al hacerlo, todos los usuarios del Arbco estarán limitados a los datos y las funciones asociadas con la relación "los árbitros" cuando accedan a esta carpeta. Adicionalmente, si Acmé presenta una demanda a Gordon, entonces las relaciones de demandante/ contraparte se intercambian para la carpeta específica de subrogación. Cuando una compañía se establece en ia ESN, se definen todas las relaciones posibles para una compañía determinada. En el ejemplo anterior, tanto Gordon como Acmé estarán configuradas para soportar las relaciones de "demandante" y "contraparte". Sin embargo, Arbco estará configurado sólo para soportar la relación "árbitro" (ya que no puede emitir de manera directa o responder las demandas de subrogación). Como se observa de mejor manera en la figura 16, ya sea que una parte demandante o una contraparte pueda asignar de manera electrónica un archivo de subrogación a un vendedor (por ejemplo, agencias de recaudación, abogados externos, proveedores de servicios, etc.) a través de la ESN. Cuando la parte demandante o la contraparte usa la función de asignar, la ESN automáticamente notifica a la tercera 54 parte que existe un archivo que necesitan trabajar. Dependiendo de la interfaz de la tercera parte, la ESN notifica a través de un correo electrónico con un enlace de URN o pasa en realidad la información del archivo a través de una interfaz al sistema de la tercera parte. La ESN también proporciona la capacidad a las terceras partes para introducir actualizaciones de estado en la ESN. Manejo del pago de subrogación La ESN proporciona un método para manejar los pagos entre las partes involucradas en una reclamación de subrogación de manera que mejora la productividad tanto de las partes demandantes como de las contrapartes eliminando muchas tareas manuales y disminuyendo el costo del manejo de pagos. Como se observa de mejor manera en la figura 17, después de recibir los pagos de las contrapartes, las partes demandantes pueden introducir información de pagos manualmente en la ESN o actualizar archivos de la información del pago (cantidades de pago, fechas, números de reclamaciones asociadas, etc.) en la ESN. La ESN automáticamente cierra los archivos en donde ya se ha hecho un pago por completo. Como se observa de mejor manera en la figura 18, los pagos EFT se pueden activar automáticamente a la aceptación de la contraparte, la ESN puede generar un mensaje a banco de la contraparte para 55 activar la EFT o la ESN puede generar un mensaje a sistema de la contraparte que en su momento emite un mensaje a un banco para activar la EFT (en el último caso, un sistema de la contraparte envía un mensaje de confirmación de la EFT nuevamente a la ESN). Red de pagos de la subrogación Como se observa de mejor manera en la figura 19, la ESN proporciona un método para hacer una red de pagos entre las partes involucradas en una reclamación de subrogación de manera que se mejore la productividad tanto de las partes demandantes como de las contrapartes eliminando muchos pasos manuales y disminuyendo el costo del manejo de los pagos. La ESN funciona para seguir los pagos que se deben y los pagos vencidos en cualquier periodo para cualquier miembro y proporciona la información o archiva de manera automática un pago. Los pagos se pueden hacer en red de manera bilateral (por ejemplo, entre dos partes como se observa mejor en la figura 19) o de múltiples partes (entre una parte y la ESN, que representa todos los miembros que participan en el servicio de red). En la red bilateral, la ESN sigue los pagos que se deben entre dos partes y envía una notificación para la EFT a la parte que tiene el saldo de pago al final de cualquier periodo definido de las dos partes. Por ejemplo, si la parte a y la parte b están de acuerdo en 56 realizar pagos en red semanalmente, la ESN da un seguimiento a la cantidad de todos los pagos que se deben entre a y b en la semana y todos los pagos que se deben entre b y a en la semana, determina qué parte debe más y emite una notificación de pagos a la parte adecuada. En la red de partes múltiples, la ESN pone en red todos los pagos y recibos con todas las partes que participan en el servicio de red para una parte determinada. La ESN entonces recibe el pago de la parte o paga a la parte dependiendo del saldo. Las partes pueden configurar la ESN para definir los periodos de red específicas por parte. La ESN proporciona una información de sesión y un archivo de reconciliación para ubicar los pagos en red para cada archivo adecuado. Notificación del manejo de subrogación La ESN proporciona una información de manejo a los miembros de la red de manera que mejora el rendimiento de la subrogación para todas las partes y proporciona una mejor información del manejo tanto para los administradores de la subrogación como para los administradores de las reclamaciones. La ESN proporciona dos tipos de notificación en línea, detallada y resumen. Para la subrogación, se pueden proporcionar diversos reportes estándar con la ESN (se enumera a continuación). La ESN permite que los miembros filtren, clasifiquen y visualicen los reportes de la administración en línea. Además de los reportes estándar, un 57 miembro puede definir reportes especializados que son específicos para sus procesos comerciales y flujo de trabajo de la organización. Para los reportes de resumen, los datos típicamente se pueden agregar junto con las dimensiones mayores de tiempo, geografía, parte, oficina, región, departamento, manejador de archivo/ equipo y estado. Dentro de estas dimensiones, los elementos de los datos principales que se pueden resumir pueden incluir Demanda Total en Dólares, Respuesta Total en Dólares, Tipo de Porcentaje de Recuperación u otros elementos de datos deseados o pertinentes. Para cualquiera de los elementos de datos identificados, las siguientes estadísticas de resumen generalmente están soportadas: suma, promedio, promedio pesado, porcentaje, máximo, mínimo y conteo. Sin embargo, también pueden soportarse otras estadísticas necesarias. 58 I nformes del dem a n da nte típ ico I nformes de la co ntra parte Archivos pendientes Pagos totales - cantidad de la parte demandante pagada para cerrar la cobertura Demandas totales - cantidad demandada de la parte demandante Número de archivos - número de archivos abiertos Archivos pagados Total de dólares pagados - total de dólares pagados de todos los archivos cerrados Porcentaje de pago promedio - total de dólares pagados divididos entre el total de dólares demandados Número de archivos - número total de archivos cerrados Tiempo de ciclo promedio - fecha de la emisión de la demanda hasta la recepción del pago Tiempo del ciclo Emisión de la demanda hasta la promesa de pago (día) Emisión de la demanda hasta la recepción del pago (día) 59 Contrademandas Total de dólares recuperados - total de dólares recuperados de todos los archivos cerrados Porcentaje de recuperación promedio - dólares totales recuperados divididos entre la cantidad de dólares totales demandados Número de archivos - numero total de archivos cerrados Tiempo del ciclo promedio - fecha de la emisión de la contrademanda hasta la recepción del pago Reportes operativos Los reportes operativos están diseñados para proveer información de la administración a los administradores del sistema. Los reportes estándar incluyen reportes de perfil del usuario y reportes de uso. Referencias de subrogación La ESN proporciona un método para que los miembros de la red buscan referencias de las mejores prácticas entre la industria de las aseguradoras de manera que mejoren el rendimiento de la subrogación en todas las aseguradoras y se provea una mejor información de gestión tanto para los administradores de la subrogación como para los administradores de las reclamaciones. La ESN permite que los miembros hagan referencia a varios parámetros de su operación de subrogación y/o reclamación en contra de la industria agregada con base en la base de datos del ESN. Por ejemplo, las partes demandantes pueden hacer referencia a sus relaciones de recuperación en comparación con la industria en un área geográfica específica; las contrapartes pueden hacer una referencia a sus relaciones de pago en 60 comparación con la industria para un área geográfica específica. Modelo de datos solicitados (UDM) para la subrogación Como se observa mejor en la figura 20, la ESN proporciona un método para organizar y modelar la información comercial específica de la subrogación de manera que provee datos consistentes tanto para las partes demandantes como para las contrapartes y provee la traducción de datos de un formato a otro. La ESN proporciona entidades, atributos y relaciones específicas al flujo de trabajo de la subrogación. Los formatos de los datos entrantes se traducen desde su formato fuente al formato de UDM. Los formatos de datos UDM se traducen a formatos de datos salientes. Traducciones Symantec se realizan de manera que el significado de cualquier elemento particular es consistente y a un archivo a otro. 61 TAB LA 1 Estados entre las com pa ñ ías (estatus) U n a rch ivo de d e ma n da s ó lo p u ed e esta r e n u n o d e l os g u ientes estad os d ife re n ci a d os "e n t re co m pa ñ ías " a l a vez .

Estado diferenciado Descripción Estado diferenciado Indica que ia ESN ha recibido el archivo de la demanda (ya sea de manera electrónica o a través de una transferencia del archivo de la demanda) y que la ESN detectó un error que evita que esta demanda se emita (por ejemplo, tiene datos no válidos o le faltan datos). En este punto, la demanda no se emite a la contraparte y sólo la puede visualizar la parte demandante. Enrutamiento pendiente Indica que la demanda se emitió y se asignó a una contraparte, pero esta parte no ha "enrutado" esta demanda dentro de su organización. Para las contrapartes que usan un enrutamiento semiautomatizado, este estado es normal. Para las contrapartes que usan un enrutamiento automatizado este estado no es común. Primer notificación de pérdida Al recibir la demanda, si la demanda representa la "primera pendiente notificación de pérdida" para la contraparte, entonces este estado indica que la contraparte está en el proceso de establecer un archivo de reclamación dentro de su sistema de reclamaciones. Respuesta pendiente Indica que la demanda se ha enrutado a un manejador de archivos dentro de la organización de la contraparte y espera una respuesta inicial. Investigación pendiente Indica que la demanda se revisó inicialmente y la contraparte está haciendo las investigaciones. Contraoferta emitida Indica que la contraparte revisó la demanda y que elaboró una contraoferta para que la considere la parte demandante. Contraoferta aprobada Indica que la parte demandante revisó la contraoferta y está de acuerdo en los términos de la contraoferta Demanda revisada emitida Indica que la parte demandante revisó la contraoferta y que se revisó la demanda para que la considere la contraparte. Impugna En el caso de que la parte demandante y la contraparte no acuerden en esta demanda, y si el arbitraje no es una opción, entonces este estado indica que la demanda está en litigio. En este punto, la parte demandante físicamente evalúa si continúa con el litigio. Negado Indica que la contraparte rechazó la demanda Presentación de arbitraje Indica que la parte demandante quiere presentar esta demanda pendiente a arbitraje y actualmente está en el proceso de preparar sus desacuerdos. 62 Estados agregados Además de los estados diferenciados enumerados anteriormente, el subsistema del flujo de trabajo puede incluir los siguientes "estados agregados". Un estado agregado es un conjunto de dos o más estados diferenciados. Los formularios de estándar se proveen dentro del sistema para que muestren archivos en un estado agregado determinado.

TABLA 2 Funciones del demandador La siguiente excepción enumera las funciones comerciales que típicamente son específicas del demandador. 63 Función Descripción Crear demanda Crea y emite manualmente una nueva demanda Reparación del daño Corrige manualmente una demanda incompleta o no válida que se creó a partir de un archivo de demanda transferido o un mensaje electrónico Borrar Borra manualmente una demanda incompleta o no válida que se creó a partir de un archivo de demanda transferido o un mensaje electrónico. Una vez que se ha emitido un archivo de demanda, no se puede eliminar Revisar Revisar una demanda. Esta función típicamente se usa como respuesta a una contraoferta que se recibió de una contraparte Aprobar Aprueba una contraoferta. Esta aprobación indica la aceptación de la parte demandante de la contraoferta propuesta y permite que la contraparte ahora "acepte" las demandas como las propuso actualmente en la contraoferta Arbitrar Se prepara para presentar una demanda para arbitraje. Esta función indica a la contraparte que la demanda está siendo preparada para su arbitraje. Esta acción coloca el archivo en un estado (solicitud de arbitraje pendiente) que permite que la parte demandante prepare y anexe sus razones para el arbitraje Arbitraje del archivo Presenta formalmente la demanda para el arbitraje. Esta acción garantiza de manera implícita derecho de acceso de "arbitro" para el archivo específico en el servicio de arbitraje, de esta manera permite que procesen la presentación del arbitraje. Complemento Hace una enmienda de una demanda específica para que incluya un "complemento" Controversia Indica que no se puede lograr ningún acuerdo con la contraparte. Esta función se usa típicamente para indicar que la parte demandante no puede lograr un acuerdo con la contraparte y que el arbitraje no es una opción. En este punto, la parte demandante decide si inicia un litigio con el expediente o lo cierra. Conecta el expediente en un estado (en controversia), que permite que la parte demandante identifique fácilmente todos los expedientes en esta condición. Aplicar pago Registra un pago recibido para un expediente. Esta función aplica el pago del expediente específico. Si el pago libera el saldo pendiente del expediente, entonces el expediente se cierra automáticamente Cerrar Cierra un archivo. Esta función típicamente se realiza de manera automática cuando se aplica el pago final del expediente. Cuando se use de manera manual, el usuario requerirá especificar una disposición del expediente que represente la razón del cierre. Reemisión Reemite una demanda a otra parte. Si se emitió una demanda a una contraparte equivocada, esta función permite que la parte demandante vuelva a emitir la demanda a la contraparte adecuada Reabrir Reabrir un expediente que ya ha sido cerrado. Esta función permite que una parte demandante vuelva a abrir un expediente que ya se ha cerrado para el propósito de presentar cantidades de pago adicionales para su recuperación o para proveer nueva información a la contraparte para su reconsideración. Transferencia de La transferencia de un expediente de demandas. Esta función se usa demandas para transferir manualmente un archivo de demandas a la ESN. Al procesar este comando, la ESN asegura que el contenido completo del expediente se almacena de manera satisfactoria en la ESN, entonces se responde de regreso al usuario. En el segundo plano, la ESN procesa para demanda del expediente al crear una demanda y emitir la demanda a la parte adecuada. Se provee un formulario que habilita al usuario para que revise el estado del procesamiento posterior a la transferencia de la demanda. 64 Transferencia de pagos La transferencia de los pagos de un expediente. Esta función se usa para transferir manualmente un expediente de pagos a la ESN. Al procesar este comando, la ESN asegura que el contenido completo del expediente se almacena satisfactoriamente en el sistema. Entonces responde al usuario. En el segundo plano, la ESN proporciona cada pago en el expediente aplicando el pago a un expediente de demanda específico. Si el pago libera el saldo pendiente del expediente, automáticamente cierra el expediente. Un formulario se provee para habilitar al usuario a que revise el estado del procesamiento posterior a la transferencia del pago. Funciones de quien emite La siguiente sección enumera las funciones comerciales que se la respuesta especifican típicamente para quien elabora la respuesta. En general, las funciones principales de la contraparte están disponibles para las contrapartes en red y fuera de red. Cuando una función sólo está disponible para una contraparte en red, se indica de esa manera.

Aceptar Aceptar una demanda. Esta función se usa para aceptar los términos de la demanda como se produce actualmente. Al hacerlo, esto representa un compromiso formal de "promesa de pago" por la contraparte. Contraoferta Hacer una contraoferta. Esta función la usa una contraparte para hacer una contraoferta a una demanda. Cuando se hace la contraoferta, la contraparte puede modificar el porcentaje de responsabilidad o las cantidades de pago. Investigación Indica que la demanda se investiga. Esta función cambia el estado del archivo a "investigación pendiente". Presentar una respuesta Presentar una respuesta a la solicitud del arbitraje. Si !a parte de arbitraje demandante presentó el expediente para arbitraje, el estado del expediente cambiará a "el arbitraje (r)". En este momento, la contraparte puede preparar y anexar su respuesta a la solicitud de arbitraje. Después de que la respuesta se anexa, entonces esta función se usa para indicar que la respuesta se ha presentado. Esta función cambia el estado del expediente a "en arbitraje (A)" que indica que ahora está lista para ser revisada por el árbitro para emitir un juicio final. Rechazar Rechazar la demanda. Esta función se usa para indicar que la demanda se ha rechazado. Cuando se rechaza una demanda, la contraparte debe seleccionar un código de rechazo de la lista de la ESN de los códigos de rechazo estándares. Crear una contrademanda Crear y emitir una contrademanda. Después de aceptar una demanda, la ESN determina si la contraparte puede emitir una contrademanda a la subrogación. De hacerlo, entonces esta función se usa para crear y emitir la contrademanda. Enrutar la demanda Se enruta una demanda entrante dentro de la organización de la contraparte. Para las contrapartes que usan el enrutamiento semiautomatizado de la demanda esta función se usa para enrutar/ asignar manualmente la demanda al equipo o individuo adecuado.

Primera notificación de Indica que la demanda representa la primera notificación de pérdida a la pérdida contraparte. Esta función cambia el estado del archivo a "primera notificación de pérdida pendiente" y permite que la contraparte establezca por primera vez una presentación de reclamación dentro de su sistema de reclamaciones. 65 Funciones del árbitro La siguiente tabla enumera las funciones comerciales que son específicas típicamente de un árbitro.

Funciones comunes La siguiente tabla enumera las funciones comerciales que no son específicas a una relación determinada y pueden compartirse por todas las relaciones (a menos que se observe de manera específica). En donde una función sólo está disponible para una parte en red, se indica de esa manera. 66 Durante la mitad a finales de la década de 1990, el uso comercial del Internet surgió y floreció debido en gran parte al surgimiento de la tecnología de buscadores fáciles de usar (por ejemplo, Mosaic, Netscape, Internet Explorer, etc.)- Este movimiento impulsó la implementación a gran escala de sistemas basados en redes informáticas (servidores de redes 67 informáticas) para dar soporte al número cada vez mayor de usuarios que se basan en buscadores. Una clave para este movimiento fue la definición de los estándares del formato de mensajes (es decir, HTML) que soportaran todos los buscadores. Los servidores de redes informáticas iniciales se usaron para proveer un contenido estadístico al transmitir únicamente páginas de redes informáticas estáticas (que contenían HTML) en un buscador. Al usar este enfoque, los sitios de las redes informáticas se crearon desarrollando conjuntos de páginas de redes informáticas interrelacionadas que estaban enlazadas entre sí. Debido a que el uso del Internet se expandió, se hizo necesario que estos servidores entregaran un contenido dinámico (por ejemplo, una página con el estado actual de una solicitud, una página con la hora de llegada real de un vuelo, etc.). El contenido dinámico requiere que el servidor construya de manera dinámica la información para cada solicitud del buscador. Al hacerlo, el servidor usa una lógica para analizar la solicitud que se solicita, recupera la información de la fuente de datos necesaria y construye de manera dinámica la página de la red informática que contiene HTML (es decir, generación de HTML) para la transmisión hacia el buscador de nuevo. Al usar este enfoque, el buscador no puede distinguir una página estática de una 68 página dinámica. La tecnología de buscador también evolucionó en paralelo con la tecnología de los servidores de redes informáticas. De manera más notable, el desarrollo de la capacidad de generar programas simples de los buscadores estándares que permitían que un usuario interactuara con una página de redes informáticas sin crear una nueva solicitud al servidor de las redes informáticas. Esto mejoró en gran medida la interacción del usuario y las capacidades de respuesta del buscador haciendo posible la construcción de interfaces de usuario enriquecidas (similares a una interfaz estándar de cliente pesado). Esta capacidad de generación de programas simples inicialmente se denominó JavaScript, pero actualmente se hace una denominación formal a éste como EC AScript. Requerimientos v retos Actualmente, la mayoría de los sistemas basados en redes informáticas invierten ciclos de procesamiento para dar formato al contenido dinámico en un formato HTML. Esta carga de procesamiento puede sumar del 30 al 50% de la carga de procesamiento de un servidor típico. Con relación al tamaño de la información transmitida, el tamaño del flujo HTML que contiene esa información es sustancialmente mayor (de 3 a 5x). Esto requiere un ancho de banda de comunicación adicional para la transición. Al depender del 69 servidor para la generación de una página de redes informáticas se requiere una interacción de cada usuario para que sea procesada por el servidor de las redes informáticas, lo que ocasiona un tiempo de respuesta aumentado para diversas operaciones (por ejemplo, clasificar una página de resultados de ciertos elementos, realizar una validación de datos, realizar cálculos, etc.). El substistema Jview™, descrito a continuación, vence estas limitantes al 1) aligerar la carga de la generación de HTML al sistema cliente, de esta manera reduce sustancialmente el procesamiento que se realiza en el servidor, 2) reduce el tamaño de los mensajes transmitidos entre el buscador y el servidor de red informática, de esta manera reduce sustancialmente el ancho de banda de comunicación requerido, 3) proporciona un juego enriquecido de funciones locales (que se realiza en el sistema cliente) que elimina las solicitudes al servidor; esto reduce adicionalmente la carga del procesamiento del servidor y mejora en gran medida la capacidad de respuesta general del sistema, y 4) utiliza completamente los estándares del buscador de redes informáticas existentes de esta manera mantiene la compatibilidad con los buscadores cliente existentes (es decir, soporta una implementación real de cliente ligero y no utiliza ninguna extensión especial del buscador, por ejemplo, complementos del buscador, 70 aplicaciones Java o controles de ActiveX). Estas capacidades se logran con un substistema JavaScript que se ejecuta dentro del buscador y una estructura de mensaje compatible con HTML (un "mensaje de transacción de Siteras" - ST ) que se transmite entre el buscador y el servidor. Dentro del buscador cliente, el subsistema Jview™ consiste en una serie de archivos JavaScript. Como respuesta a una solicitud inicial del servidor de redes informáticas, un pequeño conjunto de archivos JavaScript (es decir, el núcleo del subsistema Jview™) se transfieren al buscador del cliente. Una vez transferidos, estos archivos se colocan en la memoria intermedia a través del buscador (igual que otras imágenes o páginas estáticas). Los archivos adicionales de JavaScript transfieren por módulos cuando los necesitan las diversas interacciones de aplicación con el servidor (una vez transferidos, estos archivos adicionales también son puestos en la memoria intermedia a través del buscador). Estos archivos JavaScript proporcionan al buscador la capacidad de realizar las siguientes funciones de manera local (sin ninguna interacción adicional con el servidor): generación de HTML (toda la generación de HTML se realiza a través del subsistema Jview™ en el cliente); clasificación (que incluye la clasificación de varias columnas); formateo de datos (datos, números, porcentajes, etc.); HTML dinámica (por 71 ejemplo, la expansión/ contracción de paneles/ pestaña); imprimir el formato y la visualización previa; muestra del menú en orden jerárquico; edición y validación sintáctica; validación de la aplicación básica; administración de dominio estático dinámico (es decir, comprobación de un valor en una lista de valores); requiere verificación de campo; cálculos de la aplicación y la medición del tiempo de respuesta. Dentro del sistema Jview™, se emplean técnicas de codificación de un conjunto único de JavaScript para mantener la carga del tiempo de respuesta para el procesamiento del subsistema Jview™ en un mínimo. Cada interacción con el servidor consta de una solicitud/ respuesta estándar de HTTP (el formato del cual está basado en HTML 3.2 y contiene un "mensaje de transacción Siteras" (STM)). El STM es una estructura jerárquica de pares de valor clave (similares a un mensaje basado en XML en estructura y contenido). A diferencia de un mensaje HTML generado por un servidor típico, el STM contiene principalmente datos comerciales. De esta manera, el tamaño de este mensaje se reduce en gran medida. Esencialmente, esta estructura de mensaje se usa para entregar una "isla de datos" al buscador cliente, en donde el subsistema Jview™ puede operarlo genéricamente. NOTA: existen dos razones por las que el subsistema Jview™ usa el formato STM en lugar de XML - 1) el SPM mantiene la 72 compatibilidad con un amplio conjunto de buscadores (muchos buscadores no soportan XML) y 2) XML también es muy verboso y tiene el tamaño de 1-2 x del STM. Beneficios de Jview™ A continuación se presenta un resumen de las características clave y los beneficios de la arquitectura del subsistema Jview™. En conjunto, estas características permiten que el subsistema Jview™ enfoque el rendimiento y funcionalidad de un sistema de cliente pesado, contando con la facilidad de uso y capacidad de manejo de un sistema de cliente dado. Compatibilidad amplia con buscadores El sistema puede funcionar con cualquier buscador que soporte JavaScript V1.2, HTML 3.2 y CSS Level 1.0. Esto brinda soporte para un gran número de buscadores, incluyendo versiones anteriores de buscadores de corriente dominante (por ejemplo, buscadores serie 4.x tanto de Microsoft como de Netscape). No usan ninguna de las características específicas de un tipo o versión de buscador determinado. Cliente ligero completamente El sistema soporta una arquitectura verdadera de "cliente ligero" ya que no requiere o usa ninguna aplicación Java, complemento de buscadores o controles de active-X. Adicionalmente, no utiliza "Cookies" persistentes. 73 Explota la potencia de procesamiento del sistema cliente Muchas de las características del subsistema Jview™ se crearon para utilizar la potencia de procesamiento local de la máquina cliente. Esto mejora en gran medida la capacidad de respuesta del sistema, reduce el número de interacciones con el servidor y libera de la carga al servidor de tener que realizar este procesamiento. El rendimiento del subsistema Jview™ se ha optimizado para presentar un impacto mínimo como sea posible al tiempo de respuesta desde/ hacia el servidor. En general, el procesamiento del subsistema Jview™ añade menos de un segundo al tiempo de respuesta a cualquier interacción con el servidor. Adicionalmente, debido a que la potencia de procesamiento de los sistemas cliente siguen mejorando el tiempo de respuesta debido a que el procesamiento del subsistema Jview™ debe seguir reduciendo. Reduce el tamaño de la transmisión En una base por transacción, el tamaño del flujo STM desde/ hacia el servidor es de 4 a 5 veces más pequeño que la página comparable HTML generada por el servidor. Esta característica lo hace ideal para las aplicaciones en donde el acceso o marcación u otros canales de banda ancha baja (por ejemplo, inalámbricos) aún son dominantes. 74 Reduce la carga de procesamiento del servidor Debido a que libera la carga de la generación de HTML en el sistema cliente y el número reducido de interacciones con el servidor (debido a las capacidades de procesamiento local del subsistema Jview™, la carga de procesamiento para el servidor típico se reduce en un 30 a 50%). Mejora el tiempo de respuesta para el usuario final Debido al tamaño reducido de la transmisión, el uso de HTML dinámico, y las otras funciones y servicios que se realizan localmente, el subsistema basado en Jview™ realiza una implementación HTML basada en un servidor típico en un factor de 8 a 10 veces. Interfaz del usuario enriquecida Debido a las capacidades de procesamiento local (descritas anteriormente), las capacidades de la interfaz del usuario del subsistema Jview™ son comparables con las de muchos sistemas de cliente pesado. Mejora la productividad de desarrollo de la interfaz del usuario El ciclo de desarrollo típico para las interfaces de usuario de cliente ligero que involucra el contenido dinámico inicia con un diseñador de gráficos que crea páginas estáticas como prototipos. Una vez que éstas se aprueban, se proporcionan a un ingeniero para que las codifique (de manera que las páginas se pueden generar de manera 75 dinámica dentro del servidor). Con frecuencia le siguen varias repeticiones de revisión y corrección. En general, este es un proceso de desarrollo en serie. Con la arquitectura del subsistema Jview™, el desarrollo de la interfaz del usuario puede realizarse en paralelo con el desarrollo del código de procesamiento de transacciones del lado del servidor. Todo lo que se necesita desde el principio es la definición de STM (es decir, el paquete de datos) para cada tipo de interacción. Una vez que se define el STM, tanto la interfaz del usuario como el código del lado del servidor se pueden desarrollar en paralelo. Además, no hay un desperdicio de esfuerzos en un prototipo de interfaz de usuario. Diversas repeticiones de la interfaz del usuario se pueden desarrollar y refinar, y una vez terminada, la interfaz del usuario está lista para su producción. Únicamente una prueba de integración final con el código del lago del servidor se necesita para asegurar su operabilidad. Proporciona un fundamento para la personalización de la interfaz del usuario Debido a que la interfaz del usuario se mantiene externa del código del servidor, y debido a que la solicitud de transacción está basada en un mensaje, la arquitectura del subsistema Jview™ soporta un alto grado de personalización de la interfaz del usuario (sin que sea necesario modificar el 76 código en el servidor). Ejemplo comercial La red de subrogación electrónica es un ejemplo comercial de un sistema operativo completo que representa los conceptos descritos en la presente de manera específica para el mercado vertical del procesamiento de reclamaciones de subrogación en la industria de los seguros. Terminoloq ía Esta sección contiene las definiciones terminológicas que son útiles para la comprensión de los conceptos descritos en la descripción a continuación. Cliente basado en buscador Un sistema cliente debe contar con un buscador que soporte HTML3.2 (o superior) y un programa simple ECMA 1.0 (o superior). El programa simple ECMA se conoce comúnmente como JavaScript. Los ejemplos incluyen, sin limitarse a Microsoft Internet Explorer v 4.2 o superior o Netscape Navigator 4.7 o superior. Enfoque de generación de HTML basado en servidor Cualquier enfoque en el servidor produce un flujo de HTML y en donde dicho flujo contiene las etiquetas de la interfaz del usuario de manera que el buscador únicamente necesita "presentar" este flujo de HTML para mostrarlo. Sesión de usuario final Es un periodo finito, usualmente denotado mediante de 77 eventos de entrada al sistema y salida del sistema explícitos que permiten que un usuario determinado realice una o más solicitudes de procesamiento específico para la aplicación. Arquitectura de cliente ligero básica Una arquitectura que proporciona una funcionalidad de aplicación a un usuario final a través de un cliente que se basa en un buscador para acceder a un servidor, en donde el cliente que se basa en el buscador no depende de ninguna extensión especial incluyendo, sin limitarse a esto, complementos no estándares, aplicaciones Java transferibles y/o controles ActiveX. "Mensaje de Transacción de Siteras" (STM) Un mensaje entre un buscador y un servidor se ajusta al formato HTML estándar. Este mensaje se usa para transmitir datos de transacción entre un servidor y el buscador. A diferencia de los mensajes típicos de HTML usa una sintaxis JavaScript para encapsular los datos de la transacción. DESCRIPCIÓN DETALLADA - Jview™ El subsistema Jview™ es un sistema orientado a un objeto que consiste en un conjunto de módulos de archivos gráficos, JavaScript y CSS. El subsistema Jview™ se ejecuta dentro de buscadores que soportan ECMAScript 1.0 (es decir JavaScript). Esta sección contiene las descripciones detalladas del 78 proceso y los componentes relacionados con el subsistema Jview™ y analiza los conceptos y tecnologías conocidos en el campo de la computación por ejemplo: Diseño y programación orientada al objeto; fundamentos básicos de Internet (interacción de buscador/ servidor, solicitudes/ respuestas de HTTP, elementos básicos de TCP/ IP, etc.); HTML; CSS; JavaScript; Modelo del documento W3C (DOM) Archivos del subsistema Jview™ Los archivos que forman el subsistema Jview™ se pueden dividir en las siguientes categorías: núcleo, clases comerciales, imágenes, componentes centrales de visualización, componentes de visualización, componentes de dominio, formas/ formularios, logos y componentes de consulta de la aplicación. Archivos centrales Estos archivos realizan los servicios genéricos del subsistema Jview™ usado por todas las interacciones de la aplicación. Estos archivos son pequeños subconjuntos del sistema de aplicación general. Debido a que estos archivos se recargan mediante el buscador con cada interacción, es importante reducir al mínimo el tamaño total y el número de 79 los archivos en este conjunto. La siguiente tabla describe los archivos incluidos en esta categoría.

Clases comerciales Para cada aplicación vertical, las clases comerciales representan los objetos comerciales que se usan dentro de dicha aplicación vertical. Un archivo se define por el objeto 80 comercial. Estas definiciones se refieren directamente a las definiciones del objeto comercial (clase) que se implementan en el servidor (como se definió en el modelo de datos o depósito de la aplicación). Formularios/ formas En cada interacción del servidor, el subsistema Jview™ muestra un "formulario" o una "forma" en la porción de área de datos de la estructura de la interfaz de usuario del subsistema general Jview™. Un formulario se usa para visualizar una colección o una lista de varios elementos comerciales (comúnmente en un formato de resumen). Una forma se usa para visualizar un solo elemento comercial (comúnmente en un formato detallado). Por ejemplo, un "formulario" se puede usar para visualizar una lista de "solicitudes": una "forma" se usa para visualizar los detalles de una solicitud específica de dicha lista. Para cada aplicación vertical, se definen uno o más formularios y formas. La colección completa de formularios y formas para una aplicación determinada representa el conjunto completo de interacciones en la interfaz del usuario para dicha aplicación. Un sistema de aplicación complejo típicamente consiste en cientos de formularios y formas. Componentes de la visualización central Estos archivos se usan para definir las clases de visualización abstractas desde las cuales otros componentes 81 de visualización específico de la aplicación pueden subclasificarse. Al hacerlo, todos los componentes de la aplicación heredan sus capacidades comunes de las clases de visualización central. Esto permite que el subsistema Jview™ mantenga una consistencia de la interfaz del usuario dentro de una aplicación determinada. La siguiente tabla describe los archivos que se escriben en esta categoría.

Archivo Descripción/ Funciones jvd_Table_000.js El componente de la tabla contiene la definición de la clase abstracta de JVDTable. Esta clase está subclasificada mediante otros componentes de visualización específicos de la aplicación para definir una tabla específica de la aplicación dentro de una forma o formulario. jvd_Pane_000.js El componente del panel contiene la definición de la clase abstracta de JVDPane. Esta clase está subclasificada mediante otros componentes de visualización específicos de la aplicación para definir un panel específico de la aplicación dentro de una forma. jvd_GroupBox_000.js El componente GroupBox (cuadro del grupo) contiene la definición de la clase abstracta de JVDGroupBox. Esta clase está subclasificada mediante otros componentes de visualización específicos de la aplicación para definir un cuadro de grupo específico de la aplicación dentro de una forma. jvjVField_O00.js JView"". Componente de campo. Contiene la definición de la clase JVField. Esta clase se usa para visualizar un solo elemento de datos comerciales dentro de una forma. jvj'vComplexField_00 JV¡ew"vl. El componente de campo complejo contiene la O.js definición de clases de JVComplexField. Esta clase se usa para visualizar una disposición compleja de múltiples datos comerciales dentro de una forma. jvd_Doma¡n_000.js Componente de selección de dominio. Contiene la definición de la clase JVDomainComponent. Esta clase se usa cuando se visualizan varios valores de un dominio a un usuario en una forma. jvjvquery_000.js El componente JVQuery contiene la definición de la clase abstracta de JVQuery. Esta subclase se subclasifica mediante los componentes de consulta (se describen posteriormente). 82 Componentes de visualización Para cada aplicación vertical, uno o más componentes de visualización se definen y estos contienen los elementos de datos específicos de la aplicación que el usuario visualizará en un formulario o en una forma. Para mantener un alto grado de consistencia de la interfaz del usuario dentro de la aplicación general, cada componente de visualización está subclasificado de uno de los componentes de la visualización central. Componentes de consulta Un "formulario" típicamente se define para que muestre una lista de elementos homogéneos en un formato de resumen (por ejemplo una tabla). En muchos casos, los elementos de la lista comparten una o más características comunes, por ejemplo, una lista de solicitudes que esperan su envío, una lista de clientes que están "activos" y una lista de cuentas abiertas, etc. En muchos casos, los usuarios desean filtrar la lista de una lista más grande a una lista más pequeña. Para cada aplicación vertical, uno o más componentes de la consulta se describen porque permiten al usuario filtrar los elementos que se visualizan en un formulario determinado. De esta manera, para cada formulario que se define, se definirán uno o más componentes de consulta. Un componente de consulta se usa para limitar las operaciones 83 de filtro/ consulta que se pueden realizar en un formulario específico. Componentes de dominio Cuando se introducen datos para un elemento de datos comerciales específicos con frecuencia se requiere que el valor introducido pertenezca a una lista de valores definida previamente (es decir que exista dentro de un dominio). Por ejemplo, un dominio para "género" puede contener los valores "M" y "F". Para cada aplicación vertical, uno o más componentes de dominio se pueden definir. Cada componente define la lista de valores que forman el dominio de la aplicación específica. Una vez definidos, el subsistema Jview™ entonces puede usar esta lista para facilitar la entrada de datos (al mostrar las listas de valores desde las cuales se puede hacer la selección) y para la validación. Imágenes Los archivos de esta categoría representan cualquier archivo de gráfico genérico que se usa a través del subsistema Jview™ y no específico de ninguna aplicación o cliente vertical determinado. Logos Los archivos de esta categoría representan cualesquiera archivos gráficos específicos de aplicación o de cliente que se usan dentro de una aplicación vertical determinada. 84 Clases del subsistema Jview™ Las clases que forman el subsistema Jview™ se pueden dividir en las siguientes categorías - central STM, base y visualización. Clases centrales Las clases centrales representan las clases que realizan las funciones y servicios genéricos que son usados por el subsistema completo Jview™. La siguiente tabla describe las clases que se incluyen en esta categoría.

Clases STM Las clases STM se usan para representar los componentes principales del STM que se reciben del servidor. La siguiente tabla describe las clases incluidas en esta categoría. 85 Clases base Las clases base representan la jerarquía de la clase abstracta que se usa para representar los datos y la estructura de la información comercial que se recibe del servidor en el STM. La siguiente tabla describe las clases que se incluyen en esta categoría.

Clase Descripción/ Funciones JVBase Clase de objeto base. Esta clase abstracta contiene los atributos que son comunes para todos los otros objetos base de JView™. Todos los demás JView™. Las clases base son subclases de esta clase.

JVList Clase de lista. Esta clase abstracta se usa para representar una disposición de otros objetos base (es decir, una disposición de objetos JVBObjects o JVGAttr). 86 Clases de visualización Representan la jerarquía de las clases abstractas que se usan a través de los componentes de visualización para definir y controlar la interfaz del usuario. La siguiente tabla describe las clases que se incluyen en esta categoría. 87 Clase Descripción/ Funciones JVDisplay Clase de objeto de visualización. Esta clase abstracta contiene los atributos que son comunes para todos los otros objetos de visualización de JView™. Todos los demás JView . Las clases de visualización son subclases de esta clase. JView"". Clase de JView""1. Esta clase se usa para representar el objeto del formulario o forma actual para la interacción actual. Funciona como el punto ancla para la jerarquía del componente de objeto de visualización. JVQuery Clase componente de consulta. Esta clase se usa para representar el componente de consulta actual (si se define) para la interacción actual. La definición del componente de consulta especifica de la aplicación crea una instancia de esta clase para que contenga los elementos de datos específicos, asi como sus valores usados para controlar las operaciones de consulta/ filtrado. JVDTable Clase de componentes de la tabla. Esta clase abstracta se usa para definir un componente de la tabla dentro de la interfaz del usuario (Ul). Proporciona servicios genéricos comunes para todas las tablas. Todos los componentes de las tablas específicas para la aplicación se subclasifican a partir de esta clase. JVDPane Clase de componentes del panel. Esta clase abstracta se usa para definir un componente del panel dentro de la interfaz del usuario (Ul). Proporciona servicios genéricos comunes para todos los paneles. Todos los componentes de los paneles específicos para la aplicación se subclasifican a partir de esta clase. JVDGroupBox Clase de componentes del cuadro del grupo (GroupBox). Esta clase abstracta se usa para definir un componente del cuadro del grupo dentro de la interfaz del usuario (Ul). Proporciona servicios genéricos comunes para todos los cuadros del grupo. Todos los componentes de los cuadros del grupo específicos para la aplicación se subclasifican a partir de esta clase. JVDDomainComponent Clase de componente de dominio. Esta clase se usa para representar un dominio de aplicación (si se define) para la interacción actual. Para cada interacción, se pueden usar diversas definiciones de dominio y en este caso, se crea una instancia de esta clase para cada dominio. El componente de dominio específico de la aplicación crea una instancia de esta la clase para que contenga los elementos de datos específicos, asi como sus valores usados para controlar las operaciones de búsqueda, recuperación y validación de dominios.

JVField Clase de componentes. Esta clase se usa para definir un componente de campo dentro de la interfaz del usuario (Ul). Proporciona servicios genéricos comunes para todos los campos. JVComplexField Clase de componentes de campo complejo. Esta clase se usa para definir un componente de campo complejo dentro de la interfaz del usuario (Ul). Proporciona servicios genéricos comunes para todos los campos complejos. 88 Formato y estructura del STM El "mensaje de transacción de Siteras" (STM) es una estructura jerárquica de pares de valores clave que están diseñados específicamente para contener datos comerciales, en formatos sin procesar, transmitidos entre un servidor y un buscador. Es similar en estructura, capacidad y objetivo a otros mecanismos de codificación de datos (por ejemplo, XML, PList, etc.). Este formato permite que el subsistema Jview™ alcance un alto rendimiento y una capacidad amplia en el buscador. El STM contiene los siguientes subconjuntos lógicos de datos - encabezado, barra de navegación, objetos comerciales, lista de funciones, mensajes y dominios. Encabezado Esta sección contiene elementos de datos que se usan para mantener entorno del subsistema Jview™ y coordina la ejecución de una transacción entre el servidor y el subsistema Jview™ que se ejecuta en el buscador. Barra de navegación Esta sección contiene las estructuras de datos que se usan en el subsistema Jview™ para construir la barra de navegación dentro de !a interfaz del usuario. La barra de navegación proporciona al usuario un sistema de menús jerárquicos para acceder a las funciones dentro del sistema de aplicación. 89 Objetos comerciales Esta sección contiene los objetos comerciales (datos comerciales) relacionados con la función de la aplicación que está en ejecución. Dentro del STM, estos objetos comerciales existen en su formato objeto primitivo, usando estos objetos comerciales, el subsistema Jview™ proporciona una presentación que es fácil de usar para el usuario (es decir, genera el HTML que se visualiza en el buscador) con base en la definición de! formulario o forma específica de la aplicación (objeto del subsistema Jview™ contenido en cada interacción.

Lista de funciones Esta sección contiene una matriz de las funciones de la aplicación que el usuario puede realizar. Esta lista permite que el sistema refuerce un primer nivel de seguridad. Mensajes Esta sección contiene una matriz de cualesquiera mensajes en la aplicación que se generaron como resultado de la ejecución de la última función de la aplicación. Estos mensajes pueden ser de información, advertencias o errores. Dominios Esta sección contiene una matriz de las definiciones de los dominios dinámicos que se han enviado desde el servidor (en donde el contenido de los valores dentro del dominio se determinan de manera dinámica a través de las condiciones de la aplicación con cada función). Las definiciones de los 90 dominios estáticos en donde los valores dentro del dominio no cambian se proveen a través de los componentes de dominio (es decir, archivos de JavaScript). Sin embargo, estas definiciones de dominio estático no se transmiten dentro del STM. Formato de mensajes HTML del STM Al recibir la respuesta del HTTP del servidor, el buscador realiza sus funciones normales relacionadas con el procesamiento en un mensaje HTML. Cuando se recibe inicialmente en el buscador, el STM se codifica dentro de un flujo estándar de HTML. Un mensaje muestra está contenido en el diagrama 1. La tabla a continuación resume las partes principales del mensaje (las referencias de número de línea se refieren al mensaje muestra del diagrama 1).

Línea (s) Descripción 1-4 Etiquetas de HTML estándar. Estas etiquetas declaran el flujo como un flujo de HTML. El flujo general de HTML se declara en las líneas 1-219. La porción de HTML HEAD (que contiene el STM) se declara en las líneas 3- 207. La porción de HTML BODY se declara en las líneas 209-218. 5 Inclusión de la hoja de estilo en cascada. 91 Incluye el archivo JavaScript principal de JView'™. Esta afirmación ocasiona que se cargue el JView Core. Incluye la definición de JView1 M en el formulario o en la forma. Esta afirmación proporciona la definición de la forma o formulario específico que se visualiza dentro del JView ™. Estructura de la interfaz del usuario. Esta afirmación también ocasiona que se carguen todas las definiciones de la clase. Si se visualiza un "formulario", esta línea proporciona la definición para el componente de consulta específico de la aplicación que se usará con el formulario. -206 STM El STM completo encapsulado en las funciones de JavaScript. -48 Encabezado Es la porción del encabezado del STM. -59 NavBar Es la porción la barra de navegación del STM. En este ejemplo, la barra de navegación contiene seis diferentes elementos de navegación en las líneas 52, 53, 54, 55, 56 y 57. -143 Objetos comerciales Es la porción de los objetos comerciales del STM. En este ejemplo, existen dos instancias de los datos comerciales contenidos en esta sección. Ambos objetos comerciales son objetos SAFolder_Subro. La primera instancia se define a través de las líneas 62-101, la segunda instancia se define a través de las líneas 102-142. 5-162 Lista de funciones Es la porción de la lista de funciones del STM. En este ejemplo, la lista de funciones contiene dos diferentes entradas de funciones en las líneas 147-153 y 154-160. 4-169 Mensajes Es la porción de mensajes del STM. En este ejemplo, se definen dos diferentes mensajes de la aplicación en las lineas 166 y 167. 1-200 Dominios Es la porción de los dominios del STM. En este ejemplo, se define un dominio de aplicación único denominado "RespondingCompanies" (Compañía de contraparte) que contiene 4 elementos de dominio. 9-218 HTML BODY (cuerpo HTML) Estas líneas representan la declaración del cuerpo de HTML. En la mayoría de los flujos de HTML estándares, ésta sección contiene un gran número de definiciones que definen el formato de la interfaz del usuario que se realiza a través del buscador. Con el subsistema JView™ esta sección virtualmente esta vacía. En la línea 209, el parámetro " ocasiona que el buscador invoque al JView™ Manager para que complete la inicialización del JView™ y genere el HTML que se visualiza en el buscador para esta interacción. 92 Funciones STM JavaScript Dentro del flujo de HTML descritas anteriormente, las funciones de JavaScript se usan para encapsular los datos comerciales. Al usar estas funciones, cualesquiera estructuras de datos comerciales, simples o complejos, se pueden definir. Para una porción de STM del mensaje, se usan las siguientes funciones de JavaScript: Objetos únicos NS(<classId>,<objectId>,<instance me>) NE( ) Estas funciones se usan para definir un nodo de objeto único. La función NS() se usa para iniciar la declaración del objeto y la función NE() se usa para finalizar la declaración. Un solo nodo de objeto puede contener otros objetos únicos, nodos de matriz o nodos de atributo. Cuando se define el nodo de objeto la <clase> especifica el tipo de objeto que se representa, el <<objectid> es su único identificador de objeto, y el <instancename> es el nombre mediante el cual el objeto principal (si hay alguno) se refiere a este objeto. Matrices de objeto RS(<instanceNam e>) RE( ) Estas funciones se usan para definir un nodo de matriz. Esencialmente, este tipo de nodo se usa para definir una colección de objetos del mismo tipo/ clase. La función RS() 93 se usa para iniciar la declaración de la matriz y la función RE() se usa para finalizar la declaración. Un nodo de la matriz puede contener cualquier número de objetos únicos (NS) o nodos de atributo genérico (GA). Al definir el nodo de matriz, el <instancename> es el nombre a través del cual el objeto original (si hay alguno) se refiere a esta matriz. Atributo AB(<attributeId>, <value>) AD (<atcributeld> , <value>) AF (<attributeld>, <value>) AI<<attributeId>r <value>) AM(<attributeld>, <value>) AS(<attributeId>, <value>) Estas funciones se usan para definir un solo nodo de atributo (elemento de datos) dentro de un objeto (NS). Los nombres de funciones diferentes se refieren al tipo primitivo de datos que se representan a través del atributo - boleano (AB), fecha y hora (AD), punto numérico flotante (AF), entero numérico (Al), memo (A ) y cadena (AS). Cuando se define un nodo de atributo, el <Attributeld> es el nombre mediante el cual el objeto original se refiere a este atributo, y el <value> es el valor de los datos del atributo. Atributos genéricos GA(<attributeType>, <valuel>, <value2>, <valuen>) Estas funciones se usan para definir un solo nodo de atributo genérico (elemento de datos complejo) dentro de una matriz (RS). Este atributo sólo se puede usar dentro de un 94 nodo de matriz. Es un tipo especial de atributo complejo y la interpretación del tipo de atributo y los valores se dejan al objeto original. Formato de modo completo en comparación con el modo sin procesar En el ejemplo del mensaje anterior, el formato "modo completo" se usa. En este formato, las identificaciones de las clases y las identificaciones de los atributos se expresan como cadenas de caracteres completos. También se usa un formato "modo sin procesar" que reduce adicionalmente el tamaño general del mensaje reemplazando las representaciones de la cadena de caracteres de las identificaciones de clase e identificaciones de atributo con códigos numéricos. Adicionalmente, el modo sin procesar puede usar el método de la función JavaScript de la encapsuiacion de datos o la sintaxis de la matriz JavaScript. El método de matriz de JavaScript se prefiere para la producción ya que éste elimina cualquier sobrecarga asociada con la ejecución de las funciones de encapsuiacion de datos en sí misma. Al usar este método, todas las reglas de codificación de datos se ajustan a las que se definen a través de la sintaxis de JavaScript. A continuación se resumen varios formatos de STM: 95 Modo completo de STM NS( "STMHdr" ,nuil , "oHdr" ) ; AB("readOnly",0) ; AD("dateCreated", "20000531105702") ; AF ( "amtTota " , 17.43 ) ; AI{"count",4) ,- AM(*comments", "T is is line l\nThis is line2\n"),- AS(*conipanyName" , "Insurance Property & Casualty"); NE() ; Modo sin procesar de STM (usando la encapsulacion de la función de JavaScript NS(l,null,l) ,· ABÍl.O); AD(3, "20000531105702") ; AF ( , 17. 3 ) ; AI (8,4) ; AM(2,"This is line l\nThis is line2\n") AS (7, "Insurance Property & Casualty"); NEO ; Modo sin procesar de STM (usando la encapsulacion de la matriz de JavaScript) STMHdr = [[l.null,!], [1,1.0], [2,3, "20000531105702"] , [3,4,17.43], [4,8,4], [5,2,"This is line UnThis is line2\n") ,-] , [6,7, "Insurance Property & Casualty"),-] 3; Formato de objeto de STM El procesamiento del mensaje STM da como resultado la creación de un objeto de STM dentro del entorno del buscador. La estructura de este objeto se ilustra en la figura 21. 96 Jerarquías de objeto del subsistema Jview Durante la inicialización del entorno del subsistema Jview™, se construyen dos jerarquías de objetos principales, la jerarquía del objeto base y la jerarquía del objeto de visualizacion. Jerarquía de componente objeto base La jerarquía del objeto base consiste en los objetos base (derivados de JVBase) que se crearon como resultado del procesamiento de ST (como se ilustra dentro del diagrama 1). Esta jerarquía se ancla dentro de una variable global "goST " aunque se pueda tener acceso en cualquier momento a través de cualquier parte del sistema. Todos los objetos comerciales relacionados con la función de la aplicación están contenidos en el subárbol goSTM.oDATA. Este subárbol es una matriz (RS) que puede contener 0-n subárboles de objeto comercial. Para un formulario, contendrá 0-n subárboles de objeto comercial. Un formulario, sólo contiene un subárbol de objeto comercial. Jerarquía del componente objeto de visualización La jerarquía objeto de visualización consiste en objetos de visualización (derivados de JVDisplay) que se crearon como un resultado del procesamiento del componente del formulario/ forma del subsistema Jview™ en asociación con esta infracción (como se define en la línea 7 del mensaje ejemplar del diagrama 1). Esta jerarquía está anclada dentro 97 de una variable de la instancia del administrador del subsistema Jview™ "OJView" (la instancia del objeto del administrador del subsistema Jview™ entonces se ancla con una variable global "goJM"). Los objetos de visualización se usan para contener la instancia y los datos de estado relacionados con una interfaz de usuario y algún grado para reflejar los objetos DOM que se crean desde el HTML generado. Esta jerarquía es necesaria debido a que ciertas operaciones locales (por ejemplo, reclasificación de una tabla) se usan para regenerar porciones del DOM, en este caso, el objeto de visualización contiene los datos necesarios para regenerar los objetos DOM. Procesamiento del subsistema Jview™ Las tres fases diferentes de la operación del subsistema Jview™ se describen con detalle en las siguientes secciones. Inicialización Interacción Presentación de solicitud Inicialización del sistema Jview™ Con cada respuesta del HTTP recibida desde el servidor, el entorno del subsistema Jview™ dentro del buscador se vuelve a reconstruir por completo. Debido a esto, el sistema se diseñó por módulos para minimizar las demoras asociadas con esta inicialización. Algunas plataformas de 98 buscador permiten que algunos datos persistan entre las interacciones (por ejemplo, Cookies, comportamiento de IE, etc.), diferentes a los mecanismos de colocación de memoria intermedia en un buscador normal (es decir, se usa para páginas HTML, gráficos, CSS y archivos JavaScript), el subsistema Jview™ no se basa en ningún mecanismo específico de un buscador para colocar en memoria intermedia los datos entre las interacciones del servidor. Inicialización del buscador Al recibir una nueva respuesta del HTTP desde el servidor, el buscador realiza cualquier inicialización interna y procesa flujo de HTML recién recibido. Carga en inicialización central Después de que el buscador carga el archivo CSS, el archivo JavaScript JVMain se carga y se procesa a través del buscador como se indica a continuación. Primero se procesa una serie de constantes globales (necesarios para la inicialización). La definición de la clase para el administrador de seguimiento se procesa. El administrador de seguimiento se representa e inicializa el mismo. La creación e inicialización temprana del administrador de seguimiento permite que otras partes del subsistema JviewTM registren las entradas del seguimiento para propósitos de depuración. El administrador de seguimiento se ancla en la variable global goJVTraceMgr de manera que se puede tener acceso a éste a 99 través de cualquier parte del sistema. La definición de clases para el administrador de carga se procesa. El administrador de carga se representa e inicializa por sí mismo. El administrador de carga se usa para dar seguimiento a todos los archivos JavaScript (por ejemplo, formularios/ formas, componentes, clases, etc.) que se han cargado. El administrador de carga se ancla en la variable global goJVLoadMgr de esta manera se pueden acceder a éste a través de cualquier parte del sistema. Una serie de funciones JV_INCLUIR se procesan para cargar los otros archivos JavaScript que forman el núcleo de (1 SIN LA TM) (refiérase a la sección capacidad de "incluir" del Jview™ para obtener más detalle. Como consecuencia se cargan los siguientes archivos centrales en la secuencia cuando el buscador completa el procesamiento para JVMain -Clase de administrador de Jview™ (jv_jvmgr_000.js), Clases de Base de Jview™ (jv_jvbase_000.js), Clases de visualización de Jview™ (jv_Jvdisp_000.js), Clase de formulario/ forma de Jview™ (jv_Jview._000.js), Clases de STM (jv_stm_000.js), Clase de administrador de dominio (jv_dommgr_000.js) y constantes globales (jv_global_000.js). Al cargar cada archivo, se registra en el administrador de carga. Una serie de definiciones de funciones globales entonces se procesa. Estas funciones proporcionan servicios 100 generales que se pueden usar por cualquier parte del subsistema Jview™. Después de que el procesamiento para JVMain está completo, el buscador carga y procesa cada uno de los archivos centrales que se incluyeron en el párrafo anterior. Creación del administrador del subsistema Jview™ Durante el procesamiento del archivo global JVIEW, el administrador del subsistema Jview™ se ejemplifica. Este objeto se ancla en la variable global goJM de manera que se puede tener acceso a éste a través de cualquier parte del sistema. La inicialización de este objeto se aplaza (véase a continuación "inicialización del administrador del subsistema Jview™"). Carga de clases de la aplicación de formularios/ formas Una vez que la carga de los archivos centrales del subsistema Jview™ está completa, el buscador continúa procesando las afirmaciones en el flujo de HTML desde la respuesta actual de HTTP. La siguiente afirmación en este flujo sería una etiqueta [SCRI PT](programa simple) al que hace referencia el archivo JavaScript para la forma o formulario especifico de la aplicación. Esta afirmación ocasiona que el buscador cargue y procese este archivo como se indica a continuación, las definiciones del método y atributos adicionales para la clase JVIEW (específico para esta forma) se procesan. Estas definiciones proporcionan a la 101 clase JVIEW su comportamiento específico para la aplicación para la interacción actual. Se procesa una serie de funciones JV_INCLUIR para cargar los otros archivos JavaScript que se usan a través de este formulario/ forma. Existen dos grupos principales de archivos que están incluidos, los componentes de visualizacion y las clases comerciales. Una forma o formulario del subsistema Jview™ se construye ensamblando uno o más componentes de visualizacion (descritos a continuación en "arquitectura de la interfaz del usuario del subsistema Jview™"). El componente de visualizacion "incluye" ocasiona la carga de todas las definiciones del componente de visualizacion que son necesarias para este formulario/ forma. Dentro de la porción del objeto comercial del STM, cada objeto comercial requiere que su definición de clase de aplicación exista dentro del entorno JavaScript dentro del buscador. La clase comercial "incluye" ocasiona la carga de todas las definiciones de la clase comercial que son necesarias para el STM actual. Después de completar el procesamiento para la forma/ vista específica de la aplicación, el buscador carga y procesa cada uno de los archivos de la clase comercial y del componente de visualizacion que se incluyeron anteriormente. Carga del componente de consulta Una vez que la carga del formulario/ forma de la 102 aplicación, componente de visualización y archivos de la clase comercial está completa, el buscador continúa con el procesamiento de las afirmaciones en el flujo de HTML de la respuesta HTTP actual. Si se procesa un formulario para esa interacción, la siguiente afirmación en este flujo será una etiqueta <SCRIPT> que hace referencia al archivo JavaScript para el componente de consulta específico de la aplicación. Esta afirmación ocasiona que el buscador cargue y procese este archivo. Procesamiento STM - creación e inicialización de la jerarquía del objeto base Después de que se han cargado todos los archivos específicos de aplicación y centrales del subsistema Jview™, el buscador continúa con el procesamiento de las afirmaciones en el flujo del HTML desde la respuesta actual de HTTP. Las siguientes afirmaciones en el flujo están en las afirmaciones de JavaScript en línea que representa el STM. El buscador procesa estas afirmaciones como se indica a continuación, el buscador ejecuta cada función de STM de JavaScript en el orden en que suceden dentro del flujo de HTML (por ejemplo, NS(), RS(), etc.). Al procesar cada función, se crea un nuevo nodo (objeto) en la jerarquía de objeto base del subsistema Jview™. Para las funciones NS(), se crea un objeto específico de la aplicación (con base en la identificación de 103 clase especificada en la función NS()). Para las demás funciones del STM el tipo de objeto creado depende de la función específica del STM como se indica a continuación: RS()-JVList (Lista de JV) AB()-JVBoolean (Booleano de JV) AD()-JVDate Time (Fecha y hora de JV) AF()-JVFIoat (Flotación de JV) AI()-JVInteger (Entero de JV) AM()-JVMemo (Recordatorio de JV) AS()-JVString (Cadena de JV) GA()-J VGAttr (Atributo de JVG) Al crear cada nodo, se ejecuta la inicialización de JVBase. Esta inicialización establece los atributos de JVBase que se usan para representar la unión de ese nodo con la jerarquía del objeto base (es decir, original, secundario, hermano, etc.). Con base en la secuencia de las afirmaciones en el STM, se crea una jerarquía del objeto base de la parte superior a la inferior y de izquierda a derecha. Al crear cada subárbol específico de aplicación, cualesquiera inicializaciones específicas de aplicación se ejecutan. Esta inicialización, en caso de existir una, existe dentro de cada clase comercial de la aplicación como un método lnit(). La inicialización específica de la aplicación realiza cualquier manipulación de datos específica de la aplicación que son necesarios a través de la interacción actual. Después de 104 haber ejecutado las funciones JavaScript de STM, se crea la jerarquía del objeto base del subsistema Jview™. Esta jerarquía de objeto contiene todos los datos comerciales, por ejemplo objetos comerciales, enviados desde el servidor como respuesta a la solicitud anterior. Inicializacíón del administrador del subsistema Jview™ Después de haber procesado las funciones de STM, se ejecuta el método lnit() del administrador del subsistema Jview™ (JVMgr). Este método se activa a través del parámetro " de la etiqueta <BODY> en el flujo HTML. Lo siguiente resume el procesamiento realizado en este método. Inicializar el administrador de dominio Esta inicializacíón ocasiona el procesamiento y establecimiento de cualesquiera dominios contenidos en el STM (en la sección de dominio). Crear una instancia de un objeto JVIEW. En este punto, sólo diversas definiciones de clase de JVIEW se han procesado (tanto específicas de la aplicación como genéricas). En este momento, el objeto real JVIEW (formulario o forma) se crea. Este objeto ancla la jerarquía de visualización que controla la interfaz del usuario asociada con la interacción actual. En este momento, la jerarquía del objeto de visualización se crea e inicializa. Este proceso complejo se 105 describe posteriormente. Al terminar este proceso, se devuelve el control al administrador del subsistema Jview™ y se completa su inicialización. Creación e inicialización de la jerarquía del objeto de inicialización Este proceso ocasiona la creación de objetos de visualización que se usan para generar y controlar la interfaz de usuario para la interacción actual. Se activa al invocar el método lnit() del objeto JVIEW. Dentro de este método, se realiza el siguiente procesamiento (por razones de brevedad, cualesquiera referencias a "formulario" a continuación implica una forma o un formulario). Cualquier inicialización de formulario específica de aplicación se realiza al invocar el método InitViewQ para el objeto JVIEW. Este método permite que el formulario realice cualquier procesamiento específico de la aplicación antes de generar y visualizar el HTML. Dicha inicialización incluye inicializar las variables de componentes que contienen referencias a cualesquiera componentes de visualización creados posteriormente, inicializando otras variables basadas en las condiciones de datos dentro de la jerarquía base, clasificando datos comerciales dentro de la jerarquía base, etc. Una vez inicializado el formulario, los componentes de visualización se crean y el HTML se genera en un solo 106 proceso. Este proceso se activa al invocar el método CreateHTMLQ del objeto JVIEW. Antes de invocar este método, se crea una matriz y pasa a este método como parámetro (es decir, la matriz HTML). Esta matriz se usa para contener todas las afirmaciones de HTML que se generan mediante todos los métodos de visualización y los componentes invocados durante el procesamiento del método CreateHTML(). Este método realiza lo siguiente: invoca al método CreateHeader() para generar el HTML para la porción del encabezado de la interfaz del usuario; invoca el método CreatelnfoBarO para generar el HTML para la porción de la barra de información de la interfaz del usuario; invoca el método CreateNavBarQ para generar el HTML para la porción NavBar de la interfaz del usuario; si existe algún mensaje de aplicación, invoca el método CreateMsgArea() para generar la porción del área de mensajes de la interfaz del usuario; para una forma, invoca el método CreateActionBarQ para generar el HTML para la porción de la barra del flujo de trabajo de la interfaz del usuario; e invoca el método CreateDataArea() para crear/ inicializar cualquier componente de visualización y generar el HTML para la porción del área de datos de la interfaz del usuario (la porción que contiene la información específica de la aplicación). Este método se define en el archivo del subsistema Jview™ específico de la aplicación para la interacción actual. Éste hará cualquiera de lo 107 siguiente 1) generar directamente HTML, 2) crear cualesquiera componentes de visualizacion secundarios que formen la interfaz del usuario para este formulario, o 3) usar una combinación de ambas técnicas. Para cada componente de visualizacion creado, se produce el siguiente procesamiento. El objeto de visualizacion para este componente se ejemplifica y enlaza en la jerarquía de visualizacion. Cualquier inicialización del componente se produce dentro del constructor de la clase para ese objeto de visualizacion. Se invoca el método C reate P re HT M L para el objeto de visualizacion recién creado. Este método proporciona una generación HTML orientada ai contenedor a través de cualesquiera superclases para este objeto. El método CreateHTML se invoca para el objeto de visualizacion recién creado. De manera similar a lo anterior, éste método ocasiona la generación de cualquier HTML específico para la aplicación para este componente. Para hacerlo, 1) generará directamente HTML, 2) creará cualquier componente de visualizacion secundario que forma la interfaz del usuario para este formulario, o 3) usará una combinación de ambas técnicas. Este proceso permite alojar de manera ordenada y crear componentes de visualizacion aislados fuera del objeto JVIEW inicial. Este proceso soporta la construcción de una interfaz de usuario simple o compleja. Se invocará el método CreatePostHTM L para el objeto de visualizacion 108 recién creado. Este método proporciona una generación HTML orientada al contenedor a través de cualquier superclase para este objeto. Después de completar el método CreateDataAreaQ se generan algunas etiquetas especiales de HTML. Se crea una forma HTML-JVFORM_STM. Para las formas del subsistema Jview™ se soportan la transferencia de archivos desde el entorno local, se crea un dispositivo en pantalla de archivo del buscador estándar (STMFILE) se crea dentro de esta forma HTML (CreatePreHTML). Finalmente, también se define un archivo oculto especial (STMDATA) dentro de esta forma HTML (HTML FORM (<INPUT TYPE = "hidden"...>)), este campo se usa para contener el flujo de STM fuera del límite para cualquier solicitud posterior al servidor. Al completar el método CreateHTML principal para el objeto JVIEW, el flujo HTML se prepara y el objeto DOM dentro del buscador para la porción del cuerpo del documento actual se actualiza dentro del HTML nuevo (este proceso se describe adicionalmente en "generación de HTML" a continuación). En este punto, el "enfoque" de la interfaz del usuario se establece (con base en la definición dentro del subsistema Jview™ del primer campo que es para recibir el foco de entrada), y se devuelve el control al administrador del subsistema Jview™. 109 Inicialización del administrador del subsistema Jview (continuación) Después de haber creado la interfaz del usuario, el administrador del subsistema Jview™ completará su inicialización al realizar sus cálculos del tiempo de respuesta. En este punto, se devuelve el control al buscador y el control de la interfaz del usuario se devuelve al usuario. Interacción del subsistema Jview™ Una vez devuelto el control al usuario, el entorno del subsistema Jview™ permite que el usuario opere localmente (sin interacción del servidor). Para hacerlo, el subsistema Jview™ se basa en un mecanismo dinámico HTML dentro del buscador para realizar los servicios relacionados con la interacción. Estos servicios incluyen lo siguiente: Clasificación dinámica Formateo y visualización de datos Expansión/ compresión de las porciones de la interfaz del usuario (por ejemplo, paneles) Formateo de impresión y vista previa Menú jerárquico Edición sintáctica y validación Validación de aplicación compleja Cálculos de la aplicación El HTML que se generó inicialmente contiene las definiciones que permiten la activación de métodos 110 específicos dentro de objetos de visualización del subsistema Jview™ como respuesta a cualesquiera eventos dinámicos HTML generados por el buscador como respuesta a las diversas interacciones del usuario. Un aspecto clave de esta interacción local se refiere a la entrada de datos. Para cualesquiera datos introducidos por el usuario, el entorno del subsistema Jview™ realiza una validación sintáctica (por ejemplo, asegura números válidos, fechas, etc.) e invoca cualquier validación específica de la aplicación definida dentro de las clases comerciales. Una vez que estas validaciones se han realizado de manera satisfactoria, el objeto base específico afectado por estos datos (dentro de la jerarquía del objeto base) se modifican con los mismos datos nuevos. De esta manera, cuando el usuario ¡nteractúa con la interfaz del usuario, la jerarquía del objeto base se actualiza de manera dinámica para reflejar el estado actual de los datos. La importancia de esto será más clara posteriormente al describir la presentación de solicitudes al servidor. Para obtener mayor información sobre estos servicios refiérase a la sección "servicios del subsistema Jview™". Presentación de solicitudes al subsistema Jview™ El usuario continuará operando localmente dentro del entorno del buscador hasta que seleccione un elemento de la interfaz de usuario y active una nueva solicitud al servidor. 111 Dentro del entorno del subsistema Jview , todas estas solicitudes se procesan y se generan desde un punto central dentro del entorno del subsistema Jview™, a saber el administrador del subsistema Jview™. Lo siguiente resume el proceso de presentación de solicitudes. Para cualesquiera elementos de interfaz de usuario que activen una solicitud al servidor, el HTML asegura que los elementos ocasionan una invocación al método InvokeFunctionO dentro del administrador del subsistema Jview™ (JVMgr). El método InvokeFunctionO realiza una validación de parámetros y después invoca el método JVMgr. SubmitHost equest(), para solicitar la presentación al servidor por parte del administrador de Jview™. El método JVMgr. SubmitHostRequest() realiza lo siguiente: guarda el estado de la barra de navegación actual (es decir, qué niveles del menú están abiertos/ cerrados) dentro de una variable ejemplar en el encabezado del STM; actualiza otras variables del encabezado de STM con los valores de los datos específicos para la nueva solicitud (por ejemplo, nombre de la función, tipo de cadena, identificador de objeto, parámetros de transacción, comando OLS, calificador y otras variables de contexto del entorno del subsistema Jview™); y construye el flujo de STM saliente para la solicitud al cruzar la jerarquía del objeto base para 112 los subárboles del encabezado y objeto comercial y así crear un flujo de texto único (cuyo formato es idéntico al formato del STM en el límite que se ¡lustra en el diagrama 1). De hecho, el formato específico que se usa depende del servidor y puede ser cualquier sintaxis en serie que pueda representar una estructura jerárquica de pares clave:valor (por ejemplo STM, XML, PList, etc.). entonces el flujo resultante se almacena en la variable de la forma especial (STMDATA), que se creó cuando se generó en un inicio el HTML (refiérase a 2g en la sección anterior "creación e inicialización de la jerarquía del objeto de visualización"). Con base en el tipo de solicitud (no edición o edición), la solicitud se presenta al servidor principal de dos maneras. Para las solicitudes de no edición (es decir, las solicitudes que no ocasionan modificación de datos en el servidor), se presenta la forma HTML HTML FORM JVFORM_STM con METHOD = GET. Para solicitudes de edición (es decir, las solicitudes que ocasionan modificación de datos en el servidor), se presenta la forma HTML HTML FORM JVFORM_STM con METHOD = POST. Después de presentar la solicitud al servidor, se devuelve el control al buscador para que espere la respuesta de una solicitud recién emitida. Servicios del sistema Jview™ Dentro del procesamiento del subsistema general 113 Jview descrito anteriormente, se realizan servicios específicos. Esta sección detalla la operación de dichos servicios específicos. Capacidad "incluir" del subsistema Jview™ La capacidad de "incluir" del subsistema Jview™ se creó para aislar al servidor de la manera específica en que se colocó el módulo la parte central del subsistema Jview™. Esto permite que el servidor especifique meramente un archivo único del subsistema Jview™ (es decir, jv_main_000.js) en este flujo de respuestas de HTTP. Dentro de ese archivo, se incluyen posteriormente otros archivos para completar la carga de la parte central del subsistema Jview™. Este enfoque permite que la parte central del subsistema Jview™ se pueda dividir de una manera o se extienda sin que sea necesario ningún cambio del servidor. El entorno del buscador estándar no provee un mecanismo genérico para "incluir" archivos de JavaScript. De esta manera, se usa el siguiente proceso. Dentro de la sección del encabezado <HEAD> del flujo HTML para un flujo de respuesta determinado de HTTP, una referencia a un archivo JavaScript principal inicial que usa una etiqueta de HTML <SCRIPT SRC = ...> se define. El buscador carga el archivo JavaScript nombrado a través de esta etiqueta desde su memoria intermedia local o desde el servidor. Una vez cargado, el buscador inicia el 114 procesamiento de las afirmaciones definidas en este archivo. Estas afirmaciones pueden ser definiciones de JavaScript o afirmaciones ejecutables. Para "incluir" otro archivo JavaScript, una serie de afirmaciones ejecutables de JavaScript están contenidas dentro del archivo principal de JavaScript para realizar lo siguiente: construir una variable de cadenas que contiene una nueva etiqueta HTML<SCRIPT> para el archivo JavaScript que se incluirá y realiza una función de documento. escribir que especifica esta nueva variable de cadena. Esta función ocasiona que la nueva afirmación HTML se escriba en el flujo actual de HTML que está en proceso (delante de cualquier afirmación de HTML que sea enviada desde el servidor). Una vez que el buscador completa el procesamiento del archivo JavaScript principal, entonces procesa cualesquiera afirmaciones de HTML recién insertadas que se crearon de manera dinámica al ejecutar el código JavaScript en el archivo principal, de esta manera ocasiona la carga adicional de los archivos JavaScript. Esencialmente, el procesamiento es igual que si el servidor hubiera incluido los archivos JavaScript adicionales en su flujo original HTML. Administración del seguimiento Dentro del entorno del subsistema Jview™, el administrador de seguimiento mantiene la información del 115 seguimiento que es útil para los propósitos de depuración. El proceso de continuación se usa para administrar la información de seguimiento. En la inicialización, el administración de seguimiento localiza una matriz (con un número fijo de entradas) para los datos de seguimiento. El administrador de seguimiento se ancla en una variable global goJVTrace gr. Siempre que el método del administrador de seguimiento AddTraceEntry() se invoca, el administrador de seguimiento añade la nueva entrada de seguimiento a su tabla de seguimiento interna. Cuando se llena la tabla de seguimiento el administrador de seguimiento regresa al inicio y reemplaza las entradas de seguimiento más antiguas con las entradas de seguimiento más recientes. Están disponibles otros métodos del administrador de seguimiento para visualizar la tabla de seguimiento. Optimización de la inicialización del subsistema Jview™ Debido al hecho de que el entorno del subsistema Jview™ debe reconstruirse por completo a través del buscador, es esencial mantener la sobrecarga de procesamiento relacionada con la inicialización al mínimo. Un mecanismo que se usa para reducir el tipo de inicialización fue el colocar en módulos el subsistema Jview™ en un diversos archivos diferentes. Este enfoque presentó diversas ventajas. Con relación a los tamaños combinados de 116 archivos el sistema de aplicación completo, los archivos centrales del subsistema Jview™ representan un subconjunto pequeño (15% o menos). Una vez que se transfiere un archivo del subsistema Jview™ del servidor, se coloca en la memoria intermedia local de los buscadores, a menos que el archivo cambie, cualesquiera referencias posteriores a éste serán satisfechas desde la memoria intermedia local de los buscadores (en lugar de recuperar lo del servidor). La colocación en módulo general del sistema minimiza el número de archivos necesarios para cada interacción de la aplicación. Aunque el sistema de aplicación general puede comprender cientos de formularios, formas, informes y componentes relacionados, un usuario sólo necesita transferir los archivos necesarios para la interacción actual. De esta manera, el subsistema Jview™ evita las demoras de una "inicialización" larga asociada con la carga de un sistema monolítico (por ejemplo, una aplicación de Java, aplicaciones diversas de Java, etc). Debido a la modularización extensa, si un archivo del subsistema Jview™ cambia, sólo necesita transferir el archivo del subsistema Jview™ nuevo, y no el sistema completo. Administración de estado y contexto Con cada interacción con el servidor, el entorno del subsistema Jview™ que se ejecuta dentro del buscador se regenera por completo (se reinicializa). Debido a que el 117 sistema no está basado ni usa ningún mecanismo de persistencia proporcionado por el buscador para registrar su estado (por ejemplo, cookies, comportamientos de IE, etc.), la sección del encabezado de STM se usa para almacenar toda la información de contexto desde el entorno del subsistema Jview™. Cuando se presenta una nueva solicitud al servidor, el entorno del subsistema Jview™ almacena información relacionada con su "contexto" actual dentro del encabezado "STM". Esta información pasa al servidor. Como respuesta a la solicitud, el servidor devuelve esta información de contexto, sin alterar, de nuevo al entorno del subsistema Jview™ dentro de la misma variable de encabezado de STM. El entorno del subsistema Jview™ entonces usa esta información de contexto para volver a establecer el contexto que tenía cuando presentó la solicitud original. Seguridad de las funciones Para eliminar la proliferación de formas, formularios y reportes específicos del usuario, el subsistema Jview™ permite que esos formularios sean creados de una manera que no es específica del usuario. Sin embargo, debido a que esos formularios pueden ser usados por múltiples usuarios, con frecuencia es necesario contener enlaces incrustados en otras funciones de la aplicación. En este caso, no todos los usuarios tienen la autorización de realizar todas las funciones. 118 La arquitectura de la seguridad de las funciones dentro del subsistema Jview™ proporciona un mecanismo para asegurar que un usuario determinado sólo puede acceder a las funciones a las que tiene autorización. A continuación se resume la operación de este mecanismo. La porción Lista de funciones (FunctionList) del STM define un conjunto completo de funciones para las cuales está autorizado el operador actual. Durante la creación e inicialización de una forma/ formulario de un subsistema Jview™, cualesquiera enlaces incrustados en las funciones de la aplicación en el servidor todos están definidos usando el método J VI EW.C reate E mbeded Li n k().. Cuando se crea esta forma este método se invoca para cada enlace definido en la forma/ formulario. Al usar la FunctionList, el método JVIEW. CreateEmbededLink(). valida que el usuario actual está autorizado para acceder a la aplicación de la función asociada con los enlaces. Si no es así, el enlace se inhabilita o bien se oculta (con base en los parámetros pasados a este método). Arquitectura de la interfaz de usuario del subsistema Jview™ La arquitectura de la interfaz del usuario del subsistema Jview™ está basada en un modelo de componente. Estos componentes están organizados alrededor de la estructura de la interfaz del usuario del subsistema 119 Jview . La estructura del subsistema Jview™ proporciona un espacio de trabajo de la aplicación consistente para el usuario. Debido a que todas las partes de la estructura son los mismos componentes, esta estructura se puede modificar y extender fácilmente para que sea compatible con un gran número de sistemas de aplicación. La estructura del subsistema Jview™ consiste en los siguientes componentes principales. Área de encabezado - Área general para proveer la información de "marca" para la compañía usando el sistema y el vendedor. Barra de información - Área de información general que muestra la información sobre la tarea y el usuario actuales. Barra de navegación - Esta área proporciona acceso a las funciones específicas dentro de la aplicación en la forma de un sistema de menú jerárquico. Área de mensaje - Un área para mostrar los mensajes específicos de la aplicación. Barra de flujo de trabajo - Para las formas, esta área se usa para visualizar uno o más botones de acción que se usan para realizar las funciones de aplicación comunes que afectan el flujo de trabajo del documento comercial específico que se visualiza. Área de comando - Para formularios y formas, esta 120 área se usa para visualizar uno o más enlaces que se usan para visualizar las funciones de aplicación secundarias relacionadas con el documento comercial específico que se visualiza. Área de datos - Para formularios, esta área se usa para visualizar información específica de la aplicación, usualmente en forma de fabuladores relacionada con múltiples transacciones comerciales o documentos. Para las formas, esta área se usa para visualizar la información específica de la aplicación relacionada con una transacción o documento comercial único. Dentro del área de datos de una forma o formulario, se pueden definir uno o más componentes de visualización adicionales (por ejemplo, tablas, paneles, cuadros de grupo, etc.). La figura 23 contiene un ejemplo de un "formulario" del subsistema Jview™. La figura 24 contiene un ejemplo de una "forma" del subsistema Jview™. La naturaleza basada en el componente de la arquitectura de interfaz de usuario del subsistema Jview™ permite que un componente de una aplicación determinada sea definido una vez y después pueda volver a usarse entre varias formas y formularios. Generación de HTML Debido a una cantidad extensiva de generación de 121 HTML realizadas dentro del entorno del subsistema Jview™, el desempeño de este aspecto del sistema tiene un impacto principal en la capacidad de respuesta del sistema. Cuando el subsistema Jview™ se desarrolló, las técnicas de generación de HTML que se documentaron dentro de la industria no se ejecutaron de manera adecuada para usarse en un sistema de clase de producción. Para los flujos grandes de HTML (150, KB o más), estas técnicas con frecuencia requieren de 30 segundos o más (en un procesador de tipo Pentium III). De esta manera, el subsistema Jview™ usa un algoritmo especial, existe en la presente, que demuestra la capacidad de generar un flujo grande de HTML (150 KB) en menos de 500 milisegundos en un procesador de clase Pentium III. El diagrama 2 consiste en una sección de códigos que ilustra la técnica de generación de HTML que se usa dentro del subsistema Jview™. La tabla que se muestra a continuación resume esta técnica (las referencias de número de línea se refieren a la sección de código en el diagrama 2).

Líneas Descripción 1 Declaración de una matriz estándar de JavaScript. Cada elemento en esta matriz se usa para contener un fragmento de la generación de códigos de HTML. 2 Declaración de una variable de JavaScript estándar. Esta variable posteriormente se usa para contener el flujo completo de HTML que se genera. 4-7 Afirmaciones de generación de códigos de HTML. Cada fragmento de HTML generado se asigna a un nuevo elemento dentro de la matriz HTML. 9 Al usar el método "unir" de JavaScript estándar (para objetos de matriz), se genera un flujo completo de HTML, el DOM dentro del buscador se actualiza con una operación atómica única que reemplaza por completo el HTML para el cuerpo del documento (usando la propiedad OuterHTML). 10 Una vez que se genera el flujo completo de HTML, el DOM dentro del buscador se actualiza con una sola operación atómica que reemplaza por completo el HTML del cuerpo del documento (usando la propiedad de HTML externo). 122 Clasificación Debido a la alta capacidad de ancho de banda de los "datos" inherente a la arquitectura del subsistema Jview™, puede mostrar de manera eficiente un gran número de filas de resultado para una consulta comercial determinada, de 500 a 1,000 (en comparación con las 20 a 25 que muestran la mayoría de los buscadores). Una vez que se este conjunto de resultados se devuelve al entorno del subsistema Jview™, los usuarios típicamente desean clasificar las filas de resultados con base en diversas columnas. Dentro de JavaScript, se provee un método de clasificación primitivo para objetos de matriz. Este método de clasificación se basa en la existencia de una función "comparar" que puede comparar dos elementos dentro de una matriz y pasar un código de devolución que indica que un elemento fue mayor o menor o igual que otro elemento. Dentro de la porción del objeto comercial de la jerarquía base, una matriz se usa para almacenar un conjunto completo de objetos comerciales para la interacción actual. Sin embargo, debido a que estos objetos son complejos de manera arbitraria, no es práctico codificar de manera estadística una función "comparar". Adicionalmente, aunque JavaScript proporciona una función "eval()" que se puede usar dentro de una función de comparación genérica para evaluar los objetos comerciales arbitrarios, esta función tiene 123 un desempeño intensivo. De esta manera, el uso de esta función para clasificar conjuntos grandes de resultados no es práctica. Para resolver esta limitante y proveer una capacidad robusta de clasificación tanto para la clasificación de columnas múltiples como de una sola columna, se usa la siguiente técnica dentro del subsistema Jview™: cuando se usa un formulario, una función de comparación se genera dinámicamente por códigos para cada columna dentro del formulario; para cada función de comparación generada, se invoca la función "evalQ" una vez para compilar esencialmente esta función en un formato interno de JavaScript; cuando el formulario debe clasificarse, el sistema determina las columnas que se clasifican y después pasa la función de comparación compilada al método de clasificación para la matriz que se está clasificando. Al usar esta técnica, los tiempos de clasificación del subsistema Jview™ comúnmente son menores de un segundo (con un procesador Pentium III) para conjuntos de resultados que contienen hasta mil filas. Validación v procesamiento de la aplicación Debido al entorno orientado al objeto enriquecido que se establece dentro del entorno del subsistema Jview™, se ejemplifica la validación y procesamiento de la aplicación. Siempre que un elemento de datos dentro de la jerarquía del 24 objeto base se modifica, se invoca el método "OnUpdate()" para cada objeto original inmediato en la jerarquía base (hasta el objeto de raíz, el STM). Este método permite que cada objeto contenido active la validación o la lógica de procesamiento basado en la porción específica de su árbol que se actualizó. Durante este proceso, cualesquiera modificaciones de datos hechas a la jerarquía base se visualizan automáticamente a la interfaz del usuario. Esto se produce debido a la unión que se estableció entre las jerarquías base y de visualización. A saber, cuando un objeto base se actualiza, el sistema Jview™ mantiene una unión con todos los objetos de visualización que dependen de este objeto base. Desde estos objetos de visualización, el objeto correcto DOM (dentro del entorno del buscador) se puede regenerar. Medición del tiempo de respuesta El subsistema Jview™, que se ejecuta en el buscador del cliente, también mide y sigue el tiempo de respuesta. A continuación se resume el mecanismo que se usa para la medición y seguimiento del tiempo de respuesta. Siempre que se hace una solicitud, el subsistema Jview™ registra una etiqueta de tiempo local (TS1) dentro del buscador del cliente y pasa esto al servidor (junto con la solicitud). Después de procesar la solicitud, la respuesta desde el servidor contendrá la etiqueta de tiempo original (TS1). 125 Adicionalmente, el servidor provee su propio tiempo de respuesta principal (tiempo de servidor principal) que mide la duración desde el momento en que recibió la solicitud del servidor hasta cuando el servidor generó la respuesta. Al recibir la solicitud, el subsistema Jview™ registra otra etiqueta de tiempo local (TS2). Esta etiqueta de tiempo se toma al inicio del proceso de inicialización del subsistema Jview™ de manera que se registra de manera precisa la hora más cercana a la recepción de la respuesta. Después de tomar la etiqueta de tiempo TS2, el subsistema Jview™ continúa con su inicialización. Después de casi completar la inicialización (justo antes de devolver el control del buscador al usuario) se toma una etiqueta de tiempo final TS3 y las estadísticas del tiempo de respuesta se calculan como se indica a continuación: Tiempo de respuesta total para el usuario final = TS3- TS1 Tiempo de sobrecarga del Jview™=TS3-TS2 El tiempo de respuesta del servidor principal = tiempo de servidor principal (proporcionado por el usuario) Tiempo de la red = (TS3-TS 1 )-el tiempo del servidor principal Estas estadísticas se almacenan dentro del entorno del subsistema (dentro del administrador del subsistema Jview™) y se transmite nuevamente al servidor con la siguiente 126 solicitud de procesamiento. El servidor entonces puede almacenar esta información dentro de la base de datos de la aplicación. De esta manera, cada nueva solicitud al servidor contiene las estadísticas del tiempo de respuesta para una solicitud de procesamiento anterior. Este mecanismo es único en esta capacidad de medir el tiempo de respuesta real que experimenta el usuario final en su buscador. Optimización del rendimiento La amplia matriz de servicios locales disponibles eliminan la necesidad de que el cliente se comunique con el servidor, de esta manera reduce adicionalmente el ancho de banda, el tiempo de respuesta al usuario final y los ciclos de procesamiento del servidor. Al descargar los servicios anteriores al cliente (especialmente la generación de HTML), se logra una reducción importante en los ciclos de procesamiento del servidor. Los componentes de aplicación central JavaScript que se usan en el subsistema Jview™ son extremadamente modulares. Esta modularidad ayuda a eliminar las demoras en el tiempo de respuesta en una interacción inicial con el servidor que se asocia con los sistemas no modulados. 127 Comunicación de canales múltiples Se usan múltiples ventanas en el buscador cuando se crea un canal de comunicación separado por el servidor. Esto permite que un usuario final emita múltiples solicitudes de procesamiento de aplicación independientes y paralelas con el servidor. El OLS mantiene el estado de cada uno de estos canales de comunicación paralelo de manera que conserva la integridad de cada solicitud. Dentro de cada canal de comunicación, ya sea estructurado (STM), no estructurados (archivos), o ambos tipos de información se puede comunicar en cualquier dirección . Mantenimiento de la compatibilidad del buscador Para mantener la compatibilidad con el conjunto más amplio de los clientes basados en buscador, los niveles más bajos posibles de JavaScript y HTML se usan. Adicionalmente, sólo se proporciona el conjunto básico de los servicios de cliente delgado proporcionados por el buscador cliente. El sistema no usa adaptadores especiales, aplicaciones de Java o controles ActiveX debido a que el uso de dichos servicios reducen la capacidad de aplicación general del sistema en un amplio margen de entornos. Diagramas-Jview Los siguientes diagramas ilustran un número de características del subsistema Jview™ descrito 128 anteriormente. El diagrama 1 muestra un código de mensajes muestra de STM (modo completo). El diagrama 2 muestra un código de generación HTML del subsistema Jview™.

Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 DIAGRAMA 1 - Muestra del mensaje STM (modo completo) o Oí Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 51. RSCoActions") r 52. G ^IBACTIOM" , " /001,Eeirand Flles/0D6,Open Filo-/008,Penaing Accspcance" .'SuhroPoiaarsD-.l'endingXccaptemoBAll' ) ¡ 53. GA("traACTION", "/OOl.Demond Filss/006,Open Files/DlCPending Reoponse", "SubroPoiaerED_SendinBReeponEe") ; ¡i . GAI "HBACKON" , "/OOl.Demand Files/006, Opan Files/016, Soorc ... ¦ , "SubroFolderaD_OptmS«_rcltBa._lc" 1 ! 55. GA("NBACTIOH", ' 50 , Syatem/10, Home' ,nuU! i 56. SAI'BBACTIOH", "/50,S atem/20,Supporf,nulll ; 57. SACNBACTION", " /50. System/30, LogOilc' , "I.ogout" ) co o CJi Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 K 8 S Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 laña viW. sitGrns ">vr Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 215. </KOSCRIPT> 217. <fmv> 218. </BODYs 219. </HTM0> 134 DIAGRAMA 2 - Generación de HTML de Jview 1. var eKTMIi = new ArrayJ); // HTML Array 2. var sHTtíL; // HTML Stream 3. 4. aHTMLíaHTML.length] = *<B0DY>"; 5. aHTML{aHTML.length] = "<TABLE " ; 6. aKüSILíaKT L. leng h] - i<:R> 'i'ü>*i'his is some text.< TDx/TR>*' 7- ... additional HTML generation statements or method calis .... 8. 9. sHTKt, = aHTML. joínC'J // Créate the HTML Stream 10. JV_B0DY.OUterHTML = SHTML; ANTECEDENTES - Administrador del flujo de trabajo entre organizaciones Los sistemas automatizados que procesan transacciones comerciales con frecuencia necesitan administrar y seguir el flujo de dichas transacciones dentro del proceso comercial relacionado (es decir, flujo de trabajo). Típicamente, esta capacidad de flujo de trabajo está codificada explícitamente dentro de los programas y sistemas de programación que se usan para controlar el sistema. Estos sistemas cubren una amplia disposición de aplicaciones comerciales, de diferente complejidad, que incluyen la transmisión/ programación de la producción, el procesamiento de solicitudes, administración de recursos humanos, contabilidad financiera, administración de ventas, etc. Ejemplos comerciales de dichos sistemas incluyen ofertas de SAP, Oracle y PeopleSoft. Durante los 80 y 90's, estos sistemas se enfocaron en la integración de los procesos comerciales y los datos que 135 existían dentro de una organización (es decir, dentro de la organización). Las organizaciones implementaron satisfactoriamente dichos sistemas y lograron reducir sus costos, una mayor eficiencia y competir de manera más efectiva en una economía global. Con los sistemas entre organizaciones ahora, estas organizaciones buscan integrar los procesos comerciales y los datos que existen entre las organizaciones de socios comerciales (es decir, entre organizaciones). Requerimientos y retos Cuando menos, la administración del flujo de trabajo dentro de una organización debe ser capaz de lo siguiente: 1) mantener la información de estado relacionada con el estado actual de las transacciones comerciales (estatus). En general la información del estado se define de manera que sea fácil de comprender el flujo de la transacción al continuar desde la inserción hasta su conclusión, 2) mantener información de propiedad relacionada con propietario actual de la transacción comercial, es decir, la persona/ grupo/ organización que es responsable de realizar la siguiente acción dentro de la transacción (propiedad), 3) determinar las operaciones/ funciones permitidas que se pueden realizar en la transacción comercial en cualquier punto determinado dentro del flujo de trabajo (navegación), y 4) determinar el nuevo estado de una transacción comercial cuando se realiza 136 una operación/ función que afecta la transacción (administración del estado). Cuando la administración del flujo de trabajo para un proceso comercial complejo se codifica de manera explícita dentro de un sistema de aplicación, se presentan las siguientes limitaciones: 1) es muy difícil determinar si las condiciones del proceso comercial se pueden manejar o no; como resultado, una elaboración de pruebas total de dicho flujo de trabajo es difícil, requiere de mucho tiempo y es muy cara, y 2) cuando el proceso comercial subyacente cambia se requieren modificaciones a los programas y sistemas de programación para dar soporte a los cambios o adiciones al flujo de trabajo relacionado. Además de los requerimientos del flujo de trabajo dentro de una organización, el flujo de trabajo entre organizaciones requiere las siguientes capacidades adicionales. 1) Una estructura común, específica al proceso comercial que permite que todas las organizaciones individuales puedan comunicar el estado de una transacción comercial de una manera consistente, esto se refiere a un estado del flujo de trabajo en la comunidad o un estado del flujo de trabajo entre las organizaciones, 2) la capacidad de mantener el estado de transacción con respecto a cada organización individual involucrada en la transacción (es decir, relacionada con sus propios sistemas internos o 137 procesos comerciales); a esto se denomina estatus de flujo de trabajo específico de la organización o estatus del flujo de trabajo dentro de una organización, 3) la capacidad de distinguir entre diversas organizaciones involucradas en una transacción (es decir, las partes involucradas en la transacción), 4) la capacidad de distinguir el papel o la relación que cualquier organización determinada tiene con respecto a una transacción específica, 5) la capacidad de administrar las funciones/ operaciones que cada organización puede desarrollar con base en su relación en la transacción comercial y el estado actual de la transacción, y 6) la capacidad de proveer seguridad y privacidad a cada organización con respecto a los datos y funciones. Subsistema de la administración del flujo de trabajo entre organizaciones El subsistema de administración del flujo de trabajo entre las organizaciones (o sólo subsistema del flujo de trabajo) está diseñado para cubrir los requerimientos del flujo de trabajo entre organizaciones y dentro de una organización. Este subsistema no depende de un proceso comercial vertical específico ni ninguna aplicación. Este subsistema es único en su capacidad para lidiar con una administración del flujo de trabajo de varias partes que se expande a diferentes organizaciones. Las siguientes secciones describen las características clave y los beneficios del subsistema del flujo 138 de trabajo. Generalidades El subsistema de flujo de trabajo no administra el flujo de trabajo con base en instrucciones de programas y sistemas de programación codificados explícitamente. En su lugar, usa una serie de tablas de flujo de trabajo (estructuras de datos) y un algoritmo de flujo de trabajo único para realizar todas las operaciones de administración del flujo de trabajo. Las tablas del flujo de trabajo esencialmente son un conjunto de máquinas de estado finitas (FSM), que definen un sistema de ciclo cerrado para el flujo de trabajo relacionado con un proceso comercial determinado. Al usar este enfoque, el flujo de trabajo definido para cada proceso comercial se completa (es decir, no existen agujeros ni espacios en la tabla del flujo de trabajo). Estado (Estatus de la comunidad, flujo de trabajo entre las organizaciones) Por el flujo de trabajo entre las organizaciones, los subsistemas del flujo de trabajo incluyen una estructura que permite que todos los participantes se comuniquen el estado de sus transacciones usando un lenguaje consistente. Para cada proceso comercial, se define una estructura de comunidad específica (es decir, terminología, códigos de estado, etc.). El subsistema del flujo de trabajo puede soportar cualquier número de estructuras de comunidad 139 independiente. Dentro de la carpeta, la etapa se usa para representar el estado del flujo de trabajo de la comunidad principal para la transacción. Esto se usa para dar seguimiento al avance general de la transacción a través del flujo de trabajo hacia una conclusión. Para cada tarea dentro de la carpeta, las partes que pueden operar esa tarea se definen. Para cada parte, se mantiene un estado de la parte de tareas en la comunidad. Esto permite que el subsistema del flujo de trabajo administre y de seguimiento al estado de la comunidad de cada parte en cada tarea. Estado (Estatus de la organización, flujo de trabajo dentro de la organización) Para dar soporte al flujo de trabajo dentro de la organización, se establece una estructura paralela (similar a la estructura de comunidad) dentro del subsistema del flujo de trabajo. La única diferencia es que esta estructura es específica para una organización determinada. Esta estructura se usa para administrar y dar seguimiento a cualquier actividad específica de la organización que sucede dentro de un proceso comercial. Para cada proceso comercial se puede definir una estructura específica para la organización específica (es decir, terminología, códigos de estado, etc.) por tipo de partes. El subsistema del flujo de 140 trabajo puede dar soporte a cualquier número de estructuras específicas de una organización independiente. Para cada parte en la carpeta, la etapa de organización se usa para representar el estado del flujo de trabajo de la organización principal para la transacción. Esto se usa para dar seguimiento al avance general de la transacción a través de su flujo de trabajo específico en la organización con miras a una conclusión. Para cada tarea dentro de la carpeta, las partes que pueden operar en dicha tarea se definen. Para cada parte como tal, se mantiene un estado de la parte de tarea dentro de la organización. Esto permite que el subsistema del flujo de trabajo administre y de seguimiento el estado específico de la organización de cada parte en cada tarea. Propiedad Al mantener la parte de acción en cada tarea dentro de la carpeta, el subsistema del flujo de trabajo puede determinar qué organización es la responsable de realizar la transacción comercial tanto al nivel de carpeta como en el nivel de tarea específica. Navegación Con base en la información de estado actual que se mantiene dentro de la carpeta y sus tareas, el subsistema de flujo de trabajo puede determinar las funciones que se pueden realizar en cualquier momento por cualquier parte. 141 Esta capacidad se denomina navegación en el flujo de trabajo o sólo navegación. Al usar esta capacidad de navegación, el sistema adjunto que usa el subsistema de flujo de trabajo puede presentar a cualquier usuario la lista de las operaciones comerciales válidas que se pueden realizar en cualquier momento (sujeto al perfil de seguridad del usuario). Esto elimina la necesidad de que el operador recuerde las diferentes condiciones del flujo de trabajo y ayuda enormemente en la capacitación de nuevos operadores. Al mismo tiempo, este mecanismo asegura la integridad del proceso comercial al evitar las operaciones "fuera de proceso". Administración de estado Con base en la información de estado actual que se mantiene dentro de la carpeta y sus tareas, cuando una nueva función se realiza en la carpeta, el subsistema de flujo de trabajo automáticamente actualiza la información de estado dentro de la carpeta (es decir, en la carpeta y cualquier tarea). Esta capacidad se encuentra en el centro del subsistema del flujo de trabajo y permite una transición en orden de un estado comercial a otro. Al terminar cualquier transición de flujo de trabajo determinado, la carpeta ahora se encuentra en un estado nuevo (o el mismo estado). 142 Dentro de la tabla de flujo de trabajo es posible definir el flujo de trabajo condicional. Este flujo de trabajo permite que el estado del flujo de trabajo resultante se establezca con base en el valor de cualquier número de elementos de datos comerciales adicionales contenidos dentro de la carpeta (es decir, como se ve afectado por la función que se está realizando). La definición de estos criterios puede ser arbitrariamente compleja y cualquier número de reglas de flujo de trabajo condicional pueden definirse. Ejemplo comercial La red de subrogación electrónica es un ejemplo comercial de un sistema operativo completo que representa los conceptos descritos en la presente específicamente para el mercado vertical del procesamiento de reclamaciones de subrogación en la industria de los seguros. Terminología Esta sección contiene definiciones terminológicas que son útiles en la comprensión de los conceptos que se describen en esta sección. Carpetas Cada transacción comercial diferente se representa a través de una carpeta. La carpeta se usa para contener de manera lógica toda la información relacionada con esta transacción (por ejemplo, partes, tareas, documentos, contactos, alertas, anexos, eventos, etc.). 143 Partes Una transacción comercial involucra la interacción entre dos o más partes en donde, por propósitos de transacción, cada parte toma una relación específica (se describe posteriormente). Con un flujo de trabajo dentro de la organización, las partes típicamente son unidades comerciales diferentes (por ejemplo, división, departamento, etc.) dentro de la misma organización. Con el flujo de trabajo entre organizaciones las partes típicamente son organizaciones o individuos diferentes. Relación (tipo de parte) Para cada tipo específico de transacción comercial (carpeta), una o más relaciones se definen. Cada relación define el papel de una parte determinada que ejecutará con respecto a la transacción. Por ejemplo, en una transacción de administración sencilla de solicitud (carpeta de solicitud), una parte representa al "comprador" y una parte representa al "proveedor". De esta manera, para cada parte definida en la carpeta, esta relación de parte con la transacción se denomina como subtipo de parte. La figura 22 ilustra las relaciones de diversas partes con respecto a una transacción de demanda de subrogación de seguros. Tareas Una tarea se usa para representar una actividad comercial independiente (relacionada con la transacción para 144 esta carpeta). Cada carpeta debe tener al menos una tarea (su tarea principal). Con los procesos comerciales complejos, se usan diversas tareas dentro de la carpeta para administrar y dar seguimiento a actividades paralelas múltiples relacionadas con una transacción comercial determinada. Por ejemplo, para una transacción de administración de solicitud (carpeta de solicitud), se define una tarea para la misma solicitud, y se definen tareas adicionales para cada envío/ factura diferente. Parte de acción Para cada tarea de la carpeta, la parte responsable de realizar la siguiente acción relacionada con esta actividad comercial se denomina como la parte de acción. Cuando la transacción comercial concluye, no se producirá mayor actividad comercial. En este punto, ninguna parte de acción existe en ninguna tarea dentro de la carpeta. Función Cada operación que puede realizarse en la carpeta que afecta la información o el estado de la carpeta se denomina función. Con base en la carpeta, ciertas funciones sólo se pueden realizar a través de un tipo de parte específica, aunque otras se pueden realizar por otros o todos los tipos de parte. En una transacción de administración de orden simple algunos ejemplos de funciones incluyen: emitir una orden de compra (comprador), aceptar una solicitud inicial (proveedor), 145 crear un embarco/ factura (proveedor), etc. Transacción comercial Una interacción entre dos o más partes que ocasionan un intercambio formal o una transferencia de bienes, servicios, capital, información u otros recursos. Los ejemplos incluyen una reclamación de un seguro, una solicitud de compra, reservación de un vuelo en una línea aérea, solicitar un libro, etc. Organización Dos diferentes entidades legales (por ejemplo, compañías o individuos) opuesto a diferentes unidades comerciales (de tamaño arbitrario) dentro de una sola entidad legal. Flujo de trabajo Un conjunto definido de operaciones comerciales y/o procesos, activados por un evento comercial inicial (transacción comercial), que procede en una secuencia u orden específico y que culmina en una conclusión o terminación de la transacción. El flujo de trabajo simple seguirá un conjunto prescrito de operaciones en secuencia a la conclusión (una sola ruta). Un flujo de trabajo complejo puede contener múltiples rutas condicionales, sólo una de las cuales será tomada con base en las condiciones comerciales presentes en la transacción. 146 Flujo de trabajo entre organizaciones Un flujo de trabajo que existe entre dos organizaciones con el objetivo de realizar/ completar un proceso/ transacción comercial específica a dichas organizaciones. Estado del flujo de trabajo Un punto específico dentro de un flujo de trabajo comercial determinado para cualquier transacción determinada, su flujo de trabajo completo típicamente incluye muchos estados diferentes. Avance del flujo de trabajo (etapa) Dentro del contexto de una transacción comercial, la mayoría de las transacciones avanzan desde su inicio hasta alguna forma de cierre. Puede haber diferentes rutas que cualquier transacción determinada a través de los diversos estados del flujo de trabajo hacia el cierre. Además, el número de rutas posibles se relaciona directamente con el número de diferentes estados de flujo de trabajo y posibles transacciones permitidas en el flujo de trabajo determinado (esencialmente la mayoría de los flujos de trabajo comerciales se definen como procesos "de ciclo cerrado" ya que cualesquiera transacciones que entren al sistema eventualmente saldrán del sistema. Dentro del sistema de administración del flujo de trabajo entre organizaciones, el avance actual de una transacción determinada se denomina como etapas. La etapa se mantiene en la carpeta para cada 147 transacción comercial. Máquina de estado finito (FSM) Un modelo de cómputo que consiste en un conjunto de estado, un estado de inicio, un alfabeto de entrada y una función de transición que correlaciona símbolos de entrada y estados actuales con un estado siguiente. El cálculo comienza en un estado de inicio con una cadena de entrada. Cambia a nuevos estados dependiendo de la función de transición (definición anterior tomada de NIST-http:/ / www.nist.gov/ dads/ HTML/ finiteStateMachine.html. DESCRIPCIÓN DETALLADA - Administración del flujo de trabajo entre organizaciones El subsistema de administración del flujo de trabajo entre organizaciones (o sólo subsistema de flujo de trabajo) proporciona una administración del flujo de trabajo tanto entre las organizaciones como dentro de una organización. Este subsistema no depende de un proceso comercial vertical específico o aplicación y es único en su capacidad de tratar con la administración de flujo de trabajo de múltiples partes que se extienden en diferentes organizaciones. Esta sección contiene el proceso detallado y las descripciones de los componentes relacionados con el subsistema del flujo de trabajo. Este análisis supone alguna familiaridad con los siguientes conceptos y tecnologías: Conceptos y terminología de una máquina de estado 148 finito Conceptos de procesamiento de transacción orientados al negocio en general Diseño y programación orientado a un objeto El subsistema de flujo de trabajo descrito en esta sección se ha implementado dentro de los siguientes contextos de transacción comercial: Seguro - reclamaciones de subrogación (demandas, contrademandas, presentación de arbitraje, etc.) Fabricación - procesamiento de solicitudes (solicitudes de compras, envío, facturación, devoluciones, etc.) Ventas al menudeo - administración de la tienda (programación de tareas, mantenimiento de empleados, seguimiento de horarios, etc.) General - registro de llamadas y administración de problemas Descripción general Las siguientes secciones resumen los conceptos clave que se usan dentro del sistema. Generalidades Las siguientes descripciones generales guían el desarrollo del subsistema del flujo de trabajo. Una carpeta (definida posteriormente) es un contendor para un conjunto relacionado de elementos de datos para una transacción comercial determinada. En el sentido más puro, el estado de 149 flujo de trabajo real de una carpeta determinada se representa mediante los valores diferentes que existen en todos sus elementos de datos en cualquier punto del tiempo. Infortunadamente, este enfoque no es práctico para la comprensión humana (es decir, una sobrecarga de información). Desde un punto de vista práctico, el flujo de trabajo de una carpeta determinada se puede representar adecuadamente mediante un conjunto finito de permutaciones de valor que se producen entre un subconjunto de sus elementos de datos. Cada una de dichas permutaciones se representa a través de un estado de flujo de trabajo determinado. Esta es una forma de taquigrafía que permite que los humanos comprendan, organicen y relacionen el procesamiento de cualquier transacción comercial. Carpeta Dentro del sistema, cada transacción comercial diferente se representa a través de una carpeta de transacciones. Cada carpeta tiene las siguientes características clave. Es un contenedor lógico para toda la información relacionada con la transacción (por ejemplo, partes, tareas, documentos, contactos, alertas, anexos, eventos, etc.). Dentro de la carpeta, se mantiene una variable (etapa) del flujo de trabajo principal. Esta variable representa el avance del flujo de trabajo para esta carpeta. Estas partes representan un conjunto diferente de organizaciones que 150 tienen el servicio de interactuar con esta transacción. Cada una de tales partes definidas está regida por su relación con la transacción (denominada como el tipo de partes). Esta relación de partes se usa para restringir la información que se puede visualizar y las funciones que se pueden realizar (a través de esta parte, con respecto a su transacción). Dentro de la carpeta, una o más tareas de flujo de trabajo se definen. Una tarea se usa para representar una actividad comercial independiente (relacionada con la transacción para esta carpeta). Cada carpeta debe tener al menos una tarea (su tarea primaria). Etapa Para cualquier carpeta de transacción, la etapa representa el mayor avance (es decir, su avance en el flujo de trabajo) de esa transacción hacia su terminación o cierre final. En general, una vez que una transacción ha cambiado a una etapa determinada, no regresa a una etapa anterior. Tareas de las partes y tareas Dentro de una carpeta, las tareas se usan para representar una o más actividades comerciales que se producen con relación a la terminación de la transacción. A continuación se presentan las características de una tarea: La granularidad de la definición de la tarea (es decir, la actividad comercial específica a la cual se refiere) depende de las necesidades de la aplicación comercial específica. Por 151 defecto, una tarea primaria se crea cuando ia carpeta de transacción se crea. Cuando se crea la tarea, cierto número de partes deben asignarse a la tarea (al menos una). Esta asignación se usa para restringir la información que se puede visualizar y las funciones que se pueden realizar (por esta parte, con respecto a esta tarea). Las partes adicionales pueden recibir un acceso garantizado a la tarea durante su vida útil. Una vez asignadas, una parte no se elimina de una tarea. Para cada parte asignada a una tarea, se crea una parte de tarea. Las tareas múltiples pueden existir dentro de una carpeta al mismo tiempo. Esto permite que el sistema soporte la actividad comercial paralela dentro de una transacción comercial determinada. Dentro de cada parte de la tarea, existe una variable específica para la parte (estado de la parte) para cada parte definida en la tarea. Esta variable se usa para dar seguimiento al estado de flujo de trabajo actual de esa parte con respecto a la tarea. Existe una sola variable de acción (parte de acción) para cada tarea que identifica la parte que necesita tomar la siguiente acción para esta tarea. Debido a que pueden existir diferentes tareas en una carpeta, pueden existir varias variables de acción (es decir, un flujo de trabajo paralelo se puede administrar). Dentro de cada tarea, una última variable de actividad contiene una descripción de la última actividad 152 que se realizó en la tarea que cambió la parte de acción. Cualquier parte puede ver todos los estados de flujo de trabajo de una tarea a la que tenga acceso. Cualquier función puede cambiar el estado de una o más variables de estado específicas de una parte en una o más tareas (como se define dentro de la tabla de flujo de trabajo). Cuando todos los estados de las partes de una tarea se "cierran", la tarea se "cierra". En este caso, se configura un indicador de acción en nulo (es decir, una tarea que está cerrada y no requiere acción). Cuando el estado de la tarea principal es "cerrado", la etapa de la carpeta está "cerrada". Sin embargo, en este caso, otras tareas dentro de la carpeta pueden no estar cerradas. Esto permite que se produzca un flujo de trabajo "después del cierre" de una manera ordenada. En el punto en que todas las tareas dentro de la carpeta están "cerradas", la carpeta se "cierra". El estado del flujo de trabajo real de una carpeta realmente es la suma de todos los estados de todas las tareas. Flujo de trabajo de la comunidad Con el flujo de trabajo entre organizaciones, se debe establecer un lenguaje común o estructura para todas las organizaciones involucradas en las transacciones. Esto permite una comunicación efectiva y consistente relacionada con el estado de flujo de trabajo de una transacción determinada. Dentro del subsistema de flujo de trabajo, los 153 siguientes elementos de datos representan esta estructura común: Carpeta - etapa Parte - tipo de parte Tarea - parte de acción, última actividad Tareas de la parte - estado de la parte Estos elementos de datos representan la información del flujo de trabajo en la comunidad que está disponible para todas las partes definidas en la carpeta específica. Flujo de trabajo dentro de la organización Debido a que cualquier flujo de trabajo dentro de la organización debe también existir dentro del contexto del flujo de trabajo dentro de la organización (es decir, el flujo de trabajo que es específico para una organización determinada), el subsistema de flujo de trabajo soporta el mantenimiento de los estados del flujo de trabajo específicos de la organización. Los siguientes elementos de datos se usan para mantener el estado de flujo de trabajo específico de la organización: Parte - etapa de la organización Tareas de la parte - estado de la organización Estos elementos de datos representan la información del flujo de trabajo específico de la organización. Esta información es privada para cada parte dentro de la carpeta. 154 Modelo de datos del flujo de trabajo La figura 25 ilustra las entidades de los datos principales y sus relaciones que se usan mediante el subsistema de flujo de trabajo. Las entidades carpetas (SAFolder), partes (SAParty), tarea (SATask) y parte de la tarea (SATaskParty) contienen la información del estado de flujo de trabajo real para una transacción comercial determinada. La tabla de flujo de trabajo contiene las definiciones del flujo de trabajo que se usan mediante los procesos del flujo de trabajo. Tabla del flujo de trabajo La tabla de flujo de trabajo se encuentra en el centro del subsistema del flujo de trabajo. Esencialmente, esta tabla se usa para definir y organizar múltiples máquinas de estado finito (FSM). Estas FSM funcionan en combinación para definir y controlar el flujo de trabajo para el sistema de aplicación completo. Esta tabla y los procesos de flujo de trabajo relacionado se describen con detalle a continuación. Para un sistema de aplicación determinado, se define una sola tabla de flujo de trabajo que contiene las definiciones del flujo de trabajo de comunidad para todas las transacciones comerciales procesadas por esta aplicación. También se define otra tabla que contiene las definiciones del flujo de trabajo específica de la organización. Esta tabla de 155 flujo de trabajo específico de la organización es similar en estructura a la tabla de flujo de trabajo de comunidad. Transiciones del estado de flujo de trabajo El objetivo principal de la tabla de flujo de trabajo es permitir que el sistema determine el estado de flujo de trabajo a continuación para una carpeta de transacciones con base en su estado actual y la terminación de una función de aplicación determinada que modifica esta carpeta (es decir, la transición del estado de flujo de trabajo). Dentro del subsistema de flujo de trabajo, el mecanismo de transición de flujo de trabajo se usa para modificar uno o todos de lo siguiente: etapa, estado de la parte, parte de acción o partes de tarea. Navegación del flujo de trabajo Además de definir las transiciones de los estados del flujo de trabajo, la tabla del flujo de trabajo define de manera implícita la navegación del flujo de trabajo también. Para cualquier carpeta de transición determinada en un estado determinado, la tabla de flujo de trabajo define las funciones de la aplicación que se permiten realizar en este estado. Con base en estas definiciones, el subsistema de flujo de trabajo puede devolver esta lista de funciones y aplicación válidas a cualquier carpeta en cualquier momento. Con un sistema en línea, esto es útil ya que permite que el sistema guíe o navegue a un usuario a través del 156 sistema mostrando las funciones permitidas que son válidas. Esto reduce el conocimiento del flujo de trabajo requerido por los usuarios, una velocidad de capacitación y permite que usuarios menos capacitados operen el sistema. Administración de la parte de acción Un problema que existe con el flujo de trabajo entre organizaciones es determinar, en cualquier momento, qué organización es la responsable de realizar la siguiente acción en la transacción. Con cada tarea, el campo actionParty de la parte de acción contiene el tipo de parte de la parte que es responsable de seguir a la siguiente acción en esta tarea. De hecho, debido a que múltiples tareas pueden existir dentro de una carpeta, el subsistema de flujo de trabajo puede dar seguimiento a la parte de acción para varias tareas. Estructura de la tabla de flujo de trabajo La tabla de flujo de trabajo contiene registros que definen el flujo de trabajo para todas las transacciones comerciales dentro de un sistema de aplicación determinado. Los atributos detallados dentro de esta tabla están contenidos en el diagrama 3 a continuación. Los registros en la tabla de flujo de trabajo se organizan en grupos junto con las siguientes dimensiones: tipo de carpeta, tipo de tarea, etapa, tipo de parte de tarea y estado de parte. Estas agrupaciones dividen esencialmente la tabla en 157 varios conjuntos de registro de flujo de trabajo junto con una dimensión determinada. Dentro de estas dimensiones, cada registro de flujo de trabajo define la transición de estados del flujo de trabajo que se produce después de completar el procesamiento de una función de la aplicación específica. Adicionalmente, cada registro de flujo de trabajo define de manera implícita las funciones de la aplicación que son "válidas" de un punto de vista de flujo de trabajo dentro de cualquier estado de flujo de trabajo determinado (de esta manera se permite que el sistema soporte la navegación en el flujo de trabajo). Código de operación del flujo de trabajo Un registro de flujo de trabajo determinado se puede definir para controlar la navegación del flujo de trabajo, las transiciones del estado de flujo de trabajo, o ambos. El campo operationCode del código de operación se usa para especificar cuáles de estas operaciones en el flujo de trabajo se realizarán. Flujo de trabajo condicional En la mayoría de los casos, las transiciones en los estados de flujo de trabajo son simples y determinantes, el siguiente estado de flujo de trabajo se determina simplemente a través del estado de flujo de trabajo actual y la función de aplicación que se completa. Sin embargo, en algunos casos, la transición sólo se puede determinar al inspeccionar otros 158 elementos de datos dentro de la carpeta de transacciones. En este caso, el flujo de trabajo es condicional. Para dar soporte al flujo de trabajo condicional, la tabla de flujo de trabajo permite que se definan múltiples registros del flujo de trabajo para el mismo estado del flujo de trabajo y la misma función de la aplicación. Estos registros entonces se diferencian a través del postConditionQualifier que es un calificador de condiciones posterior. Similar a la cláusula "EN DONDE" dentro de una afirmación de SQL, este campo define la condición de datos bajo los cuales se realiza la transición de los estados. Si esta condición da un resultado en la evaluación de "verdadero" el motor de flujo de trabajo realiza la transición de estados como se definió en este registro. De no ser así, continúa con la evaluación de los calificadores condicionales en los otros registros del flujo de trabajo (si todas las condiciones devuelven un resultado "FALSO", el motor de flujo de trabajo devuelve un error en el flujo de trabajo al subsistema que hace la llamada). Esta capacidad de flujo de trabajo condicional también aplica a la navegación del flujo de trabajo. En algunos casos, una aplicación determinada puede o no estar permitida dentro de un estado de flujo de trabajo determinado con base en los valores de otros elementos de datos dentro de la carpeta de transacción. Para dar soporte a esta capacidad, se puede definir un preConditionQualifier que es un calificador de 159 condiciones previas para cada registro de flujo de trabajo. Al realizar la navegación del flujo de trabajo, el sistema sólo devuelve funciones de la aplicación para un estado de flujo de trabajo determinado en donde este campo es nulo o en donde el calificador da una evaluación de "verdadero". Asignación de partes de tareas adicionales a una tarea Como parte del mecanismo de transición del estado de flujo de trabajo, partes de tareas adicionales se pueden añadir a una tarea específica como respuesta a una función de la aplicación. Esto se controla mediante el campo taskPartyArray, en donde se define la matriz de la parte de la tarea. Una vez que se selecciona un registro del flujo de trabajo determinado para la transición de los estados en el flujo de trabajo, si la matriz de la parte de tareas contiene un tipo de parte para una parte que no existe en esa tarea, entonces se añade un nuevo tipo de parte al campo currentPartyArray para esa tarea. Administración de la parte de acción Como parte de los mecanismos de transición del estado de flujo de trabajo, la parte de acción para una tarea determinada se puede modificar como respuesta a una función de aplicación. Esto se controla a través del campo nextActionParty. Una vez que se selecciona un registro de flujo de trabajo determinado para una transición en el estado de flujo de trabajo y si el campo nextActionParty contiene un 160 tipo de parte, entonces la parte de acción para esta tarea se actualiza. Adicionalmente, si el campo nextActionParty contiene un "?", entonces eso indica que el tipo de la parte de siguiente acción depende de la aplicación, y en este caso, el tipo de la parte de siguiente acción se proporciona desde el subsistema que invoca el administrador del flujo de trabajo. Procesamiento del flujo de trabajo Existen dos tipos diferentes de procesamiento de flujo de trabajo que se realiza a través del subsistema de flujo de trabajo, navegación de flujo de trabajo y transiciones de estados en el flujo de trabajo. Las siguientes secciones describen este procesamiento con detalle. Navegación en el flujo de trabajo A continuación se describe la operación del mecanismo de navegación en el flujo de trabajo. El subsistema que hace la llamada invocará al método de clase GetWorkFlowFunctions() de la clase WorkFlowManager. Al hacerlo, se basarán los siguientes parámetros: OFolder-hace referencia a la carpeta a la que tiene acceso; SPartyType-el tipo de partes de la organización que accede a la carpeta; AFunctions-es una matriz vacía (que es para contenerlas funciones de flujo de trabajo válidas). 161 Con el método GetWorkFlowFunctions(), se realiza lo siguiente: con base en la referencia de la carpeta, se determina el estado de flujo de trabajo actual (por ejemplo, etapa, tarea, estados de la parte de tarea, etc.). Recupera los registros de la tarea para esta carpeta. PARA CADA tarea dentro de la carpeta (oTask), Recupera los registros de la parte de tarea para esa tarea. PARA CADA registro de la parte de tarea (oTaskParty), La consulta de la tabla de flujo de trabajo será consultada usando lo siguiente: SELECCIONAR * DE* SAWORKFLOW EN DONDE ((TipodeCarpeta= oFolder.folderType) Y (TipodeTarea= oTask.taskType) Y (Etapa= oFolder.stage) Y (TipodeTareadePartes= oTaskParty. partyType) Y (EstadodelasPartes = oTaskParty.partyState) Y (PartedeAcción= sPartyType) Y ((CódigodeOperación= '?') o (operationCode = "B')) ); PARA CADA registro del flujo de trabajo devuelto, SI el CalificadorCondicionesPrevias tiene un valor de "nulo" ENTONCES Se agrega la función de la aplicación especificada en este registro para aFunctions. 162 DE OTRA MANERA SI el CalificadorCondicionesPrevias da un resultado de VERDADERO ENTONCES Se agrega la función de la aplicación especificada en este registro para aFunctions. TERMINA SI TERMINA SI TERMINA PARA (no más registros del flujo de trabajo) TERMINA PARA (no más registros del las tareas de la parte) TERMINA PARA (no más registros de tareas) En este momento, la matriz aFunctions contiene la lista de funciones de aplicación que se permiten para la carpeta actual en su estado actual. El método GetWorkFlowFunctionsO se devuelve al que hace la llamada. Transiciones en los estados del flujo de trabajo A continuación se describe la operación de los mecanismos de transición de los estados de flujo de trabajo.

El subsistema que hace la llamada invoca al método de clase EvaluateWorkflowO de la ciase WorkFlowManager. Al hacerlo, los siguientes parámetros pasan: oFolder-hace referencia a la carpeta que se está procesando; oFunction-hace referencia a la función de la aplicación (cuyo procesamiento se ha recién completado); sPartyType-el tipo de parte de la organización que 163 accede a la carpeta; y sNextActionPartyType, si el campo nextActionParty para esta función de aplicación depende de la aplicación, entonces este campo contiene el tipo de la parte de acción siguiente, de otra manera será nulo. Dentro del método EvaluateWorkflowQ , se realizaron lo siguiente: con base en la referencia de la carpeta, se determina el estado flujo de trabajo actual (por ejemplo, etapa, tareas, estados de la parte de tarea, etc.)- La etapa actual se guarda en sCurrentStage. Si la función de la aplicación (oFunction) indica que se debe crear una nueva tarea, ENTONCES crea la nueva tarea para esta carpeta TERMINA SI Se recuperan los registros de las tareas para esta carpeta. PARA CADA tarea dentro de la carpeta (oTask), Recupera los registros de las tareas de las partes para esta tarea. PARA CADA registro de tareas de las partes (oTaskParty), La consulta de la tabla del flujo de trabajo se consulta usando lo siguiente: SELECCIONAR * DE SAWORKFLOW EN DONDE 164 ((TipodeCarpeta = oFolder.folderType) Y (TipodeTarea = oTask.taskType) Y (Etapa = sCurrentStage) Y (TipodeTareadePartes = oTaskParty .partyType) Y (EstadodeParte = oTaskParty .partyState) Y (PartedeAcción = sPartyType) Y ((CódigodeOperación = 'S') o (CódigodeOpeación = 'B')) ); PARA CADA registro de flujo de trabajo devuelto, SI el valor para el CalificadordeCondicionesposterior es "nulo" ENTONCES Se realiza la transición de estado indicada en este registro de flujo de trabajo (véase a continuación). DE OTRA MANERA SI el resultado del CalificadordeCondicionesposterior es VERDADERO ENTONCES Se realiza la transición de estado indicada en este registro de flujo de 165 trabajo (véase a continuación). TERMINA SI TERMINA SI TERMINA PARA (no hay más registros de flujo de trabajo) TERMINA PARA (no hay más registros para tareas de las partes) TERMINA PARA (no hay más registros de tareas) Cuando se realizará una transición de estado, las siguientes operaciones se producen usando los valores del registro de flujo de trabajo seleccionado. SI el valor de nextStage no es "nulo" ENTONCES Se establece la carpeta oFolder.stage = nextStage TERMINA SI SI el valor de nextPartyState no es "nulo" ENTONCES Se establece oTaskParty.partyState = nextPartyState TERMINA SI SI el valor de nextActionParty no es "nulo" ENTONCES SI nextActionParty = "?" ENTONCES Se establece oTask.action Party = 166 sNextAction PartyType DE OTRA MANERA Se establece oTask.actionParty = nextActionParty TERMINA SI TERMINA SI SI el valor de taskPartyArray no es "nulo" ENTONCES Se agregan nuevas partes a oTask.currentPartyArray. PARA CADA parte nueva agregada Se crea un nuevo registro de TaskParty para esta tarea Se agrega este nuevo registro TaskParty a la matriz de tareas de las partes que está en procesamiento (de manera que el estado de la parte para este nuevo registro de las tareas de la parte se inicializa correctamente). TERMINA PARA TERMINA SI En este punto, la transición del estado de flujo de trabajo se completa y el método EvaluateWorkflowO regresa al que hace la llamada. 167 NOTA: Dentro de este procesamiento, la evaluación del flujo de trabajo se realiza después del procesamiento de la función de aplicación que modificó la carpeta. Esto es necesario para permitir que la aplicación modifique los elementos de datos de la aplicación dentro de la carpeta. Una vez que esto se completa, se evaluarán los postConditionQualifier (y el flujo de trabajo resultante) en comparación con los nuevos datos de la aplicación. Ejemplo de procesamiento del subsistema de flujo de trabajo Esta sección ilustra un ejemplo del subsistema de flujo de trabajo dentro del contexto de la aplicación Subrogación de Seguros. Descripción general del flujo de trabajo de la subrogación Una reclamación de una subrogación es una transacción comercial entre dos compañías de seguros, una compañía demandante y una contraparte. Esta reclamación se presenta cuando se presenta un accidente entre dos vehículos asegurados, uno asegurado por la parte demandante y el otro asegurado por la contraparte (en donde el conductor de la contraparte fue el responsable del accidente). En este caso, la compañía que hace la demanda tiene derecho de buscar el reembolso de la contraparte por el costo incurrido en la reparación del vehículo de su 168 asegurado. La compañía demandante inicia la transacción enviando una demanda de subrogación a la compañía de la contraparte. La aplicación proporciona un ASP con base en la aplicación (red electrónica), que permite que las aseguradoras procesen y establezcan sus reclamaciones de subrogación usando un sistema automatizado. Este sistema puede hacer interfaz con una aseguradora ya sea de manera electrónica o manual (a través de una interfaz basada en una red electrónica). El flujo de trabajo relacionado con el procesamiento de una reclamación de subrogación es complejo ya que la transacción puede seguir diferentes rutas durante su vida. De esta manera, las partes adicionales (más allá del demandante y el respondedor) pueden estar involucrados en la transacción. La figura 22 ilustra un conjunto completo de partes que pueden participar en una transacción de subrogación determinada. Carpetas La aplicación de la subrogación lidia con las siguientes carpetas de transacción: Carpeta de demanda (SAFolder_Subro) Carpeta de transferencia del archivo de demanda (SAFolder_DemandUpload) Carpeta de compañía (SAFolder_Company) 169 Carpeta de ubicación (SAFolder_Location) Carpeta de grupo (SAFolder_Group) Carpeta del operador (SAFolder_Operator) Carpeta del sistema (SAFolder_System) Carpeta de alerta del sistema (SAFolder_SystemAlert) Cada una de las carpetas anteriores tiene su propio flujo de trabajo definido dentro de la tabla de flujo de trabajo.

Para este ejemplo, sólo describiremos el flujo de trabajo relacionado con la carpeta de demanda. Partes La carpeta de demanda puede tener las siguientes partes: Demandante (D)-la parte principal (es decir, la aseguradora) que inicia la transacción. Respondedor (R)-la contraparte (es decir, la aseguradora o el conductor no asegurado) responsable de la reclamación. Arbitro (A), para las demandas en arbitraje, la organización del arbitraje. Agencia de cobranza (C), si la contraparte es un conductor no asegurado, la agencia de cobranza que maneja la recuperación. Abogado del demandante (X)-para las demandas en litigio, es el abogado de la parte demandante. Abogado del respondedor (Y)-para demandas en litigio, 170 es el abogado de la contraparte. Demandante asegurado (E)-el tenedor de la póliza de la parte demandante. Respondedor asegurado (S)-el tenedor de la póliza de la contraparte. Tareas de la carpeta de demanda La carpeta de demanda puede tener las siguientes tareas: Demanda - la tarea principal que representa la reclamación de la subrogación. Arbitraje - una tarea secundaria que se usa para dar seguimiento a la actividad de arbitraje. Litigio - una tarea secundaria que se usa para dar seguimiento a la actividad de litigio. Etapas de la carpeta de demanda Las siguientes etapas se definen para la carpeta de demanda: Init-La etapa inicial que se usa cuando la carpeta de demanda se crea inicialmente. Preparación - la demanda que se ha creado, pero no se ha emitido a una contraparte. Emitido - Demanda emitida a una compañía de contraparte. Negociación - La demanda que está en negociación entre la parte demandante y la contraparte. 171 Arbitraje - Demandante que ha decidido buscar un arbitraje. Arbitraje final - el arbitraje está completo y se ha hecho una sentencia. Litigio - El demandante ha decidido continuar con un litigio. Litigio final - el litigio está completo y se ha elaborado una sentencia. Cerrado - la transacción de demanda ya se ha cerrado. Estados de la parte Para cada una de las tareas mencionadas, y para cada parte, se definen estados específicos de la parte. Dentro del flujo de trabajo de subrogación, actualmente hay 60 combinaciones válidas de estados y etapas de la parte. Funciones de la aplicación Dentro de la aplicación de subrogación, existen actualmente 60 funciones de edición diferentes que se pueden realizar en la carpeta de demanda. Ejemplo de la tabla de flujo de trabajo Dentro del diagrama 4 (se muestra posteriormente) existen algunas filas representativas de la tabla de flujo de trabajo que se usa dentro de la aplicación de subrogación de seguros. Estas filas muestra todas se refieren a la carpeta de demanda e ilustran el flujo de trabajo de un demandante (tipo de parte D) o respondedor (tipo de parte R). 172 Con base en el número de estados de flujo de trabajo (60) y funciones de la aplicación (60), la carpeta de demanda tiene 3,600 condiciones de flujo de trabajo posibles. Sin embargo, debido a que la tabla de flujo de trabajo sólo contiene condiciones de flujo de trabajo (válidas), la tabla final sólo contiene 1,000 filas (es decir, 2,600 combinaciones no son válidas). A continuación se describe la manera en que estas filas del flujo de trabajo se usan para controlar el flujo de trabajo relacionado con la subrogación. Creación de una nueva carpeta de demanda de subrogación (fila 344) Esta fila del flujo de trabajo se usa para controlar el flujo de trabajo cuando se crea inicialmente una carpeta de transacción de subrogación nueva (desde la función de la aplicación DemandD_CreateElectronic). 173 Control de navegación en el flujo de trabaio para la función de arbitraje (fila 105) Esta fila del flujo de trabajo sólo se usa para controlar la navegación en el flujo de trabajo para el demandante. Al usar un "preConditionQualifier", esta fila permite que el demandante realice la función de la aplicación Demand D_Arbitrate sólo si la contraparte pertenece a la organización de arbitraje. 174 Establecimiento de la parte de acción con ayuda de la función aplicación (fila 808) Esta fila del flujo de trabajo se usa para controlar el flujo de trabajo para una función de averiguación que se ejecuta a través del demandante dentro de la etapa "negociación" y el estado de la parte demandante "contraoferta aprobada". Debido a que se puede enviar una averiguación a una de muchas partes, esta fila ilustra el uso del símbolo "?" para establecer la parte de la siguiente acción para esta tarea en la carpeta. 175 Procesamiento de transición para los estados en el fluio de trabajo sólo para la aprobación de una contraoferta (fila 856) Esta fila del flujo de trabajo sólo se usa para controlar la transición de los estados en el flujo de trabajo cuando una parte demandante aprueba una contraoferta. Debido a que la capacidad para realizar esta función se basa en el estado de 176 la parte de la contraparte, la navegación en el flujo de trabajo para esta función se define dentro de la sección de la parte de tareas de la contraparte (descrita posteriormente en la fila 936). de la parte de otra parte (fila 936) Esta fila del flujo de trabajo se usa para controlar la navegación en el flujo de trabajo para asegurar que un demandante sólo puede aprobar una contraoferta con base en el estado de la parte de la contraparte. Adicionalmente, 177 cuando la parte demandante realiza esta función, esta fila también se usa para actualizar el estado de la parte para la contraparte.

Adición de partes a una nueva tarea (fila 51) Cuando la parte demandante realiza la función DemandD_Arbitrate (que indica que buscan el arbitraje para esta demanda), el subsistema de flujo de trabajo crea una nueva tarea para esta carpeta, la tarea de arbitraje (como se indica en el registro de funciones para esta función de 178 aplicación). La tabla de flujo de trabajo contiene diferentes filas para administrar el estado del flujo de trabajo definido por cada tarea dentro de la carpeta. Esta fila del flujo de trabajo sólo se usa para controlar la transición de los estados del flujo de trabajo para la tarea de arbitraje recién creada.

Diagramas - administración del flujo de trabajo entre organizaciones Los siguientes diagramas ilustran un número de características del subsistema de administración del flujo de 179 trabajo entre organizaciones descrito anteriormente. Diagrama 3 - Esquema modelo de los datos del flujo de trabajo - Tabla de flujo de trabajo (SAWorkflow) Diagrama 4 - Ejemplo de la tabla del flujo de trabajo -subrogación de seguros |\3 N> en o en o en Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 DIAGRAMA 3 - Esquema modelo de los datos del flujo de trabajo - Tabla de flujo de trabajo (SAWorkflow) Este esquema modelo de datos representa la entidad que se usa para controlar el flujo de trabajo de la comunidad que se define para cualquier aplicación determinada. Siempre que se realice una función de "edición" en una carpeta, los métodos de administración del flujo de trabajo usan esta tabla para controlar la etapa, el estado y la parte de acción y sus campos, stage, state y actionParty dentro de las entidades SATask y SATaskParty dentro de la carpeta. Esta tabla se usa para dos objetivos en el flujo de trabajo: 1) Determinar los siguientes pasos en el flujo de trabajo permitidos, con base en una condición de flujo de trabajo determinada (etapa, tipo de parte, estado, subestado, etc.). 2) Determinar el siguiente estado del flujo de trabajo de la carpeta después de realizar una función determinada, con base en el estado del flujo de trabajo actual de la carpeta. Los registros del flujo de trabajo dentro de esta tabla se organizan en la siguiente jerarquía/ grupos: Tipo de carpeta Tipo de tarea Etapa Tipo de la parte de la tarea Estado de la parte ro ro n o tn Oí Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 Atributos Nombre Tipo de Longitud Dígitos Nulos Requerido Descripción datos decimales actionPartyType Cadena 1 N R El tipo de parte de la parte que realiza la función folderType Cadena 64 N R El tipo de carpeta. Este campo contiene el nombre de la entidad de la carpeta a la que aplica este registro del flujo de trabajo (por ejemplo, SASubfolder, SADemandUploadFolder, etc. intrinsicFunctionld Cadena 255 N R El identificador de la función intrínseca (como se especifica en SAIntrinsicFunction) asociado con la función que se está realizando. nextActionParty Cadena 1 Y 0 Especifica el tipo de parte responsable de desarrollar la siguiente acción para esta tarea. Si se especifica, este campo puede contener un código de tipo de parte válido (por ejemplo, D, R o A), o un signo "?". El valor "?" es un valor especial que indica que el administrador del flujo de trabajo de la parte de siguiente acción se determina dinámicamente a través de la función de la aplicación que está en ejecución. Al hacerlo, el TPL debe proveer una invocación de API que permite que la función de la aplicación establezca la "nextActionParty" para una tarea determinada (durante la llamada válida). Debido a que pueden existir varias tareas, es posible que la función de aplicación deba especificar la parte de acción para cada tarea (si cada tarea especifica un "?"). Cuando el TPL invoca al administrador de flujo de trabajo para evaluar el flujo de trabajo para una carpeta, debe pasar los valores para la parte de acción que se establecieron a través de la función de la aplicación para cada tarea. r ?3 en o en en Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 Nombre Tipo de Longitud Dígitos Nulos Requerido Descripción datos decimales nextPartyState Cadena 64 Y 0 La siguiente parte especifica el estado (dentro de la entidad SATaskParty específica) para esta entrada en el flujo de trabajo. Si este campo es nulo, el estado específico de la parte actual ínara esta Darte} no se ve afectado. nextStage Cadena 64 Y O La siguiente etapa que se establece (dentro de la entidad Folder) para esta entrada de flujo de trabajo. Si este campo es nulo, la etapa actual no se ve afectada. nextStateEventPathToR Cadena 255 Y 0 Si se genera un evento de siguiente estado (como se indica oot a través de nextStateTemplateld), este campo se usa para especificar la ruta clave hacia el objetivo raíz para este evento. El objetivo raíz para esta ruta clave será la carpeta cuyo estado de flujo de trabajo se está procesando actualmente. NOTA: si el objeto raíz para el evento es el mismo que el objeto raíz para esta entrada de flujo de trabajo (es decir, la carpeta, entonces este campo es nulo). NextStateEventTemplate Cadena 255 Y 0 Si se genera un evento de siguiente estado, este campo se Id usa para especificar el identificador de la plantilla del evento para ese evento. operationCode Cadena 1 N R La operación del flujo de trabajo para esta fila es como se indica a continuación: S-cambio de estado - indica que esta fila sólo se usa para evaluar el siguiente estado de la carpeta después de realizar una función de edición. N-navegación - indica que esta fila sólo se usa para determinar el conjunto válido de funciones de edición que están permitidas con base en el estado actual de la carpeta. B-ambas - indica que esta fila se usa para las operaciones de cambio de estado y navegación.

Oí s? n Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 Nombre Tipo de Longitud Dígitos Nulos Requerido Descripción datos decimales partyState Cadena 64. N R Estado de flujo de trabajo (específico para el tipo de postConditionQualifier Cadena 4000 Y O Este calificador se usa para dar soporte al flujo de trabajo (condicional). En este caso, dos o más filas dentro de la tabla para el estado de flujo de trabajo actual especifican este calificador. El sistema evalúa el calificador para cada fila y establece el siguiente estado de flujo de trabajo con base en la fila cuyo calificador evalúa en "verdadero". NOTA: cuando se usa este campo, los calificadores especificados para un conjunto determinado de filas deben ser EXCLUSIVOS MUTUAMENTE, en que sólo uno y sólo un calificador debe evaluar en verdadero en cualquier momento determinado. Si este campo es nulo, entonces se asume que el siguiente estado de flujo de trabajo especificado para esta entrada de flujo de trabajo se puede 'realizar de manera incondicional. preConditionQualifier Cadena 4000 Y O Un calificador que se usa para determinar de manera condicional si la función especificada para esta entrada de flujo de trabajo se puede realizar o no. Si este campo es nulo, entonces se asume que la función especificada para esta entrada de flujo de trabajo se puede realizar de manera incondicional. Si este campo no es nulo, entonces el sistema evalúa el calificador. Si el calificador da una evaluación de "verdadero", entonces la función especificada para esta entrada de flujo de trabajo se permite, de otra manera se desecha.

Ni N3 en o en en Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 Nombre Tipo de Longitud Dígitos Nulos Requerido Descripción datos decimales Stage Cadena 64 N R Etapa del flujo de trabajo. status Cadena 255 Y O Este campo se usa para establecer el estado de la tarea para la parte específica (SATaskParty). El administrador del flujo de trabajo establece el estado de la parte adecuada con base en el valor de este campo como se indica a continuación: Nulo-el estado de la parte de acción se usa como el estado. No nulo-el valor de este campo se usa como el estado. No nulo y el primer carácter "&", el valor de este campo se anexa al estado actual y el "&" se reemplaza con una stkeyNextStateEventTe Cadena 4000 Y O Campo de relación (véase la sección de relaciones a mplate continuación) taskPartyArray Cadena 16 Y O Especifica los tipos de parte que deben tener acceso a la tarea representada por esta entrada de flujo de trabajo. La sintaxis de este campo es una serie de cadenas de uno o más códigos de tipo de parte en donde cada de tipo de parte diferente se representa a través de un solo carácter (es decir, el código de tipo de parte). Lo siguiente debe observarse: este campo es aditivo ya que sólo especifica las partes que se pueden añadir a una tarea. Si una parte determinada especificada dentro de este campo ya tiene acceso a esta tarea, entonces no se realiza ninguna acción. Si una parte del tipo especificado en este campo no existe en la carpeta, entonces no se realiza ninguna acción. Si una parte recibe acceso a esta tarea, el sistema crea un SATaskParty para enlazar la parte a la tarea. Para la subrogación, se definen los siguientes códigos de tipo de partes: D, R y A. > Oí O Oí Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 Nombre Tipo de Longitud Dígitos Nulos Requerido Descripción datos decimales taskPartyType Cadena 1 N R El tipo de parte de la parte cuya variable de estado (contenida en SATaskParty) se ve afectada. taskType Cadena 32 N R El tipo de tarea. Los tipos de tares válidas para la subrogación son: Demanda Arbitraje Litigio workflowBarRootClass Cadena 64 Y 0 Se usa para el control de la navegación si se especifica este campo e indica que un botón (para esta función) debe mostrarse en la barra de flujo de trabajo (barra de acción) para cualquier forma cuyo objeto raíz corresponda a la clase especificada en esta entrada de flujo de trabajo.

M Ü1 O üi Número de etiqueta de correo expreso: EL434959764US Número de caso: 208537.0004 Relaciones Nombre Tipo de Campos de relación Requerido Descripción relación (origen/ destino) toNextStateEventTemplate 1-1 SAEventTemplate 0 Si se especifica, SAEventTemplate, esto se usa para crear un "evento" específico para la aplicación que representa el cambio de estado que se está llevando a cabo. Este caso se usa típicamente para crear un evento que activa una función en segundo plano. Para las entradas de flujo de trabajo incondicionales, esto típicamente puede realizarse usando "un evento de término" que se define en SAIntrinsicFunction. Para el flujo de trabajo condicional (en donde una fusión de segundo plano necesita activarse de manera condicional, debe especificarse esta relación). NOTA: el administrador de flujo de trabajo siempre crea un evento "genérico" que registra el estado de flujo de trabajo de la carpeta antes y después de que el flujo de trabajo se evalúe. Este evento es un evento "detallado" y se puede usar para depurar los problemas de flujo de trabajo (no para activar funciones en segundo plano). 187 Diagrama 4 - Ejemplo de una tabla de flujo de trabajo -Subrogación de seguros A continuación se muestra un pequeño subconjunto de filas de una tabla de flujo de trabajo que se usa dentro de la aplicación Siteras Insurance Subrogation. KovNU-ifibar - 34i 1. SiL oIder-_Subrc 2. TaskType: Desajid 3. Stage: Init 4. TaskPartyType: Deinander(D) 5. Pa tyState; IniC 6. ActionFarty; D 7. Functionx Dea*.andD_Cre3teElectronío 8. OperationCode : B 9. PreConcitionQuali fier: 10. PostConditionQuaiifier: Da aconéete 11. Nextstage : Preparación 12. NextPartyState: Fending Issuance 13. MextActionParty: D 14. TaskPartyArray; D HowNumbor - SOS 1. .FOiderType: SAFolder_Subro 2. TasJc ype: Demand 3. Stage: Hegotiation 4. TaskParfcy yp : CamanderíD) PartyState: Counter OffGr Approved e. ActionParty: D 7. Functinn: D_s-índD_Arbitrate 8. OperationCode: N S. PreConditionQuali fier: RGsporidarlsArbitrationMenber 10. PostCojidi tionQualiíier: 11. NexcStage: 12. NextPartyState: 13. N'ex AccionFarCyj 14. TaskPartyA-rray: -saba - SOS 1. Folder^ype= SAFolder„Subro 2. T s¾T pe; Demaná 3. Stage: Wegotiaticn 4. TaskPartyType: Deroander (D) s. PartyState : Counter Ofíer Approved 6. ActionParty; D 7. Functicn: Dena.noD_Inquiry 8. OperationCode: B 9. PreConcitionQualifíer: 10. FostConditionüualifier: 11. Kextstage: 12. NexfcPartySfcate: 13. KextActionParty: 7 14. TaskPartyArra : 1. FolderType : SAFoláer_Subro 2. TaskTyps: Dems-id 3. Stage: Negociación 4. TaskPartyType: DenanderíD) 5. PartyState: Demond Issced 6. ftctionParty; D 7. Ptuactior,: Deir.andD_Approve 8. OperationCode: S S. PreConditiosQualifier: 10. Postconáitionoualifier: 11. tíextstage: 12. NextPartyState: Counter Otíer ?.pproved 13. NextActionParty: R 188 14. TaskPartyArx-ay: HowiíiBbsr - 936 1. FolderType: SAFolder_5ubro 2- TaskType: Deroand 3- Stage: Negotiation ¾ . TaskParfcyType: Responde tR) 5- PartyState: Counter Offer Issued e. ActionParty: D 7. Function: Demanc-0_Approve 8. GperationCode: B s. FreConditionQualifier: 10- PostConditionQualifier : 11. NextStage: 12. NextPartyState.- Pending Response 13. Nex ActionParty: R 14- TasIcPartyArray: SteMNutnber - 51 1. FolderType: SAFolder_Subro 2. TaskType: Arbitration 3. Stage: Jssued 4. TaskPartyType : Demander(D) 5. PartyState: Xr.it 6. ActionPsxty: ? 7. Function: Dewand3_Arbitrate S. OparationCode: S g. PreConditionQualifie : 10. PostConditionQualifier : U. SextSCage: ArbiUra on 12. NextParfcyState: Freparing For Arbitratíon 13. NextActionParty: D 1-3. TaskPa yArray: DR ANTECEDENTES - Procesamiento de Transacción Entre Organizaciones Durante la década de los 80 y 90, muchos sistemas de procesamiento de transacciones comerciales se enfocaron en los procesos comerciales de integración y los datos que existían dentro de una organización (es decir, dentro de la organización). Estos sistemas cubren una amplia disposición de aplicaciones comerciales de diferente complejidad, incluyendo la programación/ transmisión de producción, el proceso de solicitudes, administración de recursos humanos, 189 contabilidad financiera, gerencia de ventas, etc. Ejemplos comerciales de dichos sistemas incluyen ofertas de SAP, Oracle y PeopleSoft. Las organizaciones que implementaron satisfactoriamente dichos sistemas lograron costos reducidos, una mayor eficiencia y presentaron una mejor competitividad. Ahora con los sistemas dentro de la organización, estas organizaciones buscan integrar los procesos comerciales y los datos que existen entre las organizaciones de socios comerciales (es decir, entre las organizaciones). Entre 1999 y 2000, surgieron diversos intercambios entre comercios ("B2B exchange"). Estos mercados virtuales demostraron el enorme valor de integrar los procesos y los datos comerciales entre las diferentes organizaciones. Infortunadamente, este movimiento en la tecnología falló debido a una falla fundamental en el concepto de intercambio, a saber, que mientras estos intercambios fueran buenos comprados (debido a los buenos precios reducidos para comprar bienes), los mismos intercambios no eran buenos para los proveedores, ya que hubo una presión en la baja de los precios debido a una competencia cada vez mayor. El mercado resultante tenía muchos compradores, pero no proveedores. De esta manera, el mercado se colapso. Aunque este movimiento inicial entre comercios falló, claramente demostró que la reducción de costos sustancial y una mayor eficiencia se pueden lograr con sistemas que 190 automaticen el procesamiento de transacciones entre socios comerciales (es decir, procesos de transacciones entre organizaciones). Requerimientos v retos Esta sección proporciona una descripción general de los requerimientos de un sistema de procesamiento de transacciones entre organizaciones. Red de procesamiento central A diferencia del procesamiento de las transacciones entre organizaciones (en donde el sistema de procesamiento de transacciones se puede implementar directamente dentro de una organización determinada), el procesamiento de transacciones entre organizaciones requiere que la información fluya a través de una central o una red centralizada (ya sea de manera explícita o lógica). Para un mercado vertical determinado, esta red central se implementa de mejor manera a través de una sola organización de tercera parte neutra (es decir, una cámara de compensación). Esto facilita una amplia participación dentro de una red vertical determinada al eliminar cualesquiera asuntos relacionados con la privacidad/ propiedad de los datos que se pudieran presentar si la red se ejecutara por una de las organizaciones dominantes dentro del mercado vertical. Además, al conectarse a una comunidad de comercio a través de una red centralizada, se reduce enormemente el 191 número de conexiones necesarias cuando se compara en una red de punto a punto. Con una red centralizada, cada miembro mantiene sólo una sola conexión de la red (en lugar de mantener una conexión por socio comercial). Aislamiento de organizaciones miembro El valor de la red central se encuentra en su capacidad de aislar las organizaciones miembro de los detalles de implementación necesarios para conectarse a la red. En lugar de crear un conjunto común único de estándares al que todas las organizaciones miembro se deben adherir, la red central facilita la membresía permitiendo que cada organización miembro se comunique e integre con la red de una manera que le resulte mejor en cuanto a sus necesidades y capacidades para esa organización. Para hacerlo, la red debe aislar todas las organizaciones miembro junto con las siguientes dimensiones. Aislamiento de conectividad La red debe soportar una amplia variedad de capacidades de interfaz. Esto permite que las organizaciones miembro cuenten con capacidades técnicas diversas para interactuar con la red. Algunas organizaciones desearán hacer una interfaz con la red usando interfaces completamente automatizadas (mediante la comunicación de información de transacciones basadas en mensaje), mientras que otras organizaciones menos complicadas desearán 192 interactuar manualmente (usando una interfaz basada en la red informática). Esto facilita una amplia participación en la red y proporciona un aislamiento de la interfaz técnica. Aislamiento de contenido y formato de datos Al construir un aislamiento de conectividad descrito anteriormente, la red debe soportar una amplia variedad de formatos de datos mientras mantiene el significado y contenido de los datos de aplicación dentro del mercado vertical específico. Esto permite que los miembros envíen/ reciban elementos de datos asociados con cada transacción comercial en un formato que surge en su sistema local. Para soportar este requerimiento, la red necesita realizar traducciones semánticas y de formato. Esto reduce los requerimientos de integración además de incrementar la participación del miembro. En el centro de esta capacidad se encuentra la definición de un "modelo de datos unificado" que es específico para el mercado vertical. Este modelo de datos proporciona una base de datos objetivo única en donde se realizan todas las traducciones. De una manera más simple, los datos entrantes se transforman desde su formato específico de miembro al formato prescrito a través del modelo de datos unificado, el mismo proceso se realiza en reversa para una información de salida. 193 Aislamiento de procesos comerciales Los requerimientos anteriores permiten que los miembros 1) se conecten y 2) intercambien datos de una manera consistente. Tomando en cuenta esta capacidad, la red debe proveer una estructura común para realizar transacciones entre organizaciones (un flujo de trabajo entre organizaciones) aunque también aisla cada miembro de los procesos comerciales específicos y los flujos de trabajo que son únicos para sus organizaciones (flujo de trabajo dentro de la organización). Esta estructura de transacción común se especifica en un mercado vertical determinado y define un proceso comercial común que permite que todos los miembros se comuniquen de manera consistente sobre las transacciones en proceso en la red. Para obtener mayor información sobre esta capacidad, refiérase a la sección relacionada "administración del flujo de trabajo entre organizaciones". Además, este aislamiento también asegura un procesamiento consistente en cada transacción. En lugar de sólo pasar información de un miembro a otro, la red debe proveer un procesamiento específico para la aplicación requerida a través de un mercado vertical determinado. Por lo menos, este procesamiento debe mantener todos los datos relacionados con la transacción entre las organizaciones según se define dentro del modelo de datos unificado para 194 dicho mercado. Información estructurada y no estructurada La mayoría de los sistemas comerciales automatizados lidian con información estructurada en donde la estructura de la información se descompone en elementos de conjuntos de datos relacionados (atributos) que se agrupan en entidades de datos. En su momento, las entidades de datos se almacenan dentro de un sistema de administración de una base de datos. Aunque es necesario una información estructurada, muchas transacciones entre las organizaciones involucran información relacionada (documentos de soporte) que existe en un formato no estructurado (por ejemplo, imágenes, fotografías, audio, video, etc.). Debido a que la mayoría de las transacciones entre organizaciones actualmente suceden manualmente a través del correo y el fax, esta información relacionada usualmente pasa junto con cualquier información estructurada. La red debe poder proveer almacenamiento y recuperación para la información estructurada y para la información no estructurada. Y, con respecto a una información no estructurada, debe proveer un medio para permitir que todas las organizaciones miembro accedan a la información no estructurada sin incrementar sustancialmente la tecnología requerida para realizar dicho acceso (es decir, 195 sin que sea necesario mecanismos de acceso propietario para los tipos específicos de información no estructurada). Transacciones de varias partes y flujo de trabajo Aunque la mayoría de las transacciones entre comercios involucran a una parte principal y a una contraparte (por ejemplo, comprador/ proveedor, fabricante/ cliente, demandante/ demandado, etc.), el flujo de trabajo de la vida real consiste en un flujo de trabajo condicional complejo que involucra a varias partes. A diferencia de un sistema de procesamiento de transacciones dentro de la organización, este requerimiento de acceso a varias partes se refiere a todos los aspectos de las capacidades de procesamiento de las transacciones en la red y debe tener soporte. Cada uno de los siguientes subsistemas de procesamiento de transacciones debe contar para un acceso de varias partes en algún grado: procesamiento y evaluación de normas comerciales; estructura de organización de seguridad (ubicaciones); administración del flujo de trabajo; acceso a no miembros en el enrutamiento de una transacción; acceso al operador común; cierre y reservación de seguimiento de las transacciones (dentro y entre miembros); elaboración de informes; administración de documentos y notificaciones externas. 196 Privacidad y seguridad de los datos Finalmente, debido a que la red almacena información sobre cada una de las transacciones de los miembros, debe proveer una seguridad completa para asegurar que una organización determinada sólo puede acceder a las transacciones y a los elementos de datos relacionados a la que tiene permiso de acceder. Sistema de procesamiento de transacciones entre organizaciones El sistema de procesamiento de transacciones entre organizaciones consiste en una estructura de la aplicación diseñada para cubrir los requerimientos del procesamiento de una transacción entre organizaciones (mencionada anteriormente). Esta estructura no depende de un proceso comercial vertical específico ni ninguna aplicación y tiene una habilidad única para lidiar con transacciones de varias partes que se expande en diferentes organizaciones. Esta estructura opera dentro de una arquitectura de un sistema general que consiste en un número de servidores que funcionan de manera integrada. Esto se ilustra en la figura 26, arquitectura del sistema. El sistema de los programas y sistemas de programación que representa esta estructura de la aplicación se encuentra dentro del servidor de la aplicación. Este sistema consiste en cuatro áreas principales-subsistemas de 197 interfaz, nivel de procesamiento de transacciones (TPL), servicios de sistemas y lógica de aplicaciones. Esta estructura se ilustra en la figura 27, arquitectura de una estructura de aplicación. Cada una de estas áreas se describe con mayor detalle a continuación. Subsistemas de interfaz Las solicitudes de transacción pueden originarse de diferentes fuentes, por ejemplo, manualmente a través de una interfaz basada en la red, electrónicamente a través de una interfaz basada en mensajes, internamente como resultado de un procesamiento nativo, etc. El objetivo del subsistema de interfaz es dar soporte a los requerimientos de interfaz únicos de cualquier fuente determinada de origen de transacción. Debido a que las formas del origen de la transacción son nuevas/ únicas y evolucionan (por ejemplo, redes inalámbricas), el sistema puede soportar rápidamente nuevas transacciones a través de la creación de nuevos subsistemas de interfaz. El resultado final de cada subsistema es el mismo, a saber convertir la solicitud de la transacción en un formato de objeto interno (una gráfica objeto) e invocar los servicios deí TPL para procesar la solicitud de transacción. Esta estructura de procesamiento de transacción centralizado proporciona los siguientes beneficios principales; todas las solicitudes de transacción fluyen a través de un solo punto común dentro del 198 sistema, la validación de la seguridad se realiza para todas las solicitudes de transacción en un solo punto (es decir, no existe una manera de ejecutar una transacción dentro del sistema que evite la validación de la seguridad). Todos los procesamientos de transacciones se realizan de manera consistente. Un conjunto de servicios de procesamiento de transacciones comunes se realizan a través del TPL (de esta manera elimina la necesidad de que sean codificadas de manera explícita dentro de una lógica de la aplicación en cada transacción). Las siguientes secciones describen los subsistemas de interfaz que se proporcionan para dar soporte a los métodos comunes del origen de la transacción. Subsistema en línea (OLS) El subsistema en línea se usa para dar soporte a las transacciones que se originan manualmente a través de una interfaz basada en redes informáticas, orientadas hacia HTML. Este subsistema puede proveer soporte tanto a una interfaz de redes informáticas basada en servidor estándar como a una interfaz de red del subsistema Jview™. Subsistema de eventos El subsistema de eventos se usa para dar soporte a las transacciones que se originan como resultado de los procesamientos internos a través de una lógica de transacción de la aplicación. Estas solicitudes de transacción 199 se procesan en el segundo plano. Para obtener mayor información, refiérase a la sección "administración de eventos". Subsistema de correo El subsistema de correo se usa para dar soporte a las transacciones que se originan como resultado de la recepción de un mensaje de correo electrónico entrante. Este subsistema valida que el mensaje de correo electrónico entrante contiene un descriptor de seguridad válido y creará un evento que activa la solicitud de transacción para procesar los datos asociados con el mensaje de correo electrónico entrante. Subsistema de lote El subsistema de lote se usa para dar soporte a las transacciones que se originan como resultado de una programación definida previamente. Esta programación de lote se usa para definir solicitudes de transacciones "punto en el tiempo". Por ejemplo, este subsistema se usa para activar una solicitud de procesamiento que es para preparar un informe específico cada noche. Subsistema de traducción de mensajes El subsistema de traducción de mensajes está diseñado para comunicarse con otro sistema externo que usa interfaces electrónicas automatizadas. Este subsistema puede manejar mensajes electrónicos entrantes y salientes. Los mensajes 200 entrantes ocasionan la solicitud de las transacciones que se procesan a través del TPL. Los mensajes salientes se generan como respuesta a un evento específico procesado por el administrador de eventos. En general, este subsistema da soporte a mensajes asincronos (en lugar de mensajes síncronos) . Nivel de procesamiento de transacciones El nivel de procesamiento de transacciones es el responsable de procesar todas las solicitudes de transacciones. Para cada solicitud de transacción, este nivel utiliza los servicios del sistema para realizar lo siguiente: realizar una validación de seguridad de transacciones, bloquear la carpeta (si es necesario), realizar una validación de datos de entrada (sólo funciones de edición), recuperar objetos de la base de datos, invocar la validación relacionada con el modelo de datos de la aplicación (sólo funciones de edición), invocar validación relacionada con la transacción de la aplicación (sólo funciones de edición), crear eventos de seguimiento de auditoría (sólo funciones de edición), invocar al administrador de alertas para que evalúe las reglas comerciales de la aplicación y genere alertas (sólo funciones de edición), invocar al administrador del flujo de trabajo para que evalúe y establezca el estado del flujo de trabajo (sólo funciones de edición); guarda cualesquiera datos nuevos o modificados con la base de datos; y libera la carpeta (si es 201 necesario). Estos servicios se describen con mayor detalle a continuación en la sección "servicios del sistema". Lógica de aplicación Para cualquier mercado vertical determinado, las capacidades de procesamiento de transacción genérico del sistema se extienden con la lógica y configuración de la aplicación que se especifica en un mercado vertical determinado. Estas extensiones de aplicaciones son lo que proporcionan al sistema su foco de mercado vertical específico. Como resultado, el sistema de procesamiento de transacciones genéricas pueden dar servicio a cualquier número de mercados verticales. La lógica de la aplicación consiste en las siguientes partes principales. Modelo de datos unificados Mencionado anteriormente, este es el modelo de datos que definen las entidades y atributos que son específicas a un mercado vertical determinado. Lógica de aplicación, modelo relacionado Para cada entidad de datos específicos de la aplicación, la lógica de aplicación se puede definir con relación a la validación y procesamiento esto es específico a esta entidad. Lógica de aplicación- relacionada con la transacción Para cada transacción específica de la aplicación, la lógica de la aplicación se puede definir con relación a la 202 validación y procesamiento que se especifica para esta transacción. Configuración Muchos de los servicios de procesamiento de las transacciones genéricas se basan en la definición de la información de configuraciones externas. Esta configuración se define para cualquier mercado vertical (y permite que los servicios del sistema de procesamiento de la transacción genérica sean personalizados para las necesidades específicas del mercado vertical). Servicios del sistema Los diversos subsistemas y los niveles descritos anteriormente se basan en un conjunto enriquecido de servicios del sistema. Algunos de los servicios principales incluyen: bloqueo y reservación; servicios gráficos de objeto; administración de alertas y reglas comerciales; administración del flujo de trabajo; administración de la seguridad; propiedad individual y de equipo; notificaciones externas; servicios instantáneos; elaboración de informes y administración de documentos. Estos servicios se describen detalladamente dentro de la sección de procesamiento de servicios del sistema a continuación. Técnica anterior - reconocimiento Esta estructura de la aplicación se basa en servicios de las siguientes tecnologías y reconoce cualquier técnica 203 anterior en estos dominios.

Esta estructura de la aplicación construye las capacidades establecidas por esta tecnología y proporciona servicios adicionales y capacidades específicamente dirigidas al procesamiento de transacciones entre organizaciones que no están resueltas. Esta estructura de un sistema de procesamiento de transacciones basado en redes informáticas general y el papel de la estructura de la aplicación dentro de esta estructura se ilustra en la figura 28. Esta estructura se relaciona cercanamente a la descripción anterior del subsistema Jview™ y la administración del flujo de trabajo entre administraciones. Ejemplo comercial La red de subrogación electrónica es un ejemplo comercial de un sistema operativo completo que representa los conceptos descritos en la presente específicamente para el mercado vertical del procesamiento de reclamaciones de 204 subrogación en la industria de los seguros. Terminología Esta sección contiene definiciones terminológicas que son útiles para la comprensión de los conceptos descritos en esta sección. Carpeta Cada transacción comercial diferente se representa a través de una carpeta. La carpeta se usa para contener de manera lógica toda la información relacionada con esta transacción (por ejemplo, partes, tareas, documentos, contactos, alertas, anexos, eventos, etc.). Parte Una transacción comercial involucra la interacción entre dos o más partes en donde, para propósitos de la transacción, cada parte desarrolla una relación específica (descrita a continuación). Con el flujo de trabajo dentro de la organización, las partes típicamente son unidades comerciales diferentes (por ejemplo, división, departamento, etc.) dentro de la misma organización en el flujo de trabajo entre organizaciones, las partes típicamente son organizaciones o individuos diferentes. Relación (tipo de parte) Para cada tipo específico de transacción comercial (carpeta), una o más relaciones se definen. Cada relación define el papel que una parte determinada realiza con 205 respecto a dicha transacción. Por ejemplo, en una transacción de administración de orden simple (carpeta de orden), una parte representa al "comprador" y otra parte representa al "proveedor". De esta manera, para cada parte definida en la carpeta esa relación de la parte con la transacción se denomina como subtipo de parte. Tareas Una tarea se usa para representar una actividad comercial independiente (relacionada con la transacción para esta carpeta). Cada carpeta debe tener al menos una tarea (su tarea principal). Con procesos comerciales complejos, las tareas múltiples se usan dentro de la carpeta para administrar y dar seguimiento a actividades múltiples paralelas relacionadas con una transacción comercial determinada. Por ejemplo, para una transacción de administración de orden (carpeta de orden), una tarea se define para el mismo orden, y las tareas adicionales se definen para cada envío/ factura diferente. Parte de acción Para cada tarea de la carpeta, la parte responsable de realizar la siguiente acción relacionada con esa actividad comercial se denomina la parte de acción. Cuando la transacción comercial se concluye, no hay mayor actividad comercial. En este punto, ninguna parte de acción existe en las tareas dentro de la carpeta. 206 Función Cada operación que se puede realizar en la carpeta, que afecta la información o estado de la carpeta, se denomina función, con base en la carpeta, ciertas funciones pueden realizarse a través de un tipo de parte específico, mientras otras pueden realizarse por algunos o todos los tipos de parte. En una transacción de administración de orden simple, algunos ejemplos de funciones incluyen: emitir una solicitud de compra (comprador), aceptar una solicitud inicial (proveedor), crear un envío/ factura (proveedor), etc. Dos tipos de funciones principales existen, las funciones de edición y las funciones que no son de edición. Las funciones de edición ocasionan la modificación de los datos comerciales dentro de la base de datos; las funciones que no son de edición no (es decir, las funciones de no edición esenciales sólo se usan para recuperar datos). Las definiciones de las funciones están contenidas dentro de las tablas de configuración del sistema. Cada definición de función contiene configuraciones que controlan el procesamiento de las solicitudes de transacción (por ejemplo, tipo de edición, tipo de parte, especificación de la gráfica objeto, etc.). La colección de las definiciones de función dentro del sistema son específicas de un mercado vertical determinado y esencialmente definen las capacidades de procesamiento comercial del sistema. 207 Organización Dos entidades legales diferentes (por ejemplo, compañía) opuesto a unidades comerciales diferentes (de tamaño arbitrario) dentro de una sola entidad lega. Flujo de trabajo Un conjunto de operaciones comerciales y/o procesos definidos, activados por un evento comercial inicial (transacción comercial), que continúa en una secuencia u órgano específico y que termina en una conclusión o terminación de la transacción. Un flujo de trabajo simple sigue a un conjunto prescrito de operaciones en secuencia a la conclusión (ruta única). Un flujo de trabajo complejo contiene múltiples rutas condicionales, sólo una de las cuales se toma con base en las condiciones comerciales presentes en la transacción. Flujo de trabajo entre las organizaciones Un flujo de trabajo que existe entre dos organizaciones con el objetivo de realizar/ completar un proceso/ transacción comercial específico para dichas organizaciones. Especificación gráfica de objeto (OGS) Un conjunto de datos de configuración que define el conjunto de entidades de datos y atributos y su estructura objeto, se usa para una solicitud de transacción determina (es decir, función), el TPL usa el OGS para asegurar que una parte determinada sólo puede enviar o recibir elementos de 208 datos permitidos para su tipo de parte. Adicionalmente, este mecanismo también se puede usar para restringir adicionalmente el acceso a los datos con base en el papel específico del usuario (dentro de un tipo de parte). Papel Un conjunto de datos de configuración que define un grupo de funciones. El conjunto resultante de funciones entonces se puede asociar con un operador o sistema automatizado. Los servicios de administración de seguridad usan ia definición del papel para limitar las funciones que se pueden realizar a través de un operador o sistema determinado. DESCRIPCIÓN DETALLADA - Procesamiento de transacciones entre organizaciones El sistema de procesamiento de transacciones entre organizaciones (referido a partir de ahora como la estructura de la aplicación o solamente A/ F) consiste en una estructura de aplicación diseñada para cubrir los requerimientos del procesamiento de transacciones entre organizaciones (mencionado en párrafos anteriores). Esta estructura no depende de ningún proceso o aplicación comercial vertical específico y es único en su capacidad de lidiar con transacciones de múltiples partes que expanden en diferentes organizaciones. Esta sección contiene procesos detallados y 209 descripciones de componentes relacionadas con la A/ F. Este análisis presume una familiaridad con los siguientes conceptos y tecnologías: Conceptos de procesamiento de transacciones orientados al comercio en general; diseño y programación orientados al objeto; elementos fundamentales básicos de Internet. La A/ F descrita en esta sección se ha validado con los siguientes contextos de aplicación comercial vertical: Seguros - reclamaciones de subrogación (demandas, contrademandas, presentación de arbitraje, etc.); manufactura - procesamiento de solicitudes (solicitud de compra, envío, facturación, devoluciones, etc.); venta al menudeo - administración de la tienda (programación de trabajo, mantenimiento de empleados, seguimiento de reloj checador, etc.); y general - registro de llamadas y administración de problemas. Descripción general Modelo v estructuras del objeto central La A/ F incluye un modelo de objeto central que proporciona un conjunto de clases fundamentales y entidades de datos que se usan para construir aplicaciones. Los objetos centrados dentro de este modelo típicamente se usan en la mayoría de las aplicaciones. Objetos adicionales, específicos 210 a la A/ F, permiten que el sistema realice sus operaciones de control dentro del contexto de procesamiento de transacciones entre organizaciones. Cuando se construye una aplicación, estos objetos se pueden usar como son o se pueden subclasificar para dar soporte a extensiones específicas de la aplicación. Los objetos dentro del modelo de objeto central se pueden agrupar en tres categorías principales - objetos de transacción, objetos de configuración y objetos del sistema. Los objetos de transacción representan las estructuras de control de la aplicación o de la transacción dentro de las transacciones comerciales que se procesan en el sistema. Los objetos de configuración representan las estructuras de configuración usadas por el A/ F en el tiempo de ejecución, esto define las características de procesamiento específicas de cada aplicación vertical. Los objetos del sistema representan estructuras del sistema internos que se usan para controlar la operación interna del sistema. 211 O bjetos de tra nsacció n Nombre de entidad/ clase Resumen SAFolder Abstracto. El contenedor genérico para todos los datos relacionados con una transacción determinada. SAFolderData Abstracto. Esta clase se usa para dar soporte a las extensiones específicas de una aplicación en una carpeta. SAParty La organización o individuo involucrado en una transacción determinada. SADocument Abstracto. Un conjunto de elementos de datos estructurados relacionados con una transacción.

SAAttachment Abstracto. Un conjunto de metadatos relacionados sobre un conjunto de datos no estructurados (véase SAAttachmentData). SAAttachmentData Un conjunto de datos no estructurados relacionados con una transacción (por ejemplo gráficos, fotos, etc.). SAComment Un comentario de forma libre relacionado con un documento dentro de una transacción. SAContact Un conjunto de nombre y/o información de dirección relacionada con un contacto dentro de una transacción. SADocContact Un objeto de relación que conecta un documento con un contacto. SAAIert Una condición comercial que existe con una transacción determinada. SAEvent Información de auditoría que provee un registro para cada modificación en el contenido de las carpetas. SASnapshot Un glóbulo objeto binario grande (BLOB) de información que contiene un conjunto completo de información de la carpeta en un momento determinado (es decir, una fotografía instantánea). Este objeto se usa para mantener un registro histórico de todas las modificaciones de los datos en la carpeta. SATask Una actividad comercial que ocurre dentro de la carpeta. 212 O bjetos de co nfig u ración Nombre de entidad/ clase Resumen SAFunction Una función de la aplicación (transacción) que está soportada por el sistema (externo). SAIntrinsicFunction Una función de la aplicación (transacción) que está soportada por el sistema (interno). SAIntrinsic Una función de procesamiento de transacción primitivo (intrínseco) soportado dentro de las clases de los programas y sistemas de programación de la aplicación. SACompany Una organización o individuo que puede participar en transacciones dentro de la aplicación vertical. SAGroup Dentro de una compañía, un grupo o equipo de individuos en una ubicación. SALocation Dentro de una compañía, una oficina o ubicación física.

SAOperator Dentro de una compañía, una persona (o contador) que tiene acceso al sistema. SARole Dentro de una compañía, un grupo de funciones de aplicaciones relacionadas que son necesarias para realizar un trabajo o función específica dentro de la compañía. SARoleFunction Se refiere a una función específica de un papel específico.

SAAIertRuleTemplate Una plantilla que define un tipo genérico de reglas comerciales que se pueden evaluar a través del sistema. SAAIertRule Una regla comercial que se usa para evaluar una condición comercial específica para una compañía específica. SADocContactTemplate Una plantilla que define un tipo genérico de contactos de un documento. SADomain Un conjunto de valores específicos de la aplicación que definen un dominio de la aplicación. SAEventTemplate Una plantilla que define las características de procesamiento para un evento. SAMessageTemplate Una plantilla que define las características de procesamiento para un mensaje. SANotificationRule Una regla del sistema que define las características de procesamiento que se usan para generar una notificación externa con base en un evento que sucede. SAObjectGraphSpec En una plantilla de transacción, las restricciones, las entidades de datos, y los atributos que se pueden intercambiar/ procesar dentro de una transacción determinada. SAWorkflow Una plantilla que se usa a través del administrador de flujo de trabajo para controlar el flujo de trabajo de una carpeta de transacciones. SAWorkflowRule Una regla de flujo de trabajo específico de la compañía que es usada por el administrador del flujo de trabajo para realizar un flujo de trabajo dentro de la compañía. SAWorkfiowRuleTemplate Una plantilla que define una función de flujo de trabajo específica de la compañía genérica que se puede realizar a través del administrador del flujo de trabajo. 213 Objetos del sistema Carpetas v documentos Dentro de la A/ F, la carpeta es un concepto clave. Un ejemplo de un objeto de carpeta existe para cada transacción de aplicación diferente dentro del sistema. Se soportan diferentes tipos de transacciones mediante diferentes tipos de carpetas. Se proporciona una clase de carpeta genérica (SAFolder) se proporciona a través de la estructura de la aplicación. Esta clase abstracta contiene todos los elementos de datos y los métodos que se usan en la estructura para administrar de manera genérica la transacción. Las carpetas de aplicación específicas se crean a través de una subclasificación desde su clase de raíz. De esta manera, cualquier número de carpetas específicas de la aplicación se 214 pueden crear (una para cada tipo de transacción de aplicación). La carpeta es un contenedor lógico para las siguientes colecciones de datos relacionadas con la transacción: Partes - en donde una parte es una organización o individuo involucrado a la transacción; documentos - en donde un documento es un conjunto de datos estructurado; anexos - en donde un anexo es un conjunto de datos no estructurados; eventos - en donde un evento es un registro de auditoría de cualesquiera modificaciones de datos en la transacción; alertas - en donde una alerta es una condición comercial que existe dentro de la transacción; contactos - en donde un contacto es el nombre y/o la información de dirección relacionada con un individuo u organización relacionada con este documento; y tareas - en donde una tarea es una actividad comercial que sucede dentro de la transacción. Para cada carpeta, la A/ F puede proveer un número de servicios comunes. Estos servicios están soportados a través de cada carpeta declarada en la subclase específica de la aplicación que define la carpeta específica. Los siguientes servicios de carpeta están soportados genéricamente a través 215 de la A/ F: soporte de partes múltiples, soporte de flujo de trabajo, bloqueo y reservación, administración de alertas, administración de eventos, notificaciones externas, administración de documentos (tanto para documentos estructurados como no estructurados), y administración de contactos. Además de la carpeta, un documento es otro concepto clave dentro de la A/ F. Dentro de una carpeta, un conjunto relacionado de información comercial se representa a través del documento (por ejemplo, dentro de un contexto de manufactura, una carpeta de solicitud contiene los documentos siguientes, una solicitud de compra, avisos de envío, facturas y notas crediticias). Se proporciona una clase de documento genérico (SADocument) a través de la estructura de la aplicación. Esta clase abstracta contiene todos los elementos de datos y métodos usados a través de la estructura para manejar de manera genérica un documento determinado dentro de una transacción. Se crean los documentos de la aplicación específica a través de la subclasificación de esta clase de raíz. De esta manera, cualquier número de documentos específicos de la aplicación se pueden crear. El documento también es un contenedor lógico para las siguientes colecciones de datos relacionadas con el documento: DocContacts, en donde un contacto de documento 216 conecta ese documento con un contacto específico dentro de la carpeta, y Comments, en donde un comentario es una nota de forma libre relacionada con este documento. Arquitectura de la estructura de la aplicación La estructura de la aplicación consiste en una arquitectura en niveles (como se ilustra en la figura 27). Esta arquitectura consiste en los siguientes niveles: un nivel del subsistema de interfaz, un nivel de procesamiento de transacción (TPL), un nivel lógico de aplicación y servicios del sistema. El procesamiento con cada uno de estos niveles es diferente como se describe a continuación. Procesamiento del subsistema de interfaz Dentro de la A/ F el nivel de sistema de interfaz es el responsable de intercambiar las solicitudes de transacciones y sus respuestas con el entorno externo (usuales interactivos, otros sistemas automatizados, redes de mensajería electrónica, etc.). Al hacerlo, esencialmente realiza una función de control de funciones dentro de la arquitectura (es decir, administrar una sesión de procesamiento de transacciones con cada entorno externo diferente). Este nivel consiste en los siguientes subsistemas diferenciados: subsistemas en línea (OLS), subsistema de eventos, subsistema de correo y subsistema de traducción de mensajes. 217 Subsistema en línea Los procesos del subsistema en línea todos solicitan/ responden a los usuarios interactivos basados en la red informática. El OLS está diseñado para trabajar con el subsistema Jview™ (dentro del buscador) pero también puede soportar la generación de HTML basados en servidores a través del subsistema HTTP. En cualquier caso, el mensaje de transacción (STM) se usa como el formato de solicitud/ respuesta para el OLS. El OLS consiste en uno o más ejemplos de procesos (que se ejecutan en uno o más servidores de aplicación). Cada ejemplo de proceso es capaz de manera solicitudes de HTTP. Cuando una instancia de proceso determinado crea una sesión para un usuario determinado, todas las solicitudes para dicha sesión se procesan a través de un ejemplo de proceso. A continuación se describe el procesamiento principal realizado dentro del subsistema. Establecimiento de una sesión de OLS (procesamiento de entrada al sistema) Antes de poder procesar cualquier transacción, un usuario debe primero establecer una sesión con el OLS. Entonces se envía una solicitud de entrada al sistema inicial. El OLS responde con una forma de ingreso al sistema (HTML). El usuario entonces introduce su identificación de compañía, identificación de usuario y contraseña y lo 218 presenta a esta solicitud de entrada al sistema. Si se indica una seguridad en la subred de IP, con base en la identificación de la compañía y la dirección de IP de la solicitud entrante, el sistema valida la subred IP para esta solicitud. Si la subred IP es válida, el sistema valida el identificador del usuario y su contraseña para este usuario específico dentro de la compañía específica. Si el usuario es válido, se crea una sesión de OLS. Esta sesión se usa para mantener un contexto sobre el estado actual de las interacciones del usuario con el sistema. Por defecto, se crea siempre una subsesión cuando se crea una nueva sesión. La subsesión representa un canal de comunicaciones para realizar una sola solicitud de transacción en un momento (se pueden realizar múltiples solicitudes de transacción en paralelo usando múltiples subsesiones). Después de crear la sesión, OLS crea una instancia del administrador de transacción (SCTranMgr). Este objeto se usa para controlar globalmente todo el procesamiento de transacciones que sucede dentro de la sesión. Este es uno de los objetos principales que representan el TPL. Dentro de la subsesión, se crea una pila. La pila se usa para dar seguimiento a las solicitudes de transacciones relacionadas que se producen de manera anidada. La operación de la pila se describe posteriormente. Con base en el perfil del usuario se realiza una transacción inicial (predeterminada) al crear 219 una entrada de pila e invocar el nivel de procesamiento de transacción (TPL). Este proceso se describe con mayor detalle a continuación. Los resultados de esta transacción inicial entonces se envían al usuario como respuesta a su solicitud de entrada al sistema. Procesamiento de una solicitud de transacción Una vez que se establece una sesión OLS, las solicitudes/ respuestas de transacción se pueden procesar. Se recibe una solicitud de transacción a través del OLS como una solicitud estándar de HTTP (obtener o publicar). Dentro de esta solicitud HTTP una FORMA o CONSULTA variable contiene el mensaje de solicitud de transacción en la forma de un mensaje de transacción (STM). Como en el XML, el STM representa el flujo de objeto adelgazado (es decir, un flujo en serie) que consiste en una estructura jerárquica de pares clavervalor (en donde cada nodo en la jerarquía representa un objeto). El STM consiste en dos secciones principales - objeto de encabezado de STM y comerciales. El OLS convierte el STM en un formato de objeto usando una clase de objeto genérica (SCObjectGraph)-denominada OG. Si se indica la seguridad en la subred de IP, con base en el identificador de compañía y la dirección de IP de la solicitud entrante, el sistema valida la subred IP para esta solicitud. Una vez en el formato del objeto, el OLS inspecciona los atributos de la solicitud de transacción contenidas en el 220 encabezado. Estas solicitudes de transacción pueden ser comandos de OLS o solicitudes de función de la aplicación. Los comandos OLS se usan para realizar operaciones de control de pila y de cesiones para la sesión actual. Las solicitudes de la función de la aplicación se usan para ejecutar funciones de aplicación. Dentro del encabezado de la solicitud, el tipo de cadena se usa para controlar la pila dentro de la sesión. Para las solicitudes de funciones, este tipo de cadena puede ser CHAIN__TOP (es decir retira todas las entradas de pila y crea una nueva entrada de pila inicial) o CHAIN_NEXT (es decir, crea una nueva entrada de pila en la pila). Con base en el tipo de cadena, una nueva entrada de pila se crea. Esta estructura de datos se usa para anclar otros objetos relacionados a estas solicitudes de transacción. Con base en la función (código de solicitud de transacciones) contenidas en el encabezado, un objeto de transacción (SCTran) se crea al invocar el método CreateTransactionO para crear una transacción del TranMgr (creado en la sesión). El nombre de la función pasa como un parámetro a esta solicitud y se valida a través del TranMgr (este proceso de validación se describe posteriormente). La instancia de este objeto se ancla en la entrada de la pila para esta solicitud. Al crear el objeto de transacción, se crea una instancia para una transacción específica de la aplicación. Cada clase de transacción de la aplicación se subclasifica 221 desde un SCTran. Cada función se relaciona con una clase de transacción de aplicación específica. De esta manera, cuando se invoca un método CreateTransactionQ crea la instancia de la clase de transacción específica de la aplicación con base en la función basada en el método. Después de crear el objeto SCTran, el OLS establece varios atributos dentro de este objeto que controlan el procesamiento de esta solicitud (por ejemplo, OG, parámetros de consulta, parámetros de transacción, etc.). El TPL procesa dos tipos principales de funciones (transacciones), de edición y de no edición. Las funciones de no edición son de sólo lectura (es decir, indagación) que únicamente devuelve información. Las funciones de edición dan como resultado la modificación de datos dentro de la base de datos. La ejecución de una solicitud dada se determina a través de las subfunciones a continuación (pasa al TPL a través del OLS)-preparar, validar y comprometer. Las funciones de no edición sólo soportan la subfunción "preparar". Las funciones de edición soportan las subfunciones. Dentro de la pila, el OLS mantiene el estado de subfunción de una función determinada (principalmente para funciones de edición). Una máquina de estado finito se usa para controlar las transiciones válidas desde las cuales se pueden solicitar las subfunciones en cualquier momento dentro de la ejecución de una solicitud. Para las funciones que no son de edición, se produce 222 lo siguiente. La función se ejecuta al invocar el método ExecuteQ del objeto de transacción que especifica la subfunción (preparar). Con base en la subfunción preparar, el TPL invoca el método prepare() del objeto de transacción de la aplicación para procesar esta solicitud (es decir recuperar los objetos para esta solicitud). El TPL devuelve un OG de salida que contiene los objetos que se han recuperado para esta solicitud. El OLS convierte este OG en un STM usando este STM, el OLS genera una respuesta del HTTP en la solicitud inicial HTTP. Para las funciones de edición, se produce lo siguiente (el procesamiento completo de una función de edición típicamente involucra varias interacciones con un usuario). La función inicialmente se ejecuta al invocar el método Execute() del objeto de transacción que especifica la subfunción (preparar). Con base en la subfunción de preparar, el TPL invoca el método prepare() del objeto de transacción de la aplicación para procesar esta solicitud. Si esta función requiere la entrada de un usuario, este método analiza cualesquiera objetos comerciales requeridos para esta transacción y el TPL devuelve un OG de salida que contiene estos objetos iniciales para esta solicitud. Si esta función no requiere la entrada de un usuario, el procesamiento continúa con el paso 8.g. El OLS convierte estos OG en un STM. Al usar este STM, el OLS genera una respuesta de HTTP a la 223 solicitud inicial de HTTP. Con base en la respuesta del sistema el usuario puede hacer cualesquiera modificaciones a los datos (según lo admita la forma) y presenta estos datos modificados al servidor. El OLS recibe esta nueva solicitud. Con base en el tipo de cadena (CHAIN_CONTINUE) y la información de estado dentro de la entrada de la pila existente, continúa el procesamiento de su función de edición. El procesamiento de esa función ahora continúa invocando el método Execute() del objeto de transacción especificando la subfunción "validar". Con base en la subfunción para validar, el TPL ahora invoca el método validate() del objeto de transacción de la aplicación para procesar esta solicitud. Este método realiza la validación y procesamiento de los datos específicos de la aplicación relacionados con la solicitud. Al terminar este procesamiento, todos los objetos comerciales se actualizan en la memoria y no se escriben aún en la base de datos. El TPL devuelve un OG de salida que contiene los objetos comerciales actualizados. Si la validación no es satisfactoria (es decir, se detectan errores), el OLS desecha el nuevo OG y devuelve la entrada de OG recibida anteriormente (recibida en el paso 8.e) al usuario con los errores asociados. En este punto, se permite que el usuario haga las modificaciones/ correcciones de los datos (si lo permite la forma). En este momento, el 224 procesamiento regresa al paso 8.d. La validación es satisfactoria (es decir, no hay errores), OLS convierte ese OG en un STL. Al usar este STM el OLS genera una respuesta de HTTP a la solicitud inicial HTTP. Esta respuesta permite que el usuario visualice, sin modificar, los datos y permite la confirmación de esta transacción. Con base en la respuesta del sistema, el usuario puede visualizar las transacciones propuestas y presentar su confirmación. El OLS decide esta nueva solicitud. Con base en el tipo de cadena (CHAI N_CO NTI N U E) y la información del estado dentro de la entrada de la fila existente, continúa el procesamiento de esta función de edición. El procesamiento de esta función sigue al invocar el método Execute() del objeto de transacción especificando la subfunción "asignar". Con base en la subfunción de asignar, el TPL ahora asigna cualquier objeto comercial actualizado a la base de datos. Al hacerlo se genera un mensaje de terminación. El TPL devuelve un OG de salida que contiene los objetos comerciales actualizados. Si la asignación es satisfactoria, el OLS guarda el mensaje de terminación para la transacción. Entonces se desecha la entrada de la pila actual (para la función de edición que se procesó) y se vuelve a ejecutar la función asociada con la entrada de la pila anterior. El TPL procesa esta función y devuelve un OG de salida que contiene los objetos comerciales para esta función, el OLS 225 convierte este OG junto con el mensaje de terminación desde la función de edición anterior, STL. Al usar este STM, el OLS genera una respuesta de HTTP a la solicitud inicial de HTTP. NOTA: Para cada solicitud de función de aplicación procesada y antes de generar cualquier respuesta de HTTP, el OLS invoca el método TransactionStatisticsQ del TranMgr. Al invocar este método, el OLS pasa los datos estadísticos de transacción para la función de aplicación anterior (los datos de tiempo de respuesta se devolvieron en el encabezado de la solicitud para la solicitud actual). Este método ocasiona que TranMgr actualice un objeto estadístico de memoria (para la sesión actual) con los nuevos datos de transacción. Esta información se actualiza en la base de datos cuando se termina la sesión. Establecimiento de una nueva subsesión con una sesión Una vez que se establece una sesión inicial, junto con la subsesión predeterminada se puede crear otra subsesión con el objetivo de ejecutar otra función de aplicación sin interrumpir la pila o las funciones de aplicación que existen dentro de cualquier otra subsesión existente. Se recibe una solicitud de transacción (STM) a través del OLS y se convierte en un formato de objeto. Dentro del encabezado, la solicitud de transacción es para un comando OLS (OLS_NewSubsession). El OLS entonces verifica el 226 identificador de sesión actual y el código de seguridad dentro del encabezado de la solicitud. Si es válido, se crea un nuevo objeto de subsesión y se añade a la lista de subsesiones para la sesión actual. Dentro de la nueva subsesión, se crea una pila. Con base en el perfil del usuario se realiza una transacción inicial (predeterminada) al crear una entrada de pila e invocar el nivel de procesamiento de transacción (TPL) (como se describió anteriormente). Os resultados de esta transacción inicial entonces se envían al usuario como respuesta a su solicitud para ingresar al sistema. NOTA: Dentro del buscador, cada nueva subsesión se presenta mediante una nueva ventana del buscador. Terminación de una sesión OLS (proceso de salida del sistema) Dentro del OLS, se termina una sesión cuando termina la última subsesión. Las subsesiones pueden terminar de manera explícita con una solicitud de "salida del sistema" o implícitamente después de un "tiempo fuera". Para las solicitudes para salir del sistema se produce la siguiente secuencia. El OLS recibe una solicitud de transacción (STM) y se convierte en un formato de objeto. Dentro del encabezado, la solicitud de transacción es para un comando OLS (OLS_Logoff). Con base en la subsesión para esta solicitud, el OLS: elimina la pila de la subsesión que se termina (eliminando de manera individual cada entrada de la 227 pila dentro de la pila); y elimina el objeto de la subsesión y lo elimina de la lista de subsesiones activas para la función. Si no existen más subsesiones activas para esta sesión, el OLS: invoca el método LogoffQ del objeto TranMgr asociado dentro de esta sesión (creada en la iniciación de la sesión). Este método ocasiona que el TranMgr registra los tiempos de respuesta y las estadísticas de la sesión, recolectadas durante esta sesión, dentro de la base de datos. Borra el objeto de sesión (de esta manera invalida cualesquiera solicitudes adicionales para esta sesión). Se envía un mensaje de salida del sistema satisfactorio al usuario como respuesta a su solicitud para salir del sistema.

Para los tiempos fuera, se produce la siguiente secuencia. Cuando el periodo de tiempo fuera para una subsesión expira se invoca el método TimeOut() del objeto de la sesión (especificando el identificador de la subsesión pertinente). Con base en la subsesión, el OLS: elimina la pila para la subsesión que está terminando (elimina de manera individual cada entrada de pila dentro de la pila); y elimina el objeto de la subsesión y lo retira de la lista de subsesiones activas para esta sesión. Si no existen más subsesiones activas para esta sesión, el OLS: invoca el método LogoffQ del objeto TranMgr asociado dentro de esta sesión (creado en un inicio de la sesión). Este método ocasiona que el TranMgr registre cualquier tiempo de respuesta y estadísticas de la 228 sesión, recolectadas dentro de esta sesión, dentro de la base de datos y elimina el objeto de la sesión (de esta manera invalida las solicitudes adicionales para esta sesión). Subsistema de eventos Al procesar cada solicitud de transacción a través del sistema, los eventos se escriben en la tabla de eventos dentro de la base de datos. La colección de eventos de una carpeta determinada forma el historial de la actividad comercial para dicha carpeta. El subsistema de eventos inspecciona los eventos que suceden dentro del sistema y permite que el sistema o la aplicación presente un procesamiento posterior específico para cada evento. Todos los eventos registrados en el sistema se procesan posteriormente a través del administrador de eventos. Para cada evento, este subsistema realiza lo siguiente. Determina si cualquier procesamiento posterior se define para este evento, si es así, activa la función específica para realizar este procesamiento (NOTA: Este procesamiento se realiza en segundo plano). Determina si se definen notificaciones externas para este evento, si es así, invoca al administrador de notificación externo para que procese las notificaciones externas. Para obtener mayor información, consulte la sección "notificaciones externas". Determina si se definen mensajes electrónicos salientes para este evento, y si es así, invoca al administrador de traducción de mensajes de 229 salida para que genere los mensajes electrónicos. Para obtener mayor información, consulte la sección "traducción de mensaje". Para cada evento, está contenida una definición de plantilla de evento en la configuración del sistema. Esta definición contiene configuraciones que controlan el procesamiento de este evento a través del administrador de eventos. Desde una perspectiva de partes múltiples, cada evento contiene información que define los tipos de parte que se permiten acceder a este evento. Esto permite que el sistema exponga y oculte varios eventos para partes específicas dentro de la carpeta con base en el tipo de evento. Esencialmente, los servicios de administración de eventos proporcionan un seguimiento de auditorías que mantienen el sistema sobre todas las modificaciones de datos que se producen dentro del sistema. Al centralizar este servicio, todas las modificaciones de datos que se producen dentro del sistema pueden inspeccionarse, y si es necesario, se puede invocar un procesamiento adicional. Un aspecto único de este servicio es la capacidad de manejo de múltiples partes. El subsistema de eventos consiste en dos componentes principales, el objeto SAEvent (y los métodos relacionados) y el administrador de eventos. Una transacción de aplicación 230 crea un evento al usar el método de clase CreateEventO de la clase SAEvent. El administrador de eventos consiste en uno o más procesos en segundo plano (que se ejecutan en uno o más servidores de aplicación) que recuperan los procesos no procesados desde la tabla de eventos y procesa cada evento de conformidad. Cuando se crea un evento el método CreateEventO usa la plantilla de eventos (para este evento) para determinar si debe producirse algún procesamiento posterior para este evento. Si no es así, se establece el atributo "procesado" en verdadero. Esta optimización evita que el proceso del administrador de eventos recupere este evento de la base de datos (es decir, sólo para descubrir que no necesita ningún procesamiento). A continuación se describe el procesamiento principal realizado dentro de este sistema. Administrador de eventos-in icialización Cada proceso del administrador de eventos realiza la siguiente secuencia de inicialización. Lee todos los valores de configuración (por ejemplo, el tiempo para desactivar cuando no se realiza ningún trabajo, etc.). Crea una instancia del objeto del administrador de transacción (SCTranMgr). Este objeto se usa para coordinar el procesamiento de las funciones de cualquier aplicación que se activan a través de la producción de eventos específicos. Crea una trenza de Java que continuamente "consulta" la base de datos buscando 231 eventos sin procesar. Completa la ¡nicialización necesaria para manejar las solicitudes de HTTP. Este proceso soporta la capacidad de recibir solicitudes de administración especiales para controlar el proceso (por ejemplo, apagarse). No soporta la capacidad de procesar solicitudes de la función de aplicación (similar al OLS anterior). Actualiza el registro del sistema con un mensaje de registro "¡nicialización de la administración de eventos". Administrador de eventos-ciclo de procesamiento de solicitudes El ciclo de procesamiento de solicitudes se produce continuamente dentro del administrador de eventos (hasta que termina). Durante el ciclo de procesamiento se realizan las siguientes operaciones. Busca si el administrador de eventos debe terminar, es decir, bTerminateEvMgr=True (como se establece a través de la solicitud de HTTP de administración). Se usa una consulta de SQL para obtener una sola carpeta de la base de datos con las siguientes condiciones. La carpeta no está bloqueada y no se ha detenido el procesamiento en segundo plano para esta carpeta y la carpeta contiene uno o más eventos sin procesar. Si no se devuelve en fila, entonces el proceso "se desactiva" durante n segundos (como se determina a través de la configuración). Al despertar, se repite el paso 1. Si se devuelve una fila de una carpeta, entonces continúe. Bloquee 232 la carpeta. Si la operación de bloqueo no es satisfactoria, entonces repita el paso 1. De otra manera, siga a continuación. Consulte la base de datos en busca de los eventos sin procesar para esta carpeta (clasificados en orden ascendente por fecha/ hora de ocurrencia). Seleccione la primera fila del conjunto de resultados para un mayor procesamiento. Si no se devuelve en fila, continúa con el paso 10. Obtenga la plantilla de eventos asociada con este evento. Esta plantilla indica si las siguientes operaciones deben realizarse; procesamiento de notificación externa, procesamiento de mensajes externos, procesamiento posterior de la aplicación. Si se indica un procesamiento de notificaciones externas, realice lo siguiente. Invoque el método GenerateNotifications() del administrador de notificaciones externas (ExtNotifMgr) pasando una referencia a este evento. El ExtNotifMgr consulta la base de datos para obtener todas las reglas de notificación externa para este tipo de eventos (con base en las partes involucradas). Si existen reglas específicas de la parte, dichas reglas exceden todas las otras reglas; de otra manera, se usan reglas genéricas. Si no existen reglas para este tipo de eventos, entonces no se realizan notificaciones externas. El ExtNotifMgr entonces procesa cada regla de notificación externa como sea necesario. Cada regla hace referencia a un contacto dentro 233 de la carpeta (con base en el tipo de contacto genérico). Si no existe contacto especificado dentro de la carpeta, entonces no se emiten notificaciones. Si el contacto existe dentro de la carpeta, entonces ExtNotifMgr recupera la información del contacto de este contacto específico para el método de notificación especificado en la regla de notificación (por ejemplo, correo electrónico, fax, buscador, etc.). si no existe tal información, entonces no se emite ninguna notificación. Si la información requerida para generar la notificación existe, entonces la notificación se emite. Si se indica un procesamiento de mensajes externos realice lo siguiente. Invoque el método GenerateMessages() del administrador de traducción de mensajes (MTMgr) pasando una referencia a este evento. El MTMgr consulta la base de datos para obtener todas las reglas de los mensajes externos para este tipo de eventos (con base en las partes involucradas). Si existen reglas especificas para esta parte, dichas reglas exceden a las otras reglas; de otra manera se usan las reglas genéricas. Si no existen reglas para este tipo de evento entonces no se generan mensajes externos. Para cada regla de mensaje externo se realiza lo siguiente. La regla de mensaje externo invoca al formateador de mensajes salientes para construir una estructura de XML que contiene los datos del mensaje saliente. La estructura del mensaje XML se escribe para la tabla de mensajes salientes 234 dentro de una base de datos separados para el servidor de integración. El servidor de integración recupera la estructura de los mensajes XML desde la tabla de mensajes salientes y lo convierte en un formato nativo como se indica a través del encabezado del mensaje. Este subsistema entonces utiliza el protocolo adecuado (por ejemplo, TCP/ IP, FTP, HTTP, SMTP, etc.) para comunicar este mensaje al sistema externo que recibirá este mensaje. Si se indica un procesamiento posterior a la aplicación revise lo siguiente. Obtenga la función que se ejecutará desde la plantilla de eventos para este evento. Invoque el método BGLogon() del objeto TranMgr para inicializar el contexto de procesamiento de transacciones para la compañía que creó el evento. Con base en la función (el código de solicitud de transacción) se crea un objeto de transacción (SCTran) al invocar el método Createtransaction() del TranMgr (creado durante la inicialización del administrador de eventos). Después de crear el objeto SCTran, el EventMgr establece varios atributos dentro de este objeto que controlan el procesamiento de esta solicitud. La función de la aplicación se ejecuta al invocar el método ExecuteQ del objeto de transacción especificando la subfunción de "asignar". Con base en la subfunción de asignar, el TPL realiza lo siguiente. Invoca el método prepareQ del objeto de 235 transacción de aplicación. Invoca el método validate() del objeto de transacción de aplicación. Invoca una llamada al EventMgr para permitir que se incluya las modificaciones de datos específicos en el administrador de eventos (por ejemplo, actualizar el indicador de proceso dentro del evento actual que está en proceso). Si no existen errores, invoca el método commit() del objeto de transacción de la aplicación. Esto ocasiona que todos los datos procesados durante la función se escriban en la base de datos. Si no se producen errores durante las llamadas de los métodos anteriores, el TPL regresa a un estado de "satisfactorio". De otra manera se devuelve un estado de "error" (para cualquier método en donde se detecte un error). Si se devuelve un estado de error, el administrador de eventos detiene los procesos en segundo plano para esta carpeta estableciendo un indicador adecuado en la carpeta y asignando este cambio a la base de datos. Si se devuelve a un estado satisfactorio entonces el administrador de eventos va al paso 5 y continúa con el procesamiento de los eventos no procesados remanentes para esta carpeta. Cuando no hay eventos sin procesar para esta carpeta se desbloquea la carpeta. Continúa con el ciclo de procesamiento al regresar al paso 1. NOTA: Una característica exclusiva del procesamiento de notificación externa y de mensajes externos es la 236 capacidad de enviar uno o más mensajes a cada parte definida en la carpeta. Esta capacidad se basa en la arquitectura entre organizaciones inherente dentro del sistema. Administrador de eventos-terminación El administrador de eventos continúa con su ciclo de procesamiento de solicitudes hasta que termina. El administrador de eventos puede terminar al dar por terminado un proceso de manera externa o a través de una solicitud del HTTP. Si se recibe una solicitud del HTTP para terminar el administrador de eventos esta solicitud establece la variable bTerminateEvMgr=True para que su valor sea verdadero. Al regresar al inicio de este ciclo de procesamiento normal el administrador de eventos comprueba esta variable y termina (de esta manera permite la terminación de cualquier procesamiento para una carpeta determinada). El administrador de eventos realiza las siguientes operaciones durante la terminación: elimina la instancia TranManager, actualiza el registro del sistema con un mensaje de registro "terminación del administrador de eventos", entonces realiza la terminación del proceso del administrador de eventos. Subsistema de correo (procesamiento de correo entrante) Este subsistema de correo está diseñado para procesar 237 los mensajes de correo entrantes. Cada mensaje de correo entrante contiene una línea de asunto especial y un cuerpo de mensaje (además de los archivos anexos) para permitir que el sistema determine el tipo de procesamiento que se requiere. El administrador de correo es el componente principal del subsistema de correo. Típicamente, existen dos instancias en el proceso del administrador de correo (que se ejecutan en diferentes servidores de aplicación dentro de la red), un proceso está activo y el otro está inactivo. A continuación se describe el procesamiento principal realizado dentro del subsistema. Administrador de correo-inicialización Cada proceso del administrador de correo realiza la siguiente secuencia de inicialización. Lee todos los valores de configuración (por ejemplo, números de segundos para inactivarse cuando no se realiza ningún trabajo, etc.). Crea una trenza de Java que continuamente "consulta" a los servidores de correo POP3 en busca de mensajes de correo entrantes. Completa la inicialización necesaria para manejar las solicitudes del HTTP. Este proceso da soporte a la capacidad de recibir solicitud de administración especiales para controlar los procesos (por ejemplo, apagarse). No soporta la capacidad de procesar solicitudes de la función de la aplicación (similar al OLS anterior). Actualiza el registro del sistema con un mensaje de registro "inicialización de la 238 administrador de correo". Administrador de correo-ciclo de procesamiento de correo entrante El ciclo de procesamiento de correo entrante se produce de manera continua dentro del administrador de correo (hasta que termina). Durante este ciclo de procesamiento, se realizan las siguientes operaciones. Se comprueba si debe terminar el administrador de correos, es decir bTerminateMailMgr=True (como se establece a través de la solicitud de HTTP de la administración). Bloquea el recurso MailManager (usando el administrador de bloqueo). Si la operación de bloqueo es satisfactoria, entonces continúe con el paso 3. De otra manera, el proceso "se desactivará" durante N segundos (según lo determina la configuración). Al activarse, regrese al paso 1. Este orden en serie sólo permite que un proceso del administrador de correos esté activo (es decir consultar el servidor de correo) en cualquier momento y evita que se detenga el procesamiento de un mensaje de correo ocasionado por un administrador de correos activo atascado o congelado por alguna razón. Los otros procesos continúan la consulta intentando adquirir el bloqueo (esencialmente permanecen inactivos hasta que adquieren el bloqueo). Este proceso actúa como un proceso fallido que se activa cuando falla o se atasca el proceso del administrador de correo 239 activo. NOTA: Cuando esta operación se realiza a través del proceso del administrador de correo activo funciona para "regenerar" el bloqueo. Al usar los valores de configuración obtenidos durante la inicialización, entre en el sistema de la primera cuenta de correos para el servidor de correo especificado POP3. Obtenga el siguiente mensaje de correo, si hay alguno, de la cuenta. Si no existen mensajes dentro de esta cuenta entonces siga en el paso 7. Cada mensaje de correo se procesa como se indica a continuación. Analiza el mensaje de correo en sus secciones principales (por ejemplo, asunto, cuerpo, anexo). Explora el cuerpo del mensaje buscando la sección codificada especialmente. Esta sección contiene 1) la carpeta que va a contener este mensaje de correo, 2) un número de secuencia exclusivo para este mensaje y 3) una referencia a la plantilla del evento que se usará para este mensaje. Los mensajes no válidos se almacenan temporalmente para su revisión, después se desechan. Para los mensajes válidos, la referencia de la carpeta y el número de secuencia se usan para consultar la base de datos e indagar si este mensaje (SAMailMessage) ya existe dentro del sistema. Si es así ya se ha procesado, continúe con el paso 5J a continuación). Bloquee la carpeta indicada por este mensaje de correo. Si la operación de bloqueo es 240 satisfactoria, entonces continúe con el paso 5E. De otra manera, salte este mensaje de correo regresando al paso 4 (este mensaje volverá a intentar de manera implícita en el siguiente ciclo). Cree una instancia de un objeto SAMailMessage que contiene los datos del nuevo mensaje de correo. Cree un evento (con base en la plantilla de eventos decodificada dentro del mensaje) para esta carpeta que hace referencia al objeto de mensaje de correo recién creado. Asigne estos objetos a la base de datos. Desbloquee la carpeta indicada por este mensaje de correo. Elimine este mensaje de correo de la cuenta de correo del servidor de correo POP3. Regrese al paso 4 para procesar cualquier mensaje de correo remanente en esta cuenta. Con base en la configuración, obtenga la siguiente cuenta de correo de la configuración. Regrese al paso 3 para procesar los mensajes de la nueva cuenta de correo. Cuando no hay más cuentas de correo pendientes continúe. En este punto, todos los mensajes de correo en todas las cuentas ya se han procesado. El proceso " se desactiva" durante N segundos (como se determine en la configuración). Al volver a activarse, continúa el ciclo de procesamiento regresando al paso 1. Administrador de correo-terminación El administrador de correo continúa en su ciclo de 241 procesamiento de solicitudes hasta que termina. El administrador de correo termina al dar por terminado el proceso de manera externa o por una solicitud del HTTP. Si se recibe una solicitud de HTTP para terminar el administrador de correo esta solicitud establece la variable bTerminate ail gr=True para que sea verdadera. Al regresar al inicio de este ciclo de procesamiento normal, el administrador de correo comprueba esta variable y la termina (de esta manera permite que se termine el procesamiento de mensajes de correo que estén en proceso actualmente). El administrador de correo realiza las siguientes operaciones durante la terminación: actualiza el registro del sistema con un mensaje de registro "terminación del administrador de correo" y realiza la terminación del proceso del administrador de correo. Subsistema de traducción de mensajes El subsistema de traducción de mensajes está diseñado para comunicarse con otros sistemas externos usando interfaces electrónicas automatizadas. Este subsistema puede manejar mensajes electrónicos salientes y entrantes. Los mensajes entrantes ocasionan solicitudes de transacciones que son procesadas a través del TPL. Los mensajes salientes se generan como respuesta a un evento específico procesado por el administrador de eventos. En general, este subsistema da soporte a mensajes asincronos (en lugar de mensajes 242 síncronos). Esencialmente, el sistema de traducción de mensajes se usa para procesar los mensajes electrónicos entrantes y salientes. Este servicio permite que una organización sofisticada tecnológicamente procese transacciones comerciales de una manera completamente automatizada, incluso cuando sus organizaciones de contraparte interactúan con una base manual (usando interfaces basadas en redes electrónicas). El subsistema de traducción de mensajes consiste en los siguientes componentes principales-servidores de integración, procesos de traducción de mensajes entrantes y servicios de traducción de mensajes salientes. El servidor de integración proporciona una interfaz directa con cada sistema externo manejando una variedad de protocolos de comunicación y formatos de datos requeridos por los sistemas. Al hacerlo, aisla el sistema completo de los detalles de la interfaz y proporciona un mecanismo de interfaz común para todos los mensajes electrónicos. Para mantener una alta disponibilidad, el servidor de integración hace interfaz con el sistema almacenando/ recuperando todos los mensajes del servidor de la base de datos en un formato XML. De esta manera, otras partes del sistema se pueden detener sin afectar la capacidad del sistema para recibir mensajes desde otro sistema. Dentro del sistema, el servidor 243 de integración es un componente estándar que está disponible comercialmente (por ejemplo, WebMethods, BizTalk). El componente de traducción de mensajes entrantes (IMT) maneja todos los mensajes electrónicos entrantes del servidor de integración (a través de la base de datos). Este componente consiste en una o más instancias de procesos (que se ejecutan en uno o más servidores de aplicación). Similar en estructura al administrador de eventos, estas instancias de proceso continuamente consultan la base de datos buscando nuevos mensajes entrantes para procesar. El componente de traducción de mensajes salientes (OMT) maneja todos los mensajes electrónicos salientes. Dichos mensajes se generan como respuesta a un evento (con base en las especificaciones dentro de la plantilla de eventos para dicho evento). Este componente es un servicio que es invocado dentro del contexto de un procesamiento de eventos realizado por un proceso del administrador de eventos. A continuación se describe el procesamiento principal realizado dentro de este sistema. Procesamiento de mensajes entrantes-descripción general Las siguientes operaciones se realizan durante el procesamiento de mensajes entrantes. Un sistema externo establece una conexión con el servidor de integración. Esta 244 conexión varía con base en el protocolo y la naturaleza de la interfaz específica. En general, esta conexión se puede usar para transmitir un archivo de transacciones, un conjunto de transacciones individuales o sólo una transacción. El servidor de integración recibe un mensaje electrónico desde un sistema externo sobre la conexión establecida. Con base en las reglas de correlación del mensaje contenidas dentro del servidor de integración este servidor convierte el mensaje electrónico entrante en un formato de STM (mensaje de transacción de Siteras) en una sintaxis de XML. Este mensaje se almacena como un objeto (SAInboundMessage) dentro de la tabla de mensajes entrantes dentro del servidor de la base de datos (base de datos del servidor de integración). El proceso de IMT procesa los mensajes entrantes que se han puesto en cola en la base de datos. La operación detallada del proceso IMT se describe en las siguientes secciones. Proceso IMT-inicialización Cada proceso de traducción de mensajes entrantes realiza la siguiente secuencia de inicialización. No todos los valores de configuración (por ejemplo, número de segundos para desactivar cuando no se realiza ningún trabajo, etc.). Crear una instancia del objeto del administrador de transacciones (SCTrarManager). Este objeto se usa para coordinar el procesamiento de las funciones de aplicación que se activan cuando llega un mensaje entrante. Crea una trenza 245 de Java que "consulta" continuamente la base de datos (la tabla de mensajes entrantes dentro de la base de datos del servidor de integración) buscando los mensajes entrantes. Completa las in icializaciones necesarias para manejar las solicitudes del HTTP. Este proceso soporta la capacidad de recibir solicitudes de administración especiales para controlar el proceso (por ejemplo, apagarse). No soporta la capacidad de procesar solicitudes de la función de aplicación (similar al OLS anterior). Actualizar el registro del sistema con un mensaje de registro "inicialización de la traducción de un mensaje entrante". Proceso IMT-ciclo de procesamiento de mensajes El ciclo de procesamiento de mensajes sucede de manera continua dentro del IMT (hasta que termina). Durante este ciclo de procesamiento se realizan las siguientes operaciones. Se comprueba si se terminará el IMT, es decir bTerminatelMT=True (como lo establece la solicitud de administración de HTTP). Consulta la base de datos y recupera los mensajes entrantes disponibles. Si no hay mensajes disponibles este proceso "se desactiva" durante N segundos (según se determina en su configuración). Al activarse el proceso reinicia en el paso 1. Si se recupera un mensaje, el procesamiento continúa. Con base en el identif icador de mensaje generado desde el servidor e integración, este proceso intenta bloquear este mensaje 246 usando el identificador de recurso "I BMsg_<msgid>". Este bloqueo garantiza que sólo una instancia de proceso IMT funciona en un mensaje determinado a la vez. Si el bloqueo no es satisfactorio (lo que significa que otro proceso de IMT ya está procesando este mensaje), el proceso reinicia en el paso 1 anterior. De otra manera, el bloqueo es satisfactorio y el procesamiento continúa. El IMT extrae este STM (mensaje XML) del objeto SAInboundMessage y lo convierte en un formato de objeto usando una clase de objeto genérico (SCObjectGraph, denominado como el OG). Una vez en el formato de objeto, el IMT extrae la función de los atributos de solicitud contenidos en el encabezado. Basado en la función (código de solicitud de transacción), un objeto de transacción (SCTran) se crea al invocar el método CreateTransaction( ) del TranMgr (creado durante la inicialización de IMT). Después de crear el objeto SCTran, el IMT establece varios atributos de este objeto que controla el procesamiento de esta solicitud. La función de la aplicación se ejecuta al invocar el método Execute( ) del objeto de transacción que especifica la subfunción de "asignar" (para funciones de edición). Con base en la subfunción del asignar, el TPL realiza lo siguiente. Invoca el método prepare( ) del objeto de transacción de la aplicación. Invoca el método validate( ) para hacer a validación del objeto de transacción de la 247 aplicación. Invoca una llamada de retorno al IMT para permitir que se incluya cualesquiera modificaciones de datos específicos del IMT (por ejemplo, la actualización del indicador procesado dentro del mensaje actual que se está procesando). Si no existen errores, invoca ei método commit( ) del objeto de transacción de la aplicación. Esto ocasiona que todos los datos procesados durante la función se escriban en la base de datos. El TPL devuelve un estado de resultados (ya sea "satisfactorio" o "ERROR"). Si se genera un mensaje de respuesta como resultado de esta transacción, entonces el mensaje de salida se puede activar desde el evento que se registra como el resultado del procesamiento de esta solicitud de transacción (como se describe a continuación en procesamiento de mensajes de salida). Si se devuelve un estado de error, el IMT detiene el procesamiento para este mensaje al establecer el indicador adecuado y asignar este cambio a la base de datos. Si se devuelve un estado satisfactorio, el IMT desbloquee el mensaje y continúa el ciclo de procesamiento regresando al paso 1. Procesamiento de mensajes de salida El procesamiento de mensajes de salida se produce como el resultado del procesamiento de eventos que realiza el administrador de eventos cuando la plantilla de eventos para este evento especifica "procesamiento de mensaje 248 externo". En este caso, se producen las siguientes operaciones. Si se indica "procesamiento de mensajes externo" a través de la plantilla de eventos para el evento actual, el administrador de eventos invoca el servicio de traducción de mensajes de salida (OMT) (pasando una referencia al evento). Al usar el identificador de plantillas de evento desde el evento, la OMT obtendrá las reglas de procesamiento para mensajes de salida para este evento. Al usar estas reglas, la OMT construye un OG de salida con base en el contenido del objeto evento actual. El OMT entonces invoca el método ConvertToXML( ) del objeto OG para producir un flujo de XML: la OMT crea un nuevo objeto de mensaje de salida (SAOutboundMessage) que contiene el STM de salida (en formato XML). El servidor de integración continuamente consulta la base de datos para los mensajes salientes. Cuando se recupera un mensaje saliente de la base de datos se convierte a un formato nativo (específico para el sistema de destino) con base en las reglas de correlación de mensajes contenidas dentro del servidor de integración. Si una conexión con el sistema externo no existe ya, el servidor de integración establece una conexión con el sistema externo. Esta conexión varía de conformidad con el protocolo y la naturaleza de la interfaz especifica. En general, esta conexión se puede usar para transmitir un archivo de 249 transacciones, un conjunto de transacciones individuales o una sola transacción. El servidor de integración entonces trasmite el mensaje nativo al sistema externo. Una vez transmitido, el servidor de integración continúa su ciclo de procesamiento de mensajes salientes al continuar con el paso 6. Procesamiento del nivel de procesamiento de transacción (TPL) El nivel de procesamiento de transacción es el centro de la A/ F y coordina el procesamiento de las transacciones de la aplicación dentro del sistema. Una parte clave de este procesamiento es la validación entre organizaciones que se produce para cada transacción. Además de las validaciones de la seguridad del operador y de la compañía básica realizada por la mayoría de los sistemas, esta validación compleja asegura que la organización se autoriza para realizar esta transacción junto con diversas dimensiones (por ejemplo, relación, estado del flujo de trabajo, etc.) Esta etapa consiste en dos componentes principales, los objetos del administrador de transacción (SCTran Manager) y objeto de transacción (SCTran). Conceptos de TPL Los conceptos y objetos específicos son muy importantes para la operación de TPL. Esta sección proporciona una descripción general de estos conceptos y 250 objetos. Intrínseco Cada función de aplicación se define a través de un conjunto relacionado de tres objetos. El objeto intrínseco se define primero. Este objeto representa una función de aplicación específica que tiene un código duro dentro de una clase de transacción de aplicación específica (es decir una función intrínseca). Una clase de transacción de aplicación puede soportar uno, o múltiples funciones intrínsecas. IntrinsicFunction Una vez que se definen un conjunto de objetos intrínsecos, se define un conjunto base de las funciones de aplicación usando objetos IntrinsicFunction. Cada objeto IntrinsicFunction define una función de aplicación diferente y hace referencia a un objeto intrínseco específico. Este objeto establece varios parámetros y valores que controlan el procesamiento de la transacción. Algunos de estos parámetros de pueden anular y/o restringir adicionalmente a través de las funciones especificas del cliente. Debido a que las funciones intrínsecas son inherentes a la aplicación, los motores de flujo de trabajo de la comunidad hacen referencia a estos objetos cuando la evaluación del estado del flujo de trabajo entre las organizaciones cambia. Función Una vez que se define el conjunto de objetos 251 IntrinsicFunction, se define un conjunto personalizado de funciones de la aplicación usando objetos de función. Cada objeto de función hace referencia a un objeto IntrinsicFunction. Al menos, se define un objeto de función, por defecto, para cada IntrinsicFunction. Adicionalmente, un objeto función permite la adición de funciones especificas de la organización, estas funciones pueden anular o extender el conjunto predeterminado de funciones. Esto permite que las organizaciones personalicen adicionalmente la operación de una función determinada para cubrir las necesidades específicas de su organización (dentro de las restricciones establecidas por la IntrinsicFunction relacionada). Por ejemplo, una función especifica de la organización se puede usar para visualizar una forma/ formulario diferente para el usuario (uno en donde los elementos de datos se han eliminado o tienen el valor por defecto, es decir están restringidos adicionalmente). Adicionalmente, con frecuencia se definen las funciones especificas de la organización para controlar el flujo de trabajo especifico de la organización (es decir, flujo de trabajo dentro de la organización). Cada transacción procesada por el TPL especifica un identificador de función. Este identificador identifica de manera exclusiva del objeto de función que contiene las especificaciones de procesamiento para esta transacción. Debido a que cada función esta relacionada con una función 252 intrínseca, y cada función intrínseca esta relacionada con un intrínseco, los atributos de todos los objetos proporcionan el vector completo de las especificaciones de procesamiento para esta transacción. En lugar de hacer referencia a cada uno de estos objetos de manera individual este conjunto de información simplemente hace referencia a un vector de función, función o función de aplicación. Especificaciones de la gráfica objeto (OGS) y jerarquía del objeto de transacción Los objetos comerciales almacenados dentro de la base de datos están relacionados con una estructura de red. Sin embargo, dentro del contexto de una transacción de una aplicación determinada existe una jerarquía de objeto de transacción diferente que establece una relación jerárquica entre los objetos comerciales involucrados en la transacción. El objeto comercial en la parte superior de esta jerarquía se denomina objeto de raíz. Dentro del A/ F la especificación de la gráfica objeto (OGS) proporciona la definición de la jerarquía del objeto para una transacción determinada. Se define un objeto OGS para cada función dentro del sistema. Cada función puede tener su propio objeto OGS diferente o múltiples funciones pueden compartir el mismo OGS. El OGS proporciona la estructura y los atributos del procesamiento para la transacción. Un objeto OGS base se 253 define para cada función intrínseca. Este OGS funciona para restringir el objeto función. Adicionalmente, se puede definir otro OGS en el objeto de la función, sin embargo, al hacerlos este OGS solo puede restringir el OGS heredado del objeto de la función intrínseca relacionada. Objeto del maneiador de transacción (SCTranManager) En la administración de transacción (Tran gr) representa un contexto de procesamiento de transacción, (o sesión) en donde una o mas transacciones se pueden ejecutar. El método Logon( ) de este objeto se usa para proveer información de contexto adicional especifica para una compañía determinada y un operador. A continuación se describe el procesamiento principal realizado dentro de este objeto. Procesamiento para entrar al sistema El procesamiento para entrar al sistema se produce Después de representar un objeto TranMgr. La representación del objeto realiza una pequeña inicialización en si misma. La inicialización principal del TranMgr se produce como respuesta a la invocación del método Logon( ) como se indica a continuación. Un subsistema de llamada representa un objeto TranMgr (clase SCTranMgr). El método Logon( ) del objeto TranMgr entonces se invoca. Existen varios gustos para este método (es decir una 254 entrada al sistema en línea, una entrada al sistema en segundo plano, etc.), pero todos pasan los siguientes parámetros clave para este método, identificador de la compañía, identificador del operador, dirección de IP y contraseña. Este método realiza lo siguiente. Al usar el identificador de compañía, recupera el objeto de compañía (SACompany) de la base de datos. Si no se encuentra, devuelve un error. Al usar el objeto de compañía y el identificador del operador (SAOperator) de la base de datos. Si no se encuentra, se devuelve un error. Al usar el objeto del operador y la contraseña se valida la contraseña usando el algoritmo MD5 (encriptación de un sentido). Si no es valido, devuelve un error. Para las entradas ala sistema en segundo plano no se proporciona una contraseña, ya que este es un proceso de entrada al sistema interno que usa el administrador de eventos. Adicionalmente , cuando los errores de entrada al sistema se detectan se realiza un procesamiento adicional para dar seguimiento al tipo de error, su frecuencia, etc. Con base en esta información, el sistema temporalmente o permanentemente deshabilita el procesamiento de entrada al sistema para el operador especifico Al usar el objeto operador, se obtiene el papel del operador. El papel define las funciones de la aplicación que este operador puede realizar (como se define a través de esta 255 compañía). AI usar el papel, el conjunto de objetos función del papel (SARoleFunction) se recupera de la base de datos y se coloca en una memoria intermedia dentro del Tran gr. Con base en los objetos devueltos de la base de datos (por ejemplo, compañía, operador, etc.), se establecen varios atributos dentro del TranMgr que representa un estado "conectado en el sistema". Se crea un nuevo o jeto estadístico (SAStatistics) y lo ancla dentro de este objeto TranMgr. Este objeto se usa para recolectar las sesiones y las estadísticas de transacción para cualesquiera transacciones asociadas con este TranMgr. Con base en una entrada al sistema satisfactoria, el subsistema de invocación continua con el procesamiento necesario después de la entrada al sistema para el subsistema (como se describe en la sección subsistema de interfaz). NOTA: El objeto TranMgr sólo representa una compañía / operador en un momento determinado. Sin embargo, este ejemplo de objeto puede volver a usarse en el sentido de que el método Logoff( ) reestablece este objeto en la preparación para otra entrada al sistema Procesamiento para salir del sistema El procesamiento para salir del sistema restablece un objeto TranMgr (que estaba conectado al sistema). Este procesamiento se activa al invocar el método Logoff( ) del objeto TranMgr. Al hacerlo se producen las siguientes 256 operaciones. Se crea un registro estadístico de sesiones (basado en el objeto de estadísticas actual para este administrador de transacciones). Se crea un registro de estadísticas de transacciones (con base en el objeto de estadísticas actual para este administrador de transacciones). Se asignan estos registros a la base de datos. Se reestablecen los atributos del Tran gr que representa el estado "conectado al sistema" Creación de un objeto de transacción Cada una de las funciones de aplicación ejecutada dentro del sistema requiere un objeto de transacción (SCTran). En lugar de representar este objeto de manera directa, este objeto se cera a través del TranMgr como resultado de la invocación del método CreateTransaction( ). Cuando se invoca este método, el subsistema de invocación pasa el identificador de función de la función de la aplicación (transacción) que se ejecutara. Dentro de este método, se producen las siguientes operaciones. El identificador de la función valida comparado con la lista en la memoria intermedia en los objetos de funciones del papel (es decir, si este operador tiene permiso de realizar esta función). Si no es válido, se devuelve un error. Con base en el identificador de función, el objeto de función (SAFunction) y los objetos relacionados (SAI ntrinsicFunction y SAIntrinsic) se recuperan de la base de datos. Si el tipo de 257 parte definido en el objeto o función no corresponde a unos de los tipos en la disposición Tran de los tipos de parte permitidas dentro del objeto de la compañía, entonces se devuelve un error. Cada función definida dentro del sistema tiene la intención de realizarse bajo una "relación" determinada (es decir, el tipo de parte). Esta variación asegura que la organización que realiza la transacción se permite que asuma esta relación. Al usar la clase de transacción definida en el objeto de función el administrador de transacciones crea una instancia del objeto de transacción especifico para la aplicación. Se devuelve una referencia a este objeto al que invoca. Objeto de transacción (SCTran) Todas las funciones de la aplicación que se ejecutan dentro del sistema requieren un objeto de transacción (SCTran). La clase SCTran es una clase abstracta y se subclasífica mediante cada clase de transacción de aplicación. De esta manera, al crear el objeto de transacción, una instancia de una transacción específica de la aplicación se crea. Se crea un objeto de transacción al invocar el método CreateTransaction( ) del objeto TranMgr. El identificador de la función pasa como un parámetro a esta solicitud y se valida a través del TranMgr (descrito anteriormente). Dentro de cada objeto de función se define una clase de transacción específica de la aplicación. De esta 258 manera, cuando se invoca el método CreateTransaction( ) se crea una instancia de la clase de transacción especifica de la aplicación con base en el identificador de función. Descripción general de la ejecución de transacción La ejecución general de una transacción es un proceso complejo que involucra una serie ordenada de validaciones y subprocesos. Adicionalmente, con base en la naturaleza de la transacción, este procesamiento puede desarrollarse en una o más transacciones con un sistema externo o con un usuario interactivo. Esta sección proporciona una descripción general del procesamiento que se produce durante la ejecución de la transacción. A esta descripción general le sigue secciones adicionales que detalla la operación de varios subprocesos. En general, el TPL procesa dos tipos principales de funciones (transacciones), la edición y sin edición. Las funciones que no son de edición son de sólo lectura (por ejemplo, consultas) que meramente devuelven información. Las funciones que no son de edición se pueden clasificar adicionalmente como funciones de formulario o forma. Las funciones de formulario devuelven una composición de muchos objetos comerciales complejos. Las funciones de forma sólo devuelven un objeto comercial complejo único. Las funciones de edición ocasionan la modificación de los datos dentro de la base de datos. Por definición, las funciones de edición sólo funcionan como un solo objeto comercial. Las funciones de edición 259 adicionalmente se clasifican en una de los siguientes; funciones de inserción, de actualización o de borrado (con base en la operación que se realiza en el objeto de raíz para la transacción). Para cada transacción el TPL define las siguientes fases de procesamiento para cada transacción, el TPL define las siguientes fases de procesamiento principal. Preparación (Prepare) Durante la preparación, los objetos existentes necesarios para procesar esta transacción se recuperan de la base de datos, se crean nuevos objetos y se inicializan y cualquier otra inicialización o procesamiento específico de la aplicación se lleva a cabo. Esta fase ocasiona un contexto de edición que contiene objetos de aplicación ¡nicializados. Estos objetos se pueden usar meramente para mostrar información al solicitante o pueden representar un conjunto de información que se presenta para hacer más modificaciones. Validación (Valídate) Durante la validación, cualesquiera datos ingresados se validan y se aplican a los objetos dentro del contexto de edición (se devuelve al término de la fase de preparación). Después de que los datos de entrada se aplican se produce una secuencia de validación y procesamiento ordenado usando la jerarquía de objetos para esta transacción como se define dentro del OGS. Esta secuencia de procesamientos 260 realiza la validación o procesamiento especifico para la aplicación para la transacción. Al terminar esta secuencia, el TPL realiza sus servicios centrales finales, generación de alertas, evaluación del estado del flujo de trabajo, generación de eventos y generación de mensajes de término. Si se detectan errores el contexto de edición que contiene los objetos se devuelve al estado que existió Al final de la fase de preparación. De otra manera, esta fase ocasiona un contexto de edición que contiene los objetos de aplicación y de sistema que refleja los resultados del procesamiento específico para esta transacción (listo para asignarse a la base de datos). Asignación (Tran) durante la asignación, los objetos de aplicación y sistema dentro del contexto de edición (que se modificaron) se escriben en la base de datos. Para las funciones que no son de edición, sólo se permite la fase de preparación. Para las funciones de edición se requieren todas las fases. Se realiza una transacción al invocar el método Execute( ) del objeto Tran para esta transacción. Antes de invocar este método, los siguientes atributos de entrada del objeto Tran se establecen. Objeto de raíz Es una referencia a un objeto comercial existente. Si la función es una función de insertar, entonces este parámetro 261 será nulo. Clase de objeto de raíz La clase de aplicación de los objetos de raíz. Parámetros de transacción (TranParms) Un conjunto de parámetros específicos de la aplicación que se usan para controlar adicionaimente el procesamiento de la función de la aplicación. OG de entrada Se hace una referencia a un objeto OG que contiene los datos de entrada para esta transacción. Parámetros de consulta Para las funciones que no son de edición, es una referencia a un objeto de los parámetros de consulta. Este objeto contiene parámetro de consulta que se usan para controlar la selección de los objetos de la base de datos(es decir, similar a la cláusula EN DONDE de una consulta SQL).

Subfunción La fase de ejecución que se realiza, preparación, validación, asignación. Al regresar del método Execute-( ). Los siguientes atributos de salida del objeto tran se devuelven. OG de salida Es una referencia a un OG que contiene los objetos comerciales resultantes de esta solicitud (como los controla el OGS para esta transacción). Para las funciones de visualización que no son de edición, este OG consiste en una 262 matriz de cero para muchos objetos comerciales complejos. Para las otras funciones. Este OG consiste en un solo objeto comercial complejo. Flujo de datos En lugar de generar un OG de salida, algunas transacciones de la aplicación producen un flujo de datos binarios (el formato y la estructura del cual se define dentro del objeto de función). Código de devolución de TPL El código de retorno que indica el estado del procesamiento de transacción, SATISFACTORIO, ERROR, REINTENTO o FALLA. El significado de estos códigos es como se indica a continuación. SATISFACTORIO-indica que la subfunción se realizo de manera satisfactoria mediante el TPL y no se detectaron errores en la aplicación. En este caso, la matriz de mensajes puede contener uno o más mensajes informales o de advertencia. ERROR- indica que se realizo la subfunción de manera satisfactoria mediante el TPL, pero se detectaron errores en la aplicación. En este caso, la matriz de mensajes contiene uno o más mensajes de error además de cualquier mensaje de información o advertencia. REINTENTAR-solo para procesamientos en segundo plano, que indica la subfunción no se completo y que existe 263 una condición recuperable. El subsistema debe reintentar esta solicitud posteriormente. El mecanismo para hacer el reintento depende el subsistema. FALLA- indica que el TPL encontró un error de configuración o una excepción no manejada durante el procesamiento de esta solicitud (que se recupera desde este) y registro un evento en el sistema. Esta solicitud no se puede procesar Matriz de mensajes Una matriz de objetos de mensaje que contiene uno o más mensajes de la aplicación. Cada mensaje contiene una gravedad, de información, de advertencia o de error. A continuación se presenta un resumen de las operaciones que se producen al usar este método y sus parámetros. La subfunción se valida con base en el estado actual de la transacción y el tipo de función. Para las funciones que no son de edición sólo se puede especificar "preparar". Para las funciones de edición, se pueden especificar todas las subfunciones. Sin embargo, dependiendo del estado de la transacción, ciertas subfunciones no son validas. Por ejemplo, si la transacción completada tiene un estado de "validación", entonces no es valida para especificar la subfunción "preparación". Se usa una maquina de estado finito (FS ) para asegurar que la subfunción especificada es 264 valida para el estado de transacción determinado. Si la subfuncion no es valida se devuelve un error. Con base en la subfuncion pasada, se invoca uno de los siguientes métodos SCTran internos: _prepare( ), _validate( ) o _commit( ). Debido a que el subsistema de invocación inicialmente puede ejecutar una transacción con "validar "o "asignar", cada una de estas funciones internas verifica el estado de la transacción e invoca el método para una fase anterior si es necesario. Como resultado, las fases de transacción se ejecutan en orden, preparación, validación, asignación (con excepción de las funciones que no son de edición en donde sólo es válida la preparación). Las fases realizadas nunca exceden la fase indicada por la subfuncion. Una vez que la fase o las fases indicadas por la subfuncion se realizan, el contexto de edición resultante (administrado por el objeto Tran) contiene uno o mas objetos comerciales. Al usar este contexto de edición y el OGS para la transacción, se crea un OG de salida. El método UpdateStatistics( ) con el objeto TranMgr se invoca para actualizar las estadísticas de transacción para esta solicitud. El método entonces devuelve al subsistema que hace la invocación los parámetros de salida descritos anteriormente. Procesamiento de preparación El procesamiento que se realiza durante la preparación varia con base en el tipo de función que se realiza. 265 Para funciones de formulario, las operaciones siguientes se realizan. Si el estado del Tran es "preparación" (es decir, ya se realizo una "preparación"), reestablezca el Tran al estado "Init". Los criterios de selección que se usan para seleccionar los objetos comerciales para el formulario se reúnen como se indica a continuación: los criterios de selección se inicializan en nulo; los parámetros de consulta de los elementos intrínsecos se colocan en AND en los criterios de selección actual; los parámetros de consulta de las funciones intrínsecas se colocan en AND en los criterios de selección actual, los parámetros de consulta de la función se colocan en AND para los criterios de selección actual; y los parámetros de consulta que pasan en el objeto Tran se colocan en AND a los criterios de selección actual. El siguiente parámetro de consulta de codificación dura está en AND en la selección actual. Este calificador asegura que la consulta de SQL sólo devuelve los objetos comerciales para los cuales está autorizada la organización actual. Este parámetro de consulta es muy importante para proveer seguridad a los datos entre organizaciones. De esta manera DEBE tener una codificación dura dentro de los programas y sistemas de programación y no debe ser modificable a través de la configuración. A continuación se resumen las condiciones clave para este calificador. La organización que realiza esta función debe ser una parte de la carpeta que 266 contiene este objeto comercial. La organización que realiza esta función debe tener acceso a una o mas tareas dentro de la carpeta (es decir, su tercera parte debe incluirse en la matriz de parte actual para una o más tareas dentro de la carpeta). La relación de esta organización para esta transacción (es decir su tipo de parte dentro de la carpeta debe corresponder al tipo de parte de la función que realiza) Al usar los criterios de selección creados anteriormente, los objetos comerciales se recuperan desde la base de datos (de conformidad con estos criterios de selección) en el contexto de edición asociado con este objeto de transacción. Se crea un OG de salida usando el OGS para la función y los objetos comerciales dentro del contexto de edición. Establece el estado de la transacción en "preparación" establece el código de retorno y cualquier otros parámetros de salida y lo devuelve al subsistema de invocación . Para las funciones de forma, actualización y eliminación se realizan las siguientes operaciones. Si el estado de la transacción esta en "preparación" (es decir, que se realizo una "preparación"), restablezca la transacción al estado "Init". Si la función es una función de edición o si la función es una función de forma (con un valor de, bloqueo verdadero especificado en la función), se bloquea la carpeta que contiene el objeto comercial. Si el bloqueo no es 267 satisfactorio, se devuelve un error. Si pasa un parámetro del objeto de raíz de realiza lo siguiente. El objeto de raíz y cualesquiera otros objetos relacionados (como se especifica en el OGS) se recupera de la base de datos. Si la clase del objeto de raíz regresado no corresponde con el parámetro de la clase de objeto de raíz entonces se devuelve una FALLA. La carpeta asociada con el objeto de raíz y las partes relacionadas con esta carpeta se recuperan desde la base de datos. El tipo de parte de la organización que realiza esta función se determina como se indica a continuación. Se obtiene el identificador de la compañía del administrador de transacciones asociado con esta transacción. Se explora los objetos de la parte de la carpeta y se ubica el objeto de parte con el mismo identificador de compañía. Si la compañía no existe como una parte de esta carpeta, entonces se devuelve una FALLA. Obtiene el tipo de parte del objeto de parte. Si el tipo de parte para esta función no corresponde a este tipo de parte de organización para las transacciones comerciales (es decir, carpetas) entonces se devuelve una FALLA. Esta comprobación asegura que la organización que realiza esta función opera dentro de las relaciones definidas para esta transacción comercial específica. Par las funciones de edición, el método de verificación de flujo de trabajo Checkworkflow( ) del administrador del 268 flujo de trabajo se invoca para determinar si esta función es valida o no con base en el estado del flujo del estado actual de la carpeta. Si la función no es valida se devuelve un error. Después de completar las validaciones anteriores el método de preparación del objeto de transacción se invoca. Una implementación muestra de este método se proporciona en la clase SCTran (que únicamente devuelve). El objetivo de este método es pasar control a la versión específica de la aplicación de este método en la clase de transacción de la aplicación. Si este método se implementa realiza cualquier ¡nicialización específica de la aplicación como sea necesario. Al regresar del método de preparación se crea un OG de salida usando el OGS y los objetos comerciales dentro del contexto de edición. Se establece el estado de la transacción en "preparación", se establece el código de devolución y cualquier otro parámetro de salida y se devuelve al subsistema que hace la invocación. Para las funciones de inserción se realizan las siguientes operaciones. Si el estado de la transacción es "preparar" (es decir, ya se realizo una "preparación"), se reestablece la transacción a su estado "Init". Con base en la clase de objeto de raíz se crea un nuevo objeto comercial de esta clase. El método de verificación del flujo de trabajo Checkworkflow( ) del administrador del flujo de trabajo se invoca para determinar si la función es valida o no con base 269 en el estado del flujo de trabajo actual de la carpeta. Si la función no es valida se devuelve un error. El, método de preparación del objeto de esta transacción se invoca. Se proporciona una implementacion muestra de este método en la clase SCTran (que únicamente devuelve). El objetivo de este método es pasar control a la versión específica de la aplicación de este método en la clase de transacción de la aplicación. Si este método se implementa, realiza la inicialización específica de la transacción como se requiera. Al regresar del método de preparación se crea un OG de salida usando el OGS y los objetos comerciales dentro del contexto de edición. Se establece el estado de la transacción en "preparación" se establece el código de devolución y cualesquiera otros parámetros de salida y se devuelven al subsistema que hizo la invocación. Procesamiento de validación Durante el procesamiento de validación se realizan las siguientes operaciones. Si la transacción se encuentra en un estado "Init" (es decir, no se ha reflejado la preparación) se invoca el método de preparación _prepare( ) (véase procesamiento de preparación en párrafos anteriores. Si la transacción esta en un estado valido (es decir, ya se ha realizado una validación) se reestablecen los objetos comerciales dentro del contexto de edición de nuevo en el estado que existía inmediatamente después del 270 procesamiento de preparación. Si se proporciona un OG de entrada, los elementos de datos con indicador como los elementos de entrada (dentro del OGS) serán validados (una validación sintáctica). Al usar la jerarquía de objeto definida dentro del OGS el método de validación _validate( ) de cada objeto comercial se invoca iniciando en la parte inferior de la jerarquía y recorriendo hasta la parte superior. Esta secuencia de validación proporciona una validación ordenada para todos los objetos comerciales dentro de la transacción. Después de completar las validaciones anteriores el método de validación del objeto de transacción se invoca. Se proporciona una implementación muestra de este método en la clase SCTran (que hace meramente una devolución) el objetivo de este método es pasar control a la versión especifica de la aplicación usando este método en la clase de transacción de la aplicación. Si se implementa este método se realizan las validaciones y procesamientos específicos de la aplicación según sea necesario. NOTA: este método sólo se invoca después de que todos los objetos comerciales dentro de la transacción sean validados. Si se detectan errores en la aplicación se reestablecen los objetos comerciales dentro del contexto de edición nuevamente en el estado en que existieron inmediatamente después del procesamiento de preparación y devuelve un ERROR. Después de regresar del método de validación el método de generación de alertas 271 GenerateAlerts( ) el administrador de alertas se invoca. Este método evalúa las reglas comerciales para todas las partes involucradas en esta transacción y genera los objetos de alertas adecuados (SAAIert) dentro del contexto de edición. Después de procesar las alertas, el método de la evaluación del flujo de trabajo del administrador del flujo de trabajo se invoca. Con base en la función de la aplicación que se procesa, este método establece el siguiente estado de flujo de trabajo para la carpeta. Después de evaluar el flujo de trabajo el método para generar un historial de eventos (GenerateHistoryEvents( )) del objeto de la transacción se invoca. Este método cruza la jerarquía del objeto comercial para esta transacción y genera los objetos de eventos (SAEvent) con base en los cambios de los objetos comerciales (derivados del SADocument). Después de generar los eventos históricos, el método para generar un mensaje de determinación (GenerateCompletionMessage( )) de los objetos de la transacción se invocan. Al usar la plantilla del mensaje determinación definida en la función este método genera un mensaje determinado para esta función y lo añade a la matriz de mensajes (para esta transacción). Se cera un OG de salida usando el OGS para la función y los objetos comerciales dentro del contexto de edición. Se establece el estado de la transacción en "validar" se establece el código de devolución y cualquier otro parámetro de salida, y 272 devuelve un subsistema de invocación. Procesamiento de asignación Durante el procesamiento de asignación, las siguientes operaciones se realizan. Si la transacción esta en un estado "Init" (es decir nos e ha realizado una preparación), se invoca el método de preparación (_prepare( ) véase el procesamiento de preparación anterior). Si la transacción esta en un estado "de preparación" (es decir, no se ha realizado una validación) se invoca un método de validación (_validate( ) véase el procesamiento de validación anterior). Se invoca el método de comprobación de bloqueo SAAttachment del administrador de bloqueo para esta carpeta. Si no es satisfactorio, devuelve un ERROR. De otra manera, este método regenera el bloqueo (de esta manera asegura que nadie mas modifica la carpeta). Dentro del contexto de edición de este objeto de transacción, se asignan todos los objetos comerciales (que ya se han modificado) a la base de datos. Se desbloquea la carpeta. Procesamiento lógico de la aplicación Con base en la estructura analizada anteriormente, la lógica de la aplicación que se requiere para las aplicaciones construidas con la A/ F se simplifica en gran medida. La lógica de aplicación está codificada dentro del 2 conjuntos principales de objetos, las clases de transacción de la aplicación y las clases del objeto comercial. Clases de transacción de la aplicación 273 La clase de transacción de aplicación da soporte a uno o más elementos intrínsecos dentro de la aplicación. Con cada clase, los métodos siguientes están codificados. Método de preparación: este método se usa para realizar una inicialización específica de la aplicación para la transacción. Método de validación: este método se usa para realizar las validaciones y procesamientos específicos de la aplicación de la transacción. Clases de objeto comercial Cada transacción consiste en uno o más objetos comerciales. Los objetos comerciales representan las entidades de los datos para el sistema de la aplicación. Dentro de cada clase, se codifica el siguiente método. Método de validación: este método se usa para realizar la validación en procesamiento específico para el objeto comercial. Debido a una secuencia ordenada en la que se invoca este método, todos los objetos dependientes (es decir, secundarios) que están relacionados con este objeto se validan antes de que este método se invoque para este objeto. De esta manera, esta validación y procesamiento puede incluir cualesquiera validaciones complejas, ediciones cruzadas o manipulaciones de cualesquiera objetos dependientes que están subordinados a este objeto. Procesamiento de servicios del sistema diversos subsistemas y objetos descritos 274 anteriormente se basan en un conjunto enriquecido de servicios del sistema con estos servicios se describen adicionalmente e en esta sección. Bloqueo y reservación Al centralizar los datos asociados las transacciones entre organizaciones en una red/ base de datos común, el sistema facilita la capacidad de cada organización para colaborar entre si. De esta manera, cuando una organización determinada realiza una función con respecto a una transacción comercial determinada, el sistema automáticamente proporciona el bloque y la reservación de las carpetas como se indica a continuación. En general, cualquiera puede tener acceso a la información para una transacción comercial especifica (de sólo lectura) en cualquier momento (aunque la carpeta este bloqueada). Cuando una función de edición se realiza la carpeta se bloquea hasta que la función de edición se completa. Para la propiedad de equipos, cuando una carpeta se devuelve a un operador de la consulta, esta se bloquea hasta que el operador recupera otra carpeta o sale del sistema. Esto permite que un operador dentro del equipo realice varias funciones en la carpeta sin bloquear que alguien mas acceda a la carpeta. Cuando la carpeta esta bloqueada por una organización, si otra organización intenta bloquearla (por 275 ejemplo, realizando una función de edición), el sistema notifica al operador que la carpeta está bloqueada por la otra organización . Para evitar que una carpeta sea bloqueada durante una cantidad de tiempo en exceso se proporciona un mecanismo de tiempo fuera. Este mecanismo "desbloquea" la carpeta hasta que expida el periodo de tiempo fuera. Servicios gráficos de objeto Con un procesamiento de transacción de múltiples partes, cada solicitud de transacción necesita filtrarse para limitar los elementos de datos de entrada y salida para la parte específica. Esta filtración de datos de varias partes se realiza a través del TPL usando una especificación gráfica de objeto (OGS). Cada solicitud de transacción está asociada con una función (cuya definición esta contenida dentro de la configuración del sistema). Una OGS se asocia con cada función. La OGS define el conjunto de entidades de datos y sus atributos y la estructura del objeto, para una solicitud de transacción determinada (es decir una función). Cada subsistema de interfaz convierte la solicitud de transacción entrante en una gráfica de objeto (es decir, una estructura jerárquica orientada al objeto de pares clave dos puntos valor). El subsistema de interfaz entonces invoca al TPL para procesar la transacción. 276 Al usar la OGS asociada con la función para esta solicitud de transacción, la TPL valida los datos de entrada proporcionados con la solicitud de la transacción. Al hacerlo, sólo recibe y procesa los elementos de los datos de entrada que se especifican en la OGS (de esta manera evita la creación o modificación de elementos de datos que no están permitidos para esta parte). Después de procesar los datos de entrada, el TPL invoca la lógica de la aplicación para procesar la transacción. Una vez que la lógica de la aplicación ha completado el procesamiento, el TPL usa la OGS para preparar una nueva gráfica de objeto que contiene los resultados del procesamiento de la aplicación. Al hacerlo, la OG resultante sólo contiene los elementos de datos que se definen dentro del OGS (de esta manera sólo envía los elementos de datos que están permitidos para esta parte). Después de que el TPL completa su procesamiento, su sistema de interfaz convierte la nueva gráfica de objeto (de vuelta por el TPL) en una respuesta de transacción saliente.

Esencialmente, los servicios de la gráfica del objeto aseguran que una parte determinada sólo puede enviar o recibir elementos de datos permitidos para su tipo de parte. Otro aspecto único para este servicio es su capacidad de aislar la lógica de la aplicación de los detalles de la filtración del tipo de parte. Esto significa en gran medida el código de aplicación resultante mientras da soporte también a un gran 277 número de transacciones relacionadas que difieren con respecto al contenido de los datos. Administración de alertas y normas comerciales Para manejar los requerimientos de procesamiento único para cada organización miembro el sistema da soporte a la definición de las reglas comerciales que son específicas para cada organización. Estas definiciones de reglas comerciales se definen dentro de la configuración de sistema (y varían con cada aplicación vertical). Cada vez que el TPL procesa una función de edición, invoca al administrador de alertas para que realice una evaluación de reglas comerciales y genere una alerta. Para cada parte que se define en la carpeta (asociada con esta transacción), el administrador de alertas recupera y evalúa todas las reglas comerciales que aplican. En la evaluación de cada regla comercial si la regla comercial falla, se genera una alerta. Estas reglas comerciales se vuelven a evaluar en cualquier momento que se realice una nueva función de edición a la carpeta (por cualquier parte). Dentro de cada carpeta, se mantiene una colección de alertas. Esta colección representa el conjunto actual de condiciones comerciales excepcionales que existen dentro de la carpeta. Cuando se genera un alerta, una definición de reglas de alerta dentro de la configuración del sistema se usa para determinar que tipos de parte deben permitirse para que 278 accedan a esta alerta. De esta manera, algunas alertas pueden ser privadas para una parte específica, mientras otras alertas pueden ser públicas para varias partes. Esencialmente, los servicios de administración de alertas y reglas comerciales proporcionan a al a organización un procesamiento de reglas comerciales especificas. Este servicio es exclusivo ya que tiene capacidades de procesamiento de varias partes. Administración del flujo de trabajo Cada vez que el TPL procesa una función de edición, invoca al administrador del flujo de trabajo para que determine el siguiente estado del flujo de trabajo para la carpeta (es decir, la administración del flujo de trabajo). Para obtener mayor información sobre esta capacidad, refiérase a la sección relacionada en "administración del flujo de trabajo entre organizaciones". Administración de seguridad El servicio de administración de seguridad se dirige a los requerimientos de la seguridad dentro de la organización y entre las organizaciones. A continuación se resume estas capacidades de administración de seguridad. El servicio de seguridad siempre valida la identidad de cualquier operador o sistema automatizado que intenta conectarse al sistema y realizar las transacciones (es decir, valida al solicitante). 279 Una vez que se verifica la identidad del solicitante, se verifica el siguiente conjunto de restricciones de seguridad entre organizaciones. Se asegura que un solicitante sólo puede acceder a las carpetas (transacciones comerciales) y datos de la carpeta relacionados, para los cuales su organización es una parte valida. Se asegura que el solicitante sólo puede realizar las funciones para las cuales su organización está autorizada (con base en el conjunto valido de tipos de partes definidas para su organización). Para una carpeta determinada (transacción comercial), se segura que un solicitante sólo pueda realizar las funciones para las que tiene permiso a través de la relación (tipo de parte) de su organización para dicha carpeta. Para una carpeta determinada (transacción comercial) se asegura que un solicitante sólo puede realizar las funciones para las que tiene permiso su tipo de parte con base en el estado de flujo de trabajo actual de dicha carpeta. Para una carpeta determinada (transacción comercial), se asegura de que el solicitante sólo puede enviar/ recibir elementos de datos que se permiten a través de la relación (tipo de parte) de su organización para dicha carpeta. Dentro de las restricciones establecidas a través de los mecanismos de seguridad dentro de las organizaciones, se verifican las siguientes restricciones dentro de la organización. Se asegura de que un solicitante sólo tiene 280 acceso a las carpetas (transacciones comerciales) que están permitidas en su papel. Asegura que un solicitante pueda realizar sólo las funciones que están definidas en su papel. Asegura que un solicitante sólo pueda enviar/ recibir elementos de datos que están autorizados a través de su papel. Esencialmente, el servicio de administración de seguridad asegura y mantiene la privacidad de los datos dentro del sistema. Es exclusivo en su capacidad de manejar las restricciones de seguridad dentro de la organización dentro del contexto de las restricciones de seguridad entre organizaciones. Propiedad individual y en equipo Para cada capeta del sistema, se debe especificar un propietario para cada organización (parte) que se define para dicha carpeta. Esto permite que el sistema identifique al grupo o individuo especifico responsable del manejo de la transacción dentro de cada organización. El sistema puede soportar la propiedad individual o de equipo. Con la propiedad individual, la carpeta es de un individuo específico dentro de una organización determinada. Con este método de propiedad, el operador individual administra sus carpetas usando una variedad de formularios y filtros. La propiedad de esta carpeta permanece con dicho individuo hasta que se transfiere a otro individuo o se 281 completa la transacción. Con la propiedad de equipo, la carpeta es propiedad de un grupo de operadores (no un operador individual). Este método de propiedad típicamente se usa en organizaciones grandes con altos volúmenes de transacción (por ejemplo, reclamaciones de seguros, manejo de solicitudes de compra, etc.) y proporciona una mayor eficiencia en el manejo de archivos y una correspondencia mejorada. Al usar este método, un grupo de operadores se asignan para que procesen una consulta de carpetas que comparten un conjunto común de características (por ejemplo, un estado del flujo de trabajo, la geografía, la cantidad, la condición comercial, etc.). Los siguientes servicios adicionales se proporcionan para dar soporte completo a la propiedad de equipo. Una o más funciones de "obtener trabajo" se pueden definir que permiten que los operadores de grupo recuperen una carpeta de la consulta de las carpetas. Los criterios de selección que definen las carpetas que pertenecen a una consulta determinada pueden ser simples o extremadamente complejas. El bloqueo y reservación especial del manejo se proporciona (para mayor información, consulte la sección "bloqueo y reservación"). Notificaciones externas Además de las capacidades de mensajes electrónicos que proporciona el servicio de traducción de mensajes, el 282 sistema también da soporte a la capacidad de usar los servicios de comunicación externa para el objetivo de emitir notificaciones. Esta capacidad se denomina como el servicio de notificación externa. Este servicio es útil para enviar notificaciones a las personas que son usuarios poco frecuentes del sistema. Esto permite que los usuarios tengan notificación sobre la actividad comercial que se produce dentro del sistema (sin contar con una entrada al sistema y verificar el sistema en una base regular). Para los eventos que se procesan a través del administrador de eventos, sí se define una notificación externa para dicho evento, el administrador de eventos invoca al administrador de notificación externa para que genere la notificación. Los ejemplos de las redes de comunicación externa que típicamente se usaran para las notificaciones externas incluyen correo electrónico, fax, localizador, teléfono celular, PDA, y otros dispositivos inalámbricos. Servicios instantáneos Para cada carpeta, el subsistema del administrador de eventos mantiene un historial comercial enriquecido sobre todas las modificaciones de la carpeta. Dentro de cada evento, se conserva una colección completa de la jerarquía del objeto comercial para la transacción. El mecanismo 283 instantáneo se diseño para evitar la sobrecarga al mantener los datos históricos dentro de cada tabla de aplicación diferente en la base de datos. Esencialmente, la imagen instantánea es un glóbulo de datos (en formato XML) que contiene la jerarquía del objeto comercial que existió dentro de una transacción cuando la transacción se asigno a la base de datos. Al crear un evento dentro de una transacción, el método para crear un evento (CreateEvent( )) usa el objeto de raíz para el evento y genera un objeto de imagen instantánea (SASnapshot) para este evento usando el OGS de la imagen instantánea que se define en la plantilla de eventos asociada con este evento. Se almacena una referencia a este objeto en el objeto de eventos creado. Estos objetos se escriben en la base de datos, junto con todos los otros datos para la transacción durante el procesamiento de "asignar". Para visualizar los objetos comerciales dentro de una imagen instantánea, el objeto de imagen instantánea primero se recupera de la base de datos. Entonces se crea un contexto de edición especial. Finalmente, el glóbulo de datos de la imagen instantánea (flujo XML) se analiza y cada objeto comercial individual se reconstituye dentro del contexto de edición especial. El TPL entonces prepara unas GO de salida usando los objetos comerciales contenidos en este contexto de edición. 284 Elaboración de informes Con cualquier aplicación determinada, las transacciones de varias organizaciones se contienen dentro de una base de datos. Para proteger la privacidad de cada una de la organización, ninguna organización puede tener un enlace directo con la base de datos para notificar los objetivos. El servicio de elaboración de informes se diseño para proveer una facilidad de elaborar informes de alto rendimiento para generar informes. Esencialmente, el servicio de elaboración de informes usa los mismos mecanismos que usan las funciones de visualización dentro del sistema. Sin embargo, en lugar de recuperar objetos de la base de datos, este servicio utiliza mecanismo y agregados de consulta "sin procesar" (por ejemplo, SQL sin procesar) para permitir que la base de datos realice un resumen y agregado de datos en los datos. Esto reduce en gran medida la cantidad de datos transferidos entre el servidor de la base de datos y el servidor de la aplicación. Estas filas sin procesar pasaran al entorno Jview™ dentro del buscador para su presentación. Administración de documentos Aunque muchas de las facilidades dentro del sistema están orientadas alrededor de la administración de los documentos estructurados, se proporciona un conjunto enriquecido de servicios de administración de documentos 285 para administrar los documentos no estructurados. Esencialmente, un documento no estructurado recibe un trato de glóbulo binario y puede soportar virtualmente cualquier tipo de documentos (por ejemplo, documentos de procesamiento de palabras, hojas de cálculo, gráficos, imágenes/ fotos, animaciones, audio, video, etc.). El servicio de administración de documentos proporciona una variedad de métodos para importar estos documentos en el sistema. Estos mecanismos incluyen HTTP, FTP, correo electrónico y extracción de URL. Cuando se anexa un nuevo documento no estructurado a una carpeta, se crea un objeto de anexo (SAAttachment). Este objeto contiene meta datos relacionados con el documento. Además, el documento real en si mismo se almacena dentro de un objeto de los datos anexos (SAAttachmentData) . Dentro de este objeto, los datos binarios que representan al documento se almacenan en un glóbulo. De hecho, con base en el tipo primario del documento anexo, dos glóbulos se almacenan realmente dentro del objeto de datos anexos, un glóbulo nativo y un glóbulo genérico. El glóbulo nativo contiene los datos binarios reales den documento original. El glóbulo genérico contiene una versión del documento original convertido en un formato común (por ejemplo, PDF para documentos P3 para audio, MPEG para video, etc.). 286 Cuando se recibe una nueva revisión de un anexo determinado, se crea un nuevo objeto de datos anexos. El objeto del anexo mantiene una lista de todas las revisiones de un documento determinado (de esta manera provee un historial de revisión completa para el documento). Dentro de cada objeto anexo, el atributo de rejilla de parte actual (currentPartyArray) se usa para definir las partes dentro de la carpeta que pueden acceder al anexo. Se han descrito modalidades ilustrativas de la presente invención. Sin embargo, una persona experta en la técnica puede notar que algunas modificaciones sean evidentes dentro de las enseñanzas de la presente invención.

Claims (116)

1. 287
2. REIVINDICACIONES 1.- Un método para emitir, negociar y establecer reclamaciones para de seguros, al menos entre dos partes a través de una red de subrogación electrónica, dicho método comprende: proveer al menos un archivo de subrogación electrónico que puede contener información estructurada de la reclamación y documentos de soporte no estructurados de tal forma que varias partes pueden tener acceso a ésta; que permite la entrada, a través de medios electrónicos de comunicación, por una o más de dichas múltiples partes de una o ambas partes de la información de reclamación y documentos de soporte a dicho archivo de subrogación basado en reglas específicas de cada una de las partes; y permite el acceso, a través de medios electrónicos por medio, por una o más de dichas múltiples partes a uno o ambos de dicha información de reclamación estructurada y dichos documentos de soporte no estructurados con base en reglas específicas de cada parte. 2.- El método tal y como se describe en la reivindicación 1, en donde dichas entradas permisivas incluyen introducir de manera automática documentos en papel recibidos a través de un fax o un digitalizador de alta velocidad en un archivo electrónico.
3. 3.- El método tal y como se describe en la 288 reivindicación 1, en donde dichos medios electrónicos de comunicación comprenden una red y además incluyen la emisión de demandas de subrogación a través de medios de comunicación electrónica para las partes conectadas a la red y las no conectadas a la red.
4. 4. - El método tal y como se describe en la reivindicación 1, que además incluye el establecimiento de funciones de reglas comerciales y auditorías que permiten que dicho al menos un archivo de subrogación electrónico se audite electrónicamente con base en dichas reglas específicas de la parte.
5. 5. - El método tal y como se describe en la reivindicación 1, en donde dichas múltiples partes incluyen una parte demandante, una contraparte y una o más partes de soporte/ facilitadoras que además incluye enrutar una demanda a la contraparte adecuada con base las regias de enrutamiento de la contraparte.
6. 6. - El método tal y como se describe en la reivindicación 5, en donde dicho enrutamiento incluye el uso de dicho algoritmo de enrutamiento que combina un índice específico de la parte demandante y un algoritmo heurístico para determinar correctamente una contraparte adecuada y además un individuo o grupo específico dentro de dicha contraparte que manejará inicialmente la demanda.
7. 7.- El método tal y como se describe en la 289 reivindicación 1, que además incluye el uso de un modelo basado en el estado para administrar el flujo de trabajo de la subrogación entre las partes.
8. 8. - El método tal y como se describe en la reivindicación 1, que además incluye permitir las funciones del flujo de trabajo de subrogación dentro de cada parte, incluyendo planes de acción de seguimiento y flujo de trabajo específico para cada parte.
9. 9. - El método tal y como se describe en la reivindicación 1, que además incluye proveer funciones de colaboración que permiten que las partes seleccionadas intercambien información y negocien usando dichos medios de comunicación electrónica.
10. 10. - El método tal y como se describe la reivindicación 1, que además incluye proveer una función de administración de documentos que permite que dichas múltiples partes actualicen anexos y administren las versiones de los documentos.
11. 11. - El método tal y como se describe en la reivindicación 1, en donde dichos medios de comunicación electrónica incluyen una red y además incluyen alertas de generación automática para las partes conectadas en red, para las condiciones de excepción o violaciones de las reglas específicas de la parte mencionada.
12. 12.- El método tal y como se describe en la 290 reivindicación 1, que además incluye la asignación selectiva de archivos seleccionados y provee acceso en línea a terceras partes, incluyendo árbitros, abogados, y proveedores de servicios externos.
13. 13.- El método tal y como se describe en la reivindicación 1, en donde dichos medios de comunicación electrónica incluyen una red, e incluyen la generación personalizada de informes de administración en línea.
14. 14. - El método tal y como se describe en la reivindicación 1 que además incluye establecer reclamaciones de subrogación entre las partes de manera automática, basadas en las reglas comerciales de cada parte.
15. 15. - El método tal y como se describe en la reivindicación 1, que además incluye la generación automática de contrademandas con base en un porcentaje de responsabilidad y reglas de negligencia comparativa de una contraparte.
16. 16. - El método tal y como se describe en la reivindicación 1, caracterizado además porque incluyen la activación de una transferencia de fondos automática con base en la respuesta de una contraparte.
17. 17. - El método tal y como se describe en la reivindicación 1, que además incluye pagos en red entre las partes involucradas en una reclamación de subrogación, que incluye: 291 dar seguimiento a los pagos que se deben y a los pagos vencidos durante un período determinado para un miembro; pagar en la red, ya sea de manera bilateral entre las partes o multilateral entre una parte y una red de subrogación electrónica que representa a todas las otras partes que participan en un proceso en red; configurar períodos en red; y administrar la información para asignar los pagos en red para cada expediente de reclamación.
18. 18. - El método tal y como se describe en la reivindicación 1, que además incluye permitir que los miembros marquen los parámetros de su operación de subrogación y/o de reclamaciones en comparación contra un agregado con base en la información contenida en dichos expedientes de la subrogación electrónica.
19. 19. - El método tal y como se describe en la reivindicación 1, que además incluye evaluar la mejor ruta de acción dentro de un proceso de subrogación, que incluye la realización de un análisis costo-beneficio para continuar una ruta de acción particular.
20. 20. - El método tal y como se describe en la reivindicación 1, que además incluye la evaluación de la validez de una demanda de subrogación que incluye la realización de una auditoría electrónica para condiciones 292 seleccionadas con base en parámetros que pueden ser configurados de la parte demandante y una o más contrapartes, dichos parámetros que puede ser configurados incluyen, sin limitarse a esto, los datos o documentos necesarios, responsabilidad en la reclamación y daños así como las condiciones de evaluación del vehículo.
21. 21. - El método tal y como se describe en la reivindicación 1, que además incluye enrutar la demanda de subrogación a las contrapartes usando un algoritmo de enrutamiento, que combina un algoritmo heurístico para determinar de manera correcta la identidad de la contraparte y enrutar las reglas definidas por la contraparte.
22. 22. - Un método para organizar y modelar información comercial específica de la subrogación que comprende: proveer entidades, atributos y relaciones específicas para el flujo de trabajo de la subrogación; traducir formatos de datos entrantes a un formato modelo de datos unificados; y mantener la consistencia en dicha traducción.
23. 23.- Un método para administrar el flujo de trabajo entre dos o más organizaciones dentro de un proceso de subrogación, dicho método comprende: proveer un modelo de flujo de trabajo específico para la subrogación que incluye estados de flujo de trabajo entre organizaciones, transiciones, condiciones, estados e 293 indicadores de acción; y además de administrar el flujo de trabajo específico de la organización dentro del contexto del flujo de trabajo de la comunidad.
24. 24.- El método tal y como se describe la reivindicación 23, que además incluye proveer información del estado en tiempo real a dichas organizaciones.
25. 25. - El método tal y como se describe la reivindicación 23, que además incluye la administración del flujo de trabajo específico de la organización con base en los eventos en las condiciones de excepción dentro del flujo de trabajo.
26. 26. - Un sistema para emitir, negociar y establecer reclamaciones para de seguros, al menos entre dos partes a través de una red de subrogación electrónica, dicho sistema comprende: al menos un archivo de subrogación electrónico que puede contener información estructurada de la reclamación y documentos de soporte no estructurados de tal forma que varias partes pueden tener acceso a ésta; medios para permitir la entrada, a través de medios electrónicos de comunicación, por una o más de dichas múltiples partes de una o ambas partes de la información de reclamación estructurada y documentos de soporte no estructurados a dicho expediente de subrogación basado en reglas específicas de cada una de las partes; y 294 medios para permitir el acceso, a través de medios electrónicos de comunicación por medio de una o más de dichas múltiples partes a uno o ambos de dicha información de reclamación estructurada y dichos documentos de soporte no estructurados con base en reglas específicas de cada parte.
27. 27. - El sistema tal y como se describe en la reivindicación 26, en donde dichos medios para permitir la entrada incluyen medios para introducir de manera automática documentos en papel recibidos a través de un fax o un digitalizador de alta velocidad en un archivo electrónico.
28. 28. - El sistema tal y como se describe en la reivindicación 26, en donde dichos medios electrónicos de comunicación comprenden una red y además incluyen medios para emitir demandas de subrogación a través de medios de comunicación electrónica para las partes conectadas a la red y las no conectadas a la red.
29. 29. - El sistema tal y como se describe en la reivindicación 26, que además incluye métodos para establecer funciones de reglas comerciales y auditorías que permiten que dicho al menos un expediente de subrogación electrónico se audite electrónicamente con base en dichas reglas específicas de la parte.
30. 30. - El sistema tal y como se describe en la reivindicación 26, en donde dichas múltiples partes incluyen 295 una parte demandante, una contraparte y una o más partes de soporte/ facilitadoras que además incluye medios para enrutar una demanda a la contraparte adecuada con base en las reglas de enrutamiento de la contraparte.
31. 31.- El sistema tal y como se describe en la reivindicación 30, en donde dichos medios de enrutamiento incluyen un algoritmo de enrutamiento que combina un índice específico de la parte demandante y un algoritmo heurístico para determinar correctamente una contraparte adecuada y además un individuo o grupo específico dentro de dicha contraparte que manejará inicialmente la demanda.
32. 32. - El sistema tal y como se describe en la reivindicación 26, que además incluye el uso de un modelo basado en el estado para administrar el flujo de trabajo de la subrogación entre las partes.
33. 33. - El sistema tal y como se describe en la reivindicación 26, que además incluye medios para permitir las funciones del flujo de trabajo de subrogación dentro de cada parte, incluyendo planes de acción de seguimiento y flujo de trabajo específico para cada parte.
34. 34. - El sistema tal y como se describe en la reivindicación 26, que además incluye medios para proveer funciones de colaboración que permiten que las partes seleccionadas intercambien información y negocien usando dichos medios de comunicación electrónica. 296
35. 35. - El sistema tal y como se describe la reivindicación 26, que además incluye medios para proveer una función de administración de documentos que permite que dichas múltiples partes actualicen anexos y administren las versiones de los documentos.
36. 36. - El sistema tal y como se describe en la reivindicación 26, en donde dichos medios de comunicación electrónica incluyen una red y además incluye medios para generar alertas de manera automática para las partes conectadas en red, para las condiciones de excepción o violaciones de las reglas específicas de la parte mencionada.
37. 37. - El sistema tal y como se describe en la reivindicación 26, que además incluye medios para la asignación selectiva de archivos seleccionados y provee acceso en línea a terceras partes, incluyendo árbitros, abogados, y proveedores de servicios externos.
38. 38. - El sistema tal y como se describe en la reivindicación 26, en donde dichos medios de comunicación electrónica incluyen una red, e incluyen la generación personalizada de informes de administración en línea.
39. 39. - El sistema tal y como se describe en la reivindicación 26 que además incluye medios para establecer reclamaciones de subrogación entre las partes de manera automática, basadas en las reglas comerciales de cada parte.
40. 40.- El sistema tal y como se describe en la 297 reivindicación 26, que además incluye medios para la generación automática de contrademandas con base en un porcentaje de responsabilidad y reglas de negligencia comparativa de una contraparte.
41. 41.- El sistema tal y como se describe en la reivindicación 26, caracterizado además porque incluye medios para activar una transferencia de fondos automática con base en la respuesta de una contraparte. -
42. 42. - El sistema tal y como se describe en la reivindicación 26, que además incluye medios para hacer pagos en red entre las partes involucradas en una reclamación de subrogación, que incluye: medios dar seguimiento a los pagos que se deben y a los pagos vencidos durante un período determinado para un miembro; medios para pagar en la red, ya sea de manera bilateral entre las partes o multilateral entre una parte y la ESN que representa a todas las otras partes que participan en un proceso en red; medios para configurar períodos en red; y medios para administrar la información para asignar los pagos en red para cada expediente de reclamación.
43. 43. - El sistema tal y como se describe en la reivindicación 26, que además incluye medios para permitir que los miembros marquen los parámetros de su operación de 298 subrogación y/o de reclamaciones en comparación contra un agregado con base en la información contenida en dichos expedientes de la subrogación electrónica.
44. 44. - El sistema tal y como se describe en la reivindicación 26, que además incluye medios para evaluar la mejor ruta de acción dentro de un proceso de subrogación, que incluye medios para la realización de un análisis costo-beneficio para continuar una ruta de acción particular.
45. 45. - El sistema tal y como se describe en la reivindicación 26, que además incluye medios para la evaluación de la validez de una demanda de subrogación que incluye medios para la realización de una auditoría electrónica para condiciones seleccionadas con base en parámetros que pueden ser configurados de la parte demandante y una o más contrapartes, dichos parámetros que puede ser configurados incluyen, sin limitarse a esto, los datos o documentos necesarios, responsabilidad en la reclamación y daños así como las condiciones de evaluación del vehículo.
46. 46.- El sistema tal y como se describe en la reivindicación 26, que además incluye medios para enrutar la demanda de subrogación a las contrapartes usando un algoritmo de enrutamiento, que combina un algoritmo heurístico para determinar de manera correcta la identidad de la contraparte y enrutar las reglas definidas por la 299 contraparte.
47. 47.- Un método para organizar y modelar información comercial específica de la subrogación que comprende: medios para proveer entidades, atributos y relaciones específicas para el flujo de trabajo de la subrogación; medios para traducir formatos de datos entrantes a un formato modelo de datos unificados; y medios para mantener la consistencia en dicha traducción.
48. 48.- Un sistema para administrar el flujo de trabajo entre dos o más compañías dentro de un proceso de subrogación, dicho sistema comprende: medios para proveer un modelo de flujo de trabajo específico para la subrogación que incluye estados de flujo de trabajo entre organizaciones, transiciones, condiciones, estados e indicadores de acción; y además de medios para administrar el flujo de trabajo específico de la organización dentro del contexto del flujo de trabajo de la comunidad.
49. 49.- El sistema tal y como se describe la reivindicación 48, que además incluye medios para proveer información del estado en tiempo real a dichas organizaciones.
50. 50.- El método tal y como se describe ia reivindicación 48, que además incluye medios para la administración del flujo de trabajo específico de la organización con base en los 300 eventos en las condiciones de excepción dentro del flujo de trabajo.
51. 51.- Un método para optimizar y enriquecer una interacción entre un cliente y un servidor en comparación con un enfoque HTML, dicho método comprende: reducir el requerimiento de ancho de banda para la transmisión de datos entre un cliente y un servidor; reducir el número de interacciones requeridas entre un cliente y un servidor en un factor de dos o más; reduciendo el tiempo de respuesta como lo experimenta un usuario final que operan la máquina cliente; y reducir un número de ciclos de procesamiento requeridos por el servidor para la comunicación de la información de la aplicación entre un servidor y un cliente.
52. 52.- El método tal y como se describe en la reivindicación 51, que además incluye proveer la comunicación, de información estructurada y no estructurada desde y hacia el servidor.
53. 53.- El método tal y como se describe en la reivindicación 51, que además incluye, en comparación con un enfoque HTML basado en servidor, llevar a cabo un canal de comunicación basado en mensajes con un servidor que simplifica la construcción de una lógica de procesamiento que maneja cada mensaje.
54. 54.- El método tal y como se describe en la 301 reivindicación 51, que además incluye proveer múltiples canales de comunicación independientes y simultáneos con el servidor dentro de la misma sesión del usuario final.
55. 55. - El método tal y como se describe en la reivindicación 51, que además incluye dar soporte a una pluralidad de diversas implementaciones de buscador.
56. 56. - El método tal y como se describe la reivindicación 51, que además incluye la medición y grabación de un tiempo de respuesta real que experimenta un usuario final que opera la máquina cliente.
57. 57. - El método tal y como se describe la reivindicación 51, que además incluye la operación dentro de las restricciones de una arquitectura de cliente delgado básica.
58. 58. - Un sistema para optimizar y enriquecer una interacción entre un cliente y un servidor en comparación con un enfoque HTML, dicho sistema comprende: medios para reducir el requerimiento de ancho de banda para la transmisión de datos entre un cliente y un servidor; medios para reducir el número de interacciones requeridas entre un cliente y un servidor en un factor de dos o más; medios para reducir el tiempo de respuesta como lo experimenta un usuario final que operan la máquina cliente; y medios para reducir un número de ciclos de 302 procesamiento requeridos por el servidor para la comunicación de la información de la aplicación entre un servidor y un cliente.
59. 59. - El sistema tal y como se describe en la reivindicación 58, que además incluye proveer la comunicación, de información estructurada y no estructurada desde y hacia el servidor.
60. 60. - El sistema tal y como se describe en la reivindicación 58, que además incluye medios para llevar a cabo un canal de comunicación basado en mensajes con un servidor que simplifica la construcción de una lógica de procesamiento que maneja cada mensaje, en comparación con un enfoque HTML basado en servidor.
61. 61. - El sistema tal y como se describe en la reivindicación 58, que además incluye medios para proveer múltiples canales de comunicación independientes y simultáneos con el servidor dentro de la misma sesión del usuario final.
62. 62. - El esquema tal y como se describe en la reivindicación 58, que además incluye medios para dar soporte a una pluralidad de diversas implementaciones de buscador.
63. 63. - El sistema tal y como se describe la reivindicación 58, que además incluye medios para la medición y grabación de un tiempo de respuesta real que experimenta un usuario 303 final que opera la máquina cliente.
64. 64.- El sistema tal y como se describe la reivindicación 58, que además incluye medios para operar dentro de las restricciones de una arquitectura de cliente delgado básica.
65. 65.- Un método para determinar y mantener los estados de flujo de trabajo de un proceso/ transacción comercial que involucra múltiples partes independientes, dicho método comprende: definir dichos estados de flujo de trabajo y comunicar al menos uno de dichos estados de flujo de trabajo cuando lo demande cada una de las organizaciones dentro de la estructura genérica para un proceso/ transacción comercial específico; definir un o más objetivos determinación del flujo de trabajo válidos y mantener la información del estado relacionada con el avance hacia un objetivo de flujo de trabajo determinado; dar seguimiento al estado de una o más actividades que se producen de manera simultánea dentro de dicho proceso/ transacción comercial; mantener los datos del estado de manera independiente para cada una de las organizaciones involucradas dentro de dicho proceso/ transacción comercial; mantener datos para cada una de las actividades dentro de dicho proceso/ transacción comercial especificando 304 cuál de dichos organizaciones es la responsable de realizar la siguiente acción con relación a dicha actividad; y mantener una estructura determinista para todas las condiciones de flujo de trabajo válidas, estados y transiciones entre los estados relacionados con dicho proceso/ transacción comercial.
66. 66. - El método tal y como se describe en la reivindicación 65, que además incluye determinar un conjunto de operaciones válidas que se pueden realizar para llevar a cabo los cambios o transacciones del estado de flujo de trabajo en cualquier momento durante el proceso/ transacción comercial.
67. 67. - El método tal y como se describe la reivindicación 65, que además incluye hacer una diferencia entre una pluralidad de relaciones que cada una de las partes tiene con respecto a un proceso/ transacción comercial determinado con el propósito de determinar o mantener estados válidos en el flujo de trabajo.
68. 68. - El método tal y como se describe la reivindicación 65, que además incluye usar una implementación basada en parámetros que no requiere de una lógica de programación de procedimientos ni instrucciones específicas para el proceso/ transacción comercial.
69. 69. - Un sistema para determinar y mantener los estados de flujo de trabajo de un proceso/ transacción 305 comercial que involucra múltiples partes independientes, dicho sistema comprende: medios para definir dichos estados de flujo de trabajo y comunicar al menos uno de dichos estados de flujo de trabajo cuando lo demande cada una de las organizaciones dentro de la estructura genérica para un proceso/ transacción comercial específico ; medios para definir un o más objetivos determinación del flujo de trabajo válidos y mantener la información del estado relacionada con el avance hacia un objetivo de flujo de trabajo determinado; medios para dar seguimiento al estado de una o más actividades que se producen de manera simultánea dentro de dicho proceso/ transacción comercial; medios para mantener los datos del estado de manera independiente para cada una de las organizaciones involucradas dentro de dicho proceso/ transacción comercial; y medios para mantener datos para cada una de las actividades dentro de dicho proceso/ transacción comercial especificando cuál de dichos organizaciones es la responsable de realizar la siguiente acción con relación a dicha actividad; y medios para mantener una estructura determinista para todas las condiciones de flujo de trabajo válidas, estados y transiciones entre los estados. 306
70. 70. - El sistema tal y como se describe en la reivindicación 69, que además incluye medios para determinar un conjunto de operaciones válidas que se pueden realizar para llevar a cabo los cambios o transacciones del estado de flujo de trabajo en cualquier momento durante el proceso/ transacción comercial.
71. 71. - El sistema tal y como se describe la reivindicación 69, que además incluye hacer una diferencia entre una pluralidad de relaciones que cada una de dichas organizaciones tiene con respecto a un proceso/ transacción comercial determinado con el propósito de determinar o mantener estados válidos en el flujo de trabajo.
72. 72. - El sistema tal y como se describe la reivindicación 69, que además incluye una implementación basada en parámetros que no requiere de una lógica de programación de procedimientos ni instrucciones específicas para el proceso/ transacción comercial.
73. 73. - Un método para desarrollar un proceso/ transacción comercial que involucra múltiples partes independientes a través de una red electrónica, dicho método comprende: proveer al menos un archivo electrónico que puede contener información estructurada de y documentos de soporte no estructurados de tal forma que varias partes pueden tener acceso a ésta; 307 permití la entrada, a través de medios electrónicos de comunicación, de una o más de dichas múltiples partes a una o ambas partes de la información estructurada y dichos documentos de soporte a dicho archivo electrónico basado en reglas específicas de cada una de las partes; y permitir el acceso, a través de medios electrónicos de comunicación por una o más de dichas múltiples partes a uno o ambos de dicha información estructurada y dichos documentos de soporte no estructurados con base en reglas específicas de cada parte.
74. 74.- Un método para procesar una solicitud específica de una aplicación y generar una respuesta asociada, con base en la recepción de una solicitud de transacción basada en un mensaje que contiene una colección de objetos comerciales interrelacionados, dicho método comprende: proveer una estructura de procesamiento que no se basa en ningún formato de mensaje específico del sistema que lo origina; validar la identidad y la autoridad de un solicitante arbitrario que presenta solicitudes de transacción y, al hacer dicha validación, establecer un "contexto del solicitante" que se usa para validar las solicitudes de transacción; validar si se puede procesar una solicitud de transacción específica o no con base en el contexto del solicitante y, al hacer la validación, establecer un "contexto 308 de transacción" con base en la solicitud específica; asegurar que cualquier respuesta a la solicitud de la transacción contiene los objetos comerciales correctos y los atributos relacionados con base en un solicitante y el contexto de la transacción; asegurar que la porción de entrada de cualquier solicitud de transacción que resulte en la modificación de datos sólo contiene los objetos y atributos comerciales permitidos para- ser modificados con base en el solicitante y el contexto de la transacción; permitir la definición de una lógica de procesamiento específica de la aplicación sin tomar en cuenta los filtros de entrada o salida de los objetos y atributos que se indican mediante un solicitante y contexto de transacción específicos; asegurar que la solicitud de la transacción sólo puede acceder a los objetos de datos dentro de la base de datos permitidos con base en el solicitante específico y el contexto de transacción; soportar las solicitudes de transacción a partir de una pluralidad de sistemas de origen e interfaces, incluyendo, interfaces HTML en línea, segundo plano, interfaces electrónicas automatizadas y dispositivos inalámbricos; y además de habilitar los sistemas de solicitud autorizados para determinar de manera automática los tipos de solicitudes que se pueden presentar y sus estructuras 309 asociadas de solicitud/ respuesta.
75. 75. - El método tal y como se describe en la reivindicación 73, en donde dichas entradas permisivas incluyen introducir de manera automática documentos en papel recibidos a través de un fax o un digitalizador de alta velocidad en un archivo electrónico.
76. 76. - El método tal y como se describe en la reivindicación 73, en donde dichos medios electrónicos de comunicación comprenden una red y además incluyen el procesamiento de transacción comerciales a través de medios de comunicación electrónica para las partes conectadas a la red y las no conectadas a la red.
77. 77. - El método tal y como se describe en la reivindicación 73, que además incluye el establecimiento de funciones de reglas comerciales y auditorías que permiten que dicho al menos un archivo electrónico se audite electrónicamente con base en dichas reglas específicas de la parte.
78. 78. - El método tal y como se describe en la reivindicación 73, en donde dichas múltiples partes incluyen una parte principal, una contraparte y una o más partes de soporte/ facilitadoras que además incluye enrutar un archivo a la contraparte adecuada con base las reglas de enrutamiento de la contraparte.
79. 79.- El método tal y como se describe en la 310 reivindicación 78, en donde dicho enrutamiento incluye el uso de dicho algoritmo de enrutamiento que combina un índice específico de la parte principal y un algoritmo heurístico para determinar correctamente una contraparte adecuada y además un individuo o grupo específico dentro de dicha contraparte que manejará inicialmente el archivo.
80. 80. - El método tal y como se describe en la reivindicación 73, que además incluye medios para usar un modelo basado en el estado para administrar el flujo de trabajo entre las partes.
81. 81. - El método tal y como se describe en la reivindicación 73, que además incluye permitir las funciones del flujo de trabajo dentro de cada parte, incluyendo planes de acción de seguimiento y flujo de trabajo específico para cada parte.
82. 82. - El método tal y como se describe en la reivindicación 73, que además incluye proveer funciones de colaboración que permiten que las partes seleccionadas intercambien información usando dichos medios de comunicación electrónica.
83. 83. - El método tal y como se describe la reivindicación 73, que además incluye proveer una función de administración de documentos que permite que dichas múltiples partes actualicen anexos y administren las versiones de los documentos. 311
84. 84. - El método tal y como se describe en la reivindicación 73, en donde dichos medios de comunicación electrónica incluyen una red y además incluyen alertas de generación automática para las partes conectadas en red, para las condiciones de excepción o violaciones de las regias específicas de la parte mencionada.
85. 85. - El método tal y como se describe en la reivindicación 73, que además incluye la asignación selectiva de archivos seleccionados y provee acceso en línea a terceras partes, incluyendo proveedores de servicios externos.
86. 86. - El método tal y como se describe en la reivindicación 73, en donde dichos medios de comunicación electrónica incluyen una red, e incluyen la generación personalizada de informes de administración en línea.
87. 87. - El método tal y como se describe en la reivindicación 73, que además incluye la evaluación de la validez de una transacción comercial que incluye la realización de una auditoría electrónica para condiciones seleccionadas con base en parámetros que pueden ser configurados de la parte principal y una o más contrapartes, dichos parámetros que puede ser configurados incluyen, sin limitarse a esto, los elementos de datos o documentos requeridos/ opcionales.
88. 88.- El método tal y como se describe en la 312 reivindicación 73, que además incluye enrutar una transacción comercial determinada a las contrapartes usando un algoritmo de enrutamiento, que combina un algoritmo heurístico para determinar de manera correcta la identidad de la contraparte y enrutar las reglas definidas por la contraparte.
89. 89. - Un método para organizar y modelar información comercial específica de la aplicación que comprende: proveer entidades, atributos y relaciones específicas para el proceso comercial determinado; traducir los formatos de datos entrantes a un formato modelo de datos unificados; y mantener la consistencia en dicha traducción.
90. 90. - Un método para administrar el flujo de trabajo entre dos o más organizaciones dentro de un proceso comercial, dicho método comprende: proveer un modelo de flujo de trabajo específico del proceso que incluye estados del flujo de trabajo entre organizaciones, transiciones, condiciones, estados e indicadores de acción; y además de administrar el flujo de trabajo específico de la organización dentro del contexto del flujo de trabajo de la comunidad.
91. 91. - El método tal y como se describe la reivindicación 90, que además incluye proveer información del estado en 313 tiempo real a dichas organizaciones.
92. 92. - El método tal y como se describe la reivindicación 90, que además incluye la administración del flujo de trabajo específico de la organización con base en los eventos en las condiciones de excepción dentro del flujo de trabajo.
93. 93. - Un método para modelar las prácticas comerciales de cada miembro de una red, además para manejar las condiciones de excepción en el flujo de trabajo, dicho método comprende: permitir que dichos miembros configuren reglas comerciales específicas de la compañía; hacer auditorías a archivos basados en las reglas comerciales de todos los miembros involucrados en la transacción; y activar alertas como respuesta a las condiciones de excepción y a las violaciones de dichas reglas comerciales con base en los parámetros específicos de cada miembro.
94. 94. - El método tal y como se describe la reivindicación 93, en donde en dicha activación incluye activar una alerta a uno de dichos miembros con base en los parámetros de otro de los miembros mencionados.
95. 95. - Un sistema para desarrollar un proceso/ transacción comercial que involucra múltiples partes independientes a través de una red electrónica, dicho sistema comprende: 314 al menos un archivo de electrónico que puede contener información estructurada y documentos de soporte no estructurados de tal forma que varias partes pueden tener acceso a ésta; medios para permitir la entrada, a través de medios electrónicos de comunicación, por una o más de dichas múltiples partes de una o ambas partes de la información estructurada y documentos de soporte no estructurados a dicho expediente basado en reglas específicas de cada una de las partes; y medios para permitir el acceso, a través de medios electrónicos de comunicación por medio de una o más de dichas múltiples partes a uno o ambos de dicha información de reclamación estructurada y dichos documentos de soporte no estructurados con base en reglas específicas de cada parte.
96. 96.- Un sistema para procesar una solicitud específica de una aplicación y generar una respuesta asociada, con base en la recepción de una solicitud de transacción basada en un mensaje que contiene una colección de objetos comerciales interrelacionados, dicho sistema comprende: medios para proveer una estructura de procesamiento que no se basa en ningún formato de mensaje específico del sistema que lo origina; medios para validar la identidad y la autoridad de un 315 solicitante arbitrario que presenta solicitudes de transacción y, al hacer dicha validación, establecer un "contexto del solicitante" que se usa para validar las solicitudes de transacción; medios para validar si se puede procesar una solicitud de transacción específica o no con base en el contexto del solicitante y, al hacer la validación, establecer un "contexto de transacción" con base en la solicitud específica, medios para asegurar que cualquier respuesta a la solicitud de la transacción contiene los objetos comerciales correctos y los atributos relacionados con base en un solicitante y el contexto de la transacción; medios para asegurar que la porción de entrada de cualquier solicitud de transacción que resulte en la modificación de datos sólo contiene los objetos y atributos comerciales permitidos para ser modificados con base en el solicitante y el contexto de la transacción; medios para permitir la definición de una lógica de procesamiento específica de la aplicación sin tomar en cuenta los filtros de entrada o salida de los objetos y atributos que se indican mediante un solicitante y contexto de transacción específicos; medios para asegurar que la solicitud de la transacción sólo puede acceder a los objetos de datos dentro de la base de datos permitidos con base en el solicitante específico y el 316 contexto de transacción; medios para soportar las solicitudes de transacción a partir de una pluralidad de sistemas de origen e interfaces, incluyendo, interfaces HTML en línea, segundo plano, interfaces electrónicas automatizadas y dispositivos inalámbricos; y además de medios para habilitar los sistemas de solicitud autorizados para determinar de manera automática los tipos de solicitudes que se pueden presentar y sus estructuras asociadas de solicitud/ respuesta.
97. 97. - El sistema tal y como se describe en la reivindicación 95, en donde dichos medios para permitir la entrada incluyen medios para introducir de manera automática documentos en papel recibidos a través de un fax o un digitalizador de alta velocidad en un archivo electrónico.
98. 98. - El sistema tal y como se describe en la reivindicación 95, en donde dichos medios electrónicos de comunicación comprenden una red y además incluyen el procesamiento de transacción comerciales a través de medios de comunicación electrónica para las partes conectadas a la red y las no conectadas a la red.
99. 99. - El sistema tal y como se describe en la reivindicación 95, que además incluye métodos para establecer funciones de reglas comerciales y auditorías que permiten que dicho al menos un expediente electrónico se 317 audite electrónicamente con base en dichas reglas específicas de la parte.
100. 100. - El sistema tal y como se describe en la reivindicación 95, en donde dichas múltiples partes incluyen una parte principal, una contraparte y una o más partes de soporte/ facilitadoras que además incluye medios para enrutar un archivo a la contraparte adecuada con base las reglas de enrutamiento de la contraparte.
101. 101. - El método tal y como se describe en la reivindicación 100, en donde dicho enrutamiento incluye el uso de dicho algoritmo de enrutamiento que combina un índice específico de la parte principal y un algoritmo heurístico para determinar correctamente una contraparte adecuada y además un individuo o grupo específico dentro de dicha contraparte que manejará inicialmente el archivo.
102. 102. - El sistema tal y como se describe en la reivindicación 95, que además incluye medios para usar un modelo basado en el estado para administrar el flujo de trabajo entre las partes.
103. 103.- El sistema tal y como se describe en la reivindicación 95, que además incluye medios para permitir las funciones del flujo de trabajo dentro de cada parte, incluyendo planes de acción de seguimiento y flujo de trabajo específico para cada parte.
104. 104.- El sistema tal y como se describe en la 318 reivindicación 95, que además incluye medios para proveer funciones de colaboración que permiten que las partes seleccionadas intercambien información y negocien usando dichos medios de comunicación electrónica.
105. 105.- El sistema tal y como se describe la reivindicación 95, que además incluye medios para proveer una función de administración de documentos que permite que dichas múltiples partes actualicen anexos y administren las versiones de los documentos.
106. 106.- El sistema tal y como se describe en la reivindicación 95, en donde dichos medios de comunicación electrónica incluyen una red y además incluye medios para generar alertas de manera automática para las partes conectadas en red, para las condiciones de excepción o violaciones de las reglas específicas de la parte mencionada.
107. 107. - El sistema tal y como se describe en la reivindicación 95, que además incluye medios para la asignación selectiva de archivos seleccionados y provee acceso en línea a terceras partes, incluyendo árbitros, abogados, y proveedores de servicios externos.
108. 108. - El sistema tal y como se describe en la reivindicación 95, en donde dichos medios de comunicación electrónica incluyen una red, e incluyen la generación personalizada de informes de administración en línea.
109. 109.- El sistema tal y como se describe en la 319 reivindicación 95, que además incluye medios para evaluar la validez de una transacción comercial que incluye la realización de una auditoría electrónica para condiciones seleccionadas con base en parámetros que pueden ser configurados de la parte principal y una o más contrapartes, dichos parámetros que puede ser configurados incluyen, sin limitarse a esto, los elementos de datos o documentos requeridos/ opcionales.
110. 110. - El sistema tal y como se describe en la reivindicación 95, que además incluye medios para enrutar una transacción comercial determinada a las contrapartes usando un algoritmo de enrutamiento, que combina un algoritmo heurístico para determinar de manera correcta la identidad de la contraparte y enrutar las reglas definidas por la contraparte.
111. 111. - Un tema para organizar y modelar información comercial específica de la aplicación que comprende: proveer entidades, atributos y relaciones específicas para el proceso comercial determinado; traducir los formatos de datos entrantes a un formato modelo de datos unificados; y mantener la consistencia en dicha traducción.
112. 112. - Un sistema para administrar el flujo de trabajo entre dos o más organizaciones dentro de un proceso comercial, dicho sistema comprende: 320 proveer un modelo de flujo de trabajo específico del proceso que incluye estados del flujo de trabajo entre organizaciones, transiciones, condiciones, estados e indicadores de acción; y además de administrar el flujo de trabajo específico de la organización dentro del contexto del flujo de trabajo de la comunidad.
113. 113. - El sistema tal y como se describe la reivindicación 112, que además incluye medios para proveer información del estado en tiempo real a dichas organizaciones.
114. 114. - El sistema tal y como se describe la reivindicación 112, que además incluye medios para la administración del flujo de trabajo específico de la organización con base en los eventos en las condiciones de excepción dentro del flujo de trabajo.
115. 115. - Un sistema para modelar las prácticas comerciales de cada miembro de una red, además para manejar las condiciones de excepción en el flujo de trabajo, dicho sistema comprende: medios para permitir que dichos miembros configuren reglas comerciales específicas de la compañía; medios para hacer auditorías a archivos basados en las reglas comerciales de todos los miembros involucrados en la transacción; y 321 medios para activar alertas como respuesta a las condiciones de excepción y a las violaciones de dichas reglas comerciales con base en los parámetros específicos de cada miembro.
116. 116.- El sistema tal y como se describe la reivindicación 115, en donde en dichos medios para la activación incluyen activar una alerta a uno de dichos miembros con base en los parámetros de otro de los miembros mencionados.