Web pro horních 10 000 www.koncier.cz
Zobrazují se odpovědi 1 až 16 z 16

Umí Ms Sql server zavolat URL adresu?

  1. 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?

  2. Co se právě děje na Webtrhu?
  3. 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ů.

  4. 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).

  5. 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 ?

  6. Citace Původně odeslal bingoplayer Zobrazit příspěvek
    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).
    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?

  7. Asi nejvhodnější na toto je service broker - zde

  8. Citace Původně odeslal martinzsa Zobrazit příspěvek
    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 ?
    Toto může být práce na den nebo na měsíc. Osobně bych do toho takto nehrabal.

    Tato věc se nějak pozapomněla při návrhu řešení.

  9. Citace Původně odeslal martinzsa Zobrazit příspěvek
    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 ?
    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).

    Citace Původně odeslal ItSnowsInHellAgain Zobrazit příspěvek
    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?
    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ů.

  10. Citace Původně odeslal bingoplayer Zobrazit příspěvek
    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ů.
    Ano, tak jsem to myslel, příbližně.

    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.

  11. 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.

  12. Citace Původně odeslal bingoplayer Zobrazit příspěvek

    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".
    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í.

    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.
    Naposledy upravil korwin : 13.08.2018 v 14:34

  13. 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

  14. 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...

  15. Citace Původně odeslal skorozacatecnik Zobrazit příspěvek
    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
    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.


    Citace Původně odeslal indy.cz Zobrazit příspěvek
    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...
    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í).

  16. 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

  17. 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á.

Hostujeme u Server powered by TELE3