<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:tahoma, new york, times, serif;font-size:10pt"><DIV></DIV>
<DIV>Albina,</DIV>
<DIV> </DIV>
<DIV>I can think of two simple ways to achieve you requirement:</DIV>
<DIV>1. Single workflow template, approval within a loop (until predefined condition is fulfilled).</DIV>
<DIV>2. Single workflow template - in runtime the workflow starts for each approver.</DIV>
<DIV> </DIV>
<DIV>In addition, in both ways, the best way to determine the approving user is via rule.</DIV>
<DIV> </DIV>
<DIV>Good luck.<BR> </DIV>
<P><FONT face="verdana, helvetica, sans-serif" color=#00007f size=2><STRONG>Regards,<BR>Shai Eyal</STRONG></FONT></P>
<P><FONT face=Verdana color=#000080 size=2><STRONG>SAP Logistics senior consultant<BR>SAP Workflow specialist<BR></STRONG></FONT></P>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: tahoma, new york, times, serif"><BR><BR>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: "sap-wug-request@mit.edu" <sap-wug-request@mit.edu><BR>To: sap-wug@mit.edu<BR>Sent: Friday, 15 June, 2007 2:01:23 AM<BR>Subject: SAP-WUG Digest, Vol 31, Issue 38<BR><BR>
<DIV>Send SAP-WUG mailing list submissions to<BR> sap-wug@mit.edu<BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR> <A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>or, via email, send a message with subject or body 'help' to<BR> sap-wug-request@mit.edu<BR><BR>You can reach the person managing the list at<BR> sap-wug-owner@mit.edu<BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of SAP-WUG digest..."<BR><BR><BR>Today's Topics:<BR><BR> 1. Approving work items (Albina Fernando)<BR> 2. RE: Commit Work (Paul.Bakker@osr.treasury.qld.gov.au)<BR> 3. RE: Workflow development standards (Dart, Jocelyn)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Fri,
15 Jun 2007 02:02:48 +0530<BR>From: Albina Fernando <Albina.Fernando@lntinfotech.com><BR>Subject: Approving work items<BR>To: sap-wug@mit.edu<BR>Message-ID:<BR> <OF4F05F40C.4A97CA60-ON652572FA.0070DDB2-652572FA.0070DDD8@lntinfotech.com><BR> <BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>An HTML attachment was scrubbed...<BR>URL: <A href="http://mailman.mit.edu/pipermail/sap-wug/attachments/20070615/863d33c1/attachment-0001.htm" target=_blank>http://mailman.mit.edu/pipermail/sap-wug/attachments/20070615/863d33c1/attachment-0001.htm</A><BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Fri, 15 Jun 2007 06:38:29 +1000<BR>From: Paul.Bakker@osr.treasury.qld.gov.au<BR>Subject: RE: Commit Work<BR>To: "SAP Workflow Users' Group"
<sap-wug@mit.edu><BR>Message-ID:<BR> <OF53DAF750.2F2E0028-ON4A2572FA.0070D3DC-4A2572FA.00716113@treasury.qld.gov.au><BR> <BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Mike,<BR><BR>Let me crawl out on a limb and say that in 4 years of doing workflow (over<BR>half a dozen sites), I have never found a workflow problem that couldn't be<BR>explained logically.<BR><BR>Perhaps that is because I've never been to a real high-volume site like<BR>yours.. I don't know.<BR><BR>Overall, I've always found SAP workflow to be a very stable, predictable<BR>system. As someone else noted, most problems are due to those pesky users.<BR>:-)<BR><BR>cheers<BR>Paul from Brisbane<BR><BR><BR><BR>|---------+----------------------------><BR>| | "Mike Gambier" |<BR>|
| <madgambler@hotma|<BR>| | il.com> |<BR>| | Sent by: |<BR>| | sap-wug-bounces@m|<BR>| | it.edu |<BR>|
| |<BR>| | |<BR>| | 15/06/2007 01:36 |<BR>| | Please respond to|<BR>| | "SAP Workflow |<BR>| | Users'
Group" |<BR>|
| |<BR>|---------+----------------------------><BR> >---------------------------------------------------------------------------------------------------------------------|<BR> | &nb
sp; |<BR> | To: sap-wug@mit.edu |<BR> |
cc: |<BR> | Subject: RE: Commit
Work |<BR> >---------------------------------------------------------------------------------------------------------------------|<BR><BR><BR><BR><BR>Andy,<BR><BR>We see a lot of COMMIT issues in our system when it comes to Workflow in<BR>4.6c, and when I mean a lot I mean all sorts of issues, not just simple<BR>steps.<BR><BR>We see the following on occasion, sometimes often:<BR><BR>1. Events that are raised but never heard, even though the event
listener<BR>is<BR>out there, waiting.<BR><BR>2. Steps completing but the DB updates not being fast enough for the<BR>Workflow (even with COMMIT WORK AND WAIT explicitly stated in the Method<BR>code, of course LUW concept is boken here).<BR><BR>3. Branches of forks not shutting down when they should (WF becomes<BR>completely frozen)<BR><BR>4. Loops not terminating when their end condition is set (WF becomes<BR>completely frozen)<BR><BR>5. Sub-WFs completing but their Parents still waiting for them to finish<BR>(WF<BR>becomes completely frozen)<BR><BR>6. Deadlines that end but the WF does nothing afterwards (WF becomes<BR>completely frozen)<BR><BR>7. Event containers going 'missing'.<BR><BR>All of these really are down to the Workflow service jobs, SWEQSRV, SWERRE<BR>and SWWDHEX encountering various types of problems (and probably issuing<BR>ROLLBACK statements) and/or the LUW handling being incorrect with partial<BR>commits taking place that Workflow can't
handle.<BR><BR>Things like screen messages, short dumps, WF syntax/definition glitches and<BR><BR>unexpected Commits inside code all have a nasty tendancy to interrupt these<BR><BR>programs and therefore expose the whole process chain to unrecoverable<BR>breaks.<BR><BR>The phrase often quoted around here about Workflow is that it is 'flaky'<BR>and<BR>needs constant attention. To be honest we have literally tens of thousands<BR>of WFs in trouble system-wide and it's often really tough to know what to<BR>do<BR>next, particularly after time has elapsed. For most of our WFs we have had<BR>to turn off the technical log due to our volumes so we have all become<BR>familiar with the underlying tables to find out waht's going on.<BR><BR>Thankfully, as we all should know, SAP do give us some handy Transactions<BR>to<BR>help: SWIA, SWPR, SWPC (in increasing order of severity). But, often these<BR>programs require the Workflow entries to be in a consistent state to<BR>qualify<BR>for
selection and/or reprocessing. So 'adjustment' of the tables is<BR>sometimes required... And sometimes direct calling of the Workflow Admin<BR>Functions becomes inevitable...<BR><BR>We've recently gone back to SAP and asked them to provide us with a better<BR>tool to analyse the health of our running WF instances. Will publish here<BR>any progress on that front.<BR><BR>Knowing what to do and when is all part of the skill required to look after<BR><BR>Workflow I suppose.<BR><BR>Mike GT<BR><BR>>From: "Catherall, Andy M" <andy.m.catherall@csplc.com><BR>>Reply-To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>>To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>>Subject: RE: Commit Work<BR>>Date: Thu, 14 Jun 2007 06:25:09 -0600<BR>><BR>>Hi<BR>><BR>>To expand this 'Commit Work' debate a little further (sorry), I'm<BR>>curious to understand better the implications of Commits in background<BR>>work items.<BR>><BR>>I've
had problems where the code in a background step has errored poorly<BR>>(SAP standard, too!), which has caused the WF to stall quietly, awaiting<BR>>the return from a method that will never complete. Finally, I receive<BR>>the notification from the batch job to say that the Work Item is at<BR>>status 'started'.<BR>><BR>>A quick look in SM58 shows the error on the RFC that spawned the<BR>>background job. The underlying cause of the error is corrected<BR>>(sometimes, it is little more than an object locked by a user) and the<BR>>RFC can be resubmitted.<BR>><BR>>What I have discovered is that you cannot assume the LUW is correct, or<BR>>that the workflow will resume correctly - or even at all.<BR>><BR>>My theory is this that the code being run as a separate session via RFC<BR>>is frequently not *designed* specifically for this, and has Commits in<BR>>places that destroy the LUW. Based on this theory, it would
be<BR>>preferable to use BAPIs where possible, and only commit at appropriate<BR>>logic points.<BR>><BR>>Thoughts...?<BR>><BR>>I'm also curious to know if there is any wisdom on restarting background<BR>>tasks that have errored... On 4.6c<BR>><BR>><BR>>Thanks<BR>>Andy<BR>><BR>><BR>><BR>>-----Original Message-----<BR>>From: sap-wug-bounces@mit.edu@CADSCHW On Behalf Of "Alon Raskin"<BR>><araskin@3i-consulting.com><BR>>Sent: 12 June 2007 14:21<BR>>To: SAP Workflow Users' Group<BR>>Subject: RE: Commit Work<BR>><BR>>Hi Mikey,<BR>><BR>>I completely understand your point of view. There is just something<BR>>about doing my own COMMIT WORK (and wait) in the method that makes me<BR>>feel uncomfortable. It means that I am going to end the LUW myself and<BR>>not give the caller (the workflow sub-system) a chance to do its own<BR>>COMMIT WORK or ROLLBACK.<BR>><BR>>To be honest I have only
seen a COMMIT WORK 'break' things once. It was<BR>>on an IS-U implementation in Sydney, and the workflow just hung. When we<BR>>removed the COMMIT WORK all was well. I guess the COMMIT WORK was<BR>>leaving the workflow tables in some sort of inconsistent state.<BR>><BR>>I am sure there has to be a better way...<BR>><BR>>Perhaps the answer is to never call BAPIs directly from a Workflow but<BR>>rather wrap the BAPI in a 'standard' method. 'The Good Book' (not the<BR>>one with Abraham and Moses but the one with Rickayzen and Dart) even<BR>>mentions it is a good idea to wrap BAPI calls in standard methods but it<BR>>suggests this for different reasons then the one I am thinking of.<BR>><BR>>Ps. I am coming to the UK in 2nd and 3rd week of July. Any chance of a<BR>>Poker game with the boys?<BR>><BR>>Alon Raskin<BR>>e: araskin@3i-consulting.com <mailto:araskin@3i-consulting.com><BR>>p: +1 207 523 3489<BR>>c: +1 207
409 4983<BR>>f: +1 806 403 4983<BR>><BR>><BR>>________________________________<BR>><BR>>From: sap-wug-bounces@mit.edu on behalf of Mike Gambier<BR>>Sent: Tue 6/12/2007 04:04<BR>>To: sap-wug@mit.edu<BR>>Subject: Re: Commit Work<BR>><BR>><BR>><BR>>Hey Gavin & Alon,<BR>><BR>>On that same UK project (which is still going on by the way, only now<BR>>it's live with 16 million customers and going to be upgraded to ERP 2005<BR>>at some point), we still occasionally see DB update issues every now and<BR>>then, even with explicit COMMIT WORK AND WAIT statements littered (as<BR>>you say) inside the BOR Methods.<BR>><BR>>After more analysis the problems seem to be related to timing issues<BR>>with object instances that have their own buffering (and when the<BR>>buffers are refreshed), buffering at the DB level for SQL performance<BR>>and V1 and V2 updates actually being carried out at the DB
level.<BR>><BR>>Simply put Workflow can sometimes be too quick to proceed to the next<BR>>step, particularly when the system its on as a whole has a lot of<BR>>traffic.<BR>><BR>>My advice to anyone who absolutely positively needs to have performed<BR>>the update in a previous step first is to:<BR>><BR>>a) Consider adding explicit COMMIT WORK AND WAIT statements driven by<BR>>optional importing parameters to their methods - more load on the system<BR>>and delays to the Workflow but a greater chance of success. You can then<BR>>experiment by setting the parameters on certain sensitive steps to see<BR>>if this helps. If it doesn't you can always remove the flag setting in<BR>>the binding later.<BR>><BR>>b) remember to refresh buffered instances after the data has been<BR>>updated.<BR>>Often overlooked this one. Same goes for the binding to between the step<BR>>and the Workflow. If you have specified the binding make
sure any<BR>>updated instances are actually passed back to the WF container.<BR>><BR>>c) build in to the WF definition decent error handling and possible<BR>>retries (e.g. temporary exceptions). Think about how certain you have to<BR>>be that the previous DB update has actually worked to carry on with the<BR>>WF. Sometimes after several tries you may actually want to stop the WF<BR>>altogether because it would be too risky to carry on.<BR>><BR>>Regards,<BR>><BR>>Mike GT<BR>><BR>> >From: "Gavin Mooney" <gavinmooney@gmail.com><BR>> >Reply-To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>> >To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>> >Subject: Re: Commit Work<BR>> >Date: Mon, 11 Jun 2007 19:11:41 -0300<BR>> ><BR>> >Hey Alon,<BR>> ><BR>> >When I was looking into this issue once on 4.6C (for a project in the<BR>> >UK that you may remember) I found
that the code was littered with<BR>> >explicit COMMIT WORK statements, including after the execution of each<BR>> >step. I don't know if this has changed in the newer releases but my<BR>> >guess is that by being a COMMIT WORK and not a COMMIT WORK AND WAIT<BR>> >statement, you can still have update problems.<BR>> ><BR>> >We didn't see this just with BAPIs though. As far as I remember we<BR>> >resolved it either by creating a custom wrapper method that called the<BR>> >standard one and then executed a (SAP authorised) COMMIT WORK or by<BR>> >using async methods and terminating events.<BR>> ><BR>> >I'd be interested to see what experiences other members of the group<BR>> >have had....<BR>> ><BR>> >Regards,<BR>> >Gavin<BR>> ><BR>> >2007/6/11, Dave Weston <Dave.Weston@clockwork.ca>:<BR>> > > Alan, in step 1 are you also calling BAPI_TRANSACTION_COMMIT at
the<BR>> > > end<BR>> >to do the commit and apply the changes to the db ? you can also use the<BR>><BR>> >WAIT parameter to wait for the update to take place as well.<BR>> > ><BR>> > > Dave<BR>> > ><BR>> > ><BR>> > > -----Original Message-----<BR>> > > From: sap-wug-bounces@mit.edu on behalf of Alon Raskin<BR>> > > Sent: Mon 6/11/2007 5:09 PM<BR>> > > To: SAP Workflow Users' Group<BR>> > > Subject: Commit Work<BR>> > ><BR>> > > A colleague of mine is having an issue and I wanted to see if anyone<BR>><BR>> > > has<BR>> >seen this before. I have seen this issue creep up on different<BR>> >implementations so I am sure I am not the first to handle this.<BR>> > ><BR>> > ><BR>> > > *<BR>> > ><BR>> > > Step 1 creates a new document (doesn't
matter what it is,<BR>> > > its<BR>> >IS-U) by calling a BAPI<BR>> > > *<BR>> > ><BR>> > > The BAPI returns the ID of the new object which can be seen<BR>> > > in<BR>> >the container of the Workflow<BR>> > > *<BR>> > ><BR>> > > Step 2 then calls SYSTEM.GenericInstantiate to get an<BR>> > > instance<BR>> >of the newly created document<BR>> > > *<BR>> > ><BR>> > > Step 2 errors claiming that the object does not exist.<BR>> > ><BR>> > > I suggested to him to uncheck the Advance with Dialog step as I<BR>> > > thought<BR>> >that this would 'force' the WF sub-system to do a COMMIT WORK between<BR>> >steps but this did not seem to work. I was sure that the Workflow<BR>>
>sub-system always executes a COMMIT WORK between steps. Is that not the<BR>><BR>> >case? We did a test, and created a method where all it did was execute<BR>> >a COMMIT WORK. We inserted this step in between the BAPI and the<BR>> >System.GenericInstantiate and everything worked beautifully. So it is<BR>>definitely a commit issue.<BR>> >Perhaps WF treats methods marked as BAPIs differently to standard<BR>> >methods and doesn't not do an explicit COMMIT WORK? If so, how do<BR>> >people get around this?<BR>> > ><BR>> > > Regards,<BR>> > ><BR>> > > Alon Raskin<BR>> > ><BR>> > ><BR>> > ><BR>> > > _______________________________________________<BR>> > > SAP-WUG mailing list<BR>> > > SAP-WUG@mit.edu<BR>> > > <A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>>
> ><BR>> > ><BR>> > ><BR>> >_______________________________________________<BR>> >SAP-WUG mailing list<BR>> >SAP-WUG@mit.edu<BR>> ><A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>><BR>>_________________________________________________________________<BR>>Need a break? Find your escape route with Live Search Maps.<BR>><A href="http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park" target=_blank>http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park</A><BR>>&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=<BR>>1118863&encType=1&FORM=MGAC01<BR>><BR>>_______________________________________________<BR>>SAP-WUG mailing list<BR>>SAP-WUG@mit.edu<BR>><A href="http://mailman.mit.edu/mailman/listinfo/sap-wug"
target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>><BR>>P please don't print this e-mail unless you really need to.<BR>><BR>>-----------------------------------------<BR>><BR>>This email (including any attachment) is confidential and may contain<BR>>privileged information. If you are not the intended recipient or receive<BR>it<BR>>in error, you may not use, distribute, disclose or copy any of the<BR>>information contained within it and it may be unlawful to do so. If you<BR>are<BR>>not the intended recipient please notify us immediately by returning this<BR>>e-mail to us at mailerror@csplc.com and destroy all copies.<BR>>Any views expressed by individuals within this e-mail do not necessarily<BR>>reflect the views of Cadbury Schweppes Plc or any of its subsidiaries' or<BR>>affiliates'. This email does not constitute a binding offer, acceptance,<BR>>amendment, waiver or other agreement, unless such intention is
clearly<BR>>stated in the body of the email. Whilst we have taken reasonable steps to<BR><BR>>ensure that this e-mail and attachments are free from viruses, recipients<BR>>are advised to subject this mail to their own virus checking, in keeping<BR>>with good computing practice.<BR>>Please note that e-mail received by Cadbury Schweppes Plc or its<BR>>subsidiaries or affiliates may be monitored in accordance with applicable<BR>>law.<BR>><BR>>Cadbury Schweppes plc registered in England, Company Number 00052457<BR>>whose Registered Office is at 25 Berkeley Square, London, W1J 6HB United<BR>>Kingdom<BR>>Telephone:+44 (0) 20 7409 1313 Fax:+44 (0) 20 7830 5200<BR>>-----------------------------------------<BR>><BR>>_______________________________________________<BR>>SAP-WUG mailing list<BR>>SAP-WUG@mit.edu<BR>><A href="http://mailman.mit.edu/mailman/listinfo/sap-wug"
target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR>_________________________________________________________________<BR>Like puzzles? Play free games & earn great prizes. Play Clink now.<BR><A href="http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2" target=_blank>http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2</A><BR><BR>_______________________________________________<BR>SAP-WUG mailing list<BR>SAP-WUG@mit.edu<BR><A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR><BR><BR><BR>******************************************************************************************************************************************************<BR><BR>Only an individual or entity who is intended to be a recipient of this e-mail may access or use the information contained in this e-mail or any of its attachments. Opinions contained in this e-mail or any of
its attachments do not necessarily reflect the opinions of Queensland Treasury.<BR><BR>The contents of this e-mail and any attachments are confidential and may be legally privileged and the subject of copyright. If you have received this e-mail in error, please notify Queensland Treasury immediately and erase all copies of the e-mail and the attachments. Queensland Treasury uses virus scanning software. However, it is not liable for viruses present in this e-mail or in any attachment. <BR><BR>******************************************************************************************************************************************************<BR><BR><BR><BR>------------------------------<BR><BR>Message: 3<BR>Date: Fri, 15 Jun 2007 08:00:31 +0800<BR>From: "Dart, Jocelyn" <jocelyn.dart@sap.com><BR>Subject: RE: Workflow development standards<BR>To: "SAP Workflow Users' Group"
<sap-wug@mit.edu><BR>Message-ID:<BR> <2EAD340DEF223745B1AC9A10B49FBB4756902D@sgsine13.sin.sap.corp><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Nice ... but hopefully next time they will have updated to use ABAP OO<BR>for Workflow as well. <BR><BR><BR>Regards, <BR>Jocelyn Dart <BR>Senior Consultant <BR>SAP Australia Pty Ltd. <BR>Level 1/168 Walker St. <BR>North Sydney <BR>NSW, 2060 <BR>Australia <BR>T +61 412 390 267 <BR>M + 61 412 390 267 <BR>E jocelyn.dart@sap.com <BR><A href="http://www.sap.com/" target=_blank>http://www.sap.com</A> <<A href="http://www.sap.com/" target=_blank>http://www.sap.com/</A>> <BR><BR>The information contained in or attached to this electronic transmission<BR>is confidential and may be legally privileged. It is intended only for<BR>the person or entity to which it is addressed. If you are not the<BR>intended recipient, you are hereby notified that
any distribution,<BR>copying, review, retransmission, dissemination or other use of this<BR>electronic transmission or the information contained in it is strictly<BR>prohibited. If you have received this electronic transmission in error,<BR>please immediately contact the sender to arrange for the return of the<BR>original documents. <BR><BR>Electronic transmission cannot be guaranteed to be secure and<BR>accordingly, the sender does not accept liability for any such data<BR>corruption, interception, unauthorized amendment, viruses, delays or the<BR>consequences thereof.<BR><BR>Any views expressed in this electronic transmission are those of the<BR>individual sender, except where the message states otherwise and the<BR>sender is authorized to state them to be the views of SAP AG or any of<BR>its subsidiaries. SAP AG, its subsidiaries, and their directors,<BR>officers and employees make no representation nor accept any liability<BR>for the accuracy or completeness of the
views or information contained<BR>herein. Please be aware that the furnishing of any pricing information/<BR>business proposal herein is indicative only, is subject to change and<BR>shall not be construed as an offer or as constituting a binding<BR>agreement on the part of SAP AG or any of its subsidiaries to enter into<BR>any relationship, unless otherwise expressly stated. <BR><BR><BR><BR>________________________________<BR><BR>From: sap-wug-bounces@mit.edu [mailto:sap-wug-bounces@mit.edu] On Behalf<BR>Of Sue Doughty<BR>Sent: Thursday, 14 June 2007 9:41 PM<BR>To: SAP Workflow Users' Group<BR>Subject: RE: Workflow development standards<BR><BR><BR>Michelle,<BR><BR>Attached is a presentation -- Workflow - A Journey in Discovery -- that<BR>was given at ASUG this year. They had a great spreadsheet that<BR>contained all the steps of a workflow project and what needed to be done<BR>for each phase. Their email addresses are on the last page....you
could<BR>ask them to send you the spreadsheet.<BR><BR>Hope this helps.<BR>Sue Doughty<BR><BR>________________________________<BR><BR>From: sap-wug-bounces@mit.edu [mailto:sap-wug-bounces@mit.edu] On Behalf<BR>Of Michelle Van Patten<BR>Sent: Wednesday, June 13, 2007 4:31 PM<BR>To: sap-wug@mit.edu<BR>Subject: Workflow development standards<BR><BR><BR><BR>Good afternoon, <BR><BR>Does anyone have development standards for workflow they could share? I<BR>have been tasked with creating them for our company.<BR><BR>Thanks, <BR>Michelle <BR><BR>________________________________<BR><BR>NOTICE: This e-mail message and any attachments are confidential and<BR>intended solely for use of the intended recipient. If you are not the<BR>intended recipient, you should not review, retransmit, convert to hard<BR>copy, copy, use or disseminate this e-mail or any attachments to it. If<BR>you have received this e-mail in error, please immediately notify us by<BR>return e-mail and delete
this message and any attachments from your<BR>computer system. Please note that if this e-mail message contains a<BR>forwarded message or is a reply to a prior message, some or all of the<BR>contents of this message or any attachments may not have been produced<BR>by the sender. This notice is automatically appended to each e-mail<BR>message leaving the sender's e-mail domain. Thank you.<BR><BR><BR>**************************** <BR>CONFIDENTIALITY NOTICE: The information contained in this message may be<BR>confidential, privileged, proprietary, or otherwise legally exempt from<BR>disclosure. If the reader of this message is not the intended recipient,<BR>or an employee or agent responsible for delivering this message to the<BR>intended recipient, you are hereby notified that you are not authorized<BR>to read, print, retain, copy or disseminate this message, any part of<BR>it, or any attachments. If you have received this message in error,<BR>please delete this message and
any attachments from your system without<BR>reading the content and notify the sender immediately of the inadvertent<BR>transmission. Thank you for your cooperation. <BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <A href="http://mailman.mit.edu/pipermail/sap-wug/attachments/20070615/5c019f1c/attachment.htm" target=_blank>http://mailman.mit.edu/pipermail/sap-wug/attachments/20070615/5c019f1c/attachment.htm</A><BR><BR>------------------------------<BR><BR>_______________________________________________<BR>SAP-WUG mailing list<BR>SAP-WUG@mit.edu<BR><A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR><BR>End of SAP-WUG Digest, Vol 31, Issue 38<BR>***************************************</DIV></DIV><BR></DIV></div><br>
<hr size=1>
Yahoo! Answers - Get better answers from someone who knows. <a
href="http://uk.answers.yahoo.com/;_ylc=X3oDMTEydmViNG02BF9TAzIxMTQ3MTcxOTAEc2VjA21haWwEc2xrA3RhZ2xpbmU">Try
it now</a>.</body></html>