Introduction
An international law firm has engaged risual recently to manage and resolve issues with their username creation and duplication process. This process involves a new starter joining the organisation, being added to Workday, and having a username generated as part of IT onboarding. Usually, other systems would help manage this automatically however due to legacy infrastructure/processes/systems a more bespoke method was required. This method included the deployment of an Azure Logic App that could be called using a HTTP request via Azure API Management.
They key requirements for this engagement are as follows:
- The username must use custom logic based on the first name and last name provided.
- A copy of the username must be stored in a central database against the employee number.
- Any diacritics used in the username must be removed, including those specific to the organisation.
- The username should be saved in lower case and be returned to Workday.
Custom Logic
Custom logic to create the username initially seemed straight forward, however the solution needed to consider the following constraints:
- A username cannot exceed 20 characters.
- A username must first check if the first letter of the first name and the last name is valid e.g. “Joe Bloggs” would become “JBloggs”.
- A username must secondly check if incrementing the first name would satisfy the requirement e.g. “Joe Bloggs” may become “JBloggs”, “JoBloggs” or “JoeBloggs”.
- A username must then check if iterating numbers to the end would satisfy the requirement e.g. “Joe Bloggs” may become “JBloggs1”, “JBloggs2”, “JBloggs3” up to “JBloggs9”.
- Finally, a username must check if iterating a select character, “x” would satisfy the requirement e.g. “Joe Bloggs2 may become “JxBloggs”, “JxxBloggs” or “JxxxBloggs”.
Using an Azure Logic App, we would handle the HTTP request and process the above logic. This was achieved using check Conditions and SQL queries to check if a username already existed in the database. Additionally the Azure Logic App could handle a response back to Workday passing the username.
Central Storage
Once a username had been generated, the inbuilt SQL connector could be used to add the record to the Azure SQL Database. This was a seamless process however a new requirement arose which meant additional checks had to be put in place:
- A “Rehire” may occur which should return the pre-existing username.
This “Rehire” property was added to the request body and handled as a condition as the Azure Logic App executed. On triggering a check would occur returned the pre-existing username otherwise it would pass through the “New Username” path. In some cases, a user would incorrectly mark the user as a new starter (i.e. with the same employee number as a rehire) which caused issues in this process. An additional SQL query was executed and a response stating this is a rehire was returned.
Diacritics
Following initial solution implementation a further requirement arose to deal with diacritics. Normally a standard normalise function would resolve this problem using the inbuilt inline code function (JavaScript), however this wouldn’t work entirely for the use case. The client had several diacritics specific to them which wouldn’t be correctly identified by the normalise function. Instead an array of values was created and iterated through to replace values, the JavaScript in line code executed following this process.
Lowercase
Finally we had to tackle the lowercase scenario, this was easily resolved by converting all uppercase characters to lower case when the Azure Logic App was triggered. This meant any further calculations would process a lower-case value. Additionally this reduced the need for additional compute later in the Azure Logic App flow.
Summary
In summary, what seemed to be a straightforward process became more complex however with the versatility of Azure Logics Apps was very much possible.
