Ha finalizado la implementación estándar de SAP Rapid Marts XI, todo ha ido bien, pero su cliente comienza a tener problemas con respecto al consumo de tiempo de las cargas delta. En este artículo voy a explicar un par de enfoques para lograr un mejor rendimiento en las cargas delta de SAP Rapid Marts.En la imagen de abajo tenemos la infraestructura típica de SAP Rapid Marts, cargando en un solo almacén de datos.
Esta infraestructura tiene pros y contras, pero voy a destacar dos ventajas principales:
- Evita la duplicación de información
- Simplifica el mantenimiento desde la perspectiva del cliente
1st Approach: One job runs it all
Taking the architecture illustrated above as our basis, the first step to achieve better performance will be to create one single ETL job to run the different SAP Rapid Marts involved in our implementation.
Esta tarea es simple; Sólo cree un flujo de trabajo por SAP Rapid Mart que contenga todos los flujos de trabajo diferentes que forman parte de SAP Rapid Mart. Una vez realizada esta tarea, cree un trabajo ETL con todas las variables globales correspondientes, arrastre y suelte todos los flujos de trabajo y conéctelos para crear una secuencia de ejecución.
Este trabajo también nos permite aprovechar la opción "ejecutar sólo una vez" en SAP Data Services. Esta opción se establece para todos los componentes de SAP Rapid Marts y define que cada componente dentro de la misma ejecución de trabajo ETL se ejecuta sólo una vez. Si se tiene en cuenta cuántos componentes se comparten entre diferentes SAP Rapid Marts este enfoque se vuelve muy interesante.
Además, este enfoque nos permite crear una estrategia de try / catch en el proceso ETL. Algunos entornos de clientes pueden tener problemas intermitentes que pueden bloquear la ejecución de nuestras cargas diarias (es decir, errores de red). Colocaremos las sentencias try y catch para cada flujo de trabajo del trabajo, entonces dentro de la declaración de catch volveremos a colocar el flujo de trabajo que estábamos tratando de ejecutar, la siguiente imagen ilustra la idea:
The try/catch + ”Execute only once” strategy allows you to retry the execution of a component of the ETL job and continue the execution where it stopped.
Una vez implementada esta idea, la ejecución de SAP Rapid Marts será más robusta y optimizada, pero tal vez no sea suficiente para satisfacer las expectativas de sus clientes ... así que pasemos al segundo paso.
2nd Approach: Working around a parallel execution
Al analizar la información de los informes de rendimiento generados en SAP Data Services Management Console después de la ejecución de un trabajo, podrá identificar los componentes con los peores tiempos de ejecución.
Estos componentes pueden variar de una implementación a otra dependiendo del entorno de su cliente; Dentro de los 10 peores tiempos de ejecución se encuentran algunos componentes que generan información de dimensiones y / o tablas de hechos del modelo. Algunos de estos componentes se pueden quitar fácilmente de su ejecución secuencial y colocarlos en un trabajo separado para ejecutarse en paralelo.
Es crítico en esta etapa asegurarse de que estos componentes están completamente eliminados de la ejecución secuencial y que cualquier salida final del componente no se utiliza en otras partes del proceso ETL (es decir, las búsquedas de tabla posteriores). Para garantizar esto, la función "Where is used" del SAP Data Services Designer será extremadamente útil.
En mi experiencia, después de aplicar estos dos pasos deberíamos experimentar una mejora considerable en el rendimiento de ejecución de las cargas delta. Para darle un ejemplo, en una de nuestras implementaciones recientes empezamos con un tiempo de ejecución de 17 horas para cinco SAP Rapid Marts que se ejecutaban secuencialmente, esto se redujo a 6 horas usando los dos enfoques que he descrito en este post.
Cavar más profundo
Si incluso después de aplicar los pasos anteriores aún enfrenta un mal rendimiento en componentes aislados, esta situación requerirá más análisis y personalización en un nivel inferior.
Algunos componentes del estándar SAP Rapid Mart intentan ejecutar en el ERP algunos componentes con lógica compleja, lo que puede tardar mucho tiempo (por ejemplo, SAP General Ledger RM + Nota SAP 1557975 o SAP Inventory RM + SAP Nota 1528553 )
En estos casos, la solución es dividir el proceso en varios pasos y tal vez hacer uso de tablas personalizadas en el lado ERP y el aumento de rendimiento será notable. Puedo decirles que en nuestra implementación más reciente uno de los componentes tardaba menos de 12 horas en ejecutarse, pero después de analizar y modificar el comportamiento del componente, para hacer uso de una tabla personalizada en el ERP, este componente No tardó más de 30 minutos en ejecutarse. Este proceso de personalización de un componente tomó 2 días hombre para ser completamente implementado.
Como conclusión, mi experiencia con SAP Rapid Marts es muy positiva. SAP proporciona una solución de despliegue rápido que puede estar en funcionamiento y de extremo a extremo en pocas semanas. Además, proporciona un marco extremadamente fácil de usar para asegurar que su cliente tenga la capacidad de desarrollar cualquier nivel de personalización en pocas semanas. En general, estamos frente a una solución que permitirá a sus clientes crear su propio almacén de datos en semanas en lugar de meses. Si podemos mejorar este problema de rendimiento de carga delta, la solución se vuelve aún más atractiva para sus clientes y ayuda a aumentar los niveles de satisfacción con la herramienta.
¡Eso es todo amigos! Espero que este artículo le ayude a elevar la barra en sus implementaciones SAP Rapid Marts. Si tiene alguna duda, no dude en dejar un comentario a continuación.