Oracle
 sql >> Base de données >  >> RDS >> Oracle

Formulaires Oracle dans R12/R12.2

Nous expliquons ici les fonctionnalités d'Oracle Forms Architecture dans R12/R12.2

Table des matières

  • Fonctionnalités des formulaires dans R12
  • Fonctionnalités des formulaires dans R12.2
  • Architecture de servlet de formulaires
    • Avantage du mode servlet
  • Architecture de socket de formulaires
    • Avantage du mode socket
  • Différence entre la version 11i et R12
  • Définitions d'artefacts de formulaires

Fonctionnalités des formulaires dans R12

-les formulaires sont déployés comme une seule instance OC4J de 10.1.3 Oracle home
-Il utilise l'utilitaire de 10.1.2 Oracle home/bin
-Forms.EAR 10.1.2 est déployé sur le conteneur OC4J dans Application Server 10.1.3
-L'exécutable de formulaire d'exécution f60webmx a été remplacé par frmweb
-Forms Servlet est le mode de déploiement/communication par défaut
-FORMS_ les variables d'environnement remplacent FORMS60_
-Nouveau variables d'environnement, par ex. FORMS_TRACE_DIR
-$ORACLE_HOME/bin/frmbld.sh remplace f60desm pour la conception
-frmcmp.sh et frmcmp_batch pour la génération

Fonctionnalités des formulaires dans R12.2

- les formulaires sont déployés en tant que serveur géré unique dans  le serveur Weblogic d'Oracle
-Il utilise l'utilitaire de 10.1.2 Oracle home/bin
-Forms.EAR 10.1.2 est déployé sur le serveur géré dans Oracle Weblogic Application Server
-L'exécutable de formulaire d'exécution f60webmx a été remplacé par frmweb
-Forms Servlet est le mode de déploiement/communication par défaut
-FORMS_ variables d'environnement remplacent FORMS60_
-Nouvelles variables d'environnement, par ex. FORMS_TRACE_DIR
-$ORACLE_HOME/bin/frmbld.sh remplace f60desm pour la conception
-frmcmp.sh et frmcmp_batch pour la génération

Architecture de servlet de formulaires

Le servlet Forms Listener est responsable de la gestion des processus d'exécution des formulaires et du routage de toutes les communications avec les clients. Tout le trafic entre l'applet client Forms et le processus d'exécution du serveur Forms est désormais acheminé via l'écouteur Apache et le servlet Forms Listener.

-L'URL générée par l'applet Forms exécutera le servlet Forms Listener. L'écouteur du serveur HTTP Oracle (Apache) reçoit la demande, la reconnaît comme une demande d'exécution d'un servlet et la délègue à mod_oc4j pour l'exécution.
-Mod_oc4j transmet la demande au servlet Forms Listener (instance Forms OC4J). Le servlet Forms Listener lance un nouveau processus d'exécution de formulaires (frmweb).
-La couche de message Forms renvoie un message contenant les métadonnées du formulaire et les données requises pour afficher l'interface utilisateur. La structure du message est la même que celle utilisée par le processus d'écoute de formulaires, mais cette fois-ci, il est renvoyé via le servlet d'écoute de formulaires et l'écouteur apache. le renvoie au client via l'écouteur Apache.

Toutes les communications ultérieures du client Forms avec le serveur Forms suivent le même chemin.

Avantage du mode servlet

  1. Le trafic HTTP et HTTPS est facilement reconnaissable par les routeurs, tandis que les communications en mode socket sont généralement considérées comme suspectes et traitées de manière exceptionnelle.
  2. Le matériel réseau existant peut être utilisé pour prendre en charge des fonctions de base telles que l'équilibrage de charge et le chiffrement des paquets pour le transit réseau.
  3. Plus résistant aux reconfigurations de réseau et de pare-feu
  4. Plus robuste :les connexions de servlet peuvent être rétablies si les connexions réseau sont interrompues de manière inattendue pour les pages Forms, Framework et JSP.
  5. Il s'agit de la seule méthode prise en charge pour les clients génériques d'Oracle Forms. Elle est donc testée de manière plus approfondie par les groupes de produits Forms et E-Business Suite.
  6. Les performances du trafic peuvent être surveillées via des outils tels qu'Oracle Real User Experience Insight (RUEI).
  7. Le mode socket n'est pas pris en charge sur les plates-formes de serveur Windows.
  8. Aucun port n'a besoin d'être ouvert pour accéder aux formulaires dans le pare-feu en cas de servlet.
  9. Configuration SSL simple en cas de servlet (car aucune configuration SSL distincte n'est requise pour les formulaires car les connexions se font via un serveur Web/http)
  10. Le servlet Forms Listener communique via le port du serveur HTTP et n'a pas besoin de ports supplémentaires pour gérer la communication entre le client et Oracle Application Server Forms Services. L'architecture Forms Servlet est également compatible avec les normes de l'industrie des applications Web et prend en charge différentes configurations réseau avancées telles que l'équilibrage de charge.

Architecture de socket de formulaires

Les versions initiales du produit Oracle Forms Server utilisaient une méthode simple pour connecter le client au serveur. La connexion du client de bureau au processus Forms Listener a été réalisée à l'aide d'une connexion socket directe.

Fondamentalement, la connexion au bureau du client est établie avec le processus Forms Listener. Un nouveau processus d'exécution Forms est dupliqué ou, le cas échéant, le prochain processus de pool libre est utilisé. La connexion socket entre l'applet Forms et Forms Listener est transmise au processus d'exécution Forms, de sorte que l'applet communique directement avec le processus d'exécution. Sauf si HTTP est utilisé, l'écouteur n'est plus nécessaire, sauf pour desservir d'autres nouvelles connexions.

Dans 11i, CGI a été utilisé pour générer la page initiale qui aide à créer la connexion socket

Dans Oracle E-Business Suite Release 12, la requête initiale qui génère dynamiquement la page HTML pour démarrer l'applet de formulaires est traitée par le servlet Forms, bien que le servlet ne reçoive qu'une requête par session de formulaires

Avantage du mode socket

1. Utilise jusqu'à 40 % de bande passante en moins que le mode servlet Forms. Cela peut être perçu par les utilisateurs du réseau étendu (WAN) comme provoquant une réactivité plus lente, en fonction de la latence du réseau. Traitement HTTP POST.

Différence entre les versions 11i et R12

Nous avons des formulaires Oracle 6i dans la suite Oracle E-buisness 11i, tandis qu'Oracle forme 10g dans la suite Oracle E-buisness R12.0/R12.1/R12.2.

Les bases restent les mêmes dans tout cela. L'exécutable diffère d'une version à l'autre

Définitions des artefacts de formulaires

-Le .fmb fichier est un fichier source de formulaire. C'est un fichier binaire, qui contient les métadonnées, la source et le PLSQL compilé.
-Le .fmx le fichier est la version générée du formulaire utilisé lors de l'exécution
-Le .mmb fichier est le fichier source du menu. C'est un fichier binaire.
-Le .mmx le fichier est la version générée du Menu utilisé lors de l'exécution
-Le .pll fichier est le fichier source de la bibliothèque attachée côté client. Il peut également être utilisé lors de l'exécution, bien qu'Oracle Applications doive utiliser des fichiers plx. Il contient la source et le PLSQL compilé.
-Le .plx Le fichier est une version dépouillée de la source du .pll, utilisée lors de l'exécution. Il contient du PLSQL compilé.
f60webmx est le processus d'exécution des formulaires de niveau intermédiaire sous Unix. (11i)
frmweb  est le processus d'exécution des formulaires de niveau intermédiaire sous Unix. (R12.0/R12.1/R12.2)
f60srvm est le processus d'écoute des formulaires sous Linux
-L'applet des formulaires est générique sur toutes les plates-formes. L'applet Forms est également générique dans la mesure où une seule applet est utilisée pour exécuter tous les formulaires.
-Les Java Beans sont utilisés pour implémenter la logique côté client d'Oracle Applications en étendant l'applet Forms.

Formulaires, bibliothèques et menus

  • Au niveau intermédiaire, une application Forms se compose de formulaires, de menus et de bibliothèques. Il existe également des objets de base de données et des packages et procédures côté serveur sur le SGBDR, mais ceux-ci ne seront pas pris en compte dans ce document.
  • Un fichier source de formulaire est un fichier binaire et a un suffixe .fmb, par ex. XYZ.fmb. Il contient toutes les métadonnées pertinentes, les unités de programme PL/SQL et le PL/SQL compilé. Le fichier fmb n'est pas utilisé lors de l'exécution, mais peut être ouvert dans le générateur de formulaires ou utilisé pour générer la version d'exécution (.fmx) du formulaire.
  • Le fichier .fmx est essentiellement un fichier de paramètres binaires qui est lu par l'exécutable d'exécution Forms. Ce n'est pas un exécutable en soi, bien que la génération du .fmx soit parfois appelée "compilation" et que le .fmx soit souvent appelé "l'exécutable".
  • Un fichier .fmx ne peut pas être rétroconçu dans le fichier .FMB correspondant.
  • Les formulaires de candidature sont traduits, de sorte que chaque langue dispose de son propre ensemble de formulaires. Par exemple, ~/forms/US est destiné aux utilisateurs dont la langue du niveau intermédiaire (NLS_LANG) est définie sur l'anglais américain.
  • Des principes similaires s'appliquent aux menus, où un suffixe mmb désigne un fichier source et un suffixe mmx une version générée. Les applications n'utilisent qu'un seul menu, FNDMENU. Comme un formulaire, ce menu est traduit en différentes langues, situé sous ~/resource/US.
  • Les bibliothèques suivent des règles légèrement différentes pour les formulaires et les menus. Le fichier source a un suffixe .pll et la source supprimée a un suffixe .plx. Le .pll peut être chargé dans le Builder, généré et utilisé lors de l'exécution ; il contient à la fois du PL/SQL source et compilé. Le .plx a la source supprimée et ne contient que du PL/SQL compilé, il ne peut donc être utilisé qu'au moment de l'exécution. Oracle Applications utilise le .plx au moment de l'exécution, car il est beaucoup plus petit et donc plus efficace.
  • Les bibliothèques ne contiennent aucune chaîne traduisible, il existe donc une version pour toutes les langues, qui est enregistrée dans le répertoire ~/resource.
  • Les bibliothèques sont liées dynamiquement au moment de l'exécution. La norme Applications permet au développeur d'attacher une bibliothèque sans chemin ni suffixe .pll/.plx. Forms recherche d'abord une bibliothèque dans le répertoire en cours, puis dans chaque répertoire spécifié dans FORMS60_PATH. Il recherche d'abord un .plx, puis un .pll.
  • Comme indiqué, Applications utilise le .PLX car il est plus petit et nécessite moins de mémoire. Cependant, parfois des problèmes avec l'environnement, en particulier lorsqu'il est utilisé pour le développement personnalisé, peuvent conduire à ce que le .PLL soit trouvé en premier. Encore une fois, truss peut rapidement identifier ce type de problème.

Lit également
Serveur HTTP Oracle dans EBS
Conteneur OC4J