SAP PI pro začátečníky

cíl

cílem tohoto tutoriálu je, abyste pochopili-co je integrace procesu SAP? Nebudeme jít do natvrdlý-kostrbatý tématu, ale budeme diskutovat o architektuře a různé vlastnosti SAP PI. Pokryjeme pouze základní funkce a vyhneme se diskusi o všech funkcích v tomto tutoriálu.

dále je zde sada případových studií, které vám poskytnou představu o využití SAP PI na průmyslové úrovni. Jakmile se s tímto tématem seznámíte, měli byste se je pokusit vyřešit. Testovací případy jsou připraveny tak, aby vás s každou lekcí přenesly do předmětu od jednoduchých až po komplexy a poskytly vám celkovou představu o předmětu.

co je SAP ERP?

pro všechny podniky – velké i malé, to jsou standardní obchodní funkce, které musí provádět, tj. Správa materiálu, prodej a distribuce, Finance, lidské zdroje atd. Existuje mnoho software na trhu, který je využíván v průmyslu. Všimnete si toho nejjednoduššího-pokladního stroje generujícího prodejní fakturu, pokud navštívíte malý obchod do sítě počítačů ve velkém maloobchodě, hotelu atd. pracující na ERP.

Enterprise Resource Planning tj ERP je efektivní přístup, který většina podniků implementovat zvýšit jejich produktivitu a výkon. SAP ERP je plánování podnikových zdrojů SAP AG, integrované softwarové řešení, které zahrnuje klíčové obchodní funkce organizace. Základní funkce, tj. HR, MM, SD, FICO atd., se v SAP nazývají business moduly. SAP je staví jako produkty a prodává je na trhu. Existují další dva moduly, které nepodporují obchodní funkce přímo, ale jsou využívány pro prezentaci a integraci. První se nazývá EP (Enterprise Portal) a druhý se nazývá PI (procesní integrace). Všechny obchodní moduly jsou vyvíjeny v ABAP, zatímco EP a PI jsou vyvíjeny převážně v Javě. Tyto moduly nejsou spustitelné, ale musí být nasazeny v aplikačním serveru, tj. ABAP Web Application Server pro ABAP moduly a Java Web Application servery pro Java moduly.

existuje několik bodů, které bychom měli vědět, než skočíme do předmětu.

• SAP je zkratka pro systémy, Aplikace a produkty při zpracování dat.

• SAP AG je německá nadnárodní softwarová společnost, která vyrábí podnikový software pro řízení obchodních operací a vztahů se zákazníky. SAP ERP je podnikové plánování zdrojů společnosti, integrované softwarové řešení, které zahrnuje klíčové obchodní funkce organizace.

• SAP NetWeaver Process Integration (SAP PI) je software SAP enterprise application integration (EAI), součást skupiny produktů NetWeaver, který slouží k usnadnění výměny informací mezi interním softwarem a systémy Společnosti a externími stranami.

starší systém

při implementaci SAP ERP ve velkém obchodním zařízení se zjistilo, že ne všechny sekce mohou být uvedeny pod SAP ERP. Mnoho obchodních sekcí může mít své vlastní proprietární nástroje, které jsou velmi složité a nemusí být možné je vyměnit. Běží paralelně se systémem SAP. Říká se jim starší systémy. Poté je nutné integrovat mezi systémy SAP a takovým již existujícím systémem, který není SAP. To je místo, kde SAP PI přichází do hry.

proč potřebujeme SAP PI kromě starších systémů se SAP ERP ve velké obchodní instituci nespočívá v jediném systému, ale v několika integrovaných systémech, tj. CRM, SRM a FICO atd. Zvládnout s takovými složitostmi SAP představil procesní integraci platformu, která poskytuje jediný bod integrace pro všechny systémy, aniž by se dotkla stávající komplexní sítě starších systémů. Jedná se o výkonný middleware společnosti SAP, který poskytuje bezproblémovou integraci mezi aplikacemi SAP a non-SAP uvnitř i vně podnikové hranice. SAP PI podporuje výměny B2B i A2A, podporuje synchronní a asynchronní výměnu zpráv a zahrnuje vestavěný motor pro navrhování a provádění integračních procesů.

Architektura SAP PI

SAP PI se skládá ze struktury náboje a paprsku; paprsky se spojují s externími systémy, zatímco rozbočovač mezi nimi vyměňuje zprávy. Zdrojový systém je známý jako systém odesílatele a cílový systém je známý jako systém přijímače. PI není jediná složka, ale spíše soubor komponent, které flexibilně spolupracují na implementaci integračních scénářů. Architektura zahrnuje komponenty, které mají být použity v době návrhu, v době konfigurace a v době běhu.

SAP PI můžeme rozdělit do několika oblastí

1. integrační Server
2. Integration Builder
3. systémové prostředí
4. konfigurace a monitorování

integrační Server je centrálním zpracovatelským motorem SAP PI. Všechny zprávy jsou zde zpracovávány konzistentním způsobem. Skládá se ze tří samostatných motorů

1. integrační Motor
2. Adaptérový Motor
3. obchodní procesní Motor

integrační motor lze považovat za náboj a Adaptérový motor za paprsek. Pokud jde o motor obchodních procesů, vysvětlím to později.

Integration Builder je rámec klient-server pro přístup a editaci integračních objektů a skládá se ze dvou souvisejících nástrojů:

1. Enterprise Service Repository-pro návrh a vývoj objektů, které mají být použity ve scénářích
2. integrační adresář-pro konfiguraci objektů ESR pro vývoj scénářů

dva dohromady jsme vytvořili integrační procesy, které se běžně nazývají scénáře.

systémové prostředí je centrálním úložištěm informací o softwaru a systémech v datovém centru a zjednodušuje správu vašeho systémového prostředí.

v konfiguraci a monitorování můžeme sledovat zprávy a adaptéry.

Single stack a Dual stack

když byl PI poprvé vydán, ne všechny komponenty byly postaveny na stejné platformě. Integration Engine a Business Process Engine byl postaven v ABAP, zatímco Adapter Engine, Integration Builder, SL, CM a Mapping Runtime byly postaveny v Javě. Takže PI potřebuje jak Java a ABAP prostředí pro spuštění a je známý jako dual stack.

ABAP Stack	Java Stack
Integration Engine Business Process Engine Integration Builder	úložiště podnikových služeb integrační adresář Runtime Workbench System Landscape Directory Adapter Engine Mapping Runtime

ale v novější verzi jsou všechny komponenty postaveny v Javě. Některé komponenty dual-stack jsou buď vypnuty nebo upraveny tak, aby fungovaly na zásobníku Java. Takže PI potřebuje ke spuštění pouze prostředí Java a je známý jako jediný zásobník.

mezi těmito dvěma zásobníky jsou klady a zápory, ale nejsou zahrnuty v tomto tutoriálu.

Integrační Motor

integrační modul je zodpovědný za služby centrálního integračního serveru, tj. Pokud se struktura zdrojové zprávy liší od struktury cílové zprávy, pak integration engine volá mapovací Runtime, kde je zdrojová struktura převedena na cílovou strukturu. Mapování Runtime je založen na zásobníku Java. Integrační motor může také využít program ABAP pro konverzi, který je založen na zásobníku ABAP.

zpráva může být dvou typů

1. synchronní-má jak část request-response
2. asynchronní-má buď část request nebo response pouze

v PI, zpráva je reprezentována rozhraním.

rozhraní -> struktura zprávy ve formátu XML + směr

na základě výše uvedených kritérií existují tři typy rozhraní

1. odchozí rozhraní – připojení k systému odesílatele
2. příchozí rozhraní – připojení k přijímacímu systému
3. abstraktní rozhraní – připojení k BPE

když nakonfigurujeme integrační logiku (scénář) v SAP PI jako podle našich obchodních požadavků je to integrační motor, který tuto konfiguraci provádí krok za krokem. Potrubí je termín používaný k označení všech kroků, které jsou prováděny během zpracování zprávy XML. Kroky potrubí se skládají z následujících:

1. identifikace přijímače-určuje systém, který se podílí na výměně zprávy.
2. určení rozhraní-určete, které rozhraní by mělo zprávu obdržet.
3. rozdělení zpráv – pokud je nalezeno více než jeden přijímač, PI vytvoří instanci nové zprávy pro každý přijímač.
4. mapování zpráv-mapování pro transformaci zdrojové zprávy do formátu cílové zprávy.
5. technické směrování-naváže ke zprávě konkrétní cíl a protokol.
6. Call Adapter – odešlete transformovanou zprávu do adaptéru nebo proxy.

Adaptérový Motor

dříve jste si museli všimnout, že integrační modul zpracovává zprávy pouze v protokolu XML-SOAP. Ale co když máme odesílatele a obchodní systém příjemce, kde data nejsou ve stejném formátu. Používáme různé adaptéry v adaptéru motoru převést XML – a HTTP-založené zprávy na konkrétní protokol a formát vyžadovaný těmito systémy, a naopak.

jak jsme již dříve diskutovali, SAP PI je struktura náboje a paprsku, kde lze motor adaptéru považovat za paprsek. Pomocí adaptérového motoru připojujeme integrační Motor (náboj) k externím systémům. Rámec adaptéru je základem motoru adaptéru. Rámec adaptéru je založen na motoru SAP J2EE (jako součást webového aplikačního serveru SAP) a architektuře J2EE Connector (JCA). Rámec adaptéru poskytuje rozhraní pro konfiguraci, správu a monitorování adaptérů.

v systému dual stack, většina adaptérů, kde na základě zásobníku Java blokování dva adaptéry, které jsou založeny na zásobníku ABAP.

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 adaptér a HTTP adaptér

když se SAP PI přesunul z duálního zásobníku na jeden zásobník, tyto dva adaptéry se staly součástí zásobníku Java. Modifikovaný Adaptérový motor je známý jako Advance Adapter Engine a dva adaptéry se nazývají idoc_aae adapter a HTTP_AAE adapter.

Business Process Engine

modul podnikových procesů je zodpovědný za provádění a přetrvávání integračních procesů.

BPM je zkratka pro cross-component Business Process Management nebo ccBPM a nazývá se také integrační proces. Integrační proces je spustitelný proces mezi systémy pro zpracování zpráv. V integračním procesu definujete všechny kroky procesu, které mají být provedeny, a parametry relevantní pro řízení procesu. Řízení podnikových procesů poskytuje infrastrukturu výměny SAP s následujícími funkcemi:

1. stav-úplné zpracování zpráv: stav integračního procesu přetrvává na integračním serveru.
2. můžete také použít korelace k vytvoření sémantických vztahů mezi zprávami.
3. implementujete integrační procesy, pokud chcete definovat, řídit a monitorovat složité integrační procesy, které přesahují hranice podniků a aplikací, tj. sbírat/sloučit, rozdělit, Multicast

za běhu, modul podnikových procesů provádí integrační procesy. Integrační proces může odesílat a přijímat zprávy pouze pomocí abstraktních rozhraní.

Vytvořte scénář v SAP PI

začneme z domovské stránky, pokud musíme vytvořit scénář v PI.

domovská stránka bude vypadat podobně jako níže:

obrázek 6-domovská stránka pro SAP PI Java Stack

domovská stránka obsahuje hypertextové odkazy na následující pracovní oblasti 4

1. Enterprise Services Repository (ESR)
2. Integration Directory (ID)
3. System Landscape (SL)
4. konfigurace a monitorování (CM)

každý hypertextový odkaz otevře jednu aplikaci. Všechny tyto čtyři jsou Java aplikace. ESR a ID jsou houpací aplikace. Jsou spuštěny z prohlížeče založeného na JNLP. Takže poprvé to trvá více času, jak to stáhne celý soubor knihovny. Ale od druhého okamžiku trvá spuštění méně času. SL a CM jsou čistě webové aplikace a běží v prohlížeči.

Enterprise Services Repository

zde navrhujeme a vytváříme objekty, které mají být použity při vytváření integračního scénáře. Tok dat v PI bude vypadat podobně jako níže:

najdeme možnost navrhnout následující

1. objekty rozhraní-rozhraní služby, typ zprávy, typ dat
2. mapování objektů-mapování operací a mapování zpráv
3. integrační procesy

PI používá integrační repozitář pro návrh struktury zpráv pro systémy odesílatele i příjemce a vývoj zprávy rozhraní pomocí odpovídajících struktur zpráv, které fungují jako bod interakce s vnějším světem. Datový typ a typ zprávy se používají ke zjednodušení a modularizaci návrhu komplexního rozhraní.

mapování operací umožňuje transformaci zdrojové struktury na cílovou strukturu, pokud se obě struktury liší. Ale v případě, že zdroj a cílová struktura jsou stejné, pak mapování operace může být upuštěno. Podobně jako servisní rozhraní se mapování zpráv používá ke zjednodušení a modularizaci návrhu komplexního mapování operací. Mapování zpráv lze implementovat 4 způsoby

1. grafické mapování
2. Java mapování
3. XSLT mapování
4. ABAP mapování

grafické mapování je nejpoužívanější, protože umožňuje vývojáři mapovat atributy obou struktur graficky předávat data pomocí servisních rozhraní. Pro ostatní tři musíme vyvinout mapování psaním kódu. Pokud se jedná o server s jedním zásobníkem, mapování ABAP nebude k dispozici.

existují i jiné oblasti, ale nejsou zahrnuty v tomto tutoriálu.

integrační adresář

zde provádíme kroky potrubí konfigurací dříve vytvořených objektů ESR. Tyto kroky jsou prováděny integračním motorem během běhu.

než začneme konfiguraci, musíme vytvořit / importovat následující objekty v DIR.

1. Service-Business System/ Business Service / Integration proces
2. komunikační kanál

služba vám umožňuje oslovit odesílatele nebo příjemce zpráv. V závislosti na tom, jak chcete službu používat, můžete vybrat z následujících typů služeb.

1. obchodní systém-pokud chcete adresovat konkrétní obchodní systém jako odesílatele nebo příjemce zpráv, zvolte tento typ služby. Obchodní systém je skutečný aplikační systém v systémovém prostředí.
2. Business Service – pokud chcete oslovit abstraktní obchodní subjekt jako odesílatele nebo příjemce zpráv, zvolte tento typ služby. Obchodní služba není definována v systémovém prostředí.
3. služba integračního procesu-pokud chcete adresovat integrační proces jako odesílatele nebo příjemce zpráv, zvolte tento typ služby. Za běhu jsou tyto integrační procesy řízeny zprávami a mohou samy odesílat zprávy.

komunikační kanál určuje příchozí a odchozí zpracování zpráv. Zprávy jsou převedeny z nativního formátu do formátu soap-xml specifické zprávy a naopak prostřednictvím adaptéru. Obecně existují dva typy komunikačních kanálů ve scénáři

1. komunikační kanál odesílatele
2. komunikační kanál přijímače

musíte službě přiřadit komunikační kanál. V závislosti na tom, zda je služba adresována jako odesílatel nebo příjemce zpráv, má přiřazený komunikační kanál roli odesílatele nebo přijímacího kanálu a musí být odpovídajícím způsobem nakonfigurován. Ke službě integračního procesu nelze přiřadit komunikační kanál.

kroky potrubí jsou vytvořeny vytvořením následující konfigurace 4 V DIR

najdeme následující možnosti:

1. Sender Agreement
2. Receiver Determination
3. Interface Determination
4. Receiver Agreement

Sender agreement definuje, jak má být zpráva odesílatele transformována tak, aby mohla být zpracována integračním serverem. Skládá se z následujícího

1. složka odesílatele
2. rozhraní odesílatele
3. komunikační kanál odesílatele

dohoda odesílatele je podobná primárnímu klíči v tabulce. Nemohou existovat dvě podobné dohody odesílatelů v jedné krajině.

přijímací smlouva definuje, jak má být zpráva transformována tak, aby mohla být zpracována přijímačem. Skládá se z

1. složky odesílatele
2. komponenty přijímače
3. rozhraní přijímače
4. komunikační kanál přijímače

pomocí určení přijímače určíte, kterým přijímačům má být zpráva odeslána. Máte možnost definovat podmínky pro předávání zprávy přijímačům. Skládá se z

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

určení přijímače je dvou typů – standardní nebo rozšířené, v závislosti na tom, zda chcete zadat přijímač ručně nebo dynamicky mapováním za běhu.

pomocí určení rozhraní určíte, které příchozí rozhraní přijímače; zpráva má být předána. Můžete také určit, které mapování rozhraní z integračního repozitáře má být použito pro zpracování zprávy, tj. pokud odesílatel a rozhraní přijímače nejsou stejného formátu, existuje operační mapování pro změnu formátu. Definujete určení rozhraní pro odesílatele, odchozí rozhraní a příjemce. Skládá se z

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

určení rozhraní je dvou typů-standardní nebo rozšířené, v závislosti na tom, zda chcete zadat rozhraní přijímače ručně nebo pomocí rozdělení zpráv na základě mapování.

určení přijímače a určení rozhraní – oba dohromady jsou běžně známé jako logické směrování. Dohoda odesílatele a dohoda příjemce-oba společně jsou běžně známé jako Dohoda o spolupráci.

systémová Krajina

adresář SAP System Landscape (SLD) je centrálním poskytovatelem informací v systémovém prostředí. Na webové stránce najdete následující odkazy:

1. technický systém-technické systémy jsou aplikační systémy, které jsou nainstalovány ve vašem systémovém prostředí.
2. Business System-obchodní systémy jsou logické systémy, které fungují jako odesílatelé nebo přijímače v rámci PI. Business Systems má závislost one-to-one s přidruženým technickým systémem.
3. produkty a komponenty-jedná se o informace o všech dostupných produktech a součástech SAP, včetně jejich verzí. Pokud jsou v systémovém prostředí nějaké produkty třetích stran, jsou zde také registrovány.

SLD bude vypadat podobně jako níže:

obrázek 11-systémová Krajina

produkty a komponenty se běžně nazývají informace o komponentách

technický systém a obchodní systém se běžně nazývají popis krajiny.

obchodní systém lze konfigurovat jako integrační server nebo aplikační systém.

1. integrační Server-integrační server provádí pouze integrační logiku nakonfigurovanou v integračním nástroji Builder. Mohou být také identifikovány jako kroky potrubí. Přijímá zprávu XML, určuje přijímač, provádí mapování a směruje zprávu XML do odpovídajících systémů přijímače. Takto nakonfigurovaný integrační motor je identifikován jako centrální nakonfigurovaný integrační motor.
2. aplikační systém-aplikační systém neprovede integrační logiku. To zase volá integrační server, aby v případě potřeby provedl integrační logiku. Působí jako odesílatel nebo příjemce zpráv XML. Aplikační systém s lokálním integračním motorem tedy vyžaduje, aby integrační server provedl integrační logiku.

jako integrační Server lze nakonfigurovat pouze jednoho klienta systému SAP.

následující informace jsou extrahovány ze SLD do ESR a DIR

1. informace o komponentě se používají v ESR k definování produktu a obchodní systém SWCV
2. se používá v adresáři pro definování odesílatele a příjemce zpráv

konfigurace a monitorování

je to centrální vstupní bod pro účely monitorování. To vám dává možnost navigace k monitorovacím funkcím integračního motoru, stejně jako integrace se systémem správy výpočetního centra (CCMS) a infrastrukturou monitorování procesů (PMI) SAP.

konfigurace a monitorování budou vypadat podobně jako níže:

obrázek 13-konfigurace a monitorování

s konfigurací a monitorováním jsou podporovány následující monitorovací funkce:

1. monitorování komponent-monitorování různých komponent SAP PI (části Java a ABAP).
2. monitorování zpráv-sledování stavu zpracování zpráv v komponentě SAP PI a při detekci a analýze chyb.
3. end-to-end monitoring-monitorování životního cyklu zprávy z hlediska SAP PI.
4. monitorování výkonu-statistiky o různých aspektech výkonu SAP PI jsou přístupné prostřednictvím RWB. Zde můžete vybrat a agregovat údaje o výkonu, například podle atributů komponenty, časového rozsahu nebo zprávy.
5. Správa indexů-správou a sledováním indexování zpráv na komponentu SAP PI povolíte vyhledávání zpráv založené na indexu, které můžete použít při monitorování zpráv. Tento druh vyhledávání zpráv vám nabízí vylepšená kritéria výběru, včetně atributů zpráv specifických pro adaptér a výrazů nebo frází z užitečného zatížení zprávy.
6. Alert configuration-pomocí Alert Framework, centrální monitorování v PI může být poskytnuta se všemi chybami hlášených během zpracování zpráv v ABAP a Java. To umožňuje lepší reakci na takové chyby jak v běhu ABAP, tak v Adaptérovém motoru založeném na Javě. Za tímto účelem je výstražný rámec opatřen pravidly založenými na určitých událostech a na informacích z záhlaví protokolu zprávy PI. Tato pravidla určují, zda jsou výstrahy odesílány nebo ne. Pokud je upozornění odesláno, může být použito pro analýzu chyb.
7. Alert inbox-schránka upozornění je specifická pro uživatele a zobrazuje všechna upozornění pro každý server upozornění, který byl vygenerován na základě konfigurace výstrahy.
8. Cache monitoring-cache monitoring zobrazuje objekty, které jsou aktuálně v runtime cache. Různé objekty mezipaměti jsou monitorovány v závislosti na příslušné instanci mezipaměti.

synchronní vs. asynchronní komunikace

proces může být definován jako synchronní nebo asynchronní.

• synchronní proces je vyvolán operací požadavku/odpovědi a výsledek procesu je okamžitě vrácen volajícímu prostřednictvím této operace.
• asynchronní proces je vyvolán jednosměrnou operací a výsledek a případné chyby jsou vráceny vyvoláním jiných jednosměrných operací. Výsledek je vrácen volajícímu pomocí operace zpětného volání.

ve světě počítačů neexistuje asynchronní komunikace. Veškerá komunikace mezi dvěma systémy probíhá vždy prostřednictvím volání metody (request/response operation). Tak jak to uděláme asynchronní? Odpověď spočívá v zavedení třetího systému mezi volanou a funkcí volajícího.

Předpokládejme, že existují dva systémy-A A B. Veškerá komunikace mezi A A B probíhá prostřednictvím volání metody, a proto jsou synchronní. Představujeme třetí systém mezi A A B a nazýváme jej intermediární systém-i. komunikace mezi A a I probíhá prostřednictvím volání metody a podobně mezi I A B je také prostřednictvím volání metody. Ale komunikace mezi A A B může být nazývána asynchronní, protože A nemusí čekat na odpověď od B.

Toto je základ asynchronní komunikace a jaký je tento přechodný systém? To je fronta. A se nazývá odesílatel a B se nazývá přijímač. Zpráva z A je nejprve přidána do fronty a poté je znovu vytažena z fronty a odeslána do B. odpověď z B dosáhne A podobným způsobem. V určité situaci, obchodní požadavek vyžaduje, aby zprávy byly doručeny do B ve stejném pořadí, v jakém jsou spouštěny z a.v takovém případě se řídíme zásadami first-in a first-out. Pokud takové požadavky neexistují, odesílají se zprávy z fronty do B v libovolném pořadí.

asynchronní komunikací dosáhneme zaručeného doručení, tj. systém B není k dispozici, když systém a odešle zprávu. Zpráva je přidána do fronty a zůstane tam, dokud B není k dispozici. Jakmile je B K dispozici, zpráva je stažena z fronty a odešle do B.

, takže můžeme klasifikovat naši komunikaci se zprávou třemi způsoby:

1. synchronní
2. asynchronní s řádem neudržovaným
3. asynchronní s řádem udržovaným

v PI je identifikujeme jako: synchronní – BE (nejlepší úsilí), asynchronní s řádem neudržovaným-EO (přesně jednou), asynchronní s řádem udržovaným-EOIO(přesně jednou v pořadí).

potvrzení

potvrzení je kořenem asynchronní komunikace. Proč?

pro synchronní komunikaci volá systém a systém B a pokud B neodesílá odpověď, proces selhal. Ale v asynchronní komunikaci systém a volá systém I a systém i volá systém B. předpokládejme tedy, že komunikace mezi A a I je úspěšná, ale mezi I A B selže. Jak by si měl uvědomit, že dodávka do B selhala? To je realizováno potvrzením, které je odesláno zpět do a po B stejnou cestou jako zpráva z A do B. Pokud potvrzení z B nedorazí do A, pak se domnívá, že proces selhal a zprávu odešle znovu.

zatímco jsme diskutovali o asynchronní komunikaci v PI, použili jsme termín – „přesně jednou“ pro EO i EOIO. Přesně jednou znamená, že jednou Doručená zpráva nemůže být doručena znovu. K dosažení tohoto cíle existuje potvrzení pro každou zprávu odeslanou z bodu A do bodu B. na konci komunikace leží adaptéry. Adaptéry tedy musí podporovat potvrzení.

všechny adaptéry poskytují systémové potvrzení i.e.potvrzení o doručení. Tyto adaptéry, které podporují synchronní komunikační podporu aplikace-potvrzení kromě potvrzení systému.

takže v PI následuje typ potvrzení

1. systémové potvrzení-systémové potvrzení používané runtime prostředím k potvrzení, že asynchronní zpráva dosáhla přijímače.
2. potvrzení aplikace-potvrzení aplikace slouží k potvrzení, že asynchronní zpráva byla úspěšně zpracována na přijímači.

volání vzdálené funkce

při práci v PI narazíte na termín-RFC. Co jsou zač? Pro navázání komunikace mezi dvěma systémy SAP, tj. R / 3 A PI, vytvoříme cíl RFC. Je konfigurován podle následujícího

1. Typ připojení
2. IP adresa a Port přijímače

Typ připojení udává typ připojení systému, tj.

cíl RFC, který vytvoříme, je klasifikován podle požadovaného způsobu komunikace, tj. zda by měla podporovat synchronní nebo asynchronní komunikaci.

1. pro synchronní komunikaci-synchronní RFC
2. pro asynchronní komunikaci s udržovaným řádem-transakční RFC
3. pro asynchronní komunikaci s udržovaným řádem-fronty RFC

jsou identifikovány SRFC, tRFC a qRFC.

případové studie-1

předpokládají, že jste ve třídní místnosti a je v ní 10 studentů. Instruktor pak požádá každého studenta, aby mu připravil následující osobní údaje a uložil je do XML souboru. Podrobnosti jsou následující:

1. Student ID
2. jméno
3. mobilní
4. E-Mail
5. pohlaví

k dispozici bude 10 souborů a soubory jsou pojmenovány jako cv_1,2,3….10. Soubory jsou uloženy do zdrojového adresáře. Pro testovací účely jsou vytvořeny následující adresáře:

zdrojový adresář: c:\ibm\sap\training\input

adresář archivu: c:\ibm\sap\training\archive

adresář chyb: c:\ibm \ sap \ training \ error

cílový adresář: c:\ibm\sap\training\target

budete vyzváni k vytvoření scénářů v SAP PI, které budou číst zdrojové soubory ze zdrojového adresáře a zapisovat je do cílového adresáře. Jakmile je soubor úspěšně přečten ze zdrojového adresáře, měl by být přesunut do adresáře archivu a pokud soubor nelze přečíst kvůli nějaké chybě, tj. formát xml není zachován, měl by být přesunut do adresáře chyb. Soubory přesunuty do archivu, chyba nebo cílový adresář by měl mít časové razítko připojit k názvu souboru.

1. tj. název souboru + <časové razítko>.

Lekce-1

připravte scénář pro čtení jednoho souboru, tj. souboru cv_1.xml ze zdrojového adresáře a zapište jej do cílového adresáře. Název cílového souboru by měl být také cv_1.xml s časovým razítkem připojit k názvu.

Lekce-2

připravte scénář pro čtení všech souborů ze zdrojového adresáře a jejich zápis do cílového adresáře. Podobně cílové soubory by měly být také pojmenovány jako cv_1, 2 ..xml s časovým razítkem připojit ke každému z nich.

Lekce-3

instruktor vás pak požádá, abyste k datům přidali následující validaci.

1. mobilní číslo by mělo mít 10 číselných číslic-pokud mobilní číslo není 10 číslic, nahraďte jej „chyba“
2. e-mail by měl mít jeden znak “ @ „a jeden“.’znak-pokud e-mail nemá‘ @ ‚nebo‘.’znak, pak jej nahraďte ‚chyba‘

před spuštěním scénáře v některých zdrojových souborech upravte mobilní telefon a e-mail tak, aby byly podle výše uvedené logiky chybné.

Lekce-4

připravte scénář pro čtení všech zdrojových souborů a jejich klasifikaci podle jejich pohlaví. Soubory pro muže budou zapsány do jednoho adresáře a pro dámy do jiného adresáře. Pro výše uvedený účel jsou vytvořeny dva adresáře:

cílový adresář pro muže: c:\ibm\sap\training\target\men

cílový adresář pro ženy: c:\ibm \ sap \ training \ target \ women

Předpokládejme, že ve třídě je 6 mužů a 4 ženy, pak pokud jsou všechny zdrojové soubory úspěšně přečteny, měl by mít cílový adresář pro muže 6 souborů a cílový adresář pro ženy 4 soubory.

případové studie-2

instruktor vás poté požádá, abyste připravili jeden soubor s osobními údaji každého studenta v samostatných segmentech.

Lekce-5

napište scénář, který přečte tento soubor a vytvoří 10 cílových souborů, kde by každý soubor měl odpovídat osobním údajům každého zaměstnance. Cílové soubory by měly být pojmenovány jako cv_<emp_ID>_<časové razítko>

Lekce-6

upravte výše uvedený scénář tak, aby vytvořil 2 cílové soubory místo 10, kde jeden cílový soubor pro muže a jiný cílový soubor pro dámy. Cílový soubor pro muže by měl mít 6 segmenty pro 6 muži a cílový soubor pro dámy by měl mít 4 segmenty pro 4 ženy.

cílové soubory by měly být pojmenovány jako

pro muže-men_ <časové razítko>

pro dámy-women_<časové razítko>

Případová studie -3

stejně jako případová studie-1, instruktor požádá každého studenta, aby připravil své osobní údaje a uložil je do souboru XML. K dispozici bude 10 souborů. Soubory jsou uloženy ve zdrojovém adresáři.

Lekce-7

připravte scénář pro čtení všech zdrojových souborů ze zdrojového adresáře a vytvoření jednoho jediného souboru v cílovém adresáři. Zobrazí se název cílového souboru.xml s časovým razítkem se připojí k názvu souboru. Cílový soubor bude mít všechny podrobnosti o každém zdrojovém souboru jako podsegment.

Lekce-8

připravte scénář pro čtení celých zdrojových souborů ze zdrojového adresáře a vytvořte dva soubory v cílovém adresáři-jeden pro muže a druhý pro dámy. Pro 6 muži, soubor mužů by měl mít šest segmentů s podrobnostmi každého muže a pro 4 ženy, podobně by měly být 4 segmenty s podrobnostmi každé dámy.

Případová studie-4

instruktor nyní žádá každého ze studentů, aby připravil další soubor podrobností, které se budou skládat z jeho následujících akademických údajů:

1. ID studenta
2. název školy
3. název školy
4. Název Katedry
5. rok přijetí

bude 10 souborů a soubory budou pojmenovány jako ad_1, 2, 3….10. Soubory jsou uloženy do zdrojového adresáře. Takže každý student bude mít nyní pár souborů-jeden pro osobní údaje a druhý pro akademické podrobnosti. Dva soubory spolu souvisejí s ID studenta. Vstupní adresář se nyní skládá z 10 osobních souborů a 10 akademických souborů.

Lekce-9

budete vyzváni k vytvoření scénáře, který vybere zdrojové soubory a zpracuje je v páru. Scénář vygeneruje 10 cílových souborů. Každý cílový soubor se bude skládat z osobních a akademických údajů studenta v samostatných segmentech. Cílové soubory budou pojmenovány jako res_1, 2, 10.

cílové soubory budou vypadat:

Lekce-10

poté budete požádáni o změnu ID studenta v některých souborech tak, aby neměly odpovídající akademické nebo osobní soubory a naopak. Scénář by měl běžet, a pokud to našel nějaké soubory, které nemá odpovídající odpovídající soubor pak proces by měl skončit po určité době tj 2 min a tyto soubory budou přesunuty do adresáře chyb a tam bude žádné odpovídající cílové soubory pro ně.