4 Replies Latest reply: Jan 25, 2011 1:41 PM by Thomas Kruck RSS

APD job: BI_PROCESS_ANPR runing for very long.

Jitenderkumar Danduvia
Currently Being Moderated

Hi All,

 

I have executed and APD thru Process chain.

The job for APD : BI_PROCESS_ANPR is running more than 30 hrs.

 

In my case APD is transfering data from BI DSO to CRM table.

DSO has around 1.5 million data and 160 fields.

 

Please anyone can give an idea or share doc,to analysis why it is taking long time.

How do I parrallize the job  or any other way to improve preformance.

 

Help will be appreciated.

 

Thanks,

Jitender.

  • Re: APD job: BI_PROCESS_ANPR runing for very long.
    Currently Being Moderated

    Can you check if records are updating if not check the status of background job in sm37 .

    • Re: APD job: BI_PROCESS_ANPR runing for very long.
      Jitenderkumar Danduvia
      Currently Being Moderated

      Thanks for your reply,

       

      But since 30 hrs in job log i can see only :

       

      Job started

      Step 001 started (program RSPROCESS, variant &0000000000165, user ID BWREMOTE)

      Start process ANPR ZADS_CRM in run XXXXXXXX of chain XXXXXX

      -


       

      And in target it is showing 0 records.

       

      Even I am cheking, is their any way we can check how many records are updated. Because the commit statement is called only after all records are updated.

       

      Any other suggestions or help?

       

      regards,

      Jitender.

  • Re: APD job: BI_PROCESS_ANPR runing for very long.
    Currently Being Moderated

    As said earlier have you checked the background job in Sm37?

    Also you can check if there is any deadlock in system ,also as its fecthing 0 records that means background job is still active you can check condition in APD also try to rerun after cancelling it .

  • Re: APD job: BI_PROCESS_ANPR runing for very long.
    Thomas Kruck
    Currently Being Moderated

    Hi Jitender,

    I guess, you are transferring data into a CRM system. This might be a problem depending on what is triggered on CRM side (to be analyzed). Hence, I would assume that APD is waiting most of the time for CRM sytem to get things done.

    If possible, do a search for notes on CRM as target, I think performance related ones exist.

     

    Parallelization needs to split data on business partner level. If you model a "template" analysis process with an apppropriate filter, you can create copies of it and adapt the filter in each one (e.g. intervals for business partner number, or other values of BP attributes). Those copies could run in parallel.

    However, I would first check the activities happening in CRM (lots of subsequent updates for each BP maybe?).

     

    Cheers!

    Thomas

Actions