Цього тижня ми розглянемо основи служби Cognos Mashup. Ми поділимо його на складові частини, щоб побачити, як він приносить цінність поєднанню пропозицій IBM Cognos.
Щоб скористатися послугою Cognos Mashup, потрібно відповідати таким мінімальним вимогам:
1. Сервер IBM Cognos BI 8.4.1
2. Клієнт, здатний взаємодіяти з SOAP або службами на основі URL -адрес через HTTP
Доступ до Cognos Connection та служби Cognos Mashup можна отримати через шлюз Cognos
Примітка авторів: Використовуйте голос актора Р. Лі Ермі (Ганні з Суцільнометалева оболонка)
У наступних кількох статтях я буду вашим інструктором. Ви можете називати мене «сержант -дриль». Я буду розбивати вас, новобранців, на дрібні піщинки, з яких вийшло, і будуватиме вас назад у лазерно -травлені шматочки кремнію. Ви підете звідси з інструментами, які вам потрібні, щоб вижити на полі бою, відомому як служба Cognos Mashup. Ви зможете кодувати свій шлях через небезпечну власну візуалізацію місцевості. Ви зможете відрізнити друга від ворога, коли мова йде про поняття дизайну. Можливо, ви думали, що вас обіцяє обіцянка легких послуг REST. Але це не відпочинок вашої мами. Чи можу я отримати "ТАК СЕРЖАЖ ДРІЛЛЯ!"? А тепер кинь і дай мені двадцять!
Гаразд, дозвольте мені відпочити від характеру, щоб сказати вам прямо. Цього тижня ми розглянемо основи служби Cognos Mashup. Ми поділимо його на складові частини, щоб побачити, як він приносить цінність поєднанню пропозицій IBM Cognos.
Щоб скористатися послугою Cognos Mashup, потрібно відповідати таким мінімальним вимогам:
1. Сервер IBM Cognos BI 8.4.1
2. Клієнт, здатний взаємодіяти з SOAP або службами на основі URL -адрес через HTTP
Доступ до Cognos Connection та служби Cognos Mashup можна отримати через шлюз Cognos
Послуга Cognos Mashup складається з двох окремих частин, які працюють в парі, щоб дозволити споживачам розбивати дані звітів поза засобом перегляду звітів та створювати власні візуалізації. Одна частина послуги - це транспортний інтерфейс, а інша - корисне навантаження. На діаграмі нижче ми можемо розглядати запит як транспорт, а відповідача як корисне навантаження.
Транспортний інтерфейс - це засіб, за допомогою якого ми можемо викликати звіти. Споживачам є два варіанти використання. Один на основі SOAP, а інший використовує URL -адреси в стилі REST. Обидва інтерфейси працюють через HTTP і схожі за структурою. Тобто для кожної логічної операції в інтерфейсі стилю SOAP існує відповідна операція в стилі REST. Точні специфікації методу враховують ідіосинкразії для обраного стилю виклику. Але суть в тому, що… можливість входу, виклику звіту, отримання результатів та виходу з системи доступна для обох таборів.
Тож ви можете запитати себе: "Я, чому я вибрав би одне над іншим?" Часто відповідь на це питання виникає при розгляді технології проекту або умовностей. Візьмемо приклад споживача, який повністю розроблений на стороні клієнта. Він використовує HTML та JavaScript для взаємодії зі службою Cognos Mashup. У вакуумі інтерфейс на основі REST URL полегшить інтеграцію. На противагу цьому, інший проект може мати наявні активи Cognos SDK у сервлеті Java. Вони звикли до заглушок SOAP, розкритих SDK. Цілком природно, що ця ситуація схиляється до того, щоб бути споживачем служб змішування на основі SOAP. На практиці це не був складний вибір. При розгляді двох варіантів вибір завжди виглядає краще, коли розглядається загальне рішення. Спроби використовувати іншого відчувають себе вимушеними.
Логічні операції, пропоновані транспортним інтерфейсом, дозволяють споживачеві виконувати завдання, зосереджені на запуску звітів та аналізів Cognos. Набір опцій дозволяє споживачеві пройти повний життєвий цикл створення звіту. Це включає:
• Автентифікація
• Призначення параметрів
• Виконання звіту (синхронне та асинхронне)
• Поведінка дриля
• Виведення результатів
Служба змішування навіть пропонує деякі смаколики, які недоступні через SDK. Однак ми збережемо це обговорення для майбутньої статті, в якій порівнюватимемо та порівнюватимемо службу Mashup із SDK.
Тепер у нас є спосіб викликати звіти через набір сервісів на основі HTTP. Що виходить з іншого кінця? Це призводить нас до другого компонента служби змішування. Введіть ... "Корисне навантаження".
Одним з варіантів, які ми можемо вказати під час виклику звіту через службу змішування, є формат виводу. Існує ряд доступних опцій, включаючи HTML XML (LDX) та JSON. Є кілька інших, але це охоплює спектр в abroad сенс. HTML - це те, що можна очікувати. Вони виглядають дуже схоже на те, що можна отримати від звіту, переглянутого за допомогою засобу перегляду звітів у Cognos Connection. Більш перспективні формати - LDX і JSON. Насправді, якщо сервіс Cognos Mashup чітко зазнав удару, це запровадження цих двох форматів.
Обидва ці формати забезпечують вихід звіту у нейтральному для презентації форматі. Це дозволяє споживачеві виводу звіту відтворювати інформацію у будь -якій візуалізації, яка може розуміти JSON або XML. Знайдіть хвилину, щоб прочитати це ще раз.
Дані звіту тепер звільняються від путів, покладених на них засобом перегляду Cognos. Тепер дані можуть кочувати в місцях, які раніше були недоцільними. Наприклад, Rich Internet Applications можуть використовувати фреймворки, такі як Google Visualization API або Ext-JS, щоб пожвавити презентацію даних. Мобільна інтеграція стає набагато більш доступною, оскільки вихід можна адаптувати до цих пристроїв. Дані Cognos можна по -справжньому зібрати за допомогою даних із зовнішніх джерел. Насправді, дані з Cognos BI нещодавно були помічені в дикій природі і не менше співпадали з даними популярної системи управління контентом у тій же сітці Ext-JS! Скандально! Що це значить? У цьому випадку це дозволило керувати обома наборами даних за допомогою власних інструментів без складного надуманого процесу, щоб об'єднати їх у браузері.
Нижче наведено простий макет низької точності, що ілюструє неоднорідні джерела даних, які мають спільну сторінку.
Ця гнучкість пов'язана з деякими компромісами. Оскільки ми відкладаємо передачу даних в іншу частину програми, ми, по суті, передаємо частину розробок, які традиційно виконуються автором звіту, особі, яка є експертом у технології візуалізації. Спроби переплести дані звіту у візуалізацію будуть відрізнятися порівняно з написанням ідеального піксельного звіту в традиційних студіях Cognos. Планувальники проектів повинні розуміти вплив, який це має на терміни розробки. Хтось виявить, що оцінки є більш точними, коли буде прийнятий цей новий розподіл праці.
Підводячи підсумок для цього фрагменту, сервіс Cognos Mashup - це захоплююче доповнення до арсеналу інструментів, доступних суміші. Це дозволяє вийти за рамки простого штампування даних BI , що містить переглядач звітів, на сторінку HTML. Проте час навчив нас, що ніщо не є безкоштовним. Гнучкість подання даних відбувається за рахунок впровадження нових наборів навичок у набір рішень. Нехай ця інформація на деякий час просочиться. У наступних записах цієї серії ми більш детально розглянемо використання мешапу, а також те, як він поєднується з іншими кандидатами на рішення.
