Итак, возьмем для примера простые два условия:
• Предположим, мы хотим закрывать все обращения, которые находятся в каком-то статусе более 7 дней.
• Далее, мы хотим видеть все нарушения по «срокам исполнения» обращений и помечать такие элементы.
Вот собственно и задачка, достаточно простая, но теперь давайте взглянем на нее с точки зрения больших объемов. – К чему это все приведет?
Первая задачка: если мы решили писать правило DB, следовательно, мы должны от чего-то отталкиваться. У нас есть условие, закрытые обращения более 7 дней. Значит, можно взять поле фактическое окончание и написать правило. Если прошло 7 дней от фактического окончания, то выполняем перевод статуса. Все правило готово.
Начинаем считать, сколько обращений регистрируется в день? Допустим 5000, из них закрывается в день 2500, остается 2500 – теперь делаем расчет: 7 дней = 17500 scheduled task висит в воздухе и прибавляется с каждым днем.
Теперь пишем правило для нарушения сроков. Принцип тот же, но учет будет другим, реагировать будем на запись в scheduled по изменению срока. Представьте, сколько раз может меняться срок из 5000 элементов. Каждое изменение срока записывается в scheduled task. А теперь самое веселое, берем одну тысячу элементов и двигаем срок, скажем, на 18:00, сроки будем считать по графику с 9:00 до 18:00, выходит, проверка должна начаться в 9:01, сотрудники тоже начинают работать в 9 утра. Следовательно, чем будет заниматься APP в утреннее время, не считая того, что у него еще помимо работы scheduled есть и пользователи, которые жаждут сдвинуть сроки, чтобы не было просрочки.
Теперь, если немного еще углубиться, то мы увидим еще один момент во втором правиле. Срок то проверяется, скажем, по статусам, если мы учитываем тот факт, что обращение должно быть в работе. А что же происходит с scheduled – ничего, он как висел, так и висит и дожидается, когда провести проверку. Выходит, время исполнения может быть волновым, если сроки по большому количеству элементов двигать групповой правкой. Элемент уже может быть закрыт, а scheduled висит.
Вот вам первый вариант перегрузки системы правилами на scheduled task.
Какие же есть выходы из ситуации:
Если нам очень критичны сроки, то для второго правила нужно будет учить систему удалять scheduled, после того как обращение перевалило за порог нужных статусов.
Первое условие можно перевести на JOB, тогда данные элементы будут закрываться не на app сервере, а на самом sql (мгновенно).
Пример:
declare @to datetime
set @to = getdate()
set @to = convert(char(11),@to)
UPDATE [HPOVSDDB].[dbo].[ITSM_SERVICECALLS]
SET [ser_sta_oid] ='3094610096'
WHERE SER_ACTUALFINISH < @to-7 and ser_sta_oid = '3094610095'
Также, второе правило можно тоже перевести на JOB и реагировать, скажем, каждые 30 мин. Минус только в том, что для данного условия нужно очень хорошо понимать, какое действие мы будем выполнять после найденных элементов, и как мы будем снимать статистику.
Подведем итог:
Во-первых, рулы APP не будут видеть все изменения, которые производятся прямо в БД.
Во-вторых, все подобные изменения нигде не будут отраженны в системе.
В-третьих, дата в базе храниться в UTC-0, а люди работают каждый в своем регионе, как и нахождение сервера.
По этим причинам данный механизм подойдет далеко не каждому. Наверное, самое правильное решение, это допиливать scheduled task.
