14 mar 2012

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

8 mar 2012

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