Change of OperatorID without impacting users & work
We are using Single Sign-On authentication and our company will have to change the ActiveDirectory. The unique identifier for the operators will change (i.e. donald.duck@myco will become ABC123). This change has to be transparent for our end users and we need to make sure that everything which exist in the system (work, assignments, attachments, parties, managers of work groups, substitute operators, reports to, etc....) remains/becomes available for the new user ID.
Is there a bulk database tool or anything else that can find&replace the old ID with the new one in the whole system?
If we have to do this manually, how can we identify all the OOTB components/rules where the OperatorID has an impact and needs replacement?
Any suggestions, ideas or previous experiance around such problme is highly appreciated!
***Edited by Moderator Marissa to update SR Details***
Pegasystems Inc.
FR
Hello,
That sounds like a difficult task really. Finding all references with old OperatorID identifiers is quite complex (you did not mention case history for example) and in general we are not recommending to remove OperatorIDs.
Maybe you shouldn't try that and just keep old and new ones. Or just reassign cases and assignments and nothing else.
Zodiac Aerospace
FR
Indeed!
But we don’t have many options as once the users get transferred to the new AD, their old operator practically cease to exist, as they can no longer login with it.
You are right that History may contain user name, but even if we don’t change anything there, it will still be functional. Not the same if we don’t update the WorkObject or the Assignments or Pulse.
I could find a simple way to do find&replace within data & work, now the challenge is to find all OOTB classes that are relevant/prerequisite for such change. The one’s identified/considered at this moment below
|
Work |
Work- related classes |
|
Assignments |
Assign- related classes |
|
WorkParies |
Index-WorkPartyUri |
|
Attachments? |
Indeed!
But we don’t have many options as once the users get transferred to the new AD, their old operator practically cease to exist, as they can no longer login with it.
You are right that History may contain user name, but even if we don’t change anything there, it will still be functional. Not the same if we don’t update the WorkObject or the Assignments or Pulse.
I could find a simple way to do find&replace within data & work, now the challenge is to find all OOTB classes that are relevant/prerequisite for such change. The one’s identified/considered at this moment below
|
Work |
Work- related classes |
|
Assignments |
Assign- related classes |
|
WorkParies |
Index-WorkPartyUri |
|
Attachments? |
Data-WorkAttach- related |
|
Link? |
Link- related |
|
Work Group |
Data-Admin-WorkGroup |
|
WorkBakset |
Data-Admin-WorkBasket |
|
Operator ID |
Data-Admin-Operator-ID |
|
Operator's Image |
Data-Content-Image |
|
delegated personally |
System-User-MyRules |
|
Operator's Preferences |
Data-Preference-Operator |
|
Following |
Link-Association-Follow |
|
Personal Category |
Rule-Category |
|
Shortcuts |
Rule-Shortcut |
|
Tags |
|
|
Pulse messages |
PegaSocial-Message |
|
Scheduled reports |
Pega-ScheduledTask-Reporting |
Any more ideas are highly appreciated!
Updated: 16 Nov 2018 5:19 EST
Pegasystems Inc.
IN
My suggestion would be not to try and go with replace approach as it would require updates at many places and you can never be sure to cover everything.
Can you try something in authentication activity where even though user logs in with new operator and logic switches to old operator behind the scene? End user should not be generally concerned about IDs. This way everything will work smoothly. You just need some logic to maintain link between old and new operator IDs and switch using some logic in authentication activity.
Interesting problem though :)
Zodiac Aerospace
FR
Thanks Rawap,
This actually was the initial approach considered here. We still have some outstanding concerns with that - there are some OOTB places where the operator ID will become visible i.e
- in Pule when using @ mentions ( we may consider rising an SR for that, as the
Thanks Rawap,
This actually was the initial approach considered here. We still have some outstanding concerns with that - there are some OOTB places where the operator ID will become visible i.e
- in Pule when using @ mentions ( we may consider rising an SR for that, as the
- in transferring an assignment when selecting Operator (pyTransferAssignment, but that one can be easily customised)
- in Custom data maintained by user where we used the OpeartorID (we have to consider to apply there re-mapping as well)
The question will be more whether we want to live with such a re-map forever, or apply a one-time-off operation - each approach having its own advantages & risks…
EvonSys
LK
As I understand you need to change the Name in AD such as donald.duck@myco to donaldduck@myco and still refer same physical operator. However, you may have to consider few points below,
- Direct data manipulation using SQL may not work as BLOB will have old record and will replace exposed column values if work object saved from Pega (action taken by a user). Thus, need to use Pega based mechanism like a one Time Rule (OTR).
- Seem like you like to compromise History record change ! otherwise, it require massive data manipulation across History Classes.
- Resolved and Archived (if Archiving is used) work objects also needs to be considered.
- You need to consider your Data load in PROD, and plan the process accordingly considering performance i.e. Multiple nodes to process etc.. to archive timing in PROD.
Considering all facts, you may have to go for a Pega Rule that will use OBJ methods as opposed to Direct DB Calls. Your list seems to be comprehensive, consider below as well.
Correspondence: Correspondence records will have Senders’ email which will get change with AD change.
will post if something new comes to mind….