Question
Wipro Limited
CA
Last activity: 3 Apr 2024 3:15 EDT
Unable to pass other Operator ID for History-Add ForOperatorID Parameter
Hi All,
I am trying to update data table instances (Data-) of a class through a backend queue processor submitted by end users.
As part of data update, I am trying to add audit note in history table.
For History-Add method, I am passing HistoryMemo = Param.Memo and ForOperatorID = Param.UserID or Page.UserID. nothing seems to work. History is still getting added with me (pxRequestor.pyUserIdentifier) as pyPerformer.
Aren't we allowed to pass literal or property reference for pyPerformer column ?
LTIMindtree Limited
IN
Ideally the History-Add should have worked. Can you please try Data-.History_Add activity once and see if it works?
Wipro Limited
CA
@AdrijaC7 Thanks for Suggesting alternate approach. Data-.History_Add is working in same manner. I am passing Custom value for ForOperatorID but history still getting added for "me".
LTIMindtree Limited
IN
I guess this parameter will only take a valid operator ID which is present in Data-Admin-Operator-ID class. So please check once if you are providing a valid operator ID in the field.
LTIMindtree Limited
IN
Can you check once by putting the operator ID value on the ForOperatorID parameter field and try to click on the target icon beside, this will open the operator ID instance you want to add. Thus you can see if the correct operator ID is being set or not.
LTIMindtree
IN
@Ashish_PundirPlease check once whether this parameter value is setting or not in the tracer event, if the param value is setting as per the activity step, then in the further steps some where this value is getting override, please do complete trace and see where the value is getting override.
Updated: 2 Apr 2024 17:57 EDT
Evoke Technologies
IN
@Ashish_Pundir Instead of using a background processing, I tried manually running an activity and call the history-Add method for a Data- instance and I could see my operator ID is overriding my custom value that I am trying to send for that OperatorID parameter. From what I can see in the full trace is that even though we use the history-Add method to update the instace with custom parameters, in the end the person who does the commit operation, in the insert operations the pyperformer value is overriden by that person who is performing the commit. I am not sure if pega provides any extension points to customize these kind of behavior, need to check on this once. But I remember I was able to have customized pyperformer values on Work- instances. Not sure if in the engine code, these things act different for Work- instances and Data- instances.
LTIMindtree
IN
@Abhiveer JatlaYes, this could be a valid scenario because your performing executing activity and its taking operator details from operator page from clipboard, but during background processing there wont be any operator page and pega will not find current operator details during run time, your logic should work in this scenario. Please try to perform execution from queue processor instead of running the activity in standalone.
Updated: 30 Mar 2024 0:50 EDT
Maantic Inc
IN
I'm suspecting its happening because of the queue processor, can you check if Param.UserID or Page.UserID is working when you run it directly, without the queue processor? This is just to rule out if there are any errors in the logic.
CGI
IN
pyPerformer property is used to hold the value of performer who did the task or action. So when you run the activity manually without queue processor it will automatically takes your operator ID as pyPerfomer. Could you trace the queue processor when updating the case with some other operator(eg:Charles@MWS)?