Windows Сервис LKDSDomain

[revit]

Что-то никакого обсуждения не наблюдается <_< .

Я , допустим, пока не готов переводить всю сеть c Disp на Domain. На то есть ряд причин.
Использую его конечно, но для всяких некритичных подключений в виде теста и наблюдения за возможностями.

Ну и порой простые вещи типа вот такой https://forum.lkds.ru/index.php?s=&show...ost&p=27173 вымораживают. Как с подобным жить в больших сетях , где куча изменений в день и плюс монтажи т.е новые подключения с настройками, проверками, заморочками различными, я пока не могу представить.

 

[Andi]

Что-то никакого обсуждения не наблюдается <_< .
Возникла необходимость перенести лифты внутри LKDSDomain из одной организации в другую. Немного, всего 25, но всё равно хотелось бы это делать "в два клика".

Может есть смысл изменить доступ к лифту следующим образом:
1. у лифта будет признак "принадлежность организации" (некая "супер группа" соответствующая текущему понятию "организация" в LKDSDomain).
2. "супер администратор" сможет при необходимости этот признак изменить.

При таком подходе в интерфейсе и во внешней логике работы, видимой пользователю LKDSDomain, менять почти ничего не нужно.
Естественно, у записи лифта в базе должен быть уникальный глобальный идентификатор.

Сейчас нет программных средств, что бы сделать это в диалоговом режиме.

У записи лифта в базе данных LKDSDOMAIN уже есть уникальнй код - поле CodLift

Записи в БД связаны друг с другом.

Если изменить в записи лифта поле CodHouse на код другого дома, который может быть в этой или другой организации и перезапустить LKDSDomain, то данный лифт будет в другом доме и, возможно, в другой организации.



Аналогично:

Если в записи дома изменить поле CodStreet на код другого улицы, которая может быть в этой или другой организации и перезапустить LKDSDomain, то данный дом будет в другой улице и, возможно, в другой организации.

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

Если в записи пункта изменить поле CodTeam на код другой организации и перезапустить LKDSDomain, то данный пункт будет в другой организации.



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

И с журналом та же проблема - запись журнала может иметь ссылки и на пользователя и на лифт

 

[Vincent Van Gog]

Сейчас нет программных средств, что бы сделать это в диалоговом режиме.

Как говорят в таких случаях: "Вам и карты в руки" .

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

И с журналом та же проблема - запись журнала может иметь ссылки и на пользователя и на лифт

Не понял эти два момента. Имелось ввиду, что при переносе лифта в другую организацию с ним не будут отображаться записи журнала и подключенные оповещения потому, что привязка (или отбор) идёт по полю CodTeam? Если только отбор, то это можно решить программными средствами без изменения структуры базы (я так думаю по дилетантски).

 

[Andi]

Не понял эти два момента. Имелось ввиду, что при переносе лифта в другую организацию с ним не будут отображаться записи журнала и подключенные оповещения потому, что привязка (или отбор) идёт по полю CodTeam? Если только отбор, то это можно решить программными средствами без изменения структуры базы (я так думаю по дилетантски).

Имелось в виду, что запись журнала связана с записью организации двумя путями:

1. Через пользователя
2. Через лифт->дом->улицу->пункт

 

[Vincent Van Gog]

Имелось в виду, что запись журнала связана с записью организации двумя путями:

1. Через пользователя
2. Через лифт->дом->улицу->пункт

Вложение IPB #2389

Как я понимаю, все записи которые имеются в журнале, после переноса в другую организацию станут недоступны? А что с оповещениями?

 

[Andi]

Как я понимаю, все записи которые имеются в журнале, после переноса в другую организацию станут недоступны?

Не будут отобраны записи журнала перенесённых лифтов, которые имеют ненулевое значение в поле CodUser, т.е. привязанные к конкретному пользователю.

А что с оповещениями?

Оповещение может быть связано к конкретным лифтом:
Если этот лифт перенесён в другую организацию, то оповещений не будет

 

[revit]

Есть необходимость переносить блоки из LKDSPro в LKDSDomain. Можно сделать такой быстрый перенос параметров из списка LKDSPro в список LKDSDomain автоматически включив опцию "связь через "LKDSCloud"?
Примерно так:
1. выбрал из меню "копировать параметры в LKDSDomain"
2. ID, примечание, ключ записались в новую строку в списке LKDSDomain. Если ключ невозможно взять в LKDSPro или он не совпадает с ключами из списка Domain, то можно ввести понятие "ключ по умолчанию" в Domain, т.е отметить один из ключей в списке тех что для Cloud таким признаком и назначать его при переносе.
Аналогичный механизм пригодился бы и в ПКЛШ.

 

[Andi]

Есть необходимость переносить блоки из LKDSPro в LKDSDomain. Можно сделать такой быстрый перенос параметров из списка LKDSPro в список LKDSDomain автоматически включив опцию "связь через "LKDSCloud"?
Примерно так:
1. выбрал из меню "копировать параметры в LKDSDomain"
2. ID, примечание, ключ записались в новую строку в списке LKDSDomain. Если ключ невозможно взять в LKDSPro или он не совпадает с ключами из списка Domain, то можно ввести понятие "ключ по умолчанию" в Domain, т.е отметить один из ключей в списке тех что для Cloud таким признаком и назначать его при переносе.
Аналогичный механизм пригодился бы и в ПКЛШ.

Скорее это нужно сделать в LKDSDomainCfg:

1. "Импорт описаний связей с ЛБ из LKDSPro"
2. "Импорт описаний связей с ЛБ из ПКЛШ"

Далее будет загрузка файла LKDSPro.xml или выбор файла ПКЛШ с последующей загрузкой

Если в импортируемом файле есть ЛБ с неустановленным признаком "связь через LKDSCloud", то будет предупреждение "Для всех импортируемых связей будет установлен признак "связь через LKDSCloud", выберите ключ, который будет использоваться при импорте связей с неустановленным признаком "связь через LKDSCloud""

Если у импортируемой связи уже есть признак "связь через LKDSCloud", то будет использован ключ из этой связи. Ключ будет добавлен в список ключей, если его там ещё нет с названием LKDSPro<последовательный_номер> или сгенерированным из адреса ПКЛШ - Подсеть<номер_подсети>УМ<номер_УМ>Слот<номер_слота><последовательный_номер>.

Если у импортируемой связи нет признака "связь через LKDSCloud", то будет использован ключ, выбранный в предупреждении.

Если в списке ЛБ LKDSDomain уже есть ЛБ с ID из импортируемого списка, то обратки данной связи не будет.

Есть вопрос - почему связь именно через LKDSCloud ?
Как мне казалось прямые прописанные связи должны быть надёжнее и они не будут зависеть от работоспособности LKDSCloud.

 

[revit]

Скорее это нужно сделать в LKDSDomainCfg:
1. "Импорт описаний связей с ЛБ из LKDSPro"
2. "Импорт описаний связей с ЛБ из ПКЛШ"

Это конечно тоже нужно , но это для одноразового применения и для тех кто решил перейти на домэйн навсегда. Я пока к этому не готов.
Мне же необходимо в повседневном администрировании переносить из LKDSPro в домэйн при переходе лифтов или групп лифтов из одной организации в другую. Структура большая и поэтому много лифтов и в ПКЛШ и в LKDSPro. Домэйн пока не для серьезных задач, больше для экспериментальных, но на перспективу такие лифты нужно оставить именно в домэйне.

Есть вопрос - почему связь именно через LKDSCloud ?
Как мне казалось прямые прописанные связи должны быть надёжнее и они не будут зависеть от работоспособности LKDSCloud.

Cloud для временной связи. Потом в LKDSDomain уже переконфигурировать те блоки что нужно будет вывести на прямую связь.
Сразу переконфигурировать все в LKDSPro, входить в каждый блок по одному и вписывать, это во первых не нужно а во вторых муторно для большой группы.

 

[bosporsky]

У нас периодически, провайдер проводит работы ночью, а на резервном интернет-провайдере - нет выделенного ip. Есть ли возможность сделать так, что-бы в случае отсутствия прямой связи с блоками, можно было задействовать связь через LKDSCloud? Так сказать, можно ли задать LKDSCloud в качестве резервного канала связи на блоках 7.2 в LKDSDomain?

 

[Andi]

Это конечно тоже нужно , но это для одноразового применения и для тех кто решил перейти на домэйн навсегда. Я пока к этому не готов.
Мне же необходимо в повседневном администрировании переносить из LKDSPro в домэйн при переходе лифтов или групп лифтов из одной организации в другую. Структура большая и поэтому много лифтов и в ПКЛШ и в LKDSPro. Домэйн пока не для серьезных задач, больше для экспериментальных, но на перспективу такие лифты нужно оставить именно в домэйне.

Это функции не одноразового применения. Можно будет многократно загружать структуры LKDSPro, ПКЛШ, но попадать в структуру LKDSDomain будут те, которых ещё нет в списке ЛБ LKDSDomain.

LKDSDomain, LKDSPro, ПКЛШ существуют параллельно и могут иметь связи с одними и теми же ЛБ.

Cloud для временной связи. Потом в LKDSDomain уже переконфигурировать те блоки что нужно будет вывести на прямую связь.
Сразу переконфигурировать все в LKDSPro, входить в каждый блок по одному и вписывать, это во первых не нужно а во вторых муторно для большой группы.

Важно помнить, что нельзя указывать признак "Связь через LKDSCloud", если в данном ЛБ описана связь на LKDSDomain.

У нас периодически, провайдер проводит работы ночью, а на резервном интернет-провайдере - нет выделенного ip. Есть ли возможность сделать так, что-бы в случае отсутствия прямой связи с блоками, можно было задействовать связь через LKDSCloud? Так сказать, можно ли задать LKDSCloud в качестве резервного канала связи на блоках 7.2 в LKDSDomain?

Так сделать нельзя.
Прямые связи в ЛБ и связь через LKDSCloud в ЛБ работаю по разному

 

[revit]

Это функции не одноразового применения. Можно будет многократно загружать структуры LKDSPro, ПКЛШ, но попадать в структуру LKDSDomain будут те, которых ещё нет в списке ЛБ LKDSDomain.

Ну и зачем мне это на практике? Зачем мне всегда весь список из про и пклш в домен переносить постоянно? В каких ситуациях это можно постоянно применять?

LKDSDomain, LKDSPro, ПКЛШ существуют параллельно и могут иметь связи с одними и теми же ЛБ.

Это я знаю, но опять же, практически, на одном сервере это не нужно. Блок описан и обслуживается в чем то одном и бывает нужно между службами его как то перекидывать .

Важно помнить, что нельзя указывать признак "Связь через LKDSCloud", если в данном ЛБ описана связь на LKDSDomain.

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

 

[Andi]

Ну и зачем мне это на практике? Зачем мне всегда весь список из про и пклш в домен переносить постоянно? В каких ситуациях это можно постоянно применять?

Например, в переходный период, когда нужно параллельно поддерживать LKDSDisp или MPultPro и LKDSDomain.
Если нужно перенести из LKDSPro или ПКЛШ один или несколько конкретных ЛБ, то в LKDSDomainCfg можно будет выдавать список ЛБ в LKDSPro или ПКЛШ, которых нет в LKDSDomain. В этом списке можно будет выбирать нужные для импорта ЛБ.

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

Если указан признак "связь через LKDSCloud" и есть прямая связь на LKDSDomain (LKDSPro, ПКЛШ), то в ЛБ появляется две связи для одного программного ID (идентификатора LKDSDomain, LKDSPro, ПКЛШ). Для каждой этой связи ведётся своя нумерация переданных пакетов данных, так же происходит дублирование данных. И не понятно как должны вести себя в этой ситуации LKDSDomain, LKDSPro, ПКЛШ.

И не важно - вначале был признак "связь через LKDSCloud" и потом прописали связь или была связь, а признак указали потом.

 

[revit]

.... то в LKDSDomainCfg можно будет выдавать список ЛБ в LKDSPro или ПКЛШ, которых нет в LKDSDomain. В этом списке можно будет выбирать нужные для импорта ЛБ.

Выбирать нужные блоки из списка для переноса в LKDSDomain- это хорошо.

Если указан признак "связь через LKDSCloud" и есть прямая связь на LKDSDomain (LKDSPro, ПКЛШ), то в ЛБ появляется две связи для одного программного ID (идентификатора LKDSDomain, LKDSPro, ПКЛШ). Для каждой этой связи ведётся своя нумерация переданных пакетов данных, так же происходит дублирование данных. И не понятно как должны вести себя в этой ситуации LKDSDomain, LKDSPro, ПКЛШ.

И не важно - вначале был признак "связь через LKDSCloud" и потом прописали связь или была связь, а признак указали потом.

Т.е не только в LKDSDomain, но и в LKDSPro и в ПКЛШ двойная связь не допустима?

 

[Andi]

Т.е не только в LKDSDomain, но и в LKDSPro и в ПКЛШ двойная связь не допустима?

Да.

В систему оповещений об ошибках на сервере (оранжевые окошки) должно приходить соответствующее сообщение.

 

[revit]

Да.

В систему оповещений об ошибках на сервере (оранжевые окошки) должно приходить соответствующее сообщение.

Провел эксперимент-в имеющейся прямой связи LKDSPro установил связь через Cloud. Сообщение было только об изменении IP. Других сообщений нет.

 

[grandetype]

Есть вопрос - почему связь именно через LKDSCloud ?
Как мне казалось прямые прописанные связи должны быть надёжнее и они не будут зависеть от работоспособности LKDSCloud.

Вот тут внесу свои 5 копеек. Пару лет назад, когда делал свой первый сервер на lkdsdisp, у меня были прописаны прямые связи блоков и пклш. Блоки постоянно уходили со связи, хотя все порты везде были проброшены, интернет был стабильный, других причин обрыва связи я не нашёл. Сделал второй сервер, там другой провайдер, всё так же описал в связях и на нём тоже стали отваливаться и появляться блоки. Затем узнал про domain, перевёл сервера на него, настроил связь через облако и вуаля, всё стабильно заработало и по сей день.

Не понимаю, чего воротят нос от domain’на. Это очень удобно и просто, связь через облако потрясающая. Никаких городушек в виде пклш и прочего. Плюс появляются плюшки в виде использования да того же atoolcloud с телефона - пропадает необходимость носить с собой ноутбук. Роутеры настраивать не надо, вбил ключ в блоке при первой конфигурации, например, дома, прописал вай фай, а если по кабелю, то и ключа хватит, и неси на объект, ставь, только интернет появится, блок сразу выйдет на связь. Никаких идентификаторов соседа, портов и т.д.

 

[Andi]

Провел эксперимент-в имеющейся прямой связи LKDSPro установил связь через Cloud. Сообщение было только об изменении IP. Других сообщений нет.

Нужно посмотреть ещё "Список последних сообщений..." индикатора ошибок.

Вот тут внесу свои 5 копеек. Пару лет назад, когда делал свой первый сервер на lkdsdisp, у меня были прописаны прямые связи блоков и пклш. Блоки постоянно уходили со связи, хотя все порты везде были проброшены, интернет был стабильный, других причин обрыва связи я не нашёл. Сделал второй сервер, там другой провайдер, всё так же описал в связях и на нём тоже стали отваливаться и появляться блоки. Затем узнал про domain, перевёл сервера на него, настроил связь через облако и вуаля, всё стабильно заработало и по сей день.

Не понимаю, чего воротят нос от domain’на. Это очень удобно и просто, связь через облако потрясающая. Никаких городушек в виде пклш и прочего. Плюс появляются плюшки в виде использования да того же atoolcloud с телефона - пропадает необходимость носить с собой ноутбук. Роутеры настраивать не надо, вбил ключ в блоке при первой конфигурации, например, дома, прописал вай фай, а если по кабелю, то и ключа хватит, и неси на объект, ставь, только интернет появится, блок сразу выйдет на связь. Никаких идентификаторов соседа, портов и т.д.

Важно понимать, что возникает зависимость от работоспособности LKDSCloud.

 

[revit]

Не понимаю, чего воротят нос от domain’на. Это очень удобно и просто, связь через облако потрясающая. Никаких городушек в виде пклш и прочего. Плюс появляются плюшки в виде использования да того же atoolcloud с телефона - пропадает необходимость носить с собой ноутбук. Роутеры настраивать не надо, вбил ключ в блоке при первой конфигурации, например, дома, прописал вай фай, а если по кабелю, то и ключа хватит, и неси на объект, ставь, только интернет появится, блок сразу выйдет на связь. Никаких идентификаторов соседа, портов и т.д.

Ну Cloud работает вне зависимости от того что вы используете Domain или Disp.
А по поводу использования Domain-обоняние тут не причем как и другие чувства. Просто когда у тебя сеть из 3000 блоков и пары десятков подсетей в которых есть много пользователей, и каждый день вносятся изменения в структуры, то сделать так чтобы быстро и беспроблемно перейти c Pro и Disp на Domain не так то просто.... А учитывая то что некоторые вещи в Domain в отличие Disp еще и непривычны и неудобны для использования в больших сетях, то пока такое решение не принимается.
И еще ко всему -есть группа блоков и на Domain-е и переход нужно делать из Pro+Disp+Domain-> Domain. Есть мысли как это сделать быстро и без последствий?

 

[Vincent Van Gog]

И еще ко всему -есть группа блоков и на Domain-е и переход нужно делать из Pro+Disp+Domain-> Domain. Есть мысли как это сделать быстро и без последствий?

Быстро не получиться, а для "без последствий" - поднимай второй сервак параллельно с основным и поэтапно переводи на него пользователей.