(0 hodnocení)
Máme jeden skladový systém a více eshopů, které jsou na skladový systém napojeny. Eshopy si drží vlastní skladovou dostupnost ve vlastní databázi, kterou aktualizují buďto ze skladového systému 1x za hodinu vše nebo při přihození do košíku a před odeslání objednávky. Je tak zajištěno, že si zákazník nekoupí něco co nemáme fyzicky skladem.
Problém nastává v tom, že po odeslání objednávky do skladového systému na ostatních eshopech svítí špatná dostupnost u zakoupených položek z jiného eshopu, protože se po objednávce neodečtou kusy i z ostatních eshopů (srovná se to vždy pouze 1x za hodinu). Když zákazník přihodí zboží na jiném eshopu do košíku, tak se sice před přihozením aktualizuje dostupnost ale není nejlepší řešení, když zákazník vidí položku skladem a po přihození mu eshop napíše "už není skladem".
Chtěli bychom tedy v databázi skladového systému vytvořit trigger a ten by po nahrání nové objednávky zavolal url adresy na serverech s eshopy a řekl by jim "aktualizujte si skladovou dostupnost u položek, které Vám zasílám v GET parametru".
Je takové řešení proveditelné? Používáme MS Sql server a vím, že existují možnosti pro spuštění externího programu, ale spíše hledáme řešení zda SQL server umí zavolat přímo http požadavek?
Umí Ms Sql server zavolat URL adresu?
Co se právě děje na Webtrhu?
- Fery poptává: Kodér - plánek sálu
- Levon poptává: Napojení WooCommerce na sendGrid
- TMS poptává: Malý mono e-shop - Shoptet, Prestashop
Hledej: http client mssql
Mělo by to jít. Ale nedělal bych to. Dle mého by to měla obsluhovat vrstva nad tím. Tj. buď bude krom všech eshopů ještě jeden web, který slouží jen pro takovéto services (může dělat vrstvu mezi eshopy a db) nebo si dáš do všech eshopů modul, který bude mít na starosti kontaktování ostatních eshopů.
To mě taky napadlo, ale problém je ten, že na vystavování objednávek používáme i ten zmíněný skladový (je zároveň i účetní) systém - používá se například na prodejnách. V skladovém systému je pak zásah složitější (aby komunikoval i s vrstvou nad ním).
(1 hodnocení)
a preco sa eshopy nedopytuju priamo na db skladoveho systemu ? nie jednoduhsie to napojit priamo na nho ako riesit synchronizaciu s X eshopmi. pripadne nad db skladoveho systemu postavit webservice ktory bude iba vracat aktualnu dostupnost pre danu polozku a jednotlive eshopy budu volat tuto servicu pri overovani mnozstva ?
U těch eshopech nemůžeš přidat novou tabulku, kde by se uložilo info o změnách a "ping" skript by to mohl cronem (1 minuta) vždy ověřit a provést změny?To mě taky napadlo, ale problém je ten, že na vystavování objednávek používáme i ten zmíněný skladový (je zároveň i účetní) systém - používá se například na prodejnách. V skladovém systému je pak zásah složitější (aby komunikoval i s vrstvou nad ním).
Toto může být práce na den nebo na měsíc. Osobně bych do toho takto nehrabal.a preco sa eshopy nedopytuju priamo na db skladoveho systemu ? nie jednoduhsie to napojit priamo na nho ako riesit synchronizaciu s X eshopmi. pripadne nad db skladoveho systemu postavit webservice ktory bude iba vracat aktualnu dostupnost pre danu polozku a jednotlive eshopy budu volat tuto servicu pri overovani mnozstva ?
Tato věc se nějak pozapomněla při návrhu řešení.
Měli jsme tolik požadavků, že už byl problém s výkonem. Hlavní problém je ale že bychom museli udělat větší zásah do eshopu (eshopy byly před skladovým systémem), což se nám nechce (= peníze a čas).a preco sa eshopy nedopytuju priamo na db skladoveho systemu ? nie jednoduhsie to napojit priamo na nho ako riesit synchronizaciu s X eshopmi. pripadne nad db skladoveho systemu postavit webservice ktory bude iba vracat aktualnu dostupnost pre danu polozku a jednotlive eshopy budu volat tuto servicu pri overovani mnozstva ?
Tady asi přesně nechápu. Myslíš novou tabulku společnou pro všechny eshopy, které by si tam ověřovaly změny? Změny se dějí při vystavení i ve skladovém systému (prodej na prodejně) a tak by se tam změny nepropsaly. Pokud to myslíš tak, že eshop odešle objednávku a za minutu si ověří změny, tak změny se nepropíšou do ostatních eshopů.U těch eshopech nemůžeš přidat novou tabulku, kde by se uložilo info o změnách a "ping" skript by to mohl cronem (1 minuta) vždy ověřit a provést změny?
Ano, tak jsem to myslel, příbližně.Tady asi přesně nechápu. Myslíš novou tabulku společnou pro všechny eshopy, které by si tam ověřovaly změny? Změny se dějí při vystavení i ve skladovém systému (prodej na prodejně) a tak by se tam změny nepropsaly. Pokud to myslíš tak, že eshop odešle objednávku a za minutu si ověří změny, tak změny se nepropíšou do ostatních eshopů.
Pokud chceš live update, tak buď stejná DB pro vše, nebo při potvrzení objednávky (z eshopu / prodejny) zavolat skript, který to všude zaktualizuje.
Osobně bych SQL Server nechal dělat jen SQL a řešil to, jak psal aheadnology. Avšak třeba půjde řešení od indy.cz.
Vidím to tak, že nejprve budeme odesílat http požadavky přes SQL server na aktulizace a poté se bude muset ve všech eshopech a skladovém systému vytvořit modul pro vzájemnou komunikaci.
Pokud jsem pochopil funkčnost service broker, tak je to něco jako rabbitmq a moc si bohužel nedokážu představit jak by nám to pomohlo.
Tak to neaktualizujte 1x za hodinu, ale po každé objednávce. Udělejte nějaké jednoduché API k tomu hlavnímu skladu a po každé objednávce spustíte na e-shopech skript co se zeptá toho API na daný produkt (či více produktů), jak je na tom se skladem a aktualizuje. To si myslím, že je nejlepší řešení.
Problém nastává v tom, že po odeslání objednávky do skladového systému na ostatních eshopech svítí špatná dostupnost u zakoupených položek z jiného eshopu, protože se po objednávce neodečtou kusy i z ostatních eshopů (srovná se to vždy pouze 1x za hodinu). Když zákazník přihodí zboží na jiném eshopu do košíku, tak se sice před přihozením aktualizuje dostupnost ale není nejlepší řešení, když zákazník vidí položku skladem a po přihození mu eshop napíše "už není skladem".
Nebo ještě jednodušeji. Pošlete dotaz na změnu skladových zásob po objednání na hlavní sklad a on vám vrátí aktuální stav. Ten vezmete a pošlete na API daných e-shopů k aktualizaci.
Pekna diskuse a tema, diky za nej.
Predpokladam, ze pokud neni zadouci zasahovat do stavajiciho SW, bude treba nejakeho synchronizacniho datoveho mustku, ktery to externe zajisti pres API.
Rad bych se zeptal, o jake mnozstvi produktu se jedna, at uz celkovy pocet v ceniku (skladem), tak i pocet prodanych/upravenych kusu denne, nebo za hodinu? Od toho se pak odviji pripadna zatez stroje, ktery by mel synchronizaci zajistovat.
Potazmo, jsou pro tyto ucely eshopy pripraveny a umi prijmout http pozadavek a na zaklade neho spustit aktualizaci, ktera zpracuje prijata data, nebo si sama stahne nova data a provede update db?
Ptam se proto, ze se uz nejaky cas venuji jednomu projektiku, ktery ma podobne veci na starosti a tohle tema je v posledni dobe cim dal aktualnejsi diky rostoucimu mnozstvi separatnich systemu, ktere je potreba nejak propojit, integrovat. Takze mne vede zajem o to, jak to funguje u tech, ktere jeste neznam :)
Pekny den vsem, co se zapojuji do rozumnych debat tu na Webtrhu
bingoplayer: pomohlo by to tak, že do skladového systému na příjem objednávky by se vložilo pár řádek kodu, který by zavolal jednoduchou service na eshopech např.
https://mujeshop1.cz/UpravSklad
https://mujeshop2.cz/UpravSklad
SQL SEND umí volat URL
Service UpravSklad by mělat také pár řádek kodu a jen by upravila počet dostupných kusů daného produktu
To celé je práce tak na hodinu i s testováním
RabbitMQ je samozřejmě také super. Prostě přijde objednávka, tak ji ze skladu na rabbitu zafrontuji a o nic se dál nemusím starat. A v consumeru už je vyvolání v podstatě stejných service jako u service brokeru.
Celé řešení je typický případ message queue. A nepotřebuji žádné tabulky, crony apod...
Položek je pod 10 000, téměř všechny jsou nabízeny v eshopu. Přesný počet všech volání bohužel nemám k dispozici. Eshop umí velmi snadno aktualizovat dostupnost pro několik položek pokud mu přijde http požadavek s ID položek v GET parametru.Pekna diskuse a tema, diky za nej.
Predpokladam, ze pokud neni zadouci zasahovat do stavajiciho SW, bude treba nejakeho synchronizacniho datoveho mustku, ktery to externe zajisti pres API.
Rad bych se zeptal, o jake mnozstvi produktu se jedna, at uz celkovy pocet v ceniku (skladem), tak i pocet prodanych/upravenych kusu denne, nebo za hodinu? Od toho se pak odviji pripadna zatez stroje, ktery by mel synchronizaci zajistovat.
Potazmo, jsou pro tyto ucely eshopy pripraveny a umi prijmout http pozadavek a na zaklade neho spustit aktualizaci, ktera zpracuje prijata data, nebo si sama stahne nova data a provede update db?
Ptam se proto, ze se uz nejaky cas venuji jednomu projektiku, ktery ma podobne veci na starosti a tohle tema je v posledni dobe cim dal aktualnejsi diky rostoucimu mnozstvi separatnich systemu, ktere je potreba nejak propojit, integrovat. Takze mne vede zajem o to, jak to funguje u tech, ktere jeste neznam :)
Pekny den vsem, co se zapojuji do rozumnych debat tu na Webtrhu
Zkusím tedy napsat vývojářům skladového systému, je to uzavřený systém do kterého se nedostaneme (právě proto jsem se snažil vše dělat nad databází).bingoplayer: pomohlo by to tak, že do skladového systému na příjem objednávky by se vložilo pár řádek kodu, který by zavolal jednoduchou service na eshopech např.
https://mujeshop1.cz/UpravSklad
https://mujeshop2.cz/UpravSklad
SQL SEND umí volat URL
Service UpravSklad by mělat také pár řádek kodu a jen by upravila počet dostupných kusů daného produktu
To celé je práce tak na hodinu i s testováním
RabbitMQ je samozřejmě také super. Prostě přijde objednávka, tak ji ze skladu na rabbitu zafrontuji a o nic se dál nemusím starat. A v consumeru už je vyvolání v podstatě stejných service jako u service brokeru.
Celé řešení je typický případ message queue. A nepotřebuji žádné tabulky, crony apod...
bingoplayer: právě Transact-SQL příkaz SEND můžeš volat z triggeru který bude viset na INSERTu třeba na xxorders_detailxx a zavolá service přímo na eshopech nebo ještě lépe na rabbitu, který to potom rozdistribuje na eshopy
(4 hodnocení)
Uživatel si načte stránku a hned objednává nebo se jde nejdřív napít nebo si zaběhat. Chci tím říct, že bych se o počet/dostupnost staral až v okamžiku vložení do košíku.
Neobjednané košíky je však třeba někdy vysypat a čas do vysypání = doba rezervace zboží.
Šel bych tedy cestou omezení rezervace v košíku než monitorováním skutečného stavu, aniž to někoho z nakupujících zajímá. Alespoň u zboží, kterého je málo.
Když budu prodávat rohlíky, tak se smířím s tím, že dva z posledních deseti nikdo nekoupí, když to budou auta, klidně vysypu všechny košíky čumilů, když si někdo reálně objedná.