Ինչպես գիտեք, SAP-ն առաջարկում է ծրագրային ապահովման ամբողջական տեսականի ինչպես գործարքների տվյալների պահպանման, այնպես էլ այդ տվյալների վերլուծության և հաշվետվությունների համակարգերում մշակելու համար: Մասնավորապես, SAP Business Warehouse (SAP BW) հարթակը լայն տեխնիկական հնարավորություններով տվյալների պահպանման և վերլուծության գործիքակազմ է: Չնայած իր բոլոր օբյեկտիվ առավելություններին, SAP BW համակարգը ունի մեկ նշանակալի թերություն. Սա տվյալների պահպանման և մշակման բարձր արժեք է, հատկապես նկատելի է Hana-ում ամպի վրա հիմնված SAP BW-ի օգտագործման ժամանակ:
Ի՞նչ անել, եթե որպես պահեստ սկսեք օգտագործել որոշ ոչ SAP և գերադասելի OpenSource արտադրանք: Մենք X5 Retail Group-ում ընտրեցինք GreenPlum-ը: Սա, իհարկե, լուծում է ծախսերի հարցը, բայց միևնույն ժամանակ անմիջապես առաջանում են խնդիրներ, որոնք գրեթե լռելյայն լուծվել են SAP BW-ի օգտագործման ժամանակ։
Մասնավորապես, ինչպե՞ս կարելի է տվյալներ ստանալ սկզբնական համակարգերից, որոնք հիմնականում SAP լուծումներ են:
HR Metrics-ն առաջին նախագիծն էր, որում անհրաժեշտ էր լուծել այս խնդիրը։ Մեր նպատակն էր ստեղծել 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-ն ունի տվյալների փոփոխությունները գրանցելու մեխանիզմներ: Օրինակ՝ ստացող համակարգեր հետագա փոխանցման համար կան փոփոխության ցուցիչներ, որոնք գրանցում են ցանկացած փոփոխություն և որի հիման վրա ձևավորվում է Idoc (օբյեկտ՝ արտաքին համակարգեր փոխանցելու համար)։
IDoc-ի օրինակ՝ 0302 ինֆոտիպը փոխելու համար 1251445 անձնակազմի համարով աշխատողի համար.
Կամ տվյալների փոփոխությունների տեղեկամատյաններ պահելը DBTABLOG աղյուսակում:
hrp53216375 աղյուսակից QK1000 բանալիով գրառումը ջնջելու գրանցամատյանի օրինակ.
Բայց այս մեխանիզմները հասանելի չեն բոլոր անհրաժեշտ տվյալների համար, և դրանց մշակումը կիրառական սերվերի մակարդակով կարող է բավականին մեծ ռեսուրսներ խլել: Հետևաբար, բոլոր անհրաժեշտ աղյուսակների վրա գրանցումների զանգվածային հնարավորություն տալը կարող է հանգեցնել համակարգի կատարողականի նկատելի վատթարացման:
Հաջորդ հիմնական խնդիրը կլաստերային աղյուսակներն էին: Ժամանակի գնահատումը և աշխատավարձի տվյալները SAP HCM-ի RDBMS տարբերակում պահվում են որպես տրամաբանական աղյուսակների հավաքածու յուրաքանչյուր աշխատակցի համար յուրաքանչյուր հաշվարկի համար: Այս տրամաբանական աղյուսակները պահվում են որպես երկուական տվյալներ pcl2 աղյուսակում:
Աշխատավարձի կլաստեր.
Կլաստերավորված աղյուսակների տվյալները չեն կարող դիտարկվել որպես SQL հրաման, սակայն պահանջում են SAP HCM մակրոների կամ հատուկ գործառույթի մոդուլների օգտագործում: Համապատասխանաբար, նման աղյուսակների ընթերցման արագությունը բավականին ցածր կլինի։ Մյուս կողմից, նման կլաստերները պահում են տվյալներ, որոնք անհրաժեշտ են միայն ամիսը մեկ անգամ՝ վերջնական աշխատավարձի և ժամանակի գնահատում: Այսպիսով, արագությունն այս դեպքում այնքան էլ կարևոր չէ:
Գնահատելով տվյալների փոփոխությունների դելտայի ձևավորման տարբերակները՝ մենք որոշեցինք դիտարկել նաև ամբողջական բեռնաթափման տարբերակը։ Ամեն օր համակարգերի միջև գիգաբայթ անփոփոխ տվյալներ փոխանցելու տարբերակը կարող է լավ տեսք չունենալ: Այնուամենայնիվ, այն ունի նաև մի շարք առավելություններ. կարիք չկա և՛ դելտան իրականացնել աղբյուրի կողմից, և՛ իրականացնել այս դելտայի ներդրումը ստացողի կողմից: Համապատասխանաբար, ծախսերը և իրականացման ժամանակը կրճատվում են, իսկ ինտեգրման հուսալիությունը մեծանում է: Միևնույն ժամանակ, որոշվել է, որ SAP HR-ի գրեթե բոլոր փոփոխությունները տեղի են ունենում ընթացիկ ամսաթվից երեք ամիս առաջ հորիզոնում: Այսպիսով, որոշվեց ընտրել SAP HR N տվյալների ամենօրյա ամբողջական ներբեռնումը ընթացիկ ամսաթվից ամիս առաջ և ամսական ամբողջական ներբեռնում: N պարամետրը կախված է կոնկրետ աղյուսակից
և տատանվում է 1-ից մինչև 15:
Տվյալների արդյունահանման համար առաջարկվել է հետևյալ սխեման.
Արտաքին համակարգը ստեղծում է հարցում և ուղարկում այն SAP HCM, որտեղ այս հարցումը ստուգվում է տվյալների ամբողջականության և աղյուսակներ մուտք գործելու թույլտվությունների համար: Եթե ստուգումը հաջող է, SAP HCM-ն գործարկում է ծրագիր, որը հավաքում է անհրաժեշտ տվյալները և փոխանցում այն Fuse ինտեգրացիոն լուծմանը: Ապահովիչը որոշում է Կաֆկայում պահանջվող թեման և այնտեղ փոխանցում: Հաջորդը Կաֆկայից ստացված տվյալները փոխանցվում են Stage Area GP-ին:
Այս շղթայում մեզ հետաքրքրում է SAP HCM-ից տվյալների արդյունահանման հարցը: Եկեք նայենք դրան ավելի մանրամասն:
SAP HCM-FUSE փոխազդեցության դիագրամ:
Արտաքին համակարգը որոշում է SAP-ին վերջին հաջողված հարցման ժամանակը:
Գործընթացը կարող է գործարկվել ժմչփի կամ այլ իրադարձության միջոցով, այդ թվում՝ սահմանելով ժամանակի վերջ՝ SAP-ի տվյալների հետ պատասխանին սպասելու և կրկնվող հարցում սկսելու համար: Այնուհետև այն առաջացնում է դելտա հարցում և ուղարկում այն SAP:
Հարցման տվյալները ուղարկվում են մարմնին json ձևաչափով:
Մեթոդ http: POST.
Հարցման օրինակ.
SAP ծառայությունը վերահսկում է ամբողջականության, ներկայիս SAP կառուցվածքի հետ համապատասխանության և պահանջվող աղյուսակին մուտքի թույլտվության առկայության հարցումը:
Սխալների դեպքում ծառայությունը պատասխան է տալիս համապատասխան ծածկագրով և նկարագրությամբ։ Եթե վերահսկումը հաջող է, այն ստեղծում է ֆոնային գործընթաց՝ նմուշ ստեղծելու համար, ստեղծում և համաժամանակյա վերադարձնում է եզակի նստաշրջանի id:
Սխալի դեպքում արտաքին համակարգը այն գրանցում է գրանցամատյանում։ Հաջող պատասխանի դեպքում այն փոխանցում է նիստի id-ը և աղյուսակի անվանումը, որի վերաբերյալ հարցումն արվել է:
Արտաքին համակարգը գրանցում է ընթացիկ նիստը որպես բաց: Եթե այս աղյուսակի համար այլ նիստեր կան, դրանք փակվում են գրանցված նախազգուշացմամբ:
SAP ֆոնային աշխատանքը ստեղծում է կուրսոր՝ հիմնված նշված պարամետրերի և նշված չափի տվյալների փաթեթի վրա: Փաթեթի չափը գրառումների առավելագույն քանակն է, որը գործընթացը կարդում է տվյալների բազայից: Լռելյայնորեն ենթադրվում է, որ այն հավասար է 2000-ի: Եթե տվյալների բազայի նմուշում ավելի շատ գրառումներ կան, քան օգտագործված փաթեթի չափը, ապա առաջին փաթեթը փոխանցելուց հետո հաջորդ բլոկը ձևավորվում է համապատասխան օֆսեթով և ավելացված փաթեթի համարով: Թվերը ավելացվում են 1-ով և ուղարկվում խիստ հաջորդականությամբ:
Հաջորդը, SAP-ը փոխանցում է փաթեթը որպես մուտքագրում արտաքին համակարգի վեբ ծառայությանը: Եվ համակարգը վերահսկում է մուտքային փաթեթը: Ստացված id-ով նիստը պետք է գրանցվի համակարգում և այն լինի բաց կարգավիճակում։ Եթե փաթեթի համարը > 1, համակարգը պետք է գրանցի նախորդ փաթեթի հաջող ստացումը (package_id-1):
Եթե վերահսկումը հաջող է, արտաքին համակարգը վերլուծում և պահպանում է աղյուսակի տվյալները:
Բացի այդ, եթե փաթեթում առկա է վերջնական դրոշը, և սերիականացումը հաջող է եղել, ինտեգրման մոդուլը ծանուցվում է նիստի մշակման հաջող ավարտի մասին և մոդուլը թարմացնում է նիստի կարգավիճակը:
Կառավարման/վերլուծության սխալի դեպքում սխալը գրանցվում է, և այս նստաշրջանի փաթեթները կմերժվեն արտաքին համակարգի կողմից:
Նմանապես, հակառակ դեպքում, երբ արտաքին համակարգը վերադարձնում է սխալ, այն գրանցվում է և փաթեթների փոխանցումը դադարում է:
SAP HСM-ի կողմից տվյալներ պահանջելու համար ներդրվել է ինտեգրացիոն ծառայություն: Ծառայությունն իրականացվում է ICF-ի շրջանակներում (SAP Internet Communication Framework - ) Այն թույլ է տալիս հարցումներ կատարել SAP HCM համակարգից՝ օգտագործելով հատուկ աղյուսակներ: Տվյալների հարցում ստեղծելիս հնարավոր է նշել կոնկրետ դաշտերի ցանկ և զտիչ պարամետրեր՝ անհրաժեշտ տվյալներ ստանալու համար: Միևնույն ժամանակ, ծառայության իրականացումը չի ենթադրում որևէ բիզնես տրամաբանություն։ Դելտայի հաշվարկման ալգորիթմները, հարցման պարամետրերը, ամբողջականության մոնիտորինգը և այլն նույնպես ներդրված են արտաքին համակարգի կողմից:
Այս մեխանիզմը թույլ է տալիս հավաքել և փոխանցել բոլոր անհրաժեշտ տվյալները մի քանի ժամում։ Այս արագությունը գտնվում է ընդունելի շեմին, ուստի մենք այս լուծումը համարում ենք ժամանակավոր, ինչը հնարավորություն է տվել լրացնել նախագծի վրա արդյունահանող գործիքի անհրաժեշտությունը:
Թիրախային նկարում տվյալների արդյունահանման խնդիրը լուծելու համար ուսումնասիրվում են CDC համակարգերի օգտագործման տարբերակները, ինչպիսիք են Oracle Golden Gate-ը կամ ETL գործիքները, ինչպիսիք են SAP DS-ը:
Source: www.habr.com