Error when consuming external service.

As you work with http instead of https I would propose to add:

CURLOPT_SSL_VERIFYHOST => false,
CURLOPT_SSL_VERIFYPEER => false,

I am testing the various options. Thank you very much for the answers.
I have tried adding this in my code, but the response is: "Empty reply from server:
CURLOPT_SSL_SSL_VERIFYHOST => false,
CURLOPT_SSL_VERIFYPEER => false,

I could also try to consume the service with Guzzle as proposed by Enes Saridogan , but I get the same response: "Empty reply from server".

The strange thing is that both codes I was able to test them on a localhost outside sugarCRM and they worked.

Could this be a problem with the service "">pruebas.dinissan.com.co/.../crearOrModificarCliente" ?

Regards.

Hi Juan Diego Rojas Valencia

If you can provide more details (error messages, logs, print screens) would help to understand what's going on.

As Harald mentioned, by adding those "non-secure" CURL options should do the trick, even though is not at all recommended. 

Our cloud instances are in a safe TLS environment, should not mix contents/protocols.

Could you also "curl -x PUT ..." from your instance to your "pruebas.dinin..." and post here, so we can compare the headers? (if there's confidential info, you can hide or send it directly to me) once we have it figured out, I'll post it for reference.

My gut tells me that this is a TLS/Non-Secure environment type of issue but also headers play a big part on negotiating contents and authorizations.

Hi Juan Diego Rojas Valencia

If you can provide more details (error messages, logs, print screens) would help to understand what's going on.

As Harald mentioned, by adding those "non-secure" CURL options should do the trick, even though is not at all recommended. 

Our cloud instances are in a safe TLS environment, should not mix contents/protocols.

Could you also "curl -x PUT ..." from your instance to your "pruebas.dinin..." and post here, so we can compare the headers? (if there's confidential info, you can hide or send it directly to me) once we have it figured out, I'll post it for reference.

My gut tells me that this is a TLS/Non-Secure environment type of issue but also headers play a big part on negotiating contents and authorizations.

Hello Rafael Fernandes

Thank you very much for your reply.

I have shared to your email the code we are testing with.

The response I get in the sugar log is: "Empty reply from server".

I have performed the test using cURL
curl -X PUT -H 'Content-Type: application/json' -H 'token: security token​' -d '{"sasa_tipo_persona_c":"N","sasa_tipo_documento_c":"C","sasa_numero_documento_c":"1020719578","sasa_nombres_c":"Rene","sasa_primerapellido_c":"Fernandez","sasa_last_name_2_c":"SEG APE 30906374","sasa_tipodirec1_c":"1","sasa_municipio_principal_2_c":"05001","billing_address_street":"Calle 1 45 45","sasa_tipodirec2_c":"","sasa_municipio_secundario_2_c":null,"shipping_address_street":"","sasa_tipodirec3_c":"","sasa_municipio_3_c":null,"sasa_direccion3_c":"","sasa_codigopostal3_c":"","sasa_cel_principal_c":"3005466682","sasa_cel_alternativo_c":"","sasa_cel_otro_c":"","sasa_tipotel1_c":"","sasa_ciudad_tel_principal_2_c":"11001","sasa_phone_office_c":"","sasa_extension_c":"","sasa_ciudad_tel_alternativ_2_c":null,"sasa_phone_alternate_c":"","sasa_extension2_c":"","sasa_tipotel2_c":"","sasa_ciudad_tel_3_c":null,"sasa_tel_phone_other_c":"","sasa_extension3_c":"","sasa_tipotel3_c":"","listEmail":null,"facebook":"","twitter":"","website":"","sasa_nivel_educativo_c":null,"sasa_profesion_c":null,"sasa_ocupacion_c":null,"sasa_cargo_c":null,"sasa_ingreso_mensual_c":0,"sasa_tipo_de_vivienda_c":null,"sasa_estrato_c":null,"sasa_regimen_fiscal_c":"","sasa_estado_civil_c":null,"sasa_tiene_hijos_c":null,"sasa_numero_hijos_c":null,"birthdate":null,"sasa_edad_c":"0","sasa_genero_c":"M","sasa_cliente_fallecido_c":null,"sasa_fuente_c":"Sugar"}' pruebas.dinissan.com.co/.../crearOrModificarCliente​

From a terminal on our server the cURL request works.

Thank you very much.

Hi Everyone,

Just in case someone runs into this issue as well, we found the issue.

We pretty much nailed it down after doing all of the work our dev community posted as well as some of my own:

• Juan's HTTP works to retrieve auth token but not other endpoints in the same host
• This ruled out all the infrastructure issues we could have such as:
  • non-secure content (http) over TLS (https)
  • CSP policies
  • CURL (verify host/peer) to false
  • Firewall, WAF or any other cloud infra
• Using Postman, I realized that his "create" endpoint was taking too long
  • Exactly 3s to execute from here and 2s from Postman's cloud
  • Our Cloud policy states: "Outbound HTTP connections must have timeouts under 1 second"
  • https://support.sugarcrm.com/Resources/Sugar_Cloud_Policy_Guide/#Additional_Considerations

In other words, Juan's server NOT responding fast enough and our cloud policy was being enforced by "dropping the tcp connection" under 1s, therefore, returning "empty from server".

Sugar enforces those policies strictly, please make sure you review it often.

Rafa