Скажем так, консультация об осуществимости некоей задумки.
А то прогеры не хотят делать, а силой я их прогибать не хочу (хочу в первую очередь понять, "а не дурак ли я").
Желательно скайпом или почтой.
кароче не взлетит, даже и не пытайся.
Там у тебя должен быть составной тип основным реквизитом, а динамический список такое не проглотит
заинтриговали..
давайте уже выкладывайте задачу то..
(12) Тут не столько вопрос...
точнее, вопрос в том, насколько велик будет накладняк на эти действия...
-------------------
короче, идея такая: есть регистр правил - (способ хранения - РС или справочник - не суть важен)
структура: <вид документа><флагПриПроведении><ФлагПриЗаписи><ТекстЗапроса><ЧеловечьеОписание>
Цель: вынести проверки бизнес-правил из кода объектов, обеспечит управляемость "снаружи", понимаемость грамотными пользователями
Способ работы: при выполнении записи либо проведения выполняется запрос (проверка), которому передается объект. Если проверка "выполняется", "проходит" - запрос возвращает пустое значение.
Если проверка не проходит - запрос возвращает сообщение об ошибке. Соответсвенно, действие отменяется, а сообщение (сообщения, если их много) собираются, и выводятся пользователю.
-------------
собственно, вопрос: насколько велики будут накладные расходы на исполнение этого.
(19)это называется подписка на событие.
вешается 100% "сбоку" и работает без проблем..
я вообще не понял в чем проблема ЭТО реализовать?
Ну дык есть же метод Выполнить()
И причем тут УФ и ее тонкий клиент - вообще непонятно, все делается на сервере
(19) нормальная задача, я тоже думал о похожем варианте.
тут из УФ - только отрисовать РС на форме, а все остальное на сервере, как и подсказывают коллеги
Тут самый сложный момент - "понимаемость грамотными пользователями" - таких просто не существует! все равно будут звать программиста
сколько я видел параметризируемых конфигураций - ни одна не использовалась. документацию никто не пишет, в логике черт ногу сломит - легче открыть синтаксис помощник и прочитать
Собственно, возражения прогеров:
1) они не знают, в каком контексте будет выполняться запрос. пока писал - заставил проверить. Выполнить() выполняется в контексте вызова - может и на клиенте, и на сервере.
2) Пугают "тоннами кода".
(25) послушай программистов и даже не начинай это гиблое дело. если и найдется желающий покодить "пользователь" - от таких лучше держаться подальше
(24) тут без программиста никуда. Ибо запрос юзверь не напишет. Писать будут только программисты.
понимаемость пользователями - в том смысле, что ГрамотныйЮзверь™ смотрит в книгу видит фигу в этот регисто, и видит,что "для документа ЗаказПоставщику" в момент записи проводится проверка называемая "проверить на значительное превышение остатка лимита", или "для документа ЗаявкаПокупателя" в момент проведения проводится проверка называемая "проверить на низкую наценку". Вообще говоря, там (в регистре) есть еще кое что "для пользователя", но на обработку это не вляет, поэтому я об этом умолчал...
(28) Выписать-то без проблем. Но для (до) применения лекарств я предпочитаю уточнять диагноз.
бездумное приенение этого лекарства (даже в профилактических целях) не способствует нормальной работе.
мне ж не задрачить их надо, а решить задачу максимально эффективно.
Если юзвери сам код править не будут - так все карты в руки, подписки на события (обработки с проверками можно сделать хоть внешними) + регистр с настройками
Только это не режим УФ - все на сервере
Вообще клиент на УФ - это просто формочка в которую по запросу заливаются данные
(31) Не только "править не будут" - они и видеть его не будут.
прикольно будет, если сделать спр, где хранить проверки "в человеческом виде".
типа "Проверять заполнение цен при проведении", "Проводит только ответственный", "Запрет проведения, если дата документа меньше более чем в 2 дня от текущей" и пр.
тогда ответственные лица - типа начальников отделов - могут для каждого дока собирать такой набор проверок для каждого дока и рулить ими сами, без участия прогеров
+(32)Хотя обновления для оперативной базы не очень и нужны. Вон, у меня торговля работает - она в девичестве 9.31 была. Почти ничего не "накатывали", ибо накатывать на базу в 24*7 (да еще и 140Г) трудно.
за 2 часа простоя оперативной работы я могу не только бонуса лишиться, но и части зарплаты..
Stim прикольно будет, если сделать спр, где хранить проверки "в человеческом виде".
типа "Проверять заполнение цен при проведении", "Проводит только ответственный", "Запрет проведения, если дата документа меньше более чем в 2 дня от текущей" и пр.тогда ответственные лица - типа начальников отделов - могут для каждого дока собирать такой набор проверок для каждого дока и рулить ими сами, без участия прогеров
А смысла нет. по крайней мере, у нас. у нас, допустим, если заявка принята (проверка цен прошла), то проверка цен уже нигде не производится. Да и страшновато.... они "нарулят"...
(37) Да. Ну и 85 пользователей, ОЛАПы всякие, бизнес-процессы, всякие восстановления последовательностей во время работы пользователей, открытие периода в разделеном режиме во время работы, и т.п.... т.е. по меньшей мере 21.5 имею :-)
правда, смотрел в свое время у Олега Садовникова конфу - там она под 300 была, но главное - управляла, допустим, движением тележек вот таких:
(43) ну я ж говорю, что я до 22 не дотягиваю :-(
(19) Само получение кода из справочника или регистра будет очень быстрым.
А для выполнения этого кода существует команда "Выполнить".
Не вижу проблем.
Если только там нет сложных математических расчетов (заявлено, что Выполнить работает медленнее, чем обычный код в модулях).
(48) Отборы проще хранить, настраивать, можно даже периодические делать и т.п.
а объект скармливать в качестве параметра.
У нас сделано так, есть некий объект, ему "соотвествует" схема СКД, правила (отборы) хранятся в справочнике, в момент проверки пробегаем по справочнику и проверяем,если СКД с отбором "возникает" (непустой набор), значит правило выполняется.
Сейчас они почти сдались. вопрос остался один - как возвращать сообщения об ошибке, сгенерированное обработкой контроля, с сервера.
(54) щас добавлю
(54) стукнул в скайп
(58) Это предусмотрено :-) а вот они его вывести не могут
А в чем глубинный смысл задачи? Зачем требуется бизнес-логику непременно вырвать из кода и запихнуть в базу? Работать по-любому такое решение будет медленнее. Раньше такое практиковали как эрзац глюкавого демонического обновления, там где нельзя было для нормального обновления выгонять юзеров. Сейчас демоническое достаточно надежно, смысла не вижу.
(39) 3.5 терабайта, правда 8.1
(60) глубинный смысл - чтоб видеть, какие проверки есть, и как должны действовать.
видеть - со стороны квалифицированных пользователей.
частично - рулить (включать-отключать).
частично - чтоб обновлять проще.
и еще несколько пунктов.
то, что медленнее - это понятно. вопрос - насколько медленнее.
(62) Глюки кэша в 8-ке это фигня. Страшно было когда демоническое убивало базу.
(63) По опыту поддержки такой конфы:
глубинный смысл - чтоб видеть, какие проверки есть, и как должны действовать.
видеть - со стороны квалифицированных пользователей.
Для программера монопениссуально где смотреть код, в конфе или справочнике алгоритмов. Но чем больше возможных мест хранения логики тем больше гимора с раскопками. Юзеры в код бизнес-логики лезть не будут все равно, независимо от места его хранения. Для них это темный лес.
частично - рулить (включать-отключать).
Ага, проще. Кто-то снял галку - начались танцы у юзеров. Мне было с этим легче, я был единственный одинэсник, но все равно проблемы случались. Если у тебя больший штат - проблемы вида "кто бросил валенок на пульт кто отжал галку" гарантированы.
частично - чтоб обновлять проще.
На самом деле не проще. При нормальном обновлении ты видишь что и как меняется, можешь понять последствия. Когда у тебя в справочнике лежит код, единственный способ узнать его работоспособность после обновления - пробежаться по граблям. Автоматической проверки валидности нет. Даже тупейшего синтакс-чека не сделаешь.
и еще несколько пунктов.
то, что медленнее - это понятно. вопрос - насколько медленнее.
Насколько медленнее за глаза сказать нельзя. Смотря какой код вынесен в справочник. Тормоза возникают из-за дополнительного обращения к базе для чтения кода алгоритма и компиляции. В подотчетной базе тормоза были заметны даже на глаз, что вынудило разрабов изобретать механизмы кэширования для хранимых алгоритмов. Решение несколько повысило быстродействие, но взамен принесло новые глюки кэша.
Короче говоря, мое мнение - нах такое решение. Никакой пользы кроме вреда не получается.
ТеньД (62) Глюки кэша в 8-ке это фигня. Страшно было когда демоническое убивало базу.
ну, фигня-не фигня, но когда оно у четырех разных людей в одном кабинете работает по-разному....
Для программера монопениссуально где смотреть код, в конфе или справочнике алгоритмов. Но чем больше возможных мест хранения логики тем больше гимора с раскопками. Юзеры в код бизнес-логики лезть не будут все равно, независимо от места его хранения. Для них это темный лес.
вот я и хочу свести всю логику - в единое место.
смотреть юзеры - будут. не каждый, но четверо-пятеро - будут.
Им и мне будет проще администрировать.
программистам будет проще писать.
Ага, проще. Кто-то снял галку - начались танцы у юзеров. Мне было с этим легче, я был единственный одинэсник, но все равно проблемы случались. Если у тебя больший штат - проблемы вида "
кто бросил валенок на пульткто отжал галку" гарантированы.
"Кто-то" не снимет. Есличо, у меня в 7.7 самые большие таблицы - это логи действий.
На самом деле не проще. При нормальном обновлении ты видишь что и как меняется, можешь понять последствия. Когда у тебя в справочнике лежит код, единственный способ узнать его работоспособность после обновления - пробежаться по граблям. Автоматической проверки валидности нет. Даже тупейшего синтакс-чека не сделаешь.
мысли, как это тестировать - тоже есть.
Насколько медленнее за глаза сказать нельзя. Смотря какой код вынесен в справочник. Тормоза возникают из-за дополнительного обращения к базе для чтения кода алгоритма и компиляции. В подотчетной базе тормоза были заметны даже на глаз, что вынудило разрабов изобретать механизмы кэширования для хранимых алгоритмов. Решение несколько повысило быстродействие, но взамен принесло новые глюки кэша.
на худой конец, перенести эти проверки непосредственно в код - дело нескольких часов.
Короче говоря, мое мнение - нах такое решение. Никакой пользы кроме вреда не получается.
у каждого свои тараканы. ваше мнение - услышал. спасибо.
(67) а, ну тогда забей)
(0) а почему вы себя так ограничиваете одним запросом. Почему бы при проведении документа не выполнять произвольный метод в произвольном месте?
у нас так сделано (насколько я могу себе представить аналогию с SAP/ABAP)
+(69) к тому же в этой гипотетической функции куда проще сформировать таблицу с сообщениями пользователям. В 1С конечно нет интерфейсов - но можно просто договориться о формате
(69) Не совсем понял про "произвольный метод в произвольном месте".
если про то, что хочу выполнять не произвольный код, а произвольный запрос - на мой взгляд, накладняк на компиляцию кода несколько выше накладняка на план запроса.
но в конце концов, непринципиально. можно и код. Но в восьмерке практически все хотелки (в части проверок) можно реализовать запросом
(71) ну просто по моему куда проще писать/отлаживать/тестировать в каком нибудь глобальном модуле процедуру чем запрос. И к тому же, если у вас в дальнейшем появятся какие нибудь проверки, которые запросом не сделать, у вас уже будет рабочий фрэймворк которые будет такое требование воспринять. А просто впихнуть запрос в процедуру и выполнять его там - не такие уже большие накладные расходы по сравнению с выполнением одного запроса. Опять таки, я не знаю, есть у вас тестовая система или нет - но версионировать код (хранилище конфигурации) куда проще, чем запросы в справочнике.
(72) Кстати да, про этот минус я забыл. Алгоритмы в справочниках придется версионировать отдельно от остальной конфы.
вопрос: на сколько эти "вынесенные" модули будет просто и доступно отлаживать???
вот прог, который будет в дальнейшем поддерживать эту конфу, возрадуется
моё ИМХО так делать не стоит!!!
(75) а в чем проблема то? прог увидит, что при проведении читается какой то регистр и оттуда берется имя процедуры/модуля, которую надо вызвать. Ну и все.
Если уж совсем правильно сделать, то можно написать простенькую внешнюю обработку в которой эти модули статически вызывать в зависимости от документа и отлаживать себе на здоровье
ЗлобнийМальчик Если уж совсем правильно сделать, то можно написать простенькую внешнюю обработку в которой эти модули статически вызывать в зависимости от документа и отлаживать себе на здоровье
(77) три минуты работы
просто не пойму в чем тайный смысл?
лень открыть конфигуратор и православно написать код? писать удобно, проверить сразу синтаксис
отладить на тестовой, протестировать, создать релиз, и забыть ...
(82) Дело не столько в динамическом изменении (оно, конечно, хорошо - но не критично), сколько в то, что бизнес-пользователи знают и понимают, какие у них сейчас проверки есть, какая у них реакция на "непрохождение". а пользователям уровня исполнителя - корректно понятны необходимые реакции на ошибки.
(84) нет. "толково созданое руками воркфлоу" есть. но оно организует (и направляет) поток. На пути этого потока должны стоять фильтры (как задерживающие, так и регулирующие). функция фильтрации и организуется вышеупомянутым способом.
Кстати, на основе "толково созданое руками воркфлоу" есть автоматическая генерация интерфейсов рабочих мест. само "оно" тоже настраивается динамически, визуализируется и т.д. В отличие от штатного механизма снеговика. И опять же, динамическая настройка не столь важна -важно то, что поток исполнения виден бизнес-пользователю, понятен, предсказуем, считаем (исчисляем), исполнение фиксируется в системе, и т.д.
(83) ну теоретически вы могли бы эти проверки с тем же успехом зафигачить прямо в проведение... Так что с моей точки зрения основное преимуществл - именно динамическое исполнение. Но просто в сапе дотащить разработку до продуктивной системы обычно - тот еще геморрой. Мы вот практикем обновление продуктива каждые три месяца - а есть добрые люди которые раз в пол год перетаскивают...
(86) естественно, могли. и сейчас все еще можем :-) или могём?:-))
другое дело, что понимать, какие именно проверки сейчас имеются (хотя бы заявлены, задекларированы) - без лазанья в код возможности нет. Даже в коде - проверки не совсем явные. Т.е задайте себе вопрос: "какие проверки у меня в системе есть при записи и при поведении", и зафиксируйте - где, как и сколько по времени вы ищете ответ.
Хренассе.... бизнес-пользователям (читай - заказчикам ми работодателям), значит, должно быть фиолетово, и их слать лесом? :-)
встречный вопрос: "а служба ИТ, часом, не уху ела?"
x86 ИТдир такой вопрос может задать, ему толково объяснишь что смысла описывать нету
ага. ну тогда я б толково объяснил, что смысла платить такому сотруднику зарплату - нет....
(92) (коммерческий, дир по продажам, фин или еще кто - не суть важно, но уполномоченый задавать вопросы.)©
а вопросы могут быть простые. например: "по условиям ценового соглашения на продукцию этого произвдителя нам запрещено давать скидки при торговле в этом регионе" - это реализовано?
Ну и т.п.
"не уровень ген дира следить за крыжиками" - его дело задавать вопросы. а твое - на них отвечать. его дело ставить задачи. а твое - их выполнять.
(93)>>"по условиям ценового соглашения на продукцию этого произвдителя нам запрещено давать скидки при торговле в этом регионе" - это реализовано?
на это вопрос ответить проще простого
ген дир задаст тебе вопрос: "пока жи все проверки"
ты: вывалишь ему отчет из 200-400х доков/справочников, у которых по 30-80 условий проверки (причем условия проверки будут пестец многоэтажные)
вопрос: что он будет делать с этим отчетом? в чем его полезность? а не надуманна ситуация?
И сможет ли квалифицированный пользователь сам получить ответ на такой вопрос.
Задача осуществима - но писать код в режиме предприятия - зло. Ибо не поддается отладъке совершенно
(97) ограничения - часть рабочего потока.
(98) ну, собственно, я это же и предлагаю. организовать в одном месте. только с возможностью "смотреть" без открытия конфигуратора. Плюс плюшки типа динамического обновления, оперативного включения-выключения, и самодокументирования реакции. минус быстродействие
(99) писать и отлаживать можно и не в режиме предприятия.
Сам сейчас консолидацию колупаю, поэтому знаю не понаслышке
(107) уже :-)
(113) а, понял. "вбыв бы"©