1 Building a Ticketing Connector

This chapter provides information you need to build a ticketing connector and integrate it with Enterprise Manager.

This chapter has the following sections:

Note:

A ticketing connector is sometimes known as a help desk connector.

1.1 Introduction to Ticketing Connectors

Enterprise Manager Cloud Control 12c provides a Management Connector Framework (referred to as Connector Framework) to allow developers to build ticketing connectors to create/update tickets/incidents in an external ticketing application. Conceptually, a ticket and an incident are identical. To avoid confusion, incident will be used to refer to an incident in Enterprise Manager, and ticket will be used to refer to an incident in the external ticketing application.

For the connector to exchange data with the external ticketing application, a web service must be available that the connector can invoke to retrieve, create, and update incident information. The connector is composed of a set of XML and XSLT metadata files that define how the connector appears in the UI and how it connects to and exchanges data with the external ticketing application.

Ticketing connectors can be invoked in two different ways:

  • Auto Ticketing

    Lets you configure the connector to automatically open or update a ticket whenever an incident or event is triggered in Enterprise Manager. You can specify incident rules for tickets to be created or updated.

  • Manual Ticketing

    Lets you manually create a ticket from the Enterprise Manager console based on an open incident or event in Enterprise Manager. The connector populates the ticket with details based on the incident and the ticket template.

To use these ticketing features for your own help desk or ticketing system, you need to provide a set of metadata files. Table 1-1 lists the categories of metadata files that comprise a ticketing connector:

Table 1-1 Metadata File Categories

Category Type Description

Connector Descriptor

XML

The connector descriptor file defines the connector in Enterprise Manager. The file contains information about how the connector will appear in the UI, where the web service is located, how to connect to it, and what templates to use to translate data sent between systems.

Ticket Request Templates

XML or XSL

These templates generate XML requests that are sent to the web service to retrieve, create, or update a ticket. They translate the Enterprise Manager incident data fields into the format expected by the web service.

Response Templates

XSL

The response templates translate the XML response returned by a web service call into the format expected by the Connector Framework.

Publish Template

XSL

This optional template synchronizes ticket status. This template updates the ticket status in Enterprise Manager whenever the status of a ticket in the external ticketing application changes.

1.2 How a Ticketing Connector Functions

In order to know how to build a ticketing connector, you need to understand how one functions. The connectorDeploy.xml file, commonly referred to as the connector descriptor file, defines the connector in Enterprise Manager. When the connector is installed, the contents of the connector descriptor file are examined by Enterprise Manager to determine what fields are required by the connector and what templates to use when exchanging XML messages with the web service.

The following sections describe the functionality of a ticketing connector:

1.2.1 Configuring the Connector

When the operator configures the connector, the configuration page is generated based on the information in the connector descriptor file. Typically, this includes fields that contain the URL and credentials to use when connecting to the web service. One of the fields that is required for a ticketing connector is the Ticket ID field. Use this field to verify connectivity to the external ticketing application. It must be set to the identifier of an existing incident in the external ticketing application. When the operator clicks the Ok button on the configuration page, the Connector Framework performs the getTicket operation to retrieve information for the ticket identifier specified in the Ticket ID field. The Connector Framework uses the getTicket request template defined in the connector to generate the XML that is sent to the web service to retrieve the ticket information. When it gets the response from the web service, it uses the getTicket response template to translate the XML from the web service to the format expected by the Connector Framework. If the ticket data is successfully retrieved through the web service, the connector is marked as completed and is ready to use. If an error occurs, the configuration changes will be saved but the connector will not be marked as completed. Someone must investigate why it failed and address the problem. Once the problem has been addressed, they can go back to the configuration page and click Ok to have it test connectivity again.

1.2.2 Creating a Ticket

Once the connector is marked as completed, you can manually create a ticket in the external ticketing application using an existing incident or you can set up incident rules to automatically create a ticket in the external ticketing application whenever certain events occur. For example, you could set up a rule to open a ticket if any of your database tablespaces exceed a specified threshold. Whenever the rule is set up, you specify what target(s) the rule applies to, what criteria to use to trigger the rule, the ticketing connector to invoke and what template to use for that connector.

Whenever the criteria are met and the rule fires, the Connector Framework invokes the ticketing connector to create a ticket. To create the ticket:

  1. The Connector Framework uses the template specified in the incident rule to translate the Enterprise Manager incident data format into an XML request that it sends to the web service.

  2. The web service creates a ticket in the external ticketing application and sends a response with the identifier of the new ticket.

  3. The Connector Framework uses the createTicket response template to translate the new incident identifier into the format expected by the Connector Framework.

  4. When the Connector Framework gets the response, it saves the external ticket identifier in the incident TicketID field.

Note:

The same template is used for create and update requests. The template uses the TicketID field to distinguish between a create and update. If the field has data, it knows it is an updateTicket operation being performed, otherwise it knows that it is a createTicket operation.

1.2.3 Updating a Ticket

Whenever something occurs that causes the incident in Enterprise Manager to be updated, the Connector Framework uses the template specified in the incident rule to translate the Enterprise Manager incident data format into an XML update request that it sends to the web service. The web service updates the ticket in the external ticketing application and sends a response. When the Connector Framework gets the response, it uses the createTicket response template to translate the response into a format expected by the Connector Framework. The Connector Framework uses this response to verify that the update was completed successfully.

Note:

There is no updateTicket response template. Create and update responses are handled by the template that is defined for the createTicket service operation.

1.2.4 Clearing a Ticket

When the incident is resolved and it goes into a cleared status, the Connector Framework performs a normal updateTicket operation with the SeverityCode field set to CLEAR.

1.2.5 Synchronizing Ticket Status (Optional)

There is also an optional feature to synchronize ticket status changes that occur in the external ticketing application. The feature requires that the external ticketing application be configured to call emcli whenever the status changes for a ticket that originated in Enterprise Manager. The call to emcli sends the new status to Enterprise Manager, and Enterprise Manager handles the request as a publishTicket operation. To make this work, a publishTicket request template must be defined to translate the data from emcli into the format expected by Enterprise Manager.

1.3 Prerequisites

You must have a good understanding of the XML, XSD, and XSLT technologies because you will be required to generate several XML and XSLT files while building a connector. It is highly recommended that you familiarize yourself with these technologies before attempting to build a connector.

1.4 Extracting Schema Files

To create the ticketing and event connectors, you will need access to the schema files that define the format of the different files. The schema files are located in the Extensibility Development Kit (EDK). To install the EDK, go to the Setup menu, select Extensibility, then Development Kit. This page gives instructions for downloading and installing the EDK. Review the Requirements section and verify the prerequisites have been met before attempting to install the EDK. Once the prerequisites are confirmed, install the EDK as directed in the Deployment section.

The schema files are located in the emMrsXsds.jar file in the emSDK directory. To access the files, you will need to extract them using the jar command or any other utility that understands the jar file format. Use the following command to extract the files using the jar command from the EDK installation directory:

$JAVA_HOME/bin/jar xvf emSDK/emMrsXsds.jar

Table 1-2 shows the location of the extracted schema files. This table will be referenced in the different sections where the schema files are discussed.

Table 1-2 Schema File Location

File Name Location 
connectorDeploy.xsd

oracle/sysman/emSDK/core/connector/common

createTicket_response.xsd

oracle/sysman/emSDK/core/connector/ticketingConnector

EMEvent.xsd

oracle/sysman/emSDK/core/connector/eventConnector

EMIncident.xsd

oracle/sysman/emSDK/core/connector/ticketingConnector

getTicket_response.xsd

oracle/sysman/emSDK/core/connector/ticketingConnector

publishTicket.xsd

oracle/sysman/emSDK/core/connector/ticketingConnector

SelfUpdateManifest.xsd

oracle/sysman/emSDK/core/selfupdate/model

1.5 Building a Ticketing Connector

Now that you understand how a connector functions, you are now ready to start the process of building your ticketing connector. To build your connector, you will need to follow the instructions specified in the sections listed below:

1.5.1 Determining Connector Functionality

Before you can build a connector, you need to analyze your requirements and determine what functionality to include in the connector. This section assists you in determining what templates you will require for your ticketing connector. When you are done with this section, you should have a list of the templates that need to be implemented for your connector.

There are some templates that are required and must be included in every ticketing connector. You have no choice but to include these templates in your connector. There are other templates that are optional that may be included in the connector if deemed necessary. Table 1-3 lists the possible templates that can be defined for a ticketing connector. The Description column in this table explains the functionality provided by the template. You will need to analyze the functionality provided by the optional templates and determine which ones you want to include in your connector. Once you complete this analysis, you should have a list of templates that you need to provide. Your list will be comprised of the required templates plus the optional templates that you have selected for inclusion.

Table 1-3 Possible Ticketing Templates

Template Required/Optional Description

getTicket request

Required

Used to generate a request to retrieve ticket information from the web service.

getTicket response

Required

Used to translate the response from the web service to a format expected by Enterprise Manager.

Default template

Required

Used to generate a request to create/update a ticket that is sent to the web service. There must be at least one default template defined.

Additional Default templates

Optional

You can define additional templates that the operator can choose from when invoking the connector. Each default template has different functionality. For example one template may automatically close the ticket when the incident clears in Enterprise Manager. Another template will not close the ticket but update the history log.

createTicket response

Optional

Implement this template to create a ticket and update it as incident updates occur in Enterprise Manager. Without this template, the identifier of the created ticket will not be saved in the Enterprise Manager incident. This will create a new ticket every time an update occurs. Although it is not required, it is highly recommended that you implement this template.

publishTicket request

Optional

Use this template to pick up ticket status changes that occur in the external ticketing application. When a ticket status change occurs, the external ticketing application must be configured to call emcli to send the status change to Enterprise Manager. This template handles the request and transforms it to the format expected by Enterprise Manager.

You will also need to determine the file name that you want to use for each template. There are no requirements on the template file names, but Oracle recommends that you use the following naming convention:

<methodName>_request.xml
<methodName>_request.xsl
<methodName>_response.xsl

Table 1-4 lists the recommended filenames for the different templates based on the suggested naming convention.

Table 1-4 Recommended Template Filenames

Template Recommended Filename

getTicket request

getTicket_request.xml

getTicket response

getTicket_response.xsl

Default templates

Choose a file name that describes the functionality of the template

createTicket response

createTicket_response.xsl

publishTicket request

publishTicket_request.xsl

1.5.2 Developing Required Template Files

Now that you have identified the templates that you need to provide, the next step is to create the template files. It is highly recommended that you use XML/XSLT tools to generate and test the template files. You can create the files using a standard text editor but it will make the process much more difficult and time consuming. The tools catch format errors and allow you to test the templates before you package and install the connector in Enterprise Manager. This greatly reduces the number of corrections that you must make to the installed connector. Each correction that you must make to the connector requires that you uninstall the old connector, repackage and reinstall the new version of the connector.

The following subsections cover the steps required to create the different template files. You can ignore the sections that cover templates that are not targeted for your connector.

1.5.2.1 getTicket Request Template

The getTicket request template is a XML file that identifies the XML format required to retrieve the ticket information from the web service. If you have a sample of the XML required by the web service to retrieve the ticket information, you can copy that into the template file. If you do not have a sample, you will need to look at the WSDL or the schema that defines the format required by the web service. If you are not able to determine the XML format by manually looking at the files, there are tools that you can use that examine the WSDL/schema and generate a sample XML file.

There is at least one change that you need to make to the XML file to make it work as a template. In the location where the ticket identifier goes, you will need to replace whatever is specified with @TicketId@. This tells the Connector Framework to substitute the ticket identifier that is entered when the connector is configured.

Example 1-1 below is a sample of an XML file that was generated from a WSDL, and Example 1-2 shows the contents of the corresponding getTicket request template. Since the sample included the SOAP envelope information, it was stripped from the template file. The SOAP information will be added by the Connector Framework whenever the web service is called. One other thing to note is that the definition for the urn namespace was moved because it was defined in the SOAP envelope that was deleted. If the urn namespace would not have been moved, it would have been an invalid request because the namespace would have been undefined. There is not really any testing that can be done on this template other than to use a tool to verify that the XML format is valid. If you can validate it against the schema that would be even better.

Example 1-1 XML Retrieve Ticket Sample

 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                   xmlns:urn="urn:HPD_IncidentInterface_Custom_WS">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:HelpDesk_Query_Service>
         <urn:Incident_Number>?</urn:Incident_Number>
      </urn:HelpDesk_Query_Service>
   </soapenv:Body>
</soapenv:Envelope>

Example 1-2 getTicket_request.xml

<urn:HelpDesk_Query_Service xmlns:urn="urn:HPD_IncidentInterface_Custom_WS">
    <urn:Incident_Number>@TicketId@</urn:Incident_Number>
</urn:HelpDesk_Query_Service>

1.5.2.2 getTicket Response Template

The getTicket response template is an XSLT file that transforms the response from the web service into the format expected by Enterprise Manager. The format of the response XML from the web service should be defined by the WSDL or by a schema. The format expected by Enterprise Manager is specified in the getTicket_response.xsd schema file. See Table 1-2 in the Extracting Schema Files section for the location of the getTicket_response.xsd schema file.

Example 1-3 shows a sample response file from the web service. Example 1-4 shows a sample XSLT template that is designed to transform the data to the format expected by Enterprise Manager. The XSLT template looks for a root element with a name of HelpDesk_Query_ServiceResponse that has a namespace of urn:HPD_IncidentInterface_Custom_WS. It creates a getTicketResponse root element with a namespace of http://xmlns.oracle.com/sysman/connector/tt and creates a child TicketId element and sets it to the identifier specified in the Incident_Number element. If the TicketId element is not empty, Enterprise Manager knows that the ticket was successfully retrieved. Example 1-5 shows the XML that was generated by performing the translation using an XSL translation tool.

Example 1-3 Input Response XML from Web Service

<?xml version='1.0' encoding='UTF-8'?>
<urn:HelpDesk_Query_ServiceResponse xmlns:urn="urn:HPD_IncidentInterface_Custom_WS">
  <urn:Incident_Number>TKT00001</urn:Incident_Number>
</urn:HelpDesk_Query_ServiceResponse>

Example 1-4 Sample XSLT Template File

<?xml version='1.0' encoding='UTF-8'?>
<xsl:transform version="1.0"
              xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
              xmlns:urn="urn:HPD_IncidentInterface_Custom_WS"
              xmlns="http://xmlns.oracle.com/sysman/connector/tt"
              targetNamespace="http://xmlns.oracle.com/sysman/connector/tt"
              elementFormDefault="qualified">
  <xsl:template match="urn:HelpDesk_Query_ServiceResponse">
      <getTicketResponse>
        <TicketId><xsl:value-of select="urn:Incident_Number/text()"/></TicketId>
      </getTicketResponse>
  </xsl:template>
</xsl:transform>

Example 1-5 File Resulting from Transformation

<?xml version="1.0"?>
<getTicketResponse xmlns="http://xmlns.oracle.com/sysman/connector/tt"
                   xmlns:urn="urn:HPD_IncidentInterface_Custom_WS">
  <TicketId>TKT00001</TicketId>
</getTicketResponse>

Whenever you create your XSLT template, you do not have to start from the beginning. It is easier to copy an existing template and customize it to fit your situation. To customize the template shown above:

  1. Replace the urn namespace definition with the namespace that will be specified in the XML coming from your web service.

  2. Change the template match attribute to reference the root element in the XML coming from your web service.

  3. Change the name of the element where it gets the ticket identifier information when it creates the TicketId element.

  4. Once you create your file, you should run an XSLT tool to test your template by transforming data from a sample XML and verify that it generates the correct XML format.

1.5.2.3 Default Template(s)

The default templates are the most difficult to build because they are larger and more complicated than the other templates. When a ticket is manually created or an incident rule fires that invokes the ticketing connector, the Connector Framework generates an internal XML document that contains data for the affected incident. This generated XML document is used as the input XML for a translation involving the selected default template. The XML that results from the translation is the XML that will be sent to the web service to create or update a ticket in the external ticketing application.

Before you can build your template, you need to understand the format of the data being created/updated in the external ticketing application and the format of the data coming from Enterprise Manager. Understanding the format involves identifying the fields that are available and the values that can be entered in those fields.

You must familiarize yourself with the format of the data that is specified to create/update a ticket in the external ticketing system. A good place to start is the WSDL or a schema file that defines the format of the data. You will also need to see sample create/update requests to see how the data is formatted. If samples are not available, you should be able to manually retrieve data for an existing ticket using a XML client tool. This should give you a good idea of what the data looks like.

Once you understand the data in the external ticketing application, you then need to study and understand the data coming from Enterprise Manager. The fields that are available in the Enterprise Manager incident/event data are identified in two schema files. The EMIncident.xsd file defines the format of the incident data and the EMEvent.xsd file defines the format of the event data that triggered the incident. See Table 1-2 in the Extracting Schema Files section for the location of the EMIncident.xsd and EMEvent.xsd schema files. The schema files identify the fields and tell the type of data in those fields but do not give a good indication of what data is actually present. To get a good idea of what the data looks like, you need a sample XML file that was generated by Enterprise Manager. Appendix F, "Sample Incident Data," shows sample transactions that were generated by Enterprise Manager.

Once you are familiar with the data on both ends, you need to determine how many templates you need and the mapping that will be performed by each. This involves determining what fields you will specify in create/update requests and the format of the data for those fields. You only have two choices on the source of the data. You can hard code the data or get it from the Enterprise Manager incident/event data. You can make the mapping as sophisticated or simple as you like. Ultimately, you will need to determine what fields and settings make sense for your environment.

Once you have identified the templates and the mapping of each, you are now ready to build the XSLT file(s). To start the first template, copy the XML shown in Example 1-6 into your editor where you are building the XSLT file. This contains the basic skeleton that you will need to build your template. The skeleton has a section for create requests and another section for update requests. You will need to add your mapping logic in the appropriate sections. If multiple templates are being built, the recommended approach is to build the simplest template first and to test it thoroughly. Once you have verified that it works, you can make a copy of the template and use that as a baseline for the other templates.

Appendix D, "Default Template Example," walks through an example that shows how to build a default template.

Example 1-6 Template Skeleton

<?xml version='1.0' encoding='UTF-8'?>
<xsl:stylesheet version="1.0" 
              xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
              xmlns:emcf="http://xmlns.oracle.com/sysman/connector">
 
  <xsl:template match="emcf:EMIncident">
    <xsl:choose>
      <xsl:when test="normalize-space(emcf:TicketID) = ''">
        <!-- CREATE Request -->
        <!-- Replace this comment with the mapping logic for create requests -->
      </xsl:when>
      <xsl:otherwise>
        <!-- UPDATE Request -->
        <!-- Replace this comment with the mapping logic for update requests -->
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
</xsl:stylesheet>

1.5.2.4 createTicket Response Template

The createTicket response template is an XSLT file that transforms the response from the web service into the format expected by Enterprise Manager. Although the template name implies it is only for create responses, it is also used to handle update responses. The format of the response XML from the web service should be defined by the WSDL or by a schema. The format expected by Enterprise Manager is specified in the createTicket_response.xsd schema file. See Table 1-2 in the Extracting Schema Files section for the location of the createTicket_response.xsd schema file.

Example 1-7 shows a sample response file from the web service. Example 1-8 shows a sample XSLT template that is designed to transform the data to the format expected by Enterprise Manager. The XSLT template looks for a root element with a name of HelpDesk_Submit_ServiceResponse that has a namespace of urn:HPD_IncidentInterface_Create_WS. It creates a CreateTicketResponse root element with a namespace of http://xmlns.oracle.com/sysman/connector and creates a child TicketId element and sets it to the identifier specified in the Incident_Number element. It also populates the Incident_Number variable with the identifier specified in the Incident_Number element. If the TicketId element is not empty, Enterprise Manager knows that the ticket was successfully created. Example 1-9 shows the XML that was generated by performing the translation using an XSLT tool.

Example 1-7 Input Response XML from Web Service

<?xml version='1.0' encoding='UTF-8'?>
<urn:HelpDesk_Submit_ServiceResponse xmlns:urn="urn:HPD_IncidentInterface_Create_WS">
  <urn:Incident_Number>TKT00001</urn:Incident_Number>
</urn:HelpDesk_Submit_ServiceResponse>

Example 1-8 Sample XSLT Template File

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
              xmlns:urn="urn:HPD_IncidentInterface_Create_WS"
              xmlns="http://xmlns.oracle.com/sysman/connector">
 <xsl:template match="urn:HelpDesk_Submit_ServiceResponse">
   <CreateTicketResponse>
     <TicketId>
       <xsl:value-of select="urn:Incident_Number"/>
     </TicketId>
     <InstanceVariable>
       <VariableName>Incident_Number</VariableName>
       <VariableValue>
         <xsl:value-of select="urn:Incident_Number"/>
       </VariableValue>
     </InstanceVariable>
   </CreateTicketResponse>
 </xsl:template>
</xsl:transform>

Example 1-9 File Resulting from Transformation

<?xml version="1.0" encoding="UTF-8"?>
<CreateTicketResponse xmlns="http://xmlns.oracle.com/sysman/connector" xmlns:urn="urn:HPD_IncidentInterface_Create_WS">
   <TicketId>TKT00001</TicketId>
   <InstanceVariable>
      <VariableName>Incident_Number</VariableName>
      <VariableValue>TKT00001</VariableValue>
   </InstanceVariable>
</CreateTicketResponse>

Whenever you create your XSLT template, it is easier to copy an existing template and customize it to fit your situation. To customize the template shown above:

  1. Replace the urn namespace definition with the namespace that will be specified in the XML coming from your web service.

  2. Change the template match attribute to reference the root element in the XML coming from your web service.

  3. Change the name of the element where it gets the ticket identifier information when it creates the TicketId element.

  4. Once you create your file, you should run an XSLT tool to test your template by transforming data from a sample XML and verify that it generates the correct XML format.

1.5.2.5 publishTicket Request Template

The publishTicket request template is an XSLT file that transforms status change information sent by emcli into the format expected by Enterprise Manager. The format expected by Enterprise Manager is specified in the publishTicket.xsd schema file. See Table 1-2 in the Extracting Schema Files section for the location of the publishTicket.xsd schema file.

Since the source (emcli) and the destination (Enterprise Manager) XML formats will be the same for all connectors, the template defined will require little or no changes from one connector to another. The only part that may require changes is the status field. Some applications have two status values defined for each possible status. One is used internally, and the other is the value that is displayed at the console. For example, an application may have numeric internal status values that are displayed as strings at the console. If values that emcli passes for status are the display strings, you can pass the status straight through to Enterprise Manager without modification. If the values are passed as internal values, you will need to translate the numeric value to the corresponding string value.

As an example, assume there is an external application that tracks status internally using a numeric value to represent the status. Also assume that at the console, the status is displayed as a text string and that the internal status of 2 is displayed as "In Progress" at the console. If emcli passes the internal status value of 2, the template will need to translate the 2 to a value of "In Progress" and set the status field to "In Progress". If emcli passes the display status of "In Progress", the value can be passed through without any modifications. Example 1-10 contains a template that passes the status through without modifications, and Example 1-11 contains a template that translates the status. You will want to copy the template that applies to your situation. If no translation is required, the template in Example 1-10 can be copied and used without any modifications. If translation is required, the template in Example 1-11 can be copied and the status translation mapping will need to be modified to use the values defined in your application.

Example 1-10 Publish Template that Passes Unmodified Status

<?xml version='1.0' encoding='UTF-8'?>
<xsl:transform version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:a="http://xmlns.oracle.com/sysman/connector"
  targetNamespace="http://xmlns.oracle.com/sysman/connector"
  elementFormDefault="qualified">
 
  <xsl:template match="a:InboundData">
    <InboundData>
      <Operation><xsl:value-of select="a:Operation"/></Operation>
      <PropertyList>
        <ticket_guid><xsl:value-of select="a:PropertyList/a:ticket_guid"/></ticket_guid>
        <status><xsl:value-of select="a:PropertyList/a:status/text()"/></status>
        <connector_guid><xsl:value-of select="a:PropertyList/a:connector_guid"/></connector_guid>
        <last_updated_date><xsl:value-of select="a:PropertyList/a:last_updated_date"/></last_updated_date>
      </PropertyList>
    </InboundData>
  </xsl:template>
 
</xsl:transform>

Example 1-11 Publish Template that Passes Translated Status

<?xml version='1.0' encoding='UTF-8'?>
<xsl:transform version="1.0"
              xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
              xmlns:a="http://xmlns.oracle.com/sysman/connector"
              targetNamespace="http://xmlns.oracle.com/sysman/connector"
              elementFormDefault="qualified">
  <xsl:template match="a:InboundData">
    <InboundData>
      <Operation><xsl:value-of select="a:Operation"/></Operation>
      <PropertyList>
          <ticket_guid><xsl:value-of select="a:PropertyList/a:ticket_guid"/></ticket_guid>
          <status>
          <xsl:choose>
            <xsl:when test="(a:PropertyList/a:status/text() = '0')">New</xsl:when>
            <xsl:when test="(a:PropertyList/a:status/text() = '1')">Assigned</xsl:when>
            <xsl:when test="(a:PropertyList/a:status/text() = '2')">In Progress</xsl:when>
            <xsl:when test="(a:PropertyList/a:status/text() = '3')">Pending</xsl:when>
            <xsl:when test="(a:PropertyList/a:status/text() = '4')">Resolved</xsl:when>
            <xsl:when test="(a:PropertyList/a:status/text() = '5')">Closed</xsl:when>
            <xsl:when test="(a:PropertyList/a:status/text() = '6')">Cancelled</xsl:when>
          </xsl:choose>  
          </status>
          <connector_guid><xsl:value-of select="a:PropertyList/a:connector_guid"/></connector_guid>
          <last_updated_date><xsl:value-of select="a:PropertyList/a:last_updated_date"/></last_updated_date>
      </PropertyList>
    </InboundData>
  </xsl:template>
</xsl:transform>

1.5.3 Defining the Connector Descriptor File

Now that you have the templates created, it is time to create a connector descriptor file that defines the connector in Enterprise Manager. The connector descriptor XML file describes the connector metadata and the configuration properties of the connector, such as web service end points and authentication schema.

The key points to remember when constructing a descriptor are

  • The connector descriptor file name must be connectorDeploy.xml

  • The XML file should adhere to the connectorDeploy.xsd schema file.

See Table 1-2 in the Extracting Schema Files section for a summary for the location of schema files.

Refer to the sample connectorDeploy.xml in Appendix A, "Ticketing Connector Samples" for reference implementation.

Table 1-5 lists the sections that comprise a connector descriptor and provides a summary of what each section does:

Table 1-5 Metadata Sections

Metadata Section Required Explanation

Connector Information

Yes

This section provides information about the connector that will be displayed at the UI.

Authentication

No

Specifies the authentication method and the parameters that are required to connect to the web service.

Connectivity Test Variable

Yes

The variable defined in this section is used during the initial configuration step to validate connectivity.

External URL

No

This section enables you to configure the connector to provide a link to directly view the ticket contents in the external system.

Service

Yes

This section configures the URLs used to connect to the web service for the different service operations.

Template Registration

Yes

This section defines all of the templates that are used for the connector.

The following sections provide detailed information about the contents of the connector descriptor:

1.5.3.1 Connector Deploy Field Information

Each section of the connector deployment file contains fields that provide specific information about the connector. The following sections contain detailed information about what fields are available and what data goes in those fields.

1.5.3.2 Connector Information Section

The Connector Information section provides information about the connector such as name, version, description, and so on, that will be displayed at the UI. Table 1-6 lists the fields in this section and provides an explanation of each field.

Table 1-6 Connector Information Fields

Section/Field Required Description

Name

Yes

The connector name that will be displayed at the UI.

Version

Yes

The connector version that will be displayed at the UI.

EMCompatibleVersion

Yes

The earliest version of Enterprise Manager that is supported.

Description

Yes

The connector description that will be displayed at the UI.

Category

Yes

Possible values are:

EventConnector
TicketingConnector

In this case, the value will be TicketingConnector.

1.5.3.3 Sample Connector Information Section

Example 1-12 shows a sample of the information that is included in the Connector Information section. All of the fields in this section are contained in the ManagementConnector node.

Example 1-12 Connector Information Section Sample

<Name>Remedy Service Desk 7.6 Connector</Name>
<Version>12.1.0.2.0</Version>
<EMCompatibleVersion>12.1.0.1.0</EMCompatibleVersion>
<Description>Remedy Service Desk 7.6.04 Integration with Enterprise Manager</Description>
<Category>TicketingConnector</Category>

1.5.3.4 Authentication Section

The authentication section specifies the authentication method and the credentials that are required to connect to the web service. There are three possible authentication types that can be configured. If no authentication section is specified, no authentication will be performed when the connector connects to the web service. Table 1-7 lists the three possible authentication sections and the fields contained in each.

Table 1-7 Authentication Fields

Section/Field Required Description

SOAPHeaderAuthentication

No

Specifies the credentials used to connect to the web service using SOAP header authentication.
 

*Username

Yes

The username to specify in the SOAP header

*Password

Yes

The password to specify in the SOAP header

*AuthVariable

No

Up to 20 other variables to pass in the SOAP header

*SOAPHeader

Yes

A string that serves as template for the SOAP header. It will be updated by substituting the user inputs for variables defined above in the designated location and bound with a HTTP request.

HTTPBasicAuthentication

No

Specifies the credentials used to connect to the web service using basic authentication
 

*Username

Yes

The username to specify when calling the web service

*Password

Yes

The password to specify when calling the web service

UserNameTokenAuthentication

No

Specifies the credentials used to connect to the web service using Username Token Profile authentication
 

*Username

Yes

The username to specify

*Password

Yes

The password to specify

* Fields marked with an asterisk are comprised of the following subfields:

  • VariableName: Name of the variable being defined

  • DisplayName: Name to use when displaying information about this field at the UI

  • "required" attribute: Specifies whether the field is required (defaults to false if not specified)

1.5.3.5 Sample Authentication Section

Example 1-13 shows the information that is included in the Authentication section. In this example, the authentication method is a SOAP header. The operator would be required to provide Remedy Username, Remedy Password, Authentication, Locale, and Timezone values when configuring the connector. The values entered by the operator would be used to populate the XML in the SOAPHeader section, and this would be passed in the SOAP header for any requests that are sent to the web service.

Example 1-13 Authentication Section Sample

<SOAPHeaderAuthentication>
     <Username required="true">
          <VariableName>USERNAME</VariableName>
          <DisplayName>Remedy Username</DisplayName>
     </Username>
     <Password>
         <VariableName>PASSWORD</VariableName>
          <DisplayName>Remedy Password</DisplayName>
     </Password>
     <AuthVariable>
          <VariableName>AUTHENTICATION</VariableName>
          <DisplayName>Authentication</DisplayName>
     </AuthVariable>
     <AuthVariable>
          <VariableName>LOCALE</VariableName>
          <DisplayName>Locale</DisplayName>
     </AuthVariable>
     <AuthVariable>
          <VariableName>TIMEZONE</VariableName>
          <DisplayName>Timezone</DisplayName>
     </AuthVariable>
     <SOAPHeader>
          <![CDATA[
          <urn:AuthenticationInfo xmlns:urn="urn:HelpDesk_Submit_Service">
          <urn:userName>$USERNAME$</urn:userName>
          <urn:password>$PASSWORD$</urn:password>
          <urn:authentication>$AUTHENTICATION$</urn:authentication>
          <urn:locale>$LOCALE$</urn:locale>
          <urn:timeZone>$TIMEZONE$</urn:timeZone>
          </urn:AuthenticationInfo>
          ]]>
     </SOAPHeader>
</SOAPHeaderAuthentication>

1.5.3.6 Connectivity Test Variable Section

This section defines the variable used by the getTicket service operation during the initial configuration step to validate connectivity with the web service. Table 1-8 lists the fields in the section and provides an explanation of each field.

Table 1-8 Connectivity Test Variable Fields

Section/Field Required Description

ConnectivityTestVariable

Yes

Defines the variable that is used in testing connectivity to the external system. When the connector is configured, the operator specifies the identifier of an incident in the external system.

This variable will be set to the value specified by the operator and used to generate a request to retrieve the incident through the getTicket operation.
 

VariableName

Yes

Name of the variable being defined.

Should be set to "TICKET_ID"

DisplayName

Yes

Name to use when displaying information about the variable at the UI.

Should be set to "Ticket ID"

1.5.3.7 Sample Connectivity Test Variable Section

Example 1-14 shows the information that is included in the Connectivity Test Variable section. You should be able to use this section without any modifications.

Example 1-14 Connectivity Test Variable Section Sample

<ConnectivityTestVariable>
     <VariableName>TICKET_ID</VariableName>
     <DisplayName>Ticket ID</DisplayName>
</ConnectivityTestVariable>

1.5.3.8 External URL Section

This section enables you to configure the connector to provide a link to directly view the ticket contents in the external system. The ticketing application must provide a link to directly access the ticket information. Table 1-9 lists the fields in the section and provides an explanation of each field.

Table 1-9 External URL Fields

Section/Field Required Description

ExternalURL

No

URL that accesses the ticket in the external system.
 

Pattern

Yes

Pattern used to determine the external URL

The value of the <Pattern> tag describes the URL string, and how user-configured variables are inserted into it.

ConfigVariable

No

Variables that must be specified by the operator when the connector is configured.

The values that the user provides for each user variable is inserted into the URL pattern string accordingly. If there is a user variable "X" then the user input value replaces "$X$" when the ticket URL is generated.

There can be up to 50 variables specified.

VariableName

Yes

Name of the variable being defined.

DisplayName

Yes

Name to use when displaying information about this field at the UI.

required attribute

No

Specifies whether the field is required - defaults to false if not specified.

1.5.3.9 Sample External URL Section

Example 1-15 shows the information that is included in the External URL section. The variables defined in the ConfigVariable section will be displayed as input fields on the configuration page, and the operator will enter values in the fields. The values that they enter will be plugged into the URL where the variable name is listed (surrounded by $) in the Pattern field. Also the @Incident_Number@ will be replaced by the contents of the Incident_Number variable that was created by the createTicket response template shown in Example 1-9.

Example 1-15 External URL Section Sample

<ExternalURL>
     <Pattern>
          <![CDATA[http://$WEB_SERVER$/arsys/forms/$ARSERVER_NAME$/$FORM_NAME$/?qual=%27Incident%20Number*%27=%22@Incident_Number@%22]]>
     </Pattern>
     <ConfigVariable required="true">
          <VariableName>WEB_SERVER</VariableName>
          <DisplayName>Web Server</DisplayName>
     </ConfigVariable>
     <ConfigVariable required="true">
          <VariableName>FORM_NAME</VariableName>
          <DisplayName>HelpDesk Case Form Name</DisplayName>
     </ConfigVariable>
     <ConfigVariable required="true">
          <VariableName>ARSERVER_NAME</VariableName>
          <DisplayName>ARServer Name</DisplayName>
     </ConfigVariable>
</ExternalURL>

1.5.3.10 Service Section

Use this section to configure the URLs that connect to the web service for the different service operations. There must be a separate Service section entry for each of the following operations:

  • createTicket

    Create ticket on the external system.

  • updateTicket

    Forward incident updates to the external system.

  • getTicket

    Service method to validate the ticket connector connectivity with Enterprise Manager.

Note:

The service names in the connector descriptor should exactly match the names defined above and are case sensitive.

Table 1-10 lists the fields in the section and provides an explanation of each field.

Table 1-10 Service Fields

Section/Field Required Description

Service

Yes

This section enables you to specify configurations specific to the Ticketing System's Web services.
 

Method

Yes

Method defines one of the Enterprise Manager-specific service operation names.

For ticketing connectors, it must be set to one of the following values:

getTicket
createTicket
updateTicket
 

WebServiceEndpoint

Yes

This field specifies the default Web service endpoint string to be displayed in the Web service section of the Management Connector page.
 

SOAPAction

No

The SOAPAction to specify when calling the web service
 

SOAPBindingType

No

Possible values are:

SOAP11HTTP_BINDING
SOAP12HTTP_BINDING
SOAP11HTTP_MTOM_BINDING
SOAP12HTTP_MTOM_BINDING

1.5.3.11 Sample Service Section

Example 1-16 shows all three required Service sections. The URLs in the WebServiceEndpoint element are placed in a CDATA section to avoid conflicts with reserved XML characters. The values surrounded by square brackets [] need to be replaced by the operator on the configuration page. For example, the default URL for the createTicket operation is

http://[midtier_server]/arsys/services/ARService?server=[servername]&webService=HPD_IncidentInterface_Create_WS

This value will be displayed in the Web Service End Points section of the configuration page next to the createTicket operation. The operator will need to replace [midtier_server] with the actual midtier server IP address or host name. They would also need to replace [servername] with the server IP address or host name.

Example 1-16 Service Section Sample

<Service>
     <Method>createTicket</Method>
     <WebServiceEndpoint>
          <![CDATA[http://[midtier_server]/arsys/services/ARService?server=[servername]&webService=HPD_IncidentInterface_Create_WS]]>
     </WebServiceEndpoint>
</Service>
<Service>
     <Method>updateTicket</Method>
     <WebServiceEndpoint>
          <![CDATA[http://[midtier_server]/arsys/services/ARService?server=[servername]&webService=HPD_IncidentInterface_Custom_WS]]>
     </WebServiceEndpoint>
</Service>
<Service>
     <Method>getTicket</Method>
     <WebServiceEndpoint>
          <![CDATA[http://[midtier_server]/arsys/services/ARService?server=[servername]&webService=HPD_IncidentInterface_Custom_WS]]>
     </WebServiceEndpoint>
</Service>

1.5.3.12 Template Registration Section

This section defines all of the templates that were built in the previous chapter. Table 1-11 lists the fields in the section and provides an explanation of each field.

Table 1-11 Template Registration Fields

Section/Field Required Description

TemplateRegistration

Yes

This section defines up to 50 connector templates.

Each template that you created in Developing Required Template Files must be defined here.
 

FileName

Yes

Name of the file that defines the template
 

InternalName

Yes

Internal template name.

For templates associated with a service method, it must be set to one of the following service method names. It is case sensitive; so, it must match the service method name.

getTicket
createTicket
publishTicket

For default templates, this field can be set to any unique name that conforms to the following restrictions.

  • Must not contain any restricted characters. Only the following characters are allowed:

    - Upper case alphabetic characters (A-Z)

    - Lower case alphabetic characters (a-z)

    - Numeric characters (0-9)

    - Underscore character (_)

  • Must not be set to the following service method names:

    createTicket
publishTicket
getTicket
 

TemplateName

Yes

Name to use in the UI when referencing this template
 

TemplateType

Yes

There are two types of templates. One is Outbound and the other is Inbound. Outbound generates XML that is being sent to the external web service, and Inbound transforms incoming XML to the format expected by Enterprise Manager.

Outbound will always be associated with the request portion of an operation.

Inbound can be associated with a response or request portion of an operation.

For requests that originate in Enterprise Manager, the inbound template will be used to handle the response to the request.

For requests that originate outside of Enterprise Manager, the inbound template will be registered as a request. The only inbound template that will be registered as a request is the publishTicket operation.

Possible values for the template type are:

InboundXSL
OutboundXSL
OutboundXML
 

Description

Yes

Description of the template that will be displayed at the UI

1.5.3.13 Sample Template Registration Section

Example 1-17 shows the different TemplateRegistration sections.

Example 1-17 Template Registration Section Sample

<TemplateRegistration>
     <FileName>getTicket_request.xml</FileName>
     <InternalName>getTicket</InternalName>
     <TemplateName>Get Ticket</TemplateName>
     <TemplateType>OutboundXML</TemplateType>
     <Description>This is the getTicket request template.</Description>
</TemplateRegistration>
<TemplateRegistration>
     <FileName>getTicket_response.xsl</FileName>
     <InternalName>getTicket</InternalName>
     <TemplateName>Get Ticket</TemplateName>
     <TemplateType>InboundXSL</TemplateType>
     <Description>This is the getTicket response template.</Description>
</TemplateRegistration> 
<TemplateRegistration>
     <FileName>createTicket_response.xsl</FileName>
     <InternalName>createTicket</InternalName>
     <TemplateName>Create Ticket Response</TemplateName>
     <TemplateType>InboundXSL</TemplateType>
     <Description>This is the create ticket response template. </Description>
</TemplateRegistration>
<TemplateRegistration>
     <FileName>templates/Remedy_DefaultCategory_AutoClose.xsl</FileName>
     <InternalName>Remedy_DefaultCategory_AutoClose.xsl</InternalName>
     <TemplateName>Remedy Default Category Auto Close</TemplateName>
     <TemplateType>OutboundXSL</TemplateType>
     <Description>This is the Remedy default template with auto close function. </Description>
</TemplateRegistration>
<TemplateRegistration>
     <FileName>publishTicket_request.xsl</FileName>
     <InternalName>publishTicket</InternalName>
     <TemplateName>Publish Ticket Status</TemplateName>
     <TemplateType>InboundXSL</TemplateType>
     <Description>This is the publishTicket request template. </Description>
</TemplateRegistration>

1.5.3.14 Complete Connector Deployment File

Example A-1 in Appendix A shows the complete connector deployment file that includes the samples shown in the preceding sections. Figure 1-1shows an example of the connector configuration page that is displayed for the sample connector shown in Appendix A. The image has been labeled to show where the fields were defined in the deployment file.

Figure 1-1 Complete Connector Deployment Page

Surrounding text describes Figure 1-1 .

1.6 Packaging and Deploying the Ticketing Connector

Enterprise Manager uses the Self Update feature to deploy the connector. This feature, which can be accessed through the console, provides the ability to import the connector into the Enterprise Manager environment.

To deploy the connector:

  1. Prepare the connector jar file.

    Package all XML and XSLT template files as a .jar file

    <name>_connector.jar
---> connectorDeploy.xml
--->template1.xml
--->template2.xsl
…..
…..
--->templateN.xsl

  2. Prepare the manifest file.

    The SelfUpdateManifest.xsd schema file defines the format of the manifest file.

    See Table 1-2 in the Extracting Schema Files section for the location of the SelfUpdateManifest.xsd schema file.

    Key attributes of the self update manifest files are:

    • EntityType

      Value is core_connector

    • EntityTypeVersion

      Current release version. Value=12.1.0.1.0

    • Version

      Version number of the connector. This value must be set to the value specified in the ManagementConnector/Version node in the connectorDeploy.xml file.

    • Attribute @Name=connector_type

      Connector type name. This value must be set to the value specified in the ManagementConnector/Name node in the connectorDeploy.xml file.

    • Attribute @Name=connector_category

      Category type can be TicketingConnector or EventConnector

    • ArchiveList

      This element contains the list of archives that are part of the connector setup. Generally there will be a single connector jar, but for some special implementations there may be additional jars (adapter or agent). In these cases, the connector specific jar should be the first one in the defined list. This is a mandatory requirement.

    Example 1-18 shows the code for the connector_manifest.xml file.

    Example 1-18 Manifest File Sample

    <?xml version="1.0" encoding="UTF-8" ?>
<EntityInstance xmlns="http://www.oracle.com/EnterpriseGridControl/SelfUpdateManifest/"
    EntityTypeVersion="12.1.0.1.0"
    EntityType="core_connector"
    Maturity="PRODUCTION"
    Vendor="Oracle"
    PluginID="oracle.sysman.core"
>
<Description><![CDATA[BMC Remedy 7.6.04 Service Desk Connector - 12.1.0.2.0]]></Description>
<AttributeList>
    <Version>12.1.0.2.0</Version>
    <Attribute Name="connector_type" Value="Remedy Service Desk 7.6 Connector" Label="Remedy Service Desk 7.6 Connector" />
    <Attribute Name="connector_category" Value="TicketingConnector" Label="Ticketing Connector" />
</AttributeList>
<Readme><![CDATA[
  Oracle Management Connector for Remedy Service Desk integrates Oracle Enterprise Manager Cloud Control's proactive alert detection and resolution features with BMC's Remedy 7.6.04 Service Desk capabilities to provide a seamless workflow for incident management and resolution. 
 Remedy Service Desk 7.6 Connector works with BMC Remedy ITSM 7.6.04 Incident Management Application.
 
  Change Logs:
 
  12.1.0.2.0
   - Initial Release
  
  ]]></Readme>
<DependsOn>
</DependsOn>
<ArchiveList>
    <Archive Filename="remedy_service_desk_connector_7_6.jar" Size="11406" ChecksumType="SHA1" ChecksumValue="e168c00d1f2bac7868034cb4ecacd100afae4651" IsMDS="false" />
    <Archive Filename="HPD_IncidentInterface_Custom_WS.xml" Size="215299" ChecksumType="SHA1" ChecksumValue="ba20a8aa526e566da3c456630a866980342c874e" IsMDS="false" />
</ArchiveList>
<CustomData><![CDATA[]]></CustomData>
</EntityInstance>

  3. Configure emedk tool

    The emedk tool can be configured by following instructions from Enterprise Manager. From the Setup menu, select Extensibility, then Development Kit.

  4. Prepare the self-update archive

    This requires the connector jar file and the manifest file for the connector. To prepare self-update, call the following utility to create a self update archive file:

    edkutil prepare_update
        -manifest "manifest xml"
        -archivedir "archives directory"
        -out "output file or directory"
        [-typexml "update type xml"]

    Table 1-12 describes the options available with the utility.

    Table 1-12 Self Update Utility Options

    Option Description

    -manifest

    Self update manifest file that describes the update.

    -archivedir

    Directory containing the archive files specified in the manifest file.

    -out

    Directory or file name for the self update archive. If a directory is specified, the file name is autogenerated.

    -typexml

    Optional path to the update type xml

    The following example creates a self update archive in the /u01/sar directory based on the manifest file /u01/connector/connector_manifest.xml. The archives referred to in connector_manifest.xml are picked from the directory /u01/connector/archives.

      edkutil prepare_update
          -manifest /u01/connector/connector1_manifest.xml
          -archivedir /u01/connector/archives
          -out  /u01/sar/sample_connector.zip

  5. Import the connector archive to Enterprise Manager by calling any one of the following emcli commands:

    emcli import_update -file=\ file\ -omslocal  

    emcli import_update  
-file=\ file\         
-host=\ host name\
[-credential_set_name=\ setname\ ] | -credential_name=\ name\  -credential_owner=\ owner\

    These commands import a Self Update archive file into Enterprise Manager. On successful import, the update is displayed on the Self Update Home in downloaded status for further action.

    Table 1-13 describes the options available with this command:

    Table 1-13 Connector Archive Command Options

    Options Description

    -file

    The complete path name of the update archive file

    -omslocal

    The flag specifying that the file is accessible from the OMS

    -host

    The target name for a host target where the file is available

    -credential_set_name

    The set name of the preferred credential stored in the repository for the host target. Can be one of the following:

    • HostCredsNormal

      Default unprivileged credential set

    • HostCredsPriv

      Privileged credential set

    -credential_name

    The name of a named credential stored in the repository. This option must be specified along with -credential_owner option.

    -credential_owner

    The owner of a named credential stored in the repository. This option must be specified along with -credential_name option.

    The following paragraphs provide some examples of the use of the emcli command:

    Example 1

    Imports the file sample_connector.zip. The file must be present on the OMS host. In a multiple OMS setup, the request can be processed by any OMS, so the file should be accessible from the OMS processing the request. This usually means that the file must be kept on a shared location that is accessible from all OMS.

    emcli import_update        
  -file=\ /u01/sar/sample_connector.zip         
  -omslocal

    Example 2

    Imports the file sample_connector.zip.zip that is present on the host1.example.com host. The host must be a managed host target in Enterprise Manager and the agent on this host must be up and running. The preferred unprivileged credentials for host host1.example.com are used to retrieve the remote file.

    emcli import_update        
  -file=\ /u01/sar/sample_connector.zip                
  -host=\ host1.example.com\         
  -credential_set_name=\ HostCredsNormal\

    Example 3

    Imports the file sample_connector.zip that is present on the host1.example.com host. The host must be a managed host target in Enterprise Manager and the agent on this host must be up and running. The named credentials \host1_creds\ owned by user \admin1\ are used to retrieve the remote file.

    emcli import_update
  -file=\ /u01/sar/sample_connector.zip\
  -host=\ host1.example.com\
  -credential_name=\ host1_creds\
  -credential_owner=\ admin1\

  6. Apply the connector using one of the following methods:

    • From the Cloud Control console:

      1. Go to Self-Update Home page. The connector will be shown as downloaded.

      2. Select the connector row and click Apply to deploy the connector.

    • From the command line:

      1. Run the following emcli list command to determine the identifier of the connector that was just imported:

        emcli list -resource=Updates -bind="et_name = 'core_connector'"

        The output of the command would look like this example:

        Status    Category          Type                Version      Id
-------   ----------   ------------------  ----------   --------------
Applied   Ticketing    Remedy Service      12.1.0.1.0   123456789ABCDE
          Connector    Desk Connector
Applied   Event        HP OMU Connector    12.1.0.3.0   11223344AABBCC
          Connector
Applied   Ticketing    Remedy Service      12.1.0.3.0   1A2B3C4D5E6F7G
          Connector    Desk 7.6 Connector
Applied   Ticketing    CASD Connector      12.1.0.3.0   55443322CCBBAA
          Connector

        Note the ID for the connector that was just imported.

      2. Run the following emcli apply_updates command using the connector ID from the previous step:

        emcli apply_updates -id=<ID>