finding out information about completed Workflows

As far as I know, there is no way without custom coding a solution. There never has been a way. The solutions I've seen are to have a task in the workflow that writes the object info for that job to a log file before the job ends. Also, adding a dummy task near the end of the job so that the job doesn't just disappear as soon as it's complete is another idea. That way if someone calls you with a concern about the job before that dummy task completes, you can go and look at every nook and cranny of the job.

Let me know if that helps.

- Jason

For the record - I believe that keeping jobs around for extended periods of time with dummytasks is [still] *not* recommended, for performance reasons (I forget the exact number, but I think it was something like 2000 tasks in the system starts to show performance degredation) - so dumping the information to either flat-file or DB just prior to ending the workflow is still the recommended way to store job audit trails.

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

I have a script I run at the end of all my workflows that goes beyond just storing the iwgetwfobj info - it parses out the particular info I want and saves it in a nicely formatted way. I then save these history files for 30 days. If you want a copy of this script, email me.

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

nipper

IW Consulting has (for 552) and sells a package that will graphically display active jobs and also
log (for some workflow reporting) completed jobs.

We have it loaded & with several hundred jobs per day it runs nicely. I do not use it often
but it is nice when I use it.

Not cheap, but may be worth while, I wish IW would productize it.

Andy

Why anyone would pay extra for something that should be part of the product just baffles me. If that keeps up, soon we'll have to pay for training because Interwoven will stop making manuals. Oh wait...

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

nipper

>Why anyone would pay extra for something that should be part of the product just baffles me

Well what should be part of the product is really up to Interwoven.

So we should go to GearUp and the Focus groups and complain.

Oh, wait.......

The net result is that you can spend time writing it (which you did) or you can spend some bucks &
buy what they provide. FWIW, I suspect it would have been cheaper for me to write the thing rather
than spending money on it. IIRC, you were looking at this, so I assume you made that call.

I would love to hear IW's take since before I started working at IW (1999) there were a bunch of
complaints about the lack of reporting, There was no workflow then, so no one complained about
the lack of WF reporting.

Andy

Why was the WF "Plus Pack" (workflow reporting) a cost-item ? Because it was developed by the consultants and not by Engineering.

Why wasn't workflow reporting provided by Engineering? Well - that's a tougher one - I think it's been started on several times, but somehow keeps getting pushed to a back-burner in favor of something else.

The cost-tradeoff is figuring out how much it costs your company to pay you to develop a reporting mechanism vs. how much it costs to buy something that someone else has already produced. The "plus" factor in favor of the "Plus Pack" is the graphical UI - which is nice, but if you don't need it you can probably whip up something fairly quickly yourself using the tools at hand (iwgetwfobj, and/or TeamSite::WFsystem, TeamSite::WFworkflow, TeamSite::WFtask, and/or possibly some OpenAPI and/or CSSDK functions)

For what it's worth - the lack of a true audit trail for workflows was mentioned when workflow was first introduced in 4.0 - but again, for one reason or another it seems to keep getting taken off the front-burner.

Maybe when the object-oriented workflow development is released it will contain built-in reporting...

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

Forgive me, but don't the consultants and engineering work for the same company? Why should it make a difference which group of people came up with the solution? The point is, it wasn't an enhancement to something that we already have - that might justify selling it as a separate add-on. It's something we don't have that pretty much everyone who uses workflow wants. It came up as a sore subject at every Focus Group I attended. Workflow reporting and archiving has been a glaring hole for years in the workflow system. Workflow is one of the only reasons Nike can sell TeamSite to some of our users. Interwoven has not made any major changes to workflow in years. I couldn't care less whether consulting or engineering created a useful tool. Just make it part of the product. Making us pay for it is asinine.

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

I won't argue about the idea of having to pay for workflow reporting, that should have been part of the product from the beginning, is wrong.

The issue of who developed it is a semantic thing - engineering gets paid by Interwoven to develop products, consultants need to generate revenue for the time they spend doing development *and* for any continued maintenance and development on such "products" - and thus a consultant-created "product" is charged for separately from and engineer-created product.

I neither agree nor disagree with the above policy - I state it simply as the rationale (as *I* understand it) behind why the "Plus Pack" costs additional money.

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

I'll admit that the dummy task might not be a good idea in an extremely high workflow volume environment, but if there's only a few workflows going through per day, it doesn't hurt to have a workflow hang around for 24 hours. One thing to be aware of is that if a workflow is stopped at the dummy task and someone tries to workflow a file that's in the other workflow (the one waiting at the dummy task), then there will be a conflict if there's a submit task. This is because the file is in 2 workflows at the same time.

- Jason

One way to avoid having same file in two workflows is to check before the start of the workflow if the files workflowed are part of another workflow. This would ensure that one file is part of one workflow at a given point in time.

Even better might be to check if the file is already in a workflow, check what task that workflow is in. If the workflow is at an archive task, just transition the archive task to end the workflow.

- Jason

But a user or process could add any file to the job after workflow instantiation. You could have every externaltask check if each file associated with the task is associated with any task in any other job in any workarea on the same branch (and other branches if you are using integration branching) and trap this condition as some kind of error, but this may also be overkill that could hurt performance.

You don't have to worry about dummytasks being associated with files (even though it seems logical, there does not seem to be a relationship between the dummytask and the files associated with the other tasks in that job - this is actually more of a problem if you have the dummytask in the middle of the workflow instead of at the end), but if your archive tasks are grouptasks (for instance if you want your users to be able to end the archive period) you would have this concern.

Johnny

I would like to know more on how we can overcome that issue in a practical manner.

We have several checks during job initiation including looking for existing locks aswell as files already attached to jobs.

You cannot put any kind of control over usertasks that are not read only. Apart from something messy like external tasks, how would one handle checks on attaching files?

John Cuiuli

We user the following process: When users start a new workflow we check if the files are part of another workflow. This would ensure that users don't start multiple workflows with the same file. After the workflow starts, we lock the files to SYSTEM. Other users would not be able to edit this file ( we have one workarea per branch) and the workflow system transitions file locks between tasks so that the person who started the workflow would be able to edit files in their usertask. Since the files are already locked, users would not be able to attach the same files to other workflows. We also ensure that the workflows don't lie in dummy task for long ( < 30 min) and dump the workflow state information to flat file before they disappear.

-- tu

I don't believe that a file being locked prevents it (from the underlying system perspective) from being attached to a job.
I don't know any way [in the system as it stands today] other than using externaltasks to perform this check - which is what we do at my current customer's site - much like what John indicated a few posts ago. This check is performed at the beginning and after each user/group task, and if a problem is found (*) the workflow transitions to an error handling task.

(* the file is part of another job, the file is locked by someone other than the person who should be holding locks on all the files at this stage in the workflow, the file is locked in another workarea [unlikely since we only have one workarea per branch - but ...])

I don't think the performance is all that bad as both iwfilestate and iwgetfilejobs allow multiple files to be processed in a single invokation - the biggest overhead would be the use of iwlockinfo which currently only takes a single file per run, but by using the first two programs to weed through the list you can reduce the number of times you need to run the last tool (which you only have to do if you have multiple workareas). All the rest is a question of data-processing.

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

Johnny

Yeah I guess my real problem is with usability.

It's pretty much the only way to do this, but it happens indirectly from the users point of view. It would really throw our business users.

I guess I would be talking about a feature request for a hook into file events in a user task???...

Wouldn't that be more seemless?

Anything else is really a workaround.

John Cuiuli

http://www.quotient-inc.com

I agree - it should be more seamless, and frankly I think there are at least two things I'd like to see as improvements in this area:

Fish -- Correct me if I am wrong. What we do at our place is have usertask/grouptask lock='t' attribute set. When a user tries to add existing files which are locked to SYSTEM or other users, workflow fails to add files with the message " Error adding file '/abc.html': Object is being reserved by someone else". This prevents users from adding files already part of another workflow( since the files are already locked to SYSTEM). This process works perfectly fine for us and wanted to know if we have this working due to an inherent problem with current system or an expected behavior?

Good question - I don't know.

I know that you cannot *edit* a file [through the GUI] that is locked by someone else - without at least responding to a dialog box - but I wasn't aware that having a file locked by someone else (does it have to be someone else? can it be anyone else or just SYSTEM?) prevented that file from being able to be added to a workflow (through the GUI or through TeamSite::WFtask / iwaddtaskfile operations?)

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

(does it have to be someone else? can it be anyone else or just SYSTEM?)
It works for us both ways, the file locked to SYSTEM or other user. We ensure that all files in the workflow are locked to SYSTEM and the locks transfer to users when they take ownership of task.

(through the GUI or through TeamSite::WFtask / iwaddtaskfile operations?)
It works both from GUI and Command line.

One more thing we found was that the performance was bad and it takes a long time to display the error message (TeamSite on windows) when the users try to add files locked by other users. The problem appears in the branches where we have lot many files (with many files locked ) than the smaller branches. It could be based on the number of files we have locked in the workarea.