SAP PI kezdőknek

célkitűzés

ennek az oktatóanyagnak az a célja, hogy megértse – mi az SAP Folyamatintegráció? Nem fogunk belemenni a téma apróságaiba, de megvitatjuk az SAP PI architektúráját és különböző jellemzőit. Csak az alapvető funkciókat fogjuk lefedni, és elkerüljük az oktatóanyag összes funkciójának megvitatását.

következő van egy sor esettanulmány, amely kapsz egy ötletet az ipari szintű hasznosítása SAP PI. Miután jobban megismerte a témát, meg kell próbálnia megoldani őket. A teszt esetek készülnek oly módon, hogy elviszi le a témát az egyszerű, hogy több komplex minden leckét, és kapsz egy átfogó képet a témában.

mi az SAP ERP?

minden nagy vagy kicsi vállalkozás esetében ezek a szokásos üzleti funkciók, amelyeket el kell végeznie, azaz Anyaggazdálkodás, értékesítés és forgalmazás, pénzügy, emberi erőforrások stb. Sok szoftver van a piacon, amelyet az ipar használ. Észre fogja venni, a legegyszerűbb – a bankjegykiadó gép generáló értékesítési számlát, ha meglátogat egy kis bolt, hogy a hálózat a számítógépek egy nagy kiskereskedelmi üzlet, hotel stb működő ERP.

a vállalati erőforrás-tervezés, azaz az ERP egy hatékony megközelítés, amelyet a legtöbb vállalkozás alkalmaz a termelékenység és a teljesítmény növelése érdekében. Az SAP ERP az SAP AG vállalati erőforrás-tervezése, egy integrált szoftvermegoldás, amely magában foglalja a szervezet legfontosabb üzleti funkcióit. Az alapvető funkciókat (HR, MM, SD, FICO stb.) üzleti moduloknak nevezzük az SAP-ban. Az SAP termékként gyártja és értékesíti őket a piacon. Két további modul van, amelyek nem támogatják közvetlenül az üzleti funkciókat, de a prezentációhoz és az integrációhoz használhatók. Az előbbit EP-nek (Enterprise Portal), az utóbbit PI-nek (Process Integration) hívják. Az összes üzleti modult az ABAP-ban fejlesztették ki, míg az EP – t és a PI-t többnyire Java-ban fejlesztették ki. Ezek a modulok nem futtathatók, de alkalmazáskiszolgálón kell őket telepíteni, azaz ABAP Web Application Server for ABAP modules és Java Web Application Servers for Java modules.

kevés pontot kell tudnunk, mielőtt belevágnánk a témába.

• az SAP az adatfeldolgozás rendszereit, alkalmazásait és termékeit jelenti.

• az SAP AG egy német multinacionális szoftvervállalat, amely vállalati szoftvereket gyárt az üzleti műveletek és az ügyfélkapcsolatok kezelésére. Az SAP ERP a vállalat vállalati erőforrás-tervezése, egy integrált szoftvermegoldás, amely magában foglalja a szervezet legfontosabb üzleti funkcióit.

• az SAP NetWeaver Process Integration (SAP PI) az SAP enterprise application integration (EAI) szoftver, amely a NetWeaver termékcsoport egyik alkotóeleme, amelyet a vállalat belső szoftverei és rendszerei, valamint a külső felek közötti információcsere megkönnyítésére használnak.

Legacy System

miközben az SAP ERP-t nagyvállalati létesítményben hajtják végre, kiderül, hogy nem minden szakasz hozható az SAP ERP alá. Sok üzleti részlegnek lehetnek saját, saját tulajdonú eszközei, amelyek rendkívül összetettek, és nem lehet őket kicserélni. Párhuzamosan futnak az SAP rendszerrel. Régi rendszereknek hívják őket. Ezután szükségessé válik az SAP rendszerek és a már meglévő nem SAP rendszerek közötti integráció. Itt jön létre az SAP PI.

miért van szükségünk SAP PI az örökölt rendszereken kívül egy nagyvállalati létesítményben az SAP ERP nem egyetlen rendszerből, hanem több integrált rendszerből áll, pl. CRM, SRM, FICO stb. Az ilyen bonyolultságok kezelésére az SAP bevezette a Folyamatintegrációt egy olyan platformra, amely egyetlen integrációs pontot biztosít minden rendszer számára anélkül, hogy megérintené a régi rendszerek meglévő komplex hálózatát. Ez az SAP hatékony köztes szoftvere, amely zökkenőmentes integrációt biztosít az SAP és a nem SAP alkalmazások között a vállalati határokon belül és kívül. Az SAP PI támogatja a B2B és az A2A cseréket, támogatja a szinkron és aszinkron üzenetcserét, és beépített motort tartalmaz az integrációs folyamatok tervezéséhez és végrehajtásához.

az SAP PI architektúrája

az SAP PI egy hub és küllő struktúrából áll; a küllők külső rendszerekkel kapcsolódnak, míg a hub üzeneteket cserél közöttük. A forrásrendszert küldő rendszernek, a célrendszert pedig fogadó rendszernek nevezik. A PI nem egyetlen összetevő, hanem olyan összetevők gyűjteménye, amelyek rugalmasan működnek együtt az integrációs forgatókönyvek megvalósítása érdekében. Az architektúra olyan összetevőket tartalmaz, amelyeket a tervezés, a konfiguráció és a Futtatás idején kell használni.

az SAP PI-t több területre oszthatjuk

1. integrációs szerver
2. integrációs Builder
3. rendszerkörnyezet
4. konfiguráció és felügyelet

az integrációs szerver az SAP PI központi feldolgozó motorja. Az összes üzenetet itt következetesen dolgozzuk fel. Három különálló motorból áll

1. integrációs Motor
2. Adapter motor
3. üzleti folyamat Motor

integrációs motor tekinthető az agynak, az Adapter motor pedig a küllőnek. Ami az üzleti folyamat motorját illeti, később elmagyarázom.

az Integration Builder egy kliens-szerver keretrendszer az integrációs objektumok eléréséhez és szerkesztéséhez, és két kapcsolódó eszközből áll:

1. Enterprise Service Repository-a tervezési és fejlesztési objektumokat kell használni forgatókönyvek
2. Integration Directory-konfigurálni az ESR objektumokat, hogy dolgozzon forgatókönyvek

két együtt építettünk integrációs folyamatok, amelyek gyakran nevezik forgatókönyvek.

a rendszerkörnyezet az adatközpontban található szoftverekkel és rendszerekkel kapcsolatos információk központi tárháza, amely egyszerűsíti a rendszerkörnyezet adminisztrációját.

a konfigurációban és a monitorozásban figyelemmel kísérhetjük az üzeneteket és az adaptereket.

Single stack és Dual stack

amikor a PI először megjelent, nem minden komponens épült ugyanazon a platformon. Az integrációs motor és az üzleti folyamatok motorja az ABAP-ban épült, míg az Adapter Engine, az Integration Builder, az SL, A CM és a Mapping Runtime Java-ban épült. Tehát a PI futtatásához mind a Java, mind az ABAP környezetre szükség van, és dual stack néven ismert.

ABAP Stack	Java Stack
integrációs Motor üzleti folyamat Motor integrációs építő	Enterprise Service Repository integrációs Könyvtár Runtime Workbench rendszer táj Könyvtár Adapter motor Mapping futásidejű

de a későbbi verzióban az összes komponens Java-ban van beépítve. A kettős verem egyes összetevőit vagy kiadják, vagy módosítják, hogy a Java veremen működjenek. Tehát a PI futtatásához csak a Java környezetre van szükség, és egyetlen veremként ismert.

vannak érvek és ellenérvek a két halom között, de ezek nem szerepelnek ebben az oktatóanyagban.

Integrációs Motor

az integrációs motor felelős a központi integrációs szerver szolgáltatásokért, azaz a csővezeték lépésekért-útválasztásért és leképezésért. Ha a forrásüzenet-struktúra eltér a célüzenet-struktúrától, akkor az integration engine meghívja a leképezés Futásidejét, ahol a forrásstruktúra átalakul a célstruktúrává. A leképezési futási idő a Java veremen alapul. Az integrációs motor ABAP programot is használhat az átalakításhoz, amely az ABAP veremen alapul.

az üzenet kétféle lehet

1. szinkron – mind a kérés-válasz rész
2. aszinkron – csak a kérés vagy a válasz rész

a PI-ben az üzenetet interfész képviseli.

interfész -> az üzenet felépítése XML formátumban + irány

a fenti kritériumok alapján három típusú interfész létezik

1. kimenő interfész – csatlakozás a feladó rendszerhez
2. bejövő interfész – csatlakozás a vevőrendszerhez
3. absztrakt interfész – csatlakozás a BPE-hez

amikor az integrációs logikát (forgatókönyvet) az SAP PI-ben konfiguráljuk üzleti követelményeinknek megfelelően, az integrációs motor hajtja végre ezt a konfigurációt lépésről lépésre. A csővezeték az XML-üzenet feldolgozása során végrehajtott összes lépésre utal. A csővezeték lépései a következőkből állnak:

1. vevő azonosítása-meghatározza azt a rendszert, amely részt vesz az üzenetváltásban.
2. Interface Determination – határozza meg, hogy melyik interfésznek kell fogadnia az üzenetet.
3. üzenet felosztása – ha egynél több vevőt talál, a PI minden vevőhöz új üzenetet jelenít meg.
4. Message Mapping – leképezés a forrásüzenet célüzenet formátumba történő átalakításához.
5. MŰSZAKI útvonalválasztás – egy adott cél és protokoll kötése az üzenethez.
6. Call Adapter – küldje el az átalakított üzenetet az adapternek vagy egy proxynak.

Adapter Engine

korábban észre kellett vennie, hogy az integrációs motor csak XML-SOAP protokollban kezeli az üzeneteket. De mi van akkor, ha van egy feladó és egy fogadó üzleti rendszerünk, ahol az adatok nem ugyanabban a formátumban vannak. Az Adaptermotor különböző adaptereit használjuk az XML – és HTTP-alapú üzenetek átalakítására az e rendszerek által megkövetelt protokollra és formátumra, és fordítva.

mint korábban említettük, az SAP PI egy hub és küllős szerkezet, ahol az Adapter motorja küllőnek tekinthető. Az Adaptermotor segítségével csatlakoztatjuk az integrációs motort (Hub) a külső rendszerekhez. Az Adapter keretrendszer az Adapter motor alapja. Az Adapter keretrendszer az SAP J2EE motoron (az SAP Web Application Server részeként) és a J2EE Connector architektúrán (JCA) alapul. Az Adapter keretrendszer interfészeket biztosít az adapterek konfigurálásához, kezeléséhez és felügyeletéhez.

kettős verem rendszerben a legtöbb adapter, ahol a Java veremen alapul, két adaptert tartalmaz, amelyek az ABAP veremen alapulnak.

Java Stack	RFC adapter, SAP Business Connector adapter, file / FTP adapter, JDBC adapter, JMS adapter, SOAP adapter, Marketplace Adapter, Mail adapter, RNIF adapter, CIDX adapter
ABAP stack	IDOC adapter és HTTP adapter

amikor az SAP PI a kettős veremből az egy verembe költözött, akkor ez a két adapter a Java verem részévé vált. A módosított adaptermotor Advance Adapter Engine néven ismert, a két adaptert IDOC_AAE adapternek, illetve HTTP_AAE adapternek hívják.

Üzleti Folyamat Motor

Az üzleti folyamatok motorja felelős az integrációs folyamatok végrehajtásáért és tartósságáért.

a bpm a cross-component Business Process Management vagy ccBPM rövidítése, és integrációs folyamatnak is nevezik. Az integrációs folyamat futtatható, rendszerek közötti folyamat az üzenetek feldolgozására. Egy integrációs folyamatban meghatározza az összes végrehajtandó folyamatlépést, valamint a folyamat vezérléséhez szükséges paramétereket. Az üzleti folyamatok kezelése az SAP Exchange infrastruktúrát a következő funkciókkal látja el:

1. állapot – teljes üzenetfeldolgozás: az integrációs folyamat állapota megmarad az integrációs kiszolgálón.
2. korrelációkat is használhat az üzenetek közötti szemantikai kapcsolatok létrehozására.
3. integrációs folyamatokat valósít meg, amikor olyan összetett integrációs folyamatokat kíván definiálni, vezérelni és felügyelni, amelyek kiterjednek a vállalati és alkalmazási határokon, azaz gyűjtés/egyesítés, felosztás, csoportos küldés

futás közben az üzleti Folyamatmotor végrehajtja az integrációs folyamatokat. Az integrációs folyamat csak absztrakt interfészek segítségével küldhet és fogadhat üzeneteket.

forgatókönyv készítése az SAP PI-ben

a kezdőlapról indulunk, ha forgatókönyvet kell készítenünk a PI-ben.

a Kezdőlap hasonló lesz az alábbiakhoz:

6. ábra-Az SAP PI Java verem honlapja

a Kezdőlap hiperhivatkozásokat tartalmaz a következő 4 munkaterületre

1. Enterprise Services Repository (ESR)
2. integrációs Könyvtár (ID)
3. System Landscape (SL)
4. konfiguráció és monitorozás (CM)

minden hiperhivatkozás egy alkalmazást nyit meg. Mind a négy Java alkalmazás. Az ESR és az ID swing alkalmazások. A JNLP alapú böngészőből indulnak. Tehát először több időt vesz igénybe, mivel letölti a teljes könyvtárfájlt. De a második alkalommal kevesebb időbe telik az indítás. Az SL és a CM tiszta webes alkalmazások, és a böngészőben futnak.

Enterprise Services Repository

itt tervezünk és hozunk létre objektumokat az integrációs forgatókönyv készítéséhez. Az adatáramlás a PI-ben hasonlóan fog kinézni, mint az alábbiakban látható:

megtaláljuk a lehetőséget, hogy tervezzen a következő

1. Interface objects-szolgáltatás interfész, Üzenet típusa, adattípus
2. Mapping objects-művelet Mapping and Message Mapping
3. integrációs folyamatok

a PI integrációs adattárat használ az üzenetstruktúra tervezéséhez mind a küldő, mind a vevő rendszerek számára, és interfészüzenetet fejleszt ki a megfelelő üzenetstruktúrák felhasználásával, amelyek a külvilággal való interakció pontjaként működnek. Az adattípus és az üzenet típusa a komplex interfész tervezésének egyszerűsítésére és modularizálására szolgál.

a művelet leképezése lehetővé teszi a forrásszerkezet átalakítását célstruktúrává, ha a két struktúra különbözik. De ha a forrás és a célszerkezet megegyezik, akkor a művelet leképezése elhagyható. A service interface-hez hasonlóan az üzenet leképezést is használják egy komplex művelet leképezés tervezésének egyszerűsítésére és modularizálására. Message mapping lehet megvalósítani 4 módon

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

grafikus mapping a leggyakrabban használt, mivel lehetővé teszi a fejlesztő térkép attribútumok mindkét struktúrák grafikusan átadni az adatokat a szolgáltatási felületek. A másik háromnál a leképezést kód írásával kell fejlesztenünk. Ha ez egy verem szerver, akkor az ABAP leképezés nem lesz elérhető.

vannak más területek is, de ezekre nem terjed ki ez az oktatóanyag.

integrációs Könyvtár

itt végezzük el a csővezeték lépéseit a korábban létrehozott ESR objektumok konfigurálásával. Ezeket a lépéseket az integrációs motor futási idő alatt hajtja végre.

a konfiguráció megkezdése előtt a következő objektumokat kell létrehoznunk/importálnunk a DIR-ben.

1. szolgáltatás – Üzleti rendszer/ üzleti szolgáltatás/ integrációs folyamat
2. kommunikációs csatorna

a szolgáltatás lehetővé teszi az üzenetek küldőjének vagy fogadójának megszólítását. A szolgáltatás használatának módjától függően a következő szolgáltatástípusok közül választhat.

1. üzleti rendszer – ha egy adott üzleti rendszert szeretne üzenetek küldőjeként vagy fogadójaként címezni, válassza ezt a szolgáltatástípust. Az üzleti rendszer egy tényleges alkalmazási rendszer egy rendszerkörnyezetben.
2. üzleti szolgáltatás – ha absztrakt üzleti entitást szeretne címezni az üzenetek küldőjeként vagy fogadójaként, válassza ezt a szolgáltatástípust. Az üzleti szolgáltatás Nincs meghatározva a rendszerkörnyezetben.
3. integrációs folyamat szolgáltatás – Ha egy integrációs folyamatot üzenetek küldőjeként vagy fogadójaként szeretne címezni, válassza ezt a szolgáltatástípust. Futásidőben ezeket az integrációs folyamatokat üzenetek vezérlik, és maguk is küldhetnek üzeneteket.

a kommunikációs csatorna meghatározza az üzenetek Bejövő és kimenő feldolgozását. Az üzenetek natív formátumból soap-xml-specifikus üzenetformátumba konvertálódnak, és fordítva az adapteren keresztül. Általában kétféle kommunikációs csatorna van egy forgatókönyvben

1. feladó kommunikációs csatorna
2. vevő kommunikációs csatorna

kommunikációs csatornát kell hozzárendelnie egy szolgáltatáshoz. Attól függően, hogy a szolgáltatás címzettje az üzenetek küldője vagy fogadója, a hozzárendelt kommunikációs csatorna feladó vagy fogadó csatorna szerepet tölt be, és ennek megfelelően kell konfigurálni. Nem rendelhet kommunikációs csatornát integrációs folyamat szolgáltatáshoz.

a csővezeték lépéseit a következő 4 konfiguráció létrehozásával hozza létre a DIR

a következő lehetőségeket találjuk:

1. feladó megállapodás
2. Vevő meghatározása
3. interfész meghatározása
4. Vevő megállapodás

a feladó megállapodás meghatározza, hogy a feladó üzenetét hogyan kell átalakítani úgy, hogy azt az integrációs kiszolgáló feldolgozhassa. Ez áll a következő

1. Sender komponens
2. Sender interfész
3. Sender kommunikációs csatorna

Sender megállapodás hasonló elsődleges kulcs a táblázatban. Nem lehet két hasonló feladói megállapodás egy tájon.

a vevői megállapodás meghatározza az üzenet átalakításának módját, hogy azt a vevő feldolgozhassa. Ez áll a

1. feladó komponens
2. Vevő komponens
3. Vevő interfész
4. vevő kommunikációs csatorna

a vevő meghatározása annak meghatározására, hogy melyik vevőnek kell üzenetet küldeni. Lehetősége van meghatározni az üzenet továbbításának feltételeit a vevőknek. Ez áll a

1. Sender Component
2. Sender Interface
3. Receiver Component

Vevő meghatározása két típusa van – Standard vagy kiterjesztett, attól függően, hogy meg szeretné-e adni a Vevő kézzel vagy dinamikusan leképezés futás közben.

az interfész meghatározásával megadhatja, hogy a vevő melyik bejövő interfésze; az üzenetet továbbítani kell. Azt is megadhatja, hogy az integrációs adattárból melyik interfész-leképezést kell használni az üzenet feldolgozásához, pl. ha a küldő és a fogadó interfész nem azonos formátumú, akkor van egy operatív leképezés a formátum megváltoztatásához. Megadhat egy interfész meghatározást egy küldő, egy kimenő interfész és egy vevő számára. Ez áll a

1. Sender Component
2. Sender Interface
3. Vevő komponens
4. Vevő interfész

interfész meghatározása két típusa van – Standard vagy továbbfejlesztett, attól függően, hogy meg szeretné-e adni a vevő interfész kézzel vagy leképezés alapú üzenet osztott.

Vevő meghatározása és interfész meghatározása – a kettő együttesen logikai útválasztásként ismert. Küldő megállapodás és fogadó megállapodás-a kettő együtt közismert nevén Együttműködési Megállapodás.

System Landscape

az SAP System Landscape Directory (SLD) a központi információ szolgáltató a rendszer táj. A weboldalon a következő linkeket találja:

1. műszaki rendszer-a műszaki rendszerek olyan alkalmazási rendszerek, amelyek a rendszer környezetében vannak telepítve.
2. üzleti rendszer – az üzleti rendszerek logikai rendszerek, amelyek feladóként vagy vevőként működnek a PI-n belül. Az üzleti rendszerek egy-egy függőséggel rendelkeznek a kapcsolódó műszaki rendszerrel.
3. termékek és összetevők – ez az információ az összes elérhető SAP termékről és összetevőről, beleértve azok verzióit is. Ha vannak harmadik féltől származó termékek a rendszerkörnyezetben, akkor itt is regisztrálják őket.

az SLD az alábbiakhoz hasonlóan fog kinézni:

11. ábra-a rendszer tájképe

a termékeket és alkatrészeket általában komponens információnak nevezik

a műszaki rendszert és az üzleti rendszert általában Tájleírásnak nevezik.

egy üzleti rendszer integrációs kiszolgálóként vagy Alkalmazásrendszerként konfigurálható.

1. integrációs kiszolgáló – az integrációs kiszolgáló csak az integrációs Építőben konfigurált integrációs logikát hajtja végre. Ők is azonosítható csővezeték lépéseket. XML üzenetet fogad, meghatározza a Vevőt, végrehajtja a leképezéseket, és az XML üzenetet a megfelelő vevőrendszerekhez irányítja. Az így konfigurált integrációs motor központi konfigurált integrációs motornak minősül.
2. alkalmazási rendszer – az alkalmazási rendszer nem hajtja végre az integrációs logikát. Ez viszont felhívja az integrációs kiszolgálót, hogy szükség esetén hajtsa végre az integrációs logikát. Úgy működik, mint feladó vagy vevő XML üzenetek. Tehát a helyi integrációs motorral rendelkező Alkalmazásrendszer megköveteli az integrációs kiszolgálótól az integrációs logika végrehajtását.

az SAP rendszernek csak egy kliense konfigurálható integrációs szerverként.

a következő információkat nyerik ki az SLD-ből az ESR-be és a DIR-be

1. a komponens információkat az ESR-ben használják a termék meghatározásához, az SWCV
2. üzleti rendszert pedig a könyvtárban használják az üzenetek küldőjének és fogadójának meghatározásához

konfiguráció és monitorozás

ez a központi belépési pont az ellenőrzési célokra. Ez lehetőséget ad az integrációs Motor felügyeleti funkcióihoz való navigálásra, valamint az SAP Computing Center Management System (CCMS) és a Process Monitoring Infrastructure (PMI) integrációjára.

a konfiguráció és a megfigyelés az alábbiakhoz hasonlóan fog kinézni:

13. ábra-konfiguráció és felügyelet

a konfigurációval és a figyeléssel a következő felügyeleti funkciók támogatottak:

1. Component monitoring-monitoring a különböző SAP PI komponensek (Java és ABAP alkatrészek).
2. Üzenetfigyelés – az ÜZENETFELDOLGOZÁSI állapot nyomon követése egy SAP PI komponensen belül, valamint a hibák észlelése és elemzése.
3. End-to – end monitoring-az üzenet életciklusának nyomon követése az SAP PI szempontjából.
4. Teljesítményfigyelés – az SAP PI különböző teljesítmény-szempontjaira vonatkozó statisztikák az RWB-n keresztül érhetők el. Itt kiválaszthatja és összesítheti a teljesítményadatokat, például összetevő, időtartomány vagy üzenetattribútumok szerint.
5. Indexfelügyelet – az üzenetek SAP PI-összetevőnkénti indexelésének felügyeletével és felügyeletével engedélyezheti az index alapú üzenetkeresést, amelyet az üzenetfigyelésben használhat. Ez a fajta üzenetkeresés továbbfejlesztett kiválasztási feltételeket kínál, beleértve az illesztő – specifikus üzenetattribútumokat, valamint az üzenet Hasznos terhelésében szereplő kifejezéseket vagy kifejezéseket.
6. Alert configuration – az Alert Framework használatával a PI központi monitorozása az ABAP és Java üzenetfeldolgozás során jelentett összes hibával ellátható. Ez lehetővé teszi az ilyen hibákra való jobb reagálást mind az ABAP futásidejű, mind a Java-alapú Adaptermotorban. Ebből a célból a riasztási keretrendszer bizonyos eseményeken és a PI üzenetprotokoll fejlécéből származó információkon alapuló szabályokat tartalmaz. Ezek a szabályok határozzák meg, hogy a riasztások elküldésre kerülnek-e vagy sem. Ha riasztást küld, akkor hibaelemzésre használható.
7. riasztási beérkező levelek – a riasztási beérkező levelek felhasználó-specifikus, és megjeleníti az összes riasztást minden riasztási kiszolgálóhoz, amelyet a riasztási konfiguráció alapján hoztak létre.
8. gyorsítótár figyelése – a gyorsítótár figyelése a futásidejű gyorsítótárban lévő objektumokat jeleníti meg. Az adott gyorsítótár-példánytól függően különböző gyorsítótár-objektumok figyelhetők meg.

szinkron vs.aszinkron kommunikáció

egy folyamat meghatározható szinkronként vagy aszinkronként.

• egy kérés/válasz művelet egy szinkron folyamatot hív meg, és a folyamat eredményét ezen műveleten keresztül azonnal visszaküldi a hívónak.
• egy aszinkron folyamatot egyirányú művelet hív meg, és az eredmény és az esetleges hibák más egyirányú műveletek meghívásával kerülnek visszaadásra. Az eredmény visszahívási művelettel kerül vissza a hívóhoz.

a számítógépes világban nincs aszinkron kommunikáció. A két rendszer közötti kommunikáció mindig módszerhíváson keresztül történik (kérés/válasz művelet). Tehát hogyan lehet aszinkron? A válasz egy harmadik rendszer bevezetésében rejlik a hívott és a hívó funkció között.

tegyük fel, hogy két rendszer létezik – A és B. Minden kommunikáció a és B között metódushíváson keresztül történik, így szinkronban vannak. Bevezetünk egy harmadik rendszert A és B között, és közbenső rendszernek nevezzük-I. az A és I közötti kommunikáció módszerhíváson keresztül történik, és hasonlóan I és B között is módszerhíváson keresztül. De az A és B közötti kommunikáció aszinkronnak nevezhető, mivel A-nak nem kell várnia a B válaszát.

ez az aszinkron kommunikáció alapja, és mi ez a köztes rendszer? Ez a sor. A-t a küldőnek, B-t pedig a Vevőnek hívják. Az a üzenet először hozzáadódik a sorhoz, majd ismét kihúzódik a sorból, és elküldi B-nek. Bizonyos helyzetekben az üzleti követelménynek szüksége van arra, hogy az üzeneteket B-nek ugyanabban a sorrendben kézbesítsék, mint az A-tól. Ha nincsenek ilyen követelmények, akkor az üzenetek a sorból a B-be kerülnek bármilyen sorrendben.

aszinkron kommunikációval garantált kézbesítést érünk el, azaz a B rendszer nem érhető el, amikor az a rendszer elküldi az üzenetet. Az üzenet hozzáadódik a várólistához, és mindaddig ott marad, amíg B nem érhető el. Miután B elérhető, az üzenet ki van húzva a sorból, és elküldi a B.

– nek, így háromféleképpen osztályozhatjuk az üzenetkommunikációt:

1. szinkron
2. aszinkron a nem karbantartott sorrenddel
3. aszinkron a fenntartottakkal

a PI – ben azonosítjuk őket: szinkron – BE (legjobb erőfeszítés), aszinkron a nem karbantartott sorrenddel – EO (pontosan egyszer), aszinkron a fenntartottakkal-EOIO (pontosan egyszer sorrendben).

nyugtázás

a nyugtázás az aszinkron kommunikáció gyökere. Miért?

szinkron kommunikáció esetén az A rendszer felhívja a B rendszert, és ha B nem küldi el a választ, a folyamat sikertelen. De egy aszinkron kommunikációban az a rendszer hívja az I rendszert,az I rendszer pedig a B rendszert. Hogyan kell a észre, hogy a szállítás B nem sikerült? Ezt egy nyugtázás valósítja meg, amelyet B ugyanazon az útvonalon küld vissza A-nak, mint az a üzenete B-nek. Ha a nyugtázás B-től nem érkezik meg A-hoz, akkor a úgy véli, hogy a folyamat sikertelen volt, és újra elküldi az üzenetet.

míg a PI-ben az aszinkron kommunikációról beszéltünk, a – ‘pontosan egyszer’ kifejezést használtuk mind az EO, mind az EOIO esetében. Pontosan egyszer azt jelenti, hogy az egyszer kézbesített üzenetet nem lehet újra kézbesíteni. Ennek elérése érdekében, van egy nyugtázás minden üzenetet küldeni A B. Ez az adapterek, amelyek fekszenek a végén a kommunikáció. Tehát az adaptereknek támogatniuk kell a nyugtázást.

minden adapter biztosítja a rendszer-nyugtázást i.e. szállítási visszaigazolás. Azok az adapterek, amelyek támogatják a szinkron kommunikációt, támogatják az alkalmazás-nyugtázást a rendszer nyugtázása mellett.

tehát a PI – ben a következők a nyugtázás típusa

1. rendszer nyugtázás-a futásidejű környezet által használt rendszer nyugtázások annak megerősítésére, hogy aszinkron üzenet érkezett a vevőhöz.
2. alkalmazás nyugtázás – alkalmazás nyugtázások annak megerősítésére, hogy az aszinkron üzenet sikeresen feldolgozásra került a vevőnél.

távoli funkcióhívás

a PI – ben végzett munka során találkozik az-RFC kifejezéssel. Mik ezek? Két SAP rendszer, azaz az R/3 és a PI közötti kommunikáció létrehozásához létrehozzuk az RFC célállomást. A következő

1. Kapcsolat típusa
2. IP-cím és a vevő portja

a Kapcsolat típusa megmondja a Rendszercsatlakozás típusát, azaz R/3, TCP/IP, belső stb.

az általunk létrehozott RFC rendeltetési helyet a szükséges kommunikációs mód szerint osztályozzuk, azaz. támogatja-e a szinkron vagy aszinkron kommunikációt.

1. szinkron kommunikáció esetén – szinkron RFC
2. aszinkron kommunikáció esetén nem karbantartott sorrendben – tranzakciós RFC
3. aszinkron kommunikáció esetén karbantartott sorrendben – sorban álló RFC

ezeket az sRFC, a tRFC és a qRFC azonosítja.

esettanulmányok – 1

tegyük fel, hogy egy osztályteremben van, és 10 diák van benne. Az oktató ezután felkéri a tanulókat, hogy készítsék el a következő Személyes adatokat, és mentsék el őket egy XML fájlba. A részletek a következők:

1. diákigazolvány
2. név
3. mobil
4. e-mail
5. nem

10 Fájl lesz, és a fájlok neve cv_1, 2, 3….10. A fájlok a forráskönyvtárba kerülnek. Tesztelési célokra a következő könyvtárak jönnek létre:

forráskönyvtár: c:\ibm\sap\training\input

archív könyvtár: c:\ibm\sap\training\archive

hiba könyvtár: c:\ ibm \ sap \ képzés \ hiba

Célkönyvtár: c:\ibm\sap\training\target

a program arra kéri, hogy dolgozzon ki olyan forgatókönyveket az SAP PI-ben, amelyek beolvassák a forrásfájlokat a forráskönyvtárból, és beírják őket a célkönyvtárba. Ha egy fájlt sikeresen elolvasott a forráskönyvtárból, át kell helyezni az archív könyvtárba, és ha a fájl valamilyen hiba miatt nem olvasható, azaz az xml formátum nem karbantartott, akkor át kell helyezni a hibakönyvtárba. Az archívumba, hibába vagy célkönyvtárba áthelyezett fájloknak időbélyegzővel kell rendelkezniük a fájlnévhez.

1. azaz. fájlnév + <időbélyegző>.

lecke-1

készítsen elő egy forgatókönyvet egyetlen fájl, azaz a cv_1 fájl olvasására.xml-t a forráskönyvtárból, és írja be a célkönyvtárba. A célfájl nevének szintén cv_1 – nek kell lennie.xml az időbélyeggel csatolja a nevet.

2.lecke

készítsen elő egy forgatókönyvet a forráskönyvtárból származó összes fájl elolvasására és a célkönyvtárba írására. Hasonlóképpen a célfájlokat cv_1, 2 néven is meg kell nevezni ..xml az időbélyeggel mindegyikhez hozzáfűzni.

3.lecke

ezután az oktató arra kéri Önt, hogy adja hozzá a következő érvényesítést az adatokhoz.

1. a mobilszámnak 10 számjegyből kell állnia – ha a mobilszám nem 10 számjegyből áll, akkor cserélje ki ‘error’
2. az e-mailnek egy ‘@’ karakterrel és egy ‘karakterrel kell rendelkeznie.’karakter – ha az e-mailben nincs ‘@’ vagy ‘.’karakter, majd cserélje ki ‘hiba’

a forgatókönyv futtatása előtt néhány forrásfájlban módosítsa a mobilot és az e-mailt úgy, hogy azok hibásak legyenek a fenti logika szerint.

4.lecke

készítsen elő egy forgatókönyvet az összes forrásfájl elolvasására és osztályozására nemük szerint. A férfiak fájljait az egyik könyvtárba, a hölgyeket pedig egy másik könyvtárba írják. A fenti célra két könyvtárat hoztak létre:

férfiak célkönyvtára: c:\ibm\sap\training\target\men

női Célkönyvtár: c:\ ibm \ sap \ training \ target \ women

tegyük fel, hogy 6 férfi és 4 nő van az osztályban, akkor ha az összes forrásfájlt sikeresen elolvassa, akkor a férfiak célkönyvtárának 6, a nők célkönyvtárának pedig 4 fájlnak kell lennie.

esettanulmányok – 2

ezután az oktató arra kéri Önt, hogy készítsen egyetlen fájlt az egyes hallgatók személyes adataival külön szegmensekben.

lecke-5

írj egy forgatókönyvet, amely elolvassa ezt a fájlt, és 10 célfájlt hoz létre, ahol minden fájlnak meg kell felelnie az egyes alkalmazottak személyes adatainak. A célfájlokat cv_<emp_ID>_<időbélyeg>

lecke-6

módosítsa a fenti forgatókönyvet úgy, hogy 2 célfájlt állítson elő 10 helyett, ahol egy célfájl férfiaknak, egy másik célfájl a hölgyeknek. A férfiak célfájljának 6 szegmensnek kell lennie 6 férfiak számára, a hölgyek célfájljának pedig 4 szegmensnek kell lennie 4 nők számára.

a célfájlokat

férfiaknak – men_<időbélyegző>

Hölgyeknek-women_<time_stamp>

esettanulmány -3

ugyanaz, mint az esettanulmány – 1, az oktató minden tanulót arra kér, hogy készítse el saját a személyes adatokat, és mentse őket egy XML fájlba. 10 Fájl lesz. A fájlok a forráskönyvtárba kerülnek.

Lesson-7

készítsen elő egy forgatókönyvet az összes forrásfájl beolvasására a forráskönyvtárból, és egyetlen fájl létrehozására a célkönyvtárban. A célfájl neve megjelenik.xml az időbélyeggel csatolja a fájlnevet. A célfájl alszegmensként tartalmazza az egyes forrásfájlok összes részletét.

Lesson-8

készítsen egy forgatókönyvet, hogy olvassa el a teljes forrásfájlokat a forráskönyvtárból, és hozzon létre két fájlt a célkönyvtárban – az egyik a férfiaknak, a másik a hölgyeknek. Mert 6 férfiak, a férfi fájlnak hat szegmensnek kell lennie, amelyek tartalmazzák az egyes férfiak adatait, 4 nők, hasonlóképpen 4 szegmensnek kell lennie minden hölgy adataival.

esettanulmány-4

az oktató most arra kéri a hallgatókat, hogy készítsenek újabb részleteket, amelyek a következő akadémiai részletekből állnak:

1. Diákazonosító
2. iskola neve
3. Főiskola neve
4. Osztály neve
5. felvételi év

10 Fájl lesz, és a fájlok neve ad_1, 2, 3….10. A fájlok a forráskönyvtárba kerülnek. Tehát minden hallgatónak lesz egy pár fájlja – az egyik a személyes adatokhoz, a másik az akadémiai részletekhez. Két akta kapcsolódik a Diákigazolványhoz. A bemeneti könyvtár jelenleg 10 személyes és 10 tudományos fájlból áll.

Lesson – 9

a program arra kéri, hogy dolgozzon ki egy forgatókönyvet, amely kiválasztja a forrásfájlokat, és párban dolgozza fel őket. A forgatókönyv 10 célfájlt generál. Minden célfájl a hallgató személyes és tudományos adataiból áll, külön szegmensekben. A célfájlok neve res_1, 2, 10 lesz.

a célfájlok így fognak kinézni:

Lesson – 10

ezután meg kell változtatnia a diákigazolványt néhány fájlban, hogy azok ne rendelkezzenek megfelelő tanulmányi vagy személyes fájlokkal, és fordítva. A forgatókönyv kell futtatni, és ha talált olyan fájlokat, akik nem rendelkeznek a megfelelő megfelelő fájlt, akkor a folyamat végén egy bizonyos ideig, azaz 2 perc, és ezek a fájlok kerülnek át a hiba könyvtárba, és nem lesz megfelelő cél fájlokat számukra.