Deactivating Workflows in QA/PRD loses triggering events

[Michael Pokraka]

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