La fonctionnalité de confirmation différée, un composant de Managed Reporting, permet aux utilisateur de soumettre une procédure Managed Reporting qui s'exécute en arrière-plan. L'utilisateur affiche alors le rapport résultant final dans l'interface « Statut de rapport différé » de Managed Reporting. Cela est différent des procédures soumises pour l'exécution immédiate, auquel cas le navigateur attend la fin de la requête

Du point de vue de la sécurité, les requêtes en exécution différée sont acceptées par le serveur d'applications de la même manière que les requêtes en exécution immédiate. Si la sécurité des serveurs d'applications est activée, la requête différée doit se connecter avec un identifiant utilisateur et mot de passe de serveur d'applications valides.

Quand une requête est complétée, sa sortie est stockée dans un fichier sur le serveur de rapports, dans le répertoire drive:/srv/wfs/dfm_dir. La sortie est accompagnée par le fichier correspondant qui contient l'ID utilisateur qui a soumis la requête en et d'autres informations. Le serveur de génération de rapport assure que seul l'utilisateur qui a soumis la tâche différée peut ouvrir, supprimer et vérifier l'état du fichier de sortie. L'administrateur du serveur de génération de rapport (l'utilisateur identifié par le mot-clé server_admin_id dans le fichier edaserve.cfg) peut aussi visualiser et supprimer toute sortie différée, mais seulement au niveau du fichier ou en utilisant la console du serveur d'applications.

L'accès au répertoire dfm_dir devrait être restreint pour que l'ID utilisateur qui a démarré le serveur de rapports ait un accès en lecture et en écriture. L'accès en lecture doit être limité pour empêcher l'accès au répertoire aux utilisateurs non autorisés.

Un ticket différé et stocké dans le référentiel Managed Reporting pour chaque requête différée. Les tickets sont stockés par chaque utilisateur Managed Reporting. Ne peuvent voir que leurs propres tickets différés, à l'exception d'un administrateur ayant accès au mode gestionnaire. Le ticket contient le nœud du serveur d'applications sur lequel réside la sortie.

Quand un utilisateur demande un statut différé, tous les tickets appartenant à cet utilisateur sont traités en une seule fois. Si des informations d'identification sont requises pour la récupération du statut sur l'un des serveurs, le formulaire d'authentification du système de serveur dynamique s'affiche. Si l'un ou plusieurs des serveurs sont temporairement indisponibles, l'état de ceux-ci s'affiche comme inconnu.

Si un utilisateur a soumis une requête différée un jour avec l'ID utilisateur user1, puis soumet la même requête le jour d'après avec l'ID utilisateur user2 et vérifie le statut différé, il lui sera impossible d'accéder à la requête du jour précédent et recevra un message d'erreur.

Pour accéder au premier rapport, l'utilisateur doit fermer la session et se connecter au serveur de génération de rapport en tant que user1.