SOAP API Request with body larger than 16 Kilobytes results in Timeout Exception

Question

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).

Answer 1

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).

Answer 2

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?

Answer 3

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.