Kuten tiedät, SAP tarjoaa täyden valikoiman ohjelmistoja sekä tapahtumatietojen ylläpitoon että näiden tietojen käsittelyyn analyysi- ja raportointijärjestelmissä. Erityisesti SAP Business Warehouse (SAP BW) -alusta on työkalupakki tietojen tallentamiseen ja analysointiin, jossa on laajat tekniset ominaisuudet. Kaikista objektiivisista eduistaan huolimatta SAP BW -järjestelmällä on yksi merkittävä haittapuoli. Tämä on korkea datan tallennuksen ja käsittelyn hinta, joka on erityisen havaittavissa käytettäessä pilvipohjaista SAP BW:tä Hanassa.
Entä jos aloitat jonkin muun kuin SAP:n ja mieluiten OpenSource-tuotteen käytön tallennustilana? Me X5 Retail Groupissa valitsimme GreenPlumin. Tämä tietysti ratkaisee kustannusongelman, mutta samalla ilmaantuu välittömästi ongelmia, jotka ratkesivat melkein oletusarvoisesti käytettäessä SAP BW:tä.
Erityisesti kuinka noutaa tietoja lähdejärjestelmistä, jotka ovat enimmäkseen SAP-ratkaisuja?
HR Metrics oli ensimmäinen projekti, jossa tämä ongelma piti ratkaista. Tavoitteenamme oli luoda HR-tiedon arkisto ja rakentaa analyyttistä raportointia työntekijöiden kanssa työskentelyn alueella. Tässä tapauksessa pääasiallinen tietolähde on SAP HCM -tapahtumajärjestelmä, jossa kaikki henkilöstö-, organisaatio- ja palkkatoiminnot suoritetaan.
Tietojen poiminta
SAP BW:ssä on vakiomuotoiset tiedonpoimijat SAP-järjestelmille. Nämä erottimet voivat automaattisesti kerätä tarvittavat tiedot, valvoa sen eheyttä ja määrittää muutosdeltoja. Tässä on esimerkiksi vakiotietolähde työntekijämääritteille 0EMPLOYEE_ATTR:
Tulos tietojen poimimisesta yhdelle työntekijälle:
Tarvittaessa tällainen poistolaite voidaan muokata omien tarpeidesi mukaiseksi tai luoda oma imuri.
Ensimmäinen ajatus, joka syntyi, oli mahdollisuus käyttää niitä uudelleen. Valitettavasti tämä osoittautui mahdottomaksi tehtäväksi. Suurin osa logiikasta on toteutettu SAP BW:n puolella, eikä lähdettä ole voitu kivuttomasti erottaa SAP BW:stä.
Kävi ilmi, että meidän on kehitettävä oma mekanismimme tietojen poimimiseksi SAP-järjestelmistä.
Tietojen tallennusrakenne SAP HCM:ssä
Ymmärtääksemme tällaisen mekanismin vaatimukset meidän on ensin määritettävä, mitä tietoja tarvitsemme.
Suurin osa SAP HCM:n tiedoista on tallennettu litteisiin SQL-taulukoihin. Näiden tietojen perusteella SAP-sovellukset visualisoivat käyttäjälle organisaatiorakenteet, työntekijät ja muut HR-tiedot. Esimerkiksi SAP HCM:n organisaatiorakenne näyttää tältä:
Fyysisesti tällainen puu on tallennettu kahteen taulukkoon - hrp1000-objekteihin ja hrp1001:een näiden objektien väliset yhteydet.
Objektit “Osasto 1” ja “Toimisto 1”:
Objektien välinen suhde:
Molempia kohteita ja niiden välisiä yhteyksiä voi olla valtava määrä. Objektien välillä on sekä vakioyhteyksiä että räätälöityjä yhteyksiä omiin tarpeisiisi. Esimerkiksi standardi B012-suhde organisaatioyksikön ja kokopäiväisen viran välillä tarkoittaa osaston johtajaa.
Esimiehen näyttö SAP:ssa:
Tallennus tietokantataulukkoon:
Työntekijätiedot tallennetaan pa*-taulukoihin. Esimerkiksi työntekijän henkilöstötapahtumien tiedot tallennetaan taulukkoon pa0000
Päätimme, että GreenPlum ottaa "raaka" datan, ts. kopioi ne SAP-taulukoista. Ja suoraan GreenPlumissa ne käsitellään ja muunnetaan fyysisiksi objekteiksi (esimerkiksi osastoksi tai työntekijäksi) ja mittareiksi (esimerkiksi keskimääräiseksi henkilöstömääräksi).
Taulukoita määriteltiin noin 70, joista tiedot on siirrettävä GreenPlumille. Sen jälkeen aloimme kehittää menetelmää näiden tietojen välittämiseksi.
SAP tarjoaa melko suuren määrän integrointimekanismeja. Mutta helpoin tapa on, että suora pääsy tietokantaan on kielletty lisenssirajoitusten vuoksi. Siten kaikki integraatiovirrat on toteutettava sovelluspalvelintasolla.
Seuraava ongelma oli tietojen puute poistetuista tietueista SAP-tietokannassa. Kun poistat rivin tietokannasta, se poistetaan fyysisesti. Nuo. muutosdeltan muodostaminen muutosajan perusteella ei ollut mahdollista.
Tietenkin SAP HCM:llä on mekanismeja tietojen muutosten tallentamiseen. Esimerkiksi myöhempää siirtoa varten vastaanottajajärjestelmiin on olemassa muutososoittimet, jotka tallentavat muutokset ja joiden perusteella muodostetaan Idoc (ulkoisiin järjestelmiin siirrettävä kohde).
Esimerkki IDoc-tietotyypin 0302 muuttamisesta työntekijälle, jonka henkilöstönumero on 1251445:
Tai tietojen muutoslokien pitäminen DBTABLOG-taulukossa.
Esimerkki lokista, jolla poistetaan tietue avaimella QK53216375 hrp1000-taulukosta:
Mutta nämä mekanismit eivät ole käytettävissä kaikille tarvittaville tiedoille, ja niiden käsittely sovelluspalvelintasolla voi kuluttaa melko paljon resursseja. Siksi kirjaamisen massiivinen salliminen kaikkiin tarvittaviin taulukoihin voi johtaa järjestelmän suorituskyvyn huomattavaan heikkenemiseen.
Seuraava suuri ongelma oli klusteroidut taulukot. Aika-arvio ja palkkatiedot SAP HCM:n RDBMS-versiossa tallennetaan loogisten taulukoiden joukkona jokaiselle työntekijälle jokaista laskelmaa varten. Nämä loogiset taulukot tallennetaan binääritietoina taulukkoon pcl2.
Palkanlaskentaklusteri:
Klusteroitujen taulukoiden tietoja ei voida pitää SQL-komentoina, vaan se edellyttää SAP HCM -makrojen tai erityisten toimintomoduulien käyttöä. Vastaavasti tällaisten taulukoiden lukunopeus on melko alhainen. Toisaalta tällaiset klusterit tallentavat tietoja, joita tarvitaan vain kerran kuukaudessa - lopullinen palkka- ja aikaarvio. Joten nopeus ei tässä tapauksessa ole niin kriittinen.
Arvioimme vaihtoehtoja datamuutosdeltan muodostamiseksi, joten päätimme harkita myös täydellistä purkamista. Mahdollisuus siirtää gigatavuja muuttumatonta dataa järjestelmien välillä päivittäin ei ehkä näytä hyvältä. Sillä on kuitenkin myös useita etuja - ei ole tarvetta sekä toteuttaa deltaa lähdepuolella että toteuttaa tämän deltan upottamista vastaanottimen puolelle. Vastaavasti kustannukset ja toteutusaika vähenevät ja integroinnin luotettavuus kasvaa. Samalla todettiin, että lähes kaikki muutokset SAP HR:ssä tapahtuvat kolmen kuukauden horisontissa ennen nykyistä päivämäärää. Näin ollen päätettiin valita päivittäinen täydellinen tietojen lataus SAP HR:stä N kuukautta ennen nykyistä päivämäärää ja kuukausittainen täysi lataus. N-parametri riippuu tietystä taulukosta
ja vaihtelee välillä 1-15.
Tietojen poimimiseen ehdotettiin seuraavaa järjestelmää:
Ulkoinen järjestelmä luo pyynnön ja lähettää sen SAP HCM:lle, jossa tämän pyynnön tietojen täydellisyys ja taulukoiden käyttöoikeudet tarkistetaan. Jos tarkistus onnistuu, SAP HCM suorittaa ohjelman, joka kerää tarvittavat tiedot ja siirtää ne Fuse-integraatioratkaisuun. Fuse määrittää Kafkassa tarvittavan aiheen ja siirtää tiedot sinne. Seuraavaksi Kafkan tiedot siirretään Stage Area GP:hen.
Tässä ketjussa olemme kiinnostuneita tietojen poimimisesta SAP HCM:stä. Katsotaanpa sitä tarkemmin.
SAP HCM-FUSE vuorovaikutuskaavio.
Ulkoinen järjestelmä määrittää viimeisen onnistuneen SAP-pyynnön ajan.
Prosessi voidaan käynnistää ajastimella tai muulla tapahtumalla, mukaan lukien aikakatkaisun asettaminen odottamaan vastausta SAP:n tiedoilla ja käynnistämään toistopyyntö. Sitten se luo delta-pyynnön ja lähettää sen SAP:lle.
Pyyntötiedot lähetetään rungolle json-muodossa.
Tapa http: POST.
Esimerkkipyyntö:
SAP-palvelu valvoo pyynnön täydellisyyttä, nykyisen SAP-rakenteen noudattamista ja pyydetyn taulukon käyttöoikeuksien saatavuutta.
Virhetilanteissa palvelu palauttaa vastauksen asianmukaisella koodilla ja kuvauksella. Jos ohjaus onnistuu, se luo taustaprosessin näytteen luomiseksi, luo ja palauttaa synkronisesti yksilöllisen istuntotunnuksen.
Virheen sattuessa ulkoinen järjestelmä kirjaa sen lokiin. Jos vastaus on onnistunut, se lähettää istuntotunnuksen ja sen taulukon nimen, jota varten pyyntö tehtiin.
Ulkoinen järjestelmä rekisteröi nykyisen istunnon avoimeksi. Jos tälle taulukolle on muita istuntoja, ne suljetaan varoituksella.
SAP-taustatyö luo kohdistimen määritettyjen parametrien ja määritetyn kokoisen datapaketin perusteella. Eräkoko on tietueiden enimmäismäärä, jonka prosessi lukee tietokannasta. Oletuksena sen oletetaan olevan 2000. Jos tietokantanäytteessä on enemmän tietueita kuin käytetty pakettikoko, ensimmäisen paketin lähettämisen jälkeen muodostetaan seuraava lohko vastaavalla siirtymällä ja lisätyllä pakettinumerolla. Numeroita kasvatetaan yhdellä ja lähetetään tiukasti peräkkäin.
Seuraavaksi SAP välittää paketin syötteenä ulkoisen järjestelmän verkkopalveluun. Ja järjestelmä valvoo saapuvaa pakettia. Istunto vastaanotetulla tunnuksella on rekisteröitävä järjestelmään ja sen on oltava avoimessa tilassa. Jos paketin numero > 1, järjestelmän tulee kirjata edellisen paketin onnistunut vastaanottaminen (paketin_tunnus-1).
Jos ohjaus onnistuu, ulkoinen järjestelmä jäsentää ja tallentaa taulukkotiedot.
Lisäksi, jos viimeinen lippu on mukana paketissa ja sarjointi onnistui, integrointimoduuli saa ilmoituksen istunnon käsittelyn onnistuneesta loppuunsaattamisesta ja moduuli päivittää istunnon tilan.
Ohjaus-/jäsennysvirheen sattuessa virhe kirjataan lokiin ja ulkoinen järjestelmä hylkää tämän istunnon paketit.
Samoin päinvastaisessa tapauksessa, kun ulkoinen järjestelmä palauttaa virheen, se kirjataan lokiin ja pakettien lähetys pysähtyy.
Tietojen pyytämiseksi SAP HСM -puolella otettiin käyttöön integraatiopalvelu. Palvelu on toteutettu ICF-kehyksellä (SAP Internet Communication Framework - ). Sen avulla voit tiedustella tietoja SAP HCM -järjestelmästä tiettyjen taulukoiden avulla. Tietopyyntöä luotaessa on mahdollista määrittää luettelo tietyistä kentistä ja suodatusparametreista tarvittavien tietojen saamiseksi. Samaan aikaan palvelun käyttöönotto ei tarkoita liiketoimintalogiikkaa. Ulkoisen järjestelmän puolella on myös toteutettu algoritmeja delta-, kyselyparametrien, eheyden valvonnan jne. laskentaan.
Tämän mekanismin avulla voit kerätä ja lähettää kaikki tarvittavat tiedot muutamassa tunnissa. Tämä nopeus on hyväksyttävän partaalla, joten pidämme tätä ratkaisua väliaikaisena, joka mahdollisti poimintatyökalun tarpeen täyttämisen projektissa.
Kohdekuvassa tiedon poiminnan ongelman ratkaisemiseksi tutkitaan vaihtoehtoja käyttää CDC-järjestelmiä, kuten Oracle Golden Gate tai ETL-työkaluja, kuten SAP DS.
Lähde: will.com