Enqueue Errors - ECC 6.0
Ramki Maley
rmaley at erpworkflow.com
Fri Feb 26 22:18:15 EST 2010
Many thanks Andy! Your post was just in time to help me resolve an issue
in a complex requirement.
Regards,
Ramki.
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 <mailto: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 <mailto: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
More information about the SAP-WUG
mailing list