Pour un développeur IBM ACE, les questions d'entretien changent selon l'âge du parc. Beaucoup de missions françaises portent encore sur IBM Integration Bus 10, dont le support standard est terminé, ou sur sa migration vers App Connect Enterprise 12 et 13. Les offres demandent ACE, de l'ESQL, parfois Java, et citent IBM MQ comme socle ou comme un plus. Les flux tournent soit sur un nœud d'intégration classique, soit en conteneurs sur OpenShift.
Le CV ne suffit pas à distinguer un développeur d'un exploitant. Quelqu'un qui a surtout redémarré des flux et purgé des files connaît les commandes mqsi et MQ Explorer, sans avoir écrit de traitement d'erreur. Le niveau réel s'entend sur le seuil de remise d'une file, une boucle ESQL qui passe par des références, un BAR identique de la recette à la production.
Demandez aussi sur quelle version la personne a livré son dernier flux. Les policies ont remplacé les configurable services avec ACE 11, et les serveurs d'intégration indépendants ont changé le déploiement. Un profil resté sur IIB devra se mettre à jour. Le PDF contient 30 questions, un cas de 20 minutes et une grille de 1 à 4.
Les briques IBM d'un poste ACE et MQ
IBM App Connect Enterprise (ACE)
Le moteur d'intégration d'IBM, successeur d'IBM Integration Bus. Les versions 12 et 13 sont celles des missions actuelles. Il exécute des flux de messages qui reçoivent, transforment et routent des données entre applications, en MQ, en HTTP, en fichiers ou vers des bases.
IBM Integration Bus (IIB)
Le nom du produit jusqu'à la version 10, et WebSphere Message Broker avant lui. Beaucoup de flux en production ont été écrits sur IIB. Sur un CV, IIB seul signale un profil qui devra apprendre les policies, les serveurs indépendants et le déploiement en conteneurs.
ESQL
Le langage maison des nœuds Compute, proche du SQL, qui manipule l'arbre du message. Il reste le langage le plus courant dans les équipes ACE. Un développeur confirmé l'écrit avec des références plutôt qu'avec des index, et sait propager plusieurs messages depuis un même nœud.
IBM MQ
La messagerie qui transporte les messages entre applications, avec des files, des gestionnaires de files et des canaux entre serveurs. Le développeur n'en est pas l'administrateur, mais il doit comprendre la persistance, la demande-réponse, la file de remise et la file des messages non distribués. La version 9.4 est la version longue durée actuelle.
Parseurs et modèles DFDL
ACE lit chaque format avec un parseur : XMLNSC pour le XML, JSON, BLOB pour les données brutes, DFDL pour les fichiers plats et les formats binaires. DFDL a pris la place de l'ancien MRM pour décrire un fichier à positions fixes ou un enregistrement mainframe.
Toolkit, BAR et policies
Le Toolkit est l'environnement de développement, sous Eclipse. Les flux sont livrés dans des fichiers BAR. Depuis ACE 11, les paramètres d'environnement (connexions MQ, HTTP, JDBC) vivent dans des policies, ce qui permet de déployer le même BAR partout.
IBM DataPower Gateway
Une passerelle de sécurité placée devant les flux : TLS, certificats, validation des messages, limitation de débit. On la trouve chez les employeurs qui ont un parc IBM ancien. Le développeur ACE doit savoir ce qu'elle fait, sans y mettre de logique métier.
OpenShift et opérateur App Connect
Les nouvelles installations tournent souvent en conteneurs sur Red Hat OpenShift, dans le Cloud Pak for Integration ou avec l'opérateur IBM App Connect. La configuration passe alors par des ressources Kubernetes, et la question du gestionnaire de files local se pose à chaque migration.
Le développeur IBM ACE et MQ travaille dans une équipe d'intégration qui sert de nombreuses applications. Une partie du poste consiste à écrire de nouveaux flux, une autre à maintenir des flux anciens, souvent écrits sur IIB par d'autres. Les projets de migration vers ACE 12 ou 13, puis vers les conteneurs, occupent une bonne partie des missions actuelles. L'administration de MQ revient en général à une autre équipe, mais le développeur doit savoir lire l'état d'une file ou d'un canal pour diagnostiquer un flux. Java est souvent demandé en complément de l'ESQL.
Les six sujets à couvrir avec un développeur ACE
- Programmation ESQL et arbre de messages
- Conception de flux et choix des nœuds
- Files, canaux et persistance IBM MQ
- Transactions, gestion d'erreurs et rejeu
- Déploiement, configuration et supervision
- Migration IIB vers ACE et conteneurs
Cinq questions sur les flux ACE et les files MQ
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un message fait échouer le nœud Compute d'un flux qui commence par un MQInput. Le terminal Catch n'est pas câblé. Que devient le message ?
Une bonne réponseLa transaction est annulée et le message revient sur la file d'entrée, avec un compteur de remises (BackoutCount) incrémenté. Le flux le relit. Quand le compteur dépasse le seuil de la file (BOTHRESH), le nœud MQInput l'envoie sur son terminal Failure. Si ce terminal n'est pas câblé, le message part dans la file de remise (BOQNAME), à défaut dans la file des messages non distribués du gestionnaire. Si aucune n'existe, le flux boucle sur le même message et bloque la file.
Signal d'alerte« Le message est perdu » ou « il part en erreur dans les logs ». Ne pas connaître le seuil de remise, ou croire qu'un message en échec est retiré de la file dès la première erreur.
Question 2 · confirmé
Dans une boucle ESQL sur 10 000 lignes de commande, quelqu'un a écrit InputRoot.XMLNSC.Commande.Ligne[i]. Pourquoi le traitement devient-il très lent ?
Une bonne réponseL'accès par index repart du début de l'arbre à chaque tour : la boucle parcourt la liste encore et encore, et le temps croît avec le carré du nombre de lignes. La correction passe par une variable REFERENCE posée sur la première ligne, puis MOVE ... NEXTSIBLING jusqu'à la fin, ou une boucle FOR sur la référence. Un bon profil évite aussi d'appeler CARDINALITY à chaque tour et laisse le parseur lire le message à la demande.
Signal d'alerte« On ajoute des instances au flux » ou « on donne plus de mémoire au serveur ». Une réponse qui ne parle jamais de la façon dont l'arbre est parcouru.
Question 3 · junior à confirmé
Une application envoie une requête dans une file MQ et attend la réponse sur une autre file. Comment le flux ACE fait-il pour que la réponse revienne au bon demandeur ?
Une bonne réponseLe demandeur renseigne ReplyToQ et ReplyToQMgr dans l'en-tête MQMD. Côté ACE, le nœud MQReply lit ces champs et place l'identifiant de la requête dans le CorrelId de la réponse, selon les options du MQMD (MsgId recopié dans CorrelId le plus souvent). Le demandeur lit sa file de réponse en filtrant sur ce CorrelId. La personne pense aussi à une durée d'expiration sur la requête et à conserver les en-têtes MQMD quand un nœud Compute reconstruit le message.
Signal d'alerte« On lit le premier message de la file de réponse. » Ou un Compute en mode Message qui écrase le MQMD sans que la personne sache pourquoi la réponse se perd.
Question 4 · confirmé
Le même fichier BAR doit partir en recette puis en production, avec des files, des URL et des identifiants différents. Comment procédez-vous sur ACE 12 ou 13 ?
Une bonne réponseLe BAR est construit une fois. Les valeurs qui changent vivent hors du code : des projets de policies (MQEndpoint, HTTP, JDBC, etc.) propres à chaque environnement, des surcharges de propriétés appliquées au BAR avec ibmint apply overrides ou mqsiapplybaroverride, et les mots de passe dans le coffre d'identifiants du serveur (mqsisetdbparms, ibmint set credential ou un coffre externe), jamais dans le BAR. Les réglages du serveur passent par server.conf.yaml. Un profil récent sait que les configurable services d'IIB ont été remplacés par les policies depuis ACE 11.
Signal d'alerteReconstruire le BAR dans le Toolkit pour chaque environnement avec les valeurs en dur, ou chercher des configurable services sur ACE 12.
Question 5 · senior
Vous reprenez 80 flux IIB 10 à migrer vers ACE 13 en conteneurs. Par quoi commencez-vous ?
Une bonne réponsePar un inventaire : nœuds utilisés, parseur MRM encore présent, configurable services à transformer en policies, flux qui s'appuient sur un gestionnaire de files local (agrégation, collecteur, minuteries, transactions coordonnées), dépendances entre flux et bibliothèques partagées. La configuration de l'existant s'extrait avec les outils de migration d'IBM (ibmint extract node, ou mqsiextractcomponents sur les versions plus anciennes). Ensuite, un découpage en serveurs d'intégration indépendants par domaine ou par application, un gestionnaire de files distant ou dédié pour les flux qui en ont besoin, et une non-régression rejouée sur des messages réels capturés avant la bascule.
Signal d'alerte« On réimporte tout dans le nouveau Toolkit et on déploie les 80 flux dans un seul conteneur. » Aucun mot sur les flux qui dépendent d'un gestionnaire de files local.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
IBM ACE et MQ : les questions des recruteurs
IIB ou ACE sur un CV, quelle différence pour le poste ?
Le langage ESQL, les nœuds et la logique des flux sont les mêmes. Ce qui change depuis ACE 11 : les policies remplacent les configurable services, un serveur d'intégration peut tourner seul sans nœud ni gestionnaire de files local, et le déploiement en conteneurs devient courant. Un développeur qui n'a connu qu'IIB reste employable sur la maintenance, mais il lui faudra du temps sur un projet de migration ou en conteneurs.
Un administrateur MQ peut-il tenir un poste de développeur ACE ?
Il connaît les files, les canaux, la persistance et le diagnostic d'un message bloqué, ce qui aide beaucoup. Il lui manque souvent l'écriture de flux : ESQL, parseurs, traitement d'erreur, tests. Posez-lui la question de la boucle sur 10 000 lignes et celle du découpage d'un fichier en 500 messages. S'il y répond avec du code précis, le passage est réaliste ; sinon, prévoyez une période de montée en compétences.
Quel test technique proposer à un développeur IBM ACE ?
Un flux existant à corriger en une heure : une boucle ESQL lente, un Catch qui consomme l'erreur, une valeur d'environnement écrite en dur. La personne explique à voix haute ce qu'elle change et pourquoi. Pour un senior, ajoutez la discussion d'une migration de ce flux vers un conteneur. Le Toolkit doit être installé à l'avance sur le poste de test, sinon la séance passe en installation.
Faut-il exiger Java pour un poste ACE ?
Cela dépend de l'équipe. Certaines écrivent presque tout en ESQL, d'autres utilisent des JavaCompute et des bibliothèques Java maison. Beaucoup d'offres françaises citent Java à côté d'ACE. Regardez le code existant avant de rédiger l'annonce : si les flux sont surtout en ESQL, un bon niveau ESQL compte davantage qu'une longue expérience Java sans flux de messages.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
