“How exciting!” That is what I thought as I started my new role at Methods as a ServiceNow Developer. Specialising in ServiceNow development for 3 years in three different companies before joining Methods helped me feel confident about approaching the new role. I later find out, that there were some ServiceNow skills I have been lacking which I thankfully get to master down the line.
Fitting in
I joined the team as a ServiceNow developer. The team included senior developers who had many years’ experience in ServiceNow. I was warmly welcomed into the team and had so much support from them.
I realised how fortunate I am to work along with my senior colleagues, as I was able to extend my development skills so much further. I am also glad they never get fed up of my continuous, never-ending questions.
Challenges:
Our team applies agile scrum practices as a development methodology, which is very efficient for rapid improvement of solving technical problems. Additionally, the ServiceNow platform that our work relies on is built upon the principles of ITIL (IT Infrastructure Library). So, in ITIL terms I would be described as a process practitioner within the team.
Being a process practitioner / developer, I get new stories (tasks) assigned to me in every new sprint. Our sprint lasts two weeks. At the start of a sprint we hold a meeting where I discuss new stories, ask for clarifications on customer requirements and give my opinion or approval of how many points should be allocated to a story, i.e. the number of hours or estimation of the amount of effort required.
At the end of the sprint, I get a chance to demonstrate my development work to my team. In this demo I make sure that the test lead individual understands my work and has enough information on how to perform a test on my development. He basically attempts to find a flaw in my development, so it could be debugged if found. I always get feedback from my senior colleagues, as to whether there are better approaches to solving a technical issue, or if I am on the right track.
The real challenge is figuring out the most suitable approach to performing tasks and solving problems. Here’s an example.
The big challenge:
One of the major tasks I got to work on was to build a scoped application on ServiceNow platform called: ‘License Harvesting Application’. The purpose of this application was to detect outdated licenses and removing them from the system, with the ability to retrieve the licenses if required.
The task had dozens of additional core requirements, such as:
- Defining a notice period (warning) and an expiration period.
- Avoiding hard coding by using system properties.
- Catering for 3 different states within the life-cycle of license harvesting.
- Notifying users and application admin of harvesting procedures taking place.
- Ability to restore harvesting licenses of one or more users.
- Using custom table with lots of informative fields to allow management information.
- Using global variables within script includes to avoid repetitive modification of values.
- Defining accurate ACLs (to determine who can create, update, delete, etc).
- Following best practices of coding in general and of ServiceNow development.
Throughout the development of this application, I found plenty of problems and managed to solve them on the spot before they went through testing.
I also had a great opportunity to add lots of enhancing features to the application to make it user friendly, informative and easy to use. For example, displaying all details relevant to one specific user and one specific role, like: emails sent, logs and a list of related records for the same user with different roles. I provided this through the addition of related lists (tabs).
Another very important feature I made use of was the ability to demonstrate a hierarchical diagram of how a role is given to a user. For instance, a user could be a member of a group where the group has a role. That role would be given to the user through the group, since the user is a member of that group. I realised that there is a ServiceNow tool embedded within a UI Page that enables the demonstration of role inheritance using graphs. So, I inserted a related link on each form which when clicked on it takes an ID number related to the user and role and opens a page with a diagram showing how this role is allocated.
The toughest challenge:
There are times when I don’t sleep because I’m still thinking about the code I’m writing and prefer to continue coding and solving the problem over sleeping.
This tough challenge was simply finding a way to tell where a role is being inherited to a user from. I.e. is the role inherited from a group? Or from a role?
So basically, user A could be given role X directly. This means the role is not inherited, and this is easy to figure out. However, there are cases, as mentioned previously, where a user is a member of a group that has a role, so the user inherits the role from that group. Sometimes it can get really complicated. Some roles contain other roles, and if user A has role X and role X has roles M, N & L, then the user inherits all those roles. Also, if role L has other roles like: P, Q & R, then user A inherits those children roles too.
Now let’s say I need to find out, through my application, where is role Q given to user A from.
We can tell that because role X is the parent of role L, and role L is the parent of role Q, and user A has both roles X and Q, and role X is NOT inherited to user A (it is given directly instead), then role X is the provider of role Q to user A.
Using this logic, I can determine that if I wanted the application to remove (i.e. harvest) role/license Q from user A, it will have to remove role X from the user instead.
There could be longer series of role inheritance. So I took a long time, given lots of effort and even used my spare time to try my best to write a scalable code that can deal with any complex scenario of role inheritance, no matter how long it could be.
Trust me, just explaining this is not easy.
Underneath is a photo illustrating a hierarchical diagram of the role/license inheritance between a specific user and a target role:
1.
2.
Eventually, I wrapped all this sophisticated piece of logic within one script file (a Script Include), and whenever I need to use it I would just call one main function in that file and give it the user ID and role ID that needs to be harvested/removed. Sounds simple, right?
Results:
It was important for me to finish what I started and prove to myself that I could get this done. I was more than happy and delighted when I finished this application successfully. It was like a heavy weight lifted off my shoulder.
I also presented the application to my colleagues and to the customer. I had a very positive feedback on it and soon after, the application got tested and deployed within the customer’s production system. What a happy ending ?
For more information on ServiceNow please email: Mohammad.nassar@methods.co.uk