Уважаемые эксперты, помогите пожалуйста разобраться!
Мы широко используем транзакцию HRPADRUT7RUN для настройки наших отчетов, в нашей продуктивной и тестовой системах мы можем вносить изменения в настройки без сохранения изменений в запросе переносов (transport order). Это, конечно, очень удобно и быстро, но в результате наши системы не синхронизированы и в каждой системе разные настройки. И у нас возникает вопрос: это так изначально задумано САПом или это в нашей компании мы что то подкрутили в транзакции? к сожалению, система у нас уже существует несколько лет и первичные настройщики уже не работают в нашей компании, так что невозможно сказать с точностью, когда и что было изменено.

а у вас как работает эта транзакция? вы тоже можете изменять настройки в продуктиве?
с уважением
Наташа

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

У нас тоже можно менять в продуктиве.

О! И у нас можно, а я до этого не знал, запросами носил. Но думаю запросами все таки практичней, чтобы настройки идентичны были всегда.

Спасибо за ответы
да, абсолютно согласна с тем, что это настройки и все таки настройки должны сначала в разработке настраиваться, а потом уже запросами переноситься в тест и продуктив
у нас действительно часто получается, что настройки разные между системами и при дебаге разные результаты, приходится выравнивать
все таки это изначально САПом так задумано?
с уважением
Наташа

Согласен с msv. Нечего в проде настройки трогать!

Многое зависит от того, в каком состоянии находятся данные в тестовых системах. Если в них не представляется возможным протестировать тот или иной отчет, то нет смысла "тягать" это всё запросами. К тому же в некоторых "бюрократизированных" конторах время на перенос не соизмеримо с временем, потраченным на выполнение настройки.
К тому же отчетность формируется не за 2 минуты.
Если нужна историчность, то вроде как ничего не запрещает включить логирование на таблицу в продуктиве, и уже потом анализировать изменения.
ИМХО конечно же))

И это правильно. Для бизнеса правильно.

Оно то правильно для бизнеса конечно, но главное тогда самому не забывать настройки сделанные в проде повторять в деве и квалити а то ж все разъедется огого

Изменения, кстати, не обязательно вручную повторять в других системах. Можно обычный запрос на перенос сделать. Тем более, что в HRPADRUT7RUN кнопка "Транспорт" вынесена прямо на панель.
Делаем настройки в продкутиве, параллельно жамкаем "Транспорт", изменения фиксируются в запросе. Потом запрос деблокируем и переносим "против течения" - из продуктива в тест и разработку.

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

Ни когда на практике такого подхода не встречал. Даже наоборот, в некоторых "бюрократизированных" конторах выполнить этот маневр физически не удастся - против правил не попреш, и это правильно.
Я могу представить себе такую ситуацию если в системе клиент один, и всем сапом этого клиента заправляет его же ИТ отдел, тогда да - нет ничего невозможного! Но в случае сложной архитектуры системы, когда на одной инсталляции крутиться несколько клиентов в нескольких странах - подобное может иметь неприятные последствия, поэтому как правило запрещено.

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

Актуальность данных в тесте накладывает требования на полномочия, аналогичные продуктивным, иначе бизнес "закипит", либо же делать "грамотное" обезличивание, но это уже совсем в сторону от темы .

Уф.. Я уж думал одному мне это показалось кхм... странноватым
Я про такой манёвр только тут услышал

Я понимаю, когда есть определенные правила переноса изменений настроек из системы разработки (читай "грязной" системы) в систему продуктива (читай "чистая" система). Но какие могут быть вопросы к переносу настроек из "чистой" системы в "грязную"?
Например, я обнаружил что в системе разработки повреждены/испорчены какие-то настройки. Я хочу их восстановить используя в качестве основы проверенный экземпляр - продуктивную систему. Модифицируемая при этом система - это разработка. У вас есть правила, которые ограничивают изменения в разработке?

Вы устроились в компанию, вам дают задание перенастроить какую-то подсистему. Начиная работать, вы обнаруживаете, что в среде разработке настройки не совпадают с продуктивной системой - кто-то что-то настраивал и бросил. Концов не видно. Поэтому первом шагом будет привести систему разработки к работающему в данный момент виду. Продуктив хороший кандидат для этого.
Можно делать настройки ручками, глядя на продуктив глазами. А можно просто скопировать настройки из продуктива. Например, в SM30 есть для этого специальная опция сравнения. В HRPADRUT7RUN такой опции нет, но есть возможность включить данные в запрос.

RoustR
Не спорю, описанная Вами ситуация имеет место быть. Но все же - источник расхождения данных разный. В приведеном последнем примере - это незаконченная работа в "грязной" системе, системе разработки. Ситуация описанная natachalek в первом сообщении - это внесение изменений в настроечную таблицу минуя "грязную" систему разработки сразу в "чистую" продуктивную систему. Она "чистая" потому что по идее все изменения в неё носимые должны быть тщательно оттестированны, и следы этих тестов тоже должны быть в наличии. Иначе, как Вы правильно написали ниже, мы получаем следующую ситуацию:

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



Увы, таких правил множество.