Автор Тема: Топ-10 ошибок, которые делают начинающие специалисты по Workflow  (Прочитано 20485 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 762
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Ссылка на оригинальный пост: You are not allowed to view links. Register or Login. Небольшой перевод, без авторских воспоминаний :-) за жизнь.


1. Пытаться разобраться как работает Workflow, используя только знания ABAP.
 
Начинающим специалистом по Workflow, обычно становится специалист по ABAP. Почему-то считается что это где-то родственные отрасли и абаперы охотно соглашаются заняться сопровождением Workflow, если возникает такая необходимость, считая что  если они знают как работать с отладчиком, то не составит труда разобраться в рабочих журналах Workflow и вообще понять как это все работает.

PS: {Uukrul} Кстати от меня лично, иногда это встречается и в других модулях, абапер, особенно начинающий, почему-то думает что отладчик очень быстро позволит ему разобраться как работает модуль и поэтому часто соглашается типа да я еще и вот этот ММ поддрежу, если что /h поможет.

В общем автор блога тоже был уверен в своей абаперской квалификации и недели 2 сидел в отладке пытаясь понять как же работает Workflow и только благодаря прослушанным двух недельным курсам по Workflow, понял как сильно заблуждался.
 
Так что первая ошибка начинающего специалиста Workflow, это переписывание того в чем не разобрался на ABAP, хотя правильным будет работать в терминах Workflow и заниматься именно конфигурированием Workflow. Не пытайтесь разобраться в Workflow, если вы не прослушали курсы SAP или хотя бы для начала не прочитали и не переварили книгу Workflow Book, например: You are not allowed to view links. Register or Login


2. Сбивает с толку, связь рабочего элемента (workitems) с электронной почтой.
 
Это очень общая концептуальная ошибка. Проще говоря, WorkItem является рабочим шагом/тактом процесса - как правило, рабочий шаг задачи можно рассматривать с нескольких почтовых ящиков SAPOffice, и далее как правило рабочий элемент исчезает из почтовой очереди, как только один из агентов обрабатывает его. WorkItems могут быть посланы только в системе SAP в рамках SAPOffice.

В отличие от электронной почты, где сообщение представляет собой плоский элемент информации. Несколько копий отправленные в несколько ящиков, остаются в почтовых ящиках каждого человека индивидуально, пока он не прочитает или не удалит сообщение. Электронные письма могут быть отправлены любому пользователю, а не только пользователю SAPOffice.


3. Не выполнение транзакции SWU_OBUF, перед тестированием Workflow после изменения.
 
Начинающие консультанты сталкиваясь с Workflow считают, что система работает не предсказуемо и часто сбоит И это, конечно так, если у вас нет понимания того, как работает буфер времени выполнения (Runtime Buffer) для Workflow. Но не беспокойтесь: все что нужно, это только помнить, что требуется выполнить синхронизацию буфера времени выполнения, вызвав транзакцию SWU_OBUF, до выполнения измененного рабочего процесса.

Эта рекомендация относится как к процессу разработки объектов Workflow в системе разработки, так и для системы тестирования и продуктивной системы, после того как Workflow процесс будет перенесен в каждую из этих систем, так как стандартно буфер обновляется системой автоматически только раз в сутки, в полночь.


4. Наводнение в почтовых ящиках пользователей сотнями WorkItems.

Автор блога довольно сильно ощутил на своей шкуре ситуацию, когда рабочие элементы потока операций генерируют сотни элементов задач (ЭПО - Элемент потока операций) в почтовых ящиках пользователей. Если это так, то возможно лучшим решением будет использование отчетов по работе с WorkItems

Вполне возможно, что это часто психологическая вещь, когда пользователи бурно реагируют, что в их почтовых ящиках, постоянно появляются сотни писем напоминаний о шаге различных задач, которые они должны обработать. Это часто приводит кто тому, что пользователи начинают отказываться от использования своих почтовых ящиках полностью или громко требовать отключения Workflow напоминаний. Отсутствие каких либо новостей лучше, чем шквал плохих новостей.


5. Не изменяйте настройки по умолчанию для "Получатель ошибок для обратной связи" в транзакции SWEQADM.
 
Если запустить рабочий процесс с помощью события и в ходе работы процесса что-то пойдет не так (например, отсутствует обязательный параметр), ответом по умолчанию в SAP является реакция отключения связи между событием и рабочим процессом.

Да, вы не ошиблись, и да, это катастрофа. Любые последующие события системы будут потеряны навсегда, пока вы не поймете, что произошло, не исправите это в системе разработки, после чего не перенесете все это в продуктивную систему, и только после этого возобновите связь.

В транзакции SWEQADM, установите значение в состояние "Выделить связь как ошибочную", рисунок WF-01.png ниже. Это означает, что связь не будет разорвана и события будут накапливаться и храниться, пока ошибка не будет исправлена, после чего эти события могут быть доставлены снова.

PS: {Uukrul} В настоящее время системы похоже уже поставляются с правильным предустановленным параметром  "Получатель ошибок для обратной связи". По крайней мере в паре свежеустановленных систем, у меня параметр был правильным.


6. Запуск Workflows процесса непосредственно из программы, а не с помощью события.

Очень часто WS* - рабочие процессы (и даже TS * стандартные задачи) запускаются непосредственно с помощью вызова функционального модуля SAP_WAPI_START_WORKFLOW. Это ужас. Правильным и лучшим будет запуск Workflows с помощью события.

Есть миллионы причин почему именно так, вот пять из них:
  • Вы можете легко активировать или деактивировать Workflows (даже в продуктиве) по активации или деактивации связи события с потоком.
  • Вы можете легко переключаться со старого рабочего процесса в новый, манипулируя связью событие - рабочий поток.
  • Вы можете активировать новые рабочие процессы, для уже существующих событий, которые активируют уже какие-то рабочие процессы.
  • Если рабочий процесс не начинается по какой-то причине, вы можете проверить журнал событий в транзакции ​​SWEL
  • Не существует проблемы с авторизацией старта рабочего процесса.


7. Отсутствие контроля за работой Workflows процессов системы.
 
Если никто из пользователей не сообщает о проблемах в работе Workflows, то это не значит, что на самом деле нет никаких проблем. Администратор Workflows должен проявлять инициативу сам, контролируя работу всех задач, всех Workflows потоков, особенно если в системе стартуют и начинают жизнь, новые рабочие потоки.
 
Должна быть "нулевая терпимость" к запуску транзакции SWI2_DIAG - диагностика ошибок потока операций. В некоторых системах при анализе выявляются сотни проблем, которые происходят каждый день! Транзакция SWI2_DIAG не должна рассматриваться как инструмент для обработки ошибок, но как мусорное ведро в последней инстанции, обязательно.

Поле обнаружения проблемных потоков, для решения проблемы используйте транзакции: SM58, SWI2_ADM1, SWI2_DIAG, SWEQADM и SWEL.


8. Использование внутренних функциональных модулей (и таблиц), типа SAP_WAPI* и т.д.

Довольно частые вопросы на форумах и в сети SCN выглядит так: Какая таблица содержит значения рабочего процесса контейнера? У кого есть пример кода для функции SWE_EVENT_CREATE? Ох, ах и ого-го(1) уж эти абаперы. Запомните, разработчики не должны разбираться с внутренностями функциональных модулей SAP или таблиц для Workflows, так как функции и таблицы могут быть изменены в любой момент при очередном обновлении, а это означает, что ваш код может перестать работать.
 
Вместо этого, используйте вызовы WAPI. Это эквивалентно BAPI интерфейсам SAP, но для Workflows: это набор функциональных модулей, которые обеспечивают интерфейсы взаимодействия с подсистемой Workflows и который гарантированно не изменятся в будущем. Например это модули типа: SAP_WAPI_CREATE_EVENT, SAP_WAPI_READ_CONTAINER, SAP_WAPI_GET_WI_AGENTS.


9. Не уделяют достаточно информации в текстах WorkItem.

Рабочая задача должна содержать в своем тексте максимальную информацию для принятия решения пользователем. Например если это утверждение отпуска материала, то наверное не плохо было бы сообщить в тексте отпускаемое количество и возможно запас на складе отпускаемого материала на момент создания события или же количество уже проведенных отпусков за период.

Хороший текст задачи (WorkItem) содержит все - да все что необходимо для принятия решения. Пользователю не нужно никуда идти или нажимать кучу кнопок для получения дополнительной информации. (Совет: используйте webdynpros, которые позволяют делать более проще варианты предоставления информации).

Максимум если невозможно предоставить нужную информацию, постарайтесь предоставить хотя бы гиперссылки на все соответствующие бизнес-объекты. Это означает, что информация становится доступной в один щелчок мыши.

К сожалению гораздо чаще текст WorkItems, это образец телеграфного стиля, содержащий тексты вроде: "Пожалуйста утвердите запрос # 45 для USRICKB". Бедные пользователи им приходится переворошить кучу информации, чтобы понять что же это за запрос 45 и нужно или нет его утверждать.


10. Согласие на разработку пользовательских отчетов для контроля за работой Workflow.

Это одна из частых проблем при работе с пользователями. Звучит так: "Мы используем Workflow, все замечательно, но основная проблема теперь это отсутствие надлежащих отчетов для работы с задачами рабочих процессов."

Почти в каждом проекте, менеджеры запрашивают Z-отчет , через который они бы могли отслеживать ход скажем процессов утверждения заказов на закупку PO. Они хотят знать: кто из пользователей в текущий момент времени получил заказа в свой почтовый ящик? Как долго заказ уже лежит в почтовом ящике пользователя и т.д.
 
Если вы, как разработчик Workflow, пойдете на поводу у менедежеров, то скоро погрязните в этих просьбах, и все что вы будете делать это обновлять кучи Z-таблицы в различных BADIs, для хранения информации в затребованных ракурсах. Задумайтесь то ли это, к чему вы стремились когда решили заниматься Workflow.

Нужно стараться отказать в таких запросах и продемонстрировать, что все, в чем нуждаются менедежеры, покрывается стандартными отчетами GOS, SWLO, SWI1, SWI2_FREQ и (для более подробного анализа), BI. Этих отчетов должно быть достаточно для получения любой информации по рабочим потокам системы.

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 762
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
По поводу 8 пункта и примечания про: Ох, ах и ого-го(1) - так это из анекдота, типа жили три абапера в одной компании, одного звали Ох, он вечно нудел, ругал написанный чужой код, полученные спецификации на разработку и вечно был все недоволен, второго звали Ах, этот со щенячьим восторгом хватался за любые разработки, все переписывал, кучу всего не дописывал, но был рад жизни, на у третий Ого-го, просто нравился женщинам.

Оффлайн NachDenken

  • Newbie
  • *
  • Сообщений: 158
  • Репутация: +9/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
пункт 1 абсолютно верно.
3. называется "эффект золушки" :)
5. миновала сия печаль
6. можно запустить событие, а не сам поток.
7. абсолютно верно, кому-то поглядывать за потоками нужно, желательно не разработчик или консультант, а пользователь .
от себя хотелось добавить
когда создаешь свой поток, ну скажем на своем классе, делаешь связку контейнеров между задачами, атрибутами класса, меняешь, удаляешь, добавляшь часто бывало так что не работает, что где потерялось по дороге не понятно, делаю так удаляю весь поток, делаю заново с чистого листа, уже с правильными последовательностями шагом, атрибутов и передачи контейнеров событий и оперций между собой.