Добрый день, Хабр!

Хочу поделится опытом интересной задачи по тому как без труда взаимодействовать с системами SAP с помощью Python — не важно какой модуль или версия платформы.

Если интересно только техническое решение, то пропускайте всю лирику и смотрите пример реализации.

Лирика


Все свелось к тому, что одному из заказчиков потребовалось выгружать данные из своей SAP ERP системы, путем манипуляций уже создавать отчеты и рассылки интересованным людям по email, а также другие действия.

Собственно, при обсуждениях решения такой задачи мы, как подрядчик, предлагали различные варианты и один из самых очевидных это все сделать именно с помощью внутреннего функционала SAP, по-простому среди «саперов» за Зедить все с помощью ABAP.

Первое с чем мы столкнулись, это не совсем прозрачные со слов заказчика критерии выборки данных, а именно, данные каких таблиц, зачем, почему, какие действия с ними необходимо совершить. Если привести пример, то заказчику нужна была выгрузка посещаемости сотрудников офиса, с данными в разрезе табеля и отпусков. Также нужно было создать отчеты по эффективности сотрудника с аналитикой по его времени на рабочем месте, не буду вдаваться в подробности, но скажу, что количество проведенного времени влияет на продуктивность, но что бы это выяснить нужно рассчитывать количество времени на работе с результатом работы и многое другое. Это только один из примеров отчета, а заказчик генерировал очень много в ходе обсуждений.

После долгих разговоров мы поняли, что таким решением может стать SAP Query или BI\BO, но заказчика не очень устроила рассчитанная стоимость решения и не самая удобная гибкость.

Решение на Python


Тут на свою голову я вспомнил об одной статье на ресурсе про библиотеку pyrfc и так-как я, не будучи программистом python, но читав о нем когда-то статьи решил изучить это дома, и к моему удивлению я с легкостью в домашних условия будучи дилетантом данного языка программирования обнаружил, что подключится к любой системе SAP невероятно просто более того это занимает 20 минут.

Двадцать минут КАРЛ!!!

Просто представьте, что можно настроить интерфейс подключения с ERP системой SAP без использования шин данных и всяких там PI\XI за такое крошечное время.

Реализация


Окончательно убедившись, что это вполне рабочее решение и удовлетворяет заказчика я изучил несколько платформ (изучил подразумевается почитал о каждой минут по 10) я выбрал среди прочих равных платформу Odoo, так как она проще развертывается и у нее есть все необходимые свойства, такие как: Хороший интерфейс, система прав доступа, мобильное приложение, почтовый сервер, хороший интерфейс с базой данных(psql).

Далее все очень просто.

Установить на виртуальную машину заказчика Odoo (я взял версию 8) т.к. она самая простая на текущий момент, знаю, что уже версия 12, но задача не требует всех крутых новинок.

Установил все необходимые библиотеки, в частности pyrfc — ссылка на статью посвящённую установке и подключению.

Далее необходимо было только написать небольшой модуль в самой платформе Odoo, для коннекта, а инструментов для визуализации данных у нее предостаточно.

Коннект к системе заказчика:

from pyrfc import Connection
user = 'user'
passwd = 'secretuser'
saprouter = '/H/192.168.0.140/S/3297'

conn = Connection(user=user, passwd=password,
                  mshost='CLient',
                  msserv='192.168.0.140',
                  sysid='01',
                  group="SPACE",
                  saprouter=saprouter, 
                  client=‘900')

Вызов BAPI для получения информации о юзере

b_result = conn.call('BAPI_USER_GET_DETAIL',
                     USERNAME = 'user',
                     CACHE_RESULTS  = ' ')

Изменение юзера

updated_address['CITY'] = u'Moscow'
r = conn.call('BAPI_USER_CHANGE',
               USERNAME='user',
               ADDRESS=updated_address)

Самым главным инструментом для получения данных из SAP, если речь идет о таблицах, является функциональный модуль RFC_READ_TABLE, есть в SAP платформе и другие модули, которые можно вызвать, на них должна быть настройка, которая говорит о том, что их можно вызвать средствами RFC.

Например:

from pyrfc import Connection, ABAPApplicationError, ABAPRuntimeError, LogonError, CommunicationError
from ConfigParser import ConfigParser
from pprint import PrettyPrinter

def main():

    try:

        config = ConfigParser()
        config.read('sapnwrfc.cfg') - #читаем конфиг, где лежат данные о логоне в систему SAP ERP
        params_connection = config._sections['connection']
        conn = Connection(**params_connection) #создаем коннект с системой

        options = [{ 'TEXT': "FCURR = 'USD'"}]
        pp = PrettyPrinter(indent=4)
        ROWS_AT_A_TIME = 10 
        rowskips = 0

        while True:
            print u"----Begin of Batch---"
            result = conn.call('RFC_READ_TABLE',                                 QUERY_TABLE = 'TCURR',                                 OPTIONS = options,                                 ROWSKIPS = rowskips, ROWCOUNT = ROWS_AT_A_TIME)
            pp.pprint(result['DATA'])
            rowskips += ROWS_AT_A_TIME
            if len(result['DATA']) < ROWS_AT_A_TIME:
                break

    except CommunicationError:
        print u"Could not connect to server."
        raise
    except LogonError:
        print u"Could not log in. Wrong credentials?"
        raise
    except (ABAPApplicationError, ABAPRuntimeError):
        print u"An error occurred."
        raise

Результат


На данной картинке список отчетов, которые выгружаются данным методом, и пример одного из них.



Итог


По большому счету данный метод открывает огромные возможности по замене очень дорогих инструментов SAP и других более гибкими и отрытыми.

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

Хочу добавить, что данный инструмент мы уже применяем в очень большом спектре задач связанных с Расчетом KPI, вывод данных в другие источники (сайты, базы данных поставщиков и заказчиков), рассылка информации из систем на основе данных из SAP и многое другое.
Для меня вообще стало открытием вообще такая возможность, если у кого, есть похожий опыт я бы с удовольствием выслушал.

Спасибо!

C Уважением, Консультант SAP

Комментарии (14)


  1. balajah
    08.09.2018 21:00

    А что кроме odoo смотрели?


    1. zambas Автор
      08.09.2018 21:03

      Ещё думали о Django, odoo выбрали за ее erp-ориентированность


      1. balajah
        09.09.2018 09:05

        Спасибо, а то я подумал что смотрели на всякие ADempiere


  1. mspain
    09.09.2018 09:06

    В крупных конторах это вопрос политический, а не техническое ограничение. «В сап лазить должна система интеграции а ля вебсферы и точка»


    1. zambas Автор
      09.09.2018 11:28

      Полностью согласен, но бывают исключения, в особенности, когда владелец компании сам принимает активное участие. Так же когда нужны данные из sap для второстепенной системы не влияющий на работу бизнеса


  1. vlsinitsyn
    09.09.2018 13:22

    А как на это дело смотрит SAP с точки зрения лицензионных соглашений?


    1. zambas Автор
      09.09.2018 18:09

      С точки зрения SAP нужен 1 юзер для RFC доступа


  1. zambas Автор
    10.09.2018 16:56

    1. Не понял, в чем преимущество такого костыльного метода перед нативным для сапа ABAP'ом, любые данные которого можно вывести в 3 оператора (sql-запрос, создание инстанции cl_salv_table и вызов метода).

    Быстро и дешево выводить отчеты в читабельной форме в web, и изменяя его быстро и с минимальными затратами
    2.
    Почему именно python, а не, например, vba с Excel'ем. В плане поддержки — сапёров со знанием vba в тысячи раз больше, чем с python.

    Причем здесь Excel', стояла четкая задача, забрать данные, перенести их вдругую базу, по пути обработать, вывести отчет, получить доступ по web
    python — потому что любой отчет меняется за 2-3 часа и в логике и в визуальном представлении,
    + Нет привязки к лицензиями
    + Работа с данными для библиотеки pandas и предиктивной аналитики
    Не представляю как по вашим словам с этим справиться Excel
    Но самое главное для бизнеса были открыты большие возможности, о которых на этапе проектирования решения никто и не догадывался,


  1. zambas Автор
    10.09.2018 17:02

    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, которые использовали Вы в своей работает, с примерами, тогда можно будет и посмотреть


    1. valfff
      11.09.2018 08:59

      Быстро и дешево выводить отчеты в читабельной форме в 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 на большом количестве данных?


      1. zambas Автор
        11.09.2018 10:22

        Чем изменения в том методе, который вы привели в статье, «быстрее и с минимальными затратами изменяется» по сравнению с

        Как вы написали это: Запрос в базу и вывод в 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. valfff
    10.09.2018 17:02

    1. Не понял, в чем преимущество такого костыльного метода перед нативным для сапа ABAP'ом, любые данные которого можно вывести в 3 оператора (sql-запрос, создание инстанции cl_salv_table и вызов метода).
    2. Почему именно python, а не, например, vba с Excel'ем. В плане поддержки — сапёров со знанием vba в тысячи раз больше, чем с python.

    Вызов BADI для получения

    BAdi = Business Add Ins, точки расширения в SAP. Их вызов извне чуть менее, чем бесполезен. То, что вы вызываете — BAPI.

    ps Поздравляю автора с тем, что он открыл для себя SAP RFC — технологию, которой не один десяток лет.


  1. alfaterra
    11.09.2018 10:35

    А как насчет масштабируемости, что будет через несколько лет, не упадет ли производительность? Продумывали эти вопросы?


  1. zambas Автор
    11.09.2018 10:43

    А как насчет масштабируемости, что будет через несколько лет, не упадет ли производительность? Продумывали эти вопросы?

    Производительность не упадет точно, т.к. что Psql что Odoo очень легко масштабируется, плюс все написано отдельными модулями, при желании в 5-10 дней все можно портировать в другую среду, например Django или другие.
    К слову в данный момент платформа Odoo крутится на виртуальной машине и на нее выделно 512мб ОЗУ и 2 ядра по 1000мгц
    Мы провели синтетические тесты на запуск с одного компьютера в 50 потоков запроса самого тяжелого отчета.
    SAP ERP справилась за 40 секунд,
    Odoo обработала данные за 4сек.