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...

Configurer Oracle Weblogic pour un démarrage sans saisie de mot de passe

Pour éviter qu'à chaque démarrage de Weblogic l'on vous demande de saisir un nom utilisateur (weblogic) et mot de passe, il faut faire les configurations suivantes:

Admin Server :

cd $Middleware_Home/user_projects/domains/Nom_Domain/bin
./startWebLogic.sh

Entrer usager et mot de passe.

À la fin du démarrage:
Faire Ctrl + C pour arrêter l’AdminServer.

Modifiez le fichier startWebLogic.sh et ajoutez la propriété
« -Dweblogic.system.StoreBootIdentity=true » à la variable JAVA_OPTIONS

Exemple :
…
# Call setDomainEnv here.
DOMAIN_HOME="$Middleware_Home/user_projects/domains/Nom_Domain"
. ${DOMAIN_HOME}/bin/setDomainEnv.sh $*
JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.system.StoreBootIdentity=true"
…

Dans le répertoire $Middleware_Home/user_projects/domains/Nom_Domain/servers/AdminServer/security,

Créez un fichier avec le nom de boot.properties

Dans ce fichier, écrire les lignes suivants :

username=weblogic
password=welcome1

Note: Remplacer welcome1 par le mot de passe de l'usager weblogic que vous aviez choisi à l'installation.

Enregistrez les changements au fichier.

Démarrer l’admin server en background :

cd $Middleware_Home/user_projects/domains/Nom_Domain/bin
nohup ./startWebLogic.sh &

Suivre le processus de démarrage en faisant un «tail» sur le fichier «nohup.out»

tail -f nohup.out


Managed Servers:

cd $Middleware_Home/user_projects/domains/Nom_Domain/bin
./startManagedWebLogic.sh WLS_PORTAL http://votreserveur:7001

Entrer usager et mot de passe.

À la fin du démarrage:
Faire CTRL + C

Puis pour démarrer en background:

nohup ./startManagedWebLogic.sh WLS_PORTAL http://votreserveur:7001 > nohupPortal.out &

Suivre le processus de démarrage en faisant un «tail» sur le fichier «nohupPortal.out»

tail -f nohupPortal.out

Hope it helps...

Schema Validation Utility (SVU) - set: Syntax error

Vous utilisez Oracle Portal.
Dans ce cas ci, j'utilise portal 10.1.4.0.

Je viens d'installer le patch 10339228 qui est le Schema Validation Utility (SVU) de cette version de portal (10.1.4.0).

Je veux l'exécuter en mode REPORT pour voir si oui ou non il y a des incohérences dans le référentiel:

cd $ORACLE_HOME/portal/patch/oneoffs/10339228
./svu.csh -s portal -p mot_de_passe_schema_portal -c tns_alias_bd -mode REPORT -type ALL
Portal Schema Validation Utility
Exporting the contents of wwpof_output$ before running Schema Validation Utility
set: Syntax error

Cela est dû au fait que le NLS_LANG est positionné à une langue autre que l'anglais.

Conséquence: la requête suivante (qui est censée créer un nom de fichier) ramène une valeur avec un espace (connectez-vous à la base de données du référentiel et exécutez cette requête pour confirmer le problème):

select 'wwpof_output_' to_char(sysdate,'ddmonyyyy_hh24_mi_ss') from dual;

Pour corriger le problème, il y a 2 fichiers à modifier:

$ORACLE_HOME/portal/patch/oneoffs/10339228/getpar.sql
$ORACLE_HOME/portal/patch/oneoffs/10339228/utlcrlog.sql

Dans ces 2 fichiers, partout où vous verrez to_char(sysdate,'ddmonyyyy_hh24_mi_ss'), ajouter «fm» comme suit (cela résoud le problème d'espace):

to_char(sysdate,'fmddmonyyyy_hh24_mi_ss')

Puis re-exécutez votre SVU.

Note: ID 874492.1

Hope it helps...