Question
Monitoring Campaign Execution
Hi,
Since there is a limitation in Pega Monitoring process, I like to enhance the monitor process via Activities and JAVA.
Some examples of activities that we need to monitor:
1) List of campaigns that are to be executed daily,
2) Suspending recurring campaigns when our customer base is not refreshed,
3) Notify user when a recurring campaign failed,
4) Notifying user of the completion of campaign,
5) Notifying user when all emails or SMS are sent in a campaign,
and the list can goes on.
I scanned the database and I am only gather these 3 tables: pgdata.mkt_work and pgdata.pr_data_corr_sms, and pgdata.pr_data_corr_email.
1) pgdata.mkt_work
From what I see, this is the main table for the scheduling processes.
a) How can I list the campaigns that are to be executed today?
b) What mkt_work.pystatuswork should I set the campaign to if our customer base is not able to load in time?
c) Follow on with (b), when our customer base has been refreshed and our campaign can proceed with the execution, what is the mkt_work.pystatuswork that I should set it to?
d) What is the mkt_work.pystatuswork should I look up for if the campaign failed, so that I can notify the user?
e) i) What is the mkt_work.pystatuswork that I should lookup for if the campaign completed?
ii) What is the mkt_work.pystatuswork that I should lookup for if the multi-stage campaign has completed a stage for the day?
2) pgdata.pr_data_corr_sms and pgdata.pr_data_corr_email
I planned to write triggers (upon insert and delete) in the 2 tables to output the data to another tables, so that I can determine whether all SMS and emails have completed sending.
a) how can I link the SMS/email records to the campaign?
b) Is it possible to decode the SMS/email message so that I can send it to the marketing user?
If you find that some information is not suitable to be broadcast, please send the detail instruction/explanation to my login ID. We really need to build in these monitoring processes, otherwise, we are not able to act proactively whenever there is a issue, and it will be a chore for us to do the follow up.
I really hope I need not have to wait for 1 month plus to get a response with a short/brief reply.
Regards.
***Edited by Moderator: Pallavi to update platform capability tags***
Hi,
Can you give more details on which version of Pega Marketing are you on ?
Here is the initial thoughts on your questions:
1) List of campaigns that are to be executed daily - did you explore the "Marketing Calendar" functionality from the Pega Marketing portal ? this should give you this details OOTB
2) Suspending recurring campaigns when our customer base is not refreshed - Given the BLOB in the tables, its not advised to directly modify the work tables.
This would break other processing in un expected ways. There are few variations you can possibly do this - but unfortunately that would mean taking over rules -
you need to contact product support on this requirement, otherwise if you take over rules, you might face upgrade issues in the future.
You should also see in the organization if you could manage this through better back end processes. For example - why would the customer refresh fail ?
can't that be made more fool proof than fixing the campaign side of it ?
3) Notify user when a recurring campaign failed - This should be already happening OOTB - are you seeing issues ? There should be an email sent to the operator that scheduled
the campaign. Is that not enough and you need more than that ?
4) Notifying user of the completion of campaign - when a program wraps up you should also see notifications I think - if you need a little better control look at PostExecuteProgramRunExt
activity (supported from PM 7.31) - there are precautions of using post processing - read the history of the rule for more documentation on that.
5) Notifying user when all emails or SMS are sent in a campaign - the email and SMS are asynchronous processing from the campaign execution and common for all campaigns running in parallel.
The tables should have a batch class column that corresponds with the campaign run class -
but any sort of table level trigger on these will kill performance of the app server and database. As these are very high volume tables.
You will have to re-visit this with the business stakeholders on what degree of reporting you need here - you can possibly just run external reports to group by based on the columns which I mentioned to give summary of the pending queue.
There are backlog items to expose this to the administrators in future releases.