on 04-09-2009 2:34 PM
We are starting RPTARQEMAIL and the other needed programs with a job every 15 minutes. The last month everything works fine. Since about 1 month every mail is sending 2 times.
1. The job runs the first time and RPTARQEMAIL is selecting the right requests to the right period. The RPTARQEMAIL reads the table PTREQ_BATCH perfect and is setting the PTREQ_BATCH perfect. The e-mails will be send.
2. When the job runs a second time RPTARQEMAIL read the requests again. The form is starting with the right period, but the answer includes the requests of the last job. The e-mails for a old request will be send a second time.
3. With the next job the requests from the first job are not more selected.
Thanks for help.
Hi SDN colleagues,
I know that this post is quite old and marked as "Assumed answered", but since so far no solution was posted, and after dealing with a similar issue for a long time, I figured I'd post my solution for future reference:
we experienced the same problem at a customer system: about 3/4 of the mails sent through RPTARQMAIL and RPTCORMAIL (mostly those to the requestor) were sent twice, on two successive program runs. Our POST and MAIL programs were initially scheduled to run every 15 minutes, as two sequential steps on the same job, but even a change to 1 hour did not solve the problem.
After a while we noticed a certain pattern: requests with doubled mails were those which change to Status Posted (as visible in transaction PTCOR/PTARQ) occurred at the exact time that was marked as "Last run" of the email program on table PTREQ_BATCH. This meant that the items were valid for two successive intervals, thus the doubled mails.
To solve the issue we separated the POST and MAIL steps in two different jobs that run with a time lag of a couple of minutes. Worked like a charm!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Siddharth Rajora
We can see the same request in two RPTARQEMAIL log. So this report is the one which sends the mail.
It's seems is a problem with the timestamp.
Best regards.
Rubé
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
make sure you are not running any other job to send email also check your customised WF if it sends a mail
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello
It's been a long time since this post but we are experimenting a similar behaviour.
could you tell me if you solved the problem? and, if yes, how?
Thank you in advanced
Best regards
Rubé
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sine your WF is untouched I would ask you to run with Since last run only and try it
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There is a selection in the report which Says SInce last run, Ensure this is set
and check you have not done any modification to WF to trigger a mail step?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your help.
But the option u201ESince last runu201C is setting.
On debugging I see
########
PERFORM get_requests USING from_timestamp
c_arq_reqtype
to_timestamp
CHANGING req_tab.
########
gives me back in req_tab the request for the right time period plus the requests in the right time period of the run before.
The standard WF is untouched. The two mails are not sending in one running of the program. The two mails are sending with two runs in succession with a time space of 15 min.
User | Count |
---|---|
78 | |
10 | |
8 | |
4 | |
3 | |
3 | |
2 | |
2 | |
2 | |
2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.