E9.2 http status in groovy

[Stank1964]

I have an outbound REST API that I am calling with ORCH. All is well with it. Sometimes, the request is successful, but the response is empty, there is no returned payload. So, when my groovy code tries to parse a blank response to figure out what happened, it doesn't go well. I assume that with a blank response, I would get that same result if the request timed out. There needs to be very different handling in JDE based on a valid response vs. a timeout request. Does anyone know what I can do about this?

Thanks.

 

[DaveWagoner]

Timeout (504), not found (404), no auth (401), and generic error (500) should hopefully show up as an error within the orch rather than a success (200) which can be even if the return body is blank. This is one where the writer of the API may have their own practice (and their practice may change) as to whether they feed an error or not in their responses. Fun stuff
Here I've intentionally pointed a connector to a nonvalid url to time it out.

 

[Stank1964]

Hi Dave and thanks for the reply. In your exmaple the API returns something, in my case it's blank or empty. There is not function where I can get the response in groovy is there? With something in the response, I can parse it with groovy and act on it appropriately. With nothing, I don't know how to act.

 

[DaveWagoner]

The client will return a response (not the endpoint) when there is something like a timeout. Result = error in orchestration that you can handle.
The endpoint host will (hopefully-- most host software seems to handle this stuff consistently) return a response with no auth, or server error. Result = error in orch that you can handle.
Finally the endpoint itself will return whatever it was programmed to return, in your case even a successful API call may return a completely blank response. It sounds to me like in your example, if you AREN'T seeing an error, then the call was successful, regardless of whether there's anything in the body of the response.

Your groovy to handle the response (or lack of response, despite a success connect) falls AFTER the connector component that would have thrown error if there was an error returned in the API response header. If the orchestration reaches that groovy, then you ought to be able to safely assume that the API call worked. It then is up to you to handle the response, whether populated or blank Great ways within groovy to handle blank inputs.

 

[DaveWagoner]

As an aside I'd really love to be able to handle return status code as a "standard" output field on a connector component. When I get more time I'll play to see if I can extract it or get at it. But in the raw response it's technically in the header, but it has no label, so it's hard to know what to "map" in the connector response header. Wonder if anyone has figured this one out.

 

[DaveWagoner]

Even in postman you have to "bend over" a bit to see the status header in the response, in the console. You open the response in console then you must ALSO click "view raw" there. Yes, all clients (including connector) have status handling built right in but sometimes we might want to get at those status #s. We may want to handle a 500 differnetly from a 401 from a 404. Sounds like an enhancement request unless I'm missing something!

 

[Stank1964]

One thing I've noticed in the response below... The API produce http status = 400. Notice the time stamps in the this response. They seem to be appended with the http status -0400. Could this really be true? If so, what a hack this is Oracle. If this is how Oracle implemented this, shame, shame. I wonder if a successful response also has the timestamps appended with the http status... I"m looking into it



{
"message": "Orchestration has no output",
"timeStamp": "2023-08-03T08:54:33.230-0400",
"continuedOnError": [
{
"step": "55CN_SAPeCommerceOrder_Connector",
"message": {
"ServiceRequest: 55CN_SAPeCommerceOrder_Connector": {
"statusCode": 400,
"error": "java.lang.Exception: External Generic Call Failed See Log For Details: 400 {\n \"errors\" : [ {\n \"message\" : \"The order has already have shipped consignments, includeShippingTaxValue must be false\",\n \"type\" : \"OMSValidationConsignmentError\"\n } ]\n}",
"headers": {}
}
},
"timeStamp": "2023-08-03T08:54:33.230-0400",
"userDefinedErrorText": ""
}
],
"jde__simpleMessage": "Continued on Error\n1 - 55CN_SAPeCommerceOrder_Connector failed: java.lang.Exception: External Generic Call Failed See Log For Details: 400 {\n \"errors\" : [ {\n \"message\" : \"The order has already have shipped consignments, includeShippingTaxValue must be false\",\n \"type\" : \"OMSValidationConsignmentError\"\n } ]\n}",
"jde__status": "WARN",
"jde__startTimestamp": "2023-08-03T08:54:32.454-0400",
"jde__endTimestamp": "2023-08-03T08:54:33.230-0400",
"jde__serverExecutionSeconds": 0.776
}

 

[Stank1964]

It's not true. Here is a successful response, that 0400 is appended there as well... The actual http status was 200 in this case. It makes no sense and

{
"ConnectorRequest1": {
"totalTaxValue": 14.64
},
"jde__status": "SUCCESS",
"jde__startTimestamp": "2023-08-03T09:40:14.769-0400",
"jde__endTimestamp": "2023-08-03T09:40:15.364-0400",
"jde__serverExecutionSeconds": 0.595
}

 

[DaveWagoner]

grr! i wish they'd be consistent about the statusCode field at the main orch level. at least.

The -0400 might be the time zone, I can't remember the name of the date/timestamp format.

 

[Stank1964]

I think you're right, the -0400 might be some offset from UTC. The http status such a standard thing, not retruning it on a connector makes little sense to me.