Просто концепция, поскольку решение относительно велико:
Поскольку вам не разрешено что-либо менять в схеме / конфигурации базы данных, тогда возможный подход может заключаться в использовании запланированной функции / логикиприложение, чтобы периодически запрашивать ваш SQL Server и затем выводить в концентратор событий.Для такого рода операций я лично предпочел бы функции, потому что у меня был бы более подробный контроль над обработкой.Так или иначе, обе службы должны работать.
Интервал, с которым вы будете запрашивать SQL Server, полностью зависит от того, насколько быстро изменяются ваши исходные данные.
Поскольку у вас нет никакого представления о том, когда исходные данные были изменены / добавлены / удалены, вы должны сделать своего рода реплику: полную или частичную.В любом случае у вас должен быть какой-то уникальный идентификатор ваших событий.Каждый раз, когда вы запрашиваете исходные данные, вы должны сравнивать результаты с предыдущими, а затем решать, что будет добавлено, удалено, изменено.Это будет очень медленно, если исходные данные большие.Однако я не могу найти другой подход.Однако возможны некоторые улучшения, если вы часто запрашиваете исходные данные в поисках:
- того, что было изменено, из тех событий, которые уже прочитаны (идентифицируются по их уникальному идентификатору)
- что было удалено из тех событий, которые уже прочитаны (идентифицированы по их уникальному идентификатору)
- что было добавлено - не присутствует в тех событиях, которые уже прочитаны (идентифицированы по их уникальному идентификатору)
Итак, для каждого запроса вы должны передавать идентификаторы всех прочитанных событий.
Надеюсь, это поможет.