AdminGuideEDA13 0

For Global
ASSET ARENA INVESTONE Asset Managers
Administration Guide
June 30, 2015
Release 13.0
United States United Kingdom

377 East Butterfield Road 25 Canada Square
Lombard, IL 60147 40th Floor
Phone: (630) 920-3100 London, United Kingdom E14 5LQ
Fax: (630) 920-9116 Phone +44 (0) 20 8081 2000
Fax: +44 (0) 20 8081 2261
Email Client Services: AAIA.CSC.NA@sungard.com  General Info: www.sungard.com/financialsystems.aspx

Record of Revisions
Date of Revision Revisions

December 11, 2012 Initial Release of Enterprise Distributed Administration Guide
Documentation
February 5, 2013 Significant changes to Process Manager
February 7, 2013 Added sub-sections under Browser Reports (HOW TO UPLOAD CUSTOM
BROWSER REPORT PARAMETERS AND TEMPLATES TO ENTERPRISE, HOW TO EXPOSE
A ‘VERY HIDDEN’ SHEET IN AN EXCEL 2007 WORKBOOK) and RTK Reports
(PROCESS MANAGER TASK PARAMETERS REQUIRED FOR RTK REPORT PRESENTATION
OBJECT ‘NONE - From Date + 1’ OR ‘NONE - From Date - 1’)
February 12, 2013 Added sub-section under Process Manager (Report Packaging -
Custom Report Package Template)
March 11, 2013 Removed Client Process Manager Configuration Migration section
1.10.1.2
April 1, 2013 Changed BatchReports processing section to reflect the removal of
its useage of FTPPoller class in 12.0. Added a new section for Engine
Reconciliation report processing for which the FTPPoller is now
exclusively used.
May 15, 2013 Added additional package names for Enterprise logging.
November 25, 2013 Added EngineReportPollerService troubleshooting steps
December 4, 2013 - Updated: Report Packaging - Custom Report Package Template.
- Updated: HOW TO UPLOAD CUSTOM BROWSER REPORT
PARAMETERS AND TEMPLATES TO ENTERPRISE.
- Updated: HOW TO EXPOSE A ‘VERY HIDDEN’ SHEET IN AN
EXCEL 2007 WORKBOOK THAT IS SAVED FROM THE VIEWER.
- Rewrote: RTK Reports.
January 9, 2014 - Addition of Security Access Reports
February 13, 2014 Removed references to Remote EMS C++ capability. This included
removal of EMS Engine Host/Port configuration fields from “Process
Manager Configuration UI- Definition Tab” section. In addition the
Remote EMS configuration properties were removed from section
“2.2 ARCHITECTURE TABLES”.
February 13, 2014 Added new sections for the below functionality:
- 1.10.10 Admin Process Monitor
1.10.11 Architecture Property Maintenance
February 13, 2014 Added EMS.IoConnectionTimeOutMillis to Architecture Table section 2.2
Month dd, 2014 Updated for release 13.0.
March 23, 2014 Update to 2.3 Excel Executor xml file to add ConvertCharacterDate
parameter
June 16, 2014 Added archtecture property to revert back to the 13.1 and earlier
XSS Filter
October 8, 2014 Update Process Manager section 1.10.1 to show new Allocation
Match type configuration and behavior. This is applicable for release
13.6 and later.
February 17, 2015 Update Process Manager section 1.10.1.3 to include Status and
Description grid.
March 13, 2015 Added section 8.1 for Weblogic to discuss analyzing Stuck Threads
April 24, 2015 Added section 1.10.8 Excel Redirect Setup
June 30, 2015 Updated table values in Section 2.2 ARCHITECTURE TABLES
ADMINISTRATION GUIDE 13.0 ENTERPRISE DISTRIBUTED ARCHITECTURE

© 2015 SunGard. SunGard, the SunGard logo and Asset Arena are trademarks or registered
trademarks of SunGard Data Systems Inc. or its subsidiaries in the U.S. and other countries. All other
trade names are trademarks or registered trademarks of their respective holders. All rights reserved.
No part of this document may be reproduced, transmitted or stored electronically without SunGard’s
prior written permission.
This document contains SunGard's confidential or proprietary information. By accepting this

document, you agree that: (A)(1) if a pre-existing contract containing disclosure and use
restrictions exists between your company and SunGard, you and your company will use this
information subject to the terms of the pre-existing contract; or (2) if no such pre-existing contract
exists, you and your Company agree to protect this information and not reproduce or disclose the
information in any way; and (B) SunGard makes no warranties, express or implied, in this document,
and SunGard shall not be liable for damages of any kind arising out of use of this document.
Asset Arena InvestOne 1
Table of Contents
Preface ..................................................................................................................... 3
WHO SHOULD READ THIS GUIDE? ................................................................................... 3
WHAT’S COVERED IN THIS GUIDE? ................................................................................... 3
OTHER SOURCES OF INFORMATION ................................................................................... 4
CONTACTING CUSTOMER SUPPORT.................................................................................... 5
NOTATION CONVENTIONS ........................................................................................ 5
1 OVERVIEW .......................................................................................................... 6
1.1 SYSTEM REQUIREMENTS ........................................................................................ 7
1.2 ENTERPRISE TECHNOLOGIES (PENDING) ..................................................................... 7
1.3 JAAS ............................................................................................................. 7
1.4 PASSWORDS (PENDING) ........................................................................................ 7
1.5 BRANDING (PENDING) ....................................................................................... 7
1.6 PRINTERS (PENDING) ........................................................................................ 7
1.7 MEMORY SETTINGS (PENDING) ............................................................................. 7
1.8 SERVER STARTUP SETTINGS (PENDING) ................................................................... 7
1.9 ENTERPRISE COMPONENTS (PENDING)..................................................................... 7
1.9.1 Ear file (Pending)....................................................................................... 7
1.9.2 Excel Executor (Pending) ............................................................................ 7
1.9.3 FTP (Pending) ........................................................................................... 7
1.9.4 ActivePDF (Pending) .................................................................................. 7
1.9.5 IBM MQ (Pending) ..................................................................................... 7
1.10 ENTERPRISE MODULES .................................................................................... 7
1.10.1 Process Manager .................................................................................... 7
1.10.1.1 Process Server Definition ................................................................... 10
1.10.1.2 Process Submission ........................................................................... 24
1.10.1.4 Librarian .......................................................................................... 40
1.10.1.5 Report Retention/Report Cleanup ........................................................ 41
1.10.1.6 Multi-threading (Pending) .................................................................. 42
1.10.1.7 XAMIN Specific Functionality (Pending) ................................................ 42
1.10.1.8 IMpower Specific Functionality (Pending) ............................................. 42
1.10.1.9 Report Packaging - Custom Report Package Template ........................... 42
1.10.2 CPS .................................................................................................... 45
1.10.3 EMS.................................................................................................... 45
1.10.3.1 Multi-threading (Pending) .................................................................. 45
1.10.3.2 Dedicated EMS Servers ...................................................................... 45
1.10.3.3 External Datasource Configuration ...................................................... 46
1.10.4 Expense Calculator ............................................................................... 46
1.10.5 MFC (Pending) ..................................................................................... 46
1.10.6 Reporting ............................................................................................ 46
1.10.6.1 Browser Reports ............................................................................... 46
1.10.6.2 RTK Reports ..................................................................................... 50
1.10.6.3 Adhoc Reports (Pending) ................................................................... 51
1.10.6.4 Batch Reports ................................................................................... 51
1.10.6.5 Engine Reconciliation Reports ............................................................. 55
1.10.6.6 Hybrid Reports (Pending) ................................................................... 56
1.10.6.7 Security Access Reports ..................................................................... 56
1.10.6.8 GCR Reports .................................................................................... 67
1.10.6.9 EMS Reports .................................................................................... 67
1.10.6.10 Browser Spectra ............................................................................... 67
1.10.7 Report Viewer ...................................................................................... 67
1.10.8 Excel Redirect Setup ............................................................................. 67
1.10.9 Brokers (Pending) ................................................................................ 70
1.10.10 Decalog (Pending)............................................................................. 70
1.10.11 Admin Process Monitor ...................................................................... 70
1.10.12 Architecture Property Maintenance ...................................................... 73
2 Application Configuration .................................................................................... 85
ENTERPRISE DISTRIBUTED ARCHITECTURE 13.0 ADMINISTRATION GUIDE
2 Asset Arena InvestOne
2.1 BOOTSTRAP .................................................................................................... 85
2.2 ARCHITECTURE TABLES ....................................................................................... 85
2.3 EXCEL EXECUTOR XML FILE................................................................................... 92
3 Application Logging ............................................................................................ 92
3.1 ROLLING LOGS, FILE SYSTEM USAGE/IMPACT, BEST PRACTICES ......................................... 95
3.2 MERCURY LOG (PENDING) ................................................................................... 95
3.3 EXCEL EXECUTOR LOG (PENDING) .......................................................................... 95
3.4 IOEXCELREPORT LOG ......................................................................................... 95
3.5 ACCESS LOG (PENDING) ..................................................................................... 96
3.6 APPLICATION SERVER LOG (PENDING) ..................................................................... 96
3.7 OPERATING SYSTEM LOG (PENDING)....................................................................... 96
3.8 MULTI-SERVER ENVIRONMENT (PENDING) ................................................................. 96
4 Single Sign-On (Pending) .................................................................................... 97
5 WebServices (Pending) ....................................................................................... 99
6 Data Extracts (Pending) .................................................................................... 101
7 Ole (Pending) .................................................................................................. 103
7.1 COM OLE (PENDING) ...................................................................................... 103
7.2 JAVA JOLE (PENDING) ...................................................................................... 103
7.3 SERVER OLE (PENDING) ................................................................................... 103
7.4 DESKTOP OLE (PENDING) .................................................................................. 103
8 Appserver Specific Configuration/Tuning (Pending)............................................... 103
8.1 WEBLOGIC.................................................................................................... 103
8.1.1 Stuck Thread Analysis ............................................................................ 103
8.2 WEBSPHERE (PENDING) ................................................................................... 105
8.3 TCSERVER (PENDING) ..................................................................................... 105
8.4 TOMCAT (PENDING)......................................................................................... 105
Appendix............................................................................................................... 106
DATABASE SCHEMA DIAGRAM GUIDE............................................................................. 106
Index.................................................................................................................... 107

PREFACE
This guide provides information for Administrators to be able to configure and

administer the Asset Arena Investment Accounting Distributed Architecture
(Enterprise DA) environment.
WHO SHOULD READ THIS GUIDE?
Administrators who are responsible for the administration and configuration of the
Enterprise Distributed Architecture environment for their Users.
WHAT’S COVERED IN THIS GUIDE?

OTHER SOURCES OF INFORMATION
Your Asset Arena Investment Accounting Distributed Architecture software includes

documentation for each phase of the implementation. The following table provides a
complete list of Asset Arena Investment Accounting Distributed Architecture
documentation.
Refer to this Document: Purpose of Document:

Asset Arena Investment Accounting This document provides general information
Distributed Architecture – User’s for all users of Asset Arena Investment
Guide Accounting with regard to login, general
layout, navigation, user preferences, and
other information necessary to successfully
use the features available in Asset Arena
Investment Accounting.
Asset Arena Investment Accounting The purpose of this document is to describe

Distributed Architecture – Installation the process for installing the Asset Arena
Guide Investment Accounting Application. The
application consists of the Enterprise
Database, Main Enterprise App Server
Application, IIS application components, and
additional App Server modules.
Enterprise Distributed Architecture – This document details the Investment

Reporting and Data Extraction Guide Accounting (InvestOne) Enterprise
functionality found in the Reporting and Data
Extraction application for the Distributed
Architecture (DA) environment. It is a useful
resource for anyone who plans to use this
application to create and design a report.
The above documentation is only available in Portable Document Format (PDF), and
is accessible from either the CD that was supplied at the time of your installation or
from our web site. The web site for this documentation is located at
http://www.investonesupport.com/ (see the Electronic Doc link).

CONTACTING CUSTOMER SUPPORT
If you need assistance, call Enterprise Customer Support at (630) 920-0745 press 1,
or email AAIA.CSC.NA@sungard.com. Or call the London Customer Support at 011
44 207 337 6005. Please check our web site at http://www.investonesupport.com/
NOTATION CONVENTIONS
If you are reading this manual online, you can click on the highlighted portion of a
link to go directly to the related information. To see how a link works, click on the
phrase "table of contents." Once you are "linked into" the table of contents, find the
link in the table of contents section called Notation Conventions. Click Notation
Conventions to return here.
The following are types of NOTATION CONVENTIONS used in this guide:
Type Description
General Link Links to a section, text or object. Generally does not include
a section number, section heading or page number.
Cross Reference Link Links to a section, text or object. It generally includes a
section number, section heading and page number.
Indicates an important NOTE that should be read.
Symbol

1 OVERVIEW
The illustration below shows the relationship of the Enterprise DA components within
the context of the entire Asset Arena Investment Accounting architecture.

1.1 SYSTEM REQUIREMENTS
1.2 ENTERPRISE TECHNOLOGIES (PENDING)
1.3 JAAS
Enterprise uses a file named Mercury_JAAS.config, which is positioned in the
application server’s “current working directory” for authentication and authorization.
This file must contain the following on one line:
MercuryLogin {
com.sungard.sims.mercury.security.authentication.UserPasswordLoginModule
required debug = true
loginValidatorClass="com.sungard.sims.mercury.security.authentication.Authenticati
onValidatorImpl" roleFile="/resources/properties/usersroles.properties";
};
The application server’s JVM must be configured to start with the argument:
-Djava.security.auth.login.config=Mercury_JAAS.config
1.4 PASSWORDS (PENDING)
1.5 BRANDING (PENDING)
1.6 PRINTERS (PENDING)
1.7 MEMORY SETTINGS (PENDING)
1.8 SERVER STARTUP SETTINGS (PENDING)
1.9 ENTERPRISE COMPONENTS (PENDING)
1.9.1 Ear file (Pending)
1.9.2 Excel Executor (Pending)
1.9.3 FTP (Pending)
1.9.4 ActivePDF (Pending)
1.9.5 IBM MQ (Pending)
1.10 ENTERPRISE MODULES
1.10.1 Process Manager

This section briefly introduces the Process Manager and its components, with more
details for each component in the following sections. While many concepts described
in this introductory section are carried over from Release 11.0, the Enterprise

Release 12.0 has an enhanced Process Manger implementation that introduces some
new concepts. At the end of this section, the differences are highlighted.
Process Manager is a set of components responsible for the submission, execution,

and monitoring of Process requests for client accounts. Because of the possible wait
times from large Reporting Accounts or complex task lists associated with a
particular Process request, the submission process is asynchronous. This
asynchronous submission allows users to submit large requests and continue with
other activities. For scalability and performance, Process Request and Process
Execution are decoupled and handled by separate components.
Process execution, governed by Process Server(s), occurs in the background of user
activities and does not involve any direct user interaction. Process Server(s)
executed Processes in First-In-First-Out (FIFO) order.
Unit of work for Process Manager is a Process. A Process is a collection of one or

more Tasks, and each Task has one or more Parameters. A single Process Server
executes all Tasks of a Process in the sequence they exist in Process definition. Some
Processes are pre-defined, and users may define new Processes with desired Tasks.
A Task may be for a report, or any other service request such as a calculation. There
are many Tasks pre-defined for different types of services. Each Task must have one
or more Parameters such as account number, date range, etc. against which the
Task is executed. Users supply appropriate values for Parameters for all Tasks when
submitting a Process for execution. Essentially a Process is simply a container to
group related Tasks, while Tasks are the actual service units executed by a Process
Server.
A Process Server is the Process execution engine of Process Manager. A single

Enterprise application instance may be configured to have one or more Process
Server(s). Each Process Server is configured with a number of execution threads. A
Process Server can be a general-purpose or it can be a dedicated Process Server. A
general-purpose Process Server executes any Process without any preferences to
any specific Process. A general-purpose Process Server may also be referred to as a
Catch-All Process Server. A dedicated Process Server is one that is allocated to run
Processes that meet certain configurable criteria. For example, a Process Server PS1
may be dedicated to execute Processes that are submitted by certain user U1.
Process Server PS1 will not run any Process not submitted by user U1. Dedicated
Process Server configurations allows administrator to configure Process executions
capabilities depending on Enterprise deployment configuration. While the example
Process Server PS1 is allocated for only user U1, generally speaking, a dedicated
Process Server can be allocated to multiple criteria.
A dedicated Process Server has one or more allocation criteria. Allocation criteria
include InvestOne Accounting Region, InvestOne Accouting UserBank, Account,
Enterprise User Login, Customer, Primary Task Type, and Special Time Block. A
dedicated Process Server with multiple allocation criteria will run Processes that
match any or all allocation criteria depending on the Allocation Match type. For
example, a dedicated Process Server P1 with Allocation Match type of “Any” that has
allocation criterion C1 for User U1 and allocation criterion C2 for Account A1. Process
Server PS1 will execute Process P1 submitted by user U1 for any account, and it will
execute Process P2 submitted by user U2 against Account A1. Process P2 does not
meet User U1 criteria, but it does meet Account A1 criteria; therefore Process Server
PS1 does execute Process P2. If the same Process Server P1 is changed to Allocation
Match type of “All”, a process must match both criteria C1 and C2 in order to be

eligible to run on Process Server P1. Taking the same example above for Allocation
Match type of “All”, a process will run on P1 only if it is submitted by User U1 against
Acccount A1.
Irrespective of whether a Process is executed by a general-purpose Process Server or

a dedicated Process Server, A Process traverses through three stages within Process
Manager. The first stage is the Process Request stage. A Process enters the Process
Request stage via one of two routes. One route is the web interface page titled
Process Request where a User requests a Process execution. Once user submits a
request for Process execution, user immediately gains control of the user interface to
allow for performing other activity on user interface. The other route is a System
generated request for Process execution. A System generated process request occurs
for requesting a Scheduled Process execution or for requesting a Process execution
because of certain business-logic processing events firing. The second stage is the
Process Submission stage. Internally Process Manager submits the Process for
execution on user’s behalf in the Process Submission stage. Until the Process
Manager “submits” the Process for execution, it is not visible to Process Servers. The
third stage is the Process Execution stage. Each Enterprise application instance has a
number Process Servers continually checking for new Process submission. One of the
Process Servers will select the newly submitted Process and proceed with its
execution. When Process is running, it is considered to be in the Process Execution
stage. Thus a typical Process has three stages in its lifecycle: Process Request,
Process Submission, and Process Execution.
There are significant changes in Process Manager of Release 12.0. The Process
Manager updates include
• Process Server configuration user-interface

• More flexible dedicated Process Server based on Process Allocations
• Enhanced Process Server
Whereas Process Servers in earlier releases are configured with ARCH_PROPERTY

database table, Release 12.0 introduces a new web user interface for administrators
to manage Process Server definitions. Administrators can create, update and delete
Process Servers on the new web user interface. Furthermore Process Server updates
take effect immediately without Enterprise application restart. There is a very limited
concept of dedicated Process Server in earlier releases with use of database stored
procedures sp_pm_getNewJob_xxx and sp_pm_getNextJob_xxx where in_container
and ex_container substitutes xxx. The word container refers to the Process Task
type. Process Servers are configured to use a pair of sp_pm_getNewJobs_xxx and
sp_pm_getNextJobx_xxx database stored procedures. Administrators also configure
a list of containers that a Process Server uses when executing the database stored
procedures for selecting Processes for execution. The in_container database stored
procedure only executes Processes that contain at least one Task of type represented
by the container list. Conversely the ex_container database stored procedure does
not execute any Process that has at least one Task of type represented by the
container list. The Process Server configuration web user interface allows Process
Servers to be allocated to additional criteria for Process selection. The Process
Servers in Release 12.0 is modified to reduce database contention during Process
selection and to enforce a FIFO submission order for Process execution.

Now that concepts of Process Manager are introduced, the following sub-sections of
Process Manager delve into further details. Before proceeding, however, some
differences are noted here.
With Enterprise 10.0, Process Manager is fully implemented in Java. Prior to 10.0,
Process Manager was implemented mostly through Windows components (.ASP
pages, VB/COM+ objects, & MSMQ) and ran on IIS. This architecture and approach
was introduced with Apollo, and continued with Enterprise, up to version 10.0.
Processes can be submitted to the Process Manager either immediately via the
Process Request screen, or at a scheduled time, via the Scheduler. Regardless of
submission type, all submitted Processes are executed in the same manner, via
Process Server.
1.10.1.1 Process Server Definition

Process Servers definitions are managed using Enterprise application rather than
using configuration properties defined in ARCH_PROPERTY database table as was
done prior to Release 12.0. A new web user interface is available to create new
Process Servers, update properties of existing Process Servers, and delete existing
Process Servers.

Process Manager Configuration Page

New screen titled “Process Manager Configuration” (Jump To: PMConfig) allows
administrators to configure Process Servers and assign allocation criteria to these
Process Servers. It’s a two tabbed screen in which administrators can add, update or
delete Process Servers in the first tab and define and assign allocation criteria to
these Process Servers in the second tab.
This screen is available only to Sungard customer’s (customer0) Administrator Role

via the menu item “Application Administration/Process Manager/ Process Manager
Configuration” or Jump To “PMConfig”.

Process Manager Configuration UI- Definition Tab

The first tab in the “Process Manager Configuration” screen allows administrator to
add, update or delete Process Managers. It has following runtime attributes:
• Name
• Enabled
• Maximum Threads
• Host Name
• Excel Executor Host
• Excel Executor Port
• EMS Engine Host
• EMS Engine Port
Following table outlines each field in the above screen.
Definition Tab UI Field Type Required Validation / Default

Field
Name Text Yes • Name must not be identical to any
existing Process Server
• When comparing the name for conflict,
the comparison is to be case-insesitive.
In other words, Executor_1 is the same
as EXECUTOR_1.
• Maximum size: 40
Enabled Drop-down Yes • Default: No
• Possible Values: Yes, No
Maximum Threads Text Yes • Numeric value
• Range: 1 – 99
Host Name Text No • Alpha-numeric text
Excel Executor Text No • Alpha-numeric text
Host • Maximum size: 50
Excel Executor Port Text No • Numeric value
• Range: 1 - 9999
• Required if Excel Executor Host is not
empty
EMS Engine Host Text No • Alpha-numeric text

EMS Engine Port Text No • Numeric value
• Size: 1 - 9999
• Required if EMS Engine Host is not
empty
Specifying a Host Name restricts the Process Server to startup only on the specified
host. A Process Server may have a dedicated Excel Executor, which can be specified
in the Excel Executor Host and Port. As of 11.0 Enterprise, the EMS engine runs in
the same JVM as the Enterprise application, however, the use of remote EMS engine
is still available. In case of remote EMS engine, the user may specify the Host and
Port of the remote EMS Engine. The remote EMS engine is the legacy C++
implementation that runs on Windows CoEx servers.
There are three modes of operation in the PMConfig UI.

1. Add a Process Manager
2. Change a Process Manager
3. Delete a Process Manager
Add Process Manager

When user clicks the ADD button,
• Definition tab is activated and all fields are cleared.
• User is directed to the Name field in the Definition tab.
• User may add one or more allocation criteria. Criteria are shown in the table
at the bottom of the Allocation tab. If there is a change in this table, the
SUBMIT button is enabled.
• User can switch back and forth between the Definition tab and the Allocation
tab.
• User completes the desired fields on the Definition tab and Allocation tab.
When all require fields have valid values, the SUBMIT button is enabled.
• User clicks the SUBMIT button. The new Process Manager definition is
forwarded to the server. System displays “Process Manager definition added successfully”
at the status bar.
When a new process manager is added, the system produces at least one INFO log
message that shows addition of a new process manager. The INFO log message
below shows addition of a new process manager named “Test”. Empty Hostname
field shows that the process manager is not bound to any single Enterprise hosts, but
rather is intended to run on all Enterprise hosts. It has ten threads, but it is not yet
enabled.
INFO 2014-07-23 09:13:23 82-634 ProcessManagerConfigurationService: Added

process manager. ProcessExecutorDefinition Id [1048050], ExecutorName [Test],
Hostname [], ThreadCount [10], Enabled [N]
The above INFO log message is produced only on the Enterprise host that services
the PMCONFIG page request. If the new process manager had been added in enabled
mode, the Enabled property would be “Y”, and three additional INFO log messages
are produced signifying the start of the newly added process manager as shown
below.
INFO 2014-07-23 09:30:32 39-994 ProcessExecutorController: Process executor

[Test] added in the process executor controller.

INFO 2014-07-23 09:30:32 39-994 ProcessExecutor: Executor [Test], instance

count [2] started.

[ProcessExecutorDefinition Id [1048051], ExecutorName [Test], Hostname [ ],
ThreadCount [10], Enabled [Y]] started.
The process manager start action INFO log messages are produced on all Enterprise
hosts that start the process manager. Since the process manager “Test” is not bound
to a single host, all Enterprise hosts will produce the start action INFO log messages.
If the process manager had been bound to single host, the start action INFO log
messages are produced only on the bound Enterprise host.
Change Process Manager

When user selects a Process Manager in the “Process Managers” drop-down, the
LOAD DEFINTION button is activated. When user clicks the LOAD DEFINTION button,
• Definition tab is activated and all fields are populated with selected Process
Manager’s attributes.
• User is directed to the Name field in Definition tab.
• User updates one or more fields. When at least one filed is modified, the
SUBMIT button is enabled.
• User clicks the SUBMIT button. The modified Process Manager definition is
forwarded to the server. System displays “Process Manager definition updated
successfully” at the status bar.
When a process manager configuration is updated, the system produces at one INFO
log message to show the new configuration of the updated process manager. The
INFO log message below shows an example of a configuration update on a process
manager named “Test”. Note that the log message does not show old and new
configuration. It only shows the new configuration. The INFO log in the example
below was result of thread count change from 5 to 10. Note that the message only
shows the new configuration with thread count of 10 as well as all other unchanged
configuration parameters.
INFO 2014-07-23 09:36:05 81-911 ProcessManagerConfigurationService: Updated

process manager. Updated process manager. ProcessExecutorDefinition Id
[1048052], ExecutorName [Test], Hostname [], ThreadCount [10], Enabled [N]
Similar INFO log message is produced for all other parameter change. In case of the
Enabled parameter change, three additional INFO log messages are produced to
indicate the starting or stopping of the process manager. These three INFO log
messages are identical to the messages produced when new process manager is
added in enabled state or deleted while it had been enabled.
Delete Process Manager

The Process Manager deletion scenario behaves identical to the Process Manager
change scenario until the user clicks the DELETE button. When user selects a Process
Manager in the Process Managers drop-down, the LOAD DEFINTION button is
activated. When user clicks the LOAD DEFINTION button,
• Definition tab is activated and all fields are populated with select Process
Manager attributes.

• User is directed to the Name field in Definition tab.

• User clicks the DELETE button.
• User is prompted for confirmation of delete action.
• User confirms the delete action. The Process Manager definition is deleted in
the server including all its associated allocation criteria. System displays
“Process Manager definition deleted successfully” at the status bar.
• At this point, the PMConfig UI remains on the Definition tab with
o All fields populated with the selected Process Manager.
o All fields disabled.
o CANCEL button enabled
When a process manager is deleted, the system produces at least one INFO log
message to show addition of a new process manager. The INFO log message below
shows deletion of a process manager named “Test”.
INFO 2014-07-23 09:13:23 82-634 ProcessManagerConfigurationService: Deleted

process manager. ProcessExecutorDefinition Id [1048050], ExecutorName [Test],
Hostname [], ThreadCount [10], Enabled [N]
The above INFO log message shows delete action of a disabled process manager,
and it is produced only on the Enterprise host that services the PMCONFIG page
request. If the process manager had been enabled at the time of deletion, three
additional INFO message are produced. These three messages are produced on all
Enterprise hosts where the process manager had been running.
INFO 2014-07-23 09:33:25 39-994 ProcessExecutor: Executor [Test], instance count
[2] finished shutdown
INFO 2014-07-23 09:33:25 39-994 ProcessExecutor: Stop executor command

received for Executor [Test], instance count [2]

[Test] shutdown command issued.
The process manager stop action INFO log messages are produced on all Enterprise
hosts that start the process manager. Since the process manager “Test” is not bound
to a single host, all Enterprise hosts will produce the stop action INFO log messages.
If the process manager had been bound to single host, the stop action INFO log
messages are produced only on the bound Enterprise host.
During any of the above three use cases, the user may click the CANCEL button to
reset the PMConfig UI page or click the RESET button to revert the changes on the
current tab to the originally populated values. The SUBMIT and RESET buttons are
activated when a change is made on the current tab. The SUBMIT button has one
additional constraint on its activation in that it is only activated when updated
field(s) contain valid values.

Process Manager Configuration UI- Allocation Tab

The Allocation tab is available to manage allocation criteria of a Process Server. A
Process Server without any allocation criteria is a “General-Purpose” Process
Manager. A Process Server with one or more allocation criteria is a “Dedicated”
Process Server.
The top panel of the allocation tab contains fields for entering a new allocation
criterion. The allocation criteria of a Process Server are listed in the table at the
bottom of the tab. The tab contains three buttons to add allocation criterion to the
grid, delete selected allocation criterion in the grid and clear fields of allocation
criterion. There is no explicit mechanism to change an existing criterion. To change
an existing criterion, the user must delete the target criterion and replace it with a
newly added criterion. The fields for adding new criterion are dynamically adjusted
based on the Allocation Type selected by the user.
Process Manager Configuration UI Allocation tab (3 different allocation criteria are

associated with the Process Manager D1)
Any addition or deletion of the allocation criteria while in Allocation tab are preserved
in the browser until the SUBMIT button is clicked to persist the updates in the server.

Process Manager Configuration UI Allocation Tab (Entering 3 different new criterion

for the Process Manager D1)
Following table describes all the fields of the Allocation tab in the context of adding a
new allocation criterion.
Definition Tab Field UI Field Required Validation / Default
Type
Allocation Match Drop-Down Yes • Default value: Any
• Possible values
o Any
o All
Allocation Option Drop-Down Yes • Default value: Unselected,
Enabled
• Possible values
o Customer
o Container
o Region
o Userbank
o Account
o User
o Special
Condition Drop-down No • Default value: Unselected
• Default mode: Disabled
• Enabled only when Allocation
Type selection is
o Customer
o Container
o Region
o Userbank
o Account
o User
• Possible values
o Equals
o Not Equals
Customer Drop-down No • Default value: Unselected
• Default mode: Hidden
• Unhidden only when Alloction


Type
Option selection is
o Customer
o Container
o Region
o Userbank
o Account
o User
• Possible values: Names of all
active customers in current
Enterprise deployment.
Region Drop-down No • Default value: Unselected
Type selection is
o Region
active regions for
o customer selected in
Customer drop-down.
Userbank Drop-down No • Default value: Unselected
Type selection is
o Userbank
active userbanks for
o customer selected in
Customer drop-down
o region selected in
Region drop-down
Account Text No • Alpha-numeric value
• Default value: empty string
• Unhidden when Allocation Type
selection is
o Account
Account Picklist Picklist No • Default mode: Hidden
• Unhidden when Account text-
box is unhidden
• Similar to the account picklist
used in other UI screens
• Contains accounts of customer,
region and userbank selection
in their respective drop-down.
User Text No • Alpha-numeric value
• Default value: empty string
• Unhidden when Allocation Type
selection is
o User
User Picklist Picklist No • Default mode: Hidden
• Unhidden when User text-box is
unhidden
• Contains details of non-deleted
users of customer selection in
Customer drop-down.
o Includes inactive users
o Includes locked-out
users
Container Drop-down No • Default value: Unselected


Type
Type selection is
o Container
process task containers
From Text No • Default value: Empty string
• Default mode: Enabled
• Cleared and disabled when “All
Day” check-box checked.
• Required if “All Day” is
unchecked.
• Specifies start time of allocation
criterion in terms of time of day
(i.e. 3:00 PM, 10:00 PM, 8:00
AM, etc)
• Value format is in HH:MM
AM|PM
o HH must be in 12 hour
format
o AM, PM is case-
insesitive
o Example: 08:00 AM,
8:00 AM, 3:00 PM
To Text No • Default value: Empty String
• Cleared and enabled when “All
Day” check-box checked.
• Required if “All Day” is
unchecked.
• Specifies end time of allocation
criterion in terms of time of day
(i.e. 3:00 PM, 10:00 PM, 8:00
AM, etc)
• Value format is in HH:MM
AM|PM
o HH must be in 12 hour
format
o AM, PM is case-
insesitive
• Example: 08:00 AM, 8:00 AM,
3:00 PM
All Day Check-Box No • Default value: Checked
• When checked, “From” and
“To” time should be cleared and
disabled.
• Implies that the criterion is to
be applicable at all times

Assigning Allocations to Process Servers

In a multi node Enterprise Application deployment, each Enterprise Application
instance may have one or more Process Servers. A Process Server may be one of
two types: General-Purpose or Dedicated. A General-Purpose Process Server can run
any process. A Dedicated Process Server can run only those processes that match its
allocation criteria based on parameters like Region, Userbank, Account, Enterprise
User, Customer or Primary Container.
By default, a newly created Process Server is a General-Purpose Process Server. To

dedicate a General-Purpose Process Server to execute only a subset of processes,
one assigns process allocation criteria to that Process Server. Process allocation
criteria specify which processes a Process Server will run. Conversely, one removes
all process allocation criteria association from a Dedicated Process Server to make it
a General-Purpose Process Server. Processes that do not match at least one of the
process allocation criteria associated with a Process Server will not be allowed to run
on that Process Server even if it is available. A Process Server can act as a full-time
Dedicated Process Server or a part-time Dedicated Process Server based on “To” and
“From” field in the Allocation Criteria tab. A Dedicated Process Server behaves as a
General-Purpose Process Server outside of the time frame defined by “To” and
“From” fields.
Concepts of General-Purpose and Dedicated Process Servers as well as hostname

affinity are further explained with examples in the section describing Process
Submission phase

Examples of Process Allocation

Example below explains how different executors are started in different hosts
(enterprise application instance) based on the host parameter and how the
submitted processes are picked up based on those criteria. The example also shows
how a dedicated process server becomes a catch-all executor based on the allocation
time frame.
Let’s say our executor configuration definition is defined as in the following table:
Proces Hostna Allocation Comments

s me
Execut
or
E5 Unspecifi None • Unspecified hostname allows E5 to be started on all
ed Enterprise applications (A1, A2, A3)
• No defined allocation criteria makes this a catch-all
process executor
E6 H1 C1 • Specific Hostname (H1) results in E6 being started only
Region = on A1
R3 • Dedicated to only execute processes belonging to
region R3
• Dedicated to R3 processes only during 08:00 AM and
9:00 AM on a daily basis.
• Becomes a catch-all process outside the specific
dedicated time window. So it is catch-all from 12:00
midnight to 8:00 AM and from 9:00 AM to 12:00
midnight on daily basis.
Region = on A2
region R1
• Dedicated to R1 process all-day, everyday.
Region = on A2
region R2
• Dedicated to R2 processes only during 1:00 PM and
6:00 PM on a daily basis.
• Becomes a catch-all process outside the specific
dedicated time window. So it is catch-all from 12:00
midnight to 1:00 PM and from 6:00 PM to 12:00
midnight on daily basis.
Table: Example executor configurations
Suppose we have three enterprise application instance A1, A2, A3 running on the
host H1, H2, H3. Based on the above executor definition, our process manager
configurations will look like the following:
Enterprise Application: Enterprise Application: Enterprise Application:

A1 A2 A3
Hostname: H1 Hostname: H2 Hostname: H3
Process Executor: Process Executor: E5 Process Executor: E5

E5 Catch-All Catch-All
Catch-All
Process Executor: Executor: E7 Executor: E8

E6 Dedicated: Region = Dedicated: Region =
Dedicated: Region R1 R2
R3 Ti 8 00 Ti 13 00

Figure 1: Example configuration for PROCESS_EXECUTOR_ALLOC illustration
Now, consider a new process P1 is submitted by a user who is logged in with

connection to Region R2. Process P1 will be evaluated against allocation criteria of all
dedicated process executors as defined in the PROCESS_EXECUTOR_CRIT table by
the Process Allocator. Note that the evaluation is done for ALL dedicated process
executors that may be running across multiple Enterprise application instances.
Process P1 submission may be received and evaluated by Enterprise application
instance A1, but it will record process allocation matches for all enabled process
executors E5 through E8.
The Process Allocator will record multiple rows in the PROCESS_EXECUTOR_ALLOC

table for process P1 covering all matched dedicated process executors and one
additional row to cover all catch-all process executors.
SID PROCES PROC CRIT START_TIME_HOUR_ END_TIME_HOUR

S EXEC MIN _MIN
1 P1 E8 C3 1300 1800
2 P1 E8 NULL 0 1300
3 P1 E8 NULL 1800 2400
4 P1 E6 NULL 0 800
5 P1 E6 NULL 900 2400
6 P1 NULL NULL 0 2400
Table: Process allocations for process P1
The Process Allocator specifically for E8 inserts three rows in the

PROCESS_EXECUTOR_ALLOC. Process executor E8 is a part-time dedicated process
executor with one allocation criterion C3 for region R2 limited to a time window from
1:00 PM TO 6:00 PM (13:00 to 18:00). Outside of this time window, E8 can run any
process, so it has two catch-all time windows. One E8 catch-all time window is from
midnight to 1:00 PM (00:00 to 13:00) and the other E8 catch-all time window is
from 6:00 PM to midnight (18:00 to 00:00). Row #1 indicates that E8 can run P1
between 13:00 to 18:00 as a direct match with its allocation criterion C3. Row #2
indicates the E8 can run P1 between 00:00 and 13:00 because it is a catch-all
process executor in this time window which is signified by the NULL value for the
PROCESS_EXECUTOR_CRIT_SID. Similarly row #3 indicates that E8 can run P1
between 18:00 and 24:00, which is also its catch-all time window.
Two rows are inserted in PROCESS_EXECUTOR_ALLOC for E6. Process executor E6 is

a part-time dedicated process executor with one allocation criterion C1 for region R3
limited to a time window from 8:00 AM to 9:00 AM (8:00 to 9:00). Outside of this
time window, E6 can run any process, so it has two catch-all time windows. One
catch-all time window is from midnight to 8:00 AM (00:00 to 8:00) and the other
catch-all time window is from 9:00 AM to midnight (9:00 to 00:00). Because process
P2 for region R2 does not match allocation criterion C1, E6 only has two matching
allocation entries. Row #4 indicates that E6 can run P1 in its catch-all time window
between midnight and 8:00 AM. Row #5 indicates that E6 can also run P1 in its
catch-all time window between 9:00 AM and midnight. P1 cannot run on E6 between
8:00 AM and 9:00 AM, because it is reserved for processes for region R3.
Lastly row #6 is for all true full-time catch-all process executors that have no
allocation criteria, which happens to be E5 in this example. Note that there is no
specific process executor defined for PROCESS_EXECUTOR_DEFNTN_SID. If there

were 10 additional full-time catch-all process executors E11 through E20 are
present, row #6 would represent all of these full time process executors (E5, E11
through E20). This differs from the catch-all time window allocation rows for E6 and
E8. The part-time dedicated process executors like E6 and E8 are catch-all at
different time periods of the day. Therefore it is necessary to specifically add rows for
individual catch-all time windows of specific part-time dedicated process executors.
So why bother with recording the time window boundaries for each allocation entry?
Recall that the process allocations are recorded in the PROCESS_EXECUTOR_ALLOC
table at the time of process submission. Processes are retrieved during process
execution to dispatch the process to one of the available and eligible process
executor. The process submission and execution occur in two different threads,
possibly even on two different Enterprise applications JVM. The delay between
process submission and execution can vary depending on various factors such as the
rate of new process submission and the number of running process executors. There
is a significant probability that a process submitted at time t1 may be eligible to be
run by a process executor at time t1, however by the time that same process
executor actually attempts to run the process at time t2 it is no longer eligible.
Consider for example, that process P1 had been submitted at 7:59:59. Furthermore
assume that there is capacity only on process executor E6 and all other process
executors are busy. Now imagine that by the time P1 is retrieved from
PROCESS_EXECUTOR_ALLOC for execution the time is 8:00:01. At this point, P1
should not be dispatched to E6 for execution because E6 is now in its specific
allocation time window for allocation criterion C1 where it is reserved for processes
on region R3. If the time windows are not specified in the allocation entry, then E6
would run P1 thus violating its allocation criteria. Under heavy load condition the
delay between process submission and its eventual execution may be significantly
higher. To prevent such scenario, it is necessary to record the time window in the
PROCESS_EXECUTOR_ALLOC table rows.

1.10.1.2 Process Submission
Process Request
There are two means by which a Process life originates: System Request and User
Request.

A system requested Process is either a Scheduled Process or Triggered Process. A

Scheduled Process is either a one-time Scheduled Process or a recurring Scheduled
Process. A Triggered Process origination results from certain business logic condition
becoming present such as a MQ message from InvestOne Accounting Core. The
Automated Dilution Calculation Process is an example of Triggered Process, and it is
instantiated when Enterprise receives Dilution Calculation MQ message from
InvestOne Accounting Core.
A user requested Process originates from the user actions on the Process Request
page. Process Request page is reached by menu action or by Jump-To shortcut
action. The browser sends a request to
/Apollo/processmanager/invokeIoReqSubmit.do to Enterprise server when Process
Request page is requested. In response, Enterprise server generates and sends
HTML that has a Process selection drop-down element and a number of input
elements for Process Task Parameters. Recall that a Process definition has one or
more Tasks, and each Task has one or more Parameters such as account number,
date range, etc. against which the Task is executed. The set of input elements for
Process Task Parameters is determined by the Process definition selected in the
Process selection drop-down element. The Process definition names in Process
selection drop-down element are sorted in alpha-numeric order. On a first visit to
Process Request after user login, the first Process in the drop-down element is
selected by default. On subsequent visit to the Process Request page by the same
user, the Process selection in the drop-down element defaults to the Process
selection on last visit of Process Request page. The Process Request page is dynamic
in that it is automatically refreshed depending on user’s action on Process Request
page. If user changes the Process selection, browser sends another request to
/Apollo/processmanager/invokeIoReqSubmit.do with query parameter indicating the
selected Process. Enterprise server responds with a new HTML reflecting the
necessary Process Task Parameters of the Process selection. The Process Request
page is refreshed with necessary set of input elements for Parameters of selected
Process each time the user changes the Process selection. Another dynamic behavior
of Process Request page is Parameter validation. Certain Parameters validation is
performed server-side on Enterprise server while others are validated client-side on

the browser with JavaScript code embedded in the Process Request page.
Parameters such as account number result in a round-trip to Enterprise server for
server-side validation.
User’s SUBMIT button action on Process Request page triggers the browser to invoke
the /Apollo/processmanager/invokeIoReqSubmitPost.do with the user-entered
Process data. On Enterprise server, IoReqSubmitPostService collects Process data
from Process Request page, and it adds additional environment Parameters such as
Customer, Region, UserBank, etc. from user’s login session. The
IoReqSubmitPostService sends Process data to the SubmissionManager component.
The SubmissionManager is the boundary between Process Request stage and Process
Submission stage. The SubmissionManager component consists of Process data
queue, and collection of queue consumer worker threads. The queue in
SubmissionManager decouples Process Request stage and Process Submission stage,
with Process Request stage operating in context of HTTP request thread being the
queue producer and Process Submission stage operating in context of
SubmissionManager worker threads being the queue consumer. This decoupling is
necessary so that user can regain control of user interface as quickly as possible to
pursue other Process execution requests or visit a different user interface page
altogether. The SubmissionManager component is described in detail in the Process
Submission section.

Process Request page is used not only to make a request for immediate Process
execution, but also to request a Scheduled Process execution. User may setup a
schedule for Process execution rather than having it proceed to Process Submission
stage immediately after completing Process Request page. Note, however, that
Process entered on Process Request as a one-time Scheduled Process or recurring
Scheduled Process is not instantiated. Instead a Scheduled Process is originated by a
Scheduler component, which runs in the background and monitors timer for each
Scheduled Process. Upon a Scheduled Process timer expiry, Process is instantiated
and submitted for execution.
Whether a Process originates from a User Request or a System Request, each

Process traverses the Process Submission stage followed by Process Execution.
Process Submission
While IoReqSubmitService and IoReqSubmitPostService are primary components of

Process Request stage, SubmissionManager is the primary component of Process
Submission stage. SubmissionManager utilizes the ReqSubmitProcess and
ProcessAllocator to fulfill the Process Submission stage responsibilities.
The SubmissionManager is responsible for:
1. Queuing Process requests on behalf of IoReqSubmitPostService.

2. Reading queued Process requests. This is performed by a finite number of queue
consumer worker threads. Each worker thread operates on single Process request,
and performs the following operations.
a. Store Process data in database.
b. Map Process execution to Process Servers.
The SubmissionManager queue consists of two elements, a queue and a collection of

worker threads. The SubmissionManager queue implementation is a combination of
in-memory queue and file-system. The Process data are written to a temporary file
(one file per Process) on the local file-system, and the file names are placed in an in-
memory queue for consumption by worker threads. The use of file-system for
Process data achieves two objectives.
• Reduced memory footprint – Process parameter lists can be quite large and
occupy a significant amount of memory. By storing process parameters
externally in a file and only maintaining the file name in memory, the memory
footprint is reduced.
• Recovery – In the event of unplanned server shutdown, the in-memory queue can
be recreated by the contents of the queue files (since each file is created
sequentially).
Process data files are exist in the {INSTALL_DIRECTORY}/workingstore/pmqueue

directory, where {INSTALL_DIRECTORY} is the base directory for an Enterprise
deployment on Linux server. The {INSTALL_DIRECTORY} is also the same directory
in which the file Apollo.startup.properties file resides. The Process data is recorded in

the file as binary data that is a set of key-value pairs written using Java serialization.
The files are temporary until Process data is recorded in the database. It is not
uncommon to find the pmqueue directory empty during normal operation of an
Enterprise server, because lifetime of the temporary files is so short that it is
unnoticeable. The files are named such that the arrival order of Processes can be
ascertained, thus allowing for a recreating the in-memory file-name queue upon
server restart.
As mentioned in Process Request section, SubmissionManager queue decouples the

Process Request stage from Process Submission stage. Process Request stage
operates in context of HTTP service thread responding to user’s action on the
browser, while Process Submission stage operates in context of SubmissionManager
worker threads. Once Process request is queued, control is returned to user, along
with a message indicating that the process has been successfully submitted. The
benefit of this asynchronous submission implementation is more apparent when
handling requests for reporting accounts, which may contain hundreds of
subaccounts, each of which require its own process request submission. As an
example, if a user submits a Process request for a reporting account, that request is
entered into the SubmissionManager as a single item. The worker thread that
handles that request first determines that the account in question is a reporting
account, calls the InvestOne Accounting Core to retrieve a list of all the subaccounts,
and then submits individual process requests for each of subaccount. So a Process
request for a reporting account containing 500 subaccounts would ultimately
generate 500 individual Processes data items in the queue. Were this Process
request not asynchronous, users could be waiting for several minutes for Process
Request stage to complete.
A SubmissionManager worker thread performs following operations to carry a

Process through the Process Submission stage. Each operation is subsequently
described in detail.
1. Store the Process data in database

2. Run Process allocation algorithm to map the Process to all Process Servers
running on local Enterprise server instance.
3. Store Process allocation records in database
Just as the SubmissionManager, specifically the SubmissionManager queue, is a

boundary between Process Request stage, the database tables where Process and its
allocations are stored serve as the boundary between Process Submission stage and
Process Execution stage. Similarly the there is also a code execution thread context
change between Process Submission stage and Process Execution stage. Process
Submission stage operates in context of SubmissionManager worker threads, and
Process Execution stage operates in context of Process Server worker threads. It is
the Process Server worker threads that actually execute the Processes. Several
database tables that store Process data and its allocation data serve as the queue
between Process Submission and Process Execution.
Process data read from SubmissionManager queue file are analyzed, validated and
ultimately stored in database. There are two sets of database table related to
Processes. First set of tables contains the definition of a Process.
• clnt_process_tbl – Process template definitions

• clnt_process_task_tbl – Defines Process-to-Task template relationships

• clnt_task_tbl – Task template definitions
• clnt_task_parm_tbl – Defines Parameter-to-Task template relationships
Consider clnt_*_tbl tables as storage for Process template definitions, which are
instantiated for each time a Process execution is requested. The IoReqSubmitService
servicing the Process Request page uses the clnt_*_tbl tables to appropriately
refresh the Process Request web page as described earlier. Instantiation of a Process
template definition with the specific parameters is the Process execution definition.
Process execution definitions are stored in following tables.
• SYS_PROCESS – Process execution definitions

• SYS_PROCESS_TASK – Task execution definitions
• SYS_PROCESS_PARMS – Parameter values
The SYS_PROCESS table stores the execution characteristics that apply to the entire
Process. These characteristics include items account number, user id of user
submitting the Process request, Process status, etc. One Process execution definition
occupies one row of SYS_PROCESS. The SYS_PROCESS_TASK table stores the
execution characteristics such as the result of specific Process Task execution and its
execution start and completion time. Each Process Task is stored in a single row of
SYS_PROCESS_TASK, and they are associated to the Process row in SYS_PROCESS
table. The SYS_PROCESS_PARMS table stores Task Parameters. There may be
multiple rows in SYS_PROCESS_PARMS per Task, and each row they are associated
to the related Task row in SYS_PROCESS_TASK table. Any Task execution definition
has multiple Parameter values. Unlike SYS_PROCESS and SYS_PROCESS_TASK
tables with a single item to single database table row pattern, the
SYS_PROCESS_PARMS stores multiple Parameter values in a single row. Multiple
Parameter key-value pairs are concatenated and stored in single row of
SYS_PROCESS_PARMS table. There is a limit on the number of Parameter key-value
pairs that can be concatenated and stored in a single SYS_PROCESS_PARMS row.
When a set of Parameter key-value pairs exceeds the limit, each
SYS_PROCESS_TASK may have multiple associated rows in SYS_PROCESS_PARMS
table, however, in most case this is expected to be in a single row, or at least, the
count of rows in a single digit.
Process Manager in Release 12.0 adds the ability to define dedicated Process Servers
reserved to execute Processes matching certain criteria. The allocation criteria are
• InvestOne Accounting Core Region

• InvestOne Accounting Core UserBank
• Account
• Enterprise User
• Customer
• Primary Container
• Special (Allow or do not allow Process execution)
Refer to the Process Server Definition section for details on the Process allocation
criteria. There are two inputs to the ProcessAllocator mechanism. One is the Process

data, and the other is the set of dedicated Process Server definitions.
ProcessAllocator evaluates the Process data against allocation criteria of each Process
Server. The output of the evaluation is a set of allocation records that show Process
Server eligible to execute the Process and time interval within which the eligibility is
valid. The Process allocation records are stored in PROCESS_EXECUTOR_ALLOC
database table. This allocation table serves as the hand-off between Process
Submission stage and Process Execution stage. Process Execution controller
periodically queries the Process allocation table for Processes that it can dispatch to a
Process Server for execution. The next section delves into more details on the
Process Server Controller and Process execution. For now, several examples are
shown here to illustrate the Process allocation mechanism and the structure of
Process allocation records.
Consider, for example, following 3-node clustered Enterprise environment with three
Enterprise application nodes N1, N2, and N3 on Linux hosts H1, H2, and H3,
respectively.
The environment is configured with Process Servers PS1 through PS4. There is one
general-purpose Process Server PS1 without any hostname affiliation, which is
started on all Enterprise application nodes. There are three dedicated Process
Servers (PS2, PS3, PS4) with specific hostname affiliation. Process Server PS2 is
dedicated to execute only Processes submitted against InvestOne Accounting Core
Region R1, and it is dedicated to this rule only daily for a one-hour time interval
between hours 8:00 AM and 9:00 AM. Process Server PS3 is dedicated to execute
only Processes submitted against InvestOne Accounting Core Region R2, but it is
dedicated to this rule for full 24-hour daily. Process Server PS3 is dedicated to
execute Processes submitted against InvestOne Accounting Core Region R2 between
8:00 AM and 3:00 PM and Processes submitted against Region R3 between 3:00 PM
and 6:00 PM. Since PS2 is affiliated with Linux host H1, it is only started by
Enterprise application node N1. Following the same hostname affiliation rule, PS3
and PS4 are started only on Enterprise application nodes N2 and N3, respectively.
Process Hostname Allocation Comments

Server
PS1 Unspecified None • Unspecified hostname results in PS1 started
on all nodes (N1, N2, N3)
• No allocation criteria makes this a general-
purpose Process Server
PS2 H1 C1 • Specific hostname (H1) results in PS2 started
Region = R1 only on node N1
• Dedicated part-time to Region R3 during

Process Hostname Allocation Comments

Server
8:00 AM to 9:00 AM
• General-purpose during 12:00 AM midnight
to 8:00 AM and during 9:00 AM to 12:00
AM midnight the next day
Region = R2 only on node N2
• Dedicated full-time (all-day) to Region R2
Region = R2; only on node N3
C4
• Dedicated part-time to Region R2 during
Region = R3
8:00 AM to 3:00 PM
• Dedicated part-time to Region R during 3:00
PM to 6:00 PM
• General-purpose during 12:00 AM midnight
to 8:00 AM and during 6:00 PM to 12:00
AM midnight the next day
Suppose that a user logged in to Enterprise for Region R2 submits a new Process P1.
Process Allocator evaluates Process P1 against all allocation criteria of all dedicated
Process Servers, and inserts allocation records into PROCESS_EXECUTOR_ALLOC
table. Note that the allocation evaluation is performed for ALL dedicated Process
Servers of all Enterprise application nodes, because Process Manager is an entity that
spans across all nodes of a clustered Enterprise environment. Request for Process P1
may be received and evaluated by Enterprise application node N1, but it may be
eligibly, and may eventually, execute by a Process Server on Enterprise application
node N2 or N3. Assume that user’s request for Process P1 was indeed received by
Process Request stage on Enterprise application node N1. Recall that the separation
between Process Request and Process Submission stage is the Submission Manager
with its queue backed-by local file-system. The use of local file-system dictates that
the same node that receives the request in Process Request stage must also walk the
incoming Process through Process Submission stage. As such, Process Allocator on
Enterprise application node N1 evaluates Process P1 against all dedicated Process
Servers, and generates the following Process allocation records.
Allocation Process Id Process Allocation Eligibility Eligibility

# Server Id Criterion Id Start Time End Time
1 P1 PS4 C3 800 1500
2 P1 PS4 Null 0 800
3 P1 PS4 Null 1800 2400
4 P1 PS3 C2 0 2400
5 P1 Null Null 0 2400
Process allocation record contains
• Process id from SYS_PROCESS table.

• Process server id from PROCESS_EXECUTOR_DEFNTN table
• Allocation criterion id from PROCESS_EXECUTOR_CRIT table

• Execution eligibility interval start time.

• Execution eligibility interval end time
The allocation records in above table are using symbolic values for Process id,
Process Server id and allocation criterion id. In real allocation records, however,
these values are 10-digit numeric database identifier values from the appropriate
database table as described above. The eligibility start-time and end-time values
account for the delay a Process may experience in the database between Process
Submission and Process Execution stages. It is possible the Process Execution rate
may be lower than Process Submission rate at time due to multiple factors such as
earlier having received a burst of time-consuming Processes with many tasks or
having received Processes reporting accounts with large number of sub-accounts. In
such conditions where Process Submission rate significantly exceeds Process
Execution rate, a Process may remain in database for some non-trivial time interval.
Consider, for example, a Process P0 is submitted for Region R2 at 2:59:01 PM is
deemed to be match against a Process Server PS4 for an allocation criterion C3 that
spans the time interval 8:00 AM to 9:00 AM. Suppose now that the Process
experiences a 3-minute delay in the database and the time when this Process is
ready to be dispatched for execution is 3:02:01 PM. Since PS4 is only eligible to run
the P0 between 8:00 AM and 3:00 PM, it cannot execute the P0 at 3:02:01 PM.
Process Execution stage uses the eligibility start-time and end-time to determine the
validity of the match performed during Process Submission. The eligibility start-time
and end-time values are four-digit numeric values that represent hour and minute of
the data in the HHMM format. For example, 815 represents 8:15 AM, 1030 represent
10:30 AM, 1200 represents 12:00 noon, 1314 represents 1:14 PM, etc. There is one
exception to this rule, however, in representation of 12:00 AM midnight hour. An
allocation record indicating an All-Day eligibility period has start-time and end-time
of 12:00 AM to 12:00 AM the next day, which are represented as 0 to 2400,
respectively. The Process Allocator algorithm, whose discussion is outside the scope
of this document, dictates this midnight hour number approach. The start-time value
is inclusive, and the end-time value is exclusive. For an allocation window of 8:00 AM
to 3:00 PM, eligibility starts at 8:00:00 AM and ends at 2:59:59 PM.
Process Allocator creates zero or more allocation records for each dedicated Process
Server, and record count depends on the whether the dedicated Process Server is a
full-time or part-time Process Server. Process Allocator always runs the matching
algorithm from midnight hour to midnight hour of the next day. Referring to the
above example, Process Server PS2 has no matching allocation criterion for Process
P1; therefore there are zero allocation records matching P1 to PS2. Process Server
PS3 is a full-time Process Server, and it has allocation criterion C2 that matches
against Process P1 All-Day; therefore there is one allocation record for matching P1
to PS3 with start-time of 0 and end-time of 2400. The start-time of 0 and end-time
of 2400 indicates that PS3 can execute P1 at anytime of the day. Process Server PS4
results in a much more complex set of allocation records. There are four allocation
windows in a daily 24-hour period for PS4.
• No allocation between 12:00 midnight to 8:00 AM

• Allocation criterion C3 between 8:00 AM and 3:00 PM
• Allocation criterion C4 between 3:00 PM and 6:00 PM
• No allocation between 6:00 PM to 12:00 midnight the next day

There is one record per matching time window for PS4. There are two allocation
records for PS4 during its general-purpose time windows. A general-purpose time
window of dedicated Process Server is one where the allocation criterion id value is
null. There is a general-purpose time window between 0 and 800 (12:00 midnight to
8:00 AM), and another general-purpose time window between 1800 and 2400 (6:00
PM and 12:00 midnight the next day). Process P1 does match criterion C3, so there
is an allocation record specific for C3 with between 800 and 1500 (8:00 AM to 3:00
PM). Process P1 does not match criterion C4, so there is no allocation record for P4
between 3:00 PM and 6:00 PM. ProcessAllocator generates total of four allocation
records for P1 when matched against dedicated Process Servers P2 through P4, zero
for PS2, one for PS3 and three for PS4.
ProcessAllocator behavior described thus far as been related to that dealing with
dedicated Process Servers. As a general-purpose Process Server PS1 is eligible to
execute P1, so an allocation record for PS1 match is necessary. Every Process has at
least one allocation record for general-purpose Process Servers. Although a general-
purpose Process Server can execute any Process, an allocation record is necessary
because allocation records also serve as a signal between Process Submission and
Process Execution stage. Process Execution stage relies exclusively on allocation
records to dispatch Processes for execution. It is not necessary to identify match
with all instances of general-purpose Process Servers, however. So there is a single
allocation record with null value for Process Server id and null value for allocation
criterion id, which is essentially a signal from Process Submission to Process
Execution that the newly arrived Process is ready for execution. The allocation
records for dedicated Process Server adds a level of specialization.
This section discussed the Process data tables and Process allocation mechanism.
Process allocation records in the PROCESS_EXECUTOR_ALLOC table serve as signals
between Process Submission stage and Process Execution stage while rows in
SYS_PROCESS_* set of tables serve as Process data store. At the center of Process
Execution stage is the Process Server Controller that dispatches Processes to Process
Servers for execution.
1.10.1.3 Process Execution
Process Execution stage is the final stage of Process lifecycle. It consists of two main
components: Process Server Controller (PSC) and Process Server(s). There is one
PSC per Enterprise application node, and it is started during application startup and
remains running on that application node until the application node is shutdown. The
PSC runs in context of a single thread, and dispatches newly submitted Processes to
Process Servers for execution. The PSC has three stages in its lifecycle: startup,
runtime, and shutdown.

During startup, the PSC performs two actions.
• Start Process Servers

• Reset Processes that were left in running state when application node was last
shutdown ungracefully, if any.
On any given Enterprise application node, the PSC starts Process Server(s) eligible to
run on that node. An eligible Process Server is one that either has no hostname
affiliation or it has hostname affiliation matching the Linux hostname of current
node. Referring to the multi-node clustered Enterprise deployment example
discussed in Process Submission section, Process Server PS1 is eligible to run on all
three Enterprise application nodes, while PS2, PS3 and PS4 are started only on nodes
N1, N2, and N3, respectively. The next step in the PSC startup stage is to reset
Processes that were abandoned in mid-execution by the same node during its
previous incarnation when, most likely, the node was abruptly and ungracefully
shutdown. The Process execution definitions in the SYS_PROCESS_* tables are reset
to the last completed Process Task. The name SYS_PROCESS_* refers to the set of
tables consisting of SYS_PROCESS, SYS_PROCESS_TASK and SYS_PROCESS_PARMS
tables. In other words all completed Process Tasks are left in completed states as
they are, and any mid-execution Process Task is reset such that it will start again
from beginning. Recall that the Process allocation records in the
PROCESS_EXECUTOR_ALLOC table are the signals that trigger Process Execution
stage to dispatch the process. Therefore, all abandoned Processes that are reset
must be run through the Process Allocator to create appropriate Process allocation
records. In addition to restoring the signaling mechanism, the allocation reevaluation
also ensures that the Process will be matched and allocated to the most recent and
current Process Server definitions. Upon completion of startup, the PSC proceeds to
enter its steady-state stage, which is the runtime stage.
The PSC remains in runtime stage for the duration of the application lifecycle until
application node shutdown is issued. In the runtime stage, the PSC repeatedly
performs the following actions.
• Detect & apply Process Server definition changes

• Dispatch Processes.
The above two actions are repeated on a default 2-second period, though this period
is configurable using a JVM argument named pscSleepTime (i.e. –
DpscSleepTime=5000 for 5-second period). It is not necessary to configure
pscSleepTime option, however. When there is no pscSleepTime JVM argument
specified, the pscSleepTime defaults to 2 seconds. On each periodic wakeup, PSC

applies Process Server definition changes, if any, and dispatches waiting Processes to
Process Servers for execution.
When an administrator changes Process Server definition(s) using the Process

Manager Configuration page, the updates take effect on the next period of PSC
runtime. On each periodic wakeup, PSC runtime will apply Process Server definition
changes. A Process Server has two runtime states: enabled and disabled. The state
names are self-explanatory, but Process Server definition change events that cause
the state transitions between these states are enumerated here.
• Enabled to Disabled
o Process Server is disabled
o Process Server hostname affiliation changed from no affiliation to a
specific hostname of peer Enterprise application node. For example, if PS1
hostname affiliation changed from unspecified to H1, PS1 is disabled on
application nodes N2 and N3 but continues to run on application node N1.
o Process Server hostname affiliation changed from hostname of local
application node to hostname of a peer application node. For example, if
PS2 hostname affiliation changed from H1 to H2, PS2 is disabled on
application node N1, and it is created and enabled on application node N2.
o Locally running Process Server is deleted.
• Disabled to Enabled
o Process Server is enabled.
o Process Server hostname affiliation changed from hostname of a peer
application node to hostname of local application node. For example, if
PS2 hostname affiliation changed from H1 to H2, PS2 is created and
enabled on application node N2.
o Process Server is created with either no hostname affiliation or with a
hostname affiliation matching hostname of local application node.
• Enabled to Enabled with Thread Count Change
o Process Server remains enabled.
o Thread count is decreased or increased to the new thread count.
o If thread count is decreased, running processes are allowed to complete
before the thread count is decreased to the new value.
Changes to Excel Executor or EMS hostname and port numbers do not alter the
running state of a Process Server. Process Server merely passes those attributes to
the running Process, so that correct Excel Executor or remote EMS can be invoked, if
applicable.
The next step after applying Process Server definition changes, PSC runtime
proceeds to dispatch waiting Processes to Process Servers with available threads.
The dispatch attempt is made only if there are idle Process Server threads. First PSC
dispatches Processes that are matched to specific dedicated Process Servers, then
dispatches Processes that are matched to general-purpose Process Servers. In each
dispatch attempts, PSC queries the PROCESS_EXECUTOR_ALLOC table to receive
waiting Processes in order by their submission time to maintain a FIFO order. For
specifically matched case, PSC looks for allocation records of with non-null Process
Server id and non-null allocation criterion id. In general-purpose case, PSC looks for

allocation records with null allocation criterion value. Note that an allocation record
with non-null Process Sever id but null allocation criterion id implies that the Process
is matched to a part-time dedicated Process Server during its general-purpose time
window. The allocation record queries are further qualified with two additional
constraints: list of Process Server identifiers and current time in HHMM numeric
format. The PSC looks for only those allocation records that either have a null value
for Process Server id or a value matching the id of one of its locally running Process
Servers. After all it is meaningless to retrieve allocation records that point to Process
Servers running on peer Enterprise application nodes. Recall that allocation records
have eligibility start-time and end-time in HHMM numeric format as described in
Process Submission section. It is here in the PSC where the eligibility time interval
values recorded during Process Submission are used.
Allocation Process Id Process Allocation Eligibility Eligibility

# Server Id Criterion Id Start Time End Time
1 P1 PS4 C3 800 1500
2 P1 PS4 Null 0 800
3 P1 PS4 Null 1800 2400
4 P1 PS3 C2 0 2400
5 P1 Null Null 0 2400
Repeating the Process allocation records result from previous example above, the
attempt to dispatch Process P1 for execution by PSC on Enterprise application node
N3 is demonstrated here. Enterprise application node N3 is running a general-
purpose Process Server PS1 and a part-time dedicated Process Server PS4. To
reiterate the allocation criteria of the earlier example, PS4 is dedicated to Region R2
Processes between 8:00 AM and 3:00 PM and to Region R3 between 3:00 PM and
6:00 PM. Let’s add some additional scenario conditions.
• Process Server PS1 and PS4 have only one thread each
• Process P1 is submitted at 2:59:00 PM
• Process backlog in database is large such that query for allocation records by PSC
on node N3 is about to take be invoked at 3:05:00 PM.
PSC first looks for specifically matched Processes, which includes P1. PSC queries
allocation records for PS4 having non-null criteria and current time as 1505 (3:05:00
PM in numeric 24-hour HHMM format). The query result yields one record with
allocation #1, whose eligible start-time and end-time are 800 and 1500 respectively.
Since current time 1505 is outside the eligibility period, P1 can no longer be
dispatched to PS4. Another way to look at this is to note that PS4 between 3:00 PM
to 6:00 PM is reserved for Processes for Region R3. Since P1 is for Region R2, it
cannot be dispatched to PS4. This objective was accomplished using the eligibility
interval in Process allocation record. Specifically matched Processes attempt by PSC
on node N3 results in no specifically matched Processes. Next the PSC attempts to
dispatch Processes to general-purpose Process Server. The general-purpose Process
Server PS1 is running on node N3. The PSC queries allocation records for allocation
records having null value for Process Server id, null value for allocation criterion id,
and current time of 1505 (3:05:00 PM in numeric 24-hour HHMM format). The query
result yields one record with allocation #5. Process P1 is dispatched to PS1 running
on application node N3. The act of dispatching a Process involves marking an
execution claim on the Process in SYS_PROCESS table such that no other Process
Server on a peer application node attempts execute the same Process. Process P1 is

generally allocated to all general-purpose Process Servers. Remember that

application node N1 and N2 are also running an instance of general-purpose Process
Server P1. The PSCs on N1 and N2 are also performing the same periodic dispatch
actions, and they will also see the same opportunity to execute P1 on their local
instance of PS1. So it is a race to claim Process P1. As soon as a PSC of an
application node, say node N3, recognizes that P1 is unclaimed for execution, it must
mark its claim on P1 so that N2 and N3 do not dispatch P1 to their local PS1. The
race to claim Processes also applies to dedicated Process Servers as well as general-
purpose Process Servers. P1 is also matched to the dedicated Process Server PS3
running on node N2. While this example focused on the PSC of node N3 for
simplicity, the PSC on node N2 may also be simultaneously examining P1 allocation
records for possible dispatch to PS3 or PS1. PSC deletes allocation records of a
Process from PROCESS_EXECUTOR_ALLOC table after it is dispatched for execution.
PSCs on all application nodes are continuously running and looking for Processes to
dispatch. Each PSC repeatedly queries the PROCESS_EXECTOR_ALLOC table and
SYS_PROCESS_* tables. The greater the number of application nodes in a clustered
environment, greater the frequency of these database table access and updates,
which can create opportunities for contentions on these tables. In some cases where
heavy database contention is observed on SYS_PROCESS_* tables, it may be
desirable to increase PSC runtime period by increasing pscSleepTime, which reduces
frequency of database interaction on PROCESS_EXECUTOR_ALLOC and
SYS_PROCESS_* tables. Lower frequency can reduce database contention, thus
increasing Process execution throughput but with the cost of reduced response time,
because a newly submitted Process must wait longer period of time before being
dispatched on the next runtime period. Another tuning parameter is the thread count
of Process Servers. Process Servers also make updates to SYS_PROCESS_* tables as
they update execution status of Process Tasks and Processes. So higher thread count
of Process Server can also increase contention on these tables. By default, each
Enterprise application node has a 10-thread general-purpose Process Server named
“Default” configured with 2-second period for PSC runtime. Tuning these parameters
to different value depends on individual deployment configuration and characteristics
of Processes and their submission rates.
When a PSC dispatches Processes to one of its local Process Server, it starts
executing in one of the Process Server thread. All Process Tasks of that Process
begin and end on the same thread. For each Process Task, following actions take
place in context of a Process Server thread.
• Update Process Task start time in SYS_PROCESS_TASK table

• Run Process Task. This can be a report, an InvestOne service, EMS task, etc.
Table below identifies different types of Process Tasks. Task types are often
referred to as container type, which are defined in sys_container_tbl.
• Retry the Process Task if it fails. By default a failed Process Task is retried five
times with a one second delay between each retry. The retry count and delay are
configurable with ARCH_PROPERTY names ProcessServer.RetryCount and
ProcessServer.RetryDelay. Note that these properties do not exist in
ARCH_PROPERTY by default. The ProcessServer.RetryDelay property is set in
milliseconds units, so for a retry deal of five seconds, this property must be set to
5000.
• Update Process Task end time, result code, and result message in
SYS_PROCESS_TASK table.

Once all Process Tasks are completed, PROCESS_STATUS is updated to Completed or

Error status in SYS_PROCESS table. If user pauses a running Process, the Process
Server thread completes current running Process Task, but skips all remaining
Process Tasks. Paused Processes have their PROCESS_STATUS changed to Holding
status; this is the mechanism by which Process Server thread recognizes a running
Process being paused. Process Server thread does not update the status of paused
Process.
This section concludes with summary of Process Execution related configuration

parameters discussed in this section.
Configuration Configuration Default Comments

Source Value
Process Server JVM argument 2 sec • JVM argument: pscSleepTime
Controller Period • JVM argument not required.
• When absent, default is assumed
• When present but with an illegal
value, default is assumed
Process Server Process Server - • Configured on Process Manager
Thread Count definition Configuration UI
• Administrator must supply a thread
count value when creating or
updating Process Server definition
Task Retry Count ARCH_PROPERTY 5 • Property:
database table ProcessServer.RetryCount
• Property row not present by default
• Administrator must add a new row
for ProcessServer.RetryCount and
set appropriate value
Task Retry Delay ARCH_PROPERTY 1000 ms • Property:
database table ProcessServer.RetryDelay
• Property row not present by default
• Administrator must add a new row
for ProcessServer.RetryDelay and
set appropriate value

Container Type (Task Type) Container Type (Task Type) Description

Browser Reports Browser Reports
Browser Report Packaging Browser Report Packaging
StandardEngineReports Standard Engine Reports
AuditTrailEngineReports AuditTrail Engine Reports
AuditTrailEngineReportSets AuditTrail Report Sets
StandardEngineReportSets Standard Report Sets
InvestOne Services InvestOne Services
Exception Template Exception Template
Xprt Reports Xprt Reports
Expense Calculator Expense Calculator
Standard Report Standard Report for Reporting Toollkit
File File for Reporting Toolkit
API API for Reporting Toolkit
Ad Hoc Ad Hoc Query for Reporting Toolkit
HybridEngineReports Hybrid Engine Reports
Regulatory Processing Regulatory Processing
Enterprise Processing Enterprise Processing
HybridEngineReports (IA Mode) Hybrid Engine Reports (Investment Accounting Mode)
XML Ready Reports XML Ready Reports
GLExtract GLExtract
Management Fee Processing Management Fee Processing
Status Codes and Descriptions
Co Special Status Description

de Case
W Not Started This is the initial state of a
submitted Process; the Process has
been added to the queue and is
waiting for a Process Executor
thread to initiate execution of the
Process.
R Running A Process Executor thread has
initiated execution of the Process.
P Paused The Process has been Paused.
(Paused processes can be Resumed)
E Error The Process ended with an Error.
C Submitted Engine Reports / Hybrid Reports:
JCL Request submitted to Engine.
C Note (1) Ended with Hybrid Report: Ended with Error.
Errors

C Note (2) Ended with Invest One Service: Ended with

Warnings Warning.
C Note (3) Ended The Process ended Successfully.
F Note (1) Ended with Hybrid Report: Ended with Error.
Errors
F Ended The Process ended Successfully.
Note (1): For Processes with a Process Code of ‘C’ or ‘F’ and containing one or
more Hybrid Report Tasks, the RESULT_CODE of each individual Task (in
SYS_PROCESS_TASK) is checked, and if there are any with non-zero value, then the
Process Status is set to ‘Ended with Errors’.
Note (2): For Processes with a Process Code of ‘C’ and containing one or more
Invest One Service Tasks, the RESULT_MSG of each individual Task (in
SYS_PROCESS_TASK) is checked, and if there are any that include the phase
“ioservice warning” (ignoring upper/lower case), then the Process Status is set to
‘Ended with Warnings’.
Note (3): For Processes with a Process Code of ‘C’ and containing one or more
Engine Report / Hybrid Report Tasks, if there are no Hybrid Report errors (see Note
(1) above), and all Engine Report Tasks have been successfully processed, then
Process Status is set to ‘Ended’.
When CLNT_PROCESS_TASK_RPT_TBL.REPORT_PATH is not NULL, it is assumed that

the Engine Report Task has been successfully processed.
1.10.1.4 Librarian
The Librarian was introduced in the 10.0 release of Enterprise. When upgrading an
environment from pre-10.0 release of Enterprise to 10.0 or higher, a database
population tool will need to be utilized to transition existing file-based content from
the file system into the database.
The Librarian is the interface to the Library and Catalog, and is used by other
components that need to store or retrieve a file. It is the responsibility of the
Librarian to create catalog entries when needed, store or retrieve the file from the
temporary or permanent storage. When a file is to be placed into the Library, either
for initial storage or update, the Librarian creates or updates an entry in the Catalog;
zips the file; pushes the file to the temporary storage; breaks the file into 1MB
blocks; Base64 encode each block; break up each block into chunks of N bytes; and
finally add/update/delete rows within the Library to permanently store this file. If a
file is to be retrieved from the Library, the Librarian reads the Catalog to retrieve the
file’s Library identifier. Next, an attempt is made to retrieve the file from the
temporary storage. If the file is found, it is unzipped and returned to the requester
as a file stream. If the file is not found, an attempt is made to extract its chunks
from the Library; join the chunks into a block; decode each block from its Base64
encoding; join the blocks back into an array of bytes; persist the array of bytes to
the temporary storage as a file object; unzip and return to the requester as a file
stream. If the file is not found, an error is returned to the requester.

The Library consists of two entities: permanent storage within the Enterprise
database and temporary storage within the operating system environment. The
temporary storage is monitored by the CacheStateManager for staleness and contain
a recent copy of a file which aids in the reduction of database use. A file that is
placed in the temporary cache exists as a single component in zip format. The files
stored within the permanent storage are zipped, broken into 1MB blocks, each block
is Base64-encoded and each block is divided in chunks which will fit within a
database page. Updates to permanent storage take into consideration the re-
use/addition/deletion of existing blocks and chunks for database efficiency. The
permanent storage is in the table LIB_LIBRARY.
The Catalog maps an internal identifier within the Library to the actual Path Name of
the file as it is known to the Enterprise application. The path name is “scrubbed” to
remove what appears to be environment-specific information such as a Windows
drive letter. Catalog entries also contain a customer identifier, a type, and usage
statistics such as read count, update count and cache hit. The Catalog is stored in
the table LIB_CATALOG.
1.10.1.5 Report Retention/Report Cleanup

There are three tables involved in this issue (plus the table for the scheduler task
configuration):
clnt_process_task_rpt_tbl
- Contains a list of all reports generated by way of ProcessManager
- Has a LIBRARY_ID column linking a report to LIB_CATALOG
- Has a retain_days column indicating how long a report should be kept in the
system (before being deleted)
LIB_CATALOG
- Contains a list of all files stored in the database, including many of those listed in
- Has the primary key LIBRARY_ID
LIB_LIBRARY
- Contains the raw report contents (base64 encoded) of the files listed in the
LIB_CATALOG
- Has a many-to-one association with LIB_CATALOG, with the foreign key
LIBRARY_ID
So, a ProcessManager executed report would be stored within these tables like:
rpt_id process_id task_seq task_id retain_days host_ip
host_port host_user_bank account_nbr account_desc
process_name task_name userid report_date run_date
report_path file_name report_data file_type create_userid
create_date update_useridupdate_date pdf_avail
distribution_profile_id distribution_status_id LIBRARY_ID
account_view
30,600 5,002 0 1,736 9 168.162.48.188 6061 M1 11000 SHORT
000000000011000 Assets and Liabilities Assets And Liabilities kbily 1991-09-02
00:00:00.0 2011-02-01 12:05:00.0 /ReportPkg/ Assets_And_Liabilities.xls
<null> zip <null> <null> <null> 2011-02-01 12:05:00.0 N 0
<null> 10,028,752 FA
LIB_CATALOG

LIBRARY_ID CUSTOMER_SID HASHCODE PATH TYPE SIZE

COMPRESSED_IN ACCESSED_DATE CREATE_USERID
CREATE_DATE UPDATE_USERID UPDATE_DATE
DELETE_USERID DELETE_DATE
10,028,752 1 -234,190,844 /ReportPkg/30600.xls 10 229,888
false <null> 25,000,562 2011-02-01 11:52:12.396 <null> <null> <null>
2011-02-01 12:07:19.996
LIB_LIBRARY
LIBRARY_ID BLOCK_ID CHUNK_ID CHUNK
10,028,752 0 0 UEsDBBQACAAIAIZeQT4AAAAAAAAAAAAAAAAUA...
10,028,752 0 1 oD7SZt+o5zOofoJs/YRd8jnKyg+cuu+i6mG0C…
10,028,752 0 2 qASj9l4kxPbqRbzRHMtoxGl0bIJRe58R4tx7l...
After a report is past its retention days, it is deleted by the system. There is a
scheduler task which does this. That task has the rerun_period of "H24@23:30",
which indicates that it should run every day (every 24 hours) at 11:30 pm (23:30).
The start_date indicates when it should next start. The last_run_date indicates when
it last ran, and the status indicates whether it is enabled "E" or in progress "P".
The task, stored in clnt_schedule_tbl, can be seen using:
select start_date, last_run_date, status, rerun_period, * from clnt_schedule_tbl
where schedule_name = 'Report Retention Monitor'
This task starts processing using this query to identify reports past retention:
select rpt_id, report_path, pdf_avail, LIBRARY_ID FROM clnt_process_task_rpt_tbl
WHERE datediff(dd, getdate(), dateadd(dd, retain_days, run_date)) < 0
Having identified such reports, they are immediately deleted from the
clnt_process_task_rpt_tbl table (by rpt_id).
They are also immediately marked as logically deleted (but not truly deleted) in
LIB_CATALOG by setting the DELETE_DATE to the current date (and making it non-
null).
Then, within 30 minutes, another background thread scans for rows in LIB_CATALOG
with DELETE_DATE not null, and deletes the corresponding contents in LIB_LIBRARY
and LIB_CATALOG. (The 30 minutes check is performed every thirty minutes from
when the application server started, and is not synchronized with the logical
deletion.)
1.10.1.6 Multi-threading (Pending)
1.10.1.7 XAMIN Specific Functionality (Pending)
1.10.1.8 IMpower Specific Functionality (Pending)
1.10.1.9 Report Packaging - Custom Report Package Template
Sporadically and due to a combination of one or more conditions, reports of a

Process Manager Report Package may have the rightmost columns overflow
to a separate page when the package is printed to PDF. When the individual
reports are downloaded, viewed and printed from Excel the results are correct
and no overflow occurs.

Possible Conditions:
• The default printer that is set on the coex server where Excel is
processing the report is not compatible with the PDF printer’s scaling,
margin, or font settings;
• The default Normal style used by Excel for a new, blank workbook and
report packaging is not compatible with the Normal style of the
individual report.
If column overflow persists after it is implemented and confirmed that the

default printer of the coex server is using a driver of compatible scaling,
margin, and font settings as the PDF device being used for printing, the
recommended solution for column overflow is to define and use within
Enterprise a Custom Report Package Template for Process Manager Report
Packaging.
Steps to Implement Custom Report Package Template in Enterprise
I. Define a Custom Report Package Template

II. Upload the Custom Report Package Template to the customer’s
database
III. Specify Customer Preference to use the Custom Report Package
Template
IV. Test the use of Custom Report Package Template using Process
Manager
Step Details:
I. Define a Custom Report Package Template
Use procedure A) or B) depending on whether a new template will be

created or an existing template will be taken from another customer’s
database.
A) If a new Custom Report Package Template is to be used:
1. Open a new blank workbook in Excel.

2. Change the Normal style for this workbook to use Arial 10 font.
3. Save the workbook as an XLS, giving it a file name that is
easily identified as a custom report package template. For
example: RptPkgTemplate.xls
B) If an existing Custom Report Package Template from another

customer’s database is to be used:
1. Use the Library File Management function of the SunGard

Enterprise URL where the custom report package template file
exists, to download and save a copy of it from the library.
2. Make any changes to the copy of the file.

II. Upload the Custom Report Package Template to the Customer’s

database
1. Use the Library File Management function of the SunGard

Enterprise URL where the custom report package template file
exists, to upload the new template to the library.
2. In the Path field, specify the same path (including the filename)
that was defined for the customer where the existing custom report
package template file was copied from, or if a new file or different
path is desired, specify the path and filename where the custom
report package template will be found in the library.
Example of Path including path/folder and file name:
/RptPkg/RptPkgTemplate.xls
*** Make sure there are no leading or trailing spaces in the

Path field.
3. Specify Customer SID = the number that is assigned to the

customer.
4. Specify Type = Report Template Resource.
5. Click Submit.
III. Specify Customer Preference to use the Custom Report Package

Template
6. Log in to Enterprise using the customer’s URL where the Custom

Report Package Template is to be used.
7. Select Administrator role. (Operator does not matter.)
8. Jump to CustPref (Customer Preference Summary).
9. Scroll down to view the Custom Report Package Template
parameter. (Parameters are listed in ascending alpha order.)
10. In the Custom Report Package Template field, specify the same
Path (which includes the filename) that was entered when to the
file was uploaded to the library.
*** Make sure there are no leading or trailing spaces in the Path
field.
IV. Test the use of Custom Report Package Template using Process
Manager
11. Test at least one process through process manager that previously
experienced column overflow problems when printing to PDF.
*** The Process Detail - Process Information screen for a Report

Package task will show the Parameter Name
ENV_RptPkgTemplate and its corresponding Parameter Value

(e.g., /RptPkg/RptPkgTemplate.xls) if the Custom Report Package

Template is defined before execution of the associated process.
12. If there are existing schedules that should use the Custom Report
Package Template, those schedules need to be updated in order to
include the Custom Report Package Template definition as a
parameter. After updating the schedules, test/run the schedules.
1.10.2 CPS
The Central Pricing System (CPS) is designed to support the validation and correction
of security prices on an ‘Exception’ basis.
CPS uses parameters in the Site Profile and User Profile to control specific
functionality. One such option allows the client to run the CPS component for single
user bank or multiple user banks. To utilize the Multiple User Bank processing, client
must also have IBM MQ Series for the DRIP/DROP processing for data download
configured.
The Site Profile is used to control specific options for CPS processing:
1) io_CPSMaxRows Max number of exceptions to display on CPS
Browser. screens
2) io_CPSRetentionDays Number of days to retain exceptions in the
database.
3) io_NewCPS ‘T’ will activate Multiple User Bank processing.
‘F’ will activate Single user Bank.
The User Profile is used to control specific options for CPS processing:
1) io_CPSMaxRows Max number of exceptions to display on CPS
Browser. screens
1.10.3 EMS
The Exception Manager System (EMS) is an Exception-based processing environment
that allows the InvestOne user to request the execution of tasks that run EMS
Business Rules. The rules identify ‘exceptions’ (i.e. outlier data conditions) within the
investment accounting data.
1.10.3.1 Multi-threading (Pending)
1.10.3.2 Dedicated EMS Servers

As of the 11.0 release EMS is a Java component and is packaged up within the
Enterprise.ear file. If specific servers in a server pool need to be dedicated to
handling just EMS work the following steps must be completed:
1. Do not expose the EMS servers to the users via the Load Balancer.
2. Configure the Process Servers on these servers to execute only EMS related
processes.

For example, a dedicated EMS server could be configured with ARCH_PROPERTY

settings, as set for its HOST_NAME, like:
Dedicated EMS server, using inclusion:
ProcessServer[1].StoredProcNameForSingleJobs
= “pm_getNextJob_in_container”
ProcessServer[1].StoredProcNameForMultipleJobs
= “sp_pm_getNewJobs_in_container”
ProcessServer[1].StoredProcContainerNames
= “Exception Template”
General purpose servers, using exclusion:
ProcessServer[1].StoredProcNameForSingleJobs
= “pm_getNextJob_ex_container”
ProcessServer[1].StoredProcNameForMultipleJobs
= “sp_pm_getNewJobs_ex_container”
ProcessServer[1].StoredProcContainerNames
= “Exception Template”
1.10.3.3 EXTERNAL DATASOURCE CONFIGURATION
The format of the Argument in WebLogic 'Server Start - Arguments' is: -
D[ImplServerName]=[IP:Port]
Where: [ImplServerName] is the unique ImplServerName associated with the
External Database (from EMS Database Server Screen)[IP:Port] is the IP and Port
of the External Database;
1.10.4 Expense Calculator

The Expense Calculator allows the user to define the basis of the expense
calculation, calculate and recalculate expensed amounts, store and report the
intermediate and final results of the expense calculation, and communicate the
results of the calculation back to the InvestOne Accounting Engine.
The Expense Calculator data is stored in a database separate from the operational
database. Each UserBank that contains data for the expense calculator requires its
own database.
1.10.5 MFC (Pending)
1.10.6 Reporting
1.10.6.1 Browser Reports
1.10.6.1.1 - HOW TO UPLOAD CUSTOM BROWSER REPORT PARAMETERS AND

TEMPLATES TO ENTERPRISE
Overview
To upload a changed Apollo_Parms.ini file, or a new or changed custom

parameter file, the user will:

• Use the Library File Management to apply changes to the

Enterprise database;
• Test one or more existing reports from within Enterprise that
depend on such changes.
To upload a new or changed custom browser report template, the user

will:
1. Use the UploadRpt function;

2. Conditionally execute TaskMaint;
3. Test the report within the environment;
4. Publish the template (menu sync, etc if needed);
5. Conditionally execute TaskMaint;
6. Retest the report within the environment.
NOTE: Library File Management should be executed before UploadRpt

when a browser report depends on parameter changes affecting the
Apollo_Parms.ini file.
Library File Management
Manually execute the following steps to apply to Enterprise any changes

made to a custom version of the Apollo_Parms.ini file or to apply new or
changed custom parameter files:
1) Log into Enterprise for the SunGard customer and choose the
Administrator role;
2) Jump to LIBMGMT;
3) To upload a custom version of the Apollo_Parms.ini file:
a. Use the Browse button next to the File Catalog field to locate
the Apollo_Parms.ini file on your local machine;
b. For “Path”, enter “Apollo_Parms.ini” (enter that string without
quotes);
c. Keep CUSTOMER_SID = 0;
d. Leave Text File as the Type;
e. Click Submit. (NOTE: Managed servers must be restarted in
order to effect Apollo_Parms.ini changes within Enterprise.)
4) To upload an existing (or new) custom parameter file:
a. Use the Browse button next to the File Catalog field to locate
the custom parameter file on your local machine;
b. For “Path”, enter “Includes/<filename>” (enter that string
without quotes, substituting <filename> , e.g.,
MyParameter.htm);
c. Specify the CUSTOMER_SID that that will be using the
parameter files;
d. Leave Text File as the Type;

e. Click Submit.
UploadRpt
Use this function to install a new or updated report template to

Enterprise. This function may also be used to update the database list
and properties (db table = clnt_task_parm_tbl) of a report template’s
parameters that are used for execution of the report within Enterprise
Process Manager.
This function should be executed after uploading any related changes

to a custom version of the Apollo_Parms.ini file or related custom
parameter files (as explained under the Library File Management
section of this document).
Steps:
1) Log into Enterprise using the Customer URL and an appropriate

role (e.g., Administrator, Manager, Fund Accounting role) that has
access to the UploadRpt function;
2) Jump To “UploadRpt”. Refer to existing Enterprise administrative
or user documentation for execution instructions;
3) To add a new report template, provide a unique Report Name,
JumpTo Name, and report template filename;
4) To overwrite an existing report template, provide the same Report
Name, JumpTo Name, and report template filename as the existing
report.
TaskMaint
Use this function to effect template changes of UploadRpt to any

existing processes and schedules that contain the same template task.
This function may also be used to synchronize the database list and
properties of a report’s parameters using the template’s parameters
for comparison and synchronization against the database.
Steps:
1) Log into Enterprise using the Customer URL with Administrator

role;
2) Jump To “TaskMaint”. Refer to existing Enterprise administrative
or user documentation for execution instructions.
Choose the appropriate Task Id from the list. Scan Only may be
executed first in order to review comparative results between the
database and template, and to determine whether a subsequent
Update should be executed on the selected task.
Steps to resolve deviation from above instructions

To resolve behavior whereas, during execution of the report, all or

some parameters are missing on the report’s input request screen, or
related custom Apollo_Parms.ini or underlying parameter files were
not first loaded to the database prior to using the UploadRpt function
of an affected report template.
Steps:
1) Use Library File Management when a custom Apollo_Parms.ini

or report template’s parameter definition files were not yet
uploaded, or they were uploaded incorrectly;
2) Run UploadRpt;
3) Run TaskMaint (Scan Only, then Update if necessary);
4) Confirm TaskMaint results;
5) Retest reports.
1.10.6.1.2 - HOW TO EXPOSE A ‘VERY HIDDEN’ SHEET IN AN EXCEL 2007

WORKBOOK
Steps:
1) From within the Enterprise - Viewer, save the report to desktop (desktop
or any other appropriate folder).
2) From the saved location, launch to open the report in local Excel.
3) Go to Review tab, choose the Protect Workbook function, and uncheck
the option Protect Structure and Windows.
4) If the Developer tab is not already visible in the ribbon, go to Excel
Options > Popular and check the box that is labeled “Show Developer tab
in the Ribbon”. Save changes. Exit the Excel Options.
For Excel 2010, go to the File tab, choose Options, then Customize
Ribbon. Check the Developer box that is listed in the right column. Save
changes.
5) From the Developer tab of Excel, choose the Visual Basic function.
6) From the Microsoft Visual Basic menu, choose View > Project Explorer.
7) From the Microsoft Visual Basic menu, choose View > Properties Window.
8) Within the Project – VBAProject pane, click to select the sheet that needs
to be made visible.
9) Within the Properties - Sheetn pane (now showing the properties for the
highlighted sheet), highlight the Visible property.
10) From the Visible property drop-down, choose the xlSheetVisible property.
11) At this point, the Visual Basic window can be closed or left open. The
objective is to get back to the Excel workbook window, and there are
several ways to get there:

a. From the Microsoft Visual Basic menu, choose File > Close and
Return to Microsoft Excel;
b. From the Microsoft Visual Basic menu, click on the Microsoft Excel
icon;
c. From the Windows task bar, click on the Microsoft Excel task that is
associated with the Microsoft Visual Basic task.
12) Within the Microsoft Excel Workbook window, find and click on the sheet
tab that is now unhidden.
1.10.6.2 RTK Reports
1.10.6.2.1 - PROCESS MANAGER TASK PARAMETERS REQUIRED FOR RTK

REPORT PRESENTATION OBJECT ‘NONE - From Date + 1’ OR ‘NONE -
From Date - 1’
In order for ‘“hidden” presentation objects (i.e., those having the

standard label ‘NONE’) to remain invisible on the Process Request
screen, in the database, the parameter named “usePresObjects” must
exist for the associated report task of the clnt_task_parm_tbl table.
Beginning with Enterprise 11.0 SP13, the “usePresObjects” parameter

is added automatically when an RTK report is published. RTK reports
published prior to Enterprise 11.0 SP13 did not have the parameter
automatically created.
There are two ways to update RTK reports published prior to Enterprise
11.0 SP13 that have reference to “hidden” presentation objects and
need to be run through Process Manager:
1. In Enterprise, republish the report;

2. In the database, run the stored procedure
SP_UPDATE_RTK_HIDDEN_PARM passing two argument values:
TaskName and CustomerSID. Create a copy (back-up) of the
clnt_task_parm_tbl before running stored procedure.
Uniqueness of display order is required when an RTK report uses more

than one ‘NONE’ presentation object, which can be achieved by using
the Report Definition function to assign Custom Label(s) to the
appropriate object(s), then republishing the report.
It is required for schedules to be re-added if they existed prior to

Enterprise 11.0 SP13 and include an RTK report that uses the ‘NONE’
presentation object.
Schedules must also be re-added anytime an associated RTK report has

a change in parameter name or other attributes.

1.10.6.3 Adhoc Reports (Pending)
1.10.6.4 Batch Reports

Enterprise Distributed Architecture provides browser-based access to engine
batch reports. The ability to create batch report sets is contingent upon the
User’s security access. Only users with Administrator or Update User authority
will have access to the set-up folder to create report sets.
A batch request is built on the Enterprise Distributed Architecture server and

messaged into the Accounting Engine. Enterprise Distributed Architecture builds
the request dynamically, based on the user supplied report parameters.
Reference the Enterprise Distributed Architecture User's Guide for more
information on report parameters. The Accounting engine processes the jobs
and sends an ASCII file to a designated Enterprise Distributed Architecture
server.
Executed reports are stored in the Librarian. When a user requests a previously
generated report, the server retrieves the file from the database and streams it
to the client.
The following parameters in the User/Site Profile are used by the Batch Report
process and therefore must be defined. They are:
er_retention_days Represents the number of days to retain previously requested Batch

Reports.
io_BatchRpt_Refresh Represents the rate at which the Engine Report Monitor page refreshes.
io_ERReportViewer The Engine Report Viewer type.
Er_ARFileQualifier This parameter corresponds with the middle node of the region
architecture file name for engine batch reporting requests.
Er_FileQualifier This parameter corresponds with the middle node of the region release
file names for engine batch reporting requests.
Io_MultiBookAcctg This indicates that the user profile utilizes MultiBook Accounting
parameters.
Io_TargetOperator The Target Operator for MultiBook Accounting configuration.
Io_TargetBank The Target Bank for MultiBook Account configuration.
Io_EngAudit TrailJCLTarg The Engine Cardlib member containing the Audit Trail Reports JCL for the
Target Operator in MultiBook Accounting configuration.
io_EngAuditTrailOpensTarg The Engine Cardlib member containing the Audit Trail Reports Opens
Cards for the Target Operator in MultiBook Accounting configuration.
io_EngAuditTrail Allows Engine Audit Trail reports.
io_EngAudit TrailJCL This is the Engine Cardlib member containing the Audit Trail Reports JCL.
io_EngAuditTrailOpens This is the Engine Cardlib member containing the Audit Trail Reports
Opens Cards.
Io_EngBatchReptJCLTarg This is the Engine Cardlib member containing the Batch Report JCL for
the Target Operator in MultiBook Accounting configuration.
io_EngBatchReptOpensTarg This is the Engine Cardlib member containing the Batch Reports Opens
Cards for the Target Operator in MultiBook Accounting configuration.
io_EngBatchReptJCL This is the Engine Cardlib member containing the Batch Report JCL.
io_EngBatchReptOpens This is the Engine Cardlib member containing the Batch Reports Opens
Cards.
io_EngSubmitJCL This is the name of the Local Engine Report Submit JCL file, which is a

text file that is messaged in.

io_EngSumbitJob This is the Batch report Engine Job Name.
A Java Applet report viewer is used to display the engine report in the browser.
The submission and processing of Engine Reports in Enterprise involves several AAIA
components and sub-components working in concert. These components are:
• Enterprise Managed Server (Enterprise)
o ProcessServer
o
o EngineReportPollerService (a Scheduler Service)
o EngineReportsProcessor
• FTP Server
• Database
• InvestOne Engine
Engine Reports may be submitted for processing either interactively via a user on the
Process Request Screen, or as a scheduled task. In both cases, Enterprise submits
the Engine Report job request by inserting new rows into the Process Manager
database tables. This is no different that submitting any job request to Process
Manager. The relevant Process Manager tables are:
• SYS_PROCESS
• SYS_PROCESS_TASK
• SYS_PROCESS_PARM
A Process Server instance in Enterprise then claims the job, modifies its status as
Running, and proceeds with its execution. With Engine Report requests, Process
Server opens a connection to the InvestOne Engine and streams the report JCL to
the Engine for execution. This JCL submission is asynchronous, as Process Server
does not wait for the Engine response. Upon acknowledgement that the JCL
submission to the Engine was successful, Process Server considers the job complete.
Once the InvestOne Engine completes the JCL execution, it pushes the resulting
report (with an .IOR file extension) to the configured FTPServer. At this point, the
involvement of the InvestOne Engine is complete.
NOTE:
There is a significant difference between the Mainframe and UNIX implementations of the InvestOne
Engine, regarding the configuration of the FTPServer. With a Mainframe implementation, the FTPServer
connection info (address, port, user, password, etc.) is included in the submitted JCL. It is ultimately
configured in the ARCH_PROPERTY table of the database, and Enterprise queries this info when building
the Engine Report job request and JCL. (relevant settings are listed below) With the UNIX
implementation, the FTPServer connection info is configured via a local config file on the UNIX server.
In both implementations, the FTPServer may be, but does not need to be, co-located on the same server
instance as the Enterprise Managed Server.
Every Enterprise Managed Server instance runs a Scheduler service called

EngineReportPollerService, initiated at startup. This scheduled service is triggered to
run at a predefined scheduled interval as defined by its schedule definition in the
clnt_schedule_tbl. By virtue of being part of the Scheduler framework, this service is
guaranteed to be run by only one Enterprise instance at any given moment. The
DEFAULT schedule frequency for this service is defined to be at every 60 seconds by
the supplied database scripts for this Enterprise release. Upon every scheduled

invocation, this service looks for newly completed report files on the FTP Server.
When a new file is detected, it first reserves the file for processing by renaming the
file with a “.res” extension, thus preventing any inadvertent service invocations by
other Enterprise instances in the same environment from doubly processing the file
(This is just a defensive technique although technically it is now not possible for
other instances to process this same file during the same time). For example,
“123456.ior” is renamed to “123456.ior.res”. The next service implementation step
opens the report file for reading and creates a new temporary copy of the report on
the host filesystem of the Enterprise instance of which it is a component. Once this
copy is complete, it deletes the report file on the FTPServer.
NOTE:
The local directory for temporary report copies is almost always <EnterpriseHome>/workingstore/ftp.
EngineReportsProcessor (another component of Enterprise) is then asynchronously

invoked by this service to complete processing. At this point a single scheduled
EngineReportPollerService invocation is deemed complete and the Scheduler
framework is now responsible to mark this completion event and thereby yielding to
other waiting scheduled service instances on other Enterprise servers. The
asynchronous invocation of EngineReportsProcessor first queries the database to
confirm that the report is valid for the user and customer associated, and then stores
the report within Librarian database tables (LIB_CATALOG & LIB_LIBRARY). Once
the storing operation completes successfully, the report may be accessed via
Enterprise transactions. Finally, EngineReportsProcessor updates the Process
Manager database tables for the job request to indicate the job is now Finished, and
deletes the temporary report file. Processing is now complete.
If for some reason, the job fails on the AAIA engine, the Engine Report request will
stay in Submitted forever because no report file was sent back to Enterprise.
Engine Report Configuration Settings in ARCH_PROPERTY

ARCH_PROPERTY Setting Description Default
Value
EngineReports.Server Identifier (DNS If null or

entry or IP blank, code
address) of server defaults to
to which the Engine host server
will FTP the
completed Engine
Report.
EngineReports.FTPPort Port on which the 21
FTP server will be
listening
EngineReports.FTPUser FTP server user “ftpuser”
name
EngineReports.FTPPassword Password for “ftppassword”
FTPUser on FTP
server
EngineReports.FTPMode Specifies whether “passive”
active or passive


Value
FTP mode is to be
used
If an Engine Report request sits in Submitted state and never completes, one can log on
COBOL engine and look into the job queue and look for the Engine Report Request.
Troubleshooting Steps when problems arise related to EngineReportPollerService
1) Check if the Scheduler is enabled. Normally it is enabled by default in the code.
Query the DB table ARCH_PROPERTY. The VALUE column should have value as true.
SELECT * from ARCH_PROPERTY WHERE UPPER(PROPERTY_NAME) like
upper('%Scheduler.Enabled%')
2) Check if the ftp credentials are properly set.

upper('%EngineReports%')
20000244
CONFIG Enterprise * EngineReports.FTPPort * 21
The port to be used by the engine to FTP the report back to
Enterprise.
SunGard SunGard 2010-01-20 12:19:24.0 NULL NULL NULL
20000246
CONFIG Enterprise * EngineReports.FTPPassword * Y9J1JwL
RyCjLLNoAK/wu+w== The password to be used for authentication with the Engine Reports ftp
server within Enterprise (case sensitive). A blank password is highly
discouraged. SunGard SunGard 2010-01-20
12:19:24.0 NULL NULL NULL
20000247
CONFIG Enterprise * EngineReports.FTPUser * apolloftp
The user name to be used for authentication with the Engine Reports ftp server within
Enterprise (case sensitive). A blank user name is highly
20000250
CONFIG Enterprise * EngineReports.Server * 10.15.2.89
The user name to be used for authentication with the Engine Reports ftp server within
Enterprise (case sensitive). A blank user name is highly
Check if these credentials do work by connecting to the specified ftp server using the specified
user/password.
The password is normally 'ftppassword'
Normally an ftp user is created on the same machine which hosts the application server, though it
is not necessary and should work fine with any other existing ftp site meant for
Enterprise/InvestOne.

3) Check if the FTP Poller service is set up and running.
• First check in the MercuryLogging.log for any occurrence of EngineReportPollerService.

• Enable trace/debug logging for
"com.sungard.sims.mercury.processmanager.service.EngineReportPollerService".

upper('%Logger.Categories.%') and HOST_NAME like 'vm-dev-antelope.sungardims.net'
UPDATE ARCH_PROPERTY SET VALUE =
'com.sungard.sims.mercury.processmanager.service.EngineReportPollerService,
com.sungard.sims.mercury.enginereports.components.EngineReportsProcessor' WHERE
ARCH_PROPERTY_SID = ?
4) If the Poller service is not running, check the entry in the table, specifically the value in
column RERUN_PERIOD, LAST_RUN_DATE, SERVER_NODE_UUID
select * from CLNT_SCHEDULE_TBL where PROCESS_PATH like '%EngineReportPoller%';
If the value in LAST_RUN_DATE is not in the current date, then you will need to set the values in
RERUN_PERIOD to enable the schedule to pick up and run the poller service
UPDATE CLNT_SCHEDULE_TBL set RERUN_PERIOD = 'S60' where PROCESS_PATH like

'%EngineReportPoller%' and SCHEDULE_ID = 19;
‘S60’ means schedule will run every 60 seconds.
1.10.6.5 Engine Reconciliation Reports

These Engine reports are only submitted for processing interactively by an user who
wishes to compare the results of multiple Engine batch report processing.
TrialBalanceComparisonReport is one such report which is submitted interactively by an
user who wishes to compare the results of multiple views of the same Engine batch
report submission. In this case, the browser submission thread submitted interactively by
the user, triggers multiple batch report submissions on the server one for each View the
user has selected on the submission screen (FA / IA, etc) and waits for all processing to
be completed and the reconciled results are rendered to the browser.
The submission and processing of Reconciliation Reports in Enterprise

involves several AAIA components and sub-components working in concert.
These components are:
• Enterprise Managed Server (Enterprise)
o Classes implementing FileProcessor Interface
o FTP Poller
• Database
• FTP Server
• InvestOne Engine
Unlike individual Engine batch report submissions, the reconciliation reports pose the
requirement of the same Enterprise server instance both submit and process a given
Engine report placed on the FTP Server. This is because the browser is waiting for the
reconciled results from the server to be rendered to the interactive user who submitted
the request. A special interface called FileProcessor is created to achieve this by
registering all Service classes and their submitted file names to the FTPPoller class.
The FTPPoller class is now exclusively used for monitoring only those file names that are
registered with them on the FTP Server. As and when these files are placed on the FTP

server by InvestOne engine, only one FTPPoller implementation amongst all Enterprise
instances would process a given file because the others would not have registered these
files with them. The FTPPoller class then makes a call back to a method on the service
class (on the same Enterprise instance) that registered itself to prepare the file for
rendering it to the waiting browser.
Engine Reconciliation Report Configuration Settings in ARCH_PROPERTY

Value
EngineReports.FtpPollerEnabled Indicator of true
whether
Engine
Reconciliation
Report
processing is
enabled.
EngineReports.PollingFtpServerThreadCount The maximum 5
number of threads
on a single
Enterprise instance
for concurrent file
processing from
FTP Server.
EngineReportsPollingFtpServerIntervalSeconds Number of seconds 15
to sleep between
polls on the FTP
Server when no
files are found for a
given polling
attempt.
Note: The ARCH_PROPERTY entries EngineReports.Server, EngineReports.FTPPort,

EngineReports.FTPUser, EngineReports.FTPPassword and EngineReports.FTPMode
are used for Reconciliation report processing as well in the same way they are used for
individual batch report processing.
1.10.6.6 Hybrid Reports (Pending)
1.10.6.7 Security Access Reports

Security Access Reporting provides information to Administrators only on the User or
Role details, System Access Level and Activity Log Format. As noted in the following
sections, this reporting can be extracted from two levels: User or Role
Reports by Users
Jump To: UserSum

Displays the User-Definition Summary screen where the Administrator selects a
user(s) by clicking on the select box  next to the user(s), and following their
selection, can now access the Security Access Report Request using the Security
Report button.

Security Access Report Request (screen)

This is the screen that appears for “Security Access Report Being Requested For: All
Users.” It appears when a user selects one or more users (but not all of them) from
the User Definition Summary screen as shown above.
Grid Fields
Field Name Description

Role/Function/Action DISABLED at User Level.
List
User/Role/Account This report lists all the valid roles/user banks/operators/Accounts for
List selected users.
User Login List Lists logon status for the selected users.
External Id List Lists all external ids for the selected users.
Action Buttons

Button Label Description

Submit Loads the requested reports in a pop-up window.
Cancel Clicking this button cancels the “Loading Report” process which displays a
“Report Load Cancelled” window, and subsequently closes the pop-up
window. User is then returned to the User Definition – Summary screen.
Reports By Role
Jump To: RoleSum
Displays the Role Summary screen where the Administrator selects a role(s) by
clicking on the select box  next to the role(s), and following their selection, can
now access the Security Access Report Request using the Security Report button.
Security Access Report Request (screen)

This is the screen that appears for “Security Access Report Being Requested For:
Specified Role(s).” It appears when a user selects one or more roles (but not all of
them) from the Role Summary screen as shown above.
Grid Fields

Role/Function/Action This report lists all the Function Collection, Functions, Function Action
List and the JumpTo data’s defined for the selected users.
User/Role/Account This report lists all the valid roles/user banks/operators/Accounts for
List selected users.
User Login List DISABLED at Role Level.
External ID List DISABLED at Role Level.
Action Buttons
Button Label Description

Submit Loads the requested reports in a pop-up window
Cancel Clicking this button cancels the “Loading Report” process which displays a
“Report Load Cancelled” window, and subsequently closes the pop-up
window
Security Access Report Descriptions:
Role Level
disabled
User Level
disabled

User/ Role/Account List:
This report consists of the three types of individual reports: User Account, User
Client and User Role.

User Account
This report type provides the Administrator with information about the Operator,
User Bank and accounts associated with the selected users.
Grid Fields

Login ID Displays the Login ID for a User Role.
First Name User’s First Name.
Last Name User’s Last Name.
Non-Expiring Determines if the password expires after a certain period of time as predefined
Password Indicator in the system by the Administrator.
Operator ID Indicates the Operator’s Name.
User Bank Indicates the User Bank Information.
Account # Displays the Account number.

User Client
This report type provides the Administrator with all the User Role’s Login information
for the corresponding Client ID as defined by the system.
Grid Fields

Login ID The User Role’s Login ID.
Client ID Provides the information about the Client ID and associated User Role.

User Role
This report type lists the roles that are associated with each selected user.
Grid Fields

Login ID The Login ID for the User Role.
Role ID Roles associated with each User.
User Login List:
This report type provides complete information about the User Login.

Grid Fields

Login ID The Login ID for the User Role.
Active Flag Denotes whether the User’s ID status has been activated or
deactivated.
Non- Expiring Flag denotes whether the password expires after a certain period as
Password predefined in the system by the administrator.
Lock Flag Flag denotes whether the user’s ID is Locked or Unlocked.
Lock Reason Explains the reason for why the User ID was Locked.
Date of Last Access Provides information about the last time a user accessed the system.
Date of Last Indicates when the password was last changed.
Password Change
Comments General comments added by the user.
Role/ Function Action List:
This report type lists all the Function Collection items associated with each selected
role including Functions, Function Actions and JumpTo values. It is grouped by Role,
Function Collection and Functions

Grid Fields

Function Collections Lists the Function Collections associated with a selected role.
Functions Lists all the Functions attached to the Function Collections for a selected
role.
Function Actions Lists all of the Function Actions permitted for a selected role.
JumpTo Denotes the JumpTo Values defined for the particular Functions for a
selected role.
User/ Role/ Account List:
This report lists the information about a User who is associated with a selected role.

Grid Fields

Login ID Displays the Login ID for the selected User Role.
Non- Expiring Determines if the password expires after a certain period of time as
Password predefined in the system by the Administrator.
Operator Displays the Operator selection made by the user when they log on to
the system.
UserBank Displays the UserBank selection made by the user when they log on to
the system.
Account # Displays the Account number.
External ID List
This report type provides a list of all external ids associated with the selected users.
Grid Fields

Login ID Displays the Login ID for a User Role.

External Cross An External Cross Reference ID that is associated with the selected
Reference ID User.
System Defined by the Administrator.
1.10.6.8 GCR Reports
1.10.6.9 EMS Reports
1.10.6.10 Browser Spectra

The Spectra Reporting Module is comprised of four (4) distinct functional areas:
1. Spectra Report Designer

2. Spectra Report Execution
3. Spectra Report Viewer
4. Spectra Utilities
1.10.7 Report Viewer

• JRE memory requirements to support CSV file printing from the Report Viewer:
1) CSV File size up to 18 Meg - JRE memory of 256 Meg
2) CSV File size up to 35 Meg - JRE memory of 512 Meg
3) CSV File sive up to 70 Meg - JRE memory of 1 Gig
To configure the JRE memory, specify a Java Runtime Parameter of -Xmsnnnnm

(where nnnn=number of Meg).
For example, -Xms1024m is the runtime parameter value to configure 1024 Meg
(aka 1 Gig).
1.10.8 Excel Redirect Setup

In Process Manager, customers can save reports and report packages to a specified
directory location on the Apollo server and control the file naming convention
utilized. The user directs the output to a specific directory (i.e. an ftp directory)
from where the files can be distributed.
The business user passes parameters from the process to be used in naming of the
files. This allows the user to indicate such parameters as report name, account
number, run date and reporting date in the file name. This functionality is available
for pdf and xls files. This document details the process associated with xls files only.
Set Up
In order for Process Manager to support the Excel Redirection functionality, the
following setup is required:
• Apollo Site Profile changes

• Apollo User Profile changes
• Creation of appropriate directory(ies) on the Apollo server(s) for directed

reports
• Third-party file watcher/FTP process to push or pull files as needed
Site Profile
Three parameters are specified within the Site Profile, as shown below. Please note
that only user IDs with administrator access in Apollo have access to the
Administration folder and can update the Site Profile within Administration. If you
do not see the Administration folder within the Asset Arena Performance Reporting
menu, your ID is likely not setup with Administrator access. Please contact your
system administrator for assistance.
A) pm_excel_report_dir: The main directory to which reports are directed on the

Apollo server(s) is specified here. The option exists to write reports to
different sub-directories within this main root directory. On a user by user
basis, then, different sub-directories can be utilized for greater control over
report direction.
Notes: (1) The pm_excel_report_dir can be specified as a directory path on the local
file-system of the server that is running the EnterpriseExcelExecutor.
(2) The pm_excel_report_dir can also be defined as a directory on a remote
server. When a remote server location is used, it is recommended that the
actual UNC path be used, rather than a mapped drive, to mitigate problems
with access and permission on the remote server.
(3) The directory path should include a trailing backslash. However, when
specifying a UNC path, any backslash character should be replaced with a
pair of backslash characters. For example, UNC path
\\11.22.33.44\EEE\Reports\ should be specified as
\\\\11.22.33.44\\EEE\\Reports\\.
(4) The remote server can be a UNIX environment (e.g. Linux). This
requires configuration of the UNC path using SAMBA.
(5) For remote server configurations, it is necessary that the user running
the EnterpriseExcelExecutor service has full permissions to the shared
directory. For SAMBA, this may require giving everyone write access to the
SAMBA share.
B) pm_excel_report_name: This parameter dictates the file naming convention.

The same naming convention will be used for all users on the server. Any
combination of the file name parameters may be used to name the output
files; all or a subset of parameters may be used. The order of the parameters
in the file name is also user defined. The order in which the parameters are
entered in the Site Profile’s pm_excel_report_name field is the order in which
the values will appear in the file name.

File Name Parameters
Description Parameter
Account/Group Number %an
Process Name (Package Name) %pn
As of Date / To Date %tdx
From Date %fdx
Task Name / Report Name %tn
Run Date %rd
Note: If a report uses a date from a pick list, such as Latest Day or Latest Month,
and the From Date (%fdx) value is defined within the naming convention, the output
file will contain a “()” value in the file name for the From Date. The From Date will
only be populated in the file name for reports that utilize separate From and To date
field selections, such as Security Detail Performance Analysis.
C) Pm_persist_excel_reports: By invoking this option, setting the value to “Y”,

this allows the Redirect Excel Reports option to display on the New Process
Request page within Process Manager:
User Profile
Within the User Profile, there are two optional parameters that can be defined,
pm_excel_report_dir and pm_excel_report_name. If either or both of these
parameters are not defined at the user level, the default values as specified within
the Site Profile will be used. The pm_excel_report_dir option at the user level allows
a sub-directory to be specified to which a particular user’s redirected reports will be
saved. This sub-directory resides within the root directory specified in the Site
Profile.
The pm_excel_report_name parameter gives the user the option to change the file
naming convention from that defined at the site level for that individual user’s
redirected reports. Refer to the previous Site Profile section for the list of file name
parameters.

Please note that only user IDs with administrator access in Apollo have access to the
Administration folder and can update the User Profile within Administration. If you
do not see the Administration folder within the Asset Arena Performance Reporting
menu, your ID is likely not setup with Administrator access. Please contact your
system administrator for assistance.
1.10.9 Brokers (Pending)
1.10.10 Decalog (Pending)
1.10.11 Admin Process Monitor

Admin Process Monitor screen has been created as a SunGard administrator utility
screen in Enterprise. It provides SunGard administrator the access to pause or delete
processes submitted by other users in different customers.
Prior to the release, only the users who submitted the process can either pause or
delete their processes in Process Monitor screen. In many cases, TSM group have to
delete some processes in Process Monitor page for the customers. Because of this
limitation, they cannot continue with the deletion activity and hence, came the
concept of Admin Process Monitor screen.
A new screen can be seen through SunGard customer in Administrator Role, using
following mechanisms –
• Using Menu: Application Administration  Process Manager  Admin
Process Monitor
• Using Jumpto: AdminProcMon
By default, the screen looks like below –

Field Descriptions are as follows –

Field Description
Customer This drop-down lists all the customers available under the
Name Enterprise environment. It acts as a filter condition.
User ID Administrator need to input the User ID which is available under
selected customer. It acts as a filter condition.
Submit Date Submission Dates for the processes in selected customer. This field
varies as per customer selected in Customer Name field. It acts as
a filter condition.
Process Name Process Name of the submitted processes in selected customer.
This field varies as per customer selected in Customer Name field.
It acts as a filter condition.
Status Status of the processes. It acts as a filter condition.
Load Load the screen as per the defined filter conditions.
Process Number assigned to identify individual processes.
Account Enterprise Account Number for which the process has been
submitted.
View Accounting view of submitted process.
Process Name Name of the submitted process.
Task Name Name of the task that is currently being processed and its job step
number.

Submit Date Submission Date and Time of the process.

Duration Time duration for which the process ran. The format is
HH:MM:SS.MS
Status Current status of the submitted process.
PAUSE Valid only for processes that are currently executing and have a
Status of "Running." Ceases the execution of the process and
changes the status to Paused. To start up the execution of the
paused process, select the "Resume" or "Retry" button.
RESUME Valid for processes that have a Status of "Paused" or "Error." When
the Resume button is clicked, the first step of the process that did
not complete successfully is bypassed, and the remaining steps are
processed.
RETRY Valid for processes that have a Status of "Paused" or "Error." When
the Retry button is clicked, the first step of the process that did not
complete successfully is reprocessed. If that step does not
complete successfully, the process ends and the remaining steps, if
any, are not processed. If that step completes successfully, the
process continues and the remaining steps, if any, are processed.
DELETE Valid for all processes. After highlighting one or more of the
displayed processes, clicking on this button results in the deletion
of the highlighted processes.
VIEW Valid for all processes. Highlight a single process and use this
button to view the Process and detailed Task information related to
it. Click on the ‘Task Name’ link to view the Process Detail.
Points to note –
• No processes will be displayed until the user has clicked on the LOAD button.
Upon any change to filter criteria the user needs to click on the LOAD refresh
the list of processes displayed.
• The data in the table is not restricted to the user's currently logged in
Userbank and Operator.
• Administrator can filter the data using following filter parameters –
o Customer Name
o User ID
o Submit Date
o Process Name
o Process Status
• The table in which the processes are displayed has a paging mechanism. Only
300 processes are displayed per page. The table can be sorted by any of its
columns.

1.10.12 Architecture Property Maintenance

Architecture properties are application-wide properties which are stored in
ARCH_PROPERTY table. A new screen, named as Architecture Properties Maintenance
has been created which provides the SunGard Administrator the –
• Ability to add, change, delete Enterprise architecture properties.
• Ability to view history of changes (addition, modification, deletion) of Enterprise
architectural properties.
Prior to this release, administrator was required to run external SQL to add, change
or delete properties which were very error prone and can cause accidental updates to
the properties whose values were not intended to be changed. Along with this, there
is no auditing capability to track the changes done to these properties.
Architecture Properties Maintenance screen has been created to remove above
mentioned setbacks. A new screen can be seen through SunGard customer in
Administrator Role, using following mechanisms –

• Using Menu: Utilities  Application  Architecture Properties Maintenance

Using Jumpto: ArchProp
All currently ACTIVE (i.e. ones that are not DELETED) properties with their values
could be seen in this screen.
Field Descriptions are as follows –

Field Description
Property Type These are the property types available in the below table. It acts
as a sorting parameter. Be default, its value is ALL.
Host
Property Type
Property Name Name of the architectural property.
Property Desc Description of the architectural property.
Host Name
Value Value provided by the Administrator for specific architectural
property.
ADD This button can be used to create a new architectural property.
VIEW This button can be used to view the details of existing architectural
property.
CHANGE This button can be used to change the details of existing
architectural property.
DELETE This button can be used to delete an existing architectural
property.
HISTORY This button could be used to view the history of updates made to
architectural properties.

Architectural Properties Maintenance: ADD Mode –

A new architectural property can be entered by clicking on ADD button on the
Property Listing screen. Once user clicks ADD button, a pop-up screen will be opened
–
Following is the basic functionality –

• Property Type has to be selected from the provided drop-down.
• Property Name makes use of an auto-complete feature to assist the user in
remembering available property names. The user is not restricted by these
options. Once administrator starts typing the property name, the system provides
the automatic option to help him/her –

• Host Name is by default set to *. Administrator can change it, if required. In

database, Host Name when left blank defaults to “*”.This denotes the value that
will be used as a default for this property across all Enterprise instances (as long
as they don't have a override specific for their host name).
• Administrator provides the value of specific architectural property in Value field.
This field also has an auto-complete functionality. Once administrator starts
typing the value, the system provides the automatic option to help him/her –
If the user selected the Property Name "Logger.Categories.debug" or

"Logger.Categories.trace" the value field makes use of an auto-complete feature
to assist the user. The user is not restricted by these options, and multiple values
can be entered. Some basic validation has been added on the value field to ensure
user enters Numeric or Boolean values ('true' or 'false') where the code base is
clear about what these must be.
• Description of the architectural property can be provided in Property Desc field.
It’s an optional field.
• Comment field has been introduced so that the Administrator can provide his
comments while adding, changing or deleting an architectural property. It will be
helpful in auditing purpose.
• Property Type, Property Name, Value and Comment are all required fields.
Comment value entered here will be persisted in the new AUDIT_ACTION table
along with the ARCH_PROPERTY_SID and the value of the newly entered arch
property as an "Add" action item. This audit information will show up the "View
Arch Property history" page that can be viewed by clicking on the HISTORY
button.
• The maximum number of characters that can be input to these fields should match
the corresponding column sizes in the ARCH_PROPERTY table.

Once user clicks on OK –

• The information gets saved in the database and dialog box gets closed.
• An appropriate success or error message will appear at the bottom of the property
listing screen.
• The new property will show up in the property listing page upon the changes
successfully being applied.
• A non-blank Host name, which when is new to the ARCH_PROPERTY table,
will show up as a "Host" filters option in the property listing screen upon the
changes successfully being applied.
In case, user clicks on Cancel, the dialog box will be closed with no new data saved
and user gets back to property listing screen.
Architectural Properties Maintenance: VIEW Mode –

The VIEW button will always be enabled along with ADD button. A property can be
selected from the arch property listing grid and the selected property details can be
viewed in a Dialog that will open upon clicking the VIEW button. All fields will be in
READ ONLY mode and the CANCEL button will be hidden. Clicking on OK will close
the dialog and take you back to the Property listing screen.
In case, user clicks on VIEW button without selecting any property from the grid,
following error message should be displayed at the bottom of the screen –

Architectural Properties Maintenance: CHANGE Mode –

The CHANGE button will always be enabled along with ADD button. A property can
be selected from the arch property listing grid and the selected property details can
be changed by clicking on the CHANGE button. The property maintenance dialog will
open. Property Host, Value, Description and Comment fields will be the only editable
fields. All other fields will be in Read Only mode. The Comment will be the only
required field when the OK button is clicked on this dialog before the dialog is closed.
Clicking CANCEL will not perform any action and will just close the dialog and take
the user back to the property listing screen. The Comment value entered when the
property values are changed will be persisted in the new AUDIT_ACTION and
AUDIT_DATA tables. These tables will contain information on the
ARCH_PROPERTY_SID, Old and new values for each field that were changed
recorded as a "Change" action.
In case, user clicks on CHANGE button without selecting any property from the grid,
Architectural Properties Maintenance: DELETE Mode –

The DELETE button will always be enabled along with ADD button. A property can be
selected from the arch property listing grid and the selected property can be deleted
by clicking on the delete button from the dialog that will open up after having clicked
the DELETE button. All fields will be read-only except the Comment field. Clicking
CANCEL will just close the dialog and take the user back to the Property listing
screen without deleting the property. Clicking OK will force the user to enter a value
for the Comment field before closing the dialog. The Comment value thus entered
will be persisted in the AUDIT_ACTION table along with the ARCH_PRPERTY_SID of
the property being deleted as a DELETE action.

In case, user clicks on DELETE button without selecting any property from the grid,
Architectural Properties Maintenance: HISTORY –

The Architecture Properties History page is a child page of Architecture Properties
Maintenance (ArchProp) page. History of updates made to architecture properties via
the Architecture Properties Maintenance is maintained, and is available for viewing
on the Architecture Properties History page. The updates include addition of new
property and modification or deletion of existing property. The Architecture
Properties History is launched from the Architecture Properties Maintenance page by
clicking the HISTORY button.

Following is the description of fields available in History screen –

Field Description
Action Time The time at which the changes were committed for any property. It’s
format is MMM-DD-YYYY HH:MM AM/PM. For e.g. Apr-18-2013 08:49
AM
Action It provides the information on the action taken for a particular
property. The options available are Add, Change and Delete.
Property It is the name of the property for which administrator has made the
Name changes.
Comment Comments provided by administrator while making the changes in
the property.
Following is the basic functionality of this screen –

• Can be launched only by HISTORY button click action on Architecture
Properties Maintenance screen.
• Functionalities associated with buttons are as follows –
o LOAD –
 It fetches initial history from the server.
 It is enabled only during initial launch when user has never fetched
history from the server.
 It gets disabled after the first/initial history data is fetched. User
may update filter inputs and click REFRESH button to re-fetch
with modified filters.
o REFRESH –
 It is used to re-fetch history from the server with new filter values.


It remains disabled on initial page launch.

It remains disabled until first time; history is fetched with LOAD
button click action.
 It gets enabled when filters are modified after initial history fetch.
o DETAILS –
 It remains disabled until the administrator select a row in the
history summary table.
 Once an entry is selected and user clicks on this button, it can show
details such as old value and new value of changes in the form of
architecture property change dialog box.
 Architecture Property Change dialog contains following details –
• Property Name
• Action (Add, Change, Delete)
• Action Time
• Changed Attributes
• Old Host Name (Present only if Host Name changed)
• New Host Name (Present only if Host Name changed)
• Old Property Value (Present only if Value changed)
• New Property Value (Present only if Value changed)
• Comment (As entered during update on Architecture
Properties Maintenance page)
 The conditional presence of old and new Host Name and Property
Value applies only when Action is "Change". In case of "Add"
action, the old values are empty and new values are the newly
created property values. In case of "Delete" action, the old values
are the values that existed prior to deletion, and new values are
empty.
 Click OK to dismiss Architecture Property Change and return to
the Architecture Properties History page.

o RETURN
 It always remains enabled.
 This button can be used to move back to Architecture Properties
Maintenance page.
• All the filter values are optional in nature. The functionalities associated with
filters are as follows –
o Property
 This parameter is associated with PROPERTY_NAME column of
ARCH_PROPERTY database table.
 It fetches unique list of all the property names whose update
history exists.
o Host
 This parameter is associated with HOST_NAME column of
ARCH_PROPERTY database table.
 It fetched unique list of all the host names whose update history
exists.
o Action
 The drop-down consists of four different values and the data will
be filtered according to the selection –
• All
• Add
• Change
• Delete
o Date Range

It’s the combination of From and To Date.

Both From and To Dates are inclusive in nature. For e.g., a ‘From’
value of 02/01/2014 and ‘To’ value of 02/05/2014 will yield
history for date range Feb 1st to Feb 5th, both inclusive.
 Either or both the data parameters are optional in nature.
 When both ‘From’ and ‘To’ dates are specified, From Date must
be less than or equal to To Date.
o Screen after fetching data looks like this –

2 Application Configuration
2.1 BOOTSTRAP
A file named Apollo.startup.properties positioned in the application server’s “current
working directory”
WebLogic: This is the top of the domain directory tree (where startWeblogic.sh is
located).
WebSphere: This is the top of the profile directory tree (such as
%WAS_HOME%\AppServer\profiles\AppSrv01\).
This file must contain the following lines, modified with appropriate database
connection. DatabaseSchemaBase/DatabaseNameBase is the name of the main Enterprise
DA database (and is the root of the associated _MD and _EMS databases). The password
can be entered in clear text, but will be encrypted and overwritten when the application is
started.
Oracle RDBMS:
DatabaseType=oracle
DatabaseAddress=10.20.30.40:4100:oracleSID
DatabaseSchemaBase=ENT_XXX
DatabaseUserName=ioenterprise
DatabaseUserPassword=password
Sybase RDBMS:
DatabaseAddress=10.20.30.40:4100
DatabaseNameBase=ENT_XXX
DatabaseUserName=ioenterprise
DatabaseUserPassword=password
2.2 ARCHITECTURE TABLES

Application-wide configuration is generally stored in the database table
ENT_XXX.ARCH_PROPERTY. This table is in the main Enterprise database and
contains a set of named properties and values that indicate current property settings
used by the application. These are stored in the PROPERTY_NAME and VALUE
columns, respectively.
To allow for per-machine configuration, the database table also includes a

HOST_NAME column that can be used to indicate the scope of the settings. The
column may be set with “*” to indicate that a setting applies to all connected hosts,
or may be set with a specific hostname, which must match exactly the name
including the case, the result of invoking the operating system’s “hostname”
command on that host.

• Some property settings are pre-populated by the database scripts. These may
be left as they are or updated with environment-specific values.
• Some property settings are not pre-populated and the application uses basic
defaults for these. Optionally, these default values can be overridden by
inserting database rows for these properties.
• Property settings may be set or changed at any time, but many of them require
an application restart before they become effective.
PROPERTY
_TYP PROPERTY_NAME VALUE DSCRPTN
A numeric value that specifies how many backup files are kept before the
LOGGER Logger.MaxBackUpIndex 10 oldest log file is erased
The absolute or relative file system directory path under which "logs"
directory (containing log files) will be found (where "." indicates the
LOGGER Logger.LogFile.Path . application server's "working directory")
Specifies the maximum file size that the log file is allowed to take up on
disk. Values are integers followed by one of the following suffixes "KB",
LOGGER Logger.MaxFileSize 10MB "MB" or "GB"
Base path for Reporting Toolkit Template files. This location must be a
shared drive, accessible by the same path to all servers in multi-server
CONFIG BasePath /opt/CustEnvs installation
CONFIG AccountUpdateService:Sleep 5000 Sleep period for AccountUpdateService; Default is 5000 milliseconds
INSTALL Base.ApolloFiles CoEx server Specific location of the ApolloFiles directory
/ExceptionEngin
e/ExceptionReq
INSTALL EMS.apppath uest EMS app server request path (for the C++ EMS only)
INSTALL EMS.appserver EMS app server IP (for the C++ EMS only)
Default
INSTALL EMS.reopenComment Comment EMS default re-open comment
INSTALL EMS.reopenOnRerun 1 EMS reopen on rerun flag
RunAsExecuteR
INSTALL Enterprise.reportServiceID eportService Reporting service ID
ei81MDJ1R3BCZ
kU9:WlFpQ0VFd
DlPWlU9:WlFpQ
INSTALL Enterprise.reportUserPassKey 0VFdDlPWlU9 Reporting UserPassKey
{Base.ApolloFile
s}\ReportPkg\P Indicates the path where client-specific PDF input images are to be
CONFIG PDF.ClientPath DFIn%ub generated.
The pattern used to create a user-friendly PDF filename for client use;
'%tn' - Task Name; '%rd' - Run Date; '%an' - Account Number; '%ad% -
%tn (%rd) Account Description; '%aq' - Account Query; '%pn' - Process Name; '%pl'
CONFIG PDF.ClientTemplate [%an]%aq %pn - Pick List Group; '%ri' - Report ID; '%ub' - User/Bank
CONFIG PDF.Printer The system printer to be used to generate PDF input images.
BinderTemplate
s/BinderHeader. This template is used to generate the header for a Binder when it is in
CONFIG Binders.HeaderAcctTmpl prn Account Order format.
{Base.ApolloFile
CONFIG Binders.GeneralPath s}\Binders Indicates the path where general Binder images (.ps) are to be located.
CONFIG Binders.OffSitePrinter The printer used to create the report images for the 3rd Party printer.
Flags whether/not to delete via FTP command any files left over from the
Hybrids process; These files are from the Engine output as well as the
Hybrid Hybrid.DeleteFTPFiles TRUE Enterprise parsing output.

INSTALL MFP.ioSweepFlag N MFP IOSweep Flag

c:\\inetpub\\w
INSTALL ApolloBase.virtualDir wwroot No longer used
Indicates whether an account should be excluded from a Binder in the
event of an error: 'true' - Allows Binder to be generated; 'false' - Causes
CONFIG Binders.AutoSkipAccountOnError TRUE Binder to fail.
CONFIG SsoUserValidationResolver webservice The type of resolver for User validation resolving.
When to log the HTTP request headers.
CONFIG HeaderLoggingLevel Never (Never/SsoLicensedOnly/EveryRequest)
The amount of time in milliseconds to wait before checking for
CONFIG CPS.StatusCheckWaitTime 300000 connections that need to be (re)started; e.g. 300000 is 5 minutes.
Enter the user name needed for authentication with the queue manager;
CONFIG CPS.Connection1.User a value of " " (a single space) will use no authentication.
Enter the password needed for authentication with the queue manager;
CONFIG CPS.Connection1.Password a value of " " (a single space) will use no authentication.
CONFIG CPS.Connection1.HostName Undefined Enter the HostName (or IP) where the WebSphere MQ Manager resides.
CONFIG CPS.Connection1.Port 1414 Enter the Port on which WebSphere MQ listens.
CONFIG CPS.Connection1.QueueManager Undefined Enter the name of the QueueManager on the remote system.
CONFIG CPS.Connection1.Queue Undefined Enter the name of the Queue on the remote system.
Enter the number of listeners that will retrieve messages from the queue
CONFIG CPS.Connection1.ListenCount 4 simultaneously.
CONFIG InvestOneOrchestrator:Sleep 5000 Sleep period for InvestOneOrchestrator; Default is 5000 milliseconds
InvestOneServices.SpectraFundTra
CONFIG nID FDA2 The Engine Transaction ID that is to be used for 'Spectra Fund Requests'.
InvestOneServices.SpectraDistribut The Engine Transaction ID that is to be used for 'Spectra Distribution
CONFIG ionTranID FDA0 Requests'.
InvestOneServices.SpectraTransact The Engine Transaction ID that is to be used for 'Spectra Transaction
CONFIG ionTranID FDA1 Requests'.
InvestOneServices.SpectraPending The Engine Transaction ID that is to be used for 'Spectra Pending
CONFIG TransactionTranID FDA1 Transaction Requests'.
The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG InvestOneServices.SweepTranID FDA5 'Sweep'.
InvestOneServices.MoveBalanceDa The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG teTranID FDA6 'Move Balance Date'.
InvestOneServices.MoveVerificatio The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG nDateTranID FDA6 'Move Verification Date'.
InvestOneServices.PriceSweepTran The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG ID FDA7 'Price Sweep'.
InvestOneServices.SecurityPriceEdi The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG tTranID FDA8 'Security Price Edits'.
InvestOneServices.AlternatePricing The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG TranID FDA9 'Alternate Pricing'.
InvestOneServices.PoolAllocationT The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG ranID FUND 'Pool Allocation'.
InvestOneServices.AlternateLockU The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG pdateTranID FUND 'Alternate Lock Update'.
AdhocReportExecutorPoolManage
CONFIG r.managerThreadSize 4 Size of the Manager Threads
AdhocReportExecutorPoolManage
CONFIG r.jobQueueSleepTime 4 Max wait time to place a job
AdhocReportExecutorManagerThr
CONFIG ead.threadPoolSize 3 Size of the report execution threads
AdhocReportExecutorManagerThr
CONFIG ead.maxSleepTimeInSec 2 Sleep time of the manager thread
Indicates which PDF output types to generate: 'C' = Client; 'G' = General;
CONFIG PDF.OutputTypes 'B' = Both; or 'N' = None.

BinderTemplate
s/BinderTrailer. This template is used to generate the trailer for a Binder when it is in
CONFIG Binders.TrailerAcctTmpl prn Account Order format.
BinderTemplate
s/Xerox EPS 180 This file is used to generate forms and duplexing information to a Xerox
CONFIG Binders.JobTicketFile Job Ticket.xpf EPS 180 Offsite printer.
{Base.ApolloFile
s}\ReportPkg\P
CONFIG PDF.GeneralPath DFIn Indicates the path where general PDF input images are to be generated.
BinderTemplate
s/SkippedAccou This template is used to report; within a binder; that the specified
CONFIG Binders.SkippedTemplate ntTemplate.prn account has been skipped and not included.
Indicates whether Excel should save workbooks with embedded graphs
CONFIG Reports.SaveExcelGraphFormat97 in Excel 97 format; '1' - True; '0' - False
BinderTemplate
s/BinderHeader This template is used to generate the header for a Binder when it is in
CONFIG Binders.HeaderRptTmpl ByReport.prn Report Order format.
BinderTemplate
s/BinderTrailerB This template is used to generate the trailer for a Binder when it is in
CONFIG Binders.TrailerRptTmpl yReport.prn Report Order format.
BinderTemplate This template is used to generate a blank page within a Binder; such as
CONFIG Binders.BlankPageTmpl s/BlankPage.prn the backside of an odd-numbered page in duplex mode.
Indicates whether PDF images are stored in unique folders for Reports
CONFIG PDF.SplitFolders FALSE Packages and Binders; true or false.
CONFIG ProcessServer.RetryCount 5 Indicates the number of times Process Server will retry a retriable event.
Indicates the amount of time; in milliseconds; Process Server will wait
CONFIG ProcessServer.RetryDelay 1000 before retrying an event.
CONFIG Binders.OffSitePath The path where Binder images are placed for the OffSite Printer.
CONFIG Scheduler.MaxThreads 5 Scheduler process worker thread count
CONFIG Scheduler.RerunTime 60000 Scheduler time gap between two successive executions(in ms)
CONFIG ExpenseCalc.AccountThreads 8 Thread pool size for executing Accounts.
ExpenseCalc.FutureResultPollTime
CONFIG outMs 3600000 Timeout for polling Future task results from the CompletionService.
InvestOneServices.NotionalDealing The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG RatesTranID FD0A 'Notional Dealing Rates'.
CONFIG CPSArchive.Purge.Timeout 1800 For CPS Archve Purge Process; the Transaction Timeout Period
For CPS Archve Purge Process; the Decrement period (in months) that
CONFIG CPSArchive.Purge.Decrement 1 should be applied for Retention
For CPS Archive Purge Process; the Maximum times the Decrement
CPSArchive.Purge.MaxRetentionD period should be applied in order to completely purge records for given
CONFIG ecrementAttempts 24 customer
CPSArchive.Purge.MaxPurgeAttem For CPS Archive Purge Process; the Maximum times the purge process
CONFIG pts 2 should be run in order to completely purge records for given customer
EMSCycleNotification.MessageRetr
INSTALL yWorkerCount 2 EMS Message Retry Worker Count
Connection detail for MQ manager in the format:
CONFIG MQManager:ConnectionDetail MQ_Manager_Name:IP_Address:Port
MQManager:MsgProcessingWorke The maximum number of threads available for processing all MQ
CONFIG rCount 10 messages from all queues across all MQ managers.
CONFIG MQManager:ChannelName NA Channel Name for connecting to MQ manager.
CONFIG MQManager:Password NA Password for connecting to MQ manager.
CONFIG MQManager:UserName NA UserName for connecting to MQ manager.
InvestOneServices.AccountAllocati The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG onTranID FUND 'Account Allocation'.
EMSCycleNotification.EventCreato
INSTALL rCount 4 EMS Event Creator Thread Count
CONFIG ProcessManager.enableLogicalDel 0 Logical delete indicator

ete
IP Address of the host designated for PDF Conversions. Change it to
CONFIG PDFConverter.Host 127.0.0.1 appropriate value after DocConverter ENTERPRISE installation
PDF Converter port designated for PDF Conversions. Default 54546
CONFIG PDFConverter.Port 54546 should be sufficient for most installations
Encryption check flag to kick off processing that encrypts passwords in
CONFIG EncryptionCheck Pending tables with clear-text passwords
DSN=sungardim
EnterpriseExcelExecutor.Database s.net;SRVR=sung Used to map the legacy database ODBC DSN name to database server
CONFIG DsnPrefix ardims.net name of the main database, now only used for EMS reports and EMS
DSN=sungardim
EnterpriseExcelExecutor.EMSData s.net;SRVR=sung Used to map the legacy database ODBC DSN name to database server
CONFIG baseDsnPrefix ardims.net name of the EMS database, now only used for EMS reports and EMS
EnterpriseExcelExecutor.TcpAddre sungardims.net:
CONFIG ss 7007 Excel Executor IP address
No. of days to retain the M2MG messages on various M2MG related
CONFIG M2MG.RetainDays 7 tables.
CONFIG Authorization.excludeUrlList logon.do,.css.do Comma separated list of URLs to be excluded from authorization check
/data/transient/
CONFIG DataExtract.Output.FilePath dataextract/ Data Extract shared path
Maximum timeout period for scheduler. Files older as determined by this
CONFIG DataExtract.Purge.Timeout property would be deleted.
The password to be used for authentication with the Engine Reports ftp
CONFIG EngineReports.FTPPassword discouraged.
Indicator of whether Engine Report processing is enabled. This is the
processing that occurs when the Engine FTPs a report output to the FTP
site and Enterprise polls for it. Defaults to true. Set it to false to disable
Engine Reports processing on a server (for instance, if it is desired to
dedicate a machine for other purposes). Changes to this require a server
CONFIG EngineReports.FtpPollerEnabled TRUE restart.
CONFIG EngineReports.FTPPort The port to be used by the engine to FTP the report back to Enterprise.
The user name to be used for authentication with the Engine Reports ftp
server within Enterprise (case sensitive). A blank user name is highly
CONFIG EngineReports.FTPUser apolloftp discouraged.
{Base.ApolloFile Indicates the path where Enterprise will 'store' Engine reports from the
CONFIG EngineReports.GeneralPath s}\EngineRpts engine.
{Base.ApolloFile Indicates the path where Enterprise will 'store' GLExtract reports from
CONFIG EngineReports.GLExtractPath s}\EngineRpts the engine.
The user name to be used for authentication with the Engine Reports ftp
server within Enterprise (case sensitive). A blank user name is highly
CONFIG EngineReports.Server discouraged.
The password to be used for authentication with the Engine Reports sftp
CONFIG EngineReports.SFTPPassword discouraged.
The Host (IP Address) of the SFTP Server. Leaving it blank is highly
CONFIG EngineReports.SFTPServer discouraged as reports will not be transferred to the Enterprise.
The user name to be used for authentication with the Engine Reports
sftp server within Enterprise (case sensitive). A blank user name is highly
CONFIG EngineReports.SFTPUser discouraged.
CONFIG EngineReports.UseSFTP Flag to indicate Report Transfer using FTP/SFTP
Enterprise.NewUISupportedBrows msie 9, msie 10,
CONFIG ers msie 11 List of Supported Browsers
CONFIG FV.NumberOfAccountsPosting 10 Number of worker threads for posting accounts
CONFIG FV.NumberOfTransPosting 10 Number of worker threads for posting transactions per account
InvestOneServices.MoveBackLock The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG DateTranID FDA6 'Move Back Lock Date'.

InvestOneServices.MoveBackVerifi The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG cationDateTranID FDA6 'Move Back Verification Date'.
InvestOneServices.MoveForwardL The Engine Transaction ID that is to be used for the InvestOne Service
CONFIG ockDateTranID FDA6 'Move Forward Lock Date'.
RTK.API.MaxConcurrentExecutionC
CONFIG apacity 10 Maximum Concurrent Report Executions
ExpenseCalc.AccountSweepThread This property can be used to override the default thread count of 12 for
CONFIG s sweeping the accounts. This is only for ReportingWithTrustFee account.
INSTALL Indicates the current update level to the Enterprise Engine Reports
EngineReports.CurrentUpdate module.
INSTALL Indicates the current version number to the Enterprise Engine Reports
EngineReports.CurrentVersion module.
INSTALL InternalConfig.CpsEerDateValidati
onEnabled TRUE Enable Date Validation while adding a new CPS EERule
CONFIG ProcessManager.SubmissionWork The number of ProcessManager Submission Workers that are
erCount configured.
CONFIG EngineReports.PollingFtpServerThr The number of threads to handle file processing when using and polling
eadCount from an external FTP server.
CONFIG HybridReports.PollingFtpServerThr The number of threads to handle file processing when using and polling
eadCount from an external FTP server.
CONFIG EngineReports.PollingFtpServerInt The number of seconds to sleep when between polls, when polling from
ervalSeconds an external FTP server, when there are no files found.
CONFIG Flag to delete the Engine report files (downloaded to the working store)
EngineReports.DeleteFTPFiles TRUE after processing.
CONFIG InvestOneServices.SecurityPriceEdi The Transaction ID that is to be used for a Security Price Edit request via
tTranID FDA8 the InvestOneServices interface.
CONFIG Scheduler.Enabled TRUE Indicates whether or not the Scheduler is enabled.
CONFIG IooleArchMessages.FDSD Architecture message for the Security message.
CONFIG IooleArchMessages.FDTS Architecture message for the Transaction message.
CONFIG Indicates whether data validation is enabled when loading Expense Calc
ExpenseCalc.IoDataValidation 1 data in the database.
CONFIG ExpenseCalc.SingleTranUpdate No need to document as setting this to 0 results in error.
CONFIG Process limits for Report Distribution in the format
T[IME]=m;C[OUNT]=c; Where m is the number of milliseconds to allow
for overall processing time and c is the number of items to process. For
ReportDistribution.Limits t=-1;c=300000 example t=100;c=500 or T=-1;C=-1.
CONFIG Username for instance level authentication (Optional). If the optionally
configured username and password are set, then the database username
Authentication.InstanceUsername and password will not be accepted.
CONFIG Password for instance level authentication (Optional). If the optionally
configured username and password are set, then the database username
Authentication.InstancePassword and password will not be accepted.
CONFIG EnterpriseReports.DbHandleRetry Maximum number of retries when getting the Database handle when
Count 10 processing RTK reports.
CONFIG AdhocReportExecutorManagerThr
ead.jobTimeOutInMins 60 Set the max time in minutes to process an Adhoc report job.
CONFIG ProcessManager.PrioritizationMod
e TRUE Enables prioritization of processes if set to "true".
CONFIG The realm name to be used in the Digest challenge sent for REST services
Digest.Realm InvestOne authentication.
CONFIG The Nonce validity period (in seconds) for Digest Access Authentication
Digest.NonceValidityPeriod 300 for REST services.
CONFIG The key to be used for generating the nonce for Digest Access
Digest.NonceKey NonceKey Authentication.
CONFIG RTK.showRTKFileOutputType TRUE Enables the "File" output type when running RTK reports if set to "true".
CONFIG Number of worker threads that will be used for handling process
PM.SubmissionListener.Workers 3 manager submission listeners. A server restart is required to take the

new value into effect.

CONFIG CustMigration.Delete.BatchSize 100 The Batch size to be used for deleting records when deleting a customer.
CONFIG The Batch size to be used for inserting records when importing a
CustMigration.Import.BatchSize 100 customer.
The following configurations are defaulted in the application. To override the default values these
configurations need to be added to the Arch_Properties table
A comma-separated list of components for which debug-level logging in

LOGGER Logger.Categories.debug enabled. This level is used for problem diagnostics
A comma-separated list of components for which trace-level logging in
LOGGER Logger.Categories.trace enabled. This level is excessively verbose and generally not used
Indicator of whether or not the application will expose content through
JMX. Absence of this property means the application defaults to ‘true’.
CONFIG Management.JmxEnabled To turn off this property a row would be inserted to set to ‘false’
Indicator of whether or not, in support of JMX, whether the
ProcessManager tables should be queried. Absence of this property
Management.ProcessExecutorData means the application defaults to ‘true’. To turn off this property a row
CONFIG baseQueryingEnabled would be inserted to set to ‘false’
The number of connections that will be established when the database
CONFIG MercuryDataSource.InitialSize 15 connection pool is started
The maximum number of connections that should be kept in the idle
CONFIG MercuryDataSource.MaxIdle 80 pool
The minimum number of established connections that should be kept in
CONFIG MercuryDataSource.MinIdle 15 the pool at all times
The maximum number of active connections that can be allocated from
CONFIG MercuryDataSource.MaxActive 200 this pool at the same time
MercuryMetadataDataSource.Initi The number of connections that will be established when the database
CONFIG alSize 15 connection pool is started
MercuryMetadataDataSource.Max The maximum number of connections that should be kept in the idle
CONFIG Idle 15 pool
MercuryMetadataDataSource.MinI The minimum number of established connections that should be kept in
CONFIG dle 2 the pool at all times
MercuryMetadataDataSource.Max The maximum number of active connections that can be allocated from
CONFIG Active 15 this pool at the same time
The connection time out parameter to be set for all EMS Engine’s
CONFIG EMS.IoConnectionTimeOutMillis 15000 socket.connect API call to InvestOne core. The default is 15 seconds.
CONFIG EMSDataSource.InitialSize 15 connection pool is started
CONFIG EMSDataSource.MaxIdle 15 pool
CONFIG EMSDataSource.MinIdle 2 the pool at all times
CONFIG EMSDataSource.MaxActive 60 this pool at the same time
CONFIG MFPDataSource.InitialSize 0 connection pool is started
CONFIG MFPDataSource.MaxIdle 10 pool
CONFIG MFPDataSource.MinIdle 0 the pool at all times
CONFIG MFPDataSource.MaxActive 30 this pool at the same time
CONFIG ExpenseCalcDataSource.InitialSize 0 connection pool is started
CONFIG ExpenseCalcDataSource.MaxIdle 10 pool


CONFIG ExpenseCalcDataSource.MinIdle 0 the pool at all times
CONFIG ExpenseCalcDataSource.MaxActive 30 this pool at the same time
CONFIG XaminDataSource.InitialSize 0 connection pool is started
CONFIG XaminDataSource.MaxIdle 10 pool
CONFIG XaminDataSource.MinIdle 0 the pool at all times
CONFIG XaminDataSource.MaxActive 30 this pool at the same time
When true, Enterprise will use the 13.1 version of the XSS Filter. When
CONFIG XSSFilter.revertFilterVersion False false, the updated XSS Filter will be used
2.3 EXCEL EXECUTOR XML FILE

• LogLevel parameter – application default is “Warn”.
• ReportPkgSaveTimeoutSeconds parameter – Time out for report package save
operation. After this time the package save attempt is aborted. Application
default is 15
• IgnoreXIPrecisionAddin parameter – application default is “N”
• TransferBufferSize parameter – Buffer size for reading file input streams from
Enterprise. Application default is 64 * 1024
• ExcelMaxAgeMins parameter – to enable Excel instances that are running
• MutexLockRequiredForBrowserReports parameter – to disable mutex clipboard
locking
• MutexLockWaitMins parameter – application default is 5
• ConvertCharacterDate parameter – application default is 1. Addition of
parameter to XML file and setting value to 0 will change the parameter to be a
character string as opposed to a date.
• To enable the ExcelExecutor comlog, modify the EnterpriseExcelExecutor.xml to

insert the EnableComLog parameter then restart the EE service:
<Parameter Name="EnableComLog" Value="TRUE" />
The parameter will create a sub-folder named “comlogs” under the EE folder of the
coex server. Under there, SQL calls made by browser reports to the database (via
EE dataservices execution, such as for IMpower.DataServices and/or
EmsRd.DataServices) are logged to a file that is specific to the report’s unique
session id.
3 Application Logging
The Enterprise application implements the Apache log4j for logging and allows for
various levels of logging.
Log levels are: TRACE, DEBUG, INFO, WARN, ERROR and FATAL.

The application logs all INFO, WARN, ERROR and FATAL transactions by default.
Administrators can modify the log level to DEBUG or TRACE. Please note that
logging at TRACE level is extremely verbose and should be avoided.
Log levels can be modified at runtime without requiring an application restart. To
modify the log level do the following:
In the Main database, check for the current logging using:
select * from ARCH_PROPERTY where PROPERTY_TYP='Logger'
If ‘Logger.Categories.debug' is not present, insert it with:

INSERT INTO ARCH_PROPERTY ( PROPERTY_TYP, PRODUCT_NAME, CLIENT_NAME,
PROPERTY_NAME, HOST_NAME, VALUE, DSCRPTN, CREATE_LOGIN, CREATE_HOST,
CREATE_DATE, SUPERSEDED_LOGIN, SUPERSEDED_HOST, SUPERSEDED_DATE )
VALUES ( 'Logger', 'Enterprise', '*', 'Logger.Categories.debug', '*',
'com.sungard.sims', '', 'debug', 'debug', '03/19/2009', NULL, NULL, NULL )
If it is already present, update it with these values instead of inserting it.
This enables “full” debugging. Logging can be focused by replacing

'com.sungard.sims' with specific package names. Valid package names are:

Sub Package Name to be included in ARCH_PROPERTY table for

Module
Module logging
Account Reload com.sungard.sims.mercury.accountreload
Account Views com.sungard.sims.mercury.accountviews
Account Grouping com.sungard.sims.mercury.acctgrouping
Adapter XAMIN com.sungard.sims.mercury.delivery.filter.XaminAdapter
com.sungard.sims.mercury.delivery.presentation.struts.action.Xami
Adapter CallBack XAMIN
nCallbackAction
Administration com.sungard.sims.mercury.administration
Apollo Web com.sungard.sims.mercury.apolloweb
Australian Gaap com.sungard.sims.mercury.australiangaap
Franking Credits com.sungard.sims.mercury.australiangaap.frankingcredits
Tofa com.sungard.sims.mercury.australiangaap.tofa
Australian Tax Rates com.sungard.sims.mercury.australiantaxrates
Auto Distribution com.sungard.sims.mercury.autodistribution
Broker com.sungard.sims.mercury.broker
Bulk User Upload com.sungard.sims.mercury.bulkprocesses
CPS com.sungard.sims.mercury.centralpricing
JOLE (All Engine
com.sungard.sims.mercury.common.jole
requests)
Database (All Database
com.sungard.sims.mercury.common.DataSourceLogging
queries)
CSA com.sungard.sims.mercury.csa
CUI com.sungard.sims.mercury.cui
Customer com.sungard.sims.mercury.customer
Dilution Divergence com.sungard.sims.mercury.dilutiondivergence
Dual Pricing com.sungard.sims.mercury.dualpricing
Dynamic Desktop com.sungard.sims.mercury.dynamicdesktop
EMS com.sungard.sims.mercury.ems
EMS Cycle Completion com.sungard.sims.mercury.emscyclecompletion
EMS RD com.sungard.sims.mercury.emsrd
Engine Reports com.sungard.sims.mercury.enginereports
Engine Screens com.sungard.sims.mercury.enginescreen
EUSD com.sungard.sims.mercury.eusd.runtime.service.processor
Browser Reports com.sungard.sims.mercury.excel
Expense Cal com.sungard.sims.mercury.expensecalc
Future Date Cash com.sungard.sims.mercury.futuredatedcash
GLE Extract com.sungard.sims.mercury.glextract
IM Power com.sungard.sims.mercury.impower

Sub Package Name to be included in ARCH_PROPERTY table for

Module
Module logging
IntraDay com.sungard.sims.mercury.intraday
InvestOne Services com.sungard.sims.mercury.investoneservices
IO Ole com.sungard.sims.mercury.ioole
Loans com.sungard.sims.mercury.loans
MFC com.sungard.sims.mercury.mgmtfeeproc
Mil Rates com.sungard.sims.mercury.milrates
MV GAAP com.sungard.sims.mercury.mvgaap
Report Distribution com.sungard.sims.mercury.outputdistribution
Performance com.sungard.sims.mercury.performance
Performance Fees com.sungard.sims.mercury.performancefees
Process manager com.sungard.sims.mercury.processmanager
Process UserBank
com.sungard.sims.mercury.processuserbankassociation
Association
Profile manager com.sungard.sims.mercury.profilemanager
Regulatory com.sungard.sims.mercury.regulatory
Related Securities com.sungard.sims.mercury.relatedsecurities
RTK & Hybrid Reports com.sungard.sims.mercury.report
Report packaging com.sungard.sims.mercury.reportpackaging
RTK & Adhoc com.sungard.sims.mercury.rtk
Scheduler com.sungard.sims.mercury.scheduler
Security com.sungard.sims.mercury.security
Spectra com.sungard.sims.mercury.spectra
SSO com.sungard.sims.mercury.sso.service.processor
Tax Lot Tag com.sungard.sims.mercury.taxlotTag
Trial Balance
com.sungard.sims.mercury.trialbalancecomparison
Comparison
Trust Distribution com.sungard.sims.mercury.trustdistribution
User com.sungard.sims.mercury.user
Misc Utilities com.sungard.sims.mercury.util (Miscellaneous Utilities)
Web Service com.sungard.sims.mercury.webservice
3.1 ROLLING LOGS, FILE SYSTEM USAGE/IMPACT, BEST PRACTICES
3.2 MERCURY LOG (PENDING)
3.3 EXCEL EXECUTOR LOG (PENDING)
3.4 IOEXCELREPORT LOG

To enable debugging:
1. Regedit→Hkey Local Machine→Software→Sungard→Apollo Browser Reports

2. set ioExcelReportDebug = 0 (off), 1, 2, 3, or 4 (higher number produces

more detail)
Log file: <EnterpriseExcelExectutor path>\ioExcelReport<1234>.txt
3.5 ACCESS LOG (PENDING)
3.6 APPLICATION SERVER LOG (PENDING)
3.7 OPERATING SYSTEM LOG (PENDING)
3.8 MULTI-SERVER ENVIRONMENT (PENDING)

4 Single Sign-On (PENDING)

5 WebServices (PENDING)

6 Data Extracts (PENDING)

7 Ole (PENDING)
7.1 COM OLE (PENDING)
7.2 JAVA JOLE (PENDING)
7.3 SERVER OLE (PENDING)
7.4 DESKTOP OLE (PENDING)
8 Appserver Specific Configuration/Tuning (PENDING)
8.1 WEBLOGIC
8.1.1 Stuck Thread Analysis

Web article describing stuck threads
http://www.munzandmore.com/2012/ora/weblogic-stuck-threads-howto
• When a java thread is STUCK, it is not necessarily a problem, and it may be

normal processing for a comparatively long-running process or request.
• A STUCK Thread condition occurs when a java process remains stationary for a
pre-configured time interval (often 600 seconds by default). Given the fact that
there are several Enterprise processes that are known to run longer than 600
seconds, the STUCK thread condition may be seen when these long-running
processes are running.
• Thread dumps represent point-in-time views of the java threads. The thread
dump file may not actually include the date-time-stamp, so when including
thread dump files within problem tickets, it is a good idea to also provide the
date-time when the thread dump was produced. This will aid in correlating the
information in the thread dump with other log files that do include the date-time.
• When reviewing a thread dump, STUCK thread(s) are easily identifiable by
searching for the text “[STUCK]”, which denotes the start of the STUCK thread
information. Immediately following this identifier is a java stack trace.
Excel Executor Example

"[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'"
RUNNABLE native java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
java.io.BufferedInputStream.read(BufferedInputStream.java:317)
weblogic.net.http.MessageHeader.isHTTP(MessageHeader.java:224)
weblogic.net.http.MessageHeader.parseHeader(MessageHeader.java:148)
weblogic.net.http.HttpClient.parseHTTP(HttpClient.java:468)
weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:377)
weblogic.net.http.SOAPHttpURLConnection.getInputStream(SOAPHttpURLConnection
.java:37

com.sungard.sims.mercury.excel.components.ExcelClient.receiveBrowserReportResp
onse(ExcelClient.java:2092)
com.sungard.sims.mercury.excel.components.ExcelClient.singleSheetStream(ExcelCli
ent.java:307)
com.sungard.sims.mercury.excel.components.CRequest.GetReport(CRequest.java:13
4)
com.sungard.sims.mercury.excel.service.ReptblobService.invoke(ReptblobService.jav
a:57)
com.sungard.sims.mercury.excel.service.ReptblobService.execute(ReptblobService.j
ava:36)
• In the example above, the thread is stuck inside receiveBrowser
ReportResponse() method, at line 2092 of the ExcelClient.java class.
• FURTHER DIAGNOSIS OF THIS SPECIFIC EXAMPLE WOULD REQUIRE LOCATING AND

TRACKING THE SPECIFIC REQUEST WITHIN ENTERPRISE AND EXCELEXECUTOR (USING
LOGS), AND CONFIRMING THE ‘HEALTH AND WELFARE’ OF THE COEX SERVER
ENVIRONMENT.
Process Monitor Example
"[STUCK] ExecuteThread: '65' for queue: 'weblogic.kernel.Default (self-

tuning)'" RUNNABLE
java.util.Arrays.copyOf(Arrays.java:2882)
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:10
0)
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
java.lang.StringBuilder.append(StringBuilder.java:119)
com.sungard.sims.mercury.processmanager.service.IoProcMonProcService$In
nerOperation.setupGridData(IoProcMonProcService.java:813
nerOperation.invoke(IoProcMonProcService.java:579)
nerOperation.access$100(IoProcMonProcService.java:91)
com.sungard.sims.mercury.processmanager.service.IoProcMonProcService.ex
ecute(IoProcMonProcService.java:88)com.sungard.sims.mercury.delivery.pres
entation.struts.action.MercuryMappingDispatchAction.callService(MercuryMap
pingDispatchAction.java:1430)
com.sungard.sims.mercury.action.ProcessManagerAction.invokeIoProcMonProc(Proce
ssManagerAction.java:322)
• In this example, the thread is stuck in the setupGridData() method of the

IoProcMonProcService.java class (line 813).
• This method is responsible for building a string object with the process data to be
displayed on the Process Monitor screen; in some cases this string object can become
very large (e.g. if there are many processes to be displayed). The logic is stuck at a
point where it is attempting to append more data to the string.
• The problem appears to be caused by some type of memory allocation problem within
the java string handling classes.

• Due to the usage patterns for this screen, it is possible that several threads may be
stuck at this same point in the Process Monitor screen.
• The issue may be resolved by freeing memory using the application server ‘Garbage
Collection’ facility.
• If this does not work, then the Enterprise instance will need to be restarted.
8.2 WEBSPHERE (PENDING)
8.3 TCSERVER (PENDING)
8.4 TOMCAT (PENDING)

APPENDIX
DATABASE SCHEMA DIAGRAM GUIDE
Please refer to Database Schema Diagram Guide for details.

INDEX
Administrators Guide, 95 io_ERREPORTVIEWER, 53
Basic Overview of InvestOne Enterprise, what is dynamic desktop, 89
7, 8

AdminGuideEDA13 0

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

AdminGuideEDA13 0

Hochgeladen von

Copyright:

Verfügbare Formate

For Global

ASSET ARENA INVESTONE Asset Managers

June 30, 2015

United States United Kingdom

Email Client Services: AAIA.CSC.NA@sungard.com  General Info: www.sungard.com/financialsystems.aspx

Date of Revision Revisions

ADMINISTRATION GUIDE 13.0 ENTERPRISE DISTRIBUTED ARCHITECTURE

This document contains SunGard's confidential or proprietary information. By accepting this

ADMINISTRATION GUIDE 13.0 ENTERPRISE DISTRIBUTED ARCHITECTURE

This guide provides information for Administrators to be able to configure and

WHO SHOULD READ THIS GUIDE?

WHAT’S COVERED IN THIS GUIDE?

ENTERPRISE DISTRIBUTED ARCHITECTURE 13.0 ADMINISTRATION GUIDE

OTHER SOURCES OF INFORMATION

Your Asset Arena Investment Accounting Distributed Architecture software includes

Refer to this Document: Purpose of Document:

Asset Arena Investment Accounting The purpose of this document is to describe

Enterprise Distributed Architecture – This document details the Investment

ADMINISTRATION GUIDE 13.0 ENTERPRISE DISTRIBUTED ARCHITECTURE

CONTACTING CUSTOMER SUPPORT

The following are types of NOTATION CONVENTIONS used in this guide:

ENTERPRISE DISTRIBUTED ARCHITECTURE 13.0 ADMINISTRATION GUIDE

ADMINISTRATION GUIDE 13.0 ENTERPRISE DISTRIBUTED ARCHITECTURE

1.1 SYSTEM REQUIREMENTS

1.2 ENTERPRISE TECHNOLOGIES (PENDING)

This file must contain the following on one line:

1.4 PASSWORDS (PENDING)

1.5 BRANDING (PENDING)

1.6 PRINTERS (PENDING)

1.7 MEMORY SETTINGS (PENDING)

1.8 SERVER STARTUP SETTINGS (PENDING)

1.9 ENTERPRISE COMPONENTS (PENDING)

1.9.1 Ear file (Pending)

1.9.2 Excel Executor (Pending)

1.9.3 FTP (Pending)

1.9.4 ActivePDF (Pending)

1.9.5 IBM MQ (Pending)

1.10 ENTERPRISE MODULES

1.10.1 Process Manager

ENTERPRISE DISTRIBUTED ARCHITECTURE 13.0 ADMINISTRATION GUIDE

Process Manager is a set of components responsible for the submission, execution,

Unit of work for Process Manager is a Process. A Process is a collection of one or

A Process Server is the Process execution engine of Process Manager. A single

ADMINISTRATION GUIDE 13.0 ENTERPRISE DISTRIBUTED ARCHITECTURE

Irrespective of whether a Process is executed by a general-purpose Process Server or

• Process Server configuration user-interface

Whereas Process Servers in earlier releases are configured with ARCH_PROPERTY

ENTERPRISE DISTRIBUTED ARCHITECTURE 13.0 ADMINISTRATION GUIDE

1.10.1.1 Process Server Definition

ADMINISTRATION GUIDE 13.0 ENTERPRISE DISTRIBUTED ARCHITECTURE

Process Manager Configuration Page

This screen is available only to Sungard customer’s (customer0) Administrator Role

ENTERPRISE DISTRIBUTED ARCHITECTURE 13.0 ADMINISTRATION GUIDE

Process Manager Configuration UI- Definition Tab

Following table outlines each field in the above screen.

Definition Tab UI Field Type Required Validation / Default

ADMINISTRATION GUIDE 13.0 ENTERPRISE DISTRIBUTED ARCHITECTURE

There are three modes of operation in the PMConfig UI.

Add Process Manager

INFO 2014-07-23 09:13:23 82-634 ProcessManagerConfigurationService: Added

INFO 2014-07-23 09:30:32 39-994 ProcessExecutorController: Process executor

ENTERPRISE DISTRIBUTED ARCHITECTURE 13.0 ADMINISTRATION GUIDE

INFO 2014-07-23 09:30:32 39-994 ProcessExecutor: Executor [Test], instance