Uso de comandos HTTP con Omnis

Caso ejemplo

Queremos hacer uso de comandos HTTP, para obtener una imagen ubicada en algún lugar de Internet y guardarla sobre un control JPEG de nuestro propio “remote form”, como por ejemplo la localizada en la dirección de internet: http://www.tigerlogic.com/omnis/images/omnis_studio_box.png.

 

HTTP Request y HTTP Response

Antes de entrar en detalles sobre el uso de comandos HTTP con Omnis, echemos un vistazo a lo que ocurre cuando se solicita una imagen, (o cualquier otro dato) mediante HTTP. Si introducimos la URL de un archivo imagen, (como por ejemplo la indicada en el párrafo anterior) en un navegador ésta será mostrada sobre la ventana del navegador, pero, lo que realmente ha sucedido es que el navegador (como cliente) a enviado un “HTTP Request” al servidor web “www.tigerlogic.com” solicitándole el fichero “/omnis/images/omnis_ studio_box.png” (parte de la URL, denominada URI), como consecuencia de esto, el servidor envía de vuelta un “HTTP Response” al navegador, que contiene, (entre otras cosas) el fichero solicitado. El formato de los paquetes de datos transferidos obedecen al protocolo estándar definido en el RFC 2616, consulte: www.faqs.org/rfcs/rfc2616.html

El “HTTP Request” está compuesto principalmente por una cabecera, que contiene los datos de identificación del cliente,  la información de lo solicitado por éste y su formato, mientras que el servidor responde con un “HTTP Response”, que a su vez consta de una cabecera y un cuerpo con la información requerida.

La cabecera de ambos es transferida en forma de texto ASCII estándar y por lo tanto puede ser “atrapada” mediante el uso de programas para el análisis de paquetes denominados “Sniffer’s”. Véase, por ejemplo: www.wireshark.org

Están compuestos por líneas individuales, cada una de ellas terminada con un retorno de carro (CR = Código ASCII 13) y un salto de línea (LF = Código ASCII 10). En cada línea, se asigna un valor a un campo, su formato es ≤nombre de campo≥":"≤valor≥. Entre la cabecera y el cuerpo hay una línea en blanco. De modo que, delante del cuerpo siempre encontraremos la cadena CR + LF + CR + LF.

 

¿Es Omnis un navegador?

Lo que podemos decir es que Omnis, soporta algunos comandos 4GL para la ejecución del ciclo “HTTP request/response”. Volviendo al caso planteado, podemos hacer uso de éstos comandos para obtener una imagen desde una ubicación remota. En primer lugar, Omnis deberá enviar una petición HTTP al servidor para recuperar o “conseguir” el archivo imagen. A continuación mostramos el código necesario: (“host” y “uri” son las variables locales de tipo “Character”, “socket” es de tipo “Long Integer”)

Calculate host as 'www.tigerlogic.com'
Calculate uri as '/omnis/images/omnis_studio_box.png'
HTTPGet (host,uri) Returns socket

Si la solicitud es aceptada, la variable “socket” contendrá un valor positivo, por su parte, Omnis habrá enviado lo siguiente:

GET /omnis/images/omnis_studio_box.png HTTP/1.1
Host: www.tigerlogic.com
Accept: */*
User-Agent: Raining Data - OMNIS
 
Si se desea definir parámetros adicionales para incluirlos en la cabecera de la solicitud o bien para nuestra propia versión de la URI utilizada por defecto, disponemos del comando “HTTPGet” el cual permite el uso de parámetros adicionales; en éste caso el código sería algo como lo siguiente:

Do cgiList.$define()
Do cgiList.$cols.$add(‘atributo’,kCharacter,kSimplechar,2000)
Do cgiList.$cols.$add(‘valor’,kCharacter,kSimplechar,2000)
Do cgiList.$add( ... )
Do headerList.$define()
Do headerList.$cols.$add(‘nombre’,kCharacter,kSimplechar,2000)
Do headerList.$cols.$add(‘valor’,kCharacter,kSimplechar,2000)
Do headerList.$add( ... )
HTTPGet (host,uri,cgiList,headerList) Returns socket

Si el “socket” es válido podremos recuperar datos del servidor, e ir guardándolos (en un primer momento) sobre (por ejemplo)  la variable “buffer” (definida como tipo “Character”):

HTTPRead (socket,buffer) Returns charCount

Los datos obtenidos tras el primer “HTTPRead” pueden no ser todos los esperados, por lo que, (como medida de precaución) es mejor crear un bucle (la variable “bufferPart” también es tipo “Character”). Así el código completo para leer una respuesta HTTP sería:

If socket>0
  Calculate buffer as ''
  Repeat
    Calculate bufferPart as ''
    HTTPRead (socket,bufferPart) Returns charCount
    Calculate buffer as con(buffer,bufferPart)
  Until (len(bufferPart)=0)|(charCount=0)
  HTTPClose (socket)
  ...(hacer algo)...
End If

Tras la obtención de todos los datos, será muy conveniente hacer uso del comando “HTTPClose” (socket) y después, comprobar que al inicio de la variable “buffer”; disponemos de algo como  lo siguiente:

HTTP/1.1 200 OK Server: Zeus/3.3
Date: Tue, 08 Dec 2007 12:34:57 GMT Content-Length: 4351
Content-Type: image/jpeg
Last-Modified: Thu, 01 Dec 2007 10:04:25 GMT 

Tras la cabecera, vendrá una línea en blanco y luego los datos binarios.

Si se envía un “URI” inválido, como por ejemplo, solicitando el archivo “studio4_box.jpg” que no existe en el subdirectorio “/products/studio/” del servidor web, no se nos devolverá el número “2xx”, si no (generalmente) el correspondiente al error 404. De modo que, nuestra aplicación debería comprobar la presencia de este número sobre la primera línea devuelta, comprobando que su primer dígito sea igual a 2. Por ejemplo:

If not(mid(buffer,pos(' ',buffer)+1,1)='2')
  OK message Error {[uri] no localizado.}
  Quit method
End If
 
Ahora deberemos separar el cuerpo de su cabecera. Recuerde que todo lo que nos llega después de la línea en blanco, son los datos referenciados. Por lo tanto deberemos declarar las siguientes variables locales:

posEmptyLine (Long integer)
bufferStripped (Binary)
picFormat (Character) 

y las variables-instancia:

iPicture (Binary)

finalmente deberemos añadir el siguiente código antes del comando “End If”:

Calculate posEmptyLine as pos(chr(kCr,kLf,kCr,kLf),buffer)
Calculate bufferStripped as mid(buffer,posEmptyLine+4,len(buffer))
Calculate picFormat as pictformat(bufferStripped)
Calculate iPicture as pictconvfrom(picFormat,bufferStripped)

Ahora podríamos asignar la variable IPicture a la propiedad “$dataname” de un control JPEG para así mostrar la imagen sobre nuestro “remote form”.

RESTful con Omnis Studio (Parte 3 de 3)

En éste último artículo sobre el tema que nos ocupa, describimos cómo configurar un servidor web para que soporte autenticación para nuestros servicios web RESTfull construidos con Omnis Studio.

Sin duda queda de nuestra parte el construir un método de autenticación seguro para nuestra librerías Omnis. Pero cuando se utiliza un verdadero servidor Web (en lugar del servidor Tomcat), deberemos configurar su dirección URL para que soporte autenticación de tipo “basic” y/o “digest”. Por supuesto, también podemos hacer uso de https, y certificados de cliente para que las conexiones sean más seguras.

En las siguientes secciones, se han incluido algunas notas acerca de cómo configurar Tomcat, Apache Web Server y IIS para que soporten autenticación de tipo “basic” y/o “digest”. Configurar nuestro servidor de éste modo, significará que a Omnis sólo llegará la solicitud si el cliente se ha autenticado correctamente; en este caso, las cabeceras HTTP incluirán la “Authorization header”, con los detalles de la autenticación.

Omnis Studio incluye una nueva función denominada “parsehttpauth(auth)”, la cual analiza el valor (auth) del http “Authorization header” y devuelve una variable de tipo “row” con la información extraída. La primera columna denominada “named scheme” contiene la denominación del esquema (por ejemplo “basic”). El contenido del resto de sus columnas dependerá del tipo de esquema. A continuación mostramos algunos ejemplos:

Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• La “row” devuelta tendrá las siguientes tres columnas:
• scheme: basic 
• username: Aladdin 
• password: open sesame

Digest username="Mufasa",realm="testrealm@host.com",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",uri="/dir/index.html",qop=auth,nc=00000001,cnonce="0a4f113b",response="6629fae49393a05397450978507c4ef1",opaque="5ccc069c403ebaf9f0171e9517f40e41"

• La “row” devuelta tendrá las siguientes diez columnas:
• scheme: digest 
• username: Mufasa 
• realm: testrealm@host.com
• nonce: dcd98b7102dd2f0e8b11d0f600bfb0c093 
• uri: /dir/index.html 
• qop: auth 
• nc: 00000001 
• cnonce: 0a4f113b 
• response: 6629fae49393a05397450978507c4ef1 
• opaque: 5ccc069c403ebaf9f0171e9517f40e41

OAuth realm="Example",oauth_consumer_key="0685bd9184jfhq22", oauth_token="ad180jjd733klru7",oauth_signature_method="HMAC-SHA1", oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",oauth_timestamp="137131200", oauth_nonce="4572616e48616d6d65724c61686176",oauth_version="1.0"

• La “row” devuelta tendrá las siguientes nueve columnas:
• scheme: oauth 
• realm: Example 
• oauth_consumer_key: 0685bd9184jfhq22 
• oauth_token: ad180jjd733klru7 
• oauth_signature_method: HMAC-SHA1 
• oauth_signature: wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D 
• oauth_timestamp: 137131200 
• oauth_nonce: 4572616e48616d6d65724c61686176 
• oauth_version: 1.0

Bearer 0b79bab50daca910b000d4f1a2b675d604257e42

• La “row” devuelta tendrá las siguientes dos columnas:
• scheme: bearer 
• token: 0b79bab50daca910b000d4f1a2b675d604257e42

Para cualquier otro esquema:

• La “row” devuelta tendrá las siguientes dos columnas:
• scheme: denominación del esquema en minúsculas 
• data: resto de la información de cabecera

Tomcat

Lo mostrado a continuación ha sido probado con Tomcat 7.0.42, ejecutado en Windows 8.1. Reinicie Tomcat después de cambiar los archivos de configuración.

Autenticación “Basic”

Configuración de usuarios: edite el fichero “conf/tomcat-users.xml”:

• Añada perfiles y usuarios dentro de elementos ≤tomcat-users≥ por ejemplo:

≤role rolename="omnisrest"/≥
≤user username="bobm" password="bobm" roles="omnisrest"/≥

Edite el fichero “web.xml” del webapp omnisrestservlet (carpeta WEB-INF);

• Añada lo siguiente después del elemento “servlet-mapping”:

≤security-constraint≥
≤web-resource-collection≥
≤web-resource-name≥All resources≤/web-resource-name≥
≤url-pattern≥/*≤/url-pattern≥
≤/web-resource-collection≥
≤auth-constraint≥
≤role-name≥omnisrest≤/role-name≥
≤/auth-constraint≥
≤user-data-constraint≥
≤!-- transport-guarantee can be CONFIDENTIAL, INTEGRAL, or NONE --≥
≤transport-guarantee≥NONE≤/transport-guarantee≥
≤/user-data-constraint≥
≤/security-constraint≥
≤login-config≥
≤auth-method≥BASIC≤/auth-method≥
≤realm-name≥omnisrest≤/realm-name≥
≤/login-config≥

Autenticación “Digest”

Igual que lo anterior, excepto que el “auth-method” debe ser “DIGEST”.
 

Probando localmente SSL

En el “conf/server.xml”:

Des-comente el conector SSL y modifíquelo, por algo como lo siguiente:

≤Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="C:\apache-tomcat-7.0.42\mykeystore" keystorePass="xxxxxx"/≥

Creación de un certificado de servidor auto-firmado, para el almacén de claves tomcat:

• Nota: Es necesario especificar un nombre y apellido para componer el localhost (a fin de permitir la realización de pruebas locales con OWEB como cliente)

• "C:\Program Files (x86)\Java\jdk1.6.0_37\bin\keytool" -genkeypair -alias mycert -keyalg RSA -validity 10000 -keystore c:\apache-tomcat-7.0.42\mykeystore

Uso del cliente Omnis OWEB para pruebas:

Extraiga el certificado:

"C:\Program Files (x86)\Java\jdk1.6.0_37\bin\keytool" -exportcert -alias mycert -keystore c:\apache-tomcat-7.0.42\mykeystore -file my_root_cert

Impórtelo al “omnisTrustStore”:

cd ≤omnis path≥\secure\cacerts

"C:\Program Files (x86)\Java\jdk1.6.0_37\bin\keytool" -importcert -alias my_tomcat -keystore omnisTrustStore -file c:\apache-tomcat-7.0.42\my_root_cert

Ahora podrá usar con Tomcat, URLs como la siguiente: https://localhost:8443/omnisrestservlet/ws/5988/api/phase2/myapi/first

Nota: Para eliminar copias antiguas del certificado use:

"C:\Program Files (x86)\Java\jdk1.6.0_37\bin\keytool" -delete -alias my_tomcat -keystore omnisTrustStore

Apache Web Server

 

Autenticación “Basic”

Creación de usuario y contraseña:

• c:\apache24\bin\htpasswd -c c:\apache24\test_passwords test

Nota: -c es opcional, sólo es requerido para la primera vez que se crea el fichero de contraseñas

Edite el fichero “httpd.conf”, la entrada “omnisrest” deberá ser como sigue:

≤Location /omnisrest≥

SetHandler omnisrest
AuthType Basic
AuthName "omnisrest"
AuthBasicProvider file
AuthUserFile c:\apache24\test_passwords
Require user test

≤/Location≥

“Require” puede tener la forma, “Require user...”, “Require valid-user” o “Require group...”, consulte la documentación en línea de Apache, para más información.

Autenticación “Digest”

Creación de usuario y contraseña:

• c:\apache24\bin\htdigest -c c:\apache24\test_digest_passwords omnisrest test

Nota: -c es opcional, sólo es requerido para la primera vez que se crea el fichero de contraseñas

Edite el fichero “httpd.conf”, la entrada “omnisrest” deberá ser como sigue

≤Location /omnisrest≥

SetHandler omnisrest
AuthType Digest
AuthName "omnisrest"
AuthDigestDomain /omnisrest/
AuthDigestProvider file
AuthUserFile c:\apache24\test_digest_passwords
Require valid-user

≤/Location≥

Des-comente la línea “LoadModule auth_digest_module modules/mod_auth_digest.so” del “httpd.conf”.

“Require” puede tener la forma, “Require user...”, “Require valid-user” o “Require group...”, consulte la documentación en línea de Apache, para más información.

IIS

Autenticación “Basic”

IIS es bastante difícil de configurar (o al menos IIS Express que es el que hemos probado). En primer lugar, es necesario habilitar la autenticación “basic” y desactivar la autenticación “anonymous” en el archivo “AppServer\applicationhost.config” (que podremos encontrar bajo el directorio de instalación de IIS Express). Haga una búsqueda de la cadena “authentication” y modifique lo que sea pertinente.

Agregue el código siguiente al final del fichero “applicationhost.config”, justo después del elemento “location” principal:

≤location path="Default Web Site/cgi-bin/omnisrestisapi.dll"≥

≤system.webServer≥
≤security≥
≤authentication≥
≤basicAuthentication enabled="true" /≥
≤/authentication≥
≤/security≥
≤/system.webServer≥

≤/location≥

A continuación, puede utilizar el usuario y su contraseña, con URL’s protegidas - tuvimos que crear una nueva cuenta de usuario estándar para conseguir que esto funcionase.

RESTful con Omnis Studio (Parte 2 de 3)

Éste artículo describe cómo configurar un servidor Web Tomcat con interfaz de usuario “Swagger” para su uso con los Servicios Web REST de Omnis, le animamos a descargarse la librería de ejemplo que ilustra lo mostrado aquí, disponible en la web de Aula Omnis.

 

Creando nuestros propios “Web Services”

Un plug-in “Web Server” permite publicar el código de nuestras aplicaciones Omnis, que permitirá a los posibles cliente hacer uso de nuestros “Web Services”. La interfaz para éstos servicios web es vista por los clientes como una API o conjunto de APIs. Omnis genera las API’s RESTful (o ORAs) usando una definición "Swagger", que es el estándar más utilizado con las API’s RESTful.

Podrá ver las Omnis APIs RESTul desde el navegador de Omnis Stido (Studio Browser) como hijos del nodo de su librería bajo el grupo “Web Service Server” (tal cómo ya venia ocurriendo con los servicios basados en WSDL). Cada “ORA” se muestra bajo un nodo separado en el árbol, y varias opciones o acciones con hipervínculos. Podrá ver su definición “Swagger” navegando a trabes de los hipervínculos.

A la hora de crear un servicio Web o una API Omnis RESTful, será necesario ajustar algunas propiedades de la “remote-task” a usar, además de añadirle algunos métodos RESTful. Las clases “remote-task” contiene dos nuevas propiedades que nos permiten configurar un servicio Web de éste tipo, en concreto, la propiedad “$restful” deberá establecerse a “kTrue” para indicar que la “remote-task” es de tipo RESTful, y la propiedad “$restfulapiname” deberá contener el nombre de la API RESTful.

Cuando una “remote task” ha sido definida como RESTful, dispone de un grupo de objetos (localizados bajo el habitual grupo $objs) que son las URI publicadas para los posibles clientes. Una URI contiene uno o más componentes que comienzan por “/”. También podrán incluirse parámetros en la forma “{paramName}” donde cada “paramName” deberá ser único (sensible al uso de mayúsculas y minúsculas) en cada URI. Los URI’s son como clases objeto con sus propias instancias, ya que pueden contener sus propios métodos. Existen algunos métodos especialmente construidos para las URI’s, denominados métodos HTTP. Estos se corresponden directamente con métodos de protocolo HTTP utilizados de forma estándar en todas las API RESTful, y son: “$delete”, “$get”, “$head”, “$options”, “$patch”, “$post” y “$put”.

Los métodos HTTP que conforman una URI contienen algunas características y propiedades especiales, pero todos ellos muestran un parámetro de cabecera denominado “pHeaders”, el cual referencia a la variable “row”, que contiene las cabeceras HTTP recibidas tras la petición RESTful, dicha variable dispone de una columna por cada encabezado HTTP.

En el caso los métodos que aceptan contenidos (“$patch”, “$post” y “$put”) existe un segundo parámetro denominado “pContent”, que referencia al contenido recibido tras la solicitud. Para cada nuevo método HTTP, Omnis creará automáticamente los parámetros “pHeaders” y “pContent”, además de agregar un parámetro de tipo carácter, por cada uno de los incluidos en la URI.

El editor de métodos Omnis contiene algunas características adicionales para su uso con las “remote-task” RESTful. Algunas opciones añadidas al su menú nos permiten insertar nuevos URI, eliminarlos o cambiar sus nombres, además de permitir la inserción de un nuevo método HTTP. También, y cuando el método seleccionado es un método HTTP, el panel de variables mustra dos pestañas adicionales: “RESTful” y “RESTful notes” los cuales nos permiten ajustar los valores de tipo “input”, “output”, así como los códigos de respuesta HTTP y la consignación de notas sobre el método escrito bajo definición “swagger”.

La ventana de diálogo para la configuración del servidor de aplicaciones Omnis (Omnis App Server) contiene dos nuevas propiedades configurables: la “RESTful URL”, que es la dirección URL base, utilizada para invocar al servicio Omnis RESTful, y la “RESTful connection” que controla cómo interacciona el plugin Omnis Web Server RESTful con el propio Omnis.

 

Requerimientos

Para Windows Vista o superior:

• Omnis Studio dev kit con número de serie valido para el Web Services Plugin.

• Java Development kit (JDK) o Java SE Runtime environment (JRE) versión 7.

• Consignar en la variable de entorno de usuario “OMNISJVM” o “OMNISJVM64” la ruta hacia el jvm.dll dentro de su instalación de Java (por ejemplo: c:.\Archivos de programa\java\ jre1.8.0_25\bin\server jvm.dll)

 

Configuración de un servidor web Tomcat para su uso con Servicios Web RESTful

1. Descargue Tomcat 8.0 o superior, distribución de 32 bits para Windows desde el sitio web http://tomcat.apache.org
2. Extraiga el archivo zip descargado y muévalo a la carpeta apache-tomcat-8.0.15 adecuada, por ejemplo a: c:\Archivos de programa\apache-tomcat-8.0.15.
3. Tomcat requiere configurar dos variables de entorno del sistema. Puede optar por configurarlas vía: “System⇒Advanced System Settings” o desde el panel de control de Windows, son las siguientes:
• CATALINA_HOME necesaria para indicar la ubicación de la carpeta de Tomcat, por ejemplo: c:\Archivos de programa\apache-tomcat-8.0.15.
• JAVA_HOME necesaria para indicar la ubicación de la instalación del Java JDK o JRE, por ejemplo: c:\Archivos de programa\java\jdk1.8.0_25.
4. Copie la carpeta “omnisrestservlet” del directorio “clientserver\server” del raiz Omnis Studio sobre la carpeta “webapps” de Tomcat.

 

 

Instalación de la interfaz de usuario “Swagger”

La interfaz de usuario “Swagger” nos permitirá ver y probar nuestros servicios web Omnis RESTful, desde un navegador web.

1. Descargue el archivo “swagger-ui-master.zip” desde el sitio web: https://github.com/wordnik/swagger-ui, pulsando el botón “Download ZIP” situado a la derecha de la página web.
2. Extraiga el contenido del archivo descargado y cópielo sobre la carpeta “dist” del directorio “webapps” de Tomcat, después renómbrelo como “swagger-ui”.

 

Arrancando Tomcat

Una vez completados los pasos anteriores, Tomcat estará listo para iniciarse mediante la ejecución del “startup.bat” ubicado en la carpeta “bin” de Tomcat. Si ya se está ejecutándose, deberá detenerlo primero mediante el “shutdown.bat”, si se esta usando un servidor web alternativo como IIS también se deberá primero detenerlo, para iniciarlo después.

 

Usando Omnis Developer como servidor WS RESTful

Para utilizar el servidor Tomcat que acabamos de instalar como servidor web RESTful será necesario fijar los parámetros “Server port”, “RESTful URL” y “RESTful Connection” desde el diálogo de configuración del servidor, tal y como se muestra a continuación, cambie el 99.99.99.99 por su dirección IP. Para abrir este cuadro de diálogo, despliegue el nodo “Web Service Server” del navegador Omnis Studio (Studio Browser) y haga clic sobre el hipervínculo “Server Configuration”.

 

La librería de ejemplo RESTful Server

Abra el ejemplo RESTful de la librería “swaggerdemo.lbs” (incluida en restfuldemo.zip de Aula Omnis) y observe las entradas “wizard” bajo el nodo “Web Service Server” en el navegador. Este es el valor asignado a la propiedad “restfulapiname” para el “remote task” “rtWizard”. El hipervínculo “Show Method List” muestra los métodos HTTP de la “remote task” de la URI “data”.

Éste ejemplo crea una base de datos SQLite a partir de un archivo de texto separado por comas, que puede ser consultada y actualizada mediante el servicio web RESTful.

Para utilizarlo, abra la ventana “wWizard”, arrastre el archivo de texto “phonelist.txt” suministrado, sobre la ventana abierta y siga los pasos que se indican a continuación, para su acceso a través del servicio web RESTfull.

 

Invocando el servicio RESTful desde “Swagger UI”

Swagger UI (interface de usuario swagger) utiliza un URI para invocar a un servicio web RESTful, al hacer clic sobre el hipervínculo “Web Service Server” podrá ver la URI necesaria, sobre la parte superior del “swagger data”.

Abra el “Swagger UI” sobre un navegador web, mediante introducir la dirección http://99.99.99.99:8080/swagger-ui/index.html, donde 99.99.99.99 es su dirección IP. Introduzca la URI como se muestra arriba y pulse “Explore” para ver el servicio web Omnis RESTful, haga uso del hipervínculo “Show/Hide” para sus métodos.

Pulse “Try it out!” sobre GET, para que el método HTTP “$get” de la URI “/ data” de la “remote-task” “rtWizard” se ejecute, devolviendo la lista de contactos localizados en la base de datos SQLite.

Para insertar un nuevo contacto utilizando PUT, haga clic sobre el “model schema box” y su opción “set as parameter value” para cambiar el valor de los parámetros, después pulse “Try it Out”.

Para ver el registro recién insertado en el servidor junto con el resto de datos existentes, escoja la opción “test” del “”remote-form” 'jsWizard' de la librería “swaggerdemo”.

 

Invocando el servicio RESTful desde Omnis Studio

El objeto “HTTP Web Worker” es el encargado de invocar los servicios web RESTful. La librería de ejemplo “swaggerclient.lbs” incluida, muestra cómo hacer uso de éste objeto para invocar un servicio web RESTful desde una hipotética máquina cliente, en lugar de tener que utilizar la interfaz de usuario Swagger con éste mismo próposito.

Para utilizar la demo en modo cliente, abra la ventana “wRestfulClient”, y escriba la URI “http://99.99.99.99:8080/omnisrestservlet/ws/1234/api/swaggerdemo/wizard/data” donde “99.99.99.99” es la dirección IP de su servidor Tomcat.

 

Seleccione “HTTPGet” y pulse “Test” para recuperar datos del servidor o “HTTPPut” para introducir nuevos valores y enviarlos al servidor para su inserción.