In this blog entry, my goal is to address this concern. As long as user's customizations are done in a bolt-on manner allowing the base JDA code to
be preserved., the client's upgrade path is not put in jeopardy. The
customizations can include changes to RDT screens, or adding new RDT screens, or changes to standard behaviors to allocation. picking or putaway and still remain on the upgrade path.
Again, the purpose of this entry is not to advocate rampant customizations. The only objective is that an operational efficiency not be sacrificed, simply for the unfounded fear of customization.
The analogy I can think of is that I went and got a nice car. It suits me well, has all the gadgets I need etc. except for one limitation, that it has high performance tires. I happen to live in Wisconsin so I am left with two options:
- Not drive it for the 4 winter months
- Or, get a different car for winter
Many customers will treat their JDA purchase in this manner and be willing to adopt a manual approach or a different system to handle a shortcoming rather to change the tires. To add insult to injury they would somehow think that getting all weather tires from the dealership at twice the price will somehow insure the warranty of the car.
Understanding the JDA Application Architecture
JDA Changes are configuration based, database changes, or code changes. At all of these levels, following the correct methodology allows the client to preserve their changes during an upgrade migration.
- Configuration Changes - Almost all configurable changes (like field names, messages, validations, lookups etc.) have a customization level. Having this customization level to be non zero (generally 10 or above), ensures that JDA hot-fix will not replace this change.
- Database Changes - Many times, a change requires adding a custom column to a standard table, or adding a custom table. As long as the column names are prefixed with UC and table names, with USR (the convention provided by JDA), any new version will preserve these during an upgrade. Furthermore, if the user followed the convention of preserving the changes in a file in the $LES/db/ddl folders then these scripts can be run again after the new data dictionary is loaded. For example, if a client has added custom columns to PCKWRK in 2009 version and is now moving to a higher version where PCKWRK is split into two tables, the upgrade scripts cannot determine which tables the columns should be moved to. But the user can easily edit their scripts in the $LES/db/ddl folder to reflect the PCKWRK_HDR or PCKWRK_DTL and run them again (and make corresponding changes to the code).
- Command Based Changes - Changes done at command level, when done correctly are the easiest to preserve because the $LES/src/cmdsrc/usrint directory is preserved during an upgrade process. The key is how the user (or partner) made the changes:
- A change can be complete custom solution, like a new DDA, a new report etc. This type of change has no dependency on an upgrade except to ensure that it is needed and the data model is consistent
- A change that is an override to a standard command, like adding some custom business logic to allocation etc. This is where the correct methodology comes into play. The client should be mindful of the following red flags:
- A change to standard command being done at the C/ Java code level - If the partner is providing new C/ Java code and pointing your command to a new var based component, beware. You are now not on the upgrade path. The client should challenge this type of change and ask if there is another option
- A change to a standard RDT screen is being done by copying the standard code to VAR and modifying it. Again, as a client, you are not on the upgrade path. Challenge this and find out why the given change cannot be done as an override?
- Re-purpose standard database columns for some other use. A client often chooses to, or is advised to utilize a standard column (like REVLVL) for a change that the client is implementing, and not add a custom column for this purpose. Beware, that the next upgrade may not have that column available or has a different use for this, making your change not compatible anymore.
- Triggers on standard commands - Changes may be made by adding business rules on standard commands utilizing custom triggers. As long as the custom triggers are at a higher firing sequence and have a custom name, the upgrade path is preserved. Many times, a change is needed to a standard trigger. This should always be done by disabling the standard trigger and then adding a custom trigger. Clients, beware, that if the change is not being done in this manner, you are going away from the standard methodology.
- Integration Changes - These changes are more common than others, as clients usually have little choice in this. However, I see the most non-standard practices here, causing the clients undue effort during an upgrade. So client, beware, that if you end up with any custom events where a standard is available (like a custom INV-ADJ, or a custom SHIP_LOAD), as why? Generally speaking the customizations are only needed in Retrieve methods, or having some algorithms etc.
Need of Customization
As stated above, one can have a varying perspective as to
what is a customization in JDA. The
author’s perspective is that any change that takes the application away from a
possible upgrade in the future needs to be evaluated heavily for the merit of
the given change. Beyond this, as long
as base JDA code remains in play, then extending of the code, database, or
configuration should only be merited against the operational cost of the work-around
that is requiring the change. For
example:
- JDA does not offer any column in the “Pre-Plan Summary” for Wave Operations to select orders by carrier move. If the customer is doing transportation management, this can be a valuable field to display on the pre-plan summary screen
- The change will simply be to override the list command
- The override should call the original command and then add a new select to get the carrier move and re-publish the result set
- The screen will start to display the additional column because it is in the result set
- The code is upgrade proof because the standard command is still what returns the main data set
- JDA offers the capability to write triggers on existing commands. The business requires an additional log entry for inventory movement under specified conditions
- JDA Standard Inventory Deposit Screen needs to show an additional set of information. In the post 2011 version of JDA the RDT screens are Java based, hence can be extended without having to rewrite the entire RDT screen. Thus the base RDT screen still remains pristine and additional information, or method is called as custom
- A given SQL statement is not optimized. A Query hook can be added, to rewrite the query before it gets to the middleware and hence remain upgrade proof (please see the Blog entry on this topic)
The above discussion was only focused on business reasons to
extend standard functionality. More
often we need entirely custom solutions, like a new DDA, a new RDT screen
etc. Generally speaking any
modification that is needed in JDA is being built to optimize a warehouse
operation. Thus the existing set of
standard commands may still remain in play, except the business case is to
optimize the multiple set of commands.
For example:
- JDA does not offer a standard transaction to change the Item on existing inventory. The standard option is to adjust out the inventory of the first item and then adjust in the inventory for the second item. This is the preferred mechanism as the process will fire the requisite host transactions to keep the host in balance. The customization in this case, be it a DDA or RDT screen would simply be to take the input from the user (like the LPN and the new item) and then do the two transactions in succession. The end result, even though considered a customization based on being a new screen is calling standard functions underneath
- JDA does not offer a standard transaction for automatically loading and shipping a trailer. However, often for customers that do inter-company transactions, this becomes a requirement. The goal is to load and dispatch a trailer so an inbound ASN can be generated to receive the inventory in the other plant. The inventory physically does not need to be loaded. In this case again, having a DDA that can do the load inventory, close trailer, dispatch trailer transactions in succession allows to achieve the end result and convenience for the users
The business cases discussed above should allow the reader
to appreciate the concept that given needs for extending the business logic in
the JDA application are often simplistic in nature with high return value in
operational efficiency. Furthermore, any
of the business cases discussed above, though “Custom”, will remain upgrade
proof as they are calling standard commands underneath.
Types of Customizations
This leads into what types of customization terminology is
applicable in the JDA domain. Please
consider that the following is a list based on author’s perspective and how the
custom work is being defined here. A
given enterprise may still differ on specifics of the definition of custom work
but may agree on the scope of the list below:
- Extending Business logic
- Creating a wrapper command that calls on or multiple standard commands in succession
- Creating a custom command for custom DDAs, Reports, and Labels etc.
- Overriding Existing Commands
- Override to change the inputs to a standard command to effect the needed outcome
- Override the command to change the result set of the command
- Override to change entirely the business logic (not recommended), but allow the calling screens etc. to still function the same way
- Adding Custom Triggers
- Allow for additional logging
- Allow for custom
- Adding custom Tables/columns
- To track custom attributes
- To track custom
- Extending standard
- Adding custom
- Adding custom Data Driven Applications (
- Adding custom .NET screens for more complex screen
- Extending standard RDT screens
- Adding new methods, or extending existing ones like a new behavior on Form Entry
- Adding new
- Adding new RDT
- Adding new Reports and
- Adding new
- Adding new Valid Lists
All of the above mentioned changes to the standard delivered
JDA application may be intimidating to a customer and fears start to set in around
cost and possible future upgrades. Yet,
when done correctly, the cost is justified by the ROI on the operational
efficiency and the fear of an upgrade mitigated by employing the correct
methodology.
Conclusion
The JDA application architecture with its flexibility of
screen architecture, Java attributes in the RDT screens, and the entire MOCA
architecture flexibility with overriding levels of command structure allows for
extending the business application. The
notion that no two warehouses are alike bears strong resonance with this
application architecture. While controls
are needed, and needless customizations avoided, never should a path be taken
that compromises on operational efficiency in lieu of a “Customization”. Simply the notion that a given change
requires some code to be written vs. going to a screen and turning a flag on/
off should not be the differentiator between a customization and configuration.
“In a tailor-made service, you fit the cloth according to
the size and taste of the customer; not just the taste and strength of the
designer.”
