Отчеты в SOA (Business Intelligence & Service Oriented Architecture)

Проблема в том, что я вижу, что SSRS нарушает шаблон централизации контракта . Вместо этого ваш отчет должен быть создан либо из созданных вами сервисов, либо путем расширения этих служб. В противном случае вы создадите жесткую технологическую связь между вашим отчетом и вашими базами данных, что затруднит изменение, миграцию или повторное внедрение системы путешествий и сотрудников, когда это будет необходимо. Чем больше отчетов вы добавите таким образом, тем сложнее будет изменить вашу реализацию Travel and Employee.

Если вы еще этого не сделали, я бы создал операции с отчетами в службе путешествий, например, если вы используете службы на основе SOAP, добавьте операцию GetTravelRequests , которая принимает какие-то параметры запроса и разбиения на страницы, которые просто возвращают TravelID, запрос на поездку Дата, EmployeeID соответствующих записей. Затем создайте GetEmployeeTravelRequests , который GetTravelRequests с помощью функции GetEmployeeDetails из службы Employee.

Это будет медленнее, чем отчет, основанный на SSRS, но вы можете изменить базовую реализацию услуг Travel and Employee, если вы не измените контракт на обслуживание.

Я предположил, что вы используете SOAP, на что основан ответ, основанный, однако, если RESTful-сервисы являются опцией, тогда я бы рекомендовал следующее. Вместо того, чтобы выставлять числовые TravelID и EmployeeID s, вместо этого используйте URI . Например, туристическая услуга создаст туристический ресурс для URI сотрудника в базе данных Travel . Затем создайте подачу заявок на прохождение Atom . Вы можете либо остановиться там, и где пользователю отчета нужны детали сотрудника, они могут следовать за ссылкой URI сотрудника. В противном случае вы можете использовать URI сотрудников для создания собранного фида Atom, который включает сведения о сотрудниках для каждого запроса на поездку.

Основным преимуществом этого последнего подхода является снижение нагрузки БД за счет использования HTTP-кэширования; HTTP GET – самая оптимизированная операция в мире. Ваш отчет теперь является живым отчетом, а не только текущим, как когда он был создан в последний раз, который может быть один раз в день или раз в месяц, и если вы правильно структурируете фид, тогда страницы без заголовка никогда не меняются и могут быть кэшированы на год или дольше. Если вы предполагаете, что данные о сотрудниках меняются нечасто, вы можете установить максимальный возраст до 1 дня, и в этом случае запрос для конкретных сведений о сотрудниках будет только попадать в базу данных один раз в день.

Наконец, еще одно приятное преимущество заключается в том, что становится тривиально легко добавлять TravelRequests коллекции TravelRequests ресурсу Employee , который содержит TravelRequests на основе Atom список всех запросов на поездки для этого сотрудника.

Я не думаю, что ваш дизайн неправильный. Кажется, что в вашей архитектуре отсутствует пакет данных или склад или какой-то способ поддержки бизнес-аналитики в дополнение к обработке транзакций.

BI в SOA – сложная тема, и невозможно дать совет, не зная подробностей о вашей архитектуре. Но вот несколько статей, которые помогут вам начать:

• http://www.infoq.com/articles/BI-and-SOA
• http://blogs.informatica.com/perspectives/index.php/2008/09/30/how-soa-enhances-data-warehousing-and-business-intelligence/

Вы рассматривали ESB для своей SOA? Это может облегчить интеграцию данных в ваш SOA. См. Эту статью: http://www.b-eye-network.com/view/3018

Одним из потенциальных пользователей ESB является служба интеграции данных. Фактически, несколько вендоров изменили свою интеграцию данных и инструменты ETL (извлечение, преобразование и загрузка), чтобы управлять событиями, чтобы они могли потреблять сообщения о событиях из ESB. Эти события могут содержать информацию об изменениях исходных данных, которые могут использоваться службой интеграции данных для постепенного обновления хранилища оперативных данных (ODS) или хранилища данных. Этот подход особенно полезен для операционных приложений BI, для которых требуются данные внутри дня.

Это хороший пример такой путаницы, которая может возникнуть, когда вы не знаете о своих приоритетах в дизайне. И, в частности, на мой взгляд, слишком много проблем с техническими проблемами и недостаточно с требованиями пользователя.

Я начну с работы с заинтересованными сторонами, чтобы создать хороший набор пользовательских историй, достаточных для определения сферы действия проекта, и перечислить возможности, которые будут использоваться для теста приема первой фазы. Ваши шансы на успешный проект, а также на снижение вероятности редизайна позже, – это согласиться с описанием полного результата, который сразу же полезен и дает очевидную ценность после завершения первой фазы.

Он должен быть составлен полностью с точки зрения пользователя, даже без использования слов «firebase database», «SOA», «веб-сервис», «API» и т. Д.

То, что вы будете строить, будет своего рода договорным соглашением между вами и клиентом для ценной услуги; и как только он будет согласован, он не должен изменяться, кроме как увеличить его ценность для клиента в его / ее условиях. Таким образом, ваш лучший выбор – попытаться отложить рассмотрение вопросов «как», пока у вас не будет «то, что» прочно пригвождено.

Тогда у вас будет свобода рассмотрения различных технических параметров, которые могут быть использованы для устранения одного и того же результата. Часто есть фаза-один дизайн, который просто обеспечивает достаточно, чтобы заставить его работать; и вы хотите сохранить гибкость, чтобы учиться и настраивать заднюю часть любым способом, который вы считаете нужным, пока концептуальный контракт / логический дизайн не изменяется.

По моему опыту, все будут счастливее, если уделите ваше первое внимание тому, чтобы реагировать на ожидания пользователей (которые будут заполняться, как все узнают из процесса), а не предварительно оптимизировать технологию. Microsoft предоставляет множество способов сочетания и сопоставления и развития корпоративного дизайна. Если вы находитесь в Agile, не забудьте начать с наименьшего развития, которое работает, а затем повторится как сумасшедший.

Я не вижу в дизайне, что службе путешествий не потребуется доступ к службе Employee каким-то образом, форма или форма. Если они работают в виртуальной изоляции, тогда у вас будет проблема с управлением основными данными, ожидающая укуса.

Недавно я разработал архитектуру системы T & E с кадровыми данными в корпоративной инфраструктуре, а фронт-панель T & E – SaaS.

В этом случае система T & E требовала базового уровня данных о персонале в первую очередь для обеспечения проверки сотрудника. Также необходимо было позволить системе правильно обрабатывать бронирование поездок, не требуя от сотрудника повторного ввода ключевых данных.

Это было достигнуто путем доставки данных базового сотрудника в систему путешествий, сначала в виде массовой загрузки, а затем через обновления с изменением данных о сотрудниках. Это требует тщательной разработки, поскольку вы protractorуете некоторые данные PII, но безопасный транспортный протокол и хорошее шифрование между исходными и целевыми значениями для этого.

Затем отчетность о заказах на поездки и мероприятиях полностью входит в систему путешествий. Они должны храниться в состоянии хранилища, чтобы гарантировать, что изменения в записи базового сотрудника не загрязняют исторические записи о путешествиях. Это «транзакции» и их необходимо хранить как таковые.

Имея это в виду, хотя ваш дизайн не совсем неправильный, это не совсем так. Вы быстро столкнетесь с проблемами, которые вам нужны, чтобы пересмотреть ваш дизайн. Моя всеобъемлющая рекомендация заключалась в том, чтобы следовать советам @le dorfier и вернуться к началу. Дизайн для удовлетворения всех требований пользователя, убедитесь, что они являются реальными требованиями, а не просто «хочет» (т. Е. Приятно иметь). Естественный дизайн будет включать в себя требования не только к внешней стороне внешнего интерфейса, но также к отчетам, необходимым для удовлетворения бэкэнд.

Практически все, что мы разрабатываем сегодня, должно быть сделано с учетом интероперабельности, мы создаем модульное программное обеспечение с использованием компонентов и шаблонов, которые обеспечивают свободное соединение. Эта гибкость сэкономит нам неисчислимые усилия позже, и, хотя для проектирования требуется больше времени, это стоит того.