SAP PI för nybörjare

mål

syftet med denna handledning är att få dig att förstå – vad är SAP-processintegration? Vi kommer inte att gå in i ämnet nitty-gritty men vi kommer att diskutera om arkitekturen och olika funktioner i SAP PI. Vi kommer bara att täcka de grundläggande funktionerna och kommer att undvika att diskutera alla funktioner i denna handledning.

Nästa finns det en uppsättning fallstudier som ger dig en uppfattning om branschens utnyttjande av SAP PI. När du blir mer bekant med ämnet bör du försöka lösa dem. Testfallen är förberedda på ett sätt så att det tar dig ner i ämnet från enkla till fler komplex med varje lektion och ger dig en övergripande uppfattning om ämnet.

vad är SAP ERP?

för alla företag – stora eller små, dessa är de vanliga affärsfunktioner som den måste utföra, dvs materialhantering, försäljning och Distribution, Ekonomi, mänskliga resurser etc. Det finns mycket programvara på marknaden som används av branschen. Du kommer att märka den enklaste – tellermaskinen genererar försäljningsfaktura om du besöker en liten butik till ett nätverk av datorer i en stor butik, hotell etc som arbetar på en ERP.

Enterprise Resource Planning dvs ERP är ett effektivt tillvägagångssätt som de flesta företag implementerar för att förbättra sin produktivitet och prestanda. SAP ERP är SAP AG: s Enterprise Resource Planning, en integrerad mjukvarulösning som innehåller organisationens viktigaste affärsfunktioner. De grundläggande funktionerna dvs HR, MM, SD, FICO etc kallas affärsmoduler i SAP. SAP bygger dem som produkter och säljer dem på marknaden. Det finns ytterligare två moduler som inte stöder affärsfunktioner direkt men används för presentation och integration. Den förstnämnda kallas EP (Enterprise Portal) och den senare kallas PI (Process Integration). Alla affärsmoduler utvecklas i ABAP medan EP och PI utvecklas mestadels i Java. Dessa moduler är inte körbara men de måste distribueras i en applikationsserver, dvs ABAP – Webbapplikationsserver för ABAP-moduler och Java-Webbapplikationsservrar för Java-moduler.

det finns några punkter vi borde veta innan vi hoppar in i ämnet.

• SAP står för system, applikationer och produkter inom databehandling.

• SAP AG är ett tyskt multinationellt mjukvaruföretag som gör företagsprogramvara för att hantera affärsverksamhet och kundrelationer. SAP ERP är företagets Enterprise Resource Planning, en integrerad mjukvarulösning som innehåller organisationens viktigaste affärsfunktioner.

• SAP NetWeaver Process Integration (SAP PI) är SAP enterprise application integration (EAI) – programvara, en komponent i NetWeaver-produktgruppen som används för att underlätta informationsutbytet mellan ett företags interna programvara och system och externa parter.

äldre System

medan du implementerar SAP ERP i en stor företagsetablering, konstateras att inte alla avsnitt kan föras under SAP ERP. Många av affärsavsnitten kan ha egna egna verktyg som är mycket komplexa och kanske inte går att byta ut. De löper parallellt med SAP-systemet. De kallas äldre system. Då blir det nödvändigt att integrera mellan SAP-systemen och ett sådant existerande icke-SAP-System. Det är här SAP PI spelar in.

Varför behöver vi SAP PI förutom äldre system, i en stor företagsetablering, består SAP ERP inte av ett enda system utan flera integrerade system, dvs CRM, SRM och FICO etc. För att hantera sådana komplexiteter introducerade SAP processintegration en plattform för att ge en enda integrationspunkt för alla system utan att röra befintliga komplexa nätverk av äldre system. Detta är en kraftfull middleware från SAP för att ge sömlös slut-till-slut-integration mellan SAP och icke-SAP-applikationer inom och utanför företagsgränsen. SAP PI stöder B2B såväl som A2A-utbyten, stöder synkron och asynkron meddelandeutbyte och inkluderar inbyggd motor för att designa och genomföra integrationsprocesser.

arkitektur av SAP PI

SAP PI består av en nav-och ekerstruktur; ekrarna ansluter till externa system medan navet utbyter meddelanden mellan dem. Källsystemet är känt som avsändarsystemet och målsystemet är känt som mottagarsystemet. PI är inte en enda komponent, utan snarare en samling komponenter som arbetar tillsammans flexibelt för att implementera integrationsscenarier. Arkitekturen innehåller komponenter som ska användas vid designtid, vid konfigurationstid och vid körtid.

vi kan dela SAP PI i flera områden

1. Integration Server
2. Integration Builder
3. Systemlandskap
4. konfiguration och övervakning

Integration Server är den centrala processmotorn för SAP PI. Alla meddelanden behandlas här på ett konsekvent sätt. Den består av tre separata motorer

1. Integration Engine
2. Adapter Engine
3. Business Process Engine

Integration engine kan anses vara navet och Adapter motorn talade. När det gäller Affärsprocessmotorn kommer jag att förklara det senare.

Integration Builder är en klient-server ram för åtkomst och redigering integrationsobjekt och den består av två relaterade verktyg:

1. Enterprise Service Repository-för att designa och utveckla objekt som ska användas i scenarier
2. Integrationskatalog – för att konfigurera ESR-objekten för att utveckla scenarier

två tillsammans byggde vi integrationsprocesser som vanligtvis kallas scenarier.

Systemlandskapet är ett centralt arkiv med information om programvara och system i datacenter och förenklar administrationen av ditt systemlandskap.

i Konfiguration och övervakning kan vi övervaka meddelanden och Adaptrar.

Single stack och Dual stack

när PI först släpptes byggdes inte alla komponenter på samma plattform. Integration Engine och Business Process Engine byggdes i ABAP medan Adapter Engine, Integration Builder, SL, CM och Mapping Runtime byggdes i Java. Så PI behöver både Java och ABAP-miljön för att köra och är känd som dual stack.

ABAP Stack	Java Stack
integrationsmotor Affärsprocessmotor Integrationsbyggare	Enterprise Service Repository Integrationskatalog Runtime Workbench System landskap katalog Adapter Motor kartläggning Runtime

men i den senare versionen är alla komponenter byggda i Java. Några av dual-stack-komponenterna dispenseras antingen eller modifieras för att fungera på Java-stacken. Så PI behöver bara Java-miljön för att köra och är känd som single stack.

det finns för-och nackdelar mellan de två staplarna men de omfattas inte av denna handledning.

Integration Motor

Integrationsmotorn ansvarar för centrala Integrationsservertjänster, dvs rörledningssteg-routing och kartläggning. Om källmeddelandestrukturen skiljer sig från målmeddelandestrukturen anropar integrationsmotorn Mappningens körtid, där källstrukturen konverteras till målstrukturen. Kartläggningen Runtime är baserad på Java stack. Integrationsmotorn kan också använda ett ABAP-program för konverteringen, som är baserat på ABAP-stacken.

ett meddelande kan vara av två typer

1. synkron – har både begäran-svarsdelen
2. asynkron – har antingen begäran eller svarsdelen endast

i PI representeras meddelandet av ett gränssnitt.

gränssnitt -> struktur av meddelandet i XML – format + riktning

baserat på ovanstående kriterier finns det tre typer av gränssnitt

1. utgående gränssnitt – Anslut till avsändarsystemet
2. inkommande gränssnitt – Anslut till mottagarsystemet
3. Abstrakt gränssnitt-Anslut till BPE

när vi konfigurerar integrationslogik (scenario) i SAP PI enligt våra affärskrav är det integrationsmotorn som utför den konfigurationen stegvis. Pipeline är termen som används för att hänvisa till alla steg som utförs under behandlingen av ett XML-meddelande. Rörledningsstegen består av följande:

1. Mottagaridentifiering-bestämmer systemet som deltar i utbytet av meddelandet.
2. Gränssnittsbestämning – Bestäm vilket gränssnitt som ska ta emot meddelandet.
3. meddelandedelning – om mer än en mottagare hittas kommer PI att initiera nytt meddelande för varje mottagare.
4. Meddelandemappning – mappning för att omvandla källmeddelandet till destinationsmeddelandeformat.
5. teknisk Routing – binda en specifik destination och ett protokoll till meddelandet.
6. Samtalsadapter – skicka det transformerade meddelandet till adaptern eller en proxy.

Adaptermotor

du måste ha märkt tidigare att integrationsmotorn endast hanterar meddelanden i XML-SOAP-protokollet. Men vad händer om vi har en avsändare och en mottagare affärssystem där uppgifterna inte är i samma format. Vi använder de olika adaptrarna i Adaptermotorn för att konvertera XML-och HTTP-baserade meddelanden till det specifika protokollet och formatet som krävs av dessa system, och vice versa.

som vi har diskuterat tidigare är SAP PI ett nav och ekerstruktur där Adaptermotorn kan betraktas som Eker. Vi använder Adaptermotorn för att ansluta Integrationsmotorn (navet) till de externa systemen. Adapterramen är grunden för Adaptermotorn. Adapterramen är baserad på SAP J2EE-motorn (som en del av SAP Web Application Server) och J2EE Connector Architecture (JCA). Adapterramen ger gränssnitt för konfiguration, hantering och övervakning av adaptrar.

i ett dual stack-system var de flesta adaptrarna baserade på Java-stacken och spärrade två adaptrar som är baserade på ABAP-stacken.

Java Stack	RFC adapter, SAP Business Connector adapter, fil / FTP adapter, JDBC adapter, JMS adapter, TVÅLADAPTER, Marketplace Adapter, post adapter, RNIF adapter, CIDX adapter
ABAP stack	IDOC-adapter och HTTP-adapter

när SAP PI flyttade från dual stack till single stack blev dessa två adaptrar en del av Java-stacken. Den modifierade adaptermotorn är känd som Advance Adapter Engine och de två adaptrarna kallas IDOC_AAE adapter respektive HTTP_AAE adapter.

Affärsprocessmotor

Affärsprocessmotorn ansvarar för att genomföra och fortsätta integrationsprocesser.

BPM står för cross-component Business Process Management eller ccBPM och kallas också integrationsprocess. En integrationsprocess är en körbar, tvärsystemprocess för bearbetning av meddelanden. I en integrationsprocess definierar du alla processteg som ska utföras och de parametrar som är relevanta för att styra processen. Business Process Management tillhandahåller SAP Exchange-infrastruktur med följande funktioner:

1. status-fullständig meddelandebehandling: statusen för en integrationsprocess kvarstår på Integrationsservern.
2. du kan också använda korrelationer för att skapa semantiska relationer mellan meddelanden.
3. du implementerar integrationsprocesser när du vill definiera, styra och övervaka komplexa integrationsprocesser som sträcker sig över företags-och applikationsgränser, dvs samla/slå samman, dela, Multicast

vid körning utför Affärsprocessmotorn integrationsprocesserna. Integrationsprocessen kan bara skicka och ta emot meddelanden med abstrakta gränssnitt.

Bygg ett scenario i SAP PI

vi börjar från Hemsidan om vi måste bygga ett scenario i PI.

hemsidan kommer att likna som anges nedan:

Figur 6-hemsida för SAP PI Java Stack

hemsidan har hyperlänkar till följande 4 arbetsområden

1. Enterprise Services Repository (ESR)
2. Integration Directory (ID)
3. system landskap (SL)
4. konfiguration och övervakning (CM)

varje hyperlänk öppnar en applikation. Alla dessa fyra är Java-applikation. ESR och ID är swing-applikationer. De startas från webbläsaren baserat på JNLP. Så för första gången tar det längre tid eftersom det hämtar hela biblioteksfilen. Men från andra gången och framåt tar det mindre tid att starta. SL och CM är rena webbapplikationer och körs i webbläsaren.

Enterprise Services Repository

här designar och skapar vi objekt som ska användas i skapandet av ett integrationsscenario. Dataflödet i PI kommer att likna det som visas nedan:

vi hittar alternativet att utforma följande

1. gränssnittsobjekt-servicegränssnitt, meddelandetyp, datatyp
2. Kartläggningsobjekt-Operationskartläggning och Meddelandekartläggning
3. integrationsprocesser

PI använder integrationsförvar för att utforma meddelandestruktur för både avsändare och mottagarsystem och utveckla ett gränssnittsmeddelande med motsvarande meddelandestrukturer som fungerar som en punkt för interaktion med omvärlden. Datatyp och meddelandetyp används för att förenkla och modularisera utformningen av ett komplext gränssnitt.

Operation Mapping möjliggör omvandling av källstruktur till målstruktur när de två strukturerna är olika. Men om källan och målstrukturen är desamma kan operationskartläggningen avges. I likhet med service interface används meddelandekartläggning för att förenkla och modularisera utformningen av en komplex operationskartläggning. Meddelande kartläggning kan genomföras på 4 sätt

1. grafisk kartläggning
2. Java kartläggning
3. XSLT kartläggning
4. ABAP kartläggning

grafisk kartläggning är den mest använda eftersom det tillåter utvecklare att kartlägga attribut för båda strukturerna grafiskt för att skicka data med hjälp av servicegränssnitt. För de andra tre måste vi utveckla kartläggningen genom att skriva kod. Om det är en enda stackserver, kommer ABAP-mappningen inte att vara tillgänglig.

det finns andra områden också, men de omfattas inte av denna handledning.

Integrationskatalog

här gör vi rörledningsstegen genom att konfigurera de ESR-objekt som skapats tidigare. Dessa steg utförs av integrationsmotorn under körning.

innan vi börjar konfigurationen måste vi skapa/importera följande objekt i DIR.

1. Service-Business System / Business Service/ integrationsprocess
2. kommunikationskanal

en tjänst gör att du kan adressera en avsändare eller mottagare av meddelanden. Beroende på hur du vill använda tjänsten kan du välja mellan följande typer av tjänster.

1. affärssystem – om du vill adressera ett visst affärssystem som avsändare eller mottagare av meddelanden väljer du den här typen av tjänst. Ett affärssystem är ett verkligt applikationssystem i ett systemlandskap.
2. företagstjänst – om du vill adressera en abstrakt affärsenhet som avsändare eller mottagare av meddelanden, välj den här typen av tjänst. En företagstjänst definieras inte i systemlandskapet.
3. integrationsprocess Service – Om du vill adressera en integrationsprocess som avsändare eller mottagare av meddelanden, välj den här typen av tjänst. Vid körning styrs dessa integrationsprocesser av meddelanden och kan själva skicka meddelanden.

kommunikationskanal bestämmer inkommande och utgående bearbetning av meddelanden. Meddelandena konverteras från inbyggt format till soap-xml-specifikt meddelandeformat och vice versa via adaptern. Generellt finns det två typer av kommunikationskanal i ett scenario

1. Avsändarkommunikationskanal
2. Mottagarkommunikationskanal

du måste tilldela en kommunikationskanal till en tjänst. Beroende på om tjänsten adresseras som avsändare eller mottagare av meddelanden, har den tilldelade kommunikationskanalen rollen som antingen en avsändare eller en mottagarkanal och måste konfigureras i enlighet därmed. Du kan inte tilldela en kommunikationskanal till en integrationsprocess tjänst.

rörledningsstegen skapas genom att skapa följande 4-konfiguration i DIR

vi hittar följande alternativ:

1. Avsändaravtal
2. Mottagaravtal
3. Gränssnittsbestämning
4. Mottagaravtal

Avsändaravtal definierar hur en avsändares meddelande ska omvandlas så att det kan behandlas av Integrationsservern. Den består av följande

1. Avsändarkomponent
2. Avsändargränssnitt
3. Avsändarkommunikationskanal

Avsändaravtal liknar primärnyckel i tabellen. Det kan inte finnas två liknande avsändaravtal i ett landskap.

Mottagaravtal definierar hur meddelandet ska omvandlas så att det kan behandlas av en mottagare. Den består av

1. Avsändarkomponent
2. Mottagarkomponent
3. Mottagargränssnitt
4. Mottagarkommunikationskanal

du använder en mottagarbestämning för att ange vilka mottagare ett meddelande ska skickas till. Du har möjlighet att definiera villkor för vidarebefordran av meddelandet till mottagarna. Den består av

1. Avsändarkomponent
2. Avsändargränssnitt
3. Mottagarkomponent

Mottagarbestämning är av två typer – Standard eller utökad, beroende på om du vill ange mottagaren manuellt eller dynamiskt genom en mappning vid körning.

du använder en gränssnittsbestämning för att ange vilket inkommande gränssnitt för en mottagare; meddelandet ska vidarebefordras till. Du kan också ange vilken gränssnittsmappning från Integrationsförvaret som ska användas för att bearbeta meddelandet, dvs. om avsändaren och mottagargränssnittet inte har samma format finns det en operativ kartläggning för att ändra formatet. Du definierar en gränssnittsbestämning för en avsändare, ett utgående gränssnitt och en mottagare. Den består av

1. Avsändarkomponent
2. Avsändargränssnitt
3. Mottagarkomponent
4. Mottagargränssnitt

Gränssnittsbestämning är av två typer – Standard eller förbättrad, beroende på om du vill ange mottagargränssnittet manuellt eller genom mappningsbaserad meddelandedelning.

mottagare bestämning och gränssnitt bestämning – de två tillsammans är allmänt känd som den logiska routing. Avsändaravtal och Mottagaravtal – de två tillsammans är allmänt kända som samarbetsavtalet.

Systemlandskap

SAP System Landscape Directory (SLD) är den centrala informationsleverantören i ett systemlandskap. På webbsidan hittar du följande länkar:

1. tekniska System-tekniska system är applikationssystem som installeras i ditt systemlandskap.
2. affärssystem – affärssystem är logiska system som fungerar som avsändare eller mottagare inom PI. Affärssystem har ett-till-ett beroende av det tillhörande tekniska systemet.
3. produkter och Komponenter – det här är information om alla tillgängliga SAP-produkter och komponenter, inklusive deras versioner. Om det finns några tredjepartsprodukter i systemlandskapet registreras de också här.

SLD kommer att likna som anges nedan:

Figur 11 – Systemlandskap

produkter och komponenter kallas ofta Komponentinformationen

tekniskt System och affärssystem kallas vanligtvis Landskapsbeskrivningen.

ett affärssystem kan konfigureras som en integrationsserver eller applikationssystem.

1. integrationsserver – Integrationsservern kör endast integrationslogik konfigurerad i Integrationsbyggaren. De kan också identifieras som Rörledningssteg. Den tar emot XML-meddelande, bestämmer mottagaren, kör mappningarna och dirigerar XML-meddelandet till motsvarande mottagarsystem. Således konfigurerad integrationsmotor identifieras som Central konfigurerad integrationsmotor.
2. applikationssystem – Applikationssystemet kommer inte att köra integrationslogiken. Det kallar i sin tur integrationsservern att utföra integrationslogiken om det behövs. Det fungerar som avsändare eller mottagare av XML-meddelanden. Så, Applikationssystemet med en lokal integrationsmotor kräver att Integrationsservern utför integrationslogiken.

endast en klient i SAP-systemet kan konfigureras som integrationsserver.

följande information extraheras från SLD till ESR och DIR

1. komponentinformation används i ESR för att definiera produkten och SWCV
2. affärssystem används i katalogen för att definiera avsändare och mottagare av meddelanden

konfiguration och övervakning

det är den centrala ingångspunkten för övervakningsändamål. Detta ger dig möjlighet att navigera till Integrationsmotorns övervakningsfunktioner, samt integration med Computing Center Management System (CCMS) och Process Monitoring Infrastructure (PMI) för SAP.

konfigurationen och övervakningen kommer att likna som anges nedan:

figur 13-konfiguration och övervakning

med konfiguration och övervakning följande övervakningsfunktioner stöds:

1. Component monitoring-övervakning av olika SAP PI komponenter (Java och ABAP delar).
2. Message monitoring – spåra meddelandehantering status inom en SAP PI komponent och på feldetektering och analys.
3. End-to-end – övervakning-övervakning av en meddelandelivscykel från SAP PI-synvinkel.
4. prestandaövervakning – statistik om olika prestandaaspekter av SAP PI kan nås via RWB. Här kan du välja och aggregera prestandadata, till exempel efter komponent, tidsintervall eller meddelandeattribut.
5. Indexadministration – genom att administrera och övervaka indexeringen av meddelanden per SAP PI-komponent aktiverar du en indexbaserad meddelandesökning som du kan använda i meddelandeövervakning. Den här typen av meddelandesökning ger dig förbättrade urvalskriterier, inklusive adapterspecifika meddelandeattribut och termer eller fraser från meddelandets nyttolast.
6. Alert configuration – genom att använda Alert Framework kan central övervakning i PI förses med alla fel som rapporterats under meddelandebehandling i ABAP och Java. Detta möjliggör en förbättrad reaktion på sådana fel i både ABAP runtime och den Java-baserade Adaptermotorn. För detta ändamål är Varningsramen försedd med regler baserade på vissa händelser och på information från rubriken i PI-meddelandeprotokollet. Dessa regler avgör om varningar skickas eller inte. Om en varning skickas kan den användas för felanalys.
7. Varningsinkorg – varningsinkorgen är användarspecifik och visar alla varningar för varje varningsserver som har genererats baserat på varningskonfigurationen.
8. Cache – övervakning-cache-övervakning visar objekt som för närvarande finns i runtime-cachen. Olika cacheobjekt övervakas beroende på den berörda cacheinstansen.

synkron vs. asynkron kommunikation

en process kan definieras som antingen synkron eller asynkron.

• en synkron process åberopas av en begäran/svar operation, och resultatet av processen returneras till den som ringer omedelbart via denna operation.
• en asynkron process anropas av en envägsoperation och resultatet och eventuella fel returneras genom att anropa andra envägsoperationer. Resultatet returneras till den som ringer via en återuppringningsoperation.

i datorvärlden finns det ingen asynkron kommunikation. All kommunikation mellan två system sker alltid via metodsamtal (begäran/svarsoperation). Så hur gör vi det asynkront? Svaret ligger med införandet av ett tredje system mellan den uppringda och den uppringande funktionen.

Antag att det finns två system – A och B. All kommunikation mellan A och B sker via ett metodsamtal och därmed är de synkrona. Vi introducerar ett tredje system mellan A och B och kallade det Mellansystemet – I. kommunikationen mellan A och I sker via metodsamtal och på samma sätt mellan i och B sker också via metodsamtal. Men kommunikationen mellan A och B kan kallas asynkron eftersom A inte behöver vänta på svaret från B.

detta är grunden för asynkron kommunikation och vad är detta mellanliggande system? Det är kön. A kallas avsändaren och B kallas mottagaren. Meddelande från A läggs först till i kön och sedan dras det igen från kön och skickas till B. svaret från B når A på liknande sätt. I vissa situationer behöver affärskravet att meddelandena ska levereras till B i samma ordning som de utlöses från A. I så fall följer vi en första-in-och första-ut-policy. Om det inte finns några sådana krav skickas meddelanden från kön till B i valfri ordning.

med asynkron kommunikation uppnår vi garanterad leverans, dvs System B är inte tillgängligt när System a skickar meddelandet. Meddelandet läggs till i kön och förblir där så länge B inte är tillgängligt. När B är tillgängligt dras meddelandet från kön och skickas till B.

så att vi kan klassificera vår meddelandekommunikation på tre sätt:

1. synkron
2. asynkron med order ej underhållen
3. asynkron med order underhållen

i PI identifierar vi dem som: synkron – vara (bästa ansträngning), asynkron med order ej underhållen – EO (exakt en gång), asynkron med order underhållen – EOIO (exakt en gång i ordning).

bekräftelse

bekräftelse är roten till asynkron kommunikation. Varför?

för synkron kommunikation anropar System a system B och om B inte skickar svaret misslyckades processen. Men i en asynkron kommunikation kallar System a System i och system i system B. så antar att kommunikationen mellan A och I är framgångsrik men mellan I och B misslyckas den. Hur ska A inse att leveransen till B har misslyckats? Detta realiseras genom en bekräftelse som skickas tillbaka till A av B via samma väg som meddelandet från A tog till B. Om bekräftelsen från B misslyckas med att komma fram till A anser A att processen har misslyckats och skickar meddelandet igen.

medan vi diskuterade om asynkron kommunikation i PI har vi använt termen – ’exakt en gång’ för både EO och EOIO. Exakt en gång betyder att ett meddelande som levereras en gång inte kan levereras igen. För att uppnå detta finns det en bekräftelse för varje meddelande som skickas från A till B. Det är adaptrarna som ligger i slutet av kommunikationen. Så adaptrarna måste stödja bekräftelse.

alla adaptrar tillhandahåller systembekräftelse i.e. leveransbekräftelse. De adaptrar som stöder synkron kommunikation stöder applikationsbekräftelse utöver systembekräftelsen.

så i PI är följande typen av bekräftelse

1. Systembekräftelse – systembekräftelser som används av runtime-miljön för att bekräfta att ett asynkront meddelande har nått mottagaren.
2. Programbekräftelse – programbekräftelser som används för att bekräfta att det asynkrona meddelandet har behandlats på mottagaren.

Fjärrfunktionssamtal

när du arbetar i PI kommer du att stöta på termen – RFC. Vad är de? För att upprätta kommunikation mellan två SAP-system, dvs en R/3 och PI, skapar vi RFC-destinationen. Den är konfigurerad av följande

1. Anslutningstyp
2. IP-adress och port för mottagaren

Anslutningstyp berättar vilken typ av systemanslutning dvs R/3, TCP/IP, Intern etc.

RFC-destinationen vi skapar klassificeras enligt det kommunikationssätt som krävs, dvs. oavsett om det ska stödja synkron eller asynkron kommunikation.

1. för synkron kommunikation – synkron RFC
2. för asynkron kommunikation med order ej underhållen – transaktionell RFC
3. för asynkron kommunikation med order underhållen-kö RFC

de identifieras av sRFC, tRFC och qRFC.

fallstudier – 1

Antag att du är i ett klassrum och det finns 10 studenter i det. Instruktören ber sedan varje elev att förbereda sina följande personuppgifter och spara dem i en XML-fil. Detaljerna är följande:

1. student-ID
2. namn
3. mobil
4. e-post
5. kön

det kommer att finnas 10 filer och filerna heter cv_1,2,3….10. Filerna sparas i källkatalogen. För teständamål skapas följande kataloger:

källkatalog: c:\ibm\sap\training\input

arkivkatalog: c:\ibm\sap\training\archive

felkatalog: c:\ ibm \ sap \ utbildning \ fel

målkatalog: c:\ibm\sap\training\target

du uppmanas att utveckla scenarier i SAP PI som läser källfilerna från källkatalogen och skriver dem till målkatalogen. När en fil har lästs från källkatalogen ska den flyttas till arkivkatalogen och om filen inte kan läsas för något fel, dvs xml-format som inte upprätthålls, ska den flyttas till felkatalogen. Filerna som flyttas till Arkiv, fel eller målkatalog ska ha en tidsstämpel som läggs till filnamnet.

1. dvs. filnamn + < tidsstämpel>.

Lektion-1

Förbered ett scenario för att läsa en enda fil, dvs fil cv_1.xml från källkatalogen och skriv den till målkatalogen. Målfilnamnet ska också vara cv_1.xml med tidsstämpeln Lägg till namnet.

Lektion-2

Förbered ett scenario för att läsa alla filer från källkatalogen och skriva dem till målkatalogen. På samma sätt bör målfilerna också namnges som cv_1, 2 ..xml med tidsstämpeln läggs till var och en av dem.

Lektion-3

instruktören ber er alla att lägga till följande validering till data.

1. mobilnumret ska ha 10 numeriska siffror – om mobilnumret inte är av 10 siffror, ersätt det med ’error’
2. e-postmeddelandet ska ha ett ’@’ tecken och ett ’.’tecken-om e-postmeddelandet inte har’ @ ’eller’.’tecken, ersätt det sedan med ’fel’

innan du kör scenariot, i några av källfilerna, ändra mobilen och e-postmeddelandet så att de är felaktiga enligt logiken ovan.

Lektion-4

Förbered ett scenario för att läsa alla källfiler och klassificera dem efter deras kön. Filerna för män kommer att skrivas i en katalog och för damerna till en annan katalog. Två kataloger skapas för ovanstående ändamål:

målkatalog för män: c:\ibm\sap\training\target\men

målkatalog för kvinnor: c:\ ibm \ sap \ training \ target \ women

Antag att det finns 6 män och 4 kvinnor i klassen, då om alla källfiler läses framgångsrikt bör målkatalogen för män ha 6 filer och målkatalogen för kvinnor bör ha 4 filer.

fallstudier – 2

instruktören ber er alla att förbereda en enda fil med personuppgifter för varje elev i separata segment.

Lektion-5

Skriv ett scenario som läser den här filen och producerar 10 målfiler där varje fil ska motsvara personuppgifterna för varje anställd. Målfilerna ska namnges som cv_< emp_ID>_< tidsstämpel>

Lektion-6

ändra ovanstående scenario så att det producerar 2 målfiler istället för 10 där en målfil för män och en annan målfil för damerna. Målfilen för män ska ha 6 segment för 6 män och målfilen för damer ska ha 4 segment för 4 kvinnor.

målfilerna ska namnges som

för män – men_<tidsstämpel>

för damer-women_<time_stamp>

fallstudie -3

samma som fallstudie – 1, instruktören be varje elev att förbereda sin personuppgifter och spara dem i en XML – fil. Det kommer att finnas 10 filer. Filerna sparas i källkatalogen.

Lektion-7

Förbered ett scenario för att läsa alla källfiler från källkatalogen och skapa en enda fil i målkatalogen. Namnet på målfilen kommer att matas ut.xml med tidsstämpeln Lägg till filnamnet. Målfilen kommer att ha alla detaljer för varje källfil som undersegment.

Lektion-8

Förbered ett scenario för att läsa hela källfilerna från källkatalogen och skapa två filer i målkatalogen – en för männen och den andra för damerna. För 6 män, män filen bör ha sex segment som har varje mans detaljer och för 4 kvinnor, på samma sätt bör det finnas 4 segment med varje dam detaljer.

fallstudie – 4

instruktören ber nu var och en av eleverna att förbereda en annan uppsättning detaljer som kommer att bestå av hans / hennes följande akademiska detaljer:

1. Student-ID
2. skolnamn
3. högskolans namn
4. Avdelningsnamn
5. Antagningsår

det kommer att finnas 10 filer och filerna heter ad_1, 2, 3….10. Filerna sparas i källkatalogen. Så varje elev kommer nu att ha ett par filer – en för personuppgifter och den andra för akademiska detaljer. Två filer är samrelaterade med Student-ID. Inmatningskatalogen består nu av 10 personliga filer och 10 akademiska filer.

Lektion-9

du uppmanas att utveckla ett scenario som väljer källfilerna och behandlar dem i par. Scenariot kommer att generera 10 målfiler. Varje målfil kommer att bestå av personliga och akademiska detaljer för en student i separata segment. Målfilerna kommer att namnges som res_1, 2, 10.

målfilerna kommer att se ut:

Lektion-10

du uppmanas sedan att ändra student-ID i vissa av filerna så att de inte har matchande akademiska eller personliga filer och vice versa. Scenariot ska köras och om det finns några filer som inte har en matchande motsvarande fil då processen bör avslutas efter en viss tidsperiod, dvs 2 min och dessa filer kommer att flyttas till felkatalogen och det kommer inte att finnas några motsvarande målfiler för dem.