Sap

Segregation of Duties на примере SAP

18.03.2021 16:05:16 |

Автор: admin

Когда заходит речь о SoD (segregation of duties или разделении прав доступа) пользователей, то часто кажется что существует словно два мира мир красивых презентаций о том, почему доверие в бизнесе это важно и мир реальности, где нужно конвертировать красивые слова о стратегии в реалистичную и, желательно, позитивную практику.

Под катом краткое объяснение что такое риск SoD, как это выглядит с точки зрения базы данных SAP, и как с этим работать.

Предыстория

Segregation of duties (SoD) или разделение обязанностей, ролей это превентивный контроль для внутренних сотрудников, суть которого в том, чтобы не допустить концентрацию важных прав доступа в одних руках. Операции с высоким риском, должны быть разделены на несколько этапов, каждый из которых выполняется разными людьми, что позволяет предотвратить мошенничество, а заодно обезопасить сам процесс от ошибок.

В значительной мере SoD как обязательный контроль в организации развился после принятия в США знаменитого Sarbannes Oxley act (SoX) в 2002 году. Закон был направлен на противодействие мошенничеству в финансовой сфере, и ужесточению контроля за финансовой отчетностью, при этом сам акт риски SoD изначально не прописывал, а скорее определял основные направления по которым компания должна была принять меры. Риски были доработаны позже.

Пример финансового риска:

Открытие/закрытие бухгалтерских периодов проводки и записи в журнале проводок / Maintain Posting Periods & Post Journal Entry >> может привести к тому, что сотрудник может потенциально публиковать записи за предыдущие периоды для достижения ожидаемых внутренних финансовых целей, например открыть закрытый отчетный период и провести проводку задним числом, из-за чего финансовая отчетность может быть сфальцифицирована.

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

Риски, функциональность и набор правил

Набор правил (ruleset) или набор рисков SoD каждая организация определяет для себя сама. Внутренний аудитор или топ менеджмент вправе сказать для нас рисков всего пять и они все сосредоточены вокруг открытия, закрытия отчетного периода. Или наоборот, рисков 525 и каждый из них считается уникальным.

В действительности, чаще всего ruleset приходит вместе с командой аудиторов (что логично, если вас будут проверять на наличие рисков SoD, надо по крайней мере знать к чему готовиться) или вместе с софтом, который будет проверять систему (например для SAP SAP GRC), и далее дорабатывается компанией в зависимости от внутренней оценки рисков и возможностей.

Итак, словарь:

Ruleset общий список-набор рисков SoD, их классификация и определение отдельных функциональных разрешений (query);
SoD определенный риск, возникающий при комбинации двух функциональных разрешений. SoD может состоять как из двух разрешений, так и из трех, и даже из одного (uni-SoD) но очень важного, например кастомизация системы в продакшн (in SAP SPRO);
Query функциональное разрешение, кирпичик для матрицы SoD. Конкретный функционал, например проводка в системе, или открытие отчетного периода;

Выглядит все это примерно так:

	SoD name	Process	Query A	Query B	Risk description
1	FI_01_High	FI	Изменение мастер данных клиентов	Оплата счетов	Обслуживание основных данных следует отделить от обработки транзакций. Существует риск того, что пользователь может создать несуществующие счета и переводить на них деньги.
2	FI_02_Medium	FI	Освободить заблокированные счета-фактуры	Утверждение заказа на поставку	Пользователь может подтвердить заказ на поставку и разблокировать ранее заблокированный счет-фактуру, что приведет к несанкционированной обработке счетов-фактур.

Матрица SoD это таблица сопересечения различных query. Многие организации любят изображать риски SoD в виде матрицы, хотя по сути это тот же самый ruleset, изображенный в двоичной системе координат. Просто так нагляднее.

Вернемся к SAP

Риски SoD не привязаны к конкретной базе данных 1С, Oracle, SAP и сформулированы достаточно гибко, отражая самое главное функционал, который может осуществить отдельно взятый сотрудник в случае обладания нужными правами. Но чтобы предотвратить риск, необходимо спуститься на более технический уровень и посмотреть как риск выглядит с точки зрения базы данных.

Мне это удобнее рассматривать с точки зрения SAP, если в других базах данных это устроено по-другому, будет интересно если вы поделитесь опытом.

Также отмечу что чаще всего в SAP аудиторы проверяют только главную систему ECC или S4HANA, без того чтобы смотреть на права в системах CRM, SRM и других.

Возьмем конкретный финансовый риск, описанный выше:

Открытие/закрытие бухгалтерских периодов проводки и записи в журнале проводок/ Maintain Posting Periods & Post Journal Entry

Риск состоит из двух частей, что в SAP означает доступ к определенным транзакциям

Maintain Posting Periods

OB52 C FI Maintain Table T001B
F-60 Maintain Table: Posting Periods
GCP1 FI-SL: Local Posting Periods
GCP2 FI-SL Customizing: T001C
...
Post Journal Entry

FB01 Post Document
FB02 Change Document
FB08 Reverse Document
F-02 Enter G/L Account Posting
F-21 Enter Transfer Posting
F-22 Enter Customer Invoice
....

Но одними транзакциями дело не ограничивается. Чтобы возможно было выполнить тот или иной функционал, в query включаются также и технические объекты, необходимые для выполнения операции. Как правило те, на которых стоят обязательные проверки в программном коде.

Например:

Maintain Posting Periods

S_TABU_DIS ACTVT 02
S_TABU_DIS DICBERCLS FC31
Post Journal Entry

F_BKPF_BUK ACTVT 01, 02, 06
F_BKPF_KOA ACTVT 01, 02, 06
F_BKPF_KOA KOART K

Таким образом чтобы иметь возможность использовать риск SoD, пользователь должен обладать и транзакциями и техническими объектами с нужными значениями.

Еще один пример, риск BC (basic controls), за этот риск как правило отвечает главный администратор системы:

Создание пользователей и предоставление им прав доступа / Maintain users & Assign roles/profiles to users

Как это выглядит технически:

Query	Transaction	Authorization object
Maintain users	SU01	S_USER_GRP (01,02)
Assign roles/profiles to users	PFCG	S_USER_GRP (02)+S_USER_PRO (22)

В идеальном мире за создание пользователей и за предоставление им ролей (по крайней мере в продакшн) должны отвечать два разных человека. В реальности это часто не так, но это не мешает стремиться к идеальному.

Избавляемся от SoD

Что происходит когда приходит аудитор и, проверив систему на наличие рисков, находит 3000 конфликтов SoD? Как правило решить их сразу нет никакой возможности. Но можно выбрать самые критические и сфокусироваться на том, чтобы избавиться от них.

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

С транзакциями тем не менее проще:

можно отследить по данным STAD какие сотрудники не использовали транзакции и забрать доступ в первую очередь у них
многие транзакции дублируются с доступом только в визуализации и большая часть пользователей именно этот доступ и просит

С тех.объектами сложнее:

нельзя отследить (вернее достаточно сложно) какой объект был использован пользователем, а какой нет
часто объекты используются различными процессами. И забрав объект, и обезопасив один функционал, в итоге блокируешь другой. Например, как видно из примера с Maintain users & Assign roles/profiles to users, один объект S_USER_GRP используется обеими query.

Другое коварство баз данных это Accumulation of rights или совмещение доступов когда буффер авторизаций пользователя (SU56 User Authorization Buffer) включает в себя все возможные объекты из всех возможных ролей пользователя, независимо от того, под какие процессы были определены роли. Другими словами мы можем создать две разные роли в одну для SU01, другую для PFCG, но если мы дадим обе роли одному пользователю, система будет думать что это одна роль, соответвенно она посчитает это за конфликт SoD.

Стратегия избавления от SoD обычно идти от большого к меньшему. Сначала оценить насколько пользователю необходима сама роль (composite или single) и только потом идти в детали роли и корректировать ее. Но об этом можно поподробнее в другой раз, главное что нужно отметить что это не всегда очевидно, и часто есть предел в том, как сократить количество рисков (похожая аналогия с похудением) невозможно полностью исключить все риски SoD из системы.

Но если вдруг в системе не останется ни одного SoD...

вот тогда придет GDPR.

Казалось бы, практики определения рисков SoD существуют без малого 20 лет. Крупные компании достаточно активно мониторят свои системы и уже выстроили отлаженные процессы по нахождению, предотвращению и избавлению от рисков SoD. B этот момент появляется нечто новое закон о защите персональных данных.

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

Если перевести это на технический язык SAP появились новые query для HR. Их нельзя в полной мере назвать SoD, потому что это не риск связанный с разделением функционала, но тем не менее компании проверяют свои системы на наличие вполне определенного доступа, а после проверки, стараются минимизировать риски.

Пример query HR:

Query	Transaction	Authorization object
Maintain PA master data IT 0000	PA30	P_ORGIN AUTHC W,P_ORGIN INFTY 0000

Уверена что когда компании приведут свои системы в порядок в соответствии с нормами GDPR, придет что-то новое. Но до этого пока еще далеко, а аудит SoD пока еще достаточно актуальная тема.

Подробнее..

Категории: Блог компании ruvds.com , Информационная безопасность , Администрирование баз данных , Базы данных , Sap , Segregation of duties , Безопастность

Строим безопасную разработку в ритейлере. Итоги одного большого проекта

22.12.2020 10:22:28 |

Автор: admin

Эта статья завершающая в цикле материалов о нашем опыте выстраивания процесса безопасной разработки для крупного ритейлера. Если пропустили, можете прочитать первые части: о безопасной разработке порталов и мобильных приложений, о безопасной разработке в группе приложений SAP и о встраивании в процесс разработки кассового ПО. Настало время ~~собрать шишки, которые мы набили~~ подвести итоги.

Все было классно. И на этом мы могли бы закончить, если бы не одно но. При планировании мы некорректно оценили время интеграции. Спойлер: многое пошло не так, в результате внедрение усложнилось, сроки сдвинулись. Спойлер 2: учесть все факторы риска было невозможно. И вот с этого момента давайте поподробнее.

Lessons to Be Learned

1. Учитываем регламенты и бюрократию

Чем больше заказчик, тем больше у него регламентов и бюрократии, которые созданы облегчить все, но на деле только усложняют. О первый камень мы споткнулись на этапе конкурса. Нас попросили подготовить генеральный план еще до того, как мы успели ознакомиться со всеми внутренними требованиями и нюансами, а также устройством компании изнутри, которые впоследствии на многое повлияли. Это было требованием директората, без которого внедрение не случилось бы. Мы согласились и, оценив риски, подписались под довольно свободные сроки, как нам тогда показалось.

На старте заказчик предупредил нас, что у него есть регламент, согласно которому внедрения должны проходить через три стандартных этапа: разработка, тестирование и продакшн. Расскажем на примере, почему эти правила на самом деле ничего не облегчают.

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

Получилось, что какую-то работу мы проделали зря, какую-то передали на сторону заказчика. И если бы мы миновали бюрократический процесс, существенно сэкономили бы время. Как мы увидели на примере внутренних разработчиков позже, избежать его было можно. Ближе к концу проекта мы убедились, что могли бы так же игнорировать эти требования без какого-либо ущерба проекту и репутации. Но к тому моменту интеграция уже перешла в финальную фазу отладки. Мы сделали вывод, что в будущем будем договариваться, чтобы с нас снимали требования о жестком соответствии регламентам, если их несоблюдение никак не влияет на проект. Также мы поняли, что необходимо было настаивать на большем вовлечении со стороны ритейлера. Так мы могли узнать о значимых изменениях раньше и более гибко на них отреагировать. И самый главный вывод: при планировании сроков обязательно нужно оценивать зарегламентированность крупных организаций как веский фактор риска.

2. Текучка существенный тормоз процесса

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

Однажды нас застали врасплох категоричным ответом: Я считаю, что это решение будет неверным. Мы так делать не будем. Это случилось, когда мы уже договорились о полной передаче поддержки баз данных MariaDB с руководителем отдела администрирования баз данных. Перед самой сдачей проекта, когда мы все согласовали, выяснилось, что в отделе сменился руководитель. И хотя все договоренности с прежним сотрудником были запротоколированы, согласно регламенту, нам пришлось пойти на компромисс и взять администрирование на себя в рамках техподдержки всего продукта. Оказалось, что заказчик не берет на поддержку MariaDB, хотя в проектной документации не было упоминаний об этом.

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

3. Погружение в специфику избавит от множества проблем

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

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

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

Изменения в продукте по результатам проекта

1. Интеграция с AD

До этого проекта интеграция Solar appScreener с Active Directory не была оптимизирована под высокие нагрузки. Она начинала тормозить при подключении к каталогам с тысячами пользователей, с ней было не очень удобно работать. В процессе развития проекта систему доработали так, что никаких нареканий к ней уже не возникало. Теперь мы сможем интегрироваться с любой подобной системой, и проблем с производительностью у нас не будет.

2. Jira

Мы также серьезно улучшили все нюансы, связанные с Jira. До проекта мы полагались на дефолтную реализацию Jira, но у данной ритейловой компании Jira была очень серьезно переписана: добавлены различные поля, изменена дефолтная механика создания задач, все изначальные шаблоны. Поэтому мы внедрили в Solar appScreener инструмент, который позволяет подстраиваться под любой вид интеграции, потому что имеет возможность редактировать тело создаваемой задачи, которая посылается в Jira по API из Solar appScreener. Это очень гибкий инструмент.

Например, когда мы настраивали интеграцию с SAP, то столкнулись с тем, что наша старая интеграция с Jira выгружает какие-то дефолтные поля задачи, ты пытаешься создать задачу, и это не получается. Думаешь, что происходит?. Открываешь Jira, а там все не так, Jira по API выдает абсолютно не те дефолтные поля, не того типа данных, которые на самом деле должны содержаться. Но поскольку на эту реализацию у заказчика были завязаны процессы, то проблемы надо было решать на стороне Solar appScreener.

В результате в SAP нужно было заранее определить поля estimation time to do this task. Estimation time приходит как string, заходишь и видишь в нем два поля. А если открыть XML, то обнаруживается, что в этих полях данные должны быть описаны определенным образом. То есть это уже, по сути, словарь со множеством значений, где нужно сразу прописать время, например, one day в формате именно 1d. Ты это исправляешь, пытаешься запустить интеграцию и опять что-то не работает. Смотришь и понимаешь: какое-то поле, которое выгрузилось как обязательное, действительно числится как обязательное. Но при этом в самом интерфейсе его заполнять не нужно. Пару раз вот так потыкавшись, ты в итоге реализуешь интеграцию, но если бы у нас не было возможности гибкой настройки любого вида полей, то мы бы не смогли настроить интеграцию с такой кастомной версией Jira.

3. Изменение архитектуры приложения

Параллельно с этим проектом мы серьезно модернизировали архитектуру нашего приложения. Это потребовало существенных трудозатрат, так как необходимо было перейти от парадигмы цельного монолита, нагрузка от работы которого полностью ложилась на сервер, на классическую модель backend-frontend. Из-за чего пришлось применять другие подходы во всей разработке, проектировании, создании своего API и изменении стека технологий. В итоге это решение существенно упростило создание автоматизации так как именно наш новый API стал её основным инструментом и точкой входа.

Для себя мы выяснили, что есть очень много запросов на переход с MariaDB/MySQL, функционала которой было достаточно для работы приложения, на PostreSQL. Особенно со стороны крупного бизнеса, для которого эта база данных является одной из наиболее распространенных благодаря широкому функционалу и хорошей поддержке. Так, заказчик в определенный момент отказался от поддержки MariaDB, и их подразделение баз данных перешло на работу исключительно с PostgreSQL. Поэтому нам пришлось внедрять поддержку этой базы данных.

Резюме

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

Проект выявил узкие места, и мы осознали, как с ними бороться в будущем. Наша команда поняла для себя, как должна выглядеть архитектура Solar appScreener через год, чтобы продукт улучшался, расширялись его варианты поставки. Многое для себя выяснили с точки зрения улучшения пользовательского опыта работы с продуктом. В некоторых местах не хватало поиска по пользователям. Нужно было дать возможность добавить пользователя в локальную группу из LDAP и других протоколов сразу в нескольких, связанных с панелью администрирования местах (в настройках конкретного проекта, в настройках пользователя и т.п.).

Все участники этого проекта с нашей стороны сейчас занимаются развитием продукта, и у них есть общее понимание, как он должен масштабироваться на крупные внедрения процесса безопасной разработки. Мы работаем над очередной ещё более глобальной модернизацией архитектуры всего приложения, которое позволит его масштабировать и изменять более гибко, сделает более универсальной развёртку и проще взаимодействие для пользователей.

Это заключительная часть цикла статей о построении процесса безопасной разработки в крупном ритейлере. Будем рады ответить на вопросы и узнать о вашем опыте реализации практик безопасной разработки в комментариях!

Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем

Подробнее..

Категории: Информационная безопасность , Postgresql , Gitlab , Ci/cd , Совершенный код , Управление продуктом , Софт , Уязвимости , Devsecops , Анализ кода , Блог компании ростелеком-солар , Jira , Sap , Безопасная разработка , Activedirectory

Openshift 4.5, мастер-курс OpenShift administrators amp operations и роботы, наблюдающие за далекими галактиками

17.07.2020 10:14:14 |

Автор: admin

Пойте вместе с нами станьте частью DevNation.

Ниже наша новая подборка полезных ссылок на живые мероприятия, видео, митапы и техтолки.

Сначала главная новость недели релиз OpenShift 4.5!

Основные изменения:

Kubernetes 1.18.3
vSphere IPI
GCP UPI, поддерживается установка в общий VPC
Поддерживается установка компактного (3 мастера) кластера
openshift-install explain помогает составить install-config.yaml
OpenStack: установка в готовые сети и подсети, поддерживается добавление сетей
Spot Instances в AWS Machine API
Descheduler (TP), VPA (TP)
Отдельный Prometheus для пользовательских метрик (TP)
Улучшения в поддержке Knative, Tekton и Helm в консоли разработчика
Поддержка HTTP/2
Автоматический перевыпуск устаревших сертификатов
Билды с Jenkins Pipeline теперь Deprecated

Release notes тут. В ближайшее время выпустим подробнейший пост про это долгожданное чудо.

Начни новое:

20 июля: Master Course | Operations I
Масштабирование кластера OpenShift и настройка функции агрегирования логов OpenShiftа.
20 июля: Master Course | Operations II
Интеграция OpenShift с identity management и настройка пользователей, групп и RBAC.
Записи двух уроков по циклу разработки с инструментами Red Hat
Каким образом построить процесс сборки и вывода приложения в промышленную эксплуатацию, чтобы оставить комфортные условия для разработки, тестирования и отладки самого приложения, как построить защищенное соединение и упростить процесс идентификации и авторизации пользователей и сторонних приложений в своих микросервисах, как передать свое приложение на конвейер сборки эти и другие важные вопросы без регистрации, смс и биткоинов в двух частях:
Часть первая Red Hat CodeReady, Часть вторая CI/CD и Kubernetes.

Строй:

Kourier: A lightweight Knative Serving ingress
Попробуйте Kourier, чтобы облегчить экспонирование Knative-приложений во внешние сети без дополнительных CRD.
Мяу! Установите Apache Tomcat и разверните веб-приложение на Java в Red Hat OpenShift

Установите Apache Tomcat из образа Docker, а затем используйте его для развертывания и управления веб-приложением Java в Red Hat OpenShift.
Разработка приложений Eclipse MicroProfile в Red Hat JBoss Enterprise Application Platform Expansion Pack 1.0 с Red Hat CodeReady Workspaces
Настройте среду Red Hat CodeReady Workspaces для разработки приложений MicroProfile с использованием Red Hat JBoss Enterprise Application Platform XP 1.0.
Автоматизация workshop setup с Ansible playbooks и CodeReady Workspaces
Узнайте, как создать Ansible playbook для автоматизации развертывания Quarkus Workshop в кластере OpenShift 4 с помощью CodeReady Workspaces и Keycloak.
Создайте простой cloud-native конвейер для сбора данных изменений
Несколько вариантов, как создать приложение таким образом, чтобы улучшить взаимодействие с разработчиком, а не мешать ему.
Operatorhub.io и ваш Kubernetes cluster | DevNation Tech Talk
Приключения на борту корабля Kluster Kruise

На сладкое:

OpenShift Container Platform 4
Все, что вам нужно для управления жизненным циклом разработки, включая стандартизированные workflows, поддержку нескольких сред, continuous integration и release management. Поставь меня! Твой OpenShift Container Platform 4

Почитать на досуге:

Пять тысяч глаз в небо: как ученые и роботы наблюдают за далекими галактиками
Управление контейнерами в namespaces, используя nsenter
Про деньги. Как измерить и управиться с technical debt
Правила хорошего тона для команд при использовании при использовании Gitа

По-русски:

21 июля, Сотрудничество для достижения успеха: Решения Fujitsu и Red Hat для SAP HANA
Совместный вебинар про то, как построить решения для SAP HANA с использованием Red Hat на базе серверов и СХД Fujitsu.
23 июля, Red Hat Infrastructure Layer
Вебинар про человеческое управление инфраструктурным слоем. В ролях: Red Hat Enterprise Linux, Red Hat Satellite и Red Hat Insights.
23 июля, RHEL + Smart Management + Insights
RHEL + Smart Management + Insights связка, которая позволяет сделать операционную систему и ее управление действительно умным и удобным. В рамках вебинара мы расскажем вам об интеграции Red Hat Enterprise Linux, Red Hat Satellite и Red Hat Insights.

Подробнее..

Категории: Астрономия , It-инфраструктура , Kubernetes , Open source , Учебный процесс в it , Apache , Блог компании red hat , Red hat , Openshift , Tomcat , Knative , Sap , Rhel

Автоматизация работы в SAP с помощью роботов

19.03.2021 18:12:20 |

Автор: admin

Решения SAP на сегодня являются самыми распространенными ERP-системами в мире. Они умеют интегрировать между собой разные бизнес-процессы, упрощают работу отраслевых специалистов за счет огромного количества шаблонных решений. Но освоение сотрудниками систем SAP, разворачивание и внедрение их в производство являются масштабными и сложными задачами. Последние тенденции здесь использование специализированных RPA-решений для автоматизации и упрощения работы. В этой статье мы рассматриваем основные барьеры, сложности и преимущества автоматизации работы с SAP-системами с помощью RPA, а также даем гайд-инструкцию по старту роботизации SAP в UiPath Studio.

Драйверы автоматизации

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

Исследование SAPinsider Benchmark Report, опубликованное летом 2020 года, в ходе которого организаторы опросили более 200 клиентов SAP, показало, что они все чаще внедряют технологии автоматизации, чтобы полностью охватить цифровую трансформацию, максимизировать эффективность процессов и создать полноценный work-life баланс для своих сотрудников.

Потребность в автоматизации объясняется двумя основными причинами. Во-первых, у SAP сложный интерфейс, требующий времени на обучение работе с ним. И вторая проблема в конце 2027 года поддержка пакета бизнес-приложений SAP Business Suite 7 закончится. Останется лишь один вариант мигрировать заранее на SAP S/4HANA.

(SAP S/4HANA это новая система планирования ресурсов предприятия (ERP) на основе ИИ и машинного обучения.).

Поддержку этой системы продлили как минимум до конца 2040 года.

Первый драйвер роботизированной автоматизации это сами сотрудники, у которых есть потребность сосредоточить свои усилия на интеллектуальной деятельности вместо рутины. Второй неминуемый переход компаний на SAP S/4HANA.

Согласно данным того же исследования основными задачами автоматизации для клиентов SAP являются:

сквозная автоматизация между решениями SAP и другими системами компании (58%),
стандартизация процессов в рамках миграции SAP S/4HANA (40%),
настройка и выполнение программных роботов для автоматизации процессов (RPA) (40%).

Барьеры автоматизации

Основные сложности, ограничивающие возможности автоматизации работы с системами SAP это использование предприятием кастомизированных IT-систем и наличие нестандартизированных процессов.

Многие из опрашиваемых SAPinsider используют кастомизированные и изолированные ERP, что затрудняет внедрение и масштабирование решений автоматизации. Корпоративные архитекторы могли бы легче масштабировать системы автоматизации на всю организацию, если бы каждое ее подразделение и каждая используемая ERP-система работали с одними и теми же стандартизованными процессами. Поэтому многие респонденты заявили, что теперь видят в SAP S/4HANA возможность начать все сначала, оптимизировать процессы и внедрить автоматизацию.

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

Наиболее популярные типы автоматизации сегодня: платформы RPA и инструменты моделирования и мониторинга рабочих процессов. Последние помогают организациям повысить прозрачность процессов и оптимизировать их, чтобы упростить последующее внедрение RPA.

Остановимся подробнее на роботизации SAP. Какой бы путь компания для себя ни выбрала на ближайшее будущее: продолжать работать в SAP ECC или осуществлять миграцию на SAP S/4 HANA роботы могут здесь помочь.

Барьеры, ограничивающие внедрение решений по автоматизации работы с SAP, в случае роботизации не являются проблемой. Роботы одинаково будут работать как со стандартной системой SAP, так и с кастомизированной, имеющей большое количество Z-таблиц.

При этом роботизированные процессы могут включать в себя работу с разными системами, позволяя роботизировать сквозные процессы. Даже при использовании Citrix.

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

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

Самая популярная область для автоматизации это финансы. Компании автоматизируют:

обработку дебиторской задолженности (79%),
обработку кредиторской задолженности (76%),
управление счетами-фактурами (68%).

Помимо финансов, организации автоматизируют широкий спектр процессов:

тестирование SAP S/4HANA (43,5%),
миграцию данных для SAP S/4HANA (42%),
онбординг новых сотрудников (40%),
ERP-риски и контроль (36%),
обработку заработной платы (34%),
обработку производственных заказов (30%),
складские операции (30%).

Автоматизация с помощью UiPath

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

UiPath является официальным партнером SAP, у компании есть все необходимые сертификаты. Решения UiPath работают почти со всеми интерфейсами и облачными приложениями SAP:

SAP WinGUI
SAP S4/HANA
SAP SuccessFactors
SAP BAPI
SAP WebGUI
SAP S4/HANA Cloud
SAP Ariba
SAP RFC
SAP Fiori
SAP C4/HANA
SAP Concur
SAP OData
SAB Business Client
SAP Hybris
SAP Fieldglass

SAP WinGUI-это наиболее часто используемый интерфейс для доступа к функциям SAP в приложениях SAP, таких как SAP ERP, SAP ECC, SAP S/4 HANA, а также в семействе приложений SAP Business Suite, таких как SAP BI/BW, SAP CRM, SAP SCM, SAP PLM и других. При работе с SAP WinGUI в UiPath Studio можно использовать любые темы (Belize, Blue Crystal, Corbu), для работы робота обязательно должен быть включен SAP WinGUI scripting.

Кроме того, с помощью UiPath можно комфортно поддерживать очень актуальную сегодня миграцию на SAP S/4 HANA на всех ее стадиях от проектирования до разработки:

Подготовка данных;
Мэппинг и кастомизация;
Миграция данных;
Тестирование;
Постмиграция.

Еще одна интересная фича, которую предлагает UiPath акселераторы. Акселераторы это преднастроенные процессы для часто используемых действий в SAP. Они доступны бесплатно и значительно упрощают внедрение автоматизации. Например, можно использовать стандартные задачи, такие как добавить нового пользователя SAP или создать нового поставщика как шаблоны для разработки. Этим самым процесс развертывания RPA-автоматизации значительно ускоряется, даже если сами процессы сразу использовать не получится.

Акселераторы UiPath можно загрузить непосредственно с UiPath Marketplace, они содержат готовые рабочие процессы для наиболее часто используемых транзакций и приложений в SAP ECC и SAP S/4HANA. Их можно использовать как для автоматизации роботизированных процессов SAP, так и в качестве тестовых примеров. Время на внедрение робота с помощью акселераторов сокращается на 30%.

Гайд: с чего начинается работа по роботизации SAP в UiPath Studio

Для автоматизации SAP можно использовать стандартные активности UiPath, такие как Click или Type into. Но мы сегодня остановимся подробнее на тех активностях, которые были специально разработаны для взаимодействия с SAP.

SAP Logon активность для подключения к системе SAP через окно SAP Logon.

Необходимо прописать в соответствующих полях SAP Logon Path и Connection Name

C помощью SAP Logon мы выбираем то подключение, с которым хотим работать.

SAP Login используется для входа конкретного пользователя.

Нужно заполнить поля: клиент, пользователь, пароль, язык.

После того как мы откроем основное окно, мы можем пользоваться и другими активностями. Среди них:

Call Transaction вызов транзакции. В параметрах указываем код транзакции.

Click Toolbar Button нажатие на действие, доступное в Toolbar.

Select Menu Item выбор элемента меню, по аналогии с активностью Click Toolbar Button в списке для выбора отобразятся даже вложенные элементы.

Для того, чтобы понять как с ними работать, посмотрим пример. На скриншоте отображена транзакция создания нового заказа (ME21N).

Используя активность Click Toolbar Button, мы получаем доступ к тем элементам, которые могут быть доступны с использованием горячих клавиш:

Несмотря на то, что на экране мы не видим элемент подменю Other Purchase Order, робот может вызвать его напрямую без совершения нескольких кликов по различных подменю. Активность Select Menu Item нам даст возможность выбрать любой из элементов меню и подменю.

Активность Read Status Bar позволяет прочитать сообщения из статус-бара. На основе полученных сообщений, робот может принимать решение о дальнейших действиях. Например, если мы ввели в поиске некорректный номер заказа, появится сообщение об ошибке. У этой активности есть 3 выходных параметра:

Message Type стандартные типы статусов SAP: success, error и др.

Message Text сообщение в строке статуса

Message Data поле с данными статуса. В нашем примере с поиском заказа в нем будет номер открытого на экране заказа. Получив этот номер, мы можем сделать вывод открыт ли на экране тот заказ, который мы искали. Из этого поля можно напрямую извлекать данные без обработки строки сообщения.

Таким образом, зная, какой статус ожидать, мы можем валидировать выполнилось ли действие успешно.

Expand Tree активность, позволяющая выбрать любой элемент в дереве SAP.

Данные действия используются чаще всего, но в студии также есть и другие активности для взаимодействия с SAP.

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

В последующем бухгалтер делает ряд проверок: ищет заказ в учетной системе 1С или SAP. Проверяет, что заказ действительно существует, что позиции в заказе совпадают с указанными в счете-фактуре, совпадают реквизиты поставщика, что есть поступление материалов на склад и т.д.. И только после выполнения всех этих проверок в систему заводится счет-фактура. Все эти действия могут выполняться роботом.

В очень упрощенном варианте процесс может выглядеть так:

Пример процесса работы со счетом-фактурой

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

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

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

В нашем случае робот извлекает данные заказа из SAP и проверяет сумму к оплате. Она не совпадает, и робот создает пользователю задачу в Action Center на проверку счета-фактуры.

В задаче для пользователя робот отобразит данные заказа из SAP и поля самого счета-фактуры. Также мы увидим уведомление о том, что сумма к оплате не совпадает. Формы для такой задачи создаются в UiPath Studio с использованием low-code и могут выглядеть так, как вам удобно.

В нашем примере задача проверки выглядит так:

Робот может делать и более сложные проверки. Например, проверять, есть ли товар на складе, совпадает ли количество позиций и т.д. В зависимости от того, какую ошибку робот находит, он может направлять задачу ответственному человеку. Если проблема в заказе инициатору заказа, если проблема с поставкой кладовщику. И больше никаких звонков и электронной почты, робот может автоматически распределить задачи между людьми. В случае отсутствия ошибок в счете-фактуре, робот вводит все данные в учетную систему.

После согласования с пользователем счёта-фактуры, робот автоматически продолжает свою работу. В SAP вызывается транзакция MIRO для заведения счетов-фактур, в которую робот вводит необходимые данные.

Посмотреть видео этого процесса с взаимодействием в SAP можно на YouTube-канале UiPath.

Что в итоге

Решение UiPath делает автоматизацию работы в SAP для бизнеса проще, чем когда-либо. UiPath является первой компанией RPA, получившей полную сертификацию как по SAP UI, так и по SAP API автоматизации. Подробнее с каталогом сертифицированных решений SAP можно ознакомиться здесь.

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

Подробнее..

Категории: It-инфраструктура , Автоматизация , It-компании , Исследования и прогнозы в it , Uipath , Sap , Rpa

Учиться, учиться, и ещё раз учиться?

01.06.2021 14:09:01 |

Автор: admin

TLDR: крохотные модельки обошли модные графовые нейронки в предсказании свойств молекул.
Код: здесь. Берегите Природу.

^{ФОТО: Андерс Хеллберг для Wikimedia Commons, модель Грета
Тунберг}

Необученная графовая свёрточная нейронная сеть [1] (uGCN) со случайной инициализацией весов уже пару лет занимает первое место в моём списке алгоритмов для задач машинного обучения на графах из-за копеечной стоимости, простоты реализации, да вполне очевидной элегантности решения. В то же время, насколько мне известно, никто ещё не не проводил соревнований между этой простой моделью и её старшей сестрой полноценно обученной графовой свёрточной нейронной сетью (GCN) в режиме обучения с учителем. Вот я сделал.

Мотивация: показать, что uGCN выдаёт качественные представления, которые можно использовать в последующих задачах машинного обучения в индуктивном режиме, когда модели обобщаются к не виденным ранее данным (вдохновлено недавним отчётом [2] о производительности простых моделей в трансдуктивном случае).

Полученные результаты занимательны. В худшем случае простые модели (uGCN + degree kernel + random forest) показали счёт 54:90 против полноценно обученных GCN, в то время как реалистичный сценарий закончился разгромным реваншем 93:51, указывающим на то, что мы можем позволить себе почти бесплатные эмбеддинги, которые превосходят или показывают результаты на уровне полноценно обученных GCN в задаче предсказания свойств графа (например эффекта медикаментов: яд или лекарство) за долю стоимости. Простые модели обучались ~10 минут в то время как весь эксперимент продлился ~4 часа. Перейдём же к деталям и разберёмся с тем, что произошло!

Основные понятия

Многие из важных наборов данных об окружающем нас мире имеют связный характер: социальные сети, графы знаний, взаимодействия белков, всемирная паутина WWW и т.д. (просто несколько примеров) [1].

Граф, обыкновенно записываемый как G=(V, E) это математическая модель, множество множеств, состоящее из набора вершин V и множества рёбер E попарных связей e(i, j) между вершинами i и j. Расширением Графа является модель Граф со Свойствами (Labeled Property Graph), позволяющий задать вектор признаков xi для вершины i (мы также можем определять свойства для рёбер, однако это выходит за рамки сегодняшнего эксперимента). Графовая нейронная сеть [3] (GNN) это модель машинного обучения (параметрическая функция, которая подбирает, другими словами выучивает, параметры из данных), расширяющая возможности хорошо известного семейства алгоритмов, вдохновлённых биологией, до работы с неструктурированными данными в виде графов. На мой взгляд, передача сообщений это самая простая интуиция для понимания механики работы GNN и вполне оправдано обратиться к мнемоническому правилу 'скажи мне, кто твой друг и я скажу тебе кто ты'. Графовые свёрточные нейронные сети (GCN) очень подробно описал их изобретатель здесь (https://tkipf.github.io/graph-convolutional-networks/) и мне, право, непросто что-то ещё добавить к этой замечательной истории.

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

Многослойная GCN с фильтрами первого порядка.

Данные

Проведём серию экспериментов на общедоступных данных. Мы обратимся к (i) коллекции TUDatasets [4] и (ii) ограничим наше упражнение задачей бинарной классификации (предсказанием свойств) небольших молекул. Ещё одним условием нашего мероприятия будет (iii) использование графов с признаками вершин.

Заданные ограничения оставляют нам несколько наборов данных, широко используемых для сравнения современных алгоритмов. Вот наш итоговый список: AIDS, BZR, COX2, DHFR, MUTAG и PROTEINS. Все обозначенные наборы данных доступны как часть Pytorch Geometric [5] (библиотека для глубокого обучения на графах) в двух версиях: оригинальной и очищенной от дубликатов [6]. Итого у нас будет 12 датасетов.

AIDS Antiviral Screen Data [7]

Результаты экспериментов по выявлению химических соединений, негативно влияющих на вирус иммунодефицита человека. Представляет собой результат тестирования и химическую структуру соединений не покрытых соглашениями о неразглашении. В оригинальном наборе содержится 2000 молекул, а очищенная версия оставляет нам 1110 точек данных, каждая из которых представляет собой граф, вершины которого описывают 37 признаков.

Benzodiazepine receptor (BZR) ligands [8]

Оригинальный набор содержит 405 молекул, очищенная версия 276, по 35 признаков на вершину.

Cyclooxygenase-2 (COX-2) inhibitors [8]

Оригинальный набор содержит 467 молекул, очищенная версия 237, по 35 признаков на вершину.

Dihydrofolate reductase (DHFR) inhibitors [8]

Оригинальный набор содержит 756 молекул, очищенная версия 578, 35 признаков на вершину.

MUTAG [9]

В наборе содержится 188 химических соединений, разделённых на два класса согласно их мутагенному воздействию на бактерии. В очищенной версии 135 молекул, 7 признаков на вершину.

PROTEINS [10]

Энзимы и не-энзимы. В оригинальном наборе содержится 1113 молекул, по 3 признака на вершину. Очищенная версия 975 структур.

Дизайн Эксперимента

Мы устроим турнир!

Для каждого набора данных проведём 12 раундов обучения и тестирования.

В каждом раунде:

(1) псевдослучайным образом разделим данные в пропорции 80/20 в Pytorch Geometric (начиная со стартового параметра генератора random seed = 42 и увеличивая его на единицу в каждом последующем раунде), таким образом 80% точек данных (графов) будут использованы в качестве обучающей выборки, а оставшиеся 20% будут тестовой выборкой;

(2) обучим модели и оценим долю верных ответов (accuracy) на тесте.

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

Для GCN мы проводим 200 эпох обучения и тестирования со скоростью обучения learning rate = 0.01 и принимаем во внимание:
(А) среднее значение доли верных ответов для 10 финальных эпох обучения реалистичный сценарий;
(В) наибольшее значение доли верных ответов, достигнутое в процессе обучения (как если бы мы сохраняли промежуточное состояние для того, чтобы выбрать наилучшую модель впоследствии) наилучший сценарий для GCN (и наихудший для простых моделей);

(3) лучшей модели присуждается 1 балл;

(4) в случае ничьей балл присуждается лёгкой модели.

Всего будет распределено 288 баллов: 12 датасетов 12 раундов 2 сценария.

Модели

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

import networkx as nximport numpy as np from scipy.sparse import csgraph# g - граф формате популярной библиотеки NetworkXnumNodes = len(g.nodes)degreeHist = nx.degree_histogram(g)# нормализуемdegreeHist = [x/numNodes for x in degreeHist]

Необученная графовая свёрточная нейронная сеть (uGCN) со случайной инициализацией весов 3 слоя с промежуточной нелинейной активацией (ReLU, т.е. f(x) = max(x, 0)). Аггрегация усреднением полученных после прямого прохода 64-разрядных векторов (эмбеддинги вершин) позволяет получить компактное представление графа. Это на самом деле очень просто.

A = nx.convert_matrix.to_scipy_sparse_matrix(g)

Воспользуемся вариантом реализации одного слоя свёртки в три строки, который пару лет назад предложил iggisv9t :

# A - матрица связности графа# X - матрица признаков вершин (np.array)D = sparse.csgraph.laplacian(A, normed=True)shape1 = X.shape[1]X = np.hstack((X, (D @ X[:, -shape1:])))

(код здесь приводится чтобы подчеркнуть очаровательный минимализм реализации метода)

Разберём его на части и пересоберём заново.

Использованная реализация uGCN выглядит так:

# A - матрица связности графа# X - матрица признаков вершин (np.array)# W0, W1, W2 - случайным образом инициализированные весаD = sparse.csgraph.laplacian(A, normed=True)# слой 0Xc = D @ X @ W0# ReLUXc = Xc * (Xc>0)# конкатенация признаков вершин с аггрегированной информацией соседейXn = np.hstack((X, Xc))# слой 1Xc = D @ Xn @ W1# ReLUXc = Xc * (Xc>0)Xn = np.hstack((Xn, Xc))# слой 2 - эмбеддинги вершинXc = D @ Xn @ W2# аггрегация усреднением - эмбеддинг графаembedding = Xc.sum(axis=0) / Xc.shape[0]

Комбинация DK и uGCN (Mix) конкатенацией представлений графа, полученных с помощью моделей DK и uGCN.

mix = degreeHist + list(embedding)

Для каждой из первых трёх моделей обучаем классификатор случайный лес из 100 деревьев с максимальной глубиной в 17 ветвлений.

Графовая свёрточная нейронная сеть (GCN) полноценно обученный классификатор, состоящий из 3 свёрточных слоёв размерностью 64 с промежуточной нелинейной активацией (ReLU), агрегацией усреднением (до этого момента архитектура GCN очень похожа на uGCN), за которой следует слой регуляризации дропаутом (произвольным обнулением разрядов с вероятностью 50%) и линейный классификатор. Мы будем обозначать результаты модели, отобранные в наилучшем для GCN сценарии (B) как GCN-B, а модели в реалистичном сценарии (А) как GCN-A.

Результаты

После 144 раундов (12 датасетов * 12 раундов) сравнения качества предсказаний на отложенной выборке между простыми моделями и полноценно обученными графовыми свёрточными сетями 288 баллов распределились как:

147:141

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

Наборы данных, в которых простые модели побеждают: AIDS, DHFR(A) и MUTAG.

Например, DK собрала все 48 баллов для набора данных AIDS, демонстрируя отрыв более чем на 10% (абсолютное значение) от доли верных ответов полноценно обученной GCN.

Здесь побеждают GCN: BZR, COX2 и PROTEINS.

Индивидуальный зачёт:
90 GCN-B;
71 DK;
55 Mix (uGCN + DK);
51 GCN-A;
21 uGCN.

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

В целом, результаты стабильно варьировались между очищенными и оригинальными наборами данных. Это ещё раз напоминает о важности качества данных для проведения адекватных сравнений между моделями. Хорошая новость в том, что в исследовательском сообществе уже есть движение в данном направлении и значительные усилия лучших умов в области уже направлены на организацию честных турниров.

Выводы

Как видим, проведенный эксперимент подтверждает предположение о том, что в задаче предсказания свойств молекул мы можем позволить себе использовать почти бесплатные эмбеддинги, которые превосходят или показывают результаты на уровне полноценно обученных нейронных сетей. Наблюдения согласуются с вдохновляющими этот эксперимент результатами [2] в том, что концептуально метод Label Propagation очень похож на передачу сообщений в графовой свёрточной нейронной сети. Объяснение эффективности скорее всего следует искать в том, что на самом деле мощнее подбирать параметры фильтров для того, чтобы внутренние представления, выученные сетью стали линейно разделимыми, либо же просто использовать классификатор помощнее, как это сделано в рассмотренном примере.

Дисперсия результатов между раундами соревнования напоминает о том, что всякое сравнение дело непростое. Здесь стоит упомянуть Free Lunch Theorem и напомнить о том, что использовать сразу несколько моделей в построении решения скорее хороший тон. Также важно отметить влияние разбиения на выборки в ходе сравнения на одном и том же наборе данных одна и та же модель может показывать очень разное качество. Поэтому сравнивая модели, убедитесь, что обучаете и тестируете их на идентичных выборках. К слову, фиксация параметров генератора псевдослучайных чисел не панацея

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

Послесловие

В лекции открытого курса по графам знаний GCN названа Королевской Лазейкой Через Пространство Фурье, этот ярлык приклеился с тех пор, когда впервые выступил на публике с рассказом о силе графов и провёл первые эксперименты с классификацией картинок (как графов) для того, чтобы продемонстрировать мощь спектральных фильтров одной юной леди, запускавшей стартап в милой моему сердцу аэрокосмической области. Данная заметка появилась в результате того, что пару недель назад в реальной задаче на закрытых данных uGCN, вместе с простенькими моделями показали результат, который полноценно обученные GCN смогли превзойти всего на 2% (96 против 98) и мне вздумалось проверить вопрос о том, кто кого заборет ещё на каких-нибудь данных.

В наши дни машинное обучение на графах превратилось в знаменитость, всё больше исследователей обращают внимание на эту область и новые архитектуры графовых нейронных сетей появляются каждую неделю. Однако на самом деле мы ещё не очень хорошо понимаем почему GNN так успешны и нужны ли они для хорошего качества решения [2].

Перед тем, как ступать на очаровательный путь машинного обучения на графах, пожалуйста ознакомьтесь с основами этого дела. Значительные усилия прилагаются к тому, чтобы сделать новейшие достижения (да и классические методы тоже) доступными широкой аудитории совершенно бесплатно. Упомяну лишь несколько из таких инициатив: материалы и лекции стенфордского cs224w, площадку для тестирования качества алгоритмов Open Graph Benchmark [14] и недавнюю работу об основах геометрического глубокого обучения [15] методологию разработки новых архитектур нейронных сетей. Напоследок, ещё раз напомню о том, что начинать проекты машинного обучения стоит с простых методов, вроде ядер и необученных графовых свёрточных сетей достаточно часто эти модельки показывают неприлично хороший уровень.

Берегите Природу, используйте алгоритмы эффективно. Порою неученье сила.

Литература

[1] Kipf & Welling, Semi-Supervised Classification with Graph Convolutional Networks (2017), International Conference on Learning Representations;
[2] Huang et al., Combining Label Propagation and Simple Models out-performs Graph Neural Networks (2021), International Conference on Learning Representations;
[3] Scarselli et al., The Graph Neural Network Model (2009), IEEE Transactions on Neural Networks ( Volume: 20, Issue: 1, Jan. 2009);
[4] Morris et al.,TUDataset: A collection of benchmark datasets for learning with graphs (2020), ICML 2020 Workshop on Graph Representation Learning and Beyond;
[5] Fey & Lenssen, Fast Graph Representation Learning with PyTorch Geometric (2019), ICLR Workshop on Representation Learning on Graphs and Manifolds;
[6] Ivanov, Sviridov & Burnaev, Understanding isomorphism bias in graph data sets (2019), arXiv preprint arXiv:1910.12091;
[7] Riesen & Bunke, IAM Graph Database Repository for Graph Based Pattern Recognition and Machine Learning (2008), In: da Vitora Lobo, N. et al. (Eds.), SSPR&SPR 2008, LNCS, vol. 5342, pp. 287-297;
[8] Sutherland et al., Spline-fitting with a genetic algorithm: a method for developing classification structure-activity relationships (2003), J. Chem. Inf. Comput. Sci., 43, 1906-1915;
[9] Debnath et al., Structure-activity relationship of mutagenic aromatic and heteroaromatic nitro compounds (1991), J. Med. Chem. 34(2):786-797;
[10] Dobson & Doig, Distinguishing enzyme structures from non-enzymes without alignments (2003), J. Mol. Biol., 330(4):771783;
[11] Pedregosa et al., Scikit-learn: Machine Learning in Python (2011), JMLR 12, pp. 2825-2830;
[12] Waskom, seaborn: statistical data visualization (2021), Journal of Open Source Software, 6(60), 3021;
[13] Hunter, Matplotlib: A 2D Graphics Environment (2007), Computing in Science & Engineering, vol. 9, no. 3, pp. 90-95;
[14] Hu et al., Open Graph Benchmark: Datasets for Machine Learning on Graphs (2020), arXiv preprint arXiv:2005.00687;
[15] Bronstein et al., Geometric Deep Learning: Grids, Groups, Graphs, Geodesics, and Gauges (2021), arXiv preprint arXiv:2104.13478.

Подробнее..

Автозаказ как сделать так, чтобы нужные продукты сами попадали на полки 17000 магазинов по всей стране

17.06.2021 18:06:38 |

Автор: admin

В школе все мы решали задачки вида едет из пункта А в пункт Б. Речь преимущественно шла о скорости и времени как быстро доберётся транспортное средство? Реальность, однако, подбрасывает задачки значительно интереснее: Существует масштабная ритейл-сеть по продаже товаров, которой необходимо, чтобы огромное количество номенклатурных позиций доезжало в каждый из 17000 магазинов, расположенных на половине площади самой большой страны в мире, вовремя и в нужном количестве. Для решения такой задачи в X5 Group существует ряд реализованных решений, и одним из самых важных является процесс автозаказа товаров.

Техническую поддержку этого направления в X5 Group обеспечивает команда 2-SAP Логистики.

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

Автозаказ это комплекс процессов управления запасами и заказами

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

Планирование заказа.

Формирование заказа.

Отправка заказа.

Экономическое обоснование поддерживаемого уровня.

Контроль за состоянием запасов.

Управление ассортиментом.

Для этого используются разные механизмы прогнозирования в зависимости от формата магазина и гибких настроек в системе.

Прогноз продаж, построенный SAP это прогноз спроса на период 42 дня, который строится на исторических данных по продажам. Период анализа продаж и модель прогноза определяется из настройки Профиля прогноза.

В периоде анализа продажи могут быть Плановые регулярные продажи и Внеплановые промо продажи.

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

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

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

Около 04:30 эти данные по потребности из JDA поступают в SAP, где обрабатываются фоновым заданием с интервалом запуска каждые 15 минут, в результате чего создаются Автозаказы.

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

Большую роль этот функционал играет для персонала магазинов магазинах, так как он исключает необходимость формировать заказы вручную. За исключением отдельных случаев всё происходит в автоматическом режиме с учетом большого количества факторов и сложных расчетов. Автозаказ облегчает ежедневный труд тысяч сотрудников по всей стране от Калининграда до Новосибирска.

Через автозаказ пополняется до 80% основного ассортимента магазинов, а ручное пополнение выполняется для товаров in-out.

Схема реализации товара:

Классическое пополнение происходит примерно в таком виде: представим, что есть некий товар, допустим, это пакет молока, который поставляется напрямую от внешнего поставщика в магазин торговой сети Пятёрочка.

Так выглядит децентрализованная цепочка:

- в 00:00 стартует задание по АЗ, в период его работы по нашему товару рассчиталась потребность, сформировался автозаказ, и он бы отправлен из SAP в программу магазина GK(Пятёрочка), там у сотрудников магазина есть время отредактировать рассчитанное кол-во (в большую или меньшую сторону) до наступления времени автосогласования (например, до 11 утра, время зависит от тайминга поставщика, т.е. до какого момента он должен получить заказ, чтобы собрать и вовремя привезти заказ в магазин);

- после внесения корректировок эти изменения отправляются в SAP, и дальше происходит процесс автосогласования заказ согласовывается и автоматически отправляется поставщику по почте или его провайдеру (в зависимости от того, по какой схеме поставщик работает). Например, если поставщик работает по EDI (через электронный документооборот), то после доставки заказа в его систему, нам провайдер передает информацию о размещении заказа в своем ПО и в системе ER2 заказ переходит в статус Размещен;

- далее нам поступает буфер приемки, который мы передаем в ПО магазина. По этому буферу магазин осуществит приемку товара от поставщика. После осуществления приемки поставщику отправляется информация об этом. На этом путь закончен, сотрудникам магазина остается выставить на полки товар и продать его счастливым покупателям.

Автозаказ (Ночной профиль) фоновое задание, имеющее внутри себя несколько шагов, выполняющих определённые функции. Результатом задания является создание заказов на закупку товаров. Запускается параллельно по магазинам.

На ежедневной основе автозаказ формирует более 400 000 тысяч заказов для магазинов, как на распределительные центры, так и внешним поставщикам.

Продажи за период в прошлом
Прогноз на период в будущее (на основании продаж строится прогноз SAP)
Остатки на объекте получателе (остаток в SAP на момент расчёта)
Открытые заказы (заказы на поставку и возвраты)

Продажи приходят из магазинов каждый вечер до расчёта фонового задания Автозаказа.

Факт получения продаж запускает расчет Автозаказа. Если до 03:00 продажи не получены SAP ERP, то происходит безусловный запуск задания Автозаказа.

Автозаказ формируется строго по графику заказа/поставки согласованному с поставщиком, так категории FRESH и ULTRA FRESH, как правило, заказываются и поставляются в магазины ежедневно.

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

Для того, чтобы заказать оптимальное кол-во товара, учитывается прогноз, который строится в SAP в момент расчета Автозаказа.

Если по этому товару уже есть запас или размещенный заказ, который еще не закрыт, то система также учтёт это при определении размера финального заказа.

Автозаказ определяет цепочку и поставщика по каждому товару для каждого магазина, согласно записей книги источников поставок (смежный функционал, автоматизирован, и ведется также в SAP) и формирует заказ.

Запускается задание ежедневно в 00:00. Первыми выполняются расчеты по регионам Сибирь и Урал, далее по регионам Волга, ЮГ, Москва, Центральные регионы и Северо-запад. Последовательность выполнения крайне важна, т.к. наши магазины расположены в разных часовых поясах, и пока в Москве все сладко спят, в Сибири уже в разгаре рабочий день.

Задача нашей команды контролировать, поддерживать и обеспечивать работоспособность автозаказа на каждом шаге, а в случае каких-либо сбоев в системе, проактивно реагировать и минимизировать возможный ущерб для бизнеса и для наших покупателей.

Для этого мы реализовали различные системы мониторинга, инструменты для анализа, а в случае необходимости и возможность отправки в магазины резервных шаблонов заказа.<o:p>

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

Также предусмотрен инструмент для выгрузки резервных заказов, рассчитанных накануне, в случае сбоев в системе JDA по прогнозированию и пополнению магазинов больших форматов Перекрёсток и Карусель.

Подробнее..

Категории: Визуализация данных , Автоматизация , Промышленное программирование , Erp-системы , Разработка под e-commerce , Ритейл , Автоматизация рутины , Sap , Автоматизация бизнеса , Блог компании x5 retail group , Прогноз , Логистика , Прогнозирование спроса , Логистические цепочки

Экстракция данных из SAP HCM в non-SAP хранилища данных

23.09.2020 16:18:12 |

Автор: admin

Как известно, компания SAP предлагает полный спектр программного обеспечения, как для ведения транзакционных данных, так и для обработки этих данных в системах анализа и отчетности. В частности платформа SAP Business Warehouse (SAP BW) представляет собой инструментарий для хранения и анализа данных, обладающий широкими техническими возможностями. При всех своих объективных преимуществах система SAP BW обладает одним значительным недостатком. Это высокая стоимость хранения и обработки данных, особенно заметная при использовании облачной SAP BW on Hana.

А что если в качестве хранилища начать использовать какой-нибудь non-SAP и желательно OpenSource продукт? Мы в Х5 Retail Group остановили свой выбор на GreenPlum. Это конечно решает вопрос стоимости, но при этом сразу появляются вопросы, которые при использовании SAP BW решались практически по умолчанию.

В частности, каким образом забирать данные из систем источников, которые в большинстве своем являются решениями SAP?

HR-метрики стал первым проектом, в котором необходимо было решить эту проблему. Нашей целью было создание хранилища HR-данных и построение аналитической отчетности по направлению работы с сотрудниками. При этом основным источником данных является транзакционная система SAP HCM, в которой ведутся все кадровые, организационные и зарплатные мероприятия.

Экстракция данных

В SAP BW для SAP-систем существуют стандартные экстракторы данных. Эти экстракторы могут автоматически собирать необходимые данные, отслеживать их целостность, определять дельты изменений. Вот, например, стандартный источник данных по атрибутам сотрудника 0EMPLOYEE_ATTR:

Результат экстракции данных из него по одному сотруднику:

При необходимости такой экстрактор может быть модифицирован под собственные требования или может быть создан свой собственный экстрактор.

Первой возникла идея о возможности их переиспользования. К сожалению, это оказалось неосуществимой задачей. Большая часть логики реализована на стороне SAP BW, и безболезненно отделить экстрактор на источнике от SAP BW не получилось.

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

Структура хранения данных в SAP HCM

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

Большинство данных в SAP HCM хранится в плоских SQL таблицах. На основании этих данных приложения SAP визуализируют пользователю оргструктуры, сотрудников и прочую HR информацию. Например, вот так в SAP HCM выглядит оргструктура:

Физически такое дерево хранится в двух таблицах в hrp1000 объекты и в hrp1001 связи между этими объектами.

Объекты Департамент 1 и Управление 1:

Связь между объектами:

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

Отображение руководителя в SAP:

Хранение в таблице БД:

Данные по сотрудникам хранятся в таблицах pa*. Например, данные о кадровых мероприятиях по сотруднику хранятся в таблице pa0000

Мы приняли решение, что GreenPlum будет забирать сырые данные, т.е. просто копировать их из SAP таблиц. И уже непосредственно в GreenPlum они будут обрабатываться и преобразовываться в физические объекты (например, Отдел или Сотрудник) и метрики (например, среднесписочная численность).

Было определено порядка 70 таблиц, данные из которых необходимо передавать в GreenPlum. После чего мы приступили к проработке способа передачи этих данных.

SAP предлагает достаточно большое количество механизмов интеграции. Но самый простой способ прямой доступ к базе данных запрещен из-за лицензионных ограничений. Таким образом, все интеграционные потоки должны быть реализованы на уровне сервера приложений.
Следующей проблемой было отсутствие данных об удаленных записях в БД SAP. При удалении строки в БД, она удаляется физически. Т.е. формирование дельты изменений по времени изменения не представлялось возможным.

Конечно, в SAP HCM есть механизмы фиксация изменений данных. Например, для последующей передачи в системы получатели существуют указатели изменений(change pointer), которые фиксируют любые изменения и на основании которых формируются Idoc (объект для передачи во внешние системы).

Пример IDoc изменения инфотипа 0302 у сотрудника с табельным номером 1251445:

Или ведение логов изменений данных в таблице DBTABLOG.

Пример лога удаления записи с ключом QK53216375 из таблицы hrp1000:

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

Следующей серьезной проблемой были кластерные таблицы. Данные оценки времени и расчета зарплаты в RDBMS версии SAP HCM хранятся в виде набора логических таблиц по каждому сотруднику за каждый расчет. Эти логические таблицы в виде двоичных данных хранятся в таблице pcl2.

Кластер расчета заработной платы:

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

Оценивая варианты с формированием дельты изменения данных, решили так же рассмотреть вариант с полной выгрузкой. Вариант каждый день передавать гигабайты неизменных данных между системами не может выглядеть красиво. Однако он имеет и ряд преимуществ нет необходимости как реализации дельты на стороне источника, так и реализация встраивания этой дельты на стороне приемника. Соответственно, уменьшается стоимость и сроки реализации, и повышается надежность интеграции. При этом было определено, что практически все изменения в SAP HR происходят в горизонте трех месяцев до текущей даты. Таким образом, было принято решение остановиться на ежедневной полной выгрузке данных из SAP HR за N месяцев до текущей даты и на ежемесячной полной выгрузке. Параметр N зависит от конкретной таблицы
и колеблется от 1 до 15.

Для экстракции данных была предложена следующая схема:

Внешняя система формирует запрос и отправляет его в SAP HCM, там этот запрос проверяется на полноту данных и полномочия на доступ к таблицам. В случае успешной проверки, в SAP HCM отрабатывает программа, собирающая необходимые данные и передающая их в интеграционное решение Fuse. Fuse определяет необходимый топик в Kafka и передает данные туда. Далее данные из Kafka передаются в Stage Area GP.

Нас в данной цепочке интересует вопрос извлечения данных из SAP HCM. Остановимся на нем подробнее.

Схема взаимодействия SAP HCM-FUSE.

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

Данные запроса передаются в body в формате json.
Метод http: POST.
Пример запроса:

Сервис SAP выполняет контроль запроса на полноту, соответствие текущей структуре SAP, наличие разрешения доступа к запрошенной таблице.

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

Внешняя система в случае ошибки регистрирует ее в журнале. В случае успешного ответа передает id сессии и имя таблицы по которой был сделан запрос.

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

Фоновое задание SAP формирует курсор по заданным параметрам и пакет данных заданного размера. Размер пакета максимальное количество записей, которые процесс читает из БД. По умолчанию принимается равным 2000. Если в выборке БД больше записей, чем используемый размер пакета после передачи первого пакета формируется следующий блок с соответствующим offset и инкрементированным номером пакета. Номера инкрементируются на 1 и отправляются строго последовательно.

Далее SAP передает пакет на вход web-сервису внешней системы. А она система выполняет контроли входящего пакета. В системе должна быть зарегистрирована сессия с полученным id и она должна находиться в открытом статусе. Если номер пакета > 1 в системе должно быть зарегистрировано успешное получение предыдущего пакета (package_id-1).

В случае успешного контроля внешняя система парсит и сохраняет данные таблицы.

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

В случае ошибки контролей/разбора ошибка логируется и пакеты по данной сессии будут отклоняться внешней системой.

Так же и в обратном случае, когда внешняя система возвращает ошибку, она логируется и прекращается передача пакетов.

Для запроса данных на стороне SAP HСM был реализован интеграционный сервис. Сервис реализован на фреймворке ICF (SAP Internet Communication Framework help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html). Он позволяет производить запрос данных из системы SAP HCM по определенным таблицам. При формировании запроса данных есть возможность задавать перечень конкретных полей и параметры фильтрации с целью получения необходимых данных. При этом реализация сервиса не предполагает какой-либо бизнес-логики. Алгоритмы расчёта дельты, параметров запроса, контроля целостности, и пр. также реализуются на стороне внешней системы.

Данный механизм позволяет собирать и передавать все необходимые данные за несколько часов. Такая скорость находится на грани приемлемой, поэтому это решение рассматривается нами как временное, позволившее закрыть потребность в инструменте экстракции на проекте.
В целевой картине для решения задачи экстракции данных прорабатываются варианты использования CDC систем типа Oracle Golden Gate или ETL инструментов типа SAP DS.

Подробнее..

Категории: Метрики , Open source , Big data , Хранилища данных , Hr , Хранилище данных , Интеграция , Сотрудники , Sap , Блог компании x5 retail group , Sap bw , Экстрактор , Таблицы

Из песочницы Налоговый мониторинг через доступ в систему SAP (раскрытие)

08.11.2020 14:17:04 |

Автор: admin

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

Я бы дал дополнительное определение налогового мониторинга это цифровизация камеральных проверок, перевод их из разовых мероприятий в форму постоянного мониторинга деятельности предприятия. Для налогоплательщика появляется возможность управлять налоговыми рисками через мотивированное мнение налогового органа, т.е. получать предупреждения от ФНС с возможностью принять меры для устранения налогового риска.

Если говорить про прогнозы, то я бы достаточно большой долей вероятности дал бы прогноз, что к 2030 году все предприятия от средних и больше будут вынуждены вступить в налоговый мониторинг. Государство уже задало вектор движения путем изменения налогового законодательства и уменьшением порога входа в налоговый мониторинг: https://sozd.duma.gov.ru/bill/1025470-7

Существует 3 формы взаимодействия с ФНС в рамках налогового мониторинга:

Доступ ФНС в учетную систему
Витрина
ТКС

Информация из открытых источников:

Как видно из слайда, набирает популярность форма взаимодействия с ФНС на основе витрины. Существует достаточно много поставщиков коробок для витрины, в том числе и SAP.

В данной статье способ взаимодействия через ТКС рассматривать не будем, т.к. этот способ скорее возможность вступить в налоговый мониторинг организациям, которым по каким-то причинам нужен этот режим, но экспертизы \ времени \ ресурсов не хватает для витрины или прямого доступа. Но, с другой стороны, после того как ГНИВЦ выполнит планы по созданию облачной системы налогового мониторинга, то способ ТКС, возможно, ждет реинкарнация как интерфейса между облаком ГНИВЦ и учетными системами налогоплательщика.

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

Нужно понимать, что витрина данных никакого отношения к СВК не имеют. СВК можно реализовать в ручном режиме и тут тон задают методологи и написанные ими регламенты. Если говорить про автоматизацию, то другого решения кроме SAP GRC Risk Management and Process Control мне не известны и вряд ли есть. Почему вряд ли контроли должны быть встроены в бизнес процессы, реализованные в SAP и такая интеграция кажется возможной только силами вендора и его продуктов.

Если смотреть на витрину с точки зрения интерфейса, то создать аналог для прямого доступа в виде АРМ Налоговый мониторинг на ABAP не представляется сложным (скриншот примера АРМ ниже).

Рассмотрим решения по блокам \ блокам работ:

Таким образом, для функционального заказчика и ИТ заказчика есть над чем подумать, если расчет налогов осуществляется в SAP, особенно с учетом того, что прямой доступ организует единое пространство работы для налоговых бухгалтеров и ФНС, а витрина заставляет налоговых бухгалтеров работать как в учетной системе, так и в отдельной витрине со всеми вытекающими последствиями в виде дополнительных сверок.

Подробнее..

Категории: Анализ и проектирование систем , Законодательство в it , Erp-системы , Sap , Налоговый мониторинг

Масштабный проект по внедрению SAP S4HANA в удаленном режиме Гибридный интеграционный ландшафт

08.06.2021 10:08:20 |

Автор: admin

В предыдущей нашей статье мы рассказывали о том, какие уроки мы усвоили, как мы обучали коллег удаленно и как проводили тестирование системы. В данной статье речь пойдет об интеграционных ландшафтах. Для реализации решения в рамках нашего проекта мы выбрали гибридный интеграционный ландшафт на базе SAP PO и SAP MII. В данной статье мы рассмотрим особенности систем SAP PO и SAP MII, их предназначение, достоинства и недостатки. А также расскажем о трудностях, с которыми мы столкнулись при реализации проекта в 2020 году.

Итак, по порядку.

Интеграционные платформы: как выбрать?

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

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

Согласно SAP CIO Guide: Process and Data Integration in Hybrid Landscapes, существуют следующие классы интеграционных систем:

Process Integration охватывает интеграцию распределённого между системами/приложениями бизнес-процесса. Наиболее предпочтительные инструменты интеграции на базе ESB (Enterprise Service Bus)

Data Integration охватывает синхронизацию данных между приложениями, базами данных и озером данных вне транзакционного контекста. Наиболее предпочтительные инструменты интеграции на базе ETL (Extract, Transform, Load).

User Integration охватывает все задачи интеграции между сервером приложений и интерфейсами взаимодействия с пользователем.

Thing Integration охватывает все сценарии, когда данные из устройств, оборудования должны быть интегрированы с бизнес-приложениями.

Cross Use Cases остальные сценарии, применяемые для сквозного взаимодействия.

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

Опыт российской практики показывает, что компании в основном делают выбор в пользу таких интеграционных систем, как SAP PO (ранее SAP PI). Однако существуют и другие системы, которые также предназначены для интеграции между системами различных уровней. В нашем случае мы использовали интеграционные системы SAP PO и SAP MII.

Ключевые аспекты использования SAP PO и SAP MII

Когда мы подошли к выбору интеграционной платформы, то ориентировались на следующие наиболее важные аспекты, которые нужно учитывать при разработке архитектуры межсистемной интеграции:

1. SAP PO следует использовать для интеграции процессов в качестве основной Корпоративной сервисной шины (ESB) предприятия (Например, ERP с Банк-клиентом), а также когда требуется:

Использовать репозиторий корпоративных сервисов в качестве центрального репозитория SOA

Использовать поддержку дополнительных стандартов WS (web service), таких как UDDI, WS-BPEL, и задач, WS-RM в корпоративной среде.

Включение критически важных сценариев интеграции между бизнес-приложениями.

Использование новых функций, таких как аутентификация конечных пользователей, валидация XML и возможности BAM

Взаимодействие с системами, находящимися за рамками DMZ корпоративной сети.

2. SAP MII следует использовать в основном, когда стоит задача обрабатывать данные уровня заводов (MES, LIMS), которые представлены в разнородных хранилищах, которые требуется организовать и проанализировать, а также, когда нужно:

Получать согласованные отчеты о производственных операциях на разных сайтах.

Углубиться в хранилища данных предприятия и в разные хранилища данных для производственных интеллектуальных приложений.

Подключить собственные производственные приложения к данным и рабочим процессам SAP S/4HANA - через стандартные и встроенные адаптеры и инструменты (BAPI/RFC синхронный запрос).

Позволить персоналу предприятия выполнять отчетность (стандартную, мобильную и специальную) наряду с базовыми задачами.

Следует отметить, что система SAP MII по своему прямому назначению, помимо выполнения функции интеграционной шины, также дает возможность выполнять оперативные функции с использованием UI/UX-приложений и реализовать процессы по регистрации данных оперативного учета. Однако использование системы SAP MII только как платформы интеграции не дает никаких преимуществ по сравнению другими системами (например, SAP PO).

3. Наряду с отдельным использованием платформ SAP PO или SAP MII (рассматриваемых в данной статье) также нередки случаи совместного использования одновременно двух этих систем, а именно в тех ситуациях, когда:

SAP MII должен взаимодействовать c SAP S/4HANA (и другими системами корпоративного уровня) через SAP PO в интеграционных сценариях, требующих гарантированную доставку.

SAP PO должен использоваться для централизованного управления потоками данных.

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

В SAP MII должны быть реализованы правила и обработки, специфичные для уровня завода.

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

Преимущества и недостатки SAP PI

Несмотря на то, что верхнеуровнево и SAP PO, и SAP MII поддерживают схожие сценарии интеграции, обе системы разработаны с учетом конкретных сценариев использования.

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

Среди недостатков функционала обеих систем отмечены следующие:

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

Вызовы нашего проекта, и как мы с ними справились

Реализация проектов интеграции систем - непростая задача, требующая согласованной работы различных команд в рамках одной локальной компании или, как в нашем случае, различных команд из нескольких стран с разными часовыми поясами и даже разными языками. К тому же дополнительный уровень сложности для проекта в 2020 году обеспечили пандемия и удаленный формат работы. Все эти трудности заставили нас по-новому посмотреть на взаимодействие между командами, а также внутри команды внедрения.

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

В связи с этим мы пересмотрели весь рабочий процесс, а именно:

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

2. Перешли на scrum-методологию:

Ежедневные встречи, где в формате 15-минутных встреч обсуждали, что сделано, что будет сделано в течение дня и что мешает выполнению задач. Данные встречи помогают решать проблемы быстрее, чем бесконечные переписки.

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

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

3. Хорошей практикой стала демонстрация Клиенту прототипа интеграционного решения. Мы показываем не только интеграцию, но и реализацию бизнес-процессов, и таким образом исключаем неприятные неожиданности.

4. Мы сделали оптимизацию с учетом разных часовых поясов:

Приоритизировали и распределяли задачи в соответствии с часовым поясом членов команд

Планировали ключевые встречи с учетом разницы во времени

С пониманием относились к экстренным запросам во внерабочее время.

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

Пересмотренный подход позволил нам скоординировать работу команд и её в срок.

Выводы

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

В нашем случае при принятии решения об использовании интеграционных систем мы полагались на опыт команды внедрения и опыт наших глобальных коллег, внедрявших системы SAP PO и SAP MII на проектах ранее. Это позволило нам учесть особенности обеих систем и построить эффективную архитектуру.

На собственном опыте мы знаем, что выбор всегда не прост, но возможен. И все проектные вызовы можно преодолеть и обратить в свои преимущества.

Надеемся, наша статья поможет вам в поиске наилучшего для вас решения. Да пребудет с Вами Сила!

Подробнее..

Категории: Анализ и проектирование систем , Тестирование it-систем , Erp-системы , Интеграция , Sap , Платформы , Блог компании accenture , Шина

Выгрузка данных из SAP через RFC на Python

16.02.2021 10:21:44 |

Автор: admin

Поговорим о выгрузке данных из SAP ERP или S/4 HANA с использованием механизма SAP RFC.

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

Интерфейс SAP RFC (remote function call) позволяет вызывать различные функции SAP из стороннего приложения.

Преимущества этого интерфейса:

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

Установка

Для работы через RFC вам потребуется установить следующее:

Библиотека PyRFC https://github.com/SAP/PyRFC pip install pynwrfc
Библиотека SAP NW RFC для вашей платформы, скачанный с https://support.sap.com (нужен акаунт SAP).
Установить переменную окружения, указав каталог с библиотекой SAP NW RFC: SAPNWRFC_HOME=C:\NWRFC\nwrfcsdk\

Поиск уже имеющихся в системе функций

В системе SAP можно поискать уже готовые функциональные модули.

Сделать это можно следующим образом:

Запустить транзакцию SE16 (просмотр таблиц).
Указать имя таблицы TFDIR.
Задать фильтры для поиска:

FUNCNAME=*MATERIAL* (задать маску поиска)
FMODE=R (возможность вызова функции через механизм RFC)

Чтение таблиц через RFC_READ_TABLE

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

Несмотря на то, что SAP позиционирует эту функцию как тестовую и не предназначенную для использования в продуктивной среде, она вполне работоспособна.

Следует сказать, что RFC_READ_TABLE часто неудобна, т.к. она позволяет читать только одну таблицу (не поддерживает JOIN).

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

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

Просмотр функции через SE37

Входные и выходные параметры функции можно просмотреть с использованием транзакции SE37.

Параметры вызова функции присутствуют на следующих вкладках:

Importing - входные параметры простого типа (не табличные)
Exporting - выходные параметры простого типа
Tables - как входные, так и выходные параметры в виде таблиц

Рассмотрим использование SE37 на примере BAPI_MATERIAL_GETLIST.

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

SE37 - вкладка Tables

Просмотр полей таблицы

Эта функция выдает не слишком много полезных данных: Номер материала и описание.

Другие таблицы нужны для передачи на вход параметров выборки.

Например поиск по коду материала (MATNRSELECTION):

Таблица входных значений

Подключаемся к SAP

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

Код на Python:

import pandas as pd

import os

import pyrfc

conn = pyrfc.Connection(user='', passwd='',

mshost='111.111.11.11',

msserv='3600',

sysid='010',

group='NN',

saprouter='',

lang='EN',

client='')

Вызываем необходимую функцию

Рассмотрим вызов функции на примере BAPI_MATERIAL_GETLIST.

Сначала зададим входные параметры.

В данном случае для каждого параметра в таблице будет по одной строке.

Строка таблицы задается как python dictionary, а вся таблица задается как list, состоящий из строк.

В нашем примере укажем фильтр на код материала: '' (т.е. все значения), а также укажем значение для Plant.

Для выборки используем SIGN="I" (Includes),

Варианты для OPTION:

EQ Equal
BT Between (требует задать значение для для LOW и HIGH)
LE Less Equal
GE Greater Equal
CP Contains Pattern

matnrselection = [{'SIGN':'I', 'OPTION':'CP', 'MATNR_LOW':''}]

plantselection = [{'SIGN':'I', 'OPTION':'EQ', 'PLANT_LOW':'NNNN'}]

Далее вызываем функцию с этими параметрами.

result = conn.call('BAPI_MATERIAL_GETLIST',

MATNRSELECTION = matnrselection,

PLANTSELECTION = plantselection)

Преобразуем результат в DataFrame

DataFrame можно получить в одну строку:

df = pd.DataFrame(result['MATNRLIST'])

Где MATNRLIST, это имя результирующей таблицы, указанное в разделе Tables.

Итак, с помощью буквально нескольких строк кода, мы получили данные из SAP в DataFrame и можем дальше работать с этими данным используя все возможности языка Python.

Подробнее..

Категории: Python , Big data , Erp-системы , Rfc , Dwh , Sap , Интеграция приложений

Шпаргалка по Linux grep, домашний термостат на Raspberry Pi, эл. книга Ansible for DevOps и PostgreSQL на Linux

25.03.2021 12:22:32 |

Автор: admin

Собрали для вас много новых инсайтов, записей важных вебинаров, книжек и шпаргалок. Прокачивайте скилы, читайте, смотрите, думайте, применяйте на практике! Станьте частью DevNation!

Узнать новое:

4 инструмента для Linux
С Linux практически любая железка превращается в универсальный сервер общего доступа для файлов, аудио-, видео- и прочих ресурсов, с которыми легко и удобно работать с других платформ и устройств.

Домашний термостат на Raspberry Pi
Представляем проект ThermOS опенсорсная и пофиксенная альтернатива умным термостатам из коробки.
5 признаков того, что вы программируете на Rust
Автор этой статьи не так давно начал писать на Rust и обнаружил, что стал по-другому относиться к некоторым вещам и словам.
Собираем электронный календарь для всей семьи из Raspberry Pi и дисплея E Ink
Опенсорсная программа для управления личными финансами
Изучаем Java на примере написания классической аркады
Осваиваем GNU Debugger
Raspberry Pi на работе и дома: 12 проектов DIY
3 интересных программы-терминала для Linux

Скачать:

Шпаргалка по Raspberry Pi
Как загрузить, как поставить ОС, как включить SSH и подключиться по WiFi, как установить ПО и обновить систему, а также где найти дополнительную справку и ответы на вопросы.
Шпаргалка по Linux grep
Постигаем секреты поиска строк в файлах с помощью регулярных выражений.

Почитать на досуге:

Электронная книга Ansible for DevOps

Мероприятия:

Виртуальный Red Hat Summit 2021, 27-28 апреля
Бесплатная онлайн-конференция Red Hat Summit это отличный способ узнать последние новости ИТ-индустрии, задать свои вопросы техническим экспертам, услышать истории успеха непосредственно от заказчиков Red Hat и увидеть, как открытый код генерирует инновации в корпоративном секторе

BCC и Red Hat: Освобождение от рутины. Как Ansible automation platform помогает решить задачи IT инфраструктуры любого уровня, 30 марта
В ходе практической online-сессии проекта ВСС WEBINAR детально изучаем инструменты платформы Red Hat Ansible Automation, необходимые для реализации автоматизации предприятия. Также вас ждет 2 демо-сессии по оптимизации IT-инфраструктуры с помощью Ansible Automation Platform на примере настройки межсетевого экрана в среде Windows и в среде Linux
Вебинар про решения Red Hat для SAP на IBM Power Systems, 8 апреля
Ваш бизнес зависит от среды SAP? Она поддерживает критически важные процессы и предоставляет данные? Неэффективная среда может вызвать задержки, снизить гибкость и повысить расходы в ваших ИТ-подразделениях. Более чем 20-летний опыт инноваций позволяет компаниям Red Hat и SAP разрабатывать решения, отвечающие требованиям критически важных приложений. Red Hat Enterprise Linux это не только стабильная платформа, она дает конкретные преимущества при работе с инсталляциями SAP

Смотри в записи:

AnsibleFest
Два дня интереснейших докладов, демонстраций и практических занятий. Отличная возможность узнать, как разработчики, администраторы и ЛПР в сфере ИТ отвечают на вызовы перемен с помощью гибких технологий автоматизации с открытым кодом, которые позволяют перейти от того, что есть, к тому, что нужно
J4K Conference
Новая виртуальная конференция по Kubernetes, Java и облаку: 17 сессий с сотрудниками Red Hat, включая доклад Марка Литтла (Mark Little), главного человека в Red Hat по связующему ПО.

Подробнее..

Категории: Python , Postgresql , Open source , Android , Java , Виртуализация , Разработка под linux , Блог компании red hat , Red hat , Разработка на raspberry pi , Grep , Ansible , Raspberry pi , Sap

Разворачиваем базу данных SAP HANA в домашних условиях

06.04.2021 16:12:32 |

Автор: admin

В этой статье описаны шаги по установке базы данных SAP HANA в домашних условиях. Основное отличие этого материала заключается в том, что мы не будем использовать традиционные виртуальные машины, такие как Oracle VirtualBox или VM Ware Workstation Player. В этом документе речь пойдет о новом подходе, разработанном компанией Microsoft, под названием Windows Subsystem for Linux.

Что же такое WSL? По сути, это новая функция запуска Linux с использованием облегченного подхода к виртуализации.

Вот прямое определение от Microsoft:

The Windows Subsystem for Linux lets developers run a GNU/Linux environment including most command-line tools, utilities, and applications directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup.

Более детальную информацию о WSL можно получить на сайте Microsoft по ссылке.

В 2019 году появилась стабильная версия WSL2, которая получила ряд существенных дополнений по сравнению с первой версией. Основное отличие от первой версии - улучшенная производительность файловой системы, а также появившаяся полная поддержка системных вызовов ядра Linux. Ниже представлено сравнение двух версий WSL.

WSL и WSL2. Сравнение

В этой статье мы сфокусируемся на установке SAP HANA Express Edition с помощью технологии WSL версии 2.

Итак, если вы использовали WSL версии 1, для установки SAP HANA вам придется обновится до версии 2. Также если вы используете версию Windows 1903 или 1909, вам придется или выполнить дополнительные шаги, описанные в документе, или обновить версию ОС, например, до 20H2.

Установка WSL2

Для установки WSL2 нам потребуется выполнить несколько шагов. Детальную информацию по установке можно получить по ссылке на сайте Microsoft.

Шаг 1

Включаем Windows Subsystem for Linux. Для этого запускаем PowerShell с правами администратора. В открывшемся окне вводим команду:

dism.exe /online /enable-feature /featurename: Microsoft-Windows - Subsystem-Linux /all

WSL. Включение поддержки

Шаг 2

Перед началом установки WSL2, нам необходимо включить опцию Virtual Machine Platform. Для включения этой опции вам потребуется поддержка виртуализации. Подробнее об этом по ссылке.

Для включения опции в окне PowerShell (с правами администратора) необходимо ввести команду:

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Virtual Machine Platform. Включение поддержки

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

Шаг 3

Скачиваем пакет обновления ядра LinuxWSL2 Linux kernel update packege for x86. Запускаем установку.

WSL2 Linux kernel update packege for x86. Установка

После установки переходим к следующему шагу, определению WSL2 как версию по умолчанию для новых инсталляций Linux.

Шаг 4

Установка версии WSL2 по умолчанию. Для этого в окне PowerShell вводим следующую команду:

wsl --set-default-version 2

Шаг 5

На этом шаге мы произведем непосредственно установку Linux. В Microsoft Store выбираем версию Linux. Я буду использовать OpenSUSE Leap 15.2. Нажимаем кнопку Get. Затем нажимаем Launch.

Linux. Установка

Подтверждаем сообщение о лицензии и добавляем пользователя. Всё, установка завершена!!!

Linux. Завершение установки

Сразу скажу немного про управление этой виртуальной машиной, сперва оно может показать непривычным.

Прежде всего воспользуемся командой:wsl --list v

WSL список + текущая версия версия

Команда выводит название ОС и текущей версии WSL. Для отключения ВМ, необходимо в окне PowerShell ввести командуwsl --shutdown

Запуск ВМ можно произвести в окне поиска Windows. Вводим название операционной системы (в моем случае OpenSUSE).

Строка поиска в Windows

Нажимаем правой кнопкой Запустить от имени администратора, вуаля, наша ВМ снова готова к работе.

Командная строка Linux

Установка базы данных SAP HANA Express Edition

Вот, собственно, ради чего все мы все это и затеяли, а именно установка базы данных для разработчиков SAP HANA Express Edition .

Для начала скопируем дистрибутив на файловую систему нашей ВМ. Для этого нажимаем Выполнить и в открывшемся окне пишем:\\wsl$

В открывшемся окне выбираем нашу ВМ

Сетевой доступ к файловой системе Linux

И вот перед нами уже файловая система Linux. Просто и удобно!

Файловая система Linux

Копируем дистрибутив и запускаем установку. Я произвожу установку с помощью hdblcm. Как видно на картинке ниже, я устанавливаю версию 2.00.045 (SPS 4). В настоящий момент это последняя доступная версия SAP HANA Express Edition.

SAP HANA EE. Установка

Так как сама база данных, а также XSA (платформа для разработки) очень чувствительна к имени сервера, я буду использовать имя localhost (пункт Enter Local Host Name в установке). Или с помощью команды hostname можно определить название хоста на уровне ОС.

Сначала попытка установить базу данных, окончится ошибкой как на картинке ниже

SAP HANA EE. Ошибка установки

Детали можно посмотреть в файле логов в каталоге/var /tmp /hdbinst .log. Ошибка связана с тем, что отсутствуют необходимые пакеты для ОС. Так как OpenSUSE идет из коробки, нам необходимо самостоятельно произвести обновление стандартных компонентов. Это можно сделать, выполнив командуzypperupdate, а также установить дополнительные пакеты, например numactl и libltdl 7. После этого установка базы данных прошла успешно.

SAP HANA EE. Завершение установки

На этом установка завершена. Теперь возвращаемся в Windows и подключаемся к базе данных через, например, SAP HANA Studio.

SAP HANA Studio

Не забудьте получить лицензию разработчика, это делается просто и бесплатно по ссылке.

Подробнее..

Категории: Администрирование баз данных , Erp-системы , Sap , Hana , In-memory , Database development

SAP HANA. Таблицы с типом хранения Row

12.06.2021 12:08:35 |

Автор: admin

Добрый день, коллеги. В этой статье я бы хотел затронуть тему таблиц с типом Row. Этот тип таблиц для многих администраторов баз данных, долгое время оставался наиболее естественным типом, так сказать типом по умолчанию. Таблицы типа COLUMN в основнов встречались в хранилищах данных (Data Warehouse), то есть базах данных с преобладающей нагрузкой типа OLAP.

Основная идея инженеров компании SAP при разработке базы данных HANA, было объединение двух миров OLTP и OLAP приложений. В результате таблицы с колоночным хранением в базе данных HANA, стали таблицами по умолчанию, но несмотря на преимущества колоночных таблиц в большом количестве сценариев, база данных HANA продолжает использовать строковые таблицы. Об особенностях использования такого типа таблиц и пойдёт речь в этой статье.

Таблицы с типом Row хранятся в специальной области памяти, которая называется shared memory. При запуске базы данных эта область полностью загружается в память и остается там всё время, пока база данных находится в рабочем состоянии.

В таблицах с типом Row, все данные размещаются в строках друг за другом, что облегчает доступ ко всем строкам таблицы. А вот с доступом, ко всем значениям столбца немного сложнее, поскольку эти значения не могут быть переданы из основной памяти в CPU с той же эффективностью, как в случае хранения по столбцам. Компрессия данных при таком типе хранения также менее эффективна.

Классический подход для реляционных баз данных, в которых данные хранятся в табличном формате, заключается в хранении, напоминающем логическую структуру таблицы. Каждая запись храниться как объединенный кусок значений каждой колонки таблицы. Ниже представлена таблица с классическим типом хранения.

Пример таблицы с классическим хранением

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

Представление Row-store таблицы в памяти

У такого представления данных есть и свой недостаток, заключается он в том, что для многих операций в базе данных такой подход не очень эффективен. База данных не может получить прямой доступ к определенным колонкам таблицы. Вместо этого страницы с данными необходимо передать CPU для сканирования хранящихся строк по порядку, по идентификатору условияwhereдля определенных столбцов.

Пример сканирования строк в таблицах с типом Row и Column store

Эти данные перемещаются из основной памяти (main memory) в кэш CPU, это оказывает влияние на производительность, особенно при массовой обработке данных, в таких случаях как хранилище данных и аналитические запросы. В то время как для смешанного типа нагрузки, при условии доступа к одной или нескольким записям со всеми колонками, этот метод хранения является предпочтительным, так как требования трансформации данных от внутреннего хранилища к внешнему представлению (также называемое проекцией) для клиента базы данных минимальны.

В базе данных HANA, таблицы с типом Row-store имеют целый ряд ограничений:

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

Для row-store таблиц, доступно два типа индекса: классический b-tree индекс и cpb+-tree (сжатый префикс b-tree) индекс который оптимизирован для обработки символьных индексных ключей в памяти. Несмотря на то, что есть возможность выбрать тип используемого индекса, обычно в этом нет необходимости. SAP HANA будет использовать cpb+-tree тип определенный по полю или комбинации полей типа string, binary string, или decimal. Для всех остальных типов, будет создан классический b-tree индекс. Индексы по row-store таблицам не сохраняются в БД на постоянной основе, вместо этого они пересоздаются каждый раз при загрузке таблицы в память (запуске базы данных).

Управление многоверсионной конкуренцией (Multiversion Concurrency Control)

Multiversion Concurrency Control (MVCC) это концепция, которая гарантирует консистентность транзакционных данных путем изоляции транзакций которые получают доступ к одним и тем же данным в одно и то же время. Для того чтобы это было реализовано параллельно, сохраняется несколько версий записи. Проблемы с MVCC обычно связаны с большим количеством активных версий записи. Старые версии время от времени должны удаляться для того, чтобы освободить память.

Колоночные и строковые таблицы реализуют это функцию совершенно по-разному.

Для row store таблиц, каждая измененная страница сначала копируется и размещается в цепочке версий страниц, где каждая версия имеет состояние данных на определенную операцию commit. Эти цепочки страниц хранятся в виртуальном контейнере в памяти, который называется undo. Представление для мониторинга M_UNDO_CLEANUP_FILES показывает детальную информацию по этим внутренним виртуальным файлам-контейнерам.

За удаление старых версий записи отвечает Garbage Collector. Сборка мусора происходит после операции commit, а также периодически (по умолчанию каждый час). Сборщик мусора может удалить лишь те старые версии записей, для которых транзакции обновления были завершены (была выполнена операция commit или rollback). В случае, если транзакция изменяет десятки или тысячи строк без фиксации изменений (операции commit), вы можете попасть в ситуацию, когда большой объем избыточных данных необходимо хранить в основной памяти (main memory), так как в базе данных будут храниться десятки тысяч блокированных версий записей и новых активных версий записи. Я уже наблюдал картину, когда по большим таблицам в памяти хранилось до 8 млн. версий записей.

Если обраться к представлению с потоками (например M_SERVICE_THREADS), то в поле Thread Type периодическая сборка мусора будет обозначаться как MVCCGarbageCollector. Для того, чтобы найти транзакции, которые зафиксировали свои изменения, необходимо в представлении потоков, сделать выборку по условиям THREAD_TYPE=SqlExecutor и THREAD_METHOD=CommitTrans.

Реорганизация Row-store области

Реорганизация Row-store области представляет собой процесс дефрагментации сегментов памяти с целью более компактного хранения. Несмотря на значительные улучшения в самом процессе реорганизации, который претерпел существенные изменения начиная еще с HANA 1.0, сама по себе процедура всё еще остается проблемной. Об этом я расскажу ниже, а сейчас немного общей информации.

Пространство Row store увеличивается путем выделения сегментов памяти размером 64 Мб. Сегмент внутренне разделен на страницы фиксированного размера. Когда row-store таблице требуется больше памяти для хранения записей, для неё выделяются свободные страницы из существующего сегмента. Если свободных страниц в сегменте больше нет, выделяется новый сегмент.

Удаление большого числа записей может привести к появлению разрозненных сегментов. В этом случае может помочь реорганизация области row store с целью более компактного хранения в памяти. Страницы из разрозненных сегментов переносятся в другие сегменты, в результате освобождается свободное пространство. SAP рекомендует выполнять реорганизацию Row Store пространства при условии, что его размер превышает 10Gb при этом свободных блоков более 30%. В базе данных HANA доступно два режима реорганизации пространства ONLINE и OFFLINE.

ONLINE реорганизация стала доступна с версии HANA 1.0 SPS8. С тех пор этот режим постоянно улучшается с целью снижения влияния на бизнес процессы и повышения эффективности хранения в области Row store. До версии SAP HANA 2.0 SPS3 включительно, при проведении онлайн реорганизации, на таблицы участвующие в реорганизации устанавливалась эксклюзивная блокировка, в результате чего, изменения записей по этим таблицам были невозможны. Начиная с версии SAP HANA 2.0 SPS4 в процессе реорганизации произошли изменения, теперь при онлайн реорганизации блокировка устанавливается на уровне строки, а не таблицы целиком. В соответствии с рекомендациями SAP online реорганизация необходимо запускать в период минимальной нагрузки для того, чтобы добиться лучшего результата. Именно в этом и кроется основная претензия к этому режиму реорганизации, он не позволяет добиться такого же результата, как в случае OFFLINE реорганизации.

До версии HANA 2.0 SPS4, компания SAP рекомендовала использовать именно OFFLINE режим, для получения лучшего результата. При этом OFFLINE режим несёт в себе один существенный недостаток, логически вытекающий из его названия. Систему работающую в режиме 24х7 для реорганизации row-store пространства никто останавливать не будет. По этому, обычно, OFFLINE реорганизацию совмещают с другими работами, требующими останова системы.

Внимание! OFFLINE реорганизация может существенно увеличить время запуска базы данных HANA.

Начина я с версии SAP HANA 2.0 SPS4 стал доступен режим автоматической ONLINE реорганизации. По умолчанию раз в час запускается проверка на фрагментированность области row store. Если показатель полезного использования памяти менее 60% от размера области row-store, запускается автоматическая реорганизация. Пороговое значение фрагментированности, а также частота запуска проверки может быть изменена. Подробнее о автоматическом режиме можно прочитать в ноте 2789255 - Automatic Online Row Store Reorganization.

На этом я бы хотел завершить краткий обзор таблиц с типом хранения Row. Несмотря на преимущества колоночных таблиц, в базе данных HANA продолжают использоваться и строковые таблицы. В основном такие таблицы используются как технические или настроечные с относительно небольшим количеством записей, при этом основная роль отдана таблицам с колоночным типом хранения.

Подробнее..

Категории: Администрирование баз данных , Sap hana , Sap , In-memory , Sap basis , Database in-memory

Demo Day в Райффайзенбанке какие продукты и сервисы показали команды

19.04.2021 12:12:03 |

Автор: admin

Увиделись онлайн и вместе посмотрели на банковские продукты и сервисы изнутри: какие процессы ускоряем и автоматизируем, какие интеграции реализуем и какие технологии для этого используем.

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

Начинаем трансляцию

Устроились поудобнее и заглянули в zoom, где уже встречаем всех гостей приветственным словом Сергея Монина, председателя правления банка, и играем в квиз, чтобы получить приятный подарок фирменный мерч Open Demo Day Райффайзенбанка.

Теперь переходим к главному, ради чего собрались: восемь демо восемь суперфич!

20:44 >>> Сервис для оптимизации работы курьерской доставки
Команды: Customer Relations for PI, Site, Cards, Notifications & On Demand Development

Показываем, как организовали доставку банковских продуктов для физических и юридических лиц. Начиналось все с нескольких десятков доставок в месяц, и вот у нас уже работает собственная курьерская служба. Большие объемы и стремительное развитие бросают вызовы: нужно соответствовать высоким ожиданиям клиентов и автоматизировать процессы. Для этого и разрабатываем сервис, а под капотом используем наработки собственного open-source решения ViennaNET.

Задавали вопросы? Отвечаем здесь

Подсказки при заполнении ФИО с помощью Dadata? Пользователям нравится? На форме заявки ФИО заполняется при помощи подсказок сервиса Dadata, в том числе пол клиента определяется автоматически. A/b тестирование показало большой прирост конверсии в заявку с использованием этого сервиса.

Планируете слоты времени доставки делать для пользователя? Не всегда удобно принять звонок. В ближайшее время планируем сделать доработку с выбором временных интервалов по адресам, где доставку осуществляют наши собственные курьеры.

Как будет работать сервис, если Dadata недоступна? На текущий момент клиент не сможет завершить процесс подачи заявки, если сервис Dadata будет недоступен. В бэклоге продукта заложена задача по устранению этой проблемы.

Не думали на тему заполнения анкеты на доставку через интеграцию с Госуслугами? У нас был проведен тест с возможностью подачи заявки с авторизацией и получением клиентских данных из сервиса Госуслуги, но результаты показали снижение конверсии по количеству поданных заявок.

У курьеров личные телефоны для работы, и фото документов они делают на личные телефоны? Телефоны корпоративные с секьюрной оболочкой, внутри которой установлено курьерское ПО. Фото не сохраняются в телефоне в галерею, невозможно сделать видео экрана и скриншот.

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

Если все-таки ошибки в документах, корректировки вы внесете, проведете пересчет, а документы с клиентом потом переподписываете повторно? Если в документах есть критические ошибки, которые изменяют условия продукта, будет повторная встреча для подписания скорректированных документов.

Мобильные приложения нативны под обе платформы? Только под Android. Ввиду экономики оснащать курьеров телефонами с хорошими характеристиками ОС и камеры дешевле на Android.

Может ли курьер свернуть приложение и воспользоваться камерой для фото документов в личный фото архив? Курьеры не используют личный телефон для работы, весь процесс происходит строго с использованием корпоративного телефона.

Курьеры сами готовят документы и формируют пакеты с картами? Или где-то происходит их формирование? В городах, где есть инфраструктура банка, курьеры всю подготовку ко встрече делают сами (печать, подбор карты). В части городах есть специализированные агенты, которые поддерживают этот процесс по договору.

Как считаете экономику? Какие KPI стоят перед командой? Экономика завязана на стоимости доставки. KPI NPS, скорость доставки и конверсия от заявки в выданный продукт.

Как документы попадают в ПО курьерки? Можно ли их изменить силами курьера? В ПО попадают фото документов. Документы на бумаге курьерам для изменения недоступны.

42:19 >>> Переводы по номеру телефонав мобильном банке
Команда Instant &Easy

У нас в фокусе работа над самым важным и популярным функционалом для наших пользователей в мобильном банке, и к этим фичам относятся платежи и переводы. В этом направлении мы реализовали две истории: первая история, где отсортировали банки по популярности и добавили им логотипы. Это базовые и понятные вещи, которые экономят в среднем 2,5 секунды на перевод по номеру телефона. Вторая история вот о чем: упростили перевод получателю, номер которого указан в адресной книге. Что делать, если СБП у получателя не включен? Это тоже предусмотрели все наглядно показываем в демо.

Задавали вопросы? Отвечаем здесь

Как СБП изменил процесс перевода денег? Радикально упростил межбанковские переводы, ради которых раньше пользователи специально открывали карты определенных банков.

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

Перевод по Bluetooth, осуществляется только при версии 5? Если нет, то как защитите перевод? Переводы по Bluetooth полностью безопасны, вне зависимости от версии.

Брались ли в расчет практики переводов по номеру телефона других банков? Да, российских и зарубежных.

Быстрые суммы перевода показаны в контексте пользователя по последним платежам? Или просто заданы статичные шаблоны? На данный момент статичные шаблоны, но в планах отображение сумм в контексте конкретного пользователя.

Какой для вас приоритетный канал перевода как для банка? Перевод по карте или по телефону? По телефону более приоритетный и более быстрорастущий канал.

46 дней сэкономили за всю жизнь? относительно чего метрика? 46 дней в месяц. Мы взяли сэкономленное на одном переводе количество секунд и умножили это время на количество переводов, совершающихся за месяц.

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

Шаблон перевода в другой банк удобен. Мне не встречался шаблон перевести по карте из другого банка, каждый раз приходится вносить данные своей же карты (я клиент банка как индивидуальный зарплатный клиент). Можно ли сделать сохранение данных своей карты для перевода из другого банка? Согласны, шаблоны очень нужны, их реализация есть в ближайших планах.

А можно ли отображать остаточную сумму переводов без комиссии? Можно добавить такую функциональность вместе с другими лимитами.

Подскажите, что с международными переводами? В Европу или США есть ли подобные реализации? На данный момент такие решения отсутствуют.

Если будет комиссия, то как будут показываться % или сумма, если сумма большая, то как это выглядит? Будет показываться сумма комиссии, чтобы пользователю всегда было понятно, сколько денег он заплатит.

Насколько популярен способ перевода по Bluetooth? Недостаточно популярен, чтобы мы концентрировались на его развитии :)

Какой процент активных пользователей мобильного банка от общего количества клиентов банка? Примерно 2/3.

Много чего внедрили для aml / ft ? Может, какие-то новинки? Мы буквально каждый месяц делаем доработки в этой части, большая часть из которых реализуется совместно с НСПК.

Зачем смотреть инструкцию, если ее надо отправить? Не всегда необходимо ее отправлять, так как почти половина переводов переводы себе в другой банк. Но поделиться инструкцией тоже можно.

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

Почему решили уместить все действия по переводу на один экран, а не делать пошаговые переходы между экранами? Мы движемся в сторону нескольких экранов, так что переходы у нас есть. Наша цель минимально возможное количество тапов и времени на выполнение операции в мобильном приложении.

Может быть ошибка, если у получателя на одном телефоне 2+ банковские карты разных банков? Нет, эта ситуация нормально обрабатывается.

Как вы собираете обратную связь от клиентов? Ходите ли на гембы? По текущему приложению: отзывы в сторах и соцсетях, звонки и письма в контактный центр. Новые разработки тестируются с помощью Usability тестов.

Можно ли осуществить перевод не с текущего счета, а с карты другого банка? Например, приложение зеленого банка не работает из-за сбоя. Да, можно.

1:02:58 >>> Интеграция банковских услуг в SAP
Команда CDC Integrations

Мы работаем с корпоративными клиентами, и когда мы провели исследование, то увидели две важные вещи: пользователи хотят, чтобы все финансовые операции были в их учетной системе и чтобы никуда не нужно было выходить, особенно если у них много банков. Интегрировались в SAP и сделали для наших клиентов все внутри одной платформы. Интерфейсы получились почти идентичными, чтобы не было разрыва пользовательского опыта.

1:22:55 >>> Опросник NPS для кандидатов
Команда Recruitment Dev Team

Кандидаты такие же клиенты, как и другие пользователи наших банковских продуктов. И нам важно, что они думают о процессе найма в банке. Для этого мы с командой встроили опросник NPS в этот процесс: система позволяет кандидатам оценивать нас и помогает нанимающим менеджерам, собеседующим и рекрутерам со своей стороны также посмотреть на все шаги по пути найма.

Задавали вопросы? Отвечаем здесь

8 вопросов достаточно много. Текст в свободной форме практически никогда не заполняют, как менялась ваша анкета по NPS со временем? Планируете ли что-то менять в анкете в ближайшее время, какие в анкете сейчас есть явно слабые места? Это второй вариант анкеты, поменялись формулировки вопросов, их стало на один меньше. Хороший response rate (23%) показывает, что ответ на эти вопросы несильно напрягает респондентов. Мы планируем создать и другие варианты анкеты. Комментарий в свободной форме оставили около 50% кандидатов из числа тех, кто заполнил опросник.

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

Какие гипотезы выдвигались в процессе разработки опросника / интервалов отправки анкет? Гипотез было много, например, Кандидаты, которые получили отказ по вакансии, будут давать более негативные оценки, и она подтвердилась. Есть гипотеза, что задержка на отправку анкеты в 7 дней после принятия решения о судьбе кандидата поможет избежать чрезмерного влияния эмоций на результат опроса.

А вы считаете eNPS уже текущего состава команды? Пока нет.

Используется ли ваш продукт для переоценки сотрудников/чекапов/чекпойнтов и т.д.? Или это только про внешний рекрутмент? Продукт используется только для рекрумента.

Накладываете ли вы эти данные на карту пути кандидата? Отдельно или внутри вашей команды? Интересное предложение, спасибо!

Коллеги, есть ли особенности в инструментах для рекрутинга/опросов кандидатов с ограниченными возможностями? Это важная тема, но скорее относится к самому процессу рекрутмента. В наших электронных продуктах мы стараемся проектировать интерфейсы так, чтобы для людей с ограниченными возможностями они не вызвали затруднений, но пока не дошли до того, чтобы делать специальные версии ПО.

Сколько раз вы отошлете опросник отказному кандидату, ибо каждый раз качество интервьюирования может падать в зависимости от вакансии? Если кандидат одновременно проходит собеседования на несколько вакансий, он получит только один опросник за один месяц.

Вы как-то автоматизируете процесс проведения собесов? Например, скрипты для проведения собеса с последующим подсчетом балов, скорингом и т.п. Да, но пока не для всех. В IT-рекрутменте большинство компетенций оцифрованы, и интервьюеры проверяют кандидатов по единым стандартам, которые задают коммьюнити. По завершению коллеги могут принимать решение на основе единой оценки, например, в виде паутинки.

Если кандидата оценивают сразу на несколько позиций, как это учитывает ваша система? Кандидат получает один опросник по той вакансии, процесс найма по которой заканчивается быстрее, и далее 30 дней не будет получать новый опросник. Если после этого он побывает еще на одной вакансий, то процесс повторится.

1:45:43 >>> Омниканальная чат-платформа собственной разработки
Команда Chat

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

Задавали вопросы? Отвечаем здесь

Есть ли у оператора мобильное приложение с чатом? Чтобы он мог общаться с клиентами вне фиксированного рабочего места. Нет. Наши операторы сейчас могут работать и из дома (не обязательно из офиса), так что проблема по итогам 2020 стала неактуальна).

Используется ли на входящей линии КЦ голосовой бот (не IVR)? Да, уже работает в проде с сентября. Сейчас обрабатывает 90% входящих обращений, дает персонализированные ответы и 20% из них закрывает е2е. При этом не мучает клиента просьбами переформулировать вопрос :) Старый IVR остался только в 10% операций (на входе и 1-2 малых ветках). Чуть позже и их убьем.

Какое максимальное количество диалогов у оператора? Зависит от оператора. Каких-то ограничений не вводим.

Ведется ли сбор статистики по тематикам обращений? Как будет реализовано на этой платформе? Сбор тематик реализован на базе отдельного решения речевая аналитика. Уже успешно работает.

В шаблон можно вставить имя того, с кем диалог, чтобы не было сухой фразы? Да, конечно. Все шаблоны редактируемые.

Вот у вас диалог ждал, пока оператор вернется... А если оператор не вернулся по каким-либо причинам? Все, клиент повис? Состояние диалогов постоянно мониторит руководитель данной группы/сектора. К клиенту обязательно вернутся.

Если оператор принудительно закрыл беседу, до конца не ответив на вопрос клиента, происходит ли переоткрытие или всегда назначается новый оператор? Сколько храните переписки, и есть ли контроль качества работы операторов с клиентами по данным каналам? Механика, возврата к существующему оператору (если это возможно) есть. Переписки храним долго :) Есть не просто контроль качества, а амбассадоры стиля. А вообще мы стараемся сделать так, чтобы качество нашего общения было приоритетом не для выделенных сотрудников, а для всех.

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

Есть ли логика назначения диалога по компетенциям операторов + переназначение диалога другому оператору? Логика назначения по компетенциям возможна, но мы стремимся к универсализации и дифференцируем операторов не тематикой, а объемом одновременных диалогов. Для отдельной группы диалогов, по которым все же необходима выделенная группа, перевод, конечно, возможен.

Участвуете ли вы в каких-либо сторонних исследованиях, или сами проводите все продуктовые исследования и в стороннем нет потребности? Проводим как свои исследования (опросы, проблемные интервью), так и внешние(мистери шоппинг, UX аудит, рэнкинги).

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

Может ли оператор перевести вопрос на другого оператора? Например, сложный вопрос и ответа нет. Или вопрос нужно уточнять у продуктовой команды, например. Как это работает? Да, конечно. Оператор может перевести вопрос как на конкретного оператора, так и на выделенную группу.

А как вы планируете делать работу с чатом эффективнее? Чтобы ответы на вопрос занимали меньше времени? Есть несколько оригинальных идей (и да, это не ботизация 99% вопросов, так как мы еще хотим, чтобы наши клиенты были счастливы), но, к сожалению, мы не можем их рассказать, потому что они по-своему уникальны.

Есть ли смысл пилить свой чат? На рынке очень много крутых решений: например, Intercom. Какие плюсы своего решения? Может ли банк построить решение лучше, чем компания, которая на этом специализируется? К счастью, за нас это проверили разработчики мобильных банков, которые также на рынке изначально использовали вендорские решения, а в итоге все лидеры пришли к внутренней разработке. В области чатов уже сейчас ряд лидеров также разрабатывают собственные решения, хотя тоже начинали с коробок. У внутреннего решения как минимум три плюса: лучший ТТМ (думаю, не надо объяснять, что внедрение новых фич через вендора на практике очень редко можно вписать даже в двухнедельный спринт), большая гибкость в кастомизации (часть решений являются облачными, что фактически блокирует большую часть доработок, часть онпремис, но кастомизация отдельных веток или радикальные доработки архитектуры либо невозможны, либо очень дорогие и долгие). Ну и, в-третьих, вендорские решения намного сложнее использовать в комплексе с другими решениями ландшафта. В нашем случае мы сами разрабатываем как чат-платформу, так и чат-бота, голосового бота и CRM-систему. Это позволяет на входе с минимальными усилиями реализовывать самые эффективные задачи.

Резюмируя вопрос: вендорские коробки создаются, чтобы быть хорошими всем, внутренние решения, чтобы быть лучшими конкретным компаниям. Все зависит от амбиций :)

P.S. Intercom отличный пример, решение приетарно облачное, поддерживает только live-chat (чат на сайте) и очень плохо (мне неизвестны кейсы) встраивается в приложение, заточено под собственное бот-решение (а это не конек intercom, так как по факту есть rule-based решение). А для нас чат на сайте это 5-10% траффика. Решение Intercom в целом не является чат-платформой и отвечает на другие вопросы (к примеру, у коллег большой фокус на маркетинг, онбординг продуктов, что не является частью чат-платформ).

2:08:46 >>> Автоматический процесс принятия решения по заявке
Команда Personal Loans

Реализовали полностью автоматический процесс принятия решения по кредитным заявкам. Конечно, есть критерии: такие заявки рассматриваются от уже существующих клиентов, по которым не нужна дополнительная проверка. Так что система быстро проверяет все сама, без участия сотрудников. Теперь самый долгий срок рассмотрения заявки 6 минут.

Задавали вопросы? Отвечаем здесь

Отличается ли состав данных, которые должен заполнить клиент, для зарплатных клиентов? Или данные о работе просто автоматически подставляются? В общем случае о действующем клиенте банка мы знаем больше информации, чем о новом. Заново заполнять уже известную нам информацию не заставляем. Зарплатный частный случай действующего клиента.

Какое количество внешних сервисов подключено к СПР? Всего девять, из них семь влияют на принятие решения по заявке.

А что если номер телефона у клиента начинается с 8? По умолчанию указываем +7. Можно изменить.

Сколько у вас тестовых сред? Сколько времени заняла разработка с нуля до первой выдачи в иб? Сколько занимает тестирование? Есть ли в командах специалисты от юротдела или безопасников? Сколько человек в продуктовой команде? Решение на микросервисах? Что делаете с упавшими ошибочными заявками? Тестовая среда и пред-прод-разработка заняла два месяца. Тестирование выполняется в общем цикле разработки, поэтому можно считать, что тоже два месяца. Специалисты юр.отдела и ИБ вне скрам-команды, но с ними активно взаимодействуем по многим вопросам. Решение на микросервисах, и еще legacy-наследие в виде монолита. Для упавших заявок используем механизм переповторов.

Планируете ли автоматически загружать данные клиентов из Цифрового Профиля Госуслуг? Да, такие работы ведутся.

Как обошли риски по запросу в БКИ без согласия клиент? Согласие получено в рамках других продуктов Банка? Клиент предоставляет согласие при оформлении анкеты. Подтверждает простой цифровой подписью.

Кешируются ли данные, полученные из БКИ, чтобы не портить историю частыми запросами? Да, данные кешируются.

Как идет одобрение и оформление карты dual to credit по данному процессу? В пилотном решении выдача дуальной карты не предусмотрена. В дальнейшем функционал будет расширяться и дополняться.

2:26:07 >>> Цифровой маркетинг Райффайзен-Лизинг, новый сайт и маркетплейс
Команда Leasing

Для лизинга 2020 был непростым: в целом рынок упал на 6%. Что делала наша команда в прошлом году? Запустили цифровой Лизинг автомобилей и спецтехники и предоставили доступ в систему нашим партнерам. Еще активно занимались развитием сайта и маркетплейса: появился раздел по каталогам автомобилей и условиям и более заметная кнопка с оформлением заявки.

2:41:51 >>> Автоматизация исходящих платежей на базе блокчейн-платформы
Команды Technosoul Cash Management & Payments Service Team

Командами работали над интересной задачей проведение расчетов через собственную блокчейн-платформу R-chain. Как это все устроено? Есть несколько компаний покупатель и поставщик, есть банк, который поддерживает эти расчетные функции. Все участники на своих серверах устанавливают ноды, узлы блокчейна, и далее информационные системы участников объединяются в единую сеть. Так появляется возможность вести общий реестр сделок и расчетов. В теории объяснили, теперь показываем в действии на демо.

Спасибо, что были с нами!
Второй открытый Demo Day мы уже запланировали на ноябрь, следите за анонсами здесь, в нашем корпоративном блоге, и до следующей встречи :)

Подробнее..

Категории: Usability , Управление продуктом , Управление разработкой , Блог компании райффайзенбанк , Raiffeisendgtl , Чат-бот , Sap , Автоматизация процессов , Demo day , Блокчейн-платформа

Непрерывность бизнеса. Решения SAP в Microsoft Azure виртуальное мероприятие

07.10.2020 10:05:19 |

Автор: admin

13 октября приглашаем вас принять участие в виртуальном мероприятии Решения SAP в Microsoft Azure. В рамках мероприятия мы предложим вам по-новому посмотреть на размещение решений SAP в облаке Azure. Вы узнаете, почему переход на SAP S/4HANA в Azure идеальный старт для реализации вашей облачной стратегии и как данное решение позволит снизить затраты, повысить гибкость бизнеса и стимулировать инновации.

Регистрация

Под катом немного подробностей.

Ускоренное внедрение инноваций при помощи SAP S/4HANA.
Трансформация среды SAP с применением Azure.
История успеха: каким образом Microsoft и SAP использовали SAP S/4HANA в Azure для трансформации собственных бизнес-процессов.
Выступление специальных гостей: выгода от переноса своих систем и приложений SAP в Azure.
Microsoft Azure на базе новейших технологий Intel, созданных для SAP S/4HANA.

13 октября 2020
Начало в 10:00 (по Московскому времени)

Будем рады вас видеть на виртуальном мероприятии Решения SAP в Microsoft Azure!

Регистрация

Подробнее..

Категории: Intel , Microsoft , Учебный процесс в it , Облачные сервисы , Облачные вычисления , Блог компании microsoft , Вебинар , Microsoft azure , Azure , Sap

7 уроков по итогам разворачивания SAP HANA на базе MS Azure для российской компании

24.08.2020 16:22:46 |

Автор: admin

Уже более 10 лет назад в Microsoft объявили о доступности платформы Azure для широкой аудитории пользователей. За это время преимуществами облачной инфраструктуры для решения текущих задач ИТ захотели воспользоваться многие компании. Некоторые из них обращались к нам за консультацией по разворачиванию систем в облаке. Но время шло и вот уже бизнес рассматривает возможность размещения в облаках таких ресурсоемких систем, как SAP HANA. Мы в свою очередь, уже реализовали несколько аналогичных проектов и готовы поделиться теми наблюдениями, которые могут обеспечить более успешное размещение системы SAP в облаке MS Azure. Некоторые наблюдения не будут открытием, но нам хотелось показать применимость некоторых подходов именно в условиях облачной платформы. Основными усвоенными уроками хотим поделиться с вами.

1: Последовательная оптимизация ИТ архитектуры при использовании облака

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

Рекомендованный подход к построению системы SAP строится на базе оценки необходимых мощностей средствами калькулятора SAP Quick Sizer. До сих пор методологии SAP базируются на стандартных подходах, не учитывающих особенности облачных технологий. Мы получили требования от Заказчика, ввели исходные данные в эстиматоры SAP и получили предварительную конфигурацию ландшафта. В случае обычной инфраструктуры можно было на этом остановиться и перейти к покупке оборудования, но в нашем случае было возможно воспользоваться преимуществами облака. В облаке ресурсы можно нарастить в любой момент и поэтому мы отказались от излишнего запаса по ресурсам, заложенного в эстиматор и развернули машины меньшего номинала. Это позволило сократить затраты, а по мере возрастания нагрузки мы всегда можем увеличить производительность виртуальных машин SAP за считанные минуты.

Microsoft обеспечивает поддержку SAP только на ВМ серии М. Использование тестовых ресурсов аналогичных продуктивной среде по уровню поддержки на этапе первоначальной разработки избыточно.
В тоже время тестовые машины E-серии обладают схожими характеристиками с M-серией, но их стоимость существенно меньше. В итоге заменили виртуальные машины М серии на другую серию. Обратной стороной этой замены является переход ответственности за работу системы в тестовых средах с провайдера на интегратора. Это налагает на интегратора необходимость иметь экспертные компетенции в области SAP.

2: Как сэкономить на потреблении ресурсов

MS Azure позволяет существенно экономить при резервировании ресурсов с одновременным предоплатой на один или 3 года.
Зачастую на начальном этапе заказчик не может точно оценить дату запуска продуктивной системы, так как ее разработка и тестирование зачастую связаны со многими переменными, находящимися на стороне бизнеса или подрядных разработчиков.
Например, на момент запуска одного из проектов мы планировали одновременное развертывание всех сред на основе текущих планов Заказчика. Как это часто бывает, разработка потребовала более длительных согласований с бизнесом, что привело к отложенному старту продуктивного запуска на несколько месяцев.
В этом примере при резервации ресурсов с предоплатой Заказчик потерял бы существенный объем средств. Резервировать ресурсы, конечно, нужно, но зачастую существенно позже старта проекта, когда основной объем продуктивной системы стабилизировался, а разработка станет предсказуемой в плане потребления ресурсов. Зачастую при резервации вычислительных ресурсов на 3 года можно получить около 70% экономии средств по сравнению с Pay-As-You-Go методом оплаты.

3: Как выбрать регион Azure

Azure обладает широким списком регионов для размещения ресурсов. Один из основных критериев выбора региона удаленность вашей инфраструктуры от конечных пользователей, что влияет на отклик системы и работу интеграций и конечных пользователей.
Вторым, не менее важным, критерием является список сервисов в том или ином регионе. Некоторые сервисы доступны в зависимости от региона. Очень часто сервисы перед официальным выходом предоставляются в виде preview. Некоторые регионы быстрее внедряют новые технологии и дают опробовать тот или иной появившийся сервис. Не все регионы предоставляют возможность использования весь ассортимент серий виртуальных машин.
В нашей практике сравнение скорости доступа преимущество зачастую показывает региона Западная Европа. Особенно это заметно для компаний чьи сервера и клиенты расположены в европейской части России. В каждом конкретном случае, и особенно если ваши ЦОД и клиенты расположены на Дальнем Востоке, имеет смысл проверить задержки из своего ЦОД (либо из того географического региона, где расположены ваши клиенты) для выбора лучшего региона Azure.

Такие сервисы как Azure Latency Test позволяют заранее проверить задержки до каждого из регионов Azure из сети вашего ЦОД. Пример результатов измерения задержке при помощи упомянутого сервиса при тестировании из нашего московского офиса:

4: Как применять к облачным инсталляциям методы, проверенные на земле

В каждой миграции мы задаемся вопросом о том как мы можем использовать в облаке традиционные решения, проверенные классической инфраструктурой. В частности, при подготовке решения мы опираемся на рекомендации вендора для разработки технически верного решения. Проекты на SAP HANA не являются исключением и тоже проходят через призму рекомендаций и лучших практик.
На одном из проектов при реализации первого этапа решения, был развернут Jump сервер на базе Windows. Для оптимизации затрат начального этапа разработки на том же сервере был развернут и NFS сервер для нужд непродуктивных сред, что закрывало текущие потребности разработчиков и позволяло существенно сэкономить на ресурсах.

Время шло, среды и потребности в ресурсах росли, а NFS сервер справлялся со всеми поставленными задачами. Постепенно в рамках проекта мы приблизились к исчерпанию ресурсов начальной ВМ. Ресурсы ВМ в MS Azure можно увеличить за минуты, но параллельно повысились требования к отказоустойчивости сервера, что заставило рассмотреть более масштабную реконфигурацию.
Для реализации был использован Linux сервер, сервис DRBD и функционал Availability set, которые закрыли вопрос репликации данных между нодами кластера NFS и повысили доступность на случай выхода из строя одной из двух нод кластера.

К слову сказать: через пару месяцев после внедрения кластерного решения в Azure добавили сервис NetApp Files, который позволяет воспользоваться преимуществами массивов NetApp, но оплачиваемыми по модели Pay-As-You-Go.

5: Как автоматизировать график работы ВМ

При использовании любой облачной инфраструктуры всегда имеет смысл проанализировать какие дополнительные механизмы могут быть использованы для максимальной экономии средств.
В нашем случае тестирование систем происходит в рабочее время. Если в обычной инфраструктуре простаивание серверов выливается преимущественно в повышенные счета за электроэнергию, то в облаке сервера не приносящие пользу потребляют финансы за аренду мощностей. Мы оценили графики нагрузок на серверах тестирования и разработки и обратили внимание что подавляющая часть разработчиков и тестировщиков используют систему по рабочим дням с 8-00 до 20-00.

В тех случаях, когда график нагрузки на непродуктивные системы предсказуем и цикличен мы стараемся применять скрипты автоматизации включения-выключения ВМ. В Azure есть несколько инструментов: Auto-Shutdown, Automation Accounts и Cloud Shell. Мы используем их не все. Auto-shutdown исключили потому что он умеет только выключать ВМ. Cloud Shell тоже не задействовали так как для него нужно готовить дополнительные скрипты, разрабатывать графики и где-то всё это безопасно хранить с наличием резервирования, что сводило экономию до минимума.

В нашем случае используется более гибкий механизм. Automation Accounts предлагает уже готовое и рабочее решение в виде Runbooks, позволяющие по расписанию включать и выключать виртуальные машины.

Мы подготовили графики для соответствующих ресурсов, загрузили Runbooks и сформировали связи между графиками и ресурсами.

Как итог мы дополнительно сократили итоговую стоимость владения. Первоначально эти инструменты не были запланированы для реализации, но уже на стадии предварительной эксплуатации реализовали их.
Изменение графика производится за несколько минут. Вначале производится формирование нового графика, потом ассоциация сформированного графика с необходимым ресурсом. При необходимости и наличии большого числа изменений есть возможность использовать Cloud Shell для автоматизации данного процесса.

Мониторинг потребления ресурсов

Если для обычных ЦОД мониторинг работоспособности и потребления ресурсов к сожалению обычно отходит на второй план, то в рамках Azure этого допускать нежелательно. Информация об истории потребления ресурсов напрямую влияет на возможности по оптимизации затрат. А в случае с заблаговременным резервированием ресурсов может служить сигналом к доработкам архитектуры.

7: Подстраховка на случай форс-мажоров

Многие компании опасаются размещать свои ИТ системы на облачных ресурсах из-за боязни блокировок, которые ранее точечно проводились регуляторами. Как и любой другой риск этот тоже может быть учтен при проектировании системы. В проектах мы, как правило, реализуем еженедельную выгрузку бекапов системы из облака в ЦОД Заказчика. Это позволяет быть уверенными в том, что система может быть восстановлена при любом развитии событий. В дополнении к этому мы применяем стратегию мультиоблачной инсталляции, которая позволит в случае ограничения доступа не остаться без доступа к ресурсам. В данном сценарии альтернативные облачные провайдеры используются как DR сайты основного облака, что позволяет восстановить доступность системы в случае масштабных блокировок.

7+: Обработка персональных данных

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

Итоги

Многие не решаются разворачивать инфраструктуру на базе MS Azure и других облачных провайдеров, но наша практика показывает что вдумчивый анализ и реализация подходов, характерных для облачных инсталляций, способны обеспечить максимальные преимущества от облака.

Подробнее..

Категории: Облачные сервисы , Cloud , Microsoft azure , Azure , Sap , Облако , Блог компании accenture

Из песочницы Установка базы данных SAP HANA в Яндекс Облаке. Пошаговое руководство

16.09.2020 22:19:36 |

Автор: admin

Продолжаем эксперименты по установке различных SAP систем в Яндекс Облаке.

В первой части (статья была опубликована в блоге Яндекс Облака) был рассмотрена установка платформы SAP Netweaver ABAP AS, которая является основой для большинства SAP систем. В этой публикации мы перейдем от сервера приложений к уровню базы данных.

Изначально SAP Netweaver работал на широком спектре баз данных, среди которых были как принадлежащие компании SAP (SAP MaxDB, SAP ASE) так и базы данных от сторонних производителей (DB2, Oracle и MS SQL Server). Ситуация кардинально начала меняться в 2015 году с выходом SAP HANA (High-performance Analytic Appliance). Эта база данных позиционировалась компанией SAP как революционный для рынка продукт:

обработка всех запросов осуществляется исключительно в оперативной памяти
совмещение построчного и поколоночного хранение данных
встроенные библиотеки PAL (Predictive Analytics Library), BFL (Business Function Library), Text Analysis, SAP HANA SQLScript и другие инструменты для подготовки данных на стороне базы данных и таким образом уменьшения обмена данными с сервером приложений.

Чтобы максимально использовать потенциал новой БД в SAP перерабатывают свою флагманскую ERP-система, которая выходит в 2015 году под названием S/4HANA и уже работает исключительно на базе SAP HANA. В последствии глубоко переработанные HANA версии появляются у других популярных продуктов хранилища данных BW (Business Warehouse) решение выходит на рынок под названием SAP BW/4HANA и у CRM-системы решение выходит на рынок под названием SAP C/4HANA.

Остальные SAP ABAP и JAVA системы, например, шина данных SAP Process Orсhestration теперь могут использовать SAP HANA, как одну из доступных для установки баз данных, наряду с Oracle, DB2 и другими.

Поскольку SAP HANA является мультиконтейнерной базой данных, типичный корпоративный SAP ландшафт выглядит следующим образом:

в этом скриношоте каждый тенант это изолированная база данных какой-либо SAP системы (SAP Process Orсhestration, SAP EWM, SAP ATTP, SAP S/4HANA и т.д) внутри одной инсталляции SAP HANA.

Со временем у SAP появились также и коммерческие продукты которые представляют собой связку веб-приложение + база данных SAP HANA.

Например, SAP Medical Research Insights. Данная система должна помочь врачам выработать правильный план лечения, опирающийся на огромный массив данных, в том числе и о генетических исследованиях.

Еще один важный момент это наличие в архитектуре SAP HANA встроенного веб сервера (SAP HANA Extended Application Service). Данный сервер имеет привилегированный доступ к базе данных и позволяет выполнять приложения на Java, Python, Node.js и множестве других языков программирования. В версии сервиса Advanced Model (XSA) в ландшафте SAP HANA появляется такой функционал, как интегрированная среда разработки с веб-интерфейсом (SAP WEB IDE), Codereview (Gerrit) планировщик зданий (SAP XS JOB SCHEDULER) и многое другое.

Архитектура SAP HANA XSA:

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

Однако SAP HANA будет интересна не только в Enterprise-среде, и не только среди разработчиков SAP. Благодаря гибкой лицензионной политики этот продукт можно бесплатно установить и использовать, в том числе и в коммерческих целях (размер в этом случае ограничен 32 GB) Возможно приведённый ниже пример установки и использования даст идею о том какое место может занять база данных SAP HANA и SAP HANA Extended Application Service в Вашем проекте.

Шаг 1. Скачиваем установочные файлы SAP HANA

Заходим на страницу загрузки SAP HANA, express edition и если у Вас нет учетной записи в SAP необходимо пройти простую регистрацию

Скачиваем и запускаем SAP HANA Express Edition Download Manager

В Download Manager укажем следующие варианты загрузки
Платформа Linux/x86 64
Image Binary Installer
Package Applications*

* Под Applications подразумевается база данных SAP HANA, сервер приложений и среда разработки SAP HANA Extended Application Services, Advanced Model (XSA)

Шаг 2. Создаём виртуальную машину в Яндекс Облаке

На этом шаге нам понадобится следующий бесплатный софт:

PuTTY SSH-клиент.
PuTTYgen Генератор Public/Private ключей.
WinSCP SFTP-клиент.

Как альтернативу для данных приложений можно также рассмотреть приложение MobaXTerm
Создадим связку Public-Private ключ с помощью PuTTYgen.

Регистрируемся / заходим в Яндекс Облако (http://personeltest.ru/aways/cloud.yandex.ru/). Переходим в раздел Compute Cloud и приступаем к созданию виртуальной машины.

Имя виртуальной машины: saphana2

Зададим подходящие характеристики ВМ. В руководстве по установке для SAP HANA Express Edition (Server + Application) видим следующие рекомендуемые параметры:

Зададим их при создании нашей виртуальной машины.

vCPU 2,
RAM 32GB,
15 GB + 150 GB, где
15 GB (загрузочный диск SSD)
150 GB (данные * HDD)

* т.к. SAP HANA все операции проводит в оперативной памяти в качестве носителя для снепшота данных мы можем выбрать более медленный HDD

В качестве операционной системы выберем последнюю стабильную ОС OpenSUSE, на момент написания статьи это версия ОС OpenSUSE 42.3

Укажем Логин и Public SSH-ключ, сгенерированный с помощью PuTTYgen

Шаг 3. Подготавливаем виртуальную машину к установке SAP HANA XSA

Находим в настройках Публичный IPv4 адрес:

Подключаемся к созданной ВМ с помощью Putty-клиента, указав в подключении публичный IPv4, заданный логин и путь к Private ключу

Подготовим файловую структуру к установке.

lsblk
vda boot диск, vdb диск, созданный под данные.

SAP рекомендует следующую файловую структуру:

/usr/sap + /usr/sap/distr 35 GB
/hana/shared/data 60 GB
/hana/shared/log 10 GB
/hana/shared 40 GB

Реализуем такую структуру с помощью утилиты fdisk:

fdisk /dev/vdb`

Проверим ещё раз структуру и создадим файловую систему ext4 на всех созданных разделах:

lsblk

mkfs.ext4 /dev/vdb1mkfs.ext4 /dev/vdb2mkfs.ext4 /dev/vdb3mkfs.ext4 /dev/vdb4

Создадим директории под дистрибутивы и базу данных SAP HANA, а также примонтируем к ним созданные на предыдущем шаге разделы. Также обновим файл /etc/fstab, чтобы монтирование восстанавливалось при перезагрузке:

mkdir /usr/sapmkdir /hanamkdir /hana/sharedmkdir /hana/shared/datamkdir /hana/shared/logmount /dev/vdb1 /usr/sapmount /dev/vdb2 /hana/shared/datamount /dev/vdb3 /hana/shared/logmount /dev/vdb4 /hana/sharedmkdir /usr/sap/distrvi /etc/fstab

Установим разрешение на папку с установочными файлами SAP:

chmod -R 777 /usr/sap/distr

Импортируем в WinSCP настройки из Putty. Подключимся к ВМ и загрузим в /usr/sap/distr архивы SAP HANA Server (hxe.tgz), SAP HANA Extended Application Services XSA (hxeesa.tgz) и shine.tgz (Учебный контент)

Распакуем архивы:

cd /usr/sap/distr tar -xvzf hxe.tgztar -xvzf hxexsa.tgztar -xvzf shine.tgz

Добавим репозиторий:

sudo zypper ar -c https://download.opensuse.org/tumbleweed/repo/oss/ openSUSE-Tumbleweed-Oss-HTTPS

Установим требуемые для работы библиотеки libstdc++, libnuma1, libatomic и libgcc_s1:

zypper install libstdc++6zypper install libatomic1zypper install libgcc_s1zypper install libnuma1

Шаг 4. Устанавливаем SAP HANA XS

Первое с чего стоит начать установку это определением понятия SID
SID (SAP System Identificator) представляет собой комбинацию трех символов и должен быть уникальным в рамках ландшафта. В рамках установки SAP HANA Express Edition значение SID по-умолчанию HXE. Предполагается, что мы не будем выбирать в качестве SID что-то другое.

Запускаем скрипт инсталляции с правами root пользователя:

cd /usr/sap/distr ./setup_hxe.sh

В меню установки требуется несколько раз нажать Enter.

Таким образом мы установим предложенные значения по умолчанию:
Дистрибутивы лежат в /distr/HANA_EXPRESS_20

SID HXE
Номер инстанции 90
Установка всех компонентов all*
* В данном случае это значит, что мы установим набор библиотек Application Function Library (AFL), куда входят Predictive Analysis Library (PAL), Business Function Library (BFL), Optimization Function Library (OFL).

Плагин SAP HANA EPMMDS предназначен для получения данных из различных OLAP источников, а подсистема расширенных сервисов (Extended Services, XS) это встроенный веб-сервер и набор различных компонентов, имеющих привилегированный доступ к базе данных.

Указываем мастер-пароль для пользователей, которые создаются во время инсталляции SAP HANA.

Поскольку мы выбрали SID HXE, adm пользователь на уровне операционной системы будет hxeadm. Указанный мастер-пароль также применится и к пользователю SYSTEM на уровне базы данных.

В процессе установки XSA потребуется также задать мастер-пароль от пользователей XSA_ADMIN, XSA_DEV, TEL_ADMIN

Процесс инсталляции.

База SAP HANA Express Edition установлена.

Шаг 5. Проверка работы SAP HANA XSA

Проверим что база данных SAP HANA установлена и работает:

su  hxeadmHDB info

Пример сервисов, которые будут запущены:

Пройдём авторизацию в SAP HANA Extended Application Services, Advanced Model:

xs-admin-login

Пользователь: XSA_ADMIN
Пароль: Мастер-пароль, который мы задали при установке
Проверим версию SAP HANA Extended Application Services, Advanced Model:

xs -v

Шаг 6. Пост-инсталляционные действия

Для того чтобы использовать веб-инструменты разработки и администрирования SAP HANA XSA необходимо отредактировать файл hosts на локальной Windows-мшине.

1. Открываем блокнот от имени Администратора

2. Открываем в блокноте файл C:\Windows\System32\drivers\etc\hosts

3. Вносим строку вида:
<внешний ip-адрес>

Шаг 7. Начало работы

Существует несколько способов администрирования и разработки для SAP HANA XSA
Администрирование: SAP HANA Cockpit. В настоящее время SAP позиционирует его, как основной инструмент управления базой данных. Также возможно управление базой данных из Eclipse (Перспектива SAP HANA Administration Console)

Разработка: Через веб-интерфейс, через инструмент SAP Web IDE или через Eclipse (Перспектива SAP HANA Development)

Поскольку HANA Cockpit и WebIDE были установлены во время процесса инсталляции именно их как средства управления и администрирования мы и будем рассматривать.

Получим url для интересующих нас приложений xsa-cockpit, webide и cockpit-web-app:

xs app xsa-cockpit --urlsxs app webide --urlsxs app cockpit-web-app --urls

Скопируем https адрес и откроем его в браузере для каждого из этих приложений.

XSA Cockpit

XSA Cockpit это браузерная система управления сервером приложений SAP HANA Extended Application Services, Advanced Model.
XSA Cockpit позволяет управлять пользователями и ролями, организациями и пространствами.
В разделе User Management можно проверить, и при необходимости назначить, для пользователя XSA_DEV роли DEVX_ADMINISTRATOR, DEVX_DEVELOPER.
В разделе Tenant Databases можно расширить возможности XSA на новый тенант, в нашем случае HXE и связать с ним пространство разработки development

HANA Cockpit

HANA Cockpit это система управления базой данных SAP HANA.

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

Скрипт регистрации ресурсов базы данных в HANA Cockpit выполняется при установке, если скрипт по каким-либо причинам не выполнился его необходимо запустить вручную до первого использования Cockpit-ом.

su  hxeadm/usr/sap/distr/HANA_EXPRESS_20/register_cockpit.sh

WebIDE

WebIDE это интегрированная с GitHub-ом браузерная среда разработки.

В разделе Development можно разрабатывать, тестировать и публиковать модули на NodeJS, Java, HTML5.

В разделе Database Explorer можно создавать и управлять объектами на уровне базы данных (таблицы, представления, хранимые процедуры и т.д).

Подключение к тенанту и обзор объектов в нём:

Шаг 8. Первое Node.js приложение

Откроем WebIDE и создадим простое UI5/Node.js приложение Hello World!

Для этого выберем
Workspace Git Clone Repository
В качестве репозитория укажем Repository github.com/basisteam-io/SAPHANAXS_helloworld.git

Таким образом мы получим копию простого приложения Hello world!, разобраться или модифицировать которое не составит никакого труда.

Установим пространство где будет развернуто данное приложение.

В нашем случае это пространство development.

Последовательно сделаем Вuild приложения и проекта.

Результатом билдинга будет .mtar файл в папке mta_archives, которая расположена в верхней части меню с иерархией проекта.

Необходимо выбрать содержащийся в папке .mtar файл и сделать для него операцию Deploy to XS Advanced.

Вернёмся к командной строке и переключимся на пространство development:

xs target -o HANAExpress -s development

Выведем список всех запущенных приложений в этом пространстве:

xs apps

Отроем наше приложение в браузере:

Заключение

Установить базу данных SAP HANA с сервером приложений HANA Extended Application Services, Advanced Model и написать своё первое приложение оказалось не сложно. В следующей статье рассмотрим более сложный пример, включающий в себя взаимодействие с базой данных SAP HANA.

Роман Горбенко, консультант SAP EWM / SAP BASIS

Подробнее..

Категории: Облачные сервисы , Tutorial , Sap , Яндекс.облако , Hana

Из песочницы Реализация MVVM в ABAP

22.08.2020 16:14:02 |

Автор: admin

После окончания университета я несколько лет работал программистом C#. Я разрабатывал приложения на WPF с использованием шаблона проектирования MVVM. Затем перешел на ABAP. К большому удивлению обнаружил что ABAP является скорее процедурным языком чем объектно-ориентированным, хотя SAP прилагает большие усилия для продвижения ОО-парадигмы. Для разделения бизнес-логики от GUI как правило используют архитектурный шаблон MVC. Пытаясь реализовать MVC шаблон я каждый раз сталкивался с определенными сложностями, которые делают поддержку программы еще более сложной чем если бы она была написана на процедурах. Не смотря на то, что реализация MVC подробно и с примерами описана в книге Design Patterns in ABAP Objects и на специализированных ресурсах (sapland.ru, blogs.sap.com и др.), проблемы с разделением логики остаются. В реализации MVC на ABAP независимой частью остается Model, а View и Controller тесно связаны между собой. Сильное сопряжение между View и Controller затрудняет поддержку и масштабируемость. Ниже описано почему так происходит и что с этим делать.

Шаблоны MVC и MVVM

Подробно описывать принцип работы шаблонов MVC и MVVM в данной статье я не буду. Приведу лишь основные моменты, которые понадобятся нам в дальнейшем.

Основное отличие MVC от MVVM в том, что в первой Controller знает как View, так и Model, также допускается что View будет знать о Model.

В MVVM шаблоне связь между слоями более слабая. View знает только ViewModel, а ViewModel только Model. View получает данные от ViewModel через ссылку на DataContex.

Шаблон MVVM предназначен для разработки в WPF на языке C#. Но его идею можно применять и в ABAP.

Проблемы MVC в ABAP

При реализации MVC, как правило, классы Model выносят в глобальное определение, а классы View и Controller в локальное. Использование локальных классов обусловлено необходимостью взаимодействия с GUI элементами. Дело в том, что на ABAP-классах нельзя построить полноценный GUI. В классах View можно использовать функционал для формирования GUI (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY и т.п.), но этого не достаточно. Создать GUI-статусы, заголовки, экраны, PBO, PAI в классе невозможно.

Локальные View и Controller, имеют ряд недостатков:

View и Controller имеют доступ ко всем глобальным переменным и параметрам экрана выбора.
Обработка PBO и PAI в Controller требует получения состояния View (например получение выделенных строк ALV) или обновление View (например обновление таблицы ALV). В качестве решения данной проблемы нередко можно увидеть публичные атрибуты View, на которые воздействует Controller, или когда View имеет ссылку на Controller. Оба решения плохие, т.к. в первом случае нарушается инкапсуляция, а во втором Low Coupling.

MVVM в ABAP или MVA

Желая использовать преимущества MVVM в ABAP и сделать слои более независимыми я определил для себя следующий шаблон разработки.

Так как в чистом виде MVVM реализовать на ABAP нельзя, то ViewModel использовать не совсем корректно. Поэтому вместо ViewModel и Controller я использую Application.

Принцип разделения логики аналогичен принципу MVVM. View передает команды пользователя в Application, а Application воздействует на модель. Обратная связь при этом отсутствует.
Особенностью ABAP приложений является то, то представление может обновиться только после действий пользователя. Даже если какой-нибудь асинхронный процесс поменяет модель, то инициировать обновление представление он не сможет. Данная особенность позволяет ослабить связь модель-представление и делегировать функцию обновления представления самому представлению. Иными словами, представление само должно решать, когда надо обновить себя, а когда нет.

Концепция MVA

Реализация MVA основана на объектно-ориентированном подходе, где на каждый слой архитектуры будет реализован один или несколько классов. Каждый из слоев обладает рядом свойств.

Представление (View и IView):

MVA работает с абстракцией представления IView. Все классы View должны содержать реализацию IView.
IView содержит события, которые требуют взаимодействия с моделью
IView содержит контекст ссылка на данные модели, которые необходимо отобразить пользователю
View может содержать бизнес-логику, которая не требует взаимодействия с моделью. Например, если требуется реализовать из ALV проваливание в карточку контрагента, то данная логика будет относиться к представлению.
View содержит GUI элементы в группе функций, которая связана с классом View.

Приложение (Application):

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

Модель (Model):

Содержит публичные атрибуты, которые необходимы представлению.
Содержит критерии расчета модели и метод инициализации.

Реализация MVA

Рассмотрим реализацию MVA на примере отчета по движению материалов. В качестве взаимодействия с моделью будет кнопка обновления данных.

Диаграмма классов будет выглядеть следующим образом.

Model. Конструктор модели будет принимать на входи критерии выбора данных. Класс будет иметь методы инициализации и обновления данных, а также атрибут с данными для отображения.

IView. Интерфейс представления содержит методы установки контекста, отображения представления, события и определение типов контекста.

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

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

Реализация класса View в ALV представлении

В данной реализации нам необходимо определение GUI статуса, для этого создадим ФМ и свяжем его с экземпляром CL_SALV_TABLE

Важно что все UI события принимает View (в данном случае через ON_USER_COMMAND) и при необходимости View делает RAISE EVENT для Application. Этот подход делает View и Application более независимыми.

Application. Конструктор приложения принимает на вход критерии приложения (параметры экрана выбора) и создает экземпляры Model и View, подписывается на события View и связывает контекст View с Model. Конструктор это единственное место где приложение знает о View. Application содержит метод RUN, который запускает программу. Запуск приложения можно сравнить с запуском транзакции с заранее определенными параметрами экрана. Это позволяет использовать ее из других программ без SUBMIT.

Запуск Application. Теперь делаем программу, которая будет запускать приложение.

Все, приложение готово. Можно смотреть результат.

Бизнес-логика на стороне View. Обработку событий, которые не требуют обращения к модели и контроллеру, можно делать в самой View.

Например, если требуется реализовать открытие MM03 при двойном клике на MATNR, то обработку данной логики можно сделать на стороне View.

На уровень View данная логика вынесена исходя из соображений: к модели не требуется обращаться за дополнительными данными; логика относится только к ALV, т.е. если бы была реализация View в виде Excel или PDF, то данное событие невозможно было бы обработать.

Литература

Design Patterns in ABAP Objects
Паттерны для новичков: MVC vs MVP vs MVVM
Архитектурные шаблоны в ABAP: MVC, MVP, MVVM, MVA

Подробнее..

Категории: Erp-системы , Mvvm , Sap , Mvc , Abap , Mva

	Русский
	English