- Tener acceso a nuevas funcionalidades y aplicaciones de software que pueden ayudar a su empresa a ser competitiva y estar bien posicionada para satisfacer las demandas de un entorno empresarial en constante cambio aprovechando la última tecnología.
- Con los rigurosos requerimientos de cumplimiento normativo que deben cumplirse hoy en día, trabajar en una versión de EBS optimizada y totalmente compatible ayuda a su empresa a facilitar el cumplimiento a un costo menor al eliminar las personalizaciones obsoletas e implementar procesos estándar en toda su empresa.
- Aproveche las últimas mejoras de rendimiento y usabilidad, que permiten a su empresa aumentar la eficiencia y la utilización de sus aplicaciones de misión crítica.
- Mantener el soporte de productos, y con ello acceder a las actualizaciones de impuestos, normativas y cambios para sus aplicaciones.
Primero, resumamos las principales razones por las que debería considerar actualizar su sistema a EBS R12.2:
1. Plan de impacto en los usuarios comerciales
En este apartado revisaremos algunos de los cambios más sobresalientes que pudieran tener los usuarios durante la adopción de Oracle EBS 12.2 y el manejo de expectativas alrededor de las ventanas de mantenimiento de Online Patching.
1) Cuando se ejecuta la actualización de EBS, sus menús preexistentes se conservan.
- Para proporcionar a los usuarios una interfaz de usuario moderna…
- Asigne las pantallas HTML a los menús de usuario en lugar de Formularios.
- Para proporcionar a los usuarios paneles de navegación basados en información (dashboards)...
- Implementar centros de comando empresariales y agregar pantallas de tablero a los menús de usuario
- Para soportar procesos comerciales nuevos o mejorados y retirar personalizaciones ...
- Implemente nuevas funciones de 12.2 o nuevos módulos
- Dependiendo de los alcances y cambios, se determinará la capacitación y comunicación que requiera el usuario.
2) También, es recomendable que maneje las expectativas en torno al tiempo de inactividad de los parches en línea, mediante las siguientes aclaraciones importantes para usuarios comerciales:
· La aplicación de parches en línea no significa "zero downtime".
- Todavía hay una breve fase de transición durante la cual los usuarios están desconectados
· Algunas ocasiones, los Apps DBAs pueden combinar la transición de parcheo en línea (cutover) con otras actividades de mantenimiento que prolongan el tiempo de inactividad, por ejemplo:
- Aplicar código personalizado
- Actualización de contraseñas del sistema
- Parchear el nivel de la base de datos
· Los parches en línea no se pueden usar para parches de bases de datos y sistemas operativos
- Los usuarios seguirán experimentando un tiempo de inactividad cuando se apliquen los parches de la base de datos y el sistema operativo
En este apartado revisaremos algunos de los cambios más sobresalientes que pudieran tener los usuarios durante la adopción de Oracle EBS 12.2 y el manejo de expectativas alrededor de las ventanas de mantenimiento de Online Patching.
1) Cuando se ejecuta la actualización de EBS, sus menús preexistentes se conservan.
- Para proporcionar a los usuarios una interfaz de usuario moderna…
- Asigne las pantallas HTML a los menús de usuario en lugar de Formularios.
- Para proporcionar a los usuarios paneles de navegación basados en información (dashboards)...
- Implementar centros de comando empresariales y agregar pantallas de tablero a los menús de usuario
- Para soportar procesos comerciales nuevos o mejorados y retirar personalizaciones ...
- Implemente nuevas funciones de 12.2 o nuevos módulos
- Dependiendo de los alcances y cambios, se determinará la capacitación y comunicación que requiera el usuario.
2) También, es recomendable que maneje las expectativas en torno al tiempo de inactividad de los parches en línea, mediante las siguientes aclaraciones importantes para usuarios comerciales:
· La aplicación de parches en línea no significa "zero downtime".
- Todavía hay una breve fase de transición durante la cual los usuarios están desconectados
· Algunas ocasiones, los Apps DBAs pueden combinar la transición de parcheo en línea (cutover) con otras actividades de mantenimiento que prolongan el tiempo de inactividad, por ejemplo:
- Aplicar código personalizado
- Actualización de contraseñas del sistema
- Parchear el nivel de la base de datos
· Los parches en línea no se pueden usar para parches de bases de datos y sistemas operativos
- Los usuarios seguirán experimentando un tiempo de inactividad cuando se apliquen los parches de la base de datos y el sistema operativo
2. Plan para aprovisionar los entornos de actualización
Se debe tomar en cuenta una buena planificación de la capacidad de hardware adecuada, en la cual considere CPU, la memoria y almacenamiento necesario para la aplicación de parches en línea, y basado en las siguientes consideraciones:
- Las operaciones comerciales críticas continúan durante la aplicación de parches en línea
- Los recursos del sistema consumidos por un parche se pueden limitar
Se debe tomar en cuenta una buena planificación de la capacidad de hardware adecuada, en la cual considere CPU, la memoria y almacenamiento necesario para la aplicación de parches en línea, y basado en las siguientes consideraciones:
- Las operaciones comerciales críticas continúan durante la aplicación de parches en línea
- Los recursos del sistema consumidos por un parche se pueden limitar
- Aumentar o reducir el número de jobs de ADOP, que de forma predeterminada se calcula en función de la configuración del hardware.
- Si su entorno de producción 12.1 utiliza por completo la CPU y la memoria, es posible que necesite recursos de hardware adicionales
Capacidad de cómputo adecuado
En términos generales, puede considerar las siguientes directrices:
Directrices de dimensionamiento de niveles de aplicaciones y bases de datos
- Permita 2 GB adicionales de memoria libre para la máquina de nivel de base de datos y 3 GB adicionales de memoria libre para la máquina de nivel de aplicación para Parches en línea.
Configuración de parámetros de JVM para Java de 64 bits en la capa web de WLS
- Utilice varias instancias administradas (Managed Server). Por ejemplo, dos instancias administradas con un tamaño de 4 GB para cada una proporcionarán tiempos de respuesta mucho mejores que una JVM con un tamaño de pila total de 8 GB.
Capacidad de storage adecuado
En términos generales, puede considerar las siguientes directrices:
Base de datos
· El espacio de tabla SYSTEM necesita el doble de su asignación de espacio actual 25 GB aumenta a 50 GB
· El espacio de tabla de SEED necesita el doble de sus asignaciones de espacio actuales 5GB aumenta a 10GB
Sistema de archivos
· Dos sistemas de archivos necesitan el doble de espacio que un sistema de archivos
Nota: Es altamente recomendable que consulte la Guía de actualización de R12.2[1] para obtener instrucciones sobre estos tamaños y dimensionamiento requerido por su instancia de Oracle EBS 12.2.
Migración entre cualquier plataforma
Si realiza una actualización y una migración de plataforma, considere su enfoque
Database Tier
Application Tier
- Muchos clientes migran la capa de base de datos y en un tiempo de inactividad en un primer proyecto.
- Otros migran el nivel de base de datos en el mismo proyecto y tiempo de inactividad que la actualización R12.2
- Si migra el nivel de base de datos primero, la configuración intermedia debe estar certificada
- La elección del método de migración dependerá del tamaño de la base de datos y del orden de bytes ("endian-ness")
- Puede migrar el nivel de la aplicación mediante el proceso de actualización estándar R12.2
- Rapid Install proporciona el sistema de archivos R12.2 para su nueva plataforma de nivel de aplicación
Es importante que revise los requerimientos y prerrequisitos para realizar esta actividad en MOS Oracle E-Business Suite Upgrades and Platform Migration (Doc 1377213.1)
- Si su entorno de producción 12.1 utiliza por completo la CPU y la memoria, es posible que necesite recursos de hardware adicionales
Capacidad de cómputo adecuado
En términos generales, puede considerar las siguientes directrices:
Directrices de dimensionamiento de niveles de aplicaciones y bases de datos
- Permita 2 GB adicionales de memoria libre para la máquina de nivel de base de datos y 3 GB adicionales de memoria libre para la máquina de nivel de aplicación para Parches en línea.
Configuración de parámetros de JVM para Java de 64 bits en la capa web de WLS
- Utilice varias instancias administradas (Managed Server). Por ejemplo, dos instancias administradas con un tamaño de 4 GB para cada una proporcionarán tiempos de respuesta mucho mejores que una JVM con un tamaño de pila total de 8 GB.
Capacidad de storage adecuado
En términos generales, puede considerar las siguientes directrices:
Base de datos
· El espacio de tabla SYSTEM necesita el doble de su asignación de espacio actual 25 GB aumenta a 50 GB
· El espacio de tabla de SEED necesita el doble de sus asignaciones de espacio actuales 5GB aumenta a 10GB
Sistema de archivos
· Dos sistemas de archivos necesitan el doble de espacio que un sistema de archivos
Nota: Es altamente recomendable que consulte la Guía de actualización de R12.2[1] para obtener instrucciones sobre estos tamaños y dimensionamiento requerido por su instancia de Oracle EBS 12.2.
Migración entre cualquier plataforma
Si realiza una actualización y una migración de plataforma, considere su enfoque
Database Tier | Application Tier |
- Muchos clientes migran la capa de base de datos y en un tiempo de inactividad en un primer proyecto. - Otros migran el nivel de base de datos en el mismo proyecto y tiempo de inactividad que la actualización R12.2 - Si migra el nivel de base de datos primero, la configuración intermedia debe estar certificada - La elección del método de migración dependerá del tamaño de la base de datos y del orden de bytes ("endian-ness") | - Puede migrar el nivel de la aplicación mediante el proceso de actualización estándar R12.2 - Rapid Install proporciona el sistema de archivos R12.2 para su nueva plataforma de nivel de aplicación |
Es importante que revise los requerimientos y prerrequisitos para realizar esta actividad en MOS Oracle E-Business Suite Upgrades and Platform Migration (Doc 1377213.1)
3. Plan de impacto en los Apps DBAs
Dentro de los cambios principales que se tienen durante la operación como Apps DBA son:
1) ADOP - Nueva utilidad para organizar el parcheo en línea. Se utiliza para todos los parches de EBS para R12.2 y posteriores.
Dentro de los cambios principales que se tienen durante la operación como Apps DBA son:
1) ADOP - Nueva utilidad para organizar el parcheo en línea. Se utiliza para todos los parches de EBS para R12.2 y posteriores.
· Lo guía a través de las 5 fases de parcheo
· Controla el parcheo del sistema de archivos y la base de datos.
· Le permite aplicar varios parches en el mismo ciclo de parcheo
· Admite la ejecución automatizada de parches a través de archivos de entrada
· Se ejecuta en todos los nodos en una configuración de varios nodos.
Una capa es una agrupación lógica de servicios, distribuidos en una o más máquinas físicas. Oracle E-Business Suite consta de una arquitectura de tres capas.
· La capa Cliente/escritorio proporciona la interfaz de usuario que podría incluir computadoras de escritorio, portátiles o dispositivos móviles (como PDA). Su propósito es capturar y/o mostrar información al usuario.
· La capa de aplicación, a veces denominado capa media, es responsable de mantener la lógica de la aplicación que admite y administra los diversos componentes de las aplicaciones.
· El nivel de base de datos admite y administra la base de datos de Oracle y es responsable de almacenar y recuperar datos de la aplicación.
· La capa Cliente/escritorio proporciona la interfaz de usuario que podría incluir computadoras de escritorio, portátiles o dispositivos móviles (como PDA). Su propósito es capturar y/o mostrar información al usuario.
· La capa de aplicación, a veces denominado capa media, es responsable de mantener la lógica de la aplicación que admite y administra los diversos componentes de las aplicaciones.
· El nivel de base de datos admite y administra la base de datos de Oracle y es responsable de almacenar y recuperar datos de la aplicación.
Nota: La conexión entre el nivel de aplicación y el nivel de escritorio puede funcionar con éxito en una red de área amplia (WAN), porque los niveles de escritorio y aplicación intercambian una cantidad mínima de información, por ejemplo, diferencias de comparación de valores de campo. En una operación global que tiene usuarios en varias ubicaciones, requerir menos tráfico de red reduce los costos de telecomunicaciones y mejora los tiempos de respuesta para los usuarios.
3) WebLogic Server 11g
Este componente es parte de la capa de aplicación de EBS 12.2, sin embargo, al ser un cambio importante dentro de la arquitectura considere:
3) WebLogic Server 11g
Este componente es parte de la capa de aplicación de EBS 12.2, sin embargo, al ser un cambio importante dentro de la arquitectura considere:
· Weblogic puede ser familiar para algunos DBA/Sysadmin
· Utilizará las utilerías WebLogic Server y EBS Autoconfig para la configuración 12.2
· No asuma que el conocimiento previo es suficiente
· Revise la documentación relacionada a la gestión de la configuración del servidor HTTP de Oracle y los servicios de aplicaciones web en Oracle E-Business Suite versión 12.2 (Doc 1905593.1)
4) Considere realizar un entrenamiento previo de R12.2 Install/Patch/Maintain Oracle E-Business Suite
4) Considere realizar un entrenamiento previo de R12.2 Install/Patch/Maintain Oracle E-Business Suite
4. Plan de impacto en los desarrolladores
La preparación de customizaciones es un paso relevante y significativo cuando se habla de una actualización de Oracle E-Business Suite (EBS) a la versión 12.2.
Una cosa para considerar a lo largo de este capítulo es el hecho de que las customizaciones en 12.1 versus 12.2 son irrevocablemente diferentes. En general, las personalizaciones son extensiones o cambios en los flujos comerciales que puede implementar en los productos funcionales que forman parte de EBS.
Teniendo esto en cuenta, estas personalizaciones se pueden implementar en una o varias tecnologías y se pueden instalar en la capa media o en la base de datos, o en ambos. Cuando se habla de personalizaciones de bases de datos, estas se pueden implementar en esquemas personalizados o en esquemas de EBS, y estas podrían tener dependencias en el código de EBS.
A continuación, se muestra una descripción visual de cómo implementaría las customizaciones en EBS 12.1. En la capa de aplicación, las customizaciones viven con el código de la aplicación y en la base de datos tendría el código personalizado implementado con código de la aplicación y esquemas de la aplicación. Otra opción sería tener un esquema personalizado con código personalizado y la base de datos en un modelo de datos custom.
En la capa de aplicación, se pueden implementar personalizaciones como formularios, informes, scripts de sistema para capa de aplicación, scripts de base de datos, entre otros.
En EBS R12.2, es una historia diferente. Oracle decidió implementar una nueva función llamada Parches en línea. Esta nueva característica requiere algunos cambios a nivel arquitectónico, por lo que necesita preparar sus personalizaciones.
Antes de entrar con los detalles de las customizaciones al actualizar a Oracle EBS R12.2, recapitulemos acerca de los parches en línea. El parcheo en línea es la capacidad de parchear el sistema en ejecución sin tener que apagar el sistema durante un período de tiempo significativo mientras se aplican los parches.
La preparación de customizaciones es un paso relevante y significativo cuando se habla de una actualización de Oracle E-Business Suite (EBS) a la versión 12.2.
Una cosa para considerar a lo largo de este capítulo es el hecho de que las customizaciones en 12.1 versus 12.2 son irrevocablemente diferentes. En general, las personalizaciones son extensiones o cambios en los flujos comerciales que puede implementar en los productos funcionales que forman parte de EBS.
Teniendo esto en cuenta, estas personalizaciones se pueden implementar en una o varias tecnologías y se pueden instalar en la capa media o en la base de datos, o en ambos. Cuando se habla de personalizaciones de bases de datos, estas se pueden implementar en esquemas personalizados o en esquemas de EBS, y estas podrían tener dependencias en el código de EBS.
A continuación, se muestra una descripción visual de cómo implementaría las customizaciones en EBS 12.1. En la capa de aplicación, las customizaciones viven con el código de la aplicación y en la base de datos tendría el código personalizado implementado con código de la aplicación y esquemas de la aplicación. Otra opción sería tener un esquema personalizado con código personalizado y la base de datos en un modelo de datos custom.
En la capa de aplicación, se pueden implementar personalizaciones como formularios, informes, scripts de sistema para capa de aplicación, scripts de base de datos, entre otros.
En EBS R12.2, es una historia diferente. Oracle decidió implementar una nueva función llamada Parches en línea. Esta nueva característica requiere algunos cambios a nivel arquitectónico, por lo que necesita preparar sus personalizaciones.
Antes de entrar con los detalles de las customizaciones al actualizar a Oracle EBS R12.2, recapitulemos acerca de los parches en línea. El parcheo en línea es la capacidad de parchear el sistema en ejecución sin tener que apagar el sistema durante un período de tiempo significativo mientras se aplican los parches.
- Cuando instala o implementa en un entorno 12.2, la capa de aplicaciones tendrá dos Sistemas de Archivos (fs1 y fs2). Son dos sistemas de archivos completamente separados y aislados que contienen todo el código de la aplicación, así como el código Fusion Middleware que ejecuta este código.
- En la base de datos, como vimos en el capítulo anterior, existe la Redefinición basada en la edición (EBR) que permite a los clientes de EBS almacenar de manera eficiente múltiples copias de aplicaciones en la misma base de datos. Proporciona un mecanismo de aislamiento llamado Edición que permite que coexistan los esquemas de pre-actualización y post-actualización, y el código del cliente elige la “Edición” particular a la cual quiere conectarse.
4.1 Preparación para mover las customizaciones
Las personalizaciones en 12.2, para poder ser parcheadas en línea, deben cumplir con algunos estándares de desarrollo de parches en línea y procedimientos de parcheo[1].
Una vez que pasa a EBS 12.2, termina con una arquitectura, en la capa aplicación, tendrá dos copias completas del código de la aplicación, así como de Fusion Middleware. Su código vivirá en la aplicación en un directorio top (XXCUST_TOP por ejemplo), similar a como estaba en 12.1, pero implementado en ambos sistemas de archivos.
La función de parcheo en línea hará el trabajo para garantizar que automáticamente mantenga su código de personalización, así como el código de la aplicación, sincronizados.
Al preparar sus personalizaciones para la actualización R12.2, debe tener en cuenta que existen dos niveles de cumplimiento estándar.
Las personalizaciones en 12.2, para poder ser parcheadas en línea, deben cumplir con algunos estándares de desarrollo de parches en línea y procedimientos de parcheo[1].
Una vez que pasa a EBS 12.2, termina con una arquitectura, en la capa aplicación, tendrá dos copias completas del código de la aplicación, así como de Fusion Middleware. Su código vivirá en la aplicación en un directorio top (XXCUST_TOP por ejemplo), similar a como estaba en 12.1, pero implementado en ambos sistemas de archivos.
La función de parcheo en línea hará el trabajo para garantizar que automáticamente mantenga su código de personalización, así como el código de la aplicación, sincronizados.
Al preparar sus personalizaciones para la actualización R12.2, debe tener en cuenta que existen dos niveles de cumplimiento estándar.
- Uno es un conjunto mínimo de estándares requeridos donde el código y las customizaciones deben cumplir requisitos específicos para operar adecuadamente en Oracle EBS R12.2. Si sus personalizaciones no cumplen con estos estándares mínimos, lo más probable es que el código personalizado termine siendo marcado como no válido.
- Y la segunda opción recomendada es que sus personalizaciones sean totalmente compatibles con los Parches en línea. Si bien requiere estándares adicionales a los requisitos mínimos, puede estar seguro de que sus personalizaciones son totalmente compatibles y podrá parchear sus personalizaciones en línea sin ningún problema.
La decisión entre uno y otro se basa en la importancia de minimizar el tiempo de inactividad. En ese sentido, si está interesado en minimizar el tiempo de inactividad del mantenimiento de su aplicación, la recomendación a seguir es cumplir plenamente. Independientemente de la decisión, los parches de EBS siempre están en línea.
Una vez que se ha tomado una decisión, comienza el trabajo real. Deberá:
La decisión entre uno y otro se basa en la importancia de minimizar el tiempo de inactividad. En ese sentido, si está interesado en minimizar el tiempo de inactividad del mantenimiento de su aplicación, la recomendación a seguir es cumplir plenamente. Independientemente de la decisión, los parches de EBS siempre están en línea.
Una vez que se ha tomado una decisión, comienza el trabajo real. Deberá:
1. Cree una lista completa de todas sus customizaciones
2. Realizar un análisis para comprender el tipo de corrección de código requerida para estándares mínimos o cumplimiento total.
3. Implementar sus personalizaciones en su entorno de producción.
Nota: Este proceso requiere un alto nivel de experiencia y conocimiento de los proyectos de actualización de EBS, además de las operaciones que realiza su código personalizado. Oracle proporciona herramientas como los informes de preparación de parches en línea que señalan las infracciones para que puedan abordarse. Asegúrese de ejecutar estos informes antes de la actualización R12.2, ya que son aplicables durante la preparación de la actualización.
1) Inventario de customizaciones.
Nota: Este proceso requiere un alto nivel de experiencia y conocimiento de los proyectos de actualización de EBS, además de las operaciones que realiza su código personalizado. Oracle proporciona herramientas como los informes de preparación de parches en línea que señalan las infracciones para que puedan abordarse. Asegúrese de ejecutar estos informes antes de la actualización R12.2, ya que son aplicables durante la preparación de la actualización.
1) Inventario de customizaciones.
Catalogar las customizaciones existentes y decidir cuál actualizar, le permitirá tener una trazabilidad concreta de los posibles cambios. Puede utilizar alguna de las siguientes herramientas sugeridas:
- Los integradores de sistemas (como FIT Consulting) generalmente tienen servicios y herramientas para inventariar CEMLI (Configuraciones, extensiones, modificaciones, localizaciones e integraciones) y en algunos casos incluyen identificación CEMLI, documentación, mejoras y reparaciones.
- El equipo de Advanced Customer Services (ACS) de Oracle puede brindar asistencia. El servicio de gestión CEMLI de ACS incluye identificación CEMLI, documentación, mejoras y reparaciones durante la ejecución.
- Oracle ofrece un producto que informa sobre las personalizaciones de EBS Oracle Application Management Suite para Oracle E-Business Suite
- Simplifique su proyecto retirando las personalizaciones que ya no son necesarias
- Considere reemplazar las personalizaciones con la funcionalidad estándar de EBS 12.2
2) Revisar informes personalizados
Considere retirar o actualizar con enfoques técnicos más recientes:
Para informes de Oracle o informes de Oracle Discoverer como estos:
Considere actualizar de esta manera:
Documentos externos, por ejemplo, orden de compra, factura, informe legal o de cumplimiento.
Mover a Oracle BI Publisher
Listado de informes utilizados como referencia interna, p. Ej., Lista de piezas
Mover a Oracle BI Publisher
Informes operativos identificados como siguientes pasos …
Reemplazar con EBS Enterprise Command Centers
3) Remediar personalizaciones
a) Una vez que ya tenga el inventario de sus customizaciones, aproveche estos recursos de información proporcionados por Oracle para remediar y ajustar al nuevo modelo de Oracle EBS 12.2.
· Modelo de datos 12.2.x e informes de comparación de archivos
- Informe de comparación del modelo de datos de EBS (Doc 1290886.1)
- Informe de comparación de archivos EBS (Doc 1446430.1)
· Nuevos estándares de interfaz de usuario 12.2 para páginas basadas en OA Framework
- Consideraciones de actualización de Oracle E-Business Suite versión 12.2 para aplicaciones basadas en OA Framework y Oracle CRM Technology Foundation (Doc 1927975.1)
· Nuevos estándares de desarrollo 12.2 para compatibilidad con parches en línea
- Desarrollo e implementación de personalizaciones en Oracle E-Business Suite versión 12.2 (Doc 1577661.1)
- Guía para desarrolladores de Oracle E-Business Suite, versión 12.2
b) Dentro de los nuevos estándares de desarrollo 12.2 para código personalizado, debe decidir a qué nivel de cumplimiento de normas apuntar:
Mínimo
Completo
Se debe cumplir un conjunto mínimo requerido de estándares para que el código personalizado se ejecute correctamente en 12.2
Opcional, se deben cumplir estándares adicionales para que el código personalizado se instalado como un parche en línea
- La decisión se basa en la importancia de minimizar el tiempo de inactividad.
- En cualquier caso, los parches de EBS siempre se aplican en línea.
c) Por supuesto debe asegurarse que todo el código personalizado cumple totalmente con los estándares 12.2 y debe tener coherencia con la nueva vista lógica del modelo de datos, esto es:
- Todo código debe acceder al modelo de datos a través del sinónimo APPS
- El sinónimo de APPS apunta a la vista de edición (modelo lógico)
- Cualquier código que acceda al modelo físico corre el riesgo de acceder a columnas obsoletas.
- Los integradores de sistemas (como FIT Consulting) generalmente tienen servicios y herramientas para inventariar CEMLI (Configuraciones, extensiones, modificaciones, localizaciones e integraciones) y en algunos casos incluyen identificación CEMLI, documentación, mejoras y reparaciones.
- El equipo de Advanced Customer Services (ACS) de Oracle puede brindar asistencia. El servicio de gestión CEMLI de ACS incluye identificación CEMLI, documentación, mejoras y reparaciones durante la ejecución.
- Oracle ofrece un producto que informa sobre las personalizaciones de EBS Oracle Application Management Suite para Oracle E-Business Suite
- Simplifique su proyecto retirando las personalizaciones que ya no son necesarias
- Considere reemplazar las personalizaciones con la funcionalidad estándar de EBS 12.2
2) Revisar informes personalizados
Considere retirar o actualizar con enfoques técnicos más recientes:
Para informes de Oracle o informes de Oracle Discoverer como estos: | Considere actualizar de esta manera: |
Documentos externos, por ejemplo, orden de compra, factura, informe legal o de cumplimiento. | Mover a Oracle BI Publisher |
Listado de informes utilizados como referencia interna, p. Ej., Lista de piezas | Mover a Oracle BI Publisher |
Informes operativos identificados como siguientes pasos … | Reemplazar con EBS Enterprise Command Centers |
3) Remediar personalizaciones
a) Una vez que ya tenga el inventario de sus customizaciones, aproveche estos recursos de información proporcionados por Oracle para remediar y ajustar al nuevo modelo de Oracle EBS 12.2.
· Modelo de datos 12.2.x e informes de comparación de archivos
- Informe de comparación del modelo de datos de EBS (Doc 1290886.1)
- Informe de comparación de archivos EBS (Doc 1446430.1)
· Nuevos estándares de interfaz de usuario 12.2 para páginas basadas en OA Framework
- Consideraciones de actualización de Oracle E-Business Suite versión 12.2 para aplicaciones basadas en OA Framework y Oracle CRM Technology Foundation (Doc 1927975.1)
· Nuevos estándares de desarrollo 12.2 para compatibilidad con parches en línea
- Desarrollo e implementación de personalizaciones en Oracle E-Business Suite versión 12.2 (Doc 1577661.1)
- Guía para desarrolladores de Oracle E-Business Suite, versión 12.2
b) Dentro de los nuevos estándares de desarrollo 12.2 para código personalizado, debe decidir a qué nivel de cumplimiento de normas apuntar:
Mínimo | Completo |
Se debe cumplir un conjunto mínimo requerido de estándares para que el código personalizado se ejecute correctamente en 12.2 | Opcional, se deben cumplir estándares adicionales para que el código personalizado se instalado como un parche en línea |
- La decisión se basa en la importancia de minimizar el tiempo de inactividad.
- En cualquier caso, los parches de EBS siempre se aplican en línea.
c) Por supuesto debe asegurarse que todo el código personalizado cumple totalmente con los estándares 12.2 y debe tener coherencia con la nueva vista lógica del modelo de datos, esto es:
- Todo código debe acceder al modelo de datos a través del sinónimo APPS
- El sinónimo de APPS apunta a la vista de edición (modelo lógico)
- Cualquier código que acceda al modelo físico corre el riesgo de acceder a columnas obsoletas.
d) Es importante la ejecución de los informes proporcionados por Oracle que verifican el cumplimiento de los estándares, por supuesto le ayudaran a identificar las infracciones de los estándares 12.2 y las soluciones recomendadas.
Using the Online Patching Readiness Report in Oracle E-Business Suite Release 12.2 (Doc 1531121.1)
Using the Online Patching Readiness Report in Oracle E-Business Suite Release 12.2 (Doc 1531121.1)
Sugerencias finales
Descargue el libro electrónico completo con el que lograra:
- Planificar adecuadamente la actualización a través de 10 consideraciones clave
- Evitar el riesgo, el estrés y las largas horas con el manejo de sus customizaciones
- Reducir costos, incrementar la escalabilidad y simplificar su trabajo, revisando las etapas del proceso técnico de actualización