Специфика некоторых систем (CTI/NordE, conax и т.д.) такова, что при указании подписки они требуют период активации, в отличие от протокола CerberCrypt, например, где подписка ставится/снимается сиюминутная. В данном случае существует примерно такое стандартное поведение:
* открываем пакет с закрытой датой закрытия — так и отсылаем;
* открываем пакет с бесконечностью — ставим большой правый период.
Встаёт задача: как-то решить недостаток от продления пакета в бесконечность и последующим отключением пользователем самого себя от системы с целью пользоваться картой вечно. Сократить подобное пользование до разумного периода. Т.е. в том числе это защита от "хитрых клиентов".
Как написано в конфигурации для активатора CTI/NordE при активации на бесконечный срок можно сделать период активации, например, 30 дней от начала периода, после, если есть деньги, перепосылать активацию (т.е. каждый день, выходит, ибо карты в разные дни активируются).
Это делается через задачу планировщика ». Приэтом в БД создается отдельная таблица «продление пакетов/каналов», поля: entityId — идентификатор картпакета, date — дата последнего продления «сущности». Таблица не критичная, её содержимое можно удалить, тогда просто считается, что последний раз для закрытых периодов картпакетов уже было отослано, а для открытых было отослано в начале открытия на месяц, так что при следующем запуске этой задачи все они снова продлятся. В любом случае всё продлится и заново начнётся отсчёт при любом редактировании картпакета.
Сам алгоритм имеет такую логику: запускается раз в сутки, перебирает все картпакеты, активные в текущий момент. Активные картпакеты могут быть:
а) либо с закрытым периодом, тогда ничего не делаем, ибо полагаем, что уже было всё отослано один раз;
б) либо с открытым, тогда берётся для каждого картпакета из указанной таблички одна дата — дата последнего успешного продления (точнее, до какого числа РЕАЛЬНО было продлено).
Если истекает эта дата (а системный открыт), тогда он заново отсылает команду с датой начала из картпакета (т.е. дата начала всегда одинакова будет, а конец каждый месяц отодвигаться) и датой конца из этой таблички+месяц . После этого новая реальная дата снова записыватся в БД и через месяц снова будет использоваться.
Период (например, как выше названо «месяц») настраивается в задаче самой конфигурации модуля (т.е. в конфигурации данного активатора).
period.gradually.subscription=30
Если в конфигурации указан небесконечный период, то это обязует использовать эту задачу для периодического продления подписки. Этот период используется как в самом модуле (для информации о том, на сколько конкретно продлить при открытии на бесконечный период), так и в этой задаче для информации о том, на сколько сделать последующее продление.
Пользователь открывает пакет в биллинге, указывает дату начала активации и конца активации: на карту шлются эти периоды, в таблице реальный период и системный совпадают.
Пользователь открывает пакет в биллинге, указывает только дату начала активации пакета: на карту шлётся период ДАТА_НАЧАЛА — ДАТА_КОНЦА, где ДАТА_КОНЦА = ДАТА_НАЧАЛА + 30 дней; в таблицу записывается реальный период и системный (реальный — ДАТА_НАЧАЛА — ДАТА_КОНЦА, а системный ДАТА_НАЧАЛА — (открытая_дата))
Пользователь меняет период активации пакета в биллинге, даты активации перепосылаются и перезаписываются в базу с учетом вышестоящих двух пунктов.