Итак, устанавливаем минимальный CentOS, настраиваем имена хостов, DNSы и сетевые подключения и приступаем собственно к установке серверных компонентов.
1. Установка Postgre SQL server
Обновление от 03-ноя-2016: в последних версиях CentOS (у меня сегодня был 7.2.1511) отсутствует поддержка libtermcap (и как-то "иначе" реализована libreadline), из-за чего сборки с сайта 1С не устанавливаются - решил поставить сборку от Postgres Professionals https://postgrespro.ru/products/1c_build - вроде работает, но о стабильности и производительности пока судить рано. Так что у кого проблемы с libtermcap.so.2() и/ли libreadline.so.5() при установке PostgreSQL с патчами 1С, можете попробовать этот альтернативный вариант.
Для установки использовался рекомендованный (адаптированный) 1С дистрибутив, для чего потребуется скачать его из раздела поддержки пользователей сайта 1С. В моём случае это был "Дистрибутив СУБД PostgreSQL для Linux x86 (64-bit) одним архивом (RPM)", который я сохранил в /root/temp. Распаковываем архив:
[root@vm-sql01 temp]# tar -vxf postgresql-9.2.1-1.1C_x86_64_rpm.tar.gz
Все недостающие зависимости (пакеты) будут установлены в процессе установки этих rpm, хотя на сайте 1С рекомендуют предварительно установить пакеты readline, libtermcap, krb5-libs и openssl, но в моём случае они либо уже были установлены, либо не были обнаружены в репозиториях.
2. Первый запуск Postgre SQL server
В отличии от сценариев установки большинства знакомых мне sql-серверов, postgres требует предварительной инициализации перед запуском, для чего существует два пути - первый, правильный:
[root@vm-sql01 pgsql]# su postgres -c '/usr/pgsql-9.2/bin/initdb -D /var/lib/pgsql/9.2/data --locale=ru_RU.UTF-8'
Файлы, относящиеся к этой СУБД, будут принадлежать пользователю "postgres".
От его имени также будет запускаться процесс сервера.
Кластер баз данных будет инициализирован с локалью "ru_RU.UTF-8".
Кодировка БД по умолчанию, выбранная в соответствии с настройками: "UTF8".
Выбрана конфигурация текстового поиска по умолчанию "russian".
исправление прав для существующего каталога /var/lib/pgsql/9.2/data... ок
создание подкаталогов... ок
выбирается значение max_connections... 100
выбирается значение shared_buffers... 32MB
создание конфигурационных файлов... ок
создание базы template1 в /var/lib/pgsql/9.2/data/base/1... ок
инициализация pg_authid... ок
инициализация зависимостей... ок
создание системных представлений... ок
загрузка описаний системных объектов... ок
создание правил сортировки... ок
создание преобразований... ок
создание словарей... ок
установка прав для встроенных объектов... ок
создание информационной схемы... ок
загрузка серверного языка PL/pgSQL... ок
очистка базы данных template1... ок
копирование template1 в template0... ок
копирование template1 в postgres... ок
ВНИМАНИЕ: используется проверка подлинности "trust" для локальных подключений.
Другой метод можно выбрать, отредактировав pg_hba.conf или используя ключи -A,
--auth-local или --auth-host при следующем выполнении initdb.
Готово. Теперь вы можете запустить сервер баз данных:
Или второй, более простой, но не всегда дающий необходимый результат (зависит от региональных настроек сервера, но у меня иногда приводивший к установке базы данных без поддержки необходимого collation ru_RU.UTF-8):
[root@vm-sql01 pgsql]# service postgresql-9.2 initdb
Инициализируется база данных: [ OK ]
[root@vm-sql01 pgsql]#
В результате была создана структура базы данных (с настройками) в /var/lib/pgsql/9.2/data. Хочу обратить особое внимание на конструкцию --locale=ru_RU.UTF-8, которую необходимо указать при инициализации, иначе сервер может быть инициализирован с неверным набором языковых параметров, что в конечном итоге приведёт к сообщениям
Ошибка установки или изменения национальных настроек информационной базы
Порядок сортировки не поддерживается базой данных
по причине:
Порядок сортировки не поддерживается базой данных
при установке информационной базы. Теперь можно настраивать автоматический запуск sql-сервера и, собственно, запускать его:
[root@vm-sql01 temp]# chkconfig postgresql-9.2 on
[root@vm-sql01 temp]# service postgresql-9.2 start
Запускается служба postgresql-9.2: [ OK ]
[root@vm-sql01 temp]#
Всё. Для локальных подключений сервер настроен. В моём случае сервер 1С и сервер SQL находятся на разных машинах, поэтому потребуется настроить и удалённые подключения с авторизацией.
В случае каких-то проблем, читаем содержимое файлов:
/var/lib/pgsql/9.2/pgstartup.log
/var/lib/pgsql/9.2/data/postgresql-*.log
Для повышения быстродействия документация PostgreSQL рекомендует как минимум унести журнал /var/lib/pgsql/9.2/data/pg_xlog на отдельный физический том и создать симлинк на него в исходном месте; из личных наблюдений - надо ещё и значительно увеличить размер используемой памяти... но необъятное не охватить, поэтому за статьями по оптимизации работы PostgreSQL для 1С предлагаю обращаться в поисковые системы, а оттуда - на профильные форумы.
3. Настройка пользователей (ролей) Postgre SQL server
Для управления PostgreSQL на начальном этапе потребуется сменить текущего пользователя на postgres и создать нового пользователя из командной строки:
[root@vm-sql01 temp]# su - postgres
-bash-4.1$ cd /usr/pgsql-9.2/bin
-bash-4.1$ createuser --interactive -P
Введите имя новой роли:server1c
Введите пароль для новой роли:
Повторите его:
Должна ли новая роль иметь полномочия суперпользователя? (y - да/n - нет) n
Новая роль должна иметь право создавать базы данных? (y - да/n - нет) y
Новая роль должна иметь право создавать другие роли? (y - да/n - нет) n
-bash-4.1$ exit
logout
[root@vm-sql01 temp]#
В принципе, для обслуживания полезно иметь пользователя с правами суперпользователя - создавать его можно тем же путём.
Теперь осталось разрешить удалённое подключение с авторизацией - для этого в файле /var/lib/pgsql/9.2/data/pg_hba.conf потребуется заменить значение ident на md5 в строке "host all all 0.0.0.0/0 md5" и перезапустить сервис.
Не следует забывать и про настройки iptables - для работы Postgre SQL необходимо открыть как минимум порт tcp 5432, хотя привычнее (да и проще) объявить сетевой интерфейс "внутренним" (разрешить все подключения на интерфейсе).
Для управления сервером потребуется pgAdmin, который можно установить из репозиториев используемого для административных целей линукса, либо скачать с сайта проекта.
4. Установка компонентов сервера 1С
Внимание!!! Для избежания проблем с зависимостями, желательно, чтобы разрядность сервера 1С совпадала с разрядностью используемого дистрибутива Linux! Иначе (если ставим 32-битный 1С на 64-битный Linux), при входе в базу, можно получить сообщение типа "Ошибка загрузки библиотеки libWand.so по причине:Библиотека не обнаружена. Часть функций будет недоступна." и клиенты не будут запускаться (хотя конфигуратор - будет). В принципе, я с этой проблемой справился на CentOS 7 (которой не выпускают больше в 32-битном исполнении) - просто поставил не только 'ImageMagick', но и 'ImageMagick.i686' (yum install ImageMagick.i686) - всё заработало (хоть и притянуло за собой гору зависимостей).
Первый шаг установки сервера 1С мало отличается от аналогичного этапа с SQL-сервером - распаковать скачанный дистрибутив сервера командой tar -vxf rpm64.tar.gz. В итоге получим файлы:
1C_Enterprise83-common-8.3.3-715.x86_64.rpm - основные файлы 1С (включая русский и английский интерфейсы)
1C_Enterprise83-common-nls-8.3.3-715.x86_64.rpm - дополнительные языковые модули
Настраиваем автоматический запуск демона и стартуем его:
[root@vh-1c83 temp]# chkconfig srv1cv83 on
[root@vh-1c83 temp]# service srv1cv83 start
Starting 1C:Enterprise 8.3 server: Error: service failed to start!
FAILED
[root@vh-1c83 temp]# service srv1cv83 start
Starting 1C:Enterprise 8.3 server: OK
[root@vh-1c83 temp]#
Хочу обратить внимание - если сразу после установки сервис (как в приведённом примере) не стартовал, а при второй попытке старта он запустился, скорее всего не настроен DNS - об этом чуть ниже. Если верить информации с многочисленных форумов, то наш сервер уже готов обслуживать до 12 клиентов. Для работы большего числа пользователей, необходимо установить лицензию сервера - либо в виде USB HASP и драйвера, либо в виде электронной лицензии. Про установку аппаратных ключей я уже писал, а установка программных лицензий достаточно проста: запускаем конфигуратор (с клиентской машины; кластер уже должен быть настроен и должна быть информационная база), вызываем "Сервис" - "Получение лицензии", вводим номер комплекта (с коробки или "Регистрационный номер" с карточки из конверта "Пинкоды программной лицензии") и пин-код (с той самой карточки из конверта), ставим галочку "Установка на сервер", вводим имя сервера в соответствующем поле, нажимаем "Далее", говорим, что это - "Первый запуск", заполняем форму "Владелец лицензии" (к стати, я не понял что писать в полях "Фамилия", "Имя", "Отчество" - то ли ответственного за эксплуатацию, то ли генерального директора - оставил поля пустыми, и оно получило лицензию, не ругнувшись), "Далее", "Автоматически" - профит! в /var/1C/licenses на сервере появился файлик XXXXXXXXXXXXXX.lic и серверу "стало хорошо" (если это была многопользовательская лицензия, то клиентам тоже "станет хорошо", т.к. они будут получать лицензии на сервере).
Для работы с графическими объектами и экспорта в xls, могут потребоваться дополнительные пакеты: ImageMagick, freetype (входит в зависимости ImageMagick), libgsf (входит в зависимости ImageMagick), corefonts (отсутствует в репозитариях CentOS - см. раздел 6); для "ТАКСИ" и "Управляемого приложения" они необходимы, для классического толстого клиента вроде бы не особо нужны, но 1С всё равно ругается на их отсутствие, хоть и работает.
По умолчанию сервер 1С слушает порт tcp 1541(1540) и для соединений использует диапазон портов 1560-1691.
5. Настройка экземпляра (кластера) сервера 1С
Информации о наличии оснастки управления сервером 1С для Linux мне не попадалось, так что для управления сервером будем использовать традиционную оснастку mmc для Windows "Администрирование серверов 1С:Предприятия", которую следует поставить из дистрибутива технологической платформы для Windows.
В этом месте на тестовом сервере возникли трудности - кластер по умолчанию отсутствовал, а при попытке создания нового кластера, ragent аварийно завершал работу с сообщением Sep 3 21:29:04 vh-1c83 kernel: ragent[1879]: segfault at 8 ip 00007f56473c9fd4 sp 00007f563b7b14a0 error 4 in rserver.so[7f56472db000+70e000]... странно, но если верить форумам, на CentOS у многих сервер 1С 8.3 ставится некорректно - не создаётся начальная конфигурация, включающая "Кластер по умолчанию". Краткий анализ ситуации выявил, что настройки кластера по умолчанию не были сгенерированы полностью и не попали в /home/usr1cv8/.1cv8/1C/1cv8/.
При попытке подложить файлы с рабочего сервера на неудачный, сервис 1С не запускается абсолютно без каких-либо диагностических сообщений - подобное поведение я видел при проблемах (неверных контекстах) SELinux, но в данном случае никаких отказов в audit.log не обнаружилось.
В результате детального изучения проблемы с применением strace удалось выяснить, что агент сервера при запуске ищет настройки по пути ~/.1cv8/1C/1cv8/ (в домашнем каталоге запустившего пользователя) и если не находит, пытается создать настройки кластера по умолчанию, для чего ему нужно имя хоста (выяснено экспериментально), и если верить "Руководству администратора", нужен корректно работающий DNS; экспериментально же был установлен факт, что сначала ragent читает файл /etc/hosts, затем обращается к DNS-серверу, а затем вызывает uname и снова лезет в hosts и к DNS и если не находит сопоставления, аварийно завершается. Итак, для нормального запуска потребуется полноценная и правильно настроенная сетевая инфраструктура, ну а в отсутствии работающего DNS достаточно дописать строчку в /etc/hosts и привести его примерно к такому виду:
За дальнейшими инструкциями пока отсылаю к своей статье про 8.2 - принципиальных отличий пока нет. Единственное замечание - при создании новой информационной базы, если указывать пользователя подключения к базе данных не с правами суперпользователя (а с набором прав из пункта 3), информационная база не создавалась, а в /var/lib/pgsql/9.2/data/pg_log/postgresql-Xxx.log наблюдались сообщения:
ОШИБКА: нет прав для изменения параметра "lc_messages"
ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
ОШИБКА: нет доступа к языку c
ОПЕРАТОР: CREATE OR REPLACE FUNCTION plpgsql_call_handler() RETURNS language_handler AS '$libdir/plpgsql' LANGUAGE C
ОШИБКА: нет прав для изменения параметра "lc_messages"
ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
ОШИБКА: ошибка синтаксиса (примерное положение: "application") в символе 24
ОПЕРАТОР: lock table pg_class in application share mode
ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
ОШИБКА: тип "mvarchar" не существует в символе 31
ОПЕРАТОР: create table Config (FileName mvarchar(128) not null, Creation timestamp not null, Modified timestamp not null, Attributes int not null, DataSize int8 not null, BinaryData bytea not null, PartNo int not null, PRIMARY KEY (FileName, PartNo))
ОШИБКА: нет прав для изменения параметра "lc_messages"
ОПЕРАТОР: SET lc_messages to 'en_US.UTF-8';
ОШИБКА: нет доступа к языку c
ОПЕРАТОР: CREATE OR REPLACE FUNCTION plpgsql_call_handler() RETURNS language_handler AS '$libdir/plpgsql' LANGUAGE C
После подключения с учётными данными суперпользователя БД, сообщения изменились на англоязычные и проблемы исчезли. Судя по всему, если на сервере установлен язык по умолчанию en_US, данного казуса не случится, но это - не проверенная информация, а лишь предположение, сделанное по прочтении чужой статьи про 8.1 и праздных раздумий =)
Ещё одна странность - если создать пустую SQL базу не из шаблона1 (см. официальную документацию по 1С), и попытаться ей указать на этапе создания ИБ, то всё равно получим сообщение "ОШИБКА: тип "mvarchar" не существует (символ 31)"/"ERROR: type "mvarchar" does not exist at character 31", но мне так и не удалось создать из требуемого шаблона БД - валились разные ошибки, но если пользователя sql, от которого создаётся ИБ временно повысить до суперпользователя с правом создания БД, и указать создание базы данных в случае её отсутствия, то всё получается в лучшем виде, так что на этапе первичной настройки, видимо, придётся повышать пользователя до супер...
Что порадовало - теперь в 1С можно работать непосредственно из Linux, что актуально для компаний, использующих его как основную ОС в корпоративной сети (я сейчас работаю как раз в такой компании); из неожиданностей - что при установке клиента 1С, он заявляет о зависимости от сервера и требует его установки, но потом ставится, прописывает значки запуска в "Офис" - "Финансы" и работает довольно сносно (по ощущениям - чуть менее комфортно, чем 8.2 под Windows, но заметно приятнее, чем тот же 8.2 через WINE от Ethersoft).
6. Установка недостающих зависимостей
При запуске клиента к настроенному по данной инструкции серверу, появится сообщение "На сервере отсутствуют шрифты из состава Microsoft Core Fonts. Внешний вид приложения может отличаться от ожидаемого. Процедура установки описана в справочной системе..." - данное сообщение появляется достаточно редко (периодичность не выявил, но появляется точно не единожды, но и не при каждом запуске), и на работе особо не сказывается, но "для красоты" я решил пройтись по всей цепочке и поставить рекомендуемые пакеты. Всё, кроме "corefonts" поставилось из репозиториев (хотя в той самой "справочной системе" безбожно перепутаны регистры в названиях пакетов, из-за чего их идентификация оказалась весьма развлекательна), ну а шрифты я решил пересобрать (в соответствии с рекомендациями из "справочной системы") и результат прикрепляю к статье - msttcorefonts-2.5-1.noarch.rpm, заодно и сами шрифты (уже переименованные в нижний регистр, как происходит при сборке rpm рекомендованным скриптом) - msttcorefonts.tar.gz - содержимое этого архива рекомендуют распаковать в /home/usr1cv8/.fonts (не забыв сменить владельца как на папку, так и на файлы!), если нет возможности установить предложенный .rpm
Кроме "ImageMagick" и шрифтов, для возможности сохранения в табличные файлы (кроме xls - его я пока не заставил формироваться, хотя xlsx формируется), на клиенте должны быть установлены пакеты "libMagickWand5", "libgomp1", "liblcms2-2" и "libbz2-1" - на ряде машин они отсутствовали. При чём той же разрядности, что и сервер 1С (см. п. 4).
7. Настройка аппаратного hasp для виртуализированного сервера 1С (работающего на виртуальной машине KVM)
Не планировал описывать эту процедуру, но раз уж столкнулся с такой ситуацией, опишу... Итак, на этот раз я использовал драйвер от "Alladin Knowledge Systems USB HASP", предоставляемый компанией Sentinel - мне попались две версии:
2878061 сен 11 2012 aksusbd-2.0-1.i386.rpm - с сайта aladdin-rd.ru
3009880 авг 6 16:35 aksusbd-2.2-1.i386.rpm - с сайта safenet-inc.com
Можно воспользоваться драйвером эзерсофт - окончательный выбор следует делать из опыта практической эксплуатации.
Наиболее правильная (на мой взгляд) последовательность действий:
а) убедиться, что на хост-машине драйвер HASP не установлен;
б) установить выбранный драйвер USB HASP4 на виртуальном сервере;
в) выяснить список подключенных USB-устройств к хост-машине
[root@vh01 files]# ls -R /dev/bus/usb
/dev/bus/usb:
001
002
003
004
/dev/bus/usb/001:
001
002
/dev/bus/usb/002:
001
/dev/bus/usb/003:
001
/dev/bus/usb/004:
001
[root@vh01 files]#
г) подключить USB-HASP к хост-машине и выяснить адрес ключа:
[root@vh01 files]# ls -R /dev/bus/usb
/dev/bus/usb:
001
002
003
004
/dev/bus/usb/001:
001
002
/dev/bus/usb/002:
001
/dev/bus/usb/003:
001
/dev/bus/usb/004:
001
002 <==== это наш ключ - раньше его не было
[root@vh01 files]#
д) используя любой из способов (я использовал Virtual Manager на удалённой машине) добавить "USB Host Device" с найденным адресом (в моём примере - 004:002) к виртуальной машине 1С - может потребоваться выключение и включение машины (я добавлял устройство на выключенную машину).
Собственно, всё - на CentOS 6.4 x64/i686 всё работает (были багрепорты про CentOS 6.0/6.1, но вроде всё починили). Если при запуске виртуалки выдаётся сообщение о занятости устройства, скорее всего подцепился драйвер на хост-машине (так писали на паре форумов, хотя мне эту ситуацию воспроизвести не получилось - даже с установленным драйвером на сервере устройство мапилось корректно). Естественно, если переставить ключ в другой порт USB, придётся перенацеливать и виртуальную машину!
/home/usr1cv8/.1cv8/1C/1cv8/1cv8wsrv.lst - файл, в котором хранятся основные свойства сервера - например, учётные данные администратора сервера, зарегистрированые кластеры и т.п.
/home/usr1cv8/.1cv8/1C/1cv8/reg_1541/1CV8Clst.lst - файл, в котором хранятся свойства кластера по умолчанию
/opt/1C/v8.3/x86_64/ - (вместо "x86_64" может быть "i386" - в зависимости от архитектуры системы) исполняемые файлы и сопутствующие ресурсы сервера (и клиента) 1С
/var/1C/licenses - здесь лежат файлы электронных ключей лицензий
8. Настройка локального репозитория 1С для удобства обновления платформы
В процессе эксплуатации 1С нередко приходится обновлять платформу. Если всё установлено по приведённой выше инструкции, это вызывает определённые неудобства - надо останавливать сервис, удалять старые пакеты, ставить новые... не знаю - мне это ещё в винде надоело смертельно. Linux предлагает очень удобный механизм пакетного обновления из локального репозитория - всё, что нужно - это выбрать место, где будут лежать обновки: для одиночного сервера, к которому все ходят только через web-интерфейс, это может быть /root/repo (всё равно обновление под рутом идёт), ну а в общем случае - хоть /var/www/1c-repo - главное, чтобы все, кому он нужен, его видели. Далее надо установить пакет 'createrepo' (yum install createrepo) - за собой он притащит немало зависимостей, но не смертельно. Теперь командой 'createrepo /root/repo' (где "/root/repo" - выбранный путь хранения репозитория) создаём его "описание" и можно пользоваться.
Затем создаём файл описания нашего репозитория и помещаем его в каталог описаний репозиториев (для CentOS это /etc/yum.repos.d). Пример конфига локального файлового репозитария:
[root@1c yum.repos.d]# cat local-1c.repo
[local-1c]
name=1C Enterprise
#baseurl=http://inhost.firm.lan/repo
baseurl=file:///root/repo
gpgcheck=0
enabled=1
По-моему, разъяснять что за что отвечает, особого смысла нет. Единственное, что важно - сразу yum его может не увидеть - в этой ситуации поможет очистка его кэшей (yum clean all).
Всё. Теперь если надо обновиться, то помещаем новые файлы дистрибутива 1С рядом со старыми, повторяем 'createrepo /root/repo' вызываем 'yum update' - и всё - платформа пошла обновляться! Естественно, за сохранностью и защищённостью своего репозитория надо следить, так как GPG у нас выключен, и это всё же дыра в безопасности, хоть и не особо толстая...
Разработчики в управляемых приложениях применили новый механизм настройки прав доступа, о которых и пойдет речь.
Будут перечислены все те грабли, которые собрал автор, чтобы вы о них знали.
Наверняка, уже все знают, что из себя представляет новая система, поэтому предистория вкрадце:
Как было раньше( в обычном приложении):
Есть документ. Есть Роли - ПолныеПрава, ДокументНетДоступа, ДокументТолькоЧтение, ДокументЧтениеИРедактирование. В конфигураторе(аналогичный механизм в реж предприятия) вы выставляете пользователям эти роли и у них появляются соответствующие права доступа на документ. Все просто и скучно и даже зевать хочется.
С введением управляемого приложения разработчики решили усложнить(читается как расширить) настройки прав доступа.
Теперь:
Вводная та же. Чтобы дать пользователю какие-то права на документ - сначала вам необходимо создать элемент справочника Профили групп доступа. Это некий агрегирующий(суммирующий значения) объект, который объединяет роли в группы ролей. Теоритически таких профилей можно создать сколько угодно много с различным набором ролей( N*(n-1), где N - количество ролей), но на практике количество профилей определяется количеством должностных обязанностей пользователей в организации и их гораздо меньше, чем ролей.
Чтобы "привязать" эти профили к пользователям - нужно создать элементы справочника ГруппыДоступа. В типовых они создаются автоматически, когда вы отмечаете галочками профили для пользователя. Этот справочник соединяет профиль и пользователя(или нескольких пользователей).
При записи этого элемента справочника система автоматически добавляет роли (из профиля) в роли пользователя. Поэтому не стоит напрямую редактировать роли в конфигураторе, как раньше - при редактировании прав в Предприятии все роли в конфигураторе будут обновлены на роли из профилей пользователя. Кроме того, будет наблюдаться явное противоречение между набором профилей с ролями и ролями, установленными в конфигураторе.
Как хранятся роли в Профиле групп доступа, спросите вы. Ведь роли - это объекты МД, это не ссылочные типы. Отвечаю - для этого(и не только) разработчики создали служебный справочник ИдентификаторыОбъектовМетаданных, в котором хранится( в иерархии!) имена, синонимы, значения пустых ссылок всех объектов МД. Если вы хотите создать Профиль программно и добавить в него роль, то код примерно будет таким:
Но если мы добавили новую роль в конфигурации, то как она попадет в справочник? Хороший вопрос. У справочника ИдентификаторыОбъектовМетаданных есть метод, позволяющий обновлять его данные. это:
Процедуру следует запускать каждый раз, когда вы вносите изменения в метаданные, особенно когда изменяете роли, объекты, связанные с новыми ролями.
Отлично. Роль добавили, идентификаторы обновили.
Но обратная связь не работает - вы в режиме предприятия назначили пользователю профиль( с созданием группы доступа), а роль у пользователя в конфигураторе не добавилась! Что делать?
За синхронизацию ролей/профилей отвечает константа ПараметрыРаботыПользователей. Если роли не обновляются в конфигураторе, следует обновить её значение:
Хорошо, скажите вы. А как быть, если я хочу создать группы доступа программно? Да не вопрос. Единственное ограничение - не допускаются дубли связок Профиль-Пользоваль в группах доступа. Примерный код будет таким:
После выполнения этого кода, если все, что нужно обновлено - типовая конфигурация добавит пользователю роли.
Раз уж пошли по программному пути, вот код, который добавляет пользователя в справочник Пользователи и ПользователяИБ в ПользователиИнформационнойБазы:
Если вы добавляете не программно, то добавлять нужно из режима Предприятия - тогда пользовательИБ у вас сам создатся.
И если раньше, в обычном приложении, достаточно будет добавить польз в конфигураторе - и при заходе в Предприятие, этот польз сам создавался в спр Пользователи, то с управляемым приложением такой фокус не прокатит - система не даст зайти под пользователемИБ, которого нет в справочнике Пользователи.
Все чаще и чаще встречаются обмены, используя технологию Web-Сервисов. Это удобно, т.к для хостовой базы данных достаточно установить расширение Web-Сервиса и обработчик данных, а для клинтского решения подключиться к Web-Сервису. Технология является мультиплатформенной и на данный момент ее использование весьма актуально.
Примерами таких веб-сервисов можно назвать:
http://www.cbr.ru/scripts/Root.asp?Prtid=DWS веб-сервис Центробанка, для получения ежедневных данных.
http://api.yandex.ru/speller/doc/dg/concepts/api-overview.xml веб-сервис Яндекса проверки правописания.
https://www.flightstats.com/developers/bin/view/Web+Services/WSDL ряд веб сервисов авиастатистики, для мониторинга полетов, сведений о погоде, и.т.п.
WSDL (Web Services Description Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML. (спецификация http://www.w3.org/TR/wsdl).
SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределенной вычислительной среде. SOAP используется для обмена произвольными сообщениями в формате XML и удалённого вызова процедур (RPC). (спецификация http://www.w3.org/TR/soap/).
XDTO (XML Data Transfer Objects) — механизм объектного моделирования данных, описываемых с помощью схемы XML (подробнее http://v8.1c.ru/overview/xdto.htm).
Большинство примитивных типов сериализованных объектов разработана компание W3 и их описание находится в пространстве имен «http://www.w3.org/2001/XMLSchema».
 
и так: Задание 1: Установка платформы 1С: Предприятие, установка компоненты IIS сервера, связь Web-Расширения 1С с сервером IIS.
При установке платформы 1С: Предприятие необходимо установить Web-Расширение.
Рис. 1. Выбранные компоненты в момент установки 1С
В меню «Панель управленияВсе элементы панели управленияПрограммы и компоненты» Необходимо выполнить установку дополнительных компонентов Windows «Включение или отключение компонентов Windows» где указать все компоненты IIS (за исключением FTP, для текущей работы он не требуется). После установки рекомендуется перезапустить операционную систему.
Рис. 2. Выбранные компоненты в момент установки IIS
В меню «Панель управленияВсе элементы панели управленияАдминистрирование» запустить консоль «Диспетчер служб IIS», где открыть элемент «Пулы приложений» открыть пул «DefaultAppPool» в контекстном меню выбрать «Дополнительные параметры…» где элемент «Разрешены 32-рязрядные приложения» надо установить «True». Это необходимо для работы Web-Расширения 1С, т.к. оно является 32-битным прилодением.
В той же консоли «Диспетчер служб IIS», выбрать элемент «Default Web Site», выбрать действие «Проверка подлинности» где необходимо включить варианты: «Анонимная проверка подлинности», «Обычная проверка подлинности», «Проверка подлинности Windows».
Теперь возможна публикация Web-Сервисов 1С на сервере IIS. Но для того, чтобы было возможно выполнить эту публикацию, необходимо запустить Конфигуратор 1С: Предприятия от имени пользователя «Администратор».
Задание 2: Создание простой конфигурации 1С.
Считаем, что в базе данных есть информация информации обо всех заказах, содержащая количество и тип номенклатуры, который был заказан, в одном заказе может быть список, содержащий номенклатуру и количество, заказ так же имеет свой номер и дату его создания. Информацию обо всех заказах надо передать через Web-Сервис.
Для описания этого необходимо создать объекты базы данных:
Рис. 3. Структура данных в созданной конфигурации 1С
Справочник «Номенклатура», без дополнительных реквизитов. В реквизитах «по умолчанию» содержится информацию о наименовании и коде номенклатуры.
Документ «Заказ покупателя», который будет содержать табличную часть «Товары», каждая строка которой будет иметь информацию о номенклатуры (элемент типа «СправочникСсылка.Номенклатура») и количестве (элемент «Количество» типа «Число» беззнаковое с 15 знаками до запятой и 3 после).
Далее можно запустить 1С в режиме предприятия и создать несколько документов, заполненных созданными нами же номенклатурами и соответствующим количеством.
Задание 3: Создание и публикация Веб-Сервиса 1С.
В группировке «Общие» конфигурации создать новый элемент типа «XDTO-пакеты», первоначально для передачи номенклатуры. Его можно назвать, например «NomenclatureXDTO». URL пространство имен, в соответствии со спецификацией WSDL необходимо назначить в виде URL адреса спецификации данного пакета, например
«company.com/1C/Nomenclature». В этом пакете необходимо создать тип объекта, например «Nomenclature», в котором есть реквизиты «Code» и «Name», с соответствующим типом «string (http://www.w3.org/2001/XMLSchema)».
Теперь надо создать второй XDTO пакет, который будет содержать информацию о заказах покупателей, его можно назвать «ClientOrderXDTO» в пространсте имен «company.com/1C/ClientOrder». В первую очередь необходимо подключить директиву импорта «company.com/1C/Nomenclature», для того, чтобы можно было использовать созданный нами пакет сериализации номенклатуры. Это необходимо для передачи номенклатуры, содержащейся в табличной части документа «Заказы покупателей».
Теперь надо создать тип объекта «ClientOrderRow», содержащий одну строку табличной части. Этот тип будет состоять из совокупности реквизитов «Nomenclature» и «Count», соответственно для номенклатуры необходимо указать тип объекта «Nomenclature (http://company.com/1C/Nomenclature)», а для количества, «double (http://www.w3.org/2001/XMLSchema)».
Тип объекта, содержащий сам заказ можно назвать «ClientOrder» должен содержать номер заказа, дату создания и массив элементов из табличной части заказа. «Number» типа строка, «Date» типа «dateTime (http://www.w3.org/2001/XMLSchema)» и «Products» типа «ClientOrderRow (http://company.com/1C/ClientOrder)», при этом необходимо указать, что минимальное количество «0», а максимальное количество «-1», это говорит о том, что этот объект будет массивом.
Но, поскольку необходимо возвращить список заказов, то необходимо создать тип объекта, содержащий этот массив, потому надо создать еще один элемент, называемый «ArrayOfClientOrders», у которого будет всего один реквизит, называемый «ClientOrder» типа «ClientOrder (http://company.com/1C/ClientOrder)».
Рис 4. Структуры XDTO пакетов в 1С
На этом создание описания передаваемых значений можно считать оконченным. Необходимо описать сам веб сервис и его методы.
В группировке «Общие» конфигурации надо создать объект, Web-Сервиса. Его можно назвать «Service». Во вкладке «Прочее» надо указать пространство имен, которому принадлежит веб-сервис, например «company.com/1C», а так же список XDTO пакетов, содержащий только что созданные пакеты «company.com/1C/Nomenclature, company.com/1C/ClientOrder». Во вкладке «Операции» создать метод «GetClientOrders», который будет возвращать значения «ArrayOfClientOrders (http://company.com/1C/ClientOrder )», при этом установить возможность возвращать пустые значения и нажать на поле с лупой, называемое «Имя метода», тем самым в модуле веб-сервиса будет создана функция, который будет вызвана при обращении к данному методу веб-сервиса.
Для того, чтобы корректно описать функцию, получающую из базы данных и возвращающую список заказов покупателей, необходимо знать внутренний язык 1С, потому код этой функции находится в приложении 1. В пояснении нуждается то, что «ФабрикаXDTO», это некоторый менеджер, который выполняет сериализацию объектов, и этот сериализованный объект необходимо возвратить. При этом происходит выборка всех заказов, содержащихся в базе данных, сериализация полей номера, даты, и строк табличной части, при этом номенклатура, нуждается в дополнительной сериализации, и уже упакованный объект вставляется в общую структуру. Собирается массив упакованных объектов, сериализуется в пакет массива. И отправляется клиенту, как результат вызванной функции.
Для публикации веб-сервиса в меню конфигуратора 1С выбрать «АдминистрированиеПубликация на веб-сервере…», после чего указать название публикации веб-сервиса, например «Company», имя сервиса, например «Service» и адрес «service.1cws», а так же указать путь для публикации, например «C:\inetpub\www\root\Company».
После этого WSDL структура Web-Сервиса будет доступна по адресу «localhost/Company/ws/service.1cws?wsdl»
Задание 4: Создание клиента на C# платформы .NET 4.0.
В Visual Studio создать новое консольное приложение C#.
Далее вызвать контекстное меню над элементом проекта «Reference», и выполнить действие «Add service reference…», в открывшемся меню нажать на кнопку «Advanced…», откроется окно, где необходимо нажать на кнопку «Add Web Reference…».
Откроется меню, в которое необходимо вставить ссылку на WSDL описание веб-сервиса. Рис. 5. Подключение веб-сервиса к проекту на C#
Для созданного в 1С веб-сервиса эта ссылка будет иметь вид «localhost/Company/ws/service.1cws?wsdl», после корректного получения описания веб-сервиса надо указать название пространства имен .NET, из под которого будет доступно обращение к веб-сервису, например «CompanyService», затем нажать на кнопку «Add Reference…», Visual Studio автоматически сгенерирует классы по этому описанию. В проекте достаточно будет вызывать методы сгенерированного класса, при этом сериализация и вызов будут выполнять платформой .NET.
Далее необходимо написать программу, которая будет обращаться к веб сервису, и выводить пользователю полученные данные. Для этого необходимо знать язык C#, код программы представлен в приложении 2. Из этого кода надо пояснить, то, что создание объекта «Service», есть не что иное, как создание менеджера обращения к сервису. От этого имени будут вызывать методы веб-сервиса.
«_1CWebServiceClientConsole» — это общее пространство имени проекта, оно выбирается при создании. Пространство имени веб-сервиса, полученное из WSDL структуры полностью включено в пространство имени проекта, что позволяет вызывать удаленные методы «как свои».
Построение такой архитектуры является прозрачной для программистов, но при этом необходимо понимать в какие моменты и что проходит сериализацию для последующей передачи. Подобная архитектура клиент-серверных приложений на данный момент самая популярная.
Приложение 1: код функции GetClientOrders на языке 1С
Приложение 2: код программы на C# осуществляющий обращение к веб-сервису
Для ручной регистрации изменений можно в модуле объекта (документа) определить следующий обработчик события
В глобальном общем модуле определим следующую процедуру:
Обе рассмотренные процедуры одновременно решают две задачи:
Регистрируют изменения для узла, у которого реквизит Склад совпадает со складом, указанным в документе.
Производят проверку (для ранее существовавших документов), не изменился ли склад.
Если склад изменился, то производится регистрация изменения для узла, значение реквизита Склад которого соответствует старому значению документа (хранимому на момент проверки в информационной базе). Далее в момент выгрузки изменений данная регистрация может быть «подменена» на объект УдалениеОбъекта, что приведет к удалению накладной, «не свойственной» узлу.
В этом материале подробная инструкция по настройке обмена РИБ для 1С:Предприятие 8 и проблемы, с которыми столкнулся автор.
1. Создание узлов
Создаем новые узлы (главный и подчиненный): в пользовательском режиме "Операции / Планы обмена/Полный" Выберем план обмена "Полный"
Создаем две записи:
- первую запись назовем "ЦБ" (главный узел), код укажем "ЦБ",
- вторую запись назовем "Подчиненный узел", код укажем "ПУ". Значек с зеленным кружком - "ЦБ" (главный узел)
Для подчиненного узла нажимаем на иконку "Создать начальный образ". (Потребуется монопольный доступ) Создать начальный образ
Далее в открывшемся окне заполняем параметры новой базы. По окончании нажимаем кнопку "Готово" Создание начального образа ИБ
Начнется создание начального образа подчиненного узла распределенной информационной базы, по окончании появится сообщение "Создание начального образа успешно завершено". Жмем кнопку "ОК".
Добавляем базу подчиненного узла в список баз, запускаем ее.
В этой подчиненной базе открываем полный план обмена - значок "ЦБ красный, это значит, что этот узел является главным для информационно базы, в которой мы находимся.
2. Настройка префиксов
Для каждой базы, в настройках параметров учета (в УПП "Сервис / Параметры учета") на закладке "Обмен данными", устанавливаем префиксы. Это делается для того чтобы не возникало конфликтов в номерах и кодах документов и справочников, созданных в двух базах.
Для автообмена, устанавливаем галочку "Использовать механизм автоматического обмена..." Закладка "Обмен данными"
3. Добавляем настройку обмена данными между узлами
Открываем: "Сервис \Распределенная информационная база (РИБ)\Настроить узлы РИБ"
Нажимаем "Добавить", откроется окно "Настройка обмена данными" Настройка обмена данными
Нажимаем на значок "Выполнить обмен по текущей настройке" Выполнить обмен по текущей настройке
Теперь о "подводных камнях"
1. Обмен данными может выполняться в автоматическом режиме и может быть инициализирован в следующих случаях:
* При запуске программы. Обмен будет выполняться при запуске программы,
* При завершении работы с программой. Обмен будет выполняться перед завершением пользователем работы с программой,
* При появлении каталога. Обмен будет выполнен только в том случае, если каталог указанный пользователем был невиден, а в настоящий момент стал виден. Настройка может быть использована для выполнения автоматического обмена при подключении к локальной сети или flash карты. Программа периодически будет проверять видимость указанного в настройках каталога и отмечать его текущее состояние,
* При появлении файла. Рекомендуется использовать данные режим, когда нужно выполнить обмен, если появляется входящий файл обмена данными. В этом случае, достаточно указать полный путь к входящему файлу обмена данными. Программа периодически анализирует наличие файла, и как только он появится, будет выполнен обмен, а после обмена этот файл будет принудительно УДАЛЕН (это делается для того, что бы процедура обмена не выполнялась постоянно),
* Периодический обмен данными. Обмен будет выполняться согласно настройкам периодического обмена данными. Если информационная база работает в файл-серверном режиме, то периодический обмен выполняется только у пользователя, который указан в параметрах учетной политики как "Пользователь для регламентных заданий в файловом режиме". В Клиент-серверном варианте обмен выполняется на сервере 1C:Предприятия.
У меня Клиент-серверный вариант - для работы регламентного автообмена пришлось перегружать сервер
2. Кодировка Windows.
Обмен прерывался ошибкой - так как не происходит сжатие файла. Это из-за ошибки кириллицы в командной строке при сжатии.
Лечится исправлением кодировок в реестре.
Например, для Windows Server 2008 -
3. Создавая копию базы (например, для доработки) в клиент-серверном варианте, НЕОБХОДИМО, чтобы РЕГЛАМЕНТНЫЕ ЗАДАНИЯ КОПИИ базы были ВЫКЛЮЧЕНЫ. Блокировка регламентных заданий для копии ВКЛ
Если их не заблокировать, то копия будет делать обмены по тому же расписанию, что и основная база. Значит, часть сообщений в удаленные узлы будет формироваться из рабочей базы, а часть из копии, что приведет рассинхронизации конфигураций. Источник
В 1С 8.х
В процессе длительной эксплуатации системы в журнале регистрации может накапливаться значительное число записей. Поэтому поддерживается возможность сокращения журнала регистрации и удаления записей, ставших неактуальными. При сокращении журнала регистрации можно записать удаляемые события в файл, если предвидится необходимость их анализа в будущем. В конфигураторе, в меню «Администрирование – Настройка журнала регистрации…» кнопкой «Сократить» – установив текущую дату. Там же можно сохранить журнал в файл.
В поле Текущий диапазон событий, указывается диапазон времени за который есть данные. Удалить события до – здесь указываем до какой даты можно удалить данные.
Удаляемые данные можно сохранить, для этого установим свойство “Записать удаляемые события в файл” и укажем папку в которую сохраним.
Если требуется периодически сокращать журнал и при этом иметь возможность просматривать уже удаленные события журнала, то установите флажок “Сохранять разделение хранения журнала по периодам и объединять с сохраненным ранее журналом“.
Используя средства работы со списками, разработчик имеет возможность выгрузить журнал регистрации в текстовый или табличный документ, который в дальнейшем может быть сохранен в собственном формате или, например, формате листа Excel или документа HTML.
Кроме этого поддерживается выгрузка журнала регистрации в формате XML, что может использоваться для последующего анализа выгруженных записей средствами встроенного языка.
Особенности функционирования журнала регистрации
При создании новой информационной базы для журнала устанавливается режим регистрации событий всех уровней важности; включение и выключение журнала регистрации. При загрузке информационной базы из файла журнал регистрации не очищается.
Если временных таблиц много и они висят в памяти не удаленные не очищенные возникает эффект постоянной загруженности сервера 1С:Предприятие как будто этот процесс выполняет все время какой то тяжелый запрос или обработку что сказывается на производительности системы в целом. Временную таблицу нужно удалять как можно скорее после использования.
Механизм распределенных информационных баз предназначен для создания территориально распределенных систем на основе идентичных конфигураций 1С:Предприятия 8. Этот механизм позволяет переносить как данные 1С: Предприятия, так и изменения конфигурации информационной базы.
В тех случаях, когда предприятие представляет собой территориально распределенную структуру, зачастую сохраняется потребность в ведении единой системы учета. То есть необходимо иметь возможность работать в едином пространстве документов, получать отчеты, отражающие состояние дел как в территориально удаленных подразделениях предприятия, так и на предприятии в целом и т.п. При этом не всегда имеется возможность организовать работу всех подразделений с единой информационной базой в режиме он-лайн.
Для решения подобных задач и предназначен встроенный механизм. Распределенная система в этом случае должна иметь древовидную структуру, в которой существует корневой узел и определено отношение "главный - подчиненный" для каждой пары связанных узлов. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.
Обмен измененных объектов данных между каждым связанным узлом выполняется в формате ХML файлов. Перенос данных непосредственно между периферийными ИБ невозможен. Поэтому изменения данных, произведенные в одном из периферийных узлов распределенной ИБ попадают в другие периферийные узлы только через центральную ИБ.
В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.
Внесение изменений в конфигурацию возможно только в одном (корневом) узле распределенной системы. Изменения конфигурации передаются от главного узла к подчиненным.
Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.
Для того, чтобы документы, элементы справочников и другие объекты, созданные в разных узлах распределенной ИБ можно было различать, если это необходимо, в настройках программы можно указать префикс узла распределенной базы. В этом случае в при создании нового объекта (к примеру документа) будет автоматически добавляться указанный префикс.
В основе механизма распределенных информационных баз лежат универсальные механизмы обмена данными, такие как служба регистрации изменений, инфраструктура сообщений, XML-сериализация и чтение/запись XML-документов. Однако механизм распределенных информационных баз содержит ряд специфических возможностей, недоступных через универсальные механизмы обмена данными.
К таким возможностям относится интерактивное создание начального образа информационной базы, а также интерактивное чтение и запись изменений, которые могут быть выполнены сразу же, после указания того, что данный план обмена будет использовать механизм распределенных информационных баз. Таким образом, распределенная информационная база может быть создана без какого-либо дополнительного программирования, исключительно средствами визуального конструирования. При этом обмен в распределенной информационной базе будет осуществляться на основе некоторых алгоритмов, изначально заложенных в платформе.
Все действия, выполняемые при интерактивном обмене, могут быть продублированы программно, и кроме этого разработчик имеет возможность программно управлять принятием и отправкой изменений, а также выполнять реструктуризацию распределенной информационной базы, добавляя новые и удаляя существующие узлы.
Служба регистрации изменений
Суть регистрации изменений состоит в том, чтобы иметь перечень измененных элементов данных которые должны быть переданы в очередном сообщении тому или иному узлу, с которым производится обмен данными. При каждом изменении данных регистрируется, что имеются изменения, которые предстоит передать во все узлы, с которыми поддерживается обмен этими данными. При получении подтверждения приема сообщения, в котором были отправлены изменения, записи регистрации изменений должны быть удалены.
Состав данных, которыми осуществляется обмен, описывается в Плане обмена и представляет собой перечень элементов данных.
Для каждого элемента данных, указанного в плане обмена, ведется своя таблица регистрации изменений. Таблицы имеют разную структуру, в зависимости от того, для каких элементов данных регистрируются изменения, но все-таки структуры таблиц подобны. Каждая запись указывает на некоторый элемент данных, некоторый узел и содержит номер сообщения, в котором это изменение передано в первый раз.
При описании состава данных в плане обмена, для каждого элемента данных есть возможность указать признак Авторегистрации. Авторегистрацию можно «Разрешить» или «Запретить». Если авторегистрация разрешена, то при изменении данных регистрация изменений будет выполнена автоматически. Если запрещена, то регистрацию изменения можно выполнить «вручную», средствами встроенного языка.
Инфраструктура сообщений
С точки зрения плана обмена, между узлами происходит обмен сообщениями. Каждое сообщение содержит изменения данных, изменения конфигурации (если это распределенная информационная база) и ряд служебной информации. Каждое сообщение точно ассоциировано с планом обмена, имеет уникальный номер и имеет одного отправителя и одного получателя.
Сообщение оформляется как документ XML, имеющий определенную структуру. Инфраструктура сообщений позволяет формировать нужную структуру сообщения, и контролировать ее корректность. В частности, инфраструктура сообщений поддерживает нумерацию сообщений, и позволяет получать подтверждения от узла-получателя о приеме сообщений. Такое подтверждение содержится в каждом сообщении, приходящем от узла-получателя в виде номера последнего принятого сообщения.
Коллизии
При работе в реальных распределенных ИБ один и тот же объект может изменяться одновременно в различных узлах распределенной ИБ. И при переносе измененных объектов из одной ИБ в другую может случиться так, что в какую-либо ИБ будет загружаться объект, зарегистрированный в самой этой ИБ как измененный. Такая ситуация носит название коллизии.
Приведем описание действий системы в наиболее типовых вариантах коллизий: Один и тот же объект изменен более чем в одной ИБ.
Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются. Объект, измененный в одной ИБ, удален в другой.
В данном случае принцип заключается в том, что изменение всегда "главнее" удаления. В случае, если на центральную ИБ прибывает файл переноса, в котором содержится информация, что некоторый объект удален на периферийной ИБ, то в центральной ИБ объект не удаляется, а в записи таблицы регистрации изменений данный объект помечается как измененный. То есть при очередном обмене объект будет восстановлен в той ИБ, в которой он был удален, причем само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ. Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.
При загрузке изменений, если загружается информация об удалении объектов, автоматически включается механизм контроля ссылочной целостности и выполняется проверка наличия ссылок в данной ИБ на объекты, которые переданы как удаленные.
В случае обнаружения коллизии такого рода, вне зависимости от того на какой из ИБ она была обнаружена, выполняется следующее: удаление не выполняется, а в таблицу регистрации изменений заносится запись о том, что объект должен быть перенесен в адрес той ИБ, из которой была прислана информация о его удалении.
При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Таким образом на сегодняшний день платформа 1С:Предприятие предоставляет очень удобный механизм, использование которого относительно просто и не требуется никаких навыков в программировании, а благодаря механизму автоматического обмена от пользователя даже не требуется думать об актуальности его распределенной информационной базы.
1С выдает предупреждение "Файл данных достиг максимального размера".
Подскажите из - за чего это и как можно решить ?
Превышен размер файла, обычно это сообщение возникает, когда размер файла 1Cv8.1CD приближается к 10 гигабайтам или размер какой-то таблицы в файле приближается к 4 гигабайтам.
Что можно сделать?
Необходимо:
Нужно уменьшить базу за счет удаления данных и потом в конфигураторе выполнить Администрирование -> Тестирование и исправление - > Сжатие таблиц информационной базы
(файловая версия 1С 8 при удалении данных в режиме Предприятия, не удаляет данные со своих страниц БД, а помечает потоки как удаленные и сжатие БД нужно делать регулярно для очистки таких данных)
Если не поможет, то значит пора уже базу перевести, на SQL вариант!
Установка сервера 1С 8.3 и PostgreSQL 9.2 на CentOS 
