We have deployed Pega 24.1.2 in a private, on-premise environment using containerized deployment model.
To test Constellation UI in Sales Automation Insurance, we have also deployed a local Constellation App Static Content Service.
Pega Platform and CASCS share same toplevel domain (but different subdomains) and CASCS has a valid TLS certificate.
We have also deployed recent security fix.
When accessing Constellation UI, we see many CORS errors in Browser, similar to the following:
Access to fetch at 'https://pega-constellation.tld.com/c11n-appstatic/v102/app/<resource>.json' from origin 'https://pega-env.tld.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Is there a suggested way to configure CASCS to include a “Access-Control-Allow-Origin” response header?
Do you have other tips and suggestions why our setup fails?
@MalteR In principal, there should not be a problem. We have many setups of different network architectures, with no issues. I am guessing that something small has gone wrong.
Browsers incorrectly report many network errors as CORS errors. A couple of checks initially:
For your app web page, in the network requests, you should see the http OPTIONS call before the http GET call . OPTIONS call should be a 200 response. if that is good, and the get fails, that suggests that the requested content is missing. check the http response body for details
thanks for the input. We did some adjustments and it seems now exactly as you described. We get a first OPTIONS call with a 200 followed by a 400 GET-call. In the response body we get something like this:
/usr/src/app/dist/customers/<ENV>/<APP>/locales/en-US/COMMON-LDM-ENTITY-CONTACT!ASSOCIATED!TYPEID.json has not been synced for this environment
Sadly the remedy-steps do not help. As we have a fresh installation and are working with the defautl locale it should work. We did not set up additional things so adding more translations should also not be neccessary.
@NigelJohnsonThanks for your reply. That pointed us in the right direction.
Indeed the issue was not caused by CORS issues but simply a problem of mapping the correct port and route in our OCP K8s environment.
Once the Constellation Application Static Content Service could be reached correctly from the network, the HTTP communication started working.
The remaining issues are about localization.
One seems to be a version mismatch between language packs and installed version of Pega Common Data Model (CDM). Contrary to other language packs the localization rulesets do not match the versioning scheme of the app rulesets - and also they seem to be non-cumulative.
We’re trying to solve this by installing the correct version via INC-C6538.
The other problem is about loading Insurance Reference data. It seems the context root (part of URL) has been hardcoded in Pega out-of-the-box Rule-Connect; but this needs a bit more investigation. For now we have reverted to default “prweb” and trying to get everything to work…
@MalteR as the original issue relating to CORS errors has been resolved (as per INC-C5445), I will mark as ‘Accept Solution’ the above reply. This will mark the thread as resolved and will help build the GenAI search algorithm which in turn might help other users who encounter the CORS error in the future.
(I can see that our support team helped clear up some questions about the Marketplace translation files via INC-C6538 and a new issue relating to SAPortal not being translated is still being investigated in INC-C7477).
If you wish to ask further questions about the Pega Common German Language Pack 24.1 feel free to ask a New Question.
@NigelJohnsonthanks for the support. I think we are now looking at two issues. One beeing the localisation, where we get above mentioned problems with sync. Here we tried reimporting with no further improvement.
The other problem seems to be the creation of the OAuth2. After some try and error we found the issue beeing a duplication of the clientid. Meaning the OAuth2 client registration we had for the application had the same clientid as one of the common-app. We are not sure how this has happened, but after some clean up this now seems to work. So the main issue now seems to be with localization. Can you give us a hint on what to do there?