Show any image rendition in a Content Presenter Template

One of the common questions when a developer is creating a template for the WebCenter Content Presenter is


"How can I show the thumbnail of the image?" or "How can I obtain xxxx rendition?", Is quite simple, but I believe that is not documented.


This is a sample for a thumbnail:

<af:image source="#{WCAppContext.applicationURL}/content/conn/UCM/uuid/dDocName%3a#{node.propertyMap['dDocName'].value.stringValue}?rendition=thumbnail"

id="i1"/>

Where "UCM" is the name of your content connection inside the WebCenter Portal application.

I hope this helps you on your templates development.

Add SecurityGroup from parent folder in a profile check-in

Using folders component in WebCenter Content, let you to add default or inherit metadata to the contents that are under the parent folder.

Imagine that you have 3 different folders for a "news" content, two of them with "Public" SecurityGroup but the last one with "Secure" SecurityGroup.

Usually you will create only one profile, so users will select the folder during check-in process (if they can see them) and depending of the folder, the metadata dSecurityGroup will be filled.


Here are the steps to achieve this:

Modify "Folders" View

1. Log into Configuration Manager Applet
   
   
2. Go to "Tables" tab, and select "Collections" table.
   
   
3. Click on "Edit Table", if you cannot see the columns, click on "syncrhonize definition" close again the windows and try again (sometimes it tooks a while until the columns information appears)
   
   
4. Now move to "View" Tab and Edit the "Folders" View.
   
   
5. Edit it and select the "Change Columns" to include the dSecurityGroup
   
   
   
   
6. Move to the "Security" Tab and check the option "Publish view data".
   
   

Creating the Rule

1. Create a new rule and check it as "global"
   
   
2. Go to fields, and add "Security Group"
   
   
   
   
3. Edit "Derived field information" and in custom tab add this code:
   
   
   
   

<$nuevoValor=getViewValue("Folders",#active.xCollectionID,"dSecurityGroup")$>
<$if nuevoValor$>
<$dpPromote("dSecurityGroup",nuevoValor)$>
<$endif$>


Few things to remember

If the metadata from the parent that you want to "derive" is custom (like xDepartment) you should create a view from table "COLMETA" with the columns dCollectionID and xDepartment, for more info check on metalink this note: 780979.1

Instalación de WebCenter en Cluster (parte 1)

Hace unas semanas estuve instalando un entorno WebCenter para nuestras pruebas, desarrollos y demás trasteos.


Lo normal es que cuando se trate de un entorno de desarrollo, lo instalemos todo en un mismo equipo sin pensar en ningún momento en tener un cluster o repartir los nodos manejados por distintas máquinas.


Pero WebCenter PS4 necesita unos recursos de memoria RAM muy elevados que no solemos tener disponibles en nuestros equipos. En otras ocasiones usé los servicios en la nube de Amazon que te proporcionan equipos de grandes recursos de memoria por un precio relativamente bajo.


Pero para esta ocasión, no íbamos a instalar en "la nube", ya que son entornos de pruebas, con muy poco uso y que podíamos montar en nuestra oficina. El único inconveniente es que el departamento de sistemas no me daba ninguna máquina virtual de más de 4Gb de RAM.


La única solución posible era repartir los nodos manejados por varias máquinas, y tener la base de datos también separada, en total 3 máquinas.

OWC1 y OWC2 son las máquinas que tendrán la instalación de todos los nodos de WebCenter.


OWCDB es la base de datos con los esquemas necesarios para WebCenter ya creados con la herramienta rcu (más información aquí).


Instalación del Software


Nuestra instalación no tiene una unidad compartida, por lo que estamos obligados a instalar TODO el software en aquellas máquinas que componen nuestro dominio, en este caso, en las máquinas OWC1 y OWC2 realizamos la instalación de:

• JRockit
• Weblogic
• ECM
• WebCenter

Hay que hacer la instalación con los mismos usuarios, permisos y directorios, en mi caso todo cae en el directorio /oracle/middleware.


Instalación de AdminServer y creación de dominio


En primer lugar debemos de crear el dominio y configurar únicamente el AdminServer, que en nuestro caso está en la máquina #OWC1.


Ejecutamos la herramienta de configuración:

cd /oracle/middleware/oracle_common/common/bin
./config.sh

Seguimos el Wizard como muestran las siguientes capturas de pantalla:

Una vez finalizado el Wizard de creación de dominio, procedemos al arranque de Weblogic para que se creen los directorios del AdminServer.

cd /oracle/middleware/user_projects/domains/dev_domain
./startWeblogic.sh

Finalizado el arranque veremos la traza que indica su estado en "RUNNING"

<Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>

En este punto cerramos la ejecución con las teclas CTRL + C y vamos al siguiente paso.

Configuración del fichero boot.properties

Ahora accedemos al directorio security, en caso de no existir lo creamos.

cd /oracle/middleware/user_projects/domains/dev_domain/servers/AdminServer/security
vi boot.properties

Incluimos los datos de usuario y contraseña definidos durante la creación del dominio dentro del fichero properties.

username=weblogic 
password=<Password>

Iniciamos NodeManager

Especificamos las propiedades de entorno:

cd /oracle/middleware/oracle_common/common/bin
./setNMProps.sh

Ahora ejecutamos el NodeManager:

cd /oracle/middleware/wlserver_10.3/server/bin/
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh

La variable DomainRegistrationEnabled=true sólo se aplica al NodeManager que va a tener el AdminServer, en este caso sólo el de la máquina #OWC1. Es más cómodo modificar el script startNodeManager.sh para que automáticamente ponga esa variable en esta máquina del cluster.

Ahora abrimos otro terminal y con el que ejecutamos de nuevo el arranque del servidor de aplicaciones.

cd /oracle/middleware/user_projects/domains/dev_domain
./startWeblogic.sh


Accedemos a la consola de administración para cambiar la contraseña del NodeManager http://owc1:7001/console (dev_domain-> seguridad -> general, ajustes avanzados).

Con el cambio realizado, paramos el servidor Weblogic (CTRL + C) y paramos el NodeManager en la otra consola (CTRL + C).

Procedemos al arranque de nuevo de NodeManager:

cd /oracle/middleware/wlserver_10.3/server/bin/
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh

En otra consola arranco la consola de scripting de Weblogic:

cd /oracle/middleware/oracle_common/common/bin/
./wlst.sh

Conectamos al NodeManager y arrancamos el AdminServer para verificar que todo está correctamente configurado.

wls:/offline>nmConnect('oracle_nodemg','Oracle11g','owc1','5556','dev_domain','/oracle/middleware/user_projects/domains/dev_domain') 
wls:/nm/dev_domain> nmStart('AdminServer') 
wls:/nm/dev_domain> nmDisconnect()
wls:/offline> exit()

Si todo ha ido bien, el AdminServer estará de nuevo arrancado y podremos acceder a la consola de administración: http://owc1:7001/console

Desactivando la verificación de Hostname

Dado que no vamos a usar el NodeManager en modo seguro, vamos a proceder a quitar la verificación de hostname para el AdminServer.

1. Accedemos a la consola de administración http://owc1:7001/console
2. Pulsamos sobre "Bloquear y editar" para poder realizar los cambios
3. Seleccionamos "Entorno"
4. Seleccionamos "Servidores"
5. Selecciono el AdminServer
6. Vamos a la pestaña de SSL
7. Expando las opciones Avanzadas
8. Ponemos la verificación de host a "ninguna"
9. Salvamos
10. Salvamos y activamos los cambios. 

 Los cambios no serán efectivos hasta que reiniciemos el nodo manejado del AdminServer, por ello volvemos a conectar por wlst para reiniciarlo.

cd /oracle/middleware/oracle_common/common/bin/
./wlst.sh


wls:/offline>nmConnect('oracle_nodemg','Oracle11g','owc1','5556','dev_domain','/oracle/middleware/user_projects/domains/dev_domain')
wls:/nm/dev_domain> nmKill('AdminServer')
wls:/nm/dev_domain> nmStart('AdminServer') wls:/nm/dev_domain> nmDisconnect()
wls:/offline> exit()

Con esto se termina la primera parte del tutorial, en la segunda veremos como ampliamos el dominio para incluir los productos de WebCenter y posteriormente propagamos la configuración del cluster a la máquina #OWC2

Ha salido la versión PS5 (11.1.1.6.0) de WebCenter (Actualizado)

Acaba de publicarse la versión PS5 de WebCenter, por ahora está únicamente disponible a través de e-delivery a la espera de que se haga oficial en OTN.


Novedades en las notas de versión en la nueva "Documentation Library"


Release notes:

• WebCenter Portal (link)
• WebCenter Content (link) 

En breve publicarán la lista de cambios más resumida y podremos ver los cambios efectuados en esta nueva versión.


Actualización:

• La documentación permite bajar en formato ePub y .mobi
• Novedades en JDeveloper y ADF (link)
• Novedades en WebCenter Content (link)
• Novedades en WebCenter Portal (link)

WebCenter Spaces - Changing the Maximum File Upload Size

By default WebCenter Spaces PS4 should be setup to allow uploads of files up to 2Gb. But there is a little bug that restricts the file to be only "2Mb".


Those are the steps to change the default "max-filesize" to 2Gb

1. Locate your WebCenter wlst.sh or wlst.cmd and execute it.
   
   
2. Connect to admin server with this command:
   
   connect('weblogic','<weblogic-password>','t3://<ip-admin-server>:7001')
   
   
3. Now export the metadata that defines the "uploadedFileMaxDiskSpace" parameter.
   
   exportMetadata(application='webcenter',server='WC_Spaces',toLocation='/home/oracle',docs='/oracle/webcenter/webcenterapp/metadata/webcenter-config.xml')
   
   
4. Modify the file "webcenter-config.xml" and locate the line with this parameter.
   
   <webcenter:uploadedFileMaxDiskSpace>2097152</webcenter:uploadedFileMaxDiskSpace>
   
   
5. Save the file and proceed to the upload, reconnect to wlst.sh
   
   
6. Connect again to admin server
   
   connect('weblogic','<weblogic-password>','t3://<ip-admin-server>:7001')
   
   
7. Execute the upload command:
   
   importMetadata(application='webcenter',server='WC_Spaces',fromLocation='/home/oracle',docs='/oracle/webcenter/webcenterapp/metadata/webcenter-config.xml')
   
   
8. Restart WC_Spaces managed node and is ready to test.

Usando un usuario para todas las conexiones de Site Studio for External Applications (SSXA)

En una de las aplicaciones que estoy trabajando actualmente se nos ha dado la necesidad de utilizar un único usuario para todas las consultas que se hacen en UCM.

Si estamos familiarizados con WebCenter y su integración con UCM, es tan sencillo como crear un "External App" que haga el login/password del usuario que le indicamos, y todas las operaciones que se realicen hacia el content server serán con dicho usuario.

Buceando por las librerías de SSXA, he visto que si la aplicación hace login y tenemos el usuario en sesión, éste es el usado para las consultas.


Podemos ver en la clase oracle.stellent.wcm.client.ClientApplication.java de la librería oracle.ucm.wcm.core-11.1.1.jar la siguientes líneas de código.


    Principal principal = request.getUserPrincipal();
    if (principal != null)
    {
      siteContext.setIdcContext(new IdcContext(principal.getName()));
    }


Como vemos, se recupera el usuario de sesión y con este se crea la conexión a RIDC para consultar en UCM.

Sobreescribimos la clase, creando el paquete oracle.stellent.wcm.client en mi proyecto y dentro de el la clase ClientApplication.java

Modificamos las líneas anteriores para que ponga un usuario directo, por ejemplo:

siteContext.setIdcContext(new IdcContext("mi-usuario"))


Con la clase modificada debemos seguir con la segunda parte.

Se debe alterar el classloader de la aplicación y de Weblogic para que usen nuestra nueva clase en vez de la original desplegada en la shared-library de UCM.

Copiamos el JAR oracle.ucm.wcm.core-11.1.1.jar al proyecto y vamos al menú Application - Project properties

Seleccionamos añadir nueva librería

Indicamos que se trata de una nueva

Creamos la nueva seleccionando el JAR oracle.ucm.wcm.core-11.1.1.jar y de nombre SSXA-Override con la opción de "deployed by default"

Quedando asignada en mi proyecto la nueva librería, es importante que la pongamos por encima de la librería estándar de Site Studio.

Ahora vamos a modificar el fichero weblogic.xml para que incluya la siguiente entrada:


  <container-descriptor>
    <prefer-web-inf-classes>true</prefer-web-inf-classes>
  </container-descriptor>

Modificamos también el weblogic-application.xml para que incluya la siguiente entrada:


  <prefer-application-packages>
    <package-name>oracle.stellent.wcm.client.*</package-name>
    <package-name>oracle.stellent.wcm.core.idc.*</package-name>
  </prefer-application-packages>

Con esto hemos finalizado, desplegamos la aplicación y probamos los cambios. Aunque la aplicación haga login los contenidos mostrados son aquellos a los que el usuario que pusimos arriba tiene acceso.

Speed up your JDeveloper for 64bit systems

This options will increase the performance of your JDeveloper under 64bit systems with 4 or more GB or RAM.

First locate the file jdev.conf (on my system is C:\Oracle\Middleware\jdeveloper\jdev\bin\jdev.conf)  and add this values:

#Extra tunning options

AddVMOption -XX:+AggressiveOpts

AddVMOption -XX:+UseStringCache

AddVMOption -XX:+OptimizeStringConcat

AddVMOption -XX:+ScavengeBeforeFullGC

AddVMOption -XX:+UseCompressedOops

AddVMOption -XX:+UseConcMarkSweepGC

AddVMOption -XX:+UseGCOverheadLimit

AddVMOption  -XX:MaxPermSize=800M

After that configure your JVM to use more memory

Under directory C:\Oracle\dev_home\system11.1.1.5.37.60.13\DefaultDomain\bin (or similar) the file setDomainEnv.bat (this only applies to 64 bit)

set XMS_SUN_64BIT=256

set XMS_SUN_32BIT=256

set XMX_SUN_64BIT=1024

set XMX_SUN_32BIT=512

Thats all, now your JDeveloper should be a bit faster 

:-)