Како што знаете, SAP нуди целосен опсег на софтвер и за одржување на трансакциски податоци и за обработка на овие податоци во системите за анализа и известување. Особено, платформата SAP Business Warehouse (SAP BW) е комплет алатки за складирање и анализа на податоци со обемни технички можности. И покрај сите негови објективни предности, системот SAP BW има еден значаен недостаток. Ова е висока цена за складирање и обработка на податоци, особено забележлива кога се користи SAP BW базиран на облак на Хана.
Што ако почнете да користите некој не-SAP и по можност производ од OpenSource како складиште? Ние во X5 Retail Group го избравме GreenPlum. Ова, се разбира, го решава прашањето за трошоците, но во исто време, веднаш се појавуваат прашања што беа решени речиси стандардно при користење на SAP BW.
Конкретно, како да се повратат податоците од изворните системи, кои се претежно SAP решенија?
HR Metrics беше првиот проект во кој беше неопходно да се реши овој проблем. Нашата цел беше да создадеме складиште на податоци за човечки ресурси и да изградиме аналитичко известување во областа на работа со вработените. Во овој случај, главен извор на податоци е трансакцискиот систем SAP HCM, во кој се извршуваат сите кадровски, организациски и платежни активности.
Извлекување податоци
Во SAP BW постојат стандардни екстрактори на податоци за SAP системите. Овие екстрактори можат автоматски да ги соберат потребните податоци, да го следат неговиот интегритет и да одредат делта на промени. Еве, на пример, стандардниот извор на податоци за атрибутите на вработените 0EMPLOYEE_ATTR:
Резултатот од вадењето податоци од него за еден вработен:
Доколку е потребно, таков екстрактор може да се измени за да одговара на вашите сопствени барања или може да се создаде сопствен екстрактор.
Првата идеја што се појави беше можноста за нивна повторна употреба. За жал, ова се покажа како невозможна задача. Поголемиот дел од логиката е имплементирана на страната SAP BW и не беше можно безболно да се оддели екстракторот на изворот од SAP BW.
Стана очигледно дека ќе треба да развиеме сопствен механизам за извлекување податоци од SAP системите.
Структура за складирање податоци во SAP HCM
За да ги разбереме барањата за таков механизам, прво треба да одредиме кои податоци ни се потребни.
Повеќето податоци во SAP HCM се зачувани во рамни SQL табели. Врз основа на овие податоци, SAP апликациите ги визуелизираат организациските структури, вработените и другите информации за човечки ресурси на корисникот. На пример, вака изгледа организациската структура во SAP HCM:
Физички, ваквото дрво е зачувано во две табели - во hrp1000 објекти и во hrp1001 врските помеѓу овие објекти.
Објекти „Оддел 1“ и „Канцеларија 1“:
Односот помеѓу предметите:
Може да има огромен број на двата вида објекти и типови на врски меѓу нив. Постојат и стандардни врски помеѓу објектите и приспособени за вашите сопствени специфични потреби. На пример, стандардниот однос B012 помеѓу организациона единица и позицијата со полно работно време укажува на раководител на оддел.
Приказ на менаџер во SAP:
Складирање во табела со база на податоци:
Податоците за вработените се чуваат во табелите pa*. На пример, податоците за персоналните настани за вработен се чуваат во табелата pa0000
Решивме дека GreenPlum ќе земе „суровини“ податоци, т.е. само копирајте ги од табелите SAP. И директно во GreenPlum тие ќе бидат обработени и претворени во физички објекти (на пример, Оддел или вработен) и метрика (на пример, просечен број на вработени).
Дефинирани се околу 70 табели, податоците од кои мора да се пренесат на GreenPlum. По што почнавме да разработуваме метод за пренос на овие податоци.
SAP нуди широк спектар на механизми за интеграција. Сепак, наједноставниот метод - директен пристап до базата на податоци - е забранет поради ограничувања за лиценцирање. Затоа, сите интеграциски текови мора да се имплементираат на ниво на SAP. сервер апликации.
Следниот проблем беше недостатокот на податоци за избришани записи во базата на податоци на SAP. Кога ќе избришете ред во базата на податоци, тој физички се брише. Оние. формирањето на делта за промена врз основа на времето на промена не беше можно.
Се разбира, SAP HCM има механизми за снимање на промените на податоците. На пример, за последователно пренесување до системите на примачи, постојат покажувачи за промена кои ги снимаат сите промени и врз основа на кои се формира 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 ја одредува потребната тема во Кафка и таму ги пренесува податоците. Следно, податоците од Кафка се пренесуваат на Сценската област ГП.
Во овој синџир, ние сме заинтересирани за прашањето за извлекување податоци од SAP HCM. Ајде да го разгледаме подетално.
Дијаграм за интеракција на SAP HCM-FUSE.
Надворешниот систем го одредува времето на последното успешно барање до SAP.
Процесот може да се стартува со тајмер или друг настан, вклучително и истек на време за да се чека одговор со податоци од SAP и да се иницира барање за повторување. Потоа генерира делта барање и го испраќа до SAP.
Податоците за барањето се испраќаат до телото во формат json.
Метод http: POST.
Пример барање:
Услугата SAP го следи барањето за комплетност, усогласеност со тековната структура на SAP и достапност на дозвола за пристап до бараната табела.
Во случај на грешки, услугата враќа одговор со соодветна шифра и опис. Ако контролата е успешна, таа создава процес во заднина за генерирање примерок, генерира и синхроно враќа единствен идентификатор на сесија.
Во случај на грешка, надворешниот систем ја запишува во дневникот. Во случај на успешен одговор, го пренесува ID на сесијата и името на табелата за која е поднесено барањето.
Надворешниот систем ја регистрира тековната сесија како отворена. Ако има други сесии за оваа табела, тие се затвораат со евидентирано предупредување.
Позадинската работа SAP генерира курсор врз основа на наведените параметри и пакет со податоци со одредената големина. Големината на серијата е максималниот број на записи што процесот ги чита од базата на податоци. Стандардно, се претпоставува дека е еднакво на 2000. Ако има повеќе записи во примерокот на базата на податоци од користената големина на пакетот, по пренесувањето на првиот пакет, следниот блок се формира со соодветното поместување и зголемен број на пакет. Броевите се зголемуваат за 1 и се испраќаат строго последователно.
Следно, SAP го пренесува пакетот како влез во веб-услугата на надворешниот систем. И системот врши контроли на дојдовниот пакет. Сесијата со примениот ид мора да биде регистрирана во системот и таа мора да биде во отворен статус. Ако бројот на пакетот е > 1, системот треба да го запише успешното примање на претходниот пакет (package_id-1).
Ако контролата е успешна, надворешниот систем ги анализира и зачувува податоците од табелата.
Дополнително, ако последното знаменце е присутно во пакетот и сериализацијата е успешна, модулот за интеграција е известен за успешното завршување на обработката на сесијата и модулот го ажурира статусот на сесијата.
Во случај на грешка во контролата/парсирањето, грешката се евидентира и пакетите за оваа сесија ќе бидат отфрлени од надворешниот систем.
Исто така, во спротивен случај, кога надворешниот систем ќе врати грешка, тој се евидентира и преносот на пакети запира.
За да се побараат податоци од страната на SAP HСM, беше имплементирана услуга за интеграција. Услугата е имплементирана на рамката на МКФ (SAP Internet Communication Framework - ). Ви овозможува да барате податоци од системот SAP HCM користејќи специфични табели. Кога креирате барање за податоци, можно е да наведете листа на специфични полиња и параметри за филтрирање со цел да се добијат потребните податоци. Во исто време, имплементацијата на услугата не подразбира никаква деловна логика. На страната на надворешниот систем се имплементирани и алгоритми за пресметување на делта, параметри за пребарување, следење на интегритетот итн.
Овој механизам ви овозможува да ги соберете и пренесете сите потребни податоци за неколку часа. Оваа брзина е на работ на прифатлива, така што ова решение го сметаме за привремено, што овозможи да се пополни потребата од алатка за извлекување на проектот.
На целната слика, за да се реши проблемот со екстракција на податоци, се истражуваат опциите за користење CDC системи како Oracle Golden Gate или ETL алатките како SAP DS.
Извор: www.habr.com
