I might have partners sending flat files (with no sender/receiverid/doctype) that could be destined for many internal locations (various ftp locations, directories, etc), due to a takeover there are 2 merged companies at the moment. Since we can only have one Enterprise TN profile (with unique DUNS) and only primary/secondary ftp delivery, I’m wondering where a good place is to store the varous ftp/file locations and the best design to handle this - ie how to determine which location to drop the file - I could assume each custom gateway service is for one file type, so for that file type I would grab the ftp location.
One idea is a config XML that maps the gateway service name/doctype to an ftp or other protocol location. I generally like to keep things in TN though. They have v6.5.
“I’m wondering where a good place is to store the varous ftp/file locations”–> It’s always a config database would be better option store all the FTP info and select/retrieve it based on the customer name or number (key field) along with interface name and then FTP process the files to the expected Internal destinations accordingly:
The approach I’ve taken in a couple of places is to not use the Enterprise profile for anything but error notifications (using the Contacts). Instead, each internal system has its own profile.
This article from years ago describes one technique for processing a document intended for multiple recipients.
Sorry it’s not multiple recipients at the same time, I mean different internal recipients. I thought about separate internal profiles but they can’t share the same DUNS afaik
I presume that the installation has DUNS as the default/required TN ID. That’s a bummer. At the places where I’ve done TN work we changed it to be Mutually Defined to provide more flexibility. Then we set DUNS only on profiles that needed it for doc recognition or creation (when creating the doc we’d read the profile using the Mutually Defined ID to look up DUNS or whatever ID type and set it into the doc).
But since these are internal systems, and the documents don’t specify the receiver, the profile doesn’t need to use a “real” DUNS. Just set it to some reasonable string.
yeah thanks that might be doable I was thinking that as well. Then I need a way to determine which profile to use - maybe an extended field in the profile that ‘subscribes’ to the flat file doctype.