I am trying to build a service (in Developer) to create an FA and deliver it back to TN. I call the generateFA service and it appears that the FA is created, then I call tn:receive, and it does deliver SOMETHING to TN, but it appears that it’s sending the entire pipeline rather than just the FA. Of course, then TN doesn’t recognize it. (It’s also sending back the entire original inbound transaction set, so TN is seeing that as well.)
I’m really new to these tools and I can’t find a sample that does this (even though the documentation claims there is one). The FA samples seem to be transmitting the FAs directly back to the partners rather than submitting them to TN.
Is there some sample code somewhere I could look at? Or, can someone explain exactly what the receive service is looking for as input?
I’m not sure what you mean by that the “entire pipeline” is being sent to TN. Try the following steps.
- Map you inbound edidata which should be of string type to edidata in pipeline in of generateFA. Make sure that addGroup and addICEnvelope are set to true. Verify that FArequest has the appropriate value. You can force it to yes for testing purposes to make sure you all ways get an FA and that your process works.
- Once generateFA runs the outDocument object should have all your FAs complete with ISA and GS envelopes.
- Invoke tn.receive via http and map the outDocument to the string argument under the data document on the pipeline in. This will post you FAs to TN.
Chris - thanks much for your reply. I got through Step 2 OK, but I’m still confused about invoking tn:receive. The only inputs I have for tn:receive are node (which I assume is where I put outDocument) and TNParams. I don’t understand what you mean by the data document.
Thank you, Chris I got it to work. That was a huge help.
I think the docs are a bit misleading . . . or maybe just vague.
From the EDI Module User’s Guide, p. 45:
“Invoke wm.tn.receive service to submit the FA back to Trading Networks.”
Being very new to this game, I assumed that meant invoking the service directly.
You can invoke wm.tn:receive directly. To get this to work you need to map your enveloped acknowledment string to a field called edidata (i.e., if X12, the ISA to IEA string which includes the 997). You don’t need to map the edidata field to anything, it just has to be in the pipeline. If edidata (the field must be all lower case) does not exist, then you will get the unrecognized document.
You can also use the wm.tn.doc.xml:routeXml service, which does the same as wm.tn:recieve, except it doesn’t check for user validation.
You will also want to make sure your pipeline is clean. There is a lot of data left over in the pipeline when a service is invoked from TN and it can cause problems in TN if it is not dropped. To determine if left over data is the problem, create a little test service you invoke directly, hardcoding the edidata input and invoking wm.tn:receive.
Hope this helps,
Thanks, Michelle, but I’m still having the same problem with the pipeline. I get the edidata just fine, but just by invoking tn:receive, it creates ICValues which I can’t seem to get rid of. TN has the edidata, but also the ICValues, which it doesn’t recognize, of course. By the time it shows up in the pipeline, it’s already been delivered. Or what am I missing?
Thank you, Michelle, I finally got it working. The trick seemed to be to use the clearPipeline function - just dropping the variables did not work, and the edidata was not being recognized by TN. And I finally also figured out the ICValues is debugging stuff, meant to be helpful!