nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

activation element in workflow

NathansDIS

Hello all-

I have been working on a new workflow, primarily by poaching code from existing, working workflows and am wondering about the activation element in some of the task elements. I have used tasks that have the activation element and identical tasks w/o the activation element and they are functionally identical. Can someone explain to me what the purpose of the activation element is and if its use is a best/worst practice? I've been to the intro wft training, and don't remember them covering this.

FYI: we are on Windows 2000, TeamSite 6.1 SP1. I don't know if this matters, but some of the workflows (with the activation element) were originally developed for TS 5.x. Thx in advance for any info, insight, flames, etc.

-Nathan
Washington State DIS

Edited by NathansDIS on 01/18/05 09:21 AM (server time).

Find more posts tagged with

Comments

Adam Stoller

The activation element, along with inactivate and resets elements are essentially only needed when you have concurrent task operations in your workflow.

The activation element is used to say that a given task should become active only if certain logical conditions are true (e.g. task D becomes active only after tasks A, B, and C, have succesfully transitioned to it; or task D becomes active if tasks A&B, A&C, or B&C have succesfully transitioned to it [2-out-of-3])

The inactivate element is used to forcibly inactivate a task when a condition has occurred - using the first example I gave for activation - if you have tasks A, B, and C, transitioning either to task D [good] or Z [bad] and you know it is an all-or-nothing transition for D, then as soon as Z becomes active (based on A, B, *or* C transitioning to it) explicitly inactivate all three tasks A, B, *and* C because there's no point in having anyone else complete those tasks since we've already determined that the transition is to Z and not D.

The resets element is used to reset the status tracking for a task like D in the previous example. If A transitions to D, and then B transitions to Z causing Z to inactivate A [already transitioned to D], B [already transitioned to Z], and C [not yet transitioned] and Z ends up looping back such that all three tasks A, B, and C are re-activated again -- if you do *not* reset D, then the second time through it "remembers" that A already transitioned to it and so therefore B & C could transition to D before the owner of task A gets to work and they will have successfully activated task D. On the other hand, if you *do* reset D as soon as Z becomes activated, then the next time through it's like starting with a clean slate and you're still waiting for all three tasks (A, B, and C) to transition to D before activating it.

I believe some, if not all of this, is covered in the workflow tutorial supplement available on this site.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

However, I would argue that you should always explicitly include the activation data. It enables better consistency checking on the part of the instantiator, and it makes your intentions more clear to folks coming in after you.

Adam Stoller

I'd actually argue against using the activation clause unless you need it because, IMO, it makes it harder to maintain and/or modify the wft. I'd rather have good documentation with clear graphics than activation clauses in the wft -- but that's me. They're optional in a serial workflow process so feel free to use them or lose them as you see fit. They're generally needed in concurrent workflow processes - if you leave them out you'll probably get a lot of unintended behavior that will confuse and mystify everyone ;-)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Johnny

If you use an API like TeamSIte::WFConstructor to programmatically build your workflow, you don't need to worry about it either way!

John Cuiuli

Migrateduser

I agree. My one beef with WFconstructor is that (at the moment anyway), it's an all or nothing proposition. If one could generate just a fragment with it, it would be way easier to begin phasing it in. For the last couple of years, I've found myself maintaining or extending wfts that someone else had written instead of starting from scratch. In retrospect, in several of those situations, it probably would have made more sense to bite the bullet and do it. Of course, you also run into the "will whoever comes after me be able to maintain it" issue.

Johnny

True,

but when you are adding bits here and there to the WF programmatically, I really think an API like this is waaaayyy easier to maintain than bits and pieces of xml snippets... It makes the WFT so messy.

This basically turns it around from writing an XML document and embedding PERL bits into it to writing a PERL program that outputs XML.

Biting the bullet is the first thing I do when I have to touch something old AND complicated.
They just have a couple bugs to iron out.

John Cuiuli

Migrateduser

Going even further, TeamSite would be a way more useful and powerful tool if there was a way to create workflows with a GUI. Don't mention WFB because that is a piece of ****. If only IW had put in the effort to really build a useful WF generation GUI, it would be so much easier to use this product. Even when they go to Java WF, it would have still been better to have made it a graphical tool instead of a programmatical one. Sure you'd still need to build your externaltask and CGI scripts, but the construction and maintenance of the flow and the linkages would be so much better.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

NathansDIS

Thanks for the info guys. I guess the intention of the activation element would have been more clear had my simple workflow example had more than a single predecessor for each task. I'll consider you suggestion about the self-documenting nature of the activation element, however it is sometimes hard to justify changes to a functioning code segment.

NathansDIS

I have to agree with Smitty; WFB truly is a piece of ****. Even the instructor in training couldn't get the simple lab exercise to work. He had to result to directly editing the XML to get the wft to work, which of course means that you can never use WFB to edit it again. If I was IW brass, I would consider this product an embarassment to be either replaced or promptly swept under the carpet. I certianly couldn't justify continuing to bundle it with a purportedly enterprise class application package.

-n