One Star

TAdvancedFileOutputXML component hangs

Hello,
We are evaluating whether to use Talend on one of our projects. The prototype is being done in TOS DI 5.6.1. The goal is to extract a few tables from a database to generate an XML file. The XML is not the simple example that is given on the Talendforge tutorial, when one is shown how to generate a simple schema equivalent to a flat csv file. We need to generate multiple loops within loops, on many levels.
The only worthy example on how to do that that I have found is on Bekwam Blog. We have a similar schema (the category names are examples):
Company
     Loop on a list of departments (select from t_dept)
          Loop on a list of employees for each dept (select from t_emp)
               Loop on a list of addresses for each employee (select from t_adr)
          Loop on a list of printers
               Loop on a list paper_types
                    <etc>
                         <etc>
          <etc>
The "Multiple Loops" using TAdvancedFileOutputXML components approach described on the above page seems to be what we need. And to be honest I don't know of any other way to do that. But we are having a problem with the TAdvancedFileOutputXML component.
We have a requirement to use a standard xsd from the World Intellectual Property Organization, available at http://www.wipo.int/standards/XMLSchema/designs/st86model-V1-0.xsd. It is rather large (3154 lines and 716 occurrences of the "xs:element" string). I go to configure the XML tree, right-click on rootTag to "Import XML tree" and choose our "st86model-V1-0.xsd", with "Transaction" as the root. A couple of seconds later it is parsed and loaded, so this part is working fine. I have a small collapsed tree.


Then, since at this stage I will only be mapping 5 columns only, I need to delete parts of the tree. Whatever it is that I choose to delete, for example the "TransactionHeader" node, the treeview tries to *automatically expand* each node in the whole xsd tree. And probably refreshing every time it finds a new node. This xsd being huge, the TAdvancedFileOutputXML component simply loops forever. I tried many times deleting different nodes and every time I have to kill the GUI after 5 minutes. I brought it home to try it on a machine with an i7-920 with W7/64 and the x64 version of the GUI, same problem, killed it after 4 minutes.
We can't work with this component in this state. It must NOT try to expand the whole view if it can't handle it (and even if it can, it should keep its current state). It parses and loads the xsd perfectly the first time, so this doesn't look like a parser problem but more like a Treeview problem. The same thing happens with the latest milestone 6.0 DI, the base treeview component seems to be the same and set to auto-expand every node with full refresh upon delete as well.
So we can't use DI for this project until this problem is resolved, which I guess will not suddenly become a priority. Is there another way to generate an XML file with multiple loop-de-loops fed with data from many different tables?
Thanks.
2 REPLIES
Moderator

Re: TAdvancedFileOutputXML component hangs

Hi,
Could you please take a look at a related forum:https://www.talendforge.org/forum/viewtopic.php?id=31269 to see  if tFileoutputXML component is OK with you?
Best regards
Sabrina
--
Don't forget to give kudos when a reply is helpful and click Accept the solution when you think you're good with it.
One Star

Re: TAdvancedFileOutputXML component hangs

TFileOutputXML does not allow for input from more than one source nor the use of mapping nor an xsd. I suppose you meant TFileOutputMSXML. Thanks for the link, it does indeed show a new way (for me) to do things. But we still have the same problem. With the official xsd we have to work with, the component dies when we delete a node. It does when when we alt-tab out of Talend then come back in. The Treeview refresh when using a large xsd is broken in both components.
Not deleting the unused xsd elements results in an xml file containing all the unused fields with empty content, as if the overhead in xml wasn't atrocious enough. I will file a bug report.