10 Replies Latest reply on Apr 3, 2009 11:18 AM by Brad Davis

    jBPM 4 Email Question

    Brad Davis Novice

      Who is implementing the email functionality for jBPM 4? Has it been started?


        • 1. Re: jBPM 4 Email Question
          Tom Baeyens Master

          maybe alejandro is going to look at it next iteration.

          the only update we plan is to replace our own templating with templating based on jsr223 scripting.

          would it be something you're interested in contributing that migration ? that would be really helpfull to the project.

          • 2. Re: jBPM 4 Email Question
            Brad Davis Novice

            From my experience in the field, here are two features we should actively pursue.

            1) Multiple email servers. Reason: a lot of companies have multiple SMTP servers. The reason is, generally one sends internally and one externally. I think we could accomplish this by having a configuration for the email servers in the mail configuration. This would be a list of servers, which could take simple domain filtering. For example servers could include "*jboss.org" and that would indicate the mail server can serve all jboss.org emails. We could also support pop or smtp mail pretty easily.

            2) Email Attachments are often an interest for clients. An example would be sending an order in PDF format when the task to sign off on the order is produced.

            We could create an email producer interface that we could use to make email producers plugable. It could take the environment context as a parameter, and return an email object [see apache email commons]. That would make the interface flexible enough to return either a simple text email, HTML email, or Multipart email with attachments.

            The email producer that we could ship could target using jsr223 or velocity or freemarker. I have noticed all of those have been tossed around as possible templating.

            • 3. Re: jBPM 4 Email Question
              Brad Davis Novice

              Here are my initial thoughts on properties for configuration.

              To address point 1 of the 2 points in my previous post, we could have the mail servers have include-domains and exclude-domains depending on which domains they should handle. This way, multiple servers could be configured in, and the email service could determine the appropriate email handler.

               <jbpm-mail-producer name="simple" class="org.jbpm.pvm.internal.email.SimpleMailProducer"/>
               <jbpm-mail-server name="internal">

              • 4. Re: jBPM 4 Email Question
                Alejandro Guizar Master

                To choose a server, would the domain be the only relevant selection criterion? In the pluggability spirit, we could have a MailServerFilter interface that took an Email and returned whether it can send the email or not. Then we provide a MailServerFilter implementation that filters based on domains.

                For email attachments, what data sources are we interested in? One obvious source is process variables. URLs, database LOBs come to mind as well.

                • 5. Re: jBPM 4 Email Question
                  Alejandro Guizar Master

                  Another topic is identity integration for resolving email addresses for actors. Tom, how far did you go towards incorporating the JBoss identity solution?

                  • 6. Re: jBPM 4 Email Question
                    Brad Davis Novice

                    I could see creating a server filter interface.

                    As for attachments, I think we should allow them to extend our Email Producers to add attachments of their choice.

                    • 7. Re: jBPM 4 Email Question
                      Tom Baeyens Master

                      configuring multiple mail servers seems a good idea to me.

                      but i don't yet see the need for determining the server used dynamically.

                      isn't it sufficient if we configure a set of mail servers like this ?

                       <mail-server name="default">

                      and in the process language allow for an optional attribute mail-server that defaults to 'default'

                      • 8. Re: jBPM 4 Email Question
                        Brad Davis Novice

                        The reason I was interested in doing filters is you may have the following scenario.

                        1) The mail node is entered and the pooled actors is assigned to a "factory" group.

                        2) The email address resolver resolves the group to 5 people, 3 of which are from jboss.org domain, and 2 of which are from the amentra.com domain.

                        3) The SMTP server responsible for servicing jboss.org domain emails is server (1) while all other domains need to go through the external email server (2).

                        So, if we have a filter setup, we could let the email service select the appropriate email server to service the list provided.

                        • 9. Re: jBPM 4 Email Question
                          Brad Davis Novice

                          So, keeping with that example, and with Alejandro's plugable, that scenario would look something like:

                          <jbpm-mail-server name="internal">
                           <filter class="org.jbpm.pvm.internal.email.filter.WildCardFilter">

                          • 10. Re: jBPM 4 Email Question
                            Brad Davis Novice

                            Thinking about how a lot of newletter type email systems send emails, do you think we would ever want a mail node to actually produce X number of distinct emails, one per user to customize emails per user?

                            For example, in addition to customizing the email based on the environment object, customize it on the recipient list? For customer based emails, this may be important.

                            Brad, You have the following task available.

                            If this is the case, our email producer should return a collection of emails rather than one single email.