Skip to Content
Product Information

Update Usernames with Integration Centre

Have you ever wished that there was a way to update usernames automatically, only to realise that usernames are not available to the Business Rules Engine?

Today, I am delighted to show you an Integration that I have built to automate updating the username of my instance.  The specific use case I have is in a hybrid implementation, where there are many “Rehires with New Employment” performed.  In this case, the username for the inactive record needs to be updated so the previous username can be used for the new employment (there are some other follow on activities that necessitate this and integrations to update the username with the Business Email, but not going into all the detail).

So the need is to update inactive users in Employee Profile.  If you are not using an API upsert by including the parameter processInactiveEmployees=true in your middleware, you are left with the only other option, which is the Integration Centre.  The only problem is, the Integration Centre cannot update inactive records.  Well, until the H2 2020 Release that is!

With this release, it is possible to create an API Profile and assign the profile in your integration.  So to start off with, navigate to the Admin Tool > Manage API Profile Option.  Here you can create a new profile, and in my use case, I specifically selected the Process inactive Employees checkbox:

API%20Option%20Profile%20Settings

API Option Profile Settings

Now that the API Option Profile is created, I can start creating my integration in the Integration Centre.  Start off by setting the integration type as SuccessFactors Source and Destination, to allow you to use ODATA v2.  I have then also selected that it should be scheduled, as I will then run this periodically to update the username for any terminated employees.

Integration%20Type%20selection

Integration Type selection

From here, search for and select your starting entity Username (username) in User.

The Integration Centre has a wizard-style interface, allowing you to complete an integration step-by-step.  First, you will complete the Options, i.e name of the integration, optional description, and enabling server-side pagination if you are querying large amounts of data to give a performance boost.

IC%3A%20Options

IC: Options

Then on to the Configure Fields step.  This is where you map your fields to populate, but furthermore, you are also able to set calculated fields and values.  In my use case, I want to update the username by prepending it with an “i_”.  That will be a calculated column.  There are three additional fields that I must map since they are required fields, namely, userId, gender, and status.  For these three, I simply map the fields to be populated with the existing values:

Field%20Mappings

Field Mappings

The Operation is set to Update/Merge, which updates only the fields provided and leaves other field values intact.  With the H2 2020 Release, it brings in a new field, API Option Profile ID, which is where you capture the API Option ID created in the initial step.

Now on to the Username field.  As mentioned, instead of mapping this field, we will create a calculated field.

Add%20calculation

Add calculation

My calculation I set to IF/THEN/ELSE to ensure that only the username of inactive employees is updated and that active employees’ username remains the same.

Username%20Calculation

Username Calculation

You can check the Calculation Trace to see if this yields the desired results.  Once you close the calculation, you are able to preview the records and your results should look a little something like this:

Preview%20of%20Results

Preview of Results

Employees with a status of “t” (active) has the result of the username remaining unchanged, while employees with a status of “f” (inactive) are prepended with i_.

Now proceed to the Filter and Sort step, and set the following:

Advanced Filters
  • Use the Status in User field, and set the filter equal to “f” (inactive), since you do not require to update username for active employees.
  • Additionally, exclude usernames that start with “i_”.  This will ensure that you do not end up updating inactive users with each schedule that could lead to “i_i_i_i_ENeal”.
  • Lastly, I have also included Employee Status from EmpJob (Job Information) and set it as equal to 4600 (in my instance), the optionID for Employee Status “Terminated”.  This will ensure again that only when someone is terminated, they will be included in the integration update.

Time-Based%20Filters

Time-Based Filters

As I will be scheduling this integration to run periodically, it is necessary to specify a time-based filter.  In my case, I specify that only records that have been modified or are effective since the last run time will be included in the next integration run.

Now move to the Scheduling step, where you can set the frequency of the integration.  Also courtesy of H2 2020 Release, you can now set the maximum number of executions to 12 and specify the interval of hours.

Scheduling

Lastly, you are ready to Review and Run.  Here you can trigger a one-time run, and set the recurring schedule.

Your integration will now run at the intervals set, and update the usernames of terminated employees.

This method can be modified to suit your needs, perhaps create a new username for new hires.  It is a very flexible method of updating information in your instance.

 

THR81 Practice Exam – 80 Questions PLUS 70 Bonus Questions

2 Comments
You must be Logged on to comment or reply to a post.
  • Hi Eugene

    Thanks for the detailed instructions on the topic.

    We are also using similar approach till now with custom webservice from SAP Onpremise with limitations and validations in CPI tool.

    I have below queries on this approach.

    1.Can I add a condition that only after the employee termination date is crossed this would trigger the update for inactive users in the UDF.

    2.In scenarios where we have future Hires and Future terminations which needs to be updated with same username , how does this function?

    3.Users who are spread across standalone module and in EC having multiple profiles , will IC able to work in this scenario.

    I know these scenarios are specific to us 🙂, but would be greate to know if we could work with IC and have a much cleaner process.

    I would also setup with the help of your instructions and see if I can overcome my issues with.

    Cheers.

    Gautham

  • Hi Gautham

    Without looking too deep into these specific scenarios, here are my thoughts:

    1. By adding the Advanced Filter:  Employee Job Status = Terminated, that will ensure it will only update the username if the terminated date is reached, the EC Job Info status is inactive, and hence the EP Status is inactive.
    2. For future terminations, this specific set up will not trigger until termination is reached (as point 1).  For future hires, you could potentially build in conditions for status Active PLUS event is equal to Hire.
    3. This scenario should still work.  E.g. if someone is on Global Assignment, they, in fact, have two different usernames, for instance, ENeal for home, and ENeal-1 for host record.  When the host record terminates, it would update the username for that to i_ENeal-1, and for home record when that comes to be terminated, to i_Eneal.