ServiceGrid Article - Maintenance Mode for Webservice Connection

From DocWiki

Jump to: navigation, search



Maintenance mode for webservice bridges


A webservice bridge connects two endpoints with each other and is responsible for exchanging the data. When one of the endpoints is being maintained, it no longer responds correctly. In such cases, alerts were triggered and human action was needed to check the current situation.
To reduce the need for human interaction, the new Maintenance mode was introduced for webservice bridges. With this mode, the bridge behavior and its reaction to errors can be defined for a specified timeframe (Maintenance window).

How does it work?

A webservice bridge can be put into maintenance mode by defining a maintenance window for a specific timeframe. To do so, the Administrator needs to navigate to the ServiceDefinition of the webservice bridge through the following path:
Basicdata > MyCompany > [Company] > ServiceDefinitions > [ServiceDefinition]

Image017 6.9.png

A new TopFunction Display MaintenanceWindows has been added in the master data main menu in the Servicedefinition. Clicking on it displays a list of all defined maintenance windows for this ServiceDefinition/Webservice bridge.

Image018 6.9.png

When creating a new maintenance window two timestamps and two selectboxes can be defined.
StartTime and EndTime: Define the start and the end of the maintenance window respectively. Only the start time is mandatory. The maintenance mode is endless if no end time is defined. 
Reaction: Defines how a webservice bridge should behave when entering maintenance mode.
Immediate pause: Pauses the bridge instantly.
Delayed pause: Pauses the bridge when the first error occurs. It will be restarted at the given EndTime.
Behavior: Defines how a webservice bridge should behave when in maintenance mode.
Reject: The bridge does no longer accepts messages from the sending endpoint.
Queue: The bridge accepts messages and queues them. When the maintenance window has ended, the bridge tries to deliver the queued messages.

Image019 6.9.png

After a new maintenance window has been created or an existing one has been changed, it is necessary to reload the bridge. This can be done using the Reload Bridge function in the detailed form of the service definition.

Image020 6.9.png

Handling Messages Rejected due to a Maintenance Window


In the first implementation of the maintenance window, customizing the needed message rules was required to process rejected messages within the workflow of the partner. Therefore, it was necessary to do this for each connected partner separately.
With this change, these settings should be done only once on the same side on which the maintenance window is defined.

How does it work?

If a message has been rejected due to a maintenance window, it will be processed by the system like an inbound message from that partner. This means that a call update will be executed and a new ticket history record will be created.


To be able to process a rejected message as inbound transaction, an inbound message rule must be created:

  • Inbound message trigger
  • Inbound communication

                - The type of this communication is “WebService REST/SOAP outbound”.
                - The service definition, which has defined the maintenance window, must be defined as sender for this inbound communication.

  • Inbound template

This is the rejected message which should be processed by the inbound template:

<reject outboundCallId="200033391">
            Message rejected - maintenance mode with behavior &apos;rejectt&apos; enabled

Example of an inbound template:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="" version="1.0">
<xsl:template match="/reject">
         <xsl:value-of select="@outboundCallId"/>
         <xsl:value-of select="rejectReason"/>: <xsl:value-of select="message"/>

For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.  

Rating: 0.0/5 (0 votes cast)

Personal tools