The namespace #Site.URL# designates the URL through which Service Catalog is accessed. The URL path may also include a specific module to run as well as parameters (following the question mark) to pass to that module. The examples above generate a hyperlink in the email body that will direct the user to the My Services module, the Service Manager module or to capabilities available within those modules.

It is possible to create a namespace reference that will link to just about any page in My Services or Service Manager. The key to determining the appropriate URL is to have a site administrator temporarily turn on site debugging (but please read the caveats in the Cisco Prime Service Catalog Administration and Operations Guide carefully) and note the URL that appears when you navigate to the desired page. When embedding that URL in an email, you must use an encoded representation of characters such as ampersand (&).

Additional examples of such namespace references are given below.

As part of the installation process, administrators specify the Service Catalog URL. This URL is stored in the configuration file newscale.properties. A sample entry is shown below.

!-------------------------------------------------------------------
!Define the URL for the application
!This is used in emails for constructing the various urls
!-------------------------------------------------------------------
ObjectCache.Application.URL=http://appsrv01.celosis.com/RequestCenter/

The entry for ObjectCache.Application.URL is the value of the namespace #Site.URL# and #URL#. The URL typically ends with “/RequestCenter/”; however, it is possible to configure the application server to automatically reroute requests to /RequestCenter/, so this portion of the path may be absent from the properties file.

In this case, the word /RequestCenter/ must be added after #Site.URL#, such as #Site.URL#/RequestCenter/myservices/myservice.do? , and to #URL#, such as #URL#/RequestCenter/myservices/myservice.do? to ensure that the namespace link resolves to the correct URL.

In order to determine if the /RequestCenter reference must be inserted, you may consult the newscale.properties file (or have the application server administrator report on its contents). An alternate method is:

• Enter #Site.URL# or #URL# by itself in an email and send the email when, for example, a task starts.
• When receiving the email, note if the URL resolves to just http://www.mycompany.com or http://www.mycompany.com/RequestCenter/.
• If the resolved URL does not include the wording /RequestCenter/, then add /RequestCenter/ after #Site.URL# or #URL# respectively.

The namespace node #Message# is available only within the body of email messages generated as a result of a Service Link failure to deliver an outbound message. The template to be used is specified as the “Failed email” in the Service Link agent definition. Elements in this node may be useful in helping a administrator diagnose the cause of the failure.

The subject of an authorization or review task can be configured to reflect requisition data through the use of namespaces, thus making the subject specific to the customer’s order. Simply include the namespace in the Subject field.

The most frequently used namespace is the name of the service to which the current review/authorization applies. This is typically concatenated with other descriptive text; for example:

Group Review for #Name#

The namespace #Name# is available as a shortened form for the Service Name.

Only namespaces referring to a specific attribute of the service and NOT the content of a service form can be used for Organizational Unit Reviews or Authorizations or Financial Authorizations. For instance, when using a namespace to refer to the customer’s first name:

#Requisition.Customer.FirstName# -- CORRECT
#Service.Data.Customer_Information.First_Name# -- INCORRECT

Service Group Reviews and Authorizations may use #Service.Data# namespaces. Such reviews/authorizations apply to an individual service, so the service (form) data is available. Financial Authorizations and Organizational Unit Reviews/Authorizations apply to an entire requisition, which may include multiple services (requisition entries); therefore, the service data for an individual service is not available.

The Project Manager may be assigned from a person, queue, or expression. The expression may use any of the Assignment Types to identify a person in Organization Designer.

EXAMPLES:

LOGINNAME=#Service.Data.Project.ManagerLogin#
ID=#Customer.Supervisor.ID#

The subject for the monitoring task typically includes the #Name# namespace, to refer to the name of the service being monitored.

Monitor Plan for #Name#

Namespaces referring to performers, either people or queues, cannot be used.

Namespaces referring to the content of a service form can be used, but this may have side effects, as documented for the Delivery Task Name below.

The delivery task name typically includes the service name, through the use of the #Name# Namespace. Service data (#Service.Data....#) can also be used. Since all tasks are created when the form is submitted, the value of the specified field must have been supplied in the ordering moment.

Note	Using form data for a task name is not best practice, since the task would no longer be groupable by the task name in a reporting environment. Further, a Service Manager query would need to use the “contains” operator to retrieve the rest of the task name, which may adversely affect performance.

As with authorizations, the service team or person assigned to tasks in the delivery plan may depend on data on each requisition, such as a customer’s location. Expressions can be used to intelligently route tasks, rather than creating different forms or workflows for each possible scenario.

Plan tasks that can be dynamically routed include the Performer and Supervisor roles found on the Participants tab of each task:

Figure 3. Delivery Plan Task Participants

To assign “From an expression”, choose that option from the Assign drop-down list and click on the ellipsis (...) next to the “Assign to” field. The Edit Expression window appears to allow you to enter and validate the expression.

Figure 4. Review Details Window

Validation checks that any namespace specified is valid for the current scope (the specific level of review/authorization or task), with the exception of dictionary fields (Data.DictionaryName.FieldName). This is perfectly legitimate, since the Review/Authorization may be defined at a site- or organization- level, independent of the service with which it is integrated. However, it may cause a runtime error: if the specified namespace, for example, Data.EUIT_ACCESS.Access_Type, does not exist.

Validation also checks that correct relational and arithmetic operators are used.

As with authorization and review tasks, a plan task in the service delivery moment may also be conditional.

Figure 5. Task Definition General Tab

Once the condition has been entered, you must decide when that statement will be evaluated. Each task (approval, review, or delivery) with a condition can be evaluated either

• At the beginning of a phase (Authorization or Delivery moment), or
• When the activity becomes active.

Conditional statements may include arithmetic operators as well as relational (logic) operators.

The type of logical operators you can use depend on the HTML representation of the field being tested. Most fields have (input elements) that allow only one value to be assigned; these include text, text area, radio button, single-select (drop-down) list, and radio buttons. The following logical operators can be used in conditional statements applied to such fields:

Operators for conditionals have the standard order of operation:

-  (negative)
*  (multiplication), /  (division)
+  (addition),   -  (subtraction)
<, >, >=, <=, <> (not equal), =
NOT
OR
AND

Parentheses can be used to change the operator precedence or clarify the condition.

EXAMPLES:

ActivityID >= 50
Customer.FirstName = "Ann"
Requisition.ActualCost >= 2000
Service.Quantity * Service.PricePerUnit <= 1000
Data.Approver.Custom_2 = "VP" OR Data.Approver.Custom_2 = “Director”

The INCLUDES operator can only be applied to fields that can hold multiple values. These include multi-select (drop-down boxes) and check boxes. The following logical operators can be used in conditional statements applied to such fields:

EXAMPLE:

Data.EUIT_ACCESS.AccessType INCLUDES “DSL” AND NOT
Data.EUIT_ACCESS.AccessType INCLUDES “Dial-Up”

Note	No “#” signs are used to enclose the Namespace.

• An alphanumeric value included in the condition must be enclosed within double quotation marks (“”).
• Namespace names are not case sensitive. The recommended standard is to use Title case (capitalizing the first letter of all words).
• All alphanumeric comparisons are case sensitive. For example, the condition “Data.MoveIndividual.FirstName=”Matt”” would be true only if the value of the FirstName field in the MoveIndividual dictionary were “Matt”, with an initial capital letter and the rest lower case letters.
• Any Boolean Namespaces (those whose names start with “Is”) have different values, depending on the underlying database. In SQLServer, the value of a Boolean is either true or false. In Oracle the corresponding values are 1 (for true) and 0 (for false).
• Less than and greater than operators for numeric value comparisons are not supported for dictionary fields. They are treated as text during comparisons. For example, the condition “Service.Data.VM.MemoryGB > 4” is evaluated to false if the dictionary field VM.MemoryGB has a value of 16.
• Multibyte characters are not supported for text string comparisons.
• An ampersand (“&”) included in a literal must be encoded as “&”. For example, the value “two & three” would appear in an expression as “two & three”.
• The following operators are not supported for boolean type fields:
  • is greater than
  • is less than
  • is equal to ignore case
  • begins with
  • ends with
  • contains
  • does not contain

Use a condition that always evaluates to false (for example, “1=2”) in a conditional statement to specify a task that will automatically be skipped.

The most common use cases for this are:

• When a service needs to “autocomplete” without having any tasks completed. The skipped task will mark the end of the delivery plan, and the requisition is marked as complete.
• When an email needs to be sent without having to complete a task or when multiple emails are needed during a given moment in the following ways:
  • Create a parent task. On the email tab, choose an email to be sent out at completion (you may also configure one to go out when the activity becomes active).
  • Create a child task with the condition 1=2. Set the condition to evaluate when the activity becomes active.

The following diagram illustrates the nodes in the Namespace and the relationships between the nodes. The type of a node determines not only its own properties, but also the subcontexts (other nodes) to which it provides access.

The labeled boxes in this figure represent the types of Namespace nodes. Labeled arrows show the Namespace elements that allow the properties of one node to be accessed from another node. This figure can serve as a guide for service designers and administrators who need to navigate the Namespace to get access to Service Catalog data. For example, tracing the arrow labeled “Customer” from the Process node, we can see that the “Customer” element gives the Process node access to the properties of the Person node. So, for example, to access the Customer’s login name in a conditional statement for a task in a delivery plan, the condition would reference the namespace:

Requisition.Customer.LoginName

To access the same namespace from an email for a delivery plan, the namespace reference would be:

#Service.Requisition.Customer.LoginName#

Node relationships are not bidirectional. The fact that the Process node has access to the properties of the Person node does not imply that the properties of the Process node are also available to the Person node.

From the perspective of the service designer or administrator who wishes to use Service Catalog data in formatted emails or conditional statements, there are multiple “entry points” to the paths between nodes:

• Activities associated with Requisition Entries (services), such as delivery plan tasks, Service Group Authorizations, Service group reviews, and emails generated by any of these activities.
• Activities associated with Requisitions, such as Departmental Authorizations, Departmental Reviews, and Financial Authorizations.

These entry points determine the Namespace context that applies when a service designer or administrator is configuring email to be sent from an activity, or defining a conditional execution statement. Think of them as the starting point for navigating the paths between nodes. Where you enter the Namespace determines what nodes, and ultimately what properties and data values, will be available to you from that particular activity.

Figure 7. Namespace Objects and their Relationships

The authorizations and reviews at an organizational level may trigger an email:

• Organizational Unit Authorization
• Organizational Unit Review
• Financial Authorization

These email entry points support the Namespace elements listed below:

#ActivityID#
#Priority# - priority assigned to the task: 1=high, 2=normal, 3=low
#DueOn#
#Subject# - the name of the task
#Waiting#
#ScheduledStart#
#StartedOn#
#CompletedOn#
#ExpectedDuration# - typical task duration, in hours
#ExpectedDurationUnits# - units in which task duration is displayed
#ActualDuration# - actual task duration, in hours
#CurrentDate#
#StateName# - the status of the task
#URL#
#Customer.*# - where * denotes any Customer element
#Performer.*# - where * denotes any Performer element
#PerformerQueue.*# where * denotes any PerformerQueue element
#Process.*# -- where * denotes any Process (task) element
#Requisition.*# - where * denotes any Requisition element

Tasks which are part of the delivery plan, as well as service group authorizations and reviews may trigger an email:

• Service Group Authorization
• Service Group Review
• Plan Task
• Late Task
• Ad-hoc Task
• Failed Service Link Task

These email entry points support the Namespace elements listed below:

#ActivityID#
#Priority#
#DueOn#
#Subject#
#Waiting#
#ScheduledStart#
#StartedOn#
#CompletedOn#
#ExpectedDuration#
#ActualDuration#
#Instructions# -- for Adhoc tasks only
#CurrentDate# -- the current date and time in GMT
#StateName# -- the current status (state) of the activity
#URL# -- the URL for directly accessing Task Details for this activity
#Customer.*# -- all Customer elements; for an adhoc task only, this   refers to the service performer who created the task
#Performer.*# -- all Performer elements
#PerformerQueue.*# -- all Queue elements
#Process.*# - all Process elements
#Service.ServiceID#
#Service.ProcessTrackingID#
#Service.Quantity#
#Service.PricePerUnit#
#Service.HasPrice# -- false (0) if the service has no price, 1 (true)otherwise
#Service.Bundled# -- true (1)if the service is a child service in a   bundle, false (0) otherwise
#Service.isBundle# -- true (1) if the service is itself a bundle, false  (0) otherwise
#Service.BundledServices# -- the number of child services bundled with  the current service
#Service.ServiceDefinition.Name#
#Service.ServiceDefinition.IsEntitlement#
#Service.ServiceDefinition.DescriptionURL#
#Service.ServiceDefinition.ExpectedDuration#
#Service.ServiceDefinition.FunctionalPosition.PersonTypeElement#
#Service.ServiceDefinition.ServiceGroup.Name#
#Service.ServiceDefinition.ServiceGroup.FunctionalPosition
.PersonElement#
#Service.RequisitionEntryID#
#Service.Requisition.URL#
#Service.Requisition.ProcessTrackingID#
#Service.Requisition.ExpectedDuration#
#Service.Requisition.StartedDate#
#Service.Requisition.ActualCost#
#Service.Requisition.ExpectedCost#
#Service.Requisition.RequisitionID# 
#Service.Requisition.Name# 
#Service.Requisition.Customer.*# --all Customer elements
#Service.Requisition.Initiator.*# -- all Initiator element
#Service.Requisition.ClientOU.*# -- all ClientOU elements
#Service.Data.DictionaryName.FieldName#

The service data namespaces generally have the format

#Service.Data.DictionaryName.FieldName#

The authorizations and reviews at an organizational level may be conditionally executed.

• Organizational Unit Authorization
• Organizational Unit Review
• Financial Authorization

These conditional entry points support the following Namespaces:

Site.URL
Customer.*
Initiator.*
ClientOU.*

Service group authorizations and reviews, as well as tasks which are part of the delivery plan allow conditions to determine whether the task/review is executed:

• Service Group Authorization
• Service Group Review
• Plan Task
• Late Task

These conditional entry points support the following Namespaces:

Requisition.* 
Data.DictionaryName.FieldName

In delivery tasks, including escalations, the customer is the Task Supervisor. For ad-hoc tasks, the customer is the task performer who initiated the ad-hoc task. For all other tasks, and for a requisition, the customer is the person for whom the service has been requested. Customer namespaces allow access to customer information, including:

• Customer (person) information as defined in the person's profile and accessible via Organization Designer > People
• All person/profile information defined for the customer’s supervisor
• Information about the home Organizational Unit of the customer
• All person/profile information defined for the manager of the customer’s home OU

The namespaces below must be enclosed in hash marks (#) when used in emails, but entered without the hash marks when used in expressions. A complete list of person-type namespaces is listed in the Person-Based Namespaces.

Customer Namespaces.

#Customer.PersonTypeElement#
#Customer.Supervisor.PersonTypeElement#
#Customer.HomeOU.Name#
#Customer.HomeOU.OrganizationalUnitID#
#Customer.HomeOU.OrganizationalUnitTypeID# -- the type of unit, where 1=service team, and 2=business unit
#Customer.HomeOU.CostCenterCode#
#Customer.HomeOU.Manager.PersonTypeElement#
#Customer.HomeOU.ParentOU.Name#
#Customer.HomeOU.ParentOU.OrganizationalUnitID#
#Customer.HomeOU.ParentOU.OrganizationalUnitTypeID# -- the type of unit, where 1=service team, and 2=business unit
#Customer.HomeOU.ParentOU.CostCenterCode#

The performer is the person responsible for performing a task in the service's delivery plan. Performer namespaces are not available in context in which no task is current—these include the email for Organization Unit reviews and authorizations; and financial authorizations.

Performer namespaces allow access to performer information, including:

• Performer (person) information as defined in the person's profile and accessible via Organization Designer > People
• All person/profile information defined for the performer’s supervisor
• Information about the home Organizational Unit of the performer
• All person/profile information defined for the manager of the performer's home OU

The namespaces below must be enclosed in hash marks (#) when used in emails, but entered without the hash marks when used in expressions. A complete list of person-type namespaces is listed in the Person-Based Namespaces.

#Performer.PersonTypeElement#
#Performer.Supervisor.PersonTypeElement#
#Performer.HomeOU.Name#
#Performer.HomeOU.OrganizationalUnitID#
#Performer.HomeOU.OrganizationalUnitTypeID#
#Performer.HomeOU.CostCenterCode#
#Performer.HomeOU.Manager.PersonTypeElement#

Performer Queue namespaces provide information about the queue to which a review, authorization, or task was assigned. A subset of the Person-based namespace elements and properties are meaningful—those which are exposed in the user interface for maintaining queues in Organization Designer.

#PerformerQueue.FirstName#
#PerformerQueue.LastName#
#PerformerQueue.TimeZoneID#
#PerformerQueue.Email#
#PerformerQueue.WorkPhone#
#PerformerQueue.HomePhone#
#PerformerQueue.Fax#
#PerformerQueue.Mobile#
#PerformerQueue.Pager#
#PerformerQueue.TimeZone#
#PerformerQueue.HomeOU.Name#
#PerformerQueue.HomeOU.OrganizationalUnitID#
#PerformerQueue.HomeOU.OrganizationalUnitTypeID#
#PerformerQueue.HomeOU.CostCenterCode#
#PerformerQueue.HomeOU.ParentOU.Name#
#PerformerQueue.HomeOU.ParentOU.OrganizationalUnitID#
#PerformerQueue.HomeOU.ParentOU.OrganizationalUnitTypeID#
#PerformerQueue.HomeOU.ParentOU.CostCenterCode#
#PerformerQueue.HomeOU.Manager.PersonTypeElement#

The initiator is the person who orders a service.

Initiator namespaces allow access to initiator information, including:

• Initiator (person) information as defined in the person's profile and accessible via Organization Designer > People
• All person/profile information defined for the initiator's supervisor
• Information about the home Organizational Unit of the initiator
• All person/profile information defined for the manager of the initiator's home OU

The namespaces below must be enclosed in hash marks (#) when used in emails, but entered without the hash marks when used in expressions. A complete list of person-type namespaces is listed in the Person-Based Namespaces.

#Initiator.PersonTypeElement#
#Initiator.Supervisor.PersonTypeElement#
#Initiator.HomeOU.Name#
#Initiator.HomeOU.OrganizationalUnitID#
#Initiator.HomeOU.OrganizationalUnitTypeID#
#Initiator.HomeOU.CostCenterCode#
#Initiator.HomeOU.Manager.PersonTypeElement#
#Initiator.HomeOU.ParentOU.Name#
#Initiator.HomeOU.ParentOU.OrganizationalUnitID#
#Initiator.HomeOU.ParentOU.OrganizationalUnitTypeID#
#Initiator.HomeOU.ParentOU.CostCenterCode#

Functional positions allow you to access the Person information for individuals who have been assigned to these positions. You can access this information both for the default functional positions, and for those that have been configured for a particular implementation.

Functional positions are defined through the module selection Organization Designer > Functional Positions. Each functional position is associated with a particular entity—this may be a service, a service group, or an organizational unit.

Once the position has been defined, you may assign a person to the position through the Positions page for the organizational unit, or on the General tab for the service or service group. Some sample usages include:

Use Requisition.Customer.HomeOU.BudgetManager.Email to access the email address of the Budget Manager of the customer’s home organizational unit.

Use Performer.HomeOU.ParentOU.Manager.FirstName to access the first name of the Manager of the parent organizational unit of the task performer’s home organizational unit.

Default functional positions may have spaces in the position name, for example, “Budget Manager”. The space is omitted with the functional position is used within a namespace reference.

User-specified functional positions may not include spaces. The namespace reference must prefix the functional position with the keyword “Position” as in the following example:

#Service.ServiceDefinition.Position.EscalationManager.Email#

For all of the functional positions, you have access to all the variables defined in the Person table above. If no person variable is included, the expression returns the person’s database ID.

You can access information about Home OU, Parent OU, or Client OU functional positions from any person role that you can access in either the Requisition or the Service context. Information about Service and Service Group functional positions is only available in the Service context.

When using these expressions to include dynamic data in emails and task names, you must add the pound separator (‘#’) at the beginning and end of the expression, for example:

#Customer.HomeOU.Manager.Email#

Customer-based namespaces used for the Customer Information reserved dictionary are summarized below.

Initiator-based namespaces used for the Initiator Information reserved dictionary are summarized below.