It can be quite complex to manage a high number of requests in a Help Desk environment, Delays in responses may have a negative impact on business and cause user dissatisfaction. The SRM Response Plan is an escalation engine and integrated workflow that helps prioritize the tickets automatically by applying actions to accelerate their closing.

A response plan can be applied in several service requests or work orders with similar characteristics. Thus, repetitive tasks can be eliminated. Depending on how the response plan was set, the following actions can be performed:

Assign the responsible person or group to handle the request;

Assign the lead person for the work order;

Assign the supervisor for the work order or ticket;

Assign the crew that is responsible for the work order;

Select the appropriate job plan or template to accomplish the requested work;

Notify the appropriate individuals about the work in process;

Specify the actions that are needed to resolve the issue;

Assign a solution to be applied to the ticket.

1.2 Objective

This tutorial demonstrates how to create and implement a Response Plan to facilitate the processing of service requests created through Service Request Manager.

1.3 Prerequisites

This tutorial is based on Service Request Manager 7.2.1 However, the Response Plan functionality is also available in Service Request Manager 7.2.

The user required to execute this tutorial must have administrative privileges in order to create escalations, actions, communication templates, job plans and response plans.

2. Executing this tutorial

Step 1: Creating a response plan

Login to Maximo and navigate to the Response Plan application: Go to → Service Level → Response Plan.

Image 1 - Response Plan page

The application has seven tabs (Image 1): List, Response Plan, Conditions, Locations, Assets, Configuration Items and Response Actions. Except by the List tab, all the other tabs contain fields to define how the response plan will be implemented and what actions will be taken.

To create a new response plan, click on the “New Response Plan” icon.

Enter a name and description (Image 2):

Image 2 - New response plan

Every new response plan is created as draft and must be changed to active when completed.

Define the application that this new Response Plan will be applied to and rank it.

Image 3 - Define application and ranking

A response plan can be applied to an incident, work order or a problem. Therefore, you can create a response plan specific to each type of ticket you want to work. In the example above, this response plan will be applied to a service request.

Step 2: Criteria definition

Navigate to the Conditions tab to set the response plan criteria.

A response plan may be applied according to the ticket classification. In the example below (Figure 4), this response plan will be applied to tickets that are classified as 'Printer / Low Toner'.

Image 4 - Conditions

The response plan can also be applied according to a service group (Image 5):

Image 5 - Service Group

A query can be created in order to have a more accurate set of tickets that a particular response plan can be applied. The SQL Expression Builder may aid in the query creation. In the example in image 6, the response plan will be applied only if the ticket was originated from a specific offering. In this case the query would be: PMSCITEMNUM = 'PMSC_2007A'.

Image 6 - Additonal criteria

The asset used in the ticket may also be used as criteria to apply a specific response plan. Considering the example above, the toner replacement procedure may vary depending on the printer model. In this case the asset criterion supersedes the classification. Therefore the asset value will define the Response Plan to be applied.

Navigate to the Assets tab and specify an asset as shown in the image 7. The same thing can be done in the Configuration Items tab.

Image 7 - Assets

Step 3: Actions definition

After defining the criteria of the response plan, we define what actions may be taken, for example, assign the ticket to a owner group. To do this click on the Response Plan tab and fill in the field 'Assign Owner' or 'Assign Owner Group'. When the response plan is applied to an incident, as shown in Figure 8, it should be assigned to a group or person.

Image 8 - Assign owner

You can create generic response plans to assign tickets to specific groups based on the ticket classification, such as telephony, network, hardware, and so on. Therefore, you do not need to analyze and manually transfer the ticket to the owner group. That would be done automatically by an escalation (Image 9).

Image 9 - Incident assigned to an owner after applying a response plan

Response plans may also apply actions, work orders and send notifications. If an incident is opened for password change, based on criteria such as classification or source of the ticket, you can apply an existing solution with steps on how to change the password.

As a prerequisite, you need active solutions to be available. Create a response plan, define the criteria and select a solution (Image 10):

Image 10 - Response plan with solution

You can see the solution in the Solutions Details tab from the ticket that had the response plan applied. (Image 11).

Image 11 - Apply response plan with solution

The Response Plan can also be applied with a Ticket Template or with a Job Plan.

Image 12 - Response Plan with Ticket Template

Go to the Response Actions tab to set other actions such as sending notifications or closing tickets automatically.

In the example of the response plan with a solution, one might argue that there is no reason to keep the ticket opened. You can associate an action to close the ticket and send a survey to the user as shown in Image 13.

Image 13 - Response plan with notification and survey

To add a notification it is necessary to create a communication template first: Go to → System Configuration → Platform Configuration → Communication Templates and setup a SMTP server to send e-mails.

Go to → System Configuration → Platform Configuration menu and create Actions and Escalations for more options to your Response Plan.

3.How to apply a response plan

The response plan can be applied in three ways:

3.1Apply a response plan to a ticket

Open a ticket (service request, problem or incident) and from the Select Action menu select Apply Response Plan (Image 14).

Image 14 - Apply Response Plan

3.2 Apply response plan automatically

You can create an escalation to apply response plans automatically to tickets. The following example shows an escalation that runs every 5 minutes, applying a response plan when a service request is classified as “Printer / Toner Low”.

When creating an offering, check the option "Invoke Apply Response Plans Workflow Only?". Thus, when the user submits the cart with the offering, a response plan will be automatically applied to the service request.

Software systems workloads can always be articulated as a mix of two flavors of computing tasks:

OLTP (Online Transaction Processing)

Batch Processing

OLTP is the computing activity of serving requests originated by interactive users waiting for an answer in a acceptable time; whereas, batch processing refers to programs running in the background trying to finish the given amount of work in the designated window of time. The key performance metric for OLTP system is the response time experienced by the end user, while for batch systems, the reference metric is the throughput - the number of tasks completed in the unit of time. See H. H. Liu: Software Performance and Scalability: A Quantitative Approach – J. Wiley & Sons, for a more detailed discussion.

One of the benefits that the Java platform has introduced is the fact that it manages the memory for you, through the usage of the Garbage Collection (GC) algorithm. Unfortunately, a not well tuned GC can result in sub-optimal performance and scalability. The initial step of the GC tuning is choosing the GC policy according to the characteristics of the workload. Today's JVMs support multiple GC algorithms that you can control thought the command line options. The IBM JVM support 4 different policies through the -Xgcpolicy: option:

optthruput - It is the default policy and is typically used for applications where raw throughput is more important than short GC pauses. The application is stopped each time that garbage is collected.

optavgpause - Trades high throughput for shorter GC pauses by performing some of the garbage collection concurrently. The application is paused for shorter periods.

gencon - Handles short-lived objects differently than objects that are long-lived. Applications that have many short-lived objects can see shorter pause times with this policy while still producing good throughput.

subpool - Uses an algorithm similar to the default policy's but employs an allocation strategy that is more suitable for multiprocessor machines. It is recommend this policy for SMP machines with 16 or more processors and is only available on IBM pSeries® and zSeries® platforms.

TPAe based systems are actually a mix of the two workload profiles and their behavior is characterized by the presence of a lot of transient objects. Based on these considerations, Tivoli performance decided to test the gencon policy that is able to provide a good trade-off between short pause times and good overall throughput. Results achieved in all the experiments that we did were very encouraging. As you can see in the following graph about one of the scenarios we run, the response time improved and became more stable, as is shown by a reduced standard deviation:

The gencon policy was also beneficial for the CPU utilization. Also from this point of view we observed a lower and more stable demand, as you can see clearly in the following graphs (default policy and gencon):

If you are not familiar with the Tivoli Technical Enablement Support Technical Exchange seminars, check out the website: Tivoli Support Technical Exchange (STE)Customers and Business Partners can attend these free seminars, where technical experts share their knowledge about Tivoli products.

You can also subscribe to Customer STE Announcements by sending an email to isstte@us.ibm.com asking to subscribe to the "Customer STE Announcements". Subscribers will receive a customer-formatted invitation twice a month.

Welcome to Useful Tiny Little Things, a series of topics that I will publish in the Process Automation blog. My name is Leandro Cassa and I work at IBM as the CCMDB Level 3 support team leader. The purpose of this series is to provide useful simple things that we sometimes have no idea exist. These tips apply to CCMDB, Tivoli Asset Management for IT, Service Request Manager, and other products based on Tivoli's process automation engine.

This week I'll talk about filtering records, which are everywhere on TPAE based systems.

Last week we discussed the the UI table. Most of the UI tables on your system are likely to be filterable.

OK, enough talking, lets get going on search tips!

Again I'll use the Work Order Tracking application as a sample for my experiments here. Let's use the following screen shot as a data table for our experiments (click on the image to enlarge):As you can see I'm already using a very common filter wildcard, the %.

% or * - is for one or more characters_ or ? - is for a single character

Let's play around. "%problem" is already in the Description field. If we change that to "%Plumbing%" only the first row would show up. On the other hand if we filter the Description by "13%", only the first record won't show up. Let's try the single character match now (_ or ?). If we filter the Work Order (wonum) field by "300__", the result is the second and the third record appears. That is because the fourth record is 30157; it does not start with 300. Notice that you can mix filters in different fields. In other words, you could filter Description and Work Order (WONUM) together, at the same time.The screen shot on the left shows the results for mixing field filters.

Well, those are the basics. I guess you have no idea about what is coming next.

You can actually search for null entries and reverse (use the logical NOT) for any searches.

Some samples: "!=1003" return all records but the one with Work Order field (wonum) 1003. Notice you cannot mix this with what we already learned; the ones we are using right now are for unique values only, not wild cards.You can use it for any fields, just as you use exact searches, but this is truly useful for unique values.

Talking about unique values, at some point you might need to list records with null values, use "~null~" to filter those. On our data sample table (the first screen shot on this post) we have a record with no Location set, therefore a null location. Filtering that with "~null~" results on that record only (Work Order 30058).

But you could also reverse that. If you are looking for a non-null location, accomplish this by using the "!=", just like this: "!=~null~".

There is more yet.

= - is for exact matchesY or N - is for checkboxes

You probably have seem a "=something" around, it matches the exact values. So if you search for "=1003" on the Work Order field it only shows the record 1003. The only exception for the use of = is for dates. In that case, the match must not be exact. We'll cover that soon.Checkboxes also can be filtered by using Y for checked (YES or TRUE) and N for unchecked (NO or FALSE), so if you have a field which is a check box, you could use =Y or =N.

Now the grand finale.

> or < - greater or less>= or <= - greater and equal or less and equal

Those are useful and interesting, but they can only be applied for numbers and dates. In dates, the greater or less (> or <) are intuitive: if you filter the Scheduled Start using ">10/25/01" the records 30056 and 30157 show in the results, although no hour was set on the filter. Given that, ">=" or "<=" are useful if you have midnight hours.

The same behavior of not setting an hour value works if you use "=" for date fields. For example, if you filter the Scheduled Start using "=10/25/01", you still get the same records 30056 and 30157, just because they are in the same date.

The following results in a single record only (due to the few records used for this post), but it is a summary of all filters used on this post.

IMPORTANT NOTE: Using wild cards, especially at the beginning of a string and with no other criteria, almost always ends up with a full table scan. Be aware that a query in a large table can take many minutes, which may cause the impression that the system is actually hanging.

Welcome to Useful Tiny Little Things, a series of topics that I will publish in the Process Automation blog. My name is Leandro Cassa and I work at IBM as the CCMDB Level 3 support team leader. The purpose of this series is to provide useful simple things that we sometimes have no idea exist. These tips apply to CCMDB, Tivoli Asset Management for IT, Service Request Manager, and other products based on Tivoli's process automation engine.

Hope you enjoy, and I hope this helps you take more advantage of the great amount of features found in the process automation engine.

Enough talking, lets get started.

This week I'm talking about user interface (UI) tables. If you have ever
used CCMDB or any other process automation engine product, you have
already met the UI table. Most of the process automation engine
applications have a List tab on as the default tab, so as soon as you
open an application like Work Order Track on a TPAE based application
you are looking at a UI table (see image below).

And it is very likely that at some point on a existing or customized application on your system you would like this table to show more rows than what you actually see. Yes, it is possible and it is simple!

The first step is to open the Application Designer, follow with me: Go To > System Configuration > Platform Configuration > Application Designer.

Now find the application you would like to apply the changes by writing the exact name you see on the top of the application window (in my screenshot here is "Work Order Tracking").

Open the record and select the tab for the UI table in which you want to increase the displayed rows. I'm using the Work Order Tracking application, the Actuals tab and the 'Tasks for Work Order {0}' table as a sample.

Right-click on the 'tablebody...' entry as the red arrow shows in the following picture, then click the Properties
entry. Be careful: you need to right click on the 'tablebody...'. If
you select another entry by mistake you might not get the right
properties changed.

A pop-up window is displayed. Notice the Display Rows Per Page field. The default value is 6. I changed this value to 10.

Save the record, then go check your changes on the application you chose.

As you can see below, my 'Tasks for Work Order {0}' table used to list 6 entries and now it shows 10 entries.

Before:

After:

IMPORTANT NOTE: Although expanding table rows display amount is a very nice feature, it also has implications. Tivoli Process Automation Engine based systems only fetches the visible rows, so doubling the number of rows comes close to doubling the time to display such rows. Therefore, changing it from 10 rows to 100 can cause a noticeable change in the time to display of the modified application. This is especially true if there are calculated attributes or relationship based attributes being displayed.