Проблема из того, что я вижу, состоит в том, что SSRS нарушает шаблон централизации договора . Вместо этого ваш отчет должен быть сгенерирован либо из созданных вами сервисов, либо путем расширения этих сервисов. В противном случае вы создадите тесную технологическую связь между вашим отчетом и вашими базами данных, что сделает более трудным изменение, миграцию или повторное внедрение ваших систем командировок и сотрудников, когда возникнет такая необходимость. Чем больше отчетов вы добавите таким образом, тем сложнее будет изменить реализацию командировок и сотрудников.
Если вы этого еще не сделали, я бы создал операции отчетности для службы путешествий, например, если вы используете службы на основе SOAP, добавьте операцию GetTravelRequests, которая принимает какие-то параметры запросов и разбивки на страницы, которые просто возвращают TravelID, Дата запроса на поездку, EmployeeID соответствующих записей. Затем создайте GetEmployeeTravelRequests, который составляет GetTravelRequests с операцией GetEmployeeDetails из службы Employee.
Это будет медленнее, чем в отчете на основе SSRS, но вы можете затем изменить базовую реализацию служб Travel и Employee, если вы не измените договор на обслуживание.
Я вроде бы предположил, что вы используете SOAP, на чем основан ответ, приведенный выше, однако, если RESTful-сервисы являются опцией, я бы порекомендовал следующее. Вместо предоставления числовых значений TravelID s и EmployeeID s вместо используйте URI . Например, служба командировок создаст ресурс командировки для URI сотрудника в базе данных Travel. Затем создайте поток на основе Atom запросов на поездки. Вы можете остановиться и там, где пользователю отчета нужны данные о сотруднике, они могут перейти по ссылке URI сотрудника. В противном случае вы можете использовать URI сотрудника для создания составного канала Atom, который включает сведения о сотруднике для каждого запроса на командировку.
Основным преимуществом этого последнего подхода является снижение нагрузки на БД за счет использования HTTP-кэширования; HTTP GET - самая оптимизированная операция в мире. Ваш отчет теперь является отчетом в режиме реального времени, а не таким текущим, как в тот момент, когда он был сгенерирован в последний раз, что может быть один раз в день или один раз в месяц, и если вы правильно структурируете свой фид, страницы, не являющиеся заголовками, никогда не изменятся и могут быть кэшированы на год или дольше. Если вы предполагаете, что данные о сотрудниках меняются нечасто, вы можете установить максимальный возраст 1 день, и в этом случае запрос данных о конкретных сотрудниках будет попадать в базу данных только один раз в день.
Наконец, еще одним приятным преимуществом является то, что стало легко добавлять ресурс коллекции TravelRequests в ресурс Employee, который содержит разбитый на Atom список всех командировочных запросов для этого сотрудника.