Background task hangs until restarted by RSWWERRE
Hilsbos, Margaret A
Margaret.Hilsbos at dayzim.com
Wed Mar 21 11:45:29 EDT 2012
Hi Mike,
Unfortunately that setting didn't fix the 'forking' problem. I wonder if it's because it's a fork inside a fork? Oh and we have loops and other fun stuff in this workflow.
I appreciate your thoughts on the question of one workflow vs. multiple. I've been having that philosophical discussion in my head for a while, particularly with THIS workflow. I agree that it's generally less confusing to keep everything in one place.
Any other suggestions? Otherwise I'll just get the forking RFC fixed and be done with it. ;-)
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 10:56 AM
To: SAP Workflow Users' Group
Subject: RE: Background task hangs until restarted by RSWWERRE
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
>
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
More information about the SAP-WUG
mailing list