Currently, mine is hardcoded, on a per trading partner basis. There is a class definition that handles a specific transaction set (such as purchase order), then I subclass it specifically for a trading partner. The subclass implementation only has hooks for the mapping itself, and knows as little as possible about EDI or the business process itself. There is a master process that examines the file, and knows what kind of object (that part is table driven) to create to do the mapping.

It is a work in process, and certainly is not as mature and bulletproof as what you have. It is for in-house use, so I can tweak and improve it as we go. Someday it will be complete. :)

>
>Our translators are table based, but in hind-sight, if I was starting from scratch, I think I would hard code the solution for performance reasons. Table based solutions can provide flexibility, but they are harder to debug.
>