3 Replies Latest reply on Dec 6, 2019 9:23 AM by Martien van den Akker

    Can someone tell, what is the Payload size that REST adapter can accept?

    Visvanath Prasanth

      REST Adapter payload limit in OIC.

        • 1. Re: Can someone tell, what is the Payload size that REST adapter can accept?
          Martien van den Akker

          Hi,


          There aren't any theoretical limits I'm aware of in terms of settings. Other then that when you have to process a large message it is processed in the heap and if it contains multiple rows, each row has to be processed.

          So, the heap is a limit and if you need to process a lot of rows one by one from the message, processing time and transaction sizes may be a point of interest.

           

          Kind Regards,
          Martien

          • 2. Re: Can someone tell, what is the Payload size that REST adapter can accept?
            PhilWilkins

            Remember that additionally that this is a HTTP call, and therefore subject to the usual constraints such as connection timeouts.  So if you try to send too much data then there is a distinct risk of a connection timeout either from Oracle OR any network infrastructure between you and oracle. Whilst OIC may not implose any limits some network infrastructure particularly firewalls will treat overly large payloads as potentially malicious content.  This is a specific option for the Oracle API Platform CS to impose such a constraint.

             

            As a general rule of thumb its best not to send a single REST payload more than a few MB to safely avoid this.

            1 person found this helpful
            • 3. Re: Can someone tell, what is the Payload size that REST adapter can accept?
              Martien van den Akker

              PhilWilkins's answer triggers me. We had an extensive mail thread with Oracle about how OIC counts messages. One of the things is that it counts incoming messages as of at most 50k. As soon as you get past the 50k limit, it counts it as another message. In other words, it splits the message up in 50k parts and counts the parts. So 101k is 50k+50k+1k = 3 messages. And so on. Luckily it does not count outgoing messages as a result of incoming messages. But if in a response on a message a response message comes in, it is counted the same way.

               

              So suppose if you have a simple 1k request message, send out to an external party, you transform it into a request to an external party to get a list of changes as of a certain date, then only the incoming request is counted as one, not the outgoing request to the external party. But if the external party response back with a 551k message with loads of records, then this is counted as 12 messages (11x50k + .1x1k).

               

              Doing so, if you have a bundle of 5000 messages per hour, and you happen to process 5001 messages in an hour, you'll have to pay for another bundle of 5000 messages. Thus, it is important to have a proper estimate on number of messages to expect.

               

              So, technically, apart from resources and time-outs, there is also an relevant cost aspect, what it took us some energy to get it on the table.

               

              Kind regards,
              Martien