Testing an ODI interface, especially when there are tens of tables joined at the source can get very tedious at times. Finding simple errors like missing parenthesis or missing expressions can lead to headaches or sleepless nights.
I am putting some of my experiences here, and suggesting a few ways to make life better.
1. Make sure Source data is not having whitespaces before you start developing, if source tables are not trustworthy, use the LTRIM and RTRIM functions
2. Unix based text files have different line feed characters than Windows based, always make sure you know the source.
3. Sometimes the data might contain hidden characters , example, when you retrieve a number 'value' say 10, it will show you 10, but use the function TO_NUMBER(value) and it will give you an error saying invalid number, why ?? because there is a LF character ASCII code 13 after 10 which is not visible to naked eye.
4. Do not develop the interface completely and test its working in one go, there are so many things that might have gone wrong, but ODI will give only one error that it encounters, best way is to run the interface after every mapping (or maybe two) and you will get the errors then and there, although time consuming, it works.
5. Use the Active Mapping checkbox often while testing, disable a mapping and check if interface runs, the enable the mapping and check what happens. This helps in tracking erroneous mappings faster.
6. Always create a copy (duplicate) when doing major changes to interface, we tend to forget what was done before
7. Set 'Delete Temporary Objects' to false, this helps in having a look at what happens behind the curtains, and its an effective way to find out errors
8. Run the code generated by ODI at runtime (in operator window) in SQL developer or similar tools, ODI will not give you the exact line where error is encountered, but SQL editors give.
Hope these pointers help, will add more as I experience
I am putting some of my experiences here, and suggesting a few ways to make life better.
1. Make sure Source data is not having whitespaces before you start developing, if source tables are not trustworthy, use the LTRIM and RTRIM functions
2. Unix based text files have different line feed characters than Windows based, always make sure you know the source.
3. Sometimes the data might contain hidden characters , example, when you retrieve a number 'value' say 10, it will show you 10, but use the function TO_NUMBER(value) and it will give you an error saying invalid number, why ?? because there is a LF character ASCII code 13 after 10 which is not visible to naked eye.
4. Do not develop the interface completely and test its working in one go, there are so many things that might have gone wrong, but ODI will give only one error that it encounters, best way is to run the interface after every mapping (or maybe two) and you will get the errors then and there, although time consuming, it works.
5. Use the Active Mapping checkbox often while testing, disable a mapping and check if interface runs, the enable the mapping and check what happens. This helps in tracking erroneous mappings faster.
6. Always create a copy (duplicate) when doing major changes to interface, we tend to forget what was done before
7. Set 'Delete Temporary Objects' to false, this helps in having a look at what happens behind the curtains, and its an effective way to find out errors
8. Run the code generated by ODI at runtime (in operator window) in SQL developer or similar tools, ODI will not give you the exact line where error is encountered, but SQL editors give.
Hope these pointers help, will add more as I experience
No comments:
Post a Comment