By Saad Ahmad, Executive Vice President of Smart IS International

Overview

One thing that all large implementations have in common is the need for some tasks that need to be completed periodically. These may be tasks that are by design or due to some data corruption. We often are unable to get the fix from the vendor or the fix may require an upgrade which may not be feasible.

In previous versions we had Schedule Agents that could do this. In new versions we have a more elaborate construct called jobs.

Our Approach

At Smart IS we employ a slightly more sophisticated approach to this problem. We implement a concept of an application monitor that detects abnormalities and fixes them. While it executes using the provided constructs of schedule agent or jobs — it provides a more abstract view of this problem and thus the overall solution is easier to manage.

We view the problem of an application monitor as follows:

• Detect the issues of a certain type. Return several rows where each row indicates the issue of this type. This can take the form of a MOCA command or a SQL statement.
• For each of the rows returned from above execute MOCA code to fix that situation.
• Optionally log in dlytrn
• Optionally raise EMS alerts.
• Provide a front-end so that advanced end users can manipulate these monitors or add new ones.
• Run these as a single job so that overall job schedule is not adversely impacted.
• Publish progress to the job monitoring framework developed by Smart IS

Our Solution

We define this monitor in a new table:

The solution is in the form of a single MOCA command called “run ossi monitor” which is scheduled using MOCA jobs. We define this to execute every minute and to control individual jobs that we may want to run less frequently — we use “Time Since Last Run” concept. Users can maintain this information themselves using a simple front-end application:

All WMS implementations have some of these jobs that are developed over time to handle typical issues. For example:

• We often have orphan invmov records. We can detect such records and then delete them.
• Sometimes we have pckmov records that do not have corresponding pckwrk records. We can detect the condition and kill such pckmov records
• It is common to have situations where rescod is not cleared. We can detect the condition and run “deallocate resource location” for these locations.
• It is often a requirement to reprocess downloads in EERR status.
• We can create a monitor to detect some abnormal conditions and send an email to a set of users with results of the query. This solution is easier than creating an EMS alert since it does not require a roll-out process and the email can include detailed results.

Conclusion

Any sort of an application monitor is a common requirement in any large system and, JDA WMS is no exception. Above design, pattern can be implemented generally for any large system. It looks at the problem abstractly and provides a solution that is simple to implement, maintain, and manage.

Originally published at saadwmsblog.blogspot.com.