Question
B.Braun group
BR
Last activity: 16 Jan 2022 20:41 EST
Where in the Pega academy is something about URL mappings?
Somebody knows where in the Pega academy web classes is a topic about URL mappings? It is interesting that Pega have this feature, but it is nowhere to be found in the academy. Well at least I did not found.
Pegasystems Inc.
AU
It does seem a bit more hidden away than it could be. I've not come across it in Academy yet, but I would recommend the following information on Pega Community:
Application-level URL aliases:
URL aliases within an Application:
- 8.5.x: https://community.pega.com/sites/default/files/help_v85/procomhelpmain.htm#rule-/rule-urlmappings/main.htm
- 8.2.x: https://community.pega.com/sites/default/files/help_v82/procomhelpmain.htm#rule-/rule-urlmappings/main.htm
The two work together a bit. URL aliases within an Application include aliases for Case Types, Reports, Landing Pages as well as "Other". The URL Mappings rule instances are accessible in Dev Studio from the Records explorer: go to Technical > URL Mappings.
There is a single instance that is included out of the box. Since the Help suggests the rule must be called pyDefault, and that only one can be defined per application, it seems the configuration approach is to create your own pyDefault URL Mappings rule instance in an application-specific ruleset, so that rule resolution resolves to your specialization ahead of the Platform one.
The 8.2 help has some more links than the 8.5 help, and these seem to confirm the above.
It does seem a bit more hidden away than it could be. I've not come across it in Academy yet, but I would recommend the following information on Pega Community:
Application-level URL aliases:
URL aliases within an Application:
- 8.5.x: https://community.pega.com/sites/default/files/help_v85/procomhelpmain.htm#rule-/rule-urlmappings/main.htm
- 8.2.x: https://community.pega.com/sites/default/files/help_v82/procomhelpmain.htm#rule-/rule-urlmappings/main.htm
The two work together a bit. URL aliases within an Application include aliases for Case Types, Reports, Landing Pages as well as "Other". The URL Mappings rule instances are accessible in Dev Studio from the Records explorer: go to Technical > URL Mappings.
There is a single instance that is included out of the box. Since the Help suggests the rule must be called pyDefault, and that only one can be defined per application, it seems the configuration approach is to create your own pyDefault URL Mappings rule instance in an application-specific ruleset, so that rule resolution resolves to your specialization ahead of the Platform one.
The 8.2 help has some more links than the 8.5 help, and these seem to confirm the above.
Please report back with how you went and whether it could meet your objective.
B.Braun group
BR
@BraamSmithCLSA the first link you provide it is for version 8.5, and also do not match our requirements because our needs is to be able to send a link within an email and make the recipient able to access the case through the email. To accomplish that we will need to use URL mappings, which we try to implement, but for some reason we are getting always a 404 page. Besides that we also need to send the access group as one of the parameters, that is because our operators can have more than one access group, so we also need to send the access group, and the sample we have and follow it use a activity pxOpenByKeys which does not have the access group as parameter so we cannot use it. We try to use the pxOpenByKeys version but we also got 404 response. So we as part of the Pega community expect to have that funcionality also describe in the exercises to practice and have a real world example of it. How Pega can expect us to answer questions about that topic on the certification exams if they dont have that on their certification preparation? And also that is one of the requirements we have for our application here.
Pegasystems Inc.
AU
Now that you've clarified your problem scenario, I can point you in a direction that you may find more useful.
To include a link to Pega in an email, you want to make use of a feature like the Public Link URL configuration feature. Whilst this documentation is marked as 8.5, this has not changed for a long time. Use this feature to include the publicly accessible URL to Pega in the links you include in emails.
It is used in conjunction with calls to the getPublicLinkURL function in Correspondence rules, look at pxOpenAssignmentLink or WorkLink as reference implementations. You may even want to include these in your Correspondence rules for they solve the problem of constructing publicly accessible links to an assignment or work item (respectively).
Passing Access Group names as parameters is dangerous:
Now that you've clarified your problem scenario, I can point you in a direction that you may find more useful.
To include a link to Pega in an email, you want to make use of a feature like the Public Link URL configuration feature. Whilst this documentation is marked as 8.5, this has not changed for a long time. Use this feature to include the publicly accessible URL to Pega in the links you include in emails.
It is used in conjunction with calls to the getPublicLinkURL function in Correspondence rules, look at pxOpenAssignmentLink or WorkLink as reference implementations. You may even want to include these in your Correspondence rules for they solve the problem of constructing publicly accessible links to an assignment or work item (respectively).
Passing Access Group names as parameters is dangerous:
- As Access Groups are data instances, it is more likely that their names can change as business needs evolve. This approach can lead to the Access Group names being hard-coded into rules meaning that a change in Access Group name also requires code refactoring.
- Unless implemented very rigorously, this can be a security exposure. Can you assure that if a malicious user doesn't pass in ?AccessGroup=OurAppAdministrators that this will always be blocked for users that don't possess this access group?
The Application-level URL aliases I linked to above solve for this by finding first access group on the Operator's access group list that points to an application whose URL alias matches the one provided in the request. This is preferable because the link indicates what application the user intends to use, without publicly naming the security context in which to use it. That is, the user is assured to be entered into the requested application:
- Only if they are authorised to use that application (on their Operator ID Access Group List); and
- Only in a security context that has been provisioned to them for that application.
If this feature is not available on your version of Pega, it would be a compelling reason to upgrade to the newer version to utilize this new feature (and others), rather than having to configure a custom solution that involves Access Group parameters.
As the Public Link URL feature significantly pre-dates the Application URL aliases, I'm not sure how well these work together. The Public Link URL includes the default alias identifying the Pega webapp (prweb, unless otherwise overridden in web.xml). If your use case is looking to send an email with a public link to a different application, you may need to:
- Implement a new Dynamic System Setting to hold the public link up to - but not including - the alias
- Use the getDataSystemSetting() function to retrieve its value from your Correspondence rule
- Have additional logic to derive the appropriate application alias for the application you want the email recipient to use when they open Pega from the link.
I hope this helps, and do ensure in future you clarify your scenaro up front, to avoid discussion that is not relevant to your problem.
B.Braun group
BR
@BraamSmithCLSA thank you for your reply, I really appreciate that. I will try what you suggest.
Updated: 4 Feb 2021 3:14 EST
B.Braun group
BR
@BraamSmithCLSA but dont you think that the link with all the information will be exposed as well with the implementation you suggest me above? It is exactly what I want to avoid, to have explicit showing in the url(link) key words like [email protected]&ThreadName=WorkLinkThread&bPurgeTargetThread=true&AccessGroupName={$save(Accessgroup)}&Location={$save(RedirectLocation)}">{.pyID}, etc
and I think those examples that you gave me pxOpenAssignmentLink, WorkLink and pyWorkLinkWithLabel, only works if the recipient have the same access group as the sender right? And the recipient it can be from a different access group.
Pegasystems Inc.
AU
With any web application, there needs to be enough instructions in the request to instruct Pega on the action that needs to be performed. Yes it is quite ugly and - assuming your email recipients are receiving HTML-formatted emails - it would be nicer if the URL was part of a hyperlink from more user-friendly text, like:
<a href="url-goes-here">Click here to open your case in Pega</a>
... rather than being written verbatim into the body of the email. Use the existing rules as inspiration for your own; better still, try to 'include' them so that you are not duplicating the implementation.
Making this less ugly is no doubt one of the drivers behind the new URL aliases within an application feature from my first response to this thread. These provide more user-friendly URLs to common operations (like "open a case") that can be activated from channels that are outside of a Pega portal (like emails).
Regarding the sample Correspondence rules (that use getPublicLinkURL), and any coupling to the access group of the sender...
With any web application, there needs to be enough instructions in the request to instruct Pega on the action that needs to be performed. Yes it is quite ugly and - assuming your email recipients are receiving HTML-formatted emails - it would be nicer if the URL was part of a hyperlink from more user-friendly text, like:
<a href="url-goes-here">Click here to open your case in Pega</a>
... rather than being written verbatim into the body of the email. Use the existing rules as inspiration for your own; better still, try to 'include' them so that you are not duplicating the implementation.
Making this less ugly is no doubt one of the drivers behind the new URL aliases within an application feature from my first response to this thread. These provide more user-friendly URLs to common operations (like "open a case") that can be activated from channels that are outside of a Pega portal (like emails).
Regarding the sample Correspondence rules (that use getPublicLinkURL), and any coupling to the access group of the sender...
- Pega ensures the user clicking a link to an operation (that requires authentication) is authenticated to Pega before attempting to perform it.
- The authenticated user is, at any point, using one of the Access Groups listed on their Operator ID. This defines that user's current authorization context... ... Pega knows who they are; and Pega knows what they are allowed to do at this point in time.
- When Pega receives the request to perform the action - such as, when the user clicks the link on the email - the action requested is evaluated against the user's current authorization context. If the receiving user's authorization context does not allow the operation to be performed, Pega will return an authorization error.
So, the Access Group of the sender of the link typically has no influence over whether the receiver of the link is authorized to perform that operation.
- The link describes the action to perform, and the authentication channel to use (if not yet authenticated);
- Pega evaluates - on demand - whether the authenticated user is authorized to perform the operation specified in the link.
If the action you are linking to accepts an Access Group name as a parameter, suggesting that the requestor can choose the authorization context the action can run in, then that is not much different to wiring the user's password into the URL. Both must be avoided; allow the Pega engine to authorize the request naturally.
National Institutes of Health
US
@BraamSmithCLSA - can you tell me which activities should be used for each type of URL Mapping. I have not been able to find this anywhere. I can see in the OOTB pyDefault rule that "pxOpenByKeys" can be used for the Case Mappings. What about Reports and Landing Pages, what's the correct activity here? And what's the difference between how these different mapping categories are handled? Any help is appreciated.
Thanks,
Kevin
Pegasystems Inc.
AU
I am hoping that @krism2 can point you in the right direction to make a start on adopting URL Mappings for Reports and/or Landing Pages. I have not seen anything published about them yet.
This may vary by Pega Platform version, and also by whether you are UIKit or Cosmos.
In the interim, I would try:
- Use the Tracer when running the report or opening the landing page to see what the out of the box Activity is at the start of the call chain
- Implement an Activity that attempts to emulate what you do as a user in the portal. Ideally you can get it to run only with the parameters you expect to receive via your mapped URL. This example for configuring a Cases URL mapping shows opening a work item receiving only the Work ID from the URL mapping (the work pool is assumed)
- Configure a URL Mapping to leverage your Activity from #2 above, wiring in the resource paths from the URL to the parameters of the Activity.