Синхронизация внешней системы с 1С

[andy]

Я думаю что автору нужен на оборот самый простой вариант.. а не подключение напрямую к СУБД и настройки планов обмена...
Самый простой вариант хотя наверное и не самый правильный это такой. Человека можно принять на работу только 2 способами в  1с. Это Договор на выполнения работ с физ лицом и стандартная это Прием на работу в организацию.. При создании этого документа и проведении, сделать процедуру, которая будет выгружать данные в любом удобном для вас виде хоть txt хоть xml хоть экскель хоть что.  и в любое удобное для вас место...и как угодно хоть на сайт хоть на сервер хоть куда.
Опять же подразделение(отдел) сотрудника можно изменить только "кадровым перемещением организации" (если организация правильно работает) опять же точно так же.. после создания документа и проведение, выгружать данные в файл и так же куда угодно и как угодно из записывать. И все это можно сделать непосредственно кодом 1с.
И ни какие подписки на события и проверки не нужны.

Думаю это самый простой вариант (но как я уже сказал, может и не самый правильный) средствами 1с после того или иного документа формировать файл с нужными данными и слать/отправлять/загружать его куда угодно.

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

[alex0402]

Если в 1С у меня несколько пользователей, у каждого из которых на личном компьютере установлен свой клиент 1С, то эту процедуру мне нужно проделать на каждом из клиентов, или все-таки эти изменения будут зафиксированы на сервере? Надеюсь из моих объяснений хоть что-то можно понять)

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

[Владимир Смирнов]

Я думаю что автору нужен на оборот самый простой вариант.. а не подключение напрямую к СУБД и настройки планов обмена...
Самый простой вариант хотя наверное и не самый правильный это такой. Человека можно принять на работу только 2 способами в  1с. Это Договор на выполнения работ с физ лицом и стандартная это Прием на работу в организацию.. При создании этого документа и проведении, сделать процедуру, которая будет выгружать данные в любом удобном для вас виде хоть txt хоть xml хоть экскель хоть что.  и в любое удобное для вас место...и как угодно хоть на сайт хоть на сервер хоть куда.
Опять же подразделение(отдел) сотрудника можно изменить только "кадровым перемещением организации" (если организация правильно работает) опять же точно так же.. после создания документа и проведение, выгружать данные в файл и так же куда угодно и как угодно из записывать. И все это можно сделать непосредственно кодом 1с.
И ни какие подписки на события и проверки не нужны.

Думаю это самый простой вариант (но как я уже сказал, может и не самый правильный) средствами 1с после того или иного документа формировать файл с нужными данными и слать/отправлять/загружать его куда угодно.

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

Ну это всего лишь 2 процедуры практически с одинаковым кодом, в двух модулях документов, по одной процедуре в каждом модуле документа Это минимальное изменение базы..
Можно пойти дальше, можно создать внешнюю обработку которая будет собирать нужные данные о сотрудниках и которая будет запускаться по регламентному заданию так часто как вам надо, хоть каждую минуту. Тогда вы вообще не коснетесь изменения конфигурации. А что бы она не выгружала в файл всех людей, а только новых. Ее (обработку) можно ограничить "текущейДатой" что бы она проверяла документы (прием на работу и кадровое перемещение) только каждый день сегодняшней датой. Вообще вариантов полно реализации, все зависит от компетентности человека который будет это делать, от объема компании (а точнее кол-во сотрудников и текучки кадров), от скорости как быстро должны данные из 1с попадать в другую программу (как только сотрудника приняли на работу, или это терпит до конца дня допустим) и тд и тп.

[alex0402]

(обработку) можно ограничить "текущейДатой" что бы она проверяла документы (прием на работу и кадровое перемещение) только каждый день сегодняшней датой.

а если документ будет введен "задним" числом, или исправлена ошибка, допущенная неделю назад?

[andy]

Ну это всего лишь 2 процедуры практически с одинаковым кодом, в двух модулях документов, по одной процедуре в каждом модуле документа Это минимальное изменение базы..
Можно пойти дальше, можно создать внешнюю обработку которая будет собирать нужные данные о сотрудниках и которая будет запускаться по регламентному заданию так часто как вам надо, хоть каждую минуту. Тогда вы вообще не коснетесь изменения конфигурации. А что бы она не выгружала в файл всех людей, а только новых. Ее (обработку) можно ограничить "текущейДатой" что бы она проверяла документы (прием на работу и кадровое перемещение) только каждый день сегодняшней датой. Вообще вариантов полно реализации, все зависит от компетентности человека который будет это делать, от объема компании (а точнее кол-во сотрудников и текучки кадров), от скорости как быстро должны данные из 1с попадать в другую программу (как только сотрудника приняли на работу, или это терпит до конца дня допустим) и тд и тп.

Компетентность человека, который будет это делать (то есть я) чуть больше, чем нулевая. Как я уже упоминал в самом первом сообщении - моя спецификация Web-разработка. Про 1С я не знаю вообще ничего, поэтому и обратился за помощью.
Внешняя обработка - это замечательно. Но мне понравился именно "План обмена", потому что он решает за меня следующие задачи:

1. Собираются именно изменившиеся данные, т.е мне не нужно вручную полностью проверять а какой же реквизит изменился у данного сотрудника, и нужен ли он мне вообще?
2. "План обмена" сам хранит все сообщения и удаляет их в случае получения соответствующего подтверждения о доставке на конечный узел;


Для использования внешней обработки мне не хватает этой самой компетенции, может Вы мне сможете помочь? На данный момент мне непонятно следующее (о чем-то я уже писал выше):

1. Вы говорите отслеживать изменения по "Документам", а я до сегодняшнего дня думал, что мне нужен справочник, например "СотрудникиОрганизации". То есть я просто подписался на событие "ПриЗаписи" для справочника "СотрудникиОрганизации", получаю измененный объект и далее что-то с ним делаю (в моём случае - конвертирую в формат XML). Дак все-таки как правильнее то? Если я должен отслеживать именно по "Документам", можете объяснить, почему так? Я не очень в теме

2. Допустим я разработал внешнюю обработку, которая функционирует по следующему алгоритму:

• Отслеживает изменения
• Формирует XML нужного вида
• Пытается отправить данные на внешний сервер

Если все хорошо и сервер нам сказал "200 OK", т.е данные им были получены, мы благополучно ожидаем следующие.
Если же сервер ответил некий иной код (т.е он сейчас недоступен и данные сохранить не может), то я вижу вот такое развитие событий:

• Сформированный XML сохраняется в некоторую внутреннюю БД в 1С (как вот это сделать? мне вообще непонятно)
• По Регламетному заданию в случае, если в данной БД есть неотправленные данные выполняется попытка повторной отправки

Вот такой вариант развития событий вообще возможен?

А да, еще такой вопрос: как вообще обрабатываются события в 1С? В том же потоке или отдельном? То есть если я подписался на событие "ПриЗаписи" и в обработчике выполняю отправку запроса на внешний сервер, что занимает некоторое время, с точки зрения пользователя 1С как это будет выглядеть? "Подвисание" формы? Или все-таки это в фоне будет происходить?

[alex0402]

Сформированный XML сохраняется в некоторую внутреннюю БД в 1С (как вот это сделать? мне вообще непонятно)

XML не сохраняет (это не нужно). Если данные зарегистрированы для отправки все данные будут формироваться в выгрузку до тех пор, пока не придет ответ (квитанция, обработается и только после этого удалится регистрация в плане обмена) или каким либо другим образом (кодом) удалится регистрация в плане обмена.

По Регламетному заданию в случае, если в данной БД есть неотправленные данные выполняется попытка повторной отправки

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

А да, еще такой вопрос: как вообще обрабатываются события в 1С? В том же потоке или отдельном? То есть если я подписался на событие "ПриЗаписи" и в обработчике выполняю отправку запроса на внешний сервер, что занимает некоторое время, с точки зрения пользователя 1С как это будет выглядеть? "Подвисание" формы? Или все-таки это в фоне будет происходить?

"ПриЗаписи" выполняется в том же потоке, т.е. - подвисание формы. Но можно запустить и фоновое задание (выполняется на сервере асинхронно).

[andy]

XML не сохраняет (это не нужно). Если данные зарегистрированы для отправки все данные будут формироваться в выгрузку до тех пор, пока не придет ответ (квитанция, обработается и только после этого удалится регистрация в плане обмена) или каким либо другим образом (кодом) удалится регистрация в плане обмена.

Мы тут с Вами немного о разных вещах говорим. Я имел в виду, что такой алгоритм будет применяться, если я буду использовать не "План обмена" а "Внешнюю обработку". С планом обмена то понятно, что он данные аккумулирует до тех пор, пока не получит уведомление об их успешной обработке принимающим узлом.