Migrazione da ODI11 a ODI12
Premessa:
Il tool di migrazione da ODI11 a ODI12 da noi sviluppato serve a risolvere alcuni problemi che tutti gli utilizzatori di ODI devono affrontare nel passaggio da ODI11 (Versione 11.1.6 , 11.1.7) a ODI12 (Versione 12.1 , 12.2) .
Quando un cliente decide di fare l’upgrade di ODI da una versione all’altra è obbligato ad eseguire un applicazione fornita all’interno del Prodotto, che si chiama Upgrade Assistant (UA), che si occupa di aggiornare tutte le strutture di sistema e all’interno del database, che la versione precedente di ODI utilizzava, e che quindi dovranno essere aggiornate durante il passaggio alla nuova versione.
Problema:
Di tutte le attività che esegue l’UA, quella che interessa particolarmente è l’aggiornamento del repository di ODI.
Durante questa fase l’Utility Oracle si comporta perfettamente in quasi la totalità del Repository. Solamente nella traduzione delle Interfacce di ODI11 in Mapping di ODI12, crea molta entropia sia a livello di oggetti creati come ODI Mapping/Reusable Mapping che dovrebbero sostituire le Interfacce ODI, che a livello di gestione degli ODI Models e degli ODI Datastores. (Le Interfacce in ODI11 e i Mapping in ODI12 sono la parte più corposa e fondamentale dei repository ODI, dato che contengono la logica delle trasformazioni che vengono effettuate sui dati).
Per riassumere in punti sintetici i problemi riguardanti questa parte, di seguito un elenco:
- Interfacce Temporanee (dette anche gialle) , vengono tradotte con i Reusable Mapping (Interfacce Temporanee e Reusable Mapping possono anche lontanamente assomigliarsi, ma hanno una logica di utilizzo completamente diversa)
- DataStore Target delle Interfacce Temporanee, che in ODI11 esistevano solo all’interno delle interfacce, vengono creati all’interno di nuovi ODI Models (questo perché in ODI12 ogni Datastore deve esistere fisicamente nel Repository a livello di ODI Models)
- Gestione dei Knowledge Modules:
o in ODI11 ogni Interfaccia normale e temporanea, utilizza Integration Knowledge Module,nel 90 % degli utilizzatori ODI questi Knowledge Modules sono customizzati.
o in ODI12 viene privilegiato l’uso di Knowledge Module interni, non custom perché nascosti all’utente, e per le interfacce Temporanee, in cui è possibile settare un Knowledge Module custom, una volta tradotte con i Reusable Mapping, non sarà possibile effettuare lo stesso settaggio perché nei Reusable Mappings non è permesso il settaggio di Knowledge Module.
Soluzione:
Con il nostro tool, realizzato completamente con classi SDK, sia per leggere i dati sorgenti del Repository di ODI11 sia per scrivere i dati all’interno del Repository target di ODI12, è possibile:
- la migrazione di interfacce normali/temporanee in ODI Mappings senza dover utilizzare i Reusable Mappings.
- Integrazione di interfacce temporanee utilizzate in interfacce normali in un unico ODI Mapping che contiene tutto il flow.
- Mantenimento dell’attuale gestione dei Knowledge Modules con tutti i relativi settaggi esattamente come in ODI11.
Se siete interessati al servizio qui indicato o se avete delle altre esigenze da comunicarci, di seguito trovate i nostri contatti:
e-mail: Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.
Telefono: +39 02 89500080
Cellulare: +39 348 6979791