SAP PI For Nybegynnere

Mål

målet med denne opplæringen er å få deg til å forstå-HVA ER SAP – Prosessintegrasjon – Vi vil ikke gå inn i det nitty-gritty av emnet, men vi vil diskutere om arkitekturen OG forskjellige funksjoner I SAP PI. Vi vil dekke de grunnleggende funksjonene og vil unngå å diskutere alle funksjonene i denne opplæringen.

Neste er det et sett med case-studier som vil gi deg en ide om bransjens utnyttelse AV SAP PI. Når du blir mer kjent med emnet, bør du prøve å løse dem. Testtilfellene er utarbeidet på en måte slik at det vil ta deg ned i emnet fra enkle til flere komplekser med hver leksjon, og vil gi deg en generell ide om emnet.

HVA ER SAP ERP?

for enhver bedrift – stor eller liten, er dette standard forretningsfunksjonaliteter det må utføre, Dvs. Materialhåndtering, Salg Og Distribusjon, Økonomi, Menneskelige Ressurser etc. Det er mye programvare i markedet som brukes av industrien. Du vil legge merke til den enkleste – teller machine genererer salgsfaktura hvis du besøker en liten butikk til et nettverk av datamaskiner i en stor butikk, hotell etc som opererer på EN ERP.

Enterprise Resource Planning dvs.ERP er en effektiv tilnærming som de fleste bedrifter implementere for å forbedre sin produktivitet og ytelse. SAP ERP ER SAP AGS Enterprise Resource Planning, en integrert programvareløsning som inkorporerer de viktigste forretningsfunksjonene i organisasjonen. De grunnleggende funksjonalitetene, DVS. HR, MM, SD, FICO etc, kalles forretningsmoduler I SAP. SAP bygger dem som produkter og selger dem i markedet. Det er to moduler som ikke støtter forretningsfunksjoner direkte, men brukes til presentasjon og integrasjon. Den første Heter Ep (Enterprise Portal) og DEN andre HETER PI (Process Integration). Alle forretningsmodulene er utviklet I ABAP mens EP og PI er utviklet for det meste I Java. Disse modulene er ikke kjørbare, men de må distribueres i En Applikasjonsserver, dvs.

det er få poeng vi bør vite før vi hopper inn i emnet.

• SAP står For Systemer, Applikasjoner og Produkter I Databehandling.

• SAP AG ER et tysk multinasjonalt programvareselskap som lager bedriftsprogramvare for å administrere forretningsdrift og kunderelasjoner. SAP ERP er selskapets Enterprise Resource Planning, en integrert programvareløsning som inkorporerer de viktigste forretningsfunksjonene i organisasjonen.

• SAP NetWeaver Process Integration (SAP PI) ER SAP enterprise application integration (EAI) programvare, en del Av NetWeaver produktgruppen som brukes til å lette utveksling av informasjon mellom selskapets interne programvare og systemer og de av eksterne parter.

Legacy System

mens implementere SAP ERP i en stor bedrift etablering, er det funnet at IKKE alle seksjoner kan bringes UNDER SAP ERP. Mange av forretningsseksjonene kan ha egne proprietære verktøy som er svært komplekse og kan ikke være mulig å bli erstattet. De kjører parallelt MED SAP-Systemet. De kalles Eldre Systemer. Da blir det nødvendig å integrere MELLOM SAP-Systemene og et slikt eksisterende ikke-SAP-System. DET ER HER SAP PI kommer inn i spill.

Hvorfor trenger VI SAP PI Bortsett Fra Eldre Systemer, I en stor bedrift etablering, SAP ERP består ikke AV et enkelt system, men flere integrerte systemer dvs. CRM, SRM og FICO etc. FOR å håndtere slike kompleksiteter introduserte SAP Prosessintegrasjon en plattform for å gi et enkelt integrasjonspunkt for alle systemer uten å berøre eksisterende komplekse nettverk av eldre systemer. Dette er en kraftig mellomvare AV SAP for å gi sømløs ende-til-ende-integrasjon mellom SAP og ikke-SAP-applikasjoner innenfor og utenfor bedriftsgrensen. SAP PI støtter B2B samt a2a-utvekslinger, støtter synkron og asynkron meldingsutveksling og inkluderer innebygd motor for å designe og utføre Integrasjonsprosesser.

Arkitektur AV SAP PI

SAP PI består av en hub og snakket struktur; eikene forbinder med eksterne systemer mens navet utveksler meldinger mellom dem. Kildesystemet er kjent som avsendersystemet og målsystemet er kjent som mottakersystemet. PI er ikke en enkelt komponent, men heller en samling av komponenter som jobber sammen fleksibelt for å implementere integrasjonsscenarier. Arkitekturen inkluderer komponenter som skal brukes på designtid, på konfigurasjonstid og på kjøretid.

VI kan dele SAP PI inn i flere områder

1. Integration Server
2. Integration Builder
3. System Landskap
4. Konfigurasjon Og Overvåking

Integration Server er DEN sentrale prosesseringsmotoren TIL SAP PI. Alle meldinger behandles her på en konsistent måte. Den består av tre separate motorer

1. Integrasjonsmotor
2. Adaptermotor
3. Forretningsprosessmotor

Integrasjonsmotor kan anses å være navet og Adaptermotoren spaken. Når Det gjelder Forretningsprosessmotoren, vil jeg forklare det senere.

Integration Builder Er et klient-server rammeverk for tilgang til og redigering av integrasjonsobjekter, og består av to relaterte verktøy:

1. Enterprise Service Repository – for å designe og utvikle objekter som skal brukes i scenarier
2. Integrasjonskatalog – for å konfigurere esr-objektene til å utvikle scenarier

To sammen bygde vi integrasjonsprosesser som ofte kalles scenarier.

Systemlandskapet er et sentralt oppbevaringssted for informasjon om programvare og systemer i datasenteret og forenkler administrasjonen av systemlandskapet.

I Konfigurasjon og Overvåking kan vi overvåke meldinger og adaptere.

Single stack og Dual stack

når PI først ble utgitt, ble ikke alle komponenter bygget på samme plattform. Integrasjonsmotor og Forretningsprosessmotor ble bygget I ABAP mens Adapter Engine, Integration Builder, Sl, CM og Mapping Runtime ble bygget I Java. SÅ PI trenger Både Java og ABAP-miljøet for å kjøre og er kjent som dual stack.

ABAP Stack	Java Stack
Integrasjonsmotor Forretningsprosessmotor Integrasjonsbygger	Enterprise Service Repository Integrasjonskatalog Runtime Workbench System Liggende Katalog Adaptermotor Tilordning Av Runtime

men i den senere versjonen er alle komponentene bygget I Java. Noen av dual-stack-komponentene er enten dispensert eller modifisert for å fungere På Java-stakken. SÅ PI trenger Bare Java-miljøet til å kjøre og er kjent som single stack.

det er fordeler og ulemper mellom de to stablene, men de er ikke dekket i denne opplæringen.

Integrasjonsmotor

Integrasjonsmotoren er ansvarlig for sentrale Integrasjonsservertjenester, dvs. rørledningstrinnene-ruting og kartlegging. Hvis kildemeldingsstrukturen er forskjellig fra målmeldingsstrukturen, kaller integration engine Kjøretiden For Tilordning, der kildestrukturen konverteres til målstrukturen. Kartleggingen Runtime er basert På Java-stakken. Integrasjonsmotoren kan også benytte ET ABAP-program for konverteringen, som er basert på ABAP-stakken.

en melding kan være av to typer

1. Synkron-har både request-response-delen
2. Asynkron-har enten request eller response-delen bare

i PI er meldingen representert av et grensesnitt.

Grensesnitt -> struktur av meldingen I XML – format + retning

basert på kriteriene ovenfor er det tre typer grensesnitt

1. Utgående grensesnitt – koble til avsendersystemet
2. Innkommende grensesnitt – koble til mottakersystemet
3. Abstrakt grensesnitt-koble TIL BPE

Når vi Konfigurerer integrasjonslogikk (scenario) i sap pi i HENHOLD TIL våre forretningskrav, er det integrasjonsmotoren som utfører den konfigurasjonen På En Trinnvis måte. Pipeline er begrepet som brukes til å referere til alle trinn som utføres under behandlingen AV EN XML-melding. Rørledningstrinnene består av følgende:

1. Mottakeridentifikasjon-bestemmer systemet som deltar i utveksling av meldingen.
2. Grensesnittbestemmelse-bestem hvilket grensesnitt som skal motta meldingen.
3. Message Split – HVIS mer enn en mottaker blir funnet, vil PI starte ny melding for hver mottaker.
4. Meldingstilordning-tilordning for å transformere kildemeldingen til målmeldingsformat.
5. Teknisk Ruting-bind en bestemt destinasjon og protokoll til meldingen.
6. Anropsadapter-send den transformerte meldingen til adapteren eller en proxy.

Adaptermotor

du må ha lagt merke til tidligere at integrasjonsmotoren bare håndterer meldinger I XML-SOAP-protokollen. Men hva om vi har en avsender og en mottaker forretningssystem der dataene ikke er i samme format. Vi bruker de forskjellige adapterne i Adaptermotoren til å konvertere XML-og HTTP-baserte meldinger til den spesifikke protokollen og formatet som kreves av disse systemene, og omvendt.

SOM VI har diskutert tidligere, ER SAP PI et nav og snakket struktur hvor Adaptermotoren kan betraktes som snakket. Vi bruker Adaptermotoren til å koble Integrasjonsmotoren (Hub) til de eksterne systemene. Adapterrammen er grunnlaget for Adaptermotoren. Adapterrammen er basert PÅ SAP J2EE-Motoren (SOM en del AV SAP Web Application Server) og J2EE Connector Architecture (JCA). Adapterrammen gir grensesnitt for konfigurasjon, administrasjon og overvåking av adaptere.

i en dual stack system, de fleste av adaptere der basert På Java stack sperring to adaptere som er basert PÅ ABAP stakken.

Java Stack	RFC-adapter, SAP Business Connector-adapter, fil – / FTP-adapter, JDBC-adapter, JMS-adapter, SOAP-adapter, Marketplace-Adapter, Postadapter, RNIF-adapter, CIDX-adapter
ABAP stack	IDOC-adapter OG HTTP-adapter

NÅR SAP PI flyttet fra dual stack til single stack, ble disse to adapterene en del Av Java-stakken. Den modifiserte adaptermotoren er kjent som Advance Adapter Engine, og de to adapterne kalles HENHOLDSVIS IDOC_AAE adapter og HTTP_AAE adapter.

Forretningsprosessmotor

Business Process Engine er ansvarlig for gjennomføring og vedvarende integrasjonsprosesser.

BPM står for cross-component Business Process Management eller ccBPM og kalles Også Integrasjonsprosess. En integrasjonsprosess er en kjørbar, krysssystemprosess for behandling av meldinger. I en integrasjonsprosess definerer du alle prosesstrinnene som skal utføres og parametrene som er relevante for å kontrollere prosessen. Business Process Management gir SAP Exchange-Infrastruktur med følgende funksjoner:

1. Status-full meldingsbehandling: statusen for en integrasjonsprosess er vedvarende På Integrasjonsserveren.
2. du kan også bruke korrelasjoner til å etablere semantiske relasjoner mellom meldinger.
3. du implementerer integrasjonsprosesser når Du vil definere, kontrollere og overvåke komplekse integrasjonsprosesser som strekker seg over virksomhets-og applikasjonsgrenser, dvs. samle/Slå sammen, Dele, Multicast

Ved kjøretid utfører Business Process Engine integrasjonsprosessene. Integrasjonsprosessen kan bare sende og motta meldinger ved hjelp av abstrakte grensesnitt.

Bygg et scenario I SAP PI

vi starter Fra Hjemmesiden hvis vi må bygge et scenario I PI.

hjemmesiden vil se ut som angitt nedenfor:

Figur 6-Hjemmeside FOR SAP PI Java Stack

Hjemmesiden har hyperkoblinger til følgende 4 arbeidsområder

1. Enterprise Services Repository (ESR)
2. Integrasjonskatalog (ID)
3. Systemlandskap (SL)
4. Konfigurasjon og Overvåking (CM)

hver hyperkobling vil åpne ett program. Alle disse fire Er Java-program. ESR OG ID er swing applikasjoner. De lanseres fra nettleseren basert PÅ JNLP. Så for første gang tar det mer tid som den laster ned hele bibliotekfilen. Men fra andre gang og fremover tar det mindre tid å starte. SL OG CM er rene webapplikasjoner og kjører på nettleseren.

Enterprise Services Repository

her designer og lager vi objekter som skal brukes til å lage et integrasjonsscenario. Datastrømmen I PI vil se ut som vist nedenfor:

vi finner muligheten til å designe følgende

1. Grensesnittobjekter-Tjenestegrensesnitt, Meldingstype, Datatype
2. Kartleggingsobjekter-Operasjonskartlegging Og Meldingskartlegging
3. Integrasjonsprosesser

PI bruker integrasjonslager til å designe meldingsstruktur for både avsender – og mottakersystemer og utvikle en grensesnittmelding ved hjelp av tilsvarende meldingsstrukturer som fungerer som et interaksjonspunkt til omverdenen. Datatype og Meldingstype brukes til å forenkle og modulere utformingen av et komplekst grensesnitt.

Operation Mapping tillater transformasjon av kildestruktur til målstruktur når de to strukturene er forskjellige. Men hvis kilden og målstrukturen er samme, kan operasjonskartleggingen bli dispensert. I likhet med tjenestegrensesnitt brukes meldingskartlegging til å forenkle og modulere utformingen av en kompleks operasjonskartlegging. Meldingskartlegging kan implementeres på 4 måter

1. Grafisk Kartlegging
2. Java-Kartlegging
3. XSLT-Kartlegging
4. ABAP-Kartlegging

Grafisk kartlegging er den mest brukte Siden det tillater utvikler å kartlegge attributter for begge strukturer grafisk for å sende data ved hjelp av tjenestegrensesnitt. For de andre tre må vi utvikle kartleggingen ved å skrive kode. HVIS DET er en enkelt stack-server, VIL ABAP-tilordningen ikke være tilgjengelig.

Det er også andre områder, men de er ikke dekket i denne opplæringen.

Integrasjonskatalog

Her gjør vi rørlinjetrinnene ved å konfigurere ESR-objektene som er opprettet tidligere. Disse trinnene utføres av integrasjonsmotoren under kjøring.

før vi starter konfigurasjonen må vi opprette / importere følgende objekter i DIR.

1. Tjeneste-Forretningssystem/ Forretningstjeneste / Integrasjonsprosess
2. Kommunikasjonskanal

en tjeneste lar deg adressere en avsender eller mottaker av meldinger. Avhengig av hvordan du vil bruke tjenesten, kan du velge blant følgende tjenestetyper.

1. Forretningssystem-hvis du vil adressere et bestemt forretningssystem som avsender eller mottaker av meldinger, velger du denne tjenestetypen. Et forretningssystem er et faktisk applikasjonssystem i et systemlandskap.
2. Forretningstjeneste-hvis du vil adressere en abstrakt forretningsenhet som avsender eller mottaker av meldinger, velger du denne tjenestetypen. En forretningstjeneste er ikke definert i systemlandskapet.
3. Integration Process Service – hvis du vil adressere en integrasjonsprosess som avsender eller mottaker av meldinger, velger du denne tjenestetypen. Under kjøring styres disse integrasjonsprosessene av meldinger og kan selv sende meldinger.

Kommunikasjonskanal bestemmer innkommende og utgående behandling av meldinger. Meldingene konverteres fra native format til soap-xml bestemt meldingsformat og vice-versa gjennom adapteren. Vanligvis er det to typer kommunikasjonskanal i et scenario

1. Avsenderkommunikasjonskanal
2. Mottakerkommunikasjonskanal

du må tilordne en kommunikasjonskanal til en tjeneste. Avhengig av om tjenesten er adressert som avsender eller mottaker av meldinger, har den tildelte kommunikasjonskanalen rollen som enten en avsender eller en mottakerkanal, og må konfigureres tilsvarende. Du kan ikke tilordne en kommunikasjonskanal til en integrasjonsprosesstjeneste.

rørledningstrinnene opprettes ved å opprette FØLGENDE 4-konfigurasjon i DIR

Vi finner følgende alternativer:

1. Avsenderavtale
2. Mottakerbestemmelse
3. Grensesnittbestemmelse
4. Mottakeravtale

Avsenderavtale definerer hvordan meldingen til en avsender skal transformeres slik at Den kan behandles av Integrasjonsserveren. Den består av følgende

1. Avsenderkomponent
2. Avsendergrensesnitt
3. Avsenderkommunikasjonskanal

Avsenderavtalen ligner primærnøkkelen i tabellen. Det kan ikke være to lignende avsenderavtaler i ett landskap.

Mottakeravtale definerer hvordan meldingen skal transformeres slik at den kan behandles av en mottaker. Den består av

1. Avsenderkomponent
2. Mottakerkomponent
3. Mottakergrensesnitt
4. Mottakerkommunikasjonskanal

du bruker en mottakerkomponent til å angi hvilke mottakere en melding skal sendes til. Du har muligheten til å definere betingelser for videresending av meldingen til mottakerne. Den består av

1. Avsenderkomponent
2. Avsendergrensesnitt
3. Mottakerkomponent

Mottakerbestemmelse er Av To typer – Standard eller Utvidet, avhengig av om Du vil angi Mottakeren manuelt eller dynamisk ved en kartlegging under kjøring.

du bruker en grensesnittbestemmelse til å angi hvilket innkommende grensesnitt for en mottaker; meldingen skal videresendes til. Du kan også angi hvilken grensesnitttilordning fra Integrasjonsregisteret som skal brukes til å behandle meldingen, dvs. hvis avsender-og mottakergrensesnittet ikke er av samme format, er det en operativ kartlegging for å endre formatet. Du definerer en grensesnittbestemmelse for en avsender, et utgående grensesnitt og en mottaker. Den består av

1. Avsenderkomponent
2. Avsendergrensesnitt
3. Mottakerkomponent

Grensesnittbestemmelse er Av To typer – Standard eller Forbedret, avhengig av om du vil angi mottakergrensesnittet manuelt eller gjennom kartbasert meldingsdeling.

Mottakerbestemmelse og Grensesnittbestemmelse – de to sammen er kjent som den logiske rutingen. Avsenderavtale Og Mottakeravtale-de to sammen er kjent som Samarbeidsavtalen.

Systemlandskap

SAP System Landscape Directory (SLD) er den sentrale informasjonsleverandøren i et systemlandskap. På nettsiden finner du følgende lenker:

1. Teknisk System-Tekniske systemer er applikasjonssystemer som er installert i systemlandskapet.
2. Forretningssystem – Forretningssystemer er logiske systemer som fungerer som avsendere eller mottakere i PI. Forretningssystemer har en-til-en avhengighet med det tilhørende tekniske systemet.
3. Produkter Og Komponenter – dette er informasjon om alle TILGJENGELIGE SAP-produkter og komponenter, inkludert deres versjoner. Hvis det er noen tredjepartsprodukter i systemlandskapet, er de også registrert her.

SLD-ET vil se likt ut som angitt nedenfor:

Figur 11 – System Landskap

Produkter og Komponenter kalles Vanligvis Komponentinformasjonen

Teknisk System Og Forretningssystem kalles Vanligvis Landskapsbeskrivelsen.

et forretningssystem kan konfigureres Som En Integrasjonsserver eller Applikasjonssystem.

1. Integrasjonsserver – Integrasjonsserveren utfører bare integrasjonslogikk konfigurert i Integrasjonsverktøyet. De kan også identifiseres Som Rørledning Trinn. Den mottar XML-melding, bestemmer mottakeren, utfører tilordningene, og ruter XML-meldingen til de tilsvarende mottakersystemene. Dermed konfigurerte Integrasjonsmotor er identifisert Til Å Være Sentral Konfigurert Integrasjonsmotor.
2. Applikasjonssystem-Applikasjonssystemet vil ikke utføre integrasjonslogikken. Det kaller igjen integrasjonsserveren for å utføre integrasjonslogikken om nødvendig. Det fungerer som avsender eller mottaker AV XML-meldinger. Så, Applikasjonssystemet med en lokal Integrasjonsmotor krever Integrasjonsserveren for å utføre integrasjonslogikken.

Bare en KLIENT AV SAP-systemet kan konfigureres Som Integrasjonsserver.

følgende informasjon hentes fra SLD til ESR og DIR

1. Komponentinformasjon brukes I ESR for å definere Produktet OG SWCV
2. Forretningssystem brukes i Katalogen for å definere avsender og mottaker av meldinger

Konfigurasjon Og Overvåking

Det er det sentrale inngangspunktet for overvåkingsformål. Dette gir deg muligheten til å navigere til overvåkingsfunksjonene Til Integrasjonsmotoren, samt integrasjon med Computing Center Management System (CCMS) og Prosessovervåkingsinfrastrukturen (PMI) TIL SAP.

Konfigurasjonen og Overvåkingen vil se ut som angitt nedenfor:

Figur 13-Konfigurasjon Og Overvåking

Med Konfigurasjonen og Overvåking støttes følgende overvåkingsfunksjoner:

1. Komponent overvåking-overvåke ULIKE SAP PI komponenter (Java og ABAP deler).
2. Meldingsovervåking – sporing av meldingsbehandlingsstatusen i EN SAP PI-komponent og på feildeteksjon og analyse.
3. Ende-til-ende-overvåking-overvåking av en melding livssyklus FRA SAP PI synspunkt.
4. Ytelsesovervåking – statistikk om ulike ytelsesaspekter AV SAP PI kan nås via RWB. Her kan du velge og samle ytelsesdata, for eksempel etter komponent, tidsintervall eller meldingsattributter.
5. Indeksadministrasjon – ved å administrere og overvåke indekseringen av meldinger per SAP PI-komponent, aktiverer du et indeksbasert meldingssøk som du kan bruke i meldingsovervåking. Denne typen meldingssøk gir deg forbedrede utvalgskriterier, inkludert kortspesifikke meldingsattributter og vilkår eller setninger fra meldings nyttelast.
6. alert configuration – ved Å bruke Alert Framework, kan sentral overvåking I PI leveres med alle feil rapportert under meldingsbehandling I ABAP og Java. Dette muliggjør en forbedret reaksjon på slike feil i BÅDE ABAP runtime og Java-basert Adapter Engine. Til dette formål er Varslingsrammen utstyrt med regler basert på visse hendelser og på informasjon fra overskriften TIL PI-meldingsprotokollen. Disse reglene bestemmer om varsler sendes eller ikke. Hvis et varsel sendes, kan det brukes til feilanalyse.
7. varslingsinnboks – varslingsinnboksen er brukerspesifikk og viser alle varslene for hver varslingsserver som er generert basert på varselkonfigurasjonen.
8. Cache monitoring-cache overvåking viser objekter som er i runtime cache. Ulike cache objekter overvåkes avhengig av cache forekomst bekymret.

Synkron vs. Asynkron kommunikasjon

en prosess kan defineres som enten synkron eller asynkron.

• en synkron prosess påberopes av en forespørsel / svar-operasjon, og resultatet av prosessen returneres til den som ringer umiddelbart via denne operasjonen.
• en asynkron prosess påberopes av en enveisoperasjon, og resultatet og eventuelle feil returneres ved å påkalle andre enveisoperasjoner. Resultatet returneres til den som ringer via en tilbakeringing.

i datamaskinverdenen er det ingen asynkron kommunikasjon. All kommunikasjon mellom to systemer er alltid via metodekall (forespørsel/responsoperasjon). Så hvordan gjør vi det asynkron? Svaret ligger med innføringen av et tredje system mellom kalt og oppringerfunksjonen.

Anta at det er to systemer-A og B. All kommunikasjon Mellom A og B er via et metodekall og dermed er de synkrone. Vi introduserer et tredje system Mellom A Og B og kalte Det Mellomliggende system – I. kommunikasjonen Mellom A og I er via metodekall og på samme måte mellom I og B er også via metodekall. Men kommunikasjonen Mellom A Og B kan kalles asynkron, Da A ikke trenger å vente på svaret Fra B.

Dette er grunnlaget for asynkron kommunikasjon og hva er dette mellomliggende systemet? Det er Køen. A kalles avsender Og b kalles mottaker. Melding Fra A legges først til Køen, og så blir den igjen trukket fra Køen og sendt Til B. svaret fra B når A på lignende måte. I visse situasjoner krever forretningskravet at meldingene skal leveres Til B i samme rekkefølge som de utløses Fra A. I så fall følger vi en først-inn-og først-ut-policy. Hvis det ikke er slike krav, sender meldinger fra køen Til B i hvilken som helst rekkefølge.

med asynkron kommunikasjon oppnår Vi garantert levering, dvs. System B er ikke tilgjengelig når System A sender meldingen. Meldingen legges til i køen og forblir der så Lenge B ikke er tilgjengelig. Når B er tilgjengelig, blir meldingen trukket fra køen og sendt Til B.

Slik at vi kan klassifisere vår meldingskommunikasjon på tre måter:

1. Synkron
2. asynkron med ordre ikke opprettholdt
3. asynkron med ordre opprettholdt

I PI identifiserer vi DEM som: Synkron – BE (Best Effort), Asynkron med ordre ikke opprettholdt – EO (Nøyaktig En Gang), Asynkron med ordre opprettholdt – EOIO (Nøyaktig En Gang I Rekkefølge).

Bekreftelse

Bekreftelse er roten til asynkron kommunikasjon. Hvorfor?

For synkron kommunikasjon kaller System A system B, og Hvis B ikke sender svaret, mislyktes prosessen. Men I en asynkron kommunikasjon kaller System A System I Og System jeg kaller System B. så anta at kommunikasjonen Mellom A og jeg er vellykket, men mellom I Og B, mislykkes den. Hvordan skal A innse at leveransen Til B har mislyktes? Dette realiseres ved en bekreftelse som sendes Tilbake Til A av B via samme rute som meldingen fra a tok Til B. Hvis bekreftelsen fra B ikke kommer Til A, må Du vurdere at prosessen har mislyktes og vil sende meldingen igjen.

Mens vi diskuterte om asynkron kommunikasjon I PI, har vi brukt begrepet – ‘Nøyaktig En gang’ for BÅDE EO og EOIO. Nøyaktig En gang betyr en melding levert en gang ikke kan leveres igjen. For å oppnå dette er det en bekreftelse for hver melding som sendes Fra A Til B. det er adapterne som ligger på slutten av kommunikasjonen. Så adapterene må støtte bekreftelse.

alle adaptere gir systembekreftelse i.e. leveringsbekreftelse. De adaptere som støtter synkron kommunikasjon støtte søknad-bekreftelse i tillegg til systemet bekreftelse.

så I PI er følgende typen bekreftelse

1. Systembekreftelse-Systembekreftelser som brukes Av runtime-miljøet for å bekrefte at en asynkron melding har nådd mottakeren.
2. Programbekreftelse – programbekreftelser som brukes til å bekrefte at den asynkrone meldingen er behandlet på mottakeren.

Ekstern Funksjonskall

mens du arbeider I PI, kommer du over begrepet-RFC. Hva er de? For å etablere kommunikasjon mellom TO SAP-systemer, dvs.En R/3 og PI, oppretter VI RFC-Destinasjonen. Den er konfigurert av følgende

1. Tilkoblingstype
2. IP-Adresse OG Port på mottakeren

Tilkoblingstype forteller Typen Systemforbindelse, dvs.R/3, TCP/IP, Intern etc.

RFC-Destinasjonen vi lager er klassifisert i henhold til kommunikasjonsmåten som kreves, dvs. enten det skal støtte synkron eller asynkron kommunikasjon.

1. for synkron kommunikasjon – Synkron RFC
2. For asynkron kommunikasjon med ordre ikke vedlikeholdt – Transaksjonell RFC
3. For asynkron kommunikasjon med ORDRE vedlikeholdt RFC

de er identifisert av sRFC, tRFC og qRFC.

Case Studies – 1

Anta at du er i et klasserom og det er 10 studenter i det. Instruktøren ber deretter hver elev å forberede hans / hennes følgende personlige detaljer og lagre dem i EN XML-fil. Detaljene er som følger:

1. Student ID
2. Navn
3. Mobil
4. E-Post
5. Kjønn

det vil være 10 filer og filene er navngitt som cv_1,2,3….10. Filene lagres i kildekatalogen. For testformål følgende kataloger er opprettet:

Kilde katalog: c:\ibm\sap\training\input

Archive directory: c:\ibm\sap\training\archive

feilkatalog: c:\ ibm \ sap \ opplæring \ feil

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

Du blir bedt om å utvikle scenarier I SAP PI som vil lese kildefilene fra kildekatalogen og skrive dem til målkatalogen. Når en fil er lest fra kildekatalogen, bør den flyttes til arkivkatalogen, og hvis filen ikke kan leses for noen feil, dvs. Filene flyttet til arkiv, feil eller målkatalog skal ha et tidsstempel tilføye filnavnet.

1. dvs. filnavn + < tidsstempel>.

Leksjon-1

Forbered et scenario for å lese en enkelt fil, dvs.fil cv_1.xml fra kildekatalogen og skriv den til målkatalogen. Målfilnavnet skal også være cv_1.xml med tidsstempelet legger til navnet.

Leksjon-2

Forbered et scenario for å lese alle filene fra kildekatalogen og skrive dem til målkatalogen. På samme måte skal målfilene også bli navngitt som cv_1, 2 ..xml med tidsstempel legge til hver av dem.

Leksjon-3

instruktøren ber dere alle om å legge til følgende validering i dataene.

1. mobilnummeret skal ha 10 sifre – hvis mobilnummeret ikke er av 10 siffer, erstatt det med ‘feil’
2. e-posten skal ha ett ‘ @ ‘tegn og en’.’character – hvis e-posten ikke har’ @ ‘eller’.’tegn, erstatt det med ‘feil’

før du kjører scenariet, endrer du i noen av kildefilene mobilen og e-posten slik at de er feil i henhold til logikken som er gitt ovenfor.

Leksjon-4

Forbered et scenario for å lese alle kildefilene og klassifisere dem etter kjønn. Filene for mennene vil bli skrevet i en katalog og for damene til en annen katalog. To kataloger er opprettet for ovennevnte formål:

Målkatalog for menn: c:\ibm\sap\training\target\men

Målkatalog for kvinner: c:\ ibm \ sap \ training \ target \ women

Anta at det er 6 menn og 4 kvinner i klassen, så hvis alle kildefilene leses vellykket, bør målkatalogen for menn ha 6 filer og målkatalogen for kvinner skal ha 4 filer.

Case Studies – 2

instruktøren ber dere alle om å forberede en enkelt fil med de personlige detaljene til hver elev i separate segmenter.

Leksjon-5

Skriv et scenario som vil lese denne filen og produserer 10 målfiler hvor hver fil skal svare til personopplysningene til hver ansatt. Målfilene skal navngis som cv_<emp_ID > _ < tidsstempel>

Leksjon-6

Endre scenariet ovenfor slik at det produserer 2 målfiler i stedet for 10 hvor en målfil for menn og en annen målfil for damene. Målet fil for menn bør ha 6 segmenter for 6 menn og målet fil for damer bør ha 4 segmenter for 4 kvinner.

målfilene skal navngis som

for menn – men_<tidsstempel>

for Damer-women_<time_stamp>

Case Study -3

Samme som case study – 1, instruktøren ber hver elev om å forberede sin/hennes personlige detaljer og lagre dem i en xml – fil. Det vil være 10 filer. Filene lagres i kildekatalogen.

Leksjon-7

Forbered et scenario for å lese alle kildefilene fra kildekatalogen og opprette en enkelt fil i målkatalogen. Navnet på målfilen vil bli utdata.xml med tidsstempelet legger til filnavnet. Målfilen vil ha alle detaljene i hver kildefil som undersegment.

Leksjon-8

Forbered et scenario for å lese hele kildefilene fra kildekatalogen og lage to filer i målkatalogen-en for mennene og den andre for damene. For 6 menn, menn filen skal ha seks segmenter som har hver manns detaljer og for 4 kvinner, på samme måte bør det være 4 segmenter med hver dame detaljer.

Case Study-4

instruktøren ber nå hver av studentene om å forberede et annet sett med detaljer som vil bestå av hans / hennes følgende faglige detaljer:

1. Student ID
2. Skole Navn
3. College Navn
4. Avdeling Navn
5. Opptak År

det vil være 10 filer og filene er navngitt som ad_1, 2, 3….10. Filene lagres i kildekatalogen. Så hver student vil nå ha et par filer-en for de personlige detaljene og den andre for de faglige detaljene. To filer er co-relatert Med Studentbevis. Input katalogen består nå av 10 personlige filer og 10 akademiske filer.

Leksjon-9

du blir bedt om å utvikle et scenario som vil plukke kildefilene og vil behandle dem i par. Scenariet vil generere 10 målfiler. Hver målfil vil bestå av de personlige og faglige detaljene til en student i separate segmenter. Målfilene vil bli navngitt som res_1, 2, 10.

målfilene vil se ut som:

Leksjon – 10

du blir deretter bedt om å endre studentbevis i noen av filene slik at de ikke har matchende akademiske eller personlige filer og omvendt. Scenariet skal kjøre, og hvis det funnet noen filer som ikke har en tilsvarende tilsvarende fil så prosessen skal avsluttes etter en viss tid dvs. 2 min og disse filene vil bli flyttet til feilkatalogen, og det vil ikke være noen tilsvarende målfiler for dem.