fme_dataset and fme_basename attributes are there when read normally, but not when read with a FeatureReader.
If you're trying to read any of these eleven formats with the FeatureReader then unfortunately the attributes fme_dataset and fme_basename are not added in FME 2017+:
CAT, DGNV8, DGNV8XFM, FMW, GG, MGE, NTX, SCHEMA_FROM_TABLE, SEGY, SPATIALWARE, STL
However, there is a workaround - insert
READER_META_ATTRIBUTES fme_feature_type fme_dataset fme_basename
at the very top of the header (go to Tools/Edit Header... in Workbench).
If you find these attributes missing with any other format via the FeatureReader or the above work-around doesn't help then please let us know at https://www.safe.com/support/report-a-problem/ This problem is being tracked in FMEENGINE-62624.
A related question.
In most formats, you can read "fme_basename" and "fme_dataset" with a FeatureReader by selecting them through the Additional Attributes to Expose parameter in the reader parameters.
It's good but then the schema feature output from the Schema port of the FeatureReader would contain those attributes in the schema definition (attribute{} list).
It's just annoying when configuring dynamic schema writer feature type using the schema feature as the schema source. You will have to remove them through the Attributes to Remove parameter in the writer feature type if you don't want to write them into the destination dataset, and I think you don't want to write them usually.
I don't know any advantages for that "fme_basename" and "fme_dataset" would be treated as user attributes in the schema feature when the user selected them as Additional Attributes to Expose.
I suggested that "fme_basename" and "fme_datasete" should not be added to the attribute{} list (I forgot the case number), but there seems to be no change so far.
Why are "fme_basename" and "fme_dataset" treated as user attributes in the schema definition?
I ran into the same problem but cannot solve it the way @takashi proposes. Unfortunately the Additional Attribute option is not available when reading CSV...
The solution of @danatsafe doesn't work either. I added the line like this:
#! START_WB_HEADER
READER_META_ATTRIBUTES fme_feature_type fme_dataset fme_basename
READER_TYPE MULTI_READER
MULTI_READER_TYPE{0} ORACLE_NONSPATIAL
blah blah blah
but as soon as I close (of course clicking 'OK') and reopen the Header Editor, the line is gone.
Any other suggestions I can try?
I ran into the same problem but cannot solve it the way @takashi proposes. Unfortunately the Additional Attribute option is not available when reading CSV...
The solution of @danatsafe doesn't work either. I added the line like this:
#! START_WB_HEADER
READER_META_ATTRIBUTES fme_feature_type fme_dataset fme_basename
READER_TYPE MULTI_READER
MULTI_READER_TYPE{0} ORACLE_NONSPATIAL
blah blah blah
but as soon as I close (of course clicking 'OK') and reopen the Header Editor, the line is gone.
Any other suggestions I can try?
Hi @westerbrink The start of your header should look like this:
READER_META_ATTRIBUTES fme_feature_type fme_dataset fme_basename
#! START_WB_HEADER
Hi, any status on this? Getting fme_dataset and fme_basename works on ALL formats and BOTH Readers and FeatureReaders?
I have an excel file I am reading and if I expose the attributes in the Reader Feature Type they come into the workspace fine, but if I use an AttributeExposer to bring in fme_basename and fme_dataset, the values are exposed with a Null Value. I can't understand how this issue was developed.
I am using FME 2021.1 (data interop license) and trying to read all files with a .jpg extension in a folder. Ideally I want to use a feature reader so the user just has to select the folder path, and not worry about adding the /.jpg* onto the end.
When using the feature reader I can't expose fme_basename which is an essential part of the workflow. I can view it in the table and features, but can't use it in any transformers. Changing my header didn't do anything.
I am using FME 2021.1 (data interop license) and trying to read all files with a .jpg extension in a folder. Ideally I want to use a feature reader so the user just has to select the folder path, and not worry about adding the /.jpg* onto the end.
When using the feature reader I can't expose fme_basename which is an essential part of the workflow. I can view it in the table and features, but can't use it in any transformers. Changing my header didn't do anything.
Hi @kaz there's a couple ways to get this working.
You could use the Directory and File Pathnames Reader and then use a Tester to filter out only file paths that have a jpg extension, and then feed these values into the FeatureReader.
Alternatively, you could setup a file/url User Parameter with the name Folder_Select that the user can use to select a folder path. Then in the FeatureReader we can use the value $(Folder_Select)\\*.jpg for the Dataset location. This will use the folder the user selected to retrieve all jpg files without the user needing to add *.jpg at the end of their folder location every time they run the workspace.
Let me know if you need any more help!
Hi @kaz there's a couple ways to get this working.
You could use the Directory and File Pathnames Reader and then use a Tester to filter out only file paths that have a jpg extension, and then feed these values into the FeatureReader.
Alternatively, you could setup a file/url User Parameter with the name Folder_Select that the user can use to select a folder path. Then in the FeatureReader we can use the value $(Folder_Select)\\*.jpg for the Dataset location. This will use the folder the user selected to retrieve all jpg files without the user needing to add *.jpg at the end of their folder location every time they run the workspace.
Let me know if you need any more help!
Thanks for the idea @danminneyatsaf
I used the File Pathnames Reader to read everything in the folder, Testfilter to filter out JPGs, then featureReader to read each .jpg file
By setting accumulation mode in the featureReader to 'merge initiator and requestor' I was able to keep the original file paths/names without needing to expose the fme_basename attribute (the original problem)
Great solution, thanks!