Deadline - Latest End Recipient of Message

Fri Oct 31 13:01:12 EDT 2008

Tom,

I understand your requirement, I was asked for it several times and it does make sense. It also explains why it did not work for you at the first place. 
I'll describe several options that I handled it though there might be better solutions that may suit your occasion:
1. I've create customized rule which runs standard rule 168, store the result and runs 168 again. In this way you get the 2nd level manager.
2. Another time I used FM RH_STRUCT_GET (or maybe its RH_GET_STRUCT) with parameter level value 3 - it also resolve the manager of the manager.
3. In previous step resolve the initator manager (using rule 168) and store it workflow container element, say WF_MANAGER. The to set step to expression &WF_MANAGER& and deadline to the result of rule 168 for &WF_MANAGER&.

Let me know if you need more details - it should work well.

Good luck,

Regards,
Shai Eyal
SAP Logistics senior consultant
SAP Workflow specialist
http://www.linkedin.com/in/shaieyal
Mobile: 972-52-5816633

________________________________
From: "sap-wug-request at mit.edu" <sap-wug-request at mit.edu>
To: sap-wug at mit.edu
Sent: Friday, October 31, 2008 18:24:12
Subject: SAP-WUG Digest, Vol 47, Issue 40

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. RE: Event Activation/Deactivation (Penhall, Kathy)
  2. Deadline - Latest End Recipient of Message (Simon, Tom)

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

Message: 1
Date: Fri, 31 Oct 2008 10:32:05 -0500
From: "Penhall, Kathy" <kpenhall at hydro.mb.ca>
Subject: RE: Event Activation/Deactivation
To: <sap-wug at mit.edu>
Message-ID:
    <CAD3E86E65D76C47BD61434EDFD7D10F01A126CA at MHMAIL02.hydro.mb.ca>
Content-Type: text/plain; charset="us-ascii"

Hi Mike,

Thanks for your response.  The event's behaviour on feedback setting was
system defaults (Deactivation of linkage), so I'm guessing this was what
deactivated our workflow.  We've never changed this setting in any of
our workflows.  Mystery solved.

Much appreciated.

Kathy 

Date: Mon, 27 Oct 2008 15:19:25 +0000
From: Mike Gambier <madgambler at hotmail.com>
Subject: RE: Event Activation/Deactivation
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Message-ID: <BAY117-W18B5D13196FD33C3922B1CD5240 at phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"

Kathy,

Despite our controls on people changing linkages using SWETYPV, we have
the odd linkage broken from time to time too.

Usually the cause is one of three things:

1. The 'Behaviour Upon Feedback' setting was left as 'System defaults'
and a severe enough error caused the linkage to deactivate. We tend to
prefer 'Do Not Change Linkage' when the event is handling high volume or
business critical Workflows so that this doesn't happen. If this has
happened to you I'd expect to see something in SWEQADM if you had turned
on the Event Queue enablied feature.

2. Somebody mucked around with the settings in development and forgot to
'undo' or 'correct' their changes before sending through their
Transport. It happens. Can't do much about it.

3. Someone clicked on the 'Deactivate Linkage' icon in the Workflow
Builder (Header Data->Version INdependent->Start Events). This can
happen by accident because the icon is right next to the Event Container
Binding icon. Requires a bit of knowledge to find of course.

To counter these we keep a close eye on the settings by running reports
on the SWETYPV settings and check what linkages are active against a
list we try to keep up to date.
Regards,

Mike GT

> ______________________________________________ 
> From:     Penhall, Kathy  
> Sent:    Monday, October 27, 2008 9:26 AM
> To:    'sap-wug at mit.edu'
> Subject:    Event Activation/Deactivation
> 
> Hello all,
> 
> We are on ECC 6.0 and have been processing training requests via
> workflow prior to and since our upgrade in October 2007.  We book
> original training requests using WS01200151 which is generated by the
> event PDRELA_025-REQUESTED when training is requested by employees in
> ESS.  Late last week this event seems to have been deactivated in our
> production landscape - no transports had been moved and it happened
> mid-morning.  One user who was booking a number of training requests
> said he'd done it one minute, and it stopped working the next.  
> 
> Normally we activate events in DEV via transaction PFTC and create a
> transport to move the event activation forward through our landscape
> and into PRD.  I realize how easy it is to deactivate an event in this
> way in any system, and as a result very few people have access to the
> transaction in production.  I was happy to discover I could
> re-activate the event directly in production (seems to me I could not
> do this in version 4.6C), so we did this and all was right with the
> world again.  Then we attempted to find out who had run transaction
> PFTC between the time the event stopped working and when it was
> "fixed".  The only evidence we found was that the event had been
> re-activated by me.  
> 
> So my question is, how else might this event have been de-activated?
> Or should we have done our investigation before we "fixed" the
> problem?  Your help solving this mystery is appreciated.
> 
> 
> Kathy Penhall 
> HR Applications
> SAP Support Services 
> Manitoba Hydro
> 693 Taylor Avenue
> Winnipeg, MB
> (tel)204-477-7197 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081031/240a6472/attachment-0001.htm

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

Message: 2
Date: Fri, 31 Oct 2008 11:46:26 -0400
From: "Simon, Tom" <Simon.Tom at aoins.com>
Subject: Deadline - Latest End Recipient of Message
To: sap-wug at mit.edu
Message-ID:
    <A67DFD136BC63D469A22EA616D31ED9F0434815B at EXCVSRV2.aoins.com>
Content-Type: text/plain; charset="us-ascii"

Shai,
        In the deadline,  I wanted the agent assignment to be the
superior of the agent who is to execute the approval step.  The problem
with assigning rule 168 in the step for the deadline is that the
workflow container does not contain the result of the rule for the agent
to approve the step until after it is executed.  If the step is not
executed,  the binding between task and workflow is not completed.  The
task container contains the results of the rule.  That is why I am
relying on the default rules of the task to execute the rule 168.  This
binds the results from the task to the default rule to determine the
superior of the agent who is has been chosen to execute the step.  If I
knew of a business object with a method that I could use to determine
successive hierarchal agents for a initiator of a workflow I could then
create an activity step to fill these agent variables and use them in
rule 168 for the deadline.  

Thank you

Tom Simon  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081031/a91a7b85/attachment-0001.htm

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

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

End of SAP-WUG Digest, Vol 47, Issue 40
***************************************

      New Email names for you! 
Get the Email name you&#39;ve always wanted on the new @ymail and @rocketmail. 
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081031/1084d3c9/attachment.htm