Смешение понятий, что запутывает - транзакция, как производственный процесс выполнения заказа, который, конечно, длится месяцами, и транзакция как перевод БД из одного целостного состояния в другое целостное состояние, которая никак не может длится месяцами:) 18-го НДС, например:). И вот, ради того, чтобы она длилась месяцами (и только ради этого???), и придумана ДРУГАЯ система (BPMS). Очевидно, что не ТТН откатывается, а оформляется новая операция (возврат продукции от покупателя). А в заказе просто меняется статус... Только очень конкретный и детальный пример может спасти BPMS:) То есть, показать ее практическую значимость.

АнатоЛойБредятинаТолько очень конкретный и детальный пример может спасти BPMS:) То есть, показать ее практическую значимость.
Значимость BPMS для автоматизации регламентированных процессов можно сравнить со значимостью сложного производственного конвейера для выпуска однообразной качественной продукции в большом количестве. Думаю, что конкретный и детальный пример сложного производственного конвейера быстро привести не получится :(.
ViPRos - это в Вашу пользу. Вы тоже говорите, что для объяснения необходимости какой-либо концепции нужен очень сложный и большой пример:)

GaryaА мне концепция, заложенная в BPMN, нравится. Я полагаю, что не нравится она тем, кто ее до конца не понял. :) Даже если искренне полагает, что понял, скорее всего, ошибается, если думает, что это чушь и в этом нет необходимости. :)

Механизмы отката "длинных транзакций" в BPMN содержат средства автоматизированной обработки, которые позволяют связать очень сложные цепочки действий по компенсации транзакции в логически корректную последовательность, которая получается таковой (то есть, корректной) как бы "сама собой", и при этом полностью описывающей все варианты прерывания транзакции. Даже если БП состоит из десятков подпроцессов, каждый из которых в свою очередь состоит из еще некоторого количества подпроцессов, даже если прервать основной процесс может ошибка во вложенном на втором уровне подпроцессе, который может несколько раз "вызываться" (как подпрограмма) в разных местах основного процесса, даже если общее количество мест и причин, по которым может произойти прерывание, исчисляется сотнями, спроектированный в "хорошем стиле" БП корректно отработает огромное количество процедур компенсации вне зависимости от причины и места прерывания процесса и уровня вложенности процессов. При этом не требуется во всех деталях расписывать маршруты обработки для всех варианты прерывания - такое расписывание привело бы к гигантской паутине управляющих воздействий, а в BPMN ее удается избежать благодаря концепции, похожей на "стек". Действия, для которых прописана процедура компенсации, всегда обрабатываются в обратном порядке тому как на них попал поток управления. Как при вызове подпрограмм программист не вникает в алгоритм "правильного возврата" из подпрограммы, точно так же разработчик вложенных БП не вникает в нюансы взаимодействия вложенного БП с родительским БП, в маршруты компенсации по прерываниям, которые могут произойте где угодно и почему угодно. Нотация BPMN линиями прорисовывает далеко не всё, что на самом деле может отработано! Это событий-ориентированная концепция! Она позволяет при разработке маршрутов компенсации не вникать мозгами во взаимодействия множества различных действий по компенсации, число которых может измеряться сотнями, а сосредоточиться на каждом шаге БП на компенсации исключительно самого этого шага.

Получается подход, аналогичный подходу в модульном программировании. Разработчик БП, следующий "хорошему стилю", сосредотачивает своё внимание, как правило, не более чем на 5-6 аспектах в один момент времени. При этом он получает описания БП, которые возможно охватить взглядом и быстро понять, что они делают и как - и убедиться при этом в их корректности. И при этом сложная совокупность БП позволяет описать достаточно сложную, запутанную логику, которая "целиком" ни в один мозг не влезет, но сформирует корректно работающее приложение, реализующее задумки тех, кто рисовал БП, именно в том виде, в котором они нарисованы. Это очень важно - получить именно то, что ты нарисовал, а не толи то, что нарисовал, толи нет - и потом еще искать, в каком месте алгоритма содержится ошибка, которая приводит к тому, что алгоритм отрабатывает не так, как нарисованная схема БП.

Вот скажите, Бредятина, не считаете ли Вы ООП простым "запутыванием понятий"? К чему все эти "заумные понятия" абстрагирования, инкапсуляции, полиморфизма, наследования? Зачем использовать вызовы подпрограмм, может быть, проще просто написать If Статус="Приплыли" then GoTo МеткаКакБыВозвратаИзПодпрограммы ? :)
Видите. Я конкретно пишу, о конкретных операциях, и производственных и управленческих, стараясь помочь Вам объяснить объективную необходимость в BPMS, отдельной от корпоративной информационной системы, а Вы опять рассуждаете в рамках концепций самой этой непонятной (подчеркну, даже Вам!) технологии.
Про ООП я уже много раз говорил - совершенно никакого отношения не имеет к БД. А то, что не имеет никакого отношения к БД, меня, честно говоря, не интересует. Так как все задачи предпочтительно решать с помощью данных, а не программирования:)

GaryaiscrafmПоэтому и говорить о них корректно только в указанном контексте, заботится о какой-то синхронизации"Заботиться о какой-то синхронизации" приходится не в силу нотации BPMN, а в силу объективной потребности и появления способов эту потребность реализовать. В суровой реальности многие процессы имеют совершенно разный ритм . Возникновение потребности в пасте Гойя может привязаться к заказу ж/д-контейнера, а может и не привести. Понятно, что ради 100 грамм пасты Гойя заказывать ж/д-контейнер нет никакого смысла. Грузовой автомобильный, впрочем, тоже. Желательно скомплектовать некоторое количество того, в чем возникла потребность таким образом, чтобы за один прием привезти много-чего. При этом потребность в различных частях этого самого "много чего" может возникать, в среднем, 1 раз в минуту. А контейнер может заказываться, в среднем, 1 раз в неделю. Одновременно, нельзя допустить, чтобы неукомплектование контейнера привело бы к остановке производства на неделю из-за того, что на него не доставили своевременно 100 грамм пасты Гойя, не так ли?
Так. Это задача КИС (ERP).
GaryaПроцессы, формирующие потребность, имеют ритм, существенно отличающийся от ритма процессов заказа транспорта - не потому, что в BPMN так придумали, а ОБЪЕКТИВНО . Я привел пример только пары таких процессов, на самом деле могут одновременно работать десятки процессов с разными ритмами взаимодействующие между собой СЛАБО ("слабое" взаимодействие отличается от "сильного" как раз тем, что связывает между собой процессы, работающие в разном ритме).
Конечно. Одна из банальных задач КИС (ERP).
GaryaИ тут настал опять черед аналогий в ИТ-сфере. Может быть зря напридумывали все эти мютексы, семафоры, нити, потоки для многопоточной обработки? Зачем всё усложнять? Почему не реализовать всё в одном линейном алгоритме безо всяких распараллеливаний и асинхронности? Ну, ежели объективной потребности в этом нет?.. :)
Есть. Но при чем здесь BPMS?

GaryaViPRosкак раз слабость бпмс в том, что она затсавляет ЖДАТЬ!!! (вот откуда длинные транзакции) момента синхронизации. бпмс - форвард планнинг, выталкивающая система, она НЕ ЗНАЕТ что будет ЗАВТРА и чему седня надо дать ПРИОРИТЕТКак настроите БП, так они и будут работать.
А по поводу того, как в BPMS реализуется вытягивание, имеется пример (слайд 22) в моей презентации (чтобы ее скачать, нужно зарегистрироваться).
А зачем же пример технологического процесса, а не управленческого???
Операции заполнения и движения контейнеров учитываются в ERP-системе?

GaryaБредятинаЕсть. Но при чем здесь BPMS?При том, что в ERP эти вопросы так просто как в BPMS не решаются.
Разумеется. Они решаются в ERP значительно проще. Так как не нужна интеграция нескольких систем.

GaryaВ своем сообщении 13435264 я привел ссылку на вполне себе конкретную схему транзакции, являющейся очень небольшой частью полного процесса оформления командировки (оно и понятно, цель - иллюстрация, а не попытка описать огромный процесс). Транзакция включает операцию "заказ билета" и "бронирование гостиницы", каждая из которых содержит компенсацию (могут включать автоматическую отправку уведомлений об отказе в гостиницу и в транспортную компанию). Отбой может произойти отдельно "заказа билета", отдельно "бронирования гостиницы" и всей их совокупности. Отказ от заказанного билета может, к примеру, произойти, если сотрудник решит ехать до места назначения на автомобиле. Процедура отказа от бронирования гостиницы может произойти в том случае, если сотрудник решит остановиться у родствеников или знакомых. Прерывание совокупности того и этого может произойти в том случае, если по каким-либо причинам отменили командировку. В зависимости от того, что именно прерывается и по каким причинам, откат может произойти любой из этих операций отдельно, либо в совокупности. Понятное дело, что схема очень упрощенная. Но при ее изучении вполне можно составить представление и о том, как происходит компенсация в сложных процессах, в которых выполнилась некоторая последовательная цепочка действий (процедуры компенсации запускаются в порядке, обратном порядку запуска самих операций - подобно "стековой" обработке). Можно также составить представление о том, как компенсируются действия, многократно выполнившиеся в цикле и как компенсируются действия, выполнявшиеся асинхронно в нескольких параллельных потоках управления. При наличии желания, естественно. :)
Хорошо, остановимся на управлении командировкой. Будем тщательно изучать.
Garya Крупную систему на одних только данных сделать очень трудно. По одной простой причине. Ресурсов человеческого мозга не хватит, чтобы в него одномоментно влезло предназначение всех-всех-всех данных. Придется все-таки каким-то образом проводить границы между тем, что рассматривается в данный момент, рассматривалось ранее и будет рассматриваться в дальнейшем. Придется придумать какой-нибудь способ, чтобы эти границы не приводили к несогласованности первого, второго и третьего. И зачем придумывать, изобретать велосипед, если всё уже придумано?
Это точно. BPMS - классический "велосипед". На котором придется постоянно ехать вровень с автомобилем, чтобы вовремя кричать друг другу нужную информацию.