Настройка часового пояса в SAP

В 2011 году в России был отменен переход на зимнее время, в результате чего у администраторов резко прибавилось страхов и головной боли. Я освещал эту проблему в одноименном посте, в котором я описал процедуру настройки отключения автоматического перехода на зимнее время для операционных систем и SAP системы.

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

Существует так называемое всемирное координируемое время (UTC), которое является стандартом и от которого настраиваются часовые пояса, в большую или меньшую сторону. Если кто-то помнит, то раньше в качестве такой точки отсчета использовалось время гринвичского меридиана или время по Гринвичу (GMT).
Часовые пояса зависят от географического положения города/страны (рис. 1).

Рис. 1. Локальное время в разных часовых поясах.

Общая транспортная директория в среде Windows

Про транспортную систему в своем блоге я упоминал в паре постов: блокировка транспортной системы и решение проблем с транспортной системой. Транспортная система или Transport Management System (TMS) это система, обеспечивающая построение, так называемых, транспортных ландшафтов SAP систем, когда несколько систем одного назначения/версии объединяются для настройки/обеспечения контроля качества/поддержки того или иного решения компании SAP. В идеальной ситуации в ландшафт объединяются 3 системы: система настройки и разработки (DEV), система контроля качества или тестовая (QAS) и продуктивная система (PRD). Перенос настроек и разработок производится с помощью запросов на перенос (transport request), которые обычно "бегают" по пути, преднастроенному администратором системы. Типичный путь для запросов на перенос: DEV -> QAS -> PRD.

Если посмотреть на транспортную систему с более низкого уровня, то организована она с помощью транспортной директории (/usr/sap/trans) и набора утилит (R3Trans, tp). Опять же в идеальной или типовой ситуации, транспортная директория это общая директория для всех систем ландшафта (рис. 1). Данная директория содержит набор поддиректорий, которые хранят настройку транспортной системы, файлы запросов, журналы, буферы очередей систем и так далее. Стоит еще упомянуть, что транспортная система используется не только для переноса запросов на перенос, но и почти для всех манипуляций с базой данных такого вида, как, например, обновление системы с помощью пакетов поддержки, установка и обновление дополнений (ADD-ON), установка дополнительного языка в SAP систему. Для всех этих операций нужна активированная/настроенная транспортная система (TMS).

Рис. 1. Транспортный ландшафт и транспортная директория.

Рассмотрим ситуацию, когда SAP системы используют в качестве платформы операционную систему MS Windows. Транспортная директория создается на сервере одной из систем (обычно DEV, в идеале PRD). Данная система является контроллером транспортного домена, на котором производится настройка всей конфигурации ландшафта (транзакция STMS). К директории /usr/sap открывается общий доступ по сети с именем общего ресурса - SAPMNT. Таким образом, транспортная директория доступна по адресу:
\\<hostname>\sapmnt.

Если все сервера находятся в домене Windows NT, то с доступом к транспортной директории, открытой по сети, с любого сервера транспортного ландшафта проблем нет. 

Если же сервера не в домене Windows NT, то алгоритм следующий. На контроллере домена (в примере, сервер edu002) открываем файл hosts (путь C:\Windows\System32\drivers\etc\). Прописываем сервера всех систем из транспортного ландшафта (в примере, сервер edu005) (рис. 2).

Рис. 2. Файл hosts сервера edu002.

Там же открываем утилиту "Computer Management" и создаем SAP-пользователей операционной системы всех SAP систем транспортного ландшафта - <sid>adm и SAPService<SID> (в примере, et5adm и SAPServiceET5) (рис. 3).

Рис. 3. Создание SAP-пользователей в операционной системе транспортного домена.

Настройки и членство в группах аналогично пользователям системы ET2 (рис. 4).  
Пароли обязательно такие же, как и на родных системах (в примере, ET5).

Рис. 4. Настройки членства в группах новых пользователей.

Добавляем этих пользователей в настройки безопасности и открытого доступа для транспортной директории (рис. 5).

Рис. 5. Добавление новых пользователей в настройки безопасности транспортной директории.

Заходим на операционные системы других систем из транспортного ландшафта (в примере, edu005) и в файле hosts (путь C:\Windows\System32\drivers\etc\) добавляем запись о контроллере транспортного домена (рис. 6).

Рис. 6. Файл hosts сервера edu005.

Проверяем доступность транспортной директории на уровне операционной системы (рис. 7).

Рис. 7. Открытие транспортной директории с других систем транспортного ландшафта.

После этого можно приступать к настройке транспортной системы на уровне SAP (транзакция STMS).

Подробную информацию по транспортной системе можно найти в материалах курса SAP ADM325.

Автор: Шиболов Вячеслав Анатольевич

Ошибки и зависания в процессе деблокирования запроса

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

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

Для этого, как обычно, в транзакции SE01/SE10/SE09 встаете курсором на номер запроса и нажимаете кнопку "Прямое деблокирование" или выбираете пункт меню "Запрос -> Деблокировать -> Прямой (или Фоновый режим)" (рис. 1).

Рис. 1. Запуск процесса деблокирования запроса.

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

Это ни в коем случае не перечеркивает мой старый пост, так как ситуации, когда нужно изменить статус запроса бывают разные (например, удаление его и его следов из системы, что можно сделать только с не деблокированным запросом). К тому же в том посте была описана процедура перехода в режим отладки. :)

Автор: Шиболов Вячеслав Анатольевич

Дополнительный язык в SAP системе и пакеты поддержки

В посте "Установка дополнительного языка в SAP систему" я рассказывал о том, как в системах SAP осуществлена поддержка нескольких языков и о процедуре добавления дополнительного языка в систему.

Есть еще небольшой момент, про который я забыл упомянуть. Как вы помните, установка дополнительного языка осуществляется через импорт в систему языкового пакета, который содержит тексты для всех полей на импортируемом языке. Языковые пакеты распространяются через специальные Language CD, которые мы скачиваем вместе с установочными дисками SAP системы.

Но вы так же знаете, что ни один продукт не идеален, и компания SAP для всех своих продуктов выпускает, так называемые, пакеты поддержки (Support Packages) или просто патчи. Про это я писал в постах "Обновление системы на базе SAP NetWeaver 7.0", "Обновление системы на базе SAP NetWeaver 7.0: видео", "Загрузка пакетов поддержки". Так вот, пакеты поддержки помимо исправлений кода или объектов репозитария, могут содержать и исправления текстовых полей, а это уже пересекается с задачей локализации (импорта дополнительных языков в систему).

Правила при разрешении этих нюансов следующие:

1. Сразу после установки SAP системы импорт одного или нескольких языковых пакетов.
2. Импорт, вышедших после релиза SAP системы, пакетов поддержки.
3. Импорт языковых составляющих из установленных пакетов поддержки для дополнительных языков SAP системы.

Реорганизация SAP Office таблиц

В далеком 2010 году, написав вот этот пост, я рассказывал про SAP органайзер - SAP Business Workplace (транзакция SBWP), который позволяет хранить и отправлять документы по внутренней почте SAP системы (кстати, внешнюю почту тоже можно подключить к SAP).

Так вот, в прошлый раз я рассказывал про раскладывание писем по полочкам (по годам). В этот раз поговорим про другое. Если пользователи SAP системы активно пользуются внутренней почтой и отправляют по ней много вложенных документов, то некоторые таблицы в вашей базе данных активно растут. Например, таблица SOFFCONT1. Данная таблица как раз и хранит вложения из писем. Размер легко достигается нескольких десятков гигабайт. И оказывается, что когда пользователь удаляет письма, вложения из них спокойно могут продолжать храниться в этой таблице, занимая место и снижая производительность работы базы данных.

Существует ABAP-отчет RSBCS_REORG, который реорганизует таблицы (SOC3, SOFFCONT1, SOFM, SOOD, SOOS, SOST): анализирует на какие документы не ссылается ни одно письмо и удаляет эти документы из таблиц. На основном экране отчета можно указать период, документы за который обрабатывать (рис. 1).

Рис. 1. Указание даты создания документа.