1. Bevezető
A sERPa Interfész funkció egy API készítő API, amivel a működési mód függvényében API-kat, illetve API klienseket definiálhatunk. Szolgáltató: "sERPa" működési módban a sERPa biztosít API-t a külső rendszernek, míg Szolgáltató: "Külső rendszer" esetén a sERPa veszi igénybe a külső API szolgáltatásait.
Ebben a topicban a "Külső rendszer" működési módú interfészeket tárgyaljuk.
A külső rendszer használatával üzleti adatokat továbbítunk, ezért lehetőleg titkosított (https) protokollt használjunk.
2. Postman
A Postman egy komplett eszköztár API fejlesztők részére, a programmal gyorsan és hatékonyan lehet dolgozni az API-val, mivel támogatja a fejlesztők minden munkafolyamatát, továbbá elérhető Mac OS X, Windows, Linux és Chrome felhasználók számára is. Ez lehetőséget nyújt a sERPa felhasználók számára, hogy külső szolgáltató esetén teszteljék és megismerjék az API-kat.
A postman letölthető az alábbi linken: https://www.postman.com/downloads/
Mock szerver konfigurálása:
A mock szerver egy olyan eszköz, amivel szimulálni tudjuk a kiszolgáló működését. Esetünkben ahhoz, hogy a sERPában a műveleteket tesztelni tudjuk szükség van egy olyan külső rendszerre, ami szimulálja az ellenoldal viselkedését.
•Először a bal oldali menüben a Mock Servers menüre kell kattintani.
•Ezután felül a New gombra.
•A Felugró ablakon pedig ki kell választani a Mock Server lehetőséget.
•Ezután a collection fül jelenik meg. Ez az ami a végpontokat jelenti. A Mock server elkészítése önmagában nem elég és itt rontottam el a múltkor. A serverhez ugyan úgy ahogy a serpa esetében elemeket kell felvenni különböző végpontokkal. Ez a lépés maradt ki nekem a múltkor. A request becsenget a mock szervernek és a megfelelő végponton kommunikál (logikus, csak nem tudtam hogy kell ezt megcsinálni ez előtt). Ez talán kipróbálás szempontjából nehezebb mint amikor a serpa a szolgáltat
•A következő fülön elég a nevet megadni esetünkben. Majd create.
•A felugró ablakon a megjelent urlt kell használni az API definiálásánál az alap adatoknál.
•A válaszokat a gyűjtemények között lehet definiálni. Az elkészített mock server bekerül a gyűjtemények közé. Alatta található a mock server maga, az előbb kimásolt URL-rel, alatta pedig az a „gyűjtemény”, vagyis végpontok, amik a válaszokat tartalmazzák.
1.Az első fül a "gyűjtő mappa" ide kerül minden olyan szerver, végpont, hívás, ami az adott mockszerver "témájához" tartozik
2.A második nyílnál van maga a mockszerver. A megadott URL-en a kérések az adott szerverre futnak be.
3.A harmadik nyílnál az adott híváshoz tartozó végpontot találjuk. Ahogy abban az esetben amikor a serpa a szolgáltató egy URL-hez több végpont is tartozhat, ez a külső rendszernél is igaz. Tehát egy szervernek minden híváshoz tartozhat akár 1-1 végpont.
•A válaszokat az adott vépont bodyjában kell megadni. Ez az alsó szövegmező. A felső szövegmezőben a request JSON-t kell megadni, amennyiben ez szükséges. A JSON adatot a sERPában elvárt módon kell itt is megadni.
Egy [] jelöli a tömböt melyben vesszővel elválasztva {} belül helyezkednek el az objektumok
•Új példát a mock serverre jobb gombbal kattintva majd az Add example menüpontot kiválasztva lehet megadni.
Megnyitva a Mock server áttekintést láthatjuk, hogy milyen kérdéseket intézett a sERPa a szerverhez. A táblázatban láthatjuk az egyes URL-ekre beérkezett requestet és a szerverünk által adott választ vagyis response-t.
Az áttekintő ablak tetején lévő Refresh Logs gombbal tölthetjük újra az eseményeket. Abban az esetben, ha csak beérkező adat van, vagy rossz URL-re érkezik be a kérés, amire választ várunk, a response oszlopban No matching request figyelmeztetést kapunk.
Egy szervernek több végpontja lehet ugyan úgy mint a sERPában definiált API-nak. A Mock szerverben megadott példák a külső szerver végpontjai. (A sERPában ez az API / Elemek fülön található végpontoknak felenek meg)
A URL után megadott végpont névnek meg kell egyeznie a sERPában definiált elem végpontjával.
3. Adatátadás külső rendszernek
Adatátadás külső rendszernek típusú API esetén a serpában bekövetkezett esemény hatására a sERPa meghatározott információt ad át az ellenoldalnak. Ez az esemény lehet ütemezett vagy trigger által kiváltott.
Ezt az alábbi mezőben megadott értékkel tudjuk beállítani.
Ütemezett eseményt a Működési gyakoriság mező értékével lehet megadni. A legördülő listában kiválasztható értékek a következők:
•negyedóránként
•félóránként
•óránként
•naponta
Ebben az esetben a megadott időnként végzi el a műveletet. A Triggert a Trigger feltétel funkcióban kell definiálni.
Példa:
A példában egy olyan trigger feltétel van definiálva, ami az Interfész besorolású termékeken történt változásokat figyeli. Amennyiben ezekben a termékek adataiban válotás történik a sERPa adatot küld a külső rendszernek.
A működéséhez szükséges még egy Eredményhalmaz definiálása is. Az eredményhalmaz bemenő paraméterének meg kell egyeznie a trigger által átadott értékkel.
Példánkban ez egy Termék ID. Tehát olyan eredményhalmaz kell most, aminek a bemenő paramétere a Termék ID.
A trigger hatására az eredményhalmaz megkapja a Termék ID-t lefut és a Eredményhalmaz eredményét a megadott adatstruktúrával (XML, JSON) átadja a külső rendszernek.
A metódus ebben az esetben POST.
Ha jól van beállítva a mock szerverünk, akkor az eredmény azonnal látszik. Nem kell meglepődni ha a response mezőben error üzenet van. Esetünkben nem definiáltunk választ és nem is feltétlen várunk el.
A Refresh gombra kattintva tölthetők be a request-response körök ahol a táblázatban látszik mikor érkezett be a kérés, hova érkezett be a kérés és honnan érkezett a válasz (melyik végpontról)
4. Adatlekérdezés külső rendszerből
Adatlekérdezés külső rendszerből típusú API-nál a sERPa átad egy adatot, amit a külső rendszer feldolgoz és a ennek megfelelően adatot szolgáltat a sERPának. A sERPa a beérkezett adatot feldolgozza és a felhasználó által definiált műveletet elvégezteti a programmal.
Adott tehát egy API végpont definíció:
A metódus ebben az esetben is POST.
A működést itt is kettőféleképpen állíthatjuk be. Az előzőhöz hasonlóan itt is lehet időközönkénti működés vagy trigger által kiváltott működés. A működése megegyezik a fent leírtakkal.
Az előző típushoz hasonlóan itt is definiálni kell egy Eredményhalmazt. Az eredményhalmaz eredményét átadja az ellenoldalnak. Az ellenoldal a meghatározott működésnek megfelelően feldolgozza az adatokat és ad egy választ.
A művelet paraméter táblázatban lehet megadni, hogy a művelet mely adatokkal tudjon dolgozni. A működése megegyezik azzal a működéssel, amikor a sERPa a szolgáltató.
Példa:
Esetünkben termékfelvétel-módosítás-törlés művelet van hozzárendelve a végponthoz. A sERPa küld egy adatot, ez lehet például egy termék név, kód, ID. Az ellenoldalnál van egy meghatározott működés, például:
•Az átadott termék név, kód, ID-vel keresse meg a külső rendszerben a terméket és az értékeket adja vissza válaszként. A választ a sERPa feldolgozza és ha szükséges módosít rajta.
•Az is előfordulhat, hogy van olyan termék ami a külső rendszerben szerepel, de nálunk még nem. Ebben az esetben a sERPának meg lehet adni, hogy a válasz terméket vegye fel a rendszerbe.
Trigger esetén a működés ugyanez, csak ebben az esetben egy esemény váltja ki a kérdés-válasz kört.
