I found some shortcomings in using the EDI batch feature. If this doesn’t relate to your circumstances ignore this posting. I went through a lot of pains trying to use the EDI batch feature just to realize it doesn’t meet my organization’s requirements and created my own using public queues instead.
The biggest road block I found in using EDI batch is I could not control the TPA. The TPA in EDI batch is hard coded to the default EDITPA and you cannot override it. We only use a unique TPA when necessary, but for one trading partner we needed to extend the TPA to control the receiver id at all levels since it was different from the GS to the ISA and also different to the AS2. We also had to control a different version in a non-standard way from the GS to the ISA (directive from management to have no impact to the customer- do what ever they want). Because of this the EDI batch feature was not fully functional for our circumstances. If that is your case I will give you a run down of how I solved this.
One other detail too is that when we were requested (last minute scope change 10 days prior to go live after 1.5 months of testing) to batch this new trading partner’s EDI documents we hit a huge performance issue on the run time because the batch EDI document became so big when batching 1900 documents into one. Thru monitoring the thru put of the service I saw a huge hit on performance after I believe 300 documents had been processed and it got worse as it ran. At first before doing anything it took 2 hours 45 minutes processing time. After some tweaking it took total runtime (including delays with queue initiations 3 of them) I got the total runtime for 1999 documents down to 25 minutes. This still was not great but I only had about 3 days to have a complete solution in place.
Here’s a quick over view. I have 3 public queues in use. The first is the queue for my canonicals. I had to ensure that this batched EDI file was sent only once at the end of the day so I batch my canonicals upon receipt into TN by delivering to the first queue that is sheduled to run every day at a specified time.
The first queue drains at the scheduled delivery time and thru nested repeates which creates batches of 100 EDI documents enveloped to the group (GS level) with an attribute of EDI batch with the value of group. After updating the attribute I route the bizdoc to TN enveloped at the GS level.
In TN I have a processing rule setup at the X12 group envelope level with an attribute of EDI batch equal to group and the action is to deliver to my second queue for batching the 100 EDI documents enveloped at the group level. This second queue I run once at the setup of the queue and do not have setup for scheduled delivery. It is just a queue to hold all the document in batches of 100’s. I determined the 100 document batching level by doing several identical runs with the repeat parameters set at varying levels to determine the optimal performance.
So my first queue’s scheduled service continues processing all the batched canonicals and mapping to the X12 format, adding group envelope, updating the EDI batch attribute, and routing to TN until all the canonicals are processed. After it completes all the canonical processing it submits the service that drains the second queue that contains all the batched group envelopes.
This triggered service then drains all the group enveloped 100 batched EDI documents and appends the contents to create the single batched EDI string. I get the TPA and profile information only once for the entire batch which saves a lot of the run time on 1900 documents. After all the documents are combined into one I re-envelope and receive it into TN.
In TN I have a processing rule that recognizes the ISA envelope for that TP and triggers a se