SAP PI dla początkujących

cel

celem tego kursu jest zrozumienie – co to jest integracja procesu SAP? Nie będziemy wchodzić w sedno tematu, ale omówimy architekturę i różne funkcje SAP PI. Omówimy tylko podstawowe funkcje i unikniemy omawiania wszystkich funkcji w tym samouczku.

dalej znajduje się zestaw studiów przypadków, które dadzą ci wyobrażenie o wykorzystaniu SAP PI na poziomie branżowym. Po bliższym zapoznaniu się z tematem, powinieneś spróbować je rozwiązać. Przypadki testowe są przygotowane w taki sposób, aby z każdą lekcją przenieśli Cię do tematu od prostego do bardziej kompleksowego i dały ogólny obraz przedmiotu.

co to jest SAP ERP?

dla każdej firmy – dużej lub małej, są to standardowe funkcje biznesowe, które musi realizować, tj. zarządzanie materiałami, sprzedaż i dystrybucja, Finanse, Zasoby ludzkie itp. Istnieje wiele oprogramowania na rynku, które jest wykorzystywane przez przemysł. Zauważysz najprostszy – bankomat generujący fakturę sprzedaży, jeśli odwiedzasz mały sklep do sieci komputerów w dużym sklepie detalicznym, hotelu itp. działających na systemie ERP.

planowanie zasobów przedsiębiorstwa, czyli ERP to skuteczne podejście, które większość firm wdraża w celu zwiększenia wydajności i wydajności. SAP ERP to zintegrowane oprogramowanie SAP AG do planowania zasobów przedsiębiorstwa, które obejmuje kluczowe funkcje biznesowe organizacji. Podstawowe funkcjonalności tj. HR, MM, SD, FICO itp. nazywane są modułami biznesowymi w systemie SAP. SAP buduje je jako produkty i sprzedaje na rynku. Istnieją jeszcze dwa moduły, które nie obsługują bezpośrednio funkcji biznesowych, ale są wykorzystywane do prezentacji i integracji. Pierwszy z nich nazywa się EP (Enterprise Portal), a drugi PI (Process Integration). Wszystkie moduły biznesowe są rozwijane w ABAP, podczas gdy EP i PI są rozwijane głównie w Javie. Moduły te nie są plikami wykonywalnymi, ale muszą być wdrożone na serwerze aplikacji, tj. ABAP Web Application Server dla modułów ABAP i Java Web Application Server dla modułów Java.

jest kilka punktów, które powinniśmy wiedzieć, zanim przejdziemy do tematu.

  • SAP oznacza systemy, aplikacje i produkty w przetwarzaniu danych.
  • SAP AG to niemiecka międzynarodowa korporacja produkująca oprogramowanie dla przedsiębiorstw do zarządzania operacjami biznesowymi i relacjami z klientami. SAP ERP to zintegrowane rozwiązanie programowe firmy Enterprise Resource Planning, które obejmuje kluczowe funkcje biznesowe organizacji.
  • SAP NetWeaver Process Integration (SAP PI) jest oprogramowaniem SAP enterprise application integration (EAI), komponentem grupy produktów NetWeaver służącym do ułatwiania wymiany informacji pomiędzy oprogramowaniem i systemami wewnętrznymi firmy oraz systemami podmiotów zewnętrznych.

starszy System

podczas wdrażania systemu SAP ERP w dużej firmie stwierdzono, że nie wszystkie sekcje mogą być objęte systemem SAP ERP. Wiele sekcji biznesowych może mieć własne, zastrzeżone narzędzia, które są bardzo złożone i mogą nie być możliwe do zastąpienia. Działają równolegle do systemu SAP. Są one nazywane systemami Legacy. Następnie konieczna staje się integracja między systemami SAP i takim wcześniej istniejącym systemem innym niż SAP. W tym miejscu pojawia się SAP PI.

Dlaczego potrzebujemy SAP PI  Rys1.JPG oprócz starszych systemów, w dużej firmie SAP ERP nie składa się z jednego systemu, ale z kilku zintegrowanych systemów tj. CRM, SRM i FICO itp. Aby poradzić sobie z takimi zawiłościami, firma SAP wprowadziła Process Integration platformę zapewniającą pojedynczy punkt integracji dla wszystkich systemów bez dotykania istniejącej złożonej sieci starszych systemów. Jest to potężne oprogramowanie pośredniczące firmy SAP zapewniające bezproblemową integrację między aplikacjami SAP i innymi aplikacjami w obrębie i poza granicami firmy. SAP PI obsługuje zarówno wymiany B2B, jak i A2A, obsługuje synchroniczną i asynchroniczną wymianę wiadomości oraz zawiera wbudowany silnik do projektowania i wykonywania procesów integracyjnych.

Architektura SAP PI

 Rys2.JPG

SAP PI składa się z piasty i struktury szprych; szprychy łączą się z zewnętrznymi systemami, podczas gdy piasta wymienia wiadomości między nimi. System źródłowy jest znany jako system nadawcy, a system docelowy jest znany jako system odbiornika. Pi nie jest pojedynczym komponentem, ale raczej zbiorem komponentów, które elastycznie współpracują ze sobą w celu wdrożenia scenariuszy integracji. Architektura zawiera komponenty, które mają być używane w czasie projektowania, w czasie konfiguracji i w czasie wykonywania.

możemy podzielić PI SAP na kilka obszarów

  1. Integration Server
  2. Integration Builder
  3. Krajobraz systemu
  4. Konfiguracja i monitorowanie

Integration Server jest Centralnym Silnikiem przetwarzania Pi SAP. Wszystkie wiadomości są tutaj przetwarzane w spójny sposób. Składa się z trzech oddzielnych silników

  1. Integration Engine
  2. Adapter Engine
  3. Business Process Engine

Integration engine można uznać za piastę i silnik adaptera szprychy. Jeśli chodzi o silnik procesów biznesowych, wyjaśnię to później.

Integration Builder to framework klient-serwer do uzyskiwania dostępu i edycji obiektów integracji i składa się z dwóch powiązanych narzędzi:

  1. Enterprise Service Repository-do projektowania i rozwijania obiektów do wykorzystania w scenariuszach
  2. Integration Directory-do konfigurowania obiektów ESR do tworzenia scenariuszy

dwa razem zbudowaliśmy procesy integracji, które są powszechnie nazywane scenariuszami.

Krajobraz systemu jest centralnym repozytorium informacji o oprogramowaniu i systemach w centrum danych i upraszcza administrację krajobrazu systemu.

w konfiguracji i monitorowaniu możemy monitorować wiadomości i Adaptery.

pojedynczy stos i podwójny stos

kiedy PI został wydany po raz pierwszy, nie wszystkie komponenty były zbudowane na tej samej platformie. Integration Engine i Business Process Engine zostały zbudowane w ABAP, natomiast Adapter Engine, Integration Builder, SL, CM i Mapping Runtime zostały zbudowane w Javie. Tak więc PI potrzebuje zarówno środowiska Java, jak i ABAP do działania i jest znany jako podwójny stos.

stos ABAP

Java Stack

  1. Integration Engine
  2. Business Process Engine
  3. Integration Builder
  • repozytorium usług dla przedsiębiorstw
  • Katalog integracji
  1. środowisko uruchomieniowe Workbench
  2. Katalog krajobrazu systemu
  3. Silnik adaptera
  4. środowisko wykonywania mapowania

ale w późniejszej wersji wszystkie komponenty są zbudowane w Javie. Niektóre komponenty z podwójnym stosem są albo dozowane, albo modyfikowane, aby działały na stosie Javy. Tak więc PI potrzebuje tylko środowiska Java do uruchomienia i jest znany jako pojedynczy stos.

istnieją plusy i minusy między dwoma stosami, ale nie są one omówione w tym samouczku.

Silnik Integracji

 Rys. 3.JPG Silnik integracji jest odpowiedzialny za usługi central Integration Server tj. etapy pipe-line-routing i mapowanie. Jeśli struktura komunikatów źródłowych różni się od struktury komunikatów docelowych, integration engine wywołuje Środowisko wykonawcze mapowania, w którym struktura źródłowa jest konwertowana na strukturę docelową. Środowisko wykonawcze mapowania oparte jest na stosie Java. Silnik integracji może również wykorzystywać program ABAP do konwersji, który jest oparty na stosie ABAP.

wiadomość może być dwóch typów

  1. synchroniczny – ma zarówno część żądanie-odpowiedź
  2. asynchroniczny – ma tylko część żądanie lub odpowiedź

w PI, wiadomość jest reprezentowana przez interfejs.

interfejs- > struktura wiadomości w formacie XML + kierunek

w oparciu o powyższe kryteria wyróżnia się trzy typy interfejsów

  1. interfejs wychodzący – podłączenie do systemu nadawcy
  2. interfejs przychodzący – podłączenie do systemu odbiornika
  3. interfejs abstrakcyjny – podłączenie do BPE

kiedy konfigurujemy logikę integracji (scenariusz) w SAP PI zgodnie z naszymi wymaganiami biznesowymi, to silnik integracji wykonuje tę konfigurację w sposób krokowy. Pipeline to termin odnoszący się do wszystkich kroków wykonywanych podczas przetwarzania wiadomości XML. Stopnie przewodów rurowych składają się z następujących:

  1. Identyfikacja odbiornika-określa system, który uczestniczy w wymianie wiadomości.
  2. określanie interfejsu-określ, który interfejs powinien otrzymać wiadomość.
  3. podział Wiadomości – jeśli zostanie znalezionych więcej niż jeden odbiornik, PI utworzy nową wiadomość dla każdego odbiornika.
  4. mapowanie wiadomości – mapowanie w celu przekształcenia wiadomości źródłowej w format wiadomości docelowej.
  5. Technical Routing-powiązanie określonego miejsca docelowego i protokołu z Komunikatem.
  6. Call Adapter – wyślij przekształconą wiadomość do adaptera lub serwera proxy.

Adapter Engine

musisz wcześniej zauważyć, że silnik integracji obsługuje WIADOMOŚCI tylko w protokole XML-SOAP. Ale co, jeśli mamy system biznesowy nadawcy i odbiorcy, w którym dane nie są w tym samym formacie. Używamy różnych adapterów w silniku adapterów do konwersji wiadomości opartych na XML i HTTP do określonego protokołu i formatu wymaganego przez te systemy i odwrotnie.

JPG jak już wcześniej omówiliśmy, SAP PI jest strukturą piasty i szprychy, w której silnik adaptera można uznać za szprychę. Używamy silnika adaptera do podłączenia silnika integracji (Piasty) do systemów zewnętrznych. Rama adaptera jest podstawą silnika adaptera. Framework adaptera jest oparty na silniku SAP J2EE (jako część serwera aplikacji internetowych SAP) i architekturze J2EE Connector Architecture (JCA). Framework adapterów zapewnia interfejsy do konfiguracji, zarządzania i monitorowania adapterów.

w systemie z podwójnym stosem większość adapterów opiera się na stosie Java, z wyjątkiem dwóch adapterów opartych na stosie ABAP.

Java Stack

Adapter RFC, Adapter SAP Business Connector, Adapter file / FTP, adapter JDBC, adapter JMS, adapter SOAP, Adapter Marketplace, Adapter Mail, adapter RNIF, adapter CIDX

stos ABAP

Adapter IDOC i adapter HTTP

kiedy SAP PI przeniósł się z podwójnego stosu do pojedynczego stosu, te dwa adaptery stały się częścią stosu Java. Zmodyfikowany silnik adaptera jest znany jako Advance Adapter Engine, a dwa adaptery są nazywane odpowiednio adapterem IDOC_AAE i http_aae.

Silnik Procesów Biznesowych

Rys. 5.JPGsilnik procesów biznesowych jest odpowiedzialny za realizację i utrzymywanie procesów integracyjnych.

BPM oznacza cross-component Business Process Management lub ccBPM i jest również nazywany procesem integracji. Proces integracji jest wykonywalnym, międzysystemowym procesem przetwarzania wiadomości. W procesie integracji definiujesz wszystkie etapy procesu, które mają zostać wykonane, oraz parametry istotne dla sterowania procesem. Zarządzanie procesami biznesowymi zapewnia infrastrukturze SAP Exchange następujące funkcje:

  1. State-full message processing: status procesu integracji jest utrzymywany na serwerze integracji.
  2. możesz również użyć korelacji do ustanowienia relacji semantycznych między wiadomościami.
  3. wdrażasz procesy integracyjne jeśli chcesz definiować, kontrolować i monitorować złożone procesy integracyjne, które rozciągają się między przedsiębiorstwami i aplikacjami, tj. zbierać/scalać, dzielić, multiemisji

podczas pracy silnik procesów biznesowych wykonuje procesy integracyjne. Proces integracji może wysyłać i odbierać wiadomości tylko za pomocą abstrakcyjnych interfejsów.

Zbuduj scenariusz w SAP PI

zaczynamy od strony głównej, jeśli musimy zbudować scenariusz w PI.

Strona główna będzie wyglądać podobnie jak poniżej:

 rys. 6.JPGRysunek 6-Strona Główna Dla SAP PI Java Stack

Strona główna zawiera hiperłącza do następujących 4 obszarów roboczych

  1. repozytorium usług korporacyjnych (ESR)
  2. Katalog integracji (ID)
  3. Krajobraz systemu (SL)
  4. Konfiguracja i monitorowanie (CM)

każde hiperłącze otworzy jedną aplikację. Wszystkie te cztery to aplikacje Java. ESR i ID to aplikacje typu swing. Są one uruchamiane z przeglądarki opartej na JNLP. Tak więc po raz pierwszy zajmuje to więcej czasu, ponieważ pobiera cały plik biblioteki. Ale od drugiego razu, to zajmuje mniej czasu, aby uruchomić. SL I CM są czystymi aplikacjami internetowymi i działają w przeglądarce.

Enterprise Services Repository

tutaj projektujemy i tworzymy obiekty do wykorzystania przy tworzeniu scenariusza integracji. Przepływ danych w PI będzie wyglądał podobnie jak pokazano poniżej:

rys. 7.JPG znajdujemy opcję zaprojektowania następujących

  1. obiektów interfejsu-Interfejs usługi, Typ wiadomości, typ danych
  2. obiektów mapowania-mapowanie operacji i mapowanie wiadomości
  3. procesów integracyjnych

rys. 8.JPG

PI wykorzystuje repozytorium integracji do projektowania struktury wiadomości zarówno dla Systemów nadawcy, jak i odbiorcy oraz opracowania komunikatu interfejsu przy użyciu odpowiednich struktur wiadomości, które działają jako punkt interakcji ze światem zewnętrznym. Typ danych i typ wiadomości są używane do uproszczenia i modularyzacji projektowania złożonego interfejsu.

Fig9.Mapowanie operacji JPGumożliwia przekształcenie struktury źródłowej w strukturę docelową, gdy obie struktury są różne. Ale jeśli źródło i struktura docelowa są takie same, to mapowanie operacji może zostać wyłączone. Podobnie jak interfejs usługi, mapowanie Wiadomości służy do uproszczenia i modularyzacji projektowania złożonego mapowania operacji. Mapowanie wiadomości może być zaimplementowane na 4 sposoby

  1. mapowanie graficzne
  2. mapowanie Javy
  3. mapowanie XSLT
  4. mapowanie ABAP

mapowanie graficzne jest najczęściej używane, ponieważ pozwala programistom mapować atrybuty obu struktur graficznie, aby przekazać dane za pomocą interfejsów usług. W przypadku pozostałych trzech musimy opracować mapowanie poprzez pisanie kodu. Jeśli jest to serwer z pojedynczym stosem, mapowanie ABAP nie będzie dostępne.

istnieją również inne obszary, ale nie są one objęte tym samouczkiem.

Katalog integracyjny

tutaj wykonujemy kroki linii rurociągu, konfigurując wcześniej utworzone obiekty ESR. Kroki te są wykonywane przez silnik integracji w czasie pracy.

Zanim rozpoczniemy konfigurację musimy utworzyć / zaimportować następujące obiekty w katalogu.

  1. usługa – System biznesowy/ usługa Biznesowa/ proces integracji
  2. kanał komunikacji

usługa umożliwia adresowanie do nadawcy lub odbiorcy wiadomości. W zależności od tego, w jaki sposób chcesz korzystać z usługi, możesz wybrać jeden z następujących typów usług.

  1. system biznesowy – jeśli chcesz zwrócić się do określonego systemu biznesowego jako nadawca lub odbiorca wiadomości, wybierz ten typ usługi. System biznesowy to rzeczywisty system aplikacji w krajobrazie systemowym.
  2. usługa Biznesowa – jeśli chcesz adresować abstrakcyjny podmiot gospodarczy jako nadawcę lub odbiorcę wiadomości, wybierz ten typ usługi. Usługa biznesowa nie jest zdefiniowana w krajobrazie systemu.
  3. usługa procesu integracji – jeśli chcesz potraktować proces integracji jako nadawcę lub odbiorcę wiadomości, wybierz ten typ usługi. W czasie wykonywania te procesy integracji są kontrolowane przez wiadomości i mogą same wysyłać wiadomości.

kanał komunikacji określa przychodzące i wychodzące przetwarzanie wiadomości. Wiadomości są konwertowane z formatu natywnego do formatu komunikatów specyficznych dla soap-xml i odwrotnie za pośrednictwem adaptera. Zasadniczo istnieją dwa rodzaje kanałów komunikacji w scenariuszu

  1. kanał komunikacji nadawcy
  2. kanał komunikacji odbiornika

rys. 10.JPG

musisz przypisać kanał komunikacyjny do usługi. W zależności od tego, czy usługa jest adresowana jako nadawca czy odbiorca wiadomości, przypisany kanał komunikacyjny pełni rolę nadawcy lub kanału odbiorczego i musi być odpowiednio skonfigurowany. Nie można przypisać kanału komunikacji do usługi procesu integracji.

kroki linii rur są tworzone przez utworzenie następujących 4 konfiguracji w katalogu

znajdujemy następujące opcje:

  1. Umowa nadawcy
  2. określenie odbiornika
  3. określenie interfejsu
  4. Umowa odbiornika

umowa nadawcy określa, w jaki sposób wiadomość nadawcy ma zostać przekształcona, aby mogła być przetwarzana przez serwer integracji. Składa się z następującego

  1. komponentu nadawcy
  2. interfejsu nadawcy
  3. kanału komunikacji nadawcy

Umowa Nadawcy jest podobna do klucza podstawowego w tabeli. Nie może być dwóch podobnych umów nadawcy w jednym krajobrazie.

Umowa odbiornika określa, w jaki sposób wiadomość ma zostać przekształcona, aby mogła zostać przetworzona przez odbiorcę. Składa się z

  1. komponentu nadawcy
  2. komponentu odbiornika
  3. interfejsu odbiornika
  4. kanału komunikacji odbiornika

określenie odbiornika służy do określenia, do których odbiorników ma zostać wysłana wiadomość. Masz możliwość zdefiniowania warunków przekazywania wiadomości do odbiorców. Składa się z

  1. komponentu nadawcy
  2. interfejsu nadawcy
  3. komponentu odbiornika

określenie odbiornika jest dwóch typów – standardowego lub rozszerzonego, w zależności od tego, czy chcesz określić Odbiornik ręcznie, czy dynamicznie przez mapowanie w czasie wykonywania.

używasz określenia interfejsu, aby określić, do którego interfejsu przychodzącego odbiornika ma zostać przekazana wiadomość. Można również określić, które mapowanie interfejsu z repozytorium integracji ma być używane do przetwarzania wiadomości, np. jeśli interfejs nadawcy i odbiornika nie mają tego samego formatu, istnieje mapowanie operacyjne w celu zmiany formatu. Definiujesz określenie interfejsu dla nadawcy, interfejsu wychodzącego i odbiorcy. Składa się z

  1. komponentu nadawcy
  2. interfejsu nadawcy
  3. komponentu odbiornika
  4. interfejsu odbiornika

określenie interfejsu jest dwóch typów – standardowego lub ulepszonego, w zależności od tego, czy chcesz ręcznie określić interfejs odbiornika, czy poprzez podział wiadomości na podstawie mapowania.

wyznaczanie odbiornika i wyznaczanie interfejsu-obie te wartości są powszechnie znane jako routing logiczny. Umowa nadawcy i umowa odbiorcy-obie razem są powszechnie znane jako Umowa o współpracy.

Krajobraz systemu

Katalog krajobrazu systemu SAP (SLD) jest centralnym dostawcą informacji w krajobrazie systemu. Na stronie znajdują się następujące linki:

  1. system techniczny-Systemy Techniczne to systemy aplikacyjne, które są instalowane w Twoim środowisku systemowym.
  2. system biznesowy – systemy biznesowe to systemy logiczne, które funkcjonują jako nadawcy lub odbiorcy w ramach PI. Systemy biznesowe mają zależność jeden do jednego z powiązanym systemem technicznym.
  3. produkty i komponenty-to informacje o wszystkich dostępnych produktach i komponentach SAP, w tym ich wersjach. Jeśli w krajobrazie systemu znajdują się produkty innych firm, są one również rejestrowane tutaj.

SLD będzie wyglądać podobnie jak poniżej:

rys. 11.JPGRysunek 11-Krajobraz systemu

produkty i komponenty są powszechnie nazywane informacjami o komponentach

system techniczny i system biznesowy są powszechnie nazywane opisem krajobrazu.

system biznesowy można skonfigurować jako serwer integracji lub system aplikacji.

  1. Integration Server – Integration server wykonuje tylko logikę integracji skonfigurowaną w Integration Builder. Można je również zidentyfikować jako stopnie przewodów rurowych. Odbiera wiadomość XML, określa odbiornik, wykonuje mapowania i kieruje wiadomość XML do odpowiednich systemów odbiorczych. Tak skonfigurowany Integration Engine jest identyfikowany jako Central Configured Integration engine.
  2. System aplikacji-System aplikacji nie wykona logiki integracji. To z kolei wywołuje serwer integracji, aby wykonać logikę integracji, jeśli jest to wymagane. Działa jako nadawca lub odbiorca wiadomości XML. Tak więc system aplikacji z lokalnym silnikiem integracji wymaga serwera integracji do wykonania logiki integracji.

tylko jeden klient systemu SAP może być skonfigurowany jako serwer integracji.

rys. 12.JPG następujące informacje są wyodrębniane z OP do ESR i DIR

  1. informacje o komponentach są używane w ESR do definiowania produktu, a SWCV
  2. system biznesowy są używane w katalogu do definiowania nadawcy i odbiorcy wiadomości

Konfiguracja i monitorowanie

jest to centralny punkt wejścia do celów monitorowania. Daje to możliwość przejścia do funkcji monitorowania silnika integracji, a także integracji z systemem zarządzania centrum obliczeniowym (CCMS) i infrastrukturą monitorowania procesów (PMI) SAP.

Konfiguracja i monitorowanie będą wyglądać podobnie jak poniżej:

rys. 13.JPGrysunek 13-Konfiguracja i monitorowanie

przy konfiguracji i monitorowaniu obsługiwane są następujące funkcje monitorowania:

  1. monitorowanie komponentów-monitorowanie różnych komponentów SAP PI (części Java i ABAP).
  2. monitorowanie wiadomości – śledzenie statusu przetwarzania wiadomości w komponencie SAP PI oraz wykrywania i analizy błędów.
  3. End-to-end monitoring – monitorowanie cyklu życia wiadomości z punktu widzenia SAP PI.
  4. monitorowanie wydajności-statystyki dotyczące różnych aspektów wydajności SAP PI można uzyskać za pośrednictwem RWB. Tutaj można wybierać i agregować dane wydajności, na przykład według komponentów, zakresu czasowego lub atrybutów wiadomości.
  5. administracja indeksami – administrując i monitorując indeksowanie wiadomości dla każdego komponentu SAP PI, włączasz Wyszukiwanie wiadomości oparte na indeksie, którego możesz użyć w monitorowaniu wiadomości. Ten rodzaj wyszukiwania Wiadomości oferuje rozszerzone kryteria wyboru, w tym specyficzne dla adaptera atrybuty wiadomości oraz terminy lub frazy z ładunku wiadomości.
  6. konfiguracja alertów – korzystając z ramy alertów, można zapewnić Centralne monitorowanie w PI wszystkich błędów zgłoszonych podczas przetwarzania wiadomości w ABAP i Java. Umożliwia to lepszą reakcję na takie błędy zarówno w środowisku wykonawczym ABAP, jak i w adapterze opartym na Javie. W tym celu Ramka alertu zawiera reguły oparte na pewnych zdarzeniach i informacjach z nagłówka protokołu komunikatów PI. Zasady te określają, czy alerty są wysyłane, czy nie. W przypadku wysłania alertu można go wykorzystać do analizy błędów.
  7. Skrzynka odbiorcza alertu – Skrzynka odbiorcza alertu jest specyficzna dla użytkownika i wyświetla wszystkie alerty dla każdego serwera alertów, który został wygenerowany na podstawie konfiguracji alertu.
  8. monitorowanie pamięci podręcznej – monitorowanie pamięci podręcznej wyświetla obiekty, które są obecnie w buforze uruchomieniowym. Różne obiekty pamięci podręcznej są monitorowane w zależności od danej instancji pamięci podręcznej.

Komunikacja Synchroniczna a asynchroniczna

proces może być zdefiniowany jako synchroniczny lub asynchroniczny.

  • proces synchroniczny jest wywoływany przez operację żądanie/odpowiedź, a wynik procesu jest natychmiast zwracany do wywołującego za pomocą tej operacji.
  • proces asynchroniczny jest wywoływany przez operację jednokierunkową, a wynik i wszelkie błędy są zwracane przez wywołanie innych operacji jednokierunkowych. Wynik jest zwracany do rozmówcy za pomocą operacji zwrotnej.

w świecie komputerów nie ma komunikacji asynchronicznej. Cała komunikacja pomiędzy dwoma systemami odbywa się zawsze poprzez wywołanie metody (operacja request / response). Więc jak zrobić to asynchroniczne? Odpowiedź polega na wprowadzeniu trzeciego systemu pomiędzy funkcją wywołaną a funkcją wywołującą.

Załóżmy, że istnieją dwa systemy – A I B. Cała komunikacja pomiędzy a i B odbywa się poprzez wywołanie metody i dlatego są one synchroniczne. Wprowadzamy trzeci system pomiędzy A i B i nazwaliśmy go systemem pośrednim-I. komunikacja między A I I odbywa się poprzez wywołanie metody i podobnie między I I B jest również poprzez wywołanie metody. Ale komunikację między A i B można wywołać asynchroniczną, ponieważ A nie musi czekać na odpowiedź od B.

rys. 14.JPGto jest podstawa komunikacji asynchronicznej i co to za system pośredni? To jest Kolejka. A nazywa się nadawcą, a b-odbiorcą. Wiadomość z A jest najpierw dodawana do kolejki, a następnie ponownie wyciągana z kolejki i wysyłana do B. odpowiedź z B dociera do a w podobny sposób. W pewnych sytuacjach wymóg biznesowy wymaga, aby wiadomości były dostarczane do B w takiej samej kolejności, w jakiej są uruchamiane z A. w takim przypadku stosujemy zasady pierwszego wejścia i pierwszego wyjścia. Jeśli nie ma takich wymagań, to wiadomości są wysyłane z kolejki do B W dowolnej kolejności.

dzięki komunikacji asynchronicznej osiągamy gwarantowaną dostawę, tzn. System B nie jest dostępny, gdy System a wyśle wiadomość. Wiadomość jest dodawana do kolejki i pozostaje tam tak długo, jak B nie jest dostępne. Gdy B jest dostępny, wiadomość jest wyciągana z kolejki i wysyłana do B.

, dzięki czemu możemy sklasyfikować naszą komunikację komunikacyjną na trzy sposoby:

  1. synchroniczne
  2. asynchroniczne z utrzymaniem kolejności
  3. asynchroniczne z utrzymaniem kolejności

w PI identyfikujemy je jako: synchroniczne – be (Best Effort), asynchroniczne z utrzymaniem kolejności – EO (dokładnie raz), asynchroniczne z utrzymaniem kolejności – EOIO (dokładnie raz w kolejności).

potwierdzenie

potwierdzenie jest korzeniem komunikacji asynchronicznej. Dlaczego?

dla komunikacji synchronicznej system a wywołuje system b, a jeśli b nie wyśle odpowiedzi, proces nie powiedzie się. Ale w komunikacji asynchronicznej, System a wywołuje System I, a System i wywołuje System B. Załóżmy więc, że komunikacja między A I I jest udana, ale między I I B, nie powiedzie się. W jaki sposób a powinien uświadomić sobie, że dostawa do B nie powiodła się? Jest to realizowane przez potwierdzenie, które jest wysyłane z powrotem do A przez B tą samą drogą, co wiadomość z a wzięta do B. Jeśli potwierdzenie z B nie dotrze do A, A uzna, że proces nie powiódł się i wyśle wiadomość ponownie.

Fig15.JPG podczas gdy rozmawialiśmy o komunikacji asynchronicznej w PI, użyliśmy terminu – „dokładnie raz” zarówno dla EO, jak i EOIO. Dokładnie raz oznacza, że wiadomość dostarczona raz nie może zostać ponownie dostarczona. Aby to osiągnąć, istnieje potwierdzenie dla każdej wiadomości wysyłanej z A do B. To Adaptery leżą na końcu komunikacji. Więc Adaptery muszą obsługiwać potwierdzenie.

wszystkie adaptery zapewniają potwierdzenie systemu i.e.potwierdzenie dostawy. Te adaptery, które obsługują komunikację synchroniczną, obsługują potwierdzenie aplikacji oprócz potwierdzenia systemu.

Tak więc w PI, poniżej znajduje się Typ potwierdzenia

  1. potwierdzenie systemowe – potwierdzenia systemowe używane przez środowisko wykonawcze do potwierdzenia, że wiadomość asynchroniczna dotarła do odbiornika.
  2. application Acknowgment-potwierdzenie aplikacji używane do potwierdzenia, że wiadomość asynchroniczna została pomyślnie przetworzona w odbiorniku.

funkcja Zdalna wywołanie

pracując w PI, natkniesz się na termin – RFC. Co to jest? Aby nawiązać komunikację pomiędzy dwoma systemami SAP tj. R / 3 i PI, tworzymy RFC Destination. Jest on konfigurowany przez następujący

  1. Typ połączenia
  2. adres IP i Port odbiornika

Typ połączenia określa typ połączenia systemowego tj. R/3, TCP/IP, wewnętrzny itp.

miejsce docelowe RFC, które tworzymy, jest klasyfikowane zgodnie z wymaganym sposobem komunikacji, tj. niezależnie od tego, czy powinien obsługiwać komunikację synchroniczną, czy asynchroniczną.

  1. dla komunikacji synchronicznej – synchroniczne RFC
  2. dla komunikacji asynchronicznej ze zleceniem nie utrzymanym – transakcyjne RFC
  3. dla komunikacji asynchronicznej ze zleceniem utrzymanym – kolejkowane RFC

są one identyfikowane przez sRFC, tRFC i qRFC.

Case Studies – 1

Załóżmy, że jesteś w klasie i jest w niej 10 uczniów. Następnie instruktor prosi każdego ucznia o przygotowanie następujących danych osobowych i zapisanie ich w pliku XML. Szczegóły są następujące:

  1. legitymacja studencka
  2. imię i nazwisko
  3. telefon komórkowy
  4. e-mail
  5. płeć

będzie 10 plików o nazwach cv_1,2,3….10. Pliki są zapisywane w katalogu źródłowym. Dla celów testowych tworzone są następujące katalogi:

katalog źródłowy: c:\ibm\sap\training\input

Katalog archiwalny: c:\ibm\sap\training\archive

Katalog błędów: c:\ibm\SAP\training \ error

katalog docelowy: c:\ibm\sap\training\target

zostaniesz poproszony o opracowanie scenariuszy w SAP PI, które będą odczytywać pliki źródłowe z katalogu źródłowego i zapisywać je do katalogu docelowego. Po pomyślnym odczytaniu pliku z katalogu źródłowego, należy go przenieść do katalogu archive, a jeśli plik nie może być odczytany z powodu jakiegoś błędu, np. format xml nie jest utrzymywany, należy go przenieść do katalogu błędu. Pliki przeniesione do katalogu archive, error lub target powinny mieć dołączony znacznik czasu do nazwy pliku.

  1. nazwa pliku+<znacznik czasu >.

Lesson-1

przygotuj scenariusz do odczytania jednego pliku, tj. pliku cv_1.xml z katalogu źródłowego i zapisać go do katalogu docelowego. Plik docelowy powinien mieć również nazwę cv_1.xml ze znacznikiem czasu dołącza do nazwy.

Lesson-2

przygotuj scenariusz, aby odczytać wszystkie pliki z katalogu źródłowego i zapisać je do katalogu docelowego. Podobnie pliki docelowe powinny być również nazwane jako cv_1, 2 ..xml ze znacznikiem czasu dołącza do każdego z nich.

Lesson-3

następnie instruktor prosi wszystkich o dodanie następującej walidacji do danych.

      1. numer telefonu komórkowego powinien mieć 10 cyfr – jeśli numer telefonu komórkowego nie ma 10 cyfr, zastąp go „error”
      2. e-mail powinien mieć jeden znak ” @ „i jeden”.’znak-jeśli e-mail nie ma’ @ 'lub’.’znak, a następnie zastąp go błędem”

przed uruchomieniem scenariusza, w niektórych plikach źródłowych zmodyfikuj telefon komórkowy i e-mail, aby były w błędzie zgodnie z logiką podaną powyżej.

Lesson-4

przygotuj scenariusz, aby odczytać wszystkie pliki źródłowe i sklasyfikować je według ich płci. Pliki dla mężczyzn zostaną zapisane w jednym katalogu, a dla kobiet w innym. W tym celu tworzone są dwa katalogi:

katalog docelowy dla mężczyzn: c:\ibm\sap\training\target\men

katalog docelowy dla kobiet: c:\ibm\SAP\training\target \ women

Załóżmy, że w klasie jest 6 mężczyzn i 4 kobiety, to jeśli wszystkie pliki źródłowe zostaną pomyślnie odczytane, katalog docelowy dla mężczyzn powinien mieć 6 plików, a katalog docelowy dla kobiet powinien mieć 4 pliki.

Case Studies – 2

następnie instruktor prosi wszystkich o przygotowanie jednego pliku z danymi osobowymi każdego ucznia w oddzielnych segmentach.

Lesson-5

napisz scenariusz, który przeczyta ten plik i utworzy 10 plików docelowych, w których każdy plik powinien odpowiadać danym osobowym każdego pracownika. Pliki docelowe powinny być nazwane jako cv_<emp_ID>_<timestamp>

Lesson-6

zmodyfikuj powyższy scenariusz tak, aby tworzył 2 pliki docelowe zamiast 10, gdzie jeden plik docelowy dla mężczyzn i inny plik docelowy dla pań. Plik docelowy dla mężczyzn powinien mieć 6 segmentów dla 6 mężczyzn, a plik docelowy dla kobiet powinien mieć 4 segmenty dla 4 kobiet.

pliki docelowe powinny być nazwane jako

dla mężczyzn – men_<znacznik czasu>

dla Pań-kobiet_<znacznik czasu>

studium przypadku -3

tak samo jak studium przypadku – 1, instruktor prosi każdego ucznia o przygotowanie swojego/jej dane osobowe i zapisać je w pliku XML. Będzie 10 plików. Pliki są zapisywane w katalogu źródłowym.

Lesson-7

przygotuj scenariusz, aby odczytać wszystkie pliki źródłowe z katalogu źródłowego i utworzyć jeden plik w katalogu docelowym. Zostanie wyświetlona nazwa pliku docelowego.xml ze znacznikiem czasu dołącza do nazwy pliku. Plik docelowy będzie miał wszystkie szczegóły KAŻDEGO pliku źródłowego jako sub-segment.

Lesson-8

przygotuj scenariusz, aby odczytać całe pliki źródłowe z katalogu źródłowego i utwórz dwa pliki w katalogu docelowym – jeden dla mężczyzn, a drugi dla pań. Dla 6 mężczyzn plik dla mężczyzn powinien mieć sześć segmentów z detalami każdego mężczyzny, a dla 4 kobiet, podobnie powinny być 4 segmenty z detalami każdej kobiety.

Case Study – 4

instruktor prosi Teraz każdego z uczniów o przygotowanie kolejnego zestawu szczegółów, na który składać się będą następujące dane akademickie:

  1. legitymacja studencka
  2. nazwa szkoły
  3. nazwa uczelni
  4. Nazwa Wydziału
  5. rok przyjęcia

będzie 10 plików i pliki są nazwane ad_1, 2, 3….10. Pliki są zapisywane w katalogu źródłowym. Tak więc każdy student będzie miał teraz parę plików-jeden dla danych osobowych, a drugi dla danych akademickich. Dwa pliki są powiązane z legitymacją studencką. Katalog wejściowy składa się teraz z 10 plików osobistych i 10 plików akademickich.

Lesson – 9

zostaniesz poproszony o opracowanie scenariusza, który wybierze pliki źródłowe i przetworzy je w parze. Scenariusz wygeneruje 10 plików docelowych. Każdy plik docelowy będzie składał się z danych osobowych i akademickich studenta w oddzielnych segmentach. Pliki docelowe będą nazwane res_1, 2, 10.

pliki docelowe będą wyglądać tak:

Lesson – 10

następnie zostaniesz poproszony o zmianę legitymacji studenckiej w niektórych plikach, aby nie miały pasujących akt akademickich lub osobistych i na odwrót. Scenariusz powinien zostać uruchomiony i jeśli znajdzie jakieś pliki, które nie mają odpowiadającego im pliku, proces powinien zakończyć się po pewnym czasie, tj. 2 min i te pliki zostaną przeniesione do katalogu błędów i nie będzie dla nich odpowiednich plików docelowych.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.