Werken met de Azure ServiceBus zal in vele situaties handig blijken. Een van de voornaamste gebruiken is het verminderen van de last op je REST API. Een ander gebruik is voor de afhandeling van operaties die te lang duren om de hele tijd een connectie open te houden tussen je client en API.
Deze informatie kan misschien wat ingewikkeld lijken, maar eigenlijk is hiermee werken relatief eenvoudig. Hieronder volgt verdere uitleg.
Wat is Azure ServiceBus?
De bus is in feite een messaging system, het laat je toe om er berichten op achter te laten en deze later uit te lezen. Dit doe je aan de hand van queues om de berichten ordelijk te kunnen verzenden en ontvangen.
Een eenvoudig voorbeeldje: je hebt een client die een langdurige operatie wil laten uitvoeren maar de connectie niet onnodig lang wil openhouden. De client stuurt zijn request door naar de REST API en kan daarna gewoon verder gaan. Ondertussen zet de REST API een bericht op de ServiceBus. De business code zit aan de andere kant van de queue te luisteren en verwerkt het bericht zodra het binnenkomt.
Tip: het is echter beter om het opwachten van een bericht door een aparte WebJob te laten uitvoeren die dan de business code aanspreekt. Voor kleinere requests is het nog steeds mogelijk om vanuit de API rechtstreeks de business code aan te spreken.
Hoe zorg je voor een bericht naar de client?
Dit staat nog niet helemaal op punt, want in veel gevallen wil een gebruiker een bericht krijgen wanneer een operatie is afgelopen. Bij dit huidige model is dat nog niet het geval. Hier stuiten we ook op een probleem, namelijk de verbinding tussen de client en de REST API is al lang gesloten wanneer de business code het proces heeft afgerond. Maar geen paniek! ServiceBus to the rescue!
Je kan hetzelfde principe toepassen dat je gebruikte om een bericht naar de business code te brengen. Het bericht uiteindelijk terug bij de client krijgen is het volgende obstakel, maar ook hiervoor heeft Microsoft een oplossing. Je kan immers gebruik maken van signalR. Met signalR kan je met je server(API) in contact blijven met je client.
Deze technologie biedt je de optie om berichten te broadcasten naar alle clients die verbonden zijn of d.m.v. een unieke id een bericht te sturen naar één enkele client. Het schema ziet er dan als volgt uit:
Door gebruik te maken van de verschillende queues op de ServiceBus kan er een onderscheid gemaakt worden tussen de berichten die van de API komen en de berichten die naar de API onderweg zijn. In dit geval gebruiken je de REST API ook om de queue uit te lezen. Dit zou ook door een aparte job uitgevoerd kunnen worden maar daar is in dit geval geen nood aan. Bovendien zou dit alles maar complexer maken.
De REST API leest het bericht van de outgoing queue en leest hierin het unieke id van de client die een bericht verwacht en de boodschap die doorgegeven moet worden. Deze boodschap wordt vervolgens doorgestuurd aan de signalR hub die het bericht terug naar de client zendt.
En zo is het plaatje rond. Met Azure ServiceBus is het mogelijk om langdurige operaties uit te voeren zonder je API onnodig te belasten. Met de hulp van signalR blijft je client toch nog op de hoogte wanneer de operatie is afgerond of als er iets mis is gegaan.