Sending Out EDI Batch Perfromance Questions RRS feed

  • Question

  • Hi All,

    I have an orchestration to extract our business XML then transform it to the EDI xml and publish to the party batch. We can generate the EDI batch file success, but the performance is too slow for us.

    For example, our business xml contain 10,000 records, each record will be transform to 1 EDI xml, like 810. The orchestration take less than 3 minutes to extract, transfrom and publish all 10,000 record to EDI xml. We configured the party to release the batch per 1 minutes, BizTalk take over 10 minutes to generate all the batch files(5 files totally and each file within nearly 2000 transactions)
    Is there any way to optimize the performance? We are using biztalk 2009.



    Tuesday, December 27, 2011 6:25 AM

All replies

  • It is hard to make suggestions without knowing more about the design.  Is it possible to implement without an orchestration?  Have you tried to determine if there is any particular bottleneck in the process?
    Please mark this as answered if it helps. Walter Michel
    Tuesday, December 27, 2011 11:03 PM
  • Hi Walter,

    Thanks for the response.

    Actually, our orchestration performance is running fine, we accept it, but after our orchestraion publish the messages, the batch job is done by BizTalk's build in EDI component, that's not our code, this part is too slow to us, in other words, the slow part is in release EDI batch.

    When I monitor the folder, I found that the generated file take 2 or 3 minutes from 0k to 200k of the size. I have tried to create a new host/host instance for the file adapter, but it is running the same.



    Wednesday, December 28, 2011 1:06 AM
  • The batching service must cycle down each time you tell it to dehydrate (in your case every 1 minute). Because there is a cycle down/up process that must take place, you will incur overhead (time) while waiting for the cycle to happen.

    If you are taking 10 minutes to generate 5 files from the original 10,000 EDI XML files (placed in a file folder by your orchestration), then you have a couple of things to consider.


     1) The recommended files per folder maximum is around 10,000. So if you are pumping in that many files into a single folder, you *will* see an impact on both scan, read, and delete functionality on the files you are attempting to consume for your batching. I personally wouldn't recommend this many files in a single folder.

    2) Because you are setting your interval to 1 minute for the batching process, you will be cycling down the service to complete the batch, and forbid the additional incoming data to be processed, creating and publishing your batched EDI and re hydrating your service. All of this is rather time consuming. 

    You might want to consider both limiting your file storage size (possibly using MSMQ in place of FILE) and extending your 1 minute batching time limit to a longer timeout (possibly 2-5 minutes).

    I don't know all of your requirements, so these might not be options, but considering your complaint, these are some viable solutions to improve performance, aside form additional hardware.

    Wednesday, December 28, 2011 10:43 PM
  • The only things I can think of is checking to see if EDI status reporting is enabled and also check tracking.  I guess you should also make sure that AV or something else is not slowing down the file write.


    Please mark this as answered if it helps. Walter Michel
    Wednesday, December 28, 2011 10:43 PM