Question

xml text handling instead of xml reader

  • 26 January 2017
  • 7 replies
  • 5 views

Badge +1

Hello all,

I am struggling with handling xml-data.

I have a xml file that is easy to read using the XML-reader (feature paths, elements to match).

Now I have fetched the same data dynamically in an attribute using a http-caller, but i cannot get the file split up in features and attributes as I can with the XML reader

I can't get the XMLFlattener to get it, and with the xml-fragmenter I managed to get the different features, but can't get the attributes right.

Probably (or hopefully) I am overlooking something simple. I hope anyone has any ideas / tips

Regards,

Steven


7 replies

Badge +22

The XMLFragmenter has similar to attribute handing properties as the XMLReader. What is the issue you are having with the attributes?

Badge +6

One approach is to use the XML Reader to build a feature path / query string using its 'elements to match' tree control (new in FME 2016). In this case, for your xmldata.xml file, I used the tree control to select "meting" which gave me a feature path of "metingen/meting". You can copy and paste that into the 'elements to match' parameter in your XMLFragmenter. Placing the XMLFragmenter after the HTTPCaller will allow it to make multiple features from each response xml string depending on how many "meting" elements the response contains. If you only expect a single feature per result you can use XMLFlattener. Note that both XMLFragmenter and XMLFlattener flatten nested elements into attributes by default using parent.child notation.

One consideration is that XMLFragmenter does not automatically expose any of these new attributes. To work around this, add an AttributeExposer after the XMLFragmenter and use the 'Import' button at the bottom. Select the XML reader and the same file / feature path you used in the XML reader before. You can import all the field names on to your schema here so you don't need to type them.

Note that the XML Tutorial reader config article will give you a good idea of how to config the XMLFragmenter since it is essentially an XML but without the the tree control - see: https://knowledge.safe.com/articles/29322/xml-reader-configuration.html

Badge +1

Hello Dean and jdh,

Thanks for the tips. I found the featurepath metingen/metingen myself, so I was on the right track ;-)

I expect to get one feature type, with multiple features, so I guess I'll need the XML Fragmenter.

I will try and use the AttributeExposer as suggested and look into the article mentioned.

Challenge I will have to face is, that in the moment, the structure of the expected xml is clear (i.e. never changes) but different attributes can occur. I guess that can cause problems in using the 'Import' within AttributeExposer.

 

Enjoying the quest for a solution,

Regards,

Steven

Badge +1

Just a quick train of thoughts:

Could I write out the xml-file before using the XMLFragmenter and use that file to reference in the 'Import' button in AttributeExposer?

Badge +16

Just a quick train of thoughts:

Could I write out the xml-file before using the XMLFragmenter and use that file to reference in the 'Import' button in AttributeExposer?

You can just copy paste the xml into a file save it and used that for the import.

 

 

Badge +1
You can just copy paste the xml into a file save it and used that for the import.

 

 

Hi Itay, Thanks for the suggestion. Actually I am looking to do this in an automated process. I collect xml data with a http request an have to manipulate it. The contents of the xml (attribute-wise) isn't predefined. I like to try and keep it in one process as much as possible.

 

 

Badge +6

Just a quick train of thoughts:

Could I write out the xml-file before using the XMLFragmenter and use that file to reference in the 'Import' button in AttributeExposer?

Unfortunately the AttributeExposer Import option is not live. It requires user intervention to populate it. So file write / read back likely won't help in this case. That said, any attributes created by XMLFragmenter are still there, so you really only need to expose those attributes that are needed within the workspace (IDs etc). Attributes that are returned by XMLFragmenter, are missing on the schema, but still exist on the output feature type will still be written out.

 

 

Reply