Development

Windows WorkFlow Foundation – Part II

Runtime Hosting

Todos los workflows dependen del Windows Workflow Foundation Runtime Engine. Este motor ejecuta cada workflow y maneja su estado a lo largo de su tiempo de vida. El Windows Workflow Foundation Runtime es una librería; por lo tanto, debe ser ejecutado en algún proceso host. En vez de proveer un host requerido, Windows Workflow Foundation le permite al runtime (y a cualquier workflow que ejecute) ser alojado en cualquier proceso Windows, desde una simple aplicación de consola de Windows o una aplicación de formulario, hasta un servidor complejo diseñado teniendo en cuenta el ambiente de workflow.

Windows Workflow Foundation cuenta con un conjunto de servicios que le permiten al runtime ejecutarse dentro de ASP.NET, aunque los vendedores independientes de software y los usuarios finales son libres de crear sus propias aplicaciones contenedoras de workflows para aplicaciones existentes.

Los diferentes hosts tendrán distintas características. Por ejemplo, un workflow que se ejecuta en un escritorio en una simple aplicación de Windows Forms, será menos escalable y menos confiable que un workflow hosteado en Windows SharePoint Services (WSS) o BizTalk Server.

A pesar de que cada host usa el mismo Runtime Engine, cada uno debe proveer un conjunto de servicios runtime. Estos servicios brindan soporte para persistir el estado de un workflow, rastrear su ejecución, usar transacciones, etc.  

Windows Workflow Foundation provee una implementación predeterminada para todos estos servicios que pueden ser usados por cualquier host. Para darse una idea de cómo trabaja el runtime de Windows Workflow Foundation con los servicios proporcionados por el host, se debe pensar en los aspectos fundamentales de un workflow.

Un workflow puede ser de larga duración, ya que podría ejecutarse durante horas, días o semanas, y el runtime de Windows Workflow Foundation podría apagarse durante un workflow, y persistentemente almacenaría su estado si hubiera estado inactivo por un período de tiempo.

La decisión de descargar el workflow se puede lanzar porque éste se encuentra bloqueado esperando un evento externo; esta decisión es tomada típicamente por el runtime. Para escribir estados del workflow en el disco, el runtime depende del servicio de persistencia proporcionado por su proceso host.

El host basado en ASP.NET que contiene Windows Workflow Foundation depende de Microsoft SQL Server para la persistencia. Otro host podría preferir persistir workflows usando otra tecnología, como, por ejemplo, una base de datos propietaria utilizada por una aplicación de un vendedor de software independiente.

Cualesquiera que sean los servicios que proporciona el host, las bases de hosting del Windows Workflow Foundation Runtime son muy simples. Una vez que una instancia es creada, puede ser inicializada llamando a su método StartRuntime. El proceso host es una parte importante del ambiente en el que se ejecuta un workflow, ya que el runtime puede ser contenido en un rango de procesos de Windows. Asimismo, los workflows de Windows Workflow Foundation pueden ser usados en una variedad de escenarios.

Workflow Runtime Events

Los eventos workflow son procesados por el Workflow Runtime a través de los delegados de manejo de eventos. Estos eventos son generados/levantados por el Workflow Runtime y no por el Workflow Instance. Asimismo, tampoco son modelados como parte de la definición de workflow.

El Workflow Runtime levanta eventos en tiempo de ejecución para instancias workflow.

Los eventos mandados por el Workflow Runtime contienen un objeto de tipo WorkflowId, que corresponde al workflow que generó el evento.

Provee un mecanismo para mantener el paso del ciclo de vida de las instancias de workflow:

WorkflowCreated, WorkflowCompleted, etc

Provee un mecanismo para seguir todas las instancias de workflow, ya que los workflows pueden ser:

Ø  Creados

Ø  Abortados

Ø  Terminados

Ø  Etc.

La clase WorkflowRuntime expone la funcionalidad requerida por una aplicación host, y servicios para configurar y controlar el runtime.

public class WorkflowRuntime : IServiceProvider, IDisposable

El namespace System.Workflow.Runtime contiene clases e interfaces que se pueden usar para controlar el runtime de workflow y la ejecución de una instancia workflow.

El namespace System.Workflow.Runtime contiene la clase WorkflowRuntime, que usted puede usar para configurar, controlar y suscribir a eventos para el runtime de workflow asociado con su dominio de aplicación. La clase WorkflowInstance provee un proxy para cada instancia workflow y le deja controlar la ejecución de un workflow. Además de estas clases, varias clases que tienen que ver con las colas de eventos workflow y con excepciones lanzadas por el runtime de workflow son contenidas en este namespace

CorrelationProperty: representa el nombre de la propiedad y el valor usado en un conjunto de correlación que maneje el tiempo de vida de la transacción entre un mensaje y un workflow.

CorrelationToken: maneja las suscripciones de la CorrelationProperty a las actividades del dueño. Esta clase no puede ser heredada.

Runtime Services

Windows Workflow Foundation provee distintos servicios que se pueden usar para manejar hilos de instancias workflow, trabajos batch a través de transacciones, persistencia de instancias workflow a un medio de almacenamiento para ser recuperadas más tarde, y el rastreo de ejecuciones de instancias workflow.

El runtime de workflow usa muchos servicios cuando una instancia de workflow se ejecuta. Estos componentes del servicio son “enchufables”, lo que les permite a las aplicaciones proveer servicios de maneras que son únicas a su ambiente de ejecución.

Windows Workflow Foundation provee implementaciones predeterminadas de los servicios del runtime que cumplen las necesidades de varios tipos de aplicaciones. Por ejemplo, estos componentes determinan el modelo de programación que es usado para correr instancias workflow, cómo se comunican el workflow y la aplicación host, cómo monitorear y rastrear su workflow, y demás.

Windows Workflow Scheduling Services

Los servicios Windows Workflow Scheduling controlan el modo en que las instancias workflow son programadas por el runtime de workflow, ya sean manejadas de una manera asincrónica a través del DefaultWorkflowSchedulerService, o manual, de manera sincrónica, a través del ManualWorkflowSchedulerService.

wwf_SchedulingServices

DefaultWorkflowSchedulerService es usado por el runtime de workflow por default. Crea y maneja los hilos que ejecutan las instancias workflow de una manera asincrónica en el runtime del workflow. Los workflows que están esperando para ejecutarse son almacenados en la cola interna del DefaultWorkflowSchedulerService. Cuando el DefaultWorkflowSchedulerService quiere empezar un workflow, un hilo es adquirido del thread pool del framework de .NET y es usado para correr el workflow. La propiedad MaxSimultaneousWorkflows determina qué cantidad de hilos simultáneos permitirá el servicio scheduler en un tiempo. Si el límite es cuatro, por ejemplo, el DefaultWorkflowSchedulerService adquirirá hasta cuatro hilos del thread pool del framework de .NET para ejecutar los workflows. Si cuatro workflows se están ejecutando actualmente, ítems adicionales de trabajo (workflows) son colocados en la cola y eventualmente ejecutados a medida que los hilos se van habilitando.

ManualWorkflowSchedulerService controla el número de hilos que aparecen en un proceso ASP.NET reutilizando el hilo que hizo la petición ASP.NET Web para correr la instancia workflow. Esto asegura que en cualquier momento, el número de hilos activos en el runtime de workflow iguale el número de peticiones Web activas en el proceso activo de ASP.NET.

ManualWorkflowSchedulerService no ejecuta automáticamente una instancia workflow que esté en la cola. El host debe invocar al RunWorkflow para ejecutar un workflow específico.

El ManualWorkflowSchedulerService provee un servicio de threading que le permite a la aplicación host que crea una instancia workflow donar el thread en el cual la instancia workflow es ejecutada. Usando este servicio de threading, las aplicaciones host pueden correr una instancia workflow en un simple thread (eso es, en modo sincrónico).

Windows Workflow CommitWorkBatch Services

El propósito de los servicios CommitWorkBatch es permitir una lógica personalizada a pesar de la comisión de batches de trabajo (también conocida como puntos persistentes). Cuando un trabajo batch es cumplido, el runtime llama al servicio CommitWorkBatch y pasa un delegado para que llame a hacer el cumplimiento del batch de trabajo. Igualmente, el runtime debe hacer el finalizado, pero permitiéndole a un servicio insertarse a sí mismo dentro de un proceso, lo que permite una personalización alrededor del proceso de finalización.

Existen dos tipos de CommitWorkBatch Services:

Ø  DefaultWorkflowCommitWorkBatch Service

Ø  SharedConnectionWorkflowBatch Service

DefaultWorkflowCommitWorkBatch Service

La razón principal de este tipo de servicios es permitir una lógica de manejo de errores personalizada. Si el servicio DefaultWorkflowCommitWorkBatchService posee la transacción, porque creó una, cuando Current retorna null (Nothing en Visual Basic), puede llamar al delegado más de una vez, creando una nueva transacción para cada llamada. El ejemplo más común de esto es manejar problemas de red intermitentes o cluster failovers de SQL. Si la llamada al CommitWorkBatchCallback tira una excepción, WorkflowCommitWorkBatchService puede atrapar esta excepción, empezar una nueva transacción, y llamar al delegado nuevamente. Esto da un nivel de resistencia a la ejecución de instancias workflow que de otra manera causaría que los workflows se terminaran.

SharedConnectionWorkflowCommitWorkBatch Service

Cuando el motor del runtime es iniciado, la clase WorkflowRuntime crea un objeto DefaultWorkflowCommitWorkBatch Service si ningún otro servicio WorkflowCommitWorkBatch fue agregado. Se puede usar este servicio en el workflow para soportar batches de trabajo que son necesarios para la integridad de datos.

También se puede decidir utilizar el servicio SharedConnectionWorkflowCommitWorkBatchService. Este servicio es usado para transacciones de bases de datos que utilizan una conexión compartida entre objetos diferentes.

static void Main(string[] args)

{

    string connectionString = " Initial Catalog=WorkflowDataStore;Data          Source=localhost;Integrated Security=SSPI;";

    WorkflowRuntime workflowRuntime = new WorkflowRuntime();

    workflowRuntime.AddService(new SharedConnectionWorkflowCommitWorkBatchService(connectionString));

    workflowRuntime.StartRuntime();

   // … workflowRuntime.StopRuntime();

}

Para utilizar el servicio SharedConnectionWorkflowCommitWorkBatchService en vez del servicio DefaultWorkflowCommitWorkBatchService en la instancia WorkflowRuntime, se puede usar el método AddService, como se muestra en el ejemplo. El parámetro para el constructor SharedConnectionWorkflowCommitWorkBatchService es el string de conexión a la base de datos.

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <configSections>

    <section name="WorkflowServiceContainer" type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>      

  </configSections>

  <WorkflowServiceContainer Name="Container Name" UnloadOnIdle="true">

    <CommonParameters>

      <add name="ConnectionString" value="Initial Catalog=WorkFlowStore;Data Source=localhost;Integrated Security=SSPI;" />

    </CommonParameters>

    <Services>

      <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      <add type="System.Workflow.Runtime.Hosting.SharedConnectionWorkflowTransactionService, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      <add type="System.Workflow.Runtime.Tracking.SqlTrackingService, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

      <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

    </Services>

  </WorkflowServiceContainer>

  <system.diagnostics> </system.diagnostics>

</configuration>

También se puede usar el archivo de configuración de la aplicación para crear el objeto SharedConnectionWorkflowCommitWorkBatchService. Cuando se hace eso, hay que agregar la información del string de conexión a la sección CommonParameters del archivo app.config. El ejemplo muestra un archivo de configuración de la aplicación que usa el servicio SharedConnectionWorkflowCommitWorkBatchService.

Jonnathan De La Barra Hot

Business Intelligence

Microsoft SQL Server 2005 Reporting Services – Part II

Implementación y administración 

Configuración de Reporting Services. Se debe implementar y mantener un Report Server existente mediante una interfaz gráfica de usuario para configurar service accounts, virtual directories, report server database, claves de cifrado e implementación de conjuntos de Web Servers.

Administrador de reportes. Se debe configurar seguridad basada en Roles y administrar el contenido del Report Server mediante el establecimiento de propiedades en orígenes de datos, reportes, carpetas, recursos y modelos de informe. Se puede configurar la ejecución de reportes y el historial del informe, y establecer límites sobre el tiempo de procesamiento (Report Execution Timeout); supervisar y cancelar reportes pendientes o en curso; y crear y administrar conexiones de orígenes de datos y programaciones independientemente de los reportes a los que están asociadas.

Integración con las tools SQL Server Management Studio, SQL Server Configuration Manager y SQL Server Surface Area Configuration. Los administradores del Report Server pueden utilizar las herramientas que se suministran con SQL Server 2005 para administrar una instalación de Reporting Services. Pueden registrar secuencias de comandos en Management Studio para reproducir tareas de mantenimiento de rutina en otros servidores de reportes.

Seguridad basada en roles. Se debe utilizar la seguridad basada en roles para controlar el acceso a carpetas, reportes y recursos. La configuración de seguridad sigue un patrón de herencia en la estructura de carpetas. Puede modificar la seguridad en cualquier rama para cambiar la definición de acceso al nivel de elemento de los usuarios.

 

Características de acceso y entrega de reportes

 

Acceso a petición mediante conexiones Web. Se puede utilizar un browser para desplazarse por una jerarquía de carpetas a fin de buscar y trabajar con reportes y otros elementos. Se puede hacer referencia a los reportes desde la lista Favoritos del Web Browser crear un vínculo desde un portal Web.

SharePoint Web Part. Reporting Services proporciona dos Web Parts para ver reportes y desplazarse por carpetas del Report Server. Se puede incrustar las Web Parts en el sitio Microsoft SharePoint Portal para integrarlas fácilmente con una implementación del Report Server.

Mis reportes y Mis suscripciones. En el Report Manager, se pueden almacenar y administrar reportes y suscripciones en un área de trabajo personal.

Suscripciones para entrega por e-mail o a recursos compartidos de archivos. Se puede entregar reportes automáticamente mediante una suscripción estándar y establecer preferencias de presentación de reportes. Los usuarios que deseen ver un informe en Microsoft Excel, por ejemplo, pueden especificar este formato en una suscripción. Se puede entregar un informe representado en una bandeja de entrada de e-mail. Para ello se deben establecer las opciones de entrega que controlan si el informe se entrega como vínculo o como datos adjuntos. Se debe entregar un informe representado en una carpeta compartida, estableciendo las opciones de entrega que controlan si el informe se sobrescribe o se agrega a una carpeta existente.

Suscripciones controladas por datos. La distribución de reportes se automatiza mediante suscripciones controladas por datos, que generan una lista de destinatarios e instrucciones de entrega en tiempo de ejecución desde un origen de datos externo. Utilizando una consulta e información de asignación de columnas para personalizar la salida del informe para un número elevado de usuarios.

 

Programación y extensibilidad 

 

Lenguaje RDL (Report Definition Language). RDL describe todos los elementos posibles de un informe mediante una gramática XML que se valida con un esquema XML. La definición de un informe concreto se basa en el lenguaje RDL y contiene instrucciones para representar el diseño en tiempo de ejecución. RDL es extensible. Puede agregar compatibilidad con elementos o características que no se encuentren en el esquema RDL existente y, a continuación, generar herramientas personalizadas y extensiones de representación de reportes para controlar las características que cree.

API de SOAP. Los métodos del Web Service del Report Server se pueden utilizar para obtener acceso mediante programación a un servidor de reportes y al servicio Web del servidor de reportes.

Acceso mediante direcciones URL. Se puede tener acceso a elementos del Report Server mediante cadenas de direcciones URL con parámetros. Todos los reportes y los elementos almacenados en un Report Server pueden tener direcciones del espacio de nombres del Report Server.

Proveedor WMI. Reporting Services incluye un proveedor de Instrumental de administración de Windows (WMI) que se puede utilizar para administrar el servicio de Windows del Report Server.

Entrega extensible, procesamiento de datos, representación, seguridad y procesamiento de reportes. Se pueden crear extensiones de entrega personalizadas para enrutar reportes a recursos compartidos de archivos, almacenes de archivo internos o aplicaciones internas. Se puede ampliar el procesamiento de datos para consultar, convertir o transformar datos procedentes de nuevos tipos de orígenes de datos. Se puede crear extensiones de representación personalizadas para admitir la representación de reportes con formatos de aplicación o formatos orientados a Web que no se proporcionan con el producto. Se puede generar o integrar una extensión de seguridad que proporcione una alternativa al modelo de autenticación de Windows.

Arquitectura del SQL Server Reporting Server

SQL Server Reporting Services es un conjunto de componentes de procesamiento, herramientas e interfaces de programación que permiten el desarrollo y la utilización de reportes completos en un entorno administrado. El conjunto de herramientas incluye herramientas de desarrollo, de configuración y de administración así como herramientas de visualización de reportes. Las interfaces de programación incluyen el protocolo simple de acceso a objetos (SOAP), los extremos de direcciones URL e Instrumental de administración de Windows (WMI), para permitir una fácil integración con aplicaciones y portales nuevos o existentes. 

El procesamiento se distribuye en múltiples componentes. Para recuperar datos, procesar el diseño de los reportes, representar los formatos de presentación y entregar en destinos específicos se utilizan procesadores centralizados y especializados. El procesamiento de una presentación tiene lugar después de recuperar los datos y es independiente del procesamiento de los datos, lo que permite a diversos usuarios consultar el mismo informe simultáneamente en formatos diseñados para distintos servicios o cambiar inmediatamente el formato de visualización del informe, de HTML a PDF, a Microsoft Excel o a XML, con un solo clic. La arquitectura modular se ha diseñado para permitir ampliaciones. Los programadores pueden incluir funciones de reportes en aplicaciones personalizadas o ampliar la funcionalidad para hacerla compatible con características personalizadas.

El diagrama siguiente muestra los componentes y las herramientas de Reporting Services. El diagrama también muestra cómo se adaptan las herramientas personalizadas al diseño global. Presenta el flujo de solicitudes y datos entre componentes del servidor y los componentes que envían y recuperan contenido de un almacén de datos.

Diagrama de la arquitectura de Reporting Services

SSRS_architecture
 

El Report Server se implementa como un servicio de Microsoft Windows y como un servicio Web que proporciona una infraestructura de procesamiento optimizada y en paralelo para el procesamiento y la representación de reportes. El servicio Web presenta un conjunto de interfaces de programación que las aplicaciones cliente pueden utilizar para obtener acceso a servidores de reportes. El servicio de Windows proporciona servicios de inicialización, programación y entrega, así como mantenimiento del servidor. Los servicios funcionan conjuntamente y constituyen una única instancia del servidor de reportes.

A través de sus subcomponentes, el Report Server procesa solicitudes de reportes y permite que los reportes estén disponibles para el acceso a petición o la distribución programada. Los subcomponentes del Report Server incluyen procesadores y extensiones. Los procesadores son el concentrador del Report Server. Los procesadores admiten la integridad del sistema de reportes y no se pueden modificar ni ampliar. Las extensiones también son procesadores, pero realizan funciones muy específicas. Reporting Services incluye una o varias extensiones predeterminadas para cada tipo de extensión que se admite. Los programadores de otros fabricantes pueden crear extensiones adicionales para reemplazar o ampliar la capacidad de procesamiento del Report Server.

Procesadores

El Report Server incluye dos procesadores que realizan el procesamiento de reportes previo e intermedio, así como operaciones programadas y de entrega. El Procesador de reportes recupera la definición o el modelo de informe, combina información de diseño con datos de la extensión de procesamiento de datos y representa el informe en el formato solicitado. El Procesador de entrega y programación procesa reportes desencadenados a partir de una programación y los entrega a destinos.

Almacenamiento de datos

El Report Server es un servidor sin estado que almacena todas las propiedades, los objetos y los metadatos en una base de datos de SQL Server. Los datos almacenados incluyen reportes publicados, modelos de informe y la jerarquía de carpetas que proporciona el direccionamiento de todos los elementos que administra el servidor de reportes. Una base de datos del servidor de reportes puede proporcionar almacenamiento interno para una única instalación de Reporting Services o para varios servidores de reportes que formen parte de la implementación escalada.

Extensiones

Un Report Server requiere al menos una extensión de autenticación, una extensión de procesamiento de datos y una extensión de representación. Las extensiones de procesamiento de reportes personalizadas y de entregas son opcionales, pero necesarias si desea admitir controles personalizados o de distribución de reportes

Ø  Extensiones de seguridad

Las extensiones de seguridad se utilizan para autenticar y autorizar usuarios y grupos para un Report Server. La extensión de seguridad predeterminada se basa en la autenticación de Windows. También se puede crear una extensión de seguridad personalizada para reemplazar la seguridad predeterminada si el modelo de implementación requiere un enfoque de autenticación diferente (por ejemplo, si se requiere autenticación basada en formularios para la implementación de Internet o extranet). Sólo puede utilizarse una extensión de seguridad en una única instalación de Reporting Services. Se puede reemplazar la extensión de seguridad de autenticación predeterminada de Windows, pero no utilizarla junto con una extensión de seguridad personalizada.

Ø  Extensiones de procesamiento de datos

Las extensiones de procesamiento de datos se utilizan para consultar un origen de datos. Y cuando esto sucede, devuelven un conjunto de filas planas. Reporting Services utiliza diferentes extensiones para interactuar con distintos tipos de orígenes de datos. Se puede utilizar las extensiones que se incluyen en Reporting Services o desarrollar extensiones propias. Se proporcionan extensiones de procesamiento de datos para orígenes de datos ODBC, SQL Server, Analysis Services, Oracle y OLE DB. Reporting Services puede utilizar también cualquier proveedor de datos de ADO.NET. Las extensiones de procesamiento de datos procesan las solicitudes de consulta del Procesador de reportes.

Ø  Extensiones de representación

Las extensiones de representación convierten los datos y la información de diseño del Procesador de reportes en el formato específico de un dispositivo. Reporting Services incluye seis extensiones de representación: HTML, Excel, CSV, XML, imagen y PDF.

Ø  Extensiones de procesamiento de reportes

Se pueden agregar extensiones de procesamiento de reportes para proporcionar un procesamiento de reportes personalizado para los elementos de informe que no se incluyen en Reporting Services. De forma predeterminada, un servidor de reportes puede procesar tablas, gráficos, matrices, listas, cuadros de texto, imágenes. Si desea agregar características especiales a un informe que requiere un procesamiento personalizado durante la ejecución de informe (por ejemplo, si desea incrustar una asignación de Microsoft MapPoint), puede crear una extensión de procesamiento de reportes para hacerlo.

Ø  Extensiones de entrega

Reporting Services contiene una extensión de entrega por E-mail y una extensión de entrega a recursos compartidos de archivos. La extensión de entrega por e-mail envía un mensaje mediante el Protocolo simple de transferencia de correo (SMTP) que contenga el informe o un vínculo de dirección URL al informe. La extensión de entrega a recursos compartidos de archivos guarda reportes en una carpeta compartida en la red. Se puede especificar la ubicación, el formato de representación, el nombre de archivo y las opciones de sobrescritura del archivo que se crea. También puede utilizar la entrega a recursos compartidos de archivos para archivar reportes representados y como parte de una estrategia de trabajo con reportes de gran tamaño. Las extensiones de entrega funcionan conjuntamente con las suscripciones. Cuando un usuario crea una suscripción, elige una de las extensiones de entrega disponibles para determinar cómo se entrega el informe.

Integración con SQL Server 2005

SQL Server 2005 Reporting Services ofrece dos modelos de implementación:

ü  Una implementación estándar consiste en una instancia de Report Server que utiliza un motor de base de datos de SQL Server local o remoto para alojar la base de datos del Report Server. Se puede utilizar SQL Server 2000 o SQL Server 2005 para alojar la base de datos del Report Server.

ü  Una implementación escalada consiste en varios Report Servers que comparten una sola base de datos del servidor de reportes. La base de datos se puede instalar en una instancia remota de SQL Server o localmente en uno de los Report Servers. La instancia de SQL Server que aloja la base de datos del Report Server puede ser parte de un clúster de conmutación por error.

 

 

Implementación estándar

El siguiente diagrama muestra el modelo de implementación estándar, con la base de datos de servidor de reportes ubicada en un servidor remoto. También puede instalarla localmente para que todos los componentes de servidor estén en el mismo equipo.

SSRS_Impl_estandar

Las principales consideraciones al elegir dónde alojar la base de datos del servidor de reportes son:

ü  Recursos de procesamiento

ü  Disponibilidad de espacio en disco

 

El servidor de reportes y el motor de base de datos compiten por recursos de procesamiento como el tiempo de CPU, la memoria y el acceso al disco. Algunas operaciones de servidor de reportes consumen gran cantidad de recursos. Por ejemplo, un servidor de reportes intenta utilizar toda la memoria disponible para operaciones de representación de reportes. La competición por los recursos de procesamiento se puede reducir si el servidor de reportes se ejecuta en un equipo independiente.

Los requisitos de espacio en disco del servidor de reportes son la segunda razón por la que se debe utilizar un motor de base de datos de SQL Server remoto para almacenar datos del servidor de reportes. Aunque el volumen de una base de datos de servidor de reportes puede ser reducido al principio, los requisitos de espacio en disco pueden aumentar notablemente en tiempo de ejecución en función de cómo ejecute los reportes y del número de usuarios que tengan acceso al servidor de reportes. 

 

Implementación escalada

Se puede implementar Reporting Services de forma escalada para crear una instalación de Report Server altamente disponible y escalable. Configurar una implementación escalada también puede ser de utilidad si se desea mejorar el rendimiento de las operaciones programadas y la entrega de suscripciones. Una implementación escalada de Report Server consta de varios servidores de reportes que comparten una sola base de datos de servidor de reportes. Cada Report Server de la implementación se denomina nodo. Los nodos participan en la implementación escalada si el Report Server se configura para utilizar la misma base de datos que otro Report Server.

Es posible equilibrar la carga de los nodos de servidor para admitir un gran volumen de reportes. Asimismo, la base de datos del servidor de reportes se puede crear en un clúster de conmutación por error si es necesario cumplir requisitos de alta disponibilidad.

Entre las configuraciones de clúster que no se admiten se encuentra la implementación de una instalación de servidor de reportes completa, es decir, un servidor de reportes y su base de datos, en cada nodo de un clúster de varios nodos. Concretamente, no se puede implementar Reporting Services en un clúster de dos nodos formado por un nodo activo y un nodo pasivo que se utiliza cuando se produce un error en el nodo activo

El siguiente diagrama muestra varios servidores de reportes y bases de datos de servidor de reportes implementados en clústeres de servidores distintos.

SSRS_Impl_escalada

Crear una base de datos de servidor de reportes

Reporting Services utiliza dos bases de datos relacionales de SQL Server para almacenar metadatos y objetos de servidor de reportes. Una base de datos se utiliza para el almacenamiento principal y la otra para almacenar datos temporales. Las bases de datos se crean juntas y se enlazan mediante el nombre. De manera predeterminada, las bases de datos se denominan reportserver y reportservertempdb. Colectivamente, ambas se conocen como "base de datos del servidor de reportes" o "catálogo del servidor de reportes". Para alojar las bases de datos se puede utilizar SQL Server 2000 o SQL Server 2005.

Para crear la base de datos de servidor de reportes en un equipo remoto es preciso que se configure la conexión para utilizar una cuenta de usuario de dominio o una cuenta de servicio que tenga acceso a la red. Si se decide utilizar una instancia de SQL Server remota, considérese detenidamente qué credenciales debe utilizar el servidor de reportes para conectarse a dicha instancia.

No debe escribir aplicaciones que ejecuten consultas en la base de datos del servidor de reportes. La base de datos del servidor de reportes no es un esquema público. La estructura de tablas puede cambiar de una versión a la siguiente. Si se escribe una aplicación que necesita acceso a la base de datos del servidor de reportes, se debe utilizar las API de Reporting Services para obtener acceso.

El servidor de reportes y la instancia de SQL Server que aloja la base de datos del servidor de reportes pueden estar en dominios diferentes. Para la implementación en Internet, la práctica más común es utilizar un servidor que esté detrás de un firewall. Si se va a configurar un servidor de reportes para acceso a Internet, se debe utilizar credenciales de SQL Server para conectarse a la instancia de SQL Server que esté detrás del firewall y utilizar IPSEC para proteger la conexión.

Jonnathan De La Barra Hot

Development

Windows Workflow Foundation (WWF) – Part 1

Windows Workflow Foundation permite la automatización de tareas, actividades y procesos (manejo de estado, flexibilidad), permitiendo utilizar transacciones integradas a través de workflows (flujos de trabajo). Además, aprovecha las capacidades de BizTalk Server.

En otras palabras, Windows Workflow Foundation permite abstraer la lógica de proceso en un componente adicional, que cuenta con una serie de servicios, y está encargado de coordinar el flujo de la ejecución de todo un programa. De esta forma, permite tener bien definidos los mecanismos que puedan ofrecer el estado apropiado y la transparencia de un proceso.

¿Qué es un workflow?

Un workflow es un conjunto de unidades elementales llamadas actividades, que son almacenadas en forma de un modelo que describe un proceso del mundo real. Los workflows proveen una manera de describir el orden de ejecución y de relaciones dependientes entre piezas cortas o largas de un trabajo que se está ejecutando. Este trabajo pasa por el modelo de principio a fin, y las actividades pueden ser ejecutadas por personas o por funciones de sistema.

wwf_intro

Facilita y describe procesos del mundo real

·         Actividades que realizan personas

·         Actividades que realizan sistemas

WWF incluye soporte para workflow tanto de sistemas como humano, a través de un extenso rango de escenarios, que incluyen:

– Workflow dentro de la línea de aplicaciones de negocios.
– Flujo de página de la interfaz del usuario.
– Workflow humano.
– Workflow compuesto para aplicaciones orientadas a servicios.
– Workflow conducido por reglas de negocios.
– Workflow para manejo de sistemas.

Se asocia con otras tecnologías:

 ASP.NET
– Windows Communication Foundation.
– Windows Presentation Foundation.

Aplicaciones que podrían llegar a usar workflows

Una aplicación ASP.NET que muestre páginas a sus usuarios podría usar un workflow para controlar el orden en que esas páginas son exhibidas. Esto hace que sea más fácil cambiar el flujo de las páginas sin que ellos tengan que modificarlas, como también separar la aplicación de la interfaz del usuario de su lógica de control.

Una aplicación compuesta en un ambiente orientado a servicios podría implementar su comportamiento de base usando un workflow. Como cada vez más y más las aplicaciones exponen su lógica a través de servicios Web, crear procesos de negocios que utilicen esos servicios se vuelve más fácil. Una tecnología workflow como Windows Workflow Foundation provee un contenedor para la lógica que invocaría a esos servicios, poniéndolos juntos en una aplicación compleja.

Una aplicación que apunte a un problema específico, como, por ejemplo, el manejo de la relación con el cliente (CRM: Customer Relationship Management), o un mercado vertical concreto, como el de servicios financieros, podrían ser construidos alrededor de un workflow. Este tipo de aplicación comúnmente implementa un número diferente de procesos de negocios, construyendo la lógica que manejan esos procesos en un WF común. De esta forma, la aplicación será más rápida de construir, más rápida de cambiar y más fácil de personalizar.

Requerimientos que debe cumplir un workflow simple

1.    Debe tener la habilidad de tomar decisiones basadas en reglas de negocios.  Este requerimiento incluye reglas simples, por ejemplo, una decisión de o no basada en el resultado de un chequeo de crédito, como también reglas más complejas, por ejemplo, conjuntos potencialmente largos que deben ser evaluados para hacer una decisión inicial.

2.    Formas de comunicarse con otros programas y otros sistemas fuera de workflows. Un ejemplo son los servicios Web u otras tecnologías.

3.    Maneras de interactuar con las personas. Por ejemplo, un encargado debe aprobar a sus empleados. Por lo tanto, el workflow debe ser capaz de mostrar una interfaz para el usuario o interactuar con los seres humanos a través de otro software.

4.    La habilidad de mantener el estado durante el tiempo de vida de un workflow. Especialmente cuando hay gente envuelta, como el encargado en este ejemplo, un workflow puede tomar mucho tiempo en completarse (por ejemplo, ¿qué pasaría si el encargado se tomara el día o dos semanas de vacaciones?). Construir sistemas escalables requiere una manera de desactivar el workflow y almacenar su estado persistentemente, para luego reactivarlo y cargar ese estado cuando el siguiente paso sea ejecutado.

Un workflow puede ofrecer cosas como:

1.    Un componente de tipo acercamiento a workflows, donde cada paso pueda ser implementado por una porción específica de software. Como en otras tecnologías de componentes, es posible especificar declarativamente los comportamientos para estos pasos (como, por ejemplo, transacciones) en vez de escribir código que implemente estos comportamientos. También se pueden crear pasos predefinidos para workflows que son útiles en un dominio en particular, como, por ejemplo, aplicaciones de seguros o manejo de sistemas, y luego usar éstos en diferentes workflows

2.    Herramientas que crean y modifican workflows gráficamente. Como un workflow consiste en un número definido de pasos, puede ser construido usando herramientas que ilustran esos pasos y las relaciones entre ellos.

3.    La habilidad de monitorear un workflow que se está ejecutando, examinando su  ejecución en tiempo real. Por ejemplo, con la actividad Tracing.

4.    Una manera de cambiar una instancia workflow que se está ejecutando; por ejemplo, agregar un paso. Aunque esto no es típicamente necesario cuando sólo se abarca software, este tipo de flexibilidad es un requerimiento común para que Workflows interactúe con personas.

Los procesos de negocios comúnmente involucran tanto a personas como a aplicaciones y automatizan acciones entre software, la cual es muy diferente de automatizar interacciones entre personas

Workflows de sistemas

Los workflows de sistemas son interacciones automatizadas entre aplicaciones. Estas interacciones son usualmente predecibles y relativamente estáticas. La lógica que dirige esta interacción puede ser especificada una sola vez, y luego ser utilizada una y otra vez sin cambios. Los workflows de sistemas también intercambian datos bien definidos y estructurados, como, por ejemplo, documentos XML, que pueden ser procesados efectivamente por software sin ninguna intervención humana.

Workflows humanos

Un workflow humano es el que coordina interacciones con personas. Las aplicaciones que interactúan a favor de las personas tienden a necesitar más flexibilidad que aquellas que interactúan puramente con otro software.

Esto contrasta con los workflows de sistemas, ya que las personas cambian de parecer, introducen nuevas ideas y excepciones, deciden cancelar un proceso inesperadamente y realizan otras cosas que hacen a los workflows humanos más efectivos y más dinámicos.

Los programas que soportan workflows humanos deberían permitir un acercamiento más flexible orientado a eventos. Éstos también trabajan con datos menos estructurados y más comprensibles para los humanos, como, por ejemplo, mensajes de e-mail y documentos de texto, en vez de la información estructurada que es utilizada en los workflows de sistemas.

Componentes principales

Arquitectura de Windows Workflow Foundation

La arquitectura de Windows Workflow Foundation consta de seis partes principales:

          Activity: es una unidad de trabajo. El trabajo que una actividad implementa puede variar de forma muy simple a muy compleja.

          Workflow Model: es un grupo de actividades que implementa todas o algunas partes de la lógica de negocios.

          Designers: son herramientas gráficas que pueden ser usadas para crear y modificar actividades de workflows.

          Base Activity Library: es un grupo de actividades que los desarrolladores pueden usar para crear workflows.

          Runtime Engine: es una librería que ejecuta workflows. El Runtime Engine también provee otros servicios, como mecanismos para comunicarse con software fuera del workflow.

          Host Process: es una aplicación de Windows que da soporte al Windows Workflow Foundation Runtime Engine y a cualquier workflow que ejecuta. El Host Process provee servicios de soporte en ejecución para un estado persistente del workflow, para manejar transacciones y otras funciones.

wwf_architecture

Actividades

Las activities son la unidad elemental de un workflow. Son agregadas de manera similar a como se añade en XML un Child Node a un Root Node. Una vez que todas las actividades en el camino de un flujo dado terminan de ejecutarse, la instancia Workflow se completa.

Windows Workflow Foundation contiene una librería de mecanismos estándar que permiten crear actividades propias. Esto permite también extensibilidad y reutilización entre workflows.

Las activities se implementan en clases. Son heredables, anidables y, por supuesto, reutilizables

Dentro de la Base Activity Library, las más relevantes son:

          Code: ejecuta código C# para acciones personalizadas.

          EventDriven: representa una sucesión de actividades cuya ejecución es iniciada por un evento.

          EventSink: le permite al workflow recibir información de un Data Exchange Service (DES) registrado en el Workflow Runtime.

          Invoke Method: permite al workflow invocar un método en la interfaz para mandar un mensaje al DES.

          Invoke WebService: permite al workflow invocar un Web Service.

          Invoke Workflow: permite que el workflow llame o inicie otro workflow totalmente independiente.

          Select Data: le permite al workflow realizar queries indirectamente a través del host.

Workflow Model Layer

La Capa de Modelo de Workflow (Workflow Model Layer) es donde muchos de los desarrolladores pasarán la mayor parte de su tiempo escribiendo código para sus aplicaciones en Windows Workflow Foundation. Esta capa incluye soporte para tipos de modelos de workflow, actividades y la programación principal de APIs, que es usada por muchos desarrolladores.

A pesar de que Windows Workflow Foundation incluye estos dos modelos, los clientes pueden heredar de ellos, para crear sus propios modelos específicos o nuevos.

Capa de Diseño

Dentro de Visual Studio .NET, Windows Workflow Foundation provee un conjunto de herramientas gráficas que apuntan a los diseñadores. El objetivo es que la experiencia de desarrollo en Visual Studio .NET sea lo más familiar posible a las ya existentes aplicaciones de desarrolladores .NET en C# y VB.NET; y que se puedan construir aplicaciones utilizando Windows Presentation Foundation (WPF) y Windows Communication Foundation(WCF).

wwf_design_layer

Estas herramientas gráficas facilitan el desarrollo en Workflows. Esto es similar a las herramientas que se pueden usar en Visual Studio 2008, donde se arrastran hasta un formulario y luego se sueltan, para crear una interfaz gráfica para el usuario.

Runtime Layer

La capa Runtime (Runtime Layer) cumple un papel esencial en Windows Workflow Foundation e incluye:

          Execution: es el servicio de ejecución que programa actividades y soporta comportamientos comunes, tales como el manejo de eventos, excepciones, rastreo y transacciones.

          Tracking: este servicio crea los eventos de rastreo y son serializados a través de la misma interfaz.

          State management: es el servicio de manejo de estado que, como su nombre lo indica, maneja estados que puedan ser retenidos a través de la interfaz de la persistencia.

          Scheduler: es el servicio programador que programa la ejecución de actividades.

          Rules: es el servicio de reglas que provee la funcionalidad de política de ejecución y la evaluación de condición de CodeDOM (Code Document Object Model).

Jonnathan De La Barra Acalorado

Business Intelligence

Introducción al Data Mining

Hoy en día es muy frecuente, sobre todo en las grandes empresas, la disponibilidad de grandes volúmenes de datos y el uso generalizado de herramientas informáticas para la extracción adecuada del conocimiento que encierra la información. Este hecho ha transformado el análisis de datos orientándolo hacia determinadas técnicas especializadas englobadas bajo el nombre de Minería de datos o Data Mining.

De modo resumido puede considerarse el Data Mining como un proceso de descubrimiento de nuevas y significativas relaciones, patrones y tendencias al examinar grandes cantidades de datos.

Las técnicas de Data Mining, persiguen el descubrimiento automático del conocimiento contenido en la información de modo ordenado en grandes Bases de Datos. Estas técnicas tienen como objetivo descubrir patrones, perfiles y tendencias a través del análisis de los datos utilizando tecnologías de reconocimiento de patrones, redes neuronales, clustering,  clasificación, predicción y otras técnicas avanzadas de análisis multivariante de datos.

El Concepto de Data Mining

Los recientes avances tecnológicos hacen que las capacidades para generar y almacenar datos se incrementen día a día. Entre los factores que influyen en esta realidad podemos destacar el uso extendido de los códigos de barras, la automatización de todo tipo de transacciones (comerciales, negocios, económicos, gubernamentales o científicos) y los avances en la recopilación de datos. Además Internet ha favorecido el rápido acceso a la información, tanto de datos como de los resultados obtenidos por otros teams.  Por otro lado, ha supuesto la puesta en contacto de workgroups de Organizaciones que, aunque  lejanos en el espacio, están muy cercanos en el ciberespacio, lo que ha dado lugar a fuertes economías de escala a través de la puesta en común de Base de datos, conocimientos y resultados exitosos.

Por otra parte, la evolución de los storage devices (en relación precio-Capacidad de almacenamiento), tales como los discos duros que pueden almacenar gigabytes de información a un precio reducido, ha dado lugar a que empresas y organizaciones almacenen todo tipo de información, desde los datos de sus clientes y sus transacciones, hasta los datos de telemetría, monitorización de pacientes, evolución de los precios en los mercados, etc. Con el tiempo la cantidad de datos que se fue almacenando empezó a crecer y, si bien, el soporte de las herramientas para realizar la gestión de los datos era el adecuado, las relaciones significativas existentes entre ellos, empezaron a sobrepasar las capacidades humanas para el análisis.

Todo este explosivo crecimiento de datos generó, a finales de los 80 la aparición de un nuevo campo de investigación que se denomino KDD (Knowledge Discovery in Databases). Bajo estas siglas se esconde: “el proceso no trivial de descubrimiento de patrones válidos, nuevos, potencialmente útiles y comprensibles en grandes volúmenes de datos”. El proceso de KDD ha servido para unir investigadores de áreas en principio dispersas como Inteligencia Artificial, Estadística, Técnicas de Visualización, Matemáticas en la búsqueda de técnicas eficientes y eficaces que ayuden a encontrar el potencial conocimiento que se encuentra inmerso en los grandes volúmenes de datos almacenados por las organizaciones diariamente.

Si bien el nombre con el que se apareció esta área de investigación fue el de KDD, otros nombres han sido usados para este mismo concepto. Algunos de ellos son Knowledge Discovery, Data Discovery, Information Discovery, Knowledge Extraction, Data Extraction, Information Extraction, Pattern Discovery, Knowledge Mining. En la actualidad es Data Mining, por el que es conocido mundialmente. Este término proviene de la analogía entre enfrentarnos a una gran cantidad de datos para descubrir patrones útiles y en la explotación de una montaña para encontrar una veta de mineral precioso. Ambos procesos necesitan de métodos inteligentes de exploración para optimizar los resultados. En un principio Data Mining fue tan sólo usado para referirse a la etapa del proceso en la que se aplican las técnicas y algoritmos de descubrimiento de patrones. No obstante, en la actualidad, se usa para referirse al conjunto del proceso global de descubrimiento de conocimiento a partir de los datos, mientras que el concepto de herramientas de Data Mining se refiere a los algoritmos de análisis de los datos.

El gran aumento de datos que tienen que analizar las organizaciones no solo dio lugar a la aparición de Data Mining, sino que al mismo tiempo y de manera paralela surge el concepto de Data Warehouse. Uno de los grandes problemas del Data Mining es que los datos nunca fueron guardados pensando en que posteriormente serian analizados, como consecuencia, de forma previa al análisis es necesario un proceso de integración y limpieza de datos que en muchos casos resulta más costoso que el propio análisis. Sin embargo, la aparición de los Data Warehouses como repositorios de información centralizada permite que los procesos de Data Mining se puedan realizar sobre conjuntos de datos que han sido previamente integrados y sometidos a Data Cleansing (procesos de limpieza)

Jonnathan De La Barra Acalorado
Business Intelligence

Microsoft SQL Server 2005 Reporting Services – Part I

Microsoft SQL Server 2005 Reporting Services es una solución basada en el servidor que se utiliza para generar reportes empresariales.

Dichos reportes extraen contenido de una variedad de orígenes de datos relacionales y multidimensionales, para ser publicados y vistos en diversos formatos. También administra la seguridad y las suscripciones de manera centralizada. Los reportes creados se pueden ver mediante una conexión Web o como parte de una aplicación de Microsoft Windows o un portal de SharePoint.  

Reporting Services incluye:

ü  Herramientas y asistentes gráficos para crear y publicar reportes y modelos de reportes

ü  herramientas de administración del servidor de reportes para administrar Reporting Services

ü  Interfaces de programación de aplicaciones (API) para programar y extender el modelo de objetos de Reporting Services.

 

SQL Server 2005 Reporting Services ofrece funcionalidad empresarial y de reportes habilitados para Web de modo que se puedan crear reportes que extraigan el contenido de una gran variedad de orígenes de datos, publicar reportes en distintos formatos, y administrar de manera centralizada la seguridad y las suscripciones.

Los reportes que se generan pueden basarse en datos relacionales o multidimensionales de SQL Server, Analysis Services, Oracle o cualquier proveedor de datos de Microsoft .NET, como ODBC u OLE DB. Puede crear reportes tabulares, matriciales o de formato libre. También puede crear reportes adaptados a una circunstancia determinada, que utilicen modelos y orígenes de datos predefinidos.  

Visual y funcionalmente, los reportes que se generan en Reporting Services van más allá de los reportes tradicionales, puesto que incluyen características interactivas y basadas en Web. Algunos ejemplos de estas características son los reportes de varios niveles de detalle, que permiten la navegación por distintas capas de datos, los reportes con parámetros, que admiten el filtro de contenido en tiempo de ejecución, o los reportes de formato libre, que admiten contenido con diseños verticales, anidados o adyacentes, vínculos a contenido o recursos basados en Web y acceso seguro y centralizado a reportes mediante conexiones Web locales o remotas.  

Aunque Reporting Services se integra con otras tecnologías de Microsoft sin necesidad de adaptación, los programadores y otros proveedores pueden generar componentes compatibles con otros formatos de salida de reportes, formatos de entrega, modelos de autenticación y tipos de orígenes de datos. La arquitectura de desarrollo y tiempo de ejecución se ha creado con un diseño modular para admitir extensiones de terceros y posibilidades de integración.

Reportes empresariales 
 

Muchas compañías utilizan software de elaboración de reportes para distribuir información a los usuarios que utilizan reportes para tomar decisiones, identificar oportunidades o analizar amenazas. Reporting Services incluye una amplia gama de herramientas y servicios listos para usar que le permitirán crear, implementar y administrar reportes para la organización. Si bien se puede manipular reportes mediante programación, ésta no es necesaria si desea utilizar Reporting Services tal como se distribuye. Las herramientas de creación y administración incluyen el Report Designer, SQL Server Management Studio, el Report Manager y la herramienta de Reporting Services Configuration Manager. Los usuarios de empresas pueden utilizar el Report Manager, elementos Web de SharePoint o un Web browser para ver reportes a petición o suscribirse a reportes que se entregan por e-mail.

Elaborar reportes ad hoc  

Los usuarios que trabajen con datos empresariales precisan con frecuencia la capacidad de crear y ajustar reportes ad-hoc. Reporting Services incluye el Report Builder, una tool que permite seleccionar un template y un report model del Report Server, arrastrar campos de datos y elementos gráficos a una superficie de diseño para crear reportes básicos, guardar archivos de definición de reportes en el servidor y modificar los reportes. Los reportes ad hoc requieren Report Models predefinidos que se creen con un Report Designer y se publiquen después en el Report Server para usarlos en la organización.

El Generador de Reportes proporciona reportes ad hoc sobre datos relacionales y multidimensionales mediante el Data Source model. Está destinado a usuarios que desean crear reportes básicos fácilmente sin escribir consultas. El Report Builder utiliza modelos y plantillas de informe predefinidos que administran conexiones de datos, consultas y relaciones de datos de modo que los usuarios sólo deban arrastrar y colocar campos de datos en una plantilla para crear reportes tabulares o de matriz

Elaboración de reportes incrustados

 Un desarrollador, puede utilizar Reporting Services para proporcionar características de elaboración de reportes a su aplicación. Para algunas aplicaciones, la adición de reportes, completa un conjunto de características proporcionando un modo de presentar datos de los que la aplicación mantiene un seguimiento, crea o supervisa. Se puede utilizar el Report Designer para crear reportes basados en un Data Source de su aplicación o que esté disponible públicamente.

Se puede utilizar la API para definir el acceso y agregar compatibilidad con las características integradas del Report Server que se desee incluir en una aplicación 

Como parte de la implementación de la aplicación, se debe incluir un Report Server y Report Server ’s Database que contenga reportes y otros metadatos. En tiempo de ejecución, cuando el usuario solicita un informe, el código de la aplicación llama al Web Service del Report Server, que después recupera la definición de informe de la Report Server ‘s Database y procesa el informe con los datos más recientes.

Como alternativa, si la aplicación no requiere todas las características proporcionadas en el Report Server, puede utilizar los controles ReportViewer que incluye Microsoft Visual Studio 2005. A diferencia de Reporting Services, los controles ReportViewer se distribuyen gratuitamente con la aplicación.

Se puede utilizar el Report Designer para crear reportes simples o reportes complejos que incluyan expresiones y ensamblados personalizados para hacerlos compatibles con una funcionalidad personalizada.

Integración de portales  

Puesto que los reportes pueden acomodar y presentar datos de una gran variedad de orígenes, muchas organizaciones utilizan las características de elaboración de reportes interactivas de Reporting Services para distribuir datos tabulares o gráficos en aplicaciones de portal. Se puede alojar reportes en una página de portal o crear un informe que refleje una aplicación Web con estilo de panel incrustando varios reportes, imágenes y gráficos controlados por datos en un solo diseño de informe de forma libre

Elaborar reportes para Internet

Puede crear reportes que estén disponibles para aquellos empleados que trabajen fuera o en oficinas regionales implementando un servidor de reportes en un servidor Web para Internet. Tenga en cuenta que la implementación de reportes en Internet suele requerir la creación de una extensión de seguridad personalizada que permita autenticación basada en formularios. Se requieren conocimientos en seguridad para Web, implementación en Internet y programación para escribir las extensiones necesarias.  

Generar herramientas personalizadas de diseño y administración de reportes

Las herramientas y aplicaciones de que dispone Reporting Services se basan en interfaces de programación disponibles para todos los usuarios. Esto significa que es posible reemplazar las aplicaciones y herramientas incluidas en Reporting Services por un conjunto de herramientas personalizadas que se cree ad hoc. Por ejemplo, si se desea una alternativa al entorno de creación de Visual Studio utilizado por el Diseñador de reportes, se puede desarrollar una herramienta de elaboración de reportes personalizada para reemplazarlo. Para generar una herramienta de administración de reportes o un portal Web personalizado, se debe revisar la API para conocer las funciones de administración del servidor de reportes que debe permitir. Reporting Services incluye un proveedor WMI (Instrumental de administración de Windows) que se puede usar para desarrollar herramientas basadas en Windows utilizadas para la administración de servidores.


Ampliar la funcionalidad de Reporting Services

Reporting Services está diseñado para poderse ampliar. Se pueden crear extensiones personalizadas para admitir otros tipos de orígenes de datos, métodos de entrega, modelos de seguridad y elementos de informe. Cuando se crean extensiones personalizadas, el grado de dificultad puede variar considerablemente dependiendo del tipo de extensión que se cree y de la funcionalidad que debe proporcionar. Las extensiones de procesamiento de datos suelen ser las más fáciles de crear, mientras que las extensiones de representación pueden resultar muy difíciles si se crean para admitir todo el esquema del informe.

Para crear un informe, se debe crear una Report Definition mediante el Report Designer o el Report Builder. La tool de creación que se utilice depende de los requisitos del informe y del nivel de conocimiento del usuario sobre técnicas de creación de reportes.

Administrar reportes y otros elementos  

Una de las principales ventajas de utilizar Reporting Services es la posibilidad de administrar reportes y elementos relacionados, como carpetas, conexiones de orígenes de datos y recursos, desde una ubicación centralizada. Se puede definir la seguridad, establecer propiedades y programar operaciones. También se puede crear programaciones compartidas y orígenes de datos compartidos, y ponerlos a disposición de todos los usuarios. Para administrar reportes y el entorno de reportes, se debe utilizar SQL Server Management Studio o el Report Manager. La administración de reportes comprende las siguientes tareas:

  Organizar el entorno de reportes agregando nuevas carpetas para almacenar colecciones de reportes.

  Habilitar características como Mis reportes, el historial del informe y la entrega de reportes por e-mail (Push).

  Proteger el acceso a carpetas y reportes mediante la asignación de usuarios y grupos a Roles..

  Generar las programaciones compartidas y los orígenes de datos compartidos que desea poner a disposición de todos los usuarios.

Tanto los usuarios como los administradores del Report Server pueden administrar reportes, pero no del mismo modo. Los usuarios pueden publicar y administrar reportes en un área de trabajo personal denominado Mis reportes. Los administradores del Report Server pueden administrar el espacio de nombres completo de carpetas del servidor de reportes. La posibilidad de realizar tareas de administración depende de los permisos de usuario.  

Obtener acceso a reportes y entregarlos  

Reporting Services ofrece dos métodos para obtener acceso a los reportes y entregarlos:

ü  Pull: El acceso a petición permite a los usuarios seleccionar los reportes desde una tool de visualización de reportes. Se puede utilizar el Report Manager, un WebPart de Microsoft SharePoint o un Browser.

ü  Push: El acceso basado en suscripciones genera y entrega reportes automáticamente a un destino. Puede entregar reportes a una bandeja de entrada de e-mail o a un recurso compartido de archivos.  

Para ver un informe a petición, se puede buscar o seleccionar un informe de una jerarquía de carpetas, denominada espacio de nombres de carpetas del Report Server. Para recibir reportes automáticamente, puede suscribirse a un informe específico. Cuando se ejecuta el informe, el usuario recibe una notificación que le indica que el informe está disponible o recibe una copia del mismo en un mensaje de e-mail.(Push Delivery of reports by Using e-mail)

Los administradores del Report Server pueden generar Data-Driven Subscriptions que proporcionan datos a un grupo numeroso de personas. Las Data-Driven Subscriptions generan una lista de destinatarios en tiempo de ejecución. En las Data-Driven Subscriptions, la configuración de entrega se genera a partir de los datos almacenados (por ejemplo, los de una base de datos de empleados) cuando se desencadena la suscripción.

Reporting Services es compatible con varios formatos de visualización. Al principio los reportes se muestran en formato HTML, pero, una vez representado un informe, se puede volver a mostrar en un formato diferente como Excel o PDF.

Puede instalar servidores de reportes en configuraciones de servidor único (Single Server), distribuidas (Remote Database Server)  y agrupadas (Web Farm).

Jonnathan De La Barra Acalorado