Approving work items (Albina Fernando)

Shai Eyal shai.eyal at yahoo.com
Fri Jun 15 00:12:10 EDT 2007


Albina,

I can think of two simple ways to achieve you requirement:
1. Single workflow template, approval within a loop (until predefined condition is fulfilled).
2. Single workflow template - in runtime the workflow starts for each approver.

In addition, in both ways, the best way to determine the approving user is via rule.

Good luck.
 
Regards,
Shai Eyal
SAP Logistics senior consultant
SAP Workflow specialist




----- Original Message ----
From: "sap-wug-request at mit.edu" <sap-wug-request at mit.edu>
To: sap-wug at mit.edu
Sent: Friday, 15 June, 2007 2:01:23 AM
Subject: SAP-WUG Digest, Vol 31, Issue 38


Send SAP-WUG mailing list submissions to
    sap-wug at mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
    http://mailman.mit.edu/mailman/listinfo/sap-wug
or, via email, send a message with subject or body 'help' to
    sap-wug-request at mit.edu

You can reach the person managing the list at
    sap-wug-owner at mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of SAP-WUG digest..."


Today's Topics:

   1. Approving work items (Albina Fernando)
   2. RE: Commit Work (Paul.Bakker at osr.treasury.qld.gov.au)
   3. RE: Workflow development standards (Dart, Jocelyn)


----------------------------------------------------------------------

Message: 1
Date: Fri, 15 Jun 2007 02:02:48 +0530
From: Albina Fernando <Albina.Fernando at lntinfotech.com>
Subject: Approving work items
To: sap-wug at mit.edu
Message-ID:
    <OF4F05F40C.4A97CA60-ON652572FA.0070DDB2-652572FA.0070DDD8 at lntinfotech.com>
    
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20070615/863d33c1/attachment-0001.htm

------------------------------

Message: 2
Date: Fri, 15 Jun 2007 06:38:29 +1000
From: Paul.Bakker at osr.treasury.qld.gov.au
Subject: RE: Commit Work
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Message-ID:
    <OF53DAF750.2F2E0028-ON4A2572FA.0070D3DC-4A2572FA.00716113 at treasury.qld.gov.au>
    
Content-Type: text/plain; charset="us-ascii"

Mike,

Let me crawl out on a limb and say that in 4 years of doing workflow (over
half a dozen sites), I have never found a workflow problem that couldn't be
explained logically.

Perhaps that is because I've never been to a real high-volume site like
yours.. I don't know.

Overall, I've always found SAP workflow to be a very stable, predictable
system. As someone else noted, most problems are due to those pesky users.
:-)

cheers
Paul from Brisbane



|---------+---------------------------->
|         |           "Mike Gambier"   |
|         |           <madgambler at hotma|
|         |           il.com>          |
|         |           Sent by:         |
|         |           sap-wug-bounces at m|
|         |           it.edu           |
|         |                            |
|         |                            |
|         |           15/06/2007 01:36 |
|         |           Please respond to|
|         |           "SAP Workflow    |
|         |           Users' Group"    |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                     |
  |       To:       sap-wug at mit.edu                                                                                     |
  |       cc:                                                                                                           |
  |       Subject:  RE: Commit Work                                                                                     |
  >---------------------------------------------------------------------------------------------------------------------|




Andy,

We see a lot of COMMIT issues in our system when it comes to Workflow in
4.6c, and when I mean a lot I mean all sorts of issues, not just simple
steps.

We see the following on occasion, sometimes often:

1. Events that are raised but never heard, even though the event listener
is
out there, waiting.

2. Steps completing but the DB updates not being fast enough for the
Workflow (even with COMMIT WORK AND WAIT explicitly stated in the Method
code, of course LUW concept is boken here).

3. Branches of forks not shutting down when they should (WF becomes
completely frozen)

4. Loops not terminating when their end condition is set (WF becomes
completely frozen)

5. Sub-WFs completing but their Parents still waiting for them to finish
(WF
becomes completely frozen)

6. Deadlines that end but the WF does nothing afterwards (WF becomes
completely frozen)

7. Event containers going 'missing'.

All of these really are down to the Workflow service jobs, SWEQSRV, SWERRE
and SWWDHEX encountering various types of problems (and probably issuing
ROLLBACK statements) and/or the LUW handling being incorrect with partial
commits taking place that Workflow can't handle.

Things like screen messages, short dumps, WF syntax/definition glitches and

unexpected Commits inside code all have a nasty tendancy to interrupt these

programs and therefore expose the whole process chain to unrecoverable
breaks.

The phrase often quoted around here about Workflow is that it is 'flaky'
and
needs constant attention. To be honest we have literally tens of thousands
of WFs in trouble system-wide and it's often really tough to know what to
do
next, particularly after time has elapsed. For most of our WFs we have had
to turn off the technical log due to our volumes so we have all become
familiar with the underlying tables to find out waht's going on.

Thankfully, as we all should know, SAP do give us some handy Transactions
to
help: SWIA, SWPR, SWPC (in increasing order of severity). But, often these
programs require the Workflow entries to be in a consistent state to
qualify
for selection and/or reprocessing. So 'adjustment' of the tables is
sometimes required... And sometimes direct calling of the Workflow Admin
Functions becomes inevitable...

We've recently gone back to SAP and asked them to provide us with a better
tool to analyse the health of our running WF instances. Will publish here
any progress on that front.

Knowing what to do and when is all part of the skill required to look after

Workflow I suppose.

Mike GT

>From: "Catherall, Andy M" <andy.m.catherall at csplc.com>
>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>Subject: RE: Commit Work
>Date: Thu, 14 Jun 2007 06:25:09 -0600
>
>Hi
>
>To expand this 'Commit Work' debate a little further (sorry), I'm
>curious to understand better the implications of Commits in background
>work items.
>
>I've had problems where the code in a background step has errored poorly
>(SAP standard, too!), which has caused the WF to stall quietly, awaiting
>the return from a method that will never complete. Finally, I receive
>the notification from the batch job to say that the Work Item is at
>status 'started'.
>
>A quick look in SM58 shows the error on the RFC that spawned the
>background job. The underlying cause of the error is corrected
>(sometimes, it is little more than an object locked by a user) and the
>RFC can be resubmitted.
>
>What I have discovered is that you cannot assume the LUW is correct, or
>that the workflow will resume correctly - or even at all.
>
>My theory is this that the code being run as a separate session via RFC
>is frequently not *designed* specifically for this, and has Commits in
>places that destroy the LUW. Based on this theory, it would be
>preferable to use BAPIs where possible, and only commit at appropriate
>logic points.
>
>Thoughts...?
>
>I'm also curious to know if there is any wisdom on restarting background
>tasks that have errored... On 4.6c
>
>
>Thanks
>Andy
>
>
>
>-----Original Message-----
>From: sap-wug-bounces at mit.edu@CADSCHW On Behalf Of "Alon Raskin"
><araskin at 3i-consulting.com>
>Sent: 12 June 2007 14:21
>To: SAP Workflow Users' Group
>Subject: RE: Commit Work
>
>Hi Mikey,
>
>I completely understand your point of view. There is just something
>about doing my own COMMIT WORK (and wait) in the method that makes me
>feel uncomfortable. It means that I am going to end the LUW myself and
>not give the caller (the workflow sub-system) a chance to do its own
>COMMIT WORK or ROLLBACK.
>
>To be honest I have only seen a COMMIT WORK 'break' things once. It was
>on an IS-U implementation in Sydney, and the workflow just hung. When we
>removed the COMMIT WORK all was well. I guess the COMMIT WORK was
>leaving the workflow tables in some sort of inconsistent state.
>
>I am sure there has to be a better way...
>
>Perhaps the answer is to never call BAPIs directly from a Workflow but
>rather wrap the BAPI in a 'standard' method. 'The Good Book' (not the
>one with Abraham and Moses but the one with Rickayzen and Dart) even
>mentions it is a good idea to wrap BAPI calls in standard methods but it
>suggests this for different reasons then the one I am thinking of.
>
>Ps. I am coming to the UK in 2nd and 3rd week of July. Any chance of a
>Poker game with the boys?
>
>Alon Raskin
>e: araskin at 3i-consulting.com <mailto:araskin at 3i-consulting.com>
>p: +1 207 523 3489
>c: +1 207 409 4983
>f:  +1 806 403 4983
>
>
>________________________________
>
>From: sap-wug-bounces at mit.edu on behalf of Mike Gambier
>Sent: Tue 6/12/2007 04:04
>To: sap-wug at mit.edu
>Subject: Re: Commit Work
>
>
>
>Hey Gavin & Alon,
>
>On that same UK project (which is still going on by the way, only now
>it's live with 16 million customers and going to be upgraded to ERP 2005
>at some point), we still occasionally see DB update issues every now and
>then, even with explicit COMMIT WORK AND WAIT statements littered (as
>you say) inside the BOR Methods.
>
>After more analysis the problems seem to be related to timing issues
>with object instances that have their own buffering (and when the
>buffers are refreshed), buffering at the DB level for SQL performance
>and V1 and V2 updates actually being carried out at the DB level.
>
>Simply put Workflow can sometimes be too quick to proceed to the next
>step, particularly when the system its on as a whole has a lot of
>traffic.
>
>My advice to anyone who absolutely positively needs to have performed
>the update in a previous step first is to:
>
>a) Consider adding explicit COMMIT WORK AND WAIT statements driven by
>optional importing parameters to their methods - more load on the system
>and delays to the Workflow but a greater chance of success. You can then
>experiment by setting the parameters on certain sensitive steps to see
>if this helps. If it doesn't you can always remove the flag setting in
>the binding later.
>
>b) remember to refresh buffered instances after the data has been
>updated.
>Often overlooked this one. Same goes for the binding to between the step
>and the Workflow. If you have specified the binding make sure any
>updated instances are actually passed back to the WF container.
>
>c) build in to the WF definition decent error handling and possible
>retries (e.g. temporary exceptions). Think about how certain you have to
>be that the previous DB update has actually worked to carry on with the
>WF. Sometimes after several tries you may actually want to stop the WF
>altogether because it would be too risky to carry on.
>
>Regards,
>
>Mike GT
>
> >From: "Gavin Mooney" <gavinmooney at gmail.com>
> >Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >Subject: Re: Commit Work
> >Date: Mon, 11 Jun 2007 19:11:41 -0300
> >
> >Hey Alon,
> >
> >When I was looking into this issue once on 4.6C (for a project in the
> >UK that you may remember) I found that the code was littered with
> >explicit COMMIT WORK statements, including after the execution of each
> >step. I don't know if this has changed in the newer releases but my
> >guess is that by being a COMMIT WORK and not a COMMIT WORK AND WAIT
> >statement, you can still have update problems.
> >
> >We didn't see this just with BAPIs though. As far as I remember we
> >resolved it either by creating a custom wrapper method that called the
> >standard one and then executed a (SAP authorised) COMMIT WORK or by
> >using async methods and terminating events.
> >
> >I'd be interested to see what experiences other members of the group
> >have had....
> >
> >Regards,
> >Gavin
> >
> >2007/6/11, Dave Weston <Dave.Weston at clockwork.ca>:
> > > Alan, in step 1 are you also calling BAPI_TRANSACTION_COMMIT at the
> > > end
> >to do the commit and apply the changes to the db ? you can also use the
>
> >WAIT parameter to wait for the update to take place as well.
> > >
> > > Dave
> > >
> > >
> > > -----Original Message-----
> > > From: sap-wug-bounces at mit.edu on behalf of Alon Raskin
> > > Sent: Mon 6/11/2007 5:09 PM
> > > To: SAP Workflow Users' Group
> > > Subject: Commit Work
> > >
> > > A colleague of mine is having an issue and I wanted to see if anyone
>
> > > has
> >seen this before. I have seen this issue creep up on different
> >implementations so I am sure I am not the first to handle this.
> > >
> > >
> > > *
> > >
> > >         Step 1 creates a new document (doesn't matter what it is,
> > > its
> >IS-U) by calling a BAPI
> > > *
> > >
> > >         The BAPI returns the ID of the new object which can be seen
> > > in
> >the container of the Workflow
> > > *
> > >
> > >         Step 2 then calls SYSTEM.GenericInstantiate to get an
> > > instance
> >of the newly created document
> > > *
> > >
> > >         Step 2 errors claiming that the object does not exist.
> > >
> > > I suggested to him to uncheck the Advance with Dialog step as I
> > > thought
> >that this would 'force' the WF sub-system to do a COMMIT WORK between
> >steps but this did not seem to work. I was sure that the Workflow
> >sub-system always executes a COMMIT WORK between steps. Is that not the
>
> >case? We did a test, and created a method where all it did was execute
> >a COMMIT WORK. We inserted this step in between the BAPI and the
> >System.GenericInstantiate and everything worked beautifully. So it is
>definitely a commit issue.
> >Perhaps WF treats methods marked as BAPIs differently to standard
> >methods and doesn't not do an explicit COMMIT WORK? If so, how do
> >people get around this?
> > >
> > > Regards,
> > >
> > > Alon Raskin
> > >
> > >
> > >
> > > _______________________________________________
> > > SAP-WUG mailing list
> > > SAP-WUG at mit.edu
> > > http://mailman.mit.edu/mailman/listinfo/sap-wug
> > >
> > >
> > >
> >_______________________________________________
> >SAP-WUG mailing list
> >SAP-WUG at mit.edu
> >http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>_________________________________________________________________
>Need a break? Find your escape route with Live Search Maps.
>http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park
>&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=
>1118863&encType=1&FORM=MGAC01
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>P please don't print this e-mail unless you really need to.
>
>-----------------------------------------
>
>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
>e-mail to us at mailerror at csplc.com and destroy all copies.
>Any views expressed by individuals within this e-mail do not necessarily
>reflect the views of Cadbury Schweppes Plc or any of its subsidiaries' or
>affiliates'. This email does not constitute a binding offer, acceptance,
>amendment, waiver or other agreement, unless such intention is clearly
>stated in the body of the email.  Whilst we have taken reasonable steps to

>ensure that this e-mail and attachments are free from viruses, recipients
>are advised to subject this mail to their own virus checking, in keeping
>with good computing practice.
>Please note that e-mail received by Cadbury Schweppes Plc or its
>subsidiaries or affiliates may be monitored in accordance with applicable
>law.
>
>Cadbury Schweppes plc registered in England, Company Number 00052457
>whose Registered Office is at 25 Berkeley Square, London, W1J 6HB United
>Kingdom
>Telephone:+44 (0) 20 7409 1313 Fax:+44 (0) 20 7830 5200
>-----------------------------------------
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug

_________________________________________________________________
Like puzzles? Play free games & earn great prizes. Play Clink now.
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug




******************************************************************************************************************************************************

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.

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.  

******************************************************************************************************************************************************



------------------------------

Message: 3
Date: Fri, 15 Jun 2007 08:00:31 +0800
From: "Dart, Jocelyn" <jocelyn.dart at sap.com>
Subject: RE: Workflow development standards
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Message-ID:
    <2EAD340DEF223745B1AC9A10B49FBB4756902D at sgsine13.sin.sap.corp>
Content-Type: text/plain; charset="us-ascii"

Nice ... but hopefully next time they will have updated to use ABAP OO
for Workflow as well. 


Regards, 
Jocelyn Dart 
Senior Consultant 
SAP Australia Pty Ltd. 
Level 1/168 Walker St. 
North Sydney 
NSW, 2060 
Australia 
T   +61 412 390 267 
M   + 61 412 390 267 
E   jocelyn.dart at sap.com 
http://www.sap.com <http://www.sap.com/>  

The information contained in or attached to this electronic transmission
is confidential and may be legally privileged. It is intended only for
the person or entity to which it is addressed. If you are not the
intended recipient, you are hereby notified that any distribution,
copying, review, retransmission, dissemination or other use of this
electronic transmission or the information contained in it is strictly
prohibited. If you have received this electronic transmission in error,
please immediately contact the sender to arrange for the return of the
original documents. 

Electronic transmission cannot be guaranteed to be secure and
accordingly, the sender does not accept liability for any such data
corruption, interception, unauthorized amendment, viruses, delays or the
consequences thereof.

Any views expressed in this electronic transmission are those of the
individual sender, except where the message states otherwise and the
sender is authorized to state them to be the views of SAP AG or any of
its subsidiaries. SAP AG, its subsidiaries, and their directors,
officers and employees make no representation nor accept any liability
for the accuracy or completeness of the views or information contained
herein. Please be aware that the furnishing of any pricing information/
business proposal herein is indicative only, is subject to change and
shall not be construed as an offer or as constituting a binding
agreement on the part of SAP AG or any of its subsidiaries to enter into
any relationship, unless otherwise expressly stated. 



________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Sue Doughty
Sent: Thursday, 14 June 2007 9:41 PM
To: SAP Workflow Users' Group
Subject: RE: Workflow development standards


Michelle,

Attached is a presentation -- Workflow - A Journey in Discovery -- that
was given at ASUG this year.  They had a great spreadsheet that
contained all the steps of a workflow project and what needed to be done
for each phase.  Their email addresses are on the last page....you could
ask them to send you the spreadsheet.

Hope this helps.
Sue Doughty

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Michelle Van Patten
Sent: Wednesday, June 13, 2007 4:31 PM
To: sap-wug at mit.edu
Subject: Workflow development standards



Good afternoon, 

Does anyone have development standards for workflow they could share?  I
have been tasked with creating them for our company.

Thanks, 
Michelle 

________________________________

NOTICE: This e-mail message and any attachments are confidential and
intended solely for use of the intended recipient. If you are not the
intended recipient, you should not review, retransmit, convert to hard
copy, copy, use or disseminate this e-mail or any attachments to it. If
you have received this e-mail in error, please immediately notify us by
return e-mail and delete this message and any attachments from your
computer system. Please note that if this e-mail message contains a
forwarded message or is a reply to a prior message, some or all of the
contents of this message or any attachments may not have been produced
by the sender. This notice is automatically appended to each e-mail
message leaving the sender's e-mail domain. Thank you.


**************************** 
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. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20070615/5c019f1c/attachment.htm

------------------------------

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug


End of SAP-WUG Digest, Vol 31, Issue 38
***************************************


      ___________________________________________________________ 
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20070614/6fcfc9bb/attachment.htm


More information about the SAP-WUG mailing list