Email from GEL and Application SMTP setting

[Martin Snizek]

Hello,

 

I completed setting of the SMTP server via NSA, but there is a strange behaviour of notifications.

 

When I use gel script to send the email the recipient receives the email, but notifications from application are not delivered. I checked the user email and also the user setting for notifications and everything seem to be ok.

 

Does the GEL uses the same credentials as application?

 

Here is my code:

<gel:email from="${sender}" to="${emailTo}" subject="test email">
        <![CDATA[Email Test from: ${senderEmailAddress}.]]>
</gel:email>

Can you please advice me how I can check if the email notification is sent from CA PPM? Is there any possibility to track it?

 

Thank you all,

Martin

[Nick Darlington]

Yes, it does use the same credentials in all places:

 

1) <gel:email> tags

2) Notifications sent by the app service (e.g. 'late timesheet' notifications)

3) Notifications et by the bg service (e.g. 'job fail/success' or system notifications in processes outside of gel)

 

About the only place that would not use the same setup and credentials for smtp would be the email tag library that is part of jelly commons.  That tag is not using any PPM code and so it has the expectation that you would provide it with the smtp hostname etc. as part of the attributes on the tag, but that isn't the one you are using above.

 

Things I would suspect at this point:

 

1) Changes made to the CSA that the app/bg services have not picked up.  Although some configuration changes can be picked up dynamically, some others are read once into memory and reused for the lifetime of the application.  A restart will be needed in those cases.

 

2) A disconnect between the contents of the properties.xml file on disk in the $NIKU_HOME/config folder, and the same database entry in the results of the query "select value from cmn_config where name = 'properties.xml'" - the contents should be identical in both places.  If they are not, you may need to re-save information in the CSA and/or "push" the configuration from the disk (assuming it is correct there) into the DB through the use of the command line action "admin general upload-config".

 

Edit/update:

As for tracking, you could try enabling DEBUG level logging in the CSA on the following named categories to see if that will yield any clues:

 

  com.niku.union.notification.NotificationDeliveryService

  com.niku.union.notification

  com.niku.union.notification.MailMessage

  com.niku.union.notification.Utils

 

I've listed them in the order that I think might be the most helpful (especially in the tradeoff between getting pertinent information logged vs. being flooded unhelpfully), but you can choose whether to enable them in turn or all together, depending on how chatty your systems are.

[Martin Snizek]

Hello Nick,

 

thank you very much for such an information.

 

I enabled first three categories on DEBUG level, but unfortunately I got in to the log file just: * logging is not allowed for this action * for all of them

 

Do I need to restart BG and APP?

 

I found following Clarity: DEBUG logging in Clarity 13.1 almost always results in message 'logging is not allowed for this action' but it should be resolved, we are on 15.1 Patch 3.

 

Thank you,

Martin

 

EDIT: As Appender I selected STDOUT.

[Martin Snizek]

I did a restart of all services and the behaviour is maybe stranger then before.

 

Notifications about Scheduled jobs are send and received by the recipient but for example for Late Timesheet the notification is not received.

 

Thank you,

Martin

[Nick Darlington]

Ahh, that's unfortunate about the logging.  The defect was fixed yes, but some logging activities are still supressed on purpose.  I didn't have a chance to check these ones personally before listing them, sorry.  The appender is fine.

 

The notifications that are sending are going via the bg service, the ones that appear to still be a problem (like late timesheet notification) are sent by the app service.

 

Did you get a chance to check the contents of the $NIKU_HOME/config/properties.xml vs. the results from the query?  Multiple records in cmn_config for the same name 'properties.xml' and/or the contents being different from the version stored on the disk are both contributing factors to why a service may get confused about which configuration data to use.

[Martin Snizek]

Hi Nick,

 

yes, I did check of the cmn_config. There are two rows - properties.xml and logger.xml.

 

The content for properties.xml is the same as in $NIKU_HOME/config/properties.xml.

 

I also tried the admin general upload-config command and restarting services but with no luck

 

* logging is not allowed for this action * message appears only in app-ca.log, in bg-ca.log I can see all the data and it seem to be OK, but for app there is only this message

 

Please have you got any other idea?

 

Regards,

Martin

[Jeevan.B]

In addition to Nick's comment above, if you are expecting notifications to go out via "Notifications" sections of processes, then there is a defect in 14.3 to 15.1, that does not allow this to happen. It has been fixed in 15.2..

[Martin Snizek]

Hi Jeevan,

 

I do expect any notification, for example that resource was added to the project or Late Timesheet reminder.

 

Thank you,

Martin

[Legacy User]

Hi msnizek,

 

Please check out the global notifications settings under Administration > Data Administration > Notifications > Notification Default Settings > Check Email option is checked for the ones you are looking to receive notifications > If they are already set there could be another possibility that the global notification settings might not have been published, hence publish it again so it works out for all users

 

I hope this would resolve your problem. In case it is please mark this as answer which would help others too

 

Regards\\Avik

[Martin Snizek]

Hi Avik,

 

thank you for your response, all these setting is ok. I was able to solve this with assistance of CA Support.

 

Regards,

Martin

[Martin Snizek]

Hi all,

 

thank you for your replies, I solved this issue with assistance of CA Support.

 

Solution:

add attribute alwaysUseDefaultSenderAddress="true" in properties.xml

<mailServer host="XXXX" username="***" password="***" fromAddress="" sendProtocol="***" fetchProtocol="***" defaultSenderAddress="[e-mail]" useAuthentication="***" alwaysUseDefaultSenderAddress="true"/>

 

Hope this can help someone else too.

 

Regards,

Martin