Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Warning

Обязательно раскрыть и выполнить те пункты, которые удовлетворяют по условию той версии, с которой вы обновляетесь.

1. Создайте резервную копию БД, и всех приложений биллинга.
2. BGBilling версии с 6.2 должен быть запущен под JAVA JDK 1.8. Это обязательное условие, он скомпилирован под jdk 1.8, а под jdk 1.6-1.7

...

работать

...

вообще

...

не

...

будет

...

(даже

...

не

...

запустится).

...

Установите

...

JDK

...

1.8.

...

Expand
titleОбновление производится с версии <= 4.5
1) Сохраните информацию о том, какие абонентские платы были указаны для каждого из шаблонов договоров.

...

Expand
titleОбновление производится с версии <= 6.2
1) Приобретите лицензию на 7.0 версию биллинга и получите лицензионный файл lic.properties. Проверьте его на отдельно установленном сервере биллинга версии 7.0.
   Убедитесь, что индикатор лицензий отображает корректное количество договоров. 
 
3.

...

Выполните

...

инструкцию

...

по

...

обновлению

...

с

...

версии

...

7.

...

1 начиная

...

с

...

пункта

...

2

...

-

...

до

...

конца:
Инструкция по обновлению с версии 7.

...

1 на версию 7.

...

2

 

Expand
titleОбновление производится с версии <= 5.1
1) Начиная с версии 5.2 все шаблоны FO должны быть строговалидны. Если вы писали сами (или правили дистрибутивные)
	карточки договора, шаблоны счетов, счетов-фактур итд, то вам надо дополнительно проверить
	их на валидность стандарту FO-XSL. Варианты:
	а) использовать заново файлы из дистрибутива или изменить их снова, там они подправлены и заведомо корректные;
	б) проверить любым fo-xsl редактором на валидность свои шаблоны;
	в) использовать простой fo-валидатор, указывающий (но не исправляющий!) все ошибки, встречавшиеся
	во всех дистрибутивных fo-xsl документах.
	Дополнительная информация: http://forum.bgbilling.ru/viewtopic.php?t=4942
	Ссылка: ftp://ftp.bgbilling.ru/pub/bgbilling/util/fo_validator.zip
	
	   	
2)	Плагин cachcheck: понятие очереди печати изменилось. Также изменились вид и имя таблицы в БД, экшены сменились на вебсервисы.
	Старая таблица остаётся на месте, всё копируется в новую. Если используете в отчётах таблицу, обратите внимание, что надо указать новую.
	Если у вас были какие-то внешние обращения к экшенам или БД (приложения, отчёты) обратите на это внимание.
	Вместо скриптов формирования вида чека используется динамический код. Если у вас самописные скрипты, потребуется постепенно переписать.
	В настройках плагина параметры сервер и порт регистратора не поддерживаются, используется параметр connector.
	Дополнительная информация: http://forum.bgbilling.ru/viewtopic.php?t=6194
	
3) Если у вас был скриптовый обработчик события "Приход платежа" и вам нужно обрабатывать так же и изменение лимитов этим
	обработчиком( до версии 5.2 при изменени  лимита генерировалось событие "Приход платежа"), то нужно также обработать и событие "Изменение Лимита договора"
	(проставте галочку возле этого события тоже) .			   
	
4)  Структура WiFi-агента для модуля Dilaup кардинально поменялась, нужно скачать его целиком с сайта, настроить заново. 
Обратите вимание на: 
	а) имя конфигурационного файла поменялось на dialup_wifi.properties, 
	б) опция  billing.server.dialup.mid заменилось на  billing.server.moduleId, добавились новые опции,
	в) добавились настройки activemq 
	г) встроенные команды вынесены во внешние скрипты, 
	д) перед запуском нужно запустить update.sh, 
	е) в setenv.sh прописать JAVA_HOME, 
	ж) более подробно читайте в документации .  
	
5) Плагин CRM. Так как в 5.2. появилась возможность настраивать список статусов задач, то для хранения истории изменения статусов была добавлена новая таблица register_task_log
если вам нужна история изменения статуса для старых задач, то нужно выполнить несколько sql запросов для того, что бы заполнить таблицу register_task_log данными

 insert into register_task_log select id, open_dt, open_uid, 0 from register_task;
 insert into register_task_log select id, accept_dt, accept_uid, 1 from register_task;
 insert into register_task_log select id, close_dt, close_uid, 2 from register_task;
 
6) Если вы используете Slave базы, скорректируйте параметры в URL подключения к БД согласно документации.	   
	http://bgbilling.ru/v5.2/doc/ch01s24s02.html 

...

Expand
titleОбновление производится с версии <= 3.75
1) Если вы используете воип модуль добавьте в его конфигурации
	#
	findmode.0.title=Поиск по User-Name=LOGIN
	findmode.0.value=User-Name=LOGIN
	findmode.1.title=Поиск по User-Name=ALIAS
	findmode.1.value=User-Name=ALIAS
	findmode.2.title=Поиск по Calling-Station-Id=ALIAS
	findmode.2.value=Calling-Station-Id=ALIAS
	#
	find.order=0,1,2
   
   И во всех логинах которые находятся не по User-Name=LOGIN проставьте нужные
   режимы поиска.
   
2) Внимание!!!
   При использовании NetFlow коллектора для модуля IPN необходимо обновлять 
   биллинг во время с минимальным трафиком.

   Старый коллектор остается работающим.
   Новый коллектор ставится параллельно на другие порты, NetFlow потоки на него дублируются.
   Коллектор настраивается в соответствии с документацией в режиме загрузки и обработки. 

   После того как новый коллектор успешно начнет выполнять свои функции старый 
   коллектор останавливается.
   Оценить корректность работы коллектора можно по тому что после обновления 
   логи будут обрабатываться.
   В каталоге с бинарными логами новго коллектора должны появиться подкаталоги 
   для всех источников.

   Новый dataloader не обрабатывает логи NetFlow источников, оставляя их коллекторам.
   Поэтому если возникнет необходимость переобработки логов еще старого коллектора
   (они хранятся в БД) тип источника следует изменить на FTP и добавить задание на о
   бработку за нужные часы.

   После обработки тип источника нужно вернуть на NetFlow и проставить адрес.
   
Expand
titleОбновление производится с версии <= 4.1
1) Если вы используете модуль voiceip - необходимо выполнить переобсчет сессий за текущий месяц
   для добавления в таблицу сессий колонки с округленной длительностью звонка.
   Если база большая - вы можете пересчитать сессии только одного договора.
Expand
titleОбновление производится с версии <= 4.3
1) Скорректировать шаблоны кредитовых договоров для установки большого отрицательного лимита. Например, -10000000.

2) В "Сервис=>SQL Редактор" либо с помощью mysql клиента выполните запрос: 
	UPDATE contract SET closesumma=-1000000 WHERE mode=0
	
3) Для каждого из экземпляров dialup модуля выполните запрос в "Сервис=>SQL Редактор" ибо с помощью mysql клиента:
	ALTER TABLE session_detail_<mid>_<yyyyMM> ALTER COLUMN summa SET DEFAULT 0;
   где <mid> - код экземпляра модуля
   <yyyyMM> - текущие год и месяц, например 200801
   При выведении ошибки  Unknown column 'summa' in 'session_detail_...' пункт пропустить и перейти к следующему.
    
Expand
titleОбновление производится с версии <= 4.4
1) Для модуля IPN. 
   При переходе на версию 4.5 поменялась работа со шлюзами и типами правил для шлюзов Manad, Cisco, Miktotik, BGRadiusIPN .
   
   1.1. После обновления откройте список типов правил - он теперь не привязан к конкретному шлюзу и поэтому отображается полный список типов правил.  
   Если у вас много различных типов шлюзов, то чтобы  не путаться рекомендуется в зависимости от содержимого переименовать типы правил, так , 
   чтобы название типа шлюза было в названии правила ..Например manand_128, manad_256, cisco..
   
   1.2. При использовании типа шлюза Manad под FreeBSD со старым синтаксисом нужно добавить теги <LOOP></LOOP>. Т.е если у вас был тип правила:
	pipe {P0} config bw 512000
	pipe {P1} config bw 512000
	add {N1} pipe {P0} all from any to {A}
	add {N1} pipe {P1} all from {A} to any
   Его заменяем на :
	<LOOP>
		pipe {P0} config bw 512000
		pipe {P1} config bw 512000
		add {N1} pipe {P0} all from any to {A}
		add {N1} pipe {P1} all from {A} to any
	</LOOP>
   
   1.3. Для типов шлюзов Manad, Cisco, Mikrotik перенесите текст типов правил в команды типа шлюза. Синтаксис  команд в типе шлюза описан в документации 4.5(и выше). 
   При переносе типов правил Mikrotik обратите внимание, что нужно заменить теги <OPEN></OPEN> и <CLOSE></CLOSE> на [OPEN][/OPEN] и [CLOSE][/CLOSE] соответственно. 
   И нужно продублировать содержимое тега [CLOSE][/CLOSE] в теге [DELETE][/DELETE].

   1.4. Для типов шлюзов Manad, Cisco, Miktotik, BGRadiusIPN нужно указать какие типы правил доступны на данном типе шлюзе. 
   При редактировании типа шлюза есть вкладка "Типы правил". Туда нужно добавить соответствующие правила.
   
   1.5. Оптимизировать правила для Manad, Сisco, Mikrotik. Покажем на примере. Допустим, у вас был тип шлюза Manad и не нем следующие типы правил:
	Стандартный клиент 256: 	
		<LOOP>		
			pipe {P0} config bw 256000
			pipe {P1} config bw 256000
			add {N2} pipe {P0} all from any to {A}
			add {N2} pipe {P1} all from {A} to any
		</LOOP>
	Стандартный клиент 512:
		<LOOP>
			pipe {P0} config bw 512000
			pipe {P1} config bw 512000
			add {N1} pipe {P0} all from any to {A}
			add {N1} pipe {P1} all from {A} to any
		</LOOP>
	Вы создаете в типе шлюза следующую конфигурацию :
	[DEFAULT]
		<LOOP>
			pipe {P0} config bw ${speed}
			pipe {P1} config bw ${speed}
			add {N2} pipe {P0} all from any to {A}
			add {N2} pipe {P1} all from {A} to any					
		</LOOP>
	[/DEFAULT]

	Типы правил изменяете. Стандартный клиент 256: speed=256000; Стандартный клиент 512: speed=512000.

2) Если вы использовали смену тарифных планов пользователем через Web интерфейс,
   произведите настройку данной подсистемы заново, основываясь на документации:
   http://bgbilling.ru/v4.5/doc/ch01s21s08.html

3) В справочниках привязать улицы, районы, кварталы к городам. 
   Если у вас один город то можно привязать следующим образом.
   В В "Сервис=>SQL Редактор" либо с помощью mysql клиента выполните запросы: 
	UPDATE address_street SET cityid=<id города>  
	UPDATE address_area SET cityid=<id города>
	UPDATE address_quarter SET cityid=<id города>
    
   <id города> получаем в справочниках городов нажатием Ctrl+i.

...

Expand
titleОбновление производится с версии <= 6.2
  1. Для модуля Inet: переместите параметр конфигурации accounting.deviceTypeIds из inet-access.xml (<param name="accounting.deviceTypeIds" value="x"/>) в конфигурацию модуля (accounting.deviceTypeIds=x), если еще не сделали этого.
Expand
titleОбновление производится с версии <= 7.0

1. Модуль Бухгалтерия(Bill). В связи с тем, что типы реквизитов теперь создаются в справочнике модуля Бухгалтерии, необходимо перенести их из конфигурации модуля. Если типов не много, то можно в ручную, иначе можно воспользоваться конвертером.
1.1. Запуск конвертера осуществляется следующим образом: запустите командную строку (cmd в ОС Windows; xterm, konsole (или любой другой) - в Linux), перейдите в каталог BGBillingServer и запустите
Для LINUX: <путь к Java>/bin/java -Xmx256m -cp .:./lib/app/*:./lib/ext/* ru.bitel.bgbilling.modules.bill.server.utils.Converter_attributes <mid>
Для Windows: <путь к Java>\bin\java -Xmx256m -cp .:./lib/app/*:./lib/ext/* ru.bitel.bgbilling.modules.bill.server.utils.Converter_attributes <mid>
Для FreeBSD(по рекомендации пользователей):java -Xmx256m -cp ".:./lib/app/*:./lib/ext/*" ru.bitel.bgbilling.modules.bill.server.utils.Converter_attributes <mid>
где <mid> - код модуля бухгалтерия(без угловых скобок)
1.2 Убедитесь в том, что данные импортировались( Бухгалтерия->Справочники->Типы Реквизитов ).
1.3 Можете удалить поле "bill.attributes" из конфига модуля.

2. Модуль Inet. При обновлении, особенно если оно происходит не в начале месяца, желательно переименовать таблицу connection_log_entry_<mid>_<yyyyMM> за текущий месяц в, например, connection_log_entry_<mid>_<yyyyMM>_bak. Данная таблица содержит не важные данные, а вспомогательные, для отображение RADIUS/DHCP-лога сессии. После старта InetAccess/InetAccounting создастся новая таблица.
Или же можете вызвать обновление таблицы вручную (перед запуском InetAccess/InetAccounting), посмотрев длительность выполнения данного запроса сначала на тестовой БД:
ALTER TABLE connection_log_entry_<mid>_<yyyyMM> ADD COLUMN `identifier` VARCHAR(50) NULL , DROP INDEX `app-dev-con`, ADD INDEX `app-dev-con` (`deviceId`, `time`, `connectionId`, `acctSessId`, `identifier`)