Optimisation d’Alfresco Search Services: Indexation SOLR, Performance des Requêtes & Réindexation
La recherche est l’un des composants les plus importants d’une implémentation d’entreprise d’Alfresco Content Services (ACS).
À mesure qu’un référentiel Alfresco passe de quelques milliers à plusieurs millions de documents, les administrateurs peuvent constater des recherches plus lentes, un retard croissant de l’indexation, une consommation importante des ressources SOLR, une disponibilité tardive du contenu en recherche plein texte ou encore des différences entre les données du Repository et les résultats de recherche.
C’est ici que l’optimisation d’Alfresco Search Services devient essentielle.
Alfresco Search Services s’appuie sur Apache Solr pour fournir des fonctionnalités de recherche sur le contenu, les métadonnées, les chemins et les permissions du Repository.
Cependant, obtenir de bonnes performances de manière durable nécessite davantage qu’une simple installation de SOLR avec sa configuration par défaut.
Dans ce guide, nous allons étudier :
L’architecture d’indexation SOLR d’Alfresco
Le fonctionnement des SOLR Trackers
L’Indexing Lag
L’optimisation des requêtes
L’indexation Full-Text
Les performances JVM et mémoire
Les performances disque et I/O
Le Sharding
L’impact des ACL
Les stratégies de réindexation
La réindexation des grands repositories
La validation des index
Le troubleshooting
Le monitoring de production
Les bonnes pratiques d’optimisation
🎥 Vidéo recommandée : Architecture Alfresco expliquée
Pour mieux comprendre comment les différents composants Alfresco fonctionnent ensemble avant d’optimiser Search Services, regardez ce guide complet :
👉 Alfresco Architecture Explained | Repository, Database, Search & Transform Services
Cette vidéo présente les principaux composants de l’architecture Alfresco, notamment le Repository, la base de données, Search Services, le Content Store et les Transformation Services, ainsi que leurs interactions dans un environnement d’entreprise.
Elle complète particulièrement bien cet article, car les performances de SOLR Indexing et Reindexing ne dépendent pas uniquement de Search Services. Les performances du Repository, de la base de données, du stockage et des Transformation Services peuvent également influencer directement l’indexation et les recherches.
Qu’est-ce qu’Alfresco Search Services?
Alfresco Search Services fournit la couche de recherche et d’indexation utilisée avec Alfresco Content Services.
Au lieu d’exécuter chaque recherche directement sur la base de données du Repository, Alfresco utilise un index de recherche dédié.
Conceptuellement :
Utilisateur / Application
|
v
Alfresco Repository
|
v
Search Services
|
v
Apache SOLR Index
|
v
Résultats de recherche
Cet index permet d’effectuer efficacement des recherches sur de grands repositories selon différents critères :
Nom du document
Métadonnées
Propriétés personnalisées
Content Types
Aspects
Chemins des dossiers
Contenu Full-Text
Dates
Utilisateurs et permissions
Le Repository reste la source de vérité pour le contenu et les métadonnées, tandis que SOLR maintient une représentation indexée permettant d’effectuer les recherches.
Comment fonctionne l’indexation SOLR dans Alfresco ?
Il est essentiel de comprendre le pipeline d’indexation avant de commencer l’optimisation.
Lorsqu’un contenu est créé ou modifié dans Alfresco, des transactions sont générées dans le Repository.
Search Services utilise différents trackers pour identifier ces changements et mettre à jour l’index SOLR.
Le flux simplifié est le suivant :
Document créé / modifié
|
v
Alfresco Repository
|
v
Repository Transaction
|
v
SOLR Trackers
|
v
Metadata / ACL / Content Processing
|
v
SOLR Index
|
v
Document disponible en recherche
Ce processus est asynchrone.
Un document peut donc exister correctement dans Alfresco Repository avant de devenir disponible dans les résultats de recherche SOLR.
Comprendre les SOLR Trackers dans Alfresco
Les trackers sont responsables de la synchronisation entre le Repository Alfresco et l’index SOLR.
Plusieurs domaines sont particulièrement importants.
Metadata Tracking
Le Metadata Tracking détecte les transactions du Repository et indexe les métadonnées des nodes.
Par exemple :
cm:name
cm:title
cm:description
cm:creator
cm:created
cm:modified
Les propriétés des modèles personnalisés peuvent également être indexées selon leur configuration.
ACL Tracking
Les résultats de recherche Alfresco doivent respecter les permissions du Repository.
SOLR doit donc également suivre les informations liées aux ACL — Access Control Lists.
Cela permet de garantir qu’un utilisateur ne reçoit dans ses résultats de recherche que les documents auxquels il est autorisé à accéder.
Content Tracking
Pour les documents configurés pour la recherche Full-Text, le contenu textuel doit être extrait des fichiers binaires.
Par exemple :
PDF
Microsoft Word
Text
PowerPoint
Excel
Le texte extrait peut ensuite être ajouté à l’index de recherche.
Model Tracking
Les Content Models personnalisés influencent la façon dont les propriétés sont indexées.
Les changements de modèles doivent donc être pris en compte lors du troubleshooting des problèmes d’indexation.
Qu’est-ce que l’Indexing Lag dans Alfresco ?
Lorsque les utilisateurs signalent que certains documents sont « absents de la recherche », l’un des premiers éléments à vérifier est l’Indexing Lag, ou retard d’indexation.
Prenons cet exemple :
Dernière transaction Repository : 9 500 000
Transaction indexée SOLR : 9 498 000
SOLR a environ 2 000 transactions de retard.
Une petite différence temporaire peut être normale.
En revanche, une différence qui augmente continuellement doit être analysée.
Repository
TX 100
TX 101
TX 102
TX 103
TX 104
TX 105
SOLR
TX 100
TX 101
TX 102
Lag = 3 transactions
Si le Repository crée continuellement des transactions plus rapidement que SOLR ne peut les traiter, le backlog continue d’augmenter.
Causes courantes d’une indexation SOLR lente
Plusieurs facteurs peuvent provoquer un retard d’indexation.
1. CPU insuffisant
L’indexation, le traitement du contenu et l’exécution des requêtes consomment des ressources CPU.
Un serveur Search fortement chargé peut ne plus être capable de traiter suffisamment rapidement les nouvelles transactions.
2. Mémoire JVM insuffisante
Une mémoire Heap insuffisante peut provoquer :
Garbage Collection fréquente
Longues pauses GC
OutOfMemoryErrorFaible débit d’indexation
Dégradation des performances de recherche
Mais attribuer une quantité excessive de RAM à la JVM n’est pas automatiquement une bonne solution.
Le système d’exploitation a également besoin de mémoire, notamment pour le filesystem cache.
3. Stockage lent
Les moteurs de recherche dépendent fortement des performances disque.
Un stockage lent peut affecter :
Les écritures d’index
Les opérations sur les segments
Les lectures
Le démarrage
La réindexation
La récupération
Pour les index actifs de production, un stockage rapide de type SSD est généralement préférable à un stockage présentant une latence élevée.
4. Bottleneck des transformations
L’indexation Full-Text nécessite l’extraction du texte des fichiers binaires.
Une grande quantité de :
PDF
DOCX
PPTX
XLSX
Documents volumineux
peut générer une charge importante sur les services de transformation.
Le problème ne se situe donc pas nécessairement dans SOLR.
5. Repository ou base de données
Pendant l’indexation, Search Services doit obtenir des informations auprès du Repository.
Un Repository ou une base de données lente peut donc limiter le débit d’indexation.
6. Latence réseau
Dans une architecture distribuée, Alfresco Repository et Search Services peuvent être installés sur des serveurs différents.
Une latence réseau élevée peut augmenter les temps d’indexation et le risque de timeouts.
Full-Text Indexing et performances des transformations
L’indexation des métadonnées et l’indexation du contenu sont deux opérations différentes.
Document
|
+---- Metadata
|
+---- Binary Content
|
v
Text Extraction
|
v
Full-Text Index
Un document peut donc apparaître dans une recherche basée sur ses métadonnées alors que son contenu Full-Text n’est pas encore disponible.
Cette distinction est très utile pour le troubleshooting.
Si :
cm:name:"contract.pdf"
retrouve correctement le document, mais qu’une recherche portant sur un mot présent à l’intérieur du PDF ne retourne aucun résultat, il faut analyser le processus de transformation et d’indexation Full-Text.
Optimiser les performances des requêtes Alfresco
Une indexation rapide ne garantit pas automatiquement des requêtes rapides.
Les performances dépendent notamment de :
La structure des requêtes
Les champs indexés
Le nombre de résultats
Le filtrage des permissions
Les facettes
Le tri
Les wildcards
La taille du Repository
Le nombre de shards
Les performances disque
La mémoire disponible
Éviter les requêtes Wildcard coûteuses
Les recherches contenant des wildcards très larges peuvent être coûteuses.
Par exemple :
*invoice*
est généralement plus coûteux qu’une recherche ciblée sur un champ correctement indexé.
Lorsque cela est possible, préférez une requête précise :
cm:name:"invoice-2026.pdf"
ou utilisez une propriété métier appropriée.
Rechercher sur des champs spécifiques
Les recherches générales sur de nombreux champs nécessitent davantage de traitement.
Si une application connaît précisément la propriété métier recherchée, utilisez cette propriété.
Par exemple :
acme:invoiceNumber:"INV-10001"
est plus ciblé qu’une recherche Full-Text générique sur :
INV-10001
Un Content Model Alfresco correctement conçu contribue donc directement à une meilleure stratégie de recherche.
Utiliser la pagination
Une application ne devrait pas demander plusieurs milliers de résultats lorsque l’utilisateur n’a besoin que des premiers résultats.
Utilisez la pagination :
Page 1 : 0 - 24
Page 2 : 25 - 49
Page 3 : 50 - 74
Cela permet de réduire :
Le traitement du moteur de recherche
Le volume réseau
Le traitement Repository
L’utilisation mémoire
Le temps de rendu côté client
Comprendre le coût du Sorting
Le tri de très grands ensembles de résultats peut être coûteux.
Par exemple :
Recherche sur plusieurs millions de documents
+
Tri sur une propriété
+
Filtrage des permissions
+
Faceting
demande beaucoup plus de ressources qu’une recherche ciblée.
Ne demandez que les tris et facettes réellement nécessaires au besoin métier.
ACL et performances de recherche
Les permissions constituent un élément fondamental de la recherche Alfresco.
Un utilisateur ne doit jamais recevoir un document qu’il n’est pas autorisé à consulter.
Résultats correspondant à la requête
|
v
Candidats SOLR
|
v
Filtrage ACL
|
v
Résultats autorisés
Un Repository contenant un grand nombre d’ACL ou une structure de permissions complexe peut donc nécessiter une attention particulière.
Lorsqu’une requête est lente, n’analysez pas uniquement les critères de recherche.
Examinez également la complexité du modèle de permissions.
Optimisation de la mémoire JVM
La JVM doit être dimensionnée selon la taille réelle du Repository et la charge du système.
Surveillez notamment :
Heap utilization
GC frequency
GC pause duration
CPU
Query latency
Indexing throughput
OS memory
Le serveur Search a besoin de mémoire pour la JVM, mais le système d’exploitation a également besoin de RAM pour le filesystem cache.
Par conséquent :
N’attribuez pas toute la RAM du serveur à la JVM SOLR.
Les performances disque sont critiques
Les index de recherche effectuent de nombreuses opérations de lecture et d’écriture.
Pendant le fonctionnement normal :
Index writes
Segment reads
Segment merges
Transaction processing
Query reads
Cache operations
Pendant une réindexation, l’activité disque devient encore plus importante.
Surveillez :
Disk latency
IOPS
Disk utilization
Queue depth
Available capacity
Un serveur équipé de CPU puissants mais d’un stockage lent peut malgré tout fournir de mauvaises performances SOLR.
Taille de l’index et Capacity Planning
Ne dimensionnez pas le stockage SOLR uniquement en fonction de la taille du Content Store.
Par exemple :
Content Store = 5 TB
ne signifie pas :
SOLR Index = 5 TB
La taille de l’index dépend notamment :
Du nombre de nodes
Du volume de métadonnées
Des propriétés indexées
Du texte extrait
Des ACL
De la configuration
Des habitudes d’utilisation
Le Capacity Planning doit donc être basé sur des tests représentatifs et sur l’évolution réellement observée de l’index.
Conservez également suffisamment d’espace libre pour la croissance et les opérations de maintenance.
Sharding pour les grands repositories Alfresco
Lorsque le Repository devient très volumineux, un index unique peut devenir difficile à faire évoluer.
Le Sharding divise l’index en plusieurs parties.
Alfresco Repository
|
v
Search Services
|
+--------------+--------------+
| | |
v v v
Shard 1 Shard 2 Shard 3
| | |
+--------------+--------------+
|
v
Search Results
Le Sharding peut aider à distribuer les charges d’indexation et de recherche.
Cependant, davantage de shards signifie aussi :
Plus d’infrastructure
Plus de JVM
Plus de monitoring
Plus de complexité opérationnelle
Des requêtes distribuées
Le choix doit donc dépendre de la taille du Repository, de sa croissance, des requêtes et de l’infrastructure disponible.
Quand une réindexation Alfresco est-elle nécessaire ?
Une réindexation complète reconstruit l’index de recherche à partir des informations du Repository.
Elle peut être envisagée lorsque :
Une corruption de l’index est suspectée
Les résultats restent incohérents
Un upgrade Search l’exige explicitement
L’architecture des index change
L’index existant ne peut pas être réutilisé
Une modification importante exige une reconstruction
Le troubleshooting confirme que la réparation n’est pas suffisante
Une réindexation complète ne doit pas être la première solution à chaque problème de recherche.
Pour un grand Repository, elle peut prendre beaucoup de temps et générer une charge importante.
Un upgrade ne signifie pas toujours une réindexation
Ce point est particulièrement important.
La nécessité d’une réindexation dépend des versions source et cible et de la compatibilité des index.
Ne supposez jamais :
Search Upgrade = toujours Reindex
ni :
Search Upgrade = jamais Reindex
Consultez la documentation officielle correspondant exactement aux versions utilisées.
Réindexer un grand Repository Alfresco
Une approche simpliste serait :
Arrêter SOLR
Supprimer l’index
Redémarrer SOLR
Attendre la reconstruction
Dans un environnement de production volumineux, cette approche peut provoquer une interruption de recherche inacceptable.
Lorsqu’elle est supportée par l’architecture et que l’infrastructure le permet, une approche d’entreprise plus sûre consiste à reconstruire et valider un nouvel environnement de recherche séparément.
Existing Production Search
|
| reste disponible
|
Alfresco Repository
|
+------> New Search Environment
|
v
Reindex
|
v
Validation
|
v
Cutover
Cela permet de réduire considérablement l’indisponibilité de la fonction de recherche.
La réindexation peut affecter la base de données
Une erreur fréquente consiste à considérer la réindexation comme une opération exclusivement SOLR.
Lors d’une réindexation complète, le moteur Search doit récupérer des informations depuis le Repository.
Cela peut augmenter l’activité de lecture sur la base de données Alfresco.
Surveillez donc :
Database CPU
Connection Pool
Query Latency
Database I/O
Repository CPU
Repository JVM
SOLR CPU
SOLR JVM
Network
Transformation Services
Pour les environnements importants, effectuez des tests de performance représentatifs avant la réindexation en production.
Impact sur les Transformation Services
Lorsque le Full-Text doit être reconstruit, les services de transformation peuvent également devenir un bottleneck.
Repository
|
v
Document Binary
|
v
Transform Service
|
v
Extracted Text
|
v
SOLR
Des millions de documents peuvent générer une charge très importante.
Cela concerne particulièrement les repositories contenant de nombreux PDF, documents Office et autres formats nécessitant une extraction de texte.
Réindexation : plus rapide n’est pas toujours meilleur
Augmenter fortement la concurrence n’améliore pas nécessairement la durée globale.
More Threads
↓
More Repository Requests
↓
More Database Queries
↓
More Transform Requests
↓
More SOLR Writes
Au-delà d’un certain point, augmenter la charge peut ralentir l’ensemble du système.
Il faut donc optimiser le pipeline complet, et pas seulement un paramètre SOLR.
Valider l’index après la réindexation
Ne considérez jamais une réindexation comme réussie uniquement parce que le traitement semble terminé.
Effectuez plusieurs validations.
Repository vs Search
Vérifiez que les documents attendus sont retrouvés.
Metadata Queries
Testez :
cm:name
cm:title
Custom Properties
Content Types
Aspects
Full-Text Search
Recherchez des mots connus présents dans le contenu de documents représentatifs.
Permissions
Testez avec plusieurs utilisateurs et groupes.
Les documents non autorisés ne doivent jamais apparaître.
Path Queries
Validez les recherches importantes liées aux sites et dossiers.
Business Queries
Testez les requêtes réellement utilisées par les applications métier.
Performance
Mesurez les temps de réponse et comparez-les avec votre baseline.
Monitoring d’Alfresco Search Services
L’infrastructure Search de production doit être surveillée en permanence.
Indexation
Indexing Lag
Repository Transaction Progress
ACL Tracking
Content Indexing Failures
Tracker Errors
JVM
Heap Utilization
GC Frequency
GC Pauses
Thread Count
OutOfMemory Errors
Serveur
CPU
Memory
Disk Usage
Disk Latency
IOPS
Network
Recherche
Query Response Time
Slow Queries
Query Volume
Error Rate
Timeouts
Capacity
Index Growth
Disk Free Space
Repository Growth
Document Ingestion Rate
Troubleshooting : le document existe mais n’apparaît pas dans Search
Utilisez une démarche structurée.
Étape 1 — Confirmer l’existence du document
Vérifiez que le node existe dans Alfresco Repository.
Étape 2 — Identifier le type de recherche
Le problème concerne-t-il :
Metadata?
Full Text?
Path?
Custom Property?
Étape 3 — Vérifier l’Indexing Lag
Déterminez si SOLR est synchronisé avec les transactions du Repository.
Étape 4 — Vérifier les Trackers
Analysez les logs Search Services pour identifier les erreurs et timeouts.
Étape 5 — Tester les métadonnées
Si les métadonnées fonctionnent mais pas le Full-Text, analysez la transformation et le Content Indexing.
Étape 6 — Vérifier le Custom Model
Confirmez que les propriétés concernées sont correctement configurées pour l’indexation.
Étape 7 — Vérifier les permissions
Assurez-vous que l’utilisateur est autorisé à voir le document.
Étape 8 — Vérifier l’infrastructure
Analysez CPU, JVM Heap, disque, Repository, base de données et réseau.
Une fois la cause identifiée, décidez si une réparation ou une réindexation est réellement nécessaire.
Erreurs fréquentes d’optimisation Alfresco Search
Erreur 1 : réindexer pour chaque problème
Une réindexation peut masquer la véritable cause.
Erreur 2 : donner toute la RAM à la JVM
Le système d’exploitation a également besoin de mémoire.
Erreur 3 : ignorer les performances disque
SOLR dépend fortement des I/O.
Erreur 4 : ignorer la base de données pendant la réindexation
La reconstruction peut générer une charge importante sur Repository et Database.
Erreur 5 : utiliser des requêtes trop larges
Les requêtes coûteuses réduisent la scalabilité.
Erreur 6 : retourner trop de résultats
Utilisez la pagination.
Erreur 7 : ignorer les ACL
Les permissions peuvent avoir un impact significatif sur les performances.
Erreur 8 : supposer que chaque upgrade nécessite un Reindex
Vérifiez toujours la documentation correspondant aux versions.
Erreur 9 : supprimer l’index de production sans stratégie de récupération
Définissez toujours un plan de rollback.
Erreur 10 : ne tester que les requêtes techniques
Validez également les recherches réellement utilisées par les utilisateurs.
Checklist d’optimisation pour la production
✓ Indexing Lag surveillé
✓ Query Response Time mesuré
✓ Slow Queries identifiées
✓ JVM Heap surveillée
✓ Garbage Collection analysée
✓ RAM disponible pour OS Cache
✓ Stockage performant
✓ Croissance disque surveillée
✓ Charge Database surveillée
✓ Transformation Capacity surveillée
✓ Complexité ACL comprise
✓ Requêtes ciblées sur les bons champs
✓ Pagination implémentée
✓ Full-Text Indexing validé
✓ Custom Models vérifiés
✓ Reindex Strategy documentée
✓ Backup / Recovery documentés
✓ Validation post-Reindex définie
✓ Performance Baseline établie
Questions fréquentes — FAQ
Qu’est-ce qu’Alfresco Search Services ?
Alfresco Search Services est le sous-système de recherche et d’indexation basé sur SOLR utilisé avec Alfresco Content Services pour fournir notamment la recherche par métadonnées, Full-Text, chemins et permissions.
Pourquoi un document Alfresco n’apparaît-il pas dans la recherche ?
Les causes possibles incluent l’Indexing Lag, des erreurs de trackers, un problème de transformation, une configuration du Custom Model, les permissions, un problème d’infrastructure ou une incohérence de l’index.
Pourquoi l’indexation Alfresco SOLR est-elle lente ?
Les causes courantes comprennent un manque de CPU ou de mémoire, un stockage lent, des bottlenecks Repository/Database, une charge importante de transformation ou une infrastructure insuffisante.
Faut-il réindexer après chaque upgrade Alfresco ?
Non. Cela dépend du chemin d’upgrade de Search Services et de la compatibilité des index. Vérifiez toujours les exigences des versions source et cible.
Une réindexation peut-elle affecter la base de données ?
Oui. La reconstruction nécessite la récupération d’informations du Repository et peut augmenter significativement l’activité de lecture.
Le Full-Text Indexing utilise-t-il les services de transformation ?
Oui. Pour les formats binaires pris en charge, le texte doit être extrait afin de pouvoir être indexé et recherché.
Peut-on améliorer les performances SOLR ?
Oui. L’optimisation peut concerner les requêtes, la JVM, le stockage, l’OS cache, l’infrastructure, le Sharding lorsque nécessaire, les facettes, les tris et les volumes de résultats.
Qu’est-ce que l’Indexing Lag ?
C’est le retard entre les modifications enregistrées dans Alfresco Repository et leur traitement par le système de recherche.
Dois-je supprimer l’index SOLR lorsque les résultats sont incorrects ?
Pas immédiatement. Analysez d’abord l’Indexing Lag, les trackers, les transformations, les permissions, les Content Models et l’infrastructure.
Conclusion
L’optimisation d’Alfresco Search Services ne dépend pas d’un seul paramètre SOLR.
La performance globale résulte de toute l’architecture :
Repository
+
Database
+
Network
+
Transformation
+
SOLR Trackers
+
JVM
+
Storage
+
Query Design
+
ACL Model
=
Search Performance
Pour les petits repositories, une configuration standard peut être suffisante.
À mesure que le volume augmente, SOLR Indexing, Query Performance, Indexing Lag, JVM, Disk I/O, ACL et Reindexing Strategy deviennent beaucoup plus importants.
Une architecture Search d’entreprise doit donc poursuivre trois objectifs :
Maintenir l’index synchronisé avec le Repository.
Maintenir des requêtes efficaces et prévisibles.
Rendre la réindexation contrôlée, validable et récupérable.
L’objectif n’est pas simplement de rendre SOLR plus rapide.
L’objectif est de fournir une recherche d’entreprise fiable, scalable, performante et respectueuse des permissions dans Alfresco Content Services.
Articles recommandés
Alfresco Architecture Explained
Découvrez l’architecture Alfresco : Repository, Share, Database, Search Services, Content Store et Transformation Services.
Alfresco REST API Explained
Découvrez comment les applications externes et les services Spring Boot peuvent s’intégrer avec Alfresco Content Services via les REST APIs.
Alfresco Enterprise Upgrade & Migration
Découvrez les considérations liées à l’architecture, la compatibilité, les personnalisations, la base de données, le Content Store et Search lors d’un upgrade Alfresco Enterprise.
Event-Driven Microservices avec Kafka & Spring Boot
Découvrez comment Apache Kafka et Spring Boot permettent de construire des intégrations d’entreprise asynchrones, scalables et Event-Driven.
Spring Boot Microservices Architecture Explained
Découvrez les Service Boundaries, les communications interservices, la scalabilité et les principaux composants d’une architecture Spring Boot Microservices.
Références officielles
Pour les paramètres de configuration, la compatibilité, les procédures d’upgrade et les décisions liées à la réindexation, vérifiez toujours la documentation officielle correspondant exactement aux versions Alfresco Content Services et Alfresco Search Services déployées dans votre environnement.
📢 Besoin d’aide pour Java, workflows ou backend?
J’aide les équipes à concevoir des applications scalables, performantes et prêtes pour la production.
Services:
- Développement Java & Spring Boot
- Implémentation workflows (Camunda, Flowable – BPMN, DMN)
- Intégrations API & microservices
- ECM & gestion documentaire (Alfresco)
- Optimisation performance & résolution incidents
🔗 https://shikhanirankari.blogspot.com/p/professional-services.html
📩 Email: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 https://realtechnologiesindia.com
✔ Disponible pour consultation rapide
✔ Réponse sous 24 heures
🎥 Learn IT with Shikha on YouTube
Prefer learning through videos? Watch practical tutorials on Kafka, Camunda, Alfresco, Java, Spring Boot, Microservices and Enterprise Architecture.▶ Subscribe to Learn IT with Shikha on YouTube
Comments
Post a Comment