SAP PI aloittelijoille

tavoite

tämän opetusohjelman tavoitteena on saada sinut ymmärtämään – mitä on SAP-Prosessiintegraatio? Emme mene asian ytimeen, vaan keskustelemme SAP PIN arkkitehtuurista ja eri piirteistä. Käsittelemme vain perusominaisuudet ja vältämme keskustelemasta kaikista ominaisuuksista tässä opetusohjelmassa.

Seuraavassa on joukko tapaustutkimuksia, jotka antavat sinulle käsityksen SAP PI: n toimialatasoisesta hyödyntämisestä. Kun aiheeseen tutustuu tarkemmin, niitä kannattaa yrittää ratkoa. Koetapaukset on laadittu siten, että se vie sinut alas oppiaineen yksinkertaisesta useampaan kompleksiin jokaisella oppitunnilla ja antaa sinulle kokonaiskuvan aiheesta.

mitä SAP ERP on?

minkä tahansa yrityksen – suuren tai pienen yrityksen-vakiotoiminnot, kuten materiaalihallinta, myynti ja jakelu, rahoitus, henkilöresurssit jne. Markkinoilla on paljon ohjelmistoja, joita teollisuus hyödyntää. Huomaat yksinkertaisin-pankkivirkailija kone tuottaa myyntilaskun, jos käyt pieni kauppa verkon tietokoneiden suuri vähittäiskauppa, hotelli jne toimivat ERP.

toiminnanohjaus eli toiminnanohjaus on tehokas lähestymistapa, jota useimmat yritykset toteuttavat tuottavuuden ja suorituskyvyn parantamiseksi. SAP ERP on SAP AG: n toiminnanohjausjärjestelmä, integroitu ohjelmistoratkaisu, joka sisältää organisaation Keskeiset liiketoiminnot. Perustoimintoja kuten HR, MM, SD, FICO jne. kutsutaan SAP: ssa liiketoimintamoduuleiksi. SAP valmistaa niitä tuotteina ja myy niitä markkinoilla. On vielä kaksi moduulia, jotka eivät suoraan tue yritystoimintoja, mutta joita hyödynnetään esittämiseen ja integraatioon. Edellistä kutsutaan EP: ksi (Enterprise Portal) ja jälkimmäistä PI: ksi (Process Integration). Kaikki liiketoimintamoduulit on kehitetty ABAPISSA, kun taas EP ja PI on kehitetty enimmäkseen Javalla. Nämä moduulit eivät ole suoritettavia, mutta ne on otettava käyttöön sovelluspalvelimessa eli ABAP-web-sovelluspalvelimessa ABAP-moduuleille ja Java-Web-sovelluspalvelimissa Java-moduuleille.

on muutamia kohtia, jotka meidän pitäisi tietää ennen kuin hyppäämme aiheeseen.

• SAP tarkoittaa tietojenkäsittelyn järjestelmiä, sovelluksia ja tuotteita.

• SAP AG on saksalainen monikansallinen ohjelmistoyritys, joka valmistaa yritysohjelmistoja liiketoiminnan ja asiakassuhteiden hallintaan. SAP ERP on konsernin toiminnanohjausjärjestelmä, integroitu ohjelmistoratkaisu, joka sisältää organisaation Keskeiset liiketoiminnot.

• SAP NetWeaver Process Integration (SAP PI) on SAP enterprise application integration (EAI) – ohjelmisto, joka on osa NetWeaver-tuoteryhmää ja jota käytetään helpottamaan tiedonvaihtoa yrityksen sisäisten ohjelmistojen ja järjestelmien sekä ulkoisten osapuolten välillä.

Legacy System

SAP: n ERP: tä toteutettaessa suuressa liikelaitoksessa on havaittu, että kaikkia osia ei voida ottaa SAP: n ERP: n piiriin. Monilla liiketoimintaosastoilla voi olla omia, erittäin monimutkaisia työvälineitä, joita ei välttämättä ole mahdollista korvata. Ne kulkevat rinnakkain SAP-järjestelmän kanssa. Niitä kutsutaan Perintöjärjestelmiksi. Tämän jälkeen on välttämätöntä integroida SAP-järjestelmät ja tällainen olemassa oleva muu kuin SAP-järjestelmä. Tässä SAP PI astuu kuvaan.

miksi tarvitsemme SAP PI vanhojen järjestelmien lisäksi SAP ERP ei suuressa liikelaitoksessa koostu yhdestä ainoasta järjestelmästä vaan useista integroiduista järjestelmistä, kuten CRM, SRM ja FICO jne. Tällaisten monimutkaisten ongelmien käsittelemiseksi SAP otti käyttöön prosessin Integrointialustan, joka tarjoaa yhden integrointipisteen kaikille järjestelmille koskematta olemassa oleviin monimutkaisiin vanhojen järjestelmien verkostoihin. Tämä on SAP: n tehokas väliohjelmisto, joka tarjoaa saumattoman päästä päähän-integroinnin SAP: n ja muiden kuin SAP: n sovellusten välillä yritysrajan sisällä ja ulkopuolella. SAP PI tukee B2B-ja A2A-vaihtoja, tukee synkronista ja asynkronista viestinvaihtoa ja sisältää sisäänrakennetun Moottorin integraatioprosessien suunnittelua ja toteuttamista varten.

SAP PI: n arkkitehtuuri

SAP PI koostuu napa-ja puolarakenteesta; puolat liittyvät ulkoisiin järjestelmiin ja napa vaihtaa viestejä niiden välillä. Lähdejärjestelmää kutsutaan lähettäjäjärjestelmäksi ja kohdejärjestelmää vastaanottajajärjestelmäksi. PI ei ole yksittäinen komponentti, vaan kokoelma komponentteja, jotka toimivat joustavasti yhdessä integraatioskenaarioiden toteuttamiseksi. Arkkitehtuuri sisältää komponentteja, joita käytetään suunnitteluaikana, konfigurointiaikana ja suoritusaikana.

voimme jakaa SAP PI: n useisiin alueisiin

1. Integraatiopalvelin
2. Integraatiopalvelin
3. Järjestelmämaisema
4. konfigurointi ja valvonta

Integraatiopalvelin on SAP PI: n keskeinen prosessointimoottori. Kaikki viestit käsitellään täällä johdonmukaisesti. Se koostuu kolmesta erillisestä moottorista

1. Integraatiomoottori
2. Adapterimoottori
3. Liiketoimintaprosessimoottori

integraatiomoottoria voidaan pitää napana ja Adapterimoottoria puolana. Liiketoimintaprosessin moottorin osalta selitän sen myöhemmin.

Integration Builder on asiakas-palvelin-kehys integraatioobjektien käyttöön ja muokkaamiseen ja se koostuu kahdesta toisiinsa liittyvästä työkalusta:

1. Enterprise Service Repository – suunnitella ja kehittää objekteja, joita käytetään skenaarioissa
2. Integraatiohakemisto – määrittää ESR-objektit kehittämään skenaarioita

kaksi yhdessä rakensimme integraatioprosesseja, joita kutsutaan yleisesti skenaarioiksi.

Järjestelmämaisema on keskitetty tietovarasto ohjelmistoista ja järjestelmistä datakeskuksessa ja yksinkertaistaa järjestelmämaiseman hallintaa.

konfiguroinnissa ja seurannassa voimme seurata viestejä ja sovittimia.

Single stack ja Dual stack

kun PI julkaistiin ensimmäisen kerran, kaikkia komponentteja ei rakennettu samalle alustalle. Integration Engine ja Business Process Engine rakennettiin ABAP: iin, kun taas Adapter Engine, Integration Builder, SL, CM ja Mapping Runtime rakennettiin Java: iin. PI tarvitsee siis sekä Java-että ABAP-ympäristön toimiakseen ja sitä kutsutaan kaksoispinoksi.

ABAP Stack	Java-Pino
Integraatiomoottori Liiketoimintaprosessimoottori Integraatiomoottori	Enterprise Service Repository Integraatiohakemisto Runtime Workbench System Landscape Directory Adapter Engine Mapping Runtime

mutta myöhemmässä versiossa kaikki komponentit on rakennettu Java. Jotkut dual-stack komponentit ovat joko annostellaan pois tai muutettu toimimaan Java pino. PI tarvitsee siis vain Java-ympäristön toimiakseen ja sitä kutsutaan yksittäiseksi pinoksi.

näiden kahden pinon välissä on hyviä ja huonoja puolia, mutta niitä ei tässä opetusohjelmassa käsitellä.

Integraatiomoottori

Integraatiomoottori vastaa keskitetyistä Integraatiopalvelimista eli putkilinjan vaiheista-reitityksestä ja kartoituksesta. Jos lähdesanoman rakenne on erilainen kuin kohdesanoman rakenne, integrointimoottori kutsuu Kartoitusajoajan, jossa lähderakenne muunnetaan kohderakenteeksi. Kartoitusajo perustuu Java-pinoon. Integraatiomoottori voi hyödyntää muuntamisessa myös ABAP-ohjelmaa, joka perustuu ABAP-pinoon.

viesti voi olla kaksityyppinen

1. synkroninen – on sekä pyynnön vastausosa
2. asynkroninen-on joko pyyntö tai vastausosa vain

Pi: ssä viesti edustaa rajapintaa.

liitäntä -> viestin rakenne XML – muodossa + suunta

edellä mainittujen kriteerien perusteella on olemassa kolmenlaisia liitäntöjä

1. lähtevä liitäntä – yhteyden lähettäjäjärjestelmään
2. saapuva liitäntä – yhteyden vastaanottimeen
3. Abstrakti liitäntä-yhteyden vastaanottimeen

kun määrittelemme integrointilogiikan (skenaarion) SAP PI: ssä liiketoimintavaatimustemme mukaisesti, integrointimoottori toteuttaa kyseisen kokoonpanon vaiheittain. Pipeline on termi, jolla tarkoitetaan kaikkia vaiheita, jotka suoritetaan XML-sanoman käsittelyn aikana. Putkilinjan vaiheet koostuvat seuraavista:

1. vastaanottajan tunnistus-määrittää järjestelmän, joka osallistuu viestin vaihtoon.
2. Interface Determination – determine which interface will should receive the message.
3. Message Split – jos useampi kuin yksi vastaanottaja löytyy, PI lähettää uuden viestin jokaiselle vastaanottajalle.
4. Message Mapping – mapping, jolla lähdeviesti muutetaan kohdeviesti-muotoon.
5. tekninen reititys – sido viestiin tietty kohde ja protokolla.
6. Soita adapterille-lähetä muutettu viesti adapterille tai välityspalvelimelle.

Adapter Engine

sinun on täytynyt huomata aiemmin, että integraatiomoottori käsittelee viestejä vain XML-SOAP-protokollassa. Mutta entä jos meillä on lähettäjän ja vastaanottajan liiketoimintajärjestelmä, jossa tiedot eivät ole samassa muodossa. Käytämme Adapterimoottorin eri sovittimia XML – ja HTTP-pohjaisten viestien muuntamiseen näiden järjestelmien vaatimaan protokollaan ja muotoon ja päinvastoin.

kuten olemme aiemmin käsitelleet, SAP PI on napa ja puhui rakenne, jossa sovitin Moottori voidaan pitää puhui. Käytämme Adapterimoottoria Integrointimoottorin (Hub) liittämiseen ulkoisiin järjestelmiin. Adapter Framework on Adapterimoottorin perusta. Adapterikehys perustuu SAP J2EE-moottoriin (osana SAP-Verkkosovelluspalvelinta) ja J2EE Connector Architecture-järjestelmään (JCA). Adapter Framework tarjoaa rajapinnat sovittimien konfigurointiin, hallintaan ja seurantaan.

dual stack-järjestelmässä suurin osa Adaptereista, joissa perustuu Java-pinoon, ilman kahta ABAP-pinoon perustuvaa adapteria.

Java-Pino	RFC-sovitin, SAP Business Connector adapter, file / FTP-sovitin, JDBC-sovitin, JMS-sovitin, SOAP-sovitin, Marketplace-sovitin, Sähköpostisovitin, Rnif-sovitin, CIDX-sovitin
ABAP stack	IDOC-sovitin ja HTTP-sovitin

kun SAP PI siirtyi dual pinosta yhteen pinoon, nämä kaksi adapteria tulivat osaksi Java-pinoa. Modifioitu adapterimoottori tunnetaan Advance Adapter Engine ja kaksi adapteria kutsutaan IDOC_AAE adapter ja HTTP_AAE adapter vastaavasti.

Business Process Engine

Liiketoimintaprosessimoottori vastaa integraatioprosessien toteuttamisesta ja jatkumisesta.

BPM tulee sanoista cross-component Business Process Management tai ccBPM, ja sitä kutsutaan myös Integraatioprosessiksi. Integraatioprosessi on suoritettava, järjestelmien välinen prosessi viestien käsittelemiseksi. Integraatioprosessissa määritellään kaikki suoritettavat prosessin vaiheet ja prosessin ohjaamisen kannalta merkitykselliset parametrit. Liiketoimintaprosessien hallinta tarjoaa SAP Exchange-infrastruktuurille seuraavat toiminnot:

1. tila – Täydellinen viestien käsittely: integrointiprosessin tila säilyy Integraatiopalvelimella.
2. voit myös käyttää korrelaatioita viestien semanttisten suhteiden muodostamiseen.
3. otat käyttöön integraatioprosessit, kun haluat määritellä, hallita ja seurata monimutkaisia integraatioprosesseja, jotka ulottuvat yli yrityksen ja sovelluksen rajojen, kuten kerätä/yhdistää, jakaa, Multicast

suorituksen aikana, Liiketoimintaprosessimoottori suorittaa integrointiprosessit. Integraatioprosessi voi lähettää ja vastaanottaa viestejä vain abstrakteja rajapintoja käyttäen.

Rakenna skenaario SAP PI: ssä

aloitamme Kotisivulta, jos meidän on rakennettava skenaario PI: ssä.

kotisivu näyttää samanlaiselta kuin alla:

kuva 6-SAP PI Java Stackin Kotisivu

kotisivulla on hyperlinkit seuraaville 4 työalueelle

1. yrityspalvelujen arkisto (ESR)
2. Integraatiohakemisto (ID)
3. Järjestelmämaisema (SL)
4. konfigurointi ja seuranta (CM)

jokainen hyperlinkki avaa yhden sovelluksen. Kaikki nämä neljä ovat Java-sovellus. ESR ja ID ovat swing-sovelluksia. Ne käynnistetään selaimesta perustuen JNLP: hen. Joten ensimmäistä kertaa se vie enemmän aikaa, kun se lataa koko kirjastotiedoston. Toisesta kerrasta eteenpäin laukaisu vie kuitenkin vähemmän aikaa. SL ja CM ovat puhtaita verkkosovelluksia ja toimivat selaimella.

Enterprise Services Repository

täällä suunnittelemme ja luomme objekteja, joita käytetään integraatioskenaarion laatimisessa. PI: n tiedonkulku näyttää samanlaiselta kuin alla on esitetty:

löydämme vaihtoehdon suunnitella seuraavat

1. Käyttöliittymäobjektit – Palveluliittymä, viestityyppi, tietotyyppi
2. Kartoitusobjektit-Operaatiokartoitus ja Sanomakartoitus
3. integraatioprosessit

PI käyttää integraatiovarastoa sekä lähettäjä-että vastaanottajajärjestelmien viestirakenteen suunnitteluun ja liitäntäsanoman kehittämiseen käyttäen vastaavia viestirakenteita, jotka toimivat vuorovaikutuspisteenä ulkomaailmalle. Tietotyyppiä ja Sanomatyyppiä käytetään monimutkaisen käyttöliittymän suunnittelun yksinkertaistamiseen ja modularisointiin.

Operaatiokartoitus mahdollistaa lähderakenteen muuttamisen kohderakenteeksi, kun nämä kaksi rakennetta ovat erilaisia. Mutta jos lähde ja kohderakenne ovat samat, operaatiokartoitus voidaan poistaa. Palveluliittymän tavoin message mappingia käytetään yksinkertaistamaan ja modularisoimaan monimutkaisen operaatiokartoituksen suunnittelua. Message mapping voidaan toteuttaa 4 tavalla

1. graafinen Mapping
2. Java Mapping
3. XSLT Mapping
4. ABAP Mapping

graafinen mapping on käytetyin, koska sen avulla kehittäjä voi kartoittaa molempien rakenteiden attribuutteja graafisesti välittääkseen dataa palveluliittymien avulla. Kolmen muun kohdalla kartoitusta on kehitettävä kirjoittamalla koodia. Jos kyseessä on yksittäinen stack-palvelin, ABAP-kartoitus ei ole käytettävissä.

on myös muita alueita, mutta ne eivät kuulu tässä opetusohjelmassa.

Integraatiohakemisto

tässä tehdään putkilinjan vaiheet määrittämällä aiemmin luodut ESR-objektit. Integrointimoottori suorittaa nämä vaiheet ajon aikana.

ennen kokoonpanon aloittamista meidän on luotava/tuotava seuraavat objektit DIR: iin.

1. Service-Business System/ Business Service / Integration Process
2. Communication Channel

palvelu mahdollistaa viestien lähettäjän tai vastaanottajan puhuttelun. Riippuen siitä, miten haluat käyttää palvelua, voit valita seuraavista palvelutyypeistä.

1. yritysjärjestelmä – jos haluat käyttää tiettyä yritysjärjestelmää viestien lähettäjänä tai vastaanottajana, valitse tämä palvelutyyppi. Liiketoimintajärjestelmä on varsinainen sovellusjärjestelmä järjestelmämaisemassa.
2. Yrityspalvelu – jos haluat käsitellä abstraktia yritysyksikköä viestien lähettäjänä tai vastaanottajana, valitse tämä palvelutyyppi. Yrityspalvelua ei ole määritelty järjestelmämaisemassa.
3. integraatioprosessi – jos haluat käsitellä integraatioprosessia viestien lähettäjänä tai vastaanottajana, valitse tämä palvelutyyppi. Suorituksen aikana näitä integraatioprosesseja ohjataan viesteillä ja ne voivat itse lähettää viestejä.

viestintäkanava määrittää viestien saapuvan ja lähtevän käsittelyn. Viestit muunnetaan natiiviformaatista soap-xml-spesifiseen viestiformaattiin ja päinvastoin adapterin kautta. Yleensä skenaariossa

1. lähettäjän viestintäkanava
2. vastaanottajan viestintäkanava

palveluun on osoitettava viestintäkanava. Riippuen siitä, onko palvelu osoitettu viestien lähettäjänä vai vastaanottajana, määritetty viestintäkanava on joko lähettäjän tai vastaanottajan kanava, ja se on määritettävä sen mukaisesti. Et voi määrittää viestintäkanavaa integraatioprosessipalvelulle.

putkilinjan vaiheet luodaan luomalla seuraavat 4 konfiguraatiota DIR

löydämme seuraavat vaihtoehdot:

1. Lähettäjäsopimus
2. vastaanottajan määritys
3. rajapinnan määritys
4. vastaanottajan sopimus

lähettäjän sopimus määrittelee, miten lähettäjän viesti muunnetaan niin, että se voidaan käsitellä Integraatiopalvelimella. Se koostuu seuraavasta

1. lähettäjän osa
2. lähettäjän liittymä
3. lähettäjän viestintäkanava

lähettäjän sopimus on samanlainen kuin ensisijainen avain taulukossa. Samassa maisemassa ei voi olla kahta samanlaista lähettäjäsopimusta.

Vastaanottajasopimuksessa määritellään, miten Sanoma muunnetaan niin, että vastaanottaja voi käsitellä sen. Se koostuu

1. Lähettäjäkomponentti
2. vastaanottimen komponentti
3. vastaanottimen liitäntä
4. vastaanottimen viestintäkanava

käytät vastaanottimen määritystä määrittääksesi, mille vastaanottajalle Viesti lähetetään. Sinulla on mahdollisuus määritellä ehdot viestin välittämiseksi vastaanottajille. Se koostuu

1. Lähettäjäkomponentti
2. Lähettäjäkomponentti
3. Vastaanottajakomponentti

vastaanottimen määritys on kahdentyyppistä – vakio-tai laajennettua riippuen siitä, haluatko määrittää vastaanottimen manuaalisesti vai dynaamisesti kartoituksen avulla suorituksen aikana.

voit määrittää liittymämäärityksellä vastaanottimen saapuvan liittymän, johon viesti välitetään. Voit myös määrittää, minkä rajapinnan yhdistämistä Integrointivarastosta käytetään viestin käsittelyyn, ts. jos lähettäjän ja vastaanottajan rajapinta eivät ole samassa muodossa, on olemassa operatiivinen kartoitus formaatin muuttamiseksi. Määrittelet rajapinnan määrityksen lähettäjälle, lähtevälle rajapinnalle ja vastaanottimelle. Se koostuu

1. Lähettäjäkomponentti
2. Lähettäjäkomponentti
3. Vastaanottajakomponentti
4. vastaanottimen liitäntä

rajapinnan määritys on kahdentyyppistä – standardoitua tai parannettua riippuen siitä, haluatko määrittää vastaanottimen rajapinnan manuaalisesti vai kartoitukseen perustuvan viestijaon avulla.

vastaanottimen määritys ja rajapinnan määritys – nämä kaksi yhdessä tunnetaan yleisesti loogisena reitityksenä. Lähettäjäsopimus ja Vastaanottajasopimus – nämä kaksi yhdessä tunnetaan yleisesti Yhteistyösopimuksena.

Järjestelmämaisema

SAP System Landscape Directory (SLD) on järjestelmämaiseman keskeinen tiedontuottaja. Verkkosivuilta löydät seuraavat linkit:

1. tekninen järjestelmä-tekniset järjestelmät ovat sovellusjärjestelmiä, jotka on asennettu järjestelmän maisema.
2. liikejärjestelmä – Liikejärjestelmät ovat loogisia järjestelmiä, jotka toimivat lähettäjinä tai vastaanottajina PI: ssä. Liiketoimintajärjestelmät ovat yksi yhteen-riippuvuussuhteessa siihen liittyvään tekniseen järjestelmään.
3. tuotteet ja komponentit-tämä on tieto kaikista saatavilla olevista SAP-tuotteista ja-komponenteista, mukaan lukien niiden versiot. Jos järjestelmäympäristössä on kolmannen osapuolen tuotteita, ne rekisteröidään myös täällä.

nopeudenrajoitin näyttää samanlaiselta kuin alla:

Kuva 11 – järjestelmän maisema

tuotteita ja komponentteja kutsutaan yleisesti Komponenttitiedoiksi

teknistä järjestelmää ja liiketoimintajärjestelmää kutsutaan yleisesti maiseman kuvaukseksi.

liiketoimintajärjestelmä voidaan konfiguroida Integraatiopalvelimeksi tai Sovellusjärjestelmäksi.

1. Integraatiopalvelin-Integraatiopalvelin suorittaa vain integraation rakentajassa määritetyn integraatiologiikan. Ne voidaan tunnistaa myös putkilinjan portaiksi. Se vastaanottaa XML-viestin, määrittää vastaanottimen, suorittaa kuvaukset ja reitittää XML-viestin vastaaviin vastaanottinjärjestelmiin. Näin konfiguroitu Integraatiomoottori tunnistetaan keskeiseksi Konfiguroiduksi Integraatiomoottoriksi.
2. Application system – sovellusjärjestelmä ei toteuta integraatiologiikkaa. Se puolestaan kutsuu integraatiopalvelimen suorittamaan integrointilogiikan tarvittaessa. Se toimii XML-viestien lähettäjänä tai vastaanottajana. Paikallisen Integraatiomoottorin sisältävä sovellusjärjestelmä vaatii Integraatiopalvelinta suorittamaan integraatiologiikan.

vain yksi SAP-järjestelmän asiakas voidaan määrittää Integraatiopalvelimeksi.

seuraavat tiedot poimitaan NOPEUDENRAJOITTIMESTA ESR: ään ja DIR

1. komponenttitietoja käytetään ESR: ssä Tuotteen määrittelyyn ja SWCV
2. Yritysjärjestelmää käytetään hakemistossa viestien lähettäjän ja vastaanottajan määrittelyyn

kokoonpano ja valvonta

se on seurantatarkoituksissa keskitetty vastaanottopiste. Tämä antaa sinulle mahdollisuuden siirtyä Integraatiomoottorin valvontatoimintoihin sekä integraatioon Computing Center Management Systemin (CCMS) ja SAP: n Prosessinvalvontainfrastruktuurin (PMI) kanssa.

kokoonpano ja seuranta näyttävät samanlaisilta kuin alla:

kuva 13-konfigurointi ja valvonta

konfigurointi ja seuranta tukevat seuraavia valvontatoimintoja:

1. Component monitoring-seuranta eri SAP PI komponentit (Java ja ABAP osat).
2. Message monitoring – tracking the message processing status within a SAP PI component and on error detection and analysis.
3. End-to-end monitoring – viestin elinkaaren seuranta SAP PI: n näkökulmasta.
4. suorituskyvyn seuranta – SAP PI: n eri suorituskykynäkökohtia koskevat tilastot ovat saatavilla RWB: n kautta. Tässä voit valita ja koota suorituskykytiedot esimerkiksi komponentin, aikajänteen tai viestin attribuuttien mukaan.
5. Indeksinhallinta – hallinnoimalla ja valvomalla SAP PI-komponenttia kohti tapahtuvaa viestien indeksointia otat käyttöön indeksipohjaisen viestihaun, jota voit käyttää viestien seurannassa. Tällainen viestihaku tarjoaa sinulle parannetut valintakriteerit, mukaan lukien sovittimen mukaiset viestiattribuutit ja termit tai lauseet viestin hyötykuormasta.
6. Alert configuration – Alert Framework-järjestelmän avulla PI: n keskitetty valvonta voidaan toimittaa kaikkien ABAP: n ja Javan viestien käsittelyn aikana raportoitujen virheiden osalta. Tämä mahdollistaa paremman reagoinnin tällaisiin virheisiin sekä ABAP runtime että Java-pohjainen Adapter Engine. Tätä varten Varoituskehyksessä on säännöt, jotka perustuvat tiettyihin tapahtumiin ja PI-viestiprotokollan otsikosta saatuihin tietoihin. Näissä säännöissä määritellään, lähetetäänkö kuulutuksia vai ei. Jos hälytys lähetetään, sitä voidaan käyttää virheanalyysiin.
7. Alert inbox – saapuneet-Saapuneet-kansio on käyttäjäkohtainen ja näyttää kaikki jokaisen hälytyspalvelimen hälytykset, jotka on luotu hälytyskokoonpanon perusteella.
8. Cache monitoring – cache monitoring näyttää kohteet, jotka ovat tällä hetkellä runtime-välimuistissa. Eri välimuistiobjekteja seurataan riippuen kyseessä olevasta välimuistiesiintymästä.

synkroninen vs. asynkroninen viestintä

prosessi voidaan määritellä joko synkroniseksi tai asynkroniseksi.

• synkroninen prosessi käynnistetään pyyntö/vastausoperaatiolla, ja prosessin tulos palautetaan soittajalle välittömästi tämän toiminnon kautta.
• asynkroninen prosessi kutsutaan yksisuuntaisella toiminnalla ja tulos ja mahdolliset viat palautetaan vetoamalla muihin yksisuuntaisiin operaatioihin. Tulos palautetaan soittajalle takaisinsoittooperaation kautta.

tietokonemaailmassa ei ole asynkronista viestintää. Kaikki viestintä kahden järjestelmän välillä tapahtuu aina menetelmäkutsun (pyyntö/vastausoperaatio) kautta. Miten teemme siitä asynkronisen? Vastaus löytyy kolmannen järjestelmän käyttöönotosta kutsutun ja soittajan toiminnon väliin.

Oletetaan, että on olemassa kaksi järjestelmää – A ja B. Kaikki viestintä A: n ja B: n välillä tapahtuu menetelmäkutsun kautta ja siten ne ovat synkronisia. Otamme käyttöön kolmannen järjestelmän A: n ja B: n välille ja kutsumme sitä väli – I: ksi.A: n ja I: n välinen kommunikaatio tapahtuu menetelmäkutsun kautta ja vastaavasti I: n ja B: n välinen kommunikaatio tapahtuu myös menetelmäkutsun kautta. A: n ja B: n välistä viestintää voidaan kuitenkin kutsua asynkroniseksi, sillä A: n ei tarvitse odottaa vastausta B: ltä

tämä on asynkronisen viestinnän perusta ja mikä tämä välijärjestelmä on? Tuo on jono. A: ta kutsutaan lähettäjäksi ja B: tä vastaanottajaksi. Viesti A: sta lisätään ensin jonoon ja sitten se vedetään uudelleen jonosta ja lähetetään B: lle.vastaus B: stä saavuttaa A: n samalla tavalla. Tietyissä tilanteissa liiketoimintavaatimus edellyttää, että viestit toimitetaan B: lle samassa järjestyksessä kuin ne laukaistaan A: sta.tällöin noudatamme first-in-ja first-out-käytäntöä. Jos tällaisia vaatimuksia ei ole, viestit lähetetään jonosta B: hen missä tahansa järjestyksessä.

asynkronisella viestillä saavutetaan taattu toimitus eli järjestelmä B ei ole käytettävissä, kun järjestelmä a lähettää viestin. Viesti lisätään jonoon ja pysyy siellä niin kauan kuin B ei ole saatavilla. Kun B on saatavilla, viesti vedetään jonosta ja lähetetään B: lle

, jotta voimme luokitella viestimme kolmella tavalla:

1. synkroniset
2. asynkroniset, joissa järjestys ei säily
3. asynkroniset, joissa järjestys säilyy

In PI, tunnistamme ne seuraavasti: synkroniset – BE (paras Ponnistus), asynkroniset, joissa järjestystä ei pidetä – EO (täsmälleen kerran), asynkroniset, joissa järjestys säilyy – EOIO (täsmälleen kerran järjestyksessä).

kuittaus

kuittaus on asynkronisen viestinnän perusta. Miksi?

synkronisessa viestinnässä järjestelmä a kutsuu järjestelmää B ja jos B ei lähetä vastausta, prosessi epäonnistui. Mutta asynkronisessa viestinnässä järjestelmä a kutsuu järjestelmää I ja Järjestelmä I kutsuu järjestelmää B. oletetaan siis, että viestintä A: n ja I: n välillä onnistuu, mutta I: n ja B: n välillä se epäonnistuu. Miten A: n pitäisi ymmärtää, että toimitus B: lle on epäonnistunut? Tämä toteutuu kuittauksella, joka lähetetään takaisin A: han B: n kautta samaa reittiä kuin viesti A: sta vei B: hen. Jos B: n kuittaus ei saavu A: han, a katsoo, että prosessi on epäonnistunut ja lähettää viestin uudelleen.

kun keskustelimme asynkronisesta viestinnästä PI: ssä, olemme käyttäneet termiä – ”täsmälleen kerran” sekä EO: sta että EOIO: sta. Täsmälleen kerran tarkoittaa, että kerran toimitettua viestiä ei voida toimittaa uudelleen. Tämän saavuttamiseksi on olemassa kuittaus jokaisesta viestistä, joka lähetetään A: sta B: hen.sovittimet ovat viestin lopussa. Sovittimien on siis tuettava kuittausta.

All adapters ” provide system-notification i.e. toimituksen kuittaus. Ne sovittimet, jotka tukevat synkronista viestintää, tukevat järjestelmän vahvistamisen lisäksi sovellus-kuittausta.

joten PI: ssä on seuraava kuittaustyyppi

1. järjestelmän kuittaus – järjestelmän kuittaukset, joita runtime-ympäristö käyttää vahvistaakseen, että asynkroninen viesti on saapunut vastaanottimeen.
2. Sovellusvahvistukset – Sovellusvahvistukset, joita käytetään vahvistamaan, että asynkroninen viesti on onnistuneesti käsitelty vastaanottimessa.

Etätoimintapuhelu

PI: ssä työskennellessäsi törmäät termiin – RFC. Mitä ne ovat? Luodaksemme yhteyden kahden SAP-järjestelmän eli R/3: n ja PI: n välille luomme RFC-kohteen. Sen konfiguraatio on seuraava

1. yhteystyyppi
2. IP-osoite ja vastaanottimen portti

yhteystyyppi kertoo Järjestelmäyhteyden tyypin eli R/3, TCP/IP, sisäinen jne.

luomamme RFC-kohde on luokiteltu tarvittavan viestintämuodon mukaan, ts. onko sen tuettava synkronista vai asynkronista viestintää.

1. synkronisessa viestinnässä – synkronisessa RFC: ssä
2. asynkronisessa viestinnässä, jossa järjestystä ei ylläpidetä – transaktiossa RFC
3. asynkronisessa viestinnässä, jossa järjestystä ylläpidetään – jonossa olevassa RFC: ssä

ne yksilöidään sRFC: llä, tRFC: llä ja qRFC: llä.

tapaustutkimukset – 1

Oletetaan, että olet luokkahuoneessa ja siinä on 10 oppilasta. Opettaja pyytää jokaista oppilasta valmistelemaan seuraavat henkilötiedot ja tallentamaan ne XML-tiedostoon. Yksityiskohdat ovat seuraavat:

1. Opiskelijatunnus
2. nimi
3. mobiili
4. Sähköposti
5. sukupuoli

on 10 tiedostoa ja tiedostot on nimetty cv_1,2,3….10. Tiedostot tallennetaan lähdehakemistoon. Testaustarkoituksiin luodaan seuraavat hakemistot:

Lähdehakemisto: c:\ibm\sap\training\input

Arkistohakemisto: c:\ibm\sap\training\archive

Virhehakemisto: c:\ibm\sap\training\error

Target directory: c:\ibm\sap\training\target

sinua pyydetään kehittämään SAP PI: ssä skenaarioita, jotka lukevat lähdehakemistosta lähdetiedostot ja kirjoittavat ne kohdehakemistoon. Kun tiedosto on onnistuneesti luettu lähdehakemistosta, se tulee siirtää arkistohakemistoon ja jos tiedostoa ei voida lukea jonkin virheen vuoksi eli xml-muodossa, jota ei ylläpidetä, se tulee siirtää virhehakemistoon. Arkisto -, virhe-tai kohdehakemistoon siirretyissä tiedostoissa tulee olla aikaleima tiedostonimen liitteenä.

1. ts. tiedostonimi + <aikaleima>.

Oppitunti-1

valmista skenaario, jossa luetaan yksi yksittäinen tiedosto eli tiedosto cv_1.xml lähdehakemistosta ja kirjoita se kohdehakemistoon. Kohdetiedoston nimen tulisi olla myös cv_1.xml, jossa nimeen liitetään aikaleima.

Lesson-2

valmistele skenaario, jolla voit lukea kaikki lähdehakemiston tiedostot ja kirjoittaa ne kohdehakemistoon. Vastaavasti kohdetiedostot pitäisi myös nimetä cv_1, 2: ksi ..xml ja aikaleima liitetään jokaiseen niistä.

Oppitunti-3

opettaja pyytää teitä kaikkia lisäämään seuraavan validoinnin tietoihin.

1. matkapuhelinnumerossa tulee olla 10 numeerista numeroa – Jos matkapuhelinnumero ei ole 10-numeroinen, korvataan se sanoilla ”virhe”
2. sähköpostissa tulee olla yksi ” @ ”- merkki ja yksi”.’merkki – jos sähköpostissa ei ole ’@’ tai ’.’merkki, sitten korvata se ’virhe’

ennen kuin suoritat skenaarion, joissakin lähdetiedostot, muokata mobiili ja sähköposti niin, että ne ovat virhe kohti logiikka edellä.

Oppitunti-4

Laadi skenaario, jossa kaikki lähdetiedostot luetaan ja ne luokitellaan niiden sukupuolen mukaan. Miesten tiedostot kirjoitetaan yhteen hakemistoon ja naisten toiseen hakemistoon. Edellä mainittua tarkoitusta varten luodaan kaksi hakemistoa:

kohdehakemisto miehille: c:\ibm\sap\training\target\men

Naisten Tavoitehakemisto: c:\ibm\sap\training\target \ women

Oletetaan, että luokassa on 6 miestä ja 4 naista, niin jos kaikki lähdetiedostot luetaan onnistuneesti, miesten kohdehakemistossa pitäisi olla 6 tiedostoa ja naisten kohdehakemistossa 4 tiedostoa.

tapaustutkimukset-2

opettaja pyytää teitä kaikkia laatimaan yhden tiedoston, jossa on kunkin oppilaan henkilötiedot erillisinä osioina.

Oppitunti-5

Kirjoita skenaario, joka lukee tämän tiedoston ja tuottaa 10 kohdetiedostoa, joissa jokaisen tiedoston pitäisi vastata kunkin työntekijän henkilötietoja. Kohdetiedostot tulee nimetä cv_<emp_ID>_<aikaleima>

Oppitunti-6

muokkaa yllä olevaa skenaariota siten, että se tuottaa 2 kohdetiedostoa 10: n sijasta, jossa yksi kohdetiedosto miehille ja toinen kohdetiedosto naisille. Miesten kohdetiedostossa pitäisi olla 6 segmenttiä 6 miehelle ja naisten kohdetiedostossa 4 segmenttiä 4 naiselle.

kohdetiedostot tulee nimetä seuraavasti:

miehet-men_<aikaleima>

naiset-naiset_<aikaleima>

tapaustutkimus -3

sama kuin tapaustutkimus – 1, opettaja pyytää jokaista oppilasta valmistelemaan henkilökohtaiset tiedot ja tallentaa ne XML-tiedoston. Kansioita tulee olemaan 10. Tiedostot tallennetaan lähdehakemistoon.

Oppitunti-7

valmista skenaario, jolla voit lukea kaikki lähdehakemiston lähdetiedostot ja luoda yhden tiedoston kohdehakemistoon. Kohdetiedoston nimi on output.XML, jonka aikaleima liitetään tiedoston nimeen. Kohdetiedosto on kaikki tiedot kunkin lähdetiedoston alisegmentti.

Oppitunti-8

valmista skenaario, jossa voit lukea lähdehakemistosta kaikki lähdetiedostot ja luoda kohdehakemistoon kaksi tiedostoa – toinen miehille ja toinen naisille. 6 miehet, miesten tiedoston pitäisi olla kuusi segmenttiä, joilla kunkin miehen Tiedot ja 4 naiset, samoin pitäisi olla 4 segmenttien kunkin naisen tiedot.

tapaustutkimus-4

opettaja pyytää nyt jokaista oppilasta laatimaan toiset yksityiskohdat, jotka koostuvat seuraavista akateemisista yksityiskohdista:

1. Opiskelijatunnus
2. koulun nimi
3. Collegen nimi
4. laitoksen nimi
5. Sisäänpääsyvuosi

tulee olemaan 10 tiedostoa ja tiedostot on nimetty ad_1, 2, 3….10. Tiedostot tallennetaan lähdehakemistoon. Joten jokaisella oppilaalla on nyt pari kansiota-yksi henkilökohtaisia tietoja ja toinen akateemisia yksityiskohtia varten. Kaksi tiedostoa liittyy Opiskelijatunnukseen. Tulohakemisto koostuu nyt 10 henkilökohtaisesta tiedostosta ja 10 akateemisesta tiedostosta.

Oppitunti-9

sinua pyydetään kehittämään skenaario, joka valitsee lähdetiedostot ja käsittelee ne pareittain. Skenaario tuottaa 10 kohdetiedostoa. Jokainen kohdetiedosto koostuu opiskelijan henkilökohtaisista ja akateemisista yksityiskohdista erillisinä segmentteinä. Kohdetiedostot nimetään res_1, 2, 10.

kohdetiedostot näyttävät:

Oppitunti-10

oppilastunnusta pyydetään muuttamaan joissakin tiedostoissa siten, että niissä ei ole vastaavia akateemisia tai henkilökohtaisia tiedostoja ja päinvastoin. Skenaarion pitäisi ajaa ja jos se löysi tiedostoja, joilla ei ole vastaavaa tiedostoa, prosessin pitäisi päättyä jonkin ajan kuluttua eli 2 min ja nämä tiedostot siirretään virhehakemistoon ja niille ei ole vastaavaa kohdetiedostoa.