Content Server WebReports Standard

User Guide

This guide is intended for Content Server WebReports Standard

users and developers. It provides a comprehesive guide to
creating and using WebReports within Content Server.
Content Server WebReports Standard
User Guide

Rev.: 2010-Dec-23
Open Text Corporation
275 Frank Tompa Drive, Waterloo, Ontario, Canada, N2L 0A1
Tel: +1-519-888-7111
Toll Free Canada/USA: 1-800-499-6544 International: +800-4996-5440
Fax: +1-519-888-0677
E-mail: [email protected] or [email protected]
FTP: ftp://ftp.opentext.com
For more information, visit http://www.resonatekt.com or http://www.opentext.com

Copyright © 2004-2010 Resonate KT Limited

Open Text Corporation is the owner of the trademarks Open Text, The Content Experts, Great Minds Working Together,
Livelink, Livelink ECM, Livelink ECM-eDOCS, Livelink MeetingZone, MeetingZone, B2BScene, B2BScene.com, Client/Surfer,
Collaboration, Creative Desktop, Further Faster, Hyperinnovation, Internet Anywhere ,Livelink IRIMS, IRIMS, IXOS, Livelink
OnTime, OnTime, Livelink Remote Cache, Microstar, MyLivelink, O & Design, Odesta, Odesta Helix, Odesta Livelinke, Open
Text Intranet, Open Text Web Index, Personality +, Putting Knowledge To Work, Techlib, The Hyperlinked Organization, The
Source For Business Knowledge, Worksmart, and World Of E among others. This list is not exhaustive.
ACKNOWLEDGEMENTS
SAP®, R/3® and SAP ArchiveLink® are registered trademarks of SAP AG.
Adobe® is a trademark of Adobe Systems Incorporated.
Lotus® and Lotus Notes® are registered trademarks of Lotus Development Corporation. Domino is a trademark of Lotus
Development Corporation.
Microsoft® and Microsoft SQL® are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
Oracle® is a registered trademark of Oracle Corporation.
Netscape and the Netscape N and Ship's Wheel logos are registered trademarks of Netscape Communications Corporation in
the U.S. and other countries.
Firefox® is a registered trademark of the Mozilla Foundation
Sentry Spelling-Checker Engine Copyright © 2000 Wintertree Software Inc.
WordNet 2.0 Copyright © 2003 by Princeton University. All rights reserved.
Outside In® Viewing Technology © 1992-2002 Stellent Chicago, Inc. All rights reserved. Outside In® HTML Export © 2002
Stellent Chicago, Inc. All rights reserved.
Portions of eDOCS DM are copyrighted by DataDirect Technologies, 1991-2002.
All other products or company names are used for identification purposes only, and are trademarks of their respective
owners. All rights reserved.
 WebReports User Guide

Contents
1 Purpose ................................................................................................................................... 5
2 Introduction ............................................................................................................................ 6
2.1 Why Use WebReports?....................................................................................................... 6
2.2 How Do WebReports Work? ............................................................................................... 7
3 Getting Started Using WebReports ...................................................................................... 8
3.1 Overview ............................................................................................................................. 8
3.2 Creating a WebReport ........................................................................................................ 8
3.3 Editing a Reportview – Online ............................................................................................. 9
3.4 Adding a New Reportview ................................................................................................. 10
3.5 Data Source Configuration ................................................................................................ 10
3.6 Changing the associated Data Source for a WebReport .................................................. 14
3.7 Property Tabs .................................................................................................................... 15
3.8 WebReports “Run As” Feature .......................................................................................... 15
4 Running WebReports .......................................................................................................... 17
4.1 Overview ........................................................................................................................... 17
4.2 Passing Parameters .......................................................................................................... 17
4.3 Form Submission Mechanism ........................................................................................... 17
5 Reportview File .................................................................................................................... 19
5.1 Overview ........................................................................................................................... 19
5.2 Structure of the Reportview .............................................................................................. 19
5.3 Example Reportview ......................................................................................................... 20
5.4 Default Reportviews .......................................................................................................... 22
6 Reportview Tags .................................................................................................................. 25
6.1 Overview ........................................................................................................................... 25
6.2 Tag Definitions................................................................................................................... 26
6.2.1 Content Control Tags ........................................................................................... 26
6.2.2 Column Data Tags................................................................................................ 39
6.2.3 Sub-Tags .............................................................................................................. 48
7 Exporting Report Data ....................................................................................................... 114
7.1 Overview ......................................................................................................................... 114
7.2 Exporting to Desktop ....................................................................................................... 114
7.3 Exporting to Livelink – New Document ........................................................................... 114
7.4 Exporting to Livelink – New Document Version .............................................................. 115
7.5 Exporting to E-Mail .......................................................................................................... 116
7.6 Exporting to a WebForm ................................................................................................. 117
7.7 Exporting to a Workflow .................................................................................................. 118
7.8 Exporting to the Livelink Server ...................................................................................... 119
7.9 Exporting to a FTP Server............................................................................................... 119
7.10 Configuring Default WebReport Behavior ................................................................ 119
8 PDF Conversion ................................................................................................................. 121
8.1 Overview ......................................................................................................................... 121
8.2 How to Convert a Document ........................................................................................... 121
8.3 XML Job Tickets .............................................................................................................. 122
8.3.1 Creating an XML Job Ticket ............................................................................... 122
8.3.2 The $DEFAULT_PATH ....................................................................................... 123

Page i
 WebReports User Guide

8.3.3 Selecting a Job Ticket ........................................................................................ 123

8.3.4 Example Job Ticket ............................................................................................ 123
9 Setting Schedules for WebReports .................................................................................. 125
9.1 Overview ......................................................................................................................... 125
9.2 How to Set a Schedule ................................................................................................... 125
9.3 How to Set a WebReport to Run on the Same Date or Day ........................................... 125
9.4 How to Remove or Change a Schedule.......................................................................... 126
9.5 Important Notes and Recommendations ........................................................................ 126
10 WebReport Constants ....................................................................................................... 127
10.1 Overview ................................................................................................................... 127
10.2 Adding a WebReport Constant ................................................................................. 127
10.3 Referencing Constants in the WebReport Reportview ............................................. 128
10.4 Deleting a WebReport Constant ............................................................................... 129
10.5 Global Constants ...................................................................................................... 129
11 Using Parameters .............................................................................................................. 131
11.1 Overview ................................................................................................................... 131
11.2 Adding a WebReport Parameter .............................................................................. 131
11.3 Referencing Parameters in the WebReport Reportview .......................................... 132
11.4 Deleting a WebReport Parameter ............................................................................ 133
11.5 Parameter Tab Settings ............................................................................................ 133
11.6 Parameter Types ...................................................................................................... 134
12 Data Source Parameters ................................................................................................... 136
12.1 Overview ................................................................................................................... 136
12.2 Pagination ................................................................................................................. 137
13 Export Parameters ............................................................................................................. 138
13.1 Overview ................................................................................................................... 138
13.2 Exporting to Desktop ................................................................................................ 138
13.3 Exporting to Livelink - Node...................................................................................... 139
13.4 Exporting to Livelink - Version .................................................................................. 139
13.5 Exporting to E-Mail ................................................................................................... 140
13.6 Exporting to a WebForm........................................................................................... 141
13.7 Exporting to a Workflow ............................................................................................ 141
13.8 Exporting to the Livelink Server ................................................................................ 142
14 Logical Expressions .......................................................................................................... 143
14.1 Overview ................................................................................................................... 143
14.2 Order of Evaluation ................................................................................................... 145
15 Sorting Results .................................................................................................................. 147
15.1 Overview ................................................................................................................... 147
15.2 Advanced Notes ....................................................................................................... 148
15.3 Pre-defined Sort Parameters .................................................................................... 148
16 Using Variables .................................................................................................................. 150
16.1 Overview ................................................................................................................... 150
16.2 Advanced Notes ....................................................................................................... 150
17 Using a Search Query as a Data Source ......................................................................... 152
17.1 Overview ................................................................................................................... 152
17.2 Column Names Returned ......................................................................................... 152
17.3 Using Variable Parameters in Search Queries ......................................................... 153
18 Using Category as a Data Source .................................................................................... 154

Page ii
 WebReports User Guide

18.1 Basic Overview ......................................................................................................... 154

18.2 Features of Category as a Data Source ................................................................... 154
18.3 Using Parameters with a Category as a Data Source .............................................. 155
18.4 Category Data Source Actions ................................................................................. 155
19 Requests as Data Sources ................................................................................................ 156
19.1 Basic Overview ......................................................................................................... 156
19.2 Supported Parameters ............................................................................................. 156
19.3 Examples of Requests as Data Sources .................................................................. 157
20 How Reportviews Are Processed ..................................................................................... 158
20.1 Overview ................................................................................................................... 158
20.2 Advanced Notes ....................................................................................................... 158
21 JavaScript Arrays............................................................................................................... 160
21.1 Overview ................................................................................................................... 160
21.2 Generating a JavaScript Array Automatically ........................................................... 160
21.3 Examples .................................................................................................................. 160
22 WR Trigger .......................................................................................................................... 162
22.1 Overview ................................................................................................................... 162
22.2 General Usage ......................................................................................................... 162
22.3 WR Trigger tags ........................................................................................................ 163
22.4 Example .................................................................................................................... 163
23 WR Services ....................................................................................................................... 165
23.1 Overview ................................................................................................................... 165
23.2 Available Services .................................................................................................... 166
23.3 Using the Predefined Functions ............................................................................... 168
23.4 Examples .................................................................................................................. 169
24 Server Side Scripting ......................................................................................................... 172
24.1 Overview ................................................................................................................... 172
24.2 Security ..................................................................................................................... 172
Enabling Scripting for a WebReport ................................................................................ 172
Oscript Restrictions ......................................................................................................... 173
24.3 Recommendations for Developing Scripted Reportviews ........................................ 174
24.4 Defining and Calling a Script .................................................................................... 174
24.5 Passing Data to a Script ........................................................................................... 175
The Context Assoc .......................................................................................................... 175
Passing Parameters ........................................................................................................ 175
24.6 Calling Static Data Tags ........................................................................................... 176
24.7 Calling Sub-tags ....................................................................................................... 177
24.8 Calling Sub-WebReports .......................................................................................... 177
24.9 Script Scope and Calling a Script From Within a Script ........................................... 178
25 WR Power View .................................................................................................................. 180
25.1 Overview ................................................................................................................... 180
25.2 Creating Forms ......................................................................................................... 180
26 Action Sub-tags ................................................................................................................. 181
26.1 Overview ................................................................................................................... 181
26.2 Action Sub-tag Properties......................................................................................... 181
26.3 Display Considerations ............................................................................................. 182
27 Inserting JSON Data .......................................................................................................... 183
27.1 Overview ................................................................................................................... 183

Page iii
 WebReports User Guide

27.2 Basic JSON Structure ............................................................................................... 183

27.3 Tag Syntax and Options ........................................................................................... 183
27.4 Example .................................................................................................................... 186

Page iv
 WebReports User Guide

1 Purpose
This document is a user guide for the Open Text WebReports Standard module. Its purpose
is to provide descriptions of the features provided by WebReports and to enable users to
create useful WebReports as quickly as possible. The intended audience is business users
and developers who wish to create or use WebReports.

WebReports also includes full reference documentation within the Livelink ECM – Enterprise
Server on-line help system. Further help may be found on the Open Text Knowledge Center
including a WebReports discussion group:

https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=3684835&objAction=view

Installation and administration are covered in a separate document. This user guide assumes
that installation has already been completed.

Page 5
 WebReports User Guide

2 Introduction

2.1 Why Use WebReports?

The WebReports module provides the ability to create reports within Livelink that deliver
information from any standard or custom Livelink tables (e.g. Forms data, Workflow data,
Task data, document meta-data, user data, etc.) with any presentation format desired.

For example, WebReports can be used to create:

• Simple reports which require particular colors, format, style or branding.
• Reports containing hyperlinks to your intranet, the internet or other locations in Livelink.
• Reports to present WebForm data including buttons to allow editing of the form data.
• Printer friendly reports.
• Integrated database type applications running within Livelink (WebReports in combination
with WebForms).
• Sophisticated reports requiring complex data manipulation.

WebReports also provide some useful features related to the execution and storage of report
data. For example, WebReports provides:
• The option to export the report output within Livelink to a Livelink Node, a Livelink
Version, a Livelink WebForm or a Livelink Workflow.
• The option to export the report output externally to E-mail, the users’ desktop and if you
are the Livelink Admin user, to the actual Livelink Server.
• The ability to set varying default behaviors for execution.
• The option to schedule reports for delayed delivery of data via email or Livelink storage.
• The option to run reports in the background without holding up the user's browser.

Page 6
 WebReports User Guide

2.2 How Do WebReports Work?

WebReports use data sources such as LiveReports to extract the required data from the
database. Control of the report presentation is achieved through the use of a template (called
a “reportview”) which usually contains standard HTML, and if desired, JavaScript. When run,
the WebReport inserts the source data into the reportview and outputs the result to the
browser or other destination. The result is an extremely powerful and flexible reporting
1
technology which can be safely used by Livelink business users .

The following diagram illustrates the relationships between WebReports, LiveReports and the
Livelink database. WebReports reflects and complements the WebForms and WebForm
Templates paradigm. Users familiar with the concept of a custom view for a WebForm will be
at ease with WebReports, which uses the same approach.

1
LiveReports allow direct access to the Livelink database, so access to creating LiveReports
is nearly always restricted to Administrators. A WebReport does not allow direct database
access (instead it uses existing LiveReports, search queries or other data sources).
Therefore WebReports may be safely used by business users and developers who are not
Administrators.

Page 7
 WebReports User Guide

3 Getting Started Using WebReports

3.1 Overview
The WebReports module provides a new Livelink node type called WebReport, which can be
added to a Livelink workspace from the Add New Item drop down menu. When creating a
new WebReport, the user is prompted to

• Choose a data source on which the WebReport will be based.

• Select a reportview to use as the presentation template for the data source.

A WebReport has all the standard properties of other Livelink nodes, such as a document
node, but it also includes functions appropriate to reporting (for example, Edit Reportview).

3.2 Creating a WebReport

A WebReport is added by selecting WebReport from the standard Livelink Add New Item...
menu. This option brings up the Add: WebReport page. You will be taken to the following
screen:

Add Items< WebReport

This form should be filled out as follows:

Modify the Name field to an appropriate title for the new WebReport. As per all Livelink items,
an optional Description can be added. This information does not appear anywhere in the
WebReport output. The Data Source is an optional field which allows a report source to be
selected. To populate this field, click the Browse Livelink button, navigate to an appropriate
data source and then click its select link. Valid options are:

• LiveReport - the results of a LiveReport query is used.

• Saved Query - the results of a saved query (created from advanced search) is used.
• Form Template - the results of a query to return all the SQL table data associated with the
selected template is used.
• Form - the results of a query to return all SQL table data owned by the selected form is
used.
• Document - a document with either CSV or HTML table based content is used.

Page 8
 WebReports User Guide

• Folder, Compound Document, Task List, Task Group, Channel, Discussion – all show the
children when selected.
• External Application, typically via HTTP.

(Note that if no data source is selected, the row section of the Reportview is ignored.)

If the Go To Source Tab option is selected, after clicking the Add button the Source tab is
displayed so that other non-Livelink data sources can be selected, or more specific data
source settings can be modified.

The Reportview File is a mandatory field. Selecting a reportview from the Use a Default
Reportview drop-down list allows a simple pre-written reportview to be used. This default
reportview can be edited using the Edit Reportview function option once the WebReport has
been created. If a default reportview has not been selected, the Browse... button can be used
to select a pre-written reportview from the user's desktop. Once a file has been selected, the
file details are automatically inserted into the corresponding form field.

The Categories field is optionally used to associate any pre-defined attributes with the newly
created WebReport. The Create In field optionally allows the user to select an alternative
Livelink location to store the new WebReport.

3.3 Editing a Reportview – Online

WebReports provides an online editor for quick and easy modification of the reportview. This
editor is used to create the appropriate look and feel for the WebReport and to insert selected
WebReport tags into the code. If you have just created a WebReport using the default
reportview, you may wish to use the editor in order to modify the report.

The Edit Reportview option in the WebReport function menu opens the reportview editor.
The editor presents the reportview file in three sections: the header, row template, and footer
2
(see the screen shot below) . Section 5.2 of this document explains the purpose of these
sections in more detail.

After making the desired changes to the reportview, clicking Add Version (or Add Version &
Continue) generates a new version of the reportview using the newly edited text. The new
reportview will be used the next time the WebReport is run.

2
Please note the STARTROW and ENDROW tags are not visible. They do NOT need to be
added as the editor will insert them when editing is complete.

Page 9
 WebReports User Guide

Edit Reportview screen

3.4 Adding a New Reportview

It is also possible to create reportviews using standard desktop HTML editing packages, or
text editors outside of Livelink. To add a new version of a reportview created off-line, choose
Add Reportview Version from the Functions menu for the WebReport node.

3.5 Data Source Configuration

WebReports supports several types of data sources. These data sources provide a
WebReport with data when it runs. As an example, a Livelink search can be used. When the
given WebReport runs, it executes the search query associated with it then uses these results
to provide the underlying data that the reportview processes in order to create the output seen
by the end user.

To configure the data source for a WebReport, choose Properties and Source from the
function menu.

Data Source Type Description

Livelink Query This is used for any of the Livelink objects which provide data from
either SQL or search index queries. The most common examples of this

Page 10
 WebReports User Guide

are LiveReports, Saved Queries, Form Templates, WebForms, Folders,

Compound Documents, Task Lists, Task Groups, Channels, and
Discussions. The only configuration required is to browse for the source
object to be used.

Livelink File This allows files within Livelink that have HTML tables or delimited data
to be used as data sources. It provides some configuration parameters
to allow correct interpretation of the data file. These are:

• Static File Location - This allows the user to browse for a

document in Livelink that will be used as the data source.

• File Type - This parameter allows the user to select which file
type is being used as a data source. Currently the two choices
are: Separated Values (CSV, tab delimited etc.) and HTML
Table.

• Content Type - This parameter is only visible when the

Separated Values file type has been selected. It allows the
parsing of the data source to be optimized according to the
content of the file. For example, most delimited formats such as
CSV need some way to allow the delimiter to be stored in the
data without confusing the parsing software. In the example of
CSV, products like Microsoft Excel use quotes to enclose any
data cells which have commas in them. If it is known that a
given file has no delimited cells with quotes then select the No
Cells Are Quoted option which has the fastest performance. If
it is known that a given file has all cells quoted, the All Cells
Are Quoted option should be used. The Some Cells Are
Quoted option is the most robust option to use (and is the best
selection for Excel exports). It should be noted this option is
slower than the first two options.

• Assume Strict Syntax - This parameter allows the user to

specify whether the data source has a strict and predictable
syntax. For example, in a comma separated value file, the
comma in between each cell will not normally be preceded or
succeeded by any spaces. If this is known to be the case, this
option should be checked. For separated value file types (e.g.
CSV) this option is only available for All Cells Are Quoted and
Some Cells Are Quoted. With HTML files, strict syntax
specifies that all table/row/cell tags will be formed without any
attributes and without any spaces. For example: <TABLE>,
<TR>, <TD>. Regardless of which file type has been selected,
this option should not be used where syntax is unpredictable or
unknown.

• Column Separator - This parameter is only visible when the

Separated Values file type has been selected. It is used to
specify which character will separate each cell of data. For CSV
files this character is always a comma. For tab delimited files
this character would be a tab. The tab link beside this field can
be used to automatically insert a tab (\t).

• Row Separator - This parameter is only visible when the

Separated Values file type has been selected. It is used to
specify which character will separate each row of data. For CSV

Page 11
 WebReports User Guide

files this character is always a carriage return (sometimes called

end of line) or a combination of a carriage return and a linefeed.
Different operating systems may use different variations of
these characters. The links beside this field can be used to
automatically insert characters that cannot be entered via the
keyboard. The convention \t for tab, \r for carriage return/end of
line and \n for new line/line feed is used.

• Quote Character - This parameter is only visible when the

Separated Values file type has been selected. It is used to
specify which character will quote cells. Cells are usually quoted
when the cell data contains the character which is normally
used to separate the data cells. For example, with CSV files, if
the cell data includes a comma then the data is started and
ended with a double quote ("). A double quote is the most likely
character used for quoting, but this parameter allows the ability
to use an alternative character.

• Escape Quote Characters - This parameter is only visible

when the Separated Values file type has been selected. It is
used to specify which characters represent a quote within a
quoted cell. For example, in CSV files if a cell of data is quoted
and a double quote is required within the quoted cell, then the
data quote will be represented as "". Doubling a quote
character is the most common way of escaping it but this
parameter allows the ability to use alternative methods.

Column Headings Included - This parameter is used for both HTML

Table and Separated Values. It is selected when the first row in the
data source includes the headings. When this is not selected, generic
column names are used (Column1, column2 etc.)

Livelink Category This allows Livelink Categories to be used as data sources. One or
more Livelink Categories may be selected. The number of Livelink
Categories that may be selected is limited by the Livelink Administrator.

When a Livelink Category has been selected, the page will refresh and
all of the Category's Attributes will be displayed on the page. Use the
checkboxes to select one or more Attributes to be included in the
report results.

Each record in the report data will include the item DataId, SubType and
a value for each selected Category/Attribute. Multi-valued attributes will
be concatenated using a value delimiter, as defined by the Livelink
Administrator.

Select the Filter Permissions checkbox if you would like the report
results to be limited based on user permissions to SEE each node item.

Use the Attribute Function Menu next to each selected

Category/Attribute, to choose a Query Operator. Selecting a Query
Operator will activate the specified Category/Attribute to be used as a
WebReport Parameter.

Select the View SQL button to view the SQL Query that will be
performed to retrieve the Category/Attribute data.

Page 12
 WebReports User Guide

External File This allows files outside of Livelink (typically in a folder that is visible to
the Livelink server) to be used as data sources. These files must
contain tabular or delimited data as per the Livelink File data source
type and the same configuration options are provided.

FTP This allows files to be accessed via an ftp server. The configuration
options are the same as for the Livelink File data source type with
additional parameters to determine details of the the ftp server.

The supported parameters are:

• FTP Server - The domain or server name to be used for ftp

access.

• FTP File Path - The path to data source file relative to the FTP
Root Folder. E.g. /data.txt.

• FTP Port - The server port configured for FTP access (standard
configuration is port 21).

• Anonymous User Login - Check this Checkbox to user

Anonymous User Authentication. With this option, the Report
User's Email Address will be used as the authentication
password. You should verify the ftp server is configured to allow
anonymous user access prior to using this option.
Uncheck this Checkbox to display FTP User Name and FTP
Password Data Input fields.

• FTP User Name - The FTP User Name for Authentication on

the FTP Server. Use this option when not using Anonymous
User Login option.

• FTP Password - The FTP User Password for Authentication on

the FTP Server. Use this option when not using Anonymous
User Login option.

Important Notes:

The ftp server should provide access to a file in the correct format.
Depending on the source operating system and type of file being
transferred, the Row Separator value may vary from "r\n" and "\n" for
proper display of results.

The FTP File Transfer is performed in Binary Mode using a Passive

FTP Connection. Contact a system administrator to determine if this
will require FTP Server and Firewall configuration.

External Application This allows files to be accessed via an external server (usually a Web
Server). The configuration options are the same as for the Livelink File
data source type with additional parameters to determine details of the
external server. The external server should either provide access to a
file in the correct format, or to an appropriate server side script to invoke
software necessary to return a file in the correct format. The supported
parameters are:

• Server - The domain or server name to be used for accessing

Page 13
 WebReports User Guide

the external application

• Server Path - The fully formed file path (can include URL
parameters) to access the application

• Server Port - The port used to access the server

Search Query Launch This is used to define WebReports that can be invoked from the
standard Livelink search launch screen. This is the screen that users
normally see when they select Advanced Search in Livelink.
WebReports using Search Query Launch will be available and listed for
any users that have the appropriate permissions. No additional
parameters are required.

None This is selected when no data source is required. No parameters are

required.

Request Datasource This datasource can not be selected from the Source tab. It is
implementented by providing data in predetermined parameters when a
WebReport is invoked.

3.6 Changing the associated Data Source for a WebReport

To change a WebReport’s associated data source choose Properties and Source from the
function menu for the WebReport node. This screen allows you to select a new data source
using the standard Livelink browser. Once this form has been updated any future executions
of this WebReport will use whichever data source has been selected using the browser.

WebReport Source Properties

Page 14
 WebReports User Guide

3.7 Property Tabs

As with all Livelink items, WebReports have a Properties page, accessible from the item's
function drop down menu. In addition to the standard Livelink tabs there are some unique
tabs which allow control over WebReport sources, destinations, constants and parameters.
The basic features of these tabs and the Specific tab are described here.

Specific

The specific tab for a WebReport is similar in functionality to the specific tab for a document.
The document properties such as Current Version, Max Versions and MIME Type are used to
manage version control for the Reportview associated with the WebReport. Besides these
options there is always one additional option called Run/Export Audits Enabled. This option is
unchecked by default and allows each WebReport to have additional audit events enabled so
that every RUN or EXPORT event will generate an entry in the AUDIT log.

In some cases there may also be an additional option called Oscript Scripting Enabled. This
option will only appear when the Reportview includes tags related to the Server Side Scripting
feature. It is used to enable or disable the execution of any scripts which may be defined and
executed with the Reportview.

Constants

The Constants tab allows the creation and management of values that can be used in the
Reportview (or other designated fields).

Destination

The Destination tab allows the developer to specify where a report is delivered to. This could
be email, workflow initiation, or several other destinations.

Parameters

The Parameters tab allows the developer to define parameter behavior for the WebReport.
This is used to control things like the prompt order, the default value and whether a parameter
is mandatory or not.

Source

The source tab allows the developer to specify different types of data sources and the format
which the source data will appear in.

3.8 WebReports “Run As” Feature

“Run As” Overview

This feature enables a WebReport developer to specify which user the WebReport should run
as. Everytime the report is run, it will be executed using the specified user's permissions and
UserID.

As an example, any files that the Run As user doesn't have permissions to "See" will not show
up in the output, regardless of who executes the WebReport. Each WebReport can have its
own "Run As" setting, which can be set on the Specific tab of any WebReport (Function Menu
> Properties > Specific). For security reasons, this feature can only be enabled by a user with
Admin privileges.

Page 15
 WebReports User Guide

Enabling this Feature

On the Specific tab of the WebReport, click the user icon ( ) next to the "Run As" field:

In the User selection window, choose the user that will be used to run this report. Click the
Update button to save your changes.

The next time this report is run, it will be run as if the user in the Run As field executed it. All
permissions and any tags within the WebReport will be run like it was executed by the Run As
user. This includes tags like [LL_REPTAG_USERID /] - no matter who runs the report, this tag
will always resolve to the USERID of the Run As user for that WebReport.

Page 16
 WebReports User Guide

4 Running WebReports

4.1 Overview
By default, running a WebReport causes the combined output of the processed reportview
and any data source to be delivered to the user's browser. WebReports can also be
'delivered' to other destinations using a variety of Export options. There are three co
commonly
used ways to run a WebReport:

• Selecting the WebReport link from Livelink. Where a WebReport is visible in a Livelink
container, the name link can be clicked to run the current version of the WebReport. This
approach can also be used for versions that have been listed using the Properties->
Properties
Versions option from the function menu of a WebReport object. This differs from normal
documents where this action would cause a view or open option to be executed. Note:
the behavior of the WebReport link can be altered by chchanging
anging the defaults through the
Destination tab.
Properties->Destination
• Selecting the Open option from the function menu . This performs the same action as
clicking the name link.
• Invoking the appropriate WebReport URL. This option can be used to create complex
relationships between different objects in Livelink. For example, a Livelink customview
c
can invoke a WebReport to collect data for display; a Livelink WebForm
WebForm could invoke a
WebReport to build form information such as pick lists etc.; a WebReport can invoke
another WebReport to create relational database type applications. This option can also
be used to invoke a WebReport from a Livelink URL object. The reasoneason for using this
approach is that it is possible to create unique URLs which include parameters that can
be used in the reportview. Any parameters passed in the URL can be referenced within
the reportview using special tags (e.g. [LL_REPTAG_&parmname /]). ). Thus multiple
URLs can be created to allow a single WebReport to behave in different ways. It is also
possible to include input parameters to be passed directly to the underlying data sources
(see below).

4.2 Passing Parameters

When running a WebReport
WebReport, parameters
arameters can be included in the URL for the WebReport itself
as well as for the associated data source. Information about Parameters can be found in
Chapter 11 of this document.

4.3 Form Submission Mechanism

WebReports provides a form submission mechanism, "Initiate WebReport", that is similar to
"SQL Table", the main differences being that when the data is stored in the SQL table, the
primary key, or SEQ, is identified and passed to a WebReport which is initi
initiated
ated straight after
the form submission. The data stored in each method is interchangeable - i.e. it is possible to
change the form submission mechanism between "Initiate WebReport" and "SQL Table"
without affecting the existing data.

Initiate WebReport requires only two configuration options which are set on the specific tab of
the form.

• The WebReport that is to be executed immediately following form submission

 WebReports User Guide

• A checkbox to determine whether the WebReport is executed transparently or is

presented to the user following form submission

In each case the SEQ from the form just submitted is available as a parameter
[LL_REPTAG_&SEQ /]. This can be used in the WebReport as a key to lookup additional data
associated with the form just submitted or it can be passed as a parameter to a separate
(sub) WebReport which has it's destination set to "Populate Form". This allows basic
relational tables to be maintained through a series of WebReports as the act of using a
WebReport to export data to a form will cause a further WebReport to initiate if the
submission mechanism is set appropriately.

The Initiate WebReport form submission mechanism is not visible until the "Manage
Relational Table" option has been used to configure an associated SQL table.

Form tags of the type [LL_FormTag_1_1_3_1 /] are support only when "Show WebReport" is
not selected. If needing to display data just submitted with "Show WebReport" checked then
the tag [LL_REPTAG_&SEQ /] must be used as a parameter to a sub WebReport/LiveReport
to retrieve the submitted data.

Page 18
 WebReports User Guide

5 Reportview File

5.1 Overview
The reportview is a template for formatting the data source. It may be any language or syntax
that is supported by the end user's application (e.g. HTML, JavaScript, SpreadsheetML, etc.)
to build the structure and appearance of the output document. In order to be useful it must
also contain WebReport Tags which are similar to the format used by Livelink WebForms.

• A reportview is a file, often in HTML format, containing special tags which define how and
where data from Livelink should be inserted.
• Any text editor can be used to create the reportview.
• The standard Livelink header (including the dashboard and menus) is added to the
reportview by default but can be disabled using the
[LL_WEBREPORT_EXCLUDEHEADER /] tag.
• The standard Livelink footer is added to the reportview by default but can be disabled
using the [LL_WEBREPORT_EXCLUDEFOOTER /] tag.

5.2 Structure of the Reportview

The reportview consists of the following:

• Header Section - This section is used to provide any code that should be executed at the
beginning of the WebReport. It is only output once regardless of how many report rows
are being read from the underlying data source. For example if producing an HTML
document any opening tags like <TABLE> should be in this section; however, it is not
necessary to include <HTML> or <BODY> if the standard Livelink header is being
included. The Livelink header is included by default unless the
[LL_WEBREPORT_EXCLUDEHEADER /] tag is used.
• [LL_WEBREPORT_STARTROW /] – In the online editor this line cannot be edited. It is
only provided to show where the start row tag will be inserted so that users do not try to
add another one.
• Row Section - This section is used to define any code that should be applied to all data
rows. Any tags that are used to refer to data source column data will only work in this
section. It is important to note that anything in this section will be repeated for every row
of the data source. For example, if there are 10 rows of report data to be returned,
everything in this section will appear 10 times in the output of the WebReport. The only
exception to this is if conditional tags are used to exclude some data from the output.
(See the Tag Guide in chapter 6 for more information).
• [LL_WEBREPORT_ENDROW /] – In the online editor this line cannot be edited. It is only
provided to show where the end row tag will be inserted so that users do not try to add
another one.
• Footer Section - This section is used to provide any code that should be executed at the
end of the WebReport. It is only output once regardless of how many report rows are
being read from the underlying data source. Any closing HTML tags like </TABLE> would
normally be in this section.

Page 19
 WebReports User Guide

Reportview Structure

Header section output once at the

HEADER SECTION start of the Report. Can be used
to declare JavaScript functions or
define Cascading Style Sheets.

[LL_WEBREPORT_STARTROW /]

ROW TEMPLATE SECTION

Row template repeated once for each
row of data in the data set. Data tags
are included here to determine where
data from particular columns should
appear.

[LL_WEBREPORT_ENDROW /]
FOOTER SECTION Footer section is output
once at the end of the
Report.

5.3 Example Reportview

An example of a simple reportview file follows, in which tags appear in bold. In this example
the report generates a summary of customer issues that have been captured using workflows
and forms. The data source in this case is a LiveReport. Note how the tags in the row
template section specify which LiveReport column to obtain the data from. They do this by
specifying the column number [LL_REPTAG_1 /] or by specifying the LiveReport column
name [LL_REPTAG=Customer /]:

Page 20
 WebReports User Guide

Example reportview:

<HTML>
<HEAD>
<TITLE>Sample Report</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
<CENTER><H1>Sample Report</H1></CENTER>
<P><SMALL>Created by [LL_REPTAG_USERFULLNAME /], Username: [LL_REPTAG_USERNAME /]</SMALL></P>
<HR>
<TABLE BGCOLOR="#FFFFFF" BORDER="3" CELLPADDING="1" CELLSPACING="1" WIDTH="100%">
<TR BGCOLOR="#CCCCCC">
<TD ALIGN="CENTER" NOWRAP VALIGN="MIDDLE">ID</TD>
<TD ALIGN="CENTER" NOWRAP VALIGN="MIDDLE">Issue Title</TD>
<TD ALIGN="CENTER" NOWRAP VALIGN="MIDDLE">Issue Type</TD>
<TD ALIGN="CENTER" NOWRAP VALIGN="MIDDLE">Customer Name</TD>
<TD ALIGN="CENTER" NOWRAP VALIGN="MIDDLE" WIDTH="30%">Activity Record</TD>
<TD ALIGN="CENTER" NOWRAP VALIGN="MIDDLE">Form Link</TD>
</TR>
[LL_WEBREPORT_STARTROW /]
<TR>
<TD ALIGN="LEFT" NOWRAP VALIGN="MIDDLE">
&nbsp;[LL_REPTAG_1 /]
</TD>

<TD ALIGN="LEFT" NOWRAP VALIGN="MIDDLE">

&nbsp;[LL_REPTAG_2 CAPITALIZE /]
</TD>

<TD ALIGN="LEFT" VALIGN="MIDDLE">

&nbsp;[LL_REPTAG_3 UPPER /]
</TD>

<TD ALIGN="LEFT" VALIGN="MIDDLE">

&nbsp;[LL_REPTAG=Customer /]
</TD>

<TD ALIGN="LEFT" VALIGN="MIDDLE">

&nbsp;[LL_REPTAG=ActivityRecord HTMLCR /]
</TD>

<TD ALIGN="LEFT" >

<A HREF="[LL_REPTAG_URLPREFIX /][LL_REPTAG=VolumeID LLURL:FORMEDIT:1
/]&nexturl=[LL_REPTAG_MYURL ESCAPEURL /]">Edit form</A>
</TD>
</TR>

[LL_WEBREPORT_ENDROW /]

</TABLE>
<HR>
</BODY>
</HTML>

<P><SMALL>Created on ... [LL_REPTAG_DATE /]</SMALL></P>

</BODY>
</HTML>

Page 21
 WebReports User Guide

5.4 Default Reportviews

When adding a new WebReport to Livelink, the user is given the option of selecting a default
reportview. Default reportviews provide a variety of generic starting points which can be used
for developing a WebReport. Some reportviews may be useful immediately but in other cases
it will be necessary to edit them to meet specific requirements. Once a WebReport has been
created using a default reportview, the user can either edit the reportview online, or download
the reportview for editing on their desktop. These default reportviews are provided when the
WebReports module is installed; however, a Livelink administrator can modify them to provide
a company look and feel.

Pre-packaged Reportviews

Reportview Name Location Description

This reportview is designed to be
no frills. In terms of speed, it should
be the fastest of the HTML
reportviews as it contains less
HTML and fewer sub-tags. If you
basic_report defaultreportviews
want a very simple preformatted
report to open in MS Excel, remove
the function menu and other
graphics then set the mime type to
application/vnd.ms.excel.
As above but utilizing Oscript in the
reportview. Useful as a starting
basic_scripted defaultreportviews
point for reports using server side
scripting.
This is simply a blank reportview
blank_report defaultreportviews that the developer can use for
creating something from scratch.
This reportview is designed to
browse_flexible_CS10 defaultreportviews mimic the standard Content Server
10 folder browse functionality.
This reportview is designed to
browse_flexible_971 defaultreportviews mimic the standard Livelink 9.7.1
folder browse functionality.
This reportview is designed to
mimic the standard Livelink 9.7.0
folder browse functionality. In
addition to Copy, Move and Delete
operations, it also allows the user
browse_97 defaultreportviews to perform multi-file output
operations such as Zip and
Download, Zip and Email, and Print
on data from different locations as
though it were located within the
same folder.
This reportview is designed to
mimic the standard Livelink 9.5 and
Livelink 9.6 folder browse
functionality. It allows the user to
browse_95_96 defaultreportviews
perform Copy, Move and Delete
operations on data from different
locations as though it were located
within the same folder.
This reportview will output your
csv_report defaultreportviews data in a CSV format. Double
quotes are used as the escape

Page 22
 WebReports User Guide

sequence.
As above but utilizing Oscript in the
csv_scripted defaultreportviews reportview to handle any number of
columns.
This reportview provides a
replacement to the WebForms List
Data functionality. The reportview
form_report defaultreportviews
also provides appropriately
permissioned links for the editing
and deletion of form data
This is an advanced reportview that
contains server side scripting (this
will need to be enabled by your
administrator). The reportview
form_scripted defaultreportviews
provides the user with dynamic
columns and filters meaning that it
can be applied to a form data
source with any number of fields.
A no frills HTML reportview giving
results in a tabulated format that
plainhtml_report defaultreportviews can be readily interpreted by
WebReports if the output were to
be used as a data source.
This reportview is a basic example
of SpreadsheetML with little
formatting. It places report data into
a simple table. The resulting file is
a complete and portable document
spreadsheetml_report defaultreportviews
that by default opens in MS Excel.
Note for Excel to open by default
the destination mime type must be
set to text/xml or
application/vnd.ms-excel.
Allows WebReports to view Livelink
data in a preformatted Word
document using WordML. This
format is only supported by newer
wordml_report defaultreportviews
versions of Microsoft Office. Note
that the destination mime type must
be set to application/msword or
text/xml for Word to open.
A very simple XML report that
might be used in an Ajax type
situation to pull back additional data
xml_report defaultreportviews to an application. It is important to
remember to set the destination
mime type to text/xml in this
situation.
Similar to the browse views in the
defaultreportviews folder but
contains optional drag and drop
functionality by providing a tab at
browse_97_drag&drop_report defaultreportviews
the top of the report; this is meant
to be used with one of the
draganddrop_view_webdav
reportviews.
This creates a page similar to the
drag and drop page provided by
draganddrop_view_webdav100_CS10 defaultreportviews
WebDAV, for use on Livelink
instances running WebDAV 10.0. It

Page 23
 WebReports User Guide

is designed to be called from a

WebReport similar to the
browse_97_drag&drop_report
reportview, which provides a way to
access drag and drop from a
WebReport.
Similar to the browse views in the
defaultreportviews folder but makes
browse_5.0.1 examplereportviews use of the new SORT
enhancements available in
WebReports 5.0.1.
Similar to the browse views in the
defaultreportviews folder but sorting
browse_jssort examplereportviews
with JavaScript rather than
additional requests.
This reportview is an example of
WordML with formatting and
images. It contains a cover page,
followed by a table containing the
report data. The resulting file is a
complete and portable document
that by default opens in Microsoft
wordml_adv examplereportviews
Word. The possibilities for
formatting are extensive, and this
serves as an example of some
features. Note that you must set the
destination mime type to
application/msword or text/xml to
have the report open in word.
Advanced SpreadsheetML example
containing a coversheet with
spreadsheetml_adv examplereportviews
company data and a separate
worksheet with the report data.

Note that only reportviews contained in the defaultreportviews folder are available for
selection when a user creates a new WebReport. The reportviews in this folder can be
changed by the administrator. As an example, you could move one or all of the reportviews in
the examplereportviews folder into the defaultreportviews folder then all would be available on
the Add New WebReport screen.

The location field in the table above refers to a folder on the Livelink server. This is accessed
via <install path>module\webreports_5_x_x\ though this will only be available to the Livelink
administrator.

Page 24
 WebReports User Guide

6 Reportview Tags

6.1 Overview
This section describes the different types of tags that can be used in WebReports:
1. Content Control Tags

These tags are always prefixed with: [LL_WEBREPORT_. They are used to control the way
in which the output content is built. For example, it is possible to enable or disable the
standard Livelink header and footer. The most important content control tags are used to
define which part of the reportview is applied to each row of data source Data.
2. Data Tags

Data tags are always prefixed with: [LL_REPTAG. They can further be broken down into
Column Data Tags and Static Data Tags:
a. Column Data Tags

For every column in the associated data source, column data tags exist to reference
which pieces of report data are to be included in the output. These tags allow either
the column number (e.g. [LL_REPTAG_2 /]) or the column name (e.g.
[LL_REPTAG=DATAID /]) to be used.
b. Static Data Tags

Static tags are used to insert information from Livelink that is not associated with
report rows. For example, the date and time, the name of the user running the
WebReport, or various URLs that might help with building hyperlinks in the report
output. (E.g. [LL_REPTAG_NEXTURL /]).
3. Sub-tags

Sub-tags are used to provide formatting or additional functions with any of the
[LL_REPTAG... tags. These sub-tags, separated by spaces, allow actions to be taken on the
actual data pulled from the data source. Further information about sub-tags can be found in
section 6.2.3.

All tags are case sensitive (always use uppercase) and space sensitive (ensure there is a
space before the “/]” at the end of the tag); however, column names can be mixed case. The
table in section 6.2 lists all of the tags currently available in WebReports and describes their
use.

Page 25
 WebReports User Guide

6.2 Tag Definitions

The following tables describe the tags recognized by WebReports. Not all tags are supported
in all sections of the reportview. The supported sections (header, row template, footer) are
indicated beneath each tag name.

6.2.1 Content Control Tags

Tag name Description

[LL_WEBREPORT_APPEARLEFTOFF /] Excludes any Appearance HTML elements to the

left.
Support: header

[LL_WEBREPORT_APPEARRIGHTOFF /] Excludes any Appearance HTML elements to the

right.
Support: header

[LL_WEBREPORT_APPEARBOTTOMOFF /] Excludes any Appearance HTML elements at the

bottom, bottom left and bottom right.
Support: header

[LL_WEBREPORT_APPEARTOPOFF /] Excludes any Appearance HTML elements at the

top, top left and top right.
Support: header

[LL_WEBREPORT_APPEARTOPHEADEROFF Excludes any Appearance HTML elements at the

/] very top.

Support: header

[LL_WEBREPORT_CALL Calls a script defined using

NAME:<Script Name> [LL_WEBREPORT_STARTSCRIPT /] and
PARM:<parm1>:<parm2>:<parm3> etc. /] [LL_WEBREPORT_ENDSCRIPT /]. Optionally, any
number of parameters can be passed to the script
Support: header using the PARM parameter. Note that script calls
will be ignored by WebReports until scripting has
been enabled for any new reportview version by a
System Administrator.

Before using this tag, please read all the related

documentation in chapter 22.

[LL_WEBREPORT_ENDROW /] Marks the end of the report row template. Note:

when online editing is used, this tag is automatically
inserted and is not visible in the source of the
reportview.

Page 26
 WebReports User Guide

[LL_WEBREPORT_ENDSCRIPT /] Marks the end of a section of Oscript within the

reportview. Oscript within a reportview is, by
Support: header, row, footer default, tightly secured and constrained to make it
safe. However it is recommended that WebReports
with Oscript are developed and tested on a
development server before being moved to a
production Livelink instance.

Before using this tag, please read all the related

documentation in chapter 22.

[LL_WEBREPORT_EXCLUDEFOOTER /] Excludes the standard Livelink footer from the

output.
Support: header

[LL_WEBREPORT_EXCLUDEHEADER /] Excludes the standard Livelink header from the

output
Support: header

[LL_WEBREPORT_EXCLUDEHTML /] Excludes all the HTML, JavaScript and Style

definitions that Livelink uses to wrap any given
Support: header page. This can be used to good effect when
exporting, e.g. XML or CSV as the Livelink page
wrapping is no longer relevant. When this option is
used, all other EXCLUDE tags will be ignored as
they are not relevant unless in the context of a
Livelink page.

[LL_WEBREPORT_EXCLUDEMENU /] Excludes the Personal and Enterprise menus etc.

Support: header

[LL_WEBREPORT_EXCLUDESEARCH /] Excludes the Livelink search bar.

Support: header

[LL_WEBREPORT_EXCLUDETITLE /] Excludes the top bar which includes the ‘Powered

By Livelink’ icon.
Support: header

Page 27
 WebReports User Guide

[LL_WEBREPORT_EXITIF (expression) /] Causes the processing of rows to stop when a

condition is met. If the specified expression
(expression) Format: evaluates to TRUE, then no more rows will be
"parmA" <operator> "parmB" <optional included in the output. The current row being
clauses> processed is not included if the expression
evaluates to true. For example:
Support: row [LL_WEBREPORT_EXITIF
"[LL_REPTAG_ROWNUM /]" == "10" /]

In this example, rows numbered 1 to 9 will be

output but not row 10. Note: this is the only
conditional tag where it is safe to use the
ROWNUM tag in an expression. This tag only
works in the row section – i.e. between the
[LL_WEBREPORT_STARTROW /] and
[LL_WEBREPORT_ENDROW /] tags.

(See also chapter 14 for more detail)

• This tag does not change the TOTALROWS tag which will always reflect the number of rows that
were actually available from the database table. To access the number of rows which are
actually returned (i.e. that pass the conditional test), the ACTUALROWS tag should be used.
See the specific syntax information for these tags.
• ParmA and parmB can be either text or another report tag (all other tags are resolved first)
• The parameters must be enclosed inside double quotation marks.
• Operators can be one of the following:
o == (equal)
o != (not equal)
o <> (not equal)
o <= (parmA is less than or equal to parmB)
o >= (parmA is greater than or equal to parmB)
o IN (parmA text is contained in parmB text; case insensitive search)
o NOTIN (parmA text is NOT contained in parmB text; case insensitive search)
o CHILDOF (parmA node is a child of the parmB node; where both parms are nodes)
o NOTCHILDOF (parmA node is not a child of the parmB node; where both parms are
nodes)
o STARTIN (string parmB starts with the string parmA)
• Additional, optional clauses are added using one of the following operators:
o AND (logical AND)
o && (alternative AND)
o OR (logical OR)
o || (alternative OR)
• The <= or >= operators will do an integer comparison if both parms are integers, otherwise a
string comparison is performed
• The <= or >= operators will do an integer comparison if both parms are integers, otherwise a
string comparison is performed
• If either parameter is an empty string, the IN and CHILDOF operators will return true. The
NOTIN and NOTCHILDOF operators will return false if either parameter is an empty string.
• When using the CHILDOF or NOTCHILDOF operators if either parm is not a valid Livelink object
number (ID) then CHILDOF will return false and NOTCHILDOF will return true

Expression Examples:
[LL_WEBREPORT_EXITIF "[LL_REPTAG_&var1 /]" != "[LL_REPTAG=DATAID /]" /]
[LL_WEBREPORT_EXITIF "[LL_REPTAG_ROWNUM /]" == "101" /]
[LL_WEBREPORT_EXITIF "[LL_REPTAG=dataid /]" NOTCHILDOF "[LL_REPTAG_&rootid /]" OR
"[LL_REPTAG=parentid /]" NOTCHILDOF "[LL_REPTAG_&rootid /]" /]

Page 28
 WebReports User Guide

[LL_WEBREPORT_FORCEUTF8 /] This tag forces a UTF-8 Byte Order Marker (BOM)

to be added to the beginning of the output from the
Support: header WebReport. The BOM is made of of the hex
characters: #FE #BB #BF. Some client applications
may require this marker to correctly handle UTF-8
content.

[LL_WEBREPORT_FORMPARSEOFF /] This tag is only used when working with

WebReports in forms (via the WR Power View
Support: header option in form templates). It stops forms code
processing tags like LL_FormTag_ and forces
WebReports to do it. This can be useful when
working with complex data causing forms code
problems. It should be noted that WebReports does
not handle multi-value or set replacement. Also
loops are not supported with this tag. For more
information see WR Power View in Chapter 25

[LL_WEBREPORT_IF (expression) /] If a condition is met, include the contents in the

[LL_WEBREPORT_ELSE /] (optional) output. Anything between the IF and ENDIF tags
[LL_WEBREPORT_ENDIF /] will only be included if the specified condition
evaluates to true. If an ELSE clause is included
(expression) Format: then everything between the ELSE tag and the
"parmA" <operator> "parmB" ENDIF tag are included if the specified condition
evaluates to false. This tag differs from the
Support: header, row, footer INCLUDEIF tag in that this structure allows
selected parts of the row to be conditionally
included or excluded. This tag can be used
anywhere in the reportview. When including or
excluding the whole row section always use the
INCLUDEIF tag rather than IF as this will give
better performance.

See notes for the EXITIF / INCLUDEIF tags or

chapter 14 for more detail.

[LL_WEBREPORT_INCLUDEIF (expression) /] Used to determine whether or not a row of data will

be included. If this condition is TRUE, then the
(expression) Format: whole row will be included, otherwise the whole row
"parmA" <operator> "parmB" <optional will be ignored. It is possible to use multiple
clauses> INCLUDEIF tags to create a series of conditional
gates. Multiple INCLUDEIFs behave as if the
Support: row conditions are ANDed together (not ORed), i.e. the
more INCLUDEIFs used, the more restricted the
report. This tag only works in the row template – i.e.
between the [LL_WEBREPORT_STARTROW /]
and [LL_WEBREPORT_ENDROW /] tags.

Page 29
 WebReports User Guide

(See Additional notes for the EXITIF tag or chapter 14 for more detail)

• This tag affects the number of rows that are actually returned and displayed. For this reason, this
tag has an impact on the ROWNUM tag which should not be used as part of the conditional logic
for INCLUDEIF.
• This tag does not change the TOTALROWS tag which will always reflect the number of rows that
were actually available from the database table. To access the number of rows which are
actually returned (i.e. that pass the conditional test), the ACTUALROWS tag should be used.
See the specific syntax information for these tags.

Expression Examples:
[LL_WEBREPORT_INCLUDEIF "[LL_REPTAG_&var1 /]" != "[LL_REPTAG=DATAID /]" /]
[LL_WEBREPORT_INCLUDEIF "Admin" == "[LL_REPTAG_USERNAME /]" /]
[LL_WEBREPORT_INCLUDEIF "1234" NOTIN "[LL_REPTAG_1 /]" /]
[LL_WEBREPORT_INCLUDEIF "*DELETED*" IN "[LL_REPTAG=keyfield /]" /]
[LL_WEBREPORT_INCLUDEIF "[LL_REPTAG_1 LENGTH /]" >= "10" AND "[LL_REPTAG=dataid /]"
CHILDOF "[LL_REPTAG_&rootid /]" /]

Used to limit the rows returned by the WebReport

[LL_WEBREPORT_INCLUDEDISTINCT to so that only unique key values are returned.
<distinct key> /]
The "Distinct Key" value specifies which column (or
Distinct Key WebReports data tag) should be unique. Only rows
The distinct key can be either: a column name, a from the data source that result in a unique value
column number or a WebReports Tag/Sub-tag for this key will be included. Any rows that result in
combination. the same value for the specified key will be
discarded.
Support: row

Page 30
 WebReports User Guide

Notes:
• The matching for Distinct Keys is Case Insensitive
• Where there are rows with duplicate keys, the first row in the current order is kept and all
subsequent rows are discarded
• The order of rows used for duplicate comparison is based on the original data source order and
any WebReport SORT tags that are included in the row section
• The filtering of rows using this tag occurs before other row filter tags such as INCLUDEIF,
EXITIF and INCLUDERANGE

For example, given the following data set:

DataID Fruitname
12345 Apple
12346 Orange
12347 Apple
12348 Banana
12349 Orange
12350 APPLE

If the row section had an INCLUDEDISTINCT filter such as:

[LL_WEBREPORT_INCLUDEDISTINCT "FruitName" /]

This would result in only rows that had a unique value in the "FruitName" column:

DataID Fruitname
12345 Apple
12346 Orange
12348 Banana

The same result would occur if the column number 1 was used, e.g.:
[LL_WEBREPORT_INCLUDEDISTINCT "1" /] This tag also supports the use of WebReports tag/sub-
tag combinations. For example, using the original data example and this tag:

[LL_WEBREPORT_INCLUDEDISTINCT "[LL_REPTAG=FruitName DECODE:Banana:apple /]" /]

The following rows would remain after the filter was executed:

DataID Fruitname
12345 Apple
12346 Orange

In this example, the WebReports sub-tag DECODE converts any data that matches the string "Banana"
to "apple". As the data value "Apple" already exists in a previous row, the row that normally has the value
"Banana" in this column is no longer unique. This feature is most useful when sub-tags such as
NODEINFO and or CAT are used to translate dataid fields into other related data values that might not
be unique.

[LL_WEBREPORT_INCLUDERANGE Used to limit the returned rows to a limited range of

STARTROW:n ENDROW:n MAXROWS:n /] rows according to specified parameters.

Support: row The number of rows being restricted is calculated

after any other row filters (such as INCLUDEIF)
have been evaluated.

Page 31
 WebReports User Guide

Notes:

At least one of the optional parameters: STARTROW:, ENDROW: or MAXROWS: must be specified.
These are treated as follows:

• If only STARTROW is specified (no MAXROWS or ENDROW parameters are included) then
ENDROW is assumed to be the last row of the data set
• If no STARTROW is specified then the first row in the data set is assumed as the starting point
• If MAXROWS and ENDROW are both specified then the more restrictive of these two
parameters is used. E.g. if STARTROW=1, ENDROW=10 and MAXROWS=5 only 5 rows would
be returned rather than 10
• If the STARTROW is less than 1 then 1 is assumed
• If the STARTROW is greater than the total number of rows in the data set then no rows will be
returned
• If the ENDROW is less than the STARTROW then no rows will be returned

The range of rows being returned is calculated after any other row filters (e.g. INCLUDEIF, EXITIF) have
been evaluated. For example, given the following source data set:

Source
Data
Row#
1 Apple
2 Orange
3 Pear
4 Banana
5 Strawberry
6 Mango

If the row section had an INCLUDIF filter tag such as:

[LL_WEBREPORT_INCLUDEIF "[LL_REPTAG_SOURCEROWNUM ODDEVEN /]" == "EVEN" /]

This would result in only even row numbers being returned. E.g.:

Source
Data
Row#
2 Orange
4 Banana
6 Mango

If an INCLUDERANGE filter was also used, then this set of rows is whittled down further. E.g. :

[LL_WEBREPORT_INCLUDERANGE STARTROW:2 MAXROWS:2 /]

This would result in only 2 rows being returned, starting with row 2 from the data set returned after any
INCLUDEIF or EXITIF tags have been processed. Using the previous table examples, this set would be:

Source
Data
Row#
4 Banana
6 Mango

Page 32
 WebReports User Guide

[LL_WEBREPORT_INSERTJSARRAY Used to automatically insert a JavaScript array with

ARRAYNAME:<Optional Array Name> all of the report data arranged in a multi-
MULTIVALUE:<Column Name> /] dimensional array.

Support: row This will normally create an array called repData

which is indexed numerically by row and column. It
also creates a set of constants to allow the columns
to be referenced. E.g. to reference the dataid
column for a row of data the following could be
used: document.write(repData[row][DATAID]);

It is also possible to use an alternative array name

using the ARRAYNAME: parameter. The
MULTIVALUE: parameter can be used when one
single column of a table is unique and the other
columns are repeated.

For additional information about using this tag see

chapter 21.
Used to automatically insert Livelink data into the
[LL_WEBREPORT_INSERTJSON output formatted as a JSON structure.
<multiple directives> /]
This tag supports a variety of directives that specify
Support: header, row, footer options regarding what data and formats to use.
The available directives are:

@BROWSECOLUMNS, @ALLDATASOURCE,
@ALLSTATIC, @ROWCOLUMNS, @FIELDS,
@ADDJSVAR, @ESCAPETEXT, @EXCLUSIVE

[LL_WEBREPORT_JSLIBS <list of libraries> /] This tag supports one or more quoted library
selectors (e.g. "COREMENU") that determine which
Support: header JavaScript libraries to insert into the output. The
libraries currently available are:

Page 33
 WebReports User Guide

INSERTJSLIBS library options:

Library Description

(global.js,globalmenu.js,globalmenus.js,newsticker.js,functionmenu.js,menu.js)
BASE
Basic libraries used for standard Livelink menus and functions.

(checkall.js)
BASICBROWSE
Functionality related to multi object selection

(browsecoretable.js)
BROWSE
New functions (as of Livelink 9.7.1) used for browseview

(browsecorermenu.js)
COREMENU
New menu functionality (as of Livelink 9.7.1)

(otutilities.js)
COREUTIL
Miscellaneous utilities

(otajaxsupport.js)
COREAJAX
Ajax utilities

(minipaginationcontrol.js)
PAGINATE
Controls/functions used to display pagination options (as of Livelink 9.7.1)

(search.js,searchbar.js)
SEARCHBROKER
Search result utilities

The libraries currently available for Content Server 10 and greater are: (COREMENU and PAGINATE are
obsolete. Use BROWSE and COREAJAX instead.)

(webdav/global.js, menu.js)
BASE Basic libraries used for standard Content Server menus and
functions.

(checkall.js)
BASICBROWSE
Functionality related to multi object selection

(webnode/browsecoretable_en_US.js, webnode/browse.js)
BROWSE
Functions used for browseview

(core/ot_utilities.js)
COREUTIL
Miscellaneous utilities

(core/ajax_dhtml_util.js)
COREAJAX
Ajax utilties

(websbroker/search.js, websbroker/sortwidget.js)
SEARCHBROKER
Search result utilities

Page 34
 WebReports User Guide

[LL_WEBREPORT_RUNIF (expression) /] Causes the processing of a WebReport to be

aborted if a condition is met. If the specified
Support: header expression evaluates to FALSE, then the data
source is not run and no processing of the
WebReport occurs. For example:
[LL_WEBREPORT_RUNIF
"[LL_REPTAG_$GROUPA USERINGROUP /]" ==
"TRUE" /]
In this example, if the user running the report is not
in group A (as referenced by a constant) then the
report does not run. This tag only works in the
header section i.e. before the
[LL_WEBREPORT_STARTROW /] tag.

[LL_WEBREPORT_SORT "<Sort Key>": Used to sort the report data set according to a
[ASC/DESC] specified column. This tag must be used in the row
template section (between the STARTROW and
<Additional Sort Keys> [Global Direction] ENDROW tags). The column to be sorted can be
[“USECASE”] /] specified by either Column name or number. Either
the number of the data column (as returned from
<Sort Keys>: Each key is made up of either a left to right) or the name of the data column can be
column name/number reference, or a WebReports used to specify a column to sort by. Alternatively if a
tag and sub-tag combination enclosed in (single or report tag is used, the report will be sorted
double) quotes and optionally followed by a colon according to the result of the specified tag and sub-
and a direction parm as shown in the syntax tags. For example:
example.
[LL_WEBREPORT_SORT "DATAID" /]
<Global Direction>: Can be one of DESC/ASC
and defaults to ASC. The directions specified for [LL_WEBREPORT_SORT "DATAID"
each individual sort key override the global "[LL_REPTAG=DATAID NODEINFO:NAME /]" /]
direction.
[LL_WEBREPORT_SORT "PARENTID":DESC
<Directives>: Can be one or more "directives" in "[LL_REPTAG=DATAID NODEINFO:NAME
the format @PREDEFKEY , @PARMNAMES /]":ASC /]
along with any associated information. Used to
predefine sortkeys that can be associated with [LL_WEBREPORT_SORT "PARENTID"
simple URL values. E.g. &sortcol=col1 could be "[LL_REPTAG=DATAID NODEINFO:NAME /]" /]
used to trigger a sort key such as
[LL_REPTAG=DATAID CAT:cat1:attr1:display /]
The first example above would sort according to the
Support: row order of numeric data ids. The second example
would sort according to the node name even
though they are both using the same report column.
The third example would sort first on the parentid
column in descending order then on the name in
ascending order. The final example is the same as
the third with the parentid column sorted in the
default direction (ascending) Note, this tag also
supports a series of "directives" which allow
sortkeys to be pre-defined and associated with
simple URL parameters. Please refer to: (Advanced
Notes on Sorting) for more detail

Page 35
 WebReports User Guide

[LL_WEBREPORT_STARTROW /] Used to mark the start of the row template which

will be applied to every row of data (report row
template). In other words, all code between this tag
and [LL_WEBREPORT_ENDROW /] will be
repeated for every row of data output in the data
source.

Report Row Template Usage:

The section in the reportview that is stored between
startrow and endrow could be used to generate
repeated HTML table rows, or to assign report data
to a JavaScript array for later data manipulation and
display. Any code between these tags will be
repeated for each and every row of data in the
associated data source. If the STARTROW and
ENDROW tags are omitted, any data source will
be ignored.

[LL_WEBREPORT_STARTSCRIPT Marks the start of a section of the reportview that

NAME:<Script Name> /] will contain an Oscript script. Oscript within a
reportview is, by default, tightly secured and
Support: header, row, footer constrained to make it safe. However it is
recommended that WebReports with Oscript are
developed and tested on a development server
before being moved to a production Livelink
instance.

The name parameter should be a unique identifier

for the script. This name will be used when calling
the script using [LL_WEBREPORT_CALL
NAME:<Script Name> /]

Before using this tag, please read all the related

documentation in chapter 22.

[LL_WEBREPORT_SUBWEBREPORT Used to call another WebReport (a "sub-

NODEID:<nodeid of the sub-WebReport> WebReport") whose results will be returned and
PARM:<parm1 name>:<parm1 value> inserted into the parent report at the point where
PARM:<parm2 name>:<parm2 value> etc. /] the tag is placed. Sub-WebReports can be thought
of as "sub-routines" that form part of the overall
Support: header, row, footer report results. This tag is particularly useful where
you wish to collect the results from several different
queries (e.g. LiveReport SQL queries) and present
them in a single report. For example it is often
simpler to use two or more simple SQL queries in
place of one complex one or you may wish to
combine results from a SQL query with results from
a search query.

Page 36
 WebReports User Guide

Examples:
[LL_WEBREPORT_SUBWEBREPORT
NODEID:68873 PARM:InputLabel1:299
PARM:myStatus:"awaiting review" /]

[LL_WEBREPORT_SUBWEBREPORT
NODEID:[LL_REPTAG_$mySubReport /] /]

• Specify the sub-WebReport by its node ID in

the NODEID parameter. In the second
example a WebReport constant is used to
specify the node ID of the sub-WebReport.

• Optionally, parameters that would normally be

passed to a WebReport via the calling URL,
can be specified using the PARM:<parm
name>:<parm value> construct. To pass
parameters that might contain spaces or
colons, use double or single quotes to delimit
the parameter’s value (see first example).
LiveReport "InputLabel" parameters can also
be passed using PARM. If parameters are
required but are not specified, defaults will be
used if they have been setup in the sub-
WebReport.

• The LL_WEBREPORT_SUBWEBREPORT
tag can be placed anywhere in the reportview,
but its use within the row section should be
treated with caution if either the parent or sub-
WebReport could return a large result set due
to the potential performance impact.

• If a sub-WebReport's default action is set to

export report results rather than return them to
the browser, the standard status message will
be inserted in the parent report and the sub-
WebReport's results will be exported.

• Scope of parameters, and constants: The

constants and parameters for all parent
reports are in scope for a Sub-WebReport. In
cases where the same parameter or constant
is used by different reports to hold a different
value, the value set most recently (i.e. by the
more deeply nested report) will be returned.

• Sub-WebReports themselves can call a sub-

WebReport; reports can be nested up to five
reports deep.

[LL_WEBREPORT_SUPPRESSERRORLOG /] Prevents any error messages from being displayed

in the output. Errors can arise due to misplaced
Support: header tags or mistyped tags.

Page 37
 WebReports User Guide

[// Used to comment the remainder of the line. Using

this tag rather than HTML comment tags will prevent
Support: header, row, footer the comment being rendered in the output. For large
reports this has considerable benefits in terms of
restricting the amount of data being sent to each
browser. Converting all comments to use
WebReports comment tags can provide performance
benefits for large reports.

[/* ... */] Used to denote a block comment which can span
multiple lines. Using this tag rather than HTML or
Support: header, row, footer JavaScript comment tags will prevent the comment
being rendered in the output which is sent to the
user’s web browser. For large reports this has
considerable benefits in terms of restricting the
amount of data being sent to each browser.
Converting all comments to use WebReports
comment tags can provide performance benefits for
large reports.

Page 38
 WebReports User Guide

6.2.2 Column Data Tags

Tag name Description

Causes WebReports to insert the data specified by the <column
[LL_REPTAG=<column name> name> into the output report. This tag must lie between
<sub-tag> <sub-tag> \ /] [LL_WEBREPORT_STARTROW /] and
[LL_WEBREPORT_ENDROW /]. The optional list of sub-tags is
Support: row
used to specify formatting options. These sub-tags should be
separated by spaces. See the sub-tag definition table for
information on these tags.

The use of single or double quotes to delimit a column name is

supported. Using quotes is only mandatory for referencing data
source column names that contain a space character. In the
case of LiveReports, this also applies if the LiveReport renames a
column to a name containing a space character. Double quotes
should not be used if the LL_REPTAG is inside a conditional tag.
Examples:

[LL_REPTAG=name /]

[LL_REPTAG="name" /]

[LL_REPTAG="first name" /]

[LL_WEBREPORT_INCLUDEIF "John" != "[LL_REPTAG=’first

name’ /]" /]

Alternative method of referencing column data in which the

[LL_REPTAG_<column number> column number is specified instead of its name. Livelink columns
<sub-tag> <sub-tag> \ /] are numbered from left to right starting at 1.
Support: row Note the use of an “_” underscore instead of an “=” equal
sign in this form of LL_REPTAG. (This roughly matches the
Livelink WebForm tag model)

This form of the tag can be useful if one reportview is to be used

in multiple WebReports where the column names may vary.

This tag provides a means of specifying a string of text to be

[LL_REPTAG_"<literal text>" /] inserted in the reportview. Any sub-tags included in this tag
definition will operate on the text specified between the two
[LL_REPTAG_'<literal text>' /] quotes. Either double quotes or single quotes may be used but
must be matched.
Support: header, row, footer

[LL_REPTAG_"this text will be displayed in capitals" UPPER

/]

Page 39
 WebReports User Guide

This tag provides a means of accessing any parameter in the

[LL_REPTAG_&<parm name> /] URL used to invoke the WebReport. Any values in the URL
prefixed by an ampersand (&) can be referenced in this way.
Support: header, row, footer
This means that existing parameters such as &ObjAction can be
referenced as well as any number of bespoke parameters. For
example, if the following URL was executed:

...?func=ll&objId=47478&objAction=RunReport&myparm=testdat
a&nexturl=....
The parameter, myparm, can be accessed by using:
[LL_REPTAG_&myparm /]. This tag will resolve to the value in
the URL (testdata in this example) where it can be used as output
or as part of a conditional statement e.g.

[LL_WEBREPORT_INCLUDEIF “[LL_REPTAG_&myparm /]” ==

“testdata” /]
If a parameter is referenced in the reportview but is not provided
in the URL, a blank string will be inserted in the output unless a
parameter default is set on the Properties->Parameters page.

This tag provides a way to access constants that have been

[LL_REPTAG_$<const name> /] defined using the Properties->Constants tab (see chapter 10).
The constant name in the reportview should exactly match the
Support: header, row, footer
name that has been specified on the constants page. The tag is
replaced by the value that has been defined for the
corresponding constant. E.g. If a constant called MyConst has
been defined with a constant value of '12345', the following tag
would return '12345':

[LL_REPTAG_$MyConst /]

Constants are particularly useful for referencing Sub-WebReports

and other Livelink objects as it means that objectids don't need to
be hard coded within the reportview. Also, when using XML to
export WebReports applications, constants allow the objects to
be 're-linked' on XML import to the new system.

This tag provides a way to reference variables that have been

[LL_REPTAG_%<variable name> /] defined by using SETVAR, ADDVAR or CONCAT. If, for example,
ADDVAR had been used in the row section to accumulate a
Support: header, row, footer
mathematical total in a variable called MyVar, the total could be
accessed by using

[LL_REPTAG_%MyVar /]

Notes: This tag is not supported in [LL_WEBREPORT_IF/ENDIF

expressions.

Page 40
 WebReports User Guide

This tag type provides data functions. The result of each function
[LL_REPTAG_@<function> is inserted into the output; however, these tags are currently only
<reference options> /] supported in the header or footer of a reportview (i.e. before the
[LL_WEBREPORT_STARTROW /] or after the
Support: header, footer
[LL_WEBREPORT_ENDROW /] tag).

For each function there are optional characters following the

function name which reference either a specific row of data or a
column or both. These reference characters are:

• [r] is optional and specifies the row index (note, the

reserved word LAST can be used instead of n).
Currently only used by @DATA.

and can be followed by:

• _n specifies a column number, or

• _<colname> specifies a column name

Page 41
 WebReports User Guide

When one of the functions below is specified, the function will be executed against which ever data has
been referenced. For any math tags, if non-numeric values are found in the column then an error is
returned. Note that there are sub-tags (e.g. ROUND) which will help to format the values returned by these
functions.
Examples:

If the average of column 2 is required (rounded to two decimal places) the following syntax could be used:

[LL_REPTAG_@AVERAGE_2 ROUND:2 /]

If the sum of a column called "hours" is required, the following syntax could be used:

[LL_REPTAG_@SUM_hours /]

If the contents of a column called dataid from the last row of data is required, the following syntax could be
used:

[LL_REPTAG_@DATA[last]_dataid /]

@AVERAGE_<column> Returns the average of all valid

numbers in the specified column.

@DATA[r]_<column> Returns the sum of all the values in

the specified column.

@MIN_<column> Returns the lowest (minimum) value

from all the values in the specified
column.

@MAX_<column> Returns the greatest (maximum)

value from all the values in the
specified column.

@SUM_<column> Returns the sum of all the values in

the specified column.

This tag returns the number of rows included in the WebReport by

[LL_REPTAG_ACTUALROWS /] the INCLUDEIF tag. This differs from the total number of rows
provided by the data source. For example, if the WebReport is
Support: header, footer
executed in conjunction with a data source returning 10 rows of
data, but the INCLUDEIF restricts the output to three rows, then
TOTALROWS = 10 and ACTUALROWS = 3. This feature is only
supported in the header and footer sections of the WebReport.

Page 42
 WebReports User Guide

This tag returns the correct name of a column from the associated
[LL_REPTAG_COLNAMEn /] data source, based on the number which is supplied after
[LL_REPTAG_COLNAME++ /] COLNAME. For example, [LL_REPTAG_COLNAME1 /] would
return the word: DATAID in a WebReport that is dumping the
Support: header, row, footer
Livelink DTREE using an Auto LiveReport.

This tag is useful when a generic reportview is being developed.

Rather than hard coding a column name into the reportview, this
tag will always provide the correct column name. (The default
reportviews use this tag for all column names.)

The COLNAME++ variation of this tag will automatically provide

the next column number. For example, if the previous COLNAME
tag was COLNAME3 then COLNAME++ would be the equivalent
of COLNAME4. If COLNAME++ was used again, then the
equivalent of COLNAME5 would be returned. If COLNAME1 was
then used, COLNAME++ continues from the last column number
and would therefore return the equivalent of COLNAME2.

Inserts the date on which the WebReport was executed.

[LL_REPTAG_DATE /]

Support: header, row, footer

Inserts the date and time when the WebReport was executed.
[LL_REPTAG_DATETIME /]

Support: header, row, footer

Returns the number of rows remaining in the row section after any
[LL_REPTAG_FILTEREDROWS /] WebReports filtering but before the includerange tag has reduced
the number of rows.
Support: header, footer

Inserts the total number of hits from a search data source. This tag
[LL_REPTAG_INDEXTOTALHITS /] is useful when working with search data sources as it can provide
the user with an indication of the total result size without having to
Support: header, row, footer display them all. This tag can be used in combination with the
&maxrows URL parameter to limit the results to a low number and
get a value for the number of search hits very quickly with the
minimum of performance impact.

Inserts the system language currently being used.

[LL_REPTAG_LANGUAGE /]

Support: header, row, footer

Provides a path to the WebReports library folder. This is primarily
[LL_REPTAG_LIBPATH /] used to to store useful Javascript files that can be used for
WebReports applications. The path returned can be used for
Support: header, row, footer
URLs that need to reference these files. For example, a typical
path returned looks like this:
/Livelinksupport/webreports/library/
The syntax to use this tag to include a Javascript file in the
WebReports library looks like this:
<SCRIPT SRC="[LL_REPTAG_LIBPATH /]page.js"></SCRIPT>

Page 43
 WebReports User Guide

Returns a URL for the currently running WebReport but any URL
[LL_REPTAG_MYCACHEURL /] parameters that would ordinarily be included in the URL, are
cached and the cache ID is added to the URL instead. The cache
Support: header, row, footer ID is added to the URL in the format: &reqcacheid=nnnnnnnn. If
this URL is used to execute a request to Livelink, all of the cached
parms are added on to the request prior to any WebReports
processing.

Returns the ObjectID of the WebReport that is being run.

[LL_REPTAG_MYID /]

Support: header, row, footer

Returns the URL that was used to run the executing WebReport
[LL_REPTAG_MYURL /] as a string. In conjunction with the ESCAPEURL sub-tag, this tag
could be used when including a hyperlink to another Livelink item
Support: header, row, footer to allow the original WebReport to be re-run. Whenever this tag is
used to specify a 'nexturl' parameter, the ESCAPEURL sub-tag
should be used to generate the correct URL escaped format.
E.g. the last part of a hyperlink could include:
\ nexturl=[LL_REPTAG_MYURL ESCAPEURL /]
Inserts a URL which will take the user to the page they were
[LL_REPTAG_NEXTURL /] viewing prior to executing the WebReport. It could be used to
implement a “Return” button using HTML like the following:
Support: header, row, footer
<INPUT TYPE="BUTTON" NAME="return" VALUE="Return"
ONCLICK="document.location='[LL_REPTAG_NEXTURL /]' ">
Returns the data source row number after any WebReports sorting
[LL_REPTAG_ORIGROWNUM /] has occurred, but before any WebReports filtering has occurred.
This tag differs from the ROWNUM tag in that it will always return
Support: row
the original row number from the data source regardless of how
many rows are actually returned by the WebReport. It is useful for
INCLUDEIF conditions that need to react to a row number as the
normal ROWNUM tag can't be used in an INCLUDEIF statement.
This tag is similar to the [LL_REPTAG_SOURCEROWNUM /] tag;
however, it differs from the SOURCEROWNUM tag in that it
reflects the order of rows after any WebReport SORT tags have
been processed whereas SOURCEROWNUM reflects the order of
rows before any WebReports SORT tags have been processed.
Returns the dataID of the Livelink object that is currently
[LL_REPTAG_OVERRIDEOBJID /] overridden by an ActiveView template.
Support: header, row, footer
Returns the ownerID of the Livelink object.
[LL_REPTAG_OWNERID /]

Support: header, row, footer

Returns the dataID of the parent Livelink object.
[LL_REPTAG_PARENTID /]

Support: header, row, footer

This tag is used between the STARTROW and ENDROW tags
[LL_REPTAG_ROWNUM /] (the row contents) to return the current row number. This tag is
most useful when used with the ODD or EVEN sub-tags. For
Support: row
example, [LL_REPTAG_ROWNUM ODD /] will return true for
rows 1, 3, 5, 7, etc. This can be used to alternate row colors when

Page 44
 WebReports User Guide

providing standard report formats (e.g. traditional LiveReports.)

This tag cannot be used as a term in the INCLUDEIF content
control tag as it changes according to the number of rows that are
being returned by the INCLUDEIF tag.
Returns the name of the data source.
[LL_REPTAG_SOURCENAME /]

Support: header, row, footer

Returns the data source row number. This tag differs from the
[LL_REPTAG_SOURCEROWNUM /] ROWNUM tag in that it will always return the original row number
from the data source regardless of how many rows are actually
Support: row
returned by the WebReport and regardless of any WebReport
sorts that may occur. This makes it useful for INCLUDEIF
conditions that need to relate to the original data source rows
before any WebReports row processing occurs. This tag is similar
to the [LL_REPTAG_ORIGROWNUM /]; however, the
ORIGROWNUM tag provides the row number reference after any
sorting has occurred.
This tag is used to return the objectid of the data source. This tag
[LL_REPTAG_SOURCEID /] might be used in conjunction with the NODEINFO sub-tag to
retrieve the name of the data source. For example,
Support: header, row, footer
[LL_REPTAG_SOURCEID NODEINFO: NAME /]
Provides the support directory which contains standard Livelink
[LL_REPTAG_SUPPORTDIR /] support files. For example: /LivelinkSupport/.
Support: header, row, footer
Total number of rows that have been returned by the underlying
[LL_REPTAG_TOTALROWS /] data source. Note: This tag will always return the number of rows
originally available regardless of how many rows have been
Support: header, row, footer
included/excluded using the INCLUDEIF tag. If the user requires
a counter for the actual number of rows that have been included,
the ACTUALROWS parameter should be used instead.
Total number of rows returned by the Data Source (before
[LL_REPTAG_TOTALSOURCEROW dsstartrow and endrow). This tags is closely related to
S /] [LL_REPTAG_TOTALROWS /] and [LL_REPTAG_ACTUALROWS
/]. The difference being that it takes account of the special data
Support: header, row, footer
source parameters &dsstartrow and &dsendrow, making it very
useful for pagination.
The trigger event that initiated the WebReport. This tag will only
[LL_REPTAG_TRIGGER /] return a value when a WebReport was triggered using the
WRTrigger feature. The WRTrigger feature must be enabled in the
Support: header, row, footer
admin pages on a per subtype basis - default configuration is off
for all subtypes. If the feature is not enabled for a given subtype no
WebReport will be triggered even if the node is within a hierarchy
that has a cascading trigger applied. Possible trigger values are:

Trigger Description

Fired when a new version is added to

an existing document or when a new
Add Version document is added.

Page 45
 WebReports User Guide

Fired when a livelink category is

Category applied, removed or updated on a
Update given node.

Copy Fired when a node is copied.

Create Fired when a node is created.

Delete Fired when a node is deleted.

Move Fired when a node is moved.

Fired when a node is updated, such as

Update changes in the General Tab.
The nodeid of the item that initiated the trigger event.
[LL_REPTAG_TRIGGERID /]

Support: header, row, footer

The new nodeid of the item copied when a Copy event occurs.
[LL_REPTAG_TRIGGERNEWID /]

Support: header, row, footer

The nodeid of the source container in a copy or move operation
[LL_REPTAG_TRIGGERSOURCEPA
RENTID /]

Support: header, row, footer

The nodeid of the destination container in a copy or move
[LL_REPTAG_TRIGGERDESTPARE operation
NTID /]

Support: header, row, footer

Inserts the first part of the URL required to call the Livelink CGI.
[LL_REPTAG_URLPREFIX /] For example: “Livelink/livelink.exe”. This can be used to construct
a hyperlink in the WebReport that runs a Livelink command (e.g.
Support: header, row, footer
open a form for the data in the WebReport)
Inserts the full name of the user executing the WebReport.
[LL_REPTAG_USERFULLNAME /]

Support: header, row, footer

Inserts the Livelink user id for the user executing the WebReport.
[LL_REPTAG_USERID /]

Support: header, row, footer

Inserts the Livelink Login username of the user executing the
[LL_REPTAG_USERNAME /] WebReport.

Support: header, row, footer

Returns a personal authorization code for WebDav usage
[LL_REPTAG_WEBDAVAUTH /]

Support: header, row, footer

The Virtual Directory used by the web server (e.g. IIS) to handle
[LL_REPTAG_WEBDAVDIR /] WebDAV requests within Livelink.

Page 46
 WebReports User Guide

Support: header, row, footer

Inserts the name of the executing WebReport.
[LL_REPTAG_WEBREPORTNAME
/]

Support: header, row, footer

Page 47
 WebReports User Guide

6.2.3 Sub-Tags

Any of the data tags (tags that start with [LL_REPTAG ) can contain a list of formatting sub-
tags separated by spaces which allow actions to be taken on the actual data returned by the
tag before it is inserted into the output.

E.g. [LL_REPTAG_1 UPPER /]

Multiple sub-tags can be used for any tag and they are processed from left to right so that the
result of each tag becomes the input for the next tag in the list.

Some sub-tags use additional parameters. For example, in the following tag a sub-tag called
REPLACE is used which requires 2 parameters (one for the string to be replaced, and one for
the string to replace it with.)

[LL_REPTAG_1 REPLACE:dummy:genius /]

Any sub-tag parameters are added using the colon (:) symbol. Some parameters may need
to use quotes if they include spaces (or colons). For example, if the string to be replaced was
'test value', the syntax would be:

[LL_REPTAG_1 REPLACE:"test value":"new value" /]

The following table lists these sub-tags and describes their behavior.

Sub-Tag Description
If the data item pulled from the data source is an ASSOC (a Livelink
ASSOC:<key> key-value data type) the value of the field specified by <key> is
returned (and only that value). This sub-tag can be used repetitively
Support: header, row, footer
or in combination with sub-tags like RECORD and LIST where those
data types are nested. In the following example a LiveReport is
returning columns from the WFFORMS table:
[LL_REPTAG=data ASSOC:data ASSOC:dataassoc ASSOC:ID /]
This tag returns a column called data which contains an ASSOC.
The ASSOC:data returns the value associated with the key data.
This value is also an ASSOC and ASSOC:dataassoc returns a
further ASSOC. From this ASSOC:ID extracts a single ID value
which is returned to the report.

Adds the value of the tag (after formatting by any previous sub-tags)
ADDVAR:<variable name> with the current contents of a variable which can later be referenced
using the specified variable name. This tag only works when
Support: header, row, footer
numeric values are returned by a tag. The first time this sub-tag is
used, it behaves as if the variable already existed with the value of
zero (0).
E.g. [LL_REPTAG=cost ADDVAR:subtotal /]
In this example if the values 26, 34, and 14 were returned as values
from the tag "cost" then, the variable tag: [LL_REPTAG_%subtotal /]
would return: 74. See also SETVAR, CONCATVAR and Using
WebReports variables.

Page 48
 WebReports User Guide

Tests an integer value returned by the tag to determine if a particular

BITCHECK:<bit mask value> binary bit has been set. The bit mask value must be a regular
decimal number which is used to specify which binary bits will be
Support: header, row, footer
tested. If it is determined that the expected bits are set then this
sub-tag returns TRUE, otherwise it returns FALSE.
Examples: to test if the first and fourth bits (from right to left) had
been set, the mask needs to be 1001 in binary. Using a binary to
decimal converter, the number 1001 converts to decimal 9.
Therefore the syntax BITCHECK:9 would be used. If the
corresponding tag returned a value of 20 (decimal), then the bit
pattern being tested is: 10100. The mask of 9 would determine that
neither bit 0 or 3 are set so BITCHECK:9 would return FALSE. To
test if the third bit from the right was set, the mask required would
be binary 100 (decimal 4). If the corresponding tag returned decimal
15 (binary 1111) then BITCHECK:4 would return TRUE.

The first letter of each word will be converted to uppercase, while

CAPITALIZE following letters of each word will be converted to lowercase.
Support: header, row, footer
Return information about the Categories and Attributes associated
CAT:<parms> with the current object ID. This sub-tag supports both attribute sets
and multi-value attributes through use of the MV and SET operators.
Support: header, row, footer
For Example: [LL_REPTAG=DATAID
CAT:<catname>:<attname>:DISPLAY /] will return the attribute
value stored in the category <catname> and the attribute <attname>
for any attribute type. If <attname> is a multi-value attribute or an
attribute set a comma-separated list of values will be returned.

Syntax Description

CAT Will return TRUE/FALSE depending on the presence of one

or more categories assigned to the node.

CAT:JSARRAY This is a unique option for the CAT sub-tag which results in
a JavaScript object representation of all the category and
attribute data (including full support for sets and multi-
values) for a specific node.

CAT:RAW This option results in a flat oscript representation of all the

category and attribute data associated with a specific node.

See the TOJSON sub-tag for how to convert this into a data
structure that can be interpreted by JavaScript in the client.
See related tags LLURL:FUNCTIONMENU:RAW and
LLURL:ADDITEM:ITEMMENU:RAW.

CAT:DISPLAY Will return a string containing a list of semi-colon separated

category names assigned to the node. Any category
containing mandatory attributes will be suffixed with an
exclamation in square brackets - [!].

CAT:MAND Will return TRUE/FALSE depending on whether a category

containing a mandatory attribute is assigned to the node.

Page 49
 WebReports User Guide

CAT:<catname> Will return TRUE/FALSE depending on the presence of the

<catname> category.

CAT:<catname>:DISPLAY Will return a string containing a list of semi-colon separated

attribute values for the category specified in <catname>. If
either attribute sets or multi-value attributes are contained
in the category they will be displayed in the following
syntax:
'atval1;atval2;
[SET3:atval4,atval5,[MV6:atval7,atval8]];atval9'
Here atval1, atval2 & atval9 are regular attribute values.
[SET3: represents the start of an attribute set where 3 is
the attribute ID of the set (see note). Contained in the
attribute set are two regular attributes (atval4 & atval5) and
a multi-value attribute, starting [MV6:, with 6 being the
attribute ID of the multi-value attribute. The multi-value
attribute contains 2 values for attribute 6, these are: atval7
& atval8.
Note: Attribute ID's can be identified by looking at the
browser status bar whilst hovering over the attribute name
in the category definition page.

CAT:<catname>:ID Will return the ID of <catname> if the category is present.

CAT:<catname>:<attname> Will return TRUE/FALSE depending on whether an attribute,

<attname>, exists with a non-blank value in the category,
<catname>. If an attribute set is specified in <attname>, a
single entry in any one of the set's attribute values will cause
this to return TRUE. If <attname> is a multi-value attribute,
a single entry in any one will also cause this to return
TRUE. <attname> can also be nested within an attribute set
either as a regular attribute or a multi-value attribute.

CAT:<catname>:<attname>:DISPLAY Will return the value in the attribute, <attname>, for the
category, <catname>. If <attname> is an attribute set or a
multi-value attribute a comma separated list of values will be
returned.

CAT:<catname>:<attname>:ID Will return the ID of the attribute, <attname>, for the

category, <catname> if it is present. If <attname> exists
inside an attribute set, it will be returned if no attribute
matching <attname> exists at the top level in the category.
If <attname> exists at the top level of the category and
within an attribute set of the same category, the attribute ID
at the top level (not within the set) will take precedence.

CAT:<catname>:<attname>:<attval> Will return TRUE/FALSE depending on whether an attribute,

<attname>, exists with a value equal to <attval> in the
category, <catname>. <attname> may be an attribute within
an attribute set (including a multi-value), or any element
within a multi-value attribute.

CAT:<catname>:MV:<attname>:COUNT Will return number of multi-value attributes in use.

Page 50
 WebReports User Guide

CAT:<catname>:MV:<attname>:<n> Will return TRUE/FALSE for the presence of a specific non-

blank element in a multi-value attribute, <attname>, for the
category, <catname> at the index location <n>. The value of
<n> must be a positive integer between 1 and n where n
does not exceed the length of the multi-value attribute. If n
exceeds the length of the multi-value attribute, an empty
string will be returned.

CAT:<catname>:MV:<attname>:<n>: Will return TRUE/FALSE for the presence of <attval> in a

<attval> multi-value attribute, <attname>, for the category,
<catname> at the index location <n>. The value of <n> must
be a positive integer between 1 and n where n does not
exceed the length of the multi-value attribute.

CAT:<catname>:MV:<attname>:<n>:DIS Will return the value in the multi-value attribute, <attname>,

PLAY for the category, <catname> at the index location <n> where
<n> is a positive integer between 1 and n. The value of <n>
must be a positive integer between 1 and n where n does
not exceed the length of the multi-value attribute.

CAT:<catname>:MV:<attname>:INDEX: Will return the first index of the multi-value attribute,

<attval> <attname>, for the category, <catname> where <attval> is
equal to the value contained in the multi-value attribute at
index. For example, if <attval> exists in the third element of
<attname>, the number 3 will be returned.

CAT:<catname>:SET:<setname>: Uses the SET operator allowing attribute sets to be explicitly

<attname> referenced. This example will return TRUE if attribute,
<attname> within set, <setname> is non-blank. Only
attributes within <setname> can be referenced so if
<attname> exists outside the set, it will not be found. If
<attname> is a multi-value attribute, TRUE will be returned if
any field within it is non-blank.

CAT:<catname>:SET:<setname>:<attna Will return the value in the attribute, <attname>, for the
me>:DISPLAY category, <catname>, if <attname> is an attribute within
<setname>. If <attname> is a multi-value attribute, a
comma separated list of the defined values will be returned.
If no defined value exists, either in a multi-value attribute, or
a standard attribute, an empty list will be returned.

CAT:<catname>:SET:<setname>:<attna Will return the ID of the attribute <attname> within the set
me>:ID <setname>. If <attname> exists outside <setname> it will
not be returned. <attname> can be either a regular or multi-
value attribute.

CAT:<catname>:SET:<setname>:<attna Will return TRUE/FALSE depending on whether an attribute,

me>:<attval> <attname>, exists with a value equal to <attval> in the set,
<setname>. If <attname> is a multi-value attribute, all
elements will be checked for equality against <attval>, if any
match, TRUE will be returned.

CAT:<catname>:SET:<setname>:MV:<a Will return TRUE/FALSE for the presence of a specific non-

ttname>:<n> blank element in a multi-value attribute, <attname>, within a
set, for the category, <catname> at the index location <n>.
The value of <n> must be a positive integer between 1 and
n where n does not exceed the length of the multi-value
attribute.

Page 51
 WebReports User Guide

CAT:<catname>:SET:<setname>:MV:<a Will return TRUE/FALSE for the presence of <attval> in a

ttname>:<n>:<attval> multi-value attribute, <attname>, within a set, for the
category, <catname> at the index location <n>. The value of
<n> must be a positive integer between 1 and n where n
does not exceed the length of the multi-value attribute.

CAT:<catname>:SET:<setname>:MV:<a Will return the value in the multi-value attribute, <attname>,

ttname>:<n>:DISPLAY within a set, for the category, <catname> at the index
location <n> where <n> is a positive integer between 1 and
n. The value of <n> must be a positive integer between 1
and n where n does not exceed the length of the multi-value
attribute.

CAT:<catname>:SET:<setname>:MV:<a Will return the first index of the multi-value attribute,

ttname>:INDEX:<attval> <attname>, within a set, for the category, <catname> where
<attval> is equal to the value contained in the multi-value
attribute at index.
Will return TRUE or FALSE where the multi-value set,
CAT:<catname>:MVSET:<setname>:<n>
<setname>, has a non-blank attribute, <attname>, at the
:<attname>
index location <n>, within the category, <catname>.
Will display the value of an attribute <attname> within a
CAT:<catname>:MVSET:<setname>:<n
multi-value set, <setname> at the index location <n>, within
>:<attname>:DISPLAY
the category, <catname>.
Will display the ID of an attribute <attname> within a multi-
CAT:<catname>:MVSET:<setname>:<n
value set, <setname> at the index location <n>, within the
>:<attname>:ID
category, <catname>.
Will return TRUE or FALSE where the multi-value set,
CAT:<catname>:MVSET:<setname>:<n <setname>, has a attribute, <attname>, at the index location
>:<attname>:<attval> <n>, within the category, <catname> that is equal to the
value specified in <attval>.
CAT:<catname>:MVSET:<setname>:<n> Returns the number of multi-value attributes in use in the
:MV:<attname>:COUNT multi-value set.
Will return TRUE or FALSE where the multi-value set,
CAT:<catname>:MVSET:<setname>:<n>
<setname>, at index location <n> has a multi-value attribute,
:MV:<attname>:<m>
<attname>, at the index location <m>, that is non-blank.
Will display the value of a multi-value attribute <attname>, at
CAT:<catname>:MVSET:<setname>:<n>
the index location <m>, within a multi-value set, <setname>
:MV:<attname>:<m>:DISPLAY
at the index location <n>, within the category, <catname>.
Will return TRUE or FALSE where the multi-value set,
CAT:<catname>:MVSET:<setname>:<n> <setname>, at the index location <n>, has a multi-value-
:MV:<attname>:<m>:<attval> attribute, <attname>, at the index location <m> whose value
is equal to the value specified in <attval>.
Will return the first index of the multi-value attribute,
CAT:<catname>:MVSET:<setname>:<n> <attname>, within a multi-value set for the category,
:MV:<attname>:INDEX:<attval> <catname> where <attval> is equal to the value contained in
the multi-value attribute at index.

Page 52
 WebReports User Guide

This sub-tag provides capabilities to modify category and attribute

CATACTION:<options> metadata. With this tag you can:
Support: header, row, footer • add or remove a category from a node; and
• add, set, or remove the value of a specific category
attribute.
The parameter accepts the DataID or name of the category. The
parameter accepts Attribute ID or name of the attribute. The
[:Index] [:Set Index] are optional parameters to target a specific
attribute in a multi-valued attribute and multi-valued set. These
values default to 1 if not set. You must give a value of [:Index]
when using the [:Set Index] parameter. The following tables
describe the syntax for the various usages of CATACTION. Each
use case expects the DataID of the target node on which
CATACTION will work. The parts in angle brackets are required;
the parts in square brackets are optional.

Page 53
 WebReports User Guide

CATACTION Options

Operation Syntax Description

CATACTION:SETVALUE:<cate Sets the attribute value at

gory>:<attribute>[:Index][:Set a given attribute and set
Index]:<value> index.

To add a new row to a

multi-value set, specify
the 'ADDSETROW'
keyword for the [:Set
Index] parameter. Once
added the new row can
be targeted using the
'NEWROW' keyword for
[:Set Index].
Setting Attribute Values

CATACTION:ADDVALUE:<cat
Appends a value to the end
egory>:<attribute>[:Index][:Se
of multi-valued attribute.
t Index]:<value>
This tag ignores the [:Index]
parameter.

CATACTION:INSERTVALUE:< Inserts a value at the

category>:<attribute>[:Index][ given attribute index. This
:Set Index]:<value> causes the existing
attribute at that index and
all subsequent attributes
to shift down.

CATACTION:REMOVEVALUE: Removes the attribute at

<category>:<attribute>[:Index a given index. This
][:Set Index] causes the number of
values in a multi-valued
attribute to be reduced by
one (except when the
Removing Attribute attribute only has one
Values value).

CATACTION:CLEARVALUE:<c Sets the attribute value at

ategory>:<attribute>[:Index][: a given index to null. This
Set Index] does not change the
number of values in a
multi-valued attribute.

CATACTION:ADD:<category> Adds the given category

to the node.

Adding/Removing CATACTION:REMOVE:<categ Removes the given

Categories ory> category from the node.

CATACTION:UPGRADE:<cate Upgrade the category to

gory> the latest version.

For example, consider a "Test Category" schema. Use the following syntax to set the "Trial Name" attribute on
the Enterprise Workspace to "first": Page 54
[LL_REPTAG_"2000" CATACTION:SETVALUE:"Test Category":"TrialName":"first" /]
 WebReports User Guide

Creates a collapsed string by removing all spaces and tabs from

COLLAPSE the original string.
Support: header, row, footer
Converts all sequences of one or more spaces or horizontal tabs
COMPRESS to a single space character.
Support: header, row, footer

CONCATVAR:<variable name> Concatenates the value of the tag (after formatting by any
or previous sub-tags) with the current contents of a variable which
CONCATVAR:<varname>:<joinstr> can be referenced using the specified variable name.
or
CONCATVAR:<varname>:<joinstr>:NO The second (optional) parameter can be used to specify a
BLANKS character or string of characters which are used before each new
or value added to the variable. If the special string @EMAIL is used
CONCATVAR:<varname>:<joinstr>:UN as the "join string" the standard email separator as defined for the
IQUE Livelink system will be automatically inserted.

Support: header, row, footer The third optional parameter can only be used if the join string has
been supplied. When used the syntax is always: NOBLANKS.
When NOBLANKS is used, no join strings will be added for empty
data cells. Alternatively (instead of NOBLANKS) the parameter
UNIQUE can be used to ensure that only unique values are
added to the concatenated variable. The first time this sub-tag is
used, it behaves as if the variable already existed with an empty
string. E.g.

[LL_REPTAG=NAME CONCATVAR:names:";" /]

In this example if the values "Joe", "Bob", "Smith" were returned

consecutively by this tag, the variable [LL_REPTAG_%names /]
would return: Joe; Bob; Smith;

When this sub-tag is used, the associated tag output will not be
displayed unless the SHOW sub-tag is also used.

See also SETVAR, ADDVAR.

Page 55
 WebReports User Guide

CURRENTVAL Displays the current value of a variable according to its position

within the reportview. Variable sub-tags are processed starting at
the top of the file and working towards the bottom (rows are also
processed in order from 1 to n). Normally a variable tag
([LL_REPTAG_%test /]) returns the final value of a variable
regardless of where it was positioned in the reportview; however,
if the CURRENTVAL sub-tag is included in a variable tag, the tag
will display its value according to its position in the reportview.
E.g.:
[LL_REPTAG_%test CURRENTVAL /] - Shows the current value
of the variable called "test"

The output of the CURRENTVAL sub-tag can be formatted with

other sub-tags. E.g. :
[LL_REPTAG_%test CURRENTVAL CAPITALIZE /] - Shows the
value of the variable called "test", Capitalized

CURRENTVAL can also be used with other variable sub-tags (e.g.

SETVAR, CONCATVAR, ADDVAR to return the value of whatever
variable they are modifying after the changes have been made.
When used in this fashion, the CURRENTVAL variable must be
immediately to the right of the variable sub-tag. E.g.:
[LL_REPTAG=number ADDVAR:total CURRENTVAL /] - Shows
the value of a variable called "total" after ADDVAR has added the
number value to it.

CURRENTVAL also makes it possible to use the value of a

variable to feed another action type sub-tag (e.g. SETFORM).
E.g.:
[LL_REPTAG_%test CURRENTVAL CAPITALIZE
SETFORM:field1 /] - Takes the current value of the variable
called "test", capitalizes it, and uses it to set a form field called
"field1".

DATE In the simplest form (with no parameters) this tag converts Date
or formatted data to a user defined format. If a parameter is
DATE:“<format list>” specified, the data can be formatted using any of the modifiers
below.
Support: header, row, footer
For example: [LL_REPTAG=createdate DATE:"%a - %b %d,
%Y" /] would provide a date similar to: Mon - Jan 31, 2004.

Note: if this sub-tag is to be used with the current date then

[LL_REPTAG_DATETIME DATE: /] should be used (instead of the
_DATE tag).

Page 56
 WebReports User Guide

DATE Format Modifiers:

Modifier Description

INPUT Input date format as specified on the admin pages

SHORT Short date format as specified on the admin pages

LONG Long date format as specified on the admin pages

%% A percentage sign

The three-character abbreviated weekday name (e.g., Mon,

%a Tue, etc.)

The three-character abbreviated month name (e.g., Jan, Feb,

%b etc.)

%d The two-digit day of the month, from 01 to 31 (e.g., 01-31)

%j The three-digit day of year, from 001 through 366

%m The two-digit month (e.g., 01-12)

%p AM or PM

%w The 1-digit weekday, from 1 through 7, where 1= Sunday

%y The two-digit year (e.g., 93)

%A The full weekday name (e.g., Monday)

%B The full month name (e.g., January)

%H The two-digit hour on a 24-hour clock, from 00 to 23

%I The two-digit hour, from 01 to 12

%M The minutes past the hour, from 00 to 59

%P AD or BC

%S The seconds past the minute, from 00 to 59

%Y The year, including the century (e.g., 1993)

Page 57
 WebReports User Guide

DEC or DEC:<decrement number> Decrements a numeric value by 1 or a specified decrement number.

By default this sub-tag returns the current tag value minus one and
Support: header, row, footer errors if the tag does not contain a valid integer. If the optional
decrement number has been specified, then the current tag minus
the decrement number is returned.

DECODE:<if1>:<then1> Performs a value by value substitution (similar to the Oracle

or DECODE statement). DECODE's parameters consist of pairs of
DECODE:<if1>:<then1>:<if2>:<then strings which specify a match and a replacement value. There must
2>:...:<else> be at least one pair of strings specified, and it can have as many as
98 pairs in total. The <else> string is optional.
Support: header, row, footer
DECODE looks to see if the data returned by the data tag matches
any of the <if> strings specified in the parameter list. If it finds a
match it replaces the data with the <then> string. If it does not find a
match, it will replace the data with the optional <else> string (if
specified). For example:

Let us say a data tag [LL_REPTAG=STATUS /] is returning numeric

strings that indicate a status such as 0, 1, 2 etc. We want to present
these as meaningful text such as "Completed" "Pending Review"
"Open" respectively. The following DECODE statement would
achieve this:

DECODE:"0":"Completed":"1":"Pending
Review":"2":"Open":"Unknown"

The final "Unknown" parameter means that if none of the values 0, 1

or 2 is found, the string "Unknown" is substituted.

DECSTR:<encodingtype> Decodes the specified string using the selected decoding method.
Currently BASE64 is the only type supported.
Support: header, row, footer

DEF:<value> If the value returned by the main tag is undefined the value specified
here will be used.
Support: header, row, footer

Divides an integer returned in the main tag by the value specified.

DIVIDE:<value> Other subtags can be used in conjunction with this tag, like ROUND
to provide greater precision. For example:
Support: header, row, footer [LL_REPTAG_"10" DIVIDE:2 ROUND:2 /] will resolve to 5.00.

DMEMBERSHIP Returns a comma separated list of Livelink Groups which the user is
a direct member of.
Support: header, row, footer

Page 58
 WebReports User Guide

EMAILINFO:<property> Expects a valid dataID for an email message and returns email data
for that node (similar to the view in an Email Folder). The email
Support: header, row, footer needs to have been uploaded via the Livelink Explorer/Outlook
plugin in order to make use of this tag.

Format Description

Returns True or False based on the

"Attachments" field of the email. If the
ATTACHMENT email has an attachment "true" is
returned; if the email does not have an
attachment "false" is returned.

BCC Returns the "BCC" field of the email.

CC Returns the "CC" field of the email.

FROM Returns the "From" field of the email.

Returns the "On Behalf Of" field of the

ONBEHALF
email.

Returns the "Received Date" field of

RECDATE
the email.

Returns the "Sent Date" field of the

SENTDATE
email.

TO Returns the "To" field of the email.

ENCSTR:<encodingtype> Provides string encoding using the specified format. Currently

BASE64 is the only supported encoding type.
Support: header, row, footer
Converts text characters so that they are appropriate to use as a cell
ESCAPECSV of data in a CSV export.
or
ESCAPECSV:ALLCELLS This means that the following rules are followed:

Support: header, row, footer • If a comma exists in the text then the group of characters is
enclosed in double quotes
• If an end of line character exists in the text then the group of
characters is enclosed in double quotes
• If a double quote character exists in the text then it is
converted to two double quotes and the whole group of
characters is enclosed in double quotes

E.g.
If [LL_REPTAG_1 /] normally returns one "two", three, then
[LL_REPTAG_1 ESCAPECSV /] would return: "one ""two"",
three"
If the optional parameter: ALLCELLS is specified then all cells will
be quoted regardless of the contents of the data cell

Page 59
 WebReports User Guide

ESCAPEHTML Converts characters such as less than or greater than to HTML

escape syntax. For example: If [LL_REPTAG_1 /] normally returns
Support: header, row, footer <hello>,

[LL_REPTAG_1 ESCAPEHTML /]

will return: &lt;Hello&gt;

ESCAPESTR Converts characters such as line feeds, carriage returns and quotes
to the standard C language syntax e.g. \r for carriage returns. This
Support: header, row, footer sub-tag is essential for any script variable assignments as carriage
returns and other characters like quotes will cause an error.
For example: Rows[x] = "[LL_REPTAG_1 ESCAPESTR /]";

ESCAPEURL Converts non-alphanumeric characters into URL hexadecimal

sequences and spaces into the plus-sign ("+") character. For
Support: header, row, footer example, If a tag normally returns the string:
"http://www.bogus.com/somefile",

[LL_REPTAG_1 ESCAPEURL /]

would return:
"https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fwww%2Ebogus%2Ecom%2Fsomefile"

ESCAPEXML Converts data to XML compatible format by escaping special

characters, such as greater-than, less-than, ampersand and
Support: header, row, footer apostrophe.

ESCAPEWR Prevents any WebReport’s tag syntax that may be included in the
data from being interpreted as valid tax syntax.
Support: header, row, footer

EVEN Returns true if the data returned by the main tag is an even number.
Returns false otherwise. This can be used with a ROWNUM tag to
Support: header, row, footer create code that can alternate from row to row (e.g. row color). E.g.

[LL_WEBREPORT_IF "TRUE" == "[LL_REPTAG_ROWNUM ODD /]"

/]
<TR class=oddrow>
[LL_WEBREPORT_ENDIF /]
[LL_WEBREPORT_IF "TRUE" == "[LL_REPTAG_ROWNUM EVEN
/]" /]
<TR class=evenrow>
[LL_WEBREPORT_ENDIF /]

GETCVID Gets the node id of a Customview if it exists in the container

specified by its node id supplied to this subtag.
Support: header, row, footer

GETTEXT Returns the contents of a text-based document specified by the node

id supplied to this subtag.
Support: header, row, footer

Page 60
 WebReports User Guide

HIDE This sub-tag

tag is used to hide the output of a tag.

Support: header, row, footer

HTMLCR Inserts the HTML code <BR> wherever:

• a carriage return and line feed character are found together
Support: header, row, footer
• a single carriage return character is found
• a single line feed character is found.

This sub-tag is useful for correctly formatting long text fields in HTML
that would otherwise be missing carriage returns.

IMEMBERSHIP Returns a comma separated list of Livelink Groups which the user is
a direct or indirect member of.
Support: header, row, footer

INC
Increments a numeric value by 1 or a specified increment number.
number
or
By default this sub-tag
tag returns the current tag value plus one and
INC:<increment number>
errors if the tag does not contain a valid integer. If the optional
increment number has been specified, then the current tag plus the
Support: header, row, footer
decrement number is returned.

LENGTH Returns the length of the data returned in the main tag. For
example, if the data resolved by the main tag was 10 characters
Support: header, row, footer long, using this sub tag would cause the characters 10 to be returned
instead. This sub-tag
tag can be useful for determining data validity
(greater than a minimum number of characters) and HTML SIZE
parameters.
For a Livelink LIST data type, the item at the specified index can be
LIST:<index> retrieved (index starts at 1). For example,
Support: header, row, footer [LL_REPTAG_1 LIST:3 /]
Would return the third item in a list.

Adds the specified padding character to the left of the existing data
LPAD:<pad char><width> to make the result the specified final width. For example, given a
data tag returning the number 123
Support: header, row, footer
[LL_REPTAG_1 LPAD:0:6 /]
returns 000123

This sub-tag allows URLs to be easily built

uilt and elements of Livelink
LLURL:<parms> functionality to be inserted. For example, if your report needs to
contain an image representing the node type, the following could be
Support: header, row, footer
used:
[LL_REPTAG=DATAID LLURL:GIF /] resulting in if DATAID was
a Word document.
For this sub-tag
tag to function correctly, the data returned from the main
tag must be a Livelink object ID - e.g. the DATAID column of the
DTREE table.

Modifier Description
 WebReports User Guide

LLURL:ADDITEM Creates an Add Item menu similar to that found in the

Livelink Header relating to the specified node as supplied to
this sub-tag. Used by itself will create the full menu, while
using the three possible parameters, FOLDER, DOCUMENT
or ITEMMENU will create the individual parts of the Add Item
menu. Only one parameter may be used at a time, if used at
all. The created menu is subject to user permissions, and
only allowed items will be created.

LLURL:ADDITEM:ITEMMENU Returns an oscript representation of the Add Item menu for a

:RAW specific container.

See the TOJSON sub-tag for how to convert this into a data
structure that can be interpreted by JavaScript in the client.
See related tags CAT:RAW and
LLURL:FUNCTIONMENU:RAW.

LLURL:BROWSE Returns a browse URL for usage within a user defined

anchor tag.

LLURL:DEFAULTLINK Returns a default behavior URL.

LLURL:DOWNLOAD Returns a download URL.

LLURL:DROPDOWNLIST Inserts a fully functional drop-down menu showing the

location hierarchy back to the Enterprise. Each value in the
drop-down is hyper-linked allowing users to click anywhere in
the hierarchy.

LLURL:FEATURED Returns the HTML for the featured items pane. The main tag
should be the DATAID of a folder.

LLURL:FETCH Returns a fetch URL.

LLURL:FORMADD Creates the URL to add a form. This LLURL variation can
only be used when the associated tag is a valid Form dataid.
This does not work with workflow related forms.

LLURL:FORMDELETE Creates the URL to delete a form record from the associated
SQL table. This LLURL variation can only be used when the
data source includes rows of data from a valid form SQL
table. It can only be used with a row template data tag or the
[LL_REPTAG_@DATA[x]_y /] tag. This does not work with
workflow related forms.

LLURL:FORMEDIT Creates the URL to edit a form record from the associated
SQL table. This LLURL variation can only be used when the
data source includes rows of data from a SQL table that has
been created by a form template. It can only be used with a
row template data tag or an LL_REPTAG_@DATA... tag.
When used with workflow forms, this LLURL variation
creates the appropriate URL to edit a form in a workflow and
supports an additional parameter to specify a form ID. E.g.
[LL_REPTAG=VOLUMEID LLURL:FORMEDIT:1 /]. If a form
ID is not provided, an ID of 1 is used by default.

LLURL:FUNCTIONMENU Inserts a fully operational function menu for the current node.

Page 62
 WebReports User Guide

LLURL:FUNCTIONMENU:RA Returns the internal oscript representation of a Livelink

W function menu. See related tags CAT:RAW and
LLURL:ADDITEM:ITEMMENU:RAW

LLURL:GIF Inserts the complete HTML for the default node image.
Supports an optional PATH parameter which returns the path
of the image rather than the complete HTML source.

LLURL:GIF:LARGE Optional parameter for LLURL:GIF that inserts the large

Livelink image for the current object. Supports an optional
PATH parameter which returns the path of the image rather
than the complete HTML source.

LLURL:GIF:XLARGE Optional parameter for LLURL:GIF that inserts the extra

large Livelink image for the current object if it is available.
This option is only supported from Livelink 9.7+. Supports
an optional PATH parameter which returns the path of the
image rather than the complete HTML source.

LLURL:HYPERLINKTRAIL Similar to DROPDOWNLIST but this option displays a fully

functional hyperlink trail between the Enterprise and the
current node.

LLURL:INFO AUDIT, CATEGORIES, GENERAL, PRESENTATION,

REFERENCES, SPECIFIC and VERSIONS may all be used
following the INFO parameter to provide a URL to the
Properties page in question. E.g. [LL_REPTAG=DATAID
LLURL:INFO:AUDIT /] would provide a link to the audit tab
of the node. If you wish to refer to a custom tab, use the
value from the URL when viewing the tab.
E.g.\..&objAction=mytab

LLURL:MODIFIED Inserts the HTML for a new or modified image if the node
has been modified or added in the last x days.

LLURL:OPEN Returns an open URL.

LLURL:PROMOTED Returns a set of links for available actions specific to the type
of object specified by a node id. These links are similar to
those found on Livelink browse pages.

LLURL:RENDITION:<Type> Returns the GIF, URL or FUNCTIONMENU associated with a

rendition. If the rendition type is variable (e.g. some nodes
have PDF renditions and others have TIFF renditions) the
DEFAULT operator can be inserted in it's place to establish
which rendition to use based on the priority defined in the
renditions administration section. USENODE is an optional
parameter supported with all the variants which allows the
URL, FUCTIONMENU or GIF from the node to be used if the
specified rendition does not exist.

LLURL:REPORT Returns a report URL.

LLURL:SHORTLINK Returns a URL similar to DEFAULTLINK but in the 9.5+

format. Unlike LLURL:OPEN etc. this option must be used in
conjunction with [LL_REPTAG_URLPREFIX /].

Page 63
 WebReports User Guide

LLURL:SUBTYPEFILTER Returns all of the necessary code to display the subtype filter
list as seen in the standard Content Server 9.7.1 browse
view. This is currently only supported on Content Server
9.7.1 and above. Given the dataid of a folder, this feature will
actually provide the subtypes that are unique within that
folder. In addition, a comma separated list of subtypes ( E.g.
{0,144,30303,...} ) can be specified in the main tag to
indicate the subtypes that should appear in the filter list. The
code generated by this sub-tag will only work if the Content
Server browsecorermenu.js file has been included. This
can be done using [LL_WEBREPORT_JSLIBS COREMENU /]
to include the correct library. For Content Server 10 and
greater please use the 'BROWSE' library selector instead, as
the 'COREMENU' library selector is obsolete.

LLURL:UPALEVEL Inserts the HTML for a fully functional 'browse for parent'
image & link.

LLURL:WEBDAV:LONG Returns a WebDAV URL to access the Livelink item via a

client tool such as Microsoft WebFolders. This URL is in the
long format and can be observed from Properties > WebDAV
on the function menu.

LLURL:WEBDAV:NAME Returns a WebDAV URL Name to access the Livelink item

via a client tool such as Microsoft WebFolders. This value
can be set from Properties > WebDAV on the function menu.

LLURL:WEBDAV:SHORT Returns a WebDAV URL to access the Livelink item via a

client tool such as Microsoft WebFolders. This URL is in the
short format and can be observed from Properties >
WebDAV on the function menu.

LLURL:WFDEFAULTLINK Builds the link to open a workflow if a subworkid is returned

from the main tag. Supports an optional parameter where the
user can specify which tab to open on the Workflow page.
Supported parameters are: GENERAL, STEP, MAP,
MANAGE, AUDIT, ATTACH, COMMENTS, FORMS.

LLURL:WFFUNCTIONMENU Inserts a workflow function menu. Requires that the main tag
returns a subworkid.

Sets all text in the field to lower case.

LOWER

Support: header, row, footer

Returns the value of a MODULUS operation on the data returned
MODULUS:<modulus number> by the main tag. E.g. [LL_REPTAG_&PARM1 MODULUS:7 /] will
return 6 if parm1 contains 2001.
Support: header, row, footer

MULTIPLY:<value> Multiplies an integer returned in the main tag by the value specified.
Other subtags can be used in conjunction with this tag, like ROUND
Support: header, row, footer to provide greater precision. For example:

[LL_REPTAG_"10" MULTIPLY:2 ROUND:2 /] will resolve to 20.00.

Page 64
 WebReports User Guide

Return the same column from the next row of data. If this sub-tag is
NEXT used on the last row of data, a blank string is returned.
Support: row
This sub-tag offers powerful capabilities to create, move, copy and
NODEACTION:<operation> delete content within Livelink and, as such, its effects should be
carefully understood before usage. The sub-tag behaves like the
other WebReports sub-tags in that, whilst you cannot access the
content of nodes that you do not have permissions to do so with
other sub-tags, NODEACTION will not allow the user running the
report to perform an action (e.g. a move) that they would not be
able to perform via the regular interface.

NODEACTION Formatting

Action Operation Description

NODEACTION:ADDVER:TEXT: Expects a dataid from the main tag. Adds a

<text string> version to it containing the value specified
in text string.
ADDVER
NODEACTION:ADDVER:<docu Expects a dataid from the main tag. Adds a
ment> version to it containing the contents of the
latest version of the document specified in
the document parameter.

NODEACTION:COPY:<contain Expects a dataid from the main tag. Copies

er> this node to the location specified in
container. Takes all versions and uses the
same name.

NODEACTION:COPY:<contain Same as previous but only takes the latest

er>:CURRENT (current) version of the source document. If
the source object is a container only the
latest version of items within the container
will be copied.

NODEACTION:COPY:<contain Inherits the category and attribute data from

er>:INHERITATTRS:DESTINATI the destination location.
COPY ON

NODEACTION:COPY:<contain Merges the category and attribute data from

er>:INHERITATTRS:MERGED the source node and the destination
location.

NODEACTION:COPY:<contain Retains the source category and attribute

er>:INHERITATTRS:SOURCE data when copied to the destination
location.

NODEACTION:COPY:<contain Inherits the permissions from the

er>:INHERITPERMS destination container.

NODEACTION:COPY:<contain Default behavior for NODEACTION is as if

Page 65
 WebReports User Guide

er>:INHERITRMOFF the action occurred through the Livelink

interface; that is a copied node will inherit
RM Classifications from the new parent
container. This option can be used to stop
the inheritance of the RM Classification. If
an existing RM Classification is applied to
the source node that will be retained if no
RM Classification is applied the new node
will remain with an RM Classification. This
option can be used to override the "Records
Management Administration", "Managed
Objects", "Inherit from" options but cannot
be used to force the inheritance of an RM
Classification if the appropriate RM settings
are not present.

NODEACTION:COPY:<contain Uses the optional NEWNAME parameter to

er>:NEWNAME:<name> specify a new name for the destination
node.

NODEACTION:COPY:<contain If the node name is not unique in the

er>:UNIQUEONLY destination container the node will not be
copied. This option can be used with or
without the NEWNAME option.

The copy parameters above can be used in any combination and in any order.
See NODEACTION:MOVE below for an example of combining multiple
parameters.

NODEACTION:CREATE:DOC:< Expects the dataid of a document in the

container><name> main tag. The content of the latest version
of this document is used as the source of a
new document which is created in
container.

NODEACTION:CREATE:FOLD Works the same way as CREATE:DOC

ER:<container><name> above but the data in the main tag is
ignored.

NODEACTION:CREATE:GENE Creates a generation pointing to the latest

CREATE RATION:<container><name> version of the node specified in the main
tag.

NODEACTION:CREATE:SHOR Creates a shortcut pointing to the node

TCUT:<container><name> specified in the main tag.

NODEACTION:CREATE:URL:< Expects a URL in the main tag (must be

container><name> fully qualified, e.g. http://) and creates a
new URL object in container.

All NODEACTION:CREATE options support INHERITATTRS,

INHERITPERMS and UNIQUEONLY. UNIQUEONLY and INHERITPERMS
behave the same as in NODEACTION:COPY and NODEACTION:MOVE.
INHERITATTRS behaves slightly differently because there is no concept of
existing categories (this is a new node). INHERITATTRS will therefore always
provide the equivalent of INHERITATTRS:DESTINATION. If not specified, no

Page 66
 WebReports User Guide

categories will be applied.

NODEACTION:DELETE Deletes the node returned from the main

DELETE
tag.

NODEACTION:DISPLAY:LIST Expects a dataid from the main tag. Sets

the display of that item to LIST (as seen on
the general tab of the node).

NODEACTION:DISPLAY:FEAT Expects a dataid from the main tag. Sets

DISPLAY URED the display of that item to FEATURED (as
seen on the general tab of the node).

NODEACTION:DISPLAY:HIDDE Expects a dataid from the main tag. Sets

N the display of that item to HIDDEN (as seen
on the general tab of the node).

NODEACTION:LOCK:<version Locks the specified version of a document.

LOCK
number> Also see NODEACTION:UNLOCK.

NODEACTION:MAXVERS:<ver Sets the maximum number of versions for a

sions> document or a customview in the same way
as can be set from the object's specific tab.
Livelink provides an opentext.ini setting,
VersionLimitDefault, which defines the
default maximum number of versions. A
node can be set to this value using the
optional DEFAULT parameter. E.g.
[LL_REPTAG=DATAID
NODEACTION:MAXVERS:DEFAULT /]. To
MAXVERS set a node to have an unlimited number of
versions use the NOLIMIT option. E.g.
[LL_REPTAG=DATAID
NODEACTION:MAXVERS:NOLIMIT /]

See also
NODEACTION:PURGEVERSIONS

NODEACTION:MOVE:<contain Expects a dataid from the main tag. Moves

er> this node to the location specified in
container.

NODEACTION:MOVE:<contain Moves the node to container and inherits

er>:INHERITATTRS:DESTINATI categories and attributes from there.
ON

MOVE NODEACTION:MOVE:<contain Moves the node to container and merges

er>:INHERITATTRS:MERGED categories and attributes from the source
node and container.

NODEACTION:MOVE:<contain Moves the node to container and retains

er>:INHERITATTRS:SOURCE categories and attributes from the source
node.

NODEACTION:MOVE:<contain Moves the node to container and inherits

Page 67
 WebReports User Guide

er>:INHERITPERMS permissions from container.

NODEACTION:MOVE:<contain Default behavior for NODEACTION is as if

er>:INHERITRMOFF the action occurred through the Livelink
interface; that is a copied node will inherit
RM Classifications from the new parent
container. This option can be used to stop
the inheritance of the RM Classification. If
an existing RM Classification is applied to
the source node that will be retained if no
RM Classification is applied the new node
will remain with an RM Classification. This
option can be used to override the "Records
Management Administration", "Managed
Objects", "Inherit from" options but cannot
be used to force the inheritance of an RM
Classification if the appropriate RM settings
are not present.

NODEACTION:MOVE:<contain Optionally renames the moved node.

er>:NEWNAME:<name>

NODEACTION:MOVE:<contain If the node name is not unique in the

er>:UNIQUEONLY destination container the node will not be
moved. This option can be used with or
without the NEWNAME option.

The move parameters above can be used in any combination and in any
order. E.g. [LL_REPTAG=DATAID
NODEACTION:MOVE:1234:INHERITATTRS:MERGED:INEHRITPERMS:NE
WNAME:"my node" /] to combine the source and destination categories,
inherit permissions from the destination and rename the moved node to my
node.

In order to attach Livelink items to a workflow being initiated by a WebReport

(destination tab) see SETWFATTACH. See Action Sub-tags for more
information.

NODEACTION:MOVEPROVIDE Changes the storage provider for the

R:<provider name>:<version version. Available storage providers can be
number> identified in the Configure Storage
Providers administration page. To change
a storage provider to the default provider
use DEFAULT as the provider name. If no
version number is provided the latest
version will be moved to the new provider. If
MOVEPROVIDE ALL is specified in place of the version
R number all versions of the node will be
moved to the new provider. Users should
carefully consider the performance
implications of this sub-tag - it is not only
updating the database but it is moving the
underlying storage location. This means a
single node with 30 versions will result in 30
files being moved - if these are each one
mega byte documents there is a

Page 68
 WebReports User Guide

considerable overhead on the system. It is

recommended to do operations like this
outside of working hours and in a throttled
manner.

NICKNAME NODEACTION:NICKNAME:<ne Sets the nickname of the node returned

w nickname> from the main tag.

NODEACTION:OWNEDBY If the current user has permission to do so,

this changes ownership of node specified to
the current user.
OWNEDBY
NODEACTION:OWNEDBY:<ne If the current user has permission to do so,
wid> this changes ownership of the node
specified to the user specified by the
<newid> parameter.

NODEACTION:PROMOTE Where advanced version control is being

used on a node this command allows the
PROMOTE
latest version to be promoted to a major
version.

NODEACTION:PURGEVERSIO Purge versions of the node whilst retaining

NS:KEEP:<versions to keep> a fixed number of versions.

NODEACTION:PURGEVERSIO Purge a fixed number of node versions. If

PURGEVERSIO NS:REMOVE:<versions to the number to purge is greater than or
NS remove> equal to the existing number of versions,
one version will be retained.

NODEACTION:PURGEVERSIO Purge a specific version of a node.

NS:<version number>

NODEACTION:RENDITION:<ty Triggers a rendition of the specified type.

RENDITION pe> Note: This functionality is only available if
the Renditions module is installed

NODEACTION:RENAME:<new Sets the name of the node returned from

RENAME
name> the main tag

NODEACTION:RESERVE Expects a dataid from the main tag. Sets

the node to be reserved by the person
running the WebReport.
RESERVE
NODEACTION:RESERVE:<use An optional tag variation for RESERVE that
rid> allows a Livelink user id to be specified as
the person reserving the document.

NODEACTION:UNLOCK:<versi Unlocks the specified version of the

UNLOCK
on number> document. Also see NODEACTION:LOCK.

NODEACTION:UNRESERVE Unreserves the node returned from the

UNRESERVE
main tag.

Page 69
 WebReports User Guide

For a valid Livelink object ID this sub-tag will return information

NODEINFO:<format> about the current object (node) according to the format parameter
that has been provided. The format parameter accepts most
Support: header, row, footer
columns from the DTREE table in the Livelink database plus
several other parameters unique to WebReports. The main fields
are listed here. The sub-tag acts on either a Livelink nodeid or
nickname.

NODEINFO Formatting

Format Description
The ID of the user who has been assigned to this
ASSIGNEDTO
object (usually a task).
Returns a numeric value representing the object's
CATALOG catalog value (0 = listed, 1 = featured, and 2 =
hidden).

CHILDCOUNT The number of children the node has.

CREATEDBY The ID of the user who created the node.

COMMENT The description for the node.

CREATEDATE The date the node was created.

The date that the node was assigned (usually a

DATEASSIGNED
task).
The date that the node was completed (usually a
DATECOMPLETED
task).

DATEDUE The date that the node is due (usually a task).

DATESTARTED The date that the node was started.

Will return the depth of a given object from the

DEPTH
Enterprise.
Returns the path of an object in the file store (only
EFSPATH
available to Admin user).
The specific data stored for the node. This data
EXTENDEDDATA requires additional sub-tags such as ASSOC in
order to extract useful information.

GROUPID The ID of the group who owns the node.

All the NODEINFO commands can be initiated with

either a nickname or a nodeid. This means the user
ID might not know the nodeid of an item -
NODEINFO:ID will allow it to be retrieved by
providing a nickname.

JSON Export the NODEINFO record as a JSON string.

Page 70
 WebReports User Guide

Returns a colon separated list of nodeids starting

LOCATION with the Enterprise and ending with the current
node.

MAXVERSION The maximum number of versions for the node.

MODIFYDATE The date the object was modified.

NAME The name of the node.

NICKNAME The nickname of a node.

Will retrieve the dataid of the original node that a

ORIGID
Shortcut to Generation points to.

PARENTID The ID for the parent of the node.

The full path of a Livelink node from the topmost

node. This is represented as a text string delimited
PATH
by colons starting with the topmost node. For
example: Enterprise:Customers:ABC company

PRIORITY The priority of a node (usually a task).

RESERVED The numeric reservation status of the node.

RESERVEDBY The ID for the user who has reserved the node.

RESERVEDDATE The date that the node was reserved.

The size of the current node. If the DETAIL option is

specified, NODEINFO:SIZE:DETAIL, the exact size
SIZE is returned. Alternatively NODEINFO:SIZE:BYTES
can be used to extract the exact size in bytes as an
integer (allowing additional formatting).

STATUS The status of a node (usually a task).

The type of the node in words e.g. Document or

SUBNAME
Folder.
The type of the node in numeric form (sometimes
SUBTYPE
known as sub-type).

USERID The ID of the user who owns the node.

VERSIONNUM The number of the current version of the node.

The volume ID for the node. The Volume ID usually

represents the top level container for an object.
This field is sometimes referred to as the
VOLUMEID
'OWNERID'. For objects stored under a project
workspace a negative project ID number will be
returned as the Volume ID.

ODD Returns true if the data returned by the main tag is an odd number.

Page 71
 WebReports User Guide

Returns false otherwise. This can also be used as per the example for
Support: header, row, footer the EVEN tag.

ODDEVEN Returns either ODD or EVEN depending on the data returned by the main
tag. If the main tag data is not a valid integer then this sub-tag returns an
Support: header, row, footer empty string. This sub-tag can be used with a tag like ROWNUM to set an
appropriate style for each row. The ODDEVEN sub-tag also allows two
additional parameters to be specified - if provided these two parameters
will be returned alternately instead of ODD/EVEN. The example below
shows how to use the standard Livelink styles, BrowseRow1 and
BrowseRow2 to allow each row to have an alternating color. The class
statement for each row would alternate between BrowseRow1 and
BrowseRow2.
The following would be included in the <HEAD> of the reportview file:
<STYLE TYPE="text/css">
.BrowseRow1 {background-color: white; color: black; font-size: x-small; font-family: Arial, Helvetica, sans-serif;}
.BrowseRow2 {background-color: #ccff99; color: black; font-size: x-small; font-family: Arial, Helvetica, sans-
serif;}
</STYLE>
Each row includes the following TR statement:

<TR class=[LL_REPTAG_ROWNUM ODDEVEN:BrowseRow1:BrowseRow2 /]>

After processing each row would resolve to either:

<TR class=BrowseRow1>

or:

<TR class=BrowseRow2>

ONERROR:<parm> Used to specify alternative text to be used for any sub-tag error. Some sub-tags
will return an error message if the data and or one of the sub-tag's expected
Support: header, row, footer parameters does not have the correct type or value as required to perform the
sub-tag function. This sub-tag allows the default error message for a particular
tag to be displayed in several ways or defined by the developer. This sub-tag
should usually appear after whichever sub-tag might generate an error
condition. It is possible to have more than one ONERROR sub-tag in order to
handle errors differently for different sub-tags. In the event that only one
ONERROR sub-tag has been provided, the position in the sub-tag list is not
important and the ONERROR sub-tag will apply to any errors for any sub-tags
in the list. The following options for using this sub-tag include:

Format Description
This option will replace any standard error
message with a blank string, useful for
ONERROR:BLANK
preventing error messages from being
displayed.
This option will display a short version of the
ONERROR:SHORT error message consisting of the sub-tag in
question and an error number.

Page 72
 WebReports User Guide

This option will display a full error message

ONERROR:LONG
for the sub-tag in question.
ONERROR:CUSTOM:< This option allows the developer to specify
error message> their own error message for a sub-tag.

Example

[LL_REPTAG=VALUE LIST:1 ONERROR:CUSTOM:"Invalid list" INC:1

ONERROR:LONG /]

In this example the message "Invalid list" would be returned for this tag if the
LIST sub-tag had returned an error. If the LIST sub-tag does not cause an error
but the INC sub-tag does, then the standard error message would be returned.

PATCHANGE:<find Returns a modified version of the main tag based on the find and replace
pattern>:<new pattern> patterns specified.
or
PATCHANGE:<find The find pattern is specified with a series of special operators as per the table
patt>:<new patt>: below. This is a simplified and slightly modified subset of UNIX's regular
<ignoreCase?> expression pattern matching. For Livelink developers this syntax is based on
the Oscript PATFIND and PATCHANGE bulletins. This is almost identical to the
Support: header, row, footer PATFIND syntax but includes the ability to specify parts of the find pattern which
can be referenced for substitution in the replace pattern. If no match if found,
the original tag contents is returned unchanged.

The replace pattern can also include some special characters which are also
shown below. The replace pattern is normally a fixed pattern of characters but
any characters to be retained from the find pattern are enclosed in the <...>
characters and then inserted in the replace pattern using the # symbol. By
default this sub-tag ignores the case of characters when matching. Specifying
FALSE as a third parameter causes the change operation to be case sensitive.
For more detailed information about PATFIND or PATCHANGE the Livelink SDK
documentation should be consulted.

Find Pattern Special Characters

Match exact character (c is any character

c
here)
Match escaped character ( such as @%, @[,
@c
@*)

? Match any character except end of line

% Match beginning of line

Match end of line (null string before end of

$
line)
Match character class (any one of 'these'
[...] characters,
such as [abc] or [a-z])
Match negated character class (all but these
[!...] characters,
such as [! ] for no spaces)

Page 73
 WebReports User Guide

Match zero or more occurrences of the

* previous element,
such as [0-9]* for zero or more digits
Match one or more occurrences of the
+ previous element,
such as [A-Za-z]+ for one or more letters
Brackets tagged material which is specially
<...> extracted for
later reference or use

Replace Pattern Special Characters

& Ditto (Whole String)

@c Escaped character ( such as @&)

#n Tagged substring insertion

PATCHANGE Examples:

This example of the PATCHANGE sub-tag assumes that the associated tag
contains the string:

This is a test sentence 123, end

PATCHANGE:"?* <t?+t> *sen[!0-9]+<[0-9]+>?*":"Word: #1; Number: #2"

would return:
Word: test; Number: 123

In this example:

• Any characters which are matched (but not enclosed in < >) will not be
included in the replacement
• <t?+t> finds a match with the word "test". Because it is the first "tagged
substring", this word is substituted in place of #1 in the replace string.
• <[0-9]+> finds a match with the numbers "123". Because it is the
second "tagged substring", these characters are substituted in place of
#2 in the replace string.
• The part of the find pattern: sen[!0-9]+ finds the characters "sen"
followed by 1 or more characters which are NOT numbers.

Returns either TRUE or FALSE depending on whether the specified pattern is

found within the string returned by the main tag. The find pattern is specified
with a series of special operators as per the table below. This is a simplified and
PATFIND:<find pattern>
slightly modified subset of UNIX's regular expression pattern matching. For
or
Livelink developers this syntax is based on the Oscript PATFIND and
PATFIND:<find
PATCHANGE built-ins. By default this sub-tag ignores the case of characters
pattern>:<ignoreCase?>
when matching. Specifying FALSE as a second parameter causes the find
operation to be case sensitive. For more information about PATFIND or
Support: header, row, footer
PATCHANGE the Livelink SDK documentation should be consulted.

Page 74
 WebReports User Guide

Match exact character (c is any character

c
here)
Match escaped character ( such as @%, @[,
@c
@*)

? Match any character except end of line

% Match beginning of line

Match end of line (null string before end of

$
line)
Match character class (any one of 'these'
[...] characters,
such as [abc] or [a-z])
Match negated character class (all but these
[!...] characters,
such as [! ] for no spaces)
Match zero or more occurrences of the
* previous element,
such as [0-9]* for zero or more digits
Match one or more occurrences of the
+ previous element,
such as [A-Za-z]+ for one or more letters

PATFIND Examples:

This example of the PATFIND sub-tag assumes that the associated tag
contains the string:

This is a test sentence 123, end

PATFIND:"sen?+ *[0-9]+" would return TRUE

This pattern specifies the specific characters: sen followed by 1 or more

characters: ?+; 0 or more spaces: <sp>*; and 1 or more digits: [0-9]*. This
would match on the string: "sentence 123" and therefore the tag returns true.

PERMACTION:<operation This sub-tag provides the flexibility to add, remove and modify permissions of
> content within Livelink. Because of the powerful nature of this sub-tag, it's
effects should be carefully understood before usage. The sub-tag behaves like
Support: header, row, footer the other WebReports sub-tags in that you cannot modify the permissions of
nodes that you do not have permissions to do so via the regular interface. The
key difference is that using WebReports allows these changes to be automated
so they can be done much faster than through the interface.

Page 75
 WebReports User Guide

PERMACTION Options

Action Operation Description

Removes the user or group specified by

PERMACTION:ACL:<userID>:REMOVE <userID> from a Livelink object's permission
ACL.
Updates the permissions specified by
ACL
<perms> for the user or group specified by
PERMACTION:ACL:<userID>:UPDATE:<p
<userID> in a Livelink object's permission
erms>
ACL. If the user or group specified is not
currently in the ACL, they will be added.
Updates the permissions specified by
PERMACTION:OWNER:UPDATE:<perms
<perms> for the current owner in the Livelink
>
object's Default Access.
Sets the owner section of the default access
PERMACTION:OWNER:CHANGE:<userID for a Livelink object's permissions to the
OWNER >:<perms> user specified by <userID> with the
permissions specified by <perms>.
Removes the current owner from the Default
Access section of permissions for the
PERMACTION:OWNER:REMOVE
Livelink object. This will set the OWNER
section of Default Access to "No Owner".
Updates the permissions specified by
PERMACTION:OWNERGROUP:UPDATE:
<perms> for the current owner group in the
<perms>
Livelink object's default access.
Sets the owner group section of the default
PERMACTION:OWNERGROUP:CHANGE access for a Livelink object's permissions to
:<userID>:<perms> the group specified by <userID> with the
OWNERGROUP
permissions specified by <perms>.
Removes the current owner group from the
Default Access section of permissions for
PERMACTION:OWNERGROUP:REMOVE the Livelink object. This will set the owner
group section of Default Access to "No
Owner Group".
Updates the permissions specified by
PERMACTION:PUBLIC:UPDATE:<perms> <perms> for public access in the Livelink
object's default access.
Removes public access from the Default
PUBLIC
Access section of permissions for the
PERMACTION:PUBLIC:REMOVE Livelink object. This will set the public
access section of Default Access to "No
Public Access".
Updates the Role specified by <role> for the
user or group specified by <userID> in the
Project's Participant page. If the user or
PERMACTION:<role>:UPDATE:<userID>
group specified is not a Project Participant,
they will be added. This operation is only
supported by PPM objects.
<role> Removes the user or group specified by
(Projects only) PERMACTION:<role>:REMOVE:<userID <userID> from the Role specified by <role>
> in the Project's Participant page. This
operation is only supported by PPM objects.
Removes all users and groups with the
specified <role> from the Project's
PERMACTION:<role>:REMOVE
Participant page. This operation is only
supported by PPM objects.

This sub-tag expects the data id of the content in Livelink the user wants to perform permission actions upon,
to be specified in the main tag. There are two ways to specify permissions for any action that requires
<perms>; either a decimal number representing a binary bit mask for Livelink permissions, which some

Page 76
 WebReports User Guide

developers may be familiar with (and unfortunately is too much to display here), or instead the user can
specify a list of permissions using any combination of the following keywords:

Keyword Permission Affected

SEE See

SEECONTENTS See Contents

MODIFY Modify

EDITATTRS Edit Attributes

RESERVE Reserve or Checkout

DELETEVERS Delete Versions

DELETE Delete the Object

EDITPERMS Edit Permissions

ADDITEMS Add Items

The permissions specified in this sub-tag follow the permissions model of the Livelink interface, meaning that
selecting just one permission will also set the other required permissions, eg. choosing "MODIFY" will set the
"See", "See Contents" and "Modify" permisisons for an object.

To specify permissions for WPM objects (Eg. discussions, channels, task lists, etc), the following table displays
the keywords that can be substituted for <perms> in any of the applicable PERMACTION operations:

Keyword

NONE

READ

WRITE

ADMINISTER

To specify permissions for PPM objects (Eg. Projects), the following table displays the 3 types of roles that can
be substituted for <role> in the applicable PERMACTION operations:

Page 77
 WebReports User Guide

Keyword

COORD

MEMBER

GUEST

Where COORD indicates a Coordinator. For the scenario where PUBLIC permissions can be updated for PPM
objects (PERMACTION:PUBLIC:UPDATE:<perms>), the acceptable values for <perms> in this case is
ENABLED or DISABLED.

Examples

If a user creating a WebReport wants to add a user with a user ID of 1234 to the ACL of an object (in this case
DATAID), with the permissions of See and See Contents, they could use either:

[LL_REPTAG=DATAID PERMACTION:ACL:1234:UPDATE:"SEE,SEECONTENTS" /] which is using the list

of keywords to specify the permissions to add,

or

[LL_REPTAG=DATAID PERMACTION:ACL:1234:UPDATE:36995 /] which is specifying a decimal

representation of the binary bit mask for See and See Contents.

PERMCHECK:<parm> Takes the object id returned by the data tag and checks if the current user
or (or the specified user) has permission to perform the specified action for
PERMCHECK:<parm>:<userid> that object. Either TRUE or FALSE is returned depending on the result of
this verification.
<parm> = SEECONTENTS, EDIT
or DELETE

Support: header, row, footer

Page 78
 WebReports User Guide

Notes on using PERMCHECK:

• When this tag is used, the value that would normally be returned by the main tag is replaced by either
TRUE or FALSE. E.g. if [LL_REPTAG=DATAID /] normally returns “123456”, [LL_REPTAG=DATAID
PERMCHECK:SEE /] would return either “TRUE” or “FALSE”
• This tag is only valid when used with a tag that normally returns a valid Livelink object id. For example,
IDs, DATAIDs and VOLUMEIDs. An invalid report tag will cause this sub-tag to return false.
• The specified actions (see, edit, delete) map to Livelink permissions as shown in the chart below. To use
this chart, find the highest level of Livelink permission that the user is expected to have to return true from
this tag. Then use the setting listed under PERMCHECK Action.

Permcheck Action Forms DTREE Objects

NONE

SEE

SEE CONTENTS SEE SEE CONTENTS

EDIT
EDIT STATIONERY MODIFY
DATA
USE SQL TABLE
EDIT
EDIT SUBMISSION
ATTRIBUTES
MECHANISM
DELETE
EDIT
VERSIONS

ADMINISTER
DELETE DELETE
FORM

DELETE RESERVE

EDIT
DELETE
PERMISSIONS

Page 79
 WebReports User Guide

Permissions Tag Examples:

If the EDIT action has been specified against a form dataid, e.g. [LL_REPTAG=DATAID PERMCHECK:EDIT
/], then the tag will only return true if the user has at least Edit Stationery Data permission for the associated
form.

To make sure that a delete button is only visible for users who have “Administer Form” permission to an
associated form, the following WebReport declaration could be used (this assumes that form Dataid is being
returned in the underlying report data :

[LL_WEBREPORT_IF “[LL_REPTAG=DATAID PERMCHECK:DELETE /]” == “TRUE” /]

<INPUT TYPE=BUTTON NAME=”del” VALUE=”Delete” ONCLICK=”deleteItem()”>
[LL_WEBREPORT_ENDIF /]

This could also be done using JavaScript code as below; however, this code will still be visible if a user “views
source” from their browser.
If ( “[LL_REPTAG=DATAID PERMCHECK:DELETE /]” == “TRUE” ) {
document.write(‘<INPUT TYPE=BUTTON NAME=”delbutton” VALUE=”Delete” ONCLICK=”deleteItem();”>’);
};

POCOPY:<parm>
Provides access to Physical Objects data associated with the main
Support:header, row, footer copy of the physical item. This information can usually be found
of the Circulation tab of Physical Items.

If the Physical Objects module is not installed this sub-tag returns

nothing for all options.

Description in
Modifier
Livelink interface

POCOPY:UNIQUEID Unique ID

POCOPY:LOCATION Current Location

POCOPY:BORROWEDBY Unique ID

POCOPY:OBTAINEDBY Borrowed By

POCOPY:COMMENT Comment

POCOPY:BORROWEDDATE Borrowed Date

POCOPY:RETURNDATE Return By Date

POCOPY:BOXID Box ID

See also POINFO for other Physical Objects functionality.

Page 80
 WebReports User Guide

POINFO:<parm>
Provides access to Physical Objects data found on Physical Items.
Support: header, row, footer
If the Physical Objects module is not installed this sub-tag returns
nothing for all options.

Description in
Modifier
Livelink interface

POINFO:ITEMTYPE Physical Item Type

POINFO:HOMELOC Home Location

POINFO:KEYWORDS Keywords

POINFO:FROM From Date

POINFO:TO To Date

POINFO:LOCTYPE Locator Type

POINFO:REFRATE Ref Rate

POINFO:OFFSITEID Offsite Storage ID

POINFO:FACILITY Facility

POINFO:AREA Area

POINFO:LOCATOR Locator

POINFO:TXID Transfer ID

POINFO:CLIENT Client

POINFO:TEMPID Temporary ID

See also POCOPY for other Physical Objects functionality.

PREV Return the same column from the previous row of data. If this sub-
tag is used on the first row of data, a blank string is returned.
Support: row

Page 81
 WebReports User Guide

RANGE<start index> For any list - formatted as: {'item1','item2'} - , returns a range from
or the original list based on a specified start index and an optional
RANGE<start index>:<end index> end index. This sub-tag is identical to the SLICE sub-tag but only
works with LISTs. All indices count starting at 1 (one) so the slice
Support: header, row, footer will include all characters starting from and including the <start
index> and concluding with and including the <end index> (if one
is specified). If end index is omitted or exceeds the total length of
the string, then the remainder of the string is used. A LIST follows
the Livelink LIST convention where the first character is a {, the
last character is a } and each element is separated by a comma.
This output of this sub-tag is a list in the same format. A LIST can
be de-referenced using the LIST sub-tag.

RANGE Examples:

These different examples of the RANGE sub-tag show the

different results which would be produced, assuming the
associated tag contained the list:

{'Apple','Pear','Orange','Mango'}

RANGE:3 would return: {'Orange','Mango'}

RANGE:2:3 would return: {'Pear','Orange'}

RANGE:3:100 would return: {'Orange','Mango'}

RANGE:2:3 LIST:1 would return: 'Pear'

Allows indexing of the Livelink RECARRAY data type. If the data
RECARRAY:<rowIndex>:<colindex> returned by the data source is an oscript RECARRAY (a Livelink
or data structure consisting of a list of RECORDS) the value of the
RECARRAY:<rowIndex>:<fieldname> field specified by <rowIndex> and <colIndex> or <fieldName> is
returned (and only that value). Note this sub-tag can be used
Support: header, row, footer
repetitively and/or in combination with other sub-tags such as
ASSOC and LIST to access information in complex data
structures.

Allows indexing of the Livelink RECORD data type. If the data

RECORD:<index> returned by the data source is an oscript RECORD (a Livelink
or data structure) the value of the field specified by <index> or
RECORD:<fieldName> <fieldName> is returned (and only that value). Note, this sub-tag
can be used repetitively and/or in combination with other sub-
Support: header, row, footer
tags such as ASSOC and LIST to access information in complex
data structures.

Performs a “replace all” action on the items of data pulled from

REPLACE:<parm1>:<parm2> the data source. All occurrences of the <parm1> string are
replaced by <parm2>.
Support: header, row, footer
E.g. [LL_REPTAG=PRIORITY REPLACE:3:Low /] would result
in all occurrences of the number ‘3’ in the Priority field being
replaced with ‘Low’. Note there can be no spaces between
REPLACE <parm1> and <parm2>. Use only the colon
separator.

Page 82
 WebReports User Guide

Provides the ability to change Records Management data found

RMACTION:<parm>:<new value> on the Records Detail tab of Records (Livelink nodes such as
documents) that are being managed with the Records
Support: header, row, footer
Management module.

If the Records Management module is not installed this sub-tag

returns nothing for all options.

Modifier Description in Livelink

Interface
RMACTION:RECORD
Record Date
DATE:<new value>

RMACTION:STATUS:<
Status
new value>

RMACTION:STATUSD
Status Date
ATE:<new value>

RMACTION:RECEIVE
Received Date
DDATE:<new value>

RMACTION:ESSENTI
Essential
AL:<new value>

RMACTION:OFFICIAL:
Official
<new value>
RMACTION:STORAG
EMEDIUM:<new Storage Medium
value>
RMACTION:ACCESSI
Accession
ON:<new value>

RMACTION:SUBJECT:
Subject
<new value>

RMACTION:AUTHOR:
Author or Originator
<new value>

RMACTION:ADDRESS
Addressee(s)
EE:<new value>
RMACTION:OTHERA
DDRESSEE:<new Other Addressee(s)
value>
RMACTION:ORIGINAT
Originating Organization
IONORG:<new value>

RMACTION:UPDATEC
Update Cycle Period
YCLE:<new value>
RMACTION:NEXTREV
IEWDATE:<new Next Review Date
value>
RMACTION:LASTREVI
Last Review Date
EWDATE:<new value>

Page 83
 WebReports User Guide

Provides meta data information unique to RM Classification

RMCLASS:<parm> objects. Requires the dataid of the RM Classification itself to be
returned from the main tag. If needing to access details of an RM
Support: header, row, footer
Classification from the node to which it is applied the RMINFO
sub-tag can be used: [LL_REPTAG=DATAID RMINFO:CLASSID
RMCLASS:xxx /]. RSI details can be accessed in a similar
fashion with the RSI sub-tag. E.g: [LL_REPTAG=DATAID
RMINFO:CLASSID RMCLASS:RSI RSI:URL /] would get the
URL to open an RSI based purely on the dataid of the node the
RSI/RM Classification is applied to.

It should be noted that an RM Classification is just a standard

Livelink node type and therefore basic meta data associated with
the node is available using the NODEINFO sub-tag. E.g.
[LL_REPTAG=DATAID NODEINFO:CREATEDATE /] will return
the date the RM Classification was created. This differs from
RMCLASS which returns meta data that is unique to the RM
Classification object subtype and only found on the specific tab of
such objects.

If the Records Management module is not installed this sub-tag

returns nothing for all options.

Page 84
 WebReports User Guide

RMCLASS Options

Modifier Description in Livelink interface

FILENUMBER File Number

CREATIONDATE Creation Date

STATUS Status

STATUSDATE Status Date

ESSENTIAL Essential

STORAGEMEDIUM Storage Medium

DISPOSITIONAUTH Disposition Authority

UPDATECYCLE Update Cycle Period

CLOSED Closed Flag

RSI RSI

SUBJECT Subject

KEYWORDS Keywords

LASTADDDATE Last Addition Date

SELECTABLE Selectable

Page 85
 WebReports User Guide

Provides access to Records Management data found on the

RMINFO:<parm> Records Detail tab of Records (Livelink nodes such as
documents) that are being managed with the Records
Support: header, row, footer
Management module.

The three options RMCLASSIFICATION, FILENUMBER and RSI

relate more to the RM Classification but are provided here so that
everything from the Records Detail tab can be returned from this
one sub-tag in exactly the same format. Similarly, slightly more
generic data than these three options can be returned using
RMCLASS sub-tag.

If the Records Management module is not installed this sub-tag

returns nothing for all options.

Page 86
 WebReports User Guide

RMINFO Options

Modifier Description in Livelink interface

RECORDOFFICER Record Officer

RECORDDATE Record Date

RECORDTYPE Record Type

STATUS Status

STATUSDATE Status Date

RECEIVEDDATE Received Date

ESSENTIAL Essential

OFFICIAL Official

STORAGEMEDIUM Storage Medium

ACCESSION Accession

SUBJECT Subject

RECORDSMANAGERGROUP Records Manager Group

AUTHOR Author or Originator

ADDRESSEE Addressee(s)

OTHERADDRESSEE Other Addressee(s)

ORIGINATIONORG Originating Organization

UPDATECYCLE Update Cycle Period

NEXTREVIEWDATE Next Review Date

LASTREVIEWDATE Last Review Date

The dataid of the primary RM

Classification applied to this node. Using
this sub-tag option we can easily access
CLASSID
the RMCLASS sub-tag. E.g.
[LL_REPTAG=DATA RMINFO:CLASSID
RMCLASS:RSI /]
The path of the primary RM Classification
RMCLASSIFICATION
applied to the node

Page 87
 WebReports User Guide

The RSI associated with the primary RM

Classification applied to the node. Note
that the RSI returned from this sub-tag
RSI
can be different to the RSI returned from
RMCLASS:RSI - which is the RSI applied
to the RM Classification itself
The File Number of the primary RM
FILENUMBER
Classification applied to the node

Page 88
 WebReports User Guide

Provides access to meta data specific to the Record Type object

RMTYPE:<parm> from the Records Management module.
Support: header, row, footer
See the RMCLASS sub-tag for information on how to access RSI
data from the RM Classification node.

If the Records Management module is not installed this sub-tag

returns nothing for all options.

RMTYPE Options

Modifier Description in Livelink interface

RSI RSI

DEFAULTTYPE Default Type

Rounds a numeric value by the specified ROUND parameter. If

ROUND:<round number > no ROUND parameter is specified, it defaults to 2.
Support: header, row, footer
Examples:

25.479 ROUND:2 would return: 25.48

45 ROUND:3 would return: 45.000 // Zeroes padded
50.99 ROUND:0 would return: 51
-4.545 ROUND:1 would return: -4.5

The ROUND parameter must be greater than or equal to 0 and

an integer. An error occurs if the tag does not contain a valid
integer or real number. Zeroes are padded to the specified
ROUND parameter if no decimal portion is present (See second
example).

Add padding characters to the right of existing data. Add enough

RPAD:<pad char>:<width> characters to fill the field up to the specified width. If there is a
mantissa, then only the width of the number following the decimal
Support: header, row, footer
points is used. For example, given a data tag returning the
number 123.456
[LL_REPTAG_1 RPAD:9:5 /]
would return: 123.45699
Given a data tag returning the number 123
[LL_REPTAG_1 RPAD:9:5 /]
would return: 12399

Page 89
 WebReports User Guide

A Record Series Identifier (RSI) allows records managers to

RSI apply retention and destruction information to electronic records
in Livelink. You can define new RSIs or edit existing RSIs via the
Support: header, row, footer
Enterprise menu followed by the Records Management option
followed by the RSI link. This sub-tag allows access to the meta-
data associated with any given RSI.

See the RMCLASS sub-tag for information on how to access RSI

data from the RM Classification node.

If the Records Management module is not installed this sub-tag

returns nothing for all options.

Modifier Description in Livelink interface

RSI:RSI RSI

RSI:TITLE Title

RSI:DESCRIPTION Description

RSI:SUBJECT Subject

RSI:STATUS Status

RSI:STATUSDATE Status Date

RSI:DISCONTINUE Discontinue

RSI:DISCONTINUE
Discontinue Date
DATE

RSI:DISCONTINUE
Discontinue Comment
COMMENT
The URL required to access a specific
RSI:URL RSI.
E.g:...?func=RecMan.EditRSI&item=XX...

Page 90
 WebReports User Guide

This sub-tag stores the value of the data tag in a form field (after
SETFORM:<field name> formatting by any previous sub-tags). It is used in conjunction
or with the Export to Form feature. Export to Form must be set as
SETFORM:<field name>:NEXTROW the export destination in order for SETFORM to have any effect.
or (update mode only) The field name identifies a column in the destination form to
SETFORM:NEXTSEQ receive the data in the data tag. There needs to be a SETFORM
or (update mode only) sub-tag for each column of data that is to be set in the form.
SETFORM:NEXTKEY:<column name> Each SETFORM sub-tag inserts data into the same record in the
destination form until one of the following occurs, causing
Support: header, row, footer
subsequent SETFORM sub-tags to write to the next record in
destination form:

• A NEXTROW parameter is used with the SETFORM sub-

tag. This causes all subsequent SETFORMs to write to
the next record in the form.
• The reportview header section ends. This causes all
subsequent SETFORMs (in the row section) to write to
the next record in the form.
• A new reportview row is started. As the row-section is
repeated for each row of data in the data source, each
iteration of the row section also moves to the next record
in the destination form.
• The reportview row section ends. This causes a
subsequent SETFORMs (in the footer) to write to the next
record in the form.
• The footer section ends.

Example usage: [LL_REPTAG=ENDDATE

SETFORM:NEWDATE /]. In this case we are taking a column of
data called ENDDATE from the data source and storing it in a
field called NEWDATE which exists in the form we are exporting
to. This sub-tag supports all standard Livelink types so in the
above example it is possible for ENDDATE to be an integer,
string or date etc. A possible usage of this might involve using a
CSV file as a WebReport data source and reading this straight
into a form. In addition to this the source data could be in string
format but we might, as an example, use TODATE to put a string
into a Livelink date format before we use SETFORM to insert the
data as a Livelink date type. E.g. [LL_REPTAG=ENDDATE
TODATE:"%Y/%m/%d" SETFORM:NEWDATE /] will take a date
from the data source formatted as YYYY/MM/DD and convert it
to a Livelink date format that will be suitable for writing to the
form.

Update Mode Syntax

In update mode (set when form is selected as a destination) it is

necessary to specify into which form record each set of data
should be stored. The following rules govern how the target
record is specified:

• The target record in a form is determined with a sequence

number (referred to as SEQ in these guidelines).
• The SEQ to use for the current batch of SETFORM data
can be set by using SETFORM:SEQ in a data tag that
contains the required sequence number. E.g.

Page 91
 WebReports User Guide

[LL_REPTAG_"10" SETFORM:SEQ /] would result in the

current set of data (as determined by other SETFORM
sub-tags) being written to the form record with an SEQ of
10. SETFORM:SEQ does not itself write any data to the
form - it merely identifies a form record.
• At least the first form record being written to the
destination MUST have a sequence number specified.
• Any time a sequence number has been specified, all
subsequent sets of data (that do not have sequence
numbers specified) will write to the next consecutive
record in the destination form.
• If any value being used to specify a SEQ is invalid (e.g.
non-numeric) then the corresponding set of data will not
be written to the form destination table. Additionally, any
subsequent sets of data that do not specify their own
SEQ number will also not be written to the form.
• If the NEXTSEQ directive is used, then the value in the
data tag is used to set the SEQ number to be used by any
subsequent SETFORM sub-tags. This directive doesn't
actually write any data to the destination form it is simply
used to set the next SEQ to be used. E.g.
[LL_REPTAG_"5" SETFORM:NEXTSEQ /] would
determine that the next set of data will be written to the
form record with SEQ number 5. This method is most
commonly used to set a starting position in the header
section of a reportview prior to writing multiple rows of
data into the form.
• The NEXTKEY directive can be used to specify that the
first record of data to be updated should match a
particular key value (other than the SEQ column). If this
directive is used, an additional sub-tag parameter is
required to specify a field to be used for matching a key.
For example, imagine that a form has a field called "fruit"
and that the record with SEQ equal to 5 has a value of
"apple" stored in the "fruit" field. The tag:
[LL_REPTAG_"apple" SETFORM:NEXTKEY:fruit /]
would effectively select the record with SEQ equal to 5 as
the next record to be written to. In other words, the tag
has specified that we want to write to the first record we
find where the "fruit" field contains a value of "apple".
• In the event that there are fields in the target form without
a corresponding SETFORM sub-tag to map data into
them, these fields will be updated to contain ? and
existing data lost. To avoid this arrange to submit all fields
present in the form, whether or not they have changed.

Page 92
 WebReports User Guide

This sub-tag attaches documents to email destinations. The main

SETEMAILATTACH:<variablename> tag or sub-tag to the left must contain the dataid of a Livelink
document. This sub-tag is destination specific and will only
Support: header, row, footer
function in combination with the email destination. It should be
noted that each time this sub-tag is used a document is attached
to the destination email so it would be easy to overload this
delivery mechanism. It is recommended to use WebReports
variables to keep a running total of the file sizes and so stop
attaching documents when a given threshold is exceeded.

Example:

[LL_WEBREPORT_IF "[LL_REPTAG=DATAID
NODEINFO:SIZE:BYTES ADDVAR:TOT CURRENTVAL /]" <
"500000" /]
[LL_REPTAG=DATAID SETEMAILATTACH /]
[LL_WEBREPORT_ENDIF /]

Here the DATAID column is being returned from the data source.
NODEINFO:SIZE:BYTES takes the dataid and returns the size of
the latest version of the node in bytes. ADDVAR takes the size in
bytes for each row and adds the new value to the user defined
variable TOT. CURRENTVAL is then used to get the running total
of the calculation (i.e. contents of TOT variable). A WebReport IF
checks if the total size of all the nodes so far is less than 500,000
bytes (~0.5MB). If the total size is less than 0.5MB the document
will be attached to the email.

This sub-tag stores the value of the tag (after formatting by any
SETVAR:<variablename> previous sub-tags) in a variable which can be referenced using
the specified name. E.g.
Support: header, row, footer
[LL_REPTAG=DATAID SETVAR:ID /]
This example would store the current dataid in a variable called
"ID". This variable could be referenced elsewhere using a tag
such as: [LL_REPTAG_%id /]
When this sub-tag is used, the associated tag output will not be
displayed unless the SHOW sub-tag is also used.
See also ADDVAR, CONCATVAR and chapter 0.

SETWFATTACH

Support: header, row, footer

Page 93
 WebReports User Guide

SETWFATTACH Formatting

Action Description

SETWFATTACH:COPY Copies the Livelink node to the attachments folder of the

workflow being initiated.

SETWFATTACH:COPY:CURRENT When the node is copied only the latest version will be in
the new node. If this option is applied to a folder only the
latest version of all sub items will be copied.

SETWFATTACH:COPY:INHERITATT When the node is copied workflow categories and

RS:DESTINATION attributes are inherited from the workflow attachment
folder.

SETWFATTACH:COPY:INHERITATT When the node is copied workflow categories and

RS:MERGED attributes are retained from the source node and merged
with the categories and attributes of the workflow
attachment folder

SETWFATTACH:COPY:INHERITATT When the node is copied workflow categories and

RS:SOURCE attributes are retained from the source node.

SETWFATTACH:COPY:INHERITPE When the node is copied workflow permissions are

RMS inherited from the workflow attachment folder. If this option
is not used the permissions are retained from the original
node.

SETWFATTACH:COPY:NEWNAME: When the node is copied it will receive the specified name.
<name>

SETWFATTACH:COPY:UNIQUEON The node will only be copied to the attachments folder if

LY the existing name is unique. By default if a name clash
occurs the node being copied in will have an number
appended to the name and the copy will proceed. If this
option is specified the copy fails if the name is already
present.

SETWFATTACH:MOVE Moves a Livelink node to the attachment folder of a

workflow being initiated.

SETWFATTACH:MOVE:INHERITAT When the node is moved workflow categories and

TRS:DESTINATION attributes are inherited from the workflow attachment folder

SETWFATTACH:MOVE:INHERITAT When the node is moved workflow categories and

TRS:MERGED attributes are retained from the source node and merged
with the categories and attributes of the workflow
attachment folder

SETWFATTACH:MOVE:INHERITAT When the node is moved workflow categories and

TRS:SOURCE attributes are retained from the source node.

SETWFATTACH:MOVE:INHERITPE When the node is moved workflow permissions are

RMS inherited from the workflow attachment folder. If this option
is not used the permissions are retained from the original
node.

SETWFATTACH:MOVE:NEWNAME: When the node is moved it will receive the specified name.
<name>

SETWFATTACH:MOVE:UNIQUEON The node will only be moved to the attachments folder if

LY the existing name is unique. By default if a namePage
clash94
occurs the node being moved in will have an number
appended to the name and the move will proceed. If this
 WebReports User Guide

This sub-tag stores the value of the tag (after formatting by any
SETWFATTR:<fieldname> previous sub-tags) in a Workflow attribute. The sub-tag is used in
conjunction with the export to Workflow feature which must be
Support: header, row, footer
set as the export destination in order for this sub-tag to function.
Example usage, [LL_REPTAG_&POSTCODE
SETWFATTR:ADDRESS3 /]. In this case we are taking a
parameter called POSTCODE and storing it in a Workflow
attribute called ADDRESS3 which exists in the Workflow we are
initiating.
If the Attribute being populated is a multi-value, the optional MV
operator can be used. Example, [LL_REPTAG_&ORIGIN
SETWFATTR:MV:COUNTRY /]. In this case, the value of the
parameter ORIGIN is inserted in the first element of the multi-
value workflow attribute called COUNTRY. If we wanted to
populate subsequent elements in the same multi-value Attribute
we could use the ++ operator, Example [LL_REPTAG_&ORIGIN
SETWFATTR:MV++:COUNTRY /] would populate the second
element.

This sub-tag stores the value of the tag (after formatting by any
SETWFFORM:<formname>:<fieldname previous sub-tags) in a Livelink WebForm that is attached to a
> Workflow. The sub-tag is used in conjunction with the export to
Workflow feature which must be set as the export destination in
Support: header, row, footer
order for this sub-tag to function.
Behavior is slightly more complex than SETWFATTR as the
WebReport can write to any number of forms that are associated
with a Workflow. In addition to this, there is support for setting
form values that are within sets. To set a value in a form, the tag
might look as follows: [LL_REPTAG=ENTRYPOINT
SETWFFORM:ACCESSDATA:BRAVO /]. In this case the
column ENTRYPOINT is being inserted into a form called
ACCESSDATA at the field BRAVO.

Page 95
 WebReports User Guide

Format Description

SETWFFORM:<formname>:<fieldname> Populates a standard form field of any type.

SETWFFORM:<formname>:SET:<setname>: Populates a standard form field of any type

<fieldname> within a set.

SETWFFORM:<formname>:MV:<fieldname> Populates the first field within a multi value

SETWFFORM:<formname>:MV++:<fieldnam field if MV is used on its own. If the optional
e> ++ operator is specified, the next field within
the multi value will be populated, and so on.

SETWFFORM:<formname>:SET:<setname>: Populates the first field within a multi value

MV:<fieldname> field, within a set, if MV is used on its own. If
SETWFFORM:<formname>:SET:<setname>: the optional ++ operator is specified, the
MV++:<fieldname> next field within the multi value will be
populated, and so on.

SETWFFORM:<formname>:MVSET:<setnam MVSET is used to populate fields within

e>:<fieldname> multi value sets. The name of the set and
the name of the field must be specified after
the operator.

SETWFFORM:<formname>:MVSET:<setnam Multi value fields within a multi value set can

e>:MV:<fieldname> be accessed by using the MV operator in
SETWFFORM:<formname>:MVSET:<setnam conjunction with MVSET. By using the
e>:MV++:<fieldname> optional ++ operator after the MV it is
possible to access the next field within the
multi value field within the same set. This
differs from MVSET++, which increments the
multi value set, rather than the multi value
field within the multi value set

SETWFFORM:<formname>:MVSET++:<setn ++ is an optional operator for MVSET which

ame>:<fieldname> allows the user to specify the next set within
a multi value set.

Display sub-tags that do not display by default e.g. ADDVAR,

SHOW SETVAR and CONCATVAR. This sub-tag can be used with any
tag and sub-tag combination but will have no effect unless used
Support: header, row, footer
with a sub-tag which doesn't normally display any output.

Page 96
 WebReports User Guide

For any string of characters, returns a slice of the original string

SLICE:<start index> based on a specified start index and an optional end index. This
or sub-tag is similar to the SUBSTR sub-tag but allows an end index
SLICE:<start index>:<end index> to be used instead of a width. All indices count starting at 1 (one)
so the slice will include all characters starting from and including
Support: header, row, footer the <start index> and concluding with and including the <end
index> (if one is specified). If end index is omitted or exceeds the
total length of the string, then the remainder of the string is used.

SLICE Examples:

These different examples of the SLICE sub-tag show the different

results which would be produced, assuming the associated tag
contained the string:

The quick brown fox

SLICE:5 would return: "quick brown fox"

SLICE:5:9 would return: "quick"

SLICE:5:100 would return: "quick brown fox"

Replaces numeric status values returned from the Livelink

STATUS:<parm> database with the word value equivalent. For example
STATUS:TASK would replace the values -2,-1,0,1,2,3 with
Support: header, row, footer
Pending, In Progress, Issues, etc. The parameters WORK,
WORKAUDIT, SUBWORK and SUBWORKTASK perform the
same action for the values returned from these tables.

Status Type Description

Decodes the status values from the main workflow

WORK
table WWORK

Decodes the status values for the sub workflow table

SUBWORK
WSUBWORK

Decodes the status values for the workflow task

SUBWORKTASK
information stored in WSUBWORKTASK

Decodes the status values for the workflow audit table

WORKAUDIT
WWORKAUDIT

Decodes the values returned from the status column

TASK
of the DTREE table for Livelink tasks

Accepts a string of characters in <parm>. All occurrences of

STRIP:<parm> each individual character are removed from the data item. This
function is case sensitive. For example “STRIP:Lke” acting on a
Support: header, row, footer
data item with the value “Livelink System” results in “ivlin Systm”
being inserted into the WebReport output.

Page 97
 WebReports User Guide

For any string of characters, returns a substring of the original

SUBSTR:<start index> string based on a specified start index and an optional width. This
or sub-tag is similar to the SLICE sub-tag but allows a width to be
SUBSTR:<start index>:<width> used instead of an end index. All indices count starting at 1 (one)
so the slice will include all characters starting from and including
Support: header, row, footer the <start index> and including the number of characters
specified by <width> (if one is specified). If width is omitted or
exceeds the total length of the remaining string then the
remainder of the string is used.

SUBSTR Examples:

These different examples of the SUBSTR sub-tag show the

different results which would be produced, assuming the
associated tag contained the string:

The quick brown fox

SUBSTR:5 would return: "quick brown fox"

SUBSTR:5:5 would return: "quick"

SUBSTR:5:100 would return: "quick brown fox"

Returns an oscript representation of the Livelink Tabs associated

TABS to an object. These are the same tabs you see when you go to
the Function Menu > Properties section of any object. This sub-
Support: header, row, footer
tag expects a valid dataid in the main tag. The tabs will be
returned in their proper order as seen in the Livelink interface.
See the TOJSON sub-tag for how to convert this into a data
structure that can be interpreted by JavaScript in the client. The
JSON structure can then be parsed and the appropriate HTML
can be implemented to display the tabs.

Example output of the TABS sub-tag:

{A<1,?,'Name'=X,'URL'='/Livelink971/livelink.exe?func=ll&objId=1
389412&objAction=properties&nexturl=%2FLivelink971%2Fliveli
nk%2Eexe%3Ffunc%3Dll%26objid%3D1388531%26objAction%
3Dbrowse%26sort%3Dname'>,A<1,?,'Name'=X,'URL'='/Livelink9
71/livelink.exe?func=ll&objId=1389412&objAction=info&nexturl=
%2FLivelink971%2Flivelink%2Eexe%3Ffunc%3Dll%26objid%3D
1388531%26objAction%3Dbrowse%26sort%3Dname'>...

This displays the oscript representation of the General and

Specific tabs of a document.

Page 98
 WebReports User Guide

This subtag expects a date in the main tag and returns the time
TIMESINCE:<ref date> delta (<ref date> - <main tag date>). If no <ref date> is specified
then the current date is used by default. Negative values will be
Support: header, row, footer
produced if the <ref date> is before the <main tag date>. Dates
must be specified in the following format:

'Mon dd YYYY' (Eg. 'Jan 12 2010')

'D/YYYY/mm/dd' (Eg. 'D/2009/12/14')
'DayOfWeek Mon dd hh:mm:ss YYYY' (Eg. 'Fri Jan 01
01:04:24 2010')

Examples:

[LL_REPTAG=DUEDATE TIMESINCE /]
[LL_REPTAG=MODIFYDATE TIMESINCE:'Jan 12 2010' /]
[LL_REPTAG_'Feb 2 2009' TIMESINCE:'D/2009/12/14' /]
[LL_REPTAG_'D/2009/12/20' TIMESINCE:'Fri Jan 01 00:00:00
2010' /]

The first example will return the difference between the current
date and the date in the column DUEDATE. The second example
returns the difference between 'Jan 12 2010' and the date in the
column MODIFYDATE. The third and fourth examples
demonstrate different acceptable ways to specify the date format.

This sub-tag converts string formatted date information into a

TODATE:<format list> Livelink format date. This means the output can be used in
logical expressions such as to compare a custom date with a
Support: header, row, footer
date parameter or possibly the current date. The output of
TODATE can also be piped into the DATE sub-tag for further
manipulation prior to display.

Format Description

%% A percentage sign

The three-character abbreviated month name

%b
(e.g., Jan, Feb, etc.)

The two-digit day of the month, from 01 to 31

%d
(e.g., 01-31)

%m The two-digit month (e.g., 01-12)

%p AM or PM

%y The two-digit year (e.g., 93)

%B The full month name (e.g., January)

The two-digit hour on a 24-hour clock, from 00

%H
to 23

%I The two-digit hour, from 01 to 12

Page 99
 WebReports User Guide

%M The minutes past the hour, from 00 to 59

%P AD or BC

%S The seconds past the minute, from 00 to 59

%Y The year, including the century (e.g., 1993)

Example of using TODATE with DATE to get from a custom date

format to the Livelink short date format (Defined in the Livelink
Admin pages):

Imagine you are starting with a custom date stored in the format:
2006-02-15T00:00:00
Use [LL_REPTAG=MY_DATE_COLUMN TODATE:"%Y-%m-
%dT%H:%M:%S" /] to put the date into a string representation of
a Livelink date.
At this point the date will look like Wed Feb 15 00:00:00 2006
which may or may not be useful.

Now use the DATE sub-tag [LL_REPTAG=MY_DATE_COLUMN

TODATE:"%Y-%m-%dT%H:%M:%S" DATE:SHORT /] to change
the output so that the date is in the same format as, for example,
the modified date in a Livelink folder browse. At this point the
date might look like February 15, 2006 though this will depend
on your system settings in the Admin pages

For output formatting see DATE sub-tag. For the current date see
DATE and DATETIME tags.

For a string which has a known delimiter (such as a comma), the

TOLIST:<delimiter> string can be converted into a list. This list is similar to a
programming array and is in the form: {1,2,3} or
Support: header, row, footer
{'one','two','three'}. A list in this format can be used by the LIST
and RANGE sub-tags; however, the TOLIST sub-tag also
supports an optional index value that specifies which element in
the newly created list to return.

For example, if the first column of a data table returns the string:
'apple','orange','pear';

[LL_REPTAG_1 TOLIST:, /] would return the list:

{'apple','orange','pear'}

If the optional index parameter is also used, the syntax:

[LL_REPTAG_1 TOLIST:,:2 /] would return the single element:

orange. See also: LIST and RANGE

For a tag that returns an OSCRIPT type data structure, this tag
TOJSON converts the structure into a JSON (JavaScript Object Notation)
structure that can be processed by a JavaScript interpreter. This
Support: header, row, footer
sub-tag converts OSCRIPT structures as follows:

Page 100
 WebReports User Guide

Oscript Structures and TOJSON

OSCRIPT OSCRIPT Example JSON JSON Example

Structure Structure

LIST {'one','two'} Array ["one","two"]

ASSOC A<1,?,'one'=1,'two'=2> Object {"one":1, "two":2}

RECORD R<'one'=1,'two'=2> Object {"one":1, "two":2}

RECARRAY V{<'fruit','color'><'apple','green'><'banana', Array of [{"fruit":"apple", "color":"green"}, {"fruit":"banana",

'yellow'>} Objects "color":"yellow"}]

Removes all leading and trailing white space from the specified
TRIM string. White space is defined as any combination of spaces,
form feeds, new lines, carriage returns, and horizontal or vertical
Support: header, row, footer
tabs.

Truncates the field to the number of characters specified in the

TRUNC:<width> width (starting from the first character).
Support: header, row, footer
Applies a time zone offset to dates. Date tags such as
TZOFFSET [LL_REPTAG_DATETIME /] and date columns
[LL_REPTAG=CREATEDATE /] return the time at the server.
Support: header, row, footer
TZOFFSET can be used to apply the appropriate time zone
offset for the specific user viewing the output.

Converts escaped characters to their equivalents E.g. a \r would

UNESCAPESTR be converted to an actual carriage return character.
For example:
Support: header, row, footer
[LL_REPTAG=NAME UNESCAPESTR /]"

Sets all text in the field to upper case.

UPPER

Support: header, row, footer

Page 101
 WebReports User Guide

For any valid URL this sub-tag converts the "GET" form URL into
URLTOPOST a POST request by creating a series of appropriately named
FORM fields with corresponding values. If the URL contains a
Support: header, row, footer
prefix (prior to any parameters) the prefix is abandoned and only
the parameters are converted into form fields. For example, the
following URL:
/Livelink971/livelink.exe?func=ll&objId=157220&objAction=Ru
nReport&reqcacheid=1005851343
Converts into the following lines of HTML:
<INPUT TYPE="HIDDEN" NAME="func" VALUE="ll">
<INPUT TYPE="HIDDEN" NAME="objId" VALUE="157220">
<INPUT TYPE="HIDDEN" NAME="objAction"
VALUE="RunReport">
<INPUT TYPE="HIDDEN" NAME="reqcacheid"
VALUE="1005851343">

This sub-tag provides the ability to manipulate users and groups

USERACTION:<operation> in large volumes at the server. Users running a report containing
this sub-tag are only able to perform operations with the same
Support: header, row, footer
level of permissions/privileges as through the regular user
interface.

See also: NODEACTION and WFACTION

USERACTION Formatting

Action Description

Adds a user or group to the group returned from the main

tag. E.g. [LL_REPTAG=GROUPID
ADD:<userid>
USERACTION:ADD:38832 /] adds the user with id 38832
to the group returned in the GROUPID column

Creates a new group with the name returned from the main tag.
Supports an optional parameter to set the group leader. E.g.
[LL_REPTAG=newname
CREATEGROUP:<groupname>
USERACTION:CREATEGROUP:LEADERID:4526 /] creates a
new group called whatever is in the newname column and sets
the leader of that group to be the user 4526.

DELETE Simply deletes the user or group returned by the main tag

Removes a user or group from the group returned in the

REMOVE:<userid>
main tag

RENAME:<name> Renames the user or group

For a valid Livelink user ID or Livelink user name this sub-tag will
USERINFO:<format> return user information according to the format parameter that
has been provided.
Support: header, row, footer

Page 102
 WebReports User Guide

USERINFO Formatting

Format Description

CONTACT The contact information for the user.

FIRSTNAME The user's first name.

The full name of the user using the format which has been
FULLNAME globally defined for the Livelink system (e.g. Joseph R.
Smith)

GROUPID The ID of the user's base group.

GROUPNAME The name of this user's base group.

LASTNAME The user's last name.

If the child is a group, the user ID of the user who is the

LEADERID
leader of the group is returned.

MAILADDRESS The user's email address.

MIDDLENAME The user's middle name.

NAME The login ID of a user or the name of a group

The objectid of the Personal Workspace of the user. This

can be used to provide a link to a user’s Personal
Workspace by using it with the NODEINFO sub-tag. For
PWS
example, [LL_REPTAG_USERID USERINFO:PWS
NODEINFO:BROWSE /] would provide a URL to access the
Personal Workspace of the user executing the WebReport.

TITLE The user’s title.

Returns true if the current user (running the WebReport) is a

USERINGROUP member of the group returned by the main tag. If the main tag is
not associated with a valid group ID then false is returned. E.g.
Support: header, row, footer
[LL_WEBREPORT_IF "[LL_REPTAG=id USERINGROUP /]" ==
"TRUE" /]
I AM IN GROUP: [LL_REPTAG=NAME /]
[LL_WEBREPORT_ENDIF /]

Page 103
 WebReports User Guide

USERPREF:<tab>:<setting>
For a valid Livelink user ID this sub-tag will return the users settings
Support: header, row, footer found in Tools > Settings. For example, [LL_REPTAG=USERID
USERPREF:GENERAL:STARTPAGE /] will return the user's Start Page
setting (Enterprise Workspace, My Workspace, About Livelink, or My
Home). Some subtags return an Oscript Assoc and can be further
manipulated using the TOJSON subtag.

Format Description

GENERAL Returns an Oscript Assoc containing the values of the General Tab.

GENERAL:DFTSTARTPAGE The user's Default Start Page.

Returns TRUE or FALSE based on the "Show Item Descriptions on Detail

GENERAL:SHOWITEMDESC
View".

Returns the users Navigation Style. This will return on of three values; a
GENERAL:NAVSTYLE
blank string (for no preference selected), 'trail', or 'dropdown'.

GENERAL:NEWDUR Returns the number of days set for the "New" Indicator Duration.

GENERAL:MODDUR The number of days for the "Modified" Indicator Duration.

Returns TRUE or FALSE based on the "Enhanced Keyboard Accessibility

GENERAL:ENHANCEDKYBD
Mode" setting.

COLORS Returns an Oscript Assoc containing all the settings on the Color tab.

COLORS:ROW1 The hexidecimal value of Row1.

COLORS:ROW2 The hexidecimal value of Row2.

DISCUSSION Returns an Oscrip Assoc containing all the settings on the Discussion tab.

DISCUSSION:DFTPERIODFROM The "Default Period From" setting on the Discussion tab.

DISCUSSION:DFTVIEW The "Default View" setting on the Discussion tab.

DISCUSSION:FILTERPREF The "Filter Preference" setting on the Discussion tab

The "Posting Preference" setting on the Discussion tab. Returns TRUE or

DISCUSSION:POSTINGPREF
FLASE.

The "Reply Preference" setting on the Discussion tab. Returns TRUE or

DISCUSSION:REPLYPREF
FALSE.

The "View Item Options" setting on the Discussion tab. Returns TRUE or
DISCUSSION:VIEWITEMOPTIONS
FALSE.

Page 104
 WebReports User Guide

USERPREF Continued<

Format Description

WORKFLOW Returns an Oscript Assoc containing all the settings on the Workflow tab.

WORKFLOW:WFSTARTPAGE The Workflow Assignments > Starting Page setting on the Workflow tab.

WORKFLOW:PROXY The Workflow Assignments > Proxy setting on the Workflow tab.

Returns an Oscript Assoc containing all the Workflow Assignments >

WORKFLOW:ASSIGNMENTSSHOW
Show settings, including any expression data.

Returns TRUE or FALSE based on the "Automatically open the next

WORKFLOW:AUTOOPEN assignment in the same workflow if assigned to me" checkbox on the
Workflow tab.

Returns TRUE or FALSE based on the "Include workflow assignments on

WORKFLOW:INCLUDEWFASSGN
'My Assignments' page" on the Workflow tab.

Returns an Oscript Assoc containing all the settings found under

WORKFLOW:STATUSSHOW Workflow Statuses > Show on the Workflow settings tab, including any
expression data.

WORKFLOW:SORTORDER The Workflow Statuses > Sort Order setting on the Workflow tab.

WORKFLOW:DFTWFTAB The "Default 'My Workflows' Tab" setting on the Workflow tab.

WORKFLOW:MAXITEMS The "Maximum Items Per Page" setting on the Workflow tab.

This sub-tag will return information about the latest version of a

VERINFO:<format> nodeid. If supplied with an optional version number information
about that specific version will be retrieved. E.g.
Support: header, row, footer
[LL_REPTAG=DATAID VERINFO:MIMTYPE:5 /] will return the
mimetype of the 5th version of an object whereas
[LL_REPTAG=DATAID VERINFO:MIMTYPE /] will return it for the
latest version.

Page 105
 WebReports User Guide

VERINFO Formatting

Format Description

COMMENT Comments assigned to the version, not to be

confused with comments assigned to the node.

CREATEDATE The creation date of the version.

EFSPATH The location of the version file in the EFS. This
option will only return a value if the Admin user is
running the report.

FILECREATEDATE The create date of the version file.

FILECREATOR The creator of the version.

FILEDATASIZE The size.

FILENAME The name of the version file.

FILETYPE The file type.

MIMETYPE The mimetype of the version.

MODIFYDATE When the version was last modified.

NODEID ID of the version.

NUMBER The version number.

OWNER Owner of the version.

PROVIDERNAME Storage provider.

PROVIDERID The id of the storage provider.

RENDITION:<type>:< The location of the version file in the EFS. This

property> option will only return a value if the Admin user is
running the report.

RENDITIONCOUNT Returns the number of renditions available in the

latest version of the node.

RENDITIONDEFAULT Returns the default rendition type for the node

based on the priority defined in the renditions
administration pages.

TYPE The type of the version.

Page 106
 WebReports User Guide

This sub-tag offers powerful capabilities to manipulate workflows in

WFACTION:<operation> large volumes at the server. Users are only able to manipulate
workflows with the same level of permissions as through the
Support: header, row, footer
regular user interface.

Example: [LL_REPTAG=WORKID WFACTION:SUSPEND /]

changes the status of an Executing workflow, identified by the
WORKID column returned from the data source, to Suspended.

See also: NODEACTION and USERACTION

WFACTION Formatting

Action Description

ARCHIVE Changes the status of a Stopped or Completed workflow to Archived

DELETE Deletes a Stopped or Completed workflow

RESUME Changes the status of a Suspended workflow to Executing

STOP Changes the status of an Executing or Suspended workflow to Stopped

SUSPEND Changes the status of an Executing workflow to Suspended

For a valid Livelink Workflow (WORKID) this sub-tag will return

WFATTR:<format> attribute information for that workflow.
Support: header, row, footer

Page 107
 WebReports User Guide

WFATTR Formatting

Format Description

WFATTR When no optional parameters are

defined, this sub-tag will return TRUE or
FALSE depending on the presence of
the parameters package in the workflow.

WFATTR:<attname> Will return TRUE or FALSE if the named

workflow attribute has a non-blank
value.

WFATTR:<attname>:DISPLAY Will display the value in the named

workflow attribute. If the attribute is a
multi-value, all values will be shown in a
comma-separated format.

WFATTR:<attname>:ID Will display the ID of the named

attribute.

WFATTR:<attname>:COUNT Will return the number of populated

entries in a multi-value workflow
attribute.

WFATTR:<attname>:<attval> Will return TRUE or FALSE if the

specified value in the workflow is found
in the workflow attribute.

WFATTR:<attname>:<n> Will return TRUE/FALSE if there is a

value in the nth element of a multi-value
workflow attribute.

WFATTR:<attname>:<n>:DISPLAY Will display the nth value in the named

multi-value workflow attribute.

WFATTR:<attname>:<n>:<attval> Returns TRUE/FALSE if the value attval

is found at the index n within a multi-
value workflow attribute.

WFATTR:<attname>:INDEX:<attval> Will return the index of the specified

value within a multi-value workflow
attribute.

Page 108
 WebReports User Guide

This sub-tag is used to lookup data from any database table

WFDBLOOKUP:<table ref>:<column created by the Livelink WebForms module. It expects a valid key to
ref> be supplied by the data tag and accepts parameters to specify the
appropriate table and column to reference. The key, table and
WFDBLOOKUP:<table ref>:<column column information are then used to lookup one or more rows from
ref>:<column select> the specified WebForms table. An additional parameter can also be
included to specify a particular column of data to be returned. If
WFDBLOOKUP:<table ref>:<column
more than one column is returned, the data is provided in an
ref>:<column select>:MULTIMATCH
OSCRIPT RECARRAY structure (proprietary Livelink data
structure). This RECARRAY structure can be dereferenced using
Support: header, row, footer
the RECARRAY sub-tag or converted into JSON format using a
TOJSON sub-tag. If only one match is found, the RECARRAY will
only have one record but if more than one row of data is returned,
the data is provided in multiple records within the RECARRAY
structure.
The <table ref> parameter can be either: a form template ID or a
form ID. Either of these objects are used to determine the correct
SQL table name. Note that the user running the WebReport must
have the appropriate level of permissions to be able to "See
Contents" on the form/template objects. The <column ref> is an
identifier that specifies the name of a column where the key will be
searched for. The optional <column select> parameter is used to
narrow the data returned from the query down to a single, specific
column.
Normally if only one column is being returned, this sub-tag only
returns the most recently added item in a single field of text, i.e. not
in a RECARRAY; however, the MULTIMATCH option allows more
than one row of data to be returned, even though only one column
has been selected. If no column has been selected, the data is
always returned in a Recarray structure. This structure can be
dereferenced using the RECARRAY sub-tag and or the TOJSON
sub-tag can be used to convert the structure into JSON format (the
client can use this to create JavaScript variables).
The various methods of returning data are described in the
following bullets. Generally speaking a RECARRAY is always
returned unless a column select has been specified without a
MULTIMATCH option (which results in a single text field).
• If the column select option has not been specified, all
columns for the data source are returned for as many rows
as are matched by the query
• If the column select option has been specified, only the
data for the specified column in the first matched row is
returned
• If the column select option has been specified as well as
the option called MULTIMATCH, then only the specified
column is returned for any matched rows. This option
allows for more than one row of data but the data is always
returned in a RECARRAY, even if only one row is found

Page 109
 WebReports User Guide

Return information about the workflow form fields associated with a

WFFORM:<parms> specific workflow (subworkid). This sub-tag supports both sets and
multi-value fields through use of the MV and SET operators.
Support: header, row, footer

For Example: [LL_REPTAG=WORK_WORKID

WFFORM:<formname>:<fieldname>:DISPLAY /] will return the
field value stored in the form <formname> and the field
<fieldname> for any field type. If <fieldname> is a multi-value field
or a set, a comma-separated list of values will be returned.

WFFORM Formatting

Format Description

WFFORM:<formname>:<fieldname>:DI Will return the value in the field, <fieldname>, for

SPLAY the form, <formname>. If <fieldname> is a set or a
multi-value field, a comma separated list of values
will be returned.

WFFORM:<formname>:<fieldname>:ID Will return the ID of the field, <fieldname>, for the

form, <formname> if it is present. If <fieldname>
exists inside a set, it will be returned in the case
that no field matching <fieldname> exists at the top
level in the form. In the case that <fieldname>
exists at the top level of the form and within a set of
the same form, the field ID at the top level (not
within the set) will take precedence.

WFFORM:<formname>:<fieldname>:<fi Will return TRUE/FALSE depending on whether a

eldval> field, <fieldname>, exists with a value equal to
<fieldval> in the form, <formname>. <fieldname>
may be a field within a set (including a multi-value),
or any element within a multi-value field.

WFFORM:<formname>:MV:<fieldname Will return a number of multi-value fields in use.

>:COUNT

WFFORM:<formname>:MV:<fieldname Will return TRUE/FALSE for the presence of a

>:<n> specific non-blank element in a multi-value field,
<fieldname>, for the form, <formname> at the index
location <n>. The value of <n> must be a positive
integer between 1 and n where n does not exceed
the length of the multi-value field. If n exceeds the
length of the multi-value field, an empty string will
be returned.

Page 110
 WebReports User Guide

WFFORM:<formname>:MV:<fieldname Will return TRUE/FALSE for the presence of

>:<n>:<fieldval> <fieldval> in a multi-value field, <fieldname>, for
the form, <formname> at the index location <n>.
The value of <n> must be a positive integer
between 1 and n where n does not exceed the
length of the multi-value field.

WFFORM:<formname>:MV:<fieldname Will return the value in the multi-value field,

>:<n>:DISPLAY <fieldname>, for the form, <formname> at the index
location <n> where <n> is a positive integer
between 1 and n. The value of <n> must be a
positive integer between 1 and n where n does not
exceed the length of the multi-value field.

WFFORM:<formname>:MV:<fieldname Will return the first index of the multi-value field,

>:INDEX:<fieldval> <fieldname>, for the form, <formname> where
<fieldval> is equal to the value contained in the
multi-value field at index. For example, if <fieldval>
exists in the third element of <fieldname>, the
number 3 will be returned

WFFORM:<formname>:SET:<setname> Uses the SET operator allowing field sets to be

:<fieldname> explicitly referenced. This example will return
TRUE if field, <fieldname> within set, <setname> is
non-blank. Only fields within <setname> can be
referenced so if <fieldname> exists outside the set,
it will not be found. If <fieldname> is a multi-value
field, TRUE will be returned if any field within it is
non-blank.

WFFORM:<formname>:SET:<setname> Will return the value in the field, <fieldname>, for

:<fieldname>:DISPLAY the form, <formname>, if <fieldname> is a field
within <setname>. If <fieldname> is a multi-value
field, a comma separated list of the defined values
will be returned. If no defined value exists, either in
a multi-value field, or a standard field, an empty list
will be returned.

WFFORM:<formname>:SET:<setname> Will return the ID of the field <fieldname> within the

:<fieldname>:ID set <setname>. If <fieldname> exists outside
<setname> it will not be returned. <fieldname> can
be either a regular or multi-value field.

WFFORM:<formname>:SET:<setname> Will return TRUE/FALSE depending on whether a

:<fieldname>:<fieldval> field, <fieldname>, exists with a value equal to
<fieldval> in the set, <setname>. If <fieldname> is
a multi-value field, all elements will be checked for
equality against <fieldval>, if any match, TRUE will
be returned.

WFFORM:<formname>:SET:<setname> Will return number of multi-value fields that have

:MV:<fieldname>:COUNT been populated.

WFFORM:<formname>:SET:<setname> Will return TRUE/FALSE for the presence of a

:MV:<fieldname>:<n> specific non-blank element in a multi-value field,

Page 111
 WebReports User Guide

<fieldname>, within a set, for the form, <formname>

at the index location <n>. The value of <n> must be
a positive integer between 1 and n where n does
not exceed the length of the multi-value field.

WFFORM:<formname>:SET:<setname> Will return TRUE/FALSE for the presence of

:MV:<fieldname>:<n>:<fieldval> <fieldval> in a multi-value field, <fieldname>, within
a set, for the form, <formname> at the index
location <n>. The value of <n> must be a positive
integer between 1 and n where n does not exceed
the length of the multi-value field.

WFFORM:<formname>:SET:<setname> Will return the value in the multi-value field,

:MV:<fieldname>:<n>:DISPLAY <fieldname>, within a set, for the form, <formname>
at the index location <n> where <n> is a positive
integer between 1 and n. The value of <n> must be
a positive integer between 1 and n where n does
not exceed the length of the multi-value field.

WFFORM:<formname>:SET:<setname> Will return the first index of the multi-value field,

:MV:<fieldname>:INDEX:<fieldval> <fieldname>, within a set, for the form, <formname>
where <fieldval> is equal to the value contained in
the multi-value field at index

WFFORM:<formname>:MVSET:<setna Will return TRUE or FALSE where the multi-value

me>:<n>:<fieldname> set, <setname>, has a non-blank field, <fieldname>,
at the index location <n>, within the form,
<formname>.

WFFORM:<formname>:MVSET:<setna Will display the value of a field <fieldname> within a

me>:<n>:<fieldname>:DISPLAY multi-value set, <setname> at the index location
<n>, within the form, <formname>.

WFFORM:<formname>:MVSET:<setna Will display the ID of a field <fieldname> within a

me>:<n>:<fieldname>:ID multi-value set, <setname> at the index location
<n>, within the form, <formname>.

WFFORM:<formname>:MVSET:<setna Will return TRUE or FALSE where the multi-value

me>:<n>:<fieldname>:<fieldval> set, <setname>, has a field, <fieldname>, at the
index location <n>, within the form, <formname>
that is equal to the value specified in <fieldval>.

WFFORM:<formname>:MVSET:<setna Returns the number of multi-value fields in use in

me>:<n>:MV:<fieldname>:COUNT the multi-value set.

WFFORM:<formname>:MVSET:<setna Will return TRUE or FALSE where the multi-value

me>:<n>:MV:<fieldname>:<m> set, <setname>, at index location <n> has a multi-
value field, <fieldname>, at the index location <m>,
that is non-blank.

WFFORM:<formname>:MVSET:<setna Will display the value of a multi-value field

me>:<n>:MV:<fieldname>:<m>:DISPLA <fieldname>, at the index location <m>, within a
Y multi-value set, <setname> at the index location
<n>, within the form, <formname>.

WFFORM:<formname>:MVSET:<setna Will return TRUE or FALSE where the multi-value

me>:<n>:MV:<fieldname>:<m>:<fieldva set, <setname>, at the index location <n>, has a
l> multi-value-field, <fieldname>, at the index location
<m> whose value is equal to the value specified in
<fieldval>.

Page 112
 WebReports User Guide

WFFORM:<formname>:MVSET:<setna Will return the first index of the multi-value field,

me>:<n>:MV:<fieldname>:INDEX:<field <fieldname>, within a multi-value set, for the form,
val> <formname> where <fieldval> is equal to the value
contained in the multi-value field at index.

For a valid Livelink Workflow this sub-tag will return valid

WFINFO:<format> information associated with that executing workflow.

WFINFO Formatting

Format Description

ATTACHFOLDER Returns the objectid of the attachments folder

associated with the executing workflow.

FLAGS Flags.

DATEDUE_MIN Minimum due date.

DATEDUE_MAX Latest due date.

DATEINITIATED The date the workflow was started.

DATECOMPLETED The date the workflow was completed.

OWNERID The userid of the owner of the workflow.

MANAGERID The userid of the manager of the workflow.

STATUS The current status of the workflow. See also STATUS

sub-tag above (with WORK option).

PROJECT Project.

USERDATA Userdata.

CUSTOMDATA Customdata.

OWNERPERMS Ownerperms.

Page 113
 WebReports User Guide

7 Exporting Report Data

7.1 Overview
Besides being displayed in the browser, the resulting output from running a WebReport can
be exported to any of the following locations: Livelink (New document, Version, Workflow,
WebForm), Desktop, E-Mail or if you’re the Admin user, to the Livelink Server itself. The
export behavior is accessible, explicitly from the functions menu, by choosing Export or by
setting export to be the default report behavior through Properties → Destination on the
functions menu. When exporting to either Livelink or e-mail it is possible to separate the web
browser from the report so the user can carry on working whilst large reports are executed in
the background. This behavior is accessed via the Run in Background check box.

7.2 Exporting to Desktop

Select Desktop as the export destination and select the Export Mime Type for the resulting
export file. The Mime type will be used by WebReports to determine the file extension and
therefore the file type to be downloaded. This is ultimately used to determine the application
which will open the exported file. On clicking export, the user is presented with a download
dialogue. At this point, it is possible to change the default filename which will be set to the
name of the corresponding WebReport.

Export to Desktop Screen

Select Desktop as destination

Export file name

Export format

7.3 Exporting to Livelink – New Document

It is possible to export the report output to a new Livelink document. This can either be done
from the WebReport Export option by selecting Export to Livelink or by setting the default
Output Destination as Livelink and then running the WebReport. In either case, the Export
Type option is set to Livelink Node. As with the desktop export, it is possible to specify the
mime type of the resultant document. In addition to this, the user needs to select a destination
container by clicking the Browse Livelink button. The default name will be the WebReport
name followed by “Snap Shot” and the default location will be the folder containing the
WebReport. If a name that is not unique is provided for the destination, a unique postfix will
be appended e.g. New WebReport Snap Shot 5. The export feature also provides the
flexibility for the user to add a description to the new document as well as specify category
details.
 WebReports User Guide

Export to Livelink Node Screen

Select Livelink Node as destination

A unique file name

Where the document is created

Specify categories

Return Browser

7.4 Exporting to Livelink – New Document Version

Exporting report data to a new document version is similar to adding a new Livelink Node with two
main exceptions:

• Users are required to select an existing document or customview rather than a container.
• You have the option to insert the exported report into the document you are adding a
version to. This can be at the start or end, or, if using tags, anywhere in the body of the
document.

On clicking export a new version is added to the selected document, with the new mime type,
description and categories as specified on the export page.
 WebReports User Guide

Export to Livelink Version Screen

Select Version as destination

The document we want to

add the version to

Specify categories

7.5 Exporting to E-Mail

The WebReports export feature allows users to export report data to e-mail. The ‘Export to E-
Mail’ screen allows the user to specify e-mail addresses in three different ways:
3
• Typing in comma (,) separated e-mail addresses manually

• Selecting either a Livelink User or Group

• Selecting a CSV file of addresses from within Livelink

Notes for e-mail recipients:

• It is possible to use these three methods in any combination.

• If selecting a Livelink User or Group, no e-mail will be sent if an e-mail address is

not specified in the user’s Livelink profile.

• E-Mails are only sent to direct members of the selected Livelink groups.

• The total address list must not exceed 10,000 characters (about 500 e-mail
addresses).

3
Each address is separated using whatever symbol has been defined as a system preference. The instruction for this
field will indicate this symbol (e.g. comma, semi-colon, etc.)
 WebReports User Guide

Export to E-Mail Screen

Manually typed e-mail addresses

Livelink User or Group

selection dialogue

Livelink CSV address

list - browse dialogue

7.6 Exporting to a WebForm

When exporting to a WebForm, the user has the capability to take the results of a report, or
selectively choose parts of it, and insert those results into a Livelink WebForm. This provides
a powerful capability where a report developer can import data from other systems into a
WebForm, or possibly from one WebForm to another within the same system. Advanced
users could use this capability to create a cache from a larger data set and then have other
reports run against this cache, which is being updated on a regular schedule.

The export to WebForm feature allows the user to update existing WebForm data, overwrite
the existing data or append more data to the existing data. In order to specify what pieces of
data from the WebReport are inserted into the WebForm the SETFORM sub-tag must be
used. [LL_REPTAG=USERID SETFORM:USER /] would, for example, take the id of the user
and insert it into the column USER. A slightly more advanced example might involve using
sub-tags to operate on the data before inserting it into the WebForm. [LL_REPTAG=USERID
USERINFO:GROUPID SETFORM:GROUP /] uses USERINFO with the GROUPID parameter
to retrieve the group of the current user, SETFORM then takes this and inserts it into the
WebForm field called GROUP. It's possible to use SETFORM to insert data for as many fields
as needed.

Export to WebForm Screen

 WebReports User Guide

Livelink WebForm -
browse dialogue

Options for updating

7.7 Exporting to a Workflow

This feature can be used to trigger Livelink Workflows based on results in a WebReport. It can
be used in conjunction with sub-WebReports to launch an unlimited number of Workflows
from an unlimited number of Workflow maps. The report itself can be optionally attached to
the Workflow as a document and WebForms associated with the Workflow populated with
data from the WebReport. Additionally, any number of Workflow attributes can be populated,
as well as other meta-data including things like the Workflow due date and title. In order to
determine which elements of a WebReport are used to set data in a Workflow, we need to use
the sub-tags SETWFATTR and SETWFFORM.

Export to Workflow Screen

Livelink Workflow Map

– browse dialogue

Option for Workflow

attachment
 WebReports User Guide

7.8 Exporting to the Livelink Server

This feature is only available to users logged in as the Livelink Admin user. It allows the
Admin user to define an export location on the server and export the report to that place. If
this is set as the default behavior, WebReports users with permission to run reports will be
able to execute the report but they will not be able to change the existing server path or define
a new export path. The path should be specified like any other path on the file system - for
example 'C:\export_testing\test_export.xml'

7.9 Exporting to a FTP Server

This feature allows the developer to define an export location on a FTP server and export the
report to that place using a Passive connection. A relative file path should be used for the
output location - eg: 'FolderA/WR_output.html'. There are three options available if a file
already exists on the FTP server with the same name:

• Replace Existing - The existing file will be overwritten with the new WebReport output.

• Unique Name - A unique number will be appended directly before the output file's
extension - example: 'WR_output1.html'.

• Skip Output - The WebReport output will not be transferred to the FTP server.

Useful tips:

• If the FTP server allows anonymous login, simply check the 'Anonymous User Login'
checkbox. The feature will attempt to login using the Anonymous username and use the
email address of the user executing the WebReport as the password.

7.10 Configuring Default WebReport Behavior

It is possible to change the default action resulting from clicking on a WebReport in Livelink,
so that rather than running the report and displaying the output in the browser, the output is
redirected to an export operation. E.g. a WebReport could be configured to add a new
version to a Livelink document each time it is clicked. This behavior is specified from the
Destination tab using the Properties → Destination Function menu option. The fields for
specifying this default behavior are exactly the same as described for explicit exports as
shown below.

Page 119
 WebReports User Guide

Select an alternative
output destination
behaviour
 WebReports User Guide

8 PDF Conversion

8.1 Overview
Several of the WebReports destinations support third party document conversion which can
be used to create PDF formatted reports. The destinations are:

• Email

• Livelink Node

• Livelink Version

• Server

In earlier versions of WebReports, PDF conversion was supported in a slightly different form.
The user had the option of selecting a PDF MIME type which, upon its selection, caused the
reportview to be converted into a PDF format. This had limitations in that the reportview being
converted to PDF could only be in HTML format.

From WebReports 4.0, the MIME Type and conversion process have been decoupled. This
means the user can use WebReports to create a document of any type e.g. WordML or
SpreadsheetML and then perform the conversion process on this document. This brings
much more flexibility to the look of the document being converted.

8.2 How to Convert a Document

In order to convert a document, all a user needs to do is check the Use External Conversion
Engine on the destination tab of any WebReport and it will be converted into PDF format.

Note that PDF conversion is not instantaneous. The user may need to wait for several
minutes for a report to appear at the destination location.

Use External Conversion

Engine option
 WebReports User Guide

Note: before PDF conversion can be used, your Livelink Administrator must configure options
in the Livelink Admin Pages:

If you are an Administrator, see the Manage WebReports Conversion section in the on-line
Admin help.

8.3 XML Job Tickets

XML Job Tickets can be a very useful tool for users using Adlib Express for file conversion. A
job ticket allows a user to specify many different aspects of how a document will be converted
by Adlib, such as page formatting for example. This feature allows users to select a custom
job ticket they have created, and have it applied to a WebReport when it is being converted
by Adlib Express. Currently, this feature is only able to be used with Adlib Express conversion
software, as XML Job Tickets are a feature of that software.

The following tables describe the tags recognized by WebReports. Not all tags are supported
in all sections of the reportview. The supported sections (header, row template, footer) are
indicated beneath each tag name.

8.3.1 Creating an XML Job Ticket

• XML Job Tickets must be valid in order to be used. The following rules must apply to
each job ticket in order to be valid:

o Must contain an XML header at the very top, similar to <?xml version="1.0"
encoding="ISO-8859-1" ?>
o The XML header must be followed by the Adlib header tag containing version
of Adlib the ticket conforms to, such as <?AdLibeXpress applanguage="USA"
appversion="2.7.0" dtdversion="1.8" ?>
o Must contain a <JOBS> tag.
o Has to contain only one <JOB> tag. Although Adlib supports multiple jobs in
one ticket, this is not practical with WebReports conversion. Each converted
document will have its own job ticket.
o Must contain a <JOB:DOCINPUTS> tag with a <JOB:DOCINPUT .../> tag
nested inside of it. This contains information about where Adlib can find the
file to be converted. Similarily, <JOB:DOCOUTPUTS> must exist with a
<JOB:DOCINPUT .../> tag nested inside, as this contains information for
Adlib regarding where to place the converted file.

Page 122
 WebReports User Guide

o Although many attributes can be added to the <JOB:DOCINPUT .../> and

<JOB:DOCOUTPUT .../> tags, they must contain the FOLDER attribute to be
valid.

• Any FILENAME attribute found in the JOB:DOCINPUT/ JOB:DOCOUTPUT tags will

be replaced with a dynamically generated filename, so this attribute, although
optional, is not necessary and has no effect on the processing of the file to be
converted.

• The FOLDER attribute needs to contain a valid file path in order for the files to be
processed and delivered properly. The only exception to using a valid file path is
using the new $DEFAULT_PATH term.

This feature also supports the use of WebReports tags within the job ticket file. More
information regarding Job Ticket features can be found with Adlib Express documentation, as
feature availability depends on version of Adlib Express being used.

8.3.2 The $DEFAULT_PATH

When used as part of a Job Ticket file in the FOLDER attribute, $DEFAULT_PATH will
dynamically insert the appropriate file path as specified in the Manage WebReports
Conversion administration page.

There are two sets of directories that can be specified in the administration page, and if the
set of directories for use with XML Job Tickets has been specified, the $DEFAULT_PATH term
will return those file paths; otherwise, if not specified, it will return the first set of conversion
directories specified for conversion.

Because this is not a constant, you can use this term as part of the FOLDER attribute in both
DOCINPUT and DOCOUTPUT tags. Using this will return the proper file path where used.

8.3.3 Selecting a Job Ticket

The interface for selecting a Job Ticket to be used when sending a file for conversion is found
alongside the ‘Use External Conversion Engine’ check box in the destination tab for any
WebReport. The interface will only be displayed if the ‘Use External Conversion Engine’
checkbox is checked and XML Job Tickets have been enabled in the admin pages.

• To select a Job Ticket to use during conversion, just click the ‘Browse Livelink...’
button, and browse for a job ticket file that a user has created and placed in Livelink.

• If you would like to change a WebReport’s settings so it is still sent for conversion, but
not use a job ticket anymore, simply press the clear button and update the page.

• If a job ticket has been selected and the destination page has been updated, there is
a function menu available to access the functions available to the job ticket file
selected.

8.3.4 Example Job Ticket

<?xml version="1.0" encoding="ISO-8859-1" ?>

<?AdLibeXpress applanguage="USA" appversion="2.7.0" dtdversion="1.8

Page 123
 WebReports User Guide

" ?>
<!DOCTYPE JOBS SYSTEM "C:\AdLib eXpress\DTD\AdLibeXpress.dtd">
<JOBS xmlns:JOBS="http://www.adlibsys.com" xmlns:JOB="http://www.adli
bsys.com">
<JOB>
<JOB:DOCINPUTS>
<JOB:DOCINPUT FILENAME="" FOLDER="$DEFAULT_PATH" />
</JOB:DOCINPUTS>
<JOB:DOCOUTPUTS>
<JOB:DOCOUTPUT FILENAME="" FOLDER="$DEFAULT_PATH" D
OCTYPE="PDF" />
</JOB:DOCOUTPUTS>
</JOB>
</JOBS>

Page 124
 WebReports User Guide

9 Setting Schedules for WebReports

9.1 Overview
WebReport developers (i.e. users with reserve permission) can set up execution schedules
for individual WebReports to run without user intervention. Scheduled reports run in the
background and output their results to a Livelink document node or to e-mail. The schedule
allows for reports to run a fixed number of times or forever, starting from a specific date and
time. The time between repeated report runs can be from 5 minutes to 520 weeks. One
schedule can be set per user per WebReport.

9.2 How to Set a Schedule

To set a schedule, select Properties → Destination from the function menu of the
WebReport. Choose the desired output destination: either Livelink or E-Mail and fill in the
required details for that output destination. Check the Set Schedule checkbox and an
additional set of options will appear:

• In the Next run after fields, set the date and time that the report should first run. Note
that actual execution times may be up to 5 minutes after the time set here. Typically,
report runs happen on the hour and 5, 10, 15 minutes etc. past the hour.
• In the Run field, either check Forever or enter the number of times the report should run
in Times.
• Set the interval between report runs in minutes, hours, days, and weeks.
• Click Update and the schedule will be set.

9.3 How to Set a WebReport to Run on the Same Date or Day

In some circumstances it might be necessary to have a WebReport run on the same day of
the month, every month. As an example, an employee overtime report might be required on
the 25th of each month. The fixed scheduling interval that WebReports provides means this
can’t be readily achieved through the interface, rather you need to use sub-WebReports. Use
the following method to achieve this:

• Create a WebReport as normal and set its output destination to the desired location

• Create a second WebReport that has no data source and set it to run on a daily schedule
at the time you want the report to execute on the 25th

• Make the second WebReport call the first one by using

[LL_WEBREPORT_SUBWEBREPORT\

Page 125
 WebReports User Guide

• Finally, wrapper the call to the sub WebReport with a [LL_WEBREPORT_IF statement
that checks the day of the month

Your second WebReport (the “master” report) should contain code something like this:

[LL_WEBREPORT_IF "[LL_REPTAG_DATE DATE:'%d' /]" == "25" /]

[LL_WEBREPORT_SUBWEBREPORT NODEID:[LL_REPTAG_$main_rep /] /]
[LL_WEBREPORT_ENDIF /]

9.4 How to Remove or Change a Schedule

To remove a schedule, open the WebReport’s Properties → Destination page and uncheck
the Set Schedule checkbox and Click Update. Other schedule settings will be retained but
the report will no longer run until the checkbox is re-checked. To alter settings, make your
changes and click Update.

If a report has been scheduled to run a fixed number of times, the remaining number of times
and next run time will be updated by Livelink so you can see how many more runs are
expected and when the next one will happen.

Note that the Livelink Administrator has the power to disable or delete schedules created by
other users. This is achieved in the Livelink Administration pages (see the WebReports
Installation and Administration Guide for more details).

9.5 Important Notes and Recommendations

• Users should be cautious about when and how often to schedule a report that returns a
very large dataset. Such reports can require significant resources and might impact
system performance if run too often or at peak times.
• If Livelink services are turned off or Livelink Agents are disabled for another reason,
scheduled reports will not run. Once enabled again, WebReports will run a report at the
soonest opportunity if a report was missed (regardless of the schedule). After this,
WebReports will run the report at the next time in the future that fits the schedule. If
irregular run times are observed it is most likely due to this.
• The output destination settings (e-mail or Livelink) are the same for scheduling as for the
default action for a user clicking the WebReport link. If these need to be different it is
recommended that two WebReports with the same reportview are used. The scheduled
report can be hidden or placed in a permissioned folder.
• Scheduled WebReports run as if they were run by the user that set the schedule. This
means that where a permissions filter is used in a data source, such as a LiveReport or a
search query, it will return results that this user has the permissions to see. Always output
sensitive reports to an appropriately permissioned location in Livelink.

Page 126
 WebReports User Guide

10 WebReport Constants

10.1 Overview
The Constants feature provides the capability to pre-define data which can be inserted into
the report output. This feature is typically used in the following situations:

• Where some text or information in the WebReport might require changing periodically,
a constant can be used to allow easy maintenance which can be performed by a non-
technical person.

• Where values must be manually defined (such as attribute numbers), constants make
it easy to define and maintain these parameters.

• Where the same reportview is to be used for multiple WebReports in different ways,
each WebReport can have different constant settings.

• Where a reportview is being created with references which may vary between
systems, constants allow system transparency to be managed. (Note, the XML
import/export feature attempts to translate any references to Livelink objects between
systems).

10.2 Adding a WebReport Constant

To define constants for the WebReport manually

Use the procedure below where you have constants you want to define but have not yet used in
the WebReport. Once defined here you can reference them in the reportview.

• Select the Constants tab for the WebReport using the function option: Properties →
Constants.

• Select the + button to add a new constant (if no other constants have been defined
the 'Click here to add new constant' option can also be used).

• Using the new, blank row which is created add a constant name, constant value, and
optionally a constant description. Note: the constant name should not include spaces.
The constant value provides the optional capability to browse for a Livelink object.
This option automatically inserts an object ID into the value field.

• Select the Update button from the bottom of the screen.

To define constants for the WebReport automatically

Use this method where you have made reference to a constant or multiple constants in the
reportview and want to quickly populate them on the constants tab. This method saves time on
the method above as it allows the constants to be populated on mass. It also, where possible, will
determine the constant type programmatically. Where this is not possible, the constant will be of
type string.

• Select the Constants tab for the WebReport using the function option: Properties →
Constants.

Page 127
 WebReports User Guide

• Select the button to add all the constants that are used in the reportview. Note that
this icon only appears when the reportview contains constants that are not defined on
the constants tab.

• For all the new constants, enter their constant value, and optionally a con
constant
description.

• Select the Update button from the bottom of the screen

screen.

Add Constant option

10.3 Referencing Constants in the WebReport Reportview

Once a constant has been defined, the corresponding value can be inserted into the
reportview as many times as required (it is not necessary to define a constant prior to adding
the corresponding tag in the reportview. It may be faster to define them via the
the automatic
method above once you have finished changing the reportview).

Example usage, if a constant called reportID had been stored to reference another
WebReport, the syntax used could be as follows:

?func=ll&objid=[LL_REPTAG_$reportID /]&objaction=
/]&objaction=runreport

A more appropriate example would be to use the same constant with LLURL as follows:

[LL_REPTAG_$reportID LLURL:REPORT /]

which should resolve to ?func=ll&objid=xyz&objaction=runreport where xyz is the value of the

constant reportID. The benefit of this approach is that if Livelink changes the way this URL
works, the report will continue to function whereas the first method would require changes to
the report.

If working in the WebReports online editor,

editor it is possible to use the drag-and-drop
drop iinterface to
speed up some activities.

• You can drag and drop constants by selecting the appropriate constant from the
dropdown list and then dragging the icon to the point in the reportview where you
want to insert the constant.

• You can open the constants tab in a new window by selecting the constants hyperlink
before the dropdown.

• You can update the list of constants in the dropdown by clicking the icon. This has the
effect of updating the list without reloading the page.
 WebReports User Guide

• Constants appearing in the dropdown list with a star (*) next to them are Global
Constants. These can be used the same as regular constants, the difference being that
they are defined in a different WebReport.

10.4 Deleting a WebReport Constant

To delete a constant:

• Select the Constants tab for the WebReport using the function option: Properties →
Constants.

• Select the – (minus) button for the constant to be deleted and accept the warning
message by selecting OK.

• Select the Update button from the bottom of the screen.

Alternatively:

• Select the red X button to delete all the constant definitions for the entire WebReport.

• Select the Update button from the bottom of the screen.

Delete all constant

definitions option

10.5 Global Constants

Global Constants are an extension of standard constants and provide the ability to centrally
manage constants for a particular collection of WebReports that rely on the same data. This is
particularly useful where the user has a group of WebReports, Forms and other Livelink
objects that are working together to create an application. Each WebReport can refer to a
single Global Constant report defined at the top of its constants page.

The concept would be to have all WebReports for a particular application point to a single
WebReport that is used to manage the constants for the entire application. The benefit of this
is that once a constant is defined in your global report, it is available to all WebReports that
point to that WebReport. This is a big time saver when you consider that a WebReports
application may be built from 50 or more WebReports and other objects which all need to
refer to each other.

Global constants can be "daisy chained" so that one WebReport points to another and so on.
Even so, global constants adhere to Livelink permissions, so if a user does not have
permission to see a given WebReport they will not be able to make use of the constants
defined in it.
 WebReports User Guide

When working in the online editor global constants appear with a star (*) next to them in the
dropdown list.

Page 130
 WebReports User Guide

11 Using Parameters

11.1 Overview
When running a WebReport, parameters can be included in the URL for the WebReport itself
as well as for the associated data source. These two parameter types are described here.

WebReport parameters - There are several parameters which are used to control the
behavior of the WebReport. Many of these parameters are designed to allow WebReport
designers to construct unique URLs to modify the WebReport behavior according to
application requirements. In addition to these built-in parameters, the WebReports module
also supports the creation and use of unique parameters as defined by the WebReport
developers. These are passed by placing &parmname=data in the parameter list of the URL
where 'parmname' can be any string of standard alpha-numeric characters.

E.g. ...?func=ll&objId=47478&objAction=RunReport&myparm=testdata&nexturl=....

This data is then accessible within the reportview using the defined tag syntax. E.g.
[LL_REPTAG_&myparm /] would return "testdata" in the previous example.
(Note: sub-tags can be used to modify the data returned by a parameter tag.)

Data Source parameters - The data sources, LiveReports and Search Queries, allow input
parameters to be defined and collected when the report is run. When a LiveReport is being
used as a data source, the standard LiveReport prompting will be allowed prior to the
WebReport executing if no parameters have been supplied in the URL. In this scenario, when
the WebReport is run, the user is presented with the LiveReport prompts much as if they had
run the LiveReport directly. Once the user has entered the required prompts then the
WebReport continues as normal.
When a WebReport has been defined with a saved query as the data source, it is possible to
insert variables into the full text search specification of the saved query. For example, the
term %1 can be placed in the 'Full Text Search Terms' field of any full text search boxes.
These variables will be substituted with any corresponding parameters in the URL. URL
parameters follow the same convention as a LiveReport, i.e. inputlabel<x>=value (where x is
a number from 1 to 99 which corresponds with variables %1, %2, etc.) In the example below,
a variable such as %1 would be replaced with the word 'WebReport' by using a URL
parameter in the form: inputlabel1=WebReport. These variables can also be used in
complex queries as part of the Livelink Query Language (LQL). Additional information about
using search can be found in the online help.

E.g. ...?func=ll&objId=47478&objAction=RunReport&inputLabel1=WebReport&nexturl=....

If a WebReport is run by invoking its URL from a user developed page (e.g. HTML document
or another WebReport) then it is possible to supply the necessary input parameters for both
the WebReport and any data source in the URL that is used to invoke the WebReport. If all
required LiveReport parameters are passed within the URL, the user will not be prompted for
the input parameters in the normal way.

Default parameters WebReports provides a feature to allow defaults to be set for any
parameters that would normally be passed through the URL. When a default value is set for a
parameter, then this value will be used if no corresponding parameter is found in the URL.

11.2 Adding a WebReport Parameter

To define parameters for the WebReport manually

Page 131
 WebReports User Guide

Use the procedure below where you have parameters you want to define but have not yet
used in the WebReport. Once defined here you can reference them in the reportview.

• Select the Parameters tab for the We

WebReport
bReport using the function option: Properties
→ Parameters.

• Select the + button to add a new parameter (if no other parameters have been
defined the 'Click here to add new parameter' option can also be used).

• Using the new, blank row which is created, add a parameter name, display text,
prompt order, default value, and other settings.

• Select the Update button from the bottom of the screen.

To define parameters for the WebReport automatically

Use this method where you have made reference to a parameter or m multiple
ultiple parameters in
the reportview and want to quickly populate them on the parameters tab. In addition,
parameters defined in LiveReport data sources will also be populated on the tab. This method
saves time on the method above as it allows the parameters
parameters to be populated on mass. It also,
where possible, will determine the parameter type programmatically. Where this is not
possible, the parameter will be of type string.

• Select the Parameters tab for the WebReport using the function option: Properties
→ Parameters.

• Select the button to add all the parameters that are used in the reportview or
LiveReport data source.
source. Note that this icon only appears when the reportview or
LiveReport contains parameters that are not defined on the parameters tab.

• For all the new parameters

parameters, add a parameter name, display text, prompt order,
default value and other settings.

• Select the Update button from the bottom of the screen

screen.

11.3 Referencing Parameters in the WebReport Reportview

Once a parameter has been defined, tthe
he corresponding value can be inserted into the
reportview as many times as required (it is not necessary to define a parameter prior to
adding the corresponding tag in the reportview. It may be faster to define them via the
automatic method above once you have finished changing the reportview).

If working in the WebReports online editor,

editor it is possible to use the drag-and-drop
drop interface to
speed up some activities.

• You can drag and drop parameters by selecting the appropriate parameter from the
dropdown list and then dragging the icon to the point in the reportview where you
want to insert the parameter.

• You can open the parameter

parameters tab in a new window by selecting the parameters hyperlink
before the dropdown.

• You can update the list of parameters in the dropdown by clicking the icon. This has
the effect of updating the list without reloading the page.
 WebReports User Guide

11.4 Deleting a WebReport Parameter

To delete a parameter:

• Select the Parameters

arameters tab for the WebReport using the function option: Properties
→ Parameters.

• Select the – (minus) button for the parameter to be deleted and accept the warning
message by selecting OK.

• Select the Update button from the bottom of the screen.

Alternatively:

• Select the red X button to delete all the parameter definitions for the entire
WebReport.

• Select the Update button from the bottom of the screen.

11.5 Parameter Tab Settings

This table provides details of the different options available on the parameters tab and the
effect they have on the end report.

Option Description

This is the name of the parameter as it will appear in the URL once the
user has selected their values and selected Run on the prompting page.
Parameter Name
The parameter name must not contain spaces
spaces or other characters which
cannot
not be passed in a URL. TThe
he end user will be largely unaware of this
value.

This is the text that the user will be prompted with. It differs from the
Display Text
parameter name in that is can be more descriptive and can contain
spaces.

This checkbox determines whether the user will see the prompt or not. If
the user it not prompted for a particular parameter, the default value will
Prompt be used. If turning off prompting for a parameter, make sure you do not
put the user in a situation where they are stuck. This might happen if
you make a parameter mandatory, turn the prompting off and don't
select a default value.

This checkbox determines whether a parameter is mandatory or not. If a

parameter is mandatory, the user will not be able to go beyond the
Mandatory
prompt screen without selecting a value for the parameter (unless the
parameter has a default value). Mandatory parameters can be identified
on the prompt screen by the icon next to the prompt text.

Prompt Order This field determines the order in which the parameter
parameterss will appear on
the prompt screen. The values can be alphanumeric.

Type This field will determine the type of parameter the user is prompted for.
This can be String, ObjectID, User, Number, Object, Date or Custom.
 WebReports User Guide

See the separate parameter type table for details of each parameter
type.

This is the value that will be used if the user doesn't select a value on
Default Value the prompt screen. The value will appear pre-populated on the prompt
screen. The value will be used by WebReports that are running on a
schedule.

The description is a free text field which allows the WebReport

developer two options. They can put comments in it so as to remind
them and other developers about an implementation detail. The second
Description
option is to tick the Show Descriptions checkbox at the top of the
parameters page - this will cause all the descriptions to appear on the
prompt screen where they can be used to provide the end user with
instructions. This field can contain HTML tags.

Show Descriptions This field determines whether the description text for all the parameters
appears on the prompt page.

When selected, the contents of this file will be rendered at the top of the
prompts page. This allows developers to quickly apply the same
branding or instructions to the top of all their prompting screens. A text
Prompt File based document or a separate WebReport may be selected to provide
this text. If using a WebReport this gives the developer the flexibility to
bring back dynamic content to the prompt screen. One use of this might
be to perform some summary counts on the data the user is about to
select from on the prompting screen.

11.6 Parameter Types

This table illustrates the different parameter types which can be selected on the parameters
tab and the effect they have on the end report.

Type Description

String The String parameter type will prompt the user with a free text field.

The ObjectID parameter type allows the report developer to specify types of
Livelink objects the user can select from on the prompt screen. One or more
ObjectID
items can be selected from the multi-value list and at least one type must be
selected before the developer can browse for a default value.

This field allows the report developer to create a user prompt. The
User developer can decide whether the user is allowed to browse for Users,
Groups or Users and Groups.

Number Similar to the String parameter but forces the user to enter a numeric value.

Allows the user to select a Livelink sub type. For example, select Document
Object
(144) or Folder (0).

Prompts the user with a date field. The developer can decide whether the
Date
time is displayed or not - also whether the user is prompted with a blank

Page 134
 WebReports User Guide

date, the current date or a specific date in time.

Here the developer can browse for a WebReport that is being used to
Custom provide a custom prompt. The developer might use this to create a custom
pick list, for example.

Page 135
 WebReports User Guide

12 Data Source Parameters

12.1 Overview
WebReport data sources (LiveReports, Search Queries, Forms, etc.) can be manipulated
using special parameters called data source parameters. These parameters are passed in the
URL when a WebReport is executed and control things like the maximum number of results
on each page:

Parameter Name Description

This parameter allows an alternative data source to be specified as a
sourceid dataid. The dataid must correspond with one of the node types which
are currently supported by WebReports as data sources.
This parameter allows the starting row from the data source to be
specified using a number from 1 to N. This means that any rows prior to
the specified DSstartrow will not be used in the report. For example if
DSstartrow the data source normally had 100 rows of data and a DSstartrow of 21
was specified (without any DSendrow or DSmaxrows parameters),
then only rows 21 through 100 would be used. This parameter can be
combined with the DSendrow or DSmaxrows parameters.
This parameter allows the last row from the data source to be specified
using a number from 1 to N. This means that any rows after the
specified DSendrow will not be used in the report. For example, if the
data source normally had 100 rows of data and a DSendrow of 75 was
specified (without any DSstartrow or DSmaxrows parameters), then
only rows 1 through 75 would be used. This parameter can be used with
the DSstartrow or DSmaxrows parameters. When used with the
DSendrow DSmaxrows parameter, whichever parameter results in the most
limited set of data, will have precedence. For example, given the
parameters: DSstartrow=1, DSendrow=75 and DSmaxrows=20, only
rows 1 through 20 would be used. Given the parameters: DSstartrow=1,
DSendrow=20 and DSmaxrows=100, only rows 1 through 20 would be
used. If this parameter is specified as a negative number then zero (0)
rows are returned. If this parameter specifies a row number less than
the DSstartrow parameter then zero rows are also returned.
This parameter specifies the maximum number of rows to be used from
the data source using a number from 1 to N. This means that there will
never be more rows than the number specified in DSmaxrows. As
described for DSendrows, DSmaxrows specifies a maximum number
DSmaxrows
of rows but the actual number of rows may be less than DSmaxrows if
the DSstartrow and DSendrow parameters combine to specify a
smaller set of data. If this parameter is specified as a negative number
then zero (0) rows are returned.

Example of URL invocation:

?func=ll&objId=1234&objAction=RunReport&sourceid=12345&DSstartrow=11&DSendr
ow=100&DSmaxrows=50

In this example, the data source identified by nodeid 12345 will be used to supply data for the
WebReport. The data used will end at row 50 (despite the DSendrow parameter being set to
100) because the DSmaxrows parameter is set to 50.

Page 136
 WebReports User Guide

12.2 Pagination
One useful application of data source parameters is pagination. This is discussed in full detail
in the on-line help section called “Detailed Examples”.

Page 137
 WebReports User Guide

13 Export Parameters

13.1 Overview
This section provides additional information on the use of Export Destinations. Specifically, it
provides detail on how various export types can be controlled using URL parameters. This is
particularly useful for developments where WebReport exports may be invoked from tailored
web pages instead of the standard export interface described in the basic export procedures
documentation. For each export type, all of the available URL parameters are described along
with an example of usage.

Each export destination has an explanatory table with the following columns:

• Parameter Name - the name of the parameter as it would appear in the URL.

• Name in interface - this is the name which will appear in the grey box on the left hand side
of the export screen.

• Mandatory - simply indicates whether the parameter is mandatory or not. An export will
fail if mandatory parameters are missing.

• Valid Values - these are the values which are supported for the specified parameter. Note
that when a value containing a space or other special character is passed, it must be
escaped appropriately.

• Replacement Tags - some parameters support WebReports replacement tags being

passed in the URL. This field indicates whether tag replacement is supported for the
parameter. Note that, as above, if these contain spaces, they must be appropriately
escaped for use in a URL.

13.2 Exporting to Desktop

Parameter Support:

Parameter Name Name in Interface Mandatory Valid Values Replacement

Tags
objAction Yes RunReport No
export_location output destination Yes desktop No
mimetype Export MIME type No All values as shown in the No
Export MIME type field

Example of URL invocation:

?func=ll&objId=1234&objAction=RunReport&export_location=desktop&mimetype=application
%2Fvnd.ms-excel

Here WebReport 1234 exports to desktop with a Mime type of application/vnd.ms-excel

Page 138
 WebReports User Guide

13.3 Exporting to Livelink - Node

Parameter Support:

Parameter Name Name in Mandatory Valid Values Replacement

Interface Tags
Yes RunReport No
objAction
Output Yes livelink No
export_location Destination

livelink_node Export Type Yes livelinknode No

newNode_ID Create In Yes Any valid Livelink container ID Yes

nodeName Name Yes Any valid Livelink node name Yes

Export MIME No All values as shown in the No

mimetype
Type Export Mime Type field

Description No Any valid Livelink node Yes

expcomment
description

Yes An escaped URL where the No

nexturl
user will go following the export

Example of URL invocation:

?func=ll&objId=1234&objAction=RunReport&export_location=livelink&livelink_node=livelinkno
de&newNode_ID=2000&nodeName=%5BLL_REPTAG_DATE%20%2F%5D&mimetype=text
%2Fplain&nexturl=...

Here WebReport 1234 exports to a new Livelink node with a Mime type of text/plain. The
resultant file will be placed in the folder with id 2000 with the name being the current date.

13.4 Exporting to Livelink - Version

Parameter Support:

Parameter Name Name in Mandatory Valid Values Replacement

Interface Tags
objAction Yes RunReport No
export_location Output Yes livelink No
Destination
livelink_node Export Type Yes livelinkversion No

newVersion_ID Add Version to Yes Any valid Livelink document Yes

or customview ID
mimetype Export MIME No All values as shown in the No
Type Export Mime Type field
expcomment Description No Any valid Livelink node Yes

Page 139
 WebReports User Guide

description

nexturl Yes An escaped URL where the No

user will go following the
export

Example of URL invocation:

?func=ll&objId=1234&objAction=RunReport&export_location=livelink&livelink_node=livelinkve
rsion&newVersion_ID=5678&mimetype=text%2Fplain&nexturl=...

Here WebReport 1234 adds a new Livelink document version with a Mime type of text/plain to
the document id 5678.

13.5 Exporting to E-Mail

Parameter Support:

Parameter Name Name in Mandatory Valid Values Replacement

Interface Tags
objAction Yes RunReport No
export_location Output e-mail No
Yes
Destination
emailAddress E-mail address* any valid e-mail Yes
Yes
address
newVersion_ID E-mail address* The object id of a text Yes**
Yes file containing csv e-
mail addresses
usergroup_ID E-mail address* A Livelink user id or Yes
Yes
group id
emailSubject E-mail Subject No Any text Yes
mimetype Export MIME All values as shown in No
Type No the Export MIME Type
field
attachToEmail Attach Results to “yes” or “no” No
No
E-mail
emailAttachmentName Attachment Any valid file name Yes
No
Name
emailbody E-mail body text Text to appear in the Yes
No
body of the e-mail
nexturl An escaped URL where No
Yes the user will go
following the export

*Only one of these is mandatory but it's possible to use all 3 if required.
**Replacement tags are supported to determine the value of newVersion_ID (which must be a
text document) but also can be contained within the document itself.

Example of URL invocation:

?func=ll&objId=1234&objAction=RunReport&export_location=email&emailAddress=lbutler@r
esonatekt.com&emailSubject=Status%20Report&attachToEmail=on&emailbody=Please%20s

Page 140
 WebReports User Guide

ee%20attached&mimetype=application%2Fvnd.ms-excel&nexturl=...

Here WebReport 1234 sends an email to [email protected] with the subject Status
Report. The report is attached to the email in Excel format with a default name (because
emailAttachmentName isn't specified) and the email body has the text Please see attached.

13.6 Exporting to a WebForm

Parameter Support:

Name in Replacement
Parameter Name Mandatory Valid Values
Interface Tags
objection Yes RunReport No
export_location Output destination Yes form No
Populate Form Yes A valid Livelink WebForm id Yes
form_ID
(not template id)
appendForm Append Results Yes overwrite, append, update No
Yes An escaped URL where the No
nexturl
user will go following export

Example of URL invocation:

?func=ll&objId=1234&objAction=RunReport&export_location=form&form_ID=5678&appendF
orm=overwrite&nexturl=...

Here WebReport 1234 deletes the contents of WebForm 5678 and populates it with data
specified in the WebReport with SETFORM

13.7 Exporting to a Workflow

Parameter Support:

Name in Replacement
Parameter Name Mandatory Valid Values
Interface Tags
objAction Yes RunReport No
Output Yes workflow No
export_location
Destination
workflow_id Initiate Map Yes A valid Workflow map id Yes
Attach Output to No “yes” or “no” No
attach
Workflow
Attachment Yes* The name of the report to Yes
nodeName
Name be attached
Workflow Title Yes Text to appear in the title Yes
workflow_title
of Workflow instance
Workflow No Text to appear in the Yes
workflow_description Description Workflow description
field
Attachment no All values as shown in No
mimetype MIME Type the Export MIME Type
field
duedate Workflow Due no Due_on, Due_in, no_due No
DueOn Due on No e.g. D/2014/1/15 No
Due in No Integer representing a No
Workflow_duein
number of days
Expcomment Attachment No Any valid description text Yes

Page 141
 WebReports User Guide

Description for the attachment

Yes An escaped URL where No
nexturl the user will go following
the export

*Only mandatory if attaching the report data to the Workflow

Example of URL invocation:

?func=ll&objId=1234&objAction=RunReport&export_location=workflow&workflow_ID=5678&a
ttach=on&nodeName=report%20data&mimetype=text/html&workflow_title=my%20new%20w
orkflow&nexturl=...

Here WebReport 1234 initiates an instance of workflow map 5678 and sets the title to my new
workflow. The report itself is attached to the workflow with a name of report data and a Mime
type of text/html.

13.8 Exporting to the Livelink Server

Parameter Support:

Replacement
Parameter Name Name in Interface Mandatory Valid Values
Tags
objAction Yes RunReport No
Output Yes server No
export_location
Destination
Server Path File Yes A valid path file on Yes
serverFilePath
the Livelink server
Export MIME type No All values as shown
mimetype in the Export Mime
Type field
Yes An escaped URL No
nexturl where the user will go
following the Export

Example of URL invocation:

?func=ll&objId=1234&objAction=RunReport&export_location=server&serverFilePath=C:\expo
rt_testing\test_export.xml&nexturl=...

Here WebReport 1234 adds a new file to the Livelink server file system at
C:\export_testing\test_export.xml.

Page 142
 WebReports User Guide

14 Logical Expressions

14.1 Overview
WebReports provides several conditional tags to allow selective filtering of the output using
logical expressions. Examples of the tags which support logical expressions include:
[LL_WEBREPORT_EXITIF (logical expression) /],[LL_WEBREPORT_INCLUDEIF (logical
expression) /] and [LL_WEBREPORT_IF (logical expression) /]

Logic expressions for these tags are made up of one or more logical clauses which are
separated by a logical Boolean operator (AND, OR, &&, ||). For example: clause1 AND
clause2 OR clause3

Each one of these clauses is made up of two operands which are compared using one of the
comparison operators (see table below for a list of supported operators). For example, each
clause is in the form: "parmA" == "parmB"

In these clauses each operand can be either a constant value or one of the WebReports
report tags which is supported for use in a logic expression (currently variables are not
supported in IF/ENDIF expressions and the ACTUALROWS tag cannot be used within a row
section). For example: "[LL_REPTAG_TOTALROWS /]" >= "10"

Using these two concepts a logical expression with multiple clauses could look like this:
[LL_WEBREPORT_IF "[LL_REPTAG_TOTALROWS /]" >= "10" AND
"[LL_REPTAG_&reptype /]" == "parmB" /]
...
[LL_WEBREPORT_ENDIF /]

Operators

WebReports support a variety of logical operators which are described in the following table.

Operator Meaning Notes

== Equal to Performs a string compare
!= or <> Not equal to Performs a string compare
Less than or equal Compares the operands in the following manner:
to
• If both operands can be treated as integers,
an integer compare is performed;
<=
• Otherwise if both operands can be treated as
dates a date compare is performed;
• Otherwise a string compare is performed.

Less than or equal Compares the operands in the following manner:

to
• If both operands can be treated as integers,
an integer compare is performed;
>=
• Otherwise if both operands can be treated as
dates a date compare is performed;
• Otherwise a string compare is performed.

< Less than Compares the operands in the following manner:

Page 143
 WebReports User Guide

• If both operands can be treated as integers,

an integer compare is performed;
• Otherwise if both operands can be treated as
dates a date compare is performed;
• Otherwise a string compare is performed.

Greater than Compares the operands in the following manner:

• If both operands can be treated as integers,

an integer compare is performed;
>
• Otherwise if both operands can be treated as
dates a date compare is performed;
• Otherwise a string compare is performed.

Second operand Compares the operands as strings returning TRUE if

contains first the first operand is contained at least once within the
IN
operand second operand. The comparison is case insensitive.
If either operand is an empty string IN returns TRUE.
Second operand Compares the operands as strings returning FALSE
does not contain if the first operand is contained at least once within
NOTIN first operand the second operand. The comparison is case
insensitive. If either operand is an empty string
NOTIN returns FALSE.
Second operand Compares the operands as strings returning TRUE if
starts with first the first operand appears at the start of the second
STARTIN
operand operand. The comparison is case insensitive. If either
operand is an empty string STARTIN returns TRUE.
First operand is a Treats the operands as Livelink Nodes returning
child node of the TRUE if the first node is contained directly or
second operand indirectly by the second node. If either operand is not
CHILDOF
a valid Livelink object ID, CHILDOF returns FALSE. If
either operand is an empty string CHILDOF returns
TRUE.
First operand is a Treats the operands as Livelink Nodes returning
not child node of the FALSE if the first node is contained directly or
second operand indirectly by the second node. If either operand is not
NOTCHILDOF
a valid Livelink object ID, NOTCHILDOF returns
TRUE. If either operand is an empty string
NOTCHILDOF returns FALSE.

Treatment of Dates in Logical Expressions

For certain operators ( <=, >=, <, > ) WebReports first attempts to convert the string operands
into integers. If conversion to integer is unsuccessful, WebReports attempts to convert the
operands into dates. (In reality operands cannot have a type as they are all raw strings;
however, strings conforming to a particular format can be interpreted as a type such as
integer or date). Only if the strings match any of the date formats described in the table below
will they be converted into dates and compared as dates. The supported formats match those
used by common WebReports tags and data source dates.

All the following examples will be treated as dates by WebReports:

Page 144
 WebReports User Guide

Tag Format Notes

[LL_REPTAG_DATE /] May 17 2008 Current date from Livelink Server
Thu May 17 11:59:04 Current date and time from Livelink
[LL_REPTAG_DATETIME /]
2007 Server
Thu May 17 11:59:04 Date and time from DTree table
[LL_REPTAG=CreateDate /] 2007 (same format from SQL Server or
Oracle database)
[LL_REPTAG=DataId Thu May 17 11:59:04 Date and time from NODEINFO
NODEINFO:CreateDate /] 2007 sub-tag
D/2007/5/17:8:13:0 This is a WebReports parameter
defined as a date in the parameters
tab with the time field enabled. The
time shown here is 8:13 AM. The
unusual format is an internal
system format used by Livelink to
represent dates stored as strings.
[LL_REPTAG_&dateParm /] Please note that a WebReports
parameter that is not defined as a
date in the parameters tab will not
be converted to a date unless it's
contents follows the format shown.
For example a string parameter
containing 5/17/2007 will not be
converted to a date for comparison
D/2007/5/17:0:0:0 Date input parameter defined in
LiveReport (and not defined in
[LL_REPTAG_&inputlabel1 /]
WebReports Parameter tab). No
time element can be specified

14.2 Order of Evaluation

The WebReports logic clauses do not support any bracketing to force expressions to be
evaluated in a particular order. The order of evaluation of any logical expression is that each
clause is evaluated from left to right. The logical result of each clause (TRUE or FALSE) is
compared with the result of the next clause to the right. The combined result of these two
operations is then passed to the next clause to the right, and so on. Logical operators are
compared using traditional Boolean logic. For example:

Left Clause Right Clause

Clause Operator Logical Result
Result Result
FALSE AND FALSE FALSE
FALSE AND TRUE FALSE
TRUE AND TRUE TRUE
FALSE OR FALSE FALSE
FALSE OR TRUE TRUE
TRUE OR TRUE TRUE

To illustrate how multiple clauses are evaluated, consider the following example:

Page 145
 WebReports User Guide

Clause 1 Clause 2 Clause 3 Clause 4

"5" == "5" AND "10" != "5" OR "10" == "2" AND "5" == "10"

This simplistic expression would be evaluated from left to right as follows:

• Clause 1 evaluates to TRUE

• Clause 2 evaluates to TRUE
• Clause 1(TRUE) AND clause 2(TRUE) results in TRUE
• Clause 3 evaluates to FALSE
• The previous result of TRUE OR clause 3 (FALSE) results in TRUE
• Clause 4 evaluates to FALSE
• The previous result of TRUE AND clause 4 (FALSE) results in FALSE

Thus the end result of this logical expression is FALSE. From this example it should be
evident that the rightmost parameter has the highest precedence. For example, if the
rightmost clause resolves to FALSE and the preceding logical operator is AND, then the result
will always be FALSE regardless of any other parameters. Similarly, if the rightmost clause
resolves to TRUE and the preceding logical operator is OR, then the result of the expression
will always be TRUE.

If this logical expression was written out using brackets it would look like this:

( ( (("5" == "5") AND ("10" != "5")) OR ("10" == "2")) AND ("5" == "10"))

Page 146
 WebReports User Guide

15 Sorting Results

15.1 Overview
The WebReport content control tag [LL_WEBREPORT_SORT <Sort Keys> <Global
Direction> /] makes it possible to sort data using one or more columns from the data source
specified as sort keys. There are three different ways to specify the column reference for each
sort key:

• Specify a column number from the data source. A numeric value representing the column
number from left to right in the data source can be used. E.g. [LL_WEBREPORT_SORT
"1" /].
• Specify a column name from the data source. A text value representing the name of one
of the columns used in the data source can be used. [LL_WEBREPORT_SORT "dataid"
/].
• Specify a WebReports tag and sub-tags to be used as a sort key. This function allows the
sort to be based on different criteria than the normal data returned by the column. For
example: [LL_WEBREPORT_SORT "[LL_REPTAG=DATAID NODEINFO:NAME /]" /]
In this example, rather than sorting on the DataId column, the sort will be based on the
name of the DTree object which is returned by NODEINFO:NAME.

Multiple sort columns can be specified allowing the user to sort within a sort and so on. As an
example, we could sort by the first column, and within this we could sort on the second
column, and within this the third column. Here is how the syntax might look followed by an
example of the output.

[LL_WEBREPORT_SORT "1" "2" "3" /]

column 1 column 2 column 3

a 27 zucchini
b 1 apple
b 8 carrot
b 8 zucchini
d 1 potato

The methods above can be combined to provide sorting on multiple key values as shown in
the following examples:

[LL_WEBREPORT_SORT "1":ASC "name" "[LL_REPTAG_3

DECODE:1:Active:2:Inactive /]":ASC /]

This sorts by the first column explicitly in the ascending direction, then the name column, also
in the ascending direction (by default), then depending on the value in column 3, we either
sort on the column Active or Inactive, also ascending.

[LL_WEBREPORT_SORT "1" "name":DESC

"[LL_REPTAG_3 DECODE:1:Active:2:Inactive /]" /]

This sorts the first column ascending (by default), then the name column descending, then
sort on the third column having first converted any values of “1” to “Active” and any values of
“2” to Inactive.

In addition to the direction parameter that can be optionally specified for each sort key, the
SORT function also support a global direction parameter to specify the sort direction
(ascending or descending) to be used for all sort keys that don't have a direction specified.

Page 147
 WebReports User Guide

DESC or ASC should be used (some older syntaxes are still supported). If this parameter is
not specified, the direction defaults to ASC (ascending). E.g.

[LL_WEBREPORT_SORT "1" "2" DESC /]

In this example, the data set would be sorted in descending order of column 1 followed by
descending order of column 2.

15.2 Advanced Notes

This tag is always placed within a row section (i.e. after the [LL_WEBREPORT_STARTROW
/] and before [LL_WEBREPORT_ENDROW /]). It is possible to have multiple SORT tags in a
row section but this is normally unnecessary since each SORT tag supports multiple keys.

When using a WebReports tag and sub-tags as the sort parameter, any results which are
numeric or in a valid date form as defined in the Livelink system, will be sorted as integer and
date types respectively.

When using the SORT tag, it is possible to use parameter or constant tags as part of the tag
syntax. This is useful to allow content to be sorted according to a value that has been passed
as a parameter or a constant. E.g.

[LL_WEBREPORT_SORT "[LL_REPTAG=DATAID
NODEINFO:[LL_REPTAG_&nodefield /] /]":[LL_REPTAG_&direction /] /]

In the example above, a URL parameter could be passed to specify which NODEINFO:
should be used. A direction could also be passed in this example. Note that for the
&nodefield parameter the tag would not work correctly if no value had been passed as
nodefield. The Parameter Default feature should be used to provide a default parameter in
situations like this.

15.3 Pre-defined Sort Parameters

This feature allows complex sort keys to be associated with simple references that can be
passed in the URL. This feature is particularly useful when setting up reports that are sorting
using WebReports tags and sub-tags. When the user selects a column for sorting, it can be
difficult to pass the necessary tag syntax in the URL in order for the SORT tag to execute. To
solve this problem, this feature provides the ability to specify:

• The name of one or more parameters that should be checked in the URL
• A series of reference words and their associated tag syntax

When this is setup correctly, each specified parameter is checked to see if one of the
predefined reference words has been found. If a specified reference word is found in the URL
parm then the corresponding syntax for this word is inserted into the SORT tag.

In order to provide this functionality, two "directives" are provided that can be included within
the SORT tag. The concept of a "directive" exists in other content control tags such as the
INSERTJSON tag. It refers to a syntax command preceded by an @ symbol. Each directive
may have one or more additional pieces of information. The two directives supported by
SORT are @PARMNAMES AND @PREDEFKEY. These directives are explained in depth
below.

Page 148
 WebReports User Guide

Directive Description
@PARMNAMES One or more of these directives can optionally be
SORTCOL:<sortcolname> specified. If none of these directives are specified (and a
DIRCOL:<directioncolname> predefined key - as below - is specified) then it is
assumed that the parameters &sort and &direction will be
used to pass any sort or directional references. For each
@PARMNAME directive that is supplied, an alternative
URL parameter name can be specified for either the sort
column or the sort direction. The ability to specify more
than one @PARMNAME directive allows multiple sort
columns to be specified. These parameters are used in
the order of the @PARMNAME directives specified in the
SORT tag. For example, given the following set of
directives:

@PARMNAMES SORTCOL:sortcol1 DIRCOL:coldir1

@PARMNAMES SORTCOL:sortcol2 DIRCOL:coldir2

@PARMNAMES SORTCOL:sortcol3 DIRCOL:coldir3

If the URL
contained:&sortcol3=parentid&sortcol1=Name&sortcol2=
dataid

The SORT would execute based on: Name, DataID and

then ParentID - in that sequence.

Note that normally the value of each of these parameters

will specify one of the predefined keys as setup by the
PREDEFKEY directive below.
@PREDEFKEY This directive is used to setup a simple identifier that can
be used to reference a complex tag/sub-tag type sort
REF:<reference key> key. This allows the client application to specify a simple
key as a sort parameter rather than a large chunk of
PARM:<tag/sub-tag syntax> WebReports tag and sub-tag information. For example, if
a particular column contains the following syntax:
[LL_REPTAG=DATAID CAT:somecat:attr1:DISPLAY /]
and we want to be able to sort using this data, we could
setup a key as follows:

@PREDEFKEY REF:col3
PARM:"[LL_REPTAG=DATAID
CAT:somecat:attr1:DISPLAY /]"

With this definition in place, &sort=col3 in the URL (or

POST request) would tell the SORT tag to use
[LL_REPTAG=DATAID CAT:somecat:attr1:DISPLAY /]
as a SORT key. Several such predefined keys can be
created, one for each and every column that could be
sorted. Usually this feature is only used where the sort
key is complex, such as in the example above.

Page 149
 WebReports User Guide

16 Using Variables

16.1 Overview
Various components in WebReports support the concept of variables. Variables provide the
ability to store and/or accumulate results from other tags for output into the reportview.
Variables are supported by the following tag and sub-tags:

• [LL_REPTAG_%<varname> /] - tag returns whatever is stored in a variable represented

by "varname". varname is a set of valid characters (e.g. no spaces or special characters).
This variable name should match with a variable previously created by one of the sub-
tags which support variable setting.

• SETVAR – sub-tag which allows any tag result to be stored in a named variable.

• ADDVAR – sub-tag which allows any numeric tag result to be added to the numeric value
in a named variable.

• CONCATVAR- sub-tag which allows any text/string based result to be concatenated to

the text in a named variable.

• CURRENTVAL – sub-tag that returns the current value of a variable and/or the result of a
variable action sub-tag.

A more detailed description of these sub-tags and the variable tag are described in the syntax
guide. This section describes some guidelines and notes for the usage of this feature.

16.2 Advanced Notes

As Variables are set by various different types of WebReport tags, the order in which they are
set is dependent on the order in which these tags are processed. WebReports processes
each tag type in the following order:

• All passed parameter tag values from top to bottom of the reportview

• All column name tag values from top to bottom of the reportview

• All static tag values from top to bottom of the reportview (e.g. any tags which return static
Livelink environment information which is not returned from the data source)

• All report tag values (columns of data from the data source) from top to bottom of the row
section from first row to last row (according to the sort order)

• All function and variable tags from top to bottom of the reportview (this is where the
current variable values will be resolved)

(See chapter 20 for more information about processing order.)

In general, for any concatenation or addition operations with variables where the order is
important, try to use the same type of tag. For example, if multiple function results (such as
@SUM) are being added together, this is supported because all function results are being
processed in sequential order as they appear in the reportview. If the requirement was to
concatenate a combination of parameters, constants, and math results then this would not be

Page 150
 WebReports User Guide

processed in the order expected by the report designer. Currently to work around this
problem, a variable for each type of tag would have to be created and set with the results for
all tags of a specific type. Each of these variables could then be concatenated to provide a
cumulative result as shown in the next bullet:

• When variables are being resolved they can also set variables to be used in subsequent
variables by using the setting sub-tags (e.g. SETVAR)
e.g. given the following sequence of tags:
[LL_REPTAG_%subtotal /] ,
[LL_REPTAG_@SUM ADDVAR:subtotal SHOW /] ,
[LL_REPTAG_@subtotal ADDVAR:total /]
[LL_REPTAG_%total ROUND:2 /]
If the variable called subtotal started with a value of 10, a variable called total started with
a value of 20 and @SUM returned a value of 100.12345, the output of these tags would
be:
10 , 110.12345 , 130.12
Note that when the sub-tags SETVAR, ADDVAR and CONCATVAR are used they will
normally not return the result to the output unless the SHOW sub-tag is also used as in:
[LL_REPTAG_@SUM ADDVAR:subtotal SHOW /].

• Variables can be used within row sections to accumulate numbers or strings from multiple
rows. This is most useful for concatenating string values into a single string which can be
used anywhere that the variable tag can be used (including export fields such as the E-
Mail To: list).
Example 1:
[LL_REPTAG=USERID USERINFO:EMAIL CONCATVAR:tolist:"," /]
If this tag was used in a row section (between the STARTROW AND ENDROW tags), it
would build a string of e-mail addresses with a comma separating each e-mail address.
Example 2:
[LL_REPTAG=cost ADDVAR:subtotal /]
If this tag was used in a row section (between the STARTROW AND ENDROW tags), it
would add the value of the column "cost" for each row to the variable called subtotal.

• Variables can be used as operands for [LL_WEBREPORT_INCLUDEIF or

[LL_WEBREPORT_EXITIF conditional tags but cannot be used in the
[LL_WEBREPORT_IF tag. It is also important to note that variables which are set within
[LL_WEBREPORT_IF/ENDIF sections will still be set even if the IF clause is ultimately
evaluated to FALSE. This is due to the order in which tags are processed in the
reportview.

Page 151
 WebReports User Guide

17 Using a Search Query as a Data Source

17.1 Overview
A WebReport can use a saved search query as a data source. Saved queries are most
commonly created by saving an advanced search, thus creating a new object in Livelink. The
WebReport data source browser will recognize saved data queries as a selectable object.

The search queries can either use standard Full Text specifications (e.g. All Words) or
complex Livelink Query Language queries.

When a data source is selected, the corresponding search specification will be run whenever
the WebReport is run.

17.2 Column Names Returned

The columns returned by a saved search are described in the chart below:

Column Name Description

DataID The DataID for the object as stored in the Livelink

DTREE database table.

ParentID The ID of the object’s parent container as stored in the

Livelink DTREE database table.

Name The name of the object as stored in the Livelink

DTREE database table.

CreatedBy The date of the object’s creation as stored in the

Livelink DTREE database table.

ModifyDate The date the object was last modified as stored in the
Livelink DTREE database table.

Record A full record of all the fields for the object that is stored
in the Livelink DTREE database table. These fields
are stored in a special (RECORD) structure which can
be accessed using the RECORD sub-tag. E.g.:

[LL_REPTAG=RECORD RECORD:SUBTYPE /]

[Optional Fields] In addition to the fixed fields above, any other system
attributes (regions) which have been enabled for
search display can also be referenced using a
WebReports data tag. As these fields are system
dependent it is necessary to ask the administrator to
provide a list of these attributes/regions.

Page 152
 WebReports User Guide

17.3 Using Variable Parameters in Search Queries

WebReports support the use of user defined parameters in the Full Text section of the search
query. This is designed to work in a similar way to the parameters used in LiveReports.
Parameters are specified in the format: %n where n is a number from 1 to 99. These
parameters can be added to multiple Full Text boxes. When the WebReport is run,
parameters are passed by adding &inputlabeln to the URL.

For example, if the Full Text box contained: test %1, the parameter &inputlabel1=cat in the
URL would result in the search query looking for the words “test” and “cat”.

Page 153
 WebReports User Guide

18 Using Category as a Data Source

18.1 Basic Overview

A WebReport can use a Livelink Category as a data source. A user may select one or many
Livelink Categories, then select one or many Attributes within each Category. The WebReport
will process a SQL query against the Livelink database DTREE and LLATTRDATA tables and
return one record for each Livelink item with the selected Categories applied.

Each record returned from the query will contain the following values:

• DataID - The DataID for the object as stored in the Livelink DTREE database table.
• ParentID - The ParentID for the object as stored in the Livelink DTREE database
table.
• SubType - The Subtype for the object as stored in the Livelink DTREE database
table.
• Name - The Name for the object as stored in the Livelink DTREE database table
• Attribute Values - The current value for each selected Attribute as stored in the
Livelink LLAttrData table. The column header will be the attribute system name (i.e.
the original attribute name with spaces replaced by underscores).

18.2 Features of Category as a Data Source

When the Livelink Category data source is selected, the following features are available:

• Browse Livelink Button - Use the Browse Livelink button to select a Livelink Category.
After a Category has been selected, the page will refresh with a display of all Attributes
within the Category.

• Select Attributes - Select the checkbox next to a specific Attribute to include the attribute
within the query results. When an attribute has been selected, the Parameter Menu will
be displayed for that attribute. When an attribute is de-selected, the Parameter Menu will
be removed for that attribute.

• Check All/Uncheck All Buttons - Use the Check All and Uncheck All buttons to check or
uncheck all checkboxes for the specified category.

• Delete Category - Use the Delete Category icon to delete a specified category.

• Add Category - Use the Add Category icon to add another category. The Add
Category icon will only be displayed at the end of the current listing of categories. The
Livelink Administrator may configure the number of categories that may be included in the
Data Source list and the Add Category icon will not be displayed when the limit has been
reached.

• Category And/Or Join Operator - For each new Category, select either And/Or radio
button to specify whether the categories will be joined in the query with an inner join (And)
or a left outer join (Or).

Page 154
 WebReports User Guide

18.3 Using Parameters with a Category as a Data Source

The WebReport designer may define Category/Attributes as WebReport parameters and
specify a query operator from the WebReport Data Source page.

When a Category/Attribute has been checked on the Data Source page, a new Add
Parameter Menu icon will be displayed, from which a query operator may be selected.
When a query operator has been selected from the Parameter Menu, the attribute is now
available via the "Parameter Extraction" process on the Parameters tab. When an attribute
has a selected parameter query operator, the Edit Parameter Menu icon will be
displayed and a checkmark will be displayed next to the selected query operator. If an
attribute is currently used as a parameter and the query operator is changed from the Data
Source page, the query will now be based on the newly selected query operator. The
WebReport designer will be prompted with the option to update the display text on the
Parameter page; regardless of the display text on the Parameter page, the SQL Query
processed will always use the query operator as selected on the Parameter Menu on the Data
Source page.

To clear a selected query operator from the parameter menu, either:

• Select another query operator from the same menu to set a new query operator, or

• Select the existing query operator to reset the query operator to undefined.

18.4 Category Data Source Actions

Three additional actions are available to the WebReport designer when Livelink Category is
the selected data source.

• View SQL - Select the View SQL button to view the generated SQL for currently selected
categories, attributes and defined parameters.

1. Only a WebReport designer with Modify privileges may view the SQL.

• Filter Results by User Permissions - When this checkbox is checked, the query results
will be limited based on the permissions of the user running the WebReport. The user
must have SEE permission level to view a specific item.

NOTES:

1. The default value for this feature is CHECKED; only a user with Livelink
Administrator privileges may modify this feature.

2. The permissions filter is applied to query results as a separate process after the
database query has completed processing.

• Maximum Number of Results - An integer value indicating the maximum number of

results to be returned by the database query. Note that the number of items displayed
may be less than the defined Maximum Number of Results when the permissions filter is
applied after the query return.
The WebReport Designer may select a value no greater than the value defined by the
Livelink Administrator.

Page 155
 WebReports User Guide

19 Requests as Data Sources

19.1 Basic Overview

This feature allows a WebReport to use information in the GET or POST request (used to
invoke the WebReport) as a data source. It allows data to be specified in either separated
value or HTML form (or any other supported type of parsing) that would then be used by the
WebReport. This allows the possibility of pushing data into a WebReport to then be formatted
and delivered to destinations etc. The data is passed using a pre-defined parameter name
and will normally use the defaults for web documents in order to parse the data. Several other
pre-defined parameters have been made available in order to control the parsing options that
would normally be set in the data source interface. Currently this feature has no visibility on
the source tab as it is purely driven by the existence of these special parameters.

19.2 Supported Parameters

Mandatory

• DSrequestData - This is the parameter that contains the data that will be used by the
datasource. For any of the optional parameters that have not been specified, defaults
are used. The data in this parameter would normally be formatted in a way that can
be interpreted by the WebReport, e.g. Comma Separated Values (CSV) or HTML
table data. If no optional parameters have been specified, the data is expected to be
formatted as CSV. The optional parameters can be used to specify any differences in
the parsing format. A common variation would be to use a symbol such as | as the
row separation character.

Optional

• DSFILETYPE - Acceptable values are: separatedvalue (default), htmltable and

oscript. This parameter specifies how the data has been formatted and therefore how
it should be parsed. In the case of oscript the data source can be a LIST of ASSOC or
a RecArray. The tags ENTEPRISE, PERSONAL, TOOLS, TABS,
LLURL:FUNCTIONMENU:RAW, LLURL:ADDITEM:ITEMMENU:RAW and CAT:RAW
provide data structures in oscript format which can be used in this parameter.
• DSCONTENTTYPE - Only appropriate for a filetype of separatedvalue. Acceptable
values are: somequotes (default), allquotes, noquotes. These settings refer to
whether or not some of the data cells might be quoted to hide characters that might
interfere with parsing. If none of the cells are quoted, a setting of noquotes provides
faster processing.
• DSSTRICTSYNTAX - Set to either true (default) or false. True specifies that the data
has been strictly formed with no unexpected spaces or other ambiguous white space.
• DSCOLUMNSEP - Specifies a character or characters that are used to delimit
(separate) columns of data. Defaults to , (comma).
• DSROWSEP - Specifies a character or characters that are used to delimit (separate)
rows of data. Defaults to a carriage return followed by a line feed.
• DSQUOTECHAR - Specifies which character or characters have been used to quote
cells (if any). Defaults to "
• DSESCQUOTECHARS - Specifies which character or characters are used to
escape any quotes in the cell data (if any). Defaults to ""
• DSHEADINGSINC - Specifies true or false depending on whether the first row of
data includes heading names for each column. Defaults to true. If set to false
columns are automatically named as column1, column2, etc.

Page 156
 WebReports User Guide

19.3 Examples of Requests as Data Sources

Example 1 - Calling as a Sub-WebReport:

The following tags will call a Sub-WebReport and pass the DSrequestData as parameters to
the Sub-WebReport:

• [LL_WEBREPORT_SUBWEBREPORT NODEID:[LL_REPTAG_$SWR /]
PARM:DSREQUESTDATA:"444,555,666|777,888,999" PARM:DSCOLUMNSEP:","
PARM:DSROWSEP:"|" /]

Example 2 - Calling from a URL:

The DSrequestData parameters can also be set in a URL:

• ?func=ll&objId=48243&objAction=RunReport&DSREQUESTDATA=444,555,666|777,
888,999&DSCOLUMNSEP=,&DSROWSEP=|

Example 3 - Using DSFILETYPE of value OSCRIPT:

The output of tags such as CAT:RAW can be used similar to example 2 but with a form post:

<FORM NAME="getFuncs" METHOD="POST" ACTION="[LL_REPTAG_URLPREFIX /]">

<input type=hidden name="DSFILETYPE" value="oscript">

<input type=hidden name="DSrequestData" value="[LL_REPTAG_"23099" CAT:RAW /]">

[LL_REPTAG_$CLICK LLURL:REPORT URLTOPOST /]

<input type=submit value=submit>

</FORM>

A form post is a good idea where the results from the RAW tag can be large as Internet
Explorer is unable to cope with very long parameter values. Form posts on the other hand are
no problem.

Page 157
 WebReports User Guide

20 How Reportviews Are Processed

20.1 Overview
For most WebReport development, it is not necessary to understand the details of how
reportviews are processed; however, for some specialized and advanced situations this
information can be useful. For example, in order to determine what tags can be used as
parameters for other tags, there are some useful guidelines which will help to make these
scenarios clearer.

In general, sub-tags can be used within data tags, and data tags can be used within content
control tags; however, there are also cases where you can use various types of data tags
within other data tags. The success of this type of nesting is dependent on the order in which
each type of tag is processed. E.g.:

[LL_WEBREPORT_SORT "[LL_REPTAG=DATAID NODEINFO:[LL_REPTAG_&nodefield

/] /]" [LL_REPTAG_&direction /] /]

In the example above, a parameter tag (nodefield) is substituted as a parameter for the
NODEINFO sub-tag and the parameter tag (direction) is inserted as the direction parameter
for [LL_WEBREPORT_SORT /].

Officially only parameters, constants and column name tags are supported for insertion in
data tags but other combinations should be possible subject to the processing order shown
below. These data tags can be substituted into the following components in the reportview:

• Parameters of content control tags (e.g. the sort direction parameter of a sort tag).
"Content control tags" refers to any tag that has [LL_WEBREPORT_ as a prefix.

• Parameters of sub-tags

20.2 Advanced Notes

The following list describes the order in which the different tag types are processed.
Understanding this processing order is useful to determine how tags may be used with each
other. For example, passed parameters are processed before any sort tags are processed,
therefore any information passed in the parameters can be used as part of the sort tag.

• All passed parameter tag values are inserted from top to bottom of the reportview.

• All constant tag values are inserted from top to bottom of the reportview.

• All column name tag values are inserted from top to bottom of the reportview.

• All function tags are interpreted (and marked for later insertion) from top to bottom of the
reportview. @DATA tags are inserted at this point.

• All static tag values are inserted from top to bottom of the reportview (e.g. any tags which
return static Livelink environment information which is not returned from the data source).

• The reportview is divided into three sections. All row data tags are interpreted (for later
data insertion) in the row section.

Page 158
 WebReports User Guide

• All variables are prepared and marked for later resolution from top to bottom of the
reportview.

• All Sort tags are processed and data manipulated. Sorts are performed in order of the sort
tag appearance from top to bottom of the reportview.

• All report tag values (columns of data from the data source) are inserted from top to
bottom of the row section from first row to last row (according to the sort order).

• All functions and variables are inserted from top to bottom of the reportview (this is where
the current variable values will be resolved).

• All if/endif conditional tags are resolved from top to bottom of the reportview.

• All sub-WebReports are invoked (and the resulting output inserted) from top to bottom of
the reportview.

The way in which tags are created and specified in the report view is validated each time that
a new version is added to the WebReport. This validation is provided to aid in finding any
syntax errors that may exist in the reportview; however, sometimes this validation may
interfere with more complicated tag structures. Advanced users may want to disable the
validation to allow complex scenarios to be used; however, this should only be done after
basic testing (with validation on) and preferably on a test system to avoid any possible run
time errors that could be introduced.
Validation can be turned off using this tag:

[LL_WEBREPORT_DEBUGON /]

Page 159
 WebReports User Guide

21 JavaScript Arrays

21.1 Overview
The content control tag [LL_WEBREPORT_INSERTJSARRAY /] provides the ability to
automatically insert a JavaScript array with all of the report data populated. This feature is
useful for applications where the report data is to be manipulated using JavaScript in the
client browser.

21.2 Generating a JavaScript Array Automatically

The data in the report is converted to the array according to the following criteria:

• A JavaScript array is created by default with the name repData. If an alternative array
name is provided using the ARRAYNAME: parameter, then the array is created using the
specified name.

• The array is indexed numerically from 0 (zero) through to an index which is one less than
the length of the array.

• The columns are created as a second dimension of the row array (e.g. an array of
arrays). Columns are indexed numerically from 0 (zero) to an index which is one less than
the total number of columns.

• A series of constants are also created which can be used to reference the column indices.
Each constant is named according to the column which it references.

• If the inserted JavaScript needs to be enclosed in opening and closing SCRIPT tags then
the SCRIPT parameter should be included.

• For data where several columns are repeated and only one column is consistently unique,
the MULTIVALUE: parameter can be used. This parameter will create a third array
dimension for the unique column. See below.

21.3 Examples
Example 1:

Id FirstName LastName

1111 James Bond

2222 Johnny English

3333 Frank Smith

Given a data source returning data according to the table above, the tag
[LL_WEBREPORT_INSERTJSARRAY /] would generate the following:

Page 160
 WebReports User Guide

<SCRIPT LANGUAGE="Javascript">
var repData= new Array();
var ID = 0;
var FIRSTNAME = 1;
var LASTNAME = 2;
repData[0] = new Array("1111","James","Bond");
repData[1] = new Array("2222","Johnny","English");
repData[2] = new Array("3333","Frank","Smith");
</SCRIPT>

Example 2:

Id FirstName LastName ChildName

1111 James Bond Matthew

1111 James Bond Jonathan

1111 James Bond Emily

2222 Johnny English George

2222 Johnny English Mavis

3333 Frank Smith N/A

Given a data source returning data according to the table above, the tag
[LL_WEBREPORT_INSERTJSARRAY MULTIVALUE:CHILDNAME /] would generate the
following:

<SCRIPT LANGUAGE="Javascript">
var repData= new Array();
var ID = 0;
var FIRSTNAME = 1;
var LASTNAME = 2;
repData[0] = new Array("1111","James","Bond",new Array("Matthew",
"Jonathan", "Emily"));
repData[1] = new Array("2222","Johnny","English",new Array("George",
"Mavis"));
repData[2] = new Array("3333","Frank","Smith",new Array("N/A"));
</SCRIPT>

In this example, the MULTIVALUE option makes it possible to compensate for the redundancy
of the first three columns. Six possible rows have been reduced to three rows by creating
another level of JavaScript array.

Page 161
 WebReports User Guide

22 WR Trigger

22.1 Overview
The WR Trigger feature allows WebReports to be initiated by specific events in Livelink. For
node types that have been enabled with the feature, which is off by default and can be
enabled per node type in the administration pages under WR Trigger Administration, the
WebReport developer can choose to initiate a WebReport for the following Livelink events:

• Add Version

• Category Update

• Create

• Delete

• Move

• Update

22.2 General Usage

The feature is accessed via a new WR Trigger option in the properties section of the function
menu, which brings up a new tab. The menu and subsequent tab can only be accessed for
subtypes that have the WR Trigger feature enabled. Triggers can be set on individual objects
or they can be set on containers and cascaded down a hierarchy, which provides a
convenient way to set triggers on a large volume of items.

When an item is "Deleted" using the function menu one of two things can happen. The item
might be truly deleted and so completely removed from the database, or the item might be
moved to the Recycle Bin or Undelete Volume. The behavior will depend on how specific
subtypes (Documents vs. Folders etc.) are configured with these modules. The Delete trigger
only fires on a true database delete - i.e. when items are destroyed. If it is required to trigger a
WebReport based on a "function menu delete" that results in the item being moved to the
Recycle Bin or Undelete Volume, the Move trigger event must be used. Logic can then be
used in the WebReport (simply use NODEINFO:PARENTID /OWNERID) to determine
whether the item was moved to one of these locations or elsewhere in Livelink.

When a root node (a container with other items in it) is copied, moved or deleted, the trigger
occurs on the root node only. No WebReport will be initiated for individual sub items. If a
WebReport needs to be initiated for each specific item, it can be achieved using a query that
takes the node that initiated the trigger to find all the children, then use a subWebReport to
implement the specific behavior - e.g. trigger a workflow.

All triggers are initiated after the event has occurred with the exception of Delete. For
example, if using [LL_REPTAG_TRIGGERID NODEINFO:PARENTID /] in a WebReport that
has been initiated by a Move trigger event, the objectid of the new parent will be returned (see
[LL_REPTAG_TRIGGERORIGPARENTID /] for accessing the original). With the delete
trigger, the event is fired just before the delete so that we have the maximum meta data
available. Once a node is truly deleted, it no longer exists and so has no valid meta data.

Page 162
 WebReports User Guide

When a document is added to Livelink, both the Create trigger and the Add Version trigger are
fired. This is because Livelink sees this as two actions. First a node creation occurs and once
the node is created a new version (in this case version 1) is added to that node. If a folder
were added, only the Create trigger would fire.

The WR Trigger feature now supports triggering based on User or Group events. This can be
configured in the administration pages under User/Group WR Trigger Administration. The
WebReport developer can choose to initiate a WebReport based on the following User/Group
events:

• Add User to Group

• Create User/Group

• Delete User/Group

• Update User/Group

• User Login

When the Global checkbox is selected, anytime one of the selected trigger events is triggered
within Livelink (regardless of who executed it), the specified WebReport is executed.
Otherwise if a User or Group is specified (Global checkbox is off) the WebReport will execute
if the trigger event happens within the group or to the user. For example, if creation, deletion,
addition, etc. happen in the group (not explicitly on the group itself) then the WebReport will
initiate. For a user, the trigger event needs to happen on the user. This means that not all
trigger events are relevant to users and so they are ignored. In the screen-shot below, the
Admin user would need to be deleted for the 'Delete User/Group' trigger event to fire.

In this example a WebReport is initiated if a user is added to 'TestGroup1', a new user is

created with 'TestGroup1' as its Department, or if 'TestGroup1' is deleted. In addition if the
'Admin' user is deleted from Livelink, the WebReport will execute.

22.3 WR Trigger tags

WR Trigger supports the following feature specific tags which are detailed in the tag guide:

• [LL_REPTAG_TRIGGER /]

• [LL_REPTAG_TRIGGERID /]

• [LL_REPTAG_TRIGGERNEWID /]

22.4 Example
Initiate a workflow and attach a document to it when a new item is created.

Page 163
 WebReports User Guide

• Set the WebReport destination to the workflow you wish to initiate (Properties ->
Destination).

• Open the WR Trigger tab (Properties -> WR Trigger) on a folder above where the
item will be created, select the WebReport to be executed and select the Create
event as the trigger.

• In the WebReport set the item that initiates the event to be attached to the workflow.
Do this by editing the reportview and using [LL_REPTAG_TRIGGERID
SETWFATTACH:COPY:INHERITATTRS:MERGED /]. TRIGGERID is the id of the
object that initiated the event and SETWFATTACH:COPY:INHERITATTRS:MERGED
copies this node to the attachments folder merging the categories of the node with
those of the attachments folder.

Note: Rather than initiating a workflow, the WebReports destination tab could be set to send
an email. To attach the item that fired the event to the email destination use
[LL_REPTAG_TRIGGERID /]. It's worth noting that SETWFATTACH and SETEMAILATTACH
can be used multiple times to attach several items to the destination.

Page 164
 WebReports User Guide

23 WR Services

23.1 Overview
The WR services feature provides a way of retrieving information from the WebReports
engine. One of the most useful examples of this is a service that allows tags and sub-tags to
be specified in a request that returns the resulting data without the need to create a
WebReport or ActiveView object. This capability provides a way to leverage the vast number
of useful functions that are available through the WebReport engine's sub-tags and static
tags. A single call to the WR service feature can be used to bring back the result of a tag (or
literal data) processed through a virtually unlimited list of sub-tags. For example, a service call
could be made to return category or attribute information using the CAT sub-tag.
The result of a service call can simply be returned as text directly to the client that invoked the
feature, or it is possible to specify formats just as XML or JSON. If XML or JSON are used to
return data from a service call, the content is accompanied by an error field that allows any
client application to programmatically check for errors. This feature is particularly suited to
being invoked via AJAX calls, especially if the JSON response type is used. The ActiveView
or WebReports software includes a pre-defined JavaScript function that provides an easy way
to invoke these services using AJAX.

This is an example of invoking a tag/sub-tag lookup service using a simple GET type URL.

<prefix>?func=webreports.runservice&servicetype=gettagdata&tagdata=<TAGDATA>&
statictag=<STATIC TAG name>&subtags=<SUBTAGLIST>

All service requests include the parameter: ?func=webreports.runservice as a starting

point, followed by the &servicetype= parameter that is used to select one of the supported
services. Depending on which service is selected, there may be additional parameters
required as specified in the table below. These parameters can be used in GET or POST
requests using AJAX or traditional form fields to submit the request. Note that ?func= is
replaced with &func= for POST type requests when using AJAX.

Note:

In some cases it is necessary to include a percent sign (%) in the request being sent to WR
Services. To avoid this percent sign being interpreted as URL escaping, it is necessary to use
a URL code to specify a percent sign. Specifically, wherever % is required, %25 must be used
as this code will be resolved to a percent sign.

Page 165
 WebReports User Guide

23.2 Available Services

gettagdata Definitions

&func=webreports.runservice

&servicetype= Description/Parameters

This service allows the execution of static tags and or sub-tags from the
WebReports engine to be invoked directly. This capability provides a way to
leverage the vast number of useful functions that are available through the
engine, particularly with the ability to access the 60+ sub-tags and several static
Gettagdata
tags. Many of the sub-tags provide the ability to access some useful Livelink
functions such as looking up categories and attributes, testing group
membership and even performing Livelink actions (subject to normal
permissions controls). See next table (gettagdata Definitions).

This service returns all appropriate static values from the WebReports engine in
a data structure according to the responsetype parameter; however, only the
Getstatictags json responsetype is currently supported. Static tags are all of the tags in the
WebReports tag guide that come under the heading of "data tags" and which
have fixed names such as: [LL_REPTAG_DATETIME /].

This service provides a simple list of all the static tags that are available for
Liststatictags usage in the gettagdata and getstatictags services. It is primarily used for the
convenience of developers.

Page 166
 WebReports User Guide

RESPONSETYPE Definitions

Parameter Name Mandatory Description

TAGDATA Yes (if no STATIC This parameter can be used to specify data to be
tag is specified or operated on by any specified sub-tags. If a statictag has
STATICTAG returns also been specified, the tagdata will be ignored unless
an empty string) the static tag returns a blank string. This allows the
tagdata to be used as a default value for situations
where the static tag doesn't return a useful value.
This parameter can be used to specify one of a
STATICTAG Yes (if TAGDATA is selection of WebReports static tags that can be invoked.
not specified) If the specified tag returns a blank string, then the value
of tagdata (if any) will be used instead, otherwise, the
output from the statictag is used by any sub-tags that
have been specified. The static tag parameter does not
require the full WebReports syntax; only the static tag
name is used. For example, the [LL_REPTAG_USERID
/] tag would be invoked using:
&statictag=USERID
Note that WebReport services only supports a small
subset of the available static tags. In general, any static
tags that are used to return information about an
executing WebReport, will not be valid as there is no
WebReports object associated with a service call. To
find out which static tags are available, you can use the
special liststatictags option as follows:
<prefix>?func=webreports.runservice&servicetype=
liststatictags
Specifies a list of sub-tags and their fields, just as they
SUBTAGS Yes would be used in a WebReports tag syntax. E.g.
&subtags=NODEINFO:NAME UPPER

As with WebReports usage, these sub-tags are

processed from left to right with the output from the
static tag (or the tag data) being passed to the leftmost
sub-tag.

RESPONSETYPE No Allows different formats to be specified for the data to be

(default is "string") returned by a service request. Valid values are string,
json or xml. Assuming that a service has executed
successfully (no errors) and the service has returned the
string: "This is a test", the table below shows what each
of the different formats would return.

Format Example MimeType Text Escaping

Page 167
 WebReports User Guide

string This is a test text/html No unescaping required

xml <?xml version="1.0" text/xml Content is HTML escaped. E.g. & = & etc.
encoding="ISO-8859-1" ?>
<response>
<error>false</error>
<content>This is a
test</content>
</response>

json {"error":false,"content":"This text/json If the content is text based (i.e. non-

is a test"} numeric and enclosed in quotes)
conventional string escaping is used. E.g.
back slashes (\) are used before any
special characters. See the JSON standard
(RFC 4627) for more details on string/text
escaping.

23.3 Using the Predefined Functions

The ajax.js file packaged with WebReports includes a function designed to aid in the use of
WebReport services in conjunction with AJAX technology. The ajax.js file is accessed using a
SCRIPT include like this:

<SCRIPT SRC="/<support dir>/webreports/library/ajax.js"></SCRIPT>

If this file is being included into a WebReport or ActiveView the LIBPATH tag can be used like
this:

<SCRIPT SRC="[LL_REPTAG_LIBPATH /]ajax.js"></SCRIPT>

The following table describes the available function and its parameters.

executeWRService( serviceType, responseTarget, parmList, responseType, getPost)

servicetype Mandatory This parameter expects a string with one of the supported servicetypes
for running a WR service (as specified in the table above).

responseTarget Mandatory This parameter expects either a JavaScript function that has been
created by the developer, or a string representing the ID of an HTML
object where the returned data should be inserted. If a JavaScript
function is created (and passed to this parameter) it should be written
to accept the http_request as a parameter. For example:

Page 168
 WebReports User Guide

function myHandlerFunction(httpRequest) {
alert('the response was: '+ httpRequest.responseText);
}
executeWRService( 'gettagdata', myHandlerFunction,
"&statictag=userid &subtags=USERINFO:GROUPID", 'json')

parmList Optional This parameter is used to specify a string containing additional

parameters to be added to the URL as required by each servicetype.
For example, the gettagdata service type uses a combination of
&tagdata, &statictag or &subtags as per the syntax in the table above.
The parms should be specified in the &name=value type format. E.g.
"&tagdata=12345&subtags=CAT:myCategory:attr1:display"

responseType Optional This parameter expects a string with one of the supported response
types for WR services (string,json,xml - as specified in the table
above). It not specified, it defaults to json.

getPost Optional This parameter can be used to specify whether the AJAX request
should be GET or POST. If omitted, the POST method is used.

23.4 Examples
Example 1

This example shows two different ways to call the gettagdata service using the predefined
function: executeWRService. In one instance, we have written a special function called
handleServiceJSON which is designed to "eval" the JSON data (convert the JSON data to
Javascript objects) and use the resulting JavaScript structures to display the result of the
request. In this request we are using &tagdata= with a data ID and then using the
NODEINFO:NAME sub-tag variation to lookup the name of an item. Note that as we
requested a responseType of 'json', the resulting data structure includes a field called "error"
which indicates whether we have valid data or not. In the handleServiceJSON function, we
use this field to determine whether to alert an error or to display the content. In the second
instance (the get URL button) we simply pass the name of an HTML object on the page.
When the request returns from Livelink, it automatically inserts the resulting text into the
specified HTML component. Because we simply want text dumped into the page (and we
don't plan on analyzing the response for errors or handling it programmatically) the
reponseType of 'string' was selected in this example.

<SCRIPT SRC="[LL_REPTAG_LIBPATH /]ajax.js"></SCRIPT>

<script>

function handleServiceJSON(request) {
var rt = request.responseText;
var jsvar = eval('(' + rt + ')')
var error = jsvar.error;
var content = jsvar.content;
if (error == 'true') {
alert('error text is: ' + content);
} else {
alert('Object name is:' + content);
}

Page 169
 WebReports User Guide

function getName(did){
did = document.getElementById('dataid').value;
getNameParms = '&tagdata=' + did + '&subtags=nodeinfo:name';
executeWRService( 'gettagdata',
handleServiceJSON,getNameParms,'json');
}

function showURL(did){
did = document.getElementById('dataid').value;
getURLparms = '&tagdata=' + did + '&subtags=LLURL:OPEN';
executeWRService('gettagdata', 'displayname',
getURLparms,'string');
}
</script>

<input type=text value="[LL_REPTAG_MYID /]"

ID=dataid>&nbsp;&nbsp;URL:&nbsp;<SPAN ID=displayname></SPAN><br>
<input type=button value="Get Item Name"
onclick=getName()>&nbsp;<input type=button value="Get URL"
onclick=showURL()>

Example 2

This example shows the use of the getstatictags service. The service is invoked using the
executeWRService function (in ajax.js). Besides using the identifier 'getstatictags' to select
the correct service, a function called handleStaticTags (specifically written for this sample
application) is passed to the executeWRService function which in turn, sets up a request to
Livelink. The request is setup so that when the request returns from Livelink, the
handleStaticTags function is called. In this example, we've written code in
handleStaticTags to take the JSON structure from the request.responseText, convert it to a
JavaScript structure and then traverse this structure in order to show all the static tag values
that were returned from Livelink.

<SCRIPT SRC="[LL_REPTAG_LIBPATH /]ajax.js"></SCRIPT>

<script>

function handleStaticTags(request) {

var rt = request.responseText;
var jsvar = eval('(' + rt + ')')
var error = jsvar.error;
var content = jsvar.content; // This should be an array of
tags

if (error) {
alert('error text is: ' + content);
} else {
tempStr = '';
for (tag in content) {
tempStr += tag + ' = ' + content[tag] + '<br>';
}
document.getElementById('display').innerHTML = tempStr;

}
}

Page 170
 WebReports User Guide

function getStaticTags(){

executeWRService( 'getstatictags', handleStaticTags,'json');

}

</script>
<input type=button value="Get Static Tags" onclick=getStaticTags()>
<hr>
<DIV ID="display">

</DIV>

Page 171
 WebReports User Guide

24 Server Side Scripting

24.1 Overview
Although WebReports provides a number of tags to control what is included and excluded in a
WebReport, there remain tasks that demand the power of a fully fledged scripting language at
the server, before the report reaches a client. In WebReports version 4.0 onwards, the
optional ability to embed a section of script within a reportview was provided.

This feature offers tremendous power and flexibility for reporting or web application
developers. As with many powerful features, it follows that this capability also has potential
risks if used improperly. To reduce these to a minimum, WebReports scripting has been
carefully secured and constrained in a configurable way that allows each Livelink instance to
choose precisely which script features should be enabled and which not.

Presently the only script language supported is Oscript. Oscript has the advantage of running
natively on the Livelink platform and hence offers excellent performance. Although technically
it is not required for creating WebReports with Oscript, developers with access to the Livelink
SDK will benefit from the Livelink Builder’s debugging facilities. In practice, for anything but
relatively simple scripts, access to the Livelink Builder debugger will be essential to allow
developers to step through their code and debug it.

This user guide explains how to implement a script within a WebReport, but does not cover
how to write Oscript or provide a reference for Oscript syntax. For more information about
Oscript consult the Livelink SDK documentation such as the Livelink Builder help, or contact
Open Text for details of Livelink SDK training.

24.2 Security
There are a number of layered security measures to ensure that WebReports scripting is as
safe as possible:

1. If not required, the entire feature can be turned off globally by the Livelink
Administrator. Users may wish to check with their Administrator that the feature is
active before attempting to use it.

2. Even if the feature is on globally, it must be enabled for each individual WebReport
that uses it, every time a new reportview version is added to the WebReport. Any
user who can create a WebReport can include the tags to define and call scripts it but
the tags will remain disabled until a System Administrator reviews and enables
scripting for the report. Disabled reports will run but will ignore and not execute
scripts.

3. The functions available within Oscript are heavily restricted by default. For example
you may not access Global variables or many of the Builder built-in packages such as
CAPI, DAPI, File, etc. What is and is not available can be configured by the Livelink
Administrator.

Enabling Scripting for a WebReport

Only users with the “System Administration Rights” privilege have the ability to enable
scripting for a particular WebReport. There are three different ways of doing this:

Page 172
 WebReports User Guide

1. Add the new Reportview version. When a System Administrator adds a reportview
containing scripting it is automatically enabled.

2. Go to the Properties -> Specific tab for the WebReport and check the “Oscript
Scripting Enabled” checkbox which will appear if scripting is present in the reportview.

3. Use the WebReports administration page “Manage WebReports Scripting” to review

all WebReports that contain scripting and enable (or disabled) them by checking (un-
checking) the check box.

Clearly, users without the “System Administration Rights” privilege will find developing a
WebReport that contains scripting a tedious process since each new version of their
WebReport will need to be enabled by someone who does have that privilege. This is one
reason why it make sense to develop scripted WebReports on a non-production instance
where the developer may be granted the “System Administration Rights” privilege. See 24.3.

The only exception to this is that any user may create a WebReport from a default reportview
that contains oscript and it will be enabled automatically without the need for a System
Administrator to enable it. If the reportview for the WebReport is later edited or a new version
added, then its oscript will be disabled unless re-enabled by a System Administrator.
Because default reportviews are “pre-enabled”, it is essential that any reportviews containing
oscript that are to be made default reportviews (by placing them in the default reportview
folder – See the WebReports Installation and Administration Guide) must be tested and
approved.

Oscript Restrictions

WebReports uses a scheme of restrictions to make Oscript in the reportview more secure.
These are:

• No access to global variables via the $ symbol.

• No ability to declare Object, ObjRef or Frame variables.

• No ability to use parenthesis like this .() to evaluate the contents of a variable. For
example you cannot do this as .(s) is not permitted:

Assoc myAssoc
String s = 'item1'
myAssoc.item1 = 'first item'
echo ( myAssoc.(s) )

• All Builder Packages are restricted except those listed below.

• Some functions within certain restricted Builder Packages are permitted (see list
below).

The following Builder Packages are permitted by default. However the Livelink Administrator
can chose to add anything to or remove anything from the permitted list of Packages or
Package functions.

Permitted packages: 'Assoc', 'Bytes', 'Date', 'List', 'Math', 'Pattern', 'RecArray', 'Str', 'String',
'Boolean', 'Undefined', 'Void', 'Integer', 'Real', 'Record'

Permitted functions within otherwise restricted packages: 'Scheduler.debugbreak',

'Web.CRLF', 'Web.Escape', 'Web.Unescape', 'Web.DecodeForURL', 'Web.EncodeForURL',

Page 173
 WebReports User Guide

'Web.Format', 'Web.EscapeHTML', 'Web.EscapeXML'

24.3 Recommendations for Developing Scripted Reportviews

WebReports with server-side scripting should be developed on a non-production Livelink
instance. Preferably this instance would be running the Livelink Builder to aid in debugging
and the developer would have the “System Administration Rights” privilege. After the
WebReports have been developed and tested to ensure they are fit for use in production, they
can be moved to the production instance using XMLExport and Import (or one by one, using
download reportview etc).

Once in place on the production instance, a System Administrator should use the
WebReports admin page “Manage WebReports Scripting” to review all the reports and enable
them if they are satisfied that the reports and in particular the scripting aspects are safe. The
kinds of pitfalls to check for are:

• Possibility of infinite loops which could tie up threads on the Livelink server.

• Possibility of consuming too much memory through unrestrained data creation or

iterations.

• Lack of checks for undefined data or passed parameters (i.e. the script must check
for and handle undefined parameters).

• Presence of the “scheduler.debugbreak()” statement which is useful during

development but not desirable for production.

The first two of these represent the risks with the greatest potential to impact Livelink.

24.4 Defining and Calling a Script

Scripts are both defined and called within a single reportview. The definition of a script may
appear anywhere in the reportview and calls to a script can occur before its definition. This is
because script definitions are parsed, compiled and cached before a WebReport runs, in
most cases at the time the new reportview version is added. However, to make reportviews
easier to understand, it makes sense to locate the script definitions in the header section.

To define a script, use the following:

[LL_WEBREPORT_STARTSCRIPT NAME:myFunc /]
function String anyName(Dynamic c)
String s = 'Testing'
return s
end
[LL_WEBREPORT_ENDSCRIPT /]

When called, this simple script returns the string ‘Testing’ to the reportview. The string will be
inserted into the resulting report output where the call to the script was made. To call the
script use:

[LL_WEBREPORT_CALL NAME:myFunc /]

Page 174
 WebReports User Guide

This tag will cause the script named myFunc to be executed and any result returned by it to
be inserted into the report output in place of the tag. Scripts can be called from anywhere in
the reportview.

24.5 Passing Data to a Script

There are a number of ways to pass data to a script; by using the “Context” Assoc, by passing
explicit parameters, and by calling WebReports static data tags within the script section. The
last of these three methods will be discussed separately in section 24.6.

The Context Assoc

Data as passed to the WebReport from the data source may be accessed from within the
script. The first parameter passed to the first Oscript function declared in the script will
always be an Assoc called the “Context”. If there is a data source for the WebReport, the
Context Assoc will contain a key called “data” holding a RecArray (a two-dimensional array)
which will represent all the data passed to the WebReport by the data source.

[LL_WEBREPORT_STARTSCRIPT NAME:myFunc /]
function String anyName(Dynamic context)
String cell = ""
if isDefined (context.data) // check there is a data source
cell = context.data[1][1] // return the first cell of data
end
return cell
end
[LL_WEBREPORT_ENDSCRIPT /]

Note the check that context.data is defined. If there had been no data returned by the data
source (or no data source at all) context.data would be undefined and failing to check for it
would result in the entire WebReport failing to continue processing. The script is always
responsible for checking that the data it expects has in fact been passed.

Passing Parameters

When calling a script you may explicitly pass any number of parameters. For example the
following passes three parameters:

[LL_WEBREPORT_CALL NAME:myFunc PARM:1234:"a string with spaces":more_data

/]

Parameters containing spaces can be delimited with double or single quotes. The
parameters are passed to the first function declared in the myFunc script. They appear as an
Oscript List of values in the second parameter (after the Context Assoc). For example:

[LL_WEBREPORT_STARTSCRIPT NAME:myFunc /]
function String anyName(Dynamic context, List args)
String s
s = args[1] + "-" + args[2] + "-" + args[3]
return s
end
[LL_WEBREPORT_ENDSCRIPT /]

This would return “1234-a string with spaces-more_data” to the reportview.

Page 175
 WebReports User Guide

Example

The following example reportview illustrates how to access the data in the Context Assoc and
also how to explicitly pass a parameter to a script. This report will display all the data from a
data source regardless of how many columns that data source might return.

[LL_WEBREPORT_STARTSCRIPT NAME:doRow /]
Function String doRow (Dynamic c, List args)
Integer row, col
String s =''
row = Str.StringToInteger(args[1])
if isDefined(row)
for col=1 to length(c.data[1])
s+= Str.Format( '<TD>%1</TD>', c.data[row][col])
end
end
return s
end
[LL_WEBREPORT_ENDSCRIPT /]

[LL_WEBREPORT_STARTSCRIPT NAME:doRowHeader /]
Function String doRowHeader (Dynamic c, List args)
String field
String s =''
List fields
if isDefined(c.data) // check there is data
fields = RecArray.FieldNames(c.data)
for field in fields
s+= Str.Format( '<TD>%1</TD>', field)
end
end
return s
end
[LL_WEBREPORT_ENDSCRIPT /]

<TABLE>
<TR>
[LL_WEBREPORT_CALL NAME:doRowHeader /]
</TR>

[LL_WEBREPORT_STARTROW /]
<TR CLASS="[LL_REPTAG_ROWNUM ODDEVEN:Browserow1:Browserow2 /]"
VALIGN="CENTER" NOWRAP ALIGN="LEFT">
[LL_WEBREPORT_CALL NAME:doRow PARM:[LL_REPTAG_ROWNUM /] /]
</TR>
[LL_WEBREPORT_ENDROW /]

</TABLE>

24.6 Calling Static Data Tags

It is sometimes useful to be able to obtain the value returned by a WebReport static data tag
inside a section of Oscript. Note that static data tags do not include tags such as
[LL_REPTAG=<column> /] or [LL_REPTAG_%<var name> /].

For example, you may need to know the value of a WebReport constant or parameter.
Although you could arrange to pass these items as parameters at the time the script is called,

Page 176
 WebReports User Guide

you can also access them directly using the built-in “dot function” ._repTag which has the
following syntax:

String ._repTag( String tag )

Parameters:
tag - A string value representing the tag plus optional sub-tags
Returns:
A String value containing the final value of the specified tag and sub-tags.

Here are two examples which return the value of a WebReport constant called “report”:

String value1 = ._repTag('$report')

String value2 = ._repTag('[LL_REPTAG_$report /]')

Note that you may specify either the full tag name or a shortened version which omits the
opening [LL_RETAG_ and closing /]. Here are some further examples:

String value3 = ._repTag('&myNode NODEINFO:NAME')

String value4 = ._repTag('USERID USERINFO:MAILADDRESS')

Note that not all sub-tags are supported when used within ._repTag. Generally sub-tags that
cause some other action besides returning formatted data do not work. The following sub-
tags are not supported: ADDVAR, CONCATVAR, NEXT, PREV, SETFORM, SETVAR,
SETWFATTR, SETWFFORM.

24.7 Calling Sub-tags

It is possible to make use of sub-tags without also invoking a static data tag using the
following dot function:

String ._subTag(String data, String subtags)

Parameters:
data - A String value to be operated on by the sub-tags
subtags - A String containing the sub-tags to use on the data
Returns:
A String value containing the result of the data transformed by the sub-tags.

There follows an example:

String s = ._subTag('3','DECODE:1:Beginning:2:Middle:3:End:Other
UPPER')

In this case the string s is set to END.

Note that not all sub-tags are supported when called by ._subTag. Generally sub-tags that
cause some other action besides returning formatted data do not work. The following sub-
tags are not supported: ADDVAR, CONCATVAR, NEXT, PREV, SETFORM, SETVAR,
SETWFATTR, SETWFFORM.

24.8 Calling Sub-WebReports

A script can directly call another WebReport using the following dot function:

Page 177
 WebReports User Guide

Assoc ._subWebReport(Dynamic nodeid, [String parms], [String option])

Parameters:
nodeid - A String or Integer value specifying the nodeid of the report to run
parms - An optional String containing the parameters to pass to the sub-
WebReport. The required format is
'PARM:myParm1:myVal1 PARM:myParm2:myVal2' etc.
option - An optional String value of either “output”, “data” or “all” selecting the
required form of the results (see below); defaults to “output”.
Returns:
In all cases an Assoc is returned with a key “ok” holding a Boolean value that
is TRUE if the call was successful. If unsuccessful there is a further key “err”
containing an error String. If successful, the additional keys are as follows:

• If option = “output” or option is not specified an Assoc with a key

“output” is returned. The value for the “output” key is a String
containing the formatted output of the sub-WebReport.
• If option = “data” an Assoc with a key “data” is returned. The value
for the key “data” is a RecArray containing the original data from the
sub-WebReport’s data source.
• If option = “all” an Assoc with the both the keys “output” and “data”
are returned.

There follows an example which takes a nodeID (DataID) from the data source and uses it as
a parameter when calling a sub-WebReport. The script checks the sub-WebReport call was
successful and either outputs the result or an error message:

[LL_WEBREPORT_STARTSCRIPT NAME:callSWR /]
Function string callSWR(Dynamic c)
Assoc result
String parm = Str.Format('PARM:inputlabel1:%1', c.data[1].DataID)

result = ._subWebReport(._repTag('$report'), parm, 'output')

if result.ok
return result.output
else
return result.err
end

end
[LL_WEBREPORT_ENDSCRIPT /]

[LL_WEBREPORT_CALL NAME:callSWR /]

In this example ._repTag is used to return the value of a constant that points to the sub-
WebReport required.

24.9 Script Scope and Calling a Script From Within a Script

WebReports supports defining multiple scripts within the same reportview so long as each
script has a unique name within the reportview. A script can call another script from the same
reportview, but not a script defined in another reportview. Therefore script names do not need
to be unique across all reportviews in Livelink.

Page 178
 WebReports User Guide

Note that multiple oscript functions may also be declared within a single script block (i.e.
between [LL_WEBREPORT_STARTSCRIPT /] and [LL_WEBREPORT_ENDSCRIPT /]).
Functions within the same script block may call each other. However, only the first function
declared in any script block can be called from another script block (or from the reportview
using [LL_WEBREPORT_CALL /]). One can think of a script block as a discrete oscript
feature within the Livelink builder which behaves the same way in this respect. Readers
familiar with JavaScript should note that the rules described here are quite different from
those that apply to JavaScript.

To call another script in the reportview simply preface the name of the script block with a dot
“.”. This is illustrated in the following, somewhat contrived, example that performs an HTML
escape on every item of data in the “Name” column and concatenates them together
separated by semi colons:

[LL_WEBREPORT_STARTSCRIPT NAME:escape /]
function String escape(String input = '')
return Web.EscapeHTML(input)
end
[LL_WEBREPORT_ENDSCRIPT /]

[LL_WEBREPORT_STARTSCRIPT NAME:Main /]
function String anyName(Dynamic context)
String s
Integer i
if isDefined (context.data) // check there is a data source
for i = 1 to length (context.data)
s += .escape(context.data[i].Name) + '; '
end
end
return s
end
[LL_WEBREPORT_ENDSCRIPT /]

[LL_WEBREPORT_CALL NAME:Main /]

Page 179
 WebReports User Guide

25 WR Power View

25.1 Overview
WR Power View is an option available in form templates that allows developers of WebForms
to quickly leverage WebReports' unique ability to lookup and manipulate data from different
sources but in the context of a form.

25.2 Creating Forms

Forms developers are presented with the option to add a WR Power View to a form template
in addition to the traditional HTML view. This new form view behaves in a similar way to an
HTML view with some useful additions:

• Native support for existing form tags like [LL_FormTag_1_1_2_1 /] and [LL_FUNC /]
meaning that Power Views are backwards compatible with HTML views. To leverage
this capability, simply download the latest version of your form view and add it as a
reportview version to a new WebReport added from the WR Power View option.

• Full support for WebReports static tags, constants and parameters which can be
used together with form tags.

• Call an unlimited number of WebReports (through sub-WebReports calls) inside the

view enabling dynamic population of lookup fields from data sources both inside and
outside Livelink.

• Select a WR Power View for a workflow form and use WebReports parameter tags
([LL_REPTAG_& /]) to access information about the executing workflow (e.g. workid,
subworkid, taskid, mapid) then use these to lookup further information specific to the
current step, user or workflow instance.

• Use dummy forms in order to run reports inside a workflow.

To make immediate use of these features:

• From the form template function menu select "Export as HTML" then save the file to
your desktop.

• Go to Properties - Views tab of from template and select "Add View" followed by "WR
Power View".

• When selecting the reportview browse for the file saved to your desktop in the first
step.

• Open the WebReports tag guide and start making immediate use of the 100+ tags
inside your form view.

Note that the WebForms module must be installed for this feature to work.

Page 180
 WebReports User Guide

26 Action Sub-tags

26.1 Overview
The term Action Sub-tags describes a set of sub-tags that perform specific actions as
opposed to simply manipulating the data returned by a WebReports tag. The following list
describes the current set of these sub-tags and what they do.

SETVAR Used to take the tag data and set a named variable with it

CONCATVAR Used to take the tag data and concatenate it to a named variable

ADDVAR Used to take the tag data and add it numerically to a named variable

SETFORM Used to set form fields with tag values

SETWFFORM Used to set Workflow form fields with tag values

SETWFATTR Used to set Workflow Attributes with tag values

SETWFATTACH Used to set Workflow attachments

SETEMAILATTACH Used to set email attachments with Email as a Destination

CATACTION Used to set Category Attributes with tag values

NODEACTION Used to perform actions on Livelink nodes

PERMACTION Used to permissions related actions on Livelink nodes

RMACTION Used to set Records Management Attributes with tag values

USERACTION Used to perform actions on Livelink users and groups

WFACTION Used to perform actions on Workflows

The first three of these action sub-tags are all associated with managing variables.

26.2 Action Sub-tag Properties

One of the main differences between these sub-tags and the many other sub-tags is that
each of these sub-tags is designed to store or set the tag data in some other data storage
location. Normally this means that the data from the corresponding tag will not actually be
returned and displayed in the output of the WebReport.

An action sub-tag can have any number of normal sub-tags to the left of it in the tag syntax.
Any changes to the tag data will be used in the value that is eventually used to perform the
specified action.

Most sub-tags used to the right of an action sub-tag will be ignored. The SHOW sub-tag
(described below) and the CURRENTVAL sub-tag are notable exceptions to this rule.

Page 181
 WebReports User Guide

26.3 Display Considerations

Normally the use of an Action Sub-tag in a tag means that the tag data is not returned to the
output of the WebReport. If it is required that the tag data will also be displayed in the report
output, then the SHOW sub-tag must be used. This should usually be in the rightmost position
in the sub-tag list. Note that this sub-tag always causes the original tag value (prior to the
action being performed) to be displayed. For variable action sub-tags it is important to note
that any variable calculations are not included in the displayed data. The examples below
should clarify this. (Note: these examples all use a "literal tag" which returns a fixed value as
specified between quotes. This tag is sometimes useful where a specific number must be
used with action sub-tags - e.g. to add a specific number - but is used here primarily to
simplify the examples).

[LL_REPTAG_"2" SETVAR:test /] A variable called test is created and set to the

value: 2. It is not displayed in the output. (This
value for test will be assumed in the subsequent
examples.)
[LL_REPTAG_"123" ADDVAR:test /] The value 123 is added to the variable named test
(making the new value of test equal to 125).
Nothing is displayed in the report output.
[LL_REPTAG_"123" ADDVAR:test The value 123 is added to the variable named test
SHOW /] (assuming test is still set to 2). This makes the
new value of test equal to 125. The tag value of
123 is displayed in the report output.
[LL_REPTAG_"123" DEC ADDVAR:test The value 123 is decremented by the DEC subtag
SHOW /] (changing the value to 122). This is then added to
the variable named test making the new value of
test equal to 124). The tag output (after the DEC
sub-tag has modified it) of 122 is displayed in the
report output.

Page 182
 WebReports User Guide

27 Inserting JSON Data

27.1 Overview
JavaScript Object Notation (JSON) represents an efficient way of specifying data to be sent
from servers to browser-based client applications. The actual syntax used to create a JSON
data set is not important as long as the server software builds it correctly. In most, if not all,
cases, the JSON structure is immediately evaluated in the browser client, usually using the
JavaScript eval() function which converts it into a normal JavaScript object/array type
structure. The main benefit of this feature is that it minimizes bandwidth and overhead
between the server and client. JSON allows an object to be encapsulated in a way that can
be understood by humans and swiftly parsed by software applications. It is particularly well
suited to the exchange of data between clients and servers using AJAX type technology
(asynchronous messaging requests). As of Livelink 9.7.1, JSON is used to aid in sending
container browse-related data through AJAX calls.

To support this technology, WebReports provides a mechanism that allows much of the data
normally retrieved using individual WebReports tags, to be delivered as a JSON structure.

27.2 Basic JSON Structure

For Livelink purposes, the JSON structure will normally look something like this:

{"field1":123, "field2":"some text", "myRows":[{row1 fields}, {row2 fields},etc.]}

In other words, there will be various fields at the top level of the object, followed by an
optional array called myRows that will contain all of the rows of data for a WebReport data
source or the contents of a container for ActiveViews. As described below, there are directives
that allow fields to be added to the top level of the JSON structure (outside of the myRows
array) using WebReports tag syntax, as well as options to add fields/columns to each and
every row in the myRows array based on WebReports tag syntax. In this way, data that is
normally returned in individual WebReports tags to the client can be returned in a JSON
structure to be used in any way the client requires (usually in a web browser, converted to a
JavaScript array).

27.3 Tag Syntax and Options

The main syntax for this tag is as follows:

[LL_WEBREPORT_INSERTJSON /]

This tag can only be used in the Header or Footer parts of the reportview. Unlike the
INSERTJSARRAY content control tag, when this tag is used the row section is processed as
normal. It is not valid to use an INSERTJSON tag in the row section as it can be used to
return all data rows outside of the row section.

The INSERTJSON tag supports multiple "directives" which control what type of data the tag
will return. Each directive is proceeded by a "@" sign. This differs from other content control
tags but allows for a very flexible feature set. The currently supported directives are listed in
this table:

Page 183
 WebReports User Guide

This directive is only supported in Livelink version 9.7.1 and later.

@BROWSECOLUMNS It does not require any additional information. It enables the
INSERTJSON tag to return a data set identical to that normally
used in Livelink container browsing. This is useful when emulating
Livelink folder views, particularly in Livelink 9.7.1.
Notes:

• The actual rows of data returned, will be filtered based on

any WebReports conditional row tags (e.g. INCLUDEIF,
EXITIF, INCLUDERANGE).
• This directive and the @ALLDATASOURCE directive are
mutually exclusive
• When this directive is used with a WebReport, the items
returned by the data source must be valid Livelink items
that would normally exist in a Livelink container. For
example, if the data source is not returning Dtree data, an
error message will be generated. Similarly if the data
source returns an item like a Volume, this would also
cause an error message as this item would not normally
appear in a folder.

This directive does not require any additional information. It

@ALLDATASOURCE enables the INSERTJSON tag to return all information from the
data source in one declaration. Besides creating an array with all
rows and columns, this directive also provides some standard
fields to support the data source. These fields are: sourceID,
actualRows, filteredRows, totalRows and
totalSourceRows. Please note that currently the filteredRows
field will only be populated with a valid number if the
[LL_REPTAG_FILTEREDROWS /] tag is included in the
WebReport. If this tag is not required, i.e. only the INSERTJSON
output is being used, then the [LL_REPTAG_FILTEREDROWS
/] should be commented out.
For more information about these fields refer to the corresponding
report tag syntax, e.g. [LL_REPTAG_SOURCEID /]. Note that this
directive and the @BROWSECOLUMNS directive are mutually
exclusive.
This directive returns a single structure that contains all static tag
@ALLSTATIC values that would normally be returned in individual WebReport
tags. The name of each field is identical to the name used in the
corresponding static tag.
This directive is followed by multiple fields that specify additional
@ROWCOLUMNS columns to be added to each row being returned from the data
<columns> source or browse columns. Each field can be either the name of a
column or a WebReports tag and sub-tags. These columns are
normally added to existing columns built by the
@ALLDATASOURCE or @BROWSECOLUMNS directives;
however, if neither of these directives has been used, an array
called myRows will be added to the resulting JSON structure
containing only the columns that have been specified in this
@ROWCOLUMNS directive for each and every row in the data
source.
Each column uses the following format:

<JSON field name>:"<data reference>"

The data reference is either a simple column name from the data

Page 184
 WebReports User Guide

source or a WebReports tag and sub-tag combination. E.g.

@ROWCOLUMNS newColumn:"[LL_REPTAG=DATAID
CAT:price:amount1:display /]"

This example would force that a column called "newColumn" is

added to the myRows array for every row of data returned. The
tag syntax would be resolved for each and every row, in this case
looking up a Category/attribute value.

@ROWCOLUMNS Column2:"modifyDate"

In this second example, a new column field called Column2 is

added to the myRows array using whatever data is returned by
the modifyDate column in the data source.
This directive provides a mode where only the data produced by
@EXCLUSIVE the INSERTJSON tag will be returned. In this mode, all other
PARM:<parm WebReports output is omitted; however, the reportview is still
name> processed as normal to ensure that any variable processing etc.
still takes place. This mode is controlled by the presence or
absence of a parameter in the URL. This parameter is specified
using the PARM: option. For example, PARM:jsononly specifies
that if &jsononly is found in the URL, then only JSON data will be
returned. This parameter defaults to true so if it is included in the
URL, or set to true (&jsononly=true) then exclusive mode is
used. Conversely if the parameter is omitted, or set to false
(&jsononly=false) then normal mode is used. Note that in
normal mode, the JSON data is still included in the output of the
WebReport.
This directive is followed by multiple quoted fields that specify a
@FIELDS name and value for fields to be returned by the INSERTJSON tag.
The fields are made up using this syntax:
<fieldname>:"<fieldvalue>"

The field value could be a literal value but is normally a

WebReports tag. E.g.

USERID:"[LL_REPTAG_USERID /]"

Any fields specified by this directive are added to the front of the
existing JSON structure in addition to any existing fields for other
directives. These fields are not added to the myRows array, only
to the top level object.
This directive adds the JavaScript variable and associated syntax
@ADDJSVAR to assign the returned JSON to a variable specified in <var
VAR:<var name> name>. For example, @ADDJSVAR VAR:temp would add the
following to the beginning of the JSON data:
var temp = "json data object"
This directive allows the default text escaping to be modified for
@ESCAPETEXT any text/string fields being used in the INSERTJSON tag.
TYPE:<escape Valid escape types are: standard and escapeurl The standard
type> type uses the standard JSON specification for text escaping. The
escapeurl type uses URL encoding that would need to be
decoded using the JavaScript decodeURI() function.

Page 185
 WebReports User Guide

27.4 Example
In this example, a WebReport is using a simplified data source that returns only 3 columns
(parentId, dataId, subType) and 2 rows from the DTREE. Given the following INSERTJSON
syntax:

[LL_WEBREPORT_INSERTJSON
@ADDJSVAR VAR:sampleData
@ALLDATASOURCE
@FIELDS SYSTEMDATE:"[LL_REPTAG_DATE /]"
@ROWCOLUMNS objName:"[LL_REPTAG=DATAID NODEINFO:NAME /]"
supplier:"[LL_REPTAG=DATAID CAT:VendorData:supplier:DISPLAY /]" /]

(Note, carriage returns have been inserted here for clarity but should not be used in the
reportview)

This is the data that would be returned in the WebReport output (to the client):

var sampleData={"SYSTEMDATE":"Oct 08 2008", "sourceID":129293, "actualRows":2,

"filteredRows":2, "totalRows":2, "totalSourceRows":2, "myRows":[{"objName":"AAA
test document", "Supplier":"Widgets Inc.", "parentid":126758, "dataid":127200,
"subtype":144}, {"objName":"BBB test document", "Supplier":"Teletech Assets",
"parentid":126758, "dataid":129514, "subtype":144}]}

The following screen shot shows an excerpt of the JavaScript data structure that the client
would build from this JSON data (as viewed from a script debugger).

Note the following:

• The object is called "sampleData" as per the ADDJSVAR directive.

• A new field called SYSTEMDATE has been added to the object as per the FIELDS
directive.

Page 186
 WebReports User Guide

• The fields sourceID, actualRows, filteredRows, totalRows and totalSourceRows have

been automatically created as part of the ALLDATASOURCE directive.

• Two rows (as many as there are rows in the data source) are stored in the array called
myRows. This example shows all three fields that existed in the simple data source
(parentid, dataid and subtype. If the data source had returned all the fields in DTREE then
all of these columns would have been included in the myRows array of data as per the
ALLDATASOURCE directive.

• In addition to the columns returned by the data source, two new columns: objName and
Supplier have been added for each and every row of data. In this simplistic example,
Supplier uses the result of: [LL_REPTAG=DATAID CAT:’Test Category’:’Supplier
Company’:DISPLAY /] for each row to set the data value called “Supplier” in each row of
the array. The objName value is simply looked up in a similar way using the
NODEINFO:NAME sub-tag.

Page 187