New workflows 5.5.2

Hi
Is any working on new workflow 5.5.2. I am unable to understand new configurable workflow file. I thinks its entirly different from previous vertion. I am unable to get successor set and activation like stuff in new configurable workflow template. I want to sent a Email to a approver. He has to approve or reject the in mail . He need not to log onto Teamsite . If any body has solution , please tell me.

Vinay

Find more posts tagged with

Comments

Migrateduser

There is a new Template Based Email feature that is fairly easy to implement and customize - even moreso if you already know Templating Smiley Happy

- that will embed the links to allow the recipient of the email to perform approval without explicitly logging into TeamSite. However, if the user hasn't logged into TeamSite for a while (I'm not sure how long is the default) he/she will have to log in after they click the link. What they will see is a WebDesk look and feel for a pop-up that allows the user to select the approval/rejection options available for that task. I've been able to get Template Based Email working, with the help of some of the Interwoven guys here on DevNet. It's really nice. And you can use it with your old workflows - you don't have to use the new configurable (solution?) workflow in 5.5.2.

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

Migrateduser

The configurable workflows in 5.5.2 are new... but not entirely. They don't contain anything you could not have put in a WFT in a previous release. You should read the new chapter ("Solution Workflows") in the Workflow Developer Guide.

To transition a task from an email using the CCI (casual contributor interface) you must log onto TeamSite. This is not a change in 5.5.2, it has always been this way. (Note: If you have already logged into WebDesk, it won't ask you to login again.) You can find ways around this restriction, but you would be opening a security hole in your system. How would you know that the approver is the person to whom the email was sent, or that the approver even received an email?

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

As long as you brought it up, I would like to have the option of sending an approval email to a non-TeamSite user. We have our production server hosted by a 3rd party, and it would be *so nice* to be able to send those folks an email as part of a custom workflow, and they could simply click a link in the email body to provide automated feedback to the workflow. For instance, we might want to tell the folks at the hosting company to turn off one of their scripts before we deploy some content. Right now, we need to call them and tell them to do it. If it was part of the workflow, it could be automated and some of our users who have to get up at 2:00 am to make that call would be very happy with us. I understand your points about not being able to authenticate who is performing the action, but I am willing to assume that risk if it means I can get the kind of automation I desire in my process. If you can provide a mechanism that allows non-TeamSite users to invoke Casual Contributor links, that would be really nice. Maybe you can provide a switch when I'm creating the email that either forces authentication if I need that or doesn't if I don't. Of course, it's easy for me to ask for all these things, but you imply in your response that it can be done.

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

Adam Stoller

I can think of ways to do this - but they're non-trivial.

If the 3rd party person can connect to a CGI on your TeamSite server (not necessarilly within the TeamSite filesystem) you could create a custom CGI hyperlink that allows them to send information that gets logged in a "well-named" file on the TeamSite server machine. Then you have a process that periodically checks for such files and acts as a proxy for the 3rd party individual (owned by a TeamSite user - perhaps root or some other account) that would then make the approrpriate calls (directly via CLT, via the Perl modules, or perhaps even via OpenAPI or Content Services SDK?) to update information in the existing workflow and transition it.

(more design work needed to hash out details - this is off the top-of-my-head).

Alternatively, since you presumably have at least one public-facing web site - you could have the email link go to a CGI on that machine and "relay" the information from there to your TeamSite server and then continue along the route as described above.

There are probably other ways you could do this - but in terms of a customized solution which is unlikely to violate support contracts and/or get lost during a TeamSite upgrade, this is probably the direction I would investigate....

--fish
(Interwoven, Curriculum Development)

Migrateduser

Interesting food for thought. I will definitely consider these options. Thanks for the ideas.

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

james1

There is a simpler way that is probably equally dangerous.

If you put a CGI in IWHOME/httpd/iw-bin, and if anyone -- anyone!!! -- goes to your CGI's URL (http://your_teamsite_server/iw-bin/your_cgi_program.cgi), then your CGI will execute ... as the user "iwui", who is a TeamSite master. i.e., your CGI script can perform task callbacks and stuff.

Of course, your CGI script can also delete branches...!

And, as with Adam's suggestion, if you don't know (for absolutely positively sure) who is connecting to your CGI, well, then you're opening up a vulnerability that didn't exist before.

So be careful!!!

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

Both of these CGI-based approaches require that the 3rd party has web access to your TeamSite server. Often our customers very concerned about securing their servers, and therefore place them behind a corporate firewall.

A safer way to involve "outsiders" in your process would be to use an email response. You could either have the recipient "Reply" to the message (if there is only one transition that you want to automate), or give them a form with a mailto: action. Then there is the non-trivial matter of routing the email within your company to a server with an agent that can interpret the response and trigger a TeamSite transition.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

Yes, after discussing those options with my coworker, I quickly realized that none of them would work due to the security constraints on our TeamSite server. So how do you configure an email to be interpreted in such a way that it can trigger a TeamSite transition?

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

Migrateduser

There are too many possibilities. Most mail servers will have options to implement agents and route particular email addresses to them. This is how some newsgroups and mailing list administrators are implemented.

Or you could also set up a special user account for just this purpose, and have a cron job to read the incoming mail.

Or you could setup a mail filter for an existing user account, and intercept messages thaf fit particular criteria.

There are big variations in how various mail servers and clients operate. We do not have a packaged solution, so I think you are left to your own creativity (for now).

Brinko Kobrin
Interwoven Staff Engineer

Adam Stoller

It's bee a long time since I processed email on Unix - but as I recall, you might want to take a look [for] at a program called "procmail" - which can do a fair amount.

--fish
(Interwoven, Curriculum Development)

Migrateduser

I was inspired to rethink this after hearing someone at the Focus Groups talk about using Outlook voting buttons to allow outside forces to approve/reject content via email and without interfacing in any way with TeamSite. I think this would be an awesome idea, especially since Outlook is our standard email application. Unfortunately, that person did not know how to implement this solution either - it's just something they'd like to do. Our email server is Windows based, and our TeamSite is on a very secure Solaris box. How those two can interact is the mystery. I am completely ignorant about email and how it works, so I will have to do some digging to see if it's possible at all to have an email somehow trigger a TeamSite event. I suspect it will not be possible, but I really, really like the idea of using the voting buttons. It would be nice if Interwoven could provide a mechanism to hook into this.

If, perhaps, a workflow created some kind of sesion ID that was only active while the workflow was active, and could only be accessed via WFworkflow.pm or something similar, and this session ID could be passed in the URL for the casual contributor link in an email, couldn't that invoke an event within the TeamSite workflow engine to perform a callback on a task? For instance:

http://servername/iw/webdesk/task?taskid=tid&workflow=wfid&session=sessionid&successor=0

or something like that to actually invoke a successor without having anything pop up. If that was made possible, all I'd have to do then is figure out how to make the voting buttons make a call to that URL. This would help provide some security, since the only way to get the session ID would be through the workflow. In a perfect world....

As a caveat to this, I realized that I can simply send the email to a account on the TeamSite server, so then perhaps Adam's suggestion in a previous post about a mechanism in Unix to help with this solution will be very useful.

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

Edited by Smitty77 on 10/31/02 09:30 AM (server time).

Adam Stoller

The tricky part is always authentication. The mechanics of everything else is pretty straight-forward and even, dare I say it, trivial - but authentication is one of those thing that most companies, and applications like this, care about and dealing with it across a distributed network without requiring users to re-authenticate at the point of contact ... well, it's not so trivial.

Using the email to collective box and processing it on the back end would probably work fine - because at that point you're largely giving up on authentication and circumventing it. The script that processes the email would have to run as probably a Master user - and should perhaps try to validate the From: address of the email against the owner of the task represented by the taskid - but that's not real authentication/validation.

If you're only dealing with internal users - this is probably sufficient. If you're dealing with external users you generally need to be at least a tad bit more paranoid - and code for it.

--fish
(Interwoven Information Guy)