Ahojte,

čeká mě návrh obousměrné synchronizace dvou systémů a rád bych se od vás inspiroval ať nevymýšlím něco co už dávno funguje.

Jedná se o přenos dat z SQL databáze ze Serveru1 do E-Shopu (Server2) pomocí WEB služeb a naopak.

Musí se přenášet pouze změny protože v tabulkách může být okolo 100 000 produktů a milióny atributů.

Můj návrh

Do každé Sql tabulky budou přidány sloupce LastChangeDate a LastProcessDate dále bude nad každou tabulkou jednoduchý trigger Insert/Update, který porovná zda se změnili data a pokud ano tak zapíše aktuální datum do sloupce typu datetime LastChangeDate nad danou tabulkou. Tabulky nyní obsahují také sloupec typu timestamp (ale ten je nevyhovující protože se jeho hodnota mění i když jsou data stejná a nelze vynutit jen update při změně v datech). Program zajišťující přenos dat ze Serveru 1 přenese všechny záznamy s datumem posledního zpracování LastProcessDate = NULL nebo kde datum poslední změny LastChangeDate je vyšší než datum zpracování. Po zpracování uloží program do LastProcessDate aktuální datum SQL Serveru který si vyžádal na začátku přenosu (Aby se do dalšího zpracování dostaly záznamy které se změní během přenosu).

Teoreticky může být sloupec LastProcessDate v jiné žurnálové tabulce aby mohli změny zpracovávat i další systémy.

Výmaz bude řešen příznakem deleted = true, který nastavuje systém.

Na E-Shopu bych volil podobný mechanismus dvou sloupců s tím že přes webovou službu se nebude měnit LastChangeDate aby se změny nezacyklily.

Pokud se bude jednat o propojení dvou systémů (Což se předpokládá) tak je to jakž takž funkční. U propojení více systémů je problém s výmazy a kde si uchovávat zda systém výmaz provedl a datum změny atp..

Napadá vás lepší řešení, které bude dostatečně výkonné ?

Uvažoval jsem o nějaké hezčí integraci typu sběrnice atp. Ale tady by byla fronta zpráv tak náročná na obsluhu a zpracování že si to nedokážu v praxi představit. Při každé změně (kterých může být i v rámci ctvrt hodiny tisíce by se musela generovat zppráva.

Budu moc rád za rady, tipy a triky :o)

Nejaku frontu si musis urobit tak ci tak.

Ja som to kedysi davno riesil tak, ze v kazdej tabulke, ktoru som chces synchronizovat, som mal trigger, ktory vygeneroval pri kazdom update/insert/delete nejaky command, ktory som si ulozil do databazy. Niekde potom bezal Windows Service, ktory tieto commandy cital, posielal WCFkom do externeho systemu, napriklad eshopu. Ked eshop vratil ok, tak som oznacil tento command za processnuty.

Problem tvojho riesenia je, ze ak si pozeraz iba posledny stav entity, tak sa mozes dostat do nekonzistentneho stavu. ako napriklad zriesis mazanie?

@T: inak, ked som tak rozmyslal nad vyhodami EventSourcingu, tak synchronizacia ma nenapadla, ale teraz sa mi to zda ako dalsia vyhoda. Riesit synchronizaciu zalozenu na evensourcingu je jednoduchsie, ako riesit synchronizaciu relacneho modelu. Co povies? :)

Pred odpovedou najskor otazky:

- ako budu synchronizovane systemy? snaha aby to bolo co najviac live, alebo pojde o cisto synchronizacny task raz za nejake obdobie

- obe db budu vo vztahu master-master alebo na urovni tabulky, pripadne riadku bude vzdy jedna db slave

- aky je predpoklad vzniku konfliktov, teda ci sa nejaka hodnota moze zmenit v oboch systemoch

- aky je scenar riesenia konfliktov - last in je win, alebo manualne riesenie, alebo ...

Liero:

Díky za reakci,

první model propojení byl právě založený na logu událostí, ale byla to cesta do pekla. Je to propojení IS, který dělá spoustu akcí a není problém zaktualizovat x tabulek x krát za sebou. Už tak když mě bude pouze zajímat poslední stav produktu tak to budou milióny záznamů pro přenosy. Nedokážu si představit že bych každou akci takhle logoval. A kdyby byl výpadek přenosových služeb třeba na den tak to databáze neustojí. Na výmazy buď bude tabulka a nebo třeba sloupec smazáno. Ale co se týče update/insert tak mě zajímaá pouze poslední stav. Jedná se hlavně o data produktů, zákazníků atp.

Trigger který mám nad tabulkou musí být naprosto jednoduchý aby nezpomalil běh systému jako takového.

Vlko:

1) Snaha aby vše bylo co nejvíc live.

2) IS bude spíš jako master tzn že se nebudou zakládat produkty na E-Shopu, ale možná i takový požadavek padne. Struktury obou systémů jsou naprosto různé takže musí docházet v přenosovém programu na transformaci dat.

3) Tím že se budou synchronizovat jen změny tak budou konflikty minimalizovány. Pokud ke konfliktu dojde tak poslední vyhrává.

1. musis asi trochu presnejsie popisat, ako ma synchronizacia vo vysledku vyzerat.
2. Ak chces mat systemy live, tak musis posielat v podstate kazdu akciu, takze tym ze budes posielat len posledny stav az tak vela neusetris.
3. Mat milion zaznamov v databaze nieje problem, ak ich citas za sebou napr. po stovkach. Pokial to nema vazby na ine tabulky, co by nemalo mat, tak ta pocet zaznamov nemusi trapit, jedine ze pouzivas Sql Express.E
4. neodpovedal si mi na otazku, ako chcet zriesit zmazanie nejakej entity?

Ak budes mat na oboch systemoch vzdy rovnaky pocet poloziek, tak sa to da, ale inak si musis odkladat tie commandy.


Ono idealne riesenie pre teba by asi bolo, keby si mal dve synchronizacne systemy:
1. Realtime synchronizacia, teda ze kazdy command by si poslal do oboch systemov
2. Vedel by si si vypytat aktualny stav, alebo trebars zmeny za poslednych x dni a tieto spatne sozynchronizovat.

Takto by si zriesil aj aktualnost dat, aj vypadok niektoreho zo servrov

Mas tieto moznosti

1. old school synchronizacia pomocou par db stlpcov ako state (Insert, Update, Delete) a LastChangeDate + tabulka historie synchronizacii, aby si nemusel ukladat LastProcessDate. Tato synchronizacia je dobra ak synchronizacia prebieha raz za cas, lebo posledne zmeny selectnes jednoduchym selektom
2. Messaging system na oboch stranach, kde kazda change sa bude logovat, do msmq pozor nie na urovni riadku tabulky, ale zmeny, teda ak nejaky edit zmeni entitu, neulozis to ako n insertov, ale cely stav. Potom mozes mat redukcny task, ktory za nejaky cas pickne vsetky change a ak ide o zmenu stavu jednej entity, tak to nejak inteligentne spoji aby do druhej db isiel len jeden change script. Druha strana potom je notifikovana o zmene, zoberie a na zaklade nejakej biznis logiky vygeneruje potrebne update/insert prikazy a podobne to pojde z opacnej strany. Tento scenar by poriesil vsetky tovje problemy, pretoze redukcia cast ti vyriesi pripadny offtime a nasledny brutalny narast dat a to ako casto budes
3. Jeden messaging system, kde zmena bude hned publikovana aj do druhej db, tu je problem riesit offline stavy
4. Replikacie a to bud budu db rovnake, alebo budes na obidvoch systemoch drzat svoju db a repliku tej druhej, potom uz lne napisat dobre replication script a mas vystarane

Liero:

2. Většinou synchronizace bude probíhat téměř okamžitě. U logování akcí může nastat problém pokud bude druhý systém offline. A pokud IS nepěkně zapisuje. Například při novém záznamu ho hned prázdný ukládá do DB pak při stornu dá delete atp...

3. Milion by bylo jen záznamů v DB kdyby byl dlouhodobější výpadek cílového systému a fronta se nezpracovávala (běží to na pozadí a většinou se o to zákazníci nechtějí starat) a proběhli nějaké hromadné update/insert/ tak to může narůst až n násobně. Navíc cílový systém nemusí vědět o tom že se třikrát změnila hodnota skladu, ale zajímá ho výsledná hodnota. Tady by to řešil návrh by vlko na inteligentní merge akcí.

4. Mazání se dá řešit tak že IS dá u entity příznak Delete a akce se provede na cílovém systému a paxe teprve odmaže z IS (nic moc řešení). Nebo zápis do tabulky pro výmazy kde se uloží jen identifikátor. To by třeba mohl řešit i trigger.

Přesně to zvažuju změny online (zatím nejsem přesvědčen o frontě) + objekty zaserializované do XML a zkomprimované pro denní aktualizace.

vlko:

1. Je mi jasné že nejde o extra moderní řešení. Nic méně dá se říct že bude nejméně náročný na prostředky. Ono totiž v IS josu schopni pustit přecenění na všechny produkty klidně 2-3 denně. Což když spočítám počet ceníků a produktů jsou milióny záznamů záznamů s ne zcela jednoduchým objektovým grafem. A pokud by přenosy trvali delší dobu tak si zákazníci začnou stěžovat.

2. Toto řešení se mi líbí i nápad s mergem stavů. Ale myslím že přenos obrovských změn by trval dlouho a navíc je hodně náchylný na chyby. Když si vezmu akce které by se museli řešit: Trigger (možná broker) zachytí změnu a zapíše ji do změnového logu. Program pro synchronizaci zmerguje všechny změny do jedné akce a vygeneruje zprávu pro E-Shop. E-Shop si zprávu ihned převezme (aby bylo zajištěno že změny se projeví) a provede akce. Dál systém přenosu dat označí změny v logu za zpracované. Je tady v podstatě akce toho Merge. Nic méně udělat správný merge na základě obecných identifikátorů jako jsou kódy atp nebude jednoduché. Například uživatel smaže ceník s kódem X a poté ho navede. Na začátku jsme prototypovali Fronty a chtěli jsme použít SQL Broker ale narazili jsme na problémy s výkonem a rychlostí :o( Každopádně toto řešení si ještě pořádně projdu byl by to pak docela pěkný systém co se týče architektury :o)

3. Změna se nemůže projevit synchronně protože by byli omezeni uživatele IS

4. Replikace nepříchází v úvahu DB E-Shopu není veřejná navíc by byl přenosový progra příliž vázaný na tabulky E-Shopu.

do db triggerov si kludne mozes dat nejaku logiku, ze sa ti nevytvori  command na synchronizaciu , ak insertujes len prazdnu entitu.

ja preferujem toto riesenie, pretoze je v istom zmysle najrobustnejsie. Ked bdues robit nejake zmeny, tak sa ti s mensou pravdepodobostou stane, ze sa dostanes do nekonzistentneho stavu.

tato fronta commandov moze byt robena napriklad aj tak, ze si ulozis len idcko entity, a akciu insert/delete/update. Ked budes synchronizovat, tak zosychnronizujes posledny stav danej entity a ulozis si cas zosynchronizovania. Ked nahodou pri dalsej synchronizacii natrafis na command, ktory odkazuje na tu istu entitu a tento command bol vytvoreny skor ako posledna synchronizacia, tak ho mozes preskocit, kedze entita je uz zosychronizovana.

ked budes synchronizovat len posledny stav, tak si musis byt vedomy, ze je tazke urcit poradie entit, v akom sa synchronizuju, lebo sa mozes stat, ze na druhom konci budes chciet insertnut zaznam s neexistujucim cudzim klucom. Na pohlad banalne, ale nieje to jednoduche vyriesit.
Skus si napriklad zobrat tabulky Category, Produkt a medzi nimi parovacia tabulka ProductCategory, cize m:n vazba. V akom poradi budes synchronizovat?

a.d. inteligentny merge - jedina rozumna vec ktora sa da vymysliet je definovat aggregaty. Aggregat je nieco co okrem ineho ohranicuje konzistentnost medzi entitami zahrnutymi pod aggregat.
Aggregatom moze byt byt tak objednavka ako i kludne cely produktovy katalog ak je to v danom kontexte zmysluplne.

Aj kde ide o shop, nie je to lahka domena a najprv sa treba pozriet na to businessovo, ci naozaj zakaznik pozaduje taku konzistentnost medzi oboma systemami, ako sa to tvarilo pri prvych popisoch.

Zasadna otazka je, ci mas kontrolu na kodov v IS, alebo je uzatvoreny.

Vzdy si zvol system, ktory bude handlovat command. Napr. command(=specialny typ message) na vytvorenie objednavky sice moze forcenut user cez shop GUI, ale moze to byt len command delegovany na IS, ktory zabezpeci patricny processing. Shop sa dozvie o zmene stavu cez event(zase typ message), ktory obsahuje vsetky relevetne informacie(typicky aggregat objednavky) ktory bude publikovat IS a na ktory bude pocuvat Shop. Shop si buduje vlastny query storage(ktory je denormalizovany, moze byt kludne v relacnej DB), pretoze ak potrebuje nejake informacie o objednavke, tak len na zobrazenie. Tiez to je o security, do public web zony asi nechces dat citlive data, ale len nejake nevyhnutne data o objednavke.(aby si user mohol prezerat historiu objednavok?) Ak nemas IS pod kontrolou a nemozes patchovat domain vrstvu, mozes to kludne riesit nad RPC notifikaciami nad DB, ale nebudes sa snazis synchronizovat kazdu blbu zmenu nad kazdou tabulkou, ale cele aggregaty.

Iny pripad....pregenerujes sa produktovy katalog. Opublikujes udalost o zmene obsahujucu bud len vsetky zmenene produkty alebo cely aktualny katalog, alebo to mozes robit po kategoriach alebo po produktoch. Nech by si sa aj rozkradal, nikdy 100% konzistenciu(to co bolo odkliknute v IS bude hned na shope) nedosiahnes a urcite ju nikto od Teba pozadovat nebude. Ak budu nieco chciet editovat v shope, tak to podla mna budu nejake popisky, cize nie tie iste data, co riesi IS.A ak by nebodaj ano, tak to vyriesis ako command message voci IS.
Hranicne situacie moze kludne riesit clovek, co bude spracovavat objednavku pripadne si schvalia to, ze pripadne dorobis logiku, ktora objednavky, ktore sa zasadnejsie lisia od aktualnej katalogovej ceny v IS nejako oznacis - a clovek rozhodne a clovek bude riesit.Toto je pomerne zlozita tema a tazko sa vtesnava do prispevkov na fore.

Vlko spominal msmq. Ja ho odporucam len v kombinacii s NServiceBus, ktory ma vyriesenych kopu veci, napr. prechod medzi zonami tak aby si neporusil zakladny princip, ze komunikaciu zahajuje vzdy zona s vyssou citlivostou udajou voci tej s nizsou.

Tomáš Zeman, MCSD.NET, MCPD

@liero:

ES ..neviem, ci by bol na nieco ci ma zmysel a je ziaduce rekonstruovat celeho aggregata.

"lebo sa mozes stat, ze na druhom konci budes chciet insertnut zaznam s neexistujucim cudzim klucom. Na pohlad banalne, ale nieje to jednoduche vyriesit."

Naco su Ti FK na webe, ked tie data potrebujes zobrazovat? (typicky produktovy katalog?) Naco zbytocne joiny na webe kde ide o vykon?

"Skus si napriklad zobrat tabulky Category, Produkt a medzi nimi parovacia tabulka ProductCategory, cize m:n vazba. V akom poradi budes synchronizovat?"

Odpoved je jednoducha

a) kazdy produkt aggregat sa bude synchronizovat aj s jeho zaradenim do kategorii

b) publikujem vzdy cely produkt katalog, ktoreho sucastou su aj aktualne kategorie

Tomáš Zeman, MCSD.NET, MCPD

@liero:

ES ..neviem, ci by bol na nieco ci ma zmysel a je ziaduce rekonstruovat celeho aggregata.

"lebo sa mozes stat, ze na druhom konci budes chciet insertnut zaznam s neexistujucim cudzim klucom. Na pohlad banalne, ale nieje to jednoduche vyriesit."

Naco su Ti FK na webe, ked tie data potrebujes zobrazovat? (typicky produktovy katalog?) Naco zbytocne joiny na webe kde ide o vykon?

"Skus si napriklad zobrat tabulky Category, Produkt a medzi nimi parovacia tabulka ProductCategory, cize m:n vazba. V akom poradi budes synchronizovat?"

Odpoved je jednoducha

a) kazdy produkt aggregat sa bude synchronizovat aj s jeho zaradenim do kategorii

b) publikujem vzdy cely produkt katalog, ktoreho sucastou su aj aktualne kategorie

Tomáš Zeman, MCSD.NET, MCPD

dalsia vec:

kategorizaciu produktov si zvacsa chcu riesit nezavisle ludia spravujuci shop, tiez managenovat popisky, obrazky. To co prichadza z ERP pouzivaju max ako nejake defaulty. Je hlupost, aby kvalifikovany clovek, ktory riesi veci v ERP(nakupca, product manager) este riesil detailne popisky a obrazky v granularite v akej ich potrebuje clovek na shope. Tiez znasilnovat ERP na editor produktoveho katalogu pre web je vesela predstava. Naopak v ERP je Ti takyto detail o produkte naprd. lebo clovek, ktory produkt manageuje ho pozna. (iny model je taky, ze product manager si riesi aj katalog pre web, ale tam je vhodny urcite iny WF ako nejake naivne updatovanie katalogu pod zadkom)

Dalsie paradoxy. Clovek si supol produkt do basketu.(vyberal fakt dlho a kedze bol levny pepa trapi ho kazdy halier). Clovek v ERP zmeni cenu produktu a zase ju za chvilu trochu zmeni. Levny pepa je nestrany, lebo po polhodine klikania objednavky sa mu zmenila cena a musi si ju preskladat. Pritom business clovek povie, ze nevadi, lepsi pre neho zakaznik ako pripadna strata.(dokonca moze byt zisk). Ked rozdaval produktove katalogy papierovo, tak bol tiez velmi konzervativny v tom, ze ked niekto zavolal, ze nieco chce a jemu sa zvysila cena nakupu, ze ta cena neplati a ze je ina.

Ale dobre, tak si povie, ze ok, on ceny v ERP menit nebude behom dna, lebo vie, ze nejaky blbec to synchronizuje na web. Tak si otvori excel a zacne znacit zmeny. Vecer pekne zacne nahadzovat zmeny. Programator zajasa, no vidite ujko, ze to ide.
 

Tomáš Zeman, MCSD.NET, MCPD

T: dííky

Na začátku když jsem řešil první synchronizaci tak jsem to chtěl udělat robustně. SOA moc pěkná věc každý systém si zapíše co chce odebírat atp... Všechno řešit pěkně zprávama. Bohužel v IS chtěli spravovat celý katalog včetně generických vlastností v jazykových mutcích, zakládání stromů atp.... prostě chtěli mít data nachystané pro tištěné katalogy, E-Shop, vyhodnocování atp. Takže jsem hned narazil na výkonostní problémy. Firma si najme plniče dat a už se valí jedna změna za druhou. X krát přepisování popisků, vytváření mazání generických vlastností a plnění jejich hodnot k produktům, obrázky, hromadné změny, atp. Navíc si to zrovna chtěli kontrolova na webu. Naštěstí model řízený zprávami a aktualizace po celých agregátech byl jen prototyp. Možná byl problém v tom že jsem stavěl přenosový systém pro dva uzavřené systémy. Musel jsem zajistit správné párování dle kódů a dalších znaků a dle nich vytahovat identifikátory systémů a plnit vazby.

Další verzi přenosů jsem už postavil na časových razítkách a synchronizaci po drobných objektech.

Když tak čtu příspěvky tak ve všech vidím robustnost. Mě osobně se to taky líbí. Otázka je jestil se v tomto případě nezneužívá. Model integrace systémů pomocí zpráv se mi hodně líbí a myslím si že největší význam má v různých workflow kde netečou obrovské data. Například založení požadavki na vyskladnění tento proces se dá vystavit pro další systémy jako zpráva, různé zakládání dokumentů, objednávek, změny stavů objednávek, hlášení odvedené výroby. Ale napojit na jednotlivé zprávy propracovaný produktový katalog mi nepřijde úplně v pořádku.

A otázka nakonec podařilo se vám někomu zaintegrovat opravdu velké systémy kde tečou obrovká data ? + Třeba použili jste BizTalk atp ? Budu moc rád za rady a tipy. Jak jsem už zmiňoval SOA se mi moc líbí. Když jsem kdysi propojoval ERP s plánovacím systémem tak byla situace veselejší přenos pouze kmenových dat a zpět pouze hlášení výroby z dílny :o) to se to moc pěkně navrhovalo.

Nicméně mě to znovu motivovalo si toto ověřit a implementovat si sběrnici pro tento scénář NServiceBus snad nejsem s pojmy uplně mimo :o)

Další smutnou zprávou je že se propojuje další IS a zákazník má úplně stejné požadavky prostě všechna data pro katalogy udržovat v něm. Hmmm zamyslím se jako zákazník a asi bych to tak taky chtěl. Mít datovou základnu spojenou s IS (nemusí to být samozřejmě přímo jeho součást)

@filx:

skusim strucne, musim nieco dokoncit rychlo, potom pripadne viac...

a.d. uzatvorene systemy - ano, to je problem, to absolutne limituje tvoje moznosti robit rozumnu architekturu. Cize ak to spravne chapem tak tvoje moznosti spocivaju na integracii na urovni databazy?

a.d. Produktovy katalog - specilizovana aplikacia/domena - v tom pripade to dava naozaj zmysel a toto je specialny bounded context. Jo, ale naozaj tak ze tam nie je nejaka revizia skor ako sa aktualizovany produkt(katalog, cast katalogu) dostava na web? (*** dole uvaha o zvratenosti takehoto systemu)

OK. Ale radovo kolko zmien to moze byt? Nech maju 200 ludi a kazdy urobi 2 zmeny v katalogu za minutu. To je 400/min, cize nic. Hromadna zmena? Nech sme na 1000/min, 2000/min. cize nic. Hromadnym mozes dat nizsiu prioritu.(lenze to by si musel vediet, ktore zmeny sa deju na zaklade "hromadnosti")

Ano, takze problem ak si len na urovni DB, tak sa moze stat, ze sa moze naraz vykonat viac atomickych zmien na aggregate a Ty sa tazko dozvies, ze to bola "jedna tranzakcia tykajuca sa jedneho aggregatu". Keby si vedel zabezpecit aspon toto, tak mas vyhrate. (napr. pri kazdej zmene v ramci produkt aggregate sa zmeni nejaky time stamp na root tabulke)
Tiez sa da uvazovat o tom, ze budes delegovat aj take veci ako "hromadna zmena" v produktom katalogu ako jeden event a budes interpretovat na strane systemu, ktory je na takyto event subscribenuty ale pokym si len na urovni DB, tak mas problem to implementovat zial.(mozes ich prinutit volat mozno aspon stored procky?)

Vacsie resources mozu byt problem cez Bus, tie by som riesil specificky.(informacie o tom, ze tam ma byt obrazok sa prenesie, ale obrazok pojde cez specificky na resource synchronizaciu prisposobeny mechanizmus)

a.d. SOA - messages/events je skor EDA ako SOA. Ja osobne sa snazim zobrat z oboch pristupov to najlepsie. Samozrejme nie vsade mam moc presadit nieco ine ako old school SOA.

Udi Dahan vola servisom pri messagingu "subor eventov na ktore som subscribenuty, ktore vytvaraju kontrakt mojej sluzby" http://www.infoq.com/presentations/SOA-Business-Autonomous-Components

U mna je to behavior vystaveny von presne ako pri SOA, len neposkytuje ziadne query moznosti(ako to robia bezne WS) a basti len commandy (async messages). Na query sa pozeram rovnako ako Udi, ze si query storages maju budovat jednotlive integrovane systemy na zaklade eventov, na ktore su subscribenute a podla svojich potrieb alebo v odovodnenych pripadoch mozu zdielat systemy spolocny query storage.(cize sa nemusia subscribeovat jednotlive systemy, ani riesit storage, ale je na to jeden autonomny komponent, ktory to riesi za nich a je technologicky postaveny na queryovanie)

a.d. BizTalk - ano podarilo, radovo terabytes rocne. Biztalk bol ale len v pozicii adapterov a vnutorne riesenie frcalo na NServiceBuse, BT tam bol hlavne kolu preklenutiu oldschoolovych ws interfaceov, BT ESB sme nepouzili. My sme mali ale vyhodu, ze celu architekturu vnutorneho prostredia sme mali v rukach.

a.d. parovanie identit - dost velky problem. Do uvahy prichadza nejaky tvoj parovaci storage, kde si budes odpamatavat uz resolvenute relacie. Toto ako problem je len dalsi dosledok toho, ze Tvoje moznosti degradovali na uroven DB a "porad si".

a.d. co je smutne - webove apps idu strasne rychlo dopredu a u nas si firmy neuvedomuju, ze si raz prestanu stacit s nejakym old school web shopom ktory naskaluju (mozno) akurat vertikalne a draho, ze medzicasom stihli preniest zodpovednost za vacsinu "admin" taskov zo shopu na ine systemy a teda cely web admin im je z vacsej casti nanic(ale dodavatel shopu bude tvrdit opak samozrejme a bude sa ho snazit udrzat pri zivote) a ze cely shop sa redukuje na pomerne jednoduchu app logiku a to primarne zobrazovaciu.(comu zodpoveda ina architektura shopu, iny sposob ukladania dat a co sa potom paradne skaluje horizontalne)
Cele to nakoniec stoji na nejakej integracii na hlinenych nohach, ktora ich vide drahsieako by stalo prerobebenie stareho shopu, bude ich limitovat, otravovat...ale odnesie si to integrator.

*** je to ako keby sa po vytlaceni papieroveho katalogu zamestnavali ludia, ktori chodia prelepovat popisky v katalogu v tych, co su este na sklade. Si povies, ze no a co, ved toto je vyhoda IT. No nie je. Skor ako sa katalog vytlacil presiel mnohymi korekciami a bol profesionalny, ludia si uvedomovali zodpovednost za to, co ide von. Aj ked sme pri web shop a moznosti opravy "tlacovych chyba a skriatkov su tam" a perioda aktualizacie informacii moze byt kratsia, stale je tam priestor na profesionalitu a jednoducho nesmiem publikovat, pokym nemam urcitu kvalitu. Nemal by som pracovat tak, ze opublikujem, precitam si na webe...aha, preklep...opravim...a znova pozriem na webe, Ci sa na to pozriem ocami managementu alebo zakaznika...nemal by som :-) Ale toto poznanie Tebe bude prd platne, ak si to neuvedomuje zakaznik :-)

Tomáš Zeman, MCSD.NET, MCPD