forum.bitel.ru :: Просмотр темы - Изменения состояния шлюза из скрипта поведения

Это конечно хорошо, а как статус получить шлюза?

И кто такой int userID ?

Вам его получить надо или изменить?

И кто такой int userID ?

Подскажите почему? что я делаю не так?

у вас версия 4.6 ? там поменялось api - нет такого конструктора там нужно ещ добавить тритий параметр ModuleSetup. его можно получать так : Setup.getSetup().getModuleSetup( mid ), где mid - код модуля IPN

bundleName - имя файла *.properties с данными

skn писал(а):

bundleName - имя файла *.properties с данными

А нельзя ли подробнее?? Где этот файл лежит? Что в нем должно быть?
Писать с полным путем или как? В документации по API про это вообще ничего нет. Напишите пример если не сложно.

как можно запретить изменение параметров модуля IPN в договоре если статус шлюза не находится в статусе "удален".

Подскажите как из скрипта поведения изменить состояние шлюза.

ODV писал(а):

Подскажите как из скрипта поведения изменить состояние шлюза.

Подскажите, пожалуйста
как выполнить скрипт с набором команд относящейся к шлюзу состояние которого изменили из скрипта поведения?

Что-то прописываю в скрипте, а все равно выходит ошибка
Unknown class: ModuleSetup : at Line: 30 :

Тоже вставлю свою часть вопроса с вашего позволения

А можно ли производить какие либо действия со шлюзами, не привязанными к конкретному договору? Задача раскидать по группе шлюзов (набор, порядка 5-10 шт) создание пользовательского вилана.

Для себя это виделось примерно так:

1. Группируем комутаторы в папки - одна папка, это одна группа
2. Пользователю привязываем один из комутаторов из этой папки
3. При открытии шлюза, пробегаемся по всем комутаторам в папке и так же открываем персональный вилан.
4. При "удалении" шлюза, удаляем из всех комутаторов группы.

В п.3 идеально конечно было бы иметь не просто "открытие", а "создание"... но это уже не раз обсуждалось, и вроде все решили, что должно быть только "открытие" шлюза.

Все это необходимо для автоматического создания пользовательского вилана на кольце комутаторов, соединенных по stp. Понимаю, что скажете - а не проще ли VTP поднять? Но к сожалению, оборудование неоднородное и приходится извращаться.

Что скажете?

Подскажите пожалуйста, как управлять комутатором, который не привязан к договору? Саму группу комутаторов я выбиру из базы ручками запросом, получу их ID. Что дальше делать? Надо вызвать метод конкретного шлюза (открыть/закрыть его). Как это сделать?

GVRP к сожалению не поддерживает часть оборудования, так же как и VTP

Иерархию не знаю как построить, т.к. по сути группы - это есть кольца STP, дерева там не получается. А группа как раз оно - Делаю папку и в нее запихиваю все комутаторы кольца. В итогде все в кольце (в группе) должны иметь виланы на транковых портах. Транковые порты в свою очередь пропишу у каждого шлюза в конфигурации.

Подскажите пожалуйста, как управлять комутатором, который не привязан к договору? Саму группу комутаторов я выбиру из базы ручками запросом, получу их ID. Что дальше делать? Надо вызвать метод конкретного шлюза (открыть/закрыть его). Как это сделать?

одна проблемка номер влан должен вводится вручную, а он берется из списка по порядку.

mikos писал(а):

GVRP к сожалению не поддерживает часть оборудования, так же как и VTP

как вариант,
влан навсегда "прибивается" к порту коммутатора доступа,
заранее конфигурится и получаем жесткую связку
порт доступа -> номер влан - >транк->виртуальный интерфейс L3 на агрегации.

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

Схема упрощается, в договор добавляется только агрегатор.

одна проблемка номер влан должен вводится вручную, а он берется из списка по порядку.

Автор:	ODV [ 27 мар 2009, 15:41 ]
Заголовок сообщения:	Изменения состояния шлюза из скрипта поведения
Подскажите как из скрипта поведения изменить состояние шлюза и как можно запретить изменение параметров модуля IPN в договоре если статус шлюза не находится в статусе "удален".

Автор:	KaDaBRa [ 22 апр 2009, 09:35 ]
Заголовок сообщения:
Поддерживаю, как можно в скрипте поведения управлять состоянием шлюза в договоре?

Автор:	niceone [ 22 апр 2009, 13:10 ]
Заголовок сообщения:
+1

Автор:	Администратор [ 22 апр 2009, 15:24 ]
Заголовок сообщения:
http://www.bgbilling.ru/v4.5/javadoc/bi ... %20boolean)

Автор:	KaDaBRa [ 22 апр 2009, 15:46 ]
Заголовок сообщения:
Это конечно хорошо, а как статус получить шлюза? И кто такой int userID ?

forum.bitel.ru http://forum.bitel.ru/

Изменения состояния шлюза из скрипта поведения http://forum.bitel.ru/viewtopic.php?f=7&t=2087	Страница 1 из 2

Автор:	Администратор [ 22 апр 2009, 16:05 ]
Заголовок сообщения:
Цитата: Это конечно хорошо, а как статус получить шлюза? Вам его получить надо или изменить? Цитата: И кто такой int userID ? Код пользователя биллинга, можете ставить 0 - значит сервер.

Автор:	KaDaBRa [ 22 апр 2009, 16:11 ]
Заголовок сообщения:
Администратор писал(а): Вам его получить надо или изменить? И получить и изменить Цитата: И кто такой int userID ? Код пользователя биллинга, можете ставить 0 - значит сервер.[/quote] Понял, спасибо.

Автор:	Администратор [ 22 апр 2009, 16:22 ]
Заголовок сообщения:
Ну в том же классе есть метод получения статуса..

Автор:	KaDaBRa [ 22 апр 2009, 16:41 ]
Заголовок сообщения:
Простите, называется смотрю в книгу вижу фигу А теперь другая проблема, яву я знаю поскольку постольку, много времени на изучение нету:( Скрипт есть: Код: import java.sql.; import java.util.; import bitel.billing.server.script.event.; import bitel.billing.server.contract.bean.; import bitel.billing.server.tariff.; import bitel.billing.server.util.; import bitel.billing.server.ipn.bean.; import bitel.billing.common.module.ipn.IPNContractStatus; cid = event.getContractID(); ipnstat = new IPNContractStatusManager(con,5).getContractStatus(cid); print (ipnstat); выдает вот такое: Код:* Sourced file: Function [id:13; title:GateIPN] : Constructor error: Can't find constructor: bitel.billing.server.ipn.bean.IPNContractStatusManager( org.apache.commons.dbcp.PoolableConnection, int ) in class: bitel.billing.server.ipn.bean.IPNContractStatusManagerSourced file: Function [id:13; title:GateIPN] : Constructor error: Can't find constructor: bitel.billing.server.ipn.bean.IPNContractStatusManager( org.apache.commons.dbcp.PoolableConnection, int ) in class: bitel.billing.server.ipn.bean.IPNContractStatusManager : at Line: 11 : in file: Function [id:13; title:GateIPN] : new IPNContractStatusManager ( con , 5 ) at bsh.BSHAllocationExpression.constructObject(Unknown Source) at bsh.BSHAllocationExpression.objectAllocation(Unknown Source) at bsh.BSHAllocationExpression.eval(Unknown Source) at bsh.BSHPrimarySuffix.doSuffix(Unknown Source) at bsh.BSHPrimaryExpression.eval(Unknown Source) at bsh.BSHPrimaryExpression.eval(Unknown Source) at bsh.BSHAssignment.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at ru.bitel.bgbilling.kernel.script.server.bean.ScriptInstance.eval(ScriptInstance.java:310) at bitel.billing.server.script.bean.ScriptMachine$SimpleScriptRunner.runScript(ScriptMachine.java:60) at bitel.billing.server.script.bean.ScriptMachine.runScript(ScriptMachine.java:128) at bitel.billing.server.script.bean.event.EventProcessor.processEvent(EventProcessor.java:238) at bitel.billing.server.script.bean.event.EventProcessor.run(EventProcessor.java:152) Подскажите почему? что я делаю не так?

Автор:	stark [ 22 апр 2009, 20:10 ]
Заголовок сообщения:
KaDaBRa писал(а): Подскажите почему? что я делаю не так? у вас версия 4.6 ? там поменялось api - нет такого конструктора там нужно ещ добавить тритий параметр ModuleSetup. его можно получать так : Setup.getSetup().getModuleSetup( mid ), где mid - код модуля IPN

Автор:	KaDaBRa [ 22 апр 2009, 20:26 ]
Заголовок сообщения:
stark писал(а): у вас версия 4.6 ? там поменялось api - нет такого конструктора там нужно ещ добавить тритий параметр ModuleSetup. его можно получать так : Setup.getSetup().getModuleSetup( mid ), где mid - код модуля IPN Ага, именно 4.6, спасибо большое

Автор:	DeusInversus [ 24 апр 2009, 16:34 ]
Заголовок сообщения:
stark писал(а): у вас версия 4.6 ? там поменялось api - нет такого конструктора там нужно ещ добавить тритий параметр ModuleSetup. его можно получать так : Setup.getSetup().getModuleSetup( mid ), где mid - код модуля IPN Разработчики, что такое bundleName в конструкторе класса Setup??

Автор:	skn [ 24 апр 2009, 18:13 ]
Заголовок сообщения:
bundleName - имя файла *.properties с данными

Автор:	DeusInversus [ 25 апр 2009, 14:16 ]
Заголовок сообщения:
skn писал(а): bundleName - имя файла *.properties с данными А нельзя ли подробнее?? Где этот файл лежит? Что в нем должно быть? Писать с полным путем или как? В документации по API про это вообще ничего нет. Напишите пример если не сложно.

Автор:	madmax [ 05 авг 2009, 23:29 ]
Заголовок сообщения:
Что то не могу понять. Пишу так выходит ошибка module = Setup.getSetup().getModuleSetup(1); ipn = new IPNContractStatusManager( con, 1, module); ipn_status = ipn.getContractStatus( cid ); Можно примерчик

Автор:	ODV [ 06 авг 2009, 01:45 ]
Заголовок сообщения:
// Переводим шлюз в стату "закрыт" modset = new ModuleSetup(con, mid); (new IPNContractStatusManager(con, mid, modset)).changeStatus(cid, 0, 0, true);

Страница 1 из 2	Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/

Автор:	stark [ 27 апр 2009, 17:11 ]
Заголовок сообщения:
DeusInversus писал(а): skn писал(а): bundleName - имя файла *.properties с данными А нельзя ли подробнее?? Где этот файл лежит? Что в нем должно быть? Писать с полным путем или как? В документации по API про это вообще ничего нет. Напишите пример если не сложно. это путь от текущего classpath ..Для сервера это папка classes и корневая папка биллинга (обе сразу).. Обычно пишут new Setup(data.data) и он находит файл data/data.properties .. это для создания , но вам это не надо ..Вам достатьнчо скоре всего вызывать статически метод Setup.getSetup() и получить текущий Setup

Автор:	msh [ 07 май 2009, 21:33 ]
Заголовок сообщения:	Re: Изменения состояния шлюза из скрипта поведения
ODV писал(а): как можно запретить изменение параметров модуля IPN в договоре если статус шлюза не находится в статусе "удален". было бы полезно, а то иногда забывают и оставляют свитчи в озадаченном состоянии

Автор:	ODV [ 14 май 2009, 17:51 ]
Заголовок сообщения:	Re: Изменения состояния шлюза из скрипта поведения
ODV писал(а): Подскажите как из скрипта поведения изменить состояние шлюза. Подскажите, пожалуйста как выполнить скрипт с набором команд относящейся к шлюзу состояние которого изменили из скрипта поведения?

Автор:	stark [ 15 май 2009, 16:30 ]
Заголовок сообщения:	Re: Изменения состояния шлюза из скрипта поведения
ODV писал(а): ODV писал(а): Подскажите как из скрипта поведения изменить состояние шлюза. Подскажите, пожалуйста как выполнить скрипт с набором команд относящейся к шлюзу состояние которого изменили из скрипта поведения? не понял вопроса, вам уже выше отчетили как зменеть состояние шлюза, при этом если шлюз скриптовый, то отработает его скрипт

Автор:	ODV [ 15 май 2009, 17:04 ]
Заголовок сообщения:
разобрался спасибо, все работает.

Автор:	madmax [ 20 авг 2009, 22:56 ]
Заголовок сообщения:
Что-то прописываю в скрипте, а все равно выходит ошибка Unknown class: ModuleSetup : at Line: 30 :

Автор:	stark [ 21 авг 2009, 12:36 ]
Заголовок сообщения:
madmax писал(а): Что-то прописываю в скрипте, а все равно выходит ошибка Unknown class: ModuleSetup : at Line: 30 : import ru.bitel.bgbilling.server.util.ModuleSetup;

Автор:	mikos [ 22 авг 2009, 16:41 ]
Заголовок сообщения:
Тоже вставлю свою часть вопроса с вашего позволения А можно ли производить какие либо действия со шлюзами, не привязанными к конкретному договору? Задача раскидать по группе шлюзов (набор, порядка 5-10 шт) создание пользовательского вилана. Для себя это виделось примерно так: 1. Группируем комутаторы в папки - одна папка, это одна группа 2. Пользователю привязываем один из комутаторов из этой папки 3. При открытии шлюза, пробегаемся по всем комутаторам в папке и так же открываем персональный вилан. 4. При "удалении" шлюза, удаляем из всех комутаторов группы. В п.3 идеально конечно было бы иметь не просто "открытие", а "создание"... но это уже не раз обсуждалось, и вроде все решили, что должно быть только "открытие" шлюза. Все это необходимо для автоматического создания пользовательского вилана на кольце комутаторов, соединенных по stp. Понимаю, что скажете - а не проще ли VTP поднять? Но к сожалению, оборудование неоднородное и приходится извращаться. Что скажете?

Автор:	stark [ 24 авг 2009, 15:41 ]
Заголовок сообщения:
mikos писал(а): Тоже вставлю свою часть вопроса с вашего позволения А можно ли производить какие либо действия со шлюзами, не привязанными к конкретному договору? Задача раскидать по группе шлюзов (набор, порядка 5-10 шт) создание пользовательского вилана. Для себя это виделось примерно так: 1. Группируем комутаторы в папки - одна папка, это одна группа 2. Пользователю привязываем один из комутаторов из этой папки 3. При открытии шлюза, пробегаемся по всем комутаторам в папке и так же открываем персональный вилан. 4. При "удалении" шлюза, удаляем из всех комутаторов группы. В п.3 идеально конечно было бы иметь не просто "открытие", а "создание"... но это уже не раз обсуждалось, и вроде все решили, что должно быть только "открытие" шлюза. Все это необходимо для автоматического создания пользовательского вилана на кольце комутаторов, соединенных по stp. Понимаю, что скажете - а не проще ли VTP поднять? Но к сожалению, оборудование неоднородное и приходится извращаться. Что скажете? а GVRP тоже не подойдет ? вообще теоретически ваш вариант заработает . Только мне вот кажется лучше делать иерархию шлюзов, а не группы . Т.е клиенту добалять конченый шлюз, и синхронизация будет вызываться у него и всех его родителей

Автор:	mikos [ 26 авг 2009, 01:05 ]
Заголовок сообщения:
GVRP к сожалению не поддерживает часть оборудования, так же как и VTP Иерархию не знаю как построить, т.к. по сути группы - это есть кольца STP, дерева там не получается. А группа как раз оно - Делаю папку и в нее запихиваю все комутаторы кольца. В итогде все в кольце (в группе) должны иметь виланы на транковых портах. Транковые порты в свою очередь пропишу у каждого шлюза в конфигурации. Подскажите пожалуйста, как управлять комутатором, который не привязан к договору? Саму группу комутаторов я выбиру из базы ручками запросом, получу их ID. Что дальше делать? Надо вызвать метод конкретного шлюза (открыть/закрыть его). Как это сделать?

Автор:	stark [ 26 авг 2009, 11:14 ]
Заголовок сообщения:
mikos писал(а): Подскажите пожалуйста, как управлять комутатором, который не привязан к договору? Саму группу комутаторов я выбиру из базы ручками запросом, получу их ID. Что дальше делать? Надо вызвать метод конкретного шлюза (открыть/закрыть его). Как это сделать? GateTypeManager gateTypeManager = new GateTypeManager( con, mid ); RuleTypeManager ruleTypeManager = new RuleTypeManager( con, mid ); Map gateTypeMap = gateTypeManager.getTypeMap(); допутсим вы получили спискл шлюзов : List gates ; далее в цикле : for( Gate gate : gates ) { GateType type = gateTypeMap.get( gate.getTypeId() ); GateWorker worker = (GateWorker)Utils.classByName( type.getGateManager() ); gate.setGateType( type ); worker.init( gate, ruleTypeManager.getTypeMap( gate.getTypeId() ), gateTypeMap, con, mid ); worker.start(); }

Автор:	tee [ 26 авг 2009, 14:31 ]
Заголовок сообщения:
mikos писал(а): GVRP к сожалению не поддерживает часть оборудования, так же как и VTP Иерархию не знаю как построить, т.к. по сути группы - это есть кольца STP, дерева там не получается. А группа как раз оно - Делаю папку и в нее запихиваю все комутаторы кольца. В итогде все в кольце (в группе) должны иметь виланы на транковых портах. Транковые порты в свою очередь пропишу у каждого шлюза в конфигурации. Подскажите пожалуйста, как управлять комутатором, который не привязан к договору? Саму группу комутаторов я выбиру из базы ручками запросом, получу их ID. Что дальше делать? Надо вызвать метод конкретного шлюза (открыть/закрыть его). Как это сделать? как вариант, влан навсегда "прибивается" к порту коммутатора доступа, заранее конфигурится и получаем жесткую связку порт доступа -> номер влан - >транк->виртуальный интерфейс L3 на агрегации. В этом случае совершенно неважно какого производителя свичи доступа, могут быть даже конфигурируемые через консольный порт информация записывается туда один раз. Схема упрощается, в договор добавляется только агрегатор. одна проблемка номер влан должен вводится вручную, а он берется из списка по порядку.

Автор:	stark [ 26 авг 2009, 16:08 ]
Заголовок сообщения:
tee писал(а): одна проблемка номер влан должен вводится вручную, а он берется из списка по порядку. Редактировать vlan можно в 5.0 . кстатит ее night- build-ы уже доступны : ftp://bgbilling.ru/pub/bgbilling/5.0/ а пока можете использовать параметр договора в качестве vlan

Автор:	mikos [ 26 авг 2009, 23:00 ]
Заголовок сообщения:
tee писал(а): mikos писал(а): GVRP к сожалению не поддерживает часть оборудования, так же как и VTP Иерархию не знаю как построить, т.к. по сути группы - это есть кольца STP, дерева там не получается. А группа как раз оно - Делаю папку и в нее запихиваю все комутаторы кольца. В итогде все в кольце (в группе) должны иметь виланы на транковых портах. Транковые порты в свою очередь пропишу у каждого шлюза в конфигурации. Подскажите пожалуйста, как управлять комутатором, который не привязан к договору? Саму группу комутаторов я выбиру из базы ручками запросом, получу их ID. Что дальше делать? Надо вызвать метод конкретного шлюза (открыть/закрыть его). Как это сделать? как вариант, влан навсегда "прибивается" к порту коммутатора доступа, заранее конфигурится и получаем жесткую связку порт доступа -> номер влан - >транк->виртуальный интерфейс L3 на агрегации. В этом случае совершенно неважно какого производителя свичи доступа, могут быть даже конфигурируемые через консольный порт информация записывается туда один раз. Схема упрощается, в договор добавляется только агрегатор. одна проблемка номер влан должен вводится вручную, а он берется из списка по порядку. В общем-то сейчас так и делаем, виланы берем по порядку. Вся заворушка что расписывал как раз для раскидывания конфигов по комутаторам кольца.