Question
Coforge DPA Limited
CA
Last activity: 14 Jan 2020 11:56 EST
Mashup Deployment files to be in Pega instead of ClientSide
Current approach:
The Chatbot mashup files are deployed in external website.The files are generated in Pega (WebChatConfigurationPortal) and meant to be deployed in external website.
Client is recommending to change to below approach:
To avoid dependency on third party website and hosting the js file and css file in pega instead of external website.
What is the reason to host the js file and css file in external website and not in pega?
***Edited by Moderator Marissa to update SR Details***
Pegasystems Inc.
US
There would be a few downsides.
First, pega doesn't generally serve unauthenticated content...you must have a requestor session and be authenticated. Even if authenticated as a guest this would mean every anonymous user would be consuming heap for their requestor session which would be a scalability issue on a site where there are many users but few who actually interact with the chatbot/chat widget.
Second, the mashup typically requires some adjustments by hand before being deployed. The self service portal doesn't have sufficient options to generate code without being altered at this time. This may be for purposes like determining whether the button displays or not, removing references to CoBrowse, minification of the javascript, etc.
Third, public access to the Pega server is often restricted via WAF or reverse proxy for security purposes. For example you might use SiteMinder to ensure that only customers logged in to the website are allowed to contact the Pega server. This would only impact certain customer scenarios but there at least needs to be an option to serve this content from another source.
There would be a few downsides.
First, pega doesn't generally serve unauthenticated content...you must have a requestor session and be authenticated. Even if authenticated as a guest this would mean every anonymous user would be consuming heap for their requestor session which would be a scalability issue on a site where there are many users but few who actually interact with the chatbot/chat widget.
Second, the mashup typically requires some adjustments by hand before being deployed. The self service portal doesn't have sufficient options to generate code without being altered at this time. This may be for purposes like determining whether the button displays or not, removing references to CoBrowse, minification of the javascript, etc.
Third, public access to the Pega server is often restricted via WAF or reverse proxy for security purposes. For example you might use SiteMinder to ensure that only customers logged in to the website are allowed to contact the Pega server. This would only impact certain customer scenarios but there at least needs to be an option to serve this content from another source.
Fourth, if the static content was served by the Pega server this would mean the server would need to be sized to handle loading of static content of many anonymous users. Imagine a website where 10,000 users visit and 10 request a chatbot session. The Pega app servers can be sized to handle 10 concurrent users. If the widget static content is served from that app server, it will need significantly larger resources (CPU, memory, network) to handle the 10,000 users.
Finally, you actually could serve this content from the Pega app server. Any application server could have an additional application/servlet installed to serve static content off the filesystem instead of from the Pega database. As far as I know this isn't a service offered by Pega Cloud but could be implemented on any customer-owned environment. However a standard best practice for performance is to host static content on an edge server, a server tuned for fast static content, or a CDN. It would only make sense to serve static content from the Pega app server in a dev/test or a low volume environment where sizing is less of a concern.