I currently have a working process that involves IS reading my flatfile from disk and processing it. What I want to do is to have that flatfile stored in tn just like any other EDI document. How do I define a doctype for a custom flat file in TN?

So far I have created a flow that I can ftp the file to. In that flow I do the following:
pub.io:streamToBytes
pub.string:bytesToString
EDIOutbound.utils:determineTemplateToLoad (customer flow)
EDIOutbound.process:load810FileTemplate (custom flow)
wm.b2b.edi:convertToValues which outputs an EDIVaules record that should contain my flatfile but my data is placed in unDefData in EDIValues.

I’m positive that the template being passed to convertToValues is correct as it is the same template I use when the file is read from disk.

I had expected that the EDIValues output from convertToValues would contain the correct structure for my flat file that I could then create the doctype for in TN. Is this the correct logic?

Any suggestions on what is happening with the convertToValues.
Thanks.

Chris

I see you are using EDI and custom template to parse your flat file. you can defenately do this for processing but it will not help in placing this data to TN!

With flat files and TN you have 2 choices.

1. Wrap flat data into XML adn then submit it to wm.tn:receive to build a BizDoc object and store in TN database. This is a simple way.

2. If you can use your custom service to get flat data first instead of standard TN recieve service (which I think your case!) You can create your own DocType in TN and get its ID then in your custom service you get flat file data from stream and put it into pieline then you can create your own BizDoc object with flat data and use your custom DocType ID and route it to TN (Do not use TN recieve srvice for this!)

In first case you will se your flat data with XML wrapper and second you get data as it is in your TNB DB.

I agree with Igor - we’ve done option 1. It’s a bit of a pain because you have to encode/decode the string since it’s wrapped with XML elements. Also you don’t have the original unaltered file.

I got option 2 to work in a dev environment and seems better since you’d have the unaltered version of the file. However webMethods 6 is supposed to handle flat files better so we’re holding off for the time being.

Will

Igor, Will

Can either of you elaborate further on option 2 as that is where I’m trying to get to. Am I not on the right track with the steps in my custom flow.

Chris

What I did was create a new doctype in TN with no root tag, giving it a descriptive name. Then in a flow service call wm.tn.doc:createNewEnvelope passing it the internalId of the doctype you previously created (I ran the wm.tn.doctype:list service ahead of time which lists the internalIds of all the doctypes). After you create the envelope you call wm.tn.doc:addContentPart passing it the byteArray (for the flat file), the partName (anything will do) and the mimeType (I used text/plain).

The issue with this is that you have to know what doctype you’re receiving - which can be accomplished by giving a partner a specific URL for that type of doc. The invoked service would wrap it in a bizdoc and then send it to TN.

Will

Will,

How did you or did you set identifying queries?
So far I’ve created an empty docType in TN. I am unable to set identifying queries.
I first do a bytesToString and then convertToValues.
I then invoked wm.tn.doctype:list to get my list of Types.
I have looped thru the list of Types to select correct typeId.
I then invoked wm.tn.doc:createNewEnvelope and mapped in the typeId.
I next invoked wm.tn.doc:addContentPart. Here I map in the bizdoc created from wm.tn.doc:createNewEnvelope. I set my partName and mimeTypes as you instructed and I map my string from bytesToString to partsByte object in addContentPart.
At this point I get a EXMLException error.
I replace mapping string with EDIValues to partsByte but I get the same exception.

Any ideas on where I went wrong?

I can take a guess at what’s wrong. You have to map the bytes into the addContentPart (not a String). I can’t speak for the EDI stuff since I’m not using that in this particular case.

You don’t need identifying queries in the doctype since it’s not XML - you won’t be identifying the doc in the usual way (ie. you don’t send the flat file directly to TN). Because you are creating your own envelope setting the doctypeId, TN will know what it is when you submit it afterwards.

HTH
Will

Will,

I think I’m close but not quite there. I mapped by bytes from streamToBytes to partsByte and that got rid of the error.
Now I need to post that back to tn.receive get the document into tn. What am I mapping from the bizdoc to http.data?

Thanks

You don’t have to HTTP it to TN. Use wm.tn:submit which takes your bizdoc.

Will

Will,

Thanks a bunch!
I’ve never submitted a doc that way.

I think that’s it but I still have to create my processing rule and add the correct sender/recevier id’s.

I will post and update tomorrow.
Thanks again!

Chris

Will,

Thanks for your help.
The document appears in TN with the correct sender/receiver.
The rule gets kicked off and I can read the data with bytesToString.

Absolutely great!

Glad to help!

Will

Hi,

 I was very interested in the solution you guys have for sending in a Flat File to TN by creating your own envelope and using submit.  I was able to use this thread to do exactly that get a Flat File into TN and call a service to process that file.  

My only issue now is how do we get TN to process the Flat Files I pass in as Large Documents?  Has anyone figured this out yet?  Since we are bypassing the tn.receive, how can we get TN to determine if the file we are sending is Large or Not? 

Any help would be greatly appreciated!

Thanks!

CS

CS,

Once the doc is in TN you can treat like any other doc posted via tn.receive.
In my case I have a rule that kicks off a flow service.
I’m not doing any large doc stuff specifically.

HTH

Chris

If you want to do large doc handling with this approach you’ll need to do more work in setting up the envelope and streaming the content to disk since you’re bypassing the usual mechanisms TN uses to do large file handling.

1. Write the incoming bytes to disk (don’t load them all to memory)
2. Create the envelope per previous posts.
3. Open the disk file as a stream. Place the stream object in the appropriate field in the bizdoc envelope.
4. Set the large doc flag to indicate it’s a large doc.
5. Call wm.tn:submit

Rob, Chris

 I appreciate the quick response.   

But Rob could you give me any more details as to how Large Document handling could be implemented with TN using Flat Files. Specifically what fields in the BizDoc do I need to populate with what values. I have tried setting the LargeDocument field to ‘true’, and passing in a Stream from a file I saved to disk. But no luck!
I don’t see anything in TN when I do this. I am getting an error though, indicating that TN was unable to insert the Data into the DB. I think I may not be populating the right fields.
If you can let me know what fields are required for this to work, and what to map?

Thanks again!

CS

“Specifically what fields in the BizDoc do I need to populate with what values.”

Unfortunately, I do not know. There may be a service or two within the TN package that can help but I need to do some research. I’m not sure how TN persists large docs. Basically you need to reverse engineer the processing that the content handler/wm.tn:receive performs and reimplement.

Followup.

I notice I am unable to resubmit these type of documents in TN. I get the following error:
TRNCONS.000000.0000003
wn.tn.doc:resubmit

Will, Igor did either of you encounter this problem? If so how did you solve it? Am I missing a parameter when I submit the doc originally?

Thanks.

Hi,
I want some relevant documentation w.r.t Conversation scripts that would enable me to have some hands on experience from end to end using them. I am mainly in search of a simple example that would help me in understanding the usage and implementation of the mentioned topic.
Thank you

Kishan,

I don’t really understand your question.
But my suggestions are see the wmEDISamples and wmFlatFileSample packages. Then re-read this thread as all the info you put a Flat File into TN is here.

Kishan,

If your question related to the mentioned topic,

use the service wm.tn.doc.ff:routeFlatFile and convert the flatfile string as a (*Stream) along with TN_Params,then TN can recognize the FF as DocType.

HTH.

Hi,
I noticed that Chris has a similar problem to mine. I am sending flat files to TN. The files get processed fine and I can also view the content of it. But somehow I can’t resubmit the document. I was under the impression that you only had to include the service name of the service sending this FF in the $receiveSvc variable in TN_parms record type, when you submit the flat file doc. Is this correct?

I get this error:

ErrorMessage:
<errorid> TRNCONS.000000.000003 </errorid>
<errorlevel> ERROR </errorlevel>
<serverversion> </serverversion>
<servername> </servername>
<serverhostname> </serverhostname>
<clientversion> </clientversion>
<clienthostname> </clienthostname>
<username> </username>
<classname> doc.DocPanel </classname>
<methodname> gResubmitAction.actionPerformed </methodname>
<errortime> Thu Aug 04 12:30:16 GMT+02:00 2005 </errortime>
<errortext> wm.tn.doc:resubmit </errortext>
…
…
…
…
</stacktrace>
</originalexception>
<action></action>
<level></level>
</exmlexception> </exception>