multiple recievers

Can I send emails to multiple users from workflow using solutions workflow iw_solutions_mail.ipl script, if yes how can I do that?

Find more posts tagged with

Comments

Migrateduser

If you are using the Template Based Email, I ran into the same issue. I had to build a custom script that would loop for all the recipients and calls iw_solution_email.ipl every time through the loop. I couldn't figure out how to get one call to iw_solution_email.ipl and have it send an email to multiple people. When you pass in the successor task, it figures out the owner of that task and emails them, but if you want additional people to receive an email, you're screwed it appears.

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

Migrateduser

The <to> element in the email header may contain multiple <addr> elements. Ditto for the <cc> field.

So you can have


   <to>
      <addr>bob@excellent.com</addr>
      <addr>ted@excellent.com</addr>
   </to>

Of course, you still need to determine who you want the message to be sent to.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

But how do you pass multiple recipients to the script itself? There are no input flags for iw_solutions_email.ipl for additional recipients or "cc" recipients. The way to invoke the Template Based Email is by executing iw_solutions_email.ipl, correct? So in order to make it useful for additional recipients, there has to be an easy way to pass them to that script, right? Am I missing something?

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

Migrateduser

The iw_solutions_email.ipl script does not have input flags for additional recipients, or for *any* recipients. The data is obtained from the workflow job and its tasks. Typically the recipient (To Smiley Happy

is the owner of some "subject" task. (The name of this task is specified in the command.) However, you may use any data you like, such as the value of a task or job variable, a value retrieved from a file, or a hard-coded address.

See Technical Document 49305, Template-Based Email Notification for details.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

I don't understand. The "-t" flag allows you to enter subsequent tasks that are essentially the successor tasks for the current externaltask. The iw_solutions_email.ipl script determines the "to" email addresses based on the owner(s) of these tasks listed and by using the email map. It is not clear at all how I would pass any other information to this script. I have looked at the technical document and I don't see it. Can you point to the page and section where it tells me how to pass more recipients into the script?

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

Migrateduser

See the section under the heading "Where does the data come from?".

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

This doesn't tell me how to add recipients that are not owners of any tasks in the workflow. This only tells me that I can use the "-t" flag to specify tasks that may contain interesting information. Maybe I didn't make the scenario clear enough. I would like to be able to pass just email addresses into iw_solutions_email.ipl so that whatever email is generated gets sent to the owners of any "-t" tasks and also the addresses specified. Can you provide an example of how to do that with a simple call to iw_solutions_email?

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

Migrateduser

The addresses to which an email message is sent are determined by the header template. That template has access to the owners of all of the -t tasks, so you can just iterate over the tasks to produce the list of addressees.

I'm not sure what you meant by "and also the addresses specified."

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

I mean that I have emails I want to send to people that don't own any tasks - they just want to be informed of certain events, like when changes go to QA or when changes go live. You have no mechanism to send emails to anyone who doesn't own a task. That's a limitation that forces me to write my own shell around iw_solutions_email.ipl. If you added more parameters (or flags) to the script, it could be more robust.

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

Migrateduser

Let me say this again: The addresses to which an email message is sent are determined by the header template. There is nothing in iw_solutions_email.ipl that restricts recipients to the owners of tasks. This is simply the behavior of the default header templates.

If you could add addresses as parameters on the command line, you would most likely do so within a WFT (or some analogous construct). You can instead add these addresses as one or more variables on you job or task, and have your header template retrieve the addresses from those variables.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

OK, I guess I can live with that. But it definitely is not documented very well. I suggest that when you add a section to the WF Developer's Guide for Template Based Emails (you are going to add it to the WF Developer's Guide, correct?) that you don't simply cut and paste the tech note into the product document. There needs to be much more detail added so that it's very clear how to customize your emails using this feature. I would also recommend that any details specific to tpl files be noted in detail in the documentation (such as how to refer to elements in the XML and any special constructs - like iw_iterate) or a specific reference to a section in the Templating document be there so people can find clear documentation on how to accomplish anything they need to do with these email templates.

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

Migrateduser

Looking at the iw_solution_email.ipl script some more, is it not true that regardless of how many recipients I might allow for in my header, the same email body will be sent out to all the recipients? There is currently no way, unless I modify iw_solution_email.ipl, to send different email bodies to different recipients. So if there are links that will open up webdesk embedded in the email that I don't want one of my recipients to see, I would have to use some sort of wrapper to accomodate that feature. I certainly don't want to modify iw_solution_email.ipl because upgrades will overwrite my customizations.

For example, if I have multiple "-t" options included in my call to iw_solution_email.ipl, all that does is add the details for those tasks into the XML. If I have 2 successor tasks and want to send emails to the owners of those tasks, I have to set that up myself in the header tpl. But I want recipient A to have the link to A's task in webdesk in his email but not see any link to recipient B's task. And recipient B's email should have the link to B's task in webdesk in his email, but not see recipient A's link. How do I accomplish that using iw_solution_email.ipl? And what if I also have recipient C who doesn't own any tasks but just wants to be informed of what is happening with the job - I don't want them to have any links in their email. Since they all get the same email body, it doesn't seem possible without writing a wrapper that send separate emails.

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

Kay

I was able to send emails to multiple receivers by putting some script in the header file, which recieves the list of users to send email to and do a look up for those users in the email_map.cfg to get the emails from.

My questions:
1. But my question how do i create a link for the user A to his tasks in the body of the email.
2. How to avoid multiple users from receiving the same body of the email so that as david mentioned to restrict users other A seeing the tasks assigned for A.

Adam Stoller

In general, if you want two (or more) distinct pieces of email to be sent (different recipients, different body, potentially different subject, etc.) - you should consider them as two (or more) distinct notification tasks (which can probably be run concurrently).

Trying to get this all codified within a single run of a notification script is definitely going to result in a highly customized script - it's almost definitely possible, it's just a question if it's the most effective/efficient use of your time to try and make it work rather than adding another notification task that might use different presentation templates and/or inputs.

I haven't spent any significant time with with the solutions email script to be able to provide first-hand experience doing this, but I've certainly done things like this (multiple email's) with iwsend_mail.ipl by manipulating the task-level variables for each of the notification tasks.

I'd suggest trying to clearly document / define what it is you are attempting to do - step back from it a little bit and think about what really makes the most sense in terms of an implementation - and then move forward with the design and coding.

If you truly feel you *must* be able to do this within a single externaltask notification script, so be it - but you'll have to play around a lot more with examining the data and modifying the pieces to selectively pull out bits and pieces for each of the notification directives.

I'd opt for the keep-it-simple approach and use two distinct tasks / scripts.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

While what you say is true and in most cases I would agree with you, my reasons for expecting more from the Template Based Email script is because it appears to advertise that it can accomodate more than one task at a time. I wrote a relatively simple wrapper around the main script that will do exactly what I want - if more than one task is passed in, send separate emails to the owners of those tasks with embedded links specific to each task owner's task. Also allows for people who don't own any tasks but want to be informed of certain activity and sends them an email with no links to task activities. I would think this would be a simple extension to the existing script and would make the tool much more robust. I understand that you can't make every tool work the way everyone wants it to, but this particular tool is not as useful as it could be if it allows for multiple tasks as inputs but only emails out one email with links not all task owners need to see. I think it could be smarter is all.

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