BBP_GET_STATUS_2 job taking long time to finish

[Former Member]

Hi gurus,

We have scheduled a job for program BBP_GET_STATUS_2

It was completing in few minutes when data was less.

But as data increases is taking long time almost 1 and half day to complete.

Please suggest us what shall we do to get this complete in short time.

[Former Member]

I would customize/run a job for 2 or 3 weeks at maximum. Besides this I would offer to the SRM user a button in the Web in order to start the status update program for their own SCs.

That should help everyone (system time, performance and the user)

[Former Member]

Hi. I have finally found a workable solution to this, on our system at least.

I noticed that 1 month of carts took 2 hours to run.

3 months took 11 hours.

8 months took 3 days.

However, if we run 3 months as 3 separate jobs, each running for 1 month, it only took 6 hours.

This means we can run 1 month every 4 hours, then the previous 5 months one at a time once a day, taking 10 hours, meaning we have 6 months covered daily.

Then every weekend we run the previous 12 months before the last 6. We do this 1 at a time, which takes 24 hours, but this means we are covering 18 months in total.

I hope this is of some help.

Regards,

Dave.

[peter_novoth]

Hi David,

just one more thing. There were recently a lot of changes in the BBP_GET_STATUS_2. Implement the note 1095754 (or the 1079763 in case of SRM 4.0) into your SRM system, and the 1078147 into your backend system.

These notes include the latest changes, and hopefully will also speed up the report.

Kind regards,

Peter

[Former Member]

Hi. We already have those notes.

We raised several calls with SAP, and we put in loads of notes, but nothing seemed to make any difference.

We create 30000 carts a month, and I do not think that program is built to handle that many.

I had hoped it would be obsolete on the next version and there would be some realtime technology to update cart status, but it seems that has not happened.

Thanks a lot for your help.

Regards,

Dave.

[Former Member]

Hi. We have the exact same problem. We have put in all the notes mentioned here and more.

We have looked at the variant and have restricted it as much as possible, but we create about 30000 carts a month and some of them are not complete for a long time so we can not restrict the days too much.

We try to run BBP_GET_STATUS_2 for 90 day timeframe, as this covers much of it, but it takes over 10 hours to run.

We would then want to run more than 90 days once a week or something, but this takes 24 hours to run.

Does anyone have any more ideas how we can improve this?

I am thinking about stopping running the program and use a user exit in MIRO and MIGO to RFC into SRM and run the program for just the 1 applicable cart at a time, but this seems a bit drastic.

I have asked SAP all this but they told us the same as above, try the notes, restrict the variant.

Regards,

Dave.

[Former Member]

Shiv,

Try to schedule multiple jobs of this with different job varients. One that runs every hour, one that runs every day and one on a weekly basis. This should help you to keep up eith increasing demad.

[imthiaz_ahmed]

Please verify if the job scehduled has the proper vairants with the fields like SCs in Last ... Days filled with like 10 days, if this is left empty it will take longer time and the Time Frame etc. Hope this helps.

Regards,

Imthiaz

Award points if .....

[Former Member]

Hi,

See this very useful thread for setting the variant correctly for the report.

Also see these notes for the performance of the report execution based on the SRM version at your place:

Note 1152412 - BBP_GET_STATUS_2: performance improvement in SRM4.0

Note 1145063 - BBP_GET_STATUS_2: High runtime, improvement proposals

Note 1005993 - Performance in BBP_STATUS_READ for more than 20 000 items

Note 878654 - BBP_GET_STATUS_2 performance: Enhancement around period

Note 1084987 - Synchronizing documents and status between ERP and SRM

BR,

Disha.

Do reward full points for useful answers.