Као што знате, САП нуди читав низ софтвера како за одржавање трансакцијских података тако и за обраду ових података у системима за анализу и извештавање. Конкретно, платформа САП Бусинесс Варехоусе (САП БВ) је комплет алата за складиштење и анализу података са широким техничким могућностима. Уз све своје објективне предности, САП БВ систем има један значајан недостатак. Ово је висока цена чувања и обраде података, посебно приметна када се користи САП БВ заснован на облаку на Хани.
Шта ако почнете да користите неки не-САП и по могућности ОпенСоурце производ као складиште? Ми у Кс5 Ретаил Гроуп смо изабрали ГреенПлум. Ово, наравно, решава питање трошкова, али истовремено се одмах појављују проблеми који су скоро подразумевано решени када се користи САП БВ.
Конкретно, како преузети податке из изворних система, који су углавном САП решења?
ХР Метрицс је био први пројекат у коме је било неопходно решити овај проблем. Наш циљ је био да направимо репозиторијум ХР података и изградимо аналитичко извештавање у области рада са запосленима. У овом случају, главни извор података је трансакцијски систем САП ХЦМ, у којем се спроводе све кадровске, организационе и платне активности.
Екстракција података
У САП БВ постоје стандардни екстрактори података за САП системе. Ови екстрактори могу аутоматски да прикупљају потребне податке, надгледају њихов интегритет и одређују делте промена. Ево, на пример, стандардног извора података за атрибуте запослених 0ЕМПЛОИЕЕ_АТТР:
Резултат издвајања података из њега за једног запосленог:
Ако је потребно, такав екстрактор се може модификовати тако да одговара вашим сопственим захтевима или се може креирати сопствени екстрактор.
Прва идеја која се појавила била је могућност њихове поновне употребе. Нажалост, ово се показало као немогућ задатак. Већина логике је имплементирана на страни САП БВ, и није било могуће безболно одвојити екстрактор на извору од САП БВ.
Постало је очигледно да ћемо морати да развијемо сопствени механизам за издвајање података из САП система.
Структура складиштења података у САП ХЦМ
Да бисмо разумели захтеве за такав механизам, прво треба да одредимо који су нам подаци потребни.
Већина података у САП ХЦМ се чува у равним СКЛ табелама. На основу ових података, САП апликације кориснику визуелизују организационе структуре, запослене и друге ХР информације. На пример, овако изгледа организациона структура у САП ХЦМ:
Физички, такво стабло се чува у две табеле - у објектима хрп1000 и у хрп1001 везама између ових објеката.
Објекти „Одељење 1” и „Канцеларија 1”:
Однос између објеката:
Може постојати огроман број обе врсте објеката и врста веза између њих. Постоје и стандардне везе између објеката и прилагођене за ваше специфичне потребе. На пример, стандардни однос Б012 између организационе јединице и позиције са пуним радним временом указује на шефа одељења.
Приказ менаџера у САП-у:
Складиштење у табели базе података:
Подаци о запосленима се чувају у па* табелама. На пример, подаци о кадровским догађајима за запосленог се чувају у табели па0000
Одлучили смо да ће ГреенПлум узимати „сирове“ податке, тј. само их копирајте из САП табела. И директно у ГреенПлум-у они ће бити обрађени и конвертовани у физичке објекте (на пример, Одељење или Запослени) и метрике (на пример, просечан број запослених).
Дефинисано је око 70 табела из којих се подаци морају пренети у ГреенПлум. Након тога смо почели да разрађујемо метод за пренос ових података.
САП нуди прилично велики број механизама интеграције. Али најлакши начин је да је директан приступ бази података забрањен због ограничења лиценцирања. Дакле, сви токови интеграције морају бити имплементирани на нивоу сервера апликација.
Следећи проблем је био недостатак података о избрисаним записима у САП бази података. Када избришете ред у бази података, он се физички брише. Оне. формирање делте промене на основу времена промене није било могуће.
Наравно, САП ХЦМ има механизме за бележење промена података. На пример, за накнадни пренос у системе примаоца постоје показивачи промена који бележе све промене и на основу којих се формира Идоц (објекат за пренос на спољне системе).
Пример ИДоц-а за промену инфотипа 0302 за запосленог са бројем особља 1251445:
Или вођење евиденције промена података у табели ДБТАБЛОГ.
Пример дневника за брисање записа са кључем КК53216375 из табеле хрп1000:
Али ови механизми нису доступни за све потребне податке, а њихова обрада на нивоу сервера апликација може потрошити доста ресурса. Стога, масовно омогућавање логовања на свим потребним табелама може довести до приметне деградације перформанси система.
Следећи велики проблем су биле груписане табеле. Подаци о процени времена и платном списку у РДБМС верзији САП ХЦМ се чувају као скуп логичких табела за сваког запосленог за сваки обрачун. Ове логичке табеле се чувају као бинарни подаци у табели пцл2.
Платни списак:
Подаци из кластеризованих табела не могу се сматрати СКЛ командом, али захтевају употребу САП ХЦМ макроа или посебних функционалних модула. Сходно томе, брзина читања таквих табела ће бити прилично ниска. С друге стране, такви кластери чувају податке који су потребни само једном месечно – коначан платни списак и временску процену. Дакле, брзина у овом случају није толико критична.
Процењујући опције за формирање делте промена података, одлучили смо да размотримо и опцију потпуног истовара. Могућност преноса гигабајта непромењених података између система сваког дана можда неће изгледати добро. Међутим, он такође има бројне предности – нема потребе да се делта имплементира на страни извора и да се имплементира уградња ове делте на страни пријемника. Сходно томе, смањују се трошкови и време имплементације, а повећава се поузданост интеграције. Истовремено, утврђено је да се скоро све промене у САП ХР дешавају у периоду од три месеца пре текућег датума. Стога је одлучено да се одлучи за дневно пуно преузимање података из САП ХР Н мјесеци прије текућег датума и мјесечно пуно преузимање. Н параметар зависи од конкретне табеле
и креће се од 1 до 15.
Предложена је следећа шема за екстракцију података:
Спољни систем генерише захтев и шаље га у САП ХЦМ, где се проверава комплетност података и дозвола за приступ табелама овог захтева. Ако је провера успешна, САП ХЦМ покреће програм који прикупља потребне податке и преноси их у решење за интеграцију Фусе. Фусе одређује потребну тему у Кафки и тамо преноси податке. Затим се подаци из Кафке преносе у Стаге Ареа ГП.
У овом ланцу нас занима питање екстракције података из САП ХЦМ. Погледајмо то детаљније.
САП ХЦМ-ФУСЕ дијаграм интеракције.
Спољни систем одређује време последњег успешног захтева према САП-у.
Процес се може покренути помоћу тајмера или другог догађаја, укључујући постављање временског ограничења за чекање на одговор са подацима из САП-а и покретање захтева за понављање. Затим генерише делта захтев и шаље га САП-у.
Подаци захтева се шаљу телу у јсон формату.
Метод хттп: ПОСТ.
Пример захтева:
САП сервис прати захтев за комплетност, усклађеност са тренутном САП структуром и доступност дозволе за приступ траженој табели.
У случају грешака, сервис враћа одговор са одговарајућим кодом и описом. Ако је контрола успешна, креира позадински процес за генерисање узорка, генерише и синхроно враћа јединствени ИД сесије.
У случају грешке, спољни систем то бележи у дневник. У случају успешног одговора, преноси ИД сесије и назив табеле за коју је захтев поднет.
Спољни систем региструје тренутну сесију као отворену. Ако постоје друге сесије за ову табелу, оне се затварају са упозорењем које се евидентира.
САП позадински посао генерише курсор на основу наведених параметара и пакета података одређене величине. Величина групе је максималан број записа које процес чита из базе података. Подразумевано се претпоставља да је једнако 2000. Ако у узорку базе података има више записа од коришћене величине пакета, након преноса првог пакета, формира се следећи блок са одговарајућим помаком и увећаним бројем пакета. Бројеви се повећавају за 1 и шаљу стриктно узастопно.
Затим, САП прослеђује пакет као улаз веб сервису спољног система. И систем врши контроле над долазним пакетом. Сесија са примљеним ИД-ом мора бити регистрована у систему и мора бити у отвореном статусу. Ако је број пакета > 1, систем треба да забележи успешан пријем претходног пакета (пацкаге_ид-1).
Ако је контрола успешна, спољни систем анализира и чува податке табеле.
Додатно, ако је последња заставица присутна у пакету и серијализација је била успешна, интеграцијски модул се обавештава о успешном завршетку обраде сесије и модул ажурира статус сесије.
У случају грешке у контроли/парсингу, грешка се евидентира и спољни систем ће одбацити пакете за ову сесију.
Исто тако, у супротном случају, када спољни систем врати грешку, она се евидентира и пренос пакета се зауставља.
За тражење података на страни САП ХСМ имплементиран је сервис интеграције. Сервис је имплементиран на ИЦФ оквиру (САП Интернет Цоммуницатион Фрамеворк - ). Омогућава вам да тражите податке из САП ХЦМ система користећи одређене табеле. Приликом креирања захтева за подацима могуће је навести листу специфичних поља и параметара филтрирања како би се добили потребни подаци. Истовремено, имплементација услуге не подразумева никакву пословну логику. Алгоритми за израчунавање делта, параметара упита, праћење интегритета итд. такође су имплементирани на страни екстерног система.
Овај механизам вам омогућава да прикупите и пренесете све потребне податке за неколико сати. Ова брзина је на граници прихватљиве, па ово решење сматрамо привременим, што је омогућило да се попуни потреба за алатом за екстракцију на пројекту.
У циљној слици, да би се решио проблем екстракције података, истражују се опције за коришћење ЦДЦ система као што су Орацле Голден Гате или ЕТЛ алати као што је САП ДС.
Извор: ввв.хабр.цом