Tillgängliggöra Sitoo-data för bredare konsumtion och analys i BigQuery

Sitoo är ett vanligt kassasystem inom detaljhandel. Sitoo erbjuder grundläggande analys i sitt online-gränssnitt, men ofta är det av intresse att kunna gå djupare än så. Kanske vill man bryta analysen mer fritt, integrera datat med andra datakällor, eller tillgängliggöra det i sitt datalager.

I detta blogginlägg kommer vi beskriva hur man på ett enkelt, skalbart och ekonomiskt sätt tar emot, bearbetar och tillgängliggör Sitoo-data i Googles analysdatabas BigQuery.

Eventbaserad lösning för att läsa in Sitoo-data till BigQuery.

Metod – Eventdriven arkitektur

Det bästa sättet att integrera med Sitoo är att prenumerera på event. Görs detta skickar Sitoo event för varje förändring i databasen med information om vad som hänt. Med detta kan konsumerade tjänster kommunicera med API:t och bara uppdatera den data där förändringen skett. Därigenom säkerställs minimal konsumtion, vilket driver låga kostnader, samtidigt som informationen i princip hämtas i realtid.

I ett eventdrivet flöde är det viktigt att respektive komponent hålls frikopplad och blir därmed skalbar. Skulle en störning inträffa hos Sitoo kan det ske att ett större antal events skickas samtidigt, vilket lösningen måste kunna hantera.

Komponenter

Cloud Functions är en serverlös plattform som möjliggör skalbar exekvering av funktioner. Din funktion kan skrivas i till exempel Node JS, Python, Java eller GO. En Cloud Function kan triggas antingen av ett externt anrop, en eventhanterare, eller någon annan tjänst inom GCP. Den funktion som byggs inuti Cloud Function kan kommunicera med övriga komponenter inom GCP-miljön, och även extern.

PubSub är en eventhanterare vilket innebär att den kan ta emot och skicka events mellan olika komponenter. Den används för att frikoppla de olika komponenterna, och möjliggör därigenom dels att respektive komponent är mer tydlig i sin funktion, dels att man kan skala komponenterna mer exakt efter belastning. Pubsub är uppdelad i topics, eller ämnen. Aktörer som skickar meddelanden definierar till vilket ämne meddelandet ska skickas, och konsumenterna anger också på vilket ämne de vill få meddelanden ifrån.

Cloud Storage är en arbetsyta för att spara ostrukturerad data, det vill säga till exempel text- och csv-filer.

Förklaring av flöde

  1. Ett event skickas från Sitoo till en endpoint vi har byggt i Cloud Function. Denna Cloud Function är mycket enkel, den identifierar vilket typ av event som skett, och skickar eventet vidare till matchande ämne i PubSub.
  2. PubSub skickar i sin tur meddelandet till en annan Cloud Function.
  3. Ett lager av olika Cloud Functions hanterar respektive meddelandetyp. Är det till exempel en order som inkommit vill vi uppdatera ordertabeller, för ett lagerevent uppdaterar vi lagertabeller, och så vidare. I slutet av denna funktion skickas datat till matchande BQ-tabell.
  4. Om något går fel i hanteringen av eventet sparas en logg ner till en csv-filer i Cloud Storage.

Att tänka på

  • Lösningen ovan behöver kompletteras med en batchladdning som laddar historiken för respektive tabell. Ett smidigt sätt är att skapa en Cloud Function som imiterar Sitoo-event, och skickar events de historiska rader som saknas.
  • Då strukturen är modulär tillåter den successivt tilläggande av tabeller och ökande av komplexiteten. Börja med att prenumerera på en eventtyp och etablera hela kedjan. Därefter utökar du strukturen efterhand.
  • Säkerställ att din funktion som tar emot externa events är säkrad mot annan trafik än just den som Sitoo skickar ut.
  • Skriv inte ut känslig information i ren kod. Använd i stället antingen Cloud Functions inbyggda lösenordshantering, eller GCP:s modul för detta, Secrets.
  • En central best-practice i GCP är att minimera datatransformationen innan data når BigQuery. Detta görs för att förenkla genomströmningen och minimera risken för fel på vägen. I stället görs transformeringen i BigQuery, enligt ELT-logik.
  • Både Sitoo och PubSub kan ge upphov till event-dubbletter. Därför är det viktigt att ta med sig viktiga tidsstämplar till BQ, genom vilka man säkerställer att man enbart får den senaste raden vid dubbletter.

Självfallet går ovan att lösa på flera olika sätt, beroende på behov. Det går att använda andra GCP-komponenter, och även att batchladda data i stället för att strömma. Behöver du stöd i hur du skall gå till väga – tveka inte att kontakta oss!

Dela inlägget
LinkedIn