Custom Plugins: Extending the Power of Your ITSM Platform
In the world of IT Service Management (ITSM) and enterprise application development, flexibility and extensibility are key. While out-of-the-box functionalities are powerful, there often comes a time when you need to perform actions or integrate systems that aren’t natively supported. This is where the concept of custom plugins shines. They are your secret weapon to tailor your ITSM platform, like BMC Helix ITSM or Remedy, to precisely meet your unique business requirements.
Think of your ITSM platform as a sophisticated toolkit. It comes with an array of excellent tools. However, sometimes you need a specialized wrench or a custom-built jig to get a particular job done perfectly. That’s what custom plugins enable you to create.
What Are Custom Plugins?
At its core, a custom plugin is a piece of code that you develop and integrate into your ITSM platform to add new functionality or extend existing capabilities. These plugins operate within the platform’s environment, allowing them to interact with its data, processes, and users. They bridge the gap between what the platform can do by default and the specific, often complex, tasks your organization needs to accomplish.
For platforms like BMC Helix ITSM and its predecessors (e.g., BMC Remedy AR System), plugins are a well-established mechanism for customization. They allow developers and administrators to move beyond the standard workflows and actions offered by the platform’s configuration tools and implement more advanced logic or integrations.
Why Would You Need Custom Plugins?
The need for custom plugins arises from various scenarios:
- Integrating with External Systems: Your ITSM platform might need to communicate with other business applications that don’t have pre-built connectors. This could include custom HR systems, specialized inventory management tools, or even legacy applications.
- Performing Complex Data Manipulations: Sometimes, you need to perform intricate calculations, data transformations, or validations that go beyond the capabilities of standard workflow actions.
- Automating Non-Standard Tasks: If there’s a specific operational task that needs automation but isn’t covered by typical ITSM processes, a plugin can be developed to handle it.
- Enhancing User Interface Elements: While less common, plugins can sometimes be used to introduce custom UI components or alter user interactions in specific ways.
- Leveraging Third-Party Libraries: You might want to incorporate the functionality of external libraries or APIs into your platform’s processes.
The Technical Landscape: BMC Helix ITSM and AR System
When discussing custom plugins in the context of BMC Helix ITSM and BMC Remedy AR System, we’re often referring to the AR System Plug-in Server architecture. This architecture allows you to develop plugins in languages like Java or C++ that can be deployed and executed by the AR System server. These plugins are typically invoked as actions within AR System workflows, such as Active Links, Filters, and Escalations.
The AR System Plug-in Server acts as a bridge, enabling AR System to call your custom code. This separation of concerns means that your custom logic is distinct from the core AR System code, making it easier to develop, deploy, and maintain.
For more in-depth technical details and development guides, the official BMC documentation is an invaluable resource:
- Developing a Java API Plugin (BMC AR System 9.1) – This provides a foundational understanding of Java plugin development.
- Creating a plug-in (BMC Helix ITSM 20.02) – Covers the general process of creating plugins within the BMC ecosystem.
- Plug-in Server (BMC Helix ITSM 21.02) – Understanding the Plug-in Server is crucial for deploying and managing plugins.
- Developing a C API plugin (BMC AR System 9.1) – For those who prefer or require C/C++ development.
The Development Process of a Custom Plugin
Developing a custom plugin is a systematic process that requires careful planning and execution. Here’s a breakdown of the typical steps involved:
1. Requirement Gathering and Design
This is the most critical phase. Before you write a single line of code, you must thoroughly understand:
- What specific problem is the plugin intended to solve?
- What are the inputs and outputs of the plugin’s functionality?
- What data will it need to access or modify within the ITSM platform?
- What are the expected performance requirements?
- What are the security considerations?
Real-World Example: Imagine a scenario where your company uses a custom-built applicant tracking system (ATS) that is not integrated with your HR Service Management (HRSM) application within BMC Helix ITSM. When a candidate is hired, their details need to be transferred to create an employee record in BMC Helix. A custom plugin could be designed to fetch candidate data from the ATS API and create/update a user record in BMC Helix.
2. Choosing the Right Technology Stack
For BMC platforms, Java is often the preferred language for plugin development due to its robustness, extensive libraries, and good integration with the AR System Plug-in Server. However, C++ can also be used for performance-critical applications.
- Java: Offers a rich ecosystem of libraries and frameworks, making it suitable for a wide range of tasks.
- C++: Can be used for high-performance plugins where raw speed is paramount.
3. Development and Coding
This is where you translate your design into actual code. You’ll typically interact with the AR System API (often via the AR System Java API for Java plugins) to perform operations like:
- Retrieving records from forms.
- Modifying existing records.
- Creating new records.
- Performing complex queries.
- Calling external APIs.
Key Concepts to Familiarize Yourself With:
- AR System API: The interface your plugin uses to communicate with the AR System server.
- Data Types: Understanding how AR System data types (e.g., Character, Integer, Decimal, Time) map to Java data types.
- Error Handling: Implementing robust error handling is crucial for stable plugins.
- Logging: Detailed logging is essential for debugging and monitoring.
4. Building and Packaging
Once your plugin code is written, it needs to be compiled and packaged into a deployable format. For Java plugins, this usually means creating a JAR file. You’ll also need to configure specific manifest files and plugin descriptor files that the AR System Plug-in Server uses to recognize and load your plugin.
5. Deployment
Deployment involves placing your plugin’s JAR file (or equivalent for other languages) into the designated plugins directory on your AR System server. You’ll also need to configure the AR System Plug-in Server to load and recognize your plugin. This often involves editing configuration files (e.g., pluginsvr_config.xml).
6. Testing and Debugging
Thorough testing is non-negotiable. This includes:
- Unit Testing: Testing individual components of your plugin.
- Integration Testing: Testing how your plugin interacts with the AR System and any external systems.
- Performance Testing: Ensuring the plugin doesn’t negatively impact the overall performance of your ITSM platform.
Debugging often involves using logging statements within your plugin and examining the AR System server logs and the Plug-in Server logs.
7. Maintenance and Updates
As your business needs evolve or the ITSM platform is upgraded, your custom plugins may require maintenance or updates. This ensures they continue to function correctly and efficiently.
Types of Actions Triggered by Plugins
Custom plugins are typically invoked as actions within AR System workflows. The most common types of workflows where you’d use a plugin action are:
1. Filters
Filters execute automatically when a record is created, modified, or displayed. A plugin action can be added to a filter to perform custom logic based on the record’s state.
Real-World Example: When a new incident is created, a filter might trigger a plugin action that calls an external CMDB (Configuration Management Database) API to find related configuration items (CIs) based on the reported product or service. The plugin then populates specific fields in the incident form with this related CI information.
2. Active Links
Active links execute when a user interacts with a form (e.g., clicking a button, changing a field value). They are often used to provide dynamic user experiences or trigger immediate actions.
Real-World Example: A user clicks a custom button on a change request form. This button’s associated active link triggers a plugin action that initiates an external approval workflow in a dedicated system, sending relevant change request details to that system and waiting for a response. The plugin then updates the change request form with the approval status.
3. Escalations
Escalations are scheduled events that run at predefined intervals or when certain conditions are met. They are often used for proactive management and overdue tasks.
Real-World Example: An escalation runs every hour to check for pending tasks on overdue change requests. If it finds any, it triggers a plugin action that sends a highly personalized notification (perhaps with specific details dynamically retrieved from another system) to the assigned support group manager.
Benefits of Using Custom Plugins
- Unparalleled Customization: Tailor your platform to fit exact business processes, not the other way around.
- Enhanced Integration Capabilities: Seamlessly connect your ITSM with other vital business systems.
- Increased Automation: Automate complex or repetitive tasks that standard tools cannot handle.
- Improved Efficiency and Productivity: Streamline workflows, reduce manual effort, and accelerate resolution times.
- Competitive Advantage: A highly customized and efficient system can give your organization an edge.
Troubleshooting Common Plugin Issues
Developing and deploying plugins can sometimes lead to unexpected behavior. Here are some common issues and how to approach them:
Common Plugin Troubleshooting Scenarios:
- Plugin Not Loading/Not Found:
- Check Deployment: Ensure the plugin JAR file is in the correct plugins directory on the AR System server.
- Configuration Errors: Verify the
pluginsvr_config.xmlfile has the correct entries for your plugin (plugin name, class name, etc.). - Permissions: Ensure the AR System server process has read permissions for the plugin files.
- Plugin Errors During Execution:
- Examine Logs: This is your primary tool! Check the AR System server logs (
arsystem.log) and the Plug-in Server logs (often found in theARSystem/logsdirectory or a custom location). Look for stack traces and error messages specific to your plugin. - Input/Output Mismatches: Ensure the data being passed to your plugin from the workflow matches the data your plugin expects. Also, check that the data returned by the plugin is in the correct format for the workflow.
- External Service Issues: If your plugin interacts with external APIs or services, ensure those services are accessible and functioning correctly.
- Null Pointer Exceptions (Java): These are very common. They indicate you’re trying to access a method or variable on an object that is null. Use logging to trace variable values.
- Examine Logs: This is your primary tool! Check the AR System server logs (
- Performance Degradation:
- Inefficient Code: Review your plugin’s code for inefficient loops, excessive database queries (if applicable within the plugin), or poorly optimized algorithms.
- Resource Consumption: Monitor the plugin server’s CPU and memory usage. A poorly written plugin can consume excessive resources.
- Synchronous vs. Asynchronous Calls: If your plugin makes calls to slow external systems, consider how it impacts the AR System server.
- Security Vulnerabilities:
- Input Validation: Always validate any data received from the AR System or external sources to prevent injection attacks or unexpected behavior.
- Secure Credentials: If your plugin needs to access external systems using credentials, use secure methods to store and retrieve them (e.g., dedicated credential management systems, not hardcoded values).
Interview Relevance
Understanding custom plugins is a significant advantage in interviews for roles involving ITSM administration, development, or architecture, especially for organizations using BMC Helix or Remedy.
Key Topics to Discuss in an Interview:
- When to use plugins vs. out-of-the-box features: Demonstrates an understanding of platform limitations and strategic customization.
- The AR System Plug-in Server architecture: Shows knowledge of how plugins integrate technically.
- Common languages and APIs for plugin development (Java API): Highlights technical proficiency.
- Example scenarios where a plugin would be essential: Provides practical application of knowledge.
- Troubleshooting approaches for plugin failures: Shows problem-solving skills.
- Benefits and drawbacks of custom plugins: A balanced perspective.
- Awareness of official documentation resources: Indicates a commitment to learning and best practices.
Be prepared to walk through a hypothetical plugin development scenario, explaining your thought process from requirement to deployment.
Conclusion
Custom plugins are not just a technical feature; they are a strategic asset. They empower organizations to mold their ITSM platform into a powerful, tailored solution that drives efficiency, enhances integration, and supports complex business processes. While they require development expertise and careful management, the ability to extend functionality beyond the standard offerings is invaluable for any organization looking to maximize its investment in ITSM.
By mastering the development and deployment of custom plugins, you unlock a new level of control and customization for your ITSM environment, ensuring it remains a dynamic and effective tool for your business operations.