Status:500, internal.server.error.."errors": []

Data Actions
1

Hi Guys!
I am having a somewhat confusing problem.

sending a request to my API.
Checking with the API, the data comes back to PureCloud, however it fails in PureCloud with the following message:

This is under the 8th step "Execute" of testing.
{
"status": 500,
"code": "internal.server.error",
"message": "The server encountered an unexpected condition which prevented it from fulfilling the request.",
"messageParams": {},
"contextId": "8f077452-661c-4e5e-a4e6-2dacbfcbd813",
"details": [
{
"errorCode": "ACTION.PROCESSING"
}
],
"errors": []
}

Configuration:
{
"requestUrlTemplate": "https:///api/Payment/GetCustomer",
"requestType": "POST",
"headers": {
"Content-Type": "application/json",
"Authorization": "Basic YTpi"
},
"requestTemplate": "{\n "customerId": "{input.CustomerId}\",\n \"zip\": \"{input.CustomerZip}" \n}"
}

The data:
"{\n "customerId": "1901150001",\n "zip": "77380" \n}"

The response ( caught with ngrok):

HTTP/1.1 200 OK
Date: Wed, 04 Sep 2019 15:42:10 GMT
Content-Type: application/json; charset=utf-8
Server: Kestrel
Transfer-Encoding: chunked

af
{"customerFirstName":"", "customerLastName":"", "dueAmount":"", "dueAmountUnposted":"", "dueNow":"", "pastDue":"", "unPostedAmounts":""}

af = 175

Regardless what the response configuration is, it fails with the above error message.

This is only one of the many response configurations that I have tried.
{
"translationMap": {},
"translationMapDefaults": {},
"successTemplate": "${rawResult}"
}

2

Hi Zoltan_Torteli,

I would suggest trying out our "unexpected failure" workaround:

If that doesn't work, your next step is to open up a case with customer care. We are not able to troubleshoot 500 errors in the forum.

--Jason

3

Hi Jason,

The service works with the {"Transfer-Encoding": "chunked"} header. And actually fails with the {"Transfer-Encoding": "buffered"} header.

What I could tell, that the response was sent from the API, but it was not (properly?) processed by PureCloud.

Is there a way to see a deeper debug message by using the contextId? I could look at that before posting a customer care ticket.

Zoltan

4

May be you need to change

From

{input.CustomerId}

To

${input.CustomerId}

5

Dear All,

It appears, that the problem was caused by an exception in the WebAPI.

While it appeared that all the data was transmitted - visually observed -, there was still an "Unexpected EOF" that I could see only with an inspection service. And this - I believe - somehow triggered PureCloud to fail in the reception of the response.

Eliminating the exception in the WebAPI rendered PureCloud to accept the message with success.

1 Like
6

Hi Zoltran_Torteli,

I'm glad you were able to figure this out! The correlation ID that you provided allowed me to see that we were having an error processing the web service response unlike any error I have seen before.

The reason that {"Transfer-Encoding": "chunked"} worked is that in chunked mode the web service returns chunks of the response, without indicating how long the entire response will be. In buffered mode it says that the response will be exactly X bytes. Since the web service had a failure, the total response was less than X bytes, causing the Data Action to blow up since it didn't get the response size it was expecting.

To answer your earlier question, correlation IDs make it possible for support and development to research issues with Data Actions in our logs, however customers do not have any access to the Data Action logs.

--Jason

7

Thank you for your response!

Is it possible that PureCloud Action is not sending Content-Length header, just the content...as this is what I seem to observe now.

Zoltan

8

In "buffered" mode the Content-Length header is set, in chunked mode it is not. The benefit of chunked mode is that a web service could start sending a response before it has finished creating the response.

In practice we run across web services that only support one or the other, even though the RFC indicates that all web services should support both.

--Jason

9

Thank you, Jason!

Now I have one more questions.

I am initiating a test of an Action on the "Test" tab by pressing the "Run Action" button.
For my surprise, the request would hit my server twice with different "Inin-Request-Id"s.

The first:
Inin-Request-Id c191d402-137c-435f-be83-204e47e84d40

The second:
Inin-Request-Id c155f39a-7f4b-4034-a7a0-b1e7e9fc1044

However the Action - when comes back - shows the response for the first one.

I am testing the same API from Postman, and that sends the requests only once.

Might there by something I did wrong?

Z.

10

There is a bug in the UI that when flattening is enabled, two test executions happen. We have an internal ticket open for that issue.

--Jason

11

And one question more:

Under the "Action Contracts" for the Input contracts, I would set a field for type: "boolean". Save it.

When reloading the page, the type:"boolean" would be gone from the field..

Like this:
"AutoDraft": {
"description": "To be charged repeatedly (boolean)",
"type": "boolean"
},

Reload:
"AutoDraft": {
"description": "To be charged repeatedly (boolean)"
},

Z.

12

Thank you.
Unchecking the "flatten output" solved it.

13

The UI team is actively working on fixing the issue with types disappearing.

--Jason

14

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.