Lizabeth, I don't think you can set these relationships in the interface tables. You may have to import all your requests, then set the relationships by adding the appropriate rows to the KNTA_REFERENCES table and flushing the caches.
Thanks Eric, but then there would be a lot of manual insertions.We have a large amount of data and inserting rows for each child would take a lot of effort, and would call direct insertions to the Database.
I was thinking if we could create all Child And Parent Requests (through Interface tables) and manually add the Children too the Parent through References and selecting Add Request( Existing) as the option, the advantage being we would not have to update the tables directly.
However, I was concerned if this solution gives exactly the same mappings, (in the database tables or otherwise) to the Requests which are created through Workflows( Execution Step - Create Requests).
Sure, you could do that. But if you're importing say hundreds of requests, that sounds like much more work than doing an Insert-Select into KNTA_REFERENCES to create them, especially if you have some way to determine the parent-child relationships by other fields in the requests.
In any event, the references created are the same either way.
We are having some issues Converting Data from Interface tables. I would appreciate if someone can help us.
1. We are inserting values in Table Components and even though the kcrt_table_entries_int has data after we run our scripts, Data is not populated in kcrt_table_entries, when the report is run, and is thus not seen in the UI too.
2. I am using a user defined validation but get the error 'Error: CRTI_PARAMTER_NOT_FOUND_IN_LOOKUP: Parameter QA not found in Lookup for Lookup type USG - Work Group' after running the report. I have checked the code and the meaning both exist in the validation for the values( here 'QA') that I am passing.
1. I fixed the issue, The Documentation (Open Interface tables) was incorrect, The Parent and the Transaction Id had different values.
2. Yes It Does Exist. Infact I also checked by joining appropriate indices from Parameter_Set_Contexts,knta_parameter_sets and knta_parameter_set_field and the validation_id that we are using.All values do map to the same Context Value' Request Id' that we are using.
What I was wondering was (1) if the "QA" value was Enabled, and (2) if the KNTA_LOOKUPS.LOOKUP_TYPE = KNTA_VALIDATIONS.VALIDATION_NAME. If you ever changed the validation name, LOOKUP_TYPE might now be different and sometimes this causes errors or unpredictability...?
I did not change the name, and moreover if it was the knta_lookups would not have reflected the value, as per what I understand if the validation name is changed the knta_lookups does not reflect it and needs to be manually updated.