topic Re: Parallel processing and time-out in Application Development and Automation Discussions

Parallel processing and time-out

Former Member — Thu, 07 Jul 2005 15:12:56 GMT

Hi all,

I've got a prob with doing a great number of postings.

While the time elapsed for these postings is too long, I tried to do it with an function module and "IN BACKGROUND TASK". Well, there is also a alternative "STARTING NEW TASK".

But I figured out, that these both variants are starting dialog work processes. I think there is a time out for dialog WP's of 300 seconds in standard.

Will this timeout kill the processes or not??

And witch alternative is the best to do some parallel processing??

thanx in advanced

regards

Olli

Re: Parallel processing and time-out

christian_wohlfahrt — Thu, 07 Jul 2005 15:23:15 GMT

Hi Olli,

I head some problems with parallel generation of assortment list (Retail module). Here starting new task was used - and after 300 seconds time outs occurred.

Internally a synchronal 'fallback' was executed, so no harm was done - but this was explicit programming. As solution we choose different splitting parameter for the parallel execution, so that parallel tasks would need about 2-3 minutes (half the time-out time, so there was some buffer for slow system).

More commit works in parallel process will reset the timer.

It's not so good to make a low number of big portions - if a variant is ready very fast, one process will be left unused. With a higher number of packages, a dynamic distribution can use system resources more efficiently.

Normally starting new task is used - background tasks are triggered with commit work and are useful for asynchronous update of one transaction.

Regards,

Christian

Re: Parallel processing and time-out

Former Member — Thu, 07 Jul 2005 16:20:04 GMT

Hi Oliver,

Some solutions here:

1. You could increase the value of the dialog time-out (allthough this can only go to a maximum of 600 seconds). This parameter is in the SAP profiles (parameter name = rdisp/max_wprun_time).

2. As suggested by Christian, decrease the amount of work within one LUW. You can do this by inserting (from time to time) a COMMIT WORK. This COMMIT WORK also resets the timeslice counter of the running dialog process (thus giving again an extra timeslice to work). The downside is, that if you have many related objects to modify, your ROLLBACK options become limited.

3. Split the proces in several tasks and put the to work in the background (by scheduling jobs for them).

4. Program your own parallel handler (see sample code). With this you could process document by document (as if each is done separately). The number of dialog processes (minus 2) is the limit you could use.

Sample code:


* Declarations
CONSTANTS:
  opcode_arfc_noreq TYPE x VALUE 10.
DATA:
   server       TYPE msname,
   reason       TYPE i,
   trace        TYPE i VALUE 0,
   dia_max      TYPE i,
   dia_free     TYPE i,
   taskid       TYPE i VALUE 0,
   taskname(20) TYPE c,
   servergroup  TYPE rzlli_apcl.

* Parallel processes free check
CALL 'ThSysInfo' ID 'OPCODE' FIELD opcode_arfc_noreq
                 ID 'SERVER' FIELD server
                 ID 'NOREQ'  FIELD dia_free
                 ID 'MAXREQ' FIELD dia_max
                 ID 'REASON' FIELD reason
                 ID 'TRACE'  FIELD trace.
IF dia_free GT 1.
  SUBTRACT 2 FROM dia_free.
  SUBTRACT 2 FROM dia_max.
ENDIF.
* You must leave some dialogs free (otherwise no one can logon)
IF dia_free LE 1.
  MESSAGE e000(38)
     WITH 'Not enough processes free'.
ENDIF.

* Prepare your run
ADD 1 TO taskid.
WRITE taskid DECIMALS 0 TO taskname LEFT-JUSTIFIED.
CONDENSE taskname.

* Run your pay load
CALL FUNCTION 'ZZ_YOUR_FUNCTION'
  STARTING NEW TASK taskname
  DESTINATION IN GROUP servergroup
  EXPORTING
*   Your exporting parameters come here
  EXCEPTIONS
    communication_failure  = 1
    system_failure         = 2
    RESOURCE_FAILURE       = 3
    OTHERS                 = 4.

Of course you would put this within a loop and let your "payload" function fire off for each document.

You MUST check the number of free processes just before you run the payload.

And as last reminder: Do NOT use the ABAP statement WAIT (this will disrupt the counting of free processes).

Hope this will help you,

Regards,

Rob.

Re: Parallel processing and time-out

Former Member — Fri, 08 Jul 2005 07:10:38 GMT

Hi Rob, Christian, and the whole SAP world,

Thanx for your quick reply.

Do I understand the topic 2 right, that a commit work within my dialog process will reset the timeout?

So then I have no problem, because I'm doing 'BAPI_TRANSACTION_COMMIT' after each posting (I have a Monitoring transaction, and don't need to rollback all or nothing).

The alternative to start a job is not the way, because of limited number of jobs to 6 in this system. I think the other users are not happy, when I block their jobs

Thanx also for your sample code posting I will check this.

Regards

Olli

Re: Parallel processing and time-out

christian_wohlfahrt — Fri, 08 Jul 2005 08:06:43 GMT

Hi Olli!

You're right, here is short extract of commit work help:

Resets the time slice counter to 0.

An other good example for parallel execution can be found in include LWBB_HPR2F01, routine bdcp2_analysis. Corresponding transaction code is WDBU_HPR.

Regards,

Christian