I am trying to configure EDI batch feature in 6.0.1.
read the pdf and here are steps that I tried
create a public queue. deliveryserice =EDI batch, set input. schedule the service
create a TPA, with sender, receiver and ArgeementID= X12 Envelope. set the inputs for TPA record.
create a processing rule with Deliver Document by = Scheduled Delivery = public queue.
Now I submit few EDI document, processing status is set to QUEUED.
That is it, I do see the batched EDI, scheduler is involved but the EDI documents are not batched.
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
Thanks Dawn for sharing your services.
I am still at the very primary step. trying to setup the EDI batching. Somehow I am missing something, feature is not creating the batched EDI.
Tasks query shows, a status of QUEUED, even after the schedule ran.
saujanya,
Are you updating the queued task status? The queue is a series of tasks and after processing the document associated to that task you use wm.tn.queuing:updateQueuedTask to update the task’s status. Here is the basics of what I do when I drain the queue.
repeat until tasksComplete
batchGS100 Second repeat to throttle the GS enveloped EDI documents to 100 per GS envelope
wm.tn.queuing:getQueuedTask
If there are tasks log that the queue has tasks wm.tn:log
wm.tn.doc:getDeliveryContent
wm.tn.doc.xml:bizdocToRecord
mapping flow service to create X12 820 document
If it is the initial task
wm.tn.profile:getInternalID for both sender and receiver
wm.tn.tpa:getTPA needed for enveloping
end initial tasks
Sorry,this is the section we are talking about
[url=“wmusers.com”]wmusers.com(KnowledgeCenter-E-Zine Article)it has archives on Documentation/Development/services/BestPractices etc…
Thanks Dawn. From your article I came to know that, default EDITPA is the one that is used for batching. Initally, I created individual TPA for each partner. Which was my mistake.
Later, I setup the values in Default TPA. and now it works fine.
We too ran into snags with the out-of-the box batching facilities. Never had issues with the TPAs though–we always enveloped each individual transaction set before queueing it. That way, the default TPA was never used for enveloping during batching–the default is only used when queued docs are not enveloped.
We didn’t use public queues cuz in previous experiences we had run into troubles using them so avoided them here. We used an undocumented facility to allow the batch EDI service to be used without public queues. Basically, we collected the list of docs to batch from the TN store (marked with a particular user status) and passed that list to the batch service. We too added sizing controls to prevent overrunning the server with too many docs in one batch.
To clarify, even though we enveloped each transaction set with both GS and ISA envelopes, the batching still created a proper 1-ISA, 1-GS and multiple ST/SE sets with appropriate control numbering. The envelopes on the transactions sets are used by the batch service to do proper grouping and use the proper identifiers. In this way, the default TPA is not used in any way by the batch process–basically you control which TPA to use when processing the individual transaction set.
This is interesting…I’m planning on using the batching facility too, but I was trying to send the transaction to TN without a group or isa envelope to avoid using up the control numbers and avoid unnecessary enveloping. But when I do the convertToString before sending it to TN, the service inserts the control numbers anyway unless I insert a dummy number in the ST segment. Based on this thread it appears that we should be enveloping each transaction so that the final enveloping works properly.
I have noticed that control numbers for ST/SE segments are not in order. All ST have same number. The control numbers are not incrementing.
What do I have to do
Are you creating custom controlnumbers for ST02,SE02 or trying to use webMethods generated ones which convertToString will takecare when you setValue empty?
here is the situation.
create one interchange with 3 ST with custom PO#(which increment) and submit to TN for queuing
Another interchange with 2 ST and PO# quite different for previous interchange and submit to TN for queuing
So now in my queue, 2 interchanges are waiting for EDI batch.
When the EDI batch is execute(mode=IC&GP), I see one Interchange with 5 ST in it, control number for each ST is set to 0001 only and GE01=1
ST control number must increment and GE01=5 which is not happening
Here’s a more complete description of what we did at my last EDI project.
When creating a single transaction set to be batched, envelope the set with the appropriate values as indicated by the appropriate TPA. Do not use the EDI control number table for the control numbers–just let convertToString generate the (bogus and unused) control numbers. It may seem like “unnecessary” enveloping but it actually is necessary to control batching and use the proper TPA for each partner. Without the envelopes the batch process has to make (sometimes erroneous) assumptions.
When batching and enveloping, transaction set control numbers within a group always start at 1 and increment by 1 for each additional transaction set. batchProcess parameter: contentControlNumber=Sequentialize
Group and interchange control numbers use the EDI control number table managed by TN for each sender/receiver combination. batchProcess parameter: controlNumber=fromTable
I think you may need submit each transaction set individually to the queue. You’ve done a “partial” batch yourself, which I’m not certain the batchProcess service supports. What are you setting the “contentControlNumber” parameter to in the batchProcess service call? If you intend your ST/SE control numbers to be the PO#, then it should be set to “none” and you need to set ST02 and SE02 to the PO#.
In my case contentControlNUmber=Sequentialize, I changed it to None and now resulting document has original PO#.
Why I am batching is backend system pushes orders in batchs, so I create a one ISA for all the orders and submit to TN, instead of submit individual orders. As per you, I have to submit individual orders and increment by 1.