Привет Хабр! Меня зовут Белков Евгений, я руководитель направления разработки Siebel CRM в Московском кредитном банке.
В последнее время стал все больше разрабатывать дашборды на Fine Bi и все больше неординарных требований к визуализации вынуждают танцевать с бубном. В прошлый раз рассказывал о нюансах работы Jump.
Сегодня я хочу поделиться опытом работы с Динамической фильтрацией данных. Чтобы быстрее понять, что я имею в виду, давайте представим таблицу следующего вида.
Но наш Заказчик хочет видеть, сколько позиция в каждом Департаменте или Команде находятся в определенных статусах, и иметь возможность быстро переключаться между двумя разрезами, ну и конечно же:
видеть остальную детализацию по всем позициям
чтобы все было красиво и кликабельно
чтобы можно было линковаться и видеть детализацию по каждой выборке.Например так, далее буду называть их дочерними апплетами
Решения
Вариант 1. TAB-component
Он включает в себя элементарное разграничение представлений. Просто делаем представление и полностью его копируем меняя в разрезы, как нам нужно..
Самый быстрый это создать TAB-component
Переносим все созданные компоненты на этот таб и копируем
Далее меняем разрезы и получаем уже решенную проблему.
Плюсы:
Быстро и работает.
Возможность реализации собственной детализации для каждого представления.
Минусы:
1. Если у вас будут отличаться фильтры на Applet внутри Tab, а дочерние будут линковаться с обоими родителями, но фильтр будет применяться суммарный (в самом худшем случае в дочках вы можете ничего не увидеть, если фильтры на родителях будут противоречить друг другу, или взаимоисключать). Желательно пользоваться кнопкой или создать на дашборде свою кнопку Reset Button (находится в Filter Component).
2. Если Link между родителями не убрать, по при нажатии на одном родителе он будет корректировать выборку на втором. Убрать можно с помощью Set Linkage.
3. Можно копировать сколько угодно целиком вкладку Tab, но при этом скопируются все Applet, которые он содержит. Это не очень удобно, так как если детализация будет отличаться, то придется ее в случае изменения дополнительно разносить по всем копиям.
Вариант 2. Динамический разрез
1.Создаем Parameter в котором будем хранить выбранный тип разреза и по умолчанию ставим один из списка. (список лучше продумать заранее, но в моем случае у меня будет Команда, Департамент).
2. Создаем Text-Filter и настраиваем в нем Custom Value List (ваш собственный лист значений в фильтре) и Bind Parameter (настройка заполнения параметра при выборе значения в фильтре).
Не забудьте проставить Filter Method - Single, чтобы нельзя было выбрать более 1 значения. Должен получиться такой фильтр.
3.Создаем новую Calc Field - она должна будет переключать значения в зависимости от выбранного значения в фильтре из пункта выше.
4.Последний штрих - это необходимо вывести поле на таблице(в моем случае я меняю Команду на Разрез).
5.Проверяем:
По команде
По Департаменту
Ну и соответственно можно так же сделать и другие разрезы например по статусам. Для этого необходимо лишь скорректировать Custom Value List из п.2 и Calc Field из п.3.
Плюсы:
Простая реализация и быстрота добавления новых группирующих разрезов
Отсутствие копий Applets
Нет проблем с перелинковками Applets.
Таким же образом можно настроить изменения детализации дочерних Applets (нужно повторить пункты 3 и 4) это позволит вносить изменения в представлении. Но нельзя изменить
а) тип диаграммы
б) название диаграммы. его не сделать динамическим, т.к можно использовать только статический текст или Component Name. Но и тут у меня есть решение:
i) отключаем на компоненте Show Title, либо делаем его пустым(пробел например, но не рекомендую)
ii) создаем компонент KPI Card настраиваем ему нужное отображение вставив соответствующее калькулируемое поле (Parameter явно вставить нельзя, но можно обернуть Calc Field), Удалив Prompt
iii) делаем этот компонент с признаком Hover, Располагаем поверх основного компонента. Ну и чтобы ничего не съезжало делаем Combine этих двух компонентов и в целом у вас будет не заметно, что вы подменили название.
Минусы:
Сложность тонкой донастройки всех изменений если они будут касаться представления. То есть, если под каждым разрезом будут отличаться выводимые компоненты с детализацией, то придется танцевать с бубном.
Нет возможности делать Динамическими и фильтры на представлении и названия фильтров(все потому что фильтры могут быть завязаны на физическое поле из DataSet либо какой-то кастомный список.)
Заключение
Надеюсь у меня получилось визуализировать оба варианта решения одной задачи и отразить их сильные и слабые стороны. Но на самом деле вариант с использованием параметра как вводимых данных пользователем дает достаточно возможностей для реализации более сложных отчетов и расчетов на них. Также хочется и от продукта видеть определенный уровень сервиса. Надеюсь, на дальнейшее развитие продукта, и что FanRuan сделает более широким функционал использования параметров и добавит более динамики в общении отчета с пользователем. Если у вас есть опыт работы с параметрами, то поделитесь, пожалуйста, в комментариях какие кейсы использовали вы).