Lotus Expeditor: Ensamblaje y despliegue de aplicaciones ... · Configuración de la barra lateral de Lotus Expeditor 96 Inhabilitación de menús y de elementos de menú .97 Modificación

Lotus® Expeditor

Ensamblaje y despliegue de aplicaciones de Lotus Expeditor

Versión 6.1.2

��

Lotus® Expeditor

Ensamblaje y despliegue de aplicaciones de Lotus Expeditor

Versión 6.1.2

��

Nota

Antes de utilizar esta información y el producto al que da soporte, lea la información del apartado Avisos.

Nota

Para la comodidad del usuario, se proporciona la versión PDF de esta guía. El sistema de ayuda es el modo preferido para

leer la documentación.

Cuarta edición (Enero de 2008)

Esta edición se aplica al release de la versión 6.1.2 y a todos los releases y las modificaciones subsiguientes hasta

que se indique lo contrario en nuevas ediciones.

© Copyright International Business Machines Corporation 2005, 2008. Reservados todos los derechos.

Contenido

Descripción de la configuración del

entorno de ejecución de Lotus

Expeditor Client . . . . . . . . . . . 1

Configuración de un solo usuario . . . . . . . 1

Configuración multiusuario . . . . . . . . . 2

Servicio de entorno de trabajo restringido . . . . 3

Cliente del Agente de gestión de empresa . . . . 5

Cliente administrado por portal . . . . . . . . 5

Instalación de Network Client . . . . . . . . 5

Descripción de la estructura del archivo de cliente . . 5

Inicio de sesión único con el sistema operativo . . . 6

Valores gestionados . . . . . . . . . . . . 7

Instalación y lanzamiento de Lotus

Expeditor Client . . . . . . . . . . . 9

Instalación de Lotus Expeditor Client en el escritorio 9

Prerrequisitos del cliente . . . . . . . . . 9

Instalación desde un CD . . . . . . . . . 11

Instalación desde una ubicación de red

compartida . . . . . . . . . . . . . 12

Instalación con el Servicio de entorno de trabajo

restringido . . . . . . . . . . . . . . 13

Acceso al sistema operativo . . . . . . . 14

Cambio de valores de cuenta de portal

principal para los usuarios en el entorno de

trabajo restringido . . . . . . . . . . 14

Invocación de una instalación silenciosa . . . . 15

Supresión de Lotus Expeditor Client . . . . . 16

Supresión de datos específicos de usuario . . . 17

Utilización de archivos de opciones . . . . . 17

Utilización de archivos de respuestas . . . . . 19

Personalización de la instalación básica . . . . 21

Alteración temporal de la lista de sitios de

actualización para el suministro de recursos . . 22

Instalación de Lotus Expeditor Client para el

lanzamiento compartido desde una unidad de

red . . . . . . . . . . . . . . . . 22

Alteración temporal de la ubicación del directorio

de espacio de trabajo . . . . . . . . . . 23

Localización del programa iniciador de Lotus

Expeditor Client . . . . . . . . . . . . 24

Descripción de las instalaciones en Microsoft

Windows Vista . . . . . . . . . . . . 25

Lanzamiento de Lotus Expeditor Client en el

escritorio . . . . . . . . . . . . . . . 25

Utilización del daemon RCP y Dcommands . . 26

Descripción de la creación de espacio de trabajo 26

Reutilización de un espacio de trabajo existente 27

Lanzamiento de Lotus Expeditor Client desde

una unidad de red . . . . . . . . . . . 28

Lanzamiento de Lotus Expeditor Client

utilizando una ubicación de espacio de trabajo no

estándar . . . . . . . . . . . . . . 28

Utilización de enlaces a aplicaciones compuestas 28

Instalación de Lotus Expeditor Client en

dispositivos . . . . . . . . . . . . . . 29

Prerrequisitos del cliente . . . . . . . . . 31

Desinstalación . . . . . . . . . . . . 32

Lanzamiento de Lotus Expeditor Client en

dispositivos . . . . . . . . . . . . . . 32

Instalación con Network Client Installer . . . . . 33

Prerrequisitos de cliente de Network Client

Installer . . . . . . . . . . . . . . 33

Instalación de Network Client Installer . . . . 33

Instalación de Network Client Installer al

utilizar SSL con un certificado de prueba

autofirmado . . . . . . . . . . . . 35

Notificación a los usuarios del modo de instalar

desde la Web utilizando Windows y Linux . . . 37


desde la Web utilizando dispositivos soportados . 37

Instalación silenciosa de Network Client Installer 38

Desinstalación de Network Client Installer . . . 38

Desinstalación silenciosa de Network Client

Installer . . . . . . . . . . . . . . 39

Actualización de Network Client Installer . . . 39

Actualización de la información de instalación en

el servidor Web . . . . . . . . . . . . 40

Instalación de Lotus Expeditor Client para

Windows y Linux en Portal . . . . . . . . 40


el cliente de escritorio desde Portal . . . . . 40

Aplicación de actualizaciones . . . . . . . 40

Aplicación de fixpacks y arreglos individuales . . 41

Utilización de archivos de opciones . . . . . 41

Instalación y lanzamiento de Expeditor Client en un

entorno Citrix . . . . . . . . . . . . . 41

Prerrequisitos . . . . . . . . . . . . . 41

Instalación de Expeditor Client en Windows

Server 2003 / Citrix Server . . . . . . . . 42

Configuración de Citrix Presentation Server para

publicar Lotus Expeditor como una aplicación . . 42

Acceso a Lotus Expeditor de forma remota a

través de la interfaz web de Citrix . . . . . . 43

Limitaciones del entorno Citrix . . . . . . . 43

Cambio de la máquina virtual . . . . . . . . 43

Configuración de la plataforma . . . . 47

Configuración de propiedades de sistema Java . . 47

Configuración de argumentos de VM . . . . . . 47

Configuración de referencias de bibliotecas nativas 47

Configuración de bibliotecas bootclasspath de Java 48

Configuración del iniciador de la plataforma . . . 48

Configuración de valores de despliegue . . . . . 51

Cambio de preferencias de despliegue . . . . 51

Configuración de los valores de búsqueda de

actualización . . . . . . . . . . . . . 54

Habilitación e inhabilitación de la interfaz de

usuario de actualización . . . . . . . . . 54

© Copyright IBM Corp. 2005, 2008 iii

||

| | | | | | | | | | | | | | | |

Configuración del orden de búsqueda de

características . . . . . . . . . . . . . 55

Configuración del orden de búsqueda de

características en 6.1.2 . . . . . . . . . . 58

Configuración de la verificación de plug-in

firmado . . . . . . . . . . . . . . . 62

Precarga de certificados para la instalación inicial

y suministro de plug-ins firmados . . . . . . 63

Configuración del contenedor Web . . . . . . 64

Configuración de las propiedades de contenedor

web . . . . . . . . . . . . . . . . 64

Configuración de las propiedades de host virtual

(6.1.2) . . . . . . . . . . . . . . . 66

Configuración de las propiedades de host virtual

(6.1.1) . . . . . . . . . . . . . . . 67

Configuración del contenedor web para utilizar

un puerto dinámico . . . . . . . . . . 68

Configuración con el servicio Administración de

configuración . . . . . . . . . . . . . 68

Configuración de HTTPS . . . . . . . . . 69

Configuración del contenedor web utilizando

SocketConfigService . . . . . . . . . . 69

Habilitación y configuración de la Infraestructura

de canales . . . . . . . . . . . . . . 70

Habilitación y configuración de la

Infraestructura de canales utilizando

extensiones de Eclipse . . . . . . . . . 71

Habilitación y configuración de la

Infraestructura de canales utilizando

propiedades del sistema . . . . . . . . 73

Utilización del archivo de configuración de

Infraestructura de canales . . . . . . . 74

Configuración del contenedor de portlets . . . . 75

Configuración de las preferencias de portlet . . . 76

Configuración de servicios Web móviles . . . . . 76

Instalación de componentes de Web Services

Resource Framework . . . . . . . . . . 76

Configuración de los clientes de servicios web de

Apache Axis . . . . . . . . . . . . . . 77

Configuración de los valores de proxy de cliente

de Apache Axis . . . . . . . . . . . . 77

Configuración de valores gestionados . . . . . 77

Especificación de valores . . . . . . . . . 77

Configuración de proveedores . . . . . . . 80

Configuración de la planificación de

actualización de valores gestionados . . . . . 82

Verificación de que el plug-in de valores

gestionados se inicia . . . . . . . . . . 83

Configuración de la capa de red . . . . . . . 83

Configuración de la aplicación de navegador web 85

Configuración de la sincronización de plataforma . 85

Habilitación de la sincronización y cambio de

prioridad . . . . . . . . . . . . . . 85

Configuración de planificaciones y

desencadenantes de sincronización automática . . 86

Configuración de la seguridad de plataforma . . . 86

Especificación de la configuración de inicio de

sesión de plataforma predeterminada . . . . . 88

Configuración de SSL para la plataforma - 6.1.1 88

Configuración de SSL para la plataforma 6.1.2 . . 89

Configuración de SSL para el Agente de gestión

de empresa . . . . . . . . . . . . . 90

Configuración del soporte SSL del lado del

cliente . . . . . . . . . . . . . . . 92

Configuración de SSL para Servicios Web . . . 92

Configuración de SSL para el contenedor web . . 92

Configuración de SSL para ISync . . . . . . 94

Utilización de SSL desde las aplicaciones . . . 95

Habilitación de los proveedores JCE y JSSE

compatibles con FIPS . . . . . . . . . . 96

Configuración de la ayuda de plataforma . . . . 96

Configuración de la barra lateral de Lotus Expeditor 96

Inhabilitación de menús y de elementos de menú . 97

Modificación de los archivos de configuración de la

plataforma . . . . . . . . . . . . . . . 97

Actualización del archivo rcplauncher.properties 97

Actualización del archivo rcpinstall.properties 101

Configuración del registro y rastreo de

plataforma . . . . . . . . . . . . . 105

Actualización del archivo config.ini en los

escritorios . . . . . . . . . . . . . 107

Actualización del archivo config.ini en los

dispositivos . . . . . . . . . . . . . 108

Actualización del archivo

plugin_customization.ini . . . . . . . . 108

Habilitación del inicio de sesión único de

plataforma . . . . . . . . . . . . . . 109

Gestión de almacén de claves seguro . . . . . 110

Gestión de artefactos de determinación de

problemas . . . . . . . . . . . . . . 110

Cambio del intervalo predeterminado del gestor

de artefactos de determinación de problemas . . 111

Inhabilitación del gestor de artefactos de

determinación de problemas . . . . . . . 111

Gestión de cuentas . . . . . . . . . . . . 111

Creación de cuentas . . . . . . . . . . 112

Gestión de preferencias de Eclipse . . . . . . 114

Gestión de preferencias OSGi . . . . . . . . 116

Gestión de valores de UserAdmin . . . . . . 117

Gestión de valores de ConfigurationAdmin . . . 118

Gestión del ciclo de vida . . . . . . . . . 118

Descripción del ciclo de vida . . . . . . . 118

Contribución de plug-ins en el ciclo de vida de

personalidad . . . . . . . . . . . . 122


aplicación . . . . . . . . . . . . . 122


plataforma . . . . . . . . . . . . . 123

Ensamblaje y despliegue . . . . . . 127

Ampliación de la plataforma . . . . . . . . 127

Especificación de la marca y del tema de la

plataforma . . . . . . . . . . . . . 127

Cómo proporcionar una marca de producto

propia . . . . . . . . . . . . . . 127

Especificación del tema . . . . . . . . 131

Distribución de actualizaciones de marca . . 134

Configuración de la creación de marca del

contenedor de portlets . . . . . . . . 135

Configuración de definiciones de empresa

(JNDI) . . . . . . . . . . . . . . . 136

iv Lotus Expeditor: Ensamblaje y despliegue de aplicaciones de Lotus Expeditor

|||

||

||

| |

Visión general de JNDI de Lotus Expeditor

Client . . . . . . . . . . . . . . 136

Utilización del JNDI declarativo . . . . . 137

EJBObjectFactory . . . . . . . . . 138

GenericObjectFactory . . . . . . . . 138

TxnDataSourceObjectFactory . . . . . 139

WSObjectFactory . . . . . . . . . 140

Ampliación del JNDI declarativo . . . . . 140

Gestión de ciclo de vida del registro JNDI 141

Definición de orígenes de datos gestionados . . 141

Definición de un origen de datos gestionado 145

Definición de un origen de datos gestionado

cifrado . . . . . . . . . . . . . 145


cifrado con autenticación . . . . . . . 146

Definición de una base de datos . . . . . 146

Definición de un esquema de base de datos

para el llenado inicial utilizando una tarea de

base de datos . . . . . . . . . . . 147

Definición de un proveedor de bases de

datos . . . . . . . . . . . . . . 147

Migración de un origen de datos gestionado

a un esquema nuevo . . . . . . . . . 147

Utilización de la capa de red . . . . . . . 147

Adición y configuración de manejadores

personalizados . . . . . . . . . . . 147

Ampliación de la plataforma para la gestión de

propiedades de Device Manager . . . . . . 148

Adición de un proveedor de valores gestionados 149

Definición de cuentas para clientes de servicios

Web de Apache Axis . . . . . . . . . . 151

Definición de ubicaciones . . . . . . . . 151

Definición de conexión de componentes . . . 152

Ampliación del analizador de textos . . . . . 152

Contribución con un diccionario

personalizado . . . . . . . . . . . 153

Contribución con un motor nuevo . . . . 153

Despliegue de IBM Lotus Expeditor Micro

Broker . . . . . . . . . . . . . . . 153

Creación de imágenes de entorno de ejecución

de cliente . . . . . . . . . . . . . . 154

Cómo empezar a crear plataformas . . . . 154

Configuración de la plataforma de destino 155

Creación de una configuración del

Desarrollador de plataformas . . . . . . 155

Exportación de una imagen de entorno de

ejecución de destino . . . . . . . . . 157

Migración de un proyecto del Desarrollador

de plataformas de WebSphere Everyplace

Deployment 6.0 a Lotus Expeditor Client

6.1.x . . . . . . . . . . . . . . 157

Ejecución de una imagen de entorno de

ejecución de destino . . . . . . . . . 157

Configuración del diseño de aplicación . . . . 158

Empaquetado de aplicaciones para el despliegue 158

Descripción del ciclo de vida de las

características . . . . . . . . . . . . 159

Creación de una característica . . . . . . . 161

Control de la ubicación de instalación de

característica . . . . . . . . . . . 162

Habilitación de características para

actualizarlas . . . . . . . . . . . . 164

Exportación de una característica y del

contenido . . . . . . . . . . . . . . 165

Creación de un sitio de actualización . . . . 165

Utilización del manejador de instalación global 166

Creación del archivo de instrucciones de

manejador de instalación . . . . . . . 166

Creación de instrucciones para

actualizaciones de escritorio . . . . . . 169

Adición del manejador de instalación global

a una característica . . . . . . . . . 172

Despliegue de características en la plataforma . . 172

Utilización del manifiesto de suministro . . . 175

Descripción del proceso de fusión del

manifiesto de suministro . . . . . . . 177

DTD de manifiesto de suministro . . . . . 181

Instalación de contenido de idiomas adicional 186

Actualización de características en la plataforma 188

Desinstalación de características en la

plataforma . . . . . . . . . . . . . 189

Contribución a la lista de acciones diferidas . . 190

Despliegue de aplicaciones mediante Web Start . . 190

Aplicaciones y entornos soportados . . . . . 190

Diferencias respecto al soporte de Web Start de

Eclipse . . . . . . . . . . . . . . 191

Soporte multiusuario . . . . . . . . . . 191

Estructura de una aplicación Web Start de Client

Services . . . . . . . . . . . . . . 191

Desarrollo de una aplicación Web Start . . . . 192

Exportación de la aplicación Web Start . . . . 192

Instalación de soporte Web Start en el cliente 193

Despliegue de la aplicación en el servidor . . . 195

Ejecución de una aplicación mediante Web Start 195

Consideraciones acerca de la

internacionalización . . . . . . . . . . 196

Gestión del entorno de ejecución de

cliente . . . . . . . . . . . . . . 197

Gestión utilizando el servidor Device Manager . . 197

Descripción de la gestión con el servidor Device

Manager . . . . . . . . . . . . . . 197

Configuración del Agente de gestión de

empresa . . . . . . . . . . . . . . 197

Utilización del servlet de Agente de gestión

de empresa . . . . . . . . . . . . 203

Instalación del servlet de Agente de

gestión de empresa . . . . . . . . 203

Inicio del servlet de Agente de gestión de

empresa . . . . . . . . . . . . 204

Modificación de la información del

dispositivo . . . . . . . . . . . 204

Modificación de la información de cuenta

del Agente de gestión de empresa . . . 205

Modificación de la información de cuenta

del Agente de gestión de empresa

utilizando el archivo de propiedades . . 205

Conexión al servidor para comprobar

trabajos . . . . . . . . . . . . 206

Supervisión de los sucesos del Agente de


Contenido v

Creación de un trabajo de distribución de

software desde el cliente . . . . . . . 207

Utilización de cuentas del Agente de


Edición de la información del dispositivo

del Agente de gestión de empresa . . . 209

Cambio de las propiedades del Agente de

gestión de empresa . . . . . . . . . . 210

Registro de características con el servidor Device

Manager . . . . . . . . . . . . . . 211

Despliegue de características de Eclipse . . . . 211

Actualización de características con el servidor

Device Manager . . . . . . . . . . . 211

Desinstalación de características de Eclipse . . 212

Despliegue de aplicaciones nativas . . . . . 212

Parámetros necesarios y opcionales (mandato

NativeAppBundle) . . . . . . . . . 212

Opciones de trabajo y tareas para distribuir

paquetes de software nativos (paquetes

OSGi) . . . . . . . . . . . . . . 215

Parámetros de un archivo de texto de

ejemplo (mandato NativeAppBundle) . . . 216

Trabajos de distribución de software nativo

con paquetes OSGi . . . . . . . . . 218

Gestión de preferencias . . . . . . . . . 219

Consulta de preferencias de entorno de

ejecución de cliente . . . . . . . . . 219

Creación de preferencias de entorno de


Actualización de preferencias de entorno de


Supresión de preferencias de entorno de


Gestión de archivos de propiedades . . . . . 220

Consulta de valores de archivo de

propiedades . . . . . . . . . . . . 220

Cambio de un valor de archivo de

propiedades . . . . . . . . . . . . 221

Adición de una propiedad nueva a un

archivo de propiedades . . . . . . . . 221

Supresión de una propiedad de un archivo

de propiedades . . . . . . . . . . . 221

Configuración de los plug-ins de cliente

con el Agente de gestión de empresa . . 221

Configuración del contenedor web

utilizando el Agente de gestión de

empresa . . . . . . . . . . . . 222

Gestión de clientes ricos utilizando el servidor de

Portal . . . . . . . . . . . . . . . . 223

Descripción de la gestión utilizando el servidor

de portal . . . . . . . . . . . . . . 225

Utilización de la plantilla de ejemplo

MyClient de IBM Lotus Expeditor . . . . 226

Configuración del diseño de interfaz de usuario

de cliente . . . . . . . . . . . . . . 226

Utilización del portlet de Administración del

diseño del cliente ricos . . . . . . . . 227

Administración parámetros de página

específicos de cliente rico . . . . . . 227

Creación de una copia del marcador de

vista de cliente rico antes de añadirlo a

una página . . . . . . . . . . . 229

Adición del marcador de vista del cliente

rico a una página . . . . . . . . . 230

Edición de propiedades de cliente rico

comunes para un portlet en una página . 230

Edición o adición de un requisito de

característica para el portlet que

representa una vista de Eclipse . . . . 234

Eliminación de un requisito de

característica para el portlet que

representa una vista de Eclipse . . . . 236

Utilización del portlet de Administración de

Navegador gestionado . . . . . . . . 236

Instalación del portlet de Administración

de Navegador gestionado . . . . . . 237

Creación de una instancia de un portlet de

Administración de Navegador gestionado

en una perspectiva . . . . . . . . 237

Creación de una conexión en el lado del

cliente entre el Navegador gestionado y

otro portlet con capacidad de conexiones . 240

Utilización del portlet de Administración

de Navegador gestionado para ejecutar

una aplicación Web local . . . . . . 242

Utilización del portlet de Administración de

entorno de trabajo . . . . . . . . . . 243

Instalación del portlet de Administración

de entorno de trabajo en un servidor

WebSphere Portal . . . . . . . . . 244

Contribución con una instancia de una

aplicación nativa en el iniciador . . . . 244

Contribución al entorno de trabajo con la

función de bloqueo de pantalla . . . . 245


función de cambio de contraseña . . . . 246


función de cambio de entorno local . . . 247


función de cambio de teclado . . . . . 247


función de lista de tareas . . . . . . 248


función de conclusión del sistema . . . 249


función de fin de sesión de sistema . . . 249

Contribución al entorno de trabajo con el

reloj de barra de estado . . . . . . . 250

Contribución al entorno de trabajo con

una extensión de Eclipse dinámica

personalizada . . . . . . . . . . 251

Asignación de control de acceso a

elementos de iniciador . . . . . . . 251

Utilización del Portlet de habilitación de

visor WSRP de cliente rico . . . . . . . 252

Configuración del Portlet de habilitación

de visor WSRP de cliente rico . . . . . 252

Despliegue de un portlet de habilitación

de visor WSRP de cliente rico . . . . . 254

Registro . . . . . . . . . . . . . . 254

vi Lotus Expeditor: Ensamblaje y despliegue de aplicaciones de Lotus Expeditor

Definición de niveles de control de acceso a

Portal . . . . . . . . . . . . . . 254

Especificación de aplicaciones MyClient . . 255

Gestión de preferencias de cliente rico

utilizando el editor de tipo de política para

preferencias de Eclipse . . . . . . . . . 255

Modificación de un valor en un tipo de

política . . . . . . . . . . . . . 256

Creación de una política hijo para un tipo de

política . . . . . . . . . . . . . 256

Edición de valores en una política hijo . . . 257

Instalación de un nuevo conjunto de

preferencias . . . . . . . . . . . . 257

Gestión de propiedades . . . . . . . . . 258

Gestión utilizando otro sistema de gestión . . . . 258

Configuración de la política de gestor de

actualizaciones . . . . . . . . . . . . 258

Gestión de preferencias . . . . . . . . . 258

Gestión de propiedades . . . . . . . . . 259

Utilización de las interfaces de suministro para

gestionar la plataforma . . . . . . . . . 259

Actualización del manifiesto de suministro

para cambiar la plataforma . . . . . . . 259

Utilización de la aplicación de suministro 260

Utilización de la aplicación de suministro

con DCommands . . . . . . . . . 260


para configuraciones multiusuario . . . 261

Utilización de las API de suministro . . . . 261

Avisos . . . . . . . . . . . . . . 263

Marcas registradas . . . . . . . . . . . . 265

Contenido vii

viii Lotus Expeditor: Ensamblaje y despliegue de aplicaciones de Lotus Expeditor

Descripción de la configuración del entorno de ejecución de

Lotus Expeditor Client

Este apartado describe las configuraciones de entorno de ejecución de Lotus Expeditor Client.

Lotus Expeditor Client está incorporado en una plataforma Eclipse. Eclipse es una galardonada

plataforma de código abierto para la construcción de potentes herramientas de desarrollo de software y

completas aplicaciones de escritorio. Al aprovechar la infraestructura de plug-in de Eclipse para integrar

tecnología en el escritorio, los proveedores de tecnología ahorran tiempo y dinero, pudiendo concentrar

sus esfuerzos en proporcionar productos diferenciados y de gran calidad. Encontrará detalles completos

sobre Eclipse en http://www.eclipse.org.

Configuración de un solo usuario

Puede instalar Lotus Expeditor Client en una configuración de un solo usuario o multiusuario.

La configuración de un solo usuario necesita que instale en un área del sistema de archivos en el que

puede leer y grabar. Una buena elección puede ser el área del espacio de directorio inicial. Si elige otra

área fuera del directorio inicial, es posible que otros usuarios puedan modificar las aplicaciones

instaladas. En cualquier caso, los datos y la información de configuración se almacenarán siempre en el

directorio inicial de forma predeterminada.

Las áreas de configuración y de espacio de trabajo que se crean en el directorio inicial contienen todos los

datos necesarios para personalizar la instalación a medida que la cambia. La configuración se define

durante la instalación. Una configuración consta de todas las aplicaciones que se instalan inicialmente y

hace el seguimiento de los cambios que siguen a la instalación inicial. El espacio de trabajo también

contiene metadatos de plug-in, archivos de registro y datos específicos de aplicación, si están disponibles.

Con la política de configuración sólo gestionada de Lotus Expeditor Client, las configuraciones de

usuarios sólo constan de las aplicaciones y características que se han seleccionado. Cada vez que se crea

una nueva configuración, se inicia un ciclo de suministro, habilitando selectivamente cada característica

que está destinada a esta configuración. Esto se produce la primera vez que un usuario instala Lotus

Expeditor Client o cada vez que se solicita un espacio de trabajo nuevo.

Puede crear espacios de trabajo adicionales. Esto le permite lanzar la misma instalación pero cada espacio

de trabajo se puede personalizar para trabajos diferentes. Para obtener más información, consulte

“Lanzamiento de Lotus Expeditor Client utilizando una ubicación de espacio de trabajo no estándar” en

la página 28.

Se crea un icono de lanzamiento durante la instalación. La instalación de Lotus Expeditor Client sólo

creará un icono de lanzamiento. Puede crear iconos de lanzamiento adicionales que contienen mandatos.

Esto le permite lanzar otro espacio de trabajo o enviar información a una aplicación determinada

seleccionando un icono. Esta acción se puede utilizar para abrir una aplicación en otra ventana de la

instancia en ejecución. Sin esta posibilidad, tendrá que iniciar otra instancia de Lotus Expeditor Client

para lanzar una ventana.

También puede lanzar Lotus Expeditor Client desde la línea de mandatos o un script. Para obtener más

información, consulte “Lanzamiento de Lotus Expeditor Client en el escritorio” en la página 25.

No se soportan el compartimiento de una instalación de un solo usuario con usuarios adicionales. Si

necesita compartir una instalación, se recomienda la instalación multiusuario.

© Copyright IBM Corp. 2005, 2008 1

http://www.eclipse.org

Configuración multiusuario

Puede instalar Lotus Expeditor Client en una configuración de un solo usuario o multiusuario.

La configuración multiusuario está destinada a utilizarse en instancias donde varias personas comparten

una estación de trabajo, por ejemplo una estación de trabajo utilizada como quiosco con inicios de sesión

de sistema operativo individuales.

Un usuario no podrá diferenciar entre el funcionamiento de la configuración de un solo usuario y el de la

configuración multiusuario. Desde el punto de vista del usuario, el funcionamiento de Lotus Expeditor

Client es igual.

En una configuración multiusuario, normalmente los usuarios no instalan aplicaciones. Como

administrador, instale todas las aplicaciones y los usuarios las habilitarán en las configuraciones

individuales. El instalador debe ser miembro del grupo de administradores en Windows o debe estar

definido como root en Linux.

Si desea instalar aplicaciones para un usuario elija entre tres ubicaciones: ${rcp.home}/eclipse,

${rcp.home}/rcp y ${rcp.home}/shared. Como administrador, debe controlar todas estas ubicaciones. Los

usuarios sólo deben tener permisos de lectura y ejecución para estas ubicaciones. La tarea de establecer

los permisos de directorio debe realizarla un administrador, una vez haya finalizado la instalación. Como

administrador, puede instalar varias versiones de la misma característica. Si hay varias versiones, un

usuario podrá seleccionar la versión que desea utilizar.

Un usuario puede instalar aplicaciones en el sitio de usuario privado. En la mayoría de los casos, se le

recomienda que, como administrador, instale estas aplicaciones en el sitio compartido.

Como administrador, sólo deberá instalar aplicaciones cuando no hay usuarios que utilicen Lotus

Expeditor Client.

Siga estos pasos administrativos para la configuración multiusuario:

1. Inicie la sesión como administrador en Windows o como root en Linux.

2. Elija un sitio raíz para el árbol de instalación

3. Cambie los permisos en el sitio raíz de modo que sólo usted pueda escribir en las áreas instaladas.

4. Cree grupos de acceso con permisos de lectura y ejecución solamente.

5. Instale Lotus Expeditor Client en esta ubicación. Seleccione la configuración multiusuario cuando se le

solicite que lo haga durante la instalación.

6. Indique a los usuarios que lancen el icono de escritorio por primera vez. Cuando un usuario lance

inicialmente el icono de escritorio, se iniciará un ciclo de suministro para este usuario. El espacio de

trabajo y el espacio de configuración se inicializan. Para ello, el ciclo de suministro utilizará el archivo

de manifiesto de despliegue. Para obtener más información sobre la personalización de este

manifiesto, consulte “Personalización de la instalación básica” en la página 21.

Lotus Expeditor Client se lanza por primera vez para el usuario. El usuario puede utilizar cualquiera

de los módulos de suministro proporcionados para personalizar el entorno.

7. Instale las aplicaciones o características adicionales que sean necesarias. Esto permitirá a los usuarios

añadirlas a la configuración. No es necesario que los usuarios añadan las nuevas características.

Seguridad

Los sitios de instalación de núcleo (${rcp.home}/eclipse, ${rcp.home}/rcp y ${rcp.home}/shared) y los

sitios adicionales añadidos como sitios <root> deben tener los derechos de acceso controlados. Sólo se

deberá otorgar a los usuarios el acceso de lectura y de ejecución para acceder a esos sitios.

2 Lotus Expeditor: Ensamblaje y despliegue de aplicaciones de Lotus Expeditor

En Windows, los derechos de acceso predeterminados proporcionan a cualquier usuario derechos de

cambio. Esto permite a un usuario añadir archivos al árbol de instalación de Lotus Expeditor Client. Para

una instalación segura, se recomienda que elimine estos derechos de cambio. Si los derechos de cambio

no se eliminan, un usuario puede añadir una característica no fiable a un sitio copiándola. En este punto,

cualquier usuario podría instalarla.

Suministro por primera vez

La primera vez que el entorno multiusuario se instala y configura, seleccione, como administrador, el

nivel de las características base que se deben instalar. Esto establece el nivel base para todos los usuarios.

Cuando un usuario inicia Lotus Expeditor Client por primera vez, la configuración, el espacio de trabajo

y el conjunto de características del usuario se suministran en el mismo nivel que ha seleccionado

inicialmente el administrador. El suministro garantiza que la versión utilizada para una característica sea

la misma o superior.

Este primer suministro sucede una sola vez. A partir de ese momento, la característica establecida se

individualiza para cada usuario según las necesidades.

Suministro e inicialización de la memoria caché JXE -

La memoria caché de archivo JXE, por omisión, se encuentra en ${rcp.home}/rcp. Si esta ubicación es de

sólo lectura para usuarios, cuando el administrador cambie las características instaladas en una ubicación

común (${rcp.home}/eclipse, ${rcp.home}/rcp, y ${rcp.home}/shared.), debe inicializarse la memoria

caché de archivo JXE. La inicialización completa de la memoria caché de archivo JXE es crítica para el

rendimiento del entorno de ejecución de los usuarios. Una vez completados todos los cambios de

suministro, salga de la herramienta de suministro y ejecute el mandato siguiente:

${rcp.home}/rcp/rcplauncher -application com.ibm.jxesupport.initializer.initialize

Una vez haya finalizado, la aplicación de inicialización sale y la memoria caché está completamente

inicializada.

Servicio de entorno de trabajo restringido

Habilite el Servicio de entorno de trabajo restringido para proporcionar un entorno restringido en el que

todos los usuarios de Lotus Expeditor Client estén limitados a las aplicaciones y los servicios de sistema

operativo que, como administrador, haya configurado.

Cuando el Servicio de entorno de trabajo restringido está habilitado y un usuario sin privilegios de

administración inicia la sesión en el sistema operativo, Lotus Expeditor Client se lanza y el Servicio de

entorno de trabajo restringido se habilita automáticamente. Para usuarios no administrativos, Lotus

Expeditor Client sustituye el Explorador de Windows como shell de escritorio en los sistemas Windows.

En sistemas Linux, Lotus Expeditor Client sustituye la sesión predeterminada del gestor de ventanas

GNOME. Se imponen las siguientes restricciones en el entorno de trabajo:

v El entorno de trabajo modifica el comportamiento y el aspecto del modo siguiente:

– No hay barra de título

– No hay bordes de dimensionamiento

– Se maximiza para llenar la pantalla

– Se fija en orden Z de forma que no se pueda dibujar ninguna otra ventana debajo del mismo

– No se puede cerrar, minimizar ni ajustar su tamaño

– La secuencia de menú Archivo → Salir se elimina de la barra de menúsv El usuario no puede obtener acceso al sistema de archivos excepto mediante elementos que

contribuyen a las áreas de contribución compartidas del entorno de trabajo (Coolbar, barra de menús o

barra de conmutador de aplicaciones).

Descripción de la configuración del entorno de ejecución de Lotus Expeditor Client 3

|

||||||

|

||

v El usuario no puede obtener acceso a ninguna aplicación nativa excepto mediante los elementos que

contribuyen al iniciador de aplicaciones.

v El usuario no puede obtener acceso a ninguna función de sistema operativo (por ejemplo, bloqueo de

pantalla, terminación de sesión, conclusión, cambio de entorno local) excepto la utilización de la

combinación de teclas Alt + Tabulador para navegar entre ventanas nativas abiertas y mediante

elementos que contribuyen a las áreas de contribución compartidas del entorno de trabajo (barra de

menús y/o páginas de preferencias de Eclipse)

v El usuario se bloquea al utilizar las siguientes combinaciones de pulsación de tecla:

Windows:

Alt + F4, que cierra la ventana que tiene el foco. Sólo se bloquea en la ventana de Lotus

Expeditor Client; otras ventanas se pueden seguir cerrando con Alt + F4.

Control + Despl + Esc, que abre el Administrador de tareas de Windows. El Administrador de

tareas le permite detener procesos (incluyendo Lotus Expeditor Client).

La tecla de logotipo de Windows + L, que bloquea la pantalla.

Control + Alt + Supr, que visualiza el diálogo de seguridad de Windows. El diálogo de

Seguridad de Windows no está bloqueado pero todos los botones están inhabilitados excepto

Cancelar.

Linux: Alt + Control + Retroceso, que termina la sesión gnome.

Alt + Control + (F1 a F12), que conmuta entre terminales virtuales.

El sistema operativo Windows XP introdujo la noción ″Usar cambio rápido de usuario″ para cambiar las

credenciales pero no cerrar la sesión completamente y salir de todas las aplicaciones en ejecución. Si se

habilitan estos valores, la política de seguridad de sistema también se modifica para proporcionar a los

usuarios una experiencia más simple. Al ejecutar Lotus Expeditor Client en modalidad de entorno de

trabajo restringido, se recomienda inhabilitar los valores de ″Usar pantalla de bienvenida″ y ″Usar cambio

rápido de usuario″ para aumentar adicionalmente el control de administrador sobre el sistema. Por

ejemplo, si se habilitan estos valores y se establece un protector de pantalla, una vez que el protector de

pantalla se activa y, a continuación, se desactiva, se mostrará al usuario un diálogo que le permitirá cerrar

el sistema o finalizar la sesión. Otra modificación está relacionada con la secuencia de teclas Control +

Alt + Supr, que presenta un diálogo de seguridad de Windows. Si se instala el entorno de trabajo

restringido de IBM Lotus Expeditor y se inhabilitan los valores de ″Usar pantalla de bienvenida″ y ″Usar

cambio rápido de usuario″, la única opción disponible para el usuario en este diálogo es Cancelar. Sin

embargo, si las opciones ″Usar pantalla de bienvenida″ y ″Usar cambio rápido de usuario″ están

habilitadas, el usuario podrá de nuevo cerrar el sistema o finalizar la sesión. Al instalar el entorno de

trabajo restringido, estos valores se inhabilitan automáticamente para proporcionar un entorno más

seguro.

Para verificar estos valores, realice los pasos siguientes:

1. Pulse Inicio → Panel de control.

2. Pulse el panel de control de Cuentas de usuario.

3. Pulse Cambiar la forma en la que los usuarios inician y cierran sesión.

4. Modifique las opciones Usar pantalla de bienvenida y Usar cambio rápido de usuario según

corresponda.

5. Pulse Aplicar opciones.

Además, no se deberá utilizar la cuenta predeterminada de administrador de Windows XP para instalar

el entorno de trabajo restringido de IBM Lotus Expeditor. Se recomienda crear una cuenta secundaria de

usuario administrativo y utilizar esta cuenta para instalar el entorno de trabajo restringido.

Para obtener más información, consulte “Instalación con el Servicio de entorno de trabajo restringido” en

la página 13.


Cliente del Agente de gestión de empresa

Puede habilitar las estaciones de trabajo de Lotus Expeditor Client para que las gestione un Lotus

Expeditor Server. Esto es un modo de administrar de forma centralizada el entorno de Lotus Expeditor

Client.

Lotus Expeditor Server contiene el componente servidor Device Manager y proporciona gestión básica de

plataforma del cliente junto con características adicionales, por ejemplo soporte para servidores ISync y

MQe.

Para obtener más información, consulte “Gestión utilizando el servidor Device Manager” en la página

197.

Cliente administrado por portal

Puede habilitar las estaciones de trabajo de Lotus Expeditor Client para recibir información de

configuración de un WebSphere Portal Server. Esto es un modo de administrar de forma centralizada el

entorno de Lotus Expeditor Client.

El contenedor de portlet permite muchas arquitecturas diferentes en la parte del cliente con la

infraestructura de aplicación compuesta. Existen dos modos principales en que las aplicaciones pueden

ejecutarse en el cliente:

v Una aplicación basada en SWT (standard widget toolkit) agregada y desplegada por Portal. Esta

aplicación se compone de vistas basadas en SWT y se coloca en el Portal con los diversos componentes

de vista conectados juntos con la herramienta de conexión de Portal.

v Portlets que se ejecutan localmente. Se pueden ejecutar portlets adecuadamente empaquetados

localmente o fuera de línea en Lotus Expeditor Client. Esta posibilidad, combinada con el intermediario

de propiedades, permite que los portlets que se ejecutan localmente se comuniquen entre ellos.

Entonces, estos diferentes componentes se pueden comunicar entre ellos utilizando la conexión

declarativa expresada en el XML de aplicación compuesto.

Adicionalmente, existe un tercer modo de encapsular aplicaciones Web con otros componentes que

consiste en acomodar el Navegador gestionado en una vista de SWT de Navegador gestionado que

muestre las acciones de intermediario de propiedad y las propiedades. Esto tiene el mismo efecto que

una experiencia conectada tradicionalmente de cualquier portlet o vista que controle otro componente (en

este caso un navegador que admite los URL).

Para obtener más información, consulte el apartado “Gestión de clientes ricos utilizando el servidor de

Portal” en la página 223.

Instalación de Network Client

Instale Network Client Installer para que los usuarios puedan instalar de forma remota Lotus Expeditor

Client, instalar los componentes administrativos necesarios en el servidor de Portal y gestionar Lotus

Expeditor Client.

Consulte el apartado “Instalación con Network Client Installer” en la página 33 para obtener más

información.

Descripción de la estructura del archivo de cliente

Cuando Lotus Expeditor Client se instala en una máquina, el instalador crea una estructura de directorios

en el directorio de instalación. En esta sección se describe la estructura del directorio de instalación que se

instala en la plataforma cliente.


<directorio de instalación>/

_uninst/ - Archivos necesarios para desinstalar únicamente el producto Linux

eclipse/ - Componentes de la plataforma

.eclipseproduct

features/

links/ - Necesario para Toolkit. No utilizado por Expeditor.

plugins/

ITLM/ - Para gestión de licencias

rcp/ - Componentes de la plataforma

_uninst - sólo Linux

deploy/

jxes<versión>

rcplauncher.exe - Iniciador de plataforma

rcplauncher.properties - Archivo de configuración de iniciador de plataforma

startcollector.bat - Utilidad de recogida de registros de IBM Support Assistant (Windows)

startcollector.sh - Utilidad de recogida de registros de IBM Support Assistant (Linux)

eclipse/

.eclipseproduct

features/

plugins/

shared/ - Sitio que contendrá apls compartidas entre varias configuraciones

eclipse/

.eclipseextension

features/

plugins/

license/ - Licencias del producto en varios idiomas

Nota: Los directorios _uninst aparecen cuando se utiliza un instalador ISMP en Linux.

Tareas relacionadas

“Actualización del archivo rcplauncher.properties” en la página 97Este apartado describe cómo puede actualizar uno o más elementos de la plataforma de Lotus

Expeditor Client de un usuario modificando el archivo rcplauncher.properties. Información relacionada

“Configuración del iniciador de la plataforma” en la página 48Puede configurar argumentos adicionales para utilizarlos cuando el usuario lance Lotus Expeditor

Client. Por ejemplo, puede especificar que se visualice una consola al lanzar el cliente.

“Especificación de la marca y del tema de la plataforma” en la página 127El entorno de trabajo de Lotus Expeditor Client utiliza los productos de Eclipse y los temas de Eclipse

para la creación de marca (branding). Debe crear su propio plug-in de marca con la información de

producto en lugar de cambiar el que se envía con Lotus Expeditor Client. Cree una característica de

marca propia y despliéguela como parte de la instalación inicial.

Inicio de sesión único con el sistema operativo

La configuración de la plataforma de IBM Lotus Expeditor para proporcionar el inicio de sesión único

(SSO) con el sistema operativo permite a un usuario, que haya iniciado la sesión en el sistema operativo

satisfactoriamente, obtener acceso a los recursos protegidos por la plataforma de IBM Lotus Expeditor sin

que se le solicite nunca una contraseña.

La plataforma de IBM Lotus Expeditor almacena información relacionada con la seguridad, por ejemplo,

credenciales de autenticación (contraseñas), claves y certificados en el almacén de claves local. Cuando se

habilita el SSO con el sistema operativo, la plataforma de IBM Lotus Expeditor almacena la contraseña

que se utiliza para desbloquear el almacenamiento de credenciales en el almacenamiento de credenciales

nativo del sistema operativo.


Valores gestionados

La infraestructura de valores gestionados le proporciona control sobre el comportamiento del entorno de

ejecución de las aplicaciones de cliente dejándole establecer los valores que las aplicaciones leen del

almacenamiento de preferencias de Eclipse.

Si también designa estos valores como de sólo lectura, se impedirán los cambios que las aplicaciones

cliente realicen en los valores o subsiguientemente los valores se grabarán encima de dichos cambios, en

función de cómo acceda el cliente a los valores. Si el programa cliente conoce los valores gestionados y

accede a ellos mediante el ámbito de preferencias de Eclipse de valores gestionados, se impiden los

cambios en los valores de sólo lectura. Para otros plug-ins, que acceden a los valores del modo

tradicional, se pueden producir cambios pero posteriormente los valores se graban encima de ellos. Las

actualizaciones se ejecutan con regularidad para añadir cualquiera de los valores nuevos o de los cambios

de valores al almacén de preferencias del cliente.

La infraestructura de valores gestionados puede recuperar políticas, preferencias o cualquier otra pareja

de nombre y valor de cualquier sistema de fondo para el que existe un proveedor de valores gestionados.

Los proveedores conocen el sistema de fondo específico. Lotus Expeditor Client incluye proveedores para

recuperar valores del Gestor de políticas de portal y de un archivo XML que reside en un servidor HTTP.

Lotus Notes 8.0 incluye un proveedor para recuperar políticas de Domino utilizando el cliente de Notes.

Si no hay ningún proveedor disponible para el sistema de fondo, puede escribir uno propio. Consulte el

apartado “Adición de un proveedor de valores gestionados” en la página 149 para obtener más

información.

Nota: Los valores gestionados no funcionarán cuando se utilice Portal 6.0.1. Se debe utilizar Portal 6.0 o

Portal 6.0.1.1.

Tareas relacionadas

“Configuración de valores gestionados” en la página 77La infraestructura de valores gestionados le proporciona control sobre el comportamiento del entorno

de ejecución de las aplicaciones de cliente dejándole establecer los valores que las aplicaciones leen del




Instalación y lanzamiento de Lotus Expeditor Client

Este apartado describe cómo instalar y lanzar Lotus Expeditor Client en máquinas cliente.

Existen varios métodos de instalación disponibles. Antes de instalar Lotus Expeditor Client, asegúrese de

que cada máquina en la que va a realizar la instalación cumpla los prerrequisitos de cliente.

Instalación de Lotus Expeditor Client en el escritorio

Este apartado describe cómo instalar Lotus Expeditor Client en el escritorio.

Prerrequisitos del cliente

Asegúrese de que cada máquina en la que piensa instalar Lotus Expeditor Client satisface estos

requisitos.

Client para escritorio

Tabla 1.

Sistema operativo Requisitos mínimos de software Requisitos mínimos de hardware

Windows v Microsoft Windows XP

Professional Service Pack 1

v Microsoft Windows XP Home

Edition Service Pack 1

v Microsoft Windows XP Tablet PC

Edition 2005

v Microsoft Windows 2000

Professional Service Pack 4

v Microsoft Windows Vista (consulte

“Descripción de las instalaciones

en Microsoft Windows Vista” en la

página 25 para obtener más

información)

v Procesadores x86 capaces de

soportar los sistemas operativos

admitidos.

v 512 MB de RAM

v 200 MB de espacio de disco libre

v Resolución de pantalla: Pantalla

SVGA (Super video graphics

array/adapter), 1024 x 768

v Modalidad de alto contraste:

Pantalla 1152 x 768, sólo valores

predeterminados de font (10pt

Sans)

Linux v Red Hat Enterprise Linux 4.0 WS

con soporte GTK - Actualización 4

v Red Hat Enterprise Linux 5.0 WS

con soporte GTK

v SUSE Linux Enterprise Desktop

(SLED 10)

v Procesadores x86 capaces de

soportar los sistemas operativos

admitidos.

v 512 MB de RAM

v 200 MB de espacio de disco libre

v Resolución de pantalla: Pantalla

SVGA (Super video graphics

array/adapter), 1024 x 768

v Modalidad de alto contraste:

Pantalla 1152 x 768, sólo valores

predeterminados de font (10pt

Sans)

Nota: No se soportan los idiomas hebreo y árabe en las plataformas Linux. Además, no se soporta texto

bidireccional (-dir rtl).


IBM Lotus Expeditor necesita Mozilla Firefox o Mozilla Runtime Environment en

Linux

Para utilizar IBM Lotus Expeditor en Linux, primero debe tener instalado el navegador Mozilla.

Seleccione entre los elementos siguientes:

v Mozilla Firefox 1.5.x.x (compilación GTK2)

v Mozilla SeaMonkey 1.0.x.x (compilación GTK2)

v Mozilla Runtime Environment (xulrunner) 1.8.0.x (compilación GTK2)

Instale el navegador Mozilla o xulrunner con una versión del soporte de almacenamiento de instalación

que cumpla con los requisitos. Visite el sitio de actualización de Linux o el sitio web de Mozilla

(http://www.mozilla.org) para descargar e instalar estos programas.

Verificación del entorno de Mozilla en un sistema Linux

Antes de lanzar IBM Lotus Expeditor, siga estos pasos para verificar que satisface los prerrequisitos para

Linux:

SUSE Linux Enterprise Desktop 10

Se puede utilizar el xulrunner1.8.0.1 predeterminado instalado. La vía de acceso es

/usr/lib/xulrunner1.8.0.1. No se puede utilizar el Firefox 1.5.0.4 predeterminado instalado.

Puede encontrar los paquetes de prerrequisitos en los CD de Service Pack de SLED 10 o en el

sitio de actualización de Linux.

Red Hat Enterprise Linux 4.0 WS con soporte GTK - Actualización 4

Se puede utilizar el Firefox predeterminado instalado. La vía de acceso es /usr/lib/firefox1.5.0.3.

Instale Firefox o xulrunner desde el sitio de actualización de Linux o desde el sitio web de

Mozilla (http://www.mozilla.org).

Red Hat Enterprise Linux 5.0

Se puede utilizar el Firefox 1.5.0.9 predeterminado instalado. La vía de acceso es

/usr/lib/firefox1.5.0.9.

Puede encontrarlo en los CD de Red Hat Enterprise Linux 5.0, en el sitio de actualización de

Linux o en el sitio web de Mozilla (http://www.mozilla.org).

Siga estos pasos para verificar qué aplicación Mozilla está instalada en su sistema Linux:

Mozilla Runtime Environment (xulrunner)

1. Abra un terminal y entre rpm -qa | grep xulrunner para consultar los paquetes instalados.

2. Si se le devuelve algo parecido a mozilla-xulrunner-1.8.0.x-xx, Mozilla Runtime

Environment (xulrunner) está instalado.

Mozilla Firefox

1. Abra un terminal y entre rpm -qa | grep mozilla-firefox para consultar los paquetes

instalados.

2. Si se le devuelve algo parecido a mozilla-firefox-1.5.xx-xx, Mozilla Firefox está instalado.

Mozilla SeaMonkey (Mozilla Browser Suite)

1. Abra un terminal y entre rpm -qa | grep mozilla-seamonkey para consultar los paquetes

instalados.

2. Si se le devuelve algo parecido a mozilla-seamonkey-xx-xx, está instalado un Mozilla

SeaMonkey que cumple con los requisitos. Información relacionada


http://www.mozilla.org



“Instalación desde un CD”Este apartado proporciona los pasos que deben realizarse para la instalación de Lotus Expeditor Client

desde un CD.

“Invocación de una instalación silenciosa” en la página 15El programa de instalación de Lotus Expeditor Client puede configurarse para que se ejecute

silenciosamente de modo que no tenga que interactuar con el asistente de instalación. Además,

mediante la utilización de un archivo de opciones en Linux o un archivo de respuestas en Windows,

puede personalizar la instalación silenciosa para seleccionar automáticamente opciones de panel y

propiedades de instalación.

Instalación desde un CD

Este apartado proporciona los pasos que deben realizarse para la instalación de Lotus Expeditor Client

desde un CD.

Antes de instalar Lotus Expeditor Client, compruebe que haya suficiente espacio en el directorio temporal

del sistema operativo. Además del espacio necesario para instalar el producto, el directorio temporal del

sistema operativo debe tener como mínimo 200 MB libres.

Siga los pasos siguientes para instalar Lotus Expeditor Client desde un CD.

1. Inserte el CD de Lotus Expeditor Client en la unidad de CD-ROM.

2. Inicie el ejecutable del instalador apropiado para el sistema. El instalador está ubicado en el directorio

install/ del CD.

a. En un sistema Windows, ejecute el archivo setupwin32.exe.

b. En un sistema Linux, ejecute el archivo setuplinux.sh.

Notas:

v Si aparece el diálogo Descarga de archivos, pulse Abrir para ejecutar el instalador.

v Puede ejecutar el instalador directamente desde el directorio install/ del CD de instalación

en lugar de hacerlo desde el navegador.3. El instalador de Lotus Expeditor Client le guía durante el resto de la instalación:

a. En la página de bienvenida del instalador, pulse Siguiente.

b. Lea el acuerdo de licencia. Para aceptar la licencia, seleccione Acepto las condiciones del acuerdo

de licencia y pulse Siguiente.

c. En Windows, si se detecta una versión anterior, se le solicita que realice una actualización. Pulse

Siguiente para continuar y seguir en el paso 3o en la página 12. Si se detecta que la versión actual

ya está instalada, se le solicita que la desinstale.

Durante la instalación, el instalador busca Lotus Expeditor Client 6.1. Si se encuentra, los valores

se actualizan y la instalación continúa. Si tiene instalada la versión 6.0, primero debe instalar y

migrar a la versión 6.1 utilizando el instalador de 6.1 y, a continuación, actualizar a 6.1.x.

d. Entre el destino donde desea instalar Lotus Expeditor Client y pulse Siguiente.

Nota: Sólo puede instalar Lotus Expeditor Client de un directorio que contenga caracteres ASCII

válidos o a un directorio de dichas características.

Además, es posible que el usuario actual no tenga acceso al destino predeterminado. En

este caso, cambie la ubicación por un destino accesible para el usuario.

Ejemplos:

Windows

C:\Documents and Settings\user99\IBM\Lotus\Expeditor

Linux /home/user99/IBM/Lotus/Expeditor

Instalación y lanzamiento de Lotus Expeditor Client 11

e. En Linux, si se detecta una versión anterior en el destino especificado en el paso 3d en la página

11, se le solicita que realice una actualización. Pulse Siguiente para continuar y seguir en el paso

3o. Si se detecta que la versión actual ya está instalada, se le solicita que la desinstale.

f. Seleccione el tipo de instalación (un solo usuario o multiusuario) y pulse Siguiente. Para obtener

más información, consulte el apartado “Configuración de un solo usuario” en la página 1 y el

apartado “Configuración multiusuario” en la página 2.

g. Para configurar el Agente de gestión de empresa, seleccione Sí; de lo contrario, seleccione No.

Pulse Siguiente para continuar. Para obtener más información sobre cómo configurar el Agente de

gestión de empresa, consulte el apartado “Configuración del Agente de gestión de empresa” en la

página 197.

h. Si ha seleccionado configurar el Agente de gestión de empresa, continúe en el paso siguiente o, de

lo contrario, continúe en el paso 3k.

i. Especifique los valores para el Agente de gestión de empresa y pulse Siguiente.

j. Para configurar el producto para que lo administre un servidor de Portal, seleccione Sí y entre un

URL de servidor de Portal;de lo contrario, seleccione No. Pulse Siguiente para continuar.

El formato del URL de servidor de Portal es protocolo://servidor:puerto/contexto/inicioPersonalizado. El valor predeterminado es http://servidor:10038/wps/myportal.

k. Si ha seleccionado una configuración de instalación multiusuario, continúe en el paso siguiente o,

de lo contrario, continúe en el paso 3n.

l. Para permitir que los usuarios tengan la opción de lanzar el producto sin entrar una contraseña,

elija un valor y pulse Siguiente.

m. Si ha seleccionado añadir la posibilidad de configuración de contraseña, continúe en el paso

siguiente o, de lo contrario, continúe en el paso 3o.

n. Si se le presenta un panel que le solicita que habilite un indicador de contraseña en el arranque,

elija un valor y pulse Siguiente.

o. Si desea lanzar la plataforma después de que la instalación se haya realizado satisfactoriamente,

seleccione Sí; de lo contrario, seleccione No. Pulse Siguiente para continuar.

p. Antes de que empiece la instalación en sí, verifique que la información de resumen de la

instalación sea correcta. Pulse Siguiente para iniciar la instalación.

q. Cuando la instalación se haya completado, pulse Finalizar. Información relacionada

“Prerrequisitos del cliente” en la página 9Asegúrese de que cada máquina en la que piensa instalar Lotus Expeditor Client satisface estos

requisitos.






Instalación desde una ubicación de red compartida

Este apartado proporciona los pasos que deben realizarse para la instalación de Lotus Expeditor Client

desde una ubicación de red compartida.

Realice los pasos siguientes para instalar Lotus Expeditor Client desde una ubicación de red

compartida.

1. Correlaciónese con la carpeta compartida.

2. Continúe con el paso 3 descrito en “Instalación desde un CD” en la página 11.

Nota: Si instala en Windows Vista, debe ejecutar la instalación como administrador:


1. En el Explorador de Windows, pulse el botón derecho del ratón en setupwin32.exe y seleccione

Ejecutar como administrador.

2. Siga las solicitudes para completar la instalación.

3. Lance IBM Lotus Expeditor como usuario estándar utilizando <ubicación de

instalación>\rcp\rcplauncher.exe. Esto crea un nuevo icono de espacio de trabajo y escritorio

para el usuario estándar.

Para que la instalación de compartimiento de red se realice satisfactoriamente en Windows Vista,

es posible que necesite realizar ajustes en la política de seguridad local para UAC o inhabilitarla.

Información relacionada


requisitos.






Instalación con el Servicio de entorno de trabajo restringido

Habilite el Servicio de entorno de trabajo restringido para proporcionar un entorno restringido en el que

todos los usuarios de Lotus Lotus Expeditor Client estén limitados a las aplicaciones y los servicios de

sistema operativo que, como administrador, ha configurado.

El servicio de entorno de trabajo restringido sólo se puede habilitar durante la instalación inicial;

no se puede añadir a una instalación existente. El cliente del entorno de trabajo restringido de Expeditor

no da soporte a la desinstalación. La ejecución del programa de desinstalación puede parecer que

funciona correctamente, pero el sistema encontrará problemas cuando, posteriormente, inicie la sesión

como un usuario restringido anteriormente. Es necesario volver a instalar el sistema operativo base en

lugar de intentar eliminar el entorno de trabajo restringido de Expeditor.

Notas:

v

Si realiza la actualización de un entorno de trabajo restringido de Windows XP instalado

anteriormente, debe asegurarse de tener instalado y configurado Windows Installer 3.1 o

superior, o el sistema no se podrá utilizar posteriormente.

v Debido a una limitación conocida de Java, es necesario ejecutar los siguientes mandatos como

usuario root en máquinas Linux, después de la instalación inicial del entorno de trabajo

restringido de IBM Lotus Expeditor:

1. Salga de IBM Lotus Expeditor si éste está en ejecución

2. Especifique lo siguiente:

cd /opt/ibm/Lotus/Expeditor/rcp/eclipse/plugins/com.ibm.rcp.lockdown.gtk_6.1.1.<fecha>/install

o bien

cd /opt/ibm/Lotus/Expeditor/rcp/eclipse/plugins/com.ibm.rcp.lockdown.gtk_6.1.2.<fecha>/install

3. Si existe el directorio uninstall/restricted, especifique rm -rf uninstall/restricted

4. Especifique ./lockdown.sh install


||||||

|||

El Servicio de entorno de trabajo restringido sólo está disponible en entornos de instalación multiusuario.

Para habilitar el Servicio de entorno de trabajo restringido durante la instalación del producto, asegúrese

de que el manifiesto de instalación (tanto si utiliza la versión proporcionada como si crea su propio

archivo de manifiesto personalizado) contenga la información siguiente:

<feature

id="com.ibm.rcp.lockdown.feature"

version="<feature version>"

match="compatible"

action="install"

shared="false"

/>

Consulte “Personalización de la instalación básica” en la página 21 para obtener más información sobre

cómo instalar archivos de manifiesto.

Conceptos relacionados

“Acceso al sistema operativo”Como administrador, puede acceder al sistema operativo mientras se instala el Servicio de entorno de

trabajo restringido.

Acceso al sistema operativo

Como administrador, puede acceder al sistema operativo mientras se instala el Servicio de entorno de

trabajo restringido.

Para acceder al sistema operativo no restringido, por ejemplo, el shell Explorer de Windows XP o el shell

Gnome de Linux, siga estos pasos:

1. Inicie la sesión en el sistema operativo como administrador.

2. Se visualiza el shell de ventana de sistema operativo predeterminado.

Ha iniciado la sesión en el sistema operativo no restringido.

Cambio de valores de cuenta de portal principal para los usuarios en el entorno

de trabajo restringido

Puede cambiar los valores de cuenta de portal principal para los usuarios del entorno de trabajo

restringido.

Para cambiar la dirección del servidor o el nombre de usuario y la contraseña de Cuenta de portal

principal para los usuarios del entorno de trabajo restringido, un usuario con privilegios administrativos

debe lanzar Lotus Expeditor Client utilizando el parámetro -data <directorio de espacio de trabajo

de usuarios> y, a continuación, acceder al panel de preferencias de Cuenta de portal principal:

1. Si utiliza Linux, especifique chown -R root <espacio de trabajo de usuarios> para modificar los

permisos de propietario del directorio de <espacio de trabajo de usuarios> que contiene directorios de

registros, aplicaciones y .config (por ejemplo, /home/myuser/IBM/RCP/<número ID>/myuser).

2. Lance Lotus Expeditor Client con los siguientes parámetros de línea de mandatos: -data <espacio de

trabajo de usuarios>

3. Pulse Archivo > Preferencias y, a continuación, pulse la Cuenta de portal principal en el panel de la

izquierda.

4. Realice las modificaciones necesarias a los valores que se muestran y pulse Aceptar para aplicar los

cambios.

5. Permita que Lotus Expeditor Client se reinicie y asegúrese de que las aplicaciones nuevas estén

disponibles.

6. Salga de Lotus Expeditor Client.

7. Si utiliza Linux, especifique chown -R <usuario> <espacio de trabajo de usuarios> para restaurar los

permisos de propietario del directorio de <espacio de trabajo de usuarios>.

8. Finalice la sesión del usuario administrativo del sistema operativo.


9. Inicie la sesión en el sistema operativo como usuario de entorno de trabajo restringido que iniciará

automáticamente Lotus Expeditor Client. Ahora ya están disponibles las aplicaciones.

Invocación de una instalación silenciosa

El programa de instalación de Lotus Expeditor Client puede configurarse para que se ejecute

silenciosamente de modo que no tenga que interactuar con el asistente de instalación. Además, mediante

la utilización de un archivo de opciones en Linux o un archivo de respuestas en Windows, puede

personalizar la instalación silenciosa para seleccionar automáticamente opciones de panel y propiedades

de instalación.

Nota: El ejecutable del instalador está ubicado en el directorio install/ del CD.

1. En un sistema Windows, ejecute el archivo setupwin32.exe.

2. En un sistema Linux, ejecute el archivo setuplinux.sh.

Para realizar una instalación silenciosa con las opciones predeterminados:

1. Desde una línea de mandatos, vaya al directorio install/ del CD.

2. Ejecute el mandato siguiente:

En Windows:

<ejecutable de configuración> /s /v"/qn LICENSEACCEPTED=true"

Por ejemplo, setupwin32.exe /s /v"/qn LICENSEACCEPTED=true".

En Linux:

<ejecutable de configuración> -silent -V licenseAccepted=true

Por ejemplo, setuplinux.sh -silent -V licenseAccepted=true.

Para realizar una instalación silenciosa con opciones personalizadas:

Nota: Las plantillas de los archivos de respuestas y opciones están ubicadas en el directorio

<paquete_instalación_Expeditor>\desktop\install.

1. Cree un archivo de opciones utilizando los pasos proporcionados en “Utilización de archivos de

opciones” en la página 17 o cree un archivo de respuestas en Windows utilizando los pasos

proporcionados en “Utilización de archivos de respuestas” en la página 19.

2. Modifique el archivo de opciones con los valores personalizados para la instalación.

3. Desde una línea de mandatos, vaya al directorio install/ del CD de instalación.


En Windows:

<ejecutable de configuración> /s /v"/qn USEINI=<vía de acceso totalmente calificada al

archivo de respuestas>"

Por ejemplo setupwin32.exe /s /v"/qn USEINI=c:\temp\options.txt"

En Linux:

<ejecutable del instalador> -silent -options archivo de opciones

Por ejemplo, setuplinux.sh -silent -options /tmp/options.txt.

Nota: Al utilizar un archivo de opciones o un archivo de respuestas para instalar de forma silenciosa,

debe establecer la propiedad siguiente en el archivo de opciones o en el archivo de respuestas

para que continúe la instalación:

En Windows:

LICENSEACCEPTED=true

En Linux:


-V licenseAccepted=true

Consulte los ejemplos anteriores.



requisitos.

“Instalación desde un CD” en la página 11Este apartado proporciona los pasos que deben realizarse para la instalación de Lotus Expeditor Client

desde un CD.

Supresión de Lotus Expeditor Client

Utilice los pasos de este apartado para desinstalar Lotus Expeditor Client.

En Windows:

1. Lance Agregar o quitar programas seleccionando Configuración → Panel de control → Agregar o

quitar programas

2. Seleccione Lotus Expeditor Client y pulse Cambiar (para desinstalar utilizando las solicitudes del

asistente de desinstalación) o Eliminar (para desinstalar sin ninguna solicitud del asistente de

desinstalación).

Si pulsa Cambiar, aparecerá un asistente de desinstalación que le permitirá elegir si desea eliminar

datos de usuario. Si pulsa Eliminar, no aparecerá ningún asistente de desinstalación y los datos de

usuario se conservarán después de la desinstalación.

En la versión 6.1.2, el asistente de desinstalación no proporciona la opción de eliminar los

datos de usuario. Debe eliminarlos manualmente. Consulte “Supresión de datos específicos de

usuario” en la página 17.

En Linux, ejecute <dir_instalación>/_uninst/uninstaller.sh.

Los datos de usuario se almacenan en el espacio de trabajo. Consulte “Alteración temporal de la

ubicación del directorio de espacio de trabajo” en la página 23 para obtener más información.

Desinstalación silenciosa de Lotus Expeditor Client en Windows

Para eliminar de forma silenciosa Lotus Expeditor versión 6.1.1 con las opciones predeterminadas:

1. Desde una línea de mandatos, vaya al directorio /desktop/install/ del CD.

2. Ejecute el mandato siguiente: <ejecutable de configuración> /x /s /v"/qn"

Para desinstalar de forma silenciosa con opciones personalizadas:

1. Utilice un archivo de respuestas creado durante la instalación realizando los pasos que se indican en

“Utilización de archivos de respuestas” en la página 19.

2. Modifique el archivo de respuestas con los valores personalizados para su desinstalación.

3. Desde una línea de mandatos, vaya al directorio /desktop/install/ del CD de instalación.

4. Ejecute el mandato siguiente: <ejecutable de configuración> /x /s /v"/qn USEINI=<vía de acceso

totalmente calificada al archivo de respuestas>"

Por ejemplo, setupwin32.exe /x /s /v"/qn USEINI=c:\temp\response.txt".

Para eliminar de forma silenciosa Lotus Expeditor versión 6.1.2, ejecute el mandato siguiente:

"<destino cliente>\uninstall.bat" -silent


|||

|

|

Supresión de datos específicos de usuario

En Lotus Expeditor versión 6.1.2, después de eliminar Lotus Expeditor de un sistema de usuario, los

datos específicos de usuario (el espacio de trabajo) no se eliminan. Si no desea conservar los datos

específicos de usuario en el sistema, debe eliminarlos manualmente.

Nota: En instalaciones multiusuario, debe completar estos pasos para cada cuenta.

.

Los datos específicos de usuario (el espacio de trabajo) de una instalación anterior de Lotus Expeditor

pueden reutilizarse si se vuelve a instalar Lotus Expeditor Client en el sistema. Para eliminar los datos:

Suprima la ubicación del espacio de trabajo. Las ubicaciones predeterminadas son:

1. Windows:Documents and Settings/<ID usuario> /Datos de programa/Lotus/XPD.

2. Linux: /home/<ID usuario>/Lotus/XPD /<ID usuario>.

Si ha cambiado la ubicación y no es la predeterminada, debe suprimir la ubicación de sustitución.

Utilización de archivos de opciones

En Linux, se utilizan archivos de opciones para pasar opciones de línea de mandatos a una instalación o

desinstalación como se especifican normalmente estas opciones en la línea de mandatos. Estas opciones

representan la respuesta a los paneles del asistente de instalación y establecen las propiedades de

instalación como corresponde.

Las opciones que se especifican en el archivo de opciones se procesan después de procesar las opciones

que se entran directamente en la línea de mandatos. Puede generar una plantilla de archivo de opciones

desde el iniciador de instalación o desinstalación ejecutando el mandato siguiente:

ejecutable de instalador o desinstalador -options-template archivo de opciones

Al ejecutar el mandato se crea un archivo de opciones con el nombre especificado. A continuación este

archivo puede modificarse para especificar los valores que se aplicarán al ejecutar la instalación.

Nota:

v para crear archivos de opciones para el desinstalador, primero debe instalar el producto en un

sistema. El ejecutable de desinstalador está ubicado en el directorio <directorio de

instalación>/_uninst/. El archivo se denomina uninstaller.sh.

v Al ejecutar la opción options-template desde el CD, asegúrese de especificar una ubicación

grabable para el archivo de salida (es decir, utilice una vía de acceso completa a una ubicación

de disco duro porque no puede grabar en el CD).

Registro de opciones

En lugar de modificar manualmente el archivo de plantilla, otra forma de crear un archivo de opciones es

registrarlo en función de las opciones especificadas durante una instalación real. Para registrar un archivo

de opciones, ejecute este mandato:

ejecutable del instalador o desinstalador -options-record archivo de opciones

Una vez completada la instalación, se genera automáticamente un archivo de opciones con el nombre

especificado.

Opciones disponibles para la instalación

Nota: Todos los valores de opción se deben escribir entre comillas dobles (por ejemplo -V

installWelcomeAllowPanel="true").


|

|||

|

|

||

|

|

|

|

|

Las opciones siguientes controlan la ejecución de los paneles de instalación. Establezca las opciones en

true (o false) para permitir (o impedir) que se ejecuten los paneles. De forma predeterminada, se

permite que todos los paneles se ejecuten.

-V installWelcomeAllowPanel

-V licenseAllowPanel

-V destinationAllowPanel

-V installConfigurationAllowPanel

-V useDeviceManagementAllowPanel

-V deviceManagementAllowPanel

-V portalConfigurationAllowPanel

-V securityConfigureAllowPanel

-V securityPromptAllowPanel

-V launchPlatformAllowPanel

-V preInstallSummaryAllowPanel

-V provisioningStatusAllowPanel

-V postInstallSummaryAllowPanel

Utilice -V licenseAccepted para controlar si la licencia se ha aceptado para la instalación (true o false).

El valor predeterminado es false.

Utilice -V installConfiguration para determinar la configuración de instalación. Los valores válidos son

user y multiuser. El valor predeterminado es user.

Utilice -V useDeviceManagement para determinar si se utiliza el Agente de gestión de empresa (true o

false). El valor predeterminado es false.

Se utilizan las opciones siguientes para configurar el nombre de usuario, la contraseña y el URL de

servidor del Agente de gestión de empresa.

-V deviceManagementUserName

-V deviceManagementUserPassword

-V deviceManagementServerURL

Las opciones siguientes configuran el uso de Gestión de portal (true o false) así como el URL de

servidor de Portal.

-V usePortalManagement

-V portalConfigurationServerURL

Utilice -V securityAllowConfiguration para permitir a los usuarios configurar si desean permitir una

solicitud de contraseña (true o false). El valor predeterminado es true.

Utilice -V securityPasswordPrompt para permitir que la plataforma solicite una contraseña en el arranque

(true o false). El valor predeterminado es true.

Utilice -V launchPlatformOnExit para especificar si se debe lanzar la plataforma cuando la instalación se

complete satisfactoriamente (true o false). El valor predeterminado es true.

Utilice -P installLocation para especificar la ubicación de instalación del producto. Especifique un

directorio válido en el que se debe instalar el producto. El valor predeterminado es /opt/IBM/Expeditor.

Opciones disponibles para la desinstalación

Nota: Todos los valores de opción se deben escribir entre comillas dobles (por ejemplo -V

uninstallWelcomeAllowPanel="true").

Las opciones siguientes controlan la ejecución de los paneles de desinstalación. Establezca las opciones en

true (o false) para permitir (o impedir) que se ejecuten los paneles. De forma predeterminada, se

permite que todos los paneles se ejecuten.


-V uninstallWelcomeAllowPanel

-V preUninstallSummaryAllowPanel

-V provisioningStatusAllowPanel

-V postUninstallSummaryAllowPanel

Si utiliza Lotus Expeditor versión 6.1.1, hay disponible una opción adicional:

-V removeUserDataAllowPanel

Utilice -V removeUserData para determinar si se deben eliminar datos específicos de usuario durante la

desinstalación (true o false). El valor predeterminado es false.

Utilización del archivo de opciones durante la instalación

Tras modificar la plantilla, o registrar el archivo de opciones durante la instalación, ejecute el mandato

siguiente para pasar las opciones a una instalación:

ejecutable de instalador o desinstalador -options archivo de opciones








requisitos.






Utilización de archivos de respuestas

En Windows, los archivos de respuestas se utilizan para pasar propiedades de línea de mandatos a una

instalación de la misma manera en que especificaría estas propiedades en la línea de mandatos. Estas

propiedades representan la respuesta a los paneles del asistente de instalación y establecen las

propiedades de instalación correspondientes.

Guardar un archivo de respuestas

Para designar el archivo de respuestas (o archivo de inicialización) que se debe crear, ejecute el mandato

siguiente:

<ejecutable de configuración> /v"SAVEINI=c:\myfile.ini"

Una vez completada la instalación, se genera automáticamente un archivo de opciones con el nombre

especificado.

Nota:

v SAVEINI=“” suprime la creación del archivo de respuestas.

v Por omisión, el archivo .ini no se elimina cuando se desinstala el producto.


{

Utilización del archivo de respuestas durante la instalación

Después de guardar un archivo de respuestas (o archivo de inicialización) en la instalación, ejecute el

mandato siguiente para designar el archivo de inicialización que se debe utilizar para una instalación:

<ejecutable de configuración> /v"USEINI=c:\myfile.ini"

Eliminación de un archivo de respuestas durante la desinstalación

En Lotus Expeditor versión 6.1.1, para indicar que el archivo de inicialización se debe suprimir durante la

desinstalación, ejecute el mandato siguiente:

<ejecutable de configuración> /v"REMOVEINI=1"

Creación de un archivo de inicialización solamente

Para crear el archivo de inicialización pero no instalar el producto, ejecute el mandato siguiente:

<ejecutable de configuración> /v"SAVEINI=c:\myfile.ini ONLYINI=1"

Nota: Si se especifica ONLYINI=1, aparece el diálogo SetupInterrupted después del diálogo

ReadyToInstall y se graba un mensaje en el archivo de registro.

Opciones disponibles para la instalación inicial

Utilice LICENSEACCEPTED para controlar si la licencia se ha aceptado o no para la instalación (true o

false). El valor predeterminado es false.

Utilice INSTALLCONFIGURATION para determinar la configuración de instalación. Los valores válidos son

user y multiuser. El valor predeterminado es user.

Utilice USEDEVICEMANAGEMENT para determinar si se utiliza el Agente de gestión de empresa (true o false).


Se utilizan las opciones siguientes para configurar el nombre de usuario, la contraseña y el URL de

servidor del Agente de gestión de empresa:

v DEVICEMANAGEMENTUSERNAME

v DEVICEMANAGEMENTUSERPASSWORD

v DEVICEMANAGEMENTSERVERURL

Las opciones siguientes configuran el uso de Gestión de portal (true o false) así como el URL de

servidor de Portal:

v USEPORTALMANAGEMENT

v PORTALCONFIGURATIONSERVERURL

Utilice SECURITYALLOWCONFIGURATION para permitir a los usuarios configurar si desean permitir una

solicitud de contraseña (true o false). El valor predeterminado es true.

Utilice SECURITYPASSWORDPROMPT para habilitar que la plataforma solicite una contraseña en el arranque

(true o false). El valor predeterminado es true.

Utilice LAUNCHPLATFORMONEXIT para especificar si se debe lanzar o no la plataforma cuando la instalación

se complete satisfactoriamente (true o false). El valor predeterminado es true.

Utilice INSTALLDIR para especificar la ubicación de instalación del producto. Especifique un directorio

válido en el que se debe instalar el producto. El valor predeterminado es C:\Archivos de

programa\IBM\Lotus\Expeditor.


Opciones disponibles para la actualización

Utilice LICENSEACCEPTED para controlar si la licencia se ha aceptado o no para la instalación (true o false).


Utilice LAUNCHPLATFORMONEXIT para especificar si se debe lanzar o no la plataforma cuando la instalación

se complete satisfactoriamente (true o false). El valor predeterminado es true (verdadero).

Nota: No deben utilizarse otras opciones de instalación inicial durante la actualización.








requisitos.






Personalización de la instalación básica

El proceso de instalación de Lotus Expeditor Client consta de dos pasos: instalación de los archivos

básicos de la plataforma y suministro de componentes adicionales. En función de la configuración de

instalación deseada (uno o varios usuarios), se proporcionan al producto diferentes conjuntos de

componentes desde los sitios de actualización.

El conjunto de componentes que se deben suministrar se define en manifiestos de suministro,

procesados por el instalador y el sistema de suministro de la plataforma. Estos archivos deben estar

presentes en un directorio deploy/ que se encuentra en la misma ubicación que el archivo ejecutable del

instalador. Los manifiestos de suministro se deben denominar user.xml o multiuser.xml (correspondiente

a las configuraciones de instalación disponibles).

El conjunto de componentes que se deben suministrar se define dentro de un manifiesto de

suministro, procesado por el instalador y el sistema de suministro de la plataforma. El archivo debe tener

el nombre install.xml y estar situado en un directorio deploy/ que se encuentre en la misma ubicación

que el ejecutable del instalador

El CD de Lotus Expeditor Client incluye un manifiesto de suministro para cada una de estas

configuraciones de instalación. Estos archivos no pueden modificarse porque residen en el CD. Sin

embargo, si se copió el contenido del directorio install/ en un sistema de archivos de lectura-escritura

(como en el caso de un escenario de descarga web), los archivos se pueden modificar para que cada una

de estas configuraciones de instalación incluya un conjunto personalizado de componentes.

Nota: La modificación de estos manifiestos de suministro respecto a su estado original puede hacer que

una instalación de plataforma no sea válida.


Durante el proceso de instalación, el manifiesto de suministro correspondiente a la configuración de

instalación elegida se procesa (sustituyendo las variables soportadas) y se copia en <destino de

producto>/rcp/deploy/install.xml.

Durante el proceso de instalación, el manifiesto de suministro se procesa (sustituyendo las

variables soportadas) y se copia en <destino de producto>/rcp/deploy/install.xml.

La ubicación de este archivo se pasa luego al componente de suministro de la plataforma para iniciar el

proceso de suministro.

Para obtener más información sobre cómo utilizar el manifiesto de suministro y la sintaxis del mismo,

consulte “Utilización del manifiesto de suministro” en la página 175.

Alteración temporal de la lista de sitios de actualización para el

suministro de recursos

Puede alterar temporalmente la lista de sitios de actualización que se utilizan para buscar las

características que se deben instalar.

De forma predeterminada, el instalador de IBM Lotus Expeditor accede a un sitio de actualización de una

ubicación relativa al ejecutable de configuración para suministrar los componentes de plataforma. Puede

alterar temporalmente la lista desde la línea de mandatos:

1. En la línea de mandatos, cambie al directorio install/ del CD.

2. En Linux, entre el mandato siguiente utilizando la variable updateSiteList del modo siguiente:

setuplinux.sh –V updateSiteList=”<sitio 1>|<sitio 2>|...|<sitio n>”

En Windows, entre el mandato siguiente utilizando la propiedad UPDATESITELIST del modo

siguiente:

setupwin32.exe /v”UPDATESITELIST=”<sitio 1>|<sitio 2>|...|<sitio n>”

En cualquiera de los casos, cada sitio de actualización especificado debe ser un URL válido. Asimismo, si

el sitio especificado contiene el texto ${installer.root}, se sustituirá ese texto por un valor de URL de

archivo que contiene la ubicación desde la que se ha lanzado el instalador.

Instalación de Lotus Expeditor Client para el lanzamiento compartido

desde una unidad de red

Lotus Expeditor Client se puede instalar en una unidad que se puede compartir como unidad de red.

Esto permite que una sola ubicación de instalación de la red se comparta entre varios usuarios.

La instalación debe respetar las siguientes restricciones:

v Seleccione la opción Instalación multiusuario. Esto establece los parámetros de configuración en

valores favorables para una instalación compartida.

v La instalación sólo la pueden utilizar los clientes que se ejecutan en la misma familia de sistemas

operativos como aplicación de instalación. En otras palabras, si utiliza Windows para instalar Lotus

Expeditor Client, sólo los usuarios de sistemas Windows podrán utilizar la instalación. Si está

utilizando Linux para instalar Lotus Expeditor Client, la instalación sólo la pueden utilizar los usuarios

de sistemas Linux.

v La instalación se puede realizar en una unidad local que posteriormente la compartan otros usuarios o

se puede instalar en una unidad compartida. En Windows, al instalar en una unidad compartida, ésta

se debe montar como letra de unidad. No se soportan destinos montados UNC.

No se soporta la instalación en una unidad compartida montada con el cliente Samba de Linux. Si está

utilizando Linux e intenta utilizar el cliente Samba para montar una carpeta compartida e instalar en


dicha carpeta compartida, recibirá errores que indican que los archivos no se han podido renombrar. Se

trata de un problema conocido con esta configuración. Una alternativa será utilizar NFS para montar

carpetas compartidas.

v Utilice las políticas aplicables a la configuración multiusuario para desplegar características adicionales

en los sitios compartidos. Consulte el apartado “Configuración multiusuario” en la página 2 para

obtener más información.

Para habilitar el uso de una instalación compartida en red, los archivos de propiedades relacionadas con

la configuración no contienen referencias de ubicación de directorio y archivo absolutas, sino que utilizan

las siguientes variables que se resuelven y sustituyen durante el proceso de lanzamiento:

${rcp.data}

Hace referencia al directorio de espacio de trabajo. Para obtener más información, consulte el

apartado “Alteración temporal de la ubicación del directorio de espacio de trabajo”.

${rcp.home}

Hace referencia a la ubicación de instalación de la plataforma. El valor de rcp.home lo establece el

iniciador para que sea el directorio padre del directorio que contiene el iniciador.

En Windows, la ubicación de instalación predeterminada es C:\Archivos de programa\IBM\Lotus\Expeditor. El directorio Expeditor contiene un directorio rcp, en el que reside el iniciador,

rcplauncher.exe. rcp.home está ubicado en C:\Archivos de programa\IBM\Lotus\Expeditor.

En Linux, la ubicación de instalación predeterminada es /opt/ibm/lotus/Expeditor. El directorio

Expeditor contiene un directorio rcp, en el que residen el iniciador, rcplauncher. rcp.home está

ubicado en el directorio /opt/ibm/lotus/Expeditor.

Los sitios de instalación predeterminados – eclipse, rcp y shared – residen bajo el directorio rcp.home. No

se pueden añadir sitios de instalación a menos que también se haga referencia a ellos como hijos de la

raíz rcp.home.

Alteración temporal de la ubicación del directorio de espacio de

trabajo

Puede alterar temporalmente la ubicación de directorio de espacio de trabajo.

En Windows, la ubicación de espacio de trabajo predeterminada es <APPDATA>\Lotus\XPD.

En Linux, la ubicación de espacio de trabajo predeterminada es <HOME>/Lotus/XPD donde

<APPDATA> y <HOME> son variables de entorno del sistema. En las instalaciones Windows

predeterminadas, el directorio de espacio de trabajo se resolverá en Documents and Settings\<idusuario>\Application Data\Lotus\XPD. En las instalaciones Linux predeterminadas, se resolverá en

/home/<idusuario>/Lotus/XPD.

Nota: En instalaciones actualizadas de IBM Lotus Expeditor 6.1.0, la ubicación de espacio de trabajo se

conservará de la instalación 6.1.0. En ambos sistemas, esta ubicación es <directorio de inicio de

usuario>/IBM/RCP/<ID_instalación_rcp>/<nombre de usuario>.

La nueva ubicación de directorio que se especifique debe ser accesible a todos los usuarios que vayan a

utilizar el espacio de trabajo. Para una configuración multiusuario, donde cada usuario tendrá un espacio

de trabajo exclusivo, la ubicación de directorio de espacio de trabajo que se especifique deberá contener

las variables de entorno que se sustituirán en el lanzamiento y, por consiguiente, dicha ubicación se

resolverá en una ubicación exclusiva para cada usuario. En una configuración multiusuario, un espacio

de trabajo común se compartirá en serie entre todos los usuarios que inicien la sesión en el sistema. El

directorio de espacio de trabajo debe estar en una ubicación accesible a todos los usuarios, con permisos

completos en la ubicación común.


Utilice las siguientes opciones de línea de mandatos para alterar temporalmente la ubicación de directorio

de espacio de trabajo:

v En Linux, entre el mandato utilizando la variable rcpData como se indica a continuación:

setuplinux.sh –V rcpData=”<ubicación deseada de

espacio trabajo>"

Si no se especifica en Linux, se utiliza ${env.HOME}/Lotus/XPD.

Por ejemplo:

setuplinux.sh -V rcpData=${env.HOME}/Lotus/XPD

v En Windows, entre el mandato utilizando la variable rcpData del modo siguiente:

setupwin32.exe /v”RCPDATA=\"<ubicación deseada de

espacio de trabajo>\""

Si no se especifica en Windows, se utiliza ${env.APPDATA}/Lotus/XPD.

Nota: Si se utiliza la alteración temporal de línea de mandatos, el registro no se habilita

automáticamente. Añada /liwemo "<ubicación registro de instalación>" para habilitar el

registro.

Por ejemplo:

setupwin32.exe /v"/liwemo \"%TEMP%/rcp_install.log\" RCPDATA=\"${env.APPDATA}/Lotus/XPD\""

Las características que se han instalado en un espacio de trabajo no se pueden desinstalar desde un

espacio de trabajo distinto. Por ejemplo, cuando lanza inicialmente IBM Lotus Expeditor utilizando el

espacio de trabajo predeterminado, se instala y proporciona un conjunto de características. Si

posteriormente realiza el lanzamiento con un espacio de trabajo distinto utilizando la opción rcpData, las

características que se instalaron en el espacio de trabajo predeterminado no se pueden desinstalar desde

el nuevo espacio de trabajo. Si intenta desinstalar estas características, no se desinstalarán y se grabarán

errores en el registro de errores.

Localización del programa iniciador de Lotus Expeditor Client

IBM Lotus Expeditor crea claves de registro en Windows y archivos en Linux para permitir localizar el

iniciador de Lotus Expeditor Client.

En Windows, la vía de acceso de registro depende de los atributos de instalación. Si un administrador ha

instalado la plataforma Lotus Expeditor, la vía de acceso de registro es HKEY_LOCAL_MACHINE\SOFTWARE\IBM\Lotus\Expeditor. De lo contrario, la vía de acceso es HKEY_CURRENT_USER\SOFTWARE\IBM\Lotus\Expeditor. En esta carpeta de registro, se creará otra clave basada en el nombre

de producto del producto instalado. En esta nueva clave, se creará el iniciador de valor de serie para que

contenga la vía de acceso del programa rcplauncher.exe. Al buscar en el registro, compruebe primero

HKEY_CURRENT_USER. Si no se encuentran las claves, compruebe HKEY_LOCAL_MACHINE.

En Linux, se creará un archivo de configuración para que contenga la ubicación del iniciador. Si un

administrador ha instalado la plataforma IBM Lotus Expeditor, el archivo de configuración se creará en el

directorio /etc/ibm/lotus/expeditor. De lo contrario, la vía de acceso es $HOME/user/.expeditor. En el

directorio, se creará un archivo denominado .cfg que contendrá la vía de acceso al programa rcplauncher.

Por ejemplo, la línea siguiente es el contenido de archivo:

launcher=/opt/ibm/lotus/Expeditor/rcp/rcplauncher

IBM Lotus Expeditor utiliza el nombre de producto Expeditor en la característica de marca para crear las

entradas de registro descritas más arriba. Es posible que las instalaciones que han sustituido la

característica de marca IBM Lotus Expeditor por otra característica de marca cambien el nombre de

producto y, por consiguiente, el nombre de archivo que contiene la información de iniciador será

diferente.


Descripción de las instalaciones en Microsoft Windows Vista

En este apartado encontrará una descripción del Control de cuenta de usuario y el modelo de seguridad

asociado a Microsoft Windows Vista.

Control de acceso de usuario de Microsoft Windows Vista

Microsoft Windows Vista implementa un nuevo modelo de seguridad que se denomina Control de cuenta

de usuario (UAC) que, cuando se habilita, limita el acceso a los directorios y secciones del registro

protegidos. Estas limitaciones se imponen a los usuarios estándar y miembros del grupo de

administradores. A los miembros del grupo de administradores se les solicita una confirmación cada vez

que intentan acceder al recurso. De igual modo, los usuarios deben proporcionar la contraseña de un

miembro del grupo de administradores cada vez que desean acceder al recurso. Una limitación adicional

en ambos escenarios es el diálogo que solicita la aceptación o la contraseña: tiene un tiempo de espera de

dos minutos tras el cual desaparecerá e interrumpirá las instalaciones de software o no permitirá el

acceso al recurso solicitado.

UAC también implementa la virtualización de recursos para los directorios y secciones del registro

protegidos. Un ejemplo de virtualización de recursos es cuando un usuario estándar intenta crear un

archivo en C:\Archivos de programa\<MiApl>\<MisArch> y no recibe un error de acceso, pero el archivo

se crea en C:\Users\<usuario>AppData\Local\VirtualStore\Archivos de programa\<MiApl>\<MisArch>.

Si UAC está inhabilitado, la virtualización de recursos también está inhabilitada.

IBM Lotus Expeditor puede instalarse con UAC habilitado o inhabilitado, aunque se recomienda que se

mantenga habilitado para facilitar la protección del sistema.

Administración de la plataforma en Windows Vista

Con la aparición del nuevo modelo de seguridad de Microsoft en Vista, la plataforma es intrínsecamente

más segura, ya que todos los usuarios están limitados a los derechos de acceso de usuario estándar. Los

usuarios administrativos pueden solicitar privilegios elevados cuando tienen que realizar funciones

administrativas. Para IBM Lotus Expeditor, debe lanzar la plataforma que solicita los privilegios elevados

cuando instala características adicionales, soporte de idioma NLS o realiza otros cambios de configuración

que pueden afectar a todos los usuarios. Esto permitirá la correcta creación de nuevos iconos de

aplicación en el Escritorio de Windows o en el menú de Inicio de Windows, y la creación correcta de

claves de registro globales. La plataforma no debe ejecutarse excesivamente con privilegios elevados, ya

que es posible que algunas funciones, como el lanzamiento de navegadores externos, no se comporten de

la forma prevista. Para ejecutar la plataforma con privilegios elevados:

1. Inicie la sesión en Vista como parte de un usuario del grupo de Administradores

2. Pulse el botón derecho del ratón en el icono IBM Lotus Expeditor (normalmente, en el escritorio o en

el menú Inicio)

3. Seleccione Ejecutar como administrador

4. Responda la solicitud de Vista para ejecutar el programa con privilegios elevados

Lanzamiento de Lotus Expeditor Client en el escritorio

Este tema describe cómo iniciar Lotus Expeditor Client, cómo funciona el proceso de daemon y cómo se

une un proceso existente si se solicita una personalidad nueva.

Consulte “Configuración del iniciador de la plataforma” en la página 48 para obtener detalles sobre los

mandatos disponibles.

Inicio de Lotus Expeditor Client


Durante la instalación de Lotus Expeditor Client se creará un nuevo icono de escritorio titulado Expeditor

6.1.1 o 6.1.2, que se puede utilizar para iniciar Lotus Expeditor Client.

Además, puede lanzar Lotus Expeditor Client desde la línea de mandatos. De forma predeterminada, no

se necesitan argumentos, pero se pueden proporcionar argumentos adicionales. Para obtener una lista de

los argumentos de línea de mandatos soportados, consulte “Configuración del iniciador de la plataforma”

en la página 48. En sistemas Linux, si Lotus Expeditor Client se ha instalado en el directorio

predeterminado, utilice el mandato siguiente para lanzar el cliente:

/opt/ibm/lotus/Expeditor/rcp/rcplauncher

En sistemas Windows, si Lotus Expeditor Client se ha instalado en el directorio predeterminado, utilice el

mandato siguiente para lanzar el cliente:

C:\Archivos de programa\ibm\Lotus\Expeditor\rcp\rcplauncher.exe

Utilización del daemon RCP y Dcommands

En este apartado se describe cómo funciona el daemon y cómo unirse a un proceso existente cuando se

utiliza una personalidad nueva

Cuando Lotus Expeditor Client está en ejecución, puede ejecutar mandatos desde fuera de la interfaz de

usuario de Expeditor mediante el uso de un daemon de Expeditor. Estos mandatos se tratan como

argumentos adicionales en el ejecutable rcplauncher principal. Cuando se invoca un proceso rcplauncher

con estos mandatos adicionales y ya se está ejecutando un Lotus Expeditor Client, el proceso rcplauncher

utiliza el daemon e indica a Lotus Expeditor Client que ejecute estos mandatos en lugar de arrancar otra

instancia completa de Lotus Expeditor Client y, a continuación, invocar los mandatos en el nuevo

entorno.

Puede invocar personalidades adicionales que se unirán al entorno de Lotus Expeditor Client que se

ejecuta actualmente en lugar de crear otra instancia completa. Esto se realiza utilizando el daemon

descrito en el apartado anterior y se hace para ayudar a ahorrar recursos del sistema.

Por ejemplo, examinemos una suite de aplicaciones de productividad de oficina que contienen un

procesador de texto y una aplicación de hoja de cálculo. Cada una de estas aplicaciones puede ser un

icono de escritorio independiente y ambas utilizan el ejecutable rcplauncher pero proporcionan una

personalidad diferente a través del parámetro -personality. Dado que inicialmente el usuario necesita

trabajar en unos datos de la hoja de cálculo a fin de generar los datos necesarios para que se escriba una

carta, el usuario inicia la hoja de cálculo. Cuando se acerca el final del trabajo de hoja de cálculo, el

usuario decide empezar a trabajar en la carta para asegurar que se proporcione correctamente el diseño

para los datos que se deben incluir, de modo que el usuario lanza ahora la aplicación de proceso de texto.

El proceso rcplauncher reconocerá que Lotus Expeditor Client ya se está ejecutando con la personalidad

de hoja de cálculo y no invocará otra instancia completa. En lugar de ello, el proceso rcplauncher

utilizará el daemon y hará que la versión de Lotus Expeditor Client que se ejecuta actualmente abra una

ventana nueva, utilizando la nueva personalidad de proceso de texto.

Descripción de la creación de espacio de trabajo

Este apartado proporciona información sobre la creación y el contenido del espacio de trabajo de IBM

Lotus Expeditor.

El espacio de trabajo se utiliza para almacenar datos entre lanzamientos de plataforma y también

contiene el área de configuración para la plataforma. El área de configuración almacena información

relacionada con las aplicaciones y características instaladas en la plataforma.

El espacio de trabajo inicial se crea durante la instalación inicial. El programa de instalación instala

primero un conjunto mínimo de características y plug-ins en el directorio de instalación. Entonces estas

características se utilizan para lanzar la plataforma por primera vez. Durante este lanzamiento que se

efectúa por primera vez, se crea el espacio de trabajo inicial. El espacio de trabajo y la configuración


{

iniciales se crean basándose en el contenido del manifiesto de suministro. Todas las características

definidas en el manifiesto de suministro se instalan y se habilitan y la información de configuración

resultante se almacena en el espacio de trabajo.

En instalaciones multiusuario, cuando se crean espacios de trabajo adicionales a continuación de la

creación de espacio de trabajo inicial, se utilizan las características instaladas durante la creación de

espacio de trabajo inicial. En lo que respecta al ciclo de vida de las características, esto significa que las

características no se instalan otra vez sino que sólo se habilitan. Si está proporcionando características

propias y éstas contienen manejadores de instalación, deberán realizar la mayor parte del trabajo

necesario en las operaciones de configuración y desconfiguración. Para obtener más información, consulte

“Descripción del ciclo de vida de las características” en la página 159.

Dos propiedades de sistema definidas en el archivo .config/rcpinstall.properties del espacio de trabajo

proporcionan información específica para que el iniciador determine qué sucede al iniciar la plataforma.

rcp.install.id

Asocia una versión del espacio de trabajo con una versión instalada de la plataforma. En el

lanzamiento, el valor de rcp.install.id se compara con el valor de rcp.install.id en el archivo

<dir_instalación>/rcp/rcplauncher.properties. Si estos valores son diferentes, se supone que el

espacio de trabajo no coincide con la plataforma instalada. Consulte el apartado “Reutilización de

un espacio de trabajo existente” para obtener más información.

provisioning.manifest.version

Define la versión de la configuración de espacio de trabajo que se utiliza. En el lanzamiento, el

valor de provisioning.manifest.version se compara con el valor de la propiedad

provisioning.manifest.version del archivo <dir_instalación>/rcp/rcplauncher.properties. Si estos

valores son diferentes, se supone que el manifiesto de suministro definido por el archivo

rcplauncher.properties es más reciente y necesita aplicarse al espacio de trabajo. El iniciador inicia

entonces la plataforma utilizando ProvisioningApplication para realizar las operaciones definidas

en el manifiesto de suministro. Consulte el apartado “Utilización de la aplicación de suministro”

en la página 260 para obtener más información.

Puesto que la definición de plataforma contiene características asociadas con entornos locales específicos,

sólo se habilitarán las características que se apliquen al entorno local actual. Por ejemplo, si lanza la

plataforma utilizando el entorno local alemán de, las únicas características que se habilitarán serán las

que no tengan un filtro de entorno local específico y las que contengan el filtro que especifique de como

entorno local específico. En un escenario de instalación multiusuario, debe instalar todas las

características relacionadas con el entorno local antes de que los usuarios creen un nuevo espacio de

trabajo. Consulte el apartado “Instalación de contenido de idiomas adicional” en la página 186 para


Reutilización de un espacio de trabajo existente

Este apartado detalla cómo se manejan los espacios de trabajo existentes.

Se volverán a utilizar los espacios de trabajo si el valor de la propiedad rcp.install.id en

rcpinstall.properties no coincide con el valor de la propiedad rcp.install.id en rcplauncher.properties.

Normalmente, esta situación se produce si ya existe un espacio de trabajo en un sistema y se realiza una

nueva instalación de IBM Lotus Expeditor.

Si el iniciador determina que el espacio de trabajo no coincide con la versión instalada de la plataforma

basándose en la propiedad rcp.install.id, el iniciador realizará las acciones siguientes:

v El archivo .config/platform.xml se copiará en la raíz de espacio de trabajo y se redenominará como

platform.xml.old.

v El directorio .config se eliminará.


v Se creará un nuevo archivo rcpinstall.properties a partir del contenido del rcpinstall.properties

proporcionado en el plug-in com.ibm.rcp.base.

v Se lanzará la aplicación de suministro para crear un nuevo espacio de trabajo:

– La aplicación de suministro leerá el manifiesto de suministro definido por el archivo

rcplauncher.properties e intentará crear un nuevo espacio de trabajo utilizando las características ya

instaladas en el sistema de archivos, como si el espacio de trabajo no hubiera existido anteriormente.

– La aplicación de suministro leerá el archivo platform.xml.old que se había creado e intentará

habilitar cada una de las características incluidas en el sitio compartido y cada una de las

características incluidas en el sitio de aplicaciones de usuario.

– La aplicación de suministro saldrá y el iniciador reiniciará la plataforma instalada.

Lanzamiento de Lotus Expeditor Client desde una unidad de red

Este tema describe cómo iniciar Lotus Expeditor Client desde una unidad de red.

Cuando Lotus Expeditor Client se ha instalado en una unidad de red compartida, no se crean iconos ni

hay iconos disponibles para que los usuarios realicen el lanzamiento inicial de Lotus Expeditor Client. El

lanzamiento inicial se debe realizar localizando el programa rcplauncher.exe (Windows) o rcplauncher

(Linux) e iniciando el programa.

Por ejemplo, en Windows, si tiene una unidad de red X: que contiene el directorio X:\Expeditor, conmute

al directorio X:\Expeditor\rcp e inicie el programa rcplauncher.exe. El espacio de trabajo se creará en la

ubicación normal. Como parte de la creación inicial del espacio de trabajo, se añadirán iconos al escritorio

para permitir que los lanzamientos subsiguientes se produzcan utilizando los atajos.

En el caso de que la letra de unidad que hace referencia a la unidad de red cambie después del

lanzamiento inicial, los iconos creados ya no le permitirán lanzar Lotus Expeditor Client. Si la letra de

unidad se modifica de forma permanente, puede actualizar el atajo para cambiar la ubicación de

lanzamiento.

Lanzamiento de Lotus Expeditor Client utilizando una ubicación de

espacio de trabajo no estándar

La ubicación de espacio de trabajo predeterminada se calcula basándose en el sistema operativo y el

usuario definido.

Si se necesita localizar el espacio de trabajo en una ubicación alternativa, inicie el iniciador especificando

el parámetro "–data". Por ejemplo, si desea almacenar un espacio de trabajo en una unidad USB

conectada al sistema en la unidad G:, puede iniciar Lotus Expeditor Client especificando rcplauncher

–data G:\workspace. Puesto que se trata de una ubicación no estándar para el espacio de trabajo, debe

actualizar el atajo utilizado para lanzar Lotus Expeditor Client o utilizar siempre una consola o el menú

Ejecutar para lanzar Lotus Expeditor Client.

Se puede hacer referencia al mismo espacio de trabajo desde ubicaciones diferentes. Por ejemplo, si el

espacio de trabajo se crea en una unidad USB, se puede conectar como unidad G: en una máquina y

como D: en otra. Necesitará lanzar Lotus Expeditor Client e identificar específicamente el directorio de

datos en cada lanzamiento.

Consulte “Alteración temporal de la ubicación del directorio de espacio de trabajo” en la página 23 para


Utilización de enlaces a aplicaciones compuestas

Utilice el protocolo CAI para iniciar IBM Lotus Expeditor.


Las aplicaciones compuestas son accesibles a través de URLs que empiecen por CAI:///. Este protocolo se

denomina CAI (Composite Application Infrastructure - Infraestructura de aplicaciones compuestas). Para

que el navegador entienda el protocolo CAI, éste debe estar registrado con el sistema operativo. En

Windows, el archivo de registro cai_register.reg forma parte de la instalación de IBM Lotus Expeditor.

IBM Lotus Expeditor contiene información que debe grabarse en el registro de Windows. En Linux, se

utiliza una tecnología parecida, denominada GConf, para registrar CAI con el sistema operativo. En una

instalación con varios usuarios, la primera vez que cada usuario ejecuta Lotus Expeditor Client, se ejecuta

este registro (habilitación).

Por tanto, cuando en el navegador se utiliza un URL que empieza por CAI:///, IBM Lotus Expeditor se

abrirá (si no está ya abierto) y cargará la aplicación compuesta especificada. Consulte el apartado

“Configuración del diseño de aplicación” en la página 158 para obtener más información. Además,

también se habilitarán los enlaces que empiecen por CAI:/// que se incluyan dentro de tipos de

documentos que den soporte a enlaces en el sistema operativo, con lo que IBM Lotus Expeditor abrirá y

cargará la aplicación compuesta especificada.

Dentro de IBM Lotus Expeditor, utilice los elementos de menú Editar → Copiar como (habilitados cuando

se abre una aplicación compuesta) para crear estos enlaces CAI:///.

Instalación de Lotus Expeditor Client en dispositivos

Este apartado le explica como puede, como administrador, ayudar a los usuarios en la instalación de

Lotus Expeditor Client en dispositivos soportados.

Tenga en cuenta que los dispositivos tienen posibilidades diferentes para ejecutar entornos de

aplicaciones grandes como Lotus Expeditor Client. Es aconsejable que apruebe previamente determinados

dispositivos para los usuarios basándose en la carga de aplicaciones que espera que ejecuten.

Instalación del entorno de ejecución base

Existen varios modos de instalar el entorno de ejecución base de Lotus Expeditor Client en un dispositivo

soportado:

Instalación desde un CD

Para dispositivos Windows Mobile y WinCE, puede proporcionar un CD a los usuarios finales. El

usuario debe tener un PC con ActiveSync instalado y el dispositivo conectado. El usuario ejecuta

un programa de instalación (setup) en el PC que transfiere un programa de instalación al

dispositivo donde continúa la instalación. Este método sólo es apropiado cuando hay una relación

de uno a uno entre el PC y el dispositivo. De forma alternativa, utilizando algún otro mecanismo

puede proporcionar a los usuarios uno de los siguientes archivos de configuración de Lotus

Expeditor Client basados en el sistema operativo.

Archivo de configuración Dispositivo

XPD-wm-setup.exe Para dispositivos Windows Mobile

Expeditor-wince5-setup.exe Para dispositivos WinCE

Instalación desde una tarjeta de almacenamiento

Para dispositivos Windows, puede proporcionar a los usuarios una tarjeta de almacenamiento que

contenga uno de los siguientes archivos cab de Lotus Expeditor Client basados en el sistema

operativo. Los usuarios pueden insertar la tarjeta de almacenamiento en el dispositivo e iniciar el

instalador utilizando el Explorador de archivos.


XPD-Core-wm2003.cab Para dispositivos Windows Mobile 2003

XPD-Core-wm.cab Para dispositivos Windows Mobile 5



Expeditor-Core-wince5.cab Para dispositivos WinCE

Para dispositivos Nokia E90, puede proporcionar una tarjeta de almacenamiento que contiene

Nokia eRCP, IBM Certificate Installer y el sitio de actualización Core S60 de IBM Lotus Expeditor.

Consulte las Notas del release de Lotus Expeditor Client para obtener las direcciones web de

Nokia eRCP y de IBM Certificate Installer. El sitio de actualización Core S60 de IBM Lotus

Expeditor se debe copiar del CD de IBM Lotus Expeditor. Copie la carpeta s60 de \device\install

en \downloads en la tarjeta de almacenamiento. Los usuarios pueden insertar la tarjeta de

almacenamiento en los dispositivos y abrir Nokia eRCP para instalarlo. A continuación, abra IBM

Certificate Installer para instalarlo. Para obtener más información sobre cómo instalar Nokia

eRCP, consulte la publicación Nokia eRCP Installation and Configuration Guide que se incluye con el

paquete Nokia eRCP. Los usuarios lanzan eRCP Application Manager para instalar la

característica IBM Lotus Expeditor del sitio de actualización de S60. Para obtener más

información sobre Nokia eRCP Application Manager, consulte la publicación Nokia eRCP User

Guide que se incluye con el paquete Nokia eRCP.

Nota: El soporte para Nokia E90 se proporciona como código avanzado de release para

evaluación y comprobación interna. El soporte para Nokia E90 no debe utilizarse para fines

de producción.

Instalación desde un sitio web

Para dispositivos Windows, puede configurar un sitio web que proporcione uno de los siguientes

archivos cab de IBM Lotus Expeditor. Los usuarios utilizan Internet Explorer en los dispositivos

para examinar el sitio web y descargar el archivo de instalación apropiado en el sistema

operativo de dispositivo. El archivo de instalación se ejecuta automáticamente y se inicia la

instalación en el dispositivo.


Expeditor-Core-wince5.cab Para dispositivos Windows CE 5

XPD-Core-wm2003.cab Para dispositivos Windows Mobile 2003

XPD-Core-wm.cab Para dispositivos Windows Mobile 5

Nota: Para obtener información sobre la configuración del servidor web, consulte “Instalación

con Network Client Installer” en la página 33.

Para dispositivos Nokia, puede configurar un sitio web que proporcione el sitio de actualización

Core S60 de IBM Lotus Expeditor. Los usuarios utilizan el navegador web Nokia para descargar e

instalar Nokia eRCP e IBM Certificate Installer. A continuación, lance eRCP Application Manager

para instalar Expeditor desde el sitio de actualización S60.

Si está migrando dispositivos gestionados por el servidor de IBM Lotus Expeditor 6.1 o 6.1.1 a 6.1.2,

después de la migración, deberá planificar un trabajo de inventario para que el servidor de gestión

obtenga información actualizada acerca de los dispositivos gestionados.

Instalación de aplicaciones de Lotus Expeditor Client

Existen varios modos de instalar en dispositivos las aplicaciones que se ejecutan en Lotus Expeditor

Client. El método que elija dependerá de cómo se vayan a gestionar los clientes. En todos los casos, es

responsabilidad suya proporcionar las dependencias que una aplicación necesita ejecutar. Éstas pueden

incluir características opcionales de Lotus Expeditor Client para el sitio de actualización de dispositivos.

Clientes gestionados de empresa

Los dispositivos se gestionan de forma remota. En este caso, utilice la consola del servidor Device

Manager para empaquetar aplicaciones y crear trabajos que se despliegan automáticamente en


http://www.ibm.com/support/docview.wss?rs=3149&uid=swg

dispositivos. Consulte el apartado “Gestión utilizando el servidor Device Manager” en la página

197 para obtener más información. Cuando se instala una aplicación en un dispositivo, es posible

que el usuario vea un mensaje emergente que le indique que reinicie Lotus Expeditor Client (o

que cierre Nokia eRCP para los dispositivos Nokia). Si es necesario realizar un reinicio, se podrá

lanzar la nueva aplicación después del reinicio. De lo contrario, se puede lanzar inmediatamente.

Sitio de actualización remoto

Puede empaquetar aplicaciones en un sitio de actualización que dejará disponible en un servidor

web. Consulte el apartado “Creación de un sitio de actualización” en la página 165 para obtener

más información. El usuario utiliza el Gestor de aplicaciones (o eRCP Application Manager en

dispositivos Nokia) para examinar el sitio de actualización remoto e instalar aplicaciones del sitio.

Tenga en cuenta que debe indicar al usuario la dirección web específica que debe examinar.

Sitio de actualización local

Puede empaquetar aplicaciones en un sitio de actualización que dejará disponible en una tarjeta

de almacenamiento. El usuario inserta la tarjeta de almacenamiento en el dispositivo y utiliza el

Gestor de aplicaciones (o eRCP Application Manager en dispositivos Nokia) para abrir el sitio e

instalar aplicaciones. Tenga en cuenta que para dispositivos Windows, es mejor poner los sitios de

actualización en una carpeta de la raíz de la tarjeta de almacenamiento. De este modo el nombre

de carpeta puede identificar el sitio de actualización y se puede poner más de un sitio en una

tarjeta si es necesario. Los sitios no se deben poner en una profundidad mayor que la de una

carpeta. Para dispositivos Nokia, el sitio de actualización debe estar en una carpeta ubicada en el

directorio \downloads.

Para dispositivos Windows Mobile, también puede poner un sitio de actualización en la carpeta

Mis documentos del dispositivo.

Para dispositivos WinCE, también puede poner un sitio de actualización en cualquier ubicación

del dispositivo.

Nota: Al instalar, actualizar o desinstalar características, es posible que se aconseje al usuario que

reinicie el entorno de ejecución de cliente. Generalmente esto no es necesario al instalar

características nuevas. Sin embargo, las actualizaciones y desinstalaciones no entrarán en

vigor hasta que se produzca un reinicio. Si un usuario tiene que realizar un proceso por

lotes de actualizaciones o desinstalaciones, es aceptable y más eficiente retardar el reinicio

hasta se ha completado la última operación.

Prerrequisitos del cliente

Este apartado describe los prerrequisitos del cliente para instalar Lotus Expeditor Client en un

dispositivo.

Puede ejecutar Lotus Expeditor Client en dispositivos con los siguientes sistemas operativos Windows:

v Windows Mobile 2003 Second Edition (Pocket PC y Phone Edition)

v Windows Mobile 5 (Pocket PC y Phone Edition)

v WinCE 5.0 Professional

Unidades específicas probadas para este release:

v Dell Axim (X50v y X51v)

v HP iPAQ (2790 y 4700)

v I-Mate JasJar

v Unitech PA962

v Symbol MC3090R-LC48S00GER

v Symbol MC9090-GF0HBEGA2WW

Unidades específicas soportadas: Nokia E90


Nota: El soporte para Nokia E90 se proporciona como código avanzado de release para evaluación y

comprobación interna. El soporte para Nokia E90 no debe utilizarse para fines de producción.

Puede instalar IBM Lotus Expeditor en el sistema de archivos del dispositivo o en una tarjeta de

almacenamiento. Debe tener un mínimo de 12 MB de espacio de disco disponible. Se necesitan 14 MB

adicionales de espacio de sistema de archivos temporalmente para instalar desde un archivo cab. Se

necesita un mínimo de 12 MB de memoria física disponible. Sin embargo, probablemente los requisitos

mínimos sólo le permitirán ejecutar aplicaciones de GUI ricas más pequeñas. Se recomienda que el

dispositivo tenga 16 MB de espacio de sistema de archivos y 16 MB de memoria física disponible.

Puede ejecutar Lotus Expeditor Client en dispositivos Nokia E90.

Para instalar Lotus Expeditor Client en un E90, primero debe instalar eRCP de Nokia y el instalador de

certificados de IBM. Consulte las Notas del release de Lotus Expeditor ClientLotus Expeditor Client para

conocer las direcciones Web de estos componentes. Después de que se haya instalado eRCP de Nokia,

debe tener un mínimo de MB de espacio de sistema de archivos y 2 MB de memoria física disponible. Sin

embargo, probablemente los requisitos mínimos sólo le permitirán ejecutar aplicaciones de GUI ricas más

pequeñas. Se recomienda que el dispositivo tenga 8 MB de espacio de sistema de archivos y 8 MB de

memoria física disponible.

Desinstalación

Puede desinstalar Lotus Expeditor Client de un dispositivo.

Para dispositivos Windows Mobile, si ha instalado utilizando un archivo setup.exe, conecte el dispositivo

utilizando ActiveSync y desinstale ejecutando setup.exe otra vez, eligiendo eliminar Lotus Expeditor

Client. Si ha instalado desde una tarjeta de almacenamiento o un sitio web, en el dispositivo seleccione

Inicio → Configuración → Sistema → Quitar programas. Seleccione IBM Lotus Expeditor Client y toque

Eliminar. No elimine el directorio \workspace si desea conservar la información de aplicación y el ID de

dispositivo.

Para dispositivos WinCE, si ha instalado utilizando un archivo setup.exe, conecte el dispositivo utilizando

ActiveSync y desinstale ejecutando setup.exe otra vez, eligiendo eliminar Lotus Expeditor Client. Si ha

instalado desde una tarjeta de almacenamiento o un sitio web, en el dispositivo seleccione Inicio →

Configuración → Panel de control → Quitar programas. Seleccione IBM Lotus Expeditor Client en la lista

de aplicaciones. No elimine el directorio \workspace si desea conservar la información de aplicación y el

ID de dispositivo.

Para dispositivos Nokia E90, lance el gestor de aplicaciones eRCP. Seleccione Gestionar características.

Seleccione las características de Lotus Expeditor Client que desea eliminar. Seleccione Opciones →

Desinstalar la característica.



Lanzamiento de Lotus Expeditor Client en dispositivos

Revise cómo lanzar Lotus Expeditor Client en dispositivos Windows y Nokia E90.

No necesita lanzar directamente Lotus Expeditor Client en dispositivos. En lugar de ello, se inicia

automáticamente el entorno de Lotus Expeditor Client cuando se inician las aplicaciones de Lotus

Expeditor Client. Tenga en cuenta que el dispositivo no se puede gestionar de forma remota hasta que se

inicia una aplicación de Lotus Expeditor Client.

En dispositivos Windows, Lotus Expeditor Client permanecerá en ejecución mientras cualquier aplicación

IBM Lotus Expeditor está aún abierta.


http://www.ibm.com/support/docview.wss?rs=3149&uid=swg

En dispositivos Nokia E90, una vez que se ha iniciado eRCP de Nokia, Lotus Expeditor Client permanece

en ejecución hasta que se apaga el dispositivo.



Instalación con Network Client Installer

Instale Network Client Installer para que los usuarios puedan instalar de forma remota Lotus Expeditor

Client, instalar los componentes administrativos necesarios en el servidor de Portal y gestionar Lotus

Expeditor Client.

Nota: Ejecución de herramientas de línea de mandatos en Windows cuando está configurado para el

idioma húngaro: Por omisión, cuando Windows está instalado con húngaro, la página de códigos

para el indicador de mandatos no contiene todos los caracteres necesarios para mostrar la

traducción al húngaro que proporcionan las herramientas ArchiveCreator y SiteXMLUpdater. Para

utilizar estas herramientas, configure el indicador de mandatos siguiendo estos pasos:

1. Establezca el font en Lucinda Console.

2. Establezca la página de códigos 1251 ejecutando el mandato chcp 1251.

Ahora el texto para las herramientas de línea de mandatos que proporciona Network Client

Installer aparecerá correctamente en húngaro.

Prerrequisitos de cliente de Network Client Installer

Asegúrese de que cada máquina en la que piensa instalar Network Client Installer satisface estos

requisitos.

Los requisitos mínimos de hardware para las máquinas cliente son:

v 10 MB de espacio libre de disco (sólo Portal)

v 200 MB de espacio libre de disco (sólo Web)

v 210 MB (Web y Portal)

v Requisitos para Web: IBM HTTP Server u otro servidor HTTP soportado

v Requisitos para Portal: Portal 6.0

Los entornos Windows IA32 y Linux IA32 admitidos son:

v Microsoft Windows 2000 Professional Service Pack 4 (sólo para la ejecución de escritorio de Lotus

Expeditor Client)

v Microsoft Windows XP Professional Service Pack 1 y 2

v Microsoft Windows XP Home Edition Service Pack 1 y 2

v Microsoft Windows XP Tablet PC Edition 2005

v Red Hat EL 4.0 WS con soporte GTK – Actualización 4

v Red Hat EL 5.0 WS con soporte GTK

v SUSE Linux Enterprise Desktop 10

v Microsoft Windows Vista

Instalación de Network Client Installer

Puede instalar Network Client Installer en Lotus Expeditor Server, un servidor Web autónomo o un

servidor de Portal.

Antes de empezar deberá conocer la configuración de estos servidores para saber cuáles son las mejores

opciones.


También debe tener una cuenta activa en el servidor.

1. Inserte el CD de Lotus Expeditor Client en la unidad de CD-ROM.

2. Si la función de ejecución automática está habilitada en el sistema, se abre un navegador y se muestra

una pantalla de bienvenida. Si la ejecución automática se ha inhabilitado, lance el archivo que sea

apropiado para el sistema operativo de servidor. Network Client Installer está ubicado en el CD de

Lotus Expeditor Client en el directorio \nci:

Windows

Lance \nci\install\setupwin32.exe.

Linux Lance \nci\install\setuplinux.sh.

AIX Lance \nci\install\setupaix

Linux en System p

Lance \nci\install\setupLinuxPPC.sh.3. Siga las solicitudes para instalar Network Client Installer.

Nota: No instale Network Client Installer en la vía de acceso de NL de varios entornos locales. Los

caracteres válidos para un directorio de instalación son a a z, A a Z, 0 a 9, ’-’ (guión), ’_’

(subrayado) y espacio (sólo Windows). Los caracteres de doble byte no son válidos.

Si elige instalar en el servidor Web, se le solicitará la ubicación de la raíz de documentos de servidor

HTTP, el nombre de host y el URL para acceder a la raíz de documentos. También tendrá la opción de

establecer el URL de agente de Gestión de dispositivos, así como el URL de Portal.

Si elige instalar en el servidor de Portal, se le solicitará el directorio de inicio de servidor de Portal así

como el ID de usuario administrativo y la contraseña para el servidor de Portal.Especifique estos

valores como pertenecientes al entorno.

Network Client Installer se ha instalado en el servidor y el servidor está preparado para que se instale un

cliente.

Si está instalando en el servidor Web, se despliegan los siguientes componentes de Network Client

Installer en el servidor:

v Sitio de actualización de Lotus Expeditor Client

v Instaladores de Lotus Expeditor Client

v Applet de descarga

v Los archivos de configuración para el applet de descarga que contiene el URL de host se actualizan con

la información recogida durante la instalación.

Después de instalar Network Client Installer, el diseño de archivos es el siguiente:

/Expeditor

Archivos de carpeta raíz de programa

/Expeditor/applet

Archivos para el applet de descarga

/Expeditor/install

Instaladores de cliente y archivos de opciones

/Expeditor/updates

Sitio de actualización de Eclipse

Si está instalando en el servidor de Portal, se despliegan los siguientes componentes de Network Client

Installer en el servidor de Portal:

v Portlets para el cliente administrado por Portal

v Portlet de descarga para la instalación de cliente


v Plantilla de aplicación Información relacionada

“Notificación a los usuarios del modo de instalar desde la Web utilizando Windows y Linux” en la

página 37Como administrador, necesita informar a los usuarios sobre cómo instalar Lotus Expeditor Client

desde la Web utilizando Windows y Linux.

“Notificación a los usuarios del modo de instalar desde la Web utilizando dispositivos soportados” en

la página 37Como administrador, necesita informar a los usuarios cómo instalar Lotus Expeditor Client desde la

Web utilizando dispositivos soportados.

Instalación de Network Client Installer al utilizar SSL con un certificado de prueba

autofirmado

Si ha configurado el servidor Web o el servidor de Portal para utilizar SSL (Secure Sockets Layer - Capa

de sockets seguros) y está utilizando un certificado de prueba autofirmado, debe crear un almacén de

confianza y definirlo en Network Client Installer antes de ejecutar Network Client Installer para

asegurarse de que las comunicaciones SSL se realizarán correctamente entre el programa de instalación

Network Client Installer y el servidor Web o el servidor de Portal.

Si el entorno de Portal es HTTPS(10035) y el puerto 10038 está inhabilitado, antes de instalar Network

Client Installer, debe validar que las entradas del archivo <DIR_INICIAL_WP>/config/wpconfig.properties sean correctas. Por ejemplo:

XmlAccessPort=10035

xmlAccessProtocol=https

Los pasos 1-5 siguientes son, específicamente, para IBM HTTP Server (IHS). Si utiliza un servidor HTTP

distinto, consulte esa documentación para obtener información sobre cómo crear un almacén de

confianza, y ejecute el paso 6 que hay a continuación.

1. Extraiga el certificado autofirmado de IBM HTTP Server (IHS) si está instalado en el servidor Web.

Lance ikeyman desde <inicio_ihs>\bin y abra el almacén de claves definido en el archivo httpd.conf

bajo la directiva Keyfile. Por ejemplo, el archivo de claves C:/Archivos de programa/IBM HTTP

Server/selfCert/serverkey.kdb deberá tener un aspecto similar al siguiente:

# Extraer la clave pública de certificado autofirmado.

# Pulse Certificados personales en el menú y seleccione el certificado autofirmado que está utilizando.

# Pulse Extraer certificado. Extraiga el certificado en un archivo:

Data type

Base64-encoded ASCII data

Certificate file name

cert.arm

Location

c:\Archivos de programa\IBM HTTP Server\selfCert

# Pulse Aceptar.

2. Extraiga el certificado autofirmado de Portal.

Lance ikeyman de <inicio_ihs>\bin y abra el almacén de claves definido para Portal. El archivo de

claves C:\ibm\WebSphere\profiles\wp_profile\etc\DummyServerKeyFile.jks deberá tener un aspecto

similar al siguiente:


# Pulse Certificados personales en el menú y seleccione el certificado autofirmado

# que está utilizando


Data type



cert.arm


Location

C:\ibm\WebSphere\profiles\wp_profile\etc

# Pulse Aceptar.

3. Cree un nuevo almacén de claves.

Lance ikeyman desde <inicio_ihs>\bin

# Pulse el Archivo de base de datos de claves >

Nuevo desde el menú de iKeyman.

# Entre los valores siguientes:

Key database type

JKS

File name

key.jks

Location

c:\testKeyStore

# Pulse Aceptar.

# Establezca la contraseña que prefiera en el indicador de contraseña y confirme la contraseña.

4. Importe el certificado de IBM HTTP Server.

# Pulse Certificados de firmante en la lista y pulse Añadir. Esta acción importa el

# certificado público extraído anteriormente del archivo de almacén de claves de servidor HTTP.

Data type



cert.arm

Location

c:\Archivos de programa\IBM Http Server\selfcert

# Pulse Aceptar. Se le solicitará un nombre de etiqueta que represente el certificado público de firmante fiable.

# Entre una etiqueta para el certificado: Certificado autofirmado IHS

5. Extraiga el certificado autofirmado de Portal

Lance ikeyman desde c:\Archivos de programa\IBM Http Server\bin

Abra el almacén de claves definido para portal

Keyfile C:\ibm\WebSphere\profiles\wp_profile\etc\DummyServerKeyFile.jks


# Pulse Certificados personales en el menú y seleccione el certificado WASplugin que acaba de crear.


Data type



cert.arm

Location

C:\ibm\WebSphere\profiles\wp_profile\etc

# Pulse Aceptar.

6. Cree un archivo SP apropiado.

Utilizando un editor, cree un archivo de texto con el mismo nombre que el iniciador de instalación de

Network Client Installer, pero con la extensión .sp:

Windows:

setupwin32.sp

Linux: setuplinux.sp

AIX: setupaix.sp

Linux en System p:

setupLinuxPPC.spAñada estas líneas:

javax.net.ssl.trustStore=C:\testKeyStore\key.jks

javax.net.ssl.trustStorePassword=<contraseña almacén claves>

javax.net.ssl.trustStoreType=jks


Ahora, cuando lance el instalador, éste se comunicará correctamente utilizando SSL con los

certificados autofirmados.

Puesto que el mandato siguiente es necesario para instalar satisfactoriamente Network Client Installer

en un entorno SSL de Portal en el que el puerto 10038 está inhabilitado, esa información debe

comunicarse a sus usuarios.

./setupLinuxPPC.sh -is:javaconsole -V NCI_PORTAL_HOME_URL_PORT=10035 -V NCI_PORTAL_HOME_URL_PROTOCOL=https

Notificación a los usuarios del modo de instalar desde la Web

utilizando Windows y Linux

Como administrador, necesita informar a los usuarios sobre cómo instalar Lotus Expeditor Client desde la

Web utilizando Windows y Linux.

Se debe informar a los usuarios de los pasos siguientes:

1. Proporcione a los usuarios el URL del sitio web de instalación personalizada. Utilice la plantilla

HTML de ejemplo proporcionada y personalícela para el entorno. El valor predeterminado es

http://<nombre_servidor>/Expeditor/applet/index.html.

2. Si los navegadores no soportan Java, se les solicitará que guarden un archivo zip que contenga el

instalador y los archivos asociados. Indíqueles que ejecuten unzip para desempaquetar este archivo y

ejecuten el instalador apropiado: install.bat (para Windows) o install.sh (para Linux). Si ha actualizado

el archivo download.properties para pasar parámetros al instalador, deberá proporcionar estas

instrucciones a los usuarios. Las opciones de línea de mandatos no estarán contenidas en el archivo

zip.

3. Al terminar, el instalador de cliente se pone en contacto con el servidor y termina la instalación. Si el

sitio de actualización está en un área protegida, el cliente solicitará el ID de usuario y la contraseña.

Consideraciones especiales para Windows Vista

No se soporta la instalación de Lotus Expeditor Client desde la Web utilizando Windows Vista en

modalidad protegida. Siga estos pasos como método alternativo:

1. Coloque el servidor Web en una zona fiable utilizando la configuración de Internet Explorer. Esto

inhabilitará la modalidad protegida para este sitio y permitirá que la instalación se realice

satisfactoriamente.

2. Dirija a los usuarios para que accedan al sitio siguiente:

http://<servidor>/Expeditor/applet/text/<idioma>/DownloadListIndex.html

donde <servidor> es el nombre de servidor e <idioma> es el idioma.

Notificación a los usuarios del modo de instalar desde la Web

utilizando dispositivos soportados

Como administrador, necesita informar a los usuarios cómo instalar Lotus Expeditor Client desde la Web

utilizando dispositivos soportados.

Se debe informar a los usuarios de los pasos siguientes:

1. Proporcione a los usuarios el URL del sitio web de instalación personalizada. Utilice la plantilla

HTML de ejemplo proporcionada y personalícela para el entorno. El valor predeterminado es

http://<nombre_servidor>/Expeditor/applet/DownloadListIndex.html.

2. Seleccione el enlace apropiado para la plataforma en la lista de la parte inferior. Esto hace que se

descargue un archivo .cab al dispositivo. Cuando el dispositivo solicita si el archivo se debe instalar

automáticamente, los usuarios deben seleccionar sí, instalar el archivo automáticamente. Cuando la

instalación se ha completado, los usuarios deben configurar manualmente el resto de los valores.

3. Al terminar, los usuarios de los dispositivos gestionados de empresa deben establecer las preferencias

de gestión de empresa. Esto se puede realizar instalando un archivo de configuración que se les


proporciona o estableciendo los campos en la página de preferencias de gestión de empresa. Esta

página de preferencias es accesible en el dispositivo desde el gestor de aplicaciones seleccionando

Mandato → Preferencias. Consulte “Configuración del Agente de gestión de empresa” en la página

197 para obtener más información sobre los parámetros de Agente de gestión de empresa.

Instalación silenciosa de Network Client Installer

Puede configurar el programa de instalación de Network Client Installer para que se ejecute de forma

silenciosa si no desea interactuar con el asistente de instalación.

Para ello, deberá instalar utilizando el asistente de instalación, respondiendo a todas las preguntas

respecto al modo en que desea que se ejecute la instalación silenciosa. Cuando la instalación se haya

completado, copie el archivo installNCI.rsp del directorio <destino>/package, donde <destino> es el

directorio en el que ha elegido instalar Network Client Installer.

Nota: Los ejecutables del instalador están ubicados en el directorio nci/install/ del CD.

v En un sistema Windows, ejecute el archivo setupwin32.exe.

v En un sistema Linux, ejecute el archivo setuplinux.sh.

v En un sistema AIX, ejecute el archivo setupaix.

v En un sistema Linux para System p, ejecute el archivo setupLinuxPPC.sh.

Elija entre dos procedimientos para instalar silenciosamente:

v Edite el archivo de respuestas.

Importante: Si elige esta opción, la contraseña de Portal permanecerá en texto sin cifrar en el archivo

de respuestas después de que se haya completado la instalación. No se recomienda

utilizar este planteamiento.

1. Utilizando un editor de texto, abra el archivo de respuestas que ha copiado anteriormente y

<dir_destino>package/installNCI.rsp, sustituya <entre su contraseña> por su contraseña en la

propiedad NCI_PORTAL_PASSWORD y guarde el archivo.

Por ejemplo, NCI_PORTAL_PASSWORD=expeditor.


<ejecutable de configuración> -silent -options installNCI.rsp

Por ejemplo, en Linux:

setuplinux.bin -silent -options installNCI.rsp

v Utilice una opción de línea de mandatos.


<ejecutable de configuración> -silent -options installNCI.rsp -V NCI_PORTAL_PASSWORD=<contraseña de portal>

Por ejemplo, en AIX:

setupaix -silent -options installNCI.rsp -V NCI_PORTAL_PASSWORD=myPortalPassword

Nota: Dado que se trata de una instalación silenciosa, no se crea salida gráfica ni de línea de

mandatos. Para ver el progreso de la instalación o para ver los mensajes de error generados, vea

el archivo de registro de instalación, que está ubicado en la carpeta temp definida por el sistema

operativo. En este archivo temporal, el archivo NCI/logs/masterInstallLog.txt contendrá la

salida de la instalación.

Desinstalación de Network Client Installer

Este tema describe cómo desinstalar Network Client Installer. Antes de desinstalar Network Client

Installer, compruebe que la instalación se haya completado satisfactoriamente.

Para desinstalar Network Client Installer, siga estos pasos:


1. Localice y lance el programa Network Client Uninstaller. Dependiendo de cómo se haya instalado el

producto, el archivo de desinstalación estará situado en el directorio _uninst2 o _uninst3 de la vía de

acceso de instalación (especificado como \_uninstn como se muestra a continuación).

Windows

vía_acceso_instalación\_uninstn\uninstaller.exe.

Linux vía_acceso_instalación/_uninstn/uninstaller.sh

AIX vía_acceso_instalación/_uninstn/uninstaller.bin

Linux para System p

vía_acceso_instalación/_uninstn/uninstaller.sh

Nota: Para desinstalar Network Client Installer en WebSphere Portal con SSL habilitado, siga estos

pasos:

a. Copie el archivo .sp generado durante la instalación de Network Client Installer en el

directorio dir_inicial_nci/_uninstn que contiene el programa de desinstalación, donde

dir_inicial_nci es el directorio de instalación de Network Client Installer y n es un número.

b. Cambie el nombre del archivo .sp por uninstaller.sp, de forma que coincida con el nombre

de archivo base del iniciador.

c. Lance el programa de desinstalación y realice todos los pasos necesarios.2. Siga las indicaciones.

Network Client Installer se ha desinstalado.

Desinstalación silenciosa de Network Client Installer

Puede desinstalar de forma silenciosa el programa de instalación Network Client Installer.

Si necesita desinstalar de forma silenciosa Network Client Installer, debe utilizar el iniciador de

desinstalación apropiado anterior, junto con el archivo de respuestas de instalación silenciosa al que se

hace referencia en “Instalación silenciosa de Network Client Installer” en la página 38.

Por ejemplo, en Windows:

C:\Archivos de programa\IBM\Lotus\Expeditor\NCI\_uninst3\uninstaller.exe -silent -options

installNCI.rsp –V NCI_PORTAL_PASSWORD=expeditor

Actualización de Network Client Installer

Tenga en cuenta estos puntos antes de realizar la actualización.

Si tenía una versión anterior de Network Client Installer (NCI) instalada en el sistema y está instalando

esta versión como actualización, debe tener en cuenta los puntos siguientes:

v Si hay instalada una versión anterior de NCI, se detectará. La nueva versión se instalará directamente

sin necesidad de desinstalar manualmente la versión anterior.

v El sitio de actualización de cliente que se instala en el servidor web quedará sobregrabado por el sitio

de actualización en el CD de cliente. Esto significa que si ha añadido características a este sitio y utiliza

la herramienta siteXmlUpdater, necesitará volver a ejecutar esta herramienta después de la

actualización.

v Los instaladores de cliente y los archivos de manifiesto quedarán sobregrabados por los instaladores de

cliente del CD de cliente. Esto significa que si ha personalizado los archivos de manifiesto de

suministro en el directorio install/deploy, necesitará volver a personalizar estos archivos después de la

actualización.


Actualización de la información de instalación en el servidor Web

Si mueve el servidor Web o cambia otra información de sistema, necesitará actualizar la configuración en

el servidor Web.

Para actualizar la información de instalación:

1. Actualice la propiedad installer.root en el archivo download.properties.

Si desea cambiar el modo en el que se ejecuta el instalador de cliente, puede actualizar la propiedad

win32.downloads.execute y linux.downloads.execut. Esto es útil para pasar un archivo de opciones u

otros parámetros al instalador. Consulte el apartado “Utilización de archivos de opciones” en la

página 17 para obtener más información.

2. Ejecute la herramienta ArchiveCreator ubicada en el directorio <raíz_instalación_Expeditor>/bin.

La herramienta ArchiveCreator vuelve a crear los archivos zip que se descargan cuando Lotus Expeditor

Client no puede ejecutar la applet de descarga.

Instalación de Lotus Expeditor Client para Windows y Linux en Portal

Puede instalar Lotus Expeditor Client para Windows y Linux en Portal.

Antes de instalar Lotus Expeditor Client, revise los requisitos del sistema y compruebe que tiene

instalada y configurada la versión correcta de Portal Server. Compruebe que el software Network Client

Installer no exista anteriormente en el servidor. También debe estar instalado un servidor HTTP

soportado. Puede estar en un sistema de la red.

También debe tener una cuenta activa en el servidor.

1. Instale Network Client Installer del CD de Lotus Expeditor Client.

2. Seleccione Contenido Web y Contenido de portal en la lista de características.

Nota: Si está instalando en un entorno de clúster, seleccione sólo Contenido de portal en la lista de

características. El contenido Web se debe instalar en el servidor Web remoto.

3. Utilice los portlets de Administración de portal para poner el portlet de descargas en una página a la

que los usuarios puedan acceder.

4. En un entorno en clúster, modifique el valor de wed.download.url del portlet Download por el URL

del sitio de instalación del servidor web remoto. Por ejemplo, http://<nombre_servidor>/Expeditor/applet/index.html.

Lotus Expeditor Client está preparado para instalarse en Portal.

Notificación a los usuarios del modo de instalar el cliente de escritorio

desde Portal

Como administrador, necesita indicar a los usuarios cómo se instala desde Portal.

Se debe informar a los usuarios de los pasos siguientes para instalar Lotus Expeditor Client desde Portal.

1. Inicie la sesión en Portal utilizando un navegador y acceda al portlet Descargas.

2. Seleccione el enlace de instalación.

3. Si los navegadores no soportan Java, se les solicitará que guarden y ejecuten el instalador.

4. Es posible que se solicite a los usuarios que reinicien Lotus Expeditor Client.

Aplicación de actualizaciones

Puede aplicar actualizaciones a Network Client Installer desde el servidor.


http://publib.boulder.ibm.com/infocenter/ledoc/v6r11/index.jsp?topic=/com.ibm.help.ic.doc/expeditor_sysreqs.html

Antes de instalar Lotus Expeditor Client, compruebe que esté instalado y configurado Lotus Expeditor

Server o Portal Server 6.0 o superior. Compruebe que el software Network Client Installer se haya

desplegado en Lotus Expeditor Server.

1. Descargue e instale el instalador de actualizaciones si no está ya presente en el servidor.

2. Descargue el paquete de actualizaciones de Network Client Installer.

3. Ejecute el instalador de actualizaciones y seleccione la actualización en Network Client Installer.

Aplicación de fixpacks y arreglos individuales

Puede aplicar fixpacks y arreglos individuales para actualizar los paquetes de Network Client Installer.

Antes de instalar la actualización en Lotus Expeditor Client, asegúrese de que Network Client Installer se

ha desplegado en el servidor Web.

1. Descargue ele fixpack.

2. Ejecute unzip para desempaquetar el IFix encima del sitio de actualización de Eclipse existente

(ubicado bajo <raízdoc>/expeditor/updates/platform).

3. Ejecute la herramienta siteXMLUpdater ubicada en el directorio <dir_instalación_nci>/bin. Esto

actualiza el archivo site.xml.

Utilización de archivos de opciones

Si desea cambiar las opciones de la instalación de cliente que se produce al realizar la descarga del

servidor Web, puede editar los archivos de opciones ubicados en el directorio <raízdoc>/Expeditor/install

en el servidor Web.

Consulte el apartado “Utilización de archivos de opciones” en la página 17 para conocer el formato de

estos archivos de opciones.

Para elegir las opciones de línea de mandatos para la instalación de cliente en el servidor, edite el archivo

download.properties bajo el directorio <raízdoc>/Expeditor/applet.

Después de editar este archivo o los archivos de opciones, ejecute la herramienta Creador de archivadores

bajo <instalación_nci>/bin para volver a generar los archivadores para navegadores no habilitados para

java.

Instalación y lanzamiento de Expeditor Client en un entorno Citrix

El cliente de escritorio de Lotus Expeditor puede instalarse en un Citrix Presentation Server 4.5 que

ejecute Windows Server 2003 y, posteriormente, publicarse como una aplicación para permitir el acceso a

los usuarios de Citrix. Esta sección describe los procedimientos para una instalación de este tipo.

Prerrequisitos

En este tema se listan los prerrequisitos y las recomendaciones para instalar satisfactoriamente el cliente

de escritorio de Lotus Expeditor en Citrix Presentation Server 4.5.

Prerrequisitos:

v Windows Server 2003 con Citrix Presentation Server 4.5 Atención: Para una nueva instalación de Citrix, es muy recomendable probar el servidor mediante la

publicación de una aplicación, por ejemplo, Adobe Acrobat Reader, antes de intentar publicar Lotus

Expeditor.

v Citrix Presentation Server 4.5

Notas:

– Lotus Expeditor 6.1.2 sólo da soporte a la tecnología de despliegue Web/ICA.


|

|||

|

||

|

|

|||

|

|

|

– Lotus Expeditor 6.1.2 sólo da soporte a su publicación como una aplicación.

– Lotus Expeditor 6.1.2 no da soporte a varios supervisores de cliente con Citrix Presentation

Server 4.5.

– Si se utiliza un conjunto de servidores Citrix, también es recomendable emplear los perfiles

móviles de Windows para asegurar que el usuario tenga acceso a su información específica

de Lotus Expeditor, independientemente del servidor en el que el cliente de Expeditor se esté

ejecutando.

Instalación de Expeditor Client en Windows Server 2003 / Citrix Server

En este tema se describe cómo instalar Expeditor Client en un entorno de Windows Server 2003 / Citrix

Presentation Server 4.5.

Los pasos iniciales de instalación son parecidos a cualquier otra instalación multiusuario de Lotus

Expeditor:

v Un miembro del grupo de administradores realiza la instalación

v Multiusuario

v Configurar Portal principal, Gestión de empresa y SSO (Inicio de sesión único), si se desea

v Lanzar Lotus Expeditor después de la instalación, para comprobar que funcione correctamente

v Instalar todas las aplicaciones adicionales basadas en Lotus Expeditor, a las que los usuarios pueden

acceder

v Salir de Lotus Expeditor

Configuración de Citrix Presentation Server para publicar Lotus

Expeditor como una aplicación

En este tema se describe cómo utilizar el asistente de Citrix Presentation Server para publicar Lotus

Expeditor como una aplicación.

Citrix Presentation Server 4.5 proporciona un asistente para la publicación de aplicaciones. Puede lanzar

el asistente desde dentro de la consola de gestión de acceso de Citrix. Los valores recomendados para

cada panel del asistente son los siguientes:

Nota: Los valores presuponen que la ubicación predeterminada de instalación es C:\Archivos de

programa\IBM\Lotus\Expeditor\

v Welcome: No hay opciones de configuración. Vaya al panel siguiente.

v Name: Escriba un nombre de visualización, por ejemplo, Lotus Expeditor y complete la descripción de

la aplicación.

v Type: En la sección Application, seleccione Accessed from server e Installed application.

v Location: Complete los campos siguientes:

Command line: C:\Archivos de programa\IBM\Lotus\Expeditor\rcp\rcplauncher.exe

Working directory: C:\Archivos de programa\IBM\Lotus\Expeditor\rcp

Isolate application: Inhabilite este recuadro de selección.v Servers: Añada uno o más nombres de servidor Citrix configurados para distribuir Lotus Expeditor a

las máquinas cliente.

v Users: Añada uno o más nombres de usuario, que requieren acceso a Lotus Expeditor.

v Shortcut presentation:

– Application icon:

- El binario rcplauncher.exe no contiene información sobre el icono para permitir la modificación

para la marca, ni la personalización. Por tanto, es necesario apuntar a un archivo ICO de

Windows específico.


|

||

||||

|

||

||

|

|

|

|

||

|

|

|

||

|||

||

|

||

|

|

|

|

|

||

|

|

|

|||

- El icono predeterminado de marca de Lotus Expeditor se encuentra en C:\Archivos de

programa\IBM\Lotus\Expeditor\rcp\eclipse\features\com.ibm.rcp.personality.default.branding.feature_versión\win32x86\xpd.ico

– Application shortcut placement: Puede añadir el icono especificado anteriormente en el menú de

Inicio o como un acceso directo de escritorio de la máquina cliente, pero no es necesario. Si el icono

no se añade en ninguna de esas dos ubicaciones, los usuarios deben acceder a la interfaz web de

Citrix para iniciar la sesión y, posteriormente, lanzar Lotus Expeditor.v Publish immediately: Pulse Finish. Los usuarios de Citrix ya pueden acceder a Lotus Expeditor.

Acceso a Lotus Expeditor de forma remota a través de la interfaz web

de Citrix

En este tema se describe cómo pueden los clientes de Citrix acceder a Lotus Expeditor de forma remota.

Una vez completados los pasos de instalación y publicación de la aplicación, los clientes de Citrix pueden

acceder a Lotus Expeditor efectuando los pasos siguientes:

1. Abra Internet Explorer y cargue la dirección web del servidor Citrix.

2. Instale el paquete Cliente ICA de Citrix, si todavía no está instalado. Según las opciones de

instalación seleccionadas, es posible que tenga que reiniciar el navegador y/o el sistema.

3. Inicie la sesión en el servidor Citrix. Aparece Lotus Expeditor en el panel de aplicaciones.

4. Pulse el icono de Lotus Expeditor para lanzar el cliente ICA de Citrix. Se ha lanzado la plataforma de

Lotus Expeditor.

Nota: Si se han seleccionado opciones Display name o Application shortcut placement distintas durante

la configuración, es posible que el usuario tenga que buscar un icono distinto, o realizar

operaciones adicionales de navegación en la interfaz web de Citrix, antes de lanzar la plataforma

de Lotus Expeditor.

Limitaciones del entorno Citrix

En este tema se listan las limitaciones cuando se ejecuta el cliente de escritorio de Lotus Expeditor en un

entorno Citrix.

El cliente de escritorio de Lotus Expeditor en un entorno Citrix funciona de forma parecida a cualquier

otra instalación multiusuario. Sin embargo, existen las limitaciones siguientes, debidas principalmente a

varios usuarios accediendo simultáneamente a la plataforma:

v Lotus Expeditor 6.1.2 no da soporte a la funcionalidad de entorno de trabajo restringido de Lotus

Expeditor en un entorno Citrix.

v El directorio de instalación (por ejemplo, C:\Archivos de programa\IBM\Lotus\Expeditor) debe estar

protegido adecuadamente de forma que sólo los miembros del grupo de administradores puedan

añadir, modificar y suprimir archivos.

v Para evitar errores en la plataforma, sólo un miembro del grupo de administradores debe

gestionar/suministrar la instalación de plataforma de Lotus Expeditor en un momento dado.

Cambio de la máquina virtual

La máquina virtual (VM) predeterminada utilizada por la plataforma de IBM Lotus Expeditor es el

entorno de ejecución jclDesktop. Esta máquina virtual proporciona suficientes posibilidades para instalar

el conjunto predeterminado de componentes de IBM Lotus Expeditor. Si necesita más funciones, por

ejemplo Swing, o las bibliotecas de programación AWT proporcionadas por la máquina virtual (VM) Java

2 SE 5.0, siga las instrucciones de esta sección para instalar IBM Device Runtime Environment (DRE), un

producto que puede adquirir por separado.


|||

||||

|

|

|

|

||

|

||

|

||

||||

|

||

|||

||

|||

||

El producto IBM Device Runtime Environment contiene dos características aplicables a la plataforma de

Lotus Expeditor Client. La primera es la característica J2SE Core JVM, que proporciona las posibilidades

de VM de Java 2 SE 5.0. La segunda característica es JavaServer Faces, una alternativa al soporte de

Apache MyFaces.

Para utilizar cualquiera de estos componentes, debe instalarlos en Lotus Expeditor Client.

Instalación de los componentes de DRE en Lotus Expeditor Client

Instale el DRE utilizando la interfaz de usuario de instalación/actualización o el manifiesto de suministro.

La interfaz de usuario de instalación/actualización es útil para instalar un DRE en un solo entorno de

ejecución, pero para procedimientos de automatización, es preferible utilizar el manifiesto de suministro.

Para instalar los componentes de DRE utilizando la interfaz de usuario del gestor de actualizaciones:

1. Inicie Lotus Expeditor Client. A continuación, seleccione Archivo → Aplicación → Instalar

2. En el diálogo Instalar/Actualizar (Actualizaciones de características), seleccione Buscar nuevas

características a instalar. Desde el diálogo Instalar (Sitios de actualizaciones a visitar), cree una

nueva definición de sitio de actualización.

Seleccione un Sitio remoto nuevo si el DRE está disponible gracias a la utilización de un sitio web.

De lo contrario, seleccione un Sitio local nuevo. Vaya a la ubicación del DRE (ubicación o letra de la

unidad de CD-ROM en la que es posible que se haya descomprimido en una letra de unidad

conectada o montada) y, a continuación, seleccione actualizaciones/cliente. Seleccione Finalizar.

Cuando aparece el diálogo Instalar (Resultados de la búsqueda), seleccione la característica

Característica JVM básica – J2SE y, a continuación, seleccione Siguiente. (En este momento también

puede seleccionar la característica JavaServer Faces (JSF). Si acepta los términos de la licencia,

seleccione Acepto las condiciones en el acuerdo de licencia y, a continuación, seleccione Siguiente.

Luego seleccione Finalizar para completar la instalación.

Es posible que aparezca un diálogo indicándole que la característica no tiene firma. Seleccione Instalar

en este diálogo para continuar.

3. Para efectuar una instalación más automatizada del DRE, puede personalizar el manifiesto de

suministro para la instalación (“Personalización de la instalación básica” en la página 21) o utilizar

ProvisioningApplication para instalar el DRE utilizando un manifiesto de suministro (“Utilización del

manifiesto de suministro” en la página 175).

Por ejemplo, podría utilizar el siguiente contenido de manifiesto de suministro en el archivo

C:\core.jvm.feature-j2se.xml:

<?xml version="1.0"?>

<ibm-portal-composite>

<domain-object name="com.ibm.rcp.installmanifest">

<object-data>

<install>

<installfeature id="core.jvm.feature-j2se" required="true">

<requirements>

<feature action="install"

id="com.ibm.rcp.jvm.feature"

match="greaterOrEqual" url="file:/X:/updates/client/site.xml"

shared="false"

version="2.0.0.0-200704260500"/>

</requirements>

</installfeature>

</install>

</object-data>

</domain-object>

</ibm-portal-composite>

donde X: es la unidad de CD-ROM que contiene el CD-ROM de DRE.

A continuación, debe invocar la aplicación de suministro para que instale el DRE además de la

jclDesktop VM que ya está instalada:

rcplauncher –application com.ibm.rcp.provisioning.application.ProvisioningApplication

–provisioningOperation provision C:\core.jvm.feature-j2se.xml


De forma alternativa, puede elegir instalar solamente la característica JVM básica – J2SE durante la

instalación inicial.

Puede actualizar los manifiestos de suministro user o multiuser.xml para que incluyan la definición

de característica tal como se hace más arriba (y eliminar la definición de com.ibm.rcp.jvm.feature que

hace referencia a la versión 1.0.0.x de la característica jvm).

Puede actualizar el manifiesto de suministro install.xml para que incluya la definición de

característica tal como se hace más arriba (y eliminar la definición de com.ibm.rcp.jvm.feature que

hace referencia a la versión 1.0.0.x de la característica jvm).

Cambio a una biblioteca de clases y entorno de ejecución diferente

Aunque puede instalar las dos máquinas virtuales (jclDesktop y Java 2 SE 5.0) en Lotus Expeditor Client,

sólo una estará activa para la plataforma. Para conmutar la VM activa, debe utilizar la interfaz de usuario

de gestión de aplicaciones para conmutar las VM. Para ello, seleccione Archivo → Aplicación → Gestión

de aplicaciones. Expanda el sitio /rcp/eclipse y localice la Característica JVM básica. Seleccione esta

característica y, a continuación, seleccione la tarea Sustituir por otra versión. Se abrirá un diálogo

solicitándole que seleccione otra versión de la característica. Utilizando este método puede conmutar de

jclDesktop a J2SE o de J2SE a jclDesktop.

Descripción del paquete de VM

La VM que implementa las especificaciones Java está empaquetada como una característica.

Todas las características de VM son características hijo de la característica padre com.ibm.rcp.jvm. El

número de versión principal representa un proveedor VM totalmente diferente. Por ejemplo, Lotus

Expeditor Client se entrega con la VM de escritorio JCL y es la versión principal 1. Este esquema permite

actualizar una VM sin interrupciones y también permite conmutar las VM utilizando el gestor de

actualizaciones.

com.ibm.rcp.jvm.feature_2.0.0.0 includes

com.ibm.rcp.j2se.win32.x86.feature_1.5.0.SR2

com.ibm.rcp.jvm.feature_1.0.0.0 includes

com.ibm.rcp.jcl.desktop.win32.x86.feature_6.1.2.<fecha>

Las propiedades de VM están ubicadas en el archivo de plug-in de VM jvm.properties. El iniciador añade

estas propiedades dinámicamente al mandato de lanzamiento. Este método asegura que el plug-in de VM

defina las propiedades que necesita.

La propiedad –vm se puede utilizar en la línea de mandatos. Sin embargo, si necesita propiedades VM

adicionales, es responsable de añadirlas.



Configuración de la plataforma

Este apartado describe las tareas que puede realizar para configurar Lotus Expeditor Client en la

máquina del usuario.

Configuración de propiedades de sistema Java

Es posible que las aplicaciones necesiten que se establezcan propiedades de sistema específicas en el

arranque al ejecutar la plataforma de Lotus Expeditor Client.

Para minimizar el número de parámetros que debe especificar en la línea de mandatos, puede añadir

líneas de configuración al archivo rcpinstall.properties.

Consulte el apartado “Actualización del archivo rcpinstall.properties” en la página 101 para obtener

información detallada.

También puede especificar propiedades en la línea de mandatos cuando inicie la plataforma. Consulte el

apartado “Configuración del iniciador de la plataforma” en la página 48 para obtener más información.

Configuración de argumentos de VM

Es posible que las aplicaciones requieran que se añadan argumentos específicos para una VM (Virtual

Machine - Máquina virtual) que implemente las especificaciones de Java cuando se inicie la plataforma.

Para minimizar el número de parámetros que debe especificar en la línea de mandatos, puede añadir

líneas de configuración vmarg.* al archivo rcpinstall.properties, que reside en el directorio .config del

espacio de trabajo. (Consulte “Alteración temporal de la ubicación del directorio de espacio de trabajo”

en la página 23 para obtener más información.).



También puede especificar argumentos de VM en la línea de mandatos cuando inicie la plataforma.

Consulte el apartado “Configuración del iniciador de la plataforma” en la página 48 para obtener más

información.

Configuración de referencias de bibliotecas nativas

Cuando se utiliza Lotus Expeditor Client en el escritorio, es recomendable que todos los objetos de

bibliotecas nativas se incluyan en fragmentos específicos del sistema operativo/procesador.

Por lo general, basta con permitir que el código de la aplicación y el sistema operativo localicen la

biblioteca deseada. No obstante, puede ocurrir que en algunos casos no sea posible organizar las

bibliotecas en un fragmento, o que los requisitos de carga de bibliotecas impidan esta organización. Por

consiguiente, la vía de acceso de búsqueda de bibliotecas debe actualizarse.

Deberá actualizar las líneas library.path.append o library.path.prepend del archivo

rcpinstall.properties para especificar las ubicaciones de directorio que contienen las bibliotecas.




Configuración de bibliotecas bootclasspath de Java

Cuando se utiliza Lotus Expeditor Client en el escritorio, es recomendable que todas las bibliotecas de

clases necesarias para las aplicaciones residan el plug-ins o fragmentos.

Si hay casos en los que las bibliotecas se deban poner en bootclasspath de Java, necesitará actualizar la

línea o las líneas –Xbootclasspath.append o Xbootclasspath.prepend del archivo rcpinstall.properties.

Consulte “Actualización del archivo rcpinstall.properties” en la página 101 para obtener más información.

Configuración del iniciador de la plataforma

Puede configurar argumentos adicionales para utilizarlos cuando el usuario lance Lotus Expeditor Client.

Por ejemplo, puede especificar que se visualice una consola al lanzar el cliente.

Las opciones que es posible que desee configurar, son las siguientes:

–application

Altera temporalmente la propiedad de aplicación en el archivo rcpinstall.properties.

–config

Le permite especificar opciones de mandato en el archivo rcplauncher.properties para evitar

restricciones del sistema operativo en la longitud de los mandatos. Consulte el apartado

“Actualización del archivo rcplauncher.properties” en la página 97 para obtener más información.

La salida de iniciador se graba en un archivo llamado rcplauncher.log del directorio de registros. Para

un lanzamiento normal, este archivo no contiene ninguna salida. Contiene información si utiliza la

opción –debug o si al lanzar la plataforma se produce un error muy grave en el iniciador. En el caso

de producirse un error muy grave antes de la creación del registro, la salida se graba en

/tmp/rcplauncher.log en Linux y en %TEMP%/rcplauncher.log en Windows.

Se pasan argumentos basados en VM, Eclipse u OSGi, excepto los siguientes:

v Si se especifica la opción –console o –consoleLog, launcher.exe convertirá el javaw.exe/expeditorw.exe especificado en el archivo rcpinstall.properties en java.exe/expeditor.exe.

v –configuration: Esta opción se ha eliminado. La ubicación de configuración siempre se calcula

como ubicación_espacio_trabajo/.config.

Para obtener una lista completa de las opciones de entorno de ejecución definidas por Eclipse,

consulte la publicación Platform Plug-in Developer’s Guide, que se instala con Rational Software

Development Platform, y http://help.eclipse.org/help32/index.jsp.

Para configurar el iniciador de la plataforma de modo que utilice opciones adicionales, debe añadir la

opción a la vía de acceso del ejecutable. Para añadir opciones al ejecutable, modifique el acceso

directo desde el icono de escritorio. Además, puede añadir opciones como propiedades en

rcplauncher.properties. Consulte “Actualización del archivo rcplauncher.properties” en la página 97

para obtener más información.

–console

Le permite visualizar la consola de OSGi. Para registrar el mayor volumen de información posible,

añada logredirector.level=INFO al archivo rcpinstall.properties. Estas dos opciones funcionan bien

conjuntamente cuando es preciso depurar problemas.

–data

Altera temporalmente la ubicación del espacio de trabajo (propiedad osgi.instance.area). El cálculo

predeterminado del espacio de trabajo lo especifica la propiedad rcp.data en rcplancher.properties. El

área de configuración se calcula basándose en este valor. Se ignorará una opción –configuration.


http://help.eclipse.org/help32/index.jsp

Nota: Si el espacio de trabajo predeterminado no está disponible o es inaccesible, especifique el

espacio de trabajo durante el arranque de IBM Lotus Expeditor utilizando el mandato

siguiente:

rcplauncher.exe -data espacio de trabajo

donde espacio de trabajo es la vía de acceso a la ubicación de espacio de trabajo deseada.

–debug

Hace que se registre, automáticamente, información de depuración adicional.

–dir

Altera temporalmente la dirección bidi. Los valores correctos son rtl y ltr.

Nota: La alteración temporal de los valores para especificar rtl no se soporta en Linux.

–nl

Altera temporalmente el entorno local que se utiliza. Se deben haber instalado las características de

entorno local apropiadas para proporcionar el contenido localizado. Para obtener más información,

consulte el apartado “Instalación de contenido de idiomas adicional” en la página 186.

Nota: La alteración temporal de los valores para especificar hebreo o árabe como entorno local no se

soporta en Linux.

–personality

Personaliza el aspecto en función de las aplicaciones deseadas. Se puede utilizar para alterar

temporalmente el valor especificado en rcpinstall.properties.

–product

Altera temporalmente la característica de producto especificada por otros medios.

–version

Imprime la versión de rcplauncher en el registro temporal y sale. Por ejemplo: rcplauncher.exe

–version

–vm

Altera temporalmente una máquina virtual (VM) externa. También debe pasar las opciones vmargs

que son necesarias para esta VM. La VM a la que apunta esta opción puede causar problemas cuando

se conmuta después de este hecho. IBM sólo soporta las VM empaquetadas con el producto.

–vmargs

Permite que se pasen vmargs adicionales a la VM que implementa las especificaciones Java. No se

realizan comprobaciones en los valores. No se trata de una alteración, sino estrictamente de una

adición a las opciones vmargs especificadas en el archivo rcpinstall.properties.

Dcommands

Consulte el javadoc com.ibm.rcp.core.daemon.package para obtener información sobre cómo utilizar el

daemon.

La clase com.ibm.rcp.core.daemon define una interfaz que debe ser implementada por un desarrollador

de aplicaciones que utilice la extensión com.ibm.rcp.core.daemon.command. Consulte la documentación

del esquema de punto de extensión en Desarrollo de aplicaciones para Lotus Expeditorpara obtener más

información.

Puede utilizar este punto de extensión cuando necesite reenviar un mandato a un plug-in desde un

mandato de escritorio. Para ello, siga estos pasos:

1. Añada el mandato como una opción al mandato de lanzamiento.

Configuración de la plataforma 49

2. Ejecute el mandato de lanzamiento. En lugar de lanzar la plataforma, el daemon reenvía el mandato

de lanzamiento completo a la plataforma.

3. Se llama al método RcpDCommand.execute() del plug-in que ha registrado la extensión.

4. Llame al método de ejecución para decodificar los argumentos de línea de mandatos y actuar en ellos

de algún modo.

Un plug-in que ha de recibir mandatos debe:

v Contener el punto de extensión com.ibm.rcp.core.daemon.command en el archivo plugin.xml. Puede

encontrar un ejemplo completo en la documentación del esquema de punto de extensión en Desarrollo

de aplicaciones para Lotus Expeditor.

v Implementar la interfaz com.ibm.rcp.core.daemon.RcpDCommand, que se define en la documentación

del esquema de punto de extensión en Desarrollo de aplicaciones para Lotus Expeditor.

Para activar el mandato, lance la plataforma con rcplauncher.exe -my.plugin#extId.my_command. Si la

plataforma está en ejecución, el mandato se reenvía al plug-in.

Si la plataforma no está en ejecución, el mandato se ignora y se inicia la plataforma. Si necesita cifrar la

secuencia de mandato enviada a la plataforma, debe añadir la propiedad siguiente al archivo

rcpinstall.properties:

-Ddaemonconnect.provider=

com.ibm.rcp.core.internal.connect.encrypt.EncryptedDaemonConnect

La hebra de daemon escucha los mandatos mientras la plataforma está en ejecución. Examina cada

parámetro para ver si hay patrones de ID de mandato registrados utilizando el punto de extensión.

Consulte el javadoc com.ibm.rcp.core.daemon.package para obtener más información.

La hebra de daemon reconoce el siguiente patrón para los ID de mandato:

-plugin-id#[id-extensión.]id-mandato

donde la necesidad del elemento opcional [id-extensión] depende de si el ID de extensión se ha

especificado en el manifiesto de plug-in cuando se registró el mandato.

Ejemplo: Registre el punto de extensión en plugin.xml:

<extension [id="foo"] point="com.ibm.rcp.core.daemon.command">

<command id="mycmd" class="org.example.MyCommandClass"/>

</extension>

donde el ID de extensión es opcional. Si se especifica el ID de extensión (″foo″), RcpD examina en los

parámetros recibidos las coincidencias del formato:

-my.plugin#foo.mycmd

Si no se ha especificado el ID de extensión en el manifiesto, RcpD buscará:

-my.plugin#mycmd

Puesto que la lista de parámetros entera se envía a cada mandato, es posible que cada mandato tenga

cualquier número de argumentos:

-my.plugin#mycmd arg1 arg2 arg3...

Ejemplo: También es posible registrar todas las notificaciones de línea de mandatos, independientemente

del contenido, como se indica a continuación:

<extension [id="foo"] point="com.ibm.rcp.core.daemon.command">

<command id="mycmd" class="org.example.MyCommandClass" matchAll="true"/>

</extension>


||

Si registra un manejador para recibir todos los mandatos, no deberá registrarlo para que reciba también

mandatos individuales.

Ejemplo: plugin.xml de la aplicación:

<plugin>

<extension

point="com.ibm.rcp.core.daemon.command">

<command

class="com.jdmiles.command.MyCommandClass"

id="my_command"

matchAll="true"/>

</extension>

</plugin>

Tareas relacionadas

“Actualización del archivo rcplauncher.properties” en la página 97Este apartado describe cómo puede actualizar uno o más elementos de la plataforma de Lotus

Expeditor Client de un usuario modificando el archivo rcplauncher.properties. Información relacionada

“Descripción de la estructura del archivo de cliente” en la página 5Cuando Lotus Expeditor Client se instala en una máquina, el instalador crea una estructura de

directorios en el directorio de instalación. En esta sección se describe la estructura del directorio de

instalación que se instala en la plataforma cliente.

“Especificación de la marca y del tema de la plataforma” en la página 127El entorno de trabajo de Lotus Expeditor Client utiliza los productos de Eclipse y los temas de Eclipse




Configuración de valores de despliegue

El sistema de suministro de la plataforma de cliente proporciona la instalación de características y la

gestión de ciclo de vida. El sistema de suministro amplía las posibilidades proporcionadas por el Gestor

de actualizaciones de Eclipse subyacente.

El Gestor de actualizaciones de Eclipse y el sistema de suministro proporcionan diversas preferencias

para controlar cómo operan estas funciones.

Cambio de preferencias de despliegue

Este apartado describe las preferencias de despliegue que se pueden cambiar.

El siguiente conjunto de preferencias está disponible y se gestiona utilizando las preferencias de Eclipse.

IBM Lotus Expeditor permite que el usuario establezca muchas de ellas utilizando la página

Instalar/actualizar preferencias. Puede establecer otras preferencias mediante actualizaciones manuales

del archivo plugin_customization.ini o mediante la gestión remota del nodo org.eclipse.update.core, el

nodo org.eclipse.update.schedulery el nodo com.ibm.rcp.provisioning. Consulte “Gestión de preferencias

de Eclipse” en la página 114 para obtener más información sobre la gestión remota de las preferencias de

Eclipse.

Preferencias para org.eclipse.update.core:

updatePolicyURL

Ubicación del archivo de política de actualización. Puede ser un archivo local o un archivo

accesible mediante un URL HTTP (o similar). El usuario puede establecer su preferencia en la

página Instalar/actualizar preferencia.

Valor predeterminado: No especificado


org.eclipse.update.core.historySize

Número de archivos de actualización de historial a mantener para la plataforma.

Valor predeterminado: 100

org.eclipse.update.core.checkSignature

Determina si se deben comprobar durante la instalación los objetos de característica firmados.

Valor predeterminado: true

org.eclipse.update.core.automaticallyChooseMirror

Comprueba automáticamente los duplicados durante la instalación de característica.

Valor predeterminado: false

org.eclipse.update.core.updateVersions

Selecciona las características que la exploración de actualizaciones seleccionará antes de la

visualización. Los valores disponibles son compatible, equivalent o major. El usuario puede

establecer su preferencia en la página Instalar/Actualizar preferencias.

Valor predeterminado: equivalent

Preferencias para org.eclipse.update.scheduler:

download

Busca actualizaciones y notifica cuándo están disponibles (false) o descargar automáticamente

actualizaciones nuevas y notificar cuando se está preparado para instalarlas (true). Se ignora a

menos que la preferencia habilitada se establezca en true. El usuario puede establecer su

preferencia en la página Instalar/Actualizar preferencias.


enabled

Determina si se deben buscar automáticamente las actualizaciones.


schedule

Determina cuándo se deben buscar actualizaciones nuevas. Las elecciones son buscar en el inicio

de plataforma (on-startup) o en una planificación (on-schedule). Se ignora a menos que la

preferencia habilitada se establezca en true. El usuario puede establecer su preferencia en la

página Instalar/Actualizar preferencias.

Valor predeterminado: on-startup

hour Hora del día a la que se deben buscar actualizaciones nuevas (hora especificada en HH:00 AM|PM).

Tenga en cuenta que este valor depende del entorno local, de forma que un valor para el inglés

de EE.UU. no se reconoce correctamente en otro entorno local. Los administradores que gestionan

plataformas en varios entornos locales necesitarán establecer un valor específico de entorno local.

El usuario puede establecer su preferencia en la página Instalar/Actualizar preferencias.

Valor predeterminado: 1:00 AM

day Día de la semana en el que se deben buscar actualizaciones nuevas. Los valores son Every day o

Every <nombredía>. Tenga en cuenta que este valor depende del entorno local, de forma que un

valor para el inglés de EE.UU. no se reconoce correctamente en otro entorno local. Los

administradores que gestionan plataformas en varios entornos locales necesitarán establecer un

valor específico de entorno local. El usuario puede establecer su preferencia en la página

Instalar/Actualizar preferencias.

Valor predeterminado: Every day


Preferencias para com.ibm.rcp.provisioning. (Estas preferencias no están disponibles a través de la

interfaz de usuario de preferencias. Consulte “Gestión de preferencias de Eclipse” en la página 114 para

obtener más información sobre cómo modificar estos valores.):

feature.history.size

Especifica el número de versiones antiguas de una característica que se deben conservar en el

sistema de archivos. Los valores predeterminados dependerán de la configuración de plataforma.

Si la configuración de plataforma (install.configuration) se establece en usuario, el valor

predeterminado es 0. Si la configuración de plataforma se establece en multiusuario, el valor

predeterminado es -1, indicando que se conservan todas las versiones de características. El valor

predeterminado utilizado en las configuraciones de dispositivos es 0.

Por ejemplo, si el valor se establece en 0, la instalación de una versión actualizada de una

característica hará que se elimine la versión anterior de la característica. Si el valor se establece en

1, cuando se instale una versión actualizada de una característica, se mantendrá una sola versión

anterior. Si en la plataforma había instalada más de una versión, se eliminarán las versiones más

antiguas. Sólo se eliminarán las versiones más antiguas que la característica habilitada

actualmente. No se eliminarán las versiones posteriores a la característica habilitada actualmente.

runDeferredActionsOnStartup

Especifica cuándo se deben ejecutar las acciones diferidas, por ejemplo la desinstalación de

versiones antiguas de las características. Cuando se establece en true, las acciones diferidas se

ejecutan inmediatamente al iniciar la plataforma y no se visualiza ningún indicador de progreso.

Cuando se establece en false, las acciones diferidas se ejecutan después de que el entorno de

trabajo haya completado el proceso de arranque y se visualiza un indicador de progreso. El valor

predeterminado es false.

updateSiteList

Lista de series que representan sitios de actualización separados por un carácter de barra vertical

(|). Por ejemplo:

file:/E:/updatesite|http://www.mycompany.com/myupdatesite|jar:file:/z:/someupdatesite.zip!/

Los sitios de esta lista están en orden de prioridad. Primero se busca en el primer sitio de la lista,

a continuación en el segundo sitio y así sucesivamente. Se utilizará una característica que se

encuentre en el primer sitio, incluso aunque la misma característica con una versión más alta

pueda estar disponible en el segundo o tercer sitio. El valor predeterminado para updateSiteList

es una lista vacía.

whiteList

Valor booleano que especifica cómo se utilizará updateSiteList.

Si se establece en true, se utilizará updateSiteList como una lista blanca de sitios de

actualización. Una lista en blanco restringe que las actualizaciones se recuperen sólo de los sitios

de la lista. Si esta preferencia se establece en false, se utiliza updateSiteList como el conjunto de

sitios predeterminados, pero las actualizaciones no están restringidas a los sitios de

updateSiteList. El valor predeterminado es false.

Si esta propiedad está establecida en true, la búsqueda en URL de política se desactivará

y se ignorarán la preferencia useList, el sitio de actualización de feature.xml y el sitio de

actualización de bookmarks.xml.

useFeatureURL

Valor booleano que especifica si se deben incluir los URL de sitio de actualización proporcionados

utilizando feature.xml, el manifiesto de suministro o la petición de API de suministro en la lista

de búsqueda.

Si se establece en true, se utilizan los URL de sitio de actualización disponibles. Si se establece

en false, se ignoran los URL de sitio de actualización. El valor predeterminado es true.


|||

Esta preferencia determina si debe buscarse en el sitio de actualización proporcionado por

feature.xml. Si se especifican, siempre se utilizan las peticiones de API de suministro y de

manifiesto. Si la preferencia whiteList está establecida en true, se hace caso omiso de este valor.

useList

Valor booleano que especifica si se utiliza la lista de los URL de sitio de actualización definidos

en updateSiteList.

Si está establecida en true, se utiliza updateSiteList. Si está establecida en false, se ignora la

lista de sitios. El valor predeterminado es false.

Si está establecida en true y la preferencia whiteList está establecida en false, se utiliza

updateSiteList. Si la preferencia whiteList está establecida en true, se hace caso omiso de este

valor.

Configuración de los valores de búsqueda de actualización

Este apartado describe cómo proporciona la plataforma de Expeditor la búsqueda automática de

actualizaciones.

La plataforma de Expeditor proporciona varios métodos para la búsqueda automática de actualizaciones:

v Desde el diálogo Archivo → Aplicación → Instalar

v Desde el diálogo Archivo → Aplicación → Gestión de aplicaciones (cuando se selecciona el producto

Lotus Expeditor)

v Desde una característica individual del diálogo Gestión de aplicaciones, si se ha configurado un sitio

de actualización para dicha característica en particular

v Habilitando las actualizaciones automáticas utilizando la página Instalar/Actualizar preferencia o

mediante el programa actualizando la preferencia de Eclipse aplicable

La jerarquía de búsqueda de las actualizaciones automáticas o de la exploración de actualizaciones es la

siguiente:

v URL de política de actualización

v Sitios de actualización especificados por características individuales

Para evitar que se produzcan actualizaciones basándose en los sitios de actualización en las características

individuales, la política de actualización debe contener siempre un patrón especificado como “*”. De lo

contrario, si se instala una característica que no coincide con ningún patrón de la política de

actualización, se utilizará el sitio de actualización individual especificado por dicha característica.

Las actualizaciones automáticas buscarán las actualizaciones de características de equivalent, compatible

o major, basándose en el valor de preferencias org.eclipse.update.core/org.eclipse.update.core.updateVersions.

Especificación de sitios de descubrimiento y marcadores para características

Los marcadores son sitios de actualización definidos en el archivo bookmarks.xml que residen en el

directorio de configuración. Las contribuciones en el archivo de marcadores se pueden proporcionar

mediante sitios de descubrimiento definidos en características individuales. No se utilizan marcadores

durante la búsqueda automática.

Habilitación e inhabilitación de la interfaz de usuario de actualización

El producto Expeditor proporciona acceso a la interfaz de usuario de gestor de actualizaciones para el

despliegue de características nuevas y la gestión de la configuración actual.


|||

|||

Además, se proporcionan páginas de preferencias para habilitar la configuración del comportamiento del

sistema de suministro, por ejemplo la política de actualización de plataforma o la planificación de

actualizaciones automáticas. Si se desea, puede ocultar las acciones de menú y las páginas de preferencias

utilizando el soporte de actividad del entorno de trabajo.

Defina la siguiente extensión en el punto de extensión org.eclipse.ui.activities para definir una actividad

que incluya las acciones de menú y las páginas de preferencias. Esta definición de extensión se puede

incluir en cualquier plugin.xml (o fragment.xml) de cualquier plug-in (o fragmento) desplegado en la

plataforma de cliente.

<plugin>

<extension

point="org.eclipse.ui.activities">

<activity

id="UIEnabler.installupdatemenu"

name="Menú Instalar actualización"/>

<activityPatternBinding

activityId="UIEnabler.installupdatemenu"

pattern="com\.ibm\.eswe\.installupdate\.launcher/management"/>



pattern="com\.ibm\.eswe\.installupdate\.launcher/install"/>



pattern="org\.eclipse\.update\.ui/org\.eclipse\.update\.internal\.ui\.preferences\.MainPreferencePage"/>



pattern="org\.eclipse\.update\.scheduler/org\.eclipse\.update\.scheduler\.AutomaticUpdatesPreferencePage"/>

</extension>

</plugin>

Una vez que se ha definido la actividad, puede habilitar o inhabilitar la actividad para visualizar u

ocultar las acciones y las páginas de preferencias. Este ejemplo incluye las acciones de menú y las páginas

de preferencias en la misma actividad, pero la actividad se puede definir para que sólo incluya las

posibilidades que se desea controlar, por ejemplo sólo las acciones de menú. Una vez definida la

actividad, puede habilitar o inhabilitar la actividad como sea necesario.

Configuración del orden de búsqueda de características

Conozca un conjunto ampliado de posibilidades para gestionar y controlar el orden de búsqueda al

localizar características nuevas o actualizadas que se deben instalar.

Los desplegadores hacen frente a los dos retos siguientes al gestionar el conjunto de características

instaladas en cualquier sistema en particular:

v Restringir los lugares a los que puede ir un usuario para obtener características nuevas o actualizadas.

Si se permite a un usuario ir a cualquier sitio de actualización arbitraria para descargar características

nuevas o actualizadas, existe un riesgo de seguridad: la integridad de la plataforma de cliente puede

quedar comprometida debido a características dañinas.

v Mantener el conjunto de actualizaciones listadas en las características o las que se hace referencia en la

XML de la CA puede tomar un tiempo considerable. Si los sitios de actualización listados en las

características o en la XML de la CA fueran el único medio de localizar las actualizaciones, sería

problemático mantener o corregir esta información frente a problemas tales como cambios de topología

de red, redenominación de servidor, referencias de terceros o sitios inaccesibles desde sistemas de

sobremesa del usuario.

La plataforma de cliente proporciona un conjunto ampliado de posibilidades para gestionar y controlar el

orden de búsqueda al localizar características nuevas o actualizadas que se deben instalar. Además, la


plataforma proporciona ahora el concepto de lista blanca: conjunto restringido de sitios en los que

obtener características nuevas o actualizadas. Las preferencias siguientes se utilizan juntas para

proporcionar el control flexible sobre los sitios de actualización de los que se obtienen las características

nuevas:

v com.ibm.rcp.provisioning/updateSiteList

v com.ibm.rcp.provisioning/useList

v com.ibm.rcp.provisioning/useFeatureURL

v com.ibm.rcp.provisioning/whiteList

Tabla 2. Valores gestionados de la Lista blanca y los resultados esperados para 6.1.1

useFeatureURL useList UpdateSiteList whiteList Resultado deseado

True True Puede estar vacía,

lo que hará que

falle el suministro.

True Utilice información de sitio de

actualización de características explícita,

si existe. Si existe, el sitio de

actualización debe estar en

UpdateSiteList. De lo contrario, falla el

suministro. Si no existe, busque en los

sitios de UpdateSiteList. Si

UpdateSiteList está vacía, falla el

suministro.

True True Puede estar vacía,

lo que hará que


False Utilice información de sitio de


si existe. Si no existe, busque en los

sitios de UpdateSiteList. Si

UpdateSiteList está vacía, falla el

suministro.

True False Puede estar vacía,

lo que hará que


True Utilice información de sitio de


si existe. Si existe, el sitio de

actualización debe estar en

UpdateSiteList. De lo contrario, falla el

suministro.

True False Puede estar vacía

pero no puede

hacer que falle el

suministro.

False Utilice información de sitio de


si existe. Si no se proporciona

información de sitio de actualización de

características explícita (por ejemplo en

la petición de suministro o utilizando la

GUI de actualización), falla el

suministro.

False True No debe estar

vacía.

True Ignore cualquier información de URL de

sitio de actualización de características

explícita. Busque sólo en los sitios de

actualización de UpdateSiteList.

False True No debe estar

vacía.

False Ignore cualquier información de URL de

sitio de actualización de características

explícita. Busque sólo en los sitios de

actualización de UpdateSiteList.

False False Irrelevante True Combinación inválida

False False Irrelevante False Combinación inválida

La configuración predeterminada de la plataforma permite instalar actualizaciones desde cualquier sitio

de actualización especificado en la petición de suministro o utilizando la API de suministro:

[useFeatureURL = true, whiteList = false, useList = false, updateSiteList = <lista vacía>].


Mientras que esta configuración proporciona la mayor flexibilidad, también proporciona el menor control

sobre el lugar del que se obtienen las características nuevas. Además, esta configuración depende de los

usuarios de la plataforma y del contenido de las características distribuidas para localizar características

nuevas y actualizadas.

Para ayudar a controlar el número de sitios de los que se pueden obtener las características, se puede

definir updateSiteList con un conjunto de sitios de actualización. En esta configuración [useFeatureURL

= true, whiteList = false, useList = true, updateSiteList = <listanovacía>], además de los sitios

definidos por las características, las actualizaciones y las características nuevas también se pueden

encontrar en el conjunto de sitios de actualización especificados por updateSiteList. Los sitios de

actualización especificados por las características tendrán prioridad sobre los sitios de actualización

especificados por updateSiteList.

Un tercer valor de la configuración es muy similar a la utilización de la política de actualización

especificada por la preferencia org.eclipse.update.core/updatePolicyURL. En esta configuración

[useFeatureURL = false, whiteList = false, useList = true, updateSiteList = <listanovacía>], sólo

se buscarán características en los sitios de actualización especificados en la lista de sitios de actualización.

Puesto que la política de actualización dirige identificadores de características específicos a sitios de

actualización específicos, esto permite especificar los sitios de actualización en una lista sin necesidad de

obtener las características de ninguno de ellos. Tenga en cuenta que en esta configuración, si

updateSiteList está vacía, no se podrán localizar características y las solicitudes de instalación de

características fallarán.

En la versión 6.1.1, para proporcionar el máximo control sobre el lugar desde el que se pueden instalar

características nuevas y actualizadas, la configuración [whiteList = true, updateSiteList

=<listanovacía>, useList = true, useFeatureURL = true o false ] restringirá que las actualizaciones

sólo procedan del conjunto de sitios de actualización especificados en updateSiteList. Si useFeatureURL

es true (verdadero), los URL de característica tendrán prioridad sobre la lista de sitios de updateSiteList,

pero los sitios de actualización especificados por las características se deben especificar en

updateSiteList. Tenga en cuenta que en esta configuración, si updateSiteList está vacía, no se podrán

localizar características y las solicitudes de instalación de características fallarán.

Tenga en cuenta que dado que hay tres variables booleanas, las combinaciones distintas de las indicadas

más arriba son posibles, pero producirán una configuración en la que las solicitudes de suministro no se

podrán realizar nunca satisfactoriamente.

En la versión 6.1.1, en todas estas configuraciones, también se puede utilizar la política de actualización

(especificada por org.eclipse.update.core/updatePolicyURL). Si se especifica la política de actualización,

cualquier recorrelación de sitios de actualización de características se producirá antes de aplicar las

preferencias como se define más arriba. Por ejemplo, si una característica com.ibm.sample.feature

contiene un URL que hace referencia al sitio http://www.ibm.com y la política de actualización contiene

una correlación de ″com.ibm.sample″ con http://w3.mycompany.com, la búsqueda de características se

dirigirá a http://w3.mycompany.com. Si se utiliza una configuración restrictiva [whiteList = true,

useList = true], updateSiteList también deberá contener http://w3.mycompany.com.

Al buscar en los sitios de actualización, las búsquedas se producirán en orden secuencial, basándose en la

configuración. Si useFeatureUrl = true, el sitio de actualización asociado con la característica (si existe)

será la primera ubicación de búsqueda (sujeto a los demás valores de configuración). Si se encuentra la

característica en este sitio y ésta satisface las normas de coincidencia de la solicitud, se utilizará esta

característica, independientemente de las características que puedan estar contenidas en otros sitios. Si no

se encuentra la característica en este sitio, la búsqueda continuará bajando por la lista de sitios

especificados en updateSiteList (suponiendo que useList = true). La búsqueda se realizará en los sitios

de updateSiteList en el orden especificado hasta que se encuentre una coincidencia.

Por razones de rendimiento, se recomienda que updateSiteList, si se utiliza, se gestione cuidadosamente

para asegurarse de que los sitios de actualización contienen las características necesarias y están


organizados en el mejor orden de ejecución. Los sitios que no responden pueden incrementar de forma

significativa el tiempo necesario para completar la solicitud de suministro.

Para eliminar la confusión respecto a qué característica se encontrará durante las búsquedas, se

recomienda que los sitios de actualización contengan diferentes conjuntos de características o que se

mantengan las mismas versiones de todas las características en todos los sitios.

Dado que la interfaz de usuario del gestor de configuración no busca en updateSiteList antes de

visualizar características, es posible que las características se listen sin actualizaciones disponibles cuando

hay características actualizadas en updateSiteList que están disponibles para instalarse.

Además, si whiteList se establece en true (verdadero) y los URL de todas las característica no están

incluidos en updateSiteList, el gestor de actualizaciones permitirá seleccionar características que no se

permite instalar. IBM Lotus Expeditor procesará la solicitud de característica del gestor de actualizaciones

y la rechazará puesto que el URL para la característica solicitada no está incluido en updateSiteList. Esto

puede producir confusión puesto que la característica se muestra en el gestor de actualizaciones como

accesible pero no se puede instalar.

Configuración del orden de búsqueda de características en 6.1.2

Lotus Expeditor proporciona un conjunto ampliado de posibilidades para gestionar y controlar el orden

de búsqueda al localizar características nuevas o actualizadas que se deben instalar.

Los desplegadores hacen frente a los tres retos siguientes al gestionar el conjunto de características

instaladas en cualquier sistema en particular:

v Restringir los lugares a los que puede ir un usuario para obtener características nuevas o actualizadas.

Si se permite a un usuario ir a cualquier sitio de actualización arbitraria para descargar características

nuevas o actualizadas, existe un riesgo de seguridad: la integridad de la plataforma de cliente puede

quedar comprometida debido a características dañinas.

v Mantener la validez del conjunto de características instaladas. Problemas como cambios en la topología

de red, servidores renombrados, referencias a terceros y sitios inaccesibles desde los sistemas de

sobremesa del usuario hacen que este punto sea especialmente conflictivo. El mantenimiento mediante

la actualización de archivos XML CA puede ser difícil y requerir mucho tiempo.

v Asegurar que las características se actualizan desde la ubicación correcta. Es posible que los usuarios

observen que tienen acceso a diversas versiones de las mismas características en distintos sitios y no

sepan qué sitio es el que deben utilizar. Los desarrolladores deben especificar el orden que utiliza

Expeditor para buscar las actualizaciones de las características instaladas.

La plataforma de cliente proporciona un conjunto ampliado de posibilidades para gestionar y controlar el

orden de búsqueda al localizar características nuevas o actualizadas que se deben instalar. Además, la

plataforma proporciona ahora el concepto de Lista blanca: un conjunto restringido de sitios de los que

obtener características nuevas o actualizadas. Las preferencias siguientes se utilizan juntas para

proporcionar un control flexible sobre los sitios de actualización de los que se obtienen las características

nuevas. Consulte las descripciones de estas preferencias en “Cambio de preferencias de despliegue” en la

página 51.

v com.ibm.rcp.provisioning/updateSiteList

v com.ibm.rcp.provisioning/useList

v com.ibm.rcp.provisioning/useFeatureURL

v com.ibm.rcp.provisioning/whiteList

v org.eclipse.update.core/updatePolicyURL

La combinación de estas 5 preferencias determina el orden y la ubicación de búsqueda en la instalación

de las actualizaciones de características. La tabla siguiente describe la influencia que tienen los valores en

el orden de búsqueda.


|

||

||

||||

||||

||||

|||||||

|

|

|

|

|

|||

Tabla 3. Valores gestionados de la lista blanca y los resultados esperados para 6.1.2

useFeatureURL useList UpdateSiteList whiteList

URL de

política Resultado deseado

True/False True/False Si está vacío, no

se encontrará

ninguna

característica.

True Especificado/

No

especificado

Buscar primero en el URL de

característica de manifiesto si está

en updateSiteList. A continuación,

buscar en los sitios en

updateSiteList. Si la petición de

búsqueda contiene un URL de

política, whiteList borrará este

valor para asegurar la

conformidad. Crear un mensaje que

indique que se ha eliminado el

URL de política. Se hará caso omiso

de los sitios en el URL de

característica y bookmarks.xml. Si

UpdateSiteList está vacía, no se

encontrará ninguna característica.

True True Puede estar

vacío porque

también se

utiliza el URL

de característica

y

bookmarks.xml

para buscar

características.

False No

especificado


característica de manifiesto. A

continuación, buscar en los sitios

en updateSiteList. Si updateSiteList

está agotado o vacío, buscar en el

sitio de URL de característica. Si la

petición procede de la acción

″Buscar nuevas características a

instalar″ de la interfaz de usuario

de actualizaciones, buscar en los

sitios en bookmarks.xml.

True False Irrelevante False No

especificado


característica de manifiesto. A

continuación, utilizar el URL de

característica para la búsqueda. Si

la petición procede de la interfaz

de usuario de actualizaciones,

buscar en los sitios en

bookmarks.xml.

True False Puede estar

vacío porque

también se

utiliza el URL

de característica

y

bookmarks.xml

para buscar

características.

False Especificado Buscar características utilizando el

URL de política si se especifica en

la petición de búsqueda. A

continuación, buscar en el URL de

característica de manifiesto. Si no

se encuentra, buscar en

updateSiteList. Después, buscar en

el sitio de URL de característica. Si

la petición procede de la acción






||

|||||||

||||||

||||

|||||||||||||||

|||||||||||

||||||||||||||

||||||||||||||

|||||||||||

|||||||||||||||

Tabla 3. Valores gestionados de la lista blanca y los resultados esperados para 6.1.2 (continuación)

useFeatureURL useList UpdateSiteList whiteList

URL de

política Resultado deseado

True False Irrelevante False Especificado Buscar características utilizando el




característica de manifiesto. Si no

se encuentra, buscar en el sitio de

URL de característica. Si la petición

procede de la acción ″Buscar

nuevas características a instalar″ de

la interfaz de usuario de

actualizaciones, buscar en los sitios

en bookmarks.xml.

False True Podría estar

vacío porque

también se

utiliza

bookmarks.xml

para buscar

características.

False No

especificado


característica de manifiesto. Utilizar

updateSiteList para buscar

características. Si la petición

procede de la interfaz de usuario



False False Irrelevante False No

especificado


característica de manifiesto. Si la

petición procede de la acción



de actualizaciones, utilizar

bookmarks.xml sólo para buscar

características.

False True Podría estar

vacío porque

también se

utiliza el URL

de política y

bookmarks.xml

para buscar

características.

False Especificado Buscar características utilizando el




característica de manifiesto.

Después, buscar en updateSiteList.

Si la petición procede de la acción





False False Irrelevante False Especificado Buscar características utilizando el


la petición de búsqueda. Buscar

primero en el URL de característica

de manifiesto. Si la petición

procede de la acción ″Buscar

nuevas características a instalar″ de

la interfaz de usuario de

actualizaciones, buscar en los sitios

en bookmarks.xml.

La configuración predeterminada de la plataforma permite instalar actualizaciones desde cualquier sitio

de actualización especificado en la petición de suministro o utilizando la API de suministro:

[useFeatureURL = true, whiteList = false, useList = false, updateSiteList = <lista vacía>].

Mientras que esta configuración proporciona la mayor flexibilidad, también proporciona el menor control


|

|||||||

|||||||||||||||||

|||||||||

||||||||||

||||||||||||||

||||||||||

|||||||||||||

||||||||||||||||

||||

sobre el lugar del que se obtienen las características nuevas. Además, esta configuración depende de los

usuarios de la plataforma y del contenido de las características distribuidas para localizar características

nuevas y actualizadas.

Para ayudar a controlar el número de sitios de los que se pueden obtener las características, se puede

definir updateSiteList con un conjunto de sitios de actualización. En esta configuración [useFeatureURL

= true, whiteList = false, useList = true, updateSiteList = <listanovacía>], además de los sitios

definidos por las características, las actualizaciones y las características nuevas también se pueden

encontrar en el conjunto de sitios de actualización especificados por updateSiteList. Los sitios de

actualización especificados por las características tendrán prioridad sobre los sitios de actualización

especificados por updateSiteList.

Un tercer valor de la configuración es muy similar a la utilización de la política de actualización

especificada por la preferencia org.eclipse.update.core/updatePolicyURL. En esta configuración

[useFeatureURL = false, whiteList = false, useList = true, updateSiteList = <listanovacía>], sólo

se buscarán características en los sitios de actualización especificados en la lista de sitios de actualización.

Puesto que la política de actualización dirige identificadores de características específicos a sitios de

actualización específicos, esto permite especificar los sitios de actualización en una lista sin necesidad de

obtener las características de ninguno de ellos. Tenga en cuenta que en esta configuración, si



Para proporcionar el máximo control sobre el lugar desde el que se pueden instalar características nuevas

y actualizadas, la configuración [whiteList = true, updateSiteList =<listanovacía>, useList = true o

false, useFeatureURL = true o false ] restringirá que las actualizaciones sólo procedan del conjunto de

sitios de actualización especificados en updateSiteList. Tenga en cuenta que en esta configuración, si



Tenga en cuenta que dado que hay tres variables booleanas, las combinaciones distintas de las indicadas

más arriba son posibles, pero producirán una configuración en la que las solicitudes de suministro no se

podrán realizar nunca satisfactoriamente.

En la versión 6.1.2, en todas las configuraciones excepto whiteList=true, también se puede utilizar la

política de actualización (especificada por org.eclipse.update.core/updatePolicyURL). Si se especifica la

política de actualización, cualquier recorrelación de sitios de actualización de características se producirá

antes de aplicar las preferencias como se define más arriba. Por ejemplo, si una característica

com.ibm.sample.feature contiene un URL que hace referencia al sitio http://www.ibm.com y la política

de actualización contiene una correlación de ″com.ibm.sample″ con http://w3.mycompany.com, la

búsqueda de características se dirigirá a http://w3.mycompany.com.

Actualice el comportamiento del gestor cuando la preferencia useList o whiteList es ″true″:

Cuando la preferencia useList o whiteList es ″true,″ el Gestor de actualizaciones añadirá

automáticamente los sitios especificados en la preferencia updateSiteList a la lista de sitios en los que

buscar. Estos sitios pueden identificarse en el Gestor de actualizaciones con el ″signo menos″ que precede

a la entrada del sitio de actualización. Estos sitios no se pueden modificar ni eliminar, pero sí pueden

inhabilitarse para la búsqueda deseleccionando el sitio. Cuando la preferencia whiteList es ″true″, los

sitios updateSiteList son los únicos sitios que están disponibles para el usuario y no se mostrará ningún

sitio de marcador.

Al buscar en los sitios de actualización, las búsquedas se producirán en un orden específico. Si se

encuentra la característica en un sitio y ésta satisface las normas de coincidencia de la solicitud, se

utilizará esta característica, independientemente de las características que puedan contener otros sitios.

El orden de precedencia de la búsqueda es:


|||

|||||||

|||||||||

||||||

|||

|||||||

|

|||||||

|||

|

v Sitios correlacionados de URL de política (sólo si la petición de búsqueda lo ha especificado y la

preferencia whiteList es ″false″)

v URL de característica de la petición de manifiesto (sólo si el manifiesto tiene un conjunto de URL)

v Sitios de updateSiteList en orden (sólo si la preferencia useList o whiteList es ″true″)

v Sitio de URL de característica, de feature.xml (sólo si la preferencia useFeatureURL es ″true″ y la

preferencia whiteList es ″false″)

v Sitios de marcador sin ningún orden (sólo si procede de la acción ″Buscar nuevas características a

instalar″ de la interfaz de usuario de actualizaciones y si la preferencia whiteList es ″false″)

Por razones de rendimiento, se recomienda que updateSiteList, si se utiliza, se gestione cuidadosamente

para asegurarse de que los sitios de actualización contienen las características necesarias y están

organizados en el mejor orden de ejecución. Los sitios que no responden pueden incrementar de forma

significativa el tiempo necesario para completar la solicitud de suministro.

Para eliminar la confusión respecto a qué característica se encontrará durante las búsquedas, se

recomienda que los sitios de actualización contengan diferentes conjuntos de características o que se

mantengan las mismas versiones de todas las características en todos los sitios.

Configuración de la verificación de plug-in firmado

En este apartado se describen los valores de la política de los plug-in firmados que el sistema de

suministro de Lotus Expeditor Client utiliza para controlar el acceso a los sitios de actualización locales y

remotos de Eclipse. Los usuarios finales acceden a los sitios de actualización para actualizar las ofertas de

base y las aplicaciones de plug-in personalizadas.

Dado que el sistema de suministro puede acceder al código desde un sitio de actualización local o remoto

de Eclipse, la firma de los archivos jar mostrados en el sitio de actualización y la verificación de los

mismos en el cliente en el momento de la bajada permiten al usuario final obtener información fiable

sobre el código que está a punto de descargar. Este componente le permite identificar quién ha publicado

el código y verificar que el software no se haya modificado ni manipulado indebidamente desde su

colocación en el sitio de actualización.

Las decisiones tomadas por el subsistema de suministro al instalar los jars de un sitio de actualización las

realiza un motor de política que utiliza valores de política definidos como preferencias de Eclipse para

tomar decisiones fiables. El motor de política que toma las decisiones de fiabilidad está controlado por un

conjunto de preferencias de Eclipse.

Por omisión, el soporte para verificar los plug-ins firmados está desactivado. Para configurar la

verificación de plug-in firmado, modifique las siguientes preferencias de Eclipse. Consulte “Gestión de

preferencias de Eclipse” en la página 114 para obtener información sobre el establecimiento de

preferencias.

Tabla 4. Preferencias de plug-ins firmadas

Preferencia de Eclipse Valores posibles

com.ibm.rcp.security.update/VERIFICATION_LISTENER Clase que implementa la interfaz IVerificationListener

com.ibm.rcp.security.update/EXPIRED_SIGNATURE_POLICY PROMPT/ALLOW/DENY

com.ibm.rcp.security.update/UNSIGNED_PLUGIN_POLICY PROMPT/ALLOW/DENY

com.ibm.rcp.security.update/UNTRUSTED_SIGNATURE_POLICY

PROMPT/ALLOW/DENY

VERIFICATION_LISTENER

Este valor de preferencia indica qué implementación IVerificationListener de Eclipse utilizará el


||

|

|

||

||

||||

|||

sistema de suministro al verificar los archivos jar que se están suministrando de un sitio de

actualización de Eclipse. Este subcomponente proporciona las dos implementaciones siguientes de

la interfaz IVerificationListener:

com.ibm.rcp.security.update.DefaultVerificationListener

Establezca este valor para habilitar este subcomponente cuando se realiza el suministro

lanzando la plataforma en modalidad sin interfaz de usuario. Ésta se puede habilitar en

el momento de la instalación añadiendo esta preferencia al archivo

plugin_customization.ini del directorio de despliegue del kit de soporte.

com.ibm.rcp.security.update.ui.PromptVerificationListener

Establezca esta clase para implementar la interfaz de usuario que se debe mostrar al

usuario final. Las ofertas deben establecer este valor en el momento en que se lanza la

plataforma en modalidad con interfaz de usuario y se espera que el usuario final tome las

decisiones fiables para el código no fiable que el sistema de suministro está descargando.

EXPIRED_SIGNATURE_POLICY

Este valor de preferencia define el comportamiento predeterminado para una implementación de

IVerificationListener determinada cuando encuentra un archivo jar, que está firmado, pero el

certificado utilizado para firmar el archivo jar ha caducado.

UNSIGNED_PLUGIN_POLICY

Este valor de preferencia define el comportamiento predeterminado para una implementación de

IVerificationListener determinada cuando encuentra un archivo jar que no está firmado.

UNTRUSTED_SIGNATURE_POLICY

Este valor define el comportamiento predeterminado para una implementación de

IVerificationListener determinada cuando encuentra un archivo jar que no es fiable.

Si se establecen los valores de política anteriores en ALLOW o DENY, la implementación de

IVerificationListiner interpretará que se debe permitir o rechazar el suministro de características. Sin

embargo, el valor de política de PROMPT lo interpretará una implementación de IVerificationListener

basándose en que la plataforma se ejecute en modalidad sin interfaz de usuario. Por ejemplo,

PromptVerificationListener solicitará a los usuarios que tomen las decisiones fiables necesarias mientras

DefaultVerificationListener trata PROMPT como DENY para que nunca se suministre código no fiable.

Para obtener información adicional acerca de IVerificationListeners y otras API públicas relacionadas con

plug-ins firmados, consulte el javadoc de Eclipse para el paquete org.eclipse.update.core.

Los plug-ins se pueden firmar utilizando herramientas de Eclipse o la herramienta de claves java.

Precarga de certificados para la instalación inicial y suministro de

plug-ins firmados

Cuando se instala un plug-in firmado, éste se verifica utilizando certificados del almacén de claves del kit

de soporte y del almacén de claves de IBM. El almacén de claves de IBM contiene certificados de IBM

públicos que se utilizan para verificar plug-ins firmados de IBM. El almacén de claves del kit de soporte

contiene certificados públicos que se utilizan para verificar plug-ins de otros fabricantes.

Si otro fabricante desea proporcionar certificados públicos (incluyendo certificados autofirmados) que se

utilizarán para verificar plug-ins durante la instalación, utilice el siguiente procedimiento:

1. Cree el siguiente archivo de almacén de claves sin ninguna contraseña (utilizando el programa de

utilidad keytool, o ikeyman si está disponible). Nota: Utilice el programa de utilidad keytool (o

ikeyman si está disponible) que se incluye con la JVM de la instalación de destino. Esto también se

puede realizar mediante programación con la VM de instalación de destino.

Utilice el nombre de archivo siguiente para la VM de instalación de destino específica:

VM EE de escritorio (valor predeterminado):

.keystore.jks.J9.install


VM J2SE:

.keystore.JCEKS.IBM_J9_VM.install

JVM de Macintosh:

.keystore.JCEKS.Java_HotSpot(TM)_Client_VM.install

2. Utilice keytool (o ikeyman si está disponible) para añadir certificados al almacén de claves recién

creado.

3. Coloque el archivo de almacén de claves en el directorio desktop\install\deploy de la instalación de

Expeditor.

Nota: Si da soporte a más de una VM de instalación de destino, repita los pasos 1 a 3 utilizando un

programa de utilidad keytool de VM (o ikeyman) distinto y un nombre de archivo de almacén de

claves diferente. El directorio deploy puede dar soporte a varios almacenes de claves.

Configuración del contenedor Web

El contenedor Web proporciona un entorno de ejecución para las aplicaciones Web en el que dichas

aplicaciones se pueden ejecutar conectadas y desconectadas.

Configuración de las propiedades de contenedor web

La configuración predeterminada para el contenedor web sólo escucha solicitudes HTTP recibidas en

localhost en un puerto que se selecciona de forma dinámica durante el inicio de la plataforma. Si

necesita realizar cambios en la configuración, consulte el contenido de esta sección.

A continuación se indican las propiedades disponibles para configurar el contenedor web.

Tabla 5. Propiedades de sistema Java

Opción

Valor

predeterminado Descripción Propiedad del sistema Java

Clave de Administración de

configuración (esta columna

sólo se aplica a Expeditor

6.1.1)

Puerto HTTP 0 Define el puerto que utiliza el escucha

de HTTP Service para escuchar

solicitudes. Un valor 0 indica que se

seleccionará un puerto aleatoriamente

cuando se inicie la plataforma. Un

valor -1 indica que no se iniciará

ningún escucha para las solicitudes

HTTP. Ahora esta propiedad soporta

una lista de valores. La propiedad en

desuso no soporta una lista de valores.

com.ibm.pvc.webcontainer.port o

com.ibm.osg.webcontainer.port (en desuso)

http.port

Puerto

HTTPS

-1 Define el puerto que utiliza el escucha

de HTTPS Service para escuchar

solicitudes. Un valor 0 indica que se

seleccionará un puerto aleatoriamente

cuando se inicie la plataforma. Un

valor -1 indica que no se iniciará

ningún escucha para las solicitudes

HTTP. Ahora esta propiedad soporta

una lista de valores. La propiedad en

desuso no soporta una lista de valores.

com.ibm.pvc.webcontainer.port.secure o

com.ibm.osg.webcontainer.port.secure (en desuso)

https.port

Tiempo de

espera HTTP

60 seg Define el valor que se utiliza para los

tiempos de espera del socket.

com.ibm.pvc.webcontainer.http.timeout o

com.ibm.osg.webcontainer.http.timeout (en desuso)

http.timeout

Dirección

HTTP

localhost Define la dirección del host para los

puertos predeterminados en los que

escucha el contenedor web. Si esta

propiedad está definida, el contenedor

web sólo escuchará las solicitudes que

llegan a través de esta dirección IP. El

valor especial ALL indica que se

utilizarán todas las direcciones IP

disponibles en el dispositivo. El valor

de esta propiedad puede ser un

nombre resuelto o una dirección IP

(por ejemplo, www.ibm.com,

192.168.0.101, localhost).

com.ibm.pvc.webcontainer.http.address o

com.ibm.osg.webcontainer.http.address (en desuso)

http.address


Tabla 5. Propiedades de sistema Java (continuación)

Opción

Valor





6.1.1)

Número

mínimo de

hebras HTTP

4 Define el número mínimo de hebras

que deben iniciarse para escuchar

solicitudes. Los valores válidos están en

el rango de 0 a 63.

com.ibm.pvc.webcontainer.http.minThreads http.minThreads

Número

máximo de

hebras HTTP

20 Define el número máximo de hebras

que deben iniciarse para escuchar

solicitudes. Los valores válidos están en

el rango de 2 a 63.

com.ibm.pvc.webcontainer.http.maxThreads http.maxThreads

Número

máximo de

conexiones

Keep Alive

20 Utilice esta propiedad para especificar

el número máximo de conexiones

(persistentes) Keep Alive simultáneas

en todos los transportes HTTP.

com.ibm.pvc.webcontainer.http.maxKeepAliveConnections http.maxKeepAliveConnections

Número

máximo de

solicitudes

Keep Alive

50 Utilice esta propiedad para especificar

el número máximo de solicitudes que

pueden procesarse en una única

conexión Keep Alive.

com.ibm.pvc.webcontainer.http.maxKeepAliveRequests http.maxKeepAliveRequests

Tiempo de

espera de

Keep Alive

20 seg Utilice esta propiedad para especificar

el número máximo de segundos

durante los que se debe esperar a la

siguiente solicitud en una conexión

Keep Alive.

com.ibm.pvc.webcontainer.http.keepAliveTimout http.keepAliveTimeout

Archivo de

configuración

de

correlaciones

MIME

mimemap.properties Especifica el archivo de correlaciones

MIME que el contenedor web debe

utilizar.

Por omisión, el Contenedor web

utilizará el archivo

mimemap.properties que está

empaquetado dentro del archivo

webcontainer.jar situado en el

directorio del plug-in de Contenedor

web.

Por omisión, el Contenedor

web utilizará el archivo

mimemap.properties que está situado

en la carpeta META-INF del directorio

del plug-in de Contenedor web.

com.ibm.pvc.webcontainer.mimemap.configfile n/d - no se puede configurar

con Administración de

configuración.

Archivo de

configuración

de

codificación

encoding.properties Especifica el archivo de codificación del

juego de caracteres que el contenedor

web debe utilizar.


utilizará el archivo encoding.properties

que está empaquetado dentro del

archivo webcontainer.jar situado en el

directorio del plug-in de Contenedor

web.



encoding.properties que está situado en

la carpeta META-INF del directorio del

plug-in de Contenedor web.

Los usuarios pueden utilizar esta

propiedad para proporcionar su propio

archivo de codificación del juego de

caracteres.

Los usuarios pueden especificar una

vía de acceso absoluta o una vía de

acceso relativa al directorio de trabajo.

com.ibm.pvc.webcontainer.encoding.configfile n/d - no se puede configurar

con Administración de

configuración.


Tabla 5. Propiedades de sistema Java (continuación)

Opción

Valor





6.1.1)

Archivo de

configuración

de conversor

converter.properties Especifica los conversores de caracteres

que el Contenedor web debe utilizar.


utilizará el archivo converter.properties

situado en el directorio del plug-in de

Contenedor web.



converter.properties que está situado en

la carpeta META-INF del directorio del

plug-in de Contenedor web.

Los usuarios pueden utilizar esta

propiedad para proporcionar su propio

archivo de conversor de caracteres. Los

usuarios pueden especificar una vía de

acceso absoluta o una vía de acceso

relativa al directorio de trabajo.

com.ibm.pvc.webcontainer.converters.configfile n//d

Archivo de

configuración

de host

virtual

N/D Especifica la ubicación del archivo de

configuración de host virtual. Este

archivo de configuración puede

utilizarse para controlar el acceso a las

aplicaciones web registradas con el

Contenedor web por puerto o nombre

de host.

com.ibm.pvc.webcontainer.vhost.configfile n//d

Si la máquina se desconecta de la red (sólo Linux), necesita añadir manualmente la entrada siguiente en

el archivo /etc/hosts:

127.0.0.1 <nombre_host_máquina>

Esto permitirá que el Contenedor web funcione correctamente cuando esté desconectado de la red.

Configuración de las propiedades de host virtual (6.1.2)

El Contenedor web proporciona a los administradores la posibilidad de restringir el acceso a las

aplicaciones web a un puerto específico o una lista de puertos. Consulte este apartado si necesita

restringir el acceso a determinadas aplicaciones web.

Utilice la propiedad de sistema com.ibm.pvc.webcontainer.vhost.configfile para especificar un archivo de

configuración que asigne un puerto o puertos a las aplicaciones web. Por ejemplo, si la aplicación web A

se correlaciona con el puerto 80, sólo se pueda acceder a ella desde el puerto 80; si se accede a la

aplicación web A desde cualquier otro puerto, se producirá un error 404.

El archivo de configuración contiene una serie de correlaciones de aplicación con puerto. Una aplicación

se puede correlacionar con un puerto o una lista de puertos. Un archivo de configuración de ejemplo

tendrá este aspecto:

/foo=localhost:80

/foo2=*:80

/foo3=*:*

/foo4=localhost:[80,8777,9999]

/foo5=[80,8777,8999]

/foo6=80

/foo7=xyz.com:*

/foo8=xyz.com:8777

/foo9=xyz.com:[80,8777]

v foo sólo es accesible desde localhost en el puerto 80

v foo2 es accesible desde cualquier máquina externa pero sólo en el puerto 80

v foo3 es accesible desde cualquier máquina externa en cualquier puerto

v foo4 sólo es accesible desde localhost en los puertos 80, 8777 y 9999


v foo5 sólo es accesible desde localhost en los puertos 80, 8777 y 8999

v foo6 sólo es accesible desde localhost en el puerto 80

v foo7 es accesible desde cualquier máquina externa en cualquier puerto SI el nombre de host de la

máquina en la que está alojada la aplicación web es xyz.com

v foo8 es accesible desde cualquier máquina externa en el puerto 8777 SI el nombre de host de la


v foo9 es accesible desde cualquier máquina externa en los puertos 80 y 8777 SI el nombre de host de la


Se aplica el siguiente conjunto de normas para el archivo de configuración de host virtual:

v Para proteger un servlet, la aplicación web no J2EE (como el servlet de asignador WebServices),

necesita especificar el nombre de servlet similar al que se especifica para una aplicación web J2EE que

tenga una raíz de contexto (por ejemplo, para proteger el servlet de servicios web ws especifique

/ws=[9000, 9050] si desea restringir el acceso de servicios web a los puertos 9000 y 9050).

Archivo de configuración de infraestructura de canales – Este archivo debe utilizarse para configurar

canales, cadenas de canales y fábricas de canales. Consulte “Utilización del archivo de configuración de

Infraestructura de canales” en la página 74 para obtener más información sobre los pasos a seguir para

configurar la infraestructura de canales utilizando propiedades del sistema, y para ver un archivo de

configuración de ejemplo.

Configuración de las propiedades de host virtual (6.1.1)

El contenedor web proporciona a los administradores la posibilidad de restringir el acceso a las

aplicaciones web a un puerto específico o una lista de puertos. Consulte este apartado si necesita

restringir el acceso a determinadas aplicaciones web.

Utilice la propiedad de sistema com.ibm.pvc.webcontainer.vhost.configfile para especificar un archivo de

configuración que asigne un puerto o puertos a las aplicaciones web. Por ejemplo, si la aplicación web A

se correlaciona con el puerto 80, sólo se pueda acceder a ella desde el puerto 80; si se accede a la

aplicación web A desde cualquier otro puerto, se producirá un error 404.

El archivo de configuración contiene una serie de correlaciones de aplicación con puerto. Una aplicación

se puede correlacionar con un puerto o una lista de puertos. Un archivo de configuración de ejemplo

tendrá este aspecto:

/myApplication=9999

/myOtherApplication=[8777,9999]

Se aplica el siguiente conjunto de normas para el archivo de configuración de host virtual:

v Si se especifica una correlación para una aplicación determinada, sólo se puede acceder a la aplicación

en los puertos especificados (por ejemplo /myContentRoot=9000 significa que sólo se puede acceder a la

aplicación con la raíz de contexto /myContextRoot en el puerto 9000)

v Para proteger un servlet, la aplicación web no J2EE (como el servlet de asignador WebServices),

necesita especificar el nombre de servlet similar al que se especifica para una aplicación web J2EE que

tenga una raíz de contexto (por ejemplo, para proteger el servlet de servicios web ws especifique

/ws=[9000, 9050] si desea restringir el acceso de servicios web a los puertos 9000 y 9050).

v De forma predeterminada, si no se especifica ninguna correlación para una aplicación, se permitirán las

solicitudes para dicha aplicación en TODOS los puertos.

v Si se especifica la raíz de contexto pero no se especifica ningún puerto, se permitirán solicitudes para

dicha aplicación en TODOS los puertos.


Configuración del contenedor web para utilizar un puerto dinámico

Si el valor de la propiedad de sistema Java com.ibm.pvc.webcontainer.port es igual a 0, el contenedor

web selecciona un puerto aleatorio cuando se inicia el plug-in de contenedor Web. Esto hace posible

ejecutar varias instancias del contenedor web al mismo tiempo en la misma máquina.

Lotus Expeditor Client utiliza un puerto dinámico de forma predeterminada.

Nota: Este puerto se difundirá a todos los plug-ins que registran un servicio

com.ibm.pvc.webcontainer.listener.HttpSettingListener. Para obtener más información sobre el

servicio com.ibm.pvc.webcontainer.listener.HttpSettingListener, consulte Localización de los puertos

de contenedor web utilizando el servicio HttpSettingListener en Desarrollo de aplicaciones para Lotus

Expeditor. Cuando se utiliza un puerto dinámico, el rango del valor de puerto es de 1 a 65535.

Cuando se especifica el valor de un puerto de contenedor web, los administradores deben

asegurarse de que no hay ningún conflicto con ningún otro servidor del sistema. Por ejemplo, los

administradores deben tener cuidado al establecer el puerto de contenedor web en 80 porque los

servidores HTTP utilizan el puerto 80 frecuentemente.

Configuración con el servicio Administración de configuración

Cuando se utiliza Lotus Expeditor Client en el escritorio, se puede configurar el contenedor web

utilizando el servicio Administración de configuración de OSGi. El Agente de gestión de empresa

proporciona un medio para que los administradores puedan configurar el contenedor web utilizando el

servicio Administración de configuración.

Nota: si se especifica alguna de las propiedades del sistema, éstas prevalecerán y el contenedor web

ignorará los datos de configuración almacenados en el servicio Administración de configuración.

El PID del contenedor web ManagedServiceFactory es com.ibm.pvc.webcontainer.

Consulte “Configuración de los plug-ins de cliente con el Agente de gestión de empresa” en la página

221 para obtener información sobre cómo configurar el contenedor web utilizando el servicio

Administración de configuración y el Agente de gestión de empresa.

Configuración del contenedor web utilizando el Agente de gestión de empresa

Puede cambiar de forma remota la configuración del contenedor web utilizando el Agente de gestión de

empresa.

Nota: A continuación se indican los prerrequisitos para el procedimiento de configuración:

v El almacenamiento de administración de configuración ya se ha llenado previamente con datos

de configuración de contenedor Web.

v El Agente de gestión de empresa se ha registrado en el servidor Device Manager y está

preparado para funcionar.

Siga estos pasos para cambiar la configuración de un plug-in de cliente, utilizando varios trabajos para

realizar la tarea. Estas tareas deben llevarse a cabo en un sistema que ejecute un servidor Device Manager

utilizando la aplicación de consola de Device Manager.

1. Pulse Dispositivos.

2. Seleccione Utilizar consulta nueva y Devolver cualquier valor como criterio y pulse Aceptar. La

consola de Device Manager mostrará una lista de dispositivos inscritos.

3. Seleccione el dispositivo, pulse con el botón derecho del ratón y seleccione Someter trabajo.

4. Pulse Siguiente y, a continuación, seleccione Tipo de trabajo como Descubrimiento de nodos

(utilice los valores predeterminados para todos los demás atributos de trabajo).

5. Seleccione Siguiente y, a continuación, seleccione Añadir grupo.


6. Escriba ./OSGi/BundleConfiguration/<PID_Plugin> como URL de destino donde <PID_Plugin> es

el PID del plug-in. Por ejemplo, com.ibm.pvc.webcontainer es el PID del contenedor Web.

7. Entre una profundidad de búsqueda de 5 y, a continuación, pulse Siguiente.

8. Pulse Aceptar. El trabajo se ha sometido. Pulse Cerrar.

9. Una vez que el trabajo haya finalizado, seleccione el servicio y pulse Ver inventario.

10. A continuación, seleccione Árbol de gestión.

11. Seleccione la entrada de configuración que desea configurar y pulse Someter trabajo.

12. Pulse Siguiente. Deje los valore predeterminados que aparecen en el panel y pulse Siguiente.

13. Entre 1 en el campo Número de mandato.

14. Establezca el valor de Datos para la entrada de configuración y pulse Siguiente.

15. Pulse Aceptar.

16. Pulse Cerrar y, a continuación, pulse Cerrar de nuevo y espere a que finalice el trabajo.

Configuración de HTTPS

Cuando se utiliza Lotus Expeditor Client en el escritorio, HTTPS (Secure Hypertext Transfer Protocol) es

un protocolo de comunicaciones utilizado para cifrar datos entre sistemas a través de la Web.

HTTPS utiliza una capa de sockets seguros (SSL) para transferir datos HTTP cifrados. Consulte

“Configuración de SSL para el contenedor web” en la página 92 para obtener información sobre los pasos

necesarios.

Configuración del contenedor web utilizando SocketConfigService

Los paquetes de otras empresas pueden utilizar el servicio

com.ibm.pvc.webcontainer.service.SocketConfigService para configurar dinámicamente los puertos de

contenedor web durante la ejecución. Revise este apartado si necesita configurar dinámicamente los

puertos de contenedor web durante la ejecución.

Los paquetes deben utilizar un rastreador de servicios para hacer el seguimiento del objeto

com.ibm.pvc.webcontainer.service.SocketConfigService.

El ejemplo siguiente muestra cómo invocar los métodos de

com.ibm.pvc.webcontainer.service.SocketConfigService startTransport y stopTransport desde el rastreador

de servicios de un paquete.

import com.ibm.pvc.webcontainer.service.SocketConfigService;

import com.ibm.pvc.webcontainer.service.SocketConfigException;

...

private BundleContext context = null;

private ServerSocket socket = null;

public MyServiceTracker(BundleContext bc)

{

context = bc;

}

public Object addingService(ServiceReference reference)

{

SocketConfigService service = (SocketConfigService) context.getService(reference);

if(service != null) {

try {

// crear ServerSocket

socket = new ServerSocket(9999);

// configurar contenedor web para escuchar en el puerto 9999

service.startTransport(socket);


...

} catch (SocketConfigException e) {

// manejar excepción

}

...

}

...

}

public void removedService(ServiceReference reference, Object service)

{

if(service != null) {

// concluir transporte

service.stopTransport(socket);

}

}

Habilitación y configuración de la Infraestructura de canales

La Arquitectura de infraestructura de canales (CFA) es una solución altamente flexible y escalable para

transportes de cliente y servidor que proporciona servicios de red comunes, protocolos y operaciones de

E/S para el Contenedor web de Expeditor.

Si viéramos la pila de protocolos como la creación de un transporte, los canales individuales dentro de

esta arquitectura podrían considerarse como capas de protocolo en una pila de red. Esta arquitectura

proporciona conectabilidad ampliada en toda la cadena de sucesos que participan en el manejo de la

comunicación con el servidor y en el proceso del contenido de la comunicación en diversos pasos en el

servidor.

La arquitectura CFA define un conjunto de interfaces que pueden utilizarse para implementar dos tipos

principales de objetos, canales y cadenas de canales. Los canales se utilizan para transportar datos entre

la red y el componente de servidor Contenedor web. Los canales son una encapsulación de la lógica para

procesar cierta parte de una corriente de datos o para intercambiar información con un componente. La

corriente de datos puede ser parte de una petición de entrada para un servidor de aplicaciones o de una

petición de salida de un servidor de aplicaciones. Las cadenas de canales consisten en un conjunto de

canales que están enlazados entre sí y se utilizan para transportar datos de la red a un componente o de

un componente a la red. Mediante la definición de un mecanismo estándar para combinar los canales, es

posible conectar canales personalizados que soportan requisitos exclusivos de un determinado cliente o

entorno.

En la arquitectura CFA, un componente que está al principio o al final de una cadena de canales se

conoce como el usuario de infraestructura de canales (CFU). En una cadena de canales de entrada, la

petición se origina en la red y termina en el CFU. En una cadena de canales de salida, la petición se

origina en el CFU y termina en la red. El Contenedor web de Expeditor es un CFU. Los CFU pueden ser

el destino de muchas cadenas de canales de entrada y el origen de muchas cadenas de canales de salida.

Tipos de canales

Los canales se clasifican en los siguientes tipos:

v Los canales de conector son los canales más cercanos a la interfaz de red. Un canal de conector es el

canal de nivel inferior en la pila de protocolos de canal. Un ejemplo de un canal de conector es un

canal TCP (Protocolo de control de transmisiones).

v Los canales de protocolo son responsables de resumir la información que se transfiere a través de

ellos. Al leer la información, un canal de protocolo generalmente analizará la información en

estructuras de alto nivel que se correlacionan con construcciones que son específicas del protocolo. Al

escribir la información, un canal de protocolo tomará la información proporcionada en estructuras

específicas del protocolo y la correlacionará con las estructuras que necesita el canal situado debajo de


él en la pila. Puede haber cero o más canales de protocolo en el enlace entre el canal de conector y el

canal de aplicación. Un ejemplo de canal de protocolo sería un canal HTTP (Protocolo de transferencia

de hipertexto).

v Los canales de Aplicación/Aceptante son los canales de nivel superior. Estos canales generalmente se

crean encima de protocolos específicos a fin de extraer los datos correctos de los mismos. Un ejemplo

de canal de aplicación es el que se incluye para el Contenedor web de Expeditor.

v Los canales de filtro sólo pueden aparecer en el interior de una cadena. Los canales de filtro no

realizan conversiones de protocolos y, por lo tanto, deberían aceptar y emitir el mismo tipo de datos.

Los canales de filtro se pueden utilizar para aplicaciones tales como el registro cronológico, aplicación

de SLA, etcétera.

El servicio Infraestructura de canales es responsable de gestionar el ciclo de vida de la infraestructura de

canales. Es responsable del correcto comportamiento de canales y cadenas de canales durante el inicio y

conclusión del servidor.

Habilitación y configuración de la Infraestructura de canales utilizando

extensiones de Eclipse

Los pasos siguientes describen cómo habilitar la Infraestructura de canales del Contenedor web

utilizando extensiones de Eclipse.

1. Cree un plug-in de Eclipse y especifique las extensiones de Eclipse en el descriptor plugin.xml del

plug-in. Consulte la documentación de Esquemas de punto de extensión en Desarrollo de aplicaciones

para Lotus Expeditor para obtener más información sobre la extensión que puede especificar o

configurar. A continuación se muestra un ejemplo de un archivo descriptor plugin.xml:

2. http://revidd.austin.ibm.com:8880/help/topic/com.ibm.rcp.tools.doc.appdev/reference_extensionpointschemas.html

<?xml version="1.0" encoding="UTF-8"?>

<?eclipse version="3.0"?>

<plugin>



<extension point="com.ibm.rcp.channelframework.service.channel">

<channel name="TCP_OUT" factory="com.ibm.ws.tcp.channel.impl.TCPChannelFactory">

</channel>

</extension>


<channel name="TCP_IN" factory="com.ibm.ws.tcp.channel.impl.TCPChannelFactory">

<property name="hostname"

value="localhost"/>

<property name="port"

value="11111"/>

</channel>

</extension>


<channel name="TCP_IN_2"

factory="com.ibm.ws.tcp.channel.impl.TCPChannelFactory">


value="*"/>


value="9898"/>

</channel>

</extension>





value="localhost"/>


value="15000"/>

</channel>


</extension>





value="*"/>


value="5061"/>

</channel>

</extension>




<channel name="HTTP_IN"

factory="com.ibm.ws.http.channel.inbound.impl.HttpInboundChannelFactory">

<property name="persistTimeout" value="5000" />

<property name="readTimeout" value="5000" />

<property name="writeTimeout" value="5000" />

<property name="maxKeepAliveRequests" value="30" />

<property name="keepAliveEnabled" value="true" />

</channel>

</extension>


<channel name="HTTP_OUT"

factory="com.ibm.ws.http.channel.outbound.impl.HttpOutboundChannelFactory"/>

</extension>




<channel name="SSL_2"

factory="com.ibm.ws.ssl.channel.impl.WSSSLChannelFactory">

</channel>

</extension>




<channel name="UDP"

factory="com.ibm.ws.udp.channel.impl.UDPChannelFactory"/>

</extension>




<channel name="WC_APP"

factory="com.ibm.ws.webcontainer.channel.WCChannelFactory"/>

</extension>



<extension point="com.ibm.rcp.channelframework.service.chain">

<chain name="TEST INBOUND CHAIN"

type="INBOUND"

group="com.ibm.pvc.webcontainer">

<channel name="TCP_IN" order="0" type="CONNECTOR"/>

<channel name="HTTP_IN" order="1" type="PROTOCOL"/>

<channel name="WC_APP" order="2" type="ACCEPTOR"/>

</chain>

</extension>


<chain name="TEST INBOUND CHAIN 2"

type="INBOUND"


<channel name="TCP_IN_2" order="0" type="CONNECTOR"/>



</chain>


</extension>


<chain name="TEST INBOUND CHAIN 3"

type="INBOUND"


<channel name="TCP_IN_3" order="0" type="CONNECTOR"/>

<channel name="SSL_2" order="1" type="PROTOCOL"/>



</chain>

</extension>

</plugin>

v Todas las propiedades SSL deben seguir especificándose en el archivo de configuración SSL del

Contenedor web. La ubicación de este archivo se especifica utilizando la propiedad del sistema

com.ibm.pvc.webcontainer.ssl.configfile. (consulte “Configuración de SSL para el contenedor web” en la

página 92).

Nota: El canal SSL SÓLO está soportado en J2SE. No funciona en DesktopEE.

Habilitación y configuración de la Infraestructura de canales utilizando

propiedades del sistema

Se pueden configurar canales, fábricas de canales y cadenas de canales utilizando las propiedades del

sistema de esta sección. Todas las propiedades del sistema deben especificarse en el archivo de

configuración de Infraestructura de canales. Consulte “Utilización del archivo de configuración de

Infraestructura de canales” en la página 74 – la ubicación de este archivo se especifica utilizando la

propiedad del sistema com.ibm.rcp.channelframework.configfile.

Tabla 6. Propiedades de canal TCP

Opción Valor predeterminado Descripción Propiedad del sistema Java

Fábrica TCP_FACTORY (tanto De

entrada como De salida)

Responsable de crear o encontrar un canal. com.ibm.rcp.channelframework.channel.factory.<nombre_canal_TCP>

Nombre de host N/D Nombre de host en el que escuchará el canal de

entrada.

com.ibm.rcp.channelframework.channel.hostname.<nombre_canal_TCP>

Puerto N/D Puerto en el que escuchará el canal de entrada. com.ibm.rcp.channelframework.channel.port.<nombre_canal_TCP>

Número

máximo de

conexiones

abiertas

Mín - 1

Máx - 20000

El número máximo de conexiones permitidas

para un canal de entrada

com.ibm.rcp.channelframework.channel.port.<nombre_canal_TCP>

Tabla 7. Propiedades de canal HTTP


Fábrica De entrada:

HTTP_IN_FACTORY

De salida:

HTTP_OUT_FACTORY

Responsable de crear o encontrar

un canal.

com.ibm.rcp.channelframework.channel.factory.<nombre_canal_HTTP>

Tiempo de

espera

persistente

30000 Tiempo de espera para recibir

peticiones adicionales en un socket

(ms)

com.ibm.rcp.channelframework.channel.persistTimeout.<nombre_canal_HTTP>

Tiempo de

espera de

lectura

60000 Tiempo de espera para que se

complete una operación de lectura

(ms)

com.ibm.rcp.channelframework.channel.readTimeout.<nombre_canal_HTTP>

Tiempo de

espera de

escritura

60000 Tiempo de espera para que se

complete una operación de escritura

(ms)

com.ibm.rcp.channelframework.channel.writeTimeout.<nombre_canal_HTTP>

Número

máximo de

peticiones por

conexión

100 Número máximo de peticiones

permitidas en una sola conexión

HTTP

com.ibm.rcp.channelframework.channel.maxKeepAliveRequests.<nombre_canal_HTTP>

Conexión

Keep-alive

True Controla si se tomará por omisión o

no una conexión persistente en

lugar de una conexión que se

cerrará después de un intercambio

petición/respuesta.

com.ibm.rcp.channelframework.channel.keepAliveEnabled.<nombre_canal_HTTP>


Tabla 8. Propiedades de canal SSL


Fábrica SSL_FACTORY (tanto De

entrada como De salida)

Responsable de crear o encontrar un canal. com.ibm.rcp.channelframework.channel.factory.<nombre_canal_SSL>

Protocolo SSL Opcional. Especifica el protocolo a utilizar. com.ibm.ssl.protocol. <nombre_canal_SSL

Tipo de almacén

de claves

JKS Opcional. Especifica el tipo de almacén de claves

a utilizar.

com.ibm.ssl.keyStoreType.<nombre_canal_SSL>

Ubicación del

almacén de

claves

N/D Obligatoria. Especifica la ubicación del almacén

de claves en el sistema de archivos.

com.ibm.ssl.keyStore.<nombre_canal_SSL>

Contraseña del

almacén de

claves

N/D Obligatoria. Especifica la contraseña para abrir el

almacén de claves.

com.ibm.ssl.keyStorePassword.<nombre_canal_SSL>

Tipo de almacén

de confianza

Vía de acceso totalmente

calificada al archivo en el

sistema de archivos.

Obligatoria. Especifica el tipo de almacén de

confianza.

com.ibm.ssl.trustStoreType.<nombre_canal_SSL>

Ubicación del

almacén de

confianza

Contraseña de texto plano

para el almacén de claves.

Obligatoria. Especifica la ubicación del almacén

de confianza en el sistema de archivos.

com.ibm.ssl.trustStore.<nombre_canal_SSL>

Contraseña del

almacén de

confianza

Contraseña de texto plano

para el almacén de

confianza.

Obligatoria. Especifica la contraseña para abrir el

almacén de confianza.

com.ibm.ssl.trustStorePassword.<nombre_canal_SSL>

Autenticación

de cliente

requerida

false Obligatoria. Especifica si la aplicación cliente

requiere autenticación.

com.ibm.ssl.clientAuthentication.<nombre_canal_SSL>

Lista de suites

de cifrado

habilitadas

N/D Obligatoria. Suites de cifrado habilitadas. com.ibm.ssl.enabledCipherSuites.<nombre_canal_SSL>

Tabla 9. Propiedades de canal de aplicación de Contenedor web


Fábrica WC_APP_FACTORY (tanto

De entrada como De

salida)

Responsable de crear o encontrar un canal. com.ibm.rcp.channelframework.channel.factory.<nombre_canal_WC_APP>

Tabla 10. Propiedades de cadena de canal


Nombre de

cadena

N/D El nombre de la cadena. com.ibm.rcp.channelframework.chain.name.<id_cadena>

Grupo de la

cadena

com.ibm.pvc.webcontainer. El nombre del grupo al que pertenece la cadena.

Debe establecerse en el identificador de CFU (por

ejemplo, com.ibm.pvc.webcontainer)

com.ibm.rcp.channelframework.chain.group.<id_cadena>

Lista de canales N/D Lista de canales en la cadena (separados por ‘:’ y

especificados en orden empezando por el canal

conector.

com.ibm.rcp.channelframework.chain.channelList.<id_cadena>

Tipo de cadena N/D El tipo de cadena (de entrada o de salida) com.ibm.rcp.channelframework.chain.type.<id_cadena>

Tabla 11. Propiedades de fábrica de canales


Clase de fábrica N/D La clase de fábrica. Debe ser un nombre de clase

válido, el paquete de clase debe estar en la vía de

acceso de clases para los paquetes

com.ibm.rcp.channelframework.factory.class.<nombre_fábrica>

Utilización del archivo de configuración de Infraestructura de canales

Los pasos siguientes describen cómo configurar el soporte de Infraestructura de canales del Contenedor

web.

Cree el archivo de configuración de Infraestructura de canales. Consulte “Habilitación y configuración de

la Infraestructura de canales utilizando propiedades del sistema” en la página 73 para obtener más

información sobre las propiedades que se pueden especificar o configurar. La ubicación del archivo de

configuración de Infraestructura de canales se especifica utilizando la propiedad

com.ibm.rcp.channelframework.configfile.

El archivo de configuración de Infraestructura de canales de ejemplo que figura a continuación muestra

cómo configurar dos pilas de canales HTTP / HTTP separadas:


# propiedades de fábrica

com.ibm.rcp.channelframework.factory.class.HTTP_TEST_FACTORY=com.ibm.ws.http.channel.inbound.impl.HttpInboundChannelFactory

com.ibm.rcp.channelframework.factory.class.TCP_TEST_FACTORY=com.ibm.ws.tcp.channel.impl.TCPChannelFactory

com.ibm.rcp.channelframework.factory.class.WC_TEST_FACTORY=com.ibm.ws.webcontainer.channel.WCChannelFactory

com.ibm.rcp.channelframework.factory.class.SSL_TEST_FACTORY=com.ibm.ws.ssl.channel.impl.WSSSLChannelFactory

# propiedades de canal para canal(es) TCP

com.ibm.rcp.channelframework.channel.factory.TCP_TEST=TCP_TEST_FACTORY

com.ibm.rcp.channelframework.channel.port.TCP_TEST=9999

com.ibm.rcp.channelframework.channel.hostname.TCP_TEST=localhost

com.ibm.rcp.channelframework.channel.factory.TCP_TEST_2=TCP_TEST_FACTORY

com.ibm.rcp.channelframework.channel.port.TCP_TEST_2=12222

com.ibm.rcp.channelframework.channel.hostname.TCP_TEST_2=localhost

# propiedades de canal para canal(es) HTTP

com.ibm.rcp.channelframework.channel.factory.HTTP_TEST=HTTP_TEST_FACTORY

com.ibm.rcp.channelframework.channel.persistTimeout.HTTP_TEST=7500

com.ibm.rcp.channelframework.channel.readTimeout.HTTP_TEST=7500

com.ibm.rcp.channelframework.channel.writeTimeout.HTTP_TEST=7500

com.ibm.rcp.channelframework.channel.maxKeepAliveRequests.HTTP_TEST=7500

com.ibm.rcp.channelframework.channel.keepAliveEnabled.HTTP_TEST=true

com.ibm.rcp.channelframework.channel.factory.HTTP_TEST_2=HTTP_TEST_FACTORY

com.ibm.rcp.channelframework.channel.persistTimeout.HTTP_TEST_2=7500

com.ibm.rcp.channelframework.channel.readTimeout.HTTP_TEST_2=7500

com.ibm.rcp.channelframework.channel.writeTimeout.HTTP_TEST_2=7500

com.ibm.rcp.channelframework.channel.maxKeepAliveRequests.HTTP_TEST_2=7500

com.ibm.rcp.channelframework.channel.keepAliveEnabled.HTTP_TEST_2=true

# propiedades de canal para canal(es) SSL (las propiedades SSL restantes, incluidas las ubicaciones

# de almacén de claves y almacén de confianza se definen en el archivo de configuración SSL)

com.ibm.rcp.channelframework.channel.factory.SSL_TEST=SSL_TEST_FACTORY

# propiedades de canal para canal(es) de aplicación de Contenedor web

com.ibm.rcp.channelframework.channel.factory.WC_TEST=WC_TEST_FACTORY

com.ibm.rcp.channelframework.channel.factory.WC_TEST_2=WC_TEST_FACTORY

# propiedades de cadena

com.ibm.rcp.channelframework.chain.name.1=TEST HTTP CHAIN

com.ibm.rcp.channelframework.chain.group.1=com.ibm.pvc.webcontainer

com.ibm.rcp.channelframework.chain.channelList.1=TCP_TEST:HTTP_TEST:WC_TEST

com.ibm.rcp.channelframework.chain.type.1=INBOUND

com.ibm.rcp.channelframework.chain.name.2=TEST HTTPS CHAIN

com.ibm.rcp.channelframework.chain.group.2=com.ibm.pvc.webcontainer

com.ibm.rcp.channelframework.chain.channelList.2=TCP_TEST_2:SSL_TEST:HTTP_TEST_2:WC_TEST_2

com.ibm.rcp.channelframework.chain.type.2=INBOUND

v Todas las propiedades SSL deben seguir especificándose en el archivo de configuración SSL del

Contenedor web. La ubicación de este archivo se especifica utilizando la propiedad del sistema

com.ibm.pvc.webcontainer.ssl.configfile. (consulte “Configuración de SSL para el contenedor web” en la

página 92).

v Lance el entorno de ejecución de Lotus Expeditor. A continuación, el Contenedor web procederá a la

inicialización del proveedor de Infraestructura de canales y utilizará el proveedor para configurar cada

canal especificado en el archivo de configuración y, posteriormente, habilitar las cadenas de canales

especificadas también en el archivo de configuración. Todas las propiedades SSL se proporcionarán

también al proveedor de Infraestructura de canales.

v Acceda a cualquier aplicación web registrada y activa en los puertos especificados.

Configuración del contenedor de portlets

El contenedor de portlets proporciona un entorno de ejecución para las aplicaciones de portlet JSR 168 en

las que los portlets JSR 168 se pueden instanciar, utilizar y finalmente se pueden destruir.

El contenedor de portlets permite tanto a usuarios como a desarrolladores acceder a aplicaciones de

portlet desconectadas (fuera de línea) o conectadas (en línea) y ejecutarlas.

No es necesaria ninguna configuración del contenedor de portlets.


El contenedor de portlets es un procesador de extensiones adicional que aprovecha la funcionalidad del

contenedor Web y reutiliza los valores de contenedor Web (por ejemplo dirección de servidor y puerto de

servidor). Consulte el apartado “Configuración del contenedor Web” en la página 64 para obtener más

información.

Al representar los portlets, puede cambiar las imágenes y la hoja de estilo utilizados por el contenedor de

portlets. Consulte el apartado “Configuración de la creación de marca del contenedor de portlets” en la

página 135 para obtener más información.

Configuración de las preferencias de portlet

Puede gestionar y actualizar de forma remota el conjunto predeterminado de preferencias de portlet.

El Contenedor de portlets utiliza las preferencias de Eclipse para almacenar de forma persistente las

preferencias de portlet modificadas y actualizadas. Consulte “Gestión de preferencias de Eclipse” en la

página 114 para obtener más información sobre cómo gestionar las preferencias de Eclipse de forma

remota.

Configuración de servicios Web móviles

No es necesario realizar ningún tipo de configuración local para desplegar los servicios Web móviles. Los

proveedores de estos servicios escucharán en el mismo puerto que el contenedor web.

Debe tener en cuenta que, si una aplicación cliente de servicio Web móvil da lugar a una excepción de

ejecución con un mensaje que indica que el análisis del WSDL especificado ha dado un error, seguido por

una explicación, deberá garantizar que el acceso al WSDL sea posible a través del navegador. Esta

excepción podría ser el resultado de un mensaje en formato HTML de un cortafuegos que solicita

autenticación o podría deberse a un WSDL no válido. Si el WSDL no es válido, puede ser necesario

autenticarse con el cortafuegos antes de ejecutar la aplicación cliente de servicios Web móviles o de

albergar el servicio Web o el WSDL fuera del cortafuegos.

Instalación de componentes de Web Services Resource Framework

Los plug-ins de Web Services Resource Framework están empaquetados con el soporte de instalación de

Lotus Expeditor Client pero no se instalan como parte de la instalación predeterminada del cliente. Es

necesario instalar manualmente los componentes de Web Services Resource Framework del CD de Lotus

Expeditor Client CD.

Para instalar manualmente los componentes de Web Services Resource Framework, siga estos pasos:

1. Inserte el CD de Lotus Expeditor Client.

2. Inicie Lotus Expeditor Client.

3. Pulse Archivo → Aplicación → Instalar.

4. Seleccione Buscar nuevas características a instalar y pulse Siguiente.

5. Pulse el botón Nueva ubicación local y vaya al directorio /desktop/updates/platform/ del soporte o

del lugar donde haya ejecutado unzip para desempaquetar el archivo zip del producto. Pulse Aceptar.

6. Pulse Aceptar en el recuadro de diálogo Editar una ubicación local y, a continuación, pulse Finalizar.

El Gestor de actualizaciones buscará las actualizaciones.

7. Se abre la pantalla Resultados de la búsqueda. En la lista de características a instalar, expanda

/updates/platform → runtimes y seleccione Web Services Resource Framework 6.1.0.0. Pulse

Siguiente.

8. Acepte la licencia y pulse Siguiente.

9. Siga los pasos restantes para completar la instalación.


Configuración de los clientes de servicios web de Apache Axis

Apache Axis es una implementación de código abierto de SOAP. Se ha habilitado para proporcionar

soporte de ejecución para los clientes basados en JAX-RPC en Lotus Expeditor.

Configuración de los valores de proxy de cliente de Apache Axis

El entorno de ejecución del cliente de Apache Axis requiere que se establezcan propiedades de VM

cuando se conecta a través de un proxy HTTP.

El entorno de ejecución del cliente de Apache Axis requiere que se establezcan las propiedades de JVM

siguientes cuando se conecta a través de un proxy HTTP. El cliente de Apache Axis no reconoce los

valores de proxy proporcionados por las preferencias de Eclipse en el entorno de Expeditor.

v -Dhttp.proxyHost -- Nombre de host del servidor proxy

v -Dhttp.proxyPort -- Puerto en servidor de proxy

v -Dhttp.proxyUser -- Nombre de usuario opcional para autenticación de proxy

v -Dhttp.proxyPassword -- Contraseña opcional de servidor proxy

Configuración de valores gestionados

La infraestructura de valores gestionados le proporciona control sobre el comportamiento del entorno de

ejecución de las aplicaciones de cliente dejándole establecer los valores que las aplicaciones leen del


Si también designa estos valores como de sólo lectura, se impedirán los cambios que las aplicaciones

cliente realicen en los valores o subsiguientemente se grabarán los valores encima de dichos cambios, en

función de cómo el cliente acceda a los valores. Si el programa cliente conoce los valores gestionados y

accede a ellos mediante el ámbito de preferencias de Eclipse ManagedSettings, se impedirán los cambios

en los valores de sólo lectura. Para otros plug-ins, que acceden a los valores del modo tradicional, se

pueden producir cambios pero posteriormente los valores que ud. defina se grabarán encima de ellos. Las

actualizaciones se ejecutan con regularidad para añadir cualquiera de los valores nuevos o de los cambios

de valores al almacén de preferencias del cliente.

La infraestructura de valores gestionados puede recuperar políticas, preferencias o cualquier otra pareja

de nombre y valor de cualquier sistema de fondo para el que existe un proveedor de valores gestionados.

Los proveedores conocen el sistema de fondo específico. Lotus Expeditor Client incluye proveedores para

recuperar valores del Gestor de políticas de portal y de un archivo XML que reside en el servidor http. Si

no hay ningún proveedor disponible para el sistema de fondo, puede escribir uno propio. Consulte el

apartado “Adición de un proveedor de valores gestionados” en la página 149 para obtener más

información.

Puede gestionar los valores de cliente completando los procedimientos siguientes:

1. Especificación de valores

2. Configuración de proveedores.

3. (Opcional) Establecimiento de la planificación de actualización de valores gestionados.

4. Verificación de que el plug-in de valores gestionados se inicia.

Especificación de valores

Puede especificar los valores deseados de la definición de cliente utilizando el sistema de administración

de fondo que elija.

Si el sistema de administración de fondo es el Gestor de políticas de portal, puede establecer los valores

con el editor de tipo de política para las preferencias de Eclipse. Consulte el apartado “Gestión de

preferencias de cliente rico utilizando el editor de tipo de política para preferencias de Eclipse” en la

página 255


página 253 para obtener más información. Todos los valores del Gestor de políticas de portal se tratarán

como si se especificaran de sólo lectura. Si el sistema de administración de fondo es Domino, usted

especificará los valores en el subsistema de políticas del cliente de administración de Domino.

Se accede a las preferencias de Eclipse utilizando un calificador (normalmente el nombre de plug-in) y

opcionalmente un ámbito, que determinan la ubicación de almacenamiento de la preferencia. Para que las

aplicaciones cliente lean los valores, éstos deben guardarse en el mismo lugar en que el cliente los está

buscando. Existen dos modos posibles de determinar esta información:

v Consulte la documentación de la aplicación para ver si se ha publicado una lista de valores o solicite

una lista al desarrollador de aplicaciones.

v Determine usted mismo los nombres de los calificadores y los valores cambiando valores en los paneles

de preferencias y otros controles de interfaz de usuario proporcionados por la aplicación y examinando

los cambios resultantes en el almacenamiento de preferencias de Eclipse.

La infraestructura de valores gestionados permite a los administradores controlar los valores en los

ámbitos siguientes:

v Configuración - Preferencias que se almacenan por instalación de la plataforma. Se comparten entre

espacios de trabajo.

v Instancia - Preferencias que se almacenan por espacio de trabajo o por instancia en ejecución de la

plataforma.

v También es posible que se gestionen ámbitos personalizados, en función de la implementación.

ManagedSettingsScope es un ámbito personalizado, para uso de la infraestructura de valores gestionados

y las aplicaciones con información de valores gestionados. Los datos se oscurecen para evitar una

manipulación indebida por parte del usuario final. A las aplicaciones que acceden a los valores utilizando

este ámbito en lugar de utilizar los ámbitos estándar de Eclipse se les impedirá que cambien valores de

sólo lectura. Los valores de sólo lectura se almacenan en el ámbito de valores gestionados así como el

ámbito estándar asociado.

Un grupo de valores es un grupo de valores relacionados. Cuando la infraestructura de valores

gestionados recupera un valor de un sistema de fondo, el grupo de valores al que pertenece es la unidad

que se recupera, no el valor individual. La estructura de un grupo de valores depende del sistema de

fondo que genera los valores contenidos en él y la implementación del proveedor asociado con el sistema

de fondo. Por ejemplo, para el proveedor de Portal, un grupo de valores es equivalente a un tipo de

política.

Si está especificando valores gestionados en el Gestor de políticas de portal utilizando el Editor de tipo

de política para preferencias, hay atributos independientes para el ámbito y el calificador que puede

establecer de forma explícita. Para obtener instrucciones, consulte “Gestión de preferencias de cliente rico

utilizando el editor de tipo de política para preferencias de Eclipse” en la página 255. Para este

proveedor, un grupo de valores se correlaciona con el conjunto de preferencias, que se correlaciona con el

nombre de política. Cuando se configuran los conjuntos de preferencias, es importante para el

seguimiento de supresión que todos los valores con el mismo calificador estén en el mismo conjunto de

preferencias. Todos los valores que se recuperan del Gestor de políticas de portal se tratarán como si

fueran de sólo lectura.

Si está especificando valores gestionados con el proveedor de archivos XML, deberá hacer que el nombre

de grupo de valores coincida con el calificador (normalmente el ID de plug-in). Si el ámbito no es un

ámbito de instancia, deberá añadir el nombre del ámbito más el carácter de barra inclinada (/) al

principio del nombre del grupo de valores.

Por ejemplo:

<settingGroup name="org.eclipse.ui" lastModDate="20060131">

<setting name="showIntro" value="false" isLocked="false"/>

</settingGroup>


<settingGroup name="configuration/com.isv.my.plugin"" lastModDate="20060131">

<setting name="use_large_icons" value="true" isLocked="true"/>

<setting name="sortOrder" value="descending" isLocked="false"/>

</settingGroup>

Si se especifica isLocked como true, el valor se tratará como de sólo lectura. Para obtener más

información sobre el proveedor de archivos XML, consulte el apartado “Configuración del proveedor de

archivos XML” en la página 81.

Si está utilizando un sistema de valores administrativos de fondo diferente y el entorno le permite

controlar el nombre de los grupos de valores (sea cual sea el concepto de grupo de valores para dicho

sistema), es más eficiente dar al grupo de valores el nombre del calificador que se utilizará para acceder a

los valores en el cliente. Si es necesario almacenar los valores en un ámbito distinto del ámbito de

instancia, deberá añadir el nombre de ámbito y el carácter de barra inclinada (/) al principio del nombre.

Por ejemplo, si especifica un nombre de grupo de valores de org.eclipse.help.ui, la infraestructura

almacena todos los valores para dicho grupo en el ámbito de instancia utilizando un calificador de

org.eclipse.help.ui. Si especifica un nombre de grupo de valores de configuration/org.eclipse.core.internal.preferences.osgi, la infraestructura almacena todos los valores para dicho

grupo en el ámbito de configuración utilizando un calificador de

org.eclipse.core.internal.preferences.osgi.

Si no es factible denominar el grupo de valores para que coincida con el calificador, puede especificar el

calificador añadiéndolo al principio de cada nombre de valor, separando el calificador y el nombre de

valor con un carácter de barra inclinada (/). Por ejemplo, puede denominar el grupo de valores, Todas

mis preferencias de Eclipse, y denominar uno de los valores org.eclipse.core.help.base/bookmarks.

Puede denominar otra serie org.eclipse.ui/showIntro. Como resultado se recuperan juntos ambos

valores, bookmarks y showIntro, como parte del mismo grupo de valores, pero el primero se almacena

con un calificador de org.eclipse.core.help.base y el último con un calificador de org.eclipse.ui.

v Adición del ámbito al principio del nombre de grupo de valores - El ámbito se aplica a todos los

valores del grupo de valores. Por ejemplo: configuration/org.eclipse.core.runtime

v Adición del ámbito al principio del nombre de valor - Si añade el ámbito al principio de un valor

individual, también debe especificar el calificador para el valor, aunque coincida con el nombre de

grupo de valores. Por ejemplo: configuration/org.eclipse.core.help.base/bookmarks

La tabla siguiente contiene valores de ejemplo especificados por un administrador:

Tabla 12. Valores de ejemplo

Nombre de valor Grupo/calificador = com.isv.existing.plugin

use_large_icons true

sort_order descending

com.isv.existing.plugin.helper/color_scheme ocean

configuration/com.isv.existing.plugin/max_windows 5

Se crean las siguientes ubicaciones resultantes en los ámbitos estándar del almacenamiento de

preferencias de Eclipse basándose en los valores del administrador de la tabla anterior:

Root

|- instance

|- com.isv.existing.plugin

|- use_large_icons = true

|- sort_order = descending

|- com.isv.existing.plugin.helper


|- color_scheme = ocean

|-configuration

|- com.ibm.existing.plugin

|- max_windows = 5

Si este esquema de denominación para especificar ámbitos y calificadores no es factible en el sistema de

valores de fondo, por ejemplo si hay un límite de caracteres que es demasiado pequeño, puede escribir al

proveedor para que convierta el formato que puede utilizar al formato que se describe más arriba.

Tenga en cuenta que los caracteres de barra inclinada (/) en el nombre de valor distintos de los que

delinean el ámbito y el calificador se tratarán como subnodos del calificador. Si tiene la intención de tener

un carácter de barra inclinada literal (/) en el nombre de valor, necesitará utilizar en su lugar dos

caracteres de barra inclinada (//).

Limitaciones en los calificadores

A continuación se indican las limitaciones en los calificadores:

v Es muy importante que un calificador no exista en más de un grupo de valores.

v Los nombres de calificador no pueden ser ″instance″, ″configuration″, ″default″, ″ManagedSettings″ o

ningún otro nombre que se utilice como nombre de ámbito.

Comportamiento de actualización

Si elimina valores del grupo de valores, éstos permanecerán en el cliente pero los valores de sólo lectura

pasarán a ser legibles. Si elimina un grupo de valores entero, todos los valores de dicho grupo de valores

permanecerán en el cliente pero los valores de sólo lectura pasarán a ser legibles.

Si cambia un valor que no es de sólo lectura y, a continuación, el usuario final modifica el valor, la

actualización no se aplicará a menos que cambie también el valor a sólo lectura.

Configuración de proveedores

Para conectarse en la infraestructura de valores gestionados, el sistema de gestión de fondo que llena el

almacenamiento de preferencias de Eclipse con los valores para la aplicación debe tener un proveedor de

valores gestionados correspondiente.

Un proveedor de valores gestionados es un plug-in que sabe cómo extraer valores de un sistema de

gestión de fondo asociado y formatearlos de forma apropiada para que la infraestructura los lea. Lotus

Expeditor Client proporciona a los proveedores valores especificados por el gestor de políticas de portal y

para valores que se especifican en archivos XML. Si la aplicación obtiene los valores de preferencias de

un sistema de fondo distinto de WebSphere Portal o de un archivo XML, puede crear un proveedor

personalizado para la misma. Consulte “Adición de un proveedor de valores gestionados” en la página

149.

Debe configurar el proveedor de archivos asociado con los valores especificados en archivos XML. Para

obtener detalles, consulte “Configuración del proveedor de archivos XML” en la página 81.

No necesita configurar el proveedor para el Gestor de políticas de portal, que es el sistema administrativo

de fondo utilizado por el cliente administrado por WebSphere Portal. En lugar de ello, debe crear una

cuenta que identifique el servidor WebSphere Portal y almacene información de autenticación para

conectarse a ella. Consulte el apartado “Gestión de cuentas” en la página 111 para obtener más

información.


Configuración del proveedor de archivos XML

El proveedor de archivos XML es responsable de obtener los valores de preferencias de un archivo XML.

El proveedor de archivos necesita tener un archivo XML que contenga los datos de valor gestionados y

debe conocer la ubicación de dicho archivo XML.

Para configurar el proveedor de archivos:

1. Formatee el archivo XML del modo siguiente:

v Debe contener un elemento <ManagedSettings> que contenga uno o más elementos <settingGroup>.

Cada elemento <settingGroup> debe contener uno o más elementos <setting>.

v Cada código <settingGroup> debe tener los siguientes atributos:

– name - Utilice el mismo nombre que el calificador (normalmente el nombre de plug-in pero

puede ser cualquiera) con el que están asociados los valores.

– lastModDate - Especifique la fecha utilizando el formato java.text.SimpleDateFormat. La

sintaxis es AAAAMMDDThhmmssZ, donde AAAA=año, MM=mes, DD=día, hh=horas, mm=minutos,

ss=segundos. Los valores situados a la derecha de la T son opcionales.

Importante:

Cada cambio efectuado en un grupo de valores debe ir acompañado por un cambio en el

atributo lastModDate o los nuevos valores no se actualizarán. Si no se especifica ningún

lastModDate, los valores se actualizan siempre, incluso aunque no sean nuevos.v Cada código <setting> debe tener los siguientes atributos:

– name - Utilice un nombre que identifique qué realiza el valor.

– value - Proporcione un valor predeterminado para el valor.v Cada código <setting> puede tener también los siguientes atributos:

– isLocked – Booleano. El valor predeterminado es true (verdadero). Si es verdadero (true), el valor

es de sólo lectura y se impedirán los cambios que un usuario o una aplicación realice en el valor

que ha establecido el administrador o bien posteriormente se sobregrabarán dichos cambios. Si

este atributo se establece en falso (false), el valor del administrador se trata como un valor

predeterminado que se puede cambiar.

– overwriteUnlocked - Booleano. El valor predeterminado es false. De forma predeterminada, un

valor que se especifica como desbloqueado se tratará como un valor predeterminado y no se

grabará encima de ningún valor existente en el cliente. Esto es para evitar deshacer cambios que

el usuario puede haber realizado de forma legítima. Sin embargo, si este valor se establece en

true, el valor desbloqueado quedará sobregrabado por este nuevo valor incluso aunque quiera

borrar el valor existente del usuario.v Por ejemplo:

<ManagedSettings>

<settingGroup name="com.ibm.workplace.mail.policy" lastModDate="20060131">

<setting name="alwaysEncryptEmail" value="true" isLocked="true"/>

<setting name="saveCopyinSentFolder" value="false" isLocked="false"/>

</settingGroup>

<settingGroup name="desktop_settings" lastModDate="20060131">

<setting name="logOffAfter" value="30" isLocked="true"/>

<setting name="autoSaveAfterNMinutes" value="5" isLocked="true"/>

</settingGroup>

</ManagedSettings>

Consulte el plug-in com.ibm.rcp.managedsetttings.provider.file para ver el esquema.2. Establezca la ubicación inicial del archivo XML en el archivo plugin_customization.ini utilizando una

clave de com.ibm.rcp.managedsettings.provider.file/URL.


Por ejemplo:

com.ibm.rcp.managedsettings.provider.file/URL=http://www.ibm.com/settings.xml

o bien

com.ibm.rcp.managedsettings.provider.file/URL=file://c:/data/mysettings.xml

Puede actualizar el archivo plugin_customization.ini en el directorio install/deploy/ de una estructura

de CD o el proporcionado con la applet/el portlet de descarga utilizando las instrucciones

proporcionadas con el mismo.

3. Si subsiguientemente desea cambiar el URL para el proveedor de archivos, puede actualizar el archivo

XML existente para añadir un nuevo grupo de valores de

com.ibm.rcp.managedsettings.provider.file y un valor de URL. La siguiente actualización se

ejecutará en el URL existente, pero después de esto la actualización se ejecutará con el nuevo URL. Si

no se puede alcanzar el nuevo URL en el momento de realizar la actualización que lo establece, éste

no se guardará y se continuará utilizando el URL original. El URL no se cambiará hasta que se

actualice en el momento en que se pueda alcanzar el URL.

Nota: Si el archivo XML está alojado en un servidor HTTP en el que se ha habilitado la autenticación

y no hay ninguna cuenta asociada configurada para el servidor, se le solicitará al usuario un

nombre y una contraseña la primera vez que se ejecute el proveedor. Dado que el proveedor se

ejecuta en el fondo, es probable que esto confunda al usuario. Puede evitar que se visualice la

solicitud de autenticación incluyendo código en la aplicación que cree una cuenta para este

URL durante la configuración. Consulte el apartado “Gestión de cuentas” en la página 111 para


Federación

Los valores gestionados permiten utilizar simultáneamente más de un proveedor.

Por ejemplo, puede especificar los valores de establecimiento para un plug-in en el gestor de políticas de

portal y para otro en el proveedor de archivos XML. Sin embargo, existe la posibilidad de definir el

mismo grupo de valores o calificador en el gestor de políticas de portal y en el archivo XML. Esta

situación, además de ambigua es eficaz. Si determina que esto está sucediendo, deberá solucionarlo lo

antes posible. Para manejar esta situación, la infraestructura fuerza que los resultados sean deterministas

utilizando el peso del proveedor para determinar qué valor se aplica. ″Gana″ el peso más bajo. Puede

determinar el peso predeterminado de los proveedores examinando el punto de extensión

ManagedSettingProvider en los archivos plugin.xml. El peso predeterminado del proveedor de archivos

se establece en 300. El peso predeterminado del proveedor de Portal es 200. Si es necesario, puede

cambiar el peso creando un valor gestionado para el mismo, utilizando un calificador de

com.ibm.rcp.managedsettings y un nombre de valor de <id_proveedor (generalmente el ID de

plug-in)>-weight.

Configuración de la planificación de actualización de valores

gestionados

La infraestructura utiliza un trabajo de fondo planificado para llamar a cada proveedor e indicarle que

recupere valores personalizados de los sistemas de fondo asociados y, a continuación, los pase a la

infraestructura para actualizar los valores almacenados en el cliente.

El mecanismo de proveedor también incluye un mecanismo para que un proveedor informe a la

infraestructura cuando tenga actualizaciones nuevas, en lugar de esperar a que transcurra el intervalo de

sondeo. Si el proveedor que está utilizando tiene esta posibilidad, no necesita preocuparse de este valor.

Ninguno de los proveedores enviados con Lotus Expeditor Client tienen esta posibilidad pero es posible

que otros proveedores la tengan.


De forma predeterminada, el trabajo de actualización planificado se ejecuta cada 720 minutos (12 horas).

Para cambiar este valor, realice una de las acciones siguientes:

v Si el Gestor de políticas de portal está llenando de datos los valores, utilice la Consola administrativa

para editar el valor de com.ibm.rcp.managedsettings/UpdateIntervalInMinutes.

v Si el proveedor de archivos está llenando de datos los valores, cree un nuevo grupo de valores

denominado com.ibm.rcp.managedsettings y un valor de UpdateIntervalInMinutes.

v Si los valores los está llenando de datos un sistema de fondo diferente, cree una nueva pareja

nombre-valor para establecer el intervalo de actualización. Utilice un calificador de

com.ibm.rcp.managedsettings y un valor de UpdateIntervalInMinutes.

Verificación de que el plug-in de valores gestionados se inicia

Para que los valores se apliquen al cliente, se debe iniciar el plug-in com.ibm.rcp.managedsettings en la

ejecución.

Si está utilizando el cliente gestionado por el portal, esto sucederá automáticamente. También sucederá

automáticamente si cualquiera de los plug-ins de la aplicación llama a cualquiera de los métodos del

plug-in de valores gestionados. Sin embargo, si está proporcionando valores de establecimiento para una

aplicación que no tiene plug-ins informados de los valores gestionados, necesitará asegurarse de que el

plug-in se inicie. Para ello, utilice uno de los plug-ins de ciclo de vida. Consulte el apartado “Gestión del

ciclo de vida” en la página 118 para obtener más información.

Configuración de la capa de red

Actualice los valores de intervalo de sondeo y proxy para configurar la capa de red en el entorno.

Si la red está inactiva, la capa de red sondeará el sistema para averiguar cuándo la red vuelve a estar

activada. El valor de preferencia de intervalo de sondeo es com.ibm.rcp.net.http/local_resource_monitor_interval.

Consulte “Gestión de preferencias de Eclipse” en la página 114 para obtener más información sobre cómo

consultar o modificar los valores de preferencias.

Nota: Si el sistema se ha conectado utilizando un emulador de dispositivo, por ejemplo VMWare, u otras

conexiones que comparten la conexión LAN o de red inalámbrica, la API Netstatus devolverá

siempre ’true’ incluso después de desconectar el cable de LAN y la conexión inalámbrica. Esto se

debe a la existencia del adaptador virtual. Si desea que se notifique a la aplicación cuando el

estado sea fuera de línea verdadero (true) (o si piensa desconectar el sistema), vaya a Inicio → Mis

sitios de red, pulse el botón derecho del ratón en Propiedades e inhabilite las conexiones

compartidas. La API Netstatus devolverá el estado correcto.

Los valores de proxy son globales, es decir, el entorno de ejecución entero comparte los mismos valores

de proxy. La conexión HTTP/HTTPS no tiene estado y utiliza los valores de proxy establecidos cuando la

aplicación abre la conexión. Los valores de proxy se definen como preferencias de eclipse en IBM Lotus

Expeditor. Para obtener información sobre cómo gestionar estas preferencias de eclipse, consulte “Gestión

de preferencias de Eclipse” en la página 114.

Se definen las preferencias de Eclipse siguientes:

com.ibm.rcp.net.http/http.ProxyHost

Indica el host de servidor proxy. El valor predeterminado de serie es nulo.

com.ibm.rcp.net.http/http.ProxyPort

Indica el puerto de servidor proxy. El valor entero predeterminado es 80.


com.ibm.rcp.net.http/http.nonProxyHosts

Indica los hosts a los que se debe conectar directamente y no mediante el servidor proxy. El valor

puede ser una lista de hosts, cada uno separado por una barra vertical (|). Por ejemplo

http.nonProxyHosts=“www.foo.com|hostlocal".

com.ibm.rcp.net.http/http.IsSecureProxy

Indica si el proxy necesita ID de usuario y contraseña. El valor predeterminado booleano es

false.

Para configurar el proxy seguro mediante programación, puede utilizar el ejemplo siguiente de

establecimiento de la preferencia com.ibm.rcp.net.http/http.IsSecureProxy:

//poner la información de proxy en preferencia

IScopeContext context = null;

IEclipsePreferences prefNode = null;

try {

context = new InstanceScope();

prefNode = context.getNode("com.ibm.rcp.net.http");

} catch (Exception ex) {

//manejar excepción

}

//poner valores de proxy en valores de preferencias

prefNode.putInt("http.ProxyPort", 80);

prefNode.put("http.ProxyHost", "myProxyHost.ibm.com");

prefNode.putBoolean("http.IsSecureProxy", true);

prefNode.put("http.nonProxyHosts", "http://localhost");

Además, debe crear una cuenta con el nombre de usuario y la contraseña para el servidor de proxy

seguro. Debe configurarse de mediante programación con los valores siguientes:

v Nombre de cuenta = PROXY.ACCOUNT

v Tipo de autenticación = PROXY.BASIC

v Nombre de usuario = nombre de usuario del servidor proxy

v Contraseña = contraseña del nombre de usuario anterior

Configuración de ejemplo:

AccountsManager accountManager = AccountsManagerFactory.getAccountsManager();

Account account = accountManager.getAccountByName("PROXY.ACCOUNT");

try {

if (account == null) {

account = new Account();

account.setProperty(Account.USER_NAME, user);

account.getLoginContext().setPassword(passwd); //guardar la contraseña

account.setName("PROXY.ACCOUNT");

account.setType("PROXY.BASIC");

accountManager.addAccount(account);

} else{

account.setProperty(Account.USER_NAME, user);

account.getLoginContext().setPassword(passwd); //guardar la contraseña

account.setName("PROXY.ACCOUNT");

account.setType("PROXY.BASIC");

accountManager.updateAccount(account);

}

} catch (AccountsException e) {

e.printStackTrace();

}

Para obtener información sobre cómo configurar valores de proxy mediante programa, consulte

Configuración de los valores de proxy para Lotus Expeditor en Desarrollo de aplicaciones para Lotus

Expeditor.


Configuración de la aplicación de navegador web

Puede configurar la aplicación de Navegador integrado con una preferencia de Eclipse definida para su

entorno. Por ejemplo, puede especificar que la página de preferencias de Navegador web no se muestre

en el diálogo de Preferencias de IBM Lotus Expeditor.

Se definen las preferencias de Eclipse siguientes:

com.ibm.rcp.ui.browser.launcher/showPreferencePage

Especifica si se debe mostrar o no la página de preferencias de Navegador web en el diálogo de

Preferencias de IBM Lotus Expeditor. El valor booleano predeterminado es true.

com.ibm.rcp.ui.browser.launcher/allowUserDefinedHomePage

Especifica si se debe mostrar o no la interfaz de usuario ″establecer página de presentación″ en la

página de preferencias de Navegador web. El valor booleano predeterminado es true.

com.ibm.rcp.ui.browser.launcher/adminHomePage

Indica la página de presentación establecida por el administrador. El valor de serie

predeterminado es “about:blank”.

com.ibm.rcp.ui.browser.launcher/enableApplet

Especifica si se debe habilitar o no el soporte de applets Java2. El valor predeterminado booleano

es true.

Consulte Gestión de preferencias de Eclipse para obtener más información sobre cómo consultar o

modificar los valores de preferencias.

Configuración de la sincronización de plataforma

Utilice la plataforma de Lotus Expeditor Client para gestionar y configurar la sincronización.

La página Sincronización proporciona a los usuarios la posibilidad de ver rápidamente todas las

aplicaciones sincronizables con el estado de sincronización. Cada aplicación sincronizable se visualiza en

una fila con el nombre, el estado activado o desactivado, la prioridad, la hora de la última ejecución, el

ámbito, el resumen, el servidor y el estado. Esta página también proporciona a los usuarios la posibilidad

de iniciar y detener la sincronización, así como un modo rápido de establecer planificaciones de

sincronización y opciones específicas de aplicación.

La página Planificaciones de sincronización es el diálogo de preferencias de plataforma. Proporciona a los

usuarios la posibilidad de establecer dos conjuntos de planificaciones para aplicaciones de prioridad

normal y alta, respectivamente. También proporciona los valores de desencadenantes de la sincronización

aplicados a todas las aplicaciones sincronizables.

Debe satisfacer estos prerrequisitos para la sincronización:

v Un servidor de Portal disponible se configura correctamente en las preferencias de plataforma (consulte

“Gestión de clientes ricos utilizando el servidor de Portal” en la página 223).

v La plataforma se establece en online.

Habilitación de la sincronización y cambio de prioridad

Si se instala una aplicación que se puede sincronizar, puede abrir la página Sincronización desde el

iniciador para habilitar o inhabilitar la sincronización o cambiar la prioridad de una aplicación.

Pulse el recuadro de selección bajo la columna Habilitada para una aplicación a fin de habilitar o

inhabilitar la sincronización de la misma.


|

|||

|

|||

|||

|||

|||

||

Pulse el recuadro de selección bajo la columna Prioridad alta para una aplicación a fin de cambiar entre

Prioridad alta y Prioridad normal para una aplicación. También puede realizarlo pulsando el botón

derecho del ratón en la aplicación y seleccionando (o deseleccionando) Utilizar la planificación de

prioridad alta para esta aplicación.

Nota: La sincronización no se presenta como una opción en el iniciador cuando no hay elementos a

sincronizar. Habrá elementos a sincronizar cuando haya un servidor de Portal disponible que esté

configurado correctamente en las preferencias de plataforma.

Configuración de planificaciones y desencadenantes de sincronización

automática

Abra el diálogo de preferencias de plataforma y pulse la página Sincronización para configurar las

planificaciones y los desencadenantes de sincronización automática.

Puede seleccionar y deseleccionar los recuadros por separado para habilitar e inhabilitar las

planificaciones y los desencadenantes siguientes:

v Planificación de sincronización de prioridad normal

v Planificación de sincronización de prioridad alta

v Desencadenante Sincronizar cuando inicie el cliente

v Desencadenante Sincronizar cuando me conecte después de haberme desconectado

v Desencadenante Sincronizar cuando me desconecte

v Desencadenante Sincronizar cuando cierre el cliente

Seleccione Preguntar para que se visualice una solicitud de diálogo de confirmación antes de que la

plataforma realice la sincronización. También puede personalizar las planificaciones cambiando los

valores de horas, el valor de repetición y los valores de días de la semana.

Configuración de la seguridad de plataforma

La plataforma de cliente de escritorio puede utilizar la VM (Virtual Machine - Máquina virtual) IBM J9

que implementa las especificaciones Java con las bibliotecas de clase jclDesktop o la VM IBM J9 con las

bibliotecas de clase Java 2 SE 5.0. Las opciones de configuración de seguridad son diferentes en función

de la VM que se utilice.

Lotus Expeditor Client instala la J9 con jclDesktop como la VM predeterminada y Java 2 SE 5.0 se puede

instalar posteriormente. Otros productos que utilizan esta plataforma pueden suministrar sólo Java 2 SE

5.0 y no jclDesktop.

Al utilizar Lotus Expeditor Client en los dispositivos, DB2e puede usar SSL mientras se sincroniza con un

servidor especificando https en el URL de conexión.

Consulte el siguiente URL para obtener información sobre las posibilidades de seguridad de la VM en

Windows:

http://www-128.ibm.com/developerworks/java/jdk/security/50/secguides/securityguide.win32.html

Consulte el siguiente URL para obtener información sobre las posibilidades de seguridad de la VM en

Linux:

http://www-128.ibm.com/developerworks/java/jdk/security/50/secguides/securityguide.lnx.html

El siguiente URL es la página de índice para obtener información sobre los aspectos de seguridad de la

VM IBM J2SE 5:




http://www-128.ibm.com/developerworks/java/jdk/security/50/secguides/securityguide.lnx.html


El uso de JCE en la plataforma sigue los patrones estándar del uso de JCE.

Puesto que la plataforma usa varios mecanismos de comunicación de entrada y salida, en función del

tipo de comunicación necesario deben llevarse a cabo pasos de configuración específicos para configurar

JSSE para que admita comunicaciones SSL. Consulte la sección apropiada para el mecanismo de

comunicación que desee.

Lotus Expeditor Client no soporta el uso de la seguridad de Java 2 para otorgar o evitar el acceso de

código basado en identidad.

Configuración para jclDesktop

Se proporcionan los cifrados siguientes utilizando JCE en jclDesktop:

v AES

v DES

v DESede

v Blowfish

v PBEWithMD5andTripleDES

v PBEWithMD5andDES

Se soportan los siguientes suites de cifrado para las conexiones SSL:

v SSL_RSA_WITH_3DES_EDE_CBC_SHA

v SSL_RSA_WTH_DES_CBC_SHA

v SSL_RSA_EXPORT_WITH_DES40_CBD_SHA

v SSL_RSA_WITH_NULL_SHA

v SSL_RSA_WITH_NULL_MD5

v TLS_RSA_WITH_AES_128_CBC_SHA

El componente JAAS proporciona un medio para la autenticación y la autorización basadas en principal.

La herramienta de claves jclDesktop sólo puede utilizarse para crear/operar en almacenes de claves JKS.

No puede utilizarse para crear almacenes de claves JCEKS. Actualmente, los almacenes de claves JCEKS

no están soportados en jclDesktop.

jclDesktop contiene algunos certificados precargados en el archivo lib\security\cacerts. Este archivo se

carga previamente con diversas CA de raíz y se utiliza para la validación de certificados de servidor SSL,

la verificación de jar firmada y la verificación de midlet.

Conmutación de jclDesktop a J2SE

Consulte “Cambio a una biblioteca de clases y entorno de ejecución diferente” en la página 45 para

obtener información sobre cómo conmutar de jclDesktop a J2SE.

Consideraciones sobre los almacenes de claves al conmutar entre las VM

Los archivos de almacén de claves creados por la VM Java 2 SE 5.0 no son compatibles con jclDesktop.

Del mismo modo, los archivos de almacén de claves creados con jclDesktop no son compatibles con Java

2 SE 5.0. Por esta razón, IBM Lotus Expeditor mantendrá un archivo de almacén de claves por VM.

Debido a esto, al conmutar entre las VM, debe restablecer todas las contraseñas que se han almacenado

en el almacén de claves y la propia contraseña de almacén de claves. Ninguno de los datos almacenados

en un archivo de almacén de claves de la VM se transferirá al archivo de almacén de claves de la otra

VM. Es importante tener en cuenta que es posible tener dos conjuntos completamente diferentes de

credenciales almacenados; uno accesible sólo en jclDesktop y otro accesible sólo en Java 2 SE 5.0.


Especificación de la configuración de inicio de sesión de plataforma

predeterminada

Una configuración de inicio de sesión indica a la aplicación qué LoginModule debe utilizar para

autenticar a los usuarios. Un LoginModule describe la interfaz implementada por los proveedores de

tecnología de autenticación.

Lotus Expeditor Client define una configuración predeterminada que se deberá utilizar si la aplicación no

define ninguna configuración alternativa.

También proporciona las siguientes configuraciones de inicio de sesión de plataforma que puede utilizar:

v SSO-KS - Apila SSOLoginModule encima de la clase KeyStoreLoginModule para soportar el inicio de

sesión único en el almacén de claves.

Siga estos pasos para especificar otras configuraciones de inicio de sesión:

En el archivo plugin_customization.ini del directorio <dir_instalación>/rcp, establezca el valor para la

siguiente preferencia:

v com.ibm.rcp.security.auth/loginConfigName – Especifica el nombre de la Configuración a utilizar de

forma predeterminada al realizar un inicio de sesión de plataforma utilizando el método

ILoginContext.login(). El valor predeterminado para Lotus Expeditor es SSO-KS.

Por ejemplo:

com.ibm.rcp.security.auth/loginConfigName=SSO-KS

Configuración de SSL para la plataforma - 6.1.1

Si necesita utilizar un SSL (Secure Sockets Layer - Capa de sockets seguros) con un certificado de prueba

autofirmado o un certificado que no tenga un certificado raíz incluido en el almacén de claves de gestor

predeterminado, debe importar el certificado al almacén de claves de gestor de confianza

predeterminado.

Expeditor tiene el almacén de claves de gestor de confianza predeterminado preconfigurado para que sea

el archivo \jre\lib\security\cacerts, que se instala con la máquina virtual (VM) que implementa las

especificaciones Java.

Exporte el certificado del keyStore del servidor e impórtelo al almacén de claves JRE (utilizado por el

gestor de confianza predeterminado de Expeditor):

1. Para exportar un certificado desde otro almacén de claves, abra una ventana de indicador de

mandatos y vaya al directorio <dir_instalación>\rcp\eclipse\plugins\<jre_ejecutable>\jre\lib\security.

Utilice el programa de utilidad de línea de mandatos keytool para exportar el certificado. Para ello,

escriba ..\..\bin\keytool -export -alias <alias> -keystore <archivo de almacén de claves> -file

<archivo de certificado>.cer para generar un archivo de certificado. Para obtener más información

sobre la gestión de almacenes de claves, consulte la documentación de VM acerca de keytool de java.

2. Importe el certificado que ha generado escribiendo ..\..\bin\keytool -import -trustcacerts -alias

<alias> -keystore cacerts -file <nombre_archivo> donde <nombre_archivo> es la vía de acceso

absoluta del certificado creado anteriormente.

Por omisión, VM de Expeditor está configurado para dar soporte a SSL utilizando el archivo de almacén

de claves cacerts de VM. Para volver a configurar la configuración predeterminada, establezca las

propiedades de sistema siguientes. Consulte “Configuración de propiedades de sistema Java” en la

página 47 para obtener información sobre cómo establecer las propiedades.

Las propiedades que pueden especificarse para el cliente son:


-Djavax.net.ssl.keyStore=<vía_acceso_a_archivo_de_almacén_de_claves>

-Djavax.net.ssl.keyStoreType=<tipo_almacén_de_claves>

-Djavax.net.ssl.keyStorePassword=<contraseña_almacén_de_claves>

-Djavax.net.ssl.trustStore=<vía_acceso_a_archivo_almacén_de_confianza>

-Djavax.net.ssl.trustStoreType=<tipo_almacén_de_confianza>

-Djavax.net.ssl.trustStorePassword=<contraseña_almacén_de_confianza>

Para obtener más información sobre cómo establecer estas propiedades y cómo configurar SSL para la

VM, consulte el siguiente URL:

http://www-128.ibm.com/developerworks/java/jdk/security/50/

Configuración de SSL para la plataforma 6.1.2

Si necesita utilizar un SSL (Secure Sockets Layer - Capa de sockets seguros) con un certificado de prueba

autofirmado o un certificado que no tenga un certificado raíz incluido en el almacén de claves de gestor

predeterminado, se le solicitará, denegará o permitirá, según cómo configure el valor de preferencias

gestionadas para com.ibm.rcp.security.jceproxy/ssl.unknowncert.action.

Hay tres valores posibles:

ALLOW

Pasar la conexión SSL para sitios con certificados no de confianza.

DENY

No pasar la conexión SSL para sitios con certificados no de confianza.

PROMPT

Si Expeditor se está ejecutando en modalidad sin interfaz de usuario, PROMPT es igual a DENY. Si

Lotus Expeditor se está ejecutando con la interfaz de usuario habilitada, se le ofrecen al usuario las

opciones siguientes:

1. No confiar en este certificado o en su autoridad de certificación. Detener la operación actual.

2. Confiar en este certificado sólo para esta sesión.

3. Confiar en este certificado.

El valor predeterminado es PROMPT. Para cambiar este valor, debe cambiar el valor de la preferencia

com.ibm.rcp.security.jceproxy/ssl.unknowncert.action de Eclipse. Consulte “Gestión de preferencias

de Eclipse” en la página 114 para obtener información sobre el establecimiento de preferencias.

Trustmanager de Lotus Expeditor está configurado, por omisión, para dar soporte a SSL utilizando el

archivo de almacén de claves cacerts de VM. Adicionalmente, Trustmanager busca en el almacén de

claves de la plataforma. Para volver a configurar la configuración predeterminada, establezca las

propiedades de sistema siguientes. Consulte “Configuración de propiedades de sistema Java” en la

página 47 para obtener información sobre cómo establecer las propiedades.

Las propiedades que pueden especificarse para el cliente son:

-Djavax.net.ssl.keyStore=vía_acceso_a_archivo_de_almacén_de_claves

-Djavax.net.ssl.keyStoreType=tipo_almacén_de_claves

-Djavax.net.ssl.keyStorePassword=contraseña_almacén_de_claves

-Djavax.net.ssl.trustStore=vía_acceso_a_archivo_almacén_de_confianza

-Djavax.net.ssl.trustStoreType=tipo_almacén_de_confianza

-Djavax.net.ssl.trustStorePassword=contraseña_almacén_de_confianza

Para obtener más información sobre cómo establecer estas propiedades y cómo configurar SSL para la

VM, consulte el siguiente URL:

http://www.ibm.com/developerworks/java/jdk/security/50/


|

||||

|

||

||

||||

|

|

|

|||

|||||

|

||||||

||

|

http://www-128.ibm.com/developerworks/java/jdk/security/50/

http://www.ibm.com/developerworks/java/jdk/security/50/

Configuración de SSL para el Agente de gestión de empresa

Las conexiones SSL (Secure Sockets Layer - Capa de sockets seguros) se basan en la existencia de

certificados digitales para realizar intercambios seguros de datos entre servidores y clientes. En Lotus

Expeditor, el Agente de gestión de empresa da soporte tanto a las conexiones normales como SSL entre el

cliente y un Expeditor Server. Le recomendamos que adquiera certificados comerciales para los que ya

hay disponibles certificados de clave pública en los dispositivos cliente. De esta manera simplificará

mucho el uso de conexiones seguras, ya que los nuevos certificados no tienen que desplegarse en los

clientes. Sin embargo, también puede utilizar los certificados autofirmados que cree. Los procedimientos

para desplegar certificados en sistemas de escritorio y en dispositivos son distintos.

Configuración para el escritorio

El Agente de gestión de empresa espera que se proporcione el certificado de servidor para la

comunicación SSL. Para obtener instrucciones sobre cómo crear el certificado, consulte la documentación

del servidor Device Manager.

Nota: Al crear el certificado, el valor para el campo de nombre común (cn= valor) debe coincidir con la

dirección del servidor que el Agente de gestión de empresa utiliza para conectarse con el servidor

Device Manager.

El Agente de gestión de empresa busca en tres ubicaciones el archivo de certificado y acepta la primera

ubicación disponible. El Agente de gestión de empresa busca las tres ubicaciones de certificado en el

orden siguiente:

1. Un archivo con el nombre y la vía de acceso especificados en Config Admin (CM), que se pueden

personalizar totalmente con un trabajo del servidor Device Manager.

2. Un archivo denominado agentServerCert.arm en la vía de acceso especificada por la propiedad del

sistema user.home.

3. Un archivo denominado agentServerCert.arm en la vía de acceso especificada por el directorio en el

que está trabajando, ″./″.

Si el Agente de gestión de empresa encuentra un archivo en las ubicaciones 2 o 3, establecerá la

propiedad de la ubicación CM para dicha ubicación.

La configuración de SSL se puede gestionar con los trabajos Descubrimiento de nodo y Mandato

personalizado del servidor Device Manager. La nota base desde la que debe realizarse el descubrimiento

es ./OSGi con una profundidad de 4.

Los nodos que pueden gestionarse del paquete SSL Enabler son:

v com.ibm.pvc.osgiagent.protocol.agentadaptor.https: OSGi SERVICE.PID que identifica la

implementación del adaptador HTTPS.

v SSLEnabler.certloc - vía de acceso de archivo de almacén de confianza

v SSLEnabler.mode: modo de seguridad. Los valores posibles son trustall o certificates.

Estableciendo el modo de SSL en trustall, el cliente ignora los certificados y confía en todas las

conexiones HTTPS. Esto no significa necesariamente que el servidor confiará en el cliente. Sólo se puede

configurar el servidor para que confíe en el cliente a través del servidor Device Manager.

Configuración para dispositivos

Aunque los pasos de instalación son distintos para las diversas plataformas de dispositivo, debería poder

utilizar el mismo certificado para dar soporte a todas las plataformas.

Configuración SSL para Windows Mobile 2003 SE / 5.0, Windows CE 5.0


|

Debe crear un certificado y desplegarlo tanto en los servidores como en los clientes.

1. Para obtener instrucciones sobre la creación de certificados, consulte Obtención de un certificado en

Utilización de Lotus Expeditor Server y utilización de la herramienta ikeyman (IBM Key Management

Utility).

Nota:

v Al crear el certificado, el valor para el campo de nombre común (cn= valor) debe coincidir

con la dirección del servidor que el Agente de gestión de empresa utiliza para conectarse con

el servidor Device Manager.

v Asegúrese de que las fechas para las que es válido el certificado sean correctas.2. Para configurar Expeditor Server para comunicaciones SSL, consulte Configuración de Device

Manager para SSL y Protección de Lotus Expeditor Server para SSL en Utilización de Lotus Expeditor

Server.

3. Debe distribuir a los dispositivos cliente el certificado creado por ikeyman. Utilice keytool.exe de

Expeditor Client para escritorio para importar el certificado a un archivo cacerts que, a continuación,

puede distribuirse a los clientes. Este archivo sustituye el archivo existente en la carpeta

\eclipse\plugins\com.ibm.pvc.wece.device.win32.arm_6.1.2.0-<fecha>\jre\lib\security, por lo que

debe manejarse el archivo de manera que no destruya ningún certificado desplegado anteriormente.

4. Una vez se ha desplegado el certificado en el cliente, el usuario puede abrir las preferencias de

Application Manager, seleccionar la opción HTTPS y rellenar la información de cuenta

correspondiente.

5. El usuario puede pulsar el botón Probar la conexión para asegurarse de que la información entrada

es correcta y pulsar Mandato → Aceptar para conectar con el servidor Device Manager.

Configuración de SSL para Nokia E90

Nokia E90 sólo da soporte al formato de certificado X.509 versión 1 y al formato extraído PKCS (.p12).

Debería tener esto en cuenta cuando genera un certificado que debe funcionar en todas las plataformas

soportadas.



1. Debe generar un par de claves privadas que tengan el formato X.509 versión 1 y extraerlo como .arm

para otras plataformas, y en formato .p12 sólo para el E90.

2. Consulte Configuración de Device Manager para SSL en Utilización de Lotus Expeditor Server para

configurar Expeditor Server para utilizar comunicaciones SSL.

3. Nokia E90 no da soporte al formato PKCS (.p12) generado directamente por la herramienta IBM

ikeyman. Un procedimiento alternativo es tomar el certificado PKCS extraído generado por ikeyman

y, a continuación, utilizar una herramienta de otra empresa, como Open SSL o el navegador Firefox

2.0, para transformar el certificado al formato soportado por Nokia.

Nota: El PKCS (.p12) soportado de Nokia es pkcs8-shrounded-key-bag (keybag cifrada) con

1.2.840.113549.1.12.10.1.2.

4. Ponga el certificado PKCS en una tarjeta de almacenamiento y ábralo en el dispositivo o sitúe la

búsqueda de certificado en él utilizando el navegador web de Nokia y selecciónelo. Entre la

contraseña de certificado. Asegúrese de que no se produce ningún error al instalarlo.

5. Una vez se ha desplegado el certificado en el cliente, el usuario puede abrir eRCP App

MgrPreferences, seleccionar la opción HTTPS y rellenar la información de cuenta correspondiente.

6. El usuario puede pulsar el botón Probar la conexión para asegurarse de que la información entrada

es correcta y pulsar Mandato → Aceptar para conectar con el servidor Device Manager.


Configuración del soporte SSL del lado del cliente

Para acceder a un servidor que requiere autenticación de certificados de cliente para conexiones SSL, el

almacén de claves del cliente de Expeditor debe contener un certificado personal firmado por una

entidad emisora que el servidor considere de confianza.

El certificado autofirmado del cliente debe estar en el almacén de claves de la plataforma, el almacén de

claves JRE o en otro almacén de claves que se especifique con propiedades del sistema durante la

ejecución:

v javax.net.ssl.keyStore

v javax.net.ssl.keyStorePassword

v javax.net.ssl.keyStoreType

El almacén de claves de la plataforma se encuentra en el espacio de trabajo del cliente de Expeditor una

vez que se ha inicializado el cliente. La contraseña para este almacén de claves es la versión codificada en

Base64 de la contraseña que utiliza para iniciar la sesión en el cliente. El almacén de claves de la

plataforma que se crea en el entorno jclDesktop no es compatible con el almacén de claves de la

plataforma que se crea en el entorno J2SE. Se recomienda acceder al almacén de claves de la plataforma

mediante programación. Puede encontrar más información sobre cómo acceder mediante programación al

almacén de claves de la plataforma en la documentación Desarrollo de aplicaciones para Lotus Expeditor.

El almacén de claves JRE se encuentra en <dir_inicial_java>/lib/security/cacerts, con una contraseña

predeterminada de ″changeit″.

Configuración de SSL para Servicios Web

Si piensa ejecutar aplicaciones de Servicios Web que se conectan a Servicios Web ubicados detrás de un

URL seguro, por ejemplo HTTPS, debe configurar Lotus Expeditor Client con una configuración

predeterminada apropiada.

El entorno de ejecución de Servicios Web no proporciona ninguna capacidad de configuración específica

de SSL y se basa en los valores predeterminados de la plataforma.

Consulte “Configuración de SSL para la plataforma - 6.1.1” en la página 88 para obtener más

información.

Consulte “Configuración de SSL para la plataforma 6.1.2” en la página 89 para obtener más

información.

Configuración de SSL para el contenedor web

Este apartado describe cómo configurar SSL para el contenedor web

Al utilizar Lotus Expeditor Client en el escritorio, realice los pasos siguientes para permitir que el

contenedor web atienda las peticiones utilizando un socket seguro:

Nota: El cliente debe estar ejecutando la VM J2SE (y no jclDesktop) para el soporte SSL. Para conmutar,

consulte “Cambio a una biblioteca de clases y entorno de ejecución diferente” en la página 45.

1. Configure el contenedor web.

a. Cree un archivo de configuración SSL y defina las propiedades siguientes.


Tabla 13. Propiedades de configuración de SSL

Propiedad Valor Opcional/obligatoria Descripción

com.ibm.ssl.protocol SSL [valor

predeterminado], SSLv3,

TLS, TLSv1

Opcional Especifica el protocolo

que debe utilizarse.

com.ibm.ssl.keyStoreType SSO-KS [valor

predeterminado], PKCS12

Opcional Especifica el tipo de

almacén de claves que

debe utilizarse.

com.ibm.ssl.keyStore Vía de acceso absoluta o

relativa al archivo en el

sistema de archivos. Si se

especifica la vía de acceso

relativa, la vía de acceso

debe ser relativa al

directorio de trabajo

actual.

Obligatoria Especifica la ubicación

del almacén de claves en

el sistema de archivos.

com.ibm.ssl.trustStoreType SSO-KS [valor

predeterminado], PKCS12

Opcional Especifica el tipo de

almacén de confianza.

com.ibm.ssl.trustStore Vía de acceso absoluta o

relativa al archivo en el

sistema de archivos. Si se

especifica la vía de acceso

relativa, la vía de acceso

debe ser relativa al

directorio de trabajo

actual.

Obligatoria Especifica la ubicación

del almacén de confianza

en el sistema de archivos.

com.ibm.ssl.keyStorePassword Contraseña de texto

plano para el almacén de

claves.

Obligatoria Especifica la contraseña

para abrir el almacén de

claves.

com.ibm.ssl.trustStorePassword Contraseña de texto

plano para el almacén de

confianza.

Obligatoria Especifica la contraseña

para abrir el almacén de

confianza.

com.ibm.ssl.clientAuthentication true | false Obligatoria Especifica si la aplicación

cliente requiere

autenticación. El valor

predeterminado es False.

b. Establezca la propiedad del sistema com.ibm.pvc.webcontainer.ssl.configfile para que apunte al

archivo de configuración SSL creado en el paso (a).

c. Establezca el puerto HTTPS utilizando ConfigurationAdmin o utilizando la propiedad de sistema

com.ibm.pvc.webcontainer.port.secure.

Nota: El contenedor web sólo protegerá las peticiones si se ha establecido el puerto HTTPS y se

proporciona el archivo de configuración SSL al contenedor web. Si el puerto no se ha

establecido, el contenedor web ejecutará de forma predeterminada las peticiones en el

puerto HTTP.

Ejemplo: Si la propiedad del sistema se establece en 9000, el archivo de configuración SSL tendrá

este aspecto:

com.ibm.ssl.clientAuthentication.9000=true

com.ibm.ssl.trustStorePassword.9000=[xor] /s+47mLdxPk\=

com.ibm.ssl.keyStorePassword.9000=[xor] /s+47mLdxPk\=

com.ibm.ssl.trustStore.9000=../sampleTrust1.jks

com.ibm.ssl.keyStore.9000=../sampleKeys1.jks


Ejemplo: Si la propiedad del sistema com.ibm.pvc.webcontainer.port.secure se establece en

9000 y ha definido un canal SSL SSL_TEST utilizando las extensiones de Infraestructura de canales

o propiedades del sistema, el archivo de configuración SSL tendrá este aspecto:

com.ibm.ssl.clientAuthentication.9000=true

com.ibm.ssl.trustStorePassword.9000=password

com.ibm.ssl.keyStorePassword.9000=password

com.ibm.ssl.trustStore.9000=../sampleTrust1.jks

com.ibm.ssl.keyStore.9000=../sampleKeys1.jks

com.ibm.ssl.clientAuthentication.SSL_TEST=true

com.ibm.ssl.trustStorePassword.SSL_TEST=password

com.ibm.ssl.keyStorePassword.SSL_TEST=password

com.ibm.ssl.trustStore.SSL_TEST=../sampleTrust1.jks

com.ibm.ssl.keyStore.SSL_TEST=../sampleKeys1.jks

Nota: El transporte y el canal seguros están configurados ambos para utilizar los mismos archivos

de almacén de claves y almacén de confianza que los de este ejemplo. La contraseña para

estos dos archivos es ’password’.2. Cree los repositorios externos de almacén de claves y almacén de confianza:

a. Utilice iKeyman o el programa de utilidad de línea de mandatos keytool (se incluye con el JDK)

para crear los archivos de almacén de claves y almacén de confianza. La ubicación de estos

archivos se especifica mediante el archivo de configuración de SSL.

b. Utilice iKeyman o el programa de utilidad de línea de mandatos keytool para generar entradas de

clave y certificados y almacenarlos en los archivos de almacén de claves y almacén de confianza.3. Exporte e importe el certificado:

Nota: Este paso sólo se deberá realizar si las aplicaciones web desplegadas en el contenedor web van

a utilizar la clase HttpsURLConnection.

a. Utilice el programa de utilidad de línea de mandatos keytool para crear un certificado

autofirmado para el servidor (por ejemplo hostlocal). Para ello, abra una ventana de indicador de

mandatos y cambie al directorio donde tiene el archivo de claves (por ejemplo c:\temp\ para el

archivo trustkey.jks). A continuación, escriba keytool -export -alias server -keystore trustkey.jks

-file server.cer para generar un archivo server.cer.

b. Exporte el certificado de servidor del almacén de claves de contenedor web e impórtelo al almacén

de claves JRE (utilizado por el manejador de URL de Lotus Expeditor Client) en:

$Expeditor_INSTALL_DIR\rcp\eclipse\plugins\$runtime_jre\jre\lib\security\cacerts

$runtime_jre puede ser uno de los siguientes:

com.ibm.rcp.j2se.win32.x861.5.0.SR2-aaaammdd

com.ibm.rcp.j2se.linux.x861.5.0.SR2-aaaammdd

donde aaaammdd es el año, el mes y el día.

Para exportar el certificado de servidor, vaya al directorio <dir_instalación>\rcp\eclipse\plugins\<dir_jre_entorno_ejecución>\jre\lib\security. Importe el certificado que ha generado

escribiendo keytool -import -trustcacerts -alias server -keystore cacerts -file <nombrearchivo>

donde <nombrearchivo> es la vía de acceso absoluta al certificado de servidor creado en el paso

3b.

Cuando el contenedor web se configura para habilitar el soporte de SSL, el contenedor web suprimirá el

archivo de configuración SSL y almacenará la configuración en un archivo webcontainer.properties (las

contraseñas están cifradas) del directorio de configuración del usuario.

Configuración de SSL para ISync

La tecnología DB2 Everyplace Sync (ISync) permite utilizar SSL para conectar del cliente al servidor DB2

Everyplace Sync, a condición de que el cliente y el servidor estén habilitados para SSL en una

configuración compatible.


Cuando se utiliza la implementación pura de ISync Java de IBM Apache Derby, no hay pasos de

configuración SSL específicos de ISync necesarios. El proveedor de ISync de IBM Apache Derby Java

supone que la plataforma de cliente ya se ha configurado para soportar las conexiones de salida SSL.

Consulte “Configuración de SSL para la plataforma - 6.1.1” en la página 88 para obtener información

sobre la configuración de SSL.

Consulte “Configuración de SSL para la plataforma 6.1.2” en la página 89 para obtener más

información.

Los valores de isync.encoding de ASCII, UTF-8 o UTF8 para la configuración de página de códigos de

sincronización de Apache Derby no se soportan cuando se utiliza el entorno de ejecución Java

JCLDesktop. Si no se establece la propiedad isync.encoding, se utilizará la página de códigos

predeterminada para la plataforma de cliente y ésta funcionará como se espera. Si se debe utilizar la

codificación UTF-8 o ASCII, se necesitará el entorno de ejecución Java 5.

Cuando se utiliza la implementación de sincronización y de base de datos nativa de DB2 Everyplace, se

necesitan algunas tareas específicas de sistema operativo a fin de preparar el cliente para la

sincronización con el servidor de sincronización DB2 Everyplace. Consulte Secure Sockets Layer (Capa de

sockets seguros) y dispositivos móviles de DB2 Everyplace en el centro de información de DB2

Everyplace.

Utilización de SSL desde las aplicaciones

Este apartado describe cómo utilizar de SSL desde las aplicaciones, específicamente cómo crear

conexiones SSL a los servidores y cómo crear sockets SSL desde las conexiones de entrada.

Creación de conexiones SSL con los servidores

La configuración de plataforma predeterminada para SSL para crear conexiones con los servidores se

gestiona tal como se describe en la sección siguiente:

v “Configuración de SSL para la plataforma - 6.1.1” en la página 88

v “Configuración de SSL para la plataforma 6.1.2” en la página 89

.

Las aplicaciones que deben crear sus propias conexiones SSL con un servidor pueden utilizar la misma

configuración de plataforma.

Para crear un nuevo URL, las aplicaciones sólo deben especificar HTTPS como protocolo y luego se

creará el objeto HttpsUrlConnection. Las aplicaciones deben basarse en la configuración predeterminada o

configurar la configuración de seguridad para cada instancia. Cambiar la configuración predeterminada

puede tener efectos negativos en otras aplicaciones que se ejecuten en la plataforma y en las capacidades

de conexión de los componentes que se proporcionan con la plataforma.

Creación de sockets SSL para conexiones entrantes

La SSLServerSocketFactory predeterminada que proporciona SSLServerSockets se basa en los valores

proporcionados en el archivo java.security para la plataforma. Consulte los artículos que se indican en

“Configuración de la seguridad de plataforma” en la página 86 para obtener más información sobre

cuándo y cómo actualizar este archivo. Las aplicaciones deben basarse en la configuración

predeterminada.

Las aplicaciones que intenten abrir SSLServerSockets para su propio uso deben tener en cuenta que es

posible que el componente de contenedor Web de la plataforma también intente abrir sockets de servidor


http://publib.boulder.ibm.com/infocenter/db2e/v9r1/topic/com.ibm.db2e.doc/configure_ssl.html

http://publib.boulder.ibm.com/infocenter/db2e/v9r1/topic/com.ibm.db2e.doc/configure_ssl.html

SSL. Cambiar la configuración predeterminada puede tener efectos negativos en otros componentes

proporcionados con la plataforma.

Habilitación de los proveedores JCE y JSSE compatibles con FIPS

En esta sección se describe cómo habilitar los proveedores JCE y JSSE compatibles con los estándares

FIPS (Federal Information Processing Standards).

Debe conmutar a J2SE para ejecutar FIPS. Para poder habilitar el uso de proveedores JCE y JSSE

compatibles con FIPS, es necesario actualizar el archivo de configuración java.security.

El archivo de configuración java.security está contenido en los directorios siguientes:

Para J2SE en Windows:

dir_instalación\rcp\eclipse\plugins\com.ibm.rcp.j2se.win32.x86_1.5.0.versión\jre\lib\security

Para J2SE en Linux

dir_instalación/rcp/eclipse/plugins/com.ibm.rcp.j2se.linux.x86_1.5.0.versión/jre/lib/security

Consulte http://www-128.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html para obtener

más información sobre la habilitación de proveedores compatibles con FIPS.

Configuración de la ayuda de plataforma

Basándose en los requisitos del producto, puede eliminar completamente el menú Ayuda o eliminar los

elementos de menú Contenido de la ayuda y Acerca de bajo Ayuda utilizando actividades.

Para eliminar completamente el menú Ayuda, utilice la siguientes actividad:

<extension point="org.eclipse.ui.activities">

<activity id="activity.help.menu" name="hideHelpMenu" />

<activityPatternBinding activityId="activity.help.menu"

pattern="com\.ibm\.rcp\.platform\.personality/help" />

</extension>

Para eliminar el elemento de menú Contenido de la ayuda bajo Ayuda:


<activity id="activity.help.contents" name="hideHelpContents" />

<activityPatternBinding activityId="activity.help.contents"

pattern="com\.ibm\.rcp\.platform\.personality/helpContents" />

</extension>

Para eliminar el diálogo Acerca de:


<activity id="activity.help.about" name="hideHelpAbout" />

<activityPatternBinding activityId="activity.help.about"

pattern="com\.ibm\.rcp\.platform\.personality/about" />

</extension>

Configuración de la barra lateral de Lotus Expeditor

Utilice la barra lateral para realizar tareas en otras aplicaciones en el lado derecho o izquierdo, sin

perturbar el trabajo en la aplicación actual.

La barra lateral está situada en el lado derecho o izquierdo de la ventana de cliente y contiene uno o más

paneles que corresponden a las aplicaciones instaladas. Para obtener más información sobre, consulte

Barra lateral en Desarrollo de aplicaciones para Lotus Expeditor.


http://www-128.ibm.com/developerworks/java/jdk/security/50/FIPShowto.html

Inhabilitación de menús y de elementos de menú

Se pueden utilizar actividades de Eclipse (que se definen mediante la extensión org.eclipse.ui.activities)

para ocultar menús y elementos de menú añadidos como contribuciones.

Al definir una actividad, se asocia un menú o elemento de menú con la actividad, y a no ser que la

actividad esté habilitada, el menú o elemento de menú no se visualizará. Para definir la actividad,

necesitará saber el patrón que corresponderá al menú o elemento de menú deseado. En la sección Menús

de nivel superior de Lotus Expeditor de Desarrollo de aplicaciones para Lotus Expeditor se proporciona

una tabla que lista los menús y elementos de menú que son contribuciones de Expeditor.

Por ejemplo, para ocultar la acción de menú Archivo > Aplicación > Restablecer, primero localice el

patrón correcto en la tabla y luego defina una extensión que incluya el patrón:


<activity id="activity.reset.menu" name="hideReset"/>

<activityPatternBinding activityId="activity.reset.menu"

pattern="com\.ibm\.rcp\.platform\.personality/resetPerspective"/>

</extension>

Puede utilizar la misma estrategia para inhabilitar otros menús y elementos de menú en Expeditor,

especificando el patrón apropiado para ese elemento. Por ejemplo, para eliminar el menú Archivo (File),

utilice pattern="com\.ibm\.rcp\.platform\.personality/file". Para obtener los ID apropiados a utilizar

en el patrón, consulte IMenuConstants.java en el javadoc de interfaz de usuario e infraestructura de

personalidad.

Modificación de los archivos de configuración de la plataforma

La plataforma de cliente contiene varios archivos de configuración que pueden necesitar actualizaciones

para desplegar y ejecutar las aplicaciones de forma satisfactoria.

Se pueden utilizar las opciones siguientes para modificar los archivos de propiedades:

v Las características que se despliegan en una plataforma de cliente pueden contener código que se

ejecute para realizar tareas durante el ciclo de vida de una característica. Este código se conoce como

manejador de instalación. Puede utilizar un manejador de instalador global proporcionado por la

plataforma de cliente o puede crear su propio manejador de instalación para modificar los archivos de

propiedades. Consulte “Utilización del manejador de instalación global” en la página 166.

v Puede utilizar tareas proporcionadas por el servidor Device Manager para consultar y modificar

elementos específicos de archivos de propiedades gestionados. Para la plataforma de cliente, los

archivos rcpinstall.properties, config.ini, plugin_customization.ini y rcplauncher.properties se definen

de forma predeterminada para que los gestione el servidor Device Manager. También puede habilitar

archivos adicionales que se deben gestionar utilizando el punto de extensión

com.ibm.rcp.props.dm.managedFile.

Si está utilizando las posibilidades de cliente administrado de Portal para desplegar características, la

opción de manejador de instalación es el modelo de actualización recomendado. Las posibilidades de

cliente administrado de Portal no permiten consultar los valores actuales de las propiedades en los

sistemas de cliente.

Actualización del archivo rcplauncher.properties

Este apartado describe cómo puede actualizar uno o más elementos de la plataforma de Lotus Expeditor

Client de un usuario modificando el archivo rcplauncher.properties.

El archivo rcplauncher.properties se gestiona mediante manejadores de instalación. Contiene propiedades

que son necesarias para el iniciador para acciones globales.


|

||

|||||

||

|||||

|||||

Con los valores correctos en este archivo, la plataforma no se inicia. Otras propiedades de este archivo se

ignoran. Este archivo no se debe modificar excepto mediante manejadores de instalación.

Ubicaciones de archivo:

v ${rcp.home}/rcp/rcplauncher.exe

v ${rcp.home}/rcp/rcplauncher.properties

Un archivo rcplauncher.properties típico tiene este aspecto:

rcp.install.id=1156180825640

Las propiedades de marca (producto y osgi.splashPath) se gestionan desde rcplauncher.properties.

osgi.splashPath=platform\:/base/../rcp/eclipse/plugins/com.ibm.rcp.platform.personali

ty.branding,platform\:/base/../rcp/eclipse/plugins/com.ibm.rcp.platform.personality.b

randing.nl1,platform\:/base/../rcp/eclipse/plugins/com.ibm.rcp.platform.personality.b

randing.nl2,platform\:/base/../rcp/eclipse/plugins/com.ibm.rcp.platform.personality.b

randing.nl3

product=com.ibm.rcp.platform.personality.branding.DefaultProduct

El cálculo utilizado para localizar el espacio de trabajo del usuario se exterioriza en este archivo.

rcp.data=$(env.APPDATA)/Lotus/XPD

Este valor se puede personalizar en el instalador.

La propiedad rcp.install.id es un número exclusivo generado por el instalador. Se utiliza para asegurar

que no hay colisiones entre varias instalaciones de la plataforma. Éste se copia en el nuevo archivo

rcpinstall.properties del usuario.

provisioning.manifest=file\:/${rcp.home}/rcp/deploy/install.xml

La definición de la instalación base elegida por el administrador se define en este archivo. Cuando un

usuario nuevo inicia la plataforma por primera vez la configuración de suministra en este nivel.

provisioning.manifest.version=1156180825640

Ésta es la versión del archivo provisioning.manifest que se está utilizando. El número suele empezar con

el rcp.install.id actual. Cuando un usuario inicia la plataforma y el iniciador determina que la versión

de manifiesto no es idéntica al nivel del rcpinstall.properties del usuario, se iniciará un ciclo de

suministro. El nivel suministrado realmente para un usuario se graba en el archivo rcpinstall.properties

del usuario mediante el componente de suministro.

install.configuration=user

de suministro. Ésta la establece la instalación original y no se debe cambiar nunca. Se copia en el archivo

rcpinstall.properties del nuevo usuario.

update.policy.managed=true

Se trata de una propiedad interna y no se debe cambiar. Es posible que se ignore en futuras versiones de

rcplauncher.

rcp.base.location=${rcp.home}/rcp/eclipse/plugins/com.ibm.rcp.base_6.1.0.0-20060817

Esta propiedad apunta al plug-in base que contiene:

v archivo rcpinstall.properties base - Los valores iniciales representan qué hay en el conjunto básico de

características. Todos los cambios por encima de este nivel los produce la ejecución de manejadores de

instalación.

v startup.jar, eclipse.exe y launcher.jar ubicados y ejecutados desde esta ubicación.

v rcplauncher.exe está ubicado aquí pero el manejador de instalación de plug-in lo copia en

<dir_instalación>/rcp/rcplauncher.exe.


v Platform.xml y config.ini están aquí y se utilizan para dar origen al directorio de configuración inicial.

Esta propiedad se copia en el archivo rcpinstall.properties de un nuevo usuario. Desde ese punto en

adelante, se le permite salir de sincronización con el valor de rcplauncher.properties. Eso sucederá si un

usuario elige ejecutar con una versión diferente.

provisioning.application=com.ibm.rcp.provisioning.application.ProvisioningApplication

Se trata de una propiedad interna y no se debe cambiar.

jvm.location=${rcp.home}/rcp/eclipse/plugins/com.ibm.rcp.jcl.desktop.win32.x86_

6.1.0.0-20060812/jre/bin/j9w.exe

Esto apunta a la VM (Virtual Machine) que implementa las especificaciones Java que deben utilizar los

usuarios nuevos. Al crear la configuración inicial de un usuario, esta propiedad se convierte en la

propiedad vm del archivo rcpinstall.properties del usuario. Los manejadores de instalación de

características gestionan esta propiedad y la propiedad vm. Desde ese punto en adelante, se le permite al

usuario elegir una versión de VM diferente o posiblemente incluso una VM diferente. La propiedad vm

la gestionará un manejador de instalación.

jvm.feature.id=com.ibm.rcp.jcl.desktop.win32.x86.feature

jvm.feature.version=6.1.0.0-20060812

jvm.parent.feature.id=com.ibm.rcp.jvm.feature

jvm.parent.feature.version=1.0.0.0-20060930

Estas propiedades son internas y las gestionan los manejadores de instalación. Se utiliza para corregir el

archivo platform.xml inicial.

Windows tiene un límite de 256 bytes en la longitud de mandato que se puede almacenar en las

propiedades de un icono. Si está personalizando iconos de lanzamiento para que contengan, por ejemplo,

personalidades o Dcomamnds, este límite se puede exceder fácilmente. Como método alternativo, puede

definir los argumentos como propiedades en el archivo rcplauncher.properties. El mandato de

lanzamiento sólo tendrá que contener lo siguiente:

rcplauncher.exe –config launchconfigone

rcplauncher.exe –config launchconfigtwo

Cuando el iniciador detecta los argumentos -config launchconfigone, sustituye las propiedades

almacenadas en el archivo rcplauncher.properties como si se hubieran incluido en la línea de mandatos.

Por ejemplo, si el mandato real debe ser rcplauncher –console -application com.ibm.MyApplication -nl

de –path “vía de acceso con espacios y {DBCS}” –vmargs -Dmyproperty=test, se almacenarán las

propiedades siguientes en rcplauncher.properties:

config.launchconfigone.1 = console

config.launchconfigone.2 = application

config.launchconfigone.3 = com.ibm.MyApplication

config.launchconfigone.4 = nl

config.launchconfigone.5 = de

config.launchconfigone.6 = -path

config.launchconfigone.7 = vía de acceso con espacios y \uxxxx\uxxxx...

config.launchconfigone.8 = -vmargs

config.launchconfigone.9 = -Dmyproperty=test

Cuando deba existir un espacio entre elementos en una línea de mandatos completa, los elementos se

representarán como argumentos de configuración independientes. En el ejemplo anterior, los elementos

-nl de se separan con un espacio en la línea de mandatos de modo que se convertirán en argumentos de

configuración independientes.

Notas:


v El archivo de propiedades no asegura que estos argumentos permanezcan en orden. El esquema de

numeración asegura que los argumentos se puedan restaurar correctamente. El número debe empezar

por 1 y se debe numerar de forma consecutiva.

v La vía de acceso se debe entrar en la línea de mandatos entre comillas. Esto no sólo no es necesario

que esté en el archivo, sino que no está permitido. Se pueden añadir comillas si forman parte de los

argumentos, pero no añada comillas adicionales.

v La vía de acceso puede contener caracteres no ASCII o no ISO8859-1. En los caracteres que no son

ASCII se deberá utilizar el carácter de escape con \uxxxx. Puede generar estos valores con un editor

Unicode 16 y realizar la conversión con el programa Java native2ascii.

v vmargs se debe entrar en rcpinstall.properties como vmarg.xarg=-Xarg. Sin embargo, para este archivo,

entre las propiedades sólo como se describe más arriba. El valor siempre está exactamente como si

estuviera contenido en la línea de mandatos - excepto como se indica.

v La utilización del argumento –config no restringe la adición de argumentos adicionales en la línea de

mandatos real. El iniciador no garantiza el orden de la combinación de las propiedades y los

argumentos de línea de mandatos (excepto para las alteraciones temporales indicadas más abajo). El

iniciador mantendrá el orden de las propiedades especificadas del archivo.

Algunos de los argumentos que se pueden entrar en la línea de mandatos o en las propiedades config.xxx

tienen una prioridad de alteración temporal. Las propiedades VM, application, product, personality y

plugincustomization tienen la siguiente prioridad de alteración temporal:

1. Línea de mandatos

2. Propiedad config.xxx

3. Propiedad en rcpinstall.properties

El espacio de trabajo tiene la prioridad siguiente:

1. –data en la línea de mandatos

2. –data en la propiedad config.xxx

3. Propiedad rcp.data en rcplauncher.properties

El entorno local tiene la prioridad siguiente:

1. –nl en la línea de mandatos

2. –nl en la propiedad config.xxxx

3. com.ibm.rcp.core.locale en rcpinstall.properties. Normalmente esto se establece en una página de

preferencias y sustituye el valor establecido por la prioridad 4

4. com.ibm.rcp.core.locale en rcplauncher.properties. Normalmente esto lo establece el instalador y

llena el idioma predeterminado para el archivo rcpinstall.properties de un usuario.

5. Entorno local calculado por la plataforma

El valor de BIDI tiene la prioridad siguiente:

1. –dir en la línea de mandatos

2. –dir en la propiedad config.xxx

3. com.ibm.rcp.core.bidi en rcpinstall.properties. Normalmente esto se establece en una página de

preferencias.

4. Directorio calculado por la plataforma cuando se especifica –nl

Tenga en cuenta que este archivo se puede llenar con propiedades de configuración de un manejador de

instalación.

El instalador crea y llena y el archivo rcplauncher.properties. Los usuarios no deben realizar cambios en

él. Sólo los ISV y los desarrolladores deben realizar cambios en el archivo; sin embargo, no deberán

cambiar los valores instalados. Los administradores pueden añadir propiedades de configuración.

Para obtener información sobre cómo gestionar este archivo, consulte los apartados siguientes:


Gestión utilizando el servidor Device Manager

“Gestión de archivos de propiedades” en la página 220

Gestión de clientes ricos utilizando el servidor de Portal

“Gestión de propiedades” en la página 258

Gestión utilizando otro sistema de gestión


Para tener la flexibilidad de cambiar la unidad desde la que se lanza IBM Lotus Expeditor,

rcpinstall.properties no debe contener referencias de vía de acceso absoluta a archivos o directorios del

directorio de instalación.

En lugar de especificar la ubicación absoluta del directorio de instalación, se utiliza la serie ${rcp.home}

para hacer referencia al directorio de instalación y se utiliza ${rcp.data} para hacer referencia al

directorio de espacio de trabajo. Una vez realizado el lanzamiento, el iniciador sustituirá el valor de esas

señales por la ubicación correcta del directorio de instalación y del directorio de espacio de trabajo de

IBM Lotus Expeditor antes de pasar los argumentos al ejecutable Java para IBM Lotus Expeditor.

Cuando se añaden propiedades nuevas a rcpinstall.properties o se realizan cambios en las propiedades

existentes, es importante que se utilice ${rcp.home} o ${rcp.data} al hacer referencia a los directorios de

instalación o de espacio de trabajo y que no se utilice ninguna referencia de vía de acceso absoluta.

La propiedad rcp.data la escribe el instalador en el momento de la instalación y no se debe modificar. La

propiedad rcp.data proporciona un modo versátil de especificar dónde se debe ubicar el espacio de

trabajo. Consulte “Instalación de Lotus Expeditor Client para el lanzamiento compartido desde una

unidad de red” en la página 22 para obtener información sobre cómo especificar este valor antes de

instalar. Este valor se copiará en el rcpinstall.properties de cada usuario y alterará temporalmente el

algoritmo predeterminado para calcular la ubicación de espacio de trabajo.

El valor predeterminado de rcp.data para IBM Lotus Expeditor es rcp.data=${env.APPDATA}/Lotus/XPD

Si está actualizando de IBM Lotus Expeditor 6.1, el rcp.data predeterminado conservará el algoritmo

original. Para Windows, aparece como:

rcp.data=${env.HOMEDRIVE}${env.HOMEPATH}/IBM/RCP/${prop.rcp.install.id}/${env.USERNAME}/

El marcador ${env.”variable de entorno de sistema”} se utiliza para especificar el uso de una variable de

entorno de sistema.

El marcador ${prop.”rcplauncher_property”} se utiliza para especificar el uso de una propiedad de

rcplauncher.properties.

El instalador también puede escribir las siguientes propiedades en rcplauncher.properties:

v com.ibm.rcp.core.locale

v com.ibm.rcp.core.bidi

Para obtener más información sobre estas propiedades, consulte “Actualización del archivo

rcpinstall.properties”. Estas propiedades permiten al instalador especificar para cada usuario un idioma

predeterminado distinto del inglés. Éstas se copiarán en el archivo rcpinstall.properties de cada usuario

cuando se cree la configuración.

Actualización del archivo rcpinstall.properties

Este apartado describe cómo se puede actualizar el archivo rcpinstall.properties.


El archivo rcpinstall.properties reside en la ubicación ${rcp.data}/.config. Consulte “Alteración

temporal de la ubicación del directorio de espacio de trabajo” en la página 23 para obtener más

información.

Este archivo debe satisfacer todos los requisitos de un archivo de propiedades Java. En los caracteres que

no sean ASCII deberá utilizase el carácter de escape \uxxxx. Puede generar estos valores con el editor

Unicode 16 que prefiera y realizar la conversión con el programa Java native2ascii. Consulte el javadoc de

java.util.Properties.load() para obtener más información.

El archivo rcpinstall.properties puede contener las propiedades siguientes:

Nota: a menos que se indique de otro modo, todas las propiedades deben aparecer una sola vez en el

archivo rcpinstall.properties. Si una propiedad aparece más de una vez, no se garantiza qué

propiedad se utilizará.

Tabla 14. rcpinstall.properties

Propiedad Descripción

vm=<archivo ejecutable VM> Esta propiedad es necesaria. Debe apuntar a un archivo

ejecutable de la VM (Virtual Machine) que implementa

las especificaciones Java. La preferencia es expeditorw,

javaw o ibmj9w. Puede alterar este valor para las

configuraciones de usuario y multiusuario utilizando el

argumento -vm en la línea de mandatos. Consulte

“Cambio de la máquina virtual” en la página 43 para


rcp.install.id=<id> Esta propiedad es necesaria. Es un ID exclusivo que el

instalador crea para cada instalación.

Xbootclasspath.prepend=<vía de acceso> Esta propiedad especifica -Xbootclasspath/p:vía de acceso.

Consulte la documentación del iniciador de aplicaciones

Java.

Xbootclasspath.append=<vía de acceso> Esta propiedad especifica -Xbootclasspath/a:vía de acceso.

Consulte la documentación del iniciador de aplicaciones

Java.

-D<prop>=<valor> Consulte la documentación del iniciador de aplicaciones

Java. Pueden añadirse propiedades adicionales del

sistema al final del archivo.

library.path.append=<vía de acceso> Modifica PATH (en Windows) o LD_LIBRARY_PATH (en

Linux).

library.path.prepend=<vía de acceso> Modifica PATH (en Windows) o LD_LIBRARY_PATH (en

Linux).

application=<id plug-in de aplicación> Es equivalente a la propiedad de ejecución

eclipse.application de Eclipse. Puede alterarla para las


argumento -application en la línea de mandatos.

product=<id producto> Es equivalente a la propiedad de ejecución de Eclipse

eclipse.product. Se puede alterar para las


argumento -product en la línea de mandatos.

personality=<id personalidad> Le permite personalizar el aspecto en función de las

aplicaciones deseadas. Puede alterar temporalmente este

valor para las configuraciones de usuario y multiusuario

utilizando el argumento -personality en la línea de

mandatos.


Tabla 14. rcpinstall.properties (continuación)


plugincustomization=<vía de acceso al archivo de

personalización>

La instalación inicial proporciona este archivo. Se pueden

añadir valores nuevos a este archivo. Puede alterar

temporalmente este valor para las configuraciones de

usuario y multiusuario utilizando el argumento

-plugincustomization en la línea de mandatos.

install.configuration={multiuser, service, user,

userpb, lockdown}

Esta propiedad es necesaria. Especifica la configuración

instalada por el instalador. Una vez que se ha instalado

la plataforma, este valor no puede cambiarse.

vmarg.<nombre>=<valor> Aquí pueden proporcionarse argumentos específicos de

VM. El <valor> se pasa sin modificarse como vmarg a la

VM. El <nombre> sólo se utiliza como identificador

exclusivo de vmarg en este archivo. La sintaxis de este

argumento no se verifica.

library.preload=<valor> Esta propiedad es necesaria para Linux. Si es necesario,

el instalador habrá llenado este valor.

com.ibm.rcp.core.locale Opcional: El iniciador la añade mediante métodos

públicos. Se puede alterar temporalmente en la línea de

mandatos con -nl localearg.

com.ibm.rcp.core.bidi Opcional: El iniciador la añade mediante métodos

públicos. Se puede alterar temporalmente en la línea de

mandatos con -dir dir.

env.set.system env variable Se puede utilizar para establecer una variable de entorno

de sistema. Si la variable existe, se sustituirá. Por ejemplo

env.set.XXX=una nueva variable establecerá XXX en

“una nueva variable”.

<valores de configuración de java.util.logging> Opcional: Cualquiera de los valores de configuración

estándar de java.util.logging se pueden establecer en este

archivo, por ejemplo listados de manejador y entradas de

configuración de nivel de registrador. Para obtener una

lista completa de los valores de configuración de

java.util.logging, consulte “Configuración del registro y

rastreo de plataforma” en la página 105.

Un archivo rcpinstall.properties típico puede ser parecido al siguiente ejemplo:

En este ejemplo, las líneas se han partido para facilitar la lectura. En el archivo real, las líneas no deben

partirse, a menos que se utilice el carácter ’\’. Se puede utilizar el carácter de continuación de línea (’\’)

con las siguientes restricciones relacionadas con <prop>=<valor>:

1. Debe ser el último carácter de la línea. No puede haber ningún espacio en blanco de cola.

2. Si se divide el <valor>, no inserte ningún espacio en blanco antes del carácter de continuación.

3. Los espacios en blanco del principio de una línea que es continuación de otra se descartan.#Mié 01 Feb 08:42:42 CST 2006

# Nota: este archivo se ha formateado para facilitar la lectura. En el archivo real, no

# se garantiza el orden y se quitarán los comentarios.

Xbootclasspath.append=${rcp.home}/rcp/eclipse/plugins/com.ibm.rcp.base_6.1.1.20070222

0600/rcpbootcp.jar

-Dcom.ibm.pvc.webcontainer.port=0

-Declipse.registry.nulltoken=true

-Djava.protocol.handler.pkgs=com.ibm.net.ssl.www.protocol

-Djava.util.logging.config.class=com.ibm.rcp.core.internal.logger.boot.LoggerConfig

library.path.append=${rcp.home}/rcp/eclipse/plugins/com.ibm.rcp.os.win32_6.1.1.200702

220600/os/win32/x86;${rcp.home}/rcp/eclipse/plugins/com.ibm.rcp.os.linux_6.1.1.200702

220600/os/linux/x86


# Extensiones de infraestructura para soporte de registro y jxe

-Dosgi.framework.extensions=com.ibm.rcp.core.logger.frameworkhook,com.ibm.jxesupport

# Alteración de plugin_customization.ini de Eclipse

plugincustomization=${rcp.home}/rcp/plugin_customization.ini

# Excluir hook de registro de Eclipse y hook de soporte JXE

-

Dosgi.hook.configurators.exclude=org.eclipse.core.runtime.internal.adaptor.EclipseLog

Hook,com.ibm.jxesupport.CDSHookConfigurator

# Ubicación de archivo de seguridad Java

-Djava.security.properties=file:${rcp.home}/rcp/eclipse/plugins/com.ibm.rcp.base_6.1.1

.200702220600/rcp.security.properties

# Ubicación de vuelco de núcleo Java. Es un arreglo temporal sólo para variables de entorno VM

# Esta posibilidad no se soporta en el caso general en 6.1

env.set.IBM_JAVACOREDIR=${rcp.data}/logs

env.set.IBM_COREDIR=${rcp.data}/logs

env.set.IBM_HEAPDUMPDIR=${rcp.data}/logs

# Configuración de registro de JSR47

handlers=java.util.logging.ConsoleHandler

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.encoding=UTF-8

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.encoding=UTF-8

java.util.logging.ConsoleHandler.encoding=UTF-8

.level=WARNING

SystemOut.level=INFO

SystemErr.level=INFO

com.ibm.rcp.core.internal.logger.frameworkhook.level=CONFIG

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.level=WARNING

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.level=FINEST

java.util.logging.ConsoleHandler.level=FINEST

java.util.logging.ConsoleHandler.formatter=com.ibm.rcp.core.internal.logger.boot.RCPF

ormatter

# Configuración de registro de RCP

#com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.formatter=com.ibm.rcp.core.inter

nal.logger.boot.RCPFormatter

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.formatter=com.ibm.rcp.core.intern

al.logger.cbe.CBE101Formatter

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.size=4000000

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.count=6

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.append=false

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.pattern=error-log-%g

# Configuración de rastreo de RCP

#com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.formatter=com.ibm.rcp.core.int

ernal.logger.boot.RCPFormatter

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.formatter=com.ibm.rcp.core.inte

rnal.logger.cbe.CBE101Formatter

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.size=4000000

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.count=6

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.append=false

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.pattern=trace-log-%g

Para obtener información sobre cómo gestionar el archivo rcpinstall.properties, consulte los apartados

siguientes:







Para tener la flexibilidad de cambiar la unidad desde la que se lanza IBM Lotus Expeditor,

rcpinstall.properties no debe contener referencias de vía de acceso absoluta a archivos o directorios del

directorio de instalación.


En lugar de especificar la ubicación absoluta del directorio de instalación, se utiliza la serie ${rcp.home}

para hacer referencia al directorio de instalación y se utiliza ${rcp.data} para hacer referencia al

directorio de espacio de trabajo. Una vez realizado el lanzamiento, el iniciador sustituirá el valor de esas

señales por la ubicación correcta del directorio de instalación y del directorio de espacio de trabajo de

IBM Lotus Expeditor antes de pasar los argumentos al ejecutable Java para IBM Lotus Expeditor.

Cuando se añaden propiedades nuevas a rcpinstall.properties o se realizan cambios en las propiedades

existentes, es importante que se utilice ${rcp.home} o ${rcp.data} al hacer referencia a los directorios de

instalación o de espacio de trabajo y que no se utilice ninguna referencia de vía de acceso absoluta.

Configuración del registro y rastreo de plataforma

La plataforma Lotus Expeditor Client utiliza la infraestructura de registro java.util.logging de Java

Runtime Environment para guardar de forma persistente todos los mensajes de registro y rastreo de la

plataforma y las aplicaciones.

La configuración predeterminada de la infraestructura de registro de plataforma se almacena en el

archivo workspace/.config/rcpinstall.properties del usuario. Para obtener información sobre cómo

actualizar este archivo, consulte “Actualización del archivo rcpinstall.properties” en la página 101.

Configuración predeterminara del sistema

Manejadores

La configuración predeterminada para la plataforma de cliente registra tres manejadores: un manejador

de consola, un manejador de registro y un manejador de rastreo. La codificación de los manejadores

basados en archivo (registro y rastreo) se establece en UTF-8, mientras que el valor predeterminado de la

codificación de la consola es el método de codificación de la plataforma para todos los mensajes de

registro. El número de archivos (count) que debe persistir para cada uno de los manejadores toma 6 de

forma predeterminada y el tamaño máximo (size) para cada uno de los archivos antes de que roten toma

de forma predeterminada 4000000 bytes. El tamaño puede establecerse individualmente tanto para los

manejadores de registro como de rastreo, y tiene un tamaño mínimo de 100 K bytes. El filtro de nivel de

mensaje predeterminado para el manejador de consola y el manejador de rastreo es FINEST, lo que

permite que estos manejadores capturen todos los mensajes que se registran y que dichos mensajes se

procesen correctamente, mientras que el manejador de registro toma WARNING de forma

predeterminada para asegurar que el registro del sistema, que está destinado al usuario final, no se altere

con mensajes informativos y mensajes de rastreo durante la ejecución normal. Este valor permite al

usuario final identificar más fácilmente posibles problemas en el archivo de registro en el caso de que la

aplicación/plataforma no funcione como se espera.

Un punto importante a tener en cuenta es que mientras los valores estándar de java.util.logging se

utilizan para la mayor parte de la configuración, la única variación de esto es el valor de patrón. Se

espera que el patrón para Lotus Expeditor Client sea sólo un nombre relativo del directorio de espacio de

trabajo/registros de los usuarios y no soporta la sustitución de %h definida por java.util.logging para

reubicar estos archivos de registro.

Formateadores

Si la plataforma se inicia con una consola, todos los mensajes de registro y rastreo se direccionan al

manejador de consola y se visualizan utilizando el formato de texto estándar utilizando RCPFormatter.

Los archivos de registro y rastreo estándar se graban de forma predeterminada en formato XML de

CommonBaseEvent utilizando CBE101Formatter.

Configuración a nivel de registrador


||||

||

El archivo rcpinstall.properties predeterminado también incluye un pequeño conjunto de la configuración

a nivel de registrador java.util.logging predeterminada. Hay 2 registradores especiales definidos para

manejar los mensajes system.err y system.out que se denominan SystemOut y System.err. Toman de

forma predeterminada el nivel INFO, lo que significa que los mensajes system.err y system.out no

aparecerán de forma predeterminada en el archivo system.log pero aparecerán en el archivo de rastreo

del sistema.

Configuración predeterminada

A continuación, se muestran los valores predeterminados para la infraestructura java.util.logging:

# Configuración de registro de JSR47

handlers=java.util.logging.ConsoleHandler

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.encoding=UTF-8

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.encoding=UTF-8

.level=WARNING

SystemOut.level=INFO

SystemErr.level=INFO

com.ibm.rcp.core.internal.logger.frameworkhook.level=CONFIG

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.level=WARNING

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.level=FINEST

java.util.logging.ConsoleHandler.level=FINEST

java.util.logging.ConsoleHandler.formatter=com.ibm.rcp.core.internal

.logger.boot.RCPFormatter

# Configuración de registro de RCP

#com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.formatter=

com.ibm.rcp.core.internal.logger.boot.RCPFormatter

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.formatter=

com.ibm.rcp.core.internal.logger.cbe.CBE101Formatter

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.size=4000000

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.count=6

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.append=false

com.ibm.rcp.core.internal.logger.boot.RCPLogHandler.pattern=error-

log-%g

# Configuración de rastreo de RCP

#com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.formatter=

com.ibm.rcp.core.internal.logger.boot.RCPFormatter

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.formatter=

com.ibm.rcp.core.internal.logger.cbe.CBE101Formatter

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.size=4000000

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.count=6

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.append=false

com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.pattern=trace-

log-%g

Federación de mensajes de registro

Mientras las API java.util.logging de JRE se utilizan para la persistencia real de los mensajes en el disco,

es importante tener en cuenta que hay varias API de registro disponibles en la plataforma de Lotus

Expeditor Client. La plataforma de cliente proporciona las siguientes API de registro: API

java.util.logging, API de registro de Eclipse, API OSGi LogService y API de registro de Apache Commons.

La infraestructura de registro básica de la plataforma de Lotus Expeditor Client captura los mensajes de

todas estas API y las federa en un solo registro utilizando la infraestructura de formato y persistencia

java.util.logging. Para simplificar la configuración de estos mensajes federados, se crean registradores

dinámicos con nombre para los componentes que no son java.util.logging cuando se generan y se

registran mensajes del nivel apropiado. Los registradores con nombre se crean con el nombre simbólico

del paquete OSGi que está registrando el mensaje como nombre del registrador java.util.logging. Este

registrador se puede configurar utilizando la configuración a nivel de registrador java.util.logging

estándar, utilizando el archivo rcpinstall.properties o dinámicamente utilizando el mandato de consola de


|||||||||||||||||||||||||||||||||||||

OSGi setlogrlev. Consulte Ajuste dinámico del nivel de registro en Soporte y resolución de problemas en

Lotus Expeditor para obtener más información sobre esta posibilidad.

Actualización del archivo config.ini en los escritorios

Este apartado describe las propiedades proporcionadas en el archivo config.ini predeterminado.

El archivo config.ini está ubicado en el directorio <dir_configuración>/.config. El instalador

proporciona información y valores para este archivo necesario en la plataforma.

El directorio .config reside en el directorio de espacio de trabajo definido por el patrón en el archivo


A continuación se proporciona una lista de propiedades que se encuentran en el archivo config.ini:

osgi.parentClassloader

Definición del cargador de clases padre para los paquetes OSGi.

Valor actual: ext

Valor predeterminado: boot

osgi.bundles

Lista separada por comas de los paquetes que se instalarán y opcionalmente iniciarán una vez

que el sistema esté configurado y en ejecución. Para obtener más información sobre la sintaxis de

esta propiedad, consulte la publicación Platform Plug-in Developer’s Guide y la ayuda de Eclipse

(http://help.eclipse.org/help32/index.jsp).

Valor actual:

osgi.bundles=org.eclipse.equinox.common@2:start, \

org.eclipse.core.jobs@4:start,\

org.eclipse.equinox.registry@4:start,\

org.eclipse.core.runtime.compatibility.registry,\

org.eclipse.equinox.preferences@4,\

org.eclipse.core.contenttype@4,\

org.eclipse.core.runtime@4:start,\

org.eclipse.update.configurator@3:start, \

../../rcp/eclipse/plugins/com.ibm.rcp.lifecycle.platform@5:start

Valor predeterminado: <none>

osgi.bundles.defaultStartLevel

Asigna el nivel de inicio predeterminado a los paquetes que no tienen ningún nivel de inicio

asignado explícitamente.

Valor actual: 10


osgi.startLevel

Establece el nivel superior de inicio en el que la infraestructura debe intentar iniciarse.

Valor actual: 15


eclipse.exitOnError

Indica si el entorno de trabajo debe salir de forma inmediata si recibe un evento de ERROR de la

infraestructura.

Valor actual: false

Valor predeterminado: true



Para obtener información sobre cómo gestionar el archivo config.ini, consulte los apartados siguientes:







Actualización del archivo config.ini en los dispositivos

En los dispositivos, el archivo config.ini está ubicado en el directorio \eclipse\configuration. Este archivo

se puede modificar para establecer las propiedades de sistema Java que no suelen ser específicas de

aplicaciones individuales.

Consulte el apartado “Cambio de un valor de archivo de propiedades” en la página 221 para obtener más

información sobre cómo establecer propiedades en los dispositivos de usuarios.

Actualización del archivo plugin_customization.ini

Este apartado describe las propiedades proporcionadas en el archivo plugin_customization.ini

predeterminado.

Este archivo establece el valor predeterminado de las preferencias utilizadas en el sistema.

plugin_customization.ini es un archivo de propiedades Java que contiene valores de preferencias.

Normalmente, cada preferencia se identifica con un nombre de nodo y una clave. Algunas preferencias

pueden definir nodos entre el nodo raíz y la clave.

El formato de cada línea es el siguiente:

nombre nodo raíz/[nodo intermedio opcional/] nombre preferencia=valor preferencia

Para añadir una nueva preferencia predeterminada, añada una línea nueva al archivo especificando los

nombres de nodo, el nombre de la preferencia y el valor.

Por ejemplo, para establecer un archivo de política de actualizaciones, primero identifique el nodo

asociado con la preferencia (org.eclipse.update.core), el nombre de la preferencia (updatePolicyURL) y

el valor deseado (http://w3.myserver.com/policy.xml)

A continuación, añada la línea org.eclipse.update.core/updatePolicyURL=http://w3.myserver.com/policy.xml

Como archivo de propiedades Java, se espera que la codificación del archivo sea ISO-8859-1. Cualquier

carácter que no esté codificado en ISO-8859-1 debe especificarse utilizando la sintaxis de escape Unicode.

Para obtener más información, consulte el javadoc para la clase java.util.Properties.

El archivo plugin_customization.ini reside en el directorio <dir_instalación>/rcp.

Los valores actuales del archivo son los siguientes:

com.ibm.rcp.security.auth.ui/ssoEnabled=false

com.ibm.rcp.platform/portalServerAddress=

com.ibm.rcp.platform/portalEnabled=false

com.ibm.rcp.security.auth.ui/ssoAllowed=true

En el archivo plugin_customization.ini del directorio <dir_instalación>/rcp, establezca los valores en ’true’

para las siguientes preferencias:


com.ibm.rcp.security.auth.ui/ssoAllowed

Determina si los usuarios tienen la opción de utilizar el inicio de sesión único. Puede establecer

este valor de preferencia durante la instalación del cliente o posteriormente utilizando un valor

gestionado. Esta preferencia no debe aparecer para los usuarios.

com.ibm.rcp.security.auth.ui/ssoEnable

Determina si los usuarios tienen la opción de activar o desactivar el inicio de sesión único. Si la

opción se establece en true, se utiliza el inicio de sesión único. Si la opción se establece en false,

se inhabilita el inicio de sesión único. El valor de esta preferencia sólo es pertinente si ssoAllowed

es verdadero (true).

Por ejemplo:

com.ibm.rcp.security.auth.ui/ssoEnabled=true


Nota: Los valores ssoEnabled y ssoAllowed sólo se pueden establecer antes de que se ejecute la

plataforma. Una vez que la plataforma se ha ejecutado, estas opciones ya no se pueden cambiar.

Para obtener información sobre cómo gestionar el archivo plugin_customization.ini, consulte los

apartados siguientes:







Habilitación del inicio de sesión único de plataforma

El inicio de sesión único (SSO) autentica a los usuarios solicitándoles un nombre de usuario y una

contraseña una sola vez. La habilitación del inicio de sesión único de plataforma proporciona a los

usuarios el acceso seguro al almacén de claves de plataforma sin visualizar solicitudes de autenticación

adicionales.

Para permitir el inicio de sesión único de plataforma, realice el paso siguiente:

En el archivo plugin_customization.ini del directorio dir_instalación/rcp, establezca los valores para las

siguientes preferencias en true:

v com.ibm.rcp.security.auth.ui/ssoAllowed – Valor booleano. Determina si los usuarios tienen la opción

de utilizar el inicio de sesión único. Puede establecer este valor de preferencia durante la instalación

del cliente o posteriormente utilizando un valor gestionado.

v com.ibm.rcp.security.auth.ui/ssoEnable – Valor booleano. Determina si los usuarios tienen la opción de

activar o desactivar el inicio de sesión único. Si se establece en true, se utiliza el inicio de sesión único.

Si se establece en false, se inhabilita el inicio de sesión único. El valor de esta preferencia sólo es

pertinente si ssoAllowed es verdadero (true).

Por ejemplo:

com.ibm.rcp.security.auth.ui/ssoEnabled=true


Nota: Los valores ssoEnabled y ssoAllowed sólo se pueden establecer antes de que se ejecute la

plataforma. Una vez que la plataforma se ha ejecutado, estas opciones ya no se pueden cambiar.


Gestión de almacén de claves seguro

El almacén de claves Java es la abstracción de almacenamiento estándar para la información sensible a la

seguridad como las claves, los certificados y las contraseñas.

Los módulos de inicio de sesión acceden al almacén de claves Java para recuperar y almacenar

contraseñas como parte del proceso de inicio de sesión. La API de Cuentas también accede al almacén de

claves Java para cambiar contraseñas fuera del proceso de inicio de sesión.

El almacén de claves Java debe estar desbloqueado para acceder a los datos almacenados en él. El

almacén de claves se puede desbloquear utilizando el inicio de sesión de plataforma. De forma

predeterminada, Lotus Expeditor llama al inicio de sesión de plataforma para desbloquear el almacén de

claves en el arranque. Esto se puede cambiar mediante el programa a fin de desbloquear el almacén de

claves cuando se necesite.

A continuación, se muestra un ejemplo de cómo llamar mediante el programa al inicio de sesión de

plataforma segura para desbloquear el almacén de claves Java:

import com.ibm.rcp.security.auth.SecurePlatform;

public void doLogin() {

try {

SecurePlatform.getLoginContext().login();

}

catch (LoginException e) {

// El inicio de sesión ha fallado... salga de la plataforma

// o realice una acción correctora

}

}

En función de cómo se configure Lotus Expeditor, la llamada al inicio de sesión de plataforma segura

solicitará al usuario una contraseña de almacén de claves o bien obtendrá la contraseña de otro origen

seguro y la utilizará para desbloquear el almacén de claves (consulte “Habilitación del inicio de sesión

único de plataforma” en la página 109).

Una vez que se ha desbloqueado el almacén de claves Java, la API de Cuentas y los Módulos de inicio de

sesión JAAS pueden acceder a los datos seguros, tales como las contraseñas almacenadas en el almacén

de claves. También se puede acceder al almacén de claves, mediante programa, llamando a

SecurePlatform.getKeyStore( ). Todas las aplicaciones de Lotus Expeditor tienen acceso al almacén de

claves Java y pueden utilizarlo para almacenar sus propios datos.

Gestión de artefactos de determinación de problemas

Configure el gestor de artefactos de determinación de problemas para asegurarse de que los artefactos de

sistema de archivos utilizados para resolver errores se gestionan correctamente.

Aunque está diseñado para ejecutarse durante extensos periodos sin reiniciarse, el entorno de ejecución

de cliente Lotus Expeditor puede experimentar en algunos casos condiciones de error inesperadas.

Cuando se producen estas condiciones de error inesperadas, se pueden generar en algunos casos vuelcos

de núcleo y vuelcos de almacenamiento dinámico Java a fin de proporcionar información de

determinación de problemas a los equipos de servicio y soporte. Los datos de determinación de

problemas pueden ser indispensables para resolver estos errores inesperados.

En otros casos, los datos para la determinación de problemas se pueden recoger más explícitamente

ejecutando los mecanismos de recogida de IBM Support Assistant incorporados en el producto. Estos dos

casos producen artefactos de sistema de archivos en ubicaciones de la plataforma cliente conocidas

públicamente.


Con el tiempo, los vuelcos de núcleo y los vuelcos de almacenamiento dinámico Java y los jar de

recogida de datos ISA pueden llegar a consumir grandes cantidades de espacio de disco. Para asegurar la

gestión correcta del espacio del sistema de archivos, se suprimen de forma periódica los archivos más

antiguos. Se utiliza un algoritmo de antigüedad para permitir definir el tiempo de permanencia en días

de los archivos y que éstos puedan consultarse durante una sesión de determinación de problemas, pero

una vez que excedan el límite de antigüedad, se suprimen. Este periodo de antigüedad se puede

configurar y también se puede inhabilitar utilizando la administración. El periodo predeterminado es de

5 días.

El gestor de artefactos de determinación de problemas proporciona esta posibilidad para el cliente de

entorno de ejecución Lotus Expeditor.

Cambio del intervalo predeterminado del gestor de artefactos de

determinación de problemas

Puede cambiar el intervalo predeterminado del gestor de artefactos de determinación de problemas para

definir cuándo se deben eliminar los artefactos de sistema de archivos.

Para cambiar el intervalo predeterminado del gestor de determinación de problemas, realice una de las

acciones siguientes:

v Utilizando un editor de texto, abra el archivo <dir_instalación>/rcp/plugin_customization.ini,

modifique la propiedad com.ibm.rcp.core.pd.manager/interval para el intervalo en días y guarde el

archivo.

Por ejemplo, com.ibm.rcp.core.pd.manager/interval=120.

v Si gestiona el cliente utilizando el servidor Device Manager:

1. Lance la consola de servidor Device Manager a fin de crear un trabajo de configuración para la

preferencia com.ibm.rcp.core.pd.manager/interval.

2. Planifique el trabajo para el dispositivo de cliente.

Cuando el usuario lanza la plataforma de cliente, el agente de dispositivo sondea el servidor y recibe el

trabajo de configuración. La preferencia de Eclipse se actualiza.

Inhabilitación del gestor de artefactos de determinación de problemas

Esta opción le permite inhabilitar el gestor de artefactos de determinación de problemas.

Para inhabilitar el gestor de artefactos de determinación de problemas, realice una de las acciones

siguientes:

v Utilizando un editor de texto, abra el archivo <dir_instalación>/rcp/plugin_customization.ini, establezca

la propiedad com.ibm.rcp.core.pd.manager/interval en 0 y guarde el archivo.

Por ejemplo, com.ibm.rcp.core.pd.manager/interval=0.

v Si gestiona el cliente utilizando el servidor Device Manager:

1. Lance la consola de servidor Device Manager para crear un trabajo de configuración para la

preferencia com.ibm.rcp.core.pd.manager/interval estableciéndola en 0.

2. Planifique el trabajo para el dispositivo de cliente.

Cuando el usuario lanza la plataforma de cliente, el agente de dispositivo sondea el servidor y recibe el

trabajo de configuración. La preferencia de Eclipse se actualiza.

Gestión de cuentas

Puede abrir, almacenar y utilizar propiedades necesarias para conectarse a un servicio remoto y

comunicarse con él.


La API de Cuentas proporciona un modo de abrir, almacenar y utilizar propiedades necesarias para

conectarse a un servicio remoto y comunicarse con él. Ejemplos de este tipo de cuentas: Una cuenta

HTTP que se utiliza para conectarse a un servicio basado en web. Esta cuenta contendrá un URL para la

ubicación del servicio y un nombre de usuario y una contraseña para iniciar la sesión en el servicio. Una

cuenta de mensajería instantánea utilizada por un cliente IM para conectarse a un servidor IM, por

ejemplo IBM Lotus Sametime. Esta cuenta incluirá un nombre de servidor, un nombre de usuario y una

contraseña para conectarse al servidor IM. La cuenta también se puede utilizar para almacenar

preferencias de usuario, por ejemplo el texto que ve la gente cuando el estado IM del usuario es

″Ausente″. De este modo, una cuenta se puede utilizar para almacenar propiedades de conexión y

propiedades o preferencias específicas de dicha conexión. En el caso de IM, el usuario puede tener varias

cuentas IM, para uso empresarial y personal. El mensaje de estado ″Ausente″ se puede almacenar en la

cuenta, para que se pueda establecer en un valor diferente para cada uno.

La API de Cuentas proporciona un modo de obtener, añadir, actualizar, eliminar y escuchar cambios en

una cuenta. Las cuentas se pueden obtener por id exclusivo, nombre o cualquier otra propiedad y una

obtención de cuenta por método de servidor proporciona coincidencias parciales. La API de Cuentas

también proporciona integración con JAAS (Java Authentication and Authorization Service - Servicio de

autenticación y autorización de Java). (Para obtener más información sobre JAAS, consulte

http://java.sun.com/products/jaas/overview.html). Una cuenta construida correctamente puede

proporcionar un servicio de contexto de inicio de sesión que obtendrá y validará las credenciales

necesarias para conectarse a un servicio remoto. Determinadas cuentas también obtendrán cookies de

sesión y LTPA. Mediante la utilización de la integración de Cuentas con JAAS, una aplicación tendrá las

contraseñas completamente validadas y los cookies necesarios para comunicarse con el servicio remoto.

Todas las cuentas, excepto la Cuenta de portal principal se pueden gestionar utilizando la interfaz de

usuario de Cuentas. La Cuenta de portal principal se puede gestionar utilizando la interfaz de usuario de

Cuenta de portal principal.

Para obtener más información sobre, consulte Infraestructura de cuentas en Desarrollo de aplicaciones para

Lotus Expeditor.

Creación de cuentas

Una cuenta contiene un conjunto de propiedades (parejas de nombre y valor) utilizadas por una

aplicación para conectarse a un servicio remoto.

Puede hacer que una cuenta se conecte al servidor de correo personal utilizando POP3 para obtener el

correo electrónico, que una cuenta se conecte a un WebSphere Portal Server para acceder a aplicaciones

compuestas o que una cuenta LDAP realice una búsqueda de nombre desde el directorio corporativo. Es

posible que algunas cuentas ya existan en el cliente, creadas por aplicaciones o suministradas desde

Domino o Portal. Tenga cuidado al editar, eliminar o crear cuentas nuevas, porque estas acciones pueden

hacer que algunas aplicaciones ya no funcionen más. Si no está seguro de lo que debe hacer, pregunte al

administrador.

Propiedades avanzadas para cuentas HTTP / HTTPS

Las propiedades avanzadas para cuentas HTTP se utilizan, principalmente, para especificar propiedades

adicionales necesarias para la autenticación con un servidor de Portal directamente o con un servidor

HTTP/Portal protegido por Tivoli Access Manager (TAM) o Site Minder. Para utilizar correctamente estas

propiedades deben tenerse conocimientos específicos de la infraestructura HTTP de una organización y

los usuarios no deben modificarlas a menos que el administrador les proporcione instrucciones concretas.

Esta sección ofrece la información necesaria para utilizar estas propiedades, pero se presupone un cierto

conocimiento acerca del mecanismo de autenticación utilizado.

Tipos de autenticación


http://java.sun.com/products/jaas/overview.html

HTTP Básica (valor predeterminado)

HTTP Básica es la autenticación simple que consta de nombre de usuario y contraseña. La

autenticación se realiza en el URL especificado por el valor de Server y se ignoran las demás

propiedades avanzadas. Es análogo a abrir un navegador web en el URL y que aparezca un

diálogo solicitando un nombre de usuario y una contraseña.

J2EE Form (avanzada)

J2EE-FORM es una forma estándar de autenticación con un servidor de aplicaciones web, como

los servidores de WebSphere y Portal. Se somete a un URL un formulario que contiene un

nombre de usuario y una contraseña. Para servidores de WebSphere y Portal, se devuelve una

señal LTPA que se puede utilizar para autenticaciones futuras. J2EE-FORM utiliza la propiedad

URL de autenticación (auth URL) para conectar con un servlet. auth URL se utiliza de una de

estas dos maneras:

v Si auth URL es un URL completo y válido (por ejemplo, http://myportalserver.com/wps/j_security_check), se utiliza para localizar el servlet.

v Si auth URL es un URL parcial (por ejemplo, /wps/j_security_check), se añade a la raíz del

valor de Server.

Por ejemplo, si el valor de Server es http://myserver.com/mycontextroot y auth URL es

/wps/j_security_check, el URL que se utiliza es http://myserver.com/wps/j_security_check.

Portal Form (avanzada)

Portal Form es una versión más avanzada de J2EE-FORM. auth URL se establece en una

ubicación ligeramente distinta. Este auth URL genera tanto una señal LTPA para autenticación

como un cookie JSession para los datos de sesión. Debe utilizarse Portal form para comunicarse

con portlets, porque J2EE-FORM no proporciona el cookie de sesión. Utilice J2EE-FORM para

comunicarse con los servlets alojados en los servidores de Portal y WebSphere.

TAM Form y Site Minder Form (avanzada)

Debe utilizarse TAM Form y Site Minder Form cuando el recurso HTTP está protegido por una

de estas tecnologías. Debe configurarse el recurso HTTP para que acepte la señal de autenticación

que proporcionan TAM o Site Minder. Estos tipos de autenticación funcionan de la misma manera

que Portal form, excepto que se somete un formulario que es específico para TAM o Site Minder.

El resultado de la autenticación es un cookie que se puede utilizar para realizar la autenticación

con cualquiera de los recursos HTTP protegidos, incluidos los servidores de WebSphere y Portal.

Símbolo de nombre de usuario (avanzada)

Símbolo de nombre de usuario es un mecanismo de autenticación utilizado por Servicios web.

Este tipo de autenticación sólo deben utilizarlo las cuentas hijo que han seleccionado Utilice el

nombre y la contraseña de una cuenta ya existente. Sólo debe utilizarse Símbolo de nombre

de usuario si Servicios web no acepta ninguna otra forma de autenticación, puesto que requiere el

envío del nombre de usuario y la contraseña en cada solicitud. Normalmente no se utiliza este

tipo de autenticación y debe evitarse en lo posible.

TAM SPNEGO (avanzada)

TAM SPNEGO sólo está soportado en sistemas operativos Microsoft Windows. Utiliza Active

Directory para obtener un símbolo basado en el inicio de sesión del sistema operativo del

usuario. A continuación, utiliza ese símbolo para la autenticación con TAM, en lugar de utilizar

un nombre de usuario y una contraseña. Aparte de esto, el resultado de la autenticación es el

mismo que para TAM Form.

URL de autenticación

El URL de autenticación sólo se utiliza con J2EE-FORM y PORTAL Form porque necesita conocer la

ubicación del servlet de autenticación. El valor de esta propiedad puede ser un URL completo o una vía

de acceso relativa a la raíz del URL del servidor.

URL de portal principal


Algunas aplicaciones requieren este valor para interactuar adecuadamente con un servidor de WebSphere

Portal. Cuando se accede a un servidor de Portal mediante un navegador web, por omisión, se utiliza el

URL siguiente:

http://myportalserver.com/wps/myportal

El URL de portal principal es, en este caso, la parte myportal. Puesto que el administrador del sistema

puede configurar esta parte, el valor predeterminado puede modificarse según sea necesario en las

propiedades avanzadas.

Gestión de preferencias de Eclipse

Los plug-ins de plataforma y aplicación pueden utilizar las preferencias de Eclipse para el

almacenamiento de la información configurable. Los valores de ventana, las ubicaciones de servidor y los

valores de sincronización se incluyen entre los ejemplos.

Eclipse es una comunidad de código abierto cuya finalidad es la implementación de una plataforma de

desarrollo universal.

Las preferencias de Eclipse se gestionan en un formato de árbol. Los primeros nodos después de la raíz

se denominan ámbitos. Cada uno de los ámbitos define un subárbol. Los ámbitos predeterminados

proporcionados por Eclipse son default, instance, configuration y project. Bajo cada uno de los

ámbitos, normalmente el árbol de preferencias se organiza por identificación de plug-in. La asociación de

claves de preferencias y valores con un plug-in determinado ayudará a eliminar colisiones de nombres.

El producto añade un ámbito adicional denominado ManagedSettings. Consulte el apartado

“Configuración de valores gestionados” en la página 77 para obtener más información.

El ámbito de instancia se almacena por espacio de trabajo, mientras que el ámbito de configuración se

almacena en el directorio de configuración. Dado que la configuración de instalación de plataforma

establece que el directorio de configuración sea un directorio en el espacio de trabajo, los ámbitos de

instance y configuration son de hecho equivalentes.

Puede buscar preferencias por nombre y los ámbitos se pueden buscar en un orden determinado. Un

orden de búsqueda típico será los ámbitos de instance, configuration y, a continuación, default.

¿Cómo se establecen las preferencias?

Las preferencias se establecen mediante el código, normalmente como resultado de interacciones con

páginas de preferencias. Sin embargo, los plug-ins pueden utilizar internamente preferencias que no se

desvelan mediante interacciones del usuario.

¿Cómo se establecen los valores de preferencia predeterminados?

La lista siguiente describe las diversas maneras en las que se pueden establecer los valores

predeterminados de preferencias para un plug-in específico. Se listan en el orden en que se procesan. Un

conjunto de preferencias predeterminado en el nivel más bajo (por ejemplo, valores predeterminados de

ejecución) lo sobregraba el mismo conjunto de preferencias en un nivel superior (por ejemplo, valores

predeterminados de producto).

Valores predeterminados de entorno de ejecución

Se especifican por código, por ejemplo contenidos en una clase de plug-in o en un inicializador

de preferencias proporcionado como una extensión al punto de extensión

org.eclipse.core.runtime.preferences

Valores predeterminados de paquete

Los valores predeterminados especificados en archivos preferences.ini en el plug-in.


Valores predeterminados de producto

Valores predeterminados especificados en el archivo de personalización proporcionado por el

producto.

Valores predeterminados de línea de mandatos

Valores predeterminados especificados en un archivo de personalización de plug-in especificado

en la línea de mandatos.

Una vez que el desarrollador ha creado el plug-in, en el momento de ensamblaje de la aplicación, el

ensamblador puede elegir añadir archivos preferences.ini al plug-in para alterar temporalmente el valor

que el desarrollador haya establecido.

Una vez que se han desplegado plug-ins en un sistema de cliente, se recomienda encarecidamente no

actualizar el contenido de plug-in. Por consiguiente, después del despliegue de los plug-ins, el único

modo aplicable de alterar temporalmente los valores predeterminados de preferencia es a través del

archivo de personalización de plug-in de línea de mandatos. Consulte “Actualización del archivo

plugin_customization.ini” en la página 108.

Para la plataforma de cliente, el plugin_customization.ini está contenido en el directorio

<dir_instalación>/rcp.

Después de que se haya desplegado la plataforma de cliente, este archivo se puede cambiar a través de

los siguientes métodos:

v Actualización manual

v Código añadido a manejadores de instalación de características para modificar el archivo. Consulte el

apartado “Utilización del manejador de instalación global” en la página 166 para obtener más

información.

v Manipulación directa a través de trabajos de archivos de propiedades proporcionados por el servidor

Device Manager. Consulte el apartado “Gestión de archivos de propiedades” en la página 220 para


¿Cómo se establecen los valores de preferencias de project, instance y

configuration?

Normalmente los valores de los ámbitos project, instance y configuration se obtienen como resultado

de las interacciones de usuario, por ejemplo a través del diálogo de preferencias. El código de plug-in

necesitará utilizar los métodos apropiados para buscar en los ámbitos install y configuration antes de

utilizar los valores predeterminados.

Normalmente la mayoría de los componentes de plataforma y aplicación no utilizan los valores de

preferencias de proyecto. Las preferencias de nivel de proyecto se asocian generalmente con herramientas

de creación de código o de ensamblaje de aplicaciones que mantienen un concepto de los proyectos, por

ejemplo SDK de Eclipse.

Los valores de preferencias de project, instance y configuration se pueden consultar después del

despliegue utilizando los trabajos de preferencias proporcionados por el servidor Device Manager.

Consulte el apartado “Consulta de preferencias de entorno de ejecución de cliente” en la página 219 para


Puede añadir, actualizar o eliminar valores de preferencias de project, instance y configuration utilizando

los mecanismos siguientes:

v Manejadores de instalación de características durante la instalación de características. Consulte el

apartado “Utilización del manejador de instalación global” en la página 166 para obtener más

información.


v Trabajos de preferencias proporcionados por el servidor Device Manager. Consulte el apartado “Gestión

de preferencias” en la página 219 para obtener más información.

v Valores de política proporcionados por el servidor y el cliente administrados por WebSphere Portal.

Consulte el apartado “Gestión de preferencias de cliente rico utilizando el editor de tipo de política

para preferencias de Eclipse” en la página 255 para obtener más información.

¿Qué sucede con los ámbitos definidos por el usuario o personalizados?

Las aplicaciones pueden definir ámbitos personalizados adicionales para almacenar preferencias. El

ámbito ManagedSettings definido por esta plataforma de producto es un ejemplo de ámbito

personalizado. Las API de preferencias de Eclipse utilizan los trabajos de preferencias y los valores de

políticas para consultar y efectuar cambios en los valores de preferencias. Normalmente las API funcionan

para otros ámbitos, a menos que los demás ámbitos proporcionen restricciones adicionales. Si una

aplicación proporciona su propio ámbito personalizado para las preferencias, es posible que las

operaciones de gestión proporcionadas por el servidor Device Manager o los valores de políticas no se

ejecuten siempre de forma satisfactoria. Consulte la aplicación para obtener más información sobre cómo

gestionar valores en el ámbito personalizado durante las operaciones de despliegue y posteriores al

despliegue.

Gestión de preferencias OSGi

La plataforma de cliente incluye una implementación del servicio de Preferencias OSGi para que la

utilicen las aplicaciones relacionadas con OSGi.

La implementación de servicio de preferencias OSGi proporcionada por Eclipse utiliza el mecanismo de

persistencia de servicio de preferencias de Eclipse estándar para el almacenamiento de los valores de

preferencias.

Las preferencias de OSGi sólo son accesibles para los plug-ins que han creado la preferencia y están

asociados con el número de paquete del plug-in. Si el número de paquete cambia, ya no se podrá acceder

a las preferencias. Las operaciones tales como el inicio de la plataforma con la opción –clean pueden

hacer que se vuelvan a numerar los paquetes. Por esta razón, no se recomienda el uso de preferencias de

OSGi.

¿Cómo se establecen las preferencias?

Las preferencias se establecen directamente mediante el código, normalmente como resultado de

interacciones con un usuario.

¿Cómo se establecen los valores de preferencia predeterminados?

Los valores de preferencia predeterminados los establece siempre por el servicio que está definiendo las

preferencias. El servicio puede proporcionar alternativas para establecer los valores predeterminados.

¿Cómo se pueden cambiar los valores de preferencias después del despliegue?

Puede consultar los valores de preferencias OSGi después del despliegue utilizando los trabajos de

preferencias proporcionados por el servidor Device Manager. Los valores para las preferencias de OSGi

están ubicados en /configuration/org.eclipse.core.runtime.preferences.OSGiPreferences.xx donde xx es el

número de paquete. Consulte el apartado “Consulta de preferencias de entorno de ejecución de cliente”

en la página 219 para obtener más información.

Puede añadir, actualizar o eliminar valores de preferencias de project, instance y configuration utilizando

los mecanismos siguientes:


v Trabajos de preferencias proporcionados por el servidor Device Manager. Consulte “Gestión de

preferencias” en la página 219.


Consulte “Gestión de preferencias de cliente rico utilizando el editor de tipo de política para

preferencias de Eclipse” en la página 255.

Dado que el mecanismo de almacenamiento contiene algunos aspectos referenciales, si un plug-in aún no

ha creado ningún valor, no se recomienda que cree un nuevo árbol de preferencias de OSGi para el

plug-in, sino que sólo modifique los valores para el árbol existente. Es posible que los cambios en los

valores de preferencias de OSGi no estén disponibles hasta el siguiente reinicio de plataforma.

Gestión de valores de UserAdmin

La plataforma de cliente incluye una implementación del servicio UserAdmin de OSGi. El servicio

UserAdmin proporciona un mecanismo para almacenar la definición de usuario, las credenciales de

usuario, los roles de usuario y la información de grupo.

El servicio UserAdmin utiliza el mecanismo de Preferencias de OSGi para el almacenamiento de esta

información. Puesto que el mecanismo de Preferencias de OSGi utiliza el número de paquete del servicio

UserAdmin para almacenar información de usuario, si cambia el número de paquete, las definiciones de

UserAdmin dejarán de ser accesibles. Las operaciones tales como iniciar la plataforma con la opción

-clean pueden hacer que se vuelvan a numerar los paquetes.

El servicio UserAdmin es el principal mecanismo que el contenedor Web puede utilizar para almacenar

información relacionada con el usuario y el rol.

¿Cómo se crean las definiciones de usuario?

Las definiciones de usuario se crean según un programa aprovechando las API de administración de

usuarios.

¿Cómo se pueden cambiar las definiciones de usuario después del despliegue?

Puede consultar los valores de UserAdmin después del despliegue utilizando los trabajos de preferencias

proporcionados por el servidor Device Manager. Los valores de UserAdmin están ubicados en

/configuration/org.eclipse.core.runtime.preferences.OSGiPreferences.xx donde xx es el número del

paquete UserAdmin (org.eclipse.equinox.useradmin). Consulte el apartado “Consulta de preferencias de

entorno de ejecución de cliente” en la página 219 para obtener más información.

Utilice los mecanismos siguientes para añadir, actualizar o suprimir valores de usuario:






Dado que el mecanismo de almacenamiento contiene algunos aspectos referenciales, si el paquete

UserAdmin aún no ha creado ningún valor, no se recomienda que cree un nuevo árbol de preferencias de

UserAdmin para el plug-in, sino que sólo modifique los valores para el árbol existente. Es posible que los

valores de UserAdmin no estén disponibles hasta el siguiente reinicio de plataforma.


Gestión de valores de ConfigurationAdmin

La plataforma de cliente incluye una implementación del servicio ConfigurationAdmin de OSGi. El

servicio ConfigurationAdmin proporciona un mecanismo para la información de configuración

correspondiente a un servicio.

El servicio ConfigurationAdmin utiliza el mecanismo de Preferencias OSGi para el almacenamiento de

esta información. Dado que el mecanismo de Preferencias OSGi utiliza el número de paquete del servicio

ConfigurationAdmin para almacenar información de usuario, si el número de paquete cambia, ya no se

podrá acceder a las definiciones de ConfigurationAdmin. Las operaciones tales como el inicio de la

plataforma con la opción –clean pueden hacer que se vuelvan a numerar los paquetes.

¿Cómo se crean las definiciones de usuario?

Los valores de ConfigurationAdmin se crean principalmente mediante código. Además, puede utilizar el

programa de utilidad de administración para OSGi para crear definiciones de usuario.

¿Cómo se pueden cambiar los valores de ConfigurationAdmin después del

despliegue?

Puede consultar los valores de ConfigurationAdmin después del despliegue utilizando los trabajos de

preferencias proporcionados por el servidor Device Manager. Los valores de configuración están ubicados

en /configuration/org.eclipse.core.runtime.preferences.OSGiPreferences.xx donde xx es el número del

paquete ConfigurationAdmin (com.ibm.osg.service.cm). Consulte el apartado “Consulta de preferencias

de entorno de ejecución de cliente” en la página 219 para obtener más información.

Utilice los mecanismos siguientes para añadir, actualizar o suprimir valores de usuario:






Dado que el mecanismo de almacenamiento contiene algunos aspectos referenciales, si el paquete

ConfigurationAdmin aún no ha creado ningún valor, no se le recomienda que cree un nuevo árbol de

preferencias de ConfigurationAdmin para el plug-in, sino sólo que modifique los valores del árbol

existente. Es posible que los valores de ConfigurationAdmin no estén disponibles hasta el siguiente

reinicio de plataforma.

Gestión del ciclo de vida

Este apartado describe el ciclo de vida de la plataforma de cliente.

Descripción del ciclo de vida

Utilice este apartado para obtener una descripción del ciclo de vida.

Ciclo de vida de plug-ins

Los plug-ins existentes en la plataforma de cliente tienen un ciclo de vida y estados definidos. Los

plug-ins existen en un solo y único estado a la vez. Los estados definidos son los siguientes:

Nota: La información de este apartado se aplica a la utilización de Lotus Expeditor Client en un

dispositivo, excepto dónde se indique lo contrario.


Instalado

La infraestructura subyacente ha añadido el plug-in. Bajo la operación normal, un plug-in

registrado por los componentes de actualización de Eclipse entrará en un proceso de resolución y

una transición al estado de resuelto. Si en la plataforma existe un plug-in, pero éste está en estado

instalado, el plug-in tiene dependencias que no se han cumplido o bien la infraestructura ha

seleccionado otro plug-in con un nombre simbólico de paquete (Bundle-SymbolicName) idéntico.

Un plug-in en estado instalado no puede compartir paquetes ni puede contribuir con extensiones

o puntos de extensión.

Resuelto

Se han cumplido todos los prerrequisitos del plug-in. Un plug-in puede contribuir con paquetes,

extensiones y puntos de extensión en la plataforma.

Iniciándose

Se ha solicitado al plug-in que se inicie y la infraestructura está en el proceso de inicio del

plug-in. Dado que las operaciones de inicio deben ser rápidas, la permanencia del plug-in en

estado de inicio indica que el plug-in no puede utilizar las prácticas recomendadas en la clase

BundleActivator.

Deteniéndose

Se ha solicitado al plug-in que se detenga y la infraestructura está en el proceso de detención del

plug-in. Dado que las operaciones de detención deben ser rápidas, la permanencia del plug-in en

estado de detención indica que el plug-in no puede utilizar las prácticas recomendadas en la clase

BundleActivator.

Activo El plug-in se ha iniciado.

Desinstalado

El plug-in se ha desinstalado y no se puede utilizar.

Ciclo de vida de fragmento

Los fragmentos se asocian con un plug-in de host. Dado que un fragmento no se puede iniciar y detener

individualmente, sigue el ciclo de vida asociado con el plug-in de host. Los fragmentos se adjuntan al

plug-in de host durante el proceso de resolución.

Ciclo de vida de plataforma

Cuando se solicita a la plataforma que se inicie, la infraestructura subyacente empezará el proceso de

inicialización y arranque. Para iniciar la rutina de arranque de la plataforma, se instalarán y se iniciarán

individualmente un pequeño número de plug-ins y fragmentos. Este conjunto de plug-ins lo define la

propiedad osgi.bundles. El valor predeterminado de esta propiedad se define en el archivo

<dirconfig>\config.ini.

El resto de los plug-ins y fragmentos para la plataforma se instalará a continuación. El conjunto de

plug-ins y fragmentos a instalar se determinará basándose en la configuración de plataforma. Si la

infraestructura utiliza una configuración sólo gestionada, el conjunto de plug-ins y fragmentos se

determinará basándose en la configuración de plataforma definida en el archivo platform.xml que reside

en <dirconfig>. Si la infraestructura no está utilizando una configuración sólo gestionada, el componente

de configuración de actualización descubrirá el conjunto de plug-ins y fragmentos de los directorios de

extensiones de Eclipse definidos.

Una vez que se haya completado la instalación de los plug-ins en la infraestructura, se ejecutará un paso

de resolución que intentará resolver todos los plug-ins y fragmentos.

Cuando se haya completado el paso de resolución, la infraestructura empezará el proceso de inicio de los

plug-ins. La infraestructura utiliza valores conocidos como niveles de inicio para organizar el arranque de

los plug-ins. La infraestructura existe a un nivel especificado y los plug-ins se asignan para iniciarse a un


nivel específico. La infraestructura empieza en el nivel 0 sin ningún plug-in iniciado. A continuación, la

infraestructura pasará a iniciar el nivel 1. Entonces, todos los plug-ins asignados para iniciar el nivel 1 se

iniciarán en algún orden. La infraestructura avanzará por cada uno de los niveles hasta alcanzar el nivel

de inicio de infraestructura designado. El nivel de inicio de infraestructura designado lo determina la

propiedad osgi.startLevel. Los plug-ins que se inician durante el proceso de nivel de inicio son aquéllos a

los que se ha asignado específicamente un nivel de inicio y que se han marcado para iniciarse de forma

persistente. Un plug-in se marca para el inicio persistente si ha sido explícitamente iniciado por código

que invoca el método start() en un objeto de paquete.

Se debe iniciar (activar) siempre un conjunto específico de plug-ins para que la plataforma se ejecute

correctamente. Los plug-ins necesarios en el arranque se especifican en el archivo config.ini en el

directorio de configuración. La propiedad osgi.bundles define el conjunto de plug-ins necesarios en el

arranque.

Cualquier plug-in especificado en esta propiedad, si se debe iniciar antes del plug-in del configurador de

actualizaciones, debe poder resolverse utilizando sólo los plug-ins especificados por esta propiedad.

Cualquier plug-in especificado para iniciarse después del plug-in de configurador de actualizaciones

puede utilizar otros plug-ins instalados por el configurador de actualizaciones o por la definición de

plataforma. Los plug-ins de esta propiedad se deberán limitar generalmente a los que son esenciales para

el arranque.

Cuando la infraestructura haya procesado todos los niveles de inicio necesarios, empezará a ejecutar una

aplicación. Una aplicación tal como se utiliza aquí es una clase a la que una extensión hace referencia en

el punto de extensión org.eclipse.core.runtime.applications. Varios plug-ins pueden definir extensiones al

punto de extensión org.eclipse.core.runtime.applications. La aplicación real utilizada en el arranque será

la aplicación especificada como argumento de arranque específico o la aplicación especificada para un

producto determinado.

Esta aplicación define las características de control de la plataforma, por ejemplo si contendrá un entorno

de trabajo y proporcionará una interfaz gráfica de usuario o si se ejecutará para realizar una tarea

específica y, a continuación, saldrá.

Mientras la aplicación se ejecute, necesitará los paquetes, las extensiones, los puntos de extensión y los

servicios con los que han contribuido los plug-ins de la plataforma. Estos plug-ins se pueden iniciar

automáticamente cuando se necesitan, basándose en la presencia y el valor del atributo Eclipse-LazyStart

especificado en el manifest.mf del plug-in. Si un plug-in se marca como Eclipse-LazyStart: true, cuando se

detecta una petición de obtención de una clase de ese cargador de clases de plug-in, si dicho plug-in aún

no está en estado activo, la infraestructura intenta primero iniciar el plug-in para hacerlo pasar del estado

resuelto al estado activo. Como parte del proceso de inicio, se invocará el método de inicio

BundleActivator para realizar cualquier inicialización necesaria para el plug-in. Si el plug-in está marcado

como Eclipse-LazyStart: false, es posible que se resuelven las clases desde el plug-in sin realmente

intentar iniciar el plug-in. La especificación de Eclipse-LazyStart:false o la total carencia de especificación

del atributo Eclipse-LazyStart tienen un comportamiento equivalente.

Una vez que la aplicación ha terminado la tarea, la infraestructura empieza el proceso de salida. En el

orden inverso a los niveles de arranque se llamarán a los plug-ins de la plataforma para que se detengan,

permitiendo de este modo que los plug-ins realicen las operaciones de limpieza necesarias para liberar

recursos.

Este producto ha añadido algunas posibilidades adicionales en el proceso de arranque además de las

posibilidades proporcionadas por las infraestructuras subyacentes de Eclipse. En primer lugar, se ha

añadido el plug-in com.ibm.rcp.lifecycle.platform a la propiedad osgi.bundles. Este plug-in procesa la

información de configuración para seleccionar un conjunto de plug-ins, asignar a esos plug-ins un nivel

de inicio y marcar esos plug-ins para el inicio persistente.


En segundo lugar, la plataforma ha definido el punto de extensión

com.ibm.rcp.lifecycle.application.startBundles, así como las API proporcionadas en el paquete

com.ibm.rcp.lifecycle.application, para permitir que las aplicaciones proporcionen a los ensambladores y

los desplegadores la posibilidad de especificar que determinados plug-ins se inicien cuando se inicie una

aplicación. Este punto de extensión se define para ayudar en el arranque de plug-ins que proporcionan

servicios y que no exportan paquetes. Dado que no exportan paquetes, no habrá referencias de clase

normales a estos plug-ins, de modo que la presencia del atributo Eclipse-LazyStart no tendrá ningún

efecto. El conjunto de plug-ins a iniciar con una aplicación se establece de forma exclusiva por aplicación.

Las API intentarán iniciar cada uno de los plug-ins especificados por el punto de extensión. Mediante el

uso de técnicas de infraestructura, las API intentarán iniciar el plug-in, invocando el método start() en el

plug-in sólo si el atributo Eclipse-LazyStart: true no se ha establecido. Cuando la aplicación complete las

tareas, las API intentarán detener cada uno de los plug-ins que ha iniciado.

Al utilizar Lotus Expeditor Client en escritorios, la aplicación predeterminada proporcionada por la

plataforma de cliente, que se identifica como com.ibm.rcp.personality.framework.RCPApplication,

proporciona soporte para las personalidades. Cada personalidad se puede considerar como una

miniaplicación. Del mismo modo, existe un punto de extensión

com.ibm.rcp.lifecycle.personality.startBundles que proporciona la posibilidad de iniciar (y detener) los

plug-ins que están asociados con una personalidad específica. Se pueden aplicar todas las mismas

características del arranque de plug-in para una aplicación específica descrita en el párrafo anterior al

arranque de plug-in para una personalidad específica. Para obtener más información, consulte Uso de

personalidades en Desarrollo de aplicaciones para Lotus Expeditor.

Lotus Expeditor Client para dispositivos sólo soporta el punto de extensión

com.ibm.rcp.lifecycle.application.startBundles. Sin embargo, este punto de extensión se puede utilizar de

forma similar al punto de extensión personality.startBundles para iniciar plug-ins cuando el entorno de

Lotus Expeditor Client se inicia en el dispositivo. Consulte Descripción del ciclo de vida de aplicación en

Desarrollo de aplicaciones para Lotus Expeditor para obtener más detalles.

Otras notas sobre el comportamiento de arranque de plug-in

El contenedor web proporciona un punto de extensión com.ibm.pvc.webcontainer.application que permite

que los plug-ins de portlet y de web locales se identifiquen a sí mismos a través de la raíz de contexto en

el contenedor web sin necesidad de que se inicie el plug-in. Cuando el contenedor web recibe una

solicitud HTTP, si aún no se ha iniciado el plug-in que proporciona una web local o una aplicación de

portlet para dicha raíz de contexto, el contenedor web lo iniciará. Esto sólo se aplicará a aplicaciones que

tienen una raíz de contexto específica. Las aplicaciones que contribuyen con el comportamiento a la raíz

de contexto / no se iniciará automáticamente. Las aplicaciones de esta categoría incluyen las aplicaciones

que utilizan el Servicio Http de OSGi para proporcionar aplicaciones de servlet.

¿Qué diferencia hay entre un paquete y un plug-in?

El término plug-in se originó con Eclipse. El término paquete se originó en las especificaciones de OSGi

Alliance. Eclipse cambió para utilizar una infraestructura OSGi como modelo de creación de componentes

subyacente. En este apartado de arranque, no hay ninguna diferencia entre un paquete y un plug-in.

¿Cómo se debe establecer el atributo Eclipse-LazyStart?

La recomendación es establecer todos los plug-ins para tener el atributo Eclipse-LazyStart con un valor de

true. Esto permitirá que los plug-ins se inicien de forma automática (o diferida) y no requerirá que se

inicien y se marquen explícitamente para el inicio persistente.

¿Por qué debo evitar tener marcados los plug-ins para el inicio persistente?

Los plug-ins marcados para el inicio persistente se iniciarán cada vez que se inicie la plataforma. Esto

puede producir un arranque más lento. Además, si la plataforma no necesita las contribuciones del


plug-in, el plug-in seguirá consumiendo recursos, reduciendo el rendimiento del entorno de ejecución o

incrementando el consumo de memoria.

¿Qué sucede con la compatibilidad con los releases anteriores?

En los releases anteriores, el producto utilizaba la presencia o la ausencia del atributo Eclipse-LazyStart

(en aquel momento denominado Eclipse-AutoStart) como desencadenante para iniciar plug-ins. En los

datos de configuración de com.ibm.rcp.lifecycle.platform y en los puntos de extensión

com.ibm.rcp.lifecycle.application.startBundles y com.ibm.rcp.lifecycle.personality.startBundles hay

disposiciones para manejar los plug-ins que se puedan haber creado siguiendo las recomendaciones de

los releases anteriores.

Contribución de plug-ins en el ciclo de vida de personalidad

Puede iniciar un plug-in cuando se inicia una personalidad específica.

En la mayoría de los casos, la infraestructura inicia automáticamente los plug-ins que están exportando

paquetes para que los utilicen otros plug-ins y contienen el atributo Eclipse-LazyStart: true cuando hay

solicitudes de una clase desde ese plug-in. En los casos en que un plug-in no proporciona paquetes para

que los utilicen otros plug-ins o en que el plug-in necesita iniciarse antes que las últimas referencias de

paquete, utilice este mecanismo para iniciar el plug-in con una personalidad.

Las personalidades le permiten personalizar el aspecto en función de las aplicaciones deseadas. Dado que

las aplicaciones pueden tener requisitos totalmente diferentes en términos de los plug-ins utilizados, al

iniciar una personalidad es mejor para el recurso iniciar sólo lo que se necesita. Puesto que Lotus

Expeditor Client permite que se ejecuten varias personalidades cuando se utiliza la RCPApplication

predeterminada, puede controlar qué plug-ins se inician basándose en una personalidad específica.

Para contribuir con un plug-in cuando se inicia una personalidad específica:

1. Identifique la personalidad de destino (com.ibm.rcp.platform.personality es el ID de la personalidad

predeterminada utilizada por RCPApplication).

2. Añada el plug-in para iniciar añadiendo com.ibm.rcp.lifecycle.personality.startBundles al paquete que

proporciona servicio o a otro paquete independiente del paquete de personalidad o del paquete que

proporciona servicio.

El plug-in se inicia cuando se inicia la personalidad de destino.

Un plug-in que necesita iniciar DB2 Everyplace puede definir la siguiente extensión para iniciar el plug-in

com.ibm.db2e cuando se inicie com.ibm.rcp.platform.personality:



<plugin>

<extension

point="com.ibm.rcp.lifecycle.personality.startBundles">

<personality id="com.ibm.rcp.platform.personality">

<bundle id="com.ibm.db2e"/>

</personality>

</extension>

</plugin>

Contribución de plug-ins en el ciclo de vida de aplicación

Puede iniciar un plug-in cuando se inicie una aplicación de Eclipse específica.

En la mayoría de los casos, la infraestructura inicia automáticamente los plug-ins que están exportando

paquetes para que los utilicen otros plug-ins y contienen el atributo Eclipse-LazyStart: true cuando hay

solicitudes de una clase desde ese plug-in. En los casos en los que un plug-in no proporciona paquetes

para que los utilicen otros plug-ins o en que el plug-in necesita iniciarse antes que las últimas referencias


de paquete, utilice el punto de extensión com.ibm.rcp.lifecycle.application.startBundles para asociar un

plug-in con una aplicación Eclipse. La aplicación Eclipse debe utilizar la API

com.ibm.rcp.lifecycle.application.BundleControl para procesar la información de punto de extensión e

iniciar los paquetes solicitados. Consulte el javadoc com.ibm.rcp.lifecycle.application.BundleControl en

Desarrollo de aplicaciones para Lotus Expeditor para esta clase si desea obtener más información y un breve

ejemplo de código. La aplicación predeterminada utilizada por la plataforma de cliente

(com.ibm.rcp.personality.framework.RCPApplication) soporta la utilización de este punto de extensión.

Para contribuir con un plug-in en el ciclo de vida de aplicación:

1. Identifique la aplicación de destino (com.ibm.rcp.personality.framework.RCPApplication es el ID de la

aplicación predeterminada).

2. Añada un punto de extensión al paquete que contiene la aplicación, añada el punto de extensión al

paquete que contiene el servicio o añada o modifique algún otro paquete para añadir el punto de

extensión.

El plug-in se inicia cuando se inicia la aplicación de destino.

Un plug-in que necesita iniciar DB2 Everyplace puede definir la siguiente extensión para iniciar el plug-in

com.ibm.db2e cuando se inicia com.ibm.rcp.personality.framework.RCPApplication:



<plugin>

<extension

point="com.ibm.rcp.lifecycle.application.startBundles">

<application id="com.ibm.rcp.personality.framework.RCPApplication">

<bundle id="com.ibm.db2e"/>

</application>

</extension>

</plugin>

Los usuarios de plataforma que utilizan la aplicación com.ibm.rcp.personality.framework.RCPApplication

predeterminada pueden asociar plug-ins adicionales que se deben iniciar, tal como se muestra en el

ejemplo anterior, y no necesitan proporcionar una aplicación propia. Si la plataforma no utiliza la

aplicación predeterminada, será necesario asociar los plug-ins con la aplicación utilizada para iniciar la

plataforma. Los paquetes se pueden asociar con más de una aplicación. Dado que sólo se utiliza una

aplicación Eclipse en el arranque, sólo se iniciarán los plug-ins asociados con dicha aplicación.

Contribución de plug-ins en el ciclo de vida de plataforma

Puede iniciar un plug-in cuando se inicie la plataforma.

La contribución de plug-ins en el ciclo de vida de plataforma permite controlar qué plug-ins se deben

iniciar cuando se inicia la plataforma. En la mayoría de los casos, la infraestructura inicia

automáticamente los plug-ins que están exportando paquetes para que los utilicen otros plug-ins y

contienen el atributo Eclipse-LazyStart: true cuando hay solicitudes de una clase desde ese plug-in. En

los casos en que un plug-in no proporciona paquetes para que los utilicen otros plug-ins o en que el

plug-in necesita iniciarse antes que las últimas referencias de paquete, utilice este mecanismo para iniciar

el plug-in con la plataforma. Las principales razones por las que los plug-ins necesitan iniciarse con la

plataforma consisten en que contienen proveedores que las clases Java base invocan y que se deben

registrar antes de intentar utilizar los recursos de clase Java base.

Tiene dos métodos para cambiar la configuración de arranque de plataforma:

Nota: Es posible definir un conjunto de paquetes de arranque que provoquen que la plataforma no se

inicie. Aunque puede ampliar el conjunto de paquetes iniciados en el arranque de plataforma, no

se recomienda cambiar los niveles de inicio o el conjunto de paquetes predeterminados.

v Despliegue un nuevo fragmento en el host com.ibm.rcp.lifecycle.platform. Si aún no existe un

fragmento en com.ibm.rcp.lifecycle.platform.plugin, cree un fragmento nuevo que contenga el archivo


customStartLevels.properties. El contenido de defaultStartLevels.properties del paquete

com.ibm.rcp.lifecycle.platform se copia en las propiedades customStartLevels. Consulte el apartado

“Empaquetado de aplicaciones para el despliegue” en la página 158 para obtener más información

sobre cómo desplegar fragmentos en el sistema.

org.eclipse.equinox.log=1

com.ibm.rcp.core.logger=3

com.ibm.pvc.jndi.provider.java=5

com.ibm.rcp.osgiagent.scheduler=10

com.ibm.osg.service.osgiagent.NativeInstallWatchDog=10

com.ibm.rcp.net.http=10

com.ibm.rcp.provisioning=10

com.ibm.rcp.core.pd.manager=10

Nuevo customStartLevels.properties:

org.eclipse.equinox.log=1

com.ibm.rcp.core.logger=3

com.ibm.pvc.jndi.provider.java=5

com.ibm.rcp.osgiagent.scheduler=10

com.ibm.osg.service.osgiagent.NativeInstallWatchDog=10

com.ibm.rcp.net.http=10

com.ibm.rcp.provisioning=10

com.ibm.rcp.core.pd.manager=10

com.yourcompany.yourbundle=10

Se añade el nuevo paquete a la lista de paquetes.

v Utilice las propiedades de sistema.

Se espera que se utilice la siguiente propiedad de sistema para realizar cambios importantes en los

niveles de inicio predeterminados especificados por el proveedor de plataforma:

– com.ibm.rcp.lifecycle.platform.defaultStartLevels – especifica el archivo de propiedades que contiene

los niveles de inicio aplicables a la plataforma.

Se espera que esta propiedad se utilice para realizar cambios importantes en los niveles de inicio

predeterminados especificados por el proveedor de plataforma.

Se espera que se utilicen las siguientes propiedades para añadir modificaciones menores a los niveles

de inicio predeterminados especificados por el proveedor de la plataforma:

– com.ibm.rcp.lifecycle.platform.startLevel.<nivelInicio>.include – se aplica después de que se haya

procesado el archivo de propiedades de niveles de inicio. El <nivelInicio> es un nivel de inicio

específico que se debe modificar respecto al valor especificado en el archivo de propiedades. El

valor es una lista separada por comas de paquetes que se deben incluir en este nivel de inicio

particular. Se pueden utilizar [services] y [legacy].

– com.ibm.rcp.lifecycle.platform.startLevel.<nivelInicio>.exclude – se aplica después de que se haya



valor es una lista separada por comas de paquetes que se deben excluir en este nivel de inicio

particular. Se pueden utilizar [services] y [legacy].

– com.ibm.rcp.lifecycle.platform.startLevel.<nivelInicio>.replace -- se aplica después de que se haya



valor es una lista separada por comas de paquetes que se deben iniciar en este nivel de inicio

particular. Se pueden utilizar [services] y [legacy]. Este valor sustituye el valor contenido en el

archivo de propiedades.

Consulte el apartado “Actualización del archivo rcplauncher.properties” en la página 97 para obtener

más información sobre cómo establecer propiedades de sistema.

Si necesita realizar adiciones o cambios menores en el conjunto de propiedades predeterminado, por

ejemplo al realizar pruebas, es posible que las propiedades de sistema sean suficientes. Si necesita realizar

cambios más significativos o necesita desplegar cambios en muchos sistemas, es posible que sea una

mejor opción utilizar un fragmento nuevo.


El plug-in se inicia cuando se inicia la plataforma.



Ensamblaje y despliegue

Este apartado describe cómo ensamblar y desplegar Lotus Expeditor Client.

Ampliación de la plataforma

Este apartado describe cómo ampliar la plataforma.

Especificación de la marca y del tema de la plataforma

El entorno de trabajo de Lotus Expeditor Client utiliza los productos de Eclipse y los temas de Eclipse




Un desarrollador sigue estos pasos para cambiar la marca de entorno de trabajo:

1. Cree un nuevo plug-in de marca (por ejemplo com.myproduct.branding).

2. Cree un archivo plugin.xml con la extensión de productos de Eclipse en el plug-in

com.myproduct.branding.

3. Incluya la propiedad preferenceCustomization en la extensión de productos para especificar el

archivo de personalización de preferencias a utilizar.

4. Incluya una extensión de temas de Eclipse en el archivo plugin.xml en el plug-in de

com.myproduct.branding.

5. Incluya un archivo de personalización de preferencias que se especifica en la extensión de productos

de Eclipse. Normalmente éste es el archivo plugin_customization.ini del plug-in

com.myproduct.branding. Éste debe contener la preferencia para establecer el tema actual.

6. Incluya la pantalla inicial que se debe utilizar para el producto en el plug-in.

7. Cree una característica para el plug-in anterior.

8. Utilice el manejador de instalación global para especificar el atributo de producto de la característica

de creación de marca en el archivo rcplauncher.properties, de forma que al iniciar se utilice el

producto y la aplicación correctos. Consulte el apartado “Utilización del manejador de instalación

global” en la página 166 para obtener detalles.

Por ejemplo, product=com.ibm.myproduct.branding.<MyProduct> donde <MyProduct> es el ID

especificado en la extensión de productos del paso 2.

9. Utilice el manejador de instalación global para establecer la propiedad de sistema Java

osgi.splashPath (-Dosgi.splashPath=) de la característica de creación de marca para cambiar la

pantalla inicial en el archivo rcplauncher.properties. La sintaxis debe ser la sintaxis de URL. Por

ejemplo, platform\:/base/../shared/eclipse/plugins/com.myproduct.branding.

10. Despliegue la característica de creación de marca como parte de la instalación inicial actualizando el

manifiesto de suministro.

Cómo proporcionar una marca de producto propia

La marca de producto se especifica en el punto de extensión de producto de Eclipse.

A continuación se proporciona el código de ejemplo para la marca predeterminada utilizada por Lotus

Expeditor Client:

<extension

id="DefaultProduct"

point="org.eclipse.core.runtime.products">

<product

name="%product.name"


application="com.ibm.rcp.personality.framework.RCPApplication"

description="%product.description">

<property name="appName" value="DefaultPlatform" />

<property name="aboutText" value="%productAboutText" />

<property name="windowImages" value="icons/16.gif,images/32.gif" />

<property name="aboutImage" value="icons/productAbout.bmp" />

<property name="preferenceCustomization" value= "platform:/plugin/

com.ibm.rcp.platform.personality.branding/plugin_customization.ini"/>

</product>

</extension>

Para desplegar su propia marca, debe crear una característica y un plug-in de marca nuevos y

desplegarlos como parte de la instalación inicial actualizando el manifiesto de suministro. La nueva

característica de marca debe utilizar el manejador de instalación global para modificar el atributo de

producto en el archivo rcplauncher.properties.

Utilice el fragmento anterior como ejemplo para proporcionar su marca. Sustituya

com.ibm.rcp.platform.personality.branding en el fragmento anterior por el nombre del plug-in de

marca.

Especificación del título de la ventana

La barra de título aparece en la parte superior de la plataforma de cliente y generalmente contiene el

nombre del entorno de trabajo y un pequeño gráfico.

Para modificar la barra de título del producto, especifique el atributo de nombre de la extensión de

producto en el archivo plugin.xml del plug-in de marca.

Ejemplo de código de la extensión de producto en el archivo plugin.xml:

<extension

id="MyProduct"


<product name="%product.name"

application ...

Proporcione el valor real del nombre de producto en el archivo plugin.properties del plug-in de marca.

Ejemplo de código de plugin.properties:

# Nombre de producto

product.name=MyProduct

Ejemplo de código de plugin_<entorno_local>.properties:

# Comentario específico de entorno local

product.name=<Serie específica de entorno local>

Especificación de la imagen de ventana

En los sistemas Windows, se asocia una imagen pequeña con el producto que se muestra en la barra de

título, junto al nombre del producto. Si lo desea, puede modificar esta imagen para que sea coherente con

su marca.

SWT (Standard Widget Tools) permite asociar un conjunto de imágenes con un shell de modo que todas

las imágenes del conjunto tengan el mismo aspecto pero se representen en distintos tamaños. Estas

imágenes se proporcionan en el shell de SWT, que puede seleccionar la imagen más apropiada para cada

uso específico. La imagen más pequeña (16 X 16), por ejemplo, se utiliza para las barras de título y de

tareas, mientras que la imagen más grande (32 X 32) se utiliza en el conmutador de aplicaciones Alt-Tab.

Ejemplo de código:


<extension

id="MyProduct"



application="com.ibm.eswe.workbench.WctWorkbenchApplication"


<property name="windowImages"

value="platform:/plugin/com.myco.my.example/exampleimages/16.gif,

platform:/plugin/com.myco.my.example/exampleimages/32.gif" />

...

Especificación de la imagen del diálogo Acerca de

Para especificar la marca del diálogo Acerca de, debe especificar la imagen mostrada en el recuadro de

diálogo Acerca de y también el texto que se visualiza junto a la imagen del plug-in de marca.

La imagen que se muestra en el diálogo Acerca de debe ser un archivo con una extensión .bmp. Se

muestra una imagen de producto de tamaño completo (no mayor que 500 x 330 pixels) sin el texto

″aboutText″. Se muestra una imagen de producto de la mitad de tamaño (no mayor que 250 x 330 pixels)

con el texto ″aboutText″ junto a ella.

Ejemplo de código:

<extension

id="MyProduct"






value="platform:/plugin/com.myco.example/exampleimages/16.gif,

platform:/plugin/com.myco.example/exampleimages/32.gif" />

<property name="aboutImage"

value="platform:/plugin/com.myco.example/exampleimages/productAbout.bmp"/>

Puede tener una imagen del diálogo Acerca de distinta para cada entorno local admitido por el producto.

Cuando un usuario abre el diálogo Acerca de, el sistema detecta el entorno local de la máquina y, a

continuación, selecciona la imagen de diálogo Acerca de en el directorio de idioma apropiado del

directorio de plugins. Por ejemplo, una pantalla inicial para el entorno local francés residirá en el

directorio com.myco.example.nl<número_grupo_nl>_<número_versión>\nl\exampleimages\fr.

Si el sistema no encuentra una imagen de diálogo Acerca de para el entorno local, el sistema selecciona la

imagen predeterminada en el directorio com.myco.example_<número_versión>\exampleimages.

Especificación del texto de diálogo Acerca de

Especifique el texto que se visualiza junto a la imagen en el diálogo Acerca de en el archivo

plugin.properties del plug-in de marca. El archivo plugin.properties es específico del entorno local.

Ejemplo de código:

<extension

id="MyProduct"




description="%product.description"^


value="platform:/plugin/com.myco.example/exampleimages/16.gif,

platform:/plugin/com.myco.example/exampleimages/32.gif" />

<property name="aboutImage"

value="platform:/plugin/com.myco.example/exampleimages/productAbout.bmp"/>


Ensamblaje y despliegue 129

De plugin.properties:

# Texto de Acerca de

productAboutText=<Información crítica sobre el producto>

Puede tener texto de diálogo Acerca de diferente para cada entorno local que el producto soporte. Por

ejemplo, de plugin_<entorno_local>.properties del fragmento

com.myco.mytheme.nl<número_grupo_entorno_local>:

# Comentario específico de entorno local

productAboutText=Serie específica de entorno local

Especificación de la pantalla inicial

Cuando un usuario lanza el entorno de trabajo, se visualiza una imagen en una pantalla inicial. Si lo

desea, puede sustituir la imagen de esta pantalla puede su propia imagen. Este archivo debe tener la

extensión .bmp. No hay limitaciones relacionadas con el tamaño de la imagen, por, a modo de referencia,

cabe indicar que la imagen de la pantalla inicial estándar de Eclipse tiene un tamaño de 500x300 píxeles.

Es posible tener una pantalla inicial distinta para cada entorno local admitido por el producto. Cuando se

inicia la aplicación, el iniciador determina el entorno local de la máquina y selecciona la imagen de la

pantalla inicial del directorio del idioma apropiado del directorio plugins. Por ejemplo, la pantalla inicial

para el entorno local en francés residiría en el directorio nl/fr.

Para utilizar su propia pantalla inicial, incluya la imagen inicial en el plug-in de marca. En la

característica de marca, utilice el manejador de instalación global para establecer la propiedad de sistema

osgi.splashPath de Java (-Dosgi.splashPath=). La sintaxis debe ser la sintaxis de URL. Por ejemplo,

-Dosgi.splashPath=platform:\base/../shared/eclipse/plugins/com.ibm.sample.screen.

La pantalla inicial se utiliza para visualizar el estado durante la creación de espacios de trabajo y también

al procesar operaciones de suministro. Si cambia la pantalla inicial respecto a la imagen predeterminada,

también necesitará reconfigurar el color del texto de primer plano y las coordenadas de los rectángulos

de las barras de progreso y los mensajes de estado.

Para utilizar el supervisor de progreso de la pantalla inicial, se deben configurar el color de mensaje de

primer plano, el área de mensajes y el área de la barra de progreso. El área de mensajes y el área de la

barra de progreso se definen como ″x,y,length,width″ en relación a la imagen inicial. El color se define

como una serie hexadecimal de 6 caracteres: los dos primeros representan el rojo, los dos segundos el

verde y los dos terceros el azul. El uso del supervisor de progreso de pantalla inicial realizará una

búsqueda en la secuencia siguiente para identificar las ubicaciones de área de mensajes y de barra de

progreso. Los rectángulos de mensajes y progreso se deben establecer o, de lo contrario, no se utilizarán

los valores de dicho grupo. En otras palabras, si se encuentra que una definición de producto sólo tenía

una definición de barra de rectángulo de progreso y no una barra de rectángulo de mensaje, se salta esa

opción y se procesa la opción siguiente.

1. Como propiedades de la definición de producto que se está lanzando. Esto depende de que

Platform.getProduct() devuelva una definición de producto.

<extension

id="BaseProduct"


<product

name="BaseProduct" application="com.ibm.rcp.personality.framework.RCPApplication"


<property name="appName" value="DefaultPlatform" />


<property name="windowImages" value="icons/16.gif,icons/32.gif" />

<property name="aboutImage" value="icons/productAbout.bmp" />

<property name="preferenceCustomization"

value="platform:/plugin/com.ibm.rcp.platform.personality.branding/plugin_customization.ini"/>

<property name="startupMessageRect" value="0, 0, 400, 20"/>


<property name="startupProgressRect" value="0, 40, 400, 20"/>

<property name="startupForegroundColor" value="ABCDEF"/>

</product>

</extension>

Mientras que esto se puede utilizar para definir las propiedades, la definición de producto no está

disponible durante la creación de espacios de trabajo.

2. Como preferencias asociadas con el producto especificado durante el lanzamiento. Este procedimiento

busca en los argumentos de línea de mandatos para encontrar -product y el nombre asociado. Lo

utiliza como nombre de nodo para localizar las preferencias. Permite a los productos definir sus

propias ubicaciones para la barra de progreso y mensajes. Por ejemplo, añada lo siguiente a

plugin_customization.ini. Si se inicia con com.ibm.rcp.platform.personality.branding.DefaultProduct, se

utilizarán estas opciones:

com.ibm.rcp.platform.personality.branding.DefaultProduct/startupForegroundColor=00FF00

com.ibm.rcp.platform.personality.branding.DefaultProduct/startupProgressRect=6,6,410,20

com.ibm.rcp.platform.personality.branding.DefaultProduct/startupMessageRect=6,210,487,10

3. Como preferencias asociadas con com.ibm.rcp.provisioning.

Similar al punto 2, excepto en que en lugar de un nombre de producto, se utiliza

com.ibm.rcp.provisioning como nombre de nodo

4. Como propiedades de sistema.

rcplauncher -vmargs -DstartupForegroundColor=CAFE00 -DstartupProgressRect=4,5,6,7 -DstartupMessageRect=1,2,3,4

Se pueden especificar propiedades de sistema en rcpinstall.properties, como propiedades de sistema

en mandatos de configuración en el archivo rcplauncher.properties.

Especificación de la página de inicio de ayuda propia

Se puede acceder al contenido de la ayuda para el producto pulsando Ayuda → Contenido de la ayuda.

Para cambiar la página de inicio de ayuda predeterminada por una para su propio producto, proporcione

la nueva página de ayuda como un fragmento en org.eclipse.help.base. Debe utilizar un nombre

diferente del que se utiliza actualmente (por ejemplo help_home.html y rcp_help_home.html ya se

utilizan). El fragmento de ayuda predeterminado proporcionado por Lotus Expeditor Client es

com.ibm.rcp.platform.personality.branding.help. Se recomienda que lo utilice como ejemplo para crear su

propio fragmento de ayuda. No se recomienda realizar cambios en el fragmento proporcionado por Lotus

Expeditor Client ni utilizar dicho fragmento modificado.

El plug-in de marca de producto debe contener la preferencia de página de ayuda en el archivo

plugin_customization.ini de producto, por ejemplo:

org.eclipse.help.base/help_home=/org.eclipse.help.base/doc/myproduct_help_home.html

Especificación del tema

El aspecto general del cliente se controla mediante una combinación de extensiones de temas de Eclipse y

del contenido de hojas de estilo en cascada (CSS).

Los elementos específicos de la marca de producto, por ejemplo el color o la visibilidad de la barra de

mensaje de cabecera los controlan elementos de clave/valor de datos dedicados de una extensión de tema

de Eclipse. El aspecto para elementos tales como el botón de lanzamiento, las barras de herramientas y la

fábrica de presentación lo controla el contenido de CSS.

El área del mensaje de cabecera está formada por una imagen a la derecha, una imagen a la izquierda y

una imagen de fondo en mosaico. Al pasar de una aplicación a otra cambiarán el nombre y las imágenes

que se visualizan en el área del mensaje de cabecera. El sistema obtiene el nombre de la aplicación que

debe utilizarse de las aplicaciones que han contribuido mediante puntos de extensión o definiciones de

aplicación compuesta.


El área del mensaje de cabecera se encuentra en la parte superior de la ventana del entorno de trabajo,

directamente por debajo de la barra de menús. Puede personalizar todos los elementos visuales del

mensaje de cabecera para adaptarlos a sus necesidades:

v Imágenes de mensajes de cabecera

v Color de fondo de mensaje de cabecera

v Título de aplicación de mensaje de cabecera (font, posición, color y texto)

Especificación de la imagen de mensaje de cabecera

Puede especificar las imágenes de mensaje de cabecera en el archivo plugin.properties del plug-in de

marca. A continuación se muestra un ejemplo de un tema de Eclipse:

<extension

point="org.eclipse.ui.themes">

<theme id="MyProductGreenTheme">

<description>

This is the My Product Green Theme

</description>

...

<data

name="com.ibm.rcp.platform.BRANDING_BAR_IMAGE_BACKGROUND"

value="platform:/plugin/com.myco.example/exampleicons/stripe.gif">

</data>

<data

name="com.ibm.rcp.platform.BRANDING_BAR_IMAGE_LEFT"

value="platform:/plugin/com.myco.example/exampleicons/brand_bar_left.gif">

</data>

<data

name="com.ibm.rcp.platform.BRANDING_BAR_IMAGE_RIGHT"

value="platform:/plugin/com.myco.example/exampleicons/brand_bar_right.gif">

</data>

<data

name="com.ibm.rcp.platform.BRANDING_BAR_VISIBLE"

value="true">

</data>

...

Especificación de la imagen de fondo

La imagen de fondo es la imagen que se muestra en el área principal de datos del entorno de trabajo si

no hay ninguna aplicación abierta. Puede especificar el fondo para visualizar su propia imagen.

Una imagen de fondo de un tamaño menor que 500 x 330 pixels se pondrá en el mosaico en las

orientaciones x e y. Una imagen de fondo de 500 x 330 pixels o más se centrará.

Ejemplo de código para la imagen de fondo predeterminada utilizada por Lotus Expeditor Client:

<extension



<description>


</description>

...

<data name="WORKBENCH_BG_IMAGE"


value="platform:/plugin/com.ibm.rcp.platform.personality.branding

/icons/default_background.gif"/>

...

Utilice el ejemplo de código anterior como guía para especificar su propia imagen de fondo. Sustituya

com.ibm.rcp.platform.personality.branding por el nombre del plug-in de marca.

También puede cambiar la vía de acceso de imagen y el nombre de archivo especificando la propiedad

defaultBackgroundImage en el archivo plugin_customization.ini del archivo plugin.xml del plug-in de

marca.

Para apuntar a una imagen del directorio nl, puede establecer el valor de defaultBackgroundImage en

$nl$/new_default_background.gif.

Especificación del color del mensaje de cabecera

Puede especificar el color del mensaje de cabecera en el archivo plugin.properties del plug-in de marca. A

continuación se muestra un ejemplo de un tema de Eclipse:

<extension



<description>


</description>

...

<colorDefinition

label="%BrandingBarForegroundColor"

value="255,255,255"

id="com.ibm.rcp.platform.BRANDING_BAR_FOREGROUND_COLOR">

<description>

</description>

</colorDefinition>

<colorDefinition

label="%BrandingBarBackgroundColor"

value="0,0,0"

id="com.ibm.rcp.platform.BRANDING_BAR_BACKGROUND_COLOR">

<description>

</description>

</colorDefinition>

<colorDefinition

label="%BrandingBarBackgroundColorBegin"

value="56,56,56"

id="com.ibm.rcp.platform.BRANDING_BAR_BACKGROUND_COLOR_BEGIN">

<description>

</description>

</colorDefinition>

<colorDefinition

label="%BrandingBarBackgroundColorEnd"

value="80,80,80"

id="com.ibm.rcp.platform.BRANDING_BAR_BACKGROUND_COLOR_END">

<description>

</description>

</colorDefinition>

...

Especificación del font de título de aplicación del mensaje de cabecera

Puede especificar el color del mensaje de cabecera en el archivo plugin.properties del plug-in de marca. A

continuación se muestra un ejemplo de un tema de Eclipse:


<extension



<description>


</description>

...

<data

name="com.ibm.rcp.platform.BRANDING_BAR_FONT_POINT_SIZE"

value="14">

</data>

....

Especificación de la línea de estado

Puede especificar si el producto debe tener una Línea de estado o no en el archivo plugin.properties del

plug-in de marca. A continuación se muestra un ejemplo de un tema de Eclipse:

<extension point="org.eclipse.ui.themes">


<description>


</description>

...

<data

name="com.ibm.rcp.platform.STATUS_LINE_VISIBLE"

value="true">

</data>

Especificación de un tema utilizando el contenido de CSS

Para contribuir en un tema utilizando el contenido de CSS, primero necesita ampliar el punto de

extensión com.ibm.rcp.ui.themes. Las extensiones de temas especifican el contenido de CSS, un nombre

que las personas puedan leer para el tema y una imagen de vista previa opcional para el tema. A

continuación se muestra un ejemplo de extensión de tema. Consulte el esquema de Temas en Desarrollo de

aplicaciones para Lotus Expeditor.

<extension

point="com.ibm.rcp.ui.themes">

<theme

id="com.ibm.rcp.ui.themes.mytheme"

label="MYTEST Theme"

css="themes/global.css"

previewImage="themes/mytesttheme_preview.png">

</theme>

</extension>

El tema actual se especifica utilizando una preferencia de Eclipse. El ID de preferencia utilizado para

especificar el tema es WED_THEME_PREFERENCE en el espacio de nombres com.ibm.rcp.ui. Esta preferencia se

debe especificar en plugin_customization.ini del plug-in de creación de marca. A continuación se muestra

un ejemplo de cómo especificar el valor de esta preferencia:

com.ibm.rcp.ui/WED_THEME_PREFERENCE= com.ibm.rcp.ui.themes.mytheme

A continuación, cree un archivo CSS y añada los nuevos estilos al mismo. Tenga en cuenta que necesitará

importar el archivo CSS de plataforma. La sintaxis para importar el archivo CSS es la siguiente:

@import url("platform:/plugin/com.ibm.rcp.ui.css/themes/wed61/global.css");

Distribución de actualizaciones de marca

Para desplegar su propia marca, cree un plug-in y una característica de marca nuevos y despliéguela

como parte de la instalación inicial actualizando el manifiesto de suministro o utilizando cualquiera de

las posibilidades de suministro.


La propiedad product del archivo rcpinstall.properties se debe actualizar para hacer referencia al ID de

producto definido por el plug-in de marca nuevo. Consulte el apartado “Actualización del archivo

rcpinstall.properties” en la página 101 para obtener más información.

Configuración de la creación de marca del contenedor de portlets

Puede modificar el aspecto de los portlets. Utilice las instrucciones de este apartado para modificar los

elementos de interfaz de usuario de portlet utilizados por el contenedor de portlets.

La extensión de creación de marca del contenedor de portlets se aplica a todos los portlets desplegados

en el entorno de ejecución de IBM Lotus Expeditor.

Estas instrucciones incluyen la creación y el despliegue de una aplicación web de creación de marca. Esta

aplicación web incluirá los elementos de interfaz de usuario de portlet incluyendo la hoja de estilo

HTML, los iconos y los colores de pantalla.

Para modificar el aspecto de los portlets, siga estos pasos:

1. Cree un proyecto web de servicios de cliente. Consulte ″Desarrollo de aplicaciones web″ en Desarrollo

de aplicaciones para Lotus Expeditor para obtener instrucciones sobre cómo crear una aplicación web.

2. Seleccione Importar → General → Sistema de archivos para añadir los recursos de creación de marca

(hoja de estilo e iconos, por ejemplo) a la aplicación web.

3. Abra el descriptor de plugin.xml y añada una contribución de extensión

com.ibm.rcp.portletcontainer.branding.theme.

A continuación se muestra un ejemplo de una extensión de creación de marca para Expeditor

6.1.2:

<extension point="com.ibm.rcp.portletcontainer.branding.theme">

<theme styleSheet="/theme/Styles.css"

maximizeIcon="/images/maximize.gif"

minimizeIcon="/images/minimize.gif"

restoreIcon="/images/back.gif"

editIcon="/images/edit.gif"

helpIcon="/images/help.gif"

aboutIcon="/images/about.gif"

configIcon="/images/config.gif"

editDefaultsIcon="/images/edit_defaults.gif"

previewIcon="/images/preview.gif"

printIcon="/images/print.gif"

titleBarColor="#5495D5"

contentColor="#FFFFFF"/>

</extension>

A continuación se muestra un ejemplo de una extensión de creación de marca para Expeditor 6.1.1:

<extension point="com.ibm.rcp.portletcontainer.branding.theme">

<theme styleSheet="/theme/Styles.css"

maximizeIcon="/images/maximize.gif"

minimizeIcon="/images/minimize.gif"

restoreIcon="/images/back.gif"

editIcon="/images/edit.gif"

helpIcon="/images/help.gif"

titleBarColor="#5495D5"

contentColor="#FFFFFF"/>

</extension>

Nota: Los administradores deben modificar las vías de acceso de recursos para comparar cómo se

empaquetan los recursos en la aplicación web.

4. Pulse el botón Guardar para guardar todos los cambios efectuados en el descriptor de plugin.xml. La

aplicación web de creación de marca está ahora preparada para distribuirse al entorno de ejecución de

IBM Lotus Expeditor.


||

|||||||||||||||

5. Consulte “Empaquetado de aplicaciones para el despliegue” en la página 158 para obtener

instrucciones sobre cómo distribuir la aplicación web de creación de marca.

Configuración de definiciones de empresa (JNDI)

En esta sección se describe cómo desplegar una aplicación que está configurada con un conjunto inicial

de definiciones de empresa.

Visión general de JNDI de Lotus Expeditor Client

El entorno de ejecución de Lotus Expeditor Client proporciona un registro JNDI de objetos Java simple

para soportar las necesidades de definición de objetos de empresa de las aplicaciones web, las

aplicaciones EJB y las aplicaciones de mensajería.

El proveedor de JNDI de Lotus Expeditor Client permite que un directorio de denominación local para

objetos que se ejecutan en la plataforma cliente se comuniquen a través de las API de denominación Java

estándar. La implementación de JNDI de cliente de entorno de ejecución es muy ligera y no soporta la

federación de otros espacios de nombres, pero en lugar de ello proporciona un espacio de nombres

jerárquico simple para las aplicaciones cliente. En la mayoría de los casos, las aplicaciones que

aprovechan JNDI no necesitan interactuar directamente con los objetos de nombre JNDI y simplemente

utilizan representaciones String (serie) de los nombres que se deben enlazar o localizar. Si la aplicación

necesita interactuar directamente con objetos CompoundName de JNDI, tenga en cuenta que debido a la

implementación ligera, sólo se soporta un conjunto restringido de propiedades de sintaxis de JNDI para

utilizarse al crear un objeto CompoundName. Con el fin de garantizar que se utilicen las propiedades de

sintaxis JNDI correctas, use simplemente la implementación de NameParser proporcionada del proveedor

de JNDI de Lotus Expeditor Client cuando se necesite un objeto CompoundName.

Se puede acceder directamente al proveedor JNDI de Lotus Expeditor Client a través de la clase

InitialContextFactory del proveedor como se muestra más abajo:

try {

Hashtable env = new Hashtable();

env.put(Context.INITIAL_CONTEXT_FACTORY,

"com.ibm.pvc.jndi.provider.java.InitialContextFactory");

InitialContext context = new InitialContext(env);

} catch (NamingException e) {

e.printStackTrace();

}

Dado que este proveedor de JNDI también está registrado como proveedor JNDI predeterminado para la

plataforma de Lotus Expeditor Client, aunque no se especifique ningún proveedor, éste utilizará de todas

formas la clase InitialContextFactory anterior para generar el objeto InitialContext.

Puesto que el proveedor JNDI de Lotus Expeditor Client no mantiene los objetos ni la información de

estado de los mismos a lo largo de los reinicios de plataforma, el administrador de plataforma es

responsable de enlazar los objetos cada vez que se inicia la plataforma y de configurar dichos objetos

como sea necesario antes de enlazarlos en el registro JNDI. Mientras la propia aplicación puede registrar

a nivel de programa los objetos que necesita cada vez que se inicia la plataforma, Lotus Expeditor Client

proporciona otro modelo declarativo para los enlaces JNDI.

Los objetos que deben enlazarse a JNDI pueden declararse mediante puntos de extensión de Eclipse, que

se describirán con detalle más adelante, de modo que, cuando se realice una solicitud de búsqueda para

un objeto específico a través de su nombre JNDI, el proveedor de JNDI localizará la definición

declarativa, creará el objeto y lo devolverá a la aplicación de cliente a petición. Esta creación ″diferida″ de

objetos proporciona un inicio más rápido de la plataforma y una asignación de memoria basada en las

necesidades del momento, y no en la cantidad de memoria necesaria estimada.

Esta capacidad se basa en dos características de los paquetes y plug-ins:


1. Debe existir un plugin.xml y éste debe proporcionar una entrada para el punto de extensión

com.ibm.pvc.jndi.provider.java.binding

2. Si el paquete/plug-in tiene un archivo Manifest.mf, éste debe contener la entrada Eclipse-LazyStart:

true.

Lotus Expeditor Toolkit utiliza esta posibilidad declarativa de JNDI para generar automáticamente las

entradas plugin.xml y Manifest.mf necesarias para los EJB para que el proveedor JNDI de Lotus

Expeditor Client pueda localizar la información declarativa al realizar una búsqueda del nombre JNDI.

Utilización del JNDI declarativo

El componente de JNDI declarativo se basa en un punto de extensión de Eclipse.

El uso del registro de puntos de extensión de Eclipse ofrece la capacidad de añadir y eliminar objetos

dinámicamente del registro JNDI ya que se proporcionan puntos de extensión como parte de los archivos

plugin.xml de los artefactos de instalación.

Este punto de extensión de enlace JNDI se denomina com.ibm.pvc.jndi.provider.java.binding.

A continuación se muestra un ejemplo de uso de este punto de extensión:

<extension

point = "com.ibm.pvc.jndi.provider.java.binding”>

<binding

jndi-name=”java:comp/env/jdbc/dsname”

objectFactory-id=”com.ibm.pvc.jndi.provider.java.GenericObjectFactory”>

</binding>

</extension>

Observe que el componente necesario del punto de extensión com.ibm.pvc.jndi.provider.java.binding

es objectFactory-id. Lotus Expeditor Client proporciona las implementaciones de ObjectFactory

siguientes:

v EJBObjectFactory

v GenericObjectFactory

v TxnDataSourceObjectFactory

v WSObjectFactory

v ManagedDSObjectFactory

v JMSConnectionFactory

v JMSTopicFactory

v JMSQueueFactory

EJBObjectFactory se utiliza exclusivamente para paquetes de contenedores de transacciones incorporados,

mientras que GenericObjectFactory permite una descripción XML de cualquier objeto Java, incluyendo

parámetros de constructor primitivos, y la posibilidad de llamar a métodos en el objeto una vez que se ha

creado, pero antes de enlazarlo al registro JNDI y devolverlo a una aplicación de cliente.

TxnDataSourceObjectFactory proporciona la posibilidad de crear y enlazar objetos DataSource con

posibilidad de transacción JNDI que son necesarios para el contenedor de transacciones incorporado.

WSObjectFactory permite que el creador de apéndices de Servicios Web proporcione información sobre el

apéndice para que éste se pueda identificar en una llamada de búsqueda JNDI. ManagedDSObjectFactory

proporciona soporte para objetos JDBC DataSources gestionados, mientras que JMSConnectionFactory,

JMSTopicFactory y JMSQueueFactory proporciona soporte de JMS para los componentes de mensajería de

plataforma de Micro Broker.

Nota: independientemente de la fábrica de objetos específica que se utilice, todos los objetos JNDI

descritos declarativamente son necesarios para proporcionar el punto de extensión


com.ibm.pvc.jndi.provider.java.binding en los archivos plugin.xml. Asimismo es posible que

algunas fábricas de objetos proporcionen otro punto de extensión que también necesite

implementarse, como GenericObjectFactory.

ManagedDSObjectFactory proporciona un punto de extensión de Eclipse (que se describe utilizando un

archivo de definición de esquema) que permite la descripción de objetos JDBC DataSource de Java

gestionados que se deben enlazar a JNDI al realizarse una búsqueda de JNDI de cliente.

ManagedDSObjectFactory es responsable del proceso de definiciones declarativas del punto de extensión

com.ibm.rcp.database.core.datasource y de la creación del objeto JDBC DataSource que se debe

gestionar. Para obtener más información sobre la utilización de este objectFactory, consulte “Definición de

orígenes de datos gestionados” en la página 141, la definición de esquema para el punto de extensión

com.ibm.rcp.database.core.datasource, y la sección Gestión del ciclo de vida de bases de datos en

Desarrollo de aplicaciones para Lotus Expeditor.

Las fábricas de objetos JMSConnectionFactory, JMSTopicFactory y JMSQueueFactory proporcionan puntos

de extensión Eclipse (que se describen utilizando un archivo de definición de esquema) que permiten la

descripción de los objetos JMS de Java que se deben enlazar a JNDI al realizarse una búsqueda de JNDI

de cliente. Estas objectFactories son las responsables del proceso de definiciones declarativas de los

puntos de extensión com.ibm.msg.client.jmsconnectionfactory, com.ibm.msg.client.jmstopic y

com.ibm.msg.client.jmsqueue, y de la creación de objetos JMS para dar soporte a la mensajería de

empresa en IBM Lotus Expeditor. Para obtener más información sobre la utilización de estos puntos de

extensión, consulte la sección sobre el registro de forma declarativa de objetos administrados por JMS en


EJBObjectFactory:

EJBObjectFactory es responsable de gestionar el ciclo de vida de los EJB en el entorno de ejecución de

Lotus Expeditor Client.

Una vez realizada la búsqueda de cliente de un EJB, el proveedor JNDI utilizará EJBObjectFactory para

localizar el EJB e iniciarlo, lo que a su vez hará que el EJB se registre en el contenedor de EJB y se enlace

a JNDI. Lotus Expeditor Toolkit generará automáticamente las entradas de plugin.xml apropiadas para

los EJB como parte del proceso de despliegue y también añadirá la entrada Eclipse-LazyStart: true en el

archivo de manifiesto para asegurarse de que el EJB no se inicie automáticamente cuando se inicie la

plataforma, sino que en lugar de ello lo iniciará EJBObjectFactory una vez realizada la búsqueda de

cliente JNDI.

GenericObjectFactory:

Esta fábrica proporciona un punto de extensión de Eclipse (que se describe a través de un archivo de

definición de esquema) que permitirá la descripción de los objetos Java que se deben enlazar a JNDI al

realizarse una búsqueda de JNDI de cliente.

Un ejemplo del uso del nuevo punto de extensión para crear una instancia de un objeto DB2 Everyplace

DataSource es el siguiente:

<extension point="com.ibm.pvc.jndi.provider.java.genericobject">

<object

jndi-name="java:comp/env/jdbc/dsname"

class="com.ibm.db2e.jdbc.DB2eDataSource"

<method name="setUrl">

<method-parameter

type="String"

value="jdbc:db2e:oedb">

</method-parameter>

</method>

</object>

</extension>


La definición de punto de extensión de com.ibm.pvc.jndi.provider.java.genericobject permite:

v el nombre de jndi del objeto

v especificar un nombre de clase por entrada de objeto,

v una lista de parámetros que incluyen el tipo (tipos soportados listados más abajo) y el valor a utilizar

para crear la llamada de constructor que se debe ejecutar para crear este objeto,

v una lista de métodos que se deben llamar para este objeto incluyendo parámetros con el tipo (tipos

soportados listados más abajo) y el valor a utilizar en las llamadas de método.

Nota: Los valores de parámetro pueden incluir propiedades de sistema Java que se resolverán cuando se

cree la instancia del objeto. Especifique una propiedad de sistema Java utilizando la sintaxis

${propertyname}. Si la propiedad no existe, se pondrá en su lugar una serie vacía. Las propiedades

especiales _workspace y _configuration se han definido y remiten a las áreas de espacio de trabajo

o configuración actuales, basándose en las llamadas de método a

org.eclipse.core.runtime.Platform.getInstanceLocation() y getConfigurationLocation(). A

continuación se proporciona un ejemplo de la utilización de esta sustitución de propiedad:

<method-parameter

type=String

value="jdbc:db2e:${_workspace}/oedb">

</method-parameter>

Los atributos jndi-name y class son los únicos atributos necesarios.

La lista de tipos válidos para los parámetros es la siguiente:

v Objetos: Boolean, String, Integer, Short, Long, Float, Double

v Primitivos: boolean, int, short, long, float, double

TxnDataSourceObjectFactory:

El componente JNDI declarativo TxnDataSourceObjectFactory permite que esta transformación de objeto

se describa de forma declarativa a través de puntos de extensión de Eclipse.

Para crear orígenes de datos con posibilidad de transacciones que son necesarias para el contenedor de

transacciones incorporado del entorno de ejecución de Lotus Expeditor Client, se pasan objetos

DataSource estándares, tales como com.ibm.db2e.jdbc.DB2eDataSource al método

com.ibm.pvc.txncontainer.TxnDataSourceFactory.create() y se devuelve un DataSource adecuado para

utilizarse en transacciones incorporadas. Dado que TxnDataSourceObjectFactory aprovecha el mismo

punto de extenxión com.ibm.pvc.jndi.provider.java.genericobject que

com.ibm.pvc.jndi.provider.java.genericobjectfactory, la definición de origen de datos es la misma,

pero en la definición del propio enlace, se utiliza TxnDataSourceObjectFactory.

Nota: Dado que el objetivo de este ObjectFactory es crear orígenes de datos (DataSources) con

posibilidad de transacciones, el valor para el elemento de clase del punto de extensión

genericobject debe implementar javax.sql.DataSource. Si la clase proporcionada no lo

implementa, Factory generará InvalidObjectException y no se encontrará el objeto JNDI que se

está ubicando.

El ejemplo siguiente muestra cómo crear un DB2eDataSource que el contenedor de transacciones

incorporadas pueda utilizar.

extension point="com.ibm.pvc.jndi.provider.java.binding">

<binding

jndi-name="java:comp/env/jdbc/txndsname"

objectFactory-id="com.ibm.pvc.txncontainer.TxnDataSourceObjectFactory">

</binding>

</extension>


<extension point="com.ibm.pvc.jndi.provider.java.genericobject">

<object

jndi-name="java:comp/env/jdbc/txndsname"

class="com.ibm.db2e.jdbc.DB2eDataSource">

<method name="setUrl">

<method-parameter

type="String"

value="jdbc:db2e:oedb">

</method-parameter>

</method>

</object>

</extension>

WSObjectFactory:

WSObjectFactory es responsable de proporcionar una instancia inicializada anteriormente del apéndice de

cliente de servicios Web para Apache Axis en el entorno de ejecución de IBM Lotus Expeditor.

Una vez realizada una búsqueda de cliente del apéndice de cliente utilizando JNDI, el proveedor JNDI

utilizará WSObjectFactory para localizar el apéndice de servicio Web basándose en la definición de

extensión, lo que a su vez hará que el apéndice se inicialice y se enlace a JNDI.

IBM Lotus Expeditor Toolkit genera automáticamente las entradas de plugin.xml apropiadas para el

apéndice como parte del proceso de desarrollo. Se necesitará el desarrollador de apéndices o el

desplegador para rellenar los valores adecuados.

El ejemplo siguiente muestra cómo registrar la interfaz de servicio con Wsfactoryobject:

<extension point="com.ibm.pvc.jndi.provider.java.binding">

<binding jndi-name="com.ibm.test.EchoService"

objectFactory-id= "com.ibm.rcp.ws.objectfactory.WSObjectFactory">

</binding>

</extension>

<extension point="com.ibm.rcp.ws.objectfactory.WSfactoryobject">

<WSobject

account-key="username.us.ibm.com"

class="com.ibm.test.EchoService"

jndi-name="com.ibm.test.EchoService">

</WSobject>

</extension>

Donde: account-key es el nombre de la cuenta, class es el nombre de clase de la interfaz de servicio y

jndi-name es el nombre que el cliente utilizará para buscar la instancia de apéndice.

Ampliación del JNDI declarativo

La solución JNDI declarativo aprovecha el registro de punto de extensión de Eclipse a fin de

proporcionar un medio para declarar una lista de objetos que tengan que enlazarse en JNDI si y cuando

una aplicación cliente intenta localizarlos.

Para proporcionar un mecanismo apropiado para este fin, el componente JNDI declarativo utiliza la

interfaz ObjectFactory de JNDI como modo de separar el proveedor JNDI del código de implementación

específico necesario para crear una instancia de objetos diferentes que se deben enlazar en JNDI. La

interfaz javax.naming.spi.ObjectFactory es muy simple y sólo contiene un método

getObjectInstance().

El método lookup() de la implementación de proveedor JNDI llama a getObjectInstance(), si dicho

método no puede localizar el objeto solicitado en el registro actual de objetos JNDI. El proveedor JNDI

leerá primero la lista de fábricas de objetos de un punto de extensión de Eclipse. A continuación, leerá la

lista de descripciones de objetos que se deben enlazar en JNDI. Con esta información, el proveedor JNDI

determinará si el nombre que se está intentando localizar está en la lista de nombres que se deben


enlazar de forma diferida y, si está, creará instancias de ObjectFactory basándose en el id proporcionado

en el registro de punto de extensión para ese nombre y llamará a getObjectInstance() con un objeto

nulo, el nombre y el contexto actuales. El objeto devuelto de esta invocación de método se enlazará en el

registro de objeto JNDI y se devolverá del método de búsqueda del proveedor JNDI.

En el entorno de ejecución de Lotus Expeditor Client, las fábricas de objetos se registran a través del

registro de punto de extensión de Eclipse lo que permite que cualquier número de implementaciones de

ObjectFactory se registren y estén disponibles en el proveedor JNDI.

Este punto de extensión es com.ibm.pvc.jndi.provider.java.objectfactory y un ejemplo del uso de este

punto de extensión será similar a lo siguiente:

<extension

point="com.ibm.pvc.jndi.provider.java.objectfactory">

</extension>

Gestión de ciclo de vida del registro JNDI: Es necesario que se notifique a JNDI cuando un objeto

enlazado de forma diferida se elimina del entorno para que pueda estar seguro de desenlazar el objeto

del registro JNDI. Este requisito se cumplirá registrando un escucha con el registro de extensión que

notificará a JNDI cuando se registren objetos nuevos y también cuando se eliminen del registro objetos

registrados actualmente. Cuando se produzca esta notificación, el proveedor JNDI añadirá el nuevo objeto

o eliminará el objeto existente del registro.

La gestión del ciclo de vida del enlace es responsabilidad del proveedor JNDI, no del objeto del que se ha

creado una instancia. La implementación de ObjectFactory es responsable de gestionar el ciclo de vida

del objeto creado registrando los escuchas apropiados y gestionando la limpieza de los recursos

asociados, si se desactiva el artefacto de paquete de contribución. También puede llevar a cabo esta tarea

registrando su propio escucha de registro de extensión

(org.eclipse.core.runtime.IRegistryChangeListener) para el punto de extensión expuesto.

Definición de orígenes de datos gestionados

Puede declarar, migrar y llenar de datos las bases de datos a las que las aplicaciones de Lotus Expeditor

Client de la organización acceden utilizando el componente de Gestión de ciclo de vida de base de datos.

El componente de Gestión de ciclo de vida de base de datos permite a las aplicaciones de Lotus

Expeditor Client interoperar con una base de datos relacional. Como administrador, puede especificar la

estructura de base de datos necesaria (esquema) y, a continuación, llenar con datos la base de datos antes

del acceso de cliente. También puede migrar la base de datos. La interacción de base de datos se

compone de tres tipos de tareas: creación, migración e inserción de datos. Las tareas de creación se

ejecutan en primer lugar y generalmente contienen instrucciones que son responsables de crear las tablas

de una base de datos. Las tareas de migración se ejecutan después de las de creación y son responsables

de migrar los datos que existen actualmente en la base de datos. Las tareas de inserción de datos se

ejecutan en último lugar y suelen contener instrucciones que son responsables de llenar la base de datos

con datos nuevos. Si falla una de estas tareas, se registra un mensaje de error y el origen de datos no es

accesible.

Una ventaja de utilizar esquemas es que tienen versión. Si en el sistema se despliegan varias versiones de

esquemas, éstos se aplican de forma secuencial, según la versión. Por ejemplo, si despliega la versión 1.0

y la versión 2.0 del esquema, primero se ejecutan las tareas del esquema 1.0, seguidas de las tareas del

esquema 2.0. Puesto que los esquemas se aplican de forma secuencial, las versiones sucesivas de los

esquemas sólo tienen que contener los cambios con respecto a las versiones anteriores. Por ejemplo, si la

versión 1.0 del esquema crea la tabla TABLA1 en la base de datos, no es necesario que la versión 2.0 del

esquema cree la tabla TABLA1 porque ya la ha creado la versión 1.0. Las versiones anteriores del

esquema no deben eliminarse de la plataforma, puesto que es posible que nuevos usuarios de la

plataforma tengan que aplicarlas.


|||||||||||

|||||||||

Tome en consideración el caso de ejemplo siguiente. Se despliega una aplicación de forma inicial y utiliza

la versión 1.0 del esquema. Puesto que es una nueva aplicación y una nueva definición de base de datos,

los usuarios que utilicen esta aplicación aplicarán el esquema 1.0 a la base de datos. Posteriormente, se

requiere una actualización de aplicación y se despliega la versión 2.0 del esquema. Los usuarios existentes

sólo aplicarán la versión 2.0 del esquema a la base de datos, puesto que ya han aplicado la versión 1.0. Ya

que la versión 1.0 ya ha sido desplegada, no es necesario que las instrucciones en la versión 2.0 del

esquema repitan las instrucciones de la versión 1.0. Sin embargo, un nuevo usuario aplicará la versión 1.0

primero (puesto que no se ha creado todavía la base de datos) y luego la versión 2.0.

Con Lotus Expeditor Client, una base de datos puede ser una instancia específica de cualquier tipo de

base de datos de SQL, origen de datos tabular, hoja de cálculo o archivo plano que pueda proporcionar

acceso al contenido utilizando un controlador que cumpla con los requisitos de JDBC.

Los pasos implicados en la definición de orígenes de datos incluye la utilización de Lotus Expeditor

Client Toolkit con esquemas de punto de extensión. Las extensiones son los mecanismos clave que un

plug-in utiliza para añadir características nuevas a la plataforma. Las extensiones no se pueden crear de

forma arbitraria. Se declaran utilizando una especificación clara definida por un punto de extensión. Cada

extensión debe ajustarse a la especificación del punto de extensión que se está extendiendo. Cada punto

de extensión define atributos y valores esperados que una extensión debe declarar. Esta información se

mantiene en el registro de plug-in de plataforma. Dado que los proveedores de punto de extensión

consultan estos valores del registro, es importante asegurarse de que el plug-in ha proporcionado la

información esperada.

Tabla 15. Puntos de extensión de gestión de ciclo de vida de base de datos

Punto de extensión Descripción

com.ibm.rcp.database.core.provider Este punto de extensión permite la definición de nuevos

proveedores de bases de datos. Si desea utilizar otra base de datos

además de la base de datos Derby predeterminada de la

plataforma, debe implementar esta extensión. Una vez que se ha

implementado la extensión, los usuarios de la plataforma pueden

acceder a la base de datos proporcionada mediante el ID de

proveedor de base de datos.

com.ibm.rcp.database.core.schema Este punto de extensión permite la definición de esquemas. Un

esquema es un conjunto de tareas de creación, inserción de datos

y migración asociadas. Las definiciones de esquema no

corresponden necesariamente al esquema de un proveedor de

bases de datos específico, pero forman la unidad lógica de una

base de datos que experimenta sucesos de ciclo de vida. Cada

esquema se versiona de forma independiente y puede contener su

propio conjunto de tareas para mantener el ciclo de vida.

com.ibm.rcp.database.core.datasource Este punto de extensión se utiliza para declarar un origen de

datos gestionado en la infraestructura de bases de datos. Un

origen de datos gestionado permite a las aplicaciones

personalizadas de la empresa conectarse a un proveedor de bases

de datos con esquemas asociados para gestionar el ciclo de vida

del origen de datos. Si se declara, el origen de datos se creará y

asociará con una fábrica de objetos de origen de datos gestionado.

Desde éste, se puede recuperar una versión instanciada del objeto

de origen de datos de JNDI, a través de context.lookup().

com.ibm.rcp.database.core.listener Este punto de extensión permite a las aplicaciones personalizadas

definir escuchas para conectarse a orígenes de datos. Los escuchas

son útiles cuando se desea conocer el estado de operaciones que

se aplican al origen de datos. Por ejemplo, es posible que desee

informar al usuario del progreso si está a punto de producirse un

extenso proceso de esquema en un origen de datos.


||||||||

Para obtener información sobre cómo declarar los puntos de extensión, consulte la publicación Platform

Plug-in Developer Guide y Eclipse (http://help.eclipse.org/help32/index.jsp).

Elección entre tipos de orígenes de datos

El componente de Origen de datos gestionado proporciona una definición de origen de datos gestionado

predeterminada (nombre JNDI jdbc/DerbyDS) que pueden utilizar todas las aplicaciones. Si desea utilizar

las extensiones de esquema de Origen de datos gestionado con el origen de datos predeterminado, tendrá

que definir un origen de datos virtual cuyo origen de datos padre (parentDatasource) sea el origen de

datos predeterminado.

Aunque decida no utilizar esquemas con el origen de datos predeterminado, quizá desee definir

igualmente un origen de datos virtual para que su aplicación tenga un nombre exclusivo y coherente

para utilizar al acceder al origen de datos gestionado. Si más adelante decide utilizar una base de datos

distinta de la predeterminada, puede seguir utilizando el mismo nombre de origen de datos para acceder

a la base de datos, pero hacer que el origen de datos virtual haga referencia a un origen de datos padre

distinto.

El origen de datos gestionado predeterminado proporciona una base de datos cifrada almacenada en el

directorio del espacio de trabajo. Varias aplicaciones pueden compartir la instancia individual de la base

de datos, definiendo esquemas dentro de la base de datos para proporcionar un único acceso a las

referencias de tabla. Si la configuración del origen de datos predeterminado no es adecuada, tendrá que

definir un nuevo origen de datos utilizando la extensión. Los orígenes de datos virtuales no permiten

cambiar la configuración de la base de datos, como el cifrado o la ubicación.

Una de las principales ventajas de utilizar el Origen de datos gestionado es el uso de definiciones de

esquemas que pueden asociarse a las definiciones de orígenes de datos virtuales o reales. Si decide no

utilizar la posibilidad de esquemas, puede utilizar igualmente el Origen de datos gestionado y crear su

propio código para realizar tareas de definición, migración e inserción de datos.

Desarrollo iterativo

Si está utilizando orígenes de datos gestionados con esquemas, para actualizar de forma iterativa la base

de datos, se recomienda proporcionar actualizaciones en forma de versiones de esquema incrementadas.

La infraestructura de ciclo de vida de gestión de base de datos actualizará y migrará correctamente el

esquema una vez que se acceda al origen de datos gestionado. Como administrador, se espera que trabaje

con el desarrollador que está utilizando el origen de datos gestionado para asegurarse de que todos los

datos necesarios para el desarrollador están en el origen de datos gestionado. Por ejemplo, un flujo de

trabajo será lo siguiente:

1. El administrador despliega un origen de datos gestionado jdbc/MyDataSource con el esquema

versión 1.0.

2. El desarrollador utiliza jdbc/MyDataSource pero descubre más tarde que el origen de datos

gestionado necesita otra tabla y se pone en contacto con el administrador.

3. El administrador actualiza el esquema a la versión 2.0 y añade una tarea para crear una nueva tabla

como ha solicitado el desarrollador.

4. El desarrollador utiliza jdbc/MyDataSource otra vez y encuentra que el origen de datos gestionado

contiene la tabla.

Las interacciones correctas entre un administrador y un desarrollador aseguran que los orígenes de datos

gestionados estén en un estado en el que los desarrolladores desean que estén.

En términos de pruebas, se recomienda que los administradores desplieguen las actualizaciones en un

nuevo origen de datos gestionado para pruebas antes de desplegarlas en el origen de datos original. Esto

asegurará que cuando se actualice el origen de datos gestionado antiguo, los desarrolladores no verán

ningún problema. Es importante interactuar con un desarrollador durante este periodo de prueba para



asegurarse de que el desarrollador sabe qué orígenes de datos gestionados se deben utilizar en las

pruebas y en producción.

Consideraciones sobre seguridad para orígenes de datos gestionados

En función de la definición del origen de datos gestionado, es posible que el origen de datos utilice el

almacén de claves de la plataforma para almacenar la contraseña o la información de la clave de cifrado.

Al asociar un alias de almacén de claves de plataforma específico a un atributo de conexión de origen de

datos como, por ejemplo, bootPassword para el proveedor de origen de datos gestionado de Derby, la

información puede almacenarse de forma segura dentro de un almacén de claves. Sólo después de que se

utilice la contraseña apropiada para desbloquear el almacén de claves de la plataforma, se podrá obtener

la contraseña o la información de clave de cifrado de la base de datos.

Si se permite que el alias de almacén de claves se cree en el primer acceso con un valor aleatorio, es

importante conservar el almacén de claves y la contraseña del almacén de claves para seguir teniendo

acceso a la base de datos. Si el almacén de claves deja de ser accesible, es posible que la base de datos sea

totalmente inaccesible, puesto que las claves necesarias sólo están disponibles en el almacén de claves.

El valor asociado al alias debe permanecer constante desde la creación inicial, ya que el componente de

origen de datos gestionado actualmente no proporciona un mecanismo para cambiar la contraseña o la

clave de cifrado asociada a una base de datos.

Si se tiene que acceder a la base de datos de forma externa con respecto al componente de origen de

datos gestionado, o fuera del entorno de ejecución de Lotus Expeditor, y se utilizan alias para que el

almacén de claves de la plataforma contenga la contraseña, en ese caso las aplicaciones deben acceder

primero al almacén de claves para obtener los valores adecuados que se necesitarán cuando se acceda a

la base de datos.

Consulte “Gestión de almacén de claves seguro” en la página 110 para obtener información sobre el

acceso al almacén de claves seguro.

Notas de pruebas

Cuando se prueban orígenes de datos gestionados y se trabaja con orígenes de datos gestionados nuevos,

es posible que se encuentre en situaciones donde había errores debido a un script o una tarea de base de

datos incorrectos. A veces, es necesario borrar orígenes de datos gestionados con los que se ha estado

trabajando y empezar desde un lugar limpio. IBM Lotus Expeditor almacena todas las bases de datos en

el directorio de espacio de trabajo (en general bajo el directorio de base de datos a menos que se

especifique lo contrario). Para empezar de nuevo, es necesario suprimir el directorio en el que residen las

bases de datos en las que está interesado. Esto borrará de forma efectiva la memoria caché que el origen

de datos gestionado utiliza para las bases de datos y los esquemas. Una vez realizado esto, empezará de

forma efectiva con un sistema limpio que actuará como si aún no se hubiera accedido a ningún origen de

datos gestionado. Esta serie de pasos puede ser muy útil al probar orígenes de datos gestionados nuevos

antes de desplegarlos. Si surgen problemas al probar el origen de datos gestionado, se recomienda

examinar la información de error importante en los registros.


“Definición de un origen de datos gestionado” en la página 145Puede definir un origen de datos gestionado, utilizando los puntos de extensión de Eclipse y IBM

Lotus Expeditor Toolkit.

“Definición de un origen de datos gestionado cifrado” en la página 145Puede definir un origen de datos gestionado cifrado, utilizando los puntos de extensión de Eclipse y

IBM Lotus Expeditor Toolkit.

“Definición de un origen de datos gestionado cifrado con autenticación” en la página 146Puede definir un origen de datos gestionado cifrado que utilice el almacén de credenciales de

plataforma para la autenticación.


|

|||||||

||||

|||

|||||

||

“Definición de una base de datos” en la página 146La ventaja de utilizar la posibilidad de Origen de datos gestionado es que los scripts y las tareas

definidos se ejecutan automáticamente durante el acceso inicial al origen de datos. Esto elimina la

necesidad de que el código de la aplicación maneje tareas tales como la definición, la inserción de

datos y la migración de bases de datos.

“Definición de un esquema de base de datos para el llenado inicial utilizando una tarea de base de

datos” en la página 147Puede definir un esquema para el llenado de datos utilizando un script.

“Definición de un proveedor de bases de datos” en la página 147Puede definir un proveedor de bases de datos.

“Migración de un origen de datos gestionado a un esquema nuevo” en la página 147Puede migrar un origen de datos gestionado a un esquema nuevo.


Puede definir un origen de datos gestionado, utilizando los puntos de extensión de Eclipse y IBM Lotus

Expeditor Toolkit.

Siga estos pasos para definir un origen de datos gestionado:

1. Utilizando IBM Lotus Expeditor Toolkit, defina un origen de datos gestionado especificando el punto

de extensión com.ibm.rcp.database.core.datasource.

v Para definir un origen de datos gestionado normal, utilice el elemento datasource.

v Para definir un origen de datos gestionado virtual, utilice el elemento virtualDatasource. Los

orígenes de datos virtuales son potentes porque le permiten volver a utilizar otros orígenes de

datos (similar al origen de datos predeterminado) pero le ofrecen la posibilidad de proporcionar sus

propios esquemas y tareas.2. Defina un enlace JNDI válido para que coincida con el nombre JNDI del origen de datos utilizando el

punto de extensión com.ibm.pvc.jndi.provider.java.binding.

Después de realizar estos pasos, se define el origen de datos gestionado.

Definición de un origen de datos gestionado cifrado

Puede definir un origen de datos gestionado cifrado, utilizando los puntos de extensión de Eclipse y IBM

Lotus Expeditor Toolkit.




2. Utilice el proveedor de bases de datos Derby de Apache existente y especifique los siguientes

atributos de cifrado de conexión:

Tabla 16. Atributos de cifrado Derby de Apache

Atributo de cifrado Descripción

encryptionProvider Especifica el proveedor para el cifrado de datos. Si no se especifica ninguno, se

utilizará el proveedor del JRE.

encryptionAlgorithm Se especifica el algoritmo para el cifrado de datos. Si no se especifica ninguno,

el valor predeterminado es DES/CBC/NoPadding.

dataEncryption Especifica el cifrado de datos en disco para una nueva base de datos.

Consulte la documentación de Derby de Apache para obtener más información sobre cómo especificar

atributos de cifrado.

3. Defina un enlace JNDI válido para que coincida con el nombre JNDI del origen de datos utilizando el


El origen de datos gestionado cifrado se ha definido.


Definición de un origen de datos gestionado cifrado con autenticación

Puede definir un origen de datos gestionado cifrado que utilice el almacén de credenciales de plataforma

para la autenticación.




2. Utilice el proveedor de bases de datos Derby de Apache existente y proporcione los siguientes

atributos de cifrado de conexión y de alias de credenciales:

Tabla 17.

Atributo de cifrado Descripción

encryptionProvider Especifica el proveedor para el cifrado de datos. Si no se especifica ninguno, se

utilizará el proveedor del JRE.

encryptionAlgorithm Se especifica el algoritmo para el cifrado de datos. Si no se especifica ninguno,

el valor predeterminado es DES/CBC/NoPadding.

dataEncryption Especifica el cifrado de datos en disco para una nueva base de datos.

credential Especifica el alias de credenciales utilizado por el origen de datos gestionado

para arrancar la base de datos.

Consulte la documentación de Derby de Apache para obtener más información sobre cómo especificar

atributos de cifrado.

3. Defina un enlace JNDI válido para que coincida con el nombre JNDI del origen de datos utilizando el


El origen de datos gestionado cifrado se ha definido.

Definición de una base de datos

La ventaja de utilizar la posibilidad de Origen de datos gestionado es que los scripts y las tareas

definidos se ejecutan automáticamente durante el acceso inicial al origen de datos. Esto elimina la

necesidad de que el código de la aplicación maneje tareas tales como la definición, la inserción de datos y

la migración de bases de datos.

Para utilizar esta posibilidad del Origen de datos gestionado, debe definir un esquema y asociarlo a un

origen de datos gestionado.

1. Cree los archivos de script SQL, o cree las clases (que implementan

com.ibm.rcp.database.core.DatabaseTask) que actuarán en la base de datos.

2. Defina la extensión com.ibm.rcp.database.core.schema con un nombre de esquema y versión válidos.

3. Añada definiciones de tareas de creación, migración e inserción de datos a la extensión, que hagan

referencia a los scripts o las clases que se han creado en el paso 1).

4. Incluya una referencia de esquema (schemaReference) en la extensión de origen de datos gestionado

de destino (com.ibm.rcp.database.core.datasource). Si va a definir un nuevo origen de datos

gestionado, puede incluir directamente la referencia de esquema. Si va a utilizar el origen de datos

gestionado predeterminado, tendrá que definir primero un origen de datos virtual en el origen de

datos predeterminado y luego incluir la referencia de esquema en la definición de origen de datos

virtual.

Cuando el código de la aplicación utilice JNDI para buscar el origen de datos gestionado, los pasos

relacionados con el esquema se realizarán antes de que el origen de datos se devuelva al código que

efectuó la llamada.


Definición de un esquema de base de datos para el llenado inicial utilizando una

tarea de base de datos

Puede definir un esquema para el llenado de datos utilizando un script.

Para definir un esquema para el llenado de datos utilizando una tarea de base de datos:

1. Implemente el punto de extensión com.ibm.rcp.database.core.schema utilizando IBM Lotus Expeditor

Toolkit con una versión de esquema válida y una tarea de base de datos que utilice la acción de

llenado.

2. Localice el origen de datos que desee llenar y añada las referencias de esquema adecuadas.

Entonces se llena el origen de datos gestionado.

Definición de un proveedor de bases de datos

Puede definir un proveedor de bases de datos.

Para definir un proveedor de bases de datos, implemente el punto de extensión

com.ibm.rcp.database.core.provider con un ID de proveedor de base de datos válido y una clase que

implemente la interfaz DatabaseProvider.

Migración de un origen de datos gestionado a un esquema nuevo

Puede migrar un origen de datos gestionado a un esquema nuevo.

Para migrar un origen de datos gestionado a un esquema nuevo:

1. Implemente el punto de extensión com.ibm.rcp.database.core.schema con el mismo nombre de

esquema que el esquema instalado anteriormente. La única diferencia es que el número de versión

debe ser mayor que el esquema instalado anteriormente. Esto permite que el catálogo de base de

datos reconozca que existe un esquema actualizado y que éste se puede aplicar al origen de datos.

2. Implemente la interfaz DatabaseTask para proporcionar código que migre la base de datos.

Utilización de la capa de red

La capa de red es una capa de gestión de red base en Lotus Expeditor Client que proporciona una

infraestructura a las aplicaciones y los componentes de plataforma para las invocaciones de red y el

manejo de errores de red.

Proporciona a los usuarios la posibilidad de determinar el estado actual de la plataforma de cliente así

como la conectividad a servidores remotos y recursos HTTP incluidos los servicios Web. La aplicación

puede elegir que se le notifique de los cambios de estado de cliente o comprobar el estado de plataforma

de cliente utilizando las API públicas para el gestor fuera de línea. La aplicación puede manejar el error

de red utilizando las API públicas para errores de red. La aplicación también puede comprobar el estado

de red real utilizando las API públicas para el estado de red. Esta capa también incluye la versión de

Rich Client Platform (RCP) del manejador de URL HTTP que se integra con la API de cuenta y el gestor

en línea.

Adición y configuración de manejadores personalizados

Como administrador, puede añadir manejadores y configurar la plataforma para utilizar los manejadores

personalizados.

Debe crear el manejador y añadirlo a la plataforma. Consulte ″Adición y configuración de manejadores

personalizados″ en Desarrollo de aplicaciones para Lotus Expeditor para obtener más información sobre cómo

crear un manejador y añadir la extensión a un plugin.xml.


Ampliación de la plataforma para la gestión de propiedades de Device

Manager

El servidor Device Manager que trabaja con el Agente de gestión de empresa en el cliente puede

actualizar propiedades individuales presentes en los archivos de estilo de propiedades de Java.

Esto permite distribuir actualizaciones de propiedades individuales a varios clientes, sin tener que

realizar una sustitución de archivos en masa, lo que puede hacer que se propaguen valores incorrectos a

los clientes.

Los archivos que se deben gestionar se deben poder procesar como si fueran archivos de propiedades

normales de Java y la clase de Java java.util.Properties los debe poder leer y manejar. Las claves que

contienen caracteres que normalmente no se sustituyen en el manejo de URI HTTP, por ejemplo la barra

inclinada invertida (\) o el signo más (+), se sustituirán por la anotación de escape típica utilizando %xx,

donde xx es el valor hexadecimal del carácter. Cuando se visualizan en el servidor Device Manager, se

muestran los caracteres de formato de escape.

La plataforma permite cuatro archivos para la gestión de forma predeterminada. Estos archivos son

rcpinstall.properties y config.ini en el directorio de configuración y rcplauncher.properties y

plugin_customization.ini en el directorio <dir_instalación>/rcp.

Para permitir que se actualicen archivos de propiedades adicionales, primero debe registrarlos en la

plataforma. Para registrar un nuevo archivo de propiedades, añada una nueva extensión al punto de

extensión com.ibm.rcp.props.dm.managedFile. Para ello, siga estos pasos:

1. Si tiene un proyecto existente al que desea añadir este punto de extensión, vaya al paso 3.

2. Cree un nuevo proyecto para que contenga la extensión:

a. Cree un nuevo proyecto de servicios (o plug-in) de cliente.

b. Si piensa añadir código a este proyecto, deje los valores predeterminados. Si no piensa añadir

código a este proyecto, desmarque la opción Crear proyecto Java en la página de diálogo. 3. Vaya a la página Extensiones del Editor de manifiesto de plug-in para este proyecto.

4. Pulse Añadir.

5. Deseleccione la opción Mostrar sólo puntos de extensión de los plug-ins necesarios.

6. Entre com.ibm.rcp.props.dm.managedFile como el filtro de Punto de extensión. Seleccione este

punto de extensión y pulse Finalizar.

7. Opcionalmente, añada com.ibm.rcp.props.dm como paquete necesario para el proyecto.

8. Opcionalmente, rellene los campos ID y Nombre en los detalles de punto de extensión.

9. Seleccione la extensión que acaba de añadir, pulse el botón derecho del ratón y seleccione Nuevo →

archivo gestionado.

10. En los detalles de extensión, complete los detalles siguientes:

a. En el campo Archivo, entre la ubicación del archivo. En la ubicación, puede utilizar variables que

se sustituirán durante la ejecución del entorno de ejecución. Consulte la documentación de punto

de extensión para obtener más información. En el punto de extensión, puede pulsar el botón

derecho del ratón y, a continuación, seleccionar Mostrar descripción para visualizar la

descripción.

b. En el campo nombre, entre un nombre para identificar este archivo. Este nombre puede ser el

mismo que el nombre de archivo o puede utilizar un alias para representar el archivo. Este

nombre se utiliza durante las operaciones realizadas en el servidor Device Manager.11. Guarde el contenido de archivo.

Puede continuar añadiendo código a este plug-in del mismo modo que con cualquier otro plug-in. El

despliegue de este plug-in sigue los patrones estándar. Consulte el apartado “Empaquetado de

aplicaciones para el despliegue” en la página 158 para obtener más información.


Una vez que se ha desplegado en el cliente la característica que contiene este plug-in, puede iniciar

solicitudes de trabajo desde el servidor Device Manager. Consulte el apartado “Gestión de archivos de

propiedades” en la página 220 para obtener más información.

Adición de un proveedor de valores gestionados

Un proveedor de valores gestionados es un plug-in de Eclipse que sabe cómo extraer valores de un

sistema de gestión de fondo asociado y pasarlos a la infraestructura de valores gestionados en el formato

apropiado.

IBM Lotus Expeditor proporciona proveedores para los valores especificados por el gestor de políticas de

portal, para los valores que se especifican en archivos XML y para las políticas especificadas en Domino

(enviado con Notes 8.0). Si desea controlar los valores de preferencia o política desde un sistema de

fondo diferente, puede solicitar a un desarrollador que cree un proveedor personalizado.

Los proveedores personalizados deben realizar lo siguiente:

1. Ampliar el punto de extensión ManagedSettingsProvider proporcionado por el plug-in

com.ibm.rcp.managedsettings. Se proporciona información adicional en el esquema del plug-in

com.ibm.rcp.managedsettings.

Por ejemplo:

<extension point="com.ibm.rcp.managedsettings.ManagedSettingsProvider">

<provider

class="com.isv.Provider"

weight="10"/>

<extension>

El atributo class apunta a una clase que implementa la interfaz

com.ibm.rcp.managedsettings.Provider, definida en el plug-in com.ibm.rcp.managedsettings.

El atributo weight está destinado a resolver conflictos entre varios proveedores que proporcionan los

mismos datos. El administrador puede alterar temporalmente este valor. Los valores proporcionados

por el proveedor con el peso más bajo tienen prioridad. Dos proveedores pueden estar gestionando de

forma involuntaria el mismo grupo de valores si, por ejemplo, configura inicialmente políticas de

correo en un archivo XML pero ha decidido moverlas al Portal y ha olvidado suprimirlas del archivo

XML. Los pesos para los proveedores conocidos tienen los siguientes valores predeterminados, que el

administrador puede cambiar:

com.ibm.rcp.managedsettings.provider.file = 300

com.ibm.rcp.managedsettings.provider.portal = 200

com.ibm.notes.managedsettings.provider = 100

2. Implemente la interfaz com.ibm.rcp.managedsettings.provider.Provider. Puede encontrar Javadoc en

Desarrollo de aplicaciones para Lotus Expeditor → Referencia → Javadoc → Valores gestionados.

Al principio de una actualización de valores gestionados, la infraestructura llama a

getProvidedSettingGroups() para determinar para qué grupos de valores proporcionan actualmente

datos los proveedores. Se utiliza para identificar qué grupos de valores se han suprimido desde la última

actualización.

Para implementar este método, necesitará determinar cómo se relaciona el concepto de un grupo de

valores con el sistema de fondo para el que está escribiendo el proveedor. Un grupo de valores es un

grupo de valores relacionados. Suele ser el nivel de granularidad en el que se realiza el seguimiento de

las modificaciones de valores, en el caso de que no se realice el seguimiento de las modificaciones en el

nivel de valor individual. Si el sistema de fondo no tiene el concepto de grupo de valores, puede

simplemente blindar la codificación de un solo valor y poner todos los valores en este grupo de valores.

Por ejemplo: Recupera los nombres de los grupos de valores que este proveedor conoce.


Devuelve:

Colección de series que contienen los nombres de los grupos de valores que este proveedor

puede proporcionar.

Genera:

ProviderException si la llamada ha fallado por cualquier razón.public Collection getProvidedSettingGroups() throws ProviderException {

ArrayList settingGroups = new ArrayList();

String[]providedSettingGroups = BackEndSystem.getPolicyNames();

ArrayList ret = new ArrayList();

for (int i = 0; i < providedSettingGroups.length; i++){

ret.add(providedSettingGroups[i]);

}

return settingGroups;

}

Los grupos de valores se representan mediante la clase SettingGroup, que es una estructura de datos que

permite a las aplicaciones pasar fácilmente datos de valores a la infraestructura de valores gestionados.

La clase SettingGroup se utiliza para asociar un conjunto de parejas de nombre y valor, indicar el estado

bloqueado o desbloqueado y anotar la hora a la que el administrador ha cambiado cualquiera de los

valores por última vez. Después de llamar a getProvidedSettingGroups(), la infraestructura llama a

getUpdates() y le pasa una Correlación que especifica los grupos de valores y las últimas fechas

conocidas modificadas de esos grupos de valores. El método debe devolver una lista de objetos

SettingGroup para cualquiera de los grupos de valores que han cambiado desde la última fecha de

modificación. Entonces la infraestructura de valores gestionados almacena los objetos SettingGroup

devueltos en el almacenamiento local del cliente. Por ejemplo, si una de las entradas de la correlación es

el grupo de valores A, con una fecha de última modificación de 1 de enero de 2006, el proveedor debe

devolver un objeto SettingGroup en la lista si cualquiera de los valores del grupo de valores A ha

cambiado desde el 1 de enero de 2006.

Para que se guarden en el lugar correcto del almacén de preferencias de Eclipse, los valores y los grupos

de valores deben utilizar los convenios de denominación descritos en “Especificación de valores” en la

página 77. Si no puede especificar los valores de ese modo debido a las limitaciones del sistema de fondo,

se deberá codificar en el proveedor.

Si en cualquier grupo de valores actualizado faltan valores que se han proporcionado en la actualización

anterior, tales valores se tratarán como no gestionados recientemente y se desbloquearán.

Ejemplo:

public List getUpdates(Map updateMap) throws ProviderException {

ArrayList ret = new ArrayList();

Iterator groups = updateMap.keySet().iterator();

while (groups.hasNext()){

String policySet = (String)groups.next();

Date requestChangesSince = updateMap.get(policySet);

Map settingsChanges = BackEndSystem.getPolicyChanges (policySet, requestChangesSince);

SettingGroup settingGroup =

new SettingGroup(policySet, BackEndSystem.getLastChangeDate(policySet);

Iterator settingsList = settingsChanges.entrySet().iterator();

while (settingsList.hasNext()){

Map.Entry setting = (Map.Entry) settingsList.next();

settingGroup.add(setting.getKey(), setting.getValue(), true);

}

ret.add(settingGroup);


}

return ret;

}

Es posible que desee combinar las implementaciones de getProvidedSettingGroups() y getUpdates()

para requerir sólo una llamada al servidor captando la información necesaria para ambas en la llamada

getProvidedSettingGroups() y, a continuación, almacenando en la memoria caché la información de

actualización para que posteriormente la pueda devolver el método getUpdates(). El único problema con

esta acción es que en el momento en que se llama a getProvidedSettingGroups(), no tiene acceso a las

últimas fechas de modificación proporcionadas como argumento en el método getUpdates(). Puede

obtener acceso a las últimas fechas de modificación en el momento que desee llamando a

ProviderHelper.getSettingGroupLastModDates(String providerId).

Puede utilizar la API de Cuentas para reducir la lista de valores y grupos de valores a los que se aplican

al usuario conectado.

Opcional: Si el proveedor sabe cuándo tiene actualizaciones, puede solicitar que la infraestructura de

valores gestionados ejecute una actualización inmediatamente en lugar de esperar a que caduque el

intervalo de actualización. La infraestructura de valores gestionados llama a

Provider.addProviderUpdateListener en el proveedor para registrar estas notificaciones. Implemente este

método a fin de realizar el seguimiento de los escuchas. Cuando el proveedor sepa que tiene

actualizaciones, deberá llamar al método onRequestUpdate() en los escuchas registrados y se ejecutará

una actualización inmediatamente.

Definición de cuentas para clientes de servicios Web de Apache Axis

Mediante la utilización de un programa puede crear cuentas para los clientes de servicios Web de Apache

Axis.

Consulte ″Creación de cuentas mediante programa para clientes de servicios Web de Apache Axis″ en


Definición de ubicaciones

Puede definir ubicaciones nuevas, utilizando los puntos de extensión de Eclipse y IBM Lotus Expeditor

Toolkit. Si no hay contribuciones de ubicación, IBM Lotus Expeditor proporcionará dos ubicaciones

predeterminadas denominadas Online (En línea) y Offline (Fuera de línea).

Para definir una ubicación nueva, implemente la extensión

com.ibm.rcp.locationmanager.locationActionSets. Asegúrese de proporcionar el estado en línea o fuera de

línea asociado con la nueva ubicación especificando el atributo offline. El usuario podrá conmutar entre

ubicaciones a través de controles de UI. Además, puede utilizar la API pública

com.ibm.rcp.locationmanager.LocationManager para conmutar entre ubicaciones mediante el programa.

A continuación, se muestra un ejemplo de un conjunto de acciones de ubicación. En este ejemplo, una

ubicación denominada Office contribuye a la plataforma. El estado de plataforma preferido para esta

ubicación es en línea (observe los subelementos y el modo en que se utilizan los atributos):

<extension

point="com.ibm.rcp.locationmanager.locationActionSets">

<actionSet

automaticStartup="false"

id="com.ibm.rcp.locationmanager.test.locations"

label="com.ibm.rcp.locationmanager.test.locations"

<action

class="com.ibm.rcp.locationmanager.test.actions.TestAction"

id="com.ibm.rcp.locationmanager.test.office"

label="Office"


offline="false"

tooltip="Switch location"/>

</actionSet>

</extension>

Definición de conexión de componentes

Consulte el centro de información de Portal para obtener información sobre la conexión de componentes.

El centro de información de Portal está ubicado en http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp.

Ampliación del analizador de textos

Puede ampliar la infraestructura del Analizador de textos con el corrector ortográfico, que se utiliza para

corregir las palabras escritas incorrectamente en un documento.

El corrector ortográfico soporta 26 idiomas y lo pueden utilizar muchos editores, implementando las

interfaces de documento. Puede contribuir con motores nuevos y diccionarios en la infraestructura del

analizador de textos para que las aplicaciones puedan utilizar motores personalizados y diccionarios

mediante la infraestructura.

Tabla 18. Diccionarios soportados

Idiomas Diccionarios soportados

Inglés Inglés (Australia)

Inglés (Gran Bretaña)

Inglés (EE.UU.)

Chino (simplificado) Chino (simplificado)

Chino (tradicional) Chino (tradicional)

Francés Francés (Francia)

Francés (Canadá)

Alemán Alemán (Suiza)

Alemán (Alemania)

Italiano Italiano

Español España

Portugués (Brasil) Portugués (Brasil)

Árabe Árabe (Arabia)

Checo Checo (República Checa)

Danés Danés (Dinamarca)

Neerlandés Holandés (Holanda)

Finlandés Finlandés (Finlandia)

Griego Griego (Grecia)

Hebreo Hebreo (Israel)

Húngaro Húngaro

Noruego Noruego (Bokmal)

Noruego (Nynorsk)

Polaco Polaco

Portugués Portugués (Portugal)


http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp

Tabla 18. Diccionarios soportados (continuación)

Idiomas Diccionarios soportados

Ruso Ruso (Rusia)

Sueco Sueco (Suecia)

Turco Turco (Turquía)

Catalán Catalán (Cataluña)

Contribución con un diccionario personalizado

Utilice el punto de extensión com.ibm.rcp.textanalyzer.Dictionaries para aplicaciones a fin de contribuir

con diccionarios nuevos.

Un plug-in que necesita contribuir con un diccionario en la infraestructura puede definir la extensión,

similar a lo siguiente:

<plugin>

<extension

point="com.ibm.rcp.textanalyzer.Dictionaries">

<dictionary

description="English medical dictionary"

dict_name="en_US_medical.dic"

engine="jFrost"

filePath="./dictionaries/en_US_medical.dic"

language="en-US"

locale="en-US"

provider="IBM"

version_info="1.0.0"

type="spell"/>

</extension>

</plugin>

En este ejemplo, el plug-in contribuye con un diccionario médico en inglés en el motor jFrost de IBM

existente y la posición del archivo de diccionario está en la carpeta de diccionarios de dicho plug-in. Para

obtener más información, consulte ″Aportar diccionarios personalizados″ en Desarrollo de aplicaciones para

Lotus Expeditor.

Contribución con un motor nuevo

Utilice el punto de extensión com.ibm.rcp.textanalyzer.Engines para aplicaciones a fin de contribuir con

motores nuevos.

Un plug-in que necesita contribuir con un motor de comprobación ortográfica en la infraestructura puede

definir la extensión e implementar la interfaz com.ibm.rcp.textanalyzer.spellchecker.SpellCheckerEngine.

Para obtener más información, consulte ″Gestor de diccionarios de usuario″ en Desarrollo de aplicaciones

para Lotus Expeditor.

Despliegue de IBM Lotus Expeditor Micro Broker

Existe sólo una única instancia de Micro Broker por plataforma. La instancia de Micro Broker se crear

mediante el programa utilizando las API de administración.

Una vez que la instancia de Micro Broker se ha creado, el paquete com.ibm.micro la iniciará

automáticamente. Dado que el paquete com.ibm.micro se iniciará de forma lenta como resultado de la

llamada a las API administrativas en Micro Broker, el único paquete que es necesario añadir al ciclo de

vida de aplicación o plataforma es el paquete de aplicación que crea una instancia de Micro Broker o

comprueba la existencia de dicha instancia. Consulte el apartado “Gestión del ciclo de vida” en la página

118 para obtener más información.


Para empezar el prototipo inicial utilizando Micro Broker, se proporciona una característica de iniciación

de IBM Lotus Expeditor Micro Broker en el sitio de actualización updates\platform. Esta característica no

se instala de forma predeterminada y se debe instalar utilizando uno de los mecanismos de suministro.

Para utilizar esta característica, añada el plug-in com.ibm.micro.gettingstarted al ciclo de vida de

plataforma para realizar la configuración inicial de la instancia de Micro Broker o utilice la consola de

plataforma para iniciar manualmente este plug-in. La instancia de Micro Broker se denomina

FirstBroker. Este plug-in es para evaluación y uso de prototipo inicial y proporciona una configuración

muy básica. Es posible que necesite crear su propia instancia de intermediario específica de los requisitos

de aplicación, configurando posibilidades tales como conexiones y tipos de conexión, persistencia,

fábricas de conexiones y más.

Para obtener más información, consulte ″Configuración y administración de componentes de Micro

Broker″ en la documentación de Micro Broker para más detalles.

Creación de imágenes de entorno de ejecución de cliente

Este apartado describe cómo utilizar la herramienta de creación de plataformas para crear imágenes de

entorno de ejecución personalizadas de la plataforma de Lotus Expeditor Client.

Cómo empezar a crear plataformas

Utilice la herramienta Desarrollador de plataformas para crear una imagen de entorno de ejecución

personalizada de la plataforma de Lotus Expeditor Client.

Para empezar, utilice el asistente de configuración de producto (Archivo > Nuevo > Otros > Desarrollo

de plug-ins > Configuración de producto) para guiarle durante el proceso de creación de una imagen de

entorno de ejecución inicial. Elija qué plug-ins, paquetes, características y componentes de aplicación

desea para poder crear el espacio necesario de entorno de ejecución más pequeño. Si desea refinar la

imagen de entorno de ejecución en una fecha posterior, puede utilizar el Editor de configuración de

producto para volver a crear la imagen.

Siga estos pasos básicos para crear una imagen de entorno de ejecución:

Paso Consultar:

1 Asegúrese de que el sistema de desarrollo

cumple todos los requisitos de software y

hardware y de estar al corriente de las

limitaciones del Desarrollador de plataformas

en el momento de este release.

Lotus Expeditor Client Notas del release

2 Establezca la ubicación de plataforma de

destino de desarrollo de plug-ins en el

entorno de ejecución de Lotus Expeditor

Client.

“Configuración de la plataforma de destino” en la

página 155

3 Cree/actualice el archivo de configuración, si

es necesario. Cuando se crea la configuración,

se define el nombre de archivo en el asistente

de Configuración de producto con una

extensión .product de forma predeterminada

No aplicable

4 Exporte la imagen de entorno de ejecución de

destino a un directorio local.

“Exportación de una imagen de entorno de ejecución

de destino” en la página 157

5 Ejecute la imagen de entorno de ejecución de

destino.

“Ejecución de una imagen de entorno de ejecución de

destino” en la página 157

Atención: La utilización de plataformas de entorno de ejecución generadas con IBM Lotus Expeditor

Toolkit en un entorno de producción necesita una licencia independiente. Póngase en contacto con el

representante de ventas de IBM para la licencias de despliegue.


Configuración de la plataforma de destino

Para habilitar los plug-ins proporcionados con Lotus Expeditor Client, debe volver a establecer el destino

del espacio de trabajo para que utilice la plataforma de entorno de ejecución de Lotus Expeditor Client.

Debido a este requisito, se recomienda que cree un espacio de trabajo nuevo para utilizarlo al desarrollar

aplicaciones para este producto.

Creación de una configuración del Desarrollador de plataformas

Aunque una configuración de Desarrollador de plataformas puede residir en cualquier proyecto del

espacio de trabajo, se sugiere que un proyecto, por ejemplo un Proyecto general, se cree como la

ubicación donde se guarda la configuración de Desarrollador de plataformas.

Para crear un proyecto general, siga estos pasos:

1. Seleccione Archivo → Nuevo → Proyecto → General → Proyecto y pulse Siguiente.

2. Entre el nombre de proyecto y, a continuación, seleccione Finalizar.

Para crear una configuración de Desarrollador de plataformas, siga estos pasos:

1. Seleccione Archivo → Nuevo → Otros → Desarrollo de plug-ins → Configuración de producto y pulse

Siguiente.

2. Entre o seleccione la carpeta padre.

El nombre de la carpeta padre es el nombre del proyecto donde residirá la configuración del

Desarrollador de plataformas.

3. Entre o seleccione un nombre de archivo para la configuración de Desarrollador de plataformas. La

extensión de nombre de archivo se debe dejar como .product.

4. Seleccione Finalizar.

El contenido del archivo de producto se puede inicializar utilizando uno de los tres métodos

siguientes. La opción Crear un archivo de configuración con valores básicos crea un archivo de

configuración de producto básico con valores mínimos. Toda la información específica de la

configuración de producto se debe añadir con el Editor de configuración de producto. La opción

Utilizar un producto existente crea una configuración de producto utilizando información como por

ejemplo ID de producto y Aplicación de la extensión seleccionada. A continuación se puede añadir

información adicional con el editor de configuración de producto. La opción Utilizar una

configuración de lanzamiento inicializa el contenido del archivo de producto utilizando la

información definida en una configuración de lanzamiento de servicios de cliente existente. Se puede

modificar la información con el editor de configuración de producto.

5. Abra el archivo .product con el Editor de configuración de producto.

Cuando el archivo se cree, se abrirá de forma predeterminada en el editor. Subsiguientemente, el

archivo se puede abrir con las técnicas estándar de Eclipse de doble pulsación en el archivo o de

pulsación con el botón derecho del ratón en el nombre de archivo y de selección de Abrir con >

Editor de configuración de producto en el menú de contexto visualizado.

6. La información contenida en la configuración de Desarrollador de plataformas se visualiza en el

Editor de configuración de producto en cuatro páginas. Las cuatro páginas se etiquetan Visión

general, Configuración, Iniciador y Creación de marca. Para seleccionar una página, pulse en el

nombre de página. La información en las cuatro páginas se debe rellenar antes de intentar lanzar

(probar) o exportar la configuración de Desarrollador de plataformas.

7. En la página Visión general:

a. Entre el nombre de producto.

Este nombre se utilizará para identificar esta configuración de Desarrollador de plataformas. El

nombre también se utiliza como name= parameter en el archivo .eclipseproduct que se exportará

para que lo utilice Lotus Expeditor Client.

b. Seleccione la configuración de destino.


Cada configuración de destino identifica el conjunto inicial de características y plug-ins de Lotus

Expeditor Client que se deben utilizar. Entonces se pueden añadir características y los plug-ins

opcionales, así como características y plug-ins de espacio de trabajo. El Desarrollador de

plataformas soporta el lanzamiento y la exportación de las imágenes de entorno de ejecución

destinadas al escritorio. Por esta razón, no se debe utilizar el destino de dispositivo

predeterminado con el Desarrollador de plataformas.

c. Seleccione el ID de producto y/o la aplicación.

La configuración de destino contiene una recomendación para el ID de producto o la aplicación

que se debe utilizar. Los valores recomendados se pueden modificar si se desea.

d. Seleccione el entorno de destino.

Esto indica si se desea una imagen de entorno de ejecución para utilizarla en un sistema

Windows o Linux.

e. Seleccione la VM (Virtual Machine) que implementa las especificaciones Java.

De nuevo, la configuración de destino contiene una recomendación para la VM que se debe

utilizar con la configuración. Se puede utilizar el valor recomendado, si se desea. Se debe

seleccionar la línea en blanco en la lista si no se ha de incluir una VM en la configuración. Esto

está destinado a utilizarse en casos en que el sistema en el que se instala la imagen de entorno de

ejecución ya tiene una VM instalada.

f. Seleccione el botón de selección apropiado para elegir si la configuración se basa en plug-ins o

características. El valor predeterminado son las características. 8. En la página Configuración:

a. Seleccione Añadir para abrir el diálogo de selección de lista de características y añadir

características adicionales cuando la configuración se basa en características o el diálogo de

selección de lista de plug-ins para plug-ins cuando se basa en plug-ins. Los diálogos de selección

de lista tienen dos páginas en la primera de las cuales se listan los plug-ins (o las características

si se basa en características) que son necesarios u opcionales tal como lo define la configuración

de destino elegida en la página de visión general.

La primera página también proporciona un botón Seleccionar recomendados, que le

permite incluir plug-ins opcionales recomendados (o características si se basa en características)

para el destino actual seleccionado.

La segunda página del diálogo de selección de lista contiene el resto de los plug-ins o las

características que Eclipse ha encontrado pero que no están en la primera página de este diálogo.

Los plug-ins o las características que son necesarios para la configuración de destino seleccionada

aparecen seleccionados y en gris.

Nota: Para un plug-in creado personalizado, debe añadir manualmente los plug-in necesarios

utilizados por los puntos de extensión. Esto asegura que el Desarrollador de plataformas

incluya todos los plug-in necesarios cuando se exporte el producto.

b. Seleccione los idiomas a incluir en la plataforma.

c. De forma predeterminada se crea un archivo config.ini que el entorno de ejecución utiliza al

arrancar. Los usuarios pueden sustituir este archivo por su propio archivo config.ini

personalizado en el espacio de trabajo seleccionando Utilizar un archivo config.ini existente y

seleccionándolo con el botón Examinar. 9. En la página de lanzamiento:

a. Seleccione el nombre de iniciador y el nombre de archivo de configuración de iniciador si no se

está utilizando el iniciador de servicios de cliente estándar.

b. Entre los argumentos de programa, argumentos de VM y entradas de rutina de carga en la

pestaña de plataforma que corresponde al entorno de destino. La selección de la pestaña de

plataforma que corresponde al entorno de destino proporcionará un conjunto de valores

recomendados.10. En la página de creación de marca, seleccione la personalidad apropiada.


|||

11. Guarde la configuración.

Para ejecutar la plataforma de Lotus Expeditor Client en un entorno de prueba, conmute a la pestaña

Visión general y seleccione Lanzar el producto.

Nota: Debe probar la imagen de entorno de ejecución en la plataforma en la que ésta se pretende utilizar.

Por ejemplo, las imágenes de entorno de ejecución con un entorno de destino de Windows, no se

pueden probar en un sistema Linux.

Exportación de una imagen de entorno de ejecución de destino

Siga estos pasos para exportar una imagen de entorno de ejecución de destino.

Para exportar una imagen de entorno ejecución, realice el procedimiento siguiente:

1. Seleccione el enlace de Asistente de exportación de producto de Eclipse, en la página Visión general

del Editor de configuración de producto o seleccione Archivo > Exportar > Desarrollo de plug-ins >

Producto de Eclipse.

2. Entre el nombre de un directorio o un nombre de archivo archivador (sólo se soportan extensiones

.zip).

3. Seleccione Finalizar.

Después de exportar la imagen de entorno de ejecución (a condición de que haya creado un archivo

archivador), ésta se puede desempaquetar ejecutando unzip en un directorio del sistema donde se

ejecutará utilizando herramientas locales tales como pkzip o gzip.

Nota: Si encuentra errores de sincronización que indican que los plug-ins no están en el espacio de

trabajo durante el proceso de exportación, borre el campo sincronizar antes de exportar e intente

la exportación otra vez.

Migración de un proyecto del Desarrollador de plataformas de WebSphere

Everyplace Deployment 6.0 a Lotus Expeditor Client 6.1.x

Conozca cómo se produce automáticamente la migración cuando se migra un proyecto del Desarrollador

de plataformas de WebSphere Everyplace Deployment 6.0 a Lotus Expeditor Client 6.1.1 o 6.1.2.

La migración se producirá automáticamente bajo las siguientes circunstancias:

v Un espacio de trabajo del release 6.0 se abre utilizando las herramientas del release 6.1.1 o 6.1.2

v Un proyecto creado utilizando el release 6.0 se importa (utilizando el asistente de importación estándar

de Eclipse) al espacio de trabajo utilizando las herramientas del release 6.1.1 o 6.1.2.

Ejecución de una imagen de entorno de ejecución de destino

Aprender a ejecutar una imagen de entorno de ejecución de destino.

Para lanzar la imagen de ejecución de destino, realice una de las acciones siguientes:

v En sistemas Windows, ejecute el archivo startup.bat.

v En sistemas Linux, ejecute el archivo startup.sh.

Estos archivos se crean en el directorio raíz de la imagen exportada.

Nota: No instale una imagen de entorno de ejecución en un directorio que contenga un punto y coma en

el nombre de directorio.

El archivo startup.bat que el creador de plataformas exporta contiene dos programas (WCTMELaunchUtil

y rcplauncher.exe) que se ejecutan para iniciar la instancia del cliente de escritorio. WCTMELaunchUtil se

utiliza para inicializar el entorno. Entre otros elementos, este programa crea un archivo necesario para el

segundo programa (rcplauncher.exe). El programa rcplauncher.exe se utiliza para iniciar el cliente. Cada

vez que se ejecuta el primer programa, se crea un nuevo nombre de espacio de trabajo exclusivo. Si no


{

{

{

desea que se cree un nuevo nombre de espacio de trabajo cada vez que se ejecuta startup.bat, edite el

archivo de proceso por lotes para crear dos archivos de proceso por lotes independientes.

v Guarde la primera línea del archivo startup.bat en un archivo de proceso por lotes aparte. Ejecute este

archivo de proceso por lotes sólo una vez para inicializar el espacio de trabajo.

v Guarde la segunda línea del archivo startup.bat en un archivo de proceso por lotes aparte. Ejecute este

archivo de proceso por lotes cada vez que desee iniciar el cliente.

Configuración del diseño de aplicación

En el entorno de trabajo, el diseño de las aplicaciones, por ejemplo las vistas y los editores, se define

mediante dos métodos.

La plataforma de cliente proporciona la tecnología conocida como CAI (Composite Application

Infrastructure - Infraestructura de aplicaciones compuestas). CAI se basa en una definición del diseño de

aplicación contenido en una corriente XML. La corriente XML se puede obtener de una definición estática

desplegada en el sistema de archivos local, de una definición contenida en un plug-in o se puede

recuperar de un servidor de Portal.

Con una extensión de IBM, WebSphere Portal 5.1 soporta portlets cooperativos para los portlets JSR 168,

en los que un portlet JSR 168 se puede comunicar con otro portlet JSR 168. Con el release de WebSphere

Portal V5.1.0.1, puede utilizar conexión de páginas cruzadas entre portlets cooperativos para los portlets

JSR 168 y los portlets de API de IBM.

Consulte ″Descripción de aplicaciones compuestas″ en Desarrollo de aplicaciones para Lotus Expeditor para

obtener información sobre cómo crear una definición XML de CAI. Consulte “Gestión de clientes ricos

utilizando el servidor de Portal” en la página 223 para obtener información sobre cómo diseñar

aplicaciones en el servidor de portal para generar dinámicamente XML que se deberá procesar en el

cliente.

El otro modelo para el diseño de aplicaciones consiste en utilizar una definición basada en punto de

extensión/programa, que forme parte del modelo de programación de Eclipse estándar. Este modelo

necesita la definición de perspectivas para contener vistas y editores y para gestionar el diseño de la

aplicación. Ambos modelos se pueden combinar en el mismo cliente.

Empaquetado de aplicaciones para el despliegue

Este apartado describe cómo desplegar aplicaciones.

El término aplicación se utiliza en este apartado para hacer referencia a un grupo de una o varias

características que se deben desplegar juntos para proporcionar algunas posibilidades útiles.

Los artefactos de despliegue son plug-ins, fragmentos, características y sitios de actualización.

Los plug-ins contienen el código y los recursos que proporcionan funciones específicas. Los fragmentos

pueden contener código para ampliar otros plug-ins, pero se utilizan normalmente para proporcionar

información específica de entorno local o implementaciones específicas de sistema operativo. Los plug-ins

y los fragmentos no se instalan individualmente en el entorno de ejecución de cliente, pero se deben

empaquetar en una característica. Una característica es el artefacto de instalación mínima. Las

características incluyen plug-ins y fragmentos. Las características también pueden incluir otras

características, así como también precisar de la instalación de otros plug-ins y características.

Un sitio de actualización es un repositorio de características. Las características de un sitio de

actualización pueden tener relación entre ellas o no tener ninguna. En función de los métodos utilizados

para el despliegue, los sitios de actualización son opcionales. Para desplegar características sin añadirlas a

un sitio de actualización, puede utilizar las siguientes opciones de despliegue:

v Distribución de características utilizando el servidor Device Manager


v Distribución de características utilizando el cliente gestionado de Portal

Para desplegar características de un sitio de actualización, puede utilizar las siguientes opciones de

despliegue:

v Sitio de actualización local

v Sitio de actualización remoto

v Sitio de actualización archivado local

v Distribución de sitio de actualización utilizando el servidor Device Manager

Para crear características y sitios de actualización, utilice las tareas siguientes:

v Creación de una característica

v Creación de un sitio de actualización

v Exportación de una característica y de los plug-ins

Una vez que se ha creado la característica o el sitio de actualización, consulte “Gestión del entorno de

ejecución de cliente” en la página 197 para obtener información sobre cómo desplegar la característica o

el sitio de actualización.

Descripción del ciclo de vida de las características

Este apartado describe el ciclo de vida de las características para la plataforma IBM Lotus Expeditor. Es

importante comprender el ciclo de vida de las características cuando éstas se distribuyen a los sistemas

cliente.

Igual que los plug-ins que existen en la plataforma, las características que definen los plug-ins tienen un

ciclo de vida similar que afecta a la posibilidad de utilizar lo que proporcionan.

Una característica existe en uno de tres estados:

Desinstalada

Hace referencia a una característica que no está instalada en los sitios de la plataforma. Se trata

de una característica que no se ha instalado nunca, o que se ha instalado anteriormente y que,

posteriormente, ha sido desinstalada. Durante la operación de desinstalación, se invocan los

métodos de desinstalación de InstallHandler.

Instalada

Se entra en el estado de instalada realizando una acción de instalación en una característica

desinstalada o inhabilitando una característica habilitada.

Para una característica desinstalada que se instala, se llama a los métodos relacionados de

instalación de cualquier InstallHandler asociado con la característica.

Para una característica habilitada anteriormente que se está inhabilitando, se llama a los métodos

relacionados de desconfiguración de cualquier InstallHandler. Para que una característica se

instale satisfactoriamente, el descriptor de característica y los plug-ins necesarios deben ser

accesibles y válidos para copiarse en el sitio de plataforma. Además, los requisitos expresados por

la característica también se deben satisfacer para que ésta se pueda instalar. Se produce una fase

de validación antes de intentar una instalación para verificar que los descriptores de despliegue

de características son accesibles y que se satisfacen los requisitos. La existencia y validez de

plug-in (es decir, el certificado firmado válido) se comprueban durante la tarea real de instalación

de la característica.

Una característica que sólo está instalada no proporciona ninguna función en la plataforma y los

plug-ins que contiene no se instalan en el entorno de ejecución.

Configurada (o Habilitada)

El estado de configurada (o habilitada) se produce al realizar una operación de configuración (o

habilitación) en una característica en estado de instalada. Durante la operación de configuración,

se llama a los métodos relacionados con la configuración de InstallHandler para realizar tareas.


Una vez configurada, la característica y los plug-ins que contiene pueden proporcionar función a

la plataforma.

Una característica que está actualmente habilitada se puede inhabilitar, pero sólo si al hacerlo no

se invalidan otras características que dependen de la característica o de los plug-ins que contiene.

Las operaciones de habilitación e inhabilitación necesitan un reinicio de plataforma a fin de que

los resultados entren en vigor.

Una vez explicado el ciclo de vida de las características, podemos describir el rol de InstallHandler, al

que se ha hecho referencia más arriba.

Los InstallHandler pueden ser específicos de una característica individual o globales para la plataforma

entera. Independientemente del tipo, el comportamiento y la secuencia de llamada son equivalentes.

La creación de la instancia de la clase InstallHandler se deberá realizar antes que cualquier operación. La

primera llamada (después del constructor) será siempre el método de inicialización. Este método

configura el manejador de instalación y proporciona información que se puede utilizar durante toda la

secuencia de llamada.

Durante una operación de instalación, se realizará la siguiente secuencia de llamadas:

1. initialize()

2. installInitiated()

3. pluginsDownloaded()

4. nonPluginDataDownloaded()

5. completeInstall()

6. installCompleted()

Consulte el javadoc para obtener información de firma específica. Una vez que se ha llamado al método

de inicialización, se realizará siempre la llamada installCompleted. A la llamada installCompleted se le

pasa un booleano que indica el éxito o la anomalía de la operación de instalación.

Las tareas que es necesario realizar para instalar la característica se deberán realizar durante el rango de

llamadas de installInitiated a completeInstall. Si se genera una CoreException durante estos métodos, la

característica no se podrá instalar. En el momento en que se llama al método installCompleted(), la

característica se instala o no se instala. Aunque en este punto la firma permite que se genere una

CoreException, se recomienda encarecidamente que las características no generen una CoreException a

partir de la llamada installCompleted (true), porque esto hará que se registren mensajes de error, pero

que la característica se instale de todos modos.

Durante la operación de configuración (o habilitación), se deberá realizar la siguiente secuencia de

llamadas:

1. initialize()

2. configureInitiated()

3. completeConfigure()

4. configureCompleted()

Como en el caso de instalación, una vez que se ha inicializado el manejador de instalación, se llamará

siempre al método configureCompleted(). Como en el caso de instalación, configureCompleted() permite

que se genere una CoreException, pero el trabajo se deberá realizar preferentemente en los métodos

configureInitiated o completeConfigure. Si se produce una anomalía en cualquiera de los métodos, la

característica no se configurará.

También se llama al manejador de instalación durante la operación de inhabilitación en la secuencia

siguiente:


1. initialize()

2. unconfigureInitiated()

3. completeUnconfigure()

4. unconfigureCompleted()

Una CoreException generada en el método unconfigureInitiated hará que se abandone el proceso del

manejador de instalación de la característica y no se llamará a los métodos completeUnconfigure y

unconfigureCompleted. A menos que las excepciones inhiban la llamada de otra forma, se llamará a

unconfigureCompleted() a continuación de una inicialización. Se sugiere que el principal trabajo de

manejador de instalación se realice en los métodos unconfigureInitiated() y completeUnconfigure().

Finalmente, se llamará al manejador de instalación durante la desinstalación de una característica.

1. initialize()

2. uninstallInitiated()

3. completeUninstall()

4. uninstallCompleted()

Una CoreException generada en el método uninstallInitiated hará que se abandone el proceso de

manejador de instalación de la característica y no se llamará a los métodos completeUninstall y

uninstallCompleted. A menos que las excepciones inhiban la llamada de otra forma, se llamará a

uninstallCompleted() a continuación de una inicialización. Se sugiere que el principal trabajo de

manejador de instalación se realice en los métodos uninstallInitiated() y completeUninstall().

Cuando se utiliza la configuración de plataforma multiusuario, las características instaladas por el

administrador y disponibles para los usuarios sólo se instalarán una sola vez. Esto significa que los

manejadores de instalación se ejecutarán como máximo una sola vez. Por esta razón y para anticiparse a

un cambio de dirección del proceso de instalación, no se recomienda que los manejadores de instalación

realicen trabajo relacionado con la configuración de características durante los métodos del manejador de

instalación relacionados con la instalación. Puesto que las características se configurarán (o habilitarán)

varias veces, como mínimo una vez en cada espacio de trabajo, la ubicación preferible para realizar

cambios relacionados con las características es en los métodos relacionados con la configuración.

Creación de una característica

Para crear una característica, utilice el entorno de desarrollo de plug-in en Eclipse o la plataforma de

desarrollo de software de Rational.

Antes de crear una característica, deberá tener los plug-ins y los fragmentos que estarán contenidos en la

característica:

1. En el espacio de trabajo, seleccione Archivo → Nuevo → Proyecto → Desarrollo de plug-ins → Proyecto

de característica

2. Entre el nombre de proyecto. Normalmente este nombre es el mismo que el ID de característica.

3. Entre el ID de característica, el Nombre de característica y la Versión de característica. El Proveedor

de característica y la Biblioteca de manejador de instalación son opcionales.

4. Seleccione Siguiente.

5. Seleccione los plug-ins y los fragmentos que desea añadir a la característica. Si no desea entrarlos en

este momento, puede seleccionar Finalizar ahora y añadir los plug-ins y fragmentos más adelante

utilizando el editor.

6. El editor se abre. Utilice las pestañas del editor para especificar información adicional:

Visión general

Entre información descriptiva de característica y los entornos soportados.

Información

Entre una descripción, la licencia, el copyright y otros sitios de actualización a visitar.


Plug-ins

Entre los plug-ins y los fragmentos que se deben empaquetar, así como información de

entornos soportados si es necesaria.

Incluir características

Entre las características adicionales a incluir, así como la información de entornos soportados

si es necesaria.

Dependencias

Entre la información de dependencias que se debe satisfacer antes de que se instale la

característica.

Instalación

Entre información como el manejador de instalación y otros archivos de datos.

Compilación

Seleccione los archivos que se empaquetarán en la característica.7. Guarde el contenido del editor.

Consulte la publicación Platform Plug-in Developers Guide y Eclipse (http://help.eclipse.org/help32/index.jsp) para obtener más información sobre cómo utilizar el editor de características.

Especificación de características hijo opcionales

El manifiesto de características (feature.xml) permite la definición de las características incluidas. Las

características incluidas definen una relación de padre e hijo para las características, por ejemplo las

acciones realizadas en el padre también se aplican al hijo. Por ejemplo, si se instala el padre, también se

instala el hijo. Una característica incluida se puede marcar como opcional. Esto permitirá instalar un

padre sin algunas de las características hijo opcionales.

Cuando la plataforma de Lotus Expeditor instala una característica nueva, se instalarán todos los hijos

opcionales de la característica, si están disponibles en los sitios de actualización especificados durante la

operación de instalación.

Control de la ubicación de instalación de característica

Este apartado explica los métodos disponibles para controlar y especificar el sitio de instalación de

destino para una característica.

El sistema de suministro de plataforma define de forma predeterminada los siguientes sitios de destino

en los que se instalan las características:

eclipse

Contiene las características y los plug-ins que se originan en la plataforma Eclipse.

rcp Contiene las características y los plug-ins que forman parte de la plataforma de cliente.

shared

Contiene características y plug-ins adicionales destinados a que los utilicen todos los usuarios de

la plataforma de cliente.

“user” Ubicado en el espacio de trabajo, este sitio de destino contiene características y plug-ins

adicionales destinados a que los utilice sólo un usuario individual de la plataforma de cliente.

El sitio de instalación de destino para una característica determinada se determina evaluando varias

condiciones, incluyendo si la característica está instalada actualmente, la afinidad de colocación, la

posibilidad de grabar en un directorio específico y el sitio de destino solicitado.

La afinidad de colocación (colocation-affinity) es un atributo que cada característica puede especificar en

el descriptor feature.xml. El atributo de afinidad de colocación especifica el ID de otra característica.

Indica al sistema de suministro que intente instalar la nueva característica en el mismo sitio de destino




que la otra característica (la característica cuyo ID se especifica en feature.xml). Mediante el uso del

Editor de manifiesto de característica desde el entorno de desarrollo de plug-in, se puede especificar la

afinidad de colocación en la página de instalación del editor.

Por ejemplo, suponga que la característica con un ID de com.ibm.sample se ha instalado en el sitio

compartido. A continuación, una nueva característica con un ID de com.ibm.extendedsample puede

especificar una afinidad de colocación de ″com.ibm.sample” para solicitar que la característica se instale

en la misma ubicación que com.ibm.sample:

<feature

id="com.ibm.extendedsample"

label="Extendedsample Feature"

version="1.0.0"

provider-name="IBM"

colocation-affinity="com.ibm.sample">

El sistema de suministro de plataforma utiliza estas decisiones para determinar el sitio de destino para

una característica.

1. Si un sistema de suministro detecta una versión de la característica que ya está instalada, se utilizará

el mismo sitio de instalación para las versiones adicionales. Esto sólo se aplica cuando la característica

se ha instalado en los sitios de Eclipse, RCP o de destino compartidos.

Si un desplegador instala una característica X versión 1.0.0 en el sitio compartido y, posteriormente,

intenta instalar la característica X versión 1.0.1, se instalará la versión 1.0.1 en el sitio compartido.

Si un usuario A instala una característica Y en el sitio de usuario del espacio de trabajo A y,

posteriormente, otro usuario B intenta instalar la característica Y, se instalará por segunda vez la

característica Y en el espacio de trabajo B, puesto que el espacio de trabajo A no está visible para el

usuario B.

2. Si feature.xml especifica el atributo de afinidad de colocación, se tomarán las siguientes decisiones:

a. Si se ha instalado la característica que se ha especificado en el atributo de afinidad de colocación,

intente instalar en ese sitio. Si ese sitio no es accesible para el usuario que instala la característica,

la instalación de característica fallará.

b. Si no se ha instalado la característica que se ha especificado en el atributo de afinidad de

colocación, continúe en el paso 3 del proceso de decisiones.3. Si se solicita un sitio de destino específico para la característica, intente instalar la característica en este

sitio. Si ese sitio no es accesible, continúe con el paso 5. Un sitio de destino sólo se puede especificar

para características distribuidas mediante el trabajo de distribución de características de Eclipse

utilizando el servidor de gestión de dispositivos.

4. Si el manifiesto de suministro o una solicitud de suministro (ProvisioningRequest) (proporcionada

mediante una solicitud de API) especifica shared = true, el sitio compartido es el sitio de destino

deseado para instalar la característica. Si ese sitio no es accesible, continúe con el paso 5. (Consulte

“DTD de manifiesto de suministro” en la página 181 para obtener más información sobre los atributos

disponibles mediante el manifiesto de suministro.

5. Si el manifiesto de suministro o un objeto ProvisioningRequest especifica shared = false o, si debido

a problemas de accesibilidad, los sitios de destino deseados para el paso 3 y el paso 4 no están

disponibles, intente instalar la característica en el sitio “user”.

Nota: El valor predeterminado del atributo compartido depende de la configuración de instalación. Si se

está utilizando una configuración de instalación multiusuario, el valor predeterminado de ″shared″

es true. Si se está utilizando una configuración de instalación de usuario único, el valor

predeterminado de ″shared″ es false.

Puesto que la afinidad de colocación tiene prioridad sobre la especificación de sitio de destino o de

atributo compartido, la especificación de una afinidad de colocación es el modelo preferido para controlar

las ubicaciones de instalación de característica. La plataforma de cliente ha definido las siguientes

características que se pueden utilizar como destinos para el atributo de afinidad de colocación:


com.ibm.rcp.site.anchor.shared.feature

Esta característica se instala siempre en el sitio compartido.

com.ibm.rcp.site.anchor.user.feature

Esta característica se instala siempre en el sitio de usuario.

Si la plataforma se utiliza alguna vez sólo por un usuario individual con un solo espacio de trabajo, el

sitio de destino para una característica es menos importante, puesto que estarán siempre disponibles

todas las características. En la configuración multiusuario, el sitio de instalación de destino se hace más

importante, porque algunas aplicaciones se deberán compartir entre todos los usuarios de la plataforma,

mientras que otras aplicaciones deberán ser privadas para usuarios específicos.

Por ejemplo, suponga una configuración multiusuario en la que los desplegadores tienen derechos de

administración en el directorio compartido, mientras que los usuarios normales están limitados a los

derechos de sólo lectura. La característica W no contiene un atributo de afinidad de colocación. Si un

desplegador intenta instalar esta característica, ésta se instalará en el directorio compartido, puesto que

ésta es la opción predeterminada sin afinidad de colocación y sin sitio de destino especificado. Sin

embargo, si un usuario intenta instalar esta característica, ésta se instalará en el sitio de destino de

usuario y no se podrá compartir entre todos los usuarios de la plataforma. Se deberá seleccionar el sitio

de usuario porque el sitio compartido no es accesible.

Para limitar la posibilidad de un usuario específico de instalar la característica W en el sitio de usuario, el

desplegador puede especificar un atributo de afinidad de colocación con el ID

“com.ibm.rcp.site.anchor.shared.feature”. El sitio resultante para un desplegador seguirá siendo el

sitio compartido, elegido ahora no porque sea el valor predeterminado, sino porque la afinidad de

colocación selecciona dicho sitio. Cuando un usuario intente instalar la característica, la instalación fallará

porque el sitio especificado por la afinidad de colocación no es accesible.

Habilitación de características para actualizarlas

Este apartado proporciona información sobre cómo manejar las actualizaciones de las características. El

proceso de actualización de una aplicación es parecido al proceso de instalación inicial.

Lotus Expeditor Client utiliza los directorios eclipse y rcp/eclipse en la raíz de Lotus Expeditor Client

para sus propias características y plug-ins. El directorio shared se proporciona como una extensión de

Eclipse y ubicación de instalación predeterminada para las nuevas características.

Cuando se proporcionan nuevas versiones de las características, éstas se instalan en el mismo directorio

que la versión anterior. El directorio de instalación para una actualización de característica no puede

modificarse. Algunas características tienen especificado un atributo colocation-affinity. En este caso, la

característica y sus plug-ins se instalan en la misma ubicación que la característica especificada por el

atributo colocation-affinity.

Las versiones para las características se especifican mediante el calificador major.minor.service. Por

ejemplo, una versión 4.0.1 tiene una versión principal 4, una versión secundaria 0 y una versión de

servicio 1. Una versión equivalente es una versión que difiere con la primera en el nivel de servicio. Una

versión compatible es una versión que difiere con la primera en el nivel secundario. Por ejemplo, si

partimos de la versión 4.0.1 del ejemplo anterior, una versión 4.0.2 sería una versión equivalente, ya que

el valor de servicio es el primer valor que ha cambiado. Una versión 4.1.2 sería una versión compatible,

ya que el valor secundario es el primer valor que ha cambiado. Una versión principal es una versión que

difiere primero en el nivel principal. Por ejemplo, si utilizamos la versión de 4.0.1, una versión de 5.0.0 se

considerará una actualización de versión principal.

La posibilidad de actualizaciones automáticas proporcionada como parte del diálogo del Gestor de

aplicaciones sólo permite actualizaciones de versiones principales, equivalentes o compatibles, de acuerdo

con las preferencias seleccionadas en el diálogo Instalar/actualizar, al que se accede de este modo:

Gestionar → Preferencias → Instalar/actualizar. El valor predeterminado es para las actualizaciones


equivalentes. Aquí sólo pueden realizarse actualizaciones para características cuyos atributos de URL y

actualización están especificados en su archivo feature.xml. Por ejemplo:

<url>

<update_label="Sitio de actualización"

url=http://updatesite/com.your.plugin.site/site.xml>

</url>

Para obtener información adicional sobre el mantenimiento de versiones, consulte la sección de manifiesto

de características de la publicación Platform Plug-in Developer’s Guide y Eclipse (http://help.eclipse.org/help32/index.jsp).

Actualización de la característica de Eclipse en dispositivos

Puede buscar actualizaciones en una o todas las aplicaciones existentes que están instaladas en Lotus

Expeditor Client en el dispositivo. Cuando están disponibles nuevas versiones de las características, éstas

se instalan en el mismo directorio que la versión anterior. El directorio de instalación para una

actualización de característica no puede modificarse.

El tipo predeterminado de actualización en Lotus Expeditor Client para dispositivos es equivalent. Esto

significa que el proceso de actualización buscará todas las versiones equivalentes en el sitio de

actualizaciones y actualizará a la versión más alta. El usuario no puede cambiar el tipo de actualización.

Sin embargo, el administrador puede cambiarlo utilizando un trabajo de configuración de propiedades.

Para cambiar el tipo de actualización, modifique la propiedad siguiente:

./Configuration/Properties/config.ini/Eclipse.update.core.updateVersions

donde config.ini es el nombre de archivo y Eclipse.update.core.updateVersions es la clave de la

propiedad. Se da soporte a tres valores de propiedad: equivalent, compatible y major. El valor

equivalent significa que el proceso de actualización sólo busca versiones equivalentes en el sitio de

actualizaciones. El valor compatible significa que el proceso de actualización busca todas las versiones

equivalentes y compatibles, y el valor major significa que el proceso de actualización busca todas las

versiones superiores a la existente.

Para obtener más información sobre la edición de propiedades, consulte Trabajos de edición de

propiedades en Utilización de Lotus Expeditor Server.

Exportación de una característica y del contenido

Una vez que se ha definido la característica, para desplegarla necesitará exportarla junto con sus plug-ins.

Si va a crear un sitio de actualización, vaya al apartado “Creación de un sitio de actualización”.

Si va a desplegar la característica, necesitará crear y exportar la característica y el contenido. Seleccione

Archivo → Exportar → Desarrollo de plug-ins → Características desplegables.

Seleccione las características a exportar, entre un directorio o archivo archivador y, a continuación,

seleccione Finalizar. El contenido de característica, así como los plug-ins, los fragmentos y la

características que se incluyen se exportarán al directorio o archivo archivador deseado.

Consulte la publicación Platform Plug-in Developers Guide y Eclipse (http://help.eclipse.org/help32/index.jsp) para obtener más información sobre cómo utilizar el editor de características.

Creación de un sitio de actualización

Se puede crear un proyecto de sitio de actualización en el espacio de trabajo actual o puede crearlo en

cualquier lugar del sistema de archivos local.






Siga estos pasos para crear un sitio de actualización

1. Seleccione Archivo → Nuevo → Proyecto → Desarrollo de plug-ins → Proyecto de sitio de actualización.

2. Entre el nombre de proyecto y, a continuación, seleccione Finalizar.

3. Se abre el Editor de manifiesto de sitio, permitiéndole añadir características al sitio. Seleccione Añadir

característica para añadir características al sitio.

Sólo necesita añadir las características que desea dejar disponibles específicamente para la instalación.

Aquí no es necesario añadir características incluidas en otras características a menos que desee que se

puedan instalar por separado.

4. Una vez que haya añadido todas las características, seleccione Crear o Crear todo para crear las

características y el contenido de característica.

Consulte la publicación Platform Plug-in Developers Guide y Eclipse (http://help.eclipse.org/help32/index.jsp) para obtener más información sobre cómo utilizar el editor de sitio de actualización.

Utilización del manejador de instalación global

Los manejadores de instalación son clases Java que ejecutadas por el gestor de actualizaciones durante el

proceso de instalación, configuración y desinstalación de una característica.

El gestor de actualizaciones puede manejar la instalación estándar de características, plug-ins y

fragmentos sin grabar ningún código Java. Sin embargo, si es necesario realizar tareas adicionales durante

el proceso de instalación, configuración y desinstalación, se puede utilizar un manejador de instalación

para realizar estas tareas. Por ejemplo, los manejadores de instalación pueden realizar tareas tales como

las actualizaciones de archivos de configuración.

La plataforma de cliente proporciona un manejador de instalación que se puede utilizar para realizar

actualizaciones en archivos existentes en el sistema cliente. El manejador de instalación proporciona

posibilidades adicionales además de las ofrecidas por el manejador de instalación predeterminado

proporcionado por Eclipse. Las posibilidades proporcionadas por el manejador de instalación incluyen las

siguientes:

v Posibilidad de modificar los valores de rcpinstall.properties para un usuario individual o varios

usuarios para:

– bootclasspath

– PATH / LD_LIBRARY_PATH

– Vía de acceso de clase

– Propiedades de sistema VM

– VM

– Otras propiedadesv Posibilidad de establecer ubicaciones de VM (Virtual Machine - Máquina virtual) que implementa las

especificaciones Java, la ubicación base de RCP, la ubicación de iniciador de RCP, la ubicación de

manifiesto de suministro y la versión

v Posibilidad de lanzar un ejecutable o script nativo

Creación del archivo de instrucciones de manejador de instalación

El manejador de instalación procesa instrucciones de un archivo denominado handler.properties que está

presente en la característica.

Los archivos handler.properties no deben contener referencias de vía de acceso absolutas, porque la

ubicación de archivo real pueden cambiar en función del directorio de lanzamiento o del directorio de

espacio de trabajo. En su lugar, se deberán utilizar los parámetros de sustitución disponibles, porque

éstos manejarán correctamente los cambios para asegurar el funcionamiento correcto de la plataforma

cuando cambie la ubicación de lanzamiento o la ubicación del directorio de espacio de trabajo.




Todos los mandatos normales (mandatos relacionados con ″exec.command″) se ejecutan durante la fase

de completeConfigure() de la instalación. También es importante tener en cuenta que la mayoría de los

mandatos (mandatos relacionados con ″exec.command″) deben eliminar adecuadamente las acciones

durante la fase de completeUnconfigure() de la instalación.

Xbootclasspath.prepend=<vía de acceso>

Xbootclasspath.append=<vía de acceso>

Añade todas las entradas listadas a las propiedades Xbootclasspath.prepend o

Xbootclasspath.append de rcpinstall.properties.

Lo utiliza el iniciador nativo para establecer la opción vm -Xbootclasspath.

library.path.prepend=<vía de acceso>library.path.append=<vía de acceso>

Añade todas las entradas listadas a las propiedades library.path.prepend o library.path.append

en rcpinstall.properties

Modifica PATH en Windows o LD_LIBRARY_PATH en Linux.

-D<valor>=<pareja>

Añade valores de valor-pareja para agregar definiciones de propiedades de sistema VM a

rcpinstall.properties.

Lo utiliza el iniciador nativo para añadir valores a la vm.

vm Añade el valor de vm a rcpinstall.properties.

Lo utiliza el iniciador nativo para añadir entradas a la variable de vía de acceso de sistema.

jvm.location=<valor>

Modifica la ubicación de jvm en rcplauncher.properties.

rcp.base.location=<valor>

Modifica la ubicación base de rcp en rcplauncher.properties.

rcp.launcher.location=<valor>

Modifica la ubicación de iniciador de rcp en rcplauncher.properties.

exec.command.<os><arch>=<mandato>u.exec.command.<os><arch>=<mandato>

Ejecuta un mandato utilizando Runtime.exec() desde el directorio de características. Se procesa

exec.command durante el proceso de habilitación de características. Se procesa u.exec.command

durante el proceso de inhabilitación de características. Si un argumento del <mandato> contiene

espacios, incluya el argumento entre comillas (″″). exec.command/u.exec.command puede ser útil

para ejecutar scripts o registrar servicios Windows. Por ejemplo:

exec.command.win32x86=regsvr32 /s my.dll

exec.command.linuxx86=sh –c myscript.sh

exec.command.win32x86="C:\Archivos de programa\SomeProgram\Program.exe" "C:\Documents and Settings\user\Application Data"

mergemanifest=<valor>

Fusiona el archivo especificado por <valor> en el manifiesto de suministro actual identificado por

rcplauncher.properties. Se espera que <valor> sea una ubicación de sistema de archivos para un

nuevo archivo de manifiesto de suministro. A continuación se muestran ejemplos del mandato

mergemanifest:

mergemanifest=${plugin.dir}/com.ibm.rcp.newmanifest_1.0.0/upgrade.xml

mergemanifest=${features.dir}/com.ibm.rcp.newmanifest.feature_1.1.0/install.xml

Consulte “Descripción del proceso de fusión del manifiesto de suministro” en la página 177 para

obtener más información sobre el proceso de fusión.

product=<valor>

Especifica el ID de producto que utilizará como valor predeterminado la plataforma. Esto hace

que se añada la propiedad product al archivo rcplauncher.properties. Normalmente este mandato


lo utiliza una característica de creación de marcas que ha proporcionado una nueva definición de

producto. El atributo de producto se elimina durante una operación de inhabilitación de

característica.

config.<id>.<configuración>=<valor>

Añade una línea config al archivo rcplauncher.properties. Consulte “Actualización del archivo

rcplauncher.properties” en la página 97 para obtener más información sobre cómo se utiliza el

atributo config en el archivo rcplauncher.properties.

file.copy <id>=<destino><tabulador><origen>

Realiza una operación de copia de archivo durante la operación de habilitación de característica.

<id> Identificador exclusivo que diferencia varios mandatos de copia de archivo

<destino>

Archivo de destino

<tabulador>

Carácter de tabulador que se utiliza para separar el origen y el destino

<origen>

Archivo de destino

Al inhabilitar la característica, se elimina el archivo de <destino>.

product.name

Especifica la clave de registro (Windows) o el nombre de archivo (Linux) que contiene la vía de

acceso al programa iniciador. Consulte “Localización del programa iniciador de Lotus Expeditor

Client” en la página 24 para obtener más información sobre cómo se utiliza el mandato

product.name. Normalmente el mandato product.name se deberá utilizar como parte de la

operación de creación de marcas. Al inhabilitar características, se eliminará la clave de registro o

el archivo.

osgi.splashPath=<valor>

Añade la propiedad osgi.splashPath al archivo rcplauncher.properties. El valor es un URL que

hace referencia a la ubicación de la imagen inicial. Por ejemplo, la característica de creación de

marcas para IBM Lotus Expeditor especifica lo siguiente:

osgi.splashPath=platform\:/base/../rcp/eclipse/plugins/...

com.ibm.rcp.platform.personality.branding

Normalmente este mandato lo utiliza una característica de creación de marcas que necesita

especificar la imagen inicial. Al inhabilitar la característica, la propiedad se eliminará del archivo


env.set.<id>=<valor>

Añade la propiedad env.set.<id>=<valor> al archivo rcpinstall.properties. Consulte

“Actualización del archivo rcpinstall.properties” en la página 101 para obtener más información

sobre cómo se utiliza la propiedad env.set en el archivo rcpinstall.properties.

Se soportan los siguientes símbolos para vías de acceso en el archivo handler.properties:

${product.install.dir}${rcp.home}

Directorio de instalación para la plataforma.

${features.dir}

Directorio de características del sitio en el que se está instalando la característica actual.

${old.feature.dir}

Directorio de instalación anterior de la característica si existe.


${plugin.dir}

Directorio de plug-ins del sitio en el que se está instalando la característica actual.

${plugin.dir.<id>}

Nombre de directorio de instalación para el plug-in proporcionado <id>.

${old.plugin.dir.<id>}

Nombre de directorio de instalación anterior para el plug-in proporcionado<id>.

${rcp.os}

Sistema operativo de plataforma (por ejemplo win32).

${rcp.arch}

Arquitectura de plataforma (por ejemplo x86).

Creación de instrucciones para actualizaciones de escritorio

El manejador de instalación global soporta la creación de objetos relacionados con el escritorio.

Utilice el manejador de instalación global para:

v Crear/suprimir un enlace de escritorio (sólo Windows)

v Crear un grupo de programas (sólo Windows y Linux)

v Añadir/eliminar un enlace al grupo de programas (sólo Windows y Linux)

Para habilitar estas funciones, incluya un directorio /links en la característica con archivos de

propiedades que llenen las siguientes propiedades. También es posible incluir un directorio (denominado

según el sistema operativo y la arquitectura) que lea los archivos de propiedades sólo cuando el sistema

operativo correcto y la arquitectura correcta utilicen la característica. Por ejemplo, si crea un directorio

denominado /win32x86 en la característica, los archivos de propiedades de este directorio sólo se

aplicarían si el sistema operativo es win32 y la arquitectura es x86.

El formato de los archivos de propiedades para crear enlaces y grupos de programas es el siguiente:

Tabla 19. Formato de archivos de propiedades

Nombre clave de enlace Constantes de tipo serie Obligatorio Descripción

link.context CONTEXT_DESKTOP

CONTEXT_PROGRAMS

sí El valor puede ser una de las

constantes. Establece como

contexto de operación el

escritorio o un grupo de

programas.

link.foldername N/D no Este valor sólo se utiliza cuando

el contexto de un enlace es

CONTEXT_PROGRAMS. Es el nombre

de la carpeta de grupo de

programas. Si se omite, el enlace

se creará en el grupo de

programas raíz.

link.displayname N/D sí Es el nombre de visualización

del enlace. En Windows, el

nombre de archivo del enlace

será <nombre de

visualización>.lnk.


Tabla 19. Formato de archivos de propiedades (continuación)

Nombre clave de enlace Constantes de tipo serie Obligatorio Descripción

link.iconpath Se puede iniciar con una de las

siguientes constantes de vía de

acceso:

$FEATURE_DIR

$RCP_DIR

$ECLIPSE_DIR

$WORKSPACE_DIR"

no Sólo es necesario si el ejecutable

de destino no tiene un recurso

de icono incorporado. Se utiliza

para especificar un icono para

un enlace de programa. Valores

de ejemplo:

c:\\winnt\\icon.ico

$FEATURE_DIR\icons\

myicon.ico

link.target Se puede iniciar con una de las


acceso:

$FEATURE_DIR

$RCP_DIR

$ECLIPSE_DIR

$WORKSPACE_DIR"

sí Es la vía de acceso y el nombre

de archivo del ejecutable de

destino que se debe lanzar.

Valores de ejemplo:

c:\\winnt\\notepad.exe

$ECLIPSE_DIR\\

eclipse.exe

link.args N/D no Son los argumentos de línea de

mandatos para el destino

link.workingdir Se puede iniciar con una de las


acceso:

$FEATURE_DIR

$RCP_DIR

$ECLIPSE_DIR

$WORKSPACE_DIR"

no Es la vía de acceso y el nombre

de archivo del ejecutable de

destino que se debe lanzar.

Valores de ejemplo:

c:\\myworkingdir

$ECLIPSE_DIR

link.windowstate Puede ser una de las siguientes

constantes de estado de ventana:

WINDOW_STATE_NORMAL

WINDOW_STATE_MIN

WINDOW_STATE_MAX

no Es el estado de ventana inicial

del ejecutable de destino.

Tabla 20. Constantes de tipo serie - Constantes de contexto de enlace

Constante de tipo serie Descripción

CONTEXT_DESKTOP Indica que es un enlace de escritorio

CONTEXT_PROGRAMS Indica que este enlace es un grupo de programas.

Tabla 21. Constantes de tipo serie - Constantes de sustitución de vía de acceso


$FEATURE_DIR Se utiliza donde se permite la sustitución de vía de acceso. Se resuelve en la vía de

acceso instalada en el directorio raíz de esta característica. Ejemplo:

C:\Documents and Settings\testuser\Application Data\Lotus\XPD\

applications\eclipse\features\com.ibm.rcp.installhandler.test.feature

$RCP_DIR Se utiliza donde se permite la sustitución de vía de acceso. Se resuelve en la raíz

del directorio RCP de cliente RCP instalado. Ejemplo:

c:\ibm\rich client\rcp

$ECLIPSE_DIR Se utiliza donde se permite la sustitución de vía de acceso. Se resuelve en la raíz

del directorio Eclipse de cliente RCP instalado. Ejemplo:

c:\ibm\rich client\eclipse


Tabla 21. Constantes de tipo serie - Constantes de sustitución de vía de acceso (continuación)


$WORKSPACE_DIR Se utiliza donde se permite la sustitución de vía de acceso. Se resuelve en la raíz

de espacio de trabajo del usuario activo. Ejemplo:

C:\Documents and Settings\someuser\Application Data\Lotus\XPD

Tabla 22. Constantes de estado de ventana de enlace


WINDOW_STATE_NORMAL Lo utilizan los enlaces para establecer el estado de lanzamiento inicial del destino

en normal.

WINDOW_STATE_MIN Lo utilizan los enlaces para establecer el estado de lanzamiento inicial del destino

en minimizado.

WINDOW_STATE_MAX Lo utilizan los enlaces para establecer el estado de lanzamiento inicial del destino

en maximizado.

Utilice las tablas siguientes para localizar iconos, en función del tipo de usuario y características y de la

configuración de instalación.

v Ubicaciones de atajos de escritorio y menús de Windows:

Tabla 23. Ubicaciones de atajos de escritorio y menús de Windows

Caso

Ubicación de atajo

de escritorio

(configuración de un

solo usuario)

Ubicación de menú

(configuración de un

solo usuario)

Ubicación de atajo

de escritorio

(configuración

multiusuario)

Ubicación de menú

(configuración

multiusuario)

El usuario admin y

la característica se

comparten

El atajo va a

escritorio local

El menú va a menú

de inicio local

El atajo va a todos los

usuarios/escritorio

El menú va a todos

los usuarios/menú de

inicio

El usuario admin y

la característica no se

comparten

El atajo va a

escritorio local

El menú va a menú

de inicio local

El atajo va a

admin/escritorio

El menú va a

admin/menú de

inicio

El usuario no admin

y la característica se

comparten

El atajo va a

escritorio local

El menú va a menú

de inicio local

El atajo va a

usuario/escritorio

El menú va a

usuario/menú de

inicio

El usuario no admin

y la característica no

se comparten

El atajo va a

escritorio local

El menú va a menú

de inicio local

El atajo va a

usuario/escritorio

El menú va a

usuario/menú de

inicio

v Ubicaciones de atajos de escritorio y menús de Linux:

Tabla 24. Ubicaciones de menús y atajos de Linux

Caso

Ubicación de menú (configuración de un

solo usuario)

Ubicación de menú o atajo (configuración

multiusuario)

El usuario admin y la

característica se

comparten

El menú va a /.local/share/applications El menú va a /usr/share/applications

El usuario admin y la

característica no se

comparten

El menú va a /.local/share/applications El menú va a admin_home/.local/share/applications

El usuario no admin

y la característica se

comparten

El menú va a /.local/share/applications El atajo va a user_home/.local/share/applications


Tabla 24. Ubicaciones de menús y atajos de Linux (continuación)

Caso

Ubicación de menú (configuración de un

solo usuario)

Ubicación de menú o atajo (configuración

multiusuario)

El usuario no admin

y la característica no

se comparten

El menú va a /.local/share/applications El atajo va a user_home/.local/share/applications

Adición del manejador de instalación global a una característica

Puede añadir el manejador de instalación global a una característica.

Para añadir el manejador de instalación global a feature.xml, utilice el Editor de manifiestos de

característica.

1. Abra el archivo feature.xml utilizando el Editor de manifiestos de característica.

2. Seleccione la pestaña Instalación

3. Entre com.ibm.rcp.installhandler.RCPInstallHandler como Clase de manejador. No es necesaria

ninguna entrada en el atributo Biblioteca.

4. Seleccione la pestaña Compilar en el Editor de manifiestos de característica.

5. Verifique que el archivo handler.properties esté seleccionado en la sección de compilación binaria.

6. Verifique que el directorio de enlaces, si se utiliza, esté seleccionado en la sección de compilación

binaria.

7. Guarde el archivo feature.xml.

Despliegue de características en la plataforma

Este apartado describe la información y las tareas necesarias para desplegar características de aplicación e

infraestructura en la plataforma de cliente.

Nota: Si utiliza Windows Vista, asegúrese de consultar “Administración de la plataforma en Windows

Vista” en la página 25 antes de modificar la configuración de la plataforma.

Existen cuatro mecanismos para desplegar características en la plataforma de cliente:

Suministro gestionado de portal

Se distribuye del servidor de Portal al cliente un manifiesto de suministro que contiene las

instrucciones sobre qué características se deben instalar y de dónde se deben instalar. Para

obtener más información, consulte “Gestión de clientes ricos utilizando el servidor de Portal” en

la página 223.

Suministro basado en servidor Device Manager

Los trabajos específicos de instalación y gestión de características de Eclipse se crean en el

servidor, se distribuyen al cliente y los procesa el Agente de gestión de empresa. Para obtener

más información, consulte “Gestión utilizando el servidor Device Manager” en la página 197.

Utilización de la aplicación de suministro y del manifiesto de suministro

El manifiesto de suministro es un archivo XML que contiene un conjunto de instrucciones que

pertenecen a las características para instalar, habilitar, inhabilitar o eliminar. Lo puede utilizar

cualquier usuario o se puede utilizar como mecanismo iniciado desde otro sistema de gestión.

Para obtener más información, consulte “Gestión utilizando otro sistema de gestión” en la página

258.

Los cambios iniciados utilizando la aplicación de suministro son específicos sólo a una ejecución

individual, pero los pasos para solicitar los cambios se pueden duplicar fácilmente en muchos

sistemas.


Utilización de los diálogos de instalación de aplicación y gestión de aplicación

El usuario individual instala y gestiona específicamente las características instaladas utilizando

los diálogos disponibles. Los cambios son específicos sólo a una configuración y todos los

usuarios deben realizar los pasos. Esta modalidad de operación la utilizan normalmente los

desplegadores en una modalidad de prueba o los desarrolladores de aplicación o se utiliza en

escenarios donde es posible que sólo haya unas pocas plataformas instaladas localmente.

Mediante el uso de cualquiera de los métodos anteriores, puede realizar las tareas siguientes.

Instalación de características en la configuración multiusuario

La instalación multiusuario se selecciona durante la instalación inicial. Como resultado de la sección de la

instalación multiusuario, la propiedad install.configuration se establece en multiuser.

Como administrador, es responsable de realizar la instalación inicial y debe restringir el acceso a los

directorios, otorgándoles a los usuarios tan solo permiso de lectura/ejecución.

Cuando otro usuario lanza Lotus Expeditor Client por primera vez, basándose en la plataforma instalada

se crea un nuevo espacio de trabajo utilizando el manifiesto de suministro especificado en el archivo


En los lanzamientos subsiguientes realizados por el mismo usuario, el valor de

provisioning.manifest.version de su archivo rcpinstall.properties se comparará con el valor especificado

en el archivo rcplauncher.properties de la plataforma. Si los valores son diferentes, el iniciador iniciará la

aplicación de suministro para volver a procesar el manifiesto de suministro definido en el archivo


Instalación de aplicaciones para usuarios en modalidad multiusuario (entorno de trabajo no

restringido)

Como administrador, si piensa instalar y habilitar características para cada usuario del sistema, siga estos

pasos. De lo contrario, consulte “Adición de una característica nueva a los sitios de instalación

compartidos” en la página 174 y “Adición de una característica nueva al sitio de instalación de usuario”

en la página 175.

1. Si utiliza Linux, modifique los permisos de propietario del directorio <espacio de trabajo de

usuarios> especificando chown -R root <espacio de trabajo de usuarios> donde <espacio de

trabajo de usuarios> es el directorio totalmente calificado que contiene los directorios de registros,

aplicaciones y .config. Ejemplo: /home/myuser/Lotus/XPD

2. Lance Lotus Expeditor Client con los parámetros de línea de mandatos -data <espacio de trabajo de

usuarios>, donde <espacio de trabajo de usuarios> es el directorio totalmente calificado que

contiene los directorios de registros, aplicaciones y .config. Windows - Ejemplo: C:\Documents and

Settings\myuser\Application Data\Lotus\XPD Linux - Ejemplo: /home/myuser/Lotus/XPD

3. Pulse Archivo → Aplicación → Gestión de aplicaciones y, a continuación, localice las aplicaciones que

desea habilitar para el usuario.

Para cada característica que debe habilitarse, seleccione la característica y, a continuación, seleccione la

acción Habilitar. Si deben habilitarse múltiples características, debe habilitarlas una a una. A pesar de

que se le solicite reiniciar después de cada acción, puede habilitar varias características antes de

reiniciar.

4. Permita que Lotus Expeditor Client se reinicie cuando se le solicite y asegúrese de que las nuevas

aplicaciones estén disponibles.


6. Si utiliza Linux, restaure los permisos de propietario del directorio <espacio_trabajo_usuarios>

especificando chown -R <nombre_usuario><espacio_trabajo_usuarios> donde <nombre_usuario> es la

identidad de inicio de sesión de Linux para el usuario.


Nota: Estos pasos se deben realizar para cada usuario para el lque desee habilitar la aplicación recién

instalada.Además, cada usuario puede habilitar las aplicaciones según sea necesario, realizando los pasos 2 y 3

anteriores después de lanzar normalmente Lotus Expeditor Client.

Instalación de aplicaciones para usuarios de entorno de trabajo restringido

El entorno de trabajo restringido impide que los usuarios normales instalen aplicaciones, lo que hace

necesario que el administrador realice todas las instalaciones. Para instalar aplicaciones para usuarios de

entorno de trabajo restringido, realice los pasos siguientes:

1. Inicie la sesión en el sistema operativo como usuario administrador que ha instalado Lotus Expeditor

Client.

2. Lance Lotus Expeditor Client.

3. Pulse Archivo → Aplicación → Instalar y utilice el asistente de instalación para instalar las

aplicaciones deseadas.

4. Permita que Lotus Expeditor Client se reinicie cuando se le solicite.


6. Si utiliza Linux, modifique los permisos de propietario del directorio <espacio de trabajo de

usuarios> especificando chown -R root <espacio de trabajo de usuarios> donde <espacio de

trabajo de usuarios> es el directorio totalmente calificado que contiene los directorios de registros,

aplicaciones y .config. Ejemplo: /home/myuser/Lotus/XPD

7. Lance Lotus Expeditor Client con los parámetros de línea de mandatos -data <espacio de trabajo

de usuarios>, donde <espacio de trabajo de usuarios> es el directorio totalmente calificado que

contiene los directorios de registros, aplicaciones y .config. Windows - Ejemplo: C:\Documents and

Settings\myuser\Application Data\Lotus\XPD Linux - Ejemplo: /home/myuser/Lotus/XPD

8. Pulse Archivo → Aplicación → Gestión de aplicaciones y, a continuación, localice las aplicaciones a

habilitar para este usuario de entorno de trabajo restringido.

Para cada una de las características que deben habilitarse, seleccione la característica y, a

continuación, seleccione la acción Habilitar. Si deben habilitarse múltiples características, debe

habilitarlas una a una. A pesar de que se le solicite reiniciar después de cada acción, puede habilitar

varias características antes de reiniciar.

9. Permita que Lotus Expeditor Client se reinicie cuando se le solicite y asegúrese de que las nuevas

aplicaciones estén disponibles.


11. Si utiliza Linux, restaure los permisos de propietario del directorio <espacio_trabajo_usuarios>

especificando chown -R <nombre_usuario><espacio_trabajo_usuarios> donde <nombre_usuario> es la

identidad de inicio de sesión de Linux para el usuario.

12. Finalice la sesión del usuario administrativo del sistema operativo.

13. Inicie la sesión en el sistema operativo como usuario del entorno de trabajo restringido. Esto iniciará

automáticamente Lotus Expeditor Client y las aplicaciones estarán ahora disponibles.

Nota: Estos pasos se deben realizar para cada usuario de entorno de trabajo restringido.

Adición de una característica nueva a los sitios de instalación compartidos

El modelo preferido para un administrador para añadir una característica nueva a la plataforma en uno

de los sitios compartidos (directorios eclipse, rcp o shared) es el siguiente:

v Instale la característica en uno de los directorios compartidos (utilizando el servidor Device Manager, el

suministro gestionado de Portal u otro medio)

v Actualice el manifiesto de suministro especificado por el archivo rcplauncher.properties para incluir

una definición de la característica que se ha desplegado

v Actualice provisioning.manifest.version en rcplauncher.properties a un valor nuevo


Dado que provisioning.manifest.version no coincidirá con los valores de los espacios de trabajo de

usuarios, cuando éstos inicien individualmente la plataforma, recibirán automáticamente en la

configuración la característica nueva habilitada.

El administrador también puede añadir manualmente una característica nueva a la plataforma en uno de

los sitios de instalación compartidos (directorios eclipse, rcp o shared). La característica se instalará

siguiendo las normas de selección de sitio de instalación definidas en “Control de la ubicación de

instalación de característica” en la página 162. Una vez que la característica se ha añadido a la

plataforma, cada usuario debe habilitar individualmente dicha característica en la configuración.

Adición de una característica nueva al sitio de instalación de usuario

Los usuarios pueden instalar características en un sitio de instalación existente en el espacio de trabajo.

Estas características sólo están disponibles para el usuario que las ha instalado.

Adicionalmente, si el desplegador desea que las aplicaciones se desplieguen individualmente en los

espacios de trabajo de los usuarios, también puede seguir pasos similares a la adición de una

característica nueva al sitio de instalación compartido. Si se actualiza el manifiesto de suministro para

incluir la característica, pero se especifica un atributo ″shared″ con un valor ″false″, se indica a la

característica que se instale en el sitio de usuario.

Supresión de características de los sitios de instalación compartidos

Es necesario que los usuarios eliminen características de los espacios de trabajo antes de que el

administrador elimine características de la plataforma. Si la característica se suprime de la plataforma

antes de eliminarse de los espacios de trabajo de usuario, los usuarios encontrarán varios errores

relacionados con las características que faltan y no podrán realizar cambios en la plataforma.

El modelo preferido de un administrador para realizar una eliminación de una característica de la

plataforma es el siguiente:

v Actualice el manifiesto de suministro especificado por el archivo rcplauncher.properties para cambiar la

acción correspondiente a la característica de instalar a inhabilitar o bien para añadir la característica al

manifiesto de suministro con una acción de inhabilitar

v Actualice provisioning.manifest.version en rcplauncher.properties a un valor nuevo

Cuando los usuarios lancen la plataforma, se inhabilitará la característica en la configuración. Cuando la

característica se haya eliminado de todas las configuraciones de usuario, el administrador podrá eliminar

la característica de sitio de instalación compartido.

Supresión de características de los sitios de instalación de usuario

Los usuarios pueden suprimir características de su propia configuración, pero esto no afecta a las

características instaladas en el sitio compartido o en otros sitios de usuario.

Si el desplegador ha configurado el manifiesto de suministro para instalar la característica en el sitio de

instalación de usuario, la acción para la característica se puede cambiar a “uninstall” (desinstalar) para

eliminarla de cada una de las configuraciones de usuario cuando éstos reinicien la plataforma.

Utilización del manifiesto de suministro

El proceso de instalación de Expeditor Client consta de dos pasos: instalación de archivos de plataforma

básicos y suministro de componentes adicionales. En función de la configuración de instalación deseada

(usuario o multiusuario), se proporcionan conjuntos diferentes de componentes al producto desde los

sitios de actualización.


El conjunto de componentes que se deben suministrar se define en manifiestos de suministro,

procesados por el instalador y el sistema de suministro de la plataforma. Estos archivos deben estar

presentes en un directorio deploy/ que se encuentra en la misma ubicación que el archivo ejecutable del

instalador. Los manifiestos de suministro se deben denominar user.xml o multiuser.xml (correspondiente

a las configuraciones de instalación disponibles).

El conjunto de componentes que se deben suministrar se define dentro de un manifiesto de

suministro, procesado por el instalador y el sistema de suministro de la plataforma. El archivo debe tener

el nombre install.xml y estar situado en un directorio deploy/ que se encuentre en la misma ubicación

que el ejecutable del instalador

El CD de Expeditor Client incluye el manifiesto de suministro para cada una de estas configuraciones de

instalación. Estos archivos no pueden modificarse porque residen en el CD. Sin embargo, si el contenido

del directorio de instalación se copia en un sistema de archivos de lectura-grabación (como en el caso de

un escenario de descarga Web), los archivos se pueden modificar para que cada una de estas

configuraciones de instalación incluya un conjunto personalizado de componentes.

Nota: La modificación de estos manifiestos de suministro respecto a su estado original puede hacer que

una instalación de plataforma no sea válida.

Durante el proceso de instalación, el manifiesto de suministro correspondiente a la configuración de

instalación elegida se procesa (sustituyendo las variables soportadas) y se copia en <destino de

producto>/rcp/deploy/install.xml.

Durante el proceso de instalación, el manifiesto de suministro se procesa (sustituyendo las

variables soportadas) y se copia en <destino de producto>/rcp/deploy/install.xml.

La ubicación de este archivo se pasa luego al componente de suministro de la plataforma para iniciar el

proceso de suministro.

La plataforma Expeditor define un conjunto predeterminado de características que se suministrarán

durante la instalación inicial. La lista de características se puede actualizar antes de la instalación para

eliminar características que no se desean o para añadir características personalizadas o específicas de

aplicación.

En todas las configuraciones, el iniciador (rcplauncher.exe) lee rcplauncher.properties para determinar la

propiedad provisioning.manifest.version y la compara con la versión especificada actualmente en

rcpinstall.properties. Si la versión de rcplauncher.properties es posterior a la versión del archivo

rcpinstall.properties, el iniciador iniciará la aplicación de suministro de plataforma para actualizar la

plataforma basándose en el manifiesto de suministro (especificado en rcplauncher.properties).

En la configuración de plataforma multiusuario, el manifiesto de suministro se utiliza por consiguiente

como base para crear el nuevo espacio de trabajo para cada usuario.

Al actualizar el contenido del manifiesto de suministro y provisioning.manifest.version, el iniciador

iniciará la aplicación de suministro para procesar el manifiesto de suministro.

Mientras que el manifiesto de suministro se puede actualizar directamente en el sistema, el modelo

preferido para distribuir un nuevo manifiesto es utilizar el mandato mergemanifest proporcionado por el

manejador de instalación global. El manejador de instalación proporciona un mecanismo para desplegar

un nuevo manifiesto de suministro y para fusionarlo con el manifiesto existente presente en el sistema.

Esto permite el despliegue de un subconjunto de cambios nuevos que se fusionarán en el manifiesto

existente sin necesidad de especificar un archivo entero.


El mandato mergemanifest también se utiliza para proporcionar una nueva versión del manifiesto de

suministro, como sucede durante una actualización de la plataforma existente.

Descripción del proceso de fusión del manifiesto de suministro

Normalmente, el manifiesto de suministro tiene dos finalidades. Durante la instalación inicial, el

manifiesto de suministro proporciona instrucciones para que el programa de instalación especifique las

opciones disponibles para la instalación y también especifica las características que es necesario instalar

durante el suministro inicial. Después de la instalación, el manifiesto de suministro se utiliza durante la

construcción de espacios de trabajo nuevos para proporcionar la configuración inicial de esos espacios de

trabajo.

El manifiesto de suministro también se utiliza durante las operaciones de suministro subsiguientes para

realizar modificaciones en la plataforma instalada. Durante las actualizaciones iniciadas mediante el

programa de instalación o las actualizaciones iniciadas a través de un sitio de actualización de instalación,

es posible que se proporcione un nuevo manifiesto de suministro a la plataforma con instrucciones para

la nueva configuración de espacio de trabajo. Dado que es posible que un desplegador haya modificado

el manifiesto de suministro original para personalizar la plataforma, el nuevo manifiesto de suministro se

fusiona con el manifiesto de suministro actual.

Cuando un manifiesto de suministro nuevo se fusiona con otro ya existente, el manifiesto de suministro

nuevo puede contener atributos mergeaction en las características e installfeatures presentes en el

manifiesto de suministro. Los atributos mergeaction proporcionan las normas sobre cómo fusionar el

contenido de los dos archivos de manifiesto de suministro.

El principio general es que permanezca instalado lo que estaba instalado anteriormente. Generalmente

sólo se realizarán actualizaciones en los componentes existentes y no se instalarán componentes nuevos a

menos que sea necesario como dependencia.

Más específicamente, las normas siguientes controlan el proceso de fusión:

Tabla 25. Normas de control de proceso de fusión

Manifiesto actual Nuevo manifiesto

Resultado si

Merge=″Add″

Resultado si

Merge=″Remove″

Resultado si no se

especifica fusión

(Merge)

Característica

especificada

Característica

especificada

No disponible Característica

eliminada del

manifiesto de

suministro

Característica

retenida con nuevos

atributos de

característica

Característica

especificada

Característica no

especificada

No disponible No disponible Característica

retenida con

atributos de

característica

anteriores

Característica no

especificada

Característica

especificada

Característica

retenida con nuevos

atributos de

característica

Característica

eliminada del

manifiesto de

suministro

Característica

eliminada del

manifiesto de

suministro

La acción de fusión especificada aquí se define en la definición de manifiesto de suministro. La acción de

fusión sólo se aplica al manifiesto de suministro y no se aplica a las características ya presentes en el

sistema de archivos. Durante el proceso de fusión, se elimina el atributo de acción de fusión.

En el manifiesto de suministro, las características son elementos del elemento installfeature. La tabla

anterior define para cada característica los resultados en una característica de instalación con el mismo

ID.


Las acciones de instalación también definen acciones de fusión que se procesan de acuerdo con esta tabla:

Tabla 26. Acciones de fusión adicionales

Manifiesto actual Nuevo manifiesto

Resultado con

merge=”Add”

Resultado con

merge=”Remove”

Resultado sin

atributo merge

Característica de

instalación

especificada

Característica de

instalación

especificada

No disponible La característica de

instalación entera se

elimina del manifiesto

Las características

en la característica

de instalación se

fusionan

individualmente

Característica de

instalación

especificada

Característica de

instalación no

especificada

No disponible No disponible Definición de

característica de

instalación anterior

retenida

Característica de

instalación no

especificada

Característica de

instalación

especificada

Nueva característica

de instalación

retenida en el

manifiesto

Característica de

instalación eliminada

del manifiesto

Característica de

instalación

eliminada del

manifiesto

Los escenarios siguientes ayudarán a ilustrar el proceso durante la operación de fusión.

Escenario I

Durante la instalación se ha utilizado el manifiesto original del producto y el se utiliza el instalador de

producto con el nuevo manifiesto del producto de actualización.

El manifiesto original contenía estas definiciones:

<feature id="A" version="1.0"/>

<feature id="B" version="1.0"/>

<feature id="C" version="1.0"/>

El nuevo manifiesto contenía estas definiciones:

<feature id="A" version="1.0.1"/>



Las características ya instaladas en el sistema se actualizarán como parte de la nueva instalación. Los

componentes nuevos opcionales proporcionados como parte del producto no se añadirán al manifiesto

puesto que no estaban presentes anteriormente. Los componentes nuevos necesarios se especificarán en el

manifiesto con atributos merge=”add”. El manifiesto resultante será el siguiente:




Escenario II

El desplegador ha modificado el manifiesto original del producto antes de la instalación inicial para

eliminar algunas de las características de producto. El instalador de producto se utiliza con el manifiesto

nuevo del producto de actualización (sin modificaciones).









Sólo las características ya presentes en el manifiesto original estarán en el manifiesto resultante. Las

características de producto originales eliminadas por el desplegador se eliminarán del manifiesto

resultante y, por consiguiente, no se instalarán ni se actualizarán. Los componentes nuevos opcionales

proporcionados como parte del producto no se añadirán al manifiesto puesto que no estaban presentes

anteriormente. Los componentes nuevos necesarios se retendrán en el manifiesto puesto que se han

especificado con los atributos merge=″add″.

El manifiesto resultante será el siguiente:



Escenario III

El desplegador ha modificado el manifiesto original de productos antes de la instalación inicial para

añadir características personalizadas adicionales. El instalador de producto se utiliza con el manifiesto

nuevo del producto de actualización.





<feature id="D" version="4.0"/>





Se retendrán todas las características presentes en el manifiesto original, incluidas las características

personalizadas. Las actualizaciones de los componentes de producto se retendrán puesto que están

presentes en el manifiesto existente. No se añadirán componentes nuevos opcionales al manifiesto. Los

componentes nuevos necesarios se añadirán al manifiesto puesto que contienen el atributo merge=″add″.

El manifiesto resultante contendrá lo siguiente:




<feature id="D" version="4.0"/>

Escenario IV

El desplegador necesita eliminar una característica del manifiesto resultante. La característica se debe

especificar en el manifiesto de actualización con mergeaction=″remove″.







<feature id="B" version="1.2" mergeaction="remove"/>



El manifiesto resultante contendrá las definiciones siguientes:



Escenario V

El desplegador necesita añadir una característica nueva al sistema a través del proceso de fusión. La

característica se debe especificar en el manifiesto de actualización con mergeaction = add.









<feature id="E" version="1.2" mergeaction="add"/>

El manifiesto resultante contendrá las definiciones siguientes:




<feature id="E" version="1.2"/>

Escenario VI

Está disponible una nueva installfeature que contiene características opcionales y que necesita añadirse al

manifiesto de suministro. El manifiesto de suministro original contiene lo siguiente:

<installfeature id=”A” name=”Característica necesaria A” required=”true”>

...

</installfeature>

<installfeature id=”B” name=”Característica opcional B” required=”false”>

...

</installfeature>

El manifiesto de suministro de actualización contiene lo siguiente:


...

</installfeature>


...

</installfeature>

<installfeature id=”C” name=”Característica opcional C” required=”false” mergeaction="add">

...

</installfeature>

Siguiendo las normas definidas más arriba, puesto que ni installfeature A ni installfeature B incluyen una

acción de fusión (mergeaction), se fusionarán las características presentes en cada una de estas

installfeature. Puesto que installfeature C contiene una mergeaction especificada como ″add″,

installfeature C se retendrá en el manifiesto resultante.


...

</installfeature>

<installfeature id=”B” name=”Característica necesaria B” required=”false”>

...

</installfeature>


<installfeature id=”C” name=”Característica opcional C” required=”false”>

...

</installfeature>

Escenario VII

Una de las características se ha ampliado, pero ahora se ha convertido en un componente de instalación

opcional. El manifiesto de suministro original contiene lo siguiente:


<feature id=”A.1” version=”1.0”/>

...

</installfeature>


...

</installfeature>

El manifiesto de suministro de actualización contiene lo siguiente:


<feature id=”A.1” version=”1.0” mergeaction=”remove”/>

...

</installfeature>


...

</installfeature>

<installfeature id=”C” name=”Característica opcional C” required=”false” mergeaction=”add”>


...

</installfeature>

Siguiendo las normas definidas más arriba, puesto que ni installfeature A ni installfeature B incluyen una

acción de fusión (mergeaction), se fusionarán las características presentes en cada una de estas

installfeature. Puesto que la característica A.1 tiene una mergeaction de ″remove″ de installfeature A, se

eliminará de installfeature A en el resultado. Puesto que installfeature C contiene una mergeaction

especificada como ″add″, installfeature C se retendrá en el manifiesto resultante. Se añadirán todas las

características presentes en installfeature C, de modo que la característica A.1, eliminada anteriormente de

installfeature A, está contenida ahora en installfeature C.


...

</installfeature>


...

</installfeature>

<installfeature id=”C” name=”Característica opcional C” required=”false”>


...

</installfeature>

DTD de manifiesto de suministro

El manifiesto de suministro es un archivo XML que lista las características que se deben instalar durante

la parte de suministro del proceso de instalación.

La estructura del manifiesto de suministro es la siguiente:




<!ELEMENT ibm-portal-composite (domain-object)+>




<!ELEMENT domain-object (object-data)+>

<!ATTLIST domain-object name CDATA #FIXED "com.ibm.rcp.installmanifest">



<!ELEMENT object-data (install)>



<!ELEMENT install (installfeature)+>



<!ELEMENT installfeature (requirements)>

<!ATTLIST installfeature

id CDATA #REQUIRED

name CDATA #IMPLIED

restartPersonality CDATA #IMPLIED

required CDATA #IMPLIED

mergeaction (add|remove) #IMPLIED>



<!ELEMENT requirements (feature)+>



<!ELEMENT feature EMPTY>

<!ATTLIST feature

id CDATA #REQUIRED

url CDATA #IMPLIED

version CDATA #REQUIRED

match (perfect|compatible|equivalent|greaterOrEqual) #IMPLIED

size CDATA #IMPLIED

download-size CDATA #IMPLIED

shared CDATA #IMPLIED

mergeaction (add|remove) #IMPLIED

action (install|installonly|enable|disable|uninstall|ignore)

"install"

remove CDATA "true" >

Mediante la utilización de esta estructura de manifiesto de suministro, se puede especificar cualquier

número de características y cada característica puede proceder de diferentes sitios de actualización de

origen. Cada característica puede proporcionar una norma de coincidencia para determinar si se debe

instalar o actualizar. El sitio de destino y la configuración de la característica también se pueden

especificar (utilizando los atributos shared y config) y se añadirán los tamaños proporcionados al tamaño

de la instalación indicada por el instalador para que se pueda presentar al usuario un tamaño de

plataforma total preciso (incluyendo los archivos instalados y suministrado).


Ejemplos

1. Instalación del ejemplo de entrada de pedidos en un CD-ROM de Lotus Expeditor Client:

Nota: La versión de característica mostrada aquí puede diferir de la versión enviada con el producto.<ibm-portal-composite>


<object-data>

<install>

<installfeature>

<requirements>

<feature id="com.ibm.rcp.samples.orderentry.feature" version="6.1.0.0-20060815" action="install" size="25"/>

</requirements>

</installfeature>

</install>

</object-data>

</domain-object>


2. Instalación de características ubicadas en dos sitios de servidor HTTP diferentes:

<ibm-portal-composite>


<object-data>

<install>

<installfeature>

<requirements>

<feature id="com.aaa.feature1" version="1.0.0" url="http://company1.com/updates" action="install" size="900"/>

<feature id="com.aaa.feature2" version="5.6.0" url="http://company1.com/updates" action="install" size="300"/>

<feature id="com.bbb.feature1" version="1.2.0" url="http://company2.com/site" action="install" size="50" shared="false"/>

<feature id="com.bbb.feature2" version="3.0.5" url="http://company2.com/site" action="install" size="2100" match="equivalent"/>

</requirements>

</installfeature>

</install>

</object-data>

</domain-object>


Instalación de contenido de idiomas adicional

Los entornos de ejecución de IBM Lotus Expeditor se han traducido para los idiomas del Grupo 1, Grupo

2 y Grupo 3.

Los idiomas del Grupo 1 son:

v Chino (simplificado)

v Chino (tradicional)

v Japonés

v Coreano

v Francés

v Alemán

v Italiano

v Español

v Portugués (Brasil)


v Árabe

v Checo

v Danés

v Neerlandés

v Finlandés

v Griego

v Hebreo

v Húngaro

v Noruego

v Polaco

v Portugués

v Ruso


v Sueco

v Turco

Nota: Al instalar una plataforma en Linux, los fragmentos específicos de los entornos locales hebreo y

árabe no se instalan en Linux. La instalación de los entornos locales hebreo y árabe en Linux y el

lanzamiento con esos entornos locales tampoco se soportan.


v Tailandés

v Catalán

v Rumano

v Eslovaco

v Esloveno

v Ucraniano

El inglés de EE.UU. se empaqueta en todas las características y los plug-ins de IBM Lotus Expeditor y

está disponible de forma predeterminada.

Durante la instalación inicial de la plataforma, sólo se instalan y habilitan las características de idioma

nacional que contienen el entorno local actual.

Nota: Si utiliza Windows Vista, asegúrese de consultar “Administración de la plataforma en Windows

Vista” en la página 25 antes instalar las características de idioma.

Para habilitar el contenido específico de entorno local, se deben instalar características de idioma nacional

adicionales. La plataforma se debe iniciar en el entorno local deseado para instalar y habilitar las

características de idioma nacional para dicho entorno local. Esto se puede llevar a cabo conmutando el

sistema al entorno local apropiado antes de iniciar IBM Lotus Expeditor. También se puede llevar a cabo

iniciando IBM Lotus Expeditor con un argumento de mandato –nl. Por ejemplo, para iniciar la plataforma

en francés, entre <dir_instalación>/rcp/rcplauncher.exe –nl fr.

Cuando IBM Lotus Expeditor se haya iniciado, instale el grupo apropiado de idiomas. Si necesita instalar

otro grupo, deberá concluir IBM Lotus Expeditor y cambiar el entorno local utilizando uno de los

métodos anteriores.

Si las Características de idioma nacional se instalan pero no coinciden con el entorno local de plataforma

actual, no se habilitarán las características.

Cuando se ve en el diálogo Aplicación → Gestión de aplicaciones, la lista de características instaladas y

habilitadas se filtra basándose en el entorno local. Por ejemplo, si se instalan las características de idiomas

de Grupo 1 y Grupo 2 y ha iniciado la plataforma utilizando el entorno local finlandés, el diálogo Gestión

de aplicaciones sólo mostrará las características de idiomas del Grupo 2 y no mostrará las características

de idiomas del Grupo 1.

Cuando se da soporte a un idioma distinto del inglés en una instalación multiusuario, deberá, como

administrador, instalar los grupos de idiomas correctos. Si el espacio lo permite, instale todos los grupos

de idiomas. Si sólo necesita el francés, instale sólo la traducción de idiomas del Grupo 1. Existen

restricciones respecto a cómo se puede realizar esta tarea. Para instalar idiomas del Grupo 1, debe iniciar

la plataforma en un idioma que el Grupo 1 soporte.

El sistema de suministro habilitará automáticamente un único grupo de entornos locales por usuario y no

soporta la conmutación automática entre grupos de entornos locales. En un entorno multiusuario, cada


usuario puede tener un grupo de entornos locales diferente a condición de que el administrador haya

instalado todos los paquetes NL necesarios antes de que los usuarios lancen IBM Lotus Expeditor y

suministren sus propios espacios de trabajo.

Actualización de características en la plataforma

Puede elegir diversos mecanismos para actualizar las características de la plataforma.

Puede actualizar las características existentes en la plataforma utilizando estos mecanismos:

v Utilice la interfaz de usuario del Gestor de actualizaciones (Archivo → Aplicación → Instalar → Buscar

nuevas características a instalar) para instalar manualmente nuevas versiones de características

v Distribuya las nuevas versiones de las características mediante la CAI (Composite Application

Infrastructure - Infraestructura de aplicaciones compuestas) y el suministro desde el servidor.

v Distribuya las nuevas versiones de las características a través del servidor Device Manager.

v Utilice un sistema de gestión alternativo para proporcionar un manifiesto de suministro y llamar a

ProvisioningApplication para instalar nuevas actualizaciones.

v Configure la plataforma para utilizar la función Buscar actualizaciones planificada automáticamente

Buscar actualizaciones examina el conjunto de sitios de actualizaciones definido por las características en

la plataforma y la política, según ha filtrado el proceso de lista blanca. Busca las actualizaciones de las

características existentes en la plataforma. Se propondrán las actualizaciones del conjunto de

características en la plataforma. La función de búsqueda de actualizaciones no propondrá la instalación

de nuevas características que no estén ya presentes en el sistema.

En cualquiera de los procesos mencionados anteriormente, las características actualizadas se instalarán y

habilitarán en la configuración actual. De acuerdo con el valor de la preferencia

com.ibm.rcp.provisioning/feature.history.size, una vez se ha instalado y habilitado una característica

con una versión actualizada, las versiones anteriores pueden eliminarse.

A menos que se actualice el manifiesto de suministro de la plataforma (definido en rcplauncher.properties

y que, por omisión, toma el valor del archivo rcp\deploy\install.xml) para que refleje estas

actualizaciones de características, la creación de nuevos espacios de trabajo intentará utilizar las versiones

definidas anteriormente de las características. Si dichas versiones anteriores ya no están instaladas, es

posible que la creación de nuevos espacios de trabajo falle.

El mandato mergemanifest del manejador de instalación global de la plataforma proporciona un

mecanismo para actualizar automáticamente el manifiesto de suministro, de forma que sea coherente en

todo momento con las características instaladas, y proporciona un mecanismo potente para actualizar la

plataforma. La utilización de mergemanifest reduce el enfoque en la actualización de varias características

y lo centra en la actualización de una característica, y posteriormente dirige el resto de actualizaciones de

características. El escenario siguiente ilustra cómo puede utilizarse el mandato mergemanifest para el

manejador de instalación global de la plataforma:

1. Defina una característica denominada CompanyApplications y déle la versión 1.0.0. No es necesario

que esta característica contenga ningún plug-in. Distribuya la característica CompanyApplications en

un sitio de actualizaciones.

2. Cree un archivo XML de política de actualizaciones en un servidor web o de archivos compartidos

que dirija todas las búsquedas de actualizaciones al sitio de actualizaciones que sólo contenga la

característica CompanyApplications.

3. Personalice la instalación de plataforma inicial para que incluya la característica

CompanyApplications.

4. Personalice el archivo plugin_customization.ini para que incluya la preferencia de URL de política de

actualizaciones y configure las plataformas para que busquen actualizaciones automáticamente.


5. Instale la plataforma, que ahora instalará la característica CompanyApplications. El manifiesto de

suministro contendrá la característica CompanyApplications y, si es necesario crear un nuevo espacio

de trabajo, la característica CompanyApplications estará en todas las plataformas.

Cuando haya actualizaciones que deban aplicarse a la plataforma, realice los pasos siguientes:

1. Cree un archivo de manifiesto de suministro que haga referencia a las características nuevas o

actualizadas que deban distribuirse a los clientes y que contenga los identificadores mergeaction

adecuados. Incluya en la característica el archivo de manifiesto de suministro.

2. Cree un archivo handler.properties que contenga el mandato mergemanifest que haga referencia al

manifiesto de suministro incluido en la característica

3. Actualice la característica CompanyApplications a una versión nueva, por ejemplo, 1.0.1.

4. Distribuya las otras características nuevas o actualizadas a un segundo sitio de actualizaciones. (Al

utilizar un segundo sitio de actualizaciones, la búsqueda de actualizaciones sólo identificará que debe

actualizarse la característica CompanyApplications, reduciendo la confusión sobre el número de

características que deben distribuirse).

5. Distribuya la característica CompanyApplications actualizada al sitio de actualizaciones al que hace

referencia la política de actualizaciones.

Cuando los clientes efectúen la búsqueda de actualizaciones planificada, detectarán la nueva característica

CompanyApplications y propondrán su instalación. Una vez se haya instalado y habilitado la

característica, se procesará el mandato mergemanifest, con lo cual, se actualizará el manifiesto de

suministro y la propiedad provisioning.manifest.version del archivo rcplauncher.properties. Al reiniciar la

plataforma, el iniciador de la plataforma detectará la diferencia entre la propiedad

provisioning.manifest.version actual y su versión anterior (comparada con el valor en el archivo

rcpinstall.properties) y procesará el contenido del archivo de manifiesto de suministro. Puesto que el

mandato mergemanifest ha fusionado las características nuevas o actualizadas en el manifiesto de

suministro, ProvisioningApplication procesará estos cambios, instalando o habilitando las características

nuevas o actualizadas para cada espacio de trabajo.

Aunque este escenario utiliza la función de búsqueda de actualizaciones, el mismo proceso básico puede

repetirse distribuyendo la característica CompanyApplications utilizando otros procedimientos, por

ejemplo, mediante el servidor Device Manager o mediante el servidor de Portal.

La característica de creación de marca de la plataforma de IBM Lotus Expeditor contiene un mandato

mergemanifest para su manejador de instalación, que hace referencia a un user.xml incluido en la

característica de creación de marca. Si la característica de creación de marca de IBM Lotus Expeditor se

instala desde un sitio de actualizaciones, fusionará el contenido del user.xml con el manifiesto de

suministro en la plataforma.

La característica de creación de marca de la plataforma IBM Lotus Expeditor contiene un mandato

mergemanifest para su manejador de instalación, que hace referencia a un archivo install.xml incluido en

la característica de creación de marca. Si la característica de creación de marca de IBM Lotus Expeditor se

instala desde un sitio de actualizaciones, fusionará el contenido del archivo install.xml con el manifiesto

de suministro en la plataforma.

Puesto que IBM Lotus Expeditor proporciona actualizaciones de plataforma futuras mediante la

actualización de la característica de creación de marca en la plataforma, otras actualizaciones se instalarán

automáticamente utilizando el manifiesto de suministro.

Desinstalación de características en la plataforma

Cuando se instalan en la plataforma versiones nuevas de características existentes, las versiones anteriores

se inhabilitan inmediatamente.


En función del valor de preferencia para com.ibm.rcp.provisioning.feature.history.size, es posible

que las versiones anteriores también se eliminen físicamente del sistema.

Las características que se han instalado en un espacio de trabajo no se pueden desinstalar desde un

espacio de trabajo distinto. Por ejemplo, cuando lanza inicialmente IBM Lotus Expeditor utilizando el

espacio de trabajo predeterminado, se instala y proporciona un conjunto de características. Si

posteriormente realiza el lanzamiento con un espacio de trabajo distinto utilizando la opción rcpData, las

características que se instalaron en el espacio de trabajo predeterminado no se pueden desinstalar desde

el nuevo espacio de trabajo. Si intenta desinstalar estas características, no se desinstalarán y se grabarán

errores en el registro de errores.

Contribución a la lista de acciones diferidas

El sistema de suministro mantiene un conjunto de peticiones cuyo proceso se difiere hasta que se reinicia

la plataforma.

La desinstalación física de las características se difiere hasta que se reinicia la plataforma. Sólo se pueden

añadir acciones a la lista como resultado indirecto de la petición de desinstalación de una característica.

Las acciones diferidas se procesan mediante el punto de extensión org.eclipse.ui.startup. Por

consiguiente, las acciones diferidas sólo se ejecutarán cuando el entorno de trabajo esté disponible, lo que

sucede después de que se haya producido la autenticación de usuario. La aplicación de suministro

procesará sincronizadamente las acciones diferidas antes de empezar las operaciones solicitadas.

Despliegue de aplicaciones mediante Web Start

Este apartado describe cómo exportar y desplegar una aplicación RCP de Client Services mediante el

mecanismo Web Start de Java.

El mecanismo Web Start de Java soporta el despliegue de aplicaciones Java desde un servidor Web a un

cliente. Las herramientas Web Start de Client Services soportan el empaquetado de aplicaciones RCP para

el despliegue subsiguiente mediante el mecanismo Web Start. Estas aplicaciones se ejecutan en un entorno

de ejecución de IBM Lotus Expeditor instalado en el cliente. Cada aplicación se lanza como una

aplicación RCP autónoma que se ejecuta en su propia VM. La aplicación no se instala en la plataforma de

IBM Lotus Expeditor. En lugar de ello, puede hacer referencia a las características requeridas de la

plataforma IBM Lotus Expeditor que necesita. Cuando la aplicación finaliza, se puede almacenar en

memoria caché en el cliente para futuras invocaciones o se puede eliminar si la memoria caché está llena.

En este sentido, la aplicación es transitoria, como las aplicaciones Java que se ejecutan mediante Web

Start.

Se puede encontrar información adicional sobre Web Start de Java en la documentación proporcionada

con Java J2SE 1.5.

Aplicaciones y entornos soportados

Todos los tipos de aplicación que se pueden ejecutar en Lotus Expeditor Client también se pueden

desplegar y ejecutar mediante Web Start. Lo único que se necesita es que la aplicación esté empaquetada

en una o varias características y que se cree para ella una configuración de producto.

Web Start de Java necesita soporte J2SE en el cliente. Por este motivo, sólo se soporta como entorno de

ejecución Java el JRE J2SE 1.5 que se entrega mediante DRE. Los JRE jclDesktop y jclDevice no se

soportan.

Las plataformas de sistema operativo soportadas incluyen:

v Microsoft Windows XP Professional Service Pack 1 y 2

v Microsoft Windows XP Home Edition Service Pack 1 y 2


v Microsoft Windows Vista

v Red Hat EL 4.0 WS con soporte GTK – Actualización 4

v Red Hat EL 5.0 WS con soporte GTK

v SUSE Linux Enterprise Desktop 10

J2SE 1.5 se debe instalar en el cliente. Para obtener más información, consulte “Instalación de soporte

Web Start en el cliente” en la página 193.

Diferencias respecto al soporte de Web Start de Eclipse

Este apartado describe las diferencias entre el soporte de Web Start de Client Services y el soporte Web

Start de Eclipse.

Las herramientas de Web Start de Client Services difieren de las herramientas de Eclipse en las áreas

siguientes:

v Las herramientas de Web Start de Eclipse se empaquetan en una aplicación RCP con todas las

características a las que la aplicación hace referencia. En esencia, esto proporciona una aplicación

autónoma. Las herramientas de Client Services suponen que existe un entorno de ejecución de IBM

Lotus Expeditor instalado en la máquina cliente. Esto permite que el paquete de la aplicación RCP sólo

contenga las características exclusivas de aplicación. Las ventajas de esto son dobles:

– La aplicación que se debe descargar del servidor es potencialmente mucho más pequeña, lo que

hace que la descarga sea más rápida.

– El entorno de ejecución de IBM Lotus Expeditor se puede actualizar de forma independiente

respecto a la aplicación, evitando la necesidad de volver a crear y volver a desplegar todas las

aplicaciones para aprovechar las actualizaciones de características de IBM Lotus Expeditor.v Las herramientas de IBM Lotus Expeditor conocen el entorno de ejecución de IBM Lotus Expeditor y

pueden configurar correctamente el entorno de lanzamiento de IBM Lotus Expeditor de la aplicación.

v Sólo se necesita firmar el jar de lanzamiento común que se proporciona con el soporte de Web Start de

Client Services. Esto lo puede realizar una vez el administrador puesto que este jar es común a todas

las aplicaciones Web Start de Client Services.

Soporte multiusuario

Una aplicación desplegada por Web Start hace referencia a las características compartidas de una

instalación multiusuario.

Web Start no hace referencia a la configuración de IBM Lotus Expeditor de un usuario determinado.

Estructura de una aplicación Web Start de Client Services

Desplegadores de Expeditor: Estructura de una aplicación Web Start de Client Services

La aplicación RCP JNLP contiene los recursos siguientes:

Componente de lanzamiento común

Contiene la lógica común necesaria para configurar y lanzar la aplicación RCP. Está contenido en

el archivo jar com.ibm.rcp.jnlp.launch_1.0.0.jar.

Descriptor JNLP de nivel superior

Especifica el componente de lanzamiento común y la extensión de aplicación.

Descriptor JNLP de extensión de aplicación

Especifica el jar de aplicación.

Jar de aplicación

Contiene la propia aplicación RCP en forma de directorio de instalación de Eclipse.


La división de la descripción JNLP en un jnlp de nivel superior y un jnlp de extensión permite especificar

seguridad de acceso completa a nivel superior para el componente de lanzamiento común, sin necesidad

de que los recursos a los que se hace referencia en la extensión de aplicación estén firmados. Sólo es

necesario firmar el componente de lanzamiento común com.ibm.rcp.jnlp.launch_1.0.0.jar y todas las

aplicaciones RCP pueden compartir una sola instancia.

Desarrollo de una aplicación Web Start

Este apartado describe los conceptos básicos implicados en el desarrollo de una aplicación Web Start.

Todos los tipos de aplicación Client Services se pueden desplegar mediante Web Start. La propia

aplicación es una aplicación Client Services y, como tal, se desarrolla utilizando las herramientas

existentes disponibles en IBM Lotus Expeditor Toolkit. Se puede probar utilizando el soporte de servidor

de Client Services o de lanzamiento de Client Services.

El asistente de exportación de Web Start de Client Services ensambla los metadatos necesarios y

empaqueta la aplicación en un formato adecuado para el despliegue de Web Start. Consulte “Exportación

de la aplicación Web Start” para obtener más información sobre este proceso.

Exportación de la aplicación Web Start

Este apartado describe cómo exportar la aplicación Web Start.

Se deben satisfacer los siguientes prerrequisitos antes de poder exportar una aplicación para Web Start:

v La aplicación se debe estructurar como una o varias características.

v Se debe crear una configuración de producto que defina las características que forman la aplicación

junto con los detalles de lanzamiento de aplicación.

La creación y la edición de una configuración de producto siguen los mismos pasos que se utilizan al

exportar una imagen de ejecución de cliente. Consulte “Creación de una configuración del Desarrollador

de plataformas” en la página 155 para obtener más información.

Cuando se han creado una o más características para la aplicación y se ha creado una configuración de

producto, la aplicación se puede exportar utilizando los pasos siguientes:

1. Seleccione Archivos → Exportar.

2. En la carpeta Client Services, seleccione Web Start de Client Services y pulse Siguiente.

3. Seleccione la configuración de producto para la aplicación.

4. Especifique el directorio de destino para la exportación y, opcionalmente, cambie el nombre jar de

aplicación.

5. Opcionalmente, proporcione una especificación de versión para la ejecución de destino. Un espacio en

blanco (valor predeterminado) indica cualquier versión.

6. Indica si se debe exportar el componente de lanzamiento común. Este componente es necesario para

ejecutar la aplicación mediante Web Start, pero se puede desplegar una instancia individual de ésta en

el servidor Web y varias aplicaciones pueden compartir dicha instancia.

7. Opcionalmente, puede hacer que el asistente de exportación firme el componente de lanzamiento

común. El componente de lanzamiento común se debe firmar, pero puede optar por firmarlo después

de que se exporte utilizando un programa de utilidad como Java jarsigner.

8. Puede seleccionar Finalizar para exportar la aplicación utilizando las opciones JNLP predeterminadas

o seleccionar Siguiente para arrancar la página de opciones JNLP, seguida de la página Propiedades.

Los valores de URL JNLP predeterminados utilizados por el asistente de exportación harán referencia a la

aplicación como exportada al directorio de destino. Si utiliza estos valores predeterminados, puede

ejecutar la aplicación directamente desde dicho directorio navegando al archivo jnlp principal del

directorio. En Windows, también puede efectuar una doble pulsación en el archivo jnlp para ejecutar la


aplicación. Para que esto funcione, debe tener Web Start instalado correctamente en la máquina de

desarrollo. Consulte “Instalación de soporte Web Start en el cliente”.

Consulte “Estructura de una aplicación Web Start de Client Services” en la página 191 para obtener

información adicional sobre los recursos que se exportan al directorio de destino. Consulte “Despliegue

de la aplicación en el servidor” en la página 195 para obtener información sobre cómo desplegar estos

recursos en un servidor web.

Opciones JNLP

La tabla siguiente lista las opciones de JNLP que se pueden especificar durante la exportación. Un valor

predeterminado de <espacio en blanco> también implica que la opción no se graba en el archivo JNLP.

Tabla 27. Opciones JNLP

Opción JNLP Descripción Valor predeterminado

Base de código de la aplicación URL de ubicación que contiene el jar

de aplicación

Destino de exportación

URL de componente de lanzamiento

común

URL de la ubicación de componente

de lanzamiento común

Ubicación del componente de

lanzamiento común del directorio de

destino de exportación

Título Título de aplicación Nombre de configuración de

producto

Proveedor Proveedor de aplicación <espacio en blanco>

Descripción Descripción de aplicación <espacio en blanco>

Fuera de línea permitido Si es verdadero, se permite que Web

Start ejecute una versión almacenada

en memoria caché de la aplicación si

el cliente no está conectado a la red

true (verdadero)

Página de inicio URL a la página de inicio que

contiene información de aplicación

<espacio en blanco>

Icono URL a un icono de aplicación <espacio en blanco>

Propiedades

La página Propiedades del asistente de exportación de Web Start le permite especificar propiedades de

pareja de nombre y valor para pasarlas a la aplicación. Estas propiedades se pasan como propiedades de

sistema Java y la aplicación puede acceder a ellas mediante las API Java System.getProperty y

System.getProperties.

Instalación de soporte Web Start en el cliente

Este apartado describe cómo instalar soporte Web Start en el cliente.

La instalación de soporte Web Start para aplicaciones Client Services en el cliente consta de los tres pasos

siguientes:

1. Configure Lotus Expeditor Client para el soporte Web Start.

2. Configure el navegador para el soporte Web Start.

3. Configure el cliente para el soporte Web Start.

Nota: Es importante aplicar estos pasos siempre que se actualice o vuelva a instalar Lotus Expeditor

Client.


Configuración de Lotus Expeditor Client

Si desea configurar correctamente Lotus Expeditor Client para el soporte Web Start, realice los pasos

siguientes:

1. Instale Lotus Expeditor Client.

2. Instale el soporte de J2SE 1.5 para Expeditor mediante DRE. Se necesita J2SE 1.5 para ejecutar

aplicaciones mediante Web Start.

3. Copie rcpbootcp.jar en el directorio lib/ext de J2SE 1.5.

a. El archivo rcpbootcp.jar se puede encontrar en el plug-in com.ibm.rcp.base en:

<Instalación_Expeditor>/rcp/eclipse/plugins/com.ibm.rcp.base_6.1.2.0

b. Copie rcpbootcp.jar en el directorio siguiente:

En Windows:

<dir_instalación_Expeditor>/rcp/eclipse/plugins/com.ibm.rcp.j2se.win32.x86_1.5.0.<versión>/jre/lib/ext

En Linux:

<dir_instalación_Expeditor>/rcp/eclipse/plugins/com.ibm.rcp.j2se.linux.x86_1.5.0.<versión>/jre/lib/ext

Configuración adicional para plataformas Linux

Dependiendo de las posibilidades de IBM Lotus Expeditor que necesiten sus aplicaciones Web Start, es

posible que necesite actualizaciones adicionales del entorno en Linux:

v Para dar soporte al Navegador gestionado de Expeditor, establezca MOZILLA_FIVE_HOME en el

directorio de navegador Mozilla adecuado en /usr/lib. Consulte “Prerrequisitos del cliente” en la

página 9 para obtener información sobre cómo localizar este directorio en el sistema. Por ejemplo:

export MOZILLA_FIVE_HOME=/usr/lib/firefox-1.5.0.3

v Si las aplicaciones van a utilizar DB2e, añada la ubicación siguiente a la variable de entorno

LD_LIBRARY_PATH:

<Expeditor>/rcp/eclipse/plugins/com.ibm.db2e.linux.x86_<versión>/os/linux/x86

v Si las aplicaciones van a utilizar ISync, añada la ubicación siguiente a la variable de entorno

LD_LIBRARY_PATH:

<Expeditor>/rcp/eclipse/plugins/com.ibm.mobileservices.isync.linux.x86_<versión>/os/linux/x86

En las vías de acceso anteriores, <Expeditor> es la ubicación de la instalación del ejecutable Expeditor y

<versión> es la versión del plug-in.

Configuración del navegador

Para configurar el navegador, debe instalar Java 1.5 JRE en el cliente utilizando el programa de

instalación Java. El programa de instalación del JRE contiene la lógica para actualizar el sistema y asociar

Java y Web Start con los navegadores.

Una vez se ha instalado Java 1.5, configure Web Start para proporcionar referencias a las plataformas

Expeditor de J2SE 1.5, de la manera siguiente:

1. Abra el panel de control de Java. En Windows, puede encontrarlo en el Panel de control de

Windows. En Linux, ejecute la aplicación ControlPanel, que se encuentra en jre/bin del directorio

inicial de Java.

2. En la pestaña Java, pulse Ver para los valores de ejecución de aplicaciones Java.

Aparece la pantalla de valores de ejecución JNLP.

3. En la pestaña Usuario, pulse el botón Buscar y vaya al J2SE 1.5 JRE de Expeditor. Estará en la

ubicación siguiente:


En Windows:

/rcp/eclipse/plugins/com.ibm.rcp.j2se.win32.x86_1.5.0.<versión>

En Linux:

/rcp/eclipse/plugins/com.ibm.rcp.j2se.linux.x86_1.5.0.<versión>4. Siga pulsando Siguiente hasta que finalice.

5. Quite la marca de todos los J2SE 1.5 JREs listados en la página de valores de ejecución de JNLP a

excepción del J2SE de la plataforma de Expeditor.

6. Pulse Aceptar.

Configuración del cliente

Para configurar el soporte Web Start de Client Services, cree un archivo de configuración que especifique

dónde está ubicada la plataforma IBM Lotus Expeditor en el cliente. Este archivo de configuración

permite que se soporten en una máquina cliente varias plataformas basadas en IBM Lotus Expeditor. La

configuración es un archivo xml con el elemento raíz <webstart> y uno o varios elementos <platform>.

Cada elemento <platform> especifica la ubicación y la versión opcional de una plataforma IBM Lotus

Expeditor en el cliente. A continuación se muestra un ejemplo de una configuración simple que especifica

una sola plataforma IBM Lotus Expeditor:

<webstart>

<platform

type="expeditor"

version="6.1.1"

location="C:/IBM/Lotus/Expeditor"/>

</webstart>

Establezca la variable de entorno RCP_JNLP_LAUNCH_CONFIG en la ubicación de este archivo de

configuración.

Despliegue de la aplicación en el servidor

Este apartado describe los pasos que deben realizarse para el despliegue de una aplicación Web Start de

Client Services en el servidor Web.

Realice los pasos siguientes para desplegar una aplicación Web Start de Client Services en un servidor

web:

1. Asegúrese de que el servidor Web correlacione los archivos .jnlp con el tipo mime

application/x-java-jnlp-file

2. Firme el jar de lanzamiento común com.ibm.rcp.jnlp.launch_1.0.0.jar

3. Añada el jar de lanzamiento común como un recurso en el servidor Web. Esto puede ser en una

ubicación común a la que todas las aplicaciones hacen referencia o se puede copiar en el directorio de

base de código de cada aplicación. Esta decisión afecta al contenido del archivo JNLP de la aplicación.

En particular, el recurso debe tener el atributo href establecido correctamente en la ubicación del

componente de lanzamiento común.

4. Instale el archivo jar de aplicación y los archivos JNLP producidos por la exportación de Web Start en

el servidor Web bajo la base de código especificada en los archivos JNLP (o actualice el atributo de

base de código del archivo JNLP para que corresponda al lugar donde los está poniendo).

Ejecución de una aplicación mediante Web Start

Este apartado describe cómo ejecutar una aplicación mediante Web Start.

Para ejecutar una aplicación mediante Web Start, utilice el navegador habilitado para Web Start para

navegar al archivo jnlp de la aplicación que se debe ejecutar.


Consideraciones acerca de la internacionalización

Consideraciones acerca de la utilización de caracteres que no forman parte del juego de caracteres ASCII.

v Una aplicación Web Start puede desplegarse localmente en el sistema de archivos de una máquina

cliente, en lugar de en un servidor web. Una vez desplegada, la base de código de la aplicación sólo

debe contener caracteres ASCII o caracteres que formen parte del idioma actual de la máquina cliente.

v El asistente de exportación de Web Start de Client Services no puede exportar a una ubicación de

archivos que contenga caracteres que no sean ASCII o que no formen parte del idioma actual de la

máquina de desarrollo.

v El asistente de exportación de Web Start de Client Services sustituirá automáticamente los caracteres

que no sean ASCII en un URL de http: por su representación de codificación URL %xx correspondiente.

Esto se aplica a la base de código y los campos URL de componente de inicio común.


Gestión del entorno de ejecución de cliente

Los apartados siguientes proporcionan información de tareas generales necesaria para gestionar los

entornos de ejecución de cliente. Utilice las tareas especificadas en estos apartados como patrones

generales para gestionar los entornos de ejecución de cliente.

Necesitará consultar “Configuración de la plataforma” en la página 47 y “Ampliación de la plataforma”

en la página 127 para obtener los detalles que se deben proporcionar al completar cada tarea.


Esta sección describe cómo utilizar un servidor Device Manager para instalar aplicaciones y gestionar

entornos de ejecución.

El agente de gestión de empresa le permite conectarse a un Lotus Expeditor Server. Lotus Expeditor

Server contiene el componente servidor Device Manager que permite gestionar la plataforma básica del

cliente, junto con características adicionales, por ejemplo servidores ISync y MQe.

Descripción de la gestión con el servidor Device Manager

El servidor Device Manager proporciona posibilidades para gestionar dispositivos incluyendo funciones

de consulta y actualización.

El Agente de gestión de empresa que se proporciona como parte de la plataforma de cliente se considera

un dispositivo en el servidor Device Manager. Varias instalaciones en el mismo sistema darán un aspecto

de varios dispositivos, cada uno de ellos con información de inicio de sesión de cuenta individual e

información de definición de dispositivo.

Para hacer uso del Agente de gestión de empresa y el servidor Device Manager, siga estos pasos

generales:

1. Configure el Agente de gestión de empresa en el dispositivo.

v Esta tarea consiste en definir la dirección del servidor y la información de conexión, así como

parámetros de sondeo.

v Cuando el agente se pone en contacto por primera vez con el servidor, el dispositivo se inscribe o

se registra en el servidor.

El agente sondeará periódicamente el servidor Device Manager para recibir los trabajos que sea

necesario procesar para el cliente.

2. Defina trabajos en el servidor para someterlos a uno o más clientes.

v Los trabajos son tareas que es necesario realizar en el cliente.

v Los trabajos se pueden asignar a uno o más clientes, incluidos los clientes definidos así como los

clientes que se inscriben.

Consulte el tema Información sobre Device Manager 2.1 en el centro de información de Lotus Expeditor.

Configuración del Agente de gestión de empresa

El Agente de gestión de empresa se proporciona con Lotus Expeditor Client y le permite gestionar la

plataforma de manera remota utilizando un servidor Device Manager.

El Agente de gestión de empresa utiliza una cuenta de muestra para conectarse al servidor. Existen cuatro

procedimientos para crear la cuenta de ejemplo:


http://publib.boulder.ibm.com/infocenter/ledoc/v6r11/index.jsp?topic=/com.ibm.websphere.dms.doc/dm/welcome.html

v En el momento de la instalación. Para obtener instrucciones sobre cómo configurar el Agente de

gestión de empresa durante la instalación, consulte “Instalación desde un CD” en la página 11.

v Una vez finalizada la instalación. La cuenta se crea mediante el Servlet de Agente de gestión de

empresa, como se describe en la sección “Utilización del servlet de Agente de gestión de empresa” en

la página 203. Para poder utilizar el Servlet de Agente de gestión de empresa es preciso instalar una

característica adicional.

v Una vez finalizada la instalación. Mediante la utilización de la página Preferencias del agente de

gestión de empresa en el entorno de trabajo de Lotus Expeditor Client. Consulte “Configuración del

agente utilizando la página Preferencias del Agente de gestión de empresa de escritorio”.

v Una vez finalizada la instalación. Utilizando el archivo de propiedades de agente OSGi para añadir o

modificar la información de cuenta y sondeo.

Configuración del agente utilizando la página Preferencias del Agente de gestión

de empresa de escritorio

En este apartado se describe cómo configurar el agente utilizando la página de preferencias del Agente de

gestión de empresa. Puede acceder a la página Preferencias del Agente de gestión de empresa utilizando

el diálogo Archivo → Preferencias → Agente de gestión de empresa. En la página Preferencias de Agente

de gestión de empresa aparecen los parámetros siguientes:

Tabla 28. Parámetros del Agente de gestión de empresa

Parámetro Descripción

Habilitar sondeo en intervalo para el

Agente de gestión de empresa

Habilita la gestión de este cliente a través del Agente de gestión de

empresa. Una vez habilitada, no tendrá control sobre la instalación,

actualización ni desinstalación de características. Una vez habilitado, el

Agente de gestión de empresa no puede inhabilitarse fácilmente.

Nombre del usuario del dispositivo Identidad que utiliza la máquina de un usuario para conectarse a un

servidor Device Manager.

Contraseña del usuario del dispositivo Contraseña que utiliza la máquina de un usuario para conectarse a un


Contraseña del servidor Es opcional y depende del modo en que el servidor Device Manager realiza

la autenticación. La contraseña sólo es necesaria si el servidor la necesita.

HTTP/HTTPS Seleccione el tipo de conexión con el servidor.

Dirección del servidor La dirección del servidor consta de dos partes – un URI y la vía de acceso

al servlet de DM con el que se debe establecer contacto para la inscripción.

Utilice uno de valores siguientes para especificar la dirección del servidor

de gestión de dispositivos:

v Dirección IP

v Nombre del host

v Nombre de host y nombre de dominio

SyncML/DM es el protocolo de sincronización de datos que el agente y el

servidor utilizan para comunicarse entre sí. Cuando el servidor se ha

configurado para que requiera la autorización mediante SyncML/DM,

añada el valor siguiente a la dirección del servidor:

dmserver/OMADMServletAuthRequired

Si el servidor no requiere la autorización de SyncML/DM, añada el valor

siguiente a la dirección del servidor:

dmserver/OMADMServlet


Tabla 28. Parámetros del Agente de gestión de empresa (continuación)


Intervalo de sondeo Muestra el intervalo de sondeo en horas y minutos. El valor

predeterminado es de 4 horas. Cuando el intervalo se establece en 00:00, el

sondeo queda inhabilitado, independientemente del valor especificado en el

campo Habilitar el sondeo al iniciar. Es equivalente a inhabilitar el sondeo.

Esto no puede configurarse a través del panel de preferencias del Agente de

gestión de empresa. Sólo se puede configurar a través del Servlet de Agente

de gestión de empresa o del trabajo de mandato personalizado del servidor

Device Manager.

Hora de inicio del sondeo Muestra la hora de inicio del sondeo en horas y minutos. El valor

predeterminado es 2:00 am. Si la hora de inicio del sondeo coincide con la

hora de finalización del mismo, el agente continúa realizando el sondeo en

cada intervalo de sondeo. El agente no realizará el sondeo si la hora actual

se encuentra fuera de las horas de inicio y finalización del sondeo. Esto no

se puede configurar a través del panel de preferencias del Agente de

gestión de empresa. Sólo se puede configurar a través del Servlet de Agente

de gestión de empresa o del trabajo de mandato personalizado del servidor

Device Manager.

Hora de finalización del sondeo Muestra la hora de finalización del sondeo en horas y minutos. El valor

predeterminado es 2:00 am. Si la hora de inicio del sondeo coincide con la

hora de finalización del mismo, el agente continúa realizando el sondeo en

cada intervalo de sondeo. El agente no realizará el sondeo si la hora actual

se encuentra fuera de las horas de inicio y finalización del sondeo. Esto no

puede configurarse a través del panel de preferencias del Agente de gestión

de empresa. Sólo se puede configurar a través del Servlet de Agente de

gestión de empresa o del trabajo de mandato personalizado del servidor

Device Manager.

Habilitar el sondeo al iniciar Muestra si el sondeo está o no habilitado en el inicio. De forma

predeterminada está habilitado. Esto no puede configurarse a través del

panel de preferencias del Agente de gestión de empresa. Sólo se puede

configurar a través del Servlet de Agente de gestión de empresa o del

trabajo de mandato personalizado del servidor Device Manager.

Probar la conexión Seleccione este botón para probar que el Agente de gestión de empresa

puede conectarse al servidor Device Manager utilizando los parámetros

especificados en esta página.

Nota: El panel de preferencias de Lotus Expeditor Client no permite crear varias cuentas. El servidor

Device Manager proporciona funciones para permitir a un usuario cambiar el ID de cuenta

predeterminado utilizando un mandato personalizado.

Puede ver información de configuración de agente, incluido el ID de dispositivo, seleccionando Ayuda →

Acerca de Lotus Expeditor → Detalles de configuración.

Una vez que se ha configurado el Agente de gestión de empresa, se inhabilitan los diálogos Aplicación →

Instalar y gestionar aplicación → Gestión de aplicaciones.

Configuración del agente utilizando la página Preferencias del Agente de gestión

de empresa del dispositivo

En este apartado se describe cómo configurar el agente utilizando la página de preferencias del Agente de

gestión de empresa en dispositivos. Puede acceder a la página Preferencias de agente de gestión de

empresa lanzando el gestor de aplicaciones y seleccionando Mandato → Preferencias. En la página

Preferencias de Agente de gestión de empresa aparecen los parámetros siguientes:

Gestión del entorno de ejecución de cliente 199

Tabla 29. Parámetros del Agente de gestión de empresa


ID de usuario Identidad que utiliza la máquina de un usuario para conectarse a un


Contraseña del usuario Contraseña que utiliza la máquina de un usuario para conectarse a un


HTTP/HTTPS Seleccione el tipo de conexión con el servidor.

Dirección del servidor La dirección del servidor consta de dos partes – un URI y la vía de acceso

al servlet de DM con el que se debe establecer contacto para la inscripción.

Utilice uno de valores siguientes para especificar la dirección del servidor

de gestión de dispositivos:

v Dirección IP

v Nombre del host


SyncML/DM es el protocolo de sincronización de datos que el agente y el

servidor utilizan para comunicarse entre sí. Cuando el servidor se ha

configurado para que requiera la autorización mediante SyncML/DM,

añada el valor siguiente a la dirección del servidor:


Si el servidor no requiere la autorización de SyncML/DM, añada el valor

siguiente a la dirección del servidor:


Nota: Lotus Expeditor Client para dispositivos sólo soporta una cuenta. Los cambios efectuados en la

página de preferencias o desde el servidor de gestión de dispositivos en la información de cuentas

se aplican a esta cuenta en concreto.

Configuración utilizando el archivo de propiedades de agente OSGi

El Agente OSGi se puede configurar utilizando un archivo de propiedades. A continuación se

proporcionan las claves soportadas y los valores predeterminados que el agente utiliza en el arranque.

Una vez que se ha leído el archivo, el agente lo eliminará. Bajo determinadas circunstancias, el archivo de

propiedades no se suprime. Si no se está iniciando el agente por primera vez, el archivo de propiedades

sólo se leerá si las propiedades se especifican para una cuenta nueva. Si no se especifica ningún nombre

de cuenta en el archivo de propiedades, el archivo no se lee ni se suprime. Para forzar que el agente lea

este archivo de propiedades otra vez, se debe suprimir OSGiAgentTree.bin y el archivo de copia de

seguridad del mismo.

Antes de que el agente se inicie por primera vez, puede crear una cuenta predeterminada. Cuando se

inicia el agente por primera vez, éste busca el archivo de propiedades de cuenta predeterminado,

denominado osgiagent.properties, en el directorio especificado con un parámetro de línea de mandatos -D

en la invocación de la VM (Virtual Machine - Máquina virtual) que implementa especificaciones Java. Por

ejemplo, si el archivo de propiedades de cuenta está en el directorio c:\propertyfile, deberá utilizar el

siguiente parámetro -D en la invocación de VM:

-Dcom.ibm.osg.service.osgiagent.PropertiesFileLoc=c:\propertyfile

Si no se utiliza el parámetro -D, se busca en la vía de acceso de clase Java el archivo osgiagent.properties

y se utiliza dicho archivo de propiedades. Si no se localiza ningún archivo de propiedades en la vía de

acceso de clase Java, se busca en el directorio actual.


Cuando se encuentra un archivo de propiedades, el agente lee los parámetros para crear la cuenta inicial.

Cuando el agente OSGi se inicia por primera vez, si no existe ninguna cuenta inicial, se crea

automáticamente una cuenta inicial denominada SampleAccount.

Utilice las siguientes descripciones de parámetro y el formato de archivo de ejemplo como guía si crea un

archivo osgiagent.properties para crear una cuenta inicial. El campo del Panel de control de agente

correspondiente está entre paréntesis.

AccountID (ID de cuenta de SyncML DM)

ID de cuenta de SyncML DM, que normalmente es el mismo que el ID de servidor. Si no se

especifica ningún nombre de cuenta, la primera vez se crea SampleAccount. Sin embargo, si

SampleAccount ya se ha creado, el archivo de propiedades no se leerá si no se especifica

AccountID.

KeyRing (nombre de archivo de claves)

Nombre del archivo de claves.

El archivo de claves se debe poner en la vía de acceso de clase del dispositivo Windows de 32

bits para que el agente de dispositivo se comunique con el servidor mediante conexiones SSL.

Utilice una vía de acceso totalmente calificada, incluyendo el nombre de archivo. Si no se

especifica la vía de acceso, se utiliza el directorio de trabajo actual.

Un archivo de claves almacena las claves públicas de los compañeros de trabajo y asociados en

un solo lugar para acceder a ellas y recuperarlas de forma fácil.

UserName (Nombre del usuario del dispositivo)

Nombre del usuario del dispositivo.

Este nombre se utiliza al implementar la autorización de SyncML/DM o la autenticación básica

de HTTP.

ClientPW (Contraseña del usuario del dispositivo)

Contraseña del usuario. El texto de la contraseña se muestra sin cifrar.

La contraseña se utiliza al implementar la autorización de SyncML/DM.

KeyRingPassword (Contraseña de archivo de claves)

Contraseña para el archivo de claves. La contraseña se visualiza sin cifrar.

ServerPW (Contraseña del servidor)

Contraseña del servidor.


Nota: La seguridad debe estar habilitada en WebSphere Application Server.

Addr (Dirección del servidor)

Utilice el nombre de host o la dirección IP para el servidor Device Manager, por ejemplo:

http://dirección_servidor/dmserver/OMADMServletAuthRequired

Cuando se necesite autorización, utilice el valor siguiente:


Si no se implementa la autorización de SyncML/DM, utilice el valor siguiente:

OMADMServlet

PollingEnabled (Sondeo habilitado)

Determina si se habilita el sondeo. Los valores son true o false (no se tienen en cuenta las

mayúsculas y minúsculas).

El recuadro de selección de Sondeo habilitado se visualiza en la ventana Información del

dispositivo.


PollingInterval (intervalo de sondeo)

Especifica el intervalo de sondeo en horas y minutos. El valor se especifica como HH:MM.

Este campo se visualiza en la ventana Información del dispositivo.

PollingStart (hora de inicio del sondeo)

Especifica la hora de inicio del sondeo en horas y minutos. El valor se especifica como HH:MM.


PollingEnd (hora de finalización del sondeo)

Especifica la hora de finalización del sondeo en horas y minutos. El valor se especifica como

HH:MM.


LogSize (tamaño de registro)

Especifica el tamaño de los archivos de mensajes. Este campo se visualiza en la ventana

Información del dispositivo.

LogThreshold (umbral de registro)

Especifica el tipo de error mínimo que se añade al archivo de mensaje. Las opciones y los valores

correspondientes son:

v * 1 para Error

v * 2 para Aviso

v * 3 para Información

v * 4 para Depuración


TempFileLoc (Ubicación de archivos temporales)

Identifica la vía de acceso de los archivos temporales. Este campo se visualiza en la ventana

Información del dispositivo.

Configuración utilizando el archivo de propiedades de agente OSGi en Lotus

Expeditor Client para dispositivos

El Agente OSGi se puede configurar utilizando un archivo de propiedades. A continuación se

proporcionan las claves soportadas y los valores predeterminados que el agente utiliza en el arranque.

Una vez que se ha leído el archivo, el agente lo eliminará. Bajo determinadas circunstancias, el archivo de

propiedades no se suprime. Si no se está iniciando el agente por primera vez, el archivo de propiedades

sólo se leerá si las propiedades se especifican para una cuenta nueva. Si no se especifica ningún nombre

de cuenta en el archivo de propiedades, el archivo no se lee ni se suprime. Para forzar que el agente lea

este archivo de propiedades otra vez, se debe suprimir OSGiAgentTree.bin y el archivo de copia de

seguridad del mismo.

Antes de que el agente se inicie por primera vez, puede crear una cuenta predeterminada. Cuando se

inicia el agente por primera vez, éste busca el archivo de propiedades de cuenta predeterminado,

denominado osgiagent.properties, en el directorio especificado con un parámetro de línea de mandatos -D

en la invocación de la VM (Virtual Machine - Máquina virtual) que implementa especificaciones Java. Por

ejemplo, si el archivo de propiedades de cuenta está en el directorio \propertyfile, deberá utilizar el

siguiente parámetro -D en la invocación de VM (JVM_ARG):

-Dcom.ibm.pvc.osgiagent.core.propertiesfileloc=\propertyfile

que se encuentra en el archivo \eclipse\configuration\config.ini.

Si no se utiliza el parámetro -D, se busca en la vía de acceso de clase Java el archivo osgiagent.properties

y se utiliza dicho archivo de propiedades. Si no se localiza ningún archivo de propiedades en la vía de

acceso de clase Java, se busca en el directorio actual.


Cuando se encuentra un archivo de propiedades, el agente lee los parámetros para crear la cuenta inicial.

Cuando el agente OSGi se inicia por primera vez, si no existe ninguna cuenta inicial, se crea

automáticamente una cuenta inicial denominada SampleAccount.

Utilice las siguientes descripciones de parámetro y el formato de archivo de ejemplo como guía si crea un

archivo osgiagent.properties para crear una cuenta inicial.

Utilice los campos siguientes para configurar las propiedades de agente de gestión de empresa en el

primer lanzamiento de Lotus Expeditor Client para dispositivos:

Nota: La Tabla 30 lista los parámetros soportados. Si se utilizan parámetros no soportados, es posible que

reciba excepciones cuando el cliente lea osgiagent.properties.

Tabla 30. Propiedades configurables de Lotus Expeditor Client para dispositivos

Parámetro Descripción Información adicional

Addr Nombre de host del servidor Device

Manager

http://myserver.com/dmserver/OMADMServletAuthRequired

AccountID Cuenta de ejemplo (SampleAccount) Se debe utilizar SampleAccount o no se deberá incluir

esta propiedad en el archivo. Se utilizará SampleAccount

de forma predeterminada si no se incluye en el archivo.

UserName Nombre de usuario del dispositivo

ClientPW Contraseña del usuario

LogSize Especifica el tamaño de los archivos

de mensajes

LogThreshold Especifica el tipo de error mínimo

añadido al archivo de mensaje

v 1 para error

v 2 para advertencia

v 3 para información

v 4 para depuración

PollingEnabled Determina si se habilita el sondeo True o False

PollingInterval Especifica el intervalo de sondeo en

horas y minutos

Tiempo en formato HH:MM. Por ejemplo 00:05

Nota: Lotus Expeditor Client para dispositivos utiliza almacenamiento no cifrado para esta información.

Utilización del servlet de Agente de gestión de empresa

El servlet de Agente de gestión de empresa proporciona una interfaz de usuario para actualizar valores

del Agente de gestión de empresa así como para realizar tareas administrativas.

Nota: El servlet de Agente de gestión de empresa no está soportado en dispositivos Windows Mobile o

Nokia.Normalmente el usuario final no utiliza el servlet de Agente de gestión de empresa que se proporciona

como una herramienta para ayudar a los desplegadores a utilizar el agente y el servidor Device Manager.

Puede lanzarlo desde el entorno de trabajo de Lotus Expeditor Client o desde un navegador Web.

Instalación del servlet de Agente de gestión de empresa:

La característica de servlet de Agente de gestión de empresa se proporciona en el sitio de actualización de

plataforma principal, pero no se instala como parte de la plataforma predeterminada.

Si desea utilizar el servlet de Agente de gestión de empresa, debe instalarlo para poder utilizarlo.


Inicio del servlet de Agente de gestión de empresa:

Siga estos pasos para iniciar el servlet de Agente de gestión de empresa

Para iniciar el servlet de Agente de gestión de empresa desde el entorno de trabajo de Lotus Expeditor

Client, seleccione Iniciador > Servlet del Agente de gestión de empresa.

Modificación de la información del dispositivo:

Una vez que se haya iniciado el servlet, seleccione Información del dispositivo en Funciones de

administración en el panel de navegación de la izquierda para modificar la información de la cuenta

actual.

En la lista siguiente se proporciona una breve descripción de las opciones que pueden modificarse para la

cuenta:

Nombre de dispositivo

Nombre exclusivo del dispositivo. El nombre del dispositivo a menudo es un número de serie u

otra serie exclusiva. El nombre del dispositivo se muestra en la ventana Información del

dispositivo.

El Agente de gestión de empresa genera el ID del dispositivo automáticamente y no puede

modificarse. Se muestra aquí con fines meramente informativos.

Modelo

Modelo del dispositivo. El modelo del dispositivo se muestra en la ventana Información del

dispositivo. También se conoce como clase del dispositivo. A modo de ejemplo, el valor puede ser

Win32 o Linux_x86.

Cuenta predeterminada

Define la cuenta que el agente utiliza para comunicarse con el servidor Device Manager.

Ubicación del archivo temp

Identifica la vía de acceso para los archivos temporales que utiliza el Agente de gestión de

empresa durante la distribución de software.

Sondeo habilitado

Conmuta el sondeo automático del servidor por parte del Agente de gestión de empresa.

Intervalo de sondeo

Especifica el intervalo de sondeo en horas y minutos. Cuando el intervalo se establece en 00:00, el

sondeo queda inhabilitado, independientemente del valor del campo Sondeo habilitado. Es

equivalente a inhabilitar el sondeo.

Hora de inicio del sondeo

Especifica la hora de inicio del sondeo en horas y minutos. El agente no realizará el sondeo si la

hora actual se encuentra fuera de las horas de inicio y finalización del sondeo.

Hora de finalización del sondeo

Especifica la hora de finalización del sondeo en horas y minutos. El agente no realizará el sondeo

si la hora actual se encuentra fuera de las horas de inicio y finalización del sondeo.

Tamaño de registro

Especifica el número de entradas de mensaje que pueden registrarse en el agente antes de volver

a la entrada inicial. El registro del agente puede visualizarse desde el Servlet de Agente de

gestión de empresa seleccionando Registro de agente en Funciones de administración en el panel

de navegación de la izquierda.

Umbral de registro

Especifica el tipo de error mínimo que se añade al archivo de mensaje. Las opciones y los valores

correspondientes son:


v 1 para error

v 2 para advertencia

v 3 para información

v 4 para depuración

Modificación de la información de cuenta del Agente de gestión de empresa:

Una vez que haya iniciado el servlet, seleccione Editar configuración de cuenta en Funciones de

administración en el panel de navegación de la izquierda para modificar la información actual de la

cuenta.

En la lista siguiente se proporciona una breve descripción de las opciones que pueden modificarse para la

cuenta:

ID de cuenta SyncML/DM

Identificador de la cuenta de SyncML/DM, que a menudo coincide con el ID del servidor.

Nombre del usuario del dispositivo


Este nombre se utiliza al implementar la autorización de SyncML/DM o la autenticación básica

de HTTP.

Contraseña del usuario del dispositivo

Contraseña del usuario. El texto de la contraseña se muestra sin cifrar.


Contraseña del servidor


Tipo de dirección

Tipo de conexión con el servidor. Los valores posibles son HTTP o HTTPS.

Dirección del servidor

Utilice uno de los valores siguientes para especificar el Servidor de gestión de dispositivos:

v Dirección IP

v Nombre del host


Vía de acceso de servidor DM

SyncML/DM es el protocolo de sincronización de datos que el agente y el servidor utilizan para

comunicarse entre sí. Cuando el servidor se ha configurado para que requiera la autorización

mediante SyncML/DM, añada el valor siguiente a la dirección del servidor:


Si el servidor no requiere la autorización de SyncML/DM, añada el valor siguiente a la dirección

del servidor:

OMADMServlet

Modificación de la información de cuenta del Agente de gestión de empresa utilizando el archivo de

propiedades:

Device Manager soporta notificaciones en tiempo real de los agentes de dispositivo OSGi utilizando el

manejador de notificaciones HTTP POST de OSGi. El manejador de notificaciones HTTP POST de OSGi

hace el seguimiento de la dirección IP actual de cada agente de dispositivo OSGi.

Este manejador de notificaciones incluye los siguientes atributos de dirección de notificación:


v Dirección IP o nombre de sistema principal (opcional)

v Número de puerto (opcional); el puerto predeterminado es 8777

v Determina si el cliente utilizará o no la cuenta predeterminada; el valor predeterminado es utilizar el

ID de servidor

Si selecciona no utilizar la cuenta predeterminada, el ID de servidor y la contraseña de servidor asociados

con la entrada de dispositivo se codificará y se pasará al dispositivo como parte de la notificación.

Actualice automáticamente la dirección IP de notificación del dispositivo; valores válidos: Sí o No. El

valor predeterminado es sí.

Si el usuario decide no actualizar automáticamente la dirección IP de notificación del servicio (valor No),

se necesita la dirección IP (especificada más arriba) y se envía la notificación a dicha dirección IP.

De forma predeterminada, Device Manager rellena automáticamente la dirección IP de notificación para

los dispositivos OSGi recién inscritos. Además, si la dirección IP ha cambiado, la dirección se actualiza

automáticamente cada vez que el dispositivo se conecta al servidor Device Manager. Se supone que el

puerto de escucha de dispositivo (cliente) es el 8777 y éste no se actualiza. Debe gestionar el número de

puerto si se utiliza un puerto alternativo.

Para configurar un dispositivo Linux o un dispositivo Windows de 32 bits para que utilice el manejador

de notificaciones HTTP POST de OSGi, cree el archivo OSGiAgentServlet.properties utilizando un editor

de texto. Puede crearlo en cualquier directorio. Una ubicación sugerida es el mismo directorio que el

iniciador, que es:

<directorio_instalación> /rcp

El archivo OSGiAgentServlet.properties debe satisfacer todos los requisitos de un archivo de propiedades

Java. Utilice los parámetros y valores siguientes como guía:

v AllowAddress proporciona un modo para acceder de forma remota a la interfaz de usuario

proporcionada por OSGiAgentServlet. El parámetro AllowAddress no está limitado al manejador de

notificaciones. El parámetro AllowAddress sólo acepta una dirección IP.

v AllowExternalNotifications para permitir notificaciones externas, establezca el valor en yes.

v AllowDefaultAccountForNotifications para permitir la cuenta predeterminada para recibir

notificaciones, establezca el valor en yes.

Ejemplos:

v AllowAddress=9.42.30.48

v AllowExternalNotifications=yes

v AllowDefaultAccountForNotifications=yes

Conexión al servidor para comprobar trabajos:

En la ventana Panel de control del agente, puede conectarse al servidor Device Manager para ejecutar

trabajos que están en la cola de trabajos del dispositivo.

Para conectarse al servidor Device Manager, realice los pasos siguientes:

1. En la lista Funciones generales, pulse Obtener actualizaciones.

Aparece la ventana Conectar con servidor.

2. Si hay algún problema con la conexión, el icono de la bandeja del sistema parpadeará; al pulsar en el

icono, aparecerá un mensaje emergente en la parte inferior derecha de la pantalla con detalles sobre el

problema.

3. Si lo desea, puede pulsar Sucesos de agente en Funciones de administración en el panel de

navegación para obtener una lista de las acciones de servidor-dispositivo más recientes.


Para obtener información más detallada sobre los sucesos de servidor-dispositivo recientes, pulse

Registro de agente en la lista Función. La información es relativa a todas las cuentas y se muestra en

orden cronológico, no por cuenta. Para renovar el registro del agente, pulse el botón Renovar registro

de agente. .

Supervisión de los sucesos del Agente de gestión de empresa:

Para ver los sucesos recientes de agente-servidor, pulse Sucesos de agente en la lista Función.

Los sucesos más recientes se muestran en la parte superior de la lista. Los sucesos son de todas las

cuentas y se muestran en orden cronológico, no por cuenta. Para renovar la lista de sucesos, pules el

botón Renovar registro de sucesos.

Nota: asegúrese de que la ventana del navegador sea suficientemente ancha para mostrar la barra

vertical de desplazamiento para la lista de sucesos o ajuste la ventana Sucesos de agente con su

barra de desplazamiento horizontal.

Para obtener información más detallada sobre los sucesos de servidor-dispositivo recientes, pulse

Registro de agente en la lista Función. Los detalles de los sucesos más recientes se muestran en la parte

superior de la lista. La información es relativa a todas las cuentas y se muestra en orden cronológico, no

por cuenta. Para renovar el registro del agente, pulse el botón Renovar registro de agente.

Creación de un trabajo de distribución de software desde el cliente:

Desde el Servlet del Agente de gestión de empresa, el usuario del dispositivo puede iniciar una solicitud

para que el servidor Device Manager envíe una lista del software disponible al dispositivo.

Al recibir una solicitud del dispositivo, el servidor Device Manager recupera la lista y la envía al

dispositivo.

Una vez que el dispositivo ha recibido la lista, el usuario del dispositivo puede crear un trabajo de

distribución de software seleccionando un paquete de dicha lista que deba distribuirse al dispositivo.

Para crear un trabajo de distribución de software desde un dispositivo, siga estos pasos desde la ventana

Panel de control del Agente:

1. En la lista Funciones generales, pulse Software disponible.

Aparece la ventana Software disponible.

La lista de software disponible que se muestra corresponde a la cuenta actual.

2. seleccione un paquete de software de la lista de software disponible.

3. Pulse Instalar software seleccionado para instalar dicho software en el dispositivo.

Tras solicitar el software que debe instalarse, observe los sucesos del agente para supervisar su estado.

Consulte “Supervisión de los sucesos del Agente de gestión de empresa”.

4. (Opcional) Pulse Renovar software disponible para actualizar la lista de software.

Utilización de cuentas del Agente de gestión de empresa:

En esta sección se describe cómo seleccionar una cuenta, crear una cuenta, editar la configuración de una

cuenta y suprimir una cuenta mediante el Servlet de Agente de gestión de empresa.

Selección de una cuenta

La cuenta actual se muestra por encima de la lista Funciones generales.

Para cambiar la cuenta actual por otra cuenta, siga estos pasos:


1. En la lista Funciones de administración, pulse Seleccionar cuenta.

Se abre la ventana Seleccionar cuenta.

2. Pulse una de las cuentas que se muestran para establecerla como cuenta actual.

La nueva cuenta actual se muestra por encima de la lista Funciones generales.

Ahora puede seleccionar la función que debe ejecutarse para la cuenta actual desde la ventana Panel de

control del Agente de gestión de empresa.

Creación de otra cuenta

Desde la ventana Panel de control del agente, puede crear otra cuenta. Para cada cuenta, especifique

información para los parámetros de configuración de cuenta.

Parámetros de configuración de la cuenta:

ID de cuenta SyncML/DM

Identificador de la cuenta de SyncML/DM, que a menudo coincide con el ID del servidor.

Nombre del usuario del dispositivo


Este nombre se utiliza al implementar la autorización de SyncML/DM o la autenticación

básica de HTTP.

Contraseña del usuario del dispositivo

Contraseña del usuario del dispositivo. El texto de la contraseña se muestra sin cifrar.


Contraseña del servidor

Contraseña del servidor; es opcional.

La contraseña sólo es necesaria cuando se implementa la autorización de SyncML/DM en el


Tipo de dirección

Seleccione HTTP o HTTPS en la lista.

Dirección del servidor

Utilice uno de los valores siguientes para especificar el Servidor de gestión de dispositivos:

v Dirección IP

v Nombre del host


Vía de acceso de servidor DM

SyncML/DM es el protocolo de sincronización de datos que el agente y el servidor utilizan

para comunicarse entre sí. Cuando el servidor se ha configurado para que requiera la

autorización mediante SyncML/DM, añada el valor siguiente a la dirección del servidor:


Si el servidor no requiere la autorización de SyncML/DM, añada el valor siguiente a la

dirección del servidor:


Cuenta predeterminada

Define la cuenta que el agente utiliza para comunicarse con el servidor Device Manager.

Para crear otra cuenta, siga estos pasos:


1. En la lista Funciones de administración, pulse Crear cuenta nueva.

Aparece la ventana Crear cuenta nueva.

2. Especifique los valores de los parámetros.

Nota: no se lleva a cabo ningún tipo de validación de los parámetros.

3. Pulse el botón Crear cuenta nueva.

Aparece un mensaje de Configuración de cuenta guardada en el que se muestran los valores de la

cuenta nueva.

Una vez que haya creado otra cuenta, deberá conectarse al servidor para registrar el dispositivo y

comprobar si hay nuevos trabajos.

Ahora puede seleccionar otra función de la ventana Panel de control del Agente de gestión de empresa.

Edición de la configuración de una cuenta

Desde la ventana Panel de control del Agente de gestión de empresa puede cambiar la configuración de

una cuenta siguiendo estos pasos:

1. En la lista Funciones de administración, pulse Editar configuración de cuenta.

Aparece la ventana Editar configuración de cuenta con información sobre la cuenta actual.

2. Especifique los valores nuevos para cualquiera de los parámetros.

Nota: no se lleva a cabo ningún tipo de validación de los parámetros.

3. Pulse Actualizar cuenta para guardar los cambios.

Aparece un mensaje de Configuración de cuenta guardada en el que se muestran los valores de la

cuenta nueva.


Supresión de una cuenta

Desde la ventana Panel de control del Agente de gestión de empresa puede eliminar una cuenta

siguiendo estos pasos:

1. En la lista Funciones de administración, pulse Seleccionar cuenta.

Se abre la ventana Seleccionar cuenta.

2. En la lista de cuentas, seleccione la cuenta que desea eliminar. Para eliminar una cuenta, debe ser la

cuenta actual.

La cuenta actual se muestra por encima de la lista Función.

3. En la lista Función, pulse Editar configuración de cuenta.

Aparece la ventana Editar configuración de cuenta con información sobre la cuenta actual.

Nota: cuando se elimina una cuenta no aparece ningún diálogo de confirmación.

4. Pulse el botón Suprimir cuenta.

Aparece el mensaje Cuenta suprimida.


Edición de la información del dispositivo del Agente de gestión de empresa:


Desde la ventana Panel de control del Agente de gestión de empresa puede editar una parte de la

información del dispositivo. Por ejemplo, puede cambiar la cuenta predeterminada de la lista de cuentas

y la ubicación en la que se almacenan los archivos temporales.

Puede cambiar la siguiente información para cada dispositivo:

v Cuenta predeterminada

v Ubicación de los archivos temporales

v Información de sondeo

v Tamaño del archivo de registro y umbral de los tipos de mensaje

Los campos Nombre de dispositivo y Modelo son sólo de lectura.

Para cambiar la información del dispositivo, siga estos pasos:

1. En la lista Funciones de administración, pulse Información del dispositivo.

Aparece la ventana Información del dispositivo.

2. Seleccione una Cuenta predeterminada nueva o escriba otra vía de acceso en el campo Ubicación del

archivo temp.

3. Seleccione los valores de Intervalo de sondeo, Hora de inicio del sondeo y Hora de finalización del

sondeo en las listas desplegables.

4. Para habilitar el sondeo, asegúrese de que el campo Sondeo habilitado esté activado.

5. Especifique un nuevo tamaño para el archivo de registro, si lo desea.

6. Seleccione un nuevo umbral para los tipos de mensaje que se almacenan en el archivo de registro.

7. Pulse el botón Actualizar información de dispositivo para guardar los cambios.

Se muestra la nueva información del dispositivo y el mensaje Configuración de dispositivo guardada.


Cambio de las propiedades del Agente de gestión de empresa

Un trabajo de configuración de dispositivo puede cambiar los valores de los parámetros de configuración

de agente. Puede cambiar los parámetros de un dispositivo individual, de varios dispositivos de la misma

clase de dispositivo o de todos los dispositivos de una clase de dispositivo.

Consulte ″Trabajos de configuración de dispositivos″ en el centro de información del servidor Device

Manager para obtener detalles adicionales.

Cuando un dispositivo se inscribe en Device Manager, los parámetros de configuración de dicho

dispositivo se pueden establecer en los valores iniciales con un trabajo de configuración de dispositivo.

Según sea apropiado, los parámetros de configuración de dispositivo se pueden cambiar en una fecha

posterior con otro trabajo de configuración de dispositivo. Consulte el centro de información y la Ayuda

de Device Manager para obtener más información sobre la configuración de dispositivo y la utilización

de la consola de Device Manager.

Para crea un trabajo de configuración de dispositivo utilizando la consola de Device Manager, realice los

pasos siguientes:

1. En la consola de Device Manager, seleccione el dispositivo de destino, un grupo de dispositivos, la

clase de dispositivo o los criterios para ejecutar el trabajo, por ejemplo dispositivos recién inscritos.

2. Pulse el botón derecho del ratón en un dispositivo o la clase de dispositivo y seleccione Someter

trabajo en el menú emergente.

3. Utilice la ventana Atributos para especificar los atributos de este trabajo. Los atributos de trabajo

incluyen, por ejemplo, el tipo de trabajo, la fecha de activación, la fecha de caducidad, la prioridad y

la descripción.


Seleccione Configuración de dispositivo en el campo Tipo de trabajo.

4. Utilice la ventana Parámetros de trabajo de Configuración de dispositivo para establecer los valores

de los parámetros de configuración para este trabajo.

Utilice las pestañas o el árbol de la ventana Parámetros para navegar hasta los parámetros que desea

establecer para este trabajo.

Para ver descripciones de parámetros de dispositivo y los valores válidos para cada clase de

dispositivo proporcionada:

a. Pulse el nombre de clase de dispositivo en Tabla de contenido.

b. Pulse Parámetros de configuración.5. Utilice la ventana Someter resumen de trabajo para revisar y verificar los dispositivos de destino, los

atributos y la información de parámetros que ha especificado para este trabajo. Pulse Aceptar para

someter el trabajo.

Si el trabajo se somete satisfactoriamente, se visualiza el ID del trabajo creado. Puede utilizar el ID de

trabajo para realizar otras tareas tales como:

v Ver el historial de trabajos

v Ver próximos trabajos

v Excluir el dispositivo de trabajos

Registro de características con el servidor Device Manager

Para desplegar una característica utilizando el servidor Device Manager, primero necesitará definir la

característica y el contenido en el servidor. Las características se deben definir en el contexto de un sitio

de actualización.

Puede registrar una característica individual del sitio de actualización o el sitio de actualización entero.

Consulte ″Trabajo de control de características de Eclipse″ en el centro de información del servidor Device

Manager para obtener más información.

Despliegue de características de Eclipse

Una vez que se han registrado las características en el servidor Device Manager, puede utilizar el servidor

Device Manager para crear trabajos a fin de distribuir las características a los clientes.

Consulte ″Trabajo de distribución de características de Eclipse″ en el centro de información del servidor

Device Manager para obtener más información.

Actualización de características con el servidor Device Manager

Cuando despliegue versiones nuevas de las aplicaciones, necesitará desplegar versiones nuevas de las

características.

Existen dos modelos para actualizar las características desplegadas en una plataforma de destino:

v Si el descriptor de características (feature.xml) de la característica desplegada contiene un URL de sitio

de actualización, puede utilizar el trabajo de control de características de Eclipse para que la

plataforma de destino intente actualizar la característica desde el sitio de actualización de

características. Consulte ″Trabajo de control de características de Eclipse″ en el centro de información

del servidor Device Manager. Para obtener más información, consulte “Registro de características con el

servidor Device Manager”.

v Si el descriptor de características (feature.xml) de la característica desplegada no contiene un URL de

sitio de actualización o elige desplegar una versión actualizada de la característica sin hacer referencia

al sitio de actualización referido por el URL de sitio de actualización en la característica, siga la vía de

acceso de instalación para desplegar la característica actualizada. Primero necesitará registrar la nueva

característica y, a continuación, desplegarla. Para obtener más información, consulte “Despliegue de

características de Eclipse”.


Desinstalación de características de Eclipse

Si necesita eliminar una aplicación del cliente, puede utilizar el servidor Device Manager para realizar

esta tarea.

Consulte ″Trabajo de eliminación de características de Eclipse″ en el centro de información del servidor

Device Manager.

Despliegue de aplicaciones nativas

Este apartado describe cómo desplegar aplicaciones nativas.

El programa de utilidad de línea de mandatos que crea paquetes de software nativos se denomina

NativeAppBundle.bat. Está ubicado en el CD de Lotus Expeditor Client bajo utils\NativeAppBundle\.

Los nombres y valores de parámetros para el programa de utilidad se pueden escribir a continuación del

mandato o se pueden especificar en un archivo de texto.

Si se utiliza un archivo de texto, especifique el nombre de archivo de texto utilizando el siguiente

formato:

NativeAppBundle.bat -Parameters=nombre_archivo

donde nombre_archivo es el nombre del archivo de texto que contiene la lista de parámetros. En el archivo

de texto, hay un parámetro y valor por línea. Para obtener más información, consulte “Parámetros de un

archivo de texto de ejemplo (mandato NativeAppBundle)” en la página 216 y Trabajos de distribución de

software nativo con paquetes OSGi. Cuando se utiliza -Parameters, no se especifican otros nombres y

valores de parámetro cuando se escriba el mandato NativeAppBundle.bat.

Si los nombres y valores de parámetro se escriben después del mandato, utilice el formato siguiente:

NativeAppBundle.bat -InputDirectory=nombre_dir -BundleName=nombre_paquete

-InstallDirectory=nombre_dir -and etc

Parámetros necesarios y opcionales (mandato NativeAppBundle)

Este apartado describe los parámetros necesarios y los opcionales.

Los parámetros del mandato NativeAppBundle se separan en parámetros necesarios y opcionales.

Notas:

v Cuando especifique nombres de vía de acceso, utilice ″/″ o ″\\″ para especificar directorios.

v El mandato NativeAppBundle espera entrada válida. El mandato no realiza ninguna validación

de entrada y los resultados pueden ser imprevisibles si la entrada no es válida.

v Al especificar un valor de parámetro, como sí o no, el valor debe estar en el idioma local.

Utilice el parámetro -Help para ver los valores aplicables.

Parámetros necesarios (mandato NativeAppBundle)

Tabla 31. Parámetros necesarios de NativeAppBundle


-BundleName Nombre del paquete de software nativo. El nombre de paquete es necesario.

-InputDirectory Nombre vía de acceso completo del directorio para los archivos del paquete de software

nativo. El directorio de entrada es necesario.

-InstallDirectory Nombre de vía de acceso completo del directorio del dispositivo donde están instalados

los archivos del paquete de software nativo. El directorio de instalación es necesario.


||

|

|||||

||

http://publib.boulder.ibm.com/infocenter/ledoc/v6r11/index.jsp?topic=/com.ibm.websphere.dms.doc/dm/jobs_native_sw_dist_osgi_bundles.html

http://publib.boulder.ibm.com/infocenter/ledoc/v6r11/index.jsp?topic=/com.ibm.websphere.dms.doc/dm/jobs_native_sw_dist_osgi_bundles.html

Parámetros opcionales (mandato NativeAppBundle)

Tabla 32. Parámetros opcionales de NativeAppBundle


# Utilice un símbolo de almohadilla (#) en la primera posición de la línea del

archivo de parámetros para escribir comentarios.

-BuildDirectory Nombre del directorio donde está ubicado el archivo JAR de SMF.

-BundleVersion Número de versión del paquete de software nativo. El valor predeterminado

es 1.0.0.

-BundleDescription Descripción del paquete de software nativo. El valor predeterminado es

BundleName.

-JarName Nombre del archivo JAR de paquete de software nativo. El valor

predeterminado es BundleName.

-Prereq Identifica el nombre del paquete de software nativo que es un prerrequisito

del paquete que se está instalando.

-Install Programa de instalación que se debe ejecutar en el dispositivo después de que

se hayan instalado todos los archivos del paquete de software nativo. Se debe

especificar el nombre de vía de acceso completa del programa en el

dispositivo.

La opción -Install sólo se invoca si el paquete se distribuye con el parámetro

Auto Start establecido en True.

Se pueden pasar parámetros al programa.

Nota: Lotus Expeditor Client para dispositivos no soporta el parámetro

-Install.

-PreInstall y -PostInstall Especifique un programa para que se ejecute antes y/o después de ejecutar el

programa de instalación (especificado por -Install).

Puede utilizar una o varias de las opciones siguientes:

v -PreInstall=nombre_archivo_a_ejecutar

v -PostInstall=nombre_archivo_a_ejecutar

Opcionalmente, se pueden incluir pasos de verificación de instalación con el

parámetro -PostInstall.

-WhenToRunPostInstall Determina cuándo se ejecuta el programa posterior a la instalación. Los

valores permitidos son:

always Ejecutar siempre el programa posterior a la instalación

afterInstallFailure

Ejecutar sólo el programa posterior a la instalación si la instalación

falla.

afterInstallSuccess

Ejecutar sólo el programa posterior a la instalación si la instalación se

realiza satisfactoriamente.

-Uninstall Programa de desinstalación a ejecutar en el dispositivo antes de que se

eliminen los archivos instalados cuando se desinstala el paquete de control de

software nativo. Se debe especificar el nombre de vía de acceso completa del

programa en el dispositivo.


Nota: El Lotus Expeditor Client para dispositivos no soporta el parámetro

–Uninstall.


Tabla 32. Parámetros opcionales de NativeAppBundle (continuación)


-RemoveOnUninstall Determina si se eliminan archivos cuando se desinstala el paquete de control

de software nativo. Los archivos que se deben eliminar están en el directorio

identificado por el parámetro -InstallDirectory.

Los valores válidos son sí o no.

El valor predeterminado es sí.

-CleanupAfterInstall Determina si se eliminan archivos cuando se instala el programa de

instalación de paquete de software nativo estándar. Los archivos que se deben

eliminar están en el directorio identificado por el parámetro -InstallDirectory.

Los valores válidos son sí o no.

El valor predeterminado es no.

-Start Programa de inicio a ejecutar en el dispositivo cada vez que se inicia el

paquete de control de software nativo.

Cuando se distribuye un paquete de software nativo, el paquete está en un

estado ″instalado″ si Auto Start se ha establecido en True. Utilice el trabajo de

control de paquetes con una acción Start para iniciar el paquete de control de

software nativo.

Se debe especificar el nombre de vía de acceso completa del programa del

dispositivo.


La opción -Start no se invoca durante el inicio de paquete de la distribución

inicial del paquete. Si la opción -Start se ha iniciado utilizando el trabajo de

control de paquetes y no se detiene antes de que se detenga el entorno de

ejecución de OSGi, cada vez que se reinicie el entorno de ejecución de OSGi,

se reiniciará la opción -Start.

-Stop Programa de detención a ejecutar en el dispositivo cada vez que se detiene el

paquete de control de software nativo. Se debe especificar el nombre de vía

de acceso completa del programa en el dispositivo.


Utilice el trabajo de control de paquetes con una acción ″stop″ para detener el

paquete de control de aplicaciones nativo.

-IgnoreNonZeroInstallRC Utilice el parámetro de anomalía de código de retorno

(-IgnoreNonZeroInstallRC) para determinar si el trabajo debe fallar en el

caso de que el código de retorno del paso de instalación

(INSTALL_EXIT_VALUE) sea distinto de cero. Algunos mandatos utilizan

códigos de retorno distintos de cero para indicar una condición satisfactoria.

Los valores permitidos son:

sí El trabajo fallará (valor predeterminado)

no El trabajo no fallaráSi el paso de instalación falla debido a un código de retorno distinto de cero

(INSTALL_EXIT_VALUE), el dispositivo sólo se reinicia si se ha especificado

un reinicio después del correspondiente paso de instalación.

Para los pasos previos a la instalación (PRE_INSTALL_EXIT_VALUE) y

posteriores a la instalación (POST_INSTALL_EXIT_VALUE), un código de

retorno distinto de cero indica siempre una anomalía de trabajo. Cuando se

detecta una anomalía de trabajo, no se intentan pasos adicionales (excepto si

INSTALL_EXIT_VALUE es distinto de cero e -IgnoreNonZeroInstallRC=no).


Tabla 32. Parámetros opcionales de NativeAppBundle (continuación)


-WorkingDirectory Vía de acceso al directorio de trabajo. El valor predeterminado es el directorio

actual.

Debe tener acceso de R/W/X al directorio de trabajo. Si el directorio de

trabajo especificado no existe, se crea un directorio nuevo que se suprime

después de utilizarlo. Todos los archivos creados se deben suprimir después

de utilizarlos.

-PrereqVerison Número de versión mínimo del paquete de prerrequisitos. El formato de la

versión debe ser:

n

n.n

n.n.n

Si no se especifica la versión del prerrequisito, ésta toma de forma

predeterminada la versión más reciente.

La herramienta de resolución automática de prerrequisito elige como mínimo

el número de versión especificado. Por ejemplo, si la versión especificada es

1.7.1 y las versiones disponibles son 1.7.0, 1.7.1 y 1.7.2, se descargará la 1.7.2

de forma predeterminada.

-Help Muestra la sintaxis de programa. Todos los demás parámetros se ignoran.


“Opciones de trabajo y tareas para distribuir paquetes de software nativos (paquetes OSGi)”Este apartado describe las opciones de trabajo y las tareas para distribuir paquetes de software

nativos.

“Trabajos de distribución de software nativo con paquetes OSGi” en la página 218Este apartado describe trabajos de distribución de software nativo con paquetes OSGi.

Opciones de trabajo y tareas para distribuir paquetes de software nativos

(paquetes OSGi)

Este apartado describe las opciones de trabajo y las tareas para distribuir paquetes de software nativos.

Para distribuir un paquete de software nativo, utilice las siguientes opciones de trabajo y realice las

siguientes tareas:

v Identifique el software nativo para el paquete de software nativo.

v Opcionalmente, identifique el programa de instalación para ejecutarlo en el dispositivo después de que

todos los archivos del paquete de software nativo se hayan instalado (parámetro -Install).

v Opcionalmente, identifique el programa de desinstalación a ejecutar en el dispositivo antes de que se

eliminen los archivos instalados cuando se desinstala el paquete de control de software nativo

(parámetro -Uninstall).

v Opcionalmente, identifique el programa de inicio a ejecutar en el dispositivo cada vez que se inicie el

paquete de control de software nativo (parámetro -Start).

v Opcionalmente, identifique el programa de detención a ejecutar en el dispositivo cada vez que se

detenga el paquete de control de software nativo (parámetro -Stop).

v Opcionalmente, incluya la captura y el almacenamiento de los códigos de retorno, la salida estándar y

los mensajes de error estándar. Los valores permitidos son YES (mensajes de captura y

almacenamiento) y NO (valor predeterminado).

Si CAPTURE_OUTPUT=YES, los códigos de retorno, la salida estándar y los mensajes de error

estándar se capturan y, a continuación, se almacenan como detalles en el registro de terminación de

trabajo del dispositivo. La salida capturada tiene el formato siguiente:


PRE_INSTALL_EXIT_VALUE: código_retorno

PRE_INSTALL_STDOUT: salida_estándar

PRE_INSTALL_STDERR error_estándar

INSTALL_EXIT_VALUE: código_retorno

INSTALL_STDOUT: salida_estándar

INSTALL_STDERR error_estándar

POST_INSTALL_EXIT_VALUE: código_retorno

POST_INSTALL_STDOUT: salida_estándar

POST_INSTALL_STDERR error_estándar

v Opcionalmente, utilice el parámetro de anomalía de código de retorno (-IgnoreNonZeroInstallRC) para

determinar si el trabajo debe fallar en el caso de que el código de retorno del paso de instalación

(INSTALL_EXIT_VALUE) sea distinto de cero. Algunos mandatos utilizan códigos de retorno distintos

de cero para indicar una condición satisfactoria.

v Cree el paquete de software nativo utilizando NativeAppBundle.bat.

Revise todos los parámetros de NativeAppBundle.bat e incluya los parámetros aplicables para el

trabajo de distribución de software nativo.

v Ponga el archivo JAR de paquete de software nativo en el servidor HTTP.

v Cuando registre el software utilizando la consola de Device Manager, apunte al paquete de software

nativo recién creado. Asegúrese de que se puede acceder a la ubicación de software en el servidor

HTTP en el servidor Device Manager utilizando el protocolo HTTP o HTTPS.

Si está utilizando la consola de Device Manager para crear trabajos, utilice el tipo de trabajo de paquete

de software nativo cuando distribuya los paquetes OSGi a los dispositivos de destino.

Ejecución de la instalación más de una vez

Si el programa de instalación de paquete de software nativo estándar se instala otra vez mientras está

instalado el paquete de control de software nativo:

v Los archivos especificados no se descargan en el dispositivo otra vez.

v El programa de instalación de paquete de software nativo estándar no se ejecuta.

Opcionalmente, puede eliminar el paquete de control de software nativo del dispositivo con un programa

″uninstall″. Utilice el parámetro -Uninstall de NativeAppBundle.bat para especificar este programa de

desinstalación. Después de que se desinstale el paquete de control de software nativo, se puede instalar

otra vez el programa de instalación de paquete de software nativo estándar y se puede instalar otra vez

el paquete de software nativo con el software nativo.


v Distribución de software nativo con paquetes OSGi

v Parámetros necesarios y opcionales

v Ejemplo para parámetros en un archivo de texto

v Distribución de software utilizando paquetes OSGi

v Control de paquetes en un dispositivo

Parámetros de un archivo de texto de ejemplo (mandato NativeAppBundle)

Al distribuir paquetes de software nativos, puede especificar los parámetros en un archivo de texto o en

la línea de mandatos con el mandato NativeAppBundle.

Ejemplo para especificar los parámetros en un archivo de texto

El mandato para crear el paquete de software nativo desde un archivo de texto es:

NativeAppBundle.bat -Parameters=parameterList


El archivo de texto parameterList tiene las líneas siguientes:

-BundleName=TestBundle2

-InputDirectory=c:/SourceFiles/Bundle2

-InstallDirectory=c:/Archivos de programa/testBundles

-BundleVersion=2.1.0

-LocalStorageInBytes_c:/=100000000

-LocalStorageInBytes_n:/=50000000000

-Install=c:/Archivos de programa/testBundles/InstallPgm.exe -parm1

-Uninstall=c:/Archivos de programa/testBundles/UninstallPgm.exe

-Start=c:/Archivos de programa/testBundles/bundleProcess.exe

-RemoveOnUninstall=yes

-JarName=DemoTestBundle

-WhenToRunPostInstall=always

El archivo de texto de mandatos y parámetros NativeAppBundle.bat -Parameters=parameterList realiza

las acciones siguientes:

v Crea un paquete de software nativo denominado DemoTestBundle+2_1_0.jar (parámetros

-BundleVersion y -JarName).

v El archivo JAR contiene todos los archivos en el directorio c:/SourceFiles/Bundle2 (parámetro

-InputDirectory).

v El paquete se denomina TestBundle2 (parámetro -BundleName).

v Después de que el programa de instalación de paquete de software nativo estándar se haya instalado e

iniciado en el dispositivo, los archivos se instalan con InstallPgm.exe y se pasa ″parm1″ a la instalación

(parámetro -Install).

v El programa de instalación de paquete de software nativo estándar instala los archivos en el directorio

c:/Archivos de programa/testBundles del dispositivo (parámetro -InstallDirectory).

v La cantidad de almacenamiento local necesaria es como mínimo de 100 megabytes de espacio libre en

la vía de acceso c:/ y como mínimo de 50 megabytes libres en la vía de acceso d:/ (parámetro

-LocalStorageInBytes).

v El programa de desinstalación es c:/Archivos de programa/testBundles/UninstallPgm.exe. Se ejecuta

en el dispositivo antes de que se eliminen los archivos instalados cuando se desinstala el paquete de

control de software nativo (parámetro -Uninstall).

v Cada vez que se inicia el paquete de control de software nativo, se ejecuta el programa de inicio

c:/Archivos de programa/testBundles/bundleProcess.exe (parámetro -Start).

v Los archivos instalados se eliminan cuando se desinstala el paquete de control de software nativo

(parámetro -RemoveOnUninstall).

Ejemplo para escribir parámetros en una línea de mandatos

El programa de utilidad de línea de mandatos de paquete de software nativo se puede escribir en una

sola línea (más abajo el mandato aparece en varias líneas para facilitar su lectura):

NativeAppBundle.bat -BundleName=NativeTestBundle

-InputDirectory=c:/SourceFiles/Bundle1

-InstallDirectory=c:/Archivos de programa/testBundles

El mandato NativeAppBundle.bat realiza las acciones siguientes:

v El archivo JAR contiene todos los archivos en el directorio c:/SourceFiles/Bundle1 (parámetro

-InputDirectory).

v El paquete se denomina NativeTestBundle (parámetro -BundleName).

v El paquete de control de software nativo tiene el nombre predeterminado (NativeTestBundle). El

paquete de control de software nativo se instala, pero no se inicia.

v El programa de instalación de paquete de software nativo estándar instala los archivos en el directorio

c:/Archivos de programa/testBundles del dispositivo (parámetro -InstallDirectory).


v Los archivos instalados se eliminan cuando se desinstala el paquete de control de software nativo. El

valor predeterminado para el parámetro -RemoveOnUninstall es sí.

v No hay ningún programa de instalación, programa de desinstalación o programa de inicio.

Trabajos de distribución de software nativo con paquetes OSGi

Este apartado describe trabajos de distribución de software nativo con paquetes OSGi.

Para los dispositivos OSGi, por ejemplo dispositivos Windows de 32 bits, dispositivos Linux y los

dispositivos que Lotus Expeditor Client soporta, el software se puede distribuir en forma de paquetes

OSGi. Un paquete OSGi consta de clases Java y otros recursos que juntos pueden proporcionar funciones

a los propietarios de dispositivos y proporcionar servicios y paquetes a otros paquetes. Un paquete se

distribuye como un archivo JAR.

Para distribuir software nativo con paquetes OSGi, Lotus Expeditor Client incluye un programa de

utilidad de línea de mandatos para incluir el software nativo en un paquete OSGi para su distribución.

Este paquete se denomina paquete de software nativo. El paquete de software nativo se pone en un

servidor web y se registra en el Device Manager de Lotus Expeditor Server para que el paquete esté

disponible para la distribución de software.

El agente de dispositivo obtiene el paquete OSGi directamente del URL asociado al software registrado.

El URL asociado al software registrado especifica la ubicación.

El software nativo del paquete se instala en el directorio deseado del dispositivo utilizando el programa

de instalación de paquete de software nativo estándar. Se puede especificar un programa de instalación

opcional que se puede ejecutar en el dispositivo. Cuando el programa de instalación opcional se ha

ejecutado, el paquete de software nativo se detiene y se desinstala a sí mismo de forma automática.

Antes de que el paquete de software nativo se elimine a sí mismo del dispositivo, se instala

automáticamente en el dispositivo un paquete de software nativo independiente utilizado para el control

de paquetes de software nativo. El agente de dispositivo utiliza este paquete de control de software

nativo para realizar un inventario de software del paquete de software nativo. El paquete de control de

software nativo se denomina BundleName (el mismo nombre que el paquete de software nativo).

Cuando se inicia este paquete de control de software nativo, se puede iniciar (y detener) muchas veces un

programa ″start″ opcional. Cada vez que se inicia el paquete de control de software nativo, se ejecuta el

programa de inicio opcional.

Están disponibles trabajos de distribución de software nativo con paquetes OSGi para las siguientes clases

de dispositivo OSGi:

v Dispositivos Linux

v Dispositivos Windows de 32 bits

v Dispositivos Windows Mobile 2003 Standard Edition o Windows Mobile 5

Para trabajos de distribución de software nativo con paquetes OSGi, se utilizan el nombre de paquete, la

versión de paquete y la descripción de paquete del archivo de manifiesto para el nombre de paquete, la

versión y la descripción de software en la base de datos de Device Manager.

Un trabajo de distribución de software nativo no actualiza automáticamente el inventario de software en

la base de datos de Device Manager para los dispositivos de destino. Para actualizar la base de datos,

ejecute un trabajo de recogida de inventario para los dispositivos de destino. Para obtener más

información, consulte ″Device Manager 2.1″ en Utilización de Lotus Expeditor Server.

La distribución de software nativo destinada a los agentes de Device Manager utiliza el tipo de trabajo de

distribución de software nativo.


Limitación de progreso de trabajo para aplicaciones nativas

Cuando se ejecuta un trabajo de distribución de software nativo, el progreso de trabajo indica el éxito, la

anomalía u otras condiciones de progreso de trabajo. Sin embargo, el progreso de trabajo no proporciona

la condición de progreso de trabajo de una aplicación nativa que se ejecute en el dispositivo.

Por ejemplo, si como parte de la distribución de una aplicación nativa utiliza el parámetro -Install para

ejecutar un programa de instalación, el éxito o la anomalía de dicho programa de instalación no se puede

supervisar con la información de progreso de trabajo. De forma similar, si se utiliza un trabajo de control

de paquete para iniciar un programa de instalación, el éxito o la anomalía de dicho programa de

instalación no se puede supervisar son la información de progreso de trabajo. El progreso de trabajo sólo

informa sobre el estado del trabajo de Device Manager. Para obtener más información, consulte ″Device

Manager 2.1″ en Utilización de Lotus Expeditor Server.


v Trabajos de distribución de software con paquetes OSGi

v Control de paquetes en un dispositivo

Gestión de preferencias

La plataforma de cliente proporciona extensiones al árbol de gestión de SyncML/DM que permiten la

gestión de las preferencias de Eclipse.

La modalidad preferida para trabajar con las preferencias de Eclipse consiste en utilizar los trabajos de

preferencias de Eclipse.

Una alternativa a la utilización de los trabajos de preferencias de Eclipse es utilizar el trabajo de

descubrimiento de nodo y los trabajos de mandatos personalizados.

Consulta de preferencias de entorno de ejecución de cliente

Puede consultar los valores de preferencia de entorno de ejecución como ayuda para configurar Lotus

Expeditor Client.

Par consultar las preferencias actuales, utilice el trabajo de recuperación de preferencias de Eclipse.

Consulte ″Trabajo de recuperación de preferencias de Eclipse″ en el centro de información del servidor

Device Manager.

También puede utilizar el trabajo de descubrimiento de nodo para consultar las preferencias de entorno

de ejecución de cliente. Utilice ./Configuration/Preferences/Eclipse como raíz del URI de destino. La

información de preferencias recuperada mediante el trabajo de descubrimiento de nodo se podrá ver en

la pestaña Árbol de gestión de Ver inventario en la consola. Consulte ″Trabajos de descubrimiento de

nodos″ en el centro de información del servidor Device Manager.

Creación de preferencias de entorno de ejecución de cliente

Utilice el trabajo de edición de preferencias de Eclipse del servidor Device Manager para crear nuevas

preferencias.

Consulte ″Trabajo de edición de preferencias de Eclipse″ en el centro de información del servidor Device


También puede utilizar trabajos de mandatos personalizados para crear preferencias.

v Empiece cualquier URI de destino con ./Configuration/Preferences/Eclipse/ antes de añadir

información específica de clave y nodo de preferencia.

v Al crear claves, utilice text/plain para el metatipo (Meta Type) y node para el metaformato (Meta

Format).


v Al crear hojas (claves), utilice text/plain para el metatipo y chr para el metaformato.

Consulte ″Trabajos de mandatos personalizados″ en el centro de información del servidor Device


Actualización de preferencias de entorno de ejecución de cliente

Utilice el trabajo de edición de preferencias de Eclipse del servidor Device Manager para actualizar las

preferencias.


Manager.

También puede utilizar trabajos de mandatos personalizados para actualizar preferencias. Empiece

cualquier URI de destino con ./Configuration/Preferences/Eclipse/ antes de añadir información

específica de clave y nodo de preferencia. Consulte ″Trabajos de mandatos personalizados″ en el centro

de información del servidor Device Manager.

Supresión de preferencias de entorno de ejecución de cliente

Utilice el trabajo de edición de preferencias de Eclipse del servidor Device Manager para suprimir

preferencias.


Manager.

También puede utilizar trabajos de mandatos personalizados para actualizar preferencias. Empiece

cualquier URL de destino con ./Configuration/Preferences/Eclipse/ antes de añadir información

específica de clave y nodo de preferencias. Consulte ″Trabajos de mandatos personalizados″ en el centro

de información del servidor Device Manager.

Gestión de archivos de propiedades

Las extensiones al Agente de gestión de empresa permiten las actualizaciones de los valores de propiedad

individuales en los archivos de propiedades Java.

Los archivos que se pueden gestionar se deben registrar utilizando puntos de extensión. Consulte

“Ampliación de la plataforma para la gestión de propiedades de Device Manager” en la página 148.

La consola de Device Manager proporciona trabajos específicos para la gestión de propiedades. Éstos son

los trabajos preferidos.

También puede utilizar trabajos de mandatos personalizados para trabajar con propiedades.

Consulta de valores de archivo de propiedades

Utilice el trabajo de recuperación de propiedades para consultar los valores de archivo de propiedades en

el cliente.

Consulte ″Trabajo de recuperación de propiedades″ en el centro de información del servidor Device

Manager.

También puede utilizar un trabajo de descubrimiento de nodo para recuperar información de

propiedades. Utilice ./Configuration/Properties como principio del URL de destino. Los resultados de

un trabajo de descubrimiento de nodo se visualizan en la pestaña Árbol de gestión cuando se selecciona

Ver inventario en un dispositivo. Consulte ″Trabajos de descubrimiento de nodos″ en el centro de

información del servidor Device Manager.


Cambio de un valor de archivo de propiedades

Utilice el trabajo de edición de propiedades para cambiar un valor de una propiedad existente en un

archivo de propiedades.

Consulte ″Trabajo de edición de propiedades″ en el centro de información del servidor Device Manager.

También puede utilizar un trabajo de mandato personalizado para realizar una actualización de valor de

propiedad. Asegúrese de incluir ./Configuration/Properties antes del nombre de archivo de

propiedades y del nombre de propiedad. Consulte ″Trabajos de mandatos personalizados″ en el centro de

información del servidor Device Manager.

Adición de una propiedad nueva a un archivo de propiedades

Utilice el trabajo de edición de propiedades del servidor Device Manager para crear propiedades nuevas

en un archivo de propiedades definido.

Consulte ″Trabajo de edición de propiedades″ en el centro de información del servidor Device Manager

para obtener más información.

También puede utilizar trabajos de mandatos personalizados para crear una propiedad nueva en un

archivo de propiedades definido.

v Empiece cualquier URL de destino con ./Configuration/Properties/ antes de añadir información

específica de clave de propiedades y de nombre de archivo de propiedades.

v Al crear claves, utilice text/plain para el metatipo (Meta Type) y chr para el metaformato (Meta

Form).

Consulte ″Trabajos de mandatos personalizados″ en el centro de información del servidor Device

Manager.

Supresión de una propiedad de un archivo de propiedades

Utilice el trabajo de edición de propiedades del servidor Device Manager para suprimir las propiedades

existentes de un archivo de propiedades definido.

Consulte ″Trabajo de edición de propiedades″ en el centro de información del servidor Device Manager.

También puede utilizar trabajos de mandatos personalizados para suprimir una propiedad existente de

un archivo de propiedades definido. Empiece cualquier URL de destino con ./Configuration/Properties/ antes de añadir información específica de clave de propiedades y de nombre de archivo de

propiedades. Consulte ″Trabajos de mandatos personalizados″ en el centro de información del servidor

Device Manager.

Configuración de los plug-ins de cliente con el Agente de gestión de empresa:

Puede cambiar la configuración de un plug-in de cliente que se ha registrado a sí mismo como Servicio

gestionado en la infraestructura mediante el Agente de gestión de empresa.

Un Servicio gestionado representa un cliente del servicio Administración de configuración. Los plug-ins

que se han registrado a sí mismos como Servicio gestionado (por ejemplo, el contenedor web) recibirán

notificaciones de actualización de la configuración del servicio ConfigurationAdmin.

El Agente de gestión de empresa proporciona los administradores un medio para descubrir estos tipos de

plug-in y cambiar su configuración.

Nota:


v El registro como servicio gestionado no garantiza que un plug-in pueda ser descubierto por el

Agente de gestión de empresa. ConfigurationAdmin debe llenarse con los datos de

configuración de los plug-ins. Consulte la especificación de OSGi™ para obtener más información

al respecto.

v Los administradores que opten por configurar el plug-in de cliente mediante el Agente de

gestión de empresa deberán llenar el servicio ConfigurationAdmin con los datos de

configuración de los plug-ins. Pueden hacerlo a nivel de programa o utilizando una herramienta

como el Programa de utilidad de administración para OSGi.

En los pasos siguientes se describe cómo cambiar la configuración de un plug-in de cliente, utilizando

varios trabajos para realizar la tarea. Estas tareas deben llevarse a cabo en un sistema que ejecute un

servidor Device Manager utilizando la aplicación de consola de Device Manager.





4. Pulse Siguiente y seleccione Descubrimiento de tipo de trabajo como nodo (utilice los valores

predeterminados para todos los demás atributos del trabajo).


6. Escriba ./OSGi/BundleConfiguration/<PID_plugin> como URL de destino,

donde <PID_plugin> es el PID del plug-in. com.ibm.pvc.webcontainer, por ejemplo, es el PID del

contenedor web.

7. Especifique una profundidad de búsqueda 5 y pulse Siguiente.


9. Deberá esperar a que el trabajo finalice (el tiempo dependerá del intervalo de sondeo configurado).

Una vez que el trabajo haya finalizado, seleccione el servicio y pulse Ver inventario.




13. Especifique 1 para el campo Número de mandato.


15. Pulse Aceptar.


Configuración del contenedor web utilizando el Agente de gestión de empresa:

Puede cambiar de forma remota la configuración del contenedor web utilizando el Agente de gestión de

empresa.

Nota: A continuación se indican los prerrequisitos para el procedimiento de configuración:

v El almacenamiento de administración de configuración ya se ha llenado previamente con datos

de configuración de contenedor Web.

v El Agente de gestión de empresa se ha registrado en el servidor Device Manager y está

preparado para funcionar.

Siga estos pasos para cambiar la configuración de un plug-in de cliente, utilizando varios trabajos para

realizar la tarea. Estas tareas deben llevarse a cabo en un sistema que ejecute un servidor Device Manager

utilizando la aplicación de consola de Device Manager.






4. Pulse Siguiente y, a continuación, seleccione Tipo de trabajo como Descubrimiento de nodos

(utilice los valores predeterminados para todos los demás atributos de trabajo).


6. Escriba ./OSGi/BundleConfiguration/<PID_Plugin> como URL de destino donde <PID_Plugin> es

el PID del plug-in. Por ejemplo, com.ibm.pvc.webcontainer es el PID del contenedor Web.

7. Entre una profundidad de búsqueda de 5 y, a continuación, pulse Siguiente.


9. Una vez que el trabajo haya finalizado, seleccione el servicio y pulse Ver inventario.




13. Entre 1 en el campo Número de mandato.


15. Pulse Aceptar.



Puede habilitar las estaciones de trabajo de Lotus Expeditor Client para recibir información de

configuración de un WebSphere Portal Server. Esto le permite administrar de forma centralizada el

entorno de Lotus Expeditor Client.

El control de acceso basado en rol administrado de forma central es un requisito crítico de todas las

grandes empresas. WebSphere Portal proporciona un conjunto de funciones potentes especialmente

destinadas a estos requisitos. El portlet de Administración de Navegador gestionado expone cada

instancia del navegador como un portlet. Además, también se exponen elementos configurables de la

instancia de navegador (por ejemplo la barra de dirección, las restricciones de URL) mediante el portlet.

Mediante la exposición de estos elementos configurables, ahora se pueden gestionar de un modo basado

en rol. La integración con WebSphere Portal permite que la administración de usuario general

permanezca lo más unificada posible, lo cual reduce el coste financiero y de personal.

Los administradores pueden utilizar la misma gestión de páginas y lugares, gestión de usuarios y

controles de acceso para integrar, gestionar y volver a utilizar componentes de aplicaciones que se

ejecutan en diversos tipos de dispositivos, que incluyen desde dispositivos móviles, como teléfonos

móviles y PDA hasta escritorios basados en navegador. El cliente administrado por Portal amplía aún

más esta capacidad con soporte para dispositivos de escritorio de “cliente rico” basados en Lotus

Expeditor Client.

El término cliente administrado por Portal significa simplemente un lado de Lotus Expeditor Client que

puede instalar, cargar y ejecutar aplicaciones definidas por Portal. Las aplicaciones de portal son una

clase específica de aplicación que significa fundamentalmente un conjunto de páginas, portlets, políticas y

roles. Por definición, una aplicación WebSphere Portal es muy diferente de otras aplicaciones, por ejemplo

una aplicación de cliente rico, en términos de Eclipse. El equivalente de una aplicación de Portal en el

cliente rico es un conjunto de perspectivas (páginas) navegables que contienen vistas (portlets) y se

configuran con preferencias de Eclipse (política) y se pueden comunicar mediante un intermediario de

propiedades (conexión).

Un portlet de Portal se correlaciona con una vista de Eclipse, no con un portlet de cliente. Dicha vista

puede ser cualquier vista de Eclipse adecuada residente en el cliente. Una de las vistas incluidas con el

cliente es un visor para presentar la salida HTML de un portlet real que se ejecuta en el contenedor de


portlets del cliente. Esta vista del visor de portlets se trata de formas especiales en el cliente y en los

portlets de administración, con lo que se puede ser menos riguroso con la terminología y decir que un

portlet se correlaciona con un portlet.

Portal proporciona la posibilidad de definir una serie de páginas para la aplicación y una jerarquía de

navegación en la representación de esas páginas. Esto significa que cada aplicación individual puede

realmente definir una jerarquía completa de páginas contenidas todas en una sola aplicación de Portal.

Esto implica adicionalmente que una aplicación de Portal proyectada del cliente rico tiene n número de

perspectivas asociadas con dicha aplicación.

Root Page 1

Root Page 2

Sub Page 2.1

Sub Page 2.2

Label 3

Label-Link 3.1

Sub Page 3.2

Sub Sub Page 3.2.1

Label-Link 3.2.2

Las aplicaciones de WebSphere Portal que se ejecutan en el cliente necesitan propiedades ampliadas del

lado del cliente que se deben especificar en las páginas y los portlets del servidor. Para facilitar el proceso

de especificación de este atributos, utilice los siguientes portlets. Estos portlets mostrarán las propiedades

y las acciones que se correlacionan con la parte correspondiente de Eclipse en el cliente. Entonces el

archivo WAR necesita tener un plug-in SWT equivalente que utiliza el mismo WSDL para el registro de

intermediario de propiedad del lado de cliente. Este uso es básicamente de aplicaciones SWT que se

agregan al Portal y se despliegan desde el Portal.

Portlet de Administración de diseño de cliente rico

Se trata de una extensión del personalizador de página de Portal que se utiliza para gestionar

metadatos comunes específicos de cliente rico. Puede incluir estos datos en cualquier portlet de

cualquier página como preferencias de portlet. Una aplicación típica con una o varias páginas

puede incluir instancias de varios tipos de portlets. Los proxies de marcador y administrador

sirven para establecer la posición de los portlets en las páginas que se proyectan como vistas y

perspectivas en el cliente. Los portlets JSR168 también se proyectan como vistas pero además

pueden tener equivalentes del lado del cliente que se ejecuten en el contenedor de portlet. Dado

que los portlets JSR168 no se tienen que instrumentar de forma explícita para gestionar datos

específicos de cliente rico, el mismo portlet que no conoce el cliente rico puede servir de proxy de

administración para versiones desplegadas en el cliente rico y se puede utilizar como portlet

″normal″ en el servidor para entregarse a través de un navegador. El portlet de Administración

del diseño del cliente rico no gestionará atributos específicos de vista tales como conectar

propiedades/acciones o ver la configuración. Si esto es necesario para una vista determinada, se

necesitará un proxy de administración adecuadamente programado.

El portlet de Marcador genérico

Este portlet se utiliza para agregar cualquier vista genérica de Eclipse que no muestre

propiedades y acciones ni necesite configuración personalizada específica de vista. Este portlet no

es más que un contenedor para las preferencias de diseño comunes gestionadas por el portlet de

Administración de diseño de cliente rico (por ejemplo, ID de vista, proporción, requisitos de

característica). Este portlet se incluye en el módulo web con el portlet de Administración de

diseño de cliente rico y se puede copiar y redenominar según lo necesite el administrador y, a

continuación, colocar en páginas para representar vistas.

Portlet de ″proxy de administración″

A diferencia del portlet de marcador genérico, un proxy de administración se une estrechamente

a la vista de cliente rico que representa. Es posible que muestre propiedades y acciones ″ficticias″

para que se pueda utilizar la herramienta de conexión de portlet para crear conexiones entre los

proxies de administración que, a continuación, se envían en el XML de aplicación compuesta

desde el servidor de Portal. Esto supone que el desarrollador de plug-in ha implementado una

acción que pueda alcanzar la conexión a un id secundario/vista específica en el plug-in. Este


portlet también puede proporcionar una JSP personalizada que se utiliza para gestionar

propiedades de configuración específicas de vista. Lotus Expeditor Client incluye dos proxies de

administración; el portlet de Administración de Navegador gestionado y el portlet de habilitación

de visor WSRP de cliente rico. En general, el desarrollador deberá crear un proxy de

administración como parte del proceso de desarrollo de plug-ins de lado del cliente que soportan

la configuración de conexión y/o vista.

Estos portlets los instala Network Client Installer en el servidor de Portal. Consulte el apartado

“Instalación con Network Client Installer” en la página 33 para obtener información sobre Network Client

Installer.

Este apartado describe cómo gestionar Lotus Expeditor Client utilizando WebSphere Portal Server.

Tareas relacionadas

“Configuración de valores gestionados” en la página 77La infraestructura de valores gestionados le proporciona control sobre el comportamiento del entorno

de ejecución de las aplicaciones de cliente dejándole establecer los valores que las aplicaciones leen del


Descripción de la gestión utilizando el servidor de portal

Dado que Lotus Expeditor Client se ejecuta bajo Eclipse, la ventana de visualización se presente

principalmente utilizando contenedores de perspectivas con el contenido generado por las vistas.

El portlet de Administración de diseño de cliente rico soporta la administración de servidor de los

parámetros de vista y la colocación de vista en una perspectiva. A un nivel alto, esto se correlaciona de

forma exacta con los portlets colocados en una página. La disposición jerárquica de las páginas en el

Portal no tiene ningún equivalente directo en Eclipse pero el efecto se logra mediante el código de Lotus

Expeditor Client que conoce ambas disposiciones.

A un nivel detallado, el entorno de Eclipse es más complejo de modo que se deben añadir varios

parámetros a la configuración de Portal para representar de forma efectiva el diseño de cliente. Por

ejemplo, bajo Eclipse pueden haber funciones denominadas actividades que se inician automáticamente

cuando se abre una perspectiva. Las páginas de portal no tienen ningún concepto similar de modo que el

código de cliente reconoce un parámetro de página adicional para especificar las actividades. El servidor

de Portal agrega automáticamente la salida de los portlets a una página y un navegador web presenta la

página de acuerdo con el HTML generado por el servidor y el espacio disponible en la ventana del

cliente. Bajo Eclipse las vistas se pueden controlar con más precisión especificando proporciones relativas

del espacio de perspectiva total, de modo que el código de cliente reconoce un parámetro de portlet

adicional para la proporción.

El portlet de Administración de diseño de cliente rico proporcionado con Lotus Expeditor Client ofrece

una GUI para configurar los parámetros comunes para las páginas, las perspectivas, los portlets y las

vistas. Otras portlets se encargan de las preferencias de Eclipse, los parámetros de vista personalizados

para navegadores gestionados, un habilitador de cliente WSRP y las contribuciones de Lotus Expeditor

Client que no se configuran como vistas bajo las perspectivas.

La administración del diseño en el Portal consiste en ordenar las páginas y los portlets jerárquicamente

bajo una sola raíz de contenido. Puede añadir páginas empezando directamente bajo la raíz o en una de

las páginas predefinidas cuando se instala el portal. Lotus Expeditor Client sólo recupera información de

Raíz de contenido → Raíz de aplicación. Aquí es donde el servidor de Portal pone sus propias

aplicaciones compuestas. Sin embargo, el administrador normalmente utilizará las funciones de Biblioteca

de plantillas bajo el enlace Plantillas de la página de inicio. Aquí puede importar y crear plantillas de

aplicaciones y, a continuación, utilizarlas para crear aplicaciones compuestas en la biblioteca de

aplicaciones. Las aplicaciones también se pueden dividir en categorías, donde Lotus Expeditor Client

solicita normalmente la lista de aplicaciones en la categoría MyClient.


Independientemente del punto de partida, cada página puede tener páginas bajo ella y contener portlets.

Durante el funcionamiento normal, la selección de páginas hijo se visualiza de acuerdo con un tema con

pestañas comunes. El contenido generado por los portlets llena el resto de la ventana. Observe que

también hay un elemento de etiqueta, básicamente una página que tiene páginas hijo pero no portlets y

un elemento de URL que es un enlace al exterior del Portal o hacia una página existente de igual

jerarquía. La raíz de la aplicación compuesta es técnicamente una etiqueta, pero dado que este

documento trata sobre el diseño y el contenido de páginas con portlets, la etiqueta y el URL sólo se

mencionan si es apropiado pero no se describen adicionalmente.

En Portal, las páginas son artefactos que sólo existen en el contexto de elementos de una base de datos.

Las propiedades de página asociadas y el diseño de contenedor son también información que el servidor

conserva en una base de datos. El contenido de página hace referencia a portlets reales que ejecutan

código para producir la salida presentada que se ve en un navegador Web. Del mismo modo, Eclipse

tiene metadatos para describir perspectivas y las vistas contenidas y el contenido de las vistas procede de

código de plug-ins escritos como aplicaciones SWT. Dado que el entorno de ejecución de portlet de API

de IBM original y el entorno de SWT base son muy diferentes, el código de generación de contenido es

también muy diferente. Esto cambia porque un contenedor de portlet de Lotus Expeditor Client puede

ejecutar portlets estándar más nuevos (que cumplan con JSR 168) de forma que los portlets que no

utilizan ninguna función específica de Portal o función específica de Eclipse se puedan ejecutar en

cualquiera de ellos. Pero el entorno de Eclipse sigue siendo más flexible y complejo de forma que aún se

debe añadir información de página y diseño adicional a la que Portal conserva a fin de describir de

forma precisa el diseño de los elementos de Eclipse.

Utilización de la plantilla de ejemplo MyClient de IBM Lotus Expeditor

Como parte de Network Client Installer, puede utilizar la plantilla MyClient que se añade al servidor de

Portal como ayuda para desplegar aplicaciones compuestas.

Al crear una nueva aplicación utilizando esta plantilla, la plantilla crea automáticamente una página de

contribución de entorno de trabajo. Utilice esta página para poner en el cliente portlets de proxy de

administración con parámetros que definen extensiones dinámicas. Los portlets de Administración Eclipse

personalizada del entorno de trabajo de cliente rico y Administración de aplicación nativa de entorno de

trabajo de cliente rico son ejemplos de portlets que generan extensiones dinámicas. Esta página se marca

como oculta de forma predeterminada, de modo que si desea contribuir en la interfaz de usuario de

Lotus Expeditor Client utilizando esta plantilla, deberá crear otra página y poner el contenido en dicha

página.

Configuración del diseño de interfaz de usuario de cliente

El portal tiene un conjunto de propiedades de página que él mismo utiliza y tiene una GUI para

editarlas.

El servidor permite utilizar para una página las propiedades adicionales que sean necesarias para la

administración de cliente y tiene una GUI de edición de parámetros de página genérica, pero requiere

que se conozca la ortografía exacta de cada nombre de parámetro y que se asegure manualmente el

cumplimiento de las restricciones en los valores.

Dado que los parámetros se procesan de forma remota en un cliente, los errores pueden ser difíciles de

diagnosticar y para ello se puede tener que emplear mucho tiempo. Parte del portlet de Administración

de diseño de cliente rico consiste en proporcionar una GUI para editar los nuevos parámetros de página

añadidos a fin de utilizarse en Portal Administered Client. Esta GUI proporciona títulos descriptivos y

asegura que se cumplan las restricciones.

El manejo de los elementos de producción de contenido es más complicado. Para el diseño en Portal,

debe haber una instancia de portlet para representar cada instancia de vista bajo Eclipse. Este portlet

sustituto tendrá parámetros para la información de diseño adicional y se proyectará como una vista de

Eclipse en el cliente. Hay un conjunto estándar de parámetros que el portlet de Administración de diseño

de cliente rico creará y editará para cualquier portlet. Además de eso, el portlet sustituto debe ser un


proxy de administración con posibilidades de configuración propias en lugar de ser simplemente un

marcador basado enteramente en el portlet de Administración de diseño de cliente rico.

Utilización del portlet de Administración del diseño del cliente ricos

El portlet de Administración del diseño del cliente rico es una extensión del personalizador de páginas de

Portal que se utilizar para gestionar metadatos comunes específicos de cliente rico.

Puede incluir estos datos en cualquier portlet de cualquier página como preferencias de portlet. Una

aplicación típica con una o varias páginas puede incluir instancias de varios tipos de portlets. Los proxies

de marcador y administrador sirven para establecer la posición de los portlets en las páginas que se

proyectan como vistas y perspectivas en el cliente. Los portlets JSR168 también se proyectan como vistas

pero además pueden tener equivalentes del lado del cliente que se ejecuten en el contenedor de portlet.

Dado que los portlets JSR168 no se tienen que instrumentar de forma explícita para gestionar datos

específicos de cliente rico, el mismo portlet que no conoce el cliente rico puede servir de proxy de

administración para versiones desplegadas en el cliente rico y se puede utilizar como portlet ″normal″ en

el servidor para entregarse a través de un navegador. El portlet de Administración del diseño del cliente

rico no gestionará atributos específicos de vista tales como conectar propiedades/acciones o ver la

configuración. Si esto es necesario para una vista determinada, se necesitará un proxy de administración

adecuadamente programado.

El portlet de Administración del diseño del cliente rico no gestiona atributos específicos de vista tales

como conectar propiedades y acciones o ver la configuración. Si esto es necesario para una vista

determinada, deberá utilizar un proxy de administración.

El portlet de Administración de diseño de cliente rico maneja los parámetros que son comunes a todas las

perspectivas y vistas:

Propiedades de página

Se definen una vez en cada página y se almacenan en los parámetros de Portal de la página.

Portlets de página

Es una lista de portlets de la página y se genera cuando se necesita basándose en la configuración

de diseño de página actual.

Propiedades de cliente rico

Describen las propiedades de ejecución de una vista de Eclipse en el cliente. Se almacenan en los

valores de portlet y los datos de portlet.

Requisitos de característica

Son características prerrequisito que el cliente necesitará antes de iniciar la vista de destino. Se

almacenan en los valores de portlet y los datos de portlet.

Propiedades de diseño

Son los parámetros adicionales necesarios para explicar el hecho de que el diseño de Eclipse sea

más granular y complejo que el de Portal. Se almacenan en valores de portlet y datos de portlet.

Antes de empezar, asegúrese de que el portlet de Administración del diseño del cliente rico esté instalado

en el servidor de portlet. Normalmente los portlets se instalan ejecutando un instalador apropiado bajo el

directorio /nci del CD del producto. Los portlets se encuentran en los directorios bajo /nci/portal y se

pueden instalar manualmente utilizando el diálogo de administración de Portal para instalar archivos

war de /nci/portal/portlets o ejecutando scripts xmlaccess bajo /nci/portal/scripts. Además, debe haber

creado anteriormente una estructura de página para representar una aplicación destinada a la

configuración de cliente.

Administración parámetros de página específicos de cliente rico:

Puede editar parámetros de página que sean aplicables a clientes ricos. Una vez que haya cambiado y

almacenado los parámetros, el software de cliente puede acceder y procesar los cambios.


Siga estos pasos para administrar parámetros de página que son específicos del entorno de cliente

habilitado administrado por Portal.

1. Inicie la sesión en WebSphere Portal como administrador.

2. Pulse Administración en la barra de herramientas de portal.

3. En el árbol de navegación, pulse Interfaz de usuario de portal y, a continuación, Gestionar páginas.

4. Navegue al diseño de la página de destino.

5. Pulse la pestaña Cliente rico. Se visualizan los parámetros de página que se pueden cambiar, junto

con los valores actuales.

6. Cambie los parámetros de la sección Parámetros de página.

7. Pulse Aceptar para guardar los cambios.

Los parámetros de página específicos de cliente rico se cambian y se almacenan, preparados para que el

software de cliente acceda a ellos.

Propiedades de página

El servidor de portal y el manejador de topología del cliente heredan automáticamente las propiedades

de página de las páginas predecesoras. El portlet de Administración del diseño del cliente rico no

reconoce ni utiliza la información de herencia. Cualquier parámetro que cambie más determinados

parámetros necesarios se escriben siempre para la página en la que se entran. Esto es diferente del valor

de parámetro de página de servidor de Portal que indica la herencia y permite que cualquier valor que

haya cambiado vuelva al valor heredado.

A continuación se proporciona información detallada sobre los campos encontrados en esta sección de la

página de propiedades de página. Los botones de selección Visible y Oculta seleccionan entre dos

estados que se excluyen mutuamente para visualizar la perspectiva representada por esta página.

Visible

Indica que la perspectiva se crea y puede estar accesible mediante el navegador y/o el iniciador.

El acceso a través del navegador en el cliente está controlado por un parámetro que no se

configura mediante este portlet. Se puede poner un parámetro denominado

com.ibm.rcp.useNavigator en la etiqueta raíz de la aplicación que lo contiene. Si este parámetro

está presente y el valor está establecido en ″true″, todas las perspectivas y vistas visibles

proyectadas de las páginas y los portlets estarán disponibles a través del navegador en el cliente.

Para habilitar la vista de navegador, utilice Administración de servidor de portal → → Interfaz de

usuario de portal → Gestionar páginas → Raíz de contenido → Raíz de aplicación → Editar

propiedades de página (icono de página) para la aplicación destino → Opciones avanzadas →

Deseo establecer los parámetros. Añada el nuevo parámetro com.ibm.rcp.useNavigator con un

valor de true.

v Añadir al iniciador - Si se selecciona, la perspectiva representada por esta página se añade al

iniciador en la interfaz de usuario del cliente.

v Abrir automáticamente cuando se inicia la aplicación - La perspectiva proyectada se abre sin

que sea necesaria ninguna acción del usuario. Esto sólo es aplicable si se ha seleccionado

también Añadir al iniciador.

Oculta

Indica que la perspectiva no se muestra en el navegador ni en el iniciador. Se debe seleccionar

cuando la página tiene portlets de proxy de administración con parámetros que definen

extensiones dinámicas en el cliente. Los portlets de Administración Eclipse personalizada del

entorno de trabajo de cliente rico y Administración de aplicación nativa de entorno de trabajo de

cliente rico son ejemplos de portlets que generan extensiones dinámicas.


v Icono para el conmutador de aplicaciones - Especifica la vía de acceso a un icono de marca de

aplicación que se especifica en relación a la aplicación WebSphere Portal base. Lo utiliza el

conmutador de aplicaciones para representar la perspectiva y se almacena localmente en la

memoria caché del cliente.

v Actividades - Especifica qué actividades se deben incluir en la perspectiva cuando se inicia en

el cliente. Los valores son los identificadores exclusivos de las extensiones de actividad de

Eclipse. Cuando hay más de un valor, separe los valores con un punto y coma.

v

Alias de página – Especifica un identificador clave que le permite acceder a la página

mediante programa durante la ejecución de Expeditor.

v Carpeta predeterminada para las vistas no especificadas en el diseño - Define la carpeta

predeterminada en la que se deben visualizar las vistas que no tienen un ID de carpeta

asociado especificado en las propiedades de portlet.

La tabla siguiente lista los parámetros de página:

Tabla 33.

Parámetro de página Etiqueta de línea de GUI Descripción

com.ibm.rcp.activities Actividades

com.ibm.rcp.defaultFolder Carpeta predeterminada para vistas

no especificadas en el diseño

com.ibm.portal.PageIcon Icono para conmutador de

aplicaciones

Igual que el icono configurable con la

interfaz de administración normal en

Portal 6.0.

com.ibm.rcp.launcher Añadir al iniciador Booleano

com.ibm.rcp.autoStart Abrir automáticamente cuando se

inicia la aplicación

Booleano

com.ibm.rcp.hidden Oculta Booleano

com.ibm.rcp.useNavigator Booleano.

Creación de una copia del marcador de vista de cliente rico antes de añadirlo a una página:

Puede crear una copia del marcador de vista de cliente rico y utilizarla para cualquier vista que no

necesite parámetros personalizados. También se utiliza el marcador para la vista de portlet.

Para crear una copia de un marcador de vista de cliente rico en una perspectiva:

1. Asegúrese de que el portlet de Administración de diseño de cliente rico esté instalado correctamente

en WebSphere Portal.

2. Inicie la sesión en WebSphere Portal utilizando credenciales del administrador.

3. Pulse Administración bajo Enlaces a productos.

4. Expanda Gestión de portlets y pulse Portlets.

5. Localice el portlet denominado Marcador de vista de cliente rico.

Consejo: Para buscar rápidamente el marcador de vista de cliente rico, seleccione la búsqueda

predeterminada Empieza por en el campo Buscar por y escriba r antes de pulsar el campo

Buscar.

6. Pulse el icono de copia de portlet para crear una copia. Conceptos relacionados

“Adición del marcador de vista del cliente rico a una página” en la página 230Puede añadir el Marcador de vista de cliente rico a una página para que la página seleccionada tenga

un portlet adicional para representar una vista de cliente rico.


||

Adición del marcador de vista del cliente rico a una página:

Puede añadir el Marcador de vista de cliente rico a una página para que la página seleccionada tenga un

portlet adicional para representar una vista de cliente rico.

Siga estos pasos para añadir el marcador de vista de cliente rico a una página:




4. Navegue por las páginas o busque la página de destino hasta que aparezca en la lista de páginas.

5. Pulse el icono de edición del diseño de página (el lápiz) en la línea que lista la página de destino.

6. Pulse +Añadir portlets.

7. Desplácese o busque hasta que se muestre el portlet deseado en la lista.

8. Habilite el recuadro situado antes del título de portlet.


10. Pulse Hecho para salir de la edición del diseño de página.

Ahora el marcador de vista de cliente rico aparece en el diseño de página.

Edición de propiedades de cliente rico comunes para un portlet en una página:

Puede administrar propiedades de cliente rico para un portlet en una página. El conjunto de propiedades

a editar es el mismo para todos los portlets.

Siga estos pasos para editar las propiedades de cliente rico.




4. Navegue por las páginas o busque la página de destino hasta que aparezca en la lista de páginas.

5. Pulse el icono de edición del diseño de página (el lápiz) en la línea que lista la página de destino.

6. Pulse la pestaña Cliente rico.

7. Desplácese o busque hasta que se muestre el portlet deseado en la lista. Este apartado proporciona

una lista de los portlets en la página actual. El Título de portlet mostrado es para el portlet (es decir,

el portlet concreto) y es el mismo para todos los establecimientos de ese portlet en todas las páginas.

Cada portlet puede tener una descripción exclusiva denominada Descripción de instancia de

portlet.

8. Habilite el recuadro situado antes del título de portlet.

9. Al pulsar el icono de configuración (llave mecánica) irá a una página para modificar las propiedades

asociadas con el portlet seleccionado y que son aplicables a una vista de cliente.

Al pulsar en un icono de edición (lápiz) irá a una página similar para editar las propiedades de

portlet pero los cambios se almacenarán como datos de instancia de portlet para esta página en lugar

de valores del portlet. Estos iconos no ponen el portlet de Administración de diseño de cliente rico

en las modalidades respectivas; representan la operación lógica del portlet de Administración de

diseño de cliente rico en relación a los datos para el portlet de destino.


11. Pulse Hecho para salir de la edición del diseño de página.

Los parámetros de cliente rico para el portlet de destino se cambian y se almacenan, preparados para que

el software de cliente acceda a ellos.

La tabla siguiente lista los atributos de vista que puede editar.


Nota: Esta página de portlet también añade el campo de descripción de instancia proporcionado en la

lista anterior de portlets presentados en la primera página del portlet

Las propiedades de este apartado representan características de una vista de Eclipse. Los valores no son

arbitrarios pero deben reflejar las características reales de la entidad correspondiente en el cliente.

Descripción de instancia

Se trata de un campo opcional que se puede utilizar para hacer distinciones entre varias

instancias del mismo portlet en una página. Son metadatos utilizados para la administración

utilizando el portlet de Administración de diseño del cliente rico y no se visualizan en el cliente.

Tipo de extensión

Indica cómo procesará el manejador de topología del cliente los parámetros del portlet. Este

campo no se puede editar pero el valor controla cómo procesa el portlet de Administración de

diseño del cliente rico determinados campos de formato. Los únicos valores reconocidos son:

Vista sencilla

El portlet representa una vista descrita sólo por el ID de vista de Eclipse. Es el valor

correcto para un portlet que representa una vista SWT (Standard Widgit Toolkit) en el

cliente.

Portlet local

El portlet representa un portlet estándar (que cumple con JSR 168) que se ejecuta

localmente en el contenedor de portlet en el cliente. La vista configurada aquí es en

realidad una instancia del visor de portlet del cliente que se conecta al portlet local

mediante un URL (raíz de contexto).

Portlet WSRP

El portlet representa una instancia del visor de portlet del cliente y ese visor se conecta a

un portlet remoto en un servidor. La conexión de realiza utilizando los parámetros

establecidos por el portlet de proxy de administración de WSRP.

Extensión dinámica

El portlet representa una extensión dinámica donde la corriente XML que define la

extensión la proporciona un portlet de proxy de administración en lugar de que la

construya el manejador de topología. Los portlets de Extensión de Eclipse personalizada

del entorno de trabajo del cliente rico y Aplicación nativa de entorno de trabajo de cliente

rico son ejemplos de esto.

El tipo de extensión lo utiliza el portlet de Administración de diseño de cliente rico para

controlar la presentación del ID de vista SWT y la raíz de contexto de portlet local como

se describe posteriormente. Esto le permite ver una representación precisa de cómo

procesa los parámetros el Manejador de topología en el cliente.

Los botones de selección permiten seleccionar entre dos tipos de vista que se excluyen mutuamente. Para

cada tipo, el conjunto aplicable de propiedades se lista bajo la línea de selección.

Este portlet representa una vista SWT en el cliente rico

Representa una vista SWT que es la interfaz de nivel básico o más bajo normalmente utilizada

por una aplicación Eclipse.

v ID de vista Eclipse - Identificador exclusivo de la extensión de la vista Eclipse que representa

este portlet.

v Las variaciones se basan en el valor del tipo de extensión. Cuando el portlet de Administración

de diseño de cliente rico detecta que el tipo de extensión es normal (minúsculas), se permite la

edición normal. Cuando otro portlet ha establecido el tipo de extensión en sólo lectura

(mayúsculas), no se permite ningún cambio. La tabla siguiente ilustra las variaciones:


Tabla 34. Tipos de extensión

Tipo de extensión Botón de selección de vista

ID de vista en interfaz de

usuario

Acción de parámetro de ID

de vista

VISTA SENCILLA No se muestra Sólo lectura No se puede cambiar

vista sencilla Seleccionado Se puede editar Añadir o cambiar

PORTLET LOCAL No se muestra No se muestra Suprimir, si está presente

portlet local Se puede seleccionar No se muestra Suprimir, si está presente

portlet wsrp No se muestra No se muestra Suprimir, si está presente

extensión dinámica No se muestra No se muestra Suprimir, si está presente

Existente pero no válido No se muestra Visualización No se puede cambiar

No está presente Se puede seleccionar Se puede editar Cambiar o añadir

Este portlet se ejecuta localmente en el cliente rico

Representa un portlet, que cumple con el estándar JSR 168, que se ejecuta en el contenedor de

portlets incluido en el cliente Expeditor. Si sólo está utilizando interfaces API de portlets

estándares, el portlet puede ser exactamente igual que el que se ejecuta en un servidor de Portal.

Tanto si el portlet es el mismo como si no lo es, se desarrolla para el servidor y, a continuación,

se pone en un paquete para el cliente utilizando la herramienta WAB de Expeditor.

v Raíz de contexto de portlet - Información adicional necesaria para que el visor de portlets de

cliente se conecte al portlet que se ejecuta en el contenedor de portlets de cliente. Un portlet

que se ejecuta en el servidor de portal no tiene una raíz de contexto porque en el servidor un

URL apunta a una página y todos los portlets de la página los agrega el servidor.

v Las variaciones se basan en el valor del tipo de extensión. Cuando RCLAP detecta que el tipo

de extensión es normal (minúsculas), se permite la edición normal. Si otro portlet ha

establecido el tipo de extensión en sólo lectura (mayúsculas), no se permite ningún cambio. La

tabla siguiente ilustra las variaciones:

Tabla 35. Tipos de extensión

Tipo de extensión

Botón de selección de

portlet

Raíz de contexto en

interfaz de usuario

Parámetro de raíz de

contenido

VISTA SENCILLA No se muestra No se muestra No se puede cambiar

vista sencilla Se puede seleccionar No se muestra No se puede cambiar

PORTLET LOCAL No se muestra Sólo lectura No se puede cambiar

portlet local Seleccionado Se puede editar Cambiar o añadir

portlet wsrp No se muestra No se muestra No se puede cambiar

extensión dinámica No se muestra No se muestra No se puede cambiar

Existente pero no válido No se muestra Sólo lectura No se puede cambiar

No está presente Se puede seleccionar Se puede editar Cambiar o añadir

Tabla 36. Parámetros de portlet

Etiqueta de línea Descripción

Vista normal Especifica que el manejador de topología pone la vista normalmente utilizando

los parámetros siguientes:

ID de carpeta ID exclusivo de la carpeta con tabuladores de Eclipse a la que se debe añadir

esta vista cuando se añade al diseño de perspectiva.

Visible cuando se muestra la

perspectiva

Si se selecciona, la vista está visible cuando la aplicación se inicia por primera

vez en el cliente. De lo contrario, se crea un marcador para la misma. Cuando

se abre la vista, ésta aparece en la posición de marcador.


Tabla 36. Parámetros de portlet (continuación)

Etiqueta de línea Descripción

Mostrar la barra de título de vista Si se selecciona, se visualiza la vista resultante normalmente con la barra de

título. Si no se selecciona, se visualiza la vista sin barra de título.

Permitir que esta vista se pueda

desplazar dentro de la perspectiva

Si se selecciona, la vista se puede cerrar o mover.

Añadir esta vista como autónoma Si se selecciona, esta vista se añade como autónoma.

Vista rápida Si se selecciona, se añade la vista al diseño como una vista rápida. Las vistas

rápidas se añaden a la barra de vista rápida en el cliente.

Proporción Parte del área de diseño que este componente debe ocupar basándose en el

componente al que se ha conectado en el diseño. Es el dimensionamiento

basado en Eclipse de los diseños de perspectiva. Si no se especifica, se utiliza

la constante de proporción predeterminada proporcionada por Eclipse. La

proporción es un número decimal en el rango de 0,05 a 0,95.

Por ejemplo, si desea configurar cuatro portlets en una columna y cada uno

con una altura igual, ¿cómo calcula la proporción? Tenga en cuenta que el

parámetro de proporción que establece en un portlet no es la proporción real

de sí mismo, sino la proporción del portlet contiguo que se ha colocado

anteriormente.

Para el primer portlet, no se necesita ninguna proporción porque se encuentra

en la parte superior de todos los portlets. Para el segundo deberá tener una

proporción, pero dado que la proporción se ha establecido para el primero, lo

que puede ocupar 1/4 de espacio de la columna completa, la proporción es

0,25. Para el tercero, deberá tener una proporción para el segundo, lo que

puede ocupar 1/3 del espacio restante, de modo que la proporción es 0,33.

Para este último, deberá tener una proporción para el tercero. En este estado,

sólo quedan 2 portlets, cada uno de los cuales puede ocupar la mitad del

espacio restante, de modo que la proporción debe ser 0,5.

v -

v 0,25

v 0,33

v 0,5

Permitir que esta vista se pueda

cerrar desde su barra de título

Si se selecciona, el usuario de cliente puede cerrar la vista desde la barra de

título. Si no se selecciona, la función de cierre no está presente en la barra de

título. Si no hay ninguna barra de título, la función de cierre no está

disponible.

La tabla siguiente lista los atributos de una vista. Bajo PAA se deben almacenar en valores y/o datos de

instancia exactamente como los reconoce el manejador de topología de cliente. Observe que esta tabla

incluye las propiedades de cliente rico y las propiedades de diseño como se describen más arriba.

Tabla 37. Parámetros de datos de portlet PAA (Manejador de topología)

Parámetro de datos de portlet PAA (Manejador de

topología)

Etiqueta de

línea de

GUI Información adicional

com.ibm.rcp.instanceDescription Descripción

de instancia

No se utiliza en el cliente


Tabla 37. Parámetros de datos de portlet PAA (Manejador de topología) (continuación)

Parámetro de datos de portlet PAA (Manejador de

topología)

Etiqueta de

línea de

GUI Información adicional

com.ibm.rcp.extensionType Tipo de

extensión

Enumerado. Los valores válidos son:

v vista sencilla

v portlet local

v portlet wsrp

v extensión dinámica

com.ibm.rcp.viewId ID de vista

de Eclipse

Como se entra; para excepción ver

com.ibm.rcp.extensionType

com.ibm.rcp.viewId El portlet se

ejecuta

localmente

El cliente utiliza

com.ibm.rcp.portletviewer.portletview

com.ibm.rcp.portletcontainer.contextRoot Raíz de

contexto de

portlet

Visor de portlet no manejador de topología

com.ibm.rcp.fastView Vista rápida Booleano

com.ibm.rcp.folder ID de

carpeta

com.ibm.rcp.visible Visible

cuando se

muestra la

perspectiva

Booleano

com.ibm.rcp.showTitle Mostrar la

barra de

título de

vista

Booleano

com.ibm.rcp.moveable Permitir que

esta vista se

pueda

desplazar

dentro de la

perspectiva

Booleano

com.ibm.rcp.standalone Añadir esta

vista como

autónoma

Booleano

com.ibm.rcp.ratio Proporción

com.ibm.rcp.closeable Permitir que

esta vista se

pueda

cerrar

Booleano

Edición o adición de un requisito de característica para el portlet que representa una vista de Eclipse:

Administre un requisito de característica para el portlet que representa una vista de Eclipse. Esto le

permite especificar las características de Eclipse que son necesarias como prerrequisitos para que este

portlet se presente correctamente en el cliente.

Cada portlet se correlaciona con una vista basada en Eclipse (vista SWT) y las características necesarias

para entrar en dicha vista se deben cargar primero en el cliente. Las características que especifique se

cargarán automáticamente utilizando el Gestor de actualizaciones de Eclipse desde el URL especificado.


Los pasos suponen que ha puesto portlets destinados a representar vistas en el cliente rico.





5. Pulse la pestaña Cliente rico. Se visualizan los parámetros de página y una lista de portlets.

6. Pulse el icono de configuración (llave inglesa) o de edición (lápiz) en la línea del portlet cuyos

prerrequisitos se deben cambiar. Se visualiza la página para modificar las propiedades de cliente rico

del portlet de destino.

7. En la sección Requisitos de característica, pulse Añadir o el icono de modificación en la línea para

un ID de característica existente. Se visualiza la página para editar las propiedades de un requisito

de característica con todos los campos vacíos o llenos de un requisito específico, en función de si se

ha seleccionado añadir o modificar.

8. Cambie los campos de entrada como sea apropiado.

9. Pulse un botón de acción para guardar los cambios.

10. Pulse Aceptar o Hecho para finalizar y volver a las propiedades de portlet. Pulse Añadir más, si

existe, para crear otro requisito de característica.

Los parámetros de requisitos de característica de cliente rico para el portlet de destino se cambian y se

almacenan, preparados para que el software de cliente acceda a ellos.

Nota: Si la versión de una característica se modifica por una nueva versión del editor de Portal, es

posible que sea necesario reiniciar la Aplicación compuesta cuando se cargue por primera vez

desde el cliente. Esto permite que se produzca la activación de la nueva versión de la característica

en el cliente.

Al añadir o modificar una característica están disponibles los siguientes parámetros de característica:

ID de característica

Define el ID de Eclipse para la característica prerrequisito necesaria.

Versión de la característica

Define el número de versión deseado de la característica necesaria.

Norma para coincidencia

Define el algoritmo de filtro de versión utilizado por el gestor de actualizaciones de Eclipse. Sólo

instala o actualiza el ID de característica especificado si encuentra uno cuya versión se compara

con la versión especificada de acuerdo con la norma especificada para la coincidencia. El recuadro

de lista de selección contiene los valores siguientes:

perfect

La versión real debe ser una coincidencia exacta de la versión especificada.

equivalent

La versión real debe ser la misma que la versión especificada o debe estar en un nivel de

servicio más alto (los niveles de versión principal y secundario deben ser iguales a la

versión especificada).

compatibles


servicio más alto o un nivel secundario más alto (el nivel principal debe ser igual a la

versión especificada).

greaterOrEqual


servicio más alto o un nivel secundario más alto o nivel principal más alto.


URL de suministro

Especifica el URL del sitio de instalación/actualización de Eclipse donde el cliente debe captar

esta característica necesaria. Si no se especifica, el componente de suministro del cliente

proporcionará un valor predeterminado.

La tabla siguiente muestra los formatos clave de los requisitos, utilizando los datos de ejemplo anteriores.

El sufijo numérico de los nombres de parámetro de característica sirve para asociar los parámetros para

cada característica y permiten varias características.

Tabla 38. Parámetros

Parámetro de datos de portlet PAA

(Gestor de requisitos) Etiqueta de línea de GUI Información adicional

id.Feature_1 ID de característica

version.Feature_1 Versión de la característica

match.Feature_1 Norma para coincidencia

url.Feature_1 URL de suministro

shared.Feature_1 Valor booleano donde true

(verdadero) significa poner en una

ubicación compartida y false (falso)

significa instalar como específico de

usuario.

remove.Feature_1 Valor booleano donde true significa

eliminar la característica.

Eliminación de un requisito de característica para el portlet que representa una vista de Eclipse:

Puede suprimir requisitos de característica para una vista de cliente rico de una perspectiva como la

representa un portlet en una página.

Los pasos suponen que ha puesto portlets destinados a representar vistas en el cliente rico.





5. Pulse la pestaña Cliente rico. Se visualizan los parámetros de página y una lista de portlets.

6. Pulse el icono de configuración (llave inglesa) o edición (lápiz) en la línea del portlet cuyos

prerrequisitos se deben cambiar. Se visualiza la página para editar las propiedades de cliente rico del

portlet de destino.

7. En la sección Requisitos de característica, pulse el icono de supresión (cubo de basura) en la línea

correspondiente a un ID de característica existente. Se le solicitará que confirme la acción de

supresión. Pulse Sí para suprimir el requisito de característica. Se guardan los cambios.

El requisito de característica de cliente rico para el portlet de destino se elimina, preparado para que el

software cliente acceda a la nueva configuración. Esto no hace que la característica se suprima del cliente

si ya se ha instalado. Simplemente la elimina de la lista de esta vista.

Utilización del portlet de Administración de Navegador gestionado

El portlet de Administración de Navegador gestionado permite a WebSphere Portal gestionar instancias

de la vista de Navegador gestionado del cliente de un modo central.

Cada instancia del portlet de Administración de Navegador gestionado representa una instancia del

Navegador gestionado en Lotus Expeditor Client. Se pueden poner varias instancias del portlet de


Administración de Navegador gestionado en una sola página de WebSphere Portal para agregar varias

instancias diferenciadas del Navegador gestionado en una perspectiva de Eclipse. El portlet de

Administración de Navegador gestionado permite a los administradores de WebSphere Portal controlar el

acceso a las funciones del Navegador gestionado basándose en los roles de usuario. Cuando se visualiza

desde un agente que permite ejecutar HTML, el portlet proporciona una interfaz para configurar la

instancia de navegador del lado del cliente.

Puede realizar las siguientes tareas con el portlet de Administración de Navegador gestionado:

v “Creación de una instancia de un portlet de Administración de Navegador gestionado en una

perspectiva”

v “Creación de una conexión en el lado del cliente entre el Navegador gestionado y otro portlet con

capacidad de conexiones” en la página 240

v “Utilización del portlet de Administración de Navegador gestionado para ejecutar una aplicación Web

local” en la página 242


“Instalación del portlet de Administración de Navegador gestionado”Instale el portlet de Administrador de Navegador gestionado en un WebSphere Portal Server.

Instalación del portlet de Administración de Navegador gestionado:

Instale el portlet de Administrador de Navegador gestionado en un WebSphere Portal Server.

El instalador de cliente basado en servidor Lotus Expeditor Client instala los portlets. Consulte el

apartado “Instalación con Network Client Installer” en la página 33 para obtener información sobre cómo

instalar un portlet.

Creación de una instancia de un portlet de Administración de Navegador gestionado en una

perspectiva:

Puede crear una nueva instancia del portlet de Administración de Navegador gestionado y configurarla

para representar la instancia de navegador que se agrega en la perspectiva.

Para crear una instancia de un Navegador gestionado en una perspectiva:

1. Asegúrese de que el portlet de Administración de Navegador gestionado esté instalado

correctamente en WebSphere Portal.




5. Localice el portlet denominado Navegador gestionado.

Consejo: Para buscar rápidamente el portlet Navegador gestionado, seleccione Título contiene en el

campo Buscar por y especifique Navegador gestionado en el campo Buscar.

6. Pulse el icono de copia de portlet para crear una copia.

7. Déle el nombre apropiado a la copia del portlet y pulse Aceptar.

8. Ponga la nueva copia en la página de perspectiva apropiada.

9. Pulse la flecha abajo de Portal y seleccione Configurar en el menú desplegable.

10. Configure los valores de navegador. Consulte el apartado “Valores de Navegador gestionado” en la

página 238 para obtener una lista de los valores de navegador que puede editar.

11. Pulse Someter para guardar los cambios y volver a la modalidad de vista.


Valores de Navegador gestionado

Puede editar los siguientes valores de Navegador gestionado.

Tabla 39. Valores generales de Navegador gestionado

Elemento de configuración Descripción Valores

Navegador Controla qué motor de navegador se utiliza

para presentar las páginas Web.

MSIE – Microsoft Internet Explorer

Mozilla – Navegador Mozzia

Platforma – Plataforma predeterminada

URL inicial URL que el navegador debe abrir en el

arranque.

Cualquier dirección de URL válida

El URL apunta a la

aplicación web local

Define si el URL apunta a una aplicación

Web local.

Sí/No

Utilizar página de inicio

del navegador

Determina si la página de inicio del

navegador subyacente debe alterar el URL

inicial especificado.

Sí/No

Estilo de ventana

emergente

Determina el estilo de ventana emergente

para la nueva ventana.

Predeterminado/Emergente/Incorporado

Tabla 40. Valores de interfaz de usuario de Navegador gestionado


Mostrar URL Determina si se debe visualizar la barra de

dirección.

Sí/No

Mostrar barra de

herramientas

Determina si se debe visualizar la barra de

herramientas del navegador.

Sí/No

Botones atrás y adelante Determina si se deben visualizar los botones

Atrás y Adelante.

Sí/No

Mostrar botón para

imprimir

Determina si se debe visualizar el botón

Imprimir.

Sí/No

Mostrar inicio Determina si se debe visualizar el botón

Inicio.

Sí/No

Mostrar marcadores Determina si se debe visualizar el icono de

favoritos/marcadores.

Sí/No

Mostrar control de página Determina si se deben visualizar los botones

Detener/Renovar página.

Sí/No

Tabla 41. Valores de seguridad de Navegador gestionado


Permitir ejecución de script Determina si una página Web puede

ejecutar JavaScript

Sí/No

Lista de dominios de URL Lista de dominios de URL que son una lista

blanca o una lista negra.

Una lista de URL, entrados uno por

línea.


Tabla 41. Valores de seguridad de Navegador gestionado (continuación)


Permiso de dominios de

URL

Determina si los URL especificados en la

Lista de dominios de URL constituyen una

lista negra (cuando es verdadero) o una lista

blanca.

Si la lista de dominios se define como una

lista blanca, el navegador sólo podrá

navegar a los URL listados.


lista negra, el navegador puede navegar a

cualquier URL que no esté en la lista.

Permitir sólo estos URL/Bloquear estos

URL.

Lista de dominios

emergentes

Lista de dominios de URL que constituye

una lista blanca o una lista negra que define

sitios que pueden mostrar ventanas

emergentes.

Una lista de URL, entrados uno por

línea.

Permisos de dominios

emergentes

Determina si la lista de dominios

especificada en la Lista de dominios

emergentes es una lista negra (cuando es

verdadero) o una lista blanca.


lista blanca, el navegador sólo permitirá

ventanas emergentes desde esos sitios

listados.


lista negra, el navegador permite ventanas

emergentes desde todos los sitios excepto

desde esos sitios listados.

Permitir sólo estos URL/Bloquear estos

URL.

Habilitar applets Determina si se deben soportar applets

Java2.

Sí/No

Habilitar marcadores Determina si están habilitadas funciones de

marcador.

Sí/No

Dominios de descarga

controlados

Lista de dominios para restringir descargas

de archivos no solicitadas.

Lista de URL, entrados uno por línea.

Vía de descarga controlada Vía de acceso local para guardar el archivo

de descarga en dominios definidos por

Dominios de descarga controlados.

Serie

Permitir que la descarga

sobrescriba

Determina si se permite una nueva descarga

para escribir encima de un archivo existente

con el mismo nombre en el sistema de

archivos.

Sí/No

Tabla 42. Valores de proxy de Navegador gestionado


URL de configuración

automática de proxy

Especifica el URL de configuración de proxy

automática. Si se establece este elemento, se

ignorarán otros valores de proxy.

Serie


Tabla 42. Valores de proxy de Navegador gestionado (continuación)


Servidor proxy Especifica el servidor proxy unificado. Si se

establece este elemento, se ignorarán los

proxies para el protocolo de red

independiente (Servidor proxy HTTP,

Puerto de proxy HTTP, Servidor proxy

FTP, Puerto de proxy FTP y Servidor proxy

SSL).

Serie

Puerto de proxy Especifica el puerto de proxy unificado. Si

se establece el Servidor proxy, se utilizará

este valor junto con el valor del elemento

Servidor proxy para todos los protocolos de

red.

Entero

Servidor proxy HTTP Especifica el servidor proxy para el

protocolo HTTP. Este elemento de valor

funciona cuando URL de configuración

automática de proxy y Servidor proxy no se

han establecido.

Serie

Puerto de proxy HTTP Especifica el puerto proxy para el protocolo

HTTP.

Entero

Servidor proxy FTP Especifica el servidor proxy para el

protocolo FTP. Este elemento de valor

funciona cuando URL de configuración

automática de proxy y Servidor proxy no se

han establecido.

Serie

Puerto de proxy FTP Especifica el puerto proxy para el protocolo

FTP.

Entero

Servidor proxy SSL Especifica el servidor proxy utilizado para

SSL. Este elemento de valor sólo funciona

cuando URL de configuración automática

de proxy y Servidor proxy no se han

establecido.

Serie

Puerto de proxy SSL Especifica el puerto proxy para el protocolo

SSL.

Entero

Servidor proxy Socks Especifica la dirección del servidor proxy

Socks. Este elemento de valor sólo funciona

cuando URL de configuración automática

de proxy y Servidor proxy no se han

establecido.

Serie

Puerto de proxy Socks Especifica el puerto de proxy para el

protocolo Socks.

Entero

Dominios que el proxy

ignora

Especifica una lista de dominios que no

necesitan pasar por el servidor proxy.

Lista de URL, entrados uno por línea.

Creación de una conexión en el lado del cliente entre el Navegador gestionado y otro portlet con

capacidad de conexiones:

Puede conectar el portlet de Administración de Navegador gestionado con otro portlet.

Las conexiones permiten que se comuniquen los portlets. Se utilizan para guardar transferencias de

propiedades entre portlets.


El otro portlet debe representar una vista de Eclipse en el lado del cliente o ser un portlet JSR 168 que

esté destinado a ejecutarse en el contenedor JSR 168 del lado del cliente.

Para conectar el portlet de Administración de Navegador gestionado a otro portlet:

1. Asegúrese de que ya se han creado instancias de los portlets de Administración de Navegador

gestionado.

2. Cree otro portlet con un WSDL que defina las propiedades de conexión que se hayan instalado en el

servidor de Portal y registrado apropiadamente en el intermediario de propiedades.




6. Localice el portlet denominado Navegador gestionado.

Consejo: Para buscar rápidamente el portlet Navegador gestionado, seleccione Título contiene en el

campo Buscar por y especifique Navegador gestionado en el campo Buscar.




10. Ponga una instancia de otro portlet con capacidad de conexiones en la misma página.

11. Edite el diseño de página.

12. En la edición de diseño de página, pulse la pestaña Conexiones.

13. Elija un portlet de origen.

14. Elija una propiedad del portlet de origen.

15. Elija un portlet de destino.

16. Elija una acción de destino.

17. Pulse Hecho para completar el proceso.

Propiedades de salida del Navegador gestionado para 6.1.1 -

El portlet Navegador gestionado proporciona las siguientes propiedades de entrada y salida – por favor,

tenga presente que estas propiedades estarán en desuso en releases futuros:

Tabla 43. Propiedades de salida


DummyGetURLAction Envía una notificación al usuario cuando se modifica el URL del

navegador.

DummyGetTitleAction Envía una notificación al usuario cuando se modifica el título.

DummyOpenWindowAction Envía una notificación al usuario cuando se abre una nueva ventana de

navegador.

DummyCloseWindowAction Envía una notificación al usuario cuando se cierra la vista del navegador.

DummyDocumentModelAction Envía una notificación al usuario cuando se carga la página web.

Tabla 44. Propiedades de entrada


setURLAction Establece el URL del navegador y lo carga.

TextAction Establece el texto HTML del navegador.

StopAction Interrumpe la carga de la página actual en el navegador.

SetCookie Establece un cookie en el navegador.


Propiedades de salida del Navegador gestionado para 6.1.2

Lotus Expeditor versión 6.1.2 utiliza tipos de datos estándar. El portlet Navegador gestionado

proporciona las siguientes propiedades de entrada y salida:

Tabla 45. Propiedades de salida


currentURL Envía una notificación al usuario cuando se modifica un URL.

changedTitle Envía una notificación al usuario cuando se modifica el título.

NewViewID Envía una notificación al usuario cuando se abre una nueva vista de

navegador.

ClosedViewID Envía una notificación al usuario cuando se cierra la vista de navegador.

StatusText Envía una notificación al usuario cuando se carga una nueva página web.

DocumentLoadedStatus Envía una notificación al usuario cuando se modifica el estado de una

página.

Tabla 46. Propiedades de entrada


URL Establece el URL de destino a cargar.

HTMLText Establece el contenido de texto HTML de destino a cargar.

StopMessage Detiene la carga de la página web actual.

CookieData Establece datos de cookie con el URL especificado.

Utilización del portlet de Administración de Navegador gestionado para ejecutar una aplicación Web

local:

Puede configurar el portlet de Administración de Navegador gestionado para cargar la aplicación Web.

Para ejecutar una aplicación Web local:

1. Asegúrese de que ya se han creado instancias de los portlets de Administración de Navegador

gestionado.

2. Entre la modalidad de configuración para la instancia del portlet de Administración de Navegador

gestionado.

3. Especifique valores para los campos siguientes.

Navegador

Controla qué motor de navegador se utiliza para presentar las páginas Web. Seleccione en

MSIE (Internet Explorer), Mozilla (navegador Mozilla) o Plataforma (valor predeterminado de

Plataforma).

URL de la página de inicio

Raíz de contexto de la aplicación web local. Este URL debe tener el formato de

http://hostlocal/raízMicontexto o https://hostlocal/raízMicontexto. Si el URL empieza

con el protocolo https://, se supone que se utiliza SSL.

Utilizar página de inicio del navegador

Establézcalo en No. Esto asegura que se utilice el URL de página de inicio como página de

inicio del navegador.


|

||

||

||

||

||

|||

||

||

||||

||

||

||

||

||

|||

|

El URL apunta a una aplicación web local

Establézcalo en Sí.

Estilo de ventana emergente

Especifique el estilo de ventana emergente para la nueva ventana.4. Pulse Someter para guardar los cambios y volver a la modalidad de vista.

Utilización del portlet de Administración de entorno de trabajo

El portlet de Administración de entorno de trabajo permite a WebSphere Portal gestionar elementos con

los que se contribuido en las diversas partes del entorno de trabajo de Lotus Expeditor Client. Estos

portlets proporcionan un modo de hacer contribuciones basadas en rol de usuario en el entorno de

trabajo.

El portlet de Administración de entorno de trabajo le permite gestionar de forma central los elementos de

control que han contribuido en las cuatro áreas siguientes del entorno de trabajo de Lotus Expeditor

Client y acceder a dichos elementos:

v Barra de herramientas

v Barra de estado

v Lanzador de aplicaciones

v Páginas de preferencias

El portlet de Administración de entorno de trabajo soporta la adición de los elementos siguientes como

contribución:

v Aplicaciones nativas

v Modificador de contraseña

v Conmutador de entorno local

v Conmutador de diseño de teclado

v Conclusión

v Terminación de sesión

v Bloqueo

v Reloj

v Lista de tareas

Puede realizar las siguientes tareas con el portlet de Administración de entorno de trabajo:

v “Contribución con una instancia de una aplicación nativa en el iniciador” en la página 244

v “Contribución al entorno de trabajo con la función de bloqueo de pantalla” en la página 245

v “Contribución al entorno de trabajo con la función de cambio de contraseña” en la página 246

v “Contribución al entorno de trabajo con la función de cambio de entorno local” en la página 247

v “Contribución al entorno de trabajo con la función de lista de tareas” en la página 248

v “Contribución al entorno de trabajo con la función de cambio de teclado” en la página 247

v “Contribución al entorno de trabajo con la función de conclusión del sistema” en la página 249

v “Contribución al entorno de trabajo con la función de fin de sesión de sistema” en la página 249

v “Contribución al entorno de trabajo con el reloj de barra de estado” en la página 250

v “Contribución al entorno de trabajo con una extensión de Eclipse dinámica personalizada” en la página

251

v “Asignación de control de acceso a elementos de iniciador” en la página 251 Conceptos relacionados

“Instalación del portlet de Administración de entorno de trabajo en un servidor WebSphere Portal” en

la página 244El instalador de cliente basado en servidor instala los portlets.


Instalación del portlet de Administración de entorno de trabajo en un servidor WebSphere Portal:

El instalador de cliente basado en servidor instala los portlets.

Consulte el apartado “Instalación con Network Client Installer” en la página 33 para obtener información

sobre cómo instalar un portlet.

Contribución con una instancia de una aplicación nativa en el iniciador:

Puede crear una instancia nueva del portlet de Administración de aplicación nativa y configurarla para

representar la aplicación nativa que aparece en el iniciador.

Para contribuir con una instancia de una aplicación nativa en el iniciador, siga estos pasos.

1. Asegúrese de que como mínimo se haya instalado correctamente un portlet de Administración de

entorno de trabajo en WebSphere Portal.




5. Localice el portlet denominado Administración de aplicación nativa de entorno de trabajo.

Consejo: Para encontrar rápidamente el portlet de Administración de aplicación nativa de entorno

de trabajo, seleccione El título empieza por en el campo Buscar por y especifique Cliente

rico en el campo Buscar.



8. Ponga la nueva copia en la página de contribución de entorno de trabajo.


10. Configure los valores de aplicación nativos.

Tabla 47. Valores de aplicación nativos

Valor Descripción

Etiqueta Etiqueta predeterminada para la aplicación. Si no se establece para la etiqueta un valor

localizable adecuado, se utiliza este valor. La etiqueta es lo que aparece en el iniciador

como título de la aplicación. No está permitido que los caracteres & y comillas dobles (″)

formen parte de la serie de etiqueta.

Vía de acceso de

iniciador

Define la ubicación en el iniciador, donde debe aparecer la aplicación. La vía de acceso

de iniciador es una delimitación jerárquica de las carpetas padre del elemento de

iniciador, separadas por barras inclinadas invertidas. Cada elemento de la vía de acceso

corresponde al nombre de una carpeta que se debe visualizar en el iniciador, desde la

raíz hasta el elemento de iniciador final.

Lanzar automáticamente

al arrancar

Si es verdadero, la aplicación se inicia inmediatamente después de que se haya cargado

el widget de iniciador. Si se establecen varias aplicaciones en lanzamiento automático, no

hay un orden de ejecución bien definido.

Permitir varias instancias Si es verdadero, cualquier intento de lanzar una aplicación más de una vez hará que se

abran varias instancias de la misma aplicación. Si es falso, cualquier intento de lanzar

más de una instancia de la aplicación hará que la ventana de instancia de aplicación

existente se ponga en primer plano, si aún está abierta.

Mandato Mandato utilizado para lanzar la aplicación. Se especifica un mandato independiente

para ejecutarse bajo windows y Linux. El mandato incluye la vía de acceso a la imagen

ejecutable más cualquier parámetro adicional.

Directorio de trabajo Directorio de trabajo de la aplicación, después del arranque.

Entorno Definiciones de variable de entorno disponibles para la aplicación.


Tabla 47. Valores de aplicación nativos (continuación)

Valor Descripción

Modalidad de entorno Controla cómo se fusionarán las definiciones de variable de entorno adicionales con las

variables de entorno existentes:

Añadir Si el entorno original contiene una definición para var1 = A y el nuevo entorno

contiene una definición para var1 = B, el entorno final contiene la definición

Var1 = A;B

Añadir al principio

Si el entorno original contiene una definición para var1 = A y el nuevo entorno


Var1 = B;A

Modificar

Si el entorno original contiene una definición para var1 = A y el nuevo entorno


Var1 = B;

Sustituir

El nuevo entorno sustituirá completamente el entorno anterior. No se realiza

ninguna fusión.

Establecer valores

localizables

El enlace cargará una página similar al siguiente modelo y permitirá al administrador

configurar los valores localizables para la ayuda contextual, la vía de acceso de iniciador

y la etiqueta. Cada fila de la tabla de localización define un idioma soportado, donde

cada columna visualiza un campo que soporta valores localizados. La lista de idiomas

soportados depende de los idiomas que soporte la instalación de Portal. Para habilitar la

instalación de Portal para el soporte de idioma adicional, consulte el manual de IBM

WebSphere Portal.

Para entrar valores localizados para un idioma soportado, pulse el icono de edición en la

fila correspondiente a dicho idioma. En la pantalla de edición de valores localizados,

entre los valores localizados para el idioma seleccionado.

11. Asigne al portlet los permisos de acceso apropiados. En el panel de navegación de administración,

expanda Acceso y pulse Permisos de recursos.

12. En la tabla de tipos de recursos, pulse Portlets.

13. Localice la copia del portlet creado anteriormente y pulse en el icono de permisos de acceso para

asignar los permisos apropiados.

Una nueva instancia del portlet de Administración de aplicación nativa se crea y se configura para

representar la aplicación nativa que aparece en el iniciador.

Contribución al entorno de trabajo con la función de bloqueo de pantalla:

Para permitir a los usuarios bloquear la pantalla, coloque el portlet de Administración de bloqueo de

pantalla de entorno de trabajo en la página de Contribución del entorno de trabajo.

Utilice el portlet de Administración de bloqueo de pantalla de entorno de trabajo para añadir una

contribución de botón de barra de herramientas, elemento de barra de herramientas o barra de estado al

entorno de trabajo. El portlet de Administración de bloqueo de pantalla de entorno de trabajo permite a

los usuarios bloquear la pantalla desde el entorno de trabajo.

1. Coloque el portlet de Administración de bloqueo de pantalla de entorno de trabajo en la página de

Contribución de entorno de trabajo y entre en modalidad de configuración para configurar los

valores.

2. Configure los valores para el portlet de Administración de bloqueo de pantalla del entorno de trabajo.

Seleccione la ubicación en el entorno de trabajo donde debe aparecer la función de bloqueo de

pantalla:


v Mostrar como elemento de barra de menús del entorno de trabajo

v Mostrar como icono en la barra de estado del entorno de trabajo

v Mostrar como icono en la barra de herramientas del entorno de trabajo

Marque todas las áreas donde deba aparecer la función de bloqueo de pantalla.

3. Pulse Establecer valores localizables para establecer valores localizables para los campos de Ayuda

contextual y Etiqueta.

4. Para entrar valores localizados para un idioma soportado, pulse el icono de edición en la fila

correspondiente a dicho idioma. En la pantalla de seguimiento (Edición de valores localizables), entre

valores localizados para el idioma seleccionado. Entre el valor localizado para cada campo y pulse

Aceptar.

5. Pulse Aceptar otra vez para volver a la pantalla de configuración.

6. Pulse Establecer opciones avanzadas para establecer las opciones avanzadas asociadas a este portlet.

7. Asigne al portlet los permisos de acceso apropiados. En el panel de navegación de Administración,

expanda Acceso y pulse Permisos de recursos. En la tabla de tipo de recursos, pulse Portlets. Localice

el portlet de Administración de bloqueo de pantalla de entorno de trabajo y pulse el icono de

permisos de acceso para asignar los permisos apropiados.

Se crea una instancia nueva del portlet de Administración de bloqueo de pantalla de entorno de trabajo y

dicha instancia se configura en una página de WebSphere Portal.

Contribución al entorno de trabajo con la función de cambio de contraseña:

Para permitir a los usuarios gestionar contraseñas, coloque el portlet de Administración de cambio de

contraseña del entorno de trabajo en la página de Contribución del entorno de trabajo.

Utilice el portlet de Administración de cambio de contraseña del entorno de trabajo para añadir un botón

de barra de herramientas o una página de preferencias al entorno de trabajo. El portlet de Administración

de cambio de contraseña del entorno de trabajo permite a los usuarios cambiar la contraseña de sistema

operativo desde dentro del entorno de trabajo, opcionalmente sincronizando también la contraseña de

almacenamiento de credenciales principal, si el inicio de sesión único está activo.

Siga estos pasos para añadir la función de cambio de contraseña al entorno de trabajo.

1. Coloque el portlet de Administración de cambio de contraseña del entorno de trabajo en la página de

contribución de entorno de trabajo y entre en modalidad de configuración para configurar los valores.

2. Configure los valores para el portlet de Administración de cambio de contraseña del entorno de

trabajo. Seleccione la ubicación en el entorno de trabajo donde debe aparecer la función de cambio de

contraseña:


v Mostrar como página de preferencias del entorno de trabajo

Marque todas las áreas donde deba aparecer la función de cambio de contraseña.






Aceptar.




expanda Acceso y pulse Permisos de recursos. En la tabla de tipo de recursos, pulse Portlets.


8. Localice el portlet de Administración de cambio de contraseña del entorno de trabajo y pulse el icono

de permisos de acceso para asignar los permisos apropiados.

El portlet de Administración de cambio de contraseña del entorno de trabajo se pone en una página de

WebSphere Portal y se configura con los valores correctos.

Contribución al entorno de trabajo con la función de cambio de entorno local:

Añada la función de cambio de entorno local para permitir a los usuarios gestionar el entorno local del

sistema operativo.

Utilice el portlet de Administración de cambio de entorno local del entorno de trabajo para añadir una

contribución de botón de barra de herramientas, página de preferencias o barra de estado al entorno de

trabajo.

Nota: Si la plataforma de Lotus Expeditor Client es una plataforma basada en Windows, debe reiniciar el

sistema para que el cambio de entorno local entre en vigor. Si la plataforma está basada en Linux,

deberá terminar la sesión e iniciar la sesión otra vez para que el cambio de entorno local entre en

vigor.

Para añadir la función de cambio de entorno local, siga estos pasos:

1. Coloque el portlet de Administración de cambio de entorno local del entorno de trabajo en la página

de Contribución de entorno de trabajo y entre en modalidad de configuración para configurar los

valores.

2. Configure los valores para el portlet de Administración de cambio de entorno local del entorno de

trabajo. Seleccione la ubicación en el entorno de trabajo donde debe aparecer la función de cambio de

entorno local:



v Mostrar como página de preferencias del entorno de trabajo3. Pulse Establecer valores localizables para establecer valores localizables para los campos de Ayuda





Aceptar.





8. Localice el portlet de Administración de cambio de entorno local del entorno de trabajo y pulse el

icono de permisos de acceso para asignar los permisos apropiados.

El portlet de Administración de cambio de entorno local se configura en una página de WebSphere

Portal.

Contribución al entorno de trabajo con la función de cambio de teclado:

Para permitir a los usuarios cambiar el diseño de teclado del sistema operativo, coloque el portlet de

Administración de diseño de teclado de entorno de trabajo en la página de Contribución del entorno de

trabajo.


Utilice el portlet de Administración de diseño de teclado de entorno de trabajo para añadir un botón de

barra de herramientas o una página de preferencias al entorno de trabajo. El portlet de Administración de

diseño de teclado de entorno de trabajo permite a los usuarios cambiar el diseño de teclado del sistema

operativo desde el entorno de trabajo.

1. Coloque el portlet de Administración de diseño de teclado de entorno de trabajo en la página de


valores.

2. Configure los valores para el portlet de Administración de diseño de teclado del entorno de trabajo.

Seleccione la ubicación en el entorno de trabajo donde debe aparecer la función de cambio de teclado:



v Mostrar como página de preferencias del entorno de trabajo

Marque todas las áreas donde deba aparecer la función de cambio de diseño de teclado.






Aceptar.





el portlet de Administración de cambio de diseño de teclado del entorno de trabajo y pulse el icono

de permisos de acceso para asignar los permisos apropiados.

Se crea una nueva instancia del portlet de Administración de cambio de teclado del entorno de trabajo y

dicha instancia se configura en una página de WebSphere Portal.

Contribución al entorno de trabajo con la función de lista de tareas:

Añada la función de lista de tareas para permitir a los usuarios ver una lista de tareas nativas en

ejecución.

Utilice el portlet de Administración de lista de tareas de entorno de trabajo para añadir una contribución

de botón de barra de herramientas o barra de estado al entorno de trabajo.

Para añadir la función de lista de tareas, siga estos pasos:

1. Coloque el portlet de Administración de lista de tareas de entorno de trabajo en la página de


valores.

2. Configure los valores para el portlet de Administración de lista de tareas de entorno de trabajo.

Seleccione la ubicación en el entorno de trabajo donde debe aparecer la función de lista de tareas:

v Mostrar como un elemento en la barra de estado de entorno de trabajo

v Mostrar como icono en la barra de herramientas del entorno de trabajo3. Pulse Establecer valores localizables para establecer valores localizables para los campos de Ayuda





Aceptar.






el portlet de Administración de conectividad planificada de entorno de trabajo y pulse el icono de


Contribución al entorno de trabajo con la función de conclusión del sistema:

Utilice el portlet de función de conclusión del sistema para añadir un botón de barra de herramientas o

una página de preferencias al entorno de trabajo de Lotus Expeditor Client. El portlet de Administración

de conclusión del sistema de entorno de trabajo permite a los usuarios concluir desde el entorno de

trabajo.

Utilice el portlet de Administración de conclusión del sistema de entorno de trabajo para añadir un botón

de barra de herramientas o una página de preferencias al entorno de trabajo. El portlet de Administración

de conclusión del sistema de entorno de trabajo permite a los usuarios concluir el sistema desde el

entorno de trabajo.

Nota: El servicio de entorno de trabajo restringido debe estar habilitado en el cliente para que la

conclusión del sistema de entorno de trabajo se haga efectiva.

1. Ponga el portlet de Administración de conclusión del sistema de entorno de trabajo en la página de


valores.

2. Configure los valores para el portlet de Administración de conclusión del sistema del entorno de

trabajo. Seleccione la ubicación en el entorno de trabajo donde debe aparecer la función de cierre del

sistema:



v Mostrar como un elemento en la barra de menús de entorno de trabajo

Marque todas las áreas donde deba aparecer la función de conclusión.






Aceptar.





el portlet de Administración de conclusión del sistema de entorno de trabajo y pulse el icono de


Se crea una nueva instancia del portlet de Administración de conclusión del sistema de entorno de

trabajo y dicha instancia se configura en una página de WebSphere Portal.


“Servicio de entorno de trabajo restringido” en la página 3Habilite el Servicio de entorno de trabajo restringido para proporcionar un entorno restringido en el

que todos los usuarios de Lotus Expeditor Client estén limitados a las aplicaciones y los servicios de

sistema operativo que, como administrador, haya configurado.

Contribución al entorno de trabajo con la función de fin de sesión de sistema:


Añada la función de fin de sesión de sistema para permitir a los usuarios terminar la sesión en el

sistema.

Utilice el portlet de Administración de fin de sesión del sistema de entorno de trabajo para añadir un

botón de barra de herramientas, barra de menús o barra de estado en el entorno de trabajo.

Nota: El servicio de entorno de trabajo restringido debe estar habilitado para que funcione el portlet de

Administración de fin de sesión del sistema de entorno de trabajo.

Para añadir el fin de sesión del sistema, siga estos pasos:

1. Ponga el portlet de Administración de fin de sesión del sistema de entorno de trabajo en la página de


valores.

2. Configure los valores para el portlet de Administración de fin de sesión del sistema del entorno de

trabajo. Seleccione la ubicación en el entorno de trabajo donde debe aparecer la función de fin de

sesión del sistema:

v Mostrar como icono en la barra de menús del entorno de trabajo


v Mostrar como un elemento en la barra de estado de entorno de trabajo3. Pulse Establecer valores localizables para establecer valores localizables para los campos de Ayuda





Aceptar.





el portlet de Administración de fin de sesión del sistema de entorno de trabajo y pulse el icono de


Se crea una nueva instancia del portlet de Administración de conclusión y dicha instancia se configura en

una página de WebSphere Portal.


“Servicio de entorno de trabajo restringido” en la página 3Habilite el Servicio de entorno de trabajo restringido para proporcionar un entorno restringido en el

que todos los usuarios de Lotus Expeditor Client estén limitados a las aplicaciones y los servicios de

sistema operativo que, como administrador, haya configurado.

Contribución al entorno de trabajo con el reloj de barra de estado:

La contribución con el portlet de Administración de reloj de entorno de trabajo en el entorno de trabajo

permite a los usuarios añadir un reloj digital en la barra de estado del entorno de trabajo.

Para añadir el reloj de barra de estado, siga estos pasos:

1. Coloque el portlet de Administración de reloj de entorno de trabajo en la página de Contribución de

entorno de trabajo y entre en modalidad de configuración para configurar los valores.

2. Configure los valores para el portlet de Administración de reloj de entorno de trabajo.







Aceptar.





8. Localice el portlet de Administración de reloj de entorno de trabajo y pulse el icono de permisos de

acceso para asignar los permisos apropiados.

Se crea una nueva instancia del portlet de Administración de reloj y dicha instancia se configura en una

página de WebSphere Portal.

Contribución al entorno de trabajo con una extensión de Eclipse dinámica personalizada:

Para permitir que los usuarios puedan contribuir con cualquier extensión válida de Eclipse, coloque el

portlet de Administración de extensión de Eclipse personalizada del entorno de trabajo en la página de

contribución de entorno de trabajo.

Para añadir una extensión de Eclipse personalizada, siga estos pasos:

1. Ponga una instancia del portlet de Administración de extensión de Eclipse personalizada del entorno

de trabajo en la página de Contribución de entorno de trabajo y entre en modalidad de configuración

para configurar los valores.

2. Configure los valores para el portlet de Administración de extensión de Eclipse personalizada del

entorno de trabajo. Para definir una extensión de Eclipse válida, proporcione lo siguiente:

ID de paquete de host

ID del plug-in donde se añadirá la extensión.

Definición de extensión de Eclipse

XML de la extensión de Eclipse que se está definiendo. Se pueden definir varias extensiones

utilizando una sola instancia del portlet, suponiendo que todas las extensiones se añaden en

el mismo plug-in.3. Pulse Establecer valores localizables para establecer valores localizables para los campos de Ayuda


Nota: El enlace Establecer valores localizables sólo aparecerá si la definición de extensión de Eclipse

contiene una variable localizable. La definición de extensión contiene variables localizables si

contiene símbolos como %variable%.




Aceptar.





el portlet de Administración de extensión de Eclipse personalizada del entorno de trabajo y pulse el

icono de permisos de acceso para asignar los permisos apropiados.

Se crea una nueva instancia del portlet de Administración de extensión de Eclipse personalizada del

entorno de trabajo y dicha instancia se configura en una página de WebSphere Portal.

Asignación de control de acceso a elementos de iniciador:


La asignación de control de acceso a los elementos de iniciador consiste en asignar el control de acceso a

los portlets del servidor de Portal que representa cada elemento de iniciador. Es lo mismo que asignar el

control de acceso a cualquier portlet.

Nota: Consulte el apartado de Control de acceso en el centro de información de IBM WebSphere Portal for

Multiplatforms en http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp..

Utilización del Portlet de habilitación de visor WSRP de cliente rico

Utilice el Portlet de habilitación de visor WSRP de cliente rico para configurar un portlet WSRP para la

plataforma de Lotus Expeditor Client.

El Portlet de habilitación de visor WSRP de cliente rico es un portlet de proxy para un portlet WSRP que

almacena los metadatos WSRP (la información de productor y descriptor de contexto de portlet WSRP).

Cuando el Portlet de habilitación de visor WSRP de cliente rico se ha configurado y se ha desplegado en

una aplicación compuesta, la aplicación compuesta puede presentar un visor de portlet en la plataforma

de Lotus Expeditor Client que muestre el contenido del portlet WSRP remoto.

WSRP es un estándar de OASIS que define servicios Web interactivos orientados a la presentación entre

aplicaciones habilitadas para WSRP, por ejemplo el servidor de Portal o el entorno de ejecución WSRP en

Lotus Expeditor Client. El entorno de ejecución WSRP recupera el contenido de portlet de los portlets

remotos y procesa la interacción de usuario.

Este tema supone que ya está familiarizado con la especificación WSRP. Para obtener más detalles sobre

la especificación WSRP de OASIS, consulte el sitio web del estándar WSRP de OASIS:

http://oasis-open.org/committees/wsrp.

Si desea desplegar un visor de portlet para el entorno de ejecución de WSRP en el entorno de cliente

administrado por Portal, necesita configurar y desplegar un Portlet de habilitación de visor WSRP de

cliente rico. Utilice el Portlet de habilitación de visor WSRP de cliente rico para buscar portlets remotos

que proporcionen servicios WSRP y compartan los metadatos relacionados con WSRP en una vista de

cliente rico. Los datos adicionales necesarios para el visor de portlet para el entorno de ejecución de

WSRP se configuran utilizando el portlet de Administración de diseño de cliente rico, que se describe en

“Utilización del portlet de Administración del diseño del cliente ricos” en la página 227. Una vez que

haya desplegado un Portlet de habilitación de visor WSRP de cliente rico en una aplicación compuesta y

lo configure para un portlet remoto, el cliente administrado de portal presentará el visor de portlet para

el entorno de ejecución de WSRP mostrando el contenido del portlet remoto.

Nota: Despliegue sólo los portlets que cumplen los requisitos de WSRP con Lotus Expeditor Client.

Aunque pueda especificar un portlet en la línea de mandatos o la interfaz WSRP del servidor de

Portal, no se considera que el portlet satisfaga los requisitos de WSRP. Consulte el sitio web del

estándar de WSRP para obtener información sobre el cumplimiento de requisitos de WSRP. Antes

des desplegar la funcionalidad de WSRP en Lotus Expeditor Client, es mejor intentar utilizar el

proveedor de servicio WSRP en el servidor de gestión.


“Configuración del Portlet de habilitación de visor WSRP de cliente rico”Antes de desplegar el Portlet de habilitación de visor WSRP de cliente rico, éste se debe configurar.

“Despliegue de un portlet de habilitación de visor WSRP de cliente rico” en la página 254Despliegue un portlet de habilitación de componente cliente de WSRP para permitir que Lotus

Expeditor Client acceda mediante WSRP a una instancia de portlet existente configurada por el

consumidor.

Configuración del Portlet de habilitación de visor WSRP de cliente rico:

Antes de desplegar el Portlet de habilitación de visor WSRP de cliente rico, éste se debe configurar.


http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.

http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.

http://oasis-open.org/committees/wsrp

Para configurar el Portlet de habilitación de visor WSRP de cliente rico

1. Asegúrese de que el Portlet de habilitación de visor WSRP de cliente rico se ha instalado

correctamente en WebSphere Portal.




5. Localice el portlet denominado Portlet de habilitación de visor WSRP de cliente rico.

Consejo: Para buscar rápidamente el Portlet de habilitación de visor WSRP de cliente rico, seleccione

Título contiene en el campo Buscar por y especifique Habilitación de visor WSRP de

cliente rico en el campo Buscar.





10. Especifique el URL del documento WSDL (Web Services Description Language) del producto WSRP

(por ejemplo http://MiServidor:puerto/contextRoot/wsdl/wsrp_service.wsdl).

Nota: Si utiliza WebSphere Portal como productor WSRP, consulte Utilización de servicios WSRP

con WebSphere Portal → Tareas de productor → Descripción de servicio WSRP en el centro de

información de WebSphere Portal.

11. Habilita la opción de seguridad para este productor. Asegúrese de estar familiarizado con la

configuración de seguridad del productor WSRP que ha especificado. Seleccione en las opciones de

seguridad siguientes:

Sin seguridad

El productor WSRP no tiene configuración de seguridad.

LTPA El productor WSRP utiliza la señal LTPA para la autenticación. Si el productor WSRP no está

en el servidor de Portal que contiene el Portlet de habilitación de WSRP de cliente rico,

deberá configurar el inicio de sesión único entre estos dos servidores de Portal.

Nota:

v Para la configuración de seguridad para Portal, consulte Utilización de servicios

WSRP con WebSphere Portal → Consideraciones de seguridad para utilizar WSRP

con WebSphere Portal en el centro de información de WebSphere Portal.

v Después de configurar el inicio de sesión único para el servidor de productor WSRP

y el servidor de Portal que incluye el Portlet de habilitación WSRP de cliente rico,

no puede utilizar IP para definir otras configuraciones a fin de identificar estos

servidores.

Señal de nombre de usuario

El productor WSRP utiliza la señal de nombre de usuario para la autenticación. Si selecciona

esta opción, necesitará especificar una cuenta disponible en este servidor de Portal del portlet

de Almacenamiento de credenciales, utilizando el URL en el paso 10 como nombre de

recurso. Teniendo en cuenta que el portlet Almacenamiento de credenciales también

necesitará un ″Nombre de ranura″, se sugiere establecer el mismo nombre para el ″nombre

de recurso″ y el ″nombre de ranura″.12. Pulse Aceptar para ir a la página siguiente.

13. Seleccione el portlet que desea desplegar en la lista de portlets habilitados para WSRP para este

productor. Se visualiza la siguiente página.

14. Especifique las opciones de clonación del lado del cliente. Seleccione en las siguientes opciones:


No se necesita un clon

Todos los visores de portlet WSRP del lado del cliente compartirán una instancia de portlet

remota.

Se necesita un clon

Cada visor de portlet WSRP clonará una nueva instancia de portlet en el productor WSRP.

Nota: Si el productor WSRP es el servidor WebSphere Portal, seleccione No se necesita un clon; de

lo contrario, seleccione Se necesita un clon.

15. Pulse Someter para guardar los cambios y volver a la modalidad de vista.

El portlet de habilitación WSRP de cliente rico se ha configurado y está preparado para desplegarse.

Despliegue de un portlet de habilitación de visor WSRP de cliente rico:

Despliegue un portlet de habilitación de componente cliente de WSRP para permitir que Lotus Expeditor

Client acceda mediante WSRP a una instancia de portlet existente configurada por el consumidor.

Para poder desplegar un visor de habilitación de WSRP, asegúrese de que el portlet de habilitación de

componente de cliente de WSRP esté instalado en el servidor de Portal y que la característica WSRP esté

instalada en Lotus Expeditor Client.

1. Realice los pasos del apartado “Configuración del Portlet de habilitación de visor WSRP de cliente

rico” en la página 252.

2. Añada el portlet de habilitación de visor WSRP de cliente rico a una página de Portal que soporte el

cliente rico y utilice el portlet de Administración del diseño del cliente rico a fin de configurar datos

para la vista de WSRP. Consulte el apartado “Utilización del portlet de Administración del diseño del

cliente ricos” en la página 227 para obtener más información.

Una vez completado, puede ver la instancia de portlet e interactuar con a misma utilizando el visor

WSRP.

Registro

Este apartado describe el registro de portal.

Definición de niveles de control de acceso a Portal

El nivel de acceso que un usuario tiene a los portlets y las páginas alojadas por WebSphere Portal se debe

establecer utilizando las páginas de Administración de WebSphere Portal.

Las aplicaciones que cree para ejecutar en el cliente deben especificar que todos los usuarios autenticados

de WebSphere Portal pueden utilizar los portlets y las páginas que forman la aplicación para que ésta

quede disponible en el cliente.

Para establecer el nivel de acceso para los portlets y las páginas en todos los usuarios autenticados de

WebSphere Portal:

1. En las páginas de Administración de WebSphere Portal, pulse Acceso → Permisos de recursos →

Páginas.

2. Busque las páginas con ″WMC″ para visualizar la página que ha creado.

3. Pulse el icono de clave Asignar acceso de la página que ha creado.

4. Pulse el icono Editar rol para el rol de Usuario y, a continuación, pulse Añadir.

5. Marque todos los usuarios de portal autenticados y, a continuación, pulse Aceptar. Pulse Hecho y, a

continuación, pulse Aceptar para volver a los resultados de búsqueda de página. Pulse Hecho para

volver a la lista de tipos de recursos. Pulse Portlets y, a continuación, busque los portlets con ″WMC″

para volver a los portlets que ha creado.

6. Para cada portlet, establezca el rol Usuario en todos los usuarios de portal autenticados.


Especificación de aplicaciones MyClient

Las aplicaciones que especifique en la categoría MyClient se instalan y actualizan automáticamente

cuando el servidor de Portal administra Lotus Expeditor Client.

Lotus Expeditor Client carga las aplicaciones especificadas en el catálogo que están en la categoría

MyClient.

Gestión de preferencias de cliente rico utilizando el editor de tipo de

política para preferencias de Eclipse

El portlet de Políticas de recurso es una herramienta administrativa de WebSphere Portal que le permite

gestionar conjuntos de parejas de clave y valor.

Lotus Expeditor Client proporciona una extensión al portlet de Políticas de recursos denominado Editor

de tipo de política para preferencias de Eclipse mediante el cual se puede gestionar el cliente

administrado por Portal. El Editor de tipo de política para preferencias de Eclipse se integra sin

interrupciones con otras extensiones de Políticas de recurso.

Conjuntos de preferencias instalados previamente

Los elementos en negrita se muestran en las páginas de GUI como enlaces o etiquetas de entrada de

formulario. El resto de la información es para proporcionar una explicación.

Preferencias de conectividad de cliente

Nombre real: ClientConnectivityPreference

Descripción: Configura la capa de red en el cliente rico.

Preferencias:

v Intervalo de tiempo (en minutos) para sondear la disponibilidad de red

– Clave: com.ibm.rcp.net.defaults/local_monitor_interval

– Descripción: intervalo en el que el servicio de infraestructura de red debe supervisar la

actividad de red local

– Valor inicial: 5

– Restricciones: entero, 1 a 2440

Valores gestionados de cliente

Nombre real: ManagedSettings

Descripción: Configura la infraestructura de valores gestionados en el cliente rico

Preferencias: Intervalo de tiempo (en minutos) para actualizar políticas en el cliente

v Clave: com.ibm.rcp.managedsettings/UpdateIntervalInMins

v Descripción: Intervalo en el que se actualizan los valores gestionados desde el sistema de

valores de fondo

v Valor inicial: 720 restricciones - entero > 0

Valores de visor de portlet de cliente

Nombre real: PortletEditModeAllow

Descripción: Configura el visor de portlet en el cliente rico

Preferencias: Permitir la modalidad de edición en el visor de portlet de cliente

v Clave: com.ibm.rcp.portletviewer/PortletEditModeAllow

v Descripción: Se utiliza para determinar si se visualiza la selección o el icono de modalidad de

Edición

v Valor inicial: false


v Restricciones: Booleano (true, false)

Modificación de un valor en un tipo de política

El tipo de política contiene los valores predeterminados. Puede actualizar el valor predeterminado para

una preferencia en el tipo de política.

Siga estos pasos para modificar un valor en un tipo de política.



3. Pulse Políticas de recursos. Se visualiza una lista de tipos de política existentes.

4. Localice el tipo de política que desea cambiar.

5. Abra el menú emergente y seleccione Editar política.

6. Realice los cambios necesarios en los valores y pulse Aceptar.

El tipo de política se actualiza con los valores nuevos.

Creación de una política hijo para un tipo de política

Se pueden utilizar políticas hijo con la personalización para permitir diferentes valores para diferentes

tipos de usuarios. Puede crear un árbol jerárquico de políticas para tipo de política.

Utilice políticas para especificar y aplicar valores comunes y especializados que determinan el

funcionamiento de los recursos del Portal para las diferentes clases de usuarios.

Una política es una colección de valores. Algunas políticas influyen en el comportamiento de los recursos

de Portal y en la experiencia que los usuarios tendrán al trabajar con dichos recursos. Otras políticas

influyen en el comportamiento de los recursos en un cliente. Las políticas simplifican la gestión de

recursos porque los valores de política para un tipo de recurso pueden controlar el comportamiento del

recurso para diferentes clases de usuarios. Para sitios que constan de grandes cantidades de usuarios y

recursos, la especificación y la aplicación de políticas a los recursos eliminan gran parte del tiempo que,

de lo contrario, necesitarán emplear los administradores para gestionar una vasta matriz de valores

discretos para usuarios y recursos.

Para crear una política hijo, primero debe asignar una norma de política al padre. El padre situado más

arriba es el tipo de política. Asigne normas de política a un tipo de política utilizando las funciones de

políticas de recursos y personalización de WebSphere Portal. Consulte el centro de información de

WebSphere Portal para obtener información sobre cómo gestionar recursos de Portal con políticas.

Siga estos pasos para crear una política hijo.




4. Localice el tipo de política que desea cambiar.

5. Pulse el tipo de política. Se visualizan todas las políticas hijo existentes para este tipo de política.

Si ha seleccionado una norma de personalización, se visualiza el nombre de la norma de política. Si

no se ha seleccionado ninguna norma de política, utilice el menú emergente para que la norma de

política cree una nueva norma de personalización o seleccione una norma de personalización

existente.

El botón Política nueva está inhabilitado hasta que se selecciona una norma.

6. Pulse el botón Política nueva.

7. Entre un título y una descripción para esta política y seleccione una condición para esta política.

8. Cambie los valores necesarios y pulse Aceptar.

La política hijo se crea y se le devuelve a la ventana Políticas de recursos.


Edición de valores en una política hijo

Puede editar una política hijo.

Siga estos pasos para editar una política hijo. La ventana Políticas de recursos le permite navegar por el

árbol jerárquico de políticas hijo para localizar la política que desea editar.




4. Localice el tipo de política que desea actualizar.

5. Pulse el tipo de política. Se visualizan todas las políticas hijo de primer nivel.

6. Si es necesario, pulse una política hijo para navegar a una mayor profundidad en el árbol de políticas

hijo.

7. Una vez que haya localizado la política hijo que desea cambiar, utilice el menú de contexto para

seleccionar Editar política.

8. Cambie los valores necesarios y pulse Aceptar.

La política hijo se actualiza con los nuevos valores y se le devuelve a la ventana Políticas de recursos.

Instalación de un nuevo conjunto de preferencias

La mayoría de los conjuntos de preferencias que utiliza se instalan automáticamente con Lotus Expeditor

Client. Si se necesitan conjuntos de preferencias adicionales, puede instalarlos utilizando la posibilidad de

importación del Portlet.

Cuando se importa un conjunto de preferencias, se crea un nuevo tipo de política que contiene los

valores predeterminados.

Al crear un nuevo conjunto de valores de política para los plug-ins personalizados o los plug-ins

proporcionados con Lotus Expeditor Client podrá gestionar de forma centralizada las preferencias de

Eclipse desde el servidor. Consulte Desarrollo de aplicaciones para Lotus Expeditor para obtener instrucciones

sobre cómo crear nuevos conjuntos de preferencias.

Escenario de ejemplo: La empresa tiene centros de servicio en diferentes regiones del país y desea

automatizar el centro de servicio al que deben acceder los empleados de la empresa basándose en el

lugar donde viven. Puede crear su propio plug-in que utilice una preferencia de Eclipse para contener un

valor basado en la ubicación:

com.mycompany.serviceplugin/MYSERVICECENTER=Raleigh

Puede grabar una plantilla XML que contenga esta preferencia. Deberá instalar la plantilla, junto con un

norma de personalización basada en la ubicación del empleado que se asigna como tipo de política. El

paso final será crear políticas hijo basadas en las normas de personalización. Esto permitirá asignar

automáticamente el centro de servicio.

Siga estos pasos para importar un nuevo conjunto de preferencias en el servidor. Estos pasos suponen

que ha proporcionado una plantilla XML en el esquema Editor de tipos de política para preferencias.

1. Utilice un navegador para acceder a Administración → Políticas de recursos → Plantillas de cliente

rico.

2. En el menú desplegable de portlet de la barra de cabecera de Portlet, pulse Configurar para entrar en

modalidad de configuración.

3. Pulse Examinar para navegar por el sistema de archivos local y seleccione el archivo de plantilla

XML.

4. Seleccione el archivo y pulse Importar. La plantilla XML se valida y se guarda en los valores de

Portlet. Se crea el tipo de política.


Ahora puede acceder al tipo de política utilizando Administración → Políticas de recursos.

Nota:

v Si el nuevo tipo de política no aparece, puede pulsar en uno de los tipos de política y pulsar el

enlace Tipos de política en la parte superior de la página o termine la sesión en el servidor de

Portal y vuelva a iniciar la sesión.

v Para suprimir una plantilla definida por el usuario, deberá utilizar scripts XMLAccess del Editor

de políticas, que se describen en ″Archivos de configuración XML de políticas de ejemplo″ en el

centro de información de WebSphere Portal. Se recomienda que elimine el tipo de política si

desinstala una plantilla definida por el usuario. Si desinstala el Editor de tipo de política, se

suprimen las plantillas pero no se suprimen los tipos de política. No puede editar el tipo de

política a menos que vuelva a cargar la plantilla incluso después de volver a instalar el Editor de

tipo de política. Se recomienda que guarde las plantillas en otra ubicación.

Gestión de propiedades

El servidor de portal Server no proporciona tareas específicas para gestionar los archivos de propiedades.

Puede influir en el contenido de los archivos de propiedades utilizando los manejadores de instalación en

las características que despliega.

Consulte “Utilización del manejador de instalación global” en la página 166 para obtener más

información sobre los manejadores de instalación proporcionados por la plataforma.


La plataforma de cliente proporciona dos modelos de gestión de plataforma y aplicación: utilizando el

Agente de gestión de empresa y el servidor Device Manager y utilizando el servidor de Portal para

controlar el diseño de aplicación y el suministro de las aplicaciones al cliente. Si elige no utilizar estas

posibilidades, puede utilizar otro sistema de gestión para gestionar la plataforma de cliente.

El elemento crítico de la gestión de la plataforma sin utilizar el servidor Device Manager o las

posibilidades de cliente gestionado de portal es que todas las aplicaciones se deben instalar como

características. Esto requiere que las aplicaciones se empaqueten en una características y se distribuyan

como parte de un sitio de actualización.

Configuración de la política de gestor de actualizaciones

Consulte la documentación de Eclipse para obtener información sobre cómo establecer la política y

configurar actualizaciones automáticas.

Se puede encontrar información en http://help.eclipse.org/help32/index.jsp: Workbench User Guide →

Tasks → Updating features with the update manager → Controlling the eclipse update policy and

scheduling automatic updates.

Gestión de preferencias

El servidor Device Manager y las posibilidades cliente gestionado de portal se ejecutan en el contexto de

la plataforma, de modo que tienen acceso a las API necesarias para actualizar los valores de preferencia.

Si no está utilizando estas posibilidades incorporadas, es más difícil cambiar los valores de preferencias.

Puede actualizar los valores de preferencias predeterminados cambiando el archivo

plugin_customization.ini, pero si desea realizar actualizaciones en los valores actuales, necesitará llamar a

las API para efectuar los cambios.

Puede utilizar manejadores de instalación para establecer valores iniciales predeterminados, pero si

necesita consultar los valores actuales, o quizá realizar actualizaciones en valores existentes, necesitará

proporcionar su propio mecanismo para llamar a las API.



También puede utilizar la infraestructura de proveedor de valores gestionados para implementar sus

propias posibilidades de valores de preferencias.

Mientras los valores de preferencias se almacenan en el sistema de archivos de la máquina local, no se

recomienda que los archivos se cambien fuera de las API.

Gestión de propiedades

La plataforma proporciona varios archivos de configuración, como se define en el apartado que trata

sobre la configuración de la plataforma.

El modelo preferido para actualizar los archivos de propiedades que forman parte de la plataforma de

cliente consiste en añadir el manejador de instalación global a cualquier característica que deba

actualizarse en los archivos de configuración. Sin embargo, no está limitado a esta solución para

modificar los archivos de propiedades. Si elige utilizar su propio sistema de gestión para modificar estos

archivos, tenga en cuenta que éstos se formatean como archivos de propiedades Java y existen normas

específicas para el formato de estos archivos. Consulte la documentación sobre la clase java.util.Properties

para obtener información sobre estas restricciones.

Utilización de las interfaces de suministro para gestionar la plataforma

En esta sección se explica cómo utilizar las interfaces de suministro disponibles para gestionar la

plataforma de cliente.

Si se utilizan el servidor de gestor de dispositivos o el servidor de Portal para gestionar la plataforma, la

mayoría de las tareas de distribución de software ya están manejadas. Si se utiliza otro sistema de gestión

para gestionar la plataforma de cliente, dicho sistema debe utilizar las interfaces de suministro

disponibles para realizar cambios en el sistema. Principalmente hay tres opciones para utilizar las

interfaces de suministro:

v Actualizar directamente el manifiesto de suministro y las propiedades relacionadas y reiniciar la

plataforma.

v Llamar directamente a la aplicación de suministro para realizar cambios en la plataforma.

v Utilizar las API de suministro desde dentro de la plataforma para realizar cambios en la plataforma.

Estos métodos proporcionan acceso al sistema de suministro que forma parte de la plataforma para

asegurar que las características y los plug-ins se instalan y habilitan correctamente.

Atención:

El mandato standaloneUpdate de Eclipse está inhabilitado en Lotus Expeditor 6.1.2. Se

recomienda utilizar las interfaces de suministro para gestionar la plataforma.

Actualización del manifiesto de suministro para cambiar la plataforma

La aplicación de suministro se ejecuta inicialmente durante la fase de instalación de Lotus Expeditor. La

aplicación de suministro se puede volver a ejecutar en cualquier momento para efectuar actualizaciones

en la plataforma.

Para ejecutar la aplicación de suministro otra vez, actualice la propiedad provisioning.manifest.version

del archivo rcplauncher.properties a un valor mayor que el actual y actualice el contenido de archivo de

manifiesto. Si el valor actual existente en rcpinstall.properties es menor que el valor de

provisioning.manifest.version especificado en rcplauncher.properties, el iniciador iniciará

automáticamente la aplicación de suministro para procesar el manifiesto.

De forma alternativa, todos los cambios de características pueden suministrarse en un archivo de

manifiesto <dir instalación del producto>/rcp/deploy/install.update.xml para ejecutar posteriormente el

mandato de actualización de suministro y fusionar los cambios. Una vez que se ha procesado el

manifiesto, Expeditor debe reiniciarse para mostrar la aplicación y/o la personalidad seleccionadas.


||

El formato del manifiesto de suministro se puede consultar en “DTD de manifiesto de suministro” en la

página 181.


Si es necesario realizar explícitamente los pasos de suministro, por ejemplo mediante otro sistema de

gestión, la aplicación de suministro se puede invocar utilizando la línea de mandatos.

La sintaxis de la aplicación de suministro es la siguiente:

rcplauncher

–application

com.ibm.rcp.provisioning.application.ProvisioningApplication

-provisioningOperation { install | update | uninstall | provision nombrearchivo }

-provisioningStatusLog nombrearchivo

La aplicación de suministro lee el archivo rcp/rcplauncher.properties para obtener las propiedades

provisioning.manifest y provisioning.manifest.version. La aplicación de suministro analiza el

manifiesto y procesa todas las características existentes en el archivo. La aplicación de suministro ignora

los límites entre las características de instalación.

Cuando la instalación se ha realizado de forma satisfactoria (o parcialmente satisfactoria), se actualiza la

propiedad provisioning.manifest.version en el archivo rcp/rcpinstall.properties.

Una vez procesados los argumentos, la propiedad del sistema provisioningOperation se establece en la

operación que se está procesando actualmente.

La operación install (instalación) produce un análisis del manifiesto de suministro. Todas las

características existentes en el archivo se comparan con las características actuales existentes en la

plataforma y, si es necesario, se instalan y habilitan.

La operación uninstall (desinstalación) se llama dos veces. La primera vez que se llama, inhabilita todas

las características de la plataforma, excepto las que son necesarias para ejecutar la plataforma de núcleo y

el suministro. La segunda vez que se llama, desinstala todas las características inhabilitadas de la

plataforma.

La operación update (actualización) procesa el manifiesto de suministro. Si un archivo install.update.xml

se encuentra en el mismo directorio que el manifiesto de suministro, el contenido se fusiona antes de

procesar el manifiesto de suministro para realizar las actualizaciones.

La operación provision (suministro) procesa el manifiesto de suministro que se proporciona como

argumento en el mandato y procesa las características contenidas dentro del manifiesto de suministro. El

contenido del archivo de manifiesto de suministro no se fusiona con la versión definida por la plataforma

y no se modifica la propiedad provisioning.manifest.version en el archivo rcplauncher.properties.

Nota: Asegúrese de que la vía de acceso del manifiesto de suministro no acabe con una barra inclinada

invertida ″\″ ya que la VM interpretará esto como un carácter de escape, lo que da como resultado

un error.

Utilización de la aplicación de suministro con DCommands:

Las operaciones de suministro también se pueden iniciar si la plataforma ya está en ejecución. Mediante

el uso de DCommands, se pueden pasar argumentos de mandato a una clase receptora en la plataforma

en ejecución.

Para iniciar la plataforma de forma que se pasen los DCommand mediante una instancia en ejecución o

que se lance una instancia nueva para procesar los argumentos, utilice la siguiente sintaxis para el

lanzamiento:


|||

rcplauncher

–application com.ibm.rcp.provisioning.application.ProvisioningApplication

–com.ibm.rcp.provisioning #provisioningCommand

–provisioningOperation <mandato> -provisioningStatusLog <archivo>

Esto producirá uno de dos resultados:

v Se pasan los argumentos de suministro a la plataforma existente (que ejecuta actualmente el entorno de

trabajo) y el suministro se produce en la plataforma existente. Cuando se ha completado el suministro,

la plataforma existente continúa ejecutándose hasta que el usuario que utiliza la plataforma

actualmente decide cerrarla.

v Una nueva instancia de la plataforma empezará a utilizar la aplicación de suministro y el suministro se

producirá utilizando esta nueva instancia de la plataforma. Cuando el suministro se haya completado,

la plataforma saldrá.

Utilización de la aplicación de suministro para configuraciones multiusuario:

En una configuración multiusuario, utilice la aplicación de suministro para mantener la plataforma

existente.

La aplicación de suministro está principalmente destinada a que la utilice el desplegador o administrador

para actualizar la instalación principal de las características. La aplicación de suministro, cuando se utiliza

para realizar el mantenimiento en la plataforma existente, instala, habilita, inhabilita y eliminar

características de la plataforma. Para permitir que los demás usuarios de la plataforma puedan acceder a

los cambios, se deberán actualizar el manifiesto de suministro así como la propiedad

provisioning.manifest.version. Si no se realizan estos cambios, los espacios de trabajo existentes seguirán

utilizando la configuración actual.

Mediante el uso del mandato mergemanifest en el manejador de instalación global, el modelo preferido

será distribuir una característica nueva que contiene elementos de manifiesto de suministro adicionales o

actualizados que se fusionarán con el manifiesto existente. Esto hará que todos los usuarios se actualicen

a la configuración más reciente en el siguiente lanzamiento del espacio de trabajo. (Y todos los espacios

de trabajo nuevos se configurarán inmediatamente con la configuración de características más reciente).

Los usuarios que utilizan la aplicación de suministro sólo van a actualizar la lista de aplicaciones local

(existente en el espacio de trabajo).

Si un sistema de gestión tiene la intención de llamar a la aplicación de suministro, necesitará hacerlo en el

contexto de un administrador con derechos para modificar la configuración de plataforma existente.

Utilización de las API de suministro

Utilice las API de suministro para asegurar la instalación correcta y coherente de las características y el

funcionamiento satisfactorio de la plataforma.

Utilice las API de suministro para obtener acceso al sistema de suministro desde otros plug-ins que se

ejecutan en la plataforma. En el caso de que las aplicaciones que se ejecutan en la plataforma deseen

realizar cambios en la plataforma, por ejemplo solicitar la instalación de características y plug-ins nuevos,

las aplicaciones deberán utilizar las API proporcionadas en lugar de las API de actualización

proporcionadas por Eclipse. La utilización de las API de suministro asegurará la instalación correcta

coherente de las características y el funcionamiento continuado satisfactorio de la plataforma.

El modelo de programación general para utilizar las API de suministro consiste en obtener una instancia

de ProvisioningService de ProvisioningServiceFactory y, a continuación, invocar los métodos

proporcionados por el servicio para realizar cambios. Los métodos proporcionados funcionan en objetos

ProvisioningRequest específicos o en un manifiesto de suministro proporcionado al servicio. Para obtener

más información, consulte el Javadoc de suministro en Desarrollo de aplicaciones para Lotus Expeditor.



Avisos

La información aquí contenida ha sido desarrollada para productos y servicios ofrecidos en Estados

Unidos. Puede que IBM no ofrezca los productos, servicios ni características contenidos en este

documento en otros países. Póngase en contacto con el representante local de IBM si desea obtener

información sobre los productos y servicios disponibles en su zona. Cualquier referencia a un producto,

programa o servicio de IBM no pretende afirmar ni implica que sólo pueda utilizarse ese producto,

programa o servicio de IBM. En su lugar, puede utilizarse cualquier producto, programa o servicio

funcionalmente equivalente que no infrinja ninguno de los derechos de propiedad intelectual de IBM. No

obstante, es responsabilidad del usuario evaluar y verificar el funcionamiento de cualquier producto,

programa o servicio que no sea de IBM.

IBM puede tener patentes o solicitudes de patentes pendientes que aborden temas descritos en este

documento. La adquisición de este documento no confiere ninguna licencia sobre dichas patentes. Puede

enviar consultas sobre licencias, por escrito, a:

IBM Director of Licensing

IBM Corporation

North Castle Drive

Armonk, NY 10504-1785

EE.UU.

Si tiene consultas sobre licencias relacionadas con información DBCS (de doble byte), póngase en contacto

con el Departamento de propiedad intelectual de IBM en su país o envíelas, por escrito, a:

IBM World Trade Asia Corporation Licensing

2-31 Roppongi 3-chome, Minato-ku

Tokio 106, Japón

El párrafo siguiente no es aplicable al Reino Unido ni a ningún otro país en el que las disposiciones en él

expuestas sean incompatibles con la legislación local: INTERNATIONAL BUSINESS MACHINES

CORPORATION PROPORCIONA ESTA PUBLICACIÓN “TAL CUAL” SIN GARANTÍAS DE NINGÚN

TIPO, NI EXPRESAS NI IMPLÍCITAS, INCLUIDAS, PERO SIN LIMITARSE A, LAS GARANTÍAS

IMPLÍCITAS DE NO INFRACCIÓN, COMERCIALIZACIÓN O IDONEIDAD PARA UNA FINALIDAD

DETERMINADA. Algunas legislaciones no contemplan la exclusión de garantías, ni implícitas ni

explícitas, en determinadas transacciones, por lo que puede haber usuarios a los que no les afecte dicha

norma.

Esta publicación puede contener inexactitudes técnicas o errores tipográficos. La información aquí

contenida está sometida a modificaciones periódicas, las cuales se incorporarán en nuevas ediciones de la

publicación. IBM puede realizar en cualquier momento y sin notificación previa mejoras o cambios en los

productos o programas descritos en esta publicación.

Las referencias hechas en esta publicación a sitios Web que no son de IBM se proporcionan sólo para la

comodidad del usuario y no constituyen un aval de esos sitios Web. Los materiales que se encuentran en

los mencionados sitios web no forman parte de los materiales para este producto de IBM y el usuario los

utiliza por su cuenta y riesgo.

IBM puede utilizar o distribuir la información que le suministre el cliente de la forma que crea oportuna,

sin incurrir en ninguna obligación con el cliente.


El usuario con licencia de este programa que desee información sobre éste con la finalidad del: (i)

intercambio de información entre programas creados independientemente y otros programas (incluidos

éste) y (ii) uso mutuo de la información que se ha intercambiado, debe escribir a la dirección siguiente:

IBM Corporation

Department LZMS

11501 Burnet Road

Austin, TX 78758-3400

EE.UU.

Dicha información puede estar disponible, sujeta a los términos y condiciones apropiados, incluido en

algunos casos, el pago de una tarifa.

IBM proporciona el programa bajo licencia descrito en este documento y todo el material con licencia

disponible para el mismo bajo los términos del Acuerdo de cliente de IBM, el Acuerdo de licencia de

programa internacional de IBM o cualquier acuerdo equivalente entre las dos partes.

Los datos de rendimiento contenidos en este documento se obtuvieron en un entorno controlado. Por

tanto, los resultados obtenidos en otros entornos operativos pueden variar significativamente. Algunas

mediciones pueden haberse hecho en sistemas experimentales y no es seguro que estas mediciones sean

las mismas en los sistemas disponibles comercialmente. Además, algunas mediciones se pueden haber

estimado mediante extrapolación. Los resultados reales pueden variar. Los usuarios del presente manual

deben verificar los datos aplicables para su entorno específico.

La información referente a productos que no son de IBM se ha obtenido de los proveedores de esos

productos, de sus anuncios publicados o de otras fuentes disponibles públicamente. IBM no ha probado

estos productos y no puede confirmar la precisión del rendimiento, la compatibilidad ni ninguna otra

afirmación relacionada con productos que no son de IBM. Las preguntas sobre las prestaciones de

productos que no son de IBM se deben dirigir a los distribuidores de dichos productos.

Todas las declaraciones sobre futuras tendencias o intenciones de IBM están sujetas a modificación o

retirada sin previo aviso y representan únicamente metas y objetivos.

Todos los precios IBM que se muestran son precios de venta al público sugeridos por IBM, son actuales y

están sujetos a cambios sin previo aviso. Los precios de concesionario pueden variar.

Esta información se proporciona únicamente para la planificación. La información aquí contenida está

sujeta a cambios antes de que los productos descritos estén disponibles.

Esta información contiene ejemplos de datos e informes utilizados en operaciones empresariales diarias.

Para ilustrar los ejemplos de la forma más completa posible, éstos incluyen nombres de personas,

empresas, marcas y productos. Todos estos nombres son ficticios y cualquier similitud con los nombres y

direcciones utilizados por una empresa real son mera coincidencia.

LICENCIA DE COPYRIGHT:

Esta información contiene programas de aplicación de ejemplo en lenguaje fuente que ilustran técnicas de

programación en diversas plataformas operativas. Puede copiar, modificar y distribuir libremente estos

programas de ejemplo, sin pagar por ello a IBM, con la finalidad de desarrollar, utilizar, comercializar o

distribuir programas de aplicación conformes a las interfaces de programas de aplicación para la

plataforma operativa para la que se han escrito los programas de ejemplo. Estos ejemplos no se han

probado exhaustivamente bajo todas las condiciones. Por lo tanto, IBM no puede garantizar ni certificar

la fiabilidad, el servicio o el funcionamiento de estos programas. El usuario puede copiar, modificar y

distribuir estos programas de ejemplo como desee, sin tener que efectuar ningún pago a IBM, con la

finalidad de desarrollar, utilizar, realizar marketing o distribuir programas de aplicaciones según la

interfaz de programación de las aplicaciones de IBM.


Cada copia o cada parte de estos programas de ejemplo, o trabajos derivados, debe incluir un aviso de

copyright como se indica a continuación:

© (nombre de su empresa) (año). Las partes de este código proceden de IBM Corp. Programas de

ejemplo. © Copyright IBM Corp. 2004, 2007 Reservados todos los derechos.

Si consulta esta documentación en soporte software, puede que no aparezcan las fotografías e

ilustraciones en color.

Marcas registradas

Los términos siguientes son marcas comerciales o marcas registradas de International Business Machines

Corporation en los Estados Unidos y/o en otros países:

AIX

DB2

Domino

Everyplace

IBM

Lotus

Lotus Notes

Rational

Sametime

System p

Tivoli

WebSphere

Java y todas las marcas registradas basadas en Java son marcas registradas de Sun Microsystems, Inc. en

los Estados Unidos y/o en otros países.

JavaScript es una marca registrada de Sun Microsystems, Inc. en los Estados Unidos y/o en otros países.

Linux es una marca registrada de Linus Torvalds en los Estados Unidos y/o en otros países.

Microsoft y Windows son marcas registradas de Microsoft Corporation en los Estados Unidos y/o en

otros países.

Otros nombres de empresas, productos o servicios pueden ser marcas comerciales o marcas de servicio de

otras compañías.

Avisos 265


��