Ce serait généralement une mauvaise idée d'essayer d'envoyer un e-mail dans un déclencheur.
- Si le système est incapable d'envoyer l'e-mail (par exemple, parce que le serveur SMTP est temporairement indisponible), le déclencheur échouera et l'instruction de déclenchement échouera et sera annulée. Il est très rare que vous souhaitiez vraiment arrêter la transaction sous-jacente simplement parce que vous n'avez pas pu envoyer d'e-mail.
- L'envoi d'un e-mail n'est pas transactionnel. Cela signifie que vous enverrez des e-mails pour les modifications qui ne seront jamais validées. Et vous enverrez des e-mails plusieurs fois car Oracle choisit de revenir en arrière et de réexécuter tout ou partie d'un
INSERT
déclaration afin de maintenir la cohérence d'écriture.
Vous serez généralement bien mieux servi avec un travail de base de données qui recherche périodiquement les lignes nécessitant l'envoi d'un e-mail, envoie les e-mails, puis met à jour la table. Vous pouvez utiliser soit l'ancien DBMS_JOB
package ou le nouveau et plus sophistiqué DBMS_SCHEDULER
forfait. Quelque chose dans le sens de
CREATE OR REPLACE PROCEDURE process_issues
AS
BEGIN
FOR i IN (SELECT *
FROM your_table_name
WHERE issue_added = 1
AND email_sent = 0)
LOOP
send_email( i.issue_id );
UPDATE your_table_name
SET email_sent = 1
WHERE issue_id = i.issue_id;
END LOOP;
END;
qui est ensuite programmé pour s'exécuter, disons, toutes les 5 minutes (vous pouvez également utiliser le DBMS_SCHEDULER
paquet)
DECLARE
l_jobno PLS_INTEGER:
BEGIN
dbms_job.submit( l_jobno,
'BEGIN process_issues; END;',
sysdate + interval '5' minute,
'sysdate + interval ''5'' minute' );
commit;
END;
Vous pouvez utiliser le package UTL_MAIL
pour implémenter le send_email
procédure. Il vous suffit probablement d'appeler UTL_MAIL.SEND
avec les paramètres appropriés (en supposant que vous avez configuré votre SMTP_OUT_SERVER
paramètre et votre utilisateur a obtenu l'accès approprié au UTL_MAIL
package et à une ACL qui vous permet de communiquer avec ce serveur SMTP).