3

I stumbled upon an interesting limitation, it seems that SOAP API endpoint handles requests larger than 16Kb differently --- whenever body is larger than that request just times out.

We're using 'create' SOAP request to create sObjects. The main reason we're using SOAP is its ability to batch up-to 200 sObjects into one call while still being synchronous (comparing to Bulk API).

When I tried to increase HTTP read/open timeout, then after waiting for 10 minutes or so (a '<= 16KB request' takes just a second), I've received once a response about invalid XML: "Content is not allowed in trailing section.".

Interestingly, I've noticed this behavior for 'Notes' sObject, for 'Attachments' requests larger than 16Kb were handled correctly!

Has someone seen something like that? How does this works together with a 200 objects API limit?


Update: I've tried this on 2 different instances: one is Developer Edition and the other is Professional Edition with enabled API. Could that be the issue?

Just to eliminate any library specifics (I am on Ruby with Savon SOAP library) I tried making a simple post request with body as the same XML/SOAP message and with body size less than 16Kb --- I received some warning about ContentType, but as soon as I hit 16Kb + 1 byte, I started receiving Timeouts.


Update 2: Tried posting big response ~64Kb (several Note objects) with cURL and it actually worked. I will dig deeper, seems like it might be a Ruby specific issue (or something stupid I am (not) doing).


Update 3: This is strange and stupid, but now everything works like a charm. And what worries me, that I haven't changed anything.

Thanks, everybody for help: you gave me ideas how to try making those requests differently.


Update 4: Next day I started to get Timeouts again. I immediately checked if the same request works with cURL and it did. So, I just replaced usage of Ruby stdlib net/http to curb and voila --- no more timeouts.

Quick googling didn't yield any results if this is a known issue. Probably, it is a combination of the way Salesforce SOAP API endpoint responds and some bug in Ruby stdlib (or misconfiguration on my side).

  • sounds like the ruby client is not flushing the last chunk out of the request, and the server it just waiting for it. – superfell Aug 9 '12 at 6:05
2

Replacing Ruby stdlib net/http to curb solved this problem for me.

Quick googling didn't yield any results if this is a known issue. Probably, it is a combination of the way Salesforce SOAP API endpoint responds and some bug in Ruby stdlib (or misconfiguration on my side).

1

I just tried creating a single Note via the Partner API with a body that was 18,856 bytes. Took less than one second.

This example is using G4S, which is a C# wrapper around the Partner API.

    [TestMethod]
    public void UploadNoteBodyTest()
    {
        SalesforceSession salesforceSession = SessionTest.GetTestSession();

        string filePath = @"D:\Development\TestContent.txt";

        long fileSizeInBytes = (new FileInfo(filePath)).Length;

        string bodyData = File.ReadAllText(filePath);

        Id parentId = new Id("0037000000TGNKL");

        Note note = new Note();
        note.Body = bodyData;
        note.Title = "Test Note";
        note.ParentId = parentId.CaseSafeID;

        NoteService noteService = new NoteService(salesforceSession);
        noteService.Insert(note);

        Assert.IsNotNull(note.Id);

        noteService.DeleteEntity(note);
    }

I then tried essentially the same test but creating a batch of 200 Notes with the 18K body in one API call. It took 8 seconds.

One thought, Note.Body is a textArea that is "Limited to 32 KB" where as Attachment.Body is base64. This could affect the ultimate SOAP message size, especially when using compression on the request.

Other than that I'd suggest looking for triggers on the Note object, but I don't think you can actually create triggers on notes. Could you capture debug logs when the Notes are inserted to see if anything is happening that might explain the delay?

  • I'd have to double check to be absolutely sure, but I've used this API with large volumes of records before and would be surprised if some of the larger requests were less than 16KB. – Matt Lacey Aug 6 '12 at 23:18
  • @daniel-ballinger about capturing the logs - do you mean on server side or client side? If server side, could you give a hint - where I can check those? – antonlitvinenko Aug 6 '12 at 23:49
  • @LaceySnr-MattLacey by my maths the 200 Note batch test I did would have been 3.6MB before compression so it should have been well over 16KB over the wire. Against my test org it took very little time at all. Certainly not in the minutes. – Daniel Ballinger Aug 6 '12 at 23:52
  • @antonlitvinenko Try your name > Administration Setup > Monitoring > Debug Logs. Press New and find the user who the API request is coming in from. – Daniel Ballinger Aug 6 '12 at 23:54
  • 2
    Soap UI is another handy tool for testing out API requests, you can see what's being sent and received etc. which might help you find any issues in the message being sent. – Matt Lacey Aug 7 '12 at 2:04
0

I have encountered this issue as well and found it is an issue with, as explained above (sorry not enough rep to comment), net/https with specifically Ruby > 1.9.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.