Wednesday, September 12, 2018

RedPrairie/JDA Application Monitor

Overview

One thing that all large implementations have in common is the need for some tasks that need to be done 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 slightly more elaborate construct called jobs.  

Our Approach

At Oracular 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 oracular

Our Solution

We define this monitors in a new table:
ColumnDescription
Monitor IdA unique name for each monitor
DescriptionDetailed information about it
Sort#To control the sequence in which the monitors run
Time Since Last RunSecond since last run. The monitor job could be running every minute but one of the monitors may be defined to run every 10 minutes.
Enabled?1/0 to enable it
Detect Command4000 byte field to provide MOCA or SQL to detect an abnormality. Return n rows.
Fix Command4000 byte field to provide MOCA to fix 1 row. Executes for each row returned from detect command
Log Dlytrn?1/0 to log dlytrn for each row returned by detect command
Raise EMS on Fail?1/0. if enabled, raise EMS alert if fix command fails
The solution is in the form of a single MOCA command called "run ossi monitor" that 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 condition 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 rollout process and the email can include detailed results. 

Conclusion

Some sort of an application monitor is a common requirement in any large system and RedPrairie/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.  

3 comments:

  1. Thanks for sharing the information

    Application Monitor Maintenance screen is available for all verson of JDA client application or do we need to create DDA based on this Job ? Like how will we enable it to system? Help would be appriciated

    ReplyDelete
    Replies
    1. It is a suggestion for a customization. This is not available in standard JDA

      Delete
  2. Thanks for sharing this content, very excellent article. Best customized erp software development company in chennai.

    ReplyDelete