Employee Central | Business Rules Engine at work

**This blog is obsolete. There’re far better and easier ways to address the problem**

Recently a customer I am consulting for came up with a not-so-unique requirement. For privacy reasons let’s call the customer acme and acme’s requirement was to automatically generate email addresses for the employees they hired.

Requirement:

If Walter White were to be hired at Acme, his email address would have to be Walter.White@acme.com               

Seems easy –  Doesn’t it? But not when you have to factor in for the duplicates in the system.The following blog elucidates how a combination of MDF Object, Business Rules and a custom integration process came together to fulfill acme’s requirement and saved the day.

First Things First: Create a Business rule that’s always true

Navigation: EC-> Admin Tools -> Search for Configure Business Rules
Create the rule “gen-uniq-email” as per this screen grab here.

Points to be noted:

• Base object has to be Employee Information as you need this rule to kick in while hiring.
• Format() is a function that comes shipped. There are many other useful functions that you can use out of the box. Look up for the complete list here  https://partners.successfactors.com/productcentral/PSDocuments/RulesEngineHandbook.pdf
• You can also perform this activity in the data model xml  provided you have access to provisioning.
  

Format() lets you use java style runtime variables  %s. The rule here essentially means replace the first %s with the first name and the next %s with the last name of the employee.

Now tie the business rule you created with the field in question i.e., email

Navigation:EC->Admin Tools-> Search for “Manage Business Configuration”

Let’s take our rule for a spin by trying to hire an employee.

Navigation: EC->Admin Tools-> Search for ‘Add New Employee’

Walter White translates to Walter.White@acme.com – all good!

Now what happens when acme has another Walter White coming on board? Email duplication issues!

Solution

The solution is fairly simple. Just create the email address in the rule and check for its availability in the EC database. If already available, suffix the email with an incremental number, else, just use the email. But…

• There is no way to access employee email data either via a function or via an API call at the business rule level => we got to create our own email store – we do that with an MDF object.
• The business rule framework also doesn’t provide a way to create an entry in the MDF object. Hence we have to populate the MDF object with via an external contrivance – a custom BOOMI process to be precise.

Step 1: Create MDF Object  – cust_email
Navigation:EC->Admin Tools-> Search for “Configure Object Definitions”.
Just create an object with effective dating set to none, API visibility set to editable and retain the External Code and Name. Everything else is optional and can be configured on a need basis.

Now get object cust_email into the business rule

For the moment  let’s assume that the aforementioned BOOMI process already exists and keeps the MDF object cust_email afresh with all the new email addresses as and when they are generated.

With that assumption let’s understand the business rule here.

For starters, there is an if statement. The if statement checks for the existence of the email address in the MDF object. If it does exist-> then suffix the email address with an incremental number else just use the email address.

the Then Statement has a few new faces

• Format template now reads – %s.%s%s@acme.com
• The third argument is basically the suffix. E.g. Walter.White1@acme.com. So how do we get such a suffix generated?
• We can use the standard function GetNextValue() along with the MDF object Sequence to achieve the incremental behavior of the suffix. In this rule email-auto-increment is one specific Sequence object

So the Sequence object has to be created beforehand.

Navigation:EC->Admin Tools-> Search for “Manage Data” -> Create new sequence.

The sequence starts with the number 1 and it’s auto-incremented in steps of 1.

Now the business rule as such is in place. Provided the cust_email object is updated every now and then we are assured of a unique email address every time a new person is hired.

Let’s shift our crosshairs to the elephant in the room i.e., the BOOMI process.

BOOMI process

The process is pretty straight forward. Every now and then (as scheduled) the process comes alive, reads the latest emails from the SF Object PerEmail and writes it into our custom MDF object cust_email.

All good? Now let’s hire another Walter White.

The new Walter White has a different email id from the previous one – serves the purpose

FAQ

Why do we need a BOOMI process here?

• Because we cannot update the MDF object directly from within the rules engine.

Is BOOMI process to only way do this?

• No, MDF objects offer OData APIs. Technically we can use any other contrivance to achieve this so long it can be scheduled to run every now and then.

To conclude:

Business Rules Engine is fabulous with a lot of in built feature-functions.

Nevertheless it would be great to see a spruced up Business Rules framework that can write, as against only read now, into MDF objects directly, perform basic string functions like search-replace and if it’s not a tall ask – provide ability to access APIs, external and internal.

With such features, Business Rules Engine can help not only business processes but also tactical integrations. While the strategic A2A integrations take the BOOMI/HCI route, tactical integrations like creating asana/jira tasks for impending HR tasks or streaming updates to progress trackers can definitely take this route.