Contact us at +1.415.901.7500 or contact@itconvergence.com

Creando Customizaciones Listas para SaaS en su ERP On Premise

Creando Customizaciones Listas para SaaS en su ERP On Premise

Es un hecho que todas las organizaciones que ejecutan ERPs On Premise (como Oracle EBS) o SaaS (como Oracle ERP Cloud) necesitan customizaciones, extensiones e integraciones como parte de su implementación. Al calcular el ROI de una customización que tiene hoy en su solución local pero que quizás próximamente migre a la nube, puede considerar costos varados o hundidos debido al cambio en la tecnología.

Aquí hay un estrategia para obtener un mejor ROI que le permitirá mantener la inversión en sus customizaciones, incluso cuando migre a Oracle Cloud SaaS.

Existen múltiples opciones que le permitirán desarrollar esta estrategia y la presentaremos en la publicación para ayudarlo a avanzar con una estrategia de desarrollo sostenible.

 

ORACLE APPLICATION EXPRESS

Oracle Application Express (APEX) es una herramienta rápida de desarrollo de aplicaciones que se puede utilizar para crear aplicaciones completas de back-office, front-end y móviles. Originalmente lanzada en 2004 con un nombre diferente, ha ido evolucionando año tras año convirtiéndose en uno de los más fuertes del mercado.

Se puede instalar On Premise en una base de datos Oracle (incluso en la base de datos que admite sus aplicaciones Oracle) y también se puede usar como PaaS (Platform as a Service) Oracle.

APEX no requiere habilidades de desarrollo muy amplias y aprovecha el conocimiento existente que su organización puede tener internamente, como Oracle PL / SQL, HTML y JavaScript.

Cuando hablamos del desarrollo de extensiones de aplicaciones, APEX es una herramienta ideal para cerrar la brecha entre On Premise y SaaS, debido a su experiencia intuitiva para desarrolladores, diseño de páginas y componentes potentes.

Versiones de APEX

Queremos poder utilizar las extensiones desarrolladas hoy cuando nos movamos a SaaS en el futuro. Por ello trabajar con una versión actualizada de APEX nos asegurará que la herramienta aún sea adecuada cuando hagamos esa migración.

En el momento de escribir este artículo, ApplicationExpress versión 19.2 es la versión más actual y requiere la base de datos Oracle 11.2.0.4.

Aunque APEX se puede instalar en la base de datos de Oracle Applications, las dependencias de la versión del producto pueden ser un obstáculo para instalar las últimas versiones, por lo que instalar APEX en una base de datos separada puede ser la mejor opción.

Integración de APEX con EBS

APEX puede acceder a los datos de la base de datos de Oracle Applications directamente si está instalado en la misma base de datos, o mediante procedimientos alternativos como enlaces a bases de datos (database links) si está instalado en bases de datos separadas. Pero a pesar de eso, queremos implementar un método para leer y escribir datos que aún funcionará cuando migremos a SaaS.

WebServices es una buena manera de hacerlo, ya que es independiente de la plataforma y puede implementarse en las instalaciones y en la nube.

WebServices está disponible en las aplicaciones de Oracle como parte del repositorio de integración de Oracle o se puede desarrollar para proporcionar funciones especiales que no están disponibles en los WebServices estándar.

Trabajar con WebServices para leer y escribir datos de Oracle Applications es ciertamente más complejo que ejecutar comandos SQL simples, pero el hecho de que esto nos permita conservar las customizaciones cuando migramos puede hacer que valga la pena el esfuerzo.

 

ORACLE INTEGRATION REPOSITORY

Oracle Integration Repository (OIR) es una compilacion de numerosas interfaces y mecanismos de integración expuestos por Oracle Applications que proporciona un catálogo completo de las interfaces comerciales de Oracle E-Business Suite y una vista completa de todos los mecanismos de interfaz disponibles.

Como parte de esos mecanismos de interfaz, OIR enumera todos los servicios web disponibles y proporciona funciones para implementarlos para que pueda comenzar a usarlos.

Estos son WebServices que vienen preempaquetados con la aplicación y no requieren codificación adicional para trabajar.

Creando WebServices Personalizados Adicionales

Aprovechar los WebServices estándar incluidos en la aplicación siempre será nuestra primera opción, pero también es posible que necesitemos crear nuevos servicios para proporcionar funciones especiales o devolver valores especiales no incluidos en la carga útil (parámetros) de ninguno de los WebServices estándar.

Hay muchas herramientas diferentes disponibles para crear servicios web, como Java, por supuesto, pero APEX también se puede usar para publicar información fácilmente como un servicio web simplemente escribiendo tipo especial de reporte construido con APEX.

Esto significa que al instalar APEX (incluso versiones antiguas como APEX 4 o 5) en la base de datos de E-Business Suite, podremos generar WebServices para publicar datos que pueden ser consumidos por nuestro entorno externo APEX.

Este enfoque tiene la ventaja de reutilizar el conocimiento de la herramienta APEX para que no necesite aprender sobre un nuevo marco de desarrollo para crear los servicios web.

Arquitectura Sugerida para el Desarrollo de Extensiones en Aplicaciones On Premise

El siguiente diagrama resume la arquitectura sugerida basada en los conceptos discutidos hasta ahora:

(Tenga en cuenta que está más allá de los objetivos de este análisis centrarse en las diferentes configuraciones APEX disponibles para admitir el acceso seguro desde fuera de la VPN)

La base de datos EBS contiene los esquemas para el modelo de datos estándar (los datos que admiten los módulos de aplicación) más esquemas adicionales creados para contener objetos de base de datos personalizados.

Los datos en el modelo de datos estándar son publicados por WebServices generados desde el repositorio de integración, mientras que los datos de los esquemas personalizados son publicados por WebServices generados desde el entorno APEX instalado en la base de datos EBS.

El entorno externo APEX instalado en una versión actual de la base de datos contiene las extensiones de la aplicación y se integra con EBS a través de los servicios web publicados desde esa base de datos.

MIGRANDO A SAAS Y PAAS

Cuando el EBS On Premise se retira del servicio y se implementa la aplicación Oracle Cloud SaaS, las extensiones creadas en el entorno externo APEX se modifican para que funcionen con los servicios web estándar disponibles en la aplicación Oracle Cloud SaaS.

Esto puede ser un trabajo fácil de hacer si creamos servicios en nuestro EBS On Premise que se parecen a los servicios disponibles en SaaS.

La documentación de la aplicación Oracle Fusion proporciona información extensa sobre los servicios disponibles y sus cargas útiles y las reglas comerciales aplicadas, por lo que este comportamiento puede integrarse en los servicios que desarrollamos mientras todavía se encuentra en el modelo On Premise.

¿VALE LA PENA?

Aunque esta estrategia le permitirá preservar las extensiones de su aplicación cuando se mude a una aplicación en la nube, su complejidad merece un análisis completo de los pros y los contras antes de tomar la decisión de implementarla.

El esfuerzo adicional requerido para acceder a los datos a través de los servicios web y la necesidad de modificar/probar las extensiones al pasar a la nube deben evaluarse y compararse con el esfuerzo requerido para reconstruir las extensiones cuando ya está en Oracle Cloud SaaS solicitud.

Entre otros elementos para evaluar, tendrá que considerar las siguientes circunstancias:

  1. Cuando se mude a Oracle Cloud SaaS, tendrá que construir sus extensiones en el modelo PaaS, ya que esa es la única forma de extender una aplicación SaaS. Por lo tanto, volverá a utilizar una buena parte del código creado hoy mientras todavía está con su EBS On Premise.
  2. Si las extensiones que se construirán hacen un sistema separado o un módulo satelital, entonces el número de funciones para construir puede hacer que valga la pena seguir esta estrategia dado el volumen de código que se construirá y podrá reutilizarse incluso cuando se realicen ajustes será requerido.
  3. Incluso cuando los requisitos de extensión actuales pueden ser limitados, el hecho de que aún no sepa cuándo se moverá a la nube indica que cada vez habrá más requisitos de extensión. Entonces, cuanto antes implemente una estrategia de preservación, mejor.

ERP Roadmap Assessment