Expand my Community achievements bar.

SOLVED

Workflow Email Notification pointing to wrong url

Avatar

Level 3

We recently migrated to AEM 6.4 and noticed all OOB workflow Email notification body content which also has URL mentioned pointing to local-host URL on all environments (dev,stage, prod)

This was working on prior AEM version we were on (6.1) and We do have OSGI Link Externalizer Config properly setup for all run modes on 6.4

1580148_pastedImage_2.png

Apart from externalizer, We do have   Day CQ Workflow Email Notification Service (com.day.cq.workflow.impl.email.EMailNotificationService) configured with correct values for Dev/stage/prod but its also not helping.

Can anyone tell if its a product bug or required additional configuration ?

1 Accepted Solution

Avatar

Correct answer by
Level 10

Our support team replied:

Ok, so when I tested with Externalizer then the setting is ignored. Whenever I use Host URL Prefix from Host URL Prefix

It changes the prefix.

Might a good idea to log a support case

View solution in original post

25 Replies

Avatar

Level 10

Have you followed all instructions in this AEM 6.4 doc?

Configuring Email Notification

Avatar

Level 3

Yes and everything else like "from address" , custom email notification where we are getting host url from externalizer and adding to email body is working fine.  Its only problem with OOB workflow notification (so far we know in 6.4)

I see in OOB email template , host.prefix is used and its not honoring externalizer run modes value we have set it up

1580183_pastedImage_0.png

Avatar

Level 10

Do you happen to have a fresh AEM DEV instance to try. I suspect this could be an upgrade bug. Can you test on Fresh instance to rule out that nothing is mis-configured.

Avatar

Level 3

Another thing i just tried was adding explicit value for host.prefix property (value =author url of dev instance) in Link Externalizer OSGI config and I can see now localhost is replaced with DEV author URL in email notification but It is adding extra http to Dev https url

the URL now i get in email is like this  http://https//aem-author-dev.xxxxxxxx/xxxxx

The reason why i did not have this value set up was because it says it is Deprecated Property.

Does not looks like upgrade issue.

Edit 1: its externalizer.host property value not host.prefix that I updated under Link Externalizer OSGI config

smacdonald2008

Edit 2: If i remove web protocol and just add server address in externalizer.host , it worked but it has http instead of https in email notification content body. So instead of having https://author.xyz.com in externalizer.host property value , If I just add author.xyz.com, its working

My question are

1. why do we need to populate externalizer.host in Link Externalizer which is deprecated

2. why its adding http instead of https which is not acceptable for us on upper environments

Avatar

Level 10

Also - here is the 6.4 docs for Externalizing URLs - https://helpx.adobe.com/experience-manager/6-4/sites/developing/using/externalizer.html

I am checking internally to see if this is a known issue,

Avatar

Level 3

Thanks for checking internally. Meantime I will again go through this docs to confirm we are doing everything needed for 6.4

Avatar

Level 10

Also - i want to make sure there is not missing information to the AEM 6.4 docs.

Externalizing URLs

Avatar

Level 10

A team member replied:

I have used the Externalizer before. I'm a little confused by the question but they should use the externalizer.domains part of the config. As the user mentions the other configs are deprecated

Carp.png

In the code use the authorLink method

 // link to author
 externalizer.authorLink(resolver, "/my/page") + ".html";
 // => "http://author.website.com/contextpath/my/page.html"
https://helpx.adobe.com/experience-manager/6-4/sites/developing/using/reference-materials/javadoc/co...

I have not had an issue with an extra https being appended...

Avatar

Level 3

Yes we are using same approach using externalizer.domains to different mode , you can see that screenshot in thread main question.

I dont have any issue using it with our custom notification where I am following exactly same as you mention and it work without any issue.

The issue is only with OOB Workflow Email Notifications which are non customized and I have no idea why they are not having correct URL without populated deprecated externalizer.host property value which if populated like i said above is casing extra http or https issue.

Avatar

Level 10

I am testing this and will make use of this API within a workflow step. This use case and question raised my attention that we do not have a good Quick Start HELPX article that shows use of this API.

Avatar

Correct answer by
Level 10

Our support team replied:

Ok, so when I tested with Externalizer then the setting is ignored. Whenever I use Host URL Prefix from Host URL Prefix

It changes the prefix.

Might a good idea to log a support case

Avatar

Level 3

thanks smacdonald2008 for confirming. I will open one for this issue.

Avatar

Level 10

We are still putting a HELXP together to show use of this API. We will show it within a Workflow.

Avatar

Level 10

Got it working too in Java --

public void execute(WorkItem item, WorkflowSession wfsession,MetaDataMap args) throws WorkflowException {

    

    try

    {

        log.info("Here in execute method");    //ensure that the execute method is invoked   

              

        ResourceResolver resourceResolver = resolverFactory.getAdministrativeResourceResolver(null);

       

       

        //Get the FULL URL OF THE PAYLOAD in the workflow

        //Get the Assets from the file system for a test

        WorkflowNode myNode = item.getNode();

         

        String myTitle = myNode.getTitle(); //returns the title of the workflow step

         

        log.info("**** The title is "+myTitle); 

         

        WorkflowData workflowData = item.getWorkflowData(); //gain access to the payload data

        String path = workflowData.getPayload().toString();//Get the path of the asset

       

        //GET FULL PATH

        String myExternalizedUrl = externalizer.publishLink(resourceResolver, path) + ".html";

       

        log.info("The FULL PATH FO THE PAY LOAD IS "+ myExternalizedUrl); 

       

       

       

    }

      

        catch (Exception e)

        {

        e.printStackTrace()  ;

        }

     }

Avatar

Level 3

I agree, it work for me in Java or If I generate URL value using externalizer API in Java class and use it in email template as variable.

But, it does not work for OOB workflow email template at location /libs/settings/workflow/notification/email/default/en.txt

where its using $ {host.Prefix} for URL.

For me its product issue since its only with OOB emails.

Do you know or can you check how $ {host.Prefix} variable value is calculated and passed to this template then we can figure out which configuration is actually responsible for host.Prefix wrong value

1580294_pastedImage_0.png

F

Avatar

Level 10

Here is a HELXP that shows using this API in a Java class --

Adobe Experience Manager Help | Creating an Adobe Experience Manager 6.4 custom workflow step that u...

There is a video too in this HELPX that shows this API working.

Avatar

Level 3

ok i saw this before but it does not answer my question why OOB email template host.prefix variable does not have correct value.

Can you check with your team on this since its Adobe OOB email and back end class who call this template to trigger email.

this will help me understand how $ {host.Prefix} variable value is calculated and passed to this template then we can figure out which configuration is actually responsible for host.Prefix wrong value

Avatar

Level 10

There is a bug ( when trying to use it within an email template) as customer support stated.

This article is for ppl whom want to know how to build a solution with this API and see it running.

When we were investigating this - i saw we had no HELPX Quick Start for this API - that is and end to end to quickly get it working.

Avatar

Level 3

I dont understand why this thread was marked Answered though its pending further investigation by support or original issue for which this question was created does not resolved yet.