Posted: 30 Mar 2016 15:10 EDT Last activity: 11 Apr 2017 17:57 EDT
IAC implementation for internet
I'm working on exposing a gadget to internet facing website. I've reviewed the PegaTube videos, PDN articles...etc and here is the summary as per my understanding:
1) PRGateway is mandatory for internet deployments
2) The gadget manager file (JS file) and PRGateway should be in the same network domain
3) One the PRGateway is deployed, the PRPC application becomes web-node and developers cannot access that instance for development or admin purpose
a) In which infrastructure should exactly the PRGateway should be deployed? is it in the webapplication that's consuming PRPC gadget or actual PRPC environment ?
b) Network domain means, is it just the last part or FQDN should match ? I may have my intranet application's serving thru testcompany.net/home and internet testcompany.com/home. or There may be sub applications in intranet testcompany.net:1001/home for java applications, testcompany.net:1002/home for .net application...etc
c) Even with a gateway, will I run into same origin policy issues ? (This may be the reason why#2 is required)
Any insight into this would be very much appreciated. The reference material available is pretty difficult to understand.
below options are valid, given same origin policy is met.
1) the webserver hosting the parent external application
2) a separate webserver exclusively for gateway
(it is not recommended to deploy both prgateway and prweb on the same server.)
location of the gateway is not that important for the same origin policy; its the URL for the gateway that is referenced in the iac gadget is important for the same origin policy. you could use webserver proxy plugin/load balancer to achieve same origin policy.
in the example mentioned in the above article, www.pega.com/ can be proxy/load balancer that routes the request to gateway which is deployed in different server.
I believe you got the product road map on this from David via other discussion thread.
What version of Pega 7 are you using? With Pega 7.2+ you can use Pega Web Mashup gadgets without the gateway. Just generate your mashup code directly from your case type. As Gopi notes, for current Pega releases you would need a reverse proxy in place to ensure the web browser sees Pega content as being served from the same origin as the main website.
What factors should be considered for using or not using a gateway for 7.1.8 ? or what features will we loose if there is no gateway ? It's critical for us to know, because we have to plan for additional web servers, capacity planning for them and add them to current legacy load balancer (if reverse proxy method is not chosen). It's not always very easy to deal with legacy load balancers. Thanks.
The Pega gateway is a time-tested and proven solution when other methods for doing reverse proxy are not available or easy. If you are facing challenges with using another reverse proxy server as you've indicated, then for the Pega 7.1.8 release I would continue to utilize this component. When you upgrade to Pega 7.2.1+ you can then consider removing the gateway (or your reverse proxy) fully.
If I understand your comment correctly, gateway is the solution if a reverse proxy implementation is difficult or not possible. But still the gateway should be configured in such a way that the same origin policy is met. In order for this to happen, I'm back at deploying the gateway on the same host as of gadget client (not possible in many cases) or choosing a reverse proxy or load balancer. Because most of the large scale enterprise applications are deployed in multiple domains or load balancer devices(F5, NetScalar...etc). This makes the IAC implementation really complex and confusing.
These are the next steps I'll be taking:
1) Configure the reverse proxy as per the available PDN documentation and try to expose the gadget directly to the client without a gateway.
2) If #1 doesn't work, then install gateway, implement reverse proxy on gateway URL this time.