Да, всё верно.

Добрый день.
 
С точки зрения логистики, статья очень понятно написана.
 
Хотелось бы еще понять, особенности в финансах (есть ощущение, что там много подводных камней):
1) Какие проводки и в какой момент формируются стандартом?
2) Насколько они подходят/соответствуют требованиям большинства Российских компаний/РСБУ?
3) Если стандарт не подходит, то как на практике решается этот вопрос?
 
Думаю, что это тема для еще одной статьи, или Части III  :)

Привет, Вячеслав,
Хорошая серия и как раз вовремя.
Итак:"Приехала" SAP HANA 2.0 sps 02 "как есть", т.е. - Appliance - для экспириенса. Планируется миграция BW70(5Tb Oracle)->74->HANA . Дофига ес-но "Z".
Нужен совет - мигрировать или пробовать в варианте акселератор? Второй вариант мне нравится больше, т.к., имхо, позволит последовательно переводить отчёты в новую среду, не разрушая старой. Или эффекта не будет? (кроме экспириенса ес-но:)

Добрый день Олег, по большому счету вы правы, RFC не самый лучший способ исполнения, но он работает, и бог с ним.
 
Сейчас я практикую конект с SAP по rest(oData) с SAP, он более эффективен
 
Но суть не в том, чтобы скрестить Дорогой болид формулы 1 (python) и ржавую ладу калину (SAP), если сравнивать технологии, то именно так правильнее.
Суть — это брать данные из SAP и передавать их в современные системы обработки данных и библиотек, tenser Flow, pandas и прочее.
Сказки о том, что у SAP есть эффективные инструменты обработки данных с помощью нейросетей и предиктивной аналитики не выдерживают никакой критики.
Пока SAP скупит все компании, которые этим занимаются на приемлемом уровне, появятся еще 100500 технологий.
А по вашему вопросу(почему не написать все это на ABAP) все просто, Среда SAP NetWiever не позволяет быть гибкой, современной, функциональной.

1.
==По большому счету данный метод открывает огромные возможности по
==замене очень дорогих инструментов SAP
Это звучит как денег на дорогой болид формулы не хватило, поэтому купили только двигатель. Потом поставили его в кузов лады-калины, ну как-то втолкали, но все равно едет хренова и обслуживать дорого. Вопрос, а нахрена так кувыркаться?
 
2. По RFC все равно из какого языка конектиться, в бытности 4.6 из php ходили в свое время, чуть позже на С#. Кстати примеры для PHP были в справке сапа, там еще кажется джава была.
 
3. Что касается лицензий, то раньше вроде как всем было все равно, но сейчас сап стал не ровно дышать к таким реализациям, считая что это нарушение лицензии, ну или предлагает для каждого коннекта заводить отдельность пользователя, а это само собой лицензии со всеми вытекающими. В итоге недорогой инструмент, становится как-то очень дорогим если считать правильно по лицензиям. Да и кстати не понял, чем программа на питоне проще той же программы на абапе, а так же, как неясные критерии заказчика стали ясными в питоне и оставались такими же неясными в абапе, ну т.е. зазЭтить на питоне типа зазЭтом не считается как я понимаю? Кстати, поддерживать всю эту кухню, тоже та еще радость.
 
4. Ну и по поводу отсутствия галки RFC в заголовке ФМ. Если функция не имеет галки удаленного вызова, то никто вам не мешает сделать окаймляющую функцию вокруг нужной с галкой RFC и без проблем использовать удаленные вызовы функционала.

Просто как статья про ADBC - отлично!
 
Только объясните, пожлста, след.момент: Если система на HANA, т.е. скорее всего базис будет 7.4, а м.б. и 7.5, соответственно, есть более удобный инструментарий - можно пользоваться новым синтаксисом Open SQL, CDS-view или AMDP, для вызова процедур или вьюшек созданных непосредственно в HANA (минуя ABAP-словарь), можно создавать прокси и вызывать через них.
Зачем ADBC в контексте HANA?
 
И, как мне кажется, к ADBC относятся те же рекомендации, что и к Native SQL - по возможности предпочитать Open SQL, в связи с тем, что NW оптимизирован под использование Open SQL.

Евгений, если я правильно понял, в отличие от вашей, стандартная /SDF/CMO_TR_CHECK не нашла недостающие объекты, которые находятся на втором уровне вложенности (на них ссылаются недостающие объекты первого уровня).
 
Итого, с /SDF/CMO_TR_CHECK надо работать итерационно - добавить в запрос всё чего не хватает и прогнать еще раз, чтобы убедиться, что все объекты следующего уровня в запросе есть.
А вот ваша программа показывает всё чего не хватает сразу.
Получается, у вас в этом отношении преимущество.

1. Так ведь в SCI можно даже пакет указать. Проверит все объекты во всех запросах.
3. Например? Очень любопытно.
5. Поясните пожалуйста, в чем польза отключения проверки?

Сергей, спасибо за инструкцию!
(при создании "Инспекции" у меня нет возможности выбрать "Временное определение". возможно, из-за ограниченности полномочий. некритично, решается созданием "Варианта проверки")
В итоге получил вот это

SCI запускал по одному запросу, в котором содержится только программа из примера.
Отчет, представленный в статье, выдает следующий результат:, то есть выводит весь список объектов из Рис.1 текущей статьи. То есть SCI нашел не все объекты.
Также из преимуществ:
1. позволяет анализировать сразу несколько запросов.
2. удобство запуска и представления результата.
3. тестировал SCI на других запросах: заметил, что пропускает некоторые объекты
4. отрабатывает значительно быстрее
5. последняя редакция отчета позволяет отключать реализации точек расширения из списка объектов проверки.

Добрый день, Константин!
спасибо, за приятную оценку.
одним глазом посмотрел Вашу программу. при анализе моего тестового запроса она выдала не все объекты.
Да, действительно моя программа не выдает запросы, в которых находятся недостающие объекты (такой цели не ставилось). Насколько я понял, также данная программа умеет составлять последовательность переноса связанных объектов. Спасибо, возможно, чтото из фукнционала я добавлю к себе, когда будет возможность.
p.s. также, ранее я находил программу RSSYSCOMP. но она не умеет работать с несколькими запросами (приходилось ее копировать и расширять под свои нужны), и ракурс представления выходных данных для моих нужд неприемлем.