Conceptos comparados: BPC estándar y BPC integrado

Introducción

Después de las discusiones y respuestas a preguntas en este foro y también en el foro Business Planning http://scn.sap.com/community/data-warehousing/business-planning tengo la impresión de que vale la pena explicar los conceptos utilizados en BW-IP/PAK tal como se expone en BPC embedded y para comparar estos conceptos con BPC standard . Este tipo de información generalmente no está incluida en la documentación.

Esta comparación no es una lista de características y también trata de evitar juicios sobre si los conceptos utilizados son buenos o malos. La atención se centra en conceptos básicos, por ejemplo, conceptos de metadatos, modelos de datos, trabajo con datos de transacciones, cómo funcionan los motores y conceptos de transacción. Aquí solo se trata la planificación, no hay consolidación.

También corregiré algunas anotaciones ya que BW y BPC a veces usan la misma terminología para diferentes cosas. Esto generalmente causa mucha confusión.

Así que comencemos con la terminología para los objetos BPC muy básicos, a saber, Entorno BPC y Modelo BPC. En mi humilde opinión (lo siento, mi primer juicio) estos nombres no son buenos: medio ambiente y modelo son demasiado genéricos y pueden causar malentendidos. Los nombres antiguos.

  • BPC Environment Application Set
  • Modelo BPC Appliaction

Son mucho mejores, ya que un Modelo BPC representa una aplicación de planificación y un Ambiente BPC es una agrupación de aplicaciones de planificación que comparten dimensiones de planificación y están vinculadas entre sí. Los enlaces, por ejemplo, pueden estar representados por BPF, por ejemplo, dado que las aplicaciones intercambian datos de planificación. Hablando de objetos BPC siempre usaré el término completo, por ejemplo, Modelo BPC. Pero hablando de conceptos generales como en modelo de datos usaré solo modelo (sin BPC).

Un glosario contiene algunas definiciones de la terminología utilizada.

¿Por qué BPC embedded?

BPC estándar es una solución de planificación (ok, también de informes y consolidación) basada en la tecnología BW diseñada principalmente para ser utilizada por LOB. Los objetos técnicos BW necesarios (por ejemplo, InfoObjects, InfoCubes) son generados y controlados por BPC y no expuestos directamente en BPC. BPC presenta conceptos específicos de BPC diferentes de los conceptos de BW. Por lo tanto, en Estándar BPC, uno debe copiar todos los datos maestros, jerarquías y datos de transacción desde BW a BPC y alinear los datos copiados con los conceptos BPC. En este sentido, el estándar BPC es una solución de mercado de datos. Para respaldar este estándar BPC, se implementó nuevamente una gran cantidad de funcionalidad existente en BW (pero en el modo BPC).

Por otro lado, existe BW-IP (desde BW 7.0). Esta es una solución de planificación en BW (por cierto, este donde el nombre En Planificación integrada viene), es decir, BW-IP utiliza directamente objetos BW. Se añadieron muy pocos objetos nuevos a BW para soportar la planificación integrada (por ejemplo, el nivel de agregación de InfoProvider y las funciones de planificación). Los objetos BW-IP son por lo tanto objetos BW “nativos”. BW tiene una parte de informe y WHM y, por lo tanto, los requisitos fueron impulsados ​​por escenarios de TI (por ejemplo, modelos de datos centrales, punto de verdad único …). Esto también se aplica a BW-IP. Como resultado, BW-IP tiene un carácter completamente genérico, los conceptos y modelos de datos BPC estándar provienen más del área de planificación financiera (y, por supuesto, de consolidación).

Hay dos soluciones, optimizadas para casos de uso LOB (Líneas del negocio) o TI.

  • En una solución de mercado de datos, uno tiene que copiar y asignar / ajustar datos maestros / jerarquías y datos de transacciones, generalmente a partir de modelos de datos WHM de alta calidad existentes. Este foro está lleno de ejemplos de cómo se puede lograr esto. Esto requiere un poco de esfuerzo (no solo una vez) y es, por naturaleza, un tipo de problema de ETL. Esta no es una tarea fácil para las personas de LOB. Y todo esto tiene que hacerse solo para obtener la flexibilidad (en el sentido de empoderamiento, no de características del producto) que las personas LOB puedan modelar e impulsar el proceso de planificación.
  • Uno solo puede cambiar el punto de vista, es decir, en los escenarios de TI, las personas LOB necesitan ajustes en los procesos de planificación. Estos cambios conducen a cambios en el modelo de datos, etc. Obtener estos cambios de TI puede llevar demasiado tiempo.

Con respecto al conjunto de características requeridas, no hay diferencia entre los escenarios de TI y LOB. En ambos casos existe una gama completa de escenarios, desde la simple entrada de datos hasta complejas aplicaciones de planificación impulsadas por procesos que trabajan en datos masivos. Los requisitos complejos conducen a cierta complejidad en el modelo de datos y generalmente también tienen un impacto en la forma en que se manejarán los procesos de datos y planificación en la aplicación. Por lo general, se necesitan expertos para diseñar y mantener estos modelos de datos y, por lo tanto, la base de las aplicaciones de planificación. Esta complejidad inherente puede ocultarse hasta cierto punto al tomar decisiones de diseño basadas en el conjunto de características requeridas. Entonces, para el usuario final, la aplicación puede ser fácil de usar. Pero al final existe la ley de conservación de la complejidad. Esto significa que no existe la solución uno se ajusta a todos. Pero esto no significa que LOB no tenga la capacidad de ajustar / ampliar y controlar los procesos de planificación (de hecho, eso también forma parte de su trabajo). ¿Cómo es esto posible?

El tipo de entorno BPC embedded se inventó para resolver el tipo de requisitos anterior mediante un concepto de extensión, es decir, mejorar los objetos BW de modo que las extensiones propiedad de LOB de objetos BW también sean posibles. El principio rector es: ¡no copie los datos! Esto significa, antes que nada, usar los objetos y las características de BW. Por lo tanto, uno necesita modelos de datos BW-IP / PAK y motores. En segundo lugar, mejore los objetos centrales de BW mediante extensiones propiedad de LOB. Aquí hay unos ejemplos:

  • Los datos maestros BW pueden ampliarse mediante el maestro propiedad de LOB (nuevos valores, nuevos atributos; en InfoProviders propiedad de LOB, los valores LOB ganan)
  • Lo mismo para las jerarquías BW
  • InfoProviders propiedad de LOB
  • Las autorizaciones de datos de transacción son otorgadas por TI de manera central (por ejemplo, un sandbox) y dentro de este rango controlado por TI, son posibles restricciones controladas por LOB.
  • … y muchos más objetos BW con suerte admitirán un concepto de extensión LOB en el futuro …

Cuatro de las características mencionadas anteriormente ya existen en BPC 10.1. Además, también se reutilizarán los conceptos BPC de larga data en BPC embedded si esto se ajusta conceptualmente, tome el estado del trabajo y los BPF como ejemplos.

Para resumir, BPC embedded está diseñado para reutilizar los modelos de datos BW como base en un nuevo tipo de Entorno BPC. Estos modelos de datos se pueden mejorar mediante extensiones de objetos BW propiedad de LOB. Técnicamente estas mejoras pertenecen físicamente a entornos BPC o modelos BPC. Este concepto permite usar BPC en el rango de escenarios de TI puro para escenarios puros propiedad de LOB y cualquier cosa intermedia.

Pero ahora es el momento de profundizar y comparar modelos de datos en BPC estándar y BPC embedded.

Modelos de datos

Los modelos de datos generalmente tienen una visibilidad. En un sistema BW, todos los InfoObjects e InfoProviders tienen una visibilidad global. Por favor, no confundas esto con las autorizaciones. Con “visibilidad” aquí me refiero a lo siguiente: en BW no existe un “contenedor” que no sea el sistema BW en sí, donde los objetos BW pertenecen físicamente.

Contenedor

En Estándar BPC existen dos contenedores físicos como se menciona en la introducción, el Ambiente BPC para aplicaciones de planificación de grupo y otro contenedor para los objetos específicos de una aplicación de planificación (por ejemplo, el BW InfoCube generado, tabla de estado de trabajo). Este último es el Modelo BPC (es decir, la aplicación de planificación).

Estos contenedores son contenedores físicos en el sentido de que un objeto X en Entorno BPC E1 está compuesto a E1. No tiene sentido hablar sobre el objeto X en un E2 Entorno BPC diferente.

En BPC embedded, estos dos contenedores todavía existen, pero los objetos BW solo se asignarán a un Modelo BPC (y, por lo tanto, implícitamente también a un Entorno BPC). No hay dependencia física. De todos modos, esto es claro ya que uno quiere reutilizar el modelo de datos de BW como base (¡sin copia!). Por cierto, esta tarea también es la forma técnica de hacer que los objetos BW existentes sean sensibles a las características BPC, como el estado del trabajo. Pero las extensiones controladas por LOB mencionadas en la sección 2 pertenecen físicamente a uno de los contenedores BPC.

Objetos básicos

En la planificación (y presentación de informes), uno está interesado en los valores (no solo en los números) en función de un conjunto modelado de dimensiones. Tome Ingresos por Año fiscal, Versión, Producto y Cliente o Clasificación A, B o C por Año fiscal, Versión y Cliente según Ingresos.

En estándar BPC los objetos que representan los valores se llaman medidas, las dimensiones se llaman dimensiones. BW utiliza las cifras y características de las nociones, respectivamente. En clientes (Admin-Client, EPM Add-In), los objetos BPC embedded usan la terminología BPC estándar para las razones de coherencia de UI.

Estándar BPC

Hay cuatro dimensiones especiales (de hecho, tipos de dimensión) en estándar BPC, siguiendo el modelo CATE

  • Categoría (C) a las dimensiones del modelo para las versiones
  • Cuenta (A); esta dimensión especial representa las medidas. Solo hay una medida técnica (cifra clave) en la capa BW para los valores numéricos.
  • Tiempo (T) para modelar la dimensión de tiempo
  • Entity (E) está motivado a modelar partes de compañías para su consolidación

Estas dimensiones y sus atributos se utilizan principalmente para implementar la lógica comercial necesaria, por ejemplo, para una aplicación de planificación financiera o consolidación. El uso de la dimensión de la cuenta para representar las medidas generalmente se denomina modelo de cuenta. Las otras dimensiones en BPC estándar son de naturaleza puramente genérica.

No existe un concepto de dimensiones compuestas (características). Las jerarquías contienen solo miembros de dimensión de la característica base de la jerarquía. Esto corresponde a las jerarquías BW con nodos postables.

BPC embedded

Dado que aquí se usan modelos de datos BW, todas las dimensiones (características) son de naturaleza genérica, excepto las 13 dimensiones de tiempo y las dimensiones unidad / moneda. Las dimensiones de tiempo conocen el calendario y también los años fiscales. Estos conceptos provienen de Business Suite (consulte la variante del año fiscal).

Las medidas (cifras clave) son de tipo cantidad (consulte la característica de una moneda), cantidad (consulte la característica de la unidad), tipo de número, fecha u hora.

No existe una característica especial como la “dimensión de la cuenta”, por lo que los modelos de datos de BW pueden basarse en un modelo de clave, un modelo de cuenta o una combinación de ambos modelos. Esto depende de cómo se usan e interpretan las características en el modelo de datos y en las consultas de BW.

Las características compuestas son compatibles. Las jerarquías pueden contener miembros de la característica base de jerarquía, valores de características externas y nodos de texto.

Concepto

Estándar BPC

BPC integrado

Representación de dimensiones Dimensiones, modelo CATE:

  • Categoría (versión)
  • Una cuenta (para modelar las medidas)
  • Time (nada que ver con las características de tiempo BW)
  • Entidad (principalmente consolidación)
  • Más dimensiones genéricas
Características

  • genérico puro, excepto
  • 13 características de tiempo (calendario, fiscal)
  • moneda / características de la unidad
Representación de valores Medida, solo una figura clave de la tecnología en BPC generó BW InfoCube Cifras clave, de varios tipos

  • importes vinculados a una característica de la moneda
  • unidades vinculadas a una característica de la unidad
  • números de varios tipos técnicos,
  • fecha y hora
Jerarquías, relaciones entre padres e hijos Jerarquías BPC, corresponden a las jerarquías BW con nodos postables Jerarquías BW,

con diferentes tipos de nodos;

además, muestra jerarquías en consultas BW

La diferencia más importante y fundamental es que en estándar BPC uno puede tener miembros base en una dimensión y también miembros calculados, por ejemplo, cuenta C = cuenta A + cuenta B. Esto nunca es posible en BPC incrustado, por definición cualquier miembro de dimensión es miembro base y no existen miembros de dimensión calculados. Esto viene del diseño de los motores de informes, en estándar BPC, este es un motor MDX y en BPC embedded, el motor analítico BW basado en consultas BW. En BPC embedded, este tipo de cálculos se pueden modelar como parte de la consulta BW utilizando BW Query Designer.

InfoProvider

InfoProviders son objetos BW con persistencia o composiciones de objetos BW con persistencia. Los InfoProviders también pueden ser virtuales, por lo que la persistencia real puede ser “externa” BW. Los InfoProviders más destacados son InfoCubes, DataStore-Objects y Multiproviders.

BPC Estándar

Este tipo de entorno BPC contiene Modelos BPC y por modelo BPC se genera un BW InfoCube. En BPC este BW InfoCube está oculto, es decir, no está expuesto directamente. Desde el punto de vista de BW, este InfoCube no tiene tiempo y unidades BW dimensions (no lo confundas con dimensión = característica). El InfoCube generado solo tiene una cifra clave (técnica) de tipo número.

Internamente, BPC también usa un Multiprovider generado que solo contiene el BW InfoCube generado para desacoplarse de otros objetos en caso de que el BW InfoCube tenga que regenerarse. Este multiproveedor tampoco está expuesto en BPC. Entonces, por modelo BPC solo hay un objeto de persistencia y ningún concepto de composición.

Write-back escribe técnicamente registros delta en el InfoCubo, siempre a la capa más baja. El concepto de valor sin asignar no se usa.

BPC embedded

Este tipo de entorno BPC contiene Modelos BPC. Se puede asignar cualquier número de BW InfoProviders (que respalden la recuperación) a un Modelo BPC. Los InfoProviders locales pertenecen físicamente al Modelo BPC. Los multiproveedores se asignan automáticamente a un Modelo de BPC si al menos uno de los proveedores de parte se asigna al Modelo de BPC. Esto también es cierto para los niveles de agregación.

Los proveedores de BW básicos soportados con write-back (proveedor de planificación para abreviar) son: InfoCubes en tiempo real, DataStore-Objects (actualización directa, planificación), proveedores locales de BW e InfoProvider virtual que implementan una interfaz de escritura.

El write -back escribe técnicamente registros delta en el InfoCube (proveedor local de información, proveedor virtual) y los registros de después de la imagen en el DataStore-Object. En cualquier caso, aquí hay un nivel de agregación y solo se rellenan los campos (características, cifras clave) del nivel de agregación. Los otros campos tienen el valor no asignado (características) o el elemento neutro (cifra clave) con respecto a la agregación estándar SUM, MIN, MAX. El uso del concepto BW-IP de las relaciones de características fuera de las características de agregación se puede derivar de las características en el nivel de agregación.

Delta

Entonces la principal diferencia es el uso del nivel de agregación junto con el concepto de valor no asignado. Además, el estándar BPC utiliza InfoCube como almacenamiento puro: no se utilizan conceptos BW, por ejemplo consistencia del tiempo con respecto a las características del tiempo BW o las características de la moneda / unidad ya que estos BW InfoObjects simplemente no existen en BPC- InfoCubes generados. La lógica de tiempo y dinero en BPC difiere de los conceptos incorporados en BW. Por el contrario, BPC embedded utiliza conceptos de BW incorporados y es compatible con más BW InfoProviders.

Restricciones

Los informes dependen de datos consistentes, y esta consistencia ya está garantizada por las aplicaciones que entregan los datos o por los procesos de ETL. La planificación no debe vincularse a modelos de datos estáticos (por ejemplo, a partir de los datos reales). Esta es la razón por la cual uno puede ajustar y ampliar los modelos de datos y construir incluso nuevos modelos de datos para la planificación. Cuando se crean y cambian los datos de planificación, el sistema debe garantizar la coherencia de los datos. Para respaldar este tipo de controles, las soluciones de planificación proporcionan algunas características para modelar restricciones.

Existen (al menos) dos tipos de restricciones:

  • Restricciones para datos persistentes, por ejemplo, los miembros de dimensión utilizados deben existir, las combinaciones de miembros de dimensión deben ser válidas, los valores para algunas medidas deben estar en algún rango (por ejemplo, el saldo es 0 para algunas cuentas).
  • Restricciones de naturaleza más temporal; en la mayoría de los casos, este es un concepto de protección de datos. Ejemplos típicos: en un plan continuo, uno no debería poder cambiar los datos en períodos de planificación previos; una versión de planificación está cerrada, ya no se permiten cambios.

A menudo también existen características del cliente para modelar “restricciones”, por ejemplo, para proteger las celdas de datos. Esta sección trata solo de restricciones del lado del servidor.

BPC estándar

Para las restricciones de tipo 1, uno puede usar Reglas BPC; este es, de hecho, un concepto para validar registros de datos basados ​​en algunas dimensiones y medidas (valores permitidos y / o rangos de valores).

Para las restricciones de tipo 2, se puede usar el Estado de trabajo BPC para evitar que los datos se modifiquen, especialmente para controlar el proceso de planificación. Para proteger los períodos en planes móviles y para bloquear (proteger) una versión son ejemplos típicos.

BPC embedded

Para las restricciones de tipo 1, se pueden usar características compuestas, por ejemplo, para modelar combinaciones válidas de valores de características. Ejemplo: Variante del año fiscal y año fiscal; otro puede ser País y Ciudad. Compuesto no puede ser cambiado fácilmente. Por lo tanto, uno puede usar relaciones características para modelar combinaciones admisibles de valores de características. En una aplicación de planificación de surtido minorista, se puede crear una relación para las características Producto y Surtido. También se pueden derivar valores característicos de otros valores característicos.

Para las restricciones de tipo 2, se pueden usar segmentos de datos. Técnicamente, este es un filtro que describe regiones de datos que no se pueden cambiar. También se

puede usar Estado de trabajo BPC.

Delta

Concepto

Estándar BPC

BPC integrado

Restricciones para la persistencia Reglas de BPC (conocidas como validaciones en otros productos);

Validaciones también pueden ser implementadas usando lógica de escritura

Relaciones características

(métodos CHECK, DERIVE, CREATE);

validaciones también pueden ser implementadas

usando FOX o funciones de planificación de salida

Protección de Datos Estado de trabajo BPC Rebanadas de datos,

Estado de trabajo BPC

(asignado a sectores de datos técnicos en tiempo de ejecución)

Motores

Los motores de informes y planificación dependen de las decisiones de diseño tomadas en el modelo de datos en el que se basan los motores. Entonces el diseño y la forma en que funcionan los motores pueden ser bastante diferentes. Tradicionalmente, en la planificación de soluciones, los motores de informes y planificación también son bastante diferentes, ya que los informes son lo primero y la planificación se agregó más tarde. Técnicamente, la planificación a menudo es más compleja ya que se necesita un manejo razonable de las transacciones y uno tiene que construir inversiones de los conceptos de informes (por ejemplo, la agregación de usos de informes, la planificación usa la desagregación). En cualquier caso, los motores de informes y planificación deben admitir muchos tipos de cálculos, aquí es donde diferentes tipos de modelos de datos conducen a motores muy diferentes.

Tome MDX como el primer ejemplo. MDX es un lenguaje de consulta para admitir el acceso a datos multidimensionales y los cálculos (informes). No funciona solo con tablas y vistas (el lenguaje de consulta que se usará aquí es SQL) pero usa Cubos con dimensiones y medidas, hay una dimensión especial como una dimensión de tiempo, y las dimensiones pueden tener jerarquías de padres e hijos. Cómo manejar todos estos objetos es construir en el mismo corazón de MDX. Que uno sea capaz de calcular dentro de una dimensión dada también es una decisión de diseño de MDX, y el motor MDX puede manejar las consecuencias de tal decisión de diseño (ver “orden de resolución” cuando los miembros calculados se usan en filas y columnas).

MDX se enfoca en los informes, las funciones de planificación realmente no existen, con algunas excepciones, por ejemplo, la desagregación. Allí tampoco se puede encontrar un concepto real para el manejo de transacciones. Los cálculos se realizan principalmente dentro del conjunto de resultados de una instrucción MDX. Por lo tanto, los cálculos se modelan en función de un modelo de cuadrícula (filas, columnas y celdas de datos). Pero al planear uno también uno debe copiar, transformar y calcular registros de datos planos. Usar un formato de cuadrícula no es óptimo en ningún caso.

Resumen

Los motores de informes y planificación se basan en las decisiones de diseño del modelo de datos; diferentes modelos a menudo conducen a diferentes motores

Los cálculos son necesarios tanto para registros de datos planos como, por supuesto, también para recuperar celdas de datos en un formato de cuadrícula (por ejemplo, conjunto de resultados MDX)

Para soportar el manejo masivo de datos (como ETL, pero también basado en lógica de negocios) uno también necesita construir en algoritmos y / o un lenguaje de script.

El manejo de transacciones como el control de concurrencia es necesario en la planificación de aplicaciones

Estándar BPC

Históricamente, los conceptos principales del estándar BPC provienen del mundo MDX. El SQE (motor de consultas compartidas) decide si los datos necesarios en un informe son fáciles de leer (solo registros planos para leer y agregar, sin cálculos) o si además de agregaciones, jerarquías y cálculos son necesarios. En el primer caso, SQE puede usar un motor de agregación simple en el segundo caso. SQE utilizará una instrucción MDX para leer y calcular datos.

Para trabajos similares a ETL, el estándar BPC usa el Administrador de datos BPC. Aquí uno también puede usar trabajos por lotes; son típicos los escenarios de carga de datos, los preparativos de los datos de planificación o los ajustes posteriores a la planificación manual que se basan en algoritmos que representan la “lógica comercial”. El BPC generado en tiempo real InfoCube no debe cambiarse al modo de carga para usar el Administrador de datos BPC. BPC también tiene un lenguaje de script para implementar la lógica comercial específica del cliente.

En estándar BPC, los cálculos se modelan en dimensiones, por lo que fórmulas son miembros de dimensión. En este sentido, las “fórmulas” se definen en el servidor. Por supuesto, también existen cálculos en el nivel del cliente, pero estamos hablando solo de conceptos utilizados en el servidor. Los cálculos también se pueden usar en un lenguaje de script; también los fragmentos MDX son compatibles allí. Además, el estándar BPC tiene mucha lógica incorporada procedente del modelo de datos. Tome los atributos de datos maestros como ejemplo y aquí el manejo de signos junto con el uso de jerarquías y el tipo de cuenta (consulte AST, LEQ, INC y manejo de EXP). Como resultado, el SQE tiene que tener en cuenta toda esta información para crear la instrucción MDX correcta para calcular los valores. Para agregar cuentas sin interpretación de la información anterior, el resultado solo incluirá “basura”.

El modelo de datos de persistencia en estándar BPC es simple, es decir, los BW InfoCubes generados por BPC tienen una cifra clave técnica. En los informes simples o formularios de entrada, por lo tanto, hay una correspondencia uno a uno de un registro en la tabla de hechos con una celda de datos en el conjunto de resultados de un informe (o formulario de entrada).

BPC embedded

BW Analytic Engine se basa en la definición de una consulta BW. La definición de consulta BW se puede considerar como una “plantilla” de todas las sentencias MDX “razonables” que se pueden usar para el “cubo de consulta” (cf. glosario). La consulta BW también contiene la definición de una vista de consulta predeterminada, es decir, cómo usar características: las características libres (corresponden al eje de página en MDX), qué características se profundizan en filas, columnas y donde se usan jerarquías BW. Esto es bastante similar a las partes correspondientes de una declaración MDX. Por otro lado, esta analogía puede ser engañosa ya que la consulta BW no es una consulta concreta (como una consulta SQL o una consulta MDX).

BW Analytic Engine prepara y optimiza las solicitudes de lectura de datos necesarias y delega el acceso a los datos al Administrador de datos BW (no debe confundirse con el Administrador de datos BPC; este último es algo diferente). BW Data Mangager luego crea consultas SQL para leer y agregar datos.

Ahora llegamos a la diferencia fundamental de MDX en comparación con BW Analytical Engine, es decir, cómo se modelan los cálculos. Los cálculos se definen y modelan en la consulta BW. La definición de consulta BW contiene las llamadas estructuras. Hay soporte para un máximo de dos estructuras, una estructura de “figura clave” y una estructura adicional opcional. Uno puede considerar una estructura como una dimensión adicional donde uno puede definir restricciones y cálculos. Por lo tanto, los miembros restringidos o miembros calculados en MDX o estándar BPC tienen que modelarse como elementos de estructura restringida o calculada en una consulta BW. También los tipos de agregación de excepción complejos se modelan en la consulta de BW, por ejemplo, cuando el orden de agregación y el cálculo de fórmulas son importantes (se toman como ejemplos el conteo y el manejo especial de la agregación de tiempo). Los cálculos especiales basados ​​en el signo de una cuenta pueden (y deben) tratarse con fórmulas en consultas BW. Esto también es cierto para los informes de YTD. Las consultas de BW son necesarias para informes y formularios de entrada.

Ahora a los algoritmos basados ​​en registros de datos planos. BPC embedded utiliza el concepto de tipos de funciones de planificación: el tipo representa el algoritmo abstracto, por ejemplo, copia, revalorización, desagregación, FOX (el lenguaje de script BW-IP). Como los algoritmos tienen parámetros, las instancias ejecutables concretas de un tipo de función de planificación se denominan funciones de planificación. Aquí se especifican los parámetros (por ejemplo, copiar desde, copiar a) (se admiten variables BW) y también el filtro para especificar los datos que se van a cambiar o los datos de referencia (solo lectura). Una función de planificación siempre se asigna a un nivel de agregación. El nivel de agregación define el conjunto de características y cifras clave que se deben cambiar.

El nivel de agregación es el concepto para poder pegar las consultas de BW y las funciones de planificación juntas y para tener un nivel bien definido donde los datos serán cambiados. Esto es especialmente importante cuando las consultas BW y las funciones de planificación se usarán juntas en libros de trabajo de Excel o aplicaciones web. El nivel de agregación brinda una estructura adicional al modelo de datos multidimensionales que permite controlar el intercambio de datos (consultas BW con funciones de planificación en ambas direcciones).

El intercambio de datos entre las consultas de BW y las funciones de planificación también se organiza con algún tipo de búfer de planificación para soportar la planificación y la simulación sin la necesidad de guardar los datos en el DB. Cf. la siguiente sección para más detalles.

Delta

Concepto

Estándar BPC

BPC integrado

Restringir valores Cuenta especial o Medida restringida. Elemento de estructura BW en una consulta BW, figura clave restringida.
Restrinja la dimensión Medida restringida, dimensión. Elemento de estructura BW en una consulta BW, elemento de estructura de la selección de tipo.
Fórmulas Medidas calculadas, miembros. Elemento de estructura BW en una consulta BW, elemento de estructura de tipo fórmula.
Jerarquía, padre e hijo Jerarquía BPC, técnico una jerarquía especial controlada por BPC. Jerarquía BW o jerarquía de visualización, el último para mostrar subtotales en filas, columnas de una manera jerárquica
Construir en lógica Construir en la lógica de la cuenta, por ejemplo, firmar, AST, LEQ, INC y EXP

Construir en la lógica del tiempo, por ejemplo, PERIÓDICO, QTD y YTD

No hay compilación en la lógica de la cuenta, tiene que ser modelado con restricciones.

Ratios y fórmulas
Jerarquías de tiempo predefinidas; pero YTD etc. tiene que ser modelado a través de figuras clave restringidas.

ETL BPC Data Manager, funciona también en modo de planificación InfoCube en tiempo real en modo de carga: WHM

InfoCube en tiempo real en modo de planificación: funciones de planificación

Algoritmos de planificación Se entregó BPC Script Logic o funcionalidad incorporada como la desagregación Entregados tipos de funciones de planificación o funcionalidad incorporada como la desagregación y las fórmulas inversas
Lenguaje de script BPC Script Logic FOX, un tipo de función de planificación.
Respóndeme En el nivel más bajo del BPC InfoCube generado por BPC En el nivel definido por el nivel de agregación para todos.

InfoSoporte compatible con BW-IP / PAK

Concepto de transacción

Con un tipo de arquitectura cliente-servidor, uno tiene que decidir si se usa un modelo de programación sin estado o con estado. Ejemplos de aplicaciones sin estado son la mayoría de las aplicaciones web; las aplicaciones con estado son útiles cuando se necesitan simulaciones sobre la marcha sin almacenar resultados intermedios en la base de datos. El concepto de manejo de transacciones y en cola también depende de la decisión de diseño de una aplicación sin estado o con estado.

En una aplicación de planificación sin estado, por lo general, solo recupera los datos necesarios para un “paso de interacción” o, en el otro extremo, todos los datos que pueda necesitar en la aplicación. Los datos de lectura generalmente se almacenarán en el cliente (un cliente plano es el último caso). Pero la esencia aquí es que la información disponible en el cliente es suficiente para escribir los datos modificados en el DB solo en base a los datos conocidos en el cliente y los datos persistentes disponibles en el servidor. En otras palabras, no se requieren tipos de datos almacenados en la sesión del usuario (en el servidor).

Las aplicaciones de planificación con estado usan estado en la sesión del usuario (en el servidor), es decir, en la información de ida y vuelta del servidor se leerá, almacenará en el búfer y tal vez se modifique. Los cambios se realizan solo en la sesión del usuario que no está en la base de datos. Este es un tipo de escenarios de simulación, pero también el rendimiento puede beneficiarse de dicho diseño, ya que los recursos pueden requerirse solo una vez en la sesión del usuario.

Las aplicaciones sin estado frente a las con estado también suelen diferir con respecto al control de concurrencia. En cualquier caso, uno debe tener un concepto de bloqueo de datos de transacción (ver el concepto de enqueue de SAP) para evitar datos incoherentes cuando dos usuarios diferentes cambian la misma región de datos al mismo tiempo.

Estándar BPC

El estándar BPC usa un modelo de programación sin estado. Los registros de datos leídos no están protegidos por enqueues de SAP, es decir, en dos sesiones de usuario pueden cambiarse los mismos registros de datos. Solo el intervalo de tiempo necesario para procesar Enviar (es decir, guardar en DB) estará protegido por enqueues de SAP (utilizando el servidor en secuencia de planificación BW). El intervalo de tiempo se define por el tiempo para calcular los registros delta que se guardarán más el tiempo para escribir los registros de datos en el InfoCubo. La lógica implementada es: la última gana. Las simulaciones son posibles, pero hay que guardar datos intermedios en DB (enviar y actualizar).

Manejo de errores

Con respecto a los datos modificados, el sistema filtra los registros inconsistentes; registros consistentes se pueden guardar, los registros inconsistentes no se pueden guardar en la base de datos.

BPC embedded

BPC embedded usa un modelo de programación con estado. Desde el contexto de los objetos de planificación, el sistema siempre sabe que las regiones de datos que se utilizarán en modo de cambio o en modo de visualización.

  • Región de datos en modo de cambio: definida por el filtro (estático) de una consulta BW y elementos de estructura listos para la entrada; en una función de planificación, el filtro solía ejecutar la función de planificación.
  • Región de datos en modo de lectura: definida por el filtro (estático) de una consulta de BW y los elementos de estructura de visualización solamente; en una función de planificación, este es el filtro utilizado para ejecutar la función de planificación fusionada con los datos de referencia. Los datos de referencia provienen de los parámetros de la función de planificación, tome copiar de como ejemplo.

Los datos en modo de cambio estarán protegidos por bloqueos exclusivos, los datos de referencia en una función de planificación estarán protegidos por bloqueos compartidos (consulte el concepto SAP en cola). La región de datos bloqueada se describe mediante filtros (técnicamente tablas de selección), es decir, BPC incrustado no utiliza bloqueos tipo DB en los registros de DB, sino una descripción de las regiones de datos a bloquear. Este mecanismo protege los registros existentes, así como los registros que se crearán en la sesión de planificación.

Este concepto permite almacenar datos ya leídos y datos modificados en la sesión del usuario. BPC embedded utiliza los siguientes búfers

Tampón de planificación: almacena en búfer las solicitudes verdes de un InfoCubo, técnicamente el búfer es el caché OLAP; esto es un buffer para datos persistentes

Buffer Delta: los buffers han cambiado los registros en forma de registros delta para todos los InfoProviders básicos que admiten un manejo delta, por ejemplo, InfoCubes

Buffer After-Image: los buffers cambiaron los registros de forma lógica en forma de registros posteriores a la imagen para la planificación habilitada DataStore-Objects

Como resultado, en BPC embedded los clientes proporcionan dos botones para procesar datos modificados: Transferir y Enviar:

  • Transferir: verifica los datos modificados y ejecuta el algoritmo para procesar los datos modificados; escribir cambios en los búferes delta o imagen posterior. Todas las consultas de BW (listas para entrada o no) o las funciones de planificación en la misma sesión de usuario mostrarán / utilizarán los datos de sesión más recientes automáticamente. También se puede volver a los últimos datos guardados en la base de datos mediante Reset.
  • Enviar, es decir, guardar datos en DB. Técnicamente, los registros delta se tomarán del delta o buffer de imagen posterior y se guardarán en DB. Se lanzarán bloqueos y se establecerán nuevos para las consultas BW que aún se usan en modo cambio en la aplicación de planificación.

Supongamos que el usuario U1 ha adquirido un bloqueo exclusivo para la región de datos F1 (filtro). Un usuario U2 que trabaje en regiones de datos superpuestas F2 protegidas por bloqueos exclusivos (datos en modo de cambio) tendrá un conflicto de bloqueo. Entonces, el primer usuario U1 adquiere el recurso y puede cambiar / crear datos en la región de fecha definida por el filtro F1. El segundo usuario U2 no puede cambiar los datos de todos los filtros F que se superponen con el filtro F1: una consulta cambiará al modo de visualización, una función de planificación enviará un mensaje de error.

Manejo de errores

Con respecto a escribir en el búfer delta o imagen posterior, el diseño es un concepto de “todo o nada”. Esto también es cierto para guardar en DB. Lo que está en el búfer delta o en la imagen posterior se considera consistente. Excepción: una función de planificación se ejecuta antes de guardar en DB.

Observación

No confunda los datos bloqueados con estado de trabajo BPC o celdas bloqueadas. Bloquear como se usa arriba significa bloqueos de datos de transacción (véase el concepto de enqueue de SAP), es decir, el concepto en cola del servidor de enqueue de planificación de BW.

Delta

Concepto

Estándar BPC

BPC integrado

Estado del servidor Apátrida Con estado
SAP Enqueue Leído: No

Guardar: Sí, exclusivo en el intervalo de tiempo

computación delta + guardar en DB

Leer: Sí

Modo de cambio: exclusivo

Modo de lectura: compartido

Guardar: no se necesitan bloqueos; suelte bloqueos, vuelva a bloquear los recursos necesarios

Región de datos bloqueados Solo en guardar en DB, extraído de registros modificados,

es decir, tabla de selección computada que contiene todos los cambios

archivos

Efecto: la última gana

Basado en filtro y datos de referencia (función de planificación)

y filtro y definición de consulta BW

(propiedad lista para entrada de elementos de estructura en una consulta).

Efecto: solo un usuario puede cambiar los datos de la región de datos especificada

Bloquear servidor Enqueue server: BW planning Enqueue server: BW planning
Buffers de datos de transacción No Sí:

Tampón de planificación: solicitudes verdes (InfoCube)

Buffer Delta: registros delta de sesión de usuario

Buffer después de la imagen: registros de la imagen del usuario después de la imagen

Simulación A través de guardar en DB A través de transferencia.

Los datos de la sesión se tendrán en cuenta en las funciones de planificación y

Consultas BW, no es necesario guardar en DB.

Restablecer al último estado guardado posible

Manejo de errores Commit en DB para registros de datos consistentes,

registros inconsistentes no se guardarán

Escriba en el delta o en el contenido de la memoria intermedia después de la imagen usando todo o

nada principio, es decir, todos los registros cambiados / nuevos tienen que ser coherentes

para escribir en el delta o buffer de imagen posterior.

Los datos en el buffer Delta o After-Image se consideran consistentes

y se puede guardar en DB.

Excepción: función de planificación antes de guardar en DB

Glosario

La terminología en negrita se explica en este glosario.

  • BPC
    embedded: el tipo de “entorno BPC” utilizado cuando los objetos BW-IP / PAK están expuestos en BPC
  • Estándar
    BPC: el tipo entorno BPC utilizado cuando ningún objeto BW está expuesto directamente; todos los objetos BW son generados y controlados por BPC
  • BPF: flujo de proceso empresarial; un concepto para crear listas de tareas y asignar tareas a los usuarios; permite agrupar tareas de planificación
  • BW: Business Warehouse
  • BW Analytic Engine: el motor analítico lee, agrega y calcula los datos en función de las consultas de BW
  • Nivel de agregación de BW: un subconjunto de características y cifras clave del InfoProvider subyacente; es un concepto para agregar estructura a un InfoProvider. Se usa en BW-IP para definir los campos que se van a cambiar en el InfoProvider subyacente.
  • Dimensión BW: un conjunto de características en un InfoCubo, generalmente relacionado semánticamente; parte de la definición de InfoCube
  • BW Enqueue Server: infraestructura de servidor utilizada para implementar un concepto de enqueue para registros de datos de transacciones basados ​​en regiones de datos definidas en tablas de selección
  • Jerarquía BW: estructura los valores de las características de forma jerárquica (padre, hijo). Definido con respecto a una característica, la característica base. La jerarquía interna (nodos con elementos secundarios) que son valores de datos maestros de la característica base se denominan nodos postables
  • BW-IP: planificación integrada de BW
  • BW-IP Data Slice: un filtro que define una región de datos protegida; registros en esta región de datos no pueden ser cambiados
  • Multiproveedor BW: una unión de InfoSituarios basados ​​en BW
  • Consulta BW: una definición para leer, agregar datos de InfoProviders y hacer cálculos con datos; tiene también una parte visual, es decir, el diseño del conjunto de resultados inicial (filas, columnas). Una analogía aproximada es considerar una consulta BW como una plantilla para todas las sentencias MDX razonables que uno pueda crear para obtener conjuntos de resultados de un cubo de consulta. Las consultas BW son la base del motor analítico BW
  • CATE: Categoría, Cuenta, Tiempo, Entidad
  • Características compuestas: las características pueden depender de otras características, por lo que solo la combinación tiene un significado, por ejemplo, el año fiscal depende de la variante del año fiscal
  • Desagregación: también de distribución descendente, es decir, tomando valores agregados y para distribuir los valores a niveles inferiores usando factores de peso
  • Variante del año fiscal: define las propiedades de los años fiscales, por ejemplo, el mapeo de los períodos contables a intervalos de días calendario, el número de períodos contables, los turnos anuales de los períodos contables, cf. transacción GVAR
  • ETL: carga de transformación de extracto
  • Lenguaje de script FOX: BW-IP / PAK, técnicamente un tipo de función de planificación. FOX viene de la extensión de fórmula.
  • Solicitud verde: un InfoCube en tiempo real puede tener solicitudes verdes y amarillas; las solicitudes verdes provienen de datos cargados, por ejemplo, utilizando WHM, o de solicitudes amarillas cerradas. Para evitar demasiadas solicitudes, los InfoCubes en tiempo real tienen una solicitud amarilla que se cierra después de una “marca de agua” de los registros delta contenidos en la solicitud. Las solicitudes verdes pueden estar contenidas en el buffer de planificación; las solicitudes amarillas nunca se almacenan (ni se pueden) en el búfer de planificación.
  • InfoCube: Un BW InfoProvider con persistencia. Utiliza un diseño de “solo inserción” y está optimizado para manejar registros delta.
  • InfoCube, en tiempo real: Un BW InfoCube, optimizado para la recuperación. En el modo de carga uno puede usar WHM para cargar datos, en el modo de planificación uno puede usar las funciones de planificación BW-IP / PAK y las consultas de entrada para escribir datos en el InfoCubo.
  • InfoObjeto: objeto básico de BW, a saber, características y cifras clave
  • InfoSitio: abstracción BW de una persistencia de datos BW o una composición de persistencia de datos
  • Fórmulas inversas: concepto utilizado en las consultas BW listas para la entrada para hacer que las fórmulas estén listas para la entrada y para volver a calcular los operandos de la fórmula
  • LOB: línea de negocio
  • MDX: Expresiones multidimensionales, un lenguaje de consulta diseñado para el acceso a datos multidimensionales y cálculos
  • Caché OLAP: Un caché que contiene datos de transacciones persistentes basados ​​en una definición de consulta BW y una solicitud de lectura de datos; contiene generalmente datos agregados en una forma optimizada necesaria para BW Analytic Engine (también llamado BW OLAP)
  • PAK: Planning Application Kit, es decir, la tecnología utilizada para ejecutar algoritmos BW-IP directamente en SAP HANA
  • SAP Enqueue Server: infraestructura del servidor para implementar el concepto SAP en cola. Admite principalmente enqueues basadas en registros. El servidor en cola de SAP es utilizado por BW en cola servidor para implementar en cola basado en regiones de datos, es decir, tablas de selección
  • Lógica de script: lenguaje de script BPC utilizado en BPC estándar
  • Stateful: Estado del servidor se mantiene entre los recorridos de ida y vuelta del servidor cliente, p. Ej., Memoria intermedia de metadatos, datos de transacción y en cola
  • Sin Estado: No estado del servidor se mantiene entre ida y vuelta cliente-servidor
  • Elemento de estructura: este es un elemento en una estructura de una consulta BW; puede ser de tipo selección o fórmula
  • Query Cube: Virtual cube definido por el filtro (estático) de una consulta BW. Este es un objeto de tiempo de ejecución.
  • Valor no asignado: en BW todas las características admiten el valor no asignado (representación externa #); el valor no asignado es siempre un valor de datos maestros válido; este valor representa el valor resto; este diseño es muy útil para trabajar con registros delta
  • Sesión de usuario, también llamada sesión de planificación: concepto de servidor que representa el “estado del servidor” asignado a un usuario. En el servidor ABAP esta es la llamada sesión interna, cf. Documentación de palabras clave ABAP (Descripción general ABAP-> Organización de memoria ABAP – Descripción general -> Organización general de la memoria).
  • WHM: gestión de almacenes
  • YTD: año hasta la fecha

Información sobre BPC standard y BPC embedded en general:
Unificación de BPC NW y BW-IP
Preguntas frecuentes sobre SAP BPC 10.1 NW

Un pequeño ejemplo de cómo usar fórmulas inversas:
BW730: Fórmulas de entrada preparada en BW Integrated Planning

Información sobre el servidor SAP Enqueue:
Relación entre bloqueos SAP y bloqueos de base de datos

BW Enqueue Server (utilizado en BW-IP y BPC), información general y tamaño: http://service.sap.com/sap/support/notes/928044

Fuente: https://blogs.sap.com/2014/10/21/concepts-compared-bpc-standard-and-bpc-embedded/

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog de WordPress.com.

Subir ↑

A %d blogueros les gusta esto: