No Attachments upon Receipt of Email

No Attachments upon Receipt of Email

  
Hi guys,

I have a problem with sending email with attachments. The scenario goes like this:

I am sending an email through the application, which contains information about his account in a PDF format. Now, the problem goes like, the email sends successfully and receives on the other end, but it does not have any attachments at all.

I have used the Attach File widget on the Preparation of the email, by looping on the Session.Attachments record list.

I've tried to check it with the system administrator responsible for emails, but he said that there are no filters applied with the files going in and out.

Any ideas?

Regards,

Julius
Hi Jun-kun,

Email screens are rendered by the Platform and therefore not on the same session as your web request. You should not rely on session context to build your email. You should get these attachment from database.

Cheers
I see...

Could I be able to use a record list variable to insert it to the email preparation. It seems tedious to add a temporary table to deal with just an attachment added from UI to Email?

Any workarounds?

Thanks.
André Vieira wrote:
Hi Jun-kun,

Email screens are rendered by the Platform and therefore not on the same session as your web request. You should not rely on session context to build your email. You should get these attachment from database.

Cheers
 As a side note, in a multi-tenant environment, if you do not pass in the Tenant ID and do a TenantSwitch in the email's preparation, you will not be able to access multi-tenant data as expected either, you will be in the contect of the eSpace's default tenant.

J.Ja
 
Jun-kun wrote:
I see...

Could I be able to use a record list variable to insert it to the email preparation. It seems tedious to add a temporary table to deal with just an attachment added from UI to Email?

Any workarounds?

Thanks.
 I think you could do that, though passing around big pieces of binary data through parameters is not always a good idea.

J.Ja
 
Justin,

What would you recommend with the current situation?

The use case is that the user needs to be able to attach documents to an email in the application and upon receiving the email, it must contain attachments. Since the target email can receive the email and attachments are missing, what could be other causes?


Jun-kun -

I would write the files to a temporary Entity and pass the ID to the email, and in the email's preparation, retreive the file and attach it. At the end of the preparation, remove the file from the temporary entity.

This will keep the email system from having to carry around this binary data, and also allow you to audit and debug the application more easily in case the attachments do not work as expected.

J.Ja
So that means an entity will be dedicated for these email attachments but only in the end of the preparation, that set of attachments must be deleted at once.

Well, I'll give this a try Justin.

But a short curious and noob question. Why is it that I must not rely to the Session.Attachments variable as said by André Vieira? I did not get your points on multi-tenacy or even "rendered by the Platform and therefore not on the same session as your web request." as said by Andre?

Thanks for the reply to both of you :)

Jun-kun -

Yes, that is my recommendation.

The reason why Session variables do not work has to do with the way the email system operates. If you look "under the hood", the email is not sent synchronously when you request it to be sent. Instead, a message is dropped in a queue to call a screen which composes the HTML for the email, take the HTML and turn it into an email. You can see exactly what I mean by constructing some bad logic in the Preparation of an email and examing the error messages. If you look at those messages and look at the stack trace, you will see that the email is NOT being called from within the code that said "please send email" but it is a separate page request completely. Because this is a request being made by the server and to the server, it is a separate session from the end user of the application. This is also why, in a multi-tenant application, it is running in the default tenant for the eSpace and not the tenant that the user belongs to.

This behavior can be a bit confusing at first, but it is very sensible. It prevents problems with the email from interfering with the rest of the application. So long as the "send email" request itself has no errors, exceptions within the email will not do a transaction roll back for your action, for example.

J.Ja