Les versions du dispatcher sont indépendantes d’AEM. Cependant, la documentation du dispatcher est incluse dans la documentation d’AEM. Utilisez toujours la documentation du dispatcher incluse dans la documentation de la dernière version d’AEM.
Vous avez été redirigé vers cette page si vous avez suivi un lien vers la documentation de Dispatcher incluse dans la documentation d’une précédente version d’AEM.
Pour plus d’informations, consultez également la Base de connaissances de Dispatcher, Dépannage des problèmes de purge du Dispatcher et la FAQ sur les problèmes fréquents de Dispatcher.
Comme toujours, les premières étapes consistent à vérifier les principes de base :
Passez en revue tous les fichiers journaux du serveur web et de Dispatcher. Si nécessaire, augmentez le paramètre loglevel
utilisé pour la journalisation de Dispatcher.
Vérifiez votre configuration :
Disposez-vous de plusieurs instances de Dispatcher ?
Avez-vous implémenté des filtres ?
IIS propose divers outils de trace, en fonction de la version :
Ces outils peuvent vous aider à surveiller l’activité.
Lorsque vous utilisez IIS, une erreur 404 Not Found
peut survenir dans plusieurs cas de figure. Si cela se produit, consultez les articles suivants de la base de connaissances.
/bin
retour du chemin d’accès de base 404 Not Found
Vous devez également vérifier que la racine du cache de Dispatcher et la racine du document IIS sont placées dans le même répertoire.
Symptômes
Problèmes lors de la tentative de suppression des modèles de processus lorsque vous accédez à une instance de création AEM à l’aide de Dispatcher.
Étapes à reproduire :
Connectez-vous à l’instance de création (vérifiez que les demandes sont redirigées vers Dispatcher).
Créez un processus ; par exemple, en définissant le titre processusASupprimer.
Vérifiez que le processus a été correctement créé.
Sélectionnez un processus puis cliquez dessus avec le bouton droit, puis cliquez sur Supprimer.
Cliquez sur Oui pour confirmer.
La boîte de message d’erreur suivante s’affiche :
« ERROR 'Could not delete workflow model!!
».
Résolution
Ajoutez les en-têtes suivants à la section /clientheaders
du fichier dispatcher.any
:
x-http-method-override
x-requested-with
{
{
/clientheaders
{
...
"x-http-method-override"
"x-requested-with"
}
Ceci décrit comment Dispatcher interagit avec mod_dir
dans le serveur web Apache, car cela peut entraîner des effets variés, potentiellement inattendus :
Dans Apache 1.3, mod_dir
traite chaque demande pour laquelle l’URL est mappée à un répertoire du système de fichiers.
mod_dir :
index.html
existant ;Lorsque Dispatcher est activé, il traite ces demandes en s’enregistrant lui-même en tant que gestionnaire pour le type de contenu httpd/unix-directory
.
Dans Apache 2.x, les choses sont différentes. Un module peut gérer différentes étapes de la demande, telles les corrections d’URL. mod_dir
gère cette étape en redirigeant une demande (lorsque l’URL est mappée à un répertoire) vers l’URL comportant un signe /
ajouté.
Dispatcher n’intercepte pas la correction mod_dir
mais gère entièrement la demande vers l’URL redirigée (c’est-à-dire avec le signe /
ajouté). Un problème peut se poser si le serveur distant (par exemple AEM) gère les requêtes envoyées à /a_path
différemment des requêtes envoyées à /a_path/
(lorsque /a_path
est mappé sur un répertoire existant).
Si cela se produit, vous devez effectuer l’une des opérations suivantes :
Désactivez mod_dir
pour la sous-arborescence Directory
ou Location
gérée par Dispatcher.
Utilisez DirectorySlash Off
pour configurer mod_dir
de manière à ne pas ajouter le signe /
.