Skip to Content

Though the option to retry failed instances of a publication has been around for sometime now, there are still some confusions around this option.

If you right click on any of the failed instances of a Publication, you will find three options

  1. Run Now
  2. Reschedule
  3. Retry

While other options are well documented, “retry” is not still very clear

Retry synopsis:

  1. Overwrites the “failed” instance (run now and reschedule will create new instances, but retry will use the failed instance itself)
  2. In case of partial failure – retry option will process only the failed recipients.
  3. In case of complete failure – the full job runs and is same as run now option- except for the fact that a new instance is NOT created when we retry.
  4. In case if the server stops abruptly (example, you try to force restart SIA or the full box), the progress is not saved and so when the server comes up again, the instance that was running while the server was shutdown will be restarted from the beginning.
  5. Auto-Retry
    1. We can automate it using the “number of retries allowed” under the “recurrence” property of the publication.
    2. In case of a failure, it will wait for the specified duration and then will attempt to run the publication again.
  6. SAP note:
    1. https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F64653D3030312669765F7361706E6F7465735F6E756D6265723D3139353137313026

How can you test this?

If you want to replicate the partial failure scenario, you can follow the below steps.


Publication Properties

  • Source Documents: 16 Crystal reports(simple ones) – Just to make sure that we have enough time to stop the publication in the middle.
  • Dynamic Recipients: 24 recipients (web-I) – you can also use an excel file to build the Dynamic recipient report for testing.
  • Format: PDF
  • Destination: Email
  • Merged PDF: Yes
  • Personalization: Enabled


Steps:

  • Start the publication(preferably in the test mode – end users will not be annoyed)
  • After receiving few emails bring down the file repository services
  • Publication instance will go to failed state
  • Move the received files to a new outlook folder (optional – to make it easier)
  • Bring up the file repo services again. Wait for couple of minutes after this is up.
  • Right click on the failed instance and click on Retry
  • The job will continue from the point it failed and the status will change to “Running”.
  • Wait till the status becomes “success” and then check the emails received.


Screenshots

  • The list of documents

/wp-content/uploads/2015/02/2_651733.png

  • Dynamic recipient web-intelligence report

/wp-content/uploads/2015/02/3_651734.png

  • Emails received before stopping the repository services

/wp-content/uploads/2015/02/4_651735.png

  • Select the services and click on stop. (this is replicate the partial failure scenario)

/wp-content/uploads/2015/02/5_651736.png

  • Instance fails and the below message is displayed

/wp-content/uploads/2015/02/6_651737.png

  • Move received emails to a new folder (optional – to makes things easier)

/wp-content/uploads/2015/02/7_651738.png

  • Start file repository services using CMC/CCM

/wp-content/uploads/2015/02/8_651739.png

  • Once the services are up, right click on the failed instance and click on “Retry”

/wp-content/uploads/2015/02/9_651740.png

  • Wait till the instance status becomes “Success”

/wp-content/uploads/2015/02/10_651741.png

  • Now you will see that the platform processed only 16 recipients (those who did not get the email during the initial run). Hence all 24 recipients are processed and there are no duplicate emails.

/wp-content/uploads/2015/02/11_651742.png

  • Auto retry Option:

/wp-content/uploads/2015/02/1_651732.png

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply