Often there is a need to send emails out to users which have multiple languages. Unfortunately, IdentityIQ's default email templates do not support language currently. However, there are still a number of options at your disposal to solve this problem:
Option 1: All languages in single email
You can put all languages in one email template, and have an HTML section which allows you to "jump" to the correct language setting.
Option 2: Leverage velocity to render correct language
If your email template has the context of the identity who is being sent the notification, you could use an Identity attribute to render the correct language.
For example, if you had an identity attribute called "preferredLanguage", you could use this to key the correct language.
#set ( $language = $certifier.preferredLanguage )
#if ( $language == "de" )
Hallo! Mein Name ist $certifier.displayName
#elseif ( $language == "fr" )
Bonjour! Mon nom est $certifier.displayName
#elseif( $language == "es" )
¡Hola! Mi nombre es $certifier.displayName
#else
Hello! My name is $certifier.displayName
#end
if "preferredLanguage" was set to "de" then we could expect a certifier's email to look something like this:
Hallo! Mein Name ist Robert Brown
Option 3: Send email based on language
If you have API control, you have control over selecting and sending the correct email template yourself. For example:
In IdentityIQ 6.1, we added the option called emailNotifierClass to the SystemConfiguration. You can write your own emailNotifierClass which can re-translate the templates. As an example:
I do not believe the fourth option, 'Use Custom Email Notifier', is a feasible solution. I attempted to implement this solution and noticed the following difficulties:
The EmailOptions variable supplied to the 'sendEmailNotification' method is always empty. This prevents us from retrieving the necessary variables required when recompiling the email in a new language. To be honest, I am not too sure why this variable is provided as a parameter.
The EmailTemplate variable supplied to the 'sendEmailNotification' method is post compilation. This leads me to believe the EmailNotifier is not the appropriate point in the sequence to inject logic for supporting multilingual emails, as it is too late in the sequence and IdentityIQ will be performing redundant work.
Perhaps the better approach would be to extend the 'compile' method for the EmailTemplate class?
blaise.bostelmann - Yes, the fourth option is post-compile. However, I disagree with you, it is still an option. We have had customers add their custom email notifier and then do a lookup on the person, gather their preferred language, and then change place-holders (think string tokens) of the email template to suit the language. The values coming into the email template won't change, but the rest sure can. We've had others that
For instance, if your email template is something like this:
Your EmailNotifier could look up who this is being sent to (e.g. John Doe), and then look up their language:
In the case of German:
Subject: Erinnerung: ein Zugriffsüberprüfung braucht deine Aufmerksamkeit
Body:
Hallo John Doe,
Die folgende Zugriffsüberprüfung ist noch offen und muss abgeschlossen werden: Manager Certification Q4 2017
Dies muss beendet werden durch 12/31/2017
Vielen Dank im Voraus,
ACME Administration
In the case of Spanish:
Subject: Recordatorio: una revisión de acceso necesita tu atención
Body:
Hola John Doe,
La siguiente revisión de acceso sigue abierta y debe completarse: Manager Certification Q4 2017
Esto debe ser completado por 12/31/2017
Muchas gracias,
ACME Administration
Hopefully you get the drift.
Regarding your other comments. EmailOptions are not always null, these can be set via API, BeanShell, Workflow, etc. We also don't advocate extending or overriding SailPoint code by changing the EmailTemplate.compile() method. This is definitely not supported, so do not go this route.
Thank you for your response, although I am not quite certain I understood. Are you proposing we conduct a search on the EmailTemplate for the values injected into the tokens to build out the initial list of arguments?
The issue I am experiencing is with the EmailOption parameter, as I am finding the it is always empty. I have triggered emails from Certification, Workflows, and Rules, yet when I log the '.getVariables()' method of the provided EmailOption parameter a null is always returned. As you can see, not having access to the original variables supplied to the EmailTemplate can complicate this solution quite a bit. If this solution has work for others in the past then perhaps it is dependent on the version of IdentityIQ; I am developing this using a vanilla instance of IdentityIQ 7.1p0.
In addition, how do we actually send the email. It seems to me the purpose of this method is to execute the logic to send the message, am I correct?
Think of this as a two pass template. The first pass uses standard IdentityIQ product functionality to populate variables, as it always does. In the second pass, the words in the rendered email template like "GREETING" are then replaced by the the localized message like "Hola" or "Hallo", etc. The first pass is all standard IdentityIQ; the second pass is part of the custom email notifier.
I think you are expecting EmailOptions to do something other than they were intended. EmailOptions are intended to control how emails are sent, and are really used pre-compilation - which is how emails are typically sent. The methods you are calling are actually used when the emails are sent, and might be empty post-compilation.
For sending emails, this is done via the context. Heres an example:
Ah, I now understand your approach to building out the translated EmailTemplate object. You are proposing to replace the static text before and after each piece of dynamic text in the compiled email, instead of compiling a new email in the translated language and replacing the tokens with the dynamic text; the second method is what I was trying to attempt.
I believe we have a similar understanding for the EmailOptions class. I had always considered it to be the class which stores the arguments to be applied to the EmailTemplate. What I don't understand is why the object is being cleared before it is passed into the 'sendEmailNotification' method.
I am a bit confused with your proposed method for sending emails. The below method you are invoking to send the email is the same method we are implementing, so wouldn't this cause the thread to go in an infinite loop? Are you using a different implementation of the EmailNotifier class?
I have a requirement where I need to schedule an email to be triggered after a few days. Can I do that in IIQ? Is there any OOTB method to schedule emails in future date?
