Custom Change Management Systems

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.

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.
Define Ticket Fields as necessary, which are used to create Ticket or Incidents automatically from FlexDeploy.
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

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

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.

Example

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

Simple Example

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