...
По уникальному внешнему идентификатору выполняется поиск имеющейся неархивной записи о сессии в коллекции sessions базы данных кэша. Если подходящая запись найдена, она обновляется данными из пакета, если нет — пакет аккаунтинга считается первым по сессии и создаётся новая запись о сессии.
Схема поиска сессий
На схеме t1 - момент начала поиска сессии. От момента t1 до (t1 -
...
.
...
.
...
. → accounting → session → lookup → hours) (синий интервал) подбирается
...
активная сессия (сессия, не закртая по таймауту), сессия закртая по таймауту ищется на интервале от t1 до (t1 - ... → accounting
...
→ session
...
→ lookup
...
→ timed_out_days) (не отмечен на схеме). Зеленый интервал - интервал, в котором batch
...
закрыл сессии, обычно этот интервал и синий интервал поиска
...
не закрытых по таймауту сессий - пересекаются (в крайнем случае - идут встык)
...
. Если по каким либо причинам batch не работал определенное время, между этими интервалами возникнет пробел, сессия, попавшая в этот пробел не подберется, и создастся ее дубль. Для разрешения таких ситуаций к интервалу подбора активных сессий добавляется ... → accounting
...
→ session
...
→ lookup
...
→ additional_hours (обозначен красным не схеме).
При обработке первого пакета аккаунтинга по сессии ядро плагина подбирает профили абонентского и операторского оборудования в соответствии с критериями, указанными в ключах customer_profile и provider_profile блока plugins → base → <plugin_instance_name> → actions → accounting. Эти профили фиксируются в сессии и используются для определения её типа при загрузке в основную БД Гидры. Подбор профилей настраивается аналогично действию authorize. Как правило, критерии подбора профилей используются те же, что и в действии authorize — чтобы их не повторять в конфигурации, рекомендуется применять такие элементы YAML-формата как якори и ссылки.
...