K čemu propojení slouží
Data z faktur a skladových karet z Pohody pravidelně tečou do Snowflake přes staging úložiště v cloudu a přistávají v tabulkách, se kterými se dá pracovat přes SQL, bez ručního exportu a bez tabulek, které někdo musí každý týden aktualizovat.
Data ve struktuře, se kterou se dá počítat
Účetní doklady, skladové karty a pohyby se do Snowflake nahrávají přes Snowpipe nebo dávkově přes COPY INTO, ve struktuře připravené pro reporting, ne jako syrový export — sama Pohoda přitom data posílá jen jako XML dokumenty přes mServer, ne přes moderní REST rozhraní s JSON.
Kde se data dál používají
Maržový report, segmentace produktů v Google Ads a skladové predikce pracují se stejným zdrojem, takže čísla v reportech sedí s účetnictvím, ať už nad daty stavíte v Power BI, Tableau nebo jiném BI nástroji napojeném na Snowflake.
Na co si dát pozor
U propojení do Snowflake se počítá s pár specifiky, která se u BigQuery neřeší. Je lepší je znát dopředu než je objevovat až v provozu.
Snowflake nemá on-premises bránu jako Fabric
Pohoda není cloudová služba, data má obvykle na místním počítači nebo firemním serveru. Snowflake na rozdíl od Microsoft Fabric nemá vlastní produkt pro přímé napojení on-premises zdrojů — data se do něj nahrávají přes Snowpipe nebo COPY INTO z externí staging lokality v cloudovém úložišti (S3, ADLS Gen2 nebo GCS). V praxi to znamená, že stejná extrakční pipeline, která už dnes posílá data Pohody do BigQuery, je nasměruje do staging úložiště, odkud si je Snowflake načte — je to stejná extrakční práce, jen s jiným posledním krokem, ne zásadně jiná integrace.
Compute běží, i když nikdo nekouká do reportu
Snowflake účtuje výpočet (virtuální warehouse) zvlášť od úložiště, po sekundách s minimem 60 sekund běhu. Pokud warehouse nemá nastavené auto-suspend, běží a spotřebovává kredity i ve chvíli, kdy s daty nikdo nepracuje. Na rozdíl od BigQuery, kde se platí za jednotlivé dotazy a bez dotazu neběží žádný náklad navíc, je tohle riziko, na které je potřeba myslet už při nastavení.
Číselníky skladových karet
Pokud se kódy produktů v účetnictví a v e-shopu liší, je potřeba mapovací vrstva. Bez ní marže nesedí na produkty v kampaních.
Limity API a více provozoven
Pohoda obvykle omezuje objem a frekvenci dotazů a mServer navíc zpracovává požadavky synchronně, jeden po druhém — synchronizaci je proto potřeba plánovat po dávkách. Pokud jedna skupina vede víc účetních jednotek, data se musí oddělit už při načítání, aby šlo reportovat zvlášť i dohromady.
mServer mluví jen XML, ne REST
Pohoda nemá vlastní REST API s JSON odpověďmi — mServer podporuje výhradně Content-Type text/xml a data přijímá jen metodou POST. Přihlašování jde přes hlavičku STW-Authorization s údaji zakódovanými do Base64, obdobu HTTP Basic Auth.
Jak to Datimo řeší
- 1
Vlastní konektor pro váš systém
Napojení se nastaví podle vaší verze Pohody a datové struktury, přes XML rozhraní mServer, které je součástí instalace programu, stejnou extrakční logikou, jakou používáme pro BigQuery.
- 2
Staging v cloudu a načtení do Snowflake
Data nejdřív přistanou v externí staging lokalitě (S3, ADLS Gen2 nebo GCS) a odtud je do Snowflake načteme přes Snowpipe nebo COPY INTO, podle toho, jak často data potřebujete aktualizovat.
- 3
Pravidelná synchronizace
Data se aktualizují podle domluveného intervalu, ne jednou za měsíc ručním exportem.
- 4
Nastavení auto-suspend a sledování nákladů
Virtuální warehouse nastavíme s auto-suspend, aby neběžel a neúčtoval kredity ve chvíli, kdy ho nikdo nepoužívá, a náklady na compute i úložiště sledujeme průběžně.
- 5
Přístupy přes RBAC
Kdo má k datům ve Snowflake přístup, řešíme přes rolí založený model (RBAC), případně napojený na vaše SSO, ne ad-hoc sdílením.
- 6
Správa napojení v ceně
Technickou správu, údržbu při změnách API i aktivní monitoring hlídáme za vás, v rámci ceny.