Migrate-Classic-Appserver en Es

Migrar el servidor de aplicaciones clásico
Aplicaciones a PAS para OpenEdge

Contenido
Tabla de contenido
Derechos de autor................................................. .................................................. .......................... 5
Prefacio................................................. .................................................. .............................. 7
Más información sobre la migración de aplicaciones clásicas de AppServer a PAS para OpenEdge
........................................ .................................................. ......... 9

Diferencias entre AppServer clásico, WebSpeed Transaction Server y PAS para OpenEdge ... 10
Inicio rápido: mover aplicaciones clásicas de AppServer a PAS para OpenEdge
....................................... .................................................. ........ 13

Bienvenido a PAS para OpenEdge ............................................. .................................................. .............dieciséis
Prepárese para pasar de Classic AppServer a PAS para OpenEdge ........................................ .................dieciséis
Mover el código clásico de AppServer a PAS para OpenEdge .......................................... ................................. 23
Conecte a los clientes con el nuevo PAS para transportes OpenEdge .......................................... ............................ 28
Detalles importantes sobre su nuevo servidor ............................................ .................................................. 32
Próximos pasos con PAS para OpenEdge ............................................ .................................................. ........ 34
Migración de código de aplicación ABL .............................................. .................. 35

Estructura de la aplicación ABL ............................................... .................................................. ..................... 36
Migrar modos operativos clásicos de AppServer ............................................. ........................................... 37

Migrar el modo operativo clásico de restablecimiento de estado ........................................... .................................... 41
Migrar el modo operativo clásico con reconocimiento de estado ........................................... .................................. 41
Migrar el modo de funcionamiento sin estado clásico ............................................. ..................................... 42
Migrar el modo de funcionamiento sin estado clásico ........................................... ...................................... 42
Diferencias en los procedimientos de eventos entre el clásico AppServer y PAS para OpenEdge ............... 42
Procedimientos de inicio y apagado del agente multisesión .......................................... .................. 42

Procedimientos de inicio y cierre de sesión ............................................. ................................. 43
Procedimientos de conexión y desconexión .............................................. ........................................... 44
Activar y desactivar procedimientos .............................................. ............................................ 45

Conexiones de base de datos en PAS para OpenEdge ............................................ ........................................... 47
Cambios de ABL en PAS para OpenEdge ............................................ .................................................. ....... 48
Configuración del entorno en PAS para OpenEdge ............................................ ............................................. 49
Directorios y rutas del sistema de archivos en PAS para OpenEdge ......................................... ........................... 49
Migrar conexiones de cliente a PAS para OpenEdge ........................................... ...................................... 50

Migre las URL de AIA para utilizar el transporte APSV .......................................... ................................. 53
Migre las URL de WSA para utilizar el transporte SOAP .......................................... ............................... 54
Migrar URL REST ............................................... .................................................. ................. 55

Utilice el equilibrio de carga en PAS para OpenEdge ........................................... ...................................... 55
OpenEdgeWeb Paper: Versión 3

Contenido
Migrar la configuración y administración del servidor ................................. 57

Administrar instancias de servidor ............................................... .................................................. .................... 58
Migrar propiedades clásicas de AppServer .............................................. .................................................. ... 60
Embalaje e instalación de la aplicación .............................................. .................................................. ..sesenta y cinco
Embalaje de distribución ................................................ .................................................. ..............sesenta y cinco
Servicios SOAP incrementales ............................................... .................................................. ...... 66

Servicios REST incrementales ............................................... .................................................. ...... 66
Empaquetado básico de aplicaciones web .............................................. ................................................. 67
PAS para el empaquetado de instancias de OpenEdge ............................................. ........................................ 67
Proceso de instalación y actualizaciones .............................................. ................................................. 68
Ajuste de rendimiento y recursos .............................................. .................................................. ........ 70

Las funciones clásicas de AppServer no se aplican a PAS para OpenEdge ......................................... .............. 70
Herramientas del proceso de desarrollo ............................................... .................................................. .... 71
Paquete de instalación y despliegue .............................................. ........................................ 71

Herramientas de administración y monitoreo del sitio ............................................. ....................................... 71
Seguridad en el clásico AppServer versus PAS para OpenEdge .......................................... .......................... 72
Spring Security en PAS para OpenEdge ............................................ .......................................... 73
Migrar aplicaciones clásicas de WebSpeed .............................................. ..... 75
4 OpenEdgeWeb Paper: Versión

Derechos de autor
© 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
Última actualización con nuevo contenido: Lanzamiento 12

Capítulo 1: Copyright

Prefacio
Propósito
El propósito de este contenido es introducir los siguientes conceptos:
• Migración de aplicaciones clásicas de AppServer a PAS para OpenEdge
• Inicio rápido: paso a PAS para el tutorial de OpenEdge
• Referencia de migración de código de aplicación ABL
• Migrar la referencia de administración y configuración del servidor
• Migrar aplicaciones clásicas de WebSpeed
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
Migración de código de aplicación ABL en la página 35
Migrar la configuración y la administración del servidor en la página 57
Migrar aplicaciones clásicas de WebSpeed en la página 75
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.

Capítulo 1: Prefacio

2
Más información sobre la migración de aplicaciones clásicas de
AppServer a PAS para 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:
• Migración de código de aplicación ABL en la página 35
• Migrar la configuración y la administración del servidor en la página 57
• Migrar aplicaciones clásicas de WebSpeed en la página 75

Capítulo 2: Obtenga información sobre la migración de aplicaciones clásicas de AppServer a PAS para OpenEdge
Más información sobre PAS para OpenEdge
Utilice los siguientes recursos para obtener más información sobre PAS para OpenEdge.
Lea 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:
• Servidor de aplicaciones de progreso para la administración de OpenEdge (1000-095) curso disponible en

https://wbt.progress.com
Unete a la communidad:
• Hacer una pregunta: https://community.progress.com/community_groups/openedge_development
• Descargue documentos técnicos sobre temas avanzados y otros recursos:

https://community.progress.com/community_groups/openedge_general/m/documents
Para obtener más detalles, consulte los siguientes temas:
• Diferencias entre AppServer clásico, WebSpeed Transaction Server y PAS para OpenEdge
Diferencias entre AppServer clásico, WebSpeed Transaction

Server y PAS para OpenEdge
Diferencias entre PAS para OpenEdge y Progress AppServer
La siguiente lista presenta los puntos clave que influirán en sus planes de migración.
• 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.

Diferencias entre AppServer clásico, WebSpeedTransaction Server y PAS para OpenEdge
• 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.
• Transporte APSV es para clientes ABL, clientes Java o .NET OpenClients.
• Transporte REST es para clientes REST, móviles y web existentes.
• Transporte SOAP es para clientes de servicios web SOAP.
• Transporte WEB es para WebSpeed y nuevos clientes de servicios web.
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

Capítulo 2: Obtenga información sobre la migración de aplicaciones clásicas de AppServer a PAS para OpenEdge
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
contexto para conexiones administradas por sesiones vinculadas y no vinculadas .
• 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.
Diferencias entre PAS para OpenEdge y WebSpeedTransaction Server

PAS para OpenEdge proporciona un controlador web de compatibilidad especial que tiene las siguientes ventajas básicas sobre WebSpeed
Transaction Server:
• 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 .

3
Inicio rápido: mueva las aplicaciones clásicas de
AppServer a PAS para 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.
Se puede encontrar un código de inicio de muestra en la comunidad general de Progress OpenEdge:

https://community.progress.com/community_groups/openedge_general/m/documents/3775
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.

Capítulo 3: Inicio rápido: mover aplicaciones clásicas de AppServer a PAS para OpenEdge
Para completar este tutorial de inicio rápido, debe tener:
• Permisos del sistema para instalar y ejecutar scripts
• Acceso a archivos de aplicaciones de AppServer clásicos existentes
• Conocimiento de configuración de AppServer clásico
• Una licencia de PAS para desarrollo o producción OpenEdge
• Habilidades básicas de desarrollo de ABL
Archivos y estructura de archivos para el tutorial
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:
• ubroker.properties : Archivo de propiedades para el AppServer clásico que se encuentra en el

Ruta de instalación de OpenEdge / compartimiento directorio.
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.
• events / session_startup.p y events / session_shutdown.p —Ejemplo de inicio y apagado

procedimientos de eventos que escriben mensajes en el archivo de registro del agente de la aplicación PAS para OpenEdge.
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.

Si está ejecutando los archivos de muestra, el directorio de trabajo se completará con la siguiente estructura de archivos a medida que avance en el
tutorial:
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
• Bienvenido a PAS para OpenEdge
• 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
• transportes de OpenEdge Detalles importantes sobre su nuevo servidor
• Próximos pasos con PAS para OpenEdge

Bienvenido a PAS para OpenEdge

Como administrador del sistema de una aplicación clásica de AppServer, es hora de que mueva esas aplicaciones a una instancia de prueba de producción del
PAS para OpenEdge para realizar pruebas. Este tutorial de inicio rápido hace que sus aplicaciones se ejecuten y conecta a sus clientes con el nuevo servidor.
Después de completar los pasos de este tutorial, revise el Próximos pasos con PAS para OpenEdge en el tema de la página 34, donde encontrará enlaces
adicionales para modernizar, asegurar y ajustar su nuevo servidor para producción.
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.
Prepárese para pasar de Classic AppServer a PAS para OpenEdge
Complete los siguientes pasos para configurar el servidor y ajustar sus propiedades para admitir el código de su aplicación:
dieciséis OpenEdgeWeb Paper: Versión

1. Instale productos OpenEdge.
2. Cree una instancia de PAS para OpenEdge.
3. Generar un emerger archivo utilizando la utilidad paspropconv.
4. Mueve el setenv guión al nombre de instancia/ compartimiento directorio.
5. Revise y actualice el emerger archivo:
a. Actualice las entradas de PROPATH en el emerger archivo (donde sea necesario).
segundo. Actualice las conexiones de la base de datos en el emerger archivo (donde sea necesario).
6. Fusionar los cambios con la utilidad oeprop.
1. Instale los productos OpenEdge
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 .
2. Cree una instancia de PAS para OpenEdge
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:
proenv> cd% WRKDIR%

proenv> cd
C: \ OpenEdge \ 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
En este ejemplo, se especifican las siguientes opciones:
• - v : Especifica la salida detallada de la consola.
• - 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ó.
pasman. {sh | bat} prueba -I myProdInstance
los prueba de pasman El comando muestra las variables de entorno PAS para OpenEdge y confirma que el servidor puede inicializarse.

3. Cree un archivo oemerge con la utilidad paspropconv

Tu existente ubroker.properties debe convertirse a la nueva openge.properties formato utilizado por PAS para OpenEdge. Para completar
este paso, puede utilizar el ubroker.properties archivo que admita su aplicación clásica de AppServer, o el ubroker.properties archivo
incluido con los archivos de ejercicio que admite una aplicación clásica de ejemplo de AppServer.
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:
mover C: \ Downloads \ classicAppServerCode% WRKDIR%
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:
cd% WRKDIR% \ myProdInstance \ conf
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:
- - ubrokerPropsFile Ruta al servidor de aplicaciones clásico existente

ubroker.properties archivo.
- - ubrokerName Nombre completo del corredor cuyas propiedades está

convirtiendo. En este ejemplo,
UBroker.AS.app_customername_prod.
- - pasoeAppName Nombre de la nueva instancia. En este ejemplo,

myProdInstance.
La utilidad paspropconv genera los siguientes archivos en el directorio actual ( nombre de instancia/ conf):
• myProdInstance.app_customername_prod.oemerge —El archivo de combinación de PAS para OpenEdge.
• app_customername_prod_setenv.bat —El archivo de entorno para Windows.
• app_customername_prod_setenv.sh —El archivo de entorno para UNIX.
• paspropconv.log —El archivo de registro de la conversión de propiedad.

4. Mueva el script setenv a la nombre de instancia/ compartimiento directorio

La utilidad paspropconv genera cuatro archivos. Mueve el setenv archivo de variable de entorno a / compartimiento directorio de su PAS para la instancia de
OpenEdge.
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:
(Sistema operativo Windows)

> mover app_customername_prod_setenv.bat ../bin
(SO UNIX)
> mv nombre_cliente_aplicación_prod_setenv.sh ../bin
5. Revise y actualice el archivo oemerge.

Revisa el nombre-instancia.uBrokerName. emerger archivo, que lleva el nombre del uBrokerName tú
especificado para la conversión. Lea atentamente cada sección del archivo para comprender los cambios que se realizarán
para usted openge.properties archivo.
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.
1. La muestra myProdInstance.app_customername_prod.oemerge archivo indica que lo siguiente

Se requieren procedimientos de inicio:
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:
(Sistema operativo Windows)

proenv> Xcopy / I% WRKDIR% \ classicAppServerCode \ events
% WRKDIR% \ myProdInstance \ openge \ events
(SO UNIX)

proenv> cp -avr $ WRKDIR / classicAppServerCode / events

$ WRKDIR / myProdInstance / opensge / events
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:
- db C: \ OpenEdge \ WRK \ database \ sports2020.db -H localhost

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:
procopy% DLC% \ sports2020.db% WRKDIR% \ database \ sports2020.db
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:
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.
6. Fusionar los cambios con la utilidad oeprop

Después de generar el emerger utilizando la utilidad paspropconv y adaptando el archivo para que se adapte a su entorno, puede fusionar las
propiedades con el openge.properties para su instancia PAS para OpenEdge utilizando la utilidad oeprop.
1. Ve a la / compartimiento directorio de su PAS para la instancia de OpenEdge. Por ejemplo:
cd% WRKDIR% \ myProdInstance \ bin
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:
oeprop. {sh | bat} -f .. \ conf \ myProdInstance.app_customername_prod.oemerge

Mueva el código clásico de AppServer a PAS para OpenEdge
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
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

Después de fusionar las propiedades de la aplicación clásica de AppServer con su instancia PAS para OpenEdge, está listo para mover el código de su
aplicación. Sigue estos pasos:
1. Mueva su código de servidor (es posible que no todos los tipos de conexión sean necesarios para su aplicación):
a. Mover el código del servidor ABL.
segundo. Mueva el código del servidor WebSpeed.
C. Mueva el código del servidor REST.
re. Mueva el código del servidor SOAP.
2. Pruebe su acceso a la base de datos.
3. Inicie su instancia de PAS para OpenEdge.
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.
1. Mueva su código de servidor
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.

1a. Mover el código del servidor ABL
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.
1. En el % WRKDIR% / classicAppServerCode directorio, copie su código de servidor ABL

( ServerGetCustNameSample.p) al nombre de instancia/ abierto directorio. Por ejemplo:
proenv> cd% WRKDIR% \ classicAppServerCode

proenv> copiar ServerGetCustNameSample.p% WRKDIR% \ myProdInstance \ openge \
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:
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
datos. Por ejemplo:
proenv> oeprop. {sh | bat} AppServer.SessMgr.myProdInstance.agentStartupParam

- T "C: \ OpenEdge \ WRK \ myProdInstance / temp" -pf
proenv> más% WRKDIR% \ classicAppServerCode \bases.pf
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 .
1b. Código de servidor MoveWebSpeed
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.
3. En el openge.properties archivo, configure el defaultHandler propiedad a

OpenEdge.Web.CompatibilityHandler. Por ejemplo:
[myProdInstance.ROOT.WEB]
defaultHandler = OpenEdge.Web.CompatibilityHandler
4. Si modificó su web-disp.p, debe realizar cambios similares al predeterminado web-handler.p.
Nota: OpenEdge no admite aplicaciones con objetos web mapeados en HTML.
Para obtener más información sobre el código WebSpeed, consulte Migrar aplicaciones WebSpeed a PAS para OpenEdge .
1c. Mover el código del servidor REST
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.
1. Copie el código que admite la API de la interfaz REST en el directorio:

nombre de instancia/ webapps / ROOT / WEB-INF / opensge. Por ejemplo:
proenv> cd% WRKDIR% \ classicAppServerCode \ classicREST

proenv> copiar getCustomer.p% WRKDIR% \ myProdInstance \ ROOT \ WEB-INF \ openge proenv> copiar
getAllCustomers.p% WRKDIR% \ myProdInstance \ ROOT \ WEB-INF \ opensge
Nota: Los archivos del tutorial de muestra admiten los siguientes recursos del servicio REST:
• / classicRESTService / clientes
• / classicRESTService / customers / {custId}
2. Navegar a nombre de instancia/ compartimiento. Por ejemplo:
proenv> cd% WRKDIR% \ myProdInstance \ bin
3. Ejecutar el deployREST comando con la ruta al. paar archivo y el nombre de la aplicación web ABL.
Por ejemplo:
proenv> deployREST% WRKDIR% \ classicAppServerCode \ classicREST \ classicRESTService.paar RAÍZ

4. Actualice las conexiones de la base de datos según sea necesario en el agentStartupParam en el

nombre de instancia/ conf / openge.properties archivo y asegúrese de que la base de datos se esté ejecutando.
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:
http: // nombre de host: puerto / rest / classicRESTService / clientes

http: // nombre de host: puerto / rest / classicRESTService / clientes / 3005
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:
http: // localhost: 8817 / ablwebapp_name / rest / classicRESTService / customers
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 .
1d. Mover el código del servidor SOAP
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.
2. Ir nombre de instancia/ compartimiento.
3. correr deploySOAP. {sh | bat} source_descriptor ROOT
Dónde:
source_descriptor Especifique la ruta del descriptor de origen, que es un archivo WSM.
Nombre del Servicio Especifique el nombre del servicio de destino.
Para obtener más información sobre deploySOAP, consulte Implementar servicios SOAP .

2. Pruebe el acceso a su base de datos
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:
proservar% WRKDIR% \ database \ sports2020
La base de datos se ha iniciado correctamente cuando ve el Inicio de sesión multiusuario y Iniciar sesión por
mensajes.
2. Confirme que el agentStartupParam propiedad en tu nombre de instancia/ conf / openge.properties

archivo hace referencia correctamente a su servidor de base de datos.
• 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:
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:
proenv> oeprop. {sh | bat} AppServer.SessMgr.myProdInstance.agentStartupParam

- T "C: \ OpenEdge \ WRK \ myProdInstance / temp" -pf
proenv> más% WRKDIR% \ classicAppServerCode \bases.pf
3. Inicie su instancia PAS para OpenEdge

Antes de probar las conexiones del cliente, pruebe el procedimiento de inicio del servidor y la conectividad de la base de datos. En este paso, inicie o reinicie el servidor para
confirmar que los procedimientos de inicio están disponibles y el. pf las conexiones de archivos están funcionando.
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.
pasman. {sh | bat} pasoestart -restart -I myProdInstance
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.
- YO Especifica el nombre de la instancia.

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
se ejecutó el procedimiento de inicio.
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.034-0400 027876 018972 2 AS-ResourceMgr mtapsv: - :? CONN

Conectado a la base de datos sports2020, usuario número 5. (9543)
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!
Consejos para solucionar problemas:
• 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
• procedimientos del evento estén disponibles en PROPATH.
Conecte a los clientes con el nuevo PAS para transportes OpenEdge
Para conectar aplicaciones cliente con nuevos transportes:
1. Actualice sus conexiones de cliente.
2. Pruebe las conexiones de sus clientes.
3. Detén tu instancia.

1. Actualice sus conexiones de cliente
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:
Cambios en la aplicación por tipo de cliente…
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:
- URL http: // Puerto host/ apsv
Cambiar la conexión del cliente ABL para utilizar el transporte APSV Desde:
- S Puerto - H anfitrión - AppService brokername
A:
- URL http: // Puerto host/ apsv
DESCANSO
Cambiar las URL del cliente para usar la aplicación web ROOT Desde:
http: // Puerto host/ servicio de descanso / descanso / descanso
A:
http: // Puerto host/ descanso/ descanso
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

Cambios en la aplicación por tipo de cliente…
WebSpeed
Cambiar los clientes de WebSpeed para usar el transporte WEB Desde:
http: // Puerto host/ cgi / wspd_cgi.sh /. . .
A:
http: // Puerto host/ web /. . .
* WSASP, WSISA, NSAPI y CGIIPmessengers son

no se utiliza con PAS para OpenEdge.
Para actualizar una conexión de cliente OpenEdge ABL, siga estos pasos:
1. Abre el ClassicClient.p archivo en un editor. Por ejemplo:
proenv> mpro C: \ OpenEdge \ WRK \ classicAppServerCode \ ClassicClient.p
2. Inspeccione el ClassicClient.p archivo, específicamente el cConnect cuerda:
ASIGNAR iCustNum = 3005.
CREAR SERVIDOR hServer.
cConnect = "-S 5162 -H localhost -AppService asbroker1".
lReturn = hServidor: CONNECT (cConnect).
SI (lReturn) ENTONCES HAGA:

EJECUTE ServerGetCustNameSample.p EN hServer (INPUT iCustNum, OUTPUT cCustName). MOSTRAR "Nombre del
cliente:" cCustName FORMAT "x (40)" SKIP.
hServidor: DESCONECTAR ().
FIN.
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:
ASIGNAR iCustNum = 3005.
CREAR SERVIDOR hServer.
cConnect = "- URL http: // localhost: 8817 / apsv -sessionModel Session-Free ".
lReturn = hServidor: CONNECT (cConnect).

SI (lReturn) ENTONCES HAGA:

EJECUTE ServerGetCustNameSample.p EN hServer (INPUT iCustNum, OUTPUT cCustName). MOSTRAR "Nombre del
cliente:" cCustName FORMAT "x (40)" SKIP.
hServidor: DESCONECTAR ().
FIN.
SALIDA CERRADA.
DEJAR.
4. Guarde el archivo como PASforOpenEdgeClient.p.
5. Vuelva a compilar el código del cliente y salga del archivo.
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:
/ * Código de muestra, ejecutado en Appserver, obtiene el nombre del cliente

de la base de datos "sports2020", basada en el número de cliente enviado por el cliente.
*/
DEF INPUT PARAM iCustNum COMO INTEGER. PARAM DE

SALIDA DEF cCustName COMO CHAR.
SI ESTÁ CONECTADO ("sports2020") ENTONCES HAGA:

ENCUENTRE EL PRIMER cliente DONDE custNum = iCustNum NO-LOCK NO-ERROR. SI EL CLIENTE ESTÁ
DISPONIBLE ENTONCES
cCustName = Nombre.
MÁS
cCustName = "Sin registro".
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.
Prueba las conexiones de tus clientes
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:
proenv> mpro% WRKDIR% \ classicAppServerCode \ PASforOpenEdgeClient.p
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.
pasman. {sh | bat} detener -I myProdInstance
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:
¡Este es un procedimiento de evento de cierre de sesión!
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.276-0400 027876 018972 2 AS-ResourceMgr mtapsv: - :? CONN

Desconectando de la base de datos sports2020, usuario número 5. (9545)
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:
• Detalles importantes sobre su nuevo servidor
• Próximos pasos con PAS para OpenEdge en la página 34
Detalles importantes sobre su nuevo servidor

Aquí hay algunos detalles importantes sobre su nuevo servidor:
PAS para OpenEdge se diferencia fundamentalmente del clásico AppServer
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
( nombre de instancia/ conf / abl_app_name.ubroker_name. oemerge).
La última versión lo mantiene actualizado con las actualizaciones de seguridad y software.
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.

Detalles importantes sobre su nuevo servidor
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 .
PAS para OpenEdge puede no iniciarse debido a errores en su aplicación ABL

El archivo de registro del agente de multisesión PAS para OpenEdge distingue entre mensajes de ERROR, ADVERTENCIA o INFO. Como resultado, el PAS para
OpenEdge pasoestart El comando solo puede informar si el proceso del sistema operativo del agente se detuvo debido a problemas de inicio. Si pasoestart no
informa específicamente el error de inicio, luego inspecciona manualmente el archivo de registro del agente en el nombre de instancia/ registros directorio abl_app_name.
agente.{ fecha}. Iniciar sesión) para determinar cuál es el problema de inicio y corregirlo.
Configure y pruebe su instancia antes de pasar a producción

Elegir el tamaño de imagen de máquina correcto y PAS óptimo para la configuración de OpenEdge para esa imagen de máquina es clave para trasladar su
aplicación ABL al entorno de producción. PAS para OpenEdge está optimizado para el consumo de recursos y el rendimiento bajo carga. A diferencia de los
clásicos AppServer o WebSpeed, no puede derivar el rendimiento de la aplicación ABL utilizando un solo cliente. Pruebe su aplicación con el número anticipado
de clientes simultáneos para asegurarse de que no exceda los límites de recursos finitos impuestos por el sistema operativo, los procesos del sistema operativo,
las redes y la base de datos OpenEdge . Para más información, ver Objetivos y pasos comunes para ajustar PAS para instancias de OpenEdge .
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 de Apache Tomcat es una excelente herramienta de resolución de problemas
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 es un mecanismo de alerta útil
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.
®

Permisos de archivos UNIX que solo permiten el uso de root
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 .
Próximos pasos con PAS para OpenEdge

Si usted es …
• 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
los modos operativos clásicos de AppServer en la página 37
• Migración de certificados de servidor SSL: Gestión de certificados digitales
• Ajuste de PAS para OpenEdge para rendimiento: Ajuste PAS para instancias de OpenEdge
• Supervisión de PAS para OpenEdge: Supervisar 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 .

4
Migración de código de aplicación ABL
Este contenido describe los conceptos necesarios para migrar el código ABL a PAS para OpenEdge, que incluyen:
• Mejores prácticas para la estructura de la aplicación ABL
• Diferencias entre el clásico AppServer y PAS para OpenEdge
• Migración de conexiones de cliente de AppServer clásicas a PAS para OpenEdge
• Estructura de la aplicación ABL
• Migrar los modos operativos clásicos de AppServer
• Diferencias en los procedimientos de eventos entre el clásico AppServer y PAS para conexiones de base de datos
• OpenEdge en PAS para OpenEdge
• Cambios de ABL en PAS para la configuración del entorno
• OpenEdge en PAS para OpenEdge
• Rutas y directorios del sistema de archivos en PAS para OpenEdge Migre las
• conexiones del cliente a PAS para OpenEdge

Capítulo 4: Migración de código de aplicación ABL
Estructura de la aplicación ABL

Migrar una aplicación a PAS para OpenEdge significa reorganizar la estructura de su aplicación con el objetivo de hacer que las aplicaciones sean más fáciles
de implementar, escalar y extender. PAS para OpenEdge es un servidor web y sus aplicaciones se moverán hacia una estructura de aplicación de servidor web.
El código se puede organizar en los siguientes niveles:
• 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
aplicaciones web en todas las instancias.
• 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.
• trabajo —Archivos de trabajo persistentes generados por la aplicación.
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 .

Migrar los modos operativos clásicos de AppServer
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 .
Directorios de servicios 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.

En el clásico OpenEdge AppServer, los modos de funcionamiento para administrado por sesión las conexiones del cliente se determinan en la configuración clásica de
AppServer. Los posibles modos de funcionamiento para las conexiones gestionadas por sesión son
restablecimiento de estado, consciente del estado, y apátrida. por sin sesión conexiones de cliente, el modo de funcionamiento es siempre
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:
Tabla 1: Procedimientos de eventos gestionados por sesión
Procedimiento AppServer clásico PAS para OpenEdge Comentarios
Puesta en marcha Siempre Siempre Ningún cambio ; ejecutar persistente
Apagar Siempre Siempre Ningún cambio
Conectar Siempre Siempre Ningún cambio ; ejecutar persistente
Desconectar Siempre Siempre Ningún cambio

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
Mientras
SESIÓN: SERVIDOR-
FALSO
Tabla 2: Procedimientos de eventos gestionados por sesión
Puesta en marcha Siempre Siempre Ningún cambio ; ejecutar persistente
Conectar Siempre Siempre Ningún cambio ; ejecutar persistente
Desconectar Siempre Siempre Ningún cambio
Activar Nunca (1); Condicional (2) Siempre PAS para OpenEdge sigue el
Mientras
SESIÓN: SERVIDOR-
FALSO
Desactivar Nunca (1); Condicional (2) Siempre PAS para OpenEdge sigue el
Mientras
SESIÓN: CONEXIÓN AL SERVIDOR VINCULADA
= FALSO
Tabla 3: Procedimientos de eventos sin sesión
Puesta en marcha Siempre Siempre Ningún cambio
Conectar Nunca Nunca Ningún cambio
Desconectar Nunca Nunca Ningún cambio

Activar Condicional (3) Siempre PAS para OpenEdge sigue el

comportamiento clásico sin estado,
Mientras
SESIÓN: SERVIDOR-
FALSO
Desactivar Condicional (3) Siempre PAS para OpenEdge sigue el

Mientras
SESIÓN: SERVIDOR-
FALSO
Tabla 4: Procedimientos de eventos sin sesión
Puesta en marcha Siempre Siempre Ningún cambio
Conectar Nunca Nunca Ningún cambio
Desconectar Nunca Nunca Ningún cambio
Activar Condicional (3) Siempre PAS para OpenEdge sigue el

Mientras
= FALSO
Desactivar Condicional (3) Siempre PAS para OpenEdge sigue el

Mientras
= 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
el cliente está en un estado ligado.
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.
Migrar el modo operativo clásico de restablecimiento de estado
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:
SESIÓN: SERVER-CONNECTION-BOUND-REQUEST = TRUE.
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:
SESIÓN: SERVER-CONNECTION-BOUND-REQUEST = FALSE.

DEJAR.
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.
Migrar el modo operativo clásico con reconocimiento de estado
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:
SESIÓN: SERVER-CONNECTION-BOUND-REQUEST = TRUE.

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:
SESIÓN: SERVER-CONNECTION-BOUND-REQUEST = FALSE.
Migrar el modo de funcionamiento sin estado clásico
No se requieren cambios en los procedimientos de eventos para migrar aplicaciones que se ejecutan en un AppServer clásico sin estado.
Migrar el modo operativo 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.
Diferencias en los procedimientos de eventos entre el clásico

AppServer y PAS para OpenEdge
PAS para OpenEdge usa un agente multisesión, lo que significa que un solo agente puede manejar simultáneamente solicitudes de varios clientes, cada uno
en su propia sesión y cada uno ejecutando su propio modelo de aplicación. Esta forma de ejecutar aplicaciones ABL podría cambiar el uso que hace su
aplicación de los procedimientos de eventos.
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.
Procedimientos de inicio y apagado del agente de múltiples sesiones
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:

Diferencias en los procedimientos de eventos entre el clásico AppServer y PAS para OpenEdge
Tabla 5: Procedimientos de inicio y apagado del agente multisesión
Nombre del procedimiento Persistencia Corre en Parámetros
agentStartupProc No persistente Agente multisesión Un solo PERSONAJE

inicio del proceso argumento pasado al procedimiento
como un ENTRADA
parámetro y especificado
como el
agentStartupProcParam
propiedad en
openge.properties
agentShutdownProc No persistente Agente multisesión Ninguna
cierre del proceso
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.
Procedimientos de inicio y cierre de sesiones
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
Las propiedades clásicas de AppServer en ubroker.properties son srvrStartupProc, srvrStartupParam,

y srvrShutdownProc.
El PAS correspondiente para las propiedades OpenEdge en openge.properties son sessionStartupProc,

sessionStartupProcParam, y sessionShutdownProc.
En ambos servidores, estas propiedades se implementan como nombre-parámetro = valor pares.
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
sessionStartupProc Persistente Persistente Inicio de sesión ABL Una cadena de sesión

parámetros de inicio
especificado como el
sessionStartupProcParam
propiedad en
openge.properties
sessionShutdownProc No persistente No persistente Sesión ABL Ninguna
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.
Procedimientos de conexión y desconexión
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
Las propiedades clásicas de AppServer en ubroker.properties son srvrConnectProc y srvrDisconnProc.
El PAS correspondiente para las propiedades OpenEdge en openge.properties son sessionConnectProc

y sessionDisconnProc.
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:

Diferencias en los procedimientos de eventos entre el clásico AppServer y PAS para OpenEdge
Tabla 7: Comparación de los procedimientos de conexión y desconexión entre AppServer y PAS para OpenEdge
Nombre del procedimiento AppServer PAS para OpenEdge Corre en Parámetros

persistencia persistencia
sessionConnectProc Persistente Persistente Cliente OpenEdge Sin cambios

conexión
sessionDisconnProc No persistente No persistente Cliente OpenEdge Ninguna
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
SESIÓN: CLIENTE-SERVIDOR-SOLICITUD-VINCULADA a FALSO.
• 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
AppServer y PAS para OpenEdge.
Activar y desactivar procedimientos

El clásico AppServer proporciona procedimientos de eventos de activación y desactivación de sesiones ABL que le permiten administrar la inicialización y
limpieza de la solicitud de un cliente en modelos tanto de sesión independiente administrada como sin 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, según las limitaciones impuestas por la arquitectura de
una aplicación. 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 de AppServer es una única sesión ABL que se ejecuta como un único proceso de SO (AVM).
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?
Restablecimiento de estado Unido Unido No
Estado consciente Unido Unido No
Apátrida Sin consolidar Sin consolidar si
Libre de estado Sin consolidar Sin consolidar si
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:
1. El cliente ejecuta un procedimiento persistente en el AppServer (sin estado o sin estado).
• El procedimiento Activate se ejecuta antes del bloque principal del procedimiento persistente. El estado vinculado al cliente se
• establece después de que se ejecuta el procedimiento de activación.
• 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:

Conexiones de base de datos en PAS para OpenEdge
Modelo de aplicación Estado enlazado inicial Estado límite final Puede cambiar de límite
¿estado?
Gestionado por sesión Sin consolidar Sin consolidar si
Sin sesión Sin consolidar Sin consolidar si
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
Las propiedades clásicas de OpenEdge AppServer en ubroker.properties son srvrActivateProc y

srvrDeactivateProc.
El PAS correspondiente para las propiedades OpenEdge en openge.properties son sessionActivateProc

y sessionDeactivateProc.
Conexiones de base de datos en PAS para OpenEdge

La política de conexión a la red de la base de datos de OpenEdge no cambió en PAS para OpenEdge. Al igual que el AppServer clásico, es una
conexión de red privada por sesión ABL en el agente multisesión. Por lo tanto, el código de la aplicación y el monitoreo de PROMON son los
mismos para ambos servidores.
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.

Cambios de ABL en PAS para OpenEdge

Los cambios de ABL en PAS para OpenEdge incluyen:
• Modificaciones al ABL existente
• Nuevo ABL específico para PAS para OpenEdge
Modificaciones al ABL existente

Si bien ha cambiado muy poco en el soporte ABL existente, la siguiente tabla enumera algunas declaraciones, atributos de manejo y propiedades de clase
cuyo comportamiento o valores cambiaron cuando se ejecutan o consultan en una sesión PAS para OpenEdge ABL:
Tabla 9: AppServer ABL cambiado para PAS para OpenEdge
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 "
SESIÓN: TIPO DE CLIENTE atributo "AGENTE MULTISESIÓN"
SESSION: LOCAL-VERSION-INFO: OEClientType "MULTI-SESSION-AGENT"

propiedad de clase
Nuevo ABL específico para PAS para OpenEdge
La siguiente tabla enumera las nuevas opciones de instrucción ABL y propiedades de clase que se agregaron específicamente para PAS para OpenEdge:
Tabla 10: Nuevo ABL agregado para PAS para OpenEdge
Opción o clase de declaración Rango de valores Descripción

propiedad
A SALVO DE AMENAZAS opción de la N/A Le dice al administrador de sesiones de PAS para
PROCEDIMIENTO declaración OpenEdge que la DLL declarada o el procedimiento de
biblioteca compartida es seguro para subprocesos, por lo
que puede ejecutarse en múltiples sesiones de servidor
simultáneamente
SESIÓN: CURRENT-REQUEST-INFO: AgentId Entero positivo Devuelve el ID del agente

propiedad de clase * multisesión actual.
SESIÓN: CURRENT-REQUEST-INFO: SessionId Entero positivo Devuelve el ID de la sesión ABL actual

propiedad de clase * dentro de la actual
agente multisesión

Configuración del entorno en PAS para OpenEdge
Opción o clase de declaración Rango de valores Descripción

propiedad
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
SESIÓN: CURRENT-REQUEST-INFO: AdapterType Devuelve un valor enumerado que

propiedad de clase * representa el tipo de cliente que realizó la
solicitud.
Nota: Un asterisco (*) indica que este ID es dinámico y puede cambiar cada vez que se inicia una instancia de PAS para OpenEdge.
Configuración del entorno en PAS para OpenEdge

Las variables de entorno para el AppServer clásico se establecen en $ DLC / propiedades / ubroker.properties
archivo en una sección similar a la siguiente:
[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:
• A nivel de aplicación - Definir un myenv_ setenv. {sh | bat} guión y colóquelo en el

nombre-instancia / bin directorio.
• 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.
Rutas y directorios del sistema de archivos en PAS para OpenEdge
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
Camino AppServer clásico PAS para OpenEdge Comentarios
Directorio de trabajo $ WRKDIR $ CATALINA_BASE / trabajo Reubicado en el PAS para

Instancias de OpenEdge
trabajo directorio
Directorio temporal CWD ( trabajo actual $ CATALINA_BASE / temp Reubicado en PAS para
directorio) Instancias de OpenEdge
temperatura directorio
PROPATH $ WRKDIR $ CATALINA_BASE / openge Reubicado para que el ABL

el código de la aplicación es
ubicado en la instancia que lo ejecuta
Migre las conexiones del cliente a PAS para OpenEdge

Cuando migre clientes desde el acceso al AppServer clásico o sus adaptadores al acceso a PAS para OpenEdge, busque las declaraciones o
rutinas que invocan el código de conexión y asegúrese de que utiliza una URL adecuada para conectarse a la aplicación web ABL, incluido un
servicio de transporte. y la ruta de recurso adecuada para el tipo de cliente.
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
instancia / [oeabl-web-application /] transporte [/ service-resource]
ejemplo
Especifica la instancia PAS para OpenEdge con la que conectarse utilizando la siguiente sintaxis:

Sintaxis
esquema: // [nombre de usuario: contraseña @ ] host: puerto
esquema
Especifica ya sea HTTP o HTTPS.
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.
[ nombre de usuario: contraseña @ ]
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
Acceda al ID de conexión en un cliente administrado por sesión .
anfitrión
Especifica el nombre o dominio del PAS para el host OpenEdge.
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
Especifica el transporte para la conexión utilizando la siguiente sintaxis:
Sintaxis
apsv | apsv | resto | web
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
wsdl? targetURI = urn: [ Espacio de nombres SOAP:] nombre-SOAPsvc | nombre-RESTsvc / ruta-recurso
[ Espacio de nombres SOAP:] nombre-SOAPsvc
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:
• Migre las URL de AIA para usar el transporte APSV en la página 53
• Migre las URL de WSA para utilizar el transporte SOAP en la página 54
• Migrar URL REST en la página 55
• Migrar aplicaciones clásicas de WebSpeed
• Utilice el equilibrio de carga en PAS para OpenEdge en la página 55
Migre las URL de AIA para usar el transporte APSV
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:
"-URL http: // host: puerto / apsv - sessionModel Session-free "

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 .
Migrar las URL de WSA para utilizar el transporte SOAP
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 .

Migrar URL REST

La única diferencia entre el clásico OpenEdge AppServer y PAS para OpenEdge con respecto a las URL utilizadas para conectarse y acceder a
OpenEdge REST y Data Object Services, es permitir el acceso a la configuración predeterminada.
RAÍZ Aplicación web ABL en PAS para OpenEdge.
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:
http: // Puerto host/ CustomerMaint / rest / CustomerSvc / CustConnect
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:
http: // Puerto host/ asbroker1WebAppl / rest / CustomerSvc / CustConnect
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:
http: // Puerto host/ resto / CustomerSvc / CustConnect
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 .
Utilice el equilibrio de carga en PAS para OpenEdge
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 .

5
Migrar la configuración y la administración del
servidor
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.
• Administrar instancias de servidor
• Migrar las propiedades clásicas de AppServer
• Empaquetado e instalación de aplicaciones
• Rendimiento y ajuste de recursos
• Las funciones clásicas de AppServer no se aplican a PAS para OpenEdge Security en
• AppServer clásico frente a PAS para OpenEdge

Capítulo 5: Migración de la configuración y administración del servidor
Administrar instancias de servidor

El AppServer clásico es una arquitectura de instancias múltiples. La instalación de OpenEdge contiene las bibliotecas, los archivos de configuración y otros
archivos de soporte principales de AppServer. Usted crea y administra una instancia utilizando una de las herramientas de administración de AppServer clásicas,
como OpenEdge Management o el mergeprop herramienta de línea de comandos. Cada instancia tiene su propia configuración y representa una aplicación ABL
(identificada por un conjunto de archivos de configuración, archivos de código r, procedimientos de configuración y agentes y corredores de AppServer clásicos).
Puede que no lo haya pensado de esta manera, pero la plantilla clásica Los AppServers (asbroker1, restbroker1 y otros) son, de hecho, instancias clásicas de
AppServer proporcionadas como ejemplos de desarrollo. Las aplicaciones ABL implementadas reales no suelen utilizar esas instancias de desarrollo.
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.

Administrar instancias de servidor
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:
1. Cree la instancia y asígnele un nombre.
2. Implementar. pag y / o. r archivos.
3. Configure la instancia clásica de AppServer (que define implícitamente una aplicación ABL).
4. Opcionalmente, implemente un servidor web e instale adaptadores, por ejemplo:
a. Descargue e instale Tomcat.
segundo. Configure Tomcat.
C. Opcionalmente, cambie la configuración de depuración de Tomcat a un tipo de producción seguro.
a. Opcionalmente, instale y configure una aplicación web de adaptador AIA.
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).
2. Configure el servidor principal de Tomcat para la instancia.
3. Implementar. r archivos. (. pag los archivos no se pueden compilar en un servidor de producción PAS para OpenEdge).
4. Implemente la aplicación web OpenEdge ABL de la aplicación ABL (una o más).
5. Configurar la aplicación ABL y sus componentes, incluido el administrador de sesiones ABL y multisesión
agentes.
6. Para cada aplicación web ABL implementada:
a. Configure el transporte APSV (habilitar o deshabilitar).
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.

Migrar las propiedades clásicas de AppServer

El AppServer clásico mantiene las propiedades de todas las instancias definidas en un solo archivo de propiedades ubicado en
$ DLC / properties / ubroker.properties. Con esas propiedades, define un conjunto de valores de propiedad que sirven como configuración predeterminada de la
aplicación. Un administrador que instala una aplicación normalmente define una nueva instancia clásica de AppServer y puede cambiar esos valores de
propiedad para adaptarse a los requisitos específicos de un sitio.
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).
Existen ciertas reglas para leer los nombres de las propiedades:
• Todos los nombres de propiedad clásicos de AppServer no proporcionan un grupo (un [...] nombre ya que las propiedades pueden existir en
alguna [ Ubroker…] grupo).
• 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.wrkdir [AppServer.Agent] wrkdir
• AppServer.Agent.oepas1.wrkdir [AppServer.Agent.oepas1] wrkdir
• PAS para grupos OpenEdge incluye:
• [AppServer] - Propiedades que se aplican en la instancia del servidor
• [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] - Propiedades que se aplican solo a la aplicación web de la aplicación ABL

llamado nombre-de-aplicación-web ( hereda de [ nombre de la aplicación])
• [ 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:
Tabla 12: Asignación de AppServer a PAS para propiedades de instancia de OpenEdge
Propiedad clásica de AppServer PAS para propiedad 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
connectionTimeout Ver catalina.properties
ControllerNameServer N/A
debuggerEnabled N/A
defaultService N/A
descripción N/A
ambiente N/A
flushStatsData AppServer.Agent.flushStatsData
Nombre del grupo N/A
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
maxClientInstance Ver openge.properties.README
maxSrvrInstance AppServer.SessMgr.maxAgents
minSrvrInstance N/A
noSessionCache AppServer.Agent.noSessionCache
modo operativo N/A
contraseña N/A
número de puerto Ver catalina.properties
PrioridadPeso N/A
PROPATH AppServer.Agent.PROPATH
registerNameServer N/A
registrationMode N/A
registroReintentar N/A
pide tiempo fuera AppServer.SessMgr.requestWaitTimeout
serverASKActivityTimeout N/A
serverASKResponseTimeout N/A
serverLifespan N/A
serverLifespanPadding N/A
hora de término de la sesión AppServer.Agent.sessionTimeout
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
nombre de usuario N/A
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

Embalaje e instalación de la aplicación
N/A nombre de la aplicación. webApps
N/A nombre de la aplicación. SessionMgr
N/A appname.web-app-name. adapterEnabled
N/A appname.web-app-name. SOAP.adminEnabled
N/A appname.web-app-name. SOAP.adminSoapAction
N/A appname.web-app-name. SOAP.debugClients
N/A appname.web-app-name. SOAP.wsdlEnabled
N/A appname.web-app-name. SOAP.wsaUrl
N/A AppServer.SessMgr.publishDir

PAS para OpenEdge admite una variedad de opciones de empaquetado e instalación, desde la instalación de aplicaciones en una instancia PAS para
OpenEdge existente hasta la instalación completa de PAS para instancias OpenEdge basadas en una instalación existente. Esta flexibilidad se debe a que
una aplicación ABL siempre se instala como parte de una aplicación web OpenEdge ABL implementada en el servidor web PAS para OpenEdge. Al mismo
tiempo, esta aplicación web puede admitir todos los clientes de servicios web SOAP y REST, así como el acceso ABL y Open Client, a la misma aplicación
ABL. Por último, la aplicación ABL, en sí misma, puede ser compatible con múltiples aplicaciones web OpenEdge ABL en una única instancia PAS para
OpenEdge.
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.
OpenEdgeWeb Paper: Versión sesenta y cinco

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.
Además, PAS para OpenEdge admite:
• 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.
Servicios SOAP incrementales
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á:
1. Desempaquete los archivos en una ubicación temporal.
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.
Servicios REST incrementales
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á:
1. Desempaquete los archivos en una ubicación temporal.
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.
Empaquetado básico de aplicaciones web
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 el empaquetado de instancias de OpenEdge
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.
Proceso de instalación y actualizaciones
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.
Instale una instancia de PAS preempaquetada para OpenEdge
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.
2. Establezca el directorio de trabajo actual en la ubicación donde se ubicará la instancia nombrada.
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
requisitos del sitio.
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.
Instale una aplicación web ABL preempaquetada

Este tipo de instalación extiende una instancia de PAS para OpenEdge existente. Si bien la implementación de aplicaciones web generales se puede
realizar en línea o fuera de línea, la implementación de las aplicaciones web ABL indica que la instalación se realiza mejor sin conexión.
Para instalar una aplicación web ABL preempaquetada:

1. Carga el . guerra archivo que contiene la aplicación web ABL preempaquetada.
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.
Actualizar una instalación, una aplicación web ABL o un servicio existente
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.
Instalar administración remota

El producto PAS para OpenEdge se ejecuta en una configuración segura a menos que se configure de otra manera. Por lo tanto, no incluye automáticamente
las aplicaciones web remotas utilizadas por OpenEdge Management (para los componentes Tomcat y OpenEdge). Toda la administración de Tomcat y
OpenEdge se puede realizar de forma local mediante una consola JMX; las aplicaciones web administrativas no ofrecen ninguna funcionalidad adicional. Si las
políticas del sitio permiten la administración remota, puede agregar estas aplicaciones web administrativas a una instancia de PAS para OpenEdge en cualquier
momento haciendo lo siguiente:

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.
Ajuste del rendimiento y los recursos

El ajuste de recursos y rendimiento de una instancia de PAS para OpenEdge no es similar a ajustar un AppServer clásico. Está más alineado con la optimización de un
servidor web, pero no exactamente, debido al soporte de lenguaje ABL. Para obtener información sobre cómo comenzar a ajustar una instancia de PAS para OpenEdge
para que sea más compatible con su aplicación ABL, consulte
Ajuste PAS para instancias de OpenEdge .
Las funciones clásicas de AppServer no se aplican a 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
• Nombre del servidor
• WSA
• Agente de administración remota REST (OERM)
• AdminServer
• Archivos de registro de AppServer clásicos
Los siguientes temas describen otros aspectos del trabajo con el AppServer clásico que no se aplican a PAS para OpenEdge.

Las funciones clásicas de AppServer no se aplican a PAS para OpenEdge
Herramientas del proceso de desarrollo
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.
Empaquetado e implementación de instalación
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.
Herramientas de administración y monitoreo del sitio
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.
PAS para OpenEdge proporciona varias funciones administrativas y de supervisión:
• 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.
Seguridad en AppServer clásico versus PAS para OpenEdge
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.
PAS para OpenEdge ofrece dos productos:
• Un producto de servidor de desarrollo no seguro
• Un producto de servidor de producción seguro
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.
El siguiente es un resumen de la configuración de seguridad del producto del servidor de producción:
• Eliminación del compilador ABL, evitando cualquier acceso no autorizado al código fuente Eliminación de todas las aplicaciones
• web de administración remota que pueden ser atacadas por intrusos
• 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
• Seguridad adicional válvulas en otras palabras, filtros de solicitud del servidor)
• 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,
consulte Instancias de desarrollo vs producción .

Seguridad en AppServer clásico versus PAS para OpenEdge
Spring Security en PAS para OpenEdge
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 .


6
Migrar aplicaciones ClassicWebSpeed
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:
1. Mueva los archivos estáticos de la aplicación a una carpeta específica en la instancia.
2. Actualice PROPATH de la instancia para incluir las carpetas que contienen el código r de la aplicación.
3. Habilite el transporte WEB en la instancia y use el controlador de compatibilidad en el openge.properties

archivo.
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.
La ubicación de los archivos estáticos para la aplicación web predeterminada es:
nombre de instancia/ webapps / ROOT / static
Si implementa otra aplicación, la ubicación predeterminada para sus archivos estáticos es:
nombre de instancia/ aplicaciones web / webapp_name / estático

Capítulo 6: Migración de aplicaciones ClassicWebSpeed
dónde webapp_name es el nombre de la aplicación WebSpeed o la aplicación web ABL.
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
aplicación WebSpeed al PROPATH del agente de la instancia.
La ubicación predeterminada para r-code es:
nombre de instancia/ abierto
PROPATH se establece en el nombre de instancia/ conf / openge.properties archivo. Por ejemplo:
[AppServer.Agent]
PROPATH = $ {CATALINA_BASE} / openge, $ {DLC} / tty, $ {DLC} /tty/netlib/OpenEdge.Net.pl
Nota: CATALINA_BASE es una variable de entorno que resuelve ruta_instancia.
Actualice openge.properties para habilitar el transporte WEB
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

Notas de migración
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 que utilizan mapeo HTML.
• 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:
http: // nombre de host: puerto / cgi / wspd_cgi.sh /. . .
En PAS para OpenEdge, la URL predeterminada hace referencia al transporte WebSpeed ( wspd) y no el Mensajero. Por ejemplo:
http: // nombre de host: puerto / web/. . .

Capítulo 6: Migración de aplicaciones ClassicWebSpeed

Migrate-Classic-Appserver en Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Migrate-Classic-Appserver en Es

Cargado por

Copyright:

Formatos disponibles

Migrar el servidor de aplicaciones clásico

Aplicaciones a PAS para OpenEdge

Derechos de autor................................................. .................................................. .......................... 5

Prefacio................................................. .................................................. .............................. 7

........................................ .................................................. ......... 9

Inicio rápido: mover aplicaciones clásicas de AppServer a PAS para OpenEdge

....................................... .................................................. ........ 13

Mover el código clásico de AppServer a PAS para OpenEdge .......................................... ................................. 23

Detalles importantes sobre su nuevo servidor ............................................ .................................................. 32

Próximos pasos con PAS para OpenEdge ............................................ .................................................. ........ 34

Migración de código de aplicación ABL .............................................. .................. 35

Migrar modos operativos clásicos de AppServer ............................................. ........................................... 37

Migrar el modo operativo clásico con reconocimiento de estado ........................................... .................................. 41

Migrar el modo de funcionamiento sin estado clásico ............................................. ..................................... 42

Migrar el modo de funcionamiento sin estado clásico ........................................... ...................................... 42

Procedimientos de inicio y apagado del agente multisesión .......................................... .................. 42

Activar y desactivar procedimientos .............................................. ............................................ 45

Cambios de ABL en PAS para OpenEdge ............................................ .................................................. ....... 48

Configuración del entorno en PAS para OpenEdge ............................................ ............................................. 49

Migrar conexiones de cliente a PAS para OpenEdge ........................................... ...................................... 50

Migrar URL REST ............................................... .................................................. ................. 55

OpenEdgeWeb Paper: Versión 3

Migrar la configuración y administración del servidor ................................. 57

Migrar propiedades clásicas de AppServer .............................................. .................................................. ... 60

Embalaje e instalación de la aplicación .............................................. .................................................. ..sesenta y cinco

Embalaje de distribución ................................................ .................................................. ..............sesenta y cinco

Servicios SOAP incrementales ............................................... .................................................. ...... 66

PAS para el empaquetado de instancias de OpenEdge ............................................. ........................................ 67

Proceso de instalación y actualizaciones .............................................. ................................................. 68

Ajuste de rendimiento y recursos .............................................. .................................................. ........ 70

Herramientas del proceso de desarrollo ............................................... .................................................. .... 71

Paquete de instalación y despliegue .............................................. ........................................ 71

Seguridad en el clásico AppServer versus PAS para OpenEdge .......................................... .......................... 72

Spring Security en PAS para OpenEdge ............................................ .......................................... 73

Migrar aplicaciones clásicas de WebSpeed .............................................. ..... 75

4 OpenEdgeWeb Paper: Versión

Última actualización con nuevo contenido: Lanzamiento 12

OpenEdgeWeb Paper: Versión 5

6 OpenEdgeWeb Paper: Versión

• Migración de aplicaciones clásicas de AppServer a PAS para OpenEdge

• Inicio rápido: paso a PAS para el tutorial de OpenEdge

• Referencia de migración de código de aplicación ABL

• Migrar la referencia de administración y configuración del servidor

• Migrar aplicaciones clásicas de WebSpeed

Migración de código de aplicación ABL en la página 35

Migrar la configuración y la administración del servidor en la página 57

Migrar aplicaciones clásicas de WebSpeed en la página 75

OpenEdgeWeb Paper: Versión 7

8 OpenEdgeWeb Paper: Versión

• Migración de código de aplicación ABL en la página 35

• Migrar la configuración y la administración del servidor en la página 57

• Migrar aplicaciones clásicas de WebSpeed en la página 75

OpenEdgeWeb Paper: Versión 9

Más información sobre PAS para OpenEdge

Lea sobre PAS para OpenEdge:

• Servidor de aplicaciones de progreso para la administración de OpenEdge (1000-095) curso disponible en

• Hacer una pregunta: https://community.progress.com/community_groups/openedge_development

• Descargue documentos técnicos sobre temas avanzados y otros recursos:

Para obtener más detalles, consulte los siguientes temas:

Diferencias entre AppServer clásico, WebSpeed Transaction

10 OpenEdgeWeb Paper: Versión

• Transporte APSV es para clientes ABL, clientes Java o .NET OpenClients.

• Transporte REST es para clientes REST, móviles y web existentes.