Skip to Content
author's profile photo Former Member
Former Member

iDoc performance question

Hi experts,

I have a question regarding iDoc performance. We will receive an iDoc containing more than 300 000 records (about 20 or so fields per record) every day from an external system, and I was wondering about the performance of that import. I realise that there are many factors that affect performance, but in "general", is an iDoc with more than 300 000 records considered a large batch which requires a lot of power to import?

The file coming in from the external system and converted to an iDoc by a middleware will most likely be split up due to limitations in the middleware software. We might get batches of 50 000 records instead. Not sure though if that will make a difference.

Thank you!!

kind regards,

Dionisios

Add a comment
10|10000 characters needed characters exceeded

Related questions

3 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Dec 15, 2004 at 02:12 PM

    Hi Dionisios,

    Certainly processing such a volume of data keeps the available work process busy for a longer time.

    It is better to split the idoc into smaller chunks and schedule the processing.

    Though the aggregate time consumed to process this IDoc remains same, this appraoch will not load the availble work processes. Also, this results in sort of a parallel processing if multiple work processes are avilable.

    This can be adopted, provided, there is no restriction that the data should be sequentially processed.

    Hope this helps.

    Regards,

    Ranga

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member

      Thank you for your replies, they were both very helpful. It's is very likely that we will split up the iDoc in smaller batches, though I am concerned about the overall performace since we will have other iDocs coming in as well from other interfaces. But at the moment there isn't much we can do about it.

      What other alternatives do you recommend that have as good as traceability and error handling as iDocs? Would storing of the data in a databases table and then have R/3 read from that be a better choice? I suppose in that case we would have to build most of the error handling and logging ourselves.

      kind regards,

      Dionisios

  • Posted on Dec 16, 2004 at 08:47 AM

    Hi Dionisios,

    IDOC handling itself is fast - your total runtime will depend on further processing in the system.

    Only if you can make rough checks beforehand and discard hugh amounts of the incoming data, own tables might make sense. Then own error handling is the price you pay...

    Kind regards,

    Christian

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Dec 15, 2004 at 01:28 PM

    Hello Dionisios,

    in general IDOC inbound process is split into two parts: creating the IDOC and booking the data. Second part depends of course on your application.

    If you (would) receive one large IDOC with 300 000 positions, application would have to handle complete data in one transaction -> hugh memory consumption, won't work probably.

    Having 300 000 headers with only one position -> system is occupied with handling, bad idea either.

    Splitting in 50 000 portions sounds OK. Try to imagine to change a document in SAP later: scrolling a hundred times before reaching a specific line is nasty (and slow). Only some documents in SAP are able to handle several hundred positions without to much delay for each action.

    Maybe this helps a little in your investigation,

    kind regards,

    Christian

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.