Generic dynamic reader: Attributes missing

Hi

 

 

You've hit upon the sometimes frustrating difference between run-time and design-time attributes. When using "traditional" readers, the Workbench will automatically expose (make visible) the attributes made available by the reader to the follwing transformers etc.

 

 

When using a dynamic schema, this doesn't happen automatically, since the Workbench GUI doesn't know which objects might or might not pass through. So you will have to design your workspace to be "attribute-agnostic".

 

 

How you do this will vary depending on which transformer you use, e.g. some transformers write out their results in attributes with a constant name, so those are easy to use later on. For other cases you can use the AttributeExploder to split your features up in to key/value pairs and treat them sequentially. This will let your transformers know about any attributes that are only available at run-time.

 

 

Another more powerful, but also more complicted option is to use the scripting abilities in FME using e.g. Python. The excellent fmeobjects module will let you iterate over attributes and manipulate them in a very dynamic fashion that lends itself well to the dynamic schema concept.

 

 

David

 

As David says, the dynamic schema - because it isn't predictable - isn't exposed automatically in Workbench and won't appear in the table view in the DI (although the attributes are there, as you can see by querying a feature).

 

 

If you're going to be testing a specific attribute (say, does this dataset contain an attribute called 'abc') then use an AttributeExposer transformer to expose 'abc'. Then use a Tester to test 'Attribute is Missing'.

 

 

If you want to write out the data - regardless of schema - then you'll need to add a dynamic writer to the workspace. That will handle any data that the dynamic reader reads.

 

Apart from scripting there is a workspacerunner contruction to do this.

 

Involves attribute exploding/listbuilding and filewriter. A WSR to read the written file.

Thank you very much for your answers!

 

 

Since I need the original attributes only to indicate which features are affected by the Errors, the solution of Mark seems to be the easiest one. Between the generic dynamic Reader and a CSV-writer, a chain of transformers lies between that ends with loggers. What kind of CSV file definition do I have to set, so that the resulting csv writer includes the original attributes of the reader plus the additionally created ones by the transformes? Automatic or dynamic (advanced)?

 

 

PS: Is it possible to deactivate the built-in spell checker? It always tries to change the English words to German.

 

It works when the reader is set as being dynamic and when "Select all" is chosen in the "select Schema sources items"-dialog. Thank you very much.

Would it be possible, in this dynamic and generic environment, for the user to select an attribute that he wants to be processed? Like using an ATTR_NAME type user parameter?