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

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

VirVit 4 комментария
  Заметки на полях
Здравствуйте все.
Традиционно миграцию данных выполняют классическим способом – файлики, 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 можно запланировать как фоновое задание, то получается гибкий инструмент для загрузки файлов любого формата без участия человека или регулярной миграции данных между системами. И совершенно бесплатно.

Я тут!

VirVit No Comments
  Заметки на полях

Друзья! Я не пропал, я тут! У меня скоро старт двух проектов одновременно, поэтому нет времени на мыслеизлияния. В середине июля я планирую поделиться большим количеством вкусняшек, про которые не расскажут в Интернете. Про миграцию, про интеграцию, про автоматизацию, про США, про ням-ням-ням… Извините, старого, пока со временем туго. Я про вас не забыл, про каждого помню 🙂 И спасибо, что добавляетесь в подписчики, в друзья на странице Facebook, что делаете репосты! Я все это вижу и ценю.

 

СПАСИБО!

Выгружаем значения варианта отчета

VirVit No Comments
  Заметки на полях

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

Для этого используем функциональный модуль RS_VARIANT_CONTENTS_255. В некоторых системах это ФМ RS_VARIANT_CONTENTS. В SE37 запускаем его по кнопочке F8. Заполняем поля REPORT и VARIANT.

На выходе в таблице VALUTAB можно увидеть все сохраненные значения в варианте для всех полей. По имени поля можно быстро найти нужные значения. Осталось выгрузить эту информацию в Excel и обработать напильником.

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

Эффективная настройка SAP ALE

VirVit one comments

  Интеграция SAP

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

Знаете две проблемы с транзакцией PFAL? Первая заключается в том, что PFAL не умеет отправлять уже уволенных физлиц, так как работает на логической базе PCH (есть нота с решением). Вторая, что при попытке отправить всю оргструктуру по пути анализа O-S-P бараны перемешаются с апельсинами и в принимающей системе будет каша. Для этого делают всякие изощрения вроде того, что нужно сначала переслать только объекты организационного менеджмента, затем соединения между ними, а потом уже табельные номера слать. Тогда система получатель корректно примет данные и создаст последовательно. При этом фоновые задания для отправки данных планируются в такой же последовательности, когда нам нужно ежедневно передавать изменения между системами. Сегодня мы научимся эффективно решать эти вопросы с помощью простых настроек SAP ALE.

Куда развиваться стажеру в SAP

VirVit No Comments
  Вопрос-ответ

Вопрос:
Подходит к концу год работы в компании *** в качестве стажера, успел понастраивать систему, побывать в качестве консультанта на боевом проекте.

И вот у меня встает выбор, в каком направлении дальше развиваться: уйти в зарплату или в расширку на SF, меня больше привлекает SF, т.к HCM практически у всех стоит, проектов на рынке по базе уже практкически нет, слышал, что на западе активно внедряют SF и скоро, в теории, должно и до нас дойти + можно попробовать свои силы за границей. Или полностью сменить модуль на MM/SD, очень много вакансий и не привязан к российскому законодательству

Очень хотелось услышать твоё мнение, буду очень благодарен.

Ответ:
Скажу так. На самом деле на Западе, где я сейчас обитаю, есть спрос на SD и MM. Но он точно такой же, как и на все остальное, “популярное”. Специалисты нужны везде, хотя и сложно пробиться в люди. Если ты начал работать в HCM и это не вызывает у тебя отвращения или скуку, то нет смысла менять на другой модуль. Там все тоже самое, что в HR, только в другой предметной области. Не сегодня так завтра будет свое облако, и все побегут в него под прицелом вендоров.

Насчет того, куда бежать внутри HCM я много писал здесь, в блоге, размышлял. Более того, я сам примерил на себе этот SF, стоимость его изучения, применение. Мозгами я понимаю, что в классике скоро делать будет нечего. Все уйдет в облако. Из похожего останется только зарплата, так как сап ее не меняет с переходом в облако. А душа все же лежит в классике. Ну вдохновил меня SF вообще ни разу. За эти два десятилетия развития продукта я ожидал чего-то большего как для пользователей, так и для консультантов. Банальный Learning Hub от SAP на SF и тот же Coursera, UDemy, Linda – ну две большие разницы. От LH Тошнит, а на курсере хочется учиться. В uTunes я с удовольствием проходил курсы по IOS и Swift, а к сертификации по SF готовился с напряжением.

Для тебя я, для всех, кто еще не умер в классике, только начал свой путь в сап я сегодня говорю одно – если есть возможность и реальный проект, то идите в SF. Если нет, то все равно куда, хоть на кудыкину гору, собирать одну помидору. И второе, что никто все равно не слышит и не слушает, это изучайте программирование и современные технологии на уровне Advanced User. Не будьте индусами…

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