Добрый день, уважаемые коллеги!

Был выполнен перенос Z-класса. Предварительно протестили конечно.
В продуктиве дамп - отсутствует реализация одного из методов Причем, объявление этого метода имеется, в SE80 доступно.
В разработке реализация метода, разумеется, имеется, активирована.



Подскажите пожалуйста, как можно получить такой эффект? Каким образом можно потерять реализацию метода ??

Такое может быть, если выполнялись различные махинации с запросами на перенос.
Например, объявили метод в одном запросе. А тушку - впихнули в другой. Объявление метода относится, в части переноса, к соответствующей секции запроса. А тушка - она может и сама по себе переезжать.
А может быть и покруче вариант: пропустили какой-то запрос. Сейчас едет запрос с секцией, о теле метода он ничего не знает.
Т.е. на самом деле, нужно смотреть в ошибочном запросе, что же именно вы переносили, и сопоставлять с данными в системе разработки.

Спасибо за мнение

Посмотрите историю переноса запроса в управлении версиями для реализации метода. Этот запрос могли забыть перенести.

Спасибо.
Наверное, действительно какая-то путаница с запросами и последовательностью переноса.

Я уже несколько лет пользуюсь принципом - вся разработка в одном запросе. Т.е. после каждого деблокирования и переноса я создаю новый запрос и первым делом копирую в него объекты из предыдущего запроса. Подобные проблемы с переносами практически исчезли.
В своих разработках вообще получается, один запрос - один пакет (класс разработки). Очень удобно, особенно при переносах в другие системы разработки. Заодно дисциплинирует, приучает к более осмысленной структуризации разработок и созданию пакетов.

Имхо перебор, особенно для больших разработок.
Для каждой разработки делаются свои объекты словаря данных?

Я тоже так думал, пока не начал пользоваться. Это надо примерять не на существующий бардак, а как повод и способ навести порядок. Само понятие "большая разработка" уже повод задуматься и разбить её на более-менее независимые части. И руководитель мой (ты его знаешь ) тогда оценил подход, потому что проблема реально исчезла.
Для каждой разработки создаются соответствующие по смыслу только ей объекты словаря данных. При переносе разработки целиком проблем с использованием этих объектов словаря в других разработках не возникает.
Фактически лучше относиться к ним, как к публичным типам классов, или просто пользоваться типами классов. Я бы только так и делал, если бы не заморачивался совместимостью с 4.6C - там в классах нет публичных типов.

Parazit, приветствую Несколько вопросов:
При таком подходе, устраивает не нужная итерация версий объектов со всеми вытекающими?
Как работается если существует большое изменение в разработке и параллельно необходимо накатить какую-нибудь мелочь на туже разработку другим программистом например, ну или одним и тем же?
Так же открытые вопросы, как смотрит на это базис, таскать 90%(например) содержимого запросов без нужды? Не будет ли это все перегружать процесс при каком-нибудь внедренном инструменте инспекции кода?

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

Поскольку все объекты разработки уже включены в запрос, то все их изменения другими программистами автоматически попадают в него. Если нужно срочно что-то доработать и перенести, то мы создавали отдельный запрос, вручную включали в него нужные объекты и переносили. Главное в этом подходе, что таким случаям уделяется должное внимание и делается осознанно.
С версиями никаких проблем не замечал. К тому же в период активной разработки проекта с высокой вероятностью изменяются почти все объекты. Кстати транспортная система SAP не такая уж тупая. Если, например, структура таблицы БД реально не изменялась, так она при импорте и не будет с ней ничего делать.
Базису, честно говоря, вообще пофигу что мы там таскаем, лишь бы ничего не падало. Тем более, что им наш подход сокращал проблемы.
К тому же не надо переоценивать объём разработок, даже все разработки крупной компании за все годы использования SAP весят всего несколько десятков мегабайт ZIP, без данных разумеется. А уж отдельная разработка или даже целый проект - вообще копейки. Ну переносится запрос чуть дольше на несколько минут, это не идёт в сравнение с обычными организационными проволочками и вознёй в случае импорта с ошибками.

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