I am trying your approach, thanks. The documentation says you can use batching without interchange envelopes - to me, the sender/receiver pair in the individual transaction without envelope (via the bizdoc) is enough to find the TPA with all the info contained within.
Using your approach do you split the outgoing envelope (containing 1 transaction) into 3 documents (not really necessary to me) and if so do you base the processing rule (to batch) on the envelope, group or transaction or does it matter?
Right now using an envelope as you suggest, TN splits the envelope into 3 docs and triggers the batch process. But then TN is complaining about the sender/receiver id or qualifier during batching which should be available since it’s in the matching TPA. Obviously I don’t want to hardcode this in the batch input paramters since it can be used for multiple sender/receiver pairs.
Yes, wm.b2b.editn.batch:batchProcess can be used to process queued documents that do not have envelopes. There are pros to this:
Reduces the amount of data stored in each queued transaction set.
Avoid the work to envelope each transaction set, which includes looking up the appropriate TPA to set the envelopes appropriately.
The cons:
Each queue must contain documents for just one partner. If the number of partners is large the administrative work can be tedious.
Cannot invoke wm.b2b.editn.batch:batchProcess directly from the scheduled task without hard-coding parms. Must use a wrapper service that looks up the appropriate TPA to set the majority of the batchProcess inputs–e.g. sender & receiver IDs and qualifiers, standard, version, environment, control number.
We chose to put the envelopes around each transaction set before queueing so that we didn’t have a bunch of public queues to manage.
When queueing the resulting enveloped transaction set (X12 Envelope with attribute “EDI Batch” not set), we’d queue the X12 envelope. No split is necessary for queueing BUT because the TPA is used to determine splitting, and we need to split the final outgoing envelope at the group level (see below) it gets split to the group level.
When invoking batchProcess, the sender & receiver ID and qualifiers are (unfortunately) required inputs so you must set them to something. Since all your queued docs have envelopes, these inputs will never be used, so it doesn’t matter what you set them to. This was a painful, several hour debugging effort for me to find that out!
For the outgoing final envelope (attribute “EDI Batch” = “Interchange”) we have a rule that does the delivery. We split to the group level as FA reconciliation says that the split must be done to that level (there’s a side discussion we can have about whether the batch process creates the necessary entries in the tracking tables, which would eliminate the need to split to the group level but I can’t remember how it works for sure). We do not split to the transaction set level. The group envelope is explicitly ignored in processing rules.
Thanks Rob. I guess my point is that TN “should” be able to get the TPA strictly from the sender/receiver pair in the bizdoc and you “shouldn’t” have to hardcode unused values in the batch input. The other thing I noticed was that the sender ids and qualifiers as well as delimiters have to be real values not dummy values (maybe in my case because they’re actually being used - see below).
Okay - I got the batch envelope to be created by TN. However I had to provide the sender/receiver id and qualifiers as well as the delimiters in the batch input, and TN actually used these values not the ones in the envelope. I don’t want to put company specific info in the batch input for obvious reasons.
Agreed that supplying a sender/receiver shouldn’t be necessary.
According to the docs (and behavior I’ve seen previously) the receiver/sender ID and qualifiers are only used when the queued document does not have the group and interchange envelopes. If all docs being batched have envelopes, then the receiver/sender inputs are not used. If that’s not happening for you then something is wrong.
The delimiters parameter is indicated to be optional. If set, they are indeed used regardless of what’s in the TPA or the doc being batched. Trouble is, since the parm is a record either all of them must be specified or none of them can be specified.
I’m working on something else right now, but when I ran it the batch didn’t fire. The activity logs showed an error that the sender/receiver id or qualifier were missing. So I put them in, then it complained about the delimiters. So I put them in too and then it worked but it’s using the values I supplied not the ones from the TPA. What version of IS/TN did you do this on?
What are your batchProcess input parms? I’m chasing something related to this so I’m eyeballs deep into making sure I understand the entire process so can keep an eye out for what might be causing the behavior you’re seeing.
I’ve tried a variety of combinations but here’s the latest. These should all be dummy values and not used in the batch process. But when I leave them out there are errors in the activity log such as ‘sender id or qualifier error’. I changed the receiver to a different company than what’s in the edi file so that I could see if it was using the hardcoded values below or from the TPA.
senderid 0000800SARD
senderqualifier 15
receiverid 00003F0SARD
receiverqualifier 15
mode IC&GP
oneBatchQueue SINGLEOUTPUT
standard X12
version 2003
environment Production
controlNumber from Table
contentcontrolNumber Sequentialize
acknowledgement false
delimiters
record (carriage return using large editor)
field *
subfield :
release (blank)
Will, I’ve dug into this about as deep as I can but have been unable to explain the behavior you’re seeing. But lemme summarize one last time just in case we’ve crossed wires in our posts:
The docs say the sender and receiver IDs and qualifiers are used when generating the group and interchange envelope only when the transaction set being batched does not already have a group and interchange envelope. This is not the behavior you’re seeing.
When oneBatchQueue is SINGLEOUTPUT, the specified sender and receiver IDs and qualifiers are used to set the sender and receiver of the resulting bizdoc.
According to the docs, if the delimiters parameter is set (any one of the fields) they are always used. If not specified, the delimiters from the appropriate EDITPA is used. If the EDITPA doesn’t specify delimiters, “batchProcess uses its own defaults.” The behavior you’re seeing is that they are always required and used. Do all the partner-specific TPAs exist? Are the external IDs on the profiles set correctly (no typos)? Are delimiters specified in the default TPA?
If this isn’t acting the way the docs indicate it would probably be worth getting tech support involved.
I agree that tech support may be required. Since TN is showing the docs with the correct sender and receiver I can say that the profiles and doc types are correct (ie. the extended ids are matching and the 3 doc types are shown). Also, I turned on and off FA generation so verify that my TPA is being invoked. Once I hardcoded the sender/receiver I get the following error - “Segment, field or sub-field delimiter has not been setup [EDIFTN.000010.000778]”. Based on the docs saying the “batch process uses its defaults” one question is whether the default TPA values are used or some other values within the core code.
What is the release of your EDI package ?
I’m still “experimenting” the batch process, but I’ve got better results since I installed some fix (WmEDI_6-1_Fix18, WmEDIforTN_6-1_Fix25, WmEDIforTN_6-1_Fix9 …)
Many of you are using the batchProcess with a large amount of data. Could someone explain to me how you manage the �tracability� of transactions ?
In fact my problem is:
I have put documents in a queue, but how to know when my documents were batched and sent to my partner?
For me, the related documents should have been set. I discussed with the support on this point but webMethods told me this is not a bug or a mistake. They do not provide this functionality.
Gilles,
I assign a conversation id to the documents that way I can track all the related documents including the returned MDN through that one filter in TN. I used sender ID, Reciever ID, and document id as stated in the user guides.
HTH
Dawn
Thanks Gilles - I will see if I can get the administrator to add these fixes. For anyone else having this problem what I may have to do is either batch the docs myself (after sending individual transactions to TN) OR have them go into TN already batched as they come out of the source system.
“For me, the related documents should have been set. I discussed with the support on this point but webMethods told me this is not a bug or a mistake.”
I agree that the resulting batch document(s) should be related to the documents that made up the batch. IMO, this is indeed a “mistake” on wM’s part. This should be done.
To sum up the shortcomings of the batch process (some discussed here, some not):
Relate the documents that were read from the queue to the resulting batch document. IMO, this is a serious ommission and one that must be rectified.
For unenveloped documetns, the sender/receiver should be determined from the bizdoc rather than from parameters to the batch service.
The batch service should be able to get the list of documents from other sources, not just public queues. For example, one should be able to pass a document list to the service. Another option would be a facility to read documents matching TN attrbiute criteria (sender, receiver, TN doc type, user status, etc.) and then update each document after batching.
The batch service needs to be able to be throttled. If one has 1000 documents queued, it will try to process them all, which can exhaust memory.
Control submission to TN. Sometimes it might be preferrable to not submit the resulting batch document to TN.
The batch service should provide return parameters about the status of each document created and submitted to TN.
Anyone else have ideas on how the batch service could be improved?
Gilles - do you know which fix specifically addresses the batching problem? Are there other fixes that are related to this problem (since you put … in the list of fixes).
I’m going to request the fixes so I can look at the 'read me’s so any more specifics would be greatly appreciated!
We batch EDI documents using the EDI batch feature in 6.0.1. There was a public queue set up and the batch process is scheduled to run at 12:00PM and 13:00PM. The documents come in high volumes from 11:30PM to 12:15PM
The problem here is with the 12:00PM batch. It runs some times and it does not run some times. I have to wait till 13:00PM for the envelope.
I thought the problem is because I was trying to batch and queue at the same time. But the batch process runs on some of the days when the documents are coming in. There is no other process running at that time that looked suspicious and looked like preventing the formation of the batch at 12:00PM. I checked the schedule interval and it looked ok. Did any one run into such problem earlier?
Hi, we are using EDI X12 batching/queuing process followed by X12 envelope. Everything was working fine and we had Hardware issue with the server, due to some database issues we didn’t retrieve all the information. Eventually process started normally and when we are trying to send the X12 Envelope document types we are running into Duplicate Control numbers related to one trading partner meaning the control number is repeating from the period of data loss. I guess since there was data lost in the database. I am just wondering about is there any way to reset the control numbers? This is the following configuration we are using: mode: IC&GP oneBatchQueue: MULTIPLEOUTPUTS standard :X12 version: 4010 controlNumber : fromTable groupControlNumber :fromTable contentControlNumber :Sequentialize acknowledgement :true Could any one suggest me solution to solve the issue… Thanks in advance, capri.