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:
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.
Ongoing support for your customizations is your responsibility. To maintain supportability, BMC enforces the following standards:
Adherence to these tenets will serve as the basis for customization approval. Adherence is non-negotiable.
BMC requires that, at a minimum, the following information be included in the design document:
ar.cfgconfiguration template with optional configuration placeholders including the Server-Plugin-Alias MY.PLUGIN entry:
The following table outlines the responsibility of each party in the lifecycle of a custom integration implementation.
|Gather the required documentation related to the customization||Customer||Review the minimum documentation requirements above.|
|Validate proper compliance to the standards provided herein; validate proper software licensing is in place||Customer|
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 approval||Customer||Use 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 decision||BMC CRB||BMC, in its sole discretion, may approve or deny a request.|
|Request code installation||Customer|
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 request||BMC 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 isolation||BMC 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/testing||Customer||The customer is responsible for performing all technical and functional testing for the customization, including initial configuration and after system patches and upgrades.|
|Customization maintenance||Customer||The 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.|
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 removal||BMC SaaS Operations||Upon customer request, BMC will deactivate and uninstall the customization, and return or permanently destroy the code.|
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.