We are using a jdbc:inbound-channel-adapter with a poller to select from a table. The requirement is to select rows with a timestamp within a specific range. That range must be updated each time the database is polled (so rows are not read twice). Originally I envisioned having a separate table to store a datetime, and use the adapter's update attribute to update this table. This value would then have been used in the SELECT statement defined in the query attribute, as part of the WHERE clause against the main table.
We have now been told that while we will have read access to the main table, we will not be given permission to add anything to the existing schema, or have write permissions. This rules out using a separate table in which to continually update the timestamp used by the main SQL query.
The option of defining in the query attribute some SpEL which would return a dynamically generated SELECT statement will also not work. This is because the SpEL will only be evaluated once when Spring loads.
Is there another way to dynamically update the SQL in the query attribute?
Otherwise, what is the correct strategy for this use case, where the SQL which is used by the adapter must change each time the database is polled?
Thanks
You can add a parameter source to the adapter and use queries like:
"SELECT * from FOO where KEY=:key"
See attribute select-sql-parameter-source.
You can write your own parameter source, but also see ExpressionEvaluatingSqlParameterSourceFactory.
Related
Does anyone know a way to force a child table to update from the source table? it would be a one off command to run when the child table is created, then we have an auto update policy in place.
Googling suggests to try this, however it produces a syntax error
.update policy childTable with (sourceTable)
Thanks!:)
Update policy is a mechanism that works during the ingestion and does not support backfill.
You can consider using materialized view with backfill property (if your transformation logic falls under the limitations) or create the child table based on a query, using the .set command.
If your source table is huge you might need to split it to multiple commands.
We had to use this:
.append childTable <| updateFunction
Also posted on super users:
I'm a spotfire novice trying to create a parameterized info link. Ultimate goal is to create a default template that may be customized to return specific rows in a very large table. I've not been able to cobble together enough information from online searches to get me from point A to Z.
Spotfire version is 7.11 on an Oracle 11.2 SE DB.
Currently I've got a date/time prompt in the info link that will be global to all users. What I need is to be able to further filter to 1 of 2 columns (one is real, the other a string) in order to minimize loading times. There are 17 other on-demand tables that are related to the main one. Limiting the initial query will greatly speed up performance.
In information designer for the information link, if I edit the SQL in the WHERE and explicitly define the value or string for the column, I get the rows I want. When I try to define it using an input parameter (?ParamName), I either get nothing when I reload or get asked to input a parameter "for testing".
Q1: In the document properties for the analysis, I've been adding in properties that I assume is supposed to get picked up by the query.
- What part do scripts play in passing this variable to the SQL?
- Do I just need to define a value for a property name or include a IronPython script? - If script is required, can I just define the parameter to pass?
Q2: In the info link SQL, what is the correct syntax for defining the parameter variable depending on the type (real v string)? If I use a string, I need to include LIKE in order to pick up the desired rows. If I use a real, is it possible to define it as a list of values?
Thanks in advance.
Though not exactly clear from your description, I think you should be able to accomplish your goals using the "Load on demand" dialog that is accessed either when you add your data table to your analysis, or subsequently using the Data Table Properties>Type of Data>Settings dialog.
Spotfire uses this dialog to dynamically modify your SQL. Thus, you do not need to explicitly include the LIKE statement in your SQL. Spotfire will add it in based on what you define in the On-Demand settings. For example, you could have an Input Field where you type a constraint that will be stored as a Document Property and then refer to that Document Property in your On-Demand settings to control the table loading.
Like I know, I can use SearchRestrictions to restrict get operations. But what about insert_update? For instance, I want to remove an opportunity to insert Products with CHECK approvalStatus.
Search restrictions don't work like that. They restrict queries that are made against the database. How? The condition you add to a search restriction is added to the where clause of the select statement of the query. An INSERT query does not have a where clause. At least not those, that are generated when using impex.
Also impex is not the right tool for your purpose. Impex should only be used to import flawless data. It is just a simpler way of inserting data into a database, just like an insert statement in sql. You don't want data in an impex file that needs further checks.
Just filter those lines, that have undesired values. Then you can import the rest.
I currently maintain rfc function modules to be called via Java Connector for SAP. My current module returns a table of documents, where each line has some data and another table of items.
When introspecting this module via JCo 3.0, it does only show the top layer table, but not the one inside:
POSITIONS () (com.sap.conn.jco.JCoTable)
introspection errror
java.lang.IllegalStateException: Trying to access row values in a table
which does not have any rows yet
The inner table is defined. For performance purposes, I enabled the module to use basXML.
How can I enable JCo to work with nested structures? Or is this not possible?
In general this works. JCo is capable of dealing with nested structures and tables.
In this case your nested JCoTable simply seems to be empty, i.e. it has no rows.
On an empty table you cannot call any getter- or setter-method for a single field.
Simply check with JCoTable.isEmpty() or with JCoTable.getNumRows()>0 before using any getter-method. And make sure to append at least one row with JCoTable.appendRow() before using any setter-method on a JCoTable object.
I have a case in my customisation project, were I have a PXSelector that I want it to solely act as a lookup, and would not like the users to input any data via the selector and create new records.
I could not find a way to limit this from the attribute itself, therefore I tried to limit it from the events that the control fires. The idea was that in the FieldUpdating Event I would verify whether the value inserted by the user can be found in the selector's key column, if not I would revert it back to the old value. The problem was that cancelling the event had no effect on the selector and since I did not know what the previous value was, I could not revert it back manually.
It sounds like you are trying to use a filter. You need a PXFilter view which then could be used to display data in a grid for example.
You can search the source for "PXFilter to find good examples. One I found is APVendorBalanceEnq which uses public PXFilter<APHistoryFilter> Filter
PXFilter views are not committed to the database. Typically you would create a new DAC for the filter based on your needs but you can use existing DACs that are bound to tables without the fear of the data making it to the database. With the filter you simply use the field values rather than load records into the view.