Предположим, Вы хотите быстро предоставить своим бизнес-пользователям возможность отправлять предопределенные запросы к оперативным источникам данных прямо
из Вашего OLAP-куба, используя контекстные значения текущей ячейки в качестве входных параметров параметизированных запросов (например, для текущего клиента
из CRM системы получить активности/контакты с ним за последние 4 часа текущего дня).
Прежде всего в Microsoft Visual Stududio пишем и компилируем ddl-ку SQLQuery, исходный код которой кратко (без обработки исключений) приведен ниже:
using System;
using System.Data;
using System.Data.OleDb;
namespace ASSP
{
public class SQLQuery
{
public static DataTable ExecuteSQL(string connectionString, string sql)
{
OleDbConnection conn = new OleDbConnection(connectionString);
DataTable dt = new DataTable("Rslt");
OleDbDataAdapter da = new OleDbDataAdapter(sql, conn);
da.Fill(dt);
return dt;
}
}
}
Затем подключаем данную сборку к SSAS проекту.
В проекте SSAS создаем новое действие (Action) как показано на рисунке ниже:
В одной из предыдущих статей говорилось о разграничении прав доступа к OLAP измерениям с использованием таблиц метаданных,
хранящихся и ведомых в реляционной базе данных, и внешней .Net функции. Так вот, в той же базе данных можно создать ещё одну
таблицу для хранения прав доступа OLAP-пользователей к параметизированным запросам RDBMS, а в сборку OLAP_ACCESS добавить функцию CheckPermission_SQLQuery.
Тогда в разделе Condition можно будет прописать следующие условие:
IIF(OLAP_ACCESS.CheckPermission_SQLQuery(USERNAME(), "SQLQueryCodeName"), "True", "False")
Возможно (в зависимости от информационного ландшафта) пойти еще дальше: переработать таблицы метаданных и CLR процедуру таким образом, что
в Action expression качестве параметров потребуется передавать лишь кодовое наименование запроса,
переменную (динамическую) часть запроса / параметры процедуры / параметры функции, USERNAME(),
а строки соединения к OLTP-источникам, постоянная часть запроса / процедуры / функции, права доступа будут храниться в метаданных реляционной базы данных.
Особенность действий (Actions) в том, что их можно добавлять в проект и разворачивать (deploy) на действующем сервере SSAS, и это не приведет
к необходимости процессить куб.