ДБ
Принято! Благодарю!
Size: a a a
2021 March 21
H
аха..... т.е. если 1с не получает условный Response200 он не даст док провести?
Ты же запись докуметна выполняешь в один поток. Если в этом потоке будет исключение или ожидание ответа от АПИ, то и запись документа вывалиться в исключение. Какая тут разница 1С это или Питон. Поэтому тебе и говорю, что условно в одном потоке запись, в другом потоке после записи запрос к АПИ.
И 1С тут вообще не при чем.
И 1С тут вообще не при чем.
ДБ
Короче я сломаю мозг раньше чем что то получится. Сколько стоит такая штука? И кто нибудь возьмется?
H
Короче я сломаю мозг раньше чем что то получится. Сколько стоит такая штука? И кто нибудь возьмется?
Там работы на час. Дольше с твоим АПИ разбираться. Даже ноутбук расчехлять неохота.
Здесь фрилансеров искать не очень прилично.
Я бы на твоём месте разобрался и кайфанул бы. Обычная нормальная задача.
Скорее всего в интернете уже кто-то ее решил.
Здесь фрилансеров искать не очень прилично.
Я бы на твоём месте разобрался и кайфанул бы. Обычная нормальная задача.
Скорее всего в интернете уже кто-то ее решил.
ДБ
Где создавать подписку на документ?
H
Где создавать подписку на документ?
Подписку на событие?
H
А ты не хочешь доку почитать?
H
Оно, да.
Почитай доку сначала, там три страницы
Почитай доку сначала, там три страницы
ДЗ
Коллеги, добрый день. Хотелось бы услышать Ваш опыт на тему расширений или может быть подскажите, что почитать на эту тему.
Внедряем для внутренних нужд типовую конфигурацию на современной технологической платформе, в рамках которой минимально планируем изменять типовой функционал, но в значительной части дорабатывать с точки зрения новой функциональности, различных интеграционных адаптеров например со смежными системами.
Мнения с коллегами разделились.
На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.
По мнению некоторых моих коллег, правильнее делать упор именно на разработку новой функциональности именно через расширение, т.к. это позволяет вносить изменения на лету, не потребуется выгонять пользователей из системы.
Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.
Хотелось бы послушать Ваше мнение на предмет того, какой подход выбрать, именно если смотреть на длинной дистанции.
Внедряем для внутренних нужд типовую конфигурацию на современной технологической платформе, в рамках которой минимально планируем изменять типовой функционал, но в значительной части дорабатывать с точки зрения новой функциональности, различных интеграционных адаптеров например со смежными системами.
Мнения с коллегами разделились.
На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.
По мнению некоторых моих коллег, правильнее делать упор именно на разработку новой функциональности именно через расширение, т.к. это позволяет вносить изменения на лету, не потребуется выгонять пользователей из системы.
Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.
Хотелось бы послушать Ваше мнение на предмет того, какой подход выбрать, именно если смотреть на длинной дистанции.
A
Денис Злобин
Коллеги, добрый день. Хотелось бы услышать Ваш опыт на тему расширений или может быть подскажите, что почитать на эту тему.
Внедряем для внутренних нужд типовую конфигурацию на современной технологической платформе, в рамках которой минимально планируем изменять типовой функционал, но в значительной части дорабатывать с точки зрения новой функциональности, различных интеграционных адаптеров например со смежными системами.
Мнения с коллегами разделились.
На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.
По мнению некоторых моих коллег, правильнее делать упор именно на разработку новой функциональности именно через расширение, т.к. это позволяет вносить изменения на лету, не потребуется выгонять пользователей из системы.
Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.
Хотелось бы послушать Ваше мнение на предмет того, какой подход выбрать, именно если смотреть на длинной дистанции.
Внедряем для внутренних нужд типовую конфигурацию на современной технологической платформе, в рамках которой минимально планируем изменять типовой функционал, но в значительной части дорабатывать с точки зрения новой функциональности, различных интеграционных адаптеров например со смежными системами.
Мнения с коллегами разделились.
На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.
По мнению некоторых моих коллег, правильнее делать упор именно на разработку новой функциональности именно через расширение, т.к. это позволяет вносить изменения на лету, не потребуется выгонять пользователей из системы.
Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.
Хотелось бы послушать Ваше мнение на предмет того, какой подход выбрать, именно если смотреть на длинной дистанции.
Мое мнение полностью совпадает с твоим. А коллег порицать за желание говнить и фиксить
NG
Денис Злобин
Коллеги, добрый день. Хотелось бы услышать Ваш опыт на тему расширений или может быть подскажите, что почитать на эту тему.
Внедряем для внутренних нужд типовую конфигурацию на современной технологической платформе, в рамках которой минимально планируем изменять типовой функционал, но в значительной части дорабатывать с точки зрения новой функциональности, различных интеграционных адаптеров например со смежными системами.
Мнения с коллегами разделились.
На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.
По мнению некоторых моих коллег, правильнее делать упор именно на разработку новой функциональности именно через расширение, т.к. это позволяет вносить изменения на лету, не потребуется выгонять пользователей из системы.
Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.
Хотелось бы послушать Ваше мнение на предмет того, какой подход выбрать, именно если смотреть на длинной дистанции.
Внедряем для внутренних нужд типовую конфигурацию на современной технологической платформе, в рамках которой минимально планируем изменять типовой функционал, но в значительной части дорабатывать с точки зрения новой функциональности, различных интеграционных адаптеров например со смежными системами.
Мнения с коллегами разделились.
На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.
По мнению некоторых моих коллег, правильнее делать упор именно на разработку новой функциональности именно через расширение, т.к. это позволяет вносить изменения на лету, не потребуется выгонять пользователей из системы.
Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.
Хотелось бы послушать Ваше мнение на предмет того, какой подход выбрать, именно если смотреть на длинной дистанции.
> что обновление на лету это некий аналог динамического обновления.
я не ковырял точно, какие запросы выполняются на стороне субд при обновлении расширения, но из практики работы с нашей 24/7 системой могу поделиться опытом - там, где на двух-серверном кластере динамическое обновление бьет серверный (!!!) кэш в девяти случаях из десяти, обновление расширения еще ни разу его не ломало.
может быть я такой везучий. выборка конечно же не репрезентативна.
я не ковырял точно, какие запросы выполняются на стороне субд при обновлении расширения, но из практики работы с нашей 24/7 системой могу поделиться опытом - там, где на двух-серверном кластере динамическое обновление бьет серверный (!!!) кэш в девяти случаях из десяти, обновление расширения еще ни разу его не ломало.
может быть я такой везучий. выборка конечно же не репрезентативна.
ПМ
Денис Злобин
Коллеги, добрый день. Хотелось бы услышать Ваш опыт на тему расширений или может быть подскажите, что почитать на эту тему.
Внедряем для внутренних нужд типовую конфигурацию на современной технологической платформе, в рамках которой минимально планируем изменять типовой функционал, но в значительной части дорабатывать с точки зрения новой функциональности, различных интеграционных адаптеров например со смежными системами.
Мнения с коллегами разделились.
На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.
По мнению некоторых моих коллег, правильнее делать упор именно на разработку новой функциональности именно через расширение, т.к. это позволяет вносить изменения на лету, не потребуется выгонять пользователей из системы.
Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.
Хотелось бы послушать Ваше мнение на предмет того, какой подход выбрать, именно если смотреть на длинной дистанции.
Внедряем для внутренних нужд типовую конфигурацию на современной технологической платформе, в рамках которой минимально планируем изменять типовой функционал, но в значительной части дорабатывать с точки зрения новой функциональности, различных интеграционных адаптеров например со смежными системами.
Мнения с коллегами разделились.
На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.
По мнению некоторых моих коллег, правильнее делать упор именно на разработку новой функциональности именно через расширение, т.к. это позволяет вносить изменения на лету, не потребуется выгонять пользователей из системы.
Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.
Хотелось бы послушать Ваше мнение на предмет того, какой подход выбрать, именно если смотреть на длинной дистанции.
Если вы не ставите задачу сохранить замочек на конфе, то самое адекватное использовать расширение только для адаптации типового функционала (программная доработка типовых форм, модулей, интерфейса подсистем и т.п). Не использовать расширение для хранения данных, новые реквизиты внутри типовых обьектов и свои отдельнолежащие обьекты, модули вносить в основное хранилище.
NG
Если вы не ставите задачу сохранить замочек на конфе, то самое адекватное использовать расширение только для адаптации типового функционала (программная доработка типовых форм, модулей, интерфейса подсистем и т.п). Не использовать расширение для хранения данных, новые реквизиты внутри типовых обьектов и свои отдельнолежащие обьекты, модули вносить в основное хранилище.
я бы еще добавил, что нужно максимально долго стараться не затягивать форму в расширение. ибо формы в расширении это больная-больная боль на последующем их обновлении, которое можно произвести только вручную для каждой формы. в современных типовых при создании на сервере вызывается переопределяемый общий модуль, где можно затюнить форму как угодно. надо расширять/переопределять его.
JD
я бы еще добавил, что нужно максимально долго стараться не затягивать форму в расширение. ибо формы в расширении это больная-больная боль на последующем их обновлении, которое можно произвести только вручную для каждой формы. в современных типовых при создании на сервере вызывается переопределяемый общий модуль, где можно затюнить форму как угодно. надо расширять/переопределять его.
Даже при ручной актуализации формы в расширении будут сюрпризы в зависимости от того засасывался туда основной реквизит формы или не засасывался. Мрак.
ДЗ
Если вы не ставите задачу сохранить замочек на конфе, то самое адекватное использовать расширение только для адаптации типового функционала (программная доработка типовых форм, модулей, интерфейса подсистем и т.п). Не использовать расширение для хранения данных, новые реквизиты внутри типовых обьектов и свои отдельнолежащие обьекты, модули вносить в основное хранилище.
Я бы сказал, я ставлю задачу максимально сохранить замочек на типовых объектах конфигурации, само собой за исключением корня)