Пополнение картотек ибс: проблемы и

on

Обоснование необходимости пополнения ИБС из внешних источников. Виды пополняемых картотек и возможные источники данных. Даже в прежние времена, когда биллинг операторов связи совершался в ручном режиме, а картотека абонентов представляла собой набор из многочисленных шкафов, хранящих папки различных цветов и степени пухлости, возникала необходимость корректировки данных в связи с получением какой-то информации, поступившей извне. Это могли быть данные банковских выписок о поступивших платежах, звонок из милиции о постановке телефонизированной квартиры на охрану, данные с переговорного пункта о совершенном междугородном разговоре и т.д. Все эти события влекут за собой необходимость внесения соответствующих изменений в абонентскую картотеку, а потеря информации о любом из них приведет к тому, что абоненту будет выставлен неправильный счет, который впоследствии необходимо будет корректировать. Но там, где раньше можно было обойтись папками, стремянками и руками сотрудниц телефонных узлов, теперь, когда окружающий мир изменился, и повсеместно пришла автоматизация, требуется приложить гораздо больше усилий, чтобы соответствовать требованиям по точности и скорости внесения изменений. Усложнились и взаимоотношения оператора связи с контрагентами, между ними постоянно происходит перераспределение полномочий, взаимообмен услугами, сверки, детализации, и взаиморасчеты с учетом пени и скидок. Если прибавить сюда отдельные потоки данных по почтовой адресной информации, справочникам банков, видам телефонного оборудования, то станет понятно, насколько глубоки и сложны задачи синхронизации картотек, стоящие сегодня перед любым оператором связи. Все вышеизложенное в большей степени относится к фиксированной связи, с ее разнообразием поставщиков услуг и замедленным по сравнению с мобильной связью документооборотом. Назревает насущная необходимость в надежном универсальном программном обеспечении (ПО), способном обеспечить работу с картотекой оператора связи и надежную предсказуемую загрузку данных из разнородных внешних источников, наладить обратную связь и протоколирование всех процессов в системе. Рассмотрим требования к такому ПО, сформулированные на основании анализа реальных бизнес-процессов различных операторов связи по опыту разработки биллинговых систем в ЗАО «ПЕТЕР-СЕРВИС», а также на основании реализации действующих программных продуктов, связанных с обработкой поступающих внешних картотек. Гетерогенные внешние источники — гомогенное внутреннее представление информации. Изоляция логики преобразования форматов от логики внутреннего преобразования. Источники внешних данных для биллинговой системы могут быть стратифицированы не только по виду предоставляемой информации, но и по формату передаваемых данных (рис. 1). Форматы данных могут быть самыми разнообразными в связи с тем, что происходит интеграция автоматизированных систем разных производителей. /подпись к рис. 1/ Рис. 1 Виды внешних картотек /конец подписи к рис. 1/ В идеальной ситуации поставщики ПО всегда договариваются между собой о наиболее удобном формате взаимодействия и синхронно изменяют функциональность подготовки выходных документов с тем, чтобы обеспечить максимально удобный взаимный обмен. Но что делать в реальной жизни, когда идеальный вариант практически недостижим, не говоря уже о том, что представление об идеальном у каждого поставщика и оператора связи может быть свое? Производителю биллинговой системы необходимо сформировать свой взгляд на то, какие именно реквизиты того или иного вида картотеки и в каком формате должны поступать на вход системы расчетов. По опыту, самым универсальным и удобным форматом в таком случае является проверенный временем XML. Необходимо лишь неким образом сгруппировать все реквизиты и разместить их по соответствующим секциям XML-документа, указав тип каждого реквизита и какие-либо ограничения на то, какие значения он может принимать. Зачастую группировку удобно производить по принципу принадлежности группы реквизитов к одной таблице схемы данных ИБС. Например, для реквизитов абонента в одной секции можно разместить его юридические реквизиты, в другой — реквизиты, связанные с параметрами доставки, в третьей — информацию о принадлежащих ему телефонах и их тарифных планах и т.д. Далее следует проанализировать все многообразие форматов, в которых поступают данные об абонентах из всех внешних источников. Для каждого из этих форматов необходимо определить, какое преобразование необходимо выполнить для того, чтобы привести содержащиеся в нем данные к унифицированному формату. На этом этапе анализа выясняется также, все ли реквизиты, обязательные для унифицированного формата документа, присутствуют в соответствующем внешнем формате. В случае отсутствия совпадения по каким-то реквизитам, возможно, придется выполнить для них дополнительное атрибутирование. Начальная стадия загрузки сводится к работе специализированных процедур-адаптеров, которые выполняют так называемую «трансформацию», то есть последовательное перенесение информации из полей и тегов исходного внешнего документа в поля и теги документа унифицированного формата, соответствующие им по смыслу. Перед началом своей работы адаптер дополнительно проверяет корректность внешнего формата рапорта: наличие правильных разделителей в тексте, верность «шапки» XLS-файла и т.п. При этом, как правило, не выполняется никаких проверок на корректность данных или формат конкретных полей с точки зрения представления данных в биллинговой системе — все это будет сделано на последующих этапах обработки. Организуя подобным образом первичное преобразование форматов, мы изолируем логику последующей обработки унифицированной информации от логики преобразования конкретных разнообразных внешних форматов, предоставляемых сторонними системами. В этом случае при подключении нового внешнего формата от какого-то дополнительного внешнего источника нам не придется изменять базовую логику работы системы, достаточно будет лишь разработать новую процедуру-адаптер, которая осуществит преобразование по вышеописанной схеме. Это дает устойчивость системе загрузки в целом и обеспечивает быстроту интеграции с новыми внешними системами при пополнении картотек ИБС. Кроме того можно дополнительно выделить отдельные подпрограммы разбора конкретных внешних форматов, будь то Microsoft Excel, формат текста с разделителями или тот же XML, и многократно применять их в качестве библиотечных. Удачным вариантом реализации представляется использование на этапе трансформации XSL-преобразования, для того чтобы дополнительно уменьшить необходимость повторного кодирования в случае незначительного изменения внешних форматов данных. Обработка может выполняться двухтактно: сначала перевод текста или какого-либо другого формата документа к промежуточному XML-формату, а затем выполнение XSLT с получением документа универсального формата ИБС. Одним из дополнительных преимуществ использования унифицированного XML-формата является возможность применения к нему XSD-схем валидации с целью определения их корректности. Более подробно эта процедура будет рассмотрена ниже. Таким образом, в результате первого этапа обработки — «трансформации» — мы имеем набор документов унифицированного вида. Но приступать к загрузке, то есть непосредственному изменению данных картотек ИБС, еще рано. Сначала необходимо выполнить еще один важный этап — атрибутирование информации. Атрибутирование информации. «Отсев» и «резервуары» данных. Как правило, поступившая из внешних источников информация отличается существенной неполнотой с точки зрения картотеки биллинговой системы. Отсутствуют те или иные реквизиты, связанные с информацией о доставке, какие-то банковские реквизиты, почтовый индекс и так далее, и так далее. Кроме того, различные признаки, связанные с реквизитами, могут по-разному трактоваться ИБС и внешней по отношению к ней системе. Часть подобных проблем может быть решена уже на этапе трансформации, путем соответствующего изменения логики XSL — преобразования, но более сложные сопоставления могут быть произведены только с помощью выполнения еще одного специализированного этапа обработки — атрибутирования. Процедуры атрибутирования представляют собой специализированный прикладной программный интерфейс (Application Programming Interface — API). На вход им передается унифицированный документ, полученный по результатам трансформации, и каждая из них проводит дополнительное преобразование каких-то выделенных реквизитов, модифицируя таким образом переданный документ. При этом используется API как самой ИБС, так и любых других систем. В процедурах атрибутирования могут быть реализованы преобразования любой сложности с использованием любых дополнительных справочников (рис. 2). Например, можно по адресу абонента определить его почтовый индекс и дополнить им данные поступившего документа, или вычислить по типу юридического лица схему его налогообложения — сфера применения процедур атрибутирования крайне обширна. /текст к рис. 2/ Рис. 2 Укрупненная схема процесса преобразования и загрузки внешних картотек /конец текста к рис. 2/ Процедуры атрибутирования группируются в отдельные модули в соответствии с типом картотеки для каждого унифицированного документа. Эти модули могут подключаться, модифицироваться и отключаться, обеспечивая дополнительную изоляцию логики общей обработки при загрузке внешних картотек в систему. Каждая из процедур атрибутирования возвращает признак успешности своего завершения. Этот признак устанавливается в соответствии с логикой работы каждой конкретной процедуры. Например, процедура определения почтового индекса по адресу абонента может возвращать признак неуспешности операции в случае, если в справочниках ИБС или во внешних адресных справочниках для данного адреса соответствующий почтовый индекс не был найден. Для каждого из атрибутов в системе настраивается критичность неуспешности выполнения процедуры атрибутирования. Если для данного типа документа какой-то атрибут является «критичным», то в терминах системы это означает, что данный документ признается непригодным для дальнейшей загрузки в ИБС. Его обработка прекращается, делается запись об этом в системный журнал с указанием причины прекращения, а сам документ переносится в так называемый отсев. Отсев — это набор документов, которые, по той или иной причине не были загружены в ИБС. Свой отсев формируется на каждом из этапов обработки: сначала при проверке корректности формата процедурой-адаптером, затем по результатам обработки критичных реквизитов процедурами атрибутирования, и наконец — при пополнении картотек ИБС на этапе непосредственной загрузки. Для каждого из документов хранится причина его попадания в отсев, чтобы администратор системы мог осуществить последующий разбор результатов загрузки. В системе должны быть разнообразные возможности по работе с отсевом документов: просмотр, анализ ошибок, оперативная правка отсеянных документов и отправка их на повторный цикл загрузки. Кроме того должна быть предусмотрена операция, обратная по смыслу той, которую выполняют процедуры-адаптеры, — выгрузка ошибочных документов в том же формате, в каком они поступили на вход в систему, для отправки их контрагенту на предмет выверки, исправления и повторной передачи для пополнения картотек оператора связи. Следует различать отсев и резервуар документов, хранящихся в базе данных системы загрузки рапортов. В резервуаре накапливаются документы, которые в настоящий момент не были загружены в ИБС, но не из-за некорректности их данных, а потому, например, что связанные с ними данные еще не поступили. К примеру, загружаются данные обновления абонента, который еще не был создан, так как информация о его создании запоздала. В этом случае документ на обновление помещается в резервуар, где он находится до момента поступления документа о создании абонента. При этом в ИБС одновременно загружается вся цепочка данных, связанная с абонентом: о его создании и последующем обновлении. Возникает вопрос, каким образом будет поддержана общая корректность информации, если данные, относящиеся к прошлому абонента, но поступившие в разное время, противоречат друг другу? Этот совершенно справедливый вопрос касается одной из самых сложных тем при работе с картотеками биллинговой системы — поддержанием консистентности исторической информации в прошлом и в будущем. Поддержание консистентности данных ИБС при операциях в прошлом и в будущем. Необходимость развитого структурированного API биллинговой системы. Многопоточная загрузка данных. При выполнении любых действий над картотекой датами в прошлом или в будущем всегда необходимо понимать, что делать с информацией, которая уже была занесена раньше, если периоды действия каких-либо реквизитов у старых и вновь поступивших данных пересекаются. Для исключения таких ситуаций в рамках поступления одной порции информации из какого-то внешнего источника необходимо применить сортировку по датам совершения операций по каждому из абонентов. Но если поступившая информация сильно запоздала и какие-то действия над картотекой для этого периода уже были совершены ранее, то возможны два подхода: • аннулирование всей ранее поступившей истории реквизита в будущем относительно даты вновь поступившей операции («отрезание»); • вставка периода действия реквизита из поступивших данных с формированием новых участков действия реквизита («раздвижение»). Система загрузки должна предоставлять возможности по использованию как первого, так и второго способа обработки исторических данных. Способ обработки должен соотноситься с типом поступающих картотек, а также с каждым конкретным внешним источником, так как у каждого из контрагентов может быть свое представление о способе работы с исторической информацией, а также свой протокол выгрузки и поступления исходных документов по обновлению картотек. Выбор способа понадобится на финальной стадии пополнения картотек — использования API ИБС с передачей на вход ранее успешно атрибутированных унифицированных документов. Конкретные функции API соотносятся с типами картотек на уровне настроек системы, например, функция create_abonent отвечает за операцию создания абонента, update_abonent — за обновление, delete_abonent — за закрытие абонента и т.д. Работа системы загрузки сводится к сканированию набора подготовленных унифицированных рапортов, определению по настройкам соответствующей ей функции API и ее вызову с передачей дополнительно на вход способа работы с историей абонента, заданного для сочетания конкретного типа картотек и внешнего источника. Перед началом загрузки можно дополнительно проверить подготовленные документы на корректность путем применения к ним заранее подготовленных схем XSD-валидации, которые отражают представления биллинговой системы о формате и полноте реквизитов сущности, которая будет обновлена в результате проведения операции загрузки. Как и ранее этот этап обработки протоколируется. Документы, которые не смогли быть прогружены в ИБС, в зависимости от результатов помещаются в отсев или резервуар документов. Общий цикл раб