WebSphere Portal 7
Primera edición
Publicado en Septiembre de 2010
© Copyright IBM Corporation 1993, 2010
Primera edición
Publicado en Septiembre de 2010
© Copyright IBM Corporation 1993, 2010
De acuerdo con el compromiso de IBM sobre accesibilidad, esta edición de la documentación del producto es accesible.
Puede guardar una copia local de este documento desde su navegador. Cada navegador tiene menús y opciones de menús diferentes. Consulte la ayuda del navegador si necesita ayuda para guardar localmente el documento.
Si desea enviar sus comentarios acerca de este documento, pulse Enviar comentarios.
IBM® WebSphere Portal está formado por aplicaciones
middleware (denominadas portlets), mashups y herramientas de desarrollo para crear y gestionar portales B2B
(business-to-business), B2C (business-to-consumer) y B2E (business-to-employee) seguros. Los portales Web permiten a los asociados, empleados y clientes elegir su experiencia de usuario, con aplicaciones personalizadas basadas en roles, contexto, acciones, ubicación, preferencias y necesidades de colaboración en equipo. El software de IBM WebSphere Portal proporciona una aplicación compuesta o una estructura mashup empresarial más las herramientas avanzadas necesarias para crear soluciones flexibles, basadas en SOA, y también posibilidades de escalado incomparables para cada organización, sea cuál sea su tamaño.
El producto Server de WebSphere Portal proporciona funciones de personalización y productividad, junto con una infraestructura de portales escalable. IBM WebSphere Portal Server es la oferta base de la familia de productos WebSphere Portal, con posibilidades de portal de empresa que permite consolidar rápidamente aplicaciones y contenido en aplicaciones basadas en roles, e incluye funciones completas de búsqueda, personalización y seguridad.
Las ofertas Content Accelerator y Enable complementan las posibilidades de IBM Lotus Web Content Management, de gestión de documentos, de búsquedas empresariales y de flujo de trabajo mejoradas, y la oferta Extend incluye potentes características de colaboración incluida la colaboración en equipo, los formularios electrónicos, la mensajería instantánea y los servicios de reconocimiento de presencia que mejoran la eficacia del portal. Las ofertas de IBM Accelerator proporcionan soluciones adicionales que se integran fácilmente al software de WebSphere Portal y pueden reducir el tiempo y el coste, ayudando a los clientes a disminuir el coste del despliegue de contenido, a automatizar los procesos empresariales, la colaboración, etc.
Un portal es un sitio web que proporciona a los usuarios un punto único de acceso a recursos basados en la web mediante la agregación de esos recursos a un lugar y sin necesidad de que los usuarios inicien la sesión en cada portlet que utilicen. WebSphere Portal también puede ofrecer contenido a los dispositivos habilitados para WAP, teléfonos i-Mode, teléfonos Smart y diferentes navegadores Web. Asimismo, el servidor de múltiples canales y el repositorio de dispositivos móviles de IBM Mobile Portal Accelerator amplía el contenido del portal de forma dinámica a más de 7.000 dispositivos móviles, con actualizaciones y dispositivos nuevos que se añaden a medida que se comercializan.
Como administrador, puede personalizar WebSphere Portal para satisfacer las necesidades de su organización, usuarios y grupos de usuarios. Puede adaptar el aspecto del portal para que se adapte a los estándares de la organización y personalizar el contenido de la página para usuarios y grupos de acuerdo con las reglas empresariales y los perfiles de usuario. Los usuarios como, por ejemplo, los business partners, los clientes o los empleados, pueden personalizar la vista del portal. Los usuarios pueden añadir portlets a las páginas y organizarlas según lo deseen, así como controlar los esquemas de colores de los portlets. Al agregar portlets a un lugar y dar a los usuarios la posibilidad de personalizar sus propios escritorios, WebSphere Portal ofrece a los usuarios los medios para realizar sus negocios de manera eficaz y muy satisfactoria.
Los portlets son una parte importante de WebSphere Portal. Como los servlets especiales de Java reutilizables aparecen como regiones definidas en las páginas del portal, los portlets ofrecerán acceso a una gran variedad de aplicaciones, servicios y contenido web. WebSphere Portal se suministra con un amplio conjunto de portlets estándar, entre ellos portlets para visualizar contenido agrupado, transformar XML y acceder a motores de búsqueda y páginas web. Están incluidos los portlets para acceder a Lotus Notes, a productos Extended y IBM Lotus Domino, IBM Lotus Sametime, IBM Lotus Quickr, IBM Lotus Connections, Microsoft Exchange y a la mensajería instantánea. También están disponibles varios portlets de terceros. Algunos ejemplos incluyen los portlets Planificación de recursos empresariales (ERP), Paneles de instrumentos, Inteligencia empresarial, Gestión del proceso y Gestión de relaciones con los clientes (CRM). Además, WebSphere Portal suministra una API que los desarrolladores de portlets pueden utilizar para crear portlets personalizados.
WebSphere Portal incluye ahora el tiempo de ejecución de Lotus Mashup, por lo que puede ejecutar widgets dentro del portal e incluso crear mashups formados tanto por portlets como por widgets. Los widgets son componentes de interfaz de usuario altamente interactivos que se escriben en JavaScript. Generalmente estos widgets tienen un ámbito muy estrecho y se pueden crear fácilmente utilizando un lenguaje basado en scripts. Los widgets son igualmente una solución para crear un mashup entre distintas tecnologías de fondo, como un servidor de portal Java basado en EE y un servidor basado en PHP.
WebSphere es la plataforma de software de integración de IBM. Incluye toda la infraestructura de middleware, por ejemplo, servidores, servicios y herramientas, necesaria para escribir, ejecutar y supervisar aplicaciones Web bajo demanda, con la potencia del sector 24x7, tanto entre plataformas como entre soluciones de productos. WebSphere proporciona un software de integración que es fiable, flexible y potente.
WebSphere proporciona software para entornos SOA (Service Oriented Architecture) que permite procesos empresariales dinámicos y conectados entre sí y ofrece infraestructuras de aplicación de gran efectividad para todas las situaciones empresariales.
IBM WebSphere Application Server ofrece una mayor agilidad a las empresas ya que proporciona millones de proveedores y arquitectos de TI con una infraestructura innovadora basada en el rendimiento, para crear, reutilizar, ejecutar, integrar y gestionar servicios y aplicaciones SOA (Service Oriented Architecture). Desde aplicaciones empresariales críticas y aplicaciones clave para toda la empresa a aplicaciones pequeñas para departamentos, WebSphere Application Server ofrece los niveles más elevados de fiabilidad, disponibilidad, seguridad y escalado.
Examine los subtemas de este apartado si desea obtener información adicional sobre nuevas funciones, componentes principales y lo que ofrece cada componente a la solución global.
En los temas siguientes se proporciona información de visión general adicional.
Conozca las novedades de IBM WebSphere Portal.
WebSphere Portal incluye nuevas características como el etiquetado y la evaluación de contenido y virtualización, al igual que mejoras en el Constructor de página, la arquitectura de temas unificada, la capacidad de servicio, la migración y la gestión de contenido, entre otras.
Se ha añadido una tarea nueva en la recopilación de registros automatizada para informes de problemas abiertos con el Soporte de IBM. Esto es adicional a la recopilación de registros disponible en las herramientas de soporte ISA/ISA-lite de IBM. La tarea ConfigEngine no requiere la instalación de ningún código adicional para poder ejecutar la recopilación de registros.
Ahora hay dos portlets de información disponibles. Estos portlets tiene la misma función, pero el origina estaba escrito con la API de IBM y el nuevo portlet se ha escrito con la API JSR 286. El nuevo portlet se puede mostrar tanto en el extremo del cliente como en el del servidor, mientras que el portlet de información original sólo se podía mostrar en el extremo del servidor.
El asistente de configuración se ha mejorado para facilitar la configuración de la seguridad de WebSphere Portal con un servidor LDAP. La nueva función del asistente de configuración intenta ahora consultar el servidor LDAP para proporcionar valores predeterminados mejores para las diferentes preguntas que se han de responder para que la configuración de seguridad LDAP se realice correctamente.
Obtenga más información acerca del asistente de configuración.
Ahora puede añadir fácilmente un blog, una biblioteca de blogs o un wiki a una página utilizando el widget Añadir contenido del tema Constructor de página. Existen mejoras adicionales para el soporte de globalización si se utiliza la nueva API de IBM Lotus Web Content Management.
Para mejorar las características de la "Captura de datos en primer error" de WebSphere Portal para una clase de problemas relacionada con el uso de la memoria de pila, la instalación de WebSphere Portal activará de forma predeterminada la recopilación de basura en modalidad verbosa en las JVM de WebSphere Portal. Esto se lleva a cabo añadiendo los valores adecuados a los argumentos de línea de mandatos de la JVM, para la JVM de WebSphere Portal contenida en WebSphere Application Server, para activar el soporte que proporciona la JVM subyacente de grabar las estadísticas relacionadas con la recopilación de basura de en un registro.
Asimismo, en las plataformas que tienen soporte, se activa la posibilidad de "registro cíclico" que intenta equilibrar la captura del suficiente historial de recopilación de basura útil para la depuración y, al mismo tiempo, conservar la cantidad real de espacio de disco que utilizan los registros. En la recopilación de basura en modalidad verbosa el registro puede aumentar sin límite alguno. Con la posibilidad de registro cíclico, el registro está limitado a un número de generaciones razonable, en el que cada generación contiene un número limitado de informes de ciclos de recopilación de basura. Dado que WebSphere Portal activa el soporte que proporciona el código de la JVM subyacente, los detalles sobre cómo funciona este soporte se describen en la guía de diagnósticos Java adecuada.
Este registro de asignaciones de gran tamaño se activa mediante el parámetro de línea de mandatos de la JVM registrado para los servidores del portal dentro de WebSphere Application Server, y se puede ajustar o desactivar editando o eliminando las series adecuadas dentro de la configuración de WebSphere Application Server. Por ejemplo, se puede rebajar el umbral de 10 MB a un valor más pequeño si sospecha que las asignaciones son de un tamaño mayor que lo esperado pero no son de 10 MB.
Obtenga más información acerca del registro y el rastreo.
Obtenga más información acerca de la guía de diagnósticos Java.
Se ha actualizado el catálogo de mensajes de modo que cualquier mensaje añadido sea más descriptivo y contenga acciones de usuario que ayuden a los usuarios y al soporte de IBM en los procedimientos de determinación de problemas. Además de las nuevas entradas, se han mejorado los mensajes de error comunes para ayudar a la determinación de problemas.
Vías de migración mejoradas. ahora la migración desde WebSphere Portal Versión 6.1 se parece más a una actualización de software. Los cambios de los esquemas de base de datos entre WebSphere Portal Versión 6.1 y 7.0 se procesan automáticamente. También puede realizar actualizaciones de base de datos localmente.
La tecnología de virtualización le permite instalar y configurar su portal y, a continuación, crear varios perfiles que puede utilizar para crear un conjunto de servidores del portal o un entorno en clúster. Un conjunto de servidores del portal es un modo sencillo de crear y mantener un entorno de servidor de alta disponible y gran escalado. Difiere del entorno en clúster en que no lo mantiene un gestor de despliegue.
Obtenga más información sobre cómo configurar un clúster.
Obtenga más información sobre cómo configurar y mantener un conjunto de servidores del portal.
El tema Constructor de página es ahora el tema predeterminado. El tema Constructor de página ha evolucionado en una nueva arquitectura unificada que da soporte a portlets y widgets, y también como una agregación de páginas del lado del servidor y del lado del cliente. Ahora los temas se pueden editar y gestionar de forma directa y completa mediante archivos HTML almacenados en el almacén de archivos WebDAV. Se han optimizado adicionalmente los estilos para mejorar el rendimiento y agilizar la personalización mediante el uso de las innovadoras características CSS3 para degradados lineales, sombras y ángulos redondeados.
Las características del Constructor de página existentes se han mejorado para dar soporte a la nueva arquitectura de Agregación de lado cliente. El widget de navegación por separadores, con menús desplegables, creación de páginas en línea y reclasificación de páginas mediante arrastrar y soltar, permite ahora conmutar páginas del lado cliente sin renovar por completo la página del navegador. La búsqueda de contenido encuentra ahora portlets y widgets que añadir a la página. Cambiar estilo y Cambiar diseño dan soporte a plantillas CSS y de diseño que se almacenan y configuran mediante WebDAV.
La suplantación permite a un usuario, tal como un especialista en soporte, acceder a la estación de trabajo de un usuario para probar una página, un portlet, etc. nuevos, y para ver los problemas mientras tienen lugar en la estación de trabajo. Para poder suplantar a otro usuario, en primer lugar debe habilitar la característica de suplantación y asignar el rol de Puede ejecutar como usuario al usuario adecuado.
Obtenga más información acerca de la suplantación y cómo habilitarla.
Ahora los usuarios pueden etiquetar o evaluar el contenido del portal y ver el etiquetado y las evaluaciones. Esto permite una mejora organización, categorización y búsquedas de contenido del portal, incluido el contenido personalizado, si está disponible en el portal. Por ejemplo, los usuarios pueden etiquetar o evaluar libros de una librería en línea.
Obtenga más información acerca del etiquetado y evaluación de contenido del portal.
Ahora WebSphere Portal proporciona un solo punto de integración con los sistemas de gestión de flujo de trabajo como, por ejemplo, IBM WebSphere Process Server, mediante la lista de tareas unificada. La Lista de tareas unificada es un portlet que agrega las tareas y actividades desde varios sistemas a una interfaz de usuario de diseño visualmente atractivo y fácilmente configurable. Los usuarios del portal acceden a la lista de tareas unificada para ver y reclamar tareas pendientes que pueden completar para que avancen los flujos de trabajo.
La lista de tareas unificada está disponible en el catálogo de WebSphere Portal Business Solutions y ofrece una integración predefinida con WebSphere Process Server. No obstante, puede personalizar la lista de tareas unificada según las necesidades de su empresa creando proveedores de tareas exclusivos, o servicios, que acceden, recuperan y dan formato a tareas desde cualquier sistema de gestión de flujos de trabajos.
Obtenga más información acerca del portlet Lista de tareas unificada.
Se puede utilizar la tecnología de virtualización para realizar una duplicación masiva de sistemas operativos idénticos que se han instalado y configurado con WebSphere Portal. VMware está totalmente soportado en esta versión de WebSphere Portal.
Obtenga más información acerca de la virtualización en Linux.
Obtenga más información acerca de la virtualización en Windows.
WebSphere Portal 7 incluye más mejoras de documentación basadas en los comentarios de los clientes. Nuestro cambio más destacado es el paso a la publicación de la documentación en la wiki de la familia WebSphere Portal.
La wiki ofrece otras ventajas en relación al centro de información. El usuario puede comentar o editar temas cuando detecta un problema o cuando ve que se puede mejorar. Anteriormente, podía enviar los formularios de comentarios a IBM. Muchos clientes se han tomado el tiempo de enviar los formularios y han proporcionado comentarios excelentes. Como resultado de los mismos, la documentación se ha actualizado y mejorado. El nuevo formato de entrega de wiki significa que otros clientes se beneficiarán de sus comentarios con mayor rapidez.
Cualquiera podrá examinar la documentación en la wiki. No obstante, para editar o comentar el contenido, debe iniciar la sesión en la wiki utilizando un ID de Lotus developerWorks. Si ya tiene un ID de Lotus developerWorks, estará preparado para iniciar la sesión y añadir comentarios o ediciones. Si no tiene un ID de Lotus developerWorks, podrá registrarse fácilmente y comenzar a utilizarlo.
La captura de pantalla resalta las funciones que debe conocer cuando utiliza la documentación.
| Número | Descripción |
|---|---|
| 1 | Las indicaciones de ruta le ayudan a orientarse y a saber rápidamente qué documentación está leyendo. |
| 2 | La Búsqueda avanzada abre una nueva pantalla en la que puede limitar su búsqueda en una categoría específica. Por ejemplo, puede limitar su búsqueda a sólo los temas de la documentación de IBM WebSphere Portal Express 7. Puede seleccionar varias categorías o una sola categoría. Utilice la búsqueda avanzada para buscar frases exactas, sólo títulos o sólo palabras completas y beneficiarse de las expresiones booleanas en su búsqueda. Después de buscar un término o una frase, puede modificar sus selecciones y parámetros y refinar adicionalmente los resultados de la búsqueda. |
| 3 | La función Traducir página utiliza la traducción automática para traducir todo el contenido de forma instantánea. A diferencia de los servidores de traducción automática, este servidor de traducciones utiliza "crowdsourcing". Si detecta imprecisiones o una traducción confusa o incorrecta, puede corregirla. Su corrección se añadirá al servidor de traducciones y se utilizará la próxima vez que se traduzca el contenido. |
| 4 | IBM continuará proporcionando contenido traducido de calidad. Puede acceder a la documentación traducida por los centros de traducción de IBM utilizando la sección Documentación traducida de IBM de la navegación. |
| 5 | Utilice estos enlaces para ver rápidamente la versión original del tema que está buscando. |
| 6 | El resaltado en la navegación le ayuda a saber dónde está el tema actual en relación con los otros temas del contenido. |
Se han vuelto a añadir a la documentación descripciones, ejemplos y valores predeterminados para las propiedades. Buscar documentación del archivo de propiedades.
Si desea configurar un sitio que esté basado fuertemente en Web Content Management, consulte la documentación de IBM Lotus Web Content Management. Este nuevo conjunto de documentación combina todo lo que debe saber acerca de WebSphere Portal y Lotus Web Content Management para configurar un sitio.
El punto de partida para la información es la documentación del producto. Anteriormente la información se proporcionaba mediante un centro de información para WebSphere Portal 7.0, la documentación del producto se proporciona en la wiki de la familia de WebSphere Portal. Existen otros sitios y recursos disponibles cuando trabajo con WebSphere Portal, pero esta consolidación pretender facilitar la búsqueda de información. También pretende introducir mejoras en el contenido y permitir que la comunidad edite y comente la documentación. Si sabe donde buscar información, ahorrará tiempo y dinero. Obtenga más información sobre recursos primarios y secundarios para documentación y contenido suplementario de WebSphere Portal y Lotus Web Content Management.
Hay dos fuentes principales de contenido: la wiki de la familia de WebSphere Portal y el sitio de soporte de WebSphere Portal. Una fuente secundaria excelente es developerWorks, donde encontrará ejemplos y artículos basados en guías de aprendizaje.
La documentación del producto que se proporciona en la wiki del separador Documentación del producto ha sido desarrollada por IBM para ayudarle a beneficiarse de las características basadas en patrones de uso y patrones de uso previstos. Puede contribuir al contenido para que quede constancia de su experiencia con el producto. El contenido de la wiki, al que se accede desde el separador Inicio, ha sido desarrollado por la comunidad, tanto interna como externamente de IBM. Con la intención de compartir las experiencias con el producto y basarse en patrones de uso y casos de uso reales. El contenido de soporte está desarrollado por IBM Support para ayudarle a evitar y diagnosticar problemas, y pretende tener tanta capacidad de respuesta como sea posible.
IBM WebSphere Portal proporciona a los usuarios una vista coherente de las aplicaciones del portal y permite a los usuarios definir conjuntos específicos de aplicaciones que se presentan en un contexto único. Dependiendo del dispositivo solicitante, la generación de este conjunto de aplicaciones variará para cumplir los requisitos del dispositivo.
Las tareas de agregación, que se repiten con cada solicitud que provenga del dispositivo, son:
WebSphere Portal también suministra la posibilidad de crear un modelo personalizado de navegación que incluye características como:
Otro aspecto de la infraestructura versátil es la posibilidad de personalizar la experiencia de portal de un usuario, utilizando "áreas de contenido" que generen contenido suscrito dependiendo del usuario y del rol del usuario en el portal.
Personalice la experiencia del usuario es uno de los objetivos principales de IBM WebSphere Portal. Se proporcionan portlets de administración y de usuario para personalizar el contenido y el aspecto y diseño de las páginas. Además, se facilitan herramientas que permiten a los expertos en la materia personalizar el contenido según las necesidades e intereses de cada visitante del sitio.
Los usuarios pueden tener una o más páginas personalizadas y acceder a cada una de ellas a través de una página diferente. Una página puede contener un grupo de páginas organizadas para un fin concreto. Cada página puede tener un conjunto diferente de portlets. Dependiendo de las autorizaciones, los usuarios pueden cambiar el aspecto de sus páginas mediante skins y diseños de página. Igualmente, la jerarquía de navegación de páginas se basa en un árbol que permite cualquier profundidad de páginas anidadas.
El usuario o administrador puede configurar el contenido de cada página. Los administradores pueden especificar que determinados portlets sean obligatorios para que los usuarios no puedan moverlos o eliminarlos de las páginas. Cada página puede tener su propio esquema de colores y su propio diseño de columnas.
Un administrador puede conceder o revocar el acceso para personalizar una página total o parcialmente a otros administradores o usuarios. El administrador puede determinar los derechos de los usuarios para modificar una página. Los administradores pueden controlar la autorización de edición que otros administradores tienen en una página y su contenido. Esto se ha diseñado para ayudar a las organizaciones a aplicar políticas y coherencia, y a crear portales específicos de región con algunos contenidos gestionados de forma central. Este control se explica mejor a través de un ejemplo.
El primer administrador puede determinar que una página tendrá tres columnas y que ningún otro administrador podrá modificar la disposición de las columnas. Otro administrador con menos derechos de acceso no puede modificar la disposición de las columnas pero puede añadir portlets a estas columnas. La figura siguiente muestra una página dividida en tres columnas. Los administradores pueden añadir portlets a estas columnas.
El segundo administrador añade un portlet de acción de bolsa a la columna uno y un portlet de noticias de empresa a la columna dos. Este administrador desea que estos portlets estén disponibles para todo el mundo y no desea que se eliminen. Sin embargo, el administrador puede añadir portlets a las columnas. Por lo tanto, los portlets están bloqueados y otros administradores con menos accesos no los pueden eliminar. La figura siguiente muestra un ejemplo del aspecto que debería tener la autorización en cascada de otro administrador.
WebSphere Portal utiliza html, hojas de estilo en cascada, imágenes y otros artefactos de diseño Web estándar para definir el diseño de las páginas. También se pueden utilizar JSP (Java Server Pages) y otras técnicas dinámicas del lado del servidor para definir el diseño de un sitio. Puede añadir o modificar elementos para controlar los aspectos visuales de WebSphere Portal, añadir elementos de marca específicos de la empresa u obtener un esquema de colores y un estilo visual diferentes. El sistema para definir skins y temas de color soporta varios skins por tema, elementos de marca adicionales, estilos de navegación y hoja de estilo en cascada dinámicas e independientes del navegador.
Los skins y temas se pueden aplicar a una página, no sólo a todo el producto. Los diferentes skins se pueden aplicar también individualmente a portlets, para que el portal se pueda ajustar a las necesidades de cualquier usuario. Mediante el uso de un tema diferente para cada página, una instalación única puede dar la apariencia de soportar muchos portales virtuales.
Todos los elementos visuales de WebSphere Portal, incluidos la cabecera, las áreas de navegación, los gráficos, las áreas de títulos de portlets y las hojas de estilos, se pueden cambiar para darle a WebSphere Portal un aspecto personalizado. Los formatos de archivo estándar, tales como JPEG, GIF, CSS y JSP, se utilizan para definir el aspecto y el diseño.
La estructura de la carpeta de instalación del componente contiene carpetas denominadas "skin" y "theme," con carpetas "html," "wml," y "chtml". Estas carpetas contienen la mayoría de los archivos utilizados para definir la estructura básica de la página de presentación, sus esquemas de color y decoraciones de portlet. Los diseñadores de portales pueden copiar estas carpetas y modificar su contenido para crear un aspecto personalizado. El portlet de administración de temas registrará los nuevos archivos.
Puede modificar la ubicación de los portlets individuales en una página con la función de arrastrar y soltar. Para cambiar la disposición de un portlet en una página, pulse la barra de título del portlet y luego arrastre el portlet a una ubicación nueva de la página. También puede añadir portlets a la página para facilitar la personalización de páginas arrastrando los portlets de la Paleta de portlets a la página.
El componente Personalization selecciona contenido para los usuarios en función de la información de sus perfiles y la lógica empresarial. Con los recursos Personalization, los expertos pueden seleccionar contenido que se adecue a las necesidades y los intereses de cada visitante del sitio. Estas herramientas basadas en la Web ayudan a las empresas a impulsar fácil y rápidamente el contenido creado por los expertos en la materia y en empresa. Personalization incluye tres componentes de personalización básicos:
Perfil de usuario: información sobre los usuarios del sitio, incluidos los atributos de usuario
Modelo de contenido: define los atributos de contenido, tales como las descripciones de productos, artículos y demás información
Tecnología de emparejamiento: motores que emparejan a los usuarios con su contenido correcto; incluye filtros, reglas, motores de recomendación o combinaciones de los tres.
Los componentes Personalization y WebSphere Portal comparten un perfil de usuario y un modelo de contenido comunes. El modelo se basa en las clases de interfaz de las infraestructuras de recursos de WebSphere. Esto significa que las reglas de personalización se pueden añadir fácilmente a los portlets para seleccionar el contenido y destinarlo a los usuarios registrados de WebSphere Portal.
Personalization clasifica los visitantes del sitio en segmentos y, a continuación, asigna contenido relevante a cada segmento. Los expertos de la empresa crean las reglas para clasificar a los usuarios y seleccionar el contenido utilizando herramientas basadas en la web.
Personalization también incluye un motor de recomendación que proporciona capacidades de filtrado de colaboración. El filtrado de colaboración utiliza técnicas estadísticas para identificar grupos de usuarios con intereses y comportamientos similares. Se pueden sacar conclusiones sobre aquello en lo que esté interesado un determinado usuario, según los intereses de otros miembros del grupo.
Las nuevas herramientas de gestión de campaña también se incluyen con Personalization. Las campañas son conjuntos de reglas de empresa que funcionan conjuntamente para llevar a su fin un objetivo empresarial. Por ejemplo, un gestor de recursos humanos desea ejecutar una campaña para animar a sus empleados a que se inscriban en un plan de adquisición de acciones. El gestor de recursos humanos definiría un conjunto de reglas destinadas a cumplir este objetivo empresarial. Las campañas tienen fechas de inicio y de finalización y se pueden basar en páginas web o correo electrónico. Se pueden realizar varias campañas simultáneamente o darles prioridad.
Los servicios de creación de perfiles implícitos pueden recopilar información en tiempo real sobre las acciones del visitante del sitio y construir reglas empresariales de personalización mediante estos datos. Para analizar la eficacia del sitio y sus estrategias de personalización, el servidor proporciona informes para el propietario empresarial del sitio. De esta forma se ayuda a la empresa a medir la eficacia de las reglas empresariales y de las campañas a la hora de cumplir sus objetivos.
El sistema de plantillas de páginas, temas, skins y representación de portlets está completamente habilitado para su internacionalización y para que personas discapacitadas puedan acceder a él. En el caso de los portales accesibles globalmente, WebSphere Portal busca y selecciona las páginas JSP correctas dependiendo del navegador de destino y de sus valores de país e idioma.
IBM WebSphere Portal viene con sitios web de Internet y de intranet previamente construidos y de muestra que puede explorar para obtener más información acerca de la creación y gestión de distintos tipos de contenido, o los puede utilizar como una plantilla para modernizar el desarrollo de su propio portal. También puede utilizar el Asistente de nuevo sitio para generar su propio sitio de portal.
Los sitios de intranet y de Internet de muestra no se instalan automáticamente cuando se instala WebSphere Portal, pero puede añadirlos cuando se haya completado la instalación ejecutando la tarea configure-express antes de configurar la base de datos del portal, el registro de usuarios, la raíz de contexto la seguridad. Para obtener más información, consulte las instrucciones sobre cómo configurar un servidor autónomo o un servidor en clúster para su plataforma concreta.
Utilice la plantilla de sitios de intranet como un punto de partida para crear su propio sitio de empleado. Las páginas de Hogar, Trabajo y Recursos vienen llenas de contenido de marcadores, que puede utilizar tal y como viene o bien personalizar. La lista de portlets de uso sencillo que se incluye le permite organizar y gestionar anuncios, noticias, sucesos, FAQ y enlaces.
Utilice esta plantilla de sitios de Internet para obtener una revitalización en la construcción de un sitio web en el que los clientes puedan obtener más información acerca de ofertas de productos, promociones de marketing y noticias de la empresa.
Hay más ejemplos de contenido disponibles en el Catálogo de soluciones empresariales de IBM WebSphere Portal.
Utilice el Asistente de nuevo sitio para generar su propio sitio, sin necesidad de disponer de habilidades de desarrollo de portales ni de depender de asistencia por parte de un administrador. Tan sólo seleccione la plantilla de un sitio desde las muestras disponibles, elija el aspecto que desee y, a continuación, deje que el asistente haga el resto.
El asistente crea automáticamente sitios nuevos como portales virtuales; sin embargo, los administradores y desarrolladores pueden ampliar el asistente para crear todo tipo de sitios de portal. Los desarrolladores de portal también pueden ampliar el Asistente de nuevo sitio creando plantillas de sitio personalizado y, a continuación, añadiéndolas al asistente.
Descargue el Asistente de nuevo sitio desde el Catálogo de soluciones empresariales de IBM WebSphere Portal. El contenido del paquete incluye el archivo del portlet .war (Archivador de la aplicación web), archivos y directorios de soporte, e instrucciones detalladas en un archivo .pdf. Después de desplegar el asistente, tiene que añadir el portlet a una página a la que los usuarios puedan acceder. Para obtener más información, consulte el archivo .pdf que viene con el asistente.
Los portlets son una parte importante de IBM WebSphere Portal. Los portlets son pequeñas aplicaciones que se desarrollan, despliegan, gestionan y visualizan de forma independiente. Los administradores y los usuarios componen páginas personalizadas seleccionando y ordenando los portlets, lo que da como resultado páginas web personalizadas.
WebSphere Portal incorpora un gran conjunto de portlets estándar. Para obtener la información más reciente sobre portlets, incluidos los portlets más actuales que se pueden descargar, visite el catálogo de soluciones de IBM WebSphere Portal. Como alternativa, puede consultar Desarrollo de portlets para obtener información sobre la creación de portlets personalizados.
Los portlets son algo más que simples visualizaciones de sitios Web existentes. Un portlet es una aplicación completa que sigue un diseño estándar modelo-visualización-controlador. Los portlets tienen varios modos de visualización y estados, además de capacidades para mensajería y sucesos.
Los portlets se ejecutan en el interior del servidor de aplicaciones, similares en ejecución a los servlets de un servidor de aplicaciones, pero están agregados a una página web completa mediante el servidor de WebSphere Portal. El contenedor de portlets proporciona un entorno de tiempo de ejecución en el que se crean instancias de los portlets, se utilizan y finalmente se destruyen. Los portlets dependen de la infraestructura de WebSphere Portal para acceder a la información de perfiles de usuario, participar en los sucesos de acción y de ventana, comunicarse con otros portlets, acceder a un contenido remoto, buscar credenciales y almacenar datos continuos.
Normalmente, los portlets se administran más dinámicamente que los servlets. Por ejemplo, las aplicaciones de portlet compuestas de varios portlets se pueden instalar o eliminar mientras el componente WebSphere Portal está en ejecución. Un administrador puede cambiar los valores y los derechos de acceso de un portlet mientras WebSphere Portal esté en ejecución, incluso en un entorno de producción.
Las modalidades de portlet permiten a los portlets mostrar una interfaz de usuario distinta en función de la tarea que deba realizar. Un portlet tiene varias modalidades de visualización que pueden invocarse mediante iconos situados en la barra de título del portlet: Ver, Ayuda, Editar, Configurar y Edición de valores compartidos.
Un portlet se muestra inicialmente en modalidad de vista. Como el usuario interactúa con el portlet, el portlet puede mostrar una secuencia de estados de visualización, como por ejemplo formularios y respuestas, mensajes de error y otros estados específicos de la aplicación. La modalidad Ayuda proporciona asistencia al usuario. La modalidad de edición permite al usuario cambiar los valores del portlet. Por ejemplo, un portlet meteorológico puede ofrecer una página de edición para que los usuarios especifiquen una ubicación. Los usuarios deben iniciar la sesión en WebSphere Portal para acceder a la modalidad Edición. La modalidad de configuración cambia el aspecto predeterminado del portlet para todas las instancias del portlet y la Edición de valores compartidos cambia el aspecto del portlet en una página específica.
Cada modalidad del portlet se puede mostrar en el estado normal, maximizado o minimizado. Cuando un portlet está maximizado, aparece en todo el cuerpo de la página, sustituyendo la visualización de otros portlets. Cuando un portlet está minimizado, de manera predeterminada, sólo la barra de título del portlet aparece en la página.
La especificación de portlets Java es una especificación que satisface los requisitos relacionados con las tareas de agregar, personalizar, presentar y de seguridad de los portlets que se ejecutan en un entorno del portal.WebSphere Portal da soporte a los estándares de portlets JSR 168 y JSR 286. Para obtener más información sobre la API de portlet estándar, consulte el tema sobre API de portlet estándar.
WebSphere Portal permite que los portlets se comuniquen entre sí. La comunicación de los portlets se puede utilizar para intercambiar datos entre portlets. Esto hace que el portal sea más fácil de utilizar.
El portal da soporte a sucesos que se definen en la especificación de JSR 286. Permite que los administradores conecten portlets utilizando la interfaz de usuario del portal.
Por ejemplo, un portlet puede mostrar información sobre cuentas, y un segundo portlet muestra información sobre transacciones que se hayan producido en una de las cuentas a lo largo de los últimos 30 días. Para ello, el portlet de transacciones deberá obtener la información de cuentas adecuada cuando muestre los detalles de la transacción. Esto se lleva a cabo mediante la comunicación entre los dos portlets, utilizando sucesos tal y como se describe en la especificación de JSR 286. En este ejemplo, el portlet de cuentas define un suceso de publicación en su descriptor de portlet. El portlet de transacción define este suceso como un suceso de proceso en su descriptor de portlet. Mediante el uso de la interfaz de usuario del portal, ahora se pueden conectar esos dos portlets entre sí. Después de realizar esto, cuando el portlet de cuentas arroje un suceso, el portlet de transacción recibe dicho suceso y muestra información sobre las transacciones de esta cuenta.
Los servicios de portlet se utilizan para proporcionar funciones comunes a los portlets. Cada servicio de portlet tiene su propia interfaz específica de servicio para la funcionalidad que ofrece. WebSphere Portal da soporte a servicios de portlet para portlets estándar. Los portlets estándar utilizan una búsqueda JNDI para recuperar un objeto PortletServiceHome, que se utiliza para recuperar una implementación de servicio de portlet.Un servicio de portlet se puede invocar solamente mediante el código situado dentro de un portlet. Para obtener más información sobre servicios de portlet del portal, consulte el tema sobre Servicios de portlet.
WebSphere Portlet Factory está incluido con WebSphere Portal y proporciona una selección de constructores sólida que sobrealimentan el proceso de desarrollo de portlets sin escribir código. La rápida tecnología de desarrollo de aplicaciones de WebSphere Portlet Factory habilita que la creación de portlets se realice entre un 40% y 70% más rápido que usando métodos de desarrollo de J2EE tradicionales. Con WebSphere Portlet Factory, puede desarrollar y desplegar de forma rápida portlets personalizados orientados al servicio y aplicaciones de estilo Web 2.0 enriquecidas e interactivas con funciones como arrastrar y soltar, edición en línea, búsqueda con tecleo anticipado y funcionalidad de renovación de página inteligente.WebSphere Portlet Factory transforma datos operativos en información sobre la empresa de gran valor, integrando los datos desde una gran variedad de orígenes de datos, repositorios y aplicaciones empresariales empaquetados que incluyen SAP, Siebel, PeopleSoft, Lotus Domino, servicios web y REST y bases de datos relacionales líderes mediante una biblioteca de conector enriquecida y preconstruida. La integración de WebSphere Portal nativa permite la creación de aplicaciones compuestas con funciones de colaboración incluidas que facilitan la resolución de problemas en tiempo real.
Con el uso de la funcionalidad de creación de perfiles dinámica y patentada de WebSphere Portlet Factory, los desarrolladores pueden respaldar de forma sencilla la personalización de portlets llevada a cabo por usuarios empresariales mediante la personalización y pueden crear aplicaciones dinámicas y dirigidas a un pequeño grupo que varían en el contenido de los portlets en función del rol de los usuarios, de la geografía, etc. Las aplicaciones construidas con WebSphere Portlet Factory pueden desplegarse en entornos de ejecución múltiple para que proporcionen la experiencia de usuario adecuada basada en los clientes objetivo, incluidos WebSphere Portal, Mashup Center, Lotus Notes y Expeditor y WebSphere Application Server.
Las aplicaciones de WebSphere Portlet Factory son estándares que se basan y que cumplen con estándares de portlets, incluidos JSR 168 y JSR 286.
Los usuarios pueden asignar códigos y evaluaciones al contenido, y también verlos. La asignación de códigos y evaluación permite a los usuarios una mejor organización, categorización y hallar el contenido en el portal. Esto incluye Web Content Management y contenido personalizado. Por ejemplo, los usuarios pueden asignar códigos y evaluaciones a libros de una librería.
Se suministra un conjunto de bibliotecas preinstaladas de contenido web que le permiten añadir funciones de blogs y wikis a sus sitios web. Utilice los blogs, las bibliotecas de blogs y las wikis para poner presión en el poder de la comunidad y cambiar la forma en que se trabaja.
Los blogs son una herramienta estupenda a utilizar cuando se desea generar ideas en torno a un tema único. Puede utilizar los blogs para su propio trabajo indidual o para obtener comentarios sobre un concepto único a partir de un equipo mayor. Las bibliotecas de blogs llevan los blogs al siguiente nivel. En lugar de crear un blog por tema, puede utilizar bibliotecas de blogs para realizar el seguimiento de varios temas en una ubicación centralizada. Las wikis también le proporcionan otra alternativa para el contenido de creación. La edición en línea simple, incluida la inserción de imágenes y enlaces, hace que las wikis de creación sean rápidas y sencillas. También puede asignar puntuación y códigos a contenido de blogs y wikis.
Los blogs, las bibliotecas de blogs y las wikis utilizan las bibliocas de plantillas proporcionadas por IBM Lotus Web Content Management. Cada blog, biblioteca de blog y wiki tiene su propia biblioteca. La jerarquía de página que se proporciona para estos componentes es la común definida por las bibliotecas de plantillas de Web Content Management.
Un portal proporciona acceso al contenido, los datos, y los servicios localizados en toda la empresa. Estos servicios no sólo incluyen los conectores y portlets predefinidos sino también las herramientas para crear conectores y portlets adicionales.
Los sistemas ERP (Enterprise Resource Planning; planificación de recursos de la empresa) y CRM (Customer Relationship Management; gestión de relaciones con los clientes) son excelentes candidatos para los portlets porque un acceso eficaz y personalizado a estas funciones proporcionan un considerable rendimiento de las inversiones del portal. IBM proporciona plug-in para aplicaciones de empresa, mediante JCA (Java Connector Architecture).
JCA es una arquitectura estándar para integrar aplicaciones Java 2 Enterprise Edition (J2EE) con sistemas de información de empresas que no sean bases de datos relacionales. Cada uno de estos sistemas proporciona las API originales para identificar una función a la que llamar, especificando sus datos de entrada y procesando sus datos de salida. El objetivo de la JCA es proporcionar una API independiente para codificar estas funciones.
JCA también define una Interfaz de proveedor de servicios (SPI) estándar para integrar las facilidades de gestión de la conexión, la seguridad y las transacciones de un servidor de aplicaciones con las de un gestor de recursos transaccional. Por lo tanto, JCA es un método basado en estándares para gestionar conexiones, transacciones y acceso a la seguridad en sistemas de aplicación de empresas. Los conectores JCA de IBM proporcionan acceso a sistemas como SAP, PeopleSoft, J.D. Edwards, Oracle Enterprise Edition, CICS, IMS y Host-on-Demand. Gracias a la adquisición de CrossWorlds, IBM también tiene previsto desarrollar e integrar los conectores JCA con muchos otros sistemas.
Rational Application Developer ofrece un desarrollo completo y un entorno de prueba de unidades para aplicaciones que utilicen conectores JCA, servicios Web, y microflujos. Las herramientas de Rational Application Developer incluyen el soporte para Web Service Definition Language (WSDL), versiones del desarrollador de los conectores, Web Services Invocation Framework (WSIF) y el motor de microflujo.
Las características de colaboración en IBM WebSphere Portal se proporcionan a través de Domino. Domino and Extended Products son el servidor Domino Enterprise y IBM Lotus Sametime.
Los portlets son el mecanismo mediante el cual los productos de servidor Domino se integran completamente en WebSphere Portal. Portlets de productos Extended y Domino proporciona un directorio en línea con reconocimiento de personas y herramientas integradas para gestionar reuniones en línea. Todas estas funciones de colaboración ayudan a las personas de la organización a trabajar conjuntamente y a compartir información en línea para alcanzar los objetivos de la empresa. Un portal de colaboración puede mejorar la capacidad de respuesta, la innovación, las competencias y la eficacia de la organización.
Para obtener información sobre versiones con soporte de IBM Lotus Domino y IBM Lotus Sametime, consulte los requisitos del sistema detallado de WebSphere Portal.
Los ejemplos de todos los Portlets de productos Extended y Domino se proporcionan en las páginas de Colaboración y Mensajería. Los portlets se instalan con WebSphere Portal y se despliegan de forma automática; ello requiere que el administrador lleve a cabo sólo una serie de tareas de servidor u otras tareas de configuración para que los usuarios puedan beneficiarse de un conjunto de aplicaciones integradas de colaboración.
Los Portlets de productos Extended y Domino incluyen:
Los usuarios puede ver información de contacto y demás información típica de la tarjeta de visita sobre un usuario registrado mostrando su tarjeta personal. La tarjeta personal está disponible por medio de un amplio abanico de componentes del portal, incluyendo integración con Domino y Sametime, aplicaciones compuestas, personalización y creación de contenido web. Para ver la tarjeta personal, mueva el cursor sobre un nombre de persona activo (subrayado) y seleccione Pulsar para tarjeta personal.
Si Lotus Sametime está habilitado en la configuración del portal, los usuarios podrán trabajar con el conjunto completo de funciones de reconocimiento de personas, que incluye mensajería instantánea y compartimiento de aplicaciones mediante reuniones electrónicas (e-meetings). Los nombres de persona aparecen como reconocimiento - con un indicador de estado de conexión dinámico. Pulse Perfil para mostrar información completa sobre la persona. Estas son algunas de las acciones adicionales:
Si elige no habilitar Lotus Sametime en su configuración de portal, la funcionalidad de reconocimiento de personas está más limitada. Los nombres de personas aparecen como hiperenlaces, pero sin ningún icono de reconocimiento de personas junto a cada nombre, y las acciones disponibles para la tarjeta personal están limitadas para aquellos que sean nativos de WebSphere Portal.
Las funciones de accesibilidad permiten a los usuarios con discapacidades físicas (por ejemplo, una movilidad restringida o una visión limitada) utilizar los productos de software sin problemas.
Esta versión de IBM WebSphere Portal:
Si fuera necesario, la documentación de las funciones específicas del producto contiene información adicional sobre accesibilidad.
Consulte el IBM Human Ability and Accessibility Center para obtener más información sobre este compromiso que IBM tiene con la accesibilidad:
Conozca las características disponibles en las versiones anteriores de IBM WebSphere Portal que ya no están disponibles en esta versión o en versiones futuras.
A medida que estén disponibles, se proporcionarán enlaces de información adicional que sirven de ayuda para la migración dejando de lado las características que ya no se utilizan.
Si había utilizado CPP con Exchange, ahora puede utilizar los portlets de Exchange.
Si había utilizado CPP con Domino, ahora puede utilizar el portlet iNotes.
Si ha estado utilizando el portlet RSS o el portlet Lector de canales de información de IBM, ahora puede utilizar el Portlet Canal de información sindicado de IBM para WebSphere Portal. También, si no, puede descargar el portlet RSS y el portlet Lector de canales de información de IBM de IBM WebSphere Portal Business Solutions Catalog.
Si había utilizado CPP con Exchange, ahora puede utilizar los portlets de Exchange.
Si había utilizado CPP con Domino, ahora puede utilizar el portlet iNotes.
IBM WebSphere Portal proporciona opciones de despliegue
flexibles, desde una nueva instalación de prueba del producto donde puede examinar y probar funciones hasta
una instalación de producción de alta disponibilidad y escalabilidad. Revise la información de planificación
para obtener más detalles acerca de los requisitos de hardware y software, la alta disponibilidad, la
escalabilidad, las topologías soportadas y más información. Seleccione el sistema operativo y luego
seleccione el patrón de instalación que refleje mejor las necesidades de su empresa.
Antes de instalar IBM WebSphere Portal en un entorno de producción, debe evaluar sus necesidades de hardware y software, las posibles configuraciones de base de datos, las opciones de seguridad y las opciones de servidor LDAP. Si ignora este paso importante los resultados pueden ser imprevisibles y pueden producirse retrasos de un coste elevado.
Antes de instalar IBM WebSphere Portal, revise los requisitos de hardware y software para asegurarse de que tiene las versiones soportadas del software de requisitos previos y de correquisitos, así como el hardware necesario.
http://www.ibm.com/support/docview.wss?uid=swg27007791
Las limitaciones y los problemas conocidos están disponibles en la página de soporte. Los enlaces de la base de conocimiento de soporte están integrados en el Information Center para garantizar que se dispone de la información más actual. Antes de empezar el proceso de instalación, consulte el sitio web de soporte de IBM para obtener la información más actualizada sobre limitaciones y problemas conocidos. Utilice las siguientes consultas dinámicas para buscar la información más reciente sobre este release.
Los enlaces siguientes devolverán la lista más actualizada de notas técnicas para el área identificada. Si no se ha publicado una nota técnica sobre un área de tema dado, el enlace no devolverá ninguna nota técnica y se le indicará que refine la búsqueda.
También puede realizar búsquedas en el sitio de soporte directamente desde el Information Center. Consulte el tema Búsqueda de una solución en el sitio web del centro de soporte de IBM.
Esta declaración de soporte propone revisar la definición de "soportado" y "no soportado" con respecto a los diversos productos de los que depende IBM WebSphere Portal para funcionar correctamente.
WebSphere Portal necesita que se utilicen varios productos adicionales para funcionar con normalidad. Concretamente, necesita WebSphere Application Server, una base de datos, un repositorio para la información de usuario (normalmente, un LDAP) y otros productos, en función de los requisitos específicos del cliente.
Durante la prueba de un nuevo release, el desarrollo suele probar WebSphere Portal con una lista prescrita de dichos productos adicionales. Estos productos se han diseñado como "Productos soportados" en los requisitos de hardware y software del release.
Dado que la lista de "Productos soportados" no puede describir todas las configuraciones posibles que un cliente puede tener que utilizar, a algunos clientes les preocupa el nivel de soporte que se proporcionará a las configuraciones que no se hayan designado específicamente como "Soportadas". Este documento pretende aclarar el nivel de soporte que se puede esperar, como regla general, para el release actual con diversas combinaciones de productos dependientes.
Existen tres (3) categorías de soporte para productos colaterales en WebSphere Portal. Son las siguientes: "Productos soportados", "Nuevas versiones y releases de los productos soportados" y "Productos no soportados". A continuación, se detallan la definición y la declaración de soporte correspondientes a cada categoría:
Los productos de esta categoría están soportados en cuanto a los términos del Acuerdo de licencia de WebSphere Portal. Los PMR (Problem Management Records) los aceptará el centro de soporte de IBM de acuerdo con las condiciones del Acuerdo de licencia de WebSphere Portal.
Los productos que pertenecen a esta categoría suelen ser nuevos releases o niveles de arreglo de un producto que ya pertenece a la categoría de "Producto soportado" o de un producto conforme a una API estándar que WebSphere Portal soporta (como, por ejemplo, un servidor LDAP). Algunos ejemplos específicos pueden incluir un nivel de arreglo más reciente del sistema operativo, un fixpack de WebSphere Application Server (WAS) más reciente que el nivel del fixpack "Soportado", un fixpack de IBM Java (JVM), un nuevo fixpack o release de DB2 o un servidor LDAP actualizado.
Para productos que pertenecen a esta categoría, el soporte es el siguiente:
Para productos de IBM, tales como IBM Directory Server o Domino LDAP, IBM DB2, IBM JDK (JVM) y WebSphere Application Server, WebSphere Portal soportará totalmente las actualizaciones de los fixpacks, releases y versiones que no cambien de forma significativa las interfaces u otro soporte subyacente de los que WebSphere Portal depende para su funcionalidad. En el caso de que (y cuando) se envíe un release más reciente de uno de estos productos que WebSphere Portal no puede albergar, este hecho se anotará como se describe en el próximo apartado titulado "Productos no soportados". Observe que para que WebSphere Portal soporte una actualización de una base de datos o un producto LDAP, WebSphere Application Server debe soportar también dicha actualización.
Para productos que no pertenecen a IBM, el equipo de soporte hará los esfuerzos comerciales que estén a su alcance para dar soporte a productos que pertenecen en esta categoría. El soporte aceptará informes de problemas (PMR) para los releases correspondientes utilizando estos productos no probados. Si el soporte puede recrear el problema del que se ha informado utilizando una versión "Soportada" del producto, se intentará solucionar el problema.
Si el soporte no puede recrear el problema con una versión "Soportada" del producto y no es capaz de solucionar el problema en la versión sin probar del producto en cuestión, el soporte se dirigirá a la organización de soporte de dicho producto para que resuelva el problema. Hay que tener en cuenta que pueden ser necesarios varios niveles de implicación del cliente para manejar este proceso en el caso de productos que no sean de IBM.
Si la organización de soporte para dicho producto no verificado no es capaz de resolver el problema, el soporte considerará que la versión, el release o el nivel del fixpack del producto no verificado es ahora un "Producto no soportado".
WebSphere Application Server tiene una declaración de soporte similar, que se puede encontrar en la Web.
WebSphere Portal puede reconocer los cambios del WebSphere Application Server subyacente. Se puede realizar sin ningún problema la actualización a un nuevo nivel de fixpack del servidor de aplicaciones e incluso se recomienda hacerlo (por ejemplo, de WebSphere Application Server versión 7.0 a 7.0.x) siempre y cuando todos los arreglos necesarios de WebSphere Application Server estén integrados en dicho fixpack o mediante la aplicación de un arreglo temporal específico para ese nivel de mantenimiento. No obstante, la actualización de una versión de WebSphere Application Server a la siguiente (por ejemplo, de la versión 6.1 a la 7.0) resulta bastante complicado si no se realiza en el contexto de una migración de versiones y no se debe probar en un sistema "in situ". Por ejemplo, una instancia existente de WebSphere Portal versión 7.0 instalada y funcionando en WebSphere Application Server versión 7.0 no se podrá migrar correctamente a WebSphere Application Server versión 7.1 simplemente utilizando las herramientas de migración de WebSphere Application Server. Estos intentos pueden resultar en un sistema no funcional. Consulte el soporte de IBM WebSphere Portal para obtener más información sobre dichos casos de ejemplo, si fuese necesario.
El soporte para LDAP se divide en dos (2) categorías:
Es importante comprender las limitaciones de caracteres para los ID de usuario y contraseñas debido a que se utilizan en todo el sistema para proporcionar acceso y proteger el contenido. Las limitaciones de caracteres que se proporcionan aquí se aplican al administrador de IBM WebSphere Portal, al administrador de IBM WebSphere Application Server, al administrador de base de datos, al administrador del servidor LDAP y a los ID de usuario. Los servidores de base de datos y LDAP pueden tener limitaciones más restrictivas que las que se proporcionan aquí. Por lo tanto, puede consultar las restricciones en la documentación del producto de base de datos y servidor LDAP. Si no se definen correctamente los ID de usuario y las contraseñas durante el proceso de instalación se pueden producir errores de instalación. Asimismo, es posible que su empresa tenga requisitos de ID de usuario y contraseña más restrictivos que también deba cumplir.
Cuando un usuario inicia una sesión como usuario o cuando el administrador lo registra como usuario, deberá completar el formulario de información del usuario. En este formulario, no escriba caracteres a los que puede que no se les dé soporte. Independientemente de los caracteres que puede especificar en el formulario de información del usuario, los ID de usuario y las contraseñas están limitados a los caracteres válidos descritos aquí. Puede especificar otros caracteres en los campos Nombre y Apellidos.Si la política de la empresa es más restrictiva, puede proporcionar dicha información a los usuarios en la ayuda del formulario de inscripción o como una ayuda en línea directamente en el formulario.
La siguiente tabla contiene una lista de los campos obligatorios del formulario de información del usuario y de los caracteres soportados.
| Información del usuario | Caracteres válidos | Caracteres no soportados |
|---|---|---|
| ID de usuario | Nota: Los únicos caracteres soportados en IBM i son los caracteres en minúsculas, los caracteres en mayúsculas, los números y el signo de subrayado.
|
Sólo se permiten caracteres ASCII. Otras restricciones: El ID de usuario no puede contener espacios. Por ejemplo, nombre usuario. Los ID de usuario no pueden tener más de 200 caracteres.
Si especifica caracteres no soportados durante la instalación, recibirá un mensaje de error que indica que el carácter no es válido. Por ejemplo,
"Se ha encontrado el carácter especial [@] en el campo de ID de usuario administrativo. Vuelva a especificar el ID de usuario administrativo".
Importante: Recibirá un mensaje de error distinto si especifica caracteres no soportados al crear usuarios mediante el portlet Gestionar usuarios y grupos.
|
| Contraseña / Confirmar contraseña | Nota: Los únicos caracteres soportados en IBM i son los caracteres en minúsculas, los caracteres en mayúsculas, los números y el signo de subrayado.
|
Signos diacríticos, como la diéresis, y caracteres DBCS no están permitidos. Otras restricciones: La contraseña no puede contener espacios. Por ejemplo, contra seña. Las contraseñas no pueden tener más de 128 caracteres.
Atención: El inicio de sesión fallará si la contraseña contiene caracteres no soportados, incluidos los caracteres DBCS. Esto será así incluso si un usuario es admitido con éxito utilizando una contraseña que contenga caracteres DBCS.
Si especifica caracteres no soportados durante la instalación, recibirá un mensaje de error que indica que el carácter no es válido. Por ejemplo, "Se ha encontrado el carácter especial [@] en el campo de contraseña. Vuelva a especificar la contraseña." |
| Nombre | Todos los caracteres | No disponible |
| Apellido | Todos los caracteres | No disponible |
Cada operación tiene necesidades de preparación exclusivas para garantizar que la instalación sea satisfactoria. Antes de continuar con el asistente de instalación, asegúrese de que ha preparado adecuadamente el sistema operativo y de que dispone de todos los requisitos previos y correquisitos de software y de hardware necesarios.
Los diagramas de topología le ayudan a visualizar distintas configuraciones que puede configurar para dar soporte a varios requisitos de carga de sistemas y de usuarios. Los diagramas de topología son representativos de configuraciones básicas.
La topología de servidor único muestra una instalación sencilla a efectos de demostración, prueba, o entorno de desarrollo. La topología autónoma ilustra una configuración distribuida. Las topologías en clúster ilustran configuraciones de hardware más sólidas y de más carga y las topologías de Web Content Management ilustran cómo dan soporte distintas configuraciones de hardware a varios requisitos de carga de creación y de sistema. Para aumentar la capacidad y la disponibilidad, los servidores de portal múltiples se pueden agrupar en clúster utilizando IBM WebSphere Application Server Network Deployment, donde los portales comparten una configuración común y la carga se distribuye uniformemente en todas las instancias de clúster. Esta topología de alta disponibilidad y migración tras error ilustra WebSphere Portal en un entorno de producción más complejo.
Una instancia única de IBM WebSphere Portal proporciona un servidor de aplicaciones completamente funcional y un sitio web que es capaz de servir a una comunidad de usuarios de pequeña a mediana. De forma inicial, se configura una única instancia para utilizar una base de datos interna basada en Derby que no sea adecuada para uso de producción y que deba sustituirse por una base de datos de clase empresarial de.
Los despliegues de servidor único son ideales para el desarrollo, las pruebas, las demostraciones y la educación, y, como ya se mencionara, para algunos pequeños sitios de producción. Un servidor único, sin embargo, presenta un punto de fallo único y debe convertirse a un conjunto de servidores o de clústeres para mejorar su capacidad, disponibilidad y habilidad para recuperarse de condiciones de fallo.
Como configuración opcional, que se describe en el gráfico siguiente, puede configurar un servidor Web con el plugin HTTP de IBM WebSphere Application Server, frente a un despliegue de servidor típico para uso de prueba o de producción. El servidor web proporciona la habilidad para servir recursos estáticos, como imágenes y hojas de estilo, así como un punto de plug-in para un agente de inicio de sesión único (SSO) corporativo, en el caso de que WebSphere Portal participe en un dominio SSO global.
La ilustración siguiente muestra una topología común para un entorno de servidor único. Sólo hace falta un servidor único. WebSphere Portal, WebSphere Application Server y la base de datos están instalados en el mismo servidor.
El caso de ejemplo autónomo es distinto del servidor único, dado que el servidor de la base de datos, el servidor LDAP y el software de servidor web están instalados en servidores físicos distintos a IBM WebSphere Portal. Esta configuración le permite distribuir el software en su red y, por lo tanto, distribuir la carga de proceso.
Para una configuración autónoma, puede utilizar una base de datos existente y soportada en la red y un directorio LDAP existente y soportado. Puede configurar IBM WebSphere Portal para autenticarlo con el servidor LDAP. La ilustración siguiente muestra una topología común para un servidor autónomo. El servidor HTTP, (también llamado servidor web) está instalado en un servidor en una red protegida. El servidor LDAP y el servidor de la base de datos también están instalados en servidores distintos. WebSphere Portal y WebSphere Application Server están instalados en el mismo servidor.
Para aumentar la capacidad y la disponibilidad, los servidores de portal múltiples se pueden agrupar en clúster utilizando IBM WebSphere Application Server Network Deployment, donde los portales comparten una configuración común y la carga se distribuye uniformemente en todas las instancias de clúster.
IBM WebSphere Portal viene de forma estándar con WebSphere Application Server Network Deployment, una distribución de IBM WebSphere Application Server que proporciona un tipo de servidor del Gestor de despliegue para gestionar y agrupar en clúster de forma centralizada una serie de servidores. Agrupar en clúster una serie de servidores de portal significa que todas las instancias de portal comparten la misma configuración, incluida la base de datos, las aplicaciones y los portlets, y el diseño del sitio. El clúster proporciona un dominio contra el que se realizan muchas acciones administrativas una vez y se sincronizan con cada servidor del clúster. Esto simplifica la administración, a la vez que asegura que todos los miembros del clúster están configurados y se comportan de forma idéntica.
Un clúster de servidores también proporciona un dominio compartido en el que los datos de la memoria caché y de la sesión se pueden replicar y mantener coherentes en todos los miembros del clúster. El clúster también proporciona un mecanismo de sincronización de aplicaciones que asegura la gestión coherente de aplicaciones (iniciar, detener, actualizaciones, etc.) en todo el clúster.
WebSphere Application Server proporciona un plug-in de servidor HTTP que equilibra el tráfico de usuarios en todos los miembros del clúster y, a través de una función llamada “afinidad de sesiones”, asegúrese de que un usuario se mantiene unido a una instancia de clúster específica durante el tiempo que dure su sesión, para mejorar la eficiencia y el rendimiento. De forma adicional, en el caso de que un miembro del clúster esté fuera de servicio, las funciones de gestión de carga de trabajo del plug-in reconocerán que la instancia ya no está disponible y direccionará el tráfico a su alrededor.
Puede instalar IBM WebSphere Virtual Enterprise para crear un clúster dinámico que supervise el rendimiento, cargue información y pueda crear y eliminar dinámicamente miembros del clúster en función de la carga de trabajo. WebSphere Virtual Enterprise proporciona una función de direccionamiento inteligente denominada On Demand Router que tiene todas las características del plugin HTTP Server con la posibilidad adicional de definir las políticas de direccionamiento y servicio. On Demand Router es necesario si está configurando un entorno en clúster dinámico.
Hay dos tipos de clústeres: clústeres verticales y horizontales. La mayoría de los despliegues a gran escala son una mezcla de los dos tipos de clúster.
También es posible desplegar clústeres múltiples de portal para mejorar la disponibilidad, la migración tras error y la recuperación tras desastre.
Antes de instalar WebSphere Portal y crear su clúster, debe revisar todos los temas de la sección Consideraciones acerca del clúster para ayudarle a planificar un despliegue de clúster correcto.
Un clúster vertical tiene más de una instancia de clúster dentro de un nodo. Un nodo representa, por lo general, un servidor físico único en una célula gestionada, pero es posible tener más de un nodo por servidor físico. Es muy sencillo añadir clústeres verticales adicionales a un nodo, con el uso de la consola administrativa del Gestor de despliegue, pues cada instancia de clúster vertical adicional replica la configuración de la primera instancia; no es necesaria ninguna instalación ni configuración adicional.
El número de instancias verticales que se puedan crear en un único nodo dependerá de la disponibilidad de los recursos físicos en el sistema local (CPU y memoria). Demasiadas instancias de clústeres verticales podrían agotar los recursos físicos del servidor, en cuyo punto es apropiado construir instancias de clústeres horizontales para aumentar la capacidad, si es necesario.
El diagrama siguiente ilustra un clúster vertical. Un nodo único tiene instancias múltiples de IBM WebSphere Portal instaladas. El nodo está gestionado por el Gestor de despliegue. Cada instancia del nodo se autentica con el mismo servidor LDAP y almacena datos en el mismo servidor de base de datos. Aunque no esté descrito en la ilustración, la base de datos y los servidores LDAP también podrían agruparse en clúster si es necesario en caso de migración tras error, rendimiento mejorado y alta disponibilidad.
La mayoría de los sitios de portal de gran escala incorporan una combinación de agrupación en clúster horizontal y vertical para aprovechar al máximo los recursos de una máquina única antes de escalar hacia afuera a máquinas adicionales.
Para mejorar la disponibilidad, la migración tras error y la recuperación tras desastre del servidor, así como para ayudar a distribuir despliegues geográficos grandes, es mejor considerar desplegar clústeres múltiples de portal para el mismo sitio de portal. Con clústeres múltiples, un clúster puede dejarse fuera de producción, actualizarse y probarse mientras se deja el resto de los clústeres en producción. Esta es la mejor forma de conseguir el 100% de disponibilidad sin la necesidad de ventanas de mantenimiento. También es posible desplegar clústeres más cerca de las personas a las que sirven, mejorando así la capacidad de respuesta del contenido que ofrecen.
Cuando se despliegan clústeres múltiples de portal, en su mayoría, cada clúster debe contemplarse como un sistema totalmente aislado. Cada clúster está administrado de forma independiente y tiene su propia configuración, aislada del resto de los clústeres. Ello mejora la posibilidad de la topología del portal para mantenerse mientras protege su alta disponibilidad. La única excepción a esta regla ocurre cuando se comparten algunos de los dominios de base de datos del portal, en concreto los dominios Comunidad y Personalización, que están diseñados para compartirse en clústeres múltiples que presentan el mismo sitio de portal. Estos dominios almacenan datos de configuración de portal que son propiedad de los mismos usuarios finales, y por tanto es importante mantener estos datos sincronizados en todos los clústeres idénticos del portal. Consulte Consideraciones sobre la base de datos para obtener más información.
Cada clúster puede desplegarse dentro del mismo centro de datos, para ayudar a mejorar la capacidad de mantenimiento y el aislamiento de errores, o puede desplegarse en varios centros de datos, para proteger contra el desastre natural y el fallo en el centro de datos, o simplemente para proporcionar una cobertura geográfica más amplia de su sitio de portal. Cuanto más alejados estén los clústeres, mayor latencia de red de impacto habrá entre los clústeres y, por tanto, menos probable será que desee compartir la misma base de datos física entre clústeres para los dominios compartidos y deseará volver a las técnicas de replicación de la base de datos para mantener las bases de datos sincronizadas.
Por lo general, en una tipología múltiple de clúster de portal, los servidores HTTP están dedicados por clúster, ya que la configuración de los plug-in de los servidores HTTP es específica de la célula. Para direccionar el tráfico entre los centros de datos (bancos de servidores HTTP), se utiliza un dispositivo separado equilibrador de carga de red, con reglas colocadas para direccionar a los usuarios a centros de datos específicos, ya sean basados en la ubicación o en una selección de sitio aleatoria, como por ejemplo mediante resolución DNS. Se prefiere la selección de centro de datos basada en dominio o en ubicación porque su previsibilidad mantiene al mismo usuario direccionado al mismo centro de datos, lo cual ayuda a conservar la afinidad de sesiones y la eficiencia óptima. Tenga en cuenta el hecho de que la selección de direccionamiento basada en la resolución DNS puede causar un comportamiento aleatorio en términos de direccionar inesperadamente a los usuarios a otro centro de datos durante una sesión en vivo. Si esto ocurriera, la experiencia del usuario con el sitio del portal podría verse afectada cuando el usuario esté autenticado e intente reanudar en el último punto del sitio nuevo. La replicación de sesión y/o el uso apropiado de los parámetros de representación de portlets pueden ayudar a disminuir dicho efecto.
Como alternativa para desplegar clústeres múltiples de portal donde cada clúster se encuentra en una célula distinta, también es posible desplegar clústeres múltiples de portal en la misma célula. Las distintas células le dan un aislamiento total entre clústeres, y la libertad para mantener todos los aspectos de cada clúster sin que afecte a los demás. Sin embargo, las células distintas necesitan de distintos Gestores de despliegue y, por tanto, de distintas Consolas de administración para gestionar cada clúster. Los clústeres múltiples situados en la misma célula reducen los esfuerzos de administración a una única consola, pero aumenta el nivel de esfuerzo para mantener los clústeres, ya que hay un alto grado de uso compartido de recursos entre los clústeres múltiples.
Aunque los clústeres múltiples de portal situados en una única célula tiene sus usos, en especial a la hora de consolidar la creación de contenido y de representar servidores para un único nivel, también aumenta la complejidad administrativa de forma significativa. Se recomienda que los clústeres múltiples de portal se desplieguen en varias células, para así mantener la administración lo más sencilla posible. Consulte Clústeres múltiples de portal situados en una única célula para obtener más detalles.
Una topología de conjunto de servidores del portal es una serie de instancias de servidores autónomos configuradas de forma idéntica. Los conjuntos de servidores del portal ofrecen un modo sencillo de crear y mantener un entorno de servidor de alta disponibilidad y gran escalado.
Existen algunas ventajas al seleccionar un despliegue en clúster y existen ventajas al seleccionar un entorno de conjunto de servidores del portal. Estas ventajas incluyen ventajas de rendimiento y administración. Esta información describe cuándo se ha de seleccionar un escenario de despliegue en clúster o de conjunto de servidores del portal.
El término "conjunto de servidores del portal" hace referencia a una serie de instancias de servidores autónomos configuradas de forma idéntica. El que sean autónomos permite que el tamaño del conjunto de servidores del portal se pueda aumentar o disminuir sin tener que preocuparse acerca de las configuraciones complejas de los clústeres o sin un conocimiento interno del servidor. Los conjuntos de servidores del portal ofrecen un modo sencillo de crear y mantener un entorno de servidor de alta disponibilidad y gran escalado.
Cada instancia del conjunto de servidores del portal tiene una configuración de seguridad idéntica, incluida la configuración del repositorio de usuarios idéntico, por ejemplo el servidor LDAP, para asegurarse de que cada instancia del conjunto de servidores del portal tenga acceso a la misma información de usuarios y grupos y participe de forma transparente en la misma estrategia de inicio de sesión individual.
Dado que las instancias del servidor son independientes, no existe ninguna coordinación del contenido de la caché dinámica ni invalidaciones de dicho contenido. Por lo tanto, es posible realizar cambios en un servidor que no se verán inmediatamente en otro servidor del conjunto de servidores del portal. Por este motivo, es importante configurar las memorias caché para que caduquen dentro de un período de tiempo razonable para así garantizar que las actualizaciones puedan verse de forma puntual sin comprometer las ventajas del almacenamiento en memoria caché.
En un conjunto de servidores del portal que conste de instalaciones exclusivos, dado que las acciones administrativas son necesarias para todos los servidores y se deben aplicar manualmente a todos los servidores, la caducidad de las memorias caché del portal no será una preocupación general.
En las configuraciones compartidas, los cambios de configuración aparecerán generalmente entre el conjunto de servidores del portal cuando sus memorias caché caduquen, o cuando se reinicien los servidores individuales. Consulte el tema Almacenamiento en caché bajo Conceptos Relacionados para obtener información adicional.
Antes de iniciar el proceso de instalación y configuración, obtenga información acerca de las diferentes opciones de configuración de un conjunto de servidores del portal.
Existen consideraciones exclusivas para el compartimiento de bases de datos y el equilibrio de carga en una configuración de conjunto de servidores del portal.
Es importante mantener la afinidad entre un cliente y una instancia del conjunto de servidores del portal concreta, tanto para la eficacia del almacenamiento en caché como para el rendimiento, y también para garantizar el funcionamiento correcto del inicio de sesión. Durante el proceso de inicio de sesión, es necesario realizar varios pasos de petición en el mismo servidor. Si durante el proceso de inicio de sesión se desplaza entre servidores, el inicio de sesión puede fallar.
Existen muchos dispositivos de red disponibles comercialmente que dan soporte al equilibrio de carga entre servidores con afinidad. WebSphere Portal incluye IBM HTTP Server, cuyo plugin de aplicación da soporte al equilibrio de carga entre servidores también. El equilibrio de carga con el plugin de servidor de aplicaciones presupone que se utiliza un clúster de servidores de aplicaciones, por lo tanto, para utilizar esta técnica es necesario realizar tareas adicionales de configuración. Consulte la sección "Configuración de un conjunto de servidores del portal" para obtener información acerca de cómo configurar el servidor HTTP para dar servicio al conjunto de servidores del portal.
Las organizaciones que únicamente necesiten un sitio web pequeño o un sitio de intranet podrán implementar una topología de servidor único para Web Content Management. En una configuración de servidor único, la creación y la entrega se realizan en el mismo servidor. Esta configuración no se recomienda para organizaciones que necesitan un sitio web o un sitio de intranet más grande.
El siguiente diagrama de topología muestra una configuración de un único servidor para Web Content Management. Un servidor web direcciona las solicitudes entrantes de los clientes de navegador. Web Content Management, WebSphere Portal y WebSphere Application Server se instalan en el mismo servidor. El servidor LDAP que almacena la información de los usuarios autorizados se instala en un servidor dedicado. La base de datos que almacena el contenido también está instalada en un servidor dedicado. A pesar de que el diagrama no muestra una configuración en clúster, el servidor Web Content Management podría ser un clúster. De forma parecida, tanto los servidores de base de datos como el registro LDAP se pueden disponer en clúster para una migración tras error.
Las organizaciones que necesitan un sitio web grande con mucho tráfico o con distintos usuarios creando contenido deberían implementar una configuración de servidor dual. En una configuración de servidor dual, la creación se lleva a cabo en un servidor, o clúster de servidores, y el contenido se entrega a un servidor, o clúster de servidores, distinto. Los autores acceden y trabajan en el servidor de creación mientras que los usuarios acceden al servidor de entrega. De esta forma se reduce la carga en cada servidor y se permite ubicar el entorno de creación detrás de un cortafuegos.
El siguiente diagrama ilustra un entorno de servidor dual para Web Content Management. Tanto el servidor de entrega como el servidor de creación acceden al mismo servidor de base de datos y LDAP con el propósito de acceder a usuarios comunes, a grupos comunes y al contenido. La utilización de la misma configuración de LDAP es muy importante con Web Content Management. Los usuarios del sitio web acceden al sitio a través de un servidor web que dirige al usuario al servidor de entrega. En el servidor de entrega se puede utilizar un visor de contenido web, tal como se muestra en el diagrama, un servlet de contenido web, o un sito representado de forma previa. El nuevo contenido se sindica o publica en el servidor de entrega.
Si existe la necesidad de entregar sitios web complejos y de tamaño grande a un número elevado de usuarios de sitio y de creadores de contenido, implemente una configuración con un servidor intermedio. La implementación de un servidor intermedio proporciona un entorno para comprobar la exactitud del contenido, los posibles problemas con el diseño y el rendimiento. En una configuración con un servidor intermedio, la creación, la transferencia y la entrega se separan en varios servidores. El entorno de un servidor intermedio puede utilizarse para pruebas de aceptación del usuario (UAT) o para permitir que se acumulen cambios del entorno de creación antes de sindicar los cambios en el entorno de entrega en un único proceso.
En el siguiente diagrama se muestra una topología con un servidor intermedio. Hay un servidor distinto, o clúster de servidores, para los entornos de creación, intermedio y entrega. Todos los entornos, el de entrega, intermedio o de creación, acceden a los mismos servidores de base de datos y LDAP. Si es preciso, tanto los servidores de base de datos como el registro LDAP, se pueden disponer en clúster. Los usuarios del sitio web acceden al servidor intermedio a través del servidor web. Los autores acceden al servidor de creación y el contenido se sindica en el servidor intermedio para verificar que su calidad es la adecuada antes de publicarlo en el servidor de entrega.
Para utilizar un sistema Web Content Management, necesitará desplegar un conjunto de entornos de Web Content Management dentro del sistema general de WebSphere Portal. Revisar los entornos de Web Content Management le ayudará a entender lo que ocurre en cada entorno y la forma en la que podría tener que configurar los servidores físicos. Web Content Management se instala mediante la interfaz de usuario de instalación de WebSphere Portal.
Cada servidor o clúster en el sistema de contenido web requiere un repositorio de datos distinto, aunque normalmente comparten el mismo LDAP. Un sistema de Web Content Management se puede desplegar de forma aislada o en paralelo con un sistema de WebSphere Portal.
El tipo de sistema de contenido web que despliegue lo determina el tamaño del sistema de contenido web, el tipo de sitio web que se entregue y el número de usuarios que creen y que visualicen el contenido web.
Un entorno de creación se utiliza para crear y gestionar contenidos web. Este entorno de creación lo utilizan los diseñadores del sitio web y los creadores de contenido.
Un entorno de creación estándar está formado por un único clúster de creación que sindica directamente a un entorno de entrega o uno intermedio. Por ejemplo:
Existe la posibilidad de añadir un entorno de prueba a su entorno de creación para habilitar la realización de pruebas de aceptación de usuario en su sitio web y su sistema de gestión de contenido. Por ejemplo:
Por ejemplo, si tiene usuarios en ubicaciones distintas, será más eficaz instalar un entorno de creación local en cada ubicación. La sindicación bidireccional se utiliza entre todos los entornos de creación con un entorno de creación centralizado para permitir que los cambios realizados en todas las ubicaciones remotas sean visibles a todos los usuarios.
La creación descentralizada aumenta el riesgo de conflictos de actualizaciones entre entornos de creación. Para reducir el riesgo de conflictos, se pueden asignar distintos sitios, o distintas secciones de un sitio a cada entorno de creación. También puede utilizar distintos entornos de creación para distintos roles de usuario. Por ejemplo, los creadores de contenido pueden utilizar un entorno de creación diferente al de los diseñadores de plantillas de presentación.
El acceso a cada entorno de creación descentralizado se controla utilizando una combinación de controles de acceso del portlet de creación y valores de seguridad de elementos. Por ejemplo, sólo los usuarios que necesiten acceder al entorno de creación local tendrán acceso al portlet de creación local. Los usuarios tendrán acceso de "Lectura" a todos los elementos, pero sólo acceso de "Edición" a los elementos que necesiten actualizar.
Se trata de un entorno para las pruebas de aceptación de usuario o pruebas de validación (UAT) que puede ser tan simple como un único servidor UAT donde se prueban las actualizaciones de contenido y del sitio antes de sindicarlo para el entorno de entrega, o tan complejo como un réplica completa del entorno prueba donde las pruebas de aceptación de usuario (UAT) se pueden dar para revisar tanto para las actualizaciones de contenido como las del sitio como para probar el rendimiento de su entorno de entrega. También permite acumular cambios del entorno de creación desde su entorno de creación antes de sindicar los cambios para el entorno de entrega como un único lote.
Un entorno de pruebas se puede añadir al entorno de creación para poder realizar las pruebas de aceptación de usuario (UAT) en el sistema de gestión de contenido y en el sitio web:
Las pruebas del sistema se pueden realizar en una réplica del entorno de entrega antes de sindicar los cambios en el entorno de entrega activo:
Un entorno de entrega sirve para entregar contenido a quienes visualizan su sitio web.
Puede prerepresentar un sitio web completo en HTML y guardarlo en disco. El sitio previamente representado se puede utilizar como sitio activo y visualizarse a los usuarios utilizando Web Content Management o un servidor web. Despliegue un sitio representado previamente cuando no utilice ninguna característica de WebSphere Portal como, por ejemplo, portlets y el contenido sea estático y sólo se actualice de forma periódica.
Los usuarios pueden acceder al contenido que se visualiza mediante el servlets de Web Content Management. Un sitio web entregado por servlets se utiliza cuando no se necesita utilizar ninguna de las características basadas en los portlets como, por ejemplo, herramientas de creación.
Los visores de contenido web son portlets que visualizan contenido desde una biblioteca de contenido web como parte de una página de portal. Si la presentación es sencilla, puede ser suficiente con un único visor de contenido web, pero también puede utilizar varios visores de contenido web para agregar contenido desde distintas bibliotecas y proporcionar una experiencia más enriquecida para sus usuarios. Un visor de contenido web local sirve para visualizar contenido dentro de su entorno de entrega de contenido web.
El soporte WSRP en el visor de contenido web JSR 286 sirve para visualizar contenido en un clúster o servidor remoto de WebSphere Portal.
De manera predeterminada, IBM WebSphere Portal utiliza el transporte HTTP interno dentro de IBM WebSphere Application Server para manejar las solicitudes. Sin embargo, como WebSphere Application Server admite también el uso de un servidor web externo, puede acceder a WebSphere Portal desde el servidor web. Puede utilizar un servidor web local en la misma máquina que WebSphere Portal o utilizar un servidor web remoto en una máquina distinta. Un servidor web remoto es típico de un entorno de producción o de otra configuración con mucho tráfico y también se coloca de forma típica en zonas desmilitarizadas (DMZ) fuera de un cortafuegos para proteger los puertos del portal.
Para habilitar la comunicación entre el servidor web y WebSphere Application Server, hace falta un plug-in del servidor web. El plug_in del servidor web determina si una solicitud la manejará el servidor web o el servidor de aplicaciones. El plug-in se puede instalar en un servidor web situado en la misma máquina que WebSphere Application Server o en una máquina distinta. El plug-in del servidor web utiliza un archivo de configuración XML (plugin-cfg.xml) que contiene los valores que describen cómo gestionar y transferir las solicitudes a los WebSphere Application Server accesibles mediante el plug-in.
En la consola de administración de WebSphere Application Server, el servidor web se representa como un tipo de servidor específico y puede ver o modificar todas las propiedades de configuración que se utilizan en el archivo plugin-cfg.xml, para el plug-in del servidor web desde la consola de administración.
Usuarios de i : para obtener información detallada acerca de cómo utilizar un servidor Web externo con su sistema i, consulte Selección de un diagrama de topología de servidor Web y un mapa de guía, además de los pasos que se listan en esta página.
De manera predeterminada, WebSphere Portal se ha configurado para acceder a él a través del puerto HTTP interno de WebSphere Application Server. Por ejemplo, http://hostname.example.com:10039/wps/portal, donde hostname.example.com es el nombre de host completo de la máquina donde se ejecuta WebSphere Portal y 10039 es el puerto de transporte predeterminado que WebSphere Application Server crea; en su entorno, el número de puerto puede ser distinto. WebSphere Portal utiliza el nombre de host y el puerto predeterminados que se especifican mediante las propiedades WpsHostName y WpsHostPort en el archivo wkplc.properties.
Después de configurar WebSphere Portal para utilizar un servidor web externo, accederá al portal al portal con el nombre de host y el puerto del servidor web 80. Para los servidores autónomos o para los miembros del clúster vertical, no podrá acceder al portal utilizando el nombre de host y el puerto de WebSphere Portal (por ejemplo, 10039), a menos que haya una definición de host virtual para el puerto 10039 en la configuración de WebSphere Application Server.
Un entorno de desarrollo simple puede basarse en la configuración de la base de datos predefinida que utiliza Apache Derby. La instalación con Derby le permite instalar y ejecutar IBM WebSphere Portal con rapidez en un entorno de prueba de concepto. En un entorno de producción, debe utilizar uno de los otros sistemas de gestión de base de datos soportados.
El almacenamiento de datos y la migración tras error se complican más a medida que el entorno de red es también más complejo. En un entorno complejo y de alta demanda, los datos se pueden distribuir en varios servidores de bases de datos para una configuración de migración tras error y un almacenamiento de alta capacidad. Por ejemplo, en un entorno de producción, la necesidad de un tiempo de respuesta rápido en una situación de alta demanda, junto con el deseo de una prestación de migración tras error distribuida en varios servidores de bases de datos puede necesitar que se transfiera la base de datos a un servidor más sólido. Por lo tanto, conozca las limitaciones de utilizar Derby y determine cómo la transferencia a otra base de datos afectará a la capacidad y la escalabilidad del entorno. Tenga también en cuenta que la versión de Derby proporcionada con WebSphere Portal tiene limitaciones de carga de trabajo y migración tras error que se solucionarán en un release posterior de las mejoras de rendimiento de Derby.
Derby es una base de datos Java incorporada que ocupa poco espacio, es autoajustable e es ideal para soluciones en las que la base de datos debe estar oculta. Derby funciona en un entorno sin clústeres con un pequeño número de usuarios, como por ejemplo un entorno de desarrollo de portlets, un entorno de prueba o de prueba de concepto.
La base de datos Derby que se instala de manera predeterminada no está pensada para utilizarse en un entorno de producción o para crear contenido web. Aunque se da soporte al uso de una base de datos, se recomienda utilizar varias bases de datos para obtener un mejor rendimiento y más disponibilidad. Derby no da soporte a entornos en clúster, la habilitación de la seguridad en modalidad sólo de base de datos o a entornos clonados verticales en los que varios servidores de aplicaciones se configuran en un solo servidor. Utilice una de las bases de datos soportadas en un entorno de producción o al crear contenido web, ya que pueden gestionar grandes cantidades de datos y se pueden ajustar para mejorar el rendimiento.
Con el ajuste adecuado, otras bases de datos pueden proporcionar mejoras en el rendimiento. Otras bases de datos tienen soporte para la clonación y entorno de clústeres vertical y horizontal. Utilice varias bases de datos para obtener un mejor rendimiento y una mayor disponibilidad.
Cuando elija transferir datos a otra base de datos soportada, realice la transferencia de la base de datos antes de utilizar el portal con todas sus funciones. Si hay grandes cantidades de datos en las bases de datos, éstos pueden provocar que la transferencia de la base de datos produzca errores, en el caso de que el tamaño del almacenamiento dinámico de Java no sea lo suficientemente grande. Puesto que se añade información a las bases de datos a medida que se utiliza el portal, efectúe la transferencia de la base de datos tan pronto como se dé cuenta de que hay que almacenar un gran volumen de datos y la migración tras error es necesaria. Transferir la base de datos cuanto antes evita los problemas que suele provocar la transferencia en una fase posterior de un gran volumen de datos a otras bases de datos soportadas, incluido el no tener el tamaño de almacenamiento dinámico adecuado de Java.
Se pueden transferir datos de un base de datos Derby, pero no se pueden transferir a una base de datos Derby. Si va a realizar la transferencia desde una base de datos distinta a la predeterminada, tendrá que editar los archivos wpconfig_sourceDb_properties, wkplc_dbdomain y wkplc_dbtype.properties para actualizar la información de la base de datos de origen.
Hay dos tipos de usuarios de base de datos: usuarios de configuración de base de datos y usuarios de tiempo de ejecución de base de datos. Familiarícese con los permisos necesarios para que cada tipo de usuario trabaje con los dominios de base de datos de IBM WebSphere Portal y los mandatos para la creación de usuarios de configuración de base de datos y cómo otorgar permisos.
El usuario de administración de base de datos que se suele crear al instalar un Sistema de gestión de base de datos (DBMS) es el usuario de instalación de base de datos o el usuario de configuración de base de datos. El usuario de configuración de base de datos no es necesariamente el usuario predeterminado que se crea cuando se instala el sistema de gestión de bases de datos. El usuario predeterminado se podría utilziar como usuario de configuración de base de datos. WebSphere Portal utiliza el usuario de configuración de base de datos para tareas de configuración y crea la estructura de base de datos necesaria para WebSphere Portal. Por ejemplo, el usuario de configuración de base de datos puede crear tablas e índices de base de datos, realizar transferencias de bases de datos y a menudo tiene permisos para el sistema operativo, según el sistema de gestión de bases de datos.
El usuario de tiempo de ejecución de base de datos necesita menos privilegios que el usuario de configuración de la base de datos. El usuario de tiempo de ejecución tiene acceso en tiempo de ejecución al origen de datos de una base de datos y puede realizar operaciones básicas de lectura y escritura sobre los datos. Plantéese la creación de un usuario de tiempo de ejecución dedicado para cada dominio de base de datos de WebSphere Portal. Si no crea usuarios de tiempo de ejecución, WebSphere Portal utiliza el usuario de configuración para conectar a las bases de datos en tiempo de ejecución.
La tabla siguiente identifica los permisos mínimos necesarios para la función correcta de los dos tipos de usuarios de base de datos: usuarios de configuración y usuarios de tiempo de ejecución. Los permisos de la lista pertenecen a todos los dominios de base de datos de WebSphere Portal.
| Permisos dentro del dominio de base de datos | Release | Comunidad | Personalización | JCR | Comentarios | Likeminds |
|---|---|---|---|---|---|---|
| Acceso a la base de datos | Sí | Sí | Sí | Sí | Sí | Sí |
| Lectura en todas las tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Escritura en todas las tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Actualización en todas las tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Supresión en todas las tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Creación de tablas | No | No | No | Sí | No | No |
| Creación de índices | No | No | No | Sí | No | No |
| Uso de secuencias | No | No | No | Sí | Sí | No |
| Permisos dentro del dominio de base de datos | Release | Comunidad | Personalización | JCR | Comentarios | Likeminds |
|---|---|---|---|---|---|---|
| Acceso a la base de datos | Sí | Sí | Sí | Sí | Sí | Sí |
| Lectura en todas las tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Escritura en todas las tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Actualización en todas las tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Supresión en todas las tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Cuota en disco para la creación de objetos nuevos | Sí | Sí | Sí | Sí | Sí | Sí |
| Creación de espacios de tabla | Sí | Sí | Sí | Sí | Sí | Sí |
| Descarte de espacios de tabla | Sí | Sí | Sí | Sí | Sí | Sí |
| Creación de tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Alteración de tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Descarte de tablas | Sí | Sí | Sí | Sí | Sí | Sí |
| Creación de índices | Sí | Sí | Sí | Sí | Sí | Sí |
| Descarte de índices | Sí | Sí | Sí | Sí | Sí | Sí |
| Creación de desencadenantes | Sí | Sí | Sí | Sí | Sí | Sí |
| Descarte de desencadenantes | Sí | Sí | Sí | Sí | Sí | Sí |
| Creación de secuencias | No | No | No | Sí | Sí | No |
| Uso de secuencias | No | No | No | Sí | Sí | No |
| Creación de tipos | No | No | No | Sí | No | No |
| Descarte de tipos | No | No | No | Sí | No | No |
| Creación de vistas | No | No | No | Sí | No | No |
| Descarte de vistas | No | No | No | Sí | No | No |
Tenga en cuenta las opciones de configuración en relación con su caso de ejemplo de despliegue de IBM WebSphere Portal. La complejidad de la topología de red aumenta a medida que se escala desde un entorno de prueba de concepto que utiliza Derby a sistemas que utilizan técnicas de agrupación en clúster verticales y horizontales.
Los datos de WebSphere Portal se pueden configurar en un único almacén u organizarse en dominios de bases de datos para satisfacer los distintos requisitos de disponibilidad, en función de los casos de ejemplo de despliegue para los entornos de producción y prueba de concepto. Los dominios de bases de datos proporcionados por WebSphere Portal le ayudan a clasificar y distribuir los datos del portal. Cada dominio de base de datos se puede colocar en una base de datos independiente para conseguir un mantenimiento eficaz. Además, cada dominio se puede colocar en un sistema de servidor de bases de datos independiente para obtener el máximo rendimiento.
Los dominios de bases de datos clasifican los datos del portal y le ayudan a determinar cómo distribuirlos. Para maximizar la disponibilidad de los datos, puede distribuir los datos del portal en varias bases de datos y, en el caso de algunos dominios, compartir datos entre varias líneas de producción. Puede decidir transferir un solo dominio de base de datos o varios dominios.
La separación de los datos del le permite almacenar cada categoría de datos en su propio conjunto de tablas de bases de datos o en el sistema de archivos. Los conjuntos de esquemas y tablas de bases de datos para los recursos del portal se denominan dominios de base de datos. Los dominios de bases de datos dan soporte al almacenamiento y la transferencia de datos por categoría, por ejemplo, Configuración, Release, Personalización, Comunidad y IBM Java Content Repository (JCR). La separación de sus datos le permite compartir dominios en varios portales. También puede distribuir los diferentes dominios en tipos de bases de datos diferentes. Por ejemplo, puede elegir dejar los datos de LikeMinds en la base de datos predeterminada y mover todos los datos restantes a otra base de datos. La separación de los dominios se puede utilizar para dar soporte a los entornos de producción, en las que los nodos de producción estén divididos en clústeres separados. Cada clúster se puede ejecutar de forma independiente, pero compartir los mismos dominios de bases de datos de Comunidad y Personalización, por ejemplo. Cada uno de estos clústeres se denomina línea de producción.
| Dominio de base de datos | Compartible | Método de almacenamiento |
|---|---|---|
| Release | no | base de datos |
| Personalización | sí | base de datos |
| Comunidad | sí | base de datos |
| JCR | no | base de datos |
| Comentarios | sí | base de datos |
| LikeMinds | sí | base de datos |
Para fines de mantenimiento o en versiones intermedias puede quitar del servicio una sola línea de producción mientras otra línea sigue sirviendo solicitudes con los antiguos datos. Después actualizar y volver a poner en servicio la primera línea de producción, la segunda línea se actualiza utilizando el mismo enfoque. Las actualizaciones de los datos en el dominio compartido son de vital importancia porque influyen en la otra línea de producción.
La capacidad del entorno completo debe ser mayor que la utilización prevista, para que los servidores individuales se puedan sacar de la producción, sin que ello afecte a la disponibilidad de las aplicaciones. Para garantizar que todos los recursos del sistema estén disponibles para el portal, los sistemas de producción deben estar dedicados al portal y no deben ejecutar otro software de servidor que no esté relacionado con el portal.
Las bases de datos de VMM para un repositorio completo y para la ampliación de propiedades se pueden compartir entre líneas de producción. Si las bases de datos de VMM están fuera de servicio, WebSphere Portal no funcionará.
Si es un administrador de base de datos, tenga en cuenta los requisitos de base de datos para IBM WebSphere Portal.
Cuando planifique la transferencia de datos a IBM DB2 Universal Database Enterprise Server Edition, debe tener en cuenta la información de bases de datos y de usuario, como los nombres de las bases de datos, los datos que hay almacenados y el espacio de base de datos necesario. Algunos fixpacks exigen llevar a cabo algunos pasos antes de la transferencia a fin de que la tarea se realice de forma satisfactoria.
Los nombres de bases de datos y usuarios en esta página son valores sugeridos para que la documentación sea coherente. Sustituya dichos valores por los valores de su entorno. El nombre de la base de datos no puede superar los ocho caracteres y sólo puede contener letras y números.
En un entorno de base de datos local, WebSphere Portal y DB2 se instalan en el mismo sistema.
Como se muestra en la Figura 2, cuando se utilizan conexiones JDBC de tipo 2, WebSphere Portal y DB2 Connect están instalados en un sistema (el sistema local). El servidor de DB2 está instalado en una máquina independiente (la máquina remota).
Para las conexiones JDBC de tipo 4, no es necesaria ninguna instalación de DB2 Connect en el sistema que ejecuta WebSphere Portal. Como se muestra en la Figura 3, el controlador JDBC de DB2 Universal que se proporciona con DB2 se copia en ese sistema. Se utiliza dentro de la JVM (Java Virtual Machine) de WebSphere Portal y se conecta directamente al servidor de DB2 remoto.
Cuando planifique la transferencia de datos a IBM DB2 Universal Database Enterprise Server Edition, debe tener en cuenta la información de bases de datos y de usuario, como los nombres de las bases de datos, los datos que hay almacenados y el espacio de base de datos necesario. Algunos fixpacks exigen llevar a cabo algunos pasos antes de la transferencia a fin de que la tarea se realice de forma satisfactoria.
Los nombres de bases de datos y usuarios en esta página son valores sugeridos para que la documentación sea coherente. Sustituya dichos valores por los valores de su entorno. El nombre de la base de datos no puede superar los ocho caracteres y sólo puede contener letras y números.
En un entorno de base de datos local, WebSphere Portal y DB2 se instalan en el mismo sistema.
Como se muestra en la Figura 2, cuando se utilizan conexiones JDBC de tipo 2, WebSphere Portal y DB2 Connect están instalados en un sistema (el sistema local). El servidor de DB2 está instalado en una máquina independiente (la máquina remota).
Para las conexiones JDBC de tipo 4, no es necesaria ninguna instalación de DB2 Connect en el sistema que ejecuta WebSphere Portal. Como se muestra en la Figura 3, el controlador JDBC de DB2 Universal que se proporciona con DB2 se copia en ese sistema. Se utiliza dentro de la JVM (Java Virtual Machine) de WebSphere Portal y se conecta directamente al servidor de DB2 remoto.
Cuando planifique la transferencia de datos a IBM DB2 para i, debe tener en cuenta la información de bases de datos y de usuario, como los nombres de las bases de datos, los datos que hay almacenados y el espacio de base de datos necesario. Algunos fixpacks exigen llevar a cabo algunos pasos antes de la transferencia a fin de que la tarea se realice de forma satisfactoria.
DB2 está integrado con i, pero debe crear los usuarios y bases de datos necesarios y otorgarles los privilegios adecuados. WebSphere Portal puede crear automáticamente las bases de datos.
Los nombres de bases de datos y usuarios de este tema son valores sugeridos para que la documentación sea coherente. Sustituya dichos valores por los valores de su entorno.
WebSphere Portal utiliza ApacheDerby durante la instalación, y soporta la configuración de DB2 para un sistema IBM System i5. La base de datos Derby es ideal para un entorno de prueba. Para un entorno de producción, puede moverse de la base de datos Derby a IBM DB2 para i, pero tenga en cuenta que no hay ninguna opción para volver a Derby.
La base de datos de IBM DB2 para i le permite gestionar y acceder a los datos del servidor mediante una aplicación o una interfaz de usuario. Además de proporcionar acceso y protección para los datos, IBM DB2 Universal Database para i proporciona funciones avanzadas, como la integridad referencial y el proceso de base de datos paralelo.
IBM DB2 para i es el gestor de base de datos relacional totalmente integrado en el sistema i. IBM DB2 para i también proporciona funciones, como activadores, procedimientos almacenados e indexado con correlación de bits dinámica que sirven para una amplia gama de tipos de aplicaciones. Estas aplicaciones pueden ser desde aplicaciones tradicionales basadas en el host a soluciones de cliente y servidor y aplicaciones de Business Intelligence.
Como interfaz para IBM DB2 para i, para iSeries de DB2 Query Manager y Structured Query Language (SQL) Development Kit para System i5 añaden una interfaz interactiva para consultas e informes que le ayudarán a escribir programas de aplicaciones SQL en lenguajes de programación de alto nivel. La implementación de SQL para OS/400 permite definir, manipular, consultar y controlar el acceso a los datos de i. Funciona igual de bien con archivos i y tablas SQL.
Si decide utilizar una base de datos para que contenga toda la información de WebSphere Portal, Member Manager y content publishing, sólo es necesario un perfil de usuario. Son necesarios los perfiles de usuario solamente si utiliza varios sistemas i o si se necesitan bases de datos diferentes.
Cuando WebSphere Portal crea bases de datos, utiliza los nombres de bases de datos especificados en el archivo wkplc_dbdomain.properties, que se encuentra en el directorio UserData, en raíz_perfil_wp/ConfigEngine/properties. Puede crear hasta seis bases de datos diferentes estableciendo valores distintos en el archivo wkplc_dbdomain.properties.
En un entorno de base de datos local, se puede acceder a WebSphere Portal y a IBM DB2 para i con una conexión de tipo 4 o de tipo 2. La conexión de tipo 4 es el valor predeterminado y la conexión recomendada.
En un entorno de base de datos remota, WebSphere Portal se conecta directamente con el servidor de DB2 (conexión JDBC de tipo 4).
Cuando planifique la transferencia de datos a IBM DB2 Universal Database para z/OS, debe tener en cuenta la información de bases de datos y de usuario, como los nombres de las bases de datos, los datos que hay almacenados y el espacio de base de datos necesario. Algunos fixpacks exigen llevar a cabo algunos pasos antes de la transferencia a fin de que la tarea se realice de forma satisfactoria.
Cuando se planifique instalar DB2 para z/OS para utilizarla como base de datos para WebSphere Portal, debe considerar lo siguiente:
-db2 display bufferpool(bp2) -db2 alter bufferpool(bp2) vpsize(15000)
Los nombres de bases de datos y usuarios en esta página son valores sugeridos para que la documentación sea coherente. Sustituya dichos valores por los valores de su entorno. El nombre de la base de datos no puede superar los ocho caracteres y sólo puede contener letras y números.
Si tiene pensado utilizar un subsistema DB2 para z/OS para almacenar los datos para más de una instancia del portal, utilice el mismo nombre de usuario, pero un nombre de esquema independiente para cada dominio de base de datos. Para Member Manager, el nombre de usuario debe coincidir con el esquema; no se puede utilizar el mismo usuario de base de datos para las bases de datos de Member Manager de dos instalaciones del portal distintas.
Cada instalación del portal debe estar en una célula de WebSphere Application Server separada y distinta. Si los portales se instalan en el mismo sistema de archivos, cada uno se debe instalar en un directorio independiente y exclusivo. Si los portales se instalan en sistemas de archivos distintos, se puede utilizar el mismo nombre de directorio.
En un entorno de bases de datos remotos, WebSphere Portal y DB2 Connect se instalan en una máquina (la máquina local) y el servidor DB2 para z/OS se instala en una máquina separada (la máquina remota).
Cuando planifique la transferencia de datos a Oracle, debe tener en cuenta la información de bases de datos y de usuario, como los nombres de las bases de datos, los datos que hay almacenados y el espacio de base de datos necesario.
Los nombres de bases de datos y usuarios de este tema son valores sugeridos para que la documentación sea coherente. Sustituya dichos valores por los valores de su entorno.
Cuando planifique la transferencia de datos a Oracle RAC, debe tener en cuenta la información de bases de datos y de usuario, como los nombres de las bases de datos, los datos que hay almacenados y el espacio de base de datos necesario.
Los nombres de bases de datos y usuarios de este tema son valores sugeridos para que la documentación sea coherente. Sustituya dichos valores por los valores de su entorno.
Es posible que el tamaño del espacio en tabla predeterminado para Oracle RAC se deba establecer en 1024 MB con autoextend activado para que la transferencia de base de datos sea satisfactoria.
Cuando planifique la transferencia de datos a SQL Server, debe tener en cuenta la información de bases de datos y de usuario, como los nombres de las bases de datos, los datos que hay almacenados y el espacio de base de datos necesario.
Los nombres de bases de datos y usuarios de este tema son valores sugeridos para que la documentación sea coherente. Sustituya dichos valores por los valores de su entorno.
Un registro de usuarios o repositorio autentica un usuario y recupera información sobre los usuarios y los grupos para desempeñar funciones relacionadas con la seguridad, incluidas la autenticación y la autorización.
En función del repositorio federado, WebSphere Portal permite crear un usuario base que se puede federar en varios repositorios: LDAP, DB y/o el registro de usuarios personalizado. También le permite definir atributos adicionales en un almacén independiente si el directorio LDAP corporativo es de solo lectura.
Si está utilizando un repositorio federado, debe planear donde desea almacenar los nuevos usuarios y grupos. De manera predeterminada, los nuevos usuarios y grupos se almacenan en el repositorio de archivos predeterminado. Si está utilizando varios registros de usuarios LDAP y/o registros de usuarios de bases de datos, debe averiguar qué registro de usuarios desea definir como registro de usuarios predeterminado cuando al almacenar nuevos usuarios y grupos. Después de añadir todos los registros de usuarios al repositorio federado, puede ejecutar la tarea wp-set-entitytypes para establecer un registro de usuarios específico como ubicación predeterminada.
Si tiene una aplicación que no da soporte al repositorio federado, puede cambiar a un registro de usuarios LDAP autónomo o un registro de usuarios personalizado autónomo.
IBM WebSphere Portal proporciona varias tareas de configuración de seguridad. En el pasado, había una tarea que no le permitía recuperarse de los errores ni permitía que el registro de usuarios satisficiese las crecientes necesidades empresariales. Ahora, hay varias tareas, lo que le permite ajustar el sistema para satisfacer las necesidades empresariales.
| Opción de seguridad | Descripción |
|---|---|
| Seguridad LDAP autónoma | Esta opción es una opción de seguridad LDAP simple y sencilla, que es similar a la opción de seguridad LDAP que se proporcionaba en el pasado. Con esta opción, puede crear portales virtuales con un único dominio y almacenar los usuarios y los grupos en un único servidor LDAP. |
| Seguridad federada | Esta opción es una opción evolucionada del registro de usuarios LDAP autónomo con una única opción de soporte de dominios. Con esta opción, puede crear portales virtuales con varios dominios, utilizar varios repositorios (LDAP, base de datos, personalizado), y puede añadir grupos de aplicaciones al sistema.
Esta opción es la correcta si tiene que fusionar varios servidores LDAP en una estructura cohesiva. Importante: Debe prestar especial atención a que no haya nombres duplicados entre los diversos repositorios. Por ejemplo, si ha instalado el producto con un administrador del portal de "wpsadmin", el usuario "wpsadmin" no debe existir en el servidor LDAP corporativo.
|
| Seguridad personalizada | Esta opción le proporciona la capacidad de escribir un entorno de seguridad de WebSphere totalmente controlado proporcionando un registro de usuarios personalizado y un adaptador de miembros personalizado para Virtual Member Manager (VMM). Las capacidades de esta opción dependerán de la implementación. |
De manera predeterminada, WebSphere Portal se configura con el repositorio federado predeterminado, con un repositorio de archivos integrado. Por lo tanto, debe ejecutar la tarea wp-modify-ldap-security para pasar a un registro de usuarios LDAP autónomo. Para garantizar que el registro de usuarios LDAP se ejecute correctamente con WebSphere Portal, debe adaptar entonces la configuración del atributo para que coincida con el servidor LDAP configurado y con sus necesidades empresariales. Cuando haya completado los pasos de estas tareas, la seguridad estará lista para la producción.
| Tarea | Descripción |
|---|---|
| Actualizar el registro de usuarios LDAP autónomo | Puede actualizar varios parámetros, como el ID de enlace y la contraseña, para solucionar los problemas con su registro de usuarios LDAP. |
| Base de datos de extensión de propiedades; antes conocida como base de datos Lookaside | Seleccione esta opción para almacenar los atributos adicionales en la extensión de propiedades VMM, en lugar de en el registro de usuarios LDAP. Algunas aplicaciones, como el portlet Common Mail y IBM Lotus Web Content Management utilizan la base de datos de extensión de propiedades para almacenar los atributos adicionales. Después de habilitar la base de datos de extensión de propiedades, puede añadir atributos para satisfacer sus necesidades empresariales. |
| Crear el tipo de entidad | Seleccione esta opción si desea utilizar un tipo de entidad que exista en WebSphere Portal, pero no en el registro de usuarios LDAP. Esta opción crea el tipo de entidad del registro de usuarios y añade el nombre distinguido relativo (RDN) para correlacionar el tipo de entidad entre WebSphere Portal y el registro de usuarios. |
| Actualizar un tipo de entidad existente | Seleccione esta opción para actualizar el padre predeterminado de un tipo de entidad existente único; por ejemplo, si ha suprimido un repositorio y el tipo de entidad señala al repositorio suprimido, tendrá que actualizar la información para señalar a un nuevo repositorio. |
| Tarea | Descripción |
|---|---|
| Añadir un repositorio LDAP federado a la configuración VMM | Seleccione esta opción para añadir un servidor LDAP al repositorio federado. Esta tarea no cambia la asignación de seguridad actual; por lo tanto, el usuario de administración definido durante la instalación sigue activo. |
| Añadir un repositorio de base de datos federado a la configuración VMM | Seleccione esta opción para añadir una base de datos al repositorio federado. Esta tarea no cambia la asignación de seguridad actual; por lo tanto, el usuario de administración definido durante la instalación sigue activo. |
| Añadir un registro de usuarios personalizado federado | Seleccione esta opción para añadir un registro de usuarios personalizado que su empresa creara en el repositorio federado. Esta tarea no cambia la asignación de seguridad actual; por lo tanto, el usuario de administración definido durante la instalación sigue activo. |
| Tarea | Descripción |
|---|---|
| Cambiar el registro de usuarios donde se almacenan los usuarios y los grupos | Esta tarea cambia el repositorio predeterminado donde se almacenan nuevos grupos y usuarios. |
| Cambiar administrador de WebSphere Application Server | Esta tarea cambia el ID de usuario y la contraseña del administrador de WebSphere Application Server que se han definido durante la instalación por el nuevo ID de usuario y la nueva contraseña que necesita el entorno de producción autónomo o en clúster. |
| Cambiar administrador de WebSphere Portal Server | Esta tarea cambia el ID de usuario y la contraseña del administrador de WebSphere Portal que se han definido durante la instalación por el nuevo ID de usuario y la nueva contraseña que necesita el entorno de producción autónomo o en clúster. |
| Suprimir un repositorio federado de la configuración de VMM | Esta tarea suprime el repositorio predeterminado basado en archivos de la configuración. |
| Tarea | Descripción |
|---|---|
| Actualización del registro de usuarios LDAP federado | Seleccione esta opción para actualizar determinados parámetros, como el ID de enlace y la contraseña, para solucionar los problemas del registro de usuarios LDAP. |
| Actualización del registro de usuarios de base de datos federado | Seleccione esta opción para actualizar determinados parámetros, como el nombre de origen de los datos, el URL de la base de datos y el tipo de base de datos para solucionar los problemas con el registro de usuarios de la base de datos. |
| Crear un dominio nuevo | Seleccione esta opción para crear un dominio, que es un grupo de usuarios de uno o varios registros de usuarios que forma un grupo coherente en WebSphere Portal. Los dominios permiten una gestión de usuarios flexible con diversas opciones de configuración. Un dominio debe estar correlacionado con un portal virtual para permitir que los usuarios definidos se registren en el portal virtual. En un repositorio federado, puede crear varios dominios. |
| Base de datos de extensión de propiedades; antes conocida como base de datos Lookaside | Seleccione esta opción para almacenar los atributos adicionales en la extensión de propiedades VMM, en lugar de en el registro de usuarios LDAP. Algunas aplicaciones, como el portlet Common Mail y IBM Lotus Web Content Management utilizan la base de datos de extensión de propiedades para almacenar los atributos adicionales. Después de habilitar la base de datos de extensión de propiedades, puede añadir atributos para satisfacer sus necesidades empresariales. |
| Crear el tipo de entidad | Seleccione esta opción si desea utilizar un tipo de entidad que exista en WebSphere Portal, pero no en el registro de usuarios LDAP. Esta opción crea el tipo de entidad del registro de usuarios y añade el nombre distinguido relativo (RDN) para correlacionar el tipo de entidad entre WebSphere Portal y el registro de usuarios. |
| Actualizar un tipo de entidad existente | Seleccione esta opción para actualizar el padre predeterminado de un tipo de entidad existente único; por ejemplo, si ha suprimido un repositorio y el tipo de entidad señala al repositorio suprimido, tendrá que actualizar la información para señalar a un nuevo repositorio. |
IBM WebSphere Application Server incluye VMM (Virtual Member Manager), que IBM WebSphere Portal utiliza para acceder a la información de usuarios y grupos. VMM proporciona una interfaz que permite la comunicación entre WebSphere Portal y cualquier repositorio, ya sean repositorios federados, un repositorio autónomo su propio registro de usuarios personalizado.
VMM (Virtual Member Manager) es un componente abstracto dentro de la infraestructura de WebSphere Application Server. Como ilustra el diagrama siguiente, WebSphere Portal utiliza la SPI (System Programming Interface Portal) de PUMA (User Management Architecture) para recuperar y establecer atributos en objetos de usuario. PUMA pasa estas peticiones a VMM que, a continuación, pasa las peticiones a un adaptador de registro correspondiente que conecta VMM al repositorio.
Una implementación predefinida de la interfaz UserRegistry que da soporte a múltiples repositorios. Para comunicarse con los repositorios federados, tanto WebSphere Application Server como WebSphere Portal entregan todas las operaciones a la VMM.
Una implementación predefinida de la interfaz UserRegistry donde el repositorio es un único directorio LDAP. WebSphere Application Server se comunica directamente con el LDAP autónomo. WebSphere Portal se comunica con el LDAP autónomo mediante VMM.
VMM ofrece una interfaz SIP (Service Provider Interface) wim.Repository, que habilita las comunicaciones con los repositorios. WebSphere Application Server utiliza esta SPI para conectarse con los repositorios federados. WebSphere Portal utiliza esta SPI para conectarse con todos los repositorios, ya sean federados o autónomos.
Una implementación de la SPI de VMM que permite que VMM se conecte con un repositorio específico, ya sea un directorio LDAP, una base de datos, archivos u otro repositorio. Los adaptadores de registros habilitan las comunicaciones entre WebSphere Portal y cualquier repositorio.
Un dominio es una recopilación de usuarios o de grupos de una o más ramas de su árbol de repositorios. Estas ramas pueden formar parte de un único repositorio, como por ejemplo un registro de usuarios LDAP, o puede ser una combinación de varios registros de usuarios. Un dominio se correlaciona con un portal virtual para permitir que la población de usuarios del dominio inicie sesión en el portal virtual. Esta funcionalidad le permite definir las áreas de WebSphere Portal a las que solo puede acceder un conjunto limitado de usuarios.
Por ejemplo, si pertenece a una empresa internacional con empleados en Asia, Europa, EE.UU y Canadá, puede tener una aplicación o información que sólo sea aplicable a un subconjunto de estos empleados. Puede crear un subconjunto de empleados y crear un portal virtual que contenga la aplicación o información para ese dominio. Los usuarios de un dominio no pueden acceder a otro dominio a menos que también sean miembros de dicho grupo. Por el usuario wpsadmin no podrá iniciar sesión en un portal virtual a menos que sea miembro del dominio correspondiente.
La ampliación de propiedad, conocida anteriormente como base de datos Lookaside, le permite almacenar atributos de usuario adicionales en un almacén de base de datos sin afectar al registro de usuarios de fondo. Puede utilizar la Ampliación de propiedad si el LDAP es de solo lectura, pero tiene un requisito que permite a los usuarios especificar un atributo adicional, como Huso horario. Puede almacenar este atributo adicional en el almacén de bases de datos. También puede añadir atributos adicionales a una aplicación si no cambia el esquema del repositorio.La ampliación de propiedad se puede utilizar con un repositorio federado, un registro de usuarios LDAP autónomo o un registro de usuarios personalizado.
Para aumentar la capacidad y la disponibilidad, los servidores de portal múltiples se pueden agrupar en clúster utilizando IBM WebSphere Application Server Network Deployment. En un clúster, los portales comparten una configuración común y la carga se distribuye uniformemente en todas las instancias de clúster.
IBM WebSphere Portal viene de forma estándar con WebSphere Application Server Network Deployment, una distribución de IBM WebSphere Application Server que proporciona un tipo de servidor del Gestor de despliegue para gestionar y agrupar en clúster de forma centralizada una serie de servidores. Agrupar en clúster una serie de servidores de portal significa que todas las instancias de portal comparten la misma configuración, incluida la base de datos, las aplicaciones y los portlets, y el diseño del sitio. El clúster proporciona un dominio contra el que se realizan muchas acciones administrativas una vez y se sincronizan con cada servidor del clúster. Esto simplifica la administración, a la vez que asegura que todos los miembros del clúster están configurados y se comportan de forma idéntica.
Un clúster de servidores también proporciona un dominio compartido en el que los datos de la memoria caché y de la sesión se pueden replicar y mantener coherentes en todos los miembros del clúster. El clúster también proporciona un mecanismo de sincronización de aplicaciones que asegura la gestión coherente de aplicaciones (iniciar, detener, actualizaciones, etc.) en todo el clúster.
WebSphere Application Server proporciona un plug-in de servidor HTTP que equilibra el tráfico de usuarios en todos los miembros del clúster y, a través de una función llamada “afinidad de sesiones”, asegúrese de que un usuario se mantiene unido a una instancia de clúster específica durante el tiempo que dure su sesión, para mejorar la eficiencia y el rendimiento. De forma adicional, en el caso de que un miembro del clúster esté fuera de servicio, las funciones de gestión de carga de trabajo del plug-in reconocerán que la instancia ya no está disponible y direccionará el tráfico a su alrededor.
Hay dos tipos de clústeres: clústeres verticales y horizontales. La mayoría de los despliegues a gran escala son una mezcla de los dos tipos de clúster.
También es posible desplegar clústeres múltiples de portal para mejorar la disponibilidad, la migración tras error y la recuperación tras desastre.
Se recomienda que revise los temas Limitaciones y directrices de clústeres para obtener más información sobre lo que implica la configuración de un clúster.
Al preparar la configuración de clústeres de WebSphere Portal, debe tener en cuenta la planificación de clúster necesaria para los nodos de WebSphere Application Server. Si no está familiarizado con la agrupación en clúster de WebSphere Application Server, encontrará recursos aquí para ayudarle iniciarse en ello.
En WebSphere Application Server, un clúster se compone de varias copias idénticas de un servidor de aplicaciones. Un miembro del clúster es un solo servidor de aplicaciones del clúster. WebSphere Portal está instalado como servidor de aplicaciones de empresa dentro de la infraestructura de WebSphere Application Server. Todas las características de agrupación en clúster disponibles dentro de la infraestructura de WebSphere Application Server también se encuentran disponibles y son válidas para WebSphere Portal. De este modo, un clúster de WebSphere Portal es simplemente una recopilación de varios servidores de WebSphere Portal que tienen una configuración idéntica.
Para obtener información de planificación adicional, consulte la versión adecuada de IBM WebSphere Application Server Network Deployment en el sitio web http://www.ibm.com/software/webservers/appserv/was/library/.
CHGJRN JRN(Su nombre BD DB2/QSQJRN) DLTRCV(*YES)
Su nombre BD DB2 es el valor de la propiedad release.DbName, situada en el archivo wkplc_dbdomain.properties.
Se aplican las siguientes limitaciones al configurar un clúster de WebSphere Portal:
En un entorno en clúster, todas las solicitudes de una sesión particular se dirigen a la misma instancia de servidor del clúster. Es decir, cuando un usuario ha establecido una sesión (por ejemplo, iniciando sesión), toda la sesión estará servida por la misma instancia de servidor. Para verificar qué servidor maneja las solicitudes del usuario de una sesión, puede visualizar el portlet de valores globales, que muestra el nombre del nodo del servidor que maneja las solicitudes. Si uno de los servidores del clúster falla, la solicitud se direcciona a otro servidor del clúster. Si está habilitado el soporte de sesiones distribuidas (ya sea mediante sesiones persistentes o réplicas de sesión de memoria a memoria), el nuevo servidor tendrá acceso a la información de sesión desde la base de datos u otra instancia del servidor.
El soporte de migración tras error predeterminado está disponible para WebSphere Portal y todos los portlets instalados con el producto. Para aprovechar el soporte de migración tras error con los portlets que usted mismo ha desarrollado, debe asegurarse de que los portlets se han implementado de acuerdo con los mejores métodos.
Los datos que se almacenan en la memoria JVM y no están gestionados por el servidor de aplicaciones o el servidor de WebSphere Portal para réplica puede perderse en caso de migración tras error. Incluso con el soporte de sesión distribuida, durante una anomalía, los usuarios no podrán recuperar la información no confirmada que no esté almacenada en las sesiones o en otras áreas de datos replicadas (como un mapa distribuido o parámetros de representación). En tales casos, los usuarios tienen que reiniciar una transacción después de que se produzca una migración tras error. Por ejemplo, si se encuentra en el proceso de trabajar con un portlet y ha navegado por distintas pantallas cuando se produzca la migración tras error, deberá volver a situarse en la pantalla inicial en la que tendrá que repetir los pasos anteriores. Igualmente, si está intentando desplegar un portlet cuando se produce la migración tras error, puede que el despliegue no sea correcto, caso en el que deberá volver a desplegarlo. La validez de las sesiones de inicio de sesión de usuario se mantiene, a pesar de las anomalías en los nodos con el soporte para sesiones distribuidas habilitado.
En casos en los que un portlet no soporte sustituciones de anomalía, aparecerá un mensaje "Portlet no disponible" después de que se produzca aquella. Si un portlet soporta una migración tras error parcial o incompleta, algunos datos visualizados por el portlet antes de aquella podrían desaparecer posteriormente, o puede que el portlet no funcione según lo esperado. En casos así de extremos, el usuario debería cerrar la sesión y volver a iniciarla para reanudar un funcionamiento normal.
Después de que se produzca una migración tras error, el plug-in del servidor web vuelve a dirigir la solicitud a otro miembro del clúster. La mayoría de los navegadores emitirán una solicitud GET como respuesta a una redirección después de enviar una solicitud POST. De esta forma se garantiza que el navegador no envíe los mismos datos varias veces sin que el usuario lo sepa. No obstante, esto significa que después de una migración tras error, los usuarios deberían renovar la página del navegador o volver a enviar el formulario para recuperar los datos POST.
Cuando configure soporte de sesión distribuida en WebSphere Application Server, ya sea para replicación de sesiones persistentes o de sesiones memoria a memoria, puede configurar el valor Parámetros de ajuste personalizado para determinar qué atributos de sesión se replican y con qué frecuencia tiene lugar la replicación. Puede seleccionar un nivel de ajuste desde "Muy alto" para optimizar para rendimiento o "Bajo" para optimizar para la migración tras error.
Para que se conserve la información de sesión tras una migración tras error cuando utilice el portlet Web Content Authoring, el nivel de ajuste personalizado se debe establecer de forma que se graben todos los atributos de sesión.
Por ejemplo, si la frecuencia de grabación se establece en "Basada en tiempo" con una frecuencia de 10 segundos, los cambios en la sesión del portlet Web Content Authoring 10 segundos antes de la migración tras error se perderán. Si la frecuencia de grabación se establece como "Finalización del servicio servlet", la sesión del portlet Web Content Authoring se mantendrá intacta tras la migración tras error.
Durante una condición de migración tras error, un usuario de Web Content Management deberá volver a situarse en la pantalla inicial de la navegación y renovar la ventana de navegador. Puede que se pierdan datos no confirmados que se almacenen en sesiones o en otras áreas de datos replicadas. Sin embargo, apartede estos problemas, no debería haber pérdidas de servicio y el usuario debería poder seguir trabajando.
Para comunicarse con una base de datos, los servidores que ejecutan IBM i pueden utilizar uno de estos dos controladores JDBC: el controlador JDBC de IBM Toolbox para Java JDBC o el controlador JDBC de IBM Developer Kit para Java (también denominado controlador JDBC nativo). El controlador JDBC que debe utilizar depende de cómo vaya a configurar el entorno en clúster.
| Topología de escalada | Consideraciones sobre el controlador JDBC |
|---|---|
| Escalado vertical | Cuando configure un clúster vertical, puede instalar la base de datos localmente en la misma máquina que el portal o remotamente en una máquina diferente.
Utilice el controlador JDBC adecuado, en función de donde haya instalado la base de datos.
|
| Escalado horizontal | Cuando configure un clúster horizontal, debe utilizar el controlador JDBC de IBM Toolbox para Java. En la configuración típica, se utiliza una base de datos remota para los nodos primario y secundario del clúster. Si lo desea, puede utilizar la base de datos local para el nodo primario y configurar los nodos secundarios para que utilicen dicha base de datos, como haría con cualquier base de datos remota. No obstante, independientemente de si elige incluir una base de datos local en el entorno o no, debe utilizar el controlador JDBC de IBM Toolbox para Java con el clúster horizontal. |
db2_iseries.DbDriver=com.ibm.as400.access.AS400JDBCDriver
db2_iseries.DbDriverType=4
Complete el resto de la configuración tal como se describe. Cuando configure nodos secundarios en este caso de ejemplo, realice la configuración de la base de datos tal como lo haría para una base de datos remota, utilizando el nombre de host del nodo primario para la transferencia de bases de datos.
El modelo de seguridad en IBM WebSphere Application Server y IBM WebSphere Portal afecta a la planificación e implementación de la seguridad en un clúster. La seguridad se habilita de forma predeterminada para el gestor de despliegue de WebSphere Application Server; WebSphere Portal no intentará cambiar los valores de seguridad en la célula del gestor de despliegue cuando se federe un nodo. Esto significa que cualquier configuración de seguridad existente de un WebSphere Portal autónomo se sustituirá por los valores de seguridad de la célula del gestor de despliegue cuando el WebSphere Portal autónomo se una a dicha célula. Si elimina el nodo de la célula del gestor de despliegue, se restablecerán los valores de seguridad originales.
En un clúster se pueden utilizar muchas opciones de seguridad. Se pueden utilizar todas las opciones de seguridad federadas de VMM, incluidos varios repositorios LDAP, repositorios de bases de datos y el repositorio predeterminado basado en archivos. Adicionalmente, existe la opción de utilizar seguridad LDAP autónoma en vez del método de seguridad federado de VMM.
WebSphere Portal proporciona varias tareas de seguridad que pueden utilizarse para modificar los valores de seguridad de WebSphere Application Server y realizar las actualizaciones necesarias en la configuración de WebSphere Portal en un solo paso. En cuanto un nodo de WebSphere Portal se federa en una célula del gestor de despliegue, todas las tareas de seguridad de WebSphere Portal ejecutadas actualizarán la configuración de seguridad en la célula del gestor de despliegue. Ejecute tareas de seguridad tras federar el nodo WebSphere Portal porque la célula del Gestor de despliegue no contiene recursos de configuración necesarios para ejecutar las tareas de seguridad.
Las tareas de “Configuración de un entorno de producción en clúster” recomiendan que se configure la seguridad antes de configurar los nodos adicionales. Si configura la seguridad después de configurar los nodos adicionales o si necesita actualizar la configuración de seguridad después de haber creado el entorno en clúster, tendrá que ejecutar una tarea adicional para actualizar los valores de seguridad en los nodos secundarios; consulte el apartado "Configuración de la seguridad después de la creación de clústeres" para obtener más información.
Al configurar un clúster, existen dos casos de ejemplo que deben considerarse. Existe seguridad predeterminada que se utiliza cuando configura por primera vez el entorno de clúster donde el gestor de despliegue no ha configurado los valores de seguridad. El segundo caso de ejemplo se produce cuando un gestor de despliegue existente ya ha configurado los valores de seguridad antes de que un nodo se una a una célula.
El primer caso de ejemplo se produce cuando la seguridad del repositorio basada en archivos de VMM (Virtual Member Manager) predeterminado se utiliza tanto en los nodos de WebSphere Portal como en el gestor de despliegue. Cuando el nodo de WebSphere Portal se federa en la célula del gestor de despliegue, los valores de seguridad del nodo se sustituyen por los valores de seguridad del gestor de despliegue. Por lo tanto, antes de federar el primer nodo de WebSphere Portal en la célula, el grupo necesario para los administradores de WebSphere Portal y el usuario administrativo debe definirse en el repositorio de seguridad del gestor de despliegue; por ejemplo, wpsadmins y wpsadmin. De lo contrario, el grupo de administradores de WebSphere Portal y el usuario administrativo se perderán cuando se federe el nodo en el gestor de despliegue.
El segundo caso de ejemplo es cuando la célula del gestor de despliegue existente ya ha modificado sus valores de seguridad predeterminados antes de que el primer nodo de WebSphere Portal se uniera a la célula. WebSphere Portal soporta la función de utilizar dos conjuntos distintos de ID de usuario administrativo y credenciales de contraseña al federar un nodo de WebSphere Portal en una célula, un conjunto para la autenticación de nodo de WebSphere Portal y un conjunto para la autenticación del gestor de despliegue. Esto significa que no es necesario definir un ID de usuario administrativo común antes de que WebSphere Portal se una a la célula. Si la célula del gestor de despliegue utilizan una VMM federada con repositorios adicionales, los valores de seguridad del nodo del portal se sustituyen por los valores de seguridad federados de VMM del gestor de despliegue que se han modificado. Los valores de seguridad del entorno autónomo se conservarán preserved y volverán a los valores originales si elimina el nodo del clúster.
Si la célula del gestor de despliegue utiliza seguridad LDAP autónoma, será necesario configurar los valores de LDAP en los archivos de propiedades de WebSphere Portal antes de la federación. Esto permite adaptar de forma dinámica WebSphere Portal con los valores de seguridad de LDAP autónomo de la célula. Al igual que en el primer caso de ejemplo, una vez configurado el clúster se pueden realizar cambios de seguridad en los valores de seguridad de la célula del gestor de despliegue mediante las tareas de seguridad de WebSphere Portal, y se pueden añadir a la célula nodos de WebSphere Portal adicionales siguiendo los mismos procedimientos.
Si está configurando la seguridad para IBM WebSphere Portal con un gestor de seguridad externa, revise algunas consideraciones adicionales, dependiendo del gestor de seguridad externa que esté utilizando. Realice la configuración para un gestor de seguridad externa después de haber completado toda la demás configuración, asegurándose de que el clúster de WebSphere Portal esté en funcionamiento. Además, revise el archivo "Requisito de los sistemas" para asegurarse de que está utilizando un nivel soportado del software del gestor de seguridad externa.
Las siguientes consideraciones se aplican a todos los gestores de seguridad externa:
Este valor se puede establecer globalmente para todos los miembros del clúster utilizando la propiedad com.ibm.websphere.security.webseal.configURL a la que se accede desde la consola de administración del gestor de despliegue pulsando . Dado que la configuración del gestor de despliegue no es sensible al tipo de sistema de archivos de cada nodo, el valor de la propiedad configURL se debe resolver en cada nodo como se ha especificado en la consola de administración.
Asegúrese de que ha instalado y validado los binarios de eTrust SiteMinder en cada nodo del clúster.
si únicamente está utilizando eTrust SiteMinder para autenticación, instale y valide el agente del servidor de aplicaciones.
Si está utilizando eTrust SiteMinder para autenticación y autorización, se deben instalar y validar el agente de servidor de aplicaciones y SDK.
Obtenga una visión general de los conceptos asociados con la configuración de varios clústeres. Múltiples clústeres son conjuntos de servidores que se gestionan conjuntamente en un único dominio administrativo conocido como célula y participan en la gestión de la carga de trabajo.
El objetivo de un administrador es gestionar tantos productos WebSphere Portal y productos basados en portal dentro de la misma célula gestionada como sea posible, para aprovechar dichos dispositivos de tiempo de ejecución y de administración.
WebSphere Portal permite federar varios portales configurados independientemente en la misma célula. Aunque haya limitaciones para este soporte, esto permite que se gestionen varios clústeres de manera conjunta, donde puede que un portal proporcione aplicaciones o servicios distintos a los de otro portal. Con una identidad de servidor común en el servidor web, estos servicios y aplicaciones se pueden integrar perfectamente en el navegador mediante lo último en tecnología Web 2.0 (por ejemplo, mediante el uso de los servicios REST y Ajax).
Normalmente cuando se instala una aplicación empresarial que se va a compartir entre varios clústeres, el administrador simplemente instala el archivo de aplicación empresarial (EAR) en el servidor de gestión de célula, el Deployment Manager, y, a continuación, correlaciona la aplicación con los clústeres de destino en los que se va a ejecutar. Dado que WebSphere Portal instala varias aplicaciones empresariales como parte de su configuración básica y generalmente antes de que se defina ningún clúster, deben seguirse pasos especiales para garantizar que estas aplicaciones de infraestructura sean compartidas correctamente cuando varios clústeres de WebSphere Portal se definan dentro de la misma célula. Asimismo, al tratarse de aplicaciones de infraestructura, todos los clústeres basados en WebSphere Portal deben estar en la misma versión.
Puesto que los portlets son aplicaciones empresariales de un tipo especial, es posible, aunque no siempre adecuado, compartir los portlets en varios clústeres. Muchos portlets (por ejemplo, la administración de WebSphere Portal) se consideran parte de la infraestructura y, por lo tanto, pueden compartirse en varios clústeres. La mayoría de los portlets de aplicaciones de usuario final son específicos de ciertos clústeres y se instalan del modo correspondiente. Consulte la sección que trata sobre los procedimientos recomendados para el despliegue de portlets a fin de obtener información más detallada.
Asimismo, la configuración de seguridad de J2EE de la célula es compartida por todos los servidores y clústeres gestionados en la célula. Por lo tanto, cada servidor y cada clúster deben compartir el mismo repositorio de usuarios subyacente, en el que se autentican los usuarios cuando utilizan una aplicación alojada en cualquier servidor y/o clúster de la misma célula.
Puede crear un clúster dinámico de IBM WebSphere Virtual Enterprise para ejecutar IBM WebSphere Portal.
Para cada nodo que forme parte del clúster dinámico, siga las instrucciones para instalar y configurar WebSphere Portal en un entorno de producción utilizando WebSphere Virtual Enterprise como gestor de despliegue. No obstante, no ejecute la tarea para configurar un clúster estático. Después de instalar y preparar todos los nodos, siga las instrucciones proporcionadas para configurar un grupo de nodos de WebSphere Virtual Enterprise y un clúster dinámico para WebSphere Portal.
El componente WebSphere Virtual Enterprise On Demand Router (ODR) proporciona posibilidades como equilibrio de la carga de trabajo, priorización, supervisión de estado y operaciones dinámicas para clústeres dinámicos. Se puede configurar un ODR para proporcionar direccionamiento multi-clúster, incluyendo clústeres dinámicos localizados en células remotas, y direccionamiento a otros servidores que no ejecuten WebSphere Virtual Enterprise. El ODR puede servir como sustitución de un plug-in de servidor HTTP, pero en muchas configuraciones se utilizan ambos componentes. El servidor HTTP se puede localizar en la zona desmilitarizada, donde sirve contenido estático y proporciona un punto de entrada a la red privada en la que se encuentra ODR.
Consulte Preparación del despliegue de red de WebSphere Application Server para instalar el producto para obtener información sobre el orden de instalación del producto para la preparación para WebSphere Virtual Enterprise y ODR.
Consulte Creación y configuración de ODRs para obtener información sobre la creación de un ODR.
El mantenimiento de IBM WebSphere Portal en un clúster acostumbra a conllevar la aplicación de servicios correctivos (fixpacks y arreglos provisionales) o la actualización del nivel de release del software en cada nodo del clúster. Las instrucciones de aplicación de servicios correctivos a un clúster de WebSphere Portal se proporcionan con el paquete de servicio correctivo. Antes de llevar a cabo cualquier tarea de mantenimiento, es importante analizar siempre cualquier impacto sobre los usuarios finales y asegurarse de que podrá proporcionar servicio ininterrumpido (también conocido como disponibilidad 24 horas al día, los 7 días de la semana), incluso durante la fase de mantenimiento.
Para tratar la información de esta sección, los arreglos se clasifican como "secundarios" si no actualizan las bases de datos de WebSphere Portal subyacentes o si requieren actualizaciones de versión de otro software compatible como, por ejemplo, servidores de base de datos o IBM WebSphere Application Server. La mayoría de los paquetes de servicio de WebSphere Portal no se consideran secundarios y pueden requerir la utilización de un procedimiento de instalación diferente para garantizar la disponibilidad las 24 horas del día, los 7 días de la semana.
Todos los arreglos secundarios de WebSphere Portal en un entorno en clúster pueden desplegarse aplicando simplemente el arreglo en cada nodo del clúster mediante las instrucciones de instalación proporcionadas con el arreglo. No es necesario que elimine el nodo del clúster para aplicar arreglos menores. si lo hace, es posible que no pueda volver a añadir el nodo al clúster. Al aplicar arreglos secundarios que pueden actualizar aplicaciones empresariales desplegadas anteriormente, asegúrese de que desactiva la característica de sincronización automática del gestor de despliegue antes de aplicar el arreglo. Una vez que se haya desplegado el arreglo en todos los nodos del clúster, puede forzar una sincronización manual mediante el gestor de despliegue para garantizar la sincronización de todas las actualizaciones en los nodos. A continuación, puede volver a habilitar la característica de sincronización automática.
Si la documentación asociada con el arreglo secundario requiere el reinicio de WebSphere Portal o de WebSphere Application Server, asegúrese de aplicar el arreglo secundario en un nodo cada vez. De este modo los demás nodos podrán continuar proporcionando servicio a los usuarios finales. Sin embargo, si el arreglo requiere una actualización de las bases de datos de WebSphere Portal, es posible que tenga que detener el clúster antes de aplicar el arreglo. Si éste es el caso, utilice un procedimiento que asegure la disponibilidad ininterrumpida del servicio.
Hay varias formas de instalar Service Packs en un entorno en clúster de WebSphere Portal. El método recomendado utiliza varios clústeres de producción. La instalación de un Service Pack implica la modificación del difusor de direcciones de IP para evitar que un clúster reciba solicitudes de usuario, lo que le permitirá ganar tiempo para finalizar el manejo de las sesiones de usuario existentes, y la actualización del clúster para instalar el Service Pack en todos los nodos. Cuando las pruebas de verificación garanticen que el clúster actualizado está operativo, podrá empezar a recibir tráfico de producción, mientras que el clúster siguiente se lleva fuera de línea para pasar el proceso de actualización. Este método conserva la disponibilidad ininterrumpida durante el proceso de actualización.
Puede utilizar entornos virtualizados, por ejemplo VMWare ESX, para cubrir necesidades de su empresa como la consolidación del servidor de producción, la gestión centralizada o los entornos de prueba dinámicos. El entorno virtual proporciona transparencia a los sistemas operativos, aplicaciones y middleware que funciona sobre el mismo.
Existen consideraciones especiales que se deben tener en cuenta cuando se ejecuta IBM WebSphere Portal en un entorno virtual. Las máquinas virtuales funcionan mejor cuando se utilizan para consolidar servidores de prueba y de desarrollo, donde varias máquinas virtuales pueden compartir recursos de máquinas físicas e incluso pueden "comprometer en exceso" estos recursos, presuponiendo que en un momento determinado no serán necesarios todos los recursos del sistema. Esto no significa que no se puedan utilizar las máquinas virtuales para la producción, pero se debe prestar una atención especial para no comprometer en exceso los recursos que son vitales. Asimismo, debido a la capa de proceso adicional que existe sobre la memoria física del sistema y a que la CPU maneja la conmutación de contexto y la gestión de memoria de las máquinas virtuales, el rendimiento puede comenzar a disminuir cuando su uso es excesivo,si se compara con las instalaciones nativas. Es necesario realizar pruebas detalladas para comprender el rendimiento de WebSphere Portal en su entorno virtualizado y para saber hasta qué punto se ha de escalar WebSphere Portal para compensar cualquier posible disminución del rendimiento.
En los entornos de prueba y desarrollo virtualizados, puede sobrecomprometer los recursos físicos de la máquina. En los entornos de producción, asegúrese de que haya suficiente CPU y memoria para dar servicio a cada máquina virtual. Una buena regla para el requisito de memoria es doblar el tamaño máximo de pila de la instancia de WebSphere Portal y utilizar dicho valor como la configuración de la memoria de la máquina virtual. Se debe evitar estrictamente la paginación de memoria, tanto dentro de la máquina virtual como en el hipervisor, ya que puede disminuir el rendimiento.
IBM WebSphere Portal crea un perfil de configuración de servidor de aplicaciones para representar su configuración de servidor de aplicaciones, como definiciones de orígenes de datos, despliegues de portlets y de aplicaciones web y la configuración de la máquina virtual Java. Un perfil de configuración representa la configuración completa de una única instancia de portal. Varios perfiles le dan la posibilidad de tener varias instancias de portal configuradas de forma independiente y que se ejecutan desde la misma instalación. Antes de WebSphere Portal Versión 7, sólo había un perfil de configuración por instalación, que normalmente se denominaba perfil_wp.
Si desea compartir recopilaciones de búsqueda entre varias instancias del servidor del portal, por ejemplo, en un entorno en clúster o en un entorno de conjunto de servidores del portal, debe configurar un servidor de búsqueda remoto para permitir que se compartan las recopilaciones de búsqueda.
Como método recomendado, debería gestionar todo el mantenimiento en el nivel del clúster. Esto significa que durante la aplicación del mantenimiento a un clúster, todo el clúster debería dejarse fuera de servicio, por lo que los cambios que afecten a todos los clústeres pueden tener lugar sin afectar al tráfico del usuario final ni causar de forma potencial conflictos de sincronización entre recursos gestionados de célula, como aplicaciones empresariales y portlets, y los binarios del producto en el sistema de archivos local. En un entorno de disponibilidad continua, pueden ser necesarios varios clústeres para permitir que el tráfico continúe hasta un clúster mientras se está sirviendo al otro.
El mantenimiento de una instalación de WebSphere Portal con varios perfiles implica la aplicación de mantenimiento a los binarios del producto, así como a cada instancia del perfil. Es importante que todas las instancias de perfil y que los binarios del producto WebSphere Portal estén actualizados al mismo tiempo para evitar conflictos. Si uno de los perfiles de una instalación concreta pertenece a un clúster, siempre que se actualice dicho clúster, los binarios del producto WebSphere Portal compartidos y el resto de los perfiles del sistema deben actualizarse también para mantener la sincronización.
Por lo tanto, en el caso de que varios perfiles del portal que utilicen un único conjunto de binarios del producto se utilicen como parte de una configuración de clúster, es muy recomendable que todos los perfiles que compartan los mismos binarios del producto pertenezcan al mismo clúster para que se mantenga coherentes con el procedimiento recomendado de aplicar mantenimiento en el límite del clúster.
Hay varios métodos de instalación (silenciosa, interfaz gráfica de usuario y consola), opciones (base o completa) y orígenes (CD o imágenes de CD).
Hay dos tipos de instalación: completa y base.
WebSphere Portal proporciona una modalidad ligera del portal que puede mejorar el tiempo de inicio y reducir el consumo de memoria en entornos de producción; consulte para obtener más información.
Seleccione el método de instalación adecuado a su entorno. Puede utilizar un programa de interfaz gráfica, una modalidad de consola o un archivo de respuestas para una instalación silenciosa.
Elija uno de los métodos siguientes para instalar una instalación de 32 bits en un sistema operativo de 64 bits:
| Método | Instrucciones |
|---|---|
| Instalación manual | Instalación manual del
producto IBM WebSphere Application Server de 32 bits.
A continuación, instale WebSphere Portal en la instalación de
WebSphere Application Server existente. Importante: Si tiene un sistema operativo Solaris Versión
9 y selecciona este método manual, DEBE instalar manualmente
el producto WebSphere Application Server de 32 bits
para impedir al instalador la selección automática de un entorno de 64 bits.
|
| Instalación de la línea de mandatos | Especifique el mandato install.bat|sh -W defaults.force32bit=true
para instalar un WebSphere Application Server de 32 bits y WebSphere Portal en un sistema operativo de 64 bits. Nota: Este mandato sólo se admite en los sistemas operativos Windows, AIX, zLinux y Solaris Versión
9.
Importante: Si tiene un sistema operativo Solaris Versión
9, DEBE especificar este mandato para impedir al instalador la selección automática
de un entorno de 64 bits.
Importante para IBM i: Si tiene instalados un
sistema IBM i y una JVM J9 de 32 bits, puede especificar
el parámetro -W enableClassicJVM.active=false a la línea de mandatos para instalar el
servidor de portal con JVM J9 de 32 bits en lugar de con la JVM clásica de 64 bits.
|
Antes de instalar IBM WebSphere Portal, elija la ubicación de origen y el método de instalación que se adapte mejor a su entorno. Por ejemplo, puede realizar la instalación desde el DVD-ROM o desde un sistema de archivos y puede instalar con un programa de interfaz gráfica de usuario o realizar una instalación en modalidad silenciosa.
Se pueden añadir los siguientes parámetros al mandato de instalación para personalizar la instalación de forma que satisfaga sus necesidades empresariales.
IBM WebSphere Portal proporciona opciones de despliegue flexibles, desde una nueva instalación de prueba del producto donde puede examinar y probar funciones hasta una instalación de producción de alta disponibilidad y escalabilidad.
Configure un entorno de producción autónomo cuando no necesite un entorno en clúster robusto. Un despliegue de servidor autónomo es también útil para determinar y validar las necesidades del despliegue. Le permite examinar y probar las funciones y características para decidir cómo conseguir los objetivos empresariales.
Después de completar
la instalación, recuerde ajustar los servidores del entorno del portal
con el objeto de alcanzar un mejor rendimiento. Los casos de ejemplo de ajuste del portal base de la Guía de ajuste de rendimiento de IBM WebSphere Portal y IBM Lotus Web Content Management proporcionan información acerca de cómo ajustar los servicios, bases de datos, directorios y servidores de IBM WebSphere Application Server, WebSphere Portal y más información. Vea información para configurar el sistema operativo para IBM WebSphere Portal. Los otros componentes pueden precisar de pasos adicionales; consulte la documentación del producto de los componentes específicos que desee instalar para obtener más información.
IBM WebSphere Portal se instala como componente individual completo con una base de datos integrada para almacenar información. Esto permite que WebSphere Portal esté activo y en funcionamiento con rapidez para la fase de prueba del producto, en la que puede empezar a montarlo y trabajar con él de inmediato. También puede expandir el entorno para incluir migración tras error de alta disponibilidad, una base de datos más sólida y autenticación basada en LDAP.
Antes de transferir datos predeterminados al servidor de base de datos de producción, debe preparar el servidor de base de datos. La preparación de bases de datos incluye la creación de ID y bases de datos de usuario. Para esta vía de acceso de instalación se utiliza un servidor de producción autónomo y servidores de bases de datos remotos.
Consulte la información sobre la instalación y la configuración de DB2 para trabajar con WebSphere Portal.
Consulte la información sobre la instalación de DB2 para utilizarlo con WebSphere Portal.
Antes de empezar:
Antes de transferir las bases de datos a DB2, en primer lugar se deben crear los grupos y usuarios que se han especificado en wkplc_dbdomain.properties y asignar los usuarios a sus correspondientes grupos. Los nombres de usuario y grupo deben cumplir tanto los requisitos del software del sistema de gestión de bases de datos como los requisitos de WebSphere Portal.
Es necesario modificar los archivos de propiedades apropiados antes de transferir los datos desde la base de datos predeterminada a la base de datos DB2.
Las bases de datos de DB2 que se necesitan para IBM WebSphere Portal se pueden crear de forma local o remota. Cuando las bases de datos de DB2 se crean localmente, se puede hacer con una tarea de configuración o de una forma manual. Cuando las bases de datos de DB2 se crean de forma remota, únicamente se puede hacer de forma manual.
En esta sección se proporciona información sobre cómo utilizar las tareas ConfigEngine para crear bases de datos al utilizar una instalación de DB2 local. Si está utilizando una instalación DB2 remota, debe crear sus bases de datos de forma manual y no mediante la tarea ConfigEngine.
Una base de datos remota reside en un sistema distinto a WebSphere Portal. Cuando se utiliza un servidor DB2 remoto, debe crear manualmente las bases de datos que WebSphere Portal necesita.
Después de haber creado las bases de datos de DB2, las bases de datos se pueden configurar de forma manual o de forma automática mediante una tarea de configuración. La forma en la que se elige realizar la configuración después de haber creado la base de datos DB2 no depende de si se ha creado de forma local o de forma remota.
En esta sección se proporcionan instrucciones para configurar automáticamente su base de datos utilizando la tarea ConfigEngine. Como alternativa a la configuración automática de la base de datos, se pueden crear usuarios y otorgarles privilegios de forma manual. También hay tareas de configuración opcionales que no se le proporcionan con la ejecución de la tarea ConfigEngine.
Este tema proporciona instrucciones para configurar automáticamente su base de datos mediante la tarea ConfigEngine. Como alternativa a la configuración automática de la base de datos, se pueden crear usuarios y otorgarles privilegios de forma manual.
Como alternativa a la configuración automática de la base de datos, se puede configurar manualmente la b ase de datos de DB2 para crear usuarios y otorgarles privilegios de forma manual. Si ha configurado su base de datos automáticamente mediante la ejecución de la tarea ConfigEngine, no necesita ejecutar tareas manuales para la creación de usuarios, permisos o espacios de tabla, pero podría decidir realizar configuración manual adicional para los elementos que no se le proporcionan cuando ejecuta la tarea de ConfigEngine. Por ejemplo, la asignación de espacios de tabla personalizados es una tarea opcional que no cubre la tarea automatizada de ConfigEngine.
Si desea crear esquemas de base de datos, cree una copia de los scripts SQL de plantilla y edite esta copia para crear de forma manual los esquemas de la base de datos. Los scripts SQL de plantilla se deben utilizar como una guía para crear scripts ejecutables puesto que contienen sintaxis SQL no válida.
Para todas las bases de datos, utilice un usuario con derechos de administración en el sistema operativo y la instalación de DB2. Este usuario puede ser el usuario administrativo de la base de datos creado automáticamente por el programa de instalación de DB2. Este usuario es el de la configuración de la base de datos que se utilizará para tareas de configuración: creación de tablas de base de datos y realización de transferencias de base de datos. Si decide que WebSphere Portal también cree las bases de datos, el usuario de la base de datos deberá tener derechos de SYSADM (administrador del sistema). Sólo tiene que crear manualmente un ID de administrador cuando no quiera utilizar un ID de administrador de DB2 existente.
Un nombre de usuario común es db2inst1, pero puede asignar cualquier nombre de usuario siempre y cuando tenga acceso administrativo y cumpla las limitaciones aquí indicadas. No cambie el nombre de usuario después de crearlo.
users admins guests public local
IBM SQL SYS
Consulte las ubicaciones siguientes de las plantillas de script SQL:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/createSchema.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/createSchema.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/createSchema.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/createSchema.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createSchema.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createSchema.sql |
A los usuarios de configuración y base de datos en tiempo de ejecución se les otorga un conjunto distinto de permisos, según si los usuarios son propietarios de esquemas o no. Existe la posibilidad de crear una copia de los scripts de SQL y editar manualmente esta copia para otorgar permisos a los usuarios de base de datos de configuración y de tiempo de ejecución.
Cuando un usuario de base de datos de configuración es un propietario de esquema, a la propiedad domain.DbUser se le asigna el mismo valor que a la propiedad domain.DbSchema, y se crea un rol para un usuario de configuración en cada dominio de la base de datos. Este rol se crea y asigna automáticamente cuando ejecuta la tarea de configuración setup-database. Una alternativa a la creación y asignación de este rol de forma automática, es crear una copia de las plantillas de script SQL que se encuentran en el directorio de instalación de IBM WebSphere Portal para utilizarlas como una guía para crear scripts ejecutables para otorgar permisos de forma manual. Estas plantillas de sólo lectura no se deben modificar y contienen sintaxis SQL que no es válida. Para otorgar privilegios de forma manual, debe crear su propia versión de estos archivos para crear scripts que se puedan ejecutar.
Consulte las ubicaciones siguientes de las plantillas de script SQL para obtener más información sobre los permisos específicos que se otorgan al usuario de base de datos de configuración propietario del esquema:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/createConfigRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToConfigUser.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/createConfigRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToConfigUser.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/createConfigRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToConfigUser.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/createConfigRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToConfigUser.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createConfigRoleForSameSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToConfigUser.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createConfigRoleForSameSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToConfigUser.sql |
Consulte las ubicaciones siguientes de las plantillas de script SQL para el usuario de base de datos de configuración que no es propietario del esquema:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/createConfigRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToConfigUser.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/createConfigRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToConfigUser.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/createConfigRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToConfigUser.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/createConfigRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToConfigUser.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createConfigRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToConfigUser.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createConfigRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToConfigUser.sql |
Cuando el usuario de base de datos de tiempo de ejecución es un propietario de esquema, a la propiedad domain.DbUser se le asigna el mismo valor de las propiedades domain.DbRuntimeUser y domain.DbSchema. El usuario de base de datos de tiempo de ejecución generalmente no crea tablas utilizadas para consultar y manipular datos y, de forma predeterminada, no tiene acceso a dichas tablas. Para otorgar privilegios mínimos a un usuario de base de datos de tiempo de ejecución para trabajar con dichas tablas, hay que proporcionar acceso a esos objetos individualmente. Se crea un rol para usuarios de base de datos en cada dominio de base de datos. Estos roles se crean y asignan automáticamente al ejecutar la tarea de configuración setup-database antes de la transferencia de la base de datos y posteriormente al ejecutar la tarea de configuración grant-runtime-db-user-privileges después de la transferencia de la base de datos. Antes de ejecutar estas tareas de configuración, el usuario de base de datos de tiempo de ejecución sólo puede acceder a la base de datos para validar configuraciones. Una alternativa a la creación y asignación de este rol de forma automática, es crear una copia de las plantillas de script SQL que se encuentran en el directorio de instalación de IBM WebSphere Portal para utilizarlas como una guía para crear scripts ejecutables para otorgar permisos de forma manual. Estas plantillas de sólo lectura no se deben modificar y contienen sintaxis SQL que no es válida. Para otorgar privilegios de forma manual, debe crear su propia versión de estos archivos para crear scripts que se puedan ejecutar.
Consulte las ubicaciones siguientes de las plantillas de script SQL para obtener más información sobre los permisos específicos que se otorgan al usuario de base de datos de tiempo de ejecución propietario del esquema:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/createInitialRuntimeRole.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/createRuntimeRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToRuntimeUser.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/createInitialRuntimeRole.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/createRuntimeRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToRuntimeUser.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/createInitialRuntimeRole.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/createRuntimeRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToRuntimeUser.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/createInitialRuntimeRole.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/createRuntimeRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantExtendedPermissionsToRuntimeRole.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToRuntimeUser.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createInitialRuntimeRole.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForSameSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToRuntimeUser.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createInitialRuntimeRole.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForSameSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToRuntimeUser.sql |
Consulte las ubicaciones siguientes de las plantillas de script SQL para obtener más información sobre los permisos específicos que se otorgan al usuario de base de datos de tiempo de ejecución no propietario del esquema:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/release/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/release/createRuntimeRoleForDifferentSchema.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/community/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/community/createRuntimeRoleForDifferentSchema.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/customization/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/customization/createRuntimeRoleForDifferentSchema.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/createInitialRuntimeRole.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantExtendedPermissionsToRuntimeRole.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/jcr/grantRoleToRuntimeUser.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForDifferentSchema.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForDifferentSchema.sql |
El repositorio de WebSphere Portal consta de muchas tablas e índices que se crean en los espacios de tablas predeterminados. Si utiliza un conjunto de espacios de tabla existente para los objetos del repositorio, especifíquelo al ejecutar la transferencia de la base de datos al sistema de bases de datos de destino.
Si se asignan espacios de tablas personalizados, cada uno se debe asignar de manera explícita. Los espacios de tablas personalizados se pueden utilizar para contener objetos de bases de datos. Sin embargo, el nombre del espacio de tabla predeterminado se debe especificar en los archivos de correlación correspondientes. Esto se aplica a todos los dominios de bases de datos que se transfieren en una única transferencia de base de datos.
Para configurar las asignaciones de espacios de tablas personalizados:
Conozca los pasos para configurar la ordenación JCR para que funcione con la base de datos de DB2. La ordenación JCR es la recomendada cuando los entornos locales de los idiomas de los usuarios no realizan la ordenación nativa de forma correcta en la base de datos de DB2 y cuando el orden correcto en el entorno local del idioma es importante.
Esta sección proporciona información sobre cómo transferir datos de forma manual desde la base de datos predeterminada a la base de datos de Oracle. Siga estos pasos para transferir bases de datos de WebSphere Portal y Java Content Repository a DB2. Como alternativa al procedimiento de transferencia de base de datos manual, puede utilizar el asistente de configuración para completar la tarea de transferencia de la base de datos.
Antes de empezar:
Asegúrese de que se cumplen los siguientes requisitos previos:
Si se está utilizando Web Content Management, se debe actualizar la configuración de la base de datos para que dé soporte a archivos grandes. Para ello, establezca la propiedad fullyMaterializeLobData en la consola administrativa de WebSphere Application Server.
WebSphere Portal precisa del uso del controlador IBM DB2 Legacy JDBC en modalidad de type 2 o del controlador IBM DB2 Universal JDBC en modalidad de type 4, cuando se conecta a DB2.
# db2 (type 2): { jdbc:db2:wpsdb }
# db2 (type 4): { jdbc:db2://<YourDatabaseServer>:50000/wpsdb:returnAlias=0; }
# Para un controlador tipo 2 de DB2, utilice <SQLLIB>/java/db2jcc4.jar # Para un controlador tipo 4 de DB2, utilice <SQLLIB>/java/db2jcc4.jar:<SQLLIB>/java/db2jcc_license_cu.jar
# Para un controlador tipo 2 de DB2, utilice com.ibm.db2.jcc.DB2Driver # Para un controlador tipo 4 de DB2 utilice com.ibm.db2.jcc.DB2Driver
Si WebSphere Portal está instalado en la misma máquina que el servidor DB2 y pasa de una conexión JDBC de tipo 4 a una conexión JDBC de tipo 2, asegúrese de crear los nombres de alias para las bases de datos de DB2, tal y como se describe en el apartado Creación de bases de datos remotas y de que los nombres de alias no estén especificados para las bases de datos del archivo wkplc_dbdomain.properties.
Cuando pase de una conexión JDBC de tipo 2 a una conexión JDBC de tipo 4, elimine los nombres de alias de las bases de datos y consulte directamente las bases de datos. Esto es necesario debido a una limitación en el controlador JDBC universal de DB2.
Para configurar una base de datos IBM DB2 para i remota, cree ID y bases de datos de usuario en un servidor remoto. Se proporcionan tareas para ayudarle a crear los ID y las bases de datos de usuario. Antes de utilizar las tareas, debe modificar los archivos de propiedades.
Aprenda la forma de modificar los archivos wkplc.properties, wkplc_dbdomain.properties y wkplc_dbtype.properties para que funcionen con su base de datos. Modifique estos archivos de propiedades antes de ejecutar las tareas para crear bases de datos y usuarios, o transferir datos.
Consulte la información sobre la configuración de perfiles de usuario para IBM DB2 para i para trabajar con WebSphere Portal.
Esta sección proporciona información sobre la utilización de la tarea ConfigEngine para crear y configurar usuarios y bases de datos de IBM DB2 for i.
Examine los pasos para transferir datos de forma manual a la base de datos IBM DB2 Universal Database para i que se haya configurado. Como alternativa al procedimiento de transferencia de base de datos manual, puede utilizar el asistente de configuración para completar la tarea de transferencia de la base de datos.No obstante, no puede especificar todos los valores a través del asistente de configuración. Por ejemplo, independientemente del método utilizado para transferir datos, debe ejecutar una tarea de configuración para crear los recursos JMS tal como se describe en este tema.
Antes de empezar:
Asegúrese de que se cumplen los siguientes requisitos previos:
Después de configurar WebSphere Portal para que funcione con su base de datos, deberá verificar la conexión para asegurarse de que funciona correctamente.
Para verificar que WebSphere Portal se esté ejecutando desde un navegador, abra el portal en un navegador web: http://hostname.yourco.com:número_puerto/wps/portal, donde hostname.yourco.com es el nombre de host completo de la máquina donde WebSphere Portal se está ejecutando y número de puerto es el puerto de transporte que crea IBM WebSphere Application Server.
Verifique la conexión desde una línea de mandatos siguiendo estos pasos:
Por motivos de seguridad, no debería dejar las contraseñas en el archivo wkplc_dbdomain.properties. Edite el archivo antes de ejecutar una tarea de configuración e inserte las contraseñas que sean necesarias para esa tarea. Una vez ejecutada la tarea, suprima todas las contraseñas del archivo.
Como alternativa, puede especificar la contraseña en la línea de mandatos en lugar de actualizar el archivo wkplc_dbdomain.properties. Por ejemplo: ConfigEngine.sh -DPortalAdminPwd=contraseña -DWasPassword=contraseña validate-database
Cuando instale WebSphere Portal, las contraseñas del archivo wkplc_dbdomain.properties se eliminan automáticamente después de la configuración.
La configuración de la base de datos DB2 para z/OS incluye la creación de los ID de usuario y bases de datos de usuario en un servidor remoto.
Consulte la información sobre cómo instalar DB2 para z/OS para utilizarlo con IBM WebSphere Portal.
export EXTSHM=ON db2set DB2ENVLIST=EXTSHM db2startPara convertir el cambio en permanente, debe añadir la variable de entorno añadiendo lo siguiente al archivo profile.env:
DB2ENVLIST='EXTSHM'en /home/db2inst/sqllib/userprofile añada:
export EXTSHM=ON
Esta sección proporciona información sobre cómo puede modificar los archivos wkplc.properties, wkplc_dbdomain.properties y wkplc_dbtype.properties para que funcionen con su base de datos. Modifique estos archivos de propiedades antes de ejecutar las tareas para crear bases de datos y usuarios, o transferir datos.
db2 subsystem prefix display ddf
Creación de usuarios para que IBM DB2 Universal Database para z/OS funcione con IBM WebSphere Portal. .
Complete la instalación de DB2 para z/OS.
Este tema proporciona instrucciones sobre la forma en la que crear un usuario de base de datos de configuración. Repita los pasos en este tema para crear un usuario de base de datos de tiempo de ejecución.
Siga estos pasos para conceder permisos de acceso a los usuarios de la base de datos. Repita estos pasos para cada instancia de WebSphere Portal que configure.
A los usuarios de configuración y base de datos en tiempo de ejecución se les otorga un conjunto distinto de permisos, según si los usuarios son propietarios de esquemas o no. Existe la posibilidad de crear una copia de los scripts de SQL y editar manualmente esta copia para otorgar permisos a los usuarios de base de datos de configuración y de tiempo de ejecución.
Cuando un usuario de base de datos de configuración es un propietario de esquema, a la propiedad domain.DbUser se le asigna el mismo valor que a la propiedad domain.DbSchema, y se crea un rol para un usuario de configuración en cada dominio de la base de datos. Este rol se crea y asigna automáticamente cuando ejecuta la tarea de configuración setup-database. Una alternativa a la creación y asignación de este rol de forma automática, es crear una copia de las plantillas de script SQL que se encuentran en el directorio de instalación de IBM WebSphere Portal para utilizarlas como una guía para crear scripts ejecutables para otorgar permisos de forma manual. Estas plantillas de sólo lectura no se deben modificar y contienen sintaxis SQL que no es válida. Para otorgar privilegios de forma manual, debe crear su propia versión de estos archivos para crear scripts que se puedan ejecutar.
Consulte las ubicaciones siguientes de las plantillas de script SQL para obtener más información sobre los permisos específicos que se otorgan al usuario de base de datos de configuración propietario del esquema:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/release/createConfigRoleForSameSchema.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/community/createConfigRoleForSameSchema.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/customization/createConfigRoleForSameSchema.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/jcr/createConfigRoleForSameSchema.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2_zos/feedback/createConfigRoleForSameSchema.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2_zos/likeminds/createConfigRoleForSameSchema.sql |
Consulte las ubicaciones siguientes de las plantillas de script SQL para el usuario de base de datos de configuración que no es propietario del esquema:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/release/createConfigRoleForDifferentSchema.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/community/createConfigRoleForDifferentSchema.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/customization/createConfigRoleForDifferentSchema.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/jcr/createConfigRoleForDifferentSchema.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2_zos/feedback/createConfigRoleForDifferentSchema.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2_zos/likeminds/createConfigRoleForDifferentSchema.sql Privilegios necesarios para el usuario de base de datos de tiempo de ejecución |
Cuando el usuario de base de datos de tiempo de ejecución es un propietario de esquema, a la propiedad domain.DbUser se le asigna el mismo valor de las propiedades domain.DbRuntimeUser y domain.DbSchema. El usuario de base de datos de tiempo de ejecución generalmente no crea tablas utilizadas para consultar y manipular datos y, de forma predeterminada, no tiene acceso a dichas tablas. Para otorgar privilegios mínimos a un usuario de base de datos de tiempo de ejecución para trabajar con dichas tablas, hay que proporcionar acceso a esos objetos individualmente. Se crea un rol para usuarios de base de datos en cada dominio de base de datos. Estos roles se crean y asignan automáticamente al ejecutar la tarea de configuración setup-database antes de la transferencia de la base de datos y posteriormente al ejecutar la tarea de configuración grant-runtime-db-user-privileges después de la transferencia de la base de datos. Antes de ejecutar estas tareas de configuración, el usuario de base de datos de tiempo de ejecución sólo puede acceder a la base de datos para validar configuraciones. Una alternativa a la creación y asignación de este rol de forma automática, es crear una copia de las plantillas de script SQL que se encuentran en el directorio de instalación de IBM WebSphere Portal para utilizarlas como una guía para crear scripts ejecutables para otorgar permisos de forma manual. Estas plantillas de sólo lectura no se deben modificar y contienen sintaxis SQL que no es válida. Para otorgar privilegios de forma manual, debe crear su propia versión de estos archivos para crear scripts que se puedan ejecutar.
Consulte las ubicaciones siguientes de las plantillas de script SQL para obtener más información sobre los permisos específicos que se otorgan al usuario de base de datos de tiempo de ejecución propietario del esquema:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/release/createRuntimeRoleForSameSchema.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/community/createRuntimeRoleForSameSchema.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/customization/createRuntimeRoleForSameSchema.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/jcr/createRuntimeRoleForSameSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/jcr/grantExtendedPermissionsToRuntimeRole.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2_zos/feedback/createRuntimeRoleForSameSchema.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2_zos/likeminds/createRuntimeRoleForSameSchema.sql |
Consulte las ubicaciones siguientes de las plantillas de script SQL para obtener más información sobre los permisos específicos que se otorgan al usuario de base de datos de tiempo de ejecución no propietario del esquema:
| Dominio de base de datos | Ubicación de la plantilla |
|---|---|
| Release | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/release/createRuntimeRoleForDifferentSchema.sql |
| Comunidad | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/community/createRuntimeRoleForDifferentSchema.sql |
| Personalización | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/customization/createRuntimeRoleForDifferentSchema.sql |
| JCR | raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/jcr/createRuntimeRoleForDifferentSchema.sql raíz_PortalServer/base/wp.db.impl/config/templates/setupdb/db2_zos/jcr/grantExtendedPermissionsToRuntimeRole.sql |
| Comentarios | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2_zos/feedback/createRuntimeRoleForDifferentSchema.sql |
| Likeminds | raíz_PortalServer/pzn/prereq.pzn/config/templates/setupdb/db2_zos/likeminds/createRuntimeRoleForDifferentSchema.sql |