Uso nativo de SQL y MDX de forma segura
Actualizado: 2009-04-30
Planning Server dispone de un lenguaje que permite especificar reglas de cálculo con facilidad. Estas reglas se pueden usar, entre otras funciones, para especificar datos en un modelo, mover los datos dentro o entre los modelos, y calcular nuevos valores a partir de los datos existentes. Estas reglas pueden ser ejecutadas por un miembro de la función Modelador mediante Planning Business Modeler, de dos maneras. La primera forma de ejecutar una regla es como parte de un trabajo que, a continuación, se programa o asigna a un usuario empresarial. El segundo método es hacer que el sistema ejecute automáticamente la regla cada vez que se modifican los datos. Los miembros de Modelador también pueden especificar la ejecución en Microsoft SQL Server 2005 o MDX; cada uno de estos métodos presenta ventajas y desventajas en funcionalidad y rendimiento.
En algunas condiciones, el lenguaje PerformancePoint Expression Language (PEL) puede ser demasiado restrictivos para los usuarios avanzados. Esto resulta especialmente cierto para los clientes expertos en SQL Server o MDX y que desean mejorar sus procedimientos almacenados para el rendimiento, utilizar las funciones integradas de SQL Server que no exponemos, o hacer algo fuera las capacidades de PEL. Lo que PEL proporciona es la capacidad de SQL Server o MDX sin formato, junto con la comodidad de nuestra infraestructura de reglas que permite diferentes estilos de ejecución.
Para lograr esto, PEL expone una nueva implementación de reglas denominada NativeSql y NativeMdxScript. Sin embargo, estas nuevas implementaciones pueden suponer un riesgo de seguridad. En teoría, podrían hacer posible que usuario que tiene acceso a sólo un sitio de modelo pueda realizar cambios drásticos en varios sitios de modelo de toda la aplicación. En concreto, Planning Server no puede realizar ningún análisis de estas reglas porque se escriben en SQL o MDX, que Planning Server no se puede analizar con facilidad. Esto requiere una nueva implementación de reglas que se ejecute como la identidad de servicio, que tiene permisos de propietario de base de datos en el equipo de SQL Server que contiene la base de datos de la aplicación. Esto permitiría a un miembro malintencionado de la función Modelador cambiar datos en cualquier parte de la aplicación, colocar tablas, modificar el seguimiento de auditoría y muchas otras cosas.
Para reducir este riesgo, hay dos opciones: el sistema de aprobación y la ejecución de todas las reglas como un usuario con pocos privilegios (descrito en otro documento).
Ejemplo:
Los siguientes pasos describen cómo crear y ejecutar una regla nativa mediante el sistema de aprobación.
En Consola de administración de planeación, un miembro de la función Administrador global debe seleccionar la casilla Habilitar reglas nativas de SQL\MDX. Esto establece el indicador correspondiente en "True". El indicador se almacena como un valor booleano en el objeto de la aplicación. Los usuarios que dispongan de permisos EditMetadata en el nivel de la aplicación tienen acceso para modificarlo. Este paso no es necesario para reglas normales.
En Planning Business Modeler, un miembro de la función Modelador debe escribir y, a continuación, guardar una regla sin formato en un estado InActive. Cada vez que se guarda cualquier edición de la regla, incluidas las modificaciones realizadas en las reglas normales, Planning Server comprueba el tipo de operación EditRules en el contexto del modelo donde se guardan las reglas. En el caso de reglas sin formato, el servidor además comprueba que el indicador de la aplicación Habilitar reglas nativas de SQL\MDX está habilitado (la casilla activada), y que el estado de cada regla nativa es InActive. Cualquier regla establecida en InActive no se puede implementar en la base de datos o cubo OLAP y no puede ejecutarse.
En la base de datos de SQL Server, un administrador de bases de datos debe aprobar la regla estableciendo el indicador “IsActive” en true para esa regla. Este indicador se almacena en la tabla RuleSetsOrRules, en la columna IsActivated. El acceso a esta tabla se controla de acuerdo a los permisos estándar de SQL. Este paso no es necesario para reglas normales.
El modelo que contiene la regla se debe implementar por un miembro de la función Modelador. Este paso es necesario incluso para reglas normales. Como parte de la implementación del modelo, Planning Server siempre comprobará el tipo de operación GenerateApplication en el ámbito del modelo que se implementa. Además, para reglas sin formato, el servidor comprobará si el indicador de la aplicación Habilitar reglas nativas de SQL\MDX está habilitado. Si este indicador se establece en InActive, no se implementan en ningún caso las reglas normales ni nativas.
Un miembro de la función Modelador puede ejecutar ahora la regla nativa utilizando cualquiera de las rutas de acceso de ejecución estándar. Si se ejecuta directamente en Planning Business Modeler, se comprobará el tipo de operación ExecuteRule en el contexto del modelo. Si el miembro modelador crea un trabajo y lo programa o asigna a un usuario, se comprobará el tipo de operación ManageWorkflow con el ámbito del sitio de modelo en el que se encuentre el modelo. Si la regla se establece para que el sistema la ejecute (esto tiene que realizarse cuando se crea la regla), no se comprueba ningún tipo de operación adicional. Además de las comprobaciones estándar que se aplican a todas las reglas, hay una comprobación adicional para el indicador Habilitar reglas nativas de SQL\MDX, siempre que una regla nativa se ejecute desde cualquier ruta de acceso al código. Si el indicador es "false", la ejecución generará un error.
Si se realiza algún cambio en la regla nativa, debe guardarse en un estado InActive, tal como se describe en el paso 2. Se deben repetir los pasos 3 y 4 para volver a aprobar la regla. Esto crea un proceso de aprobación en torno a cada regla nativa. En algunos casos, un miembro administrador global puede decidir que las reglas nativas no son necesarias para su aplicación de planeación. Puede elegir no habilitar en ningún caso el indicador Habilitar reglas nativas de SQL\MDX. De forma predeterminada, este indicador se establece en False. Incluso si el indicador se ha establecido en True, cada regla debe ser autorizada por un miembro de la función Modelador y aprobada por un administrador de la base de datos. Esto proporciona a los administradores la oportunidad de crear un sistema de revisión que pueden usar antes de habilitar la regla. Por último, en caso de que el miembro administrador global decida que ya no desea reglas sin formato en el sistema, puede deshabilitar el bit Habilitar reglas nativas de SQL\MDX. Cuando se hace esto, las reglas nativas no se pueden crear, actualizar, implementar ni ejecutar; sólo se pueden eliminar.