Workflow questions

Does anyone know how to handle an exception workflow? What we would want to do is have a workflow set up that does not include a particular approver; but if a piece of content is critical enough, the user sends it to an additional approver. I think the catch here is that the "extra" approver may not always be the same group or person.

One additional question....is there a way for a writer or manager to view the workflow visually within Teamsite and see where a piece of content is in the visual depiction? If not, any other ideas?

Find more posts tagged with

Comments

Adam Stoller

You can generate the review task during instantiation with a default value for the owner - but precede it with a cgitask which would be an optional transition from the task before it. The cgitask script could prompt for a user to do the review, and then re-set the owner of the review task prior to transitioning to it (actually you can get fancier and modifiy a notification task too).

So it looks something like this:
...
[usertask (A)] => {"Done", "Get Review"}
"Done" => [submittask]
"Get Review" => [cgitask] => [usertask (B)] => {"Reject", "Approve"}
"Reject" => [usertask (A)]
"Approve" => [submittask]
...

Routines in TeamSite::WFworkflow and TeamSite::WFtask can greatly assist. If you want to hook in the notification - iwsend_mail.ipl (5.5.2) supports task-level variables - so when you reset the owner of the review task [usertask (B)] you could at the same time set the "mail_to" variable for an externaltask just prior to it.

[cgitask] => (set mail_to on notification, set owner on review) => [externaltask] => [usertask (B)]

As for your additional question - the WorkflowPlusPack (an Interwoven Consulting Services product) provides functionality like this - talk to your Interwoven Sales and/or Consulting representatives for more information.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

I so enjoy when someone from Interwoven brings up the Workflow Plus Pak. Thank you Adam. Once again I get to convey my disappointment that Interwoven would expect their customers, who dolled out many thousands of dollars for this product, to pay many more thousands to install a feature that should be included in the product as a no-brainer. One of the main topics at the Workflow Focus Group recently was that people wanted some sort of graphical representation of their workflows in the GUI. I'm curious if anyone from Interwoven will step up to the plate and let us know if this is something that we can expect in the next major release of TeamSite or whether they will simply be expecting us to pay for this "feature". What's being done to satisfy the many customers who asked for this?

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

Migrateduser

That's funny Dave, I can see this from a totally different perspective.

I completely concur with the "disappointment" regarding Interwoven. Working with the company always feels like a non-stop sales pitch - even when you are buying or have bought something from them they are trying to sell you something else. And don't forget that on top of the hardware and licensing, most customers need to spend a significant amount on consulting just to get TeamSite to do what they were told it could do during sales. Then there's the whole upgrades issue; I won't even get started on that topic...

I always feel that Interwoven sells customers on dozens of features that should exist in the base product, might exist but not always work correctly or could exist if custom developed. I feel like they are so busy trying to add features and products so they can sell it harder that they don't focus on what should be their core competencies. For instance I was really hoping 5.5 would fix some of the architectural flaws in the product and the disintegration of TeamSite, Templating, and OpenDeploy, but instead it appears that the main focus was performance. While I appreciate this and understand that certain operations have been optimized, my users don't care how many milliseconds it takes an ExternalTask to perform some batch operation on a group of files; they care how long it takes to bring up the templating window, which is still dismal.

I think it's perverse that it takes consulting to get the product and the plus pack to work at all, or at least to get the features working correctly. Since this plus pack is apparently only sold with consulting, there must be something seriously wrong with it, so if they bundled it the average customer might just have more problems. So I can see why they don't bundle it.

It does kind of feel like Windows 95, when to get nominal functionality I also had to buy the plus pack.

gzevin

John,

you are more than right... I cannot tell much more as as former IWOV consultant, I have signed some confidentiality statements, but I can tell you that I myself have been reprimanded a few times just because I was sincere with the clients (and they did actually trust me more after I told them how the product worked, etc). Or.. for example.. they (sales) telling me - why don't you use WF Builder and recommend this to customers - I said I don't and I waon't as this is ****.. and this was one of the reasons I was made to leave.....

Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Both of you make some good valid points. I definitely agree that the sales pitch sometimes goes well beyond the capabilities of what the procucts can do without a significant amount of work. I found the Interwoven management team truly hurt when it was clear that nobody uses or wants WorkflowBuilder in its current form. I'm hoping they are starting to "get it" but I won't be sure until I see what they do in the next major release. I have asked many times in this forum what their intentions are, only to find Interwoven engineers suddenly not answering my posts. As far as the Plus Pak, I'm sure you both saw those 2 dudes from some 3rd party company hawking their workflow reporting tool. Of course when I asked 3 or 4 times they still didn't tell me how much it cost. It truly sucks that the only major thing done with workflow since the 4.2.1 version was to create Workflow Builder. What a waste.

By the way, this would be a good thread for someone from Interwoven (Brinko? James?) to jump in and put our fears to rest. I'm still waiting for answer to my original question. What are your intentions as far as workflow GUI, archiving and reporting in the next release of TeamSite?

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

Migrateduser

If someone from Interwoven really is going to look at this, I have one very serious request. On the last three projects I have been on, one of which was probably Interwoven's biggest customer, there has been a strong resistance to doing anything in Perl (two were .NET and one was Java). This means that even if workflow builder worked, they would not want to use it. I feel that what we as workflow developers need is an API/class library for developing workflow tasks rather than hard-coding XML in .wft files. I have had to build these class libraries myself in .NET and Java. On one project we built ASPX pages to replace the workflow instantiation form, but on the other two we have to call .NET and Java from Perl in the .wft. Workflow should not be so language-specific. Some of us prefer to avoid coding in Perl.

Another things that really bothers me is that many customers think they can actually have non-technical people build workflows using WorkflowBuilder. To build workflows you have to understand quite a bit about TeamSite, which requires technical skills. I don't see how you could build a workflow in WorkflowBuilder without knowing the intricacies of workflow job XML, which I believe only comes from having built them by hand.

Another is that the default/example workflows are so bad (no deployment, no automated regeneration of content, etc. - not even stubs for these activities). Unless I just haven't looked at them recently enough.

I also have built workflow reporting tools. Using the TeamSite modules it's really not that hard (though performance can be pretty bad), but I can't believe it would be possible to buy one off the shelf (since workflows are all typically custom). At that biggest customer we built a system to log all workflow activity to a database and run reports against that.

Migrateduser

I think Interwoven is attempting to open up at least part of the workflow development to being non-perl dependent, but they threw that slide up at the end of the focus group and didn't have time to discuss it. That was because we spent 45 minutes of the 1 hour focus group being prodded to talk about Workflow Builder, which in the end it was decided that no one wanted or cared about Workflow Builder. I wish you were at that Focus Group, John - you would have had some really good things to recommend. I was also sent a preliminary set of slides from an Interwoven engineer titled TeamSite Workflow: Next Steps. It had, I believe, summarized the main pain points people submitted in the Focus Group (we all got a bunch of yellow stickies to fill in our pain points and paste them on the wall) and I got to provide input as far as my priorities for these pain points. They were broken down into these sections:

o Job and Task Management
o Workflow Monitoring and Reporting
o Building Workflows

I never heard back from the engineer after reporting back my feedback, so I don't know what the plans are. If they do take these pain points seriously, I believe they will be going in the right direction. On the other hand, if all they do is work on Workflow Builder, we are doomed.

I have a feeling we won't get much of a response from Interwoven here in this forum.

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

gzevin

John,

the sales actually never mention Perl as someting essential to work with TeamSite. They will admit only when cornered.
I myself don't mind perl as such, but I do agree the coding layer should have been taken on a different level in a form of an API that is transparent to, say, Java, .NET, etc...

as far as 'out of the box' workflows are concerned. If everything was there already, how much money do you think IWOV consulting team would loose? Smiley Happy

Even now, when I am independent, this fact pays my bills Smiley Happy

Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Personally, I like using perl and was lucky enough to have contracted at Interwoven specifically designing workflows so I was able to learn how to build them from the engineers who architected the workflow engine itself. Not everyone can be so fortunate to have those resources available when they try and create a workflow for the first time. I will admit, I think workflow is a very complex beast. Can they make it easier? Perhaps, but I wouldn't want them to take away the ability to customize things as much as we can now. With this level of customization comes complexity. No getting around that. Workflow Builder was definitely not the solution - you can't try and simplify things to the point of not needing to know how the XML works, as John said. One thing that would be nice, but is way out there would be if Interwoven gave everyone who bought TeamSite one or two free Workflow Training classes. That would probably make at least half the workflow support cases go away. I know that would be expensive, but it's unlikely a lot of companies will spring for the training classes anyway and if they were able to get a free one, they could at least get someone up to speed quickly and it would certainly enhance their user experience. Workflow is hard. It sort of has to be regardless of what language you allow it to be coded in. Training is essential and there is no good tutorial or at-home training available, and the docs...well the docs just suck. If Interwoven made it easier for customers to get training for workflow, I think everyone would ultimately win.

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

Migrateduser

I've never worked directly for Interwoven (had concrete opportunities with them on three continents but turned it down each time) - but they've been paying my bills for 2.5 years. "Back in the .com days" they sent my wife and I to Europe for a couple of months, all expenses paid, and I went to Asia. I'm not complaining on my account, I'm complaining on the customers' account. I also feel that the work might dry up soon if Interwoven doesn't get their act together.

Actually, I can code in Perl if I have to, it's just that I don't know what IDE works, and the lack of compiler for error checking, the lack of strong typing, and my lack of understanding of object-oriented features of Perl are my downfall. Plus all the special characters - concatenation of strings with . instead of + always gets me.

I agree with Dave, workflow is hard with any language. But I have to say, it is easier with OO, especially .NET.

All the best,

-John

Edited by john on 01/27/03 03:10 PM (server time).

Adam Stoller

I cannot give details for a variety of reasons - but I think I can say (without getting into too much trouble) that the engineering folk *are* looking for a way to improve workflow development - but that it's a fairly large undertaking because we generally want to be backwards-compliant as much as possible.

One could look at something like OpenDeploy's iwodcfg2xml as a possible solution for bridging the gap between old and new versions of the source files - but, as has been pointed out - workflows allow a tremendous amount of flexibility / variety that didn't really exist in OpenDeploy 4.x configuration files - so trying to figure out how to bridge the gap ... and at the same time provide much of the desired *new* functionality will take some time to design / develop / test / revise / ..... before we have a sense of something able to be released.

In the meantime work is progressing to try to improve aspects of the current system to at least make it a bit easier to learn and use.

Will this solve everyones problems in the short-term - no.
Will this solve everyones problems in the long-term - no (nothing ever does).
Will this solve most problems in the long-term - hopefully the answer will be yes, and we'll be able to take it from there to wherever you folks continue to lead us.

Keep suggestions comming - but have a bit of patience. It's not that you aren't being heard, it's just that it's too soon in the development stages to really talk about it in any detail. (talking about it in detail now would be like the proverbial too many cooks -or- designing by committe problem) Have some faith, wait it out a bit, when it comes - then do a little pro-raving, and then you can go back to finding things that need to be fixed/modified/added ;-)

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Ghoti, are you really technical, or do you actually work in marketing? I always think of the conversion tools as something that marketing uses to get management think the upgrade is less of a challenge so they will buy into it.

From my perspective, the conversion tools for OpenDeploy were largely useless. For one thing, anyone responsible for the OpenDeploy system should know how to code the configuration files by hand. But beyond that, the OpenDeploy upgrade was a major infrastructure change - the command line used changed, the method for passing key/value pairs changed, the logging changed, the error trapping/lack thereof changed. I am not sure what didn't change, but it goes way beyond config files, which I think were a small part of it. And that doesn't even bring testing into account - many of us have huge systems with tons of machines, dependencies, processes and conditions to support and test.

I don't think it's fair for you to tell us that workflow will be changing but give no details - you should be seeking our feedback as the new architecture is developed, since we probably know about as much regarding how it should work as Interwoven does. Also, it has to be 100% backward compatible - I alone have spent hundreds of hours developing workflows and externaltask processes, which means that your customers must have invested tens of thousands. So you have to support the old .wft files, and maybe give us something new (maybe a real application server page for developing workflows). Running some tool to convert .wft files is not going to cut it.

And since there's no kitchen yet, there can't be too many cooks. Design before building.

Edited by john on 01/28/03 06:06 AM (server time).

Migrateduser

Thanks for the reply, but you didn't mention anything about reporting/archiving of workflows. This worries me as it was probably the biggest pain point that people brought up at the focus group. Please tell me that the Plus Pak is not going to be the way Interwoven is going to go for this type of tool.

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

Migrateduser

If you are using workflow XML to generate your reports, you can have an externaltask at the end of the workflow that writes the XML to a file such as wfid.xml in some known directory, then run the report against that if iwgetwfobj reports the job no longer exists.

I also put a dummytask at the end of all jobs that leaves the job in workflow history for some configurable period of time. I think this doesn't free up the job's resources, which means it could have a negative effect on performance.

Agreed that it should be part of the base product, no plus pack, no custom code.

Migrateduser

Yes, I already do some custom job archiving and that is enough to suit my needs to the point I find it ridiculous to pay for a Plus Pak or a third party product. The main reason I want Interwoven to put something in there is because the vast majority of customers want it and I want to see if Interwoven is paying attention or if they are simply going by some other agenda.

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

Adam Stoller

*** THIS IS MY PESONAL RESPONSE - NOT AN OFFICIAL STATEMENT OF INTERWOVEN ***

Please forgive me for bothering to try to tell you that improvements are being worked on. I was trying to respond to something that I saw in your posts of a feeling of "we're being ignored" - and my response was meant to say "no - you're not".

I *am* technical but I'm *not* involved with the development of the product, therefore I cannot provide more information about what is or is not being considered for the future of workflows other than it *is* being looked at and I would imagine that much of what is being planned is based on the feedback from the GearUp session and these forums.

I am *assuming* that backwards-compatibility is a high-focus item for any new development. Whether that happens through the use of a conversion tool or will be built directly into the product - I simply do not know. Clearly I think we all would prefer that it be built-in, seamless, and transparent to the installed-base. Hopefully it will be.

Trying to accomplish all of what has been asked for without breaking all of what's already other there is a *non-trivial* task that takes time and resources to develop. Ideas come up, get tried out, and either get scrapped or further developed - the cycle is iterative and it doesn't happen overnight.

I never said "stop asking" - I simply asked that you consider all that is involved and to show at least a modicum of patience while we try to comply.

OpenDeply 5 *was* a *big* change from OpenDeploy 4 - it was ambitious and the initial release showed signs of the trade-offs between functionality and compatibility. However I've found that most customers who have upgraded from 4.x to 5.5.1 generally appreciate the improvements that were gained - and there are more coming in 5.6 and I'm sure more coming after that. Could the transition have been smoother? Perhaps. But there are always trade-offs.

And because I hate to waste an analogy ...

You say there's no kitchen so how can there be too many cooks. I say there is a kitchen - everything that's been discussed in these forums, the GearUp session, and ideas that get exchanged internally between many people within Interwoven (engineering, consulting, marketing, support, education, etc.). You want to be one of the cooks, so do a lot of other people in these forums, so do a lot of people who were at GearUp, so do a lot of us within Interwoven -- *that's* what I meant by too many cooks.

Oh well, I have a bunch more forum posts to get through, and some email, and some "real work" too.... later,

--fish
(Interwoven Senior Technical Consultant)