focus писал(а):
статус спасет тем, что в задании можно будет сравнить текущий статус и прошлый.
Если они равны, то для этого договора не запускать скрипт шлюза.
Соответственно если был Заблокирован, текущий Заблокирован - для этого договора задание не будет менять статус шлюза.
А по приходу платежа будет текущий Открыт прошлый Заблокирован - соответственно шлюз должен отработать.
Как-то так.
А если скрипт отработал , но связи не было . Но статус изменился . Обычно сркипт сам должен делать проверку на оборудовании - менять или не менять . Обычно он считывает статус всех абоннато на шлюзе однйо командой ( show access_list ) и потом уже шлет команды только если нужно .
Надо делать по другому , в случае удачной отработки шлюза , нудно ставить флаг , что все нормально . В случае смены статуса IPN, флаг сбрасывать . Так же сбрасывать флаг если поменялся ip, тип правила и или какая-то другая информация влияющая на шлюз . При этом нужно учитывать обратную свзязь как-то. Т.е если шлюз удавленный перезагрузился и сбросил все правила , то нужно это как-то отлавливать( по snmp или периодически пинговать, проверять uptime ). И это еще сделать как-то универсально.. Теоретически это уже сейчас можно реализовать с помощью скриптового шлюза . Кажется один из наших клиентов так и сделал себе сам , пишет в некторую таблицу флаг. Uptime можно так же сохранять в таблицу