Vývoj aplikace pro Mergado Store od A do Z

Dobrý den,

pracuju na aplikaci pro Mergado Store a měl bych pár (možná velmi základních) dotazů pro praktické testování a spuštění.

Na dev serveru mám základní hello word aplikaci a přes link je dostupná. Jakým způsobem ji teď do stavu, kdy ji budu moct otestovat přímo v Mergado Store? Abych mohl začít s API atd.

Pravděpodobně budu mít víc dotazů. Pokud už někde existuje něco jako průvodce pro spuštění, tak mě prosím nasměrujte.

Díky

V Mergado Store lze zapnout i DEV verzi aplikace. Pokud se appka jmenuje např. Hello World, tak pro vyzkoušení DEV verze stačí v URL adrese pro správu aplikace připsat za její název .dev, takto: https://store.mergado.com/detail/helloworld.dev/#manage
Následně je možné aplikaci aktivovat a libovolně vyzkoušet přímo v Mergadu.

Možná by ještě do začátku pomohly tyto články:

Mámdotaz na widgety aplikací.
Aplikace mohou být na:

  • projekty (exporty)
  • eshopy
  • uživatele

V dokumentaci se píše o widgetech applikací na projekty.
Jak je to s aplikacemi na eshopy? Jak na jejich widget?

Děkuji.

Appky mají widgety vždy, ať už se jedná pro appky pro uživatele, pro shopy i pro projekty.

Při zobrazování widgetu pro daný typ appky však záleží na tom, kde konkrétně se uživatel v Mergadu nachází.

Ve zkratce:

  • Widgety pro appky pro uživatele se zobrazují v kontextu uživatele, v kontextu shopu i v kontextu projektu.
  • Widgety pro appky pro shop se zobrazují v kontextu shopu i v kontextu projektu.
  • Widgety pro appky pro projekt se zobrazují jen v kontextu projektu.

Hierarchii kontextů lze vizualizovat nějak takto:

obrazek

Jinak v dokumentaci jsou zmíněné i příklady různých URL pro widgety appek pro shopy i pro uživatele, které Mergado v různých kontextech používá: https://mergado.github.io/docs/apps/routing.html#examples

2 Likes

A existuje způsob, jak element widgetu dostat na stránku eshopu na https://app.mergado.com/eshops/[eshop_id]/ ?

Url mám připravené pro eshopy i projekty. Widget s url eshopu jsem našel na https://app.mergado.com/eshops/[eshop_id]/applications/.

Díky

1 Like

Aktuálně nic takového není možné. Widgety appek se - krom stránky “Spuštěné aplikace” - zobrazují pouze na dashboardu projektu, protože právě projekt je tím nejprimárnějším typem entity, v rámci které uživatel v Mergadu pracuje.

Na umístění widgetů appek pro shop na stránku s přehledem projektů konkrétního shopu (a to samé s kontextem uživatele) asi prostě nikdy nevznikl požadavek.

Je to něco, co by se dodělat dalo, ale asi to nebude něco, co by se dalo udělat hned. Přeci jen jde o záležitost i nějakého UX pro uživatele Mergada, kterým by se nějaká náhlá, nepromyšlená změna layoutu hlavní stránky či seznamu projektů v rámci shopu nemusela úplně zamlouvat.

2 Likes

Měl bych prosím ještě jeden dotaz k https://mergado.github.io/docs/apps/app-hooks.html - nemůžu se dostat k datům, který by měl hook posílat v request body.

Vyzkoušel jsem i principy a php knihovnu z Githubu a i od tam jsem dostal MergadoApp\Hook\Client cannot handle request, because the data to be handled is empty . Headers a další data o http requestu se mi daří přečíst. Chybí mi nějaké nastavení v aplikaci? Testuju to pomocí https://app.mergado.com/developers/app/[app_name]/webhooks/

Díky

1 Like

Dobrý den, neznám přesně detaily z vaší infrastruktury a jak přesně vaše webová appka běží (zda je např. za nějakou reverse proxy), ale vlastní zkušenosti vím, že prázdný POST payload může nastat po tom, když HTTP request (např. právě s webhookem) narazí na nějaké “neopatrné” přesměrování (např. přes HTTP 302).

Z webu MDN:

Even if the specification requires the method (and the body) not to be altered when the redirection is performed, not all user-agents conform here - you can still find this type of bugged software out there. It is therefore recommended to set the 302 code only as a response for GET or HEAD methods and to use 307 Temporary Redirect instead, as the method change is explicitly prohibited in that case.

Na vašem místě bych se tedy podíval, zda není možné, že request našeho webhooku na něco takové nenarazí - a pokud ano a máte nad tím kontrolu, tak bych zkusil změnit kód takového přesměrování na 307 Temporary Redirect.

Bez znalosti interního fungování vaší appky je tohle bohužel to jediné, co mě napadá - jako rada, kterým směrem se vydat při zkoumání prázdného payloadu.

2 Likes

Díky za tip. Bohužel se mi to nepodařilo zatím vyřešit. Pro routing používám https://doc.nette.org/en/3.0/routing#toc-mask-and-parameters a pro získání body používám https://doc.nette.org/en/3.0/http-request-response#toc-getrawbody. Žádný dodatečný redirect v aplikaci nemám.

Zkusil jsem simulaci volání hook url se stejnými daty přes Postmana a tam se body přečte a vráti dobře. Ale v menu Webhooks v Mergadu se stále vrací prázdné body. Resp. prázdné body z Mergada. Když na url “ručně” vypíšu testovací data, vrátí se do Webhooks testeru dobře. Nemá Mergado nějaká specifika, které jsem přehlédnul? Díky

1 Like

Zdravím,
já v Nette používám defaultní router a pak v HookPresenter mám:

public function actionDefault() {
	$httpRequest = $this->getHttpRequest();
	$json = $httpRequest->getRawBody();
	$data = json_decode($json, true);

	switch ($data['action']) {
		case 'ping':
			$this->sendJson(['message' => 'pong']);

		...

	}

	...

}

Snad to pomůže :slight_smile:

2 Likes

Nette aplikací to nebylo a příčina byla v redirectu (301 –> 307) .htaccess, které jsem čerpal z http://mergado.github.io/docs/apps/routing.html a nevzpomněl jsem si na to. I tak je zvláštní, že POSTMAN simulace funguje správně. To už může být mou neznalostí :slight_smile: Díky za rady, vyřešeno.

Screenshot 2020-09-16 at 20.49.14

2 Likes

Tím pádem ale nebude problém v .htaccess, ale v tom, že v Developers máte špatně zadanou Hook URL (Developers > Úložiště), zatímco v Postmanovi používáte správné (rozdíl v lomítku na konci). Korektní ḱód na přesměrování podle mě je 301, protože se jedná o trvalý stav, nikoliv dočasný (307)

3 Likes
Funkce | Audit XML | Agentury | Nápověda | Blog | Forum | Kontakt