Customizations as part of integrations

Integrations require that your service interacts with an external application or technology. A standard integration is considered to be any integration that communicates with BMC Helix platform using an approved method or adapter. See Integrations for a list of these standards. If you wish to communicate with your Helix platform using any other method or adapter, it is considered as a non-standard integration / plug-in. The integration code must be designed and developed by adhering to the design standards and best practices as defined in the customization policy.

Occasionally integrations are required to support data flow between on-premises and/or third-party application and Helix platform. 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 are subject to BMC’s discretion to reject the implementation in case of vulnerabilities and infrastructure risks identified. Non-standard integrations should only be considered if the use case cannot be easily achieved with existing product features or standard integration methods.

It is the customer's responsibility to review this policy and validate that their filter or plug-in complies with these published standards. 

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. For information, see Creating Java plug-ins .
• Customizations must comply with the licensing capacities purchased in your BMC Helix agreements; the customer is responsible for reviewing beforehand whether your plug-in will require additional BMC Helix subscription services licensing, please contact your BMC Account Team to review.
• The customer is responsible for acquiring and maintaining any third-party licensing required outside of your BMC Helix subscription.

• BMC is not responsible for errors and use cases associated with any third-party or open source code outside of your BMC Helix platform.

• 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 updates are scheduled, the customer is responsible for releasing a compatible plug-in version to BMC prior to the update.
• 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.

Non-Standard Customizations and Integrations not supported on SaaS

• Direct access to update the database forms/tables
• File and script processing through workflows
• View forms/tables

• Direct SQL updates through workflows
  
  

Recommended 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.

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.