ePlus User Management

Disclaimer Section

Due to the potential for me to get in trouble for mentioning privileged customer accounts or user information, the overview of this project is necessarily limited. I don't want any trouble from ePlus (not that I expect any), nor am I going to give any reason for trouble to be brought. This means I will be refraining from any discussions of

Instead, where needed, I'll refer to a more generic names such as "customers", "monitoring systems", etc.

What was the Problem?

When I arrived at ePlus, one of the first things I was trained on was how to create customer user accounts for an internal portal. This portal allowed customers access to the monitoring portals so they were able to view information about their devices without requesting ePlus to provide the information manually.

The process I was shown was very manual and had two separate ways of going about user creation. These two separate ways were completely different from each other, tedious, and had the possibility for errors due to manual entry. These potential errors included

There are, of course, other issues too outside of errors. For example, the manual process would take 5 minutes on average to complete. This isn't an issue when creating one or two accounts, but this is a great pain when you have to create 40.

Implemented Solution

To ease the creation of user accounts, I initially created a powershell script that automated the creation in one of the user backends used. Since most users were being created in this backend, this met our needs for quite a long time. After several months of use, it became evident that there were still issues in the creation process that could be solved with a solution that tied together both backends.

Since multiple backends needed to be brought together, and since I am decent at creating API driven web portals, I began work on a site that would allow the customer service managers to directly create the user accounts without needing to route a request through to our department at all.

To create the site, several things had to be considered.

Building out the API itself was simple, and an initial version of the site that was able to create users on one backend was actually completed relatively quickly. At that point, the real work began since I had to build out some sort of interface in order to communicate between both backends consistently. This required building abstract classes to ensure functions are present and named correctly, converting my current approach into an OOP approach, creating a method for handling caching for multiple backends at once, learning a new API for a new backend, and more.

Once built, the portal was finally able to perform Create, Read, Update, and Delete operations for all users in both backends. At that point, hosting and making it available to the rest of the company became the primary concern. I had hosted site internally for my team to test with, and unfortunately I moved on from the company just as the site was being put into production. The very limited feedback I did get from the users of the portal were extremely positive though.

Project Examples

Due to the simplicity of the site, one image suffices to show the interface. Since ePlus owns the code to the site, I will be showing nothing more.

Image of project interface
Image of the project interface

Pros

Cons