Deactivating Workflows in QA/PRD loses triggering events

[Michael Pokraka]

Thanks yet again, that should do for our purposes. On our 4.6c system I
could however only find SWE_EVENT_RECEIVER_ERROR. Looking at the code it
seems like that does the job as well, I'll do my bit of testing and
debugging and probably create a report for this.
 
The activation/deactivation should not be a regular requirement in any
case, though I would consider it a useful addition to future SAP
releases.
Cheers
Michael
 
On Wed, Nov 20, 2002 at 09:25:13AM +0100, Dart, Jocelyn wrote:
> Hi Michael,
> All as in all event linkages with "System presetting" as their behaviour
> on feedback (system presetting = get it from the SWEQADM Basic Data).
> SWEQADM lets you change the event linkage from "Errors" to "No Errors" after
> a problem.  I'm pretty sure that doesn't require a change request as this is
> considered standard workflow admin follow up but it has to be done from SWEQADM
> not from SWETYPV.
>
> FM SWE_EVENT_RECEIVE_ERROR_SIGNAL is used to trigger the setting of the event
> to "Errors" status.  Not released for customer but should be ok to use for what you
> want to do e.g. in a custom program, and you never got it from me! ;-)
>
> Might be a good idea to request a way to manually set an event linkage into Errors
> status - sounds like a good idea for a development request if you want to take
> it further.
> Regards,
>         Jocelyn Dart
> Consultant (SRM, EBP, Workflow)
> and co-author of the book
> "Practical Workflow for SAP"
> SAP Australia
> email: jocelyn.dart at sap.com
> phone: +61 412 390 267
> fax:   +61 2 9935 4880
>
>
>
>
>
> -----Original Message-----
>> From: Michael Pokraka [mailto:workflow at quirky.me.uk]
> Sent: Wednesday, 20 November 2002 1:54 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Deactivating Workflows in QA/PRD loses triggering events
>
>
> Hi Jocelyn,
> Thanks for the clarification - it was not immediately clear to me that
> the event queue would capture _all_ error linkages.
>
> Last question on the topic: sounds simple, but some hours searching have
> been fruitless - is there a way to manually mark an event as
> in error? PRD/QA won't let me, seems that this setting is grouped in the
> same category as 'active/inactive', which means transport or to
> deliberately try to trash something (not always a good idea)
>
> By the way, I did find a sneak workaround to reactivate a linkage
> without a transport... SE37.
>
> Thanks
> Mike
>
>
> On Mon, Nov 18, 2002 at 10:06:44AM +0100, Dart, Jocelyn wrote:
> > Hi Mike,
> > In transaction SWEQADM, on the "Basic Data" tab set the "Behaviour on error feedback"
> > to be "Mark linkages as having errors" and then the queue will capture failed events
> > for all event linkages by default.  You can also set the same field in SWETYPV on an
> > individual event linkage basis.
> >
> > Failed events are captured but not automatically redelivered - they show up in the
> > "Event linkages with errors" section of SWEQADM and an administrator can choose to
> > either redeliver manually or request the event queue job to include those failed
> > events (but this inclusion still has to be sanctioned by an administrator).
> >
> > There is a fair bit of doco in SAP Library (go to site help.sap.com if you don't
> > have the latest help) and a section on it in the book.
> >
> > Hope that helps.
> > Regards,
> >         Jocelyn Dart
> > Consultant (SRM, EBP, Workflow)
> > and co-author of the book
> > "Practical Workflow for SAP"
> > SAP Australia
> > email: jocelyn.dart at sap.com
> > phone: +61 412 390 267
> > fax:   +61 2 9935 4880
> >
> >
> >
> >
> > -----Original Message-----
> > From: Michael Pokraka [mailto:workflow at quirky.me.uk]
> > Sent: Friday, 15 November 2002 9:14 PM
> > To: SAP-WUG at MITVMA.MIT.EDU
> > Subject: Re: Deactivating Workflows in QA/PRD loses triggering events
> >
> >
> > Hi Jocelyn,
> > I'm a bit confused now - was not aware that the event q can hold failed
> > events even though they are set up to run normally???
> > Where is this set up, or does it happen automatically?
> >
> > Actually, I'm not near a system at the moment, so don't bother answering
> > if it's obvious, I'll have a look when I'm next on a system.
> >
> > Thanks
> > Mike
> >
> > On Fri, Nov 15, 2002 at 03:45:47AM +0100, Dart, Jocelyn wrote:
> > > Hi Michael,
> > > There's a difference between using the event queue to deliver
> > > events in the first instance, versus using the event queue to capture
> > > and redeliver failed events.
> > >
> > > It's capturing failed events that should always be on.
> > > Volume event delivery should only be used if you need it.
> > >
> > > Jocelyn.
> > >
> > > -----Original Message-----
> > > From: Michael Pokraka [mailto:workflow at quirky.me.uk]
> > > Sent: Friday, 15 November 2002 12:53 PM
> > > To: SAP-WUG at MITVMA.MIT.EDU
> > > Subject: Re: Deactivating Workflows in QA/PRD loses triggering events
> > >
> > >
> > > Hi Jocelyn,
> > > ...and there was me trying to avoid the event queue wherever possible
> > > :-)  This was for two reasons:
> > >
> > > * it introduces an often unnecessary delay. e.g. a 'manual' workflow
> > > should run straight away if the event queue is bottled up for 20min due
> > > to a big batch run. (slow as they sometimes can be, users are an
> > > impatient lot too! :-)
> > >
> > > * I've experienced quite a few stability issues with the event queue.
> > > Nothing terribly specific I could raise with SAP, mostly once-offs like
> > > e.g. a spurious network problem causing an RFC to fail which in turn
> > > caused the SWEQUEUE job to fall over and stop running alltogether. As
> > > you pointed out however the events are still there.
> > >
> > > What you said does however make sense, and given that we think we've
> > > addressed the stability bits with monitors and the likes, I will rethink
> > > my strategy on the whole queue bit.
> > >
> > > Thanks for your (as usual) valuable input
> > > Mike
> > >
> > >
> > > On Fri, 2002-11-15 at 01:02, Dart, Jocelyn wrote:
> > > > > ----------
> > > > > From:       Dart, Jocelyn[SMTP:JOCELYN.DART at SAP.COM]
> > > > > Sent:       Friday, November 15, 2002 1:02:05 AM
> > > > > To:         SAP-WUG at MITVMA.MIT.EDU
> > > > > Subject:    Re: Deactivating Workflows in QA/PRD loses triggering events
> > > > > Auto forwarded by a Rule
> > > > >
> > > > Hi Michael,
> > > > These sorts of decisions tend to be agonized over and there are always good
> > > > arguments for both sides. However, these decisions can be changed but usually
> > > > you are talking about getting consensus from some fairly major user groups. However
> > > > you can explore that avenue if you wish.
> > > >
> > > > To avoid the activate/deactivate quandary, the event queue was introduced.
> > > > Instead of deactivating your event linkage you can mark it as in error -
> > > > using the event queue to capture the failed events until you have fixed the
> > > > problem and are ready to redeliver them.
> > > >
> > > > Yet another reason to always use the event queue if you are in 4.6C or above.
> > > > Regards,
> > > >         Jocelyn Dart
> > > > Consultant (SRM, EBP, Workflow)
> > > > and co-author of the book
> > > > "Practical Workflow for SAP"
> > > > SAP Australia
> > > > email: jocelyn.dart at sap.com
> > > > phone: +61 412 390 267
> > > > fax:   +61 2 9935 4880
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Pokraka, Michael [mailto:michael.pokraka at kcc.com]
> > > > Sent: Thursday, 14 November 2002 1:09 AM
> > > > To: SAP-WUG at MITVMA.MIT.EDU
> > > > Subject: Re: Deactivating Workflows in QA/PRD loses triggering events
> > > >
> > > >
> > > > Hi Jocelyn,
> > > > Thanks for your input. I kindof had it in mind that I could do this in
> > > > earlier versions (4.6c here).
> > > >
> > > > Perhaps a point of discussion: I would disagree with SAP's reasoning behind
> > > > this: deactivating a linkage could be considered just as serious - if e.g. a
> > > > flow if deactivated by mistake (just one click) and a few hundred
> > > > transactions go through in the meantime that _require_ the WF to happen, it
> > > > could be a minor nightmare to gather and restart all the necessary flows.
> > > >
> > > > On the other hand, suppose a workflow goes horribly wrong during a mass
> > > > input (e.g. IDOCs) and has to be deactivated (e.g. I've seen an endless loop
> > > > due to a WF causing the same event that started it). The cause might be
> > > > something basic relating to the data. Now in this case it's perfectly
> > > > reasonable to deactivate and reactivate the linkage and rerun the job.
> > > >
> > > > I would think that the activation/deactivation should be available in prod,
> > > > though under similar security as SWIA (execute WI without agent check).
> > > >
> > > > Cheers
> > > > Michael
> > > >
> > > > -----Original Message-----
> > > > From: Dart, Jocelyn [mailto:jocelyn.dart at sap.com]
> > > > Sent: 13 November 2002 10:07
> > > > To: SAP-WUG at MITVMA.MIT.EDU
> > > > Subject: Re: Deactivating Workflows in QA/PRD loses triggering events
> > > >
> > > >
> > > > Hi Michael,
> > > > Ability to deactivate event linkage does not require change request as you
> > > > may need to use this in an emergency to stop a production workflow.
> > > > However activating a workflow is considered more serious and therefore
> > > > requires
> > > > change request or else transport from another system (DEV/TST).
> > > > Using other ways of getting to the triggering event will still
> > > > require a change request/transport.
> > > >
> > > > Basic Data > Start events should show same view as triggering events but has
> > > > some little "undocumented features"... Have a look for some OSS notes and if
> > > > you can't find any report it in via OSS please.
> > > > Regards,
> > > >         Jocelyn Dart
> > > > Consultant (SRM, EBP, Workflow)
> > > > and co-author of the book
> > > > "Practical Workflow for SAP"
> > > > SAP Australia
> > > > email: jocelyn.dart at sap.com
> > > > phone: +61 412 390 267
> > > > fax:   +61 2 9935 4880
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Pokraka, Michael [mailto:michael.pokraka at kcc.com]
> > > > Sent: Wednesday, 13 November 2002 3:45 AM
> > > > To: SAP-WUG at MITVMA.MIT.EDU
> > > > Subject: Re: Deactivating Workflows in QA/PRD loses triggering events
> > > >
> > > >
> > > > Hi all,
> > > > Could someone please explain the following before I lose my marbles:
> > > > If I edit a task via PFTC (Disp/Maintain task), I can go to 'triggering
> > > > events' and deactivate by clicking on the green light, even though event
> > > > linkage is blocked in QA or PRD. However I cannot activate it ("Client nnn
> > > > has status 'not modifiable'").
> > > >
> > > > Now, here's where my grip on reality starts to slip:
> > > > So I thought I should be using SWDD (Workflow Builder). Go to the template
> > > > display, click on 'Basic Data' (little hat), and since I deactivated in PFTC
> > > > the events are no longer to be seen - the list is empty. The event linkages
> > > > are still there in SWETYPV, just not active.
> > > >
> > > > What exactly does the workflow builder's "Basic Data -> Start" tab show if
> > > > not the event linkage table????? I've checked - all relevant entries exist
> > > > in tables SWETYPECOU and SWETYPEENA (just missing the 'active' flag)....
> > > > What gives?
> > > >
> > > > Any revelations greatly appreciated!
> > > >
> > > > Cheers
> > > > Mike
> > > >
> > > > ----------------------------------------------------------------------------
> > > > --
> > > > This e-mail is intended for the use of the addressee(s) only and may contain
> > > > privileged, confidential, or proprietary information that is exempt from
> > > > disclosure under law.  If you have received this message in error, please
> > > > inform us promptly by reply e-mail, then delete the e-mail and destroy any
> > > > printed copy.   Thank you.
> > > >
> > > > ============================================================================
> > > > ==
> > > >
> > > > ------------------------------------------------------------------------------
> > > > This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law.  If you have received this message in error, please inform us promptly by reply e-mail, then delete the e-mail and destroy any
> > > > printed copy.   Thank you.
> > > >
> > > > ==============================================================================