Часть 9. 

Часть 1  Часть 2  Часть 3  Часть 4  Часть 5  Часть 6  Часть 7  Часть 8

Оглавление

4. KPI MODELER

4.1. Основные этапы работы в KPI Modeler

4.2. Создание KPI

4.3. Создание оценки

4.4. Конфигурирование плитки

4.5. Создание аналитической диаграммы

4.6. Создание альтернативной аналитической диаграммы

4.7. Применение подготовленной KPI-плитки

4. KPI MODELER

4.1. Основные этапы работы в KPI Modeler

Одна из стандартных возможностей, имеющихся в арсенале инструментов Fiori Launchpad – это создание плиток, визуализирующих уровень одного из ключевых показателей эффективности бизнеса (KPI). Пользователи могут обычным путём разместить эту плитку на своей стартовой странице и контролировать важный показатель, не переходя ни в какие дополнительные приложения. В то же время, если плитка-индикатор (KPI-плитка) покажет неудовлетворительный уровень показателя, есть возможность открыть отчёт для детального анализа ситуации. Инструменты, позволяющие конструировать подобные плитки-индикаторы, собраны в группе KPI Design и носят название KPI Modeler (см. Рис. 113).

Рис.113. Плитки, реализующие функциональность KPI Modeler

Создание KPI-плитки состоит из нескольких этапов. Можно проходить эти этапы не прерываясь, последовательно, в итоге сразу получив готовую плитку (этот подход будет проиллюстрирован примерами далее).  Но также можно и повторно использовать объекты, созданные на одном шаге, чтобы создать несколько вариантов на следующем этапе. Для этого все этапы выведены отдельными плитками в группе KPI Design. Перечислим эти этапы:

• Создание анализируемого показателя (KPI). На этом этапе нужно указать: какой массив данных будет использоваться (имя CDS-ракурса и другие технические параметры доступа к данным), какой числовой показатель из этого массива нужно отслеживать, какое «поведение» показателя считать «правильным». Под «правильным поведением» понимается бизнес-интерпретация показателя. Например, если мы отслеживаем сумму оборотов в сети магазинов, то с точки зрения бизнеса этот показатель «чем больше, тем лучше». А если мы отслеживаем процент отходов сырья на производстве, то наоборот – чем меньше, тем лучше.
• Следующий этап – создание так называемой оценки. Задача KPI-плитки – это отражение «хорошего» или «плохого» уровня отслеживаемого показателя. И на этапе оценки нужно указать: какие конкретно значения являются пороговыми для того, чтобы признать уровень показателя «хорошим» или «плохим». Кроме того, слово «оценка» имеет здесь ещё один смысл. Нам нужно указать значения параметров, фильтрующих данные из CDS. Параметры соответствуют тем, которые заданы в CDS-ракурсе (например, аэропорты вылета и назначения в ракурсе ZC_FLIGHTBYAIRPORTQUERY). Таким образом, определяется массив оцениваемых данных.
• Третий этап – конфигурирование KPI-плитки. Здесь можно выбрать один из предлагаемых стандартом вариантов визуализации. И в зависимости от выбранного варианта заполнить ряд соответствующих параметров.
• Создание детальных отчётов. На этом этапе создаются отчёты (в виде таблиц или диаграмм), которые пользователь сможет увидеть, если нажмёт на KPI-плитку. Отчётов может быть несколько. Их задача – используя тот же источник данных, что и плитка, показать пользователю детальный анализ показателя, чтобы помочь установить причины его негативной динамики.
• На последнем этапе готовая KPI-плитка размещается на Fiori Launchpad. Здесь выполняются те же действия, как и в примерах, рассмотренных ранее.

Для работы KPI Modeler необходимо выполнить несколько предварительных настроек в системе Front-End. Во-первых, в транзакции SICF активировать сервис /sap/bc/ui5_ui5/sap/sb_apps_kpis1. Во-вторых, в транзакции /IWFND/MAINT_SERVICE активировать OData-сервисы SMART_BUSINESS_RUNTIME_SRV и SMART_BUSINESS_DESIGNTIME_SRV. Как и раньше, эти сервисы должны использовать Alias, указывающий на систему Back-End. В-третьих, необходимы те же настройки, которые описаны выше для Query Designer. И те же роли для пользователя FIORI_ADM, под которым создаются все рассматриваемые здесь примеры.

В следующих разделах создание KPI-плитки будет проиллюстрировано практическим примером, вновь использующим CDS-ракурс ZC_FLIGHTBYAIRPORTQUERY. В нём есть показатель «Available Seats» - число нераспроданных мест на авиарейсах. Очевидно, что задача авиакомпаний – минимизировать значение данного показателя.

4.2. Создание KPI

Итак, в соответствии с намеченным планом, первый этап работы – определить анализируемый показатель. Это можно сделать, нажав плитку Create KPI (см. Рис. 113). Первый раздел данного приложения – это общие параметры будущего KPI: его техническое имя, название, направление «правильного поведения». В нашем примере заполним эти поля так, как показано на Рис. 114.

Рис.114. Параметры KPI

Ниже расположена следующая группа полей. Она описывает технические параметры источника, из которого будут извлекаться анализируемые данные (см. Рис. 115).

Рис.115. Параметры источника данных для KPI

Кратко поясним порядок заполнения полей:

• В поле «CDS View» нужно указать имя CDS-ракурса: ZC_FLIGHTBYAIRPORTQUERY. Как обычно, здесь есть удобная возможность выбора имени из списка, с контекстным поиском.
• Для нашего ракурса создан и активирован OData-сервис, поэтому заполнение следующего поля «OData Service» становится элементарным: там список доступных сервисов содержит только то значение, которое нужно.
• Затем также легко заполняется выбором единственной строчки списка и поле «Entity Set». Оно указывает на тот массив данных, который нужно считывать через ранее выбранный OData-сервис. Дело в том, что SAP Gateway имеет широкие возможности создания и конструирования сложных OData-сервисов. В нашем примере сервис ZC_FLIGHTBYAIRPORTQUERY_CDS просто публикует для приложений-потребителей данные из одного CDS-ракурса. Именно они и образуют единственный массив данных, доступных через этот сервис. Но в более сложных разработках OData-сервис может предоставлять доступ к нескольким массивам данных. И тогда список выбора в поле «Entity Set» будет перечислять все эти массивы.
• Теперь, когда указан массив анализируемых данных, остаётся выбрать из списка в поле «Value Measure» нужный показатель.

Определение KPI и его источника данных на этом завершено. Переходим к следующему этапу, нажав кнопку «Activate and Add Evaluation» (см. Рис. 115). Назначение других кнопок, расположенных рядом, представляется очевидным. При нажатии указанной кнопки появляется окно, предлагающее поместить создаваемый объект в транспортный запрос. Для целей данного примера можно указать в этом окне, что созданный KPI является локальным объектом.

4.3. Создание оценки

Приложение создания оценки тоже разделено на несколько групп полей. Первые две группы описывают параметры и источник данных. Они уже заполнены автоматически теми значениями, которые были указаны на Рис. 114-115. Обязательным полем здесь является название оценки (см. Рис. 116).

Рис.116. Название и описание создаваемой оценки

Информацию об источнике данных оставим без изменения и перейдём к следующей группе полей, определяющих фильтр для отбираемых из CDS-ракурса данных (см. Рис. 117).

Рис.117. Определение фильтра, отбирающего данные для оценки

Поскольку в DDL-коде ракурса только аэропорт вылета был указан как обязательный для заполнения элемент селекционного экрана, то именно это поле и выведено на Рис. 117. Как и в случае с Query Browser, выберем для примера фильтрацию по нью-йоркскому аэропорту JFK. Есть также возможность добавить и необязательные фильтры по другим аналитикам ракурса, если воспользоваться ссылкой «Optional Filters».

Наконец, в последней группе полей остаётся указать пороговые значения показателя, по которым создаваемая оценка будет определять: является ли значение хорошим или критическим. На Рис. 114 уже показано, что оцениваемый KPI считается «тем лучше, чем меньше». Оценка работает по принципу светофора, то есть должна иметь три уровня: хороший (зелёный), тревожный (жёлтый) и критический (красный). Учитывая это, заполним параметры так, как показано на Рис. 118.

Рис.118. Определение пороговых значений для оценки KPI

Чтобы перейти к следующему этапу работы, нужно нажать кнопку «Activate and Configure Tile».

4.4. Конфигурирование плитки

Прежде всего, необходимо определить тип создаваемой KPI-плитки. На выбор разработчика предлагается несколько вариантов. В верхней части окна представлены образцы, иллюстрирующие внешний вид каждого из доступных вариантов (см. Рис. 119).

Рис.119. Возможные варианты KPI-плиток

Выбрать подходящий вариант можно, нажав на него левой кнопкой мыши. При этом состав полей с настроечными параметрами, расположенных ниже, автоматически изменится в соответствии с выбранным вариантом (см. Рис. 120). Также подходящий вариант можно выбрать из списка в поле «Tile Format». Для нашего примера выбран формат Dual Tile. Это формат, предполагающий плитку увеличенного, двойного размера. В ней как бы расположены рядом сразу две плитки. Слева – общая оценка для KPI, в которой его числовая величина окрашена цветом в соответствии с пороговыми значениями. Справа – более детализированный анализ значений KPI.

Первоначально поля «Title» и «Subtitle» заполнены названиями используемых KPI и оценки. Исправим их, как показано на Рис. 120. Эти названия будут служить заголовком и подзаголовком плитки, когда она появится на Fiori Launchpad. Любая плитка должна располагаться в каком-то из каталогов. В поле «Catalog» нужно выбрать из списка каталог Z_RDS_BC (здесь снова удобно воспользоваться контекстным поиском). Параметр «Cache Duration» определяет – как часто плитка будет запрашивать обновлённые данные из системы Back-End.

Рис.120. Настроечные параметры для