Unsuccessful Alexa integration using Pega PE V8.x/7.4 (localhost:8080) running on Tomcat
Hi Pega Experts,
I see there are some of the folks who were successful in Alexa integration using Pega. But I didn't see any posts for a successful integration with Pega PE version. I tried to implement the integration functionality mentioned in the article:https://community.pega.com/knowledgebase/articles/intelligent-virtual-assistant/configuring-iva-alexa but I was unsuccessful to receive the response back to my local host after tunneling of it using ssh command (ssh -R 80:localhost:8080 ssh.localhost.run) from command prompt. Not sure where I went wrong but I noticed that Alexa tried to call our REST service as per the article using my server URL setup done in Alexa integration settings. The interesting part I noticed is that the Pega REST service URL is not yet all accessible globally from the site: https://www.uptrends.com/tools/uptime. Here is my REST service URL in terms of local host perspective.
Amazon servers must be able to access your instance, as I can see you know that because you made a ssh tunnel to expose the port on public IP and domain. What worries me is that you tunneled port 80 which is not SSL, I assume it is either a mistake or you have openssl on that 80 to expose SSL on 443 (or localhost.run has this functionality).
First of all, you need to verify if exposed service is visible on the internet ("The interesting part I noticed is that the Pega REST service URL is not yet all accessible globally from the site" - this tells me it is not). This is something you need to check and solve any network configurations problems related to port exposure.
The other thing is that you need to have a proper and valid SSL certificate for the domain you expose the service on, otherwise Amazon Alexa will refuse to connect (https://developer.amazon.com/docs/custom-skills/host-a-custom-skill-as-a-web-service.html). I don't know how localhost.run service works and whether they provide valid SSL certificate or not. Try to access the exposed service using wget (-d -v to see cert logs) or simply via browser and observe SSL status (click on the lock icon).
I run wget on your endpoint and I see SSL errors:
--2019-09-05 11:40:00-- https://rpisupat-xpw3.localhost.run/prweb/PRRestService/alexachannel/srv/alexa
Resolving rpisupat-xpw3.localhost.run (rpisupat-xpw3.localhost.run)... 22.214.171.124
Caching rpisupat-xpw3.localhost.run => 126.96.36.199
Connecting to rpisupat-xpw3.localhost.run (rpisupat-xpw3.localhost.run)|188.8.131.52|:443... connected.
Created socket 3.
Releasing 0x000000000212cfb0 (new refcount 1).
Initiating SSL handshake.
SSL handshake failed.
Closed fd 3
Unable to establish SSL connection.
1) You won't be able to use browser to verify whether the Alexa service works as the service expects to be accessed by legit amazon requests (Amazon Alexa requires we must verify certificates coming from the requests). That's why in the browser you see 401 - you can take a look in pega logs and observe log entries stating sth along the lines above.
You may want to use browser to access /prweb to verify whether both tunneling + https work (but you should use https and external url). If /prweb works then all the services underneath should work, too. Of course in Alexa console you must provide external url.
2) The service endpoint you see in REST configuration is just a hint how you should access the service. The system itself doesn't know how you reconfigure the outside world to access the system.
Thanks for the reply. I was actually having some n/w issues with my laptop and is very slow. Not only that is the reason for my issue. There was a place where I did not select the proper configuration from Alexa’s Endpoint configuration. After your suggestions, I went line by line and corrected the setup using a new skill created. By the way, I didn’t bother about ports -> 8080 or 443 or 8043 as it is mentioned in the article. I just ran ngrok and took the https URL and called PRRestService accordingly. Whole testing from console, I started seeing the REST service method calling steps from the tracer. That made me confident on the successful of this POC. This is just a starting point for me and I need to learn more in this space.