Top Ten Common Mistakes

I initially wanted to title this post as "Top 10 reasons to show your RedPrairie consultant the door" - but that would have been too cold. But these are mistakes I have seen over and over again so wanted to mention them here.

• 10. Overuse of policies (as opposed to custom columns)
RedPrairie custom column architecture is really sophisticated. I have not seen such a concept in any other system where you can simply add custom columns and they appear on forms. The exact steps are so simple:
1. Add a column to the database. Optionally add column comment
2. Add an MLS id for the column
3. Add help for the column
4. Add custom column to les_cust_fld
That is it, now field will be maintainable on the form where it makes sense and code will actually be readable. You will be able to press F1 on the field and get help. "list table columns" will show exactly what this field is for.
• 9. Not utilizing groovy
Groovy is part of the product for several releases now so it should be used when appropriate. Basically if you are about to use "session variables" stop! Probably it is time to use groovy. The overall solution is greatly simplified by groovy but I often see code with 100s of lines of code including session variables that is hard to follow. So use it when it is appropriate.
• 8. Still not using SQL-92 syntax for SQL joins
It is not such a bad thing to use older style join syntax where you join two tables in the where clause but it is time to switch to this syntax. It is database independent and much easier to read. When doing outer joins it is much better than using database-dependent syntax.
• 7. Not knowing the difference between "|" and ";"
This one really bugs me. I often see code where "|" has been used simply to run a MOCA command "after" another command - not realizing what it is actually doing. Understanding difference between "|" and ";" is very important. Also knowing when to use "{}" (command grouping) is critical as well.
If you want to publish some data and then execute two commands for that data, don't do

   publish data
   |
   do command 1
   |
   do command 2
   

Instead do:

   publish data
   |
   {
      do command 1
      ;
      do command 2
   }
   

This will ensure that "do command 1" and "do command 2" can access published columns from the above command but do not step over each other.
• 6. Standard GUI form is customized without changing name
When this happens, you will not know what has hit you until the upgrade. For example, lets say someone customized standard GUI application xyz and when it was delivered it was at version 10. The person customizing it would keep it as xyz and increase the version to 11.
Later on you received a hotfix or an upgrade where standard product now has it at version 20, guess what will show up when the form is launched?
• 5. Not following naming conventions
Custom columns should have UC_ or VC_ prefix. Custom tables should have USR_ or VAR_ prefix (UC_ or VC_ can be tolerated as well). Custom policy nodes should have USR or VAR prefix (UC or VC can be tolerated as well). Custom integrator transactions should have UC or VC prefix (USR or VAR can be tolerated as well).
• 4. Increase length of a standard column
A lot of RedPrairie code is still written in "C" where the buffers are defined with static lengths. Do not even think about increasing length of a standard column. It may work in some cases but when it would not work it will be really had to troubleshoot and could lead to corrupted data or crashes.
• 3. Not using full key in join - and justifying it!
I understand that mistakes happen but what really bothers me when a mistake is justified. I would often see someone's code where they would join without client_id or wh_id. When pointed out, they say "it is ok because they have a single warehouse or a single client".
If you hear this justification, it may be time to make some decisions!
• 2. Using catch(@?) everywhere!
Search through your LES folder and look for "catch(@?)". If you see more than a few references (which are well justified by comments) - you have been hit by extremely bad code. There may be good reason to use it some times but in many projects I see it all over the place
If you must catch an exception, catch exactly what you are looking for. For example catch(-1403,510) or catch(-1). Catching @? implies that even errors like syntax error or database crashes will be caught and you could get unintended side-affects. So don't do it!
• 1. Don't worry - data will be archived by then!
This one really bothers me because by the time the customer realizes the issue the consultant is long gone and the problems become hard to manage. The idea of an archive system is that same exact use cases should work in archive that work in online system for completed shipments. So I should be able to print the same type of paperwork or see same analysis reports. A customer should not have to list out the exact use cases for archive and if archive system is designed properly they would not have any issues. In one case I noticed that someone decided to have wh_id as part of PK in archive system when it was not so on online system - well that naturally implies that same reports will not work in archive.
I am not a big fan of how archive system concept is designed but that is something we have to live with.