OptimizationdatabasemaintenanceWorkStream

The Seven Deadly Sins of WorkStream

by Jim Connett, on September 24, 2019

Allow me to be crystal clear from the start… WorkStream® is a quality, time-tested, enterprise-class MES application fully supported by SYSTEMA and integrated into a wide array of SYSTEMA applications through custom middleware. In fact, at SYSTEMA, our WorkStream customer base continues to grow and is easily one of the top three MES platforms serviced by SYSTEMA. Furthermore, the “seven deadly sins” below do not involve any deficiencies in WorkStream code released by Applied Materials® (the current owner of WorkStream).

No, the sins I’m bringing to light today are committed by administrators modeling WorkStream and developers customizing the WorkStream environment at the manufacturing site. The sins are committed by you and me—I can look at this list and easily say “Yes, I’ve been there. Done that!” (this is why I use the pronoun ‘we’). If you administer or customize/program WorkStream, you’ll agree we intentionally commit these sins because the end result is an acceptable “lesser of two evils”. Other times, these sins are committed unintentionally and we don’t know what we’ve done until we receive a call at 2:00 am with news that lots aren’t going on hold (for example). Regardless of calculated intent or level of awareness, let’s confess together that these sins are committed and that we as administrators and developers can and should do better.

So, without further ado (cue the angelic choir and bright shining light…):

Sin #1: Non-Value-Added Error Messages

When a user reports a problem to WorkStream administrators, we often receive a message that goes something like this:

WorkStream is broken. <insert long pause and silence here>

This feedback is given in this form because we either a) fail to give the user enough information about the problem when it occurs, and/or b) create an error message that doesn’t make any sense to the end user.

Error messages are customizable using the ‘messages’ program (yes, you can even edit/modify stock WorkStream error messages). Assume a user tries to enter letters into a field that will only accept numbers. This error message is NOT helpful to the end-user or the administrator: ERR001 – Value not valid. An error message like: ERR001 – The field does not support letters, only numbers. Retry. is more appropriate and helpful.

Sin #2: Inaccurate Cursor Placement upon Error

When an error occurs (like the error described in #1 above), it is very frustrating to the end user to place the screen’s input cursor at the first field on the screen—unless, of course, this is where the error occurred. To alleviate this frustration, when WorkStream detects an error in the user’s input, programmatically place the input cursor at the actual point of error. This way, the user doesn’t have to drive the cursor to the point of the error with a dizzying array of tab or error/directional clicks on the keyboard. Moving the cursor to the error actually shows the error location to the user. The user can then correct the data in the field exactly where the cursor resides. Your screen driver programs have capabilities to move the cursor to any defined screen field. Don’t just tell the user there’s an error—show them the location of the error.

Sin #3: Complicated USERCLASS Definitions

WorkStream has a robust, integrated, and highly customizable USERCLASS module where users can be assigned to a group such as superusers (can do absolutely anything in WorkStream), equipment (can log only equipment transactions), lead-tech (can edit/correct SPC data)—the group names here are made up for this example to prove the point that you, too, can implement custom user-access groups specific to your environment and business needs. However, the USERCLASS module quickly becomes messy when it is discovered that one user can actually fit into multiple groups. Complications like this cannot be avoided organizationally, and proper planning and documentation can minimize the pain and the overall number of groups. There’s nothing worse than a new WorkStream administrator trying to figure out why 175 groups exist and how they are all configured and related.

Sin #4: Rogue Display Statements

If you program custom code and custom capabilities for WorkStream, remember to remove (or comment out) your display statements. Otherwise, your end users may see a mess displayed on the screen and think something is wrong. Of all the sins listed here, this one is my downfall.

Sin #5: Customizations with No Documentation

This is not only a sin for WorkStream developers…this is a sin often committed by the entire software development world. Documentation is an afterthought, and if your memory is anything like mine, documentation becomes a forgotten afterthought. Adding simple documentation at the top of source code that explains who made a change, when a change was made, and what changed will help future administrators and developers understand what was done when and why.

Sin #6: No Maintenance on the Supporting Database

Even though database systems are much more robust than ten years ago, a neglected WorkStream database will eventually produce obvious transaction delays to the end user, and, in the worst cases, will result in transactions that time out. This is a bad thing.

Sin #7: No Historical Archives of Transactions

It’s mind-boggling to me that today’s database tables can—and often do—store billions of records. A good DBA will be able to set up the proper partitions and indexes to ensure these large tables do not contribute to slow SQL transactions. But…partitions or no partitions, the fact remains that a pruned WorkStream database is a fast WorkStream database. In determining what to archive, target your ***LTH tables. These tables (especially WIPLTH) are very wide tables and grow very quickly, so keeping these tables fit and trim is important.

Conclusion or “Atonement”

In considering our common culpability in the sins above, we can also commit another sin by having a knee-jerk reaction at the end of this article and fixing all seven sins before the end of the workday. Yes, some of the sins may be easier to address than others, but a better path toward absolution is to commit to close yesterday’s chapter of wrong-doings, and, going forward, start a new chapter with better documentation, intentionality with regards to disabling display statements, a stakeholder meeting to discuss best practices for maintenance and archiving, better error messages, and a white-boarding session that maps out a more efficient user-class management plan to be implemented over the next 12 months.

In other words, go slow, be strategic, and, with sins acknowledged, consider yourself forgiven.

Comments