jueves, abril 30, 2009

Reemplazar caracteres por espacios en blanco

El siguiente código reemplaza los caracteres que concuerden con las expresiones lógicas por un espacio en blanco. Nótese como la definición del espacio en blanco se realiza mediante comillas simples inversas (`), esto es así porque se trata de una expresión de "sustitución".



Significado de las expresiones:
  • GC_ISO_EXP: sustituye los caracteres típicos de ficheros XML y de texto por espacios en blanco (< >' " & ; : ¨ ^).
  • GC_LN: sustituye los caracteres que NO sean minúsculas (\l) ni mayúsculas (\u) ni numéricos (\d).
  • GC_LC: sustituye los caracteres que NO sean minúsculas (\l) ni mayúsculas (\u) ni numéricos (\d) ni el guión (-) ni la barra (/).
  • GC_LNG: sustituye los caracteres que NO sean minúsculas (\l) ni mayúsculas (\u) ni numéricos (\d) ni el guión (-) .

    La constante GC_ISO contiene los caracteres imprimibles propios del conjunto ISO 8859-1, para las pruebas.

    martes, abril 28, 2009

    Función de mapeo de usuario para decodificar un campo en Base64

    La siguiente función definida por usuario o User-Defined Function (UDF) decodifica el contenido de un campo en base64.

    decodebase64

    En este caso he utilizado la librería "sun.misc.BASE64Decoder" de la que es propietaria SUN. Podría valer cualquier otra, pero es la que utilizaban en el código de referencia que utilicé para este ejemplo: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9793

    De manera análoga se puede codificar un campo en Base64 utilizando la librería correspondiente.

    martes, marzo 24, 2009

    Comprobar conexión servidor hacia fuera

    A la hora de consumir un web service externo es necesario saber si la conexión hacia el exterior está configurara correctamente (puertos del firewall, etc.). Una manera sencilla de realizar dicha comprobación es a través de la creación de una conexión HTTP con servidor externo (tipo G) en la transacción SM59 y en la que incluiremos la dirección del servidor al que se desea acceder. Para comprobar si hay conexión bastará pulsar el botón "Test de conexión".

    test_external_server

    Una mala configuración puede provocar que se reciban timeouts a la hora de invocar el web service o que se produzcan fallos a la hora de crear el socket de comunicación...

    jueves, marzo 05, 2009

    Timeouts en escenarios síncronos

    Existen ocaciones en las que los programas que utilizamos pueden tardar mucho en función de la cantidad de datos que le vayamos a pedir. Esto puede dar lugar a que si nos encontramos en un escenario síncrono podamos obtener un timeout como respuesta.


    500 Connection timed out


    Error: -5
    Version: 7000
    Component: ICM
    Date/Time: Thu Mar 5 09:57:12 2009
    Module: icxxthr_mt.c
    Line: 2698
    Server: PI_Server
    Error Tag: {-}
    Detail: Connection to partner timed out after 60s
    © 2001-2005, SAP AG

    En mi caso, el escenario en el que se producía el error era de tipo síncrono (SOAP -> RFC). Y el timeout aparecía cuando la función tenía que recopilar demasiados datos.

    En la transacción SM21 aparece una versión más detallada del error:

    http_rfc-session-has-been-deleted-following-timeout

    Una de las maneras de ampliar el tiempo de timeout es a través de la transacción SMICM. En el menú Pasar a -> Servicios (Shift+F1) veremos que el tiempo definido para el servicio HTTP es de 60 segundos, por lo que bastará marcar dicho servicio y editarlo (menú Servicio -> Modificar) para asignarle el tiempo que deseemos.

    servicios3

    NOTA: Hay que tener en cuenta que estos cambios se perderán si se reinicia el servicio ICM, tal como notifica el siguiente mensaje:

    warning

    Una de las opciones posibles para definir de manera definitiva esta parametrización es por medio de la creación del parámetro de perfil icm/server_port_<xx> a través de la transacción RZ10. Ejemplo:

    icm/server_port_0 = PROT=HTTP,PORT=8000,TIMEOUT=30,PROCTIMEOUT=600

    Los posibles valores vienen descritos en el link Timeout Options for ICM and Web Dispatcher.

    Este parámetro se debe incluir en un fichero del sistema, por lo que deberá ser un administrador el que realice la configuración.

    Links de referencia:

      lunes, marzo 02, 2009

      Cómo Eliminar un Componente del Integration Builder

      Si por casualidad has importado desde el System Landscape Directory una versión de software de un componente por error y la deseas eliminar, deberás hacer doble clic sobre la misma y en la ventana del componente seleccionar la opción Software Component Version -> Delete (Ctrl+D).

      delete_soft_comp1

      martes, febrero 17, 2009

      Convertir Workarea a Caracteres

      En ocasiones es necesario pasar el contenido de un área de trabajo a una ristra de caracteres (sobre todo cuando se desea crear un fichero de texto a partir de una tabla interna con campos de distintos tipos). Para esos casos podremos utilizar la función estándar C147_WORKAREA_TO_CHARFIELD que nos simplificará mucho la vida.


      viernes, enero 23, 2009

      Campos de extensión de las BAPIs

      Directamente copiado del texto de ayuda de los campos ExtensionIn/Out  de las BAPIs:

      Txt.brv.
      ExtensionIn

      Description
      With the parameters ExtensionIn and ExtensionOut, it is possible to enhance the interface of a BAPI without modification to achieve the automatic processing of customer-specific data.

      The data is passed on in a table. The format of the individual data records of this table is determined via the structure BAPIPAREX. This structure contains several data record fields (VALUEPART1, VALUEPART2 etc.) and a field for the name of an auxiliary structure (STRUCTURE). Because per data record the data is written piecewise consecutively to the data record fields available for the purpose, an auxiliary structure is needed for the interpretation of the data.

      In the event that an SAP database table is to be enhanced by additional fields, BAPI table extensions are especially suitable as auxiliary structures. A BAPI table extension can either be already predefined by SAP or created by the customer. Examples of auxiliary structures and BAPI table extensions can be found at the following points:

      Description of the various customer enhancement options
      Enhancement of BAPI based on existing SAP database tables
      Enhancement of BAPI through incorporation of additional customers' own database tables
      Enhancement of BAPI by import data that does not show up the database level
      Note that only fields of the data type CHAR and similar data types may be used in the BAPI parameter ExtensionIn/ExtensionOut.

      If the customer Include contains deviating parameters, the configurable message ME 887 is invoked. However, the data is not adopted in the target structure from the container.

      Default
      The auxiliary structures have been defined as follows:

      Header data:
      BAPI_TE_MEOUTHEADER
      BAPI_TE_MEOUTHEADERX
      Item data:
      BAPI_TE_MEOUTITEM
      BAPI_TE_MEOUTITEMX
      Account assignment data:
      BAPI_TE_MEOUTACCOUNT
      BAPI_TE_MEOUTACCOUNTX

      Ejemplo:
      CLEAR le_extensionin.
      le_mepoheader-campo_extendido = <valor_del_campo>.
      le_extensionin-structure  = 'BAPI_TE_MEPOHEADER'.
      le_extensionin-valuepart1 = le_mepoheader.
      APPEND le_extensionin TO lt_extensionsin.

      CLEAR le_extensionin.
      le_mepoheaderx-campo_extendido = 'X'.
      le_extensionin-structure  = 'BAPI_TE_MEPOHEADERX'.
      le_extensionin-valuepart1 = le_mepoheaderx.
      APPEND le_extensionin TO lt_extensionsin.
        CALL FUNCTION 'BAPI_PO_CREATE1'
          EXPORTING
            poheader         = le_header
            poheaderx        = le_headerx
          IMPORTING
            exppurchaseorder = l_numdoc
          TABLES
            return           = lt_return
            poitem           = lt_items
            poitemx          = lt_itemsx
            poaccount        = lt_accounts
            poaccountx       = lt_accountsx
            extensionin      = lt_extensionsin.

      viernes, diciembre 19, 2008

      Datos SLD no se actualiza en sistema ECC

      Síntomas

      • Obtención del mensaje LCR_GET_OWN_BUSINESS_SYSTEM - NO_BUSINESS_SYSTEM al realizar una llamada a proxy desde la máquina ECC o al ejecutar la transacción SXI_CACHE desde dicha máquina. También puede verse desde la transacción SLD_CACHE.
      • La tabla LCRT_CLNTCACHE está vacía. En esta tabla es donde se recogen los datos de la SLD de la máquina XI.

        Posibles problemas

        1. El usuario de la transacción SLDAPICUST puede estar mal. El usuario que se indica en esta transacción debe estar definido en la máquina XI. Si el usuario está definido en XI y el problema está en que el password definido en la transacción SLDAPICUST de la máquina ECC está mal, lo podremos saber porque si ejecutamos la transacción SLDCHECK 3 veces  comprobamremos que en XI el usuario está bloqueado.
        2. También se recomienda comprobar que el parámetro com.sap.aii.connect.integrationserver.r3.client del perfile de integración se corresponde con el mandante del Servidor de Integración.

          Más información

            jueves, diciembre 04, 2008

            Error al enviar mensajes de ECC a XI

            Se puede dar la posibilidad de que al enviar un mensaje desde ECC a XI aparezca el error HTTP_RESP_STATUS_CODE_NOT_OK por problemas de autorización del usuario. Esto es común cuando se realizan "reseteos" de contraseñas generalizadas o se borran usuarios.

            Para registrar de manera correcta al usuario, se deberá ir a "XI" (a pesar de que la conexión es ECC -> XI) y en la transacción SICF deberemos ir al nodo default_host -> sap -> xi -> engine y haciendo doble clic sobre engine, asignaremos el usuario correspondiente.

            Mensajes asíncronos no se envían/reciben con proxies

            De entre las diferentes fuentes de las que puede proceder el problema (mala configuración del adaptador, mala configuración del escenario, no se ha actualizado la cache, etc.), se encuentra el caso en el que la cola de envío o la de recepción se encuentre saturada, generalmente porque uno de los mensajes contiene errores y no permite que el resto se ejecuten.

            El escenario del que hablo hace referencia a un tipo de comunicación proxy asíncrona (asynch) relacionada con un canal de comunicación de tipo fichero de contenido fijo (File Content Conversion). En este caso se ha programado la interfaz para que cada vez que se detecte un fichero determinado en un directorio de XI se procese y se envíe mediante proxy al sistema ERP. El problema estaba en que al dejar el fichero en el directorio, el canal de comunicación correspondiente lo procesaba adecuadamente pero el mensaje nunca llegaba al sistema ERP (existía un mensaje de envío, pero no uno de recepción).

            Existen varios modos para acceder a la cola de envío/recepción de mensajes. Uno es a través de la transacción SXMB_MONI y en la misma línea del mensaje en cuestión aparece un link, fuera de pantalla, a la derecha, a la cola en la que se encuentra. La otra manera es de manera directa a través de las transacciones SMQ1 (cola de salida) y SMQ2 (cola de entrada). Se recomienda revisar ambas colas y si se encuentran llenas bastará lanzar los mensajes ( F8 ) o eliminarlos para que los futuros mensajes de la interfaz puedan circular.

            jueves, octubre 16, 2008

            El Payload del contendido de un mensaje no aparece en el Message Monitoring

            ACTUALIZADO: por fin he encontrado la manera de registrar los mensajes síncronos en el monitor de XI. Para ello hay que ir a la transacción SXMB_ADM -> Configurar Integration Engine -> Configuración específica y añadimos el parámetro:
            • Categoría: RUNTIME
            • Parámetro: LOGGING_SYNC
            • Valor actual: 1

              Y por si acaso, también recomiendan tener el valor del TRACE_LEVEL a nivel 3.

              Referencia: https://forums.sdn.sap.com/message.jspa?messageID=4599158

              Existen tres premisas que se deben conocer relacionadas con los payloads de los mensajes gestionados por XI:
              1. Por defecto, los mensajes SÍNCRONOS no se almacenan en XI para ahorrar espacio de almacenamiento.
              2. Hasta la versión PI 7.0 no hay manera directa de configurar XI para que guarde los mensajes síncronos procesados.
              3. En la versión de PI 7.1 existe una opción de indicar al servidor que guarde los mensajes síncronos procesados y ésta se describe en el blog Display Adapter Synchronous Message Content in RWB of PI 7.1

                Respecto al punto 2, no es del todo cierto. Existe un mecanismo de archivado de mensajes que permite, mediante un job, indicar qué mensajes de qué interfaces se deseean mantener registrados en el sistema. A esta opción se accede a través de la transaccion SXMB_ADM -> Especificar interfaces para archivo y tiempos de permanencia (Define Interfaces for Archiving and Retention Periods).


                En esta pantalla definiremos qué interfaces queremos rastrear y a través del botón Retention period indicaremos los días que deseamos que permanezcan los mensajes almacenados en el sistema. Por defecto los mensajes síncronos aceptados aparecen como no almacenables (0 días), por lo que deberemos cambiarlo para que dichos mensajes queden registrados.


                Una vez realizado esto deberemos planificar el job encargado de registrar los mensajes y, por último, para poder ver los mensajes recogidos en el sistema deberemos utilizar la transacción XMS_SARA para ir al administrador de mensajes y acceder a los archivos deseados en función del día.

                Referencias:

                  martes, octubre 14, 2008

                  Eliminar Espacio de Nombres de fichero XML

                  Los ficheros XML generados por defecto en XI contienen una especificación explícita del espacio de nombres, aunque sólo exista uno.



                  En ocasiones los mensajes que nos envían vienen sin especificar dicho espacio de nombres:



                  Para otros tipos de adaptadores (Ficheros/FTP, SOAP, …) existen módulos que permiten definir/filtrar los espacios de nombres de los ficheros (mirar entrada Cambiar la codificación de caracteres de un fichero XML), pero para el adaptador XI (ABAP Proxy) no es posible utilizar módulo alguno. Para ello es necesario modificar los tipos de mensajes involucrados y dejar en blanco el campo XML Namespace.



                  Una vez hecho esto, será necesario regenerar el/los ABAP proxies correspondientes desde la máquina con la que esté conectada el servidor XI a través de la transacción SPROXY.

                  Referencias:

                    lunes, octubre 13, 2008

                    Probar un Web Service

                    Una vez publicado un Web Service (mirar esta entrada para más información), falta poder probarlo. Existen varios modos de probar el funcionamiento de los Web Services.

                    Uno de ellos es mediante el uso de herramientas externas específicas como lo son:

                      Otro modo sería a través de la herramienta SAP Web Services Navigator (for Web services created/deployed on SAP Web AS) que proporciona XI para probar sus servicios web. Esta herramienta es el Navegador de Web Services y se puede acceder a ella desde la URL http://<servidor>:<puerto_java>/wsnavigator/enterwsdl.html. En ella deberemos introducir la dirección URL del WSDL publicado en la máquina. Para conocer dónde están publicados los servicios dentro de XI deberemos ejecutar la transacción SICF y navegar por el árbol base hasta encontrar el nombre del servicio correspondiente. Por defecto la ruta de los servicios suele ser: /default_host/sap/bc/bsp/sap/. Una vez conocida su ubicación se facilitará la URL al navegador (p.ej.: http://<servidor>:<puerto>/sap/bc/bsp/sap/aplicacion_ws/servicio_web.wsdl ). Tras introducir la ubicación del fichero WSDL se nos pedirá que nos identifiquemos en el sistema XI. A continuación, una vez cargado, pulsaremos sobre la opción Test y seleccionaremos la interfaz que deseamos probar pulsando sobre ella. Por último introduciremos los datos de entrada "a mano" y al pulsar el botón Send nos devolverá el mensaje de respuesta devuelto por el servidor. Este mecanismo es más visual e intuitivo pero no es muy rentable del punto de vista funcional ya que para pruebas que necesiten introducir muchos valores serían inviables de este modo.

                      Por último, también se podría usar la página HTML cuyo código se proporciona en este link, la cual permite tanto introducir el código de petición XML a mano como a través de fichero, además de otras opciones de selección relativas al tipo de comunicación del servicio.

                      Referencias:

                        Publicar un Web Service

                        ACTUALIZACIÓN (2009/03/11) - Este artículo pretende describir los pasos necesarios para generar el archivo WSDL correspondiente al Web Service creado sin llegar a tocar la publicación del mismo en los directorios UDDI. Mediante el fichero WSDL, el sistema externo podrá conocer la estructura de los datos del servicio y la dirección de conexión del mismo, por lo que bastará con hacerles llegar dicho fichero para que se puedan conectar al servicio deseado. Si se desea conocer más acerca de la publicación del fichero en directorios UDDI se puede consultar los enlaces de referencia que se encuentran al final del artículo.

                        Una vez definido y configurado correctamente la interfaz de tipo Web Service queda publicar el servicio correspondiente.  En el Integration Builder existe un asistente que permite generar el documento WSDL necesario para que los servicios externos se puedan comunicar con el Web Service. Esta herramienta se puede encontrar en el menú Tools -> Define Web Service...


                        Lo primero por lo que te pregunta el asistente es por la URL del canal de entrada del servidor SOAP de integración (Integration Server SOAP inbound channel). Bastará pulsar el botón de proponer URL (Propouse URL) para que el asistente nos facilite una URL válida del tipo http://<servidorXI>:<http_port>/sap/xi/engine?type=entry. No se recomienda el uso de esta URL ya que, aunque es válida para conectar con el servicio, no hace uso de la capa SOAP y, por lo tanto, no es segura.  Para hacer uso de la capa SOAP, la URL debe ser del tipo  http://<host>:<java_port>/XISOAPAdapter/MessageServlet?channel=<party>:<service>:<channel> o, en el caso de no existir PARTY: http://<host>:<java_port>/XISOAPAdapter/MessageServlet?channel=:<service>:<channel> (manteniendo los ':' previos al servicio).

                        Ejemplo: http://ServidorXI:50000/XISOAPAdapter/MessageServlet?channel=:Service_BS:Sender_WS_CC

                        Para comprobar que la dirección es válida se podrá probar la URL en el navegador de Internet y, tras identificarse con un usuario con los permisos adecuados, devolverá una página con el siguiente contenido:

                        Message Servlet is in Status OK


                        Status information:

                        Servlet com.sap.aii.af.mp.soap.web.MessageServlet (Version $Id: //tc/xi/NW04S_12_REL/src/_adapters/_soap/java/com/sap/aii/af/mp/soap/web/MessageServlet.java#4 $) bound to /MessageServlet
                        Classname ModuleProcessor: null
                        Lookupname for localModuleProcessorLookupName: localejbs/ModuleProcessorBean
                        Lookupname for remoteModuleProcessorLookupName: null
                        ModuleProcessorClass not instantiated
                        ModuleProcessorLocal is Instance of com.sap.aii.af.mp.processor.ModuleProcessorLocalLocalObjectImpl0_0
                        ModuleProcessorRemote not instantiated

                        En segundo lugar se nos pedirá que indiquemos la interfaz de mensaje del Repositorio de Integración que deseamos publicar. Hay que tener en cuenta que si el que inicia el servicio es el sistema externo, la interfaz será de salida (outbound). Para seleccionarla utilizaremos el botón de ayuda que aparece junto a los campos.


                        El tercer paso consiste en indicar el sistema que inicia el servicio, en el campo Service se indicará el nombre lógico de la máquina (sistema o servicio de negocios), en el campo Interface Name indicaremos el nombre de la interfaz de mensajes que se especificó en el paso anterior y el espacio de nombres será el correspondiente a dicha interfaz.


                        Una vez introducidos los campos necesarios, pulsaremos Finish y se generará el archivo WSDL que  permitirá a los sistemas externos comunicarse con el Web Service de nuestro sistema. Para ello pulsaremos el botón SAVE y lo guardaremos en algún directorio local de nuestro equipo. Hay que tener en cuenta que el servicio web está en funcionamiento desde el momento en el que se activan los canales de comunicación, por lo que la generación del WSDL no guarda relación con la activación del mismo.

                        A continuación podremos incluir el servicio web en la Biblioteca BSP a través de la transacción SE80, pero esto no es necesario para el funcionamiento del mismo. En ella deberemos seleccionar el paquete donde deseemos vincular el servicio y con el botón derecho sobre el mismo seleccionaremos la opción Crear -> Biblioteca BSP. Seguidamente pulsaremos de nuevo con el botón derecho sobre la Biblioteca BSP recién creada y seleccionaremos la opción Crear -> Aplicación BSP y, por último, sobre la propia aplicación pulsaremos una vez más con el botón derecho del ratón y crearemos una aplicación.

                        Cada aplicación puede contener más de un Web Service definido. Para crear un WS a partir del fichero WSDL que acabamos de generar pulsaremos con el botón derecho del ratón sobre la aplicación creada y seleccionaremos la opción Crear -> Objeto MIME -> Importar y seleccionaremos el archivo WSDL que hemos creado. No hay que olvidar activar la aplicación BSP tras generar el objeto MIME para que funcione correctamente. En este caso, cada vez que se modifique la "estructura" de los componentes implicados en la interfaz será necesario generar de nuevo el fichero WSDL y actualizarlo en la aplicación de la biblioteca BSP correspondiente (activando la aplicación después de su importación).

                        Referencias:

                          UDDI:

                            sábado, octubre 11, 2008

                            Problema de conexión de SPROXY a nivel de mandante

                            Este problema me sucedió en un entorno de red filtrado por un servidor proxy. La transacción SPROXY desde un mandante determinado, el 100, funcionaba correctamente mientras que para otro mandante de la misma máquina, el 200, dicha transacción devolvía un error de conexión con el Integration Builder.

                            Para conocer el posible motivo del fallo ejecuté el test de conexión que se proporciona en la transacción SPROXY y concretamente fallaba en el tercer punto, al ejecutar el report SPROX_CHECK_IFR_RESPONSE aparecía el siguiente mensaje:



                            El problema estaba en que para el mandante 200 se había activado la parametrización del proxy mientras que para el 100 no lo estaba. Esta parametrización es dependiente del mandante y para activarla/desactivarla hay que ir a la  transacción SICF y en el menú superior ir Mandante --> Parametriz.proxy (Ctrl+F2) y desmarcar la casilla "Parametriz.proxy activa" o en su defecto se pueden definir los filtros de las direcciones correspondientes.


                            El mensaje que devolvía el report SPROX_CHECK_IFR_RESPONSE se debía a que intentaba resolver la dirección de "servidorXI" a través del proxy en vez de resolverlo a través de los registros DNS definidos en el propio servidor.

                            Cambiar la codificación de caracteres de un fichero XML

                            Por defecto XI genera los mensajes XML en formato UTF-8. Para que estos se codifiquen en otro formato como el ISO-8859-1 habrá que configurar el adaptador receptor para que éste se encargue de hacerlo.

                            Como ejemplo se mostrará la configuración para un receptor de tipo fichero. Para lograr que el “contenido” del fichero se muestre en formato ISO-8859-1 se necesita añadir un módulo específico al adaptador que se encarga de realizar la conversión, entre otras cosas. En el caso de los ficheros XML, para que el módulo pueda procesar el contenido del fichero éste deberá ser de tipo BINARIO, de otro modo se producirá una excepción a la hora de procesar el fichero diciendo que el fichero pasado no se encuentra en el formato correcto. Esta restricción queda especificada en el enlace Configuring the Receiver File/FTP Adapter, en el apartado "Select the File Type of the document".



                            En la pestaña Module del adaptador se inserta el módulo AF_Modules/XMLAnonymizerBean en una posición anterior al módulo CallSapAdapter ya que de lo contrario se enviaría el fichero antes de procesarlo.

                            file_adapter_module

                            Una vez definido el módulo como tipo “Local Enterprise Bean”, se deberán especificar los parámetros anonymizer.acceptNamespaces y anonymizer.encoding. El primero sirve para filtrar los Espacios de Nombre (namespaces) del fichero que se desean conservar (los que no se informen aquí se eliminarán del fichero). Hay que tener en cuenta que un fichero XML puede contener más de un espacio de nombres definido y a través de este parámetro también se permitirá renombrar a los mismos. En el caso del namespace principal se indicará haciéndole corresponder 2 comillas simples (‘’). En la nota 880173 - XI 3.0 Adapter Framework XML Anonymizer Modulese se muestran varios ejemplos sobre el comportamiento de estos parámetros.

                            El segundo parámetro, encoding, indica el formato con el que se generarán los datos del fichero.

                            En este caso los valores que se le han dado a los parámetros han sido:
                            • anonymizer.acceptNamespaces = http://www.server.com/DIR/NameSpace ‘’
                            • anonymizer.encoding = ISO-8859-1

                              Para más información se pueden consultar los siguientes enlaces:

                                jueves, octubre 09, 2008

                                Reloj de proceso y mensaje en barra de estatus

                                La función SAPGUI_PROGRESS_INDICATOR imprime el reloj de proceso en la barra de estatus y el mensaje que se indique. En el siguiente ejemplo, se buscan todas las transacciones a las que no tiene permiso el usuario que ejecuta el código. Mientras se muestra el progreso de la búsqueda mediante el reloj el cual se actualiza cada 25% para que el refresco de pantalla no sea incómodo:


                                lunes, octubre 06, 2008

                                MAPPING.NO_MAPPINGPROGRAM_FOUND

                                El motivo de que se produzca este error se debe a que uno de los campos pasados contiene un formato no esperado y por lo tanto no se puede mapear en XI, lanzando un mensaje como el que sigue:



                                Cuando el volumen de datos enviados es demasiado grande se aconseja probar el servicio con un mensaje más pequeño representativo que nos permita validar el correcto funcionamiento de la interfaz. Una vez comprobado que el proceso de mapeo funciona correctamente, habrá que detectar cuál fue el campo que vino informado con un formato incorrecto (p.ej. "100,09" en vez de "100.09").

                                Otra posible causa de este error se debe a que los datos de la cache no hayan sido actualizados, por lo que bastaría refrescarla para que se registren los cambios.

                                lunes, septiembre 15, 2008

                                Definición de Rango Numérico

                                La transacción para definir un objeto de tipo rango de números es la SNRO. A continuación se muestra un ejemplo de definición de rango de números:



                                Para obtener el siguiente valor del objeto desde un programa habrá que utilizar la siguiente función:



                                Donde la variable "pch_numpre" es del mismo dominio que el objeto numérico y contendrá el valor actual tras incrementar el contador del rango numérico.

                                Referencias: