Navigation:  Admin Panel > Views > Views : General Settings >

View type: XML definition

Previous pageReturn to chapter overviewNext page
Show/Hide Hidden Text

The 2 types of views supported in SSP7 are Query views and Process views. Query views can be used to show lists from any internal are external database. These type of views are convenient to show content of connected third party systems. Process views are meant to show information from the SSP7 database. Views are always defined in XML files that can be edited by any text editor, for example Notepad. It is advised to always work from existing XML files, also in case new views are created.

XML file structure

All XML view definitions have the same structure, which is displayed below:

clip0017

The example above shows the 6 main components of a view definition. Each component is explained below:

1.SQL Query, ConnectionType. Here you define what kind of database connection is to be made. Check the view types below to see what options are available
2.SQL Query, ConnectionString. This contains the connection information to the database and is only used for Query Views.
3.SQLQuery, CDATA. Here it is defined what information should be retrieved from the configured database connection. Content depends on the view type.
4.CountQuery, CDATA. The count query is only used in Query Views and its result is displayed as number of lines in a view between () behind the view name on the dashboard.
5.detailURL,
5.1.IsInternalDetail. This option is used to define if the details of a ticket should be retrieved from SSP internally or from data retrieved by the query. In case this option is set to 1, the process detail page will be displayed. In case the option is set to 0, the fields defined within the XML file will be displayed. Please note that for Process Views this option is ignored.
5.2.DetailInNewWindows. With this option, SSP7 can open a popup window when a user clicks on a line in the view. The popup will contain the ticket details.
5.3.CDATA. Defines the URL that should be displayed when a line is clicked. For Process Views this option is ignored.
6.ViewLocal. This defines the name of the view as displayed on the dashboard. For each language this name can be defined. In case you are not certain about the number of a language (this number is defined with the database table "Language") you may prefer to change the name of the view with the edit page of views:
clip0018
7.Field. This is a repeated section within the view definition. For each field that should be displayed in the view, all field attributed should be defined. In case the option IsInternalDetail is set to 0, the fields defined here will also be displayed on the detail page.
Size. With this option the width of the column in the view is defined in pixels.
order. This option gives the possibility to set the ordering of views on  certain fields. In case the value "Desc" is defined here, the view will have an initial descending ordering on the field.
7.1.Column. This field refers to a field, provided by the  data in the SQLQuery. In case of Query views, this field should refer to a column (or alias) retrieved by the database query. For process views this should refer to one of the pre-defined fields that can be found under process views below.
7.2.type. Defined the type of field. Use the word "Key" to indicate that a column contains the unique identifier of records in the list. Other types are Date and Text.
7.3.positionInView. Defines on which position the field is displayed within the view and on the detail form. The field with the lowest number is shown on the left hand side of the view and on top of the details form (in case the option IsInternalDetail is set to 0).
7.4.displayInView. With this option it can be defined if the field should be displayed within the view. In case this option is set to False, the field will only be displayed on the details form (in case the option IsInternalDetail is set to 0).
7.5.FieldLocale. The label defined here will be displayed as name of the field within the view and details form. For each language another label can be used. The ID of a language is defined in the database table "Language".

Process Views

For details on the structure of the XML file, please check the section above. Per XML property, the options for process views are displayed below:

SQLQuery, connectiontype="Tickets"

SQLQuery, connectionstring can remain empty. This option is only used for query views.

SQLQuery, CDATA : First the general list content should be defined by selecting one of the following options:

MyOpenActions : show all open actions for the current logged in user. These are all the tickets where he is the Actor of the step that is now open in this ticket
MyClosedActions : show all recently closed actions for the current logged in user. These are all the tickets where he was an Actor in this ticket
MyTicketsAsRequestor : Show all open tickets where the logged in user was the Requestor, regardless of the Requested for.
MyTicketsAsRequestedFor : Show all open tickets where the logged in user was the Requested for, regardless of the Requestor.
EmailHasOpenActionInReminder : Steps that have sent a reminder can be used in combination with  MyOpenActions
EmailHasOpenActionInEscalation1 : Steps that are in escalation 1
EmailHasOpenActionInEscalation2 : Steps that are in escalation 1
 

Then additional filters can be applied by adding any of the fields below on separate lines within the CDATA property:

TicketName=<Formname>. When you enter a form title here, this View will only show tickets from the entered Form. If this field is not provided, the View will show tickets from all forms.
TicketStatus=<Open of Closed>. Enter ‘Open’ or ‘Closed’ if you want to differentiate between open & closed tickets. If this field is not provided, the View will show open & closed tickets.
TicketDateEnded=months:-3. Enter a value to set the time between the current data and the date the ticket ended, expressed in Months or Days. Enter ‘months’ or ‘days’, followed by the value. As a guideline, 3 months is a good value, as in the example above.
TicketDateStarted=days:-5. Enter a value to set the time between the current data and the date the ticket started, expressed in Days. Enter ‘months’ or ‘days’, followed by the value Fields to be shown.
TicketStatus=Open. The View will show all open tickets.
 
Field, column. Define the fields from the ticket that are shown in this View.

These are the options:

AllSteps : shows a graphical representation of the complete process, so all steps, each step has a color code to indicate the status. This is the same as how Tickets are shown in the Search Results. Each step is in it own column
AllStepsTogether : this method is nearly identical to the one above, only now all lights are merged into 1 column
AllSearchColumns: will show the columns as defined in Search Results Columns ( setting on Process level). Remark : this will only work if all tickets in this View result from the same Process.
TicketNr : the SSP number of the Ticket
TicketDateStarted : Start date of the Ticket
TicketDateEnded : End date of the ticket (if ticket is already closed)
TicketName : Name of the Process
TicketStatus : Indication is ticket is open or closed
OpenStepName : Name of the current active step
OpenStepDateStarted : Start date of current open step
OpenStepStatusImage : image ( colored light) to show status of current active step
RequestedForUniqueId : ID of the User for who the ticket was created
RequestedForFirstname : First Name of the User for who the ticket was created
RequestedForLastname : Last Name of the User for who the ticket was created
RequestedForFirstAndLastname : First Name & Last Name of the User for who the ticket was created
RequestedForEmail : Email of the User for who the ticket was created
RequestedFor-<fieldname> : Any other field of User for who the ticket was created, as defined in SSP
RequestorUniqueId : ID of the User who created the ticket
RequestorFirstname : First Name of the User who created the ticket
RequestorLastname : Last Name of the User who created the ticket
RequestorFirstAndLastname : First Name & Last Name of the User who created the ticket
RequestorEmail : Email of the User who created the ticket
Requestor-<fieldname> : Any other field of the User who created the ticket, as defined in SSP
 

Additionally, any Field from the Form that was used to create the ticket can be inserted. Internal labels as defined in the Form are used to refer to the fields. To add columns, showing these fields, simply add them, using this syntax:

Formfield-<FieldInternalLabel>

 
Finally, you can enter fields from the Process

StepDate-<Path Name>||Started = Start date of the Step
StepDate-<Path Name>||Ended = End date of the Step
StepField-<Path Name>||<FieldName> = Value of that Field

 

Where <Path Name> the path towards the target Step is, so the names of the Steps and DecisionPaths after each other, split by  ||, following the structure of the process definition.

So, for example:

-"StepField-New HR number||New employee number” : is the field "New employee number" from the Step "New HR number".
-"StepDate-D1||Larger than 200||CIO Approval Step||Ended", Gives the end data of the Step "CIO Approval Step" in Decision path “Larger than 200" from step "D1". Always take the names form the default value.

Query Views

SQL Query, ConnectionType. Use the value "Internal" in case the SSP7 database is to be queried. When another database is queries, use Oracle or SQLServer as Connection Type.
SQL Query, ConnectionString. Use the same format here as within the adapter settings.
oFor Oracle this is an example string: "data source=ORCL;user id=ORCL;password=ORCL;persist security info=false/";
oFor SQL Server, this is the example: "data source=server;initial catalog=SMTXSSP7;User ID=SMTXSSP7;Password=SMTXSSP7;persist security info=False;packet size=4096"/>
SQLQuery, CDATA. Define here the SQL Query that retrieves the data from the configured connection. This query may contain the following variables:
o$person_firstname$. Contains the logged in users first name
o$person_lastname$. Contains the logged in users last name
o$person_email$. Contains the logged in users email address
o$person_<custom user field>$. Any of the defined custom user fields can be used here as variables. More information on custom user fields can be found here.
CountQuery, CDATA. Use the exact same query condition here and replace the select part by SELECT COUNT(*) as Nmbr FROM.
detailURL,
oCDATA. Define this URL if another URL than the standard URL should be called while opening the details of a ticket.
An example URL is http://yourserver/SSP7/workflow/ProcessInstanceDetail.aspx?processInstanceId=$ID$&processInstanceGuid=$UniqueReference$
The variables like $processInstanceId$ are field names.
Field.
oColumn. Only use table columns or aliases returned by the query. In case incorrect names are used, the view will fail, resulting in a General Error on the dashboard page.