Aujourd’hui voici le cas d’une erreur que j’ai rencontrée durant une migration OWB vers la version 11.2 et qui m’a donné du fil à retordre …
L’objet de cet article n’est pas de vous détailler tout le processus de migration mais plutôt de vous montrer l’impact du nouveau système de contrôle des options utilisées dans la version 11.2 d’OWB.
Ceci nous donnera également l’occasion d’utiliser le mode debug d’OWB et de nous pencher sur l’option Oracle Data Integrator et ce qu’elle implique durant la migration …
Vous savez sans doute que la licence OWB comporte 2 volets depuis la version 10.2 :

• Des fonctionnalités de base incluses dans la licence de la base de données

• Des fonctionnalités avancées qui nécessitent d’acquérir l’option Data Integrator Enterprise

Tout ceci est parfaitement décrit sur OTN et je vous invite à la lecture du white paper cité sur la page qui donne la liste par version des fonctions soumises à la licence ODI.
Notre version OWB était 11.1.0.7 et son référentiel se trouvait dans une base de données 10.2 à la suite d’une précédente migration vers OWB 11.1 qui nous avait permis de conserver le référentiel sans upgrade de la base.
Cette fois nous migrons la base de données en 11.2.0.3, il n’y a pas le choix, la version d’OWB doit suivre !
Dans la version 11.2 d’OWB, il existe désormais un système qui vous empêche d’utiliser une fonctionnalité (par exemple les pluggable mappings) pour laquelle vous n’auriez pas explicitement déclaré avoir acquis l’option correspondante (aka ODI EE)  dans l’assistant de repository que nous verrons plus bas dans cet article.
Dans ce cas vous obtenez l’erreur OWB-00505 :

Alors migrons !

Grâce à ce white paper nous avons réussi (laborieusement) à migrer le référentiel dans la base 11.2 après quelques agaçantes erreurs Java « Out of memory » et autres MDL-1261 : error import mapping NULL durant l’import du référentiel.

• La première erreur a été résolue simplement en modifiant le paramètre Xmx de la JVM dans le fichier $OWB_HOME/bin/owb.conf :

AddVMOption -XX:MaxPermSize=256M
AddVMOption -Dnative.canonicalization=false
AddVMOption -Xmx1024m

• La seconde erreur était due à des mappings orphelins et a disparu avec la suppression de ces derniers du référentiel 10.2 d’origine.

Fort de ce succès, nous tentons de déployer un mapping depuis le centre de contrôle version 11.2 ou le client (owbclient.sh) !
Et là c’est festival, nous obtenons invariablement pour chaque mapping une superbe erreur RT-5161 :
RTC-5161: The Deployment cannot proceed because of an error during the generation or pre-deployment phase. Please review any previous errors. If the problem persists then please contact Oracle Support with the stack trace and details on how to reproduce it.

Il y a donc eu une erreur durant le pré-déploiement, mais alors laquelle car les phases de génération et de compilation passent sans problèmes ?
Et bien sûr, aucune information ni trace dans les logs OWB, juste la répétition du même message d’erreur RTC-5161 …. contact your Oracle Support …. ce que je fais …
Pendant que le support examine les fichiers de traces qui ne contiennent rien, je décide justement d’essayer d’en générer afin d’en savoir plus, il doit bien exister un mode debug dans OWB ?
Et bien oui, et il se configure dans le fichier $OWB_HOME/bin/admin/DebugUtility.properties dont voici un extrait.

# If false, no debug info is processed
#Debug=false
Debug=true
# If true, debug messages are logged
#LogDebug=false
LogDebug=true
# Output path for log file. (Escape backslashes)
LogFilePath=.
# Name for log file. Index (000-999) and extension (.log) will be postfixed
# by the utility (<LogFileName>.<index>.log).
LogFileName=Log
....
....
# Control specifications
#oracle.wh=false
oracle.wh=true

Modifiez a minima les propriétés Debug, LogDebug et oracle.wh pour leur donner la valeur true (n’oubliez pas de désactiver quand vous aurez terminé le debug !)
Vous pouvez changer si vous le souhaitez le nom du fichier de log et son emplacement, par défaut il s’appellera Log.000.log dans le répertoire courant soit $OWB_HOME/bin/admin.
Je relance un déploiement – même erreur – et je trouve un (petit) indice dans le fichier de log créé, il y avait probablement des options de debug plus pertinentes à activer mais elles ne sont pas simples à comprendre …

oracle.wh.ui.runtime.application.WHRuntimeCommandHandler@19b35853:
RT-INFO:Object UPD_LOG_TEST has no generated scripts

UPD_LOG_TEST est le nom de mon mapping.
Ce message « has no generated script » qui n’a a priori rien à voir nous a amené à nous dire – allez savoir comment :

Et si c’était un problème de licence ?

En effet, avant de migrer le repository, nous avions décoché toutes les cases dans l’écran « Enable Optional Features » du repository assistant et en particulier « Data Integrator Enterprise Edition » car le client n’a acquis aucune licence spécifique pour OWB hormis celle de la base de données.
Pour accéder à cet écran de configuration des options, il vous faut lancer l’assistant de repository par le script reposinst.sh qui se trouve dans votre $OWB_HOME/bin/unix (pensez à lancer un Xming sur votre poste ou un accès console graphique à votre serveur OWB).

Dans cet écran, choisissez l’option Managed Optional Features, notez au passage  la présence du choix Upgrade repository to current version of Oracle Warehouse Builder qui nous a permis de réaliser l’upgrade du repository de la base 10.2 vers la base 11.2.
Puis identifiez vous dans l’écran suivant en tant que propriétaire du repository (OWBSYS) , vous accédez alors à l’écran de configuration des options dans lequel toutes les options ont été décochées (elle sont cochées par défaut !).

Je coche donc l’option ODI Enterprise Edition (entourée) qui semble la plus générale, arrête et relance le centre de contrôle OWB, redéploie le mapping et cette fois c’est magique, ça fonctionne !

Mais comment, pourquoi ?

La réponse se trouve dans la note MOS 1334100.1 « Mapping Deployment Fails With RTC-5161 and OWB-00505 After OWB Upgrade From 10.2 to 11.2 » qui explique en substance que durant une migration 10.2 vers 11.2 l’option « Target Load Ordering » est réactivée par défaut dans les mappings.
Cette option bien utile qui permet d’imposer un ordre de chargement dans les mapping multi-target fait partie depuis la version 10.2 de l’option ODI Enterprise (!) ce qui explique qu’il y ait une erreur durant le déploiement si l’option n’est pas activée !
Une erreur OWB-00505 aurait tout de même été plus adaptée que cette RTC-5161 générique qui nous laisse démunis face à notre mapping qui ne se déploie pas …

Alors comment faire pour déployer ?

• Si vous avez des mappings qui utilisent effectivement le « Target Load Ordering » , achetez l’option ODI EE ou scindez les en plusieurs mappings distincts si vous souhaitez éviter cette dépense et n’utilisez que cette fonctionnalité de l’option ODI

• Sinon, décochez l’option « Target Load Ordering » de chaque mapping dans ses options de génération de code, la note MOS donne un script OMBplus permettant de réaliser cette opération en masse

La note MOS citée plus haut n’était pas publique au moment de notre migration ce qui n’a pas facilité l’identification de l’origine problème qui vous en conviendrez, était bien cachée …