Les versions de Dispatcher sont indépendantes d’AEM. Cependant, la documentation de 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.
Vérifiez les Base de connaissances de Dispatcher, Résolution des problèmes de purge de Dispatcher et le FAQ sur les problèmes fréquents de Dispatcher pour plus d’informations.
Comme toujours, les premières étapes consistent à vérifier les principes de base :
Vérifiez tous les fichiers journaux de votre serveur web et de Dispatcher. Si nécessaire, augmentez la variable loglevel
utilisé pour Dispatcher connexion.
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, vous pouvez rencontrer des problèmes 404 Not Found
renvoyée dans divers scénarios. Si cela se produit, consultez les articles suivants de la base de connaissances.
/bin
renvoyer une 404 Not Found
Vérifiez également que la racine du cache de Dispatcher et la racine du document IIS sont définies sur 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 à votre instance d’auteur (vérifiez que les demandes sont acheminées via Dispatcher).
créer un workflow ; par exemple, avec le titre défini sur workflowToDelete.
Vérifiez que le processus a été correctement créé.
Sélectionnez le workflow et cliquez dessus avec le bouton droit, puis cliquez sur Supprimer.
Cliquez sur Oui pour confirmer.
Une boîte de message d’erreur s’affiche. Elle affiche les informations suivantes :
« 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"
}
Ce processus décrit la manière dont Dispatcher interagit avec mod_dir
à l’intérieur du serveur web Apache, car il peut entraîner des effets variés, potentiellement inattendus :
Dans Apache 1.3, mod_dir
gère 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 requêtes 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. Le mod_dir
gère cette étape en redirigeant une requête (lorsque l’URL est mappée à un répertoire) vers l’URL comportant une /
ajouté.
Dispatcher n’intercepte pas la variable mod_dir
correction, mais gère entièrement la requête vers l’URL redirigée (c’est-à-dire, avec /
annexé). Ce processus peut poser un problème si le serveur distant (par exemple, AEM) traite les demandes envoyées à la fonction /a_path
différemment des requêtes envoyées à /a_path/
(lorsque /a_path
est mappé à un répertoire existant).
Si cette situation se produit, vous devez :
disable mod_dir
pour le Directory
ou Location
Sous-arborescence gérée par Dispatcher
Utilisez DirectorySlash Off
pour configurer mod_dir
de manière à ne pas ajouter le signe /
.