Foreign Tables
We have a use case where we want users logging in/available in one platform to be easily accessible to users of another platform running pega.
Is it safe to designate pr_operators as a shared table? Do we have any customers who have implemented this successfully? Is this supported for postgres? Does this handle both read and updates seamlessly?
Thanks
Sethu
***Edited by Moderator: Lochan to update platform capability tags***
Pegasystems Inc.
US
Consider using custom authentication (like SSO) to grant access to a set of users to multiple Pega applications.
As you know already, the pr_operators table just holds the operator details, but accessing another platform depends on the access group/application/portal mappings, just having a shared table won't work. There are also other dependent tables for operator preferences, skills, workgroups. In any case, I don't think it's a safe approach, but you can still look forward to hearing other opinions if anybody has tried.
Manheim
US
Harish,
The goal is not to access the other platform, but just to be aware of the available operator IDs (from the other platform) and their availability, whether they are active etc to facilitate assigning work.
We are already aware of 1 option (synchronizing operators from the other platform) to track availability, however operator signons/activity have to be then captured/cascaded through some API Call. Just wanted to check and confirm if a foreign table option was ever used by any customers for a similar use case.
Thanks
Sethu
Pegasystems Inc.
US
Sethu,
I got your use-case now. As the goal is just to be aware of available OperatorID's from other platforms, pr_operators table should be sufficient. Each instance contains the operator details (columns) along with the pylastsignon(column), availability(blob), skills(blob) and workgroup (column) & workbasket(blob) mapping information.