Product: OpenText Content Server

Version: 9.5.x, 9.6, 9.7.x, 10.0.0, 10.5

Task/Topic: Features & Functionality
Audience: Administrators
Platform: All
Document ID: 500046
Updated: May 23, 2014

Discussion Paper
Understanding Content Server
Notifications and Event Processing
Mark Simm, Principal Technical Analyst
Contents
Summary ......................................................................................................................3 
Notification Event Processing ................................................................................... 4 
Key Components of Notifications ........................................................................... 4 
AgentIDs .......................................................................................................... 4 
Notification Tables ............................................................................................ 5 
Triggers ............................................................................................................ 5 
Agent Controller ............................................................................................... 5 
Overview of Notification Event Processing............................................................. 6 
Performance ........................................................................................................... 7 
Multi Event Processing .............................................................................................. 8 
Overview Multiple instances of Livelink .................................................................. 8 
Configuring Multi Event Processing ....................................................................... 9 
The [scheduleactivity] explained .................................................................... 10 
Example ................................................................................................... 11 
Processing the Admin Separately ........................................................................... 15 
Overview ............................................................................................................... 15 
Process Admin separately and the overflow processor ....................................... 15 
About OpenText ........................................................................................................ 17 

2
Summary
This document is designed to help understand the basic design and workflow of
Livelink ECM – Enterprise Server (Livelink) covering versions 9.5.x, 9.6, and 9.7.x as
well as OpenText Content Server (OTCS) versions 10.0.0 and 10.5 Notifications and
Event Processing. This document does not cover every available agent, nor does it
cover any of the functionality related to eLink.
The items discussed in this document are the terms and definitions, database tables,
Notification AgentIDs, triggers, event processing and performance tips.

3
Notification Event Processing

Key Components of Notifications

AgentIDs
The table below describes the AgentIDs that are responsible for processing Livelink
events to Notification messages.

AgentID Role

1000 Inserts all late Workflows, Workflow steps, Tasks and Poll
(Late Event Producer) Closed.
Runs at midnight.

4000 Deletes events from the NotifyMessages table once the

(Expire Messages) default of 30 days has been reached.
Runs every 5 minutes

Subagent 4001 Removes Handler Events from the LLEventQueue after

(Expire Handler Events) the 9001 agent runs.
Runs every 5 minutes

8999 Processes events from the NotifyEvents table, inserts

(Clear Notify Events) them into LLEventQueue and assigns them to individual
consumer IDs (5001: eLink, 9001: Livelink).

9000 Processes events by running the node processors 5001

(Event Processor) (eLink) and 9001 (Livelink).

Subagent 9001 Processes events in the LLEventQueue into messages by

(Node Event Processor) checking for user interests, permissions, privileges and
transfer the entries into NotifyMessages

9999 Individual user agents that are responsible for emailing

(Internal User Agent) the notification report by sending out the NotifyMessages
to the SMTP server for email delivery, based in the
schedule configured.

4
Notification Tables
Event processing relies on the following tables to store the LES events while the
above AgentIDs process and converts them to messages. Below is a brief
description of the purpose for each table.

AgentID Purpose

AgentConfig Notification configuration is stored in this table

AgentSchedule Stores AgentID schedule configuration that the Agent Controller uses
in order to run Agents based on NextTime parameter. Contains
system-wide scheduled Notifications and personal user schedules
that override the default schedules in the AgentConfig table.

AgentStats This table stores Notifications run-time statistics.

LLEventQueue This table takes events from the NotifyEvents table and assigns them
to individual consumer IDs based on the EventHandlerID.

NofifyEvents Stores all events created by triggers and the Late Event Producer
(1000) for tracking.

NotifyInterests2 Contains individual user Notification interests stored in a bitmask

format.

NotifyMessages This table stores Notification messages that appear in the Notification
reports or in the messages that are e-mailed out to other users.

Triggers
Triggers are created when Notifications are enabled from the Livelink GUI –
“notify.config”
• NOTIFYDTREEINSERT
• NOTIFYDTREEUPDATE
• NOTIFYDVERSDATADELETE
• NOTIFYDVERSDATAUPDATE
• NOTIFYKUAFCHILDRENINSERT
• NOTIFYWORKAUDITINSERT

Agent Controller
The Agent Controller runs in the context of the Livelink Admin user. The Admin user
owns the key AgentIDs (UserID 1000), whereas the remaining AgentIDs (9999) are
owned by individual users. There is a maximum of three AgentID 9999 per user.
Every five minutes the Agent Controller runs and executes Agent101 and Notify102.
It queries the AgentConfig table for the NextTime run value. It then scans the
AgentSchedule table and will execute all AgentIDs based on SchedID and
NextTime value. It will then update the LastTime and NextTime values upon
completion.

5
 Overview of Notification Event Processing
The following diagram (Figure 1-1) outlines the notification event processing that
takes place within the Livelink schema. This document does not cover the
configuration of agents on the user side.

Figure 1-1

The Notification subsystem uses a variety of AgentIDs and Tables to process events
that are added, deleted, late or updated within the Livelink environment.
1. When an item is added to Livelink, an event is generated (by means of Database
triggers) and inserted into the NotifyEvents table.
2. The AgentID 8999 (ClearNotifyEvents) processes the events in NotifyEvents,
and will then insert these events into the LLEventQueue table; then delete these
events from NotifyEvents.
3. Once 8999 completes its scheduled run, the AgentController will run in the
context of the Admin user every 5 minutes on the Livelink server time.
4. Two threads are spawned to allow the agents to execute. The first being the
“Notify” (Notify102) thread which is responsible for all agents related to
notifications. The second thread is the “Agents” (Agents101) which executes
other agents to do various other unrelated notification functions (i.e. SOV alert,
rendition, purge undelete volume etc…)
5. AgentID 9000 (Consumer Agent) executes and processes the events from
LLEventQueue. By default, the AgentID 9001 will take a maximum of 1000
events per Agent Controller Run. AgentID 9001 will then verify which user has
an interest set on each of the events. If so, do they have permissions to see it
before creating a message into the NotifyMessages table? One record is
created for each user that has an interest set. After the message is created in
NotifyMessages, the User should be able to see it in their Personal >
Notifications menu under the report they used to set the interest.
6. AgentID 9999 then scans the NotifyMessages table processing all messages
that are emailed out at this time and are ‘emailed enabled’ for a given user
notification report. Once the message is sent to the SMTP server, it is deleted
from the NotifyMessages table and Livelink no longer tracks it.

6
Performance
The following table reviews performance inhibitors and enhancements:
LES Admin instance
Bulk Load Patch
Database Tuning (Oracle)
EnableAgentsTestAll=FALSE
Global interests
Late events
Livelink Cluster
Configuration
Multi Event Processing
Recursive Groups (Oracle)
Notifications and Search can be taxing when
configured on the same Livelink instance. If the option
to setup a separate dedicated instance of LES for
Agents and Notifications on the Back End Admin
server is selected, be sure that the server hardware
has adequate resources to run Search and Indexing on
the main LES instance as well.
A more efficient way to run Agents and Notifications is
to set them up on a dedicated instance of Livelink,
either on the Front End server or the Back End server.
This separate instance would not be included in the
Load Balancer pool, and therefore would receive no
requests from the user community. All of its resources
would be committed to the Agents and Notifications.
This patch is applied to the Livelink 9.5 SP1 instance
running Notifications. An opentext.ini file
modification is created to exclude the NodeIDs of the
parent folder being moved, copied or bulk loaded.
Refer to the “Best Practices – Oracle for Livelink ECM
– Enterprise Server”
Never set to TRUE. This will force the AgentController
to run all the AgentIDs from the AgentSchedule in the
next run.
User setting interests on things such as “notify me
when an item is added” can degrade performance.
Archiving or deleting old Workflows can help lighten
the load for event processing.
Contact Open Text Customer Support for additional
help, cluster configuration can be difficult and if not
properly deployed it can be harmful to the rest of the
environment
This should not be deployed without having consulted
with OpenText Customer Support. This is generally a
last resort effort to improve event processing.
Will cause issues with caching user rights. Scripts are
available to help identify recursive group structure in
Livelink. This can be disabled in Livelink 9.7 by going
to “func=user.GroupSettings” and selecting the check
box Prevent Recursive Groups
7
Multi Event Processing

Overview Multiple instances of Livelink

Livelink version 9.5.x introduces Multi Event Processing that allows the Livelink
Administrator to define how many NodeEventProcessor event handlers will run
simultaneously. By default Livelink is configured with one NodeEventProcessor that
is AgentID 9001; however this is now configurable up to eight processors.

NOTE: Multi Event Processing is only supported across multiple

instances of LES. One NodeEventProcessor per instance.

If the Administrator requests more than one NodeEventProcessor instance or

requests that Admin user be processed separately, one additional agent/handler will
always run (the “overflow processor”). The individual instances of the
NodeEventProcessor agent will process a range of UserIds and will not be
separately schedulable. The Administrator will define a single schedule that applies to
all instances.
At agent runtime, each NodeEventProcessor instance will know its range of users
(set at initialization from opentext.ini). It will then load the interests of all of those
users; as opposed to the current method of loading all interests for all users and will
load all of its events.
For example, if only one Event Processor is used and there is a 1000 user’s
configured then the AgentID 9001 will processor those 1000 users each Agent
Controller run. With MultiEventProcessing, you have the ability to set up to eight
processers. For example, if the Livelink Admin selected four EventProcessors with
1000 Livelink users; the following scenario would be the event processing that would
occur within the Livelink—When the Agent Controller runs, AgentIDs 9001, 9002,
9003 and 9004 will simultaneously run 250 user’s each. The ‘range’ of users is
outlined in the opentext.ini file within the [scheduledactivity] section.
Each Agent will then process 1000 events (by default) each from the LLEventQueue
based on permissions, privileges and interests.

NOTE: It is highly recommended that before proceeding with any

configuration that Open Text Customer Support be consulted for
additional information.

8
 Configuring Multi Event Processing
To enable Multi Event Processing the Livelink Admin will need to access
“http://(ServerName)/(InstanceName)/livelink.exe?func=ConfigScheduledActivities”
and then select the amount of processors desired (Figure 2-1). Each Livelink
environment will be significantly different based on throughput and hardware
resources. Due to this reason, there are no specific parameters available to state the
exact number of processors to use for any given environment.

Figure 2-1

In the following scenario, three processors have been selected, and the AgentIDs
will be distributed across four Livelink Servers. By selecting three
NodeEventProcessors, two additional AgentIDs are created along with an overflow
agent; 9001, 9002, 9003 and 9004 (Overflow Agent). Figure 2-2 illustrates the nine
load balanced Livelink users once multiple event processors have been selected.

Figure 2-2

9
Prior to Multi Event Processing being enabled the [scheduleactivity] section of
the opentext.ini will appear as a left hand column. Once multiple event processors
are selected, the [scheduleactivity] section is updated to reflect the user range
that each processor is responsible for; the right hand column displays the new
configuration.

Default Configuration Multi Event Processing Enabled

[scheduleactivity] [scheduleactivity]
1000=1 9004=1
4000=1 9003=1
4100=0 9002=1
4101=0 9001_UserRange_3={{3438,3448}}
4102=0 9001_UserRange_2={{3425,3433}}
8900=1 9001_UserRange_1={{1000,3420}}
8999=1 9001_SeparateAdmin=false
9000=1 9001_Instances=3
9001=1 1000=1
3502=1 4000=1
8000=1 4100=0
4101=0
4102=0
8900=1
8999=1
9000=1
9001=1
3502=1
8000=1

The [scheduleactivity] explained

An AgentID can only be 1 (enabled) or 0 (disabled). When the AgentID is set to 1, in
order for it to be completely enabled for this instance of Livelink, the corresponding
thread that controls that agent must be run on this instance. For example, although
AgentID 9004=1, if the [loader] section of the opentext.ini does not include
the notify thread, then this agent will not run from this machine.
[Options]
EnableAgents=TRUE
EnableAgentsTrace=FALSE
EnableAgentsTestAll=FALSE
EnableNotification=TRUE

10
[loader]
load=sockserv;javaserver;agents;notify

[scheduleactivity]
9004=1
9003=1
9002=1
9001_UserRange_3={{3438,3448}}- Agent 9003 will process the UserRange
listed
9001_UserRange_2={{3425,3433}}- Agent 9002 will process the UserRange
listed
9001_UserRange_1={{1000,3420}}- Agent 9001 will process the UserRange
listed
9001_SeparateAdmin=false - The Admin user will be process by the 9001 agent
9001_Instances=3 - Describes how many event processors were selected
1000=1
4000=1
4100=0
4101=0
4102=0
8900=1
8999=1
9000=1
9001=1
3502=1
8000=1

Example
This is how the scenario configuration will be implemented.
Front-End_1: Process AgentID 9001
Front-End_2: Process AgentID 9002
Front-End_3: Process AgentID 9003
Admin_4: Process AgentID 9004 and remaining agents.

11
Front-End_1:
[Options]
EnableAgents=TRUE
EnableAgentsTrace=FALSE
EnableAgentsTestAll=FALSE
EnableNotification=TRUE

[scheduleactivity]
9004=0
9003=0
9002=0
9001_UserRange_3={{3438,3448}}
9001_UserRange_2={{3425,3433}}
9001_UserRange_1={{1000,3420}}
9001_SeparateAdmin=true - Changed to ‘true’ for the Admin to process
separately
9001_Instances=3
1000=0
4000=0
4100=0
4101=0
4102=0
8900=0
8999=0
9000=0
9001=1
3502=0
8000=0

[loader]
load=sockserv;javaserver;agents;notify

[agents]
lib=.\bin\lljob.dll
name=lljob
prio=critical
timeout=5000

12
info=.\config\opentext.ini;agents
StartScript=.\scripts\llfull.lxe
JobScript=.\scripts\agent_run.e
CRON=0,5,10,15,20,25,30,35,40,45,50,55 * * * *
SleepIntervalSec=60
ExcludeActivityIDs=9001 - “ExcludeActivityIDs “lists the agents that the
Agent Thread will ignore to run. By default, any AgentID not listed here will run off
the Agent Thread.

[notify]
lib=.\bin\lljob.dll
name=lljob
prio=critical
timeout=5000
info=.\config\opentext.ini;notify
StartScript=.\scripts\llfull.lxe
JobScript=.\scripts\agent_run.e
SleepIntervalSec=300
ActivityIDs=3000,3501,5000,8999,9000,9001,9002,9003,9004,9999
- “ActivityIDs” lists the agents specifically run on the Notify Thread. Both the
ActivityIDs and ExcludeActivityIDs should contain the same AgentIDs.

Front-End_2:
Same configuration as Front-End_1 however all AgentIDs will be set to 0 except
9002 is 1 (enabled) within the [scheduleactivity] section. The [agents]
thread remains the same while the [notify] thread slightly changes.
[notify]
lib=.\bin\lljob.dll
name=lljob
prio=critical
timeout=5000
info=.\config\opentext.ini;notify
StartScript=.\scripts\llfull.lxe
JobScript=.\scripts\agent_run.e
SleepIntervalSec=300
ActivityIDs=9002

13
Front-End_3:
Same configuration as Front-End_1 and Front-End_2 however all AgentIDs will be
set to 0 except 9003 is 1 (enabled) within the [scheduleactivity] section. The
[agents] thread remains the same while the [notify] thread slightly changes.
[notify]
lib=.\bin\lljob.dll
name=lljob
prio=critical
timeout=5000
info=.\config\opentext.ini;notify
StartScript=.\scripts\llfull.lxe
JobScript=.\scripts\agent_run.e
SleepIntervalSec=300
ActivityIDs=9003

Admin_4:
The Default Admin server will run the remaining AgentIDs. If you are using WorkFlow
the [loader] section of the opentext.ini file for the Admin server should include the
“wfagent” thread. All Agents will be set to 1 with the exception of the following, which
will be set to 0: 4100, 4101, 4102, 9001, 9002 and 9003. The 9004 agent is the
overflow agent that will be discussed in Chapter 3 in more detail. The [agents]
thread remains the same while the [notify] thread slightly changes.

[notify]
lib=.\bin\lljob.dll
name=lljob
prio=critical
timeout=5000
info=.\config\opentext.ini;notify
StartScript=.\scripts\llfull.lxe
JobScript=.\scripts\agent_run.e
SleepIntervalSec=300
ActivityIDs=3000,3501,5000,8999,9000,9004,9999

14
 Processing the Admin Separately

Overview
In order to maintain the configuration for the multi event processing within Livelink
v9.5.0.1, adhere to the following information.
When the Administrator checks either “Rebalance users” or changes the number of
processors, the system will determine how many users are currently in the system
and will divide the number of users as evenly as possible between the number of
instances requested, storing this division in opentext.ini within the
[scheduleactivity] section.

Process Admin separately and the overflow processor

Since many consumer events are processed as the Admin user (UserID 1000), the
Livelink Administrator may choose to have the Admin user’s notification events
processed separately. The extra agent would then process the admin user, as well as
any users missed by the other agents. So that the Administrator has some idea how
balanced the load is between NodeEventProcessor agent instances, the GUI will
display the number of users in each agent.
By selecting the “Process Admin Separately” from Figure 3-1, you will notice that
there is now one user listed in the overflow processor—this is the Admin user. Agents
9001, 9002 and 9003 will be responsible for processing the User Ranges from the
[scheduleactivity] and AgentID 9004 at this point will only process events
specifically for AgentID 1000.
CHECK SCREEN CAPTURES

Figure 3-1

15
 Additionally, any time new users are added to Livelink, they are added to the overflow
process until they are rebalanced. In Figure 3-2, the overflow processor lists four
users, this consists of the Admin account and three newly created Livelink users. By
selecting rebalance and then clicking on Submit, the Livelink server service will need
to be restarted in order for these changes to be complete since the opentext.ini
file needs updating.

Figure 3-2

Once the Livelink service has been recycled, the rebalanced users are displayed as
illustrated in Figure 3-3. The next step is updating the remaining Front-End_1,
Front-End_2 and Front-End_3 opentext.ini files. Each instance requires that the
UserRange be updated so that each applicable 9001, 9002 and 9003 AgentID has
the new range to process. Without updating this step, users that were recently added
to Livelink will not receive notifications—provided the agent has no idea that
particular user exists.
Here is the updated [scheduleactivity] section that is to be copied to each of
the three Front-End Livelink instances. Once the changes have been applied, the
opentext.ini file must saved and the Livelink server be restarted.
[scheduleactivity]
9001_UserRange_3={{3443,9896}}
9001_UserRange_2={{3430,3438}}
9001_UserRange_1={{3415,3425}}

Figure 3-3

16
 About OpenText
OpenText is the world’s largest independent provider of Enterprise Content
Management (ECM) software. The Company's solutions manage information for all
types of business, compliance and industry requirements in the world's largest
companies, government agencies and professional service firms. OpenText supports
approximately 46,000 customers and millions of users in 114 countries and 12
languages. For more information about OpenText, visit www.opentext.com.

17
Copyright © 2014 OpenText SA and/or OpenText ULC. All Rights Reserved. OpenText is a trademark or registered trademark of OpenText SA and/or OpenText ULC. The list of trademarks is not exhaustive of other trademarks, registered
trademarks, product names, company names, brands and service names mentioned herein are property of OpenText SA or other respective owners.