Добрый день!
Имеет система SAP ERP 6.0 с кучей всяких непонятных пользователей, а так же джобов.
Планирую создать одного пользователя и начать переводить фоновые задания на него. Первым делом начну переводить джобы базиса. Так же хочу чтобы текущий одминский пользователь был безличным, например, admin, а для фоновых заданий, например, BTC.

Вопрос следующий:
1. Из опыта, для фоновых заданий лучше создать пользователя с типом System или Service?
2. Так же из опыта, создать пользователя в продуктивном манданте или в 000?
2. Существуют ли какие-то стандартные минимальные роли\профиля для этих целей? (за исключением SAP_ALL, S_A.SYSTEM, S_A.ADMIN) Или же лучше смотреть что будет выполняться от этого пользователя и копировать для него стандартные роли?
3. И на вопрос заказчика - А как он будет использовать пользовательскую лицензию? Как это повлияет на измерения отчёта USMM? По вопросам лицензий я не особо силён и не знаю как будет использоваться лицензия

Насколько знаю, при произведении контрольного измерения считаются только диалоговые пользователи, а технические исключаются.

Communication 'C'
Use users of type Communication for dialog-free communication between systems (-> RFC or CPIC) .

Dialog logon (using SAP GUI) is not possible.

The general settings for the validity period of a password apply to users of this type. Users of this type can change their passwords (like dialog users). The dialogs for changing the password must be provided by the caller (RFC/CPIC client). You can use the RFC function module USR_USER_CHANGE_PASSWORD_RFC or the RFC API function RfcOpenEx() to change the password.

Service 'S'
A user of the type Service is a dialog user that is available to an anonymous, larger group of users. Generally, this type of user should only be assigned very restricted authorizations.

For example, service users are used for anonymous system access using an ITS service or a public Web service. Once an individual has been authenticated, a session that started anonymously using a service user can be continued as a personal session using a dialog user (see SUSR_INTERNET_USERSWITCH)

During logon, the system does not check for expired and initial passwords. Only the user administrator can change the password.

Multiple logon is allowed.

Мне кажется не обойдется одним bg-пользователем. В одних ждобах нужны будут одни авторизации, в других - другие.

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


Какого? для фоновой обработки? Если да, то в продуктивном! в 000 не стоит создавать никого кроме как Админа



Существуют! Смотря какие операции будет выполнять этот пользователь! А вообще, рекомендую поковырять в сторону профилей S_BTCH_ADM BC полномочие на фоновую обработку (администратор)
А так же RFC и тд, в зависимости от потребностей



А никак. Подлежат измерению только Диалоговые пользователи

Я выбрал специально два типа пользователей System и Service по одной важной причине - на них не действует политика смены пароля:
- Под пользователем System нельзя логиниться в диалоге
- Под пользователем Service можно логиниться в диалоге
Да и как-то читал что САП рекомендовал всех пользователей с типом Communication перевести на System.

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

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

Prometheus, если решил взяться за приведение фоновых заданий в порядок, рекомендую посмотреть в сторону Job Management функциональности в Solution Manager

Skif, ну тогда, как вариант, буду думать об использовать несколько учётных записей. В случае блокировки одной не останавливались другие процессы.

Ludens, не смогу применить его пока не дадут добро на обновление, настройку СолМан системы. Хотя это совсем глупости в сравнении с тем что у данного клиента ещё нет договора на тех.поддержку и соответственно maintenance лицензии ))))

не дрейфь - многие так начинают

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

Skif, я не отрицаю силу СолМан и его функционала. И я принимаю его веру. Однако, к сожалению, сейчас мне надо воспользоваться тем функционалом который я имею ))))

а про солман и речи не было. всегда говорил, что солман смысл есть задействовать серьёзно при, как минимум, 2-х полных (3-х системных) устоявшихся ландшафтах.
о фоновых юзерах и соответсвующих ролях обычно для каждого функционала идёт security guide - полезная подробная дока.