О программе TSVlog

 

Программа TSVlog (и ее модификации) предназначена для предварительной обработки исходных тарификационных файлов с CDR (SMDR) – записями и преобразования их в табличную форму для последующей тарификации. Она является составной частью программного комплекса TarifSV.

Системные требования: Windows 2000, Windows XP и выше, PII/400/128 Mb. Для увеличения скорости вычислений, желательно увеличить объем оперативной памяти, по крайней мере, до 256 Mb. На диске программа занимает около 1,4 Мб.

Программа TSVlog устанавливается совместно с  TarifSV (в ту же папку). Процесс ее установки на ПК описан в документации на комплекс TarifSV.

Скорость обработки исходных log-файлов и преобразования их в табличную форму зависит от объема шаблонов и правил обработки CDR и  составляет примерно 2000 CDR - записей в секунду.

 

Основы работы с программой TSVlog

 

С помощью программы TSVlog_25.exe информация из исходных тарификационных файлов с CDR – записями преобразуется в промежуточный 2I*.db файл, содержащий данные о телефонных вызовах, необходимые для последующих расчетов программой TarifSV.exe (и ее модификаций).

В прилагаемом документе «Тарификация телефонных переговоров на М1» содержатся некоторые сведения об основах преобразования CDR – записей от АТС Meridian 1 (т.н. процесс «нормализации» записей).

 Параметры настроек программы TSVlog_25.exe (шаблоны, используемые при завершающих преобразованиях и формировании таблицы 2I*.db) содержатся в папке PhoneBase\Init БДТ, которые формируются программой  TarifSV.exe во время работы с базой данных телефонии (БДТ). Подробнее  об этом процессе см. в документации на комплекс TarifSV.

Использование упомянутых шаблонов позволяет существенно уменьшить базу данных ресурсов (в десятки раз), установить правила обработки CDR – записей, а также увеличить скорость вычислений.

В папке PhoneBase\Init кроме шаблонов размещается файл TSVLOGINI.DB, в котором содержатся установочные данные о форматах (шаблонах) названий log-файлов с CDR, префиксах, идентифицирующих шаблоны, о типе АТС, связанном с данным шаблоном, а также информация о порядке учета записей с нулевой длительностью (нулевым объемом трафика).

Особенности обработки CDR в TarifSV

 

CDR (Call Detail Recording) или, иначе,   SMDR (Station Message Detail Record) представляют собой определенным образом форматированные записи, содержащие информацию о параметрах соединения (вызова). Обычно все CDR  записываются в так называемый log-файл (файлы). Часто для этих целей используются специальные программы. Одной из подобных программ является модуль TSVserver из комплекса TarifSV.

В зависимости от типа АТС (коммуникационного сервера и т.п.), формат записей, объем и полнота представленной в них  информации могут существенно различаться. Кроме того, некоторые АТС  выдают CDR, нуждающиеся в предварительной обработке. Например, АТС М-200 требует проведения такой обработки специальной программой  SMPCallBuilder.

Для целей тарификации (биллинга)  необходимо по данным CDR однозначно определить абонента - инициатора вызова (соединения), дату и время начала соединения, объем трафика (длительность соединения - в телефонном трафике), тип трафика (куда/откуда осуществлен вызов), а также абонента – терминатора вызова (соединения).

Как уже отмечалось, в зависимости от типа АТС (коммуникационного сервера и т.п.), CDR могут существенно различаться. Наиболее полные из них содержат следующие данные:

 

·        ORIGID – поле, идентифицирующее некое устройство (ресурс, порт АТС и т.п.), являющееся инициатором (ORIGINATOR) соединения;

·       CLID1 (Calling Line Identification) – идентификатор вызывающей линии (ресурса), принятый от ORIGID.  Этот термин пришел из ISDN. Часто (что не вполне правильно) его называют АОНом. CLID позволяет уточнить абонента – инициатора вызова;

·        DIGITS1 (в Meridian 1 это DNIS - Dialed Number Identification System) – поле, содержащее информацию о типе и адресе запрашиваемого соединения (для телефонии - цифры номера, отданные ORIGID);

·        TERID - поле, идентифицирующее некое устройство (ресурс, порт АТС и т.п.), являющееся терминатором (TERMINATOR) соединения. Это может быть оконечное устройство на самой АТС (например – абонентская линия) или ресурс, через который осуществлено соединение с внешней (по отношению к данной АТС) сетью (например – соединительная линия, транк);

·         CLID2 (Calling Line Identification) – идентификатор вызывающей линии (ресурса), переданный в TERID. Значение CLID2  часто может отличаться от значения в поле CLID1;

·       DIGITS2 – поле, содержащее информацию о типе и адресе запрашиваемого соединения, которая была направлена в TERID. Эта информация может отличаться от значения в поле DIGITS1 (например, содержать код выхода в «город»);

·         Дата и время начала (окончания) соединения;

·         Длительность соединения (объем трафика).

 

Первые три из перечисленных полей, как это видно из их описания, относятся к стороне «А» (инициатору соединения), а следующие три – к стороне «В». Остальные параметры являются общими для обеих сторон.

 

Некоторые коммутаторы выдают CDR, содержащие дополнительные полезные данные:

-        Длительность ожидания соединения;

-        Тип CDR (обычный внутренний или внешний вызов, конференция, трансфер, авторизация и т.п.);

-        Код (или признак) завершения вызова, позволяющий сделать вывод о том, состоялся вызов или был по каким-то причинам отменен. Некоторые АТС выдают признак стороны, инициировавшей разъединение;

-        др.

 

К сожалению, далеко не все коммутаторы выдают CDR, позволяющие однозначно идентифицировать по ним абонентов и провести качественную тарификацию. Например, очень часто в CDR отсутствует поле DIGITS1, что затрудняет идентификацию внешних входящих вызовов.

Кроме того, сама сеть не всегда позволяет передавать полную информацию о вызовах (например, далеко не всегда можно передать CLID (АОН)).

Следует также отметить, что одному вызову могут принадлежать несколько (например, в Meridian1, AVAYA -  даже десятки!) CDR, между которыми могут находиться записи, не относящиеся к данному вызову. Да и в самой CDR, с точки зрения биллинга, содержится информация, по крайней мере, о двух вызовах, которые необходимо тарифицировать (как правило, принадлежащих разным абонентам, со своими тарифными планами). Например, при внутреннем вызове:  для стороны "А" - как об исходящем, а для стороны а для стороны "В" - как о входящем.

При использовании функции DISA (например - для входа "из города"  в корпоративную сеть с последующим выходом из нее  на "междугородку") в одной CDR может содержаться информация о четырех вызовах:

1)      входящий от абонента - оператора связи с "городом";

2)      входящий городской для абонента - арендатора функции DISA;

3)      исходящий от абонента - арендатора функции DISA за выход на МГ;

4)      исходящий от оператора связи, через которого осуществлен выход на МГ.

 

И все эти вызовы должны тарифицироваться в соответствии с собственными тарифными планами указанных абонентов.

 

Комплекс TarifSV содержит модуль TSVlog, предназначенный для анализа CDR,  получения из них требуемой информации о соединениях (вызовах) и преобразования ее в  табличную унифицированную форму (промежуточный 2I*.db файл). В последующем данные из этой таблицы используются при проведении окончательной тарификации с помощью программы TarifSV.exe.

Порядок заполнения унифицированной таблицы следующий:

1)      в log-файле находится очередная CDR;

2)      из этой CDR выделяются поля, содержащие перечисленные выше данные (ORIGID, CLID1, DIGITS1 и т.д.). Если этих данных напрямую в CDR нет, то по-возможности используется имеющаяся информация, с преобразованием ее в нужные данные по специальному алгоритму, адаптированному к формату CDR для конкретного типа АТС ;

3)     к значениям ORIGID и TERID при необходимости подставляются префиксы. Эти префиксы служат для идентификации CDR, принадлежащим разным коммутаторам. Указанная функция используется в случаях, когда CDR собираются от разных коммутаторов, но обрабатываются совместно (например, когда у вас распределенная сеть с выходами на операторов связи с различных коммутаторов);

4)      осуществляется «слияние» всех CDR, принадлежащих к одному вызову;

5)      с целью обеспечения оптимальной идентификации абонентов, участвующих в совершении данного вызова (соединения), с использованием шаблонов (набора правил, определяемых пользователем в зависимости от структуры сети) производится модификация данных (ORIGID, CLID1, DIGITS1 и т.д.);

6)      на основе анализа модифицированных данных, для всех CDR, принадлежащих одному вызову (оставшихся после «слияния»), формируются записи в итоговой таблице 2I*.db. Число таких записей зависит от сложности вызова, но для каждого вызова составляет не менее двух: сначала идет запись о вызове (соединении) с точки зрения инициатора вызова, затем - терминатора.

 

Настройка шаблонов имен log-файлов и типов АТС

 

Такого рода настройка, как правило, проводится при первоначальном запуске TSVlog_25.exe или при определении алгоритма обработки CDR того или иного вида. 

Запустите TSVlog_25.exe. Выберите пункт меню «Прогон» и п/пункт «Параметры прогона»  (рис. 1).

 

 

Рис. 1. Панель "Установка шаблонов, префиксов и типов АТС".

 

Выбрав пункт "Редактировать" (поставив "галочку"), Вы получите возможность редактировать параметры прогона (рис. 2).

 

 

 

Рис. 2. Редактирование параметров прогона.

 

В настоящее время в качестве шаблонов (масок) имен файлов с CDR (SMDR)  допустимо использовать только следующие:

a.                  *20YYMMDD.log;

b.                 *20YYMMDD.txt;

c.                  *DD_MM_20YY.log;

d.                 *DD_MM_YY.log,

где:

 - YY - последние два символа в обозначении года;

 - MM - месяц;

 - DD - день;

 - * - любая последовательность символов (до 15 шт), в том числе – ее отсутствие.

 

Например, у вас файлы SMDR собираются от AVAYA IP Office, и имена этих файлов соответствуют шаблону 20YYMMDD.log (20120301.log,  20120302.log и т.д.).

Тогда в качестве типа АТС для такого шаблона устанавливаем: AVAYA IP Office 5+.

 

Значение префикса позволяется выбрать из выпадающего списка. Обычно он ставится только при совместной обработке CDR, полученных от нескольких АТС в сети. Отнеситесь внимательно к выбору. Именно это значение в дальнейшем будет автоматически добавлено к параметрам ORIGID  и TERID при считывании последних из CDR. Этот префикс следует учитывать и при составлении шаблонов (правил) обработки CDR .

 

Тип АТС (фактически - формат CDR  в log-файле) выбирается также из списка.

Здесь вы, собственно, указываете программе, с помощью какого алгоритма нужно обрабатывать файлы CDR (SMDR), если название файла соответствует шаблону (маске) имени файла. Будьте внимательны при выборе и установке этого значения.

 

Параметр "Выводить записи с 0-й длительностью" устанавливается "галочкой" при необходимости учета всех записей, в том числе - с нулевой длительностью (объемом) соединения. Обычно, устанавливаем «галочку».

 

Проведение расчетов

 

Запустите TSVlog_25.exe. Выберите пункт меню «Прогон» и п/пункт «Старт прогона». Вам будет предложено выбрать исходные файлы с CDR – записями (рис. 3).

Как правило, при проведении тарификации за определенный период (чаще всего – за истекший месяц) оператор «загружает» не только log-файлы за этот период, но и 1 файл за конец предыдущего и 1-2 файла последующего периодов. Это связано с тем, что вызов может начаться в одном периоде, а закончиться в следующем. Кроме того, вследствие расхождения системных часов у АТС и компьютера - «сборщика», время закрытия «суточного» log-файла может не совпадать с окончанием суток «по часам АТС».

После выбора файлов производится расчет. Информация об этом процессе отображается в окне «Журнал работы» (рис. 4). При этом:

1. Файл 2I*.db создается в том же месте, где находятся исходные log – файлы. Обычно – в отдельной папке. Программа проверяет возможность записи в это место, а также размер свободного дискового пространства (с учетом возможной записи промежуточных данных, требуется примерно в  2 раза больше, чем занимают исходные файлы).

2. В случае загрузки более чем одного *.log – файла, имя файла 2I*.db формируется из имен первого и последнего загружаемых файлов.

3. В журнале под «считанными записями» имеются в виду исходные CDR – записи. Под «сохраненными» - записи в итоговой таблице (файл 2I*.db).

                

Рис. 3. Выбор исходных файлов

Рис. 4. Журнал работы

 

Формат выходного 2I*.db файла

 

Выходной файл включает записи, содержащие поля:

 

§         NUMB - уникальный номер первой CDR-записи, в которой была найдена информация о данном вызове. Этот номер берется из CDR (если таковой есть) или присваивается программой автоматически. Заметим, что одна CDR-запись может содержать информацию о нескольких  вызовах (разного типа и на разные ресурсы). В то же время, информация об одном вызове может быть «разбросана» по нескольким CDR-записям;

§         DT_START - дата и время начала вызова (соединения);

§         DURWAIT - время ожидания начала соединения, с;

§         DURATION - длительность вызова (истинная в сек) или объем трафика;

§         ORIGID - ресурс (ID ресурса, с учетом преобразований с использованием шаблонов);

§         DIGITS - номер, "набранный" ресурсом при вызове (с учетом преобразований с использованием шаблонов). В кавычках, поскольку  может содержать дополнительные символы, например, "+", "-" и т.д. ;

§         RECTYPE - тип записи – символ, служащий для обозначения разновидности вызова (не всегда совпадает с типами CDR); 

§         CLID -  дополнительный идентификатор инициатора вызова (с учетом преобразований с использованием шаблонов). В большинстве случаев для его формирования используется поле CLID в исходной CDR;

§         CODE - код завершения вызова. Если соответствующее поле присутствует в CDR, то здесь помещается его значение;

§         STRNUMBER - имя исходного log - файла и номер строки в нем, соответствующей данной записи в таблице.

 

Просмотр результатов

 

Для перехода в режим просмотра исходных и выходных фалов выберите соответствующий пункт меню (рис.5). Есть возможность загрузить образ  как исходного, так и выходного файлов. Как правило, загружается выходной файл. Затем, посредством двойного «клика» на какой-либо строке, осуществляется автоматическая «подгрузка» нужного исходного файла, в котором содержится соответствующая исходная CDR-запись. Имя этого файла отображается в нижней части окна.

Здесь возможны следующие команды:

-        Поиск соответствия - двойной «клик» на какой-либо строке в образе исходного/выходного файла приводит к поиску соответствующей выходной/исходной записи, на которую перемещается курсор. Если по исходной была найдена выходная запись, то последняя подкрашивается зеленым цветом;

-        Поиск подстроки – командами < Ctrl + F> (новый поиск), <F3> (продолжение поиска «вниз»), <Ctrl + F3> (продолжение поиска «вверх»). Для уточнения места поиска (в исходном или выходном файле) «кликните» на соответствующий образ;

-        Копирование выделенной части файла или таблицы и сохранение копии – осуществляются посредством выбора соответствующего пункта выпадающего меню. Для этого "кликните" правой кнопкой  в образе исходного/выходного файла.

 

Выделенная часть таблицы сохраняется в формате *.csv, *.xls или *.htm (по выбору).

 

Совет. Не сохраняйте в формате *.xls более 65000, а в формате *.htm – более 10000 строк таблицы.

В случае большого объема таблицы рекомендуется ее сохранять в формате *.csv (без предварительного копирования).

 

 

                                                                      

Рис. 5. Режим просмотра результатов.

 

 

 

 

Рекомендации по составлению шаблонов конвертации

 

Шаблоны конвертации предназначены для предварительного преобразования исходных данных о параметрах вызовов, полученных из CDR (SMDR).

Основные цели разработки шаблонов:

1)      Однозначно привязать каждый вызов к уникальному идентификатору ресурсов;

2)      Пометить маркерами все внешние вызовы (входящие и исходящие). Остальные программа автоматически определит, как внутренние;

3)      Сформировать (подправить имеющийся) набранный номер таким образом, чтобы в дальнейшем можно было бы однозначно использовать его при тарификации;

4)      Сформировать (подправить имеющийся) CLID, чтобы в дальнейшем можно было бы по его значению, по возможности, однозначно определить, откуда пришел вызов.

При их разработке соблюдайте, прежде всего, несколько простых правил.

·        При составлении таблиц шаблонов следует стремиться к минимизации их размеров (не более нескольких десятков записей в одной таблице). Это позволит существенно увеличить скорость вычислений.

·        Кроме того, рекомендуется придерживаться правила: шаблоны должны быть минимально привязаны к конкретному абоненту. Как правило, они составляются один раз и должны быть достаточно универсальными. Обычно какие - либо исправления и дополнения  в них вносятся только при изменениях в "железе" и конфигурации АТС (например - при появлении нового маршрута или при изменении нумерационного плана).

·        И еще одна рекомендация. При разработке шаблонов конвертации пользуйтесь методом "последовательного приближения" к итоговому результату на небольшом log-файле. После каждого изменения шаблона осуществляйте его "прогон" с помощью TSVlog.exe и анализируйте результаты.

 

 

Шаблоны конвертации хранятся в базе данных телефонии в отдельной папке PhoneBase/INIT.

Создаются они в программе TarifSV (пункт «Конвертация log-файла» основного меню).

При этом открываются 10 закладок-шаблонов. Замечу, что именно в таком порядке и используются шаблоны (преобразуются исходные данные) при работе программы TSVlog:

 

Закладка «1.Замена ORIGID» содержит данные о том, каким образом необходимо изменить значение поля ORIGID (в CDR – записи):

-        Модифицируем ORIGID / Исходное значение  – маска, 20 символов;

-        Модифицируем ORIGID / Заменить на – маска, 20 символов.

Назначение этих полей понятно из их названия. В поле ORIGID содержится идентификатор инициатора вызова. Его модификация позволяет объединить под одним обозначением группу инициаторов, относящихся с т.з. тарификации к одному объекту.

Например, если нам безразлично, с какой соединительной линии СЛ (транка) пришел вызов, то можно идентификатор любой из них заменить единым обозначением для целого пучка СЛ (транк-группы). Т.е., например, вместо «T902201» (первая СЛ в транк-группе Т9022)  записать «T9022».

 

Закладка «2.Префикс А» содержит данные о том, каким образом необходимо изменить значение поля ORIGID, если в поле DIGITS1 подстрока из первых символов (до 20)  совпадает  с определенной строкой (т.н. «префиксом А»):

-        Значение поля ORIGID – до 20 символов;

-        ПрефиксА ( вызывающего абонента)  в поле DIGITS1 – до 20 символов;

-        Новое значение поля ORIGID  – до 20 символов.

Как правило, «префикс А» применяется для выделения из общей группы записей с одинаковыми значениями в поле ORIGID тех из них, которые имеют характерный признак в первых символах поля DIGITS1 (префикс). Например, таким образом иногда обозначаются вызовы, принадлежащие разным абонентам, но  приходящие с общего маршрута, с которого не отдается CLID1 (АОН). Обычно, указанный префикс затем «вырезается» из поля DIGITS1  (с помощью шаблона "5.DIGITS1") и не участвует в дальнейшем в обработке CDR вызова.

 

Закладка «3.Замена CLID1» содержит данные, позволяющие более полно и точно восстановить идентификатор вызывающего абонента (CLID1) для вызовов, пришедших от  определенного  ORIGID. Таким образом можно однозначно идентифицировать ресурсы даже в том случае, если с разных маршрутов приходят вызовы с одинаковыми значениями параметра CLID1.

Поля таблицы:

-        Значение поля ORIGID  - до 20 символов;

-        Поле CLID1 / Исходное значение – маска, (до 20 символов);

-        Поле CLID1 / Заменить на:   – маска, (до 20 символов).

 

Закладка «4.Слияние CLID1 и ORIGID» содержит данные, позволяющие более полно и точно восстановить идентификатор вызывающего ресурса. Например, «сцепив»  ORIGID (маршрут, с которого пришел вызов) с CLID1 (идентификатор вызывающего абонента), можно однозначно идентифицировать ресурсы даже в том случае, если с разных маршрутов приходят вызовы с одинаковыми значениями параметра CLID1.

Поля таблицы:

-        Значение поля ORIGID  - до 20 символов;

-        Значение поля CLID1 – маска, (до 20 символов);

-        Новое значение поля ORIGID  – маска, (до 20 символов).

Этот шаблон часто используется также для принудительной замены значения поля ORIGID на значение (фрагмент значения) из поля CLID1. Обычно он таким образом применяется при обработке CDR от внутрикорпоративных вызовов.

Например, с транк-группы Т9017 могут поступать внутрисетевые вызовы от корпоративных абонентов с CLID1, соответствующим маске 5!!!. Если не сделать конвертации с помощью шаблона «4.Слияние CLID1 и ORIGID», то все они будут идентифицированы, как входящие вызовы с ресурса Т9017.  Использование же этого шаблона может позволить для каждого вызова заменить Т9017 на соответствующее значение из CLID1 (5ХХХ).

 

Закладка «5.DIGITS1» содержит данные о том, каким образом необходимо изменить поле DIGITS1 в первоначальной CDR, в зависимости от того, от какого ORIGID пришел вызов. Чаще всего данный шаблон используется для обозначения маркером «+» внешних входящих вызовов.

Поля таблицы:

-        ORIGID  - маска, до 20 символов;

-        Поле DIGITS1 / Исходное значение – маска, (до 32 символов);

-        Поле DIGITS1 / Заменить на: – маска, (до 32 символов);

-      Детализация стороны «В» - логическое (true/false). Используется для указания программе TSVlog, нужно ли осуществлять детализацию информации о входящем внешнем вызове, данные о котором соответствуют значениям, указанным в первых трех полях.

 

Следующие 5 закладок (шаблонов) во многом похожи на первые. Но они относятся к терминирующей стороне вызова (сторона В).

 

Закладка «6.Замена TERID» содержит данные о том, каким образом необходимо изменить значение поля TERID (в CDR – записи):

-        Модифицируем TERID / Исходное значение  – маска, 20 символов;

-        Модифицируем TERID / Заменить на – маска, 20 символов.

В поле TERID содержится идентификатор терминатора (ресурса, на котором заканчивается вызов) вызова. Его модификация позволяет объединить под одним обозначением группу терминаторов, относящихся с т.з. тарификации к одному объекту.

Например, если нам безразлично, через какую соединительную линию СЛ (транка) ушел вызов, то можно идентификатор любой из них заменить единым обозначением для целого пучка СЛ (транк-группы). Т.е., например, вместо «T902201» (первая СЛ в транк-группе Т9022)  записать «T9022».

 

Закладка «7.Префикс В» содержит данные о том, каким образом необходимо изменить значение поля TERID, если в поле DIGITS2 подстрока из первых символов (до 20)  совпадает  с определенной строкой (т.н. «префиксом В»):

-        Значение поля TERID – до 20 символов;

-        Префикс B ( вызываемого абонента)  в поле DIGITS2 – до 20 символов;

-        Новое значение поля TERID  – до 20 символов.

Как правило, «префикс В» применяется для уточнения идентификатора терминатора вызова.

 

Закладка «8.Замена CLID2» содержит данные, позволяющие более полно и точно восстановить идентификатор вызывающего абонента (CLID2) для вызовов, поступивших на определенный TERID.

Поля таблицы:

-        Значение поля TERID  - до 20 символов;

-        Поле CLID2 / Исходное значение – маска, (до 20 символов);

-        Поле CLID2 / Заменить на:   – маска, (до 20 символов).

 

Закладка «9.Слияние CLID2 и TERID» содержит данные, позволяющие более полно и точно восстановить идентификатор вызываемого ресурса в зависимости от CLID2. Используется достаточно редко для решения специфических задач.

Поля таблицы:

-        Значение поля TERID  - до 20 символов;

-        Значение поля CLID2 – маска, (до 20 символов);

-        Новое значение поля TERID  – маска, (до 20 символов).

 

Закладка «10.DIGITS2» содержит данные о том, каким образом необходимо изменить поле DIGITS2 в первоначальной CDR, в зависимости от того, на каком TERID завершился вызов. Чаще всего данный шаблон используется для обозначения маркером «-» внешних исходящих вызовов.

Поля таблицы:

-        TERID  - маска, до 20 символов;

-        Поле DIGITS2 / Исходное значение – маска, (до 32 символов);

-        Поле DIGITS2 / Заменить на: – маска, (до 32 символов).

 

 

В комплексе TarifSV принято обозначать тип вызова в поле DIGITS1 (DIGITS2) выходных (итоговых) таблиц с помощью специальных символов - маркеров. Все вызовы (внутренние, внешние и транзитные) приводятся к 4 основным типам :

 

Значения маркеров  в поле DIGITS, используемых программой TSVlog, и соответствующие им типы вызовов

 

 

Обращаю ваше внимание на то, что вызов автоматически считается внутренним (и программа сама проставит соответствующие маркеры «А» или «В»), если пользователь не определил иное (не пометил этот вызов с помощью шаблонов как внешний, -  входящий или исходящий).

 

И последнее.

Порядок применения (просмотра) содержимого шаблонов в процессе прогона TSVlog и конвертации CDR:  снизу – вверх  и слева – направо.

 

Например, имеем шаблон «3. Замена CLID1» :

 

Значение поля ORIGID	Поле CLID1
	Исходное значение	Заменить на:
%	%	%
%	!!!!!!!!!!!@%	!!!!!!!!!!!
%	!!!!!!!!!!@%	8!!!!!!!!!!
%	!!!!!!!!!@%	!!!!!!!!!
%	!!!!!!!@%	!!!!!!!
%	!!!@%	!!!

 

Например, нам надо преобразовать значение поля CLID1, имеющее не менее 11 символов, из которых одиннадцатый – «@», таким образом, чтобы оставить только первые 10 символов, вставив перед ними символ «8». Значение поля ORIGID при этом несущественно (может быть любым).

 

Пусть у нас к моменту использования данного шаблона: ORIGID = Т9022, а CLID1 = .

Сначала в столбце «Значение поля ORIGID» ищется подходящее значение для Т9022.

Уже самое первое (снизу!) значение маски в этой колонке (% - означает: любая последовательность символов, в том числе – их отсутствие) удовлетворяет искомому значению в поле ORIGID.

Сдвигаемся направо, в столбец «Поле CLID1/Исходное значение». Маска !!!@% не удовлетворяет нашему значению CLID1 = , поскольку до символа @ у нас есть 10 иных символов (9034790389). В маске же указывается, что она подходит только таким  сочетаниям символов, которые содержат ровно три символа до символа @, после чего может быть любая их последовательность (в том числе – их отсутствие).

Идем выше по таблице (шаблону).

Опять анализируем, подходит ли маска в столбце «Значение поля ORIGID» нашему ORIGID. Подходит.

Идем в следующий столбец в той же строке и анализируем, подходит ли маска !!!!!!!@% для нашего CLID1. Не подходит.

Идем по таблице еще выше.

И так далее. До тех пор, пока не найдем нужное сочетание масок и в первой и во второй колонке.

Наконец, в четвертой снизу строке находим искомое: для любого (стоит маска «%») значения ORIGID мы заменим АОН (CLID1) на 8!!!!!!!!!!, если АОН соответствует маске !!!!!!!!!!@%. Это -  наш случай. И первоначальный CLID1 = будет заменен на 89034790389. Что и требовалось.

 

 

Заключение.

 

Комплекс программ TarifSV постоянно совершенствуется. Появляются новые возможности и видоизменяется интерфейс программ.

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

Благодарю всех пользователей комплекса за доверие, помощь и поддержку.

 

 

: Сорокин Виктор Валентинович, Россия, Москва.