Производительность и надежность Workflow в DAX2009

[Vadik]

Цитата:

Сообщение от fed

Понимаешь Вадик. Я раз в три месяца наблюдаю на работающей системе последствия доработки workflow неграмотными консами и разработчиками

Я разгребаю внедрение сделанное неграмотными консами и разработчиками последние уже почти что два года. На 4.0 переписано все вдоль и поперек

Цитата:

Обычную функциональность диагностировать и чинить намного легче

Да, если она простая как дверь, жестко запрограммирована и ненастраиваема. Такая нужна далеко не всем

Цитата:

Если тебя окружают исключительно средние или хорошие консы и разработчики и у них есть время на то чтобы писать внятные ТЗ, программировать, тестировать, планировать релизы и тп - то могу только порадоваться за тебя.

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

Цитата:

workflow это просто еще одна замечательная возможность to shoot yourself in a foot

AX (да и любая другая система) вообще замечательная штука to shoot yourself in a foot при неправильном использовании - и что? Есть (были) проблемы с мастабированием в 2009 - нас с нашими объемами не коснулось. Одно дело - знать и понимать ограничения (они так или иначе у любого решения имеются), другое - шарахаться от всего стандартного и привинчивать везде балласт в виде кучи самописок. Сделаем нагрузочное тестирование на 2012, запустим и будем радоваться жизни иншалла

Цитата:

и при чем здесь воркфлоу? простинькую систему одобрений к любому типу документов не трудно прилепить

Вы простите c workflow в AX 2012 работаете? Сколько возьмете времени и денег за "написать простинький аналог" со схожим функционалом и без фатальных недостатков (с) первого релиза (2009) ? Сколько будет стоить сопровождение?

[ikopyl]

Цитата:

Сообщение от trud

ну у нас где-то 300 счетов обработалось за 15 минут. Под обработкой подразумевается шаг Начало(он самый тяжелый из всех шагов). но сам документооборот был довольно навороченным, состоял из многих subworkflow. кол-во экземпляров по сути регулировалось в параметрах АОСа - это кол-во пакетных заданий. там было что-то около 20. было вроде как по 2 ядра на АОСе и на IIS. они грузились на 100% при этом
по времени тут точно не месяца, по сути единственное что можно улучшать это обработчик, но он не очень сложный. все остальное скрыто в недрах .net. т.е. тут все днями измерялось

Давно, года три или четыре назад, настраивал пример на WF на 2009-й, приложение, AOS и IIS были установлены локально...
Так вот, WF присылало изменённый статус по документу где-то раз в минуту. Ускорить удалось до ~5 сек, поковырявшись в настройках IIS, в оснастке открыть "Пул приложений", найти свой экземпляр WF, и далее, меняя в настройках дополнительных параметров в группе полей "Модель процесса" период времени между проверками связи, если не ошибаюсь - там несколько полей, связанных с откликом, уже не помню конкретно, что менял, можно попробовать поиграться с параметрами.

Опять же, я не спец по IIS и не программист, ковырял чисто интуитивно, и что там на что ещё может повлиять - не знаю . Но вот за что купил в своё время, за то и продаю.

[macklakov]

Интеграция систем ведет к потере надежности. Если есть совместно работающих 2 сервиса, то вероятность сбоя одного из сервисов можно сказать что складывается. Если для работы системы необходимы 10 одновременно работающих служб, то вероятность сбоя возрастает на порядок. Как это происходит на конвейере Авто-ВАЗ, к примеру. Все это усугубляется проблемами совместимости компонет между собой, которые могут формировать экспоненциальную потерю надежности.
К примеру, даже для чистой AX, без всяких приблуд, нужны ActiveDirectory, SQL, AOS, винды, на которых все бегает, сеть и клиент. Если хоть что-то из этого падает или оно перестает друг с другом дружить, у пользователя нет аксапты.
По мере обвешивания аксы всякими замечательными технологиями, надежность гробится дополнительно. И Workflow в AX 2009 является ярчайшим представителем таких убийц надежности.
В принципе, есть надежда, что это все временные болезни роста и по мере миграции всего в однородный .net, как минимум, наступит избавление от проблем интеграции решений друг с другом.

[belugin]

>Интеграция систем ведет к потере надежности

Иногда к повышению. Если бы вместо в винды в Ax было что-то свое написанное специально для нее, то оно было бы менее надежно так как тестировалось на меньшем количестве ситуаций. То же и про SQL сервер.

http://www.catb.org/~esr/writings/ta...l/ch13s01.html

It can happen that the designers of a project are so wary of implementation complexity that they reject a complex but unified way to solve a whole class of problems in favor of lots of duplicative, ad-hoc code that solves each individual one in turn. The result is bloat in the size of the codebase, and maintainability problems more severe than if the unified method had been accepted. For example, a Web project that really needs a centralized relational database behind its pages might instead spawn several different keyed data files containing information that has to be reintegrated at page generation time. This sort of failure is all too common. It doesn't have a traditional name; we'll call it an adhocity trap

[macklakov]

Цитата:

Сообщение от belugin

>Интеграция систем ведет к потере надежности

Иногда к повышению. Если бы вместо в винды в Ax было что-то свое написанное специально для нее, то оно было бы менее надежно так как тестировалось на меньшем количестве ситуаций. То же и про SQL сервер.

Нет, это подмена понятий. Интеграция и повышение надежности компонент это два совершенно разных процесса. Сама по себе интеграция ведет к потере надежности. Но эффект от использования более надежных компонент может значительно превосходить издержки интеграции.
К примеру:
ERP с встроенной файловой системой имеет вероятность сбоя 10% за условный период времени.
За тот же период ERP, использующая SQL сервер, падает с вероятностью 2%, и SQL с вероятностью 1%. В сумме около 3%. Т.е. суммарная надежность существенно возрасла, т.к. используются более качественные компоненты. Но, тем не менее, сама по себе интеграция увеличила вероятность ошибки. Просто эта вероятность была компенсирована надежностью отдельных компонент.
Если же использовать компоненты не обладающие превосходным качеством, способным компенсировать издержки интеграции, то получается чистый вред.

[komar]

Цитата:

Сообщение от ice

и при чем здесь воркфлоу? простинькую систему одобрений к любому типу документов не трудно прилепить. в некоторых случаях вообще обходятся правами доступа, т.е. разносит документ не абы кто, а человек с "головой"
То что система одобрений полезна не ставится под сомнение, под сомнение ставится именно воркфлоу.
ПС у нас работало одновременно и воркфлоу и самописка, в результате одновременной эксплуатации двух систем в течение полугода, было принято решение от форкфлоу отказаться, по причинам описанным выше в том числе.

Вообще, типичный случай - для цепочек одобрений самописки работают лучше.

Цитата:

Сообщение от fed

Ну то есть - я понимаю, когда системы workflow используют для СЛАБОФОРМАЛИЗУЕМОГО документооборота. Типа сидит у нас какая-нить проектно-исследовательская контора, обменивается служебными записками, проектной документацией, спецификациями, письмами заказчиков и тп. Мы тут прикручиваем документооборот, определяем типы документов, типы аннотационных полей для каждого документа, состояния документа и определяем цепочки утвреждений для документа. Вот тут workflow очень даже хорош и уместен.
Но мы говорим о ERP-системе. ERP-система по определению работает со стандартизованными и формализованными документами и операциями. Я вообще не понимаю, зачем здесь документооборот настраиваемый ?

Видимо, ещё одна попытка теоретиков-мечтателей запихнуть в ERP весь мир, помноженная на усилия практиков-продажников втюхать это всем подряд. Или, что ещё более вероятно, у МС изначально были люди, занимавшиеся такими разработками, и балшой насяльник подумал - а давай-ка мы это прикрутим, вроде называется похоже. У конкурентов к тому же с похожим названием что-то уже прикручено, и нам тоже надо.
Фокус-то ещё и в том, что решения о том, какой набор продуктов (зачастую разными людьми и под разные задачи писавшихся) будет через год называться "Акзаптой", принимают высокопоставленные пиджаки. Они в какие-то архитектурные ньюансы лезть не будут: есть несколько систем, надо их к такому-то мартобря скрестить, чтобы что-то продавабельное работало, потом всё это надо продавать под определённым брендом. Если что-то похожее в конторе уже есть - продавать будут то, что есть. А потом - допиливать то, что продавали.