Partager via

Envoi de messages via les fournisseurs de banques de messages

  • Article

S’applique à : Outlook 2013 | Outlook 2016

Les fournisseurs de magasins de messages ne sont pas tenus de prendre en charge les envois de messages sortants (autrement dit, la possibilité pour les applications clientes d’utiliser le fournisseur de magasin de messages pour envoyer des messages). Les applications clientes doivent utiliser une banque de messages lors de l’envoi de messages, car les données du message doivent être stockées quelque part entre le moment où l’utilisateur a fini de le composer et le moment où le spouleur MAPI transmet le message à un fournisseur de transport pour l’envoyer au système de messagerie sous-jacent. Si votre fournisseur de magasin de messages ne prend pas en charge les envois de messages sortants, il ne peut pas être utilisé comme magasin de messages par défaut.

Pour prendre en charge l’envoi de messages, votre fournisseur de magasin de messages doit effectuer les opérations suivantes :

La méthode SetLockState est importante pour une bonne interopérabilité entre le spouleur MAPI et les clients. Lorsque le spouleur MAPI appelle SetLockState sur un message sortant, le fournisseur de magasin de messages ne doit pas laisser les clients ouvrir le message. Si un client tente d’ouvrir un message verrouillé par le spouleur MAPI, le fournisseur de magasin de messages doit retourner MAPI_E_NO_ACCESS. L’état verrouillé d’un message ne doit pas être persistant si le magasin est arrêté alors que le message est verrouillé par le spouleur MAPI.

Que le spouleur MAPI ait verrouillé ou non un message sortant, le fournisseur de magasin de messages ne doit pas autoriser l’ouverture d’un message dans la file d’attente de messages sortants pour écriture. Si un client appelle la méthode IMSgStore ::OpenEntry sur un message sortant avec l’indicateur MAPI_MODIFY, l’appel doit échouer et retourner MAPI_E_SUBMITTED. Si une application cliente appelle OpenEntry sur un message sortant avec l’indicateur MAPI_BEST_ACCESS, le fournisseur de magasin de messages doit autoriser l’accès en lecture seule au message.

Lorsqu’un message doit être géré par le spouleur MAPI, le fournisseur de magasin de messages définit la propriété PR_SUBMIT_FLAGS du message (PidTagSubmitFlags) sur SUBMITFLAG_LOCKED. La valeur SUBMITFLAG_LOCKED indique que le spouleur MAPI a verrouillé le message pour son utilisation exclusive. L’autre valeur de PR_SUBMIT_FLAGS, SUBMITFLAG_PREPROCESS, est définie lorsque le message nécessite un prétraitement par une ou plusieurs fonctions de préprocesseur inscrites par un fournisseur de transport.

Les procédures suivantes décrivent comment le magasin de messages, le transport et le spouleur MAPI interagissent pour envoyer un message d’un client à un ou plusieurs destinataires.

L’application cliente appelle la méthode IMessage ::SubmitMessage . Dans SubmitMessage, le fournisseur de magasin de messages effectue les opérations suivantes :

  1. Appelle IMAPISupport ::P repareSubmit. Si MAPI renvoie une erreur, le fournisseur de la banque de messages renvoie cette erreur au client.

  2. Définit le bit MSGFLAG_SUBMIT dans la propriété PR_MESSAGE_FLAGS (PidTagMessageFlags) du message.

  3. Garantit qu’il existe une colonne pour la propriété PR_RESPONSIBILITY (PidTagResponsibility) dans la table de destinataires et la définit sur FALSE pour indiquer qu’aucun transport n’a encore assumé la responsabilité de la transmission du message.

  4. Définit la date et l’heure d’origine dans la propriété PR_CLIENT_SUBMIT_TIME (PidTagClientSubmitTime).

  5. Appelle IMAPISupport ::ExpandRecips pour effectuer les opérations suivantes :

    1. D�veloppez toutes les listes de distribution personnelles et des destinataires personnalis�s et remplacez tous les noms d'affichage modifi� par leur nom d'origine.

    2. Supprimer les doublons.

    3. Vérifiez les prétraitements requis et, si le prétraitement est requis, définissez l’indicateur NEEDS_PREPROCESSING et la propriété PR_PREPROCESS (PidTagPreprocess), qui est réservée à MAPI.

    4. D�finir l'indicateur NEEDS_SPOOLER si la banque de messages est fortement coupl�e � un type de transport et qu'il ne peut pas g�rer tous les destinataires.

  6. Ex�cute les t�ches suivantes si l'indicateur de message NEEDS_PREPROCESSING est d�fini :

    1. Place le message dans la file d’attente sortante avec le bit SUBMITFLAG_PREPROCESS défini dans la propriété PR_SUBMIT_FLAGS .

    2. Avertit le spouleur MAPI que la file d'attente a �t� modifi�e.

    3. Rend le contr�le au client et le flux de messages continue dans le spouleur MAPI. Le spouleur MAPI effectue les t�ches suivantes :

      1. Verrouille le message en appelant IMsgStore ::SetLockState.

      2. Effectue le prétraitement nécessaire en appelant toutes les fonctions de prétraitement dans l’ordre d’inscription. Les fournisseurs de transport appellent IMAPISupport ::RegisterPreprocessor pour inscrire les fonctions de prétraitement.

      3. Appelle IMessage ::SubmitMessage sur le message ouvert pour indiquer à la banque de messages que le prétraitement est terminé.

S’il n’y a pas eu de prétraitement ou s’il y a eu prétraitement et le spouleur MAPI appelé SubmitMessage, le fournisseur de la banque de messages effectue les opérations suivantes dans le processus client :

  • Performs the following tasks if the message store is tightly coupled to a transport and the NEEDS_SPOOLER flag was returned from IMAPISupport::ExpandRecips:

    • G�re tous les destinataires pouvoir prendre en charge.

    • D�finit la propri�t� de PR_RESPONSIBILITY la valeur True pour tous les destinataires qu'il g�re.

    • Ex�cute les t�ches suivantes si tous les destinataires sont connus � ce magasin �troitement coupl� et de transport :

      • Appelle IMAPISupport ::CompleteMsg si le message a été prétraité ou si le fournisseur de la banque de messages souhaite que le spouleur MAPI termine le traitement des messages. Le flux de messages se poursuit avec le spouleur MAPI.

      • Effectue les tâches suivantes si le message n’a pas été prétraité ou si le fournisseur de la banque de messages ne souhaite pas que le spouleur MAPI termine le traitement des messages :

        1. Copie le message dans le dossier identifié par l’identificateur d’entrée dans la propriété PR_SENTMAIL_ENTRYID (PidTagSentMailEntryId), si défini.

        2. Supprime le message si la propriété PR_DELETE_AFTER_SUBMIT (PidTagDeleteAfterSubmit) a la valeur TRUE.

        3. Déverrouille le message s’il est verrouillé.

        4. Retourne au client. Le flux de messages est terminé.

    • Effectue les tâches suivantes si le message a été prétraité ou si le fournisseur souhaite que le spouleur MAPI termine le traitement des messages :

      1. Appelle IMAPISupport ::CompleteMsg.

      2. Continue le flux de messages avec le spouleur MAPI. Pour plus d’informations, consultez Envoi de messages : tâches du spouleur MAPI.

    • Effectue les tâches suivantes si le message n’a pas été prétraité ou si le fournisseur ne souhaite pas que le spouleur termine le traitement des messages :

      1. Copie le message dans le dossier identifié par l’identificateur d’entrée dans la propriété PR_SENTMAIL_ENTRYID , s’il est défini.

      2. Supprime le message si la propriété PR_DELETE_AFTER_SUBMIT a été définie sur TRUE.

      3. Déverrouille le message s’il est verrouillé.

      4. Retourne à l’appelant. Le flux de messages est terminé.

  • Ex�cute les t�ches suivantes si la banque de messages n'est pas �troitement coupl�e � un type de transport, pas tous les destinataires ont �t� connus pour la banque de messages ou l'indicateur NEEDS_SPOOLER est d�fini :

    1. Le message est plac� dans la file d'attente sortante sans d�finir le bit SUBMITFLAG_PREPROCESS dans la propri�t� PR_SUBMIT_FLAGS.

    2. Avertit le spouleur MAPI que la file d'attente sortante a chang� en g�n�rant une notification de la table.

    3. Renvoie au client et le flux des messages se poursuit avec un ensemble de t�ches effectu�es par le spouleur MAPI.

Voir aussi