Red Hat's IT department recently deployed JBoss BPM Suite to handle automated process workflow. JBoss BPM Suite is officially defined as:
An open source business process management suite that combines Business Process Management and Business Rules Management and enables business and IT users to create, manage, validate, and deploy Business Processes and Rules.
IT's immediate use case is to replace our aging account management system, which is essentially a collection of perl and python scripts. Some of these date back to the turn of the millennium. These scripts had the responsibility of handling all aspects of user life cycle management, including:
- Pulling user data from the HRMS
- Creating the user LDAP object
- Creating the user group LDAP object
- Creating application accounts (home directories, mailboxes, etc)
- Updating LDAP objects with HRMS changes
- Closing user accounts and removing LDAP objects upon termination
- Syncing account information with third party systems (SaaS vendors, etc)
These legacy scripts would perform SQL queries directly against multiple data sources and call LDAP operations, application command line tools and make API calls. While this system worked well for many years, maintenance became an incredible burden. In essence, only one person knew the account automation system. New application integration requests would have to wait months for resources to free up. For applications allowing direct API integration, that meant some pour soul (me) would have to spend a fair amount of time just figuring out how this new application worked and what API calls were necessary. Moreover, when a vendor would suddenly change their API, that meant something was broken until there was time to fix it. The result was Service Desk team having to perform hundreds of manual operations in the mean time. Essentially, the maintainer could not scale with demand, let alone have the time to become an expert in every new application.
Implementing Red Hat JBoss BPM Suite (hereafter referred to as BPM), gave IT an opportunity to re-architect the entire account flow and processes. A three person team was formed to stand up BPM and implement the initial rules and integration activities. At its heart, BPM wants to work with other systems by passing around JSON. Working with the HRMS team, a system was added where when a HR action is performed on the user's record (create, modify, delete), it would turn around a post a JSON document to BPM. The canonical data model looks a lot like a user LDAP object structured as JSON. When there is a new user, BPM receives a post with all the basic data needed to create their account in LDAP. Likewise, changes and terminations also resulted in similar posts, updating or deactivating the account when necessary.
Once BPM receives an action from the HRMS, it turns around and determines what business actions are necessary. Defining and changing these actions are as simple as updating a flow chart. The end point systems, such as LDAP, mail servers, file servers, etc, all run a connector application. These connectors listen for data from BPM, then perform whatever action is appropriate for the event in that application. The logic for how to interact with a specific application all rests within the connector. These connectors receive JSON events, authenticated via client certificates, which contain the user data and the desired action. The connectors act upon the event and perform the specified action should it be necessary. For example, the LDAP connector receives a message containing a modify action and the new data for a particular attribute set-- it will check the existing LDAP object and update it with any new or changed information. Likewise, if the home directory connector receives an event to create the user's home directory, it will cp -a /etc/skel /home/$office/$username.
The real power of the system rests in pushing out application-specific actions to those who know best. The teams responsible for various applications know their app well, but do not have insight into the account management system. Likewise, the account management team does not have intimate knowledge of every application in the environment. With this system and architecture, the BPM team can focus on BPM and the application owners can focus on their applications. There is a standard hand-off mechanism that everyone can consume. Additionally, changing the workflow becomes something that a business analyst can easily perform as requirements change.
The system has been in production for little over a week and our Service Desk organization already sees enormous benefit to account processing. This BPM implementation processes around 100 adds/modifications/terminations per day now and supports scaling by several orders of magnitude. Each event occurs asynchronously and is process independent of the other changes. HRMS data errors are limited to only that account, solving a long standing program with our legacy automation system. Furthermore, Service Desk is only notified when there are immediate actions they need to perform, which has been a substantial improvement in process and efficiency.
While there were bumps along the way, as with any implementation project, the product worked well and has been very stable. The team is currently tackling the remaining account use-cases and then will move on to open up the platform for other business automation projects.
System profile
- RHEL 7.2 VMs running on RHEV 3.6
- Red Hat JBoss BPM Suite 6.2
- JBoss EAP 6.4
- MariaDB 10.0.14 (separate cluster)
- Deployed and managed completely via Puppet
About the Author
Brian J. Atkisson is a Senior Principal Systems Engineer and the technical lead on the Red Hat IT Identity and Access Management team. He has 18 years of experience as a Systems Administrator and Systems Engineer, focusing on identity management, virtualization, systems integration, and automation solutions. He is a Red Hat Certified Architect and Engineer, in addition to his academic background in Biochemistry, Microbiology and Philosophy.
Last updated: January 22, 2024
