Today, I had spend 4 hours troubleshooting OTM (Oracle Transport Management) only to realise that the mistake was due to a change of Service Provider ID. This change was not updated in the Rate Offering. As such, the shipment planning was not able to pick up the rates. It was a very silly mistake and also shows the challenge of debugging in OTM. Anyone doing OTM will know the power of OTM debugging. Here are some debugging tips which could help anyone still doing OTM!
OTM Debugging Tips
Test often with each change of configuration. Use Agile to configure and test each change within a day.
Prepare a standard checklist for checking. This is important for Shipment Planning and rates setup.
Turn on your diagnostic log. It is more friendly than the log file.
Ask your OTM buddy for second opinion in your debugging approach. You may find new perspective.
Turn on your log files as last resort. The log file can either help you or discourage you. Go to the last page for the clues.
If you still unable to find the issue, rollback the change and configure your change again. This time, configure and test more aggressively. The key to debugging OTM is patience and practice. The only way is to get your hands dirty.
Unknowingly, I have spend more than 5 years with TMS (Transportation Management System) using OTM (Oracle Transportation Management) system. Overall, I enjoy the ease of configuration to deploy Agile solution using technique of DevOps. The control of global TMS solution also create high degree of adaptability for the team.
How to Agile your TMS
TMS have short transit window. It is favorable to adopt Agile.
Do design for change rather than design on sign-off requirements.
Configuration solution with custom plugins can cater for all TMS scenarios.
Determine your Agile components.
When to DevOps
DevOps complement Agile approach. This suits TMS because TMS contains many exceptions in the real world.
Use DevOps to close your loop in Agile implementation.
Consider to include monitoring tools or reports and analyse your data to determine your solution effectiveness.
TMS is usually 20% localisation. You may choose to DevOps on these localisation.
In summary, TMS needs a good product platform. You will also need to train your your TMS team to be Agile and DevOps ready.
OTM (Oracle Transportation Management) Object locks have been my nemesis lately. You can see my past battles with refactoring and code quality. In migration or upgrades, direct copy of old packages from old to new domain often do not work as expected. Of course, you will only realise it when you hit object locks.
Signs of Object Locks
If you see very long PLSQL packages, it will mean the codes will take a while to travel from end to end. Any delay will lock object or tables giving the user a non responsive feel in the UI.
Many UPDATE SQL are seen in the agent or PLSQL.
Locks in Agent are used in Modified agent.
Copying of data from different objects like Shipment to OR (Order Release).
Removal of PLSQL packages in Agent and DSU (Direct SQL Update) to bare minimal, especially Modified Agents.
Reduction of codes in PLSQL. Delete or comment out old codes.
Reduce your UPDATE to a single point.
Add exception handling in your PLSQL to allow graceful exit of your PLSQL.
Conduct unit testing to each Agent or procedures before enabling them. If in doubt, remove them.
It is a painful process and huge amount of mandays are spend. Of course, lots of practice and hair tearing are done before you realise these tips. Hopefully, they are of help to those doing migration or upgrades of OTM.