EMC Documentum xCP 2.2 Self Paced Tutorial v1.0

Getting Started with xCP 2.2
Self-paced Tutorial
Abstract
This self-paced tutorial introduces you to
the key concepts in xCP 2.2, leading you
to build a sample application through a
series of tutorials.
January 2015
Version 1.0

Copyright © 2015 EMC Corporation. All Rights
Reserved.
EMC believes the information in this publication is
accurate as of its publication date. The information is
subject to change without notice.
The information in this publication is provided “as is.”
EMC Corporation makes no representations or
warranties of any kind with respect to the information
in this publication, and specifically disclaims implied
warranties of merchantability or fitness for a
particular purpose.
Use, copying, and distribution of any EMC software
described in this publication requires an applicable
software license.
For the most up-to-date listing of EMC product
names, see EMC Corporation Trademarks on
EMC.com.
Getting Started with xCP 2.2 !2

Table of Contents
Table of Contents 3
Introduction 6
Index of Features 7
xCP Designer Overview 8
Home View 8
Application View 9
1.0 Application Creation 11
2.0 Application Configuration 13
3.0 Policies 14
3.1 Policy Model 14
3.2 Policy Search Page 17
3.3 Policy Management User Interface 22
3.4 Update Master Page: Policies 29
3.5 Deployment 32
3.6 Repository Configuration: Role and Cabinet 37
3.7 Testing the Application: Policy Creation 39
3.8 Save Last Policy 42
3.9 Testing the Application: Last Policy 47
3.10 Preview Mode 48
4.0 Vehicles 51
4.1 Vehicle Make Picklist 51
4.2 Vehicle Business Object 53
4.3 Stateless Process for Creating and Relating Vehicles 56
4.4 Add Vehicle Action Flow 63
4.5 Vehicle Real-Time Query 72
Getting Started with xCP 2.2 - Table of Contents !3

4.6 Updating the Edit Policy Page 74
4.7 Testing the Application: Vehicle Creation and Policy Linking 79
5.0 Claims 82
5.1 Claim Status Picklist 82
5.2 Claim Folder 83
5.3 Stateless Process for Creating and Relating Claims 86
5.4 Create Claim Action Flow 91
5.5 Claim Real-Time Query 97
5.6 Updating the Edit Policy Page 98
5.7 Claim Management User Interface 103
5.8 Testing the Application: Create and View Claims 107
6.0 Claim Handling Process 111
6.1 Repository Configuration: Work Queue 111
6.3 Work Queue Parameter 116
6.4 Claim Handling Process 117
6.5 Task List Query 125
6.6 Tasks Page 128
6.7 Task Pages 131
6.8 Claim Business Event 144
6.9 Update Master Page: Tasks 147
6.10 Testing the Application: Claim Process 148
7.0 Claim Documents 153
7.1 Content Models 153
7.2 User Interface 155
7.3 Content Search 164
7.4 Update Master Page: Claim Document Search 167

7.5 Testing the Application: Claim Documents 168
7.6 Relevant Documents 175
7.7 Testing the Application: Relevant Documents 184
8.0 Reports and Alerts 185
8.1 Claim Business Events 185
8.2 Historical Queries 187
8.3 Reports Page 192
8.4 Update Master Page: Reports 195
8.5 Testing the Application: Reports 196
8.6 Alerts 197
8.7 Testing the Application: Alerts 202
9.0 Extensions 203
9.1 JavaScript Expression Functions 203
9.2 Testing the Application: Custom JavaScript Function 205
9.3 Java Services 206
9.4 Testing the Application: Java Services 209
9.5 JavaScript Widgets 210
9.6 Testing: Custom Widget 212
9.7 Clear Blue Theme 213
Appendix A: Introduction to User Interface Design 216
Principles 216
Example 217

Introduction
Welcome to the xCP 2.2 Self-Paced Tutorial!
Congratulations on downloading the latest release of xCP which includes the xCP Designer and
xCP Runtime. xCP Designer is the new unified tool for configuring rich case applications which
replaces the separate modelling tools from xCP 1.x. The xCP Runtime is the modern user
interface that makes use of the new REST services provided by xCP 2.2.
In order to introduce you to the software and the new concepts in this release, this tutorial will
have you start from the very beginning to configure a new application that makes use of most
of the concepts available in xCP 2.2. The application will handle the management of insurance
policies and their related vehicle information, as well as the processing of claims against those
policies, allowing documentation to be added to claims and edited. The application will also
contain management reports about the status of claims and the average time taken to process
them.
In the final section of the tutorial you will learn how the functionality of xCP 2.2 can be
extended by adding custom libraries.
Throughout this tutorial we have tried to highlight important points as well as suggestions for
additional things you can try out with a number of symbols as follows.
This symbol highlights a useful tip.
Wherever you see this symbol you will find additional information about a concept or
a recommendation on best practice.
Wherever you see this symbol you will find a warning about common mistakes that
you might make or what may have gone wrong if your application doesn’t work as
expected.
This symbol comes with suggestions of other things you can try on your own to
improve on the final application, or experiment with features of the product.
This symbol provides a quick recap of what you have just completed, and what the
end result should be.
Remember as you work through this tutorial that you are learning. Feel free to experiment at
each step of the way, deploying your application frequently, as well as making use of the new
Preview mode feature.
If you find any mistakes in this tutorial, please let us know as soon as possible through the
appropriate channel.
To work through this tutorial successfully you will need access to a complete xCP 2.2
development environment and have at least one user account which you can use to test the
application. The administrator user that you will use to deploy the application must have the
Extended Privilege of Config, View and Purge Audit. 

Index of Features
If you are already familiar with xCP and just wish to learn how to use a particular feature of xCP
then the following table will point you to the appropriate sections of the tutorial where the
feature is introduced.
Topic Feature Tutorial Sections
Application Role 
Parameter
2.0 
6.3
Object Model Business Object 
Content  
Folder 
Relationship 
Picklist 
Type Fragment
3.1 
7.1 
5.2 
4.2 
4.1 
7.6.1
User Interface Application Page 
Instance Page 
Context Menu 
User Interface Event 
Page Fragment 
Session Parameter Real-Time Query 
Full-Text Query 
Action Flow 
Resources 
Validation Rules
3.2.2 
3.3.2 
3.3.3 
4.6.2 
3.8.1  
3.8.3 
3.2.1 
7.3.1 
4.4 
7.6.5,7.2.7
Process Stateless Process 
Stateful Process 
Process Debugging 
Queue 
Process Versioning 
Composite Service 
Task Page 
Task-List Query 
Custom Success & Error Messages
4.3 
6.4.1 
6.4.2 
6.1 
6.4.1 
4.3 
6.5.3 
6.7 
5.4
Reporting and Alerts Historical Query 
Charts 
Alert 
Alert Query
8.2.1 
8.3 
8.6.2 
8.6.3
Deployment Preview Mode 3.10
Runtime Drag and Drop 
Seamless Editing
3.2.2, 5.7.2 
7.5
Extensions Libraries 
Java Services 
Themes
9.1.1 
9.3 
9.7
Getting Started with xCP 2.2 - Introduction !7

xCP Designer Overview
Before beginning the tutorial it is worth taking some time to familiarise yourself with the two
main views within the xCP Designer tool.
Home View
This shows a list of the applications currently being configured from this instance of Designer.
From here new applications can be created and existing applications can be imported from the
file system.
!
An application can be selected from the Recent Applications list and opened for editing,
exported so that it can be backed up or shared with someone else, and deleted if it is no longer
needed.
The extensive inline help shown above is not only available from the
Home view, but can be accessed at any time by clicking the Help
button on the toolbar.
Switching between the Home View and Application View is achieved by clicking the first button
in the toolbar, which changes to reflect the current view.
Getting Started with xCP 2.2 - xCP Designer Overview !8

Application View
This is the main view where an application is configured. There are four main panels in this
view that can be moved, resized, collapsed and expanded as needed:
Navigator - organises all of the artifacts that make up the application.
Where Used - shows the artifacts referencing the currently selected artifact. Double click to
open one.
Artifact Editor - where one or more individual artifacts are configured.
Properties / Problems - shows properties for an aspect of the artifact being edited as well as a
list of application level problems and warnings. This is also where the console for Preview
mode is shown.
Where Used Properties / Problems
Navigator Artifact Editor

The toolbar buttons from left to right are as follows:
Home goes to the Home view.
Save saves changes to the current artifact and Save All saves changes to all open
artifacts.
Undo and Redo only work in some artifact editors, but will do just what is expected.
Package creates an application bundle for deployment by the xMS server to a
production system.
Run Application packages and deploys the application to a development system.
Pause stops the automatic building of the application. By default automatic building is
paused for a new application.
Validate forces a validation of the project artifacts, and is normally used when the
automatic building of the project is paused.
Preview starts, launches and stops the local preview feature The live preview feature
cannot be used while the automatic building is paused as changes need to be built in
order to preview them.
Preferences opens the preferences configuration dialog.
Help opens the inline help panel.
Refresh causes xCP Designer to reload artifacts from the file system and rebuild the
application.
Search is a quick way to locate an artifact for editing.
Simply enter something in the Search field and the list of
matching artifacts is listed. Click one to open it for
editing. 

1.0 Application Creation
Before you can configure anything you have to create a new application to contain the
application artifacts.
1. Launch xCP Designer.
2. On the xCP Designer Welcome Screen, Click on the New Application button.
3. On the New xCP Application dialog
enter Concordant Insurance as the
Application Name and click Next.
Objective Create a new application.
Concepts Application – a grouping of all of the projects that compose an application.
An application always starts off with one default project, also known as the
Application Project.
Project – a reusable set of models and pages that can be used across
different applications.
Application Project – the default project that gets created when you create
a new application.
Namespace – a prefix defined to be prepended to any Documentum
repository deployed artifacts. For example, if you create a Content Model
(Documentum experts should note that Content Model is the new term for
Document Type) with the name SOP Document, and the application has a
Namespace of emc the content model would be deployed as
emc_sop_document, obviating the need to specify the prefix for each and
every model.
Getting Started with xCP 2.2 - 1.0 Application Creation !11

4. On the next screen, enter cia as the
Namespace and click Finish.
The Application name and Namespace cannot easily be changed once the application has been
created. When choosing the Application name it is worth noting that it will become part of the URL
you use to access the application.
5. xCP Designer will restart and create the new application. After xCP Designer has
restarted, the application you have created will appear in the Projects list of the
Application Model editor (which is opened by default).
Notice that the pause toolbar button is pressed by default. This means that the project
will not be validated and built until you attempt to deploy it.
6. For this tutorial it will be better to let xCP Designer validate and build your changes every
time you save something, so that all problems will be shown in the Problems tab
immediately, so click on the Pause button to de-select it to
enable the automatic building of your application.
As your familiarity with xCP grows and your applications become
increasingly complex it will be more efficient to keep the auto-build
feature disabled and check for problems manually by clicking the
Validate button on the toolbar.
Now you have an empty application ready to be configured. For this tutorial you will not create any
sub-projects, but the Model editor is where you would configure any additional projects. 
Getting Started with xCP 2.2 - 1.0 Application Creation !12

2.0 Application Configuration
Roles are a key concept in an xCP application because you scope access to User Interface
elements and actions based on a users Role, and so you typically start by defining one or more
Roles.
1. Select the Application tab in the xCP Navigator panel, right-click on
the Roles node and select New Role.
2. The New Role dialog will appear. Enter Clerk in the Label
field and click Finish.
3. The Clerk Role editor will open and can be closed immediately. 
You have now configured one Role that you will use for the rest of this tutorial. In a production
application you are likely to have several and you would target specific functionality at each Role. 
Objective Configure a Business Role for the users of the application.
Concepts Role – represents a specific job function for a type of user within an
application. At application runtime, a user should be assigned to at least
one role within the application.
Getting Started with xCP 2.2 - 2.0 Application Configuration !13

3.0 Policies
In this application everything that a user does will be in the context of an insurance Policy, and
so you will start by configuring the functionality to create and manage those Policies.
3.1 Policy Model
The first thing you will configure is the Model that represents an insurance Policy.
1. Select the Object Models tab in the
xCP Navigator panel.
2. Right-click on the Business Objects node and select
New Business Object.
3. In the New Business Object Model
dialog enter Policy in the Label field
and click Finish.
Objective Create the Model that represents an insurance Policy in the application.
Concepts Business Object – defines a business concept that has no content
(contentless objects in Documentum). If you are experienced with
Documentum you can think of them as a type that inherits from
dm_sysobject.
Getting Started with xCP 2.2 - 3.0 Policies !14

4. The Policy Model Business Object editor will open.
5. On the Basics tab, enter a value for the Default location of '/Concordant'. This cabinet
does not exist yet but it will be created before testing. All new  
Policy objects will be created here unless otherwise specified.
6. Select the Attributes tab to add the attributes listed in the table to the Business Object.
The different types of attributes that can be added are listed in the Types pane on the
right of the editor as shown below.
7. To add the First Name Attribute:
a. Double click on the String Data Type. You can also drag and drop the
data type onto the Policy Business Object canvas. Give both ways a try if
you like.
b. Type First Name in the Attributes name field and press
Enter. You can also enter the name into the Label field
on the General tab of the Properties panel.
Attribute Label Type
First Name String
Last Name String
Address String
Coverage Float
End Date Date-time
Getting Started with xCP 2.2 - 3.0 Policies 15

c. Notice in the General tab of the Properties panel at the
bottom of the screen that the System name is
automatically generated.
 
8. Repeat the previous step for the other String attributes, Last Name and Address. Notice
that for Address the default System name will show with a problem marker (small red x).
This is because address is a reserved keyword. Change the System name to
address_line to correct the problem.
 
 
 
 
9. Then add the Coverage Attribute:
a. Double click on the Float Data Type.
b. Type Coverage in the Label field.
10. Finally add the End Date Attribute:
1. Double click the Date-time Data Type.
2. Type End Date in the Label field.
11. Click on the Save button in the toolbar to save the Policy Business Object. You can also
press Ctrl+S to save your
changes. Close the editor. 
 
It is good practice to close the editor for an artifact when you have finished editing it because each
artifact that you have open uses memory and you may find that your xCP Designer becomes
sluggish when you have many open items. You can modify the available memory and other
settings for xCP Designer in the file xcpdesigner.ini located in the root folder where xCP Designer is
installed.
You have just configured the model for a Business Object to represent the basic information about
an insurance Policy. The application you are configuring will allow the creation of multiple
instances of this model in the Documentum repository. 

3.2 Policy Search Page
3.2.1 Policy Search Real-Time Query
The first thing to configure is a Real-Time Query that returns the list of policies.
1. Select the Data Services tab in the xCP Navigator
panel, right-click on Real-Time Query and select New
Real-Time Query.
2. In the New Real-Time Query dialog
enter Policy Search for the Label,
Select Business Objects as the
Primary model and then select
Policy. Click the Finish button to
create the Real-Time Query. 
 
 
3. The Policy Search Model editor will appear. Note
that you can change the Primary model from the
Basics tab of the editor, however if you do then any
output columns that you have already defined on
the Dataset tab will be lost.
Objective Configure a page that will display a list of all policies and allow the user
to filter them by Last Name.
Concepts Real-Time Query – represents a search of object instances in the
Documentum repository. It has outputs and can have inputs. Experienced
Documentum developers may realise this is a GUI-driven way of defining a
DQL query, but don’t worry if you don’t know what that is.
Application Page – are pages that aren’t tied to a specific object or object
type, though it may interact with them. An Application Page can have
many functions, such as a search page for different types of content or
process related data, a report dashboard, a home page, etc.
Interaction – represent out-of-the-box or generated RESTful services that
can be invoked at runtime. On pages, you can map values from widgets
on a page as inputs to an Interaction. When you modelled the Policy type,
the system auto-generated Interactions to create, update and delete
policies.

4. Select the Dataset tab. The Dataset represents the data that will be returned by the
query. Double click on the following attributes from the Context Data pane on the right to
add them to the set of Output Columns: Last Name, First Name, End Date, Coverage and
Object ID. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Finally check the Return hit count checkbox underneath the Output Columns so that the
total number of results found can be displayed later on.
Adding Object ID as an output column is not technically required in this case, but it is best practice
while designing an application as it may come in handy if you decide to wire a comments widget or
a viewer widget to the currently selected item in a result list. You do not have to show the value in
the runtime, and you can always remove it later, although you will have to update any result lists
which depend on the query. Enabling the return of the hit count can have an effect on the
performance of the query which is why it is disabled by default.
5. Click on the User Inputs tab. User Inputs
become search criteria that are used to
filter the final results. Double click, or
drag-and-drop the Last Name attribute to
the canvas to add it to the User Inputs. 
 
 
 
 
6. In the editor canvas, click the Policy.Last Name entry first,
and then move to the Properties tab (located in the lower
pane of the Designer), and change the operator to Contains.
This ensures that you are not searching for an exact match.
Also enable the Case insensitive checkbox.
7. Save your changes and close the editor.
You have just configured the Real-Time Query that returns a list of Policy Business Objects from the
repository, filtered by Last Name value (if provided). The results from this query will be shown on a
User Interface Page when a user logs in to the application. 

3.2.2 Policy Search Page
The next step is to create an Application Page, add the query to the page as an Interaction, and
finally add a Results List widget to the page that is wired to the interaction.
1. Select the User Interface tab in the xCP Navigator panel, right-
click on Application UI and select New Page.
2. In the New Page dialog set the
Label to Policy Search and click the
Finish button to create the Page.  
3. The first thing to do is add the Policy Search query to the page.
a. When the page editor opens, expand the Interactions
pane and click on the New Interaction button (the green
plus symbol). 
In xCP 2.0 this pane was called Data Services and you will still see this term used.
Interactions represent the RESTful services that provide information to the Page from other
systems such as the Documentum repository, and that pass information back from the Page
to those systems. The Inputs contract for each service is a direct representation of the
model it relates to, whether it is a Business Object, Process etc.
b. Select the Policy Search Real-Time Query from
the list of Interactions then click Finish.  
When there is a large list of Interactions in
your application it is quicker to filter the list by
typing part of the name in the filter input.

c. An instance of the Policy Search Real-Time Query will be added
to the Interactions pane. Make sure that the query is selected.
d. In the General tab of the Properties panel, enable the On page load checkbox in the
section titled Refresh. If you do not enable this checkbox, then after the page
loads, no policies will be displayed until you click the Search button associated with
the Results List added in the next step.
 
When testing your application, if your page loads and the result set remains empty it is
probably because you did not set the interaction behind it to refresh. By default interactions
are not set to refresh. From the General tab they can be set to refresh automatically when
an input value changes (you can view and configure the input fields by selecting its Inputs
tab) or when the page is loaded in the browser, and from the Behaviour tab you can
configure that an interaction is refreshed when a UI Event is triggered. You can also
configure a button to refresh an interaction when it is clicked.
4. You will now add a Result List widget to the page and configure it to show the results of
the Policy query. 
a. Drag and drop a Results List widget to the page from the Widgets palette.
 
b. Select the General tab of the
Properties panel of the new widget
and specify an ID of policies and a
Title of Policies. Uncheck the
Enable Drag And Drop checkbox
but check the Enable checkbox
under Display Record Count so that
the total number of policies will be
displayed (remember you selected
to return the hit count in the query). 
The Enable Drag And Drop option only has an effect when the Results List is showing a list of
folders. Enabling the option allows a document to be imported into the target folder from Windows
Explorer or Outlook. Check the Designer help for more details on each of the other checkboxes. 

c. Select Policy Search from the Data service
instance drop-down list to bind the outputs of
the query to your results list. 
 
d. Click OK on the Connect to
Data Service Instance dialog
that appears. 
 
 
e. The widget will be updated to reflect both the input filters and output attributes of
the query, and a Search button added to refresh the data service.
The Data service setting for a Results List widget cannot be changed once it is set, however,
you can delete the data service instance from the Interactions pane and the Results List will
lose its connection to it, allowing you to assign it to a different one. You will need to
manually clean up any input widgets etc. from the original.
f. Right-click on the Object ID column in the widget and
select the Delete option from the context menu. The
column will be removed from the widget, but the value will
still be available as a value of the selected row at runtime.
The Application Page you have just configured will become the landing page of the application that
users see when they log on. It display a list of Policies that they can access which can be filtered
by Last Name if required. 

3.3 Policy Management User Interface
3.3.1 Create Policy Page
The first Instance Page to configure allows the user to create new instances of a Policy object.
1. Select the User Interface tab in the xCP Navigator panel, expand
the Business Objects UI node, right-click on Policy and click on
New Page. 
 
 
 
 
2. In the New Page dialog, select the
Create Policy radio button. 
 
When you select the Create Policy,
View Policy or Edit Policy options
here then the page will be created
with a set of widgets added that
represent the object model
selected. 
 
Click the Finish button to create the
Page.
Objective Configure the User Interface artifacts that allow users to create, edit and
execute actions against Policy objects.
Concepts Instance Pages – are for creating, editing and viewing instances of your
business objects (contentless objects), content objects (documents),
folders, etc. xCP applications can auto-generate pages from the Data
Model for an object. While in a production application you would no doubt
want to create your own look and feel, these auto-generated pages help
you get started because they have widgets pre-selected and pre-bound to
interactions.
Expressions – are used in various places in an application where you
might want to use conditional logic to determine whether to perform a
particular action or to compute a result based on some inputs, such as
displaying or hiding a widget on a page, computing a value to display on a
page or determining which flow to follow in a business process. In xCP 2.0
the language used for these expressions was unified and you will get to
work with them in this section of the tutorial. Check the xCP Designer Help
for a full list of the situations where expressions are used.
Context Menu – defines the actions that can be performed on an object at
runtime when the user right-clicks on an object of that type from a Results
List widget, or expands the action menu of a Selector widget.

3. The page is created with all the attributes defined
in the Policy Business Object, and the editor
window opens.
If the page opens and there are no widgets, it means that you did not save the Policy Model before
creating the page. To correct the problem, close and delete the page, and then save the Policy
Model and try again.
4. Drag and drop the widgets to re-order them in the
following order: First Name, Last Name, Address,
Coverage and End Date.
5. Select the First Name widget and then go to the Validation tab
of the Properties panel. Change the Is Mandatory expression
to true to make it a mandatory value. Repeat for the Last
Name widget. In the editor a red
asterisk is added to the labels to show
that they are mandatory.
6. To demonstrate the use of expressions, you will convert the user input for the First Name
and Last Name fields to upper case when the user clicks the Create button: 
a. Expand the Interactions pane at the bottom of the editor. Click
on the Create Policy Interaction that was generated and added
automatically. It defines how information from the widgets on
the page are passed to the Documentum repository when the
Policy is created.  
7. Select the Inputs tab on the Properties panel.
Notice that most of the inputs are coming
directly from the various widgets.  
 
 
 
 

The Name input value sets the object_name of the object in the repository, and by default
has no expression defined. This means that when the object is saved in the repository its
Object Name attribute will be blank which makes it hard to find when browsing the folder
structure. Because of this it is good practise to assign a value to it, and for this tutorial you
will join the Last Name and First Name together as the Object Name of the Policy.
8. Select the First Name input value and update the
expression in the editor at the bottom to the
following:
toUpper(widgets.first_name.value) 
As you type expressions they are continually validated and the location in
the expression where the syntax error occurs is highlighted and a marker
is shown just outside the expression editor. There are times however
when the expression is valid but the invalid expression marker remains
until you change the focus from the expression and go back to it.
9. Also update the Last Name input value with the
following expression:
toUpper(widgets.last_name.value)
 
e. Finally select the Name input value and enter the following expression to
concatenate the last name and first name values together with a space between
them (make sure to add a space character between the quotes):
widgets.last_name.value + ' ' + widgets.first_name.value 
 
 
 
 
 
 
Expressions can be specified manually by typing with auto-complete, or assisted by using
the Expression Builder. To access the Expression Builder, either double click the desired
value, or select the desired value and click the Selector (…) button.
10. The last thing to configure is what happens when you click the Create button.
a. Select the Create Button that was added to the bottom right of
the page in the Layout tab of the editor. 
 
 
 

b. On the General tab of the Properties
panel, under the Action section, change
the When done go to value from Current
page to Specific page. This setting
causes the application to navigate to a
different page automatically when the
Policy has been created. 
 
 
c. Just below the When done go to value under
Page Selection click the ellipsis button next
to the Page value to bring up the selector
dialog.
d. Select the Policy Search page and click the Finish button.
This configures the application to redirect back to the Policy
Search Page when you create a Policy.
3.3.2 Edit Policy Page
The second Instance Page allows the user to edit an existing policy within the system.
the Business Objects node, right-click on Policy and click on New
Page.
2. The New Page Dialog will appear. Select Edit Policy from the
Generate widgets and bindings radio group and click Finish.
3. The Edit Policy page is created with all the attributes
defined in the Policy Business Object. Notice that for an
Edit Page you have a button labelled Save and if you
open the Interactions pane you will see the Update Policy
interaction that is executed when the button is pressed. 

The only real difference between the pages for creating and editing an object is the Interaction. If
you spend time laying out widgets nicely for a ‘Create’ page, you can duplicate the page, replace
the Create interaction with an Update interaction and set the inputs appropriately, rename the
button and link it to the Update interaction, and save it as the ‘Edit’ page.
4. Select the Save button and under the Action
section of the General tab in the Properties
panel change the When done go to value from
Current page to Specific page and under Page
Selection choose the Policy Search Page.  
 
The effect of this is to redirect back to the Policy
Search Page when you save changes to a policy.
 
5. You will now make a couple of changes to the page as users should not be able to change
the policyholder’s name after a policy is created. 
a. Modify the layout by deleting the First Name and
Last Name widgets by right-clicking on them and
choosing Delete from the context menu. 
 
 
b. Drag a Value Display Widget onto the page just above the Address widget. 
 
 
c. Select the new widget and on the General tab of the
Properties panel under the Basics section, change the ID to
policy_holder and Label to Policy Holder 
 
 
 

d. Finally, on the General tab of the Properties panel under the Value section, enter
the expression policy.first_name + ' ' + policy.last_name as the Initial
Value. This will show the name of the policy holder in the Value Display Widget. 
 
 
 
 
 
 
The Initial Value for a widget can only be a static value such as a string constant or an
expression that displays attributes of an object instance. If you choose a dynamic value
such as the result of a query, it will not be set correctly as the query is not executed on page
load. In this case you must use UI Events which are covered later in this tutorial.
3.3.3 Policy Context Menu
Next you configure a Context Menu that gives access to the relevant actions for the policy.
1. Select User Interface tab in the xCP Navigator panel, right-
click the Policy node under Business Object UI and select
Create Context Menu.  
2. The Context Menu editor opens with the default
menu options, which include a link to the Edit
Policy page that you created previously. Select
the Edit Policy menu entry. 
 
 
 

3. Select the Behavior tab of the Properties panel for the menu entry and enter this
expression for the Hidden when value: differenceDays(today(),policy.end_date)>0 
 
The effect will be to hide the
menu option if the End Date of the
policy has already passed, so that
expired policies cannot be edited.
4. Save and close the editor.
The focus of this tutorial is the functionality provided by xCP and not the design of the applications User
Interface (UI). Appendix A provides some pointers on good UI design with xCP, but it is worth highlighting
at this point that the Column Box Widget is the main container that is used to manage the layout of
Pages. If you select a Column from one of the Column Box Widgets that was added automatically to your
pages you can see the layout options from the Column tab of the Properties panel as shown here. 
As you work through the tutorial you will notice that the default layout options of automatically generated
Pages and the other Widgets that you add may not always align correctly and it is these Column
properties and the Margins of the other widgets that you will need to adjust.
You now have the User Interface artifacts configured that allows users to create new instances of the
Policy model in the repository and to edit the information about existing policies. The Context Menu will
allow them to right-click on an existing policy and choose from the appropriate actions for that policy. 

3.4 Update Master Page: Policies
1. Select the User Interface tab in the xCP Navigator panel and double
click on the Master page, which was added automatically for you when
you first created the application.
2. The default Master Page
provides a Navigation Menu
widget with an embedded User
Session Control widget and a
Content Area widget. This
widget is where all other pages
will appear as users interact
with the application. 
 
3. You will now configure a couple the menu items to link them to the pages you have just
created
a. In the Layout tab of the editor, select Menu Item 1
from the default Navigation Menu widget.
b. In the General tab of the Properties panel set the ID to
policies and the Label to Policies.
 
Objective Link Navigation Menu items to the Policy Search and Create Policy pages.
Concepts Application Master Page – similar to a Slide Master page in PowerPoint—
anything you put on the master page will be on every page in your
application. Commonly, headers (like a logo), global navigation (like a
menu bar) and footers (like copyright or contact information) are put on
master pages.
Application Default Page – the page that users first see when they log in
to your application.

c. In the Layout view right-click on the renamed Policies
Menu Item and select Insert Submenu Item.
 
d. In the Properties panel under the Basics section set the
submenu item lD to new_policy and the Label to New Policy.
 
 
 
 
e. Under the Link section select Page from the
Link destination drop-down list. Select the
Page radio button under Page Selection, click
on the selector button (…) and choose the
Create Policy page.
If you do not know the specific Page name at runtime you can choose the Expression radio
button instead and specify the system name of the Page with an expression. As well as
linking to an Application Page, links can be to an Instance Page. This is configured by
explicitly choosing the Page as above or with an expression, and also entering an expression
for the Object ID value of the instance in the Object ID field.
f. In the Layout view, left-click the Policies menu item
to expose its submenu, then right-click the New
Policy submenu item and select Insert Item After
from the context menu.
g. On the Properties tab of the new menu item, change the ID to policy_search and
the Label to Search and under the Link section set the destination as the Policy
Search Page.
 
 
 

4. Now, you’ll configure your Policy Search page as the default login page for the application.
a. Select the Basics tab near the top of the screen.
 
 
b. Under Application default page section select the Page radio button, then click the
selector button (…) and choose the Policy Search page. When any user logs in they
will now be taken to the Policy Search page automatically.
The default page can also be based on an expression, allowing you to configure a dynamic
default page, such as the last policy that the user was viewing before logging out, or a page
selected by the user as a preference.
Just because the default Master Page has a Navigation Menu Widget does not mean that you have to use
it. If you are configuring an application that will be accessed from a tablet device for example you would
probably want to replace it with a series of large icons or just have a ‘home’ button and make the default
page the navigation page. Don’t be limited by what is provided out of the box. The only widget that you
must include on the Master Page is a Content Area widget.
Your application is now configured to load a default home page (Policy Search) when any user logs in, and
the default Navigation Menu has links that allow the user to navigate to the Create Policy Page and back
to the home page. 

3.5 Deployment
1. Click on the Preferences button in the toolbar to load the Preferences dialog. 
 
 
 
 
2. The first environment to configure is the Deployment Environment. 
a. Select Deployment Environments from the left of the dialog.
Objective Configure the xCP Designer preferences and deploy the application.
Concepts Deployment Environment - an xMS configuration that defines the
Documentum Content Server and all other components necessary to run
an xCP application.
Design-Time Environment - defines which services the Preview mode
feature accesses.
Run Configuration - defines how to conduct a deployment (which runtime
environment to use and which deployment options to use). In this tutorial,
you’ll only be using the default options.

b. Click the Add button on the right of the dialog. The Add Deployment Environment
dialog will appear. Specify the connection details for your xMS environment:
Environment name is the name you will
use to refer to the environment.
Hostname is the hostname or IP address
of the application server where the xMS
service is running.
Port number is the port number used by
the application server where the xMS
service is running.
Username is the administrators user name
for the xMS service.
Password is the administrators password
for the xMS service. 
c. Click the Test Connection button. If the connection is
valid click the Finish button. 
3. The second environment to configure is a Design-time Environment. 
a. Select Design-time Environments on the left side of the dialog. When prompted to
apply changes, click the
Apply Now button.
b. Click the Add button on the right of the dialog. The Add Design-Time Environment
wizard will appear. Specify the connection details for your Development
Documentum Repository:
Docbroker Hostname is the name
where the Docbroker is running.
Docbroker Port is the TCP/IP port that
the Docbroker is running on. The
default is 1489.
Repository Name should be populated
when you enter the first two values and
click the Refresh button.
Username is the docbase owner
account.
Password is the password of the
docbase owner.
Domain is the domain of the docbase
owner. This can usually be left empty.

c. Click the Test Connection button. If the connection is
valid click the Next button.
d. Specify the connection details for the BAM server:
BAM address is the hostname or IP
address of the application server where
the BAM server is running.
Port number is the port number used by
the application server where the BAM
server is running.
e. Click the Test Connection button. If the BAM server is
reachable click the Next button. 
f. Check the Specify Global Registry Repository check-box and specify the connection
details for the Global Repository:
Docbroker Hostname is the name where
the Global Registry Docbroker is running.
Docbroker Port is the TCP/IP port that the
Global Registry Docbroker is running on.
The default is 1489.
Repository Name should be populated
when you enter the first two values and
click the Refresh button.
Username is the docbase owner account.
Password is the password of the docbase
owner.
Domain is the domain of the docbase owner. This can usually be left empty.
g. Click the Test Connection button. If the connection is
valid click the Next button.
h. Enter a value for Environment name and
optionally for Description. Click the Finish
button to save the settings.
The Design-Time Environment defined here is not used until later in this tutorial, but it
makes sense to configure it at the same time as the other Environment settings. Full details
on the different Run Configuration settings can be found in the Inline Help in xCP Designer.
Simply click this Help button icon in the Preferences dialog.

4. The final thing to set up is a Run Configuration.  
a. Select Run Configurations on the left side of the dialog.
b. Click the Add button on the right to add a run
configuration. The Add Run Configuration
dialog will appear. Specify a Name for the new
run configuration (any name will do) and
optional Description and click the Finish
button. 
 
 
 
c. Click the OK button to close the dialog.
5. Close any open editors and click the Run Application
button on the toolbar to deploy and run your application.
 
‘Running’ your application consists of the following stages: Validation, Compilation, Packaging and
Deployment. In this final Deployment stage, xCP Designer hands the deployment package to the
xMS service so that it can deploy
the relevant changes to each
system component. At this point
the Run in Background button in
the progress dialog is enabled.
Clicking this button will allow you
to continue working on your
application while the xMS service
completes the deployment. 
If deployment fails open the file runapp.log and check for error messages. If you see an error like
‘The current user (dmadmin) needs to have 'config audit' privilege to audit the dm_all_workflow
event.’ then it means the user account configured within the xMS system does not have the correct
privilege. You have to use Documentum Administrator to grant that privilege to the user. Note that
you will not be able to log on as the user mentioned and change it for security reasons, and so you
will need to log on as a different superuser and change the privilege for the user mentioned.  
 
Once you have done that you can redeploy. If deployment still fails then you may need to restart
the application server where you applications are deployed, or the application server where your
XMS agent is installed.

6. When the deployment is completed,
the default web browser will be
opened and directed to the URL of
your application.  
Notice that the URL to access the
application is simply the Application
Name. For ease of access later on
though you should add the URL to
the browser's bookmarks.
 
 
xCP Designer assumes your application server is running on port 8000. If this is not the case you
can change the value in the file xcpdesigner.ini file which is in the same folder as xcpdesigner.exe.
Your application has now been compiled and the components deployed to the relevant services. Before
you can start to use it however you need to create the cabinet and add at least one user to the Clerk role.

3.6 Repository Configuration: Role and Cabinet
For this tutorial these steps can be done using Documentum Administrator. The URL for
Documentum Administrator will look like this: http://<Server>:<Port>/da
3.6.1 Adding Users to Role
1. Log on to Documentum Administrator with
an administrative account (typically
dmadmin).  
 
 
 
 
 
2. Navigate to Administration > User Management > Roles
3. As with every artifact, the system name of your applications Clerk role has your
namespace prepended, and so in the filter box in the right side of the screen enter the
namespace of your application (cia) and
either press Enter or click the filter button
to limit the list of roles shown to those in
your application.
4. Double click the cia_clerk role to view the users in the role. There
shouldn’t be any users yet.
5. From the menu select File > Add Member(s).
Objective Add test users to the Clerk Role and create the Concordant Cabinet in the
repository.

6. The system displays the
Choose a user/group dialog.
Locate one or more users
(such as dmadmin) to add to
the role. You can filter the list
of users to make it easier.
7. Select the user(s) and click the Add arrow in the center of the screen to
add them to the role. Click the OK button to save the change. Leave
Documentum Administrator open for the next section.
3.6.2 Creating a Cabinet
1. Select the Cabinets node in Documentum Administrator.
2. From the menu select File > New > Cabinet
3. In the New Cabinet dialog enter a Name of
Concordant and click the Finish button.
Your repository now has a Cabinet called Concordant which is where all of the Policy object instances for
your application will be created. You also have one or more test users that are in the Clerk Role. 

3.7 Testing the Application: Policy Creation
1. Log in to your application as a user that
you just added to the Clerk Role. If you
choose another Language, the interface
will update to reflect that language, even
switching to a ‘right to left’ orientation if
required.
2. Upon logging in, you will be presented with the main screen to your application. Notice
that since you haven’t yet created any policies the list is empty.
If you see an error message like this it means you have not added the user to the role correctly. 
 
3. Start testing the application by creating a new Policy.
a. Hover your cursor over the Policies menu item and click on the New
Policy submenu item. 
 
 
The behaviour of the Navigation Menu Widget can be changed so
that you have to click on the menu rather than hover over it. You
change this setting from the General tab of the Properties panel
for the Navigation Menu Widget (not the menu item itself). 
Objective Test the application by logging in and creating & editing Policies.

b. Start to fill in the details for the Policy by entering a
value for First Name, but skip Last Name and go
straight to Address. The Last Name field should be
highlighted as it is a mandatory field.
c. Hover the mouse pointer over the small exclamation mark at the end
of the field to see the inline validation message.
 
d. Go back and fill in the Last Name, Policy
Address, Coverage, and End Date fields. 
 
 
 
 
 
 
e. Click on the Create button to finish creation of the policy and redirect
you back to the Policy Search page.
f. You will also see a dropdown message near the top
of your screen indicating that the policy was created
successfully.  
 
4. Create a couple more Policy objects, making sure that at least one has an End Date in the
past so that you can test the rule that was added to the context menu. Each time you add
a new policy it should show in the list of policies on the home page. Notice how the Last
Name and First Name values have been converted to uppercase by the function you
added to the expressions on the Create Policy Interaction.  
Also note that the total count of policies is displayed in the bottom right corner of the list. 
You will find that the first time you access any function such as policy creation after deploying the
application the system will respond more slowly. This is normal. 

5. Type par t of one of your
policyholders last name into the
Last Name field at the top and
click the Search button. You
should see the list narrow down to
contain just policies where the
Last Name contains the string you
entered. 
 
 
6. Right-click on a policy in the list whose End Date is
in the future. The context menu will appear and
allow you to select the Edit Policy option. You may
need to clear the search field and click Search
again to see one in the list with a future date. 
7. When you click Edit Policy from the menu the
Edit Policy page loads allowing you to make
changes to some of the Policy data. Make a
change, such as changing the Coverage
amount and click the Save button. 
 
 
8. Click the Yes button in the confirmation dialog. A
notification that the item was updated successfully
is displayed at the top of the screen and the
application redirects to the Policy Search Page.
 
 
9. Right-click on another policy in the list
whose End Date is in the past. The context
menu will appear but this time the Edit
Policy option should not be available. 
 
Before moving on with the tutorial you could go back and try the following: 
1. Modify the Context Menu and remove the unwanted options. 
2. Play around with the layout of the Widgets on each Page. 
3. Modify the width and style of the Columns in the Results List Widget. 
4. Add a new Navigation Menu item linked to the Manage Application Roles Page. 

3.8 Save Last Policy
A common requirement for a case management application is to remember the last case that a
user was working on even if they close the browser and reopen it. In this section of the tutorial
a reference to the last edited policy will be cached in a Session Parameter configured as a
cookie, and the Policy Search Page updated to show the last edited policy with a Button Widget
to open it.
3.8.1 Define Session Parameters
The first step is to define the Session Parameter that stores the ID of the policy.
1. Select the User Interface tab in the xCP Navigator panel, right-
click on Session Parameters and choose New Session
Parameter.
2. In the New Session Parameter
dialog enter Last Policy ID in the
Label field, leave the Type as String
and enable the Stored in a cookie
checkbox. Click the Finish button.
3. The Last Policy ID Session Parameter editor will open, but no changes are required so
you can close it immediately. 
Objective Cache the users last edited Policy across sessions.
Concepts Session Parameter - stores data that can be shared between various
application elements at runtime and persisted between sessions.
Page Fragment - a component that contains a collection of widgets or
interactions that you can add to pages or other page fragments. Creating
page fragments eliminates the need to add the same widget or widgets to
multiple pages in an end-user application. Page Fragments can be
created at the Application level or Object Model Instance level.

3.8.2 Update the Edit Policy Page
The second step is to update the Edit Policy page so that the Session Parameter is updated
whenever a policy is edited.
1. Instead of using the xCP Navigator panel to locate
an artifact, try using the Search feature. In the
Search box at the top right of the screen enter edi as
the filter text. Select Edit Policy from the filtered list
of artifacts to open it. 
Throughout this tutorial, whenever you are asked to open an artifact for editing you can use this
method instead of browsing with the xCP Navigator panel.
2. Expand the Interactions pane and select the
Session Parameters entry. This system generated
Interaction updates Session Parameter values
when the page loads.
The Session Parameters Interaction is only shown once you have at least one Session Parameter in
your application. This is why you did not see it in the previous section of the tutorial.
3. On the General tab of the Properties
panel, expand the cia node to view
the parameters. Enter the expression
policy.id for Last Policy ID.
3.8.3 Policy Page Fragment
The next step is to create a Page Fragment for the display of Policy information, which can then
be added to the Policy Search Page to show details of the most recent policy accessed, and
later used on each Business Process Task Page.
1. Select the User Interface tab in the xCP Navigator panel.
Expand the Business Object UI node, right-click on Policy
and select New Page Fragment.

2. In the New Page Fragment dialog
choose the View Policy radio button
(this is closest to what you want it
for) and change the Label to View
Policy Details. Click the Finish
button to create the Page Fragment.
3. Rearrange the widgets on the Layout tab of the Page Fragment editor
to match the screenshot opposite.
4. Select the Data tab of the editor. Notice that the
fragment takes the id of the policy model as an Input
value.  
When a fragment is added to a page the contents
of the widgets on the layout will show the attributes
of an instance of the given model whose
r_object_id value is assigned as the id Input value.
This allows you to build a user interface where the
contents of fragments can be updated dynamically
at runtime.
3.8.4 Update the Policy Search Page
The final steps are to update the Policy Search page to display the last edited policy and to add
a button that allows the user to open it for editing immediately.
1. Select the User Interface tab in the xCP Navigator panel, expand the
Application UI node and double-click Policy Search to open it for
editing.

2. Start by adding a Page Fragment Widget to the page.
a. Select the Layout tab of the editor and right-click
in the Column Box widget that contains the
search widgets. Select Insert Column on Right
from the context menu. 
 
 
 
b. Select the new Column and on the General
tab of the Properties panel set the
Orientation to Horizontal.
c. Drag a Page Fragment Container Widget into the new Column from the palette.
d. On the General tab of the Properties panel for the Page Fragment Container enter
policy as the ID, Policy as the Label and select View Policy Details as the Page
Fragment ID. The fragment will be updated to show the policy information.
 
 
 
 
e. Under the Page Fragment Input Mapping section of the General tab in the
Properties panel set the expression sessionparameters.cia.last_policy_id as
the id Input value (this is the ID of the
last edited policy from the Session
Parameter cookie):

When you have a Page Fragment that has been configured like this you can simply double-click the
Widget on the Page Layout and xCP Designer will open that Page Fragment for editing.
3. Next you will add a Button widget that opens the Edit Policy Page of the last edited policy.
a. Drag & drop a Button widget to the right of the Page
Fragment Container widget on the layout. Set the ID to
open_last_policy and the Label to Open Last Policy.
b. Under the Action section of the
properties select Go to a page from the
Invoke drop-down list.  
 
Choose the Page radio button and select
Edit Policy as the page to navigate to. 
 
Finally enter the following expression in
the Object ID (Instance Pages) field: 
 
sessionparameters.cia.last_policy_id  
 
The result of this configuration will be to
load the Instance Page for the Policy
object based on the ID saved in the
cookie.
You have now extended your application so that it will save the ID of the Policy in a cookie on the users
computer whenever they open one for editing. You have also updated the Policy Search Page so that the
user can see the details of the last edited Policy and open it with a single click. 

3.9 Testing the Application: Last Policy
1. Close any open windows and click the Run Application
2. When the deployment is completed, log in to your application as the user that you added to
the Clerk Role. The Policy Search Page will load and there should be no Last Policy Fragment
showing because this is the first
time you have loaded the page
since making the change, and Page
Fragments are automatically hidden
if their Input values are empty.
3. Right-click on a policy and select Edit Policy from the menu.
4. Make a change to the policy, click the
Save button and click Yes on the
confirmation dialog to go back to the
Policy Search Page. The Last Policy
Fragment now shows the policy details.
5. Log out of the application by selecting Sign Out from
the User menu option.
6. Log in again and confirm that the Last Policy ID value has been read
from the cookie.
If the layout of the page reverts back to the previous version (without the Page Fragment) it is
because the application pages are being cached. You can either use the Private Browsing /
Incognito mode of your browser, or clear the browser cache to ensure the latest versions of
artifacts are used. Clearing the browser cache though may also clear the value stored in the
cookie. In Production you would increment the applications version number before deploying to
force a refresh in each clients browser.
7. Finally click the Open Last Policy Button. The Edit Policy Page should
load for that policy. 
Objective Test that the last edited Policy is stored by opening a policy, logging out
and logging back in again.

3.10 Preview Mode
You saw in the last step that when there was no value in the Last Policy ID cookie the Page
Fragment was automatically hidden. However the Open Last Policy button was not hidden, and
so in this step you will update the Behavior of the button to implement this.
Before testing with Preview mode you need to clear your web servers browser cache so that the Last
Policy cookie is deleted. It is a good idea to run your browser in private / incognito mode when testing
you application so that you don’t have to keep doing this.
1. Start Preview mode by selecting the Start
Preview Mode option from the Preview mode
toolbar drop-down.
2. A new Console tab opens in the
bottom panel. Wait for the
confirmation that the embedded
Jetty application server has started.
3. Select the Preview in Browser option from the Preview mode toolbar
drop-down. The browser will load a new tab pointing at the local
embedded application server.
4. Your default browser should load and show you the applications login page. It is useful to
check that the URL of the page is localhost so that you know you are testing with Preview
mode and not your own development application server. 
Objective Change the User Interface and test the change with Preview mode.
Concepts Preview mode - allows you to preview the application in a browser during
design time, replacing the need of end-to-end deployment to view design
changes in an application.

5. Log in as the user that you added to the Clerk Role. The Policy Search Page loads and so
long as you cleared the browser
cache to delete the cookie, there
s h o u l d b e n o l a s t p o l i c y
information. The Open Last Policy
button will be visible.
6. Leave the web browser open at the Policy Search page and
switch back to xCP Designer. Open the Policy Search Page
editor from the User Interface tab in the xCP Navigator panel,
or the Search function.
7. On the Layout tab of the Page editor select the
Open Last Policy button and select the
Behavior tab of the Properties panel.
This is where you define what events the widget
can publish and what events and behaviors it
can subscribe to (such as hiding the button).
Click the Add button in the Subscribe section.
8. In the Subscribe dialog select Hide When
from the Behavior dropdown list and enter
t h i s e x p r e s s i o n b e l o w i t :
sessionparameters.cia.last_policy_id=='' 
 
Click Finish to save the subscription. By
comparing the session parameter to an
empty string, the button will be hidden when
there is no cookie or the cookie is empty.
9. Save your changes but keep the editor open. Switch back to your web browser and clear
the browser cache again so that the new expression will be used. Refresh the browser
and you will be prompted to log in again. Log in and this time the Open Last Policy button
will be hidden.
When you make any changes to expressions, Session Variables, or UI Events, you can only view
them in the Preview mode when the browser cache is cleared. Preview mode only covers UI level
changes. Anything that requires repository representation such as a Business Object must be
deployed before previewing.

10. Right-click on a policy and select Edit Policy from the context
menu.
11. Make a change to the policy, click
the Save button and click Yes on
the confirmation dialog to go back
to the Policy Search Page. The
Open Last Policy button should
now be visible.
For the rest of this tutorial remember that you can use Preview mode at any time to see the effect of
changes to the user interface before you get to each deployment and testing section. As you progress
through this tutorial you will create many Pages and Preview mode is invaluable when getting the layout
of each page correct with widgets aligned correctly.
Before moving on with the tutorial you could go back and try the following (don't forget to use Preview
mode to test the changes): 
1. Change the style of the End Date Widget in the Page Fragment to remove the time. 
2. Put the Widgets in the Page Fragment inside a Column Box Widget 
3. Adjust the spacing of the Widgets to make the fragment smaller.

4.0 Vehicles
Now that you can create and manage insurance Policy objects you will add the ability to create
Vehicles and relate them with policies. Don’t forget to close any open editors before continuing
with the tutorial.
4.1 Vehicle Make Picklist
The list of vehicle makes will rarely change, and so to ensure data consistency it is better to use
a static picklist of values from which the user can pick the make when creating a Vehicle.
1. Select the Object Models tab in the xCP Navigator panel, right-click
on Picklists and select New Picklist.
2. In the New Picklist dialog enter
Vehicle Make in the Label field and
click the Finish button.
3. The Picklist editor will appear. You will use the default Data type of
String. 
 
 
 
 
4. Click on the Entries tab to start adding entries.
You can click anywhere on the empty grid to add
a new row to the pick list and start entering
values. You can simply tab between the Label
and Value columns and new rows will be added
automatically. You can also use the Add Entry
and Remove Entry buttons.
Objective Model a picklist to represent a list of vehicle manufacturers that can be
selected when adding a vehicle to an insurance policy.
Concepts Picklist – a static list of name/value pairs used when configuring Data
Model attributes as well as Results List and Drop-down List Widgets.
Getting Started with xCP 2.2 - 4.0 Vehicles 51

5. Add the entries listed in the table so that your picklist looks like this.
 
You now have a Picklist containing a list of vehicle manufacturers. The Value of each picklist entry is the
short code identifier for the manufacturer and the Label is their full name. 
Label Value
Ford Motor Company FORD
Toyota TOYO
Volkswagen VOLK

4.2 Vehicle Business Object
Another business object will be used to store the Vehicle information but this time you will also
add the ability for it to be related to a Policy
1. Select the Object Models tab in the xCP Navigator panel, right-
click on Business Objects and select New Business Object.
2. In the New Business Object Model
dialog enter Vehicle in the Label
field and click the Finish button to
create the Business Object.
3. For the Policy model you configured the Default location value from the Basics tab to
ensure that all policies were created inside the Concordant cabinet. For the Vehicle
model you will handle
this in a different way
later on in the tutorial. 
4. Select the Attributes tab
of the editor. Notice that
the Vehicle Make Picklist
appears in the Types
pane on the right.  
 
 
 
 
 
 
Objective Create the Model that represents the information about a Vehicle and
define how it is related to a Policy.
Concepts Relationship – defines how different objects are associated.
Relationships can be one-way, two-way, one-to-one, one-to-many etc. and
can also have custom attributes defined. Relationships are a powerful
concept in xCP because they allow you to define rich data models that can
be searched and navigated easily.

5. Add the attributes from the table to the Vehicle Model. To add the Vehicle Make attribute
you actually add the Vehicle Make Picklist. The default System name for Year of year will
not be allowed as it is a reserved keyword like address was for the Policy. You will need to
change it to vehicle_year.
 
6. To configure a relationship between the Vehicle
and Policy, scroll down or close the sections in
the Types pane to locate the Relationships
section. Either double click or drag-and-drop
Policy to add the relationship to the attribute
list for Vehicle.
7. In the General tab of
the Properties panel
select the Two-way
radio button and click
the Many to One icon
as shown. 
 
 
 
 
 
Specifying a two-way relationship ensures that Vehicle objects will have access to the Policy to
which they are related, and vice-versa. Specifying that the relationship should be Many-To-One
indicates that there can be many Vehicles associated with a single Policy,
but a Vehicle cannot be associated with multiple Policies (that would be a
Many-to-Many relationship).  
 
Relationships can have their own attributes added in the right pane of the
Attributes tab in the editor that help describe and qualify the relationship.
Vehicle Make Picklist
Model String
Year Integer
VIN String

8. Add the attributes from the table below to the relationship. Note that you can only add
them by the drag and drop method. When you add the Notes attribute also set the String
length to 1024 in the Value section of General tab of the Properties panel.
 
9. Save the changes and close the editor.
Your application now has the concept of a Vehicle object with the value for the Vehicle Make attribute
coming from a Picklist of allowed values. A Policy is allowed to have many Vehicles related to it, but a
Vehicle can only be related to a single Policy. You have also defined that when a Vehicle is related to a
Policy you can describe that relationship with additional attributes. 
Start Date Date-time
End Date Date-time
Notes String

4.3 Stateless Process for Creating and Relating Vehicles
Because a Vehicle object will only ever be created in relation to a Policy object you will not use
the automatically-generated Create Data Service for a vehicle as it does not provide the ability
to relate the newly-created vehicle to a policy. Instead you will create your own Data Service
using a Stateless Process to create the vehicle and then relate it to the policy.
1. Select the Processes tab in the xCP Navigator panel and click
the New Process button.
2. In the New Process dialog enter
Vehicle Create and Relate to Policy
as the Label. Enable the Process
can run in stateless mode checkbox
and click the Finish button. 
 
It is a good idea to use a naming convention for processes so that you can easily find them in the
Navigator, such as a prefix of ‘Vehicle’ for all processes that act on vehicles and ‘Policy’ for those
that act on policies.
3. Click the Process Properties button in the Process editor
panel to open the Process Properties dialog.
Objective Configure a Data Service using a Stateless Process to create a Vehicle
and relate it to a Policy.
Concepts Stateless Process - a process whose state is not maintained in the
repository. It is executed synchronously, and as such, cannot involve any
human tasks - all tasks must be automatic - although, a stateless process
can invoke a stateful/normal process which does contain human tasks. In
this case the stateless process will not wait for the stateful process to
complete. Stateless processes are incredibly powerful in xCP as they can
be wired to widgets and events in the xCP user interface. Stateless
processes replace the need for things like custom Forms Adaptors from
xCP 1.x, as instead of having to write code to execute as the result of
clicking a custom button, you instead define a stateless process with the
desired functionality. Also, a stateless process is executed in a similar way
to a database transaction - if any activity in the process fails, any changes
made to the Documentum repository such as the addition, modification, or
deletion of folders will be rolled back.

4. Select the Data tab in the Process Properties
dialog and select the Packages node.
5. Click the Add button just below the tab to create a new package.
6. In the Package Definition panel enter a Name of
vehicle and de-select the This is a mandatory
package checkbox. Click the Select button and
choose the Vehicle model as the package Type.
7. Select the Process Variables node and add each of the process variables listed below.
 
 
 
When you define a String process variable it is not possible to set the maximum length of it. This is
because all String variables have a maximum length of 2000 characters in xCP 2.2.
The way that process data is modelled changed between xCP 2.0 and xCP 2.1, with the concept of
a Composite Service was added to standardise the definition of Input and Output values for the
process variables and packages of a Stateless Process. In xCP 2.1 if you had both single and
repeating variables as Output variables there were then limitations as to where you could
reference the Stateless Process. In xCP 2.2 these limitations have been removed.
Variable Name Type
make String
model String
year Integer
vin String
policy_id String
start_date Date-time
end_date Date-time
notes String

8. Select the Composite Service tab in the Process Properties dialog. Select the Use as
Input checkboxes for each of the Variables and click the OK button.
 
 
 
 
 
 
 
 
 
 
 
9. Expand the Content node in the Activities panel on the right of the
Process editor.
 
10. Drag and drop a Create activity and two Set Process Data activities onto the process
model canvas. The Create activity will be used to create a new instance of the Vehicle
model. The first Set Process Data activity will
relate the new vehicle to an existing policy object.
The final Set Process Data activity will then set
the attributes of the relationship.
11. Click the Straight flow toolbar button to enter line drawing
mode. The editor will stay in line drawing mode until you
click the Select Objects toolbar button or you click the editor
canvas.
There is no difference between a Straight-flow or Multi-Segment flow, it is purely a visual difference
that allows you to layout your process map in the most appropriate way.
12. Draw flow lines between all four activities. You
can select multiple activities and right-click on
them to access alignment options from the
context menu.

13. Double-click the Create activity to open the Activity Inspector dialog at the Create tab.
Change the activity’s name to Create Vehicle. To set the model to be created click the
Select button, choose the Vehicle model from the Select Model dialog and click the Finish
button. Under the section Get Destination Folder by select the Folder path radio button
as you will be deciding where the vehicle goes in this step. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Click the Next button to open the second page of the Create tab. 
14. From here you map the Process Data from the tree on the left that will be passed to the
Create activity, by using Functions from the drop down list in the centre.

15. First map the make Variable to the Make attribute of the new Vehicle object by using a
Copy function as follows: 
a. Select the Copy function from the dropdown list of
functions in the centre of the dialog. This function requires
one input value and one output value but other functions
take multiple input values. 
 
b. With the function selected, expand the Process Data
Variables node on the left and select make to create a
connection to the function. The line is automatically
drawn. If you clicked make again the line would be
removed. 
c. Finally click Vehicle Make under the Create method tree
to complete the mapping. Again the line is drawn
automatically. If you click the wrong attribute simply
click it again to remove the link and click the correct
attribute.
16. Repeat the last step to map
the model, year, and vin
Variables on the left to the
Model, Year and VIN attributes
of the Create method on the
right using multiple Copy
functions.
17. Set a hardcoded value for the Destination folder path as follows:
a. Select the Copy function and ONLY connect it to the
Destination folder path [0] node on the right.
b. Double-click the new Copy function
to open its Function Editor dialog 
 
 
 
 
 
 
 
c. Add a new Function Parameter by clicking the Add button.

d. Double click the new empty parameter and type /Concordant as its
value. This is the cabinet that you created previously. Note that when
entering strings into the Function Editor dialog there is no need to
enclose them in single quotes. Click the OK button to close the dialog. 
You could have used the same ‘Default location’ mechanism for the location of vehicles as you did
with policies, but as you have seen with this step of the tutorial, there are often multiple ways of
achieving the same end-result. Using data mapping as you have done here would allow you to set
a dynamic folder location for the new object.
18. Set the Name of the new vehicle to be the same as the vin value as follows:
a. Add another Copy function and connect it to the
Name attribute on the right.
b. If you now just select the vin Variable it would be
disconnected from the existing function. To make it an
input to a second one select the Line drawing mode tool.
c. Click on the black anchor on the left
side of the Copy function and draw a
line to the black anchor next to the vin
Variable as shown in the screenshot opposite.
Position the crosshair as close to the anchor as
possible before clicking again to complete it.
19. Click the Next button to advance to the Output Message Mapping page of the Create tab.
In this page the output values of the Create activity are on the left and the Process Data
is on the right. Add another Copy function and use it to connect the output ID value of
the Create activity (the newly created object) to the Object ID attribute of the Vehicle
Package.
 
 
 
 
The ID of the new Vehicle is stored in Process Data at this step so that you may relate the
Vehicle to a Policy in the following step. Click the OK button to close the activity inspector. 
20. Double-click the Set Process Data activity to open
its activity inspector. Rename the activity to
Relate Vehicle to Policy. 

21. Use the Copy function to map
the policy_id Variable to the
Object ID of the Vehicle’s
related Policy. As the name of
the activity implies, this will
relate the newly-created
Vehicle object to the Policy
object represented by the
policy_id Variable. 
Click the OK button to close
the activity inspector.
Notice how the relationship is modelled in the Process Data tree. You can access the attributes of
the relationship as well as the related object. Copying an r_object_id value into the Object ID
attribute of the related object as you have done here is what creates a new relationship instance.
You cannot create a relationship and set it’s attributes in a single activity. Technically you could
map the start_date, end_date and notes Process Variables to the Policy relationship Start Date,
End Date and Notes attributes in this activity, and no error would be thrown at runtime, but the
values would not actually be saved.
22. Double-click the Set Process Data-1
activity to open its activity inspector.
Rename the activity to Set Relation
Attributes. 
23. Use the Copy function to map the
start_date, end_date, and notes
Variables on the left to the Start
Date, End Date and Notes
a t t r i b u t e s o f t h e P o l i c y
relationship on the right. 
 
Click the OK button to close the
activity inspector. 
 
 
You now have a Stateless Process that creates a new instance of your Vehicle Business Object in the
Concordant cabinet, relates it to a Policy and sets the attributes of the relationship. 

4.4 Add Vehicle Action Flow
As mentioned in the previous step, for the Policy you used a Create Page that captured the
information about the new policy before executing the Create Policy Data Service. For the
Vehicle however you want to capture the basic information about the vehicle, and if it is a
temporary addition to a policy you will capture additional information before executing the
Stateless Process that you configured in the last section to create the vehicle and relate it to
the policy. To accomplish the capturing of this information you will use an Action Flow.
1. Select the User Interface tab in the xCP Navigator panel,
expand the Business Object UI node, right-click on the Vehicle
Business Object and select New Action Flow from the context
menu.
2. In the New Action Flow dialog enter Create
Vehicle and Relate to Policy as the Label
and 3 for the Number of Steps. Click the
Select button (…) next to Data Contract and
choose Vehicle Create and Relate to Policy
from the pop-up dialog. Click the Finish
button to create the Action Flow. 
 
The number of steps in you action flow will
depend on how many pages of information
you want to capture.
3. An Action Flow consists of several components: a Model and one or more Step Pages.
The editors for all components open automatically when you first create an Action Flow.
 
Objective Configure an Action Flow containing rules for capturing Vehicle
information that will then be passed to the Vehicle Create and Relate to
Policy Stateless Process.
Concepts Action Flow - a reusable sequence of steps that an end user performs in
the application. You can define an action flow and reuse it in multiple
contexts. At runtime, the action flow presents end users with either a
single step or multiple steps to assist them in executing a business task.

4. Select the Layout tab of the Step 1 (Vehicle) Page editor
and start by adding a Column Box widget to act as the
container for all of the other widgets.
5. In the General tab of the Properties panel clear the Title value.
The heading My Column Box will be removed.
When working with the Column Box and Results List widgets you can select and set the
properties of the widget itself and the individual columns within the widget. It is not
always obvious once you have selected a column how to select the parent widget again
because if you click on the dotted border of the widget you only select the column. There is in fact
an invisible handle for the parent widget 2 pixels outside the dotted line. If you point the mouse
there and click you can select the parent.
6. By default column boxes are added with two columns. Right-
click on the first column and select Delete from the context
menu to leave just one column.
7. Add the widgets listed in the table below to the column box, setting their ID and Label as
shown.
8. For Make, Model, VIN and Year
set the Is Mandatory expression
to true from the Validation tab.
Type ID Label
Rich Text label N/A
Drop-down List make Make
Text Input model Model
Text Input vin VIN
Number Input year Year
Checkbox temporary Temporary

9. Configure the additional properties of the widgets as follows:
a. Select the Rich Text widget and on the
General tab replace the default Value with
the markup Enter the details of the
vehicle and click Next to act as a
header for the Step Page.
If you remove the Value of the Rich Text widget completely you will
see that it is possible to end up with widgets on a page that are not
visible. You can still select them however by clicking on the invisible
handle around the widget.
b. Select the Make Drop-down List widget and under
the Value section choose the Picklist Radio button
and select the Vehicle Make Picklist.
c. Select the Year Number Input widget and under
the Value section set the Data type as Integer.
d. Select the Temporary Checkbox widget and under
the Value section delete the Checkbox text value.
10. Select the Navigation tab of the editor. This is where you configure the rules for when the
Next button is enabled, and what the next page should be. You will enter an expression to
select the next page based on the value of the Temporary Checkbox. Under the Action
section select the Expression Radio button and click the Selector (…) button.
a. Select the Functions tab and choose the
ifThenElse function. You can filter the list
by selecting the Conditional group. Click
the OK button.

b. Select the expr part of the function if it is not
selected by default. Click the Selector (…) button
again.
c. Expand the Context Data tree to
locate the temporary widget on the
Step 1 Step page of the Action Flow.  
 
Select the Value from the right-hand
panel and click the OK button.  
 
The condition of the function must
return true or false but because the
value of a checkbox is already
boolean you do not need to add
anything else to the condition.
d. Select the resultIfTrue section of the function and replace it with an empty string
(two single quotes), but position the cursor inside the quotes.
e. The function should return a static string that is the system name of the next Step
Page to go to if the condition is true, which in this case is the second page. 
 
Click the Selector (…) button again and this time
choose the Step 2 node in the Context Data tree and
the Step 2 value in the right-hand panel. 
 
When you click OK the full system name of the Page
is inserted into the expression.

f. To reference the page you only need the final part of the string, so delete the
actionsflow.steps part. If you knew the system name of the page you could also
enter it directly without using the selector.
g. Finally replace the resultIfFalse section of the
function and enter the system name of the third
step, which is ‘create_vehicle_an_2’.
h. Save and close the Step 1 (Vehicle) editor.
11. Select the Layout tab of the editor for Step 2 and start by
adding a Column Box widget, removing the Title value and
deleting the first column as you did for the last one.
12. Add the widgets listed in the table below to the column box.
13. For Start Date and End Date, these values should be mandatory only if the temporary
checkbox is ticked on the first page. To configure this set the Is Mandatory expression to
actionflow.steps.create_vehicle_and_.widgets.temporary.value from the Validation
tab of each widget. This will equate to a boolean value.
the markup Enter the start and end
dates of the cover for this vehicle
and click Next to act as a header for
the Step Page. 
Type ID Label
Rich Text label N/A
Date-time Input start_date Start Date
Date-time Input end_date End Date
Text Area notes Notes

b. Select the Start Date widget and on the Style tab select a Date style of Date only.
c. Repeat the last step for the End Date widget, choosing a Date Style of Date only.
15. This page will always progress to the final page and so no further changes are needed.
Save and close the Step 2 (Vehicle) editor.
16. Select the Layout tab of the editor for Step 3. Add a Column Box
widget, remove the Title value and delete the first column as you did
previously.
17. Add the widgets listed in the table below to the column box. This page acts as a summary
page for the details of the action that will be carried out when the Finish button is clicked.
the markup Check the vehicle
details and click Add Vehicle to
finish to act as a header for the Step
Page.
b. Select the Year widget and on the
General tab set the Data type to Integer.
Type ID Label
Rich Text label N/A
Value Display make Make
Value Display model Model
Value Display year Year
Value Display vin VIN

c. Select the Make widget and on the
General tab under the Value section
enter the following expression for Initial
value. This is the selected value from
the Make Drop-down List on the first
step of the Action Flow. You can either
use the selector or type it directly:  
actionflow.steps.create_vehicle_and_.widgets.make.value
d. Repeat the last step for the Model, Year and VIN widgets, entering the following
expressions:
Model: actionflow.steps.create_vehicle_and_.widgets.model.value
Year: actionflow.steps.create_vehicle_and_.widgets.year.value
VIN: actionflow.steps.create_vehicle_and_.widgets.vin.value
When entering multiple expressions like this that are similar, often the quickest way is to
select the first one using the Selector and then copy the first part of the expression to the
clipboard (in this case actionflow.steps.create_vehicle_and_.widgets). For the subsequent
widgets you can just paste that part into the expression editor, and complete the last part
using the auto-suggest feature, beginning with a period.
20. The next thing you will do is configure the Action Flow Inputs (which will be the ID of the
policy that the vehicle is to be related to).
a. Select the Data tab of the Create Vehicle and
Relate to Policy editor for the Action Flow.  
 
 
 
 
b. Click the Add Entry button for the Action Flow
Inputs section.
c. On the General tab of the Properties panel change the
Name of the new value to policy. When you invoke the
action flow later you can pass in the ID of the policy that
the vehicle should be related to.

21. The final thing to configure is what happens when the user clicks the Finish button.
a. Select the Navigation tab of the editor, scroll
down to the Finish Button section and change
the Label of the button to Add Vehicle. Notice
that you can use an expression to set the label
of the Finish button if you want to.
b. In the Behavior section enter the following expression for the Enabled When value :
actionflow.executionContext.currentstepid=='create_vehicle_an_2'.  
 
 
 
 
 
 
This causes the Finish button to be disabled on every page apart from the last one. 
Note that the comparison is with the system name of the Step Page without the namespace.
It is easy to forget that within the context of an Action Flow, references to step pages do not
require the namespace.
c. Expand the Interactions pane of the Navigation tab and
select the Vehicle Create and Relate to Policy entry.
If you do not have the Stateless Process available as
an interaction it means you forgot to select it when
you first created the Action Flow. If this is the case
you can simply add it here and configure the Finish
Button’s Action property to call it.
d. Select the Inputs tab of the Properties
panel and expand the Variables node.
The list of Variables available as Inputs of the Stateless Process are based on the settings in
the Composite Service of the process. If you do not see the full list of variables here then
check that configuration in the process data dialog.

For each Variable enter the appropriate expression from the list below. You can
either type them or use the selector. Notice that for everything apart from the
policy_id the value comes from a widget on a step page, but for the policy_id the
value comes from the Action Flow Inputs. 
 
end_date: actionflow.steps.create_vehicle_an_1.widgets.end_date.value
make: actionflow.steps.create_vehicle_and_.widgets.make.value
model: actionflow.steps.create_vehicle_and_.widgets.model.value
notes: actionflow.steps.create_vehicle_an_1.widgets.notes
policy_id: actionflow.Inputs.policy
start_date: actionflow.steps.create_vehicle_an_1.widgets.start_date.value
vin: actionflow.steps.create_vehicle_and_.widgets.vin.value
year: actionflow.steps.create_vehicle_and_.widgets.year.value
When you have added the expressions the Inputs tab should look like this. 
The Action Flow that you have just configured will provide a wizard-like pop-up dialog that captures the
information about a Vehicle, and if the user checks the Temporary checkbox it then asks for the details of
the temporary cover to be provided. The final step of the wizard is a summary of the Vehicle details and if
the user clicks the Add Vehicle button the Vehicle Create and Relate to Policy Stateless Process will be
executed. 

4.5 Vehicle Real-Time Query
In order to list the vehicles that are related to a selected policy you will use another Real-Time
query, but the difference here is that you want to include information about the relationship
itself and not just the Vehicle.
1. Select the Data Services tab in the xCP Navigator panel, right-
click on Real-Time Query and select New Real-Time Query.
2. In the New Real-Time Query dialog enter Vehicles
related to a Policy as the Label. Select Business
Objects as the Primary model and then select
Vehicle. Click the Finish button to close the dialog
and create the query.
3. On the Dataset tab of the editor select Vehicle from the Context Data panel on the right
and add the Vehicle Make, Model, Year, VIN and Object ID attributes to the Output
Columns list by double-clicking on them.
For this query there is no need to return the hit count as there will never be many
vehicles related to a single policy.  
Objective Configure a Real-Time Query to return a list of Vehicles related to a Policy.

4. Now select the Policy relationship from the Context Data panel and add the Start Date,
End Date and Notes attributes to the Output Columns list. 
Notice that you have a choice of model that can be returned from the
query - either the Vehicle or the relationship between the Vehicle and
Policy. This selection will affect the default context menu that is used at
runtime in a Result List widget showing the data. For this tutorial you
want to choose Vehicle so that you can compose the context menu, but
if you chose the relationship then a system generated context menu would be used that allows you
to delete the relationship.
5. On the User Inputs tab of the editor, expand Vehicle > Policy > Policy in the Context Data
panel. Double-click the Object ID to add it to the User Inputs list. Verify that you’ve added
Policy.Object ID and not Vehicle.Object ID.
You have now configured a Real-Time Query that returns a list of Vehicle Business Objects from the
repository, filtered by the ID of the Policy to which they are related. The results from this query will be
shown when a user is looking at the details of a Policy. 

4.6 Updating the Edit Policy Page
4.6.1 Adding Vehicles to a Policy
The first step is to add a Button Widget to the Page that invokes the Action Flow.
1. Select the User Interface tab in the xCP Navigator, expand the Business
Object > Policy node and double-click the Edit Policy Page to open it.
2. Expand the Interactions pane on the Layout tab of the
Page editor. There should just be the Update Policy and
Session Parameters Data Services.
3. Click the Add button (the green cross) and select the Create Vehicle and Relate to Policy
Action Flow.
Note the different icon for each type of Interaction. Some are system generated and may have the
same name as one you create, and when you define a Stateless Process the system creates one
with the name you gave it and another called ‘Initiate Process <Name>’ so that you can initiate it in
a stateful way as well. In these cases it is possible to choose the wrong one.
4. On the Inputs tab of the Properties panel set the
value of the policy Input to be policy.id either by
typing or using the selector. This is how the
r_object_id of the Policy the user is currently
editing is passed into the Action Flow at runtime. 
 
 
Objective Bring the Action Flow, Stateless Process and Real-Time Queries together,
allowing a user to see and create Vehicles related to a Policy from the
Edit Policy page.
Concepts User Interface Event (UI Event) - enables you to configure a dynamic
application where the action of the end user determines what appears on
the screen. When a UI event occurs, the application can adjust the content
that appears on the page or execute a background service. xCP provides a
number of system events and custom events can be defined where more
complex rules are required.

5. Drag and drop a Button Widget onto the canvas next to the Save button.
 
6. Under the Basics section of the General tab of the Properties
panel, change the ID of the widget to add_vehicle and the Label
to Add Vehicle. 
7. Under the Action section choose Data service
instance from the Invoke drop-down list,
Create Vehicle and Relate to Policy-1 from the
Data service instance drop-down list and None
from the When done go to drop-down list. This
last setting will result in the Action Flow closing
and no changes being made to the page that it
was invoked from.
If you choose the Current page setting for the When done go to value that would cause the browser
to refresh the entire page and execute the Data Service again. The disadvantage of this approach
is that refreshing the page can have undesired results, such as changing the current Tab in a Tab
widget back to the first Tab. The better option is to use the UI Event framework to refresh the
Interaction that is linked to the appropriate Widget when the relevant actions have completed.
4.6.2 Displaying Vehicles Related to a Policy
The second step is to add a Results List Widget to the Edit Policy Page, and wire it to the Real-
Time Query defined earlier to list all the vehicles associated with the policy.
1. Go back to the Interactions pane and add the Vehicles
Related to a Policy. Make sure the data service is
selected. 

2. On the Inputs tab of the Properties panel check that the
Object ID Input has been automatically mapped to the
policy.id of the current policy instance. If it has not then
enter or select policy.id as the value. 
 
 
3. Under the Refresh section of the General tab of the Properties
panel enable the On page load checkbox for the data service. This
will cause the list to be updated automatically when the Edit Policy
Page is opened.
4. You also want the list to be refreshed after a new Vehicle is created, and for this you will
subscribe the Interaction to refresh when a UI Event is triggered.
a. On the Behaviour tab of the Properties panel click the
Add button in the Subscribe panel.
b. In the Subscribe dialog click Add
button to select a Behaviour
Trigger that will cause the query
to execute.
c. In the UI Event Mapping
dialog select the success
event for the Create Vehicle
and Relate to Policy-1 Data
Service Instance. Click the
OK button to save the
selection.  

d. Click the Finish button to save
the new subscription.  
 
This will cause the query results
to be updated automatically
when a new Vehicle is created
and related to the Policy.
In this example you only subscribe to one trigger event in order to refresh the query results. You
can actually add as many different triggers as you need using this mechanism.
5. Drag and drop a Results List widget onto the page between the attributes and the
buttons.
 
 
6. On the General tab of the Properties panel set the ID of the widget to vehicles, the Title to
Vehicles, and select Vehicles Related to a Policy from the Data service instance drop-
down list. Also de-select the Enable Drag And Drop checkbox as this is not displaying the
contents of a folder. Click OK on the confirmation dialog. 
 
 
 
 
 
When you select a data service instance for a Results List widget the columns of the
widget are updated to reflect the Outputs of the data Service, and by default a Column is
added for every Output value.
7. On the Style tab of the Properties panel set the Height of the
result list to be 5 rows. 
 

8. In addition to updating the columns a
Search button is added inside some
nested Column Box widgets, even if there
are no Input values to the source
Interaction.  
 
These unwanted columns and widgets can
be removed as follows.
a. Right-click on the Object ID column and select Delete from
the context menu to remove it from the result list. 
 
Remember that removing a column from the widget does
not remove the value from the underlying data
b. Select the Column Box widget that is outside the Search
grouping as shown here, right-click and select Delete
from the context menu to remove all of the widgets. 
 
 
 
 
9. The final page layout should look like the screenshot below. Save the changes and close
the editor.
Your Edit Policy Page will now show a list of Vehicles that are related to the Policy and the user will be able
to invoke the Create Vehicle and Relate to Policy Action Flow to add new Vehicles to the Policy. 

4.7 Testing the Application: Vehicle Creation and Policy Linking
Deploy the application and test that you can create vehicles and add them to a policy.
1. Close any open windows and click the Run Application button on the
toolbar to deploy and run your application.
2. When the deployment is completed, log in
to your application as the user that you
added to the Clerk Role.
3. The Policy Search Page loads and the list of policies will be
populated with those that were created earlier. Right-click on
one that has a future End Date and select Edit Policy from the
context menu.
4. Initially there should be no vehicles associated with the policy. Click on the Add Vehicle
button to launch the Action Flow for creating a new vehicle and relating it to a policy.
Objective Test the application by logging in and adding Vehicles to a Policy.

5. The action flow will open at the first page. Complete the action flow as follows:
a. Select a Make and enter values for the Model, Year, and VIN for the vehicle. Leave
the Temporary Checkbox unchecked. Notice that the Add Vehicle button is disabled
at this point. Click the Next button.
b. The final page of the Action flow opens. Click the Back button to go back to the first
page.
c. Now enable the Temporary checkbox and click the Next
button again.

d. When the second page opens select a Start Date and End Date and enter some text
in the Notes. Click the Next Button.
e. On the final page click the Add Vehicle button. The stateless
process will execute and create the Vehicle and relate it to the Policy.
When it is completed the action flow dialog closes and a
confirmation will appear at the top of the screen.
6. The Vehicles results list is updated and the new vehicle should show in the list. 
Remember that the first time you do something after deploying the application it will take longer to
complete. If you go ahead and create another vehicle it will complete much faster.

Before moving on with the tutorial you could go back and try the following. Don't forget to use Preview
mode to test the changes: 
1. Create a Context Menu for the Vehicle Business Object. 
2. Set the size of the Action Flow so that it doesn’t have so much white space. 
3. Add an expression to the Behavior of the Next button in the Action Flow so that the user cannot click
the button until the mandatory fields are populated.

5.0 Claims
Your application needs the ability to manage a Claim made against a Policy, and so in this
section of the tutorial you will add the artifacts necessary for the creation of claims.
5.1 Claim Status Picklist
To ensure data consistency a picklist will be used to control the valid states of a claim.
1. Select the Object Models tab in the xCP Navigator panel, right-click on
Picklists and select New Picklist.
2. In the New Picklist dialog enter Claim Status as the
Label and click the Finish button.
3. In the Basics tab select Integer as the Data type.
4. Select the Entries tab and add the entries listed in the table below (pressing tab will
automatically add new rows).
The Picklist that you have just created will be added to the Claim Model in the next step to reflect the
current status of a Claim. 
Objective Configure a Picklist containing the possible states of a Claim.
Label Value
Processing 0
Pre-Approved 1
Approved 2
Denied 3
Getting Started with xCP 2.2 - 5.0 Claims 82

5.2 Claim Folder
Whenever documents are required a Folder model is usually the best type to choose as you get
out of the box functionality to support the management of documents such as drag and drop
support. It also makes it easier to administer the system from tools such as Documentum
Administrator. Because this folder is handling claim information for a vehicle and a specific
policy the folder will also have relationships defined to these models. 
Folders and select New Folder.
2. In the New Folder Model dialog enter Claim as the
3. On the Basics tab of the editor, enter
the string ‘/Concordant’ for the
Default location. 
 
The Inherits from value of Base Folder
refers to the Documentum dm_folder
object type.  
 
 
 
 
 
 
4. Under the Runtime Features section enable the User may
comment on the folder object checkbox so that you can
enable commenting later on.
Objective Create the Model that represents a Claim against a Policy. The Claim will
act as a container for documentation related to the Claim.
Concepts Folder - Defines a folder that contains objects such as Business Objects,
Content objects, and other Folders.

5. On the Attributes tab of the editor add each of the attributes listed in the table below. Be
careful to select the right data type and remember that Claim Status is dragged from the
Picklists section and not Data Types.
6. Configure a relationship between the Claim and Policy models as follows.
a. Drag the Policy model from underneath the Relationships section of the Types
panel to the Attributes of the Claim.
b. On the General tab of the
Properties panel configure the
relationship as Two-way and select
the Many to One option to indicate
that a policy can have many claims
but that a claim can only be
related to a single policy. 
Incident Date Date-time
Incident Location String
Amount Float
Vehicle in Motion Boolean
Claim Status Picklist

7. Repeat step 6 to relate the Claim to the Vehicle model using the same Relationship Type
of Two-way and Many to one to indicate that a claim can only be related to a single
vehicle, but that a vehicle can be involved in many claims. 
 
 
 
 
 
 
 
 
 
 
The Claim Folder that you have just configured will be used to hold the documents related to a Claim
against a Policy and the Claim will have a Vehicle related to it. 

5.3 Stateless Process for Creating and Relating Claims
Similar to the creation of a vehicle, the default data service that is available for the creation of
a claim cannot do all that you need it to, and so you will configure another stateless process
that will create the claim and relate it to an existing policy and vehicle.
1. Select the Processes tab in the xCP Navigator panel and click
2. In the New Process dialog enter Claim Create and Relate
to Policy as the Label, enable the Process can run in
stateless mode checkbox and click the Finish button.
3. Click the Process Properties toolbar icon in the editor to open
the Process Properties dialog.
4. Select the Data tab in the Process Properties dialog,
select the Packages node and click the Add button.
5. Under Package Definition enter claim for the Name and choose Claim for the Type. Make
sure the checkbox This is a mandatory package is not enabled. The package will be
created by the process, and if this is left checked it will not be possible to start the
process. 
Objective Configure a Data Service using a Stateless Process to create a Claim and
relate it to a Policy and Vehicle.

6. Select the Process Variables node and add each of the process variables listed below,
making sure to set the right Type for each one.
7. Select the Composite Service tab in the Process Properties dialog. Enable the Use as
Input checkboxes for each of the Variables and click the OK button.
8. Expand the Content node in the Activities panel on the right of the editor.
9. Drag and drop a Create activity and a Set Process
Data activity onto the process model canvas. The
Create activity will be used to create a new
instance of the Claim model and the Set Process
Data activity will relate the new claim to an
existing policy and vehicle. 
Variable Name Type
amount Float
incident_date Date-time
incident_location String
vehicle_in_motion Boolean
vehicle_id String
policy_id String

10. Click the Straight flow toolbar button to enter line drawing mode.
11. Draw flow lines between all three activities. You can
select multiple activities and right-click on them to
access alignment options from the context menu.
12. Double-click the Create activity to open the activity inspector. Change the activity’s name
to Create Claim and select the Folder path radio button under the section Get Destination
Folder by. To set the model to be created click the Select button, choose the Claim model
from the Select Model dialog.
13. Click the Next button to open the second page of the Create tab. Using Copy functions
map the amount, incident_date, incident_location and vehicle_in_motion Process
Variables to the Amount, Incident Date, Incident Location and Vehicle in Motion attributes
of the new Claim. You can refer back to section 4.3 if you need to refresh you memory on
how to use the mapping screen.
Notice that you do not need to do anything to set a value for the Claim Status attribute, because an
Integer attribute will automatically have a default value of 0 (Processing). 

14. Add another Copy function and connect it to the Destination folder path [0] node under
Create. Double-click the function to open the editor, add a parameter and enter a value
of /Concordant (without quotes) as the value, to specify where the claim should be
created. Click the OK button to close the function editor. 
15. Finally add another Copy function and map the Process Data > Execution Data >
workflow > id value to the Name of the new claim. For the purposes of this application,
the name of the claim doesn’t matter and so you are using an existing value that will be
unique for every claim created.
It is important to note that the Destination folder path[0] attribute has a red asterisk next to it
denoting that it is mandatory, and that the Name does not. However at runtime an error will be
thrown if you do not assign a name to newly created objects.
16. Click the Next button to advance to the Output Message Mapping page of the Create tab.
Add another Copy function and use it to connect the output ID value of the activity (the
newly created object) to the Object ID attribute of the claim Package. Click the OK button
to close the activity inspector.

17. Double-click the Set Process Data activity to open its activity inspector. Rename the
activity to Relate Policy and Vehicle to Claim and use the Copy function to map the
policy_id Variable to Packages > claim (Claim) > Policy > Policy (Policy) > Object ID.
18. Add another Copy function to map the vehicle_id Variable to Packages > claim (Claim) >
Vehicle > Vehicle (Vehicle) > Object ID. Click the OK button to close the activity inspector.
Make sure you map the vehicle_id to the Vehicle related to the Claim and not the one related to the
Policy that is related to the Claim!
19. Save your changes and close editor.
You now have a Stateless Process that will create a new instance of your Claim Folder in the Concordant
cabinet and relate it to a Policy and a Vehicle. 

5.4 Create Claim Action Flow
Another action flow will be used to manage the capture of the claim information and the
initiation of the stateless process that actually creates the claim.
the Folder UI node, right-click on the Claim folder and select New
Action Flow from the context menu.
In the Content UI & Folder UI nodes you will see
system defined models for Base Content & Base
Folder. These are the Documentum dm_document
and dm_folder models for which you can define your
UI artifacts.
2. In the New Action Flow dialog enter
Create Claim and Relate to Policy as
the Label and 1 for the Number of
Steps. Click the Select button (…) next
to Data Contract and choose the
Claim Create and Relate to Policy
stateless process. Click the Finish
button to create the action flow. 
 
Two editors will open for the Step 1
Page and the Model of the Action
Flow.
3. Select the Data tab of the Create Claim and Relate to Policy editor. Click the Add Entry
button to add a new Input. From the General tab of the Properties panel for enter a
Name of policy and then choose the Model radio button and select Policy as the model.
Using a model like this instead of a basic data type gives you access to all of the
attributes of the policy object instance that will be passed to the action flow. 
 
 
 
 
 
 
 
Objective Configure an Action Flow containing rules for capturing Claim information
that is then passed to the Claim Create and Relate to Policy Stateless
Process.

4. Add a second Input value called vehicle_id of type
String so that when the action flow is invoked you
can pass it a pre-selected vehicle from the Edit
Policy page.
 
5. Select the Layout tab of
the Step 1 (Claim) editor.
Add a Column Box widget
that will act as a container
for the other widgets.
6. Right-click on the first column and select Delete from the context
menu to remove it as you only need a single column. 
7. Select the Column Box widget again and on the General tab of
the Properties panel remove the Title value so that the title of
the widget is removed.
8. Add the widgets listed in the table below to the column box and configure the General
properties as shown. The page should look like this screenshot.
9. Configure the Properties of each widget as follows. Note that you will not make any of
these values mandatory for this tutorial so that you can enter invalid data. Later in this
section you will configure the display of a custom error message for when this happens.
Type ID Label
Date-time Input incident_date Incident Date
Text Input incident_location Incident Location
Number Input amount Amount
Drop-down List vehicle Vehicle
Checkbox vehicle_in_motion Vehicle in Motion

a. Select the Incident Date widget and on the Style tab under the Format section
change the Date style from Date and time to Date only.
b. Select the Amount widget and on the General tab under the Value section select a
Data type of Float. 
c. The Vehicle drop-down list widget will list the
vehicles related to the policy so first click the
Add button on the Interactions pane and
select the Vehicles Related to a Policy query. 
d. On the General tab of the Properties panel for the query under the Refresh section,
enable the On page load checkbox so that the list will be populated when this step
loads.
e. On the Inputs tab of the Properties panel for the query change the expression for
Object ID to be the ID of the policy that
is passed to the action flow using the
expression  
 
actionflow.Inputs.policy.id
Sometimes xCP Designer will automatically set Input values for Interactions, but it does
occasionally get it wrong. The Problems panel normally highlights incorrect settings for you.

f. Now select the Vehicle widget and on the General tab of the Properties panel under
the Value section set the Initial value expression as actionflow.Inputs.vehicle_id.
This setting ensures that if a vehicle_id value is passed to the action flow then it will
be the default selection in the list of vehicles.
g. Just below the Initial value expression select
the Data service instance radio-button and
select Vehicles Related to a Policy from the
drop-down list. Finally select Object ID as the
Value and VIN as the Display. The result of this
setting will be that the Vehicles widget will be
populated with all vehicles related to the policy. 
h. Finally select the Vehicle in Motion widget and on the General tab of the Properties
panel enter true in the Initial value expression to make sure the checkbox is ticked
by default.
i. Just below the Initial value expression clear the Checkbox text value so that there is
no additional text in the widget.  
10. Select the Navigation tab of the Create Claim and
Relate to Policy editor and change the Label of the
Finish Button from Finish to Create Claim.

11. Stay on the Navigation tab and expand the Interactions pane.
Select the Claim Create and Relate to Policy entry.
12. For this action flow you will configure custom success and error messages to be displayed
when the action flow completes.
a. On the General tab of the Properties panel enter the following expression for the
Success Message:
'Claim created for ' + actionflow.Inputs.policy.object_name + ' and
vehicle ' + actionflow.steps.create_claim_and_re.widgets.vehicle.label
b. And then enter the following expression for the Error Message (you can copy and
paste the first expression and change the first part of the text) :
'Unable to create claim for ' + actionflow.Inputs.policy.object_name + '
and vehicle ' + actionflow.steps.create_claim_and_re.widgets.vehicle.label
13. Select the Inputs tab of the
Properties panel and expand the
Variables node.  
 
 
 
 
 
 
For each Variable enter the appropriate expression from the list on the next page. You
can either type them or use the selector.  

Notice that for everything apart from the policy_id the value comes from a widget on the
step page. The policy_id value comes from the action flow Inputs.
 
amount actionflow.steps.create_claim_and_re.widgets.amount.value
incident_date actionflow.steps.create_claim_and_re.widgets.incident_date.value
incident_location actionflow.steps.create_claim_and_re.widgets.incident_location.value
policy_id actionflow.Inputs.policy.id
vehicle_id actionflow.steps.create_claim_and_re.widgets.vehicle.value
vehicle_in_motion actionflow.steps.create_claim_and_re.widgets.vehicle_in_motion.value 
When you have added the expressions the Inputs tab should look like this. 
 
 
 
 
 
14. Save your changes and close the action flow editors.
The action flow that you have just configured will provide a pop-up dialog that captures the information
about a Claim and if the user clicks the Add Claim button the Claim Create and Relate to Policy Stateless
Process will be executed. 

5.5 Claim Real-Time Query
In order to list the claims that are related to the policy being viewed, you will use another Real-
Time Query.
1. Select the Data Services tab in the xCP Navigator panel, right-click
on Real-Time Query and select New Real-Time Query.
2. In the New Real-Time Query dialog
enter Claims Related to a Policy as
the Label. Select Folders as the
Primary model and then select
Claim. Click the Finish button to
close the dialog.
3. Select the Dataset tab of the editor and
double click the Incident Date, Amount,
Vehicle in Motion, Claim Status and
Object ID fields under the Context Data
panel to add them to the Output Columns
list.  
 
Remember that adding Object ID is good
practice in case it needs to be passed to
an interaction or widget later.
4. Select the User Inputs tab. Expand the Context Data to locate
Claim>Policy>Policy. Double-click Object ID to add it to the User
Inputs list. Verify that you’ve added Policy.Object ID and not
Claim.Object ID.  
 
This will be used to filter
the results based on the
policy that the claims are
related to.
5. Save your changes and close the editor. 
You have now configured the Real-Time Query that returns a list of Claim Folders for a Policy that will be
shown when a user is looking at the details of a Policy. 
Objective Configure a Real-Time Query to return a list of Claims related to a Policy.

5.6 Updating the Edit Policy Page
5.6.1 Adding Claims to a Policy
The first step is to rearrange the layout of the Edit Policy page and then add a new Button
Widget that invokes the action flow for creating new claims.
1. Select the User Interface tab in the xCP Navigator panel and double-
click the Edit Policy page under Business Object UI > Policy to open
the page for editing.
2. Expand the Interactions pane on the Layout tab of the editor. Click the Add button and
select the Create Claim and Relate to Policy action flow.
 
 
 
 
 
Make sure you select the correct Data Service. You need the choose the Action Flow and not the
Stateless Process. The icons allow you to differentiate between the two.
3. On the Inputs tab of the Properties panel set the value of the policy to be policy (you do
not need to add the .id part to the expression) and vehicle_id to be
widgets.vehicles.selected_row.id either by typing the expressions or using the selector.
This is how the r_object_id of the Policy the user is currently editing and any pre-selected
vehicle are passed into the action flow at runtime.
4. Before adding another Results List onto the page to display a list of claims related to the
policy and the button to add a claim, to make the page look nicer you will add a Tab
widget and rearrange the other widgets on the page as follows:
Objective Bring the Action Flow, Stateless Process and Real-Time Queries together,
allowing a user to see and create Claims related to a Policy from the Edit
Policy page.

a. On the Layout tab of the editor start by dragging a Tab Group widget onto the page
between the attributes and the Vehicles results list widget. When dragging a widget
the green line shows where it will be placed.
b. Rename the first two tabs as Vehicles and Claims
and delete the third. You rename the tabs from
the General tab of the Properties panel like other
widgets.
c. Select the Vehicles tab and drag the Vehicles results list
widget up into it. Clear the Title value from the General
tab of the Properties panel for the widget so that the
heading Vehicles is removed. Now that you have the list
in a tab called Vehicles the heading is not needed.
d. The final thing to rearrange is to drag the Add Vehicle button
widget into the same tab as the results list, just below the list.
It should be aligned to the left of the tab automatically.
5. Now select the Claims tab and drag a new Button widget into the tab.
This will be configured to invoke the action flow that lets the user create
a Claim.
6. Under the Basics section of the General tab of the Properties
panel change the ID of the button to add_claim and the Label
to Add Claim.
7. Under the Action section choose Data
service instance from the Invoke drop-down
list and from the Data service instance drop-
down list select Create Claim and Relate to a
Policy-1. Select None from the When done
go to drop-down list as you will use a UI
Event to update the list of claims. 

5.6.2 Displaying Claims Related to a Policy
The second step is to add a Results List widget to the page, and wire it to the Real-Time Query
defined earlier to list all the claims associated with the policy.
1. Expand the Interactions pane on
the Layout tab of the editor and
add the Claims Related to a Policy
Real-Time Query.
2. Under the Refresh section of the General tab of the Properties
panel check the On page load checkbox to force the query to run
when the Edit Policy page is opened.
3. On the Inputs tab of the Properties panel check that the
Object ID Input has been automatically mapped to the
policy.id of the current policy instance. If it has not then
enter or select policy.id as the value.
4. You also want the list to be refreshed after a new Claim is created, and for this you will
subscribe the Interaction to refresh when a UI Event is triggered.
a. On the Behaviour tab of the Properties panel click the
Add button in the Subscribe panel.
b. In the Subscribe dialog click Add
button to select a Behaviour
Trigger that will cause the query
to execute.
c. In the UI Event Mapping
dialog select the success
event for the Create Claim
and Relate to Policy-1 Data
Service Instance. Click the
OK button to save the
selection.  

d. Click the Finish button to save
the new subscription.  
 
This will cause the query results
to be updated automatically
when a new Claim is created and
related to the Policy.
5. Drag a Results List widget onto the Claims tab just above
the Add Claim button.
6. Under the Basics section of the General tab of the Properties panel change the ID of the
widget to claims, but leave the Title empty. Select Claims Related to a Policy for the value
of Data service instance under the Data section. Accept the warning that the selection
cannot be changed.
7. The widget will be updated with the correct columns and a Search button. Unwanted
columns and the Search button can be removed. First right-click on the Object ID column
and select Delete to remove it. Then select the Column Box widget that is outside the
Search grouping as shown here, right-click and select Delete to remove all of the widgets.
8. On the Style tab of the Properties panel set the Height of the
result list to be 5 rows. 
 

9. The final page layout should look like this screenshot. The Vehicles tab should also have
a results list and button widgets.
10. Save the changes and close the editor. 
 
 
Your Edit Policy Page will now show a list of Claims that are related to the Policy and the user will be able
to invoke the Create Claim and Relate to Policy Action Flow to add new Claims to the Policy. 

5.7 Claim Management User Interface
5.7.1 View Claim Page
The first thing you will create is an Instance Page to view information about a Claim.
1. Select the User Interface tab in the xCP Navigator panel, Expand
Folder UI, right-click on Claim and select New Page.
2. In the New Page dialog select the
View Claim radio button and the
Label of the page will be updated
automatically. Click the Finish
button.  
 
Because a Claim is a folder the
page is created with a results list
widget to show the contents of the
folder, and a series of buttons that
provide basic functionality for
creating documents, importing files
etc. as shown below
 
If you expand the Interactions pane you will also see the underlying Interactions that
support the functionality. 
 
Objective Configure the User Interface artifacts that allow users to view and
execute actions against Claim Folders.

3. By default the generated page does not display the custom
attributes that you added to the Claim model, such as amount and
incident date, and so you will add these first. Start by adding a
Column Box widget at the top of the page that will act as a
container for the other widgets.
4. Select the Column Box widget and on the General tab of the Properties panel remove the
Title value so that the title of the widget is removed.
5. Add four Value Display widgets to the first column of the column
box widget, configuring their properties as shown below on the
General tab of the Properties panel: 
 
 
Incident Date 
Set the ID to incident_date, the Label to Incident Date, the Data-type to Date-time and
the Value expression to claim.incident_date 
 
Incident Location 
Set the ID to incident_location, the Label to Incident Location, the Data-type to String and
the Value expression to claim.incident_location 
 
Amount 
Set the ID to amount, the Label to Amount, the Data-type to Float and the Value
expression to claim.amount 
 
Vehicle in Motion 
Set the ID to vehicle_in_motion, the Label to Vehicle in Motion, the Data-type to Boolean
and the Value expression to claim.vehicle_in_motion 
When finished the Page should look like this screenshot. 

6. To add additional context to the page you will add a small map showing the location of the
incident using the Google Maps API as follows:
a. Add a Value Display
widget to the second
column of the column
box widget.
b. On the General tab of the Properties panel set the ID to
location_map and the Label to Location Map .
c. Under the Value section change the
Data type to HTML. If you forget to do
this you will not see a map at runtime,
just HTML code.
d. In the Value expression enter the HTML markup shown below. The expression field
is too small to see the whole expression and
so you may prefer to open the expression
editor dialog by clicking on the popup button
above the text entry box. 
 
'<img src="http://maps.googleapis.com/maps/api/staticmap?
sensor=false&size=200x100&zoom=15&center=' + claim.incident_location +
'&markers=' + claim.incident_location + '"/>' 
 
This expression adds an image
element onto the page pointed at
the Google Maps API, passing the
value claim.incident_location to
the center and marker parameters.
 
5.7.2 Claim Context Menu
The final thing to configure before testing the application again is a Context Menu for the Claim
so that the user will be able to right-click on a claim and execute actions against it.

expand the Folder UI node, right-click on Claim and select
Create Context Menu. 
 
The context menu is created with a set of default items, based
on what artifacts already exist for the Claim folder. Unwanted
items can be deleted, which is what you will do.
 
2. Right-click on the Create Claim and Relate
to Policy item in the list and select Delete
to remove it. Remove items, including the
spacers, until you are just left with View
Claim, Import… and Delete.
3. Select the Import… item and review the General tab of the
Properties panel. Confirm that the Invoke Action Flow on
Drag _Drop checkbox is checked. This will allow you to
drag documents onto the list of Claims on the Edit Policy
Page to import them. 
4. You also need to configure that after deleting a Claim the application should redirect back
to the Edit Policy instance page that was open. This is different to the Delete Context
Menu item for the Policy which redirected to an application page and did not need
changing. 
 
To do this select the Delete item and under
the Action section of the General tab of the
Properties panel, choose the Page radio
button and and select Edit Policy as the
Page. For the Object ID field enter
sessionparameters.cia.last_policy_id
for the expression, which is the value from
the cookie that is created whenever the
Edit Policy Page is opened. 
 
 
You now have the User Interface artifacts configured that lets a user view a Claim and allows them to
right-click on an existing Claim from the Edit Policy Page and choose from appropriate actions for a Claim. 

5.8 Testing the Application: Create and View Claims
Deploy the application and test that you can create claims for a policy, and that the custom
success and error messages are working.
2. When deployment is completed,
log in to your application as the
user that you added to the Clerk
Role. The Policy Search page
loads and the list of Policies will be
populated with those that were
created earlier. Right-click on one
that has a future End Date and
select Edit Policy from the menu.
3. Select the Claims tab on the
Edit Policy Page. The list of
Claims should be empty initially.
4. Click the Add Claim button. The Add Claim action flow will open requesting details about
the claim. Enter details for the Incident Date, Incident Location and Amount. Select a
Vehicle from the drop-down list. The list of vehicles should match those related to the
policy. By default the Vehicle in Motion Checkbox is checked to indicate that the vehicle
was moving at the time of the incident. 
Objective Test the incremental changes you’ve made to the application by creating
Claims for the Policies and Vehicles already in your system.

5. Click the Create Claim button to create
the claim and relate it to the policy. You
should see your custom success
message pop up when the dialog closes.
6. When the action flow closes
the list of Claims should
refresh to show the new claim,
with the Claim Status set to
Processing by default.
Notice that the Incident Date value for a Claim is automatically rendered as a hyperlink to the View
Claim page. xCP will always try and render the first column of a Results List as a hyperlink like
this if possible. You can override the default Page through the Context Menu for an Object Model.
7. Click the Add Claim button again, and this
time enter details for the claim but do not
select a vehicle.
 
 
 
 
8. Click the Create Claim button to create the claim. This time you will see your custom
error message as there is no vehicle selected. If you click the arrow next to Details you
will see the technical error message behind it to help in troubleshooting.
Click Cancel to close the action flow without creating a claim.
9. Select the Vehicles tab and choose a vehicle from the list. If a
vehicle is selected when creating a new claim it should be the default
value in the action flow.

10. Select the Claims tab again and click the Add Claim
button. This time when the action flow loads the Vehicle
drop-down list should show the vehicle that you had
selected.
11. Either finish creating the claim or click the Cancel button to go back to the policy.
12. To make sure your context menu for claims is working,
right-click on one of your claims and select View Claim to
open the View Claim page. You can also click on the
Incident Date value which is rendered as a hyperlink to the
same page.
If you select the Import… menu option the standard Import Action Flow will launch, but until you
have configured some Content Models later in this tutorial you cannot actually import anything.
13. Whether you open it from the hyperlink or the menu, the View Claim page should load
showing the details about the claim along with a map showing the location of the
incident. The only action buttons that can be used properly at this point without further
configuration are New Folder and Delete, although that will not redirect correctly after
deleting the claim.
If the map does not appear it may be that you do not have an internet connection. If you do have
an internet connection then check the expression on the Value Display widget.

14. Go back to the Policy Search page and edit a policy that
has a claim. Select a claim, right-click and select Delete.
15. A confirmation dialog should appear and if you click the Yes button the claim is deleted
and the list of Claims on the Edit Policy page is updated to reflect the change.
 
1. Change the layout of the View Claim page to improve the look and feel of it 
2. Set the size of the action flow so that it doesn’t have so much white space. 
3. Add an expression to the Behavior of the Create Claim button on the action flow so that the user
cannot click the button until the mandatory fields are populated.

6.0 Claim Handling Process
The next business requirement that you will implement is to add a business process for
handling the review and approval or denial of a claim.
6.1 Repository Configuration: Work Queue
While most system configuration is done using xCP Designer, Work Queues and the related
items are still configured through Documentum Administrator. The URL for Documentum
Administrator will look like this: http://<Server>:<Port>/da
6.1.1 Queue Admin Access
Depending on how your repository has been set up your administrator account may not have
access to the Queue Management function. Only users that are members of the system role
queue_admin can manage Work Queues. To check, and set it up if required, follow these
steps.
1. Log on to Documentum Administrator with an
administrative account (typically dmadmin).
Navigate to:
 
Administration > User Management > Roles
2. Double click on the queue_admin role to see the members of the role.
You may need to filter the list of select a different results page to
locate this role.  
Objective Configure the repository to support the use of Work Queues.
Concepts Work Queue - lists all the process tasks which are waiting to be processed
by task processors. To access a work queue, a task processor has to be a
member of the queue. Once a user is an active member of the work
queue, he can start to work on pending tasks. Based on their role, they
can access the work queue to cherry pick some tasks and complete them
or let the system decides which tasks are going to be assigned to them. At
any time, a work queue manager can assign and reassign tasks to the
appropriate worker.
Getting Started with xCP 2.2 - 6.0 Claim Handling Process 111

3. If the role is empty or does not contain your
administrator user then continue with the steps below.
if your user is in the list of role members then proceed
to the next section of the tutorial.
4. Select Add Member(s) from the File menu.
5. In the Choose a user/group dialog search for your administrator user, select them and
add it to the role by clicking the Add button in the middle of the screen. Click the OK
button to save the change.
6. Log out and log back in again and look for the Work Queue Management node. You may
need to restart the Web Server where Documentum Administrator is running for your
changes to take effect.
If you do not configure the Work Queue before deploying the application you will get an error because the
xMS service will check that referenced Work Queues exist before deploying. That is why you have
configured the Queue now in Documentum Administrator.
The configuration you have just completed is necessary so that your Administrator user can complete the
next section where the Work Queues are configured.
6.1.2 Claims Work Queue
You will now configure the repository to support the Work Queue.
1. Log on to Documentum Administrator with an administrative
account (typically dmadmin). Navigate to Administration > Work
Queue Management > Policies > Work Queue Policies.

2. Select New > Work Queue Policy
from the File menu.  
 
 
3. In the Create New Work Queue Policy dialog specify the following values and click the OK
button to create the policy.
A work queue policy contains the logic that the system uses to track, and manage tasks in the
work queue. This logic enables the system to assign an initial priority, and age the priority of the
task based on different values you set up in the policy.
4. Navigate to Administration > Work Queue Management > Work
Queues.
5. Select New > Work Queue
Category from the File menu.
6. In the Create New Work Queue Category dialog
enter cia for the Name (the namespace you used
for your application) and Concordant Insurance
Queues for the Description. Click the OK button
to create the Work Queue Category.
Queue categories are like folders in which you organise your work queues. Categories can be
designed to resemble your business model’s hierarchy enabling you to drill though different
categories to locate your work queue in a logical representation of your organisation.
Setting Value
Policy Name cia
Threshold 100
Max Priority 1
Initial Priority 0
Increment Priority 0
Percent Quality Check 0

7. Double click to open the cia work
queue category, then select New
> Work Queue from the File
menu.
8. In the Create New Work Queue dialog
enter claims for the Name. Check
that the Policy Name drop-down list
has the value cia selected and click
the OK button to create the Work
Queue.
9. Click on the 0 Users link for the Work Queue.
10. Select Add Member(s) from the File menu.
11. Double-click the queue_manager role to select
members of that role directly.
12. Double-click the queue_admin role to select the
members of that role directly.

13. Select the user directly
and add them to the
Queue by clicking the
Add button in the
middle of the screen.
Note that it is possible to add the queue_advance_processor, queue_manager and
queue_processor groups as members of the queue, and then the members of those groups will be
treated as members of the queue. However, when debugging a process only users added directly
to the queue can be used for testing.
14. Click the OK button to save the changes. Log out of Documentum Administrator.
The repository has now been configured with a Work Queue where tasks related to the handling of Claims
can be held for processing.

6.3 Work Queue Parameter
In order to reference a queue from within a process a Parameter is required that defines the
queue name.
Parameters and select New Parameter.
2. In the New Parameter dialog enter Claims Work Queue
as the Label and select Work queue as the Type. Click
the Finish button to close the dialog.
3. In the editor enter claims as the Value, which is the
name you gave the Work Queue created in the
previous section.
The Work Queue Parameter will let you reference a Work Queue in the Process without hardcoding the
value. This means that if you wanted to change the name of the Work Queue in the repository you could
just update the Parameter at runtime without having to re-deploy the application. 
Objective Configure a Work Queue Parameter that references the Work Queue in
the repository.
Concepts Parameter - functions as a variable throughout an application. When you
create a parameter, you define its type and optionally specify a default
value. Parameter values can be overridden at deployment time and
application runtime. One use of Parameters is to ease the deployment of
an application to different environments (development, testing,
production, etc), where certain configuration items can be specified as
Parameters so that they can easily be redefined from one environment to
another.

6.4 Claim Handling Process
6.4.1 Process Configuration
In this section you will create a two step process containing Work Queue Tasks for processing of
the claim. A simple condition will be used so that if the first reviewer approves the claim, then
a second reviewer is asked to review it.
1. Select the Processes tab in the xCP Navigator panel
and click the New Process button.
2. In the New Process dialog enter Claim Processing as
the Label and leave the checkbox Process can run in
stateless mode unchecked. Click the Finish button to
create the process.
3. Click the Process Properties toolbar icon in the editor panel to open
4. Select the Data tab and add the following packages. There is no technical requirement to
add the policy and vehicle packages here. They are simply being added to more easily
expose them to the claims agent who will be interacting with the workflow.
Objective Configure a Process to handle the review and approval of new Claims.
Concepts Stateful Process – a process whose state is maintained in the repository.
Any processes which require manual tasks (as opposed to automatic
tasks) must be defined as stateful.
Process Debugger - allows you to test the design of a process model,
detecting, and diagnosing errors before you deploy the process to a
production environment. Debugging the process saves you time because
you can resolve problems during the design phase of an end-user
application, instead of troubleshooting problems at runtime.
Package Type Mandatory
claim Claim Yes
policy Policy No
vehicle Vehicle No

5. Next add a single Process Variable called response of type Integer. Ensure your Process
Data looks like the following and then click the OK button to close the dialog.
6. Add two Work queue task activities, a Decision Split activity and a Join
activity to the canvas and draw flow lines between them. Your process
should match this screenshot. You can use the Multi-Segment Flow
line to make it look nicer. The Work queue task activity is in the Task
group of the Activities panel
and the Decision Split and
Join activities are in the Flow
group.
7. Double-click the Work queue task
activity to open the Activity Inspector
dialog. Change the Name of the activity
to First Approval and for the Instruction
enter the text Please review the claim
and decide whether to Approve or Deny
the claim.
8. Select the Work queue tab, choose the Work queue radio button and click the Select
button to select which work queue the task will be assigned to at runtime as follows:
a. Select Work queue from a Parameter from the
first page of the Select Work queue dialog. Click
the Next button. 

b. Select Claims Work Queue which is the Work
Queue Parameter that you configured earlier.
Click the Finish button. If you click the Next
button you can assign skills required to complete
this task, but this tutorial does not cover that
topic.
9. Click the OK button to close the Activity Inspector dialog.
10. Double-click the Work
queue task-1 activity to
open the Activity Inspector
dialog. Change the Name
to Second Approval and for
the Instruction enter the
text Please review the
claim that has been pre-
approved and decide
whether to Approve or Deny
the claim.
11. Select the Work queue tab, choose the Work queue radio button and click the Select
button to choose the Claims Work Queue as the Work queue
value that the task will be assigned to as you did for the first
activity. In this tutorial you assign both manual tasks to the
same queue. In practice you would probably configure
different queues for the different approvals and assign
different users to each queue.
13. Double-click the Decision Split
activity to open the Activity
Inspector dialog. Change the
Name to Pre-Approved? then
click the Select button and
change the Perform as value to
Repository Owner.
The setting of Repository Owner as the performer of the Decision Split is not essential, but it is
common practise to run automatic steps like these as Repository Owner so that user permissions
do not prevent them from completing.

14. Select the Transition tab and pick Select next
activities based on conditions from the When
this activity completes drop-down list.
Configure the conditions as follows:
a. Double-click the first row in the condition builder (labelled if).
b. In the Edit Rule dialog enter the expression process.Variables.response==1 for
the If condition value and choose
Second Approval as the Then
transition value. 
 
If the user approves the claim the
response value will be 1, and so the
process will route the claim to the
Second Approval activity. 
 
Click the OK button to save the rule.
c. Double-click the second row in the condition builder (labelled else).
d. In the Edit Rule dialog select Join as
the Then transition value. Click the
OK button to save the rule.
e. The Transition condition should look like the following screenshot.

16. Finally double-click the Join
activity to open the Activity
Inspector dialog. Change the
Name to Review Completed
then click the Select button
and change the Perform as
value to Repository Owner.
17. Select the Trigger tab and choose the This number
of input flows selected radio button. The number of
possible input flows should change to 1, meaning
that this activity will start if the claim is approved by
the second approver or denied by the first.
When configuring Processes you can choose to version them from the context
menu in the xCP Navigator panel. When versioning a process all data services
and pages will also be versioned. Process versioning should be done carefully
and is most relevant when updating an application that has already been
deployed to a production environment.
6.4.2 Process Debugging
Now that you have configured the process you can use the Process Debugger to test the logic
of the Decision Split condition and the Join trigger. In order to debug a process Designer will
first connect to a Documentum repository.
1. Select the First Approval activity and click
the Toggle Breakpoint button on the
toolbar to set a breakpoint on the activity.
A red dot denotes a breakpoint. This will
allow you to act as if you are the user
performing the task and set a response
value.
2. Click the Debug Process button on the toolbar to begin
debugging as follows:

a. In the Debugger Login dialog the design time
environment configured earlier in this tutorial should
be selected. If there is no environment available
then revisit section 3.5 to set it up. Click the OK
button to continue. 
b. The Debug Process dialog
allows you to set the initial
Process Data (Packages and
Variables) if required. For
this process the claim
package is mandatory and
so you will need to select
one. 
 
 
 
 
 
c. Click the Attach link next to claim in the Debug Process dialog.
d. In the Select Package Object dialog
navigate to the Concordant cabinet and
select one of your claims. If you had
previously deleted all of your claims you will
need to create a new one first. Click the
Open button to choose the claim and close
the dialog.
e. Click the Start Workflow button to
begin. The Process Debug panel
appears, the process begins and
pauses at the first breakpoint.

f. Select the Process Data tab of the debug panel and confirm
that the response value is 0.
g. Go back to the Task Manager tab of the Debug panel
and click the Acquire button to select a performer for
the task.
h. Select your user from the Acquire As User… dialog and click
the Acquire… button.
i. Click the Finish button to complete the First Approval
activity.
j. The process runs through to completion,
pausing between each activity.
k. Click the Rerun Debug button from the left to start over
again. If you want to stop debugging the process before
it has completed you click the Stop Debug button just
below it. 
 
l. When you rerun the debug, the previous
Process Data settings are restored, so there is
no need to re-select a claim. Click the Start
Workflow button to begin.

m. This time, when the process pauses at the first
breakpoint, select the Process Data tab of the Debug
panel and click the response (integer) variable. Enter a
value of 1 to indicate that the claim is approved and
press Enter. Go back to the Task Manager tab to Acquire
and Finish the task again.
Be careful when changing Process Data in the debug view, if you do not press the Enter key
after making a change like the one above the new value is not saved and you will not get
the result you expect. You must press the Enter key after making a change, or select
another variable.
n. The process progresses and should branch to the Second Approval activity after the
Pre-Approved? decision. Note that even
though you did not set a breakpoint on this
activity it will pause here because it is a
work queue task that should be acquired.
Click the Acquire button on the Task
Manager tab of the Debug panel and
select your user.
o. There is no need to click the Finish button
this time as no breakpoint is set. The task
will complete automatically and the
process will follow through, pausing at
each activity.
p. Click the Exit Debug Session button to close the Debug
panel. You have successfully debugged the process and
confirmed that the routing logic is working.
You have just configured a review and approval Process that will run and have its state stored in the
Document repository because it contains Manual tasks assigned to users of the claims Work Queue. 

6.5 Task List Query
The default behaviour of the Task-List Query for a Queue when added as a Data Service to a
page is to allow the end-user to select a queue from a drop-down list and it will then display the
items in that specific queue. However you will predefine the work queue to be displayed.
click on Task-List Query and select New Task-List Query.
2. In the New Task-List Query dialog enter Claims
Queue as the Label and choose the A work queue
radio button. Click the Finish button to create the
query.
3. Select the Basics tab and confirm that the A work queue radio button is selected. Click
the Add button next to Filter by work queue and select Claims Work Queue. Click the OK
button to close the Add Work Queue dialog. This will restrict the list of tasks to those
from this single queue. 
 
Objective Configure a Task-List Query that will return a list of Process Tasks.
Concepts Task-List Query - returns the work items in a particular work queue (or
inbox) so that the user may pull up the relevant activity page for
processing.

4. Choose the Selected processes radio button next to Filter by process. Click the Add
button below this and select Claim Processing (v1.0). Click the OK button to close the
Add Process dialog. This will restrict the list of tasks to those from this single process.
5. Select the Dataset tab of the editor. From here you select Output Columns from the
Context Data panel on the right that shows Process Data common to the processes
selected on the Basics tab, as well as general task information.
If you do not choose to filter the Task-List Query by any processes on the Basics tab then the
Context Data tree will only let you select task information. When you want a Task-List to show
processes from multiple processes it is a good idea to set them up with a similar Process Data
model.
Select Output Columns as follows:
a. Select Task in the Context Data tree. Double-click Task Name and Sent Date from
the panel below the tree to add them to the list of Output Columns.

b. Select Claim in the Context Data tree. Double-click Name, Amount and Claim
Status from the panel below the tree to add them to the list of Output Columns.
c. Finally Select Policy in the Context Data tree. Double-click Last Name to add it to
the list of Output Columns.
The Task-List Query will be used to display a list of Work Queue tasks to users, showing pending tasks
from the Claim Processing Process. The Task list will show details of the Claim as well as the Task itself. 

6.6 Tasks Page
In order to access tasks the user needs access to their task list from the main application
window. In this step you will create a page that will be made accessible from the main
application navigation menu.
7. Select the User Interface tab in the xCP Navigator panel, right-click
on Application UI and select New Page.
8. In the New Page dialog enter Tasks
as the Label and click the Finish
button to create the page.
9. Select the Layout tab of the editor, click the New
Interaction button and add the Task-List Query that
you just created to the page. Be very careful when
choosing it as there is a system generated query
called Claims Queue Workqueue that you do not want.
10. Select the interaction and in the General tab of the Properties panel under the Refresh
section check the On page load checkbox to make sure that the task-list will refresh when
the user navigates to the page.
 
Objective Configure an Application Page that displays pending Work Queue tasks.

11. Select the Inputs tab of the Properties panel and enter or select the following expression
for the Work Queue Name Input value: parameters.cia.claims_work_queue 
 
 
By passing the Parameter Claims Work Queue in as the Input the list will automatically be filtered
to just show tasks from that queue. Using a Parameter like this allows the actual Work queue to
change at runtime without having to redeploy the application.
12. In the Layout tab of the editor add a Results List widget to the page. In the General tab of
the Properties panel enter tasks as the ID, leave the Title blank and select Claims Queue
as the Data service instance under the Data section. Click OK on the confirmation dialog
and the results list widget will be updated to reflect the configuration of the Claims Queue
task-list query. Deselect the Enable Drag And Drop checkbox.
 

13. Finally select the Search button that was added
automatically and change the Label to Refresh from
the General tab of the Properties panel. This will
allow the user to manually refresh the list of tasks.
The system generated Task-List Query that you see in the Selector
is created to provide a list of the Work Queues that you selected to
filter the Task-List query on.  
 
When you then add the Task-List
Query as an Interaction on a Page, if
you leave the ‘Work Queue Name’
Input empty and link it to a Results-
List Query, the system will add the
system generated Query to the Page
Interactions.  
 
This Interaction is then linked to a Drop-down List widget
above the Results List so that the user can select from one of
the Work Queues, and the Results List Widget will then only
show tasks from the selected Work Queue. 
 
When you have a single Work Queue as in the tutorial this
drop down is not needed as the ‘Work Queue Name’ Input can
be set at design time.
This new Tasks Page is really just a container for the Task-List Query created in the previous step so that
you can link to it from the application Navigation. You could also have added a second Results List
Widget to the Policy Search Page to show the results of this Task-List Query. 

6.7 Task Pages
6.7.1 First Review Response Picklist
Start by defining a Picklist that will serve as the response drop-down list when first approving or
denying a claim. It will be used on an Activity Page created later.
2. In the New Picklist dialog enter First Review Response as the Label
and click the Finish button.
3. On the Basics tab of the editor select Integer as the Data type.
4. Select the Entries tab and add the entries listed in the table below. Pressing tab
automatically adds new rows. Note that these values match those in the Claim Status
picklist that are relevant for this activity.
Objective Configure User Interface Activity Pages for the Process Tasks so that
users can interact with the Process.
Label Value
Pre-Approve 1
Deny 3

6.7.2 Second Review Response Picklist
Define a second picklist that will serve as the response drop-down list for the second approval
activity page when approving or denying a claim.
2. In the New Picklist dialog enter Second Review Response as the
3. On the Basics tab of the editor select Integer as the Data type.
4. Select the Entries tab and add the entries listed in the table below. Note that these
values also match those in the Claim Status Picklist but will allow the user to fully approve
the claim rather than only pre-approve the claim.
5. Save your changes and close the editor. 
Label Value
Approve 2
Deny 3

6.7.3 First Approval Activity Page
Each manual (user) activity in the process requires a page so that the user can see and action
it. You will start by creating the page for the First Approval Activity.
1. Select the User Interface tab in the xCP Navigator panel. Expand
Process UI, right-click on Claim Processing and select New Page.
2. In the New Page dialog confirm that Claim Processing
is selected as the Specific object model. Choose
First Approval as the Activity. Accept the default
Label of Claim Processing First Approval and click the
Finish button to create the page.
3. Take some time to review the default layout as it has many widgets and interactions
added automatically, based on the configuration of the process and the activity. There
are also two widgets that aren’t visible. The first is the instructions widget highlighted in
the screenshot below and the second is the task_subject widget next to the task icon.

It is important to note that the default Layout has a Selector Widget
added for each Package defined in the Process as shown in this
screenshot, inside the Packages Column Box Widget. The purpose of
the Selectors is to allow the user to locate an instance of the correct
type in the Repository. 
 
If you click the Validate button on the toolbar and then look at the
Problems panel you will see that for each Selector further
configuration is required to make them functional - you first have
to create a Selector Action Flow and assign it, and then choose
what attribute should be used as the display value of the
Selector. 
 
In many cases the Packages would have already been set up
when the process is initiated and so these Selectors are not
required and can be deleted.
4. The first thing you will do is remove the widgets and interactions that are not needed on
the Layout tab of the editor as follows:
a. This process doesn’t make use of Process
Attachments. and so the entire Attachments Tab can
be removed. 
 
Select the Attachments Tab, right-click and select
Delete from the menu. The tab and all of the widgets it
contains are deleted.
b. Expand the Interactions pane, right-click on the Data Source for
Attachments interaction and select Delete from the menu.
c. The packages for the process are added when the process
is initiated and so the Package Selectors can be removed. 
 
Select the Packages column box widget (click on the
heading Packages), right-click and select Delete from the
menu.
d. The default widget added for the response process variable
needs to be replaced with a drop-down list and so can also
be removed. 
 
Select the Variables column box widget, right-click and select
Delete from the menu.

5. By default a large number of action button widgets are added to a task page related to a
work queue because tasks can be assigned, reassigned, moved from one queue to
another etc. In order to differentiate which are related to queue behaviour and which are
related to the task itself, move the following buttons from the top of the layout to the
bottom: Assign, Unassign, Reassign and Change Work Queue. Your layout should look
like the screenshot below.
6. The next step is to add the widgets that are required to view details of the Claim, Policy
and Vehicle together so that a decision can be made:
a. Select the Task Details tab and drag a Column Box widget
onto the tab. 
 
b. In the General tab of the Properties
panel change the ID to details and clear
the Title value so that the heading of
the column box is removed.
c. Right-click in the first column of the column box widget
and select Insert Column on Right from the menu. The
first column will contain the Claim details, the second will
contain the Policy details and the third will contain the
Vehicle details. 

d. Add four Value Display widgets to the first column of the column
box widget and configure their General properties as shown below.
The page should look like this screenshot. 
 
 
Incident Date 
Set the ID to incident_date, the Label to Incident Date, the Data-
type to Date-time and the Value expression to: 
claim_processing_first_approval.processPackages.claim.incident_date 
 
Incident Location 
Set the ID to incident_location, the Label to Incident Location, the Data-type to
String and the Value expression to 
claim_processing_first_approval.processPackages.claim.incident_location 
 
Amount 
Set the ID to amount, the Label to Amount, the Data-type to Float and the Value
expression to 
claim_processing_first_approval.processPackages.claim.amount 
 
Vehicle in Motion 
Set the ID to vehicle_in_motion, the Label to Vehicle in Motion, the Data-type to
Boolean and the Value expression to 
claim_processing_first_approval.processPackages.claim.vehicle_in_motion 
When entering multiple expressions like this, the quickest method is to use the Selector to
pick the first one, then highlight everything up to the final period (the context of the value)
and copy it to the clipboard. For the subsequent values you can simply paste it into the
Values expression field, press period, and select the final value.
7. Add a Page Fragment widget to the second column of the Column Box widget. On the
General tab of the Properties panel set the ID to policy, the Label to Policy and select
View Policy Details as the Page Fragment ID. The widget will update to show the layout of
the page fragment.

8. Setting the Page Fragment ID value simply
informs the page what widgets to display in
the fragment area. To configure where the
data for the page fragment comes from at
runtime you configure the Page Fragment
Input Mapping values on the General tab of
the Properties panel. 
 
For a page fragment like this one you only
need to set the id OR the model, not both.
For the id Input enter the ID of the policy
package with this expression:  
 
claim_processing_first_approval.processPackages.policy.id
You might need to validate the application or save and close the page and re-open it for the Page
Fragment Input Mapping values to be shown so that you can complete this step.
9. Add another four Value Display widgets to the
final column of the column box widget and
configure their General properties as shown
below. The page should look like this
screenshot. 
 
Make 
Set the ID to make, the Label to Make, the Data-type to Vehicle Make (String) and the
Value expression to 
claim_processing_first_approval.processPackages.vehicle.vehicle_make 
 
Model 
Set the ID to model, the Label to Model, the Data-type to String and the Value expression
to 
claim_processing_first_approval.processPackages.vehicle.model 
 
Year 
Set the ID to year, the Label to Year, the Data-type to Integer and the Value expression to 
claim_processing_first_approval.processPackages.vehicle.vehicle_year 
 
VIN 
Set the ID to vin, the Label to VIN, the Data-type to String and the Value expression to 
claim_processing_first_approval.processPackages.vehicle.vin 
When configuring the Make Value Display Widget Make sure that
you set the Data-type correctly. Although the Make attribute of the
Vehicle Model is a String, it is a String Picklist. If you incorrectly set
the Data-type to String then you will see the Value (e.g. TOYO) and not the display Label (e.g.
Toyota) at runtime.

10. Next you add a list of the documents that will get submitted to the claim, although there
won’t be any documents yet because that comes in the next section of this tutorial.
a. Right click on the History tab and select Insert Tab
Before from the context-menu. 
 
b. From the Tab tab of the Properties panel change the ID
of the tab to claim_documents and the Label to Claim
Documents. You may need to save the changes and
then close and reopen the page to see the new tab
correctly.
c. Drag a Folder View widget onto the
tab. On the General tab of the
Properties panel, under the Root
Folder section, choose the Folder Id
radio button and enter the following
expression for the Folder Id so that it
will show the contents of the Claim folder:  
 
claim_processing_first_approval.processPackages.claim.id
11. The next step with the layout changes is to add back in the ability for a user to select the
response when reviewing the claim.
a. Select the second column of the Column
Box widget that appears to have no widgets
in it. As previously mentioned, there is in
fact a Value Display widget that will display
the task instructions.
b. On the Column tab of the Properties panel
select Vertical as the Orientation.
c. Drag a Drop-down List widget into the column below the hidden
Value Display widget.

d. On the General tab of the Properties panel set the ID as
response and Label as Response.  
 
 
 
 
 
e. Under the Value section of the General tab of
the Properties panel, set the Data type to
Integer, choose the Picklist radio button and
select First Review Response as the source
of the values for Picklist.
f. Select the Behavior tab of the Properties panel and click the
Add button to add a new subscription. 
 
 
 
 
 
 
 
g. subscribe to the Disable When behaviour with the following expression: 
 
claim_processing_first_approval.executionData.currenttask.state==0 
 
 
 
 
 
 
 
 
 
 
This expression ensures that the Drop-down List widget is not enabled until the Task
is acquired by a user. Click the Finish button to save the subscription.

After making these changes your page layout should now look similar to this.
12. As you have seen with other pages and context menus,
you need to configure what happens after an action is
completed. Select the Complete button and under the
Action section of the General tab in the Properties
panel select Specific page for the When done go to
setting and select Tasks as the value for page. This will
ensure that the application navigates back to the tasks
page after completing a task.
 
13. The only thing left to do is reconfigure the interactions. When the original widgets were
deleted some of the bindings were removed and need to be reconfigured. You will only
focus on the Complete interaction in this tutorial. This is the Interaction that is executed
when the task is completed and the process continues.
a. Expand the Interactions pane and choose
the Complete task First Approval (Claim
Processing)-1 interaction.
b. On the Inputs tab of the Properties panel expand the Variables node, select the
response variable and enter this expression: widgets.response.value

c. Expand the Packages > claim node. Delete any expressions that have been
automatically assigned to the attributes of the claim (you are not updating most
attributes).  
 
Select the Claim Status attribute and enter the expression: 
widgets.response.value 
 
Select the Object Id attribute and enter this expression:  
claim_processing_first_approval.processPackages.claim.id
Using the Complete Interaction in this way to update the attributes of packages as the Task is
completed removes the need to add additional Process Data Mapping activities in the process
definition. As well, because the Claim Status Picklist and Response Picklists are configured as
Integers, with correlated values for Pre-Approved, Approved and Denied, it means you can easily
update the Claim Folder with the correct Claim Status value.
d. Expand the Packages > policy node. As with the claim node, delete any expressions
that have been automatically assigned to the attributes of the claim (you are not
updating anything), but for the Object Id value enter this expression:  
claim_processing_first_approval.processPackages.policy.id

e. Finally expand the Packages > vehicle node delete any expressions that have been
automatically assigned to the attributes of the claim (again you are not updating
anything), but for the Object Id value enter this expression:  
claim_processing_first_approval.processPackages.vehicle.id
14. Save you changes and close the editor
It is really important that you map the Object Id value for each Package in your Process. If you do not
map them, when the task is completed the link between the Package and the Object in the repository will
be cleared and the subsequent tasks will have no reference to the Objects. Nothing will be deleted, but
the process will not behave as expected. Unfortunately changing the layout of Widgets (adding and
removing) can cause these bindings to be removed. Because of this it is good practice to always double
check the Package bindings in the Interactions after making changes to a Task page.
6.7.4 Second Approval Activity Page
To create the page for the second activity you do not need to repeat everything that you just did
for the first one. It is normally much quicker after building one page for a given process to
duplicate it, make any changes and update the expressions for the interactions.
1. Select the User Interface tab in the xCP Navigator panel.
Expand the node Process UI > Claim Processing, right-click on
the Page Claim Processing First Approval and select
Duplicate.
2. In the Duplicate Page dialog enter Claim Processing
Second Approval as the Label and select Second
Approval from the Activity drop-down list. Click the
Finish button to duplicate the page.
If you receive an error message at this point, close the dialog and delete the new page that was
created. Go back and remove the ‘Complete’ data service from the first page, add it back in again
and duplicate the page before re-configuring it. This is a known intermittent issue with the GA
build of xCP 2.2

3. On the Basics tab of the editor, update the Page title to
Claim Processing Second Approval (it will still show the
title of the original page).
4. On the Layout tab of the editor select the Policy Page Fragment widget. On the General
tab of the Properties panel under the Page Fragment Input Mapping section update the
expression to reflect that this is the second activity as highlighted here. Most expressions
are updated automatically for you.
5. Select the Response drop-down list widget and on the General tab of the Properties panel
under the Value section change the Picklist value to Second Review Response.
 
 
 
 
 
 
 
6. On the Behavior tab of the Properties
panel for the widget select the Disable
When Subscription and change the
expression to reflect the new name of the
activity.
The Picklists and Activity Pages that you have just configured will allow users to interact with the Claim
Processing Process, updating the status of the Claim automatically. 

6.8 Claim Business Event
For seasoned Documentum developers you should know that business events remove the need
to write Type Based Objects (TBOs), since many common events (such as create, update,
delete, etc.) can be trapped and a process (which can have pretty complex and even custom
logic) can be invoked. In this section, you will be using a Business Event to launch the Claim
Processing process defined in the previous section whenever a Claim object is related to a
Policy object.
1. From the Object Models tab in the xCP Navigator panel, expand Folders
and double-click Claim to edit the model.
2. Select the Business Events tab of the editor and click the
New Business Event button.
3. On the first page of the Business
Event for Claim dialog enter
Process Claim as the Label and
select Policy Related as the Select
Trigger value. Click the Next button. 
 
The reason for using Policy Related
as the trigger rather than Claim
Created is that the process requires
the claim and its related policy and
vehicle. A claim is always related to
a policy after it has been created,
and so you choose the final trigger.
Objective Configure a Business Event to start the Claim Processing Process
whenever a new Claim is created.
Concepts Business Event – has an event source (an object instance), a trigger (the
specific event type that occurs), a condition (written as an expression) and
an action.

4. On the second page of the Business Event for Claim
dialog you choose the Actions that are executed
when the Event is triggered. You want to start a
process so click the Add button.
5. In the dialog select Start Process
(which is the only option) from the
drop-down list and choose the
process Claim Processing by
clicking the ellipsis button.
6. The list of Process Data for the
selected process is then displayed,
and mandatory packages are
highlighted (claim in this case). In
theory the process also requires a
policy and vehicle but they were
not made mandatory when the
process was defined. You
configure the data to be passed
from the Event to the Process as
you have done previously by
selecting a Package or Variable
and typing or selecting the value to
pass.  
 
Set the following values:
a. For the claim package and enter the expression event.claim  
 
 
 
 
 
 
 
Note that when assigning an object to a package you do not need to enter the ID of
the object.

b. For the policy package and enter the expression event.related_policy.policy
 
c. For the vehicle package and enter the expression event.claim.vehicle.vehicle 
 
Notice that the Context Data of the Relate Event is aware of the Claim and the Related Policy. The
Context Data will vary depending on the Event that you are configuring. Also notice that due to the
relationships defined between Claim, Policy and Vehicle, you have access to everything you need
just from the Claim.
7. Click the OK button to close the dialog and click the Finish button to close the Business
Event for Claim dialog.
Now that you have configured the Business Event, whenever a Claim is related to a Policy the Claim
Processing Process will be started with the Packages set up for the Claim, Policy and Vehicle. 

6.9 Update Master Page: Tasks
Now that you have created the process for handling claims and configured the Tasks page so
that users can interact with the activities in the process, you need to make that page available
from the navigation menu on the Master page.
1. Select the User Interface tab in the xCP Navigator panel and double-click the
Master page to open it for editing.
2. Select Menu Item 2 from the navigation menu.
3. In the General tab of the Properties panel change the ID to tasks and the Label to Tasks.
Under the Link section select Page for the Link destination and under Page Selection
choose the Page radio button and select the application page Tasks.
The application has now been updated to give users access to the lists of tasks for the Claim Processing
Process. 
Objective Update the Navigation Menu to give access to the Tasks Page.

6.10 Testing the Application: Claim Process
button on the toolbar to deploy and run your
application.
2. When the deployment is completed, log in to your application as
the user that you added to the Clerk Role. As before the Policy
Search Page loads showing your existing policies. You should
now have a new Tasks menu item in the navigation menu.
3. Click on the Tasks menu item. There should not be any tasks in the list yet as you need to
create a new Claim first to trigger the Business Event that starts the Claim Processing
process. 
Remember that the Search button was added automatically when the Results List Widget was
bound to the Task-List Query. Even though there are no User Input values to the Query the button
is still useful as a ‘Refresh’ button, and it is common practice to change the Label to reflect that.
4. Go back to the Policy Search page and open a policy for editing.
You can either use the Edit Policy context menu item as shown
here or the Open Last Policy button.
5. In the Claims section of your open policy, click the Add Claim button to
initiate a new Claim. 
Objective Test the incremental changes you’ve made to the application by creating a
new Claim, ensuring that the Claim Processing Process is initiated, and
then participating in that process.

6. Fill in the claim details, choose a Vehicle
from the list and then click the Create
Claim button.
7. You should see a success
message displayed and the new
claim will appear in the list of
claims.
8. Now click on the Tasks menu item to go back to the Tasks page. This time there should
be a new task for the First Approval activity of the process showing you the key details
from the Task itself, the Claim and the Policy. Click on the Task Name which should be a
hyperlink to open the appropriate task page directly.
 
 
 
 
 
Remember that you did not have to configure that the Task Name should be rendered as a
hyperlink, the xCP runtime does that for you automatically.
9. The task page opens showing you the details of the Claim, Policy and Vehicle. The
Response drop-down list should be disabled because the task has not been acquired yet.
Acquiring a task means you are accepting responsibility to work on it and the task cannot
then be completed by anyone else.

10. Click the Acquire button to acquire the task. A message will appear confirming that the
task has been acquired and the page will reload. The Response drop-down list should
now be enabled and the list of action buttons updated to reflect that you can now action
the task.
11. Click on the Claim Documents tab and click the folder in the tree view. The same View
Claim page that you configured earlier is displayed alongside the tree view.
You will probably be thinking at this point that the page layout is not very nice. When the View
Claim page is displayed like this inside the tab, the Name value is not displayed properly, and on
the Task Details tab the spacing and alignment can make it hard to understand what value goes
with what label. The dates also display a meaningless time and the Vehicle Year value has a
comma in! Good user interface design does require additional consideration and effort, and is
really outside the scope of this tutorial, although Appendix A does give some pointers. Do take
some time to look at the options within the properties of each widget to see how you can change
the look and feel of the application though.
12. After reviewing the details of the
claim select the Pre-Approve option
from the Response drop-down list.
Click the Complete button to finish
the task.
Remember that you didn’t check the configuration of any of the other buttons, and so although
you can click on them to experiment, the results may not be desirable.

13. A message will appear indicating that
the task has been completed and the
application should redirect you back to
the Tasks page. The list of tasks will
be empty again at this point because
although the process proceeds to the
Second Approval activity the list will
need to be refreshed before you see it.
14. Click the Refresh button to refresh the list
and the Second Approval task should
appear. You may need to wait for 10 - 20
seconds before the new task appears.
15. Before opening the task, navigate
back to the Policy Search page and
click the Open Last Policy button.
16. Select the Claims tab, and
confirm that the Claim Status
value has been updated to Pre-
Approved.
17. Navigate back to the Tasks page,
open the Second Approval task
and click the Acquire button to
acquire it. Select the History tab
and review the steps that have
completed and the current step
marked as Dormant.
18. Now select either Approve or Deny from the Response drop-down list.
It doesn’t matter at this point what option you choose.
19. Click the Complete button to finish the task. A message will
appear indicating that the task has been completed and the
application will redirect you back to the Tasks page. There should
be no further tasks, even if you click the Refresh button.

20. Navigate back to the Policy that
you are using and check that the
Claim Status has been updated
to either Approved or Denied
depending on what you chose as
the response during the Second
Approval activity.
21. Stay on the Claims tab and click the Add
Claim button again and create a new
claim.
22. Navigate to the Tasks page and right-click on the new First Approval task. A context menu
should appear with the default set of actions for a task as shown in this screenshot. 
 
Choosing View opens the task page, the same as
clicking on the Task Name hyperlink. 
 
Choosing Acquire will acquire the task as the current
user but not open the page. If you then choose View, the
task page opens in its acquired state with the drop-down
enabled etc.
This task related Context Menu is system generated and cannot be altered. The list of available
actions is dynamically defined based on the configuration of the task. For example if the task has
not been acquired then the Acquire action is provided, however if the task has already been
acquired, then the Acquire action is hidden and the Unassign action provided instead. One
special case to note is that if the activity does not have a Page associated with it, then a Complete
action is provided. This is useful in the situations where the task is simply asking a user to do
something outside of the application like update another line of business application, or make a
phone call, and so they can carry out the task and complete it with the fewest mouse-clicks and
page changes.
1. Create a Page Fragment for viewing the Claim details on the Task Pages. 
2. Create a Page Fragment for viewing the Vehicle details on the Task Pages. 
3. Add a new Navigation Menu linked to the Manage Application Parameters Page. 

7.0 Claim Documents
Every claim will need one or more documents added to support it and as the claim is handled
correspondence will be generated in relation to it. In this section of the tutorial you will create a
a couple of Content models to support this requirement.
7.1 Content Models
7.1.1 Claim Document Model
The first Content model is configured with the attributes that all claim documents require.
1. Select the Object Models tab in the xCP Navigator panel, right-click
on Content and select New Content.
2. In the New Content Model dialog enter Claim
Document as the Label and click the Finish
button to create the Content model.
3. Select the Attributes tab of the
editor. Locate the Discovered
Metadata section of the Types
pane and add Business Terms
(USA), Email Address and Phone
Number. Each or these attributes
is a repeating attribute.
Objective Create the Models that represent documents related to Claims.
Concepts Content - defines content such as a text, image, video, or audio files. If
you are familiar with Documentum already these are equivalent to
Document Types.
Discovered Metadata – pieces of information found by text analysis. They
are available only for Content objects. They can be found in the content
itself, in the values of the file properties, or in the values of the object
attributes.
Inheritance - allows the definition of a hierarchical data model when an
Object Model can inherit the Attributes and Business Events of another.
Getting Started with xCP 2.2 - 7.0 Claim Documents 153

When a document is imported into the system as a Content type that has Discovered Metadata assigned,
the Content Intelligence Services (CIS) server analyses it and populates the attributes with any relevant
values found. More information on the content analytics can be found in the Designer Help.
7.1.2 Correspondence Model
The second Content model is configured to inherit from the Claim Document model and is then
extended with attributes that are specific to Correspondence.
Content and select New Content.
2. In the New Content Model dialog enter a Label
of Correspondence but this time choose the
Inherit from an existing content model radio
button and select Claim Document. Click the
Finish button to create the Content model.
3. Select the Attributes tab of the editor and check the show
inherited checkbox to see the inherited attributes. 
 
Notice that as well as the Discovered Metadata attributes
added to the Claim Document model you also see all of
the system attributes denoted by (Base Content) and
(Base Model). These inherited attributes cannot be
altered.  
 
Uncheck the inherited attributes checkbox.
4. Add a single Date-time attribute with a Label of
Correspondence Date. This attribute will contain the date
of the letter, which can be different to the date it is
created in the system.
 

7.2 User Interface
7.2.1 Claim Document View Page
The first instance page is for viewing claim documents.
the Content UI node, right-click on Claim Document and select
New Page.
2. In the New Page dialog ensure that Claim Document is
selected as the Specific object model and choose the
View Claim Document radio button. You can accept the
default Label. Click the Finish button to create the page.
3. The page is created with Value Display
widgets for the system and discovered
metadata attributes of the document,
a Viewer widget to display its content,
and a Comments widget.
4. Drag the discovered metadata Value Display widgets down from the
top of the page to the bottom of the Document Info column box so that
the layout is a little neater.
Objective
Configure the User Interface artifacts that allow users to view and
execute actions against Content objects.

7.2.2 Claim Document Context Menu
Next you need to configure the Context Menu for the Claim Document.
the Content UI node, right-click on Claim Document and select
Create Context Menu.
2. For this tutorial you will not configure anything on the default
context menu so save and close the editor.
7.2.3 Claim Document Import Page Fragment
The system generated Import and Import New Version (Check-in) action flows provided by xCP
rely on the existence of a couple of Page Fragments for each Content model, created using a
specific naming convention. You will create these next. The first is the Import page fragment.
expand the Content UI node, right-click on Claim Document and
select New Page Fragment.
2. In the New Page Fragment dialog ensure that
Claim Document is selected as the Specific object
model and choose the Import Claim Document
radio button. Accept the default Label as this
follows the required naming convention and click
the Finish button to create the page fragment. 
 
This page fragment will be used by the system
generated Import action flow.
 
 

3. Select the Layout tab of the editor. By default a Text Input
widget is added so that the user can modify the Name of the
document they are importing. Additional widgets are added
to reflect the custom attributes of the Content model. In this
case Value Display widgets are added for the discovered
metadata attributes.
4. Because discovered metadata is not applied until after the file is
imported these attributes are not relevant here, so delete these three
Value Display widgets to just leave the Name text input widget
5. Save you changes and close the editor.
7.2.4 Claim Document Check-in Page Fragment
Next you create the Import New Version page fragment.
expand the Content UI node, right-click on Claim Document
and select New Page Fragment.
Claim Document is selected as the Specific object
model and choose the Import New Version Claim
Document radio button. Accept the default Label
as it conforms to the correct naming convention
and click the Finish button to create the page
fragment. 
 
generated Check-in action flow. 
 
3. As with the Import Fragment delete the three Value Display
Widgets for the Discovered Metadata attributes.

7.2.5 Correspondence View Page
Now you will create the user interface elements for the Correspondence content model starting
with the View Page.
Content UI node, right-click on Correspondence and select New Page.
2. In the New Page dialog ensure that Correspondence is
selected as the Specific object model and choose the
View Correspondence radio button. You can accept the
default Label. Click the Finish button to create the page.
3. As with the Claim Document a default layout is provided with Value
Display widgets added to the top of the page for the custom attribute(s).
Drag the Correspondence Date value display widget to the bottom of the
Document Info column box.  
 
You will notice that although the Correspondence Model inherits Discovered Metadata Attributes
from the Claim Document Model they are not displayed on the page by default. Only direct
Attributes of the Model itself are added to the default Layout.
4. Add three Value Display widgets to the Document Info column box
beneath Correspondence Date and configure their General properties
to display the three discovered metadata attributes as follows:
Business Terms (USA) 
Set the ID to business, the Label to Business Terms (USA), the
Data-type to String, check the Has multiple values checkbox
and set the Value expression to correspondence.business
Email Address 
Set the ID to email, the Label to Email Address, the Data-type to String, check the Has
multiple values checkbox and set the Value expression to correspondence.email

Phone 
Set the ID to phone, the Label to Phone Number, the Data-type to String, check the Has
multiple values checkbox and set the Value expression to correspondence.phone
7.2.6 Correspondence Context Menu
Then configure the correspondence Context Menu.
the Content UI node, right-click on Correspondence and select
Create Context Menu.
2. For this tutorial you will not configure anything on the default context menu so save and
close the editor.
7.2.7 Correspondence Import Page Fragment
Next you configure the Page Fragments, starting with the Import one.
New Page Fragment.
Correspondence is selected as the Specific object
model and choose the Import Correspondence
radio button. Accept the default Label as it
conforms to the naming convention and click the
Finish button to create the page fragment. 
 
generated Import action flow.

3. Select the Layout tab of the editor. The widgets that have
been added to reflect the custom attributes of the Content
model are in alphabetical order.
4. Delete the three Value Display widgets for the discovered
5. You will now add some additional validation to ensure that a valid Name and
Correspondence Date value are entered.
a. Drag and drop an Error Display widget beneath Correspondence Date.
b. Select the Behaviour tab of the Properties
panel for the error display widget. Click the
Add button to select which widgets
validation messages will be displayed.
c. In the Widget selector dialog choose the object_name and correspondence_date
widgets and click the OK button. The error display widget will now show all
validation messages from these two widgets.

d. Select the Name widget and on the Validation tab of
the Properties panel change the Is Mandatory
expression to true and check the Hide error in
tooltip checkbox to
prevent the inline display
of validation messages.
e. Stay on the Validation tab and click the Add button next to the list of Validations to
add a new validation check.
f. In the Validation Rule dialog enter the
following expression and error message
to validate that the Name is not too long: 
And when this condition is not met 
length(widgets.object_name.value)<=32
 
Show this validation error
The name of the document is too long 
 
g. Select the Correspondence Date widget and on the
Validation tab of the Properties panel change the Is
Mandatory expression to true and check the Hide
error in tooltip checkbox
to prevent the inline
display of validation
messages.

h. Stay on the Validation tab and click the
Add button to add a new validation check
to make sure that the correspondence
date entered is in the past:
And when this condition is not met 
differenceDays(today(), widgets. 
correspondence_date.value)>=0
 
Show this validation error
The correspondence date cannot be in the
future 
 

7.2.8 Correspondence Check-in Page Fragment
Finally configure the Import New Version page fragment. You will not configure additional
validations for this fragment.
New Page Fragment.
Correspondence is selected as the Specific object
model and choose the Import New Version
Correspondence radio button. Accept the default
Label as it conforms to the naming convention and
click the Finish button to create the page fragment. 
 
generated Check-in action flow.
3. Delete the three Value Display widgets for the discovered
Now that you have configured the Context Menus and Import and Check-in Page Fragments for the two
Content Models you will be able to use the Import and Import New Version buttons when testing the
application. You will also be able to drag and drop files into the Claim folder when viewing a Claim. 

7.3 Content Search
7.3.1 Document Search Full-Text Query
To provide a generic document search function, first you have to configure a Full-Text Query to
return the documents.
click on Full-Text Query and select New Full-Text Query.
2. In the New Full-Text Query dialog enter Claim
Document Search as the Label. Select Content as
the Primary model and then select Claim Document.
Click the Finish button to close the dialog.
3. Select the Dataset tab of the editor. Add the attributes Name, ContentType and Last
changed to the Output Columns by double-clicking or dragging the attributes from under
Claim Document in the Context Data panel on the right.
Objective Conﬁgure a page that will allow the user to search the repository for
documents using the full-text of the document.
Concepts Full-Text Query - allows you to search the content of documents and their
indexed attribute values. They can also be used to search the indexed
attributes of other Object Models such as Business Objects. A Full-Text-
Query enables users to search for approximate strings and returns a text
summary for each result..
Facets - are filters computed by the xPlore server and enable users to
explore large datasets easily.

4. Select the Facets tab of the editor and add ContentType, Created by, Created on and
Object type to the list of Facets, again by double-clicking or dragging them.
5. Select the User Inputs tab of the editor and confirm that the Include an input field for full-
text searching checkbox is checked. Double-click or drag the Name attribute for the
Claim Document to the User Inputs.
6. Select the User Input that you just added (Claim
Document.Name) and on the General tab of the Properties
dialog change the Operator to Contains.
7. Save your changes and and close the editor.
7.3.2 Claim Document Search Page
The next thing you configure is a new Application Page where you will add the query to the page
as an interaction and add a results list widget to the page and wire it to the interaction.
1. Select the User Interface tab in the xCP Navigator panel, right-click
on Application UI and select New Page.

2. In the New Page dialog enter Claim Document Search as
the Label. Click the Finish button to close the dialog and
create the page.
3. Select the Layout tab of the editor. Click on the
New Interaction button and select the Claim
Document Search full-text query.
4. Add a Results List widget to the page and change the ID to claim_documents. Under the
Data section of the General tab of the Properties panel select Claim Document Search as
the Data service instance (click OK on the warning dialog) and deselect the Enable Drag
and Drop checkbox.
5. The results list widget
will be configured with
the correct columns
and input widgets,
and the Facets panel
will be visible.
Changing the ID of the Results List Widget is not essential, but it is good practise to set the ID of
Widgets to something meaningful. Later on when you want to access their values in expressions it
is much easier to identify the correct widget.
You now have a new Application Page that will allow users to search across Claim Documents and
Correspondence using the full-text of the documents themselves.  

7.4 Update Master Page: Claim Document Search
7. Select the User Interface tab in the xCP Navigator panel and double-click the
Master Page to open it for editing.
8. Select Menu Item 3 from the navigation
menu.
9. In the General tab of the Properties panel change the ID to search and the Label to
Document Search. Under the Link section select Page for the Link destination and under
Page Selection choose the Page radio button and select the Claim Document Search
page.
Users will now be able to access the Document Search feature to locate documents. Because you have
configured Context Menus for each Content Model they will be able to right-click on the search results to
action the documents. 
Objective Update the Navigation Menu to give access to the Claim Document
Search Page.

7.5 Testing the Application: Claim Documents
button on the toolbar to deploy and run your
application.
2. When the deployment is completed, log in to your application as the user that you added
to the Clerk Role. The Policy Search page loads
with your existing policies listed and you should
see the new Document Search menu item.
3. Open a policy either from the right-click menu or the Open
Last Policy button. When the policy opens right-mouse click
on one of the claims and select Import… from the context
menu. The context menu does not appear if you right-click
on the hyperlink, you must right-click on another column.
The default Import action flow should load.
4. In the Default Import Action Flow dialog click the Add a file
button to select one or more files from the local file system.
Start by selecting the sample file Estimate Request
Letter.docx from the supporting material that came with this
tutorial.
5. The dialog updates to show the current Folder and drop-down lists to set the Content Type
and Format of the document currently selected in the list of Files.
6. Notice that at the end of the Folder path there
is a small down arrow. If you click the arrow the
Context Menu appears that has been defined
for that folder type.
You need to be aware of this feature, because if you select View Claim now from the menu the page
behind the Import Action Flow will still respond to the selection and change the page to view the
claim. If you cannot build appropriate behaviour in the Context Menu items to prevent users
navigating like this then you should consider configuring your own Custom Action Flow for importing
documents. In this way you can either make the Folder path read-only or not show it at all.
Objective Test the incremental changes you’ve made to the application by importing
documents, verifying that the Discovered Metadata is extracted, and
performing a full-text search.

7. For the Content Type value select Correspondence and for the Format select MS Word
Document 2007 / 2010. When you choose Correspondence as the Content Type the
corresponding Import page fragment is loaded.
8. Select a value for Correspondence
Date that is in the future and add
some additional characters to the
end of the filename to test the
validation rules.
9. Select a Correspondence Date
value in the past and restore the
filename before clicking the Finish
button to import the document to
the claim.
10. You can also drag and drop one or more
documents straight onto a row of the claims
results list to invoke the action flow. Try importing
the file Estimate.docx this way with a Content Type
of Claim Document to see the other page
fragment in the Import action flow.
This behaviour is enabled by default, and controlled by the Import item
on the Context Menu for the Claim. If you want to disable it uncheck
the ‘Invoke Action Flow on Drag Drop’ checkbox on the properties of
the Menu Item.
11. After a couple of minutes, your document will
be indexed. Navigate to the Document
Search page using the new Document Search
menu item.

12. Enter the word bumper for the value in Full-Text and click on the Search button. In your
results you will see the Claim Document that you imported as part of your claim. Notice
that the term bumper that you searched for is highlighted in the results list, and the
facets are available on the left. 
13. Click on the Name of the document, which should be a hyperlink, to open the View page
for the document.  
 
Note that some of the discovered metadata attributes are populated and that the Viewer
widget displays a preview of the document.
The Viewer Widget and Comments widget can be added to any page, so long as you provide the
correct input values for them. 

If no Discovered Metadata has been populated then it means that the CIS service or the Temis
Luxid services that it relies upon are not running. If the viewer is not working, check whether the
document has JPEG renditions created using Documentum Administrator. If not, it probably means
that Content Transformation Services has not processed the document. If the renditions do exist
then check the ACS URL in Documentum Administrator. Log on to Documentum Administrator and
navigate to the ACS Server node. View the
Properties of the ACS Server Configuration
and update the Base URL if needed. 
 
 
 
 
14. Before editing a document, open the User Settings page by clicking on
the User icon in the navigation menu and selecting settings.
15. As well as choosing the current Role (for
when a user belongs to more than one
role), Workflow availability etc. there is an
option at the bottom of the page to Enable
client plug-in. Confirm that it is not
checked.  
 
The default setting for each user is for the
plug-in to be disabled. In this mode all file
transfer between a client machine and the
server will use the browsers default
mechanism. 
 
When checked a Java applet will be used
to provide a seamless editing experience of
documents. 
 
Save any changes.
16. Navigate back to the Document Search page, search for a document
again and open one to view. Click on the Edit button. The document
will be downloaded to your browsers default downloads folder, which
will depend on the configuration of your computer. Without the client
plug-in the user has to open the document in the appropriate
application from that location in order to edit it.
17. Notice that the action buttons have changed, and you now have
a Cancel Editing button. Whenever you edit a document it will
be checked-out to you, and you can either cancel the checkout
or check-in a new version.

18. Click the Import New Version button.
19. The Default Import New Version Action Flow dialog opens and allows you to add a file
(you have to locate it from your downloads folder) and choose the versioning options.
Click the Finish button to complete the check-in.
The benefit of not using the client plug-in like this is that the application has no reliance on a Java
runtime, and so can be used from devices that do not support Java, such as tablets.
20. Open the User Settings again and enable the client
plug-in. Save the change and close your browser
completely. You will repeat the editing of a document
with it enabled but you need to log in again for the new
setting to take effect.
21. Open the browser and log on to your
application. You will probably see
one or more security warnings, which
you need to allow/accept. It is best
to check any boxes to prevent the
repeated security warnings each
time you log on.
22. Navigate to the Document Search
page, search for a document and
open one to view. Click on the Edit
button. This time a Choose local
cache folder dialog should appear.
Select where you would like to store
documents that are being edited.
You can accept the default option.
Click the Open button to continue.

If you see this error when you try and edit the document it
means that the plug-in is not installed correctly. You can try
the following steps to fix the problem. First clear the browser
cache, and then the Java cache (you can access Java settings from the Control Panel). Finally
restart the application server where the application is running. You may also need to update the
version of your Java Runtime Environment.
23. The document should open in Word
(or whatever the native editor is on
your computer). Make a change and
close the editor.
24. In the xCP application click the Import New Version button.
25. This time the Default Import New
Version Action Flow dialog appears
with the file pre-selected because
the applet keeps track of where
edited files are stored. Finish
importing the file as before.
26. If you have Outlook installed on your client machine you can also test the drag and drop
of an email message from Outlook once the client plug-in is enabled. Navigate to the
Policy Search page again, open a claim and select the Claims tab. Drag an email from
Outlook to a claim.

27. If you receive a warning about a program trying to
access data from Outlook, choose to allow access.
28. The Default Import Action Flow
dialog appears again with the
email message as a selected
file. Choose Correspondence
as the Content Type and MS
Outlook Message (.msg) as the
F o r m a t . S e l e c t a
Correspondence Date and click
the Finish button.
29. If you search for this new document and open it
you will see that the viewer displays a rendition of
the email with a reference to the attachments.
30. You can also drag and drop a single attachment from within an email message.
1. Modify the layout of each View Page to make them more user-friendly. 
2. Review the Context Menus and remove unwanted items. 
3. Change the layout of the Claim Document Search page to make it more user-friendly. 
4. Update the page fragments with validation and add behaviour to the buttons to disable them if there
are validation errors. 

7.6 Relevant Documents
The benefit of using a Type Fragment to support this requirement is that you do not have to
extend the Claim Document and Correspondence content models with the attributes, you
simply attach the Type Fragment to the instances of those content types that need them.
7.6.1 Relevant Document Type Fragment
Start by configuring the Type Fragment.
1. Select the Object Models tab in the xCP Navigator panel, right-
click on Type Fragments and select New Type Fragment.
2. In the New Type Fragment dialog enter Relevant
Document as the Label. Click the Finish button to
close the dialog and create the type fragment. 
 
3. On the Attributes tab of the editor add the attributes listed in
the table.
Objective Configure a Type Fragment that can be associated to any type of Content to
extend the attributes for those that are relevant to the outcome of a Claim.
Concepts Type Fragment - allows you to add behaviour and attributes to an object
instance without changing its Model. Type fragments can be attached and
detached automatically or as part of a business process.
Resources - a project sub-folder that stores optional content for an
application such as page logos and icons.
Date Marked Date-time
Marked By String
Relevant Boolean

7.6.2 Associate Type Fragment with Content Models
Now that you have configured a type fragment you need to associate it with the Claim
Document and Correspondence models.
1. Select the Object Models tab of the xCP Navigator panel, expand the
Content node and double-click Claim Document to open it.
2. Add the Relevant Document type
fragment by dragging or double-
clicking it. The type fragment can be
found under the Type Fragments
section of the Types pane in the
editor.
In this tutorial the use case for the Type Fragment is very simple, and so it is important to note that
Type Fragments are independent from the class of Object Model and so your Relevant Document
Type Fragment could be associated with a Policy (Business Object) or Claim (Folder) as well.
There is no need to do anything to the Correspondence content model because it will inherit
the type fragment settings from the Claim document model that you have just configured.
7.6.3 Document Mark Relevant Stateless Process
Type fragments can be attached automatically when instances of an object are created, but you
will configure a simple stateless process to mark one or more documents as relevant by
attaching the type fragment. This process will be initiated manually by a user when
appropriate.
1. Select the Processes tab of the xCP Navigator panel and click

2. In the New Process dialog enter a Label of Document
Mark Relevant and check the Process can run in
stateless mode checkbox. Click the Finish button to
close the dialog and create the stateless process.
3. Click the Process Properties toolbar icon in the editor to open
4. Select the Data tab and add a String
Process Variable with a Name of
documents and select the Multivalue
radio-button. This will hold a list of the
ID values of the documents to be
processed.
5. Select the Composite Service tab
and check the Use as Input
checkbox for the documents
Variable. 
 
Click the OK button to save the
changes.
6. Drag and drop an Attach Type Fragment activity onto the process model canvas. This
activity can be found under the Type
Fragment node in the Activities pane.
Draw flow lines to join it to the Initiate
and End activities.

7. Double-click the Attach Type Fragment
activity to open the Activity Inspector
dialog. Change the Name of the activity to
Mark Relevant, choose the Objects
referenced by Object ID radio button and
add the Relevant Document type fragment
by clicking the Add button.  
 
 
 
8. Click the Next button to go to the next page of the Attach Type Fragment tab where you
will set the attributes of the type fragment.
 
 
 
 
 
 
9. Using Copy functions map the following values into the type fragment attributes. You can
refer back to section 4.3 if you need to refresh you memory on how to use the mapping
screen.
a. Add a Copy function and link it to the Relevant
attribute. Double click the function, add a
Function Parameter and set its value to true and
click the OK button.
b. Add another Copy function and link it to the Date Marked attribute. Expand the
Execution Data > task node in the Process Data tree on the left and link it to the
creation_date value of the task. This will set the Date Marked attribute with the
current date and time.

c. Add another Copy function and link it to the Marked By attribute. Expand the
Execution Data > workflow node in the Process Data tree on the left and link it to
the supervisor value of the workflow. This will set the Marked By attribute with the
name of the user that initiates the process. 
 
10. Finally add another Copy function and link it to the Item[0] entry of the activity. This is
how you set which objects are to have the type fragment attached. Expand the Variables
node in the Process Data tree on the left and link it to the documents variable.
 
7.6.4 Update View Claim Page
Now you will make the Document Mark Relevant stateless process available by clicking a
button on the View Claim page.
Folder UI > Claim node and double-click the View Claim page to open it
for editing.
2. On the Layout tab select the Results List widget that lists
the documents.

3. On the General tab of the Properties panel check the
Allow selection of multiple items checkbox so that
multiple documents can be marked as relevant at once.
Checking this box tells Designer to treat the ID of the selected row as a repeating value as opposed
to a single value. If you do not check this box here then you will not be able to pass a repeating
value of ID’s to the stateless process in the next few steps.
4. From the Interactions pane add the
Document Mark Relevant stateless
process as an Interaction by clicking
the New Interaction button.
5. On the Inputs tab of the Properties panel for the interaction expand the Variables node and
set the expression widgets.results_list.selected_row.id for the documents value.
6. Finally add a Button widget underneath the Results List widget.
On the General tab of the Properties panel give it an ID of mark
and Label of Mark Relevant.
7. Under the Action section on the General tab of
the Properties panel select Data service
instance from the Invoke drop-down list, and
then select Stateless Process Document Mark
Relevant from the Data service instance drop-
down list. Finally select None from the When
done go to drop-down list.

7.6.5 Add Relevant Icon Resource
When you want to include custom graphics in an application you place them in the appropriate
folder in the application folder structure on the file system and they are then packaged into the
applications WAR file for deployment. At runtime they can then be access using a relative URL.
1. Select the Resources tab of the xCP Navigator panel. Right-click on
Concordant Insurance and select Open.
2. Windows Explorer opens at the
folder on the file system where
resource files should be added
(ArtifactsResources inside the
application folder).
3. Move the image GreenFlag.png from the
Resources folder that came with the
supporting material for this tutorial into the
folder and close the Windows Explorer
window.
4. In the xCP Navigator panel right-click on
Concordant Insurance again and this time
select Refresh to force xCP Designer to check
the folder for new resources.
7.6.6 Update Content Pages
Finally you will update the View Claim Document and View Correspondence pages to display an
icon for those marked as relevant.
the Content UI > Claim Document node and double-click the View
Claim Document page to open it for editing.
2. Select the Layout tab of the editor
and add a Value Display widget to
the Document Info column box
above Name.

3. On the General tab of the Properties panel set the
ID to marked and clear the Label.
4. Under the Value section build the Initial
Value expression as follows. You will
probably find it easier to open the Edit
Expression dialog as it will be a long
expression:
a. Bring up the selector
a n d c h o o s e t h e
ifThenElse Function.
b. The function is added and the expr part highlighted
automatically.
c. Bring up the selector again, expand Claim Documents > Type Fragments > Relevant
Document and select the Relevant boolean attribute. 
d. Double-click the resultIfTrue part and enter the following HTML snippet: 
'<img src="Artifacts/Resources/GreenFlag.png"/>' 
Take care that you enclose the whole
string in single quotes, and use double
quotes inside the string.  
e. Finally select the resultIfFalse part and
replace it with empty single quotes. The
end result of this expression is to output
an HTML <img> tag if the type fragment
has been added.

5. The final thing to do is close the Edit
Expression dialog and set the Data type to
HTML.
7. Repeat these steps for the View Correspondence page.

Now when a user selects a document from the Claim Folder they can choose to mark it as relevant to the
claim to distinguish it from the other documents. When viewing the documents a visual clue will be
shown to highlight that it has been marked relevant.
7.6.7 Fix Data-model Problems
Because a type fragment was added to the Claim Document content model the configuration
for the related page fragments need updating.
1. Validate the project by clicking the Validate toolbar button.
2. Select the Problems tab. There should be multiple errors shown.
3. Double-click each problem to open the relevant artifact. For these type of problems
Designer will automatically update the fragment when it is opened so you do not need to
make any further changes. The error will disappear immediately.
4. Close each editor once you have opened them to save the changes.

7.7 Testing the Application: Relevant Documents
2. When the deployment is completed, log in to
your application as the user that you added to
the Clerk Role. Open the policy and view the
claim that has the documents you imported.
You should see the new Mark Relevant button.
3. Select several documents and click the Mark Relevant button.
After a few seconds you will see a success message to confirm
that the process executed successfully.
Remember that you will find that the first time you access any
function like this after deployment the system will respond more
slowly. This is normal.
4. Click on one of the documents to open its View page.
The icon should be displayed in the Document Info
section of the page.
If you made a mistake in the expression or didn’t set the Data type to HTML, don't
forget that you don’t need to redeploy the application to fix it, you can use the
Preview mode to get it right. Be especially careful of copying and pasting
expressions as a double quote character is often pasted incorrectly, and although it
appears correct in the editor it may not be resolved correctly at runtime. The bottom
image is the correct one.
1. Create a Page Fragment to display the Type Fragment attributes. 
2. Add the Page Fragment to the Content View Pages. 
3. Change the Behavior of the Mark Relevant button so that it is disabled if no document is selected. 
Objective Test the new Process and Type Fragment by marking a couple of
documents as relevant to the Claim.

8.0 Reports and Alerts
Now that your application allows claims to be created and handled to completion you will
configure some reports and alerts based on the Claim Processing process.
8.1 Claim Business Events
xCP utilises business events as the collection points for reporting data. The Claim model
already has a business event defined which occurs when a claim is related to a policy. When
such a relation is created attribute values are copied to the Business Activity Monitoring (BAM)
database for reporting. In this exercise, you will be defining one additional business event on
the Claim model so that you can build reports based on claims.
1. Select the Object Model tab of the xCP Navigator panel, expand the Folders
node and double-click Claim to open it for editing.
2. Select the Business Events tab of the editor and click the New
Business Event button to add a new event.
3. In the Business Event for Claim dialog enter
Claim Processed for the Label and for the
Select Trigger select Claim Updated. For the
Condition Details enter this expression: 
 
event.claim.claim_status == 2 OR 
event.claim.claim_status == 3 
 
The condition on the event ensures that the
data pushed to the BAM database is relevant
for the report you want to build. You are going
to use it to get a timestamp on when the claim
is fully processed and the status is Approved or
Denied.  
 
Click the Next button to continue.
Objective Configure a Business Event to record when the status of a Claim changes.
Getting Started with xCP 2.2 - 8.0 Reports and Alerts 185

4. Because you only want this business event to push
information to the BAM database there is no need
to configure any actions on the second page of the
dialog. Click the Finish button to close the dialog.
5. The Business Events should
now look like this.
The new Business Event will record when a Claim is approved or denied in the Business Activity
Monitoring database so that you can then build reports using that data. 

8.2 Historical Queries
8.2.1 Number of Claims by Status
This first query will be used to display a simple chart showing how many processed claims are
approved and how many are denied.
1. Select the Data Services tab of the xCP Navigator panel, right-click
on Historical Query and select New Historical Query.
2. In the New Historical Query dialog enter Number of
Claims by Status as the Label, select Folders as the
Primary model and then select Claim. Click the
Finish button to close the dialog.
3. Select the Data Collection tab of the editor. This is where you select which Business
Events the data will be taken from, allowing you to build a dataset that combines
information from multiple events. Add the Claim Processed Event to the Subscription list
by double-clicking or dragging it from the Events panel on the right.
Objective Configure Queries against the Business Activity Monitoring database for
the required reports.
Concepts Historical Queries – used to design charts that reflect past activity in the
system. Application data is taken offline and stored in a data warehouse
separate from the Documentum repository. The data returned by historical
queries can be instance data or aggregated.

4. Now select the Dataset tab of the editor and expand the Claim Processed node in the
Context Data pane on the right. This shows you the data that is available for the selected
event. Select the Claim node so that you can access the Claim attributes.
5. Double-click or drag the Object ID and Claim Status attributes from the Context Data
pane to add them to the Dataset Columns.
Object ID is added so that you may get a total count within the system. The Claim Status
attribute is added as something which will be common across multiple rows, so that you
can utilise it as a “group by” field. Any query which utilises aggregation functions such as
“count” must also have a “group by” field.
6. Select the Calculation tab of the editor. This
is where you add calculations and
aggregations on top of the dataset to define
the final output columns of the historical
query. Click the Add Calculation button.

7. In the Calculated Column dialog choose the Apply
aggregation functions radio-button and select Object
ID. 
 
Click the Next button. 
 
 
 
 
 
 
 
 
8. Check the Count checkbox and click the Finish
button. 
 
 
 
9. You do not need to do anything for the Claim Status
attribute as it is automatically defined as a “group by”
field. You can check this by selecting the Claim Status
column and looking at the Calculations tab of the
Properties panel. 
 
When a Business Event is triggered xCP only copies the attribute values to the BAM database
which are currently being utilised in Historical Queries. If you have three attributes used in a
Historical Query for a given Model that has seven attributes, only those three values will be
captured. If you then add a fourth attribute to the query at a later point, values for the fourth field
will only be captured for new events occurring from that point forward. Existing event data in the
BAM database will not hold values for the fourth attribute.
8.2.2 Average time for claim processing
The purpose of this query is to determine how much time is needed to process a claim, from
the time the process is started to when the claim is either accepted or denied.

2. In the New Historical Query dialog enter Average Claim
Processing Time as the Label, select Folders as the
Primary model and then select Claim. Click the Finish
button to close the dialog.
3. Select the Data Collection tab of the editor and this time add both events to the
Subscription list. Remember that the Process Claim event is triggered when the claim is
first created and the process is initiated. 
 
 
 
 
 
 
 
 
4. Select the Dataset tab of the editor. Notice that you can now select
attributes of the claim from either event in the Context Data pane. Be
careful when selecting attributes when you have more than one event as
it is easy to select them from the wrong event.
5. Select the Process Claim event node in the Context Data pane and add the Event Name
attribute of the event (not the Claim object) to the Dataset Columns. You don’t need to
add any other attributes yet as the rest will be calculated. 
 
 
 
 
 
6. Select the Calculation tab of the editor and click the
Add Calculation button.

7. In the Calculated Column dialog choose the Create a
duration column radio-button and click the Next
button. 
 
8. Change the Label to Claim Processing
Duration and verify that the From event is
Process Claim and To event is Claim
Processed. Because your testing of the
application will only take seconds as
opposed to days change the In value to
Seconds. Click the Finish button. 
9. You will notice in the
Calculation tab that as well
as adding the Claim
P r o c e s s i n g D u r a t i o n
column, two more columns
have been added (Created
on and Created on_1)
which are the creation
dates of the two events. 
10. Click the Add Calculation button again and this time choose the
Apply aggregation functions radio-button and select the Claim
Processing Duration from the list of Columns. Click the Next
button. 
 
 
11. Check the Average function because you want to display the
average time taken to process a claim. Click the Finish
button. 
 
 
You now have the Historical Queries configured that you need to present reports in the User Interface.
These Queries are based on data that is stored in the Business Activity Monitoring database. 

8.3 Reports Page
1. Select the User Interface tab of the xCP Navigator panel, right-click
on Application UI and select New Page. 
 
 
 
 
2. In the New Page dialog enter a
Label of Reports and click the
Finish button to create the page. 
 
 
 
 
 
 
3. Select the Layout tab of the editor and add the Average Claim Processing Time and
Number of Claims by Status historical queries by clicking the New Interaction button.
 
 
4. Now add a Column Box widget to the page and
on the General tab of the Properties panel
change the ID to charts and the Title to Charts.
5. Add a Pie Chart widget to the left column of the Column Box
widget and configure it a follows: 
 
 
a. On the General tab of the Properties panel under the Data section select Number of
Claims by Status as the Data Service Instance. The Title should be updated to
match the name of the historical query. Change the ID to claims_by_status. 
 
 
 
 
 
 
Objective Create an Application Page with Presentation Widgets to present the
data exposed by the Historical Queries defined in the previous section.

b. On the Values tab of the Properties
panel select the Claim Status field
and click the Remove button as you
only want a single pie chart, and
Claim Status will be used as the
Categories. 
 
 
 
c. Change the Label for the Count of Object ID field
to Number of Claims by Status by clicking on the
current label and entering the new value. 
 
d. Now select the Categories tab of the Properties panel.
Click the Add button to add a new Field and select Claim
Status from the drop-down list. 
 
The data displayed for the chart while in Designer is only
to give an idea of what it will look like at runtime. 
 
6. Add a Gauge Chart widget to the right column of
the Column Box widget and configure it as
follows:
 
a. On the General tab of the Properties panel under the Data section select Average
Claim Processing Time as the Data Service Instance. The Title should be updated
to match the name of the historical query. Change the ID to average_time. 
 
 
 
 
 
 

b. On the Default Display tab of the Properties panel under the Ranges section add
three ranges with the settings below. Click the Add button to add each one. 
 
 
 
 
 
 
 
 
7. Your final page layout should look like this: 
You have now configured a basic Reports page that shows reports based on historical information about
the Claim Processing Process.

8.4 Update Master Page: Reports
1. Select the User Interface tab of the xCP Navigator panel and double-click
Master to open the page for editing. 
 
2. Right-click the Document Search menu item and
select Insert Item After. 
 
 
3. On the General tab of the Properties panel change the ID to reports, the Label to
Reports, select Page as the Link destination and select the Reports page. 
 
 
 
 
 
 
In this tutorial you have added charts to an Application Page and bound them to Historical Queries, but be
aware that any of the Presentation Widgets can be added to any Page and bound to any type of Data
Service, including Stateless processes. This means for
example that you could show a chart on the applications
home page highlighting the current performance level of
the claim processing team. It is also worth noting that
these Widgets are interactive and have the concept of a
selected row. This means that you could add a Results
List widget on the same Page and have the selected Claim
Status slice in the Pie Chart Widget passed as an Input
value to a query that lists Claims with that Status.
Users will now be able to access the Reports feature from the Navigation Menu and see the reports
update as Claims are processed. 
Objective Update the Master Page so that the Reports Page is accessible from the
Navigation Menu.

8.5 Testing the Application: Reports
As mentioned earlier, BAM data will not yet exist for claims already in the system because you
had not defined the historical query that used the Claim model. As a result you will need to
create additional claims and complete all of the tasks for those claims in order for the Pie Chart
and Gauge Widget to show some data.
to the Clerk Role. The Policy Search page loads with your existing policies listed. Open an
existing policy and create at least five claims.
3. Navigate to the Tasks page and complete each First Approval task, Pre-approving some
and Denying others. Complete the Second Approval task for those you Pre-approved and
Approve them again.
4. Wait several minutes for the statistics on your newly created claims to be processed and
navigate to the new Reports page. You should see the data populating the Pie Chart and
Gauge as in the screenshot below. Try clicking on the Pie Chart to see the values.

Objective Create new Claims, process them to completion and review the results in
the Reports Page.

8.6 Alerts
8.6.1 Historical Query
The first step in configuring an Alert is to configure a historical query that the alert will use to
evaluate the trigger condition.
2. In the New Historical Query dialog enter Running
Claim Processes as the Label, select Folders as the
Primary model and then select Claim. Click the
Finish button to close the dialog.
3. Select the Data Collection tab of the editor and add the Process Claim event to the
Subscription list. This event tells you when the process started. 
 
 
 
 
 
 
 
 
4. Select the Dataset tab of the editor and configure the Dataset Columns as follows:
a. Select the Process Claim event node in the Context Data pane and add the Created
On attribute of the event. 
 
Objective Configure an Alert and Alert Query to highlight when a Claim review
process completes outside of a defined time period.

b. Select the Process Claim > Claim node and add the Object ID, Name and Claim
Status attributes of the claim. 
 
 
 
 
 
 
 
 
5. There is no need to add any calculations to this query and so you can save your changes
and close the editor.
8.6.2 Alert
The next step is to define the Alert condition and any required actions.
1. Select the Object Models tab of the xCP Navigator panel, right-click on
Alerts and select New Alert.
2. In the New Alert dialog enter Long Running Claim as
the Label, select Historical Queries as the Primary
model and then select Running Claim Processes. Click
the Finish button to create the alert. 
 
 
3. Select the Triggers tab of the editor. This is where you configure the trigger condition for
the alert. If the condition evaluates true then the alert will be raised. Enter this
expression for the Condition is true value:
differenceSeconds(now(),running_claim_proce.createdon) > 300 AND
running_claim_proce.claim_status < 2 
 
Concepts Alert – a condition that prompts the system to perform certain actions
when the condition is true. You define the logic of the condition in a
Boolean expression that the system evaluates against Historical Query
data at runtime. When the data meets the condition, the system triggers
the alert and performs the configured actions.

The expression you enter here
must return a boolean value. In
this case it will return true if more
than 300 seconds have elapsed
since the process was initiated
and the Claim Status is still
Processing or Pre-Approved. 
4. Select the Dataset tab and add the Object ID, Name, Created on and Claim Status
attributes to the Dataset Columns. These are the attributes that will be available when
the alert is raised. 
 
 
 
 
 
 
 
When an Alert is raised you can also define that one or more Stateless or Stateful Processes are
initiated (from the Actions tab). For this tutorial you will just show a list of Alerts on the Tasks Page.
8.6.3 Alert Query
Because you will display a list of alerts about long running processes you need to configure an
Alert Query so that it can be linked to a results list widget in the next step.
on Alert Query and select New Alert Query. 
Concepts Alert Query – a special type of query that returns Alert instances that have
been raised.

2. In the New Alert Query dialog enter Long Running
Claims as the Label, select Alerts as the Primary
model and then select Long Running Claim. Click
the Finish button to create the alert query. 
 
 
3. Select the Dataset tab. The Context Data pane for an alert query shows the system
attributes for an alert (such as Alert Description and Alert Severity) as well as the Dataset
Columns that you configured for the alert (such as Claim Status and Created on).
Configure the Dataset as follows:
a. Add the Object ID, Name, Created on, Claim Status, Alert Status and Alert Object
ID attributes to the Output Columns. The Alert Status denotes whether the alert
has been acknowledged or not, and the Alert Object ID is required if you want to
action the alert from its context menu.  
 
 
b. Drag the Alert Status attribute to the Predefined Inputs section. On the General tab
of the Properties panel for the Data Field change the Operator to != (does not
equal) and enter ‘Closed’ as the expression for the Value. This will have the effect
of only showing alerts that are not closed.
 
 
 
 
 
 
 
 
 
 
 
 
 

8.6.4 Update Tasks Page
The final step is to add a new results list widget to the Tasks page that will display a list of
Alerts raised about long running claim processes.
1. Select the User Interface tab in the xCP Navigator, expand the Application
UI node and double-click the Tasks page to open it.
2. On the Layout tab of the editor click the New Interaction
button and select the Long Running Claims alert query.
By default it is set to refresh on page load.  
 
3. Add a Results List widget underneath the existing Tasks results list and on the General
tab of the Properties panel set the ID to alerts, the Label to Alerts and deselect the
Enable Drag And Drop checkbox. Under the Data section select Long Running Claims as
the Data service instance.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
You have just configured a new Alert and Alert Query that will raise an Alert if any instance of the Claim
Processing Process has not completed after 5 minutes. You also updated the Tasks Page to show a list of
Alerts that have been raised. 

8.7 Testing the Application: Alerts
As with the testing of reports, before the historical query that the alert uses will return anything
you will need to create at least one claim.
to the Clerk Role. The Policy Search page loads with your existing policies listed. Create
another claim for a policy and this time do not process the tasks. You will probably need
to wait longer than three minutes, but navigate to the Tasks page and an Alert should
have been raised that will appear in the Alerts results list below the Tasks results list. 
 
 
 
 
 
 
 
 
 
 
 
3. Right-click on the Alert and choose Close to
remove the alert from the list. If you choose
Acknowledge the Alert Status will update
and the alert will stay in the list. 
 
Before moving on with the tutorial you could go back and try adding additional reports to the application
and adding a chart directly to the Policy Search page. 
Objective Create new Claims and leave the processes incomplete to check that
Alerts are raised as expected.

9
9.0 Extensions
In xCP there are numerous extension points and in this tutorial you will learn what those
extension points are and how they are accessed within xCP Designer. For more details on how
to build these extensions please refer to the Extension Point White-paper that is available on
the EMC Community Network (ECN) site (https://community.emc.com).
All of the libraries and files referenced in this tutorial should be available from same location
that this guide was downloaded from.
9.1 JavaScript Expression Functions
The function utilised in this exercise can be used to display hyperlinks inside results lists
widgets to open pages in new browser tabs so that the user can open multiple items at once.
Note that expression functions can be written in both Java and JavaScript, but they each can
only be utilised in certain areas of the application. For more details, see the Extension Points
White-paper.
9.1.1 Import Library
1. Select the Application tab in the xCP Navigator panel and double-click
Model to open the root level Application Model for editing. 
 
2. Click the Add button in the Libraries pane on the right to add a new library. 
 
 
 
 
3. Browse to the folder containing the
xfn.xTensionFunctions-2.2.0.jar
library which accompanied this
guide, select the library and click
the Finish button. 
 
 
Objective
Add a library to the application containing additional JavaScript
functions.
Concepts Library – a package of extensions (such as a theme or custom JavaScript
function) or an exported project (containing application artifacts) that can
be imported into an application to extend its functionality.
Getting Started with xCP 2.2 - 9.0 Customisations 203

The warning that some libraries cannot be added is always displayed, regardless of what libraries
are in the folder. If a library is not compatible it will be greyed out and cannot be selected.
4. The Library will be imported and appear in the Libraries
pane. Close the editor and then close and re-open xCP
Designer to enable the new functions.
9.1.2 Update View Page
1. Select the User Interface tab of the xCP Navigator panel, expand the
Application UI node and double-click the Policy Search page to open it. 
2. Select the Coverage column, right-click and choose Insert
Column After from the context-menu. 
 
3. On the General tab of the Properties panel for the new column
clear the Label of the column.
4. On the General tab of the Properties panel
for the column, under the Data section enter
the following expression:
displayLink('cia_policy', Outputs.id,
'cia_edit_policy', 'Edit', Outputs.id)
Make sure that you also change the Data
type to HTML as the output is a hyperlink 
 
The new function can be found under the
Application node of the Functions tab in
the Selector dialog.
This function takes the system name of the object type
(cia_policy), the object_id of an object instance, the system name
of the page to load, a string to display for the hyperlink itself and
finally a target reference. If you use something unique like the
object_id again each policy loads in it’s own new tab. The system
name of things like object types and pages can normally be found
on the Basics tab of the relevant editor.
5. Save you changes and close the editor. 

9.2 Testing the Application: Custom JavaScript Function
There is no need to deploy your application to test the new Javascript function because it does
not get deployed to the Documentum repository.
1. Start Preview mode by selecting the Start Preview Mode option
from the Preview mode toolbar drop-down.
2. A new Console tab opens in the Console panel.
Wait for the confirmation that the embedded
Jetty application server has started.
3. Select the Preview in Browser option from the Preview mode
toolbar drop-down and log in to the application.
4. Make sure the URL of the application is that of the Preview
mode with a port number of 8888.
5. When the Policy Search page loads each policy should have a new Edit hyperlink at the
end of the row.
6. Click on each hyperlink, and each time should get a new browser tab open up at the Edit
Policy page for that policy, while leaving the original tab open at the Policy Search page.


9.3 Java Services
Although xCP provides an extensive palette of business process activities, allowing most
business requirements to be met without coding, there are often times when custom code is
required, such as to integrate with an external system that does not provide a standards based
interface. In this tutorial you will configure a Java Service using a Java class that can append a
comment to a document when it is marked as relevant to a claim.
9.3.1 Configuring a Java Service
Java Services and select New Java Service.
 
 
 
 
2. In the New Java Service dialog click
the Add button, browse to the folder
c o n t a i n i n g t h e l i b r a r y
CollaborationOperations.jar
from the supporting material that
accompanied this guide. Select it
and click the Next button to go to
the next step of the dialog.
3. Select the class to be used for the Java service. In this example you should select
com.emc.xcp.ext.services.CollaborationOperations. Click the Next button. to go to
the next step of the dialog.
Objective Configure a Java Service that can be added to a Process to
programatically add a Comment on a document.
Concepts Java Service – a package of custom Java code that can be executed from
an activity in a Process.

4. Change the Label to Collaboration Operations and click the Finish button to create the
new Java service. 
 
 
 
 
 
5. No further changes are needed so just close the editor.
9.3.2 Updating the Mark Relevant Process
Now you will update the Document Mark Relevant Process so that it uses the new java service
to append a comment to the document that will be visible in the comments widget on the
appropriate view page.
1. Select the Processes tab in the xCP Navigator panel and double-
click Document Mark Relevant to open the process for editing. 
 
 
2. Delete the flow line that connects the Mark Relevant and End
activities.
 
3. Expand the Java node of the Activities pane and drag an Execute Java
Service activity onto the canvas between the Mark Relevant and End
activities. 
4. Draw flow lines to join everything up again. 
 
 
5. Double-click the Execute Java Service
activity and in the Activity Inspector
dialog change the name to Add
Comment.
6. Click the Select button next to Java Service, select
the Collaboration Options Java service and click the
Finish button. 

7. This Java service only has one Method,
addCommentToObject, which should be selected
automatically. Click the Next button to go to the
next page of the Execute Java Service tab.
8. Using Copy functions map the following values to the inputs of the Java service. You can
refer back to section 4.3 for detailed instructions on using the data mapping screen.
a. Add a Copy function and map the Variables > documents value to the objectIds[0]
argument. The Java service takes a list of r_object_id values.
b. Next use a Copy function to map the Execution Data > workflow > supervisor value
to the commentUser argument. This will be the name of the person adding the
comment.
c. Use another Copy function to map
the fixed string Marked relevant to
the case. to the commentText
argument.
d. Use one more Copy function to map the
value false to the keepWhenVersioned
argument to set that the comment
should not be kept on new versions of
the document.
9. Your mapping screen should look like this. Click the OK button to save the changes.

9.4 Testing the Application: Java Services
toolbar to deploy and run your application You will be prompted to stop
Preview Mode if it is running.
to the Clerk Role. The Policy Search page loads with your existing policies listed. Open a
policy, and import a new document into a claim.
3. Open the claim, select the new document and click the Mark Relevant
button. 
 
 
4. When the success message is displayed, open the
document to view it. The Comments widget at the bottom
of the page should now have a comment appended.
When adding libraries to a Java Service, the list of libraries you see is a list of all libraries for all Java
Services (hence the title Shared Java Service LIbraries. Do not remove a library unless you do not need it
for any Java Service. Because the libraries are managed as a group you must make sure that the names
of your classes are unique across libraries. 

9.5 JavaScript Widgets
Custom widgets can be added to the page editor to enhance the user experience of an
application. Widgets are packaged as libraries and added to your application in just the same
way as JavaScript functions. In this tutorial you will make use of a custom slider widget and
update the action flow for creating a new vehicle so that the year can be selected using the
slider.
9.5.1 Import Library
1. Select the Application tab in the xCP Navigator panel and double-click Model
to open the root level Application Model for editing. 
 
2. Click the Add button in the Libraries pane on the right to add
a new library. 
 
3. Browse to the folder containing the library burnett.SliderWidget-2.2.0.jar from the
Widget subfolder of the supporting material that accompanied this guide, select the
library and click the Finish button. 
 
 
 
 
4. The library will be imported and appear in the Libraries pane.
Close the editor then close and re-open xCP Designer to
enable the new widgets.
Objective Add library containing a custom Widget to extend the User Interface.

9.5.2 Update Create Vehicle Action Flow
Business Object UI > Vehicle > Create Vehicle and Relate to Policy node
and double-click Step 1 to open it. 
2. Select the Layout tab of the editor, right-click the Year widget and
select Delete to remove it.
3. Scroll down to the bottom of the Widgets pane, and check that you have a
new Custom section with two new widgets available.
4. Drag-and-drop a new Slider widget (not the Advanced Slider)
onto the layout to replace the control you deleted. 
 
5. On the General tab of the Properties panel set a value of year for the ID, Year for the
Label, 1990 for the Minimum Value and 2020 for the Maximum Value. For the Value
enter an expression of 2015 as the initial value. This widget expects an integer and so
the expression does not require any quotes around it. Note that this widget was originally
build for xCP 2.1 and so does not support the option to define it as mandatory. 
 
 
 
 
 
 
 
 
6. Because you kept the ID of the widget the same (year) there is no need to change
anything else in the action flow configuration and so you can save your changes and close
the editor. 

9.6 Testing: Custom Widget
Because this is just a runtime change you can test the changes using Preview Mode.
1. If you don’t have it started already then start Preview Mode by selecting
the Start Preview Mode option from the Preview Mode toolbar drop-
down.
2. A new Console tab opens in the Console panel. Wait
for the confirmation that the embedded Jetty
application server has started.
3. To launch the browser in preview mode select the Preview in Browser
option from the Preview Mode toolbar drop-down. 
 
 
4. Log in to your application as the user that you added to the Clerk Role. The Policy Search
page loads with your existing policies listed. Open a policy for editing and add a new
vehicle. When the Create Vehicle and Relate to Policy action flow loads you should see
the new Year slider widget in the dialog.

9.7 Clear Blue Theme
Themes are packaged as libraries and added to your application in just the same way as
JavaScript functions and widgets. For this tutorial however you will not be adding a library as
xCP provides a sample custom theme that can be selected for your application. Details on how
to build a theme are provided in the extension points white paper.
A theme is selected from the Master page as follows.
1. Select the User Interface tab of the xCP Navigator panel and double-click
Master to open the page for editing. 
 
2. Select the Basics tab and select Clear Blue as the
Application theme. Click the Apply button to apply
the theme. 
 
The theme will be compiled and then applied to the
application. 
 
 
 
 
 
 
3. Once the theme has been applied, select the Layout tab and
you should see the change immediately, with the Navigation
Menu changing from black to blue.
4. Close the editor.
Application UI node and double-click Policy Search to open it for editing.
Objective Change the theme of the application to override default styles, and apply
custom styles to Widgets on the Policy Search Page.

6. Again, you should notice the change
in the style of the page, with the
background pattern removed and
bold labels for the widgets.
7. Select the column that
contains the Last Policy
information as you will
use a custom style to
make it stand out on the
page as follows: 
 
 
a. On the General tab of the Properties panel
select Vertical for the Orientation. 
 
b. Drag a Column Box widget onto the layout inside the column underneath the Open
Last Policy button widget. Right-click on one of the columns and select Delete so
that you are left with a single column. On the General tab of the Properties panel
set the ID to last_policy and the Title to Last Policy. 
 
 
 
c. Drag the Page Fragment widget and the Open Last Policy
button widget into the new Column Box widget.
d. Finally, select the Last Policy column box widget and on the Style tab
of the Properties panel enter the custom styles box-body-clouds box-
head-silver for the CSS class (take
care to leave a space between the
styles). The column box widget
will update to reflect the styles. 
 

e. Now select the Open Last Policy button widget
and on the Style tab of the Properties panel
enter the custom style button-s-greensea for the
CSS Class. The button widget will update to
reflect the new style. 
9. You can test changes like these using Preview mode, although you may need to restart
preview mode in order to see them. Your final page should look something like this.  
You will also notice that the theme updates the style of the login page, removing the default xCP
Logo. You can add your own logo to the source files of the application to be shown on the login page
when you use the Clear Blue theme. Check the designer help for details on where the file should be
placed.
Why not go back and apply styles to the other Pages in the application. The list of supported styles and
colours are given in the inline Designer help.
Congratulations - you have completed the tutorial and you have a working application that showcases
many of the great features of xCP.

9
Appendix A: Introduction to User Interface Design
There are many books and online articles about good User Interface (UI) design that will teach
you all you need to know about building a really good application. The purpose of this appendix
is not to summarise everything you need to know, but simply to highlight some of the key things
to consider.
Principles
Alignment & Spacing
Column box widgets are the main container that you will use to build columns of information on
a page. Be careful to minimise the nesting of column box widgets for the sake of performance
but do make use of them to lay out the information on the page in a clear and intuitive order.
As a general rule, controls should be left-aligned in one or more columns, and you should
adjust the spacing to make sure it is clear which label is associated with which field.
Screen Size
When configuring an application it is most likely that you will be using a computer with a higher
resolution screen than that of your target users. Consider the effects of running you
application on a lower-resolution screen, and test using a browser window that is the correct
size for your users.
When the amount of information you need to display on a single screen requires more space
than you have, you can either make the page longer so that the user has to scroll up and down,
or use tabs. Both are good solutions, as most people are used to scrolling web pages up and
down, and tabs are a very common UI paradigm. The thing to avoid is making a user scroll
horizontally, especially in results lists.
When using tabs pay attention to actions that are invoked from the tab, such as the adding of a
claim in this tutorial, to make sure that when the action is completed the whole page is not
refreshed and the tab focus lost.
Consistency 
User friendly interfaces are predictable and understandable. It is a good idea to settle on a UI
design early on and stick to it, documenting the padding and spacing requirements for each
type of page if you are working as part of a development team so that everyone can configure
UI elements consistently.
Context
Although the navigation menu widgets shows a marker highlighting which selection was
chosen, when you navigate within the main functional area (e.g. to sub-menu pages or task
pages) make sure the current context is clearly visible, such as the case number being
updated, or the name of the current task in the process and some indication of how many
steps have gone before and how many are left in the process.
Getting Started with xCP 2.2 - Appendix A: Introduction to User Interface Design 216

Language
Most of the time the default buttons added to pages such as Search, Complete, Finish and
Acquire should have their labels changed to better reflect the action being performed. When a
default Search button is added to a results list widget for example, and there are no input
fields, you can relabel the button as Refresh instead. Similarly on a task page it is better to
rename the Acquire button as Work on Task or Accept Task.
Example
To illustrate these principles, the following screenshot shows what the First Approval task page
looks like after you have configured it from a functional perspective following this tutorial. 
 
And after updating the margins of the Master page and on the Task page updating the policy
page fragment a little, rearranging fields, modifying the column properties and using some
additional theme styles the page can look more like this. 
 
Whilst still not perfect, it is (hopefully) clearer what the page is showing and what the user is
meant to do.
Getting Started with xCP 2.2 - Appendix A: Introduction to User Interface Design 217

EMC Documentum xCP 2.2 Self Paced Tutorial v1.0

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to EMC Documentum xCP 2.2 Self Paced Tutorial v1.0 (20)

Recently uploaded (20)

EMC Documentum xCP 2.2 Self Paced Tutorial v1.0