Brazos Portal (2.0)

Java 8
Spring Boot
Angular 2+
TypeScript
Twitter Bootstrap (3.x)
ElasticSearch (1.x and 2.x)

Introduction

Brazos Portal is a proprietary process portal designed to be used with IBM BPM1. It is built as an alternative to the default process portal provided by IBM and can be used to:

Version 2 of Brazos Portal uses the ElasticSearch index maintained by IBM BPM, which means searches for tasks are extremely fast compared to v1.x, since it relies on a relational database for the same information.

BP3 presents: Brazos Portal - Setting Mobile BPM Free from BP3 on Vimeo.

My Responsibilities

I worked on Brazos Portal in 2016 and 2017, from product inception to its first release. During this time, I have:

Difficulties Faced

Since IBM unofficially supported the use of ElasticSearch by other applications, there was not much documentation in this area. This made using the IBM BPM provided ElasticSearch challenging, as we had to experiment with the ElasticSearch indices and documents inserted by IBM BPM to understand how we can get the task information needed.

The JMS queue emits events, which are then recorded to ElasticSearch.

Additionally, Angular 2+ was in beta when we started using it for this project, requiring frequent updates to catch up with breaking changes.

ElasticSearch

Prior to this project I had only heard about ElasticSearch. By the time I was being moved off this project, I had learned how to:

The flexibility of aggregations was quite intriguing, as we used them extensively to provide task due date information to the user.

Angular 2+

I had a great time learning how to use Angular 2+, especially not having to deal with scoping and change detection issues that were easy traps to fall into in AngularJS.

In Angular 2+, the process of scoping is hidden from the developer and every component can be considered to be “isolated” (while users can specify variables exposure using TypeScript’s encapsulation). Additionally, the introduction of push-only change detection, along with access to the change detector of the component and NgZone2, change detection became easier to manage.

Webpack

We used to use Gulp with various plugins as our build tool for web projects; however, this time a tool better suited for improving our page load times was needed. This is when I introduced Webpack3 to the project, which allowed us to decrease page load times by bundling the software into larger pieces (loading files in larger chunks is faster, as there is less request overhead). Even after the general release of Angular CLI, the team decided to keep using Webpack because it was working really well (and it would’ve been a decent amount of work to convert all build configurations to work with Angular CLI).

In addition to Webpack’s mentioned benefits, it provided great tools to analyze the sizes of included chunks (such as third-party libraries), allowing us to cut out duplicates and unused portions of libraries.

The Webpack Bundle Analyzer Plugin.

What Did I Learn From This Project?

What Would I Do Different Next Time?

Footnotes

  1. You can read more about IBM BPM (Business Process Manager) here

  2. One of my favorite articles that explain the Angular Change Detector and NgZone

  3. At the time we started working on this project Angular CLI was still in early development. 


Back to Projects