function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
NikhilNikhil 

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


Rasmus MenckeRasmus Mencke
The amount of records in the attachment should not affect your code. What I would suspect without seeing your code is that you might be hitting the governer limits. Have you bulkified you code?

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.
NikhilNikhil
Thanks for your immidiate reply,

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

Scooter429Scooter429
>>The amount of records in the attachment should not affect your code. What I would suspect without seeing your code is that you might be hitting the governer limits. Have you bulkified you code?
 
Can you clarify what you mean about "bulkified" your code?  I suspect that there is some type of magical threshold that is being crossed at 32767.
NikhilNikhil
Hey Guys i got this reply from Salesforce....have a look 


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.