martes, 12 de febrero de 2013

WebCenter Portal: Twitter Search Adapter. Alpha

Próximamente compartiré un pequeño tutorial explicativo de cómo se construye un Default Search Adapter para el buscador de WebCenter Portal que trae OOTB. (Ampliando así el ejemplo traído por la documentación oficial).

Os dejo la imagen de la alpha del adaptador que usaré para explicar el framework (aún no funciona los filtrados/paginación). En este adaptador se usa el API de Twitter de Java.

Enlace al tweet con la imágen.

Twitter Search Adapter para WebCenter



WebCenter Portal PS5: Bugs encontrados y soluciones a los mismos

En esta entrada quiero compartir los errores más extraños que he encontrado en la versión PS5 de WebCenter Portal.

HTTP 404 durante la navegación de páginas.
El escenario era el siguiente:
  • anonymous-role eliminado de la seguridad de las páginas. No era permitido que un usuario anónimo atravesará más allá de la login page.
  • múltiples navegaciones: Múltiples navegaciones usadas en las páginas (a parte de la default). Esto provocaba que al navegar con node.goLinkPrettyUrl se perdiera los enlaces de otras navegaciones forzando un HTTP 404 (que yo traduzco en un error de seguridad más que un 404). Al navegar con
    node.goLinkPrettyUrl las URL generadas son del estilo /faces/[id_nodo]
  • SSO Kerberos.
  • Uso de back button del navegador: Aparte de navegar por el portal, en ciertas ocasiones al seleccionar varias veces el back button se perdía la navegación.
Al parecer el error HTTP-404 es algo muy comentado en blogs y parece estar directamente relacionado entre ADF Security y la seguridad propia de las páginas de WebCenter.

Solución: 
  1. La solución aplicada antes de la aparición del parche de Oracle fue la transformación de toda la navegación al uso de af:commandLink con navegación ppr. Con ello se forzaba al servidor una navegación desde código Java y evitaba que se perdiese la navegación por cualquiera de las razones anteriores.
  2. Aplicar el parche 14076906 (11.1.1.6.3), que introduce la solución a los bugs:
    1. 13421349 - NAVIGATION MODEL GENERATES 404 WHEN ACCESSING LINKS TO SECURED PAGES
    2. 13503135 - ADF CONTROL STATE NOT PRESENT ON GOLINKS WHEN USING PRETTYURLGOLINK
Object name oracle_webcenter_doclib_view_jsf_taskflows_presenter_presenterSingleViewPageDef_oracle_webcenter_doclib_view_jsf_taskflows_presenter_contentPresenter_xml_doclib_content_presenter of type Iterator Binding Definition is invalid

En páginas que continen Content Presenter y se mezclaba navegación con goLinkPrettyUrl en ocasiones la página daba una excepción mostrando un popup con el error que aparece en el título.

Por alguna razón, no es capaz de leer el iterador de la pageDef haciendo que salga ese molesto popup.
Solución:
  1. Cambiando la navegación a ppr pareció solventar el problema.
  2. Aplicando el parche 14076906 (11.1.1.6.3) parece eliminar este molesto bug.
 No se pueden leer los comentarios asociados a las respuestas de las preguntas de un sondeo / encuesta (Poll & Surveys)
Sorprendentemente los Task Flow OOTB de Poll & Surveys no dejan ver los comentarios que los usuarios han introducido a las respuestas que han dado a una encuesta.

Investigando por la BBDD encontre que en el esquema de WebCenter no registraba los comentarios. 
Al parecer, estos comentarios los almacena en el MDS y se pueden acceder usando el Data Control : Take Poll Data Control

Soluciones:
  1. Si tienes una versión de JDeveloper 11.1.1.6 con una extensión antigua de la versión 11.1.1.6 de WebCenter el método getFeedback asociado a una Question no aparece. Éste método es introducido en extensiones más recientes de WebCenter en JDeveloper 11.1.1.6.
  2. Aplicando el parche 11819965 (11.1.1.6.4 que requiere el parche 14076906 previamente instalado) se añade en los Task Flow OOTB la posibilidad de ver los comentarios asociados a las respuestas.
Como siempre recordar que tanto el foro de OTN WebCenter Portal como Oracle My Support son dos fuentes principales de soluciones a problemas que se puedan encontrar en los desarrollos de WebCenter.

lunes, 11 de febrero de 2013

JDeveloper 11.1.1.6: Error al ejecutar el servidor integrado

Hace tiempo encontré en el foro de OTN algún post como el siguiente:

Post de OTN con problemas al arrancar Integrated WebLogic porque no puede aplicar una template

Fragmento del error:
wlst > Adding domain extension template: /C:/oracle/Middleware/jdeveloper/common/templates/applications/jrf_template_11.1.1.jar
Error: addTemplate() failed.


En mi caso, la stack trace contenía el error de que no podía aplicar la template para jrf_template_11.1.1

¿Cómo solucionar este error?.
Hay que asegurarse de que en la %ORACLE_HOME% únicamente aparece una vez esta template.
Al buscar en C:/Oracle/Middleware (Middleware por defecto configurado cuando se instala JDeveloper) por la template jrf_template_11.1.1 observé que estaba 2 veces.

Una de ellas en la ruta:
C:\Oracle\MiddlewarePS5\oracle_common\common\templates\applications

Y otra en:
C:\Oracle\MiddlewarePS5\oracle_common\common\templates\was

Eliminando la que se encontraba en \was y ejecutando de nuevo el WebLogic Integrado instaló y extendió perfectamente generando el Default Domain.


jueves, 7 de febrero de 2013

Runtime LOV para parámetros de Task Flow

Tanto los Task Flow ofrecidos OOTB por WebCenter Portal/Spaces como los que se desarrollan Custom a medida suelen tener parámetros de entrada para configurar el funcionamiento de los mismos.

Enlace de descarga del ejemplo

En muchas ocasiones, es bastante incómodo tener que ir a visitar la documentación oficial para saber exáctamente que valores se deben poner en los parámetros de entrada de un componente.

Por ejemplo: El Task Flow Search contiene numerosos parámetros de entrada. Entre ellos el de los servicios sobre los que se quieren obtener resultados.
Por defecto encontramos esta ventana para configurar sus parámetros:

Parámetros por defecto del Task Flow Search

Como se puede observar, por ejemplo el parámetro de "" exige el conocimiento de los identificadores de servicios de WebCenter por lo que deben ser consultados en la documentación oficial.

Sin embargo, con el ejemplo que os traigo se puede realizar una pequeña modificación a los parámetros de entrada de cualquier Task Flow para que se haga más amigable la elección de la configuración.

Parámetro Services to be Included modificado con un selector

¿Cómo se logra sobreescribir los parámetros de entrada de los Task Flow?.
La respuesta es sencilla. Extendiendo las capacidades que ofrece Oracle Composer. Hay 3 posibilidades que hay para modificar el comportamiento por defecto de una parámetro de entrada:
  • Lista estática: Aparecera un combo en el que se puede seleccionar un valor de una lista con valores estáticos configurados. También se pueden definir de manera global para poder ser reusados en otros parámetros de entrada.
  • Lista dinámica de valores (LOV). El enumerado procede de un manage bean que devuelve un java.util.List<SelectItem>. También se pueden definir de manera global para poder ser reusados en otros parámetros de entrada.
  • Selectores (pickers): Son Task Flow Custom que se desarrollan para realizar interfaces mas complejos de selección del valor o valores que va a contener el parámetro de entrada del Task Flow.
Para extender Oracle Composer seguir los siguientes pasos:
  • Crear en la carpeta META-INF un archivo llamado pe_ext.xml.
    Archivo pe_ext.xml para extender Oracle Composer
  • Registrar los distintos Task Flow que queremos sobreescribir.
    Task Flow registrados para sobreescribir sus parámetros de entrada
    La ruta del Task Flow viene determinada por: [su ruta de paquetes / carpetas]+[nombre-fichero.xml]#[task-flow-id]

    Por ejemplo para saber como encontrar los Task Flow de producto seguir estos dos pasos:
    • Localizar el Task Flow. En caso de uno Custom sabemos en que carpeta se encuentra. Sin embargo, para uno de producto usar el siguiente enlace: Tabla de rutas de los Task Flows de WebCenter.
      Tabla de la documentación oficial de Oracle de las librerías y rutas de Task Flow
    • Para saber el identificador del Task Flow solo hay que abrir la definición del mismo y tomar el identificador.
      Identificador del Task Flow
      Para los Task Flow de producto hay que configurar el proyecto para Show Libraries y navegar en la librería que contiene el Task Flow que se esta buscando.
      Task Flow de Search buscado a través de las librerías
  • Aprovechar el registro del Task Flow para registrar al mismo tiempo qué parámetros se desean sobreescribir. El nombre de los parámetros debe coincidir con el nombre configurado en la definición del Task Flow
    [Imagen con los nombres de los input param]
  • Según la tipología comentada anteriormente el registro del enumerado cambia.
    • Lista estática: Es una lista directa de nombre/valor.
      Declaración de una lista estática para un parámetro del Task Flow
    • Lista dinámica: Puede referenciar directamente un manage-bean definido en adfc-config.xml. Debe devolver una List<SelectItem>
      Declaración de una lista dinámica para un parámetro del Task Flow
    • Selector (picker): Hay que configurar la ruta del Task Flow que implementa el selector.
      Declaración de un selector basado en Task Flow para un parámetro de un Task Flow
  • En el caso de usar un selector (picker), es decir, un Task Flow Custom hay que tener en cuenta los siguientes detalles a la hora de implementarlo:
    • Deben declararse dos parámetros de entrada. El nombre de los parámetros debe ser exactamente el mismo que el de la imagen/explicación, al igual que su tipo.
      Parámetros de Oracle Composer obligatorios para el selector
      •  inParamVal: Contiene el valor actual configurado en el parámetro.
      • outParam: Es un mapa de valores donde Composer almacena cierta información. Se usa para volcar la información seleccionada en nuestro selector.
    •  El Task Flow debe al menos tener un activity return.
      Return activity para el Task Flow selector
    • Durante la implementación de código. En la inicialización cargar los valores que ya estaban previamente seleccionados de inParamVal en una lista interna o algun bean manejable.
      Código referente a recoger el valor ya configurado previamente para el parámetro
      Proporcionar botones para poder salir del popup lanzador por Oracle Composer y volcar en el mapa outParam los nuevos valores seleccionados.
      Código reference al volcado de la nueva información seleccionada para el parámetro

Recomendaciones: Como recomendación personal. Me gusta tener en un proyecto separado aparte toda la sobreescritura correspondiente a parámetros de entrada de los Task Flow de producto de WebCenter. Los Task Flow Custom desarrollados podrían llevarlo de serie dentro de sí mismos.

El ejemplo: En el ejemplo os dejo las 3 posibilidades que hay (no muestro como declarar listas globales, leer documentación para ello).
Con respecto al ejemplo del selector (picker), he desarrollado un selector basado en un af:selectManyShuttle a través del cual el usuario puede seleccionar qué servicios quiere que se configuren para el Task Flow de producto Search. Para verlo, obviamenete acceder a la página Home del portal como administrador. Acceder a Oracle Composer y modificar el parámetro de selección de servicios.
Por otro lado, hay un Custom Task Flow interno en el proyecto de Portal que tiene dos parámetros de entrada. Uno de ellos recoge la información de una lista estática y el otro la recoge de un Manage Bean.

Referencias:
 Enlace de descarga (Ejemplo desarrollado en JDeveloper 11.1.1.6) 

miércoles, 6 de febrero de 2013

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: 

martes, 5 de febrero de 2013

Oracle WebCenter Portal: Uso del adaptador de búsqueda estándar en lugar de Oracle SES

Por defecto las aplicaciones creadas con JDeveloper con la plantilla de WebCenter Portal Framework están preparadas para funcionar con Oracle SES como motor de búsqueda.

En el caso de no disponer de licencia de Oracle SES y querer usar "WebCenter Default Search Adapter" (los adaptadores de búsqueda estándar) se debe cambiar la siguiente propiedad del fichero de configuración adf-config.xml:

<!-- Default  for SES -->
<crawl-properties fullCrawlInterval="P5D" enableWcServicesCrawl="true" enableWcDiscussionsCrawl="true" enableWcUcmCrawl="true"/>

a

 <!--WebCenter Portal Default Search Adapter -->
<crawl-properties fullCrawlInterval="P5D" enableWcServicesCrawl="false" enableWcDiscussionsCrawl="false" enableWcUcmCrawl="false"/>


Fuente: http://docs.oracle.com/cd/E29505_01/webcenter.1111/e25595/jpsdg_search.htm#CBHEHJHI