Background task hangs until restarted by RSWWERRE

Wed Mar 21 13:52:05 EDT 2012

Hi Margaret,

Have you tried the other settings (L2 I think - I've just logged off).
Also try to add an investigative WAIT UP TO 30 SECONDS into one of the
methods, just to see if it is a locking problem.

Regards,
Mike

On Wed, March 21, 2012 3:45 pm, Hilsbos, Margaret A wrote:
> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>