Container problem in parallel processing with simple forms

Thu May 3 06:49:56 EDT 2007

Hi Nigel,
OK, it was the latter, I re-read your post ... you mentioned "container
structure element 'B'" which I interpreted as one structure with two
fields A and B and that stuck in brain for the rest of your posting even
though you did describe it correctly.

Anyhow, it looks like the form step reads and writes the whole container.
To me this is an obvious OSS. On the other hand, I've always found forms a
bit limited for all but the most basic tasks - nevermind that they're on
the endangered species list of SAP technologies. It should take an ABAPer
an hour or two to write a function module with a dialog to replace the
form with something far more customizable and reusable. Probably less time
overall than the OSS route if this is your only scenario where this is
happening.

Oh and by the way, South Africa and Peru are also on Southern Hemisphere
time, but they're about 8 and 15 hours behind :-)

Cheers,
Mike

On Thu, May 3, 2007 12:23 am, Nigel Thurgood wrote:
> Thanks for replying Mike.
>
> Unfortunately either I didn't explain clearly enough or you misinterpreted
> the problem - I'll assume it was the former (smiley thing).
>
> Scenario is:
>
> Two parallel branch fork, each fork containing a simple form ('Change'
> form).
>
> First branch / form references container structure 'Australia'
>
> Second branch /form references container structure 'NewZealand'.
>
> NOTE THAT THESE ARE SEPARATE CONTAINER STRUCTURES.
>
> Australian agent opens the Australian form, and BEFORE HE HAS SAVED HIS
> CHANGES, New Zealand agent opens the New Zealand form.
>
> Australian agent saves and closes the Australian form.
>
> New Zealand agent saves and closes the New Zealand form.
>
> The workflow log shows that only container structure New Zealand has any
> data set in it. This is because the Australian changes were reset when the
> New Zealand form was saved.
>
> You've earnt yourself an early mark, or I'm missing the bleeding obvious
> somewhere. I hope it's me, as this means mucho changes to my workflows.
>
> Note that this is a real-life scenario. The workflow (create material
> master record) determines whether the material is for Australia, New
> Zealand, or both. If both, then a task is sent to both country's agents.
> The problem only occurs when both tasks are open (and not saved) at the
> same time. At first I supposed this would be a one in a thousand happening
> (still too many!), but in fact the scheduled RSWUWFML2 sends both agents a
> 'You have new work items' email with logon icon, and both being keen as
> mustard, the tasks are opened pretty much simultaneously and this causes
> the conflict.
>
>>From what I can gather, and I need to look at this in more detail, when
>> the task starts, the entire container, including Australia AND New
>> Zealand and other elements and structures, is read into field
>> GT_CONTAINER.
>
> Australia then makes changes to the Australia form and saves. The
> Australia structure of the gt_container is updated by the local Australia
> structure. Note that the New Zealand structure, blank at the outset,
> remains blank.
>
> New Zealand then makes changes to the New Zealand structure and saves. The
> New Zealand structure of the gt_container is updated by the local New
> Zealand structure. Note that the Australia structure, blank when the New
> Zealand step commenced, becomes blank again.
>
> Thus the Australia changes are overwritten (or more accurately 'cleared').
>
> If you wish, I can send screen shots of all the above . I've written a
> dummy workflow to debug this problem, with just a fork, two form steps and
> a start transaction.
>
> Cheers.
>
> Nigel.
>
>
>
>
> -----Original Message-----
> From: Mike Pokraka [mailto:asap at workflowconnections.com]
> Sent: Wednesday, 2 May 2007 9:09 PM
> To: SAP Workflow Users' Group
> Subject: Re: Container problem in parallel processing with simple forms
>
>
> Hi Nigel,
>
> This is neither a problem nor a limitation but works correctly as I'd
> imagine it would.
>
> It *should* always update the entire structure including elements A B C D
> E and whatever else, otherwise we might as well all go home right now.
> Updates always update an entire row, that's how databases work. It would
> be disastrous if it worked differntly!
>
> Your only solution is to use speparate structures / container elements for
> the two agents.
>
> Cheers,
> Mike
>
>
>
> On Wed, May 2, 2007 1:44 am, Nigel Thurgood wrote:
>> Scenario is a fork with 2 branches, each branch contains a simple form
>> step. Branch A form changes container element structure 'A', branch B
>> form
>> changes container structure element 'B'.
>>
>> *     Agents A and B open forms A and B simultaneously, then the
>> GT_CONTAINER
>> for both forms has both structures A and B blank.
>> *     Agent A enters data on form and presses 'Save';
>>
>> *     Function SWY_STRUCTURE_TO_CONTAINER firstly calls function
>> SWY_GET_CONTAINER, which loads a local copy of blank structures A and B
>> from GT_CONTAINER (ie as at when the form was opened);
>> *     The container element name ('A')  is sourced, and then
>> SWC_SET_ELEMENT
>> updates structure A of the local container;
>> *     SWC_SET_CONTAINER then updates GT_CONTAINER with the local
>> container.
>>
>> *     Agent B enters data on form and presses 'Save';
>>
>> *     SWY_GET_CONTAINER loads local copy of blank structures A and B (ie
>> as at
>> when the form was opened);
>>
>> *     The container element name ('B') is sourced, and then
>> SWC_SET_ELEMENT
>> updates structure B of the local container;
>> *     SWC_SET_CONTAINER then updates GT_CONTAINER with the local
>> container.
>>
>> *     End result is that Agent A / form A changes are overwritten.
>>
>> Apologies if this has been vovered before / is a know problem /
>> limitation. Any advice would be appreciated.
>>
>> Best regards.
>>
>> Nigel E Thurgood
>>
>> Senior Application Specialist
>> Sanitarium Health Food Company
>>
>> Phone: (02) 4349-6019
>> Mobile: 0416 254919
>>
>> This is an email from Australian Health & Nutrition Association Limited,
>> ABN 63 096 452 872 trading as Sanitarium Health Food Company.
>>
>> THIS E-MAIL IS CONFIDENTIAL.
>> Any recipient who is not the intended recipient is requested to
>> notify the sender by return e-mail and erase all copies of the message
>> and attachments. The sender cannot guarantee that this email or any
>> attachment to it is free of computer viruses or other conditions which
>> may
>> damage or interfere with data, hardware or software with which it might
>> be
>> used.
>>
>> If you do not wish to receive commercial email messages from Sanitarium
>> Health Food
>> Company, please send an unsubscribe message to the sender of this email,
>> or contact
>> unsubscribe at sanitarium.com.au.
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>
>
> --
> Mike Pokraka
> Senior Consultant
> Workflow Connections
> Mobile: +44(0)7786 910855
> This is an email from Australian Health & Nutrition Association Limited,
> ABN 63 096 452 872 trading as Sanitarium Health Food Company.
>
> THIS E-MAIL IS CONFIDENTIAL.
> Any recipient who is not the intended recipient is requested to
> notify the sender by return e-mail and erase all copies of the message
> and attachments. The sender cannot guarantee that this email or any
> attachment to it is free of computer viruses or other conditions which may
> damage or interfere with data, hardware or software with which it might be
> used.
>
> If you do not wish to receive commercial email messages from Sanitarium
> Health Food
> Company, please send an unsubscribe message to the sender of this email,
> or contact
> unsubscribe at sanitarium.com.au.
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>

-- 
Mike Pokraka
Senior Consultant
Workflow Connections
Mobile: +44(0)7786 910855