Bugzilla Connector: Empower Your Service Center.

Shawn Beasley29. Jan 2019 | ConsultingUse cases

Software Support and Bugzilla

Software has bugs!

This is nothing new. Your service department has to deal with this on a daily basis. When your software development team uses a bug tracking tool, it’s could very likely be Bugzilla. When tracking and reporting to product management about reliability and usability, it’s good to be on the same page.

Your service desk uses OTRS, because timely and transparent communication is a vital part of customer satisfaction, when bugs occur. Some questions come to mind:

• How does your support team categorize the incident when creating the record?
• How can we use the captured data to make the software better?
• How to ensure that the data we provide is translatable, by our product manager, into something of value for development?

OTRS has a solution: Dynamic Field Web Service

As an OTRS customer, you have access to the one tool you need to connect all you services to your service center. The generic interface allows you to easily design an API which can consume valuable information from most any SOAP or REST source via an HTTP request. In this use case, let’s look at getting the PRODUCT an COMPONENT information from Bugzilla. Using this information, we can easily categorize incoming incidents for the product wich are developed and supported by our service center.

This will allow the service desk manager to report upon incidents based on the same categories and products which are in the Bugzilla tracking tool. The product manager is then empowered to better focus his development efforts on the areas which are the most painful for the customer. When new products and categories arrive, they will automatically be available for use by the service team.

Requirements:

OTRS:
This can be managed or OnPremise.

Bugzilla:
Bugzilla must be setup with Products and Components. We will use the public interface as documented in the chapter 6. WebService API Reference of the Bugzilla Manual.

OTRS Feature Add-ons:

• OTRSDynamicFieldWebservice

Setup:

Web service:

One web service and two invokers are needed. One will call the product, and the second will use the input from the product to call the category.

Dynamic fields:

Two dynamic fields of type web services are required. One will store the product, and the other the category.

Configuration

Using the newly introduced web service operation Generic::PassThrough, it is now possible to configure a web service to pass it’s request data on to another function in OTRS. Currently this is used only for the dynamic fields of type web service.

Step 1 Configure the Web Service

You need to create a web service and add a network transport HTTP::REST under OTRS as requester.

Click save to continue.

Then add the invokers GetComponent and GetProduct Invokers using the Generic::PassThrough controller.

Go back and set the controller mappings in the network transport.

Notice that the controller mapping for GetComponent uses a variable :name. This is important later for the mapping.

Step 2 Configure the Mapping

We have to map the outgoing request, because we should not pass ticket data to the provider. We will only pass API specific parameters. The incoming requests must be mapped to the correct format for displaying in the drop down.

XLST Outbound Mapping (GetProduct)

This removes all ticket data and sends the parameter accessible which limits the return to only selectable products.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
        <RootElement>
            <type>
                accessible
            </type>
        </RootElement>
    </xsl:template>
</xsl:stylesheet>

XLST Inbound Mapping (GetProduct)

You do not need to specify the name of the dynamic field here, only it’s key and value. is_active limits to non-retired items. Notice we add the name of the product as the key and the value.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="RootElement">
        <RootElement>
            <xsl:for-each select="products[is_active = '1']">
                <PossibleValue>
                    <Key>
                        <xsl:value-of select="name"/>
                    </Key>
                    <Value>
                        <xsl:value-of select="name"/>
                    </Value>
                </PossibleValue>
            </xsl:for-each>
        </RootElement>
    </xsl:template>
</xsl:stylesheet>

XLST Outbound Mapping (GetComponent)

Note we use the value of the FORM DATA to select the component. This means we must always use these two dynamic fields together in one screen of OTRS. The product field should always have a higher order and be selected first.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:date="http://exslt.org/dates-and-times"
    extension-element-prefixes="date">
    <xsl:output method="xml" encoding="utf-8" indent="yes"/>
    <xsl:template match="RootElement">
    <xsl:copy>
            <name>
                <xsl:value-of select="//Form/DynamicField/WebServiceBugsillaProduct"/>
            </name>
    </xsl:copy>
   </xsl:template>
</xsl:stylesheet>

XLST Inbound Mapping (GetComponent)

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:date="http://exslt.org/dates-and-times"
                extension-element-prefixes="date">
    <xsl:output method="xml" encoding="utf-8" indent="yes"/>
    <xsl:template match="RootElement">
        <xsl:copy>
            <xsl:for-each select="//products/components/name">
                <PossibleValue>
                    <Key>
                        <xsl:value-of select="."/>
                    </Key>
                    <Value>
                        <xsl:value-of select="."/>
                    </Value>
                </PossibleValue>
            </xsl:for-each>
        </xsl:copy>
    </xsl:template>
</xsl:stylesheet>

Step 3 Setup Dynamic Fields

We need two fields as described above. See an example of the configuration below. The key difference is the Invoker chosen. Note that the Field order should always be a lower number for the product field as for the category field. This makes sure that the product field is displayed first and components will trigger correctly

Create a field for the products and one for components.
Ensure to select the correct invoker for each field.

Step 4 Configure for use in the system.

Using the system configuration of OTRS, you can then add the two dynamic fields anywhere ticket data can be edited or reply are made. We will choose Ticket::Frontend::AgentTicketFreeText###DynamicField and add thees as well to Ticket::Frontend::AgentTicketZoom###DynamicField for ease of viewing.

Using then the Miscellaneous -> Free Text, you can then access the values for your dynamic fields via web service request.

Until next time,

((enjoy))

Shawn Beasley

• 0