🚀PROMO #PLANCARRERA2024 - 🔥Bonificaciones, Precios Congelados y Cuotas

 X 

✒️SAP BI / BW BO Data Store Objects (ODS o DSO)

SAP BI / BW BO Data Store Objects (ODS o DSO)

SAP BI / BW BO Data Store Objects (ODS o DSO)

DATA STORE OBJECTS (ODS o DSO)

1. Clases de Objetos DataStore

Sap BI distingue entre tres clases de objeto datastore: actualización estándar, optimizada para escritura y actualización directa. Estas tres clases de ODS se muestran a continuación:

  • ODS estándar: consiste en tres tablas (cola de activación, tabla de datos activas y log de modificaciones). Está totalmente integrado en el proceso de staging. En otras palabras, los datos se pueden cargar y descargar de los objetos DataStore durante el proceso de Staging. Utilizar un log de modificaciones significa que todas las modificaciones también se escriben y están disponibles como actualizaciones delta para destinos de datos conectados.
  • ODS optimizado para escritura: es un nuevo tipo de objeto DataStore. Está dirigido al nivel de almacén de la arquitectura, ya que, por ejemplo, los datos con la misma clave no son agregados, por lo tanto, podríamos tener como fue variando históricamente. Tiene como ventaja principal la mayor rapidez de las cargas. Este tipo de ODS es utilizado para reportes que necesitan los datos actualizados rápidamente, pero, hay que tener en cuenta que los reportes que utilizan este tipo de ODS tienen un desempeño muy pobre en cuanto a Performance.
  • ODS actualización directa: (ODS transaccional 3.x anterior) sólo tiene la tabla con datos activos. Esto significa que no se integra tan fácilmente en el proceso de staging. En lugar de eso, esta clase de objeto DataStore se rellena utilizando APIs y se puede leer a través de un BAPI. Las siguientes BAPIs son entregadas por SAP (pueden ver su código ABAP a través de la transacción SE37):

- BAPI_ODSO_READ_DATA_UC

- RSDRI_ODSO_INSERT

- RSDRLI_ODSO_INSERT_RFC

- RSDRI_ODSO_MODIFY

- RSDRI_ODSO_MODIFY_RFC

- RSDRI_ODSO_UPDATE

- RSDRI_ODSO_UPDATE_RFC

- RSDRI_ODSO_DELETE_RFC

Transacción SE37: mediante la transacción SE37 podremos probar muchos de los módulos de funciones entregados por SAP- También podemos ver el código ABAP de las funciones.

2. Comparación de PSA, ODS e InfoCubo

Los PSA almacenan datos fuente brutos, los InfoCubos almacenan datos de resumen y existen tres clases de objetos DataStore. Veamos una comparación rápida de estos tres objetos antes de que profundicemos más en los objetos DataStore estándar.

La utilización principal del PSA es almacenar temporalmente los datos del sistema fuente antes de que se transfieran a los destinos de datos reales. Por esta razón, no podrá modificar los datos del sistema SAP BI antes que pasen por el PSA. Aquí solo se realiza una copia de los datos del sistema fuente, funcionaría como una memoria intermedia.

Los ODS se utilizan principalmente para armonizar o consolidar datos. Resultan especialmente apropiados para esta utilización, puesto que proporcionan varias opciones diferentes.

Por otro lado, los ODS están formados por tablas planas que se pueden leer de manera simple (sirven como tablas de distribución o consulta, por ejemplo). Los objetos en sí contienen muchas funciones (determinación delta, por ejemplo). Teniendo en cuenta todas estas propiedades, los objetos DataStore cubren muchas de las demandas que se realizan dentro del proceso de staging.

3. Posicionamiento de ODS en el flujo de datos

En muchas situaciones, es necesario o ventajoso, incorporar ODS adicionales al proceso de Almacenamiento. SAP BI le permite integrar uno o más ODS en el flujo de datos entre la PSA y los InfoCubos. Normalmente, estos ODS almacenan datos en un nivel detallado y se pueden utilizar para armonizar y consolidar los datos antes de ser almacenados en InfoCubos multidimensionales de forma agregada.

Como puede verse en la parte derecha del gráfico PSA / Objeto DataStore / InfoCubo, la integración de objetos DataStore en el flujo de datos es opcional.

También es posible actualizar datos desde una fuente de datos a un InfoCubo directamente y no utilizar ODS.

Analizándolo como una situación de implementación, podemos distinguir tres clases de ODS en diferentes posiciones del flujo de datos basándonos en su utilización:

  • Datos fuente similares: en este caso, los datos se almacenan de la misma forma que los ha entregado la fuente de datos del sistema fuente. Si desea conservar un historial completo de las modificaciones de los datos, deberá incluir una referencia temporal consistente en la clave del objeto DataStore.
  • Requerido técnicamente: en estos objetos DataStore, los datos se almacenan de forma armonizada. El proceso de armonización engloba varios aspectos:

- Armonización de tipos de datos de variante y longitudes: un ejemplo podría ser aquel en el que el número de cliente tiene 10 caracteres en el sistema fuente, pero 13 caracteres en otro sistema. SAP BI necesita armonizar la longitud del número de cliente. Puede hacerlo implementando un ODS en el que el cliente tenga un número de cliente de 13 caracteres. Debe realizar las transformaciones necesarias antes de implementar este objeto DataStore.

- Armonización de diferentes métodos delta del sistema fuente: un objeto DataStore puede convertir diferentes métodos delta desde los sistemas fuente (delta aditivo y after-image para registros rectificados) en un único delta con una clase. Ello garantiza que a los destinos conectados adicionales (en especial InfoCubos) se les proporcione un método delta apropiado.

Esta armonización resulta especialmente útil al derivar un delta, siempre que un sistema fuente sólo sea capaz de extraer actualizaciones completas.

- Armonización de datos: a menudo, tiene que armonizar el propio contenido de datos reales. Ello puede implicar características (materiales, por ejemplo) y ratios (beneficios).

Un ejemplo sería la derivación de un número de material global único a partir de los números de material subsidiario locales. Por ejemplo, en el primer sistema fuente, el número de material 100 es un "auto deportivo".

Un segundo sistema fuente dice que el mismo número de pieza es "lápices". Como resultado, un número de material global se deriva en SAP BI, lo que proporciona números de material global únicos. La gestión de datos maestros trabaja en SAP BI para dar soporte a este escenario y a muchos otros.

  • Específico de aplicación empresarial: estos ODS se utilizan normalmente para preparar datos para determinados escenarios de reporting. Por ejemplo, tiene materiales que tienen diferentes estatus y debido a que cambian continuamente quiere armar un ODS sólo para almacenar los materiales que tienen estatus entregado.

4. Arquitectura y funciones de objetos ODS

Los ODS estándar están formados por tres tablas:

  • Tabla de datos activos (Active): aquí es donde se almacena el estado actual de los datos. Es muy importante que la clave esté correctamente definida por el responsable del modelado, ya que una coincidencia en la clave inicia un tratamiento delta especial durante la fase de activación (explicada más adelante). Los reportes creados mediante BEx utilizan los datos de esta tabla.

"Para que los datos pasen a la tabla activa, los datos deben ser activados. Esto puede realizarse en una cadena de procesos como veremos en la unidad 7 o bien desde la solapa que vemos en la imagen siguiente, seleccionando la petición (request) sin activar y presionando el botón Activate."

  • Tabla de log de modificaciones (Change Log): durante la ejecución de activación, las modificaciones se almacenan en el log de modificaciones. En este punto puede encontrar el historial completo de las modificaciones, dado que el contenido del log de modificaciones no se borra automáticamente. Los destinos conectados se actualizan desde el log de modificaciones si reciben datos del objeto DataStore en el método delta. El log de modificaciones tiene clave técnica que consiste en una solicitud, un paquete de datos y un número de registro de datos.
  • Tabla de datos nuevos (New Data): durante el proceso de transferencia de datos, los registros se escriben primero en esta tabla.

5. Modelado y creación de ODS

Se configuran diferentes listas de selección para seleccionar InfoObjetos en el área superior izquierda de la GUI. Con arrastrar y soltar o con la opción de entrada directa al menú contextual, los InfoObjetos se añaden a las áreas adecuadas del objeto DataStore.

Finalmente, pueden tomarse decisiones sobre la habilitación de atributos de navegación y la creación de índices definidos por el usuario.

  • Opciones de los ODS: la pregunta más importante cuando se modelan objetos DataStore es: ¿Qué InfoObjetos forman los campos clave del objeto DataStore y qué InfoObjetos representan los campos de datos?

Cuando modele un ODS, debería tener en cuenta lo siguiente:

¿Qué InfoObjetos debe contener el objeto DataStore?

¿Qué objetos definen de manera única el proceso? Estos objetos no dependen los unos de los otros y normalmente forman la clave del ODS.

¿Qué atributos de navegación (Atributo nav.) deben estar activados para este objeto DataStore?

Los atributos navegacionales son atributos que pertenecen a alguna característica incluida en el ODS o InfoCubo. Este tipo de atributos tienen la ventaja de poder ser utilizados luego en el armado de reportes con BEx Query Desginer.


Para InfoObjetos sobre los que se consulta muy seguido, pueden utilizarse los índices. Sólo conviene utilizar índices en caso que este ODS sea utilizado para reportes.

6. Carga y activación de ODS

Veremos un ejemplo para ilustrar qué sucede exactamente cuando los datos se transfieren y posteriormente se activan en un objeto DataStore.

Supongamos que se cargan dos solicitudes REQU1 y REQU2 en un objeto DataStore. Ello puede ocurrir de forma secuencial o paralela. El proceso de carga contabiliza ambas solicitudes en una cola de activación.

En la imagen siguiente, se activa esta solicitud nueva. El nuevo registro de datos sobrescribe entonces al existente en la tabla activa del objeto DataStore. Esto crea un valor actualizado de 10 para el pedido de la tabla activa. También se introduce un nuevo registro en el log de modificaciones, ya que tiene una clave técnica nueva.

Durante la activación de ratios en el modo sobrescribir, el proceso de activación crea un registro con signos invertidos y lo coloca en el log de modificaciones.

En este caso, se trata de un registro para un valor 4711 de -10. Como resultado, al final de la ejecución de la activación, aparecen tres registros de datos de dos solicitudes en el log de modificaciones.

En nuestro ejemplo, ambos registros cargados pertenecen a la misma clave semántica: Nº doc.. Por este motivo, la tabla con los datos activos sólo tiene una entrada. Una vez más, después de la activación satisfactoria, la cola de activación está vacía.

Los números de solicitud generados por la activación en el log de modificaciones no son los mismos que los de la cola de activación, ya que documentan dos sistemas de eventos diferentes.

Si el objeto DataStore no estaba en el flujo de datos en este ejemplo, y los datos fuente fluyeron directamente a un InfoCubo, el InfoCubo añadiría el 10 al 30 y obtendría un valor incorrecto de 40.

Si en su logar pasamos los datos del log de modificaciones al InfoCubo, 10, -10 y 30 se añaden al valor correcto de 30. En este ejemplo, se necesitó un objeto DataStore en el flujo de datos antes del InfoCubo. No siempre es necesario, pero muchas es recomendable.


 

 

 


Sobre el autor

Publicación académica de Diego Rafael Arevalo Forcado, en su ámbito de estudios para la Carrera Consultor en SAP BI / BW BO.

SAP SemiSenior

Diego Rafael Arevalo Forcado

Profesión: Estudiante de Universidad - Paraguay - Legajo: JN32R

✒️Autor de: 13 Publicaciones Académicas

🎓Egresado del módulo:

Disponibilidad Laboral: FullTime

Certificación Académica de Diego Arevalo

✒️+Comunidad Académica CVOSOFT

Continúe aprendiendo sobre el tema "Data Store Objects (ODS o DSO)" de la mano de nuestros alumnos.

SAP Senior

Acceder a esta publicación

Creado y Compartido por: Mary Galicia / Disponibilidad Laboral: FullTime

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Senior

Acceder a esta publicación

Creado y Compartido por: Jhon Jairo Monsalvo Villalobos / Disponibilidad Laboral: FullTime + Carta Presentación

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Senior

Acceder a esta publicación

Creado y Compartido por: German Augusto Macias Chacon

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP SemiSenior

Acceder a esta publicación

Creado y Compartido por: Diego Andrés Vasquez Ruiz / Disponibilidad Laboral: PartTime + Carta Presentación

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Expert


Acceder a esta publicación

Creado y Compartido por: Miguel Antonio Lazo Vega

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Expert


Acceder a esta publicación

Creado y Compartido por: Maria Guadalupe Gonzalez Sanchez

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP SemiSenior

Acceder a esta publicación

Creado y Compartido por: Miguel Fernando Olaya Rivera / Disponibilidad Laboral: FullTime + Carta Presentación

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Senior

Acceder a esta publicación

Creado y Compartido por: Mauricio Osenga Vasquez

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Master

Acceder a esta publicación

Creado y Compartido por: Vanessa Cristal Vera

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP SemiSenior

Acceder a esta publicación

Creado y Compartido por: Diego Rafael Arevalo Forcado / Disponibilidad Laboral: FullTime

 


 

👌Genial!, estos fueron los últimos artículos sobre más de 79.000 publicaciones académicas abiertas, libres y gratuitas compartidas con la comunidad, para acceder a ellas le dejamos el enlace a CVOPEN ACADEMY.

Buscador de Publicaciones:

 


 

No sea Juan... Solo podrá llegar alto si realiza su formación con los mejores!