SAP PI per principianti

Obiettivo

L’obiettivo di questo tutorial è quello di farvi capire – che cosa è SAP Process Integration? Non entreremo nel nocciolo dell’argomento, ma discuteremo dell’architettura e delle diverse caratteristiche di SAP PI. Tratteremo solo le funzionalità di base ed eviteremo di discutere tutte le funzionalità in questo tutorial.

Avanti ci sono una serie di casi di studio che vi darà un’idea circa l’utilizzo a livello di settore di SAP PI. Una volta che hai più familiarità con l’argomento, dovresti provare a risolverli. I casi di test sono preparati in modo tale che vi porterà verso il basso nel soggetto da semplice a più complessi con ogni lezione e vi darà un’idea generale del soggetto.

Che cos’è SAP ERP?

Per qualsiasi azienda, grande o piccola, queste sono le funzionalità aziendali standard che deve svolgere, ovvero Gestione dei materiali, vendite e distribuzione, finanza, risorse umane ecc. C’è molto software sul mercato che viene utilizzato dall’industria. Si noterà il più semplice – la macchina cassiere generando fattura di vendita se si visita un piccolo negozio a una rete di computer in un grande negozio al dettaglio, hotel ecc che operano su un ERP.

Enterprise Resource Planning ovvero ERP è un approccio efficace che la maggior parte delle aziende implementa per migliorare la produttività e le prestazioni. SAP ERP è la pianificazione delle risorse aziendali di SAP AG, una soluzione software integrata che incorpora le funzioni aziendali chiave dell’organizzazione. Le funzionalità di base cioè HR, MM, SD, FICO ecc sono chiamati moduli di business in SAP. SAP li costruisce come prodotti e li vende sul mercato. Ci sono altri due moduli che non supportano direttamente le funzioni aziendali ma vengono utilizzati per la presentazione e l’integrazione. Il primo si chiama EP (Enterprise Portal) e il secondo si chiama PI (Process Integration). Tutti i moduli aziendali sono sviluppati in ABAP mentre EP e PI sono sviluppati principalmente in Java. Questi moduli non sono eseguibili ma devono essere distribuiti in un server di applicazioni, ad esempio ABAP Web Application Server per i moduli ABAP e Java Web Application Server per i moduli Java.

Ci sono alcuni punti che dovremmo sapere prima di saltare nell’argomento.

• SAP sta per Sistemi, applicazioni e prodotti nell’elaborazione dei dati.

• SAP AG è una multinazionale tedesca di software che produce software enterprise per gestire le operazioni aziendali e le relazioni con i clienti. SAP ERP è Enterprise Resource Planning della società, una soluzione software integrata che incorpora le funzioni aziendali chiave dell’organizzazione.

• SAP NetWeaver Process Integration (SAP PI) è un software SAP Enterprise Application Integration (EAI), un componente del gruppo di prodotti NetWeaver utilizzato per facilitare lo scambio di informazioni tra il software e i sistemi interni di un’azienda e quelli di parti esterne.

Sistema legacy

Durante l’implementazione di SAP ERP in un grande stabilimento aziendale, si scopre che non tutte le sezioni possono essere portate sotto SAP ERP. Molte delle sezioni aziendali possono avere i propri strumenti proprietari che sono altamente complessi e potrebbero non essere possibili per essere sostituiti. Corrono parallele al sistema SAP. Sono chiamati i sistemi legacy. Quindi diventa necessario integrare tra i sistemi SAP e tale sistema non SAP preesistente. Questo è dove il SAP PI entra in gioco.

Perché abbiamo bisogno di SAP PI Oltre ai sistemi legacy, in una grande azienda, SAP ERP non è costituito da un unico sistema ma da diversi sistemi integrati, ad esempio CRM, SRM e FICO ecc. Per gestire tali complessità SAP ha introdotto l’integrazione dei processi una piattaforma per fornire un unico punto di integrazione per tutti i sistemi senza toccare la complessa rete esistente di sistemi legacy. Si tratta di un potente middleware di SAP per fornire un’integrazione end-to-end perfetta tra applicazioni SAP e non SAP all’interno e all’esterno dei confini aziendali. SAP PI supporta gli scambi B2B e A2A, supporta lo scambio di messaggi sincroni e asincroni e include un motore integrato per la progettazione e l’esecuzione di processi di integrazione.

Architettura di SAP PI

Il SAP PI è costituito da una struttura hub e spoke; i raggi si collegano con sistemi esterni mentre l’hub scambiano messaggi tra di loro. Il sistema di origine è noto come sistema mittente e il sistema di destinazione è noto come sistema ricevente. Il PI non è un singolo componente, ma piuttosto un insieme di componenti che lavorano insieme in modo flessibile per implementare scenari di integrazione. L’architettura include componenti da utilizzare in fase di progettazione, configurazione e runtime.

Possiamo dividere il SAP PI in diverse aree

1. Integration Server
2. Integration Builder
3. System Landscape
4. Configurazione e monitoraggio

Integration Server è il motore di elaborazione centrale del SAP PI. Tutti i messaggi vengono elaborati qui in modo coerente. Si compone di tre motori separati

1. Motore di integrazione
2. Motore adattatore
3. Motore di processo aziendale

Il motore di integrazione può essere considerato il mozzo e il motore adattatore il raggio. Per quanto riguarda il motore di processo aziendale, lo spiegherò più tardi.

Integrazione Builder è una piattaforma client-server per l’accesso e la modifica di oggetti di integrazione e si compone di due strumenti correlati:

1. Enterprise Repository di Servizio – progettazione e sviluppo di oggetti per essere utilizzato in scenari
2. indice di Integrazione – per configurare il ESR oggetti per sviluppare scenari

Due insieme, abbiamo costruito processi di integrazione, che sono comunemente chiamati scenari.

Il System Landscape è un repository centrale di informazioni su software e sistemi nel data center e semplifica l’amministrazione del system landscape.

In Configurazione e monitoraggio possiamo monitorare i messaggi e gli adattatori.

Single stack e Dual stack

Quando PI è stato rilasciato per la prima volta, non tutti i componenti erano costruiti sulla stessa piattaforma. Integration Engine e Business Process Engine sono stati costruiti in ABAP mentre Adapter Engine, Integration Builder, SL, CM e Mapping Runtime sono stati costruiti in Java. Quindi PI ha bisogno sia di Java che dell’ambiente ABAP per essere eseguito ed è noto come dual stack.

Stack ABAP	Stack Java
Motore di Integrazione Business Process Engine Integrazione Builder	Enterprise Service Repository Integrazione Directory Runtime Workbench System Landscape Directory Adattatore Motore Mappatura Runtime

Ma nella versione successiva tutti i componenti sono costruiti in Java. Alcuni dei componenti dual-stack vengono erogati o modificati per funzionare sullo stack Java. Quindi PI ha bisogno solo dell’ambiente Java per essere eseguito ed è noto come single stack.

Ci sono pro e contro tra i due stack, ma non sono coperti in questo tutorial.

Motore di integrazione

Il motore di integrazione è responsabile dei servizi del server di integrazione centrale, ovvero i passaggi della pipe-line-routing e mapping. Se la struttura del messaggio di origine è diversa dalla struttura del messaggio di destinazione, integration engine chiama il Runtime di mappatura, in cui la struttura di origine viene convertita nella struttura di destinazione. Il Runtime di mappatura è basato sullo stack Java. Il motore di integrazione può anche utilizzare un programma ABAP per la conversione, che si basa sullo stack ABAP.

Un messaggio può essere di due tipi

1. Sincrono – ha sia la parte richiesta-risposta
2. asincrono – ha solo la richiesta o la parte di risposta

In PI, il messaggio è rappresentato da un’interfaccia.

Interfaccia> struttura del messaggio in formato XML + direzione

in Base ai criteri di cui sopra, ci sono tre tipi di interfacce

1. interfaccia di Uscita – collegare al mittente sistema
2. in Ingresso interfaccia di connessione al ricevitore di sistema
3. interfaccia Astratta – collegare il BPE

Quando si configura la logica di integrazione (scenario) in SAP PI, come per le nostre esigenze di business, è l’integrazione del motore che esegue la configurazione in maniera saggia fase. Pipeline è il termine utilizzato per riferirsi a tutti i passaggi eseguiti durante l’elaborazione di un messaggio XML. I passaggi della tubazione sono costituiti da quanto segue:

1. Identificazione del ricevitore-determina il sistema che partecipa allo scambio del messaggio.
2. Determinazione dell’interfaccia: determina quale interfaccia riceverà il messaggio.
3. Divisione messaggi-se vengono trovati più di un ricevitore, PI istanzierà un nuovo messaggio per ciascun ricevitore.
4. Message Mapping-mappatura per trasformare il messaggio di origine in formato messaggio di destinazione.
5. Instradamento tecnico: associa una destinazione e un protocollo specifici al messaggio.
6. Call Adapter-invia il messaggio trasformato all’adattatore o a un proxy.

Motore adattatore

È necessario aver notato in precedenza che il motore di integrazione gestisce i messaggi solo nel protocollo XML-SOAP. Ma cosa succede se abbiamo un mittente e un sistema di business ricevitore in cui i dati non è nello stesso formato. Utilizziamo i vari adattatori nel motore adattatore per convertire i messaggi basati su XML e HTTP nel protocollo e nel formato specifici richiesti da questi sistemi e viceversa.

Come abbiamo discusso in precedenza, SAP PI è una struttura hub e spoke in cui il motore adattatore può essere considerato come spoke. Usiamo il motore adattatore per collegare il motore di integrazione (Hub) ai sistemi esterni. Il quadro adattatore è la base del motore adattatore. Il framework Adapter è basato sul motore SAP J2EE (come parte del SAP Web Application Server) e sull’architettura J2EE Connector (JCA). Il framework Adapter fornisce interfacce per la configurazione, la gestione e il monitoraggio degli adattatori.

In un sistema dual stack, la maggior parte degli adattatori si basa sullo stack Java escludendo due adattatori basati sullo stack ABAP.

Stack Java	RFC adattatore SAP Business Connettore adattatore, file/FTP adattatore, JDBC adattatore, JMS adattatore, adattatore SOAP, Mercato Adattatore, adattatore di Posta, RNIF adattatore, adattatore CIDX
stack ABAP	IDOC e adattatore adapter

Quando SAP PI spostato dual stack per single stack di queste due schede è diventato parte di Java stack. Il motore adattatore modificato è noto come Advance Adapter Engine e i due adattatori sono chiamati rispettivamente IDOC_AAE adapter e HTTP_AAE adapter.

Business Process Engine

Il Business Process Engine è responsabile dell’esecuzione e della persistenza dei processi di integrazione.

BPM sta per cross-component Business Process Management o ccBPM ed è anche chiamato processo di integrazione. Un processo di integrazione è un processo eseguibile, cross-system per l’elaborazione dei messaggi. In un processo di integrazione è possibile definire tutte le fasi del processo da eseguire e i parametri rilevanti per il controllo del processo. Business Process Management fornisce all’infrastruttura SAP Exchange le seguenti funzioni:

1. Stato-elaborazione completa dei messaggi: lo stato di un processo di integrazione viene mantenuto nel server di integrazione.
2. È inoltre possibile utilizzare le correlazioni per stabilire relazioni semantiche tra i messaggi.
3. Si implementano i processi di integrazione quando si desidera definire, controllare e monitorare processi di integrazione complessi che si estendono attraverso i confini aziendali e applicativi, ad esempio raccogliere/unire, dividere, Multicast

In fase di runtime, il Business Process Engine esegue i processi di integrazione. Il processo di integrazione può inviare e ricevere messaggi utilizzando solo interfacce astratte.

Crea uno scenario in SAP PI

Iniziamo dalla Home page se dobbiamo costruire uno scenario in PI.

La home page sarà simile a come indicato di seguito:

Figura 6-Home Page per SAP PI Java Stack

La Home page ha collegamenti ipertestuali alle seguenti 4 aree di lavoro

1. Enterprise Services Repository (ESR)
2. Integration Directory (ID)
3. System Landscape (SL) Configurazione e monitoraggio (CM)

Ogni collegamento ipertestuale aprirà un’applicazione. Tutti questi quattro sono un’applicazione Java. ESR e ID sono applicazioni swing. Vengono lanciati dal browser basato su JNLP. Quindi per la prima volta ci vuole più tempo mentre scarica l’intero file della libreria. Ma dalla seconda volta in poi, ci vuole meno tempo per lanciare. SL e CM sono applicazioni web puri ed eseguiti sul browser.

Repository di servizi aziendali

Qui progettiamo e creiamo oggetti da utilizzare nella realizzazione di uno scenario di integrazione. Il flusso di dati in PI sarà simile a come mostrato di seguito:

Troviamo la possibilità di progettare i seguenti

1. Oggetti di interfaccia-Service Interface, Message Type, Data Type
2. Mapping objects-Operation Mapping and Message Mapping
3. Processi di integrazione

PI utilizza il repository di integrazione per progettare la struttura dei messaggi per i sistemi mittente e destinatario e sviluppare un messaggio di interfaccia utilizzando le corrispondenti strutture dei messaggi che fungono da punto di interazione con il mondo esterno. Il tipo di dati e il tipo di messaggio vengono utilizzati per semplificare e modulare la progettazione di un’interfaccia complessa.

Operation Mapping consente la trasformazione della struttura di origine alla struttura di destinazione quando le due strutture sono diverse. Ma se l’origine e la struttura di destinazione sono le stesse, la mappatura delle operazioni potrebbe essere eliminata. Simile all’interfaccia di servizio, la mappatura dei messaggi viene utilizzata per semplificare e modulare la progettazione di una mappatura delle operazioni complessa. La mappatura dei messaggi può essere implementata in 4 modi

1. Mappatura grafica
2. Mappatura Java
3. Mappatura XSLT
4. Mappatura ABAP

La mappatura grafica è la più utilizzata in quanto consente allo sviluppatore di mappare graficamente gli attributi di entrambe le strutture per passare i dati utilizzando le interfacce di servizio. Per gli altri tre, dobbiamo sviluppare la mappatura scrivendo codice. Se si tratta di un server a stack singolo, la mappatura ABAP non sarà disponibile.

Ci sono altre aree anche, ma non sono coperti in questo tutorial.

Directory di integrazione

Qui facciamo i passaggi della pipe-line configurando gli oggetti ESR creati in precedenza. Questi passaggi vengono eseguiti dal motore di integrazione durante il runtime.

Prima di iniziare la configurazione dobbiamo creare/importare i seguenti oggetti nella DIR.

1. Servizio – Sistema aziendale/ Servizio aziendale/ Processo di integrazione
2. Canale di comunicazione

Un servizio consente di indirizzare un mittente o un destinatario di messaggi. A seconda di come si desidera utilizzare il servizio, è possibile selezionare tra i seguenti tipi di servizio.

1. Sistema aziendale: se si desidera indirizzare un particolare sistema aziendale come mittente o destinatario dei messaggi, scegliere questo tipo di servizio. Un sistema aziendale è un sistema di applicazione reale in un panorama di sistema.
2. Servizio business: se si desidera indirizzare un’entità aziendale astratta come mittente o destinatario dei messaggi, scegliere questo tipo di servizio. Un servizio business non è definito nel panorama del sistema.
3. Servizio processo di integrazione-Se si desidera indirizzare un processo di integrazione come mittente o destinatario dei messaggi, scegliere questo tipo di servizio. In fase di runtime, questi processi di integrazione sono controllati da messaggi e possono essi stessi inviare messaggi.

Il canale di comunicazione determina l’elaborazione in entrata e in uscita dei messaggi. I messaggi vengono convertiti dal formato nativo al formato di messaggio specifico soap-xml e viceversa tramite l’adattatore. Generalmente ci sono due tipi di canale di comunicazione in uno scenario

1. Mittente Canale di comunicazione
2. Ricevitore Canale di comunicazione

È necessario assegnare un canale di comunicazione a un servizio. A seconda che il servizio sia indirizzato come mittente o destinatario di messaggi, il canale di comunicazione assegnato ha il ruolo di mittente o ricevitore e deve essere configurato di conseguenza. Non è possibile assegnare un canale di comunicazione a un servizio di processo di integrazione.

pipe-line passi sono creato con la creazione i seguenti 4 di configurazione nella directory

troviamo le seguenti opzioni:

1. Mittente Accordo
2. Ricevitore Determinazione
3. Interfaccia di Determinazione
4. Ricevitore Accordo

Mittente accordo definisce come il messaggio di un mittente è quello di essere trasformato in modo che possano essere elaborati dal Server di Integrazione. È costituito dal seguente

1. Componente mittente
2. Interfaccia mittente
3. Canale di comunicazione mittente

L’accordo mittente è simile alla chiave primaria nella tabella. Non ci possono essere i due accordi di mittente simili in un paesaggio.

Accordo ricevitore definisce come il messaggio deve essere trasformato in modo che possa essere elaborato da un ricevitore. Consiste di

1. Componente mittente
2. Componente ricevitore
3. Interfaccia ricevitore
4. Canale di comunicazione ricevitore

Si utilizza una determinazione del ricevitore per specificare a quali ricevitori deve essere inviato un messaggio. Hai la possibilità di definire le condizioni per l’inoltro del messaggio ai ricevitori. È costituito da

1. Componente mittente
2. Interfaccia mittente
3. Componente ricevitore

La determinazione del ricevitore è di due tipi: standard o esteso, a seconda che si desideri specificare il ricevitore manualmente o dinamicamente tramite una mappatura in fase di esecuzione.

Si utilizza una determinazione dell’interfaccia per specificare a quale interfaccia in entrata di un ricevitore; il messaggio deve essere inoltrato. È inoltre possibile specificare quale mappatura dell’interfaccia dal repository di integrazione deve essere utilizzata per l’elaborazione del messaggio, ad esempio se il mittente e l’interfaccia del ricevitore non sono dello stesso formato, esiste una mappatura operativa per modificare il formato. Si definisce una determinazione dell’interfaccia per un mittente, un’interfaccia in uscita e un ricevitore. Si compone di

1. Componente mittente
2. Interfaccia mittente
3. Componente ricevitore
4. Interfaccia ricevitore

La determinazione dell’interfaccia è di due tipi: standard o migliorata, a seconda che si desideri specificare l’interfaccia del ricevitore manualmente o tramite la divisione dei messaggi basata sulla mappatura.

Determinazione del ricevitore e determinazione dell’interfaccia: i due insieme sono comunemente noti come routing logico. Accordo mittente e accordo destinatario-i due insieme sono comunemente noti come Accordo di collaborazione.

System Landscape

La directory SAP System Landscape (SLD) è il fornitore centrale di informazioni in un System landscape. Nella pagina web troverete i seguenti link:

1. Technical System – Sistemi tecnici sono sistemi applicativi che vengono installati nel vostro paesaggio di sistema.
2. Business System – I sistemi aziendali sono sistemi logici, che funzionano come mittenti o ricevitori all’interno di PI. Business Systems ha una dipendenza one-to-one con il sistema tecnico associato.
3. Prodotti e componenti-Si tratta di informazioni su tutti i prodotti e componenti SAP disponibili, comprese le loro versioni. Se ci sono prodotti di terze parti nel panorama del sistema, sono anche registrati qui.

Il SLD sarà simile a come indicato di seguito:

Figura 11-System Landscape

Prodotti e componenti sono comunemente chiamati le informazioni sui componenti

Sistema tecnico e sistema aziendale sono comunemente chiamati la descrizione del paesaggio.

Un sistema aziendale può essere configurato come server di integrazione o sistema applicativo.

1. Integration Server-Il server di integrazione esegue solo la logica di integrazione configurata in Integration Builder. Possono anche essere identificati come passaggi di linea del tubo. Riceve il messaggio XML, determina il ricevitore, esegue le mappature e indirizza il messaggio XML ai sistemi di ricezione corrispondenti. Così motore di integrazione configurato è identificato come motore di integrazione configurato centrale.
2. Sistema applicativo-Il sistema applicativo non eseguirà la logica di integrazione. A sua volta chiama il server di integrazione per eseguire la logica di integrazione, se necessario. Agisce come mittente o destinatario di messaggi XML. Pertanto, il sistema applicativo con un motore di integrazione locale richiede che il server di integrazione esegua la logica di integrazione.

Solo un client del sistema SAP può essere configurato come Server di integrazione.

Le seguenti informazioni sono estratte dal SLD nel ESR e DIR

1. Component Informazioni sono utilizzate nella ESR per definire il Prodotto e il SWCV
2. Business Sistema sono utilizzati nella Directory per definire il mittente e il destinatario di messaggi

la Configurazione e il Monitoraggio

è il punto centrale di monitoraggio. Ciò offre la possibilità di accedere alle funzioni di monitoraggio del motore di integrazione, nonché all’integrazione con il sistema di gestione del centro di elaborazione (CCMS) e l’infrastruttura di monitoraggio dei processi (PMI) di SAP.

La configurazione e il monitoraggio saranno simili a quelli indicati di seguito:

Figura 13-Configurazione e monitoraggio

Con la Configurazione e il monitoraggio sono supportate le seguenti funzioni di monitoraggio:

1. Monitoraggio dei componenti-monitoraggio dei diversi componenti SAP PI (parti Java e ABAP).
2. Monitoraggio dei messaggi: monitoraggio dello stato di elaborazione dei messaggi all’interno di un componente SAP PI e rilevamento e analisi degli errori.
3. Monitoraggio end-to-end – monitoraggio del ciclo di vita di un messaggio dal punto di vista SAP PI.
4. Monitoraggio delle prestazioni-le statistiche sui diversi aspetti delle prestazioni di SAP PI sono accessibili tramite RWB. Qui è possibile selezionare e aggregare i dati sulle prestazioni, ad esempio per componente, intervallo di tempo o attributi del messaggio.
5. Amministrazione indice – amministrando e monitorando l’indicizzazione dei messaggi per componente SAP PI, si abilita una ricerca di messaggi basata su indice che è possibile utilizzare nel monitoraggio dei messaggi. Questo tipo di ricerca dei messaggi offre criteri di selezione avanzati, inclusi attributi dei messaggi specifici dell’adattatore e termini o frasi del payload dei messaggi.
6. Configurazione alert-utilizzando il framework Alert, il monitoraggio centrale in PI può essere fornito con tutti gli errori segnalati durante l’elaborazione dei messaggi in ABAP e Java. Ciò consente una migliore reazione a tali errori sia nel runtime ABAP che nel motore dell’adattatore basato su Java. A tale scopo, il Framework Alert è dotato di regole basate su determinati eventi e su informazioni provenienti dall’intestazione del protocollo di messaggi PI. Queste regole determinano se gli avvisi vengono inviati o meno. Se viene inviato un avviso, può essere utilizzato per l’analisi degli errori.
7. Posta in arrivo di avviso-la posta in arrivo di avviso è specifica per l’utente e visualizza tutti gli avvisi per ogni server di avviso generato in base alla configurazione di avviso.
8. Monitoraggio cache – il monitoraggio della cache visualizza gli oggetti attualmente presenti nella cache di runtime. Diversi oggetti cache vengono monitorati a seconda dell’istanza cache interessata.

Comunicazione sincrona vs asincrona

Un processo può essere definito sincrono o asincrono.

• Un processo sincrono viene richiamato da un’operazione di richiesta/risposta e il risultato del processo viene restituito immediatamente al chiamante tramite questa operazione.
• Un processo asincrono viene richiamato da un’operazione unidirezionale e il risultato e gli eventuali errori vengono restituiti richiamando altre operazioni unidirezionali. Il risultato viene restituito al chiamante tramite un’operazione di callback.

Nel mondo dei computer, non esiste una comunicazione asincrona. Tutte le comunicazioni tra due sistemi avviene sempre tramite chiamata di metodo (operazione richiesta/risposta). Quindi, come facciamo a renderlo asincrono? La risposta sta nell’introduzione di un terzo sistema tra la funzione chiamata e quella chiamante.

Supponiamo che ci siano due sistemi: A e B. Tutte le comunicazioni tra A e B avvengono tramite una chiamata al metodo e quindi sono sincrone. Introduciamo un terzo sistema tra A e B e lo chiamiamo il sistema intermedio-I. La comunicazione tra A e I avviene tramite chiamata di metodo e allo stesso modo tra I e B avviene anche tramite chiamata di metodo. Ma la comunicazione tra A e B può essere chiamata asincrona in quanto A non deve attendere la risposta da B.

Questa è la base della comunicazione asincrona e cos’è questo sistema intermedio? Questa è la coda. A è chiamato il mittente e B è chiamato il ricevitore. Il messaggio da A viene prima aggiunto alla coda e quindi viene nuovamente estratto dalla coda e inviato a B. La risposta da B raggiunge A in modo simile. In determinate situazioni, il requisito aziendale richiede che i messaggi vengano consegnati a B nello stesso ordine in cui vengono attivati da A. In tal caso seguiamo una politica di first-in e first-out. Se non ci sono tali requisiti, i messaggi vengono inviati dalla coda a B in qualsiasi ordine.

Con la comunicazione asincrona, otteniamo la consegna garantita, ovvero il sistema B non è disponibile quando il sistema A invia il messaggio. Il messaggio viene aggiunto alla coda e rimane lì finché B non è disponibile. Una volta che B è disponibile, il messaggio viene estratto dalla coda e invia a B.

in Modo che possiamo classificare il nostro messaggio di comunicazione in tre modi:

1. Sincrono
2. Asincrona con il fine di non mantenute
3. Asincrono con ordine mantenuto

In PI, possiamo identificarli come: Sincrono – ESSERE (Best Effort), Asincrona con il fine di non mantenuta – EO (una sola Volta)Asincrono con ordine mantenuto – EOIO (Esattamente una Volta in Ordine).

Riconoscimento

Il riconoscimento è la radice della comunicazione asincrona. Perché?

Per la comunicazione sincrona, il sistema A chiama il sistema B e se B non riesce a inviare la risposta il processo non è riuscito. Ma in una comunicazione asincrona, il sistema A chiama il Sistema I e il sistema I chiama il sistema B. Quindi supponiamo che la comunicazione tra A e I abbia successo ma tra I e B, fallisce. Come dovrebbe A rendersi conto che la consegna a B ha fallito? Ciò è realizzato da un riconoscimento che viene rispedito ad A da B tramite la stessa rotta del messaggio da A portato a B. Se il riconoscimento da B non arriva ad A, A considera che il processo non è riuscito e invierà nuovamente il messaggio.

Mentre abbiamo discusso sulla comunicazione asincrona in PI, abbiamo usato il termine – ‘Esattamente una volta’ sia per EO che per EOIO. Esattamente una volta significa che un messaggio consegnato una volta non può essere consegnato di nuovo. Per raggiungere questo obiettivo, c’è un riconoscimento per ogni messaggio inviato da A a B. Sono gli adattatori che si trovano alla fine della comunicazione. Quindi gli adattatori devono supportare il riconoscimento.

Tutti gli adattatori forniscono il riconoscimento del sistema i.e. conferma di consegna. Quegli adattatori che supportano la comunicazione sincrona supportano il riconoscimento dell’applicazione oltre al riconoscimento del sistema.

Quindi in PI, di seguito sono riportati il tipo di riconoscimento

1. Riconoscimento di sistema – Riconoscimenti di sistema utilizzati dall’ambiente runtime per confermare che un messaggio asincrono ha raggiunto il ricevitore.
2. Riconoscimento applicazione-Riconoscimento applicazione utilizzato per confermare che il messaggio asincrono è stato elaborato correttamente presso il ricevitore.

Chiamata di funzione remota

Mentre si lavora in PI, ci si imbatte nel termine – RFC. Cosa sono? Per stabilire la comunicazione tra due sistemi SAP cioè un R / 3 e PI, creiamo la destinazione RFC. È configurato dal seguente

1. Tipo di connessione
2. Indirizzo IP e porta del ricevitore

Tipo di connessione indica il tipo di connessione di sistema cioè R / 3, TCP / IP, interno ecc.

La destinazione RFC che creiamo è classificata in base alla modalità di comunicazione richiesta, ovvero se deve supportare la comunicazione sincrona o asincrona.

1. per la comunicazione sincrona – RFC sincrono
2. per la comunicazione asincrona con ordine non mantenuto – RFC transazionale
3. per la comunicazione asincrona con ordine mantenuto – RFC in coda

Sono identificati da sRFC, tRFC e qRFC.

Casi di studio – 1

Si supponga che ci si trova in una stanza di classe e ci sono 10 studenti in esso. L’istruttore chiede quindi ad ogni studente di preparare i seguenti dati personali e salvarli in un file XML. I dettagli sono i seguenti:

1. ID studente
2. Nome
3. Cellulare
4. Email
5. Genere

Ci saranno 10 file e i file sono denominati come cv_1,2,3….10. I file vengono salvati nella directory di origine. A scopo di test vengono create le seguenti directory:

Directory sorgente: c:\ibm\sap\training\input

Directory archivio: c:\ibm\sap\training\archive

Directory degli errori: c:\ ibm \ sap \ training \ error

Directory di destinazione: c:\ibm\sap\training\target

Ti viene chiesto di sviluppare scenari in SAP PI che leggeranno i file di origine dalla directory di origine e li scriveranno nella directory di destinazione. Una volta che un file viene letto correttamente dalla directory di origine, dovrebbe essere spostato nella directory di archivio e se il file non può essere letto per qualche errore, cioè il formato xml non mantenuto, dovrebbe essere spostato nella directory di errore. I file spostati in archivio, errore o directory di destinazione devono avere un timestamp aggiungere al nome del file.

1. cioè nome file + <timestamp>.

Lezione-1

Prepara uno scenario per leggere un singolo file, ad esempio file cv_1.xml dalla directory di origine e scriverlo nella directory di destinazione. Anche il nome del file di destinazione dovrebbe essere cv_1.xml con il timestamp aggiungere al nome.

Lezione-2

Prepara uno scenario per leggere tutti i file dalla directory di origine e scriverli nella directory di destinazione. Allo stesso modo i file di destinazione dovrebbero anche essere denominati come cv_1, 2 ..xml con il timestamp si aggiunge a ciascuno di essi.

Lezione-3

L’istruttore chiede quindi a tutti di aggiungere la seguente convalida ai dati.

1. Il numero di cellulare dovrebbe avere 10 cifre numeriche-se il numero di cellulare non è di 10 cifre, sostituirlo con’errore’
2. L’e-mail dovrebbe avere un carattere ‘@’ e uno ‘.’carattere-se l’e-mail non ha il ‘@’ o ‘.’carattere, quindi sostituirlo con ‘errore’

Prima di eseguire lo scenario, in alcuni dei file di origine, modificare il cellulare e l’e-mail in modo che siano in errore secondo la logica sopra indicata.

Lezione-4

Prepara uno scenario per leggere tutti i file sorgente e classificarli in base al loro genere. I file per gli uomini saranno scritti in una directory e per le donne in un’altra directory. Vengono create due directory per lo scopo di cui sopra:

Directory di destinazione per gli uomini: c:\ibm\sap\training\target\men

Directory di destinazione per le donne: c:\ ibm \ sap \ training \ target \ women

Supponiamo che ci siano 6 uomini e 4 donne nella classe, quindi se tutti i file di origine vengono letti correttamente, la directory di destinazione per gli uomini dovrebbe avere 6 file e la directory di destinazione per le donne dovrebbe avere 4 file.

Case Studies – 2

L’istruttore chiede quindi a tutti voi di preparare un unico file con i dati personali di ogni studente in segmenti separati.

Lezione-5

Scrivere uno scenario che leggerà questo file e produce 10 file di destinazione in cui ogni file deve corrispondere ai dati personali di ciascun dipendente. I file di destinazione devono essere denominati come cv_<emp_ID> _ < timestamp>

Lezione-6

Modificare lo scenario precedente in modo che produca 2 file di destinazione invece di 10 in cui un file di destinazione per gli uomini e un altro file di destinazione per le donne. Il file di destinazione per gli uomini dovrebbe avere 6 segmenti per 6 uomini e il file di destinazione per le donne dovrebbe avere 4 segmenti per 4 donne.

I file di destinazione devono essere denominati come

Per men – men_<time_stamp>

Per Ladies-women_<time_stamp>

Case Study -3

Come per case study – 1, l’istruttore chiede ad ogni studente di preparare/lei i dati personali e salvarli in un file XML. Ci saranno 10 file. I file vengono salvati nella directory di origine.

Lezione-7

Preparare uno scenario per leggere tutti i file di origine dalla directory di origine e per creare un singolo file nella directory di destinazione. Verrà emesso il nome del file di destinazione.xml con il timestamp aggiungere al nome del file. Il file di destinazione avrà tutti i dettagli di ogni file sorgente come sotto-segmento.

Lezione-8

Preparare uno scenario per leggere l’intero file sorgente dalla directory sorgente e creare due file nella directory di destinazione – uno per gli uomini e l’altro per le donne. Per 6 uomini, il file men dovrebbe avere sei segmenti con i dettagli di ogni uomo e per 4 donne, allo stesso modo ci dovrebbero essere 4 segmenti con i dettagli di ogni donna.

Caso di Studio – 4

L’istruttore chiede a ciascuno degli studenti di preparare un’altra serie di dettagli che consiste la sua/il suo accademico i seguenti dettagli:

1. ID studente
2. Nome della Scuola
3. College il Nome di
4. Nome del Reparto
5. Ammissione Anno

Ci saranno 10 i file e i file sono denominati come ad_1, 2, 3….10. I file vengono salvati nella directory di origine. Così ogni studente avrà ora un paio di file – uno per i dettagli personali e l’altro per i dettagli accademici. Due file sono co-correlati con l’ID dello studente. La directory di input ora è composta da 10 file personali e 10 file accademici.

Lezione – 9

Ti viene chiesto di sviluppare uno scenario che sceglierà i file sorgente e li elaborerà in coppia. Lo scenario genererà 10 file di destinazione. Ogni file di destinazione consisterà dei dettagli personali e accademici di uno studente in segmenti separati. I file di destinazione saranno denominati come res_1, 2, 10.

I file di destinazione saranno simili:

Lezione – 10

Ti viene quindi chiesto di cambiare l’ID studente in alcuni file in modo che non abbiano un file accademico o personale corrispondente e viceversa. Lo scenario dovrebbe essere eseguito e se ha trovato dei file che non hanno un file corrispondente corrispondente, il processo dovrebbe terminare dopo un certo periodo di tempo, cioè 2 min e quei file verranno spostati nella directory di errore e non ci saranno file di destinazione corrispondenti per loro.