Compruebe la preparación para la actualización y corrija los problemas de comprobación previa

Oracle realiza periódicamente algunas comprobaciones previas para determinar la preparación del cambio de versión para que el cambio de versión se ejecute sin problemas. Si las comprobaciones previas no se superan, es posible que deba realizar tareas para corregir los problemas.

Después de corregir cualquier problema de comprobación previa, configure la configuración de cambio de versión.

Ver el estado de la comprobación previa

Para ver el estado de la comprobación previa o volver a ejecutar la comprobación, realice los siguientes pasos:

  1. En el panel de navegación, haga clic en Configuración y, a continuación, en Cambio de versión.

    Puede ver cuándo finalizó la última comprobación previa sobre la tabla de comprobación de preparación.

    La tabla de comprobación de preparación muestra la siguiente información sobre el estado de los elementos de comprobación previa.

    Columna Descripción
    Condición de elegibilidad Condición que se debe cumplir para estar listo para la actualización. Algunas condiciones incluyen enlaces a la documentación asociada.
    Responsable Quien es responsable de manejar la condición.
    Fecha de Vencimiento Fecha en la que se debe cumplir la condición.
    Estado de elegibilidad Estado de la condición, incluidas las explicaciones de las condiciones que no se han cumplido. Amplíe Más detalles... para ver información adicional sobre el fallo de la condición. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.
  2. Si hay comprobaciones previas que no se aprobaron, realice las tareas asociadas para corregir los problemas.
  3. Para volver a ejecutar la comprobación previa, haga clic en Volver a marcar.

    La comprobación previa tarda aproximadamente una hora en completarse.

Nota

Si Oracle ha intentado cambiar la versión de la instancia, verá los detalles de ese intento en Resumen de cambio de versión directamente debajo de la tabla de comprobación de preparación.

Comprobaciones previas del agente de conectividad

Condición de elegibilidad Responsable típico Aplicable a la región gubernamental Tareas que completar

Versión de agente Java

Equipo de operaciones de desarrollo Asegúrese de que los agentes de conectividad utilizan JDK 17 y PKCS12 KeyStore. Amplíe Más detalles para ver los agentes de conectividad que necesitan revisión. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar. También puede ver la sección Estado de agente de conectividad para ver el estado de todos los agentes de conectividad de la instancia.
  1. Para cualquier agente de conectividad que no utilice JDK 17, instale JDK 17 en el servidor que aloja el agente.
  2. Para cualquier agente que siga utilizando JKS KeyStore, convierta KeyStore en PKCS12 KeyStore. Puede realizar la conversión de dos formas:
    • Automáticamente, durante el cambio de versión: su JKS KeyStore se convertirá automáticamente a PKCS12 KeyStore durante el cambio de versión.
    • Manualmente, antes de la actualización: puede convertir el JKS KeyStore a PKCS12 KeyStore manualmente, antes de la actualización, siguiendo los pasos a continuación.
    Nota

    La conversión de JKS KeyStore a PKCS12 KeyStore no afecta al agente de conectividad de Oracle Integration Generation 2 y solo se aplica después de actualizar a Oracle Integration 3.

    Si desea convertir manualmente JKS KeyStore a PKCS12 KeyStore, complete los siguientes pasos antes de la actualización. Estas tareas requieren que detenga brevemente y, a continuación, reinicie el agente de conectividad, por lo que debe elegir una hora en la que no se esté utilizando el agente de conectividad.

    1. En el servidor que aloja el agente de conectividad, cree una copia de seguridad del archivo keystore.jks, que se encuentra en la siguiente carpeta:

      Agent_Install_Location/agenthome/agent/cert

    2. Mueva el archivo de copia de seguridad a una carpeta diferente.
    3. Convierta JKS KeyStore en PKCS12 KeyStore ejecutando el siguiente comando desde la línea de comandos:

      keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype JKS -deststoretype PKCS12 -deststorepass changeit -srcstorepass changeit

    4. Pare el agente de conectividad.
    5. Suprima el archivo keystore.jks en la siguiente ubicación:

      Agent_Install_Location/agenthome/agent/cert

    6. Inicie el agente de conectividad.

Conectividad de agente para Oracle Integration 3: el agente de conectividad debe estar en ejecución

Equipo de operaciones de desarrollo El agente de conectividad debe estar activo y en ejecución antes de que comience la actualización. Amplíe Más detalles para ver los agentes de conectividad que necesitan revisión. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar. También puede ver la columna Estado de agente en la sección Estado de agente de conectividad para ver el estado de todos los agentes de conectividad de la instancia, indicando si cada agente está fuera de línea (no disponible).

Los agentes a los que no se puede acceder durante el cambio de versión o que no cumplen los requisitos de cambio de versión no se actualizarán, en cuyo caso deberá realizar pasos posteriores al cambio de versión para recuperar la conectividad.

Conectividad de agente para Oracle Integration 3: actualice la configuración de la lista de permitidos

Equipo de operaciones de desarrollo Debe actualizar la configuración de la lista de permitidos para los agentes de conectividad antes de la actualización. Amplíe Más detalles para ver los agentes de conectividad que necesitan revisión. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar. También puede ver la columna Estado de lista de permitidos en la sección Estado de agente de conectividad para ver el estado de todos los agentes de conectividad de la instancia, indicando si la lista de permitidos se ha actualizado correctamente.

A medida que se acerca la ventana de actualización, realice las siguientes tareas previas al cambio de versión:

  • Agregue la dirección IP de Oracle Cloud Infrastructure Identity and Access Management (IAM) a la lista de permitidos.
  • Agregue las direcciones IP de tiempo de diseño y de tiempo de ejecución para Oracle Integration a la lista de permitidos.
  • Defina la propiedad Cache del servidor proxy para las URL de Oracle Integration para que se refresquen con la mayor frecuencia posible.

Los agentes a los que no se puede acceder durante el cambio de versión o que no cumplen los requisitos de cambio de versión no se actualizarán, en cuyo caso deberá realizar pasos posteriores al cambio de versión para recuperar la conectividad.

Identificador AgentGroup no soportado

Equipo de operaciones de desarrollo Si alguno de los grupos de agentes tiene un espacio en sus identificadores, no se migrará a Oracle Integration 3. Si aún necesita los grupos de agentes, deberá volver a crearlos después de la actualización.

Comprobaciones previas de instancia

Condición de elegibilidad Propietario típico Aplicable a la región gubernamental Tareas que Terminar

URL de punto final personalizado

Administrador En función de cómo se configure el punto final personalizado antes de la migración, realizará diferentes pasos y el proceso de cambio de versión gestionará el punto final personalizado de forma diferente. Amplíe Más detalles para determinar cómo continuar con el cambio de versión.
Diagrama de flujo, descrito en texto

  • Si utiliza Visual Builder:
    1. Para continuar con el cambio de versión, complete las tareas previas al cambio de versión de Visual Builder.
    2. Durante el cambio de versión, el proceso de cambio de versión configura el punto final personalizado y cualquier punto final personalizado alternativo en Visual Builder.
  • Si no utiliza Visual Builder y tiene puntos finales personalizados alternativos, suprímalos de la instancia de Oracle Integration Generation 2. Oracle Integration 3 no soporta actualmente puntos finales personalizados alternativos.
  • Si no utiliza Visual Builder y el punto final personalizado utiliza SSL:
    1. Para continuar con el cambio de versión, configure un equilibrador de carga frente a la instancia de Oracle Integration Generation 2 y elimine el certificado SSL.
    2. Durante el cambio de versión, el proceso de cambio de versión configura el punto final personalizado en Oracle Integration 3.
    3. Después del cambio de versión, el acceso en tiempo de ejecución a las integraciones seguirá funcionando como lo hizo para Oracle Integration Generation 2. Para todos los demás puntos de acceso, como el tiempo de diseño y la automatización de procesos, sigue accediendo al punto final personalizado, pero el punto final personalizado se redirige a la URL adecuada.
  • Si no se aplica ninguna de estas situaciones y se transfiere esta comprobación previa, el proceso de cambio de versión configura el punto final personalizado en Oracle Integration 3, y el punto final personalizado funcionará como se describe en el punto anterior para el escenario SSL.

Acción de ID de instancia

Administrador El ID de instancia generado por el sistema que se muestra en la página Instancias y en el flujo de actividad de una instancia de integración ha cambiado de un valor numérico a un valor alfanumérico en Oracle Integration 3. El tipo de dato del valor no cambia; sigue siendo un tipo de dato de cadena. El cambio a un valor alfanumérico puede afectar a cualquier sistema que utilice que se base en que el ID de instancia sea un valor numérico. Por ejemplo, si analiza el identificador de instancia de una API de REST y almacena el identificador de instancia en una base de datos como un campo numérico, deberá actualizar el campo de la base de datos. Puede elegir mantener el ID de instancia como numérico al configurar los valores de cambio de versión. Consulte FlowId Soporte de conversión.

Si tiene integraciones que utilizan ID de instancia, la comprobación previa muestra una advertencia. Amplíe Más detalles para ver las integraciones que necesitan revisión. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Nota: esta comprobación previa solo comprueba la existencia de integraciones que utilizan ID de instancia, no la precisión de los ID de instancia. La advertencia permanecerá después de actualizar las integraciones, pero no afectará al cambio de versión.

Límite de correo electrónico diario

Administrador Oracle Integration 3 puede enviar un límite de 10 000 correos electrónicos en una ventana móvil de 24 horas, como se describe en Límites de servicio. Si su despliegue necesita enviar más que eso, puede utilizar su arrendamiento de cliente. Consulte Configuración de correos electrónicos de notificación.

Ámbitos personalizados en IDCS

Administrador No Oracle Integration 3 agrega un ámbito por defecto (/ic/api/ , urn:opc:resource:consumer::all) a Oracle Identity Cloud Service (IDCS) cuando se crea la instancia. No soporta ningún otro ámbito personalizado agregado a IDCS. Si ha creado ámbitos personalizados en IDCS, debe eliminarlos.

Otros Fallos

Varía Si hay otros problemas que bloquearán la actualización que no tengan comprobaciones previas específicas, se incluirán en otros fallos. Amplíe Más detalles para ver las incidencias que necesitan acción. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

B2B para comprobaciones previas de Oracle Integration

Condición de elegibilidad Propietario típico Aplicable a la región gubernamental Tareas que Terminar

B2B Período de retención

Administrador No Aunque no es necesario hacer nada para corregir este estado de comprobación previa, tenga en cuenta que las ediciones Standard y Enterprise de Oracle Integration 3 soportan 32 días de retención de datos por defecto. Durante el cambio de versión, solo se migrarán los últimos 32 días de datos retenidos. Amplíe Más detalles para ver cuántos días de datos retenidos tiene actualmente. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Después del cambio de versión a Oracle Integration 3, podrá aumentar el período de retención de datos si lo desea o actualizar a la edición Healthcare, que admite 184 días de retención de datos.

Comprobaciones previas de integraciones

Condición de elegibilidad Propietario típico Aplicable a la región gubernamental Tareas que Terminar

Respuesta retardada (asíncrona)

Equipo de desarrollo El patrón de respuesta retrasada (asíncrona) se admitía anteriormente en los siguientes adaptadores:
  • Adaptador de Oracle CX Sales y B2B Service
  • Adaptador de Oracle ERP Cloud
  • Adaptador de Oracle HCM Cloud
  • Adaptador de Oracle Field Service Cloud
  • Adaptador de Salesforce
  • Adaptador de ServiceNow
Si tiene integraciones que utilizan una respuesta retrasada (asíncrona) con uno de estos adaptadores, vuelva a trabajar mediante la creación de dos conexiones de llamada para lograr una funcionalidad similar:
  1. Cree una llamada simple para las devoluciones de llamada correctas.
  2. Cree una llamada adicional para las devoluciones de llamada con fallos en el manejador de fallos para detectar el fallo correcto.

Amplíe Más detalles para ver qué integraciones necesitan revisión. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Certificados de identidad

Equipo de desarrollo Los certificados de identidad establecen la identidad del cliente durante la comunicación SSL bidireccional. Las conexiones basadas en el adaptador AS2 y el adaptador REST pueden utilizar certificados de identidad.

Amplíe Más detalles para ver los nombres de los certificados de identidad y las conexiones que los utilizan. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Si tiene certificados de identidad, después de la actualización, deberá cargar nuevos certificados de identidad como se describe en Garantía de conectividad:

Nombre de aplicación duplicado de enrutamiento básico

Equipo de desarrollo Si la instancia contiene integraciones de enrutamiento básicas que tienen los mismos nombres de punto final de origen y destino, realice los siguientes pasos:
  1. Edite la integración de enrutamiento básica, suprima el punto final de destino y vuelva a agregarlo con un nombre diferente.
  2. Guarde la integración.

Amplíe Más detalles para ver las integraciones que necesitan revisión. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Lectura de varios archivos

Equipo de desarrollo La operación Leer varios archivos quedó en desuso en Oracle Integration Generation 2.

Si tiene integraciones que incluyen una operación para leer varios archivos, vuelva a trabajar las integraciones para que no utilicen este patrón. Por ejemplo, utilice una operación listFile para mostrar los archivos y utilice una acción for-each para leer cada archivo individualmente. Amplíe Más detalles para ver las integraciones que necesitan revisión. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Integraciones de publicación/suscripción

Equipo de desarrollo

Si la instancia incluye integraciones que publican mensajes o se suscriben a mensajes de Oracle Integration, tenga en cuenta que las integraciones de publicación/suscripción (o publicación/suscripción) deben convertirse en orquestaciones controladas por eventos. Las integraciones se gestionarán de forma diferente en función de su configuración:

  • Las integraciones de publicación/suscripción que utilizan anexos no se pueden convertir automáticamente en este momento. Si desea continuar con el cambio de versión, puede eliminar estas integraciones o ignorar los fallos de comprobación previa. Después de la actualización, puede volver a crearlos, transfiriendo la asociación al servidor FTP o al almacenamiento de objetos de su arrendamiento y transfiriendo la referencia al flujo de suscriptor. Consulte Definición de filtrado de suscripción basado en cabecera en Uso de integraciones en Oracle Integration 3.
  • Todas las demás integraciones de pub/sub activas se convierten automáticamente durante la actualización. Las integraciones de publicación/suscripción en estado borrador no se pueden migrar y estarán en blanco después de la actualización.
  • Si ha asignado datos en el flujo de suscriptor, las asignaciones se convierten con la mayor precisión posible. Sin embargo, después de la actualización, debe revisar las asignaciones y corregirlas si es necesario.
  • Si ve el error Solo están presentes los suscriptores, no hay editores, tiene suscriptores huérfanos que se deben suprimir antes de la actualización.

Amplíe Más detalles para ver las integraciones que no se pueden convertir automáticamente. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Nota: puede que desee aprovechar esta oportunidad para suprimir cualquier flujo de publicación de borrador.

Autenticación básica de API de transferencia de demanda en la acción OAuth

Equipo de desarrollo Si su instancia incluye integraciones que acceden a las API incorporadas de DT (tiempo de diseño) mediante una conexión REST con autenticación básica, debe cambiarlas para utilizar OAuth.

En Oracle Integration Generation 2, puede utilizar la autenticación básica para utilizar la API REST de Oracle Integration y la API REST del servidor de archivos. En Oracle Integration 3, debe utilizar OAuth. Debe actualizar los clientes, scripts, integraciones y comandos que utilizan la API de REST de Oracle Integration o la API de REST del servidor de archivos para conectarse mediante OAuth. Para obtener más información sobre el soporte de métodos de autenticación, consulte Cuándo se soporta la autenticación básica en Oracle Integration 3. Para obtener más información sobre el uso de OAuth con la API de REST de Oracle Integration, consulte Seguridad, autenticación y autorización o con la API de REST del servidor de archivos, consulte Seguridad, autenticación y autorización.

Comprobaciones previas de adaptadores

Condición de elegibilidad Propietario típico Aplicable a la región gubernamental Tareas que Terminar

Adaptadores Personalizados

Equipo de desarrollo No Si su instancia incluye integraciones que utilizan un adaptador personalizado, la instancia aún no se puede actualizar. Espere hasta que Oracle inicie los cambios de versión de esta función. Amplíe Más detalles para ver los adaptadores personalizados que está utilizando. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Adaptador de Oracle Utilities

Equipo de desarrollo Swagger 2.0 ya no se admite en el adaptador de Oracle Utilities. Si hay alguna integración existente mediante el catálogo REST de Swagger 2.0, el tiempo de ejecución no se verá afectado. Sin embargo, si intenta editar la conexión en tiempo de diseño, volver a probar la conexión, refrescar los metadatos, refrescar los artefactos o reactivar, la integración falla. Debe actualizar el catálogo para utilizar la definición OpenAPI 3.x. Amplíe Más detalles para ver las integraciones que necesitan revisión. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar. Consulte Uso del catálogo REST de Swagger 2.0 con Oracle Utilities Adapter versión 24.04.0 o superior.

Adaptadores no admitidos

Equipo de desarrollo Si la instancia incluye una integración que utiliza uno de los siguientes adaptadores, los cuales no están soportados en Oracle Integration 3, sustituya los adaptadores por el adaptador REST:
  • Adaptador de Automation Anywhere
  • Adaptador de Evernote
  • Adaptador de Oracle Messaging Cloud Service
  • Adaptador de Oracle Monetization Cloud
  • Adaptador de Oracle Taleo Business Edition (TBE)
  • Adaptador de Robotic Process Automation de UiPath

    Nota: Las capacidades de automatización robótica de procesos (RPA) están disponibles en Oracle Integration 3. Consulte Learn About Robots y Build a Robot in Using Robots in Oracle Integration 3.

Amplíe Más detalles para ver qué adaptadores no soportados está utilizando. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Tipos de REST no soportados

Equipo de desarrollo Los siguientes tipos de conexión están en desuso y no están soportados en una conexión de adaptador de REST. Sustituya estos tipos de conexión por diferentes tipos de conexión. Consulte Configure Connection Properties for Invoke Connections en Using the REST Adapter with Oracle Integration 3.
  • URL del catálogo de metadatos
  • URL de definición de Swagger
  • URL de definición de RAML

Amplíe Más detalles para ver qué tipos de REST no soportados está utilizando. Para copiar los detalles en el portapapeles, haga clic en Icono Copiar.

Los desarrolladores con una API de REST que se describe mediante RAML o el catálogo de metadatos de Oracle deben realizar las siguientes acciones:
  1. Consulte al proveedor de servicios REST y solicite una definición de Swagger (si está disponible). Oracle Fusion Applications debe tener una opción de Swagger disponible. Esta es una directriz para todas las aplicaciones de Oracle Fusion Applications.
  2. Si no hay una especificación alternativa disponible, utilice la plantilla básica del adaptador de REST seleccionando URL base de API de REST como URL de conexión y definiendo la solicitud de API de destino mediante el asistente de configuración de punto final del adaptador.

Otra opción es convertir RAML en una especificación OpenAPI para utilizarla con la conexión del adaptador REST.

Para proporcionar un soporte más sólido y completo para las especificaciones de Swagger/OpenAPI, el adaptador de REST incluye una opción unificada para especificar todas las especificaciones de OpenAPI en un solo campo. Esta opción también sustituye a la opción para proporcionar una URL de definición de Swagger, que ya no está disponible.

Comprobaciones previas de Visual Builder

Condición de elegibilidad Propietario típico Aplicable a la región gubernamental Tareas que Terminar

URL de punto final personalizado

Administrador No Esto también se ha tratado en Comprobaciones previas de instancia, pero se repite aquí, ya que se aplica a Visual Builder.

Si tiene un punto final personalizado y está utilizando Visual Builder:

  1. Para continuar con el cambio de versión, complete las tareas previas al cambio de versión de Visual Builder.
  2. Durante el cambio de versión, el proceso de cambio de versión configura el punto final personalizado y cualquier punto final personalizado alternativo en Visual Builder.

VBCS

Administrador No Si utiliza Visual Builder con su propia instancia de base de datos Oracle (BYODB), Autonomous Transaction Processing (ATP) debe estar activo y en ejecución durante el cambio de versión.

Asegúrese de completar las tareas adicionales descritas en Preparación de Visual Builder para el cambio de versión en Administración de Oracle Visual Builder en Oracle Integration 3.

Comprobación previa de Process Automation

Condición de elegibilidad Propietario típico Aplicable a la región gubernamental Tareas que Terminar

Proceso de automatización

Administrador No

Hay varias diferencias entre Process en Oracle Integration Generation 2 y Process Automation en Oracle Integration 3. Consulte Preguntas frecuentes sobre el proceso.

En función de cómo utilice Process en Oracle Integration Generation 2, utilizará una opción diferente para actualizar o migrar. Consulte Opciones de cambio de versión de proceso.

Acción de Proceso

Administrador No

Si utiliza la acción Procesar en cualquier integración, deberá reemplazar o eliminar la acción Procesar antes de actualizar. Utilice el método descrito en la opción de actualización de proceso que se aplica a su situación.

Corrección de una instancia con comprobaciones de preparación fallidas

Si la actualización se ha programado y la instancia ya no está lista para la actualización, solucione los resultados para que la actualización se complete correctamente.

  1. En Oracle Integration, abra la página Cambio de versión mediante uno de los siguientes pasos:
    • En el panel de navegación, haga clic en Configuración y, a continuación, en Cambio de versión.
    • Haga clic en Anuncios icono Anuncios y, a continuación, en el enlace de la notificación.
    Aparecerá la página Cambio de versión.

    En la captura de pantalla se muestra la página Actualizar con un mensaje que indica que la comprobación de preparación ha fallado, seguida de una lista de condiciones de elegibilidad y su estado. Hay un botón Comprobar de nuevo para volver a ejecutar la comprobación de preparación.

  2. Revise las condiciones que no se aprobaron y realice la acción adecuada. Consulte Comprobación de la preparación del cambio de versión y corrección de problemas de comprobación previa para conocer los pasos que se deben realizar.
  3. Después de abordar todos los problemas, vuelva a comprobar la instancia.
    1. Haga clic en Volver a comprobar.
      El cheque tarda aproximadamente una hora en completarse. Puede ver cuándo finalizó la última comprobación sobre la tabla de comprobación de preparación.
    2. Continúe realizando correcciones hasta que se supere la comprobación.
      Si no está seguro de cómo corregir una incidencia, introduzca una solicitud de servicio (SR) en My Oracle Support.