Managing the Services and Attributes
Manage Service Items tab allows service item administrators to:
- Review the service items currently tracked by Service Catalog, no matter how they were added to the system.
- Add new service item instances.
- Update information related to a service item such as service item details, services associated with the service item, permissions provided for each service item.
Existing service items are listed in alphabetical order by name.
Step 1 Choose Service Item Manager > Manage Service Items.
Step 2 Select appropriate Actions, see Actions in Manage Service Items table.
Actions available are summarized in the table below. Additional information is provided in the following sections.
Table 9-1 Actions in Manage Service Items
Add a service item of the specified type.
Delete the chosen service item.
Assign the service item to the chosen person (customer).
Remove the customer to whom the service item is currently assigned.
Export to Excel
Export the list of service items to a text file in CSV (comma-separated values) format and display that file as an Excel spreadsheet.
To export service item data to spreadsheet format, click Export to Excel. A text file in CSV format is produced. You can open the file in Excel or save it to your local disk for future use.
Save as your default service item view to the current view, with filters and field selection criteria in effect.
To save the filter and search criteria currently in effect, click Save View. If you exit from Manage Service Items and return, the saved filter criteria will be in effect. To revise the saved view, click Filter and Search and edit the criteria as appropriate. Click Save View after you have applied those changes to replace the view with the edited or default view (if you remove all criteria).
Filter and Search
Display the popup window to configure search parameters.
The Filter and Search option allows you to restrict the service items that are displayed. The filter criteria include all attributes that comprise the service item, as well as the customer and organizational unit to which the service item is assigned; the date the service item was assigned to that person; and the requisition ID through which the service item was created.
By default, filter criteria for alphanumeric fields use a “Contains” filter. For example, entering ‘386’ (without the quotation marks) in the Name field will find all service item instances whose name includes the string ‘386’.
You can define permissions to view or edit service items based on the role assigned to a user. For more information on permissions that can be added, see Assigning Permissions section in Cisco Prime Service Catalog Administration and Operations Guide.
Managing Service Request Initiated by Other Authorized Person (Order-On-Behalf)
The Service Catalog order-on-behalf process allows a service request initiator to order a service on behalf of another person, the intended customer. A drawback of this approach is that the intended customer must have ordering permissions for the service. This contradicts some corporate policies where, for example, IT or administrative personnel should be able to order services for other people, but people not in the IT or administrative roles should not be able to order these services for themselves.
Without service items and service item-based dictionaries, a workaround for this situation is possible but hardly ideal. An initiator could choose the person for whom the service was intended (using a person-based dictionary), but there was no way for that person to be able to track “his” requisitions. This situation is remedied by the use service items and service item-based dictionaries. An initiator can order a service (and provision a service item) and designate a chosen person as the customer. The customer would then be able to monitor the request in the form of a service item that would appear in his Service Items page.
The procedure for implementing this functionality is fairly straightforward:
1. Design the service item.
2. Create the service item-based dictionary, being sure to include in the dictionary the CustomerID and OrganizationalUnitID. Optionally include a user-defined Status field, which can be updated as the delivery plan progresses.
3. Include the SIBD in an active form component.
4. Create a person-based dictionary to allow the initiator to choose the customer for the service item. Include this dictionary either in the same active form component as the SIBD or another form component—as long as both dictionaries are included in the service.
5. In the active form component containing the person-based dictionary write two rules as shown below, to copy information on the chosen person to the service item-based dictionary.
Figure 9-1 Rule Dictionary
An administrator is now able to order the service for various customers, and the customers can see the service item in the Service Items page or My Items portlet (provided they have been granted the My Services 360-Degree Consumer or Professional role.) If the service item has associated services for which the owners of the SIs have ordering permission, they are able to order those services directly from the Service Items page.
A drawback of this approach is that the requisition would not be searchable by “Customer”, within Service Catalog’s online modules, including Reporting and Advanced Reporting. In Advanced Reporting, the Service Item’s Customer replacement dictionary (in the example above, SICustomer) would need to be reportable.
Retrieving Service Items, History, and Subscriptions
You should generally not have to write a SQL query using the service items, history and subscriptions table. Most of this information is provided to users via the My Items portlet and page. However, it is possible to write a data retrieval rule retrieving information from these tables. For example, perhaps you do not want a user to request a service which provisions a service item if he already has one.
In order to write SQL-based data retrieval rules, you need to know a little bit about the table structure.
select * from SiServiceItemSubscription
where ServiceItemTypeName = 'State of the Art Laptop'
and DisplayName = 'joe-nov13-2013'
- As specified above, the name of the table corresponding to a service item is the item’s name prefixed by “Si”. So, an SI with the display name State of the Art Laptop, with a table name of StateOfTheArtLaptop has a corresponding table in the database named SiStateOfTheArtLaptop.
- How is that table related to ServiceItemSubscription? The easiest way to join it is on ServiceItemTypeName. So, if you want to get the subscription information for a State of the Art Laptop named joe-nov13-2013, this query works:
Or, you could get a list of all State of the Art Laptops by executing this query:
select*from siserviceitemsubscription sis
join siStateoftheArtLaptop al
on al.PrimaryID = sis.ServiceItemIDpredefined
where sis.serviceitemtypename ='State of the Art Laptop'
select sih.*, sis.*from SiServiceItemHistory sih
join siServiceItemSubscription sis
on sih.OwnerID = sis.PrimaryID
where sis.ServiceItemTypeName ='State of the Art Laptop'
and sis.DisplayName ='joe-nov13-2013’
- And then how do I get from there to the ServiceItemHistory records? The key is the PrimaryID in the Service Item Subscription equals the OwnerID in the Service Item History. So:
Export/import is provided primarily for backward compatibility with previous versions of Service Catalog. It provides a way to copy or “clone” an existing service by downloading the service definition to the local workstation; modifying the service name; and importing the revised service definition. Cloning a service is best accomplished by Copying a Service.
Exporting and Importing a Service
The procedure for using service export/import is as follows.
1. Configure the service.
2. Export the service.
3. Modify the service name in the exported XML file.
4. Import the modified XML file.
Although service export/import may work in transferring a service definition from one site to another, this is not recommended. The export includes associations to people, OUs, queues, roles and other entities that are not part of the service definition. Importing the service does not create these entities in the target environment if they do not already exist; it simply drops the association without issuing any error messages.
Tip Catalog Deployer is the recommended tool for transferring Service Catalog content between sites.
Note Passwords for ‘Persons’ and ‘Agents’ data imported from a different database (using Catalog Deployer or REX), must be reset in the target database. This is because the Key Encryption Key is different for different instances of Prime Service Catalog databases. If the passwords for ‘Persons’ and ‘Agents’ are not reset, they cannot be decrypted correctly in the target database.
To export a service:
Step 1 Choose Service Designer> Services. Select the service you want to export.
Step 2 From the General tab, click Export.
The Export Service window appears.
Figure 9-2 Export Service
Step 3 Right-click the File Name link and choose Save Target As to save the file to your desired location.
Service Designer exports the service in XML format to the location you designated.
If you are using Internet Explorer, you may experience difficulty saving the XML file. If this occurs, go to
Tools > Internet Options > Advanced Tab > Security and check the
Do not save encrypted pages to disk option. This option is unchecked by default.
To edit the exported XML file that is saved in the user specified location.
Step 1 Open the XML file in a plain text editor such as Windows Notepad.
Step 2 Change the service name in the file where it reads:
<ServiceDefinition name="service name here"....>.
If you do not change the service name within the XML file, the import process will overwrite your original service. (It is possible to change other elements in the XML file, but this practice is not recommended. If invalid XML is produced, the import will fail.)
Step 3 Click Save to save the edited XML file.
The edited XML file is now ready for import.
To import a service:
Step 1 Choose Service Designer > Services > New > Import.
Step 2 In Import Data window, browse to or enter the filename (including the path) in the Import from file field.
You can only import an XML file that has been previously exported and saved to its default location ora location on the local machine.
You can also use the Browse function to choose a file on your workstation.
Step 3 Click Import.
Service Designer displays an Imported Data screen to confirm the import.
Step 4 Click OK to refresh the Service Catalog display. The imported service appears in the service group specified in the XML file.
Copying a Service
Service Designer includes the ability to copy a service definition. Copying a service copies the complete service definition, including any associations with keywords and categories as well as the associations to included active form components.
To copy a service definition:
Step 1 Choose Service Designer > Services > General.
Step 2 Click Copy on the General tab of the service definition. The Copy Service popup window appears.
Figure 9-3 Copy Service
Step 3 Enter the name of the new service and choose the service group into which the new service definition should be placed. Only service groups in which the current user has permission to “Design forms” are available for selection.
Note Copying a service to a new group, does not affect the service group authorizations of the target group—these remain the same.
Tracking Service Design Changes
You can track the changes done to the Service Designer entities via History option. To track the changes performed by various service designers and to store the data in the database, you must first enable the service design change history option. For more information on how to enable service design change history, see Cisco Prime Service Catalog Administration and Operations Guide.
For now, service design change history is supported only for Services, Dictionaries, and Active Form Components entities. There are various other attributes for each of these entities, which are also tracked but not in detail. The track changes are limited to support create, update, and delete operations only to the following attributes and can be viewed from Change Details table:
– Name and Description fields
– Other fields, like Additional URL, Hide in Service Catalog, Standard Duration, Service Group, Image URL, and so on.
– Name and Description fields
– Addition and Deletion of dictionary
– Display Properties of the Form. For example: Change in the Input Type field
– Active Form Rules (Conditional rule)
– Name and Description fields
– Dictionary Attributes
To view service design change history:
Step 1 Select Service Designer > History.
Step 2 Enter the Start Date and End Date. The dates should not exceed 60 days.
Step 3 (Optional) Select the type of Entity from the drop-down list.
Step 4 (Optional) Select the user name or the user group from the Users drop-down list.
Step 5 Click Filter. The Change Details table is displayed.
Step 6 (Optional) Select a row from the table to see the details of a specific entity, which is displayed in a new pop-up window.