Custom Change Management System
- Muthu Sankaralingam
- Emily Simon
- Jay-Ar Brouillard
- Erick Jones
FlexDeploy has out of box integration with ServiceNow, BMC Remedyforce, Freshworks Freshservice, and Jira ITSM, and provides a framework to enable custom integrations with other change management systems. Such third party Change Management System integrations can be enabled using a Java or Groovy implementation.
Navigate to the Change Management Systems page from the Administration -> Integrations -> Change Management Systems menu. Here you will see the out of the box integrations for the three providers.
To create a custom integration for another provider click the Create button. The following tasks will be performed to complete the integration:
- Provide a unique name and description.
- Determine whether you will implement the integration in Java or Groovy. Groovy has the advantage that the script is loaded dynamically and does not require a FlexDeploy server recycle when you make changes.
- Define properties for the new change management system. Properties are configuration values used by FlexDeploy to connect to the new system and parameterize its usage.
- Develop either a Java class or Groovy script to perform the integration.
The examples below demonstrate a custom integration for Zendesk using both Java and Groovy.
Properties
The Properties tab defines the metadata for parameters necessary to both connect to the underlying system and provide configurable options for any instances which will consume this integration.
URL, credentials, and other connection related parameters should be exposed as properties so that the configuration can be updated without changes to the Java or Groovy classes/scripts.
For customers providing your own integrations you may choose to hard-code some of the logic into the scripts to follow enterprise standards for your organization. For Systems Integrators who are developing solutions which may be utilized by multiple customers it is important to make use of properties where appropriate to allow simple configuration based on end customer requirements.
The metadata for each property consists of the following attributes:
| Attribute | Description |
|---|---|
| Active | Whether this property is in use for the integration. Allows hiding the property without removing it. |
| Key Name | A unique name which is used by the API and other scripts, and therefore must following keyword limitations of Java and Groovy (e.g. no spaces or special characters other than underscore). |
| Display Name | A name for the property which will be displayed for data entry rather than the technical Key Name. |
| Description | A meaningful description of what the property is used for. |
| Data Type | The data type for the property. Supported types - String, Boolean, Integer, or Double, |
| Sub-Type | An optional qualifier describing the type of data the property will contain. This is used to validate the data entry. Supported types - URL, JDBCURL, or Directory. Simply leave blank if none of these qualifiers are applicable. |
| Required | Whether or not a value for the property is required for CMS instances using this provider. Implementations should use default values in the Java/Groovy class or script for any optional properties. |
| Encrypted | Indicates whether the property is secure and should be encrypted when stored, and care should be taken not to print their values in the logs. |
Values for these properties will be provided when instances of this CMS are created.
API Implementation
Custom integrations must implement the following API operations:
Method Name | Parameter(s) | Return Type | Description |
|---|---|---|---|
createTicket | Map<String,Serializable> pTicketFields | void | Creates a Change Request ticket using the pDescription and pComment |
createIncident | Map<String,Serializable> pTicketFields | String | Creates an Incident ticket using the pDescription and pComment |
findCMSObjectByType | String pCMSObjectNumber ChangeManagementSystem.CMSObjectType pCMSObjectType | void | Find a "ticket" or "incident" using the object identifier and type. The object type will be TICKET or INCIDENT, and implementations must translate that into the corresponding object type within the provider (e.g. Problem, Request, etc.) |
| isTicketApproved | CMSObject pTicket String pEnvironmentCode | Boolean | Returns whether the ticket is approved in the CMS. |
| isTicketRejected | CMSObject pTicket String pEnvironmentCode | Boolean | Returns whether the ticket is rejected in the CMS. |
checkConnection | N/A | void | This method should invoke any status or heath check URL of the change management system to ensure the system is up and running and a connection can be authenticated. This method will be called when the Test Connection button is clicked on the CMS Instance. |
isDoPolling | N/A | void | Returns whether FlexDeploy should automatically poll the CMS to identify whether the ticket is approved or rejected. If polling is enabled FlexDeploy will lookup the ticket every 1 minute using findCMSObjectByType and then check the status using the isTicketApproved and isTicketRejected methods. If polling is not enabled, the CMS or another external system is responsible for approving/rejecting the associated task using the FlexDeploy REST API. |
| getTicketURL | CMSObject pCMSObject | String | returns the REST API url of the change ticket |
If your usage of the CMS will not include the automated creation of TICKET or INCIDENT objects the API can be simplified. Although createTicket and createIncident are required to be implemented, if you are not using these auto-creation features you can choose to simply throw an exception from one or both methods as appropriate.
throw new UnsupportedOperationException("createIncident is not supported for Zendesk CMS integration");
Add custom task notes
With out-of-the-box CMS providers including BMCHelixRemedyforce, ServiceNow, JiraITSM, and Freshworks, you have the ability to add notes to a FlexDeploy External Approval upon approval or rejection. Custom Change Management Systems have the same functionality. Can do so by overriding the following getAdditionalTicketInfo in your Groovy API. It takes CMSObject and environment code as parameters and must return a Map<String, String>.
def getAdditionalTicketInfo(CMSObject pTicket, String pEnvironmentCode)
{
// Create notes to add to External Approval
def changeNumber = pTicket.getNumber()
def map = {'notes': 'Approval note for ' changeNumber + ' added by FD admin'}
return map
}
Java Implementation
Here are high level steps for Java implementation. You can use any IDE to prepare this implementation.
- Create java class that extends flexagon.fd.model.integration.cms.api.ChangeManagementSystem. Example shown below has the methods implemented which uses properties map to retrieve the configuration values to connect to the change management system.
- All properties defined are available in Map returned by getProperties method.
- We are using Zendesk as a use case
- In order to compile your java class, you will need FlexDeployAPI.jar on classpath.
- Implement all the methods described in the table in the API Implementation section.
- For any failure connecting to the system or if any issues with the data, then you can throw exception. For example throw new ApiException("Invalid credentials.", "");
- Once you are ready with unit testing, you can prepare Jar file for your credential store java class and other utility classes. This jar file can be placed on server classpath now.
- For Tomcat, put this jar file in apache-tomcat-flexdeploy/lib folder.
- For WebLogic, put this jar file in Domain lib folder.
- If you are using any third-party libraries from your Java implementation, then those jar files will also need to be added to same lib folder. Keep in mind that this can cause issues with server functioning, so be prepared to remove your additional library files.
- To pickup changes to your API, the FlexDeploy server must be restarted.
Groovy Implementation
Here are high level steps for Groovy implementation. You can use any IDE to prepare this implementation.
As groovy is able to access FlexDeploy variables and Java classes, you can take advantage of Java libraries from Groovy script. For example, if there is Java library used to access the change management system, you can places those in lib folder and use those classes from Groovy script. This allows you to keep dynamic part of implementation in Groovy and use Java library.
- Create a groovy class. Example shown below has the methods implemented.
- We are using Zendesk as a use case
- All properties defined are available as groovy binding variables. For example, properties can be accessed directly like BMC_DOMAIN_NAME, BMC_SALESFORCE_HOST_NAME or BMC_USER_NAME etc
- Implement all the methods described in the table in the API Implementation section
- For any failure connecting to the system or if any issues with the data, then you can throw exception. For example throw new ApiException("Invalid credentials.", "");
Groovy has the advantage that changes to the API are picked up dynamically without having to recycle the server.
Groovy Utilities
There are some utility variables provided by FlexDeploy that can be used in your custom Groovy code.
- log is a FlexDeploy logger variable which should be used to log any information from the groovy class.
- fdrestutils is a utility object available to use FlexDeploy API to invoke any REST API. See the Java docs for more details on the functions available.
def builder = new groovy.json.JsonBuilder() def root = builder.issue { notes "${pComment}" } String payload = builder.toString(); String ticketNumber = ticket.getNumber(); String resourcePath = REDMINE_TICKET_REST_PATTERN.replaceAll("\\{REDMINE_ISSUE\\}", ticketNumber) fdrestutils.putRequest(REDMINE_URL, REDMINE_USER_NMAE, REDMINE_PASSWORD, resourcePath, payload);
Related content
- style