Preguntas sobre instalación.

[Leonel Leonardis]

A mi me funciona bien:

Código: [Seleccionar]

curl -u admin:123456789*-a --data "respuesta=ACEPTADA&respuesta_descripcion=OK" http://localhost:7271/boletows/sube_actualizar_solicitud/SIUG3/T367894621651257260


Código: [Seleccionar]

{"codigo":1,"mensaje":null,"datos":{"resultado":true}}
Ojo, si en config/entorno.inc.php le pongo:

Código: [Seleccionar]

define('ES_PRODUCCION', true);
define('USA_CACHE', true);


Código: [Seleccionar]

curl -u admin:123456789*-a --data "respuesta=ACEPTADA&respuesta_descripcion=OK" http://localhost:7271/boletows/sube_actualizar_solicitud/SIUG3/T367894621651257260


Código: [Seleccionar]

<br />
<b>Fatal error</b>:  Uncaught Error: Call to undefined function apc_delete() in /usr/local/app/boleto_estudiantil/WS/lib/Cache.class.php:27
Stack trace:
#0 /usr/local/app/boleto_estudiantil/WS/web/index.php(28): Cache::cachear()
#1 {main}
  thrown in <b>/usr/local/app/boleto_estudiantil/WS/lib/Cache.class.php</b> on line <b>27</b><br />

Hay que tener instalada la extensión PHP APC, o sino en el archivo lib/Cache.class.php reemplazar las funciones apc_xxx() por apcu_xxx(), por ejemplo apcu_store en lugar de apc_store.

saludos.
2

[Fernando Velarde]

Ellos, enel Ministerio, están recibiendo

RESPONSE: Curl failed with error #1: Protocol "http" not supported or disabled in libcurl

a)  Si yo pongo directo en el navegador   (no estoy especificando POST porque es la barra de URL ...)
http://34.232.173.37/boletows/sube_actualizar_solicitud/UPE01/T229906141651845643

Recibo  {"codigo":-1,"mensaje":"El metodo HTTP utilizado es incorrecto","datos":{"tipo_error":"aplicacion"}}      (Lo más parecido al error de ellos)

b)  Haciendo por CURL
curl -u uperest:miclave --data "respuesta=RECHAZADA&respuesta_descripcion=TRAMITE_EXPIRADO" http://34.232.173.37/boletows/sube_actualizar_solicitud/UPE01/T229906141651845643

Recibo  {"codigo":1,"mensaje":null,"datos":{"resultado":true}}    (Lo correcto,  que está funcionando)

c)  Haciendo cualquiera de estas dos  por el REST Client con POST
http://34.232.173.37/boletows/sube_actualizar_solicitud/UPE01/T229906141651845643?respuesta=ACEPTADA&respuesta_descripcion=OK   

o
http://34.232.173.37/boletows/sube_actualizar_solicitud/UPE01/T229906141651845643
y este JSON
{
"respuesta": "ACEPTADA",
"respuesta_descripcion": "OK"
}

Recibo     { "codigo": -1,  "mensaje": "La cantidad de parametros no es correcta.",  "datos": { "tipo_error": "aplicacion"  }}

Algo me está faltando en esta prueba pero no me puedo dar cuenta qué....

Las preguntas que me hago ahora ...

Los trámites en el Ministerio se están evaluando, ya que en listado que ellos mandan, hay algunos con estado "HABILITADO"
Supongo que la falla en el Curl, afecta a la actualización de los estados de trámite en nuestra base de datos porque creo que eso es lo que hace el sube_actualizar_solicitud ..

1) Hay un Curl que está generando error...     ¿Ese Curl sería del código  del Ministerio, y es la forma que utilizan ellos para llamar a nuestro WS sube_actualizar_solicitud ?      ¿Podría existir la chance que ellos lo tengan habilitado solo para https y no http ? 

2) ¿ El código de sube_actualizar_solicitud    donde me devuelve los mensajes de error ,   estaría  en WS/clases  ?

3) ¿ Qué me estaría olvidando para porbarlo en el REST CLIENT ? y ver si consigo el OK  o la réplica del error...

Gracias !!

[Leonel Leonardis]

Te respondo:

a)  Si yo pongo directo en el navegador   (no estoy especificando POST porque es la barra de URL ...)
http://34.232.173.37/boletows/sube_actualizar_solicitud/UPE01/T229906141651845643

Recibo  {"codigo":-1,"mensaje":"El metodo HTTP utilizado es incorrecto","datos":{"tipo_error":"aplicacion"}}      (Lo más parecido al error de ellos).

Claro, porque en el navegador es como hacer un GET y el método debe ser POST.

b)  Haciendo por CURL
curl -u uperest:miclave --data "respuesta=RECHAZADA&respuesta_descripcion=TRAMITE_EXPIRADO" http://34.232.173.37/boletows/sube_actualizar_solicitud/UPE01/T229906141651845643

Recibo  {"codigo":1,"mensaje":null,"datos":{"resultado":true}}    (Lo correcto,  que está funcionando)

c)  Haciendo cualquiera de estas dos  por el REST Client con POST
http://34.232.173.37/boletows/sube_actualizar_solicitud/UPE01/T229906141651845643?respuesta=ACEPTADA&respuesta_descripcion=OK

Claro, porque estas haciendo por POST.

http://34.232.173.37/boletows/sube_actualizar_solicitud/UPE01/T229906141651845643
y este JSON
{
"respuesta": "ACEPTADA",
"respuesta_descripcion": "OK"
}

Recibo     { "codigo": -1,  "mensaje": "La cantidad de parametros no es correcta.",  "datos": { "tipo_error": "aplicacion"  }}

No va por JSON, se manda por "form-data".

1) Hay un Curl que está generando error...     ¿Ese Curl sería del código  del Ministerio, y es la forma que utilizan ellos para llamar a nuestro WS sube_actualizar_solicitud ?      ¿Podría existir la chance que ellos lo tengan habilitado solo para https y no http ?

Claro, el Ministerio de Infraestructura y Servicios Públicos de la Provincia de Buenos Aires llama a esos servicios cuando el formulario a completar por el alumno expira "respuesta=RECHAZADA&respuesta_descripcion=TRAMITE_EXPIRADO", o cuando el beneficio es aceptado "respuesta=ACEPTADA&respuesta_descripcion=OK".

Nosotros en su momento hicimos pruebas y no usábamos https, pero igualmente le podes consultar a ellos en el email ​contactouniversidades.minfra@gmail.com

2) ¿ El código de sube_actualizar_solicitud    donde me devuelve los mensajes de error ,   estaría  en WS/clases  ?

Claro, seria WS/clases/ConsultaSubeActualizaSolicitud.class.php.

3) ¿ Qué me estaría olvidando para porbarlo en el REST CLIENT ? y ver si consigo el OK  o la réplica del error...

En el curl del punto b) te esta respondiendo bien, podes ver en la tabla mbe_solicitudes y revisar si cambiaron las columnas respuesta, respuesta_fecha, respuesta_desc y procesado.

RESPONSE: Curl failed with error #1: Protocol "http" not supported or disabled in libcurl

Es una mala instalación de curl, que ejecuten curl --version | grep Protocols y vean si soporta el protocolo http.
Referencias:
https://bbs.archlinux.org/viewtopic.php?id=228681
https://forum.openmediavault.org/index.php?thread/19842-protocol-http-not-supported-or-disabled-in-libcurl/

saludos.
4

[Fernando Velarde]

Gracias Leonardo por toda la ayuda...

Es una mala instalación de curl, que ejecuten curl --version | grep Protocols y vean si soporta el protocolo http.

Algo de eso hubo.... pero el Ministerio no lo reconoció....  tampoco me importa que no lo haya reconocido sino que funcione....
Luego que les contamos a ellos casi todo en forma parecida a como lo contamos en este Post,  de un día para otro empezó a funcionar bien, pero dicen no haber tocado nada.

Así que Guaraní ya está terminado.

El punto que nos queda es que tenemos dos sistemas distintos. El viejo de alumnos de 2019 para atrás (donde antes funcionaba el ws)  y el Guaraní.  Le pedimos al Ministerio dos usuarios distintos para que cada usuario apunte a un ws diferente y listo, pero nos negó esa posibilidad.  Así que el único ws que quedó relacionado con ellos es el de Guaraní.

Lo que se me ocurre es tocar la clase para que elija en que sistema escribir.... Si el trámite está en la tabla de Guaraní, ok... y si no está en la tabla de Guaraní que vaya a escribir la tabla del sistema viejo (en MySQL)

[Leonel Leonardis]

Hola Fernando,

Lo que se me ocurre es tocar la clase para que elija en que sistema escribir.... Si el trámite está en la tabla de Guaraní, ok... y si no está en la tabla de Guaraní que vaya a escribir la tabla del sistema viejo (en MySQL)

Vas a tener que personalizar el Web Service de Sube:

1) En config/basesDeDatos.inc.php vas a tener que agregar una conexión a mysql.

2) En clases/ConsultaSubeActualizaSolicitud.class.php funciones:
2.1) getParametrosQuery: Acá obtenes los parámetros de conexión a la DB.
2.2) existeSolicitud: Valida si existe la solicitud en la DB.
2.3) setConsulta: Arma la query para actualizar la solicitud en la DB.

saludos.
2