Diferencias

Muestra las diferencias entre dos versiones de la página.

--- desarrolladores:webservice_uso [27/01/2021 10:06]
guille [Accion search.]
+++ desarrolladores:webservice_uso [21/01/2023 04:19] (actual)
@@ Línea 10: / Línea 10: @@
 De este modo suap entrega una especificación completa que permite afrontar la totalidad del problema y a la vez que se desliga de cualquier responsabilidad frente a falencias de operación producidas por implementaciones incompletas por parte de los consumidores.
+=====   =====
 ===== Dirección del WS y credenciales. =====
-Explicaremos brevemente como hacerse de las credenciales y definir la dirección (URL) del WS usando la interfaz web de suap. Si estás leyendo este manual sin contar con usuarios de prueba podés requerirlo a **[email protected]**.
+[[:desarrolladores:webservice_uso:direccion_del_ws_y_credenciales|Dirección del WS y credenciales.]]
-==== Dirección del WS de suap (URL) ====
-La URL de suap está conformada por las siglas de la instalación, que siempre coinciden con la abreviatura de la Institución de profesionales. A modo de ejemplo damos siglas reales para algunas de ellas:
+=====   =====
-    * CBPRN. Corresponde al Colegio Bioquímico de la Provincia de Río Negro
-    * CBN. Corresponde al Colegio de Bioquímicos de Neuquén
-    * CBLP. Corresponde al Colegio de Bioquímicos de la Pampa
-    * ABNECH. Corresponde a Asociación de Bioquímicos del Nor Este de Chubut.
-    * CMN. Corresponde al Colegio Medico de Neuquén.
-    * CKN. Corresponde al Circulo de Kinesiólogos de Neuquén
-    * CPN. Corresponde al Circulo de Psicólogs de Neuquén
-    * CBPM. Corresponde al Colegio de Bioquimicos de Puerto Madryn
-    * ABCZSCH. Corresponde a la Asociación Bioquímica Clinica Zona Sur Chubut
-    * CIBOCH. Corresponde al Circulo Bioquimico Oeste de Chubut.
-    *
-Quedando así la URL para el acceso WEB (página) de cada instalación del siguiente modo:
-    * cbprn.suap.com.ar o [[http://www.cbprn.suap.com.ar|www.cbprn.suap.com.ar]]
-    * cbn.suap.com.ar o [[http://www.cbn.suap.com.ar|www.cbn.suap.com.ar]]
-    * cblp.suap.com.ar o [[http://www.cblp.suap.com.ar|www.cblp.suap.com.ar]]
-    * abnech.suap.com.ar o [[http://www.abnech.suap.com.ar|www.abnech.suap.com.ar]]
-    * cmn.suap.com.ar o [[http://www.cmn.suap.com.ar|www.cmn.suap.com.ar]]
-    * ckn.suap.com
-Para conformar la uri del WS de suap debe seguirse la siguiente regla:
-    * Definir las siglas de la instalación donde opera el prestador. Llamaremos **INST**     a estas siglas, en el ejemplo serían (cbprn, abnech, cbn, cblp o cmn)
-    * conformar la url del siguiente modo: **[[https://ws.INST.suap.com.ar/procesador/doV2/|https://ws.INST.suap.com.ar/procesador/doV2/]]**
-En los ejemplos reales a la fecha los accesos a cada ws serían entonces:
-    * CBPRN → **[[https://ws.cbprn.suap.com.ar/procesador/doV2/|https://ws.cbprn.suap.com.ar/procesador/doV2/]]**
-    * CBN → **[[https://ws.cbn.suap.com.ar/procesador/doV2/|https://ws.cbn.suap.com.ar/procesador/doV2/]]**
-    * CBLP** → [[https://ws.cblp.suap.com.ar/procesador/doV2/|https://ws.cblp.suap.com.ar/procesador/doV2/]]**
-    * ABNECH** → [[https://ws.abnech.suap.com.ar/procesador/doV2/|https://ws.abnech.suap.com.ar/procesador/doV2/]]**
-    * __CMN__** → [[https://ws.cmn.suap.com.ar/procesador/doV2/|https://ws.cmn.suap.com.ar/procesador/doV2/]]**
-==== Ambiente de pruebas ====
-En una primera etapa el desarrollador cuenta con un entorno de pruebas. El mismo tiene las siguientes direcciones:
-    * **[[http://www.test.suap.com.ar|www.test.suap.com.ar]] ** es la url base
-    * **[[http://www.test.suap.com.ar/prestador.php|www.test.suap.com.ar/prestador.php]]** es la url del prestador, para realizar gestiones web
-    * **[[https://ws.test.suap.com.ar/procesador/doV2|https://ws.test.suap.com.ar/procesador/doV2]]** es la dirección del WS.
-Para operar se debe realizar todo como en cualquier versión de producción.
-==== Credenciales para usar el WS ====
-En el caso de utilizar el WS de suap es necesario generar y obtener las credenciales. Dichas credenciales están ligadas a un usuario real de suap. Se puede crear un usuario específico para todo el laboratorio o a un usuario existente gestionarle una credencial para el WS. De ahora en mas a dicha credencial la llamaremos //TOKEN//.
-Pasos para conseguir un TOKEN para WS de suap:
-    - En la aplicación del prestador ir a la opción integrantes del laboratorio. {{:desarrolladores:labs.png?44x60}}
-    - En la lista de usuarios que tienen permitida tareas en el laboratorio se podrá observar una serie de columnas nuevas que se relacionan con el ws y los TOKENs de acceso. La lista completa de columnas para cada usuario es, entonces:
-    - Nro. Simplemente el número de usuario. Identificador único dentro de suap
-    - Usuario. Es el nombre del usuario y acceso al perfil del mismo.
-    - Ultimo acceso. La fecha y hora de la ultima vez que se logeó en suap web.
-    - Un botón para agregar un nuevo usuario. Debajo el acceso al registro de actividad de cada usuario
-    - Acceso a un chat con el usuarios
-    - Botón para inactivar o activar el usuario
-    - Botón para blanquearle la contraseña generando una nueva
-    - Botón para crear o renovar el TOKEN de WS
-    - Token de WS si es que lo tiene mas un botón para copiarlo al portapapeles
-El TOKEN consta de dos cadenas de caracteres separadas por un carácter : (dos puntos). La porción izquierda es el usuario y la porción derecha es el password. Por ejemplo, si el TOKEN es:
-**izquierda_AAABHJKiywz****:derecha_ccDDFfFGG**
-El TOKEN se decompone en:
-    * USUARIO: **izquierda_AAABHJKiywz**
-    * PASSWORD: **derecha_ccDDFfFGG**
-Una vez obtenido el TOKEN precionando la opción “crear token” se puede copiar al portapapeles usando el botón a tal fin. De este modo ya puede transportarlo a su sistema.
-==== Permiso para utilizar el WS de suap ====
-El o los usuarios a los que se les genera un TOKEN de ws deben, además, tener asignado el permiso para usar el WS. Dicho permiso se llama **webService**      y se asigna en la lista de permisos del usuario.
-==== Comentarios finales. ====
-En este punto usted ya debe haber podido generar el token para el usuario dentro de la web de suap y cuenta con una url de prueba para comenzar su implementación.
-En el WS cada request que realice debe contener en el header tipo de autenticación basic y el usuario y contraseña generados para el WS.
 ===== REST y JSON =====
-El Web Service de suap está basado en REST y el estandar adoptado para flujo de datos es JSON.
+[[:desarrolladores:webservice_uso:rest_y_json|REST y JSON]]
 ===== Recurso =====
-Es importante entender que el WS es, en el fondo, una especificación para crear y obtener recursos. Un recurso se identifica con una **URI**     (//uniform resource identifier).//
+[[:desarrolladores:webservice_uso:recurso|Recurso]]
-La totalidad de los recursos del WS están envueltos en una estructura JSON. Es decir, una imagen o un pdf primero es traducido a base64 y es devuelto como valor de una clave en la estructura JSON del **response**.
-La creación de los recursos se realiza mediante un request con el método **POST**.
-La obtención de recursos se hace mediante un request con el método **GET **    a la **URI**. En los capítulos siguientes se elaboran detalladamente estos conceptos.
-==== Nombre y URI de los recursos ====
-La URI del recurso es la forma de accederlo como ya lo dijimos. Está conformada por la **URL BASE**      o **dirección del WS**      + el nombre del recurso + su **token**. Supongamos que en la página de suap de testing vemos la orden número 654321. Su **token**      es O654321 (regla para órdenes). La **URI**      para acceder esa orden mediante el WS es entonces:
-**[[https://ws.test.suap.com.ar/procesador/doV2/orden/O654321|https://ws.test.suap.com.ar/procesador/doV2/orden/O654321]]**
-==== Atributo ====
-Los recursos, en su mayoría, contienen atributos. Los nombres de los atributos pueden ser un grupo de palabras. Por ejemplo la fecha de realización de una orden es “**FechaRealizacion**”. Las palabras que componen el nombre de los atributos van capitalizadas y pegadas sin ningún carácter en general. Eventualmente podrían separarse por un guión bajo.
-FALTA DOCUMENTAR
 ===== Obteniendo Recursos. =====
-Lo mejor para comenzar es hacer una serie de ejemplos. En este punto usted debería contar con:
+[[:desarrolladores:webservice_uso:obteniendo_recursos|Obteniendo Recursos.]]
-    * URL de un sitio de test para prestador. [[http://www.test.suap.com.ar/prestador.php|www.test.suap.com.ar/prestador.php]]
-    * Credenciales para acceder que requirió por mail a [email protected]
-    * Un token de usuarios que gestionó en el sitio para prestadores de ejemplo
-    * URI base del WS de test: [[https://ws.test.suap.com.ar/procesador/doV2|https://ws.test.suap.com.ar/procesador/doV2]]
-Para proceder con este capítulo es necesario contar con ordenes creadas desde la página web. Puede consultar al personal administrativo del punto de atención que desea conectar a su software de consumo de WS como se realiza esta operación en la web de testing.
-==== Método GET. ====
-Es el método utilizado para obtener un recurso mediante su **URI**. Para avanzar con el ejemplo en la página de suap puede mirar la lista de ordenes. Verá que las mismas tienen un número. Ese número con el agregado de una O delante es el **token**      de la orden en tanto recurso para el WS. Con eso podremos armar la **URI**      de un recurso orden para hacer un GET y comenzar a analizar el **response**.
-|**<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>GET https://ws.test.suap.com.ar/procesador/doV2/orden/O1234]]]]]]  \\  </font>  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>El header de este request tiene auth basic + user:pass (token)</font> **  |
-==== Estructura general del response (respuesta). ====
-Un response producto de un **GET**    es un Json que contiene las siguientes secciones principales:
-|**<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>Esquema de response general.</font>  ** \\ <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>{"REST": {…},      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>“RENDER”: {…},      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>“STATUS” : {…},      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>“VIEW”: {…},      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>}</font>  |
-    * **REST**. Es el o los recursos en términos REST. Los atributos del recurso base más las URIs de los recursos relacionados. Aquí encontraremos los “links” de los recursos relacionados y nada mas. Consumir la información desde esta sección es mas trabajoso ya que requiere de mayor cantidad de consultas al WS, pero permite resolver cualquier situación no prevista ya que literalmente se puede navegar por toda la información.
-    * **RENDER. **    Es la misma información de la sección REST pero ya preparada (renderizada) para que el consumidor la disponga sin tener que acceder a los recursos relacionados. El objetivo de esta sección es bajar la taza de uso del WS, facilitando toda la información necesaria para el consumidor en la menor cantidad posible de transacciones.
-    * **STATUS**. Sección que indica estados de las transacciones. Por ejemplo los errores en la sección interna **ERROR**
-    * **VIEW**. Es información que debe ser presentada al usuario y una especificación de como se debe requerir información faltante para cumplir con los requisitos mínimos
-Para ejemplificar veamos como se obtiene un atributo y un recuros en la sección **REST **    y **RENDER**. Por caso la fecha de realización como atributo y el afiliado como recurso.
-En el fragmento inferior vemos que la fecha de realización es el valor de la fecha, es decir, es un atributo. En cambio el recurso afiliado es una URI. Si hiciermos GET a esa URI obtendríamos toda la infomación del recurso.
-| \\  <font 10pt:normal/Courier;;#000000;;inherit>{</font>  \\ <font 10pt:normal/Courier;;#000000;;inherit>“REST”: {</font>  \\ <font 10pt:normal/Courier;;#000000;;inherit>“FechaRealizacion”:“2017-01-04 00:00:00”,</font>  \\ <font 10pt:normal/Courier;;#000000;;inherit>- - -</font>  \\ <font 10pt:normal/Courier;;#000000;;inherit>“afiliado”:</font> <font 10pt:normal/Courier;;#000000;;inherit>“https://ws.test.suap.com.ar/procesador/doV2/afiliado/7C9tIPdWMNTt99Zn1afALxroGVuQMt]]]]]]”     \\  </font> <font 10pt:normal/Courier;;#000000;;inherit>,</font>  \\ <font 10pt:normal/Courier;;#000000;;inherit>- - -</font>  \\ <font 10pt:normal/Courier;;#000000;;inherit>}</font>  |
-El mismo response pero en la sección RENDERpresenta la información mas apropiada para consumir sin realizar mas consultas. Con respecto a los atributos vemos que no hay diferencia, en cambio con los recursos asociados sí. Del afiliado observamos que tenemos información mas completa y útil sin la necesidad de hacer mas requests al WS.
-| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>{      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"RENDER": {      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"FechaRealizacion": "2017-01-04 00:00:00",     \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>- - -      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"afiliado":{ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"NombreCompuesto": "CORBALAN MARTA LAURA ",     \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"DocNumero": "10044895",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"DocTipo": "DNI",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"NumeroAfiliado": "15055729820800",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"Token": "7C9tIPdWMNTt99Zn1afALxroGVuQMt",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>- - -      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>}      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>}</font>  |
-==== La sección VIEW del GET. ====
-La sección **VIEW** es una pequeña “vista” o formulario con opciones que debe ser presentada al usuario. El consumidor tiene la libertad de realizar GET para mantener sincronizado su sistema con suap sin la intervención del usuario, pero debe ofrecer al menos una forma de acceder al GET de los recursos procesando la sección VIEW del **response. **
-En el caso del método que nos ocupa el VIEW en la mayoría de los casos contendrá acciones.
-{{:desarrolladores:seccion_view.png?616x398}}
-=== Acciones en la sección VIEW. ===
-<font 9pt:normal/auto;;#000000;;inherit>FALTA DOCUMENTAR</font>
-==== Accion search. ====
-Otro modo de obtener recursos es mediante la accion search. Se crean mediante el método **POST** y devuelven como response una lista de recursos que coinciden en los criterios de búsqueda especificados.
-Se debe especificar en la **URI** del **POST** el **“recursoABuscar” + “.” +** “**search” **. Es decir, supongamos que buscamos un afiliado, la **URI ** en testing sería:
-|
-|  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>POST </font>  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>https://ws.test.suap.com.ar/procesador/doV2/afiliado.search]]</font>  |
-En el content debemos especificar los atributos y/o recursos relacionados mas sus atributos separados por puntos “.” y finalmente la operación de comparación. Veamos por ejemplo el caso de buscar todos los afiliados que contienen el nombre “Santiago”:
-|   \\  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>POST </font>  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>https://ws.test.suap.com.ar/procesador/doV2/search.afiliado]]  \\  </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>[{     </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>“NombreCompuesto.contenga”:”Santiago”     </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>}]</font>  |
-Si seguimos el ejemplo veremos que nos devuelvo un response que contiene 3 secciones:
-    * **REST**.   Será una lista de las n primeras **URI**s de los recursos que   satisfacen esta condición.
-    * **STATUS**. Información sobre el resultado de la transacción. En el caso de la acción search se incorpora una sección además de ERROR. La sección NOTICE permite saber tres cosas, si queda una página mas, cuantos se muestran por página y que página se está mostrando.
-    * **RENDER.**    Es la misma información que en REST pero ya procesada para consumir sin la   necesidad de recorrer las **URI**s.
-| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>REQUEST https://ws.test.suap.com.ar/procesador/doV2/afiliado.search]]]]]]]]]]]]  \\  </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>{      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"REST":{      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"1":"https:ws….V2/afiliados/YMABXGMrPMo0iDFs1lVeGSvhLEWwPq",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>- - -      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>“10”:https://ws....V2/afiliados/ges37O3Ne007vZyM4OnGIpj0cEzm4N]]]]]]]]]]]]”      \\  </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>},   </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit> \\ "STATUS": {      \\ "ERROR": [],      \\ "NOTICE": {      \\ "More": true,      \\ "ActualPage": 1,      \\ "PageSize": 100      \\ }      \\ }       \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>,      \\ “RENDER”:{                                          \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"1":{      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"NombreCompuesto": "MU OZ SANTIAGO SEGUNDO ",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>"DocNumero":”      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>- - -      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>}      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>} </font>  |
-Como novedad vemos que en la sección **STATUS**     aparecen dos claves que nos permiten recorrer los resultados puesto que queries largas están paginadas. Las dos claves son **pagina **    y **cantidadTotal**. Podemos ver que estamos viendo la página 1 de una query que generó 1100 resultados posibles. Para ver la página siguiente se debe incorporar al content del POST una clave **pagina**     cuyo valor es el número de página que queremos ver:<font 10pt:normal/Courier;;rgb(0,0,0);;inherit> \\ </font>
-|**<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>POST https://ws.test.suap.com.ar/procesador/doV2/afiliado.search]]]]]]]]]]]]  \\  </font>  ** <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>{     \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>“NombreCompuesto.contenga”:”Santiago”,      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>“pagina”: 2     \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>}</font>  |
-El resultado del **POST**    del ejemplo superior será el de la página siguiente y nos daremos cuenta puesto que tanto en **REST **      como en **RENDER **      los resultados estarán numerados a partir del 11 en este caso que la página contiene 10 elementos. En **STATUS**    la clave **pagina**    tendrá el valor 2. Esta lógica aplica para cualquier página que requiramos, por ejemplo, la página 5 nos dará los elementos del 41 al 50.
-<font 9pt:normal/auto;;#000000;;inherit>FALTA DOCUMETAR     \\  \\ </font>
-\\
-=== Mantenerse al día. ===
-La obtención de recursos mediante search sirve para actualizar datos de convenios en el LIS. Supongamos un **POST**      al recurso search.obrasSociales con el siguiente content:
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>https://ws.test.suap.com.ar/procesador/doV2/obraSocial.search]]  \\  {                                       \\  “Nombre.contenga”:””                                      \\  }</font>  |
-Tendremos como response la lista de los convenios que están siendo gestionados por suap en este momento. Además esa lista, como siempre, contendrá las URIs de cada uno para poder recorrerlos y obtener información relevante para el sistema del consumidor. Por ejemplo valores de unidades, nomencladores, etc.
-| \\  <font 10pt:normal/Courier;;#000000;;#ffffff>{      \\ “REST”: {                                    \\ “1”: “https://ws.test.../28EiEf2G0gP49RtFighfflHBZXk1tu]]]]]]”,      \\  “2”: “https://ws.test.../mAJU8wAVBgU4GgLQGhX9JTXUO6wDrX]]]]]]”,      \\  “3”: “https://ws.test.../Gy226GrRazQ8yNjYXawYB7ikv3C6xI]]]]]]”      \\  },                                    \\  “STATUS”: {                                    \\  “ERROR”: [],                                    \\  “pagina”: 1,                                    \\  “cantidadTotal”: 3,                                    \\  “cantidadPorPagina”: “10”                                    \\  },                                    \\  “RENDER”: {                                    \\  “1”: {                                    \\  “Nombre”: “PAMI”,                                    \\  - - -                                    \\  },                                    \\  “2”: {                                    \\  “Nombre”: “ACA SALUD”,                                    \\  - - -                                    \\  },                                    \\  “3”: {                                    \\  “Nombre”: “Sancor Salud”,                                    \\  - - -                                    \\  }                                    \\  }                                    \\  }</font>  |
 =====   =====
@@ Línea 221: / Línea 35: @@
 ===== Creando recursos. =====
-La creación de recursos es mediante el método **POST**. La dirección a la que hay que realizar el post es como una **URI **     pero sin el **token**      puesto que no lo tendremos. Por ejemplo si deseamos crear una orden para autorizar, la dirección del post sería **URI BASE + ordenes**. En el entorno de testing nos queda:
+[[:desarrolladores:webservice_uso:creando_recursos|Creando recursos.]]
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>https://ws.test.suap.com.ar/procesador/doV2/orden]]]]]]</font>  |
+===== Políticas =====
-Un request mediante **POST**      mas un contenido en esa dirección puede terminar en una orden autorizada. En términos generales un **POST**      a una dirección de recurso puede instanciar un recurso en suap. Existe la posibilidad de que no ocurra esto ya que puede haber errores o datos incompletos.
+[[:desarrolladores:webservice_uso:politicas|Políticas]]
-|
+=====   =====
-    * **Política de persistencia**. Si la respuesta del **POST**     contiene una sección **REST**     con una clave **token**     y un valor diferente de **null**, entonces el recurso se persistió. Su **URI **     será exactamente la misma del **POST**     + el **token.**
+=====   =====
-==== Contenido (content) del POST ====
-En términos formales el contenido del **POST**      es un **JSON**      con los atributos del recurso que el consumidor desea crear. Dicho JSON está estructurado en dos grandes secciones que representan dos políticas diferentes de como se referencia la información dentro de suap. Una sección es **REST**      y la otra sección es **SEARCH.     \\  \\ **
+===== APÉNDICE =====
-| \\  **<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>Contenido de un POST a un recurso ordenes     \\ https://ws.test.suap.com.ar/procesador/doV2/orden]]]]]]</font> ** <font 10pt:normal/Courier;;rgb(0,0,0);;inherit> \\ { "REST": {…},                                     \\ “SEARCH”: {…}                                   \\ }</font>  |
+[[:desarrolladores:desarrolladores:webservice_uso:apendice|APÉNDICE]]
-=== Sección REST ===
-En esta sección se indican los atributos con su valor y los recursos relacionados mediante su **URI. **    Por ejemplo, en una orden, la **fecha de realización **    es un atributo cuyo nombre es “**FechaRealizacion**” que debe contener una fecha en formato: yyyy-mm-dd hh:mm:ss. Un afiliado es un recurso relacionado que debe ser especificado por su **URI**.
-Supongamos que deseamos instanciar un recurso orden con:
-    * Fecha de realización 23/06/2018
-    * Afiliado Marta Laura Corbalán del ejemplo anterior, cuyo recurso tiene como**  URI      \\ ** [[https://ws.test.suap.com.ar/procesador/doV2/afiliados/7C9tIPdWMNTt99Zn1afALxroGVuQMt|https://ws.test.suap.com.ar/procesador/doV2/afiliados/7C9tIPdWMNTt99Zn1afALxroGVuQMt]]** \\  \\ **
-Para pedirle al WS que cree el recurso orden con esos datos especificados en la sección **REST**      debemos armar el siguiente JSON:
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>POST a ordenes (testing)      \\  https://ws.test.suap.com.ar/procesador/do/V1.0/ordenes]]]]]]  \\  { “REST”:{ “FechaRealizacion”:”2018-06-23 00:00:00”, “afiliados”:                          \\  “https://ws.test.suap.com.ar/procesador/doV2/afiliados/7C9tIPdWMNTt99Zn1afALxroGVuQMt]]]]]]”     \\  },                        \\  … }}</font>  |
-En general es poco probable que se cuente con la URI de los recursos y mas que nada al principio. Por lo que si el consumidor fuera por este camino tendría que implementar primero una serie de herramientas para poder buscar afiliados para poder incorporarlos en la sección REST, y lo mismo con los prescriptores y así con todos los recursos relacionados a una orden en este ejemplo. Recién entonces podría armar un contenido completo para realizar el POST y obtener finalmente el recurso instanciado en suap.
-Si bien el WS no impide estas prácticas tampoco la alienta. Es por eso que ofrecemos la sección SEARCH que hace exactamente lo ante dicho pero en una cantidad menor de pasos.
-=== Sección SEARCH ===
-En esta sección se le indica a suap que se van a identificar los recursos mediante busquedas por sus atributos. Es decir, por ejemplo si es el POST a una orden y no tenemos el **token**    del afiliado que deseamos, podemos indicar que se lo busque por su nombre, DNI, o cualquier dato parcial o completo que tengamos del mismo. Suap aplicará una política simple en esta condición, si encuentra un único recurso con esos criterios de búsqueda, entonces lo utilizará, si encuentra mas de uno requerirá que sea seleccionado uno por parte del usuario mediante la sección VIEW del response.
-Cabe destacar que los atributos deben seguir siendo especificados en la sección **REST**.
-A modo de ejemplo un uso de la sección **SEARCH**    del WS identificando al afiliado por su DNI y un conjunto de practicas identificados por sus ultimos 4 digitos del NBU.
-| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>POST a un recurso ordenes      \\ https://ws.test.suap.com.ar/procesador/doV2/orden]]]]]]  \\  {                      \\  "REST":{                      \\  "FechaRealizacion":"2019-03-09",                         \\  "FechaPrescripcion":"2019-03-02",                         \\  "DiagnosticoTexto":"Texto diagnostico"                       \\  },                      \\  "SEARCH":{                      \\  "afiliado":[                      \\  {"DocTipo.igual":"DNI"},                           \\  {"DocNumero.igual":"10044895"}                      \\  ],                      \\  "prestador":[                      \\  {"NombreCompuesto.contenga":"…."}                      \\  ],                      \\  "prescriptor":[                             \\  {"NombreCompuesto.contenga":"Abenda"}                      \\  ],                      \\  "items":[                      \\  [{"CodigoConvenio.igual":"660711"}                      \\  ],                      \\  [{"CodigoConvenio.igual":"660413"}                      \\  ]]                      \\  }                     \\  }</font>  |
-**Este ejemplo crea una orden de PAMI, simplemente creando un ejemplo con otro afiliado de otra OS debería generarse otra orden**
-**  FALTA DOCUMENTAR**
-|
-==== Interpretación del VIEW ====
- \\  \\ El view es una lista de requerimientos y ofertas que hay que hacerle al usuario. Cada requerimiento u oferta indica exactamente donde debe ir el resultado de lo que el usuario responda.     \\ Un requerimiento es algo que faltó o que es necesario resolver por parte del usuario. Por ejemplo un requerimiento puede ser definir un profesional ya que con la matrícula brindada hay dos o mas opciones posibles. Los requerimientos están siempre presentes como un error en la sub sección ERROR de la sección STATUS.     \\ Una oferta es algo que le puede ser de utilidad al usuario. Por ejemplo un comprobante para imprimir es algo que el usuario puede necesitar o no para terminar un proceso externo a suap y necesario para el colegio. Pero no es algo necesario para instanciar un recurso.     \\ Si se realiza un procesador de la sección VIEW practicamente no haría falta nada mas para instanciar recursos en suap (por ejemplo ordenes), mas allá de que sería quizás torpe y se realizarían muchisimas mas llamadas de las necesarias. Comencemos con un ejemplo considerando que operamos en la instalación de **test**.
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>POST a un recurso ordenes     \\  https://ws.test.suap.com.ar/procesador/doV2/orden]]]]]]  \\  {                     \\  "REST": {},                     \\  "SEARCH": {                     \\  "afiliado": [                     \\  {                     \\  "NombreCompuesto.contenga": "Juan"                     \\  }                     \\  ]                     \\  }                    \\  }</font>  |
-Como es esperable es imposible obtener un recurso **ordenes**      con ese content. Por lo que el response del WS contendrá un VIEW requiriendo todo lo que haga falta indicado en ERROR de STATUS cada atributo y recurso faltante. Si no está en** {“STATUS”:{“ERROR”:{..}}}**      entonces no es algo necesario es una simple oferta.
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>Fracción de response      \\ "REST": [],                    \\ "STATUS": {                     \\ "ERROR": {                          \\ "FechaRealizacion": {                            \\ "CODE": 10060,                            \\ "MESSAGE": "El atributo es requerido"                     \\ }, - - -"VIEW": {                        \\ "FechaRealizacion": {                          \\ "type": "timestamp",                          \\ "label": "FechaRealizacion",                          \\ "path": "REST/FechaRealizacion"                        \\ }</font> ,     \\   \\ - - - |
-Del response tomamos 3 fragmentos mínimos a modo de ejemplo y vemos que:
-    - **{“REST”:[]…}**      Es una lista vacía por lo que **token **     no está definido. Condición de persistencia no se cumple, ya es condición suficiente para procesar el VIEW.
-    - En** {“STATUS”:{“ERROR”:{..}}} **     se nos indica que FechaRealización es un atributo requerido mediante un código para que tome decisiones el consumidor y un mensaje para que tome decisiones el usuario en caso de ser necesario. Por eso es una buena práctica mostrar ese texto.
-    - Por otra parte el**  {“VIEW”:{“FechaRealizacion”:{..}}}**      le indica al consumidor como procesar este atributo o recurso. En este caso se indica que:     \\  \\ 1.	El tipo es fecha, por lo que el consumidor puede ofrecerle un formato apropiado o incluso un widget de calendario. El resultado debe ser si o si en el formato especificado por el WS     \\ 2.	El resultado de lo que el usuario ingrese debe ser colocado en el JSON de request nuevo en la posición que se indica. Las “/” separan claves. Es decir, en el ejemplo al **“REST”**      debe agregarse una clave** “FechaRealizacion”**      que contiene una clave **“value”**      que vale la fecha que ingrese el usuario.     \\ 3.	Información de asistencia al usuario como el label del campo para ingresar la fecha. El error que ocacionó que el WS requiera este dato, etc.
-|
-=== Tipo string y timestamp. ===
-Una propuesta para presentarle al usuario bien podría ser:
-[[:desarrolladores:tipo_string_y_timestamp.png?720x243}}|tipo_string_y_timestamp.png]]
-=== Tipo list. ===
-En lineas generales este criterio sirve para los tipos** texto y fecha.**     Otro ejemplo interesante es el tipo **lista**. Siguiendo con el ejemplo podemos ver que hay un atributo **contexto **    en el response de un post vacío a ordenes:
-| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>Fracción de response     \\ "REST": [],                 \\ "STATUS": {                    \\ "ERROR": {                    \\ "afiliado": [                    \\ {                    \\ "code": 10010,                    \\ "message": "Sea mas especifico en la busqueda, se encontraron mas resultados de los permitidos"                    \\ },                    \\ {                    \\ "code": 10060,                    \\ "message": "El atributo es requerido"                    \\ }                    \\ ], - - -"VIEW": {                   \\ "afiliado": {                    \\ "type": "list",                   \\ "label": "Seleccione un afiliado de la lista",                    \\ "path": "REST/afiliado",                    \\ "options": {                    \\ "lelWBHU685gZOTAWSh3OrO5XAT0XEa": "GUERRERO JUAN ANTONI|40506285720700|PAMI|",                    \\ "EduJfFqI1BOBgcYL8G4TXEd34MbGBd": "MINERVINI….                    \\ }                    \\ },                   \\ - - -</font>  |
-Los criterios a aplicar sobre el **atributo **      afiliado son similares a los de **FechaRealizacion**    vistos en el ejemplo anterior, aquí la diferencia es que el input o el entry que se le provee al afiliado es sobre una lista de opciones en las que se detalla en la sección “**opciones**” que mostrarle al afiliado para que elija y que devolver en la ruta especificada. Siempre se devuelve la clave y se muestra el valor      \\  \\ [[:desarrolladores:tipo_list.png?616x264  }}|tipo_list.png]]
-Al igual que en el caso de **FechaRealizacion **      quedará en la **ruta **      especificada el valor que seleccione el usuario en este caso. Ya podemos apreciar que es el usuario quien mediante estos mecanismos simples puede ir construyendo el próximo request ya que se van completando las secciones del mismo.
-=== Tipo recurso. ===
 =====   =====
-Otro caso interesante para ver con ejemplos es el del tipo **recurso**. Veamos un ejemplo mas para poder formalizar una política.
-| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>Fracción de response    \\ "REST": [],                \\ "STATUS": {                   \\ "ERROR": {                   \\ - - -                      \\ "afiliados": {                   \\ "CODE": 10070,                   \\ "MESSAGE": "El recurso es requerido"                  \\ }, - - -"VIEW": {                   \\ - - -                   \\ "prescriptor": {                   \\ "type": "resource",               \\ "label": "",                   \\ "resource": {                  \\ "MatriculaNacional": {                   \\ "path": "SEARCH/prescriptor/2/MatriculaNacional.contenga",                   \\ "type": "string",                   \\ "label": "Buscar con MatriculaNacional"                   \\ },                   \\ "NombreCompuesto": {                   \\ "path": "SEARCH/prescriptor/3/NombreCompuesto.contenga",                   \\ "type": "string",                   \\ "label": "Buscar con NombreCompuesto"                   \\ },  - - -                     \\ },                  \\ - - -</font>  |
-El tipo **recurso **      es ni mas ni menos que una serie de atributos que definen un recurso cuando es imposible ofrecerlo en una lista. Por ejemplo, supongamos el ejemplo concreto del response que estamos analizando. El afiliado bien podría ser elegido de una lista, pero sería una lista con miles de opciones. Por lo que al no haber dato alguno y ser un dato necesario para instanciar la orden entonces se ofrece completar datos que buscarán un recurso afiliado adecuado. Si miramos la porción del response de **afiliados **      dentro de **VIEW **      veremos que está como siempre la clave “**tipo**” y una clave “**resource**” que a simple vista parece como una sección **VIEW **    mas pequeña!. La realidad es que no parece, es. **VIEW **      es una estructura recursiva.     \\ La primer entidad de **VIEW **      está implícita y es de tipo **recurso**.
- \\ [[:desarrolladores:tipo_recurso.png?400x308  }}|tipo_recurso.png]]
-A diferencia de los atributos anteriores (**FechaRealizacion **     y **Contexto**) acá podemos observar que el destino es dentro de la clave **“SEARCH”:{..}**      en vez de **“REST”:{..}**. El WS está ofreciendo herramientas de búsqueda. Repasemos como iría quedando conformado el nuevo request que pudimos armar en función de un response al realizar un request vacío.
-| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;inherit>Nuevo POST a ws.test.suap.com.ar/procesador/do/V1.0/ordenes     \\ "REST": {                  \\ “FechaRealizacion”:{“value”:”2018-07-02 00:00:00”},                  \\ “Contexto”:{“value”:”Ambulatorio”},               \\ },               \\ "SEARCH": {                  \\ “prescriptor”:{                  \\ “NombreCompuesto.contenga”:”Juan Perez”,                  \\ “DocNumero.contenga”:”123..”,                 \\ },               \\ }</font>  |
-Podemos ir observando que el WS nos indicó:
-    * Qué falta.
-    * Cómo requerirlo al usuario.
-    * Cómo enviarlo al WS nuevamente.
-Es decir, mediante una política sencilla, nos está ayudando a requerirle al usuario la información y a construir el request para enviar nuevamente el **POST.**
-=== Tipo transpuesta/mucho a muchos. ===
-Este tipo de widget representa relaciones entre recursos como el título lo indica. Mucho a muchos. Pensemos un poco como sería la incorporación de un conjunto de practicas a una orden en una especificación RESTfull. Por un lado para poder vincular una orden con un conjunto de items practica tendríamos que crear
-    * El recurso orden
-    * los recursos item
-    * vincular los recurso items con el recurso orden.
-Esto sería asi porque para poder vincular el recurso orden con los items necesito los tokens. Es un problema de orden de creación. El WS no permite crear items de forma aislada.
-**FALTA DOCUMENTAR**
-===== Políticas =====
 =====   =====
- \\ Como ya expusimos el WS de suap no es solamente una especificación de intercambio de datos, es además una serie de políticas. Dichas políticas se van guiando mediante las secciones STATUS y VIEW que responde el WS de suap.
-==== Política de persistencia. ====
-Persistencia en el sentido de que se instanció un recurso en la base de datos de suap. La política es simple. Un recurso solo puede ser instanciado a requerimiento del consumidor mediante un método //**POST**//. Si el contenido del response contiene una sección REST con un atributo **token**     diferente a **null**, entonces el recurso se persistió.
-|Persistencia en el sentido de que se instanció un recurso en la base de datos de suap. La política es simple. Un recurso solo puede ser instanciado a requerimiento del consumidor mediante un método POST. Si el contenido del response contiene una sección REST con un atributo token diferente a null, entonces el recurso se persistió. En cualquier caso si no hay token entonces se puede desestimar la transacción previa puesto que no tuvo repercusión en suap. |
-==== Política de acceso a un recurso. ====
-Para poder acceder a un recurso es necesario contar con la URI del mismo (Uniform Resource Identifier. Uniform en el sentido de constante). En el caso del WS de suap si se cuenta con el **Token **    de un recurso se puede construir la URI del siguiente modo.      \\  \\ **URI Base + ‘/’ + recurso en plural + ‘/’ + Token.**       \\  \\ A modo de ejemplo tomemos por caso una orden cuyo token es 1234.  En el entorno de test la URI de la misma sería:    \\  \\ Uri Base = [[https://ws.test.suap.com.ar/procesador/doV2|https://ws.test.suap.com.ar/procesador/doV2]]  \\
-recurso = orden    \\
-token = O1234.    \\
- \\
-**URI: [[https://ws.test.suap.com.ar/procesador/doV2/orden/O1234|https://ws.test.suap.com.ar/procesador/doV2/orden/O1234]]**  \\ Mediante el método **GET**a dicha URI se obtendrán todos los datos del recurso.
-==== Responsabilidad del WS de suap. ====
-Suap garantiza la información del recurso de la forma mas completa posible y mediante dos modalidades que se expresan en dos secciones del Json de respuesta.
-    * REST: Es la sección donde el recurso está detallado en terminos REST. Tomemos por ejemplo una orden cualquiera. En esta sección los atributos (fechas, estados de autorización, etc) estarán con sus valores, por el contrario los recursos relacionados (afiliado, prestador, prescriptor, etc) estarán representados por su URI.
-    * RENDER: En esta sección se representa un recurso en un formato resuelto para el consumidor. A diferencia de REST los recursos relacionados están representados por una nueva clave que contiene información ya
-==== Responsabilidad del consumidor ====
-El consumidor del ws debe cumplir las siguientes responsabilidades:
-    * Procesar la sección VIEW en cualquier POST (creación de un recurso)
-    * En la generación de un recurso siempre debe existir un atributo que puede escribir el usuario libremente. (campo mágico)
-    * Permitir al usuario hacer un GET de un recurso determinado con el procesamiento de la sección VIEW. Es decir, el consumidor podrá realizar los GETs que desee para administrar la sincronización entre su sistema y suap prescindiendo del procesamiento del view si lo deseara. Pero en algún lugar debe inlcuir un procesamiento de VIEW para el usuario.
-===== APÉNDICE =====
-==== Descripción de Recursos ====
-    * [[:desarrolladores:webservice_uso:recursos_desde_punto_atencion|recursos desde punto atencion]]
-    * [[:desarrolladores:recursos_desde_colegio|:desarrolladores:recursos desde colegio]]
 ===== Tipos de atributo =====
-==== timestamp ====
+[[:desarrolladores:webservice_uso:tipos_de_atributo|Tipos de atributo]]
-El tipo fecha es en realidad una fecha y una hora. El formato completo es:      \\  \\ AAAA-MM-DD HH:mm:SS      \\  \\ Por ejemplo el día 28 de julio de 2018 se escribe **2018-06-28 00:00:00**. Las horas van de 0 a 23. No hay am y pm.
-==== string ====
-=====   =====
-==== token ====
+====   ====
 ===== Estado autorización ORDEN: =====
-|**EstadoAutorizacion**  |**Texto**  |**Explicación**  |
+[[:desarrolladores:webservice_uso:estado_autorizacion_orden|Estado autorización ORDEN]]
-|0 |SIN_PROCESAR |La orden no pasó por ningún proceso de validación de forma completa |
-|1 |AUTORIZADA |Todas las prestaciones contenidas en la orden están autorizadas. |
-|2 |PARCIALMENTE_AUTORIZADA |Hay por lo menos una prestación de la orden autorizada y el resto de las prestaciones rechazadas. Esta orden contiene estrictamente prestaciones que están autorizadas o rechazadas. |
-|3 |REMITIDA_AUDITORIA |La orden en su totalidad está remitida a auditoría **a pesar de que contenga prestaciones autorizadas**. No es una orden consumible, está sujeta a la observación de un médico auditor la resolución. |
-|4 |RECHAZADA |Todas las prestaciones de la orden están rechazadas. |
-|5 |PARCIALMENTE_REMITIDA_AUDITORIA |La orden presenta al menos una prestación autorizada y una prestación remitida a auditoría. El resto de las practicas pueden estar rechazadas, autorizadas o remitidas a auditoría. Las practicas autorizadas de la orden se pueden consumir, pero las practicas pendientes pueden decantar en un rechazo o autorización luego de que el médico auditor observe la situación. |
-|6 |AUTORIZADA_EXTRA_SISTEMA |La orden puede ser facturada a pesar de no contar con una autorización por sistema informático. Está autorizada por un aval en papel. Puede requerir la carga de algún número de expediente o no. |
-|7 |REMITIDA_AUDITORIA_ADM |Idem el estado 3 pero será revisada por un auditor que no es médico. Esta situación es para aplicar controles que no requieren criterios médicos pero si debe ser revisado por un ser humano |
-|8 |PARCIALMENTE_REMITIDA_AUDITORIA_ADM |Idem el estado 5 pero será revisada por un auditor que no es médico. |
-===== Operadores de SEARCH =====
-Los operadores van sobre el final de la ruta del atributo del recurso y siempre en minúscula. Si se agregan de un mismo recurso varios criterios en diferentes atributos debe considerarse que se aplican todos unidos por el operador lógico **Y**    (AND).
-==== Igual ====
-El atributo debe ser igual al valor que se indica. Es como el operador == o = de algunos lenguajes. Por ejemplo:
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>{     \\ …            \\ “practicas.NBU.igual”:”660475”, …          \\ }</font>  |
-Aquí el recurso **practicas **      debe ser uno o varios tal que su atributo **NBU **      sea exactamente igual al valor 660475
-==== mayor / menor ====
-El atributo debe ser mayor o menor que el valor que se indica. En el caso de fechas y números es claro y en el caso de textos se respeta el orden alfabético.    \\ Son como el operador **> (mayor) y < (menor)**    de algunos lenguajes.
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>{     \\ …            \\ “fechaRealizacion.mayor”:”23062018”, …          \\ }</font>  |
-==== mayor_o_Igual / menor_o_Igual ====
 =====   =====
-Son lo mismo que el operador mayor o menor en cada caso, pero además el valor puede ser igual.    \\ Son como el operador >= **(mayor o igual) y <= (menor o igual)**    de algunos lenguajes.
+===== Operadores de SEARCH =====
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>{    \\ …            \\ “fechaRealizacion.mayor_o_Igual”:”23062018”, …          \\ }</font>  |
-==== contenga ====
-La condición de coincidencia se satisface si el texto dado está presente en alguna posición del atributo. Es como el operador **LIKE **      de algunos lenguajes.
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>POST a una búsqueda de afiliados    \\  https://uriBase/search.afiliados]]]]]]  \\  {           \\  …            \\  “Nombre.contenga”:”Guillermo”, …          \\  }</font>  |
-En el ejemplo se buscan todos los afilidos que contengan la cadena “Guillermo” dentro del atributo Nombre.
-==== in ====
-|<font 10pt:normal/Courier;;rgb(0,0,0);;inherit>POST a una búsqueda de afiliados    \\  https://uriBase/search.afiliados]]]]]]  \\  {          \\  …            \\  “Nombre.in”:”Guillermo”, …          \\  }</font>  |
-\\
+[[:desarrolladores:webservice_uso:operadores_de_search|Operadores de SEARCH]]

Ayuda en linea de SUAP

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página