Enqueue Errors - ECC 6.0

[Mike Pokraka]

Andy,

Excellent info, thanks! I did wonder what exactly the locking parameters
did, so this is one for my 'useful posts' archive :)

Cheers,
Mike


On Thu, February 25, 2010 5:43 pm, Catherall, Andy wrote:
> All
>
> An update on an ancient thread.
>
> I had opportunity to talk to an SAP webflow developer the other week (ie
> someone who builds the actual webflow engine) and got some insights into
> the enqueue issue.
>
> To summarise my problem:
> In the move from 4.6c to ECC6, workflows appear to have lost a degree of
> their 'event handling' abilities. Yes, we can capture events all over
> the place now; and we can raise local events too.. but, the enhanced
> enqueing means that a workflow will not necessarily respond to that
> event at the time that it is raised.
> This might be due to the workflow being locked to activities going on in
> other branches of a fork, for example.
>
> Worse, it will not necessarily then respond to that event at the
> earliest possible opportunity after the event has been raised. You might
> expect that when the work item [that was locking the workflow]
> completed, the webflow engine would review the overall status of the
> workflow before the next step was started, and recognise that an
> applicable event had been received elsewhere in the workflow, and
> therefore not move on to the next step. But it does not do this.
>
> Instead, we have to wait for RSWWERRE to run, periodically, and try to
> re-present the event every so often. If the workflow is busy again, the
> event is put back on the queue for later. In the meantime, the rest of
> the workflow can merrily continue, oblivious to the event effectively
> knocking at its door.
>
> Instead of the workflow using the event as an interrupt, so that it
> responds in a timely manner to activities that are going on within the
> wider SAP system, the 'event' has become a rather ineffective, delayed,
> tool, which cannot be relied upon to ensure that no-longer-relevant
> steps are not shown to users.
>
> This particular issue was having quite an effect on a number of my
> workflows that rely upon events to guide their behaviour.  Whilst I'm
> not out of the woods yet, I have made some progress.
>
> The lesson
> The lesson I received, then, was with respect to the various settings,
> on the 'Locking Properties' tab, on the 'Control' tab, of the 'Version
> Dependent' tab(!), of the workflow header. I have struggled to find
> information on what the various options do.
> The great lesson was that the 'old' 4.6c way of operating is effectively
> embodied in L3. This will cause the lock to be taken only at the point
> where the step is transitioning to or from the workflow - at the point
> where the containers are being updated, for example. This means that a
> wait-for-event step can now respond to the event, and can now updated
> the workflow that it lives in. It can now cause the fork & the workflow
> to complete! Fantastic.
>
> The L2 and L1 options are similar, but only cause the locks to be
> released during tasks of type W and B, as applicable.
>
> Testing continues, but I thought I'd share this.
>
> Thanks
> Andy
>
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Catherall, Andy M
> Sent: Friday 14 November 2008 15:47
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
> Hi Sue
>
> Thanks for the info. Can I just check some aspects, as what I am seeing
> seems subtly different.
>
> 1) The main fork has a couple of dialog tasks. However, the other branch
> of the fork only has a 'wait-for-event' followed by a background-step,
> not a dialog task.
> 2) The error in the log is being reported against the 'wait for event'
> step. It is failing to complete due to us having a lock on the workflow.
> 3) The next step to be created is the subsequent dialog step in the main
> fork. Following the thread below, we turned off 'Advance with dialog'
> days ago.
> 4) Whilst the workflow at large, and even the WFE work item, do not go
> into error, several moments (sometimes over an hour) later, the WFE
> finally completes and the fork terminates. We suspect the 'reprocess
> errored workitems' job, but the varying delay has us confused.
>
> We've run several tests around this, and it seems to be consistently the
> case that a 'wait for event' cannot respond to an event if a user
> happens to still be in the work item (which, as this is now a racing
> issue, may well be the case).
>
> This seems to be a major flaw, but I guess there must be some
> alternative approach, as the community at large does not appear to be
> making much noise about this. Are we being forced down the route of
> capturing events at the WF header level? Does this even work, if the
> workflow is still locked anyway?
>
> Our next test is to see if the WFE completes when it is the only task in
> a subflow (and that subflow positioned in place of the WFE in the fork).
> It seems rather bizarre if this approach works!
>
>
> Thanks for any advice anyone can give, and have a good weekend!
>
> Cheers
> Andy
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Sue Doughty
> Sent: Wednesday 12 November 2008 14:44
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
>
> Hi Andy,
>
>
>
> You can only have one dialog task in one path of a fork.  What we had to
> do was to create sub-workflows for all but one of the dialog tasks in
> the fork.  That was a big project to go into all workflows and make that
> change.
>
>
>
> The waiting on events in parallel forks will work....you just cannot
> have a dialog task under the wait step.  If you make your dialog task
> underneath the event a sub-workflow, then your events will work fine.
>
>
>
> SAP was adamant that it was working as designed and would not consider
> modifying it.
>
>
>
> Regards,
>
> Sue T. Doughty
>
> SAP Workflow Specialist
>
> Old Dominion Freight Line, Inc.
>
> 500 Old Dominion Way
>
> Thomasville, NC 27360
>
> Phone:  (336) 822-5189
>
> Toll Free (800 ) 432-6335, ext. 5189
>
> Email:  sue.doughty at odfl.com
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Catherall, Andy M
> Sent: Wednesday, November 12, 2008 6:36 AM
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
>
> All
>
>
>
> Context
>
> -----------
>
> We have recently started making changes to a workflow in ECC6. The
> original design existed in our 4.6c system and has worked for years. As
> the SAP instance was upgraded, the workflow remained. We have then
> copied this workflow in ECC6, and are developing on the copy.  The
> workflow handles parked MM invoices.
>
>
>
> Issue
>
> --------
>
> This workflow has a main fork, and two parallel forks. These parallel
> forks handle the BUS2081-POSTED and BUS2081-DELETED events. The main
> fork allows the user the opportunity to resolve the issues with the
> invoice and Post it (if complete) or save it (if still awaiting more
> information). There is an 'advance with dialog' step immediately after
> the invoice edit step, which raises a pop-up to confirm with the user
> that they *did* mean "save", didn't they...?
>
>
>
> Of course, if they selected "POST", we are expecting the posted event to
> be raised (which it is), and for the other fork of the workflow to kick
> in (as it used to do), and for some tidy-up and completion to occur
> (which is not happening due to the locked workflow), and hence for our
> main fork to be terminated as the workflow ends (but, as it is not
> ending, the main fork continues...).
>
>
>
> Based on the conversations below, it sounds like there is a fundamental
> design paradigm shift - we can't have parallel forks waiting to respond
> to event based on the users' actions, because the main fork will have
> locked the workflow anyway. I take it this can't also be true for the
> 'new' header-level event handling??
>
>
>
> Given that the discussion below occured several months ago, has the
> debate or approach moved on? Is there now an updated view regarding
> 'best practice' design for this sort of functionality?
>
>
>
> Many thanks
>
> Andy
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Sue Doughty
> Sent: Tuesday 25 March 2008 13:07
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
> We are on ECC 6.0.  I have a new issue with the Enqueue errors.
>
>
>
> We have workflows using Webservice to pass around a form via workflow
> for approval and processing.  After the form has been processed, I have
> a notification fork which sends a workflow (via a sub-workflow) with a
> copy of the form that certain departments need to view - it could be one
> or up to four sub-workflows.  Also in the fork is a background process
> (via a sub-workflow) that checks the TOA01 table (via a method in the
> BUS1065 BO) to insure that the image was stored with the employee
> record.  The first step waits for 30 seconds and then checks every 10
> minutes for 30 minutes before sending a notification to the Workflow
> group if it fails to find it.
>
>
>
> The problem is that as soon as the sub-workflow for the checking of the
> TOA01 table starts, all of the other sub-workflows in the fork will not
> continue until that sub-workflow finishes.  I get an error that the work
> item number of the main workflow (top level) is locked by user WF-BATCH
> (enqueue error).
>
>
>
> I thought that as long as I was executing sub-workflows, I would not get
> the enqueue errors.  Am I missing something?
>
>
>
> Regards,
>
> Sue T. Doughty
>
> SAP Workflow Specialist
>
> Old Dominion Freight Line, Inc.
>
> 500 Old Dominion Way
>
> Thomasville, NC 27360
>
> Phone:  (336) 822-5189
>
> Toll Free (800 ) 432-6335, ext. 5189
>
> Email:  sue.doughty at odfl.com
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Sue Doughty
> Sent: Tuesday, October 23, 2007 10:11 AM
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
>
> Hi Mike,
>
> I've moved two of the three decisions and the call to PA40 into a sub
> workflow and now all three branches of the fork can now be completed.
>
> I replied back to OSS stating that I felt like it was not working
> correctly and this is their response.....they will NOT do anything about
> it and suggested, as you did, to do sub workflows:
>
> thank for your response as well, and of course your valuable input
>
> is always appreciated. Nevertheless we have now reached a level,
>
> where you put into question the fundamental design / architecture
>
> of the workflow runtime system.
>
> An important feature of the workflow runtime system are so-called
>
> "synchronous process chains" (advance with dialog), i.e. if there
>
> is a sequence of dialog steps to be processed by the same user,
>
> they are executed as one chain without going to the inbox in between.
>
> A pre-requiste for this is the lock on the father workflow during
>
> the entire process chain.
>
> workflow F_______________________________
>
> ^ | ^ | ^
>
> | | | | |
>
> task ___W1___| v___W2___| v___W2___|
>
> ----------------------------------------------> time
>
> In your case there are two of such process chains, which collide
>
> because they are in parallel branches of a fork.
>
> I talked again to my boss, who is not only development manager
>
> but in this case also the responsible developer. He definitely
>
> sees no room for tolerance here.
>
> On the other side there should be a workaround by embedding the
>
> individual branches into subflows, because only the direct father
>
> and not the top-level workflow is locked. Hope this helps.
>
> Mike, I really appreciate your help in this!!
>
> Regards,
>
> Sue T. Doughty
>
> SAP Workflow Specialist
>
> OLD DOMINION FREIGHT LINE, INC.
>
> 500 Old Dominion Way, Thomasville, NC 27360
>
> Toll Free :(800)432-6335, ext.5189
>
> Phone :(336)822-5189 Fax :(336)822-5149
>
> sue.doughty at odfl.com
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Mike Pokraka
> Sent: Tuesday, October 23, 2007 9:47 AM
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
> OK, as I understand it:
>
> User A in one branch executes a decision and is advanced to the next
> step,
>
> which is a transaction.
>
> Before user A completes the txn, user B executes a decision in another
>
> branch followed by another unrelated action. This fails because user A
> has
>
> locked the WF.
>
> If I've understood this correctly then I'd call that a big fat bug. I
>
> would suggest replicating this in a test WF in it's simplest form - does
>
> it do the same without the decisions (i.e. just two PA40's in parallel
>
> branches)? What if you use transactions other than PA40 in both
> branches?
>
> Simplify as far as possible and send it back to OSS. (and let us know
> the
>
> outcome).
>
> Cheers,
>
> Mike
>
>
>
> On Tue, October 23, 2007 12:36 pm, Sue Doughty wrote:
>
>> Hi Mike,
>
>>
>
>> Thanks for your response.
>
>>
>
>> It is a standard call to PA40.
>
>>
>
>> Hi Mike,
>
>>
>
>> Thank you for your response.
>
>>
>
>> It is a standard call to PA40.
>
>>
>
>> I agree...a task should NOT lock the TOP level workflow.
>
>>
>
>> I did what you said and got the PA40 up and then tried to execute
>
>> another branch doing something different.  It still locks the workflow
>
>> at the top level.
>
>>
>
>> I will try moving the decisions out into the sub workflow and see if
>
>> that changes things.
>
>>
>
>> Regards,
>
>> Sue T. Doughty
>
>> SAP Workflow Specialist
>
>> OLD DOMINION FREIGHT LINE, INC.
>
>> 500 Old Dominion Way, Thomasville, NC 27360
>
>> Toll Free :(800)432-6335, ext.5189
>
>> Phone :(336)822-5189 Fax :(336)822-5149
>
>> sue.doughty at odfl.com
>
>> -----Original Message-----
>
>> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf
>
>> Of Mike Pokraka
>
>> Sent: Tuesday, October 23, 2007 4:46 AM
>
>> To: SAP Workflow Users' Group
>
>> Subject: RE: Enqueue Errors - ECC 6.0
>
>>
>
>> Hi Sue,
>
>>
>
>> OK, so that changes the picture a little. Regarding subWF, you should
>
>> try
>
>> putting the entire user dialog chain into the subwf - i.e. the
> decision
>
>> and the PA40.
>
>>
>
>> I've had similar probs where a lock would cause a similar error and
> the
>
>> error monitoring job would pick it up - as per the OSS response.
> However
>
>> I
>
>> am also not convinced this is right. Is this s standard "Call
>
>> transaction
>
>> PA40" type of method or does the code do something strange?
>
>>
>
>> A task should NOT lock the top level workflow. That defeats the whole
>
>> point of parallel execution. Yes there can problems if you and up with
>
>> two
>
>> branches joining at the same time and racing for the next step but a
> WF
>
>> should definitively be able to execute two steps in parallel otherwise
>
>> we
>
>> can all go home. Here's another test: when one user locks PA40, try to
>
>> execute something else in the other branch after the decision - or a
>
>> PA40
>
>> on a different employee - in other words something that works. If that
>
>> also fails then I say it's rubbish design that needs to be fixed.
>
>>
>
>> Cheers,
>
>> Mike
>
>>
>
>>
>
>> On Mon, October 22, 2007 9:10 pm, Sue Doughty wrote:
>
>>> Hi Mike,
>
>>>
>
>>> I changed the PA40s to subworkflows.
>
>>>
>
>>> I executed the workflow again and tried to execute the decision tasks
>
>>> (which call the PA40 subworkflow).
>
>>>
>
>>> It is still giving me an enqueue error on the Decision step at the
>
>>> INSTANCE level if more than one fork is executed at a time.  It seems
>
>>> like it is telling me that only one path of the fork can be executed
>
>> at
>
>>> a time.  If two people try to execute two different paths, it will
> get
>
>> a
>
>>> locking error.  It is two difference paths of a fork and two separate
>
>>> decision steps.
>
>>>
>
>>> This can't be the way it is supposed to work!
>
>>>
>
>>> Regards,
>
>>> Sue T. Doughty
>
>>> SAP Workflow Specialist
>
>>> OLD DOMINION FREIGHT LINE, INC.
>
>>> 500 Old Dominion Way, Thomasville, NC 27360
>
>>> Toll Free :(800)432-6335, ext.5189
>
>>> Phone :(336)822-5189 Fax :(336)822-5149
>
>>> sue.doughty at odfl.com
>
>>>
>
>>> -----Original Message-----
>
>>> From: Sue Doughty
>
>>> Sent: Monday, October 22, 2007 11:28 AM
>
>>> To: 'SAP Workflow Users' Group'
>
>>> Subject: RE: Enqueue Errors - ECC 6.0
>
>>>
>
>>> Hi Mike,
>
>>>
>
>>> Thanks for responding.
>
>>>
>
>>> There is a decision task.  They can click to print forms or if they
>
>> want
>
>>> to do the action in PA40, they click "Execute Payroll (or whatever)
>
>>> followup action".  The task that gets executed is a call to PA40.
>
>>>
>
>>>
>
>>> Regards,
>
>>> Sue T. Doughty
>
>>> SAP Workflow Specialist
>
>>> OLD DOMINION FREIGHT LINE, INC.
>
>>> 500 Old Dominion Way, Thomasville, NC 27360
>
>>> Toll Free :(800)432-6335, ext.5189
>
>>> Phone :(336)822-5189 Fax :(336)822-5149
>
>>> sue.doughty at odfl.com
>
>>>
>
>>> -----Original Message-----
>
>>> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
>
>> Behalf
>
>>> Of Mike Pokraka
>
>>> Sent: Monday, October 22, 2007 9:39 AM
>
>>> To: SAP Workflow Users' Group
>
>>> Subject: Re: Enqueue Errors - ECC 6.0
>
>>>
>
>>> Hmmm, my first thougt was that this is complete nonsense from OSS.
>
>>> Then I notice that they talk about a decision task. So, now I think
>
>>> we're
>
>>> missing a piece of info here - is this a decision or a PA40?
>
>>>
>
>>> A possible workaround may be to put the PA40's into a subWF. It may
>
>> only
>
>>> lock the subworkflow. On the other hand it may also be a case of
>
>>> rejecting
>
>>> SAP's response - depending on this mystery decision task that is
> PA40.
>
>>>
>
>>> Cheers,
>
>>> Mike
>
>>>
>
>>>
>
>>> On Mon, October 22, 2007 1:26 pm, Sue Doughty wrote:
>
>>>> We are in the process of upgrading from 4.7 to ECC 6.0.
>
>>>>
>
>>>>
>
>>>>
>
>>>> We have a New Hire workflow that has a fork with three branches.
>
>> Each
>
>>>> branch goes to a different department and they all have a work item
>
>>> that
>
>>>> executes PA40 where they execute a specific action for the employee.
>
>>>>
>
>>>>
>
>>>>
>
>>>> In 4.7, if two departments happened to hit the same employee at the
>
>>> same
>
>>>> time, the second department trying to execute the work item would
> get
>
>>> an
>
>>>> error in PA40 - Employee is being processed by ######.  They would
>
>>>> cancel out and come back later.  The work item would remain in their
>
>>>> in-box.
>
>>>>
>
>>>>
>
>>>>
>
>>>>
>
>>>> In ECC 6.0, the workflow gets an ENQUEUE error - Error when loading
>
>>>> component: Work item 000000638111 locked (action FIND_FLOWITEM) and
>
>>> then
>
>>>> Work item 000000638111 locked by user E050889 (enqueue error)
> (action
>
>>>> FIND_BY_WIID_BY_WFM)
>
>>>>
>
>>>>
>
>>>> The error is referencing the Workflow INSTANCE, not the work item
>
>>> being
>
>>>> executed.  The work item for the second user is then set to Complete
>
>> -
>
>>>> it never takes them to PA40.  They have no way of going back in
> later
>
>>>> and executing the action.
>
>>>>
>
>>>>
>
>>>>
>
>>>> I opened a note with SAP and was told that it is working as
> designed.
>
>>>> See SAP's response below:
>
>>>>
>
>>>>
>
>>>>
>
>>>> Here the lock did not occur during work item execution, but after
>
>>>> execution during
>
>>>> the so-called "callback", because the corresponding workflow (father
>
>>>> work item) was locked. In such a case the work item (user decision)
>
>>>> is COMPLETED and the workflow is suspended. Especially the so-called
>
>>>> "synchronous process chain" (advance with dialog) is interrupted
>
>>>> unless SWWERRE puts the subsequent work item (PA40) into the inbox
>
>>>> of the user concerned.
>
>>>>
>
>>>> According to our development manager this works as designed.
>
>>>>
>
>>>>
>
>>>>
>
>>>>
>
>>>>
>
>>>> I am at a loss as to how to fix this problem.  I don't want to take
>
>>> out
>
>>>> the fork and have the departments execute the PA40 action one after
>
>>> the
>
>>>> other.  This would lengthen the time the workflow takes to get
>
>> someone
>
>>>> hired and I don't know which department I would do first....they all
>
>>> do
>
>>>> things in their own time.
>
>>>>
>
>>>>
>
>>>>
>
>>>> Has anyone else encountered this problem?  Does anyone have any
>
>>>> suggestions?
>
>>>>
>
>>>>
>
>>>>
>
>>>> Any help would be greatly appreciated.
>
>>>>
>
>>>>
>
>>>>
>
>>>> Regards,
>
>>>>
>
>>>> Sue T. Doughty
>
>>>> SAP Workflow Specialist
>
>>>>
>
>>>> OLD DOMINION FREIGHT LINE, INC.
>
>>>>
>
>>>> 500 Old Dominion Way, Thomasville, NC 27360
>
>>>>
>
>>>> Toll Free :(800)432-6335, ext.5189
>
>>>> Phone :(336)822-5189 Fax :(336)822-5149
>
>>>> sue.doughty at odfl.com
>
>>>>
>
>>>>
>
>>>>
>
>>>>
>
>>>>
>
>>>> ****************************
>
>>>> CONFIDENTIALITY NOTICE: The information contained in this message
> may
>
>>> be
>
>>>> confidential, privileged, proprietary, or otherwise legally exempt
>
>>> from
>
>>>> disclosure. If the reader of this message is not the intended
>
>>> recipient,
>
>>>> or an employee or agent responsible for delivering this message to
>
>> the
>
>>>> intended recipient, you are hereby notified that you are not
>
>>> authorized to
>
>>>> read, print, retain, copy or disseminate this message, any part of
>
>> it,
>
>>> or
>
>>>> any attachments. If you have received this message in error, please
>
>>> delete
>
>>>> this message and any attachments from your system without reading
> the
>
>>>> content and notify the sender immediately of the inadvertent
>
>>> transmission.
>
>>>> Thank you for your cooperation.
>
>>>>
>
>>>> _______________________________________________
>
>>>> 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
>
>>>
>
>>> _______________________________________________
>
>>> SAP-WUG mailing list
>
>>> SAP-WUG at mit.edu
>
>>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>>>
>
>>>
>
>>> ****************************
>
>>> CONFIDENTIALITY NOTICE: The information contained in this message may
>
>> be
>
>>> confidential, privileged, proprietary, or otherwise legally exempt
>
>> from
>
>>> disclosure. If the reader of this message is not the intended
>
>> recipient,
>
>>> or an employee or agent responsible for delivering this message to
> the
>
>>> intended recipient, you are hereby notified that you are not
>
>> authorized to
>
>>> read, print, retain, copy or disseminate this message, any part of
> it,
>
>> or
>
>>> any attachments. If you have received this message in error, please
>
>> delete
>
>>> this message and any attachments from your system without reading the
>
>>> content and notify the sender immediately of the inadvertent
>
>> transmission.
>
>>> Thank you for your cooperation.
>
>>>
>
>>> _______________________________________________
>
>>> 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
>
>>
>
>> _______________________________________________
>
>> SAP-WUG mailing list
>
>> SAP-WUG at mit.edu
>
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>>
>
>>
>
>> ****************************
>
>> CONFIDENTIALITY NOTICE: The information contained in this message may
> be
>
>> confidential, privileged, proprietary, or otherwise legally exempt
> from
>
>> disclosure. If the reader of this message is not the intended
> recipient,
>
>> or an employee or agent responsible for delivering this message to the
>
>> intended recipient, you are hereby notified that you are not
> authorized to
>
>> read, print, retain, copy or disseminate this message, any part of it,
> or
>
>> any attachments. If you have received this message in error, please
> delete
>
>> this message and any attachments from your system without reading the
>
>> content and notify the sender immediately of the inadvertent
> transmission.
>
>> Thank you for your cooperation.
>
>>
>
>> _______________________________________________
>
>> 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
>
> _______________________________________________
>
> SAP-WUG mailing list
>
> SAP-WUG at mit.edu
>
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> ****************************
> CONFIDENTIALITY NOTICE: The information contained in this message may be
> confidential, privileged, proprietary, or otherwise legally exempt from
> disclosure. If the reader of this message is not the intended recipient,
> or an employee or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that you are not authorized
> to read, print, retain, copy or disseminate this message, any part of
> it, or any attachments. If you have received this message in error,
> please delete this message and any attachments from your system without
> reading the content and notify the sender immediately of the inadvertent
> transmission. Thank you for your cooperation.
>
> ****************************
> CONFIDENTIALITY NOTICE: The information contained in this message may be
> confidential, privileged, proprietary, or otherwise legally exempt from
> disclosure. If the reader of this message is not the intended recipient,
> or an employee or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that you are not authorized
> to read, print, retain, copy or disseminate this message, any part of
> it, or any attachments. If you have received this message in error,
> please delete this message and any attachments from your system without
> reading the content and notify the sender immediately of the inadvertent
> transmission. Thank you for your cooperation.
>
>
>
> Cadbury Cocoa Partnership - a historic alliance to secure the future of
> cocoa farming. Visit www.cadbury.com <http://www.cadbury.com/>  to learn
> more
>
>
>
> Please support our Purple Goes Green commitments and consider the
> environment before you print this email
>
>
>
> -----------------------------------------
>
>
>
> This email (including any attachment) is confidential and may contain
> privileged information. If you are not the intended recipient or receive
> it in error, you may not use, distribute, disclose or copy any of the
> information contained within it and it may be unlawful to do so. If you
> are not the intended recipient please notify us immediately by returning
> this email to us at mailerror at csplc.com <mailto:mailerror at csplc.com>
> and destroy all copies.
>
> Any views expressed by individuals within this email do not necessarily
> reflect the views of Cadbury Holdings Ltd or any of its subsidiaries or
> affiliates. This email does not constitute a binding offer, acceptance,
> amendment, waiver or other agreement, or create any obligation
> whatsoever, unless such intention is clearly stated in the body of the
> email. Whilst we have taken reasonable steps to ensure that this email
> and any attachments are free from viruses, recipients are advised to
> subject this email to their own virus checking, in keeping with good
> computing practice. We accept no liability for any damage sustained as a
> result of any viruses. Please note that email received by Cadbury
> Holdings Ltd or its subsidiaries or affiliates may be monitored in
> accordance with applicable law.
>
> This email originates from Cadbury Holdings Ltd ("Cadbury") or Cadbury
> UK ("Cadbury UK") as the case may be.
>
> Cadbury Holdings Ltd: registered in England and Wales, registered no.
> 52457
> Registered address: Cadbury House, Sanderson Road, Uxbridge, Middlesex
> UB8 1DH United Kingdom.
>
> Telephone: +44 (0) 1895-615000  Fax: +44 (0) 1895-615001
>
>
>
> Cadbury UK: a partnership of Cadbury UK Ltd, Trebor Bassett Ltd and The
> Old Leo Company Ltd each of which is registered in England and Wales.
>
> Principal trading address: Cadbury House, Sanderson Road, Uxbridge,
> Middlesex UB8 1DH United Kingdom.
>
> Telephone: +44 (0) 1895-615000  Fax: +44 (0) 1895-615001
>
>
>
> -----------------------------------------
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>