Ik ontving onlangs de volgende vraag: “Hoe kunnen we generieke toegang tot data in Snowflake mogelijk maken die we willen blootstellen aan externe partners? We willen dat zij alle velden kunnen filteren, maar we kunnen er ook niet te veel tijd aan besteden”. Ik had geen antwoord klaar en wist dat ik eerst onderzoek zou moeten doen voordat ik zou reageren. En daar kwam de Generieke OData API naar voren.
Wat deed ik eerst, intuïtief?
Ik keek naar de standaard API Development lifecycle voorgesteld door MuleSoft.
Maar toen vroeg ik me af: “Waarom zou ik het volledige API-contract vanaf nul willen schrijven, waarbij ik alle individuele parameters opsom, wetende dat ik het allemaal opnieuw zou moeten doen voor toekomstige databronnen?” Ik geloofde niet dat het schaalbaar zou zijn om het API-contract te moeten schrijven voor elke ‘eenvoudige tabel’ die toegankelijk moest zijn.
Laten we iets anders proberen!
De generieke OData API
Ik had eerder gehoord over MuleSoft’s APIKit voor OData. Ik had ook in het verleden OData API’s geconsumeerd, maar ik had het nooit zelf geïmplementeerd. Wat een geweldige gelegenheid om te experimenteren met iets dat daadwerkelijk nuttig zou kunnen zijn!
Kijkend naar de documentatie leek het proces relatief eenvoudig:
- Beschrijf de data die toegankelijk moet zijn, waarbij u de datatypes voor alle velden verstrekt (een timestamp is een datum tijd, een snelheid is een getal, een beschrijving is een string…).
- Gebruik APIKit voor OData in Anypoint Studio om de basis applicatiestructuur op te zetten.
- Werk uw magie om verbinding te maken met de onderliggende database (Snowflake in dit geval).
- Controleer of alles werkt.
Ik zal u niet lastigvallen met de details over de definitie van de data, maar het is een zeer eenvoudig proces dat gemakkelijk geautomatiseerd kan worden. Zodra de datadefinitie klaar was, kon ik de applicatiestructuur opzetten. Ik verbond alle Dots met enkele Arrows en kreeg mijn verbinding met Snowflake kort daarna werkend.
APIKit @ work
Kijkend naar de gegenereerde flows was het duidelijk dat 95% van het werk al voor mij gedaan was. De APIKit voor OData module voegt een transformer toe die automatisch zoekt naar de verstrekte invoerparameters (de filters en paginering* parameters in dit geval) en schrijft een SQL Select query die u eenvoudig kunt uitvoeren tegen een database.
Het principe is vrij eenvoudig. De ‘Transform to SQL select’ zoekt naar parameters die werden verstrekt met de API-aanroep en transformeert deze parameters naar een SQL query. Die SQL query kan worden uitgevoerd naar de database. De ‘Query Snowflake’ doet precies wat het zegt, en de ‘Serialize entity collection’ transformeert simpelweg de data naar een leesbaar formaat.
Ik ben blij te kunnen zeggen dat er niet veel meer bij komt kijken. Met dit op zijn plaats kon ik OData API-aanroepen uitvoeren naar Snowflake waarbij het meeste werk ging naar het beschrijven van de data. Ik kon nu de data bevragen met elk filter dat ik wilde, zonder elk filter specifiek te hoeven implementeren.
Een voorbeeld. De APIKit module houdt er rekening mee dat de snelheid een getal is en dat we gemakkelijk kunnen filteren op waarden boven of onder een bepaalde waarde, zonder de syntactische notatie en de interpretatie daarvan handmatig te hoeven implementeren om een geldige SQL-statement te krijgen.
/odata4/MY_COLLECTION?$filter=SPEED gt 100&$top=3&$skip=2
Dus…
Hiermee bereikte ik wat ik wilde bereiken: het verstrekken van een lees-API met een minimale hoeveelheid werk. De rest van het werk kan waarschijnlijk gemakkelijk geautomatiseerd worden, gebaseerd op de schema’s van de databron. Dit is een ideaal scenario voor het blootstellen van pure leesoperaties op databronnen die SQL-querying toestaan.
* Maar… (er is altijd iets) een klein probleem, dat gerelateerd was aan de LIMIT en OFFSET parameters die zich anders gedragen in Snowflake (vergeleken met de meeste databases), kwam naar voren tijdens het testen. Ik zal niet te veel in detail gaan, maar voel u vrij om contact op te nemen als u meer wilt weten.
