Anda di halaman 1dari 189

Sarbanes-Oxley

Express
Administrators Manual - August 2005

OpenPages, Inc.
201 Jones Road
Waltham, MA 02451
781.647.3800
www.openpages.com

ii

Copyright Information
Copyright 2003-2005 OpenPages, Inc. All rights reserved.
No part of this book may be reproduced, stored in a retrieval system, or transmitted by any
means, electronic, mechanical, photocopying, recording, or otherwise, without written
permission from OpenPages.
All questions pertaining to duplication or redistribution of this material and/or the software that
it describes should be directed to:
OpenPages, Inc.
201 Jones Road
Waltham, MA 02451
781.647.3800

Trademark Information
OpenPages, Sarbanes-Oxley Express, and SOX Express are Registered Trademarks of
OpenPages Inc.

Disclaimer
Although every precaution has been taken in the preparation of this user manual, OpenPages
and the author assume no responsibility for errors or omissions. No liability is assumed for
damages resulting from the use of the information contained herein.

Release Information
Software Version: Sarbanes-Oxley Express 3.1.0
Administrators Manual Published: August 2005
Manual Version: AM-310.7

iii

Table of Contents

Chapter 1

Introduction
What is the Sarbanes-Oxley Act of 2002? . . . . . . . . . . . . . . . . . . . . . . 2
Overview . . . . . . . . . . .
What is Section 302? . . .
What is Section 404? . . .
Additional Responsibilities
Additional Information . .

....
....
....
...
....

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

2
2
2
2
2

What is Sarbanes-Oxley Express? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
How Can Sarbanes-Oxley Express Help Me? . . . . . . . . . . . . . . . 3
What is Internal Controls Documentation? . . . . . . . . . . . . . . . . 3

Chapter 2

Administering SOX Express


Administering Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
About SOX Express Users and Groups . . . . . .
About User Names and Passwords . . .
Creating a New SOX Express User . . . . . . . . .
Modifying an Existing User Account . . . . . . . .
Disabling a User Account . . . . . . . . . . . . . . .
Re-enabling a SOX Express User . . . . . . . . . .
Associating an Existing User with a Group . . .
Disassociating a User from a Group . . . . . . . .
Creating a Group . . . . . . . . . . . . . . . . . . . . .
Removing a Sub-Group . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

6
6
6
7
7
7
8
8
8
9

Using Application Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10


Overview of the SOX Express Application Permissions
SOX Express Application Permissions . . . . . . . . . . . .
Administration . . . . . . . . . . . . . . . . . . . . . .
Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . .
Browse Files . . . . . . . . . . . . . . . . . . . . . . .
Folders . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Management . . . . . . . . . . . . . . . . . .
View Locks . . . . . . . . . . . . . . . . . . . . . . . .
Other Permissions . . . . . . . . . . . . . . . . . . . . . . . . .
All Permissions . . . . . . . . . . . . . . . . . . . . . .
Administration . . . . . . . . . . . . . . . . . . . . . .
Collaboration . . . . . . . . . . . . . . . . . . . . . . .
Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

10
10
10
10
10
11
11
11
11
11
11
11
11
12

iv

Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Setting Up Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Overview of Implementing ACL Security . . . . . . . . . . .
About Access Controls . . . . . . . . . . . . . . . . .
Preparing For Your Security Implementation . .
The Compliance Object Folder Structure . . . . . . . . . . .
Using Inheritance with Access Control Lists . . . . . . . .
About Breaking Inheritance . . . . . . . . . . . . . .
Creating a New ACL . . . . . . . . . . . . . . . . . . . . . . . . .
Editing an Existing ACL . . . . . . . . . . . . . . . . . . . . . .
Deleting an Existing ACL . . . . . . . . . . . . . . . . . . . . .
Using Groups to Establish User Roles . . . . . . . . . . . . .
The Core SOX Express Groups . . . . . . . . . .
Example: Using Groups to Establish User Roles
Using Groups to Limit User Activities . . . . . . . . . . . . .
Using Nested Groups to Limit User Scope . . . . . . . . . .
Step One: Breaking Folder Inheritance . . . . . .
Step Two: Nesting Your User Groups . . . . . . .
Using Group ACLs to Traverse Business Entities . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

13
13
14
15
16
16
17
18
18
19
19
19
20
23
23
23
26

Setting Up LDAP User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 27


Overview of LDAP Authentication . . . . . . . . . . . . . . . . . . . . .
Supported LDAP Servers . . . . . . . . . . . . . . . . . . . . . .
Configuring the LDAP Authentication Module . . . . . . . . . . . . . .
Step One: Adding Existing Users to the LDAP Server . .
Step Two: Changing the OPSystem Password (optional)
Step Three: Editing the LDAP Configuration File . . . . . .

.
.
.
.
.
.

27
27
27
27
28
28

Configuring Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
About the UPEA Command File . . . . . . . . . . .
Pre-requisites . . . . . . . . . . . . . . . . .
UPEA Syntax . . . . . . . . . . . . . . . . . .
Changing the Password Encryption Algorithms
Changing the 3DES Encryption Key . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

30
30
30
30
31
32

Working with Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33


Viewing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplied Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding Reports . . . . . . . . . . . . . . . . . . . . . . . .
Accessing the Report Pages and Page Templates
Creating a New Instance of a Report . . . . . . . . . . . . . .
Modifying an Existing Report Template . . . . . . . . . . . . .
Deleting a Report . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Interactive Reports . . . . . . . . . . . . . . . . . . . .
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating an Interactive Report . . . . . . . . . . . . .
Running an Interactive Report . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

33
34
36
36
37
38
38
38
38
38
39

Limiting the Report Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40


About the Report Scoping Wizard . . . .
Overview . . . . . . . . . . . . . . . .
Usage Example . . . . . . . . . . .
Configuring the Report Scoping Wizard
Overview . . . . . . . . . . . . . . . .
Configuring the Scope Wizard .
Using the Report Scoping Wizard . . . . .
Overview . . . . . . . . . . . . . . . .
Scoping a Report . . . . . . . . . .
Table of Contents

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

40
40
40
40
40
40
41
41
42

Managing Reporting Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43


Overview of Reporting Periods . . . . . . . . . . . . . . . . . . . .
Creating a New Reporting Period . . . . . . . . . . . . . . . . . . .
Changing the Reporting Period Naming Convention
Deleting a Reporting Period . . . . . . . . . . . . . . . . . . . . . .
Deleting a Reporting Period . . . . . . . . . . . . . . . . .
Configuring the Deletion Period . . . . . . . . . . . . . .
Accessing Past Reporting Periods . . . . . . . . . . . . . . . . . .
How ACLs and Reporting Periods Interact . . . . . . .
How Reporting Periods and Audit Trails Interact . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

43
43
43
44
44
44
45
45
45

Resetting Compliance Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46


Overview of Compliance Object Resetting . . . . . . . .
Preparing Your Data . . . . . . . . . . . . . . . . . . . . . .
Backing Up Your SOX Express Data . . . . . .
Creating a Reporting Period (optional) . . . .
Creating a Ruleset . . . . . . . . . . . . . . . . . . . . . . . .
Creating the Ruleset File . . . . . . . . . . . . . .
Sample Ruleset . . . . . . . . . . . . . . . . . . . .
The Ruleset Tag Library . . . . . . . . . . . . . .
Loading the Ruleset . . . . . . . . . . . . . . . . . . . . . . .
Performing the Compliance Object Reset . . . . . . . .
Preparing for the Reset . . . . . . . . . . . . . . .
Configuring the Ruleset Parameters . . . . . .
Using the Compliance Object Reset Page . .
Starting the Compliance Object Reset . . . . .
Viewing the Reset Status . . . . . . . . . . . . .
Viewing the Reset Session Details . . . . . . . . . . . . .
Viewing the Reset Session Log . . . . . . . . . .
After the Reset . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

46
46
46
46
47
47
47
48
55
55
55
55
56
57
57
57
58
58

Starting Jobs from SOX Express Objects . . . . . . . . . . . . . . . . . . . . . . . 59


Overview of SOX Express Jobs . . . . . . . . . . . . . . . .
Additional Information . . . . . . . . . . . . . . . .
Starting a Job from a SOX Express Compliance Object
Monitoring Job Progess . . . . . . . . . . . . . . . . . . . . .

Chapter 3

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

59
59
59
59

Configuring SOX Express


Using The Backup Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Overview of the Backup Utility . . . . .
Prerequisites . . . . . . . . . . . . . . . . . .
Configuring the Backup/Restore Utility
Using the Backup Utility . . . . . . . . . .
Additional Information . . . . . . . . . . .
Generated Files . . . . . . . . . .
Usage Notes . . . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

61
61
61
61
61
61
62

Using the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63


Overview of the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . 63
Using the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Generating Object Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Overview of Name Generation . . . .
Modifying the Naming Settings . . . .
Configuring the Object Name . . . . .
Autogenerating Long Names
Naming Examples . . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

64
64
65
65
66

Managing Signatures and Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


Overview of Signatures and Locks . . . . .
Enabling and Disabling Signatures . . . . .
Manual Signatures . . . . . . . . . .
Automatic Signatures . . . . . . . .
Cascading Signatures . . . . . . . .
Enabling and Disabling Locks . . . . . . . .
The Lock and Unlock Permissions . . . . .
Locking Access Privileges . . . . . . . . . . .

....
....
....
....
....
....
....
....

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

67
67
67
68
69
69
70
70

Enabling Workflows for SOX Express Objects . . . . . . . . . . . . . . . . . . . . 71


About Enabling SOX Express Workflows . . . . . . . . . . . . . . . . . . 71
Pre-requisites for Starting SOX Express Jobs . . . . . . . . . 71
Enabling a Job Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Configuring Job Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Overview of SOX Express Jobs . . . . . . . . . . . . . . . . . .
Enabling Signatures for SOX Express Jobs . . . . . . . . . .
Assigning Job Tasks Based on Object Properties . . . . . .
Planning Ahead . . . . . . . . . . . . . . . . . . . . . . .
Modifying the Job Type Properties . . . . . . . . . .
Modifying the Job Task . . . . . . . . . . . . . . . . . .
Creating the Compliance Object Custom Property
Attaching Reports to Workflow Tasks . . . . . . . . . . . . . .
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a Report to a Workflow Task . . . . . . . . .
Removing a Report from a Workflow Task . . . . .
Using Interactive Reports with Workflow Tasks .
Enabling Optional Reporting Tools

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

73
73
73
73
73
74
75
75
75
75
76
76

. . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Differences From the Exporter Tool . . . . . . . . . . . . .
Configuring the Reporting Metadata . . . . . . . . . . . . . . . . . . .
About the Configuration Tables . . . . . . . . . . . . . . . .
About the Reporting Schema Scripts . . . . . . . . . . . .
Customizing the Reporting Schema Configuration . . .
Supported Macro Keywords . . . . . . . . . . . . . . . . . . .
Populating the Reporting Schema . . . . . . . . . . . . . . . . . . . .
Checking the Results of the Reporting Schema Refresh
Exporting Data to the Reporting Database Instance . . . . . . . .
Exporting the Reporting Schema Contents . . . . . . . .
Importing the Reporting Schema Contents . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

77
77
77
77
79
79
80
81
82
83
83
84

Changing the Database Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . 85


Overview of Changing the Database Passwords . . . . . . . . .
Changing the Oracle Password . . . . . . . . . . . . . . . . . . . .
Changing the WebLogic Password . . . . . . . . . . . . . . . . . .
Changing the Password in WebLogic . . . . . . . . . . .
Changing the Password References in SOX Express
Changing Your Server IP Address . . . . . . . . . . . . . . . . . .

Chapter 4

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

85
85
86
86
86
87

Modifying SOX Express Behavior


Customizing the Overview Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
About Customizing the Overview Pages . . . . .
Modifying the Overview Page Definitions . . . .
Enabling/Disabling the Expand All Capability
Modifying the Overview Node Cache . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

89
89
90
91

Modifying Compliance Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Overview of Modifying Compliance Objects . . . . . . . . . . . . . . . .


Example: Adding a New Text Field . . . . . . . . . . . . . . . .
Step One: Identifying the New Field . . . . . . . . . . . . . . . . . . . .
Example: Identifying the New Field . . . . . . . . . . . . . . .
Step Two: Defining the Field Properties . . . . . . . . . . . . . . . . . .
Example: Defining the Field Properties . . . . . . . . . . . . .
Step Three: Attaching the Property Bundle . . . . . . . . . . . . . . . .
Example: Attaching the Property Bundle . . . . . . . . . . . .
Step Four: Displaying the New Field . . . . . . . . . . . . . . . . . . . .
Example: Displaying the New Text Field . . . . . . . . . . . .
Step Five: Activating the New Field . . . . . . . . . . . . . . . . . . . . .
Example: Adding a New Text Area Field . . . . . . . . . . . . . . . . . .
Example: Adding a New Drop-down Selection Field . . . . . . . . . .
Example: Adding a New HTML Field . . . . . . . . . . . . . . . . . . . . .
Hiding an Existing Object Property Field . . . . . . . . . . . . . . . . . .
Modifying Property Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying an Existing Property in configTileDefinitions.xml
Modifying an Non-Existent Property in
configTileDefinitions.xml . . . . . . . . . . . . . . . . . . . .
Modifying the Overview Label . . . . . . . . . . . . . . . . . . .

92
92
92
93
93
95
96
96
97
98
99
99
101
103
105
106
106
107
107

Additional Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Compliance Object Tables . . . . . . . . . . . . . . . .
Adding a Column to a Compliance Object Table . . . . . . .
Replacing a Column in a Compliance Object Table . . . . .
Modifying the Label of a Compliance Object Table Column
Hiding a Column in a Compliance Object Table . . . . . . .
Configuring the Compliance Object Listings . . . . . . . . . . . . . . .
Adding a Column to a Compliance Object Listing . . . . . .
Replacing a Column in a Compliance Object Listing . . . .
Modifying the Label of a Compliance Object
Listing Column . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hiding a Column in a Compliance Object Listing . . . . . . .
Configuring the User Selector Tool . . . . . . . . . . . . . . . . . . . . . .
Configuring the User Segment Size . . . . . . . . . . . . . . .
Specifying a Group for the User Selector . . . . . . . . . . . .
Configuring the Displayed Fields . . . . . . . . . . . . . . . . .
Redirecting the SOX Express Logout Link . . . . . . . . . . . . . . . . .
Displaying the Sub-Processes Header in the Action Menu . . . . .
Resolving Duplicate Names During Copy Operations . . . . . . . . .
Setting the Default Copy Behavior . . . . . . . . . . . . . . . .
Copy Behavior Options . . . . . . . . . . . . . . . . . . . . . . . .
Using an SSL Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . .

108
108
108
109
110
111
111
111
112
113
114
114
114
115
115
116
117
117
117
117
118

Using Netegrity SiteMinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119


Overview of SiteMinder Integration . . . . . . . . . . . . . . .
Installing and Configuring SiteMinder . . . . . . . . . . . . . .
Configuring SOX Express for SiteMinder Integration . . .
Configuring OpenPages for SiteMinder Integration . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

119
119
119
119

Appendix A

The Notification Manager


Overview of the Notification Manager . . . . . . . . . . . . . . . . . . . . 120
Why would I use Notifications? . . . . . . . . . . . . . . . . . . 120
About the Notification Manager

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Exploring the Notification Reports . . . . . . . . . . . .


Using the Notification Manager . . . . . . . . . . . . . .
Requirements for Setting Up a Notification
Results of Running a Notification Report . .
Step One: Preparing Your Data

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

121
121
121
121

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Using the Test Notification Template . . . . . . . . . . . . . . . . . . . . 122
Using the General SOX Notifications Template . . . . . . . . . . . . . 122
Step Two: Creating the Notification

. . . . . . . . . . . . . . . . . . . . . . . . . . 123

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Test Notification . . . . . . . . . . . . . . .
Understanding the Test Notification Fields
Creating a General Notification . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

123
123
123
126

Step Three: Triggering the Notification . . . . . . . . . . . . . . . . . . . . . . . . 129


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running Notification Reports Manually . . . . . . .
Running Notification Reports Automatically . . . .
The Notification Manager Command Line
Scheduling Your Automatic Notification

Chapter B

.......
.......
.......
Interface
.......

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

129
129
129
129
131

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

132
133
133
135
137
139
140
142
144
147
151
153
155
157
159
160
161
162
164
164
164
165
165
166
166
167
167
167
167
168
168
168

The SOX Express Reporting Schema


Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
Compliance Object Tables . . . . . . . . . . . . . .
Business Entity . . . . . . . . . . . . . . . .
Accounts . . . . . . . . . . . . . . . . . . . . .
Sub-Accounts . . . . . . . . . . . . . . . . .
Processes . . . . . . . . . . . . . . . . . . . .
Sub-Processes . . . . . . . . . . . . . . . . .
Control Objectives . . . . . . . . . . . . . .
Risk . . . . . . . . . . . . . . . . . . . . . . . .
Controls . . . . . . . . . . . . . . . . . . . . .
Test . . . . . . . . . . . . . . . . . . . . . . . .
Test Results . . . . . . . . . . . . . . . . . . .
Issues . . . . . . . . . . . . . . . . . . . . . . .
Action Items . . . . . . . . . . . . . . . . . .
Signatures . . . . . . . . . . . . . . . . . . . .
Files . . . . . . . . . . . . . . . . . . . . . . . .
Links . . . . . . . . . . . . . . . . . . . . . . .
Milestones . . . . . . . . . . . . . . . . . . . .
Compliance Object Relationship Tables . . . . .
Business Entity Relationships . . . . . . .
Account Relationships . . . . . . . . . . . .
Sub-Account Relationships . . . . . . . .
Process Relationships . . . . . . . . . . . .
Sub-Process Relationships . . . . . . . . .
Control Objective Relationships . . . . .
Control Relationships . . . . . . . . . . . .
Test Relationships . . . . . . . . . . . . . .
Test Result Relationships . . . . . . . . .
Issue Relationships . . . . . . . . . . . . . .
Test Result Relationships . . . . . . . . .
Action Item Relationships . . . . . . . . .
Milestone Relationships . . . . . . . . . . .

....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Master Relationships Table . . .


Milestone Relationships
Security Tables . . . . . . . . . . .
Effective Rights . . . . .
Folders . . . . . . . . . . .
Actors . . . . . . . . . . . .
Audit Trails . . . . . . . . . . . . . .
Audit Trail . . . . . . . . .

Appendix C

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

169
169
170
170
171
171
172
172

Integrating with TeamMate


What is TeamMate? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
How TeamMate and SOX Express Interact . . . . . . . . . . . . . . . . 173
TeamMate/SOX Express Naming Schemes . . . . . . . . . . 174
Exporting Data to TeamMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
How Exporting Data Works . . . . . . . . . .
Setting Up The Schema Mapping . . . . . .
Running the TeamMate Export Report . .
Importing the Data Into TeamMate . . . .
Troubleshooting the Export Process . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

175
175
175
175
176

Importing Data From TeamMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177


How Importing Data Works . . . . . . . . . . .
Exporting the Data From TeamMate . . . . .
Transforming the XML File . . . . . . . . . . . .
Importing the TeamMate Data . . . . . . . . .
Displaying the TeamMate Properties

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

177
177
177
177
178

Introduction

This Administration Guide provides information and instructions for


maintaining and administrating the Sarbanes-Oxley Express
application. Topics covered include user and group administration,
database backup and restoration, customizing the applications look
and feel, using the data loader capabilities, and much more.

What is the Sarbanes-Oxley Act of 2002? 2

What is the Sarbanes-Oxley Act of 2002?


Overview
The Sarbanes-Oxley Act of 2002 (SOA) is a piece of landmark legislation designed to make
public companies more transparent in their financial reporting and more proactive in sharing
material information with other participants in the financial reporting chain such as auditors,
audit committees, analysts, and investors.
The SOA is a complex act with many provisions. The two sections most relevant to public
corporations are sections 302 and 404. Section 302 pertains to disclosure controls and
procedures; Section 404 to internal controls and procedures for financial reporting.

What is Section 302?


Section 302 of the SOA mandates that CEOs and CFOs personally certify financial statements
and filings, as well as affirm that they are responsible for establishing and enforcing disclosure
controls and procedures at all levels of their corporation. With each quarterly filing, they must
certify that they have evaluated the effectiveness of these controls. In addition, they must
disclose to their audit committee all significant deficiencies, material weaknesses, and acts of
fraud.
Section 302 of the Sarbanes-Oxley Act was put into effect in 2002.

What is Section 404?


Section 404 of the SOA requires an annual evaluation of internal controls and procedures for
financial reporting. Under this scheme, a corporation must document its existing controls that
have a bearing on financial reporting, test them for efficacy, and report on gaps and
deficiencies.
Furthermore, the companys independent auditor must issue a report, to be included in the
companys annual report, that attests to managements assertion on the effectiveness of
internal controls and procedures and financial reporting.
Section 404 of the Sarbanes-Oxley Act will be effective for the fiscal years ending June 15th,
2004.

Additional Responsibilities
The SOA also describes other responsibilities. For example, it informs company boards of their
responsibilities with respect to the institution of audit committees. It instructs the SEC to create
an independent public accounting oversight board with the express mandate to regulate the
conduct of audit firms. Furthermore, it lays down guidelines for conduct of attorneys that
represent public corporations before the SEC.

Additional Information
This guide only provides a high-level overview of the Sarbanes-Oxley Act of 2002. You can find
more in-depth information about the Sarbanes-Oxley Act of 2002 in the Sarbanes-Oxley
Resource Center on the OpenPages web site at http://www.openpages.com.

Introduction

What is Sarbanes-Oxley Express? 3

What is Sarbanes-Oxley Express?


Overview
Sarbanes-Oxley Express (SOX) is an Internal Controls Management System that empowers
CEOs, CFOs and financial management officers to document internal controls as set up by the
Sarbanes-Oxley Act.
SOX allows users to easily see the status of their internal controls documentation project, and
provides a secure repository for the storage of their IC documentation.

How Can Sarbanes-Oxley Express Help Me?


SOX has many features that assist users in documenting their internal controls. Some of the
most important are:

Collaborative Task Management


Allows the breakdown of the Internal Controls documentation project into easily
achievable milestones and tasks that can be assigned to specific users.

Automated Reporting Processes


Generates real-time reports on the current status of the IC documentation project that
can be sorted and filtered on multiple levels.

Internal Controls Documentation Repository


Flexible, robust documentation repository with versioning and both property and fulltext searching capabilities.

Signoff Capability
Supports the attachment of signoff tasks that require a user to append a signature to
a compliance object.

What is Internal Controls Documentation?


A critical facet of implementing an internal controls framework is developing a repository of
internal controls. Internal controls may relate to different aspects of running the business,
particularly financial reporting, optimal operations, and compliance.
For each financial account, a business will have one or more processes that apply to that
account. Each process has certain risks associated with it that may result in an unwanted
result, such as fraud, mishandling of funds, or simple accounting errors. The Sarbanes-Oxley
Act of 2002 requires that these risks be identified, and that controls be put into place to prevent
errors from occurring. The existence and performance of these controls must be documented
and evaluated by the CEO and CFO of the company, and attested to by an external auditor.

Introduction

Administering
SOX Express
This chapter provides information about administering the SOX Express
application using the capabilities of the SOX Express user interface,
including adding and modifying SOX Express users, setting up folderlevel security, report administration, and managing reporting periods.
This chapter contains the following sections:

Administering Users and Groups on page 6


Using Application Permissions on page 10
Setting Up Security on page 13
Setting Up LDAP User Authentication on page 27
Configuring Password Encryption on page 30
Working with Reports on page 33
Managing Reporting Periods on page 43
Resetting Compliance Objects on page 46
Starting Jobs from SOX Express Objects on page 59

Administering Users and Groups 6

Administering Users and Groups


About SOX Express Users and Groups
To create and administer users and groups for Sarbanes-Oxley Express, you must have access
to a SOX Express user account with administrative privileges.
In general, there are two different groups of SOX Express users; regular SOX Express users
who can view and create compliance objects (such as accounts, processes, risks, etc.), and
SOX Express administrators, who can create and modify users and groups, as well as other
administrative features of the SOX Express application.
This section will explain how to create, modify, and delete SOX Express user accounts and
groups using the SOX Express interface.

About User Names and Passwords


When creating user names, the following rules apply:

The maximum length of a user name is 32 characters.


The user name cannot contain spaces.
The user name can contain alphanumeric characters and any of the following special
characters:

Allowed Special
Character

Description

At sign

Dash

Exclamation point or bang

Period or dot

Underscore

When creating passwords, the following rule applies:

The maximum length of a password is 32 characters.

Creating a New SOX Express User


When creating a new SOX Express user, you must first select the group to which the user will
belong, and then enter information about the user and user account. If you have not created an
appropriate group for the new user, add them to the SOXUsers group.
If the user will be responsible for adding, editing, or removing reports or access control lists
(ACLs), the account should be added to the SOXAdministrators group.
To create a new SOX Express user:
1.
2.
3.

Log into SOX Express with an account that has permissions to add and modify users
and groups.
Click on the Users / Groups link under the Administration heading. The list of SOX
Express users and groups is displayed.
Expand the list of groups and users until the group to which you want to add the new
user is displayed. Click the name of the group to display the Group Details page.

Administering SOX Express

Administering Users and Groups 7

4.
5.

Scroll down to the Users section that lists all of the users who currently belong to the
group. Click the Add New... button.
Enter the necessary information for the new user account. When you are finished, click
Create to continue.
Note: User names must contain only alphanumeric characters and underscores, and
cannot contain spaces. User names and passwords are limited to 32 characters.

Modifying an Existing User Account


To edit a user account:
1.

Log into SOX Express with an account that has permissions to add and modify users
and groups.
2. Click on the Users and Groups link under the Administration heading. The list of
SOX Express users and groups is displayed.
3. Expand the list until the user account you wish to edit is shown and then click on the
user name to display the Details page.
4. Click the Edit... button at the top of the User Information section. The Edit User
Information page is displayed.
Note: You may not change a users user name.
5.

Edit the necessary information, and click Save to return to the User Details page.

Disabling a User Account


User accounts cannot be deleted in SOX Express. Disabling a user account prevents the user of
that account from logging in.
To disable a user account:
1.
2.
3.
4.

Log into SOX Express with an account that has permissions to add and modify users
and groups.
Click on the Users and Groups link under the Administration heading. The list of
SOX Express users and groups is displayed.
Expand the list until the user account you wish to disable is shown and then click on the
user name to display the Details page.
Click the Disable button at the top of the User Information section. The button text
changes to Enable and the value of the Active field changes to False.

Re-enabling a SOX Express User


To enable a disabled user account:
1.
2.
3.
4.

Log into SOX Express with an account that has permissions to add and modify users
and groups.
Click on the Users and Groups link under the Administration heading. The list of
SOX Express users and groups is displayed.
Expand the list until the disabled user account you wish to enable is shown and then
click on the user name to display the Details page.
Click the Enable button at the top of the User Information section. The button text
changes to Disable and the value of the Active field changes to False.

Administering SOX Express

Administering Users and Groups 8

Associating an Existing User with a Group


To add a new user to a SOX Express group:
1.

Log into SOX Express with an account that has permissions to add and modify users
and groups.
2. Click on the Users and Groups link under the Administration heading. The list of
SOX Express users and groups is displayed.
3. Navigate to the group to which you want to add a user.
4. Click the group name to display the Details page.
5. Click the Associate... button at the top of the Users table. The Select Users page is
displayed.
6. Expand the user list to find the user you wish to add.
7. Select the checkbox next to the user account you wish to add to the group and click the
Associate button to add the user to the current group.

Disassociating a User from a Group


To disassociate a user from a group:
1.
2.
3.
4.
5.

Log into SOX Express with an account that has permissions to add and modify users
and groups.
Click on the Users and Groups link under the Administration heading. The list of
SOX Express users and groups is displayed.
Expand the list of groups and users and click the name of the desired user group.
Scroll down to the Users section of the Details page
Select the checkbox next to the user you wish to remove from the group and click the
Disassociate button to remove the user from the group.

Creating a Group
Users with the correct permissions can create groups using the SOX Express User/Group
interface. Groups can contain other groups and users, and inherit application permissions from
the groups that they belong to.
To create a new group:
1.
2.
3.

4.
5.

Log into SOX Express with an account that has permissions to add and modify users
and groups.
Click on the Users and Groups link under the Administration heading. The list of
SOX Express users and groups is displayed.
Expand the list and click on the name of the group to which the new group will belong.
If there is no higher-level group for the new group, click on SOXUsers. The Details
page of the group is displayed.
Scroll down to the Sub-Groups section of the Details page and click Add New...
Fill in the required information for the new group and click Create. The parent groups
Details page is displayed with the new group listed in the Sub-Groups section.
Note: Group names must contain only alphanumeric characters and underscores, and
cannot contain spaces. Group names are limited to 40 characters.

6.

Click the name of the new group to view the Details page if you want to add users to
the group or modify the group permissions.

Administering SOX Express

Administering Users and Groups 9

Tip: Finding Users Quickly


In order to more easily find a specific user without browsing through multiple groups and
subgroups, it is recommended that you create an Everyone group (or other suitable name) as
a sub-group of the SOXUsers group.
This is useful since normally you create SOX Express users in the context of a group, and then
add them to multiple groups directly. This means that in order to find an existing user, you
need to know a group to which the user belongs. To help this process, follow the suggestions
below.
As you create your list of SOX Express users, add them directly to the Everyone group as well
as the functional groups they will belong to. In this manner, to find a specific user quickly, you
can open the Everyone group and select the user directly.
If you want to deny a user access to SOX Express by removing him from all SOX groups, you
will need to remove him from the Everyone group as well.
Note: If you have set up your security access controls for your groups and users, it is
important that the Everyone group is not granted access control to your SOX data. Otherwise,
the access permissions of the Everyone group may override your security settings. The
Everyone group is merely a convenience to help administrators quickly find a specific user
and modify their information.

Removing a Sub-Group
When you remove a sub-group from a SOX Express group and that sub-group does not belong
to any other SOX Express group, the sub-group will not appear in the Users/Groups listing.
When adding an existing group to another group, the removed group will still be available in
the group selector list.
Note: If you remove a sub-group from the SOXUsers group, and the members of that group do
not belong to any other groups that inherit permissions from the SOXUsers group, they will no
longer be able to log in to SOX Express.
To remove a sub-group from a group:
1.
2.
3.
4.
5.

Log into SOX Express with an account that has permissions to add and modify users
and groups.
Click on the Users and Groups link under the Administration heading. The list of
SOX Express users and groups is displayed.
Expand the list and click on the name of the group to which the soon-to-be-deleted
group belongs. The Details page of the group is displayed.
Scroll down to the Sub-Groups section of the Details page, select the checkbox next to
the group to be deleted, and click Disassociate. A confirmation dialog is displayed.
Click OK in the dialog to disassociate the selected group(s)

Administering SOX Express

Using Application Permissions 10

Using Application Permissions


Overview of the SOX Express Application Permissions
Sarbanes-Oxley Express (SOX Express) provides a set of application permissions that
administrators can use to limit the activities of the various user groups that can access the SOX
Express application.
This section provides a quick overview of the different SOX Express-specific permissions
available to administrative users.
All of the permissions can be accessed through the Details page of the various user groups and
are grouped under the SOX heading. Selecting the SOX permission checkbox will select all of
the SOX permissions. This is only advisable for administrative level users.

SOX Express Application Permissions


The following permissions can be applied to SOX Express user groups:

Administration
This application permission grants all three permissions in the Administration grouping. If you
wish to create an administrative-level group, they will need this permission group. If a user
group possesses any of these permissions, they will see the Administration heading in the
right-hand Action menu with the appropriate sub-headings.

Access Control Lists


Allows members of the user group to view, edit, and remove the access control listings for
compliance objects through the Access Controls link in the left-hand Action menu. See the
Setting Up Security section for more information on Access Control Lists (ACLs).

Object Reset
Allows members of the user group to reset compliance objects for a new reporting period. For
information on governing reset behavior, see the section, Resetting Compliance Objects on
page 46.

Reporting Periods
Allows members of the user group to create and delete Reporting Periods through the
Reporting Periods link in the left-hand Action menu.

Users and Groups


Allows members of the user group to add, modify, and remove users and groups through the
Users/Groups link in the left-hand Action menu.

Audit Trail
This application permission allows members of the user group to view the Audit Trail
information for compliance objects. With this permission enabled, an Audit Trail button can be
selected at the top of the compliance objects Details page.

Browse Files
Allows groups with this permission to view and navigate the Browse Files heading on the
Action menu.

Administering SOX Express

Using Application Permissions 11

Folders
This application permission allows members of the user group to create new folders in the
compliance object repository that do not correspond to business entities. This allows users to
create their own folder structure.

Issues
The application permission allows members of the user group to view the list of SOX Issues
through the Issues link in the left-hand Action menu.

Project Management
The application permission allows members of the user group to use the Project Management
capabilities available through the Project Management link in the left-hand Action menu.

View Locks
Users with the View Locks permission can view the existing locks on compliance objects. The
View Locks permission does not grant the right to lock or unlock an object - for that you need
either the Lock permission or the Unlock permission.

Other Permissions
The following application permissions are not contained under the SOX permission heading, but
still have an impact on SOX Express application behavior. Application permissions determine
what functional areas and administrative operations a given user or group is able to perform.
Typically, end users do not require applicaiton permissions.

All Permissions
Grants members of the user group all permissions and access to every functional and
administrative area within SOX Express (Web and server).

Administration
Grants members of the user group access to all administrative functions within SOX Express
(Web and server).

Collaboration
This application permission grants all administrative permissions under the Collaboration
grouping that are related to managing tasks and jobs.

Manage Job Tyes


Allows group members to add and modify job types. Job types are templates that can be used
to create individual jobs.

Start Jobs
Allows group members to start a job.

View All Active Jobs


Allows group members to view a list of jobs and the Details page related to a selected job.

Administering SOX Express

Using Application Permissions 12

Files
This application permission grants all administrative permissions under the Files grouping that
are related to managing files and folders.

Add Folders
Allows group members to create and add new folders.

Cancel Checkout
Allows group members to cancel the file check out process for associated files that were
checked out by others. When a file check out is canceled, the file is checked back into the
system without applying any changes and no new version of the file is created.

Lock
Allows group members to sign off on any SOX Express compliance object, regardless of signoff
or ACL restrictions.

Unlock
Allows group members to unlock any SOX Express compliance object.

Publishing
Add Folder Assignments
Allows group members to create a new folder assignment. Folder assignments link to an
existing folder in the repository and automatically create a reference in the current channel
folder to any files of a particular file type.

Add Folders
Allows group members to create and add a new channel folder.

Add Pages
Allows group members to create and add publishing-specific files that are used to generate
published web pages. Pages are based on page templates.

Add Templates
Allows group members to create and add page templates that are used to create Web pages.

Assign Files
Allows group members to assign files to specific channel folders.

Browse Channels
Allows group members to browse channels. A channel represent the structure of a published
website.

Create Channels
Allows group members to create a new channel for publishing a website.

Manage Rules
Allows group members to add and modify file rules that specify how file assignments are
published within a given channel folder.

Administering SOX Express

Setting Up Security 13

Setting Up Security
Overview of Implementing ACL Security
Sarbanes-Oxley Express allows administrators to grant or deny read, write, delete, and
associate permissions to groups or specific users. These permissions are set using an Access
Control List, or ACL. An ACL is the list of groups and users who have permissions for the
specified folder. You can explicitly set permissions on folders or inherit permissions from a
parent folder.
This section provides an overview of the procedures involved in setting up security for your
internal controls documentation project, as well as the reasoning behind the required group and
ACL structures.

About Access Controls


Access Controls can be set to control the ability to read, write, delete, and associate the
compliance objects in a folder. Each of these settings can be set individually, allowing fine-level
control over user and group access to the contents of a folder. Any folders that contain the SOX
Express compliance objects (business entities, accounts, risks, etc.) can be administered
through ACLs.

Note: SOX Express access controls can only be set at the folder level. Individual objects within
a folder cannot have ACLs - they automatically assume the ACL of the folder. If you have
permissions for one item in a folder, you have the same permissions for the other compliance
objects in that folder.

Explaining Access Permissions


There are four access permissions that users and groups can be given for a folder structure.
The permissions are Read, Write, Delete, and Associate. The section below quickly explains the
different permissions.

Read - the group or user can view the details of the objects contained in the folder and
the folder itself, but cannot edit them. Note that if Read access is denied to a group or
user, they will not be able to SEE the folder, or any folders under that folder.
Write - the group or user can view the details of the objects within a folder and modify
them, but cannot delete them. Write access to a folder is required for creating new
objects within the folder.
Delete - the group or user can delete objects within the folder.
Associate - the group or user can create associations between compliance objects

The settings for the different permissions are:

Granted - the user or group has full access to the specified action (Read/Write/Delete/
Associate). The user can view, modify, or delete the file or folder, depending on the
permission.
Inherited - the setting is inherited from the nearest parent folder that contains an
explicit setting for the permission. If no parent folder has an explicit permission set, the
root folder of the compliance hierarchy sets the permission.
Denied - the user or group cannot perform the specified action. If Read permissions
are denied, the folder will not be displayed in the hierarchical view or the compliance
object view.

Read permission is required for Write and Associate access, and Write access is required in
order for Delete access to be granted. You can select any combination of permissions, but when
you save the ACL, it will be modified to be a valid combination of permissions.
Administering SOX Express

Setting Up Security 14

For example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/Granted,


when you click Ok, the displayed permissions will be Granted/Granted/Granted/Granted
because users must have Read permissions in order to have Write, Delete, or Associate
permissions. Therefore, the Read permission is automatically changed to Granted.
In order to set Read to Denied, Write, Delete, and Associate must also be set to Denied.

Using ACLs with Top-Level Folders


When setting up your business entity and other compliance object hierarchy, certain folders are
already created for you by the SOX Express installation. These folders are created with pre-set
ACLs, and should not be modified.
Make sure you do not modify the ACLs for the following folders:
Default
BusinessEntity
ICDocumentation
Accounts
ControlObjectives
Controls
Processes
Risks
Signatures
SubAccounts
SubProcesses
Test Results
Tests
Issue
IssueActionItems
Plan
Milestone
Task
Files and Forms

Preparing For Your Security Implementation


Before you can implement your security settings for your internal controls documentation
project, you should do the following:

Set up at least a sample business entity hierarchy for testing purposes


Have a map on hand of your business entity hierarchy for easy reference.

Note: It can also be helpful to have your user accounts created, although you can implement
ACL security without them.

Example: Representing the Corporate Structure with Business Entities


Widgets, Inc. has a main corporate center that centrally controls all of the corporations
outlying regions. Each region has a central authority that is responsible for overseeing all of the
individual sites located within the region. In addition, each site has a staff responsible for
handling the finances and day-to-day operations of their site.
When setting up their compliance object hierarchy, the administrators realized that although
each site needed to be responsible for documenting their own controls, the set of processes and
risks for each site were identical. Therefore, they decided to create a Library of compliance
objects all linked to a Library business entity. The Library business entity would serve as the
blank template for each sites compliance object hierarchy.
First, the administrators created a business entity (CorporateCenter) for the entire corporation.
Then, they created an entire set of internal controls under the Library sub-entity. Once the
hierarchy was complete, they created a business entity under CorporateCenter for each region,
and sub-entities under each region for each regional site. Once the regional site entities were in
place, the administrators copied over the entire compliance object hierarchy from the Library
Administering SOX Express

Setting Up Security 15

entity to each regional site. Now each regional site has its own hierarchy, complete with a
unique entity folder structure.
Note that in our example, only the Library and the Site business entities have non-entity
compliance objects in them. The CorporateCenter and all of the Regional entities are just
containers for the Site business entities.

The Compliance Object Folder Structure


When the SOX Express object hierarchy is viewed using the Access Control menu option in
SOX Express, the folder structure is slightly different than the hierarchy shown in the Overview
screens (Account Overview, Entity Overview, etc.). The folder structure of the object hierarchy
looks like the following:

Business entities are contained in their own folder, while all of the other compliance object
types have their own folder underneath the ICDocumentation folder.
Note: ACLs should never be added to folders that were automatically created during the SOX
Express installation (e.g. ICDocumentation, BusinessEntity, etc.). Always create ACLs using the
SOX Express administrative user interface.
When you add a new business entity called Enterprise, a folder with the name of the business
entity is created underneath the BusinessEntity folder, as below:

When you add a sub-entity named Region to the Enterprise entity, a corresponding folder is
created.

When you add other compliance objects to a business entity hierarchy, the folder structure of
the business entities it belongs to is automatically created under the compliance object type
folder. All compliance objects of that type created for that business entity are placed in the
same folder.

Administering SOX Express

Setting Up Security 16

Important Note: When you are setting ACLs, it is important to remember to set ACLs for the
business entity folders under the ICDocumentation folder structure, as well as the
BusinessEntity folder structure. If you do not, when you try to access the compliance objects
you will not be able to browse to the objects. You should never set ACLs on the container
folders (e.g. ICDocumentation, BusinessEntity).

Using Inheritance with Access Control Lists


By default, folders in the SOX Express compliance object folder hierarchy inherit their security
ACLs from the folders above them. If a folder does not have an ACL set for a particular group,
the application looks back up the folder tree until it finds an ACL for that group and uses it for
the current folder. By default, all users can edit any compliance object in the entire project.
This setup is extremely useful for smaller projects, where there is a single (or very few) teams
all working on the same business entity structure. In the odd case where you have specific
users who are denied viewing or editing privileges, you can easily deny them access to a
particular folder structure by setting an explicit ACL for the group or user that denies them
access.
However, this paradigm rapidly becomes unwieldy for large numbers of groups or business
entities. If you only want a group to see one particular region or site out of 50, it is much
simpler to grant access to the single site than to deny access to the other 49.

About Breaking Inheritance


Using the SOX Express user interface, you can break the inheritance property on any folder.
When you break inheritance, access is limited to ONLY the groups and users who have an ACL
for that business entity. All other groups and users (besides the creator of the object) are
automatically set to Denied/Denied/Denied.
For large teams and projects who wish to restrict which areas of the IC documentation project
can be seen or modified, breaking the inheritance chain is very helpful, since it automatically
denies all groups and users access to the particular business entity structure. Only the groups
and users specifically included in an ACL have access to the business entity children.
Instead of denying a group access to 49 sites, as in the example above, now you only have to
grant access to the desired site, and the other 49 are denied by default.
Note: Breaking inheritance is not without its drawbacks. Because all groups (except
SOXAdministrators and OPAdministrators) are denied access to the business entity, groups that
do not have an ACL entry cannot see the business entity or any compliance object underneath
the business entity. This is true even if an ACL entry for a specific group is added to a subentity. Because the group (or user) is denied Read access at the parent business entity, they
cannot browse the tree to view the sub-entity where they have access. The following sections
will explain how to circumvent this restriction using nested groups.
To break the inheritance on a folder:
WARNING: Once you break the inheritance on a folder, the new permissions (or lack thereof)
go into effect immediately. Only members of the SOXAdministrators and OPAdminstrators
groups will be able to access the object, unless a specific ACL for a user or group is created.
1.
2.
3.
4.
5.
6.

Log into SOX Express as a user with Administrative privileges.


Click the Access Control link on the Action Menu and navigate to the business entity
folder where you wish to break inheritance (under the Default directory).
When you have found the desired folder, click the name of the folder to display the
Details page.
Click the Add button and choose the desired group or user from the list.
Choose the desired permissions for the group or user by highlighting the appropriate
entries and click the OK button to add the new ACL to the folder.
Now that a valid ACL exists for the folder, click the Disable Inheritance button under
the Folder heading. The value of the Inherit ACL field is changed to false and the
Disable Inheritance button changes to Enable Inheritance.
Administering SOX Express

Setting Up Security 17

7.

Click Access Controls in the breadcrumb trail to return to the Access Controls folder
list.

Remember, no one except the groups (and sub-groups of those groups) listed in the Access
Controls table will be able to see the folder or its contents.
Note: The SOXAdministrators group and the creator of a folder or object is exempt from ACL
restrictions. The creator always has Delete access to files and folders he or she has created,
while the SOXAdministrators group has total access to all files and folders.

Creating a New ACL


You must have the Access Control Lists application permission to view or edit ACL settings.
To set an ACL on a folder:
1.
2.
3.
4.
5.
6.
7.

Log into SOX Express as a user with the Access Control Lists application permission.
Click on the Administration | Access Control link in the Action menu. An expandable
list of folders is displayed.
Navigate to the folder whose access control list you want to modify. Click the folder
name to display the Details page of the folder.
Click the Edit... button at the top of the Access Controls table. The Edit Permissions
page is displayed.
Click Add to add a new access control to the list. A dialog box is displayed.
Choose the desired group or user from the drop-down list.
Select the desired permissions by highlighting the appropriate choices and clicking OK
when finished. The dialog closes, and the new ACL appears in the list area of the folder
Details page.
Read permission is required for Write and Associate access, and Write access is
required in order for Delete access to be granted. You can select any combination of
permissions, but when you save the ACL, it will be modified to be a valid combination of
permissions.
For example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/
Granted, when you click Ok, the displayed permissions will be Granted/Granted/
Granted/Granted. Because users must have Read permissions in order to have Delete
permissions, the Read permission is changed to Granted.
In order to set Read to Denied, Write, Delete, and Associate must also be set to Denied.
Note: If you do not set a specific permission, it will be set to Inherited unless a set
access permission (such as Delete) forces the blank permission to Granted.
For example, if you set a folder ACL for a group to Granted for Read, and leave Write,
Delete, and Associate blank, they will be shown in the UI as Granted/Inherited/
Inherited/Inherited. However, if you set the permissions to Granted for Delete, and left
Read, Write, and Associate blank, the ACL would be displayed as Granted/Granted/
Granted/Inherited, since Delete requires Read and Write permissions.

8.
9.

Repeat steps 5 to 7 for each ACL you want to set.


Once you have finished setting the permissions, click the Access Control link in the
Action menu to return to the Access Control list.

Administering SOX Express

Setting Up Security 18

Editing an Existing ACL


To edit an existing ACL:
1.
2.
3.
4.
5.

Log into SOX Express as a user with the Manage ACLs application permission.
Click the Access Control link on the Action Menu to display the list of access controls.
Click the checkbox next to the folder name and click the Edit button to display the list
of existing ACLs.
Click the checkbox next to the existing ACL you wish to modify and click the Edit button
to display the Edit ACL page.
Select the desired permissions by highlighting the appropriate choices and clicking
Save when finished. The dialog closes, and the updated ACL appears in the list area of
the Access Control page.
Read permission is required for Write and Associate access, and Write access is
required in order for Delete access to be granted. You can select any combination of
permissions, but when you save the ACL, it will be modified to be a valid combination of
permissions.
For example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/
Granted, when you click Ok, the displayed permissions will be Granted/Granted/
Granted/Granted. Because users must have Read permissions in order to have Delete
permissions, the Read permission is changed to Granted.
In order to set Read to Denied, Write, Delete, and Associate must also be set to Denied.
For example, if you set a folder ACL for a group to Granted for Read, and leave Write
and Delete blank, they will be shown in the UI as Granted/Inherited/Inherited.
However, if you set the permissions to Granted for Delete, and left Read and Write
blank, the ACL would be displayed as Granted/Granted/Granted, since Delete requires
Read and Write permissions.

Deleting an Existing ACL


To delete an existing ACL:
1.
2.
3.
4.
5.

Log into SOX Express as a user with the Access Control Lists application permission.
Click the Access Control link on the Action Menu to display the list of access controls.
Navigate the folder tree to display the folder containing the ACL you want to change.
Click the folder name to display the Details page with the list of existing ACLs.
Click the checkbox next to the existing ACL you wish to remove and click the Delete
button to remove the ACL.
Note: If you have broken inheritance for a folder, there will be entries for the
SOXAdministrators and OPAdministrators groups. These ACLs cannot be edited or
deleted.

Administering SOX Express

Setting Up Security 19

Using Groups to Establish User Roles


User groups fulfill three functions - to segregate users into meaningful subsets, to define ACLs
to limit both the range of actions that can be performed on a folders contents, and to limit the
scope of a users activity to a specific folder or set of folders. In this section, we will examine
how groups can be used to separate a set of users into different roles within an organization.

The Core SOX Express Groups


SOX Express has two pre-defined user groups already created as part of the initial installation.
These groups are:

SOXUsers - This group is a container for all users who are part of the SOX Express
application. Every SOX Express user will be a part of this group through inheritance.
The SOXUsers group has a single sub-group - SOXAdministrators.
Note: The SOXUsers group should never be used to set ACLs on any folder. The group
exists for administrative purposes only.

SOXAdministrators - In order to have administrative-level permissions, users must


be part of this group. Administrators can customize reports, create users and groups
through the OpenPages user interface, and assign and modify ACLs. They also have
access to all folders and objects in the SOX Express hierarchy, regardless of ACLs.

Example: Using Groups to Establish User Roles


Widgets, Inc. has decided that they will divide their SOX Express users into four main teams,
each responsible for a different area of their internal controls documentation project. These
four teams are:

The Executive Team. These are people who do not document or modify individual
compliance objects. As a team, they are only interested in viewing the entire internal
controls documentation process as a whole, and quantifying the results. CFOs and
high-level corporate users fall into this category. They need read access to almost all
folders in order to run reports on the documentation project as a whole.
The System Team. This group is responsible for setting up and maintaining the entire
hierarchy of SOX Express compliance objects. They are also the only ones allowed to
modify anything above the control level. In most companies, the IT department or a
sub-set of the central accounting team is responsible for these activities.
The Regional Teams. These groups are responsible for developing, maintaining, and
overseeing the compliance objects for all of the sites within their regions.
The Site Teams. These groups are responsible for documenting the controls for their
sites, as well as uploading test results and control documents.

The Executive and System teams are both based in the Corporate Center, while the Regional
Teams and Site Teams are located in their respective regional and site headquarters.
Although you can have user groups that correspond to the entire team, they are not necessary
when setting ACLs. However, so-called team groups can be helpful for organizational
purposes as well as assigning tasks or other uses. The important groups within each team will
divide the teams according to the level of interaction (Reading, Writing, Deleting, Associating)
they will be allowed, as well as the scope of the folders they can act on. These groups will be
explained in the following sections.

Administering SOX Express

Setting Up Security 20

Using Groups to Limit User Activities


Groups are used in folder ACLs to limit what each group of users can do to the compliance
objects located in the folder. In general, you will want a group of users who are limited to just
viewing the compliance objects, a group who can both view and edit the objects, and another
group who can view, edit, associate and delete the objects.
In the following sections, we will divide each team into subgroups with different access
privileges.

The Executive Team


The Executive team is interested mainly in the overall status of the internal controls
documentation project, and gathers most of their information by running reports on the various
compliance objects and drilling down into the objects via the report links. As such, they only
need read access to objects, but their scope needs to be extremely wide.
Some possible sub-groups of the Enterprise team are:

FinancialOfficers
ExternalAuditors
InternalAuditors

In the case of the Executive Team, the sub-groups are merely organizational in nature.
However, by making them sub-groups of the Executive Team group, you gain the flexibility of
categorizing the Executive users by roles without adding complexity to your ACL definitions.

All of the sub-groups require the same access to the compliance object hierarchy - they only
need Read access in order to run reports and view individual objects from those reports. As an
organizational grouping, the ExecutiveTeam group will not appear in any ACLs directly - rather,
it will be added as a member of many other groups with read-only access.
Once you have created your Executive Team sub-groups, add the appropriate users to each
sub-group. Users should NOT be added directly to the ExecutiveTeam group - add them to a
sub-group instead.

Administering SOX Express

Setting Up Security 21

The System Team


The System team is responsible for creating, maintaining, and expanding the entire hierarchy
of compliance objects and their associations. Of all the teams, they need the widest authority to
make changes to the compliance object structure. However, not everyone on the team needs
the same permissions. Using sub-groups, we can separate the System team into their separate
roles. The sub-groups for the System team are:

SystemReviewers - contains all users responsible for reviewing newly created


compliance objects and reporting errors in setup or descriptions. They require Read
access.
SystemWriters - contains all users responsible for creating and modifying new or
changed compliance objects, and implementing any changes found by the Reviewers.
They require Read, Write, and Associate access to compliance objects.
SystemDirectors - contains all users responsible for making modifications to the
object hierarchy itself, including removing unnecessary compliance objects. They
require Read, Write, Associate, and Delete access.

Since the System team is responsible for modifying the entire object hierarchy, as well as
reports, projects, etc, they also need to be granted access at the highest level in the entity
hierarchy.
Once you have finished creating the SystemTeam sub-groups, add the System users to the
appropriate System user group, depending on their role.
Note: When looking at this group, you might be tempted to add the ExecutiveTeam group to
the SystemReviewer group. After all, they both need Read access to everything - why not? One
small reason - the Library business entity. As the blank template for any new Regions or Sites
that might be created, the SystemReviewers will need access to the Library. The
ExecutiveTeam group, however, does not want access to the Library, since they will not want to
include the Library objects in any reports they run. Dont forget that the scope of what you can
see determines the content of any reports you run. Reports will not include any objects you
cannot view.
Setting up the System team demonstrates the ability to use sub-groups to refine the
permissions and access levels within a specific organization.

Administering SOX Express

Setting Up Security 22

The Regional Teams


Each Regional team (one for each region) is responsible for reviewing and maintaining the
compliance objects that are specific to the sites in their region. In function, they are quite
similar to the System team, but their influence is limited to all of the sites in their region.
The various sub-groups for the Regional teams are actually two levels - first you need an
umbrella RegionalTeams group. Under that group, you need to create sub-groups for each
region.
For example:

Region01Reviewers - responsible for reviewing and reporting on all of the sites in


Region 01. They require Read access to everything in Region 01.
Region01Writers - responsible for making any necessary changes to the compliance
objects in any of the sites in Region 01. They require Read, Write, and Associate access
to everything in Region 01.
Region01Directors - responsible for deleting obsolete compliance objects or defunct
sites in Region 01. They require Read, Write, Associate, and Delete access to
everything in Region 01.

You would create a set of groups for each region in your company (Region02Reviewers,
Region02Writers, etc.). Once you have completed creating a set of groups for each region and
added all of the users from the Regional Teams who belong directly to each group, it is time to
create the groups for each Site.

The Site Teams


Below the Regional level, each Site has its own team of Reviewers, Writers, and Directors. For
each site in each region, you would create a set of sub-groups as follows:

R01Site01Reviewers - responsible for reviewing and reporting on Site 01 in Region


01. They require Read access to everything in Site 01.
R01Site01Writers - responsible for making any necessary changes to the compliance
objects in Site 01 in Region 01. They require Read, Write, and Associate access to
everything in Site 01.
R01Site01Directors - responsible for deleting obsolete compliance objects or defunct
sites in Site 01 in Region 01. They require Read, Write, Associate, and Delete access to
everything in Site 01.

Just like at the Regional level, you would create a set of sub-groups for each site in each
Region. Although by this time we are probably creating a lot of groups, each group will only
have to be declared in an ACL once at the site level.
As you create the Site groups, you can add the users who belong directly to each group. Adding
groups to other groups will be handled in the next section.

Administering SOX Express

Setting Up Security 23

Using Nested Groups to Limit User Scope


By now, you have created dozens and dozens of groups, and you havent actually created any
ACLs! Not to worry - this is where all of those groups come in handy. In this section, we will
nest our groups inside one another, add ACLs to our regions and sites, and break the
inheritance of our business entities to restrict the scope of our users and groups. Lets take the
last one first.

Step One: Breaking Folder Inheritance


The first step in limiting user access to regions and sites is to break the inheritance of all of our
business entity folders - all regions and all sites. Breaking the inheritance sets all of the groups
and users without an ACL (except those with the Access Control Lists application permission) on
the business entity folder to Denied/Denied/Denied/Denied. They cant view, edit, or delete the
folder, create or remove associations, or view any business entity folder underneath it, even if
they have an ACL set on a lower-level folder.
The Read permission is the most important, for Read allows you to see folders underneath the
business entity and navigate down to them. However, with so many Regions and Sites to set
up, we dont want to have to keep Denying access to all sorts of groups.
To set ACLs and break inheritance in the SOX Express user interface:
1.
2.
3.
4.
5.
6.

7.
8.

Log into SOX Express as a user with the Access Control Lists application permission.
Click the Access Control link on the Action Menu and navigate to the business entity
folder where you wish to break inheritance (under the Default directory).
When you have found the desired folder, click the name of the folder to display the
Details page.
Click the Add button in the Access Controls table and choose the desired group or user
from the list.
Choose the desired permissions for the group or user by highlighting the appropriate
entries and click the OK button to add the new ACL to the folder.
Now that a valid ACL exists for the folder, click the Disable Inheritance button under
the Folder heading. The value of the Inherit ACL field is changed to false and the
Disable Inheritance button changes to Enable Inheritance.
Click Access Controls in the breadcrumb trail to return to the Access Controls folder
list.
Repeat this procedure for each business entity folder.
Note: Do not forget to modify the business entity folders under each compliance object
type in the ICDocumentation tree.

Step Two: Nesting Your User Groups


Now you have a lot of groups with users assigned to them according to their role. In this step,
we will add groups to other groups in order to properly restrict their area of effect.
The way groups with users nest seems backwards at first glance - the most general groups (the
System and Executive groups) have to be added to the more limited ones (the Regional
groups), while the Regional groups have to be added to the most limited ones (the Site
groups).
If the Region01Writers group belonged to the SystemWriters group, which can read, write, and
associate to all regions, they would also be able to read and write to all Regions, which is not
the desired behavior. We are trying to limit user scope, not enhance it. So adding smaller
groups to larger groups doesnt work out correctly.
If you add the larger Regional groups to the smaller Site groups beneath them, you dont
increase the smaller groups scope beyond its boundaries, but the Regional groups extend their
vision downwards into all of the sites in their own Region. (Remember, since we broke
inheritance at each level of the business entity, Regional groups dont automatically get to see
the Sites underneath their Region.)
Administering SOX Express

Setting Up Security 24

Heres a diagram that shows the way this works:

Lets follow one use case shown in the preceding diagram. The SystemWriters group becomes a
sub-group to the Region01Writers group (and the Region02Writers group, and so on). Then,
the Region01Writers group becomes a sub-group of the R01Site01Writers group (and the
R01Site02Writers group, etc.). The sub-groups of Region01Writers also become sub-groups of
R01Site01Writers through group inheritance. The effective members list of R01Site01Writers is
now:
R01Site01Writers
<writer1>
<writer2>
...
Region01Writers
(SystemWriters)
In the above example, SystemWriters is in parenthesis, because it isnt explicitly added to the
group - its included as a sub-group of the RegionalXXWriters groups. The same goes for the
ExecutiveTeam group; it is added to each of the RegionXXReviewers groups. Executives only
need Read access, so we dont need to add them to any other ACL classification.
Note: If you are using the Library paradigm, you do not want to add the ExecutiveTeam group
to the Library group. You dont want empty Library data included into the executive level
reports.
Now lets explore how we can use our nested groups to set our ACLs.

Step Three: Setting Folder Access Control Lists


Now that we have user groups with different permission needs for each site, we can start
creating our ACLs. For each Site, we create an ACL for each R##Site## group and give them
the necessary permissions. For example, in R01Site01, the ACLs for the business entity folder
would look like this:

Administering SOX Express

Setting Up Security 25

We dont need to specify the Region01Reviewers, Writers, or Directors - they are already
included as members of the R01Site01 groups!
In general, you only need to specify ACLs for different access control levels (Read, Write,
Delete, Associate) for business entity folders that contain non-business entity compliance
objects. For example, in our hierarchy, Regions only contain the sub-entity Sites - there are no
accounts, processes, etc. directly associated with a Region. Therefore, we dont have to create
ACLs for Region01Reviewers and the other ACL-specific groups at the Region level. In our
current example, heres the ACL list for Region01:

Heres are some general guidelines for whether or not to create an ACL for a user group on a
business entity:

If the business entity has accounts or processes associated with it, you need to create
an ACL for each entity-specific group (such as R01Site1Writers, etc.) with the correct
privileges.
When you create ACLs for a business entity, you must replicate the ACL for each
business entity folder underneath the ICDocumentation folder structure. For example,
you must create the same ACL list for the ICDocumentation/Accounts/Region01/
R01Site01 folder that you created for the BusinessEntities/Region01/R01Site01 folder,
and so on through each sub-folder structure under ICDocumentation (Accounts,
Processes, Risks, Controls, etc.).
Note: If no folder with the correct name exists, either there is no compliance object of
that type currently in the business entitys hierarchy, or a parent folders ACLs do not
include a group that contains the current user, preventing you from seeing the folder.

If a business entity only has sub-entities associated with it, you should not create
individual ACLs for the business entitys Reviewer, Writer, and Director groups. We will
deal with this in the next section,

Only one step remains - weve created the ACLs for our business entities, but when you log in,
you can only see the first level of your business entities! We now need to establish read
permissions in the business entities above our Site user groups, so that we can browse down to
the Site level and view our compliance objects.

Administering SOX Express

Setting Up Security 26

Using Group ACLs to Traverse Business Entities


Even though we have successfully created a nested series of groups that successfully limits the
scope of our site users, we seem to have gone a little too far - we cant browse through the
business entities to get to our site! We need to create a group that will allow site users to
browse through the entities, without granting anything but Read.
To allow Read access to lower-level user groups:
1.
2.
3.

4.
5.
6.

Log into SOX Express as a user with Administrative privileges.


Click the Users / Groups link in the Action menu to display a list of the available
groups and users.
Create a new group at the Region level (actually, at any level above the lowest, if you
have more than two levels). Call the new group Region01Browsers, because thats what
its purpose will be - to allow users from the entities below it to browse down to their
site.
Create a similar group for each business entity above the lowest level (Site, in our
example).
Click the Access Controls link in the Action menu and navigate into your business
entity folder structure (under \Default\BusinessEntities).
Create an ACL on Region01 and grant Region01Browsers Read access. Repeat this with
Region02Browsers in the Region02 business entity folders, and so on in any other
Regions youve created.
In order to not make the Browsers groups unwieldy, well need to roll-up each sites
users into a single group that can be added to the Region01Browsers group.

7.

Add the R01Site01Directors and R01Site01Writers group to the R01Site01Reviewers


group.
8. Add the R01Site01Reviewers group to the Region01Browsers group. This has the effect
of adding all of the R01Site01 groups to the Browsers group, even though you only
added one.
9. Repeat the process for the rest of the business entities.
10. If you have more than one level above your lowest level, you will need to link the
Browsers groups together, creating a chain to the highest level of business entity.
For example, if we had top-level business entities called Country01, etc., we would
create a group called Country01Browsers, and add the Region01Browsers group to it.
However, if Region02 was not a child of Country01, you would not add
Region02Browsers to the Country01Browsers group.
11. Once the groups have been added, log out and log back in with a Site level user and
test that the ACLs are working correctly.

Administering SOX Express

Setting Up LDAP User Authentication 27

Setting Up LDAP User Authentication


Overview of LDAP Authentication
SOX Express supports the use of an LDAP authentication server to control user access. This
section details the configuration steps required to integrate SOX Express with an LDAP data
source.
Only one login module can be active at the same time. The underlying Openpages platform
supports a single namespace, so all users must be authenticated through the same data
source. Multiple authentication modules cannot be used at the same time.
Any users that are created or imported into SOX Express must also be present in the LDAP
authentication server. It is the responsibility of the person managing the SOX Express users to
maintain the correlation between the SOX Express user list and the external LDAP data source.
If a user is disabled on the SOX Express server, they must be manually disabled on the LDAP
Directory server.
Note: If an LDAP Directory Server is being used for user authentication, the Change
Password button will be disabled in the SOX Express user interface. When an LDAP server is
used, passwords are not maintained in SOX Express. The password must be changed directly in
the LDAP server.

Supported LDAP Servers


SOX Express has been certified for use with the following LDAP servers:

Microsoft Active Directory


Sun One Directory Server (formerly known as iPlanet Directory Server)

Configuring the LDAP Authentication Module


To successfully use an LDAP Directory Server with SOX Express, you must configure the LDAP
Authentication Module to recognize the presence of the LDAP server. This is accomplished by
completing the following steps:

Adding the necessary users to the LDAP server


Changing the OPSystem password (optional)
Modifying the LDAP configuration file

The following sections will detail the steps required to configure SOX Express to work with an
external LDAP authentication source.

Step One: Adding Existing Users to the LDAP Server


Please refer to your LDAP Directory Server documentation for the steps required to add SOX
Express users to the LDAP server.
All users that will need access to the SOX Express or OpenPages platforms must be added to
the LDAP authentication server. In addition, the following users will need to be added to the
LDAP server:

OPSystem
OPAdministrator (only if you are using this account)
SOXAdministrator (only if you are using this account)

Note: If you specify a password for the OPSystem account that is different from the one
installed by the product, you will need to complete Step Two to change the OPSystem account
password system-wide.

Administering SOX Express

Setting Up LDAP User Authentication 28

Step Two: Changing the OPSystem Password (optional)


If the OPSystem password on the LDAP server does not match the one installed by SOX
Express, you will need to change the OPSystem password using the provided tool.
To change the OPSystem password:
1.
2.

Start all services.


Run the following batch file:
<WL_HOME>/aurora/bin/chng-sys-pswd.bat
<WL_HOME> is the home directory for your WebLogic installation. By default, this
location is c:\bea\weblogic81.
You will be prompted for the old OPSystem password and then the new password.

3.

Open and edit the <OP_WORKFLOW>\bin\twf.ini file.


<OP_WORKFLOW> is the Workflow directory of your SOX Express installation. By
default, this location is c:\OP_Workflow.

4.
5.
6.

Find the line that contains the TWFServerPassword property and change the value to
the new OPSystem password.
Save your changes and exit.
Restart all services in order to enable the new password.

Step Three: Editing the LDAP Configuration File


Finally, you must modify the authentication configuration file to enable the LDAP Directory
Server you are using.
The aurora_auth.config file contains three authentication modules:

Openpages - the default internal user directory


OpenpagesIP - the LDAP configuration for the Sun One Directory Server
OpenpagesAD - the LDAP configuration for the Microsoft Active Directory Server

The only module that Openpages pays attention to is the module named Openpages.
Therefore, in this step we will modify the configuration file to change the name of the correct
LDAP authentication server module to Openpages, and then change the settings to reflect the
settings of your LDAP server.
To modify the configuration file:
1.
2.
3.
4.

Stop all OpenPages, SOX, and i-Flow services.


Open and edit the <WL_HOME>\aurora\conf\aurora_auth.config file in a text editor.
Find the module named Openpages and change the name to OpenpagesDefault
(without the quotes).
Depending on the LDAP server you intend to use, modify either the OpenpagesIP or
OpenpagesAD module name to Openpages (again without the quotes).
If you are using a Microsoft Active Directory server, change the OpenpagesAD module.
If you are using a Sun One Directory Server, change the OpenpagesIP module.

5.

Specify the correct values for the following properties in the appropriate module:
provider.url - Change the value to the hostname and port number for the LDAP
authentication server.
base.dn - The top level of the LDAP directory tree structure (Domain Name) on
the LDAP server. If the users to be authenticated are located in multiple
locations within your Active Directory structure, you will need to list all of the
locations explicitly by using the distinguished names of the locations, each
separated by a semi-colon.

Administering SOX Express

Setting Up LDAP User Authentication 29

For example:
base.dn="DC=LDAPTesting,DC=local;CN=Users,DC=LDAPTesting,DC=local;
OU=Auditors,OU=External Auditors,OU=Staff,DC=LDAPTesting,DC=local"
user.attr.id - the attribute name of the user identifier (for example, uid, cn,
etc.)
Additional custom parameters can be added by preceding them with the prefix
ctx.env. (without the quotes).
For example, when using the Sun One Directory Server:
OpenpagesIP
{
com.openpages.aurora.service.security.namespace.LDAPLoginModule
required debug=false
provider.url="ldap://192.168.0.169:30429"
security.authentication="simple"
base.dn="DC=LDAPTesting,DC=local;OU=People,DC=LDAPTesting,
DC=local"
user.attr.id="uid"
ctx.env.your.param="paramvalue"
;
};
An example when using the Microsoft Active Directory server:

6.
7.

OpenpagesAD
{
com.openpages.aurora.service.security.namespace.LDAPLoginModule
required debug=false
provider.url="ldap://192.168.0.165:389"
security.authentication="simple"
security.search.user.dn="CN=Paul Smith,CN=Users,DC=LDAPTesting,
DC=local"
security.search.user.credentials="openpages"
base.dn="CN=Users,DC=LDAPTesting,DC=local"
user.attr.id="sAMAccountName"
;
};
When you are finished editing the file, save your changes and exit.
Restart all services.

Congratulations! You have configured the SOX Express system to use an external LDAP user
authentication server.

Administering SOX Express

Configuring Password Encryption 30

Configuring Password Encryption


Overview
SOX Express contains the ability to modify the encryption algorithm used to encrypt the SOX
Express user passwords. The tool used to modify the encryption is called the
UpdatePasswordEncryptionAlgorithm tool, hereafter referred to as UPEA.
The UPEA tool supports two algorithms - the default encryption algorithm called OP-CUSTOM,
and the Triple DES (3DES) algorithm.

About the UPEA Command File


The UPEA tool is a command file named UpdatePasswordEncryptionAlgorithm.cmd, located in
the <WL_HOME>\config\OpenpagesDomain directory of your SOX Express installation. The
UPEA tool can be used to:

Change the encryption algorithm from OP-CUSTOM to 3DES


Change the encryption algorithm from 3DES to OP-CUSTOM
Change the 3DES encryption key.

Note: When changing the encryption algorithm to 3DES, all user passwords will be reset to
0p3nP4g3s (first character is a zero), and users will need to change their passwords the next
time they log into the system. When changing the encryption algorithm from 3DES to OPCUSTOM, all passwords are unchanged.

Pre-requisites
The following tasks must be completed before running the UPEA tool.

There must be a properly installed and functioning SOX Express 3.0.4 system on the
machine.
All users must log off the system
A full backup of the OP/SOX database must be completed
All SOX Express services should be shut down except for OPAdminWLS. This ensures
that no users are logged onto the system during the password encryption update.

UPEA Syntax
UpdatePasswordEncryptionAlgorithm -Mode [CA|CK] -AlgorithmName [OP-CUSTOM|3DES]
[-ProviderName SunJCE -ProviderClass com.sun.crypto.provider.SunJCE] -Username
OPAdministrator -Password <OPAdministrator password> [-KeySize <length> ][-Port
<portnumber>] [-?]
Parameters:

Parameter
-Mode

Description
Specifies in which mode the tool should run. Possible modes
are:
CA - Change Algorithm Used to switch the encryption
algorithm from OP-CUSTOM to 3DES or 3DES to OP-CUSTOM
CK - Change Key Used to change the 3DES encryption key.

-AlgorithmName

Specifies which encryption algorithm will be put into use.


Valid values are OP-CUSTOM and 3DES.

-ProviderName

Used when changing algorithms to the 3DES encryption


algorithm only. Has only one valid value: SunJCE.

Administering SOX Express

Configuring Password Encryption 31

Parameter

Description

-ProviderClass

Used in conjuction with -ProviderName to specify the class for


the new encryption algorithm. Has only one valid value:
com.sun.crypto.provider.SunJCE.

-Username

Specifies the username to use when modifying the user


passwords. Must be OPAdministrator.

-Password

The password to the OPAdministrator account.

-Port

Optional parameter to be used only if the OpenPages


(OPAdminWLS) port has been changed from the default value
of 7001. If so, the value of -Port should be the new port
number.

-KeySize

Specifies the length of the 3DES encryption key. The smallest


valid length is 112. If an invalid value is given, or no value is
provided, the default is the smallest valid size.

-?

Displays the onscreen help for the UPEA tool.

Changing the Password Encryption Algorithms


Note: Only the OPAdminWLS service should be running when using the UPEA tool.
To change the encryption algorithm from OP-CUSTOM (the default) to 3DES:
1.
2.

Log into the application server as a user with Administrative privileges.


Open a command window and change directories to the <WL_HOME>\config\
OpenpagesDomain directory (where <WL_HOME> is the directory where you installed
the BEA WebLogic server. <WL_HOME> defaults to c:\bea\weblogic81.
3. Type in the following command (on a single line) and execute it:
UpdatePasswordEncryptionAlgorithm -Mode CA -AlgorithmName 3DES -ProviderName
SunJCE -ProviderClass com.sun.crypto.provider.SunJCE -Username OPAdministrator Password <password> [-KeySize <length>]
where <password> is the password for the OPAdministrator account.
Note: If you have changed the default port for OpenPages to a port other than 7001,
add the -Port parameter to the end of the command with the new port number.
4.
5.
6.
7.

The tool will display a message describing the changes it will make and ask for
confirmation. Type Y at the prompt and hit Enter to proceed.
Once the UPEA tool has finished, a success message will be displayed.
Restart all SOX Express services.
You (or the site administrator) must notify all users that their passwords have been
reset to 0p3nP4g3s, and that they will need to change their passwords the next time
they log into the system.

To change the encryption algorithm from 3DES to OP-CUSTOM:


1.
2.

Log into the application server as a user with Administrative privileges.


Open a command window and change directories to the <WL_HOME>\config\
OpenpagesDomain directory (where <WL_HOME> is the directory where you installed
the BEA WebLogic server. <WL_HOME> defaults to c:\bea\weblogic81.
3. Type in the following command (on a single line) and execute it:
UpdatePasswordEncryptionAlgorithm -Mode CA -AlgorithmName OP-CUSTOM -Username
OPAdministrator -Password <password>
where <password> is the password for the OPAdministrator account.
Note: If you have changed the default port for OpenPages to a port other than 7001,
add the -Port parameter to the end of the command with the new port number.
Administering SOX Express

Configuring Password Encryption 32

4.
5.
6.

The tool will display a message describing the changes it will make and ask for
confirmation. Type Y at the prompt and hit Enter to proceed.
Once the UPEA tool has finished, a success message will be displayed.
Restart the SOX Express services.

Changing the 3DES Encryption Key


At certain times, you may wish to change the encryption key used by the 3DES encryption
algorithm. To change the encryption key:
Note: Only the OPAdminWLS service should be running when using the UPEA tool.
1.
2.

Log into the application server as a user with Administrative privileges.


Open a command window and change directories to the <WL_HOME>\config\
OpenpagesDomain directory (where <WL_HOME> is the directory where you installed
the BEA WebLogic server. <WL_HOME> defaults to c:\bea\weblogic81.
3. Type in the following command (on a single line) and execute it:
UpdatePasswordEncryptionAlgorithm -Mode CK -AlgorithmName 3DES -Username
OPAdministrator -Password <password>
where <password> is the password for the OPAdministrator account.
Note: If you have changed the default port for OpenPages to a port other than 7001,
add the -Port parameter to the end of the command with the new port number.
4.
5.
6.

The tool will display a message describing the changes it will make and ask for
confirmation. Type Y at the prompt and hit Enter to proceed.
Once the UPEA tool has finished, a success message will be displayed.
Restart the SOX Express services.

Administering SOX Express

Working with Reports 33

Working with Reports


SOX Express contains a set of reports that allow users with the correct permissions to quickly
view and organize information about the current state of your Internal Controls Documentation
project. For example, users can quickly view information grouped by user, by location, or view
all controls that are ineffective or are incompletely documented.

Viewing Reports
Reports are accessed through the Reports link in the left-hand Action menu when you are
logged in to SOX Express. If you do not see the Reports link, your account does not have the
necessary privileges to view reports. If you feel that this is in error, please contact your SOX
Express Administrator for additional information.
To view a report:
1.

After logging in to SOX Express, click on the Reports link in the left-hand Action menu.
A page listing all of the available reports is displayed.

2.

Choose the report you wish to view and click the name of the report. A new window is
displayed.
If the report is scoped, you will be prompted to choose the business entity where you
want the report to run from. The report will use the selected business entity as the
starting point and limit the scope of the report to all compliance objects contained
below the entity.
If the report is not scoped, it will run as soon as you click the name of the report.

3.

4.

When you select a report to view, the report is generated in direct response to your request.
This allows you to see up-to-the-minute status of your IC documentation project.

Administering SOX Express

Working with Reports 34

Supplied Reports
Sarbanes-Oxley Express comes with a selection of pre-defined reports that allow you to quickly
view important information about your project. SOX Express contains the following supplied
reports (in alphabetical order):
Reports that are scoped by default are listed in italics.

Report Name

Description

Accounts by Category

Lists all accounts under the selected business entity grouped


by category.

Ad Hoc Tests

Lists all tests where the testing frequency is set to Ad Hoc.

All Documentation

Lists all of the control documentation contained in the selected


business entity.

All Tests

Lists all tests and their associated controls under the selected
business entity.

Annual Tests

Lists all tests where the testing frequency is set to Annually.

At Risk Action Items

Lists all actions due in the next week that are less than 50%
complete.

Audit Overview

Lists all modified compliance objects during a particular time


period. You must have the Audit Trail application permission to
view this report.

Business Entity Survey

Lists the Internal Controls Assessment surveys completed for


Business Entities (if survey reports are loaded).

Checked Out Files by Date

Lists all associated files that have been checked out from the
repository by their check out date. Dates are sorted in
ascending order from oldest to most recent. You must have the
Cancel Checkout application permission to view this report.

Checked Out Files by File


Name

Lists all associated files that have been checked out from the
repository by file name for the specified reporting period. You
must have the Cancel Checkout application permission to view
this report.

Checked Out Files by Full


Path

Lists all associated files that have been checked out from the
repository by full path name for the specified reporting period.
You must have the Cancel Checkout application permission to
view this report.

Checked Out Files by User

Lists all the users who have files checked out from the
repository for the specified reporting period. You must have
the Cancel Checkout application permission to view this report.

Control Analysis

Process-centric view of Controls

Control Signoff by Business


Entity

Lists for each business entity the number of controls that are
Unsigned, Signed, and Revoked, along with a summary of the
percent of controls signed off for each entity.

Control Signoff by Process

Lists for each process the number of controls that are


Unsigned, Signed, and Revoked, along with a summary of the
percent of controls signed off for each process.

Controls - Account
Dashboard

Lists the number of controls for each account that are


Effective, Ineffective, or Undetermined. Also denotes
Progress - what percentage of controls for the account are
marked Effective.

Administering SOX Express

Working with Reports 35

Report Name

Description

Controls - Business Entities


Dashboard

Lists the number of controls for each business entity that are
Effective, Ineffective, or Undetermined. Also denotes
Progress - what percentage of controls for the account are
marked Effective.

Controls - Processes
Dashboard

Lists the number of controls for each process that are


Effective, Ineffective, or Undetermined. Also denotes
Progress - what percentage of controls for the account are
marked Effective.

Controls by Location

Lists all controls in the current project, grouped by location.

Controls by Performer

Lists all controls, grouped by the person responsible for the


control.

Daily Change Report

Lists the changes made to all compliance objects within the


last 24 hours. You must have the Audit Trail application
permission to view this report

Disassociated Objects by
Name

Lists all compliance objects with no parent for the specified


reporting period. Disassociated object names are sorted in
ascending order.

Disassociated Objects by
Path

Lists all compliance objects with no parent by full path name


for the specified reporting period. Path names are sorted in
ascending order.

Export Business Entities

Exports the selected business entities (with their associated


compliance objects) to XML format for import into a reporting
database.

High priority new Issues

Lists all current issues with status of New and priority of High.

Incomplete Action Items

Lists all action items that are not 100% complete.

Incomplete Documentation

Lists all project entities that do not have sufficient


documentation under the selected business entity.

Ineffective Controls

Lists all ineffective controls under the selected business entity.

Issues and Action Items

Lists all issues and incomplete action items

Issues by Assignee

Lists all issues grouped by the user to which they are assigned.

Issues by Status

Lists all issues grouped by their current status.

Milestones

Lists all milestones and project tasks for the current project.

Monthly Tests

Lists all tests where the testing frequency is set to Monthly


under the selected business entity.

My Tests - Performer

Lists all tests that are performed by the current user.

My Tests - Reviewer

Lists all tests that are reviewed by the current user.

Overdue Action Items

Lists all action items less than 100% complete and past their
due date.

Process Surveys

Lists the Internal Controls Assessment surveys completed for


processes.

Process Tree

Lists all processes and their risks and controls

Processes Signoffs by
Business Entity

Lists for each process the number of controls that are


Unsigned, Signed, and Revoked, along with a summary of the
percent of controls signed off for each process.

Administering SOX Express

Working with Reports 36

Report Name

Description

Quarterly Tests

Lists all tests where the testing frequency is set to Quarterly


under the selected business entity.

Signoffs - Business Entity


Dashboard

Lists whether the Primary and Executive Owners have signed


off on each business entity.

Signoffs - Processes
Dashboard

Lists whether the Primary and Executive Owners have signed


off on each process.

Test Notifications

Creates action items and sends e-mails to notify users who


have Tests without Test Results. Can be run manually

Top-level Processes

Process-centric view of processes and their account and


business entities.

Undetermined Controls

Creates Action Items and e-mail messages to notify users who


have Controls assigned to them that are not marked as
Effective or Ineffective. Can be run automatically or manually.

Understanding Reports
Reports are generated by combining Report Pages and Report Page Templates that provide
necessary information about the filtering and sorting of the report contents, as well as the
displayed name and description of the report.
Reports are represented in a publishing channel by a page template which lists the parameters
that the source file needs in order to create a report. A Report Page contains a set of values for
the parameters specified in the Report Page Template.
In this manner, a single Report Template can be supplied with multiple sets of values for its
parameters. This allows SOX Express to create multiple reports based on the same layout and
internal logic. Each Report Page represents a report as viewed in the SOX Express application.
These report files are contained inside the OpenPages repository. The OpenPages repository
handles the data storage and access capabilities for the SOX Express application. In order to
create, modify, or delete SOX Express reports, you must have an SOX Express account with
permission to modify publishing channels. If you are not sure whether you have access to this
functionality, please see your SOX Express Administrator for additional information.

Accessing the Report Pages and Page Templates


Once you have successfully logged in to OpenPages, complete the following steps to view the
existing report files:
1.

Click on the Browse channels link under the Publishing heading in the left-hand
Action menu. This displays a list of the available publishing channels.
Note: If you cannot see the Publishing heading, you do not have the correct
permissions. See your SOX Express Administrator.

2.

Click the Reporting folder, then the SOX folder. A list of files and folders is displayed.
Each folder represents a report grouping in the SOX Express user interface. Each
Page file represents a SOX Express report.

Administering SOX Express

Working with Reports 37

Creating a New Instance of a Report


To create a new instance of a report, you must create a new Report Page based on a copy of an
existing Report Page Template. The new Report Page will show up in SOX Express as a new
report.
To create a new report:
1.
2.

Log in to the OpenPages web application as a user with the correct Reporting privileges.
Determine which existing report you want to use as the basis for your new report.
For example, if you want to add a new report that is a slightly tweaked version of the
existing Control Analysis report, you would want to use the report template that the
Control Analysis report is based on.

3.

Click on the Browse channels link in the Action menu and find the report you want to
create a modified version of. The SOX reports are listed in folders under the Reporting/
SOX directory.
4. Click the name of the report to view the Details page of the report.
5. Note the value of the Template field. You will need to make a copy of the referenced
template.
6. Click on the Browse Files link in the Action menu and navigate to the Reports folder.
7. Create a new folder under the Reports folder.
8. Navigate under the Reports/SOX folder structure and find the JSP with the same name
as the Template field you just saw.
9. Click the checkbox next to the JSP name and click the Copy To... button.
10. Choose the directory you created in step 7 and click OK to create a copy of the report
template in the target folder.
11. Click on the Browse channels link in the Action menu.
12. Navigate to the folder under the Reporting/SOX folder where you wish your report page
to be created.
Reports placed in the Reports/SOX folder will be displayed in the SOX Express report
list under the heading General Reports. If you wish to create a new heading for your
custom reports, create a new folder underneath the SOX folder.
For example, to create a new report grouping titled My Custom Reports on the
Reports page in SOX Express, create a folder in OpenPages and name it My Custom
Reports. Any reports you create in that folder will appear under that folder structure
on the Reporting page in SOX Express.
13. Click the Add Page button at the top of the window. The Describe page step is
shown.
14. Enter an informative name and description for the page. Make sure they accurately
describe the contents of the report. Note: You will not be able to change the name of a
report after it is created. You will have to delete the report and create a new one to
name the report something else.
15. Select the page template you will use to create the report. Each page template has a
different set of parameters that the report can sort and filter.
Choose the copied template you just created and click Next.
16. Depending on the page template you chose, you will now have to enter the sorting and
filtering information for the report. Supply the required information for the report and
click Apply. After you have applied the modifications, click Finish to create the new
report.

When you log into SOX Express, your report should be visible on the Report page.

Administering SOX Express

Working with Reports 38

Modifying an Existing Report Template


Important Note: If you wish to modify one of the supplied report templates for your own
purposes, you must copy the source JSP and report template to a new location outside the SOX
folder structure, and then modify the copied template. Otherwise, you will risk losing your
changes when upgrading to a newer version of SOX Express.
Occasionally, you may wish to modify one of the reports you have created. In order to modify
an existing report:
1.
2.
3.
4.

After logging into OpenPages, click on the Publishing heading in the left-hand Action
menu.
Navigate to the report you wish to modify and click on the report name to display the
Details page.
Find the section containing the information you wish to change, and click the Edit...
button above the section. An editable version of the information is displayed.
Change the desired settings. If you are changing the parameter sorting information,
you will need to click Apply before clicking Save.
Note: You cannot modify the name of a report. In order to change the name of a
report, you must delete the mis-named report and create an identical report with the
new name.

5.

The modified information is saved and immediately applied to the report.

Deleting a Report
To delete an existing report:
1.
2.

After logging into OpenPages, click on the Publishing heading in the left-hand Action
menu.
Navigate to the report (page) you wish to delete and click the checkbox next to the
report name.
Note: Do not delete a page template! If a page template is deleted, all reports (pages)
based on that template are deleted as well.

3.
4.

Once the report is selected, click the Delete button at the top of the table. A
confirmation dialog is displayed.
Click OK to delete the report.

Creating Interactive Reports


Overview
SOX Express now allows administrative-level users with the option to create interactive reports
that prompt the user at run-time for parameter values. This section explains how to modify
newly-created and existing reports to prompt the user for needed information.

Creating an Interactive Report


You can either modify an existing report to be interactive, or specify an interactive parameter
during report creation. In either case, follow the procedure below to create an interactive
report.
1.
2.

Log in to OpenPages as a user with the application permissions to create and modify
reports.
Click the Browse channels link in the Action menu and navigate to the page template
for the report you wish to modify.

Administering SOX Express

Working with Reports 39

3.
4.
5.
6.
7.

Click the name of the report template (page template) you wish to modify. The Details
page is displayed.
Click the Edit... button above the list of report parameters. The Edit Parameters applet
is displayed.
Click the name of the parameter that you wish to make interactive. The parameter
information is displayed at the bottom of the page.
Click the checkbox marked Interactive Value and click the Apply button on the righthand side of the page.
Repeat steps 5 and 6 for each parameter you wish to make interactive. When you are
finished, click the Save button at the bottom of the page.

The next time the report is run, the user will be prompted to enter a value for each field marked
as an interactive value.
Note: Reports with an interactive parameter named label are a special case and will not
display a dialog to enter a value for label. The label field is included to support reporting
periods and should not be modified.
Although any parameter type can be made an interactive value, at this time SOX Express only
supports three modes of entering values into the value fields when the report is run. The three
supported types are text entry fields, enumerated drop-downs, and file browsers. Unsupported
types may still be marked as interactive, but the value for the field must be entered manually
via a text string at run-time. A valid value must be entered into the value field for the report to
return the correct set of information.

Running an Interactive Report


To run an interactive report:
1.
2.
3.

Click on the Reports link in the SOX Express Action menu. A list of available reports is
displayed.
Navigate to the report you wish to run and click on the name of the report. If the report
contains interactive parameters, a dialog is displayed.
Enter the required information into the text fields.
Note: Although any parameter type can be made an interactive value, at this time SOX
Express only supports three modes of entering values into the value fields when the
report is run. The three supported types are text entry fields, enumerated drop-downs,
and file browsers. Unsupported types may still be marked as interactive, but the value
for the field must be entered manually via a text string at run-time. A valid value must
be entered into the value field for the report to return the correct set of information.

4.

After all of the required information has been entered, click the Next button to
generate the report based on the supplied information. The report is displayed in a new
window.

Administering SOX Express

Limiting the Report Scope 40

Limiting the Report Scope


About the Report Scoping Wizard
Overview
Sarbanes-Oxley Express (SOX Express) contains a reporting tool called the Report Scoping
Wizard. Once configured, the scoping wizard allows users to easily run existing reports against
a limited set of data (a selected business entity hierarchy) without having to tailor a separate
report for each business entity.
The benefits of using the Report Scoping Wizard are diverse - first, you reduce reporting
response time by reducing the amount of data that needs to be accessed by the report. Second,
you allow a single report to take the place of multiple business-entity specific reports. Before
the scoping wizard, you would have had to create a copy of a report (such as All
Documentation) for each specific business entity if you wanted to limit the report scope to just
that entity hierarchy. Third, you can let your business users select their own scope for their
reports, and not have to read their minds to determine the reports they want.
This guide contains the following sections:

About the Report Scoping Wizard (this section)


Configuring the Report Scoping Wizard
Using the Report Scoping Wizard

Usage Example
Note: The following example assumes that the Report Scoping Wizard has been installed and
that the All Documentation report has been configured to use the wizard.
A district manager logs into SOX Express and decides to run the All Documentation report to
find out how the internal controls documentation project is progressing for his district. Clicking
on the All Documentation report, he is presented with a hierarchical list of the available toplevel business entities to which he has access. He navigates the list of entities and selects the
sub-district he is interested in and runs the report. The displayed information is automatically
restricted to the sub-district he chose.

Configuring the Report Scoping Wizard


Overview
After you have installed the Report Scoping Wizard files, you must configure the behavior of the
scoping tool. This is accomplished by editing two parameters of the Scope Wizard page, as
detailed in the following section.

Configuring the Scope Wizard


To configure the scoping wizard, you must:
1.
2.
3.
4.
5.
6.

Log in to the OpenPages application as a user with Publishing permissions.


Click the Browse Channels link in the Action menu.
Navigate to the Reporting\SOX Sub Reports\Scope Wizard directory.
Click on the name of the Scope Wizard page to display the Details page.
Click the Edit... button above the Parameters section. An editable list of parameters is
displayed.
The only two parameters which need to be set are the first two parameters. The other
parameters are used by the system and should not be modified.

Administering SOX Express

Limiting the Report Scope 41

Setting the Level to run report at Parameter


The first parameter is Level to run report at. The value of this parameter determines at which
level of the business entity hierarchy the report will run.
For example, if your business entity hierarchy is set up as:
Corporate Entity
Eastern Division
East Region 1
East Region 2
Western Division
...
Corporate Entity would be Entity Level 1, Eastern/Western Division would be Entity Level 2, and
the Regions would be Entity Level 3.
In the above example, if you set Level to run report at to be 2, as soon as the user running
the report chooses a Level 2 entity, such as Eastern Divison, the report would run on the
contents of that entity.
Setting the Level to run report at to 3 would trigger a report when the user selects East
Region 1 or any other level 3 business entity.
Note: This parameter is global - all reports run through the Scoping Wizard will share the same
value. Currently, you cannot run different reports at different levels using the Scoping Wizard.

Setting the Run Immediately at Parameter


The other setting for the Report Scope Wizard is the Run immediately at parameter. This
parameter allows users to set a specific top-level business entity which, if selected at report
run-time, will automatically trigger a report.
To extend the example above, if another top-level entity were named Master Library, entering
the matching string Master Library into this parameter would cause the report to be
immediately run when the Master Library were selected.
This setting overrides the Level to run report at parameter for the business entity named in
the string. The name of the business entity must match exactly.

Using the Report Scoping Wizard


Overview
Once the Report Scoping Wizard template is installed, you must decide which reports you wish
to configure to use the scoping template. In general, the scoping template is most useful for
segmenting reports that return a great deal of data, such as the All Documentation report.
It can also be useful to scope (interactively limit) reports where users are only interested in a
portion of the results (those sections that apply only to their own division or direct reports). The
criteria for determining which reports you will scope depends on your business practices, and
will change from installation to installation.
Regardless of the scope applied to a report, the report will still be limited by the access rights of
the user running the reports. Objects within the scope of the report that the user does not have
the proper access rights to will not be included in the report.

Administering SOX Express

Limiting the Report Scope 42

Scoping a Report
To create an interactive report that will be scoped when the report is run, you must complete
the following tasks:

(optional) Hide the original report.


Make the report interactive
Create a new report based on the scope wizard

Step One: Hide the Original Report


Note: You only need to hide the original report if you do not wish users to be able to run the
original report against the full dataset.
To hide the original report (the un-scoped version):
1.
2.
3.
4.
5.

Log in to the OpenPages application as a user with the proper Publishing permissions.
Click the Browse Channels link in the Action menu.
Navigate the channel folders and find the report page for the report you wish to hide.
Click the name of the page and note the template on which the report is based.
Move the page and the template it is based on to the Reporting\Hidden Reports channel
folder.
Note: If any other pages use the report template you are moving, you must also move
the other pages based on the template. Page templates and pages must maintain the
same relative locations to one another. If necessary, you can create sub-folders under
the Hidden Reports folder.

Step Two: Edit the Report Template


Once you have moved the report and its template to the Hidden Reports folder (or not), you will
need to edit the report template and make the scope parameter interactive.
To do this:
1.
2.

Find the template for the report you are scoping.


On the Details page, click the Edit... button on the Parameter Information table. This
displays the parameters included in the report template.
3. In the list of parameters, click the Scope parameter. The details of the parameter are
shown.
4. Click the checkbox next to Interactive Value and click the Apply button on the right.
5. Click Save to save your changes.

Step Three: Create the Scoped Report


Once you have edited the report template, you must create a new report based on the Scope
Wizard template. This new report will take the settings of the scope wizard and apply them to
the report template you modified in Step Two.
To create the scoped version of the report:
1.
2.

In the original location of the report you want to scope, click Add Page....
Type in the name of the new report and select the Scope Wizard Template as the report
template. Click Next to continue.
Note: If you have moved the original report to a new location (such as Hidden
Reports), you can name the new report the same name as the original. If you did not
move the original report, you will have to choose a different name.

3.

Click Browse... and select the report (pagespec) you want to scope. Click Apply to
modify the parameter, and Finish to create the new report.

You can now log in to SOX Express and run the new report.

Administering SOX Express

Managing Reporting Periods 43

Managing Reporting Periods


Overview of Reporting Periods
A reporting period is a snapshot of the current state of the repository, usually created when
the documentation phase of a quarter or year is complete and ready for attestation.
Administrators with the Reporting Periods application permission can create, modify, and delete
reporting periods.
Past reporting periods can then be viewed and reported on from any time in the future without
rolling back the changes made to the repository after the reporting period was created.
Once a reporting period is created, the existing IC documentation is carried forward to the
current reporting period and can be modified in a normal fashion without altering the state of
the earlier reporting periods data.
Once created, the contents of a reporting period cannot be altered. Any changes to the
compliance objects or files will only be reflected in the current reporting period.

Creating a New Reporting Period


To create a new reporting period, you must have the Reporting Periods application permission.
1.
2.
3.

Click on the Reporting Periods link in the left-hand Action menu. The Reporting
Periods page is displayed.
Click on the Add button at the top of the page. A new page is displayed.
Enter the necessary information into the correct fields and click Create to create the
new reporting period. You are returned to the Reporting Periods page and the new
reporting period is listed in the table.

After adding a new reporting period, the reporting period will be added to the Reporting Period
selection drop-down at the top of each overview and compliance object page.

Changing the Reporting Period Naming Convention


By default, the naming convention for a new reporting period looks like this:
Q1-2004
The naming convention for reporting periods is set in a configuration file named
SOXCustomMessages.properties, located in the applications/sosa/WEB-INF/classes directory of
your BEA WebLogic installation.
The naming convention is controlled by the value of reporting.period.display.format. For
example:
reporting.period.display.format=Fiscal Year:{1} Quarter:{0}
where {1} is the value selected for the Fiscal Year drop-down and {0} is the value of the
Quarter drop-down when the reporting period is created.
For the default setting (with no value for reporting.period.display.format) the line would look
like this:
Q{0}-{1}
To change the naming convention:
1.
2.

Change directories to the <WLHOME>/applications/sosa/WEB-INF/classes directory


and open the SOXCustomMessages.properties file in a text editor.
Copy and paste the following line from the sample area and remove the comment
marker (the leading #)
#reporting.period.display.format=Fiscal Year:{1} Quarter:{0}
Administering SOX Express

Managing Reporting Periods 44

3.

Modify the value of reporting.period.display.format to the desired format and save your
changes. For example, to create the following display period name:
Results for Quarter 3 in the year 2004
the necessary line in SOXCustomMessages.properties would look like:
reporting.period.display.format=Results for Quarter {0} in the year {1}

When the naming convention for reporting periods is modified, all reporting periods will adopt
the new naming scheme.
After changing the value of reporting.period.display.format, the SOX Express services must be
restarted to pick up the changed value.

Deleting a Reporting Period


After you have created a reporting period, occasionally you may have to delete it to reflect latebreaking changes to your financial close, or due to a mistake in the name (e.g. wrong quarter,
wrong year, etc.).
SOX Express supports deletion of reporting periods for a configurable amount of time after the
reporting period is created. Once the deletion period is passed, the reporting period cannot be
deleted in order to prevent the accidental deletion of historical reporting periods.
When a reporting period is deleted, no files are removed from the database. Signoffs and test
results that were suppressed in the current reporting period are restored.

Deleting a Reporting Period


To delete a reporting period:
1.

Click on the Reporting Periods link in the left-hand Action menu. The Reporting
Periods page is displayed.
2. Select the checkbox next to the name of the reporting periods you want to delete.
3. Click on the Delete button at the top of the page. A confirmation dialog is displayed.
4. Click OK to delete the selected reporting period. You are returned to the Reporting
Periods page and the deleted reporting period is removed from the table.

Note: If you cannot delete a reporting period (you click the checkbox and the Delete button
does not activate), the deletion period for that reporting period has expired.

Configuring the Deletion Period


It is possible to configure the amount of time after a reporting period is created in which the
reporting period can be deleted. This property is set in the sosa.properties file (in the
\aurora\conf directory of your SOX Express installation) and defaults to 7 days after the
reporting period is created. The pertinent section of the configuration file looks like this:
#------------------------------------------------------------------# Reporting Periods
#------------------------------------------------------------------# The number of days after which a reporting period can no longer be
# deleted
reporting.period.delete.interval=7
Change the value of reporting.period.delete.interval to modify the number of days after
creation that a reporting period can be deleted.
Changing the deletion period setting will require restarting the SOX Express services.

Administering SOX Express

Managing Reporting Periods 45

Accessing Past Reporting Periods


Any SOX Express user can view past reporting periods through the Reporting Period selector at
the top of the overview pages and the compliance object view pages. No user can modify
objects in past reporting periods.

How ACLs and Reporting Periods Interact


When viewing objects, your existing ACLs control which objects you can view in the current
reporting period and in past reporting periods. If your access permissions change in the current
reporting period, you will be able to view the newly accessible items in past reporting periods,
and you will not be able to view items to which you have lost permissions, even if in past
reporting periods you had access to them.
Regardless of your access permissions, you are never allowed to add, edit or remove
compliance objects and/or files from past reporting periods.

How Reporting Periods and Audit Trails Interact


When viewing an audit trail for a compliance object, only the changes made during the
currently selected reporting period are shown. You can view the audit trail for past reporting
periods, but only the change activities for that reporting period will be shown.
You cannot view audit trails for multiple reporting periods on the same page.

Administering SOX Express

Resetting Compliance Objects 46

Resetting Compliance Objects


Overview of Compliance Object Resetting
Compliance Object Resets are a way to automatically modify compliance objects that exist in
the SOX Express repository. Resets can be started by users with the proper permissions from
the Object Reset menu item in the Administration section of the Action menu.
The most common use of the Compliance Object Reset functionality is to reset all of your
compliance objects at the beginning of a new Reporting Period. For example, each quarter you
have controls and tests that need to be reviewed and performed. The results of those tasks are
recorded by updating the properties and attachments of the appropriate compliance objects.
Once all of these quarterly tasks have been completed, and the quarter is finished, you archive
all of the results into a Reporting Period and prepare for the new quarter. However, the existing
compliance objects still display the test results and changed properties of the previous quarter.
Rather than go in and modify the compliance objects by hand, you can use the Compliance
Object Reset capability to take your existing compliance objects and modify their properties
based on the rules in your ruleset.
While Resets work well with the Reporting Period capability of SOX Express, Resets do not
require the existence of a Reporting Period to be utilized.
Note: When modifying properties or using properties within <criteria> tags, you may not use
system properties. System properties are the properties common to all compliance object
types, such as name, description, or creator. Property modifications and ruleset criteria must
use custom properties (non-system properties). If the property you want does not appear in a
property bundle for the appropriate compliance object type, you cannot use it in your ruleset.

Preparing Your Data


Before a Reset is performed, you will need to perform a few tasks to help ensure that the Reset
procedure goes smoothly. It is always recommended that you back up your SOX Express data
before running a Reset. In addition, if you plan on archiving your changes to a Reporting
Period, you will need to set the Reporting Period up before running the Reset.

Backing Up Your SOX Express Data


It is highly recommended that you back up your pre-existing SOX Express data prior to running
a Reset. In this way, an un-modified copy of your data is maintained, in case your Reset ruleset
does not perform as intended.

Creating a Reporting Period (optional)


If you are planning to reset your data as part of the beginning of a new Reporting Period, you
will have to archive the existing data to a Reporting Period. Detailed instructions for creating a
new Reporting Period can be found in Managing Reporting Periods on page 43.

Administering SOX Express

Resetting Compliance Objects 47

Creating a Ruleset
Compliance Object Resets are rule-based operations on the compliance objects in your SOX
Express repository. The rules that govern how a Reset will affect your data are contained in a
Ruleset. A Ruleset is a set of rules contained in an XML loader file that is created outside of SOX
Express. Multiple Rulesets can be included in a single XML file. The ruleset loader file is loaded
into the system through the Object Manager loader tool. Once the Ruleset is imported, it can be
selected during the Specify Options step of the Compliance Object Reset guided action.
Compliance Object Resets can modify compliance objects in three ways: modifying the value of
a property, deleting a compliance object, and disassociating two compliance objects.
When creating a Ruleset, you must know the bundles, properties, and property values you are
modifying and match them exactly. If you do not specify a valid property or property value, the
property will not be modified.
Note: Before creating a final Ruleset to use for your Reset session, it can be extremely helpful
to create simple Rulesets that contain a single rule from your final Ruleset. Running these
single Rulesets against a known dataset can verify the accuracy of each rule before attempting
a massive modification of your data.

Creating the Ruleset File


To create the ruleset file, open a new text file in a text editor. Save the file with the following
naming convention:
<file-identfier>-op-config.xml
Once the file is saved, you may edit it to create the XML file.

Sample Ruleset
The following is a sample of how a simple Ruleset might look:
<?xml version="1.0" encoding="UTF-8"?>
<openpagesConfiguration xmlFormatVersion="1.20">
<ruleSets>
<ruleSet name="Quarterly Reset"
description="Rule set to be executed at the beginning of each
and every quarter"
type="Object Reset">
<rule name="Rule 1"
description="Property Update rule setting a property"
type="Property Update">
<propertyUpdateRule contentType="SOXControl">
<bundle name="SOXControl">
<property name="Design Effectiveness"
useDefaultValue="false">
<propertyValue name="Not Rated"/>
</property>
</bundle>
</propertyUpdateRule>
</rule>
<rule name="Rule 2"
description="Property Update rule setting a collection of
properties (including a multi-valued one)."
type="Property Update">
Administering SOX Express

Resetting Compliance Objects 48

<propertyUpdateRule contentType="SOXRisk">
<bundle name="SOXRisk">
<property name="Assertions"
useDefaultValue="false">
<propertyValue name="Existence"/>
<propertyValue name="Rights and Obligations"/>
</property>
<property name="Impact"
useDefaultValue="false">
<propertyValue name="Unknown"/>
</property>
</bundle>
</propertyUpdateRule>
</rule>
<rule name="Rule 3"
description="Object Delete rule"
type="Object Delete">
<objectDeleteRule contentType="SOXTestResult"/>
</rule>
<rule name="Rule 4"
description="Object Delete rule with criteria"
type="Object Delete">
<objectDeleteRule contentType="SOXIssue"/>
<criteria logicalOperator="or">
<criterion bundle="SOXIssue"
property="Status"
operator="=">
<propertyValue name="Closed"/>
</criterion>
</criteria>
</rule>
<rule name="Rule 5"
description="Object Disassociate rule"
type="Object Disassociate">
<objectDisassociateRule parentContentType="SOXRisk"
childContentType="SOXDocument"/>
</rule>
</ruleSet>
</ruleSets>
</openpagesConfiguration>

The Ruleset Tag Library


The following XML tags can be used to build a ruleset:

Administering SOX Express

Resetting Compliance Objects 49

<openpagesConfiguration>
Description: Progenitor tag for the loader file contents. All other tags are contained within the
<openpagesConfiguration> tag.
Parent Tags: None.
Child Tags: <ruleSets>
Syntax:
<openpagesConfiguration xmlFormatVersion="1.15">
</openpagesConfiguration>
Attributes:

Attribute
xmlFormatVersion

Description
Version of the OpenPages XML DTD.

<ruleSets>
Description: Container tag for one or more ruleSet tags.
Parent Tags: <openpagesConfiguration>
Child Tags: <ruleSet>.
Syntax:
<ruleSets>
</ruleSets>
Attributes: None.

<ruleSet>
Description: A ruleset is a collection of rules that will be executed when the ruleset is selected
during a Reset session. Each ruleset is displayed in the SOX Express user interface as a
separate entry in the list of Rulesets.
Parent Tags: <ruleSets>
Child Tags: <rule>
Syntax:
<ruleSet name=Name
description=Description
type=Object Reset
</ruleSet>
Attributes:

Attribute

Description

name

An identifying name for the ruleset. Will be displayed in


the SOX Express user interface.

description

A description of the function of the ruleset.

type

The type of ruleset. Currently, there is only one type Object Reset.
Administering SOX Express

Resetting Compliance Objects 50

<rule>
Description: Each <rule> tag contains a single rule that will be applied to the SOX Express
data when the ruleset is selected and a Reset session is initiated.
Parent Tags: <ruleSet>
Child Tags: <propertyUpdateRule>, <objectDeleteRule>, <objectDisassociateRule>,
<criteria>
Syntax:
<rule name=Name
description=Description
type=[Property Update|Object Delete|Object Disassociate]
</rule>
Attributes:

Attribute

Description

name

The name of the rule.

description

A description of the function of the rule.

type

The type of rule. There are three types of rules:


Property Update, Object Delete, and Object
Disassociate.

<propertyUpdateRule>
Description: The <propertyUpdateRule> tag defines a rule that modifies the value of an
existing property on a certain object type. Unless modified by the use of the <criteria> tag
within the same <rule> tag, all objects of the specified object type within the scope of the
Reset will be updated.
Parent Tags: <rule>
Child Tags: <bundle>
Syntax:
<propertyUpdateRule contentType=>
</propertyUpdateRule>
Attributes:

Attribute
contentType

Description
Specifies the content type that the rule will be applied
to. Must match a valid SOX Express content type.

Administering SOX Express

Resetting Compliance Objects 51

<bundle>
Description: The <bundle> tag specifies which bundle contains the property to be modified.
Parent Tags: <propertyUpdateRule>
Child Tags: <property>
Syntax:
<bundle name=
</bundle>
Attributes:

Attribute

Description

name

The name of the property to be modified.

<property>
Description: The <property> tag is used inside a <bundle> tag to specify the property that
will be updated.
Parent Tags: <bundle>
Child Tags: <propertyValue>
Syntax:
<property name=>
useDefaultValue=[true|false]

[<propertyValue>
<propertyValue>]
</property>
Attributes:

Attribute

Description

name

The name of the property to be updated

useDefaultValue

Specifies whether the property should be updated to


reflect the default value of the property (if one exists).
If no default value exists, the property is not updated.

Administering SOX Express

Resetting Compliance Objects 52

<objectDeleteRule>
Description: The <objectDeleteRule> tag is used to specify an object type for deletion. Unless
modified by the use of the <criteria> tag within the same <rule> tag, all objects of the
specified object type within the scope of the Reset will be deleted.
Parent Tags: <rule>
Child Tags: None.
Syntax:
<objectDeleteRule contentType=/>
Attributes:

Attribute
contentType

Description
Specifies the object type to be deleted. All objects of
this type within the scope of the Reset are deleted.

<objectDisassociateRule>
Description: The <objectDisassociateRule> tag is used to disassociate a compliance object
type from another compliance object type. If you use the <criteria> tag with this rule type, the
criteria must be based on the childs property values. You cannot base a rule on properties or
property values belonging to the parent content type.
Parent Tags: <rule>
Child Tags: None.
Syntax:
<objectDisassociateRule parentContentType=
childContentType=/>
Attributes:

Attribute

Description

parentContentType

Identifies the parent content type that the child


content type is associated with.

childContentType

Identifies the child content type to be disassociated.


Any objects of the child content type associated with
objects of the parent content type within the scope of
the Reset will be disassociated from the parent object.

Administering SOX Express

Resetting Compliance Objects 53

<criteria>
Description: The <criteria> tag is used to refine the behavior of a rule by specifying the
standards that need to be met in order to invoke the rule. The criteria tag can contain one or
more <criterion> tags that will be judged when deciding whether to apply the rule to a specific
compliance object. It should be noted that criteria can only be applied in a positive manner that is, if the criteria are met, the rule will be used. You cannot specify a rule where if the
criteria are met, the rule is NOT applied.
Parent Tags: <rule>
Child Tags: <criterion>
Syntax:
<criteria logicalOperator=[and|or]>
Attributes:

Attribute

Description

logicalOperator

Specifies whether all of the criterion (and) will be


used to determine whether the rule will be applied to
the object, or if only one of the criterion (or) needs to
be satisfied.

<criterion>
Note: It is strongly recommended that you use a maximum of three criterion within a single
<criteria> tag. Adding additional criterion will increase the processing time required to
complete the Reset.
Description: The <criterion> tag allows the user to specify a property and value(s) that must
match the evaluation specifications set in the <criterion> tag.
Parent Tags: <criteria>
Child Tags: <propertyValue>
Syntax:
<criterion bundle=
property=
operator=[=|<>|<=|<|>|>=|like]

<propertyValue=/>
[<propertyValue=/>]
</criterion>
Attributes:

Attribute

Description

bundle

The property bundle containing the property to be


evaluated.

property

The property name of the property to be evaluated

Administering SOX Express

Resetting Compliance Objects 54

Attribute
operator

Description
Specifies the manner in which the value of the property
will be evaluated. Valid operators are equal (=), not
equal (<>), greater than (>), less than (<), greater or
equal to (>=), less than or equal to (<=), and like.
Only the equal, not equal, and like operators can be
used with string variables.
Note: The like parameter allows the use of wildcards
in the <propertyValue> tag. These wildcards consist of
the % and _ symbols, which are passed to a SQL
database query against the Oracle database. The
percent mark (%) symbol is used to represent any
number of characters in a location, while the
underscore (_) character is used to represent any
single character in a location.
The usage is consistent with the use of wildcards in a
SQL where clause. See your SQL documentation for
additional information, if needed.

<propertyValue>
Description: The <propertyValue> tag performs two functions, depending on its location. If
the <propertyValue> tag is contained inside a <property> tag, it specifies the new value (or
values) for the updated property. If the <propertyValue> is contained inside a <criterion> tag,
it specifies the relevant property to be considered when applying the criteria.
If you are modifying a enumerated string (drop-down) property that is multi-selectable, you
can place multiple <propertyValue> tags inside the <property> tag. When the rule is
processed, all of the <propertyValue> tags will be evaluated, and the property will be modified
to select all of them.
Parent Tags: <property>, <criterion>
Child Tags: None.
Syntax:
<propertyValue name=/>
Attributes:

Attribute
name

Description
Specifies the value of the property. See the description
of the <propertyValue> tag for details.

Administering SOX Express

Resetting Compliance Objects 55

Loading the Ruleset


After you have finished creating the ruleset loader file, you will need to use the Object Manager
tool to load the ruleset into the SOX Express system.
To load the ruleset:
1.
2.

Log into the server machine and navigate to the following directory.
<bea-home>\config\OpenpagesDomain
Run the following command on a single line:
ObjectManager load config OPAdministrator <password> <path-to-rulesetxml-file> <file-identfier>
where
<password> is the password to the OPAdminstrator user account.
<path-to-ruleset-XML-file> is the full path to the ruleset file you created.
<file-identifier> is the portion of the ruleset file name preceding -op-config.xml. For
example, if you created a ruleset file called ruleset-op-config.xml, the <fileidentifier> in the ObjectManager command would be ruleset.

3.

The ruleset is now loaded. If you have created multiple ruleset files, repeat this
procedure for each of them.

Updating a Ruleset
If you load a ruleset with the same name as an already-loaded ruleset, the ruleset will be
overwritten with the new rules. To return to an earlier version of the ruleset, you would have to
re-load the original ruleset loader file. Rulesets are not version-controlled.

Performing the Compliance Object Reset


After you have loaded the ruleset you will be using for the Compliance Object Reset, you must
log into the system and begin the Reset.

Preparing for the Reset


The Reset must be run in single user mode - the user performing the Reset should be the only
user logged into the SOX Express system during the Reset. It is suggested that you advise your
users that the system will be down for the duration of the Reset, and that you shut down and
restart the system before beginning the Reset to make certain that you are the only user on the
system.
Note: In order to ensure the system remains unused while the Reset is in progress, you may
wish to change the port number of the SOX Express system when you restart it. Users
accessing the original port will not be able to access the SOX Express system.
The user running the Reset must have the Object Reset application permission. If the user does
not have the Object Reset permission, they will not be able to see the Object Reset menu item
under the Administration heading.

Configuring the Ruleset Parameters


Before executing the Reset, there are some configuration parameters that should be set. In
general, these settings will only need to be set once before your first time initiating a Reset, but
you may wish to change them for different entity trees or ruleset behavior.
The following parameters can be set in the sosa.properties file. This file can be found in the
<bea-home>\config\OpenpagesDomain\applications\sosa\conf directory.

Administering SOX Express

Resetting Compliance Objects 56

Logging Level
This parameter controls how much information is displayed in the user interface. The line in
sosa.properties is scor.option.logging.level. The possible values are:

Low - display error messages only


Medium - display any error messages and any warning messages.
High - display any errors, warnings, and any informational or diagnostic messages.

No matter which option is chosen, the same amount of information is logged during the Reset
session. The Logging Level setting only controls how much of the logged information is
displayed on the Log page.
The default value for the scor.option.logging.level parameter is High.

Obey ACL Restrictions


This parameter controls whether the Reset occurs against all compliance objects contained
within the scope of the Reset session, or whether the Reset occurs against only those objects
that the user who initiated the Reset has access to. The parameter in sosa.properties is called
scor.option.acl.check. It can have a value of true or false (without quotes).
The default value of the scor.option.acl.check parameter is false.

Obey Locking Restrictions


This parameter controls whether existing locks on compliance objects are honored when
running the Reset. The parameter in sosa.properties is called scor.option.ignore.locks. A value
of true means that locks will be ignored when running the Reset, and a value of false means
that locked objects will not be modified by the Reset.
The default value for the scor.option.ignore.locks parameter is false.

Using the Compliance Object Reset Page


The Compliance Object Reset page contains a table that shows all of the previous Reset
sessions that have been started. The table contains columns with the following information:

the
the
the
the
the

name of the Reset session


description of the Reset session
date and time the Reset began
date and time the Reset completed
current status of the Reset

The table also has an Add New button that can be selected to start a new Reset session. For
more information on starting a new Reset session, see Starting the Compliance Object Reset
on page 57.

Administering SOX Express

Resetting Compliance Objects 57

Starting the Compliance Object Reset


To begin the Compliance Object Reset, complete the steps in the following procedure.
1.

Log into the SOX Express system as a user with the Object Reset application
permission.
Note: If you have chosen to obey ACL restrictions, the user must have the permissions
to modify the objects within the scope of the Reset. If the user does not have sufficient
permissions, warning messages will be generated in the log, and the compliance
objects will not be modified.

2.

Click the Object Reset link under the Administration heading in the Action menu.
The Compliance Object Reset page is displayed.
3. Click the Add button at the top of the table to create a new Reset. The Specify Options
page is displayed.
4. Enter a name and description for the new Reset.
5. Select a Ruleset from the dropdown list of available Rulesets. The chosen Ruleset will
be used for the new Reset.
6. Click Next to display the Reset Scope page.
7. Choose the Business Entities to which the Reset will be applied by selecting the
checkboxes next to the entity names. Once you have selected the Business Entities,
click the Start Reset button to begin the Reset.
8. A confirmation warning dialog is displayed. If, after reading the warning, you wish to
begin the Reset, click Ok. The Reset begins, and the Compliance Object Reset page is
displayed.

Viewing the Reset Status


The new Reset session is added to the list of Reset sessions on the Compliance Object Reset
page. You can track the progress of the Reset by monitoring the Status column of the table.
The possible values for the Status field are Initiated, In Progress, Completed, or Failed.
The Failed status will only be shown if the system is set to stop the Reset if errors are
encountered. If the system is set to continue on errors, then when the Reset is completed, the
Completed status will be shown. Any errors that occurred during the Reset will be captured in
the Reset Session Log.

Viewing the Reset Session Details


Every time you start a Reset, an entry is added to the Reset Session table. By clicking on the
name of the reset, the Reset Session Details page is displayed for that Reset Session.
The Details page contains the following information:
Name - The name of the Reset Session.
Description - The description of the Reset Session (set during the creation procedure)
Ruleset Name - The name of the Ruleset that was applied during this session.
Created - The time and date the Reset Session was created.
Start Date - The time and date the Reset was begun.
End Date - The time and date the Reset was completed.
Status - The current status of the Reset. The Status can be one of the following values:

Initiated - The Reset has been initialized, and is preparing to modify your data.
In Progress - The Reset is currently modifying the selected data.
Completed - The Reset finished successfully. Depending on whether the Reset was set
to continue on errors, some errors may be reported in the Session Log.
Failed - The Reset did not finish, because errors were encountered. Check the Session
Log for details on what errors occurred.
Administering SOX Express

Resetting Compliance Objects 58

Created By - The user that initiated the Reset Session.


Scope - The Business Entities that were modified by the Reset.
Logging Level - The level of detail that will be displayed in the Session Log. Can be one of the
following values:

Low - display error messages only


Medium - display any error messages and any warning messages.
High - display any errors, warnings, and any informational or diagnostic messages.

Continue on Error - Whether the Reset Session will log errors and continue to run, or whether
the error will be logged and the session will halt. Value will either be true or false.
Check ACLs - Whether the Reset occurs against all compliance objects contained within the
scope of the Reset session, or whether the Reset occurs against only those objects that the
user who initiated the Reset has access to. It can have a value of true or false.
Ignore Locks - Whether existing locks on compliance objects are honored when running the
Reset. A value of true means that locks were ignored when running the Reset, and a value of
false means that locked objects were modified by the Reset.

Viewing the Reset Session Log


In addition to the Details page, a detailed view of the Reset Session is recorded in the Reset
Session Log. The level of detail depends on the configuration setting. For details on setting the
logging level, see the section Configuring the Ruleset Parameters on page 55
To view the Reset Session Log, click on the View Log button on the Reset Session Details
page.
The Reset Session Log contains three sections - the Error Messages section, the Warning
Messages section, and the Informational Messages section.

Error Messages
The Error Messages section contains the details of any errors encountered by the Reset.

Warning Messages
The Warning Messages section contains any warning messages generated by the Reset.

Informational Messages
The Informational Messages section captures the running details of the Reset - the number of
successful operations, details on the preparation steps that occur during the Initializing phase,
and a summary of the number of errors encountered during the Reset.

After the Reset


After you have performed an Object Reset, it is highly recommended that you refresh the
Reporting database so that users who run third-party reports will immediately see the changes.
If your users are not using a third-party reporting tool, such as Crystal Reports or
CommandCenter, you do not need to perform a reporting schema refresh. The native SOX
Express reports will automatically see the changes.
For detailed information on performing a reporting database refresh, see Enabling Optional
Reporting Tools on page 77.

Administering SOX Express

Starting Jobs from SOX Express Objects


Overview of SOX Express Jobs
SOX Express allows users with the correct permissions to start jobs that are associated with
SOX Express compliance objects. This section will explain how to start a job from a SOX
Express compliance object and how to monitor the current progress of the job.

Additional Information
For a complete explanation of jobs and job types, see the Working with Jobs and Job Types
chapter of the OpenPages User Manual.
For an explanation of enabling job types for a specific type of compliance object, see the
Enabling A Job Type section of the Openpages User Manual.
For instructions on configuring your jobs and administering some of the advanced features of
the SOX Express workflow capabilities, see the Configuring SOX Express chapter of the SOX
Express Administrators Manual.

Starting a Job from a SOX Express Compliance Object


In order to start a job from a compliance object, that job type must have been enabled through
the OpenPages user interface. If you have not enabled the job type, you will not be able to
select the job correctly.
For an explanation of enabling job types for a specific type of compliance object, see the
Enabling A Job Type section of the Openpages User Manual.
To start a job from within a compliance object:
1.
2.
3.
4.
5.

From the Home page, click on the appropriate link in the Action menu for the
compliance object type (Account, Process, etc.) where you are starting a job.
Navigate to the compliance object(s) for which you want to start a job.
Click the checkbox next to the desired compliance object. If you select multiple
compliance objects, a job will be started for each object.
Click the Submit button. The Submit for Approval page is displayed. If the Submit
button is not available, no jobs have been enabled for this type of compliance object.
Fill in the description and a due date (if any) for the job and click Submit to start the
job.

Monitoring Job Progess


You can keep track of what activity has occurred for a job through the My Jobs table on your
Home page. Each job is shown with its name, description, the compliance object it is attached
to, and the currently active task.
Clicking on the name of a currently running job displays the Details page for that job. In the
details page, you can view information about the job, including any comments input by various
users and assignees.

Configuring
SOX Express
This chapter provides information about administering the SOX Express
application, including adding and removing SOX Express users, report
administration, and adding custom fields to SOX Express compliance
objects.
This chapter contains the following topics:

Using The Backup Utility on page 61


Using the Restore Utility on page 63
Generating Object Names on page 64
Managing Signatures and Locks on page 67
Enabling Workflows for SOX Express Objects on page 71
Configuring Job Behavior on page 73
Enabling Optional Reporting Tools on page 77
Changing the Database Passwords on page 85

Using The Backup Utility 61

Using The Backup Utility


Overview of the Backup Utility
The Backup Utility is a tool that allows the user to backup necessary SOX Express and
OpenPages files and databases. As part of the backup process, the following SOX Express and
OpenPages resources are backed up.

SOX Express database and Workflow database


SOX Express storage folder and its content
the aurora.properties and twf.ini files
the config.xml, config.xml.keep, and config.xml.op4 files
all JSP, XML, TLD, and property files under
<WL_HOME>\config\<OpenpagesDomain>\applications\sosa.

Prerequisites
The following software is required to use the Backup/Restore Utility:

SOX Express 3.0.0 or later installed


Oracle Admin Client Software (version 9.2.0.4) installed on the SOX Express Application
Server machine.

Configuring the Backup/Restore Utility


The Backup/Restore Utility is automatically installed during the SOX Express 3.0 installation
procedure.

Using the Backup Utility


To back up your data with the Backup Utility:
1.
2.

Change directory to <WL_HOME>\aurora\bin directory


Execute the following command:
OPBackup <drive>:\<path-to-backup-location>
where drive is the drive where the backup files will be placed, and <path-to-backuplocation> is the name of the folder where the backed up files and database dump files
will be placed.

The <backup-directory-name> is an optional parameter. When <backup-directory-name> is


not specified, the Backup utility will use the default backup location specified in the
<WL_HOME>/aurora/bin/op-backup-recovery.env (BACKUP_LOCATION) file.

Additional Information
Generated Files
Backup Log File
The backup process creates a log file, which is identified by a unique name in the <backupdirectory-name> folder. Each time you run the OPBackup command a separate log file is
generated.

Configuring SOX Express

Using The Backup Utility 62

Backed-Up Content
The backup process creates a zip file in the <backup-directory-name>directory. This zip file
contains the necessary backed up data files including the database dump file. This file may be
used as a parameter to the OPRestore command to restore the installation-specific SOX files
and the database. Each time the OPBackup command is run, a separate zip file is created and
each data file is identified by a unique name.

Usage Notes

The OPBackup command uses the Oracle exp command to export the database.
The OPBackup command stops all OpenPages and SOX Express services before
performing any backup operation. It restarts the services when the backup activities
are complete.

Configuring SOX Express

Using the Restore Utility 63

Using the Restore Utility


Overview of the Restore Utility
The Restore Utility is used to restore necessary OpenPages and SOX Express files and database
content. The Restore Utility uses a backup file created using the SOX Express Backup Utility.
As part of the restoration process, the following SOX resources gets restored.

OpenPages database and Workflow database


OpenPages storage folder and its content
the aurora.properties and twf.ini files
the config.xml, config.xml.keep, and config.xml.op4 files

Under the <WL_HOME>\config\<OpenpagesDomain>\applications\sosa folder, the following


files get restored.

sosa.properties
webapp.proerties
configTileDefintions.xml
SOXCustomMessages.properties

Using the Restore Utility


To restore backed up data using the Restore Utility
1.
2.

Change directory to <WL_HOME>\aurora\bin directory


Execute the following command
OPRestore <backup-file-name> <path-to-backup-location>
Where

<backup-file-name> is the name of the backup file (without the .zip file
extension)
<path-to-backup-location> is the full path of the folder where the backup file is
located

Additional Information

The restore process creates a log file identified by a unique name in the <backupdirectory-name> folder. Each time you run the OPRestore command, a separate log
file is created.
The OPRestore command uses the Oracle imp command to import the database.

Configuring SOX Express

Generating Object Names 64

Generating Object Names


Overview of Name Generation
SOX Express provides the ability to auto-generate the names of newly created compliance
objects. This ability allows users to enforce internal naming policies and ensure unique object
names.
The auto-generation of object names is controlled by a series of settings in the sosa.properties
file. This file must be modified in order to set the autonaming properties. It is possible to turn
autonaming on or off for each compliance object type individually. For example, you may want
all business entities and processes named by hand, but all risks, controls, and test plans named
automatically by SOX Express. This can be accomplished by modifying the appropriate settings
(detailed in Modifying the Naming Settings on page 62).

Modifying the Naming Settings


The sosa.properties file contains a set of four parameters for each compliance object type.
The relevant settings are:

Setting Name

Description

autonaming.sox.<objecttype>.autonamed

Determines whether the object type name


will be autogenerated. Can be set to true
or false.

autonaming.sox.<objecttype>.editable

Determines whether the generated name


can be edited during the creation process.
Can be set to true or false

autonaming.sox.<objecttype>.format

Determines the format of the generated


name. Additional details can be found in
Configuring the Object Name on page 65

autonaming.sox.<objecttype>.parent.default

If the created compliance object has no


parent, the value for this parameter will be
used to replace the %P; variable in the
generated name.

For example, the settings for the Business Entity compliance object type could look like this:
autonaming.sox.SOXBusEntity.autonamed = false
autonaming.sox.SOXBusEntity.editable = false
autonaming.sox.SOXBusEntity.format = %P;_BUSE_%N3;
autonaming.sox.SOXBusEntity.parent.default = ORPHANED
In the above example, Business Entities would not be autonamed. If we change the value of
autonaming.sox.SOXBusEntity.autonamed to true, as below:
autonaming.sox.SOXBusEntity.autonamed = true
autonaming.sox.SOXBusEntity.editable = false
autonaming.sox.SOXBusEntity.format = %P;_BUSE_%N3;
autonaming.sox.SOXBusEntity.parent.default = ORPHANED
New Business Entities would be created with automatically generated names. These names
would not be able to be edited during the creation process (or afterwards).

Configuring SOX Express

Generating Object Names 65

Configuring the Object Name


The autonaming.sox.<objecttype>.format setting allows you to incorporate some contextual
information about the object, as well as include a incremental number.
There are three variables that you can include in the format of the autogenerated name. They
are %P;, %U;, and %Nn. They are explained in the following table.

Variable

Meaning

%P;

Will be replaced with the name of the parent of the new


object. If the created object has no parent, the value of
autonaming.sox.<objectname>.default will be used.

%U;

Will be replaced with the creators username.

%Nn;

A unique number. The value of n specifies the amount


of padding the number has. For example, the variable
%N5 would result in numbers like 00001, 00002, etc.
%N3 would result in 001, 002, 003 and so on.

In addition to the variables, you can include any valid text as well in the autoname. The name
of a compliance object must be 252 characters or less and cannot contain any of the following
characters:
'/',':','*','\', '"', '<','>','!', '#', '%', '?', '|'
(slash, colon, asterisk, backslash, double quote, less than, greater than, exclamation point
(bang), pound, percentile, question mark, pipe)

Autogenerating Long Names


Be wary of nesting compliance objects with autogenerated names too deep, as the generated
names can stack with repeated use of the %P; variable.
For example, if you autogenerate the names of Processes, Control Objectives, Risks, Controls,
and Tests using the %P; variable for all of them, the following will happen.
The Process Name will be Entity_Name - Process 001 (given the format string %P; - Process
&N3;)
Using the same format through the rest of the compliance object hierarchy, the name of the
associated Control Objectives would be Entity_Name - Process 001 - Control Objective 001
(the parent name plus the rest of the format string).
The Risk name would then be Entity_Name - Process 001 - Control Objective 001 - Risk 001.
The Control name would then be Entity_Name - Process 001 - Control Objective 001 - Risk 001
- Control 001.
And finally, the Test name would be Entity_Name - Process 001 - Control Objective 001 - Risk
001 - Control 001 - Test 001. (85 characters)
With repeated use of the %P; variable, the names can get extremely long. With longer naming
conventions, you could exceed the maximum length of a compliance object name (252
characters).

Configuring SOX Express

Generating Object Names 66

Naming Examples
Here are some examples of the various ways the variables can be used:
If we use a parent Process of Hiring Practices and a creator of JSmith, and the following
settings in sosa.properties:
autonaming.sox.SOXRisk.autonamed = true
autonaming.sox.SOXRisk.editable = false
autonaming.sox.SOXRisk.format = %P;_RIS_%N7;
autonaming.sox.SOXRisk.parent.default = ORPHANED
The autogenerated name would be Hiring Practices_RIS_0000001
Example 1:
For the autonaming format parameter
autonaming.sox.SOXRisk.format = %P;-Risk-%N5;
the generated Risk name would be Hiring Practices-Risk-00001.
Example 2:
Given a different autonaming format parameter, such as
autonaming.sox.SOXRisk.format = Risk %N3; for %P; (%U;)
would result in the generated name Risk 001 for Hiring Practices (JSmith)
Example 3:
Not all of the variables need to be used in an autogenerated name. For example,
autonaming.sox.SOXRisk.format = Risk %N4;
results in Risk 0001
Example 4:
If the risk HAD no parent process, the value of autonaming.sox.SOXRisk.parent.default would
be used. In this case, the value
autonaming.sox.SOXRisk.format = %P;_RIS_%N7;
results in ORPHANED_RIS_0000001

Configuring SOX Express

Managing Signatures and Locks 67

Managing Signatures and Locks


Overview of Signatures and Locks
SOX Express allows users to create signatures on compliance objects. By itself, a signature is
a merely a virtual note that signifies the users agreement that the object meets with their
approval. It has no enforcement powers, and does not prevent the item from being modified
after approval has been given.
There are two ways in which signatures can be applied to a compliance object: manually
through the Add button, or automatically through a workflow task. Your SOX Express system
must be configured to support either method, and they are not exclusive - you can implement
both ways, if desired.
A workflow signature is a signature that is created on an object as a direct result of a workflow
being completed. If all other methods of creating a signature are disabled, the presence of a
signature verifies that the necessary workflow was completed (and when). A manual signature
is added through the compliance objects Details page.
A signature lock is a lock placed on an compliance object and its descendants that prevents the
objects from being modified. The lock is activated by placing a signature on a compliance
object; whether manually or automatically makes no difference. Once the signature is placed,
the lock becomes active. The signed compliance object and all of its associated child compliance
objects below it in the object hierarchy cannot be modified until the signature is revoked or an
administrator removes the lock.
Only one active lock can be placed on a compliance object. Multiple locks can be inherited from
parent compliance objects as those objects are locked.
The following sections will explain how to implement signatures and locking behavior.

Enabling and Disabling Signatures


This section describes how to enable and disable signatures through the sosa.properties file.

Manual Signatures
Manual signatures are added on the Details page of a compliance object. The Signatures table
has an Add button and a Revoke button at the top of the table. Users without the ability to add
signatures to a compliance object will not see the buttons.
In order to add a signature to an object, the user must have write permissions to the object.

Enabling Manual Signatures


When you enable the ability to manually add a signature to a compliance object, you are
actually granting the ability to add a signature to a type of compliance object (i.e. accounts,
business entities, etc.) to a specific group. The group will be able to add a signature to any
object of the proper type that they have read access to.
To enable a user or group to add a signature directly to a compliance object:
1.

Open the sosa.properties file (located in the


\config\OpenpagesDomain\applications\sosa\conf directory under your BEA WebLogic
installation.

Configuring SOX Express

Managing Signatures and Locks 68

2.

3.

Find the line that corresponds to the compliance object type you want to enable
signatures for. The lines for the different types are:
sosa.signature.permission.add.businessentity=
sosa.signature.permission.add.account=
sosa.signature.permission.add.process=
sosa.signature.permission.add.controlobjective=
sosa.signature.permission.add.risk=
sosa.signature.permission.add.control=
sosa.signature.permission.add.test=
Add the name of the group you want to be able to add a signature to the end of the
line. Multiple groups are separated by commas. There cannot be a space after the
comma.
For example, to add the groups Auditors and Managers to the signoff list for processes,
the modified line would look like:
sosa.signature.permission.add.process=Auditors,Managers
Members of the two groups would then be able to add signatures to processes and
subprocesses.

4.
5.
6.

Repeat the process for each group and compliance object type you want to set up.
Save the changes to sosa.properties and exit the text editor.
Restart the SOX Express server to activate the new settings.

Disabling Manual Signatures


To disable manual signatures for a group or a compliance object type:
1.

2.

3.

Open the sosa.properties file (located in the


\config\OpenpagesDomain\applications\sosa\conf directory under your BEA WebLogic
installation.
Find the line that corresponds to the compliance object type you want to disable
signatures for. The lines for the different types are:
sosa.signature.permission.add.businessentity=
sosa.signature.permission.add.account=
sosa.signature.permission.add.process=
sosa.signature.permission.add.controlobjective=
sosa.signature.permission.add.risk=
sosa.signature.permission.add.control=
sosa.signature.permission.add.test=
Remove the name of the group for which you want to revoke signing privileges from the
end of the line.
Members of the removed group would no longer be able to add signatures to the
compliance object type.

4.
5.
6.

Repeat the process for each group and compliance object type you want to revoke.
Save the changes to sosa.properties and exit the text editor.
Restart the SOX Express server to activate the new settings.

Automatic Signatures
Automatic signatures are applied to a compliance object as a result of a workflow task. A user is
assigned a task to create a signature. Completing the task results in a signature dialog box.
Once the user fills out the dialog, the new signature is created on the compliance object.
For instructions on setting up automatic signatures, see Enabling Signatures for SOX Express
Jobs on page 73.

Configuring SOX Express

Managing Signatures and Locks 69

Cascading Signatures
When a compliance object has a signature added to it, SOX Express provides the ability to
automatically apply the signature to all of the associated objects underneath the signed object
down the entire object tree. For example, signing a process would apply that signature to any
sub-processes, accounts, risks, controls, and tests associated with the process. This feature is
turned off by default, but can be enabled through the sosa.properties file.
To enable or disable cascading signatures for a compliance object type:
1.

2.

3.
4.
5.
6.

Open the sosa.properties file (located in the


\config\OpenpagesDomain\applications\sosa\conf directory under your BEA WebLogic
installation.
Find the line that corresponds to the compliance object type you want to disable
signatures for. The lines for the different types are:
#sosa.signature.cascade.SOXBusEntity=SOXBusEntity,SOXAcc
ount,SOXSubaccount,SOXProcess,SOXSubprocess,SOXControlOb
jective,SOXRisk,SOXControl,SOXTest
#sosa.signature.cascade.SOXAccount=SOXSubaccount,SOXProc
ess,SOXSubprocess,SOXControlObjective,SOXRisk,SOXControl
,SOXTest
#sosa.signature.cascade.SOXSubaccount=SOXSubaccount,SOXP
rocess,SOXSubprocess,SOXControlObjective,SOXRisk,SOXCont
rol,SOXTest
#sosa.signature.cascade.SOXProcess=SOXSubprocess,SOXCont
rolObjective,SOXRisk,SOXControl,SOXTest
#sosa.signature.cascade.SOXSubprocess=SOXSubprocess,SOXC
ontrolObjective,SOXRisk,SOXControl,SOXTest
#sosa.signature.cascade.SOXControlObjective=SOXRisk,SOXC
ontrol,SOXTest
#sosa.signature.cascade.SOXRisk=SOXControl,SOXTest
#sosa.signature.cascade.SOXControl=SOXTest
#sosa.signature.cascade.SOXTest=
The object names after the equals sign are the compliance objects that will be signed
automatically when a signature is added to a compliance object of the appropriate type.
To enable cascading signatures, remove the comment character (#) from the beginning
of the line(s) you want to activate.
To disable cascading signatures after they have been enabled, add the comment
character (#) to the beginning of the line(s) you want to activate.
Removing a compliance object type from the list will remove the object from the
cascade. A signature will not be automatically created for the object type.

Enabling and Disabling Locks


Important Note: If locking is enabled, the cascading signatures setting must be turned off.
Cascading signatures and locks cannot be enabled at the same time, or you may see some
unexpected results.
Whether a lock is created when a signature is added is controlled by a setting in
sosa.properties. When the setting is active, adding a signature to a compliance object will also
create a lock on the object that prevents further changes from being made to the compliance
object and any object associated with it. Revoking a signature will remove the associated lock.
The setting is signature.autolock=. A value of true activates the locking behavior, and a
value of false deactivates it.
Note: When the locking feature is enabled, users can only create signatures on items to which
they have Write permissions.
See the Signing Off On Compliance Objects section of the SOX Express Users Manual for more
information on locking behavior.
Configuring SOX Express

Managing Signatures and Locks 70

The Lock and Unlock Permissions


Locks may also be applied to compliance objects without the use of signatures. If the Lock
application permission is granted to a group, the group can create a lock on any compliance
object to which they have Write permissions (as long as they also have write permissions to all
of the objects associated compliance objects down the hierarchy).
The Unlock permission allows a user to unlock any locked compliance object, as long as he has
Write permission to the object and all associated objects in the hierarchy.
Unlocking a compliance object using the Unlock button does NOT revoke the signature.

Locking Access Privileges


By default, Read permission is required in order to be able to lock a compliance object. This
setting can now be configured through a new property in the aurora.properties file named
allow.locking.read.access. This property is set to false by default.
When set to true, users with Read access to a compliance object will be able to lock the
compliance object by adding a signature. The default value of false requires that users have
at least Write access to a compliance object before they are allowed to lock it.

Configuring SOX Express

Enabling Workflows for SOX Express Objects 71

Enabling Workflows for SOX Express


Objects
About Enabling SOX Express Workflows
SOX Express provides the capability to start jobs (workflows) that are attached to specific SOX
Express compliance objects. This allows users to create workflows that apply to certain SOX
Express compliance objects, such as accounts or processes, and assign tasks.
Note: This section assumes that you already know how to create jobs and job types, as
described in the Managing Jobs and Job Types chapter of the OpenPages User Manual. The
OpenPages User Manual can be found in the docs directory of your OpenPages installation.

Pre-requisites for Starting SOX Express Jobs


In order to start a job from within the SOX Express user interface, the following pre-requisites
must be fulfilled:

The SOX Express user who is responsible for starting jobs must have the Start Jobs
application permission.
The job type to be started must be owned by the SOX Express user or a group to which
the user belongs.

Enabling a job type to be started from a compliance object requires access to OpenPages. Make
sure you have an OpenPages user name with the Manage Job Types application permission
when attempting to enable a job type.

Enabling a Job Type


Note: These steps can also be accomplished during the job creation process.
To enable a new or existing job type to be started from a SOX Express compliance object, you
will need to accomplish the following steps:
1.
2.
3.
4.
5.
6.

Log into the OpenPages server with a user name that has privileges to start and edit
jobs and job types.
Click the My Jobs link in the Action menu. The My Jobs page is displayed.
Click the View Job Types button at the top of the page. A list of Job Types is
displayed.
Choose the job type you wish to enable and click its name. The Job Type Details page is
displayed.
Click the Edit... button on the Properties table. The Edit Job Type Properties page is
displayed.
Click New and add a new Single File property with the name of the SOX Express
compliance object type for which you want the job type activated. The name of the
compliance object type must match a value in the following table and is case-sensitive.
Note: You do not need to specify any values except for the name of the property.

Configuring SOX Express

Enabling Workflows for SOX Express Objects 72

Content Type

Compliance Object

SOXAccount

Accounts

SOXBusEntity

Business Entities

SOXControl

Controls

SOXControlObjective

Control Objectives

SOXDocument

Associated Files

SOXProcess

Processes

SOXRisk

Risks

SOXSubaccount

Sub-Accounts

SOXSubprocess

Sub-Processes

SOXTest

Control Tests

7.

Add a Single File property for each compliance object type you wish to enable. When
you are finished adding properties, click Save to save your changes and return to the
Job Type Details page.

Jobs of the selected job type can now be associated with compliance objects of the type
specified in each Single File property.

Configuring SOX Express

Configuring Job Behavior 73

Configuring Job Behavior


Overview of SOX Express Jobs
When you create jobs and associate them with SOX compliance objects, there are certain
characteristics you can modify to add additional functionality to the workflow capabilities of
SOX Express.
The following sections detail the modifications you can make to SOX Express jobs and tasks:

Enabling Signatures for SOX Express Jobs on page 73


Assigning Job Tasks Based on Object Properties on page 73
Attaching Reports to Workflow Tasks on page 75

Enabling Signatures for SOX Express Jobs


To create a signature event for a job started from a SOX Express compliance object, create a
task in the job with an output arrow (exactly) labelled Signoff. When users complete the task,
they will be prompted to enter a signature which will appear in the Signoff table in the
compliance objects Details page.

Assigning Job Tasks Based on Object Properties


Note: This is an advanced topic, and should only be attempted by a user already familiar with
the SOX Express and OpenPages systems.
SOX Express supports the ability to determine the correct user to assign workflow tasks to by
looking at properties of the compliance object used to start the job.
For example, you can have a custom field on a Process called Reviewer, and list the user
name of the person responsible for reviewing the account. If you start a review job from that
process, the job can read the value of the Reviewer field and assign a review task to that
user. Otherwise, you would have to modify the job type each time before you ran it and
reassign each task to the proper user or group.
The steps involved in setting up automatic user assignment are:

Plan out the needed user roles and names for the job type.
Modify the job type and add the correct properties.
Set up a Custom Java Action Set to extract the user names and insert them into the
proper places in the tasks.
Create custom fields in the SOX Express object for the user names.

Planning Ahead
Before beginning the job type modification procedure, plan out what user roles and
assignments you will need to define. This is best done ahead of time.
Before you begin to make your changes, you should know in which field the name of the task
owner will be stored, and what the name of that field will be.
For our example, we will create a Reviewer role, and the field containing the name of the user
will be Process Reviewer.

Modifying the Job Type Properties


Once you have determined which user roles you will want to automatically assign, you must
modify the job type to create some properties with which to hold the user information once it is
gathered from the compliance object. You can also complete this step during the job type
creation process in the Edit Properties step, if desired.

Configuring SOX Express

Configuring Job Behavior 74

In this procedure, we will create two new properties for the Job Type. These properties are
named TaskOwner and PropertyName. TaskOwner is where the retrieved name of the
assignee will be stored, and PropertyName identifies the field name where the name of the user
will be found. You will need to create these properties for any job where you wish to use
automatic user assignment.
To modify the job type:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

12.

13.
14.

From the Home page, click on the My Jobs link in the Action menu. The list of currently
active jobs is displayed.
Click the View Job Types button at the top of the screen. A list of job types is
displayed.
Click the name of the job type you wish to modify. The Job Type Details screen is
displayed.
Click the Edit button under the Properties section, The Edit Job Type Properties screen
is displayed.
Click the New button on the right-hand side of the page.
Select Single File from the dialog box and click Ok.
Enter the compliance object type which this job will be activated from. For a list of
compliance object types, see the section Enabling a Job Type on page 71.
If you wish to enable the job for more than one compliance object type, repeat steps 5
through 7 for each object type.
Click the New button on the right-hand side of the page.
Select Simple String from the dialog box and click Ok.
Enter TaskOwner as the name of the property and a valid group name for the Default
Value and click the Apply button. The property is added to the list of properties for the
job type.
Repeat steps 9 and 10, and enter PropertyName into the Name field, and the name of
the property field where you will set the user name into the Default Value field. (For our
example, Default Value would be set to Process Reviewer.)
Click the Apply button to add the PropertyName property to the list of properties.
Click Save to save your changes and return to the Job Type Details page (or the Edit
page, if you are currently creating a new Job Type).

Modifying the Job Task


Once the custom properties have been added to the job type, you must create a Java Action to
pick up the user name from the compliance object field and store it in the TaskOwner property
you just defined. Finally, you must modify the task to use the Java Action you created and
assign the task to the TaskOwner property.

Create the New Java Action


1.

From the Details page of the job type you want to modify, click the Edit button in the
Tasks table. The Edit Tasks page is displayed
Note: You do not need to complete Step 1 if you are currently creating the job type.
Click Next from the Edit Job Type Properties to display the Edit Tasks page.

2.
3.
4.

Click the Java Action Sets button on the right-hand side of the shortcut bar. The
Define Java Action Sets dialog box is displayed.
Click the New button to display the Define Java Action Set dialog.
In the Name field, type GetOwnerSet and click the New button to create a new Java
Action.

Configuring SOX Express

Configuring Job Behavior 75

5.

6.

7.
8.

Fill out

the fields as follows:


Action Name: GetOwner
Description: <leave blank>
Class name:
com.openpages.aurora.service.workflow.actions.GetMetaDataAction
Method to execute: getPropertyAsString
Store Return Value as: TaskOwner
There are two parameter properties to set.
a. Set the Single File property to the value of the Single File property type that
identifies which compliance object type the job will be associated with.
b. Set the Simple String property to PropertyName.
Click Apply to save your settings, then click Ok to close the dialog.
Click Close to close the Define Java Action Sets dialog. You are returned to the Edit
Tasks page.

Modify the Task Properties


1.
2.
3.
4.
5.

Right-click on the task to be assigned and select the Properties menu choice. The Task
Properties dialog is displayed.
Click the Actions tab and select GetOwnerSet for the value of Upon reaching this
node: .
Click the General tab and select <TaskOwner> as the Assigned To value.
Click OK to return to the Edit Tasks page.
Click Save to save your changes and return to the Job Type Details screen.

Creating the Compliance Object Custom Property


The final step to activate user assignment is to create the property field for the SOX Express
compliance object. This is the field you will use to enter the user name of the person the task
will be assigned to.
Follow the steps outlined in the section Modifying Compliance Objects on page 92 to add a
new field to your SOX Express compliance object.
Note: Make sure the name of the new field exactly matches the value of the PropertyName
custom property. In our example above, the name of the new field would have to be Process
Reviewer.

Attaching Reports to Workflow Tasks


Overview
SOX Express Express allows reports to be automatically attached to tasks within a workflow.
Clicking on the name of an attached report runs the report and displays the results in a new
window.

Adding a Report to a Workflow Task


To attach a report to a workflow task:
1.
2.
3.
4.
5.

Log into the OpenPages application as a user with the Manage Job Types permission.
Click on My Jobs in the Action Menu to display a list of all of your running jobs.
Click on the View Job Types button to display a list of job types.
Click the name of the Job Type you wish to edit to display the Job Type Details page.
Under the Tasks section, click the Edit button to view the Create Tasks page for the job
type.

Configuring SOX Express

Configuring Job Behavior 76

6.
7.
8.
9.
10.
11.
12.
13.

Right-click the name of the task to which you want to add a report and click the
Properties menu selection. The Edit Task Properties page is displayed.
Click the Publishing tab to display the publishing settings for the task. This tab
displays a list of the reports that will be attached to the task when the task is reached.
Click the Add button to display a file browser.
Navigate to the folder containing the report page you wish to attach to the task. Click
the name of the folder to display the contents in the right-hand pane.
Select the report(s) you wish to attach to the task. Control-click to select multiple
reports within a single folder.
Click OK to add the reports to the task and return to the list of attached reports. The
selected reports are now listed in the window.
Once you have added all of the reports you want, click OK on the bottom of the page to
close the Edit Task Properties window and return to the Create Tasks page.
Click Finish at the bottom of the Create Tasks page to save your changes.

Removing a Report from a Workflow Task


To attach a report to a workflow task:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Log into the OpenPages application as a user with the Manage Job Types permission.
Click on My Jobs in the Action Menu to display a list of all of your running jobs.
Click on the View Job Types button to display a list of job types.
Click the name of the Job Type you wish to edit to display the Job Type Details page.
Under the Tasks section, click the Edit button to view the workflow diagram for the job
type.
Right-click the name of the task that has the report you want to delete and click the
Properties menu selection. The Edit Task Properties page is displayed.
Click the Publishing tab to display the publishing settings for the task. This tab
displays a list of the reports that will be attached to the task when the task is reached.
Select the name(s) of the report you are removing and click the Remove button.
Once you have removed the desired reports, click OK on the bottom of the page to
close the Edit Task Properties window.
Click Finish at the bottom of the Create Tasks page to save your changes.

Using Interactive Reports with Workflow Tasks


In order to use reports with interactive properties, simply attach the report as normal to a
workflow task. When the report is run, the report will prompt the user for values for the
interactive parameters.
If you have an interactive report parameter with the same name as a job property, the value of
the job property will be passed to the report as a string in the report.
The following limitations apply to the use of autofilling interactive report parameters with job
properties:

No attempt to validate that the job property and interactive report parameter are the
same data type (e.g. string, file path, enumerated list)
If a single interactive parameter matches the name of a job property, the user will not
be prompted to provide values for any other interactive parameters. If they do not
match job properties, they will be submitted to the report with blank entries. This may
cause the report to fail, depending on the report parameter.

Configuring SOX Express

Enabling Optional Reporting Tools 77

Enabling Optional Reporting Tools


Overview
In order to use the reporting capabilities of an optional reporting tool (such as
CommandCenter or Crystal Reports, you must configure and populate the reporting schema
with your current SOX Express data. The following sections will explain how to configure and
populate that database instance using the tools provided with Oracle and SOX Express.
This functionality replaces the orginal Exporter tool.

Differences From the Exporter Tool


The following compatibility areas exist between the current tool and the previous OP Exporter
tool:

Exposes the information about the nesting relationship between parent and child
objects in the relationship tables (also known as roll-up tables and transitive closures).
The OP Exporter tool does not preserve this information, making it challenging to create
generic drill-down reports.
Presents multi-valued properties as separate tables, as opposed to a single commaseparated list (a multi-valued roll-up). Presenting information in a single list makes
searching for objects that fall into more than one category more complex and requires
editing the filtering considerations by hand.
Accounts and sub-accounts, as well as processes and sub-processes, are treated as
separate content types (reflecting the actual object hierarchy in SOX Express). The OP
Exporter blended each set together and exposed them as a single content type.
Removes extraneous information from the master relationship table
(SX_ASSOCIATION). The OP Exporter required additional columns to be present in the
master relationship table (such as parent name, description, and loop-back URL).
Removes unnecessary self-to-self relationship tables that are only required for nested
compliance objects of the same type.
Changed the syntax of the nesting path value to a concatenated list of the names of all
the superior objects of the same type from top to bottom, and the name of the object
itself. The OP Exporter did not include the name of the object itself, causing top-level
objects to have a value of NULL.

Configuring the Reporting Metadata


Before the dynamic part of the SOX Express reporting schema can be created, the configuration
tables must be populated. Populating the configuration tables is a manual process. To simplify
the configuration process, an Oracle package named OP_REPORT_MGR is included with SOX
Express, along with two SQL scripts. The SQL scripts demonstrate how to load a reporting
configuration that corresponds to the standard SOX Express schema shipped with SOX Express.
Note: If you have customized your SOX Express schema, you will have to customize the SQL
scripts to reflect the changes you have made in your schema.

About the Configuration Tables


The SOX Express reporting schema includes a set of permanent tables that store the
configuration tables used by the OP_REPORT_MGR package to dynamically generate and
populate the rest of the reporting schema. The following tables are used to store configuration
information for the SOX Express reporting schema.

Configuring SOX Express

Enabling Optional Reporting Tools 78

RPT_OBJECTS
The RPT_OBJECTS table is used to register the names of the database objects that
represent resources corresponding to registered content types. It also defines that
physical types of the database objects - views, materialized views, or tables. It allows
specifying tablespaces to store the database objects and their indices.

RPT_OBJ_COLUMNS
The RPT_OBJ_COLUMNS table is used to define the mapping between the properties
associated with a content type and the database object columns representing them,
column aliases, and and their physical order. It also allows the defining of functionbased columns by specifying the data transformation of the property values by means
of the supported macro keywords or a user-supplied function.

RPT_RELATIONS
The RPT_RELATIONS table is used to register object-to-object relationships. Database
objects representing relationships can be either materialized views or tables, depending
on the type of the master object. It can also specify column aliases for the parent and
child identifiers.

RPT_LEVEL_LABELS
The RPT_LEVEL_LABELS table is used to assign a string label to a particular level in the
hierarchy of jobects of the same type. For example, business entities can be nested,
and assigning a label to each level of nesting (Division, Department, Workgroup, etc.)
allows a better sense of level than Level 3 Entity.
The following diagram represents the relationship of the configuration tables.

Configuring SOX Express

Enabling Optional Reporting Tools 79

About the Reporting Schema Scripts


SOX Express ships with two SQL scripts that demonstrate how to use the OP_REPORT_MGR
package to load the reporting configuration. By default, the scripts are configured to support
the default SSS (SOX Standard Schema) shipped with SOX Express.
The supplied scripts are:
ReportingSchema_Core.sql

Cleans up the reporting schema configuration tables


Registers the database objects to represent the SOX-specific content types and sets
their properties. The default database object is a materialized view.
Registers the columns that represent the core (system) attributes common to resources
of all content types in the system.
Registers the relationships between the various tables.
Registers the level labels for the content types that can be nested.

ReportingSchema_ProcessCentric_Delta.sql

Registers the remaining extended attributes defined in the SSS.

Note: The ReportingSchema_ProcessCentric_Delta.sql script only needs to be run the first time
you load the configuration into the reporting schema. Subsequently, it will only need to be run
if the schema of the SOX Express is modified in some way.

Executing the Configuration Scripts


To configure the reporting schema, log in as the openpages user and manually run both scripts
in SQL*Plus on the Oracle server machine in the following order:
sqlplus> ReportingSchema_Core.sql;
sqlplus> ReportingSchema_ProcessCentric_Delta.sql;

Customizing the Reporting Schema Configuration


To modify the reporting schema configuration, you can use any of the following methods:

Changing the supplied scripts


You can edit the supplied scripts and do a complete reload of the configuration data.
You can repeat this process as many times as necessary, as long as you run both
scripts - first loading the core attributes, and then the extended attributes.

Incrementally adding new content types and attributes


You can create additional scripts using the existing ones as a reference to register
additional content types or additional attributes for already registered content types.

Editing data directly in the database


In some cases, it might be easier to make minor changes or test new settings by
editing the contents of the configuration tables directly. Only experienced DBAs should
attempt this procedure, however, as the risk of user error is prominent.

Naming Restrictions
When customizing your schema configuration or contents, the following naming restrictions
must be followed: Object (table, view, or materialized view) and column names must be 30
characters or less and must be valid Oracle names (containing only alphanumeric characters,
dollar sign($), hashes(#), and underscores(_).
Mixed case names, names containing spaces, and international characters are not supported.
Object names must be unique in the application user schema. Column names must be unique
within the scope of a single object.

Configuring SOX Express

Enabling Optional Reporting Tools 80

Supported Macro Keywords


Currently, the following macro keywords can be used to specify the data transformation of the
property values inside the configuration tables.

[FriendlyName] - applies to the resource name, resulting in the original resource name
with the extension removed.
[SoxUrl<;hostname:port>] - applies to the resource ID, resulting in the URL to view
the resource properties (the Details page) in the SOX Express user interface.
Note: If the hostname and port information is omitted, the SoxUrl defaults to
localhost:7009. If you are using third-party reporting tools such as CommandCenter
or Crystal Reports, you must modify the macro to explicitly specify the host server
name and port of the SOX Express application server. For load-balanced configurations,
you can specify different values in the hostname and port for different content
types.

[DelimitedList] - applies to the multi-valued properties, resulting in a comma-separated


list of values.
[LockStatus] - applies to the resource ID, resulting in an indication whether there is a
specific lock on the resource. This does not include checked-out locks.
[NestingPath] - applies to the resource ID of the nested content types (business
entities, sub-accounts, and sub-processes), resulting in a concatenated string of the
friendly names of the resource and all its subordinate objects of the same type.
[NestingLevel] - applies to the resource ID, resulting in a numeric value representing
the object level in the hierarchy of nested objects of the same type.
[NestingLabel] - applies to the resource ID, resulting in a value that represents the
nesting level.

If any of the columns for a given content type use one of the Nesting* macros, the resulting
database object will contain a level-based hierarchy representation, where each level of nesting
is represented by a column. The extra columns are named according to the level labels defined
for the corresponding content type.
If no level labels were defined for a given level, the column will be named as LEVEL<#> (e.g.
LEVEL1, LEVEL2, etc.)
Note: It is strongly recommended that you define level labels to accommodate the expected
depth of object nesting for a given implementation, because the algorithms that populate the
reporting schema rely only on the configuration data and do not validate whether the real data
has additional levels of nesting than were originally declared.
The following picture shows a table with the nesting and level-based hierarchy columns:

Configuring SOX Express

Enabling Optional Reporting Tools 81

Populating the Reporting Schema


After loading the reporting schema configuration, you can create and populate the dynamic
portion of the reporting schema by executing the supplied command file (Refresh-ReportingSchema.cmd) and providing the required input parameters.
Note: For the Refresh-Reporting-Schema.cmd file to work correctly, the Refresh-ReportingSchema.sql file must be located in the same directory as the command file.
To populate the reporting schema:
1.
2.
3.

Open a command window on the Oracle database server.


Navigate to the directory containing the Refresh-Reporting-Schema.cmd batch file.
Execute the Refresh-Reporting-Schema.cmd file using the following syntax:
Refresh-Reporting-Schema.cmd
<OracleUserName> <OracleUserPassword> <OracleAlias>
<ReportingPeriodValue> [<AddReportingPeriodColumn>
[<ReportingPeriodColumnName> [<BackwardCompatibilityMode>]]]
where:
<OracleUserName> is the name of the Oracle user account used by the SOX Express
application to connect to the database. This is a required parameter.
<OracleUserPassword> is the password of the Oracle user account. This is a
required parameter.
<OracleAlias> is the Oracle Net Alias, a friendly Oracle instance system identifier or
connection string. Usually this is the same as the SID. This is a required parameter.
<ReportingPeriodValue> - is a value to be inserted into the Reporting Period
column. This is a required parameter. Can be any arbitrary string. If the string contains
spaces, it must be enclosed with double quotes. The special keyword auto can be
used to populate the reporting period column with a timestamp representing the time
that execution of the Refresh-Reporting-Period.cmd was started. Specifying a value of
no, none, null, or nothing will cause the default value of
<AddReportingPeriodColumn> to flip to no, and a reporting period column will not be
added unless the <AddReportingPeriodColumn> is explicitly set to Yes.
<AddReportingPeriodColumn> - indicates whether the reporting period column
should be added to all objects created during the reporting schema refresh. Allowed
values are yes and no. This is an optional parameter that defaults to yes if it is not
included in the parameter list. The reporting period column can be used to uniquely
identify data produced by different reporting schema refresh sessions, if the user
chooses to load the data into a dedicated data warehouse.
<ReportingPeriodColumnName> - specifies a physical name for the reporting
period column. Defaults to none. When the default value is used, the reporting period
column is named REPORTING_PERIOD. This is an optional parameter.
Note: When the Refresh-Reporting-Schema.cmd is run, it will automatically turn on
Oracle Statistics for the following tables: all tables beginning with SX_, and the
EFFECTIVE_RIGHTS table.

Configuring SOX Express

Enabling Optional Reporting Tools 82

Checking the Results of the Reporting Schema Refresh


On every execution, the command line utility creates a new log file named in the format of
Refresh-Reporting-Schema-YYYY-MM-DD#HH-MM-SS.log.
After the command executes, review the file for any possible errors and to get information
about what input parameters were used for a given execution session, as well as the time it
took to refresh the reporting schema.
Below is a sample of a successful reporting schema refresh:
Refreshing Reporting Schema...
Execution started at 2004-10-13 16:25:03.53
Input parameters:
Add reporting period column: [yes]
Column name: [Default/Not specified]
Column value: [Auto generated/not specified]
Backward compatibility mode: [Not requested]
Execution finished at 2004-10-13 16:52:02.73
Elapsed time: +000000000 00:26:59.209000000
PL/SQL procedure successfully completed.
The sample log below illustrates the errors logged when the reporting schema configuration
was not loaded or was incomplete:
ERROR at line 1:
ORA-20100: Reporting schema metadata are not loaded
ORA-06512: at "OPENPAGES.OP_EXPORTER", line XXXX
ORA-06512: at line 1
This sample log corresponds to a situation where a reporting schema refresh is attempted, but
another schema refresh session or compliance object reset event is in progress:
ERROR at line 1:
ORA-20100: Another reporting schema refresh operation in progress
ORA-06512: at "OPENPAGES.OP_EXPORTER", line XXXX
ORA-06512: at line 1

Synchronization Control
Because during the reporting schema refresh database objects can be dropped and created,
this operation is implemented as a single instance task. To enforce that no more than one
refresh operation can be executed at any given time, the RPT_LOCK table is used.
As the reporting schema refresh and the compliance object reset operations both use and
modify a common subset of the database objects (namely the NODES table and the
EFFECTIVE_RIGHTS materialized view), those operations cannot be executed at the same time.
The RPT_LOCK table can be used to verify if reporting schema refresh is in progress and its
current status. If refresh is being executed, the table will contain a single record, otherwise the
table will be empty. For more information about the table layout and usage sample refer to the
diagram below:

Configuring SOX Express

Enabling Optional Reporting Tools 83

The following is an example of checking for the currently running reporting schema refresh jobs
and their status using SQL*Plus:
column
column
column
column
column

initiator format a40


active_module format a40
start_time format a30
entry_time format a30
last_heartbeat format a30

select * from rpt_locks;

Exporting Data to the Reporting Database Instance


After the contents of the reporting schema are created (refreshed), it must be copied to a
dedicated reporting instance. This is a two-step process - first the data must be exported
outside the live application instance, and then loaded into the dedicated reporting Oracle
instance.
The following sections will explain the procedures required to export the reporting schema to
the reporting instance.
Note: To run the Export-Reporting-Schema.cmd command file, the Generate-ExportParams.sql script must be located in the same directory as the command file.

Exporting the Reporting Schema Contents


To export the required reporting schema database objects:
1.
2.

Open a command prompt on the database server machine and navigate to the location
of the Export-Reporting-Schema.cmd command file.
Execute the Export-Reporting-Schema.cmd file with the following syntax:
Export-Reporting-Schema.cmd
<OracleUserName> <OracleUserPassword> <OracleSID> <NLS_LANG>
where:
<OracleUserName> is the name of the Oracle user account used by the SOX Express
application to connect to the database. This is a required parameter.
<OracleUserPassword> is the password of the Oracle user account. This is a
required parameter.
<OracleSID> is the Oracle instance system identifier or service name. This is a
required parameter.
<NLS_LANG> is the national language setting to be used for the data export session.
This is a required parameter.

Note: In order to run the export command successfully, SQL*Plus and the Oracle EXP utility
must be installed on the Oracle database server.
After completion, the command line utility creates four files:

reporting-schema-exp-parameters1.txt - contains the export parameters used by the


EXP utility.
reporting-schema-exp-parameters2.txt - also contains the export parameters used by
the EXP utility.
rpt-exp_YYYY-MM-DD#HH-MM-SS.log - provides statistics about the data exported and
any error information.
rpt-exp_YYYY-MM-DD#HH-MM-SS.dmp - export file containing data and object
definitions for the reporting schema.

Configuring SOX Express

Enabling Optional Reporting Tools 84

Importing the Reporting Schema Contents


Importing the data is a two-step process. First, you must import the contents, constraints, and
indexes for all of the reporting schema tables, except for the RPT_OBJECTS, RPT_RELATIONS,
EFFECTIVE_RIGHTS, ACTORINFO and FOLDERS tables.
Then import the contents and indexes for the above-mentioned tables.
Note: The constraint definitions for those tables should not be imported, as foreign keys on
those tables reference other tables which are not part of the reporting schema and are not
exported.
To simplify the importing process, you can use a copy of the reporting-schema-exp-params.txt
file to create a parameter file for the Oracle IMP utility.
For information about the format of Oracle parameter files for the EXP/IMP utilities consult your
Oracle product documentation.
Note: It is possible to import the entire data dump file and review the reported errors.
However, only the foreign key creation errors for the above-mentioned tables can be safely
ignored.
Currently, in order to load updated data, the existing database objects have to be dropped. As
part of the SOX installation, the AuroraDBDelete.sql script is supplied, which can be used to
drop all the objects in the user schema. This script can be executed in SQL*Plus.
Note: Exercise caution when executing the script, as the script removes all objects owned by
the currently connected user.
Once the contents are imported successfully, the reporting schema data source is ready to be
accessed by the third-party query engine.

Configuring SOX Express

Changing the Database Passwords 85

Changing the Database Passwords


Overview of Changing the Database Passwords
Occasionally, you may need to update or change the Oracle or WebLogic system password.
When you do, you will also need to update the password in various places inside SOX Express
configuration files and property files.

Changing the Oracle Password


The default Oracle username/password used by SOX Express is openpages/openpages. To
change the password, you will have to modify the following files:

config.xml
config.xml.keep
aurora.properties
autoexnt.bat
op-backup-recovery.env

Note: Be sure to backup each file before making any modifications.


To change the default Oracle username/password:
1.
2.
3.
4.

5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

Stop the OpenPages Application Server.


Change directories to the directory <WL_HOME>\config\OpenpagesDomain.
Open the file config.xml in a text editor.
Search for the string JDBCConnectionPool and change the value for the attribute
Password to your new password. The password will be encrypted automatically the
next time the service accesses the file.
Save the file and exit the text editor.
Repeat the above steps for the config.xml.keep file.
Change directories to the <WL_HOME>\aurora\conf directory.
Open the aurora.properties file in a text editor.
Search the file for the string database.PASSWORD.
Change the value following the equals sign to the new password.
Save your changes and exit the editor.
Change directories to the c:\Windows\System32 directory.
Open the autoexnt.bat file in a text editor. In the first java command, you will see the
Oracle password (next to the port number at the end of the string).
Change the string to the new password.
Save your changes and exit the editor.
Change directories to the <WL_HOME>\aurora\bin directory.
Open the op-backup-recovery.env file in a text editor.
Find the line that starts DB_OP_PWD and change the value of the variable to the new
password.
Save your changes and exit the editor.
Restart the OpenPages Application Server.

Configuring SOX Express

Changing the Database Passwords 86

Changing the WebLogic Password


In order to change the password for the BEA WebLogic server, you will first need to change the
password inside WebLogic, and then change all references to that password inside the SOX
Express environment.

Changing the Password in WebLogic


To update the WebLogic password in BEA WebLogic:
1.

Log onto the application server and stop all the SOX Express application services except
OPAdminWLS.
2. Log into the BEA WebLogic administration console (http://<servername>:7001/
console).
3. Select the Compatibility Security|Users option in the left-hand menu.
4. On the Users screen, there is an option to change the password.
5. Enter system (without the quotes) into the Name field.
6. Enter the current system password in the Old Password field, and the new password in
the New Password field.
7. Click the Change button to save your changes.
8. A link titled Click here to save these changes to the realm implementation. will appear
in the upper right of the Users window. Click the link to save the changes to the realm.
9. A confirmation dialog will appear. Click Continue and close the Administration Console.
10. Navigate to the \bea\weblogic81\config\OpenpagesDomain directory and open the
boot.properties file using a text editor
11. Set password to the new password in clear text. This will get encrypted the next time
the server starts.

Changing the Password References in SOX Express


To modify all references to the BEA WebLogic password in SOX Express:
1.

2.
3.

4.
5.
6.

Shut down the OPAdminWLS service. (This assumes that the other services are already
stopped from changing the password in WebLogic. If the other SOX Express services
are running, shut them down also.)
Navigate to the <WL_HOME>\config\OpenpagesDomain directory.
Edit the following files:
startWebLogic.cmd
startPublishwebServer.cmd
startOPAppServer.cmd
startSOSAServer.cmd
In each file, find the following line:
set WLS_PW=<old-password>
Replace the old password with the new system password for WebLogic.
set WLS_PW=<new-password>
In each .cmd file, change the password parameter in the JAVA command to reflect the
new password:
-Dweblogic.management.password=<old-password>
to

7.
8.

-Dweblogic.management.password=<new-password>
Finally, edit the password.ini file and change the old password to the new one.
Restart the SOX Express services.

Configuring SOX Express

Changing the Database Passwords 87

Changing Your Server IP Address


When changing the IP addresses of the application and database server and keeping the
machine name the same, you will have to delete the .wlnotdelete folders in your SOX Express
installation directory.
The folders are located under the \bea\weblogic81\config\OpenpagesDomain directory, in the
\applications folder, and in the four folders that correspond to the four servers. Before
removing the folders, you will need to shut down all application servers and then remove all
five folders.

Configuring SOX Express

88

4
Modifying SOX Express
Behavior
This chapter provides information about administering the SOX Express application, including
adding and removing SOX Express users, report administration, and adding custom fields to
SOX Express compliance objects.
This chapter contains the following topics:

Customizing the Overview Pages on page 89


Modifying Compliance Objects on page 92
Additional Modifications on page 108
Using Netegrity SiteMinder on page 119

Modifying SOX Express Behavior

Customizing the Overview Pages 89

Customizing the Overview Pages


About Customizing the Overview Pages
SOX Express allows administrators to control which compliance objects are displayed in the
Entity Overview, Process Overview, and Account Overview pages. By modifying the settings in
the configTileDefinitions.xml file, compliance object types (risks, controls, etc.) can be removed
from the Overview pages.
In addition, you can toggle the shift-click Expand All behavior of the overview pages by
changing a configuration file setting.
The modifications to the overview pages are detailed in the following sections:

Modifying the Overview Page Definitions on page 89


Enabling/Disabling the Expand All Capability on page 90

Modifying the Overview Page Definitions


Once an object type is removed from the page definition, it will no longer be displayed in the
Overview page along with any object types that are associated with it.
For example, if you remove Controls from the Entity Overview page, they will no longer be
displayed as you expand the Entity Overview page. The ICDocumentation structure will appear
to stop at the Risk level. In addition, Tests and Test Results will no longer be displayed, since
the Controls they are associated with are not present in the Entity Overview page.
There are two things to keep in mind when modifying which compliance objects are displayed in
the Overview pages:

Compliance objects below the removed object type will not be displayed - think
carefully before removing an object type from an overview page.
Any changes to the Overview pages are applied to everyone in the system. There is no
way to restrict the modified view to a certain sub-set of users. All users will see the
same modified Overview page.

The custom definitions for the three Overview pages are kept in the configTilesDefinitions.xml
configuration file, located in the config\OpenpagesDomain\applications\sosa\WEB-INF directory
of your SOX Express installation.
You must have write access to the OpenPages server machine in order to modify the
configuration file.
Note: When modifying an Overview page, restrict your modifications to the
configTileDefinitions.xml file. This file overrides the default definition and will not be overwritten
during an upgrade procedure.
To modify an Overview page:
1.
2.
3.

Back up the existing configTileDefinitions.xml file.


Open the configTileDefinitions.xml file in a text editor.
Find the definition tag for the overview page you wish to modify. Search for:
account.overview to display the Account Overview definition
entity.overview to display the Entity Overview definition
process.overview to display the Process Overview definition

Modifying SOX Express Behavior

Customizing the Overview Pages 90

4.

5.

Each definition contains a commented-out putList statement which contains the


definition for the overview page. Uncomment the entire definition. The putlist
statement should look like the following:
<putList name="types.list" >
<add value="SOXBusEntity" />
<add value="SOXAccount" />
<add value="SOXSubaccount" />
<add value="SOXProcess" />
<add value="SOXSubprocess" />
<add value="SOXControlObjective" />
<add value="SOXRisk" />
<add value="SOXControl" />
<add value="SOXTest" />
<add value="SOXTestResult" />
</putList>
Find the line which corresponds to the compliance object type you want to remove and
comment it out. For example, to remove Risks from the overview page, modify the
definition to look like the following:
<putList name="types.list" >
<add value="SOXBusEntity" />
<add value="SOXAccount" />
<add value="SOXSubaccount" />
<add value="SOXProcess" />
<add value="SOXSubprocess" />
<add value="SOXControlObjective" />
<!-<add value="SOXRisk" />
-->
<add value="SOXControl" />
<add value="SOXTest" />
<add value="SOXTestResult" />
</putList>
Remember that removing Risks from the overview page will also remove Controls,
Tests, and Test Results. You do not need to comment out each type - merely the
topmost element.
Note: The order of the elements in the overview page definition does not determine the
order in which the object types are associated or displayed. For example, if you
commented out the SOXSubaccount line in the Account Overview definition,
processes that are associated with accounts would still be displayed, while processes
associated with subaccounts would not.

6.

Repeat the above steps for each overview page and save your changes. You must
restart the SOX Express server for the changes to take effect.

Enabling/Disabling the Expand All Capability


SOX Express allows users to press shift-click when clicking on the plus icon next to a
compliance object in order to expand all levels of the object hierarchy. This behavior is turned
off for the highest levels of the entity hierarchy (business entities and top-level folders).
In a large-scale system, users capable of viewing all of the objects in the compliance object
hierarchy can experience slow behavior when expanding all from the top levels of the hierarchy.
If you wish to enable the ability to expand all from the business entity and folder levels of the
entity hierarchy, add the following line to the sosa.properties configuration file, located in the
\sosa\conf directory of your SOX Express installation. You will have to restart the server after
making the changes.
expand.selection.enabled = true
To disable the functionality once you have enabled it, either remove the line or comment it out.
Modifying SOX Express Behavior

Customizing the Overview Pages 91

Modifying the Overview Node Cache


The sosa.properties file (located in the \applications\sosa\conf directory of your SOX Express
installation) contains a parameter that controls the number of objects that each node of the
overview page can contain for each user session.
To change the maximum number of nodes displayed in the Overview cache, modify the
following setting:
overview.node.cache.capacity=1000
If the number of nodes displayed exceeds the above setting, the additional nodes will not be
displayed. Each cached object requires 1600 bytes of memory.
After making your changes, you must restart SOX Express.

Modifying SOX Express Behavior

Modifying Compliance Objects 92

Modifying Compliance Objects


Overview of Modifying Compliance Objects
SOX Express allows administrators to add new properties to the various compliance objects
(business entities, accounts, processes, risks, etc.) involved in the internal controls
documentation project, as well as hiding existing properties. Each object has certain properties
already defined for it, such as Account Type, Transaction Volume, etc.
The following paragraphs provide a quick overview of the steps required to add a new field to a
compliance object.
Step One: Identifying the New Field
The first step is identifying what type of field you want to add to the object - what type of data
you intend to collect, and how that data will be selected and/or stored. SOX Express supports
many different types of fields, which will be explained in more detail in later sections.
Step Two: Defining the Field Properties
The next step is creating a new property bundle that contains the property definition of the new
field(s). The property definition stores the data entered into the field. It is recommended that if
you are creating more than one new field for a compliance object, you store all of the custom
property definitions in the same property bundle.
Step Three: Attaching the Property Bundle
Each type of compliance object (business entity, account, process, etc.) has a corresponding
content type that gathers all of the different property bundles used by the compliance object.
Once the new property bundle is created, it must be attached to the appropriate content type.
Step Four: Displaying the New Field
Once the property bundle for the new field is attached to the compliance objects content type,
the display definition of the object must be modified to include the new field. In this step, you
will determine where the new field will be displayed on the details page.
Step Five: Activating the New Field
Once the previous steps are completed, the SOX Express application must be restarted to
recognize the new field.

Example: Adding a New Text Field


During the following procedure, you will be shown an example of how to create a new text field.
Additional examples of adding property fields will follow the procedure.
The following instructions will allow users to add new custom property fields to compliance
objects.

Step One: Identifying the New Field


The first step when adding a new field is to examine what sort of field you want to add, and
which compliance objects you wish to modify. Planning your changes ahead of time helps to
minimize the necessary work, and perhaps prevent duplication of effort. Prior to beginning the
creation of the new field, you should identify the following information:

the affected compliance object - Which compliance object or objects will the new field
be added to?
the name - How will the new field be identified?
the label - What text will be displayed on the Details screen? This information will also
appear when adding and editing a compliance object.
the property type - What form input element (text field, text area, drop-down, etc.) will
be used to capture the data?

Modifying SOX Express Behavior

Modifying Compliance Objects 93

Example: Identifying the New Field


In our example, we wish to add a Process Owner, Account Owner, Control Owner, etc. to
each object. To do this, you would have to create a property bundle and a new field for each
compliance object type - one for accounts, one for processes, etc.
However, if we simply create an Owner field for all objects, we will only need to create one
property bundle for the new Owner field, and simply re-use later if we want to add it to each
compliance object type. This simplifies the work we have to do, so we will follow this approach.
For the purposes of this example, we will add it to the Account object.
So, we know that we want to apply the new field to the Account object. We need to determine
a name for the new field - well call it Owner. The name of the field is important, because it is
also the text that will appear next to the field when it is displayed, followed by a colon (:). Since
we chose to name the new property Owner, the text next to the new field will read Owner:.
We are only entering a name into the field, so the property type for this field will be Simple
String.

Step Two: Defining the Field Properties


The next step in adding a new field to a compliance object is to create a new property bundle
that will contain the definition of the new property (or properties) you wish to add. Each new
field requires a corresponding property. The property stores the information entered into the
new field.
Note: For additional information about property bundles, see the OpenPages User Manual.
To define the property for the new field:
1.
2.

Log into the OpenPages server as a user with Administrative permissions.


Click the Property Bundles link under the Administration heading in the left-hand
Action menu. The Property Bundles page is displayed.

Add Bundle
Button

Modifying SOX Express Behavior

Modifying Compliance Objects 94

3.

Click the Add Bundle... button. The Describe Property Bundle page is displayed.

4.

Enter a name and description for the property bundle in the respective fields.
For our example, the new custom property bundle will be called CustomFields. We will
use this name for the new property bundle in future steps. Replace CustomFields with
your property bundle name as necessary.

5.

Click the Next button. The Define Properties page is displayed.

New Button

Property
Definition
Area

6.

Initially, there are no properties defined for the bundle. To start defining properties,
click the New button. The Select Property Type page is displayed in a pop-up window.

The Select Property Type page enables you to select the type of information that the
property is going to contain.
For explanations of the different property types, access the online help or the
Openpages 5.0 User Manual.

Modifying SOX Express Behavior

Modifying Compliance Objects 95

7.

Select the desired property type and click the OK button. The Define Properties page is
displayed with new controls available and active in the property definition area.
For our example, we will choose the Simple String property type.
If at any point in the process you realize that you have made an error, you can click the
Reset button to clear all the fields. If you have accidentally selected the wrong
property type, you can click the New button again to select another type.

8.

Enter a name and description that you want to use for the property type. Names are
mandatory for all property types.
For our example, we will use the name Owner for our new property.

9. Enter the all other information that you need to specify for the property.
10. If you want the property to be required, meaning that the user must provide a value for
this property when the file is added to the system, click the Value Required checkbox
so that it is selected.
Since we want every account to have an owner, we will select the Value Required
checkbox for the Owner property.
11. When you have finished defining the property, click the Apply button to save your
changes and add the property to the bundle. The property is added to the property list.

Property
List

Delete
Button

Finish
Button

12. When you are finished defining properties for the bundle, click the Finish button. The
new property bundle is saved and is displayed on the Property Bundle page.

Example: Defining the Field Properties


So, in Step One, we created a new property bundle which we called CustomFields. We then
added a new Simple String property to the property bundle and named it Owner. We also
decided that the new fields value must be required when a new account is created or modified.
After saving our changes, it is time to attach the property bundle to the desired compliance
object (in this case, the Account object).

Modifying SOX Express Behavior

Modifying Compliance Objects 96

Step Three: Attaching the Property Bundle


The next step in the procedure is adding the newly created property bundle to the content type
for the compliance object we want to change. There is a content type for each compliance
object:

Content Type

Compliance Object

SOXAccount

Accounts

SOXBusEntity

Business Entities

SOXControl

Controls

SOXControlObjective

Control Objectives

SOXDocument

Associated Files

SOXIssue

Issues

SOXMilestone

Project Milestones

SOXProcess

Processes

SOXProject

Projects

SOXRisk

Risks

SOXSubaccount

Sub-Accounts

SOXSubprocess

Sub-Processes

SOXTask

Project and Issue Action Items

SOXTest

Control Tests

SOXTestResult

Control Test Results

To add the property bundle to a content type:


1.

2.
3.
4.
5.
6.

While logged into OpenPages with an administrative-level account, click the Content
types link under the Administration heading in the left-hand Action menu. The list of
available content types is displayed.
Click on the name of the content type you want to edit. The Details page is displayed.
Click the Edit button under the Property Bundle Information heading. The Assign File
Types and Property Bundles page is displayed.
Click the Add button on the list of property bundles. A list of available property bundles
is displayed.
Highlight the name of the custom property bundle you just created and click Ok to add
the property bundle to the content type.
Click Save to save your changes and return to the Details page for the content type.

Example: Attaching the Property Bundle


In Step One, we decided that we wanted the new Owner field to be added to the Account
object. We created a new property bundle called CustomFields in Step Two. Using the above
procedure, we now select the SOXAccount content type and add the new CustomFields property
bundle to the content type. If we wanted to use the new field in more than one compliance
object, we would repeat the above procedure for each object type.

Modifying SOX Express Behavior

Modifying Compliance Objects 97

Step Four: Displaying the New Field


The next step in the process of enabling your new property is to edit the
configTileDefinitions.xml file so that your new property is recognized by the SOX Express
application.
To activate the new property:
1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object>.prop.body where <object> is the object you want to modify. For
example, if you are modifying an account, the string would be account.prop.body.
4. Remove the comment tags (<!-- and -->) from the object definition if this is the
first time you are modifying the object.
5. Modify the <putlist> tag to include the definition for the new property, as in the
example below:
<putList name="property.list">
<add value="account.property.accountType"/>
<add value="account.property.newProp"/>
</putList>
The order of the property definitions controls the order in which they will be listed on
the object Details page and in the Add and Edit pages. Insert the new property
definition into the spot where you want the property to be listed.
Make sure the name for the new property definition (i.e. account.property.newProp in
this example) does not inadvertently match another property definition already defined
for the object.
Note: When modifying the Business Entity definition (busentity.prop.body), you must
remove the three sample property definition lines from the sample business entity
definition. The lines to be removed are:
<add value="customer.busentity.property.newProp"/>
<add value="customer.entity.property.ExecutiveOwner"/>
<add value="customer.entity.property.PrimaryOwner"/>

6.

Add the definition tag for the new property after the <definition> end tag containing
the <putlist> tag, using the format of the example below. A sample definition tag can
also be found in the XML file. Portions of the example in bold text should be replaced
with text specific to your property.
<definition>
<putList name="property.list">
<add value="account.property.accountType"/>
<add value="account.property.newProp"/>
</putList>
</definition>
<definition name="account.property.newProp">
<put name="bundle.name" value="TestBundle"/>
<put name="property.name" value="AddedProperty"/>
</definition>

Modifying SOX Express Behavior

Modifying Compliance Objects 98

The string account.property.newProp should be replaced with the property definition


name you assigned in step 4. The string TestBundle should be replaced with the name
of your new property bundle. The string AddedProperty should be replaced with the
name of the new property you created in Step One.
Make sure you match the spelling and case of the property bundle and property name
exactly.
7.

Save the configTileDefinitions.xml file.

Example: Displaying the New Text Field


Now we are ready to insert the new field into the Account detail page. When we open the
configTileDefinitions.xml file, we locate the section that relates to the account compliance
object. That section looks like this:
<definition name="account.prop.body"
extends="icdocumentation.property.form.body">
<putList name="property.list">
<add value="account.property.accountType"/>
<add value="account.property.accountNumber"/>
<add value="account.property.assertions"/>
<add value="account.property.sizeOfAccount"/>
<add value="account.property.transactionVolume"/>
<add value="account.property.importanceOfErrors"/>
<add value="account.property.susceptibilityToFraud"/>
<add value="account.property.recentChanges"/>
<add value="account.property.additionalInfo"/>
<add value="account.property.classification"/>
<!-- add new property here - EXAMPLE
<add value="account.property.newProp"/>
-->
</putList>
</definition>
We decide that the owner should be listed first - before the Account Type: field. So, using the
text editor, we add the following line before the accountType line, like so:
<definition name="account.prop.body"
extends="icdocumentation.property.form.body">
<putList name="property.list">
<add value="account.property.accountOwner"/>
<add value="account.property.accountType"/>
<add value="account.property.accountNumber"/>
...
</putList>
In this example, weve named the new value account.property.accountOwner, but we could
have called it anything, as long as we create a property definition that shares the same name.
Now that weve added account.property.accountOwner as a property in the property list, we
need to add a definition for the property in the same file. Below the list of account properties,
there is a sample definition that looks like this:
<definition name="account.property.newProp">
<put name="bundle.name" value="TestBundle"/>
<put name="property.name" value="Added Property"/>
<put name="field.length.maximum" value="128" />
</definition>

Modifying SOX Express Behavior

Modifying Compliance Objects 99

We copy the sample definition and paste it outside the comment markers (<!-- -->), so that
when the file is read by the server, it will not be ignored. We then modify the pasted definition
tag to look like the following:
<definition name="account.property.accountOwner">
<put name="bundle.name" value="CustomFields"/>
<put name="property.name" value="Owner"/>
<put name="field.length.maximum" value="128" />
</definition>
The first line is changed to match the name of the property value we added to the property list
- in this case, account.property.accountOwner. The bundle.name line is modified to include
the exact name of the property bundle we created in Step Two - CustomFields. The
property.name line is modified to include the exact name of the property we added - Owner.
Once the new field definition is added, we save our changes and exit the editor.

Step Five: Activating the New Field


Contact your SOX Express Administrator and have him restart the SOX Express application
server. Once the server is restarted, verify that the new property has been successfully added
by modifying an existing object and entering a value for the new property.
Note that existing objects of the type you modified will not display the new property when you
view the Details screen. However, when the object is edited, the new property will be displayed
correctly, including any default values. In addition, once the object is opened for editing the
Value Required attribute of the property will be enforced, if present.

Example: Adding a New Text Area Field


In this example, we will add a new text area field called Description of Failure to a test result.
In effect, the process is the same as adding a simple text field.
First, we create a new property bundle, which we give a unique name, such as
TestResultCustomFields. Then we create the property for the new text area. Single-line text
fields and multi-line text areas both use the Simple String property, so we create a new Simple
String property and name it Description of Failure. Remember that the name of the property
is also the text that will appear next to the new field when the Details page is displayed, so
check for typographical errors and spelling.
Once we save the new TestResultCustomFields property bundle, we need to edit the
configTileDefintions.xml file. Use the directions in Step Four: Displaying the New Field to open
the configTileDefinitions.xml file for editing, and find the Test Result definitions area, which
looks like this:
<!--======= Test Result Definitions - Start =======-->
<definition name="testresult.prop.body"
extends="icdocumentation.property.form.body">
<putList name="property.list">
<add value="testresult.property.date"/>
<add value="testresult.property.by"/>
<add value="testresult.property.result"/>
<add value="testresult.property.effective"/>
</putList>
</definition>
<!--======= Test Result Definitions - End ========-->

Modifying SOX Express Behavior

Modifying Compliance Objects 100

Uncomment the object definition by removing the comment tags (<!-- and -->) from
around the definition.
In this example, we want to put the Description of Failure field at the end of the list, so that it
is the last field displayed. Copy the last <add value... /> line and paste it in front of the
</putlist> tag. When you are finished, the section should look like this:
<!--======= Test Result Definitions - Start =======-->
<definition name="testresult.prop.body"
extends="icdocumentation.property.form.body">
<putList name="property.list">
<add value="testresult.property.date"/>
<add value="testresult.property.by"/>
<add value="testresult.property.result"/>
<add value="testresult.property.effective"/>
<add value="testresult.property.effective"/>
</putList>
</definition>
<!--======= Test Result Definitions - End ========-->
Modify the line to reference the new definition you will create for the new field. When you are
finished, the section looks like:
<!--======= Test Result Definitions - Start =======-->
<definition name="testresult.prop.body"
extends="icdocumentation.property.form.body">
<putList name="property.list">
<add value="testresult.property.date"/>
<add value="testresult.property.by"/>
<add value="testresult.property.result"/>
<add value="testresult.property.effective"/>
<add value="testresult.property.failure"/>
</putList>
</definition>
<!--======= Test Result Definitions - End ========-->
Now, we need to add the definition of the new field. Because we named the new value in the
previous step testresult.property.failure, the new definition will need to match this value
exactly. Here is a generic text area definition tag for you to copy and insert:
<definition name="account.property.newProp"
extends=textarea.property>
<put name="bundle.name" value="TestBundle"/>
<put name="property.name" value="Added Property"/>
</definition>
The new definition should look like this when you are finished:
<definition name="testresult.property.failure"
extends=textarea.property>
<put name="bundle.name" value="TestResultCustomFields"/>
<put name="property.name" value="Description of Failure"/>
</definition>
If you wish to change the display parameters of the text area - the height and width of the
input area - you must add the following two lines to the definition:
<put name="column.size" value="80"/>
<put name="row.size" value="6"/>
If we wanted to change the Description of Failure field to be 80 characters wide and 6 lines
tall, the modified text area definition would look like this:

Modifying SOX Express Behavior

Modifying Compliance Objects 101

<definition name="testresult.property.failure">
extends=textarea.property>
<put name="bundle.name" value="TestResultCustomFields"/>
<put name="property.name" value="Description of Failure"/>
<put name="column.size" value="80"/>
<put name="row.size" value="6"/>
</definition>
Once you save your changes and restart the SOX Express server, the new field will be displayed
in the Test Result details page.

Example: Adding a New Drop-down Selection Field


In this example, we will add a new drop-down selection field called Purpose of Control to a
control. Drop-down selections are useful when you have a field that has a finite set of known
values. They also make it easier to create reports based on the field value, because you can
accurately predict the values to look for, without worrying about idiosyncratic responses or
shorthand, such as Y instead of Yes.
First, we create a new property bundle, which we give a unique name, such as
ControlCustomBundle. Then we create the property for the new field. Drop-down selection
fields use the Enumerated String property type and the name for the new field will be
Purpose of Control. Remember that the name of the property is also the text that will appear
next to the new field when the Details page is displayed, so check for typographical errors and
spelling.
With an enumerated string property, you must specify the possible values in the property. We
will need three values for the property; well call them - Prevention, Identification, and
Error Recovery.
Type the three values into the Add value field under the Allowed Values section and hit Add
after each one. Because the vast majority of controls added into the system will deal with
Financial Reporting, click the drop-down next to the Default value heading and select
Financial Reporting. Then click the Apply button to save the new property. Click Finish to
save the new property bundle.
Once we save the new ControlCustomBundle property bundle, we need to edit the
configTileDefintions.xml file. Use the directions in Step Four: Displaying the New Field to open
the configTileDefinitions.xml file for editing, and find the Control definitions area, which looks
like this:
<!--======= Control Definitions - Start =======-->
<definition name="control.prop.body"
extends="icdocumentation.property.form.body">
<putList name="property.list">
<add value="control.property.classification"/>
<add value="control.property.documentationLocation"/>
<add value="control.property.controlType"/>
<add value="control.property.whoPerformsControl"/>
<add value="control.property.itDependent"/>
<add value="control.property.controlsTested"/>
<add value="control.property.walkthroughs"/>
<add value="control.property.controlEvaluation"/>
<!-- add new property here - EXAMPLE
<add value="control.property.newProp"/>
-->
</putList>
</definition>
<!--======= Control Definitions - End ========-->

Modifying SOX Express Behavior

Modifying Compliance Objects 102

In this example, we want to put the Purpose of Control field at the end of the list, so that it is
the last field displayed. Copy the last <add value... /> line and paste it in front of the
EXAMPLE line. When you are finished, the section should look like this:
<!--======= Control Definitions - Start =======-->
<definition name="control.prop.body"
extends="icdocumentation.property.form.body">
<putList name="property.list">
<add value="control.property.classification"/>
<add value="control.property.documentationLocation"/>
<add value="control.property.controlType"/>
<add value="control.property.whoPerformsControl"/>
<add value="control.property.itDependent"/>
<add value="control.property.controlsTested"/>
<add value="control.property.walkthroughs"/>
<add value="control.property.controlEvaluation"/>
<add value="control.property.newProp"/>
<!-- add new property here - EXAMPLE
<add value="control.property.newProp"/>
-->
</putList>
</definition>
<!--======= Control Definitions - End ========-->
Modify the line to reference the new definition you will create for the new field. When you are
finished, the section looks like:
<!--======= Control Definitions - Start =======-->
<definition name="control.prop.body"
extends="icdocumentation.property.form.body">
<putList name="property.list">
<add value="control.property.classification"/>
<add value="control.property.documentationLocation"/>
<add value="control.property.controlType"/>
<add value="control.property.whoPerformsControl"/>
<add value="control.property.itDependent"/>
<add value="control.property.controlsTested"/>
<add value="control.property.walkthroughs"/>
<add value="control.property.controlEvaluation"/>
<add value="control.property.Purpose"/>
<!-- add new property here - EXAMPLE
<add value="control.property.newProp"/>
-->
</putList>
</definition>
<!--======= Control Definitions - End ========-->
Now, we need to add the definition of the new field. Because we named the new value in the
previous step control.property.COSO_Objective, the new definition will need to match this
value exactly. Here is a generic drop-down definition tag for you to copy and insert:
<definition name="task.property.actionPlanType">
<put name="bundle.name" value="custom.bundle"/>
<put name="property.name" value="custom.property.name"/>
</definition>

Modifying SOX Express Behavior

Modifying Compliance Objects 103

The new definition should look like this when you are finished:
<definition name="control.property.Purpose">
<put name="bundle.name" value="ControlCustomBundle"/>
<put name="property.name" value="Purpose of Control"/>
</definition>
Once you save your changes and restart the SOX Express server, the new field will be displayed
in the Control details page.

Example: Adding a New HTML Field


In this example, we will add a new HTML-enabled field titled Additional Comments to the
Control compliance object. HTML-enabled fields allow users to add HTML-encoded text in the
field. This can be useful for adding a link to additional documentation, or embedding a table of
results from an external report.
First, we create a new property bundle, which we give a unique name, such as
ControlCommentBundle. Then we create the property for the new field. HTML-enabled fields
use the Simple String property type and the name for the new field will be Additional
Comments. Remember that the name of the property is also the text that will appear next to
the new field when the Details page is displayed, so check for typographical errors and spelling.
Click the Apply button to save the new property. Click Finish to save the new property bundle.
Once we save the new ControlCommentBundle property bundle, we need to associate the
new bundle with the SOXControl content type (using the procedure in Step Three), and then
edit the configTileDefintions.xml file. Use the directions in Step Four: Displaying the New Field
to open the configTileDefinitions.xml file for editing, and find the Control definitions area, which
looks like this:
<!--======= Control Definitions - Start =========-->
<!-- Uncomment this definition and alter list as necessary
<definition name="control.prop.body">
<putList name="property.list">
<add value="control.property.classification"/>
<add value="sox.property.rich.text.example"/>
<add value="control.property.documentationLocation"/>
<add value="control.property.controlType"/>
<add value="control.property.whoPerformsControl"/>
<add value="control.property.itDependent"/>
<add value="control.property.controlsTested"/>
<add value="control.property.walkthroughs"/>
<add value="control.property.controlEvaluation"/>
</putList>
</definition>
-->
<!--======== Control Definitions - End ==============-->

Modifying SOX Express Behavior

Modifying Compliance Objects 104

In this example, we want to put the Additional Comments field at the end of the list, so that it
is the last field displayed. Copy the last <add value... /> line and paste it on the next line.
When you are finished, the section should look like this:
<!--======= Control Definitions - Start =========-->
<!-- Uncomment this definition and alter list as necessary
<definition name="control.prop.body">
<putList name="property.list">
<add value="control.property.classification"/>
<add value="sox.property.rich.text.example"/>
<add value="control.property.documentationLocation"/>
<add value="control.property.controlType"/>
<add value="control.property.whoPerformsControl"/>
<add value="control.property.itDependent"/>
<add value="control.property.controlsTested"/>
<add value="control.property.walkthroughs"/>
<add value="control.property.controlEvaluation"/>
<add value="control.property.controlEvaluation"/>
</putList>
</definition>
-->
<!--======== Control Definitions - End ==============-->
Modify the line to reference the new definition you will create for the new field. When you are
finished, the section looks like:
<!--======= Control Definitions - Start =========-->
<!-- Uncomment this definition and alter list as necessary
<definition name="control.prop.body">
<putList name="property.list">
<add value="control.property.classification"/>
<add value="sox.property.rich.text.example"/>
<add value="control.property.documentationLocation"/>
<add value="control.property.controlType"/>
<add value="control.property.whoPerformsControl"/>
<add value="control.property.itDependent"/>
<add value="control.property.controlsTested"/>
<add value="control.property.walkthroughs"/>
<add value="control.property.controlEvaluation"/>
<add value="control.property.additionalComments"/>
</putList>
</definition>
-->
<!--======== Control Definitions - End ==============-->
Now, we need to add the definition of the new field. Because we named the new value in the
previous step control.property.additionalComments, the new definition will need to match this
value exactly. Here is a generic HTML-enabled field definition tag for you to copy and insert:
<definition name="sox.property.rich.text.example">
<put name="bundle.name" value="SOXRTF"/>
<put name="property.name" value="RTF"/>
<put name="display.type" value="rich.text.area"/>
<put name="row.size" value="250"/>
<put name="column.size" value="100%"/>
<put name="label" value="RTF" />
</definition>

Modifying SOX Express Behavior

Modifying Compliance Objects 105

The new definition should look like this when you are finished:
<definition name="control.property.additionalComments">
<put name="bundle.name" value="ControlCommentBundle"/>
<put name="property.name" value="Additional Comments"/>
<put name="display.type" value="rich.text.area"/>
<put name="row.size" value="250"/>
<put name="column.size" value="100%"/>
<put name="label" value="Additional Comments:" />
</definition>
If you wish to change the display parameters of the HTML area - the height and width of the
input area - you must modify the following two lines of the definition:
<put name="row.size" value="250"/>
<put name="column.size" value="100%"/>
Once you save your changes and restart the SOX Express server, the new field will be displayed
in the Control details page.

Hiding an Existing Object Property Field


If you do not need to display certain property fields in the compliance object Details page, you
can hide the field by modifying the configTileDefinitions.xml file and commenting out the field
identifier from the list.
One item to take into consideration when deciding to hide a field is that some reports rely on
certain property fields presence to run. Hiding a field that a report relies on can cause the
report to fail or return unexpected results.
The fields currently references by the supplied reports are:

Compliance Object

Referenced Properties

Accounts

Assertions

Processes

Process Type
Transaction Type
Impact
IT Process
Financial Statement Close Process

Controls

Control Evaluation
Control Type
Who Performs Control
Document Location
Walkthroughs
IT Dependent

Tests

Date Performed
Performed By
Test Result
Effectiveness

Project Items

Due Date

Action Items

Assignee
Start Date
Percent Complete
Business Location

Modifying SOX Express Behavior

Modifying Compliance Objects 106

To hide a property field:


1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

4.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object>.prop.body where <object> is the object you want to modify. For
example, if you are modifying an account, the string would be account.prop.body.
Uncomment the definition for the compliance object and modify the <putlist> tag to
comment out the list entry for the property to be hidden, as in the example below:
<putList name="property.list">
<add value="account.property.accountType"/>
<-- <add value="account.property.accountNumber"/> -->
</putList>
The above example would hide the Account Number field in the Account Detail page, as
well as from the Edit screen and from any reports run on accounts.

5.

Save the configTileDefinitions.xml file.

Modifying Property Labels


Each property of a compliance object has a label associated with it. The label is the descriptive
text that appears to the left of the property field. You can change the text of the label by
modifying the definition of the property in the configTileDefinitions.xml file.
If you want to modify a property that is not located in the configTileDefinitions.xml file, you
must create a definition that extends the original property definition. Then, replace the property
in the property list of the object definition and add the extended definition to the
configTileDefinitions.xml file. The following procedures will explain both methods of replacing
the property label.

Modifying an Existing Property in configTileDefinitions.xml


If the property definition already exists in the configTileDefinitions.xml file, you do not need to
re-copy the definition.
To modify an existing property label:
1.
2.
3.

Open the configTileDefinitions.xml file in a text editor.


Find the property definition for the property whose label you want to modify.
Add the following line to the property definition:
<put name="label" value="New Text Here" />
The value of name must be label and the value of value is the new text that will
replace the existing label.

4.

Save your changes to configTileDefinitions.xml and restart the services.

Modifying SOX Express Behavior

Modifying Compliance Objects 107

Modifying an Non-Existent Property in configTileDefinitions.xml


To modify a label for a property whose definition does NOT reside in the
configTileDefinitions.xml file, follow the procedure below:
1.
2.

Open the configTileDefinitions.xml file in a text editor.


Find the object definition for the compliance object that has the property label you want
to change.
For example, say you want to change the label of the Assignee property on the Task
compliance object. The Assignee property is not defined in the
configTileDefinitions.xml file, so well have to extend the definition here and provide a
new label. Here is a sample Task object definition from configTileDefinitions.xml.

3.

4.

<definition name="task.prop.body">
<putList name="property.list">
<add value="task.property.assignee"/>
<add value="task.property.businessLocation"/>
<add value="task.property.startDate"/>
<add value="task.property.dueDate"/>
<add value="task.property.percentComplete"/>
<add value="task.property.predecessor"/>
</putList>
</definition>
Now, replace the assignee property with the entry for the extended definition.
<definition name="task.prop.body">
<putList name="property.list">
<add value="extended.task.property.assignee"/>
<add value="task.property.businessLocation"/>
...
Provide the property definition for the extended property. The syntax for the extended
property looks like this:
<definition name="extended.task.property.assignee"
extends="task.property.assignee">
<put name="label" value="Responsible Person"/>
</definition>
The value of extends is the original property the new extended property is
augmenting.

5.

Save your changes to the configTileDefinitions.xml file and restart the services.

Modifying the Overview Label


If the modified property appears in an Overview page, you will also have to modify the property
in the Overview listing definition.

Modifying SOX Express Behavior

Additional Modifications 108

Additional Modifications
Overview
This section details some of the other modifications you can make to the appearance and
functionality of SOX Express.
Topics in this section include:

Configuring the Compliance Object Tables on page 108


Configuring the Compliance Object Listings on page 111
Configuring the User Selector Tool on page 114
Redirecting the SOX Express Logout Link on page 116

Configuring the Compliance Object Tables


When you view the Details page for a compliance object, the page contains tables for the
parent compliance objects, and the associated (child) compliance objects. These tables have
different columns that display varying information about the specific compliance object types.
For example, the Associated Accounts and Parent Accounts tables show three columns of
information: Name, Description, and Assertions. It is possible to modify the tables to display
additional columns with other property fields, or change the existing columns to show new
information, or to simply remove a column entirely.
When you modify the columns for a particular compliance object type, the change will appear
everywhere the object type appears in a table. You cannot specify different columns for the
Parent Accounts table and the Associated Accounts table, for example.
Note: The parameters of the table itself cannot be modified. Therefore, any information you
add must share the same table width as the rest of the table. If you add three columns to the
table, the table will still take up the same horizontal width as the original three columns. This
can lead to awkward screen layout and some unusual table formatting. It is recommended that
you only display the most important information using the table columns.

Adding a Column to a Compliance Object Table


To add a column to a compliance object table:
1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

4.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object> List Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account List
Definitions.
Uncomment the definition for the compliance object and modify the <putlist> tag to
add the list entry for the column to be added, as in the example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />

Modifying SOX Express Behavior

Additional Modifications 109

<add value="account.item.list.field.assertions" />


<add value="account.item.list.field.accountnumber" />
</putList>
The above example would add the Account Number field to the table in a new column.
The order of the values in the putList statement determines the order in which the
columns are displayed.
5.

Below the list definition for the compliance object type, create a new definition for the
field to be displayed in the new column. It should look like the following:
<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
</definition>
where the value of name matches the new value you added to the putList; the value
for type is always custom.property; the value for bundle is the property bundle
where the custom property is contained; and the value for property is the exact name
of the custom property to be displayed.

6.

Save the configTileDefinitions.xml file.

Replacing a Column in a Compliance Object Table


1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

4.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object> List Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account List
Definitions.
Uncomment the definition for the compliance object and comment out the line for the
property you wish to replace inside the <putlist> tag to add the list entry for the
column to be added, as in the example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />
<!-- <add value="account.item.list.field.assertions" /> -->
</putList>
The above example would add the Account Number field to the table in a new column.

5.

Add a new line for the property you wish to add inside the <putlist> tag, as in the
example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />
<!-- <add value="account.item.list.field.assertions" /> -->
<add value="account.item.list.field.accountnumber" />
</putList>
The above example would add the Account Number field to the table in place of the
Assertions column. The order of the values in the putList statement determines the
order in which the columns are displayed.
Modifying SOX Express Behavior

Additional Modifications 110

6.

Below the list definition for the compliance object type, create a new definition for the
field to be displayed in the new column. It should look like the following:
<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
</definition>
where the value of name matches the new value you added to the putList; the value
for type is always custom.property; the value for bundle is the property bundle
where the custom property is contained; and the value for property is the exact name
of the custom property to be displayed.

7.

Save the configTileDefinitions.xml file.

Modifying the Label of a Compliance Object Table Column


If you have added a column to a compliance object table, and you wish to rename the column,
you can override the displayed text (by default, the property label) by specifying a new label
parameter in the property listing definition.
To change the displayed text in the column heading:
1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

4.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object> List Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account List
Definitions.
Below the listing definition, find the property definition for the column you want to
modify.
For example, a definition might look like this:
<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
</definition>
Note: If you are changing the label of a default property (one originally supplied with
SOX Express), you will have to create a property definition for the default property.

5.

Add the following line to the definition:


<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
<put name=label value=New Column Name/>
</definition>
where New Column Name is the new text to appear as the property name in the
column heading.

6.

Save the configTileDefinitions.xml file.

Modifying SOX Express Behavior

Additional Modifications 111

Hiding a Column in a Compliance Object Table


1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

4.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object> List Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account List
Definitions.
Uncomment the definition for the compliance object and modify the <putlist> tag to
comment out the list entry for the column to be hidden, as in the example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />
<!-- <add value="account.item.list.field.assertions" /> -->
</putList>
The above example would hide the Assertions column from the table.

5.

Save the configTileDefinitions.xml file.

Configuring the Compliance Object Listings


When you click on the Action menu link for a compliance object type, the displayed page
contains an expandable list of the various compliance objects. This table has different columns
that display information about the specific compliance objects.
For example, the Accounts listing displays three columns; Name, Description, and Assertions. It
is possible to modify the account listing table to display additional columns with other property
fields, or change the existing columns to show new information, or to simply remove a column
entirely.
Note: The parameters of the table itself cannot be modified. Therefore, any information you
add must share the same table width as the rest of the table. If you add three columns to the
table, the table will still take up the same horizontal width as the original three columns. This
can lead to awkward screen layout and some unusual table formatting. It is recommended that
you only display the most important information using the table columns.

Adding a Column to a Compliance Object Listing


To add a column to a compliance object listing:
1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

Modifying SOX Express Behavior

Additional Modifications 112

3.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object> Tree Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account Tree
Definitions.
Note: Business Entities, Issues, and Test Results do not use an expandable tree view,
and therefore do not have List Definitions.

4.

Uncomment the definition for the compliance object and modify the <putlist> tag to
add the list entry for the column to be added, as in the example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />
<add value="account.item.list.field.assertions" />
<add value="account.item.list.field.accountnumber" />
</putList>
The above example would add the Account Number field to the table in a new column.
The order of the values in the putList statement determines the order in which the
columns are displayed.

5.

Below the list definition for the compliance object type, create a new definition for the
field to be displayed in the new column. It should look like the following:
<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
</definition>
where the value of name matches the new value you added to the putList; the value
for type is always custom.property; the value for bundle is the property bundle
where the custom property is contained; and the value for property is the exact name
of the custom property to be displayed.

6.

Save the configTileDefinitions.xml file.

Replacing a Column in a Compliance Object Listing


To replace a column in a compliance object listing:
1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

4.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object> Tree Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account Tree
Definitions.
Uncomment the definition for the compliance object and comment out the line for the
property you wish to replace inside the <putlist> tag to add the list entry for the
column to be added, as in the example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />
<!-- <add value="account.item.list.field.assertions" /> -->
</putList>

Modifying SOX Express Behavior

Additional Modifications 113

The above example would add the Account Number field to the table in a new column.
5.

Add a new line for the property you wish to add inside the <putlist> tag, as in the
example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />
<!-- <add value="account.item.list.field.assertions" /> -->
<add value="account.item.list.field.accountnumber" />
</putList>
The above example would add the Account Number field to the table in place of the
Assertions column. The order of the values in the putList statement determines the
order in which the columns are displayed.

6.

Below the list definition for the compliance object type, create a new definition for the
field to be displayed in the new column. It should look like the following:
<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
</definition>
where the value of name matches the new value you added to the putList; the value
for type is always custom.property; the value for bundle is the property bundle
where the custom property is contained; and the value for property is the exact name
of the custom property to be displayed.

7.

Save the configTileDefinitions.xml file.

Modifying the Label of a Compliance Object Listing Column


If you have added a column to a compliance object listing definition, and you wish to rename
the column, you can override the displayed text (by default, the property label) by specifying a
new label parameter in the property listing definition.
To change the displayed text in the column heading:
1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

4.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object> Tree Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account Tree
Definitions.
Below the listing definition, find the property definition for the column you want to
modify.
For example, a definition might look like this:
<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
</definition>

Modifying SOX Express Behavior

Additional Modifications 114

Note: If you are changing the label of a core property, you will have to create a
property definition for the core property.
5.

Add the following line to the definition:


<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
<put name=label value=New Column Name/>
</definition>
where New Column Name is the new text to appear as the property name in the
column heading.

6.

Save the configTileDefinitions.xml file.

Hiding a Column in a Compliance Object Listing


To hide a column in a compliance object listing:
1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

4.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object> Tree Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account Tree
Definitions.
Uncomment the definition for the compliance object and modify the <putlist> tag to
comment out the list entry for the column to be hidden, as in the example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />
<!-- <add value="account.item.list.field.assertions" /> -->
</putList>
The above example would hide the Assertions column from the table.

5.

Save the configTileDefinitions.xml file.

Configuring the User Selector Tool


Configuring the User Segment Size
SOX Express features a new user selector tool that breaks the list of users into 10-user
segments for quickness of browsing. The number of users in each segment is configurable via a
setting in the sosa.properties configuration file.
If you wish to increase the number of names in each segment, do the following:
1.
2.
3.

Open the sosa.properties file in a text editor. The file can be found in the
\bea\weblogic81\config\OpenpagesDomain\applications\sosa\conf directory.
Find the following line:
user.bucket.size=10
Change the value to the number of users desired. In order to have 25 users in each
segment, change the line to the following:
Modifying SOX Express Behavior

Additional Modifications 115

4.

user.bucket.size=25
Save your changes and restart the SOX Express services to view the change.

Specifying a Group for the User Selector


If you want to constrain the list of users that can be chosen as a value for a compliance object
property, you must replace the existing user selector with the original dropdown user selector.
To change the user selector to the original and specify a group for the list:
1.
2.
3.

4.

5.

Open the configTileDefinitions.xml file in a text editor. Make sure you back up the file
before making any changes.
Search for the string select.user.dropdown. An example definition is displayed.
Copy the example and paste it outside of the comment tags. The example looks like the
following:
<definition name="customer.entity.property.ExecutiveOwner">
<put name="bundle.name" value="SOXObjectOwners"/>
<put name="property.name" value="Executive Owner"/>
<put name="display.type" value="select.user.dropdown"/>
<put name="select.user.group" value="SOXUsers"/>
<put name="select.user.group.include.subgroups" value="yes"/>
</definition>
Replace the following strings with your property information:
customer.entity.property.ExecutiveOwner with the property definition name
of the field you are modifying.
SOXObjectOwners with the bundle that contains the custom property
Executive Owner with the label of your custom property.
SOXUsers with the group whose members will be listed in the user selector.
Save your changes when you have finished. You will have to restart the SOX Express
services to see the new behavior.

Configuring the Displayed Fields


Administrators can modify the fields that are displayed in the user selector and user group
selector by updating a definition in the configTileDefinitions.xml configuration file. The two
selectors share the same definition, and cannot be configured individually.
To modify the displayed fields:
1.
2.
3.

Open the configTileDefinitions.xml file in a text editor. Make sure you back up the file
before making any changes.
Search for the string config.user.selector.table.field.list. An example definition is
displayed.
Copy the example and paste it outside of the comment tags. The example looks like the
following:
<definition name="config.user.selector.table.field.list">
<putList name="table.field.list">
<add value="email" />
<add value="firstName" />
<add value="lastName" />
<add value="description" />
</putList>
</definition>

Modifying SOX Express Behavior

Additional Modifications 116

4.

5.

6.

The example contains all of the potential fields that can be displayed in SOX Express.
To hide any of these fields, comment out the appropriate line with the <!-- --> tags.
For example, to hide the e-mail address of users, modify the example as follows:
<definition name="config.user.selector.table.field.list">
<putList name="table.field.list">
<!-- <add value="email" /> -->
<add value="firstName" />
<add value="lastName" />
<add value="description" />
</putList>
</definition>
To re-order the list, re-arrange the listings from top to bottom - each entry corresponds
to a left-right orientation. For example, to display the last name before the first name,
move the lastName line above the firstName line.
Save your changes when you have finished. You will have to restart the SOX Express
services to see the new behavior.

Redirecting the SOX Express Logout Link


By default, clicking the Logout link in the header pane logs the user out and displays the login
page. This destination page can be changed by modifying a property in the aurora.properties
file.
You can find the aurora.properties file in the \<weblogic-installdir>\weblogic81\aurora\conf
directory.
To redirect the logout link:
1.
2.
3.

Open the aurora.properties file in a text editor.


Search for the string logout.link.url.
Enter a fully qualified URL as the value of the logout link.
Example:

4.
5.

logout.link.url=http://www.openpages.com
Save your changes and exit the text editor.
Restart the OpenPages and SOX servers.

Modifying SOX Express Behavior

Additional Modifications 117

Displaying the Sub-Processes Header in the Action Menu


SOX Express displays a list of compliance object types as headings on the Action Menu. In SOX
Express 3.0.4, the sub-process compliance object was added, and the heading included in the
Action Menu.
Since not all organizations use sub-processes in their compliance object hierarchy, we have
included a flag in the sosa.properties file called subprocesses.show.menu.item. By default,
this flag is set to true. If you do not use sub-processes and wish to remove the Sub-Processes
heading from the Action Menu, set this flag to false and restart the SOX Express services.

Resolving Duplicate Names During Copy Operations


There is an optional setting in the sosa.properties configuration file that can control the
behavior of SOX Express when it encounters duplicate compliance object names during a copy
operation. By default, the copy operation will create a new version of the destination object
containing the information of the copied object.
The sosa.properties file contains the setting expose.copy.options, which is set to false by
default. When set to true, additional options are displayed during the copy process which the
user can use to set how duplicate names will be handled for the current copy.

Setting the Default Copy Behavior


In addition, you can set the default copy behavior of SOX Express (whether the Advanced Copy
Options are displayed or not) by modifying the setting copy.options.default in the
sosa.properties file to one of the following values (without the quotation marks): overwrite
(the existing default), copyof, or existing.
You will need to restart the SOX Express services after making either change in order to pick up
the new settings.

Copy Behavior Options


The new options are:

Create a new version of the existing object in the destination directory


A new version of the object in the target directory is created with all of the information
of the copied object. All prior version of the object in the target directory are
maintained. Corresponds to the overwrite value of the copy.options.default setting.

Create new objects whose names are prefixed with Copy Of


When the copy occurs, any objects with the same name as an existing object in the
target location will be renamed to Copy of <objectname>. Corresponds to the
copyof value of the copy.options.default setting.

Do not overwrite existing objects


If a copied object has the same name as an object in the target location, that file will
not be copied. All other objects (without duplicate names) will still be copied to the
target location. Corresponds to the existing value of the copy.options.default setting.
Note: If you choose this option, you should examine the results of copy operations to
determine whether any associations between objects have changed as a result of the
copy. For example, if an associated risk is not copied to the new location because an
existing risk has the same name, the copied parent process of the risk will be
associated with the pre-existing risk in the target location.

Modifying SOX Express Behavior

Additional Modifications 118

Using an SSL Connection


To access SOX Express using an SSL connection, you should use the following URL (assuming
the default settings were kept during the installation):
https://<SOXSERVER>:7010/sox
where <SOXSERVER> is the fully qualified hostname of your server machine.
For example:
https://www.openpages.com:7010/sox
You must have an SSL digital certificate in order to use SSL with SOX Express. Instructions on
configuring an SSL certificate with the BEA WebLogic server can be found at:
http://e-docs.bea.com/wls/docs81/secmanage/ssl.html

Modifying SOX Express Behavior

Using Netegrity SiteMinder 119

Using Netegrity SiteMinder


Overview of SiteMinder Integration
SOX Express integrates with the Netegrity SiteMinder website security application to provide
secure, managable access to your SOX Express application. The following sections detail how to
configure your SOX Express installation to interact with SiteMinder.

Installing and Configuring SiteMinder


Configuring SOX Express for SiteMinder Integration

Installing and Configuring SiteMinder


This document assumes that you have already installed a SiteMinder Policy Server for your
existing web server. You will need to install the following additional SiteMinder components to
integrate with SOX Express:

the SiteMinder Web Agent (for WebLogic)


the SiteMinder Servlet Agent (for WebLogic)

The agents must pass the SOX Express user name in the response header attributes.

Configuring SOX Express for SiteMinder Integration


To configure SOX Express to work with the SiteMinder application:
1.
2.
3.

Edit the aurora.properties file, located in the \<weblogic-installdir>\


weblogic81\aurora\conf directory.
Add the following line:
security.siteminder.enabled=true
Modify the following line:
sox.app.security.auth.siteminder.enabled=false
to

4.

sox.app.security.auth.siteminder.enabled=true
Save the changes to aurora.properties and restart the SOX Express server.
Note: For instructions on restarting SOX Express and OpenPages, see the SOX Express
Installation Manual included with your installation media.

Configuring OpenPages for SiteMinder Integration


To configure OpenPages to work with the SiteMinder application:
1.
2.
3.

Edit the aurora.properties file, located in the \<weblogic-installdir>\


weblogic81\aurora\conf directory.
Add the following line:
security.siteminder.enabled=true
Modify the following line:
op.app.security.auth.siteminder.enabled=false
to

4.

op.app.security.auth.siteminder.enabled=true
Save the changes to aurora.properties and restart the OpenPages server.

Sarbanes-Oxley Express and Netegrity SiteMinder should now be configured correctly.

Modifying SOX Express Behavior

The Notification
Manager

Overview of the Notification Manager


The Notification Manager is an add-on tool for Sarbanes-Oxley Express
(versions 3.0.1 and later) that automatically creates action items and
notification e-mails when the certain criteria are met.
The Notification Manager allows users to define a set of object
properties and values that will trigger the creation of an action item and
the sending of a notification e-mail. The user responsible for the item
will receive the e-mail and see the action item in their Home page,
alerting the user to their necessary tasks.
For example, a notification event can be set to run nightly that will send
a notification e-mail to all users who have Tests that do not have
completed Test Results associated with them.

Why would I use Notifications?


Notifications allow you to alert people that important dates are
approaching, and remind them that they still have outstanding tasks to
perform before the date arrives. Since notification can be tied to the
value of a compliance object property, you can target the reminder to
only those people who meet the criteria for the notification.
For example, you can set up a notification to remind all Control owners
who have controls that have a value of Undetermined for the Control
Evaluation field, and set the notification to start 20 days after the
beginning of the quarter.

About the Notification Manager 121

About the Notification Manager


Exploring the Notification Reports
When the Notification Manager is installed, a new folder in OpenPages is created under the
Publishing/Reporting/SOX directory named Notifications. This folder contains the reports and
report templates required to set up a notification event. The contents of the folder are:

the Test Notifications page (report). This is a prepared report that will send e-mail to
all Test Performers that have Tests that have not been performed and are due within
the next 15 days.
the Undetermined Controls page (report). This is a prepared report that notifies users
who have Controls assigned to them that are marked as Undetermined.
the Test Notification Template. This report template is used when creating your own
reports to notify Test Performers and Reviewers about incomplete Test Results.
the General SOX Notifications Template. This template is used to create your own
notification reports using your own custom trigger conditions. Detailed information
about creating your own notification reports can be found in Using the General SOX
Notifications Template on page 122 of this guide.

This guide will explain how to set up and run notification reports based on the included Test
Notification Template and the General SOX Notifications Template.

Using the Notification Manager


In order to set up and execute a notiification, the following general steps will need to be
performed. Each step will be explained in detail in later sections.

Step One: Preparing Your Data on page 122


Step Two: Creating the Notification on page 123
Step Three: Triggering the Notification on page 129

Once the steps are completed, you will have a notification that can be run manually or
scheduled to be run automatically, depending on your choices.

Requirements for Setting Up a Notification


In order to set up a notification event, you must have the following:

A user account with Publishing access to the OpenPages Server


Administrator access to the OpenPages server machine (for scheduling reports to run
automatically)

Results of Running a Notification Report


When a notification report is run, the following events occur (based on the setting you chose
during the notification creation process):

When the report is run, a milestone is generated with a name based on the report and
the Milestone Suffix parameter.
For each compliance object that generates a notification, an action item is created
under the report milestone. This action item is assigned to the Executive or Primary
Owner of the compliance object.
A notification e-mail is generated for the Executive or Primary Owners detailing the
compliance objects that require attention.

Step One: Preparing Your Data 122

Step One: Preparing Your Data


Overview
The first step in setting up a notification is to make sure that your compliance objects have the
necessary information that will be required by the notification report. If the compliance objects
are not up-to-date, the report will not find the data it needs and will either return a sub-set of
the entire results, or fail to run at all.
For example, when running the Undetermined Controls report, the report checks the Control
Evaluation field for a value of Undetermined. If your controls do not begin with a status of
Undetermined, the report will not be able to differentiate between legacy settings, and
controls that have not been evaluated yet.

Using the Test Notification Template


If you plan to use notifications based on the Test Notification Template, or the provided Test
Notifications report, you will need to make sure that your Tests have the following properties
populated correctly:

Test Reviewer (the person responsible for verifying that the tests are completed)
Test Performer (the person responsible for executing the tests)
Frequency (whether the test is performed Annually, Quarterly, or Monthly)
Relative Due Date (when the test should be completed, measured in days after the
beginning of the Frequency period)

Note: If you are viewing existing Tests that were created before version 3.0.1, the new
properties will not be visible on the Details page of the Test. To display the new properties on
an existing Test, click the Edit button. The new properties will be included on the Edit page.
When you Save your changes, the new properties and values will now be displayed on the
Details page. You will need to enter values for each pre-existing Test in order to use the
Notification Manager.

Using the General SOX Notifications Template


If you are creating notifications based on property values, make sure that the properties you
are checking have valid values.
If you are creating custom properties and plan to run notifications based on those properties,
make sure that you update all of the necessary compliance objects with the new custom
property field(s).
Note: The General SOX Notifications template cannot compare date fields using the greater
than/less than/equal/not equal operators.

Step Two: Creating the Notification 123

Step Two: Creating the Notification


Overview
SOX Express comes with two templates for creating notification reports - Test Notifications and
General SOX Notifications.
Reports created with the Test Notification template are targeted at Tests and are used to notify
Test Performers and Reviewers that incomplete Tests exist. It also contains special logic to deal
with setting relative due dates and gathering information from both Tests and Test Results.
The General SOX Notifications template allows users to set up to three properties and property
values to evaluate. You can only evaluate properties for a single compliance object type.
The following sections explain the various settings available to each type of notification report.

Creating a Test Notification


To create a new Test Notification:
1.
2.
3.

Log in to OpenPages as a user with Publishing privileges. The Home page is displayed.
Click the Browse Channels link on the Action menu. A list of channels is displayed.
Navigate to the Reporting/SOX/Notifications folder. The contents of the folder are
displayed.
4. Click the Add Page... button at the top of the folder list. The Describe Page screen is
displayed.
5. Enter a name and description for the notification report and choose the Test Notification
Template as the page template. Click Next to continue.
6. Enter the information for your notification. When you are finished, click Apply to save
your changes.
Note: Detailed information about the various fields can be found following this
procedure.
7.

Click Finish to save the new report.

Understanding the Test Notification Fields


The following table contains an explanation of the various fields available to notification reports
based on the Test Notification Template:

Parameter
Milestone Suffix

Explanation
String appended to the milestone created as a result of
running the report. When the report is run, a milestone is
created to hold the action items that will be created as a
result of the notification process. By default, the milestone is
named for the content type that the report targets (in this
case - Tests). The milestone suffix is added to the end of the
milestone name to create a unique name for holding the
results of the notification report.
The name is appended with a dash, so a Milestone Suffix of
Weekly Reminder will result in a milestone named Tests Weekly Reminder.

Sender Name

This is the name that will appear as the sender of the


notification e-mail.

Sender Address

The e-mail address that appears as the sender e-mail


address on the notification e-mail.

Step Two: Creating the Notification 124

Parameter

Explanation

Subject

The subject of the notification e-mail.

Select a Test Frequency

(Annually, Quarterly, Monthly)


Selecting a Test Frequency limits the notification report to
only send out notifications for incomplete Tests that match
the chosen frequency.

Notify Test Reviewer ___


days before due date

The number of days before the test due date that the
notification e-mail will be sent to the user listed as the Test
Reviewer.
The Due Date for a Test is set in the Relative Due Date field
on the Test compliance object. The Relative Due Date is the
number of days after the beginning of the test period (as set
in Frequency - Annually, Quarterly, Monthly).
For example, a Relative Due Date of 60 and a Frequency of
Quarterly means that the Test must be completed 60 days
after the beginning of the most recent quarter. If you set
this field (Notify Test Reviewer...) to 14, then 14 days before
the Relative Due Date the notification will alert the Test
Reviewer.
Note: SOX Express considers financial quarters to begin on
January 1st, April 1st, July 1st, and October 1st. If your
financial quarter begins on a different date, you may want to
adjust the Relative Due Date.

Notify Test Performer ___


days before due date

The number of days before the test due date that the
notification e-mail will be sent to the user listed as the Test
Performer.
The Due Date for a Test is set in the Relative Due Date field
on the Test compliance object. The Relative Due Date is the
number of days after the beginning of the test period (as set
in Frequency - Annually, Quarterly, Monthly).
For example, a Relative Due Date of 60 and a Frequency of
Quarterly means that the Test must be completed 60 days
after the beginning of the most recent quarter. If you set
this field (Notify Test Peformer...) to 21, then 21 days before
the Relative Due Date the notification will alert the Test
Performer.
Note: SOX Express considers financial quarters to begin on
January 1st, April 1st, July 1st, and October 1st. If your
financial quarter begins on a different date, you may want to
adjust the Relative Due Date to take this into account.

Also examine past ___ days


when evaluating
completeness

The number of previous days to check when looking for


incomplete Tests.
By default, the notification report only checks for the exact
value of the Notify Test Reviewer/Performer X days before
due date fields, so if the report is not run for a few days,
some incomplete Tests with due dates that do not exactly
match the values may not create notifications.
This setting provides some overlap in case the report is not
run every day. If an Action Item already exists for the Test,
a new one will not be created.

Send repeat notifications

If this field is set to true, an e-mail will be sent to the Test


Reviewer/Performer every time the notification report is run
and the Test continues to be incomplete. If set to false,
the Performer/Reviewer will receive a single e-mail the first
time the incomplete Test is included in the report results.

Step Two: Creating the Notification 125

Parameter

Explanation

General Message

This text will appear as the introductory text in the body of


the e-mail for both Test Perfomers and Test Reviewers.

Send mail to Test Reviewers

If set to true, an e-mail message will be generated that


contains the incomplete tests belonging to the Test
Reviewer.

Message to Test Reviewers

This text will appear underneath the General Message on emails to Test Reviewers.

Send mail to Test Performers

If set to true, an e-mail message will be generated that


contains the incomplete tests belonging to the Test
Performer.

Message to Test Performers

This text will appear underneath the General Message on emails to Test Performers.

Group notifications by

This setting is used to group the tests that meet the criteria
for notification within the notification e-mail.

Test Reviewer property

Defines the property that contains the Test Reviewer user.


Should only be modified if you are using a custom property.

Test Performer property

Defines the property that contains the Test Performer user.


Should only be modified if you are using a custom property.

Test Due Date property

Defines the property that contains the Test Due Date.


Should only be modified if you are using a custom property.

Test Frequency property

Defines the property that contains the Test frequency.


Should only be modified if you are using a custom property.

Test Result Date Performed


property

Defines the property that contains the date the Test Results
were performed. Should only be modified if you are using a
custom property.

Mail Server

The machine address that contains the mail server. If the


server machine contains a mail server, the setting should be
localhost.

SOX Server

The full URL of the SOX Express server machine. This


address is used to create the links contained in the
notification e-mail, and should NOT be set to localhost.

Report Title

The text displayed as the title of the notification report.

Scope

The scope parameter is used to limit the range of the


notification report. If you do not want to limit the scope of
the notification report, leave it set to _op_sox/Project/
Default.
If you wish to change the scope, click the Browse button
and select the business entity hierarchy you want to include
in the notification report. Only the compliance objects under
that business entity will be evaluated when the report is run.

Library Filter

When you are running a notification report, you do not


usually want to include the Master Library in the report
results, since they are not considered active.
If the path contains the value of the Library Filter
parameter, it will not be included in the report results.

Project

Internal parameter. Do not modify.

Reporting Period

Internal parameter. Do not modify.

Step Two: Creating the Notification 126

Creating a General Notification


The following table contains an explanation of the various fields available to reports based on
the General SOX Notifications Template:

Parameter
Milestone Suffix

Explanation
String appended to the milestone created as a result of
running the report. When the report is run, a milestone is
created to hold the action items that will be created as a
result of the notification process. By default, the milestone is
named for the content type that the report targets (in this
case - Tests). The milestone suffix is added to the end of the
milestone name to create a unique name for holding the
results of the notification report.
The name is appended with a dash, so a Milestone Suffix of
Weekly Reminder will result in a milestone named Tests Weekly Reminder.

Sender Name

This is the name that will appear as the sender of the


notification e-mail.

Sender Email

The e-mail address that appears as the sender e-mail


address on the notification e-mail.

Email Subject

The subject of the notification e-mail.

General Message

This text will appear as the introductory text in the body of


the e-mail for both Executive Owners and Primary Owners.
Note: If you are entering a plain-text message, any escaped
characters (such as newlines, etc.) must be preceded with
two backslashes instead of one (e.g. \\n). If you are using
HTML for your e-mail message, this is not necessary.

Send mail to Executive


Owners

If set to true, an e-mail message will be generated and


sent to the Executive Owner of the compliance object that
generated the notification.
If no Executive Owner is set on the compliance object, the
Notification Manager will look up the hierarchy until a valid
Executive Owner is found.
If no Executive Owner is found, no notification will be
generated.

Message to Executive
Owners

This text will appear underneath the General Message on emails to Executive Owners.
Note: If you are entering a plain-text message, any escaped
characters (such as newlines, etc.) must be preceded with
two backslashes instead of one (e.g. \\n). If you are using
HTML for your e-mail message, this is not necessary.

Send mail to Primary Owners

If set to true, an e-mail message will be generated and


sent to the Primary Owner of the compliance object that
generated the notification.
If no Primary Owner is set on the compliance object, the
Notification Manager will look up the hierarchy until a valid
Primary Owner is found.
If no Primary Owner is found, no notification will be
generated.

Step Two: Creating the Notification 127

Parameter
Message to Primary Owners

Explanation
This text will appear underneath the General Message on emails to Primary Owners.
Note: If you are entering a plain-text message, any escaped
characters (such as newlines, etc.) must be preceded with
two backslashes instead of one (e.g. \\n). If you are using
HTML for your e-mail message, this is not necessary.

Send repeat notifications:

If this field is set to true, an e-mail will be sent to the


Executive and/or Primary owners every time the report is
run and the compliance object continues to meet the
notification criteria. If set to false, the Executive and/or
Primary owners will receive a single e-mail the first time the
compliance object is included in the report results.
Note: If Create Action Items is set to false, then
notification e-mails will be sent each time the report is run,
regardless of the value of Send repeat notifications.

Content type to send


notifications for

Determines which compliance objects will be evaluated


when the report is run.
Notification reports can only be run against a single
compliance object type. If you want to run the same report
against multiple compliance object types, you will have to
create multiple reports, or provide different parameter
values in the command line.

[Filter Property 1
Filter Evaluation 1
Filter Value 1]

The report template contains three sets of Property/Value


evaluations that can be performed when determining which
compliance objects will generate a notification.
For example, if the three parameters have the following
values:
Filter Property 1: SOXControl.Control Evaluation
Filter Evaluation 1: =
Filter Value 1: Undetermined
then a notification would be generated if any Control had a
value of Undetermined for the Control Evaluation property.

Filter Property X

Contains the property to be considered when evaluating


whether a notification should be generated.

Filter Evaluation X

The evaluation method to be used when comparing the


compliance object property value with the Filter Value
Note: The possible operators are =,<> (not equals), <, >,
<=, and >=. Only the = operator can be used with strings.
All other operators only work with integers.

Filter Value X

Contains the value of the property to be considered when


generating notifications.

Create notification if

Determines whether all property/value evaluations need to


be true in order to create a notification, or if only one of
them needs to be true.

Group Notifications by

This setting is used to group the compliance objects that


meet the criteria for notification within the notification email.

Step Two: Creating the Notification 128

Parameter
Create Action Items

Explanation
Determines whether an action item will be created for each
notification e-mail sent to an Executive or Primary Owner.
If an Action Item has already been created for the
compliance object, no new action item will be generated
Note: If this option is set to false, then notifications will
always be sent when the notification report is run,
regardless of the Send repeat notifications setting.

Action Item Description

An optional description for the created Action Items.

Action Item should be


completed in

If set, the Action Items Due Date will be set to the number
of days after the creation of the action item.
For example, a value of 14 would give the created Action
Item a due date two weeks after the creation of the Action
Item.

Mail Server

The machine address that contains the mail server. If the


server machine contains a mail server, the setting should be
localhost.

SOX Server

The full URL of the SOX Express server machine. This


address is used to create the links contained in the
notification e-mail, and should NOT be set to localhost.

Report Title

The text displayed as the title of the notification report.

Executive Owner Property

The property containing the Executive Owner value. Should


not be changed unless you are using a custom Owner field.

Primary Owner Property

The property containing the Primary Owner value. Should


not be changed unless you are using a custom Owner field.

Library Filter

When you are running a notification report, you do not


usually want to include the Master Library in the report
results, since they are not considered active.
If the path contains the value of the Library Filter
parameter, it will not be included in the report results.

Scope

The scope parameter is used to limit the range of the


notification report. If you do not want to limit the scope of
the notification report, leave it set to _op_sox/Project/
Default.
If you wish to change the scope, click the Browse button
and select the business entity hierarchy you want to include
in the notification report. Only the compliance objects under
that business entity will be evaluated when the report is run.

Project

Internal parameter. Do not modify.

Reporting Period

Internal parameter. Do not modify.

Step Three: Triggering the Notification 129

Step Three: Triggering the Notification


Overview
There are two ways to run the notification reports - manually and automatically. You can run
notification reports from the Reporting interface like any other report, or use the provided
command line interface to run the notification reports from outside Sarbanes-Oxley Express.
You can also schedule the notification reports to execute automatically by using the Windows
Scheduler tools to initiate the command line at a specific time.
The following sections will explain how to run your notification reports both manually and
automatically.

Running Notification Reports Manually


Running a notification report by hand works the same as running any other report through the
SOX user interface.
You can also run reports manually by entering a valid command line at a command prompt, as
detailed in the Running Notification Reports Automatically section.
Note: You cannot use the Preview functionality in the OpenPages user interface with
Notification reports.
To run a notification report:
1.
2.
3.
4.

Log in to SOX Express and click the Reports link on the Action menu.
Click on the Notificiations link to display the notification reports.
Choose the notification report you wish to run and click the name of the report.
A new window opens, and the results of the report are displayed.
Note: The report may take a short while to display - this is normal.

Running Notification Reports Automatically


Notification reports can be run automatically by scheduling the NotificationManager command
file to be executed at a certain time using the Windows Scheduler tool. You can run a single
report, an entire folder of reports, and run a single report against multiple datasets by
providing parameters to the report directly through the command line.

The Notification Manager Command Line Interface


The NotificationManager.cmd program can be found in the <WL_HOME>\aurora\util
\NotificationManager directory.
The following section details the allowable parameters that can be used with the
NotificationManager command.

Syntax
NotificationManager -Username=<username> -Password=<password>
-NotificationProgram=<full-path-to-notification-report>|-ProgramFolder=<path-to-foldercontaining-notification-reports> [-SaveOutput=<true|false>] [-LogSession=<true|false>]
-[{parameterName=parameterValue}] [-ParameterFile=<full-path-to-file>]

Step Three: Triggering the Notification 130

Parameters
All parameters are in the syntax -parameter=value. If the value of any parameter contains
spaces, that value must be contained within quotation marks.

Parameter Name

Explanation

-Username

The name of a valid SOX Express user with permission to


run the notification reports.

-Password

The password for the user name set in -Username.

-NotificationProgram

(Required unless -ProgramFolder is specified) The full path


to the notification report the command will run, starting
with the Reporting channel. Should not begin with a leading
slash.
Example: -NotificationProgram=Reporting\SOX\
Notifications\Test Notifications Report

-ProgramFolder

(Required unless -NotificationProgram is specified)


Specifies a folder containing notification reports. All reports
in that folder will be executed when the command is run.
Example: -ProgramFolder=Reporting\SOX\Notifications

-SaveOutput

(Optional) Can be true or false. If set to true, the output


of the report will be saved to an output file in the /
output_files directory under the
aurora\utils\NotificationManager directory. If the
parameter is not present, no output file will be created.
The file name is the name of the notification report (or
folder) with an html extension. If an output file with that
name already exists, a timestamp extension will be added
to the end of the existing files name and the older file will
be moved to the output_files\archive folder.
Example: Undetermined Controls.html.200406060103

-LogSession

(Optional) Can be set to true. If set, the activities of the


NotificationManager will be written to a log file. The log file
will be located in the logs directory under the
\aurora\util\NotificationManager directory.
The name of the log file is NotificationManager.log. The
file has a maximum size of 1MB, and will be rotated into
the \logs\archives directory when the limit is exceeded.

-parameter=value

If you wish to pass a value for a notification report


parameter, you may include the parameter and value
directly in the command line. The parameter name must
match the report parameter name exactly.
The parameter names can be viewed by logging into
OpenPages and navigating to the channel folder containing
the report page. The parameter names are shown in the
Details page for the report, which can be viewed by clicking
on the name of the report in the channel folder view.
Examples: -mailServer=mail.openpages.com
-generalMessage=Please do not ignore this e-mail.

Step Three: Triggering the Notification 131

Parameter Name
-ParameterFile

Explanation
Specifies a text file containing a list of parameter=value
pairs (equivalent to entering individual -parameter=value
entries into the command line directly). Each
parameter=value pair should be on a single line.
Value is the full path to the file, including the file name.
Example: ParameterFile=c:\bea\weblogic81\aurora\util\Notification
Manager\notification_parameters.txt

Scheduling Your Automatic Notification


Because the Notification Manager can be run from a simple command prompt, you can easily
schedule the Notification Manager to be executed at any time with the standard Windows
Scheduler.
To set up a scheduled event for the Notification Manager:
1.
2.
3.
4.

From the Windows menu on the application server machine, select Settings | Control
Panel.
Open the Scheduled Tasks item in the Control Panel.
Double-click the Add Scheduled Task item.
On the Task tab, fill in the Run field with the path to the NotificationManager program
and any parameters you require to run the report.
Example: To run a single report, the contents of the Run field might look like the
following:
c:\bea\weblogic81\aurora\util\NotificationManager
NotificationManager.cmd -Username=SOXAdministrator
-Password=SOXAdministrator -NotificationProgram=Reporting/SOX/
Notifications/Test Notifications

5.
6.
7.
8.
9.
10.
11.

Edit the Start in field to be the path to the NotificationManager program, i.e.
c:\bea\weblogic81\aurora\util\NotificationManager.
Make sure the Run as: is set to the current Windows user.
Check the checkbox next to Enabled to set a time for the command to be executed.
Click the Schedule tab to display the Schedule settings.
Set the days and time you want the notification report(s) to run.
Click Apply and then Ok to save your changes and exit the scheduler.
Repeat these steps for each report you wish to run. Remember that you can use the
-ProgramFolder parameter to run all the reports in a specified folder at the same time.

The SOX Express


Reporting Schema
Overview
The following appendix describes the tables that are part of the SOX
Express reporting schema. The reporting schema is used to make SOX
Express data available to optional or third-party reporting tools.
Note: The table structures documented here correspond to the default
Standard SOX Schema supplied with SOX Express. For customized
schema, the table structures would be different.

133

Compliance Object Tables


Business Entity
Physical Name: SX_ENTITY
Description: This table contains the information relating to the Business Entity compliance
object.
Primary Key: ENTITY_ID
Indices: 11

Column Name

Description

Native Type

ENTITY_ID

The unique ID of the Business


Entity

NUMBER(38,0)

EN_CREATIONDATE

Date the entity was created

DATE

EN_CREATOR

The resource ID of the user who


created the Business Entity

NUMBER(38,0)

EN_DESCRIPTION

The user-created description of the


compliance object

VARCHAR2(2048)

EN_ENTITY_IN_SCOPE

May be used to include or exclude


the business entity from
downstream compliance-related
activities such as testing,
attestation, and reporting.

VARCHAR2(256)

EN_ENTITY_TYPE

May be used to categorize the


entitys level in the organization
(sales office, regional
headquarters, etc.)

VARCHAR2(256)

EN_ERP_COMPANY_CODE

May be used to identify the


business entity using the code used
in an ERP system.

VARCHAR2(256)

EN_EXECUTIVE_DELEGATE

May be used to assign the secondhighest level of responsibility for


the business entity

VARCHAR2(4000)

EN_EXECUTIVE_OWNER

May be used to assign the highest


level of responsibility for the
business entity

VARCHAR2(4000)

EN_EXPORTLABEL

Label assigned to the level of the


entity hierarchy

VARCHAR2(4000)

EN_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

EN_LOCKSTATUS

Denotes whether the object can be


modified

VARCHAR2(256)

EN_MODIFIEDDATE

The last date the object was


modified

DATE

EN_NAME

The user-defined name of the


object.

VARCHAR2(4000)

EN_NESTINGLEVEL

Level of the business entity within


the business entity hierarchy.

NUMBER

EN_NESTINGPATH

Concatenated list of the ancestor


business entities, if any.

VARCHAR2(4000)

The SOX Express Reporting Schema

134

Column Name

Description

Native Type

EN_PARENTFOLDERID

The unique identifier of the parent


folder of the business entity.

NUMBER(38,0)

EN_SOXURL

The constructed URL of the


business entitys details page.

VARCHAR2(4000)

EN_VERSIONID

The number of the current version


of the business entity.

NUMBER(38,0)

CORPORATE

Name of the top level business


entity, if any.

VARCHAR2(256)

DEPARTMENT

Name of the second level business


entity, if any.

VARCHAR2(256)

DIVISION

Name of the third level business


entity, if any.

VARCHAR2(256)

WORKGROUP

Name of the fourth level business


entity, if any.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_ENTITY (I1)

EN_CREATOR

IX2_SX_ENTITY (I2)

EN_ENTITY_IN_SCOPE

IX3_SX_ENTITY (I3)

EN_ENTITY_TYPE

IX4_SX_ENTITY (I4)

EN_ERP_COMPANY_CODE

IX5_SX_ENTITY (I5)

EN_EXPORTLABEL

IX6_SX_ENTITY (I6)

EN_FULLPATH

IX7_SX_ENTITY (I7)

EN_LOCKSTATUS

IX8_SX_ENTITY (I8)

EN_NAME

IX9_SX_ENTITY (I9)

EN_NESTINGLEVEL

IX10_SX_ENTITY (I10)

EN_NESTINGPATH

IX11_SX_ENTITY (I11)

EN_PARENTFOLDERID

The SOX Express Reporting Schema

135

Accounts
Physical Name: SX_ACCOUNT
Description: This table contains the information relating to Account compliance objects.
Primary Key: ACCOUNT_ID
Indices: 7

Column Name

Description

Native Type

ACCOUNT_ID

The unique ID of the compliance


object.

NUMBER(38,0)

AC_ACCOUNT_TYPE

May be used to categorize the


account, at the highest level, into
various financial statements.

VARCHAR2(256)

AC_ANNUALIZED_VALUE

May be used to capture the account


balance from operational systems.

NUMBER(38,0)

AC_ASSERTIONS

May be used to indicate the


financial statement assertions that
must be made on the account.

VARCHAR2(256)

AC_CLASSIFICATION

May be used to sub-categorize the


account into various financial
statement account categories.

VARCHAR2(256)

AC_CREATIONDATE

Date the account was created

DATE

AC_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

AC_DESCRIPTION

The user-created description of the


compliance object

VARCHAR2(2048)

AC_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

AC_LOCKSTATUS

Denotes whether the object can be


modified

VARCHAR2(256)

AC_MODIFIEDDATE

The last date the object was


modified

DATE

AC_NAME

The user-defined name of the


object.

VARCHAR2(4000)

AC_PARENTFOLDERID

The unique identifier of the parent


folder of the business entity.

NUMBER(38,0)

AC_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

AC_VALUE_AS_OF_DATE

May be used to capture the date on


which the Annualized Value data
was set or recorded.

DATE

AC_VERSIONID

The number of the current version


of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

136

Table of Indices

Index Name

Table Column

IX1_SX_ACCOUNT (I1)

AC_ACCOUNT_TYPE

IX2_SX_ACCOUNT (I2)

AC_CLASSIFICATION

IX3_SX_ACCOUNT (I3)

AC_CREATOR

IX4_SX_ACCOUNT (I4)

AC_FULLPATH

IX5_SX_ACCOUNT (I5)

AC_LOCKSTATUS

IX6_SX_ACCOUNT (I6)

AC_NAME

IX7_SX_ACCOUNT (I7)

AC_PARENTFOLDERID

Account Assertions
Physical Name: SX_ACCOUNT_ASSERTIONS
Foreign Key: ACCOUNT_ID
Foreign Key Reference: SX_ACCOUNT.ACCOUNT_ID
Indices: 2

Column Name

Description

Native Type

ACCOUNT_ID

The unique ID of the object.

NUMBER(38,0)

AC_ASSERTIONS

May be used to indicate the


financial statement assertions
that must be made on the
account.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_ACCOUNT_ASSERTIONS
(I1)

ACCOUNT_ID

IX2_SX_ACCOUNT_ASSERTIONS
(I2)

AC_ASSERTIONS

The SOX Express Reporting Schema

137

Sub-Accounts
Physical Name: SX_SUBACCOUNT
Description: This table contains the information relating to sub-account compliance objects.
Primary Key: SUBACCOUNT_ID
Indices: 10

Column Name

Description

Native Type

SUBACCOUNT_ID

The unique ID of the compliance


object.

NUMBER(38,0)

AC_ACCOUNT_TYPE

May be used to categorize the


account, at the highest level, into
various financial statements.

VARCHAR2(256)

AC_ANNUALIZED_VALUE

May be used to capture the account


balance from operational systems.

NUMBER(38,0)

AC_ASSERTIONS

May be used to indicate the


financial statement assertions that
must be made on the account.

VARCHAR2(256)

AC_CLASSIFICATION

May be used to sub-categorize the


account into various financial
statement account categories.

VARCHAR2(256)

AC_CREATIONDATE

Date the account was created

DATE

AC_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

AC_DESCRIPTION

The user-created description of the


compliance object

VARCHAR2(2048)

AC_EXPORTLABEL

Descriptive label assigned to the


level of the account hierarchy

VARCHAR2(256)

AC_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

AC_LOCKSTATUS

Denotes whether the object can be


modified

VARCHAR2(256)

AC_MODIFIEDDATE

The last date the object was


modified

DATE

AC_NAME

The user-defined name of the


object.

VARCHAR2(4000)

AC_NESTINGLEVEL

Level of the sub-account in the


account hierarchy.

NUMBER

AC_NESTINGPATH

Concatenated list of the ancestor


accounts, if any.

VARCHAR2(4000)

AC_PARENTFOLDERID

The unique identifier of the parent


folder of the business entity.

NUMBER(38,0)

AC_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

AC_VALUE_AS_OF_DATE

May be used to capture the date on


which the Annualized Value data
was set or recorded.

DATE

The SOX Express Reporting Schema

138

Column Name

Description

Native Type

AC_VERSIONID

The number of the current version


of the compliance object.

NUMBER(38,0)

GL_ACCOUNT

The top-level parent sub-account.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_ACCOUNT (I1)

AC_ACCOUNT_TYPE

IX2_SX_ACCOUNT (I2)

AC_CLASSIFICATION

IX3_SX_ACCOUNT (I3)

AC_CREATOR

IX4_SX_ACCOUNT (I4)

AC_EXPORTLABEL

IX5_SX_ACCOUNT (I5)

AC_FULLPATH

IX6_SX_ACCOUNT (I6)

AC_LOCKSTATUS

IX7_SX_ACCOUNT (I7)

AC_NAME

IX8_SX_ACCOUNT (I8)

AC_NESTINGLEVEL

IX9_SX_ACCOUNT (I9)

AC_NESTINGPATH

IX10_SX_ACCOUNT (I10)

AC_PARENTFOLDERID

Sub-account Assertions
Physical Name: SX_SUBACCOUNT_ASSERTIONS
Foreign Key: SUBACCOUNT_ID
Foreign Key Reference: SX_SUBACCOUNT.SUBACCOUNT_ID
Indices: 2

Column Name

Description

Native Type

SUBACCOUNT_ID

The unique ID of the object.

NUMBER(38,0)

AC_ASSERTIONS

May be used to indicate the


financial statement assertions
that must be made on the subaccount.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

139

Table of Indices

Index Name

Table Column

IX1_SX_SUBACCOUNT_
ASSERTIONS (I1)

SUBACCOUNT_ID

IX2_SX_SUBACCOUNT_
ASSERTIONS (I2)

AC_ASSERTIONS

Processes
Physical Name: SX_PROCESS
Description: This table contains the information relating to the Process compliance object.
Primary Key: PROCESS_ID
Indices: 5

Column Name

Description

Native Type

PROCESS_ID

The unique ID of the compliance


object.

NUMBER(38,0)

PR_ADDITIONAL_DESCRIPTION

May be used to provide HTMLformatted information about the


compliance object.

VARCHAR2(4000)

PR_CREATIONDATE

Date the account was created

DATE

PR_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

PR_CYCLE_OWNER

May be used to assign the highestlevel of responsibility for the


process cycle

VARCHAR2(4000)

PR_DESCRIPTION

The user-created description of the


compliance object

VARCHAR2(2048)

PR_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

PR_LOCKSTATUS

Denotes whether the object can be


modified

VARCHAR2(256)

PR_MODIFIEDDATE

The last date the object was


modified

DATE

PR_NAME

The user-defined name of the


object.

VARCHAR2(4000)

PR_PARENTFOLDERID

The unique identifier of the parent


folder of the compliance object.

NUMBER(38,0)

PR_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

PR_VERSIONID

The number of the current version


of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

140

Table of Indices

Index Name

Table Column

IX1_SX_PROCESS (I1)

PR_CREATOR

IX2_SX_PROCESS (I2)

PR_FULLPATH

IX3_SX_PROCESS (I3)

PR_LOCKSTATUS

IX4_SX_PROCESS (I4)

PR_NAME

IX5_SX_PROCESS (I5)

PR_PARENTFOLDERID

Sub-Processes
Physical Name: SX_SUBPROCESS
Description: This table contains the information relating to sub-process compliance objects.
Primary Key: SUBPROCESS_ID
Indices: 11

Column Name

Description

Native Type

PROCESS_ID

The unique ID of the compliance


object.

NUMBER(38,0)

PR_ADDITIONAL_DESCRIPTION

May be used to enter XHTMLformatted information about the


process.

VARCHAR2(256)

PR_CREATIONDATE

Date the compliance object was


created

DATE

PR_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

PR_DESCRIPTION

The user-created description of the


compliance object

VARCHAR2(2048)

PR_EXPORTLABEL

Descriptive label assigned to the


level of the process hierarchy

VARCHAR2(256)

PR_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

PR_LOCKSTATUS

Denotes whether the object can be


modified

VARCHAR2(256)

PR_MANAGEMENT_PRIORITY

May be used to assign the level of


importance accorded by
Management. The potential values
are High, Medium, Low, or Not
Determined (default).

VARCHAR2(256)

PR_MODIFIEDDATE

The last date the object was


modified

DATE

PR_NAME

The user-defined name of the


object.

VARCHAR2(4000)

PR_NESTINGLEVEL

Level of the sub-account in the


process hierarchy.

NUMBER

The SOX Express Reporting Schema

141

Column Name

Description

Native Type

PR_NESTINGPATH

Concatenated list of the ancestor


processes, if any.

VARCHAR2(4000)

PR_PARENTFOLDERID

The unique identifier of the parent


folder of the compliance object.

NUMBER(38,0)

PR_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

PR_SUBPROCESS_OWNER

May be used to assign the highestlevel of responsibility for the subprocess transaction.

VARCHAR2(256)

PR_TARGET_DESIGN_RATING

May be used to set a goal for the


design of the process. Possible
values are Unreliable, Informal,
Standardized, Monitored,
Optimized, or Not Determined
(default).

VARCHAR2(256)

PR_VERSIONID

The number of the current version


of the compliance object.

NUMBER(38,0)

TRANSACTION

Name of the top level process, if


any.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_SUBPROCESS (I1)

PR_CREATOR

IX2_SX_SUBPROCESS (I2)

PR_EXPORTLABEL

IX3_SX_SUBPROCESS (I3)

PR_FULLPATH

IX4_SX_SUBPROCESS (I4)

PR_LOCKSTATUS

IX5_SX_SUBPROCESS (I5)

PR_MANAGEMENT_PRIORITY

IX6_SX_SUBPROCESS (I6)

PR_NAME

IX7_SX_SUBPROCESS (I7)

PR_NESTINGLEVEL

IX8_SX_SUBPROCESS (I8)

PR_NESTINGPATH

IX9_SX_SUBPROCESS (I9)

PR_PARENTFOLDERID

IX10_SX_SUBPROCESS (I10)

PR_TARGET_DESIGN_RATING

The SOX Express Reporting Schema

142

Control Objectives
Physical Name: SX_CONTROLOBJECTIVE
Description: This table contains the information relating to the Control Objective compliance
object.
Primary Key: CONTROLOBJECTIVE_ID
Indices: 5

Column Name

Description

Native Type

CONTROLOBJECTIVE_ID

The unique ID of the compliance


object.

NUMBER(38,0)

CO_ADDITIONAL_DESCRIPTION

May be used to provide HTMLformatted information about the


compliance object.

VARCHAR2(4000)

CO_CATEGORY

Obsolete field.

VARCHAR2(4000)

CO_COSO_OBJECTIVE_CATEGORY

May be used to identify one or


more of the COSO objective
categories that apply to this
control objective.

VARCHAR2(256)

CO_CREATIONDATE

Date the compliance object was


created

DATE

CO_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

CO_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

CO_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

CO_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

CO_MODIFIEDDATE

The last date the object was


modified

DATE

CO_NAME

The user-defined name of the


object.

VARCHAR2(4000)

CO_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

CO_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

CO_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

143

Table of Indices

Index Name

Table Column

IX1_SX_CONTROLOBJECTIVE (I1)

CO_CREATOR

IX2_SX_CONTROLOBJECTIVE (I2)

CO_FULLPATH

IX3_SX_CONTROLOBJECTIVE (I3)

CO_LOCKSTATUS

IX4_SX_CONTROLOBJECTIVE (I4)

CO_NAME

IX5_SX_CONTROLOBJECTIVE (I5)

CO_PARENTFOLDERID

Control Objective COSO Objective Category


Physical Name: SX_CONTROLOBJECTIVE_COSO_OBJEC
Foreign Key: CONTROLOBJECTIVE_ID
Foreign Key Reference: SX_CONTROLOBJECTIVE.CONTROLOBJECTIVE_ID
Indices: 2

Column Name

Description

Native Type

CONTROLOBJECTIVE_ID

The unique ID of the object.

NUMBER(38,0)

CO_COSO_OBJECTIVE_CATEGORY

May be used to identify one or


more of the COSO objective
categories that apply to this
control objective.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_CONTROLOBJECTIVE_
COSO_O (I1)

CONTROLOBJECTIVE_ID

IX1_SX_CONTROLOBJECTIVE_
COSO_O (I2)

CO_COSO_OBJECTIVE_CATEGORY

The SOX Express Reporting Schema

144

Risk
Physical Name: SX_RISK
Description: This table contains the information relating to the Risk compliance object.
Primary Key: RISK_ID
Indices: 12

Column Name

Description

Native Type

RISK_ID

The unique ID of the compliance


object.

NUMBER(38,0)

RI_ADDITIONAL_DESCRIPTION

May be used to provide HTMLformatted information about the


compliance object.

VARCHAR2(4000)

RI_ASSERTIONS

Obsolete field.

VARCHAR2(4000)

RI_COSO_OBJECTIVE_CATEGORY

May be used to identify one or


more of the COSO objective
categories that apply to this
control objective.

VARCHAR2(256)

RI_CREATIONDATE

Date the compliance object was


created

DATE

RI_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

RI_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

RI_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

RI_GENERAL_GUIDANCE

May be used to provide


information to control designers
about how this risk may best be
moderated.

VARCHAR2(4000)

RI_IMPACT

May be used to measure the


importance of the particular risk.
Values are High, Medium, Low,
and Unknown.

VARCHAR2(256)

RI_LIKELYHOOD

How often the risk is likely to


occur within a financial reporting
period. Values can be High,
Medium, Low, and Unknown.

VARCHAR2(256)

RI_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

RI_MODIFIEDDATE

The last date the object was


modified

DATE

RI_NAME

The user-defined name of the


object.

VARCHAR2(4000)

RI_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

The SOX Express Reporting Schema

145

Column Name

Description

Native Type

RI_RISK_IN_SCOPE

May be used to determine


whether the risk is significant
from a Sarbanes-Oxley Act
perspective. Possible values are
Yes, No, or Not Determined
(default).

VARCHAR2(256)

RI_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

RI_TARGET_DESIGN_RATING

May be used to set a goal for the


design of the process. Possible
values are Unreliable, Informal,
Standardized, Monitored,
Optimized, or Not Determined
(default).

VARCHAR2(256)

RI_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_RISK (I1)

RI_CREATOR

IX2_SX_RISK (I2)

RI_FULLPATH

IX3_SX_RISK (I3)

RI_IMPACT

IX4_SX_RISK (I4)

RI_LIKELYHOOD

IX5_SX_RISK (I5)

RI_LOCKSTATUS

IX6_SX_RISK (I6)

RI_NAME

IX7_SX_RISK (I7)

RI_PARENTFOLDERID

IX8_SX_RISK (I8)

RI_RISK_IN_SCOPE

IX9_SX_RISK (I9)

RI_TARGET_DESIGN_RATING

The SOX Express Reporting Schema

146

Risk Assertions
Physical Name: SX_RISK_ASSERTIONS
Description: This table contains information relating to risk assertions.
Foreign Key: RISK_ID
Foreign Key Reference: SX_RISK.RISK_ID
Indices: 2

Column Name

Description

Native Type

RISK_ID

The unique ID of the object.

NUMBER(38,0)

RI_ASSERTIONS

May be used to indicate the


financial statement assertions
that must be made on the risk.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_RISK_ASSERTIONS (I1)

RISK_ID

IX2_SX_RISK_ASSERTIONS (I2)

RI_ASSERTIONS

Risk COSO Objective Category


Physical Name: SX_RISK_COSO_OBJECTIVE_CATEGOR
Foreign Key: RISK_ID
Foreign Key Reference: SX_RISK.RISK_ID
Indices: 2

Column Name

Description

Native Type

RISK_ID

The unique ID of the object.

NUMBER(38,0)

RI_COSO_OBJECTIVE_CATEGORY

May be used to identify one or


more of the COSO objective
categories that apply to this
control objective.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_RISK_COSO_OBJECTIVE_CAT (I1)

RISK_ID

IX1_SX_RISK_COSO_OBJECTIVE_CAT (I2)

RI_COSO_OBJECTIVE_CATEGORY

The SOX Express Reporting Schema

147

Controls
Physical Name: SX_CONTROL
Description: This table contains the information relating to the Control compliance object.
Primary Key: CONTROL_ID
Indices: 12

Column Name

Description

Native Type

CONTROL_ID

The unique ID of the compliance


object.

NUMBER(38,0)

CT_ADDITIONAL_DESCRIPTION

May be used to provide HTMLformatted information about the


compliance object.

VARCHAR2(4000)

CT_ASSERTIONS_CONTROLLED

Indicates the financial statement


assertions affected by the
control.

VARCHAR2(4000)

CT_CLASSIFICATION

May be used to determine if this


is a key control and allow the
determination of when, how, and
how often the control must be
tested.

VARCHAR2(256)

CT_CREATIONDATE

Date the compliance object was


created

DATE

CT_CONTROL_METHOD

Identifies how the control is


implemented.

VARCHAR2(256)

CT_CONTROL_OWNER

Identifies the user responsible for


the control

VARCHAR2(4000)

CT_COSO_COMPONENT

May be used to determine to


which of the COSO components
the control best applies.

VARCHAR2(256)

CT_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

CT_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

CT_DESIGN_EFFECTIVENESS

Attests to the effectiveness of the


design of the control.

VARCHAR2(256)

CT_DOCUMENTATION_LOCATION

Identifies where or how


documentation about the control
is stored.

VARCHAR2(4000)

CT_DOES_THE_CONTROL_OWNE
R_PERF

Identifies whether the control


owner is the person responsible
for performing the control
activity.

VARCHAR2(256)

CT_FREQUENCY_OF_CONTROL_A
CTIVI

Identifies the frequency with


which the control is performed.

VARCHAR2(256)

CT_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

CT_IT_SYSTEM

Denotes what IT systems were


affected.

VARCHAR2(256)

The SOX Express Reporting Schema

148

Column Name

Description

Native Type

CT_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

CT_MODIFIEDDATE

The last date the object was


modified

DATE

CT_NAME

The user-defined name of the


object.

VARCHAR2(4000)

CT_OPERATING_EFFECTIVNESS

Attests to the operational


effectiveness of the control.

VARCHAR2(256)

CT_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

CT_POSSIBLE_TEST_TYPES

Determines the different ways in


which the control may be tested.

VARCHAR2(4000)

CT_SITES_COVERED

Denotes which sites are covered


by the control.

VARCHAR2(4000)

CT_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

CT_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

CT_WHO_PERFORMS_CONTROL

If the control owner does not


perform the control, this field
identifies the user assigned to
perform the control.

VARCHAR2(4000)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_CONTROL (I1)

CT_CLASSIFICATION

IX2_SX_CONTROL (I2)

CT_CONTROL_METHOD

IX3_SX_CONTROL (I3)

CT_COSO_COMPONENT

IX4_SX_CONTROL (I4)

CT_CREATOR

IX5_SX_CONTROL (I5)

CT_DESIGN_EFFECTIVENESS

IX6_SX_CONTROL (I6)

CT_DOES_THE_CONTROL_OWNER_PERF

IX7_SX_CONTROL (I7)

CT_FREQUENCY_OF_CONTROL_ACTIVI

IX8_SX_CONTROL (I8)

CT_FULLPATH

IX9_SX_CONTROL (I9)

CT_LOCKSTATUS

IX10_SX_CONTROL (I10)

CT_NAME

IX11_SX_CONTROL (I11)

CT_OPERATING_EFFECTIVENESS

IX12_SX_CONTROL (I12)

CT_PARENTFOLDERID

The SOX Express Reporting Schema

149

Control Assertions Controlled


Physical Name: SX_CONTROL_ASSERTIONS_CONTROLL
Foreign Key: CONTROL_ID
Foreign Key Reference: SX_CONTROL.CONTROL_ID
Indices: 2

Column Name

Description

Native Type

CONTROL_ID

The unique ID of the object.

NUMBER(38,0)

CT_ASSERTIONS_CONTROLLED

Indicates the financial statement


assertions affected by the
control.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_CONTROL_ASSERTIONS_
CONT (I1)

CONTROL_ID

IX2_SX_CONTROL_ASSERTIONS_
CONT (I2)

CT_ASSERTIONS_CONTROLLED

Control IT Systems
Physical Name: SX_CONTROL_IT_SYSTEM
Foreign Key: CONTROL_ID
Foreign Key Reference: SX_CONTROL.CONTROL_ID
Indices: 2

Column Name

Description

Native Type

CONTROL_ID

The unique ID of the object.

NUMBER(38,0)

CT_IT_SYSTEM

Denotes which IT systems were


affected.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_CONTROL_IT_SYSTEM (I1)

CONTROL_ID

IX2_SX_CONTROL_IT_SYSTEM (I2)

CT_IT_SYSTEM

The SOX Express Reporting Schema

150

Control Possible Test Types


Physical Name: SX_CONTROL_POSSIBLE_TEST_TYPES
Foreign Key: CONTROL_ID
Foreign Key Reference: SX_CONTROL.CONTROL_ID
Indices: 2

Column Name

Description

Native Type

CONTROL_ID

The unique ID of the object.

NUMBER(38,0)

CT_POSSIBLE_TEST_TYPES

Determines the different ways in


which the control may be tested.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_CONTROL_POSSIBLE_
TEST_T (I1)

CONTROL_ID

IX2_SX_CONTROL_POSSIBLE_
TEST_T (I2)

CT_POSSIBLE_TEST_TYPES

Control Sites Covered


Physical Name: SX_CONTROL_SITES_COVERED
Foreign Key: CONTROL_ID
Foreign Key Reference: SX_CONTROL.CONTROL_ID
Indices: 2

Column Name

Description

Native Type

CONTROL_ID

The unique ID of the object.

NUMBER(38,0)

CT_SITES_COVERED

Denotes which sites are covered


by the control.

VARCHAR2(256)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_CONTROL_SITES_
COVERED (I1)

CONTROL_ID

IX2_SX_CONTROL_SITES_
COVERED (I2)

CT_SITES_COVERED

The SOX Express Reporting Schema

151

Test
Physical Name: SX_TEST
Description: This table contains the information relating to the Test compliance object.
Primary Key: TEST_ID
Indices: 8

Column Name

Description

Native Type

TEST_ID

The unique ID of the compliance


object.

NUMBER(38,0)

TE_ADDITIONAL_DESCRIPTION

May be used to provide HTMLformatted information about the


compliance object.

VARCHAR2(4000)

TE_CREATIONDATE

Date the compliance object was


created

DATE

TE_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

TE_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

TE_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

TE_GUIDANCE_FOR_TESTER

May be used to document any


additional information that the
Test Performer or Test Reviewer
may find useful when performing
the test.

VARCHAR2(4000)

TE_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

TE_MODIFIEDDATE

The last date the object was


modified

DATE

TE_NAME

The user-defined name of the


object.

VARCHAR2(4000)

TE_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

TE_SAMPLE_SIZE_USED

May be used to determine the


recommended or required sample
size to use when performing the
test.

VARCHAR2(256)

TE_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

TE_TEST_FREQUENCY

How often the test is performed.

VARCHAR2(256)

TE_TEST_FREQUENCY_OFFSET

May be used to set the date for


performing the test in number of
days after the start of the
frequency period.

NUMBER(38,0)

TE_TEST_PERFORMER

The user responsible for


performing the test

VARCHAR2(4000)

TE_TEST_REVIEWER

The user responsible for ensuring


that the test is complete.

VARCHAR2(4000)

The SOX Express Reporting Schema

152

Column Name

Description

Native Type

TE_TEST_TYPES_EXPECTED

Indicates the type of test to be


performed.

VARCHAR2(256)

TE_TESTING_STEPS

May be used to list the steps that


must be completed in order to
correctly perform the test.

VARCHAR2(4000)

TE_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_TEST (I1)

TE_CREATOR

IX2_SX_TEST (I2)

TE_FULLPATH

IX3_SX_TEST (I3)

TE_LOCKSTATUS

IX4_SX_TEST (I4)

TE_NAME

IX5_SX_TEST (I5)

TE_PARENTFOLDERID

IX6_SX_TEST (I6)

TE_SAMPLE_SIZE_USED

IX7_SX_TEST (I7)

TE_TEST_FREQUENCY

IX8_SX_TEST (I8)

TE_TEST_TYPES_EXPECTED

The SOX Express Reporting Schema

153

Test Results
Physical Name: SX_TESTRESULT
Description: This table contains the information relating to the Control compliance object.
Primary Key: TESTRESULT_ID
Indices: 11

Column Name

Description

Native Type

TESTRESULT_ID

The unique ID of the compliance


object.

NUMBER(38,0)

TR_ADDITIONAL_DESCRIPTION

May be used to provide HTMLformatted information about the


compliance object.

VARCHAR2(4000)

TR_CREATIONDATE

Date the compliance object was


created

DATE

TR_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

TR_DATE_PERFORMED

Shows the last date the test was


performed.

DATE

TR_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

TR_EFFECTIVENESS

Attests to the effectiveness of the


design of the control. May be
obsolete.

VARCHAR2(256)

TR_EXCEPTION_DESCRIPTION

If an exception was found, this


field can be used to capture more
information about the exception.

VARCHAR2(4000)

TR_EXCEPTIONS

Indicates whether any exceptions


were found when performing the
test.

VARCHAR2(256)

TR_FULLPATH

VARCHAR2(1024)

TR_IS_THIS_A_RETEST

Indicates whether the test is


being performed again to check a
previous result.

VARCHAR2(256)

TR_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

TR_MODIFIEDDATE

The last date the object was


modified

DATE

TR_NAME

The user-defined name of the


object.

VARCHAR2(4000)

TR_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

TR_PERFORMED_BY

The user name of the person who


performed the test.

VARCHAR2(4000)

TR_PERSON_INQUIRED_OF_
OBSERVED

Indicates whether the person


involved with the performance of
the control being tested was
actually observed during the
performance of the control.

VARCHAR2(4000)

The SOX Express Reporting Schema

154

Column Name

Description

Native Type

TR_REVIEWED_BY

Indicates the user who reviewed


the test result.

VARCHAR2(4000)

TR_REVEWER_CONCLUSION

Indicates the objective


assessment of the reviewer of the
test result.

VARCHAR2(256)

TR_REVIEWER_CONCLUSION_
COMMENT

Provides an area for the reviewer


to mark down his subjective
assessment of the test results in
additional detail.

VARCHAR2(4000)

TR_SAMPLE_SIZE_USED

Identifies the sample size used


during the test.

VARCHAR2(256)

TR_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

TR_TEST_RESULT

Displays the result of the test.

VARCHAR2(256)

TR_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_TESTRESULT (I1)

TR_CREATOR

IX2_SX_TESTRESULT (I2)

TR_EFFECTIVENESS

IX3_SX_TESTRESULT (I3)

TR_EXCEPTIONS

IX4_SX_TESTRESULT (I4)

TR_FULLPATH

IX5_SX_TESTRESULT (I5)

TR_IS_THIS_A_RETEST

IX6_SX_TESTRESULT (I6)

TR_LOCKSTATUS

IX7_SX_TESTRESULT (I7)

TR_NAME

IX8_SX_TESTRESULT (I8)

TR_PARENTFOLDERID

IX9_SX_TESTRESULT (I9)

TR_REVIEWER_CONCLUSION

IX10_SX_TESTRESULT (I10)

TR_SAMPLE_SIZE_USED

IX11_SX_TESTRESULT (I11)

TR_TEST_RESULT

The SOX Express Reporting Schema

155

Issues
Physical Name: SX_ISSUE
Description: This table contains the information relating to Issues.
Primary Key: ISSUE_ID
Indices: 10

Column Name

Description

Native Type

ISSUE_ID

The unique ID of the object.

NUMBER(38,0)

IS_ADDITIONAL_DESCRIPTION

May be used to provide HTMLformatted information about the


compliance object.

VARCHAR2(4000)

IS_ASSIGNEE

Indicates the user who is


responsible for resolving the
issue.

VARCHAR2(4000)

IS_CREATIONDATE

Date the issue was created

DATE

IS_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

IS_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

IS_DETAIL

Hidden field - do not use.

VARCHAR2(4000)

IS_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

IS_ISSUE_CREATED_BY

Lists the user who created the


issue.

VARCHAR2(4000)

IS_ISSUE_IMPACT

Identifies the severity of the


issue.

VARCHAR2(256)

IS_ISSUE_PROBABILITY

The likelihood that the issue will


occur.

VARCHAR2(256)

IS_ISSUE_TYPE

Identifies the nature of the issue


as it relates to the activity being
performed.

VARCHAR2(256)

IS_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

IS_MODIFIEDDATE

The last date the object was


modified

DATE

IS_NAME

The user-defined name of the


object.

VARCHAR2(4000)

IS_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

IS_ROOT_CAUSE_DESCRIPTION

Can be used to provide details


about the selection of the Root
Cause Type.

VARCHAR2(4000)

IS_ROOT_CAUSE_TYPE

May be used to objectively select


the primary reason for the issue
to occur.

VARCHAR2(256)

The SOX Express Reporting Schema

156

Column Name

Description

Native Type

IS_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

IS_STATUS

Displays the status of the issue.

VARCHAR2(256)

IS_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_ISSUE (I1)

IS_CREATOR

IX2_SX_ISSUE (I2)

IS_FULLPATH

IX3_SX_ISSUE (I3)

IS_ISSUE_IMPACT

IX4_SX_ISSUE (I4)

IS_ISSUE_PROBABILITY

IX5_SX_ISSUE (I5)

IS_ISSUE_TYPE

IX6_SX_ISSUE (I6)

IS_LOCKSTATUS

IX7_SX_ISSUE (I7)

IS_NAME

IX8_SX_ISSUE (I8)

TR_PARENTFOLDERID

IX9_SX_ISSUE (I9)

IS_ROOT_CAUSE_TYPE

IX10_SX_ISSUE (I10)

IS_STATUS

The SOX Express Reporting Schema

157

Action Items
Physical Name: SX_ACTIONITEM
Description: This table contains information relating to Action Items.
Primary Key: ACTIONITEM_ID
Indices: 6

Column Name

Description

Native Type

ACTIONITEM_ID

The unique ID of the object.

NUMBER(38,0)

AI_ACTION_ITEM_TYPE

Assigns a classification system to


the action item.

VARCHAR2(4000)

AI_ACTUAL_COMPLETION_DATE

Indicates when the action item


was actually completed.

DATE

AI_ADDITIONAL_DESCRIPTION

May be used to provide HTMLformatted information about the


compliance object.

VARCHAR2(4000)

AI_ASSIGNEE

Indicates the user who is


responsible for resolving the
action item.

VARCHAR2(4000)

AI_BUSINESS_LOCATION

Can be used to identify the


particular location associated
with the action item.

VARCHAR2(4000)

AI_COMMENT

May be used to enter information


each time the action item is
updated.

VARCHAR2(4000)

AI_CREATIONDATE

Date the issue was created

DATE

AI_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

AI_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

AI_DETAIL

Hidden field - do not use.

VARCHAR2(4000)

AI_DUE_DATE

Hidden or obsolete field - use


AI_EXPECTED_DUE_DATE.

DATE

AI_EXPECTED_COMPLETION_
DATE

Sets the expected completion


date of the action item.

DATE

AI_FULLPATH

The folder path of the compliance


object.

VARCHAR2(1024)

AI_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

AI_MODIFIEDDATE

The last date the object was


modified

DATE

AI_NAME

The user-defined name of the


object.

VARCHAR2(4000)

AI_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

AI_PERCENT_COMPLETE

Indicates the progress of work on


the action item.

NUMBER(38,0)

The SOX Express Reporting Schema

158

Column Name

Description

Native Type

AI_PREDECESSOR

Identifies which action item (if


any) must be completed before
work on the current action item
can begin.

VARCHAR2(4000)

AI_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

AI_START_DATE

Indicates when work on the


action item was started.

DATE

AI_STATUS

Displays the status of the action


item.

VARCHAR2(256)

AI_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

Table of Indices

Index Name

Table Column

IX1_SX_ACTIONITEM (I1)

AI_CREATOR

IX2_SX_ACTIONITEM (I2)

AI_FULLPATH

IX3_SX_ACTIONITEM (I3)

AI_LOCKSTATUS

IX4_SX_ACTIONITEM (I4)

AI_NAME

IX5_SX_ACTIONITEM (I5)

AI_PARENTFOLDERID

IX6_SX_ACTIONITEM (I6)

AI_STATUS

Action Item Type


Physical Name: SX_ACTIONITEM_ACTION_ITEM_TYPE
Description: This table contains information relating to Action Items Types.
Foreign Key: ACTIONITEM_ID
Foreign Key Reference: SX_ACTIONITEM.ACTIONITEM_ID
Indices: 2

Column Name

Description

Native Type

ACTIONITEM_ID

The unique ID of the object.

NUMBER(38,0)

AI_ACTION_ITEM_TYPE

Assigns a classification system to


the action item.

VARCHAR2(4000)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

159

Table of Indices

Index Name

Table Column

IX1_SX_ACTIONITEM_ACTION_
ITEM_ (I1)

ACTIONITEM_ID

IX2_SX_ACTIONITEM_ACTION_
ITEM_ (I2)

AI_ACTION_ITEM_TYPE

Signatures
Physical Name: SX_SIGNOFF
Description: This table contains information relating to signatures.
Primary Key: SIGNOFF_ID
Indices: 6

Column Name

Description

Native Type

SIGNOFF_ID

The unique ID of the object.

NUMBER(38,0)

SI_COMMENTS

May be used to enter information


when the signature is created.

VARCHAR2(4000)

SI_CREATIONDATE

Date the signature was created

DATE

SI_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

SI_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

SI_FULLPATH

VARCHAR2(1024)

SI_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

SI_MODIFIEDDATE

The last date the object was


modified

DATE

SI_NAME

The user-defined name of the


object.

VARCHAR2(4000)

SI_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

SI_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

SI_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

160

Table of Indices

Index Name

Table Column

IX1_SX_SIGNOFF (I1)

SI_CREATOR

IX2_SX_SIGNOFF (I2)

SI_FULLPATH

IX3_SX_SIGNOFF (I3)

SI_LOCKSTATUS

IX4_SX_SIGNOFF (I4)

SI_NAME

IX5_SX_SIGNOFF (I5)

SI_PARENTFOLDERID

IX6_SX_SIGNOFF (I6)

SI_STATUS

Files
Physical Name: SX_FILE
Description: This table contains information relating to files.
Primary Key: FILE_ID
Indices: 6

Column Name

Description

Native Type

FILE_ID

The unique ID of the object.

NUMBER(38,0)

FI_CREATIONDATE

Date the signature was created

DATE

FI_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

FI_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

FI_FULLPATH

VARCHAR2(1024)

FI_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

FI_MODIFIEDDATE

The last date the object was


modified

DATE

FI_NAME

The user-defined name of the


object.

VARCHAR2(4000)

FI_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

FI_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

FI_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

161

Table of Indices

Index Name

Table Column

IX1_SX_FILE (I1)

FI_CREATOR

IX2_SX_FILE (I2)

FI_FULLPATH

IX3_SX_FILE (I3)

FI_LOCKSTATUS

IX4_SX_FILE (I4)

FI_NAME

IX5_SX_FILE (I5)

FI_PARENTFOLDERID

Links
Physical Name: SX_LINK
Description: This table contains information relating to files.
Primary Key: LINK_ID
Indices: 6

Column Name

Description

Native Type

LINK_ID

The unique ID of the object.

NUMBER(38,0)

LI_CREATIONDATE

Date the signature was created

DATE

LI_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

LI_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

LI_FULLPATH

VARCHAR2(1024)

LI_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

LI_MODIFIEDDATE

The last date the object was


modified

DATE

LI_NAME

The user-defined name of the


object.

VARCHAR2(4000)

LI_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

LI_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

LI_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

162

Table of Indices

Index Name

Table Column

IX1_SX_LINK (I1)

LI_CREATOR

IX2_SX_LINK (I2)

LI_FULLPATH

IX3_SX_LINK (I3)

LI_LOCKSTATUS

IX4_SX_LINK (I4)

LI_NAME

IX5_SX_LINK (I5)

LI_PARENTFOLDERID

Milestones
Physical Name: SX_MILESTONE
Description: This table contains information relating to files.
Primary Key: MILESTONE_ID
Indices: 6

Column Name

Description

Native Type

MILESTONE_ID

The unique ID of the object.

NUMBER(38,0)

MI_CREATIONDATE

Date the signature was created

DATE

MI_CREATOR

The resource ID of the user who


created the compliance object.

NUMBER(38,0)

MI_DESCRIPTION

The user-created description of


the compliance object

VARCHAR2(2048)

MI_FULLPATH

VARCHAR2(1024)

MI_LOCKSTATUS

Denotes whether the object can


be modified

VARCHAR2(256)

MI_MODIFIEDDATE

The last date the object was


modified

DATE

MI_NAME

The user-defined name of the


object.

VARCHAR2(4000)

MI_PARENTFOLDERID

The unique identifier of the


parent folder of the compliance
object.

NUMBER(38,0)

MI_SOXURL

The constructed URL of the


compliance objects details page.

VARCHAR2(4000)

MI_VERSIONID

The number of the current


version of the compliance object.

NUMBER(38,0)

REPORTING _PERIOD

The user specified label of the


reporting period.

VARCHAR2(256)

The SOX Express Reporting Schema

163

Table of Indices

Index Name

Table Column

IX1_SX_MILESTONE (I1)

MI_CREATOR

IX2_SX_MILESTONE (I2)

MI_FULLPATH

IX3_SX_MILESTONE (I3)

MI_LOCKSTATUS

IX4_SX_MILESTONE (I4)

MI_NAME

IX5_SX_MILESTONE (I5)

MI_PARENTFOLDERID

The SOX Express Reporting Schema

164

Compliance Object Relationship Tables


Relationship tables represent the transitive many-to-many relationships between SOX Express
compliance objects.
Each relationship table has four columns - parent object ID, child object ID, the distance
between parent and child (the nesting level), and the reporting period label. If the distance
between the parent and child objects is 1, the objects are linked directly.
Each relationship table has an index on the parent ID and child ID columns, and foreign keys
referencing the respective compliance object tables.

Business Entity Relationships


Table Name

Parent Object ID

Child Object ID

SX__ENTITY_ENTITY

PARENTENTITY_ID

CHILDENTITY_ID

SX__ENTITY_ACCOUNT

ENTITY_ID

ACCOUNT_ID

SX__ENTITY_SUBACCOUNT

ENTITY_ID

SUBACCOUNT_ID

SX__ENTITY_PROCESS

ENTITY_ID

PROCESS_ID

SX__ENTITY_SUBPROCESS

ENTITY_ID

SUBPROCESS_ID

SX__ENTITY_CONTROLOBJECTIVE

ENTITY_ID

CONTROLOBJECTIVE_ID

SX__ENTITY_RISK

ENTITY_ID

RISK_ID

SX__ENTITY_CONTROL

ENTITY_ID

CONTROL_ID

SX__ENTITY_TEST

ENTITY_ID

TEST_ID

SX__ENTITY_TESTRESULT

ENTITY_ID

TESTRESULT_ID

SX__ENTITY_ISSUE

ENTITY_ID

ISSUE_ID

SX__ENTITY_ACTIONITEM

ENTITY_ID

ACTIONITEM_ID

SX__ENTITY_SIGNOFF

ENTITY_ID

SIGNOFF_ID

SX__ENTITY_FILE

ENTITY_ID

FILE_ID

SX__ENTITY_LINK

ENTITY_ID

LINK_ID

Account Relationships
Table Name

Parent Object ID

Child Object ID

SX__ACCOUNT_SUBACCOUNT

ACCOUNT_ID

SUBACCOUNT_ID

SX__ACCOUNT_ISSUE

ACCOUNT_ID

ISSUE_ID

SX__ACCOUNT_ACTIONITEM

ACCOUNT_ID

ACTIONITEM_ID

SX__ACCOUNT_SIGNOFF

ACCOUNT_ID

SIGNOFF_ID

SX__ACCOUNT_FILE

ACCOUNT_ID

FILE_ID

SX__ACCOUNT_LINK

ACCOUNT_ID

LINK_ID

The SOX Express Reporting Schema

165

Sub-Account Relationships
Table Name

Parent Object ID

Child Object ID

SX__SUBACCOUNT_SUBACCOUNT

PARENTSUBACCOUNT_ID

CHILDSUBACCOUNT_ID

SX__SUBACCOUNT_ISSUE

SUBACCOUNT_ID

ISSUE_ID

SX__SUBACCOUNT_ACTIONITEM

SUBACCOUNT_ID

ACTIONITEM_ID

SX__SUBACCOUNT_SIGNOFF

SUBACCOUNT_ID

SIGNOFF_ID

SX__SUBACCOUNT_FILE

SUBACCOUNT_ID

FILE_ID

SX__SUBACCOUNT_LINK

SUBACCOUNT_ID

LINK_ID

Process Relationships
Table Name

Parent Object ID

Child Object ID

SX__PROCESS_SUBPROCESS

PROCESS_ID

SUBPROCESS_ID

SX__PROCESS_ACCOUNT

PROCESS_ID

ACCOUNT_ID

SX__PROCESS_SUBACCOUNT

PROCESS_ID

SUBACCOUNT_ID

SX__PROCESS_CONTROLOBJECTIVE

PROCESS_ID

CONTROLOBJECTIVE_ID

SX__PROCESS_RISK

PROCESS_ID

RISK_ID

SX__PROCESS_CONTROL

PROCESS_ID

CONTROL_ID

SX__PROCESS_TEST

PROCESS_ID

TEST_ID

SX__PROCESS_TESTRESULT

PROCESS_ID

TESTRESULT_ID

SX__PROCESS_ISSUE

PROCESS_ID

ISSUE_ID

SX__PROCESS_ACTIONITEM

PROCESS_ID

ACTIONITEM_ID

SX__PROCESS_SIGNOFF

PROCESS_ID

SIGNOFF_ID

SX__PROCESS_FILE

PROCESS_ID

FILE_ID

SX__PROCESS_LINK

PROCESS_ID

LINK_ID

The SOX Express Reporting Schema

166

Sub-Process Relationships
Table Name

Parent Object ID

Child Object ID

SX__SUBPROCESS_SUBPROCESS

PARENTSUBPROCESS_ID

CHILDSUBPROCESS_ID

SX__SUBPROCESS_ACCOUNT

SUBPROCESS_ID

ACCOUNT_ID

SX__SUBPROCESS_SUBACCOUNT

SUBPROCESS_ID

SUBACCOUNT_ID

SX__SUBPROCESS_CONTROLOBJ

SUBPROCESS_ID

CONTROLOBJECTIVE_ID

SX__SUBPROCESS_RISK

SUBPROCESS_ID

RISK_ID

SX__SUBPROCESS_CONTROL

SUBPROCESS_ID

CONTROL_ID

SX__SUBPROCESS_TEST

SUBPROCESS_ID

TEST_ID

SX__SUBPROCESS_TESTRESULT

SUBPROCESS_ID

TESTRESULT_ID

SX__SUBPROCESS_ISSUE

SUBPROCESS_ID

ISSUE_ID

SX__SUBPROCESS_ACTIONITEM

SUBPROCESS_ID

ACTIONITEM_ID

SX__SUBPROCESS_SIGNOFF

SUBPROCESS_ID

SIGNOFF_ID

SX__SUBPROCESS_FILE

SUBPROCESS_ID

FILE_ID

SX__SUBPROCESS_LINK

SUBPROCESS_ID

LINK_ID

Control Objective Relationships


Table Name

Parent Object ID

Child Object ID

SX__CONTROLOBJECTIVE_RISK

CONTROLOBJECTIVE_ID

RISK_ID

SX__CONTROLOBJECTIVE_CONTROL

CONTROLOBJECTIVE_ID

CONTROL_ID

SX__CONTROLOBJECTIVE_TEST

CONTROLOBJECTIVE_ID

TEST_ID

SX__CONTROLOBJECTIVE_TESTRESUL

CONTROLOBJECTIVE_ID

TESTRESULT_ID

SX__CONTROLOBJECTIVE_ISSUE

CONTROLOBJECTIVE_ID

ISSUE_ID

SX__CONTROLOBJECTIVE_ACTIONITE

CONTROLOBJECTIVE_ID

ACTIONITEM_ID

SX__CONTROLOBJECTIVE_SIGNOFF

CONTROLOBJECTIVE_ID

SIGNOFF_ID

SX__CONTROLOBJECTIVE_FILE

CONTROLOBJECTIVE_ID

FILE_ID

SX__CONTROLOBJECTIVE_LINK

CONTROLOBJECTIVE_ID

LINK_ID

The SOX Express Reporting Schema

167

Control Relationships
Table Name

Parent Object ID

Child Object ID

SX__CONTROL_TEST

CONTROL_ID

TEST_ID

SX__CONTROL_TESTRESULT

CONTROL_ID

TESTRESULT_ID

SX__CONTROL_ISSUE

CONTROL_ID

ISSUE_ID

SX__CONTROL_ACTIONITEM

CONTROL_ID

ACTIONITEM_ID

SX__CONTROL_SIGNOFF

CONTROL_ID

SIGNOFF_ID

SX__CONTROL_FILE

CONTROL_ID

FILE_ID

SX__CONTROL_LINK

CONTROL_ID

LINK_ID

Test Relationships
Table Name

Parent Object ID

Child Object ID

SX__TEST_TESTRESULT

TEST_ID

TESTRESULT_ID

SX__TEST_ISSUE

TEST_ID

ISSUE_ID

SX__TEST_ACTIONITEM

TEST_ID

ACTIONITEM_ID

SX__TEST_SIGNOFF

TEST_ID

SIGNOFF_ID

SX__TEST_FILE

TEST_ID

FILE_ID

SX__TEST_LINK

TEST_ID

LINK_ID

Test Result Relationships


Table Name

Parent Object ID

Child Object ID

SX__TESTRESULT_ISSUE

TESTRESULT_ID

ISSUE_ID

SX__TESTRESULT_ACTIONITEM

TESTRESULT_ID

ACTIONITEM_ID

SX__TESTRESULT_FILE

TESTRESULT_ID

FILE_ID

SX__TESTRESULT_LINK

TESTRESULT_ID

LINK_ID

Issue Relationships
Table Name

Parent Object ID

Child Object ID

SX__ISSUE_ACTIONITEM

ISSUE_ID

ACTIONITEM_ID

SX__ISSUE_FILE

ISSUE_ID

FILE_ID

SX__ISSUE_LINK

ISSUE_ID

LINK_ID

The SOX Express Reporting Schema

168

Test Result Relationships


Table Name

Parent Object ID

Child Object ID

SX__TESTRESULT_ISSUE

TESTRESULT_ID

ISSUE_ID

SX__TESTRESULT_ACTIONITEM

TESTRESULT_ID

ACTIONITEM_ID

SX__TESTRESULT_FILE

TESTRESULT_ID

FILE_ID

SX__TESTRESULT_LINK

TESTRESULT_ID

LINK_ID

Action Item Relationships


Table Name

Parent Object ID

Child Object ID

SX__ACTIONITEM_FILE

ACTIONITEM_ID

FILE_ID

SX__ACTIONITEM_LINK

ACTIONITEM_ID

LINK_ID

Milestone Relationships
Table Name

Parent Object ID

Child Object ID

SX__MILESTONE_MILESTONE

PARENTMILESTONE_ID

CHILDMILESTONE_ID

SX__MILESTONE_ISSUE

MILESTONE_ID

ISSUE_ID

SX__MILESTONE_ACTIONITEM

MILESTONE_ID

ACTIONITEM_ID

SX__MILESTONE_FILE

MILESTONE_ID

FILE_ID

SX__MILESTONE_LINK

MILESTONE_ID

LINK_ID

The SOX Express Reporting Schema

169

Master Relationships Table


The Master Relationships table contains all of the possible transitive relationships between
parent and child compliance objects.

Milestone Relationships
Physical Name: SX__ASSOCIATION
Primary Key: None
Indices: 4

Column Name

Description

Native Type

PARENT

Parent resource ID

NUMBER(38,0)

PARENT_CTYPE_ID

Parent content type ID

NUMBER(38,0)

PARENTTYPE

Parent type name

VARCHAR2(256)

CHILD

Child resource ID

NUMBER(38,0)

CHILD_CTYPE_ID

Child content type ID

NUMBER(38,0)

CHILDTYPE

Child type name

VARCHAR2(256)

CHILD_LEVEL

Distance between parent and child

NUMBER(38,0)

REPORTING_PERIOD

User specified label

VARCHAR2(256)

Table of Indices

Index Name

Table Column

SX__ASSOC_PARENT_CTYPE_NDX

PARENT_CTYPE_ID

SX__ASSOC_PARENT_NDX

PARENT

SX_ASSOC_CHILD_CTYPE_NDX

CHILD_CTYPE_ID

SX_ASSOC_CHILD_NDX

CHILD

The SOX Express Reporting Schema

170

Security Tables
Security tables are used to create security reports and implement the SOX Express security
filters inside the reporting frameworks that support this feature.
In the Effective Rights table, all of the permission flags can be set to one of the following
values:

Positive one (1) - permission is granted


Negative one (-1) - permission is denied
NULL or zero (0) - permission is not explicitly defined for the object, which effectively
denies access

Effective Rights
Physical Name: EFFECTIVE_RIGHTS
Description: This table contains information relating to the users ability to modify the
resource.
Primary Keys: RESOURCEID, ACTORID
Indices: 1

Column Name

Description

Native Type

RESOURCEID

The unique ID of the folder.

NUMBER(38,0)

ACTORID

The unique ID of the user.

NUMBER(38,0)

READACCESS

Whether the actor has permission to view


the contents of the folder

NUMBER(2,0)

RELATEACCESS

Whether the actor has permission to


associate objects to the contents of the
folder

NUMBER(2,0)

WRITEACCESS

Whether the actor has permission to


modify the contents of the folder

NUMBER(2,0)

DELETEACCESS

Whether the actor has permission to delete


the contents of the folder

NUMBER(2,0)

MANAGEACCESS

Whether the actor has permission to


modify the folder ACLs

NUMBER(2,0)

Table of Indices

Index Name
EFFECTIVE_RIGHTS_UN (I1)

Table Columns
ACTORID, RESOURCEID

The SOX Express Reporting Schema

171

Folders
Physical Name: FOLDERS
Description: This table contains information relating to folders.
Primary Keys: RESOURCEID
Indices: 1

Column Name

Description

Native Type

RESOURCEID

The unique ID of the folder.

NUMBER(38,0)

FULLPATH

The full path of the folder in the


container hierarchy

VARCHAR2(1024)

CREATORID

The unique ID of the creator

NUMBER(38,0)

CREATIONDATE

The date the folder was created

DATE

ACLINHERITFROMPARENT

Whether the folder inherits ACLs from


the parent folders.

NUMBER(38,0)

Table of Indices

Index Name
FOLDERS_FULLPATH (I1)

Table Columns
FULLPATH

Actors
Physical Name: ACTORINFO
Description: This table contains information relating to users.
Primary Keys: ACTORID
Indices: 1

Column Name

Description

Native Type

ACTORID

The unique ID of the user.

NUMBER(38,0)

NAME

The name of the user

VARCHAR2(256)

ADMINLEVEL

Whether the user is an administrator

NUMBER(38,0)

EMAIL

The e-mail address of the user

VARCHAR2(256)

DESCRIPTION

The description of the user

VARCHAR2(1024)

ISIMPORTED
ISHIDDEN

NUMBER(1,0)
Whether the user is shown in user
picklists

NUMBER(1,0)

IMPRTERID

NUMBER(38,0)

OPEDITED

NUMBER(38,0)

The SOX Express Reporting Schema

172

Table of Indices

Index Name
ACTORINFO_UN (I1)

Columns
NAME

Audit Trails
Audit trail information is represented by a single table that aggregates change events to
compliance objects and the relationships between them.

Audit Trail
Physical Name: SX_AUDIT
Description: This table contains information relating to the audit trails.
Primary Keys: None.
Indices: 3

Column Name

Description

Native Type

RESOURCEID

The unique ID of the resource

NUMBER(38,0)

VERSIONID

The version ID of the resource

NUMBER(38,0)

RESOURCE_NAME

The name of the resource

VARCHAR2(256)

RESOURCE_TYPE

The content type of the resource

VARCHAR2(256)

WHO

The user who made the change

VARCHAR2(230)

WHEN

When the change was made

DATE

WHICH_PROPERTY

Identifies the property that was


changed

VARCHAR2(256)

ACTION

Identifies the action performed on the


resource

VARCHAR(7)

OLD_VALUE

The previous value of the modified


property

VARCHAR2(4000)

NEW_VALUE

The edited value of the modified


property

VARCHAR2(4000)

CHANGE

Description of the change

VARCHAR2(4000)

Table of Indices

Index Name

Columns

SX_AUDIT_RES_NDX (I1)

RESOURCEID

SX_AUDIT_VER_NDX (I2)

VERSIONID

SX_AUDIT_WHEN_NDX (I3)

WHEN

The SOX Express Reporting Schema

173

Integrating with
TeamMate

What is TeamMate?
TeamMate EWP (Electronic Working Paper) is an audit management
system developed by PricewaterhouseCooper (PwC) that allows
auditors to increase the efficiency of the entire auditing process.
With Sarbanes-Oxley Express support for exporting and importing data
to and from TeamMate, you can leverage your existing auditing
infrastructure to interface with your SOX Express compliance object
model.

How TeamMate and SOX Express Interact


In order to use TeamMate EWP with SOX Express, you must use a
report to select the processes you wish to audit and export the relevant
information (Risks, Controls, and Tests) to an XML file. A translation
tool then transforms the generated XML to the corresponding
TeamMate XML structure. Once the translation is complete, the
resulting file is then imported into TeamMate for the auditors to work
on.
After the auditing is completed, the results of the audit can be exported
from TeamMate and transformed back into the SOX Express format.
The audit information can then be imported into SOX Express as Test
Results, Issues, and Action Items, while the appropriate fields for each
object are updated with the auditing results.
An overview of the process looks like this:

Risks, Controls, and Tests are exported from SOX Express.


Data is transformed from SOX Express XML structure to
TeamMates XML structure.
Resulting data is imported into TeamMate.
Auditors then test as necessary.
The auditing data is then exported to an XML file.
The XML file is transformed back to SOX Express XML
structure.
Resulting file is imported into SOX Express as Test Results,
Issues, and Action Items
The compliance objects are updated with the results of the
audit testing.

Note: The TeamMate Integration Module only exports compliance


object information from the Current Reporting Period.

174

TeamMate/SOX Express Naming Schemes


The following tables explain how the different compliance objects are represented in SOX
Express and TeamMates hierarchy structure:

SOX Express Object

TeamMate Equivalent

Business Entity and Process

Project (establishing context)

Risk, Control, and Test

Procedure

TeamMate Object

SOX Express Equivalent

Procedure (with unique Test ID)

Test (already exists in SOX Express)

Test Result

Test Result

Exception (Issue)

Issue and Action Item

Exporting Data to TeamMate 175

Exporting Data to TeamMate


How Exporting Data Works
When you export data from SOX Express to TeamMate, you run a pre-defined report and select
a process (or set of processes) that you wish to export to TeamMate. When you click Export,
all of the Risks, Controls, and Tests underneath those processes (and any sub-processes
beneath them) are exported to an XML file that can be imported into TeamMate.
Because TeamMate uses a two-tiered organizational structure (Projects and Areas), while SOX
Express allows many levels of nesting, when data is exported to TeamMate, the top-level
process will be used as the Project, and the lowest level sub-process will be used as the Area.
All nesting information will be maintained as properties, but specific Areas for the intermediate
levels will not (can not) be created.

Setting Up The Schema Mapping


Before running the export procedure for the first time, you will need to set up the mapping
between your SOX Express schema and the TeamMate import schema. A sample file is provided
that maps the default SOX Standard Schema to TeamMate, but any customization you have
made to your schema must be represented in the mapping XML file.

Running the TeamMate Export Report


After completing the TIM installation procedure, a new Reporting area was created named
TeamMate that contains a new report named TeamMate Export. Running the report allows
you to choose the scope of the report by listing the available business entities.
After choosing a business entity, the report displays a list of processes contained within that
business entity. By selecting the checkbox next to a process or sub-process, that object will be
exported to the TeamMate XML file when the file is generated.
Once you have finished selecting the processes to be exported, click the Export button at the
top of the report. The report will execute and create the TeamMate XML file containing the
selected processes.
You will recieve a prompt to save the generated file. Click Save and choose the location to
place the generated file.
Note: If you have specified an inclusion criteria within the TeamMateIntegration.properties file,
an additional button will be displayed to export TeamMate Tests. Clicking this button will
ignore any selections you have made from the process list and export only those objects (within
the current scope) that match the criteria you specifed in the properties file.

Importing the Data Into TeamMate


Please refer to your TeamMate documentation on importing external data files.

Exporting Data to TeamMate 176

Troubleshooting the Export Process


Some or all of the selected processes are not being exported.

If you have selected a process that does not contain Risks, Controls, or Tests, that
Process will not be exported.
If you have turned on the option to export Tests without Test Results, some of the
selected processes may already have Test Results associated with their Tests and
therefore would not be exported.
Make sure you are clicking the Export button, and not the Export TeamMate Tests
button. Clicking the Export TeamMate Tests button will ignore the selected processes
and compare all processes in the selected business entities with the property criteria
specified in the properties file.

Importing Data From TeamMate 177

Importing Data From TeamMate


How Importing Data Works
After the auditing team has finished testing the controls exported from SOX Express, the
collected data must be exported from TeamMate and re-imported back into SOX Express.
The main steps for importing data from TeamMate are:

Exporting the Data From TeamMate


Transforming the XML File
Importing the TeamMate Data

Exporting the Data From TeamMate


Directions for exporting the TeamMate data can be found in the TeamMate documentation.
When you export the necessary data from TeamMate, be sure to select the Export to SOX
Express option.

Transforming the XML File


Once you have generated the XML file containing the exported TeamMate data, you must
transform the XML into the OP XML format. SOX Express provides a command to perform this
transformation - teammatesox.
To transform the TeamMate XML file, do the following:
1.
2.
3.
4.

Copy the TeamMate output file to a directory on the application server.


Open a command window on the application server.
Change directories to the location of the TeamMate XML file.
Type the following on a single line:
teammatesox <input_file> TM_OP_XSL.xsl teammate_data-op-config.xml
where:
<input_file> is the name of the XML file you generated from TeamMate
The name of the output file (teammate_data-op-config.xml) can be customized if you
desire, but the filename must end in -op-config.xml. This is required because the
import tool for SOX Express expects this filename convention.

Importing the TeamMate Data


After the transformation is complete, you must import the generated file into SOX Express.
To import the transformed file:
1.
2.

Open a command window on the application server, if one is not already open.
Go to the WebLogic Server OpenpagesDomain directory and run the following
command on a single line:
ObjectManager load config SOXAdministrator <password>
<config-folder-path> <prefix>
Where:
<password> is the password to the SOXAdministrator account.
<config-folder-path> is the folder where the input files for the load process are to be
found (if not specified, they will be loaded from the current directory).

Importing Data From TeamMate 178

<prefix> is the prefix of the files used by the load process. For example, if the
generated filename of the TeamMate import file is teammate_data-op-config.xml, the
<prefix> value would be teammate_data (without the quotes).
3.

After ObjectManager has completed the command, close the command window.

Displaying the TeamMate Properties


When the TeamMate data is imported back into the SOX Express system, it contains some
additional properties added by TeamMate. These properties will not display in the SOX Express
user interface until definitions for the properties are added to the configTileDefinitions.xml file.
The new fields are:

Compliance
Object Type
Test (SOXTest)

Bundle Name
SOXTestTeammate

Property Name
Teammate Test
Performer
Teammate Test
Reviewer

Test Result
(SOXTestResult)

SOXTestResultTeammate

Teammate Project ID
Teammate Test Result
Conclusion
Teammate Date
Performed
Teammate Date
Reviewed

Issue (SOXIssue)

SOXIssueTeammate

Teammate Issue
Impact

Task (SOXTask)

SOXTaskTeammate

Teammate Action Item


Status

For each of these fields, you must complete the following procedure to display the new field in
SOX Express:
The next step in the process of enabling your new property is to edit the
configTileDefinitions.xml file so that your new property is recognized by the SOX Express
application.
To activate the new property:
1.

Log in to the server machine and navigate to the following directory:


<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.

2.

Open the configTileDefinitions.xml file in a text editor.


Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.

3.

Find the definitions section for the compliance object you want to modify, as identified
by the string <object>.prop.body where <object> is the object you want to modify. For
example, if you are modifying a test, the string would be test.prop.body.

4.
5.

Remove the comment tags (<!-- and -->) from the object definition if this is the
first time you are modifying the object.
Modify the <putlist> tag to include the definition for the new property, as in the
example below:
<putList name="property.list">
<add value="test.property.isEffective"/>
<add value="test.property.newProp"/>
</putList>
The order of the property definitions controls the order in which they will be listed on
the object Details page and in the Add and Edit pages. Insert the new property
definition into the spot where you want the property to be listed.
Make sure the name for the new property definition (i.e. test.property.newProp in this
example) does not inadvertently match another property definition already defined for
the object.
Note: When modifying the Business Entity definition (busentity.prop.body), you must
remove the three sample property definition lines from the sample business entity
definition. The lines to be removed are:
<add value="customer.busentity.property.newProp"/>
<add value="customer.entity.property.ExecutiveOwner"/>
<add value="customer.entity.property.PrimaryOwner"/>

6.

Add the definition tag for the new property after the <definition> end tag containing
the <putlist> tag, using the format of the example below. A sample definition tag can
also be found in the XML file. Portions of the example in bold text should be replaced
with text specific to your property.
<definition>
<putList name="property.list">
<add value="test.property.isEffective"/>
<add value="test.property.newProp"/>
</putList>
</definition>
<definition name="test.property.newProp">
<put name="bundle.name" value="TestBundle"/>
<put name="property.name" value="AddedProperty"/>
</definition>
The string test.property.newProp should be replaced with the property name as defined
in the property list (e.g. test.property.teammateTestPerformer). The string
TestBundle should be replaced with the name of your new property bundle (e.g.
SOXTestTeammate). The string AddedProperty should be replaced with the name of
the new property you are adding (e.g. Teammate Test Performer.
After modification, the new property definition should look like this:
<definition name="test.property.TeammateTestPerformer">
<put name="bundle.name" value="SOXTestTeammate"/>
<put name="property.name" value="Teammate Test Performer"/>
</definition>
Make sure you match the spelling and case of the property bundle and property name
exactly. Use the values in the above table to determine the values you should be using
in your new definitions.

7.

Save the configTileDefinitions.xml file.