I was working in a HR Services application where I was wanting to create operator(for the employee) on the fly after they had been entered by the HR person on the screen. All the employees initially shall have the same org,div,unit as well as the access group. We also need to validate whether the employee already exists or not. I have followed the below approach.
I have created a wrapper activity in our application class to call the OOTB CreateOperator activity from Data-Admin-Operator-ID class and used a data transform to set the parameters for the activity using the values from pyWorkParty(Employee) page. I have referred the above activity in a utility shape in a flow which corresponds to a step in one of the stages in our case design.
For checking whether the operator exists also I have created a wrapper activity to call the OOTB CheckOperatorExists by passing in the parameter and referred the same in a utility shape in another step.
Is this the best approach to follow or are there other ways or best ways to address this requirement.
Thank you Lee. For our requirement we did not have the external authentication in scope. It was a simple requirement where we needed to create an Operator for an employee after the HR person captured his details. Although the case which stored employee details had many fields, for some of which we had used the OOTB fields from Data-Party and some were created. From these field we passed on some data to create an Operator(having most of the data fetched from a model operator). But we had to write an activity for that. Even the Show-Property step in CreateOperator activity had a challenge. When we used the wrapper activity in a utility shape that passed in the parameters as well as called the CreateOperator, when we test run the flow, it was creating the Operator but not showing the confirm harness. It was showing a string message called noError.
So, I thought of asking if there is any best way to call an activity of Data class from a utility shape to address the requirement.
This solution will work initially to allow the employee to log into PEGA, however in a production system the operator ID should be created automatically during authentication based on the information in the Enterprise Identity Management (EIM) system (or created by a periodic sync between the two systems). EIM (or LDAP) is normally the SOR for employee information. Your solution may lead to a mismatch between the two systems.
Thank you James. Initially for the HR application, it was just the HR who captured the Employee information and on submitting that, it would have created an Operator ID. We were also thinking of having a model operator and copy few attributes while creating the new operator.