Добрый день! Знающие люди, помогите!!! Как можно определить статистику на какие объекты и на какое время блокировал пользователь за последний месяц? На данный момент удалось понять только то, что можно увидеть какие объекты заблокированы в текущий момент и время начала их блокировки, но этой информации не достаточно.

ммм, цель какая? Просто интересно.
Поковыряйтесь в концепции https://help.sap.com/saphelp_nw70/helpdata/en/7b/f9813712f7434be10000009b38f8cf/frameset.htm, вообще постановка вопроса корректна?
Возможно стоит продублировать в базис ветку.

Видел вчера этот вопрос, попытался лазить.
Мне кажется, что там глухарь.
Слишком глубоко закопано. Уверен, что задача не решается. Точнее уверен, что такого рода инфа нигде не хранится. Попросту незачем.

Задание можно назвать творческим. Основная идея - собирать количество времени, которое разработчик тратит на разработку(субъективный показатель конечно, но все же) и в это время он блокирует объект разработки. Пользователь известен, в названии объекта разработки всегда содержится код разработки. Не хватает только временной начальной и конечной точки блокировки объекта.
Если такой информации нет, то как тогда ее возможно собирать?

По идее у этого механизма должен быть механизм трассирвки\логирования есть группа параметров *enq* в rz11. Попробуйте это дело включить и посмотреть что интересного в трэйсы сыпется. (но сначала у базиса спросите )

Постой-ка, брат Мусью!!! (с)
В начале темы был намек на SM12, это очевидно ведь, нет?
И Вы вставили свой вопрос в тему про блокированные объекты, и сами почти точно их и подразумевали.
А в итоге Вам нужна история блокирования объектов разработки (источники отчетов, ФМ и пр.), они с помощью этих средств не видны (в SM12).

Почему бы не измерять время работы разработчика не временем блокирования объектов, а временем между созданием и деблокированием инструментального запроса? Мне кажется, это более логично. Первую неделю ваш разработчик возился с одним объектом и держал его блокированным, а потом на 8 день включил в запрос 100 других объектов, с которых снял блокировку через 10 минут. После этого все утащил в тестовую систему. Как оценить "KPI" разработчика по данной задаче? Суммировать время для каждого объекта (получится ерунда же) или все же смотреть совокупное время начиная с первого объекта? Мне кажется, что явно первое. А историю работы с запросом достать куда легче, порыться чуток.

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

Очень приятна заинтересованность грамотных людей моим вопросом)

Именно поэтому аналог блокировки в SM12 и не подходит для решения Вашего вопроса, там же совсем другая концепция. Критерием того, что объект нельзя трогать другому пользователю, там является сигнал блокирования (запускается ФМ, который накладывает блок), который посылает транзакция, где данный объект открылся. По окончании работы блок снимется, другой пользователь приступит к работе. Процесс непрерывный, но блокирование объекта там измеряется секундами/минутами (для редких случаев часами, а в случае сбоя - днями и месяцами).
У объектов разработки специфика другая: начав работу с объектом, разработчик накладывает на него блок. Но окончанием работы с объектом служит не покидание этого объекта, а деблокирование запроса. Открыв документ в FB02 на редактирование, Вы легко его покинете, заполнив часть полей утром, а часть - вечером. Чистое время блокирования объекта составит, предположим, 3 минуты. Но, включив в запрос функциональный модуль, Вы его будете держать блокированным до тех пор, пока не деблокируете запрос. И если



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

Сдается мне, MaryI пытается разработать систему учета и контроля рабочего времени разработчиков на основе данных о реальном блокировании объектов разработки в системе. Если я угадал, то следующая итерация в войне "меч против щита" будет написание джоба прогерами, который буде произвольно лочить заданные объекты по расписанию

Согласен , что задача неочень тривиальная, и вряд ли имеет смысл ее искать по SM12 (отображает только текущие блокировки). Есть специальные инструменты для трассировки блокировок (первое что приходит на ум это ST05), но опять же ее имеет смысл ставить только с согласия базиса ну и конечно установив фильтр по интересуемой учетке.

Несогласен с утверждением, что блокировка имеет другую концепцию для разработок. Запись в таблице блокировок (SM12) все же создается (TRDIR)

С уважением,
Руслан

Согласен частично с MaryI, так как в одном запросе могут сидеть куча программистов.
но и смотреть по блокировкам тоже странно,
программист может открыть SE80 и пойти пить чай.
Ну или сидеть в другом окне

Ну да, разумеется, если открыть текст проги на изменение на экране, то запись будет, тут согласен. Я, конечно же, имел в виду блокировку объектов запросом.
Но в этом случае справедливо вот это утверждение:

Поэтому ни та, ни другая попытка не имеют под собой никакой почвы, вообще никакой, на мой взгляд. Невозможно измерить эффективность работы разработчика временем, которое он провел наедине со своим объектом Тут миллионы комбинаций. Открыл объект на изменение, а думал о другой... ну точнее о другом Или работал усердно над этой задачей, но объект не открывал на изменение. Как вообще это можно измерить? Только нормальным планированием, еженедельными статус-встречами и нормальным контролем качества.

+1
У нас был такой случай - до окончания тестирования 14 разработок, сделанных одним разработчиком, были не деблокированы 3 месяца.
Но все посчиталось очень просто - приходил на работу 3 месяца, предварительная оценка работ была 3 месяца.
Без планирования невозможно оценить работу разработчика.
Настаивать на блокировании объектов так же непродуктивно, как и считать затраченное время исключительно по времени создания/деблокирования запроса/задачи в системе разработки.

еще есть незаслуженно забытый метод, основанный на подсчете количества строк кода, выданных разработчиком

Приезжает блондинка в автосервис, говорит: "мотор стучит".
Мастер посмотрел, ударил куда-то молотком и говорит: "с вас 5 тысяч".
Блондинка: "Чего так много? вы всего один раз ударили!".
Мастер: "Ударить молотком- 100 руб. знать куда - 4900".

так и у меня как программиста часто бывает, проще накидать новый ФМ на сотню строк, чем найти и поправить 1 строчку в чужом коде, заросшим мхом.