REST API v SAP S/4 HANA

REST API (Representational State Transfer Application Programming Interface) představuje moderní způsob, jakým mohou aplikace komunikovat navzájem, a to prostřednictvím HTTP/S protokolu.

Lze si to představit jako analogii k tomu, kdy uživatel načítá webovou stránku z internetu. Dochází k obousměrnému přenosu dat pomocí protokolu HTTP/S mezi webových serverem a počítačem uživatele. Stejného principu používá REST API pro přenos zpráv mezi dvěma systémy, aplikacemi.

V dnešní době se často (vlastně asi většinou) setkávám i u velkých firem s technologií systémové integrace z devadesátých let - posílání textových souborů s oddělovači na FTP server a podobně. Právě tyto zastaralé technologie lze dnes nahradit výrazně spolehlivějšími, jako je SOAP nebo REST.

Další výhodou protokolu HTTP/S je oproti jiným to, že je široce podporován a akceptován v téměř všech sítích. To je výhodou při domluvě se síťovými administrátory, kdy povolení prostupu na firewallu není obvykle problém.

V prostředí SAP S/4HANA má REST API zásadní význam pro integraci různých systémů, rozšiřování funkcionality a zajištění snadného přístupu k datům.

Výhody REST API

• Jednoduchost a přehlednost: REST API je založeno na standardních HTTP metodách jako GET, POST, PUT a DELETE, což usnadňuje vývoj a integraci.

• REST API je stateless, což znamená, že každý požadavek obsahuje všechny informace potřebné k jeho zpracování. To může usnadnit analýzu provozu firewallem a také snížit pravděpodobnost ztráty informací mezi požadavky.

• Podpora různých formátů: REST API může pracovat s různými formáty dat, jako je JSON a XML, což zajišťuje flexibilitu při výměně informací.

• Snadná integrace: REST API umožňuje snadnou integraci s dalšími aplikacemi, což je klíčové pro moderní podnikové prostředí, kde se očekává, že různorodé systémy budou spolupracovat.

Jak funguje REST API v SAP S/4HANA?

REST API v SAP S/4HANA umožňuje vývojářům efektivně komunikovat se systémem prostřednictvím HTTP požadavků. Základní komponenty zahrnují:

• URL Endpointy: Pro každý objekt nebo službu v SAP S/4HANA existují specifické URL, které se používají k provádění operací nad těmito objekty.

• HTTP Metody: Používání HTTP metod pro definování akce, kterou s objektem chceme provést (např. GET pro získání dat, POST pro vytvoření nového záznamu atd.).

• Autentizace: Pro zajištění bezpečnosti a kontroly přístupu je nezbytné implementovat autentizační mechanismy, obvykle pomocí OAuth 2.0 nebo Basic Authentication.

Příklady použití REST API v SAP S/4HANA

• Integrace s e-commerce platformami: REST API může být využito k synchronizaci produktových dat, objednávek a zákaznických informací mezi SAP S/4HANA a e-commerce platformami jako je Shopify nebo Magento.

• Mobilní aplikace: Vývojáři mohou využívat REST API pro vytváření mobilních aplikací, které umožňují zaměstnancům přístup k ERP funkcionalitě z jakéhokoli zařízení.

• Automatizace procesů: Pomocí REST API mohou organizace automatizovat rutinní úkoly, jako je aktualizace databáze nebo generování reportů, čímž se zvyšuje efektivita pracovních toků.

Závěr

REST API v SAP S/4HANA ERP je klíčovým nástrojem pro moderní integraci a rozvoj podnikových aplikací. Umožňuje snadnou komunikaci a flexibilitu potřebnou pro dnešní dynamické podnikatelské prostředí. S jeho pomocí mohou organizace zvýšit efektivitu svých procesů a vytvořit robustní digitální ekosystémy.

Generování a zpracování vlastního IDOC v SAPu

Standardní použití komunikace IDOC je koncipováno jako přenos dat mezi různými SAP i nonSAP systémy.

Tento příspěvek ale popisuje netradiční problém, kdy je potřeba v klientu systému SAP vytvořit IDOC a následně ho v tom samém klientu systému zpracovat. Toto řešení může být použitelné tam, kde chceme zachovat stávající vžité rozhraní ALE monitoringu (transakce WE02, BD87 atd.) i u jiných dat zpracovávaných v systému.

Tento příspěvek vychází z tutoriálu Step-by-step guide to ALE and IDOCs, který však popisuje komunikaci mezi dvěma klienty SAPu. Základním prvkem je použití funkčního modulu IDOC_INBOUND_ASYNCHRONOUS, který ze zadaných dat vytvoří inbound(vstupní) IDOC do systému. Tento IDOC je pak na vstupu zpracován funkčním modulem, který data z IDOCu  zapíše do databázové tabulky.

Nebudu znovu popisovat kroky uvedené ve zmíněném tutoriálu, ale pouze rozdíly, které vedou ke zpracování IDOCu ve stejném systému v jakém se IDOC i vytvořil.

Základem je program pro generování IDOCu v systému, který využívá funkční modul IDOC_INBOUND_ASYNCHRONOUS. Program pracuje s předem založeným message type, idoc type, segment (vše podle tutoriálu).
Dále je idoc naplněn aplikačními a po té řídícími daty. Aby mohl být IDOC vytvořen a zároveň zpracován ve stejném systému, je nutné uvést stejné hodnoty v Recipient a Sender information (Port, Partner number a Partner Type).
Následně je v programu už jen zavolán funkční modul IDOC_INBOUND_ASYNCHRONOUS.

&---------------------------------------------------------------------*
*& Report  Z_IDOC_TEST_ASYNCHRONOUS*&*&---------------------------------------------------------------------**&*&*&---------------------------------------------------------------------*REPORT  Z_IDOC_TEST_ASYNCHRONOUS.
DATA:     ltb_edidc LIKE edi_dc40 OCCURS 10 WITH HEADER LINE, "řídící data IDOCu     ltb_edidd TYPE TABLE OF edi_dd40 WITH HEADER LINE,  "aplikační data IDOCu     S_ZSHSTUSEG LIKE ZSHSTUSEG. " struktura, která je stejná jako definice segmentu IDOCu z WE31 - plní se do ní aplikační dataPARAMETERS: P_NAME LIKE ZSHSTUSEG-ZSNAME. "vstupní parametr     ltb_edidd-segnam = 'ZSHSTUSEG'. "název segmentu IDOCu     ltb_edidd-segnum = 000001. "pořádové číslo segmentu v IDOCu - mohu jich dát více za sebou a přenášet několik záznamů v jednom IDOCu     s_ZSHSTUSEG-ZSTUID = SY-TIMLO. "jako pořadové číslo vkládám aktuální čas - špatně jsem si navrhl tabulku     s_ZSHSTUSEG-ZSNAME = P_NAME.   "plním jmeno ze vstupního parametru do struktury     ltb_edidd-sdata = S_ZSHSTUSEG. "strukturu s daty plním do tabulky? IDOCu     APPEND ltb_edidd.
* Hlavička IDocu - posílám to localhostu do localhostu     CLEAR ltb_edidc.
    REFRESH: ltb_edidc.
    ltb_edidc-direct = 2.     ltb_edidc-mestyp = 'ZSTUDMESTYPE'." message type - WE81, WE82     ltb_edidc-idoctyp = 'ZSHSTUDDOCS'." idoc type - WE30*    ltb_edidc-rcvpfc = ''.     ltb_edidc-sndpor = 'SAPNSP'."tRFC port - SAPNSP je automatický port, který nemusím vytvářet (SID)     ltb_edidc-sndprn = 'T90CLNT090'."sender port - WE20     ltb_edidc-sndprt = 'LS'."partner type - WE20     ltb_edidc-rcvpor = 'SAPNSP'."tRFC port - SAPNSP je automatický port, který nemusím vytvářet (SID)     ltb_edidc-rcvprn = 'T90CLNT090'."receiver port - WE20     ltb_edidc-rcvprt = 'LS'."partner type - WE20     ltb_edidc-tabnam = 'EDI_DC40'.     APPEND ltb_edidc.
* Vytvoření IDocu     CALL FUNCTION 'IDOC_INBOUND_ASYNCHRONOUS' " funkční modul, který ze zadaných dat (ltb_edidc, ltb_edidd) vytvoří IDOC       TABLES                                  " dále však musí existovat logika,která vstupní IDOC zpracuje  (funkční modul-SE37, přiřazení-WE57, input method-BD51, creating process code WE42, generating partner profile BD64-process code-WE20) )         idoc_control_rec_40 = ltb_edidc[]     " popsáno zde - http://saptechnical.com/Tutorials/ALE/Guide/Index.htm         idoc_data_rec_40    = ltb_edidd[]
      EXCEPTIONS         OTHERS              = 1.     IF sy-subrc NE 0.       ROLLBACK WORK.       MESSAGE ID sy-msgid TYPE 'I' NUMBER sy-msgno
        WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    ELSE.* Výmaz nebo kopírování importovaných souborů* funkce pro kopírování: PFL_COPY_OS_FILE*      IF delfile NE space AND server NE space.*        DELETE DATASET piv_pathfile.*      ENDIF.       COMMIT WORK.     ENDIF.* Výmaz dat pro příští soubor     REFRESH:       ltb_edidd.

Výše zmíněný postup by sice IDOC vytvořil, ale ten by skončil s některým z chybných statusů zpracování. Pro korektní zpracování IDOCu je nutné nastavit několik dalších věcí.

V transakci WE20 je nutné nastavit námi použitý Message type do Inbound parameters.

Po rozkliknutí tohoto message type je potřeba určit, který Process code se použije při zpracování příchozího IDOCu.

Použijeme vlastní Process code, který si vytvoříme v transakci WE42 a přiřadíme mu Identification, což je v tomto případě zákaznický funkční modul.

Ve stejné transakci na záložce Logical message přiřadíme Message type.

Zde je uvedený kód funkčního modulu, který se stará o konečné zpracování dat příchozího IDOCu. Funkční modul přijatá data zapíše do tabulky ZSTUDENTS viz. tutoriál.

FUNCTION ZSTUDMESTYPE.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     REFERENCE(INPUT_METHOD) LIKE  BDWFAP_PAR-INPUTMETHD
*"     REFERENCE(MASS_PROCESSING) LIKE  BDWFAP_PAR-MASS_PROC
*"  EXPORTING
*"     VALUE(WORKFLOW_RESULT) LIKE  BDWF_PARAM-RESULT
*"     VALUE(APPLICATION_VARIABLE) LIKE  BDWF_PARAM-APPL_VAR
*"     VALUE(IN_UPDATE_TASK) LIKE  BDWFAP_PAR-UPDATETASK
*"     VALUE(CALL_TRANSACTION_DONE) LIKE  BDWFAP_PAR-CALLTRANS
*"  TABLES
*"      IDOC_CONTRL STRUCTURE  EDIDC
*"      IDOC_DATA STRUCTURE  EDIDD
*"      IDOC_STATUS STRUCTURE  BDIDOCSTAT
*"      RETURN_VARIABLES STRUCTURE  BDWFRETVAR
*"      SERIALIZATION_INFO STRUCTURE  BDI_SER
*"  EXCEPTIONS
*"      WRONG_FUNCTION_CALLED
*"----------------------------------------------------------------------

* Include File containing ALE constants
INCLUDE MBDCONWF.
*TABLES : ZSTUDENTS.
DATA : W_ZSHSTUSEG LIKE ZSHSTUSEG.
  DATA : T_ZSTUDENTS LIKE ZSTUDENTS OCCURS 0 WITH HEADER LINE.
  WORKFLOW_RESULT = C_WF_RESULT_OK.
  LOOP AT IDOC_CONTRL.
    IF IDOC_CONTRL-MESTYP NE 'ZSTUDMESTYPE'.
      RAISE WRONG_FUNCTION_CALLED.
    ENDIF.
*  Before reading a new entry, clear application buffer
    LOOP AT IDOC_DATA WHERE DOCNUM EQ IDOC_CONTRL-DOCNUM.
          W_ZSHSTUSEG = IDOC_DATA-SDATA.
          MOVE-CORRESPONDING W_ZSHSTUSEG TO T_ZSTUDENTS.
          INSERT INTO ZSTUDENTS VALUES T_ZSTUDENTS.
    ENDLOOP.
    UPDATE ZSTUDENTS FROM T_ZSTUDENTS.
    IF SY-SUBRC EQ 0.
      IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
      IDOC_STATUS-STATUS = '53'.
      IDOC_STATUS-MSGTY = 'I'.
      IDOC_STATUS-MSGID = 'YM'.
      IDOC_STATUS-MSGNO = '004'.
      IDOC_STATUS-MSGV1 = T_ZSTUDENTS-ZSTUID.
      APPEND IDOC_STATUS.
      CLEAR IDOC_STATUS.
    ELSE.
      IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
      IDOC_STATUS-STATUS = '51'.
      IDOC_STATUS-MSGTY = 'E'.
      IDOC_STATUS-MSGID = 'YM'.
      IDOC_STATUS-MSGNO = '005'.
      IDOC_STATUS-MSGV1 = T_ZSTUDENTS-ZSTUID.
      APPEND IDOC_STATUS.
      CLEAR IDOC_STATUS.
      WORKFLOW_RESULT = C_WF_RESULT_ERROR.
      RETURN_VARIABLES-WF_PARAM = 'Error_Idocs'.
      RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
      APPEND RETURN_VARIABLES.
      CLEAR RETURN_VARIABLES.
    ENDIF.
 ENDLOOP.

ENDFUNCTION.

Dále je potřeba ještě v transakci WE57 potřeba přiřadit Basic Idoc Type a Message Type k funkčnímu modulu.

Po spuštění programu v SE38 zkontrolujeme v transakci WE02 správné zpracování IDOCu.

Monitoring SAP (2)

RSMO - Data Load Monitor Start

Tato kontrola je relevantní v případě BI systému SAP. Monitoruje stav požadavků na "load" dat z jiných systémů.

SMGW - Gateway Monitor

SAP Gateway řídí CPI-C services, které jsou založeny na TCP/IP protokolu. Tyto services umožňují vzájemnou komunikaci SAPu a externích programů. Také RFC je založeno na CPI-C, tj. všechny RFC spojení jdou přes SAP Gateway. U SMGW kontrolujeme log soubor.

BWCCMS - CCMS Monitor for BW

Relevantní pro kontrolu BI systémů. Kontrolujeme zde především stav PROCESS CHAINů, což jsou datové toky v SAP BW. Pro detailnější analýzu pak použijeme transakci RSPC.

SM21 - Online System Log Analysis

Kontrola systémového logu je velice důležitá kontrola, kterou lze zjistit mnoho informací.

SOST - SAPconnect Send Request

Monitor SAP komunikace. Především se zde kontrolují odeslané emaily ze systému a analyzují příčiny chyb.

SPAD - Spool Administration

V této transakci lze zkontrolovat konzistenci SPOOLu tj. tiskového výstupu.

SP01 - Output controler

Zobrazuje obsah SPOOLu, tj. můžete si zde prohlédnout výstupy posílané na tiskárny, PDF atd.

ST03N - Workload and Performance Statistics

Zobrazuje aktuální a historickou zátěž systému. Důležitá transakce pro ladění systému a hledání úzkých hrdel.

SM66 - Systemwide Work Process Overview

Zobrazuje aktivní workprocessy napříč všemi instancemi.

SM51 - List of SAP Systems

Transakce zobrazí všechny instance a po rozkliknutí uvidíme všechny workprocessy na dané instanci.

  

SM12 - Display and Delete Locks

Zobrazuje zámky tabulek databáze. Pomocí této transakce je možné zámek ručně uvolnit.

STMS - Transport Management System

Kontrola transportních požadavků importovaných do systému.

SM13 - Administrate Update Records

Kotntrola update požadavků do databáze. 

SM04 - User List

Seznam přihlášených uživatelů v systému. Touto transakcí je lze i odhlásit.

SMQ1, SMQ2 - qRFC Monitor Outbound, Inbound

qRFC narozdíl od tRFC posílá data v pevně daném pořadí tak, jak byla vytvořena nebo odeslána. Tyto transakce umožňují monitoring qRFC front. V případě, že se některá qRFC zpráva zasekne, všechna navazující data zůstávají stát a čekají na opravu. 

 

SM58 - Asynchronous RFC Error Log

Monitoring pro tRFC frontu.

Monitoring SAP (1)

Monitorovat SAP potřebujeme především ve chvíli, kdy nastane nějaký problém a my potřebujeme zjistit jeho příčinu. Velice užitečný je i tzv. proaktivní monitoring, který se snaží těmto událostem předcházet a zajistit nápravu ještě před tím, než dojde k závažnějšímu problému. Proaktivní monitoring je dobré provádět každý den a může to orientačně zabrat půl až hodinu denně na systém podle množství chyb. V podstatě si stačí ve složce FAVORITES v SAP GUI vytvořit seznam transakcí k monitoringu a ty každý den projít.

Na větších systémech se monitoring provádí ze samostatného systému SAP Solution manager. Tento centralizovaný monitorovací systém sbírá data od agentů z ostatních SAP i nonSAP systémů. Zároveň se na něm vytváří i jakýsi seznam kontrol (transakce DSWP) pro každý systém. Po vykonání dané kontroly si položku "odfajfkujete" a  po ukončení kontrol vygenerujete report. 

ST22 - Abap Dump Analysis

Tato transakce zobrazuje a analyzuje short dumpy, které vzniknou za běhu systému. Short dump je v řeči SAPu jakýsi error běhu programu. Může vzniknout chybným kódem jak na straně SAPu, tak na straně vlastního vývoje, dále systémovými vlivy jako je výpadek napájení, nedostatek místa v databázi, výpadek síťového spojení atd.

Po rozkliknutí jednoho dumpu se objeví jeho sáhodlouhá analýza. Obecně se dá říct, že pokud programy které způsobily chybu začínají na Z nebo Y, jedná se o chybu vlastního vývoje. Pokud ne, tak doporučuji hledat příčinu na portálu service.sap.com. Přístup do něj mají však jen zákazníci a konzultanti partnerských firem. Něco se dá najít přes google i na jiných webech, ale úspěšnost není příliš velká.

SM37 - Job Overview

Tato transakce slouží pro kontrolu jobů na pozadí. Job je v SAPu chápán jako naplánovaná úloha, která běží na pozadí systému s předem definovaným vstupem a výstupem např. do souboru, spoolu atd. Po rozkliknutí problémového jobu lze zjistit kým a kdy byl naplánován, jak často má běžet, jaký program spouští a přečíst výstup daného běhu. Tím lze zjistit problém - chybné oprávnění, neplatné vstupní parametry, chyba programu atd.

SM35 - Batch Input Monitor

Batch input je jedna z možností jak do SAPu může uživatel hromadně zadávat data. Tyto akce je dobré monitorovat pro případ, kdy by se přenos nezdařil a uživatel nezajistil nápravu. 

ST02 - Setups/Tune Buffers

Transakce pro monitoring SAP bufferů, které zabírají část operační paměti. Jsou v nich uložena často používaná data proto, aby se omezil počet databázových přístupů a tím zrychlil běh systému. V případě nedostatku místa v bufferech dojde ke swapování tj. k odložení části dat na pevný disk, což naopak výrazně zpomalí práci systému. Je tedy žádoucí co nejvíc omezit počet swapů optimalizací velikosti bufferů.

SM12 - TemSe Administration

TemSe je úložiště pro dočasné objekty, které se v systému neukládají dlouhodobě. TemSe využívá např. spool system (tisk). Touto transakcí můžete kontrolovat konzistenci TemSe úložiště.

SM13 - DBA Planning Calendar

Přehled naplánovaných databázových úloh. Liší se podle použité databáze, ale obecně lze přes tuto transakci provádět zálohy databáze, zálohy redologů a jiné databázové úlohy.

DBACOCKPIT - transakce pro Oracle

SAP je možné použít v kombinaci s několika databázemi - Oracle, MS SQL, IBM DB2, MaxDB, IBM Informix. Podle použité databáze se liší transakce pro její správu. Pro často používanou databázi Oracle, zastřešuje množství transakcí pro správu DBACOCKPIT. Touto transakcí lze monitorovat veškeré dění na databázi Oracle - např. informace o tablespaces, indexech, zálohách, redologs atd. Za zmínku ještě stojí, že většina úprav na databázi (přidání tablespace, recovery atd.) se provádí z nástroje BR*TOOLS, což je konzolová aplikace vyvinutá SAPem pro snadnější správu databáze.

SMICM - ICM Monitor

Internet Communication Manager zajišťuje komunikaci mezi SAPem a okolním světem přes protokoly HTTP, HTTPS a SMTP. Je to vlastně server, který přijímá požadavky z internetu a dále je předává SAPu ke zpracování. Transakce SMICM slouží k jeho správě. 

RZ04 - Maintain SAP instances

Slouží k údržbě a kontrole SAP instancí. Doporučuji kontrolovat Instances/Profiles - Consistency check. Tato kontrola projde nastavení profilů všech instancí daného systému a upozorní na případné chyby a vzájemné rozdíly. Dále je zde možno udržovat operační módy SAPu.

SMMS - Message Server Monitor

SAP Message Server zajišťuje komunikaci mezi jednotlivými instancemi SAPu. Jeho činnost a log můžeme monitorovat transakcí SMMS. 

ST06N - Operating System Monitor

Transakce slouží pro monitorování operačního systému - CPU, RAM, HDD atd.

Jak nainstalovat vlastní SAP

K SAPu se člověk nedostane jen tak. Většinou je to spjato s jeho působením v nějaké organizaci, která SAP už používá nebo právě zavádí. Konzultanti dodavatelské firmy provedou potřebnou implementaci systému, což je většinou spojeno s už hodně otřepaným vtipem, že když firma přežije nasazení SAPu, přežije pak už vše:) .

Z důvodu použití transportního systému mezi vývojovým, testovacím a produkčním systémem není dobré ani jeden z nich používat pro vysloveně nezřízené pokusy.

Pro tyto případy je výhodné si postavit vlastní pokusný systém (SANDBOX), který je úplně nezávislý na ostatních. Pokusný systém si můžete zřídit i v případě, že nevlastníte žádnou licenci SAPu.

Na komunitní stránce http://www.sdn.sap.com/irj/scn/nw-downloads je k dispozici několik různých verzí SAP NetWeaver Application Server ABAP pro linux nebo windows v licenci 90 dní trial nebo developer edition (viz. licenční podmínky).

Nejjednodušší variantou je instalace pro Windows. Není problém instalovat na Win XP, pouze na začátku instalace je potřeba ignorovat varování, že nesplňujete systémové požadavky.

Podrobný tutoriál instalace třeba někdy příště - dnes uvádím video, které instalaci pěkně krok po kroku popisuje i s komentářem a není problém podle něj SAP nainstalovat (vyzkoušeno).

( http://youtu.be/mnFqkPkGUpc )

SAP HANA a In-memory databáze

SAP HANA

V poslední době se začíná hodně mluvit o technologiích in-memory databází. SAP se tohoto technologického trendu chytil a hodlá s ním změnit svět databází, jak si můžeme přečíst na serveru ŽIVĚ.CZ. Jestli je to při současném čtyřprocentním podílu SAPu na trhu databází přehnaný optimismus nebo správná vize, uvidíme za pár let. Nedá se ale předpokládat, že by Oracle, IBM nebo Microsoft dali svou kůži lacino.

Co jsou to in-memory databáze

In-memory databáze (IMDB) nebo také main memory databáze (MMDB) používá jako primární úložiště dat operační paměť počítače. Tato technologie výrazně zrychlí zpracování dat oproti standardnímu přístupu na pevný disk. SAP uvádí u své technologie HANA, že je 1200 x rychlejší než doposud používané databáze a jedno jádro CPU dokáže projít 2 miliony záznamů za 1ms. To sebou nese velké nároky a samozřejmě i náklady na velikost operační paměti, protože všechna data jsou uložena pouze v ní.

Všechna data jsou tedy uložena pouze v operační paměti počítače a nikde jinde. Mnohonásobně nám to urychlí zpracování dat, ale co se stane v případě výpadku napájení, pádu systému nebo jen chybě obsluhy s daty? Každý systém je potřeba čas od času restartovat nebo upgradovat a je tedy potřeba nějak vyřešit, co se v té chvíli stane s daty. Na to existuje několik možných řešené v podobě snapshotů databáze, archivování změn databáze pro případnou obnovu, použítí NVRAM (Non-volatile random access memory) - uchová informace i po výpadku napájení nebo použítí technologie vysoké dostupnosti.

Zdroje:

[1] - http://en.wikipedia.org/wiki/In-memory_database
[2] - http://www.sap.com/solutions/technology/in-memory-computing-platform/hana/overview/index.epx

Jak funguje jádro SAP ?

SAP = ABAP + JAVA

(zdroj obrázku: help.sap.com)

Aby administrátor systému SAP byl schopen porozumět příčině chyb a uměl je řešit, potřebuje vědět, jak funguje jeho jádro. V tomto článku se tedy pokusím objasnit základní principy fungování technické komponenty SAP Web Application Server (dále SAP Web AS).

Původně byl sytém SAP Web AS založen na programovacím jazyku ABAP (Advanced Business Application Programming) a jeho běhovém prostředí. Tento jazyk byl navržen tak, aby se jeho syntaxe co nejvíce podobala běžnému jazyku a pomocí něj se dá dělat jak kompletně nový vývoj zákaznických aplikací, tak úprava standardních aplikací SAP.

Od verze SAP Web AS 6.20 má systém dvě běhová prostředí. K ABAPu se přidala JAVA 2 Enterprise Edition (J2EE). Obě prostředí pracují nezávisle a vývoj pro ně probíhá v rozdílných programovacích nástrojích. Při instalaci SAP Web AS je možné specifikovat, které z daných (případně obě) prostředí chcete používat.

Architektura

Architektura SAP Web AS je třívrstvá, tj. různé části (vrstvy) logiky systému lze provozovat odděleně, což velice pomáhá na velkých systémech při rozložení výpočetního výkonu na více serverů.

Databázová vrstva

Databázový stroj (databáze) může být nainstalován na samostatném serveru a představuje tak samostatnou vrstvu systému. SAP podporuje mnoho databází - Oracle, IBM DB2, MaxDB, MS SQL Server ..

Jako příklad teto vrstvy můžeme uvést, že v databázových tabulkách se uchovávají data o zákaznících.

Aplikační vrstva

Aplikační vrstva představuje prostředí pro vykonávání programové logiky (programů) na straně serveru. Jak bylo už napsáno, může to být v prostředí ABAPu nebo Javy. 

Příkladem této vrstvy může být požadavek uživatele, který chce vědět, za kolik peněz odebral daný zákazník zboží za minulý rok. Aplikační logika (program) nejdříve požádá databázi o všechny záznamy faktur za minulý rok pro daného zákazníka. Po té je záznam po záznamu projde, vyloučí např. neplatné faktury, zbytek sečte a dostane tak požadovanou informaci.

Prezentační vrstva

Prezentační vrstva má za úkol předat informaci uživateli. V systému SAP, tak může prezentační vrstvu představovat webový prohlížeč,  SAP GUI (klientský program nainstalovaný v počítači) nebo dnes oblíbené aplikace pro mobilní telefony a tablety.

Instance SAP

Instanci obecně můžeme kostrbatě definovat, jako samostatnou jednotku obsahující všechny nezbytné části a služby pro fungování systému. V naprosté většině případů je jedna instance rovna jednomu aplikačnímu serveru. Někdy se tedy tyto pojmy nesprávně zaměňují.  

V systému SAP musí existovat vždy jedna centrální instance, která zajišťuje pro sebe a ostatní instance základní služby (např. přidělování uživatelů, zamykání objektů atd.). Dále může systém obsahovat další instance, které slouží pro rozložení výkonu na více serverů.

Protože je centrální instance životně důležitá pro chod systému, někdy se konfiguruje tak, aby na ni nebyli přihlašování koncoví uživatelé. Tím se zvyšuje spolehlivost celého systému, protože pád jiné (necentrální instance) např. v důsledku přetížení, pak nemá vliv na chod ostatních instancí. Výpadek tedy poznají pouze uživatelé jedné (přetížené) instance.

ABAP instance

(zdroj obrázku: www.sap.com)

Dispatcher

Každá ABAP instance obsahuje jeden dispatcher, což je komponenta, která přijme požadavek od uživatele a předá ji ke zpracování příslušnému work processu. Zajišťuje tedy rozložení výkonu v rámci instance. Nemůže se tedy např. stát, že jeden požadavek uživatele vytíží systém na 100% a omezí tak ostatní uživatele.

Work processes (WP)  

WP jsou samostatné jednotky vykonávající požadavek ( např. zmiňovaný součet všech faktur zákazníka za minulý rok). Pro představu je můžeme přirovnat k serverovým procesům. 

Jeden WP má alokované pouze určité zdroje a nemůže tedy plně vytížit celý systém a omezit tak práci ostatních uživatelů.

WP je několik druhů, podle toho jaký úkol provádějí ( dialog, update, background, enqueue, spool ).

Message Server (MS)

Zajišťuje komunikaci mezi jednotlivými instancemi a přidělujeme jim přihlášené uživatele. Rozděluje tak zátěž na více aplikačních serverů. Message server je v systému právě jeden a běží na centrální instanci.

ABAP + JAVA instance

Detailní popis samostatné JAVA instance je na samostatnou kapitolu. Uvedu proto jen popis koexistence ABAPu a JAVY v rámci jedné instance.

(zdroj obrázku: www.sap.com)

Jak je vidět na obrázku, požadavky uživatele přicházející ze SAP GUI odbavuje přímo ABAP dispatcher dané instance. Požadavky přicházející z webového prohlížeče přijímá nejdřív ICM (internet communication manager) dané instance a po té je přiděluje buď ABAP nebo JAVA dispatcheru, podle druhu požadavku.

Komunikace mezi ABAP a JAVA work processy zajišťuje JCo (Java Connector).