Автоматически прописать путь к базам в 1С 8.2

Начинается переход с 1с 7.7 на 8.2.
Необходимо в автоматическом режиме добавить информационные базы всем пользователям.
В 7.7 это делалось путем добавления необходимого ключа в реестр с помощью логон-скрипта.
В 8.2. нашел следующий способ.
Создаем файл с расширением .v8i и с содержанием, подобным этому:

[Демо]
Connect=File="\\SERVER\Share1c\Base\Demo";
OrderInList=1
Folder=/
OrderInTree=1
App=Auto
DefaultApp=ThickClient
WA=1
Version=8.2.13.219

Еще есть такой вариант:

[Название базы в списке]
Connect=Srvr=SERVER1;Ref=demo
OrderInList=1
Folder=/
OrderInTree=1
App=Auto
DefaultApp=ThickClient
WA=1
Version=8.2.13.219

Где SERVER1 - имя сервера приложений 1С, demo - имя базы данных на сервере.

Далее в файле %ProgramFilesDir%\1cv82\common\1CESCmn.cfg прописываете строку (без кавычек) : "CommonInfoBases=\\SERVER\SHARE\ibcommon.v8i"

Где SERVER - имя сервера с сетевой папкой, SHARE - имя самой шары.

Файл 1CESCmn.cfg можно подкладывать любым доступным способом (скриптом, при установке клиента и пр.).

Добавление новой базы происходит правкой текстового файла на шаре, пользователи увидят новую базу при следующем запуске 1С.

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

Elastix

Вообще, повозится с Asterisk мне хотелось достаточно давно. Но как то все не до этого было.

А тут у меня появился новый начальник, который решил, что надо бы нам его попробовать.

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

Мне же лично хотелось неторопливо и вдумчиво почитать документацию, с нуля настраиваю попутно систему в тестовом режиме. Чтобы при этом никто не стоял над душой.

Но придется, по крайней мере пока, использовать готовое решение. 

В принципе, большинство этих готовых  решений отличается не сильно. Ну подумаешь, правится все не через конфиги, а через ГУИ. Внутри то почти одно и тоже. Другое дело, что с использованием настройки через ГУИ ты зачастую не видишь внутренних закономерностей в работе продукта. А это грустно. Ладно, попробую этим заняться на досуге.

 

С другой стороны.. (дальше будут использоваться фрагменты различных статей).

Использование стандартного дистрибутива Linux, пусть даже хорошо известного администратору, имеет свои слабые стороны. В пакетных репозитариях сегодня редко встретишь полный набор необходимых программ (да еще и последних версий), а значит, все придется собирать, устанавливать и обновлять вручную. Это займет много времени и сил, ведь кроме системы, зависимостей, Asterisk и драйверов к оборудованию VoIP, придется разбираться с установкой веб-интерфейса, системы учета звонков и т.д. Специализированное решение не требует глубоких знаний (хотя они и приветствуются), – настройки просты и понятны любому, кто хорошо представляет конечный результат. Разработчики обычно сами следят за новинками ПО и предлагают обновления при помощи собственных репозитариев.

После анализа вариантов готовых решений был выбран Elastix (elastix.org). 

Asterisk. Требования к ресурсам.

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

Размер системы Asterisk на самом деле определяется не количеством пользователей или телефонных аппаратов, а, скорее, количеством одновременных вызовов, которые система должна будет поддерживать. Эти цифры очень приблизительны, поэтому экспериментируйте и выбирайте наиболее подходящий для себя вариант.