Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Migrate-Classic-Appserver en Es
Migrate-Classic-Appserver en Es
Tabla de contenido
Más información sobre la migración de aplicaciones clásicas de AppServer a PAS para OpenEdge
Prepárese para pasar de Classic AppServer a PAS para OpenEdge ........................................ .................dieciséis
Conecte a los clientes con el nuevo PAS para transportes OpenEdge .......................................... ............................ 28
Diferencias en los procedimientos de eventos entre el clásico AppServer y PAS para OpenEdge ............... 42
Directorios y rutas del sistema de archivos en PAS para OpenEdge ......................................... ........................... 49
Migre las URL de WSA para utilizar el transporte SOAP .......................................... ............................... 54
© 2019 Progress Software Corporation y / o sus subsidiarias o afiliadas. Todos los derechos reservados.
Estos materiales y todo el progreso Los productos de software tienen derechos de autor y todos los derechos están reservados por Progress Software
®
Corporation. La información de estos materiales está sujeta a cambios sin previo aviso, y Progress Software Corporation no asume ninguna responsabilidad
por los errores que puedan aparecer en ellos. Las referencias en estos materiales a plataformas específicas compatibles están sujetas a cambios.
Corticon, DataDirect (y diseño), DataDirect Cloud, DataDirect Connect, DataDirect Connect64, DataDirect XML Converters, DataDirect XQuery, DataRPM, Deliver más de lo
esperado, Icenium, Kendo UI, Kinvey, NativeScript, OpenEdge, Powered by Progress, Progress, Progress Software Developers Network, Rollbase, SequeLink, Sitefinity (y
Design), Sitefinity, SpeedScript, Stylus Studio, TeamPulse, Telerik, Telerik (y Design), Test Studio y WebSpeed son marcas comerciales registradas de Progress Software
Corporation o una de sus afiliadas o subsidiarias en EE. UU. y / u otros países. Analytics360, AppServer, BusinessEdge, DataDirect Autonomous REST Connector, DataDirect
Spy, SupportLink, DevCraft, Fiddler, JustAssembly, JustDecompile, JustMock, Kinvey Chat, NativeChat, NativeScript Sidekick, OpenAccess, ProDataSet, Progress Results,
Progress Software, ProVision, PSE Pro, SmartBrowser, SmartComponent, SmartDataBrowser, SmartDataObjects, SmartDataView, SmartDialog, SmartFolder, SmartFrame,
SmartObjects, SmartPanel, SmartQuery, SmartViewer, SmartWindow y WebClient son marcas comerciales o marcas de servicio de Progress Software Corporation o sus
subsidiarias en EE. UU. y otros países. Java es una marca comercial registrada de Oracle y / o sus afiliadas. Cualquier otra marca contenida en este documento puede ser una
marca comercial de sus respectivos propietarios. Java es una marca comercial registrada de Oracle y / o sus afiliadas. Cualquier otra marca contenida en este documento puede
ser una marca comercial de sus respectivos propietarios. Java es una marca comercial registrada de Oracle y / o sus afiliadas. Cualquier otra marca contenida en este
documento puede ser una marca comercial de sus respectivos propietarios.
Noviembre de 2019
Propósito
El propósito de este contenido es introducir los siguientes conceptos:
Audiencia
Usuarios de OpenEdge que buscan migrar del clásico OpenEdge AppServer al Progress Application Server para OpenEdge (PAS para
OpenEdge).
Organización
Más información sobre la migración de aplicaciones clásicas de AppServer a PAS para OpenEdge en la página 9
Inicio rápido: mueva las aplicaciones clásicas de AppServer a PAS para OpenEdge en la página 13
Convenciones de documentación
Ver Convenciones de documentación para obtener una explicación de la terminología, el formato y las convenciones tipográficas utilizadas en la biblioteca de
contenido de OpenEdge.
La migración de una aplicación desde Progress OpenEdge AppServer (AppServer clásico) o WebSpeed Transaction Server a Progress
Application Server (PAS) para OpenEdge comienza con mover su aplicación a un entorno de prueba con unos pocos cambios simples de
código y propiedad. Los siguientes materiales están diseñados para ayudarlo a mover su aplicación.
• Inicio rápido: mueva las aplicaciones clásicas de AppServer a PAS para OpenEdge en la página 13 hay un tutorial paso a paso para mover una
aplicación clásica de AppServer a una instancia de prueba PAS para OpenEdge.
• Migrar aplicaciones clásicas de AppServer a PAS para OpenEdge es un video complementario que muestra cómo mover una aplicación ABL de
muestra a PAS para OpenEdge utilizando el transporte APSV.
• Migre los servicios REST de Classic AppServer a PAS para OpenEdge es un video complementario que muestra cómo mover servicios REST de
AppServer clásicos de muestra a PAS para OpenEdge utilizando el transporte REST.
Después de mover su aplicación a un sistema de prueba, estará listo para completar la migración si obtiene más información sobre PAS para
OpenEdge. Debido a que cada aplicación es única, no existe un consejo universal para migrar a un entorno de producción en vivo. Los tipos de cliente
y la complejidad de sus configuraciones de servidor existentes dictarán la ruta de migración de su aplicación.
Este contenido comienza destacando las diferencias entre PAS para OpenEdge y los servidores existentes, AppServer clásico y WebSpeed
Transaction Server. El siguiente contenido está disponible para profundizar en las mejores prácticas para migrar el contenido clásico de
AppServer y WebSpeed Transaction Server a PAS para OpenEdge:
Utilice los siguientes recursos para obtener más información sobre PAS para OpenEdge.
• Más información sobre Progress Application Server para OpenEdge , para una introducción detallada
• Administrar PAS para OpenEdge , para una introducción al marco administrativo general, incluidas las opciones de seguridad, ajuste y
supervisión.
• Más información sobre PAS para OpenEdge y OpenEdge Management , para recomendaciones de configuración, incluido el uso de OpenEdge
Management
• Progress Application Server para OpenEdge: Guía de tamaño de máquina , para obtener detalles sobre cómo dimensionar su máquina PAS para OpenEdge para su
uso en producción.
Toma un curso:
Unete a la communidad:
• Diferencias entre AppServer clásico, WebSpeed Transaction Server y PAS para OpenEdge
• PAS para OpenEdge es una plataforma de servidor web. PAS para OpenEdge es una plataforma de servidor web unificada construida sobre la tecnología
de servidor web ApacheTomcat y mejorada por el desarrollo de OpenEdge para gestionar las necesidades específicas de los clientes de OpenEdge. Debido a
que la tecnología subyacente es diferente, existen diferencias en cómo instalar, configurar, conectar y ejecutar aplicaciones usando PAS para OpenEdge
• La concesión de licencias es diferente. PAS para OpenEdge está disponible como dos licencias de producto independientes:
• los Servidor de aplicaciones de desarrollo de progreso para OpenEdge es un servidor web para desarrollo y prueba
Aplicaciones OpenEdge.
• los Servidor de aplicaciones de producción Progress para OpenEdge es un servidor web seguro para OpenEdge
implementación de aplicaciones de producción.
• Las aplicaciones se ejecutan en una instancia. A diferencia del clásico AppServer, las aplicaciones no se ejecutan en el directorio de instalación de PAS para
OpenEdge. En su lugar, las aplicaciones se ejecutan en una o más instancias que crea según la plantilla de instalación. Esto facilita las actualizaciones futuras
porque los cambios realizados en una instancia se pueden mantener cuando se actualiza a una nueva versión. No se requieren pasos adicionales de copia de
seguridad y restauración para actualizar las aplicaciones clásicas de AppServer.
• Ya no se necesitan adaptadores especiales. Con PAS para OpenEdge, no hay adaptadores especiales (WSA o AIS) para admitir diferentes tipos de clientes
OpenEdge. En cambio, las instancias admiten cuatro tipos de transporte para conectar todos los tipos de clientes existentes y futuros.
Cuando un tipo de cliente determinado se conecta a una instancia, la URL debe contener el transporte requerido para ese tipo de cliente. Estos transportes
son importantes cuando configura la seguridad. Puede habilitar y deshabilitar un transporte para una aplicación web ABL dada para proteger aplicaciones
específicas.
Nota: Para los servicios web OpenEdge REST implementados en AppServer, puede migrar la aplicación empresarial AppServer a una instancia
PAS para OpenEdge para que los clientes existentes de OpenEdge REST y Data Object Services puedan conectarse y enviar solicitudes
utilizando los mismos URI de recursos. Se deben implementar nuevas aplicaciones REST con el transporte WEB para acceder a más métodos
REST.
• Los clientes se conectan de manera diferente. Las conexiones de cliente están estandarizadas en conexiones de URL HTTP o HTTPS a una
aplicación web (una aplicación web OpenEdge ABL derivada de oeabl.war). La aplicación web OpenEdge ABL, también conocida como aplicación
web ABL, gestiona la ejecución de todo el código ABL del servidor en nombre de todos los tipos de clientes OpenEdge admitidos. Sus aplicaciones
ya no utilizan conexiones de modo directo o nativo a una instancia de un ABL, Java , o .NET Open Client como lo hicieron con el clásico AppServer.
• Las solicitudes de los clientes se distribuyen de forma diferente. Cada aplicación web ABL implementada incluye un administrador de sesiones que
maneja todas las conexiones del cliente a la aplicación web y distribuye las solicitudes del cliente a los agentes multisesión disponibles del servidor, que a su vez
pasan cada solicitud a una sesión ABL disponible. Cada uno configurado agente multisesión es un proceso del sistema operativo independiente que mantiene un
grupo de sesiones ABL que se utilizan para ejecutar todas las solicitudes de los clientes enviadas a ese agente. Dependiendo de la aplicación, cada proceso de
agente de múltiples sesiones puede ejecutar solicitudes en múltiples sesiones de servidor a la vez, lo que permite que una sola instancia maneje múltiples
solicitudes de uno o más clientes en paralelo. Por lo tanto, en comparación con el clásico AppServer, donde cada sesión de servidor se ejecuta en su propio
agente (proceso del SO), una instancia puede procesar la misma carga de cliente utilizando menos recursos del SO.
• Dos modelos de aplicación reemplazan cuatro modos de funcionamiento. A diferencia del clásico AppServer, que admite cuatro modos de funcionamiento
diferentes, PAS para instancias de OpenEdge admite dos modos de funcionamiento, denominados
modelos de aplicación. Los modelos admitidos son:
• Modelo sin sesión que se ejecuta casi exactamente como el clásico AppServer libre de estado modo operativo
• Modelo administrado por sesiones se ejecuta de forma similar al clásico AppServer apátrida modo operativo.
Nota: Puedes emular estado-reset o consciente del estado modos de funcionamiento con cambios de código en los procedimientos de configuración de
conexión y desconexión, denominados procedimientos de eventos por ejemplo. Para más información, ver Migrar los modos operativos clásicos de
AppServer en la página 37.
• Las conexiones de cliente establecen el modelo de aplicación, no el servidor. No configura una instancia para admitir un solo modelo de
aplicación como lo hace con el AppServer clásico. Cada conexión de cliente identifica el modelo de aplicación que utiliza la aplicación web ABL
conectada para atender las solicitudes de ese cliente conectado. Es la misma forma en que un cliente identifica el modo de sesión cuando se
conecta al AppServer clásico. El beneficio de este tipo de conexión es que cualquier sesión disponible puede manejar solicitudes de cualquier
cliente dado de acuerdo con el modelo de aplicación que requiere.Cuando migra el código ABL a una instancia desde una aplicación clásica de
AppServer, el código debe ejecutarse en esa instancia con muy pocos (si los hay) cambios, como se describe en Migración de código de aplicación
ABL en la página 35. Si intenta migrar varias aplicaciones clásicas de AppServer que se ejecutan en diferentes modos de funcionamiento a una sola
instancia, debe hacer más
cambios de código, especialmente en los procedimientos de eventos de una instancia, para manejar la administración de contexto para cualquier cambio en el
modelo de aplicación y el estado de enlace para cada conexión de cliente.
• Las solicitudes de los clientes se procesan de manera diferente. Para ejecutar las solicitudes del cliente, cada agente multisesión mantiene
dos grupos dentro de su espacio de proceso único: un grupo de sesiones de servidor (contextos de ejecución ABL) y un grupo de máquinas
virtuales ABL (AVM) que ejecutan el código ABL. El agente recibe una solicitud de cliente, asocia una sesión de servidor disponible (contexto de
ejecución ABL) con un AVM disponible, y el AVM ejecuta el código ABL para manejar la solicitud en el contexto de sesión asociado.Cuando el
AVM termina de ejecutar la solicitud del cliente, tanto el AVM y su sesión de servidor asociada se devuelven a los grupos respectivos del agente.
La sesión recién disponible retiene todo el contexto (datos globales) establecido para la solicitud de cliente más reciente a menos que la aplicación
lo borre explícitamente durante el manejo de la solicitud.
• Las conexiones de cliente no están vinculadas de forma predeterminada. Las conexiones de cliente no están vinculadas a una conexión de sesión para permitir la
reutilización eficiente de los recursos del servidor. Si su aplicación requiere que una conexión de cliente esté vinculada a una conexión de sesión, consulte Administrar el
• Conexiones de base de datos de red y autoservicio en PAS para OpenEdge. Un solo hilo maneja todas las sesiones ABL. Por lo tanto, es
importante tener en cuenta que si ese hilo falla, todas las conexiones fallarán. Si está acostumbrado a recortar agentes manualmente, tenga
cuidado de no recortar el hilo de la base de datos.
• El NameServer ya no maneja el equilibrio de carga. No hay una arquitectura de NameServer o Unified Broker en PAS para OpenEdge
porque cada instancia es un servidor web. Sin embargo, puede lograr tolerancia a fallas y equilibrio de carga en varias instancias que admiten
una sola aplicación empresarial sin sesión registrando las instancias con un equilibrador de carga HTTP estándar del sector. Sus clientes se
conectan al equilibrador de carga mediante una URL que identifica el mismo ABL aplicación web y el transporte de conexión apropiado
soportado por todas las instancias registradas. Según el servicio de equilibrio de carga, puede delegar las solicitudes de los clientes a las
instancias disponibles mediante diferentes políticas de equilibrio de carga.
• Las aplicaciones WebSpeed en una instancia PAS para OpenEdge tienen una arquitectura más integrada en comparación con el servidor
WebSpeedTransaction porque tanto el servidor web como el servidor WebSpeedTransaction se combinan en una sola instancia.
• WebSpeed en una instancia es más eficiente que WebSpeed en Transaction Server con respecto a la administración y disponibilidad de
los agentes que manejan las solicitudes de los clientes.
• WebSpeed Transaction Server solo admite los verbos HTTP GET y POST. WebSpeed en una instancia admite todos los verbos HTTP
estándar.
• WebSpeed en una instancia admite procedimientos de eventos que no eran compatibles con el servidor de WebSpeedTransaction.
• PAS para OpenEdge incluye soporte para múltiples servidores en una sola instancia. No es necesario configurar y ejecutar un servidor web
separado, WebSpeed Transaction Server ni AppServer clásico.
• Una instancia comparte un único contexto de seguridad entre el transporte WEB que admite WebSpeed y todos los demás transportes
(REST, SOAP y APSV).
• PAS para OpenEdge ofrece la opción de crear controladores web personalizados para abordar las necesidades específicas de la aplicación. una introducción detallada a
PAS para OpenEdge se puede encontrar en Más información sobre Progress Application Server para
UNA
OpenEdge .
Los administradores del sistema pueden mover las aplicaciones existentes del servidor de aplicaciones OpenEdge (AppSever clásico) a PAS para entornos
de producción y preparación de OpenEdge utilizando las herramientas proporcionadas por OpenEdge y la guía de este tutorial y la documentación de PAS
para OpenEdge.
El objetivo de este tutorial de inicio rápido es permitirle ejecutar una aplicación clásica de AppServer en una instancia de PAS para OpenEdge y
actualizar una conexión de cliente ABL para usar el nuevo transporte APSV para acceder a esa aplicación. Puede usar su código de AppServer
clásico existente o el código de muestra proporcionado.
Este tutorial de inicio rápido no cubre la modernización de aplicaciones, el ajuste del rendimiento, la supervisión de aplicaciones ni la protección de la instancia para
la producción completa. Además, este tutorial de inicio rápido no destaca todas las funciones más recientes disponibles en PAS para OpenEdge. Los enlaces a esta
información adicional se pueden encontrar en el Próximos pasos con PAS para OpenEdge en la página 34 tema.
Prerrequisitos
Para completar los pasos de este tutorial, debe tener OpenEdge 12 o posterior instalado en su máquina Linux o Windows 64. Puede ejecutar la
migración utilizando OpenEdge 11.7.3 o posterior, pero no podrá usar la última versión de PAS para las funciones de OpenEdge. .
También debe tener el ubroker.properties archivo y código de tiempo de ejecución para su aplicación clásica AppServer y acceso a la base de datos
OpenEdge. También debe tener Progress Developer Studio o Progress Procedimiento Editor para ejecutar el código del lado del cliente, pero también puede
ejecutar el código en la línea de comandos de Proenv utilidad.
Puede completar los pasos de este tutorial de inicio rápido utilizando sus propios archivos de la aplicación AppServer clásica si tiene acceso
completo para migrarlos a un nuevo servidor, o puede descargar el classicAppServerCode.zip
archivo del Progreso Comunidad general de OpenEdge y utilice esta aplicación de muestra para probar el procedimiento.
los classicAppServerCode.zip contiene los siguientes archivos, a los que su aplicación clásica de AppServer puede tener análogos:
Este ejemplo ubroker.properties El archivo contiene propiedades para una aplicación clásica de AppServer llamada
app_customername_prod, que se migrará a PAS para OpenEdge.
• ServerGetCustNameSample.p —Código de servidor de muestra ABL que devuelve un nombre de cliente de la base de datos Sports2020 a un
cliente.
• ClassicClient.p —Código ABL del lado del cliente que accede al código ABL del lado del servidor mediante la cadena de conexión clásica de
AppServer.
• PASforOpenEdgeClient.p : Código ABL del lado del cliente que accede al código ABL del lado del servidor mediante PAS para la cadena de
conexión OpenEdge.
• database.pf —Archivo de parámetros que accede a la base de datos Sports2020 al inicio de la instancia. También se puede acceder a la base de datos directamente usando
una cadena de conexión de base de datos, pero es una mejor práctica usar un archivo. pf archivo que puede permanecer en una ubicación estática incluso si cambia una
base de datos.
• classicREST / classicRESTService.paar —Archivo de definición de servicio de aplicación REST de AppServer clásico de muestra. Se utiliza
para demostrar cómo migrar aplicaciones REST clásicas a PAS para OpenEdge.
• classicREST / getCustomer.p y classicREST / getAllCustomers.p —Código ABL del lado del servidor que
apoya la muestra classicRESTService.paar archivo de definición de servicio.
En este tutorial, copiará una base de datos del directorio de instalación de OpenEdge ($ DLC) a un directorio de trabajo ($ WRKDIR). También creará
una instancia de PAS para OpenEdge en el directorio de trabajo.
WRK
classicAppServerCode
ClassicClient.p
database.pf
PASforOpenEdgeClient.p
ServerGetCustNameSample.p
ubroker.properties
clásicoREST
classicRESTService.paar
getAllCustomers.p
getCustomer.p
eventos
session_shutdown.p
session_startup.p
base de datos
sports2020.b1
sports2020.d1
sports2020.db
sports2020.lg
sports2020.lic
sports2020.lk
sports2020.st
sports2020_10.d1
sports2020_20.d1
sports2020_30.d1
sports2020_40.d1
sports2020_50.d1
sports2020_60.d1
sports2020_70.d1
sports2020_80.d1
myProdInstance
ablapps
compartimiento
común
conf
hcapps
registros
abierto
temperatura
aplicaciones web
trabajo
• Prepárese para pasar de Classic AppServer a PAS para OpenEdge Mueva el código
• clásico de AppServer a PAS para clientes OpenEdge Connect con el nuevo PAS para
PAS para OpenEdge es un servidor web unificado que no requiere adaptadores especiales. Todos los tipos de clientes envían solicitudes a su código de servidor ABL
utilizando uno de cuatro transportes:
los Administrador de sesiones distribuye las solicitudes de los clientes a un subyacente Agente multisesión lo que garantiza un uso eficiente de los recursos de su
servidor. Basado en la tecnología de servidor web Apache Tomcat y mejorado por el desarrollo de OpenEdge para gestionar las necesidades específicas de sus clientes
OpenEdge, obtiene lo mejor de ambos mundos. El desarrollo progresivo aplica actualizaciones de ApacheTomcat que garantizan el cumplimiento de los estándares de
la industria, como Seguridad de primavera, mientras admite todos los tipos de clientes en un solo servidor sin productos adicionales, utilizando archivos de propiedades
fáciles de configurar.
Se crea una instancia de PAS para OpenEdge con una aplicación web ROOT ABL previamente implementada (ubicada en el
nombre de instancia/ aplicaciones web directorio) y una aplicación ABL con el mismo nombre que la instancia en el
nombre de instancia/ ablapps directorio. En este tutorial, implementará código en la aplicación web ROOT ABL.
Complete los siguientes pasos para configurar el servidor y ajustar sus propiedades para admitir el código de su aplicación:
segundo. Actualice las conexiones de la base de datos en el emerger archivo (donde sea necesario).
Ofertas de OpenEdge desarrollo y producción licencias de PAS para OpenEdge. Para organizar una configuración de producción, instale el producción licencia
que implementa una seguridad más sólida y limita la administración externa de las instancias de su servidor.
Si está menos familiarizado con el proceso de instalación de OpenEdge, consulte Instalar OpenEdge .
Para obtener más información sobre las diferencias entre las instancias de desarrollo y producción de PAS para OpenEdge, consulte Instancias
de desarrollo versus producción .
Después de instalar OpenEdge, use pasman crear para crear una instancia de prueba. Esta instancia actúa como
puesta en escena área para implementar su aplicación existente en una instancia de producción antes de pasar a un entorno en vivo. Si bien los
comandos de Windows generalmente se muestran aquí, UNIX tiene comandos equivalentes que producen resultados similares. Se incluyen notas donde
sea útil.
1. Abra la aplicación Proenv usando el menú de inicio de Windows, o ubicándola en $ DLC / bin / proenv.sh.
Proenv establece las variables de entorno y las rutas para ejecutar comandos de OpenEdge.
Nota: $ DLC es una sintaxis de variable de entorno de estilo UNIX para el directorio de su instalación Progress. En Windows, use% % DLC para ir
al directorio de instalación de Progress.
2. Cambie al directorio de trabajo de OpenEdge ($ WRKDIR o% WRKDIR%), que es donde tu nueva instancia
se crea y se almacenan los archivos y registros relacionados. En este ejemplo, el directorio se llama WRK:
3. Ejecutar el pasman crear comando para crear una instancia nombrada llamada myProdInstance:
pasman. {sh | bat} create -v -p 8817 -P 8818 -m myAdmin: myPwd -Z prod myProdInstance
• - pag : Puerto TCP que escucha mensajes HTTP. Este ejemplo usa 8817.
• - PAG : Puerto TCP que escucha mensajes HTTPS. Este ejemplo usa 8818.
• - m uid: pwd : Combinación de nombre de usuario y contraseña que reemplaza al predeterminado tomcat: tomcat utilizado por Apache
Tomcat. El ejemplo usa myAdmin: myPwd solo con fines de demostración.
• - Z : Identifica el modelo de seguridad de la instancia. pinchar para bloquear el servidor con la configuración de seguridad del servidor de producción. Esta
opción deshabilita las cuentas de desarrollo y los transportes de forma predeterminada.
• nombre_ruta_instancia : Especifica la ruta absoluta al directorio donde se crea la instancia y el nombre de la instancia. El
ejemplo usa myProdInstance. Si no se especifica ninguna ruta, la instancia se crea en el directorio actual. En este ejemplo, la
instancia se crea en el directorio actual y recomendado,
WRK, porque no se especifica ninguna ruta.
Nota: los pasman El comando administra y configura instancias PAS utilizando una variedad de comportamiento. los
crear action crea una nueva instancia a partir de una plantilla. Se necesitan varios obligatorios y opcionales opciones.
Para obtener más información sobre las opciones de PASMAN, escriba Pasman ayuda a crear en la ventana de Proenv, o ver
Utilice PASMAN para crear una instancia .
4. correr prueba de pasman para confirmar que el ProtocolHandlers inicialice en el puerto que proporcionó.
los prueba de pasman El comando muestra las variables de entorno PAS para OpenEdge y confirma que el servidor puede inicializarse.
OpenEdge proporciona una herramienta de migración llamada paspropconv en $ DLC / contenedor directorio de la instalación de OpenEdge. La utilidad
paspropconv crea un archivo temporal de cambios llamado ubrokername. emerger que deben revisarse antes de fusionarse con el openge.properties archivo
de la nueva instancia.
1. Asegúrese de tener acceso a un ubroker.properties archivo para su aplicación clásica de AppServer. por
los propósitos de este tutorial, mueva el ubroker.properties archivo y el contenido del
classicAppServerCode directorio al directorio de trabajo usando Proenv. Por ejemplo:
2. Cambiar al nombre de instancia/ conf directorio para ejecutar la herramienta de conversión en una ubicación donde el
Se almacenan los archivos de configuración. Por ejemplo:
3. Ejecute la utilidad paspropconv que toma un ubroker.properties archivo como entrada y crea un
fusionar archivo con propiedades convertidas y recomendaciones para su nuevo servidor. Esta herramienta está escrita en Perl y utiliza guiones dobles (-)
para ejecutarse correctamente. Para este ejemplo, el classicAppServerCode El directorio contiene archivos existentes de una aplicación clásica de
AppServer:
paspropconv
- - ubrokerPropsFile C: \ OpenEdge \ WRK \ classicAppServerCode \ ubroker.properties
- - ubrokerName UBroker.AS.app_customername_prod
- - pasoeAppName myProdInstance
Dónde:
La utilidad paspropconv genera los siguientes archivos en el directorio actual ( nombre de instancia/ conf):
1. Desde el directorio donde ejecutó la utilidad paspropconv (por ejemplo, nombre de instancia/ conf), mueve el
archivo de variable de entorno para su sistema operativo en el nombre de instancia/ compartimiento directorio. Por ejemplo:
(SO UNIX)
> mv nombre_cliente_aplicación_prod_setenv.sh ../bin
Nota: Cada configuración de servidor es diferente. Lee cada sección en el emerger archivo y ajuste su entorno en consecuencia.
Las propiedades sin comentar en la parte inferior de la emerger archivo son las propiedades que se fusionarán en el
openge.properties archivo para su nueva instancia. Revise y actualice las propiedades sin comentarios según la configuración de su servidor.
Preste especial atención a las entradas PROPATH y las conexiones de la base de datos.
5a. Actualice las entradas de PROPATH en el archivo oemerge (donde sea necesario)
Confirme o actualice las entradas PROPATH para que apunten a cualquier ubicación de código adicional o compartida. Algunos subdirectorios de su PROPATH pueden
apuntar a su antiguo servidor. Actualice estas entradas para que apunten a las ubicaciones en su nuevo servidor, o asegúrese de tener acceso a las ubicaciones de los
archivos antiguos y que estén especificadas en su PROPATH. En este ejemplo, actualizará PROPATH para que apunte a la ubicación de los procedimientos de eventos
en la instancia PAS para OpenEdge.
sessionShutdownProc = session_shutdown.p
sessionStartupProc = session_startup.p
2. Si su configuración clásica de AppServer usó un directorio llamado eventos para almacenar el inicio y el apagado
procedimientos, luego copie ese directorio en su nuevo servidor. Por ejemplo:
(SO UNIX)
3. Haga referencia a la ubicación de su nuevo eventos directorio en la sección PROPATH de su emerger archivo, o
asegúrese de que su nuevo servidor aún tenga acceso a la ubicación del directorio anterior. Por ejemplo, agregue la siguiente entrada a su
PROPATH en el [ AppServer.Agent.app_name] parte de su archivo oemerge:
[AppServer.Agent.myProdInstance]
PROPATH = $ {CATALINA_BASE} / openge, $ { CATALINA_BASE} / openge / events, [...]
Nota: los eventos directorio es una entrada en una lista de muchas en PROPATH. Mantenga el resto de las entradas iguales o cámbielas
si tiene ubicaciones adicionales para su código.
Nota: PAS para OpenEdge no admite el acceso al registro de Windows. Utilice el entorno o las variables del sistema Java.
5b. Actualice las conexiones de la base de datos en el archivo oemerge (donde sea necesario)
Puede hacer referencia a la base de datos de la aplicación AppServer clásica existente actualizando su archivo. pf archivo que se conecta a la base de datos, o
actualizando la cadena de conexión de la base de datos directamente en su emerger archivo bajo el
agentStartupParam propiedad. En este ejemplo, copiará la base de datos OpenEdge predeterminada al directorio de trabajo y se conectará a esa base de datos
mediante un archivo. pf archivo.
1. Si su aplicación AppServer clásica existente usa archivos de parámetros (. pf) para conectarse a una base de datos o inicializar
otros valores, luego confirme que esos archivos están disponibles para el nuevo servidor, o cámbielos para que apunten al
ubicación correcta del archivo en el agentStartupParam propiedad en [ AppServer.SessMgr.app_name]. por
ejemplo:
[AppServer.SessMgr.myProdInstance]
agentLogEntryTypes = ASPlumbing, DB.Connects
agentStartupParam = -T "C: \ OpenEdge \ WRK \ myProdInstance / temp" - pf C: \ OpenEdge \ WRK \
classicAppServerCode \ database.pf
Nota:
El contenido del. pf El archivo debe especificar la cadena de conexión de la base de datos. Por ejemplo:
Para configurar una nueva conexión de base de datos utilizando la base de datos de muestra proporcionada con la instalación de OpenEdge, siga estos pasos:
1. En su directorio de trabajo, cree un directorio llamado base de datos utilizando Proenv. Por ejemplo:
cd% WRKDIR%
base de datos mkdir
2. Ejecutar el procopia comando para copiar la base de datos sports2020 del $ DLC directorio al $ WRKDIR:
Nota: Sports2020 es la base de datos de muestra de OpenEdge que se envía con OpenEdge 12. Si está ejecutando OpenEdge 11.7, utilice deportes2000
como fuente de la base de datos.
3. ( Opcional) Edite el emerger archivo para usar la base de datos Sports2020 en el inicio del agente:
[AppServer.SessMgr.myProdInstance]
agentStartupParam = -T "$ {catalina.base} / temp" - db
C: \ OpenEdge \ WRK \ database \ sports2020
Nota: En el ejemplo anterior, el database.pf El archivo apunta a la misma ubicación que la cadena de conexión directa a la base
de datos en el agentStartupParam la propiedad. agentStartupParam
asignado al database.pf archivo si contiene la ruta correcta a su base de datos.
2. Para aplicar los cambios de su emerger archivo, utilice la utilidad oeprop para fusionar las propiedades convertidas en
los openge.properties archivo para su nuevo servidor. Por ejemplo:
Nota: Para obtener más información sobre la utilidad oeprop, escriba oeprop -ayuda en la ventana de Proenv, o ver
OEPROP .
3. Verifique que los cambios se fusionaron revisando el openge.properties archivo en el nombre de instancia/ conf
directorio. Las siguientes propiedades (entre otras) se actualizaron si utilizó los archivos del tutorial:
[myProdInstance.ROOT.APSV]
adapterEnabled = 1
[AppServer.SessMgr.myProdInstance]
agentStartupParam = -T "$ {catalina.base} / temp" pf
C: \ OpenEdge \ WRK \ classicAppServerCode \ database.pf
[AppServer.Agent.myProdInstance]
PROPATH = $ {CATALINA_BASE} / openge, $ {CATALINA_BASE} / opensge / events, $ {CATALINA_BASE} / webapps / ROOT / WEB-INF / opensge, [.
..]
sessionShutdownProc = session_shutdown.p
sessionStartupProc = session_startup.p
1. Mueva su código de servidor (es posible que no todos los tipos de conexión sean necesarios para su aplicación):
Dependiendo de su base de código, deberá completar algunas o todas las secciones aplicables para mover su código al transporte adecuado. Este
tutorial muestra los cambios en el código del servidor de aplicaciones y del cliente ABL.
Puede ejecutar su código de AppServer clásico existente desde la ubicación actual, o puede aprovechar esta oportunidad para organizar ese código en el
código de aplicación recomendado y en los directorios de códigos comunes.
Mueva el código del servidor existente a estas ubicaciones recomendadas para promover la seguridad, escalabilidad, extensibilidad y una implementación más sencilla:
• Para el código de la aplicación, mueva el código compilado a nombre de instancia/ webapps / ROOT / WEB-INF / opensge.
• Para el código común utilizado por varias aplicaciones, mueva el código compilado a nombre de instancia/ openge.
Mueva el código de su servidor ABL a una ubicación en su nueva instancia de PAS para OpenEdge. Este ejemplo utiliza el código de muestra del classicAppServerCode
directorio, pero se puede acceder a todo el código del servidor ABL de manera similar.
Este tutorial ejecuta código de muestra usando la aplicación web ROOT (predeterminada) en una instancia PAS para OpenEdge. Moverá el código
del servidor al nombre de instancia/ abierto directorio.
Nota: Revisa el ServerGetCustNameSample.p para asegurarse de que haga referencia al mismo nombre de la base de datos a la que se conectará su
servidor. Para OpenEdge 12, la base de datos es deportes2020. Para OpenEdge 11.7, la base de datos es deportes2000.
2. Verifique que su nombre de instancia/ conf / openge.properties incluye las entradas necesarias en el
agentStartupParam propiedades para hacer referencia a su base de datos.
• Si hace referencia a la base de datos directamente, asegúrese de que agentStartupParam La cadena de conexión de la base de datos
apunta a la ubicación correcta de la base de datos. Por ejemplo:
[AppServer.SessMgr.myProdInstance]
agentStartupParam = -T "C: \ OpenEdge \ WRK \ myProdInstance / temp" -db C: \ OpenEdge \ WRK \
database \ sports2020.db
• Si está almacenando la ubicación de la base de datos en un archivo. pf archivo, luego asegúrese de que el. pf archivo apunta a la ubicación correcta de la base de
Nota: Asegúrese de haber actualizado las conexiones de la base de datos en el emerger archivo (cuando sea necesario) como se describe en Prepárese
para pasar de Classic AppServer a PAS para OpenEdge , incluida la copia de la base de datos Sports2020 al% WRKDIR% \ base de datos directorio
usando procopia.
Nota: Si te mueves un clásico estado-reset o consciente del estado aplicación, debe configurar especial conectar
y desconectar procedimientos de eventos. Para más información, ver Migrar los modos operativos clásicos de AppServer .
Nota: Este paso no es necesario si está utilizando el código del tutorial de muestra. Se incluye como referencia para mover el código de la aplicación
WebSpeed a PAS para OpenEdge.
1. Mueva los archivos estáticos (imágenes y páginas HTML), desde su aplicación WebSpeed al
nombre de instancia/ webapps / ROOT / static directorio.
2. Revise la entrada PROPATH en el nombre de instancia/ conf / openge.properties archivo para asegurarse
que incluye código compilado para su aplicación WebSpeed.
[myProdInstance.ROOT.WEB]
defaultHandler = OpenEdge.Web.CompatibilityHandler
Para obtener más información sobre el código WebSpeed, consulte Migrar aplicaciones WebSpeed a PAS para OpenEdge .
Nota: Este paso se puede realizar utilizando el código del tutorial de muestra, pero no es necesario si no se están migrando los servicios REST de AppServer
clásicos a PAS para OpenEdge. Se incluye como referencia para mover el código de la aplicación REST a PAS para OpenEdge.
Una aplicación REST clásica de AppServer. guerra o. Código Postal El archivo no se puede implementar en PAS para OpenEdge. Si tiene una aplicación REST
de AppServer clásica. guerra, luego descomprima el archivo y despliegue la aplicación. paar
o exporte el archivo desde Progress Developer Studio para OpenEdge.
Nota: Los archivos del tutorial de muestra admiten los siguientes recursos del servicio REST:
• / classicRESTService / clientes
3. Ejecutar el deployREST comando con la ruta al. paar archivo y el nombre de la aplicación web ABL.
Por ejemplo:
5. En el openge.properties archivo, habilite el transporte REST para la aplicación web ABL que admite
el servicio REST. Por ejemplo, si la aplicación ROOT admite el servicio REST, establezca la siguiente propiedad:
[myProdInstance.ROOT.REST]
adapterEnabled = 1
6. Cuando se esté ejecutando PAS para OpenEdge, pruebe las conexiones del servicio REST con las siguientes URL:
Nota: los 3005 es un ID de cliente en el Deportes2020 base de datos que se incluye con OpenEdge 12. Si está utilizando la Deportes2000 base
de datos, uso 1 como ID de cliente. Además, si está implementando en una aplicación web ABL que es diferente de RAÍZ, incluir el nombre
de la aplicación web ABL en la URL antes de / descanso segmento. Por ejemplo:
El comando deployREST admite descriptores de servicio REST adicionales distintos de. paar archivos, incluyendo
. Código Postal archivos que contienen archivos de catálogo móvil (u otros archivos estáticos).
Nota: no implementar el administrador REST ( oerm.war) con PAS para OpenEdge porque los archivos de soporte ya están incluidos en el
servidor.
Para obtener más información sobre deployREST, consulte Implementar servicios REST .
Nota: Este paso no es necesario si está utilizando el código del tutorial de muestra. Se incluye como referencia para mover el código de la aplicación SOAP a
PAS para OpenEdge.
Los adaptadores de servicios web (WSA) no son necesarios para los clientes SOAP. PAS para OpenEdge incluye el soporte de transporte SOAP necesario.
1. Copie el código que admite la API de la interfaz SOAP en una de las ubicaciones de PROPATH.
Dónde:
Para obtener más información sobre deploySOAP, consulte Implementar servicios SOAP .
Antes de iniciar su instancia de PAS para OpenEdge, asegúrese de que el servidor de base de datos esté funcionando.
1. Usando Proenv, inicie el servidor de la base de datos usando el proservar comando, si aún no se está ejecutando. por
ejemplo:
La base de datos se ha iniciado correctamente cuando ve el Inicio de sesión multiusuario y Iniciar sesión por
mensajes.
• Si tu openge.properties hace referencia a la cadena de conexión de la base de datos directamente, asegúrese de tener la ruta absoluta
correcta. Por ejemplo:
[AppServer.SessMgr.myProdInstance]
agentStartupParam = -T "C: \ OpenEdge \ WRK \ myProdInstance / temp" -db C: \ OpenEdge \ WRK \
database \ sports2020.db
• Si tu openge.properties hace referencia a la cadena de conexión de la base de datos a través de a. pf archivo, asegúrese de que el. pf archivo contiene
la ruta absoluta correcta. Por ejemplo:
1. Para iniciar la instancia, ejecute pasman pasoestart. Esto carga tu nuevo openge.properties archivo que
habilita el transporte APSV en su instancia de producción, una configuración que está deshabilitada de manera predeterminada en una nueva instancia de producción.
Dónde:
- reiniciar Si la instancia ya se está ejecutando o está bloqueada, intente detenerla y luego ejecute un inicio completo. Si la
instancia ya está en estado detenido, esta opción no tiene ningún efecto.
2. Vea el archivo de registro del agente de la aplicación en un editor de texto para asegurarse de que el agente se inició correctamente y para ver si su
El archivo de registro del agente se puede ver en nombre de instancia/ registros / Nombre de la aplicación. agente. fecha. Iniciar sesión.
El archivo de registro del agente debe contener estos tipos de entradas que indican que el inicio del agente, la conexión a la base de datos y la ejecución del
procedimiento de inicio fueron exitosos:
2019-10-04T14: 09: 54.939-0400 027876 010356 1 AS-Aux-0 mtapsv: - :? Inicio del agente de MSAS: Progress OpenEdge Release 12.1
build 1135.
2019-10-04T14: 09: 55.145-0400 027876 024664 1 AS-4?:?:? - (Procedimiento: 'session_startup.p' Línea: 24) ¡Este es
un procedimiento de evento de inicio de sesión!
• Revise los registros en el nombre de instancia/ registros directorio para errores de inicio. los
nombre de instancia. agente.{ fecha}. Iniciar sesión El archivo proporciona información sobre las conexiones del agente de la aplicación, incluidas las notificaciones de
conectividad de la base de datos.
• Vuelva a verificar las recomendaciones en el openge.properties archivo que fueron importados desde el emerger
archivo.
• Confirme que. pf archivo tiene la ruta correcta a la base de datos. Confirme que los
3. Detén tu instancia.
Todas las conexiones de cliente deben actualizarse para utilizar uno de los cuatro transportes, descritos en Bienvenido a PAS para OpenEdge . Esta tabla
resume esas actualizaciones:
OpenEdge
Cambiar los clientes del Adaptador de Internet AppServer (AIA) para usar el Desde:
transporte APSV
- URL
http: // Puerto host/ aia / Aia? AppService = brokername
A:
Cambiar la conexión del cliente ABL para utilizar el transporte APSV Desde:
A:
DESCANSO
Cambiar las URL del cliente para usar la aplicación web ROOT Desde:
A:
WSA
Cambie los clientes del Adaptador de servicios web (WSA) para utilizar el Desde:
transporte SOAP
- WSDL
http: // Puerto host/ wsa / wsa1 / wsdl? targetURI = urn: CustomerSvc
A:
- WSDL
http: // Puerto host/ jabón / wsdl? targetURI = urn: CustomerSvc
WebSpeed
A:
Para actualizar una conexión de cliente OpenEdge ABL, siga estos pasos:
SALIDA CERRADA.
DEJAR.
Nota: Si está utilizando OpenEdge 11.7, cambie la declaración de asignación de iCustNum = 3005 a
iCustNum = 10 en el ClassicClient.p archivo.
3. Reemplace las conexiones clásicas ( cConnect) parámetro con el parámetro de conexión actualizado, e indicar
que el sessionModel es Sin sesión. Por ejemplo:
cConnect = "- URL http: // localhost: 8817 / apsv -sessionModel Session-Free ".
SALIDA CERRADA.
DEJAR.
6. Abra el archivo de código del servidor. ServerGetCustNameSample.p —En un editor. El código toma un número de cliente como entrada y devuelve
un nombre de cliente:
Nota: No se requieren cambios en el código del servidor, ServerGetCustNameSample.p, si está ejecutando OpenEdge 12. Si está
usando OpenEdge 11.7, cambie el nombre de la base de datos de deportes2020 a
deportes2000 en el ServerGetCustNameSample.p archivo.
La prueba final es ejecutar una conexión de cliente que recopile datos de su base de datos.
1. Ejecute el código del cliente. Por ejemplo, abra el PASforOpenEdgeClient.p archivo en mpro usando lo siguiente
comando en Proenv y luego presione F1:
2. Verifique que su aplicación pueda conectarse y acceder a los datos de su base de datos:
Detén tu instancia
Cuando haya terminado de probar su servidor y ya no sea necesario, es una buena práctica detener la instancia.
1. Utilizar el pasman comando con el detener acción para detener una instancia en ejecución.
2. Vea el archivo de registro del agente de la aplicación en un editor de texto para asegurarse de que el agente se detuvo correctamente y para ver si
se ejecutó el procedimiento de apagado. Si está utilizando los archivos incluidos en este tutorial, el procedimiento de apagado escribe el siguiente mensaje en el
archivo de registro:
El archivo de registro del agente se puede ver en nombre de instancia/ registros / Nombre de la aplicación. agente. fecha. Iniciar sesión.
El archivo de registro del agente debe contener estos tipos de entradas que indiquen una ejecución exitosa del procedimiento de cierre, la desconexión de la
base de datos y el cierre del agente:
2019-10-04T14: 36: 42.252-0400 027876 019344 1 AS-4 ROOT: a: 0000001f - (Procedimiento: 'session_shutdown.p' Línea: 22) ¡Este
es un procedimiento de evento de apagado de sesión!
2019-10-04T14: 36: 42.279-0400 027876 010356 1 AS-Listener mtapsv: - :? Cierre completo del agente MSAS.
Para preparar la instancia de prueba para la versión de producción completa, continúe su aprendizaje con lo siguiente:
Aunque tanto PAS para OpenEdge como el clásico AppServer ejecutan aplicaciones comerciales ABL, la arquitectura y la configuración son fundamentalmente
diferentes. PAS para OpenEdge es un servidor de aplicaciones basado en un servidor web que utiliza aplicaciones web especiales para ejecutar código ABL. Tiene
todo el comportamiento y las características de un servidor web. Aunque muchos de los parámetros de configuración parecen ser similares, las herramientas y
técnicas para una implementación exitosa en el entorno de múltiples sesiones son diferentes. Para obtener más información sobre cómo configurar su instancia,
consulte el resultado de la herramienta de conversión de propiedades
En el entorno web, rastrear los últimos cambios de seguridad es extremadamente importante. El producto PAS para OpenEdge se actualiza continuamente
con nuevas funciones, corrección de errores y parches de seguridad. Manténgase actualizado para mantener su aplicación segura y estable.
Utilice archivos de propiedades para cambiar PAS para los valores de configuración de OpenEdge
Aunque PAS para OpenEdge se basa en Apache Tomcat, PAS para OpenEdge ha simplificado la configuración y el inicio subyacentes de
Tomcat para la administración local y remota. En lugar de realizar cambios en el
nombre de instancia/ conf / server.xml o nombre de instancia/ bin / setenv. [bat | sh] archivos directamente, PAS para
Usos de OpenEdge archivos de propiedad y archivos de script extensibles para el cliente. Para más información, ver Archivos de propiedad .
Compruebe todos los archivos de registro de PAS para OpenEdge en busca de errores
La solicitud de un cliente atraviesa múltiples PAS para subsistemas OpenEdge, cualquiera de los cuales puede generar un error de ejecución. El registro del error se
produce en el archivo de registro específico del subsistema. Compruebe siempre todos los archivos de registro en el nombre de instancia/ registros directorio cuando
investiga errores de ejecución. Para más información, ver Archivos de registro .
Detener una instancia de PAS para OpenEdge puede llevar algún tiempo
Detener una instancia de PAS para OpenEdge puede llevar varios minutos en algunos casos. Incluso puede parecer colgado. PAS para OpenEdge (Tomcat)
tiene una política que permite que sus aplicaciones web finalicen las solicitudes de los clientes antes de detenerse. Un PAS normal para OpenEdge detener no
siempre detiene todos sus procesos. Si desea que PAS para OpenEdge no espere a que finalicen las solicitudes del cliente antes de detenerse, utilice el parada
de pasman comando con el
- F opción para forzar el apagado.
El registro de acceso es de gran ayuda cuando soluciona problemas de conexión del cliente, tiempos de respuesta máximos, fallas de inicio de sesión del cliente por
parte de piratas informáticos, y mucho más. Aunque el registro de acceso utiliza una pequeña cantidad de tiempo de procesamiento y espacio en disco, no puede
obtener esta información fácilmente de otras fuentes y puede ser útil para monitorear el estado de su servidor y ajustar su tiempo de ejecución. Ver el Apache Tomcat Referencia
®
de configuración.
La detección de hilos atascados de Apache Tomcat identifica las solicitudes que tardan mucho en procesarse, lo que puede indicar que algo está mal en la
ejecución de la solicitud. La detección de subprocesos atascados es un mecanismo de alerta que registra un mensaje para las solicitudes que tardan más
de una cantidad de tiempo configurable en completarse. Ver el Apache Tomcat Referencia de configuración.
®
En UNIX, PAS para la instalación de producción de OpenEdge y la adaptación de instancias elimina todo acceso de cualquier cuenta de usuario. Una vez que se
completa una instalación de OpenEdge, sus instancias se configuran para ser iniciadas, detenidas, configuradas y monitoreadas por la cuenta de usuario raíz
(requerido por el instalador de OpenEdge). Si toda la administración de su sistema operativo se realiza a través de la cuenta de usuario raíz, no es necesario realizar
ninguna acción. Si sigue las mejores prácticas y nunca utiliza la cuenta de usuario raíz del sistema operativo, deberá cambiar los permisos de archivo para los
ejecutables y scripts de instancia y núcleo. Ver el Permisos de usuario y archivo .
• Interesado en ver una demostración, mire y comparta el video: Mover sus aplicaciones clásicas de AppServer a Progress ® Servidor de
aplicaciones para OpenEdge ®
• Una administración del sistema que respalda el nuevo servidor, tome la capacitación en línea: Servidor de aplicaciones de progreso para la administración de
OpenEdge (1000-095)
• Al escribir nuevas aplicaciones REST para PAS para OpenEdge, aproveche las interfaces WebHandler basadas en ABL para el desarrollo de
aplicaciones web (como las API de servlet Java): Desarrollar un servicio ABL utilizando el transporte WEB
• Al migrar una aplicación clásica de restablecimiento de estado o con reconocimiento de estado, configure procedimientos especiales de eventos de conexión y desconexión: Migrar
• Ajuste de PAS para OpenEdge para rendimiento: Ajuste PAS para instancias de OpenEdge
• Registro, anulación del registro o eliminación de PAS para instancias de OpenEdge: Cree y configure PAS para instancias de OpenEdge .
• Registro de una instancia de PAS para OpenEdge como un servicio de Windows: Registrar una instancia de PAS para OpenEdge como servicio de Windows .
• Gestión de PAS para OpenEdge con OpenEdge Management: Más información sobre PAS para OpenEdge y OpenEdge Management .
Este contenido describe los conceptos necesarios para migrar el código ABL a PAS para OpenEdge, que incluyen:
• Diferencias en los procedimientos de eventos entre el clásico AppServer y PAS para conexiones de base de datos
• Rutas y directorios del sistema de archivos en PAS para OpenEdge Migre las
• Instalar en pc directorios
• Ejemplo directorios
• Solicitud directorios
• Servicio directorios
Instalar directorios
El PAS para OpenEdge Instalar en pc El directorio le permite tener un comportamiento predeterminado en todas las instancias. Tener este
comportamiento separado en la estructura del directorio de instalación facilita la actualización a una nueva versión del servidor PAS para OpenEdge sin
perder las personalizaciones que se realizaron en las instancias individuales.
Directorios de instancias
los ejemplo Los directorios le permiten personalizar cada instancia. Los cambios realizados en el nivel de instancia anulan los del nivel de instalación.
Cada instancia contiene las siguientes estructuras y contenido relacionado:
• compartimiento —OpenEdge y utilidades y bibliotecas personalizadas que se adaptan a esa instancia específica. Por ejemplo, las utilidades de OpenEdge están diseñadas
para utilizar el espacio de archivos de la instancia local, pero cargan y utilizan las bibliotecas y utilidades compartidas instaladas.
• común / lib : Archivos y bibliotecas de Java que se comparten entre todas las aplicaciones web de la instancia.
Nota: El directorio de instalación del servidor también tiene un común / lib directorio que contiene las bibliotecas de Java y los archivos compartidos por todas las
• conf —Los archivos de configuración de Tomcat, OpenEdge y personalizados para la instancia que controlan solo las aplicaciones
implementadas en la instancia.
• registros : Los archivos de registro de la instancia del servidor, incluidos todos los archivos de registro de la aplicación del servidor, la aplicación web, OpenEdge y ABL.
• abierto -Los . pag y. r archivos y archivos de soporte solo para aplicaciones ABL. Otras aplicaciones web de Progress y de terceros no pueden
escribir ni leer desde este directorio.
• temperatura —Archivos temporales generados por la aplicación. Un administrador puede eliminar estos archivos como parte de la limpieza antes de
reiniciar la instancia del servidor.
• webapps | webapps-ref : Un directorio, o una referencia a un directorio, que contiene las aplicaciones web de Tomcat, OpenEdge y ABL
escritas por el cliente para la instancia.
Nota: El administrador no debe eliminar estos archivos como parte de la limpieza antes de reiniciar una aplicación.
Para obtener más información sobre PAS para instancias de OpenEdge, consulte Instancias .
Directorios de aplicaciones
Un típico Aplicación web ABL La estructura del directorio puede seguir el modelo establecido por la aplicación web OpenEdge ABL ( oeabl.war).
Copias de oeabl.war se puede implementar en su instancia desde el
$ DLC / servidores / pasoe / extras directorio.
• / apsv —Una ruta de URI reservada para conexiones de cliente OpenEdge (se puede desactivar).
• /jabón —Una ruta de URI reservada para conexiones de cliente SOAP OpenEdge (se puede deshabilitar).
• /descanso —Una ruta de URI reservada para clientes REST de OpenEdge (se puede desactivar).
• /web —Una ruta de URI reservada para aplicaciones clásicas de WebSpeed y nuevos clientes REST (se puede desactivar).
• estático : Un directorio que contiene archivos estáticos, incluidas imágenes, hojas de estilo y páginas HTML.
• META-INF —Un directorio obligatorio que contiene metadatos y context.xml definiciones específicas de la aplicación web. OpenEdge
utiliza un context.xml para la aplicación web y el sitio de implementación puede adaptarlo para cumplir con los requisitos de seguridad.
• WEB-INF : Un directorio obligatorio que contiene el archivo de configuración de la aplicación web ( web.xml), Archivos de configuración de Spring Security y otros
archivos privados de la aplicación.
• adaptadores —Árbol de directorio OpenEdge que contiene los archivos de implementación REST y SOAP.
• lib : Directorio obligatorio que contiene las bibliotecas de Java específicas de la aplicación web.
• clases : Directorio obligatorio que contiene las clases de Java o los archivos de datos específicos de la aplicación web.
• abierto —Directorio proporcionado por OpenEdge donde los desarrolladores de ABL pueden distribuir sus archivos de aplicaciones ABL que se aplican
específicamente a la aplicación web.
Para obtener más información sobre las aplicaciones web ABL en PAS para instancias de OpenEdge, consulte aplicaciones web .
Si bien una aplicación ABL podría ubicar físicamente sus archivos en cualquier lugar del sistema de archivos del SO, ubicarlos dentro del PAS para instancias
de aplicaciones web OpenEdge promueve el escalado, la extensibilidad y la implementación. Al organizar los archivos, es más fácil:
• Implemente una aplicación ABL (identificada por su nombre) en una instancia PAS para OpenEdge existente.
• Asegure una aplicación configurándola como de solo lectura. Por ejemplo, común. r y. pag archivos utilizados en varias aplicaciones
web ubicadas en el openge / * directorios de la instancia.
• Una o más aplicaciones web como oeabl.war que se puede implementar en una instancia PAS para OpenEdge existente. Se utilizan para alojar
el acceso de transporte APSV, SOAP, REST y WEB a la lógica empresarial de ABL.
Para obtener más información sobre las aplicaciones ABL en PAS para instancias de OpenEdge, consulte Aplicaciones ABL .
Un servicio ABL es una ruta dependiente del transporte hacia la lógica comercial de una aplicación ABL (entidades comerciales). Los nombres de los servicios ABL
se definen durante el desarrollo y no cambian durante la implementación.
libre de estado. Cada instancia clásica de AppServer solo se ejecuta en un solo modelo. Debía iniciar varios AppServers clásicos para
admitir varios modelos de sesión y modos de funcionamiento.
Los tres modos de funcionamiento en el AppServer clásico produjeron diferentes requisitos para implementar conexiones de cliente administradas por sesión. En
algunos modos administrados por sesión, el contexto de solicitud del cliente de la sesión se conserva entre las solicitudes del cliente porque el cliente fue Unido a
una sola sesión ABL. Otros modelos administrados por sesión dan como resultado que la aplicación ABL administre manualmente el contexto de la solicitud del
cliente en una tienda externa porque cada solicitud se ejecuta en una sesión ABL diferente.Cuando un cliente usa el modelo sin sesión, la aplicación ABL administra
manualmente el contexto de la solicitud del cliente en una tienda externa porque todas las solicitudes de los clientes se ejecutan en una sesión ABL diferente.
En PAS para OpenEdge, el cliente continúa conectándose utilizando los modelos administrados por sesión o sin sesión, lo que da como resultado el mismo
comportamiento del lado del cliente que con el AppServer clásico. Sin embargo, el modelo de sesión se simplifica en PAS para OpenEdge, ya que ahora solo hay un
modelo de conexión compatible, HTTP / S. Al eliminar todos los demás modelos de conexión, los modelos de sesión (ahora llamados modelos de aplicación) convertirse
simplemente en una sesión administrada o libre de sesiones, donde cualquier PAS para instancia de OpenEdge es capaz de admitir ambos tipos simultáneamente.
Un PAS para conexión administrada por sesión OpenEdge es ligado condicionalmente a la misma sesión ABL según la configuración del SESIÓN:
SOLICITUD DE CONEXIÓN AL SERVIDOR atributo. Dependiendo de esta configuración, las optimizaciones del agente multisesión le proporcionan el
escalado de recursos del modo de funcionamiento sin estado del clásico AppServer con el rendimiento y la simplicidad de la gestión del contexto de sesión
de los modos de funcionamiento de restablecimiento de estado y reconocimiento de estado. Esto le proporciona lo mejor de ambos mundos.Cuando la
aplicación ABL requiere la máxima escalabilidad a nivel de solicitud, o la ejecución simultánea real de solicitudes de cliente, el modelo PAS para OpenEdge
sin sesión funciona con el mismo comportamiento que el clásico AppServer que se ejecuta en el modo de funcionamiento sin estado.
Con PAS para OpenEdge fusionando todos los modos de gestión de sesión del clásico AppServer, existen algunas diferencias entre cuándo se ejecutan los
procedimientos de eventos de una sesión de PAS para OpenEdge en comparación con los procedimientos de configuración del AppServer clásico
correspondiente. La mayoría de los cambios son transparentes. Sin embargo, en algunos casos, debe realizar ajustes si desea que sus sesiones ABL en el
servidor ejecuten procedimientos de eventos con el mismo comportamiento que los procedimientos de configuración en AppServer.
Las siguientes tablas comparan la ejecución del procedimiento de configuración en el AppServer clásico y la ejecución del procedimiento de evento en PAS para
OpenEdge:
Activar Nunca (1); Condicional (2) Siempre PAS para OpenEdge sigue el
comportamiento sin estado clásico,
Mientras
SESIÓN: SERVIDOR-
CONEXIÓN VINCULADA =
FALSO
Desactivar Nunca (1); Condicional (2) Siempre PAS para OpenEdge sigue el
comportamiento sin estado clásico,
Mientras
SESIÓN: SERVIDOR-
CONEXIÓN VINCULADA =
FALSO
Activar Nunca (1); Condicional (2) Siempre PAS para OpenEdge sigue el
comportamiento sin estado clásico,
Mientras
SESIÓN: SERVIDOR-
CONEXIÓN VINCULADA =
FALSO
Desactivar Nunca (1); Condicional (2) Siempre PAS para OpenEdge sigue el
comportamiento sin estado clásico,
Mientras
SESIÓN: CONEXIÓN AL SERVIDOR VINCULADA
= FALSO
= FALSO
= FALSO
1. Los modos de funcionamiento clásico de AppServer de restablecimiento de estado y reconocimiento de estado nunca ejecutan el evento Activate o Deactivate
procedimientos.
2. El modo de funcionamiento sin estado de AppServer clásico siempre ejecuta los procedimientos de activación y desactivación, a menos que
3. El modo de funcionamiento sin estado Classic AppServer siempre ejecuta los procedimientos Activar y Desactivar a menos que
el cliente está en un estado ligado.
Cuando un cliente PAS para OpenEdge se conecta utilizando el modelo de aplicación administrada por sesión, de forma predeterminada, las sesiones del servidor
ejecutan las solicitudes de este cliente en el estado independiente, similar al modo operativo sin estado clásico. Al igual que en el AppServer clásico, puede cambiar la
conexión del cliente al estado vinculado haciendo que el cliente ejecute un procedimiento persistente remoto o haciendo que la sesión del servidor establezca el
SESIÓN: SOLICITUD DE CONEXIÓN AL SERVIDOR atribuir a CIERTO. Entonces, para emular el comportamiento del
los modos de funcionamiento clásico de restablecimiento de estado y reconocimiento de estado de AppServer, debe establecer este atributo de manera adecuada en los
procedimientos de evento Connect y Disconnect de la instancia PAS para OpenEdge. Además, para emular el modo operativo clásico de restablecimiento de estado de
AppServer, debe ejecutar DEJAR como la última declaración del procedimiento de desconexión.
Cuando un cliente PAS para OpenEdge se conecta utilizando el modelo de aplicación sin sesión, las sesiones del servidor también ejecutan solicitudes de
este cliente en el estado independiente, similar al modo operativo clásico sin estado. Al igual que en el AppServer clásico, puede cambiar la conexión del
cliente al estado vinculado haciendo que el cliente ejecute un procedimiento persistente remoto, pero también como en el AppServer clásico, la sesión
administrada SESIÓN los atributos de control no tienen función. Por ejemplo, configurar el SESIÓN: SOLICITUD DE CONEXIÓN AL SERVIDOR
atribuir a CIERTO en una sesión de servidor que se ejecuta en el estado no vinculado no tiene ningún efecto.Solo puede saber que la conexión está
vinculada consultando el SESIÓN: CONEXIÓN AL SERVIDOR VINCULADA atributo. Y, como en el caso del clásico AppServer, Progress recomienda que Nunca
Haga que los clientes de PAS para OpenEdge ejecuten procedimientos persistentes remotos para establecer una conexión sin sesión.
Por lo tanto, si está migrando una aplicación desde un AppServer clásico sin estado o sin estado, su aplicación no debería requerir cambios en el código
ABL para lograr el mismo comportamiento en PAS para OpenEdge.
Los siguientes temas detallan los cambios que podrían ser necesarios para que coincida con su comportamiento clásico de AppServer en particular.
Para lograr el mismo cliente Unido y Reiniciar comportamiento en PAS para OpenEdge como en un AppServer de restablecimiento de estado clásico, incluya lo
siguiente como la primera declaración en su procedimiento de evento Connect:
Este código deshabilita la ejecución de los procedimientos de evento Activate y Deactivate para las solicitudes del cliente a través de esta conexión hasta que este atributo se
establezca en FALSO, pero las deja disponibles para su uso por conexiones de cliente sin sesión.
También incluya lo siguiente como las últimas declaraciones antes de salir de su procedimiento de evento Disconnect:
los DEJAR La declaración en PAS para OpenEdge realiza efectivamente la misma operación de restablecimiento de sesión ABL que ocurre en el AppServer clásico
después de que se ejecuta el procedimiento de evento Disconnect.
Para lograr el mismo cliente Unido comportamiento en PAS para OpenEdge como en un AppServer clásico con reconocimiento de estado, incluya lo siguiente como
la primera declaración en su procedimiento de evento Connect:
Esto deshabilita la ejecución de los procedimientos de evento Activate y Deactivate para las solicitudes del cliente a través de esta conexión hasta que este atributo se
establezca en FALSO, pero los deja disponibles para que los utilicen conexiones de cliente sin sesión.
También incluya lo siguiente como última declaración antes de salir del procedimiento de desconexión:
No se requieren cambios en los procedimientos de eventos para migrar aplicaciones que se ejecutan en un AppServer clásico sin estado.
No se requieren cambios en los procedimientos de eventos para migrar aplicaciones que se ejecutan en un AppServer clásico sin estado.
PAS para OpenEdge tiene solo dos modos de funcionamiento (modelos de aplicación): administrado por sesión y sin sesión. El modo de funcionamiento clásico
de AppServer sin estado se asemeja más a la gestión de sesión. State-freepartidos sin sesión. Si su aplicación se ejecuta en modos de funcionamiento de
restablecimiento de estado o de reconocimiento de estado en el AppServer clásico, es posible que deba modificar los procedimientos de conexión y
desconexión para imitar estos modos cuando se ejecuta en PAS para OpenEdge. Para más información, ver Migrar los modos operativos clásicos de AppServer
en la página 37.
El agente multisesión PAS para OpenEdge tiene dos procedimientos de eventos de inicio y apagado adicionales que se ejecutan cuando el agente se inicia
y se apaga. La siguiente tabla describe el comportamiento de estos dos procedimientos. los Nombre del procedimiento columna enumera la propiedad en
openge.properties donde establece el nombre del procedimiento especificado:
Nota: los agentStartupProc El procedimiento se ejecuta en una sesión ABL separada dentro del agente multisesión. Los valores globales que crea
no son visibles para otras sesiones ABL.
El clásico AppServer proporciona procedimientos de eventos de inicio y apagado de sesiones ABL que le permiten administrar la inicialización y
limpieza de una sesión ABL. Las propiedades que controlan estos procedimientos de eventos usan el prefijo srvr, que refleja su identificación con los
procesos del servidor (agente) del clásico AppServer. Cada agente clásico de AppServer es una única sesión ABL que se ejecuta como un único
proceso de SO (AVM). Estos procedimientos de eventos siempre se han ejecutado como parte del inicio y cierre de la sesión ABL.
En PAS para OpenEdge, estas propiedades del procedimiento de inicio y cierre de sesión se renombran con el
sesión prefijo para reflejar mejor su asociación con sesiones ABL en lugar de procesos de servidor. Además, PAS para OpenEdge eliminó la ejecución
inconsistente producida por modelos de conexión que ya no existen (HTTP es el único). El agente multisesión en PAS para OpenEdge inicia sesiones
ABL bajo demanda para cumplir con la carga del cliente, y el agente multisesión se detiene Sesiones ABL cuando están inactivas durante un cierto
período de tiempo.
Nombrar
Ejecución
La siguiente tabla compara la ejecución de estos procedimientos en el clásico AppServer y PAS para OpenEdge. los Nombre del
procedimiento columna enumera la propiedad en openge.properties donde establece el nombre del procedimiento especificado:
Tabla 6: Comparación de los procedimientos de inicio y apagado de la sesión entre AppServer y PAS para OpenEdge
Nombre del procedimiento AppServer PAS para OpenEdge Corre en Parámetros de inicio
persistencia persistencia
sessionStartupProcParam
propiedad en
openge.properties
apagar
En todos los demás aspectos, los procedimientos de eventos de inicio y cierre de sesión son los mismos para el AppServer clásico y PAS para OpenEdge.
El clásico AppServer proporciona procedimientos de evento de conexión y desconexión de sesión ABL que le permiten administrar la inicialización y
limpieza de una sesión de servidor administrada por sesión. Debido a los diferentes modelos de conexión para el AppServer clásico, la ejecución y el
alcance de estos procedimientos varían en el AppServer clásico. Las propiedades que controlan estos procedimientos de eventos usan el prefijo srvr, que
refleja su identificación con los procesos del servidor (agente). Cada agente clásico de AppServer es una única sesión ABL que se ejecuta como un único
proceso de SO (AVM).
En PAS para OpenEdge, estas propiedades del procedimiento Conectar y Desconectar se renombran con el sesión
prefijo para reflejar mejor su asociación con sesiones ABL en lugar de procesos de servidor. Además, PAS para OpenEdge eliminó la
ejecución inconsistente producida por modelos de conexión que ya no existen (HTTP es el único).
Nombrar
Esta sessionDisconnProc El procedimiento es importante cuando migra una aplicación de restablecimiento de estado a PAS para OpenEdge. Debido a que no hay
"restablecimiento" de sesiones administradas por sesión en PAS para OpenEdge, debe escribir código adicional para restablecer la sesión y eliminar cualquier
información de contexto antes de que el próximo cliente utilice la sesión.
Ejecución
La siguiente tabla compara la ejecución de estos procedimientos en el clásico AppServer y PAS para OpenEdge. los Nombre del
procedimiento columna enumera la propiedad en openge.properties donde establece el nombre del procedimiento especificado:
Tabla 7: Comparación de los procedimientos de conexión y desconexión entre AppServer y PAS para OpenEdge
desconectar y
cierre de sesión
Notas:
• El clásico AppServer srvrConnectProc El procedimiento persistente no se elimina a menos que el código de la aplicación ABL lo elimine
explícitamente. PAS para OpenEdge elimina automáticamente el sessionConnectProc procedimiento después de cerrar la conexión del cliente.
• El clásico AppServer sin estado srvrConnectProc y srvrDisconnectProc Los procedimientos se ejecutan en diferentes sesiones ABL. Debido a que PAS para
OpenEdge crea una conexión de cliente administrada por sesión vinculada a la misma sesión ABL, el sessionConnectProc y sessionDisconnectProc Los
procedimientos de eventos se ejecutan en la misma sesión ABL que todas las solicitudes del cliente (de la misma manera que funcionan los procedimientos
clásicos de configuración de AppServer con reconocimiento de estado y restablecimiento de estado).
• El AppServer clásico de restablecimiento de estado afecta al "restablecimiento" automático de la sesión ABL después de la desconexión del cliente. Para permitir que PAS
para OpenEdge emule este comportamiento clásico de restablecimiento de estado, sin modos de funcionamiento, ejecute un ABL DEJAR declaración al final de la sessionDisconnProc
después de configurar
• Un AppServer clásico de restablecimiento de estado o con reconocimiento de estado afecta el estado automático vinculado al cliente antes de
srvrConnectProc se ejecuta el procedimiento. Para permitir que PAS para OpenEdge emule este comportamiento, sin modos de funcionamiento,
configure el ABL SESIÓN: CLIENTE-SERVIDOR-SOLICITUD-VINCULADA atribuir a CIERTO al principio de sessionConnectProc procedimiento para
producir el mismo comportamiento. (Ver el
sessionActivateProc y sessionDeactivateProc propiedades en Activar y desactivar procedimientos
en la página 45.)
En En todos los demás aspectos, los procedimientos de evento Connect y Disconnect de la sesión ABL son los mismos para los
los srvrActivateProc y srvrDeactivateProc Los procedimientos son importantes si su aplicación utiliza los modos sin estado o sin estado del clásico
AppServer. Estos modos clásicos del AppServer requieren que usted administre manualmente el contexto del cliente y de la sesión porque cada solicitud
se ejecuta en una sesión ABL diferente. El procedimiento de Activación se ejecuta porque restaura el contexto guardado al final de la solicitud anterior del
cliente, y los procedimientos de Desactivación se ejecutan porque guarda el contexto para que lo utilice la siguiente solicitud del cliente. Debido a que no
hay operaciones formales de conexión y desconexión en los modos clásicos de AppServer, debe implementar su propia arquitectura de inicio / detención
de sesión de cliente.
El AppServer clásico ejecuta los procedimientos de Activate y Deactivate. La condición de vinculación del cliente se relaciona con el cliente de AppServer que
está vinculado a una sola sesión ABL donde se garantiza que cada solicitud del cliente se ejecutará en esa sesión ABL particular. Cuando el cliente está
vinculado a una sesión, no hay ningún requisito para que el código de la aplicación ABL se guarde y restaurar el contexto mediante los procedimientos de
activación y desactivación porque el contexto persiste mientras la sesión esté vinculada.
Siempre que una sesión ABL esté vinculada al cliente, no ejecutará los procedimientos de activación y desactivación. Los modos del AppServer clásico
influyen en la condición vinculada al cliente y en el código ABL de la aplicación. La siguiente tabla ayuda a ilustrar el comportamiento clásico de
AppServer:
Tabla 8: Comparación de los procedimientos de activación y desactivación entre AppServer y PAS para OpenEdge
Modo operativo Estado enlazado inicial Estado límite final Puede cambiar de límite
¿estado?
Los modos clásicos de AppServer sin estado y sin estado pueden cambiar el estado de no vinculado a vinculado y de vinculado a no vinculado en función
de dos condiciones:
• El procedimiento Activate se ejecuta antes del bloque principal del procedimiento persistente. El estado vinculado al cliente se
• Debido a que existe el estado vinculado al cliente, el procedimiento Desactivar no se ejecuta después de que se ejecuta el bloque principal del procedimiento
persistente.
• Los procedimientos de activación o desactivación no se ejecutan hasta que se borra el estado vinculado al cliente.
• El estado vinculado al cliente se borra cuando el cliente elimina el procedimiento persistente y el procedimiento Desactivar se ejecuta como parte
de la operación de eliminación.
2. Los conjuntos de códigos ABL clásicos de AppServer SESIÓN: SOLICITUD DE CONEXIÓN AL SERVIDOR a CIERTO ( apátrida
solamente).
• El procedimiento de desactivación no se ejecuta al final de la solicitud del cliente que establece el estado vinculado al cliente.
• Los procedimientos de activación o desactivación no se ejecutan hasta que el código de aplicación ABL que se ejecuta en el AppServer clásico
borra el estado vinculado al cliente.
• Cuando el código ABL de AppServer borra el estado vinculado al cliente, el procedimiento de desactivación se ejecutará cuando finalice el
procedimiento actual.
• La ejecución normal de Activación y Desactivación se reanuda en cada solicitud de cliente posterior después de que se borra el estado vinculado al cliente.
Al igual que el AppServer clásico, PAS para OpenEdge admite el estado vinculado al cliente, pero puede requerir cambios en el código ABL para obtener el mismo
comportamiento que los modos operativos de AppServer clásicos cuando un cliente está conectado con un modelo de aplicación determinado:
Modelo de aplicación Estado enlazado inicial Estado límite final Puede cambiar de límite
¿estado?
Las transiciones de enlazado a no enlazado y no enlazado a enlazado en PAS para OpenEdge siguen el mismo comportamiento que el clásico AppServer para
procedimientos persistentes ejecutados por el cliente o usando el
SESIÓN: SOLICITUD DE CONEXIÓN AL SERVIDOR atributo en el servidor. Del mismo modo, la secuencia de cambio de estado de PAS para los procedimientos de
activación y desactivación de OpenEdge sigue el comportamiento de los estados cambiantes vinculados al cliente para el AppServer. La diferencia entre el clásico
AppServer y PAS para OpenEdge es que para iniciar una sesión de servidor en el estado vinculado, debe cambiar el procedimiento de evento de conexión
administrado por sesión para establecer manualmente el estado vinculado al cliente Cuando fuerza manualmente un estado vinculado al cliente en PAS para
OpenEdge , asegúrese de que el estado vinculado al cliente se borre en el procedimiento de evento de desconexión administrado por sesión.
Nombrar
Sin embargo, la política de conexión de la base de datos de autoservicio cambia considerablemente. Las conexiones de autoservicio son un recurso
compartido en PAS para OpenEdge. Cada agente multisesión crea una única conexión de autoservicio que aparece en PROMON como su propia conexión
de usuario. Por lo tanto, cada sesión ABL que se ejecuta con un parámetro de conexión a la base de datos: db o que ejecuta un ABL CONECTAR La
declaración comparte la conexión de autoservicio de su agente gestor de sesiones múltiples y aparece en PROMON con su propia conexión de usuario.
Cada conexión de usuario de sesión ABL es específica para esa sesión. Una sola conexión de usuario de sesión ABL no vincula la conexión de usuario de
ninguna otra sesión ABL.
Dos nuevos Tipo Los valores, específicos de PAS para OpenEdge, se encuentran en la pantalla PROMON:
• AUTO / PASA - Conexión de base de datos de autoservicio compartida de un agente de múltiples sesiones
• AUTO / PASN - Usuarios de sesión ABL individuales que comparten la conexión del agente multisesión
Nota: Desconectando manualmente AUTO / PASA resulta en la desconexión todas Usuarios de sesión ABL que estaban usando la conexión de base de datos de
autoservicio compartida, lo que hace que se caiga toda la conectividad de la base de datos.
Declaración, atributo de identificador o propiedad de clase Comportamiento o rango de valores en PAS para OpenEdge
DEJAR declaración Borra el contexto de la sesión del servidor antes de finalizar la solicitud del
cliente actual y devolver la sesión al grupo de sesiones del agente para que
otros clientes accedan a ella.
SESIÓN: MODO DE FUNCIONAMIENTO DEL SERVIDOR atributo "Gestionado por sesión" o " Sin sesión "
La siguiente tabla enumera las nuevas opciones de instrucción ABL y propiedades de clase que se agregaron específicamente para PAS para OpenEdge:
simultáneamente
SESIÓN: CURRENT-REQUEST-INFO: TheadID Entero positivo Devuelve el ID del AVM que ejecuta la
propiedad de clase * sesión ABL actual dentro del agente
multisesión actual
Nota: Un asterisco (*) indica que este ID es dinámico y puede cambiar cada vez que se inicia una instancia de PAS para OpenEdge.
[Environment.asbroker1]
TESTENV = MYEN
En PAS para OpenEdge, no establece variables de entorno en archivos de configuración como ubroker.properties
en el clásico AppServer. En su lugar, configura las variables de entorno con estos métodos:
• Para configuraciones individuales - Agrega un proset.env archivo al $ WRKDIR. En el proset.env , configure las variables de entorno que
necesite su aplicación.
Nota: En plataformas UNIX, su myenv_setenv.sh El script no necesita estar marcado como ejecutable.
EXPORTAR cualquier variable de entorno definida en ese script para que otros procesos puedan usarlas.
PAS para OpenEdge se ejecuta en un entorno de servidor de aplicaciones web. Para que una aplicación ABL se ejecute de forma coherente y segura dentro de
ese entorno, la ubicación predeterminada de ciertas rutas del sistema de archivos debe ser diferente a la del AppServer clásico. La siguiente tabla muestra una lista
de diferencias conocidas:
Tabla 11: Rutas y directorios del sistema de archivos en PAS para OpenEdge y AppServer clásico
Directorio temporal CWD ( trabajo actual $ CATALINA_BASE / temp Reubicado en PAS para
directorio) Instancias de OpenEdge
temperatura directorio
Para los clientes de ABL, este es el CONECTAR() en el identificador del objeto del servidor utilizado para acceder a PAS para la instancia de
OpenEdge. Para OpenEdge Java y .NET Open Clients, se pasa un conjunto de parámetros al
Conexión constructor de objetos. Las URL de estos clientes utilizan el transporte APSV, pero no la ruta de servicio ni de recursos.
Para los clientes de servicios web OpenEdge SOAP, el archivo WSDL que implementa proporciona la información de URL para que los clientes de servicios web SOAP
accedan a sus objetos de servicio. Las URL de conexión para estos clientes utilizan el transporte SOAP seguido de una ruta WSDL que incluye un parámetro de
consulta de URL para especificar el objeto de servicio web al que acceder.
Los clientes del servicio web OpenEdge REST se conectan con una URL que utiliza el transporte REST seguido de una ruta URI que identifica
el servicio y el recurso. El formato de la URL no cambia al acceder al mismo servicio web REST implementado en el AppServer clásico, por lo
que puede configurar un PAS para la instancia OpenEdge y la aplicación web ABL para que los clientes del servicio web REST existentes
puedan usar URL idénticas a las URL. solían acceder a los mismos servicios web REST que se ejecutan en el AppServer clásico.
En general, la URL que utiliza para acceder a una aplicación web ABL debe ajustarse a la siguiente sintaxis:
Sintaxis
ejemplo
Especifica la instancia PAS para OpenEdge con la que conectarse utilizando la siguiente sintaxis:
Sintaxis
esquema
Nota: Las conexiones seguras de Internet a una instancia de PAS para OpenEdge mediante HTTPS deben tener un almacén de certificados
para certificados de clave pública en el cliente (cliente SSL) y un almacén de certificados y claves para claves privadas y certificados en la
instancia PAS para OpenEdge (servidor SSL). Para obtener información sobre la configuración de clientes OpenEdge y PAS para instancias
OpenEdge para conexiones HTTPS, consulte Gestión de certificados digitales . Otros clientes SOAP y clientes REST (como los navegadores
web) tienen sus propias herramientas para administrar los almacenes de certificados.
Especifica las credenciales de inicio de sesión de usuario necesarias para conectarse a la aplicación web ABL especificada utilizando el transporte
en la instancia PAS para OpenEdge, según el modelo de autenticación configurado para la transporte. Si el modelo de autenticación es
Anónimo, no se requieren credenciales de usuario. Si el modelo es HTTP Basic o HTTP Forms, debe proporcionar un nombre de usuario
válido ( nombre de usuario) y contraseña ( frase de contraseña) conocido por los sistemas de cuentas de usuario configurados para el transporte.
Además, los clientes SOAP y REST a menudo utilizan una API para pasar las credenciales de usuario en un encabezado de autenticación
del mensaje HTTP, en cuyo caso no es necesario especificarlas en la URL. Tenga en cuenta que las credenciales de usuario que
especifique en la URL se pasan en este encabezado de autenticación del mensaje HTTP. Sin embargo, para protegerlos, utilice siempre
HTTPS durante la vida útil de la conexión.
Nota: Los transportes APSV y SOAP solo admiten autenticación básica HTTP y anónima (no formularios HTTP).
Para los clientes OpenEdge que utilizan el transporte APSV (ABL y Open Clients), puede pasar por separado las mismas o diferentes
credenciales de usuario en un objeto cliente-principal, o si la conexión es administrada por sesión, como parámetros de conexión al PAS
para OpenEdge Procedimiento de conexión. En este caso, la aplicación ABL en el servidor generalmente administra la autenticación de
estas credenciales separadas en un nivel secundario, después la autenticación se realiza correctamente en el servidor. Para obtener más
información, consulte los temas sobre el uso de un principal de cliente y el procedimiento Connect en
anfitrión
Puerto
Especifica el puerto para la conexión de host. Por lo general, HTTP usa 8810 y HTTPS usa 8811.
[ Aplicación web/]
Especifica la aplicación web OpenEdge ABL con la que conectarse. Si nombre-aplicación-web no se especifica, una conexión a
la aplicación web OpenEdge ABL predeterminada ( RAÍZ) se utiliza.
transporte
Sintaxis
apsv
Especifica el transporte APSV utilizado por los clientes ABL y los clientes abiertos Java y .NET.
jabón
Especifica el transporte SOAP utilizado por clientes de servicios web ABL y SOAP externos.
descanso
Especifica el transporte REST utilizado por los clientes del adaptador REST, que incluye principalmente aplicaciones de navegador web y
aplicaciones que se ejecutan en dispositivos móviles, como Rollbase y aplicaciones móviles que acceden a OpenEdge Data Object Services.
®
web
Especifica el transporte WEB utilizado por los nuevos clientes REST y los clientes WebSpeed migrados mediante el controlador de
compatibilidad.
recurso-servicio
Soportado solo para los transportes OpenEdge SOAP y REST, esto especifica un servicio web OpenEdge SOAP o REST y
su recurso asociado para acceder usando la siguiente sintaxis:
Sintaxis
Especifica un URI que identifica el espacio de nombres para los servicios web SOAP definidos en el archivo WSDL ( Espacio de nombres
SOAP) y el nombre de un servicio ( SOAPsvc-nombre) para acceder, como se define en el archivo WSDL. SOAPsvc-nombre también puede
identificar el servicio por sí mismo si solo hay un servicio web definido en el archivo WSDL.
RESTsvc-nombre / ruta-recurso
Especifica una ruta de URI que identifica el nombre de un servicio web REST ( RESTsvc-nombre) y el recurso REST ( ruta
de recursos) acceder. los ruta de recursos también puede incluir parámetros de consulta para el recurso.
Para obtener más información sobre la formación de URI para acceder a los servicios SOAP, REST y WEB de OpenEdge, consulte Desarrollar
servicios ABL .
Además de especificar la URL de una aplicación web ABL, la conexión del cliente debe especificar el modelo de aplicación que se espera que
ejecute PAS para OpenEdge y su aplicación empresarial. Esto se hace para cada transporte y tipo de cliente cuando se conecta a PAS para
OpenEdge. Es lo mismo que especificar el modelo de sesión cuando te conectas al AppServer clásico:
• Transporte APSV - Para clientes ABL, configurando el - sessionModel parámetro de conexión del
CONECTAR () método; para Java y .NET Open Clients, estableciendo la propiedad de proxy de Open Client adecuada.
• Transporte SOAP —El modelo de aplicación debe especificarse para el servicio web OpenEdge SOAP cuando lo define en ProxyGen y
se incluye en el archivo WSDL que genera para el acceso del cliente. Los clientes SOAP solo deben escribirse para admitir el modelo de
aplicación para el que se define el servicio web y para el que está escrita la aplicación comercial de implementación en PAS para
OpenEdge.
• Transporte REST —El modelo de aplicación no tiene sesión para ejecutar solicitudes de servicio web OpenEdge REST. Todos los clientes REST
deben estar escritos para admitir solo acceso sin sesión.
• Transporte WEB —El modelo de aplicación está libre de sesiones para ejecutar solicitudes de clientes de OpenEdgeWebSpeed. Todos los clientes REST
deben estar escritos para admitir solo acceso sin sesión.
Para obtener más información sobre la migración de conexiones de cliente desde el acceso a los servicios clásicos de AppServer para acceder a los servicios
correspondientes de PAS para aplicaciones web OpenEdge ABL, consulte los siguientes temas:
PAS para OpenEdge no es compatible con OpenEdge NameServer ni con los modos de conexión directa del clásico AppServer. Todas las
conexiones deben usar una URL similar a la que se usó para el Adaptador de Internet AppServer (AIA) clásico.
Por ejemplo, un cliente ABL: URL parámetro de conexión al CONECTAR () El método podría ser el siguiente para una conexión AIA, que
también se muestra en una cadena de parámetros de conexión que incluye: sessionModel
parámetro de conexión:
"-URL http: // Puerto host/ aia / Aia? AppService = asbroker1 -sessionModel Session-free "
El parámetro de conexión APSV equivalente para una conexión PAS para OpenEdge podría ser el siguiente:
Si el apsv URI es apsv, u omitido, luego se conecta al predeterminado RAÍZ Aplicación web ABL. Si apsv es
asbroker1WebAppl / apsv, luego se conecta a la aplicación web ABL con el nombre, asbroker1WebAppl,
que se implementa en el archivo WAR, asbroker1WebAppl.war.
Nota: El modelo de aplicación de conexión APSV se especifica como sin sesión de la misma manera que el modelo de sesión de conexión AIA.
Para obtener más información sobre la conexión de cliente ABL (así como Open Client) a PAS para OpenEdge, consulte Conectarse a una instancia de PAS para
OpenEdge .
La forma de conectar los clientes del servicio web SOAP varía significativamente con la plataforma del cliente, pero todos proporcionan una forma de especificar
una URL para el archivo WSDL y el servicio web al que se conectan.
Por ejemplo, un cliente ABL: WSDL parámetro de conexión al CONECTAR () El método puede ser el siguiente para una conexión clásica del
Adaptador de servicios web OpenEdge (WSA):
"-WSDL http: // Puerto host/ wsa / wsa1 / wsdl? targetURI = urn: CustomerSvc "
El parámetro de conexión SOAP equivalente para una conexión PAS para OpenEdge podría ser el siguiente:
"-WSDL http: // host: puerto / jabón / wsdl? targetURI = urn: CustomerSvc "
Si el jabón URI es jabón u omitido, luego se conecta al predeterminado RAÍZ Aplicación web ABL. Si jabón es
asbroker1WebAppl / soap, luego se conecta a la aplicación web ABL con el nombre, asbroker1WebAppl,
que se implementa en el archivo WAR, asbroker1WebAppl.war.
Nota: Este ejemplo utiliza el mismo nombre de archivo WAR que en el ejemplo anterior de una migración de URL AIA clásica (consulte Migre las URL de AIA para
usar el transporte APSV en la página 53), en lugar de utilizar un nombre de archivo que refleje el nombre original de la instancia de WSA, wsa1. Esto es para
ilustrar que los tres transportes de conexión web se pueden admitir en una única aplicación web ABL en PAS para OpenEdge siempre que todos puedan acceder
en última instancia a la misma base de código ABL del servidor.
Tenga en cuenta también que, al igual que para una conexión al WSA clásico, especifica la URL exacta para una conexión a un servicio web OpenEdge SOAP
cuando implementa el servicio web. Esto genera el archivo WSDL de implementación que contiene la URL de conexión actualizada. También podría ser posible
implementar el mismo archivo WSM en PAS para OpenEdge que creó originalmente a partir de la generación de un servicio web SOAP existente para el
ClassicWSA usando ProxyGen. Para obtener más información sobre la implementación del servicio web OpenEdge SOAP en PAS para OpenEdge, consulte
Implementar servicios SOAP en Administrar Progress Application Server (PAS) para OpenEdge, y Gestionar transportes SOAP en Administre
Progress Application Server (PAS) para OpenEdge con OpenEdge Management.
Para obtener más información sobre cómo conectarse a un servicio web SOAP desde un cliente ABL, consulte los temas sobre la creación de clientes ABL para consumir
servicios web SOAP en Desarrollar un cliente ABL SOAP .
Por ejemplo, una URL para acceder a un servicio web REST de OpenEdge para el AppServer clásico usando el servidor OEWeb podría ser la
siguiente:
Después de migrar el mismo código ABL al asbroker1WebAppl.war Aplicación web ABL en una instancia PAS para OpenEdge,
usaría esta URL:
Nota: Este ejemplo utiliza el mismo nombre de archivo WAR que en el ejemplo anterior de una migración de URL AIA clásica (consulte Migre las URL de AIA
para usar el transporte APSV en la página 53), en lugar de utilizar un nombre de archivo que pueda coincidir con la aplicación web REST original para el
AppServer clásico en el servidor OEWeb ( CustomerMaint.war).
Esto es para ilustrar que los tres transportes de conexión web pueden ser compatibles con una sola aplicación web ABL en PAS para OpenEdge siempre que
todos puedan acceder a la misma base de código ABL del servidor.
También puede cambiar el nombre de la aplicación web ABL por el nombre de archivo de la aplicación web REST original para el AppServer
clásico ( CustomerMaint.war), y use una URL casi idéntica a la original (que se muestra en el ejemplo anterior), o después de migrar el código ABL
al predeterminado RAÍZ Aplicación web ABL, puede usar esta URL:
Tenga en cuenta que OpenEdge ABL no tiene un REST nativo CONECTAR () método en este momento. Sin embargo, puede probar una conexión REST a través
de un navegador.
Para obtener más información sobre cómo crear y conectarse a servicios web REST y Servicios de objetos de datos, consulte los temas sobre estos
servicios en Desarrollar servicios ABL .
El AppServer clásico puede depender opcionalmente de un NameServer que permite a los clientes localizar instancias de AppServer por su nombre de
servicio de aplicación. Por lo tanto, no tiene que configurar los clientes con direcciones de red y puertos explícitos para acceder a una instancia clásica de
AppServer en particular. Este mismo NameServer puede lograr tolerancia a fallas del servidor y balanceo de carga para una alta carga de clientes al tener
acceso a múltiples instancias clásicas de AppServer que brindan el mismo servicio de aplicación a los clientes.
Debido a que es un servidor de aplicaciones web, PAS para OpenEdge no utiliza OpenEdge NameServer. Sí permite el uso de un servicio de equilibrio
de carga de DNS y proxies del lado del servidor que permiten que un cliente se conecte a un recurso del servidor sin tener que conocer la dirección y el
puerto de red explícitos, logrando así un nivel similar de tolerancia a fallas y equilibrio de carga utilizando múltiples PAS para instancias de OpenEdge
que admiten la misma aplicación web ABL.
Todos los clientes de OpenEdge deben realizar la conversión para conectarse a una URL que identifique tanto la aplicación web ABL como el transporte de
conexión admitido por PAS para las instancias de OpenEdge registradas con el servidor DNS. Para PAS para clientes OpenEdge REST y SOAP, la URL
cambia de manera similar a los cambios requeridos cuando mueve los adaptadores clásicos de AppServer REST o WSA a un servidor web diferente.
Nota: Para obtener más información sobre las opciones de configuración del equilibrio de carga para PAS para OpenEdge, consulte PAS de equilibrio de carga para
instancias OpenEdge .
Debido a que PAS para OpenEdge ejecuta aplicaciones comerciales ABL en un entorno de servidor web, la configuración y administración de instancias
de PAS para OpenEdge es muy diferente del clásico OpenEdge AppServer. Este contenido describe algunas de las diferencias más significativas.
PAS para OpenEdge también funciona con instancias pero con una diferencia. El servidor central PAS para OpenEdge todavía se encuentra en la instalación de
OpenEdge, bajo $ DLC / servidores / pasoe directorio. Contiene las bibliotecas compartidas, las utilidades y las plantillas predeterminadas que utilizan las
instancias. A diferencia del clásico AppServer, la mayoría de las bibliotecas de PAS para OpenEdge, los archivos de configuración, las aplicaciones
predeterminadas, etc., se encuentran dentro de la propia instancia, en lugar de estar dispersos por el árbol del directorio de instalación de OpenEdge.
Una configuración PAS para OpenEdge se divide entre el directorio de instalación del servidor de aplicaciones Progress, común a todos los productos
web de Progress, y el producto OpenEdge que se implementa en él. La utilidad de línea de comandos para administrar PAS para instancias de
OpenEdge es TCMAN, que admite una amplia variedad de operaciones que van desde crear, configurar y eliminar una instancia hasta controlar la
implementación de aplicaciones web ABL (y otras aplicaciones web) contenidas dentro de una instancia. . Para obtener más información sobre TCMAN,
consulte TCMAN
en Administrar Progress Application Server (PAS) para OpenEdge. OpenEdge Management también admite algunas operaciones fuera de línea de una
instancia PAS para OpenEdge a través de TCMAN. Para más información, ver Gestionar PAS para datos OpenEdge en Administre Progress Application
Server (PAS) para OpenEdge con OpenEdge Management.
La configuración de las aplicaciones ABL se gestiona mediante las siguientes utilidades de línea de comandos, que se encuentran en la
/compartimiento directorio de la instancia:
• oeprop —Una utilidad de línea de comandos para instalaciones seguras que permite la manipulación directa del
conf / openge.properties archivo de la misma forma general que el mergeprops utilidad manipula el clásico AppServer ubroker.properties
archivo. Para más información, ver OEPROP .
• deploySOAP —Una utilidad de línea de comandos para instalaciones seguras que permite la implementación incremental de una descripción SOAP (. wsm)
archivo a la aplicación web OpenEdge ABL de una aplicación ABL, al igual que lo hace la utilidad WSAMAN para el Adaptador de servicios web clásico
(WSA). Para más información, ver Implementar servicios SOAP .
• deployREST —Una utilidad de línea de comandos para instalaciones seguras que permite la implementación incremental de una descripción de servicio
REST (. paar) archivo a la aplicación web OpenEdge ABL de una aplicación ABL, al igual que lo hace la utilidad RESTMAN para las aplicaciones RESTWeb
clásicas de OpenEdge. Para más información, ver Implementar servicios REST .
La configuración de aplicaciones ABL se puede gestionar opcionalmente a través de las API REST de la aplicación web OpenEdgeManager ( oemanager.war)
en instalaciones no seguras en un PAS para servidor de desarrollo OpenEdge.
OpenEdge Manager utiliza las API REST para realizar la administración en línea de las aplicaciones ABL y sus aplicaciones web, transportes, el administrador de
sesiones y agentes multisesión. Las API REST de OpenEdgeManager están abiertas y disponibles para que los desarrolladores de OpenEdge las utilicen en sus
propias herramientas de gestión. Para más información, ver Utilice la interfaz de usuario de Swagger para explorar las API REST de administración
Precaución: No utilice aplicaciones de gestión de aplicaciones web remotas como Tomcat manager.war
o OpenEdge oemanager.war en una instalación segura de servidor web de Internet, como PAS para servidor de producción OpenEdge.
Al igual que en el AppServer clásico, comienza con la creación de una instancia PAS para OpenEdge. En una instalación de servidor de desarrollo de PAS
para OpenEdge, se le proporciona una instancia de muestra en el archivo OpenEdge $ WRKDIR ubicación. Esta instancia de muestra se define en el openge.properties
archivo de configuración con el nombre de la aplicación ABL oepas1. Dentro oepas1, es la aplicación web ABL predeterminada implementada como / webapps
/ ROOT. Puede implementar de forma incremental servicios web SOAP y REST, y conectar clientes OpenEdge a esta aplicación web ABL predeterminada.
También puede crear su propia aplicación web ABL y agregarla a la oepas1 Aplicación ABL.
El siguiente conjunto de tareas compara la creación de instancias para el clásico OpenEdge AppServer y PAS para OpenEdge.
El conjunto general de pasos para crear una instancia en el AppServer de producción clásico es:
3. Configure la instancia clásica de AppServer (que define implícitamente una aplicación ABL).
segundo. Opcionalmente, instale y configure la aplicación web aWSA, e implemente y configure cero o más SOAP
descriptores de servicios web (. wsm archivos).
C. Opcionalmente, instale y configure una aplicación web REST (exportada desde PDSOE) e incrementalmente
implementar cero o más definiciones de servicios web REST (. paar archivos).
Cuando se instala el producto de servidor de producción PAS para OpenEdge, no se instala ninguna instancia de muestra predeterminada por razones de seguridad.
Por lo tanto, sigue esta secuencia de pasos:
1. Cree la instancia PAS para OpenEdge y asígnele un nombre (que define implícitamente una aplicación ABL
con el nombre de la instancia ubicado en el nombre de instancia/ ablapps directorio).
3. Implementar. r archivos. (. pag los archivos no se pueden compilar en un servidor de producción PAS para OpenEdge).
5. Configurar la aplicación ABL y sus componentes, incluido el administrador de sesiones ABL y multisesión
agentes.
segundo. Configure el transporte SOAP (habilite o deshabilite) e implemente y configure de forma incremental cero o más
Descriptores del servicio SOAPWeb (. wsm archivos).
C. Configure el transporte REST (habilite o deshabilite) e implemente y configure gradualmente cero o más
Definiciones de servicios web REST (. paar archivos).
re. Configure el transporte WEB (activar o desactivar) y cualquier controlador web asociado.
PAS para OpenEdge funciona de la misma forma general, pero es diferente con respecto a lo siguiente:
• Cada instancia de PAS para OpenEdge incorpora su openge.properties archivo dentro del
nombre de instancia/ conf directorio.
• Una instancia de PAS para OpenEdge admite aplicaciones ABL con nombre que corresponden a la arquitectura del directorio de instalación.
• Las propiedades de una aplicación ABL en PAS para OpenEdge configuran sus aplicaciones web, transportes, un administrador de sesiones
ABL y agentes multisesión ABL.
La siguiente es una breve comparación de las propiedades clásicas de AppServer con PAS para las propiedades de OpenEdge:
• Muchas de las propiedades utilizadas por un AppServer clásico se pueden encontrar en PAS para OpenEdge.
• Algunas propiedades clásicas de AppServer no tienen significado y no se encuentran en PAS para OpenEdge.
• Algunas propiedades clásicas de AppServer se relacionan con la funcionalidad que proporciona el directorio de instalación de PAS para OpenEdge y se administran
mediante propiedades centrales a nivel de servidor.
• PAS para OpenEdge tiene nuevas propiedades que no se aplican al AppServer clásico.
La siguiente es una descripción general de cómo las propiedades encontradas en el ubroker.properties archivo para un mapa clásico de AppServer a las
propiedades que se encuentran en un PAS para instancias de OpenEdge openge.properties archivo. La información detallada sobre propiedades individuales se
puede encontrar en los respectivos archivos README
( ubroker.properties.README y openge.properties.README).
• Todos los nombres de propiedad clásicos de AppServer no proporcionan un grupo (un [...] nombre ya que las propiedades pueden existir en
• Todos los nombres de propiedad de PAS para OpenEdge utilizan una declaración de espacio de nombres que rastrea la jerarquía de grupos que se encuentra en el openge.properties
archivo. Por ejemplo:
• AppServer.Agent [AppServer.Agent]
• AppServer.Agent [AppServer.Agent]
• AppServer.Agent.oepas1 [AppServer.Agent.oepas1]
• [AppServer.Agent] - Propiedades que se aplican a todos los agentes multisesión en la instancia del servidor (hereda de la nada)
• [AppServer.Agent. nombre de la aplicación] —Propiedades del agente multisesión que se aplican solo a la aplicación ABL
llamado nombre de la aplicación ( hereda de [ AppServer.Agent])
• [AppServer.SessMgr] - Propiedades que se aplican a todos los administradores de sesiones de aplicaciones ABL en la instancia del servidor (se
hereda de la nada)
• [AppServer.SessMgr. nombre de la aplicación] - Propiedades del administrador de sesiones de la aplicación ABL que se aplican solo a la aplicación ABL
denominada nombre de la aplicación ( hereda de [ AppServer.SessMgr])
• [ nombre de la aplicación] —Propiedades que se aplican solo a las aplicaciones web de la aplicación ABL (se hereda de la nada)
• [ appname.web-app-name. APSV] : Propiedades que se aplican solo a la aplicación web de la aplicación ABL denominada nombre-aplicación-web
ya su transporte APSV (hereda de [ appname.web-app-name])
• [ appname.web-app-name. JABÓN] : Propiedades que se aplican solo a la aplicación web de la aplicación ABL denominada nombre-aplicación-web
y a su transporte SOAP
• [ appname.web-app-name. DESCANSO] : Propiedades que se aplican solo a la aplicación web de la aplicación ABL denominada nombre-aplicación-web
y a su transporte REST
• [ appname.web-app-name. WEB] : Propiedades que se aplican solo a la aplicación web de la aplicación ABL denominada nombre-aplicación-web
y a su transporte WEB
La siguiente tabla enumera las propiedades clásicas de AppServer y cómo se corresponden con las propiedades de una instancia de PAS para OpenEdge:
4glSrcCompile N/A
allowRuntimeUpdates AppServer.allowRuntimeUpdates
appServerKeepaliveCapabilities N/A
appserviceNameList N/A
autoencendido N/A
autoTrimTimeout N/A
brkrDebuggerEnabled N/A
brkrDebuggerKeyAlias N/A
brkrDebuggerKeyAliasPassword N/A
brkrDebuggerPassphrase N/A
brkrDebuggerPortNumber N/A
brkrDebuggerSSLEnable N/A
brkrDebuggerUseBrokerAlias N/A
brkrLogAppend N/A
brkrLogEntries N/A
brkrLogEntryTypes N/A
brkrLogThreshold N/A
brkrLoggingLevel N/A
brkrNumLogFiles N/A
brokerLogFile N/A
certStorePath N/A
classMain N/A
collectStatsData AppServer.Agent.collectStatsData
compresiónEnable N/A
ControllerNameServer N/A
debuggerEnabled N/A
defaultService N/A
descripción N/A
ambiente N/A
flushStatsData AppServer.Agent.flushStatsData
hostName N/A
infoVersion AppServer.Agent.infoVersion
initialSrvrInstance AppServer.SessMgr.numInitialAgents
ipver AppServer.SessMgr.ipver
keyAlias AppServer.Agent.keyAlias
keyAliasPasswd AppServer.Agent.keyAliasPasswd
keyStorePasswd AppServer.Agent.keyStorePasswd
keyStorePath AppServer.Agent.keyStorePath
maxSrvrInstance AppServer.SessMgr.maxAgents
minSrvrInstance N/A
noSessionCache AppServer.Agent.noSessionCache
contraseña N/A
PrioridadPeso N/A
PROPATH AppServer.Agent.PROPATH
registerNameServer N/A
registrationMode N/A
registroReintentar N/A
serverASKActivityTimeout N/A
serverASKResponseTimeout N/A
serverLifespan N/A
serverLifespanPadding N/A
srvrActivateProc AppServer.Agent.sessionActivateProc
srvrConnectProc AppServer.Agent.sessionConnectProc
srvrDeactivateProc AppServer.Agent.sessionDeactivateProc
srvrDisconnProc AppServer.Agent.sessionDisconnProc
srvrExecFile AppServer.SessMgr.agentExecFile
srvrExecutionTimeLimit N/A
srvrLogAppend N/A
srvrLogEntryTypes AppServer.SessMgr.agentLogEntryTypes
srvrLogFile AppServer.Agent.agentLogFile
srvrLogThreshold AppServer.SessMgr.agentLogThreshold
srvrLogWatchdogInterval N/A
srvrLoggingLevel AppServer.SessMgr.agentLoggingLevel
srvrMaxPort AppServer.Agent.agentMaxPort
srvrMinPort AppServer.Agent.agentMinPort
srvrNumLogFiles AppServer.SessMgr.agentNumLogFiles
srvrSelectionScheme N/A
srvrShutdownProc AppServer.Agent.sessionShutdownProc
srvrStartupParam AppServer.Agent.sessionStartupParam
srvrStartupProc AppServer.Agent.sessionStartupProc
srvrStartupProcParam AppServer.Agent.sessionStartupProcParam
srvrStartupTimeout N/A
sslAlgorithms AppServer.Agent.sslAlgorithms
sslEnable AppServer.Agent.sslEnable
uuid AppServer.Agent.uuid
workDir N/A
N/A AppServer.statusEnabled
N/A AppServer.collectMetrics
N/A AppServer.applications
N/A AppServer.Agent.agentShutdownProc
N/A AppServer.Agent.agentStartupProc
N/A AppServer.Agent.agentStartupProcParam
N/A AppServer.SessMgr.publishDir
Los siguientes temas describen con mayor detalle cómo PAS para el empaquetado e instalación de OpenEdge difiere del clásico
AppServer.
Embalaje de distribución
El AppServer clásico no tiene una estructura de directorio definida o una ubicación donde se deben implementar los archivos de la aplicación ABL, o
donde se deben ubicar sus archivos de trabajo y temporales. Con esta falta de estructura, depende del desarrollador de la aplicación ABL determinar
cómo administrar escalabilidad y extensibilidad.
Debido a que se basa en la plataforma del servidor ApacheTomcat, PAS para OpenEdge sigue las convenciones comunes al entorno Tomcat para
implementar aplicaciones ABL como aplicaciones web. Aunque una aplicación ABL no puede considerarse una aplicación completamente escalable o
extensible cuando se compara con una aplicación web estándar de Tomcat, se puede diseñar, empaquetar y distribuir para que sea escalable y extensible
con una cantidad mínima de trabajo. PAS para OpenEdge, mediante el uso de la funcionalidad de servidor de instalación PAS para OpenEdge, ofrece
opciones de implementación y empaquetado de implementación adicionales para los desarrolladores de aplicaciones ABL que no existen para los
desarrolladores de aplicaciones web y Tomcat estándar.
El AppServer clásico admite servicios REST y SOAP a través de adaptadores externos. Este mismo soporte existe para PAS para OpenEdge, sin
embargo, los servicios se implementan en diferentes ubicaciones y existen diferentes utilidades para administrar la implementación. PAS para OpenEdge
incorpora la funcionalidad de los adaptadores externos del AppServer clásico en una única aplicación web desplegable, que puede ser la misma
aplicación web en la que se implementa la aplicación ABL. Las herramientas para implementar servicios REST o SOAP continúan incluyendo OpenEdge
Management y OpenEdge Explorer, pero nuevas herramientas de línea de comandos ( deploySOAP y deployREST) se utilizan para corresponder con los
cambios arquitectónicos en PAS para OpenEdge.
• Implementación de descriptores de servicios SOAP individuales (. wsm archivos) en una aplicación web OpenEdge ABL existente.
• Implementación de definiciones de servicios REST individuales (. paar archivos) en una aplicación web OpenEdge ABL existente.
• Implementar una aplicación web OpenEdge ABL completa, incluidos los servicios web SOAP y REST previamente implementados, en una instancia PAS para
OpenEdge existente.
• Implementar una instancia completa de PAS para OpenEdge, incluidas las aplicaciones web OpenEdge ABL previamente implementadas, en una instalación
OpenEdge existente.
Nota: A diferencia del clásico AppServer, las instancias PAS para OpenEdge no se eliminan cuando se desinstala OpenEdge. Por lo tanto, las instancias y su
implementación y configuración completas pueden simplemente agregarse a una nueva instalación de OpenEdge. Para obtener más información, consulte el Registro
TCMAN comando en el PAS para la referencia de herramientas de administración de OpenEdge.
Un servicio web SOAP se implementa mediante un archivo descriptor SOAP (. wsm) que llama a las API de la interfaz de servicio ABL en la aplicación ABL. Para
implementar servicios SOAP incrementales en una aplicación web ABL de instancia de PAS para OpenEdge existente, empaquete el. wsm archivo y cualquier ABL. pag
o. r archivos de idioma que admiten la API de la interfaz de servicio. Una vez que el paquete esté disponible en el servidor host de la instancia de PAS para
OpenEdge, podrá:
2. Utilice PAS para instancias de OpenEdge deploySOAP utilidad de línea de comandos para implementar el descriptor SOAP
archivo en una aplicación web OpenEdge ABL existente. Para más información, ver Implementar servicios SOAP .
3. Mueva cualquier ABL. pag o. r archivos en una de las aplicaciones ABL PROPATH ubicaciones.
Nota: los PROPATH La ubicación puede incluir la aplicación web OpenEdge ABL WEB-INF / openge árbol de directorio.
Un servicio web REST se implementa mediante un archivo de definición de servicio REST (. paar) que llama a las API de interfaz de servicio ABL en la aplicación ABL.
Para implementar definiciones de servicio REST incrementales en una aplicación web ABL existente de PAS para la instancia OpenEdge, empaquete el archivo. paar archivo
y cualquier ABL. pag o. r archivos de idioma que admiten la API de la interfaz de servicio. Una vez que el paquete esté disponible en el servidor host de la instancia de
PAS para OpenEdge, podrá:
2. Utilice PAS para instancias de OpenEdge deployREST utilidad de línea de comandos para implementar el servicio REST
archivo de definición en una aplicación web ABL existente. Para más información, ver Implementar servicios REST .
3. Mueva cualquier ABL. pag o. r archivos en una de las aplicaciones ABL PROPATH ubicaciones.
Nota: los PROPATH La ubicación puede incluir la aplicación web OpenEdge ABL WEB-INF / openge árbol de directorio.
Puede implementar una aplicación ABL como una o más aplicaciones web OpenEdge ABL. Una aplicación web OpenEdge ABL está empaquetada como un
archivo de aplicaciones web (. guerra) archivo que sigue el diseño descrito anteriormente (ver Estructura de la aplicación ABL en la página 36). Para mejorar
el rendimiento y el consumo de recursos, implemente una aplicación ABL utilizando una única aplicación web OpenEdge ABL, haciendo que la aplicación
completa sea accesible desde una única URL de servidor. Hay situaciones en las que implementar una aplicación ABL como múltiples aplicaciones web
OpenEdge ABL (donde la aplicación es accesible a través de múltiples URL de servidor) es la ruta correcta a seguir. Dado que el uso de varias aplicaciones
web OpenEdge ABL ralentiza el rendimiento y consume más recursos de proceso del sistema operativo, utilice este enfoque solo cuando:
• Su aplicación web OpenEdge ABL está diseñada como un conjunto de servicios discretos, implementados individualmente, donde la aplicación web
OpenEdge ABL encapsula el "conjunto de servicios" dentro de su aplicación ABL.
• Debe evitar interrumpir a los clientes clásicos de AppServer hasta que puedan actualizarse para usar una única URL.
Al implementar aplicaciones web OpenEdge ABL, puede pre-implementar y configurar SOAP, REST y Spring Security. También tiene la
opción de implementar las API de interfaz de servicio SOAP, REST, WEB y APSV. pag
y. r archivos como parte de cada aplicación web WEB-INF / openge directorios. Usando la incrustación opcional de. r y. pag módulos en la
aplicación web, se asegura de que la versión de las interfaces de servicio SOAP, REST, WEB y APSV permanezca coherente con sus
definiciones de transporte (URI). Es posible que deba cambiar la aplicación ABL PROPATH para incluir la aplicación web OpenEdge ABL WEB-INF
/ openge camino.
PAS para OpenEdge se puede empaquetar e implementar como una instancia completa preconfigurada. La instancia se puede desempaquetar en un
sistema de archivos del SO y reconfigurar para la instalación local de OpenEdge y para los requisitos del sitio. Dicho brevemente, hace lo siguiente:
1. Cree una instancia de PAS para OpenEdge que represente el paquete de implementación.
2. Implementar y configurar las aplicaciones web OpenEdge ABL que conformarán la aplicación ABL.
3. Implemente y configure cualquier servicio web SOAP y REST en las aplicaciones web OpenEdge ABL.
4. Implemente la aplicación ABL. pag y / o. r archivos como parte del nombre de instancia/ abierto directorio, o
una aplicación web OpenEdge ABL abierto directorio (por ejemplo,
nombre de instancia/ webapps / ROOT / WEB-INF / openge).
5. Instale cualquier aplicación que adapte scripts en el nombre de instancia/ compartimiento directorio.
Nota: En UNIX, los archivos de script deben configurarse como ejecutables porque los archivos de almacenamiento no conservan los permisos de archivo.
6. Proporcione cualquier archivo de entorno de proceso del sistema operativo que contenga las variables de entorno necesarias para su aplicación.
7. Configure el PAS para las características y propiedades predeterminadas del servidor OpenEdge. Ver Característica TCMAN y TCMAN
config para más información.
Para hacer el empaque, use Java tarro utilidad o la utilidad WinZip (o equivalente) para crear un único archivo de almacenamiento que comienza con la raíz de la
instancia ( CATALINA_BASE) directorio.
Nota: Si es necesario, puede implementar la aplicación ABL. pag y. r archivos en cualquier lugar del sistema de archivos del SO, como en un AppServer clásico.
Sin embargo, pierde la mayoría, si no todos, los beneficios de la infraestructura PAS para OpenEdge para la implementación, las actualizaciones y la seguridad.
La instalación de una aplicación ABL en PAS para OpenEdge depende del paquete descrito en los temas anteriores. Estos temas se centran en
la instalación de PAS para OpenEdge.
Nota: Todas las instalaciones dependen de haber instalado ya sea Progress Dev AS para OpenEdge ( servidor de desarrollo) o Progress Production
AS para OpenEdge ( servidor de producción) productos.
Este tipo de instalación implementa un PAS empaquetado para la instancia de OpenEdge creada de acuerdo con el procedimiento descrito en PAS para el empaquetado
de instancias de OpenEdge en la página 67.
1. Carga el . tarro o. Código Postal archivo que contiene el PAS empaquetado para la instancia de OpenEdge.
3. Utilizar el expandir utilidad encontrada en $ DLC / servers / pasoe / bin / expand. {Sh | bat} para desembalar el
ejemplo.
4. Utilice el $ DLC / servers / bin / tcman. {Sh | bat} registro comando para vincular la nueva instancia con
la instalación de OpenEdge.
5. Si se trata de un sistema de Windows y la instancia se ejecutará como un servicio de Windows, utilice el servicio tcman.bat
crear comando para crear un nuevo servicio de Windows.
6. Si se trata de un sistema UNIX, configure el nivel de seguridad correcto ({ producción | estándar | desarrollo
}) usando el $ DLC / servers / pasoe / bin / openge_tailor comando, especificando solamente los
modo de seguridad opción.
7. Utilizar el tcman. {sh | bat} config comando para asignar una nueva red ( http / https / ajp13) puertos
8. Utilizar el característica tcman. {sh | bat} comando para habilitar o deshabilitar las funciones del servidor de acuerdo con
9. Utilizar el oeprop utilidad para configurar las propiedades de la aplicación ABL de acuerdo con los requisitos del sitio.
10. Utilice un editor de texto y configure la seguridad de cada aplicación web ABL de acuerdo con los requisitos del sitio. por
más información, ver PAS seguro para instancias de OpenEdge en Administrar Progress Application Server (PAS) para OpenEdge.
2. Ejecute la instancia tcman. {sh | bat} implementar comando para cargar la aplicación web en el
nombre de instancia/ aplicaciones web directorio. Para más información, ver Implementar una aplicación web ABL .
3. Ejecutar el oeprop utilidad para configurar la aplicación web en la aplicación ABL openge.properties
archivo.
4. Ejecutar el oeprop utilidad para configurar los transportes APSV, SOAP, REST y WEB de la aplicación web de acuerdo con
a los requisitos del sitio.
5. Utilice un editor de texto y configure la seguridad de la aplicación web ABL de acuerdo con los requisitos del sitio. por
más información, consulte el PAS seguro para instancias de OpenEdge temas en Administrar Progress Application Server (PAS) para
OpenEdge.
6. Implemente cualquiera. pag o. r código necesario para admitir la nueva aplicación web ABL.
a. Si el ABL. pag o. r El código está empaquetado dentro de la aplicación web ABL, use el oeprop utilidad para agregar su
ruta a la aplicación ABL PROPATH.
segundo. Si el ABL. pag o. r el código está empaquetado dentro de la aplicación web ABL pero debe moverse a otro lugar,
moverlo y actualizar la aplicación ABL PROPATH con su nueva ubicación.
C. Si el ABL. pag o. r el código está empaquetado externamente, expanda esa distribución a su nueva ubicación y actualice
la aplicación web OpenEdge ABL de la aplicación ABL.
Nota: Si es necesario, puede implementar la aplicación ABL. pag y / o. r archivos en cualquier lugar del sistema de archivos del SO, como en un AppServer
clásico. Sin embargo, pierde la mayoría, si no todos, los beneficios de la infraestructura PAS para OpenEdge para la implementación, las actualizaciones y la
seguridad.
Cuando necesite actualizar PAS para OpenEdge, hay diferentes procesos a seguir:
• Cuando actualiza a una versión posterior de OpenEdge, todas las instancias de PAS para OpenEdge recogen automáticamente las nuevas bibliotecas y utilidades
compartidas que se encuentran en el directorio de instalación de PAS para OpenEdge en
$ DLC / servidores / pasoe.
• Es raro que una aplicación web ABL requiera una actualización porque no contiene código parcheable. Si existen parches para los archivos de
configuración de seguridad u otros archivos estáticos, entonces Progress recomienda que desarrolle un script automatizado que pueda realizar las
sustituciones y adiciones de archivos adecuadas.
• Para actualizar un servicio web REST o SOAP, use el mismo proceso que usó con el WSA clásico para servicios SOAP y el Administrador REST
clásico para servicios REST: anule la implementación del servicio anterior, implemente el nuevo servicio y configure el nuevo servicio.
1. Elija qué aplicación web de administración remota implementar: Tomcat's gerente o de OpenEdge
oemanager.
2. Implemente la aplicación web de administración remota desde $ DLC / servidores / pasoe / extras utilizando el TCMAN
utilidad desplegar mando. Para más información, ver Implementar una aplicación web ABL .
3. Configure la seguridad de la administración remota de acuerdo con las políticas del sitio, utilizando un editor de texto para alterar la
web.xml y archivos de configuración de Spring Security. Para más información, ver PAS seguro para instancias de OpenEdge en Administrar
Progress Application Server (PAS) para OpenEdge.
En general, las herramientas y procesos que tiene para un AppServer clásico no se aplican a PAS para OpenEdge. Toda la arquitectura es diferente,
por lo que requiere herramientas y métodos nuevos y diferentes. Algunas de las características asociadas con los productos clásicos de AppServer y
Adapter que no son aplicables a PAS para OpenEdge incluyen:
• ASBMAN
• NSMAN
• WSAMAN
• RESTMAN
• ubroker.properties
• WSA
• AdminServer
Los siguientes temas describen otros aspectos del trabajo con el AppServer clásico que no se aplican a PAS para OpenEdge.
Una aplicación ABL contiene los mismos componentes básicos tanto en el AppServer clásico como en PAS para OpenEdge, pero debe empaquetarse y
distribuirse de la manera que mejor se adapte a la arquitectura de PAS para OpenEdge. Por lo tanto, los scripts existentes, las herramientas de compilación,
etc., que empaquetan una aplicación ABL de AppServer clásica no funcionan con PAS para OpenEdge. Puede continuar empaquetando y distribuyendo su
aplicación ABL como si fuera para un AppServer clásico, pero perderá algunos de PAS para el valor de OpenEdge.
Nota: Si es necesario, puede implementar la aplicación ABL. pag y. r archivos en cualquier lugar del sistema de archivos del SO, como en un AppServer clásico.
Sin embargo, pierde la mayoría, si no todos, los beneficios de la infraestructura PAS para OpenEdge para la implementación, las actualizaciones y la seguridad.
La mayoría de las aplicaciones ABL tienen algún tipo de script automatizado o programa de instalación que las hace más fáciles de instalar. Dependiendo del
proceso de empaquetado e implementación elegido para PAS para las aplicaciones OpenEdge ABL, puede ser necesario cambiar o reescribir estas
herramientas. Hay una cantidad significativa de cambios en la ubicación de los archivos y donde se administran las propiedades de configuración. Casi todo
PAS para OpenEdge se implementa con scripts extensibles para que gran parte del proceso se pueda automatizar.
PAS para OpenEdge es no el clásico AppServer. Su arquitectura es diferente, sus subsistemas de servidor Tomcat son diferentes y su ejecución
de las sesiones ABL es diferente. Por lo tanto, todo el soporte de administración y monitoreo del clásico AppServer no es compatible con PAS para
OpenEdge. Como resultado, cualquier herramienta de automatización de terceros escrita para monitorear un AppServer clásico ya no será útil y
deberá reescribirse.
PAS para OpenEdge admite un conjunto muy ampliado de recopilación de datos métricos que proporciona una imagen amplia del estado del servidor y
la aplicación. PAS para OpenEdge admite una serie de consultas de estado administrativo y operaciones destinadas a descubrir qué está sucediendo
en ese momento, con la opción de corregir ciertas condiciones (bloqueos, fugas, etc.) sin tener que reiniciar todo el servidor.
• JMX —El soporte JMX estándar de Java para PAS para OpenEdge complementa el de la administración JMX de PAS (Apache Tomcat). JXM brinda
al administrador soporte completo de PAS para la administración de OpenEdge sin exponer al servidor a una peligrosa administración remota a
través de aplicaciones web. PAS para OpenEdge admite las siguientes herramientas JMX:
• Se puede acceder a JConsole, una herramienta GUI para explorar y administrar beans de Java, en la misma máquina usando el ID de proceso (PID)
o abriendo puertos para acceso remoto. Sin embargo, abrir puertos remotos puede considerarse un riesgo de seguridad y solo se recomienda para el
desarrollo. Para más información, ver Ejecute JConsole de forma remota y JConsole y JMX .
• El PAS para OpenEdge OEJMX Los scripts brindan al administrador PAS completo para la administración de OpenEdge y el soporte de
monitoreo sin exponer al servidor a una peligrosa administración remota a través de aplicaciones web. Para más información, ver Use OEJMX
para administrar y monitorear una instancia .
• DESCANSO - PAS para OpenEdge proporciona una Opcional API de administración REST a través de una aplicación web para OpenEdge Management /
OpenEdge Explorer y herramientas de administración de terceros. Esta aplicación web se puede proteger, pero no es una parte estándar del producto de servidor
de producción PAS para OpenEdge. Para más información, ver Utilice la interfaz de usuario de Swagger para explorar las API de administración .
• Gerente —PAS para OpenEdge proporciona una Opcional Aplicación web Apache Tomcat Manager para la administración remota del servidor Tomcat y
PAS para aplicaciones OpenEdge. Consulte la documentación de Apache Tomcat Manager para obtener información detallada. La utilidad TCMAN
proporciona acceso de cliente de texto completo a la información del servidor. Esta aplicación web se puede proteger, pero no es una parte estándar del
producto de servidor de producción PAS para OpenEdge.
• HealthScanner - PAS para OpenEdge proporciona una Opcional Aplicación web OpenEdge HealthScanner que monitorea su entorno. Habilitar
la recopilación de datos para OpenEdge HealthScanner permite que PAS para OpenEdge recopile datos del sistema para calcular una
puntuación de estado. HealthScanner permite verificar el estado de su servidor mediante una solicitud HTTP. Además, las solicitudes HTTP
independientes pueden recopilar información resumida y detallada sobre los datos recopilados. los OEHealth El script se puede utilizar para
recopilar el resumen y la información detallada sin tener que habilitar la aplicación web, lo que puede considerarse un riesgo de seguridad. Para
más información, ver Utilice OpenEdge HealthScanner .
• Puerto de apagado - Un puerto de apagado es un número de puerto no utilizado que se utiliza para apagar Tomcat. Si está creando una instancia de PAS para
OpenEdge en una máquina con Windows, este es un campo obligatorio. Las plataformas UNIX pueden desactivar un puerto de apagado y usar señales para detener
un servidor en ejecución. Las plataformas Windows, que carecen de un mecanismo de señalización efectivo, requieren un número de puerto válido.
Por definición de la industria, el AppServer clásico no cumple con los requisitos de seguridad y las mejores prácticas. Por ejemplo, nunca implementaría un
AppServer clásico como servidor de Internet. Cualquier seguridad que tenga una aplicación OpenEdge proviene de los esfuerzos diligentes de los desarrolladores
de OpenEdge que han escrito las herramientas y los procesos de instalación a su alrededor.
Los dos productos PAS para OpenEdge son casi idénticos, con las diferencias en la seguridad de la configuración. El objetivo de PAS para
OpenEdge en el producto de servidor de producción es cumplir con el 95% de las mejores prácticas de seguridad recomendadas para un servidor
Apache Tomcat. El 5% restante es algo que el administrador de producción debe hacer de acuerdo con las políticas de la empresa o el
desarrollador lo hace en función de las restricciones impuestas por su aplicación.
• Eliminación del compilador ABL, evitando cualquier acceso no autorizado al código fuente Eliminación de todas las aplicaciones
• Configuración del servidor central con eliminación de funciones de depuración no seguras, como configuración de permisos de archivo y directorio UNIX de
• implementación automática
• Capacidades administrativas completas a través de utilidades locales seguras, como herramientas de línea de comandos y acceso JMX Para obtener más información,
En su mayor parte, el AIA y el WSA clásicos no tienen seguridad incorporada y requieren la configuración manual del archivo descriptor de la
aplicación web ( web.xml) para utilizar las funciones de seguridad del contenedor de servlets. En PAS para OpenEdge, la seguridad de los
servicios APSV (anteriormente AIA) y SOAP fue asumida por el marco de Spring Security. Toda la seguridad que se ha implementado previamente
para AIA y WSA se puede migrar a la seguridad del contenedor de Spring Security.
Las aplicaciones web clásicas REST y Data Object ya incluyen Spring Security como su marco de seguridad principal. Esto continúa en PAS para las
aplicaciones web ABL de OpenEdge. Los archivos de plantilla para Spring Security han cambiado, lo que requiere que transfiera manualmente la
configuración clásica de la aplicación web REST y Data Object a los archivos de configuración de las aplicaciones web ABL.
Para obtener más información sobre el soporte de la aplicación web ABL para Spring Security, consulte los temas sobre seguridad en Administrar Progress Application
Server (PAS) para OpenEdge como Habilitar la autenticación de la aplicación ABL .
PAS para OpenEdge está disponible como host para aplicaciones WebSpeed. Puede migrar aplicaciones WebSpeed existentes a PAS para
OpenEdge, o puede utilizar Progress Developer Studio para OpenEdge para desarrollar nuevas aplicaciones WebSpeed que se ejecutan en PAS
para OpenEdge.
Este tema describe la migración de aplicaciones WebSpeed existentes (clásicas). Para obtener información sobre el desarrollo de nuevas aplicaciones web para
PAS para OpenEdge utilizando el transporte WEB, consulte Servidores de aplicaciones, aplicaciones web y servicios en Desarrollar servicios ABL.
Para migrar una aplicación WebSpeed a una instancia PAS para OpenEdge, debe hacer lo siguiente:
2. Actualice PROPATH de la instancia para incluir las carpetas que contienen el código r de la aplicación.
Archivos estáticos
Una instancia de PAS para OpenEdge requiere que los archivos estáticos que admiten una aplicación WebSpeed estén en una ubicación particular en la estructura de
directorios de la instancia. Los archivos estáticos incluyen imágenes y archivos HTML.
Si implementa otra aplicación, la ubicación predeterminada para sus archivos estáticos es:
código r
Para permitir que una instancia de PAS para OpenEdge encuentre el código r de una aplicación WebSpeed, agregue cualquier carpeta que contenga archivos de código r de la
[AppServer.Agent]
PROPATH = $ {CATALINA_BASE} / openge, $ {DLC} / tty, $ {DLC} /tty/netlib/OpenEdge.Net.pl
Asegúrese de que nombre de instancia/ conf / openge.properties tiene habilitado el transporte WEB y el
defaultHandler se establece en OpenEdge.Web.CompatibilityHandler. Por ejemplo:
[abl_app_name.ROOT.WEB]
adapterEnabled = 1
defaultCookieDomain =
defaultCookiePath =
defaultHandler = OpenEdge.Web.CompatibilityHandler
Antes de migrar una aplicación WebSpeed existente a una instancia de PAS para OpenEdge, tenga en cuenta lo siguiente:
• Se debe crear una instancia de PAS para OpenEdge a partir de una versión OpenEdge 11.6 o posterior porque es entonces cuando OpenEdge.Web.CompatibilityH
Fue presentado. Para obtener información sobre cómo crear, iniciar y detener instancias, consulte Crear y configurar PAS para instancias de
OpenEdge .
• El código R debe estar ubicado en la misma máquina donde se ejecuta la instancia de PAS para OpenEdge. El código R en unidades mapeadas en
red puede causar problemas con el rendimiento y los permisos.
• Vuelva a compilar el código r solo si se generó en OpenEdge 10. X o versiones anteriores. No se admiten las
• Aplicaciones WebSpeed con un web-disp.p y los archivos de apoyo no ejecutar sin realizar cambios en el WebHandler
predeterminado.
• Los mensajeros WSASP, WSISA, NSAPI y CGIIP no son necesarios. No son compatibles y no se pueden configurar en una instancia
PAS para OpenEdge. Como no hay Messenger, la URL de conexión de la aplicación cambia.
En WebSpeed clásico, la ruta URL incluía Messenger en el directorio de scripts del servidor web y luego la ruta al código. Por
ejemplo:
En PAS para OpenEdge, la URL predeterminada hace referencia al transporte WebSpeed ( wspd) y no el Mensajero. Por ejemplo: