Event Activation/Deactivation

[Mike Gambier]

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



Subject: Event Activation/DeactivationDate: Mon, 27 Oct 2008 09:25:41 -0500From: kpenhall at hydro.mb.caTo: sap-wug at mit.edu

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 PenhallHR ApplicationsSAP Support Services Manitoba Hydro693 Taylor AvenueWinnipeg, MB(tel)204-477-7197
_________________________________________________________________
See the most popular videos on the web 
http://clk.atdmt.com/GBL/go/115454061/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081027/b3989009/attachment.htm