Как быстро изменить содержимое поля инфотипа

Есть очень простой и быстрый способ изменить содержимое одного или нескольких полей. SE16N… Шучу.

Создаем LSMW, записываем изменение инфотипа следующим образом. В PA30/PP02 указываем точные даты начала и окончания (лучше конкретный день), что позволит нам выбрать именно ту запись, которую мы хотим обновить. При записи нажимаем кнопку копирования, а затем сохраняем. То есть мы копируем запись поверх себя.

Теперь, твик, чтобы не выгружать все поля, а изменить только нужное нам. На экране присвоения полей нашей записи нужно с помощью кнопочки Screen Field удалить все поля, которые мы не хотим изменить. В идеале должны остаться только поля, которые мы меняем. Тогда при выполнении пакетного ввода система поменяет только наше поле, а остальные останутся без изменений, так как мы записывали “Копирование”, а не “Создание”.

На обновление 1 поля для 6к сотрудников только что ушло 10 минут (с подготовкой файла и записью LSMW).

LSMS Delete Screen Field

LSMS Delete Screen Field


Миграция данных с помощью SAP ALE

Здравствуйте все.
Традиционно миграцию данных выполняют классическим способом – файлики, LSMW, загрузка. Вариант классический, опробованный, рабочий. Чтобы не было скучно, мы решили пойти другим путем и провести миграцию данных с помощью SAP ALE. У подхода оказались интересные нюансы и преимущества перед традиционной миграцией. Стоит сразу же отметить, что слабонервным и начинающим подход противопоказан ввиду высокого порога вхождения в технологию.
Чтобы перенести данные с помощью ALE нам нужно настроить модель распределения, где указать откуда, куда и какие данные мы собираемся переносить. Это все делается в BD64, где сложностей не возникает.
Нам нужно использовать стандартный IDOC HRMD_A, если этих данных достаточно, либо расширить его своими инфотипами. Первые расширения IDOC обычно идут сложно, зато потом одно удовольствие клепать то да се. Для расширения концептуально мы создаем новые сегменты и прописываем их в наше расширение (WE30, WE31). Не забываем указать эти сегменты в T777D для каждого инфотипа.
Если нужно провести какие-то преобразования, то либо в правилах в SALE, либо в ФМ CONVERT*TO*, либо в CMOD/BADi делаем преобразования.
Делаем файловый порт источником данных и грузим апельсины бочками. Если нужно преобразования использовать для разных форматов файла, то идем в LSMW для обработки IDOC.
Звучит сложно, но только в первый раз. Взамен мы получаем отдельные плюшки в сравнении с LSMW.
  • Возможность на уровне системы управлять очередями и последовательностью загрузки данных
  • Возможность управлять производительностью. Да и сами IDOC грузятся намного быстрее, чем любая LSMW.
  • Легкий поиск ошибок, чего не скажешь про журналы LSMW.
  • Возможность поменять настройку и заново прогрузить тот же объем, что невозможно в LSMW (в большинстве случаев).
  • Возможность одним разом загружать данные в множество систем просто перенаправляя потоки данных в BD64.
  • Нет проблем с перезагрузкой данных, когда в LSMW нужно сначала удалять загруженные записи, а потом записать новые.
  • В случае миграции данных из “цивилизованной” системы, где есть возможности для интеграции, такая миграция может проходить практически в автоматизированном режиме (через файлы, веб-сервисы, OData или еще какие технологии).
  • Нет проблем с табличными инфотипами.
Но за сыр нужно платить. Плата заключается, как уже писал выше, в высоком пороге входа – надо много знать из технологии. Плюс, так как IDOC сохраняется напрямую в базу данных, но пользовательская логика для инфотипов не работает. Такие вещи приходится помнить и реализовывать в принимающей системе (например, вызывать те же функциональные модули прежде чем сохранить IDOC в инфотип).
LSMW, кстати, удобно скрестить с ALE как инструмент для быстрого преобразования практически любого текстового файла в структуру IDOC. Я писал ранее, как можно из файла формировать IDOC за считанные минуты. Если вспомнить, что LSMW можно запланировать как фоновое задание, то получается гибкий инструмент для загрузки файлов любого формата без участия человека или регулярной миграции данных между системами. И совершенно бесплатно.

Запускаем любой функциональный модуль с данными из файла

Это то, чего не хватает шаловливым ручкам, когда они чешутся. Удалые ребята хотят делать в системе какие-то вещи массово, которые сложно сделать через LSMW. При этом ключа разработчика у нас нет. Из банального пример, боль LSMW при миграции, так сказать, это загрузить данные из файла, а потом удалить. Мало ли ошибочно залили. Приходится писать отдельный проект для удаления. Плюс пакетник все же медленнее, чем ФМ работает.

Говорить мы сегодня будем опять про eCATT. Да, это не только средство для разработки тестов, но и неплохой скриптовый язык, который работает быстро, настраивается гибко и позволяет извращаться кто во что горазд.

Читать далее


Правила преобразования в LSMW

С базовыми вещами в рамках миграции данных мы все умеем работать хорошо. Мы знаем как записывать проекты LSMW, мы умеем использовать разные способы загрузки (BAPI, BUS, IDOC, Batch Input) – мы с вами большие молодцы. Сегодня мы чуть внимательнее посмотрим на возможности LSMW для управления данными во время миграции. Правила преобразования в LSMW нужны как раз для изменения данных из загружаемых файлов в целевые поля системы SAP.

SAP LSMW transformation rules

Читать далее


Революция в LSMW – вы этого не знали!

Классный заголовок? 🙂 Я точно не знал.

Есть у этой штуки скрытые другие штуки.

Вот такой пунктик меню скрыт врагами.

Если мы его запустим после конвертации данных, то система уже на этом этапе проверит ваши данные на предмет соответствия настройкам системы. Обычно мы запускали пакетник на выполнение, а потом в логах искали такие глупые ошибки. Вуаля:

День миграции данных это точно сэкономит.

А если вы приглядитесь, то в меню есть такой пунктик: Analyze Transactions with Errors. Он появляется в том случае, если загрузка данных идет не через IDOC. И это второй шедевр, который позволяет выгружать толпу ошибок и анализировать.