F5 APM : personnalisation, iApps et dépendances

Les écrans de logon, messages, erreurs et webtops peuvent être adaptés selon les modes de personnalisation documentés. Les champs attendus par les actions et les éléments qui déclenchent le parcours doivent rester fonctionnels. Une page plus jolie ne doit pas rendre le login ou les erreurs inutilisables.

Testez clavier, contrastes, langues, petits écrans et messages de refus. Évitez d’exposer des détails internes sur les serveurs AAA dans un message destiné à l’utilisateur.

Une iApp ou un template peut générer des objets avec une relation de gestion. Modifier directement un objet géré peut être limité ou écrasé lors d’une reconfiguration. Identifiez la source de configuration et les dépendances avant l’édition.

Exportez la référence, notez la version du template et vérifiez le support de votre plateforme. Après import ou upgrade, rejouez les écrans et les actions de politique. Les anciennes personnalisations ne sont pas automatiquement compatibles avec un nouveau mode d’interface.

Comprendre la propriété des objets iApps.

Ces repères permettent de relier le besoin à la configuration et aux observations. Comparer les objets réellement attachés au service avant de modifier un réglage.

Une personnalisation supprime le champ utilisé par Logon Page. Le formulaire s’affiche mais l’action suivante ne reçoit plus la variable attendue. Comparez les noms de champs et le mapping avant de modifier l’authentification AAA.

Expliquez la décision du schéma, puis recherchez dans la référence les objets qui la produisent. Pour APM, justifiez aussi ce qui changerait si un prérequis échouait : une réponse DNS, une décision WAF et une autorisation d’accès ne se vérifient pas au même endroit.

Revenir au parcours F5 APM pour lire les guides voisins et leurs exemples.