Hi,
No problem, let's see if I can help a bit. Before I start: my experience (around 4-5 years) is only with Oneworld. I know nothing about WorldSoftware and I've never used Oneworld with A/S400 and DB2. Only Intel and Unix with Oracle and SQL Server.
1) Usually, the legacy people is responsible for the files. All we do is suggest some ways to handle the operation properly and avoid problems.
Flat files is one of the possibilities. This option suits you better when the data to be exchanged is usually new data, altough it works with any situation. For instance: the company has a legacy system to handle sales orders from their customers and every new sales order must be entered also into JD Edwards. So they produce a flat file with all the new sales orders and interface it with JDE. Flat files are great for that kind of stuff.
When your needs are more like replying to JD Edwards any operation performed over a record into a legacy system, then I think that using an intermediary table suits you better. It's easyer to handle all the operations (insert, update, delete), while flat files are better for inserting new records.
2) CSV is when we have a flat file with several different fields, each separated by a comma or any other mark character (@,#,*,.,;, etc).
Positional format is when we have a logical layout to the file that is based on the starting position and the ending position of the field. For instance: we have a file of 100 columns, where from column 1 to 10 there will be numeric data and it will be the equivalent to a primary key, from columns 11 to 50 there will be string data and it will be the equivalent to a description and so on and so forth.
To handle them, usually we get a single line of the file and then break it into several variables, according to the logical layout stablished previously. You can build an UBE that reads the file and then process each line. For each line, you have the data in the variables and then you can insert it into a z-file.
Again, you are not obliged to use it. We do it because it's very common around here (Brazil - we have this format as a standard format for electronic banking operations, such as paying supplyers or billing customers), people are used to it and we've built a tool that gives us power and flexibility to handle virtually any kind of layout.
3) It depends on how you are extracting the data from the legacy. If you have a flat file, you create a table convertion UBE from the flat file to the z-file. If you have data into a table outside JDE, you can create SQL (outside JDE, also) to handle the data and get it into the Z-file.
4) Again, it depends on the way you are extracting data. Usually, you modify your legacy programs to handle this control.
5) JDE's tables, in a last instance, are database tables into an Oracle, SQL Server or DB2 DBMS. So you can handle JDE's tables at the DBMS level fine. What you can't do is handling external tables from inside JDE, because it doesn't see those tables, only the tables created into JDE.
So, yes, you can create a trigger into an external table and make it populate an JDE table after any operation is performed. Please, do it carefully and only populate temporary tables such as the z-files, do not populate a transactional data table.
For instance: you have a system that must generate G/L records into F0911. You can build a trigger into your legacy system G/L table that after any operation will populate F0911Z1. Once the record is in it, it's just a matter of running the UBE that gets data from F0911Z1 to F0911.
Hope it helps.
Best.
