SAP PI for begyndere

mål

formålet med denne tutorial er at få dig til at forstå – hvad er SAP-procesintegration? Vi vil ikke gå ind i emnet nitty-gritty, men vi vil diskutere om arkitekturen og forskellige funktioner i SAP PI. Vi dækker kun de grundlæggende funktioner og undgår at diskutere alle funktioner i denne tutorial.

dernæst er der et sæt casestudier, der giver dig en ide om branchens udnyttelse af SAP PI. Når du bliver mere bekendt med emnet, bør du forsøge at løse dem. Test cases er udarbejdet på en måde, så det vil tage dig ned i emnet fra simple til flere komplekser med hver lektion og vil give dig en samlet ide om emnet.

hvad er SAP ERP?

for enhver virksomhed – stor eller lille er dette de standard forretningsfunktioner, den skal udføre, dvs.materialestyring, salg og Distribution, økonomi, menneskelige ressourcer osv. Der er mange programmer på markedet, som industrien bruger. Du vil bemærke den enkleste – teller-maskinen, der genererer salgsfaktura, hvis du besøger en lille butik til et netværk af computere i en stor detailbutik, hotel osv.

Enterprise Resource Planning, dvs.ERP er en effektiv tilgang, som de fleste virksomheder implementerer for at forbedre deres produktivitet og ydeevne. SAP ERP er SAP AG ‘ s Enterprise Resource Planning, en integreret programløsning, der inkorporerer organisationens vigtigste forretningsfunktioner. De grundlæggende funktionaliteter, dvs. HR, MM, SD, FICO osv., kaldes forretningsmoduler i SAP. SAP bygger dem som produkter og sælger dem på markedet. Der er yderligere to moduler, der ikke understøtter forretningsfunktioner direkte, men bruges til præsentation og integration. Den førstnævnte kaldes EP (Enterprise Portal), og sidstnævnte kaldes PI (procesintegration). Alle forretningsmoduler er udviklet i ABAP, mens EP og PI hovedsagelig udvikles i Java. Disse moduler er ikke eksekverbare, men de skal implementeres i en applikationsserver, dvs.ABAP-applikationsserver til ABAP-moduler og Java-applikationsservere til Java-moduler.

der er få punkter, vi bør vide, før vi hopper ind i emnet.

• SAP står for systemer, applikationer og produkter i databehandling.

• SAP AG er et tysk multinationalt selskab, der fremstiller virksomhedsprogrammer til styring af forretningsdrift og kunderelationer. SAP ERP er selskabets Enterprise Resource Planning, en integreret programløsning, der inkorporerer organisationens vigtigste forretningsfunktioner.

• SAP er en del af SAP enterprise application integration (EAI), der bruges til at lette udvekslingen af information mellem en virksomheds interne programmer og systemer og eksterne parter.

Legacy System

under implementering af SAP ERP i en stor forretningsvirksomhed konstateres det, at ikke alle sektioner kan bringes under SAP ERP. Mange af forretningssektionerne kan have deres egne proprietære værktøjer, som er meget komplekse og muligvis ikke kan udskiftes. De løber parallelt med SAP-systemet. De kaldes Legacy-systemer. Derefter bliver det nødvendigt at integrere mellem SAP-systemerne og et sådant allerede eksisterende ikke-SAP-System. Det er her SAP PI kommer i spil.

Hvorfor har vi brug for SAP PI bortset fra ældre systemer består SAP ERP i en stor forretningsvirksomhed ikke af et enkelt system, men flere integrerede systemer, dvs.CRM, SRM og FICO osv. For at håndtere sådanne kompleksiteter introducerede SAP procesintegration en platform til at give et enkelt integrationspunkt for alle systemer uden at berøre eksisterende komplekst netværk af ældre systemer. Dette er en kraftfuld mellemvare fra SAP for at give problemfri ende til ende-integration mellem SAP og ikke-SAP-applikationer inden for og uden for virksomhedsgrænsen. SAP PI understøtter B2B såvel som A2A-udvekslinger, understøtter synkron og asynkron meddelelsesudveksling og inkluderer indbygget motor til design og udførelse af integrationsprocesser.

arkitektur af SAP PI

SAP PI består af en nav-og talestruktur; egerne forbinder med eksterne systemer, mens navet udveksler meddelelser mellem dem. Kildesystemet er kendt som afsendersystemet, og målsystemet er kendt som modtagersystemet. PI er ikke en enkelt komponent, men snarere en samling af komponenter, der arbejder fleksibelt sammen for at implementere integrationsscenarier. Arkitekturen inkluderer komponenter, der skal bruges på designtid, på konfigurationstid og på kørselstid.

vi kan opdele SAP PI i flere områder

1. Integrationsserver
2. Integrationsbygger
3. systemlandskab
4. konfiguration og overvågning

Integrationsserver er SAP PI ‘ s centrale behandlingsmotor. Alle meddelelser behandles her på en ensartet måde. Den består af tre separate motorer

1. Integrationsmotor
2. Adaptermotor
3. Forretningsprocesmotor

Integrationsmotor kan betragtes som navet og Adaptermotoren taleren. Med hensyn til Forretningsprocesmotoren vil jeg forklare det senere.

Integration Builder er en klient-server ramme for adgang til og redigering integration objekter og den består af to relaterede værktøjer:

1. Enterprise Service Repository – at designe og udvikle objekter, der skal bruges i scenarier
2. Integrationsmappe-at konfigurere ESR-objekter til at udvikle scenarier

to sammen byggede vi integrationsprocesser, der ofte kaldes scenarier.

systemlandskabet er et centralt lager af information om programmer og systemer i datacentret og forenkler administrationen af dit systemlandskab.

i Konfiguration og overvågning kan vi overvåge meddelelser og adaptere.

Single stack og Dual stack

da PI først blev frigivet, blev ikke alle komponenter bygget på den samme platform. Integration Engine og Business Process Engine blev bygget i ABAP, mens Adapter Engine, Integration Builder, SL, CM og kortlægning Runtime blev bygget i Java. Så PI har brug for både Java og ABAP-miljøet for at køre og er kendt som dual stack.

ABAP Stack	Java Stack
Integrationsmotor Forretningsprocesmotor Integrationsbygger	Enterprise Service Repository Integration Directory Runtime arbejdsbord system Landskabsmappe Adapter motor kortlægning Runtime

men i den senere version er alle komponenter bygget i Java. Nogle af dual-stack-komponenterne udleveres enten eller ændres til at arbejde på Java-stakken. Så PI har kun brug for Java-miljøet for at køre og er kendt som single stack.

der er fordele og ulemper mellem de to stakke, men de er ikke dækket af denne tutorial.

Integration Motor

Integrationsmotoren er ansvarlig for centrale Integrationsservertjenester, dvs.rørledningstrin-routing og kortlægning. Hvis kildemeddelelsesstrukturen er forskellig fra målmeddelelsesstrukturen, kalder integrationsmotoren Kortlægningens Runtime, hvor kildestrukturen konverteres til målstrukturen. Kortlægningen Runtime er baseret på Java stack. Integrationsmotoren kan også bruge et ABAP-program til konverteringen, som er baseret på ABAP-stakken.

en meddelelse kan være af to typer

1. synkron – har både anmodnings-svardelen
2. asynkron – har enten anmodningen eller svardelen kun

I PI er meddelelsen repræsenteret af en grænseflade.

Interface -> struktur af meddelelsen i format + retning

baseret på ovenstående kriterier er der tre typer grænseflader

1. udgående grænseflade – Opret forbindelse til afsendersystemet
2. indgående grænseflade – Opret forbindelse til modtagersystemet
3. abstrakt grænseflade – Opret forbindelse til BPE

når vi konfigurerer integrationslogik (scenarie) i SAP PI i henhold til vores forretningskrav, er det integrationsmotoren, der udfører denne konfiguration trinvis. Pipeline er det udtryk, der bruges til at henvise til alle trin, der udføres under behandlingen af en meddelelse. Rørledningstrinnene består af følgende:

1. Modtageridentifikation-bestemmer det system, der deltager i udvekslingen af meddelelsen.
2. Interface bestemmelse – Bestem hvilken grænseflade skal modtage meddelelsen.
3. besked Split – hvis der findes mere end en modtager, vil PI instantiere ny besked for hver modtager.
4. Meddelelseskortlægning – kortlægning for at omdanne kildemeddelelsen til destinationsmeddelelsesformat.
5. teknisk Routing – bind en bestemt destination og protokol til meddelelsen.
6. Opkaldsadapter – send den transformerede besked til adapteren eller en fuldmagt.

Adaptermotor

du skal have bemærket tidligere, at integrationsmotoren kun håndterer meddelelser i SOAP-protokollen. Men hvad nu hvis vi har en afsender og et modtagervirksomhedssystem, hvor dataene ikke er i samme format. Vi bruger de forskellige adaptere i Adaptermotoren til at konvertere MLML – og HTTP-baserede meddelelser til den specifikke protokol og det format, der kræves af disse systemer, og omvendt.

som vi har diskuteret tidligere, er SAP PI en nav-og talestruktur, hvor Adaptermotoren kan betragtes som talte. Vi bruger Adaptermotoren til at forbinde Integrationsmotoren (Hub) til de eksterne systemer. Adapterrammen er grundlaget for Adaptermotoren. Adapterrammen er baseret på SAP J2EE-motoren (som en del af SAP-applikationsserveren) og J2EE Connector Architecture (JCA). Adapterrammen giver grænseflader til konfiguration, styring og overvågning af adaptere.

i et dual stack-system var de fleste adaptere baseret på Java-stakken, der spærrede to adaptere, der er baseret på ABAP-stakken.

Java Stack	RFC adapter, SAP Business Connector adapter, fil / FTP adapter, jdbc adapter, JMS adapter, sæbe adapter, Marketplace Adapter, Mail adapter, RNIF adapter
ABAP stack	IDOC adapter og HTTP adapter

da SAP PI flyttede fra dual stack til single stack, blev disse to adaptere en del af Java stack. Den modificerede adaptermotor er kendt som Advance Adapter Engine, og de to adaptere kaldes henholdsvis IDOC_AAE adapter og HTTP_AAE adapter.

Forretningsproces Motor

Forretningsprocesmotoren er ansvarlig for udførelse og vedvarende integrationsprocesser.

BPM står for cross-component Business Process Management eller ccBPM og kaldes også integrationsproces. En integrationsproces er en eksekverbar proces på tværs af systemet til behandling af meddelelser. I en integrationsproces definerer du alle de procestrin, der skal udføres, og de parametre, der er relevante for styring af processen. Business Process Management leverer SAP-Udvekslingsinfrastruktur med følgende funktioner:

1. status-Fuld beskedbehandling: status for en integrationsproces vedvarer på Integrationsserveren.
2. du kan også bruge korrelationer til at etablere semantiske relationer mellem meddelelser.
3. du implementerer integrationsprocesser, når du vil definere, styre og overvåge komplekse integrationsprocesser, der strækker sig på tværs af virksomheds-og applikationsgrænser, dvs.indsamle/flette, opdele, Multicast

ved kørsel udfører Forretningsprocesmotoren integrationsprocesserne. Integrationsprocessen kan kun sende og modtage meddelelser ved hjælp af abstrakte grænseflader.

Byg et scenario i SAP PI

vi starter fra hjemmesiden, hvis vi skal opbygge et scenario i PI.

hjemmesiden vil ligne som angivet nedenfor:

figur 6-hjemmeside for SAP PI Java Stack

hjemmesiden har hyperlinks til følgende 4 arbejdsområder

1. Enterprise Services Repository (ESR)
2. Integrationsmappe (ID)
3. systemlandskab (SL)
4. konfiguration og overvågning (CM)

hvert hyperlink åbner en applikation. Alle disse fire er Java-applikation. ESR og ID er sving applikationer. De lanceres fra bro.ser baseret på JNLP. Så for første gang tager det mere tid, da det henter hele biblioteksfilen. Men fra anden gang tager det mindre tid at starte. SL og CM er rene applikationer og kører på netsøgeren.

Enterprise Services Repository

her designer og opretter vi objekter, der skal bruges til fremstilling af et integrationsscenarie. Datastrømmen i PI vil se ud som vist nedenfor:

vi finder muligheden for at designe følgende

1. Interfaceobjekter-Servicegrænseflade, meddelelsestype, datatype
2. Kortlægningsobjekter-Operation kortlægning og kortlægning af meddelelser
3. integrationsprocesser

PI bruger integrationslager til at designe meddelelsesstruktur til både afsender-og modtagersystemer og udvikle en grænseflademeddelelse ved hjælp af tilsvarende meddelelsesstrukturer, der fungerer som et interaktionspunkt for omverdenen. Datatype og meddelelsestype bruges til at forenkle og modularisere designet af en kompleks grænseflade.

operation Mapping tillader transformation af kildestruktur til målstruktur, når de to strukturer er forskellige. Men hvis kilden og målstrukturen er ens, kan operationskortlægningen udleveres. I lighed med servicegrænsefladen bruges meddelelseskortlægning til at forenkle og modularisere designet af en kompleks operationskortlægning. Kortlægning af meddelelser kan implementeres på 4 måder

1. Grafisk kortlægning
2. Java kortlægning
3. ABAP kortlægning

Grafisk kortlægning er den mest anvendte, da den giver udvikleren mulighed for at kortlægge attributter for begge strukturer grafisk for at videregive data ved hjælp af servicegrænseflader. For de andre tre skal vi udvikle kortlægningen ved at skrive kode. Hvis det er en enkelt stakserver, vil ABAP-kortlægningen ikke være tilgængelig.

der er også andre områder, men de er ikke dækket af denne tutorial.

Integration Directory

her gør vi rør-line trin ved at konfigurere ESR objekter oprettet tidligere. Disse trin udføres af integration motor under run-time.

før vi starter konfigurationen, skal vi oprette/importere følgende objekter i DIR.

1. Service – Business System/ Business Service/ integrationsproces
2. kommunikationskanal

en tjeneste giver dig mulighed for at adressere en afsender eller modtager af meddelelser. Afhængigt af hvordan du vil bruge tjenesten, kan du vælge mellem følgende Servicetyper.

1. forretningssystem – hvis du vil adressere et bestemt forretningssystem som afsender eller modtager af meddelelser, skal du vælge denne servicetype. Et forretningssystem er et egentligt applikationssystem i et systemlandskab.
2. Business Service – Hvis du vil adressere en abstrakt forretningsenhed som afsender eller modtager af meddelelser, skal du vælge denne servicetype. En virksomhedstjeneste er ikke defineret i systemlandskabet.
3. integrationsproces Service – hvis du vil adressere en integrationsproces som afsender eller modtager af meddelelser, skal du vælge denne servicetype. Ved kørsel styres disse integrationsprocesser af meddelelser og kan selv sende meddelelser.

kommunikationskanal bestemmer indgående og udgående behandling af meddelelser. Meddelelserne konverteres fra native format til soap-specifikke besked format og vice versa via adapteren. Generelt er der to typer kommunikationskanal i et scenario

1. afsender kommunikationskanal
2. modtager kommunikationskanal

du skal tildele en kommunikationskanal til en tjeneste. Afhængigt af om tjenesten adresseres som afsender eller modtager af meddelelser, har den tildelte kommunikationskanal rollen som enten en afsender eller en modtagerkanal og skal konfigureres i overensstemmelse hermed. Du kan ikke tildele en kommunikationskanal til en integrationsproces tjeneste.

rørledningstrinnene oprettes ved at oprette følgende 4 konfiguration i DIR

vi finder følgende muligheder:

1. Afsenderaftale
2. Modtagerbestemmelse
3. Grænsefladebestemmelse
4. Modtageraftale

Afsenderaftale definerer, hvordan en afsenders meddelelse skal transformeres, så den kan behandles af Integrationsserveren. Den består af følgende

1. Afsenderkomponent
2. Afsendergrænseflade
3. Afsenderkommunikationskanal

Afsenderaftale svarer til primær nøgle i tabel. Der kan ikke være de to lignende afsenderaftaler i et landskab.

Modtageraftale definerer, hvordan meddelelsen skal transformeres, så den kan behandles af en modtager. Den består af

1. Afsenderkomponent
2. Modtagerkomponent
3. Modtagergrænseflade
4. Modtagerkommunikationskanal

du bruger en modtagerbestemmelse til at specificere, hvilke modtagere en meddelelse skal sendes til. Du har mulighed for at definere betingelser for videresendelse af meddelelsen til modtagerne. Den består af

1. Afsenderkomponent
2. Afsendergrænseflade
3. Modtagerkomponent

Modtagerbestemmelse er af to typer – Standard eller udvidet, afhængigt af om du vil specificere modtageren manuelt eller dynamisk ved en kortlægning ved kørsel.

du bruger en grænsefladebestemmelse til at angive, hvilken indgående grænseflade for en modtager; meddelelsen skal videresendes til. Du kan også angive, hvilken grænseflade kortlægning fra Integration Repository skal bruges til behandling af meddelelsen dvs. hvis afsenderen og modtagergrænsefladen ikke er af samme format, er der en operationel kortlægning for at ændre formatet. Du definerer en grænsefladebestemmelse for en afsender, en udgående grænseflade og en modtager. Den består af

1. Afsenderkomponent
2. Afsendergrænseflade
3. Modtagerkomponent
4. Modtagergrænseflade

Grænsefladebestemmelse er af to typer – Standard eller forbedret, afhængigt af om du vil specificere modtagergrænsefladen manuelt eller gennem kortlægningsbaseret meddelelsesopdeling.

Modtagerbestemmelse og Grænsefladebestemmelse – de to sammen er almindeligt kendt som den logiske routing. Afsenderaftale og Modtageraftale – de to sammen er almindeligt kendt som samarbejdsaftalen.

systemlandskab

SAP system Landscape Directory (SLD) er den centrale informationsudbyder i et systemlandskab. På hjemmesiden finder du følgende links:

1. teknisk System-tekniske systemer er applikationssystemer, der er installeret i dit systemlandskab.
2. forretningssystem – forretningssystemer er logiske systemer, der fungerer som afsendere eller modtagere inden for PI. Forretningssystemer har en-til-en afhængighed med det tilhørende tekniske system.
3. produkter og komponenter – Dette er information om alle tilgængelige SAP-produkter og komponenter, inklusive deres versioner. Hvis der er nogen tredjepartsprodukter i systemlandskabet, er de også registreret her.

SLD vil ligne som angivet nedenfor:

Figur 11-systemlandskab

produkter og komponenter kaldes almindeligvis Komponentinformationen

teknisk System og forretningssystem kaldes almindeligvis Landskabsbeskrivelsen.

et forretningssystem kan konfigureres som en Integrationsserver eller applikationssystem.

1. Integrationsserver – Integrationsserveren udfører kun integrationslogik konfigureret i Integrationsbyggeren. De kan også identificeres som Rørledningstrin. Den modtager en meddelelse, bestemmer modtageren, udfører kortlægningerne og dirigerer meddelelsen til de tilsvarende modtagersystemer. Således er konfigureret Integrationsmotor identificeret til at være Central konfigureret Integrationsmotor.
2. applikationssystem – applikationssystemet udfører ikke integrationslogikken. Det kalder igen integrationsserveren til at udføre integrationslogikken, hvis det kræves. Det fungerer som afsender eller modtager af SMS-beskeder. Så applikationssystemet med en lokal Integrationsmotor kræver, at Integrationsserveren udfører integrationslogikken.

kun en klient af SAP-systemet kan konfigureres som Integrationsserver.

følgende oplysninger udvindes fra SLD til ESR, og Dir

1. komponentoplysninger bruges i ESR til at definere produktet, og SV
2. forretningssystemet bruges i mappen til at definere afsender og modtager af meddelelser

konfiguration og overvågning

det er det centrale indgangspunkt til overvågningsformål. Dette giver dig mulighed for at navigere til overvågningsfunktionerne i Integrationsmotoren samt integration med Computing Center Management System (CCMS) og Process Monitoring Infrastructure (PMI) i SAP.

konfigurationen og overvågningen vil ligne som angivet nedenfor:

figur 13-konfiguration og overvågning

med konfiguration og overvågning understøttes følgende overvågningsfunktioner:

1. Component monitoring-overvågning af de forskellige SAP PI komponenter (Java og ABAP dele).
2. besked overvågning – sporing meddelelsen behandling status inden for en SAP PI komponent og på fejl afsløring og analyse.
3. end-to-end overvågning – overvågning af en besked livscyklus fra SAP PI synspunkt.
4. Performance monitoring – statistik om forskellige performance aspekter af SAP PI kan tilgås via RVB. Her kan du vælge og samle ydelsesdata, f.eks. efter komponent -, tidsinterval-eller meddelelsesattributter.
5. Indeksadministration – ved at administrere og overvåge indekseringen af meddelelser pr.SAP PI-komponent aktiverer du en indeksbaseret meddelelsessøgning, som du kan bruge i meddelelsesovervågning. Denne form for meddelelsessøgning giver dig forbedrede udvælgelseskriterier, herunder adapterspecifikke meddelelsesattributter og udtryk eller sætninger fra meddelelsens nyttelast.
6. Alert configuration – ved at bruge Alert-rammen kan central overvågning i PI forsynes med alle fejl rapporteret under meddelelsesbehandling i ABAP og Java. Dette muliggør en forbedret reaktion på sådanne fejl i både ABAP-runtime og den Java-baserede Adaptermotor. Til dette formål er Advarselsrammen forsynet med regler baseret på visse begivenheder og på oplysninger fra overskriften til PI-meddelelsesprotokollen. Disse regler bestemmer, om advarsler sendes eller ej. Hvis der sendes en advarsel, kan den bruges til fejlanalyse.
7. alert indbakke – alert indbakke er brugerspecifik og viser alle advarsler for hver alert server, der er blevet genereret baseret på alert konfiguration.
8. Cache overvågning – cache overvågning viser objekter, der er i øjeblikket i runtime cache. Forskellige cache-objekter overvåges afhængigt af den pågældende cache-forekomst.

synkron vs. asynkron kommunikation

en proces kan defineres som enten synkron eller asynkron.

• en synkron proces påberåbes ved en anmodning/svaroperation, og resultatet af processen returneres straks til den, der ringer op via denne handling.
• en asynkron proces påberåbes af en envejsoperation, og resultatet og eventuelle fejl returneres ved at påberåbe sig andre envejsoperationer. Resultatet returneres til den, der ringer op via en tilbagekaldsoperation.

i computerverdenen er der ingen asynkron kommunikation. Al kommunikation mellem to systemer er altid via metode opkald (anmodning/svar operation). Så hvordan gør vi det asynkront? Svaret ligger i introduktionen af et tredje system mellem den kaldte og opkalds funktion.

Antag, at der er to systemer-A og B. Al kommunikation mellem A og B sker via et metodekald, og de er således synkrone. Vi introducerer et tredje system mellem A og B og kaldte det det mellemliggende system – I. kommunikationen mellem A og i er via metodekald og tilsvarende mellem I og B er også via metodekald. Men kommunikationen mellem A og B kan kaldes asynkron, da A ikke behøver at vente på svaret fra B.

dette er grundlaget for asynkron kommunikation, og hvad er dette mellemliggende system? Det er køen. A kaldes afsenderen, og B kaldes modtageren. Besked fra A føjes først til køen, og derefter trækkes den igen fra køen og sendes til B. svaret fra B Når A på en lignende måde. I visse situationer, forretningskravet har brug for, at meddelelserne leveres til B i samme rækkefølge, som de udløses fra A. I så fald følger vi en først-ind-og først-ud-politik. Hvis der ikke er sådanne krav, sendes meddelelser fra køen til B i enhver rækkefølge.

med asynkron kommunikation opnår vi garanteret levering, dvs.System B er ikke tilgængelig, når System A sender beskeden. Meddelelsen føjes til køen og forbliver der, så længe B ikke er tilgængelig. Når B er tilgængelig, trækkes beskeden fra køen og sendes til B.

så vi kan klassificere vores meddelelseskommunikation på tre måder:

1. synkron
2. asynkron med ordre ikke vedligeholdt
3. asynkron med ordre opretholdt

I PI identificerer vi dem som: synkron – BE (bedste indsats), asynkron med ordre ikke vedligeholdt – EO (nøjagtigt en gang), asynkron med ordre vedligeholdt – EOIO (nøjagtigt en gang i rækkefølge).

anerkendelse

anerkendelse er roden til asynkron kommunikation. Hvorfor?

for synkron kommunikation kalder System a system B, og hvis B ikke sender svaret, mislykkedes processen. Men i en asynkron kommunikation kalder System a System i og System i system B. Så Antag, at kommunikationen mellem A og jeg er vellykket, men mellem I og B fejler den. Hvordan skal A indse, at leveringen til B har mislykkedes? Dette realiseres ved en anerkendelse, der sendes tilbage til A af B via den samme rute som meddelelsen fra A tog til B. Hvis bekræftelsen fra B ikke ankommer til A, overvejer A, at processen er mislykket, og sender beskeden igen.

mens vi diskuterede om asynkron kommunikation i PI, har vi brugt udtrykket – ‘præcis en gang’ for både EO og EOIO. Præcis en gang betyder, at en meddelelse, der leveres en gang, ikke kan leveres igen. For at opnå dette er der en anerkendelse for hver meddelelse, der sendes fra A til B. Det er adapterne, der ligger i slutningen af kommunikationen. Så adapterne skal understøtte anerkendelse.

alle adaptere leverer systemkvittering i.e. leveringsbekræftelse. De adaptere, der understøtter synkron kommunikation, understøtter applikationsbekræftelse ud over systemkvitteringen.

så I PI er følgende typen af bekræftelse

1. Systembekræftelse – systembekræftelser, der bruges af runtime-miljøet til at bekræfte, at en asynkron meddelelse har nået modtageren.
2. Applikationsbekræftelse – applikationsbekræftelser, der bruges til at bekræfte, at den asynkrone meddelelse er blevet behandlet på modtageren.

Fjernfunktionsopkald

mens du arbejder i PI, kommer du på tværs af udtrykket – RFC. Hvad er de? For at etablere kommunikation mellem to SAP-systemer, dvs.en R/3 og PI, opretter vi RFC-destinationen. Det er konfigureret af følgende

1. forbindelsestype
2. IP-adresse og Port på modtageren

forbindelsestype fortæller typen af systemforbindelse, dvs.R/3, TCP/IP, intern osv.

den RFC-Destination, Vi opretter, klassificeres efter den krævede kommunikationsform, dvs. uanset om det skal understøtte synkron eller asynkron kommunikation.

1. til synkron kommunikation – synkron RFC
2. til asynkron kommunikation med ordre ikke vedligeholdt – Transaktionel RFC
3. til asynkron kommunikation med ordre vedligeholdt – kø RFC

de identificeres af sRFC, tRFC og krfc.

casestudier – 1

Antag at du er i et klasseværelse, og der er 10 studerende i det. Instruktøren beder derefter hver elev om at forberede følgende personlige oplysninger og gemme dem i en fil. Detaljerne er som følger:

1. studiekort
2. navn
3. mobil
4. e-mail
5. køn

der vil være 10 filer og filerne er navngivet som cv_1,2,3….10. Filerne gemmes i kildekataloget. Til testformål oprettes følgende mapper:

Kildekatalog: c:\ibm\sap\training\input

arkivmappe: c:\ibm\sap\training\archive

Fejlmappe: c:\ ibm \ sap \ træning \ fejl

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

du bliver bedt om at udvikle scenarier i SAP PI, som vil læse kildefilerne fra kildekataloget og skrive dem til målmappen. Når en fil er læst fra kildekataloget, skal den flyttes til arkivmappen, og hvis filen ikke kan læses for en fejl, dvs. De filer, der flyttes til arkiv, fejl eller målmappe, skal have et tidsstempel til filnavnet.

1. dvs. filnavn + <tidsstempel>.

Lektion-1

Forbered et scenario for at læse en enkelt fil, dvs.fil cv_1.fra kildekataloget og skriv det til målmappen. Målfilnavnet skal også være cv_1.med tidsstemplet Tilføj til navnet.

Lektion-2

Forbered et scenario for at læse alle filerne fra kildekataloget og skrive dem til målmappen. På samme måde skal målfilerne også navngives som cv_1, 2 ..med tidsstemplet Tilføj til hver af dem.

Lektion-3

instruktøren beder jer alle om at tilføje følgende Validering til dataene.

1. mobilnummeret skal have 10 numeriske cifre-hvis mobilnummeret ikke er på 10 cifre, skal du erstatte det med ‘fejl’
2. e-mailen skal have et ‘@’ tegn og et ‘.’tegn-hvis e-mailen ikke har ‘@’ eller ‘.’tegn, derefter erstatte det med ‘fejl’

før du kører scenariet, skal du i nogle af kildefilerne ændre mobilen og e-mailen, så de er i fejl i henhold til logikken ovenfor.

Lektion-4

Forbered et scenario for at læse alle kildefilerne og klassificere dem efter deres køn. Filerne til mændene vil blive skrevet i en mappe og for damerne til en anden mappe. To mapper er oprettet til ovenstående formål:

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

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

Antag, at der er 6 mænd og 4 kvinder i klassen, så hvis alle kildefilerne læses med succes, skal målmappen for mænd have 6 filer, og målmappen for kvinder skal have 4 filer.

casestudier – 2

instruktøren beder jer alle om at forberede en enkelt fil med de personlige oplysninger om hver elev i separate segmenter.

Lektion-5

Skriv et scenario, der vil læse denne fil og producerer 10 målfiler, hvor hver fil skal svare til de personlige data for hver medarbejder. Målfilerne skal navngives som cv_<emp_ID>_<tidsstempel>

Lektion-6

Rediger ovenstående scenario, så det producerer 2 målfiler i stedet for 10, hvor en målfil for mænd og en anden målfil for damerne. Målfilen for mænd skal have 6 segmenter til 6 mænd og målfilen for damer skal have 4 segmenter til 4 kvinder.

målfilerne skal navngives som

for men – men_<time-stamp>

for Ladies – kvinder_<time_stamp>

Case Study -3

samme som case study – 1 beder instruktøren hver elev om at forberede sin/hendes personlige oplysninger og gemme dem i en fil. Der vil være 10 filer. Filerne gemmes i kildekataloget.

Lektion-7

Forbered et scenario for at læse alle kildefilerne fra kildekataloget og oprette en enkelt fil i målmappen. Navnet på målfilen vil blive output.med tidsstemplet Tilføj til filnavnet. Målet fil vil have alle detaljerne i hver kildefil som sub-segment.

Lektion-8

Forbered et scenario for at læse hele kildefilerne fra kildekataloget og oprette to filer i målmappen – den ene til mændene og den anden til damerne. Til 6 mænd, mænds fil skal have seks segmenter, der har hver mands detaljer og til 4 kvinder, tilsvarende skal der være 4 segmenter med hver dames detaljer.

casestudie – 4

instruktøren beder nu hver af de studerende om at forberede et andet sæt detaljer, der vil bestå af hans / hendes følgende akademiske detaljer:

1. Student ID
2. Skole navn
3. College navn
4. Institut Navn
5. optagelse år

der vil være 10 filer og filerne er navngivet som ad_1, 2, 3….10. Filerne gemmes i kildekataloget. Så hver studerende vil nu have et par filer – en til de personlige oplysninger og den anden til de akademiske detaljer. To filer er co-relateret med Student ID. Inputmappen består nu af 10 personlige filer og 10 akademiske filer.

Lektion – 9

du bliver bedt om at udvikle et scenario, der vælger kildefilerne og behandler dem i par. Scenariet vil generere 10 målfiler. Hver målfil vil bestå af de personlige og akademiske detaljer for en studerende i separate segmenter. Målfilerne vil blive navngivet som res_1, 2, 10.

målfilerne vil se ud:

Lektion – 10

du bliver derefter bedt om at ændre studiekort i nogle af filerne, så de ikke har matchende akademiske eller personlige filer og omvendt. Scenariet skal køre, og hvis det fandt nogen filer, der ikke har en matchende tilsvarende fil, skal processen slutte efter en vis periode, dvs.2 minutter, og disse filer flyttes til fejlmappen, og der vil ikke være nogen tilsvarende målfiler for dem.