You need to sign in to do that
Don't have an account?
Nikhil
InboundEmail.TextAttachment returns null while trying to send txt attachment file of size 40 kb
Hi Forum members,
I am trying to send a email via InBoundEmail Service .My Text file contains more then 350 Records,File size is 40 KB.
If i send a file with 310 records.My class accepts the file and able to further process as per buisness logc,So in this case when i m sending 310 records then
code part " if (email.textAttachments == null) " returns false,
but in case of 350 records
code part " if (email.textAttachments == null) " returns true
So my emailservice is not able to process more then 350 Records,Though i have handeled the logic to process more then 2000 records inside the class but before this i need email.textAttachments as not null.
If anyone knows the resolution please reply ASAP
Following is the Code part
global class EmailExample implements Messaging.InboundEmailHandler
{
Double GuestRate ;
Double CostRate ;
public static void test()
{
}
global Messaging.InboundEmailResult handleInboundEmail(Messaging.inboundEmail email,Messaging.InboundEnvelope env)
{
Messaging.InboundEmailResult result = new Messaging.InboundEmailResult();
try
{
List<Messaging.InboundEmail.TextAttachment> Obj = new List<Messaging.InboundEmail.TextAttachment>();
if (email.textAttachments == null)
{
//Some code
}
else
{
//Some code
}
}
catch(........
Thanks
Nikhil
I am trying to send a email via InBoundEmail Service .My Text file contains more then 350 Records,File size is 40 KB.
If i send a file with 310 records.My class accepts the file and able to further process as per buisness logc,So in this case when i m sending 310 records then
code part " if (email.textAttachments == null) " returns false,
but in case of 350 records
code part " if (email.textAttachments == null) " returns true
So my emailservice is not able to process more then 350 Records,Though i have handeled the logic to process more then 2000 records inside the class but before this i need email.textAttachments as not null.
If anyone knows the resolution please reply ASAP
Following is the Code part
global class EmailExample implements Messaging.InboundEmailHandler
{
Double GuestRate ;
Double CostRate ;
public static void test()
{
}
global Messaging.InboundEmailResult handleInboundEmail(Messaging.inboundEmail email,Messaging.InboundEnvelope env)
{
Messaging.InboundEmailResult result = new Messaging.InboundEmailResult();
try
{
List<Messaging.InboundEmail.TextAttachment> Obj = new List<Messaging.InboundEmail.TextAttachment>();
if (email.textAttachments == null)
{
//Some code
}
else
{
//Some code
}
}
catch(........
Thanks
Nikhil
The max message size we allow is around 10mb, but the protocol adds aroudn 30% to the size of an email message, so in reality you might only be able to send in message around 6-7mb including all attachments.
I am sure that i am not crossing the limit of calls provided by SF.Still if we assume that i am, in that case also service will give error while manupulating the records which is done after recieving the email.
But the point here is that i am not able to receive the file cause email.textAttachments is coming as null where the charachter count is more then 31500 approx
till 31500 email.textAttachments is not returning null at all.
This is what the exact problem is.
Please comment
The reason for the issue is Apex currently only supports strings up to 32,000 characters, text attachments are treated as strings and thus are limited by the 32K limit.
However, a patch release will be going out in the next few weeks which will increase this limit to 100K.
Also, there are a number of bugs which have been identified because of this issue.
1. The above limit was not documented in the help section for email services
2. Attachments over this limit were dropped, this behaviour will be changed and a bounceback email will be sent to the sender to indicate that the attachment is too large.
3. The code on our servers which calculates the size of the attachment also contained some bugs which meant that sometimes attachments were treated as being larger then they actually were.
All 3 of the above bugs will be fixed in upcoming patch releases.