Суть: стали мы спорить, использовать ли ЛБД HRные или нет, т.к. САП везде пишет что лбд устарели. Есть доводы за, есть доводы против, хочется услышать ваши мнения.

Итак, было сказано за:

1. селекционный экран
2. полномочия
3. выборка данных

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

Против - SAP пишет что лбд устарели
https://help.sap.com/doc/abapdocu_752_i ... benldb.htm

геморрой при проверке кода автоматическими инструментами типо SLIN SCI
устаревшие операторы типо infotypes, устаревшие макросы
и что это из мезозоя

т.к. я тоже уже из мезозоя, хочу узнать ваше мнение

А сам SAP произвел какие-нибудь отчеты по HR, которые выполняют выборку ТН, и которые не используют ЛБД? Я что-то не заметил (пока не касался элект.труд.книжки, может быть там?) . Вроде как все стандартные отчеты в HR построены на ЛБД.
Мало того, SAP даже развивает этот инструмент. Например, ввел опцию "Области отчетности", которая прямо встроена в ЛБД. И это было совсем недавно.

да, я тоже такой довод приводила, но тем не менее... САП пишет устарело, все проверки пишут устарело.

Опять же если хочется выборку побыстрее надо хану

сап анонсирует с одной стороны S/4 HR, но при этом говорит что только в части интеграции с остальной S/4... Будет ли какое-то решение с ханой вместо логических баз, или в ядре какой-то новой логической базы - непонятно.

Если смотреть чисто технически на наши лбд, то все что есть в селекционниках лбд это просто ограничения для 0001 инфтипа. Оно ж как там внутрях: берет все от селекционника, натравливает это тупо селектом на PA0001 и потом к каждому ТН применяет полномочия + ограничения по периодам и далее уже ограничение по 0000 ифотипу + динамические ограничения.

Все это добро потом из внутренних таблиц лбд через PUT PERNR выдается в событие GET PERNR. Скорее всего по этому и говорят что устарело, а если нужно быстро выбрать табельные, то используйте хану а далее читайти инфотипы декоплед фреймфорком, который: а) буфферищируем б) итает то что надо в) проверяет так же все полномочия и типа всем счатье.

В последнее время в Z* программах часто вижу что в get pernr копят список ТН для отчета, и потом в end-of-selection кидают обработку их где все равно читают нужные инфотипы.... где в этом случае профит, кроме лбд-селекционника ума не приложу

Только читают они довольно оптимизировано и вроде как даже чего-то буферизируют.
ИМХО, ЛБД это выделенный программный блок отвечающий за определенные задачи.
Если все писать самим, то все будут приходить к аналогам ЛБД (какие-то блоки, решающие такие же задачи).
Мне кажется, лбд могут устареть только в конктексте переориентирования сервисов на фронт энд... Там - да, каждый уже свои морды рисует или вовсе юзает какой-нить Employee Central. А в контексте бекэнда, лбд крайне удобная, полезная и до сих пор актуальная штука.


Если просто напихать в GET ТН и обработать их в EOS, то это извращением попахивает)
Скорее всего, так делают для параллелизации: в GET формируют перечень ТН, удовлетворяющих условиям СЭ, а в EOS разбивают весь пул на пачки и отдают фоновым заданиям, а итог фоновых прог собирают в общий отчет.