Maximum Payload Size and limitations for Soap router | Community
Skip to main content
itsme
Level 3
October 31, 2019
Solved

Maximum Payload Size and limitations for Soap router

  • October 31, 2019
  • 1 reply
  • 2850 views

We are using nl/jsp/soaprouter.jsp for creating new records in the database. We are planning to use the xtk:session WriteCollection method and create/update multiple records in one call.

What is the maximum size of request payload the endpoint accepts?

As per the contract, we cam make 50K engine calls per day. So if I merge multiple record insert/updates into one payload, that will be considered as one call. Please confirm.

The methods like write and others accepts the open XML as parameter and thus it is very difficult for the caller to know the actual structure of the payload. Is it possible to generate a wsdl which will expose the attributes of a schema as class properties and some method accepting the class or class collection as parameter to save the records.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jonathon_wodnicki

Hi,

API calls have no limit in size AFAIK, they're ordinary HTTP POST.

The Update data workflow activity defaults to transaction batches of 10k.

That said, if possible use files for ETL as they are strictly better:

  • Simple, don't need a message bus or specialized code
  • Reliable, doesn't require high availability, files can be checksummed
  • Performant, use bulk load feature of db
  • Auditable, can zip files to look backward in time
  • Free, don't need extra hardware and not subject to license limitation

Thanks,

-Jon

1 reply

Jonathon_wodnicki
Community Advisor
Jonathon_wodnickiCommunity AdvisorAccepted solution
Community Advisor
November 4, 2019

Hi,

API calls have no limit in size AFAIK, they're ordinary HTTP POST.

The Update data workflow activity defaults to transaction batches of 10k.

That said, if possible use files for ETL as they are strictly better:

  • Simple, don't need a message bus or specialized code
  • Reliable, doesn't require high availability, files can be checksummed
  • Performant, use bulk load feature of db
  • Auditable, can zip files to look backward in time
  • Free, don't need extra hardware and not subject to license limitation

Thanks,

-Jon