Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : Outlook 2013 | Outlook 2016
Le spouleur MAPI utilise la méthode IXPLogon ::FlushQueues pour télécharger et charger tous les messages en attente vers et à partir d’un fournisseur de transport. En règle générale, le spouleur MAPI vide les files d’attente pour tous les fournisseurs de transport connectés à la session, en commençant par le premier fournisseur de transport défini dans la section ordre de transport du profil de l’utilisateur. Le vidage des files d’attente est presque toujours le résultat d’une demande directe de l’utilisateur, de sorte que l’envoi et la réception de messages pendant le vidage des files d’attente sont synchrones avec le spouleur MAPI. Étant donné que ces appels sont synchrones, le fournisseur de transport doit les traiter aussi rapidement que possible.
Les fournisseurs de transport doivent gérer l’appel FlushQueues comme décrit dans la séquence d’étapes suivante pour activer le traitement approprié des messages et permettre à d’autres fournisseurs de transport d’utiliser des ressources externes telles que des modems dans le cadre de l’opération FlushQueues du spouleur MAPI.
| Étape | Composant | Mise en œuvre |
|---|---|---|
| 1. | Spouleur MAPI |
Appelle la méthode FlushQueues pour le premier fournisseur de transport répertorié dans l’ordre de transport du profil de l’utilisateur, en transmettant les indicateurs demandés dans le paramètre ulFlags . FlushQueues est appelé une seule fois avec tous les indicateurs définis pour l’ensemble de l’opération de chargement et de téléchargement. |
| 2. | Fournisseur de transport |
Doit effectuer un certain nombre d’opérations avant de revenir à partir de l’appel FlushQueues . Si des messages précédemment envoyés sont différés, la méthode IMAPISupport ::SpoolerNotify doit être appelée avec l’indicateur NOTIFY_SENT_DEFERRED défini. Notez qu’il est possible pour le spouleur MAPI d’annuler un message qui a été différé avant que le fournisseur de transport ait la possibilité de terminer le traitement du message. Si le fournisseur de transport utilise une ressource externe telle qu’un modem, la connexion à la ressource externe doit être établie. Le bit STATUS_OUTBOUND_FLUSH dans la propriété PR_STATUS_CODE (PidTagStatusCode) de la ligne status du fournisseur de transport doit être défini à l’aide de la méthode IMAPISupport ::ModifyStatusRow. Le fournisseur de transport doit ensuite retourner S_OK pour l’appel FlushQueues . |
| 3. | Spouleur MAPI |
Vérifie la ligne status du fournisseur de transport pour le bit STATUS_OUTBOUND_FLUSH et appelle IXPLogon ::SubmitMessage pour le premier message de la file d’attente. |
| 4. | Fournisseur de transport |
Gère le message et retourne à partir de l’appel SubmitMessage . |
| 5. | Spouleur MAPI |
Si le fournisseur de transport retourne S_OK à partir de SubmitMessage, le spouleur MAPI appelle IXPLogon ::EndMessage pour le message comme il le fait avec l’envoi de messages standard. Si le fournisseur de transport retourne une valeur autre que S_OK à partir de SubmitMessage, le spouleur MAPI gère la valeur de manière appropriée avant d’appeler EndMessage, ou avant d’appeler à nouveau SubmitMessage . |
| 6. | Fournisseur de transport |
Retourne à partir de EndMessage avec son status de traitement des messages dans le paramètre lpulFlags. |
| 7. | Spouleur MAPI et fournisseur de transport |
La boucle SubmitMessage- EndMessage continue jusqu’à ce que tous les messages de la file d’attente aient été téléchargés. |
| 8. | Spouleur MAPI |
Avertit le fournisseur de transport qu’il a terminé le téléchargement des messages en appelant la méthode IXPLogon ::TransportNotify du fournisseur de transport avec l’indicateur NOTIFY_END_OUTBOUND_FLUSH défini. |
| 9. | Fournisseur de transport |
Libère toutes les ressources externes utilisées dans l’envoi de messages sortants afin qu’elles puissent être utilisées par d’autres fournisseurs de transport pour vider leurs files d’attente. Le bit STATUS_INBOUND_FLUSH dans la propriété PR_STATUS_CODE de la ligne status du fournisseur de transport doit être défini à l’aide de ModifyStatusRow. |
| 10. | Spouleur MAPI |
Vérifie la ligne status du fournisseur de transport pour le bit STATUS_INBOUND_FLUSH et appelle IXPLogon ::StartMessage s’il est défini. |
| 11. | Fournisseur de transport |
Traite le message et retourne à partir de StartMessage. Si le fournisseur de transport a d’autres messages à charger, il doit appeler SpoolerNotify avec l’indicateur NOTIFY_NEWMAIL défini. Si le fournisseur de transport n’a aucun message à charger, il doit appeler IMAPIProp ::SaveChanges sur le message que le spouleur MAPI a passé dans StartMessage et retourner. |
| 12. | Spouleur MAPI |
Continue d’appeler StartMessage jusqu’à ce que SaveChanges soit appelé sur un message. Une fois le chargement du fournisseur de transport terminé, le spouleur MAPI appelle TransportNotify avec l’indicateur NOTIFY_END_INBOUND_FLUSH défini. |
| 13. | Fournisseur de transport |
Efface le bit STATUS_INBOUND_FLUSH dans la propriété PR_STATUS_CODE de sa ligne status à l’aide de ModifyStatusRow et libère toutes les ressources externes afin qu’elles puissent être utilisées par d’autres fournisseurs de transport. |
| 14. | Spouleur MAPI |
Appelle FlushQueues pour le fournisseur de transport suivant répertorié dans l’ordre de transport du profil de l’utilisateur. |
Si une application cliente appelle IMAPIStatus ::FlushQueues sur l’objet status d’un fournisseur de transport, le fournisseur de transport doit définir le bit approprié dans sa ligne status avec ModifyStatusRow. Le spouleur MAPI appelle ensuite la méthode IXPLogon ::FlushQueues du fournisseur de transport à la convenance du spouleur MAPI. Lorsque la méthode IXPLogon ::FlushQueues du fournisseur de transport est appelée à la suite de l’appel IMAPIStatus ::FlushQueues d’une application cliente, l’opération se produit de manière asynchrone pour l’application cliente. Sinon, IXPLogon ::FlushQueues fonctionne de manière synchrone avec le spouleur MAPI.
Pour des raisons de performances, le spouleur MAPI n’appelle la méthode FlushQueues d’un fournisseur de transport que si les indicateurs STATUS_INBOUND_FLUSH et STATUS_OUTBOUND_FLUSH sont définis dans la ligne status du fournisseur de transport. Par conséquent, un fournisseur de transport peut arrêter l’opération FlushQueues à tout moment en effaçant les indicateurs STATUS_OUTBOUND_FLUSH et STATUS_INBOUND_FLUSH dans sa ligne de status. Si le spouleur MAPI s’arrête et doit mettre fin à l’opération FlushQueues , il appelle TransportNotify avec les indicateurs NOTIFY_END_INBOUND_FLUSH et NOTIFY_END_OUTBOUND_FLUSH définis. Le fournisseur de transport doit libérer toutes les ressources externes et retourner.