SAP PI voor Beginners

doelstelling

het doel van deze handleiding is om u te laten begrijpen – wat is SAP Process Integration? We zullen niet ingaan op de nitty-gritty van het onderwerp, maar we zullen discussiëren over de architectuur en de verschillende kenmerken van SAP PI. We zullen alleen de basisfuncties behandelen en zullen voorkomen dat we alle functies in deze tutorial bespreken.

vervolgens vindt u een aantal casestudy ‘ s die u een idee zullen geven van het gebruik op industrieniveau van SAP PI. Als je eenmaal meer kennis hebt gemaakt met het onderwerp, moet je proberen ze op te lossen. De testcases zijn zo opgesteld dat ze je bij elke les van eenvoudig naar meer complexen in het onderwerp brengen en je een totaalbeeld van het onderwerp geven.

Wat is SAP ERP?

voor elk bedrijf – groot of klein, zijn dit de standaard zakelijke functies die het moet uitvoeren, d.w.z. materiaalbeheer, verkoop en distributie, financiën, personeel, enz. Er is veel software in de markt die wordt gebruikt door de industrie. U zult merken dat de eenvoudigste-de kassa genereren verkoopfactuur als u een bezoek aan een kleine winkel aan een netwerk van computers in een grote winkel, hotel etc die werken op een ERP. ERP is een effectieve aanpak die de meeste bedrijven toepassen om hun productiviteit en prestaties te verbeteren. SAP ERP is SAP AG ‘ s Enterprise Resource Planning, een geïntegreerde softwareoplossing die de belangrijkste bedrijfsfuncties van de organisatie omvat. De basisfuncties HR, MM, SD, FICO enz.worden in SAP business modules genoemd. SAP bouwt ze als producten en verkoopt ze in de markt. Er zijn nog twee modules die niet direct zakelijke functies ondersteunen, maar worden gebruikt voor presentatie en integratie. De eerste heet EP (Enterprise Portal) en de laatste heet PI (Process Integration). Alle business modules worden ontwikkeld in ABAP, terwijl EP en PI worden ontwikkeld meestal in Java. Deze modules zijn geen uitvoerbare bestanden, maar ze moeten worden ingezet in een applicatieserver dwz ABAP Web Application Server voor ABAP modules en Java Web Application Servers voor Java modules.

er zijn weinig punten die we moeten weten voordat we in het onderwerp springen.

• SAP staat voor Systems, Applications, and Products in Data Processing.

• SAP AG is een Duits multinationaal softwarebedrijf dat bedrijfssoftware maakt voor het beheer van de bedrijfsvoering en klantrelaties. SAP ERP is de Enterprise Resource Planning van het bedrijf, een geïntegreerde softwareoplossing die de belangrijkste bedrijfsfuncties van de organisatie omvat.

• SAP NetWeaver Process Integration (SAP PI) is SAP enterprise application integration (EAI) software, een onderdeel van de NetWeaver productgroep die wordt gebruikt om de uitwisseling van informatie tussen interne software en systemen van een bedrijf en die van externe partijen te vergemakkelijken.

oud systeem

bij de implementatie van het SAP ERP in een grote onderneming, blijkt dat niet alle secties onder het SAP ERP kunnen worden gebracht. Veel van de bedrijfsonderdelen kunnen hun eigen eigen tools hebben die zeer complex zijn en mogelijk niet kunnen worden vervangen. Ze lopen parallel aan het SAP-systeem. Ze worden de Legacy systemen genoemd. Dan is het noodzakelijk om te integreren tussen de SAP-systemen en dergelijke reeds bestaande niet-SAP-systeem. Dit is waar de SAP PI in het spel komt.

Waarom hebben we SAP PI naast bestaande systemen bestaat SAP ERP in een grote onderneming niet uit één enkel systeem, maar uit verschillende geïntegreerde systemen, zoals CRM, SRM en FICO, enz. Om met dergelijke complexiteiten om te gaan, introduceerde SAP procesintegratie een platform om één enkel integratiepunt voor alle systemen te bieden zonder het bestaande complexe netwerk van legacy-systemen aan te raken. Dit is een krachtige middleware van SAP om naadloze end-to-end integratie te bieden tussen SAP-en niet-SAP-toepassingen binnen en buiten de bedrijfsgrenzen. SAP PI ondersteunt zowel b2b als A2A-uitwisselingen, ondersteunt synchrone en asynchrone berichtenuitwisseling en bevat een ingebouwde engine voor het ontwerpen en uitvoeren van integratieprocessen.

architectuur van SAP PI

de SAP PI bestaat uit een hub-en spaakstructuur; de spaken verbinden met externe systemen terwijl de hub berichten tussen hen uitwisselt. Het bronsysteem staat bekend als het afzendersysteem en het doelsysteem staat bekend als het ontvangstsysteem. De PI is niet een enkel onderdeel, maar eerder een verzameling componenten die flexibel samenwerken om integratiescenario ‘ s te implementeren. De architectuur bevat componenten die tijdens het ontwerp, tijdens de configuratie en tijdens de looptijd moeten worden gebruikt.

we kunnen de SAP PI verdelen in verschillende gebieden

1. integratieserver
2. Integration Builder
3. System Landscape
4. configuratie en Monitoring

integratieserver is de centrale verwerkingsengine van de SAP PI. Alle berichten worden hier op een consistente manier verwerkt. Het bestaat uit drie afzonderlijke motoren

1. Integratiemotor
2. Adaptermotor
3. Bedrijfsprocesmotor

Integratiemotor kan worden beschouwd als de naaf en de Adaptermotor de spoke. Met betrekking tot de Business Process Engine, Ik zal het later uitleggen.

Integration Builder is een client-server framework voor het benaderen en bewerken van integratieobjecten en het bestaat uit twee gerelateerde tools:

1. Enterprise Service Repository – om objecten te ontwerpen en te ontwikkelen voor gebruik in scenario ‘s
2. Integratiemap-om de ESR-objecten te configureren om scenario’ s

te ontwikkelen twee samen bouwden we integratieprocessen die gewoonlijk scenario ‘ s worden genoemd.

het systeemlandschap is een centrale opslagplaats van informatie over software en systemen in datacenter en vereenvoudigt het beheer van uw systeemlandschap.

in Configuratie en Monitoring kunnen we de berichten en adapters controleren.

Single stack en Dual stack

toen PI voor het eerst werd uitgebracht, werden niet alle componenten op hetzelfde platform gebouwd. Integration Engine en Business Process Engine werd gebouwd in ABAP terwijl Adapter Engine, Integration Builder, SL, CM en Mapping Runtime werden gebouwd in Java. Dus PI heeft zowel de Java als de ABAP omgeving nodig om te draaien en staat bekend als de dual stack.

ABAP Stack	Java-Stack
Integratie Motor Business Process Engine Integratie Builder	Enterprise Service Repository Directory Integratie Runtime Werkbank System Landscape Directory Adapter Motor Mapping Runtime

Maar in de latere versie met alle componenten zijn gebouwd in Java. Sommige van de dual-stack componenten zijn ofwel afgevoerd of aangepast om te werken op de Java stack. Dus PI heeft alleen de Java omgeving nodig om te draaien en staat bekend als de single stack.

er zijn voors en tegens tussen de twee stapels, maar ze worden niet behandeld in deze tutorial.

Integratiemotor

de integratie-Engine is verantwoordelijk voor de centrale Integratieserverdiensten, d.w.z. de pipe-line stappen – Routering en toewijzing. Als de bronberichtstructuur verschilt van de doelberichtstructuur, roept integration engine de looptijd van de toewijzing aan, waarbij de bronstructuur wordt geconverteerd naar de doelstructuur. De Mapping Runtime is gebaseerd op de Java stack. De integratie engine kan ook gebruik maken van een ABAP programma voor de conversie, die is gebaseerd op de ABAP stack.

een bericht kan bestaan uit twee typen

1. synchroon-heeft zowel het verzoek-antwoordgedeelte
2. asynchroon-heeft ofwel het verzoek of het antwoordgedeelte alleen

in PI wordt het bericht weergegeven door een interface.

Interface -> structuur van het bericht in XML – formaat + richting

op basis van de bovenstaande criteria zijn er drie soorten interfaces

1. uitgaande interface – verbinding maken met het afzendersysteem
2. inkomende interface – verbinding maken met het ontvangersysteem
3. Abstracte interface-verbinding maken met de BPE

wanneer we integratielogica (scenario) configureren in de SAP PI volgens onze business requirements, het is de integratie engine die die configuratie uitvoert in een stapsgewijze manier. Pipeline is de term die wordt gebruikt om te verwijzen naar alle stappen die worden uitgevoerd tijdens de verwerking van een XML-bericht. De leiding-Line stappen bestaan uit de volgende:

1. ontvanger identificatie-bepaalt het systeem dat deelneemt aan de uitwisseling van het bericht.
2. Interfacebepaling-bepaal welke interface het bericht moet ontvangen.
3. Message Split-als er meer dan één ontvanger wordt gevonden, zal PI voor elke ontvanger een nieuw bericht instantiëren.
4. Message Mapping-mapping om het bronbericht te transformeren naar het doelberichtformaat.
5. technische Routing-bind een specifieke bestemming en protocol aan het bericht.
6. Oproepadapter: stuur het getransformeerde bericht naar de adapter of een proxy.

Adapter-Engine

u moet eerder hebben gemerkt dat de integratie-engine alleen berichten in het XML-SOAP-protocol verwerkt. Maar wat als we een afzender en een ontvanger bedrijfssysteem hebben waar de gegevens niet in hetzelfde formaat zijn. We gebruiken de verschillende adapters in de adapter Engine om XML – en HTTP-gebaseerde berichten om te zetten naar het specifieke protocol en formaat dat vereist is door deze systemen, en vice versa.

zoals we eerder hebben besproken, SAP PI is een hub en spaak structuur waar de adapter motor kan worden beschouwd als spaak. We gebruiken de adapter Engine om de integratie Engine (Hub) aan te sluiten op de externe systemen. Het Adapterkader is de basis van de Adaptermotor. Het Adapter Framework is gebaseerd op de SAP J2EE Engine (als onderdeel van de SAP Web Application Server) en de J2EE Connector Architecture (JCA). Het Adapter Framework biedt interfaces voor configuratie, beheer en monitoring van adapters.

in een dual stack systeem waren de meeste adapters gebaseerd op de Java stack, met uitzondering van twee adapters die gebaseerd zijn op de ABAP stack.

Java-Stack	RFC adapter, SAP Business Connector adapter, file/FTP-adapter, JDBC-adapter, JMS-adapter, ZEEP-adapter, Marktplaats Adapter, Mail adapter, STAAT.RNIS adapter, CIDX adapter
ABAP stack	IDOC-adapter en HTTP adapter

Als SAP PI verplaatst van dual stack stapel dan deze twee adapters werd een deel van de Java stack. De gewijzigde adaptermotor staat bekend als de Advance Adapter Engine en de twee adapters worden respectievelijk de idoc_aae adapter en HTTP_AAE adapter genoemd.

Business Process Engine

De Business Process Engine is verantwoordelijk voor het uitvoeren en voortzetten van integratieprocessen.

BPM staat voor cross-component Business Process Management of ccBPM en wordt ook wel integratieproces genoemd. Een integratieproces is een uitvoerbaar, systeemoverschrijdend proces voor het verwerken van berichten. In een integratieproces definieer je alle processtappen die moeten worden uitgevoerd en de parameters die relevant zijn voor het aansturen van het proces. Business Process Management biedt SAP Exchange Infrastructure de volgende functies:

1. State-full message processing: de status van een integratieproces wordt gehandhaafd op de integratieserver.
2. u kunt ook correlaties gebruiken om semantische relaties tussen berichten tot stand te brengen.
3. u implementeert integratieprocessen wanneer u complexe integratieprocessen wilt definiëren, beheren en bewaken die zich uitstrekken over bedrijfs-en toepassingsgrenzen, d.w.z. verzamelen/samenvoegen, splitsen, Multicast

tijdens runtime voert de Business Process Engine de integratieprocessen uit. Het integratieproces kan berichten verzenden en ontvangen met behulp van abstracte interfaces alleen.

Bouw een scenario in SAP PI

we starten vanaf de startpagina als we een scenario in PI moeten bouwen.

de homepage zal er vergelijkbaar uitzien als hieronder:

Figuur 6-homepage voor SAP PI Java Stack

de homepage heeft hyperlinks naar de volgende 4 werkgebieden

1. Enterprise Services Repository (ESR)
2. Integration Directory (ID)
3. System Landscape (SL)
4. configuratie en Monitoring (CM))

elke hyperlink opent een toepassing. Al deze vier zijn Java applicatie. ESR en ID zijn swing toepassingen. Ze worden gestart vanuit de browser op basis van JNLP. Dus voor de eerste keer duurt het meer tijd als het downloadt de hele bibliotheek bestand. Maar vanaf de tweede keer kost het minder tijd om te lanceren. SL en CM zijn pure webapplicaties en draaien op de browser.

Enterprise Services Repository

hier ontwerpen en maken we objecten die gebruikt kunnen worden bij het maken van een integratiescenario. De gegevensstroom in PI zal er vergelijkbaar uitzien zoals hieronder getoond:

we vinden de optie om de volgende

1. Interface objects – Service Interface, Message Type, Data Type
2. Mapping objects – Operation Mapping en Message Mapping
3. integratieprocessen te ontwerpen

PI maakt gebruik van integration repository om berichtstructuur te ontwerpen voor zowel zender-als ontvangersystemen en een interfacebericht te ontwikkelen met behulp van overeenkomstige berichtstructuren die fungeren als een interactiepunt naar de buitenwereld. Gegevenstype en berichttype worden gebruikt om het ontwerp van een complexe interface te vereenvoudigen en te modulariseren.

Operation Mapping maakt transformatie van bronstructuur naar doelstructuur mogelijk wanneer de twee structuren verschillend zijn. Maar als de bron en de doelstructuur hetzelfde zijn dan kan de operatie mapping worden verwijderd. Net als service interface wordt message mapping gebruikt om het ontwerp van een complexe operatie mapping te vereenvoudigen en modulariseren. Message mapping kan op 4 manieren worden geïmplementeerd

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

grafische mapping wordt het meest gebruikt omdat het ontwikkelaar in staat stelt attributen van beide structuren grafisch toe te wijzen om gegevens door te geven met behulp van service interfaces. Voor de andere drie moeten we de mapping ontwikkelen door code te schrijven. Als het een single stack server is, dan zal de ABAP toewijzing niet beschikbaar zijn.

er zijn ook andere gebieden, maar ze worden niet behandeld in deze tutorial.

Integration Directory

hier maken we de pipe-line stappen door de eerder gemaakte ESR objecten te configureren. Deze stappen worden uitgevoerd door de integratie-engine tijdens de looptijd.

voordat we de configuratie starten moeten we de volgende objecten in de map aanmaken/importeren.

1. Service-Business System/ Business Service / integratieproces
2. communicatiekanaal

met een service kunt u een afzender of ontvanger van berichten aanspreken. Afhankelijk van hoe u de service wilt gebruiken, kunt u kiezen uit de volgende servicetypen.

1. bedrijfssysteem – als u een bepaald bedrijfssysteem wilt aanspreken als afzender of ontvanger van berichten, kiest u dit servicetype. Een bedrijfssysteem is een daadwerkelijk applicatiesysteem in een systeemlandschap.
2. zakelijke dienst-als u een abstracte zakelijke entiteit wilt aanspreken als afzender of ontvanger van berichten, kiest u dit servicetype. Een zakelijke dienst wordt niet gedefinieerd in het systeemlandschap.
3. integratieproces Service-als u een integratieproces wilt aanspreken als afzender of ontvanger van berichten, kiest u dit servicetype. Tijdens runtime worden deze integratieprocessen gecontroleerd door berichten en kunnen ze zelf berichten verzenden.

communicatiekanaal bepaalt de inkomende en uitgaande verwerking van berichten. De berichten worden geconverteerd van native formaat naar soap-xml specifieke bericht formaat en vice versa via de adapter. In het algemeen zijn er twee soorten communicatiekanalen in een scenario

1. zender communicatiekanaal
2. ontvanger communicatiekanaal

u moet een communicatiekanaal toewijzen aan een service. Afhankelijk van het feit of de dienst wordt geadresseerd als afzender of ontvanger van berichten, heeft het toegewezen communicatiekanaal de rol van afzender of ontvanger en moet het dienovereenkomstig worden geconfigureerd. U kunt geen communicatiekanaal toewijzen aan een integratieprocess-service.

de pipe-line stappen worden gemaakt door het maken van de volgende 4 configuratie in de DIR

vinden we de volgende opties:

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

Sender agreement definieert hoe het bericht van een afzender moet worden getransformeerd zodat het door de integratieserver kan worden verwerkt. Het bestaat uit de volgende

1. Afzendercomponent
2. Afzenderinterface
3. Afzendercommunicatiekanaal

Afzenderovereenkomst is vergelijkbaar met de primaire sleutel in de tabel. Het kan niet zo zijn dat de twee overeenkomsten van dezelfde afzender in één landschap voorkomen.

Ontvangerovereenkomst bepaalt hoe het bericht moet worden getransformeerd zodat het door een ontvanger kan worden verwerkt. Het bestaat uit

1. zender-Component
2. ontvanger-Component
3. Ontvangerinterface
4. Ontvangercommunicatiekanaal

u gebruikt een ontvanger-bepaling om aan te geven naar welke ontvangers een bericht moet worden verzonden. U heeft de mogelijkheid om voorwaarden te definiëren voor het doorsturen van het bericht naar de ontvangers. Het bestaat uit

1. Sender Component
2. Sender Interface
3. ontvanger Component

ontvanger bepaling is van twee types – standaard of uitgebreid, afhankelijk van of u de ontvanger handmatig of dynamisch wilt specificeren door een toewijzing tijdens runtime.

u gebruikt een interfacebepaling om aan te geven naar welke binnenkomende interface van een ontvanger het bericht moet worden doorgestuurd. U kunt ook opgeven welke interface-toewijzing van de integratie Repository moet worden gebruikt voor het verwerken van het bericht, d.w.z. als de afzender en de ontvangstinterface niet van hetzelfde formaat zijn, is er een operationele toewijzing om het formaat te wijzigen. U definieert een interface-bepaling voor een afzender, een uitgaande interface en een ontvanger. Het bestaat uit

1. Sender Component
2. Sender Interface
3. Ontvangercomponent
4. Ontvangerinterface

de Interfacebepaling bestaat uit twee typen: standaard of verbeterd, afhankelijk van of u de ontvangerinterface handmatig wilt specificeren of door middel van op mapping gebaseerde berichtsplitsing.

ontvanger bepaling en interface bepaling-de twee samen zijn algemeen bekend als de logische routing. Afzender Overeenkomst en ontvanger overeenkomst – de twee samen zijn algemeen bekend als de samenwerkingsovereenkomst.

System Landscape

de SAP System Landscape Directory (SLD) is de centrale informatieverstrekker in een systeemlandschap. In de web pagina vindt u de volgende links:

1. technisch systeem-technische systemen zijn applicatiesystemen die in uw systeemlandschap zijn geïnstalleerd.Bedrijfssysteem-bedrijfssystemen zijn logische systemen, die functioneren als afzenders of ontvangers binnen PI. Business Systems heeft één-op-één afhankelijkheid met het bijbehorende technische systeem.
2. producten en componenten – Dit is informatie over alle beschikbare SAP-producten en componenten, inclusief hun versies. Als er producten van derden in het systeemlandschap zijn, zijn deze ook hier geregistreerd.

de snelheidsbegrenzer zal er vergelijkbaar uitzien als hieronder:

Figuur 11-systeemlandschap

producten en componenten worden gewoonlijk de Componentinformatie

technisch systeem en bedrijfssysteem worden gewoonlijk de Landschapsbeschrijving genoemd.

een bedrijfssysteem kan worden geconfigureerd als een integratieserver of toepassingssysteem.

1. integratieserver-de integratieserver voert alleen integratielogica uit die is geconfigureerd in de Integratiebouwer. Ze kunnen ook worden geïdentificeerd als Pipe Line stappen. Het ontvangt XML-bericht, bepaalt de ontvanger, voert de toewijzingen uit en stuurt het XML-bericht naar de bijbehorende ontvangersystemen. Zo geconfigureerde integratie Engine wordt geïdentificeerd als centrale geconfigureerde integratie engine.
2. toepassingssysteem-het toepassingssysteem zal de integratielogica niet uitvoeren. Het roept op zijn beurt de integratie server om de integratie logica uit te voeren indien nodig. Het fungeert als afzender of ontvanger van XML-berichten. Dus, het applicatiesysteem met een lokale integratie Engine vereist de integratie server om de integratie logica uit te voeren.

slechts één client van het SAP-systeem kan als integratieserver worden geconfigureerd.

de volgende informatie wordt uit de SLD geëxtraheerd in het ESR en DIR

1. Componentinformatie wordt in het ESR gebruikt om het Product te definiëren en het Swcv
2. bedrijfssysteem wordt gebruikt in de Directory voor het definiëren van de afzender en ontvanger van berichten

configuratie en Monitoring

het is het centrale invoerpunt voor monitoringdoeleinden. Dit geeft u de mogelijkheid om te navigeren naar de bewakingsfuncties van de Integration Engine, evenals integratie met het Computing Center Management System (CCMS), en de Process Monitoring Infrastructure (PMI) van SAP.

de configuratie en Monitoring zullen er vergelijkbaar uitzien als hieronder:

Figuur 13-configuratie en bewaking

met de configuratie en bewaking worden de volgende bewakingsfuncties ondersteund:

1. Component monitoring-monitoring van de verschillende SAP PI componenten (Java en ABAP onderdelen).
2. Berichtmonitoring-het volgen van de status van berichtverwerking binnen een SAP PI-component en bij foutdetectie en-analyse.
3. End-to-end monitoring-monitoring van een levenscyclus van berichten vanuit het oogpunt van SAP PI.
4. prestatiemonitoring-statistieken over verschillende prestatieaspecten van SAP PI kunnen worden geraadpleegd via de RWB. Hier kunt u prestatiegegevens selecteren en samenvoegen, bijvoorbeeld op component -, tijdbereik-of berichtattributen.
5. Indexbeheer – door het beheren en bewaken van de indexering van berichten per SAP PI-component, schakelt u een op index gebaseerde zoekopdracht in die u kunt gebruiken bij berichtbewaking. Dit soort bericht Zoeken biedt u verbeterde selectiecriteria, waaronder adapter-specifieke bericht attributen en termen of zinnen uit het bericht payload.
6. Alert configuratie – door gebruik te maken van het Alert Framework, kan centrale monitoring in PI worden voorzien van alle fouten die worden gemeld tijdens de berichtverwerking in ABAP en Java. Dit maakt een verbeterde reactie op dergelijke fouten in zowel de ABAP runtime en de Java-gebaseerde Adapter Engine. Hiertoe wordt het Waarschuwingskader voorzien van regels die gebaseerd zijn op bepaalde gebeurtenissen en op informatie uit de koptekst van het PI-berichtprotocol. Deze regels bepalen of waarschuwingen worden verzonden of niet. Als een waarschuwing wordt verzonden, kan deze worden gebruikt voor foutanalyse.
7. Alert-inbox-de alert-inbox is gebruikerspecifiek en toont alle waarschuwingen voor elke alert-server die is gegenereerd op basis van de alert-configuratie.
8. Cachebewaking-cachebewaking toont objecten die zich momenteel in de runtime-cache bevinden. Verschillende cache objecten worden gecontroleerd, afhankelijk van de cache instantie in kwestie.

synchrone vs. asynchrone communicatie

een proces kan worden gedefinieerd als synchroon of asynchroon.

• een synchrone proces wordt aangeroepen door een verzoek / reactie operatie, en het resultaat van het proces wordt onmiddellijk via deze operatie aan de beller teruggegeven.
• een asynchroon proces wordt aangeroepen door een eenrichtingsoperatie en het resultaat en eventuele fouten worden geretourneerd door andere eenrichtingsoperaties aan te roepen. Het resultaat wordt teruggestuurd naar de beller via een callback operatie.

in de computerwereld is er geen asynchrone communicatie. Alle communicatie tussen twee systemen verloopt altijd via method call (request/response operation). Hoe maken we het asynchroon? Het antwoord ligt bij de invoering van een derde systeem tussen de aangeroepen en de beller functie.

stel dat er twee systemen zijn-A en B. Alle communicatie tussen A en B is via een methodeaanroep en dus zijn ze synchroon. We introduceren een derde systeem tussen A en B en noemen het het intermediaire systeem – I. de communicatie tussen A en I is via methodeaanroep en op dezelfde manier tussen I en B is ook via methodeaanroep. Maar de communicatie tussen A en B kan asynchroon worden genoemd omdat A niet hoeft te wachten op de reactie van B.

dit is de basis van asynchrone communicatie en wat is dit intermediaire systeem? Dat is de rij. A wordt de afzender genoemd en B wordt de ontvanger genoemd. Bericht van A wordt eerst toegevoegd aan de wachtrij en dan wordt het weer getrokken uit de wachtrij en verzonden naar B. De reactie van B bereikt A op een soortgelijke manier. In bepaalde situaties moeten de berichten in dezelfde volgorde aan B worden bezorgd als ze vanuit A. worden geactiveerd. in dat geval volgen we een first-in en first-out beleid. Als er geen dergelijke vereisten zijn, worden berichten vanuit de wachtrij naar B in willekeurige volgorde verzonden.

met asynchrone communicatie bereiken we gegarandeerde levering, d.w.z. systeem B is niet beschikbaar wanneer Systeem A het bericht verstuurt. Het bericht wordt toegevoegd aan de wachtrij en blijft daar zolang B niet beschikbaar is. Zodra B beschikbaar is, wordt het bericht verwijderd uit de wachtrij en stuurt B.

Dus we kunnen classificeren onze boodschap communicatie op drie manieren:

1. Synchrone
2. Asynchrone met orde niet gehandhaafd
3. Asynchrone met orde gehandhaafd

In PI, we zien hen als: Synchroon – WORDEN (Best Effort), Asynchrone met orde niet gehandhaafd – EO (Precies één Keer)Asynchrone met orde gehandhaafd – EOIO (Precies één Keer in deze Volgorde).

bevestiging

bevestiging is de basis van asynchrone communicatie. Waarom?

voor synchrone communicatie roept Systeem A systeem B op en als B het antwoord niet verstuurt, is het proces mislukt. Maar in een asynchrone communicatie, systeem A roept systeem I en Systeem I roept systeem B. dus stel dat de communicatie tussen A en I is succesvol, maar tussen I en B, het mislukt. Hoe moet A zich realiseren dat de levering aan B is mislukt? Dit wordt gerealiseerd door een bevestiging die wordt teruggestuurd naar A door B via dezelfde route als het bericht van A nam naar B. Als de bevestiging van B er niet in slaagt om te komen tot A dan a van mening dat het proces is mislukt en zal het bericht opnieuw te sturen.

terwijl we spraken over asynchrone communicatie in PI, hebben we de term – ‘precies één keer’ gebruikt voor zowel EO als EOIO. Precies één keer betekent dat een bericht dat eenmaal is afgeleverd, niet opnieuw kan worden afgeleverd. Om dit te bereiken, is er een bevestiging voor elk bericht dat van A naar B wordt verzonden.het zijn de adapters die aan het einde van de communicatie liggen. De adapters moeten dus bevestiging ondersteunen.

alle adapters bieden systeem-bevestiging i.e.ontvangstbevestiging. Adapters die synchrone communicatie ondersteunen, ondersteunen applicatie-bevestiging naast de systeembevestiging.

in PI volgt het type bevestiging

1. Systeembevestiging – systeembevestiging die door de runtime-omgeving wordt gebruikt om te bevestigen dat een asynchrone boodschap de ontvanger heeft bereikt.
2. bevestiging van toepassing-bevestiging van toepassing om te bevestigen dat het asynchrone bericht met succes is verwerkt op de ontvanger.

remote Function Call

tijdens het werken in PI komt u de term – RFC tegen. Wat zijn dat? Om communicatie tot stand te brengen tussen twee SAP-systemen, namelijk een R/3 en PI, creëren we de RFC-bestemming. Het wordt geconfigureerd door het volgende

1. verbindingstype
2. IP-adres en Poort van de ontvanger

verbindingstype geeft het type systeemverbinding aan, d.w.z. R/3, TCP / IP, intern enz.

de RFC-bestemming die we creëren is geclassificeerd volgens de vereiste communicatiewijze, d.w.z. of het synchrone of asynchrone communicatie moet ondersteunen.

1. voor synchrone communicatie – synchrone RFC
2. voor asynchrone communicatie met order not maintain – transactionele RFC
3. voor asynchrone communicatie met order maintain – Queued RFC

zij worden geïdentificeerd door sRFC, tRFC en qRFC.

casestudy ‘ s-1

stel dat u zich in een klaslokaal bevindt en er 10 studenten in zitten. De instructeur vraagt vervolgens aan elke student om de volgende persoonlijke gegevens voor te bereiden en op te slaan in een XML-bestand. De details zijn als volgt:

1. Student ID
2. naam
3. mobiel
4. e-mail
5. geslacht

er zullen 10 bestanden zijn en de bestanden worden genoemd als cv_1,2,3….10. De bestanden worden opgeslagen in de bronmap. Voor testdoeleinden worden de volgende mappen aangemaakt:

bronmap: c:\ibm\sap\training\input

archiefmap: c:\ibm\sap\training\archive

Foutmap: c:\ibm \ sap \ training \ error

doelmap: c:\ibm\sap\training\target

u wordt gevraagd om scenario ‘ s te ontwikkelen in SAP PI die de bronbestanden uit de brondirectory lezen en naar de doeldirectory schrijven. Zodra een bestand met succes wordt gelezen van de brondirectory, zou het naar de archiefdirectory moeten worden verplaatst en als het bestand niet voor één of andere fout kan worden gelezen dwz XML-formaat niet gehandhaafd, zou het naar de foutdirectory moeten worden verplaatst. De bestanden verplaatst naar archief, fout of doelmap moet een time-stamp hebben toegevoegd aan de bestandsnaam.

1. d.w.z. bestandsnaam + <tijdstempel>.

Les-1

Maak een scenario klaar om één enkel bestand te lezen, d.w.z. bestand cv_1.xml uit de bronmap en schrijf het naar de doelmap. De doelbestandsnaam moet ook cv_1 zijn.xml met de tijdstempel toegevoegd aan de naam.

Les-2

Maak een scenario om alle bestanden uit de bronmap te lezen en ze naar de doelmap te schrijven. Op dezelfde manier moeten de doelbestanden ook worden genoemd als cv_1, 2 ..xml met de time-stamp toe te voegen aan elk van hen.

Les-3

de instructeur vraagt u vervolgens om de volgende validatie toe te voegen aan de gegevens.

1. het mobiele nummer moet 10 numerieke cijfers hebben – als het mobiele nummer niet van 10 cijfers is, vervang het dan door ‘error’
2. de e-mail moet één ‘ @ ‘ – teken en één ‘hebben.’karakter-als de e-mail niet de ‘@’ of ‘.’karakter, dan vervangen door ‘fout’

voordat u het scenario uit te voeren, in sommige van de bronbestanden, wijzigen van de mobiele en de e-mail, zodat ze in fout volgens de logica hierboven gegeven.

Les-4

Maak een scenario om alle bronbestanden te lezen en ze te classificeren volgens hun geslacht. De bestanden voor de mannen worden in een directory geschreven en voor de dames in een andere directory. Er worden twee mappen aangemaakt voor het bovenstaande doel:

doelmap voor mannen: c:\ibm\sap\training\target\men

doelmap voor vrouwen: c:\ibm \ sap \ training \ target \ women

stel dat er 6 mannen en 4 vrouwen in de klas zitten, dan moet, als alle bronbestanden met succes worden gelezen, de doelmap voor mannen 6 bestanden hebben en de doelmap voor vrouwen 4 bestanden.

casestudy ‘ s-2

de instructeur vraagt u vervolgens één enkel dossier samen te stellen met de persoonlijke gegevens van elke student in afzonderlijke segmenten.

Les-5

Schrijf een scenario dat dit bestand zal lezen en 10 doelbestanden produceert waarbij elk bestand moet overeenkomen met de persoonlijke gegevens van elke werknemer. De doelbestanden moeten worden benoemd als cv_<emp_ID>_<tijdstempel>

Les-6

Wijzig het bovenstaande scenario zodat het 2 doelbestanden produceert in plaats van 10 waarbij een doelbestand voor mannen en een ander doelbestand voor de dames. Het doelbestand voor mannen moet 6 segmenten voor 6 mannen hebben en het doelbestand voor dames moet 4 segmenten voor 4 vrouwen hebben.

de doelbestanden moeten worden genoemd als

voor mannen-men_<time-stamp>

voor dames-Vrouwen_<time_stamp>

Case Study -3

hetzelfde als case study-1 vraagt de instructeur elke student zijn/haar persoonlijke gegevens voor te bereiden en op te slaan in een XML-bestand. Er zullen 10 dossiers zijn. De bestanden worden opgeslagen in de bronmap.

Les-7

Maak een scenario om alle bronbestanden uit de bronmap te lezen en om één enkel bestand in de doelmap aan te maken. De naam van het doelbestand zal worden uitgevoerd.xml met de tijdstempel toegevoegd aan de bestandsnaam. Het doelbestand zal alle details van elk bronbestand als subsegment hebben.

Les-8

Maak een scenario om de volledige bronbestanden uit de bronmap te lezen en maak twee bestanden in de doelmap – een voor de mannen en de andere voor de dames. Voor 6 mannen moet het Mannen-bestand zes segmenten hebben met de details van elke man en voor 4 vrouwen moeten er ook 4 segmenten zijn met de details van elke dame.

casestudy-4

de instructeur vraagt nu aan elk van de studenten om een andere set details voor te bereiden die zal bestaan uit zijn/haar de volgende academische details:

1. studenten-ID
2. schoolnaam
3. Universiteitsnaam
4. Afdelingsnaam
5. Toelatingsjaar

er zullen 10 bestanden zijn en de bestanden worden genoemd als ad_1, 2, 3….10. De bestanden worden opgeslagen in de bronmap. Dus elke student zal nu een paar bestanden-een voor de persoonlijke gegevens en de andere voor de academische gegevens. Twee dossiers zijn mede gerelateerd aan de studentenkaart. De input directory bestaat nu uit 10 persoonlijke bestanden en 10 academische bestanden.

Les-9

u wordt gevraagd een scenario te ontwikkelen dat de bronbestanden zal kiezen en in paren zal verwerken. Het scenario zal 10 doelbestanden genereren. Elk doelbestand zal bestaan uit de persoonlijke en academische gegevens van een student in afzonderlijke segmenten. De doelbestanden worden genoemd als res_1, 2, 10.

de doelbestanden zullen er zo uitzien:

les-10

u wordt vervolgens gevraagd om de studenten-ID in sommige bestanden te wijzigen zodat ze geen overeenkomende academische of persoonlijke bestanden hebben en vice versa. Het scenario moet worden uitgevoerd en als het gevonden bestanden die geen overeenkomende bijbehorende bestand dan het proces moet eindigen na een bepaalde periode dat wil zeggen 2 min en die bestanden worden verplaatst naar de fout directory en er zullen geen overeenkomstige doelbestanden voor hen.