Previous versions of the Infor M3 enterprise resource planning (ERP) application were installed solely on IBM i (AS/400, iSeries), so the skills required to support it were standard IBM i administration-type skills, including user profile management and batch and interactive workload management, along with message job queue and spooled file management. If an administrator was comfortable supporting IBM i, then M3—or Movex as it was then called—could be also supported, no additional skills required.
Today, the M3 Business Engine is now supported on IBM i, Windows, AIX, Sun Solaris, and Linux. The majority of M3 installations are opting for Microsoft Active Directory integration along with other complimentary M3 applications, in addition to optional external disk and high availability demands. On top of that, the introduction of Java has further compounded the ongoing support of this environment. So, it’s easy to see how critical events be missed.
Centralize and simplify Infor M3 monitoring with the pre-configured monitoring template from Halcyon.
Equally difficult is finding a single monitoring tool that spans these operating systems and is also capable of monitoring the hardware, operating system, and application layers while tracking activity within a Java Virtual Machine (JVM).
It’s no surprise, then, that this mix of tightly-integrated workloads forces those supporting M3 to resort to a number of tools and enlist the help of multiple platform-based administrators.
Identifying the Blind Spots in Infor M3 Monitoring
With M3 being somewhat fragmented, it is essential to establish a central console that incorporates all components, regardless of underlying platform, to simplify monitoring checks. This is easier said than done, as it can be difficult to centralize all administrative activities involved in monitoring M3 when using multiple monitoring tools that do not integrate well with each other.
Since superseding ServerView, the Grid has become key to both the day-to-day administration and ongoing support of the M3 application. Due to the distributed nature of M3, the Grid acts as a common point of entry for all underlying M3 services and applications, which can span multiple servers, potentially on disparate platforms.
Naturally, a lot of information is housed here. Spikes might be easy to spot with some monitoring tools, but prolonged periods of activity are often the early indicators of an underlying issue likely to impact the business. M3 and many monitoring tools have no ability send alerts based on these conditions.
For an M3 administrator to maintain control, they must be able to easily verify that time- or event-driven activities, such as backups, have occurred as expected. To do this effectively, they must check history logs, event logs, and log files and have the option of sending a notification when a planned activity is missed or found to be overrunning. This can be time-consuming to perform manually.
If they don’t have the time or resources to proactively monitor services, processes, subsystems, and jobs, it’s impossible to ensure that output is flowing through the M3 Management Output System (MOS), that the M3 Enterprise Collaborator (MEC) is active, that MapGenServer is running, or that OpenText StreamServe is operating as expected. It also makes it difficult to maintain visibility into LifeCycle Manager (LCM).
The web services responsible for keeping M3 Smart Office and M3 Work Place active are also essential to the running of M3. Without these, a degraded connection or total service failure is possible. Monitoring JVM activity can be particularly important for many M3 shops, as well.
Outside of the application metrics, it’s also critical to keep a track of general system administration elements, including CPU, disk, and memory. With many M3 environments opting for Microsoft Active Directory integration, Active Directory, and its associated performance counters and event log messages also become critical to M3 application access.
Similarly, other hardware such as external disk systems, hubs, switches, routers, and environmental equipment all play a part in this closely connected environment.
Halcyon Closes the Gaps in Infor M3 Monitoring
Halcyon has built a pedigree of being able to provide end-to-end monitoring of Infor M3 no matter which operating systems have been deployed. All of the information feeds into Halcyon Enterprise Console, offering proactive real-time monitoring across all versions of M3, completely eliminating manual checks in some cases, and adapting as and when the ERP application itself does.
Enterprise Console provides an exception-based, color-coded graphical console that spans all supported M3 infrastructure. The console can be installed on a Windows client and on any Apple or Android device to provide fully-mobile M3 monitoring.
The Halcyon Infor M3 template is designed to help users quickly deploy industry-standard, base-level monitoring in minutes. Individual Halcyon rules can then be applied on top easily accommodate heavily customized M3 environments.
When it comes to the keeping an eye on the Infor Grid, the Halcyon template monitors and sends notification for many of the elements, including:
- Host, node, and port statuses
- Excessive CPU activity
- Heap usage, both in terms of megabytes consumed and as a percentage
- Mandatory background autojobs, both the count and ensuring that a defined list of autojobs are active
- Number of connected sessions
- Number of warnings or errors written to logs
Halcyon alerts can be sent as visual notifications, audible sounds, SMS messages, or emails. With administrators often away from their desk, the ability to respond to alerts is a powerful must-have option and Halcyon is happy to oblige here as well.
With the recent introduction of being able to execute a REST command (Representational State Transfer), Halcyon allows users to automatically restart a non-running autojob, for example. Should issues be detected, it’s important to have the option to automate recovery as well as optionally raising exceptions where necessary.
Halcyon offers granular monitoring of JVM activity, automatically pinpointing current heap size, thread count, and the total time spent performing garbage collection tasks. Database monitoring for instances including DB2, Microsoft SQL Server, and Oracle are included as standard, both for real-time metrics and historical trend analysis. Lock-wait and message-wait conditions can also be tracked.
Where system elements are considered, Halcyon’s pre-configured templates speed up both the initial monitoring deployment and the ongoing administration of spiralling server estates. Halcyon SNMP-based monitoring can be administered for network hardware components, all filtering up to Enterprise Console.
Halcyon’s power monitoring templates now cover many major ERP, high availability, and backup solutions, in addition to operating systems and associated hardware layers. To see the Infor M3 monitoring template in action, request a demo.