1.Introducción
En el siguiente documento se expone el método para crear servicios ODATA a partir de queries BEX en el entorno SAP BW.
Los servicios ODATA permiten que una query BEx sea consumida por cualquier sistema externo a SAP que disponga de este servicio.
2 Configuraciones previas en el sistema
2.1 Configuración del SAP Gateway
Si es la primera vez que se realizan queries ODATA en nuestro entorno, es posible que haya que configurar el SAP Gateway. Las acciones expuestas a continuación solo hay que realizarlas una vez.
Para al configuración del mismo, se han implentado los tres primeros pasos de la nota 2113675
Transacción SPRO:
Creamos el Gateway LOCAL
Con los valores:
SAP System Alias LOCAL
Local GW Selected
RFC Destination NONE
Software Version DEFAULT
2.2 Activación de los servicios ICF
Transacción SICF_INST.
2.3 EQ_RS_AUTOSETUP
Tras configurar los puntos anteriores, las queries ODATA no se publicaban como servicio. Tras revisión de notas SAP, ejecuté el programa EQ_RS_AUTOSETUP.
Tras esta ejecución, la publicación de queries se efectúa correctamente (ver mas adelante)
3 Creación de query BEX y publicación como servicio ODATA
3.1 Creación de la query BEx
El primer paso es crear la query BEX que nos proporcionará la información que deseamos suministrar al sistema externo. La query se creará de la forma habitual en el query designer o en Eclipse, aunque los servicios ODATA tienen algunas restricciones. Hasta el momento las restricciones que he podido comprobar son las siguientes:
Filtros y variables
Como en cualquier otra query, intentaremos que la información se filtre al máximo posible, con el fin de obtener un mejor rendimiento.
Las variables (tal y como se indica mas adelante), no se ejecutan directamente en el servicio externo del ODATA (es decir, no aparece una pantalla como en Analysis for Office o Analyzer, por ejemplo) No obstante, colocaremos en la query todas las variables por las cuales el servicio externo preguntará de forma dinámica, ya que:
Grabar la query
Marcamos la query como ODATA
3.2 Publicación del servicio
Los pasos a seguir para publicar el servicio son los siguientes:
Ejecutar la transacción /n/IWFND/MAINT_SERVICE y pulsar “Añadir Servicio”
En “Alias de Sistema” indicamos el Gatway creado anteriormente y “Obtener servicios”
Tras pulsar “obtener servicios” en el listado debería aparecer nuestra query con el sufijo _SRV al final:
Nota importante: Si no aparece, ejecutar el módulo de funciones RSEQ_NAT_GENERATION mediante la SE37
Pulsamos en el servicio y lo asignaremos al paquete correspondiente o como objeto local:
Si todo ha ido correcto, veremos nuestra query en el listado de servicios, estando ya a partie de este momento consultable:
3.3 Interpretación del servicio – confección de la URL
Los siguientes ejemplos son sobre la query ZUS_ODATA_TEST_Q001.
Las URLs indicadas serán válidas para cualquier otra query, simplemente substituyendo el nombre de la query y el tlcmbpccid01.cnx.ad.internal por el nombre que corresponda a su sistema.
Las URLS son consultables desde qualquier navegador web o herramienta que disponga el protocolo ODATA (como por ejemplo excel 2013 tal y comoindico mas adelante)
Consulta de metadatos:
http://tlcmbpccid01.cnx.ad.internal:8000/sap/opu/odata/sap/ZUS_ODATA_TEST_Q001_SRV/$metadata
Está URL proporcionara información diversa que será de utilidad para el desarrollador del sistema externo A bw. En los metadatos (en formato XML) hay información diversa tal como el nombre de los campos, contenido…
Consulta de resultados
http://tlcmbpccid01.cnx.ad.internal...DATA_TEST_Q001_SRV/ZUS_ODATA_TEST_Q001Results
Esta es la ULR que nos devolverá los resultados de la query. Dicha URL debe ser utilizada desde un sistema externo con protocolo ODATA
Paso de variables
Mediante el estándar ODATA, podría utilizarse, mediante la nomenglatura correspondiente, cualquier campo para pasar un filtro del sistema externo al sistema BW.
En el siguiente ejemplo, utilizo los filtros que están en la query mediante las variables correspondientes. En nuestro ejemplo (extrapolable a cualquier query). En los metadatos observamos:
La ZZSITECOD_SVO es la variable que he puesto en la query para el site (en el ejemplo se trata de una query del módulo Real Estate). Para filtrar por ejemplo por el site ‘5’, añadiremos a la URL de resultados que teníamos anteriormente:
http://tlcmbpccid01.cnx.ad.internal..._ODATA_TEST_Q001_SRV/ZUS_REFX_ZCP_REFX06_Q001(ZZSITECOD_SVO=’5′)/Results
Como es posible que el sistema externo quiera disponer de los posibles valores para mostrarlos al usuario, se podrá obtener el rango de valores mediante la URL:
http://tlcmbpccid01.cnx.ad.internal:8000/sap/opu/odata/sap/ZUS_ODATA_TEST_Q001_SRV/ZUS_ODATA_TEST?$select=ZZSITECOD_SVO
Para visualizar este ejemplo, he utilizado el ODATA del Excel (office 2013):
Y obtengo como resultado en el excel:
En caso de detectar problemas de rendimiento, deberemos acotar si el problema está en BW o en el servicio. Para ello utilizaremos las estadísticas de BW en la RSRT:
A continuación podemos ver una comparación por ejemplo entre antes y después de colocar el filtro por site (en este caso la query estaba sobre un modelo de BW de Real Estate)
(resultado mostrando todo del detalle de la query -sin filtro-)
(resultado con el filtro detallado por site)
4. Conclusión
Salvo las tareas de configuración inciales en el SAP Gateway (que habrá que realizar solo una vez), podremos publicar cualquier query BEx como servicio ODATA prácticamente de forma automática y sin ningún desarrollo adicional.
Además, la misma query podría ser consumida por ejemplo desde un reporting en Analysis for Office (AFO) y a la vez desde otro sistema que disponga de protocolo ODATA (o que pueda interpretar XML), garantizando de este modo la coherencia de datos entre ambos sistemas.
Espero que este post haya sido de vuestro interés.
Okumaya devam et...
En el siguiente documento se expone el método para crear servicios ODATA a partir de queries BEX en el entorno SAP BW.
Los servicios ODATA permiten que una query BEx sea consumida por cualquier sistema externo a SAP que disponga de este servicio.
2 Configuraciones previas en el sistema
2.1 Configuración del SAP Gateway
Si es la primera vez que se realizan queries ODATA en nuestro entorno, es posible que haya que configurar el SAP Gateway. Las acciones expuestas a continuación solo hay que realizarlas una vez.
Para al configuración del mismo, se han implentado los tres primeros pasos de la nota 2113675
Transacción SPRO:
Creamos el Gateway LOCAL
Con los valores:
SAP System Alias LOCAL
Local GW Selected
RFC Destination NONE
Software Version DEFAULT
2.2 Activación de los servicios ICF
Transacción SICF_INST.
2.3 EQ_RS_AUTOSETUP
Tras configurar los puntos anteriores, las queries ODATA no se publicaban como servicio. Tras revisión de notas SAP, ejecuté el programa EQ_RS_AUTOSETUP.
Tras esta ejecución, la publicación de queries se efectúa correctamente (ver mas adelante)
3 Creación de query BEX y publicación como servicio ODATA
3.1 Creación de la query BEx
El primer paso es crear la query BEX que nos proporcionará la información que deseamos suministrar al sistema externo. La query se creará de la forma habitual en el query designer o en Eclipse, aunque los servicios ODATA tienen algunas restricciones. Hasta el momento las restricciones que he podido comprobar son las siguientes:
- No se aceptan características libres
- Debe existir al menos una característica en las filas
Filtros y variables
Como en cualquier otra query, intentaremos que la información se filtre al máximo posible, con el fin de obtener un mejor rendimiento.
Las variables (tal y como se indica mas adelante), no se ejecutan directamente en el servicio externo del ODATA (es decir, no aparece una pantalla como en Analysis for Office o Analyzer, por ejemplo) No obstante, colocaremos en la query todas las variables por las cuales el servicio externo preguntará de forma dinámica, ya que:
- Las variables disponibles quedarán indicadas en los metadatos del servicio (ver mas adelante), facilitando de ese modo la interpretación del servicio
- Podremos comparar el rendimiento del servicio vs la query BEx
Grabar la query
Marcamos la query como ODATA
3.2 Publicación del servicio
Los pasos a seguir para publicar el servicio son los siguientes:
Ejecutar la transacción /n/IWFND/MAINT_SERVICE y pulsar “Añadir Servicio”
En “Alias de Sistema” indicamos el Gatway creado anteriormente y “Obtener servicios”
Tras pulsar “obtener servicios” en el listado debería aparecer nuestra query con el sufijo _SRV al final:
Nota importante: Si no aparece, ejecutar el módulo de funciones RSEQ_NAT_GENERATION mediante la SE37
Pulsamos en el servicio y lo asignaremos al paquete correspondiente o como objeto local:
Si todo ha ido correcto, veremos nuestra query en el listado de servicios, estando ya a partie de este momento consultable:
3.3 Interpretación del servicio – confección de la URL
Los siguientes ejemplos son sobre la query ZUS_ODATA_TEST_Q001.
Las URLs indicadas serán válidas para cualquier otra query, simplemente substituyendo el nombre de la query y el tlcmbpccid01.cnx.ad.internal por el nombre que corresponda a su sistema.
Las URLS son consultables desde qualquier navegador web o herramienta que disponga el protocolo ODATA (como por ejemplo excel 2013 tal y comoindico mas adelante)
Consulta de metadatos:
http://tlcmbpccid01.cnx.ad.internal:8000/sap/opu/odata/sap/ZUS_ODATA_TEST_Q001_SRV/$metadata
Está URL proporcionara información diversa que será de utilidad para el desarrollador del sistema externo A bw. En los metadatos (en formato XML) hay información diversa tal como el nombre de los campos, contenido…
Consulta de resultados
http://tlcmbpccid01.cnx.ad.internal...DATA_TEST_Q001_SRV/ZUS_ODATA_TEST_Q001Results
Esta es la ULR que nos devolverá los resultados de la query. Dicha URL debe ser utilizada desde un sistema externo con protocolo ODATA
Paso de variables
Mediante el estándar ODATA, podría utilizarse, mediante la nomenglatura correspondiente, cualquier campo para pasar un filtro del sistema externo al sistema BW.
En el siguiente ejemplo, utilizo los filtros que están en la query mediante las variables correspondientes. En nuestro ejemplo (extrapolable a cualquier query). En los metadatos observamos:
La ZZSITECOD_SVO es la variable que he puesto en la query para el site (en el ejemplo se trata de una query del módulo Real Estate). Para filtrar por ejemplo por el site ‘5’, añadiremos a la URL de resultados que teníamos anteriormente:
http://tlcmbpccid01.cnx.ad.internal..._ODATA_TEST_Q001_SRV/ZUS_REFX_ZCP_REFX06_Q001(ZZSITECOD_SVO=’5′)/Results
Como es posible que el sistema externo quiera disponer de los posibles valores para mostrarlos al usuario, se podrá obtener el rango de valores mediante la URL:
http://tlcmbpccid01.cnx.ad.internal:8000/sap/opu/odata/sap/ZUS_ODATA_TEST_Q001_SRV/ZUS_ODATA_TEST?$select=ZZSITECOD_SVO
Para visualizar este ejemplo, he utilizado el ODATA del Excel (office 2013):
Y obtengo como resultado en el excel:
En caso de detectar problemas de rendimiento, deberemos acotar si el problema está en BW o en el servicio. Para ello utilizaremos las estadísticas de BW en la RSRT:
A continuación podemos ver una comparación por ejemplo entre antes y después de colocar el filtro por site (en este caso la query estaba sobre un modelo de BW de Real Estate)
(resultado mostrando todo del detalle de la query -sin filtro-)
(resultado con el filtro detallado por site)
4. Conclusión
Salvo las tareas de configuración inciales en el SAP Gateway (que habrá que realizar solo una vez), podremos publicar cualquier query BEx como servicio ODATA prácticamente de forma automática y sin ningún desarrollo adicional.
Además, la misma query podría ser consumida por ejemplo desde un reporting en Analysis for Office (AFO) y a la vez desde otro sistema que disponga de protocolo ODATA (o que pueda interpretar XML), garantizando de este modo la coherencia de datos entre ambos sistemas.
Espero que este post haya sido de vuestro interés.
Okumaya devam et...