Workflow duration time very high

[Former Member]

Hi all.

We have a worklfow created for invoice approval in our NW7 ECC6 ERP system.

Scanning solution from Readsoft scans, verifies and transfers the invoice documents into the ERP system, where then the workflow gets kicked off.

Sometimes a workflow instance consumes much time to complete without throwing any error message.

We activated workflow trace for some hours and loged an instance from start to its end.

that is the last line in the trace before the workflow takes "a break"

1

180

20110608070526.5626480

DATA

SWF_EXC

EXEC_START

WF-BATCH

WS90300012

0041

E

77866102

965

then the next line shows:

1

181

20110608070542.1432890

DATA

SWF_WFM

SYNC

WF-BATCH

Synchronization point reached

WS90300012

0041

E

77866097

4

In the general workflow log we can see the following for "WI update processor" task:

background work item created - time: 09:08:51 AM

background processing started (tRFC entries ......) - time: 09:08:51 AM

work item processing complete - time: 09:33:12 AM

result processing - time: 09:33:14 AM

Our assumption is, that there is a kind of resource bottleneck at the time of background processing.

We checked background processes and there are free processes all the time, also transaction SARFC shows free WPs for RFC.

Have you experienced such a strange behaviour?

I appreciate any hint from your side!

Thanks and regards

Stefan Molzen

[Former Member]

finally it was general SAP system performance.

The system was too slow to compute all workflow calls and put them on hold (maybe temporary RFC WP bottle neck for some seconds that had such a big influence on all)

Once we increased database buffer the entire DIA wp response times decreased from 800 to 500 ms and the workflow issues were goen with that.

//Stefan

[Former Member]

Hi Stefan

In workflow log, check the workitem where wf stucks. Then, go to tcode SWDD and search in WS90300012 which BO and method use the task that you detected in the log. Now in tcode SWO1 test the method and compares the time that it takes.

Regards,

[Former Member]

Hello Enrique.

I checked the task in the workflow builder but there is no method maintained for that specific step.

Kind regards

Stefan Molzen

[Former Member]

Hello

We found nothing that helped in resolving the issue.

We found only that the worflow item processing gets delayed for unknown reasons.

And it gets kicked off again by a repeatitive job that runs in the system with report: RSWWERRE

exmaple job log

29.06.2011 10:50:26 Step 001 started (program RSWWERRE, variant &0000000000002, user ID WF-BATCH)

29.06.2011 10:50:28 Starting Background Steps in Status "Being Processed"

29.06.2011 10:50:28 ==> 0 background steps started

29.06.2011 10:50:28 ==> 0 error(s) occurred ( > see application log)

29.06.2011 10:53:10 Starting Work Items in Status "Ready"

29.06.2011 10:53:10 ==> 15 background steps started

The report is for temporary workflow issues as far as I could read in the documentation.

But still we don´t know why the temporary error occures and what the error is.

Does someone maybe know where to look for in this strange issue?

Thanks and regards

smolzen

[Eddie_Morris]

Hi,

Please check the work items in error and you should see an error message in the technical workflow log. Try transaction SWI2_DIAG for work items in error or while in SM58 double click on the Transaction ID and it might give the Work item ID. The look at this work item ID via SWI1.

Regards,

Eddie

[Former Member]

Hello Eddie.

That is the strange thing: There is not error in a work item. The entire workflow instance is without any error.

At some point the workflow instance gets stuck and needs the report I wrote to kick it off again.

Any suggestion is welcomed

Thanks an dregards

Stefan

[Eddie_Morris]

Hi Stefan,

If there is no error them it is unlikely that the work items are in error and that RSWWERRE are restaring them. Why do you think RSWWERRE is restarting them? If there is a temporary error then they may be out in SM58 without status Error...if this is the case then maybe look at what user is the triggering user.....they could be missing authorisations which causes a temp error. When RSWWERRE runs (With user WF-BATCH) it restarts the work item as it has full authorisation.......this is just a guess.

The issue could be that there is not enough resources to execute them and they are temporarily put in SM58 and then reprocessed when there are resources. What is in the status text in sm58? Is it Transaction Recorded?

Regards,

Eddie

[Former Member]

Hi Eddie

Why do you think RSWWERRE is restarting them?

Because the time when the stucked workflow instance continues is exactly the same of the report RSWWERRE

  If there is a temporary error then they may be out in SM58 without status Error...

Unfortunately no entries in SM58

 ... if this is the case then maybe look at what user is the triggering user.....they could be missing authorisations which causes a temp error.

The temporary error occures for all users (at least it seems so). For normal human users, but also for our background user with SAP_ALL and SAP_NEW authorizations.

 When RSWWERRE runs (With user WF-BATCH) it restarts the work item as it has full authorisation.......this is just a guess.

Right, WF-BATCH has also SAP_ALL

 The issue could be that there is not enough resources to execute them and they are temporarily put in SM58 and then reprocessed when there are resources. What is in the status text in sm58? Is it Transaction Recorded?

That is what my assumption is, too. Temporary too few resources of some kind.

Once the workflow instance is stucked, no entry in SM58 is visible, unfortunately.

... please keep in mind that we haven´t regsitered the workflow RFC destination yet, I am still checking the SAP note which has been noted down earlier in this thread. Do you think it could help us to register the WORKFLOW_LOCAL_XXX destination?

I kow, strange issue. Sorry for that.

Any suggestion is welcomed.

Thanks and regards

Stefan Molzen

[Eddie_Morris]

Hi Stefan,

If you unschedule RSWWERRE do the items remain in SM58?

Are the work item related to a specific workflow or are they across all workflows?

Is the Status Text in SM58 = Transaction Recorded or something else?

If the entries are related to all work items, events in the system then the problem is with resources or some hold up in execution...maybe some RFC paramters need adjusting (I am no RFC expert but note 74141 gives information on RFC resources).

Registering in SMQS could help or make things worse....When you register all transaction will be queued so if you have a delay in execution or incorrect RC parameters then the entries in SM58 could start to build up. I would try to sort out the current issue first ebfore even looking at SMQS.

Regards,

Eddie

[Former Member]

Hi Eddie

 If you unschedule RSWWERRE do the items remain in SM58?

There are no entries in SM58. But if I unschedule the job the workflow instances remain in the "temporary error status" and don´t get kicked off again.

 Are the work item related to a specific workflow or are they across all workflows?

We don´t have so many workflows (I only know of 1). I cannot tell you an answer on that question.

 Is the Status Text in SM58 = Transaction Recorded or something else?

There are no entries in SM58

 If the entries are related to all work items, events in the system then the problem is with resources or some hold up in execution...maybe some RFC paramters need adjusting (I am no RFC expert but note 74141 gives information on RFC resources).

I checked RFC resources of all servers and found that from time to time the quota for RFCs gets exceeded. I will contact our hosting partner and ask for parameter review.

 Registering in SMQS could help or make things worse....When you register all transaction will be queued so if you have a delay in execution or incorrect RC parameters then the entries in SM58 could start to build up. I would try to sort out the current issue first ebfore even looking at SMQS.

Agree

Thanks an dregards

Stefan Molzen

[Eddie_Morris]

Hi Stefan,

Sorry for assuming the entries were in SM58.

Regarding the object method executed in the work item or work items...what object method is being executed? If this is executed via SWO1 does it execute immediately or does it take some time? Are there any temp exception raised when you

execute the method vai SWO1?

Regards,

Eddie

[former_member185167]

Hello,

It sounds to me like you are having a locking problem. I would check the workflow log again, use the technical view.

You could run RSWWERRE more often but best to find the root cause; insertion of a Wait step may help.

regards

Rick Bakker

hanabi technology

[Eddie_Morris]

Hi,

Have you registered WORKFLOW_LOCAL_XXX in SMQS? Is this queueing the transaction in SM58 and therefore causing the delay in execution. If this is the case then you may want to commit more resources to this e.g. increase Max Conn or add resources to the AS Group used in SMQS.

Regards,

Eddie

[Former Member]

Hi all

@Sanju: SWU3 shows not all green, but the relevant things have been done.

@Enrique: I must admit I don´t know exactly how to check that. Can you outline a bit please?

@Eddie: No, WORKFLOW_LOCAL_XXX RFC hasn´t been registered in the scheduler yet. Sometimes SM58 contains 5-10 workflow related entries (in status Transaction executing) and they stay there for approximately 1-2 minutes and disappear afterwards. Do you think the registering could help? I found SAP note 888279 and will read it carefully in the meantime.

Thanks and regards

Stefan Molzen

Edited by: Stefan Molzen on Jun 15, 2011 11:07 AM

[Former Member]

Hi,

When you update, do you use COMMIT WORK?

Regards,

[Former Member]

Hi,

Please check whether the SWU3 is configured properly or not.

Thanks and regards,

SNJY