In our environment, we have created multiple projects in Information
Steward 4.0 connecting to SAP ECC system as the backend. Also we have
configured a failed repository database which is Oracle 11g. We want to
report the failed data via Web Intelligence reports with universe
created in Information Design tool. But we have few queries without
which we are unable to proceed on our critical tasks. Any urgent help
on this will be highly appreciated.
What is the naming convention for the tables that are created? Is it
specific to the type of failed repository database like different for
MS SQL server, Oracle etc
Whenever we run the rule , is the data inserted in the same set of
tables? What is the exact procedure for it? Are the tables dropped and
then re-created and then data is inserted again or are the tables
truncated and fresh data is loaded everytime when the rule is run
Is there any setting in CMC or some config file that can be modified
to change the name of the failed tables created
Is it possible to modify the table names via Information Steward
dynamically after the rules are run?
We want to report this failed data via Web Intelligence reports
created via BO 4.0 (BI launchpad). But we did like to know that are
these failed environment specific i.e. different tables will be created
in DEV environment and in QA environment. Supposingly we migrate the
project from DEV to QA (export rules and views) and then we did like to
move the universe and reports as well via LCM tool in BO, will they be
applicable in QA as well i.e. failed data tables created same
irrespective of environment.
We did observe in our DEV environment that sometimes when we ran the
same rules, different tables were created for failed data. This
happened 2-3 times. Can this be explained as to under what scenarios
this might happen? After that now whenever we have run the same set of
rules, the same table is getting created and data is getting inserted.
Please explain.
In the Information Steward User Manual section 3.12.5 Viewing failed rule data contains the description of the table names and what is included there. Should be same for all database systems.
The data is not stored historically so for every new execution the table is refreshed (not sure if really droped or only truncated.
You can not change the name.
No
As syntax for names (see documentation) should be <source_table>_ <source_connection>_ <source_db_username>_failed_data if these parameters remain same, from theory perspective a universe on top of theses tables should work.
Niels
P.S.: Watch out for Information Steward 4.1 planned to be RTC / Begin of Ramp-Up end of May 2012, where we have extended the Failed Record database schema and also some managmement around the tables itself.
Hi Neil,
Thanks for the reply. Please find my comments below:
In the Information Steward User Manual section 3.12.5 Viewing failed rule data contains the description of the table names and what is included there. Should be same for all database systems.
MINAKSHI: I have read in one of the documents that table names created are different for different backend systems.
The data is not stored historically so for every new execution the table is refreshed (not sure if really droped or only truncated.
MINAKSHI:I wanted to understand if the table is dropped or truncated. I could not find anywhere how exactly Information steward works.
You can not change the name.
MINAKSHI: Ok. Could there be a possibility in future to bring this functionality.
No
MINAKSHI: Ok
As syntax for names (see documentation) should be <source_table>_ <source_connection>_ <source_db_username>_failed_data if these parameters remain same, from theory perspective a universe on top of theses tables should work.
MINAKSHI: We have tried and tested this in our environments. Even if the connection names are same, different failed tables are created in our DEV and QA environments. Hence we are facing issues while creating universe since we will have to create universe in QA again if the table names are different. This is where we are stuck currently.
(BOB member since 2008-08-05)
(BOB member since 2008-11-05)