IAC implementation for internet
Hi all,
I'm working on exposing a gadget to internet facing website. I've reviewed the Video Library, 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
Questions:
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.
Thanks,
Ravi
Hi Ravi,
I can help you out regarding your questions about [not] violating same domain origin policy. Please reference the bottom of this article.
https://pdn.pega.com/setting-gatewayurl-configuration-parameter
Thanks,
Rett
ConEdison
US
Now that browser same origin policy issue is clarified. Next question: where exactly should the gateway be deployed?
1) the webserver hosting the parent external application
2) a separate webserver exclusively for gateway
3) the webserver where prpc is running
Hi Ravi, yes, that is a common setup. prgateway should be accessible such that same origin policy is met - https://pdn.pega.com/setting-gatewayurl-configuration-parameter#sameoriginpolicy
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.
Pegasystems Inc.
US
Hi Ravi,
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.
David
ConEdison
US
Hi David,
We are on 7.1.8, I was able to generate the mash up code from case type though. Is there a variation on how it's generated in 7.2+ ? will that avoid reverse proxy as well ?
Pegasystems Inc.
US
Hi Ravi,
Yes, we are planning to eliminate the need for a reverse proxy for Web Mashup in the upcoming Pega 7.2.1 release - stay tuned for news about this in the PegaWorld time-frame!
David
ConEdison
US
Thanks David.
To summarize:
1) 7.2.1: The most advanced one, no gateway and no reverse proxy.
2) The versions below 7.2.1 : use the IAC JS file, Install Gateway, user reverse proxy/load balancer for meeting the same origin policy.
Is this correct ?
Pegasystems Inc.
US
The gateway is optional in all Pega 7 deployments and should not be used for Pega 7.2.1+
If the mashup code you generate has code to directly get the Javascript from your Pega application, then no IAC JS file is required. This should be true for Pega 7.1.8+
We are working to update the PDN documentation to make this clearer.
ConEdison
US
Ok, the JS is available if I generate the mashup code from Actions.
<script src='http://pegawebxxxx:123/prweb/PRServlet/diUaKsacMtre7L5yrCk0rSysO-2JIzOaNbGl5Fsimgg[*/!ApplicationName/$STANDARD?pyActivity=pzIncludeMashupScripts'></script>
<script>
pega.web.config.gatewayURL = "http://TestGateWay/web/PRPCGateway";
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.
Pegasystems Inc.
US
Hi,
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.
ConEdison
US
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.
Thanks.
Txs
US
Hi David
we need your help. Just generate mashup code directly from case type
<!-- ********************** Begin Pega content ********************** -->
<script src ='https://XXXXXXXXXXX/prweb?pyActivity=pzIncludeMashupScripts'></script>
<div data-pega-gadgetname ='PegaGadget'
data-pega-action ='createNewWork'
data-pega-action-param-classname ='XX-XX-XX-Work'
data-pega-action-param-flowname ='pyStartCase'
data-pega-action-param-model =''
data-pega-isdeferloaded ='false'
data-pega-applicationname ='XXXX'
data-pega-threadname ='STANDARD'
data-pega-systemid ='XXXXXXXXXX'
data-pega-resizetype ='stretch'
data-pega-url ='https://XXXXXXXXXX/prweb' ></div>
Hi David
we need your help. Just generate mashup code directly from case type
<!-- ********************** Begin Pega content ********************** -->
<script src ='https://XXXXXXXXXXX/prweb?pyActivity=pzIncludeMashupScripts'></script>
<div data-pega-gadgetname ='PegaGadget'
data-pega-action ='createNewWork'
data-pega-action-param-classname ='XX-XX-XX-Work'
data-pega-action-param-flowname ='pyStartCase'
data-pega-action-param-model =''
data-pega-isdeferloaded ='false'
data-pega-applicationname ='XXXX'
data-pega-threadname ='STANDARD'
data-pega-systemid ='XXXXXXXXXX'
data-pega-resizetype ='stretch'
data-pega-url ='https://XXXXXXXXXX/prweb' ></div>
<!-- ********************** End Pega content ********************** -->
when we run the above code in mash up, we are getting below error.
| Status | fail |
| Message | There has been an issue; please consult your system administrator |
| Operator ID | Unauthenticated or not available |
| Requestor ID | No ID available |
| Timestamp | Tue Apr 11 21:45:45 UTC 2017 |
| Engine Version | PegaRULES 7.20 ML1 (coreAssemblyCached_721_916) |
based on pdn forums we Understand that we have to use IAC URL for mash up code.
how to generate IAC authentication URL for pega mash up pages in 7.2.1 version?
thank you for your support in advance.
Regards
Kishore