WebCenter Portal: Configuración de alta disponibilidad

Las etapas que se siguen en la mayoría de proyectos es la siguiente:
  • Desarrollo en entorno local e integración de los desarrollos en un entorno de desarrollo común. Este entorno normalmente suele ser standalone.
  • Entorno de test o certificación. En algunas ocasiones este entorno es standalone y en otras ocasiones es una simulación real del entorno productivo, por lo que es un entorno en clúster.
  • Entorno productivo. Normalmente suele ser un entorno en clúster.
El motivo de esta entrada no es otro que asegurar, desde el principio del desarrollo, que los desarrollos ADF (Task Flows, WebCenter Portal Application...) estén preparados para ser ejecutados independientemente del entorno.

¿Qué se debe cambiar de la configuración de las aplicaciones ADF desplegadas en entornos en clúster?.
  •   adf-config.xml. En el fichero de configuración de ADF debe habilitarse la posibilidad de que el framework haga un seguimiento y replique los manage beans en el clúster. Esto se consigue añadiendo:
    
  
    true

    ¿Por qué habilitar la alta disponibilidad de los manage-beans?  
    En ADF existen los siguientes ámbitos de manage bean:
    •  backingBean: Es el más pequeño de todos. Su duración es el de una petición (request) en una página o fragmento. Suele utilizarse para el manejo de componentes ADF de una página. Recordar que los UIComponent de ADF son objetos NO serializables.
    • request: Al igual que en backing bean, la duración es de una petición (request). Sin embargo, a diferencia de backing, los objectos en request scope pueden ser rescatados por Task Flow o fragmentos incluídos en la página.
    • view: Es el primer scope que va más alla de una petición. El ámbito de la viewScope va directamente relacionada con el viewId actual de la página. Hasta que no se cambia de viewId no se destruye el manage-bean perteneciente a este ámbito.
    • pageFlow: Este scope hace que el manage bean se mantenga vivo durante todo el flujo de páginas de un Task Flow (unbouned o bounded). Hay que recordar que cada pageFlowScope es local a cada Task Flow.
    • session: Como su propio nombre indica su periodo es el de una sesión HTTP con la aplicación. Esta información también debe ser serializada.
    • application: Su periodo de vida va relacionado desde que arranca hasta que se para una aplicación. Estos beans comparten la información a todos los usuarios.

    Como se puede comprobar, al menos 4 ámbitos de manage-bean son mayores que la duración de una petición (request). Esto significa que estos manage-bean (view, pageFlow, session y application) deben ser serializables para poder ser replicados en las distintas instancias de un clúster.

    Imaginemos en caso de que no se replicara la información. Si un usuario está interactuando con la página X, servida por la máquina A y por algún motivo la máquina A deja de ofrecer sevicio. El balanceador de carga asignará al usuario algún nodo o máquina que pueda seguir sirviendo las peticiones del usuario. En el caso de no haber serializado la información en el clúster, el usuario percibirá errores puesto que la información no se encuentra actualizada en la máquina B.

    Para serializar un bean basta con que implemente la interfaz java.io.Serializable y que todos sus atributos sean Serializables. Remarco esto último porque, aunque un bean implemente Serializable y se le asigne un serializationUID, si alguno de sus atributos internos NO es Serializable (ya sea un UIComponent o algún otro objeto) entonces hace que este bean no sea realmente Serializable.
    •   public class MiBean implements Serializable {
     // All attributes serializable
     String name;
     ...
  }
  • weblogic.xml: No basta con únicamente establecer la alta disponibilidad del framework ADF. Se debe configurar también como se va a llevar a cabo la replicación y serialización de información entre entornos. Por defecto viene configurado como MEMORY. Lo que quiere decir que guardará en memoria local los estados de los manage-bean. Esto solo vale para entornos standalone. Para entornos clúster se recomienda la configuración REPLICATED_IF_CLUSTERED. Es un comodín, dado que si se despliega en un servidor standalone, éste actuará como si fuera configurado como MEMORY. Sin embargo, si es desplegado en clúster replicará la información entre todos los nodos del clúster.

    No solo existe la replicación en memoria. También existe la opción de replicación a fichero o base de datos. Debe usarse replicación a base de datos siempre y cuando la memoria de la JVM vaya limitada o sea muy escasa. Sin embargo, este tipo de serialización puede afectar al performance de la aplicación.
      
    /myportal
    REPLICATED_IF_CLUSTERED
    Nota: Asignar el cookie-path es algo común en las aplicaciones de WebCenter Portal con conexión a WebCenter Content. Si se habilita la edición inline de contenidos (configuración de OHS y conexión a WebCenter Content) normalmente se suele perder la sesión del portal al acceder a UCM. Para ello se introduce una cookie-path con el mismo nombre y path del portal configurado en OHS. (Ampliaré información en post posteriores).

  • web.xml: En la documentación de Apache Trinidad y Oracle se recomienda que el parámetro de contexto org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION se cambie a false para entornos en clúster/productivos. Este parámetro según la documentación puede sobrecargar y a la vez provocar fallos en caso de failover.
      
    If this parameter is true, there will be an automatic check of the modification date of your JSPs, and saved state will be discarded when JSP's change. It will also automatically check if your skinning css files have changed without you having to restart the server. This makes development easier, but adds overhead. For this reason this parameter should be set to false when your application is deployed.
    org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION
    false
  • Servicios WebCenter: La aplicación ya está preparada para entornos de alta disponibilidad. Sin embargo, hay que tener en cuenta ciertos aspectos relacionados con los servicios proporcionados por WebCenter. Por ejemplo, el colector de Analytics debe ser configurado 1-1. No acepta entornos en clúster.
    Por otro lado, Collaboration Server debe modificar su configuración para hacer un enable de entorno en clúster.

    Para más información de como modificar las conexiones y servicios WebCenter para alta disponibilidad leer la documentación oficial de Oracle: 

Comments

Post a Comment

Popular posts from this blog

OJET: Inter-Module communication in TypeScript Template

Image
In this post I bring another example on how to Communicate Modules using the Oracle JET - TypeScript Template based on the Oracle JET Cookbook: InterModule Communication From now and so on will create multiple examples using TypeScript for those who are not familiar with it and wants to turn the Cookbook examples into TypeScript :). The example ( ojet-typescript-list-detail ) can be found as usual in my GitHub repository: https://github.com/DanielMerchan/ojet-examples This example is a bit different compared to the Cookbook example where the modules are not running at the same time within a Module. This example is built as described in the following images: Customers module acts as the Wrapper Module. It coordinates when to load the list and detail modules. Customers module makes use also of signals npm module for communication between Customers-List, Customers-Detail. Explanation of the Example customers.js is the coordinator responsible module for: initiali
Read more

OJET: Build and Deploy in an Application Server

Image
There are some other sources where an Oracle JET Application is packaged and deployed as a WAR in Oracle WebLogic Application Server (Arda Eralp) https://blogs.oracle.com/ardaeralp/deploy-oracle-jet-application-to-weblogic-server (Andrejus Baranovski's) http://andrejusb.blogspot.com/2016/07/serving-oracle-jet-application-from.html They may look bit old or maybe because they call directly grunt tasks by using the grunt-cli . In this post I will update a bit these posts in Oracle JET 6.1.0 and the usage of ojet build (instead of calling the grunt tasks) for also building the corresponding WAR file. The example can be found in my GIT repository: https://github.com/DanielMerchan/ojet-examples Let's start... Install grunt-war module in your Oracle JET Application. npm install grunt-war --save-dev Create a war.js (or call it whatever you want) in /scripts/grunt/config folder under your souce files. This is a sample code inside of it, check https://www.npmjs.com/packag
Read more

OJET: Select All options using only Checkboxset

Image
This is an example on how to select all other options by using another oj-checkboxset. GitHub: ojet-checkbockset-select-all The idea is to keep track of the selection and make use of the on-value-changed as described in the following code. self.colorOptions = ko.observableArray([ { id: "blueopt", value: "blue", color: "Blue" }, { id: "greenopt", value: "green", color: "Green" }, { id: "redopt", value: "red", color: "Red" }, { id: "limeopt", value: "lime", color: "Lime" }, { id: "aquaopt", value: "aqua", color: "Aqua" }, ]); self.selectAll = ko.observableArray([]); self.currentColor = ko.observableArray(["red"]); self.selectAllOptionChanged = (event) => { const newSelection = event.detail.value; if (newSelection.indexOf('all')
Read more