FW: Container problem in parallel processing with simple forms

[Nigel Thurgood]

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.