Informazioni utili e pratiche su SAP: NOZIONI DI SAP PI (Process Integration)

System Landscape

The SAP System Landscape Directory (SLD) è il fornitore di informazioni centrale in un ambiente di sistema. Nella pagina web si trovano i seguenti link:

1. Technical System - Sistemi tecnici sono sistemi applicativi installati nel vostro ambiente di sistema.

2. Business System - I sistemi aziendali sono sistemi logici, che funzionano come mittenti o destinatari all'interno PI. Business Systems ha dipendenza uno-a-uno con il sistema tecnico associato.

3. Products and Components – Si tratta di informazioni su tutti i prodotti e componenti SAP disponibili, compreso le loro versioni. Se ci sono dei prodotti di terze parti nel system landscape, anche essi sono registrati qui.

Il SLD sarà simile a questa figura:

Products and Components sono comunemente chiamati Component Information.

Technical System and Business System sono comunemente chiamati Landscape Description.

Un business system può essere configurato come Integration server or Application system:

1. Integration Server - Il server di integrazione viene eseguito solo per la configurazione della logica di integrazione Integrazione Builder. Possono anche essere identificati come i passi Pipe Line. Esso riceve i messaggi XML, determina il ricevente, esegue le mappature, ed instrada il messaggio XML per i corrispondenti sistemi di ricezione. Così configurato Integration Engine è identificato come motore centrale configurato Integration.

2. Application system - Il sistema di applicazione non esegue la logica di integrazione. E a sua volta chiama il server di integrazione per eseguire la logica di integrazione se necessario. Agisce come mittente o destinatario di messaggi XML. Così, il sistema di applicazione con un Integration Engine locale richiede il server di integrazione per eseguire la logica di integrazione.

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

Le seguenti informazioni sono estratte dal SLD nel ESR e DIR:

1. Informazione sui componenti sono utilizzati nel ESR per definire il prodotto e il SWCV

2. Business System sono utilizzati nel Directory per definire il mittente e il destinatario di messaggi.

Configuration and Monitoring

E 'il punto di accesso centrale per scopi di monitoraggio. Questo dà la possibilità di navigare attraverso le funzioni di monitoraggio del motore di integrazione, così come l'integrazione con il Computing Center Management System (CCMS), e Process Monitoring Infrastructure (PMI) di SAP.

La schermata della Configuration and Monitoring sarà simile a questa:

Per la Configuration and Monitoring sono supportate le seguenti funzionalità:

1. Component monitoring – monitoraggio delle diverse componenti di SAP PI (Java e ABAP parti).

2. Message monitoring - monitoraggio dello stato di elaborazione dei messaggi all'interno di un componente di SAP PI e rilevamento degli errori e di analisi.

3. End-to-end monitoring - monitoraggio del ciclo di vita di un messaggio dal punto di vista SAP PI.

4. Performance monitoring - statistiche sui diversi aspetti delle prestazioni di SAP PI si può accedere attraverso l’RWB. Qui, è possibile selezionare ed aggregare i dati delle performance, ad esempio, per componente, intervallo di tempo, o gli attributi dei messaggi.

5. Index administration - con la somministrazione e il monitoraggio della indicizzazione dei messaggi per componente SAP PI, si attiva una ricerca messaggio indicizzato che è possibile utilizzare nel monitoraggio dei messaggi.

6. Alert configuration – utilizzando l’Alert Framework, il central monitoring in PI può essere dotato di tutti gli errori riportati durante l’elaborazione dei messaggi in ABAP e JAVA.

7. Alert inbox - la casella di posta elettronica degli alert è specifico per l'utente e visualizza tutti gli alert per ogni server di allarme che è stato generato in base alla configurazione degli alert.

8. Cache monitoring - monitoraggio della cache visualizza gli oggetti che si trovano attualmente nella cache runtime. Diversi oggetti della cache vengono monitorati a seconda dell’istanza della cache in questione.

Synchronous vs. Asynchronous communication

Un processo può essere definito come sincrono o asincrono:

Un processo sincrono viene richiamato da una operazione di richiesta / risposta, e il risultato del processo viene restituito al chiamante immediatamente tramite questa operazione.

Un processo asincrono viene richiamato da un'operazione a senso unico e il risultato e gli eventuali errori vengono restituiti richiamando altre operazioni di sola andata. Il risultato viene restituito al chiamante tramite un'operazione callback.

Nel mondo dei computer, non c'è comunicazione asincrona. Tutte le comunicazioni tra due sistemi è sempre tramite chiamata al metodo (operazione di richiesta / risposta). Quindi, come facciamo a creare un processo asincrono? La risposta si trova con l'introduzione di un terzo sistema tra la chiamata e la funzione chiamante.

Supponiamo che ci sono due sistemi - A e B. Tutte le comunicazioni tra A e B avvengono tramite una chiamata di metodo e quindi sono sincroni. Introduciamo un terzo sistema tra A e B e lo chiamammo il sistema Intermedio “I”. La comunicazione tra A ed I avviene tramite una chiamata al metodo, ed allo stesso modo avviene tra I e B.

Ma la comunicazione tra A e B può essere chiamato asincrono perché A non deve attendere la risposta da B.

Questa è la base della comunicazione asincrona, ed il sistema intermedio è chiamato CODA. A è detto il mittente e B è chiamato il ricevitore.

Quindi A invia un messaggio alla coda e B legge i messaggi dalla coda.

In certi casi, B deve leggere i messaggi nello stesso ordine con cui vengono inviati da A, in questo caso si utilizza la politica del First In – First Out.

Con la comunicazione asincrona, la consegna è garantita. Infatti il Sistema B non è disponibile quando il sistema A invia il messaggio. Il messaggio viene aggiunto alla coda e vi rimane fino a quando B non è disponibile. Quando B è disponibile, il messaggio viene estratto dalla coda e letto da B.

Così possiamo classificare la nostra comunicazione dei messaggi in tre modi:

sincrono

Asincrono con ordine non mantenuto

Asincrono con ordine mantenuto

In PI, li identifichiamo come: sincrono - BE (Best Effort), asincrono con ordine non mantenuto - EO (esattamente una volta, cioè un messaggio recapitato una volta non può essere consegnato di nuovo), asincrono con ordine mantenuto - EOIO (esattamente una volta in ordine).

Acknowledgment

Acknowledgment (riconoscimento) è la radice di comunicazione asincrona.

Per la comunicazione sincrona, il sistema A chiama il sistema B e se B non riesce a inviare la risposta, il processo fallisce.

Nella comunicazione asincrona, il Sistema A chiama Sistema I ed il Sistema I chiama il Sistema B. Quindi supponiamo che la comunicazione tra A ed I funzioni, ma tra I e B, fallisca, come ci si rende conto che la consegna di B è fallita? Questo è realizzato da un riconoscimento (Acknowledgment) che il sistema B manda ad A nella stessa maniera che avviene tra A e B. Se il riconoscimento di B non arriva ad A, allora A considera che il processo non è riuscito e invierà il messaggio nuovo.

Remote Function Call

Quando si lavora in PI, si incontra il termine - RFC.

Per stabilire la comunicazione tra i due sistemi SAP cioè un progetto di R / 3 e PI, creiamo la RFC destinazione. Viene configurato nel seguente modo:

1.    Tipo Di Connessione

2.    Indirizzo IP e la porta del ricevitore

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

L’RFC destinazione che creiamo è classificato in base alla modalità di comunicazione richiesta ovvero se debba supportare la comunicazione sincrona o asincrona.

1.    per la comunicazione sincrona - RFC sincrono

2.    per la comunicazione asincrona con ordine non mantenuta - RFC Transazionale

3.    per la comunicazione asincrona con l'ordine mantenuto - In coda RFC

Essi sono identificati da sRFC, tRFC e qRFC.