/
Configuración de las transformaciones XML de entrada

Configuración de las transformaciones XML de entrada

Transacción /EDGE/FC_SPRO → Carpeta de configuración "Transformaciones".

A través de esta opción es posible realizar el mapeo del XML a estructuras ABAP.

Parte de la base que previamente se importó el XSD, del XML que se quiere transformar, dentro de un WSDL a la instancia ABAP como un proxy ABAP. El procedimiento es el siguiente:

  • Importar la definición del XML, es decir, el XSD, como un WSDL al sistema SAP, de tal forma que se creen los proxies necesarios como si se estuviera publicando un servicio. Esta actividad solo se realiza una vez y debe ser transportada a cada ambiente. La idea es que el Framework ABAP genere una clase y una interfaz con un método, donde al método le entre como único parámetro la definición tal cual del XML. De esta forma se haría uso de herramientas estándar para deserializar el XML y colocarlo en una estructura más simple ABAP.

El proxy creado, genera una estructura ABAP de entrada al método; esa estructura es la que se utiliza para recorrer el XML y para configurar el mapeo.

Para tener más claridad al respecto, a continuación se muestra el proxy creado para la facturación electrónica de Costa Rica, donde se crearon varias operaciones en el WSDL, cada una con un XML que se utilizaría dentro del proceso tanto de emisión como de recepción:

Para el caso de recepción donde se utiliza la transformación XML, se generó la siguiente estructura:

Por lo tanto, con base en la estructura anterior, se hace el mapeo funcional desde la herramienta de configuración que se está describiendo.

El mapeo que se describirá se basa en el hecho de dejar al final en dos estructuras ABAP la información del XML. Una estructura de cabecera y otra de detalle.

A continuación, se describe la primera parte de la configuración, la cual está relacionada con la creación de los datos básicos para la transformación. Columnas:

  • Transform.
    Código de la transformación.


  • Nombre de la transformación
    Descripción o nombre de la transformación.


  • Nodo raíz del documento XML
    Por lo regular los XML comienzan a partir de un nodo raíz o padre. Si ese es el caso para la transformación que se requiere construir, aquí se debe indicar el nombre del nodo raíz. Por ejemplo, para Colombia el nodo raíz era INVOICE, sin embargo para Costa Rica no existe nodo raíz, ya que el elemento más externo del XML es el mensaje en si; por lo tanto, no se indicó nodo raíz.


  • Nodo ítem
    Corresponde al nodo con ocurrencia de 0..n o de 1..n y que en ABAp se representa con una tabla interna, el cual contiene las líneas, detalle o posiciones de la factura.
    Si para llegar el nodo ítem se requiere navegar entre otras estructuras; estas se deben separar con un guión.

A continuación, se muestra un ejemplo de esta configuración:

La segunda configuración que se debe realizar, es el mapeo como tal de los campos. Para entender el proceso de mapeo, es necesario tener en cuenta las siguientes premisas:

  • El resultado del mapeo son dos estructuras. Una para cabecera y otra para posiciones.


  • La estructura de cabecera tiene la siguiente disposición y tipo:
    Tipo: /EDGE/FC_ST_PROPERTY
    Disposición:


    Cuando a nivel de cabecera se está mapeando un nodo que es una lista, se tienen dos opciones:
    1. Indicar cuál registro de la lista se va a obtener, esto se hace con los símbolos [n]; donde n es igual a la posicón o registro que se quiere obtener.
    2. No se indican los símbolos anteriores, entonces el motor de transformación repite el mismo nodo en la estructura tantas veces como registros encuentra en la lista.


  • La estructura de cabecera tiene la siguiente disposición y tipo:
    Tipo: /EDGE/FC_ST_PROPERTY_ITEM
    Disposición:


    Cuando a nivel de cabecera se está mapeando un nodo que es una lista, se tienen dos opciones:
    1. Indicar cuál registro de la lista se va a obtener, esto se hace con los símbolos [n]; donde n es igual a la posicón o registro que se quiere obtener.
    2. No se indican los símbolos anteriores, entonces el motor de transformación repite el mismo nodo en la estructura tantas veces como registros encuentra en la lista. Sin embargo, se mantiene el mismo ITEM (consecutivo) para que se tenga claridad de a cuál posición pertenecen los nodos que se mapearon.


A continuación, se describe la segunda parte de la configuración, la cual está relacionada con el mapeo de los campos en la transformación. Columnas (en el dynpro ABAP también está documentado con la tecla F1 el significado de cada campo):

  • Cab. o P.?
    Indicador de mapeo desde cabecera o posición.
    Si se indica cabecera, se comenzará la búsqueda en la estructura ABAP del XML a partir del nodo de cabecera.
    Si se indica ítem, entonces se buscara una a una las posiciones según la ruta de éstas definidas en la tabla maestra.


  • Consec.
    Consecutivo de asignación que indica la secuencia de asignación de los campos. Se recomienda asignarlos de 10 en 10.


  • Ruta del campo que se va a buscar
    Opcional.
    Indica la ruta del campo origen de la información que se va a extraer. Esta ruta está de acuerdo a la estructura ABAP que se generó por el proxy. Para navegar entre más de un nodo, cada nodo se separa con el otro por un guión. Ejemplo: RECEPTOR-IDENTIFICACION → en este ejemplo se comienza en el nodo RECEPTOR, luego se pasa al nodo IDENTIFICACION. 

    Cuando se está mapeando un nodo que es una lista, se tienen dos opciones:
    1. Indicar cuál registro de la lista se va a obtener, esto se hace con los símbolos [n]; donde n es igual a la posicón o registro que se quiere obtener.
    2. No se indican los símbolos anteriores, entonces el motor de transformación repite el mismo nodo en la estructura destino tantas veces como registros encuentra en la lista. Sin embargo, cuando se mapeando a las posiciones, se mantiene el mismo ITEM (consecutivo) para que se tenga claridad de a cuál posición pertenecen los nodos que se mapearon.

    Si está mapeando información de la cabecera y ésta no contiene un nodo raíz, y la información que se requiere obtener está directamente en un campo sin nodo padre, entonces no es necesario indicar nada en esta columna.


  • Nombre del campo que se va a obtener
    Opcional
    Corresponde al nombre del campo dentro de la ruta final que se indicó en la columan anterior, desde donde se va a obtener la información.


  • Campo destino al cual se asignará el val
    Obligatorio.
    Nombre del campo que se va a crear en la estructura properties que se mencionó anteriormente.
    Si se quiere llevar el campo a la tabla de la factura para que pueda ser tenido en cuenta en el monitor o para utilizarlo en otros proceso o fucnionalidades; se debe anteponer una arroba @. De esta forma el paso de guardar datos extras (/EDGE/CL_FC_SAVE_EXT_DATA_STEP) podrá tomar estos campos y llevarlos a la tabla de la factura. Se recomienda verificar el capítulo "Configuración del monitor o reporte de cada proceso" para validar la forma de cómo agregar nuevos campos al monitor.


  • Tom.Vacío?
    Indica si al realizar la búsqueda de la información en el nodo y campo fuente, ésta no se encuentra o está vacía. Si esto sucede y este campo está chequeado, entonces al campo destino se le asigna vacío; de lo contrario el campo destino no se creará.


  • Constante
    Literal que se asignará al campo destino, siempre y cuando se haya seleccionado que el tipo de asignación es por constante.


  • Cons.ABAP de SYST
    Campos ABAP de la estructura SYST, que se le asignará al campo destino, siempre y cuando se haya seleccionado que el tipo de asignación es por constante ABAP.


  • Tipo Asig.
    Indica el tipo de asignación que se va a realizar al campo destino. Existen varios tipos de asignación:
    ' '→ Por defecto - no se tienen en cuenta las constantes
    C → Se asigna la constante en caso de estar vacío el campo o en caso de no indicar ni ruta ni campo origen.
    A → Se asigna la constante ABAP en caso de estar vacío el campo o en caso de no indicar ni ruta ni campo origen.


  • Clase ABAP
    Si se llena este campo, no importa el tipo de asignación que se haya seleccionado, el motor de transformación realizará la invocación de la clase respectiva para realizar el mapeo o asignación correspondiente. Se utiliza cuando la transformación implica una lógica más compleja que una simple asignación desde el XML.
    Esta clase debe implementar la interfaz /EDGE/IF_FC_CUST_ASSIGNMENT. El único método que debe implementar es EXECUTE_ASSIGNMENT, y éste tiene los siguientes parámetros:
    PI_ASSIGN → /EDGE/FC_TB959 → datos de la asignación que se configuró.
    PI_CURRENTNODE → ANY → puntero a la estructura del XML.
    PC_CONTEXT → /EDGE/CL_FC_CONTEXT → contexto que se comparte por todos los pasos del intérprete.
    PR_VALUES → /EDGE/FC_TT_PROPERTIES → retorno delos valores asignados o mapeados

    Actualmente existen varias implementaciones para este tipo de asignaciones con clases ABAP. Estas implementaciones son genéricas y pueden ser utilizadas en cualquier cliente. A continuación se detallan:
    /EDGE/CL_FC_EXT_CA_COMP_CODE → Permite obtener la sociedad con base en la identificación del receptor de la factura electrónica. En la configuración se debe asignar de dónde se obtiene la identificación del receptor. Igualmente se debe configurar a nivel del intérprete el parámetro COMPANY_CODE_PARAM, el cual indica el parámetro a nivel de configuración estándar donde está relacionada la sociedad con su identificación fiscal (tabla estándar SAP T001Z). También se puede indicar a nivel de configuración la constante que se debería colocar en caso que no se encuentre el código de la sociedad.
    Ejemplo de la configuración para utilizar esta asignación ABAP:


    /EDGE/CL_FC_EXT_CA_DATETIME_DA → Permite obtener de un campo en formato xsd:datetime solo la fecha en formato ABAP.

    /EDGE/CL_FC_EXT_CA_DATETIME_TI → Permite obtener de un campo en formato xsd:datetime solo la hora en formato ABAP.

    /EDGE/CL_FC_EXT_CA_VENDOR_CODE → Permite obtener el código SAP del proveedor con base en la identificación del emisor de la factura electrónica. En la configuración se debe asignar de dónde se obtiene la identificación del emisor. La consulta se hace la tabla LFA1 por el campo STCD1, bien sea igual o que al menos comience por la identificación que llega en el XML.
    Ejemplo de la configuración para utilizar esta asignación ABAP:
     

    /EDGE/CL_FC_EXT_CA_XML_IN_DATE → Obtiene la fecha de entrada del XML de la factura electrónica en formato ABAP.

    /EDGE/CL_FC_EXT_CA_XML_NAME → Obtiene el nombre del XML de la factura electrónica.


Adicional a lo descrito anteriormente, a continuación se describe un poco más en detalle la configuración de los mapeos:

Si el campo destino está vacío, no se realizará ningún mapeo o asignación.

Si la clase ABAP no está vacía, se ejecturá ésta sin realizar ninguna verificación previa. Ésta tendrá la responsabilidad de realizar la asignación o mapeo respectivo. Se podrán llenar los demás campos como ayuda para la clase que va a relaizar el mapeo. Pero únicamente el procesador de mapeos y asignaciones la ejecutará.

Si la ruta está vacía y el campo fuente está vacío se evalúa lo siguiente en el mismo orden indicado:
1. Si el indicador tomar vacío está activo, entonces se asigna vacío.
2. Si uno NO. Si el tipo de asignación igual a vacío (por defecto), entonces no se asigna nada.
3. Si dos NO. Si el tipo de asignación igual a C (por constante), entonces se le asigna constante indicada en la parametrización.
4. Si tres NO. Si el tipo de asignación igual a A (por constante ABAP), entonces se le asigna la constante ABAP indicada en la parametrización.

Si la ruta NO está vacía, entonces se busca dicha ruta en la estructura ABAP representada para el XML. En caso que en la ruta hayan listas, el usuario podrá definir cuál registro tomar de la lista con el símbolo [n], donde n es la línea que requiere obtener. Si no indica dicho símbolo, el sistema recoletará todos los datos de dicha lista con el mismo nombre del campo destino.

Si al encontrar el dato en la estructura ABAP, éste está vacío, entonces se verifica si el usuario marcó "tomar vacío", si es así, entonces se aplican las mismas reglas mencionadas para el caso en que "la ruta está vacía y el campo fuente está vacío".

Como premisa general se entiende que si se va a buscar un campo en una estructura ABAP que representa un XML, siemre debe existir la estructura que corresponde a la ruta y el campo que se debe obtener dentro de la estructura que corresponde al campo fuente.

Avvale 2024