Коллеги, доброго времени суток.

У нас появилась нестандартная задача. Необходимо раз в сутки деблокировать и переносить запросы на настройку в автоматическом режиме.
Проблема заключается в автоматическом деблокировании. Кто-нибудь знает, можно ли это решить стандартным функционалом или же придется писать отчет для деблокирования?

Такого функционала нет, придется абапить, но на мой взгляд сама постановка вопроса не имеет смысла... Кто поручится, что все настройки и разработки из открытых запросов завершены, как вы будете разбирать ошибки, например, объект в запросе не активен и пр...???

автоматическое деблокирование ?
я конечно извиняюсь, но это идиотизм...

Во всем есть смысл, если это оправдано

логика TMS к чертям
безопасность к чертям
консистентность к чертям

зачем ставить SAP?

Есть хорошее решение.
Ведите настройки и разработки непосредственно в продуктиве.
Эффект такой же, а геморрою с переносами на порядок меньше.

Этот топик надо признать как вредоносный и стереть.

Оффтопик он:

Оффтопик офф...

Я говорил исключительно про настроечные запросы. Имелось в виду автоматические переезды не из системы разработки в продуктив, а между продуктивными системами. Например, различные справочники названий подразделений и т.д. переезжают в настроечных запросах и мы как разработчики никакого отношения к этим справочникам не имеем. Такие справочники ведутся в ландшафте продуктивных систем.
И как оказалось, в стандарте есть функционал групп распределения (ведется через BDXJ). Смысл заключается в том чтобы найти в существующих запросах объекты из группы распределения и сформировать новый запрос для автоматического переноса, включив в него копии найденых объектов. Эту работу делает отчет RBDCUS44, сформированные им запросы обычно имеют префикс ">>ALE Customizing<<". После формирования, сервисный запрос деблокируется и встает в очередь на импорт в системе назначения. На принимающей стороне необходимы два отчета: RSTMSTIQ - для выравнивания очереди импорта и RBDCUS47 - для установки запросов. Чтобы на принимающей стороне были установлены только "нужные" нам запросы, туда пересылается IDOC с номерами запросов для установки. Вот так, никаких нарушений безопасности и ошибок не возникает.

Как показывает практика, более 90% вопросов по нестандартному решению является неполной информированностью о стандартном функционале, присутствующем в системе.
Увы. И это относится к любому функциональному модулю.

Более того, 80% из этих 90% зачастую не про то, о чём в действительности хотел бы услышать ответ автор вопроса.

вроде для этого есть Master Data Management

А вот интересно, про запросы - у вас продуктив открыт, что ли, каким образом "создаются запросы"?

У нас распределенный продуктив, есть одна центральная система и один филиал. Все справочники и настройки ведуться в центральной системе и едут в филиал. Всё добро переезжает исключительно в настроечных запросах. Запросы создаются точно так же как в системе разработки, с одним лишь исключением - никто не ведет разработку в продуктиве . Понятно что это странный подход и по хорошему всё это должно пересылаться посредством IDOC`ов, пока это сделано только для пересылки документов. Но в таком подходе есть один плюс - быстро и просто реализуется в условиях острой нехватки ресурсов .



Спасибо, я про такой функционал не знал. попробую разобраться.