Введение
Современная экономическая ситуация в сфере API-интерфейсов характеризируется весьма активным применением API-интерфейсов в бизнес-решениях и в архитектурном проектировании. Тем не менее, качественным характеристикам API-интерфейса уделяется не слишком много внимания. Если вы серьезно относитесь к качеству своих бизнес-решений, то вам нужно не менее серьезно относиться и к масштабируемости, доступности, производительности и безопасности создаваемого вами API-интерфейса.
Если говорить о производительности, то существуют сценарии, в которых API-интерфейсы могут интегрироваться со всеми типами источников данных/сервисов, и зависеть от серверного сервиса, время реакции которого может превышать несколько секунд. Этот серверный сервис может стать узким местом для API-интерфейса вашего клиента и, соответственно, оказать отрицательное воздействие на все бизнес-решение.
Например, в сфере цифрового маркетинга насыщенный пользовательский интерфейс вызывает API-интерфейс, который извлекает данные из отчетов IBM Cognos. Вследствие высокой сложности процесса обработки данных, а также логики интеллектуализации бизнеса время исполнения может исчисляться минутами. По любым меркам это неприемлемо для конечного пользователя, взаимодействующего с критически важным для бизнеса приложениями.
Возможно ли создание API-интерфейса, способного превзойти соответствующие серверные сервисы? Несомненно! Эту цель можно достичь путем применения технологии WebSphere DynaCache в конструкции API-интерфейса и создания возможностей многократного использования этого актива в аналогичных бизнес-сценариях в качестве высокопроизводительного API-интерфейса, интегрированного с медленными серверными сервисами.
Обзор API-интерфейсов на основе REST для отчетов Cognos BI
Продукт Cognos Business Intelligence (Cognos BI) способен создавать отчеты и анализировать данные из множества источников данных. Продукт Cognos BI состоит из множества компонентов. Компонент Cognos Report Studio предназначен для создания отчетов и их публикации на сервере Cognos BI. Пользователи могут обращаться к этим отчетам через порталы Cognos.
Кроме того, Cognos BI позволяет обращаться к опубликованным отчетам программным способом - с помощью решения Cognos Mashup Service при посредстве протоколов REST и SOAP.
Как показано на рис. 1, решение Cognos Mashup Service (CMS) предоставляет базовые возможности доступа для дистанционного "потребления" отчетов. Однако в случае востребованных бизнес-приложений, которые обслуживают тысячи пользователей, вам придется - в дополнение к базовому сервису, предоставляемому решением CMS в готовом виде - озаботиться такими аспектами, как доступность, масштабируемость и качество данных.
Рисунок 1. Решение Cognos Mashup Service: обзор интерфейса
В следующих разделах мы покажем, как создать API-интерфейс для существующего отчета Cognos с использованием протокола REST.
Каждый отчет, созданный в инструменте Cognos Report Studio, идентифицируется с помощью уникального имени, которое пользователь предоставляет именно с этой целью. Кроме того, инструмент Cognos Framework Manager генерирует для каждого отчета уникальный идентификатор, который также можно использовать для идентификации соответствующего отчета. Чтобы вызвать отчет, клиентскому приложению требуется такой уникальный маршрут поиска или уникальный идентификатор.
Ниже показан пример структуры URL-адреса для вызова отчета с использованием имени отчета и его маршрута.
Ниже показан пример структуры URL-адреса для вызова отчета с использованием идентификатора отчета.
Отчеты могут иметь различные опции, например, fmt=DataSet.
Эта опция позволяет предоставлять результирующий отчет Cognos в формате XML, который содержит только данные отчета, но не содержит его разметку. Различные опции отчета описываются в документации по Cognos Mashup Service.
Доступ к отчетам Cognos из Java-приложения
В этом учебном пособии показано, как обратиться к отчету Cognos с помощью простого клиента HTTPClient без каких-либо зависимостей от SDK-комплекта Cognos в приложении. Тем не менее, SDK-комплект Cognos можно использовать для повышения управляемости и для сложных манипуляций. Для получения информации по использованию SDK-комплекта Cognos обратитесь к документации по Cognos.
В листинге 1 показан пример приложения для вызова URL-адреса отчета Cognos с помощью библиотеки Apache HTTPClient.
Листинг 1. Вызов отчета Cognos по HTTP
Если сервер Cognos является защищенным, то вместо http используйте https и сделайте несколько HTTP-вызовов для входа на сервер с целью исполнения отчета, а затем для финального выхода из системы. Для входа на сервер Cognos (и выхода из него) по URL-адресу можно воспользоваться следующим форматом: https://webservername:portnumber/<cognos context path>/rds/auth/logon.
Учетные данные для входа в систему передают в виде XML-строки. Для получения дополнительной информации обратитесь к документации по Cognos Mashup Service. На рис. 2 показано взаимодействие API-клиентов с отчетами Cognos при наличии соединений с различными источниками данных.
Рисунок 2. Интеграция приложения пользователя с данными из отчета Cognos
Использование инфраструктуры WebSphere DynaCache
Инфраструктура DynaCache - это сервис, поставляемый с продуктами WebSphere по умолчанию. Это облегченное решение кэширования для распределенных приложений, удовлетворяющее потребности заказчика в кэшировании.
Сервис DynaCache исполняется на сервере приложений в JVM-машине ( Java™ Virtual Machine), перехватывая вызовы к кэшируемым объектам. Например, он перехватывает вызовы с помощью метода service сервлета или метода execute команды. Он сохраняет выходную информацию объекта в кэше или обслуживает контент объекта из динамического кэша.
В этом учебном пособии мы будем кэшировать объекты с помощью файла cachespec.xml. Сначала вам нужно активировать динамический кэш в среде WebSphere. Затем вы можете создать файл cachespec.xml и поместить его в раздел WEB-INF веб-модуля.
В состав установочного пакета WebSphere входит монитор кэша по умолчанию в виде EAR-файла (Enterprise Application). В случае необходимости вы можете развернуть и сконфигурировать этот EAR-файл. Он предоставляет простой пользовательский интерфейс для мониторинга объектов кэша и инвалидизации объектов в кэше. На рис. 3 показан пример списка кэшированных объектов с их атрибутами в процессе исполнения, полученного с помощью инструмента WebSphere Cache Monitor. Обратитесь к документации по конфигурированию кэшируемых объектов относительно настройки динамического кэша с использованием файла cachespec.xml.
Рисунок 3. Атрибуты кэшированных объектов в процессе исполнения, полученные с помощью инструмента Cache Monitor
Обобщение вышеизложенного материала
Теперь вы можете извлекать данные из отчетов Cognos и интегрировать их со своим приложением. Следующая задача состоит в том, как повысить производительность.
Во многих случаях отчеты Cognos базируются на результатах анализа, связанного с извлечением сложных данных из распределенных систем, поэтому для формирования такого отчета может потребоваться несколько минут. Если эти отчеты интегрируются в приложения, то столь долгое ожидание не будет способствовать улучшению взаимодействия с пользователем. В следующем разделе показано, как интегрировать отчет Cognos с приложением пользователя таким образом, чтобы существенно повысить скорость функционирования.
В предыдущих разделах было показано, как интегрировать данные из отчетов Cognos в приложение пользователя. Кроме того, мы кратко рассмотрели технологию DynaCache, предлагаемую вместе в продуктами WebSphere.
Динамическое кэширование очень эффективно для отчетов, формирование которых занимает много времени. В дополнение к регулярным API-сервисам по требованию, вы можете запланировать выбранные API-интерфейс для исполнения в "непиковые" периоды времени, чтобы заранее загрузить в динамический кэш эти требовательные и долго формирующиеся объекты отчета.
Когда пользователь дает приложению указание загрузить данные из отчета, приложение ищет DynaCache и загружает контент из этого кэша, что позволяет мгновенно предоставить данные пользователю. Кэш можно настроить таким образом, чтобы он избавлялся от устаревших данных. На рис. 4 показано, каким образом DynaCache повышает производительность API-интерфейса Cognos.
Рисунок 4. Повышение производительности приложения путем кэширования данных отчета с помощью WebSphere DynaCache
Чтобы инкапсулировать логику и вызвать отчет Cognos с помощью HTTP-клиента CognosReportHelper, создается POJO-объект. Затем реализуется класс CognosReportCacher, расширяющий класс com.ibm.wbephere.command.CachealeCommandImpl. Этот класс содержит данные отчета в формате XML-строки; именно он кэшируется в DynaCache для каждого экземпляра уникального отчета. В этом классе обязательно должны быть реализована следующие два метода: isReadyToCallExecuted и performExecute. В методе performExecute осуществляется обращение к отчету Cognos путем вызова представленного метода в классе CognosReportHelper (рис. 6).
После этого программный код приложения пользователя вызывает метод execute класса CognosReportCacher (рис. 5), который наследуется от класса CacheableCommandImpl.
Примечание. Примеры программного кода в этом учебном пособии показаны в качестве иллюстрации. Если вы собираетесь использовать этот код в своей производственной среде, рекомендуется произвести его дополнительную настройку и тестирование.
Рисунок 5. Пример программного кода для класса CognosReportCacher
Рисунок 6. Пример программного кода для класса CognosReportHelper
В приложении пользователя вызов отчета Cognos осуществляется следующим образом (рис. 7).
Рисунок 7. Пример программного кода для приложения пользователя
На рис. 8 показана диаграмма последовательности для примера программного кода.
Рисунок 8. Диаграмма последовательности
В листинге 2 показано определение cachespec.xml.
Листинг 2. Определение cachespec.xml
<?xml version="1.0"?> <!DOCTYPE cache SYSTEM "cachespec.dtd"> <cache> <cache-entry> <class>command</class> <sharing-policy>not-shared</sharing-policy> <name>com.myservice.cognos.reports.CognosReportCacher</name> <cache-id> <component type="method" id="getReportKey"> <required>true</required> </component> <timeout>604800</timeout> <inactivity>604800</inactivity> </cache-id> </cache-entry> </cache>
getReportKey() - это callback-метод, который требуется файлу cachespec.xml для инфраструктуры DynaCache. Он функционирует как идентификатор кэша, чтобы предоставить уникальный ключ для объекта отчета в кэше, позволяющий направлять повторные API-вызовы в этот кэш. Если вызов одного и того же отчета производится с разными параметрами, эти параметры добавляются к вышеупомянутому ключу, чтобы сделать его уникальным. Как показано в примере кода на рис. 5, метод getReportKey() возвращает полный URL-адрес запроса вызывающей стороны. Значение параметра тайм-аута представлено количеством секунд, после истечения которых кэш избавляется от этого объекта.
Еще одно важное соображение при проектировании решения - это правило инвалидации кэша. Данное правило определяет, как должно завершаться существование кэшированных объектов, чтобы кэш обновлялся надлежащим образом. Управление этой задачей должно осуществляться в соответствии с требованиями бизнеса - в зависимости от частоты изменения источника данных и от того, насколько важной является синхронизация реакции API-интерфейс с источником данных.
В этом примере источник данных обновляется один раз в неделю. Соответственно, применяется простое правило на основе таймаута кэша (604800). В более сложных сценариях можно осуществлять инвалидизацию кэш согласно правилам или спроектировать триггерные события для программной очистки кэша. Это имеет большое значение для высокопроизводительных API-интерфейсов, применяемых в производственной среде. Другими словами, вам следует сбалансировать высокую производительность и согласованность данных с потребностями своего бизнеса.
Преимущества WebSphere eXtreme Scale
Механизм DynaCache - это поставщик кэша по умолчанию, обеспечивающий базовые возможности динамического кэширования для ваших API-интерфейсов. Однако если вам требуются расширенные возможности, такие как транзакционная поддержка, улучшенная масштабируемость и высокая готовность, вы можете за дополнительную плату сконфигурировать в качестве поставщика кэша продукт WebSphere eXtreme Scale.
Хорошая новость состоит в том, что для работы с технологией eXtreme Scale вам не нужно переписывать свой API-код. Достаточно выполнить следующие шаги.
- Установите клиент eXtreme Scale на своем сервере приложений для удаленного сервера или клиент eXtreme Scale плюс серверные пакеты в других топологиях, соответственно.
- Сконфигурируйте поставщика динамического кэша eXtreme Scale в качестве своего поставщик кэша в среде WebSphere Application Server.
- Перезапустите сервер.
Заключение
В учебном пособие было показано, как интегрировать приложение с данными из существующего отчета Cognos с помощью решения Cognos Mashup Service при посредстве REST. Кроме того, было продемонстрировано кэширование данных отчета с использованием технологии WebSphere DynaCache с целью повышения производительности.
Это решение можно распространить на другие сценарии интеграции с медленными серверными сервисами. Созданные конфигурации DynaCache можно по-прежнему использовать для аналогичных шаблонов интеграции вне зависимости от серверного сервиса. Для повышения емкости при кэшировании мы рекомендуем заменить механизм WebSphere DynaCache (поставщик кэша по умолчанию) на механизм WebSphere eXtreme Scale - в качестве поставщика подключаемого сервиса, что позволит избежать переписывания вашего API-кода при этой замене.