Предположим, Вы хотите быстро предоставить своим бизнес-пользователям возможность отправлять предопределенные запросы к оперативным источникам данных прямо из Вашего 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, и это не приведет к необходимости процессить куб.