Información de contexto

Con la migración a SAP BW/4HANA, el sistema de origen de tipo «Servicio web» no está disponible. Y aquí viene una nueva capacidad de «interfaz de escritura» para objetos DataStore que permite insertar datos en tablas de cola entrantes de objetos de almacenamiento de datos intermedios y objetos de almacenamiento de datos estándar, reemplazando la capacidad de inserción de tablas PSA de fuentes de datos de sistemas fuente de servicios web. Ver Nota SAP 2441826 – BW4SL y BWbridgeSL – Sistemas de origen de servicios web.

Hay dos escenarios de carga admitidos a través de la interfaz de escritura:

1. Para cada llamada, se abre una nueva solicitud interna («One-step»), es decir, BW abre y cierra internamente una Solicitud RSPM alrededor de los registros transferidos.
2. El sistema externo administra la Solicitud RSPM explícitamente y envía Paquetes de Datos a esta Solicitud («Escribir en la Solicitud»), es decir, el sistema externo abre la Solicitud RSPM, n veces envía datos (con información sobre la solicitud y el paquete) y la cierra.

Para los sistemas que tienen datos nuevos que llegan con una frecuencia baja, puede usar el procedimiento de «Un paso». Cada vez que llega un conjunto de nuevos registros de datos, se envían al sistema BW y se genera una solicitud RSPM.

Para los sistemas que reciben datos nuevos con una frecuencia alta (con un volumen bajo), puede usar el procedimiento «Escribir en solicitud», primero abra una solicitud RSPM y, cada vez que lleguen datos nuevos, envíe los datos con la solicitud correspondiente y paquete, y cierre la solicitud al final.

“Escribir en solicitud” requiere que el sistema externo administre la solicitud RSPM y sepa cómo empaquetar los registros de datos. Sin embargo, si se encuentra en una situación en la que hay datos de alta frecuencia y bajo volumen, pero el sistema externo no tiene la capacidad de manejar las solicitudes de RSPM y tiene que usar el envío de datos de «un paso», donde cada llamada crea un nueva solicitud RSPM. Esto dará como resultado que se generen demasiadas solicitudes RSPM en un período breve. Tenga en cuenta que, por lo general, una gran cantidad de solicitudes de RSPM (varios miles de solicitudes en los mismos objetos del almacén de datos) requieren la ejecución de la limpieza de RSPM para evitar más problemas de rendimiento.

Para evitar esta limitación de rendimiento causada por muchas solicitudes de RSPM generadas por el envío de datos de «un paso», puede considerar tener un objeto alternativo en el que pueda escribir datos y usarlos para el almacenamiento temporal de datos y cargar los datos necesarios desde este objeto. a través de Fuente de datos.

ODP CDS DataSource basado en ABAP CDS View

En este caso, necesitaríamos crear una vista ABAP CDS y, primero, aceptar los datos entrantes de alta frecuencia aquí (en la tabla subyacente), luego generar una fuente de datos ODP CDS basada en esta vista ABAP CDS y cargar datos desde la fuente de datos. con la frecuencia personalizada. De esta manera, puede evitar que se generen demasiadas solicitudes RSPM en un período breve para el ADSO de destino. Además, la cadena de procesos que carga datos desde la vista ABAP CDS se puede ejecutar con frecuencia de acuerdo con los requisitos comerciales. Por ejemplo, cada hora.

La vista ABAP CDS y el DataSource actúan como una tabla de entrada adicional (sin que se genere una solicitud) para este ADSO. Entonces, en lugar de escribir datos directamente en el ADSO de destino, el sistema primero escribe datos en la tabla subyacente de la vista ABAP CDS y el sistema BW carga datos del ODP que representa la vista ABAP CDS.

Básicamente, el procedimiento sería el siguiente:

1. Crear una tabla de base de datos. Todos los campos (excepto los campos técnicos como REQTSN, DATAPAKID, RECORD y RECORDMODE) simplemente se copian de la tabla de entrada del ADSO de destino. Además de eso, agregamos 2 campos, uno como campo clave y otro para el mecanismo delta. En el siguiente ejemplo, «RECORD_ID» se usa como campo clave y «DELTA_TIMESTAMP» se usa para el mecanismo delta.

2. Cree una vista ABAP CDS. Todavía no hay tanto esfuerzo aquí. Al usar una vista CDS, puede configurar fácilmente el mecanismo delta, así como otras configuraciones personalizadas que le gustaría tener mediante varias anotaciones. En el ejemplo, utiliza la anotación de extracción delta genérica Analytics.dataExtraction.delta.byElement.name.

Entonces, todos los demás módulos son mucho más fáciles. Dado que usamos exactamente los mismos campos que en el ADSO de destino, los campos en el origen de datos se detectan automáticamente desde la vista CDS de ABAP y las asignaciones en la transformación entre el origen de datos y el ADSO de destino se generan automáticamente con una asignación directa.

3. Crear fuente de datos ODP CDS. Dado que la función de extracción de datos ya está configurada en la vista ABAP CDS, se libera/expone automáticamente para el uso de ODP. Por lo tanto, puede crear fácilmente un ODP CDS DataSource basado en la vista ABAP CDS.

4. Crear transformación y DTP entre DataSource y ADSO de destino. Como se mencionó anteriormente, los campos en la vista ABAP CDS son los mismos que los campos en la tabla de entrada ADSO de destino. El DataSource derivado de él tiene exactamente los mismos campos que el ADSO de destino. Como resultado, el sistema los mapeará automáticamente en la transformación.

Hasta ahora, este flujo de datos ya está disponible y puede usarlo en su cadena de procesos.

En el ejemplo, tenemos un ADSO de destino llamado ADSO_0004 y tiene debajo campos clave y campos no clave.

1. Habilite la escritura en la tabla y la vista ABAP CDS

1.1 Crear una Estructura DDIC con los Campos Semánticos del ADSO

Estos campos se pueden encontrar en la tabla de entrada para DataStore ADSO_0004 /BIC/AADSO_00041. Ignore los campos clave técnicos (REQTSN, DATAPAKID y RECORD), así como el campo de modo de registro «RECORDMODE» y copie los campos semánticos (modelados) en una estructura creada en SE11.

La lista de campos de la cola de entrada de ADSO se puede copiar, como se muestra a continuación:

1.2 Crear una tabla de base de datos como cola de mensajes

Puede crear una tabla de base de datos basada en la estructura DDIC de 1.1 como include. Se debe agregar un campo de clave técnica personalizado para definir el pedido y un campo de marca de tiempo delta como el que se muestra a continuación para el procesamiento de datos.

• El campo RECORD_ID define un identificador de registro único que también define el orden sobre todos los registros.
• El campo DELTA_TIMESTAMP se usa más adelante para habilitar un delta genérico.
• El .INCLUDE contiene los campos semánticos de la estructura generada.

1.3 Crear un módulo de función RFC para recibir y almacenar el mensaje enviado

Siempre que lleguen nuevos datos con cualquier frecuencia, puede usar código como el que se muestra a continuación para escribir los nuevos registros de datos y generar un valor idéntico para el campo clave personalizado «RECORD_ID» y el campo delta «DELTA_TIMESTAMP» de la tabla.

Los datos se reciben dentro de la estructura de los campos semánticos, se modelan en 1.1 y luego se trasladan al formato de tabla de la base de datos. El orden de los datos entrantes se mantiene en los campos RECORD_ID.

Tenga en cuenta que las llamadas paralelas de esta función podrían recibir datos en paralelo, sin embargo, el orden de estas dos llamadas de función no se puede predecir, es decir, un fragmento de datos se insertaría con un RECORD_ID «más bajo» y el otro con un «más alto». ”.

Ejemplo de código

• Se utiliza un “TSN” (número de secuencia de transacción) para definir el orden de los mensajes.
• La variable l_record se usa para mantener el orden dentro de los registros enviados en una llamada de función.
• Un movimiento inválido debe reconocerse dentro del movimiento correspondiente:
  • Si se genera una excepción, estas necesidades se reconocen en el lado del remitente (como para el objeto Push Datastore).
  • Los datos deben enviarse nuevamente en caso de un error persistente o el tipo de datos, etc. debe corregirse.
• El campo no clave DELTA_TIMESTAMP se rellena de forma «redundante» para habilitar el puntero delta genérico.

FUNCTION zpush_adso_0004. 
*"---------------------------------------------------------------------- 
*"*"Local Interface: 
*"  TABLES 
*"      IT_DATA STRUCTURE  ZOT_ADSO_0004 [structure from above] 
*"  EXCEPTIONS 
*"      FAILED 
*"---------------------------------------------------------------------- 
 
  CHECK NOT it_data[] IS INITIAL. 
 
  DATA: lt_dbdata TYPE STANDARD TABLE OF zadso_0004," DB table from above   
        l_record  TYPE n LENGTH 6, 
        l_timest  TYPE rstimestmp. 
 
  DATA(l_tsn) = cl_rspm_tsn=>tsn_odq_to_bw( cl_odq_tsn=>get_tsn( ) ). 
  l_timest    = l_tsn(14). " UTC timestamp short 
 
 
  TRY. 
 
* Convert to DB structure 
      LOOP AT it_data ASSIGNING FIELD-SYMBOL(<ls_data>). 
        ADD 1 TO l_record. 
        APPEND INITIAL LINE TO lt_dbdata ASSIGNING FIELD-SYMBOL(<ls_dbdata>). 
        MOVE-CORRESPONDING <ls_data> TO <ls_dbdata>. 
        <ls_dbdata>-record_id       = |{ l_tsn(14) }{ l_tsn+14(6) }{ l_record(6) }|. 
        <ls_dbdata>-delta_timestamp = l_timest. 
      ENDLOOP. 
 
* Insert Message Records to DB 
      INSERT zadso_0004 FROM TABLE lt_dbdata. " DB table from above 
      CALL FUNCTION 'DB_COMMIT'. 
 
    CATCH cx_root INTO DATA(lrx_root). 
      CALL FUNCTION 'RS_EXCEPTION_TO_SYMSG' 
        EXPORTING 
          i_r_exception = lrx_root 
          i_deepest     = 'X'. 
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno 
              WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 
              RAISING failed. 
  ENDTRY. 
 
 
ENDFUNCTION. 

2. Procesamiento de datos dentro de objetos relacionados con BW

2.1 Cree una vista CDS ABAP con definición delta genérica en la cola de mensajes

Puede utilizar las anotaciones de análisis para habilitar la extracción de datos y el mecanismo delta en las vistas ABAP CDS. Para obtener información detallada sobre las anotaciones de análisis, consulte Anotaciones de análisis | Portal de ayuda de SAP.

En nuestro ejemplo, estamos usando Analytics.dataExtraction.habilitado para marcar la vista adecuada para la replicación de datos y Analytics.dataExtraction.delta.byElement.name para habilitar la extracción delta genérica. Vea a continuación el código de ejemplo:

@AbapCatalog.sqlViewName: 'ZADSO_0004_DS' 
@AbapCatalog.compiler.compareFilter: true 
@AbapCatalog.preserveKey: true 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'adso 4' 
@Analytics:{ dataCategory: #FACT, 
             dataExtraction: { enabled: true, 
                               delta.byElement: { name: 'DeltaTimestamp', 
                                                  maxDelayInSeconds : 60 
                                                } 
                             } 
            } 
define view ZADSO_0004_CDS 
  as select from zadso_0004 
{ 
  key record_id       as RecordId, 
      @Semantics.systemDateTime.lastChangedAt: true 
      delta_timestamp as DeltaTimestamp, 
      carrid          as Carrid, 
      connid          as Connid, 
      fldate          as Fldate, 
      bookid          as Bookid, 
      customid        as Customid, 
      custtype        as Custtype, 
      smoker          as Smoker, 
      luggweight      as Luggweight, 
      wunit           as Wunit, 
      invoice         as Invoice, 
      class           as Class, 
      forcuram        as Forcuram, 
      forcurkey       as Forcurkey, 
      loccuram        as Loccuram, 
      loccurkey       as Loccurkey, 
      order_date      as OrderDate, 
      counter         as Counter, 
      agencynum       as Agencynum, 
      cancelled       as Cancelled, 
      reserved        as Reserved, 
      passname        as Passname, 
      passform        as Passform, 
      passbirth       as Passbirth 
} 

2.2 Crear fuente de datos basada en la vista ABAP CDS

Dado que la vista ABAP CDS está habilitada para la extracción de datos, se libera/expone automáticamente para ODP. En el sistema de origen ODP (con contexto ABAP_CDS) que apunta al mismo sistema BW/4HANA, puede crear un nuevo origen de datos y seleccionar el proveedor de datos operativos correspondiente.

Después de la creación, puede encontrar que, en las propiedades de extracción, el origen de datos ya está habilitado para delta.

2.3 Crear DTP/Transformación

Luego, puede crear una transformación y un DTP para cargar datos desde DataSource al ADSO de destino.

Tenga en cuenta que no es necesario asignar los campos de clave técnica RECORD_ID y DELTATIMESTAMP, sin embargo, para aplicar el orden correcto necesitaríamos una rutina de inicio en la Transformación.

SORT source_package BY recordid ASCENDING.

Junto a una Extracción Agrupada por los campos clave de la Tabla Activa de la ADSO (en la DTP).

Todos los demás campos son solo una asignación de asignación directa, ya que son los mismos campos.

2.4 Mantener la cadena de procesos

Dependiendo de los requisitos del procesamiento posterior, puede usar una cadena de procesos por hora o por día, o cualquier otra frecuencia personalizada para ejecutar el DTP y activar los datos en el ADSO de destino.

Por lo tanto, la frecuencia de ejecución de DTP, cada una de las cuales crea una solicitud RSPM en el ADSO de destino, está completamente desacoplada de las llamadas de datos entrantes.

Además, Limpiar datos en la tabla

A medida que pasa el tiempo, los datos se acumularán en la tabla de base de datos que creamos para el almacenamiento temporal. En este caso, puede agregar un programa adicional para eliminar los datos antiguos en la tabla DB. Puede colocar el programa al final de la cadena de procesos para que cada vez que cargue y active nuevos registros de datos, los datos antiguos en la tabla de base de datos se eliminen o ejecute el programa con una configuración personalizada.

Este código de programa a continuación se puede usar para diferentes tablas de entrada y para cada variante de proceso en un proceso, debe crear una variante de programa que especifique

• el nombre de la tabla p_tab, aquí ZADSO_0004, y
• número de días después de los cuales los registros de datos se consideran obsoletos y deben eliminarse (aquí, por ejemplo, 7 días)

Por supuesto, también podría crear un programa diferente, que se especifica para cada tabla de entrada sin usar este enfoque genérico donde el nombre de la tabla se especifica mediante un parámetro.

Código de ejemplo

REPORT z_inbound_message_cleanup. 

PARAMETERS: p_tab  TYPE tabname DEFAULT '', 
            p_days TYPE i DEFAULT 7. 

PERFORM main USING p_tab 
                   p_days. 

FORM main USING i_tabname         TYPE tabname 
                i_older_than_days TYPE i. 
 
  DATA: lt_dfies TYPE STANDARD TABLE OF dfies, 
        l_now    TYPE rstimestmp, 
        l_secs   TYPE i. 
 
  CHECK i_older_than_days GT 0. 
 
  CALL FUNCTION 'DDIF_NAMETAB_GET' 
    EXPORTING 
      tabname   = i_tabname 
    TABLES 
      dfies_tab = lt_dfies 
    EXCEPTIONS 
      not_found = 1 
      OTHERS    = 2. 
  IF sy-subrc <> 0. 
    MESSAGE ID sy-msgid TYPE 'I' NUMBER sy-msgno 
            WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. 
    RETURN. 
  ELSE. 
    LOOP AT lt_dfies ASSIGNING FIELD-SYMBOL(<ls_dfies>) 
         WHERE fieldname EQ 'DELTA_TIMESTAMP'. 
      EXIT. 
    ENDLOOP. 
    IF sy-subrc NE 0. 
      MESSAGE 'No field DELTA_TIMESTAMP found' TYPE 'I'. 
      RETURN. 
    ELSEIF <ls_dfies>-inttype NE 'P'. 
      MESSAGE 'DELTA_TIMESTAMP not of type P' TYPE 'I'. 
      RETURN. 
    ENDIF. 
  ENDIF. 
 
* ---- Days to Seconds 
  l_secs = i_older_than_days * 24 * 60 * 60. 
 
* ---- Timestamp now 
  GET TIME STAMP FIELD l_now. 
 
  TRY. 
 
* ---- Timestamp 
      DATA(l_timestamp) = cl_abap_tstmp=>subtractsecs_to_short( tstmp = l_now 
                                                                secs  = l_secs ). 
 
* ---- Delete messages "older than x days" 
      DELETE FROM (i_tabname) WHERE delta_timestamp LT l_timestamp. 
      IF sy-subrc EQ 0. 
        MESSAGE |Messages older than { i_older_than_days } days deleted from table { i_tabname }| TYPE 'I'. 
      ELSE. 
        MESSAGE |No (further) messages older than { i_older_than_days } days deleted from table { i_tabname }| TYPE 'I'. 
      ENDIF. 
 
      CALL FUNCTION 'DB_COMMIT'. 
 
    CATCH cx_root INTO DATA(lrx_root). 
      CALL FUNCTION 'RS_EXCEPTION_TO_SYMSG' 
        EXPORTING 
          i_r_exception = lrx_root 
          i_deepest     = 'X'. 
      MESSAGE ID sy-msgid TYPE 'I' NUMBER sy-msgno 
              WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. 
 
      RETURN. 
  ENDTRY. 
 
ENDFORM.

Epílogo

En este artículo, utilizamos una vista ABAP CDS y un ODP CDS DataSource como una forma alternativa de lograr un procesamiento de cola de entrada de alta frecuencia. También puede considerar otras opciones, como la vista de HANA y el origen de datos de HANA, etc. Los conceptos básicos son los mismos: primero escribir los datos entrantes de alta frecuencia en un objeto temporal y luego cargar los datos de este objeto con una frecuencia adecuada.