Есть ли в 1С стандартные триггеры на изменение объектов справочников?
Есть ли в 1С стандартные триггеры на изменение объектов справочников?
Поясню подробнее, что требуется. Необходимо событийное выплёвывание данных из 1С вовне (например, в xml файл). Создали элемент справочника номенклатура -> сгенерировался xml, содержащий информацию об этом элементе. Поменяли элемент справочника -> сгенерировался xml с информацией об этом элементе. Удалили элемент справочника - аналогично.
Как руками написать для каждого справочника - понятно. Но может быть есть стандартные механизмы, на БСП или на чём-то там ещё. Неважно в какой формат. Есть что-то стандартное в платформе для таких нужд?
Поясню подробнее, что требуется. Необходимо событийное выплёвывание данных из 1С вовне (например, в xml файл). Создали элемент справочника номенклатура -> сгенерировался xml, содержащий информацию об этом элементе. Поменяли элемент справочника -> сгенерировался xml с информацией об этом элементе. Удалили элемент справочника - аналогично.
Как руками написать для каждого справочника - понятно. Но может быть есть стандартные механизмы, на БСП или на чём-то там ещё. Неважно в какой формат. Есть что-то стандартное в платформе для таких нужд?
Найденные решения
(1) Триггеры есть - подписки на события. Но для целей именно обмена есть еще лучше - планы обмена. Про них лучше почитать, но главное в двух словах: настраиваешь состав плана обмена и по нему автоматически регистрируются в специальных табличках списки объектов, измененных с последнего сеанса обмена. Остается только читать эти списки, отдавать куда надо инфу об измененных объектах и чистить списки. Предусмотрена даже автоматическая чистка списков изменений по квитанциям успешных загрузкок (если обмен асинхронный).
ЗЫ. С физическим удалением лучше не связываться и не реализовывать для него хитрые кейсы. Лучше с пометкой на удаление работать. Тогда удаление будет частным случаем изменения.
ЗЫ. С физическим удалением лучше не связываться и не реализовывать для него хитрые кейсы. Лучше с пометкой на удаление работать. Тогда удаление будет частным случаем изменения.
(27) Да поймите вы уже, что синхронное действие по передаче данных о записываемом объекте в транзакции записи этого объекта в БД вызывает увеличение времени этой самой транзакции в разы, а то и на порядки.
Транзакция на изменение элемента в БД - самое "страшное" для производительности всей БД.
Пока у вас не настанет понимание этого факта в масштабах ВСЕЙ БД, вы будете упорно пытаться все делать синхронно: записали - передали в другую БД или любый другие варианты, подобные этому.
Транзакция на изменение элемента в БД - самое "страшное" для производительности всей БД.
Пока у вас не настанет понимание этого факта в масштабах ВСЕЙ БД, вы будете упорно пытаться все делать синхронно: записали - передали в другую БД или любый другие варианты, подобные этому.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Триггеры есть - подписки на события. Но для целей именно обмена есть еще лучше - планы обмена. Про них лучше почитать, но главное в двух словах: настраиваешь состав плана обмена и по нему автоматически регистрируются в специальных табличках списки объектов, измененных с последнего сеанса обмена. Остается только читать эти списки, отдавать куда надо инфу об измененных объектах и чистить списки. Предусмотрена даже автоматическая чистка списков изменений по квитанциям успешных загрузкок (если обмен асинхронный).
ЗЫ. С физическим удалением лучше не связываться и не реализовывать для него хитрые кейсы. Лучше с пометкой на удаление работать. Тогда удаление будет частным случаем изменения.
ЗЫ. С физическим удалением лучше не связываться и не реализовывать для него хитрые кейсы. Лучше с пометкой на удаление работать. Тогда удаление будет частным случаем изменения.
(20) Нет разницы. Событийное "выплевывание в файл" подразумевает периодический мониторинг появления этих файлов. Поэтому никакой принципиальной разницы нет. Можно периодически "выплевывать в файл", а можно периодически напрямую спрашивать у 1С "есть чо?"
При этом ведение списков изменений - транзакционное. И наличие списка измененных объектов гарантирует, что при сбоях выгрузки/загрузки информация об измененных объектах утеряна не будет.
При этом ведение списков изменений - транзакционное. И наличие списка измененных объектов гарантирует, что при сбоях выгрузки/загрузки информация об измененных объектах утеряна не будет.
Есть подписка на события, возможно это то что вам нужно?
Подписки на события 1С
Когда пользователь нажимает на ту или иную кнопку, открывается или закрывается форма, записывается документ – возникает событие.
Программист может назначить на событие обработчик – функцию написанную на встроенном языке 1С, которая выполнит определенные действия при возникновении события.
Иногда возникает необходимость назначить обработчик сразу на несколько или все документы.
Подписка на событие 1С позволяет назначить обработчик при наступлении события у любого нескольких объектов (справочников, документов).
Подписки на события 1С
Когда пользователь нажимает на ту или иную кнопку, открывается или закрывается форма, записывается документ – возникает событие.
Программист может назначить на событие обработчик – функцию написанную на встроенном языке 1С, которая выполнит определенные действия при возникновении события.
Иногда возникает необходимость назначить обработчик сразу на несколько или все документы.
Подписка на событие 1С позволяет назначить обработчик при наступлении события у любого нескольких объектов (справочников, документов).
Если будете самостоятельно клепать журнал регистрации в каталоге 1С,
Можете похоронить производительность 1С, особенно при выгрузке в XML/
Не берусь советовать, но есть такие дела, замеченные за франчайзингами 1с.
Любят они все журналировать подобным образом.
Я делал подобную штуку но выгружал текстом, и все равно очень неприятная тема.
Производительность падает документы подвисают.
Можете похоронить производительность 1С, особенно при выгрузке в XML/
Не берусь советовать, но есть такие дела, замеченные за франчайзингами 1с.
Любят они все журналировать подобным образом.
Я делал подобную штуку но выгружал текстом, и все равно очень неприятная тема.
Производительность падает документы подвисают.
(4) Нет это от того, что делал в 8.2 на обычных формах. Сразу после перехода с 8.1 в которой это было реализовано, но поговорить об этом можно. Можно даже привести пример автору реализации асинхронного кода.
Кстати, если скачаете мои обработки, там все в асинхронном режиме даже конструктор запросов вызывается.
Но думаю что автор сам решить когда и что ему делать.
Кстати, если скачаете мои обработки, там все в асинхронном режиме даже конструктор запросов вызывается.
Но думаю что автор сам решить когда и что ему делать.
(11) Что значит в 8.1 не было асинхронности? В 8.1 нельзя было где-то сохранить ссылку на измененный объект в пределах транзакции записи объекта в ИБ для последующей обработки этой самой ссылки?
Или что в вашем понимании асинхронность действий в данном случае?
Или что в вашем понимании асинхронность действий в данном случае?
(17) ээээ....Я веду речь про асинхронность ДЕЙСТВИЙ, а не про синхронность/асинхронность вызовов процедур/функций.
Синхронность/асинхронность вызовов процедур/функций вообще никаким боком к синхронности/асинхронности действий в пределах транзакции записи объекта в ИБ.
Синхронность/асинхронность вызовов процедур/функций вообще никаким боком к синхронности/асинхронности действий в пределах транзакции записи объекта в ИБ.
В вашем случае лучше завести план обмена с нужными объектами, подписками регистрировать объекты на узел этого плана обмена, а отдельным фоновым заданием обрабатывать объекты с этого узла, т.к. всякие внешние выгрузки в момент записи объекта - не очень красивый и быстрый вариант (будет тормозить запись, плюс нужно все исключения корректно обработать).
Хочу уточнить свои цели и озвучить выводы из вышесказанного.
1. Есть справочники которые создаются в одной системе (1С) и должны НЕМЕДЛЕННО попадать в другую (не 1с). Например, справочник "Номенклатура". При этом если что-то пошло не так (исключение), пусть лучше пользователь не сможет создать элемент, чем думает что всё ок, а в другой системе ничего не появилось. Для них подойдет подписка на события с генерацией xml файла
2. Есть справочники, которые должны отправляться в другую систему, но с допустимыми с лагами во времени. Например, ресурсные спецификации или ЭтапыПроизводства2_2. При этом важно, чтобы они корректно отработали в 1С и не застопорились даже при ошибке выгрузки. Для этого случая пойдёт план обмена.
Правильно мыслю?
1. Есть справочники которые создаются в одной системе (1С) и должны НЕМЕДЛЕННО попадать в другую (не 1с). Например, справочник "Номенклатура". При этом если что-то пошло не так (исключение), пусть лучше пользователь не сможет создать элемент, чем думает что всё ок, а в другой системе ничего не появилось. Для них подойдет подписка на события с генерацией xml файла
2. Есть справочники, которые должны отправляться в другую систему, но с допустимыми с лагами во времени. Например, ресурсные спецификации или ЭтапыПроизводства2_2. При этом важно, чтобы они корректно отработали в 1С и не застопорились даже при ошибке выгрузки. Для этого случая пойдёт план обмена.
Правильно мыслю?
(27) Да поймите вы уже, что синхронное действие по передаче данных о записываемом объекте в транзакции записи этого объекта в БД вызывает увеличение времени этой самой транзакции в разы, а то и на порядки.
Транзакция на изменение элемента в БД - самое "страшное" для производительности всей БД.
Пока у вас не настанет понимание этого факта в масштабах ВСЕЙ БД, вы будете упорно пытаться все делать синхронно: записали - передали в другую БД или любый другие варианты, подобные этому.
Транзакция на изменение элемента в БД - самое "страшное" для производительности всей БД.
Пока у вас не настанет понимание этого факта в масштабах ВСЕЙ БД, вы будете упорно пытаться все делать синхронно: записали - передали в другую БД или любый другие варианты, подобные этому.
(25) Если нужна такая тесная интеграция, чтобы две системы работали как единое целое (иногда такое нужно), то это делается на распределенных транзакциях. Можно сделать так, чтобы в конце транзакции записи 1С выполнялась попытка записи непосредственно в другую систему - обычно через http или напрямую в БД (не через файлики). И только если запись во вторую систему прошла успешно - завершать транзакцию записи 1С.
Но в этом случае и время записи увеличится и надежность упадет, так как при проблемах с каналом связи/драйверами или проблемах во второй системе работа в 1С станет колом.
ЗЫ. На практике такая тесная интеграция нужна очень редко. Потому что если достаточно раз в минуту подгребать изменения и не может быть такой ситуации, что вторая система должна иметь возможность отменить изменения в первой системе, то оптимально работать через очередь изменений.
Но в этом случае и время записи увеличится и надежность упадет, так как при проблемах с каналом связи/драйверами или проблемах во второй системе работа в 1С станет колом.
ЗЫ. На практике такая тесная интеграция нужна очень редко. Потому что если достаточно раз в минуту подгребать изменения и не может быть такой ситуации, что вторая система должна иметь возможность отменить изменения в первой системе, то оптимально работать через очередь изменений.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот