SajidAbbasMalek | 2018-08-12 13:31:13 UTC | #1
This web service call works fine in Postman whereas fails in Custom data action Test with below error.
{ "message": "The request timed out.", "contextId": "5fde5e1b-a2a4-4330-8d09-b9f3b5a5ffff" }
Input Contract
{ "$schema": "SCHEMA URL", "type": "object", "required": [ "cardType", "cardNumber", "cardExpiry", "cardSecurityCode", "token" ], "properties": { "cardSecurityCode": { "type": "string" }, "cardExpiry": { "type": "string" }, "cardType": { "type": "string" }, "cardNumber": { "type": "string" }, "token": { "type": "string" } } }
Output Contract
{ "$schema": "SCHEMA URL", "type": "object", "required": [ "success", "message", "isOTPRequired" ], "properties": { "isOTPRequired": { "type": "string" }, "success": { "type": "string" }, "message": { "type": "string" } } }
Request
{ "requestUrlTemplate": "https://XXXXXXXXXXXXXXXXXXXXX/pay", "requestType": "POST", "headers": { "Content-Type": "application/json", "clientID": "CallCenterIVR", "Authorization": "${input.token}", "Transfer-Encoding": "buffered" }, "requestTemplate": "{\r\n \"systemId\": \"CallCenterIVR\",\r\n \"entityId\": \"GF7R68\",\r\n \"paymentId\": \"43533790\",\r\n \"sessionId\" : \"XXXXXXf\",\r\n \"paymentMethod\" : \"CARD\", \r\n \"currency\": \"INR\",\r\n \"amount\": \"10.0\",\r\n \"requestType\": \"TRAVEL\",\r\n \"cardDetails\": {\r\n \"cardType\": \"${input.cardType}\",\r\n \"cardNumber\": \"${input.cardNumber}\",\r\n \"cardExpiry\": \"${input.cardExpiry}\",\r\n \"cardSecurityCode\": \"${input.cardSecurityCode}\"\r\n },\r\n \"billTo\": {\r\n \"firstName\": \"asdwe\",\r\n \"lastName\": \"iopipo\",\r\n \"street\": \"vcbnvn\",\r\n \"city\": \"erte\",\r\n \"state\": null,\r\n \"postalCode\": null,\r\n \"country\": \"AQ\",\r\n \"emailId\": \"das@aws.com\"\r\n }\r\n}" }
Response
{ "translationMap": { "success": "$.success", "message": "$.message", "isOTPRequired": "$.isOTPRequired" }, "successTemplate": "{\r\n \"success\": \"${success}\",\r\n \"message\": \"${message}\",\r\n \"isOTPRequired\": \"${isOTPRequired}\"\r\n}" }
Jason_Mathison | 2018-08-13 12:27:16 UTC | #2
For purposes of testing a data action in the UI there is a hard 10 second time limit. In your case the call to the third party web service is taking 14 seconds, causing the overall action to timeout.
If it is expected (and acceptable) for this web service to take this long, you could take the output from postman and either setup a static route to return this results right away, or use a tool like mockable.io to return a static response.
There is no hard 10 second time limit when processing inbound calls/emails/etc.
SajidAbbasMalek | 2018-08-19 15:13:38 UTC | #3
I have found out the reason why this action is getting timed out?
Its because the target web service is not using Port 443 which is a required in case of PCI compliance.
Now I have a problem. Can't use the custom data action due to 443 issue and if we use bridge data action instead, it does not support passing secure variables from architect.
Jason_Mathison | 2018-08-20 13:55:17 UTC | #4
Based on the contextId that you provided in your initial post, I don't see any indication that the remote web service is ignoring your request on port 443. After 14.7 seconds the remote host returned a 200 response code. Because this was longer than the hard 10 second UI timeout you are seeing a failure in the UI.
If this really is an issue with the remote web service not processing requests on port 443 the only solution that comes to mind is to create a intermediary web service that handles forwarding the request on to the right port.
SajidAbbasMalek | 2018-08-26 08:22:36 UTC | #5
Thanks Jason,
Yes this makes sense... GUI is not actually waiting more than 10 seconds but what about below limitations?
https://help.mypurecloud.com/faq/can-we-call-a-web-service-running-on-a-port-other-than-443/ https://help.mypurecloud.com/articles/data-action-web-services-data-actions-integration-times/
The problem with adding an intermediary web service is, customer wont do that, we will need to create this by introducing a Bridge Server. Which will make this transaction non-PCI compliant... as its a payment web service. It has to be secure and PCI-DSS compliant. Moreover our payment IVR collects customer's credit card information.
Jason_Mathison | 2018-08-27 10:46:52 UTC | #6
For the issue with Data Actions only being able to connect via port 443, are you sure that is an issue? Our logs indicated that the web service returned a 200.
For the issue with the UI timeout, we are seeing if we can extend that timeout, however I can't say if that will happen or not. Regardless, you could work through configuring your action by capturing responses with a tool like postman, then return those pages statically with a tool like mockable. The UI timeout has no impact on using your Data Action from the IVR.
You are correct that bridge actions do not support secure actions. I would highly recommend that you try to work through the kinks of using Data Actions instead. Out of curiosity, what payment processor are you using?
SajidAbbasMalek | 2018-08-27 17:31:28 UTC | #7
Thank you Jason.
I am not saying 443 is an issue. Forget about UI timeout for the moment, My confusion is
- Documentation says web data action won't allow integration with web service which is not communicating over 443 for PCI compliance.
- This payment web service is using random port to send response and yet you confirmed via logs 200 success is received.
Question is how? as per my understanding 200 should not have received in the first place.
Anyways, let me get back to you after trying the approach you suggested.. Mockable static resonse pages.
Customer did not expose the payment processor to us. They have just exposed a couple of web services to fetch the session id, then to create token and then to execute the payment request. Moreover not all of the web services are returning json either. I am right now trying to get all their web services to return json first and then attempt the integration.
I'll ask them whats the underlying payment processor and let you know.
Jason_Mathison | 2018-08-27 19:03:09 UTC | #8
This payment web service is using random port to send response and yet you confirmed via logs 200 success is received.
When the data action service connects to the third party it will use a random port on the Data Action side, but always connect to port 443 on the 3rd party web service.
From https://www.bleepingcomputer.com/tutorials/tcp-and-udp-ports-explained/ On the other hand, if you are the remote user connecting to a web server it would work in reverse. Your web browser would pick a random TCP port from a certain range of port numbers, and attempt to connect to port 80 on the IP address of the web server. When the connection is established, the web browser will send the request for a particular web page and receive it from the web server. Then both computers will disconnect the connection.
system | 2018-09-27 19:14:16 UTC | #9
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 3358