Siguiendo un antiguo requerimiento de crear empleados directamente en SAP desde un web services, me hicieron una actualizacion de este mismo y es que el Web Service es con JSON, la infomacion vendra en un array JSON, he investigado y ciertamente se puede consumir JSON en SAP y asimismo lo puedes crear, mi pregunta esta es en como consumirlo y pasar los datos a una tabla interna. Por mas que investigo no puedo dar con esa parte.
Yo no tampoco estoy muy claro…pero de las forma que yo he trabajo con web service, son a través de web dynpro for java y es a traves de modulos de funciones al igual que otros servicios pero yo no lo he configurado, simplemente creo el modulo de funcion con los export y los import y le indico al otro consultor del tipo de dato que lo estoy creado…en este caso, mencionas que es un array, ps tendrias que crear una estructura en el diccionario con los mismo tipos de datos que tiene el otro servidor y luego dentro de tus export del modulo de funciones declaras una estructura del tipo que creaste en el diccionario…espero te sirva o te de luz !!
Buenas @Roland,
creo entender que el servicio web lo publica JSON y lo consume SAP, por tanto tienes que definir una puerta lógica y un consumer proxy en sap.
Los de JSON deben proporcionarte el wsdl que es justo lo que necesita SAP para crear automáticamente el proxy con todos los datos de estructuras y tablas en el diccionario.
Ve por ejemplo a la SE80 -> Tratar objeto -> pestaña Enterprise services -> Cliente proxy y dar a nuevo -> URL/HTTP Destination -> y en la url se pones el wsdl que te han proporcinoado y vas rellenado las siguientes pantallas hasta Finalizar.
Entonces tendrás que activas el cliente.
En el wsdl viene la definición del array de JSON.
Para poder usar luego el cliente proxy tienes que crear la puerta lógica con la tx. SOAMANAGER.
Y en tu report o función crear el objeto puerta lógica y llamar al método de dicho objeto pasándole los parámetros concretos definidos automáticamente que los puedes consultar con la SE80.
@canuto Ciertamente como dices debo de tener una estructura en mi diccionario de datos igual a la del servidor que me la envia, gracias por confirmarmelo. Y @Salco segui detalladamente tus instrucciones que igual tenia la duda de si hacerlo asi o de otro modo pero cuando copiaba el url del web service y seguia los demas pasos al final me daba un error. Hice una prueba con un programa que se llama “SoapUi” recomendable para probar los WSDL antes de pasarlos a SAP y poder depurar su funcionamiento y para mal mi caso la URL que me enviaron no funciona adecuadamente. Y es que esa url no trae un wsdl sino que es una REST API que contiene el JSON. Igual habria forma de poder consumir esta REST API en SAP?
@Roland todo servicio web tiene asociado un wsdl que es donde se define, así que pide por favor a los de JSON que te envíen el wsdl.
Los de sap consumimos servicios web que publican nuestros compañeros de .NET. Un wsdl es un fichero XML de este estilo:
La primera es creando un objeto dentro de SAP (ABAP Proxy) que lo que hace es que mapea el web service a un objeto utilizable desde ABAP. Este nunca lo pude poner a funcionar. Nota: Esto se hace por la SE80
La segunda es consumiendo el web service a la roca desde ABAP. Te pondré un código de muestra:
FORM get_ws_data.
DATA: http_client TYPE REF TO if_http_client .
DATA: w_string TYPE string ,
w_result TYPE string ,
r_str TYPE string .
DATA: result_tab TYPE TABLE OF string WITH HEADER LINE.
CLEAR w_string .
w_string = 'URL DEL WEB SERVICE'.
CALL METHOD cl_http_client=>create_by_url
EXPORTING
url = w_string
IMPORTING
client = http_client
EXCEPTIONS
argument_not_found = 1
plugin_not_active = 2
internal_error = 3
OTHERS = 4.
* Se establece el método GET o POST
CALL METHOD http_client->request->set_header_field
EXPORTING
name = '~request_method'
value = 'POST'.
* Parámetro que recibe el web service
CALL METHOD http_client->request->set_form_field
EXPORTING
name = 'nombre del parámetro'
value = valor.
CALL METHOD http_client->send
EXCEPTIONS
http_communication_failure = 1
http_invalid_state = 2.
CALL METHOD http_client->receive
EXCEPTIONS
http_communication_failure = 1
http_invalid_state = 2
http_processing_failed = 3.
CLEAR w_result .
* Resultado del web service
w_result = http_client->response->get_cdata( ).
ENDFORM. "get_ws_data
@Salco no tengo mucha experiencia consumiendo Web services y segun habia leido e investigado es asi como dices, agradezco mucho la informacion y las instrucciones.
@romaldyminaya Gracias por la informacion, procedere a hacer pruebas y te dejo saber los resultados.
Pues voy a probar lo que comenta @romaldyminaya porque yo sólo lo he hecho con la SE80 y la SOAMANAGER y va muy bien, pero recién me entero que hay otra forma, estupendo!!
Buenas @romaldyminaya, estoy haciendo pruebas pero no me funciona
Debe ser que algo no estoy haciendo bien obviamente.
En la url le pongo la url que me pasaron los de net:
h_tp://servweb2010/ServiciosWebSAP/Services/ConexconSap/DBSapCertificados.svc
(se lo he puesto con ?wsdl y sin ello)
Al método se le puesto ~ seguido del nombre, para el wsdl que adjunto al final he puesto:
name = ‘~OBTENERTODOS’
value = ‘GET’.
El set_form_field no lo he usado, porque no se que poner
Y el w_result lo que trae es el código que expone el navegador cuando se pone la url, tanto cuando va con ?wsdl como cuando no.
@Salco Te comento que la solucion de @romaldyminaya me funciono a la perfeccion! Revisa bien si no estas haciendo algo mal. Te dejo un fragmento de codigo parecido al de Romaldy.
data : lv_value type string.
data : http_client type ref to if_http_client .
data : lv_url type string.
data : return type string.
data : lv_err_string type string ,
lv_ret_code type sy-subrc .
Gracias @Roland, me acaba de decir el técnico de .NET que es que hay por lo menos dos formas de exponer un servicio web, con SOAP (basado en XML) y otra que es con REST API.
Cuando se expone con SOAP, entonces en SAP hay que crear un proxy consumer con el wsdl y crear el puerta lógica con SOAMANAGER.
Cuando se exponer con REST API, entonces en SAP hay que hacerlo on the rock como dice @romaldyminaya.
Cada uno tiene sus ventajas y sus inconvenientes, entre ellos cabe destacar que REST API es menos pesado, con lo cual es más rápido, pero no está tipado. Con SOAP al venir las declaraciones de estructuras ocupa más la información que viaja pero está tipado, se sabe que tipo de datos viaja en cada momento.
En la oportunidad que tuve de realizar ese código, era para consumir un WebService basado en SOAP. Es decir, a código puro puedes realizar peticiones GET y POST a literalmente cualquier servicio que sea visible a través de HTTP.
Lo que pasa es que por lo general cuando publicas un servicio en .NET la primera URL lo que te muestra el listado de todos los métodos que están disponibles (WSDL). Si quieres usarlo en SAP debes especificar la URL que realizará la funcionalidad X (Esta url la consigues haciendo clic en el método que quieres correr).
Como pudiste observar la primera URL solo brinda un XML descriptivo el cual es un estándard y puede usarse en numerosos sistemas para mapear un objeto a dicho servicio.
En la segunda puedes ver los enlaces que llevan directamente a cada método individualmente.
Al hacer clic en el GetCitiesByCountry realmente estás accediendo a la URL que es la que ejecuta dicho proceso (Esta es la url que debes poner que llame en el programa para hacerle la petición GET.
Me gustaría añadir que existe un programa muy sencillo en el que no se usa apenas código y puedes integrar servicios web (SOAP o REST), con SAP y multitud de cosas más. Puedes generar programas muy complejos con sólo hacer drag en los items que te interesen.
En Valencia (ESP) lo utiliza la administración pública como middleware para muchas de sus conexiones con software.
El programa se llama Mule, es de Mulesoft Anypoint Studio.
Pues es que no las tengo todas conmigo @romaldyminaya , porque me da la impresión que el wsdl que he visto en el punto 1 que has facilitado, la forma de consumirlo es con los “verbos” de http GET y POST tal cual se pueden ver en el propio wsdl, pero en mi wsdl no existen esos verbos, es un svc y según lo que he leído en la red se consume de otra forma… ¿estoy en lo cierto?
