Legacy Dev Forum Posts

Twin_Engines | 2016-06-16 22:59:57 UTC | #1

Hello, I am developing a web service so PureCloud can connect to it and pull data, I have all contract methods implemented and they work fine using postman to test it, but once we tried to make the call it always returns 204 No Content as a result, but POSTMAN brings up the data, I used your API to develop the webservice.

I need to know if the request I am expecting and the response are correct, the thing is as I am not getting time out I guess it does connect to the webservice, but can't figure out why would it say No Content found while POSTMAN brings the information.

This is what I expect and what I response (GetAccountByPhoneNumber), also I will attach my call flow so maybe I can get feedback

Thanks,

.<img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/43bb38fca431073c6e8755434bc24be98913fc41.jpg" width="293" height="500">

This is the schema of what I expect and what I respond. { "PhoneNumber": "", "CustomAttribute": "" }

And I get this as response:

{ "Account": { "Addresses": { "Address": [ { "City": "", "Country": "", "Line1": "", "Line2": "", "Line3": "", "PostalCode": "", "State": "", "Type": "" } ] }, "CustomAttribute": "", "EmailAddresses": { "EmailAddress": [ { "EmailAddress": "", "EmailType": 1 } ] }, "Id": "", "Name": "", "Number": "", "PhoneNumbers": { "PhoneNumber": [ { "Number": "", "PhoneType": 1 } ] } } }

anon5606108 | 2016-06-17 14:06:52 UTC | #2

Hi Twin_Engines,

An error of No Content is the error we expect if your web service cannot find any matching entries. Is it possible that you implemented this, and that your web service simply is unable to find an account matching your input?

Based on what you've mentioned in your question, I would take the following steps to troubleshoot:

• If not already enabled, configure or develop your Web Service to trace requests and responses it receives and sends.
• Execute both your PostMan query and a test call. Compare the requests and responses received in these two situations. If there are differences here, there may be an issue with input. Phone number formatting is a possible culprit - if the phone number is formatted differently in Architect than what you have in your PostMan request, that could be your issue.
• If differences exist between the request, you can use PostMan to debug by exactly mimicking the request payload your service receives while processing the call flow.
• If no differences are observed between the PostMan and call flow payloads, you may want to look at the Connector logs for possible issues. Our documentation provides instructions for this here: https://help.mypurecloud.com/articles/troubleshoot-web-services-data-dip-connector/

If you require any assistance with any of the steps I suggested, please feel free to reply back to this thread. If you have done those steps and still experience an issue, we may be able to help with that as well. If you do have further questions, it would be helpful to see an example request/response from your Web Services server, so that I might compare it to known good examples we have.

Twin_Engines | 2016-06-17 19:29:24 UTC | #3

Thanks a lot for the quick reply and great suggestion, the NoContent functionality and the Conflict one are implemented, I just created a log and it saves the request and response that postman sends and gets but once we try the call flow it is not saving any request so it may not be properly connected to the webservice.

The endpoint of the webservice is in the image of the initial question, also the callflow, the number we are looking for is hardcoded in the input "PhoneNumber" on the bridge action, we set up the connector with some one in PureCloud so can't really tell if we are missing something, maybe if you could give me any critical information we must put in there could be helpful to ensure our configuration is right, I did follow all your documentation and checked each step was configured and everything looks fine.

Thanks a lot for the help.

I was wondering as well if we need any sort of authentication?, as we are not requesting any data from purecloud I don't see why we would need one but if you can let me know please, I did read all the documentation about it but everything points out to be something I would need to use if we were requesting data which we are not.

UPDATE:

Hey sorry, I was just checking the connectors log for today (6/17/2016) and I see errors... is this relevant to my issue?, the PureCloud bridge server is in the same server the webservice is.

Sample (There are more errors listed):

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: The handshake failed due to an unexpected packet format. at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

anon5606108 | 2016-06-17 20:03:08 UTC | #4

Hi Twin_Engines,

It seems likely that the System.Net.WebException could be part of the issue, especially if the service itself does not report any requests and responses from the Bridge Server. To troubleshoot connectivity issues further, I would suggest the following possible courses of action:

• If you have not already done so, attempt to run PostMan from the Bridge server, using the same query as you have previously seen working from other locations. If you are able to get PostMan to work from the Bridge, we can eliminate nearly all possible connectivity issues.
• Use PostMan to call the Action Endpoint on its own. When you place a call through Architect, what actually happens behind-the-scenes is that Architect calls a REST Endpoint. You can call this REST endpoint yourself. If you're familiar with our APIs, the endpoint you will need is /bridge/api/v1/actionCall/YOURACTIONNAMEHERE. You should be able to use the same input payload as before, and should receive "flattened" payload back from the Action call. This will eliminate any possible issues associated with the execution of your Architect flow. I've chosen to omit the full process for calling the Bridge API, because it would clutter the response. If you get to this step and are unsure about how to authenticate and call that API, I will provide full instructions.

Finally, to answer the questions you asked before your reply: First, if everything looks the same as how we document it, that should be all you need. I do not know of any vital information that we did not put in our documentation. If we find any through the course of this troubleshooting session, we will add that to the documentation. Second, there is no authentication necessary for using the Data Dip Connector through the IVR system.

Please let me know the results of the latest troubleshooting steps, and any other troubleshooting you've done, and I'll be happy to assist further!

Twin_Engines | 2016-06-20 21:42:15 UTC | #5

Thanks again for the quick answer, postman works on the bridge server, I don't have clear how to set up the endpoint you gave me, I did set up postman with the purecloud environment and I have an OAuth2 key that I use with it, but I don't think I understand how to call it from postman, I am trying this:

/bridge/api/v1/actionCall/YOURACTIONNAMEHERE

http://HUSSV031/api/v1/actionCall/GetAccountByPhoneNumber

I am not sure if bridge is the name of the bridge server, anyway I am getting an error connecting to that endpoint.

Could not get any response This seems to be like an error connecting to http://HUSSV031/api/v1/actionCall/GetAccountByPhoneNumber. Why this might have happened: The server couldn't send a response: Ensure that the backend is working properly SSL connections are being blocked: Fix this by importing SSL certificates in Chrome Cookies not being sent: Use the Postman Interceptor extension Request timeout: Change request timeout in Settings > General

Thanks for all the help so far.

UPDATE: Hey sorry, I was just doing some research about the error I posted and looks like it is related to the system waiting for an authentication and it should not so I followed a couple of Microsoft guides about the topic doing a couple of changes on IIS, opened the port on the firewall (though it is not directly related to the error), so my issue is something around that error as the connector is getting his connection shut down, we should do a quick test tomorrow in order to check that.

anon5606108 | 2016-06-21 13:21:56 UTC | #6

Hi Twin_Engines,

Based on your update, it looks like you have a plan of action from your side, so I definitely encourage you to do that first and see if that resolves your problem. If not, I have more information on the endpoint you can call to test below.

First, I apologize for being unclear about how to call the endpoint. I see you have an Oauth2 key, and that is good. I am assuming you configured that key based on this article: https://developer.mypurecloud.com/api/rest/postman/index.html. It should not matter if that is not the case, but my instructions will be assuming that you've done the things listed in the article. This has been tested based on an Oauth2 key generated by those instructions.

It should be noted that this process on its own will not fix anything - it is simply a way to test which may produce more immediate feedback than calling the action through an IVR.

1. The endpoint you will need to call is: https://apps.{{environment}}/bridge/api/v1/actionCall/YOURACTIONNAMEHERE, where YOURACTIONNAMEHERE corresponds to the name of your published Bridge action.
2. The body of this request should be the same as the body for your Web Services server request. Be sure to set the content type to application/json in the headers.
3. You should apply authorization in the same way as presented in the article above, with one caveat: once the bearer token is in the headers, you will need to ensure that the word "bearer" is all lowercase. Unfortunately, the Bridge API is case-sensitive about the word, and Postman, at least in my test environment, supplies a capital B.
4. Assuming your data matches something that your Web Service will return, you should receive a flattened version of the return body. The flattening process moves everything from its nested objects to the top layer, with a '.' separating the layers. If your call does not return data, an error should be produced.

Please let me know if my troubleshooting instructions, or your own investigations provide any further insight as to what the issue might be.

Twin_Engines | 2016-06-21 20:42:11 UTC | #7

We noticed in the configuration for the integration that the web service is pointing to a URL that contains an internal server name (http://hussv031/HabasitWebService.svc). The HUSS031 is the internal server name... will this work correctly with the PureCloud integration and resolve correctly? Or does this web service need to be an externally accessible URL? We should note that the web service is set up on the same server as the bridge server.

The error on the connector's log (System.IO.IOException: The handshake failed due to an unexpected packet format.) is related to an ssl negotiation going wrong so it closes the request connection, what exactly makes the call to the webservice?, if the webservice and the bridge server are located in the same machine it should be able to connect to the web service without any ssl certificate? or something in the cloud is doing the request so it is not being able to get to the server?

Below is the response we got from the postman test: { "ErrorMessage": "Operation timeout: no response received from server." }

UPDATE: Hey thanks a lot for all the help you provided, looks like now it is working with POSTMAN, it is bringing data using the bridge action ENDPOINT, tomorrow we will test if it works on a call flow, we did change the port we were using to be 80 and also created an outbound rule on the firewall for the port 443 on the bridge server, can't tell what exactly fixed the issue but looks fine now, hopefully it will work on the call flow.

Twin_Engines | 2016-08-11 14:56:04 UTC | #8

Good Morning,

Just saw this Post and noticed i didn't mention what the issue really was, well the problem was that the bridge actions in the admin site had their ids corrupted and were not recognized in the architect when it was running, the data-dip service logs never pointed out to this so it took a developer from Purecloud to figure that out.

Solution: Just deleted the old actions and created them again.

system | 2017-08-28 19:24:56 UTC | #9

This post was migrated from the old Developer Forum.

ref: 86