Page tree
Skip to end of metadata
Go to start of metadata

Integrations require that your service interacts with an external application or technology. A standard integration is considered to be any on-premises system that communicates with the BMC Helix service using an approved method or adapter. See Integrations for a list of these standards. If you wish to communicate with your Helix service using any other method or adapter, or if your integration modifies the forms that are supplied with the out-of-the-box service, the integration is considered to be non-standard and is therefore considered a customization. In this case, pre-approval by the BMC Customization Review Board (CRB) is mandatory. If approved, the integration code must be designed and developed to conform to the same design standards and best practices as defined in the customization policy.

Occasionally non-standard integrations are required to support data flow between your on premises applications and your Helix service. Allowable functions include extending core functionality through means of a Java filter or AR System Database Connectivity (ARDBC) plug-in. Customers wishing to use one of these two methods must follow the approval process detailed below, and agree to design and develop their integration within the operational guidelines stated herein. Non-standard integrations should only be considered if the use case cannot be easily achieved with existing product features or standard integration methods.

This topic contains the following information:

Approval process

The approval process involves contacting the BMC CRB and submitting your design documentation for review. It is the customer's responsibility to review this policy and validate that their filter or plug-in complies with these published standards. To submit a request to the BMC CRB, use the Request Something Else option if you are using the i.onbmc support portal, otherwise submit a case via Support Central. In the Summary field, prefix the summary with "Customization Request:". This will ensure that the request is routed to the CRB promptly. In the Description field, provide an overview of the integration and high-level technical details of the custom component. Attach related design documents as necessary.

Code standards

Ongoing support for your customizations is your responsibility. To maintain supportability, BMC enforces the following standards:

  • Plug-ins must follow development guidelines as documented by BMC. See Creating Java plug-ins for information. 
  • Plug-ins must be of type Filter or ARDBC.
  • Plug-ins must be written in Java.
  • Plug-ins must be compiled with current protocol version (same version as your environment's AR Server). As platform and/or application upgrades are scheduled, the customer is responsible for releasing a compatible plug-in version to BMC prior to the upgrade.
  • Plug-ins may not contain GNU General Public License (GPL) or copyleft code as part of the distribution. The customer remains responsible for obtaining proper licensing for any third-party software and for providing license validation upon BMC's request.
  • Plug-ins must run in their own plug-in server.  Existing plug-in servers may not be modified.
  • Configuration may not depend on IP addresses or hard coded hostnames.
  • Configuration may not contain usernames and/or passwords.
  • Configuration information like keystore information, certificates, and so on must be provided by the customer. The customer is responsible for preventing certificate expiry.
  • Configuration information must be provided as-is. Any manual changes must be documented with the least possible steps.
  • Plug-ins may not modify standard application or system configuration files.
  • Plug-ins will not be accessible via the internet.
  • Plug-ins will not have access to internal DNS servers or services.
  • Plug-ins may not host a runtime that will perform continuous background processing. The plug-in can be a request/response handler only.
  • Plug-ins must be packaged in a .tar file format, following current standard Remedy directory structure. The installation process should not require reverse engineering.


Adherence to these tenets will serve as the basis for customization approval. Adherence is non-negotiable.

Required documentation

BMC requires that, at a minimum, the following information be included in the design document: 

  • Intended use of the integration including where data is coming from, where data is going to, and how data is being transported
  • Maximum memory footprint (-xmx flag) requirements
  • A pluginsrv_config.xml template describing content between <plugin></plugin> tags
  • An ar.cfg configuration template with optional configuration placeholders including the Server-Plugin-Alias MY.PLUGIN entry:  MY.PLUGIN onbmc-s:<PLUGINPORT>
  • A description of any access the plug-in will require including:
    • Inbound network ports (the plug-in port is assumed by default)
    • Outbound network ports and services
    • File system access (read and write)
    • Fork/execute permissions

Operational responsibilities

The following table outlines the responsibility of each party in the lifecycle of a custom integration implementation.

TaskResponsible partyNotes
Gather the required documentation related to the customizationCustomerReview the minimum documentation requirements above.
Validate proper compliance to the standards provided herein; validate proper software licensing is in placeCustomer

Review this standard in its entirety prior to submitting a request for approval.

If you are unsure of the licensing terms of your customization, consult with your in-house legal department before requesting approval from BMC.

Request approvalCustomerUse the Request Something Else option if using the i.onbmc support portal or submit a case if using BMC Support Central. Attach the design document to the request; make sure it includes the design components listed above.
Assessment and decisionBMC CRBBMC, in its sole discretion, may approve or deny a request.
Request code installationCustomer

Use the Request a Change option if using the i.onbmc support portal or submit a case if using BMC Support Central. A separate request is required for each environment.

The customer must provide the required documentation listed above, and provide detailed installation steps and operational requirements as part of the change request. Failure to provide the proper detail may result in a delay in implementing the change.

Implement change requestBMC SaaS Operations

Implementation of a change request will follow the BMC Helix Change Management policy.

BMC will enforce isolation according to the plug-in access requirements.

BMC will implement the change using the local AR Server port of 46262 and local AR Server hostname of "onbmc-s".

Customization isolationBMC SaaS Operations

BMC reserves the right to isolate a plug-in and enforce the access requirements that were documented by the customer. The isolation may be enforced using any standard method, including, but not limited to:

BMC may use any isolation method to reduce exposure of the executable outside of the documented required access rights.

Customization validation/testingCustomerThe customer is responsible for performing all technical and functional testing for the customization, including initial configuration and after system patches and upgrades.
Customization maintenanceCustomerThe customer is responsible for maintaining the custom code. BMC will not analyze log files generated by the plug-in. The plug-in must use standard AR logging mechanisms and practices. BMC will provide the logs upon request via the File transfer process. A separate operational request is necessary to set up the MFT process.
Customization monitoringCustomer

BMC will not monitor the plug-in for termination or problems with availability as BMC does not know the test cases. BMC advises that the customer provide some self-monitoring and embed methods of notification in case of component failure. BMC will use a standard and dedicated AR plug-in server process to run the plug-in.

BMC will however monitor CPU consumption. Excessive resource consumption will not be permitted. The plug-in should not consume more than 10% of the total available CPU; BMC reserves the right to cap this consumption at 10%.

Customization removalBMC SaaS OperationsUpon customer request, BMC will deactivate and uninstall the customization, and return or permanently destroy the code.

Customization guidelines

If BMC determines that the customization puts a contractual obligation between BMC and any of its customers at risk, BMC reserves the right to take any action necessary to guarantee these commitments. Causes for action include, but are not limited to, service stability, service availability, service performance or any kind of security threat. Mitigation actions may include restarting the plug-in, capping execution parameters, increasing the isolation configuration, changing configuration parameters or even deactivating the plug-in. BMC will promptly notify the customer if a restart or deactivation is required but may not be able to do so in advance of taking action.

In order to determine impact, BMC may monitor the customization, including but not limited to, accessing log files, changing log settings, tracking execution or even attaching debuggers.


You are responsible for ensuring that your plug-in will not violate your agreement with BMC or any applicable law. You are solely responsible for the development, content, operation, maintenance, and use of your plug-in.

Related topics


BMC Helix Client Gateway connectivity

File transfer process

1 Comment