¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Creación de aplicaciones de negocio de Office
Collapse the table of content
Expand the table of content

Creación de aplicaciones de negocio de Office

Febrero de 2007

Publicado: 26 de marzo de 2007

Microsoft Architect Journal
por Atanu Banerjee

Resumen: 2007 Microsoft Office System ofrece un conjunto de servidores, clientes y herramientas para que las empresas y los proveedores de software creen e implementen aplicaciones compuestas con mayor facilidad en toda la empresa. Estas soluciones, denominadas aplicaciones de negocio de Office (OBA, Office Business Applications), se pueden crear e implementar con rapidez; proporcionan a los usuarios finales amplias capacidades de personalización; son fáciles de modificar cuando lo requieran las necesidades de negocio; y se crean mediante las conocidas herramientas y aplicaciones de Microsoft Office. En este artículo se muestra cómo diseñar aplicaciones compuestas y cómo 2007 Microsoft Office System proporciona una buena plataforma (conocida por los usuarios finales) para crear dichas aplicaciones.

En esta página

Introducción Introducción
¿Qué son las aplicaciones compuestas? ¿Qué son las aplicaciones compuestas?
2007 Microsoft Office System como plataforma para crear aplicaciones compuestas 2007 Microsoft Office System como plataforma para crear aplicaciones compuestas
En qué medida las aplicaciones de negocio de Office son aplicaciones compuestas En qué medida las aplicaciones de negocio de Office son aplicaciones compuestas
Creación de una aplicación de negocio de Office Creación de una aplicación de negocio de Office
Creación de sitios SharePoint de departamentos para alojar documentos y procesos locales Creación de sitios SharePoint de departamentos para alojar documentos y procesos locales
Conclusión Conclusión
Acerca del autor Acerca del autor

Introducción

La globalización, la especialización y la contratación de recursos externos requieren que las personas trabajen con mayor colaboración que antes. Esta tendencia requiere un cambio pertinente en las herramientas que los trabajadores de la información usan para obtener una perspectiva, colaborar, tomar decisiones y tomar medidas. Hoy en día, la mayoría de las aplicaciones de negocio automatizan de manera eficaz las transacciones, pero no permiten una colaboración enriquecedora entre las distintas funciones. En consecuencia, los trabajadores de la información se ven obligados a usar herramientas de productividad personales para realizar las complejas interacciones necesarias para desempeñar sus tareas. Sin embargo, esto, a su vez, conduce a una pérdida en la productividad, ya que los usuarios están obligados a pasar de un conjunto de herramientas a otro, con frecuencia desplazándose manualmente por los datos mediante operaciones como, por ejemplo, cortar y pegar. Estas brechas entre las distintas aplicaciones de negocio y las herramientas de productividad deben estar vinculadas sin interrupciones y de un modo sincronizado y seguro para los trabajadores de la información.

Todavía no ha surgido una manera efectiva de habilitar la composición de aplicaciones de negocio que sea contextual, colaborativa, fácil de usar, basada en funciones y configurable para integrar tecnologías de otras plataformas necesarias para crear estas clases de aplicaciones compuestas. La facilidad de uso es importante, ya que la plataforma, las herramientas y la arquitectura para la composición no deben agregar una complejidad técnica excesiva que requiera un entrenamiento radical de las personas.

¿Qué son las aplicaciones compuestas?

Una aplicación compuesta es una colección de activos de software ensambladas para ofrecer una capacidad de negocio. Estos activos son artefactos que se pueden implementar de manera independiente, permiten la composición y aprovechan capacidades específicas de la plataforma.

Anteriormente, los activos de software de una empresa normalmente consistían en aplicaciones de negocio independientes que eran compactas y no se integraban bien entre sí. Sin embargo, para obtener las ventajas de negocio de la composición, una empresa debe tratar sus activos de software de manera más granular, y los distintos niveles de arquitectura requerirán activos variables de este tipo, como activos de presentación, aplicación y datos. Por ejemplo, un servicio web puede ser un activo de aplicación, un cubo de procesamiento analítico conectado (OLAP) puede ser un activo de datos y una pantalla de entrada de datos en particular puede ser un activo de presentación.

Un inventario de activos de software por sí mismo no habilita aplicaciones compuestas. Se requiere una plataforma con capacidades para la composición; es decir, una plataforma que ofrezca la capacidad para implementar activos tanto de manera independiente como combinados entre sí. En otras palabras, estos activos deben ser componentes y la plataforma debe proporcionar contenedores (figura 1).

Figura 1. Representación de alto nivel de una aplicación compuesta

Los contenedores que proporciona la plataforma deben ser de tipos diferentes y se asignan a distintos niveles de la arquitectura. Las arquitecturas empresariales suelen dividirse en tres niveles: la presentación, la aplicación (o lógica de negocios) y los datos. Por lo tanto, la plataforma debe proporcionar contenedores para ellos. Sin embargo, la arquitectura de tres niveles supone que los procesos y los datos de negocio están estructurados donde todos los requisitos son conocidos durante el proceso de diseño y creación del sistema. Por su naturaleza, las aplicaciones compuestas suponen que dicha composición de soluciones puede producirse una vez que se hayan creado e implementado los activos, por lo que deben representar explícitamente las interacciones entre personas entre los trabajadores de la información que son esenciales para completar cualquier proceso de negocio. Generalmente, los procesos estructurados o las aplicaciones de negocio tradicionales no capturan estas interacciones. Por lo tanto, es esencial agregar un cuarto nivel (nivel de productividad) para representar estas interacciones humanas. Esto se muestra en la figura 2.

Figura 2. Los cuatro niveles de una aplicación compuesta

Las discusiones tradicionales acerca de la arquitectura de las aplicaciones de negocio suelen centrarse en el nivel de aplicación como la conexión entre personas y datos. Sin embargo, normalmente el nivel de aplicación contiene la lógica de negocios estructurada y esto lleva a discusiones sobre las arquitecturas orientadas a servicios (SOA), los bus de servicio empresarial (ESB), las arquitecturas de componente de servicio (SCA) y la mayoría de las demás perspectivas arquitectónicas del sector actual, incluidas las discusiones de primera generación acerca de las aplicaciones compuestas. Sin embargo, la creación de una aplicación compuesta requiere que el arquitecto no sólo considere el nivel de productividad como un elemento esencial de la pila, sino que también reconozca que contiene el mayor valor de negocio.

Para ampliar la comparación entre aplicaciones compuestas y SOA: ambas tienen como objetivo la flexibilidad y la modularización. Sin embargo, las SOA ofrecen flexibilidad en un solo nivel: la lógica de negocios estructurada en el nivel intermedio. Las aplicaciones compuestas tienen como objetivo la flexibilidad en los cuatro niveles. Dicho esto, una aplicación compuesta es una excelente manera de extraer información de una SOA. Además, si las aplicaciones de línea de negocio (LOB) se presentan como servicios, será más fácil crear compatibilidad para procesos de funciones cruzadas en una aplicación compuesta.

Por lo tanto, para diseñar una aplicación compuesta, un arquitecto de soluciones debe:

  • Seleccionar una pila de composición. Elegir uno o varios contenedores de cada nivel y un conjunto de tipos de componente que se pueden implementar en dichos contenedores.

  • Seleccionar componentes. Definir el repositorio de activos que deben crearse a partir de este conjunto de tipos de componente, según las necesidades del negocio.

  • Especificar la aplicación compuesta. Definir cómo se conectarán dichos activos con el fin de ofrecer un proceso específico de funciones cruzadas. La plataforma debe permitir que estas conexiones se acoplen de manera flexible.

Tras la implementación, los usuarios tendrán la oportunidad de personalizar los activos y las conexiones, y la pila de composición debe permitir esto a través de mecanismos de acoplamiento y de ampliación flexibles.

2007 Microsoft Office System como plataforma para crear aplicaciones compuestas

2007 Microsoft Office System es un tipo de plataforma para crear aplicaciones compuestas, denominadas aplicaciones de negocio de Office (OBA, Office Business Applications).

Figura 3. Capacidades que ofrece 2007 Microsoft Office System

En qué medida las aplicaciones de negocio de Office son aplicaciones compuestas

Ahora examinemos cada uno de los niveles de la figura 2, así como los tipos de contenedores y de componentes que ofrece la plataforma.

Tabla 1. Capacidades de alto nivel de 2007 Microsoft Office System

Capacidad

Descripción

Sitio web y marco de seguridad

Un marco común para la creación de distintas clases de sitios, como por ejemplo, sitios de colaboración en equipo, portales de la intranet y sitios de Internet.

Formatos de archivo XML abiertos

Esto permite el procesamiento enriquecido de documentos en el servidor. Con versiones anteriores de Microsoft Office, el análisis del documento (por ejemplo, una hoja de cálculo) mediante el modelo de objetos de documento requería una sesión en memoria y en ejecución de la aplicación usada para crear el documento (por ejemplo, Excel).

IU extensible

Portal en el servidor que los usuarios pueden personalizar a partir de bloques de creación que los proveedores de soluciones pueden extender. Aplicaciones cliente que se pueden extender con Visual Studio Tools para Office.

Catálogo de datos de negocio

Repositorio de metadatos para definir las entidades de negocio almacenadas en almacenes de datos de servidor, diseñar las relaciones entre las entidades y definir las acciones permitidas en las entidades.

Búsqueda empresarial

Permite extraer datos desde distintos orígenes empresariales mediante búsquedas

Flujo de trabajo

Integrado con Workflow Foundation, permite alojar flujos de trabajo que representan interacciones entre personas y que vinculan elementos de la IU.

Administración de contenido empresarial

Permite administrar contenido diverso, con una topología para la administración web, de documentos y de registros. Admite la administración de ciclo de vida de documentos.

Inteligencia empresarial

Hojas de cálculo de Excel basadas en servidor más componentes de inteligencia empresarial (BI) (paneles, informes, elementos web) integradas en el portal y conectadas a SQL Server Analysis Services.

Comunicación y colaboración

Compatibilidad para comunicaciones unificadas integradas en la plataforma.

Composición en el nivel de presentación

El primer tipo de contenedor en el nivel de presentación es la aplicación cliente Microsoft Office (Excel, Word, Infopath). Estas aplicaciones son contenedores personalizables que ahora pueden extraer con mayor facilidad información y funcionalidad de aplicaciones LOB a través de paneles de tareas personalizados, cintas de opciones personalizadas y acciones que presentan a los usuarios datos y acciones en el contexto de su actividad actual. El tipo de componente que se puede alojar dentro de estos contenedores es el documento XML abierto. Se trata de la nueva representación XML para documentos de Microsoft Office, que permite un procesamiento enriquecido de servidor de la información almacenada en éste. Esto se muestra en la figura 4.

Figura 4. Las aplicaciones cliente Office son contenedores personalizables para contenido de XML abierto.

El segundo tipo de contenedor es un portal web, habilitado por Windows SharePoint Services (WSS) y Microsoft Office SharePoint Server (MOSS). WS v3.0 proporciona la jerarquía de contenedores siguiente, tal como se muestra en la figura 5:

  • Granja de servidores: instalación de uno o varios servidores web con carga equilibrada y servidores back-end con una base de datos de configuración.

  • Aplicación web: sitio web IIS, extendido para usar WSS, que puede alojar colecciones de sitios.

  • Colección de sitios: contenedor para sitios WSS, que existe dentro de una base de datos de contenido específica. Una colección de sitios contiene un sitio de primer nivel y sitios secundarios opcionales, y es la unidad de propiedad, capacidad de seguridad y recuperación.

  • Sitio: contenedor para sitios secundarios, páginas y contenido como, por ejemplo, listas y bibliotecas de documentos.

  • Página: contenedor para zonas de elementos web y elementos web.

  • Zona de elementos web: contenedor para elementos web.

  • Elemento web: componentes que muestran contenido en una página de manera modular y son el principal modo de personalización de páginas por parte de usuarios.

Figura 5. Contenedores proporcionados por Windows SharePoint Services

Si bien WSS admite la creación de colecciones de sitios para la colaboración en equipo, MOSS permite la funcionalidad del portal por encima de WSS con capacidades adicionales. Por ejemplo, MOSS incluye capacidades para búsquedas mejoradas, conectividad a almacenes de datos de negocio e inteligencia empresarial. Sin embargo, un portal MOSS es una colección de sitios WSS, por lo que es una jerarquía de sitios WSS. MOSS también incluye una galería de elementos web que contiene un amplio conjunto de elementos listos para usar, por ejemplo, para extraer hojas de cálculo y gráficos de Microsoft Office Excel. Los proveedores de soluciones también pueden ofrecer sus propios elementos web personalizados para una funcionalidad específica de la aplicación o del dominio, que puede cargarse en WSS. Los trabajadores de la información pueden personalizar las páginas agregando elementos web de la galería, eliminando elementos web de una página o reorganizando el diseño.

Composición en el nivel de productividad

2007 Microsoft Office System ofrece distintas maneras de compartir información y colaborar para su uso. Por ejemplo, el almacenamiento en el servidor proporciona contenedores para documentos en curso y otras clases de contenido heterogéneo con un control de versiones. Esto permite una colaboración en situaciones inesperadas o imprevistas. Es difícil capturar todas las complejas interacciones de personas en un sistema de administración de procesos de negocio (BPM), ya que el trabajo no suele realizarse según lo previsto. En arquitecturas tradicionales de tres niveles, existe poca compatibilidad para esto más allá del almacenamiento de documentos en tránsito en discos duros personales o servidores de correo electrónico y, a veces, puede resultar difícil decidir qué documento es la versión correcta. Sin embargo, 2007 Microsoft Office System puede configurar bibliotecas de documentos con versiones para almacenar documentos en las etapas intermedias de un proceso de negocio, lo que mejora la capacidad de administración, así como la probabilidad de una recuperación sin inconvenientes de eventos imprevistos. WSS ofrece los tipos de almacenamiento siguientes:

  • Lista: contenedor para elementos, que puede ser de tipos de lista integrados o de tipos de lista personalizados. Tradicionalmente, esto ha sido la unidad atómica de almacenamiento, pero ahora una lista puede almacenar enormes cantidades de datos, como por ejemplo, bases de datos de conocimientos o contenido web. Además, existe compatibilidad integrada para índices y consultas.

  • Biblioteca de documentos: tipos especiales de listas que admiten el control de versiones y el control de origen de documentos. Por ejemplo, los formularios de Infopath se pueden almacenar en bibliotecas de formularios, los informes en bibliotecas de informes y otros documentos en bibliotecas de documentos.

Figura 6. Arquitectura de SharePoint Workflow

Los trabajadores de la información pueden agregar bibliotecas de documentos y especificar plantillas de documento concretas para que las usen todos los documentos en dichas bibliotecas. Por ejemplo, un analista de negocio puede usar la herramienta de diseño WYSIWYG Infopath para crear un formulario y, a continuación, usar dicho formulario como plantilla para crear una biblioteca de formularios. Cuando un usuario cree un documento nuevo dentro de dicha biblioteca, se usará esta plantilla para crear un formulario vacío. 2007 Microsoft Office System también dispone de compatibilidad integrada en el servidor para Windows Workflow Foundation (WF). El motor de tiempo de ejecución de WF se aloja dentro de MOSS y actúa como un contenedor para la lógica de negocios que se puede asociar a elementos de trabajo y documentos en modo de flujos de trabajo. Estos flujos de trabajo se pueden asociar con listas, bibliotecas de documentos o tipos de contenido concretos. Se inician y finalizan mediante las acciones del usuario y se administran mediante listas de tareas WSS. Por ejemplo, las actividades de flujo de trabajo crean y actualizan elementos de tareas según sea necesario, y los usuarios pueden realizar un seguimiento del progreso del flujo de trabajo a través de tablas de historial. Las aplicaciones cliente de 2007 Microsoft Office también tienen en cuenta el flujo de trabajo. Se pueden usar para el inicio, la configuración y la finalización del flujo de trabajo, así como para la personalización ad hoc (reenvío o delegación).

Los flujos de trabajo se pueden asociar con listas, bibliotecas de documentos o tipos de contenido concretos. Estas asociaciones con plantillas WF se controlan en una tabla de asociaciones de flujos de trabajo en todo el conjunto de servidores. Las plantillas de WF se definen mediante metadatos XML y pueden incluir tanto ensamblados de flujos de trabajo como formularios. Por ejemplo, cuando un usuario crea una biblioteca de documentos, tiene la opción de asociar dicha biblioteca con un flujo de trabajo concreto y especificar las condiciones bajo las cuales se activa el flujo de trabajo (por ejemplo, es posible que se haya creado o modificado un documento en una biblioteca específica). Este flujo de trabajo puede admitir un proceso de negocio concreto o la administración del ciclo de vida de documentos.

La integración de 2007 Microsoft Office System con WF ofrece una variedad de ventajas (figura 7). Los procesos de negocio sencillos se pueden automatizar de modo que se integren perfectamente en la IU de Sharepoint. Los usuarios estarán equipados con capacidades de autoservicio, como por ejemplo, compatibilidad para una amplia variedad de escenarios de enrutamiento y seguimiento de documentos controlados por el usuario, de manera que se reducirá la participación del personal de TI a la hora de unir aplicaciones sencillas. WF también ofrece a los proveedores de soluciones verticales un punto de extensión para implementar sus propias reglas y lógica de negocios en los contenedores que proporciona 2007 Microsoft Office System.

Figura 7. Host de flujos de trabajo con WSS

Por último, el nivel de productividad también debe ofrecer una manera ligera de crear y publicar información e informes. 2007 Microsoft Office System admite esta capacidad que se integra en SQL Server Reporting Services y proporciona los componentes siguientes:

  • Centro de informes: una plantilla para crear sitios de creación de informes WSS.

  • Biblioteca de informes: una biblioteca de documentos con compatibilidad especial para almacenar informes.

  • Panel: una página WSS ensamblada a partir de elementos web de informes.

  • Visor de informes: elemento web para visualizar los informes de SQL Server Reporting Services.

  • Elemento web: permite la visualización de gráficos y tablas de Excel.

  • Elemento web y lista de indicadores clave de rendimiento (KPI): los trabajadores de la información tienen la opción de crear estadísticas de origen de varias maneras.

Se puede proporcionar a los usuarios un panel como una plantilla de informes basada en una función de negocio específica, como por ejemplo, ventas, marketing o administración de inventario.

Composición en el nivel de aplicación

Normalmente, la lógica de negocios estructurada reside dentro del nivel de aplicación. Se puede tratar de una aplicación LOB, como por ejemplo un sistema de planeamiento de recursos empresariales (ERP), o una orquestación entre varios sistemas, como por ejemplo un sistema BPM. El nivel de aplicación normalmente incluirá tanto sistemas de transacciones como sistemas de tomas de decisiones. Existen varias maneras en que las OBA pueden permitir la composición en el nivel de aplicación, así como para consumir servicios compuestos expuestos por otras tecnologías de plataforma (Microsoft y que no sean Microsoft).

El primer nivel de composición en el nivel de aplicación es a través de bibliotecas de actividades incluidas que se crean mediante Workflow Foundation y se implementan en 2007 Microsoft Office System. Anteriormente, se ha comentado cómo los flujos de trabajo pueden asociarse a listas, bibliotecas de documentos y tipos de contenido concretos. En la figura 7 se muestra cómo el tiempo de ejecución de WF proporciona un contenedor para actividades específicas de la aplicación que se incluyen e implementan como bibliotecas de actividades y encima de las cuales se ensamblan los flujos de trabajo.

El segundo nivel de composición en el nivel de aplicación que proporciona 2007 Microsoft Office System es a través de Excel Services. Éste es un motor de cálculo Excel en el servidor integrado en Sharepoint Server. Ofrece acceso de explorador a hojas de cálculo interactivas y en directo implementadas en el servidor, así como acceso de servicio web a cálculos de Office Excel en el servidor. Con Excel Services, los usuarios avanzados de Excel ahora pueden proporcionar una lógica de aplicación en el servidor que les resulte familiar. Esto significa que MOSS ahora es un contenedor para la lógica de aplicación, tal como se muestra en la figura 8.

Figura 8. Excel Services en 2007 Microsoft Office System

Una tercera manera para que las OBA permitan la composición en el nivel de aplicación es consumiendo servicios compuestos expuestos por otras tecnologías de plataforma. 2007 Microsoft Office System se puede integrar perfectamente en una arquitectura orientada a servicios. Si la empresa ya está desarrollando una red troncal de servicios, estas interfaces se pueden consumir desde 2007 Microsoft Office System. Esta operación se puede realizar de varias maneras. La primera implica la invocación de interfaces de servicio web en las actividades integradas en los flujos de trabajo implementados en el nivel de productividad. La segunda es a través del catálogo de datos profesionales (BDC), que se describe en la sección siguiente.

Composición en el nivel de datos

2007 Microsoft Office System también incluye un catálogo de datos profesionales (BDC) que se ejecuta dentro del servidor como un servicio compartido. Puede leer datos desde varios tipos de orígenes de datos (bases de datos, cubos de servicios de análisis y servicios web) y, a continuación, mostrarlos en el portal a través de tablas y listas de Sharepoint. Actúa como un repositorio de metadatos para las descripciones de entidades de datos de negocio y sus atributos, así como para asignar estas entidades de nuevo a los almacenes de datos de la empresa, tal como se muestra en la figura 9.

Figura 9. Catálogo de datos profesionales (BDC)

Si bien BDC no se puede usar para crear una entidad que se asigna a varios almacenes de datos, es posible definir las relaciones que vinculan las entidades, como por ejemplo, relaciones principal-secundario. Por consiguiente, BDC se puede usar para crear vinculaciones ligeras entre entidades de datos en toda la empresa, casi como un diccionario de sinónimos empresarial. Las entidades definidas por BDC a continuación se pueden volver a integrar en 2007 Microsoft Office System, por ejemplo, en listas de Sharepoint. De este modo, los usuarios pueden redactar páginas con vinculaciones a datos de servidor y pasar por tablas de datos siguiendo las relaciones entre las entidades.

Aunque BDC permite la composición de datos, proporciona acceso de sólo lectura a éstos. Sin embargo, los usuarios pueden usar BDC para diseñar las acciones que se pueden realizar en una entidad de datos, donde una acción se define mediante un nombre, una dirección URL y un conjunto de atributos a partir de la definición de la entidad que se debe devolver a dicha dirección URL. A continuación, ésta se puede usar dentro de un menú desplegable en una lista de Sharepoint. La dirección URL puede corresponder a un servicio web o a un documento en el servidor, por ejemplo, un formulario de Infopath, con código subyacente para rellenar previamente el formulario a partir del contexto que se pasa desde BDC. Los trabajadores de la información, a continuación, pueden usar el portal para crear aplicaciones ligeras en Sharepoint con tablas y listas que extraen datos y acciones de BDC.

Resumen de las capacidades para la composición

En la figura 10 se muestra cómo algunas de las capacidades de 2007 Microsoft Office System se asignan a los niveles de la figura 2. En la tabla 2 se proporciona una lista de los tipos de activos que son candidatos para la composición.

Figura 10. Capacidades de la plataforma de aplicación de 2007 Microsoft Office System asignada a niveles

Tabla 2. Lista de activos de aplicación para la composición

Documentos de XML abiertos

Paneles

Flujos de trabajo

Sitios

Actividades del negocio

Páginas

Reglas del negocio

Conexiones de datos

Esquemas

Autorizaciones

Estadísticas

Informes

Elementos web

Paneles

Creación de una aplicación de negocio de Office

La creación de un proceso de negocio estándar como una OBA consta de dos pasos.

  1. Crear un paquete de procesos, que contiene metadatos de proceso y componentes de aplicación en paquetes.

  2. Implementar el paquete de procesos en sistemas de producción. Ambos pasos se describen con detalle en la sección siguiente.

Creación de un paquete de procesos

  1. Para crear interfaces de usuario para procesos centrados en documentos en aplicaciones cliente de Microsoft Office, use Visual Studio Tools para Office (VSTO).

  2. Cree sitios WSS con elementos web específicos de la tarea, páginas, paneles, listas y bibliotecas de documentos, donde cada sitio esté diseñado para una función o un proceso de negocio concreto. Estos sitios se pueden usar para crear plantillas de sitio con el fin de incluir un proceso de negocio estándar en una solución OBA.

  3. Use Workflow Foundation para asociar listas y bibliotecas de documentos en los sitios con reglas en el servidor y lógica de negocios para el procesamiento de documentos en curso en el servidor. Incluya estos flujos de trabajo en ensamblados para su implementación.

  4. Defina puntos de conexión desde flujos de trabajo en la OBA hasta los sistemas LOB de servidor. Los metadatos del paquete de procesos deben incluir las interfaces de servicios web para esta integración. Las conexiones reales deberán realizarse durante la fase de implementación.

  5. Defina entidades BDC para las conexiones de datos necesarias para los procesos de funciones cruzadas integrados en la OBA.

  6. Agregue compatibilidad para la toma de decisiones definiendo las estadísticas, los informes, los paneles y los gráficos y tablas de Excel que los sitios WSS usarán.

  7. Incluya la solución como un paquete de procesos (plantillas de sitio WSS, ensamblados WF, documentos Office, etc.) usando los tipos de componente de la tabla 2.

Implementación del paquete de procesos en sistemas de producción

  1. Implemente sitios WSS en el servidor Sharepoint del sistema de producción.

  2. Configure conexiones desde flujos de trabajo hasta aplicaciones LOB mediante servicios web u otros adaptadores personalizados.

  3. Configure conexiones de datos conectando definiciones de entidades de datos BDC a almacenes de datos reales.

  4. Suminístrelo a los usuarios.

Implementación de una aplicación compuesta en la empresa

Una manera de implementar una OBA en la empresa puede ser la siguiente:

  1. Implemente sitios de Sharepoint en los niveles de departamento.

  2. Conecte varios departamentos.

  3. Conecte procesos de negocio a aplicaciones LOB.

  4. Agregue conexiones de datos para procesos de funciones cruzadas.

  5. Conecte procesos de negocio a sistemas "del perímetro".

Creación de sitios SharePoint de departamentos para alojar documentos y procesos locales

Los sitios de Sharepoint se deben configurar en el nivel de departamento para permitir la colaboración en equipo, tal como se muestra en la figura 11. Estos sitios tendrán bibliotecas de documentos para almacenar documentos en curso. Los trabajadores de la información del equipo tendrán sus propias páginas personalizadas, creadas a partir de las plantillas disponibles en el sitio del equipo.

Figura 11. Asignación de OBA en sitios de departamento para la colaboración en equipo, la coordinación de actividades con modelos de proceso de negocio y la conexión a sistemas LOB a través de una red troncal de servicios.

Tenga en cuenta que la figura 11 es una vista lógica de la arquitectura, ya que, normalmente, no todos estos sitios de departamento se estarían ejecutando en servidores independientes. Si no que, varios sitios se estarían ejecutando en un solo servidor de acuerdo con la figura 5, y la arquitectura física (es decir, el escenario de implementación para servidores Sharepoint) se seleccionaría según otros factores, como la carga, la disponibilidad y la dispersión geográfica de los equipos.

Los documentos en curso se almacenan en bibliotecas de documentos y se asocian con flujos de trabajo que se invocan cada vez que se crea o modifica un documento. Este flujo de trabajo puede ejecutar reglas de validación en los documentos; aplicar directivas de aprobación y acciones sobre los datos; limpiar, validar o filtrar los datos que contiene; o actualizar los sistemas de servidor.

Además de los flujos de trabajo de los procesos de negocio, los documentos en curso están sometidos a un ciclo de vida propio, desde la redacción y la colaboración hasta la administración y la publicación, pasando por el archivado o la destrucción. Es posible establecer la activación de un flujo de trabajo adecuado, como por ejemplo, la administración del proceso de archivado, siempre que un documento alcance una de estas etapas intermedias.

Conexión a varios departamentos

Según se indica en la figura 11, los modelos de proceso de negocio coordinan las actividades tanto dentro de un equipo como entre departamentos. Dentro de un departamento, los procesos de negocio se pueden diseñar mediante actividades de WF, que se implementan en el servidor Sharepoint que se usa en dicho departamento. La coordinación de actividades entre departamentos se puede efectuar mediante procesos de colaboración que administran el ciclo de vida de entidades de negocio individuales (administrar pagos).

Los procesos de negocio entre departamentos se pueden ubicar de manera centralizada en centros de datos de TI o más próximos a los trabajadores de la información dentro de los servidores de departamentos. Por ejemplo, los flujos de trabajo de larga duración que se ejecutan de manera centralizada pueden ejecutarse en Microsoft BizTalk Server, mientras que los procesos de departamentos se pueden ejecutar en flujos de trabajo de WF dentro del servidor Sharepoint.

Conexión de procesos de negocio a aplicaciones de línea de negocio

La orientación al servicio es una de las maneras de presentar aplicaciones de negocio actuales en una OBA.

En ese sentido, SOA fomenta la modularización (requisito básico para la composición) y es una solución complementaria. Esto permite el ensamblado de aplicaciones empresariales de funciones cruzadas que van más allá de los límites de las aplicaciones actuales.

SOA no es la única manera de conectar LOB a OBA. Una red troncal de servicios también se puede presentar usando otras tecnologías de integración, como por ejemplo, adaptadores personalizados.

Adición de conexiones de datos para procesos de funciones cruzadas

El BDC (figura 9) se puede usar para conectar almacenes de datos back-end a 2007 Microsoft Office System mostrando los datos en elementos web y listas de Sharepoint. Esto permite crear aplicaciones compuestas para procesos de funciones cruzadas en el portal de Sharepoint, usando una combinación de BDC, listas de Sharepoint y el flujo de trabajo. Por ejemplo, el BDC se puede usar para definir las entidades que tienen una relación principal-secundario (por ejemplo, detalles de encabezado y pedido) y las listas de Sharepoint las pueden mostrar. Siguiendo las relaciones principal-secundario, es posible explorar en profundidad la lista que muestra información de encabezado hasta la información detallada correspondiente. Además, las acciones se pueden diseñar en metadatos BDC, lo que significa que éstos se muestran como elementos de menú en la lista de Sharepoint y la selección de un elemento desplegable desde este menú hará que el contexto de la fila seleccionada se pase a la dirección URL definida para la acción.

Conexión de procesos de negocio a sistemas perimetrales

Con frecuencia, el ámbito de una OBA no se incluye dentro de una organización. Por ejemplo, una OBA puede admitir un proceso de negocio que necesita consumir un servicio ofrecido por un proveedor host (situación tipo "software como un servicio" [SaaS]). De forma alternativa, es posible que la OBA necesite admitir un proceso de negocio que ofrezca un servicio a otra organización. Esto es especialmente habitual en escenarios de administración de la cadena de suministro, en las que están implicados socios comerciales. Aquí, debe haber una manera de transferir documentos desde un trabajador de la información a un colega en la organización del socio comercial. Este proceso debe ser seguro, confiable, asincrónico y transparente.

En la figura 12 se muestra una manera de unir una arquitectura de un extremo a otro para este proceso. Se han establecido brokers de mensajes en el extremo de la organización para enviar y recibir mensajes y documentos de los socios comerciales. Es posible que los mensajes de diferentes socios comerciales se reciban en varios formatos y que se entreguen a través de varios canales, como por ejemplo, servicios web, EDI, correo electrónico, RosettaNet, etc. Además, los mensajes se pueden intercambiar en una variedad de patrones diferentes: mensajería unidireccional, bidireccional asincrónica o bidireccional sincrónica. Estos brokers de mensajes deben atender todas las combinaciones de patrones de intercambio de mensajes y formatos de mensaje.

Figura 12. Conexión de la OBA a sistemas "del perímetro"

Una vez que el broker de mensajes ha recibido el mensaje, se procesa en el formato canónico singular necesario para los servicios de flujo descendente y el mensaje transformado se envía a una cola de mensajes para desacoplar los procesos públicos de los privados. A continuación, el mensaje se recupera de la cola mediante un servicio de enrutamiento que examina el mensaje y lo dirige al destinatario correspondiente. Pero, antes de que el documento alcance su destinatario, es posible que un servicio de aplicaciones empresariales, como por ejemplo aplicaciones LOB u orquestaciones BPM, necesiten preprocesarlo. Es posible también que se apliquen reglas de negocio con el fin de garantizar la validez y aplicar las políticas empresariales. El resultado de todo este procesamiento es un documento que puede ser procesado por un humano con información suficiente como para tomar una decisión rápidamente. Por ejemplo, una solicitud de pedido de compra de un cliente se puede introducir en un servicio de cumplimiento de pedidos y la respuesta de este servicio se puede usar para generar un documento XML que corresponda a un formulario de Infopath con una confirmación de pedido de compra candidato. A continuación, este formulario generado se puede colocar en una biblioteca de formularios de Sharepoint para que un trabajador de la información en el departamento de ventas lo apruebe.

Una vez que el trabajador de la información ha revisado la confirmación propuesta y realizado los cambios necesarios, envía el formulario. De esta forma se inicia el flujo de trabajo para el trayecto de vuelta, que actualiza los sistemas LOB y, a continuación, publica la información del formulario como un documento XML en una cola para mensajes salientes como respuesta a la solicitud original. A continuación, el agente de mensajes realiza una nueva conversión al formato usado por el socio comercial.

Existen varias formas de implementar los brokers de mensajes en el perímetro, por ejemplo, mediante BizTalk Server. Éste proporciona una solución escalable y administrable que también incluye aceleradores y adaptadores basados en estándares, como por ejemplo, el acelerador RosettaNet para la colaboración con socios comerciales. Las colas que desacoplan procesos internos y externos se pueden implementar mediante Microsoft SQL Service Broker 2005.

Ejemplo de aplicación de negocio de Office

Con el fin de ofrecer recursos técnicos y una orientación para la creación de OBA con un valor de negocio significativo, diríjase aquí para obtener una implementación de referencia de una OBA. Este paquete de aplicaciones de referencia para la administración de la cadena de suministro trata escenarios de colaboración entre los distintos niveles de una cadena de suministro de varios niveles.

Conclusión

2007 Microsoft Office System ofrece un conjunto eficaz de capacidades para crear aplicaciones compuestas, que se denominan aplicaciones de negocio de Office (OBA, Office Business Applications). De esta forma se habilitan soluciones de funciones cruzadas que proporcionan una interfaz de usuario compuesta que presenta las funciones y las capacidades de negocio en un conjunto heterogéneo de activos de TI de servidor. Estas soluciones también ofrecen capacidades de negocio de colaboración, que reducen las diferencias entre las aplicaciones de negocio tradicionales y las herramientas de productividad personal.

Acerca del autor

Atanu Banerjee es un arquitecto del equipo de estrategia de arquitectura de Microsoft. Tiene 10 años de experiencia en el sector de software y anteriormente trabajó en soluciones para la administración de la cadena de suministro y el control de procesos avanzados. Se unió a Microsoft después de trabajar en i2 Technologies, donde era arquitecto principal para la línea de productos de administración de oferta y demanda. Antes de eso, trabajó en el grupo de sistemas de control avanzado de Aspen Technologies. Obtuvo un Doctorado en Georgia Tec en 1996 y es licenciado por IIT Delhi, India.

Mostrar:
© 2015 Microsoft