ServiceGrid Article - Transaction Patterns

From DocWiki

Jump to: navigation, search

Contents

Overview

Transaction Patterns define the content of each transaction type by field mapping. Field mapping is the process in which each available inbound field is connected with a field from the Cisco ServiceGrid platform on the inbound and outbound side. 

General Rules

The Cisco ServiceGrid platform communicates in the following two directions:

  1. Inbound
  2. Outbound

The exchange of call data between a Service Customer (SC) and a Service Provider (SP) always consists of an initial CallOpen transaction and a sequence of CallUpdate transactions.


Sdbridgecallopencallupdate-18163637-700px.jpg


Call Identification

Only one field out of all the CallIdentifier fields is mandatory for inbound transactions. One of the following fields should be filled for a successful transaction:

Field Name
Field Description
Calls.CustCallID
The customer call identification code or number.
Calls.ID
The internal Cisco Service call identification.
Calls.SPCallID
The provider call identification code or number.
Calls.CustCallIDX
This is a special field which is a combination of {Calls.CustCallID}~SD{Calls.ID}.
Calls.HexID
The hexadecimal representation of Calls.ID.
Calls.ID
If this field is used, no additional selection of fields is needed. This is a unique identifier through the whole Cisco ServiceGrid platform. However, it cannot be used for CallOpen transactions because Cisco ServiceGrid created this identifier.
Calls.CustCallID
This identifier should be unique for each ContractElement or ServiceItem. If a CallUpdate occurs and another ContractElement of ServiceItem is used, an existing Call will not be found.
Calls.SPCallID
This identifier should be unique for each ContractElement or ServiceItem. If a CallUpdate occurs and another ContractElement of ServiceItem is used, an existing Call will not be found.

NOTE: Other or additional mandatory fields depend on the customization. If more than one contract exists, additional fields should be used to specify only one contract such as Contract, ContractElements, or Device fields.

Transaction Identification (Finding)

This section lists the various transaction identification states:

  • If the specified call does not exist, transaction will be performed as CallOpen.
  • If the call exists, a CallUpdate or CallClose transaction occurs.
  • If no call state is given, and the specified call does not exist, the call state having the CanStart flag and the lowest sequence number will be used.
  • If the corresponding call exists, and no call state is given by the inbound transaction, a CallUpdate transaction will be initiated without changing the call state.
  • If a call should be closed, a call state has to be sent.

Call and Contract Finding (Identification)

The address string of the inbound transaction is important for finding the correct call or contract.

Possible address strings are as as follows:

  • In case of email, the mail address of the sender.
  • In case of SOAP or HTTP-Post, the mail address of the corresponding SOAP or HTTP-Post user.
  • In case of FTP, the user directory name.

NOTE: Additional parameters are the MessageTrigger scope, definition (Company, CallSystem), and the specified contract definition in the content of the inbound record.

Transactions after a call was closed

If the customer sends a transaction without a call state and the corresponding call is closed, a new call will be created.
If the provider sends an update to a closed call, the transaction will be added to the found call without changing any call state.

Find converter and templates in inbound communications

  • If there are more than one inbound templates or converters, the correct inbound communication is found depending on the inbound address string.
  • In case this inbound address string is used more than once in inbound communications, the inbound communication choice is random. This means that the wrong template or communication might be chosen.

NOTE: Avoid using inbound addresses more than once. To prevent this, additional inbound fields can be used to check the format of the inbound record. If the wrong converter or template is used, stop processing and step over to the next possible converter or template.

Inbound Transactions - Sending a Call Open Transaction to Cisco ServiceGrid

  • A CallOpen transaction received by Cisco ServiceGrid will be processed by the Cisco ServiceGrid inbound converter.
  • This process has to result in a unique reference to a Contract and ContractElement in the Cisco ServiceGrid database valid for the sender of the transaction. Otherwise, the transaction will be rejected.
  • If the processing is successful, a new call will be created in the Cisco SerrviceGrid database.


Sdbridgecallopen-18164223-700px.jpg


  • In most cases, the initial CallOpen transaction is sent from the service customer to the service provider and contains all important information describing the service requests such as Incident, Problem, Change, and so on in detail.
  • There are a number of options and combinations of values in the CallOpen transaction to refer to a Contract and ContractElement.
  • The simple standard option is to send the Contracts.ShortName and the ContractElements.ShortName.

For more information about Contract and ContractElement data in the Cisco ServiceGrid database, refer to the SD.BasicData document.

Simple Standard Sample for Call Open

The following fields are a simple standard sample for a CallOpen transaction:

Case 1: When the service provider is sending a CallOpen to Cisco ServiceGrid.

SDTag
SD
Description
Type
Length
Example
Calls.SPCallID
M
The providers' call identification code or number.
varchar
30
4321
Contracts.ShortName
O
Short name of the Contract between SC and SP.
varchar
12
Service
ContractElements.ShortName
O
Short name of the ContractElement between SC and SP.
varchar
12
SL1
Calls.Description
O
The incident description as free text.
text
0
Description Text
CallStates.ShortName
O
The providers' call status code.
varchar
20
Work External

Case 2: When the service customer is sending a CallOpen to Cisco ServiceGrid.

SDTag
SD
Description
Type
Length
Example
Calls.CustCallID
M
The customers' call identification code or number.
varchar
30
4321
Contracts.ShortName
O
Short name of the Contract between SC and SP.
varchar
12
Service
ContractElements.ShortName
O
Short name of the ContractElement between SC and SP.
varchar
12
SL1
Calls.Description
O
The incident description as free text.
text
0
Description text
CallStates.ShortName
O
The customers' call status code.
varchar
20
Work External


Call Open Fields

In some cases, the sender of the CallOpen transaction might want to provide more information about the service request.

The sample below contains a larger number of fields describing details such as Component, Location, Contact, Caller, and so on.

SDTag
SD
Description
Type
Length
Example
Contracts.ShortName
M
Short name of the Contract between SC and SP.
varchar
12
Service
ContractElements.ShortName
O
Short name of the ContractElement between SC and SP.
varchar
12
SL1
Contracts.CustIDProv
set
The customer ID in the provider system.
varchar
50
CUST12345
Contracts.ProvIDCust
set
The provider ID in the customer view.
varchar
50
PROV12345
Contracts.ContractIDProv
set
The contract ID in the provider view.
varchar
50
CON12345
Contracts.ContractIDCust
set
The contract ID in the customer view.
varchar
50
CON54321
Calls.CustCallID
M
The customers' call identification code or number.
varchar
30
4321
Calls.SPCallID
M
The provider call identification code or number.
varchar
30
4321
CallStates.ShortName
O
The call status code.
varchar
20
Work External
Calls.CallOpenTime
O
The time when the call was opened.
timestamp
19
10.04.2003 10:00
Calls.Description
O
The incident description as free text.
text
0
Description text
Calls.Diagnosis
O
The incident diagnosis as free text.
text
0
Diagnosis text
Calls.Remarks
O
Additional remarks as free text.
text
0
Remarks text
Calls.CustomerCategory1
O
The call category level 1.
varchar
50
Hardware
Calls.CustomerCategory2
O
The call category level 2.
varchar
50
Computer
Calls.CustomerCategory3
O
The call category level 3.
varchar
50
Desktop
Calls.CustomerCategory4
O
The call category level 4.
varchar
50
Interface
Calls.CustomerCategory5
O
The call category level 5.
varchar
50
LAN
CustomerPriorities.ShortName
O
The customer priority code.
varchar
20
Low
CustomerSeverities.ShortName
O
The customer severity code.
varchar
20
Medium
Calls.MainComponent
O
The name of the component.
varchar
50
Desktop
Calls.MainCompManufacturer
O
The manufacturer of the component.
varchar
50
IBM
Calls.MainCompType
O
The components' OEM type code.
varchar
50
8571
Calls.MainCompModel
O
The model descriptor of the component.
varchar
50
200
Calls.MainCompSerNr
O
The serial number of the component.
varchar
50
553456
Calls.MainCompInvNr
O
The inventory number of the component.
varchar
50
9008001
Calls.MainCompDescription
O
The description of the component.
varchar
4000
Device Description Text
Calls.MainCompLocation
O
The door number of the component's address.
varchar
50
D2005
Calls.MainCompLocationName
O
The street name of the component's address.
varchar
50
Sales Department
Calls.MainCompLocationZip
O
The postal code of the component's address.
varchar
50
80788
Calls.MainCompLocationCity
O
The city of the address of the caller.
varchar
50
München
Calls.MainCompLocationCountry
O
The country of the address of the component.
varchar
50
DE
Calls.MainCompLocationProvince
O
The province of the address of the component.
varchar
50
Bayern
Calls.MainCompLocationStreet
O
The street of the component's address.
varchar
50
Mainstreet 1
Calls.MainCompLocationTel
O
The phone number of the component's address.
varchar
50
+49 100 100
Calls.MainCompLocationFax
O
The fax number of the address of the component.
varchar
50
+49 100 200
Calls.CCPLastName
O
The last name of the contact person.
varchar
50
Meier
Calls.CCPFirstName
O
The first name of the contact person.
varchar
50
Hans
Calls.CCPSalutation
O
The salutation of the contact person.
varchar
50
Mr.
Calls.CCPDepartment
O
The department name of the contact person.
varchar
50
Sales Department
Calls.CCPShortName
O
The short name of the contact person.
varchar
50
HM
Calls.CCPSign
O
The sign of the contact person.
varchar
50
50901
Calls.CCPPIN
O
The personal identification number of the contact person.
varchar
50
1234
Calls.CCPEMail
O
The email address of the contact person.
varchar
50
hans.meier@customer.com
Calls.CCPMobileTel
O
The mobile phone number of the contact person.
varchar
50
+49 7777 8888
Calls.CCPTel
O
The phone number of the contact person.
varchar
50
+49 600 800
Calls.CCPFax
O
The fax number of the contact person.
varchar
50
+49 400 500
Calls.CCPLocation
O
The name of the location.
varchar
50
Headquarter
Calls.CCPLocationZip
O
The postal code of the address of the contact person.
varchar
50
80788
Calls.CCPLocationCity
O
The city of the address of the contact person.
varchar
50
München
Calls.CCPLocationCountry
O
The country of the address of the contact person.
varchar
50
DE
Calls.CCPLocationProvince
O
The province of the address of the contact person.
varchar
50
Bayern
Calls.CCPLocationStreet
O
The street of the address of the contact person.
varchar
50
Mainstreet 1
Calls.CallerLastName
O
The last name of the caller.
varchar
50
Doe
Calls.CallerFirstNam
O
The first name of the caller.
varchar
50
Joe
Calls.CallerSalutation
O
The salutation of the caller.
varchar
50
Mr.
Calls.CallerTitle
O
The title of the caller.
varchar
50

Calls.CallerDepartment
O
The department of the caller.
varchar
50
Sales Department.
Calls.CallerPIN
O
The personal identification number of the caller.
varchar
50
3456
Calls.CallerSign

O
The short sign of the caller.
varchar
50
JD
Calls.CallerShortName
O
The short name of the caller person.
varchar
50
6577890
Calls.CallerEMail
O
The email of the caller.
varchar
50
joe.doe@customer.com
Calls.CallerMobileTel
O
The mobile phone number of the caller.
varchar
50
+ 49 777 200300
Calls.CallerTel
O
The phone number of the caller.
varchar
50
+ 49 300 200300
Calls.CallerTel2
O
The alternative phone number of the caller.
varchar
50
+ 49 300 2003008
Calls.CallerFax
O
The fax number of the caller.
varchar
50
+ 49 300 2003001
Calls.CallerLocation
O
The location of the caller.
varchar
50
Headquarter
Calls.CallerLocationCity
O
The city location of the caller.
varchar
50
LONDON
Calls.CallerLocationCountry
O
The country location of the caller.
varchar
50
UK
Calls.CallerLocationProvince
O
The province location of the caller.
varchar
50
LONDON
Calls.CallerLocationStreet
O
The street location of the caller.
varchar
50
Piccadilly 10
Calls.CallerLocationZip
O
The postal code location of the caller..
varchar
50
SW100
Calls.CHDLastName
O
The last name of the helpdesk person.
varchar
50
Schmied
Calls.CHDTel
O
The phone number of the helpdesk person.
varchar
50
+49 700 200
Calls.CHDDepartment
O
The department of the help desk person.
varchar
50
Service


Other Options to Open a Call
Besides the standard option of using Contract and ContractElement, there are a number of other options to open a call.

Field Name
Field Description
CustCallID
CusctCallID is mandatory for a CallOpen inbound transaction.
SPCallID
SPCallID is mandatory for a CallOpen inbound transaction.
ContractElements.Shortname
If the ContractElements.ShortName is unique, the Contracts.ShortName field is not needed.


It is important, that only one contract is selected depending on inbound address identifier, used CallSystem and scope in MessageTrigger settings, and used contract selection fields.

There are several fields which can be used to specify only one contract. For example, Device selection fields, Contract selection fields and ContractElement selection fields.

NOTE: Each inbound value in the fields for contract selection should have a corresponding record in the Cisco ServiceGrid database.

The other fields depending on individual settings are as follows:

Field Name
Field Description
ContractElements.ShortName
If the ContractElements.ShortName is unique, the Contracts.ShortName field is not needed.
CallStates.ShortName
If only one CallOpen CallState exists, the CallStates.ShortName field is not mandatory.
Calls.Description
The Calls.Description in a CallOpen transaction is not mandatory.


Sending a Call Update Transaction to Cisco ServiceGrid

Once a call is opened and processed to the service partner, the following call update transactions take place as illustrated in the diagram below:


Sdbridgecallupdate-18164609-700px.jpg


CallUpdates to a call can be sent from both the service customer or service provider, following the agreed workflow.

Sample for a Call Update Transaction
An example for minimum requirements for a CallUpdate transaction uses the following fields:

Service provider:

SDTag
SD
Description
Type
Length
Example
Contracts.ShortName
O
Short name of the contract between SC and SP.
varchar
12
Service
ContractElements.ShortName
O
Short name of the ContractElement between SC and SP.
varchar
12
SL1
Calls.SPCallID
M
The provider's call identification code or number.
varchar
30
4321
Calls.Remarks
O
The worklog text.
text
0
Worklog Text
CallStates.ShortName
O
The provider's call status code.
varchar
20
Work External

Absolute minimum in case of using the ServiceGrid identifier:

SDTag
SD
Description
Type
Length
Example
Calls.ID
M
The Cisco ServiceGrid identification number.
varchar
30
4321
Calls.Remarks
O
The worklog text.
text
0
Worklog Text

Call Update Fields:

SDTag
SD
Description
Type
Length
Example
Contracts.ShortName
M
Short name of the contract between SC and SP.
varchar
12
Service
ContractElements.ShortName
O
Short name of the ContractElement between SC and SP.
varchar
12
SL1
Contracts.CustIDProv
O
The customer ID of the provider system.
varchar
50
CUST12345
Contracts.ProvIDCust
O
The provider ID in the customer view.
varchar
50
PROV12345
Contracts.ContractIDProv
O
The contract ID in the provider view.
varchar
50
CON12345
Contracts.ContractIDCust
O
The contract ID in the customer view.
varchar
50
CON54321
Calls.CustCallID
M
The customer's call identification code or number.
varchar
50
4321
Calls.SPCallID
O
The provider's call identification code or number.
varchar
50
4321
CallStates.ShortName
O
The call status code.
varchar
20
Work External
Calls.CallRecoveryTime
O
The time when the call was recovered.
timestamp
19
10.04.2003 10:00
Calls.CallCloseTime
O
The time when the call was closed.
timestamp
19
10.04.2003 10:00
Calls.Solutions
O
The incident solution as free text.
text
0
Solution Text
Calls.Diagnosis
O
The incident diagnosis as free text.
text
0
Diagnosis Text
Calls.Remarks
O
Additional remarks as free text.
text
0
Remarks Text
Calls.Notes
O
Additional notes in a call.
text
0
Notes Text.


Options for Inbound Transactions

There are several ways to control the standard inbound processing. Normally, the option is in inbound templates, but these options can also be set as inbound content.

Control Tags

Control tags are elements which can be set by inbound tags as shown in the following table:

Inbound Control Tag - Values: Y/N (Yes/No)

Field Name
Field Description
Control.UpdateAfterCloseAllowed
If set to Y, the customer can update an existing call after it is closed when Calls.ID is not given.
Control.UseCodeDefaults
If set to N, no default code will be set, if the value is not given by inbound content.
Control.MakePreSelection
If set to Y, converter tries to find an open Call only using SPCallID or CustCallID.
Control.SetCurrentCallState
If set to Y, current CallState will be set explicitly, if no CallState is sent.
Control.ForwardAfterClose
If set to N, partner outbound message trigger will not be fired, if call was closed before updating with actual record.
Control.UseSuccessors
If set to N, only partner successors are valid. Own successors will be ignored.
Control.MergeDefaultsOnContractOrContractElementChange
If Contract or ContractElement is changed by Call-update within known bounds, the defaults from Contract or ContractElement are normally NOT merged into the call, unless this flag is set to Y.
Control.UseIndependentDeviceRef
If set to Y, does not include the device in search for Contract or ContractElement but still establishes an independent reference to the device which will also work on Call updates.
Calls.InternalState

00 - normal processing,

01 - NOT_OPEN, meaning the transaction should be handled like an open-transaction,

03 - PROVIDER_ERROR, only a marker,

04 - DON’T_SEND_CALL, no partner message rules will be fired.


Root Attributes
The inbound messages, created by templates, should use the Cisco ServiceGrid namespace. The root tag named can be expanded with attributes.

Root Attribute
Description
Valid
If this attribute is set to NO, inbound processing will be stopped, and the next possible converter or template will be used. If no further converter or template is found, an error message is thrown.


Error Handling

Several inbound tags can be set to throw error messages before the inbound processing starts.

InboundFieldName
Value
Description
Error.ErrorStateShortName
0
No Error; nothing happens.
1
Information; an Information Error Message will be sent to the correspondent Partner Error message Recipient, depending on the Role and Contract.
2
Warning; a Warning Message will be sent to the corresponding Sender Error message Recipient.
3
Reject Error; Transaction will be aborted; Message will be sent to the correspondent Sender Error message Recipient.
4
System Error; Transaction will be aborted; Message will be sent to the correspondent Sender Error message Recipient and to the Cisco ServiceGrid Support Team.
5
Internal Error; Transaction will be aborted; Message will be sent to the Cisco ServiceGrid Support Team.
Error.ErrorStateName
NOERROR
similar to ErrorStateShortName 0
INFORMATION
similar to ErrorStateShortName 1
WARNING
similar to ErrorStateShortName 2
REJ_ERROR
similar to ErrorStateShortName 3
SYS_ERROR
similar to ErrorStateShortName 4
SD_ERROR
similar to ErrorStateShortName 5
Error.ErrorMessage

If an ErrorMessage is set depending on several individual inbound check rules, a REJECT ERROR is thrown, except for the ErrorStateName or ErrorState ShortName which is set explicitly.


Special Inbound Fields

Field Name
Field Descrption
TimeStamps
All timestamps are interpreted with sender timezone and corresponding format defined in inbound communication. All timestamps will be converted to UTC timezone and an internal format. The used timezone is taken from the sender or receiver organization.
Following TimeStamps could only be set, if the corresponding flag at the CallState on sender side is set to Y (Yes) or O (Overwrite):
  • CallAcknowledgeTime
  • CallResponseTime
  • CallRecoveryTime
  • CallOpenTime
  • CallStartSLATime

If the flags are set to Y, values can be inserted, if the field is empty.

Contracts.{ContractFieldName}
Selection fields to find correct contract. If additional fields are used, they are logical AND combinded. All criteria should match.
ContractElements.{ContractElementFieldName}

Selection fields to find correct contractelement or serviceitem. If additional fields are used, they are logical AND combinded. All criteria should match.
Calls.[Caller|CCP|CHD]PIN or Calls.[Caller|CCP|CHD]ShortName
If no Calls.[Caller|CCP|CHD]LastName is used, the converter tries to use the wanted person from the Cisco ServiceGrid Database.
Calls.ID
This is the Cisco ServiceGrid internal CallIdentifier. It cannot be used at CallOpen Transactions. It should be numeric. If no Call is found, the transaction will be rejected. When this field is filled, no other search criteria (like Contract- or ContractElements-Fields) will be used.
Calls.Remarks and Calls.Discription
At CallOpen Transaction, if these fields are not filled, the content from the other field will be used.
Calls.ShortDescription
Could only be set at CallOpenTime.
Calls.CustCallID and Calls.SPCallID
Field could only be set if there is no value in it. Field cannot be overwritten. If one of these values is changed, the converter tries to create a new Call. This field is used for finding Call in combination with other Contract/ContractElement/Device-Selection-Fields.
Calls.Notes
If this field is filled at inbound transaction, only the fields for finding a Call will be used. All other fields except this one are ignored. No CallUpdate will be initiated. Only notes are attached to the Call.
Calls.XMLInfo
Field to store separate XML structures in it. Could not be displayed by Online Interface except View Templates.
Devices.{DeviceFieldName}
With the Devices Fields, inventory items can be selected. Fields work in combination with Contracts, ContractElements, and Location Fields. If more than one device is selected, a default device will only be used when the Devices.ShortName, Devices.Component and Locations.ShortName fields are identical. Otherwise, the transaction will be rejected.
ParentCall.CustCallID and/or ParentCall.SPCallID or ParentCall.ID
Fields to connect the actual Call to defined ParentCall SUBCALL Fields which are put in parantheses with this tag will be imported in a second step and ignored during the actual processing. It is possible to create more than one Call with one Inbound Document. Inside these parantheses, normal Cisco ServiceGrid Fields can be used, including the SUBCALL Tag by itself. The processing takes place from outer to inner. If inner SUBCALLS are processed, outer Subcalls exist and can be connected through ParentCall Tags.
CallAdditionals

It is possible to add several CallAdditionals to the call.
One CallAddtionals set exists of 1 to 64 free fields (Field1, Field2, and so on) and optionally a FunctionPort (default=Converter) and a PosNr (default=last PosNr+1).
In case of call update, a key existing of several fields can be given (Parameter: key = yes). This key may exist on several FieldX fields, FunctionPort, and PosNr. These key fields are used to search for an existing additional entry connected to the call. If an entry is found, its values are updated with the ones given in the call updates keyless fields.

NOTE: The same field can be given as key and as an update value. First, search for an entry and then update its key.
If no key is given, a new entry will be created. In case of an existing entry with the same unique key (CallID, FunctionPort, PosNr), the transaction will be rejected.


Outbound Transactions

Format Description

The following are the three possibilities of creating outbound formats:

  1. JAVA converter (individual converters): This is a special programmed JAVA converter and is the preferred method for using complex structures and calculations on outbound side.
  2. XSLT template (preferred): This XSLT template works without programming a converter.
  3. Combination of Java converter and XSLT: For advanced cases, a mixture of both methods (XSLT and JAVA converter) is possible. Even when there are several outbound transactions, calculations could be done by a JAVA converter and format conversion could be done by XSLT scripts.

Available fields for outbound communications

There are more than 3,700 fields available for outbound transactions. These fields are documented in our online interface in the location CommonContent > Dictionary > Fields > UBOT(UsedByOutboundTemplate)=Y. The source namespace is described in internal FieldNames.

Field dictionary:

Master data of an example import field:

Examples

Using this namespace, every other namespace or format can be produced using XSLT.

The syntax of this namespace should be interpreted in such a way that each word between slashes describes separate nodes. If there are brackets on the end of the word, it means, that this structure is a multiple record structure. In case of multiple records, each record is counted with the NR Attribute.

Example 1: Fields below the root node:

/SD.call/CallerDepartment.This means: /{RootNode}/{Field}

You can get this information through:

<xsl:value-of select=”/SD.call/CallerDepartment”/>

To step into the root node, select the value with relative path such as :

<xsl:value-of select=”CallerDepartment”/>

Example 2: Sample Structure below the root node:

/SD.call/CallStates/ShortName. This means: /{RootNode}/{SubNode}/{Field} 

To receive the value of this field, use the following absolute path description similar to the above:

<xsl:value-of select=”/SD.call/CallStates/ShortName”/>

or step into the structure like:

<xsl:template match=”/SD.call”>
  <xsl:for-each select=”CallStates”>
     <xsl:value-of select=”ShortName”/>
  </xsl:for-each>
</xsl:template>

Example 3: Multiple Record Structure

/SD.call/CallHistory[]/BPPersonsEDI/LastName 

There is a possibility to get one record from the CallHistory with one statement. To know only the last CallHistory Entry, use the following statement:

<xsl:value-of select=”/SD.call/CallHistory[@NR=1]/BPPersonsEDI/LastName”/>



To see all the persons who created CallHistory-Entries, use an xsl for each statement as shown below:

<xsl:template match=”/SD.call”>
  <xsl:for-each select=”CallHistory”>
     <xsl:sort select=”@NR”/>
     <xsl:value-of select=”BPPersonsEDI/LastName”/>
  </xsl:for-each>
</xsl:template>


This statement gives a list of all editing persons found in the CallHistory, sorted by creation date.

Root Attributes

The outbound messages, created by templates, should use the specific Cisco ServiceGrid namespace. The root tag named can be expanded with attributes.

Root Attribute
Description
Send
If this attribute is set to NO, this message will not be sent.
EMFrom
This is set to relay the Cisco ServiceGrid sender address. This is only allowed for addresses known by the sdcall.SolveDirect.com mail server.
EMTo
This is used to set alternative receiver address. This is used when the receiver should be changed depending on the content to the corresponding call.
ReplyTo
A possibility to set the reply to address depending on the call content.

Error Handling

In case of error message trigger, only the fields in internal field name called /SD.call/Error are filled. No other outbound field is available. Not many of these fields are available for normal message triggers.

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


Rating: 0.0/5 (0 votes cast)

Personal tools