Comments 15
UFO just landed and posted this here
В крупных конторах это вопрос политический, а не техническое ограничение. «В сап лазить должна система интеграции а ля вебсферы и точка»
А как на это дело смотрит SAP с точки зрения лицензионных соглашений?
1. Не понял, в чем преимущество такого костыльного метода перед нативным для сапа ABAP'ом, любые данные которого можно вывести в 3 оператора (sql-запрос, создание инстанции cl_salv_table и вызов метода).
Быстро и дешево выводить отчеты в читабельной форме в web, и изменяя его быстро и с минимальными затратами
2.
Почему именно python, а не, например, vba с Excel'ем. В плане поддержки — сапёров со знанием vba в тысячи раз больше, чем с python.
Причем здесь Excel', стояла четкая задача, забрать данные, перенести их вдругую базу, по пути обработать, вывести отчет, получить доступ по web
python — потому что любой отчет меняется за 2-3 часа и в логике и в визуальном представлении,
+ Нет привязки к лицензиями
+ Работа с данными для библиотеки pandas и предиктивной аналитики
Не представляю как по вашим словам с этим справиться Excel
Но самое главное для бизнеса были открыты большие возможности, о которых на этапе проектирования решения никто и не догадывался,
1. Не понял, в чем преимущество такого костыльного метода перед нативным для сапа ABAP'ом, любые данные которого можно вывести в 3 оператора (sql-запрос, создание инстанции cl_salv_table и вызов метода).
Быстро и дешево выводить отчеты в читабельной форме в web, и изменяя его быстро и с минимальными затратами
2.
Почему именно python, а не, например, vba с Excel'ем. В плане поддержки — сапёров со знанием vba в тысячи раз больше, чем с python.
Причем здесь Excel', стояла четкая задача, забрать данные, перенести их в другую базу, по пути обработать, вывести отчет, получить доступ по web
python — потому что любой отчет меняется за 2-3 часа и в логике и в визуальном представлении,
+ Нет привязки к лицензиями
+ Работа с данными для библиотеки pandas и предиктивной аналитики
Не представляю как по вашим словам с этим справиться Excel
Но самое главное для бизнеса были открыты большие возможности, о которых на этапе проектирования решения никто и не догадывался, например с этими данными было разработано мобильное приложения на том же Python (Да это не круто, но достаточно для бизнеса)
BAdi = Business Add Ins, точки расширения в SAP. Их вызов извне чуть менее, чем бесполезен. То, что вы вызываете — BAPI.
Я полностью разделяю то, что сам коннект не бэст практис, но оно работает, работает отлично.
Поправил, всегда их путаю устно
ps Поздравляю автора с тем, что он открыл для себя SAP RFC — технологию, которой не один десяток лет.
Никогда не сталкивался, спасибо,
Поделитесь новыми технологиями в SAP, которые использовали Вы в своей работает, с примерами, тогда можно будет и посмотреть
Быстро и дешево выводить отчеты в читабельной форме в web, и изменяя его быстро и с минимальными затратами
Чем изменения в том методе, который вы привели в статье, «быстрее и с минимальными затратами изменяется» по сравнению с
SELECT * INTO TABLE @DATA(lt_tcurr) FROM tcurr WHERE FCURR = 'USD'.
cl_salv_table=>factory( Importing = DATA(lo_alv) Changing = lt_tcurr ).
lo_alv->display( ).
забрать данные, перенести их в другую базу,
В каком виде хранятся данные в другой базе? Выгружаете к себе целиком саповские таблицы?
Oltp-отчеты не строите? Если строите, то как себя ведут эти вызовы rfc на большом количестве данных?
Чем изменения в том методе, который вы привели в статье, «быстрее и с минимальными затратами изменяется» по сравнению с
Как вы написали это: Запрос в базу и вывод в ALV Отчет.
Нам нужно было забрать данные и произвести над ними вычисления, что бы построить отчеты и вывести их в web, средствами ABAP это было сделать можно, но:
1) Очень большите трудозатраты, потому как готовых библиотек для работы с предиктивной аналитикой в ABAP Нет, а если есть, то это отдельный продукт с отдельными специалистами и вообще целым новым проектом
2) Технологическая сложность вывода в WEB отчетов и работы с ними в режиме реального времени
3) Посмтоянные изменение для вычисления данных для отчетов и форма вывода.
В каком виде хранятся данные в другой базе? Выгружаете к себе целиком саповские таблицы?
Данные в таком виде как в SAP таблицах не хранятся в другой базе, хранятся только результаты вычислений и преобразований на основании выборки части данных из SAP
Если строите, то как себя ведут эти вызовы rfc на большом количестве данных?
Мы написали свои ZRFC Функциональные модули, т.к. стандартные как раз и сильно загружали систему и мы работает только с определенными таблицами и все нам не нужны.
Oltp-отчеты не строите?
OLAP
Наверное я слишком коротко описал в статье задачи если кратко описать последовательную схему, то выглядит так:
1) Вызов Z RFC метода(ABAP+RFC) — модулей много, в зависимости от запроса
2) Выбор данных и структурирование(Python)
3) Обработка данных (Python+ библиотеки sklearn, numpy, pandas)
4) Сохранение результата вычислений (Odoo)
5) Вывод отчетов (Odoo, wkhtml2pdf, xlrd, xlwt, xlutils или openpyxl)
6) Хранения данных для отправки в другие системы(Мобильное приложение, MS Axapta(другого филиала)
Это очень кратко
Если вам интересно, попробуйте оценить стоимость аналогичного решения на основе
Чем изменения в том методе, который вы привели в статье, «быстрее и с минимальными затратами изменяется» по сравнению с
Как вы написали это: Запрос в базу и вывод в ALV Отчет.
Нам нужно было забрать данные и произвести над ними вычисления, что бы построить отчеты и вывести их в web, средствами ABAP это было сделать можно, но:
1) Очень большите трудозатраты, потому как готовых библиотек для работы с предиктивной аналитикой в ABAP Нет, а если есть, то это отдельный продукт с отдельными специалистами и вообще целым новым проектом
2) Технологическая сложность вывода в WEB отчетов и работы с ними в режиме реального времени
3) Посмтоянные изменение для вычисления данных для отчетов и форма вывода.
В каком виде хранятся данные в другой базе? Выгружаете к себе целиком саповские таблицы?
Данные в таком виде как в SAP таблицах не хранятся в другой базе, хранятся только результаты вычислений и преобразований на основании выборки части данных из SAP
Если строите, то как себя ведут эти вызовы rfc на большом количестве данных?
Мы написали свои ZRFC Функциональные модули, т.к. стандартные как раз и сильно загружали систему и мы работает только с определенными таблицами и все нам не нужны. Постоянное обращение к базе SAP ERP нам не нужно, т.к. результаты хранятся в Odoo
В день примерно 20-30 запросов в базу, каждый с выборкой по 10-20 тысяч стр.
Oltp-отчеты не строите?
OLAP, Но думаем над тем, что бы воспользоваться возможностями Python например для подключения приложений с обратной связью например, web касса, система контроля доступа.
Наверное я слишком коротко описал в статье задачи если кратко описать последовательную схему, то выглядит так:
1) Вызов Z RFC метода(ABAP+RFC) — модулей много, в зависимости от запроса
2) Выбор данных и структурирование(Python)
3) Обработка данных (Python+ библиотеки sklearn, numpy, pandas)
4) Сохранение результата вычислений (Odoo)
5) Вывод отчетов (Odoo, wkhtml2pdf, xlrd, xlwt, xlutils или openpyxl)
6) Хранения результатов для отправки в другие системы(Мобильное приложение, MS Axapta(другого филиала)
1. Не понял, в чем преимущество такого костыльного метода перед нативным для сапа ABAP'ом, любые данные которого можно вывести в 3 оператора (sql-запрос, создание инстанции cl_salv_table и вызов метода).
2. Почему именно python, а не, например, vba с Excel'ем. В плане поддержки — сапёров со знанием vba в тысячи раз больше, чем с python.
BAdi = Business Add Ins, точки расширения в SAP. Их вызов извне чуть менее, чем бесполезен. То, что вы вызываете — BAPI.
ps Поздравляю автора с тем, что он открыл для себя SAP RFC — технологию, которой не один десяток лет.
2. Почему именно python, а не, например, vba с Excel'ем. В плане поддержки — сапёров со знанием vba в тысячи раз больше, чем с python.
Вызов BADI для получения
BAdi = Business Add Ins, точки расширения в SAP. Их вызов извне чуть менее, чем бесполезен. То, что вы вызываете — BAPI.
ps Поздравляю автора с тем, что он открыл для себя SAP RFC — технологию, которой не один десяток лет.
А как насчет масштабируемости, что будет через несколько лет, не упадет ли производительность? Продумывали эти вопросы?
А как насчет масштабируемости, что будет через несколько лет, не упадет ли производительность? Продумывали эти вопросы?
Производительность не упадет точно, т.к. что Psql что Odoo очень легко масштабируется, плюс все написано отдельными модулями, при желании в 5-10 дней все можно портировать в другую среду, например Django или другие.
К слову в данный момент платформа Odoo крутится на виртуальной машине и на нее выделно 512мб ОЗУ и 2 ядра по 1000мгц
Мы провели синтетические тесты на запуск с одного компьютера в 50 потоков запроса самого тяжелого отчета.
SAP ERP справилась за 40 секунд,
Odoo обработала данные за 4сек.
Sign up to leave a comment.
SAP и Python интеграция или как забрать данные из SAP проще