ABRA API Tutoriál - Základní dotazování
Pokud jste v předchozí kapitole zvládli úspěšné odeslání prvního kontrolního dotazu, můžeme si předvést pár dalších jednoduchých příkladů základního dotazování. Předpokladem je, že máte vše nastaveno a vše vám funguje dle předchozích kapitol.
Načteme si konkrétní objednávku přijatou s ID="1000000101" (objednávka s tímto ID je v demodatech obsažena). Načítáme, tj. zvolíme metodu GET a zadáme následující URL obsahující tentokrát i ID požadovaného objektu:
GET http://localhost:8082/data/receivedorders/1100000101
Pokud bylo vše správně zadáno, obdržíme po odeslání odpověď dle následujícího obrázku:
V tomto případě se načte OP celá, včetně nepersistentních položek a včetně vlastněných objektů a kolekcí. Čili, jak je vidět na obrázku, už se jedná o stromovou strukturu celého objektu (viz např. kolekce řádků Rows) nebo např. nepersistentní položka DisplayName. (Srovnejte s dotazem Načtení kolekce objednávek přijatých v předchozí kap., kde tomu tak není (kvůli výkonu).)
Vytvoříme si objednávku přijatou, na jejímž základě si později vytvoříme fakturu vydanou. Tvoříme nový objekt, tj. zvolíme metodu POST. Budeme ji směřovat na kolekci objednávek přijatých, čili URL adresa bude následující:
POST http://localhost:8082/data/receivedorders
V jednom kroku je možné rovnou zakládat i vlastněné kolekce (v našem případě řádky OP). Data nové OP zapsaná v JSON formátu nechť vypadají následovně:
{
"docqueue_id": "I700000101",
"period_id": "2K00000101",
"docdate$date": "2021-09-09",
"rows": [
{
"rowtype": 1,
"text": "Položka #1",
"totalprice": 123.4,
"vatrate_id": "02100X0000",
"division_id": "2100000101"
},
{
"rowtype": 3,
"store_id": "2100000101",
"storecard_id": "3100000101",
"unitquantity": 2,
"qunit": "ks",
"unitprice": 500,
"vatrate_id": "02100X0000",
"division_id": "2100000101"
}
]
}
Je vidět, že se jedná o stejný formát jako v případě odpovědi na dotaz při načtení konkrétní OP.
V aplikaci Postman se přepneme na záložku Body, zvolíme formát Raw / JSON dle obrázku, vložíme výše uvedená data OP a odešleme:
Po úspěšném vytvoření Web API vrátí status 201 Created a rovnou také kompletní reprezentaci vytvořeného objektu. Viz obrázek:
V předchozím bodu jsme si vytvořili OP. Nyní si předvedeme, jak lze tuto OP přes Web API zaktualizovat. Aktualizujeme, čili zvolíme metodu PUT. Musíme samozřejmě cílit na konkrétní OP, která má být aktualizována, čili URL adresa bude obsahovat ID nově vytvořené OP, viz výše:
PUT http://localhost:8082/data/receivedorders/1540000101
ID vašeho dokladu bude nicméně s největší pravděpodobností odlišné. Je třeba, abyste použili to ID, které jste získali po založení objednávky metodou POST a které vidíte v sekci Headers. Viz výše.
Předvedeme si přidání description. V datech stačí uvést jen to, co chceme na Business objektu změnit:
{
"description": "abcde",
}
Data zadáme a odešleme stejně jako v předchozím případě při zakládání nové OP. Po úspěšné modifikaci rozhraní Web API opět vrátí status 200 OK a rovnou opět kompletní reprezentaci zmodifikovaného objektu.
Kromě jednoduchých aktualizací vlastností BO je možné aktualizovat vnořené kolekce. Předvedeme si přidání dalšího řádku do naší OP (data opět zadáme stejně jako v předchozím případě). Data pro update OP v JSON reprezentaci:
{
"rows": [
{
"rowtype": 1,
"text": "Item #3",
"totalprice": 1234.55,
"vatrate_id": "02100X0000",
"division_id": "2100000101"
}
]
}
Pokud bylo vše správně zadáno, obdržíte opět zmodifikovaný objekt OP již vč. nového řádku.
Obdobným způsobem je možné aktualizovat stávající řádek, pouze by se v datech řádku na začátku specifikovalo ID daného řádku.
{
"rows": [
{"ID": "...."
Tímto způsobem nelze řádky mazat. Je nutné zaslat explicitní dotaz metodou DELETE na adresu řádku (viz práce s řádky objektu).
BO mohou obsahovat fieldy, které není možné nastavovat (typicky počítané fieldy, jako jsou např. částky na hlavičkách dokladů), Při pokusu o vyplnění takových položek je vrácen status 403 Forbidden a patřičné chybové hlášení.
U vlastněných kolekcí (např. řádky dokladů) je možné tyto kolekce procházet opět pomocí odpovídajícího zdroje. Takže pokud bychom např. chtěli vidět řádky naší OP, zadáme metodu GET a URL s uvedením zdroje pro řádky, příp. vč. ID konkrétního řádku:
GET http://localhost:8082/data/receivedorders/1540000101/rows
Příp. vč. ID konkrétního řádku (které zjistíme v předchozím dotazu - vaše bude odlišné):
GET http://localhost:81/data/receivedorders/1540000101/rows/1A50000101
Takto bychom mohli řádek i smazat, tj. zvolíme metodu DELETE a uvedeme URL směřující na konkrétní řádek, jak je uvedeno výše.
V předchozím bodě jsme si vytvořili novou OP. Nyní použijeme importního manažera pro vytvoření nového dokladu Dodací listy(DL) z naší OP. Příklad importu OP do dokladu Dodací listy v rámci Importního manažera je k dispozici zde.
V předchozím bodě jsme si vytvořili DL podle OP. Nyní si v ABRA Gen vytvoříme běžným způsobem FV a použijeme podruhé importního manažera pro import DL do této faktury. Tento příklad máme popsaný v rámci popisu importního manažera zde.
Nyní si předvedeme příklad jiného druhu a to, jak pracovat s číselníky, které podporují skrývání. V tomto případě je třeba do URL za název zdroje uvést views/hidden, pokud chceme jen skryté záznamy, nebo views/all, pokud chceme všechny záznamy vč. skrytých. Další práce se stejná, jako při dotazování jiných BO.
Dále viz podrobný help. Kap.: Struktura URI.
Nechť chceme načíst skrytá střediska. Načítáme, tj. zvolíme metodu GET a zadáme následující URL:
GET http://localhost:8082/data/divisions/views/hidden
Pokud bylo vše správně zadáno, obdržíme po odeslání odpověď dle následujícího obrázku:
Pokud se vám žádné skryté středisko nevypíše, spusťte aplikaci ABRA Gen, otevřete agendu Střediska a některé středisko smažte (použijte funkci Vymazat a v následném dialogu nezatrhávejte možnost Vymazat bez možnosti obnovení - vymazání s možností obnovení znamená skrytí). Následně z Postmanu odešlete uvedený požadavek.
Porovnejte výsledek, pokud zadáte:
GET http://localhost:8082/data/divisions/views/all
a
GET http://localhost:8082/data/divisions
Nyní si předvedeme příklad jiného druhu a to, jak volat QuickReports výrazy (QuickReports funkce). V tomto případě je třeba do URL uvést název zdroje určeného pro volání QR funkcí a to qrexpr a je třeba použít metodu POST. Výraz se uvádí v JSON řetězci, který je hodnotou vlastnosti expr vstupního JSON objektu. Nechť chceme načíst např. název firmy, jejíž ID známe.
Dále viz podrobný help. Kap.: Struktura URI.
URL bude vypadat následovně:
POST http://localhost:8082/data/qrexpr
Vlastní výraz zapsaný v JSON formátu bude následující:
{
"expr": "NxGetValueFromRoll('Firms','Name','1100000101')"
}
V aplikaci Postman se přepneme na záložku Body (zde by měl být nastaveno formát Raw a JSON dle obrázku z předchozích příkladů), vložíme výše uvedený výraz a odešleme:
Po úspěšném zpracování Web API vrátí status 200 OK a rovnou také výsledek volané QR funkce. Viz obrázek:
Dále viz podrobný help. Kap.: Struktura URI a Dotazovací jazyk REST API systému ABRA Gen.
1. Obdrželi jste odpovědi systému tak, jak popisuje text výše?
Pokračujte bodem 2 testu.
Obdržel jsem různé chybové odpovědi, např. chybějící token, nepodporovaná metoda pro danou URL cestu apod. Takové chyby jsou způsobeny typicky nesprávným zadáním URL či zasílaných dat. Vraťte se k textu výše a akce pečlivě zopakujte.
2. Nyní si zkusíme, jak jste text pochopili. Zkuste si načíst agendu Adresář firem (zdroj firms), zadat novou firmu a pak v ní nějaký údaj updatovat. Podařilo se provést?
Pokračujte bodem 3 testu.
Řešení:
-
Načtení agendy Adresář firem: Metoda GET, URL následující:
GET
http://localhost:8082/data/firms
-
Založení nové firmy: Metoda POST, URL a data zadaná v aplikaci Postman na záložce Body budou následující:
GET
http://localhost:8082/data/firms
{ "name": "My new company" }
3. Nyní si zkusíme bonusový test a to změnit adresu, např. město. Podařilo se provést?
Pak gratulujeme k úspěšnému zvládnutí principů základního dotazování. V případě zájmu viz též rozšířené dotazování. Dále viz podrobný help. Kap.: Dotazovací jazyk REST API systému ABRA Gen a Příklady rozšířeného dotazování REST API ABRA Gen.
Řešení: Zde je třeba si uvědomit, že město není přímo položkou BO firmy, ale že adresa je provázaný objekt, čili v JSON musí mít adekvátní zápis:
-
Aktualizace města: Metoda PUT, URL následující:
PUT
http://localhost:8082/data/firms/{ID aktualizované firmy}
{ "ResidenceAddress_ID": { "City": "Prague" } }