Editar

Compartir a través de

Implementación de IBM Sterling Order Management en Azure

Azure Database for PostgreSQL
Archivos de Azure
Red Hat OpenShift en Azure
Azure Virtual Machines
Azure Virtual Network

Esta arquitectura ilustra una implementación de un entorno de Sterling Order Management Software (OMS) en Azure. En este artículo, no se detalla cómo instalar Sterling OMS. Para obtener más información sobre el proceso de instalación, consulte Instalación de Sterling Order Management Software.

Los logotipos de Red Hat son marcas comerciales de Red Hat, Inc. El uso de estas marcas no implica ninguna aprobación. Apache® y Apache ActiveMQ son marcas comerciales registradas o marcas comerciales de Apache Software Foundation en los Estados Unidos u otros países. El uso de estas marcas no implica la aprobación de Apache Software Foundation.

Architecture

Diagrama de arquitectura que muestra los componentes y servicios que dan soporte a la implementación de un sistema de administración de pedidos IBM Sterling OMS en Azure.

Descargue un archivo Visio de esta arquitectura.

Puede implementar una carga de trabajo para que esté orientada interna o externamente. Utilice la configuración que mejor se adapte a sus requisitos.

Flujo de trabajo

La arquitectura cumple los requisitos de infraestructura de las siguientes maneras:

  • Se utiliza una plataforma de hospedaje de contenedores para implementar cargas de trabajo de alta disponibilidad en zonas de disponibilidad. Se recomienda Red Hat OpenShift en Azure.
  • Un servicio de base de datos totalmente administrado funciona como la base de datos back-end para el sistema OMS. Sterling OMS admite actualmente IBM Db2, Oracle Database y PostgreSQL. Se recomienda Azure Database for PostgreSQL con la opción de servidor flexible.
  • Una configuración escalable y de alta disponibilidad proporciona un entorno para ejecutar un agente de mensajes como IBM MQ, que es compatible con la API de Java Message Service (JMS). El diagrama no incluye esta configuración. En función de sus requisitos, puede estar dentro del clúster o externo al clúster.
  • Los puntos de conexión privados aíslan y ayudan a proteger el tráfico de red a todos los servicios conectados.
  • Se usan máquinas virtuales de Azure adicionales y opcionales con fines de administración y desarrollo.
  • Los recursos compartidos de Azure Files Premium y Estándar proporcionan almacenamiento para los archivos de registro y otros datos de configuración de la aplicación.

Componentes

  • Red Hat OpenShift en Azure proporciona clústeres de OpenShift de alta disponibilidad y totalmente administrados a petición. Microsoft y Red Hat supervisan y operan conjuntamente estos clústeres.

  • Azure Virtual Network es el bloque de creación fundamental para las redes privadas en Azure. Se utilizan redes virtuales para la comunicación entre los nodos, los servicios de Azure y las necesidades de conectividad híbrida.

  • Azure Files proporciona recursos compartidos de archivos totalmente administrados en la nube que son accesibles mediante los protocolos SMB y NFS. En esta solución, Azure Files hospeda los datos con estado de las bases de datos y los sistemas que están dentro del clúster.

  • Azure Bastion es un servicio totalmente administrado que proporciona acceso RDP y SSH con seguridad mejorada y sin problemas a las máquinas virtuales sin ninguna exposición mediante direcciones IP públicas. En esta solución, Azure Bastion es opcional. Puede usar Azure Bastion y una subred para proporcionar acceso con seguridad mejorada a cualquiera de los nodos de trabajo o a las máquinas JumpBox opcionales.

  • Azure Database for PostgreSQL es un servicio de base de datos relacional totalmente administrado basado en el motor de base de datos de PostgreSQL. Azure Database for PostgreSQL ofrece un rendimiento predecible y escalabilidad dinámica, y es adecuado para cargas de trabajo críticas para la empresa. Su modelo de implementación de servidor flexible proporciona un control pormenorizado y flexibilidad sobre las opciones de configuración y las funciones de administración de la base de datos.

  • Azure Virtual Machines es una oferta de infraestructura como servicio (IaaS). Puede usar máquinas virtuales para implementar recursos informáticos escalables a petición. Esta solución usa máquinas virtuales Linux en Azure para proporcionar un jumpbox para la administración de los recursos y servicios basados en Azure de OMS.

Alternativas

Si tiene conectividad de red con el entorno de Azure, puede realizar la instalación desde una máquina existente en lugar de usar una máquina Linux de Azure.

Normalmente, los siguientes servicios no son necesarios, pero son alternativas eficaces:

  • IBM Db2 en Azure es una alternativa opcional al modelo de servidor flexible de Azure Database for PostgreSQL. Si ejecuta IBM Db2 en máquinas virtuales, familiarícese con el uso de Azure Load Balancer y el software de agrupación en clústeres de Pacemaker para lograr una alta disponibilidad para los servidores de bases de datos.
  • Azure NetApp Files admite cualquier tipo de carga de trabajo proporcionando alta disponibilidad y alto rendimiento. Azure NetApp Files es ideal para cargas de trabajo sensibles a la E/S, como las cargas de trabajo de IBM Db2 que se ejecutan en máquinas virtuales de Azure.
  • Oracle Database en Azure es una alternativa opcional al modelo de servidor flexible de Azure Database for PostgreSQL.

Detalles del escenario

IBM Sterling OMS es un sistema de administración de pedidos que ofrece una plataforma completa de suministro de pedidos para todos los canales. Este sistema incluye características como:

  • Visibilidad y demanda del inventario en tiempo real.
  • Orquestación y flujos de trabajo de pedidos totalmente configurables.
  • Logística inversa para las devoluciones multicanal y el estado de los pedidos de devolución.

Una asociación entre Microsoft y el equipo de IBM Sterling OMS garantiza que esta solución esté configurada para ejecutarse de forma óptima en Azure. En este artículo, se proporciona un diseño para ejecutar Sterling OMS 10.0 y versiones posteriores en Azure para los clientes que tienen soporte técnico de IBM y un asociado para la instalación. Para obtener respuestas a preguntas específicas del producto, póngase en contacto con el equipo de IBM.

Posibles casos de uso

Muchas industrias y sectores usan soluciones de OMS, entre las que se incluyen:

  • Retail
  • Comercio electrónico
  • Fabricación

Para ver más casos de uso de OMS, consulte IBM Sterling Order Management.

Recomendaciones

Esta guía admite Sterling OMS 10.0 Q3 2022 y versiones posteriores. Estas versiones proporcionan las mejores opciones de integración con Azure porque admiten PostgreSQL y la plataforma de contenedores Red Hat OpenShift en Azure. Antes de crear su propia implementación, use la Guía de inicio rápido: Sterling Order Management en Azure para implementar Sterling OMS. Cuando comprenda cómo funcionan la implementación y la configuración, podrá determinar con más rapidez los requisitos de diseño de la implementación.

Microsoft trabaja estrechamente con IBM y otros asociados para asegurarnos de que la guía de instrucciones, la arquitectura y la guía de inicio rápido le proporcionen la mejor experiencia en Azure. Estos recursos siguen los procedimientos recomendados, como se describe en el Marco de buena arquitectura de Microsoft Azure. Póngase en contacto con el equipo de la cuenta de IBM para obtener soporte técnico más allá de esta documentación.

Antes de continuar con la implementación, responda las siguientes preguntas sobre el diseño:

  • ¿La implementación de Sterling OMS es una nueva o va a migrar una implementación existente a Azure?
  • ¿Qué plataforma de base de datos back-end tiene previsto usar? ¿Qué tamaño necesitará la base de datos para los datos?
  • ¿Qué tipo de agente de mensajes basado en JMS tiene previsto usar?
  • Dónde planea implementar el sistema de mensajería:
    • ¿En el mismo clúster de OpenShift?
    • ¿Externo al clúster en otra plataforma o en máquinas virtuales?
  • ¿Tiene un registro de contenedor existente y tiene previsto seguir usándolo?
  • ¿Qué número y tamaños de máquinas virtuales necesita para los nodos de trabajo?
  • ¿Cuáles son los requisitos de seguridad relacionados con el cifrado?
  • ¿Cuáles son los requisitos de acceso y qué consideraciones tiene sobre la integración del proveedor de identidades (IdP)?
  • ¿Cuáles son las necesidades de conectividad? ¿Qué reglas de firewall necesita para conectarse a servicios internos y externos (salida)?
  • ¿Cuál es su estrategia para la alta disponibilidad y la recuperación ante desastres?

Sterling OMS

La versión 10.0.2209.0 de Sterling OMS se ha probado en Azure. Se recomienda usar la versión más reciente de Sterling OMS.

Antes de implementar los recursos de Azure para admitir el entorno de Sterling OMS, familiarícese con los siguientes requisitos:

  • Para obtener información sobre los requisitos del sistema de Sterling OMS, consulte Requisitos del sistema.
  • Sterling OMS depende de un sistema de bases de datos relacional para la administración de datos y el estado. También se requiere un sistema de agente de mensajes habilitado para JMS para la comunicación de servicio a servicio y los flujos de trabajo de pedidos. Sterling OMS admite varias opciones de agente de mensajes y base de datos que puede implementar en su entorno. Para obtener más información, consulte los siguientes recursos:

Red Hat OpenShift en Azure

Sterling OMS se ha probado con la versión 4.10.15 de Red Hat OpenShift en Azure. Antes de implementar Red Hat OpenShift en Azure:

  • Decida un dominio. Al implementar Red Hat OpenShift en Azure, especifique un nombre de dominio que se anexa a todos los servicios que se implementan en el clúster.
  • Determine la visibilidad de la API y de la entrada. Decida cómo quiere que estén accesibles desde Internet la API del clúster de OpenShift (para la administración) y la entrada (para las aplicaciones y los servicios implementados). Si usa conectividad privada para ocultar la API o la entrada, solo puede acceder a estos puntos de conexión desde una máquina que pueda acceder a la red donde implemente el servicio.
  • Calcule los tamaños y el número de máquinas virtuales de control y de trabajo. En Red Hat OpenShift en Azure, el número de control es un número fijo, con un tamaño mínimo recomendado. Los nodos de trabajo que ejecutan las cargas de trabajo de aplicación, como Sterling OMS, se dimensionan por separado. Al implementar la instancia, tenga en cuenta el número necesario de nodos de trabajo en el clúster, además del tamaño adecuado de cada uno. Es posible que tenga que realizar algunas pruebas y validaciones para determinar los números y tamaños correctos. Estos valores dependen del número de agentes de la implementación y del número de pods para cada tipo de agente que ejecute. Después de la implementación, puede ajustar estos valores cuando necesite modificar la escala.

Para más información, consulte la sección Antes de comenzar de Red Hat OpenShift en Azure.

Dimensionamiento del entorno

Se recomienda usar las máquinas virtuales de la serie Ds más recientes como nodos de trabajo. Algunos ejemplos son las series Dsv3, Dasv4, Dsv4, Dasv5 y Dsv5. Las versiones más recientes de estas máquinas virtuales proporcionan el mejor rendimiento. Al implementar más nodos, use solo máquinas virtuales que tengan almacenamiento Premium.

Detalles de la base de datos

Dado que Sterling OMS tiene varias opciones de base de datos back-end, es importante decidir primero en qué plataforma hospedar la base de datos. A continuación, puede tomar decisiones sobre el tamaño de esa plataforma. Tenga en cuenta las siguientes directrices generales durante este proceso:

  • Azure Database for PostgreSQL, modelo de implementación de servidor flexible: debido a la naturaleza de sus opciones de escala y redundancia, el modelo de servidor flexible de Azure Database for PostgreSQL es el método preferido para hospedar cargas de trabajo de Sterling OMS en Azure. Al implementar la instancia:
    • Seleccione el nivel de proceso que coincida con los patrones de uso. Se recomienda empezar con un nivel de uso general y seleccionar un número adecuado de núcleos. Tenga en cuenta también que la CPU, la memoria y las IOPS están vinculadas a la selección del tamaño de proceso.
    • Agregue el almacenamiento adecuado. Recuerde también que el aumento del almacenamiento aumenta el costo y no se puede reducir el almacenamiento aprovisionado. Como resultado, es importante conocer el tamaño inicial de los datos y predecir el crecimiento.
    • Ajuste los parámetros del servidor, como max_connections, que afectan a la capacidad de los agentes para mantener la conectividad con la base de datos.
  • Db2 en máquinas virtuales: al ejecutar Db2 en máquinas virtuales de Azure, hay varios factores complejos que debe abordar, como el rendimiento y la disponibilidad. Para ver un artículo detallado sobre una implementación de Db2 de alto rendimiento en Azure, consulte Alta disponibilidad de IBM Db2 LUW en máquinas virtuales de Azure en Red Hat Enterprise Linux Server. En este artículo, se describen las consideraciones de dimensionamiento y rendimiento. También muestra cómo implementar un clúster de Db2 de alta disponibilidad que usa Pacemaker.
  • Oracle: si actualmente usa Oracle Database o planea migrar a Oracle, familiarícese con los siguientes recursos para ejecutar cargas de trabajo de Oracle en Azure:

Detalles específicos de la cola de mensajes

Sterling OMS requiere un agente de mensajes basado en JMS. Normalmente, se usa IBM MQ. La mejor manera de ejecutar una instancia de IBM MQ de alta disponibilidad en Azure es usar Gráficos de Helm de IBM MQ para implementaciones de Kubernetes. Puede implementar estos gráficos en el clúster de Red Hat OpenShift en Azure existente en nodos de trabajo independientes para aislar las cargas de trabajo. También puede implementar e instalar manualmente IBM MQ en máquinas virtuales si lo prefiere.

Como parte de la implementación estándar, puede definir las colas en el momento de la implementación, lo que reduce el tiempo de configuración necesario para poner en marcha las instancias. La implementación estándar crea una instancia activa y dos pasivas del administrador de colas. Una vez completada la implementación, puede usar SSH para conectarse al pod líder actual y definir el archivo de enlace de JMS. Después, puede usar ese archivo para crear el mapa de configuración para la implementación de Sterling OMS.

IBM también admite otros sistemas de cola de mensajes basados en JMS, como Apache ActiveMQ. Para obtener más información, consulte Colas de mensajes en Sterling Order Management Software. Las opciones de implementación varían según la solución.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Mantener el acceso y la visibilidad en el ciclo de vida de mantenimiento de los recursos puede ser una de las mayores oportunidades de su organización para operar de forma eficaz y mantener el tiempo de actividad. Para mejorar la posición de seguridad del entorno, es importante usar la autenticación segura y mantener actualizadas las soluciones. Use el cifrado para ayudar a proteger todos los datos que se mueven dentro y fuera de la arquitectura.

Azure ofrece Sterling OMS mediante los modelos de IaaS y plataforma como servicio (PaaS). Microsoft crea protecciones de seguridad en el servicio en los niveles siguientes:

  • Centro de datos físico
  • Red física
  • Host físico
  • Hipervisor

Evalúe cuidadosamente los servicios y las tecnologías que seleccione para las áreas que hay sobre el hipervisor, como la versión revisada más reciente de Red Hat OpenShift en Azure para una versión principal. Asegúrese de proporcionar los controles de seguridad adecuados para la arquitectura. Es responsable de aplicar revisiones y mantener la seguridad de los sistemas IaaS. Microsoft asume ese rol para los servicios PaaS, como Red Hat OpenShift en Azure. Aunque puede iniciar una actualización para Red Hat OpenShift en Azure, está totalmente administrada por Microsoft y Red Hat. Para más información sobre la aplicación de revisiones y la actualización de Red Hat OpenShift en Azure, consulte Actualización de un clúster de Red Hat OpenShift en Azure.

Utilice grupos de seguridad de red para filtrar el tráfico de red hacia y desde los recursos en la red virtual. Con estos grupos, puede definir reglas que concedan o denieguen el acceso a los servicios de Sterling OMS. Algunos ejemplos son:

  • Bloquear el acceso a todas las demás partes de la infraestructura implementada, como los puertos y servicios específicos que usan el agente de mensajes o la base de datos back-end.
  • Controlar qué ubicaciones tienen acceso a Sterling OMS y al clúster de OpenShift.

Los números de puerto y los intervalos que debe abrir dependen de muchos factores. Algunos que se deben tener en cuenta son:

  • Puerto 443, para la comunicación entre servicios.
  • Puertos específicos de la base de datos, como el puerto 5432, para la opción de servidor flexible de Azure DB for PostgreSQL.
  • Puertos de cola de mensajes, como el puerto 1414 para IBM MQ.

Tenga en cuenta también estos puntos:

  • Los nodos del clúster de Red Hat OpenShift en Azure deben tener acceso saliente a Internet. Si no puede proporcionar este acceso, estos nodos necesitan, como mínimo, acceso a los puntos de conexión de registro de los servicios y Azure Resource Manager.
  • IBM proporciona instrucciones para implementar varias aplicaciones de Sterling OMS que comparten servicios comunes como una base de datos back-end. Estas implementaciones también tienen consideraciones sobre el firewall dentro de la aplicación. Para más información, consulte Apertura de puertos de firewall para la comunicación dentro de la aplicación.

Si necesita acceso a los demás nodos que no son de Red Hat OpenShift en Azure, también puede usar Azure Bastion para acceder a las máquinas virtuales. Por motivos de seguridad, no debe exponer las máquinas virtuales a una red o a Internet sin configurar grupos de seguridad de red para controlar el acceso a ellas.

El cifrado del lado servidor (SSE) de Azure Disk Storage ayuda a proteger los datos. SSE también le ayuda a satisfacer los compromisos de seguridad y cumplimiento de la organización. Con discos administrados de Azure, SSE cifra los datos en reposo al conservarlos en la nube. Este comportamiento se aplica de forma predeterminada a los discos de datos y del sistema operativo. OpenShift usa SSE de forma predeterminada. Red Hat OpenShift en Azure también admite claves de cifrado administradas por el cliente (CMEK) para los discos del sistema operativo del clúster.

Authentication

Debe configurar OAuth para Red Hat OpenShift en Azure. Para obtener más información, consulte Configuración de la autenticación de Azure Active Directory para un clúster de Red Hat OpenShift en Azure 4 (Portal) en la documentación de Red Hat OpenShift en Azure.

Protección de la infraestructura

Controle el acceso a los recursos de Azure que implemente. Cada suscripción de Azure tiene una relación de confianza con un inquilino de Microsoft Entra. Use el control de acceso basado en rol de Azure para conceder a los usuarios de la organización los permisos adecuados en los recursos de Azure. Para conceder el acceso, asigne los roles de Azure a usuarios o grupos en un ámbito determinado. El ámbito puede ser una suscripción, un grupo de recursos o incluso un solo recurso. Asegúrese de auditar todos los cambios en la infraestructura. Para más información sobre la auditoría, consulte Registro de actividad de Azure Monitor.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Una implementación estándar de Sterling OMS consta de los siguientes componentes. Puede ajustar muchos de estos recursos basados en proceso para satisfacer sus necesidades. Por ejemplo, puede escalar verticalmente los nodos del agente de IBM MQ para permitir un mayor rendimiento.

Red Hat OpenShift en Azure (para OMS)

  • Tres máquinas virtuales de control (Standard_D8s_v5)
  • Tres máquinas virtuales de trabajo (Standard_D8s_v5)

Recursos adicionales

  • Una red virtual (/16), con las siguientes subredes consideradas:
    • Subred del nodo de control de Red Hat OpenShift en Azure (/24)
    • Subred del nodo de trabajo de Red Hat OpenShift en Azure (/24)
    • Subred de datos, si es necesario (/27)
    • Subred de máquina virtual adicional, si es necesario (/27)
    • Subred de administración, si es necesario (/30)
  • Una instancia de Azure Database for PostgreSQL con la opción de servidor flexible
  • Una instancia de Azure Container Registry
  • Dos cuentas de Azure Storage
  • Tres zonas DNS
  • Dos equilibradores de carga
  • Una máquina virtual de jump box
  • Azure Bastion

Las implementaciones individuales pueden diferir, por ejemplo, si ejecuta Db2 en máquinas virtuales de Azure o si implementa IBM MQ en el entorno de Red Hat OpenShift en Azure. Para revisar una estimación de ejemplo, use la calculadora de costos. Las configuraciones varían, por lo que debe comprobar la configuración con el equipo de dimensionamiento de IBM antes de finalizar la implementación.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

Red Hat OpenShift en Azure tiene funcionalidades integradas para la recuperación automática, el escalado y la resistencia para garantizar que Red Hat OpenShift en Azure y Sterling OMS funcionen correctamente. Red Hat OpenShift en Azure y Sterling OMS se han diseñado para tener partes en las que se producen errores y se recuperan. Un requisito clave para la recuperación automática es que haya suficientes nodos de trabajo. Para recuperarse de un error de zona dentro de una región de Azure, los nodos de control y de trabajo deben equilibrarse entre zonas de disponibilidad.

Sterling OMS y Red Hat OpenShift en Azure usan el almacenamiento de base de datos para conservar el estado fuera del clúster de Kubernetes. Los registros y otros recursos de la aplicación se conservan en una cuenta de almacenamiento. Para asegurarse que las dependencias de almacenamiento sigan funcionando durante un error, utilice el almacenamiento con redundancia de zona siempre que sea posible. Este tipo de almacenamiento permanece disponible cuando se produce un error en una zona. La implementación de la base de datos también debe tener en cuenta las configuraciones de varias zonas.

Dado que el error humano es común, implemente Sterling OMS con la mayor automatización posible. Para ver algunos scripts de ejemplo para configurar una automatización completa y de un extremo a otro, consulte Guía de inicio rápido: Sterling Order Management en Azure en GitHub.

Implementación de este escenario

Antes de empezar, revise los requisitos de Sterling OMS en Requisitos del sistema. Asegúrese también de que dispone de los siguientes recursos:

  • Acceso a una suscripción de Azure con permiso de Lector.
  • Un registro de aplicación o un nombre de entidad de seguridad de servicio que tenga permisos de Colaborador y Administrador de acceso de usuario en la suscripción.
  • Un dominio o un subdominio delegado en una zona DNS de Azure.
  • Una clave de derecho de IBM Sterling OMS.
  • Dimensionamiento del clúster recomendado por IBM.
  • Una red virtual existente o una red virtual nueva, según sus requisitos. Para obtener un ejemplo de creación de una nueva red virtual con dos subredes vacías, consulte Tutorial: Creación de un clúster de la versión 4 de Red Hat OpenShift en Azure.
  • Requisitos de alta disponibilidad y recuperación ante desastres para la implementación específica.
  • Un archivo de configuración OMEnviroment, omenvironment.yaml, que se usará al implementar Sterling OMS mediante el catálogo del operador de OpenShift.

Para obtener una guía paso a paso para instalar Red Hat OpenShift en Azure y Sterling OMS en Azure, incluido cómo abordar los requisitos previos, consulte Guía de inicio rápido: Sterling Order Management en Azure.

Consideraciones de la implementación

El procedimiento recomendado actual es implementar las cargas de trabajo mediante el uso de la infraestructura como código (IaC) en lugar de implementar manualmente las cargas de trabajo, ya que la implementación manual puede dar lugar a una configuración incorrecta. Las cargas de trabajo basadas en contenedores suelen ser sensibles a los errores de configuración, lo que puede reducir la productividad.

Antes de crear el entorno, consulte Guía de inicio rápido: Sterling Order Management en Azure para desarrollar una comprensión de los parámetros de diseño. La guía de inicio rápido no está pensada para una implementación lista para producción, pero puede usar los recursos de la guía para llegar a un mecanismo de nivel de producción para la implementación.

IBM ofrece servicios especializados para ayudarle con la instalación. Póngase en contacto con su equipo de IBM para obtener soporte técnico.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

  • Aneesh AR | Especialista sénior en servicios en la nube
  • Vijaya Bashyam | Miembro sénior del personal técnico
  • James Read | Arquitecto principal de soluciones de EMEA
  • Andy Repton | Especialista en OpenShift administrado

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes