MODPLSQL-00367: mod_plsql: /pls/apex/f HTTP-400 Illegal PLSQL identifer in input

Une application oracle application express (apex) utilise un «database access descriptor» (DAD) configuré au niveau d'un serveur OAS 10g.

Voici la section concernant ce DAD dans le fichier «dads.conf»:

<location /pls/apex>
SetHandler pls_handler
Order allow,deny
Allow from All
AllowOverride None
PlsqlDatabaseUsername apex_public_user
PlsqlDatabasePassword xxxxxxxxx
PlsqlDatabaseConnectString hostname:port:service ServiceNameFormat
PlsqlAuthenticationMode Basic
PlsqlSessionStateManagement StatelessWithFastResetPackageState
PlsqlDocumentTablename wwv_flow_file_objects$
PlsqlDocumentPath docs
PlsqlDocumentProcedure wwv_flow_file_mgr.process_download
PlsqlAlwaysDescribeProcedure Off
PlsqlDefaultPage f?p=102
</location>

Après avoir migré le serveur OAS à la version fusion middleware 11.1.1.3, en essayant l'url de l'application apex, l'on reçoit un message d'erreur HTTP-400.

Dans le fichier $INSTANCE11g_HOME/diagnostics/logs/OHS/ohs1/ohs1.log on peut lire le message d'erreur suivant:

MODPLSQL-00367: mod_plsql: /pls/apex/f HTTP-400 Illegal PLSQL identifer in input

Cette erreur est causée par la ligne suivante dans la configuration du DAD:

PlsqlDefaultPage f?p=102

Selon la documentation Oracle, ce paramètre peut être remplacé par un Rewrite rule:
http://download.oracle.com/docs/cd/E14571_01/web.1111/e10144/under_mods.htm#CIHBJFII

Donc supprimons cette ligne de notre fichier «dads.conf» (ou la mettre en commentaire).

Dans le fichier «httpd.conf», ajoutons le Rewrite rule (dans la section commune, pas dans un virtual host):

RewriteRule ^/pls/apex$ /pls/apex/f?p=102 [R]

Puis redémarrer OHS:

$INSTANCE11g_HOME/bin/opmnctl restartproc ias-component=ohs1

Hope it helps

«Failed to load user defined filter» after upgrade from portal 10.1.4.0 to portal 11.1.1.3

Après avoir migré de portal 10.1.4.0 à portal 11.1.1.3, les omniportlets ramènent le message d'erreur suivant:

Failed to load user defined filter
Dans le fichier WLS_PORTAL-diagnostic.log, l'on peut voir le message d'erreur:

oracle.xml.parser.v2.XMLParseException: Start of root element expected.
at oracle.xml.parser.v2.XMLError.flushErrors1(XMLError.java:323)
at oracle.xml.parser.v2.NonValidatingParser.parseRootElement(NonValidatingParser.java:380)
at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:321)
at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:319)
at oracle.xml.xslt.XSLProcessor.newXSLStylesheet(XSLProcessor.java:682)
at oracle.xml.xslt.XSLStylesheet.(XSLStylesheet.java:287)
at oracle.xml.parser.v2.XSLStylesheet.(XSLStylesheet.java:90)
at oracle.webdb.reformlet.data.xml.FilterHandler.loadFilter(Unknown Source)
at oracle.webdb.reformlet.data.xml.XMLDataDefinition.createContext(Unknown Source)
at oracle.webdb.reformlet.data.DataSourceDefinitionWrapper.createContext(Unknown Source)
at oracle.webdb.reformlet.definition.DataDefinition.setDataSourceInfoInContext(Unknown Source)
at oracle.webdb.reformlet.definition.DataDefinition.execute(Unknown Source)
at oracle.webdb.reformlet.definition.DataDefinition.execute(Unknown Source)
at oracle.webdb.reformlet.api.layout.LayoutContext.nextRow(Unknown Source)
at oracle.webdb.reformlet.api.el.ELRows.hasNext(Unknown Source)
...
...
Cela est dû au fait que les URLs dans les omniportlets sont sous la forme:

Pour le XML url:
http://localhost:7777/pls/pes/P_PESB_RECUP_FIL_RSS?P_IDENT=1&P_PERSP=Accueil

Pour le XSL filter url:
http://localhost:7777/portal/page/portal/14F1816FBFB751AEE04400144F0104BD

«localhost» a été utilisé dans la version 10g pour que les pages soient portables, c'est à dire qu'on peut exporter les pages d'un environnement à un autre et les omniportlets restent fonctionnels car localhost existe aussi sur l'hote cible.

Le problème vient du fait qu'avec la version 11g de portal, le server de bd qui abrite le metadata repository doit être capable de communiquer avec le serveur de midle tier par le virtual host utilisé. Puisque localhost est utilisé, il faut que le server de bd puisse communiquer avec le server de midle tier par localhost !!! ce qui est impossible, puisque sur chaque server, localhost pointe sur le serveur lui même.

Pour régler ce problème, il faut:

- Créer un virtual host commun dans tous les environnements (pour que les pages restent portables).
- Il faut definir ce virtual host dans le fichier /etc/hosts du serveur de bd de sorte qu'il pointe sur le serveur de middle tier ou le definir dans un DNS.
- Modifier tous les omniportlets pour qu'ils utilisent ce nouveau virtual host.

Hope it helps...

Object Not Found (WWC-50003) Error Accessing a page Using Durable URL after upgrade to Portal 11.1.1.3

Après avoir migré de la version 10.1.4.2 de portal vers la version 11.1.1.3, en voulant utiliser les liens (url) durables des pages, l'on reçoit le message d'erreur suivant:

Object Not Found (WWC-50003)

Cela est dû au fait que le processus de migration du metadara repository regenère les liens (url) durables. Mais c'est le comportement voulu par oracle, donc ce n'est pas une anomalie...

La question qui reste en suspens c'est pourquoi oracle décide de regénérer les liens durables tout en sachant très bien que cela rendra le site non fonctionnel après la migration...?

Pour régler le problème, deux options s'offrent à nous:

1- Parcourir le site et remplacer tous les appels par des liens durables par les nouveaux liens durables générés.

2- Si vous ne désirez pas faire ce travail manuel, et que vous souhaiteriez conserver vos anciens liens durables, suivre la procédure suivante:
- Restaurer le schéma PORTAL (en le renommant) d'un export de la BD pris avant de migrer le metadata repository. Cela suppose que vous devez avoir un export valid pris avant la migration. Si vous n'avez pas d'export, mais plutot un backup rman, restaurer le backup rman et faites votre export.
- Créer un DBLINK en utilisant le schéma précédemment restauré. - Demander le script «guidmasg.sql» à oracle support
- Se connecter à la BD du référentiel avec le schéma portal (le schéma migré) - Exécuter le scipt comme suit: SQL> @guidmasg.sql DBLINK

Hope it helps...