Я вам этого не говорил, не писал, мы друг друга не знаем. Этот блог ведет аноним.
Теперь о серьезном. IDOC вы уже знаете, настраивать и запускать в космос тоже умеете. Работать с LSMW учили еще в начальных классах. Мы же не в США, вы точно должны это все знать.
Если скрестить эти две технологии, выключить голову, то можно сделать нечто страшное. Мы ранее учились использовать LSMW для создания IDOC. В некоторых случаях этот подход позволяет очень эффективно изменять данные и делать это быстрее, чем через пакетный ввод. Как и у любой технологии, есть отрицательная сторона.
Представьте, что мы записываем LSMW для формирования IDOC с HRMD_A. У нас есть родительский сегментик, есть сегменты с инфотипами — все просто и логично. В родительском сегменте есть такая штука как операция E1PLOGI-OPERA, которая может принимать значения D — Delete, I — Insert, U — Update.
При получении IDOC система смотрит на статус. Если буковка D или I, то выполняется полное удаление всего объекта. Неважно что лежит ниже в сегментах с инфотипами. Просто вызывается ФМ CALL FUNCTION ‘RH_DELETE_OBJECT’, куда передаются тип объекта и его идентификатор.
Когда мы пишем LSMW, то можем в силу человеческого фактора забыть, что I — Insert в области IDOC трактуется как «Удалить и создать», а не просто «Создать» новую запись инфотипа. Для нас логично, что «создать» означает создать новую запись инфотипа, который мы загружаем. Но САП он САП со своей лучшей практикой.
Так вот, если вы записываете LSMW по созданию записей ИТ через LSMW, укажите в операции буковку I (Insert), а потом без задней мысли запустите эти IDOC на обработку, то система молча удалит все табельные номера или объекты оргменеджмента в зависимости от того, что вы загружаете.
Это произойдет молниеносно, без возможности отката и записи в журнал аудита, без проверки полномочий (IDOC обычно под суперпользователями запускаются). Все что можно увидеть, это журнал самих IDOC.
И ЭТО ОЧЕНЬ ОЧЕНЬ ОЧЕНЬ опасно. НИКОГДА ТАК НЕ ДЕЛАЙТЕ. Автор сего опуса ответственности за ваши действия не несет, даже не просите.
Решения есть два:
Привет, други и подруги.
В EhP5 появилась новая транзакция для работы с IDOC — WLF_IDOC. В какой-то версии (в EhP 3 вроде) появилась транзакция WLFEIR. Внешне выглядит простенько, удобненько, но дьявол кроется в мелочах.
Транзакции совмещают множество инструментов обработки и мониторинга IDOC в одном месте с удобным интерфейсом. Теперь стало можно искать IDOC по содержимому прямо здесь.
Можно сравнить два IDOC по содержимому каждого поля. Выделяем два IDOC и нажимаем кнопочку сравнения.
Поменять статус IDOC — пожалуйста, кнопочка в тулбаре.
Запустить обработку последовательно, параллельно — закладка Background Processing. Хотите получить в логах сообщение об успешной/неуспешной обработке IDOC — доступна функция Monitoring.
Про настройку ALE мы немного уже поговорили в прошлый раз. Теперь обсудим возможности этого самого ALE, а в будущем и интеграции. Сегодня я разбираюсь в преобразованиях в ALE, которые позволяют на лету менять данные по заранее определенным алгоритмам.
Часто преобразования нужны в гетерогенных средах, где присутствуют различные системы по своим настройкам, типу или архитектуре. Например, вы включаетесь в новый ландшафт, где уже есть свои коды балансовых единиц или табельных номеров, а в вашей системе своя кухня. Или вам нужно передать дополнительный признак в зависимости от тех или иных условий в стандартных полях IDOC. Посмотрим на возможности преобразования данных.
Вся настройка преобразования IDOC в ALE заключается в трех простых пунктах меню в IMG. Запускаем транзакцию SALE и спускаемся до нужных нам настроек.