The TRIRIGA Dash Notation Naming Convention

In technology there is one constant and that is change. The naming convention for TRIRIGA objects has not been an exception. There have been a few different naming conventions taught by TRIRIGA development instructors over the years. This includes the TRIRIGA Dash Notation naming convention that I developed and taught as a TRIRIGA development instructor while at IBM. I did manage to get a portion of this naming convention in to the TRIRIRGA Application Developer Guide prior to my leaving IBM.

A few years ago I improved the TRIRIGA naming convention based on my experience performing an application upgrade for a client. It was during the upgrade analysis phase that the current naming convention revealed its failures to me and I set about trying to think of a solution. In order to talk about why the convention was changed it is important to first understand why the convention exists. The purpose of a naming convention is to convey information based off the name in order to make things easier for the developer. The original purpose was a simple one, and that was that the naming convention would allow one to easily identify what is an out of the box object versus what is a custom or customized object.

When I first started at TRIRIGA the convention was starting to shift from prefixing objects with an acronym for the company to the generic cst for custom. For instance if the name of the company implementing TRIRIGA was named My Awesome Company then objects would most likely be prefixed with mac. There was a lot of speculation at the time that the naming convention change was just simply so that TRIRIGA Professional Services would be able to reuse custom functionality easier between clients. If that were true it would certainly make TRIRIGA Professional Services more efficient and to me greater efficiency is a very appropriate reason to change. Whatever the reason for the change, I do believe it was also a good idea for no other reason than it gets everyone operating in the same general manner.

To prefix custom or customized objects with cst was a good start. However, there was too much ambiguity on when to use a dash and this led to several different variations being implemented. Even within the TRIRIGA Professional Services organization it seemed like each developer had their own twist on the convention.  For instance if the triBuilding form was customized it might be labeled cstBuilding, cst - triBuilding, cst-triBuilding or csttriBuilding.

During the analysis phase of an application upgrade, of an environment that had several different TRIRIGA developers develop it prior to my coming on the project, I realized there were two main failings of the TRIRIGA naming convention. The first failing was that I could not tell just by an objects name whether it was a custom object or a customized out of the box object. If a form is named cstBuilding, does that mean it is a new custom building form for the triBuilding object,  the out of the box triBuilding form that has been customized, or a new form for a custom cstBuilding BO? This meant that I had to open each object, inspect it, and then try to determine if it was a pure custom object or whether it was a customized out of the box object in which the changes need to be reproduced.  For workflows the problem was compounded.  Although a determination that a workflow was a customized out of the box workflow could be made, it was not possible to tell what tasks were new or what tasks had been modified. This is the second failing of the TRIRIGA Naming Convention.

 I now had two clearly identified problems, so I set about trying to figure out what would be the best way to solve them. After thinking of possible solutions and talking about potential solutions with my coworkers I decided that there was one solution that would solve both problems. The solution was to adjust the naming convention so that it conveys if an object is pure custom or customized out of the box and to also bring that convention down to the worfkflow level.

The way to do this was really quite simple, it all comes down to a dash. Pure custom objects should be prefixed with cst followed by the object name in camel case where as customized objects should be prefixed with cst- followed by the object name. Going back to the earlier example of the triBuilding form, if it is customized then it should be named cst-triBuilding where a new custom form for the triBuilding BO would be named cstTriBuilding and a cstBuilding form would indicate that it is a form for a cstBuilding BO. This format is the same for all objects, not just forms. Now if I saw a cst- I knew it was customized out of the box, if I didn't then it was pure custom. Incidentally cstBuilding is probably the most common way the triBuilding form would be renamed after it was customized. I know lots of long standing TRIRIGA developers use that convention. However, I hope you can see how there is ambiguity there and that it doesn't convey if the object is custom versus customized out of the box and therefore should not be used.

A few more examples: For workflows, a workflow named triBuilding - Synchronous - Precreate would be an out of the box workflow. A workflow named cstTriBuilding - Synchronous - Precreate would be a new custom workflow against the triBuilding BO. A workflow named cstBuilding - Synchronous - Precreate would be a new custom workflow against a custom cstBuilding BO. For Queries, a query named triBuilding - Find - All would be an out of the box query against the triBuilding BO. A query named cst-triBuilding - Find - All would be the out of the box query against the triBuilding BO that was customized. A query named cstTriBuilding - Find - All would be a new custom query against the triBuilding BO. For those queries or workflows that go against a form name instead of a BO name it is the same format. For instance triStructure - Find - All would become cst-triStructure - Find - All after it is customized. A query named cstTriStructure - Find - All would be a new custom query against the triStructure form.

This same convention was then brought down to the tasks in the workflow builder. If an out of the box tasked is modified, then it's label should be prefixed with cst-. If its a brand new custom task to the workflow it should be prefixed with cst. Following this naming convention allows you to open a customized workflow and see what tasks were modified and what tasks were added. Unfortunately there are some tasks, such as the switch task, that do not have an editable label field. Those tasks do not benefit from a workflow task naming convention. (Note: I've also created a naming convention for workflow variable tasks, which you can read in my previous post.)

Obviously for a pure custom workflow all the tasks in it are custom so one might argue that there is no need to follow the naming convention. I advise against that train of thought and I always follow the naming convention even in pure custom workflows. The reason for this is that I always try to program in a way that takes in account human nature. By thinking of human nature and where I might fail, I develop processes to minimize that chance of failure. Seeing as people are creatures of habit, if one gets in the habit of always following the naming convention then they will follow it when they need to. If however, one applies the naming convention in some instances and then not in others, their chance of not doing it when needed is much higher.

Adopting the TRIRIGA Dash Notation naming convention has allowed me other ways to become more efficient. Since the naming convention is very precise I have been able to write SQL scripts that help me identify objects that have been renamed according to the standard. I can then take the output of those SQL scripts and run them through a custom utility and automatically generate my rename scripts. This can literally save me hours of time in a large object migration. I no longer have to just cut and paste repeatedly to build my rename scripts. Now I have take then potential for human error out of the equation. This makes the renaming safer and faster therefore reducing the cost of the deployment.

Another benefit of adopting the TRIRIGA Dash Notation is it reduces the cost of application upgrades. The analysis portion of an application upgrade is traditionally what takes the most time. By being able to easily tell what is custom versus what is customized out of the box it cuts down and the number of objects that have to be analyzed. If it's a customized out of the box workflow the analysis can be dramatically faster. After all what takes longer to analyze a workflow that has 100 tasks in which you have no idea what was touched, or one that you can easily tell what tasks were modified?

A final benefit of adopting the TRIRIGA Dash Notation is that it also reduces costs by reducing the ramp up time needed by new developers or even for existing developers who haven't touched a particular area of the system in a long time. It's easy to remember what a workflow does when you've spent the last several months building out functionality, however what if you haven't touched that workflow in 6 months or a year? With the TRIRIGA Dash Notation you can jump back in to a workflow and know where you modified it and immediately hone in to an area you might need to make changes to fix an issue.

In conclusion, the TRIRIGA Dash Naming Convention reduces ambiguity, increases efficiency leading to lower application upgrade and deployment costs. So, the final question is, how much is your TRIRIGA naming convention costing you?

Thanks for taking the time to read this and entertaining my personal little crusade to make TRIRIGA Development better.

Please contact me at www.edatai.com if you are interested in making your TRIRIGA environment more efficient.