Een succesvolle omnichannelstrategie kan loyale klanten opleveren en verloren omzet terugwinnen, maar de overstap is niet eenvoudig. Omnichannelretail is een zeer complex bedrijfsmodel dat nieuwe fysieke processen en technologieën en de juiste IT-infrastructuur vereist om dit alles te ondersteunen.
In deze blog delen we een beproefd stappenplan dat retailers en B2B-bedrijven kunnen gebruiken om een omnichannelstrategie te implementeren. Met deze stappen kun je ervoor zorgen dat je nieuwe omnichannelplan schaalbaar en flexibel is en het grootste rendement oplevert met het laagste risico.
Task coordination in een clustered setup is het proces waarbij taken over meerdere nodes binnen een cluster worden beheerd en aangestuurd. In zo’n omgeving zorgt Task Coordination ervoor dat taken efficiënt worden verdeeld, uitgevoerd en gemonitord. Conflicten, dubbele verwerking en resource contention worden hiermee voorkomen.
Kort gezegd: het zorgt ervoor dat taken efficiënt worden uitgevoerd, zonder conflicten en met correcte synchronisatie tussen verschillende nodes.
WSO2 MI is een integratie-runtime. In een WSO2 MI clustered setup is het essentieel dat taken correct worden gecoördineerd over meerdere MI-instanties. Dit voorkomt redundantie en waarborgt consistentie.
In een clustered setup kan dezelfde scheduled task op meerdere nodes worden gedeployed. Zonder goede coördinatie wordt die taak mogelijk op elke node uitgevoerd. Dat leidt tot dubbele verwerking, met risico op datacorruptie of performanceproblemen.
Binnen WSO2 MI zijn de meeste integratie-artifacts stateless. Die vereisen geen coördinatie in een clustered setup. De volgende artifacts vereisen dat wel wanneer ze op meerdere instanties worden gedeployed:
- Scheduled Tasks
- Message Processors
- Polling Inbound Endpoints
- Event-Based Inbound Endpoints
Eenvoudige Scheduled Task
In dit scenario deploy je een eenvoudige scheduled task die elke 30 seconden wordt uitgevoerd op twee lokale servers/instanties van WSO2 MI.
Hiervoor gebruik ik de nieuwste versie van WSO2 Micro Integrator 4.3. Je kunt één van onze blogs raadplegen [link] voor instructies over het draaien van WSO2-producten op Linux, Windows of Mac.
Zoals aangegeven draai ik twee WSO2 MI 4.3 servers lokaal, elk op een andere poort.
- Eén server draait op de standaardpoort.
- De tweede server draait met een aangepaste port offset.
Voor één van de servers blijft de port offset op de standaardwaarde staan. De andere server krijgt een gewijzigde port offset, zodat beide instanties gelijktijdig lokaal kunnen draaien zonder poortconflicten.
Op de andere server kun je de port offset aanpassen door het bestand deployment.toml te wijzigen in <wso2mi-home>/conf, zoals hieronder weergegeven.
Maak een integratieproject aan en ontwikkel een eenvoudige scheduled task zoals hieronder, inclusief een sequence die wordt geïnjecteerd wanneer de task wordt uitgevoerd.
Dit is een eenvoudige configuratie waarbij de task elke 30 seconden wordt uitgevoerd. Zodra de task wordt gestart, roept deze de sequence aan die is geconfigureerd in de injectTo-parameter.
Deployen en testen vóór configuratie van Task Coordination
Bouw het integratieproject met Maven en kopieer de geëxporteerde carbon application naar de map <wso2mi-home>/repository/deployment/server/carbonapps op beide servers.
Start daarna beide integratieservers.
Zoals hieronder weergegeven, is de task succesvol gedeployed, ingepland en wordt deze uitgevoerd op beide servers.
Ideally, the task should be running only in one server in a clustered setup. If the task runs on both the servers, there will be duplication of messages or processes.
Task Coordination Configuration
Task coordination between nodes in a clustered setup in WSO2 MI is achieved with RDBMS. In simple, for task coordination the nodes should communicate, and this communication happens via a database.
The communication between the nodes in WSO2 MI happens via the WSO2_COORDINATION_DB. The script to create the database is in <wso2mi-home>/dbscripts/<db_type>. To create the database, run the <db_type>_cluster.sql script in <wso2mi-home>/dbscripts/<db_type> (eg: if the DB type is MySQL then run the <wso2mi-home>/dbscripts/mysql/mysql_cluster.sql).
For the communication of WSO2 MI server and the created database add the following snippet to deployment.toml under <wso2mi-home>/conf. I have used MySQL hence the below config is to connect to the created MySQL database.
Voeg de juiste database driver toe aan de map <wso2mi-home>/lib.
Deployen en testen na Task Coordination Configuration
De eenvoudige task is al gedeployed op beide WSO2 MI-servers. Nadat de benodigde configuratie voor task coordination is uitgevoerd, start je beide WSO2 MI-servers opnieuw.
Na het opstarten zie je dat de task op beide servers is gedeployed, maar slechts op één server wordt ingepland en uitgevoerd.
Hoewel de task op beide servers is gedeployed, wordt deze – zoals verwacht – slechts op één server ingepland en uitgevoerd.
Doordat de task maar op één instantie draait, ontstaat er geen duplicatie van berichten.
Naast het voorkomen van duplicatie biedt deze aanpak ook hogere beschikbaarheid en fault tolerance. Dit kun je testen door de server waarop de task actief is uit te schakelen.
Zoals in de bovenstaande afbeelding te zien is, is de server die de task had ingepland uitgeschakeld. De task wordt vervolgens automatisch ingepland op de eerstvolgende beschikbare server.
Dit bevestigt dat de tasks fault tolerant zijn.
Task Resolvers
Een Task Resolver zorgt ervoor dat taken correct worden gecoördineerd over meerdere nodes. De resolver bepaalt welke node een specifieke task uitvoert. Daarmee voorkom je dubbele uitvoering en zorg je voor een efficiënte verdeling van taken binnen het cluster.
Wanneer er tasks zijn gedeployed in WSO2 MI, mag elke task slechts op één node binnen het cluster draaien. De configuratie van de task resolver op de server nodes bepaalt de logica voor het toewijzen van taken aan de verschillende servers.
Default Resolver
Dit is de standaard task resolver van WSO2 MI. Hiervoor is geen extra configuratie nodig.
De default resolver werkt in een active-passive modus. Alle tasks worden toegewezen aan één willekeurige node uit de beschikbare nodes in het cluster.
Wordt de server waarop de tasks draaien onbeschikbaar, dan worden de taken automatisch toegewezen aan een andere node.
Round Robin Resolver
Deze resolver verdeelt de tasks over de nodes in een circulaire volgorde.
Met deze resolver worden taken gelijkmatig verdeeld over de beschikbare nodes in het cluster, in plaats van dat alle taken op één server draaien.
Door taken volgens het round robin-principe te verdelen, realiseer je betere load balancing binnen het cluster.
Voeg hiervoor de volgende configuratie toe aan deployment.toml onder <wso2mi-home>/conf,
Bij de round robin resolver bepaalt de parameter task_server_count hoeveel nodes beschikbaar moeten zijn in het cluster voordat het proces voor task resolving start.
Dit zorgt ervoor dat niet alle tasks op één enkele server worden ingepland zolang het vereiste aantal servers nog niet beschikbaar is. Pas wanneer het opgegeven aantal nodes actief is, worden de taken verdeeld volgens het round robin-principe.
Task Node Resolver
Deze resolver verdeelt de tasks eveneens volgens het round robin-principe, maar dan over een vooraf gedefinieerde set van nodes.
In plaats van taken te verdelen over alle beschikbare nodes in het cluster, worden de tasks alleen toegewezen aan de specifiek geconfigureerde nodes. Zo houd je volledige controle over welke servers verantwoordelijk zijn voor het uitvoeren van bepaalde taken.
Voeg hiervoor de volgende configuratie toe aan deployment.toml onder <wso2mi-home>/conf,
Above is a config in one of the nodes and has the ID node-1. Likewise, all the nodes in the cluster are required to be provided with an ID so that the required set of nodes which should resolve the tasks can be set in the task_nodes parameter. As per the above config, the tasks will be resolved in node-1 and node-2 only.
Additionally, for the other two node resolvers, a node ID was not given to the nodes. If needed, IDs can be provided to other node resolvers too, but not required. If an ID is not provided a random UUID value will be used as the node ID. But for the task node resolver, ID should be provided for nodes so that task_nodes parameter can be filled in with the IDs.
Conclusion
Effective task coordination ensures that a clustered setup operates efficiently, minimizing downtime and maximizing resource utilization. It helps in scaling applications, achieving high availability, and managing complex workloads that span multiple nodes.
Task coordination in WSO2 Micro Integrator is crucial for ensuring that tasks are executed efficiently and without redundancy in a clustered environment. WSO2 MI also gives the flexibility to choose a node resolver based on the requirements.
With the required coordination configuration in WSO2 MI, duplication of messages or duplication of integration mediation are handled efficiently preventing redundant operations. Further, ensures that tasks can be reassigned to other nodes if a failure occurs. This enhances the system’s fault tolerance and ensures continuous operation. Hence this is an essential feature for any large-scale, clustered deployment of WSO2 Micro Integrator.
