Настройка задач планировщика

В менеджере задач каждой загруженной карте указывается сопоставленный в настоящий момент договор. В случае, если карта заносится на договор текущей датой, то привязка договора к карте обновляется сразу, иначе это делает задача планировщика Установка договоров картам CerberCrypt. Задача должна быть установлена на 0 часов 0 минут каждого дня.

В конфигурации задачи указывается код модуля.

Задача Установка статусов пакетам карт CerberCrypt устанавливает картам договора актуальные статусы, основываясь на заданиях по смене статуса. Должна запускаться в 0 часов 0 минут каждых суток, в параметрах указывается код экземпляра модуля. Данная задача необходима для случаев, когда статусы пакетов карты изменяются будущим числом.

Осуществляется задачей планировщика Начисление CerberCrypt. Рекомендуемая частота запуска - один раз в сутки. Целесообразно запускать задачу в первом часе каждых суток (например, в 0 часов 30 минут каждые сутки), тарификация производится включая текущие сутки с учётом актуальных статусов пакетов, установленных задачей Установка статусов пакетам карт CerberCrypt.

В конфигурации задачи указывается код модуля.

Осуществляется задачей Блокировка Cerber Crypt. Минимальная частота запуска - один раз в сутки после задачи начисления (например 2 часа). Если в договоре присутствуют иные виды списаний кроме начисления за использование цифрового ТВ, то задачу можно установить несколько раз в сутки.

В конфигурации задачи указывается код модуля. При блокировке пакеты всех договоров, баланс которых менее лимита, переводятся в статус заблокировано. Параметр forgive.hours определяет сколько часов от суток "прощать" клиенту. Под "прощением" понимается, что если задача запускается ранее указанного часа суток, то блокировка производится мгновенно и прошедшие часы достаются клиенту даром. Если задача запускается после этого часа, до добавляется задание на блокировку с 0 часов последующих суток, клиент может смотреть канал до конца суток.

"Прощение" определённого числа часов предотвращает недовольство клиентов в связи с отключением каналов в 0 часов, как это должно следовать из требования корректности начислений (при снятии денег посуточно блокировка должна происходить на границе суток).

В данном примере если блокировка производится после 2х часов ночи, статус заблокировано устанавливается со следующего дня, позволяя абоненту доработать день.

Если у пакета установлен параметр "Не блокируемый", то в этой задаче он обрабатываться не будет.

Осуществляется задачей планировщика Синхронизация CerberCrypt. Для всех активных в текущий день карт открываются указанные на текущий момент пакеты со статусом активен. Данная задача производит синхронизацию подписок по результатам работ задач Установка статусов пакетам карт CerberCrypt и Блокировка Cerber Crypt. Обновление подписок при их смене оператором, либо клиентом через Web интерфейс происходит мгновенно.

В параметрах задачи указывается код модуля и адрес E-Mail на который высылаются сообщения о недоступности сервера CerberCrypt.

Специфика некоторых систем (CTI/NordE, conax и т.д.) такова, что при указании подписки они требуют период активации, в отличие от протокола CerberCrypt, например, где подписка ставится/снимается сиюминутная. В данном случае существует примерно такое стандартное поведение:

Встаёт задача: как-то решить недостаток от продления пакета в бесконечность и последующим отключением пользователем самого себя от системы с целью пользоваться картой вечно. Сократить подобное пользование до разумного периода. Т.е. в том числе это защита от "хитрых клиентов".

Как написано в конфигурации для активатора CTI/NordE при активации на бесконечный срок можно сделать период активации, например, 30 дней от начала периода, после, если есть деньги, перепосылать активацию (т.е. каждый день, выходит, ибо карты в разные дни активируются).

Это делается через задачу планировщика «Постепенное продление подписок пакетов». Приэтом в БД создается отдельная таблица «продление пакетов/каналов», поля: entityId — идентификатор картпакета, date — дата последнего продления «сущности». Таблица не критичная, её содержимое можно удалить, тогда просто считается, что последний раз для закрытых периодов картпакетов уже было отослано, а для открытых было отослано в начале открытия на месяц, так что при следующем запуске этой задачи все они снова продлятся. В любом случае всё продлится и заново начнётся отсчёт при любом редактировании картпакета.

Сам алгоритм имеет такую логику: запускается раз в сутки, перебирает все картпакеты, активные в текущий момент. Активные картпакеты могут быть:

Если истекает эта дата (а системный открыт), тогда он заново отсылает команду с датой начала из картпакета (т.е. дата начала всегда одинакова будет, а конец каждый месяц отодвигаться) и датой конца из этой таблички+месяц . После этого новая реальная дата снова записыватся в БД и через месяц снова будет использоваться.

Период (например, как выше названо «месяц») настраивается в задаче самой конфигурации модуля (т.е. в конфигурации данного активатора).

Если в конфигурации указан небесконечный период, то это обязует использовать эту задачу для периодического продления подписки. Этот период используется как в самом модуле (для информации о том, на сколько конкретно продлить при открытии на бесконечный период), так и в этой задаче для информации о том, на сколько сделать последующее продление.

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

Пользователь открывает пакет в биллинге, указывает только дату начала активации пакета: на карту шлётся период ДАТА_НАЧАЛА — ДАТА_КОНЦА, где ДАТА_КОНЦА = ДАТА_НАЧАЛА + 30 дней; в таблицу записывается реальный период и системный (реальный — ДАТА_НАЧАЛА — ДАТА_КОНЦА, а системный ДАТА_НАЧАЛА — (открытая_дата))

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

Имеется специальная задача контроля синхронизации, которая отвечает за корректную отправку синхронизаций по картам. То есть, если в момент синхронизаций сервер УД был недоступен, то подписка уйдёт только в лучшем случае при следующем изменении карты или на границе суток, когда запустится задача общей синхронизации (если она будет успешна). Задача контроля синхронизации следит за картами с флагом "требует синхронизации" и при наличии карт с ним ставит синхронизатор по ним снова в очередь. Задача необязательна, период настраивается также по желанию нужной оперативности при возможных сбоях сервера УД.

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

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