Policy programs are like cheat codes. If a requirement permit asynchronous nature then policy program is gold. The key feature of policy program is it doesn't need compilation after changes and can be modified run time. Anybody good at SQL can toy around with the powers of policy program.
Recently we were asked to implement email functionality for SR status update changes. As obesessed with PP, i thought of writing new policies for it instead of modiying existing workflows. Things were smooth, life was cool and eveything was deployed successfully. However to my horror emails were not getting triggered. Policy conditions were configured correctly as record was getting created in S_ESCL_REQ table on violation. Situation worsened when email was going via F9 functionality. After some debugging it was observed that Email Manager Task was not running because of which emails were not flowing out of the system.
Email Manager component in conjuction with Communications Outbound Manager is the trump while using policy program of type "Send Message" for sending emails. Both are part of the Communications Management component group. Email Manager uses profiles set up in Communications Manager. The Communications Outbound
Manager does verification of the profile. Below is the snapshot of how Email Manager sends email message.
1 - Workflow monitor agent reads record from the S_ESCL_REQ and inserts a record into the S_APSRVR_REQ table for workflow actions that invokes the Send Email workflow policy programs.
2 - Email Manager picks up records from the S_APSRVR_REQ table, setting their status from QUEUED to ACTIVE then to SUCCEEDED during the course of the execution.
3 - Outbound Communications Manager is invoked to log onto the SMTP/POP3 profile and send the outbound message.
So in order for smooth email bombarding Email Manager should be up and task should be running.
Happy e-Mailing!!
אין תגובות:
הוסף רשומת תגובה