Background task hangs until restarted by RSWWERRE

Tue Mar 20 10:55:59 EDT 2012

I for one would agree with you that one workflow is simpler. Easier to
troubleshoot as all related functionality is in one place, and if
dependencies ever surface it's easier to enhance.

Regards,
Mike

On Tue, March 20, 2012 12:52 pm, Hilsbos, Margaret A wrote:
> Thanks Mike! That should do it. I'll test it out today. The workflow is
> running fine in our production system - no RFC problem there - but it will
> be nice to have this setting corrected in case an RFC connection ever
> breaks, then the other steps will then continue to work correctly, meaning
> less cleanup after the connection is fixed.
>
> Thanks also to Rick, Joerg, Sree for your suggestions.   Rick, the steps
> are in a fork because they're independent of each other at that point.
> They're in the same workflow because they use data gathered previously in
> the workflow. It's occurred to me that I might have simplified the main
> workflow by just raising an event to trigger a standalone workflow for
> each of these branches. But I guess 'simpler' overall is in the eye of the
> beholder, so I won't rework it just for that.
>
> Joerg, I checked SMQS and added the workflow_local as you suggested, but
> that didn't fix it. I found some other problems in the RFC connection (to
> another system, not the workflow_local) that I'm still working to resolve.
>
> Sree, you are right, but as these steps are logically independent, ideally
> we'd like the parallel steps to proceed even if the RFC connection in one
> branch fails. The setting Mike identified should do that. Which makes this
> one of those unplanned 'tests' that's great to have happen in a test
> environment before it happens in production!
>
> Margaret
>
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Mike Pokraka
> Sent: Tuesday, March 20, 2012 5:09 AM
> To: SAP Workflow Users' Group
> Subject: Re: Background task hangs until restarted by RSWWERRE
>
> Hi Margaret,
>
> Bit of a forking problem you've got there.
>
> Workflow header -> version dependent tab -> locking properties subtab.
> Set it to LB / Lock behaviour for background workflows
>
> The lock in this case is the WF steps trying to lock the entire WF to do
> what they do (good for dialog WFs). The setting above changes it to a more
> performance-friendly flavour that only lock what it needs to (good for
> background, but not ideal for mutliple users doing stuff at the same
> time).
>
> Regards,
> Mike
>
> On Fri, March 16, 2012 5:54 pm, Hilsbos, Margaret A wrote:
>> Well, this is interesting. We added some steps to a workflow that
>> we've been using for a long time now.  Everything worked fine when we
>> tested our changed workflow in our development system. Now in our QA
>> system, the workflow hangs at the new steps (which are in a fork
>> because they are independent of each other, and independent of the
>> previously existing steps). The two steps that hang are instantiations
>> of class-based objects.
>> This is my first use of ABAP OO classes as object instances in a
>> workflow (been using utility methods for a while now). It took me a
>> couple whacks to get everything working fine in Dev, but it was
>> working and not hanging, so I wouldn't think anything about the class
>> is the problem.  Also, if I test the class methods in SE24, everything
>> works fine.
>>
>> Here's the step history in Dev for one of the steps - total time 2s:
>> Workflow System           Background work item created
>> 03/12/2012 15:51:39
>> Workflow System           Execution started automatically
>> 03/12/2012 15:51:39
>> Workflow System           Work Item Processing Complete
>> 03/12/2012 15:51:40
>> Workflow System           Result Processing
>>          03/12/2012 15:51:41
>>
>> Here's the step history for the same step in QA, with a similar object
>> - total time about 27 minutes!:
>> Workflow System            Background work item created
>> 03/16/2012 10:08:38
>> Workflow System            Execution started automatically
>> 03/16/2012 10:08:38
>> Workflow System            RSWWERRE
>>           03/16/2012 10:35:07
>> Workflow System            Work Item Processing Complete
>> 03/16/2012
>> 10:35:08
>> Workflow System            Result Processing
>>        03/16/2012 10:35:08
>>
>> The two new steps are similar and are parallel in a three-way fork
>> with another step that wasn't touched for this change, other than to
>> move it into the fork. However, due to other changes on the QA box
>> which hosed an RFC connection, the old step is hanging too, but for
>> purposes of our test I just manually complete that one.  (I'll get the
>> RFC problem fixed later, I promise.)  I wouldn't think the steps in
>> parallel would care about the RFC step in another branch hanging, but
>> ... any other ideas?
>>
>> Since this process isn't time critical and RSWWERRE is restarting it
>> soon enough, we'll probably move it forward even if we don't figure
>> out why it's doing this. I just wondered if anyone has any ideas why
>> this might be happening?
>>
>> Oh, and everything was transported yesterday, and I started testing
>> today, and did SWU_OBUF "just because" anyway, but of course that didn't
>> help.
>>
>> Thanks in advance for any suggestions!
>>
>> Margaret
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>