I have been trying to persist only the Group envelopes in TN without the ISA but I have been unsuccessful. This is what I am doing and maybe I am missing something.
a. Build ST segments
b. addGroupEnvelope
c. Call recognize service and pass the following values in TN_parms
1. SenderID
2. ReceiverID
3. $contenType : application/EDI
4. DoctypeName : X12 Group
5. edidata : contains my GS/ST data.
d. routeBizdoc
The service fails at step (c.) with errors like unable to create bizdocenvelope.
Can someone please help me with persisting a GS document in TN
I am using 6.0.1. and I want to persist only the GS in TN. I was able to persist it successfully when I include the ISA but it doesnt make sense to introduce the ISA with all the control numbers at this stage. In TN, I cant tell it to build only the GS doc bypassing the ISA envelope document when I use tn.receive. Also, the other main reason is we want to batch these GS’s and make use of the EDI batching process that will build the ISA and send it to out. This way, I dont have to worry about control numbers at the ISA.
I was trying the easy way out, by using the recognize and routeBizdoc services and the TN_parms record. Maybe, I can persist the GS only in TN as “X12 Group” doctype by creating the bizdoc using CreateEnvelope, addContentPart and then persisting.
Any suggestions or improvisations, please feel free to let me know.
There are a couple of ways I know you can do this.
In wm 6.0.1 review wm.b2b.editn.batch:batchProcess for how to batch EDI documents into TN. This is new in 6.0.1. I have not used this procedure first because I had already developed the one mentioned below and it offered no advantage to switch from what I could tell.
The other way I have does is in my flow service I pre-sorted my application file by Trading Partner. I then append the mapped Transaction Sets (ST-SE) for a given partner into stringList. When the partner changes I wm.b2b.edi.util:addGroupEnvelope, the wm.b2b.edi.util:addICEnvelope, and post it to TN.
A word of caution is that wm.b2b.edi.util:addGroupEnvelope generates the Group Control number as a string when the EDI standards dictates that it be an integer. Because wm uses the data day of the month as part of its algorithm you will get a leading zero on days 1 thru 9 of the month which violates the standard. I copied the service and modified by adding invoking addInt and adding 0 to the control number to convert it to an integer to solved the problem.
Search the archives here as well as this topic has been discussed with lots of input from the real gurus in the group.
Thanks for the input and the suggestions. I am trying to make use of the wm.b2b.editn.batch:batchProcess as we are starting the whole process from scratch. Moreover, the various STs are built during different times of the day and hence, I need to create a separate TN txns. At the end of the day, I need to pick them up, build a GS/ISA and then send it out.
I recently had a similar requirement on my project using IS 4.6. The design I used was as follows:
Create a dummy or holding profile in TN.
Post the partner’s transactions to this dummy profile throughout the day. The dummy profile is needed because I don’t want to invoke a processing rule and send the data to the partner prematurely.
At the end of the day, a scheduled process is run that queries the TN database for all of the transactions posted to the dummy profile throughout the day.
The process combines all of the transaction sets, adds the group and ISA segments, and submits the single envelope to TN using the real partner ID and qualifier. The process also changes the user status of the dummy transactions so we know they have been processed.
Hopefully the new service in 6.0.1 will meet your needs and save you a lot of time!!
Why the dummy profile? If you have no rules set at the Transaction Set document level could you not just post the docs to TN to the appropriate partner with a different Status. Then check for docs with that particular status later in the day via a scheduled service and envelope them and send them to the VAN?
Thanks for all the input. Finally I was able to persist the EDI documents at the GS or ST level without having an ISA segment. This helps me to route the documents at the ST or GS in a batch at the end of the day.
Also, I used the EDI batching process which is new in 6.0.1. It did not work the first time I used as it was with lot of bugs. After applying around 7 patches that webMethods provided, it is working now. So anyone working with webMethods EDI batching process, please make sure you apply all the patches as of June 06, 2003
FYI
Regarding the patches. There are several patches for EDI on wm 6.01 on the Advantage Knowledge base. Check to see which ones may apply to you and request them from tech support. There’s also few for Developer and the Flat File Schema Editor.
Here are the steps I used to persist the EDI GS or ST documents in TN unlike the normal tn.receive service which expects the ISA segment also.
a. wm.tn.doctype:view (obtain the internal id of TN document…for eg "X12 Group or “X12 4010 850”
b. wm.tn.doc:createNewEnvelope (specify the internal ids of the EDI document, sender id, receiver id, etc.)
c. Set any user defined fields by changing the Bizdoc
d. Call appropriate service to change EDI attributes
e. wm.tn.doc:addContentPart (add the EDI content part like the GS or the ST segments)
f. wm.tn.route:routeBizdoc (finally to persist the Bizdoc to TN)
After this, you can setup you customized processing rule to trigger appropriate actions like sending the TN docs to a queue.