OWB to ODI migration service presentation

Editor's Notes

• #6: The owb2odi converter is a semiautomatic tool developed by D&T and its goal is to speedup the migration process from OWB to ODI. The migration process can take place at customer side or in outsourcing. Tipically we perform the migration in outsourcing.
• #7: Owb2odi converter analyze OWB’s design metadata and through many alghoritms transform these metada in ODI metadata. Supported versions are: every owb version and every odi version (included 12c)
• #8: The typical conversion scenario is that we acquire OWB mdl file, we import it locally and we perform the extract process to get and store OWB’s metadata. We then anlyze that metadata and perform the migration. Finally we release the converted odi xml files and we install them into client env
• #9: Owb to odi converter is composed of 3 main components: the firt one is a TCL script that runs OMBPLUS script to reach OWB metadata and staging them to a database schema. Then second component, a java component, perform the real conversion on previuosly exported metadata. Finally, those changed metadata are used as input to a set of classes that used ODI SDK to create ODI objects
• #10: So the converter will create: an ODI equivalent project. From location we will have odi topology logical schema and other topology needings From each owb module an equivalent odi folder And from mapping we will have different objects depending on the ODI version: on ODI 11 a package with one or more interfaces, on ODI 12 a package with a single mapping rappresenting the whole owb mapping
• #11: So, since ODI 11 has a lot of differences with OWB, the converter has to manage many aspects. It has to split flow mapping when loading several tables and also it has to split the mapping in some particular mapping design to garantee the correctness of the sql generated. Many are the combination of operators that need the mapping to be splitted and we choose to use temporary interface as derived sql query to garantee a successful conversion
• #12: Obviously with ODI 12c is much easier because of the introduction of the components. So the design of ODI mapping is very similar to OWB. But it is not exactly the same. Indeed you cannot use one component table to perform a set operation (with owb you can) and also every component must be reached by a single component (and with owb you can). So in some mapping the converter will perform a bit of rework.
• #13: As i said our tool is semiatumatic. When we first started developing this tool on 2008 we analyzed if this tool should be fully automatic or not. We eventually realized that, since OWB and ODI have big differences on fundamentals aspects, the customer need to be guided to reach what they realy want in the new platform. So after the extraction of owb metadata we stop the execution of the tool and organize some assessment meeting with the customer to define TOPOLOGICAL aspects and other customizations they need
• #14: So during the assessment meeting all the aspects about location and how to represent them in odi are managed. This phase is essential because you cannot alsways understand the overall architecture simply looking at the locations. Often you’ll need that client explains and translates for you some of this information such as server naming conventions and many other aspects so that you can build correctly the odi topology. And with a correct topology definition you have good fundamentals
• #15: The second reason for having a semiautomatic tool is about the datastore management. In real world project you often have mapping with NOT BOUND operators. So this operators are not directly associated with imported tables o view. For example you may have an NOT BOUND operator that doesn’t even exists in OWB repository. So potentially owb repository could be not enough to get all datastore informations. For this and for other problems regarding owb ynchronization with underlying structures, we decided to manually reserve the datastore. This approach allows also the customer to reorganize the datastores in different models and submodel hierarchy
• #16: Finalluy the thirs reason for the semiautomatic approach: KM settings. Indeed, during the assessment meetings, it is possible to define which KM to use on the mapping. Obviuosly we define our standard matrix of combination for KMs and mapping, but this schema can be changed considering customer needings and considerations. So, after the conversion, you have a set of ready to run mappings with a very little need of fixing
• #17: So , regarding the overall conversion process, you can have a big speed up on undestanding the architecture, on migrate the objects and also on debugging the resulting conversion because we realese the project only after only that every mapping runs without any syntactic error
• #18: What about timing: within a couple of days we can procude a report regarding the estimated time of conversion Tipically a couple of assessment meeting are necessary to define the details of the projects and finilaly we can provide the resulting project within 5/10 working days depending on the size and cardinality of the projects. Anyway we release the full project after that every mapping is executable without any syntactic error and is ready to run.
• #19: A typical architecture scenario is composed of a jo scheduler and a Warehouse builder installation that perfom mapping design and also mapping execution through process flow. Or, in legacy systems, the flow could be arranged with Oracle workflow
• #20: So a possible resulting architecture could be something like this: ODI will implements all the process management through loadplan and scenarios. Or ODI will simply contains scenario code but the workflow is delegated to BPEL or other work flow manager.
• #21: Finally one of our sucess story. Is about Pirelli EDW, composed of 2300 mappings, 400 oracle work flow. Through the converter we converted all the mappings and we manually created odi load plan as replacement of al oracle work flows. We spemt about 1 month for the mapping conversion and 3 mounths for load plan implementation and testing.