Stephen,
Normally we try to avoid largeDoc processing as much as possible, but I guess you already know that 8) It kills performance, makes the whole processing logic a bit harder to understand, and lastly requires you to figure out where best to “chop” the document so that you don’t end up with multiple levels of “largeDocs”.
I’m guessing there’s two alternatives for you, w/o having to change the BigDocThreshold:
-
persist only the filename into bizDoc, and have your processing service read in the file yourself. Definitely ugly, and you won’t have a record of what exactly you’ve processed in TN.
-
I’m not sure if this will work, but might worth a try – Construct bizDoc yourself in step 2 (File Polling invoked service). Call wm.tn.doc:createNewEnvelope, and then wm.tn.doc:addContentPart, supplying storageType and storageRef. My thinking is by supplying the storage parameters, TN will treat the document as largeDoc irregardless of the BigDocThreshold. Unfortunately I don’t have time to try this, so I can offer it up as a possibility. 8(
Lastly, both RosettaNet and EDI (for TN and EDIINT) offer additional services to deal with largeDocs. FYR.
#B2B-Integration#Integration-Server-and-ESB#webMethods