1. mistermp3 21.10.19 11:50 Сейчас в теме

Есть ли в 1С стандартные триггеры на изменение объектов справочников?

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

Как руками написать для каждого справочника - понятно. Но может быть есть стандартные механизмы, на БСП или на чём-то там ещё. Неважно в какой формат. Есть что-то стандартное в платформе для таких нужд?
Найденные решения
19. herfis 285 21.10.19 13:18 Сейчас в теме
(1) Триггеры есть - подписки на события. Но для целей именно обмена есть еще лучше - планы обмена. Про них лучше почитать, но главное в двух словах: настраиваешь состав плана обмена и по нему автоматически регистрируются в специальных табличках списки объектов, измененных с последнего сеанса обмена. Остается только читать эти списки, отдавать куда надо инфу об измененных объектах и чистить списки. Предусмотрена даже автоматическая чистка списков изменений по квитанциям успешных загрузкок (если обмен асинхронный).

ЗЫ. С физическим удалением лучше не связываться и не реализовывать для него хитрые кейсы. Лучше с пометкой на удаление работать. Тогда удаление будет частным случаем изменения.
29. nomad_irk 41 21.10.19 14:46 Сейчас в теме
(27) Да поймите вы уже, что синхронное действие по передаче данных о записываемом объекте в транзакции записи этого объекта в БД вызывает увеличение времени этой самой транзакции в разы, а то и на порядки.

Транзакция на изменение элемента в БД - самое "страшное" для производительности всей БД.

Пока у вас не настанет понимание этого факта в масштабах ВСЕЙ БД, вы будете упорно пытаться все делать синхронно: записали - передали в другую БД или любый другие варианты, подобные этому.
Остальные ответы
Избранное Подписка Сортировка: Древо
8. lefthander 21.10.19 12:16 Сейчас в теме
(1)Возможно "версионирование объектов" - это подсистема БСП
13. AlexandrSmith 47 21.10.19 12:29 Сейчас в теме
(8) А много места не сожрет.
14. lefthander 21.10.19 12:32 Сейчас в теме
(13)а надо что бы было мало места сожрано? Можно ведь только нужные объекты настроить, а не все объекты базы.... И вопрос был - есть ли стандартные... один из таких стандартных именно версионирование.объектов
16. AlexandrSmith 47 21.10.19 12:41 Сейчас в теме
(14) Да не я согласен, главное чтобы место не съело.
19. herfis 285 21.10.19 13:18 Сейчас в теме
(1) Триггеры есть - подписки на события. Но для целей именно обмена есть еще лучше - планы обмена. Про них лучше почитать, но главное в двух словах: настраиваешь состав плана обмена и по нему автоматически регистрируются в специальных табличках списки объектов, измененных с последнего сеанса обмена. Остается только читать эти списки, отдавать куда надо инфу об измененных объектах и чистить списки. Предусмотрена даже автоматическая чистка списков изменений по квитанциям успешных загрузкок (если обмен асинхронный).

ЗЫ. С физическим удалением лучше не связываться и не реализовывать для него хитрые кейсы. Лучше с пометкой на удаление работать. Тогда удаление будет частным случаем изменения.
20. lefthander 21.10.19 13:23 Сейчас в теме
(19)А разве автор топика спрашивал про обмены? Он спросил о механизмах сообщения если с объектом что то делали... ;)
21. herfis 285 21.10.19 13:36 Сейчас в теме
(20) Нет разницы. Событийное "выплевывание в файл" подразумевает периодический мониторинг появления этих файлов. Поэтому никакой принципиальной разницы нет. Можно периодически "выплевывать в файл", а можно периодически напрямую спрашивать у 1С "есть чо?"
При этом ведение списков изменений - транзакционное. И наличие списка измененных объектов гарантирует, что при сбоях выгрузки/загрузки информация об измененных объектах утеряна не будет.
22. lefthander 21.10.19 13:39 Сейчас в теме
(21)Если в тот же справочник номенклатуры пять раз внести разные изменения одного объекта то в плане обмена будет присутствовать информация о том что объект менялся. Но кто и что менял информации не будет. Или я не прав?
23. herfis 285 21.10.19 14:15 Сейчас в теме
(22) Т.е. ты считаешь, что ТС версионирование таким образом реализовать хочет а-ля лог работы пользователей? Крайне маловероятно. Готов поспорить, что банальный обмен.
24. lefthander 21.10.19 14:27 Сейчас в теме
(23)Топик стартер придет и решит что ему нужно. ;)
2. AlexandrSmith 47 21.10.19 11:53 Сейчас в теме
Есть подписка на события, возможно это то что вам нужно?

Подписки на события 1С

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

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

Иногда возникает необходимость назначить обработчик сразу на несколько или все документы.

Подписка на событие 1С позволяет назначить обработчик при наступлении события у любого нескольких объектов (справочников, документов).
3. AlexandrSmith 47 21.10.19 11:57 Сейчас в теме
Если будете самостоятельно клепать журнал регистрации в каталоге 1С,

Можете похоронить производительность 1С, особенно при выгрузке в XML/

Не берусь советовать, но есть такие дела, замеченные за франчайзингами 1с.

Любят они все журналировать подобным образом.

Я делал подобную штуку но выгружал текстом, и все равно очень неприятная тема.
Производительность падает документы подвисают.
4. nomad_irk 41 21.10.19 12:05 Сейчас в теме
(3) Это от того, что делали синхронное выполнение. Асинхронность действий - залог быстродействия.
5. AlexandrSmith 47 21.10.19 12:11 Сейчас в теме
(4) Нет это от того, что делал в 8.2 на обычных формах. Сразу после перехода с 8.1 в которой это было реализовано, но поговорить об этом можно. Можно даже привести пример автору реализации асинхронного кода.

Кстати, если скачаете мои обработки, там все в асинхронном режиме даже конструктор запросов вызывается.

Но думаю что автор сам решить когда и что ему делать.
9. nomad_irk 41 21.10.19 12:19 Сейчас в теме
(5)
8.2 на обычных формах. Сразу после перехода с 8.1 в которой это было реализовано

Вообще никакой корреляцции. Действия либо синхронные, либо асинхронные, ни версия платформы, ни вид приложения не влияют на это.
11. AlexandrSmith 47 21.10.19 12:26 Сейчас в теме
(9) Я не помню что бы в 8.1 была асинхронность. А я всего лишь код переносил, но давайте по обсуждаем. Тема интересная место для фантазии много
15. nomad_irk 41 21.10.19 12:39 Сейчас в теме
(11) Что значит в 8.1 не было асинхронности? В 8.1 нельзя было где-то сохранить ссылку на измененный объект в пределах транзакции записи объекта в ИБ для последующей обработки этой самой ссылки?
Или что в вашем понимании асинхронность действий в данном случае?
17. AlexandrSmith 47 21.10.19 12:45 Сейчас в теме
(15)
_irk 40 21.10.19 12:39 Сейчас в теме
(11) Что значит в 8.1 не было асинхронности? В 8.1 нельзя было где-то сохранить ссылку на измененный объект в пределах транзакции записи объекта в ИБ для последующей обработки этой самой ссылки?


Да фоновое задание, тоже асинхронный вызов.
18. nomad_irk 41 21.10.19 12:50 Сейчас в теме
(17) ээээ....Я веду речь про асинхронность ДЕЙСТВИЙ, а не про синхронность/асинхронность вызовов процедур/функций.
Синхронность/асинхронность вызовов процедур/функций вообще никаким боком к синхронности/асинхронности действий в пределах транзакции записи объекта в ИБ.
12. AlexandrSmith 47 21.10.19 12:27 Сейчас в теме
(9) Я предлагаю по версиям пройтись и затронуть еще какие-нибудь изменения в 8.1 по отношению к 8.2
6. AlexandrSmith 47 21.10.19 12:12 Сейчас в теме
(4) Так что асинхронность залог быстродействия.
7. maks_20 62 21.10.19 12:16 Сейчас в теме
В вашем случае лучше завести план обмена с нужными объектами, подписками регистрировать объекты на узел этого плана обмена, а отдельным фоновым заданием обрабатывать объекты с этого узла, т.к. всякие внешние выгрузки в момент записи объекта - не очень красивый и быстрый вариант (будет тормозить запись, плюс нужно все исключения корректно обработать).
alex-l19041; +1 Ответить
10. AlexandrSmith 47 21.10.19 12:24 Сейчас в теме
(7) Да полностью согласен, это самый лучший способ.
25. mistermp3 21.10.19 14:30 Сейчас в теме
Хочу уточнить свои цели и озвучить выводы из вышесказанного.
1. Есть справочники которые создаются в одной системе (1С) и должны НЕМЕДЛЕННО попадать в другую (не 1с). Например, справочник "Номенклатура". При этом если что-то пошло не так (исключение), пусть лучше пользователь не сможет создать элемент, чем думает что всё ок, а в другой системе ничего не появилось. Для них подойдет подписка на события с генерацией xml файла
2. Есть справочники, которые должны отправляться в другую систему, но с допустимыми с лагами во времени. Например, ресурсные спецификации или ЭтапыПроизводства2_2. При этом важно, чтобы они корректно отработали в 1С и не застопорились даже при ошибке выгрузки. Для этого случая пойдёт план обмена.

Правильно мыслю?
26. nomad_irk 41 21.10.19 14:33 Сейчас в теме
(25) требование "НЕМЕДЛЕННО" в случае использования реляционных БД в качестве хранилища данных использовать глупо, ИМХО.
Со временем, надеюсь, вы это осознаете.
27. mistermp3 21.10.19 14:38 Сейчас в теме
(26) Имею ввиду, что не 1 раз в час, или через любые другие дискретные интервалы времени, а именно по факту события.
Не подразумевал, что прям реалтайм :-)
28. lefthander 21.10.19 14:41 Сейчас в теме
(27)Так объект справочника можно создавать достаточно долго, до тех пор пока его не записали, это не объект. А после записи его могут начать редактировать, так как ошиблись с реквизитами.
Есть смысл говорить об интервалах - 5-10-15 минут...
29. nomad_irk 41 21.10.19 14:46 Сейчас в теме
(27) Да поймите вы уже, что синхронное действие по передаче данных о записываемом объекте в транзакции записи этого объекта в БД вызывает увеличение времени этой самой транзакции в разы, а то и на порядки.

Транзакция на изменение элемента в БД - самое "страшное" для производительности всей БД.

Пока у вас не настанет понимание этого факта в масштабах ВСЕЙ БД, вы будете упорно пытаться все делать синхронно: записали - передали в другую БД или любый другие варианты, подобные этому.
30. mistermp3 21.10.19 15:37 Сейчас в теме
(29) То есть для обоих вариантов лучше план обмена, но для тех которые должны улетать НЕМЕДЛЕННО = «как можно быстрее» сделать обмен раз в пять минут, для остальных допустим два раза в день.
Так?
31. nomad_irk 41 21.10.19 19:05 Сейчас в теме
(30) Именно, можете даже раз в минуту сделать, но делать это сразу для "пачки" измененных объектов. Можете даже приоритеты у передаваемых данных расставить, чтобы выгрузка, скажем, номенклатуры происходила перед выгрузкой документа в одной "пачке" данных
32. mistermp3 21.10.19 19:16 Сейчас в теме
(31) nomad_irk, именно то, что и хотел услышать. Потому что можно разными способами, а как оптимально сделать очевидно не сразу
33. herfis 285 22.10.19 09:36 Сейчас в теме
(25) Если нужна такая тесная интеграция, чтобы две системы работали как единое целое (иногда такое нужно), то это делается на распределенных транзакциях. Можно сделать так, чтобы в конце транзакции записи 1С выполнялась попытка записи непосредственно в другую систему - обычно через http или напрямую в БД (не через файлики). И только если запись во вторую систему прошла успешно - завершать транзакцию записи 1С.
Но в этом случае и время записи увеличится и надежность упадет, так как при проблемах с каналом связи/драйверами или проблемах во второй системе работа в 1С станет колом.
ЗЫ. На практике такая тесная интеграция нужна очень редко. Потому что если достаточно раз в минуту подгребать изменения и не может быть такой ситуации, что вторая система должна иметь возможность отменить изменения в первой системе, то оптимально работать через очередь изменений.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Специалист техподдержки 1С
Москва
зарплата от 80 000 руб. до 120 000 руб.
Полный день

Системный аналитик 1С
Москва
зарплата от 80 000 руб. до 120 000 руб.
Полный день

Программист 1С
Москва
зарплата от 100 000 руб. до 200 000 руб.
Полный день

Тестировщик 1С
Москва
зарплата от 70 000 руб.
Полный день

Программист 1С
Новосибирск
зарплата от 50 000 руб. до 80 000 руб.
Полный день