Have you tried using the parameter value in a writer fan out?
The error message IndentationError: expected an indented block indicates that a code block (the definition of a function called output_folder in this script) doesn't have appropriate indentations. In Python scripts, indentations have to be inserted with strictly conforming to Python syntax specifications.
That is the direct reason for the error, but it doesn't seem to be necessary to define the function in this case. What do you intend to perform with this line?
def output_folder(feature):
Agree with Takashi, try removing line 5:
def output_folder(feature):
I remove the line "def output_folder" as suggested by @takashi and @david_r but it did not fixed the issue.
The problem is that featuretype is a list of tables read from another oracle table. I was first thinking of creating another column in the table MYTABLESLISTV that will contain the output folder for each oracle spatial object processed. Because I wasn't able do to that, I tried to write the above script.
Any thoughts?
I remove the line "def output_folder" as suggested by @takashi and @david_r but it did not fixed the issue.
The problem is that featuretype is a list of tables read from another oracle table. I was first thinking of creating another column in the table MYTABLESLISTV that will contain the output folder for each oracle spatial object processed. Because I wasn't able do to that, I tried to write the above script.
Any thoughts?
I noticed that the first line "import fmeobject" also could cause a syntax error, since the module name fmeobject is wrong. If you needed to use FME Objects Python API in a script, the module name should be fmeobjects, but you can remove the import statement in this case, because you don't use any API method.
That aside, from the script you have posted, it is supposed that you are going to perform this processing.
- Retrieve the value (a character string) of a user parameter called "featuretypes" which is defined before this scripted parameter, and save it as a Python variable called "feature".
- If the substring (starting at the position of index 10 and ending at the last) of "feature" is equal to "road", assign string+'\\shape' to "outptut_feature". Otherwise assign string+'\\mapinfo' to "output_feature".
- Return the value of "output_feature" as the parameter value.
Is it the processing that you actually want to achieve? If not, what do you want to achieve?
I noticed that the first line "import fmeobject" also could cause a syntax error, since the module name fmeobject is wrong. If you needed to use FME Objects Python API in a script, the module name should be fmeobjects, but you can remove the import statement in this case, because you don't use any API method.
That aside, from the script you have posted, it is supposed that you are going to perform this processing.
- Retrieve the value (a character string) of a user parameter called "featuretypes" which is defined before this scripted parameter, and save it as a Python variable called "feature".
- If the substring (starting at the position of index 10 and ending at the last) of "feature" is equal to "road", assign string+'\\shape' to "outptut_feature". Otherwise assign string+'\\mapinfo' to "output_feature".
- Return the value of "output_feature" as the parameter value.
Is it the processing that you actually want to achieve? If not, what do you want to achieve?
@takashi
Yes this what I want to do, and you are rigth There was a typo on the spelling of "fmeobject".
What you are saying will work is featuretype was constituted by only a table but in my case it has several tables.
Please could you have a look on the workspace that I uploaded, edit it and return it to me so I can see eactly what I'm doing wrong?
I remove the line "def output_folder" as suggested by @takashi and @david_r but it did not fixed the issue.
The problem is that featuretype is a list of tables read from another oracle table. I was first thinking of creating another column in the table MYTABLESLISTV that will contain the output folder for each oracle spatial object processed. Because I wasn't able do to that, I tried to write the above script.
Any thoughts?
1. You cannot access the user parameter named "featuretypes" now through the FME_MacroValues dictionary, since the "featuretypes" is not defined before this parameter now. At run-time, FME configures user parameters in the order that you defined in the Navigator of Workbench, so if you want to access "featuretypes" in the script for "output_folder", you should move the "output_folder" to lower position than the "featuretypes", like this screenshot.
2. I looked at the "featuretypes" script too, and guess that you intended to create a string consisting of one or more table names separated by spaces through the "featuretypes" scripted parameter. e.g. "table1 table2 table3". On the other hand, the "output_folder" script just determines if the substring of "feature" is equal to "road". If the result was unexpected, there is a logical bug even if there was no syntax error. What value should the script return if "feature" consists of two or more table names?
I remove the line "def output_folder" as suggested by @takashi and @david_r but it did not fixed the issue.
The problem is that featuretype is a list of tables read from another oracle table. I was first thinking of creating another column in the table MYTABLESLISTV that will contain the output folder for each oracle spatial object processed. Because I wasn't able do to that, I tried to write the above script.
Any thoughts?
Perhaps do you need to determine the output folder for each feature according to the source table name? If so, the Fanout Dataset option might help you, rather than scripted parameters. e.g. with this setting, the features from tables whose name ends with "roads" will be written into "shape" folder and others will be written into "mapinfo" folder.
1. You cannot access the user parameter named "featuretypes" now through the FME_MacroValues dictionary, since the "featuretypes" is not defined before this parameter now. At run-time, FME configures user parameters in the order that you defined in the Navigator of Workbench, so if you want to access "featuretypes" in the script for "output_folder", you should move the "output_folder" to lower position than the "featuretypes", like this screenshot.
2. I looked at the "featuretypes" script too, and guess that you intended to create a string consisting of one or more table names separated by spaces through the "featuretypes" scripted parameter. e.g. "table1 table2 table3". On the other hand, the "output_folder" script just determines if the substring of "feature" is equal to "road". If the result was unexpected, there is a logical bug even if there was no syntax error. What value should the script return if "feature" consists of two or more table names?
@takashi ,
Thank you very much for all your answers.
However, I was thinking of using the solution provided by a script instead of fanout.
As you mentioned, the scripted parameter feature returned the list of all the tables as a string but what I really wanted is that based on the name of each feature, I would like to have other constraints like a "where clause" and an output folder.
The fanout option - that you propose below - solves the issue of having an output folder for each feature. How can I solve the issue of the where_clause?
Keeping in mind that each feature is an oracle spatial object, let's assume that the feature that end with roads has a column entitled 'state' with the values 'paved' or 'unpaved' and I would like to extract only the road which a status equal to 'paved,.
Thanks
As an easy solution, I think you can use a Tester transformer to filter out unnecessary features - i.e. "unpaved" road features. Since the road features have "state" attribute storing "paved" or "unpaved", the condition for required features would be: the source table name does not end with "roads" OR the value of "state" is equal to "paved".
Alternatively, as a little bit advanced solution, the SQLCreator/Executor transformer might be helpful.
- SQLCreator: Retrieve the table names from the [TableName] table.
Tester: Branch the data flow into two streams according to whether the table name ends with "roads". Send the Passed features to a SQLExecutor (1), send the Failed features to another SQLExecutor (2).
SQLExecutor (1) -> writer feature type [shape]: Execute a SQL statement containing the where clause (state='paved') to read road features from "***roads" tables, and then write them into "shape" folder.
SQLExecutor (2) -> writer feature type [mapinfo]: Execute a SQL statement to read non-road features from other tables, and then write them into "mapinfo" folder.
SQLExecutor Parameters
- Combine Attributes: Keep Initiator Attributes if Conflict
Combine Geometry: Result Geometry Only
In this case, you can add an Oracle Spatial reader as a Workspace Resource in order to derive the destination schema from the existing database. And source table name - which will be used as the schema definition name and the destination feature type name in the dynamic writer feature types, can be propagated from the initiator feature for each SQLExecutor to the result features.
Regarding Workspace Resources, see these articles to learn more.
As an easy solution, I think you can use a Tester transformer to filter out unnecessary features - i.e. "unpaved" road features. Since the road features have "state" attribute storing "paved" or "unpaved", the condition for required features would be: the source table name does not end with "roads" OR the value of "state" is equal to "paved".
Alternatively, as a little bit advanced solution, the SQLCreator/Executor transformer might be helpful.
- SQLCreator: Retrieve the table names from the [TableName] table.
Tester: Branch the data flow into two streams according to whether the table name ends with "roads". Send the Passed features to a SQLExecutor (1), send the Failed features to another SQLExecutor (2).
SQLExecutor (1) -> writer feature type [shape]: Execute a SQL statement containing the where clause (state='paved') to read road features from "***roads" tables, and then write them into "shape" folder.
SQLExecutor (2) -> writer feature type [mapinfo]: Execute a SQL statement to read non-road features from other tables, and then write them into "mapinfo" folder.
SQLExecutor Parameters
- Combine Attributes: Keep Initiator Attributes if Conflict
Combine Geometry: Result Geometry Only
In this case, you can add an Oracle Spatial reader as a Workspace Resource in order to derive the destination schema from the existing database. And source table name - which will be used as the schema definition name and the destination feature type name in the dynamic writer feature types, can be propagated from the initiator feature for each SQLExecutor to the result features.
Regarding Workspace Resources, see these articles to learn more.
The FeatureReader could also be effective and easier. e.g.
or
If you use the FeatureReader, it's not necessary to add the Workspace Resource (Oracle Spatial reader) to the workspace, since the destination schema can be derived from the schema feature read by the FeatureReader.
Anyway, in my personal view, use of scripted parameters does not seem to be the best practice in your case.
